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

Hello,

If you got a fan in your rpi4 box, you could try to overclock it.
If not, there is a funcionality in config.txt to overclock it just for a
few seconds at boot time.

I can't remember the funtion but I'm looking at:
https://www.raspberrypi.com/documentation/computers/config_txt.html

Cheers,

Lexi Winter <[email protected]> escreveu (sábado, 30/03/2024 à(s) 19:45):

> hello,
>
> 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?
>
>         thanks, lexi.
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)