lkml.org 
[lkml]   [2006]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.20-rc2

* Andrew Morton <akpm@osdl.org> wrote:

> > [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965

> This is the second report we've had where bit 29 of ->preempt_count is
> getting set. I don't think there's any legitimate way in which that
> bit can get set. (Ingo?)

It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit
28). Nor can i think of any bug scenario barring outright memory
corruption (either hardware or kernel induced) that could cause this.
It's quite hard to trigger bit 29 there via any of the scheduling
mechanisms: either the preempt count would have to underflow massively
/and/ avoid detection during that undflow (sheer impossible) or the
HARDIRQ_COUNT would have to overflow to more than 4096 (again near
impossible to trigger), and simultaneously the softirq and preempt count
would have to overflow by 256 /at once/, or underflow by 1 at once. The
likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in
comparison.

So my guess would still be memory corruption of some sort, or some
really weird compiler bug. We just recently mandated REGPARM on i386 for
example, it would be interesting to know whether an older (say 2.6.18 or
19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the
hardware (the CPU in particular) a bit more.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-26 13:47    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site