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

[Nick Hudson <skrll%netbsd.org@localhost>]

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

Nick