Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Apr 2004 10:16:00 -0400 (EDT)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        alpha@FreeBSD.org
Subject:   Re: pmap_emulate_reference() panics still ongoing
Message-ID:  <16527.48288.319462.214843@grasshopper.cs.duke.edu>
In-Reply-To: <20040428135850.GA43106@ip.net.ua>
References:  <20040428084120.GA25958@ip.net.ua> <16527.42479.941859.703698@grasshopper.cs.duke.edu> <20040428135850.GA43106@ip.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

Ruslan Ermilov writes:
 > On Wed, Apr 28, 2004 at 08:39:11AM -0400, Andrew Gallatin wrote:
 > > 
 > > Ruslan Ermilov writes:
 > >  > Andrew,
 > >  > 
 > >  > This is with latest src/sys/alpha/alpha/pmap.c,v 1.146.
 > >  > 
 > >  > db> where
 > >  > Debugger() at Debugger+0x38
 > >  > __panic() at __panic+0x228
 > >  > pmap_emulate_reference() at pmap_emulate_reference+0x15c
 > >  > trap() at trap+0x3dc
 > >  > XentMM() at XentMM+0x2c
 > >  > --- memory management fault (from ipl 0) ---
 > >  > --- user mode ---
 > > 
 > > Damn.  Did the change make it any worse for you?
 > > 
 > No, I can't say this made things any worse.  ;)

Good.

 > This is not a very fast runner (166MHz EV4, 64MB RAM, swap
 > is used).  Since I've upgraded it to 5-CURRENT, running the
 > GENERIC kernel, my 5 attempts to build world ended up with
 > this panic (often the panic message was unreadable, this one,
 > after I've upgraded kernel to the latest pmap.c, was probably
 > a good exception).  Now I've built the debug version of the
 > kernel.  Will it be of some help?

Wow, and I thought my 600MHz ev67 was slow.  At least you can
reproduce this -- I can't.

Given that I always run a bwx-enabled kernel, and I never see it, I
wonder if there might be some corruption caused by 8 or 16 bit data
fields in the vm or pmap systems which share a 32-bit word, but which
are separately locked.  I'm thinking that the read-modify-write which a
non bwx kernel needs to do could lead to data-corruption in this case.

I don't see anything immediately, but then I don't know the vm system
very well.

 > (Hardly relevant, but it was happy running 4.10-RC.)

Very relevant -- it means the bug is new to 5.x

Drew



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