System slow and no USB on Asus Chromebox 3 (Teemo)

[benhigh98]

A little bit of a non-traditional hardware configuration here, but I'm attempting to install the latest nightly (hrev57509) of Haiku on my Asus Chromebox 3, codename Teemo, with MrChromebox's coreboot firmware with the following DMI:

Google Teemo/Teemo, BIOS MrChromebox-4.22.0 12/22/2023

After dd'ing the raw disk image extracted from the ISO as described ​here, and setting up the bootloader for UEFI as described ​here, I'm able to get to the desktop. However, USB devices are not working, the system boots extremely slowly, and one CPU core reports being completely maxed out. The system remains responsive to the power button (although shutdown similarly takes around 2-3 minutes), but no input from USB devices is read. Additionally, ethernet does not appear to respond, as attempting to SSH into the machine yields a timeout. When USB mice with LEDs (ie, my secondary Razer mouse) are unplugged and plugged back in, the LEDs do not turn back on.

I have attempted to upgrade my coreboot firmware (previously attempts were made on MrChromebox-4.18.2 11/29/2022), and I have tried to remove my wireless card (the only internal component I'm able to remove on this device), as well as of course trying other USB ports. However, I have yet to be able to get any other results. Attempting to use this SSD in my Dell XPS 15 works without any issues at all.

Since I am unable to control the Haiku machine, I can only collect the lspci and lsusb when booted into Fedora Linux, as well as the syslog.

[waddlesplash]

I doubt XHCI is the problem here, considering the "one CPU core reports being completely maxed out", ethernet problems, etc.

Can you try booting with ACPI disabled?

[benhigh98]

I just attempted to boot with ACPI disabled from the Haiku bootloader, but I'm getting the same result. The desktop appears eventually, but very slowly, and the USB keyboard and mouse still do not respond. One CPU core is still showing 100% utilization. I'm also getting the same result in safe mode.

[korli]

Disabling some kernel modules/drivers is possible in the boot loader, for instance you can try to disable the xhci usb module, then the ethernet driver, etc.

[benhigh98]

I just tried to boot with everything in /add-ons/kernel/boot disabled one at a time, including the xhci module, but I'm still getting the same issue (if the system doesn't crash outright, at least). I also tried disabling usb_ecm and virtio_net in /add-ons/kernel/drivers, as well as /add-ons/kernel/network/devices/ethernet, but similarly have not observed any changes. Is there anywhere else I should be looking for other modules to disable?

[waddlesplash]

If you can't even get any input at all on the desktop, it's probably not going to be very easy to debug this without kernel development expertise (or at least, working with a kernel developer over IRC or something like that rather than merely in ticket replies.)

Can you even drop to KDL via the keyboard shortcut (Alt+SysRq+D)?

[benhigh98]

Unfortunately no, after getting past the bootloader, the keyboard stops responding entirely. Even when the system crashes into the KDL on its own when disabling different modules, the keyboard remains unresponsive. I tried booting with screen debugging enabled, but it seems like whatever is causing USB devices to stop responding is occurring even that early on in the boot.

[waddlesplash]

Well, then this may be basically undebuggable, unfortunately. The only remaining ideas I have are to make modifications to the boot scripts to launch various programs immediately after boot, to try and diagnose what thread is eating so much CPU, if you want to try for that.

I know Coreboot has sometimes caused problems on more normal hardware than Chromebooks, but nothing this severe.