On Tue, Nov 16, 2010 at 10:54:36AM -0500, Don Zickus wrote: > On Tue, Nov 16, 2010 at 10:47:56AM -0500, Don Zickus wrote: > > On Thu, Nov 11, 2010 at 01:04:20PM -0800, Sarah Sharp wrote: > > > Once you've found the right directory, echo "auto" to the power/control > > > file. That should autosuspend the USB 3.0 hard drive after 2 seconds. > > > Wait for 5 seconds or so, and then echo "on" to power/control. If the > > > dmesg shows that the device disconnected on resume, it may not be able > > > to handle USB device suspend. That could be the reason it disconnects > > > on resume from hibernate, because the xHCI driver has to put all the > > > devices in USB device suspend before suspending the host controller. > > > > > > The device might also need a reset-resume quirk, but I'd have to stare > > > at the log files and the code to see why this particular bug is > > > happening: > > > > > > xhci_hcd 0000:04:00.0: Can't reset device (slot ID 1) in enabled/disabled state > > > xhci_hcd 0000:04:00.0: Not freeing device rings. > > > xhci_hcd 0000:04:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90012710450, 32'h200e01, 4'hf); > > > xhci_hcd 0000:04:00.0: clear port reset change, actual port 3 status = 0xe03 > > > usb 6-4: new high speed USB device using xhci_hcd and address 4 > > > > > > I think it means reset-resume may not be able to be done under the xHCI > > > host. But, as I said, I have to look deeply at it. > > > > Hi Sarah, > > > > So I was poking around with it more, using suggestions from Matthew > > Garrett. > > Oh, one other thing, I am not sure I mentioned before. When my machine > comes back from resume and is in that broken state, a software reboot > doesn't fix it. I have to power cycle the box. > > Matthew was wondering if this is because the driver expects the chip to be > in a certain state during power up when it initializes the registers. > Suspending/resuming the chip could cause the registers to change state for > which the driver does not properly re-initialize? The xHCI driver tries to restore the registers after a resume, according to the instructions in the xHCI spec. But in your case (and in all the boxes I have), the register restore fails. So the driver halts, resets, and completely re-initializes the hardware. I don't think the bug is there. Have you to tried to see if USB 2.0 devices work fine across suspend? I'm only half-way through marking up the log, but it looks like the real issue is the device disconnecting on its own a short time after resume. I can fix any software bugs that appear because of that, but it really looks like you have a flaky USB 3.0 device. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
