Re: 2.6.3-mm3 (ioremap failure w/ _X86_4G and _NUMA)

From: Dave Hansen (haveblue_at_us.ibm.com)
Date: 02/28/04

  • Next message: Andrea Arcangeli: "Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)"
    To: John Stultz <johnstul@us.ibm.com>
    Date:	Fri, 27 Feb 2004 19:18:05 -0800
    
    

    On Fri, 2004-02-27 at 18:48, john stultz wrote:
    > On Fri, 2004-02-27 at 16:06, Andrew Morton wrote:
    > > john stultz <johnstul@us.ibm.com> wrote:
    > > >
    > > > When running -mm3 (plus the one-line fix to the expanded-pci-config
    > > > patch) to on an x440 w/ 4G enabled, the tg3 driver cannot find my
    > > > network card.
    > > >
    > > > When booting I get:
    > > > tg3.c:v2.7 (February 17, 2004)
    > > > tg3: Cannot map device registers, aborting.
    > > > tg3: probe of 0000:01:04.0 failed with error -12
    > > >
    > > > Otherwise the system seems to come up fine.
    > > >
    > > > Disabling CONFIG_ACPI (or CONFIG_X86_4G) makes the problem go away.
    > >
    > > Beats me. Maybe acpi is returning some monstrous reosurce length and we're
    > > running out of kernel virtual space only with the 4g split?
    > >
    > > 'twould be appreciated if you could stick a few printk's in there and work
    > > out what's happening please. Check out the pci space base address and
    > > length with and without ACPI?
    >
    > The base address and length are the same either way, instead its
    > __ioremap that's failing at "if(!PageReserved(page))"[ioremap.c:142].
    >
    > I've also narrowed down the issue to only occur w/ (CONFIG_X86_4G=y &&
    > CONFIG_NUMA=y) so it looks like its a propblem w/ 4G and discontigmem
    > together.
    >
    > I've also finally moved to -mm4 and reproduced the problem there.

    Can you dump out all of the variables in the
            if (phys_addr < virt_to_phys(high_memory)) {
            ...
    statement, plus the arguments that ioremap() is getting?

    Evidently, it's OK if highmem pages aren't PageReserved(), and I'm
    starting to wonder if you've done something rare, like spanned the
    highmem boundary with your ioremap().

    We do some weird stuff with that highmem boundary when NUMA is on,
    because we remap a bunch of mem_map[] in that area to get it local on
    NUMA nodes which might be causing something unexpected. Take a look and
    see if any of the variables that __ioremap() is using correspond to
    those that remap_numa_kva() is playing with (from your boot log):
    node 0 will remap to vaddr f8000000 - f8000000
    node 1 will remap to vaddr f5600000 - f8000000
    High memory starts at vaddr f8000000

    It's just a guess.

    -- dave

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Andrea Arcangeli: "Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)"

    Relevant Pages

    • Re: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes
      ... ioremap_nocache: addr c0403000, size 200 ... ACPI: PCI interrupt for device 0000:00:12.0 disabled ... AC'97 space ioremap problem ... system 00:08: ioport range 0x1080-0x1080 has been reserved ...
      (Linux-Kernel)
    • Re: [PATCH][help?] Radeonfb acpi resume
      ... > The above will probably blow up anything that is not an x86 with ACPI. ... > Besides there is already a mecanism in that file for calling functions ... Oregon State University ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes
      ... Going through ACPI ... ioremap at this place in ACPICA. ... ioremap: addr c0403104, size fc ... system 00:08: ioport range 0x1080-0x1080 has been reserved ...
      (Linux-Kernel)
    • Re: [PATCH][help?] Radeonfb acpi resume
      ... The above will probably blow up anything that is not an x86 with ACPI. ... Besides there is already a mecanism in that file for calling functions ... for re-posting cards (since I have code to explicitely re-post rv280 and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes
      ... failing the ioremap and thus failing the driver. ... The ACPI tables ... the device mmio areas will be UC most of the time. ... Subject: [PATCH] x86: copy srat table and unmap in acpi_parse_table ...
      (Linux-Kernel)