Bug 439380 - Both the bay.c and ibm_acpi drivers are functional at the same time
Summary: Both the bay.c and ibm_acpi drivers are functional at the same time
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Prarit Bhargava
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks: 439246
TreeView+ depends on / blocked
 
Reported: 2008-03-28 12:50 UTC by Prarit Bhargava
Modified: 2008-05-21 15:13 UTC (History)
5 users (show)

Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 15:13:41 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0314 0 normal SHIPPED_LIVE Updated kernel packages for Red Hat Enterprise Linux 5.2 2008-05-20 18:43:34 UTC

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



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