Messages in this thread | | | Date | Tue, 3 Dec 1996 08:05:59 -0500 (EST) | From | Ion Badulescu <> | Subject | Re: Strange OOPS in 2.0.25 kernel |
| |
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]
Ionut
-- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt.
| |