On 27/04/15(Mon) 22:45, Remi Locherer wrote: > On Mon, Apr 27, 2015 at 03:13:06PM +0200, Martin Pieuchot wrote: > > This trace tells use that the pipe is no longer valid, which means that > > the device has been removed but a xfer is still referenced by ehci. > > > > The output of "ps" could help understand what's going wrong in such > > case. If you can, please get it next time :) > > > > If you think you can reproduce this bug too, here's a diff that would > > get us a useful trace: > > It seams to be easier to trigger this bug than the first one.
What did you do to trigger it? > ddb trace and ps output: > > https://relo.ch/urtwncrash_trace_part1.jpg > https://relo.ch/urtwncrash_trace_part2.jpg > https://relo.ch/urtwncrash_ps_part1.jpg > https://relo.ch/urtwncrash_ps_part2.jpg > > Unfortunately "boot reboot" in ddb did not work so I had to upload > the photos. But at least one line number appeared in the output so now I > know how to build a kernel with debug symbols ;) > > > > > > Index: usbdi.c > > =================================================================== > > RCS file: /cvs/src/sys/dev/usb/usbdi.c,v > > retrieving revision 1.81 > > diff -u -p -r1.81 usbdi.c > > --- usbdi.c 14 Mar 2015 03:38:50 -0000 1.81 > > +++ usbdi.c 27 Apr 2015 13:08:33 -0000 > > @@ -824,10 +824,8 @@ usb_insert_transfer(struct usbd_xfer *xf > > DPRINTFN(5,("usb_insert_transfer: pipe=%p running=%d timeout=%d\n", > > pipe, pipe->running, xfer->timeout)); > > #ifdef DIAGNOSTIC > > - if (xfer->busy_free != XFER_FREE) { > > - printf("%s: xfer=%p not free\n", __func__, xfer); > > - return (USBD_INVAL); > > - } > > + if (xfer->busy_free != XFER_FREE) > > + panic("%s: xfer=%p not free\n", __func__, xfer); > > xfer->busy_free = XFER_ONQU; > > #endif > > s = splusb(); > > >
