Mailinglist Archive: opensuse-bugs (8048 mails)

< Previous Next >
[Bug 228344] Acer Ferrari 1000 resets on resume with CONFIG_MTRR
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 14 Feb 2007 09:40:18 -0700 (MST)
  • Message-id: <20070214164018.91D5E25C889@xxxxxxxxxxxxxxxxxxxxxx>

------- Comment #27 from bk@xxxxxxxxxx 2007-02-14 09:40 MST -------
There is indeed a newer BIOS available from Acer, six-teen versions to be
but only the last version is available, without changelog.

At least the Windows-only Flasher seems to backup the old BIOS image to a
file, so I guess I could restore the current BIOS in case.

There is no support for upgrades. If something goes wrong -> not Acer's fault.
I could at least understand if somebody would not like to mess with the BIOS.

Back to teh technical analysis:

In the way I understand the x86-64 manual, the initial setup of Extended
Fixed-Range MTRRs is wrong. On early boot, after identifiying the boot CPU,
I dumped MTRR and SYSCFG MSR contents and found the following
Extended Fixed-Range MTRR setup in the boot CPU:

1) Fixed-Range MTRRs are enabled (MTRR_deftype bits 10 and 11 are set)

2) Extended Fixed-Range MTRRs are enabled and RdMem and Wrmem bits are
configured to be rw-accessible (The MtrrFixDramEn and MtrrFixModEn bits
in the SYSCFG MSR are set)

2) All WrMem and RdMem bits are 0, but the MTRRs for 00000-9FFFF (0-640k) are
set to write-back (WB). To repeat, the entire register's value is 6,
and Fixed-Range MTRRs are enabled as well.

This combination, according to the page 235 of AMD publication 24593 from,,30_182_739_7044,00.html
is not an "allowable combination" and results in "undefined" and

But when I retrieve the MTRRs after boot, I get this register dump:

CPU 0 MTRR 00000-7FFFF RdMem+Wrmem+write-back
CPU 0 MTRR 80000-9FFFF RdMem+Wrmem+write-back
CPU 0 MTRR C0000-C7FFF RdMem+write-protect
CPU 0 MTRR C8000-CFFFF RdMem+write-protect
CPU 0 MTRR E4000-E7FFF RdMem+write-protect
CPU 0 MTRR E8000-EFFFF RdMem+write-protect
CPU 0 MTRR F0000-F7FFF RdMem+write-protect
CPU 0 MTRR F8000-FFFFF RdMem+write-protect

CPU 1 MTRR 00000-7FFFF write-back
CPU 1 MTRR 80000-9FFFF write-back
CPU 1 MTRR C0000-C7FFF write-protect
CPU 1 MTRR C8000-CFFFF write-protect
CPU 1 MTRR E4000-E7FFF write-protect
CPU 1 MTRR E8000-EFFFF write-protect
CPU 1 MTRR F0000-F7FFF write-protect
CPU 1 MTRR F8000-FFFFF write-protect

While CPU Core 1 still had the same setup as in early boot, the access types
of the Boot CPU Core have drastically changed. A number of memory ranges which
are often used for ROM are changed to a shadowed ROM configuration, as if
something shadowed ROM respective memory-mapped I/O to system memory for
shadowed ROM while the 1st 640k of memory are now properly configured for

Now, when the inital MTRR setup of the two CPU core is restored during suspend
after saving+restoring the CPU context in {save,restore}_processor_state, the
bug manifests itself in the form of sata_sil from the kernel CVS failing to
access sda when it's time to write the suspend image or a system reset later
on resume with older kernels.

I have not found Linux kernel code which would set the RdMem and Wrmem bits,
ACPI seems to be not able to do wrmsr but an SMI (system management interrupt)
may do it:

A good fix may however be to save the MTRR state in save_processor_state,
including the extended fixed-range MTRRs (currently nothing regarding MTRRs
is done there) and restore it in restore_processor_state, and ensuring that
all running CPUs have the save MTRR setup.

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 >