Opened 19 months ago

Last modified 8 weeks ago

#13991 new bug

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

Reported by: KapiX Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: #14659 Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (1)

syslog (473.4 KB ) - added by KapiX 19 months ago.
I think this is the syslog from the last run, with every safe mode option enabled (it failed to boot).

Download all attachments as: .zip

Change History (19)

comment:1 by KapiX, 19 months ago

No syslogs, because it doesn't save any.

comment:2 by diver, 19 months ago

Component: - GeneralSystem/Kernel

comment:3 by KapiX, 19 months ago

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.

Last edited 19 months ago by KapiX (previous) (diff)

by KapiX, 19 months ago

Attachment: syslog added

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

comment:4 by korli, 19 months ago

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

comment:5 by korli, 19 months ago

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.

comment:6 by KapiX, 19 months ago

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.

comment:7 by korli, 19 months ago

Platform: Allx86-64

What about 32-bit?

comment:8 by KapiX, 19 months ago

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.

Last edited 19 months ago by KapiX (previous) (diff)

comment:9 by KapiX, 19 months ago

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.

EDIT: the issue persists, but with EFI loader Haiku can boot successfully significantly more often (>50%).

Last edited 19 months ago by KapiX (previous) (diff)

comment:10 by korli, 16 months ago

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/

comment:11 by waddlesplash, 15 months ago

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.

comment:12 by waddlesplash, 9 months ago

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.

comment:13 by waddlesplash, 9 months ago

Blocked By: 14659 added

comment:14 by mmlr, 9 months ago

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.

in reply to:  14 comment:15 by korli, 9 months ago

Platform: x86-64All

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.

comment:16 by KapiX, 9 months ago

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

in reply to:  16 comment:17 by mmlr, 9 months ago

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.

comment:18 by waddlesplash, 8 weeks ago

Summary: Haiku 64-bit boots once every ten times on i7-8700KHaiku 32-bit boots once every ten times on i7-8700K (64-bit was fixed)
Note: See TracTickets for help on using tickets.