Bug 113198 - yenta_socket.o module fails to load on a Micron Transport GX3 laptop
yenta_socket.o module fails to load on a Micron Transport GX3 laptop
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-09 12:16 EST by brian atkisson
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.6.9-31.EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-14 15:26:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description brian atkisson 2004-01-09 12:16:06 EST
Description of problem:
I get the following message when loading the pcmcia service:

Starting PCMCIA
services:/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
insmod
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
insmod yenta_socket failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: init_module:
Operation not permitted
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: insmod
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: insmod ds failed
 cardmgr.

/var/log/messages:
Jan  9 09:07:48 webmonkey kernel: PCI: No IRQ known for interrupt pin
A of device 02:03.0. Pleas
e try using pci=biosirq.
Jan  9 09:07:48 webmonkey kernel: PCI: No IRQ known for interrupt pin
A of device 02:03.1. Pleas
e try using pci=biosirq.
Jan  9 09:07:48 webmonkey kernel: ds: no socket drivers loaded!
Jan  9 09:07:48 webmonkey cardmgr[3736]: starting, version is 3.1.31
Jan  9 09:07:48 webmonkey cardmgr[3736]: no pcmcia driver in /proc/devices
Jan  9 09:07:48 webmonkey cardmgr[3736]: exiting
Jan  9 09:09:23 webmonkey kernel: PCI: No IRQ known for interrupt pin
A of device 02:03.0. Pleas
e try using pci=biosirq.
Jan  9 09:09:23 webmonkey kernel: PCI: No IRQ known for interrupt pin
A of device 02:03.1. Pleas
e try using pci=biosirq.
(END)



Version-Release number of selected component (if applicable):
Kernel-2.4.21-4.0.2.EL

How reproducible:
Every time

Steps to Reproduce:
1. start pcmcia service
2.
3.
  
Actual results:
service doesn't start

Expected results:
service to start

Additional info:
Comment 1 Arjan van de Ven 2004-01-09 12:29:09 EST
so did you try pci=biosirq as kernel option ?
(also it's possible that the bios in the laptop just isn't RHEL3
compatible)
Comment 2 brian atkisson 2004-01-09 12:46:54 EST
I tried that and it still doesn't work.  During boot up, I get:
Jan  9 09:44:26 webmonkey kernel: PCI: No IRQ known for interrupt pin
A of device 02:03.1.
Jan  9 09:44:26 webmonkey kernel: ds: no socket drivers loaded!

The pcmcia system worked fine under RH Linux 8 & 9.

[root@webmonkey root]# service pcmcia start
Starting PCMCIA
services:/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
insmod
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/yenta_socket.o:
insmod yenta_socket failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: init_module:
Operation not permitted
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: insmod
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o failed
/lib/modules/2.4.21-4.0.2.EL/kernel/drivers/pcmcia/ds.o: insmod ds failed
 cardmgr.


Thank you,
Brian
Comment 3 Jos Vos 2004-03-16 10:36:26 EST
Same here on ASUS M6800N notebook with kernel 2.4.21-9.0.1.EL.

Note that on the same notebook with RHL 9 and RHL 9 update kernel
2.4.20-28.9 the yenta_socket module *does* load, but then the system
immediately hangs forever as soon as a PCMCIA card is inserted.
Comment 4 Jos Vos 2004-03-16 11:02:02 EST
FWIW: on RHL 9 with the original RHL 9 kernel 2.4.20-8, the module
also does not load, so something in the -8 -> -28.9 transition has
changed the behaviour.
Comment 5 Jos Vos 2004-03-17 19:47:20 EST
I found the cause for this problem: it is due to the fact that ACPI
support is missing in the kernel and ACPI seems to play a role for
assigning IRQ's etc. in this case.  As soon as I compile a stock
kernel with ACPI support, loading yenta_socket and the rest of PCMCIA
works.

A stock kernel with no ACPI support does not work either.
Comment 6 Pete Zaitcev 2004-08-20 04:11:30 EDT
So, it's a Wontfix for RHEL3, right? If that thing is ACPI-only,
only RHEL4 can fix it, or am I mistaken?
Comment 7 Pete Zaitcev 2005-05-13 20:32:04 EDT
OK, I realize now that my comment #8 was stupid, because while RHEL 3 has
no ACPI, it's not relevant. The problem is the regression from RHL 9.
Unfortunately, the code is rather intricate, and I'm afraid to touch it.

Is there a chance to run RHEL 4 on that box, Brian?
Comment 8 brian atkisson 2005-05-14 14:23:49 EDT
Actually, RHEL4 is loaded on it now and it works fine. Thanks!
Comment 9 Ernie Petrides 2005-05-16 16:37:50 EDT
Pete, this is a RHEL3 bug.  So CLOSED/CURRENTRELEASE is an inappropriate
disposition.  I'm assuming you've decided that we're not going to fix this
in RHEL3, so I'm changing the disposition to WONTFIX.  If that's incorrect,
please reopen this bug and put it back into ASSIGNED state.  Thanks.  -ernie

Note You need to log in before you can comment on or make changes to this bug.