2.5/2.6 PCMCIA Issues

2.5/2.6 PCMCIA Issues

[Misha Nasledov]

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

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
misha@nasledov.com
http://nasledov.com/misha/

[-- Attachment #2: config-2.6.0-test2.gz --]
[-- Type: application/octet-stream, Size: 6802 bytes --]

Re: 2.5/2.6 PCMCIA Issues

[Russell King]

On Mon, Aug 04, 2003 at 04:22:04PM -0700, Misha Nasledov wrote:
> 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.

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.

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

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

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

What type of console?  Standard VT or under X11?

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

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5/2.6 PCMCIA Issues

[Misha Nasledov]

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

On Tue, Aug 05, 2003 at 02:44:53PM +0100, Russell King wrote:
> 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.

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.

> What type of console?  Standard VT or under X11?

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

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

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
misha@nasledov.com
http://nasledov.com/misha/

[-- Attachment #2: aurora-dmesg.gz --]
[-- Type: application/octet-stream, Size: 3764 bytes --]

Re: 2.5/2.6 PCMCIA Issues

[OSDL]

Misha Nasledov wrote:
> 
> 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.

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

Re: 2.5/2.6 PCMCIA Issues

[Andrew Morton]

OSDL <torvalds@osdl.org> wrote:
>
> Misha Nasledov wrote:
> > 
> > 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.
> 
> 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.

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/

Re: 2.5/2.6 PCMCIA Issues

[Misha Nasledov]

On Tue, Aug 05, 2003 at 10:59:43PM -0700, OSDL wrote:
> 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.

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
misha@nasledov.com
http://nasledov.com/misha/

Re: 2.5/2.6 PCMCIA Issues

[Misha Nasledov]

Hi,

On Tue, Aug 05, 2003 at 10:59:43PM -0700, OSDL wrote:
> You should try with just CONFIG_YENTA - the 82365 stuff is for the old
> 16-bit only controllers.

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
misha@nasledov.com
http://nasledov.com/misha/

Re: 2.5/2.6 PCMCIA Issues

[Linus Torvalds]

Andrew Morton wrote:
>
> 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.

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

Re: 2.5/2.6 PCMCIA Issues

[Russell King]

On Wed, Aug 06, 2003 at 12:11:00AM -0700, Linus Torvalds wrote:
> Andrew Morton wrote:
> > Disabling i82635 in config fixes it up.
> 
> Ok. Misha confirmed that disabling 82365 works for him too.

Interesting.

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

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5/2.6 PCMCIA Issues

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5/2.6 PCMCIA Issues

[Adam Belay]

On Tue, Aug 05, 2003 at 10:59:43PM -0700, OSDL wrote:
> Misha Nasledov wrote:
> > 
> > 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.
> 
> 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.

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.

--- a/drivers/pcmcia/i82365.c	2003-07-27 17:08:32.000000000 +0000
+++ b/drivers/pcmcia/i82365.c	2003-08-06 11:18:21.000000000 +0000
@@ -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;


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

Thanks,
Adam

Re: 2.5/2.6 PCMCIA Issues

[Linus Torvalds]

On Wed, 6 Aug 2003, Russell King wrote:
> 
> 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.

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.

> 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.)

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

Re: 2.5/2.6 PCMCIA Issues

[Russell King]

On Wed, Aug 06, 2003 at 11:42:25AM +0000, Adam Belay wrote:
> 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.

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5/2.6 PCMCIA Issues

[Andrew Morton]

Adam Belay <ambx1@neo.rr.com> wrote:
>
> [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.

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

Re: 2.5/2.6 PCMCIA Issues

[Russell King]

On Wed, Aug 06, 2003 at 01:34:50PM -0700, Andrew Morton wrote:
> Adam Belay <ambx1@neo.rr.com> wrote:
> >
> > [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.
> 
> This patch fixes the insertion-time hang on the A21P, with CONFIG_I82365=y

Ok, I'll merge that now.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.5/2.6 PCMCIA Issues

[Alan Cox]

On Mer, 2003-08-06 at 08:11, Linus Torvalds wrote:
> 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).

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

Re: 2.5/2.6 PCMCIA Issues

[Misha Nasledov]

Hi,

I think I know what you're talking about. My laptop won't suspend either if
there are PCMCIA cards in it; once I take out the offending PCMCIA cards and
try to suspend again, it'll suspend properly. I think this is a bug as this
kind of thing never happened in 2.4.. I'm Cc'ing this to lkml, so maybe
somebody will take a look at it...

On Mon, Oct 13, 2003 at 07:10:10PM +0300, Jari Tenhunen wrote:
> Hi,
> 
> I found your old post on lkml. I'm having exactly same kind of problems
> with my laptop (Thinkpad T20). 2.6-series up to 2.6.0-test6 won't
> suspend and it seems that the problem is PCMCIA (no errors, screen
> blanksi, hd spins down but won't suspend). After some testing 
> I found out that after unloading the yenta_socket module everything works.
> 
> Have you seen any patches for this or have you managed to contact the
> developer(s)?

-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/