I previously reported trouble with a USB audio device. Some background: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103808352918939&w=2
Since then repeated testing has shown that a single processor kernel will also fail, just not nearly as quickly, so I was incorrect in that assumption. After some testing with the ohci driver, I'm starting to suspect this is a documented problem in the AMD766 controller on the motherboard. Referring to http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_873_1130,00.html and their "AMD-766 Peripheral Bus Controller Data Sheet", I am suspicious of Erratum Number 20. To my understanding this describes a case where the HccaDoneHead may not be updated at the end of a frame. The Erratum fails to mention if the WDH (OHCI_INTR_WDH) interrupt will still occur or not. My hardware is: 00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-766 [ViperPlus] USB (re v 07) (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 16, IRQ 11 Memory at 000dc000 (32-bit, non-prefetchable) [size=4K] Chip labeling: AMD-766AC B 0038FQA J I've spent some time instrumenting ohci-hcd.c and ohci-q.c in drivers/usb/host, and it looks like I do not get a WDH interrupt when I see the failure. I'm not sure I've proved this conclusively, as it's possible the WDH interrupt occurs, but the ohci->hcca->done_head register is 0. The Erratum suggests the pointer will be lost and never written into DoneHead. I'd guess that means the register will be 0 from the last time the driver cleared it, and the HC did never update it. I don't see any straightforward ways to workaround this problem. Am I correct in my understanding that the ohci driver will lock in the case of a missed WDH interrupt w/lost DoneHead pointer? It looks to me like the driver relies on the DoneHead coming back from the HC successfully, and cannot recover without it (dl_reverse_done_list() in ohci-hcd.c). With my limited knowledge of the driver, it seems possible to enable the SOF interrupts and then maybe keep the done list up to date at that time. That seems like an excessive penalty to pay in additional interrupts though. Maybe a timeout if a frame fails to complete? Is that possible in the current driver architecture? For audio, using ISOC frames, I can imagine this not being to bad, but am not really sure. Here's a snippet of the log when debugging is enabled: Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: RET d7a0cd80 dev:2,ep=2 -O,ISOC,flags:2,len:960/1215,stat:0 Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: SUB d7a0cd80 dev:2,ep=2 -O,ISOC,flags:2,len:0/1215,stat:-115 Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: data(0/1215): 9c 17 e4 19 fa 17 3f 1a 6a 18 9d 1a d9 18 f2 1a... stat:-115 Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: RET d7a0cc00 dev:2,ep=3 -I,ISOC,flags:2,len:0/15,stat:0 Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: data(0/15): stat:0 Jan 1 22:02:21 sea kernel: drivers/usb/host/ohci-dbg.c: SUB d7a0cc00 dev:2,ep=3 -I,ISOC,flags:2,len:0/15,stat:-115 Audio playback will be halted at this point and no further activity occurs. Enabling the ohci_int() debug printout shows that no further activity occurs after this point. I can get one additional SOF (OHCI_INTR_SF) interrupt past this point if I hack the driver to enable them continuously, but no further WDH interrupts occur. (You cannot see interrupts in this snippet because I've moved the interrupt debug printout from the stock source code location to later in ohci_int() and didn't want to confuse the order without posting source also.) Comments and testing above are based on linux-bk 2.5.53 code. Behavior is consistent across multiple versions of the 2.5 and 2.4 kernels. Any thoughts or suggestions on the best way to proceed? I'm presently pursuing being able to recover any way possible, probably by maintaining the TD/URB list in the driver, so that I can check the list on SOF interrupts and catch the missing DoneHead entry. Is that possible? This is mostly to prove the problem, rather than as a optimal fix. I'm relatively new to the OHCI USB driver, so please be gentle with comments! :) -- Kevin ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
