https://bugzilla.novell.com/show_bug.cgi?id=228344 bk@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|mark.langsdorf@amd.com | ------- Comment #31 from bk@novell.com 2007-02-20 12:49 MST ------- I had a simple off-by-one error in checking the MtrrFixDramModEn bit and while trying to set RdMem and WrMem, the bit was not set, so this was the reason why the exception which occurred in wrmsr so everything works as documented and I can set the RdMem and WrMem and bits successfully on the second CPU core. I now worked on extending my changes which save and restore the extended fixed-range MTRRs which are a special feature of the AMD64 architecture during suspend/resume to also syncronize them between CPUs as described as a "must" in section 7.6.5 "MTRRs in Multi-Processing Environments" of the AMD x86-64 programmer's manual, vol. 2, despite the BIOS not conforming to that, so that part is actually a BIOS workaround, but the MTRR code already has a tradition in doing so, e.g. in comment #28, I mentioned a MTRR BIOS bug workaround by Andi and there are more, e.g for more easyer cases than the Ferrari 1000, the Linux MTRR code already did the right thing, but with the extended fixed-range MTRRs of the AMD64 architecture, and the Ferrari 1000 setting up shadow RAM when enabling ACPI mode made it bit more tricky. But on the other hand, I think fixing this nearly worst-case scenario was a good test for this code to save/restore and snyc the AMD64 extended fixed-range MTRRs should be working once and for all. I'll dig out the combined changes and post them for review. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.