On Fri, 13 Oct 2000, Dag Bakke wrote:
>
> This patch enables the expansion ROM, but it still doesn't make the card
> work.
Ok. It seems that your stuck bit is really stuck, and I was wrong: it's
not the cardbus bridge that does something strange, it actually looks like
your hardware has a data line that is stuck at 0.
> non-working case:
> -------------------------
> cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
> Found 06:00 [115d/0003] 000200 00
> bus res 0 1200 1c000000-1fffffff
> bus res 1 200 20000000-23ffffff
> bus res 2 100 00001800-000018ff
> bus res 0 1200 1c000000-1fffffff
> bus res 1 200 20000000-23ffffff
> bus res 0 1200 1c000000-1fffffff
> bus res 1 200 20000000-23ffffff
> bus res 0 1200 1c000000-1fffffff
> PCI: Error while updating region 06:00.0/6 (1c000001 != 18000001)
Notice how it's bit 0x04000000 again. The 0x18000001 value is the one we
read back afterr having written the region address: we wrote 0x1c000001,
and bit 0x04000000 simply doesn't stick - the above is a debug message
telling us that we read back something different. See the code in
arch/i386/kernel/pci-i386.c: pcibios_update_resource() if you're
interested in seeing exactly what the logic is.
So I'm afraid that it's really starting to look like that particular
hardware really has either a broken line somewhere on the motherboard (or
a docking connector with a broken pin or similar), or there is some other
hardware limitation (maybe the bridge is limited to 64MB and just isn't a
valid PCI-PCI bridge).
The fact that you apparently have an identical machine that does work
makes me suspect it's not a chip limitation, but truly a broken connector
or line.
In which case there would be no way to make it work - whenever we'd write
data to the card, it would lose one bit.
If I remember correctly, you said that this card worked under Windows. Was
that on the _same_ machine? That would be an important data-point: if it
works under Windows, that means that I'm wrong, and that it's some quirk
that windows knows how to work around.
I have one final test you could do: considering that the lost bit seems to
be the same bit that we use as the size of the MEM resource bridge window,
and assuming that it is not a physically broken connector or something,
but really is some strange quirk of the bridge itself and interactions
with the memory window, you could try to change the alignment of the
window allocation such that it's always given a window where the upper bit
won't matter.
The way to do that would be in the same place where you changed the size
in drivers/pcmcia/yenta.c: make the alignment be double what the size is,
so do something like
size = 128*1024*1024;
align = size << 1;
in yenta_allocate_res() for the MEM case (leave the IO case at 256 and
1024).
(The reason I'm saying 128*1024*1024 is to see if the "stuck bit" moves).
Oh, and also, to see the stuck bit more clearly, please add a line like
printk("base=%08x, size=%08x\n", base, size);
to drivers/pci/pci.c: pci_size() just before the return.
Ok? I'm getting the feeling that your hardware simply is broken, but I
want to debug this to death. Thanks for being patient,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST