From: Gerhard Brauer <gerhard.brauer@web.de>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.{26.2,27-rc} oops on virtualbox
Date: Tue, 26 Aug 2008 21:27:34 +0200 [thread overview]
Message-ID: <20080826192734.GC5300@tux1.brauer.lan> (raw)
In-Reply-To: <20080826145338.GA8601@Krystal>
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
next prev parent reply other threads:[~2008-08-26 19:27 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-20 19:29 Luiz Fernando N. Capitulino
2008-08-21 21:34 ` H. Peter Anvin
2008-08-22 6:42 ` H. Peter Anvin
2008-08-22 6:50 ` Ingo Molnar
2008-08-22 14:39 ` Luiz Fernando N. Capitulino
2008-08-22 15:34 ` Mathieu Desnoyers
2008-08-22 16:29 ` Luiz Fernando N. Capitulino
2008-08-22 16:35 ` Mathieu Desnoyers
2008-08-22 17:20 ` Luiz Fernando N. Capitulino
2008-08-22 18:11 ` H. Peter Anvin
2008-08-22 19:40 ` Luiz Fernando N. Capitulino
2008-08-22 20:31 ` H. Peter Anvin
2008-08-22 20:55 ` Luiz Fernando N. Capitulino
2008-08-22 20:57 ` Luiz Fernando N. Capitulino
2008-08-22 21:08 ` H. Peter Anvin
2008-08-26 14:18 ` Gerhard Brauer
2008-08-26 14:53 ` Mathieu Desnoyers
2008-08-26 16:09 ` Luiz Fernando N. Capitulino
2008-08-26 16:13 ` Luiz Fernando N. Capitulino
2008-08-26 17:18 ` Mathieu Desnoyers
2008-08-26 17:32 ` H. Peter Anvin
2008-08-26 18:02 ` Luiz Fernando N. Capitulino
2008-08-26 18:15 ` Mathieu Desnoyers
2008-08-26 19:52 ` H. Peter Anvin
2008-08-26 20:34 ` Gerhard Brauer
2008-08-26 20:48 ` Mathieu Desnoyers
2008-08-26 21:25 ` Gerhard Brauer
2008-08-26 21:35 ` Mathieu Desnoyers
2008-08-26 21:51 ` H. Peter Anvin
2008-08-27 0:13 ` Gerhard Brauer
2008-08-27 19:13 ` Luiz Fernando N. Capitulino
2008-08-27 23:33 ` Mathieu Desnoyers
2008-08-28 13:30 ` Luiz Fernando N. Capitulino
2008-08-31 9:29 ` Gerhard Brauer
2008-08-31 13:28 ` Stefan Lippers-Hollmann
2008-08-31 14:03 ` Gerhard Brauer
2008-08-31 14:09 ` Luiz Fernando N. Capitulino
2008-09-21 13:41 ` Gerhard Brauer
2008-09-22 9:51 ` Ingo Molnar
2008-09-24 13:24 ` Luiz Fernando N. Capitulino
2008-08-28 13:50 ` Gerhard Brauer
2008-08-26 19:27 ` Gerhard Brauer [this message]
2008-08-26 16:02 ` Luiz Fernando N. Capitulino
2008-08-26 16:40 ` Gerhard Brauer
2008-08-22 17:16 ` H. Peter Anvin
2008-08-22 17:45 ` Mathieu Desnoyers
2008-08-22 17:57 ` H. Peter Anvin
2008-08-22 19:10 ` Luiz Fernando N. Capitulino
2008-08-22 19:14 ` H. Peter Anvin
2008-08-22 19:18 ` H. Peter Anvin
2008-08-22 19:42 ` Luiz Fernando N. Capitulino
2008-08-22 14:28 ` Luiz Fernando N. Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080826192734.GC5300@tux1.brauer.lan \
--to=gerhard.brauer@web.de \
--cc=hpa@zytor.com \
--cc=lcapitulino@mandriva.com.br \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®