From: Jochen Hein <jochen@jochen.org>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: [2.5.55, PCI, PCMCIA, XIRCOM]
Date: Fri, 10 Jan 2003 17:21:51 +0100 [thread overview]
Message-ID: <87znq9ynz4.fsf@jupiter.jochen.org> (raw)
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
next reply other threads:[~2003-01-10 16:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 16:21 Jochen Hein [this message]
2003-01-10 17:13 ` [2.5.55, PCI, PCMCIA, XIRCOM] Valdis.Kletnieks
2003-01-10 19:00 ` Jochen Hein
2003-01-10 22:17 ` Valdis.Kletnieks
-- strict thread matches above, loose matches on Subject: below --
2003-01-12 22:58 Alessandro Suardi
2003-01-12 23:16 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87znq9ynz4.fsf@jupiter.jochen.org \
--to=jochen@jochen.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.