From owner-freebsd-usb@FreeBSD.ORG Thu Mar 12 18:55:07 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69804106566B for ; Thu, 12 Mar 2009 18:55:07 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (smtp.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id EAFE78FC19 for ; Thu, 12 Mar 2009 18:55:06 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n2CIAIrg003290 for ; Thu, 12 Mar 2009 12:10:20 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n2CHiLvl022921; Thu, 12 Mar 2009 11:44:21 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n2CHiLpN022918; Thu, 12 Mar 2009 11:44:21 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18873.18933.723897.835863@gromit.timing.com> Date: Thu, 12 Mar 2009 11:44:21 -0600 From: John Hein To: bug-followup@freebsd.org, artur.zabronski@gmail.com X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: usb@freebsd.org Subject: Re: usb/122539: kernel panic: ohci_abort_xfer: not in process context X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:55:07 -0000 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.