lkml.org 
[lkml]   [2010]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: BAR 0: can't allocate resource
Date
> > 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


\
 
 \ /
  Last update: 2010-01-11 22:51    [W:0.044 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site