On Thu, May 13, 2010 at 02:02:58PM -0700, Sarah Sharp wrote:
> On Tue, May 11, 2010 at 07:24:42AM -0700, Sarah Sharp wrote:
> > On Tue, May 11, 2010 at 04:16:54PM +0800, Andiry Xu wrote:
> > > Hi Sarah,
> > >
> > > This is v5 resend of xHCI isoc supporting patchset. They're based on
> > > your master branch, commit 8e6632cd. I used "git am --3way" to apply the
> > > patches successfully. Please let me know if you still cannot apply the
> > > patches.
> >
> > They applied! Thanks Andiry.
>
> Hi Andiry,
>
> I did a bit of testing this morning with your patches. The good news is
> that my high speed camera now works, and I can switch back and forth
> between the high speed and full speed cameras in cheese.
>
> The bad news is that my machine crashed during some more intensive
> testing. I had a USB3 hard drive attached to the root hub and a single
> TT high speed hub attached to another root hub, with a FS and HS webcam
> and a FS audio device. I was watching video from the high speed webcam
> and tried to kill (ctrl+c) a `cp` of my kernel git tree to the device.
> That successfully stopped, but the whole system hung when I tried to
> unmount the USB3 drive.
>
> I'm not sure what the cause is yet, as my log file got corrupted (and of
> course I didn't have netconsole working at the time). I'm going to try to
> reproduce this tomorrow, as I need to focus on spec review for the rest
> of the day.
Hi Andiry,
I've been able to grab the oops message out after turning off a lot of
debugging so that I could use netconsole. The modifications I made to turn off
debugging are on my amd-isoc branch. This time the oops was triggered
with just a HS webcam and a FS webcam plugged into a HS hub.
The dmesg is attached. The first thing I notice is that you're giving back URB
ffff88012fe9f000 twice, any idea how that could happen?
When I ran the trimmed oops message through scripts/markup_oops.pl, got
the following output:
No vmlinux specified, assuming /lib/modules/2.6.34-rc7/build/vmlinux
break;
case TRB_TYPE(TRB_TRANSFER):
ret = handle_tx_event(xhci, &event->trans_event);
if (ret < 0)
xhci->error_bitmask |= 1 << 9;
ffffffffa030179e: 80 cc 02 or $0x2,%ah
ffffffffa03017a1: 89 83 c0 09 00 00 mov %eax,0x9c0(%rbx) | %ebx = ffff88012e146220
ffffffffa03017a7: b8 01 00 00 00 mov $0x1,%eax | %eax => ffff88012fe9e800
ffffffffa03017ac: e9 af f3 ff ff jmpq ffffffffa0300b60 <xhci_handle_event+0xa0>
ffffffffa03017b1: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) | %eax = ffff88012fe9e800
int skip_td = 0;
union xhci_trb *cur_trb;
struct xhci_segment *cur_seg;
urb_priv = td->urb->hcpriv;
idx = urb_priv->td_cnt;
ffffffffa03017b8: 48 8b 50 08 mov 0x8(%rax),%rdx | %eax = ffff88012fe9e800 %edx => 0
*ffffffffa03017bc: 8b 4a 04 mov 0x4(%rdx),%ecx | %edx = 0 %ecx = ffff8800b7dc7680 <--- faulting instruction
status = 0;
if (ep->skip) {
ffffffffa03017bf: 4b 8d 54 ad 00 lea 0x0(%r13,%r13,4),%rdx
ffffffffa03017c4: 48 8d 14 92 lea (%rdx,%rdx,4),%rdx
ffffffffa03017c8: 41 80 bc d7 e0 00 00 cmpb $0x0,0xe0(%r15,%rdx,8)
ffffffffa03017cf: 00 00
ffffffffa03017d1: 0f 85 bf 00 00 00 jne ffffffffa0301896 <xhci_handle_event+0xdd6>
-EREMOTEIO;
else
td->urb->iso_frame_desc[idx].status = 0;
} else {
/* handle completion code */
switch (trb_comp_code) {
ffffffffa03017d7: 83 7d cc 1f cmpl $0x1f,-0x34(%rbp)
ffffffffa03017db: 0f 86 e4 01 00 00 jbe ffffffffa03019c5 <xhci_handle_event+0xf05>
case COMP_STOP:
So it looks like the urb_priv might be NULL. If you're giving back URBs
that have already been given back, then that could be the cause.
Let me know if you have any patches I can try to fix this.
Sarah Sharp
Attachment:
isoc-dmesg.tar.gz
Description: Binary data
