lkml.org 
[lkml]   [1996]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.079 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site