Most recent kernel where this bug did not occur: 2.6.16-git20 Distribution: Debian Hardware Environment: Toshiba 500CDT, ToPIC95-B, Ibm H&A 10mbps Ethernet/modem Software Environment: Problem is present in 2.6.17-rc1, 2.6.17, and git current Problem Description: I have this pcnet_cs card which has always worked no problem up to 2.6.16.28. I just tried to upgrade to 2.6.17, and the kernel log is flooded with eth0: Too much work at interrupt, status 0x22 along with the occasional eth0: pcnet_reset_8390() did not complete. and no network traffic works. I tried removing and reinserting the card and driver with no improvement. I see where this problem occurs in 8390.c but am baffled since there were no changes to that file. There were changes in pcnet_cs.c but mostly API updates from what I can tell. Steps to reproduce: Insert and attempt to use the aforementioned pcnet_cs card with any distribution after linux-2.6.16-git20. I tried disable_clkrun option of yenta_socket with no effect.
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...