Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 May 2002 21:44:35 -0700
From:      Jordan K Hubbard <jkh@queasyweasel.com>
To:        Darren Pilgrim <dmp@pantherdragon.org>
Cc:        Morsal Rodbay <morsal@swipnet.se>, C J Michaels <cjm2@earthling.net>, Greg Lehey <grog@lemis.com>, FreeBSD Questions <questions@FreeBSD.ORG>, FreeBSD Hackers <hackers@FreeBSD.ORG>
Subject:   Re: Does FreeBSD have a problem with some AMD processors?
Message-ID:  <1B83B87E-7451-11D6-8623-0003938C7B7E@queasyweasel.com>
In-Reply-To: <3CF6D4B5.64C81220@pantherdragon.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I haven't read the AMD errata docs so I can't comment on that, but it 
appears to be an issue with AMD CPUs and certain support chipsets, I 
believe the early VIAs.  Reading the cvs logs for the MTRR  support 
code will certainly yield more detailed information (and author 
attribution) than I've provided.  In fact, here, I'll simply do it for 
you. :-)

RCS file: /home/ncvs/src/sys/i386/i386/i686_mem.c,v
Working file: i686_mem.c
head: 1.14
----------------------------
revision 1.14
date: 2002/04/14 20:13:08;  author: dwmalone;  state: Exp;  lines: +53 
-32
Make the MTRR code a bit more defensive - this should help people
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).

Here's a description of the problem and my fix:

         The problem with the old MTRR code is that it only expects
         to find documented values in the bytes of MTRR registers.
         To convert the MTRR byte into a FreeBSD "Memory Range Type"
         (mrt) it uses the byte value and looks it up in an array.
         If the value is not in range then the mrt value ends up
         containing random junk.

         This isn't an immediate problem. The mrt value is only used
         later when rewriting the MTRR registers. When we finally
         go to write a value back again, the function i686_mtrrtype()
         searches for the junk value and returns -1 when it fails
         to find it. This is converted to a byte (0xff) and written
         back to the register, causing a GPF as 0xff is an illegal
         value for a MTRR byte.

         To work around this problem I've added a new mrt flag
         MDF_UNKNOWN.  We set this when we read a MTRR byte which
         we do not understand.  If we try to convert a MDF_UNKNOWN
         back into a MTRR value, then the new function, i686_mrt2mtrr,
         just returns the old value of the MTRR byte. This leaves
         the memory range type unchanged.

I'd like to merge this before the 4.6 code freeze, so if people
can test this with XFree 4 that would be very useful.

PR:             28418, 25958
Tested by:      jkh, Christopher Masto <chris@netmonger.net>
MFC after:      2 weeks


- Jordan
On Thursday, May 30, 2002, at 06:41PM, Darren Pilgrim wrote:

> Jordan K Hubbard wrote:
>>
>> I'll bet you wouldn't have any trouble running -stable on it.  There
>> was a problem with MTRR support which still needs a little fixing in
>> order to shut down properly but that's nowhere near as bad as X not
>> running.  Fix should be in FreeBSD 4.6 as well.
>
> The MTRR issue you're referring to, is this related to the one in the
> AMD errata docs about SMM TSEG and large page mappings?  Which CPUs
> does this bug affect?  Is it AMD specific at all?
>
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1B83B87E-7451-11D6-8623-0003938C7B7E>