Red Hat Bugzilla – Bug 106502
Base driver button not loaded
Last modified: 2007-11-30 17:06:58 EST
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):
Steps to Reproduce:
1. install RHEL 3 RC 2
2. lsmod | grep button
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:
# Check if it is already running
if [ ! -f /var/lock/subsys/$PROGNAME ]; then
echo -n $"Starting acpi daemon: "
modprobe button > /dev/null 2>&1
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$PROGNAME
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
# modprobe button
/lib/modules/2.4.21-4.EL/kernel/drivers/acpi/button.o: init_module: No such
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 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,
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,
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
[root@bahama root]# cat /proc/cmdline
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
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.