Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 Description of problem: I installed RC 2 on an Everest McKinley. HP's post-install tests detected this. Version-Release number of selected component (if applicable): kernel-2.4.21-4.EL How reproducible: Always Steps to Reproduce: 1. install RHEL 3 RC 2 2. lsmod | grep button Additional info:
Is acpid installed?
I checked a couple different installs. On an everything install, button is loaded, and acpid is not. On an install of only *devel packages, neither button nor acpid is installed.
The button driver is loaded by the acpid initscript; the acpid package *should* be part of any ia64 install.
I have seen *no* sign of acpid on *any* install, and I just found another install case today -- all *server packages -- that does *not* have button loaded.
My cow-orkers have enlightened me to the fact that acpid is a process, not a module. I see signs of it everywhere with ps(1). But the missing button module is still a bug.
Hm, looking at the acpid init script: start() { # Check if it is already running if [ ! -f /var/lock/subsys/$PROGNAME ]; then echo -n $"Starting acpi daemon: " modprobe button > /dev/null 2>&1 daemon /usr/sbin/$PROGNAME RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$PROGNAME echo fi return $RETVAL } So, the module should be loaded before acpid is started.
I see. But when I run modprobe button without redirecting to /dev/null I get this: # modprobe button /lib/modules/2.4.21-4.EL/kernel/drivers/acpi/button.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.EL/kernel/drivers/acpi/button.o: insmod /lib/modules/2.4.21-4.EL/kernel/drivers/acpi/button.o failed /lib/modules/2.4.21-4.EL/kernel/drivers/acpi/button.o: insmod button failed # dmesg | tail tulip2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip2: MII transceiver #0 config 1000 status 782d advertising 01e1. divert: allocating divert_blk for eth3 eth3: Digital DS21143 Tulip rev 65 at 0xc0000000f0101000, 00:30:6E:46:AA:26, IRQ 61. PCI: Found IRQ 62 for device e1:07.0 tulip3: EEPROM default media type Autosense. tulip3: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip3: MII transceiver #0 config 1000 status 782d advertising 01e1. divert: allocating divert_blk for eth4 eth4: Digital DS21143 Tulip rev 65 at 0xc0000000f0100000, 00:30:6E:46:AA:27, IRQ 62. #
Odd, over to kernel as to why the button module won't load.
ENODEV can be returned from the button module init routine if acpi is disabled. Could you please post your kernel command line parameters? You can get them via # cat /proc/cmdline Thanks.
[root@bahama root]# cat /proc/cmdline BOOT_IMAGE=scsi0:EFI\redhat\vmlinuz-2.4.21-4.EL console=ttyS0,115200n8 root=LABEL=/ ro [root@bahama root]#
I cannot reproduce this on our local McKinley system. Note that the same kernel is installed no matter which packages are selected during the install procedure. Have you tried rebooting the system a number of times to see if you get varying results? In other words, take an installation that seems to load the button driver, and reboot several times, noting whether the driver was loaded. This would at least allow us to isolate one variable in the equation. One other thing to check on the failing system is whether /proc/acpi exists.
/proc/acpi does exist. Thx for the clarification about the kernel not varying based on pkgs. I didn't think it did, but the package selections were the only correlation I noticed. Now I see another correlation. I can reproduce this on single-processor Everests (both McKinley and Madison). I checked four other Everests (both McKinley and Madison) with more than one processor, and all have button. I did try three times rebooting a machine with button, and it didn't make a difference.
It seems that acpi_disabled was declared __initdata, which is a hint that it can be freed after initialization stages of the kernel. I've submitted a patch which fixes this, as it is used during runtime.
We haven't seen this fail in a while -- assuming the patch worked.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-017.html