Most recent kernel where this bug did *NOT* occur: NONE Distribution: archlinux (archlinux.org) Hardware Environment: Please view lspci and dmidecode-2.9 output. Also dmesg and lsmod outputs - classified by init level (all attachments without X working and nvidia driver not loaded) Software Environment: Init level 3 and 1 without X.org - please view attachments Problem Description: System goes into ram successfully by executing s2ram -f. I have also used the hibernate scripts and powersaved to suspend with identical results. It then resumes successfully (both init levels) with working caps lock key and full keyboard functionality since blindly typing "reboot" works. For both init levels, dmesg spits ACPI errors and exeptions on resume (see attachments). Suspend also works by simply executing "echo -n mem > /sys/power/state". The kernel command line in both cases is: root=/dev/hda3 resume=/dev/hda2 ro acpi_sleep=s3_mode silent agp=off vga=791 splash=silent quiet Without passing a "vga=X" line, system resumes without keyboard functionality and a hard reboot is required Steps to reproduce: Boot into either init levels, make sure nvidia binary module is unloaded then run s2ram -f or "echo -n mem > /sys/power/state". The above analysis has been done using the 2.6.19 kernel with the same results. Nvidia Binary Module Note (If this is superfluous and unnecessary - disregard): If I boot into init level 3 and start X which loads the binary nvidia module then go into suspend - I successfully resume with the following observations, 1) The hard drive led is on for about 30 sec after which the system seems to be dormant (no keyboard functionality), 2) After approx 4-5min, the system then resumes from suspend with fully functioning system and X working. I suspect the nvidia module could be doing some magic here. I hope this might help in deciding whether this is a kernel issue or nvidia issue. Please let me know if additional info is required regards
Created attachment 10763 [details] dmidecode output
Created attachment 10764 [details] lspci output
Created attachment 10765 [details] dmesg output in init level 1 before S3 suspend
Created attachment 10766 [details] dmesg output in init level 1 after S3 suspend
Created attachment 10767 [details] lsmod output in init level 1
Created attachment 10768 [details] dmesg output in init level 3 before S3 suspend
Created attachment 10769 [details] dmesg output in init level 3 after S3 suspend
Created attachment 10770 [details] lsmod output in init level 3
Created attachment 10771 [details] disassembled dsdt Disassembled dsdt using Intel's iasl - thought this would be helpful
Re: no video on resume from S3 It is a BIOS issue, or a video driver issue, not an ACPI issue. See workarounds in Documentation/power/video.txt and free to file a (different) bug against the video driver on it. But your dmesg after the resume _does_ show an ACPI issue: Back to C! ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1 ACPI: EC: read timeout, command = 128 ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_WAK] (Node dff6bdec), AE_TIME ACPI Exception (hwsleep-0577): AE_TIME, During Method _WAK [20070126] please attach the entire output from acpidump -- the disassembled DSDT may not be sufficient. Also, if you can you run the latest git tree -- there has actually been a key fix to the ec driver post -rc3
Created attachment 10776 [details] acpidump output acpidump output with latest git kernel (2.6.21-rc3 git revision 8ce5e3e)
Created attachment 10777 [details] dmesg output before S3 suspend dmesg output before S3 suspend (2.6.21-rc3 git revision 8ce5e3e)
Created attachment 10778 [details] dmesg output after S3 suspend dmesg output after S3 suspend (2.6.21-rc3 git revision 8ce5e3e)
Created attachment 10779 [details] lsmod output lsmod output (init level 3 - 2.6.21-rc3 git revision 8ce5e3e)
Created attachment 10781 [details] Enable runtime GPEs Please check if this patch removes AE_TIME exceptions. If not, please check if acpi interrupt count still increase in /proc/interrupts after resume.
Created attachment 10782 [details] dmesg output after S3 suspend with enable runtime gpes patch applied Similar acpi exception errors are observed in dmesg (init1) after suspend (compared to unpatched hwsleep.c). Regarding /proc/interrupts: output of cat /proc/interrupts | grep acpi Before Suspend: 9: 40 XT-PIC-XT acpi After Suspend: 9: 48 XT-PIC-XT acpi
hm, could you try to increase ACPI_EC_DELAY to 5000 in drivers/acpi/ec.c?
Increasing ACPI_EC_DELAY to 5000 in drivers/acpi/ec.c does nothing to the error and exceptions in dmesg after resuming from S3. However, the resume takes longer Additionally, output of cat /proc/interrupts | grep acpi Before Suspend: 9: 40 XT-PIC-XT acpi After Suspend: 9: 48 XT-PIC-XT acpi
Could you please check if interrupt counter change _after_ resume? e.g. do several samples of the counter while doing read of battery states/info
Can you explain how one would go about doing this? Would a simple 'cat /proc/acpi/battery/BAT0/state' do? Also, should I revert the patch you provided.
yes and no, respectively. Or if you removed patch already, it's ok too -- as it seem to have no effect.
(NB: done while running latest git kernel): The interrupt count increases while reading battery state after S3 resume - with a blank screen :) #cat /proc/interrupts | grep acpi 9: 58 XT-PIC-XT acpi (read bat. state) 9: 68 XT-PIC-XT acpi (read bat. state) 9: 78 XT-PIC-XT acpi (read bat. state) 9: 88 XT-PIC-XT acpi
It should be noted that the ACPI exceptions are still visible in dmesg
Thanks for tests. interrupt count increase means EC works. So, somehow it is disabled during _WAK evaluation, but later its available again.
Created attachment 10838 [details] Change order of pm_finish() and device_resume() Please check if this patch makes any difference.
I'm afraid that last patch did not resolve the issue - the exceptions and error are still visible in dmesg. Thanks
Is this still an issue in Linux-2.6.22.stable or later?
Please reopen this bug if it's still present with kernel 2.6.22.