And the third log file. -- Paul > -----Original Message----- > From: Paul Zimmerman > Sent: Thursday, October 21, 2010 3:23 PM > To: 'Sarah Sharp'; 'Andiry Xu' > Cc: 'linux-usb@xxxxxxxxxxxxxxx' > Subject: RE: [PATCH][RFC] xhci fixes > > The second log file. > > -- > Paul > > > -----Original Message----- > > From: Paul Zimmerman > > Sent: Thursday, October 21, 2010 3:14 PM > > To: 'Sarah Sharp'; 'Andiry Xu' > > Cc: 'linux-usb@xxxxxxxxxxxxxxx' > > Subject: RE: [PATCH][RFC] xhci fixes > > > > Hi Sarah, Andiry, > > > > I finally have some logs of those issues that I reported before. > > > > It takes a more complicated USB setup than before to show these issues. What I have now is this: > > > > +----+ +----+ +----+ > > |Snps| |USB3|---> USB3 SS BOT device |USB2|---> USB2 HS webcam > > |xhci|--->|SS |---------------------------->|FS | > > |ctlr| |hub |---> USB3 SS BOT device |hub | > > +----+ +----+ +----+ > > > > I am using a script to do file transfers to/from the BOT devices, and using Cheese to play video > from > > the webcam. > > > > I am using Linus' 2.6.36 kernel from yesterday, plus a modified version of the debugging patch that > > Sarah created for this issue, plus John's hub patch. > > > > I have 3 logs with 3 different issues. I am attaching the first log, plus the modified debugging > > patch, to this email. I will send the other 2 logs as replies to this email. > > > > event_seg-is-null.log is only a partial log, unfortunately. It doesn't contain the initial instance > of > > the problem, so I'm not sure if there is enough info to tell what went wrong. The next 2 logs are > > complete. > > > > I would appreciate if you can glean any clues to the problem from these logs. Thanks. > > > > -- > > Paul > > > > > -----Original Message----- > > > From: Paul Zimmerman > > > Sent: Tuesday, August 24, 2010 11:20 AM > > > To: 'Andiry Xu' > > > Cc: Sarah Sharp; linux-usb@xxxxxxxxxxxxxxx > > > Subject: RE: [PATCH][RFC] xhci fixes > > > > > > > From: Andiry Xu [mailto:andiry.xu@xxxxxxx] > > > > > > <snip> > > > > > > > But I haven't seen td bd415150 and following tds on the endpoint ring. > > > > I'm afraid the full endpoint ring is not printed, because I allocate 8 > > > > segments for isoc endpoint, but there is only one segment showed in the > > > > log. Perhaps you only print one segment of isoc endpoint ring? > > > > > > > > With your patch, every time when event_seg is NULL, you break out and > > > > returns. But event_seg will be NULL when a missed service interval event > > > > is encountered and it's quite normal for isoc transfer. Your patch may > > > > workaround the issue but it does not help to find the root cause. And > > > > suppose the do-while will not run infinity. ep->skip is cleared when > > > > irq_handler found the td on the ring, or when the td_list is empty. > > > > Since urb_enqueue needs to acquire the lock which is hold by > > > > irq_handler, it cannot insert tds to the ring. Eventually the td_list is > > > > empty, and ep->skip is clear. > > > > > > Hi Andiry, > > > > > > I have some good/bad news (depending on how you look at it). > > > > > > I have updated my debug code to print all the ring segments instead of just > > > one. > > > > > > However, our xHCI controller hardware was just updated to the latest version. > > > With this version, the "event_seg is NULL" case happens *much* less frequently > > > than before. So far, I have only been able to reproduce it once in over an > > > hour of intensive testing. Unfortunately, the debug messages had already been > > > flushed from the log by the time I realized it had occurred. > > > > > > Previously, it would happen after just a few startup/shutdown cycles of the > > > webcam app. > > > > > > So it's possible that the problematic case I was seeing was related to some > > > sort of hardware issue that has now been resolved. > > > > > > I will keep trying to capture a dmesg log from when it does happen, just to be > > > sure. > > > > > > -- > > > Paul
Attachment:
warn-in-xhci_find_new_dequeue_state.log.gz
Description: warn-in-xhci_find_new_dequeue_state.log.gz
