Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Dec 1995 02:40:52 -0800
From:      David Greenman <davidg@Root.COM>
To:        Peter Dufault <dufault@hda.com>
Cc:        gibbs@freefall.freebsd.org, m.sapsed@bangor.ac.uk, hm@hcs.de, freebsd-bugs@freebsd.org
Subject:   Re: Problem with FreeBSD 2.1.0-RELEASE 
Message-ID:  <199512191041.CAA00152@corbin.Root.COM>
In-Reply-To: Your message of "Tue, 19 Dec 95 03:42:52 EST." <199512190842.DAA19622@hda.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> >> Fatal trap 12: page fault while in kernel mode
>> >> Fault virtual address              = 0x60
>> >> Fault code                         = supervisor read, page not present
>> ...
>> >> Stopped at _incore+0x48: cmpl %esi, 0x48(%ebx)
>> >
>
>...
>
>> 
>>    This is a "can't happen" panic.
>
>I don't think so.  The offset to the b_lblkno was 72 (0x48) and
>the fault address was 0x60, so the bp in %ebx was 0x24 at the check
>for NULL.

   Oh, sorry - my quick base conversion went astray somewhere. :-)
   Okay, the problem looks like the buffer is getting trashed after being put
on the hash list.
   In order to diagnose this problem, I suggest adding a check in incore() for
bp->b_hash.le_next != NULL && bp->b_hash.le_next < (struct buf *) 0x100 at the
bottom of the while loop (before bp is assigned) and if this become true, print
the value of bp. Then either using DDB or more printf's, print out the
contents of the buffer. What to look for? ...I don't really know, but this
should at least give some clues about the origin of the buffer and the extent
of the corruption.
   My guess is that a temporary bp is getting put on the hash list and then
later freed (or freed, then put on the hash list, the remalloced and then
corrupted).

-DG



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512191041.CAA00152>