#11710 closed bug (fixed)
[Haiku-64bit] regression: hrev48613 won't boot
Reported by: | taos | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | - General | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
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).
Attachments (10)
Change History (41)
comment:1 by , 10 years ago
Platform: | All → x86-64 |
---|
by , 10 years ago
Attachment: | hrev48600.serial.log added |
---|
comment:2 by , 10 years ago
Possibly fixed with hrev48619 as there was a major regression in BMessage handling?
comment:3 by , 10 years ago
64 bit is not booting on hrev48613. Attached syslog. This is on real hardware.
by , 10 years ago
Attachment: | hrev48613_x86_64_syslog added |
---|
follow-up: 5 comment:4 by , 10 years ago
vidrep, that syslog mentions only hrev48585. As PulkoMandy said, please try with 48619 or later.
comment:5 by , 10 years ago
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.
comment:6 by , 10 years ago
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 ^
comment:7 by , 10 years ago
comment:8 by , 10 years ago
Milestone: | R1 → R1/beta1 |
---|---|
Priority: | normal → blocker |
Summary: | [Haiku-64bit] regression: hrev48613 can't boot with VirtualBox → [Haiku-64bit] regression: hrev48613 won't boot |
comment:9 by , 10 years ago
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.
by , 10 years ago
Attachment: | syslog-hrev48613.txt added |
---|
comment:10 by , 10 years ago
Priority: | blocker → normal |
---|
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
comment:12 by , 10 years ago
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).
comment:13 by , 10 years ago
Milestone: | R1/beta1 → Unscheduled |
---|
64bit only, can't be R1 or beta1 blocker.
comment:14 by , 10 years ago
Tried a fresh install of 48600 and update to 48636 - still not booting. If a serial debug log is helpful, let me know.
follow-up: 20 comment:16 by , 10 years ago
This appears to be simular to https://dev.haiku-os.org/ticket/11630
comment:18 by , 10 years ago
The last debug messages are about the display, its vendor and 'Supported Additional Modes'
comment:19 by , 10 years ago
comment:20 by , 10 years ago
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.
follow-up: 24 comment:21 by , 10 years ago
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.
comment:22 by , 10 years ago
Interestingly, on my system with an Intel HD 3000 GPU it goes much further than the syslog you've specified.
comment:23 by , 10 years ago
So yes, I can confirm that this applies to all x86_64 systems, not just VirtualBox.
comment:24 by , 10 years ago
Replying to pulkomandy:
It would be helpful to binary search when the problem started exactly.
comment:25 by , 10 years ago
comment:26 by , 10 years ago
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.
by , 10 years ago
Attachment: | hrev48640_syslog.txt added |
---|
comment:27 by , 10 years ago
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.
serial log of hrev48600