Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
On Tue, 3 Apr 2007 15:55:32 +0200 (CEST) Bernhard Kaindl <[EMAIL PROTECTED]> wrote: > With at least 3 of the following 4 patches, s2ram and s2disk are > fixed on at least the Acer Ferrari 1000 notebooks and at least > s2disk on the Acer Ferrari 5000 notebooks. These patches cause my Vaio to oops during suspend-to-disk. oops: http://userweb.kernel.org/~akpm/s5000499.jpg config: http://userweb.kernel.org/~akpm/config-sony.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
On Tue, 3 Apr 2007 15:55:32 +0200 (CEST) Bernhard Kaindl [EMAIL PROTECTED] wrote: With at least 3 of the following 4 patches, s2ram and s2disk are fixed on at least the Acer Ferrari 1000 notebooks and at least s2disk on the Acer Ferrari 5000 notebooks. These patches cause my Vaio to oops during suspend-to-disk. oops: http://userweb.kernel.org/~akpm/s5000499.jpg config: http://userweb.kernel.org/~akpm/config-sony.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
Hi! > > With at least 3 of the following 4 patches, s2ram and s2disk are > fixed on at least the Acer Ferrari 1000 notebooks and at least > s2disk on the Acer Ferrari 5000 notebooks. > > The Acer Ferrari 1000 is a 12" Turion 64 X2 notebook with only 1.7 kg weight > while the Ferrari 5000 is a 14" AMD Turion notebook and a bit older but > still not quite old. > > Introduction: > - > > The memory interface of AMD K8 CPUs supports "Extended fixed-range MTRR > Type-Field Encodings" which allow to specify whether accesses to certain > address ranges are executed by accessing RAM thru the AMD Direct Connect > Architecture or by executing memory-mapped I/O. The associated CPU feature > is called IORR's or I/O Range Registers. This allows e.g. to implement > Shadow RAM by copying ROM contents into RAM. > > The BIOS of these Acer AMD Turion 64 notebooks makes use of fixed-range > IORRs to implement shadow RAM and other configurations, and it does > this while it transitions the system into ACPI mode, but Linux is not > prepared for that and breaks the IORRs/MTRRs while suspending, resulting > in errors which look like hardware errors. Symptoms vary from from instant > resets and power-offs to SATA link failures. > > References: > http://en.wikipedia.org/wiki/MTRR > http://en.wikipedia.org/wiki/Direct_Connect_Architecture > http://en.wikipedia.org/wiki/Memory-mapped_IO > http://en.wikipedia.org/wiki/Random_access_memory#Shadow_RAM > > In-depth problem description: > - > > AMD introduced this MTRR extension with the AMD64 CPUs which have integrated > memory controllers. In part (fixed-range IORRs for addresses below 1MB), AMD > uses the fixed-range MTRR registers which already configure the address range > below 1MB to implement corresponding IORR bits and calls the resulting > memory access methods in combination with the original Intel-style MTRR > bits "Extended fixed-range MTRR Type-Field Encodings". They are documented > in section 7.8.1 of the "AMD64 Architecture Programmer's Manual Volume 2: > System Programming", starting with page 234: > http://amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf > > The extended fixed-range type-field encodings are enabled using two > bits in the AMD64-specific SYSCFG MSR (described in detail on page 59). > > When the extended fixed-range type-field encodings are enabled, all > fixed-range MTRR fields are defined this way: > > 7 5 43 2 0 > ++ > | reserved | IORR RdMem bit | IORR WrMem bit | Intel-style MTRR bits | > ++ > > Linux MTRR code does not yet support that the BIOS may change fixed-range > MTRRs and when suspending, this leads Linux MTRR code to clear the IORR bits > for some memory regions. The resulting combination of IORR and Intel-style > MTRR bits is not allowed and causes undefined and unpredictable behaviour > (see the last paragraph before table 7-10). > > A possible workaround is to detect the Acer Ferraris through DMI and > don't change the fixed-range MTTRs on them. Linux MTRR code has no > external interface to change fixed-range MTRRs, so no functionality > and no syncronisation (it's broken on the Ferrari 1000 after ACPI > is enabled if no real fix is applied) is lost by this patch: > > --- linux/arch/i386/kernel/cpu/mtrr/generic.c > +++ linux/arch/i386/kernel/cpu/mtrr/generic.c > @@ -3,6 +3,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -149,6 +150,13 @@ static int set_fixed_ranges(mtrr_type * > int changed = FALSE; > int i; > unsigned int lo, hi; > + char *vendor = dmi_get_system_info(DMI_SYS_VENDOR); > + char *product = dmi_get_system_info(DMI_PRODUCT_NAME); > + > + if (vendor && product && !strncmp(vendor, "Acer", 4) && > + (!strncmp(product, "Ferrari 1000", 12) || > + !strncmp(product, "Ferrari 5000", 12))) > + return FALSE; What would happen if we just did "return FALSE" here, for all machines? Lower system performance? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
Hi! With at least 3 of the following 4 patches, s2ram and s2disk are fixed on at least the Acer Ferrari 1000 notebooks and at least s2disk on the Acer Ferrari 5000 notebooks. The Acer Ferrari 1000 is a 12 Turion 64 X2 notebook with only 1.7 kg weight while the Ferrari 5000 is a 14 AMD Turion notebook and a bit older but still not quite old. Introduction: - The memory interface of AMD K8 CPUs supports Extended fixed-range MTRR Type-Field Encodings which allow to specify whether accesses to certain address ranges are executed by accessing RAM thru the AMD Direct Connect Architecture or by executing memory-mapped I/O. The associated CPU feature is called IORR's or I/O Range Registers. This allows e.g. to implement Shadow RAM by copying ROM contents into RAM. The BIOS of these Acer AMD Turion 64 notebooks makes use of fixed-range IORRs to implement shadow RAM and other configurations, and it does this while it transitions the system into ACPI mode, but Linux is not prepared for that and breaks the IORRs/MTRRs while suspending, resulting in errors which look like hardware errors. Symptoms vary from from instant resets and power-offs to SATA link failures. References: http://en.wikipedia.org/wiki/MTRR http://en.wikipedia.org/wiki/Direct_Connect_Architecture http://en.wikipedia.org/wiki/Memory-mapped_IO http://en.wikipedia.org/wiki/Random_access_memory#Shadow_RAM In-depth problem description: - AMD introduced this MTRR extension with the AMD64 CPUs which have integrated memory controllers. In part (fixed-range IORRs for addresses below 1MB), AMD uses the fixed-range MTRR registers which already configure the address range below 1MB to implement corresponding IORR bits and calls the resulting memory access methods in combination with the original Intel-style MTRR bits Extended fixed-range MTRR Type-Field Encodings. They are documented in section 7.8.1 of the AMD64 Architecture Programmer's Manual Volume 2: System Programming, starting with page 234: http://amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf The extended fixed-range type-field encodings are enabled using two bits in the AMD64-specific SYSCFG MSR (described in detail on page 59). When the extended fixed-range type-field encodings are enabled, all fixed-range MTRR fields are defined this way: 7 5 43 2 0 ++ | reserved | IORR RdMem bit | IORR WrMem bit | Intel-style MTRR bits | ++ Linux MTRR code does not yet support that the BIOS may change fixed-range MTRRs and when suspending, this leads Linux MTRR code to clear the IORR bits for some memory regions. The resulting combination of IORR and Intel-style MTRR bits is not allowed and causes undefined and unpredictable behaviour (see the last paragraph before table 7-10). A possible workaround is to detect the Acer Ferraris through DMI and don't change the fixed-range MTTRs on them. Linux MTRR code has no external interface to change fixed-range MTRRs, so no functionality and no syncronisation (it's broken on the Ferrari 1000 after ACPI is enabled if no real fix is applied) is lost by this patch: --- linux/arch/i386/kernel/cpu/mtrr/generic.c +++ linux/arch/i386/kernel/cpu/mtrr/generic.c @@ -3,6 +3,7 @@ #include linux/init.h #include linux/slab.h #include linux/mm.h +#include linux/dmi.h #include asm/io.h #include asm/mtrr.h #include asm/msr.h @@ -149,6 +150,13 @@ static int set_fixed_ranges(mtrr_type * int changed = FALSE; int i; unsigned int lo, hi; + char *vendor = dmi_get_system_info(DMI_SYS_VENDOR); + char *product = dmi_get_system_info(DMI_PRODUCT_NAME); + + if (vendor product !strncmp(vendor, Acer, 4) + (!strncmp(product, Ferrari 1000, 12) || + !strncmp(product, Ferrari 5000, 12))) + return FALSE; What would happen if we just did return FALSE here, for all machines? Lower system performance? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
On Tue, Apr 03, 2007 at 03:55:32PM +0200, Bernhard Kaindl wrote: > PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from > Processor type and features > -> [M/*] /dev/cpu/*/msr - Model-specific register support > to dump the contents of the fixed-range MTTRs to stdout. > > On a two-CPU system, the output format looks like this: > > MSR 0x250: 1e1e1e1e1e1e1e1e | 0606060606060606 | > MSR 0x258: 1e1e1e1e1e1e1e1e | 0606060606060606 | > MSR 0x259: | | > MSR 0x268: 1515151515151515 | 0505050505050505 | > MSR 0x269: 1515151515151515 | 0505050505050505 | > MSR 0x26a: | | > MSR 0x26b: | | > MSR 0x26c: 15151515 | 05050505 | > MSR 0x26d: 1515151515151515 | 0505050505050505 | > MSR 0x26e: 1515151515151515 | 0505050505050505 | > MSR 0x26f: 1515151515151515 | 0505050505050505 | FWIW, x86info --mtrr would have done this for you :) > To have a sane MTRR setup the MTRRs of the CPUs should always > match, but this has so far not lead to problems, it seems. However, > Intel and AMD manuals tell us to keep MTRRs in sync for good reasons. Indeed. From a quick lookover, I don't see anything obviously wrong in your patches, though Jan and Andi probably remember more gory details about that code than I'll admit to. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Fix MTRR suspend support for specific machines (some AMD64, maybe others also)
On Tue, Apr 03, 2007 at 03:55:32PM +0200, Bernhard Kaindl wrote: PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from Processor type and features - [M/*] /dev/cpu/*/msr - Model-specific register support to dump the contents of the fixed-range MTTRs to stdout. On a two-CPU system, the output format looks like this: MSR 0x250: 1e1e1e1e1e1e1e1e | 0606060606060606 | MSR 0x258: 1e1e1e1e1e1e1e1e | 0606060606060606 | MSR 0x259: | | MSR 0x268: 1515151515151515 | 0505050505050505 | MSR 0x269: 1515151515151515 | 0505050505050505 | MSR 0x26a: | | MSR 0x26b: | | MSR 0x26c: 15151515 | 05050505 | MSR 0x26d: 1515151515151515 | 0505050505050505 | MSR 0x26e: 1515151515151515 | 0505050505050505 | MSR 0x26f: 1515151515151515 | 0505050505050505 | FWIW, x86info --mtrr would have done this for you :) To have a sane MTRR setup the MTRRs of the CPUs should always match, but this has so far not lead to problems, it seems. However, Intel and AMD manuals tell us to keep MTRRs in sync for good reasons. Indeed. From a quick lookover, I don't see anything obviously wrong in your patches, though Jan and Andi probably remember more gory details about that code than I'll admit to. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
