Bug 605429 - RHEL 5.5 hibernate broken on Dell PowerEdge 710
Summary: RHEL 5.5 hibernate broken on Dell PowerEdge 710
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 5.5
Hardware: x86_64 Linux
low
medium
Target Milestone: rc
: ---
Assignee: Lenny Szubowicz
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-17 22:07 UTC by Adam Radford
Modified: 2013-08-15 13:29 UTC (History)
4 users (show)

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


Attachments (Terms of Use)

Description Adam Radford 2010-06-17 22:07:21 UTC
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 13:55:57 UTC
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 13:29:58 UTC
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.