Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Just as a side note, some discussion has been taking place at https://bugzilla.kernel.org/show_bug.cgi?id=43081 particularly on looking for ways to detect the 5V/5VSB setting via software, if possible at all. If this is not possible from the kernel, I'd suggest, setting the default to whatever works out of the box for most Asus-based laptops. -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 03.01.2013 21:58, schrieb Alan Stern: ... On Thu, 3 Jan 2013, Octavio Alvarez wrote: If not, then what would the sanest default be? Where to document this cas in a clean, user friendly way? The sanest default is what my patch does: disable wakeup for OHCI controllers on computers with ASUS boards. I'm open to suggestions on the best way to document it for users. I agree that wakeup should be disabled by default for all affected devices. But the problem I see is, that this will cause a regression for those people who have set the jumpers on their board to +5VSB. OTOH, I doubt that many people are using the +5VSB setting if the ports are powered all the time. Noone wants illuminated devices if the PC is switched off completely. Factory setting is also +5V. And the second problem is, that we still don't know which devices are affected. The FAQ entry on the ASUS website shows that they are aware of the problem, so there is a chance that they will fix it sooner or later. So blacklisting all ASUS devices seems to be a bit overkill. Maybe we have luck and get a statement about the affected hardware. Regards, Frank Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 28.12.2012 01:10, schrieb Alan Stern: On Wed, 26 Dec 2012, Octavio Alvarez wrote: It can't hurt to try the test. Does the patch below make any difference? Thank you for the patch, but it makes no difference. :( Too bad. I looked for more instances of linux immediate wakeup and found interesting links. They are regarding EHCI, but I wonder if something similar could affect OHCI as well. First, two threads in linux-pm from 2010: http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025063.html [PATCH] ehci: Disable wake on overcurrent (WKOC_E) http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025064.html [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) Do you think this may affect OHCI too in some similar way? No, I don't think so. The mechanisms used by EHCI and OHCI for controlling the wakeup setting (and in particular, wake on overcurrent) are totally different. --- Then, three links, apparently regarding EHCI about the usage of +5VSB instead of the +5V line for powering the USB controller. Could the experiment with switching the +5V and +5VSB lines be relevant as well for OCHI? In fact, this message _is_ about OHCI. http://www.gossamer-threads.com/lists/mythtv/users/316830 ASUS M2NPV-VM It's certainly worth trying this out. I figured out that you have to enable the +5VSB jumper on all the USB hubs that have devices connected to them, even if you're not going to use them to wake up the box! In other words, turn them ALL on, not just the one where the wake-up device is connected. Don't worry about joysticks waking up your machine randomly, because they won't; apparently only devices with power buttons can do so. --- https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128315 Suspend started working after changing the USB from +5V to +5VSB. I do get a message about half the times that 1 application refused to freeze: Plasma. After the suspend attempt, I have to kill plasma and restart it. If I try suspending again it works most of the time. But this seems like an unrelated bug. --- http://www.gossamer-threads.com/lists/mythtv/users/309798 Additionally, you need to have the motherboard jumper for USB host controller set so that it gets power during S3. If hardware jumpers on the motherboard are in the wrong position, it definitely could cause the sort of problem you've been experiencing. Alan Stern Ok, I tried switching the ports to +5VSB. That makes S3 work (no immediate wakeups). The problem is, that with this setting, the USB ports are powered ALWAYS (even when the computer is switched off completely). Great, especially when you have a USB device connected with lots of LEDs (or just an ordinary optical mouse)... :( Is there way to determine if the port is powered permanently ? I assume not, so there seems to be no sane way to fix/work around this. Seems like users have to disable wakeups for OHCI manually... Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 3 Jan 2013, [ISO-8859-1] Frank Sch�fer wrote: Ok, I tried switching the ports to +5VSB. That makes S3 work (no immediate wakeups). The problem is, that with this setting, the USB ports are powered ALWAYS (even when the computer is switched off completely). Great, especially when you have a USB device connected with lots of LEDs (or just an ordinary optical mouse)... :( Is there way to determine if the port is powered permanently ? I assume not, so there seems to be no sane way to fix/work around this. Seems like users have to disable wakeups for OHCI manually... Frank, take a look at comment #51 in https://bugzilla.kernel.org/show_bug.cgi?id=43081 (near the end of the bug report). Does it do what you want? Does anybody know if the +5VSB line is supposed to remain powered when the computer is shut down (G2/S5 state)? Maybe that's the bug in ASUS's ACPI implementation, and to work around it they avoid using +5VSB for OHCI. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 03 Jan 2013 11:22:19 -0800, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 3 Jan 2013, [ISO-8859-1] Frank Sch�fer wrote: Ok, I tried switching the ports to +5VSB. That makes S3 work (no immediate wakeups). The problem is, that with this setting, the USB ports are powered ALWAYS (even when the computer is switched off completely). Great, especially when you have a USB device connected with lots of LEDs (or just an ordinary optical mouse)... :( I just wanted to mention the following link to this FAQ on the Asus website. They blame the OS (Vista) for this, but they don't provide any workaround information, except what we already know: either switch to +5VSB or disable wakeups. http://support.asus.com/FAQ/Detail.aspx?no=7E9E847A-6F0F-DE5A-BF73-6733215FD3BDp=1m=P5N-E%20SLI Looking for 7E9E847A-6F0F-DE5A-BF73-6733215FD3BD site:asus.com shows that this FAQ is not exclusive of nVidia-based systems. So the title of this bug may be wrong. I wonder if there is any non-Asus system with MCP51 that behaves correctly. And yes, I second Frank's question: Is there way to determine if the port is powered permanently? Does the output of any utility (dmidecode, or whatever other utility) change if power is on +5V or +5VSB? Any BIOS setting? If not, then what would the sanest default be? Where to document this cas in a clean, user friendly way? I'd test it myself but my test machine died a while ago. Best regards. -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 26 Dec 2012, Octavio Alvarez wrote: It can't hurt to try the test. Does the patch below make any difference? Thank you for the patch, but it makes no difference. :( Too bad. I looked for more instances of linux immediate wakeup and found interesting links. They are regarding EHCI, but I wonder if something similar could affect OHCI as well. First, two threads in linux-pm from 2010: http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025063.html [PATCH] ehci: Disable wake on overcurrent (WKOC_E) http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025064.html [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) Do you think this may affect OHCI too in some similar way? No, I don't think so. The mechanisms used by EHCI and OHCI for controlling the wakeup setting (and in particular, wake on overcurrent) are totally different. --- Then, three links, apparently regarding EHCI about the usage of +5VSB instead of the +5V line for powering the USB controller. Could the experiment with switching the +5V and +5VSB lines be relevant as well for OCHI? In fact, this message _is_ about OHCI. http://www.gossamer-threads.com/lists/mythtv/users/316830 ASUS M2NPV-VM It's certainly worth trying this out. I figured out that you have to enable the +5VSB jumper on all the USB hubs that have devices connected to them, even if you're not going to use them to wake up the box! In other words, turn them ALL on, not just the one where the wake-up device is connected. Don't worry about joysticks waking up your machine randomly, because they won't; apparently only devices with power buttons can do so. --- https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128315 Suspend started working after changing the USB from +5V to +5VSB. I do get a message about half the times that 1 application refused to freeze: Plasma. After the suspend attempt, I have to kill plasma and restart it. If I try suspending again it works most of the time. But this seems like an unrelated bug. --- http://www.gossamer-threads.com/lists/mythtv/users/309798 Additionally, you need to have the motherboard jumper for USB host controller set so that it gets power during S3. If hardware jumpers on the motherboard are in the wrong position, it definitely could cause the sort of problem you've been experiencing. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 21.12.2012 18:02, schrieb Alan Stern: snip On Fri, 21 Dec 2012, Frank Schäfer wrote: 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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- Interrupt: pin A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Kernel driver in use: ohci_hcd That certainly looks right. And it says that the controller is not sending an erroneous wakeup signal (PME is off). Therefore we can conclude that the problem really does lie in the firmware. Ok, so the chipset doesn't matter ? snip Anyway, system still wakes up from S3 immediately. Okay. I dislike disabling remote wakeup for all nVidia/SiS OHCI controllers just to compensate for ASUS's mistakes, but there doesn't seem to be any alternative at this point. Is it possible to disable remote wakeup only for OHCI controllers with ASUS Bios ? Or would such a quirk be too complex ? Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 24.12.2012 20:23, schrieb Alan Stern: On Fri, 21 Dec 2012, Frank Schäfer wrote: Anyway, system still wakes up from S3 immediately. It just occurred to me that not too long ago we learned about a BIOS bug in ASUS systems that affects EHCI controllers during system suspend (the workaround is commit dbf0e4c7257f8d684ec1a3c919853464293de66e; you can look it up if you want). Perhaps the same bug affects OHCI controllers too. It can't hurt to try the test. Does the patch below make any difference? Thank you for the patch, but it makes no difference. :( Regards, Frank Alan Stern Index: usb-3.7/drivers/pci/pci-driver.c === --- usb-3.7.orig/drivers/pci/pci-driver.c +++ usb-3.7/drivers/pci/pci-driver.c @@ -716,7 +716,7 @@ static int pci_pm_suspend_noirq(struct d * Since the value of the COMMAND register doesn't matter once the * device has been suspended, we can safely set it to 0 here. */ - if (pci_dev-class == PCI_CLASS_SERIAL_USB_EHCI) + if ((pci_dev-class 8) == PCI_CLASS_SERIAL_USB) pci_write_config_word(pci_dev, PCI_COMMAND, 0); return 0; -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 26 Dec 2012 09:21:03 -0800, Frank Schäfer fschaefer@googlemail.com wrote: Am 24.12.2012 20:23, schrieb Alan Stern: On Fri, 21 Dec 2012, Frank Schäfer wrote: Anyway, system still wakes up from S3 immediately. It just occurred to me that not too long ago we learned about a BIOS bug in ASUS systems that affects EHCI controllers during system suspend (the workaround is commit dbf0e4c7257f8d684ec1a3c919853464293de66e; you can look it up if you want). Perhaps the same bug affects OHCI controllers too. It can't hurt to try the test. Does the patch below make any difference? Thank you for the patch, but it makes no difference. :( I looked for more instances of linux immediate wakeup and found interesting links. They are regarding EHCI, but I wonder if something similar could affect OHCI as well. First, two threads in linux-pm from 2010: http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025063.html [PATCH] ehci: Disable wake on overcurrent (WKOC_E) http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025064.html [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) Do you think this may affect OHCI too in some similar way? --- Then, three links, apparently regarding EHCI about the usage of +5VSB instead of the +5V line for powering the USB controller. Could the experiment with switching the +5V and +5VSB lines be relevant as well for OCHI? http://www.gossamer-threads.com/lists/mythtv/users/316830 ASUS M2NPV-VM I figured out that you have to enable the +5VSB jumper on all the USB hubs that have devices connected to them, even if you're not going to use them to wake up the box! In other words, turn them ALL on, not just the one where the wake-up device is connected. Don't worry about joysticks waking up your machine randomly, because they won't; apparently only devices with power buttons can do so. --- https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128315 Suspend started working after changing the USB from +5V to +5VSB. I do get a message about half the times that 1 application refused to freeze: Plasma. After the suspend attempt, I have to kill plasma and restart it. If I try suspending again it works most of the time. But this seems like an unrelated bug. --- http://www.gossamer-threads.com/lists/mythtv/users/309798 Additionally, you need to have the motherboard jumper for USB host controller set so that it gets power during S3. -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Fri, 21 Dec 2012, Frank Schäfer wrote: Anyway, system still wakes up from S3 immediately. It just occurred to me that not too long ago we learned about a BIOS bug in ASUS systems that affects EHCI controllers during system suspend (the workaround is commit dbf0e4c7257f8d684ec1a3c919853464293de66e; you can look it up if you want). Perhaps the same bug affects OHCI controllers too. It can't hurt to try the test. Does the patch below make any difference? Alan Stern Index: usb-3.7/drivers/pci/pci-driver.c === --- usb-3.7.orig/drivers/pci/pci-driver.c +++ usb-3.7/drivers/pci/pci-driver.c @@ -716,7 +716,7 @@ static int pci_pm_suspend_noirq(struct d * Since the value of the COMMAND register doesn't matter once the * device has been suspended, we can safely set it to 0 here. */ - if (pci_dev-class == PCI_CLASS_SERIAL_USB_EHCI) + if ((pci_dev-class 8) == PCI_CLASS_SERIAL_USB) pci_write_config_word(pci_dev, PCI_COMMAND, 0); return 0; -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 19.12.2012 20:35, schrieb Alan Stern: On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote: I can confirm that MCP55 has this bug and it should be safe to add MCP65-78S, too, because MCP79 still has the bug. By the way, you mentioned that runtime suspend seemed to work okay, right? It might be worthwhile testing this again, just to be certain. In particular, I'd like to see what lspci -vv shows for the controller while it is runtime suspended with a device attached. As far as the OHCI hardware is concerned, there shouldn't be any difference between runtime suspend and system suspend. This strongly suggests that the bug doesn't lie in the controller itself but in the firmware (BIOS or ACPI). Alan Stern Yes runtime suspend works (tested with a mouse) and lspci -vv doesn't change. With /sys/devices/pci:00/:00:02.0/usb2/2-9/power: control = on runtime_status = active 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd = set control to 'auto' runtime_status = active 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd = after ~2s the device suspends runtime_status = suspended 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 20 Dec 2012, Frank Schäfer wrote: Yes runtime suspend works (tested with a mouse) and lspci -vv doesn't change. With /sys/devices/pci:00/:00:02.0/usb2/2-9/power: control = on runtime_status = active 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd = set control to 'auto' runtime_status = active 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd = after ~2s the device suspends runtime_status = suspended 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8234 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 A routed to IRQ 23 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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: ohci_hcd Of course I checked that the host controller suspends, too. The lspci output above shows that the host controller is _not_ suspended. Or at least, that's what it looks like -- maybe for some reason the runtime suspend code didn't put the controller into D3. It would help to see the dmesg output from a kernel with CONFIG_USB_DEBUG enabled. What do you get in /sys/devices/pci:00/:00:02.0/power/ ? I also checked if lspci changes after unplugging the mouse, but that's not the case. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
于 2012/12/18 4:06, Alan Stern 写道:
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
* they only forward requests from the root hub. Therefore
* controllers should always be enabled for remote wakeup.
*/
- device_wakeup_enable(hcd-self.controller);
+ if (!usb_hcd_wakeup_quirks(hcd-self.controller))
+ device_wakeup_enable(hcd-self.controller);
return retval;
error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
*/
#include linux/usb.h
+#include linux/pci.h
#include linux/usb/quirks.h
#include usb.h
@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev-quirks |= quirks;
}
+
+struct pci_hcd {
+ u32 vendor;
+ u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+ {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+ { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+ struct pci_dev *pdev;
+ int i;
+
+ if (dev-bus != (struct bus_type *)pci_bus_type)
+ return 0;
+
+ pdev = to_pci_dev(dev);
+ for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+ if ((hcd_wakeup_qrk[i].vendor == pdev-vendor)
+ (hcd_wakeup_qrk[i].device == pdev-device)) {
+ return 1;
+ }
+
+ return 0;
+}
I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:
Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt
Incidentally, this patch should be written differently. Instead of a
quirks routine, there should simply be a bad_wakeup bitflag added to
the usb_hcd structure. The flag should be set in ohci-pci.c by
matching against nVidia's PCI vendor ID.
Oh. I forget to mention the issue also takes place on the uhci.
https://bugzilla.kernel.org/show_bug.cgi?id=42721
So we also should make such a patch for uhci.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, Lan Tianyu wrote:
Hi Alan:
How about this patch?
Index: linux-pm/drivers/usb/host/ohci-pci.c
===
--- linux-pm.orig/drivers/usb/host/ohci-pci.c 2012-11-01
18:21:33.604460469 +0800
+++ linux-pm/drivers/usb/host/ohci-pci.c2012-12-19
14:39:07.081601806 +0800
@@ -188,6 +188,15 @@
pci_write_config_word(pdev, 0x50, misc | 0x0300);
}
+static int ohci_quirk_bad_wakeup(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci (hcd);
+
+ ohci_dbg(ohci, marked as bad wakeup.\n);
I'd prefer the message to be something more like enabled nVidia/SiS
wakeup quirk.
+ hcd-bad_wakeup = true;
+ return 0;
+}
+
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -238,6 +247,31 @@
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ /* MCP51 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x026d),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP61 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x03f1),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa5),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa7),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
Since we don't know of any nVidia controllers that function correctly,
you might as well match any product ID.
+ {
+ /* SiS OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_SI, 7001),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
Index: linux-pm/include/linux/usb/hcd.h
===
--- linux-pm.orig/include/linux/usb/hcd.h 2012-11-01
18:21:34.732460451 +0800
+++ linux-pm/include/linux/usb/hcd.h2012-12-19 10:48:43.305822774 +0800
@@ -138,6 +138,7 @@
resource_size_t rsrc_start; /* memory/io resource
start */
resource_size_t rsrc_len; /* memory/io resource
length */
unsignedpower_budget; /* in mA, 0 = no limit */
+ boolbad_wakeup;
This should be a bitflag (i.e., bad_wakeup:1) and it should come
immediately after has_tt:1.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, lantianyu wrote: Oh. I forget to mention the issue also takes place on the uhci. https://bugzilla.kernel.org/show_bug.cgi?id=42721 So we also should make such a patch for uhci. That bug report shows clearly that it is a software problem or a device problem, not an error in the UHCI controller hardware. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern st...@rowland.harvard.edu wrote: + ohci_dbg(ohci, marked as bad wakeup.\n); I'd prefer the message to be something more like enabled nVidia/SiS wakeup quirk. To me, the stupid end-user, both messages are useless. I don't know that that means or implies. I would go with: Disabled OHCI wakeup (USB) due to faulty controller (no-wakeup.txt) and have a file named no-wakeup.txt under Documentation with this: Users have reported OHCI misbehavior consisting on false wakeups right after suspend to RAM on some OHCI controllers, particularly from nVIDIA and SiS. For those controllers, wakeups has been disabled. The system will not be able to wake up the system from suspend to RAM from an OHCI (USB) device. To see the list of affected controllers do: grep -B 3 ohci_quirk_bad_wakeup linux-pm/drivers/usb/host/ohci-pci.c Bug is tracked at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472 -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern st...@rowland.harvard.edu wrote: You, the stupid end-user, would not see this message at all under normal circumstances. It uses the ohci_dbg macro and therefore will not appear unless your kernel is built with CONFIG_USB_DEBUG enabled. Shouldn't it be exposed to dmesg? -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, Octavio Alvarez wrote: On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern st...@rowland.harvard.edu wrote: You, the stupid end-user, would not see this message at all under normal circumstances. It uses the ohci_dbg macro and therefore will not appear unless your kernel is built with CONFIG_USB_DEBUG enabled. Shouldn't it be exposed to dmesg? None of the other quirk messages are. On the other hand, they don't affect the behavior as much as this quirk does. Still, if we do produce a message about it, I don't feel it is necessary to try and explain the whole situation. Something as simple as Buggy wakeup support, disabling should be enough for an end-user who wants to know why typing on the USB keyboard doesn't wake up a suspended system. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 19.12.2012 16:29, schrieb Alan Stern:
On Wed, 19 Dec 2012, Lan Tianyu wrote:
...
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -238,6 +247,31 @@
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ /* MCP51 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x026d),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP61 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x03f1),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa5),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa7),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
Since we don't know of any nVidia controllers that function correctly,
you might as well match any product ID.
Some more NVIDIA OHCI controllers:
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0067)/* nForce2 */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x01c2)/* nForce */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x036c)/* MCP55 */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0454)/* MCP65 */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x055e)/* MCP67 */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x077b)/* MCP78S */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x077d)/* MCP78S */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0d9c)/* MCP89 */
I can confirm that MCP55 has this bug and it should be safe to add
MCP65-78S, too, because MCP79 still has the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote: I can confirm that MCP55 has this bug and it should be safe to add MCP65-78S, too, because MCP79 still has the bug. By the way, you mentioned that runtime suspend seemed to work okay, right? It might be worthwhile testing this again, just to be certain. In particular, I'd like to see what lspci -vv shows for the controller while it is runtime suspended with a device attached. As far as the OHCI hardware is concerned, there shouldn't be any difference between runtime suspend and system suspend. This strongly suggests that the bug doesn't lie in the controller itself but in the firmware (BIOS or ACPI). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 19 Dec 2012 11:35:50 -0800, Alan Stern st...@rowland.harvard.edu wrote: As far as the OHCI hardware is concerned, there shouldn't be any difference between runtime suspend and system suspend. This strongly suggests that the bug doesn't lie in the controller itself but in the firmware (BIOS or ACPI). Is there a way we can help to look for such a failing pattern, more directly related to BIOS/ACPI instead of the OHCI controller, in lspci, dmidecode or some other tool? -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
[CC: list trimmed slightly] On Wed, 19 Dec 2012, Octavio Alvarez wrote: On Wed, 19 Dec 2012 11:35:50 -0800, Alan Stern st...@rowland.harvard.edu wrote: As far as the OHCI hardware is concerned, there shouldn't be any difference between runtime suspend and system suspend. This strongly suggests that the bug doesn't lie in the controller itself but in the firmware (BIOS or ACPI). Did you actually do a runtime suspend test? What does lspci -v show for the controller while it is suspended with a device attached? Is there a way we can help to look for such a failing pattern, more directly related to BIOS/ACPI instead of the OHCI controller, in lspci, dmidecode or some other tool? Not that I know of. Probably the only way we will find the answer to this problem is by getting in touch with an engineer at ASUS who knows what the BIOS is doing wrong. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月18日 04:06, Alan Stern wrote:
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
* they only forward requests from the root hub. Therefore
* controllers should always be enabled for remote wakeup.
*/
- device_wakeup_enable(hcd-self.controller);
+ if (!usb_hcd_wakeup_quirks(hcd-self.controller))
+ device_wakeup_enable(hcd-self.controller);
return retval;
error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
*/
#include linux/usb.h
+#include linux/pci.h
#include linux/usb/quirks.h
#include usb.h
@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev-quirks |= quirks;
}
+
+struct pci_hcd {
+ u32 vendor;
+ u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+ {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+ { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+ struct pci_dev *pdev;
+ int i;
+
+ if (dev-bus != (struct bus_type *)pci_bus_type)
+ return 0;
+
+ pdev = to_pci_dev(dev);
+ for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+ if ((hcd_wakeup_qrk[i].vendor == pdev-vendor)
+ (hcd_wakeup_qrk[i].device == pdev-device)) {
+ return 1;
+ }
+
+ return 0;
+}
I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:
Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt
Incidentally, this patch should be written differently. Instead of a
quirks routine, there should simply be a bad_wakeup bitflag added to
the usb_hcd structure. The flag should be set in ohci-pci.c by
matching against nVidia's PCI vendor ID.
Hi Alan:
How about this patch?
Index: linux-pm/drivers/usb/host/ohci-pci.c
===
--- linux-pm.orig/drivers/usb/host/ohci-pci.c 2012-11-01
18:21:33.604460469 +0800
+++ linux-pm/drivers/usb/host/ohci-pci.c2012-12-19
14:39:07.081601806 +0800
@@ -188,6 +188,15 @@
pci_write_config_word(pdev, 0x50, misc | 0x0300);
}
+static int ohci_quirk_bad_wakeup(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci (hcd);
+
+ ohci_dbg(ohci, marked as bad wakeup.\n);
+ hcd-bad_wakeup = true;
+ return 0;
+}
+
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -238,6 +247,31 @@
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ /* MCP51 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x026d),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP61 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x03f1),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa5),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* MCP79 OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 0x0aa7),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
+ {
+ /* SiS OHCI */
+ PCI_DEVICE(PCI_VENDOR_ID_SI, 7001),
+ .driver_data = (unsigned long)ohci_quirk_bad_wakeup,
+ },
/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
Index: linux-pm/include/linux/usb/hcd.h
===
--- linux-pm.orig/include/linux/usb/hcd.h 2012-11-01
18:21:34.732460451 +0800
+++ linux-pm/include/linux/usb/hcd.h2012-12-19 10:48:43.305822774 +0800
@@ -138,6 +138,7 @@
resource_size_t rsrc_start; /* memory/io resource
start */
resource_size_t rsrc_len; /* memory/io resource
length */
unsignedpower_budget; /* in mA, 0 = no limit */
+ boolbad_wakeup;
/* bandwidth_mutex should be taken before adding or removing
* any new bus bandwidth constraints:
Index:
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
* they only forward requests from the root hub. Therefore
* controllers should always be enabled for remote wakeup.
*/
- device_wakeup_enable(hcd-self.controller);
+ if (!usb_hcd_wakeup_quirks(hcd-self.controller))
+ device_wakeup_enable(hcd-self.controller);
return retval;
error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
*/
#include linux/usb.h
+#include linux/pci.h
#include linux/usb/quirks.h
#include usb.h
@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev-quirks |= quirks;
}
+
+struct pci_hcd {
+ u32 vendor;
+ u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+ {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+ { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+ struct pci_dev *pdev;
+ int i;
+
+ if (dev-bus != (struct bus_type *)pci_bus_type)
+ return 0;
+
+ pdev = to_pci_dev(dev);
+ for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+ if ((hcd_wakeup_qrk[i].vendor == pdev-vendor)
+ (hcd_wakeup_qrk[i].device == pdev-device)) {
+ return 1;
+ }
+
+ return 0;
+}
I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:
Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt
--
Octavio.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
* they only forward requests from the root hub. Therefore
* controllers should always be enabled for remote wakeup.
*/
- device_wakeup_enable(hcd-self.controller);
+ if (!usb_hcd_wakeup_quirks(hcd-self.controller))
+ device_wakeup_enable(hcd-self.controller);
return retval;
error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
*/
#include linux/usb.h
+#include linux/pci.h
#include linux/usb/quirks.h
#include usb.h
@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev-quirks |= quirks;
}
+
+struct pci_hcd {
+ u32 vendor;
+ u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+ {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+ { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+ struct pci_dev *pdev;
+ int i;
+
+ if (dev-bus != (struct bus_type *)pci_bus_type)
+ return 0;
+
+ pdev = to_pci_dev(dev);
+ for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+ if ((hcd_wakeup_qrk[i].vendor == pdev-vendor)
+ (hcd_wakeup_qrk[i].device == pdev-device)) {
+ return 1;
+ }
+
+ return 0;
+}
I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:
Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt
Incidentally, this patch should be written differently. Instead of a
quirks routine, there should simply be a bad_wakeup bitflag added to
the usb_hcd structure. The flag should be set in ohci-pci.c by
matching against nVidia's PCI vendor ID.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Has anybody ever seen a report of an nVidia OHCI controller that does _not_ have this bug? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 04:28, Frank Schäfer wrote: Am 12.12.2012 09:23, schrieb Lan Tianyu: On 2012年12月12日 05:59, Frank Schäfer wrote: Am 11.12.2012 17:48, schrieb Alan Stern: [snip] We really need to know which component is bad: the host controller or the device. It happens with all USB 1.1 devices I have (several mice and a HP Deskjet 960c printer). The same devices do not cause other machines to wake up, so I assume it's the host controller. Good information. Attaching device makes hc work abnormally during entering into s3 since without device it can work, right? Right. The system successfully enters S3 (machine switches off = fan stops, light off etc.) but it resumes immediately. No errors in the log, it looks like this: snip ... [24685.640361] PM: Syncing filesystems ... done. [24686.022132] PM: Preparing system for mem sleep [24686.110208] Freezing user space processes ... (elapsed 0.01 seconds) done. [24686.123851] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [24686.134818] PM: Entering mem sleep [24686.134840] Suspending console(s) (use no_console_suspend to debug) [24686.135751] sd 1:0:0:0: [sda] Synchronizing SCSI cache [24686.136509] sd 1:0:0:0: [sda] Stopping disk [24686.150741] i8042 kbd 00:0b: wake-up capability enabled by ACPI [24686.150833] i8042 aux 00:0a: wake-up capability disabled by ACPI [24686.150926] parport_pc 00:09: disabled [24686.151029] serial 00:08: disabled [24686.151056] serial 00:08: wake-up capability disabled by ACPI [24686.151219] ACPI handle has no context! [24686.151299] [drm] nouveau :00:0d.0: Disabling display... [24686.151302] [drm] nouveau :00:0d.0: Disabling fbcon... [24686.151311] [drm] nouveau :00:0d.0: Unpinning framebuffer(s)... [24686.151341] [drm] nouveau :00:0d.0: Evicting buffers... [24686.255063] usb 1-5: reset high-speed USB device number 3 using ehci_hcd [24686.346351] [drm] nouveau :00:0d.0: Idling channels... [24686.346668] [drm] nouveau :00:0d.0: Suspending GPU objects... [24686.447591] [drm] nouveau :00:0d.0: And we're gone! [24687.547695] PM: suspend of devices complete after 1412.642 msecs [24687.547853] PM: late suspend of devices complete after 0.153 msecs [24687.548029] forcedeth :00:07.0: wake-up capability enabled by ACPI [24687.559652] ehci_hcd :00:02.1: wake-up capability enabled by ACPI [24687.570602] ohci_hcd :00:02.0: wake-up capability enabled by ACPI [24687.581671] PM: noirq suspend of devices complete after 33.815 msecs [24687.581735] ACPI: Preparing to enter system sleep state S3 [24687.582536] PM: Saving platform NVS memory [24687.582591] Disabling non-boot CPUs ... [24687.583984] smpboot: CPU 1 is now offline [24687.584703] Extended CMOS year: 2000 [24687.584703] ACPI: Low-level resume complete [24687.584703] PM: Restoring platform NVS memory [24687.584703] Extended CMOS year: 2000 [24687.586196] Enabling non-boot CPUs ... [24687.589496] smpboot: Booting Node 0 Processor 1 APIC 0x1 [24687.583795] Initializing CPU#1 [24687.583795] process: Switch to broadcast mode on CPU1 [24687.601153] CPU1 is up [24687.601538] ACPI: Waking up from system sleep state S3 [24687.613683] ohci_hcd :00:02.0: wake-up capability disabled by ACPI [24687.624693] ehci_hcd :00:02.1: wake-up capability disabled by ACPI [24687.624746] pci :00:00.0: Found enabled HT MSI Mapping [24687.635726] pci :00:00.0: Found enabled HT MSI Mapping [24687.657735] pci :00:00.0: Found enabled HT MSI Mapping [24687.668730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679803] pci :00:00.0: Found enabled HT MSI Mapping [24687.679878] pci :00:00.0: Found enabled HT MSI Mapping [24687.679956] pci :00:00.0: Found enabled HT MSI Mapping [24687.773804] PM: noirq resume of devices complete after 171.507 msecs [24687.773907] PM: early resume of devices complete after 0.056 msecs [24687.773980] ohci_hcd :00:02.0: setting latency timer to 64 [24687.774001] ehci_hcd :00:02.1: setting latency timer to 64 [24687.774023] pci :00:04.0: setting latency timer to 64 ... snip When I disconnect all USB 1.1 devices, suspend works fine. I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. diff --git a/drivers/usb/core/hcd.c
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 13.12.2012 09:45, schrieb Lan Tianyu: [snip] I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). It would be great if we could get in touch with an engineer at ASUS or nVidia who knows the cause of this problem and how to work around it. Tianyu, do you think this would be possible? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012 07:35:55 -0800, Frank Schäfer fschaefer@googlemail.com wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). These are 4 machines I found reported. I don't know what is the exact PCI ID needed, so I compiled links and information. MACHINE 1: DELL XPS 1340 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=43081 The bug doesn't have system information, but a search on the Internet [1][2] suggest that it's an MCP79 chipset, integrated by Dell itself. [1] http://ubuntuforums.org/showthread.php?t=1927427 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/969755 The lspci for [2] is at: https://launchpadlibrarian.net/99189829/Lspci.txt MACHINE 2 and 3: ASUS P4S8X and P4S8X-MX mainboards Bug: https://bugzilla.kernel.org/show_bug.cgi?id=47991 lspci: https://bugzilla.kernel.org/attachment.cgi?id=81331 Both are mostly unrelated to nVidia, except for the graphics card in one of them. Both have SiS-based chipsets. Enough device information in bug report. MACHINE 4: ASUS 1201N Bug: https://bugs.launchpad.net/linux/+bug/952080 lspci: https://launchpadlibrarian.net/96828581/Lspci.txt Also an nVidia MCP79-based device. All device info in bug report. -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 23:47, Alan Stern wrote: On Thu, 13 Dec 2012, Frank Schäfer wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). It would be great if we could get in touch with an engineer at ASUS or nVidia who knows the cause of this problem and how to work around it. Tianyu, do you think this would be possible? Hi Alan: I think this is very hard because these board is old and nVidia doesn't produce chipset now. Otherwise, I have no such channel to communicate with ASUS or nVidia engineer. :( Alan Stern -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 23:35, Frank Schäfer wrote: Am 13.12.2012 09:45, schrieb Lan Tianyu: [snip] I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? Yeah. From other reporter. I also wonder if this could be an BIOS / ACPI issue. Just from my opinion, this cause's by OHCI/UHCI. Because if there is no attached device, suspend can work. This shows BIOS/ACPI work correctly. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). Regards, Frank -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月12日 05:59, Frank Schäfer wrote: Am 11.12.2012 17:48, schrieb Alan Stern: [snip] We really need to know which component is bad: the host controller or the device. It happens with all USB 1.1 devices I have (several mice and a HP Deskjet 960c printer). The same devices do not cause other machines to wake up, so I assume it's the host controller. Good information. Attaching device makes hc work abnormally during entering into s3 since without device it can work, right? I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Do this for all devices under OHCI/UHCI and test again. Thanks. This can answer Alan's question Does the HC turn on the GPE even when the device does not send a remote wakeup request? I don't know enough about the low level details, so I really can't contribute anything else than doing testing / debugging. If it comes to blacklisting, do you think there is a chance/possibility to get a statement form NVIDA about this issue ? It seems that at least the MCP51, MCP55 and MCP61 chipsets are affected... I think we can default disable OHCI/UHCI wakeup on these board to avoid the problems. Before doing this, I think we should try to make the issue clear. Hi Alan: About your question of Does the device send a remote wakeup request even when it is disabled for remote wakeup?, I am not very clear. Default, device remote wakeup is disabled and if we disable device's remote wakeup via sysfs, the device's remote wakeup feature will not be set during being suspended. So normally, it should not send out remote wakeup signal but if it still sent out, this means it's a buggy device, right? Moreover, this test is hard to do during s3 since system suspend, we can't see any log. So this should be done in the runtime. I think it's easy to do this test on mouse or keyboard device. Regards, Frank Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 12.12.2012 09:23, schrieb Lan Tianyu: On 2012年12月12日 05:59, Frank Schäfer wrote: Am 11.12.2012 17:48, schrieb Alan Stern: [snip] We really need to know which component is bad: the host controller or the device. It happens with all USB 1.1 devices I have (several mice and a HP Deskjet 960c printer). The same devices do not cause other machines to wake up, so I assume it's the host controller. Good information. Attaching device makes hc work abnormally during entering into s3 since without device it can work, right? Right. The system successfully enters S3 (machine switches off = fan stops, light off etc.) but it resumes immediately. No errors in the log, it looks like this: snip ... [24685.640361] PM: Syncing filesystems ... done. [24686.022132] PM: Preparing system for mem sleep [24686.110208] Freezing user space processes ... (elapsed 0.01 seconds) done. [24686.123851] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [24686.134818] PM: Entering mem sleep [24686.134840] Suspending console(s) (use no_console_suspend to debug) [24686.135751] sd 1:0:0:0: [sda] Synchronizing SCSI cache [24686.136509] sd 1:0:0:0: [sda] Stopping disk [24686.150741] i8042 kbd 00:0b: wake-up capability enabled by ACPI [24686.150833] i8042 aux 00:0a: wake-up capability disabled by ACPI [24686.150926] parport_pc 00:09: disabled [24686.151029] serial 00:08: disabled [24686.151056] serial 00:08: wake-up capability disabled by ACPI [24686.151219] ACPI handle has no context! [24686.151299] [drm] nouveau :00:0d.0: Disabling display... [24686.151302] [drm] nouveau :00:0d.0: Disabling fbcon... [24686.151311] [drm] nouveau :00:0d.0: Unpinning framebuffer(s)... [24686.151341] [drm] nouveau :00:0d.0: Evicting buffers... [24686.255063] usb 1-5: reset high-speed USB device number 3 using ehci_hcd [24686.346351] [drm] nouveau :00:0d.0: Idling channels... [24686.346668] [drm] nouveau :00:0d.0: Suspending GPU objects... [24686.447591] [drm] nouveau :00:0d.0: And we're gone! [24687.547695] PM: suspend of devices complete after 1412.642 msecs [24687.547853] PM: late suspend of devices complete after 0.153 msecs [24687.548029] forcedeth :00:07.0: wake-up capability enabled by ACPI [24687.559652] ehci_hcd :00:02.1: wake-up capability enabled by ACPI [24687.570602] ohci_hcd :00:02.0: wake-up capability enabled by ACPI [24687.581671] PM: noirq suspend of devices complete after 33.815 msecs [24687.581735] ACPI: Preparing to enter system sleep state S3 [24687.582536] PM: Saving platform NVS memory [24687.582591] Disabling non-boot CPUs ... [24687.583984] smpboot: CPU 1 is now offline [24687.584703] Extended CMOS year: 2000 [24687.584703] ACPI: Low-level resume complete [24687.584703] PM: Restoring platform NVS memory [24687.584703] Extended CMOS year: 2000 [24687.586196] Enabling non-boot CPUs ... [24687.589496] smpboot: Booting Node 0 Processor 1 APIC 0x1 [24687.583795] Initializing CPU#1 [24687.583795] process: Switch to broadcast mode on CPU1 [24687.601153] CPU1 is up [24687.601538] ACPI: Waking up from system sleep state S3 [24687.613683] ohci_hcd :00:02.0: wake-up capability disabled by ACPI [24687.624693] ehci_hcd :00:02.1: wake-up capability disabled by ACPI [24687.624746] pci :00:00.0: Found enabled HT MSI Mapping [24687.635726] pci :00:00.0: Found enabled HT MSI Mapping [24687.657735] pci :00:00.0: Found enabled HT MSI Mapping [24687.668730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679803] pci :00:00.0: Found enabled HT MSI Mapping [24687.679878] pci :00:00.0: Found enabled HT MSI Mapping [24687.679956] pci :00:00.0: Found enabled HT MSI Mapping [24687.773804] PM: noirq resume of devices complete after 171.507 msecs [24687.773907] PM: early resume of devices complete after 0.056 msecs [24687.773980] ohci_hcd :00:02.0: setting latency timer to 64 [24687.774001] ehci_hcd :00:02.1: setting latency timer to 64 [24687.774023] pci :00:04.0: setting latency timer to 64 ... snip When I disconnect all USB 1.1 devices, suspend works fine. I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 12 Dec 2012 12:28:16 -0800, Frank Schäfer fschaefer@googlemail.com wrote: Good information. Attaching device makes hc work abnormally during entering into s3 since without device it can work, right? Right. The system successfully enters S3 (machine switches off = fan stops, light off etc.) but it resumes immediately. No errors in the log, it looks like this: A while ago I did some tests, and I got no errors whatsoever, not even with PM_DEBUG. System is successfully suspended but immediately awaken. -- Octavio. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月12日 23:50, Alan Stern wrote: On Wed, 12 Dec 2012, Lan Tianyu wrote: Hi Alan: About your question of Does the device send a remote wakeup request even when it is disabled for remote wakeup?, I am not very clear. Default, device remote wakeup is disabled and if we disable device's remote wakeup via sysfs, the device's remote wakeup feature will not be set during being suspended. So normally, it should not send out remote wakeup signal but if it still sent out, this means it's a buggy device, right? Right. Moreover, this test is hard to do during s3 since system suspend, we can't see any log. So this should be done in the runtime. I think it's easy to do this test on mouse or keyboard device. Yes, that should work. But Frank says that the same mouse and keyboard do not cause other machines to wake up, so the devices are probably working correctly. Yeah. Do you have one of these machines to test? Unfortunately, I don't have such machine. Alan Stern -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Tue, 11 Dec 2012, Lan Tianyu wrote: Hi AlanGreg: Since 3.1, Alan enabled usb device wakeup default, there are a lot of problem that immediately resume when enter into s2ram/s2disk. I have traced some these bugs. Most of these bugs are related usb1.1 device which attached to OHCI/UHCI. If disable the hc wakeup or no device attached, it will work again. Not all usb1.1 devices will cause this issue. What if the device is disabled for wakeup? That's the right solution if the device is buggy. From enabe/disable hc wakeup side, I check what is done in the ACPI. When system is entering into s3/s4, ACPI will check all the device which has wakeup resource(there is a gpe interrupt for these devices). If their wakeup was enabled, ACPI will enable their gpe interrupt . If there was a signal of gpe during s3, the system would be resumed. That's the right thing to do. Normally, usb hc will have gpe to wakeup system. This issue caused by hc with some usb1.1 devices triggering wakeup signal just after entering into s3/s4. Does the HC turn on the GPE even when the device does not send a remote wakeup request? Does the device send a remote wakeup request even when it is disabled for remote wakeup? System resumes immediately. Since the signal is triggered after system entering into s3/s4, it's hard to debug what hc does during this procedure(This comes from my analyse, I have no such machine to debug). So can we add a blacklist which contains devices causing such issue and disable these devices' remote wakeup when system suspend to avoid such problems? Well, we can create blacklist entries for malfunctioning USB devices. I don't know about malfunctioning host controllers, though. Maybe. Or you have some new debug measures, they are welcome. If something I said is wrong, please help me correct it. Thanks. We really need to know which component is bad: the host controller or the device. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 11.12.2012 17:48, schrieb Alan Stern: [snip] We really need to know which component is bad: the host controller or the device. It happens with all USB 1.1 devices I have (several mice and a HP Deskjet 960c printer). The same devices do not cause other machines to wake up, so I assume it's the host controller. I don't know enough about the low level details, so I really can't contribute anything else than doing testing / debugging. If it comes to blacklisting, do you think there is a chance/possibility to get a statement form NVIDA about this issue ? It seems that at least the MCP51, MCP55 and MCP61 chipsets are affected... Regards, Frank Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 10/05/2012 07:56 AM, Alan Stern wrote: On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Well, there was the workaround: echo disabled /sys/devices/pci:00/:00:0b.0/power/wakeup ... which I applied on startup at /etc/rc.local and has worked beautifully for me since. Further testing started to get us nowhere. As far as conclusions regarding hardware, we got to the PC is doing something fishy or is weirdly wired up. I also concluded that it wasn't actually a regression because on 3.1, enabling 0:0:0b.0/power/wakeup also made the system autoresume. It's just that the policy changed and that's how my system got broken, but the policy can be tweaked on /etc/rc.local. I went on vacation and forgot after that. However, I also started to distrust my pen drive, as it has been randomly acting up other Linux systems. This causes it to unmount by itself, throw journal errors, etc. Not sure if the pen drive is damaged, or the kernel has problem, as my iPhone does similar things sometimes and that's not damaged. In any case, conclusions drawn from the pen drive might be incorrect now and we might have to retest. So, theories: a. My MCP51 is damaged. b. The MCP51 designer or manufacturer's brain is damaged. c. The kernel programming is wrong for MCP51. And options: a. Somehow blacklist power/wakeup for this device and call it a day. b. Continue testing the weird stuff until we squash the sucker, which I'm more than willing to do. We can re-test from scratch if necessary to rebuild the whole test matrix. I may need detailed instructions for some tests. I would get a new pendrive just to get that out of the way. There are some cheap Kingstons out there I can get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 05.10.2012 18:44, schrieb Octavio Alvarez: On 10/05/2012 07:56 AM, Alan Stern wrote: On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Well, there was the workaround: echo disabled /sys/devices/pci:00/:00:0b.0/power/wakeup ... which I applied on startup at /etc/rc.local and has worked beautifully for me since. Further testing started to get us nowhere. As far as conclusions regarding hardware, we got to the PC is doing something fishy or is weirdly wired up. I also concluded that it wasn't actually a regression because on 3.1, enabling 0:0:0b.0/power/wakeup also made the system autoresume. It's just that the policy changed and that's how my system got broken, but the policy can be tweaked on /etc/rc.local. I went on vacation and forgot after that. However, I also started to distrust my pen drive, as it has been randomly acting up other Linux systems. This causes it to unmount by itself, throw journal errors, etc. Not sure if the pen drive is damaged, or the kernel has problem, as my iPhone does similar things sometimes and that's not damaged. In any case, conclusions drawn from the pen drive might be incorrect now and we might have to retest. So, theories: a. My MCP51 is damaged. b. The MCP51 designer or manufacturer's brain is damaged. c. The kernel programming is wrong for MCP51. I just want to let you know that I'm having exactly the same problem with the Nvidia MCP61. The first linux kernel I tried with this hardware was ~2.6.16 and it already din't work there... I don't know much about the powermanagement stuff, but I can certainly test patches and provide informations about the system if needed. Regards, Frank And options: a. Somehow blacklist power/wakeup for this device and call it a day. b. Continue testing the weird stuff until we squash the sucker, which I'm more than willing to do. We can re-test from scratch if necessary to rebuild the whole test matrix. I may need detailed instructions for some tests. I would get a new pendrive just to get that out of the way. There are some cheap Kingstons out there I can get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 9 Jul 2012, Octavio Alvarez wrote: On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern st...@rowland.harvard.edu wrote: Removing my pen drive cleared CCS on [6]. Okay, that explains that. More or less. Is this an old USB-1.1 pen drive? If it is USB-2.0 then I would expect it to connect to the EHCI controller, not the OHCI controller. I don't know... Is there a way to know that? The device is a Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 That doesn't mean much by itself. But the lsusb output you included confirms that the pen drive was running at high speed -- which means that it should never have been connected to the OHCI controller at all. Another mystery. It appears that your computer's USB hardware is kind of funky. Alan, take a look at this: Bus# 2 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub |-Dev# 18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90 `-Dev# 19 Vendor 0x046d Product 0xc31d Logitech, Inc. Bus# 1 `-Dev# 1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub `-Dev# 18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3 For some reason, my USB drive is now on EHCI! As it should be. Was there ever a time when it was definitely using the OHCI controller? (The CCS status you got before wasn't definite enough to count -- it showed a connected status but not an enabled status.) That should never happen, except when ehci-hcd is unloaded. What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Well, we can assume that the suspend doesn't work when either device is plugged in. Which suggests another test. Try unloading ehci-hcd, and plug in the pen drive. At that point it should use the OHCI controller. Then if you unplug the keyboard and mouse, what happens when you suspend? My guess is that it will resume immediately. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 7 Jul 2012, Octavio Alvarez wrote: On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern st...@rowland.harvard.edu wrote: roothub.portstatus [4] 0x0303 LSDA PPS PES CCS roothub.portstatus [5] 0x0303 LSDA PPS PES CCS roothub.portstatus [6] 0x0101 PPS CCS That's normal, except for the status of port 6 (which actually is port 7, since we normally count ports starting from 1). The port shows Current Connect Status, so something is connected to it -- but what? It looks like it was my pendrive. Disconnecting the mouse and keyboard cleared CCS on [4] and [5] (not necesariliy in that order). Removing my pen drive cleared CCS on [6]. Okay, that explains that. More or less. Is this an old USB-1.1 pen drive? If it is USB-2.0 then I would expect it to connect to the EHCI controller, not the OHCI controller. FYI, bisecting and other testing was done pretty much without my pendrive all the time. Good. The fewer possible sources of confusion, the better. I just tested suspend, just for the sake of it, and it still wakes up right after sleep. Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG enabled? Sure. This is it, up to second 178 (last msg is in 81), before pushing the suspend button. ... Pretty much normal. This is the continuation of the previous dmesg, starting on second 178, when I pressed the power button. (done without my pen drive) The suspending part is normal. The resuming part is not... [ 181.394398] usb usb2: usb resume [ 181.394403] ohci_hcd :00:0b.0: wakeup root hub [ 181.394426] usb usb1: usb resume [ 181.394430] ehci_hcd :00:0b.1: resume root hub [ 181.428035] ehci_hcd :00:0b.1: port 6 low speed -- companion That shouldn't have happened. It's not actually _wrong_, but it indicates that the USB controllers did not maintain their states properly while the system was suspended. [ 181.472053] hub 2-0:1.0: hub_resume [ 181.472076] ohci_hcd :00:0b.0: GetStatus roothub.portstatus [4] = 0x00030301 PESC CSC LSDA PPS CCS [ 181.472082] hub 2-0:1.0: port 5: status 0301 change 0003 [ 181.472100] ohci_hcd :00:0b.0: GetStatus roothub.portstatus [5] = 0x00030301 PESC CSC LSDA PPS CCS These messages are indications of the same problem. [ 181.472105] hub 2-0:1.0: port 6: status 0301 change 0003 [ 181.524028] ehci_hcd :00:0b.1: GetStatus port:6 status 003402 0 ACK POWER OWNER sig=k CSC [ 181.540030] hub 1-0:1.0: hub_resume [ 181.540040] ehci_hcd :00:0b.1: GetStatus port:1 status 001020 0 ACK POWER sig=se0 OCC [ 181.540051] ehci_hcd :00:0b.1: GetStatus port:2 status 001020 0 ACK POWER sig=se0 OCC [ 181.540061] ehci_hcd :00:0b.1: GetStatus port:3 status 001020 0 ACK POWER sig=se0 OCC [ 181.540071] ehci_hcd :00:0b.1: GetStatus port:4 status 001020 0 ACK POWER sig=se0 OCC [ 181.540086] ehci_hcd :00:0b.1: GetStatus port:7 status 001020 0 ACK POWER sig=se0 OCC [ 181.540095] ehci_hcd :00:0b.1: GetStatus port:8 status 001020 0 ACK POWER sig=se0 OCC These messages are highly suspicious. They indicate a low-level hardware problem in the wiring of the USB controllers or support components. I won't go into further detail. The remaining events all seem to flow from these underlying problems. Just out of curiosity, what happens if you suspend with the mouse and keyboard unplugged, i.e., no USB devices attached at all? (To forestall possible questions, you run a little shell script that sleeps for 10 seconds, during which you unplug the keyboard and mouse, and then initiates a system suspend.) Also, what happens if you unload ehci-hcd before suspending (with the keyboard and mouse plugged in as normal)? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 7 Jul 2012, Octavio Alvarez wrote: 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 :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 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x804a 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 PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0303 LSDA PPS PES CCS roothub.portstatus [5] 0x0303 LSDA PPS PES CCS roothub.portstatus [6] 0x0101 PPS CCS roothub.portstatus [7] 0x0100 PPS That's normal, except for the status of port 6 (which actually is port 7, since we normally count ports starting from 1). The port shows Current Connect Status, so something is connected to it -- but what? Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG enabled? 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 ... Pretty much normal. 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 :00:0b.1 0b.1 is the EHCI controller. We want to see the OHCI controller, 0b.0. I also bisected the 3.2 doesn't sleep due to ohci problem and found this: commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b Author: Alan Stern st...@rowland.harvard.edu Date: Mon Sep 26 11:23:38 2011 -0400 USB: Update USB default wakeup settings Yes, that commit enables wakeup for USB host controllers by default. Before that, you had to enable wakeup by hand. The question is: Why does the controller think it needs to wake up the system? Can you also post a dmesg log showing a full suspend/immediate-resume cycle with CONFIG_USB_DEBUG enabled? 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.mo...@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.mo...@intel.com Signed-off-by: Len Brown len.br...@intel.com Yes, okay, that is indeed totally separate. You should bring that issue up with Bob Moore and Len Brown on the linux-acpi mailing list. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
