A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

[Dou Liyang]

Hi, Rafael

Recently, I worked for unify the interrupt delivery mode and do its 
setup earlier[1]. And I met a bug about ACPI[2].

When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init:
Run acpi_early_init() before timekeeping_init()).  And I reproduced the
problem you said.

Question:
--------

In the changelog of commit:

 > Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
 > timekeeping_init()) optimistically moved the early ACPI initialization
 > before timekeeping_init(), but that didn't work, because it broke fast
 > TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely

Here, does the fast TSC calibration means *quick_pit_calibrate()* ?

 > for others too).  The reason is that acpi_early_init() enables the SCI
 > and that interferes with the fast TSC calibration mechanism.

I reproduced it by the following command line:
     ...noapic acpi_sci=level...

the original dmesg is:

[    0.000000] tsc: Fast TSC calibration using PIT

the broken dmesg is:

[    0.001000] tsc: PIT calibration matches HPET. 1 loops

Is it right? If it is wrong, please give the right process for
reproducing.

 >
 > Thus follow the original idea to execute acpi_early_init() before
 > efi_enter_virtual_mode() to help the EFI people for now and we can
 > revisit the other problem that commit 73f7d1ca3263 attempted to
 > address in the future (if really necessary).

If the result which I reproduced was right, I think we can do what
the commit 73f7d1ca3263 attempted to do now. And it also can fix the
bug[2].

Because my patchset[1] will setup the interrupt delivery mode earlier
than TSC initialization. So, in Fast TSC calibration, kernel is in its
final interrupt mode, not just PIC mode. The change of trigger type
will never break the Fast TSC calibration(I have tested in my box).


[1] https://lkml.org/lkml/2017/6/30/17
[2] https://lists.gt.net/xen/devel/483350


Thanks,

	dou.

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

[Dou Liyang]

At 07/11/2017 09:26 PM, Dou Liyang wrote:
> Hi, Rafael
>
> Recently, I worked for unify the interrupt delivery mode and do its
> setup earlier[1]. And I met a bug about ACPI[2].
>
> When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init:
> Run acpi_early_init() before timekeeping_init()).  And I reproduced the

Oops, Make a mistake,

your commit c4e1acbb35e4 (ACPI / init: Invoke early ACPI initialization 
later)

Thanks,

	dou
> problem you said.
>
> Question:
> --------
>
> In the changelog of commit:
>
>> Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
>> timekeeping_init()) optimistically moved the early ACPI initialization
>> before timekeeping_init(), but that didn't work, because it broke fast
>> TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
>
> Here, does the fast TSC calibration means *quick_pit_calibrate()* ?
>
>> for others too).  The reason is that acpi_early_init() enables the SCI
>> and that interferes with the fast TSC calibration mechanism.
>
> I reproduced it by the following command line:
>     ...noapic acpi_sci=level...
>
> the original dmesg is:
>
> [    0.000000] tsc: Fast TSC calibration using PIT
>
> the broken dmesg is:
>
> [    0.001000] tsc: PIT calibration matches HPET. 1 loops
>
> Is it right? If it is wrong, please give the right process for
> reproducing.
>
>>
>> Thus follow the original idea to execute acpi_early_init() before
>> efi_enter_virtual_mode() to help the EFI people for now and we can
>> revisit the other problem that commit 73f7d1ca3263 attempted to
>> address in the future (if really necessary).
>
> If the result which I reproduced was right, I think we can do what
> the commit 73f7d1ca3263 attempted to do now. And it also can fix the
> bug[2].
>
> Because my patchset[1] will setup the interrupt delivery mode earlier
> than TSC initialization. So, in Fast TSC calibration, kernel is in its
> final interrupt mode, not just PIC mode. The change of trigger type
> will never break the Fast TSC calibration(I have tested in my box).
>
>
> [1] https://lkml.org/lkml/2017/6/30/17
> [2] https://lists.gt.net/xen/devel/483350
>
>
> Thanks,
>
>     dou.
>

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

[Dou Liyang]

Hi, Rafael

