[linux-pm] [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/7/06, Matthew Wilcox <matthew at wil.cx> wrote:
> On Wed, Nov 08, 2006 at 12:57:03AM +0800, Jeff Chua wrote:
> > 2) this fails ...
> >
> > e0000000-efffffff : 0000:00:02.0
> > f0000000-ffffffff : PCI MMCONFIG 0
> >    fed00000-fed003ff : HPET 0
>
> Heh, no kidding ...
>
>                 num_buses = pci_mmcfg_config[i].end_bus_number -
>                     pci_mmcfg_config[i].start_bus_number + 1;
>                 res->start = pci_mmcfg_config[i].base_address;
>                 res->end = res->start + (num_buses << 20) - 1;
>                 res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>                 insert_resource(&iomem_resource, res);
>
> So if we have 256 busses assigned, then we request 256MB and, well,
> there's no room for anyone else.  This code was added by Andi in commit
> de09bddb9d6f96785be470c832b881e6d72d589f
>
> Hopefully he'll have a good idea how to restrict it.  Given your "working"
> resource map, it seems like it should be limited to 16MB (and thus 16 busses).
> But how to figure that out?
>

Maybe Andi can shed some light on the reasoning for not checking e820
to see if the entire MMCONFIG region is reported as reserved in the
e820 map.  I can patch up the pci_mmcfg_insert_resource to verify if
the region that is exported by ACPI is reserved in e820 and printk an
error message if it is not and skip the resource insertion.

Does that seem like a good avenue to pursue?

-Aaron


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux