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):
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.
SHT->suspend() called, SHT->resume() called, power-off (or crash from
unexpected interrupt sometimes), power-on, SHT->resume() called.
SHT->suspend() called, power-off, power-on, SHT->resume() called.
This does not happen in newer 2.6.31 based FC12 or newer kernels.
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.
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.