Re: Strange OOPS in 2.0.25 kernel

Ion Badulescu (
Tue, 3 Dec 1996 08:05:59 -0500 (EST)

On Mon, 2 Dec 1996, Tyson D Sawyer wrote:

> 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]


  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.