Kernel Bug Tracker – Bug 7116
pcnet_cs no longer works after linux-2.6.16-git20 (Too much work at interrupt)
Last modified: 2012-05-14 17:03:07 UTC
Most recent kernel where this bug did not occur: 2.6.16-git20
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
I have this pcnet_cs card which has always worked no problem up to
188.8.131.52. I just tried to upgrade to 2.6.17, and the kernel log is
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.
Where can I find the dump_cis and dump_cisreg equivalents for the new PCMCIA
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]
Created attachment 9093 [details]
Created attachment 9094 [details]
Created attachment 9095 [details]
Created attachment 9096 [details]
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
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
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
Author: Dominik Brodowski <email@example.com>
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 <firstname.lastname@example.org>
:040000 040000 967add784fbb04f2af52f2e0f5e942284e95bbff
704326f0e53a1f83aae4403aac771357943c9cf2 M drivers
:040000 040000 0be81163641a820bba7da5b68713c23fbe6f3d26
582e25d839c2abd4be56ffa38932a9a7188b6a69 M include
Created attachment 9164 [details]
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]
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]
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 184.108.40.206 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]
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]
Created attachment 16611 [details]
Created attachment 16612 [details]
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.
Could you try modprobing these modules first, before inserting the card?
Created attachment 16626 [details]
dmesg with pcmcia debug
Created attachment 16627 [details]
Created attachment 16628 [details]
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 220.127.116.11.
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 18.104.22.168.
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).
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...