Kernel panics popping up in latest nightlies

[ddavid123]

For the last week, I have been seeing many kdebug messages pop up in the nightly anyboot build! I am not an expert, but it seems like there is an issue with paging. I have disabled the Virtual memory option in Haiku and rebooted many times with the same results. Every time I do "installoptionalpackage -l and -a <package> I get this kdebug screen.

Sometimes when I am in the middle of the boot sequence I get this error

And sometimes I get the following error just before the desktop is displayed.

I wish I had more information, but that is all I have.

P.S. Even though VirtualBox says it is Alpha 3, ignore it. I had installed Alpha 3 last month and am using the same VM. I am re-initializing the partition with every reinstall! :)

[ddavid123]

I should also say that this is happening in VM and in bare hardware as well.

[bonefish]

Interestingly the kernel itself hasn't changed at all for five weeks. If you can reproduce the issue more or less reliably, it would be great, if you could do a binary search to narrow down the responsible revision range.

Do you emulate multiple CPUs/cores in VirtualBox? Have you changed the configuration in any way recently?

[ddavid123]

I can reproduce the issue reliably when I evoke the "installoptionalpackage -l or -a The kdebug message pops up every time. What is more, I can not install webpositive or anything else because of this bug. It doesn't show most of the packages. And if I try to do "installoptionalpackage -a webpositive" anyway it will say it is not installable or something.

Other than that example, it sometimes throws an error when I try to run Vision. Other than that, it is very frequent and seemingly random, even while doing nothing but Haiku running.

In the Virtual Box setup, I did enable the second cpu core recently (3 days ago), but I have reinstalled Haiku 3 times since then. Also this is happening on bare hardware as well and nothing has changed as far as hardware config in 2 years.

[bonefish]

Just to be clear: Did/does the problem occur with Virtual Box and a single CPU? And do I understand you correctly that on real hardware the bug didn't show up until recently as well? I just want to make sure that it's indeed a recently introduced issue and not just one that has existed for much longer, but appears only on multi-processor setups.

It is important to get a revision range (last working - first non-working) as narrow as possible. As said before the kernel hasn't changed for five weeks and the VM related code hasn't been touched even longer, so this could be some side effect of a change in some other component (boot loader, drivers) which may not seem related. If the bug was indeed introduced only a week or so ago, it should take only testing a few nightlies to find the first buggy one, which would help a lot.

[ddavid123]

I discovered the problem. I have been running Alpha 3 on the Laptop bare hardware until last week. When I installed Haiku nightly hrev42552 on it last week,I had issues with the kdebug popping up and with every nightly build since. Just 10 minutes ago, I disabled the second cpu core in virtual box and ran the hrev42552 build and I have no problems!

Since my laptop has an Intel dual core processor it could be that Haiku since Alpha 3 can not work properly with both cores enabled. So it seems the problem isn't just a week old, it was a week ago I stopped using Alpha 3 on my laptop and enabled the second core om my desktop pc Virtual Box system. That is why the problem seemed to happen last week!

I am now able to run Haiku hrev42593 in VirtualBox with only one core enabled.

[bonefish]

Ticket #8345 documents the same assert as the third picture, just for the PAE code.

[bonefish]

I have tried to reproduce the issue with VB 4.0.12 and different combinations of CPU count (2 to 8) and amount of memory (256 MiB to 4 GiB). I also tried with "Nested Paging" disabled. None triggered the KDL.

ddavid123, can give you virtual machine and host system specs, please.

[anevilyak]

We're actually observing this issue 100% reproducibly on boot with the ARM port on qemu. In the latter's case it occurs while tearing down the area for the USB PMA (since USB fails to initialize due to not finding the PCI bus manager). In our case, what appears to happen is that the page in question does not in fact have any mappings, but does have a wired count of 1. We initially assumed that this might pertain to incomplete reporting of the accessed/modified flags in ARMVMTranslationMap32Bit since the ARMv5/v6 cores we're currently working with don't support those bits in hardware and we'll have to do sw emulation of them, but if this is a previously known problem then it's possible we're simply reliably triggering whatever the corner case is in the VM.

[palmr]

Screenshot of what I see

[palmr]

I attempted to set up a VM today and got a kernel panic similar to ones here. DaaT on IRC suggested that I post my details here.

I was attempting to set up a Haiku VM using VirtualBox-4.2.4-81684 and the zipped ISO of Haiku R1/aplha4 (hrevr1alpha4-44699). My hardware has 4 CPUs and 8GB of RAM, and runs 64bit Windows 7.

My Virtual Box config for the Haiku VM is shown in the screenshot I attached: https://dev.haiku-os.org/attachment/ticket/7904/Haiku-KernelPanic-palmr-1.gif I got that message right after the boot screen and before the installers language picker.

To get it running and installed I changed the VM to 1 CPU, but it seems it works fine with 3 and 4 CPUs as well.

[Ziusudra]

Also seeing this with the alpha4.1 vm image.

Edit: VirtualBox 4.2.6 hrev82870

Host: Turion 64 X2 TL-62 2.1GHz, 3Gb, Vista Home Premium 32bit SP2

Guest: 2 core, 1Gb, 32Mb video, VT-x+Nested Paging+PAE

Also seen with 1 core and various combinations of accel options. In addition to seeing the panics in VMCache::Delete and X86VMTM32Bit::Map, see attached panic in X86VMTM32Bit::UnmapArea.

installoptionalpackage -l seems to be a reliable trigger. Edit: or not

Edit: Cannot reproduce with only one core, was either wrong about having seen it then or it is very rare.

[kallisti5]

I think #8345 may be related to this... thoughts?

[bonefish]

Replying to kallisti5:

I think #8345 may be related to this... thoughts?

Please cf. ​http://dev.haiku-os.org/ticket/8345#comment:13 and ​http://dev.haiku-os.org/ticket/8345#comment:24.

[diver]

Got exactly the same 3 back traces in hrev45407 / VirtualBox 4.2.10 with io-apic + 2 cores.

[pulkomandy]

The current ARM port gets past this (and was the only 100% reliable reproductible one). Does it still happen on virtual or real x86 hardware?

[waddlesplash]

#8345 was fixed, and it was a memory corruption in VM code which was probably the same underlying cause. I don't think anyone has seen this since; so closing as fixed.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone