Regression: r27752 broke booting

[luroh]

Since hrev27752, I get the following after the red rocket icon has lit up: "PANIC: page fault, but interrupts were disabled. Touching address 0x00000020 from eip 0x8003ac1b"

Picture and serial output from hrev27757 attached.

[bonefish]

If you build your images yourself, please update to hrev27758 and enable tracing in src/system/kernel/module.cpp (uncomment the #define TRACE_MODULE line).

[luroh]

Done, serial_r27758.txt attached.

[bonefish]

Thanks! I fixed a bug in hrev27760 that might be related or even cause this bug. If the problem still persists, please provide a new serial output, since I also added some more debug output.

[luroh]

Still with us, serial_r27761.txt attached.

[luroh]

FWIW, same happens on real hw as well.

[bonefish]

I've no idea what's wrong. Everything works fine here, in VMware as well as on real hardware, gcc 2 and gcc 4. The module debug output from your syslog looks as it should.

The stack crawl suggests that gUSBStack in the USB bus manager module is NULL. According to the module debug output the initialization function that should set it is invoked, it is not uninitialized later, nor is a second image with the USB bus manager loaded. So everything should be fine.

You could try to also enable USB tracing (uncomment the #define TRACE_USB in src/add-ons/kernel/bus_managers/usb/usb_p.h). Maybe Michael has an idea.

[luroh]

It's like deja vue all over again. ;)

Thanks for the advice, USB tracing enabled in serial_r27763.txt.

[luroh]

bonefish: Reading a recent commit log of yours, I guess you might be building Haiku with -j2 or some such option, correct? Now, I'll be the first to admit that I don't know the first thing about jam, but I do know that I have had problems with concurrent jam jobs in the past, i.e., ending up with various degrees of different program behaviour. This prompted me to go back to jam -q and the occasional jam -aq. Could this be the cause of what we're seeing here? You not being able to repeat the problem, I mean.

[anevilyak]

Hi luroh,

Just curious, when it KDLs, can you grab the output of team_images 1 from the kernel debugger? I'm wondering if the same thing is happening that happened to me where the PCI bus manager's image was loaded twice, which resulted in a NULL ptr due to the second image not having been completely initialized. I can't test myself right now due to systems being packed for moving.

[luroh]

anevilyak: Hi! Doesn't look like it, team_images_1.txt excerpt attached.

[julun]

Hi,

for me it's a bit different, i don't get that kdl really over here. My vmx file has been changed to use 2 cpu's and 512 mb ram. Reverting this back gives the KDL as in the panic.png screenshot, but having two cpus it simply stops, no kdl. About the jam thing, I'm using it like jam -aqj 4 without any problems since months.

Karsten

[luroh]

julun: I can confirm, numvcpus = "2" makes it hang at the red rocket, pressing F12 does nothing.

[julun]

Hi,

I've uploaded such an unbootable image, one can get get it here:

www.julun.de/haiku/haiku.tar.bz2

Karsten

[bonefish]

(In #2778) Duplicate of #2776.

[bonefish]

My VMware is already configured for 1 CPU, but I can reproduce the problem with qemu.

[mmlr]

There is (broken) code in the USB module to handle R5 where the module is loaded multiple times. If that was the case and one of the modules would get unloaded afterwards (which never happens in case of R5) a crash would occure. But from the supplied syslogs here, it doesn't look like this is happening at all, because the corresponding message "usb_module: uninit" is not present and also it doesn't look like the module is loaded multiple times at all. I'll #ifdef that code out anyway though.

[bonefish]

Fixed in hrev27767.