#16999 closed bug (fixed)
No boot to installer or live desktop (regression)
| Reported by: | vidrep | Owned by: | korli |
|---|---|---|---|
| Priority: | blocker | Milestone: | R1/beta3 |
| Component: | System/Boot Loader | Version: | R1/beta2 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
vendor 8086: Intel Corporation device 22b1: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller EFI only
Last known working revision was hrev53545 x86_64.
Latest nightly never boots past the "chip" icon.
Installing hrev53545 and updating results in the same no boot condition.
Attachments (5)
Change History (26)
comment:2 by , 3 years ago
I'm currently in the process of trying random nightlies to see if I can track down which commit broke installing to this particular PC.
comment:3 by , 3 years ago
| Component: | - General → System/Boot Loader |
|---|
comment:4 by , 3 years ago
comment:5 by , 3 years ago
| Summary: | Broadwell based Intel PC won't boot with recent nightly → No boot to installer or live desktop (regression) |
|---|
comment:6 by , 3 years ago
vidrep: Could you open a new issue for "the installed EFI bootloader doesn't start automatically" with this information? The original issue here is "Latest nightly never boots past the "chip" icon."
comment:7 by , 3 years ago
Nothing guarantees these are the same issue, thus I think your bisect is adding confusion :-)
comment:8 by , 3 years ago
As you are running on a less common Pentium processor I think it is probably due to p-states changes: https://git.haiku-os.org/haiku/log/?qt=range&q=hrev54571..hrev54575
comment:9 by , 3 years ago
I've attached a listdev from last working state. If you need anything more, like a syslog, let me know.
by , 3 years ago
comment:10 by , 3 years ago
| Milestone: | Unscheduled → R1/beta3 |
|---|---|
| Priority: | normal → blocker |
comment:11 by , 3 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Can you boot with on-screen debug enabled and capture the last screen of logs? Or get a serial log if that machine has a serial port and that's more convenient for you.
Also, are you able to compile test images for each of the 4 commits in this range? It may help to know which exact one introduced the problem.
Assigning to Korli since he did most of the changes in this range, maybe you have an idea what could create the problem here?
comment:12 by , 3 years ago
It would probably make sense to disable c-states or p-states modules for such processors.
comment:13 by , 3 years ago
I have attached photos of the debug output, boot log, and KDL when attempting to boot from a USB drive with the most current anyboot written on it.
by , 3 years ago
| Attachment: | debug_log.JPG added |
|---|
by , 3 years ago
| Attachment: | boot_log.JPG added |
|---|
by , 3 years ago
comment:15 by , 3 years ago
I'd have to re-install hrev54571, which was the last working revision. I'll post a syslog for that in a couple of hours, once I get back from running errands.
comment:16 by , 3 years ago
You should be able to block list the intel_pstates module, observe whether it works better and eventually provide a syslog.
comment:17 by , 3 years ago
Blacklisting the intel_pstates lets the system boot and update. syslog attached of this test session.
by , 3 years ago
comment:18 by , 3 years ago
One side effect, which may not be related - After updating WebPositive wouldn't launch.
comment:19 by , 3 years ago
see proposed change: https://review.haiku-os.org/c/haiku/+/4120
affected chips: https://en.wikichip.org/wiki/intel/microarchitectures/airmont#All_Airmont_Chips
comment:20 by , 3 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Applied in hrev55198. Please confirm to get this patch in beta3.
comment:21 by , 3 years ago
Working. Tested with Beta 3 test iso. Now boots to installer/live desktop, installs, and successfully reboots to new install.
comment deleted