On Mon, 28 Jan 2008, Greg KH wrote: > I'm getting the above error messages a lot in my current USB kernel > tree. I'm guessing it's due to the: > Subject: USB: EHCI: add separate IAA watchdog timer > patch from Alan (as1028) which was based off an earlier patch from > David. > > Any ideas why this is so noisy and slows down USB device discovery?
It should not slow down device discovery (or anything else). > I've included below the output of dmesg from plugging in a usb card > reader with a SD card in the slot. > > Any thoughts? > usb 1-6.3: new high speed USB device using ehci_hcd and address 8 > ehci_hcd 0000:00:1d.7: IAA watchdog: status c029 cmd 10031 > ehci_hcd 0000:00:1d.7: IAA watchdog: status c029 cmd 10031 For any interested readers: The 0x0020 bit in the status means the IAA bit is set, and lack of the 0x0040 bit in the command means that the IAAD bit has been cleared (as it should). But the controller is supposed to generate an interrupt request when IAA is set in the status register, and apparently it hasn't -- otherwise the watchdog timer would have been disabled and the bit would have been cleared by the interrupt handler. On Mon, 28 Jan 2008, David Brownell wrote: > On Monday 28 January 2008, David Brownell wrote: > > On Monday 28 January 2008, Greg KH wrote: > > > Any ideas why this is so noisy and slows down USB device discovery? > > > > Noisy: it should be ehci_dbg() not ehci_info(). Yes. Although it is eye-opening to see on how many systems the message appears. Obviously this design bug is present in a lot of controllers... or else there's a serious error somewhere in ehci-hcd. > ... also, it looks like the watchdog may have been running when > it should have been disabled. You can't really tell that from Greg's log. For example, hal will silently poll USB storage devices looking for media changes, and that would cause the watchdog to be enabled. On Mon, 28 Jan 2008, Greg KH wrote: > But even then, it's taking longer to boot because of this problem. Is > this really showing that my hardware is broken? It didn't used to have > any problems :) The hardware isn't working to the EHCI spec. Whether that means it's broken is a matter of opinion... possibly depending on what company you work for! :-) It's hard to tell from your log how much the boot has been delayed (no timestamps). > Ok, anything I can do to test this? > > Or should I just drop the patch? I still don't see how the new watchdog code could cause anything to slow down. Just as an experiment you could try reverting the patch or booting an older kernel to see if it speeds up again. In fact, it's even possible that a separate recent change to the driver has caused the controller to start exhibiting this buggy behavior -- in which case reverting the patch wouldn't result in a speedup but booting an older kernel would. I'm in favor of keeping the patch but changing the ehci_info to ehci_dbg. However it would be good to have more information before making any decisions. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
