On 14 Jun 2002, Peter Osterlund wrote:
>
> OK, with the patch below I get a little further. The kernel no longer
> complains about resource collisions, bringing up eth0 works, but the
> network card is still not usable:
>
> eth0: Transmit timed out, status ffffffff, CSR12 ffffffff, resetting...
> eth0: Out-of-sync dirty pointer, 0 vs. 17.
Some part of your resource isn't mapped through the cardbus bridge. Either
because the bridge resources themselves were wrong, or because we didn't
enable the resouce after we allocated it (the latter is unlikely, as any
"pci_enable_dev()" will do that part).
> Yenta IRQ list 0a98, PCI irq10
> Socket status: 30000068
> Yenta IRQ list 0a98, PCI irq10
> Socket status: 30000006
> cs: cb_alloc(bus 1): vendor 0x13d1, device 0xab02
> Scanning bus 01
> Found 01:00 [13d1/ab02] 000200 00
> PCI: Calling quirk c01d56a0 for 01:00.0
> Fixups for bus 01
> PCI: Scanning for ghost devices on bus 1
> Unknown bridge resource 0: assuming transparent
> Unknown bridge resource 1: assuming transparent
> Unknown bridge resource 2: assuming transparent
This is the problem.
The PCI code thinks that the parent of the network device doesn't have
resources allocated, so it will allocate the resources from the parent of
the parent.
Which is wrong, since it means that it will try to allocate the PCI
resources from outside the window that the cardbus controller is
exporting. Resulting in the fffff stuff.
HOWEVER, I don't see why that happens. yenta_allocate_resources() should
have made absolutely certain that we have all the necessary bridge
resources clearly allocated. Can you add debug code to the end of
"yenta_allocate_res()" that prints out the resource that got allocated?
Pat?
Linus
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:32 EST