Re: port-i386/57662: StarTech ICUSB23208FD 8-Port USB-to-Serial Adapter Hub fails on Alix with NetBSD/i386 9.3

[Alexander Schreiber <als%thangorodrim.ch@localhost>]

On Tue, Oct 24, 2023 at 07:40:43AM +1100, matthew green wrote:
> Alexander Schreiber writes:
> > And I just did, I grabbed NetBSD 10.0_BETA i386 boot iso from:
> >
> > http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/202310212330Z/i386/installation/cdrom/boot.iso
> >
> > and installed it on another one of those Alix machines I've got kicking
> > around. Somewhat similar behaviour. I can do a few sessions with cu
> > (3-5 seems to be typical) and then, with the next session, cu just hangs
> > (sitting in status D, no output and so far I've been willing to wait a few
> > min but to no avail).
> >
> > top says:
> >
> > CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> >
> > Memory: 57M Act, 11M Wired, 13M Exec, 31M File, 138M Free
> > Swap: 512M Total, 512M Free / Pools: 22M Used
> >
> > and again, nothing in dmesg. 
> 
> so cu(1) is hung, let's find out why.  you can use crash(8)
> to do this fairly easily.
> 
> # crash
> crash> ps|grep cu
> 26171 26171 3   1       180   ffffa11149cde640                 cu poll
> crash> bt/a ffffa11149cde640
> trace: pid 26171 lid 26171 at 0xffffac019fc24d00
> sleepq_block() at sleepq_block+0x15e
> sel_do_scan() at sel_do_scan+0x62a
> pollcommon() at pollcommon+0xd2
> sys_poll() at sys_poll+0x57
> syscall() at syscall+0x1ae
> --- syscall (number 209) ---
> syscall+0x1ae:
> 
> where the argument to "bt/a" is the address ps provided.
> in my example, cu(1) is sitting in poll() like i'd expect,
> can you show what your cu(1) backtraces are?
> 
> from the back trace we'll have an idea on the next step.

Did that. Interestingly, what I did this time:
 - did one cu session, terminated it normally
 - got distracted for at least an hour
 - did another cu session, that promptly hung

invoked crash:

console# crash
Crash version 10.0_BETA, image version 10.0_BETA.
Kernel compiled without options LOCKDEBUG.
Output from a running system is unreliable.
crash> ps|grep cu
1524  1524 3   0   1000000           c260c640                 cu usbxfer
0       17 3   0       200           c1eaa100           lnxrcugc lnxrcugc
crash> bt/a c260c640
trace: pid 1524 lid 1524 at 0xce80ab18
sleepq_block(0,0,c14afda4,c14afda4,0,c1d43100,c1ec1808,c1d43100,c1f0ce80,c1d4310
0) at sleepq_block+0x138
cv_wait(c1edbe84,c1ec1808,c1edbe78,1ee4c25,0,2,23d6c,0,ce80abf8,ce80abf8) at cv_
wait+0xc6
usbd_transfer(c1edbe78,0,0,0,ce80abb0,0,8,8,8,c1edbe78) at usbd_transfer+0x15c
usbd_do_request_len(c1f0ce00,ce80abf8,0,0,0,0,1388,ce80ac3c,c03ed0df,c1f0ce00) a
t usbd_do_request_len+0xad
usbd_do_request(c1f0ce00,ce80abf8,0,40,1,0,4af,c1eaf00c,dd313180,ce80ac70) at us
bd_do_request+0x3f
uftdi_open(c1f14340,1,0,c1ef5c00,0,0,4200,1841,0,c1ef5c00) at uftdi_open+0x4e
ucomopen(4200,0,7,2000,c260c640,c0d28fe2,c22d17c0,0,c1f153c0,100) at ucomopen+0x
307
cdev_open(4200,0,7,2000,c260c640,d,c22db040,42,c22b8dc0,0) at cdev_open+0x11c
spec_open(ce80ad90,0,c116aed8,c22db040,7,c2cf8640,7,c1fc7000,ce80ae9c,c0d18b64) 
at spec_open+0x1ef
VOP_OPEN(c22db040,7,c2cf8640,7,c22db040,c2cf8640,c22db040,0,c1f1a590,c1fdd000) a
t VOP_OPEN+0x3e
vn_open(0,c1f1a590,10,7,0,ce80aed0,ce80aecb,ce80aed4,c1f1a590,c260c640) at vn_op
en+0x2ff
do_open(c260c640,0,c1f1a590,6,0,ce80af34,c260b5c0,0,c1f1a590,c260c640) at do_ope
n+0xa1
do_sys_openat(6,0,ce80af34,c14af694,ce80af9c,c049b4c6,c260c640,ce80af68,ce80af60
,c1f09b00) at do_sys_openat+0x72
sys_open(c260c640,ce80af68,ce80af60,c1f09b00,0,5,ce80af60,ce80af68,0,0) at sys_o
pen+0x2c
syscall() at syscall+0x1d6
--- syscall (number 5) ---
b8f54857:

I hope that is helpful. Let me know what else I can do to help.

Kind regards,
           Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison