On Wed, 20 Jun 2012, Austin Schuh wrote: > > That's the smoking gun. �There _was_ an interrupt, and the STS_INT bit > > (the 0x01 bit) in the status register was set. �That should have caused > > ehci_irq to call ehci_work -> scan_async -> qh_completions. > > > > qh_completions should have seen that the QTD_STS_ACTIVE bit wasn't set > > in the qTD token (the 0x80 bit in the low-order byte of the 00008c00 > > word in the second line of the "async" file). �That would tell it the > > transfer was complete. > > > > Here's a patch to print out the values of the qTD tokens. �Let's see > > what it shows when your transfer hangs up. �Leave the "IRQ:" message in > > place. > Here's the output with your latest patch. > [ 431.233814] usb 1-4: usbdev_do_ioctl: SUBMITURB > [ 431.233820] usb 1-4: userurb 00007f8888b03c20, ep3 int-in, length 32 > [ 431.233827] usb 1-4: link qh64-0001/ffff88056bc40d00 start 1 [1/0 us] > [ 431.247524] ehci_hcd 0000:00:1a.7: IRQ: status c028 cmd 10031 > [ 431.297262] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297268] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297273] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297277] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297280] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297283] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297286] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 431.297289] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 208d80 > [ 433.276713] ehci_hcd 0000:00:1a.7: IRQ: status 6009 cmd 10011 > [ 433.276726] ehci_hcd 0000:00:1a.7: qh ffff88056bc40d00 qtd > ffff8800378011e0 token 80108d00 > [ 433.276732] usb 1-4: urb complete > [ 433.276735] usb 1-4: userurb 00007f8888b03c20, ep3 int-in, > actual_length 16 status -121 > [ 433.276739] data: 10 00 00 00 04 00 01 c1 ff ff ff ff 00 00 00 00 > ................ > [ 433.276764] usb 1-4: usbdev_do_ioctl: REAPURBNDELAY > [ 433.276972] usb 1-4: usbdev_do_ioctl: SUBMITURB > [ 433.276979] usb 1-4: userurb 00007f8888b02090, ep2 bulk-out, length 12 > [ 433.276982] data: 0c 00 00 00 01 00 16 91 25 00 00 00 > ........%... > [ 433.277051] ehci_hcd 0000:00:1a.7: IRQ: status c009 cmd 10021 And qh_completions wasn't even called... It's interesting that in both the last two test cases, the problem occurred immediately following the completion of an interrupt-IN URB. Maybe there's some connection. > $ cat 0000\:00\:1a.7/async > qh/ffff88055a83b180 dev4 hs ep2 42002204 40000000 (00008c00 data0 nak4) > ffff880037801240 out len=0 00008c00 urb ffff8805709bef00 The next question is: Why wasn't qh_completions called? Either ehci_irq isn't calling ehci_work, or ehci_work isn't calling scan_async, or scan_async isn't calling qh_completions. Can you add appropriate debugging statements to figure that out, or would you like me to write another patch? Alan Stern -- 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
