Searched hist:94683 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-9.3-release/sys/i386/i386/ | ||
| H A D | i686_mem.c | diff 94683 Sun Apr 14 18:13:08 MDT 2002 dwmalone 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 |
| /freebsd-9.3-release/sys/amd64/amd64/ | ||
| H A D | amd64_mem.c | diff 94683 Sun Apr 14 18:13:08 MDT 2002 dwmalone 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 |
Completed in 95 milliseconds