Mailinglist Archive: opensuse-bugs (8048 mails)

< Previous Next >
[Bug 228344] Acer Ferrari 1000 resets on resume with CONFIG_MTRR
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Mon, 19 Feb 2007 06:46:51 -0700 (MST)
  • Message-id: <20070219134651.7B81DFCD@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=228344


bk@xxxxxxxxxx changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
Info Provider| |mark.langsdorf@xxxxxxx




------- Comment #28 from bk@xxxxxxxxxx 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/24593.pdf
) 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-rc1-mm2/broken-out/x86_64-work-around-tyan-bios-mtrr-initialization-bug.patch

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/24594.pdf
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.

< Previous Next >