Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1718805 > unrolled thread

Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-08-24 06:00 +0200
    Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Baoquan He <bhe@redhat.com> - 2017-08-24 10:10 +0200
      Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-08-24 11:30 +0200
        Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Baoquan He <bhe@redhat.com> - 2017-08-24 12:30 +0200
          Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-08-24 12:50 +0200
    Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-24 18:50 +0200
      Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-08-25 04:10 +0200
        Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-25 14:40 +0200
          Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization  earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-08-25 16:10 +0200

#1718805 — Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Hi Rafael, Zheng,

At 07/31/2017 06:50 PM, Dou Liyang wrote:
> Hi,
>
> At 07/14/2017 01:52 PM, Dou Liyang wrote:
>> Linux uses acpi_early_init() to put the ACPI table management into
>> the late stage from the early stage where the mapped ACPI tables is
>> temporary and should be unmapped.
>>
>> But, now initializing interrupt delivery mode should map and parse the
>> DMAR table earlier in the early stage. This causes an ACPI error when
>> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
>> the DMAR table after using in the early stage.
>>
>> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
>> be mapped and parsed in late stage like before.
>>
>> Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
>> Cc: linux-acpi@vger.kernel.org
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Zheng, Lv <lv.zheng@intel.com>
>> Cc: Julian Wollrath <jwollrath@web.de>
>> ---
>> Test in my own PC(Lenovo M4340).
>> Ask help for doing regression testing for the bug said in commit
>> c4e1acbb35e4
>> ("ACPI / init: Invoke early ACPI initialization later").
>>
>
> Now, I can prove this patch doesn't result in the bug[1] which made the
> fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
> APU).
>
> The true reason of the bug is enabling ACPI subsystem earlier than
> using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
> could fix this bug as Julian tested and said[2].
>
> And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
> platform to the ACPI mode later") split the ACPI early initialization
> code into acpi_early_init() and acpi_subsystem_init(). executing
> acpi_enable_subsystem() at the original early ACPI initialization spot.
>
> The sequence of them shows below:
>
>  start_kernel
> +---------------+
> |
> +--> .......
> |
> |    late_time_init()
> +--> +-------+
> |
> +--> .......
> |
> |    acpi_early_init()
> +--> +-------+
> |
> +--> .......
> |
> |   acpi_subsystem_init()
> +-> +--------+
>
> We make sure the acpi_subsystem_init() is called later than
> late_time_init(), the bug will be avoided.
>
> This patch changes the sequence of late_time_init() and
> acpi_early_init(), doesn't effect acpi_subsystem_init().
>
> So, this patch is OK.
>
> Btw, Thanks very much for Borislav Petkov, he will have access to
> Thinkpad x121e from Mid-August and will test this series.
>

Almost one month passed, Borislav have tested this series in Thinkpad
x121e and I also have tested in my box and QEmu again. It is OK.

BTW,
1) I found your commit b064a8fa77df (" ACPI / init: Switch over
platform to the ACPI mode later") split the ACPI early initialization
code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
the ACPI subsystem is in acpi_subsystem_init().

2) As we discussed earlier, invoking acpi_put_table() is not good for
this situation.

So I do this patch, Is that goot to you? Any comments will be welcome.

If it is OK, As the patches need to be re-based, and I also found
several spelling mistake, I will send a new version next week.

Thanks,
	dou.

> [1] https://lkml.org/lkml/2014/3/10/123
> [2] https://lkml.org/lkml/2014/3/12/311
>
>
> Thanks
>     dou.
>
>>  init/main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/init/main.c b/init/main.c
>> index df58a41..7a09467 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>>      kmemleak_init();
>>      setup_per_cpu_pageset();
>>      numa_policy_init();
>> +    acpi_early_init();
>>      if (late_time_init)
>>          late_time_init();
>>      calibrate_delay();
>>      pidmap_init();
>>      anon_vma_init();
>> -    acpi_early_init();
>>  #ifdef CONFIG_X86
>>      if (efi_enabled(EFI_RUNTIME_SERVICES))
>>          efi_enter_virtual_mode();
>>

[toc] | [next] | [standalone]

#1718945

Hi Liyang,

On 08/24/17 at 11:54am, Dou Liyang wrote:
> > > Test in my own PC(Lenovo M4340).
> > > Ask help for doing regression testing for the bug said in commit
> > > c4e1acbb35e4
> > > ("ACPI / init: Invoke early ACPI initialization later").
> > > 
> > 
> > Now, I can prove this patch doesn't result in the bug[1] which made the
> > fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
> > APU).
> > 
> > The true reason of the bug is enabling ACPI subsystem earlier than
> > using PIT, not the SCI setup. invoking acpi_enable_subsystem() later

