https://bugzilla.novell.com/show_bug.cgi?id=228344 ------- Comment #27 from bk@novell.com 2007-02-14 09:40 MST ------- There is indeed a newer BIOS available from Acer, six-teen versions to be exact, but only the last version is available, without changelog. At least the Windows-only Flasher seems to backup the old BIOS image to a backup 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 http://www.amd.com/gb-uk/Processors/TechnicalResources/0,,30_182_739_7044,00... is not an "allowable combination" and results in "undefined" and "unpredictable" behaviour. 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 write-back. 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: http://en.wikipedia.org/wiki/System_Management_Mode 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: 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.