On 03/12/2010 12:34 PM, Justin Piszcz wrote: > > > On Fri, 12 Mar 2010, Yinghai Lu wrote: > >> On Fri, Mar 12, 2010 at 12:02 PM, Justin Piszcz >> <jpiszcz@xxxxxxxxxxxxxxx> wrote: >>> >>> >>> On Fri, 12 Mar 2010, Yinghai Lu wrote: >>> >>>> On Fri, Mar 12, 2010 at 5:10 AM, Justin Piszcz >>>> <jpiszcz@xxxxxxxxxxxxxxx> >>>> wrote: >>>>> >>>>> [ 0.112379] pci 0000:00:00.0: reg 1c: [mem 0xe0000000-0xffffffff >>>>> 64bit] >>>> >>>>> [ 0.133510] PCI: pci_cache_line_size set to 64 bytes >>>>> [ 0.133515] pci 0000:00:00.0: BAR 3: reserving [mem >>>>> 0xe0000000-0xffffffff >>>>> flags 0x120204] (d=0, p=0) >>>>> [ 0.133518] pci 0000:00:00.0: address space collision: [mem >>>>> 0xe0000000-0xffffffff 64bit] already in use >>>>> [ 0.133522] pci 0000:00:00.0: can't reserve [mem >>>>> 0xe0000000-0xffffffff >>>>> 64bit] >>>>> [ 0.137020] system 00:09: [mem 0xe0000000-0xefffffff] has been >>>>> reserved >>>>> [ 0.172034] pci_bus 0000:00: resource 0 [io 0x0000-0xffff] >>>>> [ 0.172035] pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffff] >>>> >>>> looks like the silicon report wrong size in that BAR3 >>>> >>>> YH >>> >>> Hi, >>> >>> Is there anyway to work around this? Or is it a bad motherboard? >>> >> >> maybe one new BIOS could hide that register > Hi, > > It is using the latest F8c BIOS: > http://www.gigabyte.us/Products/Motherboard/Products_Overview.aspx?ProductID=3007 > > > Other (earlier) bios' have been tested, that did not help either. > > Is there anyway to to the kernel not to touch that range of memory? > 0xe0000000-0xffffffff? kernel doesn't touch that BAR. just set the res start to 0, but later it doesn't try to get one for it. because pci 00:00.0 is one hostbridge. YH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
