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

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

From: matthew green <mrg%eterna.com.au@localhost>
To: Alexander Schreiber <als%thangorodrim.ch@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: Thu, 26 Oct 2023 08:45:34 +1100

 > 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 lnxrcug=
 c
 > crash> bt/a c260c640
 > trace: pid 1524 lid 1524 at 0xce80ab18
 > sleepq_block(0,0,c14afda4,c14afda4,0,c1d43100,c1ec1808,c1d43100,c1f0ce80=
 ,c1d43100) 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,c1f=
 0ce00) at usbd_do_request_len+0xad
 > usbd_do_request(c1f0ce00,ce80abf8,0,40,1,0,4af,c1eaf00c,dd313180,ce80ac7=
 0) at usbd_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 uco=
 mopen+0x307
 [ ... ]
 >
 > I hope that is helpful. Let me know what else I can do to help.
 
 OK, so seems like a transfer isn't completing like it should.
 
 can you build a kernel with USB_DEBUG, UFTDI_DEBUG, which ever of
 XHCI_DEBUG / UHCI_DEBUG / OHCI_DEBUG / EHCI_DEBUG the ufdti is
 attached to, reboot without them plugged in, set the various
 sysctl that will be eg hw.usb.debug / hw.xhci.debug / etc, to 1,
 plug the devies in and try to trigger a hang.  when it hangs, use
 "vmstat -u usbhist" to obtain the usb history which should provide
 a bunch of useful data to what has happened.
 
 usbd_xfer_schedule_timeout() should have setup a timeout for this,
 the default would be 5 i think with this via usbd_do_request().
 
 
 .mrg.