Boot failure: PANIC: acquire_spinlock(): failed to acquire spinlock for a long time

[cdesai]

I 'dd'ed the image from haiku-nightly-hrev48579-x86_gcc2_hybrid-anyboot.zip to a flash drive

Had to select Graphics mode VGA from the bootloader as any other option didn't work with my monitor (1600x900@60)

This is after I enabled the 'show debug text on display' option, it crashed right after and dropped me in a KDL prompt, where I typed 'co' to get this.

Hardware: i7-2600 (onboard graphics, HD 3000), 12G RAM, Dell 1600x900 monitor.

[cdesai]

stacktrace

[anevilyak]

waddlesplash: for the thousandth time, stop recategorizing tickets if you don't actually know where they belong to. There isn't enough information here to implicate any component whatsoever.

@cdesai: a list of hardware (I.e. lspci output from Linux) would be helpful.

[cdesai]

@anevilyak: ​http://sprunge.us/WShd

[waddlesplash]

@cdesai: please attach that as a text file to the ticket

@anevilyak: I was pretty sure, from talking to cdesai on IRC, and from looking at the stacktrace, that this is the kernel's fault. After all, it's just after the entry point (_start) no? (And there were some very similar bugs surrounding acquire_spinlock before, but they occurred after boot had finished).

[cdesai]

lspci output from Linux

[anevilyak]

Replying to waddlesplash:

@anevilyak: I was pretty sure, from talking to cdesai on IRC, and from looking at the stacktrace, that this is the kernel's fault. After all, it's just after the entry point (_start) no? (And there were some very similar bugs surrounding acquire_spinlock before, but they occurred after boot had finished).

Except those are also frequently provoked by using the on-screen debug output option, that one can mess with timing in a number of ways and really shouldn't generally be used. It's really only meant for debugging very early boot issues. More useful would be the syslog output from a perfectly normal boot attempt, i.e. by attempting to boot normally, then a soft reset, then accessing the previous boot's in-memory syslog via the boot loader. Most likely this one's a device driver issue.

[cdesai]

Okay so I was able to get it booting finally, but the resolution wasn't right.

Some more details: Still the same image/hrev/hardware. Booting directly via the flash drive results in a black screen after the Haiku loading screen finishes because it picks and invalid resolution and the monitor doesn't like that. I then tried a bunch of options from the bootloader menu, some of which resulted in the above.

It only allows me to select 4:3 resolutions.

So then I started from square one again, and was able to get it to boot by selecting the 'VGA Mode' in the failsafe video option, enabling it and booting into safe mode.

I did check the syslog from a working build and the video BIOS did report the correct values, unfortunately I didn't have any FAT partition devices around so I couldn't save the full log, I'll get it next time from a non-working boot via the way you suggested.