You are not logged in.
On boot of ArchLinux32 2024.07.10 on an old 32-bit laptop, it successfully shows the boot menu, starts the kernel, and then hangs. The terminal is flooded with
Probing EDD (edd=off to disable)... ok
uhci_hcd 0000:00:1d.0: request interrupt 9 failed
...: init 0000:00:1d.0 fail, -16
...: probe with driver uhci_hcd failed with error -16
genirq: Flags mismatch irq 9. 00000080 (uhci_hcd:usb1) vs. 00002080 (acpi)
ehci-pci 0000:00:1d.7: request interrupt 9 failed
...: init 0000:00:1d.7 fail, -16and so on.
Pressing tab and adding edd=off to the kernel parameters does not change the behaviour.
Booting from an old hard drive, it is able to boot OK with 4.10.0-28-generic i686 which has the boot flags
ro forcepae lapicbut adding those flags to the Arch kernel does not help.
Offline
With that enabled, the very last message is (though this changes every time)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.7-arch1-1.2 #1 7517The interrupt errors I have described are still present.
The only other suspicious thing I see is - potentially - a partial stack trace that has maybe scrolled out of the buffer, with these lines (I am only writing the text and not the +0x40/0x2b0 addresses because I have to transcribe this manually):
driver_register
__pci_register_driver
uhci_hcd_init
? ohci_pci_init
do_one_initcall
? parse_args
? rdinit_setup
kernel_init_freeable
? rest_init
kernel_init
ret_from_fork
rest_init
ret_from_fork_asm
entry_INT80_32Last edited by reinderien (2025-09-04 13:45:54)
Offline
I also saw a message scroll by that said 'unstable clock detected'.
How do I disable OHCI and UHCI?
Last edited by reinderien (2025-09-04 13:46:23)
Offline
https://www.kernel.org/doc/html/v5.0/ad … eters.html
maybe one of usbcore.nousb or usbcore.quirks helps.
Offline
Given your laptop has other sources of clocks, maybe 'clocksource=hpet' or so helps? Forgive me, I you'll have to dig on your own here,
there might be other possible clock sources you have to resort to, maybe even back to the 'PIT'.
[X86-32] pit,hpet,tsc
Offline
usbcore.quirks is not a valid parameter for this kernel. usbcore.quirks=go (at a guess) did not change the behaviour; I will try nousb next
Last edited by reinderien (2025-09-04 18:48:21)
Offline
Also, maybe verify first with an old Ubuntu 8 or another Linux from the Epoch, that Linux once really worked on that laptop in the past.. :-)
Offline
usbcore.nousb, at the least, has quieted down the boot console. At this point, it still complains on these two:
usbserial: usb_serial_init - registering generic driver failed
usbserial: usb_serial_init - returning with error -19and the farthest it gets (without increasing log verbosity) is
Triggering uevents...If I crank verbosity back up via `usbcore.nousb debug` then the furthest it gets is
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUAwhich seems reproducible on every boot.
loglevel=7 adds more detail, and shows
pnp: PnP ACPI init
pnp 00:00: disabling [mem ...] because it overlaps ... BAR 6
system 00:00: [mem ... ] has been reserved
system 00:01: [io ...] has been reserved
(7 similar lines)which also seems reproducible on every boot.
To all of that, adding clocksource=hpet does not change the behaviour.
Also, maybe verify first with an old Ubuntu 8 or another Linux from the Epoch, that Linux once really worked on that laptop in the past.. :-)
As I mentioned, an old 4.10.0-28-generic i686 does work OK.
Offline
Progress! From that one PNP ACPI init message, and reading the kernel documentation for available parameters,
acpi=offdoes allow it to mostly boot! Is there some "partial" or "patched" ACPI mode that I can set that is not fully-disabled?
...Once I get to a terminal that looks to be functioning, I see that it's actually still hung.
Last edited by reinderien (2025-09-04 19:15:10)
Offline
I think the current problem is that with ACPI off, I don't actually have a keyboard. The system otherwise seems to be running. The problem is that I only have one USB port, and the boot stick is in it. I've confirmed that if I move the stick to a hub, the BIOS doesn't see it. So... how do I prevent ACPI from panicking the kernel, but still get a keyboard?
Offline
I've basically given up on arch. DebianEdu 12 is "modern enough" and has an i386 build, so I'm using that. Seems fully stable.
Offline