Messages in this thread | | | Date | Tue, 26 Aug 2008 21:27:34 +0200 | From | Gerhard Brauer <> | Subject | Re: 2.6.{26.2,27-rc} oops on virtualbox |
| |
On Tue, Aug 26, 2008 at 10:53:38AM -0400, Mathieu Desnoyers wrote: > * Gerhard Brauer (gerhard.brauer@web.de) wrote: > > > > Here is also an archive with guest dmesg and messages.log from such an > > oops when heavy disk io leads to the oops: > > http://bugs.archlinux.org/task/11141?getfile=2445 > > > > Hrm, can you try this ?
Sorry for the delay but i need to build a complete distribution kernel and my machine is not the fastest.
My host: archlinux 2.6.26 P4 2Ghz VirtualBox: Sun xVM 1.6.4 gcc 4.4.1-3
My guest: archlinux 2.6.26
My "tests": I could sometimes boot the guest with the "tricks" (VT-x enabled, acpi off,...). But i always get an oops if i compile something bigger on this guest (ex. virtualbox-modules where the tarball must be untarrt with bsdtar -> disk io) If this happens the next reboot leads always to the early oops (Freeing smp....). Each reboot do this. Then i close virtualbox application, unload/reload vboxdrv from host and start vbox again. Then i could mostimes boot the guest again. But next heavy disk IO leads again to the oops. If i could boot without oops, and reboot or halt the guest, then the next boots are clean.
> 1 - Make sure you kernel is not CONFIG_DEBUG_RODATA Not set.
> 2 - Change the whole text_poke implementation in > arch/x86/kernel/alternative.c to this : With this changes i also get the oops, in all above mentioned tests.
> Then, after having tested (2), try this on top of it : > > In arch/x86/kernel/alternative.c, alternatives_smp_switch() > > Add unsigned long flags; > Change > spin_lock -> spin_lock_irqsave(&smp_alt, flags); > spin_unlock(&smp_alt); -> spin_unlock_irqrestore(&smp_alt, flags);
With our distribution kernel i could change these spin_lock/unlock in alternatives.c. Fist thought was that there was a slightly better behavior (first boot goes on, i could compile something, but next package i build thee opps (heavy io opps) comes again. And then also after reboot the early oops (freeing smp...) Here is a screenie from oops when building something: http://users.archlinux.de/~gerbra/tmp/2008-08-26-210724_724x456_scrot.png
Sometimes (could not be reproduced) the virtualbox app also traps with an error dialog (Guru message), which offers a log from the VM and a scren shot. Maybe this could be helpfull. Log and screenie could be found here: http://users.archlinux.de/~gerbra/tmp/vbox-guru/
> > This will help testing if there is a problem with interrupts coming > shortly after the modification. If it fixes the problem, my guess is > that we should flush the instruction cache (and maybe the data cache ?) > in text_poke and text_poke early when interrupts are off.
From my side i would say: both changes would not solve the oops.
> Mathieu
Regards Gerhard
| |