Date: Thu, 12 Mar 2009 11:44:21 -0600 From: John Hein <jhein@timing.com> To: bug-followup@freebsd.org, artur.zabronski@gmail.com Cc: usb@freebsd.org Subject: Re: usb/122539: kernel panic: ohci_abort_xfer: not in process context Message-ID: <18873.18933.723897.835863@gromit.timing.com>
next in thread | raw e-mail | index | archive | help
Note: this is not specific to ohci or the device originally used in
this PR. The problem is more generic.
This happens for us when hardware flow control is turned on when using
a usb serial device (specifically an ftdi based one). Eventually if
hardware flow has to kick in and RTS is to be set, uftdi_set() is
called in uftdi.c (old usb stack).
In uftdi_set() there is this...
(void)usbd_do_request(ucom->sc_udev, &req, NULL);
Since we're calling this from the interrupt context, the response
to the request times out (because the reply is not processed), the
ohci_abort_xfer which performas the panic because we're not in
the process context.
Here is a patch that uses the usbd_do_request_async() call (instead of the
synchronous version) to assert flow control when the input buffer reaches
the highwater mark (which is detected from within interupt context).
(patch against today's version of uftdi.c in the old usb stack)
Index: sys/legacy/dev/usb/uftdi.c
===================================================================
RCS file: /base/FreeBSD-CVS/src/sys/legacy/dev/usb/uftdi.c,v
retrieving revision 1.1
diff -u -p -r1.1 uftdi.c
--- uftdi.c 23 Feb 2009 18:16:17 -0000 1.1
+++ uftdi.c 12 Mar 2009 17:34:27 -0000
@@ -557,7 +557,7 @@ uftdi_set(void *vsc, int portno, int reg
DPRINTFN(2,("uftdi_set: reqtype=0x%02x req=0x%02x value=0x%04x "
"index=0x%04x len=%d\n", req.bmRequestType, req.bRequest,
UGETW(req.wValue), UGETW(req.wIndex), UGETW(req.wLength)));
- (void)usbd_do_request(ucom->sc_udev, &req, NULL);
+ (void)usbd_do_request_async(ucom->sc_udev, &req, NULL);
}
static int
This is not specific to FTDI devices. It would probably be better to
handle this in the usb serial layer. Whatever better fix someone
comes up with should be merged to 7.x if possible (and 6).
I have not yet looked to see if the new usb stack has the same
problem. Please let me know if someone does this analysis.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18873.18933.723897.835863>