Haiku won't boot after update (regression)

[vidrep]

Acer AspireXC-704

Previously installed Haiku installation fails to boot after update to latest nightly.

DriveSetup shows raw disk only and does not recognize previous Haiku partitions.

I have narrowed the breakage to:

hrev53033 working hrev53038 not working

listdev and syslog attached

[Starcrasher]

I was puzzled by numbers and checked the joined sylog. Of course, it's between hrev57033 and hrev57038 but a lot happened during this period (Changes to XHCI, PCIe, usb-disk driver transition to new API..)... Could you precise where it hangs?

[korli]

vidrep, can you enable on-screen logs and post the few last screenshots?

[vidrep]

The syslog is from hrev57033 I've enabled on-screen debug logs and attached a couple of photos while booting (hrev57191).

[waddlesplash]

Are you booting from USB or internal hard drive?

[waddlesplash]

<Vidrep_64> I'm booting from an internal hard drive

[waddlesplash]

Presumably hrev57034 (note multiple commits in that hrev) is the cause here. So this would then be a problem with the new PCIe support code.

I've asked Vidrep to try booting with ACPI disabled, as that will use the older configuration mechanism and may reveal differences.

[vidrep]

I was able to successfully install a current nightly build only if "disable ACPI" is first selected in the boot menu. Otherwise the system will KDL on the fourth icon during boot. It will KDL during shutdown regardless.

[waddlesplash]

The problem is likely in the new ECAM PCI mechanism and the ACPI bus, then, based on the commit range.

[vidrep]

syslog with ACPI enebled and reboot with it disabled

[vidrep]

System KDL when shutting down or rebooting Photo attached

[waddlesplash]

Since the system boots with ACPI disabled, maybe related to #18454.

[waddlesplash]

Please retest with a recent nightly.

[vidrep]

Tested with hrev57645 x86_64

Fresh install booting from USB stick

Image on USB stick boots to installation screen, but the hard disk and its Haiku partitions are not seen unless ACPI is disabled first. After disabling ACPI and installing to HDD the system will KDL on the fourth icon upon reboot. Diable ACPI allows it to boot to the desktop. The system will KDL again when shutting down or rebooting.

[pulkomandy]

Unfortunately I can't find any boot in the non-working case in your attached files.

I'm interested in the PCI initialization which starts like this (with all the "PCI: ..." following that):

From the hrev57033 log:

238	KERN: PCI: mechanism addr: e0000000, seg: 0, start: 0, end: ff
239	KERN: PCI: mechanism pcie controller found
240	KERN: pci_init_deferred()

From the other log:

4556	KERN: PCI: pci_module_init
4557	KERN: acpi: ACPI disabled
4558	KERN: PCI: mechanism 1 controller found

(I find only cases with ACPI disabled).

I think you can extract the syslog while booting from USB with ACPI enabled.

I'm hopping to see something like this in current nightlies:

KERN: initialize PCI controller from ACPI
KERN: PCI: range from ACPI [0(1),fe(1)] with length ff
KERN: PCI: range from ACPI [0(1),cf7(1)] with length cf8
KERN: PCI: range from ACPI [d00(1),ffff(1)] with length f300
KERN: PCI: range from ACPI [a0000(1),bffff(1)] with length 20000
KERN: PCI: range from ACPI [c0000(1),c3fff(1)] with length 0
KERN: PCI: range from ACPI [c4000(1),c7fff(1)] with length 0
KERN: PCI: range from ACPI [c8000(1),cbfff(1)] with length 0
KERN: PCI: range from ACPI [cc000(1),cffff(1)] with length 0
KERN: PCI: range from ACPI [d0000(1),d3fff(1)] with length 0
KERN: PCI: range from ACPI [d4000(1),d7fff(1)] with length 0
KERN: PCI: range from ACPI [d8000(1),dbfff(1)] with length 0
KERN: PCI: range from ACPI [dc000(1),dffff(1)] with length 0
KERN: PCI: range from ACPI [e0000(1),e3fff(1)] with length 0
KERN: PCI: range from ACPI [e4000(1),e7fff(1)] with length 0
KERN: PCI: range from ACPI [e8000(1),ebfff(1)] with length 0
KERN: PCI: range from ACPI [ec000(1),effff(1)] with length 0
KERN: PCI: range from ACPI [f0000(1),fffff(1)] with length 0
KERN: PCI: range from ACPI [80800000(1),bfffffff(1)] with length 3f800000
KERN: PCI: range from ACPI [4000000000(1),7fffffffff(1)] with length 4000000000
KERN: PCI: mechanism addr: c0000000, seg: 0, start: 0, end: ff

(we have added quite a bit of debug info in here)

I have also noticed this log:

io-apic 0 entry count exceeds max supported, only using the first 64 entries
io-apic 0 has range 0-63, 64 entries, version 0x00720020, apic-id 1

maybe we should do something about that?

[vidrep]

Would enabling any of the debug options in the boot menu be of any help?

[pulkomandy]

I don't know, I need a log where the problem actually happens to investigate it, and I don't think I found one in the attached logs (maybe I missed it). They are either #rom before the problem, or with acpi disabled.

[vidrep]

hrev57666 x86_64 ACPI enabled

Enable on screen debug output - IMG.0126.JPG

Display current boot loader log - IMG.0128.JPG, IMG.0129.JPG

Hopefully this helps.

[pulkomandy]

Ok, there are some strange values in the ACPI range list similar to #18454. So I guess we need to fix that first and see if it helps here. Waddleplash had already guessed it, but now I think it's confirmed.

[vidrep]

I have attached a couple more photos of debug output, but this time with on screen paging disabled. I was able to capture the last few lines before it was overwritten by the KDL.

IMG_0126.2.JPG

IMG_0127.2.JPG

[waddlesplash]

hrev57044 may also be related here then.

[vidrep]

Updated to hrev57683. Same problem as before - cannot boot without first disabling ACPI.