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: gnats-bugs%netbsd.org@localhost
Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-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: Mon, 16 Oct 2023 01:51:48 +0200

 On Sun, Oct 15, 2023 at 09:35:02PM +0000, Manuel Bouyer wrote:
 > The following reply was made to PR port-i386/57662; it has been noted by GNATS.
 > 
 > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >         netbsd-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: Sun, 15 Oct 2023 23:31:07 +0200
 > 
 >  On Sun, Oct 15, 2023 at 08:45:01PM +0000, als%thangorodrim.ch@localhost wrote:
 >  > [...]
 >  > 
 >  > I can then connect via "cu -l /dev/ttyU0 -s 115200" to an attached device,
 >  > and disconnect via the "~." sequence. This works 1-2 times and then any further attempts to do so only yield "cu: link down" and then cu exiting.
 >  > 
 >  
 >  I've seen this with other USB a non-USB serial ports.
 >  Usually this is because the serial port is not completely closed (cu usually
 >  has 2 processes running, one may be left over when exiting).
 >  killing the leftover processes allows a new cu session to start
 
 The fact that:
  - upon device plug-in, I get a "fatal breakpoint trap in supervisor mode"
  - upon removing, waiting a few min and plugging the device back
    in I get "uhub1: autoconfiguration error: device problem, disabling port 1"
 tells me that this might not be the problem.
 
 I suspect either some state corruption in the kernel driver or (actually
 more likely) incorrect handling of device quirks (quirk being a polite
 way of saying the device does something broken). This might be a combination
 of USB host issues (it appears to work fine on a different h/w with
 amd64) and NetBSD not having as much developer time to deal with devices
 behaving oddly (it works with Linux on the same h/w).
 
 -- 
 "Opportunity is missed by most people because it is dressed in overalls and
  looks like work."                                      -- Thomas A. Edison