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

    * Andrew Morton <> 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-12-26 13:47    [W:0.022 / U:26.972 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site