> > 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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
