Any work around to 2.1.0's kernel panic?

[ToddAndMargo]

Hi All,

Anyone know of a workaround to 2.1.0's new and exciting
feature know as a "kernel panic" when booting up an XP guest
from a Cent OS 5.2 host?

Many thanks,
-T


For details see: http://www.virtualbox.org/ticket/2827

Host: CentOS 5.2 (RHEL 5.2 clone)

$uname -r: 2.6.18-92.1.22.el5

Guest: Windows XP Pro Service Pack 3

My mobo: http://www.supermicro.com/products/moth ... DAL-E+.cfm

My chipset: http://www.intel.com/products/server/ch ... erview.htm

[Sasquatch]

You state in the bug report that you have VT-x enabled. What happens if you disable it?

[ToddAndMargo]

You state in the bug report that you have VT-x enabled. What happens if you disable it?

I took me two hours to restore everything from backup and revert to
2.0.6. I though of one last VTx test but decided against it due
to a possible file system corruption from the kernel panic.

So, I guess my answer is, I don't know and I am too chicken to try.
Plus I lost a lot of billable hours to it already. VTx has always worked
under previous VBoxes

-T

[SteveCGElliott]

I also see v2.1 getting kernel panic on RHEL5.2 (2.6.18-92.1.22.el5)

http://www.virtualbox.org/ticket/2829

My symptoms are only when Host Networking is enabled on a connected NIC.

Can anyone suggest how more diagnostic information can be gathered?

Is there any VirtualBox trace or extended logging?

Steve

[ToddAndMargo]

I also see v2.1 getting kernel panic on RHEL5.2 (2.6.18-92.1.22.el5)

http://www.virtualbox.org/ticket/2829

My symptoms are only when Host Networking is enabled on a connected NIC.

It is my impression that the Virtual Box developers do not test on Red Hat Enterprise Linux (or Cent OS). They just compile it up and wait for you and me to bitch.

I pity anyone in RHEL/CentOS 4.x, as all you have to do it stick a USB drive in the hole and you kernel panic. (I upgraded a server to get around it.)

Can anyone suggest how more diagnostic information can be gathered?
Is there any VirtualBox trace or extended logging?
Steve

Since your bug is probably going to be tagged as a duplicate of mine, I'd upload your machine's XML file and its log file to both of our bug reports. My files were found in

~todd/.VirtualBox/Machines/VB-WinXP/VB-WinXP.xml
~todd/.VirtualBox/Machines/VB-WinXP/Logs/VBox.log

[TerryE]

Todd, downgrade to 2.0.6 until the dev team releases a stable 2.1

[ToddAndMargo]

Todd, downgrade to 2.0.6 until the dev team releases a stable 2.1

That is what I did. It was a pain in the a-- to reinstall all my bridge networking (good thing I kept my notes!).

I really, Really, REALLY wish the developers would test their stuff on RHEL/CentOS before they release it.

-T

[chronoboy]

As I can see, this issue is related with people also losing their keyboards.

When my kernel panics, I was luckily enough one time on my console(tty1), and it outputed a huge kernel panic. I needed to power off and power back on to get up and running.

It appears to be tied in with this module: vboxnetflt

The host networking filter. I managed to re-produce the kernel panic many times, when trying to install a new OS with host networking. My last attempt was when I booted my Debian Etch VM, as soon as it reached "Starting Networking...", I heard my console beep as the kernel panic occurred. Funny thing is, my mouse still worked, and my VM continued to boot as well. Only my keyboard was affected, both on the host and in the guest. I was able to shutdown the guest safely by clicking the close box and choosing to simulate an ACPI power off event. On the host, I was still able to open applications, but just no keyboard. For now, it's easy to say, do not use host networking until this issue has been resolved.

[TerryE]

chronoboy, if you've tied this one down repeatedly then check out the tickets and create/update accordingly. You probably know this, but you need to register for a wiki user account (this is different to a forum account sorry) if you haven't already done so, and then you can use the public Bugtracker in update mode. Also don't forget to attach your VBox.log etc.

[chronoboy]

My topic got locked, so I'm here now.

Can you guys which are experiencing the same issue, except using a different distro check your /var/log/kern.log for me? You can only read this file as a root user, it has the detailed information of the kernel panic. The log should persist on reboot. I submitted a new ticket, which has a small dump of this log in it. I see no one else has provided this dump besides me, I wonder if they are all very similar.

The kernel panic happens when the guest attempts to communicate using the HostIF. For example, a DHCP query would cause it to happen during guest boot if the guest is configured for DHCP. Setting the guest to a static IP address will still cause a kernel panic, if a program in the guest attempts to communicate using the HostIF. This occurs on any host interface used, even the TUN device. This makes it difficult for a host and a guest to correct communicate with each other using HostIF.

I managed to figure the above out, by using a very stripped down Debian Etch image.

If you would like to view the ticket I submitted to see if your issue is exactly the same, can you please update your ticket with a kern.log and close my ticket for duplication. Also has anybody been able to obtain a kernel dump when this issue occurs? This is only thing which I am not sure how to create exactly.

http://www.virtualbox.org/ticket/2891

I hope there is a resolution really early next year, as Host networking is very important for many applications.

[perennial]

The fix given in http://www.virtualbox.org/ticket/2827 (amongst others) helped for myself (so far at least ) . Haven't encountered the problem running fedora 10 i386 and ubuntu 8.04 i386 guests on a x86_64 fedora 10 host, before got kernel panic within minutes of starting a guest using HostIF (running 2.6.27.9-159.fc10.x86_64 so quite after 2.6.20 though).