Opened 7 years ago
Last modified 5 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: | Blocking: | ||
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)
Change History (20)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Component: | - General → System/Kernel |
---|
comment:3 by , 7 years 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.
by , 7 years ago
I think this is the syslog from the last run, with every safe mode option enabled (it failed to boot).
comment:4 by , 7 years 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 , 7 years 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 , 7 years 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:8 by , 7 years 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.
comment:9 by , 7 years 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%).
comment:10 by , 7 years 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 , 6 years 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 , 6 years 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 , 6 years ago
Blocked By: | 14659 added |
---|
follow-up: 15 comment:14 by , 6 years 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.
comment:15 by , 6 years ago
Platform: | x86-64 → All |
---|
follow-up: 17 comment:16 by , 6 years ago
Seems fixed for x86_64. I didn't test 32-bit but it likely needs the same type of fix applied.
comment:17 by , 6 years 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 , 5 years ago
Summary: | Haiku 64-bit boots once every ten times on i7-8700K → Haiku 32-bit boots once every ten times on i7-8700K (64-bit was fixed) |
---|
comment:19 by , 5 weeks ago
Blocked By: | 14659 removed |
---|
No syslogs, because it doesn't save any.