I am getting this error when I try to boot up the latest nightly on a USB drive. I don’t have a phone atm to take picture, so I am manually typing it out:
PANIC: acquire_spinlock(): Failed to acquire spinlock 0xffffffff802060e0 for a long time (last caller: 0x0000000000000000, value: 1)
Welcome to Kernel Debugging Land...
Thread 1845 "syslog sender" running on CPU 9
stack trace for thread 1845 "syslog sender"
kernel stack: 0xffffffff824cf000 to 0xffffffff824d4000
0 ffffffff824d3d20 (+ 32) ffffffff8014ade0 <kernel_x86_64> arch_debug_call_with_fault_handler + 0x1a
1 ffffffff824d3d40 (+ 80) ffffffff800b3a98 <kernel_x86_64> debug_call_with_fault_handler + 0x78
2 ffffffff824d3d90 (+ 96) ffffffff800b5144 <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf4
3 ffffffff824d3df0 (+ 80) ffffffff800b54de <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e
4 ffffffff824d3e40 (+ 240) ffffffff800b5877 <kernel_x86_64> panic + 0xb7
5 ffffffff824d3f30 (+ 48) ffffffff80078605 <kernel_x86_64> acquire_spinlock + 0x105
6 ffffffff824d3f60 (+ 80) ffffffff800b3026 <kernel_x86_64> syslog_sender(void*) + 0xc6
7 ffffffff824d3fb0 (+ 32) ffffffff8008c5b7 <kernel_x86_64> common_thread_entry(void*) + 0x37
8 ffffffff824d3fd0 (+ 2108866608) ffffffff824d3fe0 17140:syslog sender_1845_kstack@0xffffffff824cf000 + 0x4fe0
I tried R1beta4 as well, and it booted up, but the keyboard didn’t work.
Edit: Looks like the latest nightly on the Haiku Files site updated to hrev57320 as I was writing this, lol. I checked that version, and get the same error.
While I can’t offer any help…
Just here to say… I admire your effort!
While you wait for better replies… I assume you have already tried using the different fail-safe options on the bootloader menu? (just to see if anything helps at least ).
If you have the time (and bandwidth), going back to a shortly after B4 nightly to see if it works, and then splitting the gap down each time could help find what change has impacted here.
I haven’t tried the fail-safe options yet. I completely forgot about those, lol. I will try that, thanks.
@cian When I have the time, I will also look into doing this too, thanks.
Usually we only see this panic with the “on-screen syslog” option turned on. Do you have that enabled?
Sorry, I don’t know what that is. How do you turn it on? Also, how do you enter the bootmenu thing to choose the fail-safe modes?
I’m still working on finding a rev that works to see if I can narrow down which rev(s) caused the problem. So far I’ve found that href 56001 doesn’t panic with the spinlock, but it does go to a black screen and does nothing. However, I’ve recently found out this is way before Beta4 (which I think is href 56578) and beta4 did work (except for the laptop’s keyboard), so I think the black screen might be a completely different and irrelevant thing there.
Edit: Ok, I think I found out how to enter fail-safe mode (hold down shift during Haiku bootup screen), so I’ll try that soon too. Sorry it’s taking me so long to do this stuff, I’ve been busy with lots of other things.
That page doesn’t explain what syslog is or why it’s needed, and I already found out how to enter the bootmenu (as per my previous message). But thanks anyways, I guess.
Syslog is a short for system log. That is the collection of messages of kernel, drivers and apps from boot to shutdown. That is saved and if you manage to boot successfully, you will find a file named syslog.txt in /boot/system/var folder. Looking at this file, you can find a lot of infos on your hardware and how it was configured by drivers.
Since, in case of troubles, the system may not boot completely, there’s an option to see the messages ‘live’ in boot menu to ease debugging.
Ah, ok. I guess I expected on-screen syslog to be the default for nightlies, lol. It really should be turned on by default, imo. Anyways, thanks for explaining!
Ok, so I tried safe mode and it doesn’t work (panics similarly to if there wasn’t safe-mode). I didn’t try all of the options option though, just the safe-mode one. As for the on-screen syslog… I’m waiting for my ancient phone to charge so I can take a photo of the screen, unless there’s some other way to get the syslogs, idk.
It’d be cool if there was some tool on Linux and Windows to read the main partition of the USB drive so I could get the syslog file without needing to use another Haiku instance.
On linux, you can mount BFS partitions read-only with befs module if your kernel has it enable. It is also possible to mount them in read-write mode with fuse but it is a bit more complicated as you have to build the fuse module by yourself. See here.
A tool to view files on windows exists but I don’t know if it runs on latest versions. See here.
I don’t have Linux, unfortunately. The fact that I would have to manually enable some befs module or compile a fuse module myself is basically the reason why I don’t have Linux, lol.
Anyways, I seen the BFS viewer tool, but it doesn’t seem to work for me.
This is the best I can do, after waiting an hour for my phone to charge and another 10 minutes of waiting for Google Photos to upload these dang photos (not exaggerating too, I timed it!). I’m a bit frustrated with the idea that I have to spend hours installing linux just to spend more hours compiling a fuse module just to get some syslogs off of a USB Drive.
I am remembering why I hate IT and technology and why I left my Computer Science major for Theology after 3.5 years of CS college classes. Anyways, here’s the photo, which is probably unreadable or useless because half the screen is covered by the panic stack trace.
I’m exhausted. I’m gonna take a week break from technology crap after this.
Linux can read BFS natively, it just can’t write it, so you don’t need a FUSE module. But at this stage of the boot, the syslog will not have been written to disk, so there’s no point in doing that. You can install Haiku on a VM on some other OS and use USB passthrough to read the syslogs too, that’s probably a much easier route.
The panic in your screenshot is likely the expected one with on-screen debug output. Please try with the “disable SMP” bootloader option and see if that gets you to the desktop.
Can you type at the kernel debugger prompt?
Yeah, I can type at the prompt. I’ll try with the “disable SMP” option (as well as the on-screen syslog thing). Thanks.
If you can boot with “disable SMP” (with or without onscreen syslog), then please also try booting without that option (and without “onscreen syslog”) and when you get the panic, try the
continue command at the kernel debugger prompt and see if the boot continues.
Ok, I haven’t done the second thing yet, but I can boot with “disable SMP”, but the touchpad and keyboard don’t work. I will reboot and try the second thing now.
Ok, so, running without the “disable SMP” and without the onscreen syslog thing, it was not able to boot up. It showed a few different stack traces, and I just kept putting in “continue” until the 4th stacktrace, and it just sat there without visual change for about 10 minutes or so before I just shut the computer down. Here are the images:
Sounds like something has gone very wrong with SMP on your system. You can open a ticket, but I’m not sure who would be able to debug this without having access to the hardware.
It’s interesting beta4 works, though. Maybe some of the
KDEBUG options enabled on the nightlies but disabled on the beta are somehow causing problems on your system…