2.5/2.6 PCMCIA Issues

Hi,

I was told that you would be the correct person to write to regarding issues with PCMCIA under the 2.5/2.6 kernels. I own an IBM ThinkPad T21 with a Texas Instruments PCI1450 (rev 03) CardBus bridge. When I first installed a 2.5 kernel on here, it was 2.5.73; when I would insert my Orinoco card, it would work fine, but when I ejected the card (either manually or by using cardctl first), the module would fail to unload and this would cause issues, eventually forcing me to reboot my machine to relinquish my Orinoco card. 2.5.74 was supposed to have some PCMCIA fixes to fix this hotplug issues, but to my surprise, it made my PCMCIA problems even worse; as soon as I put my Orinoco card into the slot, the system would completely lock up. Even the cursor in my console would stop blinking, so I am unable to get any sort of oops message or kernel error for you. Kernels 2.5.75, 2.6.0-test1, and 2.6.0-test2 also had the new problem from 2.5.74. If it is in any way pertinent, I am running the latest version of cardmgr from pcmcia-cs.

Please find attached a gzipped copy of my 2.6.0-test2 .config file.

Misha Nasledov
[email protected]
http://nasledov.com/misha/

Explain this further. If you're saying that, when you removed the Orinoco card, that the eth interface remained (as shown by iwconfig and ifconfig) and the module use count didn't drop to zero, this isn't a PCMCIA problem. It's a problem somewhere in the hotplug / network scripts failing to take the interface down.

There were some fixes to this, but they were incomplete until 2.6.0-test2.

What type of console? Standard VT or under X11?

The boot time kernel messages would be useful to see for 2.6.0-test2, including those issued by PCMCIA when the modules are loaded.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

I don't believe the ethernet interface remained, but the module use count definitely did not drop to zero. I suppose it's possible it's an issue with the scripts, but the same scripts work perfectly under 2.4.21, which is what I primarily use on my laptop.

This was under the Linux framebuffer; inserting the card was the first thing I did after it displayed the login prompt.

I am attaching the dmesg output after booting 2.6.0-test2; this does not include the insertion of the Orinoco card as the console freezes immediately after the event. I inspected my logs after a reboot and there were no messages whatsoever regarding the event of the insertion of the Orinoco card.

Misha Nasledov
[email protected]
http://nasledov.com/misha/

Can you try with PnP and the i82365 support _disabled_. I find this sequence very suspicious:

Intel PCIC probe: PNP <6>pnp: Device 00:17 activated. invalid resources ?
pnp: Device 00:17 disabled.
not found.

and I bet it messes up some of the register state that the yenta probe had just set up.

You should try with just CONFIG_YENTA - the 82365 stuff is for the old 16-bit only controllers.

Linus

I have an IBM A21P which has the same problem.

The controller is a PCI1450 (rev 03)

The symptoms are that insertion of a PCMCIA or Cardbus card causes the machine to lock up: it is calling yenta_interrupt() a zillion times per second. Presumably the IRQ isn't getting cleared.

Disabling i82635 in config fixes it up.

2.5.70 does not lock up. 2.5.71 does lock up.

dmesg and .config are at

	http://www.zip.com.au/~akpm/linux/patches/a21p-lockup/

Ok. Misha confirmed that disabling 82365 works for him too.

I don't see what should have changed in 2.5.71 here, though. There are some pcmcia changes there, but they all look like they are just changes to the calling convention, not any _functional_ differences.

Anyway, I suspect that i82365 should just quit by default if a yenta controller has already been found. I can't imagine that you'd have both a yenta controller _and_ an i82365 controller, since there are actually some port overlaps there (ie yenta should already register the i82365 legacy ports).

Something is broken in resource handling that the i82365 driver even tries to probe for the ports that are in use.

Russell, any ideas about why i82365 doesn't just leave the thing well alone?

Linus

Interesting.

Not really - I suspect there's something else going on.

When yenta initialises, we claim the PCI resources for it, and disable the legacy IO space by writing 0 to it (it reads back 1.) This is the same that we've always done.

I wonder if the PNP code is activating the legacy IO space, and thereby screwing up the configuration which yenta has setup.

Could someone with both yenta and i82365 with PNP try running lspci -vv after both have tried to initialise, and obviously before inserting a card in a slot? You should see:

16-bit legacy interface ports at 0001

as the last line for each of the Cardbus bridge devices.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Ok, more data points.

