Re: BAR 0: can't allocate resource

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

On Saturday 09 January 2010 08:07:26 pm Alex Brooks wrote:
> > I was hoping for a kernel directly from Linus' git repo, e.g.,
> > 2.6.33-rc3; I don't think the debug output I'm thinking about went in
> > until after 2.6.32 was released.
> 
> I'm not sure how to modify the 2.6.33-rc3 kernel source exactly re MCFG -- the 
> dmesg output for 2.6.33-rc3 is quite different (attached),

It's interesting that we now use MMCONFIG by default; no tweaking
necessary.  I guess Linux just got a little smarter between 2.6.26
and 2.6.33 -- in this case, it looks like we reduce the size of the
MMCONFIG region from what the BIOS reported.

But I don't think MMCONFIG is relevant to this problem anyway.

> including some new  
> information about an address collision for the recalcitrant device:
> 
> pci 0000:01:04.0: address space collision: [mem 0x00800000-0x00800fff] already 
> in use
> pci 0000:01:04.0: can't reserve [mem 0x00800000-0x00800fff]
> 
> Does this shed any more light on things (or can you tell me what I could 
> modify to get better debug info)?

It shows that we think the octal UART is at 0x00800000, which
doesn't seem valid (I think it's in the middle of your system RAM).

This is before Linux moves anything around, so normally this would
be what BIOS left in the BAR.  But BIOS puts it at 0xfebff000 in the
working case (without the Mini PCI adapter), and the adapter shouldn't
even be visible to the BIOS, so I would expect the octal UART to still
be at the same address.

I'm afraid I still don't see a software problem here.  To me (and I'm
certainly not a hardware person), it feels like an electrical problem
on the PCI bus: we read a BAR and it has a nonsensical value, we write
the BAR and can't read that value back, we read the vendor/device/class
codes and get nonsense.  It's also interesting that most of these
nonsense values we read seem to have only one bit set.

Bjorn