Bug 8199

Summary:	ACPI Error (psparse-0537): Method parse/execution failed [\_WAK] - sony vaio VGN-FS790 (PCG-7D2L)
Product:	ACPI	Reporter:	Dennis W (dwavomba)
Component:	Power-Sleep-Wake	Assignee:	Alexey Starikovskiy (astarikovskiy)
Status:	REJECTED INSUFFICIENT_DATA
Severity:	high	CC:	acpi-bugzilla, bunk
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.21-rc3	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	dmidecode output lspci output dmesg output in init level 1 before S3 suspend dmesg output in init level 1 after S3 suspend lsmod output in init level 1 dmesg output in init level 3 before S3 suspend dmesg output in init level 3 after S3 suspend lsmod output in init level 3 disassembled dsdt acpidump output dmesg output before S3 suspend dmesg output after S3 suspend lsmod output Enable runtime GPEs dmesg output after S3 suspend with enable runtime gpes patch applied Change order of pm_finish() and device_resume()

Description Dennis W 2007-03-14 19:50:29 UTC

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

Comment 1 Dennis W 2007-03-14 19:57:32 UTC

Created attachment 10763 [details]
dmidecode output

Comment 2 Dennis W 2007-03-14 19:57:59 UTC

Created attachment 10764 [details]
lspci output

Comment 3 Dennis W 2007-03-14 19:59:46 UTC

Created attachment 10765 [details]
dmesg output in init level 1 before S3 suspend

Comment 4 Dennis W 2007-03-14 20:00:26 UTC

Created attachment 10766 [details]
dmesg output in init level 1 after S3 suspend

Comment 5 Dennis W 2007-03-14 20:01:19 UTC

Created attachment 10767 [details]
lsmod output in init level 1

Comment 6 Dennis W 2007-03-14 20:02:33 UTC

Created attachment 10768 [details]
dmesg output in init level 3 before S3 suspend

Comment 7 Dennis W 2007-03-14 20:03:14 UTC

Created attachment 10769 [details]
dmesg output in init level 3 after S3 suspend

Comment 8 Dennis W 2007-03-14 20:03:53 UTC

Created attachment 10770 [details]
lsmod output in init level 3

Comment 9 Dennis W 2007-03-14 20:55:27 UTC

Created attachment 10771 [details]
disassembled dsdt

Disassembled dsdt using Intel's iasl - thought this would be helpful

Comment 10 Len Brown 2007-03-14 23:31:31 UTC

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

Comment 11 Dennis W 2007-03-15 09:11:14 UTC

Created attachment 10776 [details]
acpidump output

acpidump output with latest git kernel (2.6.21-rc3 git revision 8ce5e3e)

Comment 12 Dennis W 2007-03-15 09:12:55 UTC

Created attachment 10777 [details]
dmesg output before S3 suspend

dmesg output before S3 suspend (2.6.21-rc3 git revision 8ce5e3e)

Comment 13 Dennis W 2007-03-15 09:14:07 UTC

Created attachment 10778 [details]
dmesg output after S3 suspend

dmesg output after S3 suspend (2.6.21-rc3 git revision 8ce5e3e)

Comment 14 Dennis W 2007-03-15 09:15:12 UTC

Created attachment 10779 [details]
lsmod output

lsmod output (init level 3 - 2.6.21-rc3 git revision 8ce5e3e)

Comment 15 Alexey Starikovskiy 2007-03-15 10:19:44 UTC

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.

Comment 16 Dennis W 2007-03-15 12:20:20 UTC

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

Comment 17 Alexey Starikovskiy 2007-03-15 12:30:07 UTC

hm, could you try to increase ACPI_EC_DELAY to 5000 in drivers/acpi/ec.c?

Comment 18 Dennis W 2007-03-15 13:06:01 UTC

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

Comment 19 Alexey Starikovskiy 2007-03-15 22:43:26 UTC

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

Comment 20 Dennis W 2007-03-16 10:11:58 UTC

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.

Comment 21 Alexey Starikovskiy 2007-03-16 10:41:44 UTC

yes and no, respectively. Or if you removed patch already, it's ok too -- as it
seem to have no effect.

Comment 22 Dennis W 2007-03-17 09:56:06 UTC

(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

Comment 23 Dennis W 2007-03-17 09:57:20 UTC

It should be noted that the ACPI exceptions are still visible in dmesg

Comment 24 Alexey Starikovskiy 2007-03-17 10:00:54 UTC

Thanks for tests.
interrupt count increase means EC works. So, somehow it is disabled during 
_WAK evaluation, but later its available again.

Comment 25 Alexey Starikovskiy 2007-03-19 09:46:48 UTC

Created attachment 10838 [details]
Change order of pm_finish() and device_resume()

Please check if this patch makes any difference.

Comment 26 Dennis W 2007-03-20 18:07:14 UTC

I'm afraid that last patch did not resolve the issue - the exceptions and error
are still visible in dmesg. Thanks

Comment 27 Len Brown 2007-09-06 15:47:26 UTC

Is this still an issue in Linux-2.6.22.stable or later?

Comment 28 Adrian Bunk 2007-10-06 14:24:12 UTC

Please reopen this bug if it's still present with kernel 2.6.22.