Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Hi, Alan!
So, after about more than a week of bisecting, and thanks to Jonathan
Nieder's
more-than-precise instructions, the results are in.
On Mon, 25 Jun 2012 11:41:31 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
<stern@rowland.harvard.edu>
wrote:
> What happens if Octavio disables wakeup for that controller before
> suspending?
>
> echo disabled >/sys/bus/pci/devices/0000:00:0b.0/power/wakeup
On kernel 3.2, it lets suspend work again.
If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers?
[Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ grep . ohci/*/registers
bus pci, device 0000:00:0b.0
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
cmdstatus 0x00000 SOC=0
intrstatus 0x00000024 FNO SF
intrenable 0x8000004a MIE RHSC RD WDH
ed_controlhead 2edac040
hcca frame 0x5fce
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80002e53 FRT FR=0x2e53
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
roothub.b 00000000 PPCM=0000 DR=0000
roothub.status 00008000 DRWE
roothub.portstatus [0] 0x00000100 PPS
roothub.portstatus [1] 0x00000100 PPS
roothub.portstatus [2] 0x00000100 PPS
roothub.portstatus [3] 0x00000100 PPS
roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS
roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS
roothub.portstatus [6] 0x00000101 PPS CCS
roothub.portstatus [7] 0x00000100 PPS
And what shows up in /sys/kernel/debug/usb/devices?
[Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ cat devices
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 8
B: Alloc= 29/900 us ( 3%), #Int= 3, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.03
S: Manufacturer=Linux 3.3.0+ ohci_hcd
S: Product=OHCI Host Controller
S: SerialNumber=0000:00:0b.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c05a Rev=54.00
S: Manufacturer=Logitech
S: Product=USB Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 6 Ivl=10ms
T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c31d Rev=66.00
S: Manufacturer=Logitech
S: Product=USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 4 Ivl=255ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 3.03
S: Manufacturer=Linux 3.3.0+ ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:0b.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
Also, what does the "lspci -vv" output show for the controller if you
run it with superuser permissions?
[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s 0000:00:0b.1
00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2)
(prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 22
Region 0: Memory at d5007000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci_hcd
I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:
commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Sep 26 11:23:38 2011 -0400
USB: Update USB default wakeup settings
This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers. Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they
should be enabled for wakeup by default.
Also, to be compliant with both the old and new policies, root hubs
should not be enabled for remote wakeup by default. Userspace must
enable it explicitly if it is desired.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For the [3.4] wakening back part, with both settings the PC locks up
requiring a
mechanical (power supply switch) power cycle to bring the computer back.
Not even the 5-sec power button cycle helps. I guess this is a different
bug, so I'll try to troubleshoot it and open a different one.
And yet the PC doesn't lock up if you unbind ohci-hcd before
suspending?
It suspends but it locks-up while waking up.
Maybe you can do a git bisection to find what changed between 3.2 and
3.4 to cause this behavior.
commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore <robert.moore@intel.com>
Date: Tue Feb 14 15:00:53 2012 +0800
ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl
registers
Adds sleep and wake support for systems with these registers.
One new file, hwxfsleep.c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
--
Octavio.
Reply to: