Red Hat Bugzilla – Bug 123505
/etc/pcmcia/config references missing modules
Last modified: 2007-11-30 17:07:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
Numerous drivers referenced in /etc/pcmcia/config are missing. Some
are gone completely. Others have man pages, but lack the actual
For example, the 3c589 card claims to be supported:
> class "network" module "3c589_cs"
>card "3Com 589 Ethernet"
> manfid 0x0101, 0x0589
> bind "3c589_cs"
However, inserting a 3c589 card yields a "didn't work" beep code from
the speaker, and the following in the logs
May 18 17:03:33 localhost cardmgr: socket 0: 3Com 589 Ethernet
May 18 17:03:33 localhost kernel: cs: memory probe
May 18 17:03:33 localhost cardmgr: executing: 'modprobe 3c589_cs'
May 18 17:03:33 localhost cardmgr: + modprobe: Can't locate
May 18 17:03:33 localhost cardmgr: modprobe exited with status
255May 18 17:03:33 localhost cardmgr: module
/lib/modules/2.4.21-9.EL/pcmcia/3c589_cs.o not available
May 18 17:03:34 localhost cardmgr: get dev info on socket 0
failed: Resource temporarily unavailable
This is due to the fact that there is no 3c589_cs.o module installed
anywhere on the machine. Other modules that don't exist include:
xirc2ps_cs (manpages present, no module)
And many others, but I don't have the time go through and find all of
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Obtain 3c589
2. Place in PCMCIA slot
3. Hear 1 happy beep indicating the card was recognized by cardmgr.
4. Hear 1 sad beep indicating the module could not be located.
5. less +G /var/log/messages
Actual Results: The card was detected, but unusuable as there was no
Expected Results: The 3c589_cs module should have been installed by
the distribution, and then found by cardmgr, and then loaded.
If a bunch of PCMCIA modules were removed on purpose (which I
sincerely hope is not the case), then the pcmcia config files need to
get cleaned up. But a card should not be detected and then fail
because the module wasn't shipped with the package.
This is precisely the sort of problem that I had hoped my customers
would have avoided by going to a well tested Red Hat Enterprise Product.
A quick repair of this problem would be most useful to Red Hat's and
my customers doing new RHE installs.
for Red Hat Enterprise Linux
Massachusetts Institute of Technology
have you installed the kernel-unsupported rpm from the cd/RHN ?
Installing the kernel-unsupported rpm did work. However, there needs to be an option in
the installer, or at least some mention of the fact that you'll get a broken behavior until
you install this rpm. The fact that /etc/pcmcia/config contains references to modules that
have manpages, but don't actually have the modules installed is broken. Upon hearing
one successful beep and one low-pitched beep when inserting the 3c589 card, most users
would attribute that to some problem with their card, rather than thinking "Hrm, maybe
there's an rpm that contains a bunch of unsupported modules"
Why is it an "enhancement" that the PCMCIA, as presently constructed refers to missing
modules, and does not adequately give users the clue about how to remedy the problem?
I could see this as a low priority bug. But I'm afraid that I REALLY think this is a BUG, not
an enhancement request. Is it **REALLY** that hard to put together enough of the default
PCMCIA configuration so that it will find the few fully supported fingers and toes without
blowing chow for unsuspecting new users?
Sorry. I was working under the premise that we were going to treat
this as a request to begin (in RHEL3) supporting the 3c589_cs.o
driver (as opposed to as a config script bug). I'll switch the
severity back to "normal".
So, back in October, it was determined that this was in fact a bug, not an enhacement. Why did it get
switched back to enhancement?
Sorry about that.
Don, this is a request to Product Management to consider supporting
the drivers/net/pcmcia/3c589_cs.o module in the RHEL3 kernel. (It's
built but released via the associated kernel-*unsupported-* RPMs.)
No, it's not a request to support the 3c589. I merely used the 3c589 as an example. The problem is
/etc/pcmcia/config has entries for cards that point to modules (of which 3c589 is only ONE example)
which do not exist unless the kernel-unsupported package is installed. This results in the cardmanager
getting confused, since it beeps a success code to indicate it found the card in its database, then a fail
code to indicate it could not load the module.
Possible solutions include:
- punting those drivers from /etc/pcmcia/config, and making kernel-unsupported include a new
pcmcia config file, or append to the existing one via a %post scriptlet in the spec file.
- Installing kernel-unsupported by default when pcmcia is installed.
People here at MIT tell me that this problem has been "solved" by the deletion
of the kernel-unsupported RPM from RHEL 4, and associated with that deletion the
loss of a fair number of device drivers that used to be just hunky dory under
Could someone at the Red Hat side please follow up with maybe a pointer to a
white paper that makes explicit 3 categories of action taken on
1. Now supported.
2. Never gonna be supported.
3. In process of being supported.
Or is it the case that we should just make our own list consisting of:
"Anything you don't see in the modules now is never gonna be supported".
As unhappy as I would be to see that list of drivers, explicit closure here
would be a good thing.
Thanks in advance,
MIT Linux Platform Coordinator
Closing this issue out as worksforme in RHEL3 as long as you install the
kernel-unsupported rpm. Support for new platforms, chipsets, drivers, features
and/or packages in RHEL3 is over.
Close it if you must.
But recognize: RED HAT MISSED THE POINT!
An opportunity has been lost to help the community understand explicitly what is and is not supported
I guess we will have to leave it to competitors of Red Hat to give proper road maps for device driver
support, and to deal with shifting support levels by something other than sudden and undocumented
The bug is closed.
The problem has gone away.
So has the customer.
MIT Linux Platform Coordinator