Haiku booting process hangs at ohci ownership change

[vaisarger]

Hi! My system is a very old laptop with only OHCI type USB, I would use in it Haiku because of its efficiency, and because i'm curious to test it. (In such machine, it's pointless using QEMU, since bare metal is so slow) Haiku iso is the last 32 bit official haiku-r1beta1-x86_gcc2_hybrid-anyboot, whose I burned a bootable DVD.

Boot process hangs at third icon, then I started to modify boot options and saw boot log messages.

As I said, when boot reaches the device section, first it complies that there is no uhci usb, and then writes the last row: "usb ohci -1: smm in control of the host controller". And nothing more. Afterward I read that Haiku, in the boot process, normally changes the ownership of the device, and then goes ahead (not in my case).

The system BIOS is rather old and with very few options, so I could only enable/disable "USB legacy support" and the expected S.O. "WindowsXP/Other", but nothing changes.

(I tried to push power button, but nothing happens until I push it for 7-8 sec, afterwards system shuts down)

I then tried to blacklist ohci usb support, but being the installation media a DVD rom, it is not possible. Obviously I tried to enable *every* option in safe mode section, like add-on disabling, don't call the BIOS, video failsafe, ACPI, etc.etc., every one, but no effect.

Then I copied the image in a USB stick (through Etcher) to blacklist ohci, but, while my BIOS supports "Removable Devices", it's not working anyway (it seems trasparent to the bios, and it then shifts to HD boot).

So I'm stuck.

Is there a way to download ISO image with ohci support disabled? May I write some commands at some point?

[waddlesplash]

I then tried to blacklist ohci usb support, but being the installation media a DVD rom, it is not possible.

No, it is possible; you can blacklist entries via the bootloader. See ​https://www.haiku-os.org/docs/userguide/en/bootloader.html

[waddlesplash]

OHCI init code is here: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/busses/usb/ohci.cpp#215

I don't really see how this could hang the whole boot process; it seems to wait for fixed amounts of time between logs.

[vaisarger]

blacklisting denied

[vaisarger]

"No, it is possible; you can blacklist entries via the bootloader. " Please, may you tell me how to do it, because it seems me that is not possible (see picture I have attached).

[vaisarger]

"I don't really see how this could hang the whole boot process; it seems to wait for fixed amounts of time between logs." I am just a system admin with a pretty good knowledge in bash scripting, so I haven't got the knowledge to analyze deeply a boot log of a new O.S. (sorry). The only thing I say is that very last row Haiku init.d (or kernel, I don't know) writes in the terminal is "usb ohci -1: smm in control of the host controller", then it hangs.

I tried many changes in bootloader option and the few ones allowed by my old BIOS... and now I run out of options, and I don't know how to do.

Thank you anyway for your interest :)

[CodeforEvolution]

Hey, here’s a link to the guide which should tell you how to get to the bootloader menu: ​https://www.haiku-os.org/docs/userguide/en/bootloader.html

From there, under the troubleshooting section of the guide, there should be information on how to blacklist files from within the boot loader.

[waddlesplash]

Hey, here’s a link to the guide which should tell you how to get to the bootloader menu: ​​https://www.haiku-os.org/docs/userguide/en/bootloader.html

The ticket author has posted a screenshot with an error message from the bootloader saying that "blacklisting isn't supported on this volume"; so obviously they have already gotten into the menu. Further, I already posted that link in comment:1, so this reply is redundant and completely unhelpful.

[waddlesplash]

So, the "doesn't support blacklisting!" comes from ​menu.cpp:749. IsPackaged() comes from whether or not fPackageVolumeInfo is set or not, which comes from ​vfs.cpp:530. But ​PackageVolumeInfo::SetTo will bail if there is no current state, which there never is on volumes being booted for the first time, and so fPackageVolumeInfo will be NULL, making blacklisting impossible for a first boot (after the first boot, package_daemon will write this file and thus make bootloader blacklisting possible.)

This probably deserves it's own ticket.

[waddlesplash]

Hmm, except ​_InitState already has a case for when no activated-packages file exists. Dunno what's going on here, then.

[CodeforEvolution]

Ah, ok, sorry for the noise.

[mmlr]

The delays are indeed fixed and so the handover should simply time out. We do however request work from the firmware, which runs in system management mode (SMM) and has higher priority than us. If it stalls there, the system will just stop, whithout us ever getting back control.

The ownership handover has been historically problematic, as quite a lot of firmware is/was simply broken and would simply not do anything, or in the worst case stall. The workaround has been to disable SMM interrupts of the controller and hope that reinitialization of the controller would then not be noticed by the firmware.

Much of that code and logic in OHCI, UHCI and EHCI is inspired by FreeBSD, so it would be interesting to know if the same happens there. Can you try booting FreeBSD and see if it also experiences the hang?

The only possible thing to try is to not bother with the handover procedure at all, because it is often buggy in firmware, and always do the fallback of trying to shut SMM out. This would indeed align with what the "don't call the BIOS" safemode option is meant for and could therefore be tied to that.