Henrique, Please also try to set acpi_gbl_system_awake_and_running to true in the same place, if you find that disable_all_gpes() is called not once... Thanks, Alex. >-----Original Message----- >From: Alexey Starikovskiy [mailto:alexey.y.starikovskiy@xxxxxxxxxxxxxxx] >Sent: Thursday, February 08, 2007 8:51 PM >To: Henrique de Moraes Holschuh >Cc: Starikovskiy, Alexey Y; linux-acpi@xxxxxxxxxxxxxxx; Brown, Len >Subject: Re: Bad libata resume behaviour due to ACPICA change (in acpi- >test) > >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? >> >> - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
