Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 605429 - RHEL 5.5 hibernate broken on Dell PowerEdge 710
RHEL 5.5 hibernate broken on Dell PowerEdge 710
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.5
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Lenny Szubowicz
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-17 18:07 EDT by Adam Radford
Modified: 2013-08-15 09:29 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-15 09:29:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Radford 2010-06-17 18:07:21 EDT
Description of problem:

There is a bogus SHT->resume() entrypoint of scsi drivers being called 
when initiating a hibernate before the system powers off.  This causes some
devices to attempt to re-map their interrupt handlers, and some devices will
even throw interrupts, causing 'IRQ #106' and nobody cared error messages.

Version-Release number of selected component (if applicable):

2.6.18-194.el5
2.6.18-203.el5

How reproducible:

Easily reproducable every time.

Steps to Reproduce:
1.  Load a scsi driver with some printk's in suspend() and resume()
functions, then click 'hibernate' or echo "disk" > /sys/power/state. 
I have seen this with 3w-9xxx, megaraid_sas, etc.
2. Watch the bogus resume() called before power off.
3. Hope you don't crash.
  
Actual results:

SHT->suspend() called, SHT->resume() called, power-off (or crash from
unexpected interrupt sometimes), power-on, SHT->resume() called.

Expected results:

SHT->suspend() called, power-off, power-on, SHT->resume() called.

Additional info:

This does not happen in newer 2.6.31 based FC12 or newer kernels.
Comment 1 Matthew Garrett 2010-08-04 09:55:57 EDT
This is a somewhat inevitable consequence of the suspend infrastructure in the 5.x series. There's no separate freeze and suspend functions, so the suspend() function gets called to quiesce the driver for the state copy and then resume() will be called to power it up again in order to save the image to disk. Later kernel versions introduce infrastructure to split this into separate functionality which means we can handle it more cleanly. I don't think there's any reasonable way to retrofit this, but I'll leave the bug open and see if I can come up with something at some point.
Comment 2 Lenny Szubowicz 2013-08-15 09:29:58 EDT
Given how long this problem has gone unresolved, it's relatively low severity, and the lifecycle stage that RHEL 5 is currently in, the problem reported will not be fixed in RHEL 5.

                                   -Lenny.

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