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

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

On Sun, Jun 05, 2005 at 08:46:45PM +0400, Ivan Kokshaysky wrote:
> It's the "transparent" bridge. The code in setup-bus.c doesn't handle this
> properly.
> 
> Please try this patch - it should fix two problems:
> - in pci_setup_bridge() use bridge resources directly, instead of
>   the resource pointers in struct pci_bus (this fixes an oops);
> - [ioport,iomem]_resource must not be touched in the bus setup code,
>   otherwise we screw up the whole resource tree.
> 
> Ivan.

With the patch and Linus' modifications, the boot progresses further
than with Linus' mods alone.  However, it now fails a bit later when
it comes the CardBus bridge in the docking station (following output
manually typed from the console):

...
ACPI: PCI interrupt 0000:03:05.0[A] -> GSI 31 (level, low) -> IRQ 31
Yenta: CardBus bridge found at 0000:03:05.0 [104c:ac50]
yenta 0000:03:05.0: Preassigned resource 0 busy, reconfiguring ...
yenta 0000:03:05.0: no resource of type 1200 available, trying to continue ...
yenta 0000:03:05.0: Preassigned resource 1 busy, reconfiguring ...
yenta 0000:03:05.0: no resource of type 200 available, trying to continue ...
yenta 0000:03:05.0: no resource of type 100 available, trying to continue ...
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:03:05.0, mfunc 0x00521d22, devctl 0x66
Yenta TI: socket 0000:03:05.0 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:03:05.0 falling back to parallel PCI interrupts
Yenta TI: socket 0000:03:05.0 no PCI interrupts. Fish. Please report.
Yenta: ISA IRQ mask 0x0000, PCI irq 0
Socket status: ffffffff

For your reference, at this stage we appear to have a cascade of three
bridges between a potential device (currently empty CardBus slot) and
the CPU

                1              2      3
CPU Southbridge -> PCI Express -> PCI -> CardBus

Note that the messages before this log, e.g., from ohci1394, also indicate
that the peripherals in the docking station still remain inaccessible due to
unmapped memory (all reads return 0xff). 

Many thanks for your effort,
  Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/