Bug 7116

http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO-6.html
Where can I find the dump_cis and dump_cisreg equivalents for the new PCMCIA 
subsystem?

tried that with 2.6.18 on and toshiba 530CDT (should be pretty much the same HW)
and a Natsemi network card (also pcnet_cs driver). it worked just fine. also a
xircom card works w/o problems. so could you do try 2.6.18 and if not working
give the output of dmesg, lspci -vvv from a working and a non-working kernel.
also post a copy of your config.opts.

dump_cis and cbdump can be built using "make debugtools". no dump_cisreg...

Created attachment 9092 [details]
config.opts

Created attachment 9093 [details]
dmesg

Created attachment 9094 [details]
dmesg

Created attachment 9095 [details]
lspci

Created attachment 9096 [details]
lspci

Created attachment 9097 [details]
the bootup log of 2.6.18

Maybe it has to do with the "driver needs updating to support shared IRQ" in 
dmesg?

looking at the files it's not obvious what's wrong. i also tried your
config.opts on my tecra530, but it works. also looking at pcnet_cs and pcmcia
changes there's nothing obvious. i think it's about resource assignments. cbdump
with the card inserted from both kernels could probably tell. if they're
different you have to play with those:
  include memory 0xc0000-0xfffff
  include memory 0xa0000000-0xa0ffffff
  include memory 0x60000000-0x60ffffff
  include memory 0x10000000-0x1fffffff
one of those line might contain resources that should not be used...

and if all that does not help: "git bisect" will tell what change broke your box...

Down to 5 changes on git bisect, some other interesting message I saw:
eth0: mismatched read page pointers  1 vs 3f.
This message alternates with the too much work at interrupt message on one 
particular revision.

The problem is introduced in one of the following patches:
dbb22f0d65ccc2e9dfeb4c420942f2757a80f8d2    [PATCH] pcmcia: access config_t 
using pointer instead of array
855cdf134dfcf2ecb92ac4ad675cf655d8ceb678    [PATCH] pcmcia: always use device 
pointer to config_t
360b65b95bae96f854a2413093ee9b79c31203ae    [PATCH] pcmcia: make config_t 
independent, add reference counting

Very strange.  I'll find the offending patch tomorrow since I'm out of time.

$ git bisect good
360b65b95bae96f854a2413093ee9b79c31203ae is first bad commit
commit 360b65b95bae96f854a2413093ee9b79c31203ae
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Tue Jan 10 20:50:39 2006 +0100

    [PATCH] pcmcia: make config_t independent, add reference counting

    Handle config_t structs independent of struct pcmcia_socket, and add
    reference counting for them.

    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>

:040000 040000 967add784fbb04f2af52f2e0f5e942284e95bbff 
704326f0e53a1f83aae4403aac771357943c9cf2 M      drivers
:040000 040000 0be81163641a820bba7da5b68713c23fbe6f3d26 
582e25d839c2abd4be56ffa38932a9a7188b6a69 M      include

Created attachment 9164 [details]
test patch

does the test patch make any difference?

Same problem exists (now using HEAD)

Any ideas?  I have no clue what's going on with that driver.

Do you even have anything to suspect that I can play around with?

sorry, i can't see what's wrong. cc'ing Dominik as he might have a better idea.

anyway, could you provide a 'cbdump' output with the card inserted for a working
and a non-working kernel? 

Created attachment 9432 [details]
pcmcia-fixes-2.6.git

Could you test 2.6.19-rc5 with this patch, please?

I only have access to -rc4 in git, testing that now.

Works now!  So what was the problem?

I'm not really sure :) Could you post the output of "lspcmcia -vvv", please?

Created attachment 9445 [details]
lspcmcia

Here you go

Thanks -- the bugfix is that the resource management code of the PCMCIA core was
informed too late that this is a multifunction card.

I've upgraded to 2.6.25.8 with the same config (make oldconfig) and this problem is back.

What was the last kernel version which worked for you? Also, could you post a dmesg and "lspci -vvv" output of a working and non-working kernel, please?

I haven't bisected since I don't have the time but I am using 2.6.19-rc5 which seems to work.  Attachments follow

Created attachment 16609 [details]
dmesg 2.6.19-rc5

Not too useful because of kobject debug spam.  Let me know if you need me to rebuild 2.6.19-rc5 with a bigger dmesg buffer.

Created attachment 16610 [details]
dmesg 2.6.25.8

Created attachment 16611 [details]
lspci 2.6.19-rc5

Created attachment 16612 [details]
lspci 2.6.25.8

I'm a bit confused about this one... are "pcnet_cs" and "serial_cs" built in, or is just one of those a module which gets loaded afterwards? It shouldn't matter, but maybe this card needs pcnet_cs to be up and running before serial_cs...

Also, could you post a "lspcmcia -vvv" (sorry for the typo yesterday) for the new kernel? (we have one for a working one already). Also, so far there's no need to bisect. What might be useful, though, is enabling PCMCIA_DEBUG and setting the module parameter "debug" of the module pcmcia to 10 (if it's built-in, add "pcmcia.debug=10" to the kernel command line, if it's a module, "modprobe pcmcia debug=10").

pcnet_cs and serial_cs are modules.  I will enable PCMCIA debug and post back.

Reply-To: linux@dominikbrodowski.net

Could you try modprobing these modules first, before inserting the card?

Created attachment 16626 [details]
dmesg with pcmcia debug

Created attachment 16627 [details]
lspcmcia 2.6.19-rc5

Created attachment 16628 [details]
lspcmcia 2.6.25.8

Created attachment 16629 [details]
dmesg with modules pre-inserted

Created attachment 16630 [details]
lspcmcia with modules pre-inserted

Hm, that's a tough one. Could you try out kernel 2.6.20 and check whether that works?

2.6.20 has this problem also.

And still no fix in 2.6.27.4.

Finally, some illumination.  I have some more of these IBM H&A credit cards.  There seems to have been a firmware update (HAWIN95.EXE) available at some point.  This firmware update seems to change the prodid string from "Home and Away Credit Card Adapter" to "w95 Home and Away Credit Card ".  It is the "w95" version which does not function with Linux.  The card without the "w95" firmware works perfectly.  So now where to look?

I did the obvious thing and flashed the "w95" card back to the original firmware.

Now it works.

Apparently, whatever hack is done by IBM to support Win95 renders the card incompatible with later versions of Linux.

Both the Win95 and original firmware work correctly with Linux prior to some change in 2.6.16.28.

It seems that the IBM Win95 kludge has to do with how the separate devices on the multifunction card are enumerated.  Perhaps this is why the above patch worked for the time (and then broke again later).

Hi,

Does this problem still exist?

Could you try kernel 2.6.30-git15 or newer?

Even better would be trying out 2.6.34-rc1, once it gets out in a few days...