Re: 2.6.33: pci 0000:00:00.0: address space collision / spontaenous reboots [full dmesg]

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

 





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?

Justin.


or use pci quirk to hide that in OS.

may need to access the chipset doc.

YH

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux