On Tue, Dec 26, 2006 at 01:40:19PM +0100, Ingo Molnar wrote:
> 
> * 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.

This is my year-old workstation that I've build from good parts (Asus
A8N-SLI premium, OCZ memory), not overclocked, not overheated (it is
in a Antec P180 case with 12 cm fans -> CPU max is 43'C when not used
for my hour-long simulations).  I will leave it do memtest for a
couple hours.

The compiler is "gcc version 4.1.2 20061028 (prerelease) (Debian
4.1.1-19)" and the .config is attached.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
      http://geekz.co.uk/schneierfacts/fact/163