https://bugzilla.novell.com/show_bug.cgi?id=228344 bk@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |mark.langsdorf@amd.com ------- Comment #28 from bk@novell.com 2007-02-19 06:46 MST ------- I tested saving the Fixed-range MTRR state in save_processor_state, but on restore_processor_state for the second core, an exception is thrown by WRMSR when set_fixed_ranges tries to set the RdMem and/or WrMem attributes in the Extended MTRR Type-Field Format for Fixed-Range MTRRs which are described in section 7.8.1 of AMD publication 24593, Rev. 3.12 ( http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/2459... ) which are already set on the boot core. That kind exception is handled by the MTRR code already, it logs that the MSR for which WRMSR failed and continues and the system resumes otherwise fine. The code to handle an exception from WRMSR is in mainline because it was a work-around for an BIOS bug regarding MTRRs, found and fixed by SuSE/Andi: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12... I looked up the reasons why WRMSR may throw an exception on page 359 of http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/2459... and AFACS, none of them is present, so at least from that documentation, the exception shouldn't be thrown. I also verified that the MtrrFixDramModEn and MtrrFixDramEn bits are set in the SYSCFG MSR of the second core immediately before trying to set the bits, but both are set, so nothing should prevent to set these bits, but the system throws the exception nonetheless. I tried to search for AMD erratas and Turion 64 X2 docs which would document this, but didn't find documentation on that. Mark, may I be right with the following: May it be that these bits may not be set on the second TL-56 core despite having two a separate L2 cache since this kind of memory configuration (shadowed ROM and write-back memory below 1M) and is more usual for the system BIOS (which will only use the boot core) than by modern operating systems which use both cores? As a workaround, the fixed-range MTRRs could be saved&restored using separate backup values per logical CPU. The resulting suspend/resume setup would not change, except that the exceptions would not be thrown and logged and the MTRRs would be restored as it was before resume. -- 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.