Mailinglist Archive: opensuse-bugs (8048 mails)

< Previous Next >
[Bug 228344] Acer Ferrari 1000 resets on resume with CONFIG_MTRR
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Tue, 20 Feb 2007 12:49:42 -0700 (MST)
  • Message-id: <20070220194942.27AE0FD1@xxxxxxxxxxxxxxxxxxxxxx>

bk@xxxxxxxxxx changed:

What |Removed |Added
Info Provider|mark.langsdorf@xxxxxxx |

------- Comment #31 from bk@xxxxxxxxxx 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:
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

< Previous Next >