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: linux-pm/drivers/usb/core
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 b/drivers/usb/core
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 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
