pmap_emulate_reference() panics still ongoing

[Andrew Gallatin]

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