Bug 106502 - Base driver button not loaded
Summary: Base driver button not loaded
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-07 20:53 UTC by Tim Chambers
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-26 17:43:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:017 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 1 2004-01-13 05:00:00 UTC

Description Tim Chambers 2003-10-07 20:53:20 UTC
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):

How reproducible:

Steps to Reproduce:
1. install RHEL 3 RC 2
2. lsmod | grep button

Additional info:

Comment 1 Bill Nottingham 2003-10-07 22:56:43 UTC
Is acpid installed?

Comment 2 Tim Chambers 2003-10-07 23:16:53 UTC
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.

Comment 3 Bill Nottingham 2003-10-08 02:36:00 UTC
The button driver is loaded by the acpid initscript; the acpid package *should*
be part of any ia64 install.

Comment 4 Tim Chambers 2003-10-08 22:57:36 UTC
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.

Comment 5 Tim Chambers 2003-10-09 00:01:22 UTC
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.

Comment 6 Bill Nottingham 2003-10-09 00:26:26 UTC
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 -eq 0 ] && touch /var/lock/subsys/$PROGNAME
        return $RETVAL

So, the module should be loaded before acpid is started.

Comment 7 Tim Chambers 2003-10-10 02:17:29 UTC
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 
/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. 

Comment 8 Bill Nottingham 2003-10-10 02:46:09 UTC
Odd, over to kernel as to why the button module won't load.

Comment 9 Jeff Moyer 2003-10-15 15:23:02 UTC
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


Comment 10 Tim Chambers 2003-10-15 17:18:19 UTC
[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]#                                                            

Comment 11 Jeff Moyer 2003-10-15 18:40:34 UTC
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.

Comment 12 Tim Chambers 2003-10-15 19:49:24 UTC
/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

Comment 13 Jeff Moyer 2003-10-16 22:51:35 UTC
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.

Comment 14 Glen A. Foster 2003-12-26 17:43:03 UTC
We haven't seen this fail in a while -- assuming the patch worked.

Comment 15 Ernie Petrides 2004-12-03 01:59:55 UTC
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.


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