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 09:14:45 +0200

 On Mon, Oct 16, 2023 at 01:30:02AM +0000, David H. Gutteridge wrote:
 > The following reply was made to PR port-i386/57662; it has been noted by GNATS.
 > 
 > From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > 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 21:28:05 -0400
 > 
 >  On Mon, 16 Oct 2023 at 01:51:48 +0200, Alexander Schreiber wrote:
 >  >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 por=
 >  t 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 combinati=
 >  on
 >  >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).
 >  
 >  You don't mention what USB controller details are specific to this
 >  hardware in question (e.g., dmesg excerpt of that part). Separately,
 >  have you tried a -current kernel?
 
 I haven't tried -current, no.
 
 As for machine info, here is the full dmesg:
 
 [     1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
 [     1.000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
 [     1.000000]     2018, 2019, 2020, 2021, 2022
 [     1.000000]     The NetBSD Foundation, Inc.  All rights reserved.
 [     1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
 [     1.000000]     The Regents of the University of California.  All rights reserved.
 
 [     1.000000] NetBSD 9.3 (KHAZAD_DUM) #3: Wed Aug 17 18:46:46 UTC 2022
 [     1.000000]         root%khazad-dum.angband.thangorodrim.de@localhost:/net/build/khazad-dum/obj/sys/arch/i386/compile/KHAZAD_DUM
 [     1.000000] total memory = 255 MB
 [     1.000000] avail memory = 242 MB
 [     1.000000] rnd: seeded with 256 bits
 [     1.000000] timecounter: Timecounters tick every 10.000 msec
 [     1.000000] Kernelized RAIDframe activated
 [     1.000000] running cgd selftest aes-xts-256 aes-xts-512 done
 [     1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
 [     1.000003] Generic PC
 [     1.000003] mainbus0 (root)
 [     1.000003] Firmware Error (ACPI): A valid RSDP was not found (20190405/tbxfroot-261)
 [     1.000003] autoconfiguration error: acpi_probe: failed to initialize tables
 [     1.000003] ACPI Error: Could not remove SCI handler (20190405/evmisc-312)
 [     1.000003] cpu0 at mainbus0
 [     1.000003] cpu0: Geode(TM) Integrated Processor by AMD PCS, id 0x5a2
 [     1.000003] cpu0: package 0, core 0, smt 0
 [     1.000003] pci0 at mainbus0 bus 0: configuration mode 1
 [     1.000003] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
 [     1.000003] pchb0 at pci0 dev 1 function 0: vendor 1022 product 2080 (rev. 0x33)
 [     1.000003] glxsb0 at pci0 dev 1 function 2: RNG AES
 [     1.000003] vr0 at pci0 dev 9 function 0: vendor 1106 product 3053 (rev. 0x96)
 [     1.000003] vr0: interrupting at irq 10
 [     1.000003] vr0: Ethernet address 00:0d:b9:19:a3:44
 [     1.000003] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
 [     1.000003] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 [     1.000003] vr1 at pci0 dev 11 function 0: vendor 1106 product 3053 (rev. 0x96)
 [     1.000003] vr1: interrupting at irq 15
 [     1.000003] vr1: Ethernet address 00:0d:b9:19:a3:45
 [     1.000003] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
 [     1.000003] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 [     1.000003] gcscpcib0 at pci0 dev 15 function 0: vendor 1022 product 2090 (rev. 0x03)
 [     1.000003] timecounter: Timecounter "gcscpcib0" frequency 3579545 Hz quality 1000
 [     1.006160] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
 [     1.006160] gpio0 at gcscpcib0: 32 pins
 [     1.006160] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE Controller (rev. 0x01)
 [     1.006160] viaide0: bus-master DMA support present
 [     1.006160] viaide0: primary channel wired to compatibility mode
 [     1.006160] viaide0: primary channel interrupting at irq 14
 [     1.006160] atabus0 at viaide0 channel 0
 [     1.006160] viaide0: secondary channel wired to compatibility mode
 [     1.006160] viaide0: secondary channel ignored (disabled)
 [     1.006160] ohci0 at pci0 dev 15 function 4: vendor 1022 product 2094 (rev. 0x02)
 [     1.006160] ohci0: interrupting at irq 12
 [     1.006160] ohci0: OHCI version 1.0, legacy support
 [     1.006160] usb0 at ohci0: USB revision 1.0
 [     1.006160] gcscehci0 at pci0 dev 15 function 5: vendor 1022 product 2095 (rev. 0x02)
 [     1.006160] gcscehci0: interrupting at irq 12
 [     1.006160] gcscehci0: EHCI version 1.0
 [     1.006160] gcscehci0: 1 companion controller, 4 ports: ohci0
 [     1.006160] usb1 at gcscehci0: USB revision 2.0
 [     1.006160] isa0 at gcscpcib0
 [     1.006160] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
 [     1.006160] com0: console
 [     1.006160] com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
 [     1.006160] attimer0 at isa0 port 0x40-0x43
 [     1.006160] pcppi0 at isa0 port 0x61
 [     1.006160] midi0 at pcppi0: PC speaker
 [     1.006160] sysbeep0 at pcppi0
 [     1.006160] attimer0: attached to pcppi0
 [     1.006160] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
 [     1.599963] uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
 [     1.610805] uhub0: 4 ports with 4 removable, self powered
 [     1.610805] uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
 [     1.610805] uhub1: 4 ports with 4 removable, self powered
 [     1.619966] IPsec: Initialized Security Association Processing.
 [     4.590009] wd0 at atabus0 drive 0
 [     4.590009] wd0: <SanDisk SDCFX3-008G>
 [     4.602862] wd0: drive supports 4-sector PIO transfers, LBA addressing
 [     4.602862] wd0: 7815 MB, 15880 cyl, 16 head, 63 sec, 512 bytes/sect x 16007040 sectors
 [     4.610660] wd0: 32-bit data port
 [     4.610660] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66)
 [     4.610660] wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 4 (Ultra/66) (using DMA)
 [     4.620014] WARNING: 1 error while detecting hardware; check system log.
 [     4.630593] boot device: wd0
 [     4.630593] root on wd0a dumps on wd0b
 [     4.640012] root file system type: ffs
 [     4.640012] kern.module.path=/stand/i386/9.3/modules
 
 >  
 >  While I don't know if there's an overlap here, there have been issues
 >  (with memory fragmentation) that can cause USB devices to not work in
 >  some contexts (on some hardware). E.g., if I plug a USB 3 external
 >  hard drive into a Raspberry Pi 3B+ on 9.3_STABLE, it fails to attach,
 >  whereas there are no such issues on a typical amd64 laptop also
 >  running 9.3_STABLE (different arch, different USB controller, 8x
 >  difference in RAM). See for instance
 >  http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=3D54977
 
 Invalid PR number, I assume you meant 54977? And while I can see memory
 fragmentation being an issue with block devices, I wouldn't expect a
 serial device to need that much memory to run into it, especially on
 a freshly booted machine that runs little else (sshd, ntpd). Although
 yes, this machine only does have 256M of RAM, so .. maybe?
 
 Kind regards,
            Alex.
 -- 
 "Opportunity is missed by most people because it is dressed in overalls and
  looks like work."                                      -- Thomas A. Edison