Re: Bad libata resume behaviour due to ACPICA change (in acpi-test)

[Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>]

first thing to check is timing of acpi_hw_disable_all_gpes() at 
drivers/acpi/events/evgpe.c:647,
printk() around it should be good.


Henrique de Moraes Holschuh wrote:
> On Mon, 05 Feb 2007, Starikovskiy, Alexey Y wrote:
>   
>> I cannot reproduce your problem with T43 here on linux-acpi-test with
>> defconfig (relevant ACPI modules were tried both dynamic and static).
>> Resume time is about 4-6 seconds, not 20-40 as you mention.
>> Could you please send your .config and try defconfig on your machine?
>>     
>
> Sorry for the delay on doing the tests.  2.6.20+acpi-test defconfig does NOT
> do ACPI S3, so I had to use defconfig with SMP turned off (that was the only
> change).  Are you sure you tried linux-acpi-test in 2.6.20 defconfig without
> any changes?
>
> gcc is Debian 3.4.6-5.  I am avoiding 4.1.1 because of the reports of it
> miscompiling the kernel sometimes.
>
> The bug changed behaviour a little in defconfig.  Now, I get the "Restarting
> tasks ... done" right away after the line that used to hang (SCSI device
> sda: write cache...", and THEN it hangs for about 20s.
>
> In my default T43 kernel, I get "Restarting tasks ... done" *before* the
> (SCSI device sda: write cache..." line.
>
> So the hang is still there, it is still 100% reproducible here, but I am not
> sure it has much to do with libata.  It might have something to do with
> whatever happens after "Restarting tasks ... done", and libata resume just
> happens to be running in another thread at that time and outputs its stuff
> through printk.
>
> Any ideas on how to debug this further?
>
>