[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201001120847.47684.a.brooks@marathon-robotics.com>
Date: Tue, 12 Jan 2010 08:47:47 +1100
From: Alex Brooks <a.brooks@...athon-robotics.com>
To: Bjorn Helgaas <bjorn.helgaas@...com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: BAR 0: can't allocate resource
> > 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.
OK, at this point I think I'll look into switching hardware. Thanks very much
for all the help.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists