data corruption with current (maybe sis chipset related?)

[Alan L. Cox]

Mark Santcroos wrote:
> 
> On Thu, May 08, 2003 at 04:05:29PM +0200, Heiko Schaefer wrote:
> > > On Tue, May 06, 2003 at 07:16:32PM +0200, Mark Santcroos wrote:
> > > > On Tue, May 06, 2003 at 04:41:30PM +0200, Heiko Schaefer wrote:
> > > > > does anyone know of any (freebsd-current) issues that might be causing
> > > > > this - or have any idea on how i can further rule out anything of this
> > > > > kind ?
> > > >
> > > > Try this in your kernel config:
> > > >
> > > > options           DISABLE_PSE
> > > > options           DISABLE_PG_G
> >
> > ok. i have done my copying and checksumming orgy with these options in the
> > kernel - and it seems that i do not get any corruption anymore.
> > i will re-run my test once again now, just to be safe.
> >
> > after that: does it make sense to single out which of the two options is
> > the relevant one ?
> 
> No.
> 
> > i'm also clueless what exactly these options do, and what exactly we've
> > ruled out now. could the lack of data-corruption just be some side-effect?
> 
> They prevent the usage of 4M pages. It's a CPU bug that will cause data
> corruption if enabled.
> 

For the record, this is not completely correct.  DISABLE_PSE does
control the use of 4MB pages.  DISABLE_PG_G is, however, something
entirely different.  Normally, on a process context switch TLB entries
for the old address space are flushed.  If a TLB entry corresponds to an
in-kernel virtual-to-physical mapping, there is no reason to flush that
entry because all processes share the same kernel address space. 
Setting the "G"lobal bit on a page table entry accomplishes this.  In
other words, the TLB entry persists across context switches. 
DISABLE_PG_G disables this.

The problem with PG_G is that the "flush all" TLB entries operation,
just like a context switch, has no effect on entries marked as global. 
Such entries have to be flushed by specifying their address in a "flush
single page" operation.  Sometimes the failure to flush an entry is
covered up by a combination of DISABLE_PG_G and a lucky context switch.

So, in summary, it does make sense to try these options separately.

Alan