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 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: at usbus0 > umass0 on uhub1 > umass0: 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: 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 > > 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
Re: 15.0 on RPi4, USB broken: uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
(...) initial_turbo https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking Nuno Teixeira 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 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: at usbus0 >> umass0 on uhub1 >> umass0: > 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: 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 >> >> 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)
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 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: at usbus0 > umass0 on uhub1 > umass0: 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: 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 > > 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)
Re: Multiple issues with current (kldload failures, missing CTF stuff, pty issues, ...)
Am 2024-03-29 18:21, schrieb Alexander Leidinger: Am 2024-03-29 18:13, schrieb Mark Johnston: On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote: Hi, sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work (see below for the issue). As the monthly stabilisation pass didn't find obvious issues, it is something related to my setup: - not a generic kernel - very modular kernel (as much as possible as a module) - bind_now (a build without fails too, tested with clean /usr/obj) - ccache (a build without fails too, tested with clean /usr/obj) - kernel retpoline (build without in progress) - userland retpoline (build without in progress) - kernel build with WITH_CTF / DDB_CTF (next one to test if it isn't retpoline) - -fno-builtin - CPUFLAGS=native (except for stuff in /usr/src/sys/boot) - malloc production - COPTFLAGS= -O2 -pipe The issue is, that kernel modules load OK from loader, but once it starts init any module fails to load (e.g. via autodetection of hardware or rc.conf kld_list) with the message that the kernel and module versions are out of sync and the module refuses to load. What is the exact revision you're running? There were some unrelated changes to the kernel linker around the same time. The working src is from 2024-03-11-094351 (GMT+0100). The failing src was fetched after Glebs stabilization week message (and todays src before the sound stuff still fails). Retpoline wasn't the cause, next test is the CTF stuff in the kernel... A rather obscure problem was causing this. The "last" BE had canmount set to "on" instead of "noauto". No idea how this happened, but this resulted in the "last" BE to be mounted on "zfs mount -a" on top of the current BE. This means that all modules loaded after the zfs rc script has run was loading old kernel modules and the error message of kernel version mismatch was correct. I fiund the issue while bisecting the tree and suddenly the error message went away but the new issue of missing dev entries popped up (/dev was mounted correctly on the booting dataset, but the last BE was mounted on top of it and /dev went empty...). It looks to me like bectl was doing this (from "zpool history")... 2024-03-11.14:16:31 zpool set bootfs=rpool/ROOT/2024-03-11-094351 rpool 2024-03-11.14:16:31 zfs set canmount=noauto rpool/ROOT/2024-01-18-092730 2024-03-11.14:16:31 zfs set canmount=noauto rpool/ROOT/2024-02-10-144617 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-11-212006 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-16-082836 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-24-140211 2024-03-11.14:16:32 zfs set canmount=noauto rpool/ROOT/2024-02-24-140211_ok 2024-03-11.14:16:33 zfs set canmount=on rpool/ROOT/2024-03-11-094351 2024-03-11.14:16:33 zfs promote rpool/ROOT/2024-03-11-094351 2024-03-11.14:17:03 zfs destroy -r rpool/ROOT/2024-02-24-140211_ok I surely didn't do the "zfs set canmount=..." for those by hand. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
