I have a Sony Vaio Fit 14" (core i3, intel hd 4000). Since I got it in August, I've been having this issue. If the laptop has been powered on connected to the power supply, it suspends and resumes correctly. However, once I disconnect it from the line, if I suspend it, it resumes immediately. Even if I connect it to the power again, the problem persists until I reboot. I think I found the source of the problem, since I was able to work it around. cat /proc/acpi/wakeup Device S-state Status Sysfs node P0P1 S4 *disabled EHC1 S3 *enabled pci:0000:00:1d.0 EHC2 S3 *enabled pci:0000:00:1a.0 XHC S3 *enabled pci:0000:00:14.0 RP01 S0 *disabled pci:0000:00:1c.0 PXSX S3 *disabled pci:0000:07:00.0 RP02 S3 *disabled pci:0000:00:1c.1 PXSX S4 *disabled pci:0000:08:00.0 RP03 S5 *disabled pci:0000:00:1c.2 PXSX S5 *enabled pci:0000:0e:00.0 PEG0 S3 *disabled PEGP S3 *disabled If I disable XHC wakeup support, the laptop keeps suspended. Its weird, since no USB device has wakeup enabled: cat /sys/bus/usb/devices/*/power/wakeup disabled disabled disabled disabled disabled disabled disabled disabled PS: It may fail before 3.9, I didn't try. Regards, Alejandro
Additional comments: I also disabled EHC1 and EHC2. Otherwise, it still fails. Therefore, wht XHC, EHC1 and EHC2 disabled, it works.
Hi Alejandro: This looks like XHCI cause the issue. System resume works as long as XHC wakeup is disabled regardless of EHC1/2 status, right? Cc Alan & Sarah.
Hi Lan, nop, sorry, that's what I thought at first. But then I realized that I had to disable ECH1/2 as well. Just checked right now. If configuration is like this, everything works as expected: P0P1 S4 *disabled EHC1 S3 *disabled pci:0000:00:1d.0 EHC2 S3 *disabled pci:0000:00:1a.0 XHC S3 *disabled pci:0000:00:14.0 RP01 S0 *disabled pci:0000:00:1c.0 PXSX S3 *disabled pci:0000:07:00.0 RP02 S3 *disabled pci:0000:00:1c.1 PXSX S4 *disabled pci:0000:08:00.0 RP03 S5 *disabled pci:0000:00:1c.2 PXSX S5 *enabled pci:0000:0e:00.0 PEG0 S3 *disabled PEGP S3 *disabled However, at the very moment I enable any of XHC, EHC*, it does resume immediately after suspend: P0P1 S4 *disabled EHC1 S3 *enabled pci:0000:00:1d.0 EHC2 S3 *disabled pci:0000:00:1a.0 XHC S3 *disabled pci:0000:00:14.0 RP01 S0 *disabled pci:0000:00:1c.0 PXSX S3 *disabled pci:0000:07:00.0 RP02 S3 *disabled pci:0000:00:1c.1 PXSX S4 *disabled pci:0000:08:00.0 RP03 S5 *disabled pci:0000:00:1c.2 PXSX S5 *enabled pci:0000:0e:00.0 PEG0 S3 *disabled PEGP S3 *disabled
Ok. Thanks for clarification. Both XHCI and EHCI will trigger it. Could you check whether it worked on the older kernel before v3.9? Thanks.
Hi Lan, apparently the problem has been solved in Kernel 3.10.15 (linux-lts in Arch linux). I clearly remember me eagerly waiting for 3.11 wishing it will solve the suspend issue, so I'm clear 3.10.x failed to me in the past. But, for some reason, 3.10.15 seems to work fine. Maybe some patch got included, or maybe linux-lts and linux have different configuration files in Arch linux, I cannot tell (but I could if you think it is relevant). What it is sure is that it is happening in 3.11.4, x86_64. Thanks
This does not sound like a USB problem. It might be a problem somewhere else (ACPI, for instance). Or it might be caused by a bug in the BIOS. Have you checked for BIOS updates? In any case, if you have a kernel that works, the simplest way to find the solution may be git bisection.
Hello, I guessed it was related to ACPI, that's why I sent it to the ACPI group. Regarding the BIOS update..., still not available. I will be observant, though. Thank you, Alejandro
(In reply to Alan Stern from comment #6) > This does not sound like a USB problem. It might be a problem somewhere > else (ACPI, for instance). Or it might be caused by a bug in the BIOS. > Have you checked for BIOS updates? Hi Alan: Thanks for response. Enabling device's wakeup via /proc/acpi/wakeup is just to open device's wakeup gpe and remain its power during system suspend from ACPI side. If the device sent wakeup signal immediately after system suspend, the symptom would take place. So I guessed it's USB related issue first. > > In any case, if you have a kernel that works, the simplest way to find the > solution may be git bisection. > Yes, git bisect is the best way. Hi Alejandro: Could you check whether these is a good upstream kernel version for this issue? If yes, please do git bisect.
HI Alejandro: Any update?
Since no response for one month, close this bug as insufficient data. Please feel free to reopen the bug if available.