- Zwane Mwaikambo tried enabling yenta + i82365 + pnp on his machine. The boot messages for PCMCIA were:

Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
...
ti113x: Routing card interrupts to PCI
Yenta IRQ list 0000, PCI irq9
Socket status: 30000006
Intel PCIC probe: not found.

As you can see, the PCIC probe didn't find any PNP devices. No problems were noticed.

- I've just tried modular PCMCIA, inserting both yenta and i82365 on an (arm) machine, obviously without PNP here...

Linux Kernel Card Services 3.1.22
options: [pci] [cardbus]
irq 21: nobody cared
Yenta IRQ list 0000, PCI irq21
Socket status: 30000007
irq 22: nobody cared
Yenta IRQ list 0000, PCI irq22
Socket status: 30000811
Intel PCIC probe: <7>PCI: master abort, pc=0xbf020818
PCI: master abort, pc=0xbf020818
PCI: master abort, pc=0xbf020818
not found.

Again, no PNP activity as expected, and no undesirable side effects caused by inserting and removing PCMCIA cards. (the master aborts come from attempting to access 0x3e0/1 and having nothing on the PCI bus to claim it... yes, not even an ISA bridge...)

Could the problem be PNP related? I don't see much material change in the PNP layer between 2.5.70 and 2.5.71 though.

Can other people try the CONFIG_YENTA=y, CONFIG_I82365=y, CONFIG_PNP=y and report their results (in particular the dmesg from boot, and whether the machine locks when they insert a card _after_ boot.)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

It definitely could be PnP-related, and it may well show up only on machines that have the yenta controller listed as an old-style pcmcia controller in the bios etc.

Yes, getting more data-points would be good. Together with what kind of machine they have (not just what kind of yenta controller, but the bios and manufacturer..)

Linus

I have such a box, it worked in 2.4 (the i82365 is at different ports)

I tried with i82365 support disabled and my card's module successfully loaded and all was in order. When I tried ejecting the card at first, it seemed like it would fail as I got a message in my syslog saying "unregister_netdevice: waiting for eth0 to become free. Usage count = 3", but after a few patient moments, the module was finally unloaded.

Thanks for your help!

Misha Nasledov
[email protected]
http://nasledov.com/misha/

Hi,

While playing around with 2.6.0-test2 on my laptop, I tried to see if APM support still worked on it. When I tried apm --suspend, the screen would blank, but it would unblank as soon as I hit a key and I would have the syslog messages "kernel: Suspending devices" and "kernel:
Devices Resumed." I found that if I ejected my card and made sure the drivers were properly unloaded, apm --suspend once again suspended my laptop. Under 2.4, the kernel would properly suspend while cards were loaded, although I would sometimes have issues with waking the laptop up if the state it was woken up in did not match the state it was put to sleep in.

Misha Nasledov
[email protected]
http://nasledov.com/misha/

Here's a quick fix that will at least correct the i82365 probing. It will be interesting to see what effect it has on these other problems. Note that this driver needs some work with check_region etc.

[PCMCIA] Fix PnP Probing in i82365.c
pnp_x_valid returns 1 if valid. Therefore we should be using !pnp_port_valid. Also cleans up some formatting issues.

@@ -795,16 +795,14 @@
 
 	    if (pnp_device_attach(dev) < 0)
 	    	continue;
-
-	    printk("PNP ");
-
+
 	    if (pnp_activate_dev(dev) < 0) {
 		printk("activate failed\n");
 		pnp_device_detach(dev);
 		break;
 	    }
 
-	    if (pnp_port_valid(dev, 0)) {
+	    if (!pnp_port_valid(dev, 0)) {
 		printk("invalid resources ?\n");
 		pnp_device_detach(dev);
 		break;

Thanks,
Adam

Ok, this may allow us to detect the i82365 device. However, yenta_socket is already controlling it, and it has disabled the legacy port access.

Now, i82365 initialises, and PNP tells it that we have this device. PNP tries to activate it. This is where we are probably going wrong.

I think we need some way for yenta to tell the PNP subsystem to ignore the device that yenta is controlling.

As far as check_region goes - fixing it looks like it'll be fairly disgusting. The probing seems to be pretty complex, and I don't have the hardware to test against. So, until someone who cares about it puts the work in, I'm not touching that part of it. 8)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

This patch fixes the insertion-time hang on the A21P, with CONFIG_I82365=y

Ok, I'll merge that now.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html