With 2.4.20 the xircom_cb driver works perfectly on my Thinkpad 600.
Loading the driver with 2.5.55 for my IBM ethernet card I get:
Jan 10 11:35:24 gswi1164 kernel: Linux Kernel Card Services 3.1.22
Jan 10 11:35:24 gswi1164 kernel: options: [pci] [cardbus] [pm]
Jan 10 11:35:24 gswi1164 kernel: PCI: Found IRQ 11 for device 00:02.0
Jan 10 11:35:24 gswi1164 kernel: PCI: Sharing IRQ 11 with 00:03.0
Jan 10 11:35:24 gswi1164 kernel: Module yenta_socket cannot be unloaded due to unsafe usage in include/linux/module.h:420
Jan 10 11:35:24 gswi1164 kernel: Yenta IRQ list 06b8, PCI irq11
Jan 10 11:35:24 gswi1164 kernel: Socket status: 30000020
Jan 10 11:35:24 gswi1164 kernel: PCI: Found IRQ 11 for device 00:02.1
Jan 10 11:35:24 gswi1164 kernel: Yenta IRQ list 06b0, PCI irq11
Jan 10 11:35:24 gswi1164 kernel: Socket status: 30000006
Jan 10 11:35:24 gswi1164 kernel: cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
Jan 10 11:35:24 gswi1164 kernel: PCI: Device 01:00.0 not available because of resource collisions
The message is not helpful at all. Looking at the source in
arch/i386/pci/i386.c I find:
246 int pcibios_enable_resources(struct pci_dev *dev, int mask)
247 {
248 u16 cmd, old_cmd;
249 int idx;
250 struct resource *r;
251
252 pci_read_config_word(dev, PCI_COMMAND, &cmd);
253 old_cmd = cmd;
254 for(idx=0; idx<6; idx++) {
255 /* Only set up the requested stuff */
256 if (!(mask & (1<<idx)))
257 continue;
258
259 r = &dev->resource[idx];
260 if (!r->start && r->end) {
261 printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name) ;
262 return -EINVAL;
263 }
The following patch should provide some useful hints, why it is
failing:
--- linux-2.5.55/arch/i386/pci/i386.c.jh 2003-01-10 13:57:44.000000000 +0100
+++ linux-2.5.55/arch/i386/pci/i386.c 2003-01-10 14:39:34.000000000 +0100
@@ -258,7 +258,7 @@
r = &dev->resource[idx];
if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
+ printk(KERN_ERR "PCI: Device %s not available because of resource collisions (start: %08lx, end: %08lx)\n", dev->slot_name, r->start, r->end);
return -EINVAL;
}
if (r->flags & IORESOURCE_IO)
Now I get the message:
PCI: Device 01:00.0 not available because of resource collisions (start: 00000000, end: 0000007f)
Looking at the reserved regions:
root@gswi1164:/usr/src# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vesafb
03e8-03ef : serial
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-10ff : PCI CardBus #01
1400-14ff : PCI CardBus #01
1800-18ff : PCI CardBus #04
1c00-1cff : PCI CardBus #04
8400-841f : Intel Corp. 82371AB/EB/MB PIIX4
8400-841f : uhci-hcd
ef00-ef3f : Intel Corp. 82371AB/EB/MB PIIX4
efa0-efbf : Intel Corp. 82371AB/EB/MB PIIX4
fcf0-fcff : Intel Corp. 82371AB/EB/MB PIIX4
fcf0-fcf7 : ide0
fcf8-fcff : ide1
I don't understand, why the PCMCIA services try to claim these io
resources. The /proc/ioports of 2.4.20 are:
root@gswi1164:~# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vesafb
03e8-03ef : serial(set)
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
4000-40ff : PCI CardBus #01
4000-407f : PCI device 115d:0003
4000-407f : xircom_cb
4400-44ff : PCI CardBus #01
4800-48ff : PCI CardBus #04
4c00-4cff : PCI CardBus #04
8400-841f : Intel Corp. 82371AB/EB/MB PIIX4 USB
8400-841f : usb-uhci
ef00-ef3f : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
efa0-efbf : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
fcf0-fcff : Intel Corp. 82371AB/EB/MB PIIX4 IDE
fcf0-fcf7 : ide0
fcf8-fcff : ide1
I don't know who is to blame, but I guess it's the xircom driver or
the pcmcia layer. Any ideas?
Jochen
-- #include <~/.signature>: permission denied - 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 : Wed Jan 15 2003 - 22:00:33 EST