Re: data corruption with current (maybe sis chipset related?)

Mark Santcroos wrote:
> On Thu, May 08, 2003 at 02:43:15PM -0500, Alan L. Cox wrote:
> > 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.
> 
> This is not my expertise, so take me with a grain of salt :)
> 
> I think Terry also already mentioned this. PSE for the 4M pages and PG_G
> for the global pages.
> 
> I also think that last time we concluded that they are both needed.

Yes, but Alan is correct in his assessment.  You were having
two seperate problems.  One was the CPU bug, related to PSE,
and the other was a problem that *somewhere* in the code, it's
actually necessary to turn of PG in %CR0 before loading a
certain global page.  You can workaround the problem by adding
a loop to go through the pages that have the PG_G bit set, and
then reset the PG bit on them, after PG in %CR0 has been
turned on.

I didn't bother to do this because it's a hack, and the code
in question really needs to be refactored to fix the problem;
so the cheap solution was to just disable it.  Sorry.  8-(.


> He mentioned I guess that while using only one of them might "solve" the
> problem, but that would only be hiding the problem for a bit longer.

The problem was trap 12's.  It's still possible that you would
get trap 12's, but they would be from a different cause than
the bug.  In fact, I remember specifically that you tested a
case that caused me to believe you would be bitten (I can't
remember what it was off the top of my head; I can dig it out
of my archives, if you need it).

-- Terry