Seems redhat mail server was down earlier, I didn't receive new mail in
this thread.  Just curious, do you know why the fast tsc calibration
using PIT will fail if enabling ACPI subsystem earlier than using PIT?

Thanks
Baoquan

> > could fix this bug as Julian tested and said[2].
> > 
> > And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
> > platform to the ACPI mode later") split the ACPI early initialization
> > code into acpi_early_init() and acpi_subsystem_init(). executing
> > acpi_enable_subsystem() at the original early ACPI initialization spot.
> > 
> > The sequence of them shows below:
> > 
> >  start_kernel
> > +---------------+
> > |
> > +--> .......
> > |
> > |    late_time_init()
> > +--> +-------+
> > |
> > +--> .......
> > |
> > |    acpi_early_init()
> > +--> +-------+
> > |
> > +--> .......
> > |
> > |   acpi_subsystem_init()
> > +-> +--------+
> > 
> > We make sure the acpi_subsystem_init() is called later than
> > late_time_init(), the bug will be avoided.
> > 
> > This patch changes the sequence of late_time_init() and
> > acpi_early_init(), doesn't effect acpi_subsystem_init().
> > 
> > So, this patch is OK.
> > 
> > Btw, Thanks very much for Borislav Petkov, he will have access to
> > Thinkpad x121e from Mid-August and will test this series.
> > 
> 
> Almost one month passed, Borislav have tested this series in Thinkpad
> x121e and I also have tested in my box and QEmu again. It is OK.
> 
> BTW,
> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
> platform to the ACPI mode later") split the ACPI early initialization
> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
> the ACPI subsystem is in acpi_subsystem_init().
> 
> 2) As we discussed earlier, invoking acpi_put_table() is not good for
> this situation.
> 
> So I do this patch, Is that goot to you? Any comments will be welcome.
> 
> If it is OK, As the patches need to be re-based, and I also found
> several spelling mistake, I will send a new version next week.
> 
> Thanks,
> 	dou.
> 
> > [1] https://lkml.org/lkml/2014/3/10/123
> > [2] https://lkml.org/lkml/2014/3/12/311
> > 
> > 
> > Thanks
> >     dou.
> > 
> > >  init/main.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/init/main.c b/init/main.c
> > > index df58a41..7a09467 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
> > >      kmemleak_init();
> > >      setup_per_cpu_pageset();
> > >      numa_policy_init();
> > > +    acpi_early_init();
> > >      if (late_time_init)
> > >          late_time_init();
> > >      calibrate_delay();
> > >      pidmap_init();
> > >      anon_vma_init();
> > > -    acpi_early_init();
> > >  #ifdef CONFIG_X86
> > >      if (efi_enabled(EFI_RUNTIME_SERVICES))
> > >          efi_enter_virtual_mode();
> > > 
> 
> 

[toc] | [prev] | [next] | [standalone]

#1719060

Hi Baoquan,

Thanks for your reply.

At 08/24/2017 04:05 PM, Baoquan He wrote:
> Hi Liyang,
>
> On 08/24/17 at 11:54am, Dou Liyang wrote:
>>>> Test in my own PC(Lenovo M4340).
>>>> Ask help for doing regression testing for the bug said in commit
>>>> c4e1acbb35e4
>>>> ("ACPI / init: Invoke early ACPI initialization later").
>>>>
>>>
>>> Now, I can prove this patch doesn't result in the bug[1] which made the
>>> fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
>>> APU).
>>>
>>> The true reason of the bug is enabling ACPI subsystem earlier than
>>> using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
>
> Seems redhat mail server was down earlier, I didn't receive new mail in
> this thread.  Just curious, do you know why the fast tsc calibration
> using PIT will fail if enabling ACPI subsystem earlier than using PIT?
>
It's related to particular hardware, As you know, I tested in many
kinds of PC and laptop and PIT works well no matter before or after
enabling ACPI subsystem.

In pit_verify_msb(), we use inb(0x42) to read the current MSB,

Normally, the value is continuously, like following shows:

msb = fe
msb = fd
msb = fc
msb = fb
msb = fa
msb = f9
msb = f8
msb = f7
msb = f6
...

But, if in some particular hardware, you will see like that:

msb = fe
msb = f0
msb = ed
msb = e9
msb = e0
msb = db
...

In this case, the count in pit_expect_msb() is always zero.
So we will see "Fast TSC calibration failed" in our dmesg log.

For the further deep reason why the hardware failed, I'm sorry
I can't answer and don't know how to investigate. For hardware,
I usually change a new one directly and know very little.

Thanks,
	dou.


