Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
Date: Sun, 31 Mar 2024 19:03:53 UTC
(...) initial_turbo https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking Nuno Teixeira <eduardo@freebsd.org> escreveu (domingo, 31/03/2024 à(s) 19:59): > 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 <lexi@le-fay.org> 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) > -- Nuno Teixeira FreeBSD Committer (ports)