NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/49831: kernel panic on close of ucom tty

The following reply was made to PR kern/49831; it has been noted by GNATS.

From: Nick Hudson <>
Subject: Re: kern/49831: kernel panic on close of ucom tty
Date: Sat, 25 Jun 2016 09:41:41 +0100

 On 06/25/16 09:15, Iain Hibbert wrote:
 >   anyway, I tried this on the T61p running a standard NetBSD amd64 7.99.29
 >   kernel and had a slightly different process but similar result. I plugged
 >   the serial/parallel adapter in and it attached as normal
 >   uhub7 at uhub4 port 3: vendor 0517 product 0606, class 9/0, rev 2.00/7.02, addr 2
 >   uhub7: single transaction translator
 >   uhub7: 2 ports with 0 removable, self powered
 >   ulpt0 at uhub7 port 1 configuration 1 interface 0
 >   ulpt0: Prolific Technology Inc. IEEE-1284 Controller, rev 1.00/2.02, addr 3, iclass 7/1
 >   ulpt0: using bi-directional mode
 >   uplcom0 at uhub7 port 2
 >   uplcom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 4
 >   ucom0 at uplcom0
 oh, so no umct(4) anymore?
 This device is still interesting, however.
 >   I then connected to the com port (nothing plugged in) with 'cu -l
 >   /dev/ttyU0' and disconnected ok .. tried again, and the system froze I was
 >   unable to see anything else -- bit of blind typing and I managed to
 >   reboot, all I could get from the message buffer was
 >   ulpt0: detached
 >   ulpt0: at uhub7 port 1 (addr 3) disconnected
 >   panic: kernel diagnostic assertion "xfer->ux_state == XFER_BUSY" failed: file "/var/cvs/NetBSD-current/src/sys/dev/usb/ehci.c", line 1573 xfer 0xfffffe8107880960 state 158
 More like a problem in the ulpt(4) code. I'll take a look.
 >   fatal breakpoint trap in supervisor mode
 >   trap type 1 code 0 rip ffffffff80114ae5 cs 8 rflags 246 cr2 75b607107068 ilevel 0 rsp fffffe8040defb00
 >   curlwp 0xfffffe81078865a0 pid 0.55 lowest kstack 0xfffffe8040dec2c0
 >   rebooting...
 >   so anyway, I booted your amd64 kernel and I have a slightly different
 >   problem with that, because the nouveau driver doesn't quite work on this
 >   laptop so the screen is unreadable (though I can see green/white blobs so
 >   I know its working ok inside :)
 >   anyway, the same process (although in single-user mode) and no panic. So,
 >   I'd say that something is good with your code!
 Bit early to say that without a umct(4) I'm afraid
 >   iain
 Thanks for testing

Home | Main Index | Thread Index | Old Index