> Thanks
> Baoquan
>
>>> could fix this bug as Julian tested and said[2].
>>>
>>> And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
>>> platform to the ACPI mode later") split the ACPI early initialization
>>> code into acpi_early_init() and acpi_subsystem_init(). executing
>>> acpi_enable_subsystem() at the original early ACPI initialization spot.
>>>
>>> The sequence of them shows below:
>>>
>>>  start_kernel
>>> +---------------+
>>> |
>>> +--> .......
>>> |
>>> |    late_time_init()
>>> +--> +-------+
>>> |
>>> +--> .......
>>> |
>>> |    acpi_early_init()
>>> +--> +-------+
>>> |
>>> +--> .......
>>> |
>>> |   acpi_subsystem_init()
>>> +-> +--------+
>>>
>>> We make sure the acpi_subsystem_init() is called later than
>>> late_time_init(), the bug will be avoided.
>>>
>>> This patch changes the sequence of late_time_init() and
>>> acpi_early_init(), doesn't effect acpi_subsystem_init().
>>>
>>> So, this patch is OK.
>>>
>>> Btw, Thanks very much for Borislav Petkov, he will have access to
>>> Thinkpad x121e from Mid-August and will test this series.
>>>
>>
>> Almost one month passed, Borislav have tested this series in Thinkpad
>> x121e and I also have tested in my box and QEmu again. It is OK.
>>
>> BTW,
>> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
>> platform to the ACPI mode later") split the ACPI early initialization
>> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
>> the ACPI subsystem is in acpi_subsystem_init().
>>
>> 2) As we discussed earlier, invoking acpi_put_table() is not good for
>> this situation.
>>
>> So I do this patch, Is that goot to you? Any comments will be welcome.
>>
>> If it is OK, As the patches need to be re-based, and I also found
>> several spelling mistake, I will send a new version next week.
>>
>> Thanks,
>> 	dou.
>>
>>> [1] https://lkml.org/lkml/2014/3/10/123
>>> [2] https://lkml.org/lkml/2014/3/12/311
>>>
>>>
>>> Thanks
>>>     dou.
>>>
>>>>  init/main.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/init/main.c b/init/main.c
>>>> index df58a41..7a09467 100644
>>>> --- a/init/main.c
>>>> +++ b/init/main.c
>>>> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>>>>      kmemleak_init();
>>>>      setup_per_cpu_pageset();
>>>>      numa_policy_init();
>>>> +    acpi_early_init();
>>>>      if (late_time_init)
>>>>          late_time_init();
>>>>      calibrate_delay();
>>>>      pidmap_init();
>>>>      anon_vma_init();
>>>> -    acpi_early_init();
>>>>  #ifdef CONFIG_X86
>>>>      if (efi_enabled(EFI_RUNTIME_SERVICES))
>>>>          efi_enter_virtual_mode();
>>>>
>>
>>
>
>
>

[toc] | [prev] | [next] | [standalone]

#1719123

On 08/24/17 at 05:28pm, Dou Liyang wrote:
> Hi Baoquan,
> 
> Thanks for your reply.
> 
> At 08/24/2017 04:05 PM, Baoquan He wrote:
> > Hi Liyang,
> > 
> > On 08/24/17 at 11:54am, Dou Liyang wrote:
> > > > > Test in my own PC(Lenovo M4340).
> > > > > Ask help for doing regression testing for the bug said in commit
> > > > > c4e1acbb35e4
> > > > > ("ACPI / init: Invoke early ACPI initialization later").
> > > > > 
> > > > 
> > > > Now, I can prove this patch doesn't result in the bug[1] which made the
> > > > fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
> > > > APU).
> > > > 
> > > > The true reason of the bug is enabling ACPI subsystem earlier than
> > > > using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
> > 
> > Seems redhat mail server was down earlier, I didn't receive new mail in
> > this thread.  Just curious, do you know why the fast tsc calibration
> > using PIT will fail if enabling ACPI subsystem earlier than using PIT?
> > 
> It's related to particular hardware, As you know, I tested in many
> kinds of PC and laptop and PIT works well no matter before or after
> enabling ACPI subsystem.
> 
> In pit_verify_msb(), we use inb(0x42) to read the current MSB,
> 
> Normally, the value is continuously, like following shows:
> 
> msb = fe
> msb = fd
> msb = fc
> msb = fb
> msb = fa
> msb = f9
> msb = f8
> msb = f7
> msb = f6
> ...
> 
> But, if in some particular hardware, you will see like that:
> 
> msb = fe
> msb = f0
> msb = ed
> msb = e9
> msb = e0
> msb = db
> ...
> 
> In this case, the count in pit_expect_msb() is always zero.
> So we will see "Fast TSC calibration failed" in our dmesg log.

Thanks for telling!

It's truly weird that the TSC becomes unstable only if enabling ACPI
subsystem earlier than using PIT.

Let's see what other people say about this.

Btw, you will resend another round, right? Then I would like to test
your new post.

