On Wednesday 02 May 2007, Mike Nuss wrote: > Mike Nuss wrote: > > David Brownell wrote:
Cleaning up some of my inbox here ... :) > >> So, trying for some (bad) ASCII art here > >> > >> TDs 1-4 submitted to ED, > >> HC completed a few (say, 1 & 2) > >> > >> ed.tail ---------------------------+ > >> ed.head ----------+ I > >> I I > >> v v > >> td1 --> td2 --> td3 --> td4 --> dummy > >> > >> Where "td" is like td1, and clearly is not the first TD in > >> the queue. > >> > >> One problem being that by now td1 and td2 should have shown up in > >> the donelist, through an IRQ. That would explain the symprom of > >> data transfers seeming to stop. > >> > >> It'd be interesting to see whether there's anything in that donelist; > >> if so, that might suggest that the driver somehow lost an IRQ. Try > >> printing its value in that "sanitize" path. > > > > It looks like the donelist is empty. > > > > user.warn kernel: ohci_hcd 0000:00:13.0: IRQ INTR_SF lossage > > user.err kernel: ohci_hcd 0000:00:13.0: done_head:0 > > user.warn kernel: finish_unlinks > > user.warn kernel: finish_unlinks: 0x2daa480 != 0x2daa440 > > user.warn kernel: finish_unlinks:skip ed > > user.err kernel: ohci_hcd 0000:00:13.0: leak ed c2b8f140 (#82) state 0 > > (has tds) > > user.err kernel: ohci_hcd 0000:00:13.0: free td c2daa440 > > > > Mike > > As a followup, I ran into this situation again tonight, with slightly > different results. This time, the tick_before check failed, and the > donelist was not empty: > > ohci_hcd 0000:00:13.0: IRQ INTR_SF lossage > ohci_hcd 0000:00:13.0: done_head:66216129 > ohci_hcd 0000:00:13.0: stalled endpoint, ed c3f25140 state 0x1 type > intr; next ed 00000000 > ohci_hcd 0000:00:13.0: info 0840512c MAX=64 DQ SKIP EP=2-IN DEV=44 > ohci_hcd 0000:00:13.0: tds: head 03f26180 DATA0 tail 03f26180 (not > listing) > finish_unlinks > finish_unlinks:tick_before(0, 16603) > finish_unlinks:skip ed > > I also decided to start dumping the ED when this happens. The SKIP bit > is set (it was also set in the case where the donelist was empty). With > that bit set by the driver, according to the OHCI spec, the HC will > pause queue processing. Is there anything odd about SKIP being set > during ohci_endpoint_disable() or is that just a red herring? It's possible that the SKIP bit isn't handled correctly. I've not looked at that code in some time, but I seem to recall thinking that setting SKIP was an action more in the "defensive paranoia" category than the "essential" one, so far as "functionally necessary" criteria go. It's just an optimization ... every time it's applied, the QH is also removed from the schedule. Either one alone should prevent the HCD from doing much more with that QH... But I don't have time to sort out the relationship between the SKIP bit and the software DEQUEUE flag. The complication is dl_done_list(). See if you can make that code behave without turning on SKIP. A quick'n'dirty experiment might be #defining that bit to zero and deferring the clear of ED_H so that dl_done_list() still has a way to tell when it's cleaning up after a halt. - Dave > Mike > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
