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

The following reply was made to PR port-i386/57662; it has been noted by GNATS.

From: Alexander Schreiber <als%thangorodrim.ch@localhost>
To: matthew green <mrg%eterna.com.au@localhost>
Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Subject: Re: port-i386/57662: StarTech ICUSB23208FD 8-Port USB-to-Serial
 Adapter Hub fails on Alix with NetBSD/i386 9.3
Date: Wed, 25 Oct 2023 01:06:51 +0200

 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