Thanks
Baoquan

> 
> For the further deep reason why the hardware failed, I'm sorry
> I can't answer and don't know how to investigate. For hardware,
> I usually change a new one directly and know very little.
> 
> Thanks,
> 	dou.
> 
> 
> > Thanks
> > Baoquan
> > 
> > > > could fix this bug as Julian tested and said[2].
> > > > 
> > > > And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
> > > > platform to the ACPI mode later") split the ACPI early initialization
> > > > code into acpi_early_init() and acpi_subsystem_init(). executing
> > > > acpi_enable_subsystem() at the original early ACPI initialization spot.
> > > > 
> > > > The sequence of them shows below:
> > > > 
> > > >  start_kernel
> > > > +---------------+
> > > > |
> > > > +--> .......
> > > > |
> > > > |    late_time_init()
> > > > +--> +-------+
> > > > |
> > > > +--> .......
> > > > |
> > > > |    acpi_early_init()
> > > > +--> +-------+
> > > > |
> > > > +--> .......
> > > > |
> > > > |   acpi_subsystem_init()
> > > > +-> +--------+
> > > > 
> > > > We make sure the acpi_subsystem_init() is called later than
> > > > late_time_init(), the bug will be avoided.
> > > > 
> > > > This patch changes the sequence of late_time_init() and
> > > > acpi_early_init(), doesn't effect acpi_subsystem_init().
> > > > 
> > > > So, this patch is OK.
> > > > 
> > > > Btw, Thanks very much for Borislav Petkov, he will have access to
> > > > Thinkpad x121e from Mid-August and will test this series.
> > > > 
> > > 
> > > Almost one month passed, Borislav have tested this series in Thinkpad
> > > x121e and I also have tested in my box and QEmu again. It is OK.
> > > 
> > > BTW,
> > > 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
> > > platform to the ACPI mode later") split the ACPI early initialization
> > > code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
> > > the ACPI subsystem is in acpi_subsystem_init().
> > > 
> > > 2) As we discussed earlier, invoking acpi_put_table() is not good for
> > > this situation.
> > > 
> > > So I do this patch, Is that goot to you? Any comments will be welcome.
> > > 
> > > If it is OK, As the patches need to be re-based, and I also found
> > > several spelling mistake, I will send a new version next week.
> > > 
> > > Thanks,
> > > 	dou.
> > > 
> > > > [1] https://lkml.org/lkml/2014/3/10/123
> > > > [2] https://lkml.org/lkml/2014/3/12/311
> > > > 
> > > > 
> > > > Thanks
> > > >     dou.
> > > > 
> > > > >  init/main.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/init/main.c b/init/main.c
> > > > > index df58a41..7a09467 100644
> > > > > --- a/init/main.c
> > > > > +++ b/init/main.c
> > > > > @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
> > > > >      kmemleak_init();
> > > > >      setup_per_cpu_pageset();
> > > > >      numa_policy_init();
> > > > > +    acpi_early_init();
> > > > >      if (late_time_init)
> > > > >          late_time_init();
> > > > >      calibrate_delay();
> > > > >      pidmap_init();
> > > > >      anon_vma_init();
> > > > > -    acpi_early_init();
> > > > >  #ifdef CONFIG_X86
> > > > >      if (efi_enabled(EFI_RUNTIME_SERVICES))
> > > > >          efi_enter_virtual_mode();
> > > > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 

[toc] | [prev] | [next] | [standalone]

#1719143

At 08/24/2017 06:21 PM, Baoquan He wrote:
> On 08/24/17 at 05:28pm, Dou Liyang wrote:
>> Hi Baoquan,
>>
>> Thanks for your reply.
>>
>> At 08/24/2017 04:05 PM, Baoquan He wrote:
>>> Hi Liyang,
>>>
>>> On 08/24/17 at 11:54am, Dou Liyang wrote:
>>>>>> Test in my own PC(Lenovo M4340).
>>>>>> Ask help for doing regression testing for the bug said in commit
>>>>>> c4e1acbb35e4
>>>>>> ("ACPI / init: Invoke early ACPI initialization later").
>>>>>>
>>>>>
>>>>> Now, I can prove this patch doesn't result in the bug[1] which made the
>>>>> fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
>>>>> APU).
>>>>>
>>>>> The true reason of the bug is enabling ACPI subsystem earlier than
>>>>> using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
>>>
>>> Seems redhat mail server was down earlier, I didn't receive new mail in
>>> this thread.  Just curious, do you know why the fast tsc calibration
>>> using PIT will fail if enabling ACPI subsystem earlier than using PIT?
>>>
>> It's related to particular hardware, As you know, I tested in many
>> kinds of PC and laptop and PIT works well no matter before or after
>> enabling ACPI subsystem.
>>
>> In pit_verify_msb(), we use inb(0x42) to read the current MSB,
>>
>> Normally, the value is continuously, like following shows:
>>
>> msb = fe
>> msb = fd
>> msb = fc
>> msb = fb
>> msb = fa
>> msb = f9
>> msb = f8
>> msb = f7
>> msb = f6
>> ...
>>
>> But, if in some particular hardware, you will see like that:
>>
>> msb = fe
>> msb = f0
>> msb = ed
>> msb = e9
>> msb = e0
>> msb = db
>> ...
>>
>> In this case, the count in pit_expect_msb() is always zero.
>> So we will see "Fast TSC calibration failed" in our dmesg log.
>
> Thanks for telling!
>
> It's truly weird that the TSC becomes unstable only if enabling ACPI
> subsystem earlier than using PIT.
>
> Let's see what other people say about this.
>
> Btw, you will resend another round, right? Then I would like to test
> your new post.

