Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 439380

Summary: Both the bay.c and ibm_acpi drivers are functional at the same time
Product: Red Hat Enterprise Linux 5 Reporter: Prarit Bhargava <prarit>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED ERRATA QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 5.2CC: alan, dzickus, epollard, jarod, jgarzik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0314 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 15:13:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 439246    
Attachments:
Description Flags
RHEL5 patch to fix this issue
none
RHEL5 patch to fix this issue none

Description Prarit Bhargava 2008-03-28 12:50:11 UTC 
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
driver.

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
handler.

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.

P.
Comment 1 Prarit Bhargava 2008-03-28 12:51:51 UTC 
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.

P.
Comment 2 Prarit Bhargava 2008-03-28 14:46:58 UTC 
Created attachment 299477 [details]
RHEL5 patch to fix this issue
Comment 4 Prarit Bhargava 2008-03-28 15:06:33 UTC 
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?

Thanks,

P.
Comment 5 Jarod Wilson 2008-03-30 04:16:46 UTC 
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 20:34:37 UTC 
Works great on my T61.
Comment 9 Don Zickus 2008-04-09 18:44:43 UTC 
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 15:13:41 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2008-0314.html