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

[matthew green <mrg%eterna.com.au@localhost>]

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.

thanks.


.mrg.