Yes, I am waiting ACPI maintainers advice and I prepare to re-base it
next week when rc7 is out.

Thanks,
	dou.

>
> Thanks
> Baoquan
>
>>
>> For the further deep reason why the hardware failed, I'm sorry
>> I can't answer and don't know how to investigate. For hardware,
>> I usually change a new one directly and know very little.
>>
>> Thanks,
>> 	dou.
>>
>>
>>> Thanks
>>> Baoquan
>>>
>>>>> could fix this bug as Julian tested and said[2].
>>>>>
>>>>> And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
>>>>> platform to the ACPI mode later") split the ACPI early initialization
>>>>> code into acpi_early_init() and acpi_subsystem_init(). executing
>>>>> acpi_enable_subsystem() at the original early ACPI initialization spot.
>>>>>
>>>>> The sequence of them shows below:
>>>>>
>>>>>  start_kernel
>>>>> +---------------+
>>>>> |
>>>>> +--> .......
>>>>> |
>>>>> |    late_time_init()
>>>>> +--> +-------+
>>>>> |
>>>>> +--> .......
>>>>> |
>>>>> |    acpi_early_init()
>>>>> +--> +-------+
>>>>> |
>>>>> +--> .......
>>>>> |
>>>>> |   acpi_subsystem_init()
>>>>> +-> +--------+
>>>>>
>>>>> We make sure the acpi_subsystem_init() is called later than
>>>>> late_time_init(), the bug will be avoided.
>>>>>
>>>>> This patch changes the sequence of late_time_init() and
>>>>> acpi_early_init(), doesn't effect acpi_subsystem_init().
>>>>>
>>>>> So, this patch is OK.
>>>>>
>>>>> Btw, Thanks very much for Borislav Petkov, he will have access to
>>>>> Thinkpad x121e from Mid-August and will test this series.
>>>>>
>>>>
>>>> Almost one month passed, Borislav have tested this series in Thinkpad
>>>> x121e and I also have tested in my box and QEmu again. It is OK.
>>>>
>>>> BTW,
>>>> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
>>>> platform to the ACPI mode later") split the ACPI early initialization
>>>> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
>>>> the ACPI subsystem is in acpi_subsystem_init().
>>>>
>>>> 2) As we discussed earlier, invoking acpi_put_table() is not good for
>>>> this situation.
>>>>
>>>> So I do this patch, Is that goot to you? Any comments will be welcome.
>>>>
>>>> If it is OK, As the patches need to be re-based, and I also found
>>>> several spelling mistake, I will send a new version next week.
>>>>
>>>> Thanks,
>>>> 	dou.
>>>>
>>>>> [1] https://lkml.org/lkml/2014/3/10/123
>>>>> [2] https://lkml.org/lkml/2014/3/12/311
>>>>>
>>>>>
>>>>> Thanks
>>>>>     dou.
>>>>>
>>>>>>  init/main.c | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/init/main.c b/init/main.c
>>>>>> index df58a41..7a09467 100644
>>>>>> --- a/init/main.c
>>>>>> +++ b/init/main.c
>>>>>> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>>>>>>      kmemleak_init();
>>>>>>      setup_per_cpu_pageset();
>>>>>>      numa_policy_init();
>>>>>> +    acpi_early_init();
>>>>>>      if (late_time_init)
>>>>>>          late_time_init();
>>>>>>      calibrate_delay();
>>>>>>      pidmap_init();
>>>>>>      anon_vma_init();
>>>>>> -    acpi_early_init();
>>>>>>  #ifdef CONFIG_X86
>>>>>>      if (efi_enabled(EFI_RUNTIME_SERVICES))
>>>>>>          efi_enter_virtual_mode();
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[toc] | [prev] | [next] | [standalone]

#1719425 — Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

