Public bug reported: On Ubuntu 26.04, the 7.0.0 kernel frequently adds ~63 seconds to boot because the kernel repeatedly tries and fails to enumerate a USB port during the initramfs phase, proceeding only after exhausting all retries. The 6.19.10 mainline kernel doesn't stall on the same hardware with the same broken port present. Reproduction / behavior: - Once the stall occurs, it then occurs on EVERY subsequent boot - the long ~60+ seconds loading screen happens every time - until I fully drain power (shut down, unplug the power cable, hold the power button ~30s, then plug back in and boot). A normal reboot or power-off does not clear it; only the full power drain does. - After a power drain, the next boot may be clean, but once the stall reappears even once, it again persists on every boot until the next power drain. - This is easy to hit on 7.0.0. On 6.19.10, on the same hardware, I do not see this behavior at all. - I have not isolated exactly what first triggers it on a given session; I am reporting the observed pattern: it latches on and persists across reboots until a full power drain resets it. Hardware: - CPU: AMD Ryzen 7 7700X - GPU: AMD Radeon RX 7900 XT / Navi 31 - Motherboard: ASRock B650M Pro RS WiFi, BIOS 4.20 - Root: NVMe (Lexar SSD NM710 2TB), ext4, no USB needed for root The failing port: - usb 1-8 on controller 0000:0d:00.0 (xhci_hcd). - It never enumerates: it cycles through "device descriptor read/64, error -110", "Device not responding to setup address", and "device not accepting address N, error -71", then "unable to enumerate USB device". - physical_location reports back / left / lower. It does not correspond to any usable socket I can find: my actual front ports enumerate as 1-6 and 1-5, and my working rear ports are on a different controller (0000:10:00.4). So 1-8 appears to be a phantom/dead endpoint on this controller. Boot time comparison (systemd-analyze), same machine, same disk, same broken port physically present: 6.19.10-061910-generic: initrd 2.160s (total 19.820s) 7.0.0-27-generic: initrd ~65-67s (total ~1min 38s) On 7.0.0, the kernel log shows the full retry cycle on usb 1-8 consuming the window from ~1.4s to ~65s, and dracut-initqueue finishes the instant the kernel gives up on the port: [ 1.408] usb 1-8: new high-speed USB device number 3 using xhci_hcd [ 6.880] usb 1-8: device descriptor read/64, error -110 [22.752] usb 1-8: device descriptor read/64, error -110 [28.897] usb 1-8: device descriptor read/64, error -110 [44.768] usb 1-8: device descriptor read/64, error -110 [44.877] usb usb1-port8: attempt power cycle [50.118] usb 1-8: Device not responding to setup address. [55.331] usb 1-8: device not accepting address 5, error -71 [60.510] usb 1-8: Device not responding to setup address. [65.723] usb 1-8: device not accepting address 6, error -71 [65.725] usb usb1-port8: unable to enumerate USB device [65.739] systemd[1]: Finished dracut-initqueue.service - dracut initqueue hook. During this whole window the boot splash stays at a low fallback resolution (simpledrm), because amdgpu does not load until after the initramfs completes. What differs between the kernels: - 6.19.10 reaches the root filesystem and proceeds in ~2s of initrd; it does not sit through a 60+ seconds USB retry cycle during boot, and the slow state does not keep recurring. - 7.0.0 blocks the initramfs for the full retry/timeout budget on this single failed port. Root is on NVMe and does not depend on USB at all, so nothing about reaching the root filesystem requires waiting on this port. Runtime note (not a boot fix): - Once booted, writing 1 to /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port8/disable stops the port retrying, but only after userspace is up, so it does not help the initramfs stall. Per-port quirks (quirks=0x01) and dracut cmdline/pre-trigger hooks did not prevent the boot-time stall in my testing. Expected: the kernel should not block boot for ~63s on a single USB port that fails to enumerate, especially when root is on NVMe and does not depend on USB. 6.19.10 demonstrates the faster behavior on identical hardware. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jun 28 19:10:17 2026 InstallationDate: Installed on 2026-05-01 (58 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp7s0Link: Not connected. MachineType: ASRock B650M Pro RS WiFi ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=b624231d-8e1e-4b2a-887d-4d219254360d ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/16/2026 dmi.bios.release: 5.41 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 4.20 dmi.board.asset.tag: Default string dmi.board.name: B650M Pro RS WiFi dmi.board.vendor: ASRock dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr4.20:bd04/16/2026:br5.41:svnASRock:pnB650MProRSWiFi:pvrDefaultstring:rvnASRock:rnB650MProRSWiFi:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:pfaDefaultstring: dmi.product.family: Default string dmi.product.name: B650M Pro RS WiFi dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: ASRock ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158569 Title: 7.0.0 kernel spends ~63s in initramfs retrying a non-enumerable USB port while 6.19.10 doesn't (same hardware) Status in linux package in Ubuntu: New Bug description: On Ubuntu 26.04, the 7.0.0 kernel frequently adds ~63 seconds to boot because the kernel repeatedly tries and fails to enumerate a USB port during the initramfs phase, proceeding only after exhausting all retries. The 6.19.10 mainline kernel doesn't stall on the same hardware with the same broken port present. Reproduction / behavior: - Once the stall occurs, it then occurs on EVERY subsequent boot - the long ~60+ seconds loading screen happens every time - until I fully drain power (shut down, unplug the power cable, hold the power button ~30s, then plug back in and boot). A normal reboot or power-off does not clear it; only the full power drain does. - After a power drain, the next boot may be clean, but once the stall reappears even once, it again persists on every boot until the next power drain. - This is easy to hit on 7.0.0. On 6.19.10, on the same hardware, I do not see this behavior at all. - I have not isolated exactly what first triggers it on a given session; I am reporting the observed pattern: it latches on and persists across reboots until a full power drain resets it. Hardware: - CPU: AMD Ryzen 7 7700X - GPU: AMD Radeon RX 7900 XT / Navi 31 - Motherboard: ASRock B650M Pro RS WiFi, BIOS 4.20 - Root: NVMe (Lexar SSD NM710 2TB), ext4, no USB needed for root The failing port: - usb 1-8 on controller 0000:0d:00.0 (xhci_hcd). - It never enumerates: it cycles through "device descriptor read/64, error -110", "Device not responding to setup address", and "device not accepting address N, error -71", then "unable to enumerate USB device". - physical_location reports back / left / lower. It does not correspond to any usable socket I can find: my actual front ports enumerate as 1-6 and 1-5, and my working rear ports are on a different controller (0000:10:00.4). So 1-8 appears to be a phantom/dead endpoint on this controller. Boot time comparison (systemd-analyze), same machine, same disk, same broken port physically present: 6.19.10-061910-generic: initrd 2.160s (total 19.820s) 7.0.0-27-generic: initrd ~65-67s (total ~1min 38s) On 7.0.0, the kernel log shows the full retry cycle on usb 1-8 consuming the window from ~1.4s to ~65s, and dracut-initqueue finishes the instant the kernel gives up on the port: [ 1.408] usb 1-8: new high-speed USB device number 3 using xhci_hcd [ 6.880] usb 1-8: device descriptor read/64, error -110 [22.752] usb 1-8: device descriptor read/64, error -110 [28.897] usb 1-8: device descriptor read/64, error -110 [44.768] usb 1-8: device descriptor read/64, error -110 [44.877] usb usb1-port8: attempt power cycle [50.118] usb 1-8: Device not responding to setup address. [55.331] usb 1-8: device not accepting address 5, error -71 [60.510] usb 1-8: Device not responding to setup address. [65.723] usb 1-8: device not accepting address 6, error -71 [65.725] usb usb1-port8: unable to enumerate USB device [65.739] systemd[1]: Finished dracut-initqueue.service - dracut initqueue hook. During this whole window the boot splash stays at a low fallback resolution (simpledrm), because amdgpu does not load until after the initramfs completes. What differs between the kernels: - 6.19.10 reaches the root filesystem and proceeds in ~2s of initrd; it does not sit through a 60+ seconds USB retry cycle during boot, and the slow state does not keep recurring. - 7.0.0 blocks the initramfs for the full retry/timeout budget on this single failed port. Root is on NVMe and does not depend on USB at all, so nothing about reaching the root filesystem requires waiting on this port. Runtime note (not a boot fix): - Once booted, writing 1 to /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port8/disable stops the port retrying, but only after userspace is up, so it does not help the initramfs stall. Per-port quirks (quirks=0x01) and dracut cmdline/pre-trigger hooks did not prevent the boot-time stall in my testing. Expected: the kernel should not block boot for ~63s on a single USB port that fails to enumerate, especially when root is on NVMe and does not depend on USB. 6.19.10 demonstrates the faster behavior on identical hardware. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jun 28 19:10:17 2026 InstallationDate: Installed on 2026-05-01 (58 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp7s0Link: Not connected. MachineType: ASRock B650M Pro RS WiFi ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=b624231d-8e1e-4b2a-887d-4d219254360d ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/16/2026 dmi.bios.release: 5.41 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 4.20 dmi.board.asset.tag: Default string dmi.board.name: B650M Pro RS WiFi dmi.board.vendor: ASRock dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr4.20:bd04/16/2026:br5.41:svnASRock:pnB650MProRSWiFi:pvrDefaultstring:rvnASRock:rnB650MProRSWiFi:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:pfaDefaultstring: dmi.product.family: Default string dmi.product.name: B650M Pro RS WiFi dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: ASRock To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158569/+subscriptions
Комментариев нет:
Отправить комментарий