Summary: | [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci_abort_xfer: not in process context | ||
---|---|---|---|
Product: | Base System | Reporter: | Artur Zabronski <artur.zabronski> |
Component: | usb | Assignee: | freebsd-usb (Nobody) <usb> |
Status: | Open --- | ||
Severity: | Affects Only Me | Keywords: | crash |
Priority: | Normal | ||
Version: | 7.0-RELEASE | ||
Hardware: | Any | ||
OS: | Any |
Description
Artur Zabronski
2008-04-07 18:40:02 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-usb Over to maintainer(s). 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. The code to pull the patch out of the text of the last submission for the web page was too agressive and pulled some text into the patch blurb. So it's not missed, here is that last bit of text separately... ====================== 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. ====================== For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Keyword: crash – in lieu of summary line prefix: [panic] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi> |