Bug 439380 - Both the bay.c and ibm_acpi drivers are functional at the same time
Both the bay.c and ibm_acpi drivers are functional at the same time
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Prarit Bhargava
Martin Jenner
Depends On:
Blocks: 439246
  Show dependency treegraph
Reported: 2008-03-28 08:50 EDT by Prarit Bhargava
Modified: 2008-05-21 11:13 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:13:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
RHEL5 patch to fix this issue (2.74 KB, patch)
2008-03-28 10:46 EDT, Prarit Bhargava
no flags Details | Diff
RHEL5 patch to fix this issue (2.88 KB, patch)
2008-03-28 11:06 EDT, Prarit Bhargava
no flags Details | Diff

  None (edit)
Description Prarit Bhargava 2008-03-28 08:50:11 EDT
After examining the code to figure out the extent of the WAR in BZ 439246, it
looks like I found a new bug :(

drivers/acpi/bay.c is built in and registers a notifier for bay events,
bay_events().  This handler is *very* simple and printks an event message and 
indicates that a status change has occurred through a uevent file.  AFAICT,
there is no way to determine what the status change actually was with the bay.c

drivers/acpi/ibm_acpi is loaded and creates sysfs files (which are the files we
are currently using to manually interact with the device) and then attempts to
register its own handler -- this fails because bay.c has already registered a

This results in the odd situation that RHEL5 is actually using TWO drivers for
one device.

ibm_acpi.c is not upstream so upstream doesn't have this situation.

Thinking of doing the following:

a) in bay.c introducing a blacklist file so that additional vendor drivers can
override the generic bay.c driver.
b) introducing a command line option so that other unknown systems can override.

Comment 1 Prarit Bhargava 2008-03-28 08:51:51 EDT
epollard -- you should review the ibm_acpi drivers behavior to make sure that it
is doing the right thing for all devices in the driver.

Comment 2 Prarit Bhargava 2008-03-28 10:46:58 EDT
Created attachment 299477 [details]
RHEL5 patch to fix this issue
Comment 4 Prarit Bhargava 2008-03-28 11:06:33 EDT
Created attachment 299479 [details]
RHEL5 patch to fix this issue

Jarod provided me with a dmidecode dump from his T61.

jwilson -- could you please test ASAP?


Comment 5 Jarod Wilson 2008-03-30 00:16:46 EDT
I've got a RHEL5 install, including a kernel with this patch, up and running on
a spare partition on my T61 now, will get this tested out properly Monday morning.
Comment 6 Jarod Wilson 2008-04-01 16:34:37 EDT
Works great on my T61.
Comment 9 Don Zickus 2008-04-09 14:44:43 EDT
in kernel-2.6.18-89.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 12 errata-xmlrpc 2008-05-21 11:13:41 EDT
An advisory 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.