POISON_BYTE is 0x5a. Something in devfs is using a pointer from a data
structure that was already free'd, and was thus corrupted by poisoning.
(the above is almost certainly just a pointer dereference off 0x5a5a5a5a
with an offset of 4 for some entry at the beginning of a structure,
which is why you get the final "5e" in the page fault address).
>It boots OK with devfsd when CONFIG_DEBUG_KERNEL is not set.
>It boots OK without devfsd when CONFIG_DEBUG_KERNEL is set (then devfsd
>can be started after login).
Well, not poisoning the free'd memory makes it "work" only in the sense
that usually the free'd memory hasn't been re-allocated yet, so you
don't see the bug even if it is still there.
Richard Gooch probably wants a full stack trace, with symbols. Which
should show it fairly clearly. At least EIP and the first few "stack
trace" entries..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/