On Tue, Jun 12, 2012 at 12:40 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 12 Jun 2012, Austin Schuh wrote: >> $ cat /sys/kernel/debug/usb/ehci/0000\:00\:1a.7/async >> qh/ffff88047452a700 dev8 hs ep2 42002208 40000000 (80008c00 data1 nak4) >> ffff880037801180 out len=0 80008c00 urb ffff880596b06600 > > This means that the transfer was completed but the computer apparently > never got a completion interrupt. > >> $ cat /sys/kernel/debug/usb/ehci/0000\:00\:1a.7/lpm >> $ cat /sys/kernel/debug/usb/ehci/0000\:00\:1a.7/periodic >> size = 1024 >> $ cat /sys/kernel/debug/usb/ehci/0000\:00\:1a.7/registers >> bus pci, device 0000:00:1a.7 >> EHCI Host Controller >> EHCI 1.00, hcd state 1 >> ownership 00000001 >> SMI sts/enable 0xc0080000 >> structural params 0x00103206 >> capability params 0x00016871 >> status 8008 Async FLR >> command 0010021 (park)=0 ithresh=1 Async period=1024 RUN >> intrenable 37 IAA FATAL PCD ERR INT >> uframe 3f17 >> port:1 status 001000 0 ACK POWER sig=se0 >> port:2 status 001000 0 ACK POWER sig=se0 >> port:3 status 003000 0 ACK POWER OWNER sig=se0 >> port:4 status 001005 0 ACK POWER sig=se0 PE CONNECT >> port:5 status 001000 0 ACK POWER sig=se0 >> port:6 status 001000 0 ACK POWER sig=se0 >> irq normal 43424 err 0 reclaim 6314 (lost 21) >> complete 43440 unlink 3819 > > That's pretty normal, except that the count of lost IAA interrupts > ought to be 0. Does that typically mean anything? > If you get rid of the line saying: > > ehci->need_io_watchdog = 0; > > under the PCI_VENDOR_ID_INTEL case in > drivers/usb/host/ehci-pci.c:ehci_pci_setup(), it may help. That seems to have fixed it. Hmm... I used to be able to run my code anywhere from 3-30 times before it would hang. It is at 470 cycles right now and counting without an issue. Apart from building and deploying custom patched kernels everywhere that I need to run my code, is there something that I can do to help get this hack packaged up into something that could be submitted? Or, is there something else that I should look around for that could be the root cause of the problem? > This isn't supposed to be necessary; Intel components are pretty > reliable. > > Alan Stern Thanks for your help! Austin Schuh -- 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
