Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Apr 2002 13:19:13 -0700 (PDT)
From:      David Malone <dwmalone@FreeBSD.org>
To:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/sys memrange.h src/usr.sbin/memcontrol memcontrol.c
Message-ID:  <200204142019.g3EKJD294534@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
dwmalone    2002/04/14 13:19:13 PDT

  Modified files:
    sys/sys              memrange.h 
    usr.sbin/memcontrol  memcontrol.c 
  Log:
  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 have seen one side effect of the fix, which is that ACPI calls
  after X has been run seem to hang my machine. As running X would
  previously panic the machine, this is still an improvement ;-)
  
  I'd like to MFC this before the 4.6 code freeze - please let me
  know if it causes any problems.
  
  PR:             28418, 25958
  Tested by:      jkh, Christopher Masto <chris@netmonger.net>
  MFC after:      2 weeks
  
  Revision  Changes    Path
  1.5       +1 -0      src/sys/sys/memrange.h
  1.7       +2 -1      src/usr.sbin/memcontrol/memcontrol.c

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204142019.g3EKJD294534>