Terry Lambert wrote:
> Glendon Gross wrote:
> > That's right, guys!  This is FreeBSD after all... so Mr. Lambert is
> > entitled to charge 10K for that bugfix code if he wants.  In fact he is
> > "Free" to do so.  But it's a little pricy for me, although perhaps not for
> > AMD if it means they can fix their cache-paging problems!
> It cost me two weeks to figure out, and both Intel and AMD
> wanted to charge me $$$ to file a problem report.


> Since it's not a FreeBSD problem, you'll forgive me if I
> find it funny that Linux and Windows disables the PSE to work
> around some problems.  It's not that hard to understand or
> work around, if you know where to look, and knowing where to
> look is what will cost them.


> The *other* AMD problem, with AGP and 4K and 4M pages that
> point to the same memory could arguably be a chipset or a
> software problem (depending on whether or not the chipset
> vendor has documented the behaviour before people were let
> loose to write the software -- errata: the difference
> between a software problem and a software workaround to a
> hardware problem).  It's already documented how to work
> around that one; I'm sure a fix is pending for Linux, and
> Windows will probably leave PSE off until they can figure
> out a way to update everyone.

I'm a little confused as to which bugs are which that we're talking
about now.  Which is the one that you're trying to sell the info for?

The issues that I know about:

- interactions between PG_G, CR4_PGE, 4M and 4K pages and TLB flushing
(potentially cross platform issue due to boot time quirks)..  I think we have
a workaround for this in our code already, but I have a better complete fix
for it in a pending change that I'm working on.

- AMD invlpg vs 4MB page bug (AMD bug).  If you invlpg using an address in
the upper 2MB of a 4MB page, the 4MB tlb may not be flushed (we dont suffer
from this (I think) because we do some very suboptimal things with 4MB
pages), versus doing an invlpg at the base address of the 4MB mapping.

- AMD write cache allocation due to speculative writes being cancelled and
then written back later vs no cache snooping on AGP regions.  I'm somewhat
perplexed about this issue, there's lots of conflicting info going around,
a good deal of it which does not make much sense [to me :-)].  I really
dont see what PSE has to do with this for several reasons..  if the page/
region is cacheable, why does a 4MB vs 4K page make any difference?
cacheable vs no-cache-snooping is a recipe for disaster.. why would 4K
pages on a non-coherent region be safer?  Or is the problem that write
allocation happens on uncacheable/non-write-back regions in 4MB pages?  Or
something else?

- hardware prefetch (newer AMD cpus, pentium 4, 0.13 micron pentium3's)
related problems.  (can be solved with PAT and/or MSRR programming).

I'm just trying to figure out if there's something I'm missing.  I know we
do some very dubious things with PG_G at bootup.

"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to