Alan Cox wrote:
> Its a deliberate debugging trap.
>
> > #if DEBUG
> > if (cachep->flags & SLAB_POISON)
> > if (kmem_check_poison_obj(cachep, objp))
> > BUG();
> > ^^^^^^ This one is triggered
>
> Someone freed memory and then scribbled on it.
>
> The first thing useful here is to know which drivers you were using shortly
> before the oops
Sorry, I really can't reproduce it; as I said, it was nothing unusual I did
(with respect to loaded drivers, which I always have quite a lot of), and it
happened while doing some editing in vi, which surely doesn't have any bad
impact, I hope dearly :-)
But it might as well have been some cron job or so, I'll try to check better
when this happens again. Any more debugging hints you could give me?
Mike Galbraith wrote:
> blogd?
It's SuSE-specific I think, something to log boot messages to a console.
This SHOULD have finished at this point, however - it's only needed during
the boot process, so I don't know why this is there...
> In any case, one thing you can do is to disable the BUG() and
> see if whoever scribbled on the freed area has a reference to
> it still and trips over the damage poison or the new owner did
> to what he thinks is his data.
Can you explain that in more detail, what I should do and what is expected to
happen then?
Greetings,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
