panic w/ USB<->serial adapter and modem

[Steve Watt]

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 - - -

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



-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
   Free time?  There's no such thing.  It just comes in varying prices...