> In every case the EIP (extended instruction pointer) indicates that
> the code was attempting to access a value in memory. The address
> of that value (according to the instruction and the value of the index
> register used) is different by the 2 most significant bits from what
> the processor attempted to access. That is noticed by the most
> significant nibble changing from 0 to c in every oops as I marked by the
> *'s in the context above.
No, this is a real bug - a null pointer passed in %ecx which the kernel
tries to dereference. It gets it from
p = page->firstfree;
in kmalloc.c; for some reason, p is NULL, so p->bh_flags oopses.
I tried to track it down, but the bug (if it exists) is not obvious and I
dind't have much time to spend on this, so I kind of waited for someone
else to come up something.
2.0.x always seems to add 0xc0000000 to the virtual address, but it
doesn't really mean anything. As I said, the dereference in this case is
of %ecx, which is 0..
[I might be wrong about the 2.0.x behavior, as I didn't get many oopses
myself :), but I did check the archive of linux-kernel and all oops
reports were exhibiting this 0xc000xxxx virtual address]
Ionut
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.