Reading root bridge resources

From: Rajesh Shah (rajesh.shah_at_intel.com)
Date: 03/31/05

  • Next message: Lee Revell: "2.6.12-rc1-RT-V0.7.41-15: it_real_fn oops on boot in run_timer_softirq"
    Date:	Wed, 30 Mar 2005 16:24:01 -0800
    To: gregkh@suse.de
    
    

    Greg,
    A while back I had volunteered to write a patch that stores the
    resource ranges being decoded by root bridges for ACPI based
    i386 and x86_64 systems. The thread at:
    http://sourceforge.net/mailarchive/message.php?msg_id=10604487
    has some context regarding this. The basic intent was to allow
    hot-plugged devices sitting directly under a root bridge (versus
    under a p2p bridge) to claim the correct resources. The current
    code in pci_scan_bus_parented() simply assigns ioport_resource
    and iomem_resource to each root bridge, even if it decodes a
    subset of those resources.

    I did such a patch recently, and ran into problems while testing
    it. I made the changes in arch/i386, just like Matthew had done
    for arch/ia64. I found that ACPI firmware on some systems was
    not reporting the correct resources in the _CRS method per the
    ACPI specification. On other systems, there were too many resource
    ranges to fit in the 4 slots available in the pci_bus structure.
    Getting an inaccurate picture of root bridge resources broke 2 of
    my test systems, since some devices failed to claim resources at
    boot time even though they were otherwise properly configured by
    BIOS.

    I am therefore inclined to just drop this patch. This may break
    hotplug on systems that support hotplug slots directly connected
    to the root bridge. If a slot is under a p2p bridge, we already
    read bridge bases correctly so this problem does not affect us.
    Note however that I was not able to find any such i386 or x86_64
    machine anyway. Does somebody have access to such a machine? Any
    other suggestions?

    Note that a similar patch went into 2.6.11-mm4'ish for ia64. I
    haven't heard of any breakage there, so apparently ia64 system
    firmware is better behaved.

    Rajesh
    -
    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: Lee Revell: "2.6.12-rc1-RT-V0.7.41-15: it_real_fn oops on boot in run_timer_softirq"

    Relevant Pages

    • Re: ACPIPNP and too large IO resources
      ... you probably have a bridge device that consumes the ... range for downstream PNP devices. ... We might need to consider this patch as ... A patch in -mm kernel correct the parsing of "address resources" of pnpacpi. ...
      (Linux-Kernel)
    • Re: PCI resource problems caused by improper address rounding
      ... resources allocated above 4GB, and that doesn't work very well. ... that patch is not safe. ... region allocator use a window that is in the *middle* of the gap, ... BIOSes *invariably* get resource allocation wrong, ...
      (Linux-Kernel)
    • Re: [PATCH - Resend] PNPACPI: only parse device that have CRS method
      ... mc> this patch blacklist device that don't have CRS method as there are ... with your patch and still does not work. ... resources showed resources but smsc-ircc2 got still no ... declare my ACPI BIOS broken and revert to PNPBIOS on this laptop? ...
      (Linux-Kernel)
    • acpi based pci gap calculation - v3
      ... I don't see this patch being applied in any of the tree yet. ... Then searches the e820 memory space for a gap within these producer resources. ... Allows us to find a gap for the unclaimed pci resources or MMIO resources ...
      (Linux-Kernel)
    • [PATCH] Insert Local and IO APIC(s) into resource map
      ... This patch inserts the Local APIC and IO APICinto the resource tree. ... the insertion until after PCI has allocated its necessary resources. ...
      (Linux-Kernel)