On Thursday, August 24, 2017 5:54:28 AM CEST Dou Liyang wrote:
> Hi Rafael, Zheng,
> 
> At 07/31/2017 06:50 PM, Dou Liyang wrote:
> > Hi,
> >
> > At 07/14/2017 01:52 PM, Dou Liyang wrote:
> >> Linux uses acpi_early_init() to put the ACPI table management into
> >> the late stage from the early stage where the mapped ACPI tables is
> >> temporary and should be unmapped.
> >>
> >> But, now initializing interrupt delivery mode should map and parse the
> >> DMAR table earlier in the early stage. This causes an ACPI error when
> >> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
> >> the DMAR table after using in the early stage.
> >>
> >> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
> >> be mapped and parsed in late stage like before.
> >>
> >> Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
> >> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
> >> Cc: linux-acpi@vger.kernel.org
> >> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> >> Cc: Zheng, Lv <lv.zheng@intel.com>
> >> Cc: Julian Wollrath <jwollrath@web.de>
> >> ---
> >> Test in my own PC(Lenovo M4340).
> >> Ask help for doing regression testing for the bug said in commit
> >> c4e1acbb35e4
> >> ("ACPI / init: Invoke early ACPI initialization later").
> >>
> >
> > Now, I can prove this patch doesn't result in the bug[1] which made the
> > fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
> > APU).
> >
> > The true reason of the bug is enabling ACPI subsystem earlier than
> > using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
> > could fix this bug as Julian tested and said[2].
> >
> > And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
> > platform to the ACPI mode later") split the ACPI early initialization
> > code into acpi_early_init() and acpi_subsystem_init(). executing
> > acpi_enable_subsystem() at the original early ACPI initialization spot.
> >
> > The sequence of them shows below:
> >
> >  start_kernel
> > +---------------+
> > |
> > +--> .......
> > |
> > |    late_time_init()
> > +--> +-------+
> > |
> > +--> .......
> > |
> > |    acpi_early_init()
> > +--> +-------+
> > |
> > +--> .......
> > |
> > |   acpi_subsystem_init()
> > +-> +--------+
> >
> > We make sure the acpi_subsystem_init() is called later than
> > late_time_init(), the bug will be avoided.
> >
> > This patch changes the sequence of late_time_init() and
> > acpi_early_init(), doesn't effect acpi_subsystem_init().
> >
> > So, this patch is OK.
> >
> > Btw, Thanks very much for Borislav Petkov, he will have access to
> > Thinkpad x121e from Mid-August and will test this series.
> >
> 
> Almost one month passed, Borislav have tested this series in Thinkpad
> x121e and I also have tested in my box and QEmu again. It is OK.
> 
> BTW,
> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
> platform to the ACPI mode later") split the ACPI early initialization
> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
> the ACPI subsystem is in acpi_subsystem_init().
> 
> 2) As we discussed earlier, invoking acpi_put_table() is not good for
> this situation.
> 
> So I do this patch, Is that goot to you? Any comments will be welcome.
> 
> If it is OK, As the patches need to be re-based, and I also found
> several spelling mistake, I will send a new version next week.

OK, but does it depend on anything?  Or does anything depend on it?

It is [12/13] in a series, so it looks like it doesn't depend on the
previous patches in it, but the next one may depend on it?  Which is the
case?

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1719714

Hi Rafael,

