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
On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <[email protected]> said:
>
>
> 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: PCI: Device 01:00.0 not available because of
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
[email protected] writes:
> On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <[email protected]> said:
>> Jan 10 11:35:24 gswi1164 kernel: PCI: Device 01:00.0 not available because of
> 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)
For reference, this is already filed in bugzilla as
http://bugzilla.kernel.org/show_bug.cgi?id=134 . I should have
searched there.
> - 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...
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
On Fri, 10 Jan 2003 20:00:31 +0100, Jochen Hein said:
> > - 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...
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 ;)
> cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
OK.. we obviously made it *into* cb_alloc()..
> PCI: Enabling device 01:00.0 (0000 -> 0003)
This is coming out of pcibios_enable_resources() - the same function that
without my patch would have given the 'resource collisions' error and
returned.
> PCI: Setting latency timer of device 01:00.0 to 64
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
> On Fri, 10 Jan 2003 20:00:31 +0100, Jochen Hein said:
> > > - 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
Guess the report was mine :) note for readers, this is bug 134
in the 2.5 kernel bug database at http://bugme.osdl.org .
> > > right around that point in bootup (right after IDE and somewhere in PCI
> > > init). Haven't chased that one at all...
> if it OOPSes without my patch, then it's somebody else's problem.
No, it did oops only with the patch.
[snip]
> 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.. ;)
-ENOPATCH ;)
Ciao,
--alessandro
On Sun, 12 Jan 2003 14:58:39 PST, Alessandro Suardi said:
> > On Fri, 10 Jan 2003 20:00:31 +0100, Jochen Hein said:
> > > > - 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
>
> Guess the report was mine :) note for readers, this is bug 134
> in the 2.5 kernel bug database at http://bugme.osdl.org .
>
> > > > right around that point in bootup (right after IDE and somewhere in PCI
> > > > init). Haven't chased that one at all...
> > if it OOPSes without my patch, then it's somebody else's problem.
>
> No, it did oops only with the patch.
My *original* patch (the one that just moved 2 lines) plus the 2-liner
by Zwane Mwaikambo to fix the DMA patch is working for me. I know Zwane's
patch is already in Bitkeeper, I don't think we've ever resolved the "right"
solution for mine....
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech