Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT

On Mar 30, 2024, at 12:44, Lexi Winter <lexi@le-fay.org> wrote:

> i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for
> the root disk:
> 
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa)
> ugen0.3: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA> at usbus0
> umass0 on uhub1
> umass0: <ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA, class 0/0, rev 2.10/1.00, addr 2> on usbus0
> umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:1:0: Attached to scbus1
> da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
> da0: <ASM1153U ASM1153USB3.0TOS 0> Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 123456789019
> da0: 40.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=0x2<NO_6_BYTE>
> 
> when connected via USB 2, this works fine.  when connected via USB 3.0,
> the device sometimes fails to attach on boot, causing mountroot to fail.
> i can reproduce this reliably with both GENERIC-NODEBUG and a custom
> modular kernel, and sometimes (but not every boot) with GENERIC.
> 
> when the problem happens, with USB_DEBUG enabled, the kernel logs:
> 
> uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2
> 
> however, if i boot with "boot -v", the device is reliably detected
> correctly.  since -v shouldn't cause any functional changes, i suspect
> this may be some kind of timing issue.
> 
> i've tried increasing some of the USB timings (hw.usb.timings.*) but
> this didn't seem to have any effect.  is there anything else i could try
> that might affect this, or is this perhaps a known issue?
> 

Here is my config.txt material related to such issues:

#
# Local addition that avoids USB3 SSD boot failures that look like:
#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
# WARNING, not sufficient for "boot -s": that needs the full force_turbo=1
initial_turbo=60

As far as I can tell, without using one of the turbo settings, the
more modern RPI firmware is varying the speed of the clock in the early
boot time frame and FreeBSD is working in a way that requires more
uniformity for such. (May be delays based on just loop counting?)


===
Mark Millard
marklmi at yahoo.com