Re: PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

[Andreas Koch <koch@esa.informatik.tu-darmstadt.de>]

So, I managed to test Ivan's latest patch. The machine still hangs,
but a little bit later in the boot process.

Observations thus far:

1) After Ivan's sanity checks in pcibios_allocate_bus_resources get
executed (with the same results I described in a prior mail), I get a
number of messages stating that for the devices on
0000:03:{02,03,04,05}.x, resource regions could not be assigned.
These are the devices in the docking station (behind the PCIE-PCI bridge).

2) Later, I get messages that bogus ressources of 0000:00:1e.0 are ignored

3) Then, the output of pci_setup_bus_bridge begins. It indicates that
for the bridges 0000:00:1c.0, 1c.1 and 1e.0, the characteristics IO,
MEM and PREFETCH are disabled. This is the direct result of Ivan's
latest patch. NOTE: 0000:00:1c._2_, the bridge to the external PCIE,
_does_ appear to have valid data for IO, MEM and PREFETCH.

4) Since the messages of ohci1394 with regard to 0xff reads from the
external FireWire controller persist, I assume that the external
devices can still not be successfully memory mapped.

5) With this latest patch, the boot process proceeds beyond the attempt
of initializing the external CardBus bridge 0000:03:05.0 (which fails
as before `no PCI interrupts. Fish ...' to the initialization of the
internal CardBus bridge. After a `socket status: 3000006' and ACPI PCI
interrupt assignment messages, the machine hangs with no further output.

I regret that I cannot be more specific. But since this machine's
serial port is _on the external dock_, I cannot even provide full logs
obtained by SERIAL_CONSOLE. If you want me to look for specific things in
the output (that I can capture by inserting loop-based pauses at specific
places in in the boot process), I'll gladly do so.

Andreas