Re: [2.5.55, PCI, PCMCIA, XIRCOM]

Re: [2.5.55, PCI, PCMCIA, XIRCOM]

[Alessandro Suardi]

> 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

Re: [2.5.55, PCI, PCMCIA, XIRCOM]

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

[2.5.55, PCI, PCMCIA, XIRCOM]

[Jochen Hein]

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

Re: [2.5.55, PCI, PCMCIA, XIRCOM]

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]

On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <jochen@jochen.org>  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

[-- Attachment #1.2: pcmcia.patch --]
[-- Type: application/x-patch , Size: 492 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.5.55, PCI, PCMCIA, XIRCOM]

[Jochen Hein]

Valdis.Kletnieks@vt.edu writes:

> On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <jochen@jochen.org>  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

Re: [2.5.55, PCI, PCMCIA, XIRCOM]

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 2775 bytes --]

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:

<ink@jurassic.park.msu.ru>
	[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

[-- Attachment #1.2: pcmcia.temp --]
[-- Type: text/plain , Size: 982 bytes --]

--- drivers/pcmcia/cardbus.c.old	2003-01-10 16:49:11.000000000 -0500
+++ drivers/pcmcia/cardbus.c.new	2003-01-10 16:48:24.000000000 -0500
@@ -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) {


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]