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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 20.12.2012 18:34, schrieb Frank Schäfer: 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 Of course I checked that the host controller suspends, too. I also checked if lspci changes after unplugging the mouse, but that's not the case. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 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 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. 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 It wouldn't hurt to include a URL for the bug report in a comment. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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:
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 14.12.2012 23:02, schrieb Alan Stern: 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? Not me, but MCP55 and MCP61 are the only ones I've (knowingly) tested. The problem is, that people usually don't report working hardware. Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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. Do you have one of these machines to test? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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. 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. 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. 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? Or you have some new debug measures, they are welcome. If something I said is wrong, please help me correct it. Thanks. https://bugzilla.kernel.org/show_bug.cgi?id=47991 https://bugzilla.kernel.org/show_bug.cgi?id=43081 2012/10/5 Frank Schäfer schaefer.fr...@gmx.net: 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 -- Best regards Tianyu Lan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
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! 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). -- Octavio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sun, 08 Jul 2012 07:40:49 -0700, Alan Stern st...@rowland.harvard.edu wrote: 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. 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 Does it make sense to think that some ports are OHCI and some are EHCI, particularly if some of them are on the back and some on the front? 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. Considering that this happens while the system is already resuming, do you think is in some way related with the bug? [ 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.) I'm using the power button to suspend and resume, so this test is actually easy. It's weird, but without K M connected, even with the pendrive connected, the system suspends! (The keyboard leds go off and all, though) Also, what happens if you unload ehci-hcd before suspending (with the keyboard and mouse plugged in as normal)? It doesn't suspend. I tested this a while ago. It's pretty much specific to ohci_hcd. Not sure if this is helpful but: [Sun Jul 08 10:02:31 -0700 -- alvarezp@octavio:~] $ sudo lsusb - Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice3.02 iManufacturer 3 Linux 3.2.0-3-686-pae ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:0b.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sun, 8 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. 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. Does it make sense to think that some ports are OHCI and some are EHCI, particularly if some of them are on the back and some on the front? No, not really. All the ports should be connected to both controllers. You can check the dmesg log to make sure that they have the same number of ports. 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. Considering that this happens while the system is already resuming, do you think is in some way related with the bug? Yes, I do. It happened during resume because of something that went wrong during suspend. That same something could easily be responsible for the immediate wakeup. 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.) I'm using the power button to suspend and resume, so this test is actually easy. It's weird, but without K M connected, even with the pendrive connected, the system suspends! (The keyboard leds go off and all, though) It's normal for the LEDs to turn off -- they use more current than is available when the keyboard is suspended. What happens if you unplug only the keyboard, or only the mouse? Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 st...@rowland.harvard.edu wrote: On Mon, 25 Jun 2012, Octavio Alvarez wrote: On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern st...@rowland.harvard.edu wrote: What happens if Octavio disables wakeup for that controller before suspending? echo disabled /sys/bus/pci/devices/: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 :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 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=: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=: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 :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 st...@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
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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Hi, Quick administrivia. Alan Stern wrote: 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? Yotam Benshalom from https://bugzilla.kernel.org/show_bug.cgi?id=43081 (cc-ed) is experiencing the same symptoms (Nvidia MCP79 OHCI controller producing immediate wakeups when he tries to resume, bisects to a6eeeb9f45b5). On Sat, 7 Jul 2012, Octavio Alvarez wrote: 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 [...] 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. The Debian bug for this one is http://bugs.debian.org/680707. Please cc me or 680...@bugs.debian.org if bringing it up with ACPI folks so we can track the discussion. Thanks again for your hard work. Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern st...@rowland.harvard.edu wrote: 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. Sorry about that. [Sat Jul 07 20:41:28 -0700 -- alvarezp@octavio:~] $ sudo lspci -vv -s :00:0b.0 00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2) (prog-if 10 [OHCI]) 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 A routed to IRQ 20 Region 0: Memory at d5006000 (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 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? Will do as soon as I reboot into a suitable kernel. Thanks for your help. -- Octavio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Hi Octavio, Quick instructions: Alan Stern wrote: It might be worthwhile tracking down the reason for the immediate wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up in /sys/kernel/debug/usb/devices? 0. prerequisites: apt-get install git build-essential 1. get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. fetch point releases: cd linux git remote add stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git fetch stable 3. configure, build: git checkout stable/linux-3.2.y cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration scripts/config --enable USB_DEBUG make deb-pkg; # optionally with -jnum for parallel build 4. test: dpkg -i ../name of package; # as root reboot mount -t debugfs debugfs /sys/kernel/debug grep . \ /sys/kernel/debug/usb/ohci/*/registers \ /sys/kernel/debug/usb/devices Also, what does the lspci -vv output show for the controller if you run it with superuser permissions? This one's easier (no rebuild necessary). For kernel 3.4, I'll break it into two parts: the going asleep and the wakening back. [...] For the 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. [...] Maybe you can do a git bisection to find what changed between 3.2 and 3.4 to cause this behavior. This works like so: cd linux git bisect start v3.4.1 stable/linux-3.2.y # git checkouts out a version halfway between to test, so try it: make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot ... test test test ... cd linux git bisect bad; # if resume locks up git bisect good; # if it resumes fine git bisect skip; # if some other bug makes it hard to test # git checks out a version halfway between to test, so: make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root ... and so on ... After enough cycles it will find the first bad commit. If you get bored before then: # if the gitk package is installed, # to see the current regression range narrowing at any step git bisect visualize # to print a log of tests you've run so far, which lets someone # else pick up where you left off git bisect log # to abandon the bisect git bisect reset See [1] for details. Hope that helps, Jonathan [1] http://git-htmldocs.googlecode.com/git/git-bisect-lk2009.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Sun, 24 Jun 2012, Ben Hutchings wrote: [The full log for this bug is at http://bugs.debian.org/677472] On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote: Under normal circumstances the system simply does not suspend. It appears to go all the way to suspension (screen off, disks off, etc.) but when it appears that it is going to go off, something prevents it. System doesn't hang, it just fails at the very last moment of suspension. I tried debugging using pm_test. I set it to core but suspend_stats doesn't catch anything: # cat /sys/kernel/debug/suspend_stats success: 12 fail: 0 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno: 0 0 last_failed_step: Even with pm_test set to none, suspend_stats increases the success value. This indicates that the system is woken up immediately after it suspends. From the kernel point of view (but not a practical point of view!) this is different from failing to suspend. As I said earlier, removing ohci_hcd lets suspend work again. So the USB controller (OHCI) has for some reason started waking up the system. As I suspected, this system has an Nvidia chipset: 00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc] 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 d5006000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied Kernel driver in use: ohci_hcd The Nvidia implementation of OHCI is unusual in some ways and has prompted a number of changes to power management. The last one was: commit c61875977458637226ab093a35d200f2d5789787 Author: Alan Stern st...@rowland.harvard.edu Date: Thu Nov 17 16:41:45 2011 -0500 OHCI: final fix for NVIDIA problems (I hope) Actually that wasn't exactly a power management change, although it was vaguely related. It really was more concerned with initialization and shutdown. But it looks like we have to disappoint Alan again. Well, this sounds like a different problem. What happens if Octavio disables wakeup for that controller before suspending? echo disabled /sys/bus/pci/devices/:00:0b.0/power/wakeup Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern st...@rowland.harvard.edu wrote: What happens if Octavio disables wakeup for that controller before suspending? echo disabled /sys/bus/pci/devices/:00:0b.0/power/wakeup On kernel 3.2, it lets suspend work again. For kernel 3.4, I'll break it into two parts: the going asleep and the wakening back. For the going asleep part, it works just like 3.2. It previously went almost asleep, but with echo disabled wakeup it suspends correctly. For the 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. -- Octavio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 25 Jun 2012, Octavio Alvarez wrote: On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern st...@rowland.harvard.edu wrote: What happens if Octavio disables wakeup for that controller before suspending? echo disabled /sys/bus/pci/devices/:00:0b.0/power/wakeup On kernel 3.2, it lets suspend work again. It might be worthwhile tracking down the reason for the immediate wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up in /sys/kernel/debug/usb/devices? Also, what does the lspci -vv output show for the controller if you run it with superuser permissions? For kernel 3.4, I'll break it into two parts: the going asleep and the wakening back. For the going asleep part, it works just like 3.2. It previously went almost asleep, but with echo disabled wakeup it suspends correctly. For the 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? Maybe you can do a git bisection to find what changed between 3.2 and 3.4 to cause this behavior. Alan Stern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
[The full log for this bug is at http://bugs.debian.org/677472] On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote: Under normal circumstances the system simply does not suspend. It appears to go all the way to suspension (screen off, disks off, etc.) but when it appears that it is going to go off, something prevents it. System doesn't hang, it just fails at the very last moment of suspension. I tried debugging using pm_test. I set it to core but suspend_stats doesn't catch anything: # cat /sys/kernel/debug/suspend_stats success: 12 fail: 0 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno: 0 0 last_failed_step: Even with pm_test set to none, suspend_stats increases the success value. This indicates that the system is woken up immediately after it suspends. From the kernel point of view (but not a practical point of view!) this is different from failing to suspend. As I said earlier, removing ohci_hcd lets suspend work again. So the USB controller (OHCI) has for some reason started waking up the system. As I suspected, this system has an Nvidia chipset: 00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc] 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 d5006000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied Kernel driver in use: ohci_hcd The Nvidia implementation of OHCI is unusual in some ways and has prompted a number of changes to power management. The last one was: commit c61875977458637226ab093a35d200f2d5789787 Author: Alan Stern st...@rowland.harvard.edu Date: Thu Nov 17 16:41:45 2011 -0500 OHCI: final fix for NVIDIA problems (I hope) But it looks like we have to disappoint Alan again. Ben. Also, I didn't find anything wrong in /var/log/pm-suspend.log. I may paste it in another message if you want because it's 4000 lines long. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
