From owner-freebsd-usb@FreeBSD.ORG Sun Dec 19 21:46:21 2004 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 292F616A4CE for ; Sun, 19 Dec 2004 21:46:21 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4DC943D2F for ; Sun, 19 Dec 2004 21:46:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])iBJLkENb329926; Sun, 19 Dec 2004 16:46:19 -0500 Message-ID: <41C5F6A5.5000906@elischer.org> Date: Sun, 19 Dec 2004 13:46:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Steve Watt References: <200412190252.iBJ2q1eW002380@wattres.watt.com> In-Reply-To: <200412190252.iBJ2q1eW002380@wattres.watt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-usb@freebsd.org Subject: Re: panic w/ USB<->serial adapter and modem X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2004 21:46:21 -0000 Steve Watt wrote: > I've got a 5.3-STABLE (updated 19 Nov around 2000PST) machine that > has serious difficulty when I attempt to use the modems that are > attached via the Prolofic Technology PL2303 serial adapters. It > seems that the kernel panics when carrier drops, during the general > TTY cleanup. > > Here's a hand-transcribed trace from the one I saw this afternoon. > Note that I didn't bother writing down all of the addresses in > all of the functions, those are listed as "...". I include the > line number and source line from GDB (ex-post-facto) as well. > Some of the latter is guessing, since it wasn't a debug kernel. > > - - - 8< - - - hand-entered off my scribbled notes - - - This may be fixed in the ongoing 5 branch after 5.3 (and teh 6 branch (-current)) and in the newest 4.x too i think. There were problems in the abort code that have been fixed.. this may relate to your problem. > > panic: uhci_abort_xfer: not in process context > KDB: enter: panic > [ thread 100027 ] > kdb> trace > kdb_enter(...) > panic(...) at panic + 0xce > uhci_abort_xfer(c19f8b00,6,caca1b80,c05f328f,c19f8b00) at uhci_abort_xfer + 0x8b > 1954 if (xfer->device->bus->intr_context || !curproc) > 1955 panic("uhci_abort_xfer: not in process context"); > uhci_device_bulk_abort(...) at uhci_device_bulk_abort + 0x19 > 1919 uhci_abort_xfer(xfer, USBD_CANCELLED); > usbd_ar_pipe(...) at usbd_ar_pipe + 0x22 > 747 /* Make the HC abort it (and invoke the callback). */ > 748 pipe->methods->abort(xfer); > usbd_abort_pipe(..) at usbd_abort_pipe + 0x11 > 547 s = splusb(); > 548 err = usbd_ar_pipe(pipe); > ucomstopread(c156ad00,1,c1559e00,3,caca1bc8) at ucomstopread+0x28 > 1156 err = usbd_abort_pipe(sc->sc_bulkin_pipe); > ucomstop(...) at ucomstop+0x44 > 933 DPRINTF(("ucomstop: read\n")); > 934 ucomstopread(sc); > ttyflush(c1559e00,3,0,1,5) at ttyflush+0x43 > 1420 (*tp->t_stop)(tp, rw); > ttymodem(...) at ttymodem+0x194 > 1614 ttyflush(tp, FREAD | FWRITE); > ucom_status_change(c156ad00,caca1c4c,...) at ucom_status_change+0x73 > 759 ttyld_modem(tp, onoff); > uplcom_intr(c19f9900,c156ad00,0,0,1) at uplcom_intr+0x69 > 805 ucom_status_change(&sc->sc_ucom); > usb_transfer_complete(c19f9900,0,caca1cbc,a,c26cc00) at usb_transfer_complete+0x135 > 845 pipe->methods->done(xfer); > uhci_idone(c19f996c,0) at uhci_idone+0x11d > 1497 end: > 1498 usb_transfer_complete(xfer); > uhci_check_intr(c1595000,...) at uhci_check_intr+0x93 > 1372 usb_uncallout(ii->xfer->timeout_handle, uhci_timeout, ii); > 1373 uhci_idone(ii); > uhci_softintr(c1595000,...) at uhci_softintr+0x2b > 1303 LIST_FOREACH_SAFE(ii, &sc->sc_intrhead, list, nextii) > 1304 uhci_check_intr(sc, ii); > usb_schedsoftintr(c1595000,7058c,c15a0040,4,c146b380) at usb_schedsoftintr+0x12 > 859 bus->methods->soft_intr(bus); > uhci_intr1(c1595000,...) at uhci_intr1+0x18c > 1274 usb_schedsoftintr(&sc->sc_bus); > uhci_intr(c1595000,0,0,0,0) at uhci_intr+0x2e > 1189 return (uhci_intr1(sc)); > ithread_loop(...)... > fork_exit(...)... > fork_trampoline(...)... > > - - - >8 - - - hand-entered off my scribbled notes - - - > > So it's pretty clear, reading that over, that uhci_abort_xfer > *IS* being called from interrupt context, namely when carrier > drops. There's some kind of think-o happening in there, but > I'm not sure quite what to do about it. > > It also looks like there's some risk of ugly recursion, because > usb_transfer_complete is called from uhci_abort_xfer, but I really > haven't analyzed the code path well enough to be certain that > it's OK. > > My kernel config is pretty much GENERIC, and usbdevs -v looks > like: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00 > port 1 powered > port 2 powered > Controller /dev/usb1: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00 > port 1 addr 2: full speed, self powered, config 1, Generic USB Hub(0x9254), ALCOR(0x058f), rev 3.12 > port 1 addr 3: full speed, power 500 mA, config 1, PL2303 Serial adapter (ATEN/IOGEAR UC232A)(0x2303), Prolific Technology(0x067b), rev 2.02 > port 2 addr 4: full speed, power 500 mA, config 1, PL2303 Serial adapter (ATEN/IOGEAR UC232A)(0x2303), Prolific Technology(0x067b), rev 2.02 > port 3 addr 5: full speed, power 500 mA, config 1, PL2303 Serial adapter (ATEN/IOGEAR UC232A)(0x2303), Prolific Technology(0x067b), rev 2.02 > port 4 powered > port 2 powered > Controller /dev/usb2: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1.00 > port 1 powered > port 2 powered > > >