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