This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
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
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
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:
Environment:
Last Closed: 2008-05-21 11:13:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

P.
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?

Thanks,

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

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.