Date: Sat, 04 May 2002 10:37:00 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Michael Smith <msmith@freebsd.org> Cc: acpi-jp@jp.FreeBSD.org, current@freebsd.org Subject: Re: Odd problem with MTRR and ACPI Message-ID: <200205041037.aa97524@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 03 May 2002 23:08:31 PDT." <200205040608.g4468Vh00626@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Heh, finally someone that's actually trying to fix this. 8) ;-) > The "right" thing is going to be to fix the MTRR code to preserve the > extra MTRR bits; I've tried a few times to get some documentation on what > these other bits mean without any luck. The code I added to the MTRR stuff recently can almost do this using a "unknown" mtrr type. I might also add an "immutable" type which is set by default for unknown values and must be explicitly cleared with memcontrol. That way people can change the unknown MTRR values if they really want to, but won't end up doing it by accident. > You'll need to hide these bits from the layers above and just hang on to > them. Beyond that, I really don't have any great ideas unless/until you > can find out what the bits do. I did find some AMD errata docs which hinted at a problem involving 4MB pages, MTRR and SMM. (Search for "MTRR SMM athlon ASEG" on google and you should get the PDF - there are two pages describing errata involving ASEG and TSEG. Does anyone know what ASEG and TSEG are?) I tried using a kernel with DISABLE_PSE but the problem seemed to persist. However, the docs do hint at there being a link between SMM and MTRRs for the Athlon. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200205041037.aa97524>