Haiku 32-bit boots once every ten times on i7-8700K (64-bit was fixed)

[KapiX]

As in title.

It just shows a bootsplash and then immediately reboots. It doesn't even show any debug output when enabled.

Various other options didn't help as well:

• Safe mode
• only-VESA
• Disable SMAP

Mobo: MSI Z370 PC Pro

Set to CSM mode.

When it actually boots, it hangs when trying to mount Be formatted external disk to front-panel USB3 port. This disk was formatted on the same machine.

I tried downloading hrev51798 and booting from pendrive, same behavior.

[KapiX]

No syslogs, because it doesn't save any.

[KapiX]

One other interesting thing is that instead of bootsplash it sometimes displays last frame of GRUB menu.

I've tried multiple other safe mode options, but no luck. If I enable them all I *think* I can reliably boot the system, but it would be really helpful if I could reliably trigger the boot menu in the first place... (and no, pressing down shift during boot does not always work).

EDIT: no, enabling all safe mode options doesn't change anything, it still doesn't boot.

Also, Linux 4.15.4 throws a bunch of ACPI errors (but works). Disabling ACPI doesn't help.

[KapiX]

I think this is the syslog from the last run, with every safe mode option enabled (it failed to boot).

[korli]

There seems to be a problem to find/control the ACPI embedded controller. Otherwise it seems you would be better booting off AHCI.

[korli]

Forgot to write that there are 2 XHCI controllers (ASMedia and Intel), so maybe you have different behaviors when booting off a USB port or another.

[KapiX]

No, no difference (I've tried 2.0, 3.0 and 3.1). Any pointers where I could start debugging? My initial thought is to insert some debugging statements (whatever it might be) around framebuffer code, although I'm not entirely clear how I could display them.

[korli]

What about 32-bit?

[KapiX]

Exactly the same.

EDIT: I'm dumb. The first thing I should have done was try an older revision. I did check alpha 4.1 and even though it doesn't have XHCI driver, it can display things on screen (like could not find partition) without restarting the computer. I suspect hrev51207 could break this, but I did not confirm yet. Will update.

[KapiX]

It turned out hrev51207 was not the problem. My experiments showed that last available build that kind of works OK (boots most of the time, only rarely restarts) is hrev50554. hrev50701 is broken.

However, I thought it might have something to do with VESA emulation, so I made EFI-enabled anyboot image from HEAD, disabled Legacy boot, and surprise, surprise, it works perfectly fine (well, it KDL-ed two times, but that might be an issue with the pendrive). Either GRUB is doing something nasty, or Legacy mode is broken. Either way, I will have to repartition my disk to make it UEFI-enabled.

I will leave this open for the time being, until I test that everything is fine when booting from hard disk.

[korli]

What you could do is: start with the image from hrev50554, then bisect update to hrev repository until hrev50701. For instance, try with hrev50627 first. This will help to do reduce the range of the commits to check. ​https://download.haiku-os.org/haiku-repositories/master/x86_64/

[waddlesplash]

I just ran into this commit from FreeBSD: ​https://github.com/freebsd/freebsd/commit/f823b0ab84a7fc512bd8df7f85228e215b064a0d

I wonder if it's related? "INTx interrupts not getting delivered" seems like it could be a possible cause of a number of symptoms here.

[waddlesplash]

So, I am pretty convinced at this point that this and #14659 are the same problem. The fact that they have identical symptoms and a similar if not identical bug is reproducible on QEMU points to a common cause.

I ran some tests adding debug output in _start, and it seems that we can get debug prints from most CPUs except CPU 0(but this was on a KVMless system, I need to test on a system with KVM to see what happens there.) Which is very strange; it seems that CPU 0 just is not getting to _start at all?

It's still pretty frustrating how, at least there, all that happens is the CPU unceremoniously resets. No triple fault, no other notices from QEMU, we just get a reset. So, this is going to be pretty tricky to debug.

[mmlr]

Can you retest with change 810 from Gerrit applied? ​https://review.haiku-os.org/c/haiku/+/810

If the reboots really have the same cause as #14659, that change should fix them. It does not explain the hangs however.

[korli]

Replying to mmlr:

If the reboots really have the same cause as #14659, that change should fix them. It does not explain the hangs however.

In comment 8 KapiX writes that the behavior is the same on x86.

[KapiX]

Seems fixed for x86_64. I didn't test 32-bit but it likely needs the same type of fix applied.

[mmlr]

Replying to KapiX:

Seems fixed for x86_64. I didn't test 32-bit but it likely needs the same type of fix applied.

The 32 bit code does not use the reworked C++ code as it needs to remain gcc2 compatible. It is therefore not affected by the particular issue introduced in that rewrite. If you can still reproduce the problem there, it would be a different bug that would need a separate investigation.