Mailinglist Archive: opensuse-bugs (7763 mails)
| < Previous | Next > |
[Bug 224778] softirq.c#cpu_callback BUG_ON
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Fri, 1 Dec 2006 10:17:10 -0700 (MST)
- Message-id: <20061201171710.8A1ACD0D@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=224778
zach@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zach@xxxxxxxxxx
------- Comment #5 from zach@xxxxxxxxxx 2006-12-01 10:17 MST -------
(In reply to comment #3)
> Any idea why we aren't seeing this on our Xen virtual machines?
Timing conditions different. To reproduce it more easily, you can increase the
size of the compressed init ramdisk. This causes more time to be spent
decompressing during boot, thus opening the window to the point where you allow
timer interrupts before softirqd is started. Eventually in the window, you get
a timer interrupt that schedules an RCU callback via a tasklet. Then softirqd
startup code hits this BUG_ON, but there actually is no bug.
I believe S. Caglar Onur <caglar@xxxxxxxxxxxxx> was able to reproduce this
under Xen as well (unfortunately I can't reproduce his name properly with
Turkish accents here).
Note that with a sufficiently large ramdisk, even native hardware is
vulnerable. Virtual machines simply expose the problem better. Note that a
Xeno-Linux kernel running under Xen is an entirely different case, with
radically different startup timing, and probably won't show the bug, but an
unmodified 2.6.18 kernel under Xen in full virtualization mode will show the
bug.
> And is this patch in 2.6.19? Should it also be included in 2.6.18-stable?
It is in -mm right now, probably going into 2.6.19.1; it should be in
2.6.18-stable if that is still being maintained. (Apologies again, I don't
know what the expiration policy for -stable is on a new release).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
zach@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zach@xxxxxxxxxx
------- Comment #5 from zach@xxxxxxxxxx 2006-12-01 10:17 MST -------
(In reply to comment #3)
> Any idea why we aren't seeing this on our Xen virtual machines?
Timing conditions different. To reproduce it more easily, you can increase the
size of the compressed init ramdisk. This causes more time to be spent
decompressing during boot, thus opening the window to the point where you allow
timer interrupts before softirqd is started. Eventually in the window, you get
a timer interrupt that schedules an RCU callback via a tasklet. Then softirqd
startup code hits this BUG_ON, but there actually is no bug.
I believe S. Caglar Onur <caglar@xxxxxxxxxxxxx> was able to reproduce this
under Xen as well (unfortunately I can't reproduce his name properly with
Turkish accents here).
Note that with a sufficiently large ramdisk, even native hardware is
vulnerable. Virtual machines simply expose the problem better. Note that a
Xeno-Linux kernel running under Xen is an entirely different case, with
radically different startup timing, and probably won't show the bug, but an
unmodified 2.6.18 kernel under Xen in full virtualization mode will show the
bug.
> And is this patch in 2.6.19? Should it also be included in 2.6.18-stable?
It is in -mm right now, probably going into 2.6.19.1; it should be in
2.6.18-stable if that is still being maintained. (Apologies again, I don't
know what the expiration policy for -stable is on a new release).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
| < Previous | Next > |