[2.5.55, PCI, PCMCIA, XIRCOM]

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:

@@ -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

resource collisions

The problem is (as I understand it) that drivers/pcmcia/cardbus.c ends up not allocating the onboard ROM resource for some cards before trying to enable it. I've attached a patch that worked for me on 2.5.52, although said patch caused a lot of discussion here about the *right* way to do it (even *I* admit it's a hack) - and I've seen a report it causes an OOPS on 2.5.53. I've not tried it on post-52, but I had a -54 kernel OOPS right around that point in bootup (right after IDE and somewhere in PCI init). Haven't chased that one at all...

/Valdis

@@ -283,8 +283,6 @@
 		dev->hdr_type = hdr & 0x7f;
 
 		pci_setup_device(dev);
-		if (pci_enable_device(dev))
-			continue;
 
 		strcpy(dev->dev.bus_id, dev->slot_name);
 

@@ -302,6 +300,8 @@
 			pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
 		}
 
+		if (pci_enable_device(dev))
+			continue;
 		device_register(&dev->dev);
 		pci_insert_device(dev, bus);
 	}

For reference, this is already filed in bugzilla as
http://bugzilla.kernel.org/show_bug.cgi?id=134 . I should have searched there.

It Oopses for me too:

Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: Found IRQ 11 for device 00:02.0
PCI: Sharing IRQ 11 with 00:03.0
Module yenta_socket cannot be unloaded due to unsafe usage in
include/linux/module.h:420
Yenta IRQ list 06b8, PCI irq11
Socket status: 30000020
PCI: Found IRQ 11 for device 00:02.1
Yenta IRQ list 06b0, PCI irq11
Socket status: 30000006
cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
PCI: Enabling device 01:00.0 (0000 -> 0003)
PCI: Setting latency timer of device 01:00.0 to 64

Unable to handle kernel NULL pointer dereference at virtual address
  00000004
 printing eip:

cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x1000-0x17ff: excluding 0x15e8-0x15ef
cs: IO port probe 0x0a00-0x0aff: clean. c010e02e
*pde = 00000000

Oops: 0000
CPU:    0
EIP:    0060:[<c010e02e>]    Not tainted
EFLAGS: 00010282

EIP is at .text.lock.sys_i386+0x1e/0x88
eax: 00000020 ebx: c571f44c ecx: 00000000 edx: c571f44c
esi: 00002000 edi: c5e17840 ebp: c5defedc esp: c5defecc
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 310, threadinfo=c5dee000 task=c1125280)

Stack: c571f44c c571f400 c5e17840 c571f400 c5deff08 c6a6d1c3 c571f44c 00002000
       c5e177b4 c6a6f288 00000000 c571f44c c5e177ac c571f44c 02100388 c5deff2c
       c01d6983 c571f400 c6a6f210 ffffffed c6a6f288 c571f44c c571f400 c6a6f260
Call Trace:
 [<c6a6d1c3>] xircom_probe+0xff/0xfffaff53 [xircom_cb]
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c01d6983>] pci_match_device+0x47/0x64
 [<c6a6f210>] xircom_pci_table+0x0/0xfffade07 [xircom_cb]
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c6a6f260>] xircom_ops+0x0/0xfffaddb7 [xircom_cb]
 [<c0218088>] device_bind_driver+0x38/0x64
 [<c0218156>] device_attach+0x42/0x70
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c0218413>] bus_remove_device+0x87/0xa4
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c6a6f300>] +0x0/0xfffadd17 [xircom_cb]
 [<c6a6f2a8>] xircom_ops+0x48/0xfffaddb7 [xircom_cb]
 [<c021877a>] put_driver+0x36/0x3c
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c01d6a84>] pci_device_resume+0x44/0x54
 [<c6a6f288>] xircom_ops+0x28/0xfffaddb7 [xircom_cb]
 [<c6a1d00d>] 0xc6a1d00d
 [<c6a6f260>] xircom_ops+0x0/0xfffaddb7 [xircom_cb]
 [<c012c9d6>] load_module+0x13a/0x1cc
 [<c0108d9b>] system_call+0x7/0xb

Code: 8b 51 04 85 d2 77 09 75 05 83 39 fe 77 02 0c 01 8d 5e ff c1

#include <~/.signature>: permission denied

if it OOPSes without my patch, then it's somebody else's problem. If it does so with my patch, but just gives the infamous "resource collisions" message without it, then it's my fault ;)

OK.. we obviously made it *into* cb_alloc()..

This is coming out of pcibios_enable_resources() - the same function that without my patch would have given the 'resource collisions' error and returned.

xircom_probe to pci_set_master to pcibios_set_master, and we've returned from pci_enable_device. and thus we've gotten past where my patch is. Only possibility is that my code has re-arraigned some pointers in an evil way.

Now, it's pretty obvious that *some* call to pci_assign_resource has to happen before pci_enable_device() for these Xircom cards for things to work at all (and note that they work just fine in 2.4 and pre-2.5.47).

I wonder if the *current* problem with the OOPs is due to this change in the .53 patches to pci/setup_{bus,res}.c - as per the changelog:

<[email protected]>
[PATCH] PCI: setup-xx fixes

Don't disable PCI devices before changing the BARs, as discussed recently. Disabling PCI_COMMAND_MASTER bit is an obvious bug.

Further, pdev_enable_device() is a leftover from very old (2.0, I guess) alpha PCI code. It's used in pci_assign_unassigned_resources() to enable *every* PCI device in the system. So, if we have two graphic cards on the same bus, both with legacy VGA IO... oops.

Actually, only alpha relied on that due to the lack of pcibios_enable_device (which has been already fixed).

After this patch, we no longer go into pdev_enable_device, which may have been doing something that was in fact still needed by the Xircom code, although I'm mostly guessing that it's the 'disable the ROM'. The other possibility is that ink's patch exposes a problem with the way my patch calls pci_alloc_resource() before pci_enable_device().

In any case, I've attached a new *UNTESTED* patch, that only tries to gratuitously assign resources of MEM class, and disables the ROM once it does so.

No, I don't claim to fully understand this code. And if you're not brave enough or can't test it yourself, I'll be taking the 2.5.56 plunge sometime this weekend. ;) And all you other kernel hackers are welcome to jump right in and tell me what I'm doing wrong.. ;)

/Valdis

@@ -283,18 +283,26 @@
 		dev->hdr_type = hdr & 0x7f;
 
 		pci_setup_device(dev);
-		if (pci_enable_device(dev))
-			continue;
 
 		strcpy(dev->dev.bus_id, dev->slot_name);
 
 		/* FIXME: Do we need to enable the expansion ROM? */
 		for (r = 0; r < 7; r++) {
 			struct resource *res = dev->resource + r;
-			if (res->flags)
+			if (res->flags & IORESOURCE_MEM) {
 				pci_assign_resource(dev, r);
+				if (dev->rom_base_reg) {
+					pci_read_config_dword(dev, dev->rom_base_reg, &reg);
+					reg &= ~PCI_ROM_ADDRESS_ENABLE;
+					pci_write_config_dword(dev, dev->rom_base_reg, reg);
+					dev->resource[PCI_ROM_RESOURCE].flags &= ~PCI_ROM_ADDRESS_ENABLE;
+				}
+			}
 		}
 
+		if (pci_enable_device(dev))
+			continue;
+
 		/* Does this function have an interrupt at all? */
 		pci_readb(dev, PCI_INTERRUPT_PIN, &irq_pin);
 		if (irq_pin) {