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- > SERR- 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- > SERR- 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- > SERR- 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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50d3544c.5030...@googlemail.com
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- SERR- 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- SERR- 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- SERR- http://lists.debian.org/50d34c2d.2010...@googlemail.com
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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50d213ca.9080...@googlemail.com
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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50cdff0f.2000...@googlemail.com
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 like"1-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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c9f5db.6080...@googlemail.com
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: ... [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 ... 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 like"1-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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c8e8e0.8050...@googlemail.com
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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c7acd2.6010...@googlemail.com
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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506f009c.1040...@gmx.net
