From owner-freebsd-usb@FreeBSD.ORG Tue Apr 12 01:00:52 2005 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B70F16A4CE for ; Tue, 12 Apr 2005 01:00:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2CF343D3F for ; Tue, 12 Apr 2005 01:00:51 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3C10psW096595 for ; Tue, 12 Apr 2005 01:00:51 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j3C10pnK096594; Tue, 12 Apr 2005 01:00:51 GMT (envelope-from gnats) Date: Tue, 12 Apr 2005 01:00:51 GMT Message-Id: <200504120100.j3C10pnK096594@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Ian Dowse Subject: Re: usb/79436: Panic: ohci_abort_xfer: not in process context X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ian Dowse List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 01:00:52 -0000 The following reply was made to PR usb/79436; it has been noted by GNATS. From: Ian Dowse To: Anthony Ginepro Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: usb/79436: Panic: ohci_abort_xfer: not in process context Date: Tue, 12 Apr 2005 01:54:04 +0100 In message <200504020537.j325buK8001163@renaissance.homeip.net>, Anthony Ginepr o writes: >When plugging T3 in craddle, the kernel panics in a few seconds after >(due to some action in ppp), it either get caught in one of this panic strings >: >- ohci_abort_xfer: not in process context >- page fault Hi, Would you be able to try the following patch to see if it helps? I'm not sure if it will solve the problem with the OHCI controller, as the ucom device is re-using a transfer from the completion callback, which is not generally safe, and the OHCI controller appears to handle this the worst. If it doesn't help, or just changes into a different panic, you could try applying the patch from http://people.freebsd.org/~iedowse/releng_5_xfer_reuse.diff in addition to the patch below. Ian Index: ucom.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ucom.c,v retrieving revision 1.51.2.2 diff -u -r1.51.2.2 ucom.c --- ucom.c 30 Jan 2005 01:00:10 -0000 1.51.2.2 +++ ucom.c 10 Apr 2005 18:08:28 -0000 @@ -381,6 +381,7 @@ (minor(dev) & UCOM_CALLOUT_MASK)) ttyld_modem(tp, 1); + sc->sc_state |= UCS_RXSTOP; ucomstartread(sc); } @@ -929,7 +930,7 @@ DPRINTF(("ucomstop: %d\n", flag)); - if (flag & FREAD) { + if ((flag & FREAD) && (sc->sc_state & UCS_RXSTOP) == 0) { DPRINTF(("ucomstop: read\n")); ucomstopread(sc); ucomstartread(sc); @@ -1009,10 +1010,9 @@ DPRINTF(("ucomstartread: start\n")); - sc->sc_state &= ~UCS_RXSTOP; - - if (sc->sc_bulkin_pipe == NULL) + if (sc->sc_bulkin_pipe == NULL || (sc->sc_state & UCS_RXSTOP) == 0) return (USBD_NORMAL_COMPLETION); + sc->sc_state &= ~UCS_RXSTOP; usbd_setup_xfer(sc->sc_ixfer, sc->sc_bulkin_pipe, (usbd_private_handle)sc, @@ -1021,7 +1021,8 @@ USBD_NO_TIMEOUT, ucomreadcb); err = usbd_transfer(sc->sc_ixfer); - if (err != USBD_IN_PROGRESS) { + if (err && err != USBD_IN_PROGRESS) { + sc->sc_state |= UCS_RXSTOP; DPRINTF(("ucomstartread: err = %s\n", usbd_errstr(err))); return (err); } @@ -1046,11 +1047,13 @@ if (!(sc->sc_state & UCS_RXSTOP)) printf("%s: ucomreadcb: %s\n", USBDEVNAME(sc->sc_dev), usbd_errstr(status)); + sc->sc_state |= UCS_RXSTOP; if (status == USBD_STALLED) usbd_clear_endpoint_stall_async(sc->sc_bulkin_pipe); /* XXX we should restart after some delay. */ return; } + sc->sc_state |= UCS_RXSTOP; usbd_get_xfer_status(xfer, NULL, (void **)&cp, &cc, NULL); DPRINTF(("ucomreadcb: got %d chars, tp = %p\n", cc, tp));