Re: Linux 2.6.20-rc2

[Ingo Molnar <mingo@elte.hu>]

* 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