At 08/25/2017 12:38 AM, Rafael J. Wysocki wrote:
> On Thursday, August 24, 2017 5:54:28 AM CEST Dou Liyang wrote:
>> Hi Rafael, Zheng,
>>
>> At 07/31/2017 06:50 PM, Dou Liyang wrote:
>>> Hi,
>>>
>>> At 07/14/2017 01:52 PM, Dou Liyang wrote:
>>>> Linux uses acpi_early_init() to put the ACPI table management into
>>>> the late stage from the early stage where the mapped ACPI tables is
>>>> temporary and should be unmapped.
>>>>
>>>> But, now initializing interrupt delivery mode should map and parse the
>>>> DMAR table earlier in the early stage. This causes an ACPI error when
>>>> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
>>>> the DMAR table after using in the early stage.
>>>>
>>>> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
>>>> be mapped and parsed in late stage like before.
>>>>
>>>> Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
>>>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
>>>> Cc: linux-acpi@vger.kernel.org
>>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>>>> Cc: Zheng, Lv <lv.zheng@intel.com>
>>>> Cc: Julian Wollrath <jwollrath@web.de>
>>>> ---
>>>> Test in my own PC(Lenovo M4340).
>>>> Ask help for doing regression testing for the bug said in commit
>>>> c4e1acbb35e4
>>>> ("ACPI / init: Invoke early ACPI initialization later").
>>>>
>>>
>>> Now, I can prove this patch doesn't result in the bug[1] which made the
>>> fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
>>> APU).
>>>
>>> The true reason of the bug is enabling ACPI subsystem earlier than
>>> using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
>>> could fix this bug as Julian tested and said[2].
>>>
>>> And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
>>> platform to the ACPI mode later") split the ACPI early initialization
>>> code into acpi_early_init() and acpi_subsystem_init(). executing
>>> acpi_enable_subsystem() at the original early ACPI initialization spot.
>>>
>>> The sequence of them shows below:
>>>
>>>  start_kernel
>>> +---------------+
>>> |
>>> +--> .......
>>> |
>>> |    late_time_init()
>>> +--> +-------+
>>> |
>>> +--> .......
>>> |
>>> |    acpi_early_init()
>>> +--> +-------+
>>> |
>>> +--> .......
>>> |
>>> |   acpi_subsystem_init()
>>> +-> +--------+
>>>
>>> We make sure the acpi_subsystem_init() is called later than
>>> late_time_init(), the bug will be avoided.
>>>
>>> This patch changes the sequence of late_time_init() and
>>> acpi_early_init(), doesn't effect acpi_subsystem_init().
>>>
>>> So, this patch is OK.
>>>
>>> Btw, Thanks very much for Borislav Petkov, he will have access to
>>> Thinkpad x121e from Mid-August and will test this series.
>>>
>>
>> Almost one month passed, Borislav have tested this series in Thinkpad
>> x121e and I also have tested in my box and QEmu again. It is OK.
>>
>> BTW,
>> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
>> platform to the ACPI mode later") split the ACPI early initialization
>> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
>> the ACPI subsystem is in acpi_subsystem_init().
>>
>> 2) As we discussed earlier, invoking acpi_put_table() is not good for
>> this situation.
>>
>> So I do this patch, Is that goot to you? Any comments will be welcome.
>>
>> If it is OK, As the patches need to be re-based, and I also found
>> several spelling mistake, I will send a new version next week.
>
> OK, but does it depend on anything?  Or does anything depend on it?
>

It depends on nothing and can be considered independent.

[11/13] patch in this series depends on it. [11/13] patch caused an
ACPI error, we used this patch to fix it.

> It is [12/13] in a series, so it looks like it doesn't depend on the
> previous patches in it, but the next one may depend on it?  Which is the
> case?
>

The second case(the next one may depend on it) is what I want.

But, seems I made a mistake about the order of the patches. I should
put it before [11/13] to avoid the ACPI error.

I will adjust the order of the patches in the next version, and post
the whole series to you.

Thanks,
	dou.

[toc] | [prev] | [next] | [standalone]

#1720031 — Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

On Friday, August 25, 2017 4:06:11 AM CEST Dou Liyang wrote:
> Hi Rafael,
> 
> At 08/25/2017 12:38 AM, Rafael J. Wysocki wrote:
> > On Thursday, August 24, 2017 5:54:28 AM CEST Dou Liyang wrote:
> >> Hi Rafael, Zheng,
> >>
> >> At 07/31/2017 06:50 PM, Dou Liyang wrote:
> >>> Hi,
> >>>
> >>> At 07/14/2017 01:52 PM, Dou Liyang wrote:
> >>>> Linux uses acpi_early_init() to put the ACPI table management into
> >>>> the late stage from the early stage where the mapped ACPI tables is
> >>>> temporary and should be unmapped.
> >>>>
> >>>> But, now initializing interrupt delivery mode should map and parse the
> >>>> DMAR table earlier in the early stage. This causes an ACPI error when
> >>>> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
> >>>> the DMAR table after using in the early stage.
> >>>>
> >>>> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
> >>>> be mapped and parsed in late stage like before.
> >>>>
> >>>> Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
> >>>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
> >>>> Cc: linux-acpi@vger.kernel.org
> >>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> >>>> Cc: Zheng, Lv <lv.zheng@intel.com>
> >>>> Cc: Julian Wollrath <jwollrath@web.de>
> >>>> ---
> >>>> Test in my own PC(Lenovo M4340).
> >>>> Ask help for doing regression testing for the bug said in commit
> >>>> c4e1acbb35e4
> >>>> ("ACPI / init: Invoke early ACPI initialization later").
> >>>>
> >>>
> >>> Now, I can prove this patch doesn't result in the bug[1] which made the
> >>> fast TSC calibration using PIT failed in a Thinkpad x121e (AMD E-450
> >>> APU).
> >>>
> >>> The true reason of the bug is enabling ACPI subsystem earlier than
> >>> using PIT, not the SCI setup. invoking acpi_enable_subsystem() later
> >>> could fix this bug as Julian tested and said[2].
> >>>
> >>> And, I found that Commit b064a8fa77df (" ACPI / init: Switch over
> >>> platform to the ACPI mode later") split the ACPI early initialization
> >>> code into acpi_early_init() and acpi_subsystem_init(). executing
> >>> acpi_enable_subsystem() at the original early ACPI initialization spot.
> >>>
> >>> The sequence of them shows below:
> >>>
> >>>  start_kernel
> >>> +---------------+
> >>> |
> >>> +--> .......
> >>> |
> >>> |    late_time_init()
> >>> +--> +-------+
> >>> |
> >>> +--> .......
> >>> |
> >>> |    acpi_early_init()
> >>> +--> +-------+
> >>> |
> >>> +--> .......
> >>> |
> >>> |   acpi_subsystem_init()
> >>> +-> +--------+
> >>>
> >>> We make sure the acpi_subsystem_init() is called later than
> >>> late_time_init(), the bug will be avoided.
> >>>
> >>> This patch changes the sequence of late_time_init() and
> >>> acpi_early_init(), doesn't effect acpi_subsystem_init().
> >>>
> >>> So, this patch is OK.
> >>>
> >>> Btw, Thanks very much for Borislav Petkov, he will have access to
> >>> Thinkpad x121e from Mid-August and will test this series.
> >>>
> >>
> >> Almost one month passed, Borislav have tested this series in Thinkpad
> >> x121e and I also have tested in my box and QEmu again. It is OK.
> >>
> >> BTW,
> >> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
> >> platform to the ACPI mode later") split the ACPI early initialization
> >> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
> >> the ACPI subsystem is in acpi_subsystem_init().
> >>
> >> 2) As we discussed earlier, invoking acpi_put_table() is not good for
> >> this situation.
> >>
> >> So I do this patch, Is that goot to you? Any comments will be welcome.
> >>
> >> If it is OK, As the patches need to be re-based, and I also found
> >> several spelling mistake, I will send a new version next week.
> >
> > OK, but does it depend on anything?  Or does anything depend on it?
> >
> 
> It depends on nothing and can be considered independent.

