Bug 11491
Description
Hannes Diethelm
2008-09-03 11:28:56 UTC
The dmesg output is after two suspend/resume cycles. I tryed nearly every kernel version and every hack... Also after two or three suspend-resume cycles the system is acting realy slow, and while shuting down, I need to press keys or nothing happens while shuting down all processes. Created attachment 17675 [details]
Patch 1/4 : Don't issue the burst disable command if EC exits the burst mode
Created attachment 17676 [details]
Patch 2/4: Clear the query_pending bit only after processing EC notification event
Created attachment 17677 [details]
Patch 3/4: Simplify EC working flowchart and always enable EC GPE
Created attachment 17678 [details]
patch 4/4: Add some udelay in EC GPE handler to avoid EC GPE interrupt storm
Hi, Hannes From the dmesg it seems that there exists the following info in course of resuming. >[ 919.086617] ACPI: EC: non-query interrupt received, switching to interrupt mode > [ 927.155731] ACPI: EC: acpi_ec_wait timeout, status = 0x09, event = "b0=1" > [ 927.155736] ACPI: EC: read timeout, command = 130 Maybe it is related with EC driver. Will you please try the attached four patches on the latest kernel(2.6.27-rc5) and see whether the resume is still very slow? After the test, please attach the output of dmesg, acpidump. Thanks. Created attachment 17777 [details]
dmesg output of patched kernel after one suspend/resume
Created attachment 17778 [details]
acpidump of patched kernel before suspend/resume
Thanks! It's working great now! :D Suspend/resume takes now abaut 1-2 seconds. When will this patch be in the stable kernel? If you need other help, no problem. Created attachment 17779 [details]
Quick and dirty backport to 2.6.26 of these four patches
I made a backport to 2.6.26 of these four patches beacuse I got some other problemes with the rc-kernel. May be someone can use it. Hi, Hannes Thanks for the test. And it is very lucky that your system can work well after applying the patches.Now another people also works on this issue and my patches are not accepted by him. Of course I am discussing this issue with him. If reaching an agreement about this issue, will you please try the updated patch on your laptop? thanks. Created attachment 17824 [details]
Patch 3/4: Switch to polling mode when there is no EC GPE interrupt for some EC transactions
Created attachment 17825 [details]
patch 4/4: Add some delay in EC GPE handler to avoid EC GPE storm
Hi, Hannes Will you please try the updated patches again and see whether the resume is still normal? Of course the patches in comment #2,#3 is still required. thanks again. Created attachment 17836 [details]
dmesg output of patched kernel after one suspend/resume new patchset / 2.6.27-rc6
Hi Ykzhao I tryed the new patches but they are not working for me. The symptoms are the same. Slow resume and also after resume some keystrokes are lost and some processes are realy slow and can be speed up by typing on the keyboard. Hi, Hannes Will you please try the patches on the 2.6.27-rc5 kernel and see whether the resume is still slow? Will you please double check the test result in comment #9? thanks. Hi! I made some tests... It's strange that also patchset 1 is not working with a different configuration then mine. May be i also forgot to mention how my laptop behaves on resuning: If i press the start button then the hardware starts and the harddrive light lights up. After abaut 30s it goes off. After this, nothing more happens and the screen stays black. Also the caps-lock is not reacting at all. 2.6.26-1-686 no patch not resuming at all / hdlight / no capslock default debian kernel 2.6.26-laptop patchset 1 not resuming at all / hdlight / no capslock default debian kernel with small changes 2.6.26.3-bootsplash patchset 1 fast, 1-2s my own kernel 2.6.27-rc5-debconf-1 patchset 1 not resuming at all / hdlight / no capslock debian config / all new default 2.6.27-rc5-debconf-1-1000hz patchset 1 not resuming at all / hdlight / no capslock debian config / all new default / 1000hz 2.6.27-rc5-test1 patchset 1 fast , 1-2s my own kernel config / all new default 2.6.27-rc5-test2 patchset 2 resuing slow or not at all / hdlight / no capslock my own kernel config / all new default Is there some posibility to debug this problem myself? I was thinking abaut kgdb but it's not working for me because i dont's have a rs232. I'm quite experienced in c programming, but i don't have the time to get into the kernel acpi code and it's also a bit over my level. But if i can help you to find where the kernel hangs while resuming, i'll do. But I need some instructions how to do so. Created attachment 17878 [details]
All configs and dmesg output of tested kernels
Hi, Hannes Does the patch set 1 mean that the patch in comment #2,3,4,5 is used? I have no idea why the test result is different after the patch set 2 is used on the 2.6.27-rc5 kernel. From the test log we can know that the following message doesn't appear again regardless the patch set 1 or 2 is applied. > ACPI: EC: non-query interrupt received, switching to interrupt mode > ACPI: EC: acpi_ec_wait timeout, status = 0x09, event ="b0=1" > ACPI: EC: read timeout, command = 130 But from the log in 2.6.27-rc5-test2 we can see the following message which looks so confusing. >[ 131.043453] Back to C! > 300.068785] Force enabled HPET at resume > [ 131.045091] ACPI: Waking up from system sleep state S3 > [ 158.182237] pcieport-driver 0000:00:01.0: restoring config space at offset 0xf (was 0x100, writing 0xc010a) Will you please try the boot option of "hpet=disable idle=poll" when the patch set 2 is used? thanks. Hi! Yes, patchset 1 means patches from comments 2 to 5 and patchset 2 the patches from comments 2,3,13,14. I've tested the boot option "hpet=disable idle=poll" and now also patchset 2 is working! Created attachment 17970 [details]
2.6.27-rc5 patchset 2 cmdline: hpet=disable idle=poll
Hi, Hannes Thanks for the test. Now it seems clear that the issue is not related with the EC driver. Maybe it is caused by the hpet or C-state. But we had better confirm the root cause. Will you please try the following boot options and see whether the problem still exists? Of course the patch set 2 is still used.(The boot option should be used independently.) a. idle=poll b. processor.max_cstate=1 c. hpet=disable thanks. Ok, i've tested this boot options: idle=poll working processor.max_cstate=1 working hpet=disable not working Hi,Hannes Thanks for the test. Now it is confirmed that this issue is related with C-states. Will you please do the following test?(Please don't add any boot option mentioned in comment #24). a. suspend to RAM b. press the power button to wake up the system. wait for about 20 seconds and press the power button again. c. after the system returns, please attach the output of dmesg. thanks. Hi! Ok, I did this. After 20s I pressed the power button. But nothing happened. So after quite some time, i started to press random keys on the keyboard ( but only the keyboard ) so the system resumed. Whats the meaning of pressing the power button again? (All tests with the new patchset and 2.6.27-rc5) Created attachment 18053 [details] Dmesg output of test described in comment #26 Hi, Hannes Sorry that I don't describe it very clearly. What I expected is that you wait for 20 seconds and press the power button again(of course pressing keyboard is also OK) after pressing the power button to resume the system. Will you please do it again? Thanks again. Hmm.... I don't know what you mean. In the previous test i did this: 1. Suspend to ram 2. press power button to resume 3. wait 20s 4. press power button again 5. wait some time (~1-2min) 6. press a lot of keys (~100-200 keystrokes) 7. system is up If you d'like I could press a key every 2 secons so you can see where the system is hanging. Hi, Hannes What you have done is very right. From the log in comment #28 it seems that it will take so long time to resume. So I think that maybe you misunderstand what I have said. In fact what you have done is correct. thanks. Is there something going on abaut this bug? Hi, Hannes Now the updated EC patch is available. Will you please try the patch in http://bugzilla.kernel.org/show_bug.cgi?id=10724#C142 and see whether the problem still exists? If the problem still exists, please add the following boot options and try it again. a. idle=poll b. nolapic_itmer c. processor.max_cstate=1 Thanks. Hi! I tested the patch from http://bugzilla.kernel.org/show_bug.cgi?id=10724#C142 and it seams to work! Thanks! Created attachment 18373 [details] Dmesg output 2.6.27-rc7 with patch from http://bugzilla.kernel.org/show_bug.cgi?id=10724#C142 thanks for the test. As the system can work well after applying the patch, the bug will be marked as resovled. Thanks. patch above shipped in linux-2.6.28-rc1 closed |