Date: Sun, 19 Dec 2004 13:46:13 -0800 From: Julian Elischer <julian@elischer.org> To: Steve Watt <steve@Watt.COM> Cc: freebsd-usb@freebsd.org Subject: Re: panic w/ USB<->serial adapter and modem Message-ID: <41C5F6A5.5000906@elischer.org> In-Reply-To: <200412190252.iBJ2q1eW002380@wattres.watt.com> References: <200412190252.iBJ2q1eW002380@wattres.watt.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C5F6A5.5000906>