[Haiku-64bit] regression: hrev48613 won't boot

[taos]

I've updated my virtual hrev48600 via pkgman to hrev48613. Unfortunately, after rebooting hrev48613 freezes at the last boot splash icon. Going back to hrev48600 in boot options allows for a successful start again.

Booting from anyboot images: hrev48600 -> works (serial output attached as hrev48600.serial.log - first boot: anyboot, second: "hard disk" installation) hrev48613 -> booting stops at last boot splash icon (serial output attached as hrev48613.serial.log)

Booting from updated haiku installation: hrev48614 -> booting stops at last boot splash icon (hrev48614.serial.log)

Booting in safe mode doesn't work either.

I don't know if only VirtualBox installations are affected. At the moment, I don't have access to a machine that can boot Haiku 64bit natively (that's not quite true: it can boot but keyboard and touchpad (or usb mouse) won't work - revision is much older than the one affected by #11707).

[taos]

serial log of hrev48600

[taos]

serial log of hrev48613

[taos]

serial log of hrev48614

[pulkomandy]

Possibly fixed with hrev48619 as there was a major regression in BMessage handling?

[vidrep]

64 bit is not booting on hrev48613. Attached syslog. This is on real hardware.

[luroh]

vidrep, that syslog mentions only hrev48585. As PulkoMandy said, please try with 48619 or later.

[vidrep]

Replying to luroh:

vidrep, that syslog mentions only hrev48585. As PulkoMandy said, please try with 48619 or later.

I did an update from hrev48585 to hrev48613, after which it no longer would boot.

I pulled the syslog for 64 bit after mounting it from another partition. I'll try a fresh install of hrev48619 (or later) when I get home from work.

[taos]

Unfortunately, I couldn't check if the problem is gone for revisions > hrev48619. It seems there are no new images/packages available for 64bit at the moment and I didn't succeed in building an anyboot image myself.

Error during building of hrev48626 on haiku hrev48600:

In file included from /GIT/haiku/generated.x86_64/build_packages/gcc_syslibs_devel-4.8.4_2014_12_21-1-x86_64/develop/headers/c++/bits/stl_algo.h:59:0,
                 from /GIT/haiku/generated.x86_64/build_packages/gcc_syslibs_devel-4.8.4_2014_12_21-1-x86_64/develop/headers/c++/algorithm:62,
                 from /GIT/haiku/src/system/boot/platform/bios_ia32/interrupts.cpp:12:
/GIT/haiku/generated.x86_64/build_packages/gcc_syslibs_devel-4.8.4_2014_12_21-1-x86_64/develop/headers/c++/cstdlib:178:10: error: expected unqualified-id before '__int128'
   inline __int128
          ^

[vidrep]

I installed the last bootable revision of 64 bit (hrev48600) and updated to the latest available nightly as of Jan. 7 (hrev48614) via "pkgman full-sync". 64 bit Haiku still will not boot past the rocket icon.

[kallisti5]

x86_64 stopped working here on my physical dev machines and in qemu after performing an update to hrev48614

Attaching a full syslog and bumping to critical.

[anevilyak]

It was already asked if hrev48619 or newer fixes it. The revision you tested is older than that. If the build bots haven't yet produced one, then it would be appreciated if you could try a newer build manually. In any case, 64-bit is not an official R1 target so this shouldn't have blocker priority

[kallisti5]

anevilyak, ah. sorry.. I missed that. I'll test once built.

[taos]

After update to hrev48629, haiku 64 bit still doesn't boot under VirtualBox. It still stops after the last boot splash icon lights up. In contrast to hrev48614, no icon lights up with serial log enabled.

Update: Tried with a slightly different VirtualBox configuration on another computer. Here, even with serial log enabled all boot splash icons light up before freezing. I've attached serial log output from this computer for hrev48629 (hrev48629.2.serial.log - boot freeze after updating from hrev48600) and (for comparison) hrev48600 (hrev48600.2.serial.log - successful boot).

[pulkomandy]

64bit only, can't be R1 or beta1 blocker.

[taos]

serial log of hrev48600 (computer 2)

[taos]

serial log of hrev48629 (computer 2)

[vidrep]

Tried a fresh install of 48600 and update to 48636 - still not booting. If a serial debug log is helpful, let me know.

[korli]

And does fresh hrev48636 nightly boot correctly?

[georgewhite]

This appears to be simular to https://dev.haiku-os.org/ticket/11630

[georgewhite]

This appears to be simular to https://dev.haiku-os.org/ticket/11630

[georgewhite]

The last debug messages are about the display, its vendor and 'Supported Additional Modes'

[taos]

Replying to korli:

And does fresh hrev48636 nightly boot correctly?

Not under VirtualBox.

[taos]

Replying to georgewhite:

This appears to be simular to https://dev.haiku-os.org/ticket/11630

I think it's different. Prior to (and including) hrev48600 I had no problems booting haiku (local apic enabled or disabled). I checked a revision near the one mentioned in #11630 and, for me, it boots consistently and without problems to the desktop with local apic enabled. Additionally, the last messages in syslog/serial output differ. For me, it always stops with either:

vesa: vesa_init() completed successfully!
vesa: acc: vesa.accelerant

or with hrev48636 anyboot if I wait a little longer:

vesa: vesa_init() completed successfully!
vesa: acc: vesa.accelerant
bfs: bfs_stat_index:2166: No such file or directory
Last message repeated 3 times.

[pulkomandy]

I don't see anything obviously broken in this commit range. It would be helpful to binary search when the problem started exactly. The problem with inline __int128 is known, it is currently not possible to build haiku x86_64 on haiku. You need to build it from Linux or another OS.

[georgewhite]

Interestingly, on my system with an Intel HD 3000 GPU it goes much further than the syslog you've specified.

[georgewhite]

So yes, I can confirm that this applies to all x86_64 systems, not just VirtualBox.

[luroh]

Replying to pulkomandy:

It would be helpful to binary search when the problem started exactly.

hrev48606 works, hrev48607 doesn't.

[korli]

hrev48607 with hrev48617, hrev48618 and hrev48619 cherrypicked doesn't work either.

[luroh]

Booting hrev48640 ends with "PANIC: get_boot_partitions failed!" with a lot of stuff apparently missing, according to the syslog.

Edit 1: the panic stems from hrev48640. hrev48639 just hangs like before.

Edit 2: the panic from hrev48640 is also present in a pure gcc2 build.

Edit 3: the commit that breaks booting is "Migrate image hash table to BOpenHashTable." (commit 69ff01cb...).

Edit 4: with hrev48641, the panic is gone but booting gcc2 now hangs at bootsplash with all icons lit up. hrev48640 with just 69ff01c reverted boots fine. No panic, no hang.

[kallisti5]

still broken

[kallisti5]

better, but nope

[georgewhite]

The problem oddly enough seems to vary from computer to computer. I don't really get it. It would be interesting to see if the app_server is running, and to check for it, you can hold Alt-SysReq-D to force KDL to appear and use threads to identify if such a process was started before KDL was launched, to see if the problem is in app_server or a driver.

[anevilyak]

Fixed in hrev48646.

[kallisti5]

Great work! Confirmed working here!

[vidrep]

Confirmed working here as well. Thanks.

[taos]

Works under VirtualBox, too. Thanks!