Created attachment 116371 [details] acpidump1 Hello, I'm currently running Arch as single OS on My Sony Vaio S Series. The Resum on lid open was working correctly for 3/4 mounths. Probably after a bulk update the system does not handling the process anymore. The suspention is working properly (i'm using systemd but can work also with acpid). I also tried to revert all the updates but the issue stay. Adding dmidecode Adding DSTD table Adding a Sleep/resume snippet
Created attachment 116381 [details] dmidecode
Created attachment 116391 [details] suspend/resume
Created attachment 116401 [details] boot process adding boot process
1 Please attach the output of: # cat /proc/acpi/wakeup 2 When it worked, do you remember the kernel version?
Created attachment 117191 [details] attachment-4904-0.html Device S-state Status Sysfs node EHC1 S3 *enabled pci:0000:00:1d.0 EHC2 S3 *enabled pci:0000:00:1a.0 XHC S3 *enabled pci:0000:00:14.0 HDEF S0 *disabled pci:0000:00:1b.0 RP01 S0 *disabled pci:0000:00:1c.0 WLAN S0 *disabled pci:0000:02:00.0 RP02 S0 *disabled pci:0000:00:1c.1 RMSC S0 *disabled pci:0000:03:00.0 RP03 S4 *disabled pci:0000:00:1c.2 RLAN S4 *disabled pci:0000:04:00.0 PEG0 S0 *disabled pci:0000:00:01.0 PEGP S0 *disabled pci:0000:01:00.0 When it worked my kernel was 3.11.2-1 moved to -> 3.11.6-1; i also tried downgrade it but i never get back the functionality. Now i'm on 3.12.1-1-ARCH. Unfortunately i can't remember if LID0 was listed in wakeup list. 2013/12/2 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=65931 > > Aaron Lu <aaron.lu@intel.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|NEW |NEEDINFO > CC| |aaron.lu@intel.com > > --- Comment #4 from Aaron Lu <aaron.lu@intel.com> --- > 1 Please attach the output of: > # cat /proc/acpi/wakeup > > 2 When it worked, do you remember the kernel version? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
If kernel 3.11.2-1 previously worked but not now, I suppose it's not a kernel problem? Perhaps some other system configuration related issue?
Thanks Aeron for the replay, I actually double checked and downgraded all the packages installed on that infamous update.. also checked the new default config files generated by some packages. I led to Kernel because i got also a changes in the battery charging limit default from 80% to 100%. i researched a bit and find out was handled by sony_laptop module.. i talked to the maintainer and he said the lid was not managed my the module but was indeed strange that the default was changed while no changes happened in the module since a while. Now i have another default for battery % chanrging limit and i can't override it if just echoing on startup. This behaviour let me think is something related to ACPI, and possibly some thing changed the variables in the BIOS {efi variables?} i'm very poor man in this field so maybe i'm saying nothing right.
Can you please test some older version kernels to see if there is one that works well for the LID open resume functionality?
Any update on the test?
Created attachment 119201 [details] attachment-10939-0.html I'm sorry Aaron, I got tons of work in these weeks. I'll update the ticket as soon as i'll have couple of hours to install and try some kernels. I'll keep you updateed, José 2013/12/19 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=65931 > > --- Comment #9 from Aaron Lu <aaron.lu@intel.com> --- > Any update on the test? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Any update?
Hello Aaeron, Sorry for late reply, I've actually tested 3.8.8-2-ARCH (well before my first installation on this laptop) and my first kernel: 3.10.10-1. I've also tried a Live Ubuntu 3.8.0-35.50~precise1 without success. This fall in UEFI problems and the changes has been probably applied by one of the package upgraded that silently changes configuration in UEFI but there's no evidence that the package that made the changes was the Kernel. As stated above, not only the "RESUME On LID open" was affected but also parts controlled by sony-laptop module that are closely related to UEFI stuff.
Let me try to summarize: On 3.11.2-1, everything works well; Upgrade to 3.11.6-1, resume doesn't work on LID open and battery doesn't show correctly. Downgrade to 3.11.2-1, resume still doesn't work and what about the battery status? Does it work well now?
I figured out the battery behaviour is related to an unwanted changes in the default charging limit that can be set via UEFI calls. I figured it out with the help of sony_laptop module maintainer that show me where the conf is located and how to adjust it (i can choose to stop charge at 70,80 or 100% of real battery). This doesnt solve the fact the default has been overwritten and i have to set the charing limit on sturtup. I think the LID behaviour can be related to these changes and that's why i think the upgrade changed something at UEFI level.
Then I'll move it to EFI category to see if they could help.
What "UEFI calls" change the charging limit? I'm not at all sure why UEFI would be involved in this.
Created attachment 129011 [details] attachment-29552-0.html In sysfs I cna actually change the behaviour echoing here: j0lly@j0llyb0x:/sys/devices/platform/sony-laptop$ cat battery_care_health 100 but the default was 80 before an untracked update. I suspect something was changed here: j0lly@j0llyb0x:/sys/firmware/efi/efivars$ ll totale 0 drwxr-xr-x 2 root root 0 mar 11 20:16 ./ drwxr-xr-x 4 root root 0 mar 11 20:16 ../ -rw-r--r-- 1 root root 12 mar 11 20:16 AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a -rw-r--r-- 1 root root 26 mar 11 20:16 ActiveVgaDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 5 mar 11 20:16 AuthVarKeyDatabase-515fa686-b06e-4550-9112-382bf1067bfb -rw-r--r-- 1 root root 10 mar 11 20:16 BackupPlatformLang-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 124 mar 11 20:16 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 160 mar 11 20:16 Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 6 mar 11 20:16 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 8 mar 11 20:16 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 6 mar 11 20:16 BootPrevious-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 130 mar 11 20:16 BootPreviousData-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 72 mar 11 20:16 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 72 mar 11 20:16 ConInCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 38 mar 11 20:16 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 34 mar 11 20:16 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 34 mar 11 20:16 ConOutCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 34 mar 11 20:16 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 904 mar 11 20:16 Custom-a04a27f4-df00-4d42-b552-39511302113d -rw-r--r-- 1 root root 5 mar 11 20:16 CustomSecurity-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 3147 mar 11 20:16 db-d719b2cb-3d3a-4596-a3bc-dad00e67656f -rw-r--r-- 1 root root 80 mar 11 20:16 dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f -rw-r--r-- 1 root root 28 mar 11 20:16 DDR3LVoltageVariable-ef5f1f9f-735e-4671-b68b-4c80cf011328 -rw-r--r-- 1 root root 34 mar 11 20:16 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 111 mar 11 20:16 iFfsData-f9f0b131-f346-4f16-80dd-f941072b3a7d -rw-r--r-- 1 root root 20 mar 11 20:16 IrsiInfo-5bce4c83-6a97-444b-63b4-672c014742ff -rw-r--r-- 1 root root 1564 mar 11 20:16 KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 7 mar 11 20:16 Lang-49484d23-5647-4a86-8c25-b0cbc2e65ceb -rw-r--r-- 1 root root 30 mar 11 20:16 MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70 -rw-r--r-- 1 root root 5 mar 11 20:16 MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829 -rw-r--r-- 1 root root 3052 mar 11 20:16 MrcS3RestoreVariable-14ef381c-9721-434e-be09-192ab97e781f -rw-r--r-- 1 root root 8 mar 11 20:16 MTC-eb704011-1402-11d3-8e77-00a0c969723b -rw-r--r-- 1 root root 12 mar 11 20:16 OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 12 mar 11 20:16 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 8 mar 11 20:16 PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb -rw-r--r-- 1 root root 20 mar 11 20:16 PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb -rw-r--r-- 1 root root 6 mar 11 20:16 PhysicalBootOrder-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 10 mar 11 20:16 PhysicalPresenceInterfaceControl-e46909c4-6702-474d-9bd1-6d9fbc4b0190 -rw-r--r-- 1 root root 1303 mar 11 20:16 PK-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 5 mar 11 20:16 PlatformConfigurationVariable-f2f2d9a4-2a67-0361-b349-ada7e588f971 -rw-r--r-- 1 root root 10 mar 11 20:16 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 10 mar 11 20:16 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 6 mar 11 20:16 PowerOnPassword-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 5 mar 11 20:16 RestoreFactoryDefault-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 12 mar 11 20:16 S3RestoreDataVariable-14ef381c-9721-434e-be09-192ab97e781f -rw-r--r-- 1 root root 28 mar 11 20:16 SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e -rw-r--r-- 1 root root 5 mar 11 20:16 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 5 mar 11 20:16 SecureBootEnforce-59d1c24f-50f1-401a-b101-f33e0daed443 -rw-r--r-- 1 root root 17 mar 11 20:16 SecureFlashInfo-382af2bb-ffff-abcd-aaee-cce099338877 -rw-r--r-- 1 root root 904 mar 11 20:16 Setup-a04a27f4-df00-4d42-b552-39511302113d -rw-r--r-- 1 root root 5 mar 11 20:16 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 36 mar 11 20:16 SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 162 mar 11 20:16 SmbiosPolicy-41a3ee4e-6d57-418b-8f8e-c366a5b70c4b -rw-r--r-- 1 root root 1044 mar 11 20:16 SpdData-70a9c11d-f710-42f8-89c1-bde841dc9b45 -rw-r--r-- 1 root root 6 mar 11 20:16 SRID-d0d5da82-9dd7-4d63-9a94-fdfa8255c2bd -rw-r--r-- 1 root root 6 mar 11 20:16 SwitchableGraphicsVariable-b2b7c21f-1786-4a64-be69-16cef7647331 -rw-r--r-- 1 root root 6 mar 11 20:16 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 61 mar 11 20:16 VBiosInfo-bbd1fd65-5668-4fb2-8999-231095717a07 I'm very noobish about UEFI; i don't know how to manipulate this entry, but i really suspect one of the above outlined is related to the change. Thanks for the feedback, José Il 11/03/2014 21:39, bugzilla-daemon@bugzilla.kernel.org ha scritto: > https://bugzilla.kernel.org/show_bug.cgi?id=65931 > > Matt Fleming <matt@console-pimps.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |matt@console-pimps.org > > --- Comment #16 from Matt Fleming <matt@console-pimps.org> --- > What "UEFI calls" change the charging limit? > > I'm not at all sure why UEFI would be involved in this. >
I'm also experiencing this with an ASUS laptop: $ uname -r 3.13.0-24-generic $ dmesg | grep -i lid [ 1.007819] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0 [ 1.009189] ACPI: Lid Switch [LID] $ cat /proc/acpi/wakeup Device S-state Status Sysfs node PEG4 S4 *disabled PEG5 S4 *disabled PEG6 S4 *disabled P0P1 S4 *disabled pci:0000:00:1e.0 EHC1 S3 *enabled pci:0000:00:1d.0 USB1 S3 *disabled USB2 S3 *disabled USB3 S3 *disabled USB4 S3 *disabled EHC2 S3 *enabled pci:0000:00:1a.0 USB5 S3 *disabled USB6 S3 *disabled USB7 S3 *disabled HDEF S4 *disabled pci:0000:00:1b.0 RP01 S4 *disabled pci:0000:00:1c.0 RP02 S4 *disabled pci:0000:00:1c.1 WLAN S3 *disabled pci:0000:02:00.0 RP04 S4 *disabled RP05 S4 *disabled RP06 S4 *disabled pci:0000:00:1c.5 GLAN S4 *enabled pci:0000:04:00.5 RP07 S4 *disabled RP08 S4 *disabled GLAN S4 *disabled RP03 S4 *disabled pci:0000:00:1c.2 SLPB S4 *enabled
I am experiencing exactly the same problem using legacy boot. Does that confirm that this is not strictly UEFI related? $ uname -r 3.14.7-1-ck $ dmesg |grep -i LID [ 1.528482] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input3 [ 1.534095] ACPI: Lid Switch [LID0] $ cat /proc/acpi/wakeup Device S-state Status Sysfs node RP05 S4 *disabled pci:0000:00:1c.4 PXSX S4 *disabled pci:0000:03:00.0 RP01 S4 *disabled pci:0000:00:1c.0 PXSX S4 *disabled pci:0000:01:00.0 RP03 S4 *disabled PXSX S4 *disabled RP04 S4 *disabled pci:0000:00:1c.3 PXSX S4 *disabled pci:0000:02:00.0 RP06 S4 *disabled PXSX S4 *disabled EHC1 S3 *enabled pci:0000:00:1d.0 XHC S3 *enabled pci:0000:00:14.0 HDEF S4 *disabled pci:0000:00:1b.0 PWRB S4 *enabled
Murat, yes, I'd be very surprised if this was in any way related to UEFI. Let's move this over to ACPI and see whether the ACPI folks have any ideas.
(In reply to j0lly from comment #0) > Created attachment 116371 [details] > acpidump1 > > Hello, > > I'm currently running Arch as single OS on My Sony Vaio S Series. > The Resum on lid open was working correctly for 3/4 mounths. > Probably after a bulk update the system does not handling the process > anymore. > The suspention is working properly (i'm using systemd but can work also with > acpid). > do you mean that the system suspends when closing the lid, but does not resume when opening the lid? if you press the power button manually after opening the lid, can the system resumes back?
Hi, I only checked DSDT. The decoded _PRWs tell us: EHC1 (GPE0D S3) EHC2 (GPE0D S3) XHC_ (GPE0D S3) HDEF WKMD=1(GPE0D S0) WKMD=0(GPE0D S0) WLAN (GPE09 S0) RP01 PMEE=1(GPE09 S0) PMEE=0(GPE09 S0) RMSC (GPE09 S0) RP02 PMEE=1(GPE09 S0) PMEE=0(GPE09 S0) RLAN (GPE09 S4) RP03 PMEE=1(GPE09 S4) PMEE=0(GPE09 S0) PEG0 (GPE09 S0) PEGP (GPE09 S0) So it looks like you should be woken up from S3 by receiving GPE 0x0D... And in _L0D, it notifies the following devices: Method (_L0D, 0, NotSerialized) // _Lxx: Level-Triggered GPE { Notify (\_SB.PCI0.XHC, 0x02) Notify (\_SB.PCI0.EHC1, 0x02) Notify (\_SB.PCI0.EHC2, 0x02) Notify (\_SB.PCI0.HDEF, 0x02) } It seems only the following devices have something to do with S3 wakeup GPE: EHC1, EHC2, XHC, HDEF I don't know what the HDEF is. Maybe you can: "echo HDEF > /proc/acpi/wakeup" and try again. It looks like there is also a BIOS configuration item related to HDEF wake capability: Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake { If (WKMD) { Return (Package (0x02) { 0x0D, Zero }) } Else { Return (Package (0x02) { 0x0D, Zero }) } } Maybe your old behavior also relates to a BIOS configuration.
please provide the information in comment #21.
Hello, Sorry for my delay, I'm sorry to let you know that I broke my laptop and don't sony redounded me instead of repair because missing parts... I'm not able to reproduce nor test the behavior.. It still a valuable information and hope someone with the same issue will keep follow the bug. thanks again, j
Okay. Bug closed as we're not able to reproduce the problem currently. Please feel free to re-open or comment on this bug if somebody else gets the same problem.
I have this exact bug in a SVP132A1CL. This is a Sony Vaio Pro, a descendant of the S series, I believe. I was watching this bug with hope to see it resolved. My laptop used to be able to wake up on lid open, but now I have to push the power button to wake it up. I'd be happy to provide any details if you tell me what you need. I run Arch Linux as my only OS. I am pretty sure there is an option to enable/disable this behaviour on the windows software but it is inaccessible from bios menu and afaik linux. I don't have Windows installed but I can clone my disk and install windows just for this purpose if we are that desperate and you can give me a strict protocol to follow (to reverse-engineer acpi flags etc.) I otherwise have no experience with kernel programming. Thanks.