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

[Lexi Winter]

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]

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,

Post by Lexi Winter
hello,
i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for
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.
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]

(...)

initial_turbo
https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking

Post by Nuno Teixeira
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.
https://www.raspberrypi.com/documentation/computers/config_txt.html
Cheers,

Post by Lexi Winter
hello,
i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for
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.
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)

[Mark Millard]

Post by Lexi Winter
i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for
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.
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



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lexi Winter]

Post by Mark Millard

Post by Lexi Winter
uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2

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

thanks -- after setting this in config.txt, the problem seems to be
fixed.

hopefully this won't cause any overheating issues; none of my RPis have
fans, but they have fairly decent passive cooling, and are running
powerd on boot.

regards, lexi.