Re: PCI conflicts with latest kernels

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

[I re-added the CC: list, so the archives will have the whole
conversation, in case anybody else has similar problems or
can help answer this.]

On Sunday 14 March 2010 05:11:55 pm Giampaolo Bellini wrote:
> I apply the patch but seems that it does not solve conflicts

Yes, I didn't expect it to fix anything, only to tell us more about
what's happening.

But from your dmesg, I think the problem is that the e820 map reserves
0xe0000-0x100000, and then PCI device 0b.0 has a BAR programmed to part
of that same region:

   BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  pci 0000:00:0b.0: reg 10: [mem 0x000e0000-0x000e0fff]
  pci 0000:00:0b.0: address space collision: [mem 0x000e0000-0x000e0fff] already in use

I don't know enough about the e820 map to know whether this is a bug in
the e820 map or a problem in the PCI BAR programming, or what.

> as far I understand, the problem was there also with 2.6.29 but was not
> logged the same way and/or with the same debug-level due to changes made in
> *drivers/pci/setup-res.c* (expecially in pci_claim_resource()))

Yes.  In 2.6.29, pcibios_allocate_resources() used request_resource()
directly and logged errors with dev_info().  In 2.6.34-rc1, we use
pci_claim_resource(), which calls request_resource() and logs errors
with dev_err(), so we now have a higher priority message than we used
to have.

> machine, however, seems stable... for me the problem is that I'm trying to
> avoid text-messages during boot stage and printk(KERN_ERR "message") cause
> the system to switch in text mode & show such errors...

If you only want to hide the message, you can use "loglevel=2".

> as you can see, I've try also with pci=use_crs

Since you don't have ACPI, pci=use_crs and pci=nocrs are not relevant
for your system.

Bjorn