OK

Please send it as an independent patch, then.

> [11/13] patch in this series depends on it. [11/13] patch caused an
> ACPI error, we used this patch to fix it.

So the ordering of patches in the series should be different, then.

It should be ordered so as to avoid triggering the warning at all,
so this patch should go before the [11/13].

> > It is [12/13] in a series, so it looks like it doesn't depend on the
> > previous patches in it, but the next one may depend on it?  Which is the
> > case?
> >
> 
> The second case(the next one may depend on it) is what I want.
> 
> But, seems I made a mistake about the order of the patches. I should
> put it before [11/13] to avoid the ACPI error.

Right.

> I will adjust the order of the patches in the next version, and post
> the whole series to you.

Please just CC it to linux-acpi.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1720094

Hi Rafael,

At 08/25/2017 08:27 PM, Rafael J. Wysocki wrote:
> On Friday, August 25, 2017 4:06:11 AM CEST Dou Liyang wrote:
[...]
>>>>
>>>> BTW,
>>>> 1) I found your commit b064a8fa77df (" ACPI / init: Switch over
>>>> platform to the ACPI mode later") split the ACPI early initialization
>>>> code into acpi_early_init() and acpi_subsystem_init(). Actually enabling
>>>> the ACPI subsystem is in acpi_subsystem_init().
>>>>
>>>> 2) As we discussed earlier, invoking acpi_put_table() is not good for
>>>> this situation.
>>>>
>>>> So I do this patch, Is that goot to you? Any comments will be welcome.
>>>>
>>>> If it is OK, As the patches need to be re-based, and I also found
>>>> several spelling mistake, I will send a new version next week.
>>>
>>> OK, but does it depend on anything?  Or does anything depend on it?
>>>
>>
>> It depends on nothing and can be considered independent.
>
> OK
>
> Please send it as an independent patch, then.
>
>> [11/13] patch in this series depends on it. [11/13] patch caused an
>> ACPI error, we used this patch to fix it.
>
> So the ordering of patches in the series should be different, then.
>
> It should be ordered so as to avoid triggering the warning at all,
> so this patch should go before the [11/13].

Yes, Indeed.

>
>>> It is [12/13] in a series, so it looks like it doesn't depend on the
>>> previous patches in it, but the next one may depend on it?  Which is the
>>> case?
>>>
>>
>> The second case(the next one may depend on it) is what I want.
>>
>> But, seems I made a mistake about the order of the patches. I should
>> put it before [11/13] to avoid the ACPI error.
>
> Right.
>
>> I will adjust the order of the patches in the next version, and post
>> the whole series to you.
>
> Please just CC it to linux-acpi.

Got it. Will just CC it to linux-acpi, and CC the whole series to you.

Thanks,
	dou.
>
> Thanks,
> Rafael
>
>
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web