re: UltraSPARC III... Stability issue ?

[matthew green <mrg%eterna.com.au@localhost>]

> > Possibility #1: Something is broken in pseg_set().  
> >     (Oh, wonderful.  Someone wrapeed the pseg() routines in a mutex 
> >     even though they use compare and swap instructions to be SMP 
> >     safe.)
> 
> that would be me -- they don't work without it.  i forget the
> failure modes, but the system was unstable without this mutex.

this came in here:

---
revision 1.327
date: 2010-03-09 22:57:22 -0800;  author: mrg;  state: Exp;  lines: +9 -8;
branches:  1.327.2;
XXX: workaround we'd like to remove when pmap / uvm locking is cleaned up:

- rename pseg_get() and pseg_set() to pseg_get_real() and pseg_set_real().
- if USE_LOCKSAFE_PSEG_GETSET is defined, which it current is by default,
  define pseg_[gs]et() in terms of functions that take a new pseg_lock
  mutex at IPL_VM while calling into the real functions.

this seems to avoid the pseg_set() crashes we've seen:
  1 - spare needed, when pseg_get() just worked for this pmap
  2 - the 2rd ldxa via ASI_PHYS_CACHED in pseg_set() loads garbage
      into %o4, and causes the 3rd ldxa to fault
---

i suspect it can now be removed due to the merge of rmind-uvmplock
branch, but i don't know i've tested since that was merged.

it would be nice to get rid of it.  i suspect the real problem is
that while pseg_set() works atomically on each entry it does not
work atomically across an entire translation and if a pseg_get()
runs concurrently to pset_set(), it can return partial data, and
trigger a fault.  but as you can see, it's 4 years ago now..


i see about testing with this removed.  it may only be OK for parts
that operate via pmap*() calls, since the uvmplock change was
largely about ensuring all pmap operations were done under the
owning uvm object's lock, which allowed removing multiple other
layers of locking that became redundant.


.mrg.