On Tue, Nov 16, 2010 at 01:22:20PM -0800, Sarah Sharp wrote: > > > 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? Actually, yeah I decided to try those to see what happens when they are connected to the usb3 card. - usb2 webcam - usb2 pen drive - <nothing> in all the above cases the resume worked successfully. So they only case that it doesn't work is when the harddrive is plugged in. And I still can't get the 'auto' thing working when this usb3 Buffalo harddrive is plugged in (and not mounted). Oh well. > > 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. I wouldn't doubt that it's flaky. :-) Thanks, Don -- 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
