Bug 113198

Summary: yenta_socket.o module fails to load on a Micron Transport GX3 laptop
Product: Red Hat Enterprise Linux 3 Reporter: brian atkisson <brian>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jos, petrides, riel
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 2.6.9-31.EL Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-14 19:26:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description brian atkisson 2004-01-09 17:16:06 UTC
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 17:29:09 UTC
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 17:46:54 UTC
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 15:36:26 UTC
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 16:02:02 UTC
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-18 00:47:20 UTC
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 08:11:30 UTC
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-14 00:32:04 UTC
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 18:23:49 UTC
Actually, RHEL4 is loaded on it now and it works fine. Thanks!

Comment 9 Ernie Petrides 2005-05-16 20:37:50 UTC
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