RE: Updated 2.4 TODO List - more on PCI resources...]
> > I agree. I would expect it to be 8 instead of 32. > > Actually I just checked on a new Thinkpad T20 with a TI > > PCI 1450 CardBus controller *on a different OS* > > and it is 8. > > I'll fix it to be 8. > > Thanks, > > Linus Well, preferably to what David said: L1_CACHE_BYTES / 4 Thanks, ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
On Fri, 13 Oct 2000, Dunlap, Randy wrote: > > I agree. I would expect it to be 8 instead of 32. > Actually I just checked on a new Thinkpad T20 with a TI > PCI 1450 CardBus controller *on a different OS* > and it is 8. I'll fix it to be 8. Thanks, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > > I'm not familiar with yenta controllers/devices, > > and I'm not trying to throw you a tasty red herring, > > but... > > > > yenta_config_init() does > > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > > > Is this writing to the CardBus bridge or to the device's > > CacheLineSize register? > > It is writing to the bridge. I think it should probably actually be > L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect > setting. Maybe Linus knows. > > -- Dave I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...]
I have tested Linus' patch and it makes a difference: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.0/6 (1c01 != 1801) PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.1/6 (1c004001 != 18004001) PCI: Enabling device 06:00.1 ( -> 0003) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 192k freed Warning: unable to open an initial console. cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. eth0: first available media type: MII tulip_attach(06:00.0) PCI: Enabling bus mastering for device 06:00.0 PCI: Setting latency timer of device 06:00.0 to 64 xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by [EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford) eth1: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x1800, 00:00:00:00:00:00, IRQ 11. lspci: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1800 [size=128] Memory at 2000 (32-bit, non-prefetchable) [size=2K] Memory at 2800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c00 [size=16K] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] Memory at 20001000 (32-bit, non-prefetchable) [size=2K] Memory at 20001800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c004000 [size=16K] Capabilities: [dc] Power Management version 1 It still doesn't work. It looks very much like a stuck bit, but at least we get a slightly "better" error message and the expansion ROM now gets enabled. progress! Linus wants to "debug this to death" (his words, not mine) but I don't have access to the suspect hardware for the next five weeks, and it will probably be serviced some time during those weeks. Thank you for being patient, Linus. And sorry for not being able to provide more debug data. Dag B - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > I'm not familiar with yenta controllers/devices, > and I'm not trying to throw you a tasty red herring, > but... > > yenta_config_init() does > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > Is this writing to the CardBus bridge or to the device's > CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
I'm not familiar with yenta controllers/devices, and I'm not trying to throw you a tasty red herring, but... yenta_config_init() does config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); Is this writing to the CardBus bridge or to the device's CacheLineSize register? If the latter, and given that PCI_CACHE_LINE_SIZE is in units of 4-byte "words", is 32 [= 128 bytes] a good value to use? If so, why? Or is it OK because it is setting a PCI bridge device's cache line size? >From TI's PCI1451 GJG CardBus controller spec: 4.8 Cache Line Size Register The cache line size register is programmed by host software to indicate the system cache line size. Thanks, ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...]
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 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 2 100 1800-18ff
> bus res 0 1200 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 0 1200 1c00-1fff
> bus res 1 200 2000-23ff
> bus res 0 1200 1c00-1fff
> PCI: Error while updating region 06:00.0/6 (1c01 != 1801)
Notice how it's bit 0x0400 again. The 0x1801 value is the one we
read back afterr having written the region address: we wrote 0x1c01,
and bit 0x0400 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: I'm not familiar with yenta controllers/devices, and I'm not trying to throw you a tasty red herring, but... yenta_config_init() does config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); Is this writing to the CardBus bridge or to the device's CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
On Fri, 13 Oct 2000, Dunlap, Randy wrote: I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. I'll fix it to be 8. Thanks, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Updated 2.4 TODO List - more on PCI resources...]
I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. I'll fix it to be 8. Thanks, Linus Well, preferably to what David said: L1_CACHE_BYTES / 4 Thanks, ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...]
On Thu, 12 Oct 2000, Dag Bakke wrote:
>
> Linus,
> I realized there was one more test to do before deeming the hardware sane.
>
> PCMCIA (16-bit) in my laptop is tested and works fine with three different
> types of cards.
> Another Xircom card behaved just the same (non-functional) in my latop.
> My Xircom card was tested in another laptop and found working.
>
> Today I took my card *and* disk and tested it in an identical laptop.
> It works.
>
> So it appears that the *cardbus* logic is broken on my machine. Plain, old
> hardware defect. And I have been wasting your time. Sorry about that.
No problem. This was good to have it out of the way. And I don't think you
actually wasted my time: this may still be a Linux bug. See more below.
> In any case, debug output follows for both the non-working and the working
> case. Feel free to pin-point the hw-bug or flat out ignore it.
Yup, bug pin-pointed, and clear: these are the resources for the failing
case:
> device PCI device 115d:0003 resource 1 size 04000800
> device PCI device 115d:0003 resource 2 size 04000800
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0103 resource 1 size 04000800
> device PCI device 115d:0103 resource 2 size 04000800
> device PCI device 115d:0103 resource 6 size 04004000
> device PCI device 115d:0103 resource 6 size 04004000
While I'll bet you $20 that the working case (which doesn't print out the
same printk because it doesn't fail) has the exact same resources, except
the "size" field doesn't have that pesky high bit set, so the sizes are
all 0x0800 of 0x4000 instead of being 64MB+.
Now, that said, I do think that this is a linux bug. Sure, your hardware
is strange too, and hardware obviously _does_ make a difference, but there
is no way a non-power-of-two size field can ever be valid, and Linux is
buggy for allowing the hardware to confuse it this way.
What seems to be happening is that somehow your cardbus bridge (or docking
station bridge) is set up so that it doesn't let through that high bit
that defines the size of the PCI bridge map, and the way Linux calculates
the size is basically the simplistic
write all 1's to the base register
read the base register
sz = ~(base & mask) & maxmask;
and while that works most of the time in normal situations, it's really
not correct. What we _should_ do is more akin to this patch. Can you test
this on your broken system, and see if the system magically comes to life?
NOTE! I do worry about the masking off of a bit in the bridge. There may
be a real hardware bug there - but the fact that the mask seems to move
depending on how big a bridge window there is (judging by your past mails
about how behaviour did actually change when changing the cardbus window
size) implies to me that it's not something as simple as a stuck bit.
If it is a stuck bit somehow, then you're screwed, and the patch below
won't help you at all. But if it's the bridge snooping (and modifying) the
decode window sizes, then the patch below should make a difference.
Thanks,
Linus
--- v2.4.0-test9/linux/drivers/pci/pci.cSun Oct 8 10:50:20 2000
+++ linux/drivers/pci/pci.c Thu Oct 12 09:52:07 2000
@@ -474,6 +474,16 @@
return IORESOURCE_MEM;
}
+/*
+ * Find the extent of a PCI decode..
+ */
+static u32 pci_size(u32 base, u32 mask)
+{
+ u32 size = mask & base; /* Find the significant bits */
+ size = size & ~(size-1);/* Get the lowest of them to find the decode
+size */
+ return size-1; /* extent = size - 1 */
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
@@ -501,10 +511,10 @@
l = 0;
if ((l & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
res->start = l & PCI_BASE_ADDRESS_MEM_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_MEM_MASK);
+ sz = pci_size(sz, PCI_BASE_ADDRESS_MEM_MASK);
} else {
res->start = l & PCI_BASE_ADDRESS_IO_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_IO_MASK) & 0x;
+ sz = pci_size(sz, PCI_BASE_ADDRESS_IO_MASK & 0x);
}
res->end = res->start + (unsigned long) sz;
res->flags |= (l & 0xf) | pci_calc_resource_flags(l);
@@ -543,7 +553,7 @@
res->flags = (l & PCI_ROM_ADDRESS_ENABLE) |
IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_READONLY |
IORESOURCE_CACHEABLE;
res->start = l & PCI_ROM_ADDRESS_MASK;
- sz = ~(sz & PCI_ROM_ADDRESS_MASK);
+ sz = pci_size(sz, PCI_ROM_ADDRESS_MASK);
res->end = res->start + (unsigned long)
Re: Updated 2.4 TODO List - more on PCI resources...]
Linus Torvalds wrote: > > On Wed, 11 Oct 2000, Dag B wrote: > > [snip] > > Expansion ROM at 1800 [disabled] [size=32M] > > Capabilities: [dc] Power Management version 1 > > There's something really wrong going on with your ethernet controller. It > seems to try to take up all available space. > > Please add a debug printk() to drivers/pci/setup-res.c to the very end of Linus, I realized there was one more test to do before deeming the hardware sane. PCMCIA (16-bit) in my laptop is tested and works fine with three different types of cards. Another Xircom card behaved just the same (non-functional) in my latop. My Xircom card was tested in another laptop and found working. Today I took my card *and* disk and tested it in an identical laptop. It works. So it appears that the *cardbus* logic is broken on my machine. Plain, old hardware defect. And I have been wasting your time. Sorry about that. In any case, debug output follows for both the non-working and the working case. Feel free to pin-point the hw-bug or flat out ignore it. Thanks, Dag B Non-working case: [] PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:68 [10b7/9050] 000200 00 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0005] 000300 00 Found 01:01 [10c8/8005] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource f900-f9ff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource f8c0-f8ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - device 3Com Corporation 3c905 100BaseTX [Boomerang] resource 6 size 0001 bus res 0 100 - bus res 1 200 - Limiting direct PCI/PCI transfers. [] cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 2 size 04000800 PCI: Failed to allocate resource 2 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0103 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0103 bus res 0 1200 1c00-1fff bus res
Re: Updated 2.4 TODO List - more on PCI resources...]
Linus Torvalds wrote: On Wed, 11 Oct 2000, Dag B wrote: [snip] Expansion ROM at 1800 [disabled] [size=32M] Capabilities: [dc] Power Management version 1 There's something really wrong going on with your ethernet controller. It seems to try to take up all available space. Please add a debug printk() to drivers/pci/setup-res.c to the very end of Linus, I realized there was one more test to do before deeming the hardware sane. PCMCIA (16-bit) in my laptop is tested and works fine with three different types of cards. Another Xircom card behaved just the same (non-functional) in my latop. My Xircom card was tested in another laptop and found working. Today I took my card *and* disk and tested it in an identical laptop. It works. So it appears that the *cardbus* logic is broken on my machine. Plain, old hardware defect. And I have been wasting your time. Sorry about that. In any case, debug output follows for both the non-working and the working case. Feel free to pin-point the hw-bug or flat out ignore it. Thanks, Dag B Non-working case: [] PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:68 [10b7/9050] 000200 00 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0005] 000300 00 Found 01:01 [10c8/8005] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource f900-f9ff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource f8c0-f8ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - device 3Com Corporation 3c905 100BaseTX [Boomerang] resource 6 size 0001 bus res 0 100 - bus res 1 200 - Limiting direct PCI/PCI transfers. [] cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 2 size 04000800 PCI: Failed to allocate resource 2 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( - 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0103 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0103 bus res 0 1200 1c00-1fff bus res 1 200
Re: Updated 2.4 TODO List - more on PCI resources...]
On Thu, 12 Oct 2000, Dag Bakke wrote:
Linus,
I realized there was one more test to do before deeming the hardware sane.
PCMCIA (16-bit) in my laptop is tested and works fine with three different
types of cards.
Another Xircom card behaved just the same (non-functional) in my latop.
My Xircom card was tested in another laptop and found working.
Today I took my card *and* disk and tested it in an identical laptop.
It works.
So it appears that the *cardbus* logic is broken on my machine. Plain, old
hardware defect. And I have been wasting your time. Sorry about that.
No problem. This was good to have it out of the way. And I don't think you
actually wasted my time: this may still be a Linux bug. See more below.
In any case, debug output follows for both the non-working and the working
case. Feel free to pin-point the hw-bug or flat out ignore it.
Yup, bug pin-pointed, and clear: these are the resources for the failing
case:
device PCI device 115d:0003 resource 1 size 04000800
device PCI device 115d:0003 resource 2 size 04000800
device PCI device 115d:0003 resource 6 size 04004000
device PCI device 115d:0003 resource 6 size 04004000
device PCI device 115d:0103 resource 1 size 04000800
device PCI device 115d:0103 resource 2 size 04000800
device PCI device 115d:0103 resource 6 size 04004000
device PCI device 115d:0103 resource 6 size 04004000
While I'll bet you $20 that the working case (which doesn't print out the
same printk because it doesn't fail) has the exact same resources, except
the "size" field doesn't have that pesky high bit set, so the sizes are
all 0x0800 of 0x4000 instead of being 64MB+.
Now, that said, I do think that this is a linux bug. Sure, your hardware
is strange too, and hardware obviously _does_ make a difference, but there
is no way a non-power-of-two size field can ever be valid, and Linux is
buggy for allowing the hardware to confuse it this way.
What seems to be happening is that somehow your cardbus bridge (or docking
station bridge) is set up so that it doesn't let through that high bit
that defines the size of the PCI bridge map, and the way Linux calculates
the size is basically the simplistic
write all 1's to the base register
read the base register
sz = ~(base mask) maxmask;
and while that works most of the time in normal situations, it's really
not correct. What we _should_ do is more akin to this patch. Can you test
this on your broken system, and see if the system magically comes to life?
NOTE! I do worry about the masking off of a bit in the bridge. There may
be a real hardware bug there - but the fact that the mask seems to move
depending on how big a bridge window there is (judging by your past mails
about how behaviour did actually change when changing the cardbus window
size) implies to me that it's not something as simple as a stuck bit.
If it is a stuck bit somehow, then you're screwed, and the patch below
won't help you at all. But if it's the bridge snooping (and modifying) the
decode window sizes, then the patch below should make a difference.
Thanks,
Linus
--- v2.4.0-test9/linux/drivers/pci/pci.cSun Oct 8 10:50:20 2000
+++ linux/drivers/pci/pci.c Thu Oct 12 09:52:07 2000
@@ -474,6 +474,16 @@
return IORESOURCE_MEM;
}
+/*
+ * Find the extent of a PCI decode..
+ */
+static u32 pci_size(u32 base, u32 mask)
+{
+ u32 size = mask base; /* Find the significant bits */
+ size = size ~(size-1);/* Get the lowest of them to find the decode
+size */
+ return size-1; /* extent = size - 1 */
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
@@ -501,10 +511,10 @@
l = 0;
if ((l PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
res-start = l PCI_BASE_ADDRESS_MEM_MASK;
- sz = ~(sz PCI_BASE_ADDRESS_MEM_MASK);
+ sz = pci_size(sz, PCI_BASE_ADDRESS_MEM_MASK);
} else {
res-start = l PCI_BASE_ADDRESS_IO_MASK;
- sz = ~(sz PCI_BASE_ADDRESS_IO_MASK) 0x;
+ sz = pci_size(sz, PCI_BASE_ADDRESS_IO_MASK 0x);
}
res-end = res-start + (unsigned long) sz;
res-flags |= (l 0xf) | pci_calc_resource_flags(l);
@@ -543,7 +553,7 @@
res-flags = (l PCI_ROM_ADDRESS_ENABLE) |
IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_READONLY |
IORESOURCE_CACHEABLE;
res-start = l PCI_ROM_ADDRESS_MASK;
- sz = ~(sz PCI_ROM_ADDRESS_MASK);
+ sz = pci_size(sz, PCI_ROM_ADDRESS_MASK);
res-end = res-start + (unsigned long) sz;
}
res-name =
Re: Updated 2.4 TODO List - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote:
>
> > drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window.
> [snip]
>
> > align = size = 32*1024*1024;
> Done.
> Didn't work. But it certainly made a difference.
>
> lspci -v now says:
>
> 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
> Subsystem: Xircom Cardbus Ethernet 10/100
> Flags: medium devsel, IRQ 11
> I/O ports at 1800 [size=128]
> [virtual] Memory at 1800 (32-bit, non-prefetchable)
> [size=32M]
> [virtual] Memory at 1800 (32-bit, non-prefetchable)
> [size=32M]
> Expansion ROM at 1800 [disabled] [size=32M]
> Capabilities: [dc] Power Management version 1
There's something really wrong going on with your ethernet controller. It
seems to try to take up all available space.
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev->name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start, r->end);
just after the line that says
if (!r)
continue;
in the same function.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...
Linus Torvalds wrote: > > On Wed, 11 Oct 2000, Dag B wrote: > > 2.4.0-test9/10p1 > > Can you do another test with this (ie in-kernel pcmcia), AND enable > debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in [snip] > drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. [snip] > align = size = 32*1024*1024; Done. Didn't work. But it certainly made a difference. lspci -v now says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] Expansion ROM at 1800 [disabled] [size=32M] Capabilities: [dc] Power Management version 1 What used to be a 4M expansion ROM is now 32M. Just for grins, I made a version with align = size = 64*1024*1024; and got [virtual] Memory at 2000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at 2000 [disabled] [size=64M] debug output from boot follows: dagblap:~# dmesg | more Linux version 2.4.0-test9 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #3 Wed Oct 11 22:0 6:48 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=test10p1a ro root=/dev/discs/disc0/part5 pci=rom [...] PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:68 [10b7/9050] 000200 00 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0005] 000300 00 Found 01:01 [10c8/8005] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource fb00-fbff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource fac0-faff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 [...] NeoMagic 256AV/256ZX audio driver, version 1.1 NM256: Found card signature in video RAM: 0x27ec00 Trying to free nonexistent resource NM256: Mapping port 1 from 0x266c00 - 0x27ec00 Initialized NeoMagic 256AV audio in PCI native mode Initialized AC97 mixer Done installing NM256 audio driver. Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x2 kmem_create: Forcing size word alignment - nfs_fh Yenta IRQ list 0298, PCI irq11 Socket status: 3006 Yenta IRQ list 0298, PCI irq11 Socket status: 3020 ACPI: support found ACPI: PBLK 1 @ 0x0810:0 ACPI: S1 supported ACPI: S5 supported cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 PCI:
Re: Updated 2.4 TODO List - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote: > > Tested with: > 2.2.18pre15 + pcmcia-cs 3.1.21 > 2.4.0-test9/10p1 Can you do another test with this (ie in-kernel pcmcia), AND enable debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in both cases, just change the #undef DEBUG to a #define DEBUG and recompile the kernel). In addition, you might want to change the yenta_allocate_res() thing in drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. Change the line that says align = size = 4*1024*1024; to something like align = size = 32*1024*1024; and see if that makes any difference.. But the DEBUG output is the most interesting part. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...
Keywords: cardbus, dell, xircom, pci, resources In short: Xircom Realport cardbus cards still do not work under Linux in (my) Dell Latitude CPi laptop. A problem indication shows up even before loading the xircom driver. This is not the Latitude docking-station problem, which has been noted by others. AFAICT. Tested with: 2.2.18pre15 + pcmcia-cs 3.1.21 2.4.0-test9/10p1 2.4.0-test9 + pcmcia-cs 3.1.21 quite a few other combinations, including older versions of 2.2 and 2.4-test* kernels and pcmcia-cs. I have tried every combination of "rom,bios,direct" as options to the "pci=" kernel boot-option, 3 different BIOS versions, with and without the docking (which has never caused me any grief, mind you), with cardbus support compiled-in and as modules, and quite a few other tricks and stupidities. No go. As soon as I insert the card (or if the card was inserted prior to boot, during boot-time), I get: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) PCI: Failed to allocate resource 1 for PCI device 115d:0103 PCI: Failed to allocate resource 2 for PCI device 115d:0103 PCI: Failed to allocate resource 6 for PCI device 115d:0103 PCI: Enabling device 06:00.1 ( -> 0003) (-test9) or, in the case of 2.2.18pre15+pcmcia-cs 3.1.21: Oct 8 20:58:56 dagblap pcmcia: Starting PCMCIA services: Oct 8 20:58:56 dagblap pcmcia: modules Oct 8 20:58:57 dagblap kernel: Linux PCMCIA Card Services 3.1.21 Oct 8 20:58:57 dagblap kernel: kernel build: 2.2.18pre15 #1 Sun Oct 8 20:31:01 CEST 2000 Oct 8 20:58:57 dagblap kernel: options: [pci] [cardbus] [apm] [pnp] Oct 8 20:58:57 dagblap kernel: PCI routing table version 1.0 at 0xfbda0 Oct 8 20:58:57 dagblap kernel: 00:03.0 -> irq 11 Oct 8 20:58:57 dagblap kernel: 00:03.1 -> irq 11 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS installation structure at 0xc00fe2d0 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS version 1.0, entry at f:e2f4, dseg at 40 Oct 8 20:58:57 dagblap kernel: Intel PCIC probe: Oct 8 20:58:57 dagblap kernel: TI 1225 rev 01 PCI-to-CardBus at slot 00:03, mem 0x6800 Oct 8 20:58:57 dagblap kernel: host opts [0]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 32/34] Oct 8 20:58:57 dagblap kernel: host opts [1]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 35/37] Oct 8 20:58:57 dagblap kernel: ISA irqs (scanned) = 3,7,9 PCI status changes Oct 8 20:58:57 dagblap pcmcia: cardmgr. Oct 8 20:58:57 dagblap rc: Starting pcmcia succeeded Oct 8 20:58:57 dagblap cardmgr[481]: starting, version is 3.1.21 Oct 8 20:58:57 dagblap kernel: cs: cb_alloc(bus 35): vendor 0x115d, device 0x0003 Oct 8 20:58:57 dagblap cardmgr[481]: watching 2 sockets Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x1000-0x17ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0100-0x04ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0a00-0x0aff: clean. Oct 8 20:58:57 dagblap cardmgr[481]: initializing socket 1 Oct 8 20:58:57 dagblap kernel: cs: no valid ROM images found! Oct 8 20:58:57 dagblap cardmgr[481]: unsupported card in socket 1 Oct 8 20:58:57 dagblap cardmgr[481]: no product info available Oct 8 20:58:57 dagblap cardmgr[481]: PCI id: 0x115d, 0x0003 The hardware is functional. (Tested on NT4.) lspci -v says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 This line: "Expansion ROM at 1100 [disabled] [size=4M]" doesn't look very positive. Can the PCI resource allocation code handle a 4M ROM image? (To the extent which the PCI code cares...?) I do know other users with the exact same type of Xircom card, so this is quite possible some quirk with this particular laptop model. (CPiA 366XT) Any takers? Let me know what debug-switches and knobs I can turn on, and what information I can provide. Regards, Dag B - To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: Updated 2.4 TODO List - more on PCI resources...
Keywords: cardbus, dell, xircom, pci, resources In short: Xircom Realport cardbus cards still do not work under Linux in (my) Dell Latitude CPi laptop. A problem indication shows up even before loading the xircom driver. This is not the Latitude docking-station problem, which has been noted by others. AFAICT. Tested with: 2.2.18pre15 + pcmcia-cs 3.1.21 2.4.0-test9/10p1 2.4.0-test9 + pcmcia-cs 3.1.21 quite a few other combinations, including older versions of 2.2 and 2.4-test* kernels and pcmcia-cs. I have tried every combination of "rom,bios,direct" as options to the "pci=" kernel boot-option, 3 different BIOS versions, with and without the docking (which has never caused me any grief, mind you), with cardbus support compiled-in and as modules, and quite a few other tricks and stupidities. No go. As soon as I insert the card (or if the card was inserted prior to boot, during boot-time), I get: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( - 0003) PCI: Failed to allocate resource 1 for PCI device 115d:0103 PCI: Failed to allocate resource 2 for PCI device 115d:0103 PCI: Failed to allocate resource 6 for PCI device 115d:0103 PCI: Enabling device 06:00.1 ( - 0003) (-test9) or, in the case of 2.2.18pre15+pcmcia-cs 3.1.21: Oct 8 20:58:56 dagblap pcmcia: Starting PCMCIA services: Oct 8 20:58:56 dagblap pcmcia: modules Oct 8 20:58:57 dagblap kernel: Linux PCMCIA Card Services 3.1.21 Oct 8 20:58:57 dagblap kernel: kernel build: 2.2.18pre15 #1 Sun Oct 8 20:31:01 CEST 2000 Oct 8 20:58:57 dagblap kernel: options: [pci] [cardbus] [apm] [pnp] Oct 8 20:58:57 dagblap kernel: PCI routing table version 1.0 at 0xfbda0 Oct 8 20:58:57 dagblap kernel: 00:03.0 - irq 11 Oct 8 20:58:57 dagblap kernel: 00:03.1 - irq 11 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS installation structure at 0xc00fe2d0 Oct 8 20:58:57 dagblap kernel: PnP: PNP BIOS version 1.0, entry at f:e2f4, dseg at 40 Oct 8 20:58:57 dagblap kernel: Intel PCIC probe: Oct 8 20:58:57 dagblap kernel: TI 1225 rev 01 PCI-to-CardBus at slot 00:03, mem 0x6800 Oct 8 20:58:57 dagblap kernel: host opts [0]: [ring] [serial pci irq] [pci irq 11] [lat 32/32] [bus 32/34] Oct 8 20:58:57 dagblap kernel: host opts [1]: [ring] [serial pci irq] [pci irq 11] [lat 32/32] [bus 35/37] Oct 8 20:58:57 dagblap kernel: ISA irqs (scanned) = 3,7,9 PCI status changes Oct 8 20:58:57 dagblap pcmcia: cardmgr. Oct 8 20:58:57 dagblap rc: Starting pcmcia succeeded Oct 8 20:58:57 dagblap cardmgr[481]: starting, version is 3.1.21 Oct 8 20:58:57 dagblap kernel: cs: cb_alloc(bus 35): vendor 0x115d, device 0x0003 Oct 8 20:58:57 dagblap cardmgr[481]: watching 2 sockets Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x1000-0x17ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0100-0x04ff: clean. Oct 8 20:58:57 dagblap kernel: cs: IO port probe 0x0a00-0x0aff: clean. Oct 8 20:58:57 dagblap cardmgr[481]: initializing socket 1 Oct 8 20:58:57 dagblap kernel: cs: no valid ROM images found! Oct 8 20:58:57 dagblap cardmgr[481]: unsupported card in socket 1 Oct 8 20:58:57 dagblap cardmgr[481]: no product info available Oct 8 20:58:57 dagblap cardmgr[481]: PCI id: 0x115d, 0x0003 The hardware is functional. (Tested on NT4.) lspci -v says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] [virtual] Memory at 1100 (32-bit, non-prefetchable) [size=4M] Expansion ROM at 1100 [disabled] [size=4M] Capabilities: [dc] Power Management version 1 This line: "Expansion ROM at 1100 [disabled] [size=4M]" doesn't look very positive. Can the PCI resource allocation code handle a 4M ROM image? (To the extent which the PCI code cares...?) I do know other users with the exact same type of Xircom card, so this is quite possible some quirk with this particular laptop model. (CPiA 366XT) Any takers? Let me know what debug-switches and knobs I can turn on, and what information I can provide. Regards, Dag B - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
Re: Updated 2.4 TODO List - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote: Tested with: 2.2.18pre15 + pcmcia-cs 3.1.21 2.4.0-test9/10p1 Can you do another test with this (ie in-kernel pcmcia), AND enable debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in both cases, just change the #undef DEBUG to a #define DEBUG and recompile the kernel). In addition, you might want to change the yenta_allocate_res() thing in drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. Change the line that says align = size = 4*1024*1024; to something like align = size = 32*1024*1024; and see if that makes any difference.. But the DEBUG output is the most interesting part. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List - more on PCI resources...
Linus Torvalds wrote: On Wed, 11 Oct 2000, Dag B wrote: 2.4.0-test9/10p1 Can you do another test with this (ie in-kernel pcmcia), AND enable debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in [snip] drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window. [snip] align = size = 32*1024*1024; Done. Didn't work. But it certainly made a difference. lspci -v now says: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: medium devsel, IRQ 11 I/O ports at 1800 [size=128] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] [virtual] Memory at 1800 (32-bit, non-prefetchable) [size=32M] Expansion ROM at 1800 [disabled] [size=32M] Capabilities: [dc] Power Management version 1 What used to be a 4M expansion ROM is now 32M. Just for grins, I made a version with align = size = 64*1024*1024; and got [virtual] Memory at 2000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at 2000 [disabled] [size=64M] debug output from boot follows: dagblap:~# dmesg | more Linux version 2.4.0-test9 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #3 Wed Oct 11 22:0 6:48 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=test10p1a ro root=/dev/discs/disc0/part5 pci=rom [...] PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:68 [10b7/9050] 000200 00 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0005] 000300 00 Found 01:01 [10c8/8005] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource fb00-fbff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource fac0-faff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 [...] NeoMagic 256AV/256ZX audio driver, version 1.1 NM256: Found card signature in video RAM: 0x27ec00 Trying to free nonexistent resource c6a63c00-c6a63c0f NM256: Mapping port 1 from 0x266c00 - 0x27ec00 Initialized NeoMagic 256AV audio in PCI native mode Initialized AC97 mixer Done installing NM256 audio driver. Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x2 kmem_create: Forcing size word alignment - nfs_fh Yenta IRQ list 0298, PCI irq11 Socket status: 3006 Yenta IRQ list 0298, PCI irq11 Socket status: 3020 ACPI: support found ACPI: PBLK 1 @ 0x0810:0 ACPI: S1 supported ACPI: S5 supported cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( - 0003) Found 06:01 [115d/0103] 000300 00
Re: Updated 2.4 TODO List - more on PCI resources...
On Wed, 11 Oct 2000, Dag B wrote:
drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window.
[snip]
align = size = 32*1024*1024;
Done.
Didn't work. But it certainly made a difference.
lspci -v now says:
06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
Subsystem: Xircom Cardbus Ethernet 10/100
Flags: medium devsel, IRQ 11
I/O ports at 1800 [size=128]
[virtual] Memory at 1800 (32-bit, non-prefetchable)
[size=32M]
[virtual] Memory at 1800 (32-bit, non-prefetchable)
[size=32M]
Expansion ROM at 1800 [disabled] [size=32M]
Capabilities: [dc] Power Management version 1
There's something really wrong going on with your ethernet controller. It
seems to try to take up all available space.
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev-name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r-flags, r-start, r-end);
just after the line that says
if (!r)
continue;
in the same function.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
