From: Li, S. <sha...@in...> - 2005-03-08 06:58:21
|
>> >> Perhaps you should fix that, too? It is going to cause ugly >> perfrmance problems. > >Yep, been looking into it, and I think I've got it. The GPE in >question is fired periodically, about every 5 seconds. It fires when >suspending but kacpid is stopped, so the GPE is simply disabled and >never serviced. However, the state of it being disabled is recorded >in the atomic copy. > >Upon resume, after restoring the atomic copy, the code at the top of >acpi_ev_disable_gpe believes that the GPE is already disabled (as it >was when we suspended) even though it's not. Hardware state is out >of sync with what the kernel thinks and badness ensues. The culprit >difference between 2.6.8 and 2.6.9-rc1 is that 2.6.8 disabled the >GPE unconditionally, 2.6.9-rc1 checks against its last known state >which is incorrect upon resuming. > >Removing the check resolves this issue (patch attached). Is this an >adequate fix? Great analyzing! I guess Both S3, swsusp, and swsusp2 can't suffer from this bug. Sure this patch hasn't any side effect. But I wonder if it's the right fix. Maybe we should disable all GPEs which have been disabled on very early of resume (that is to restore ACPI hardware's state). This is very useful for suspend-to-disk. If you found a similar bug in S3, it possibly it's BIOS bug (OS didn't enable GPE on resume for S3, but for S4, we follow boot time code path, so we possibly enabled some). Thanks, Shaohua |