[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes

    * Andreas Herrmann3 <> wrote:

    > Yes.
    > Meanwhile I have figured out that it is some ACPI stuff that maps the
    > page cached. I've changed the ioremap's in drivers/acpi/osl.c to
    > ioremap_nocache. See attached patch.
    > Now the machine boots without conflicts.

    ah, nice!

    but in general we must be robust enough in this case and just degrade
    any overlapping page to UC (and emit a warning perhaps) - instead of
    failing the ioremap and thus failing the driver (and the bootup).

    Does my third patch (which falls back to UC in case of attribute
    conflicts, also attached below) instead of your ioremap_nocache() patch
    solve your bootup problem too?

    while ACPI should not hurt too much from using UC mappings, we should
    still solve this intelligently and only use UC when needed. (Sane system
    makers with a sane layout of IO areas and BIOS areas should not be
    punished with UC overhead.)

    > > as an intermediate fix, how about following the attribute of the
    > > already existing mapping, instead of rejecting the ioremap due to
    > > the conflict? I.e. something like below?
    > I guess it is not a good idea to use an existing cachable attribute if
    > the IO-region is non-prefetchable. And in this example there are 3
    > devices which are potentially affected:
    > 00:12.0 IDE interface: ATI Technologies Inc 4379 Serial ATA Controller (rev 80) (
    > ...
    > Memory at c0403000 (32-bit, non-prefetchable) [size=512]
    > ...
    > 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 82)
    > ...
    > Memory at c0403400 (32-bit, non-prefetchable) [size=1K]
    > ...
    > 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 80)
    > ...
    > Memory at c0403800 (32-bit, non-prefetchable) [size=256]
    > ...
    > BTW, is there a need for osl.c to map all regions as cached?

    no, there should be no such need. There can be "mapping leaks", in that
    the mapped object is not unmapped. There's detection code in today's
    x86.git that should report something like this if it occurs:

    Debug warning: early ioremap leak of 1 areas detected.
    please boot with early_ioremap_debug and report the dmesg.
    ------------[ cut here ]------------
    WARNING: at arch/x86/mm/ioremap_32.c:346 ()

    but i have not seen this message in your boot log. Could you boot with
    early_ioremap_debug and send us the dmesg - i'm curious which ACPI
    tables are actively mapped while those devices are initialized.


    Subject: x86: patches/pat-conflict-fixup.patch
    From: Ingo Molnar <>

    Signed-off-by: Ingo Molnar <>
    arch/x86/mm/pat.c | 7 ++++++-
    1 file changed, 6 insertions(+), 1 deletion(-)

    Index: linux-x86.q/arch/x86/mm/pat.c
    --- linux-x86.q.orig/arch/x86/mm/pat.c
    +++ linux-x86.q/arch/x86/mm/pat.c
    @@ -174,7 +174,12 @@ int reserve_mattr(u64 start, u64 end, un
    current->comm, current->pid,
    start, end,
    cattr_name(attr), cattr_name(ml->attr));
    - err = -EBUSY;
    + /*
    + * Force UC on a conflict:
    + */
    + ma->attr = _PAGE_UC;
    + if (*fattr)
    + *fattr = _PAGE_UC;
    } else if (ml->start >= end) {

     \ /
      Last update: 2008-01-17 22:17    [W:0.033 / U:4.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site