Re: Linux 2.6.20-rc2

Ingo Molnar
2006-12-26T12:42:49Z

* 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