At 07/11/2017 09:26 PM, Dou Liyang wrote:
> Hi, Rafael
>
> Recently, I worked for unify the interrupt delivery mode and do its
> setup earlier[1]. And I met a bug about ACPI[2].
>
> When I investigated it, I got your *commit c4e1acbb35e4 (ACPI / init:
> Invoke early ACPI initialization later).*  And I reproduced the
> problem you said.
>
> Question:
> --------
>
> In the changelog of commit c4e1acbb35e4:
>
>> Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
>> timekeeping_init()) optimistically moved the early ACPI initialization
>> before timekeeping_init(), but that didn't work, because it broke fast
>> TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
>

Sorry to trouble you again, I forgot cc Julian who reported it. :)

Add Cc: Julian Wollrath.

Thanks,

	dou.

> Here, does the fast TSC calibration means *quick_pit_calibrate()* ?
>
>> for others too).  The reason is that acpi_early_init() enables the SCI
>> and that interferes with the fast TSC calibration mechanism.
>
> I reproduced it by the following command line:
>     ...noapic acpi_sci=level...
>
> the original dmesg is:
>
> [    0.000000] tsc: Fast TSC calibration using PIT
>
> the broken dmesg is:
>
> [    0.001000] tsc: PIT calibration matches HPET. 1 loops
>
> Is it right? If it is wrong, please give the right process for
> reproducing.
>
>>
>> Thus follow the original idea to execute acpi_early_init() before
>> efi_enter_virtual_mode() to help the EFI people for now and we can
>> revisit the other problem that commit 73f7d1ca3263 attempted to
>> address in the future (if really necessary).
>
> If the result which I reproduced was right, I think we can do what
> the commit 73f7d1ca3263 attempted to do now. And it also can fix the
> bug[2].
>
> Because my patchset[1] will setup the interrupt delivery mode earlier
> than TSC initialization. So, in Fast TSC calibration, kernel is in its
> final interrupt mode, not just PIC mode. The change of trigger type
> will never break the Fast TSC calibration(I have tested in my box).
>
>
> [1] https://lkml.org/lkml/2017/6/30/17
> [2] https://lists.gt.net/xen/devel/483350
>
>
> Thanks,
>
>     dou.
>

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

[Julian Wollrath]

Hi,

> > I reproduced it by the following command line:
> >     ...noapic acpi_sci=level...
> >
> > the original dmesg is:
> >
> > [    0.000000] tsc: Fast TSC calibration using PIT
> >
> > the broken dmesg is:
> >
> > [    0.001000] tsc: PIT calibration matches HPET. 1 loops
> >
> > Is it right? If it is wrong, please give the right process for
> > reproducing.
yes, this is right, see [1] for the original thread.

The earliest I could move the call of acpi_early_init() without
triggering the bug back than is shown in the patch at [2] but
unforunately I do not have access to the Thinkpad X121e I had back than
anymore, so I cannot help with regression testing.

Cheers,
Julian

[1] https://lkml.org/lkml/2014/3/10/123
[2] https://lkml.org/lkml/2014/3/11/424

-- 
 ()  ascii ribbon campaign - against html e-mail 
 /\                        - against proprietary attachments

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

[Dou Liyang]

Hi, Julian

At 07/14/2017 11:01 PM, Julian Wollrath wrote:
> Hi,
>
>>> I reproduced it by the following command line:
>>>     ...noapic acpi_sci=level...
>>>
>>> the original dmesg is:
>>>
>>> [    0.000000] tsc: Fast TSC calibration using PIT
>>>
>>> the broken dmesg is:
>>>
>>> [    0.001000] tsc: PIT calibration matches HPET. 1 loops
>>>
>>> Is it right? If it is wrong, please give the right process for
>>> reproducing.
> yes, this is right, see [1] for the original thread.
>

  Got it.

> The earliest I could move the call of acpi_early_init() without
> triggering the bug back than is shown in the patch at [2] but
> unforunately I do not have access to the Thinkpad X121e I had back than
> anymore, so I cannot help with regression testing.
>
> Cheers,
> Julian
>
> [1] https://lkml.org/lkml/2014/3/10/123
> [2] https://lkml.org/lkml/2014/3/11/424
>

These two links is really helpful for me.

Thanks,

	dou.