Bug 496564 - lpfc driver has no suspend/resume support
Summary: lpfc driver has no suspend/resume support
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Lenny Szubowicz
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-20 05:37 UTC by Zhang Kexin
Modified: 2013-08-15 12:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-15 12:35:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
kernel panic info (3.23 KB, application/octet-stream)
2009-04-20 05:37 UTC, Zhang Kexin
no flags Details
cpuinfo of the kernel panic machine gs-bl460cg1-01.rhts.bos.redhat.com (4.98 KB, application/octet-stream)
2009-04-20 05:42 UTC, Zhang Kexin
no flags Details

Description Zhang Kexin 2009-04-20 05:37:48 UTC
Created attachment 340288 [details]
kernel panic info

Description of problem:
with kernel RHEL5.4-Server-20090412.nightly, on gs-bl460cg1-01.rhts.bos.redhat.com, when do "echo disk > /sys/power/state", kernel panic.

also tried 2.6.18-128 kernel, same things happens.

Version-Release number of selected component (if applicable):
distro is RHEL5.4-Server-20090412.nightly, kernel version is 2.6.18-138.


How reproducible:
always

Steps to Reproduce:
1. [root@dell-pe2950-01 ~]# cat /sys/power/state 
disk 

2. echo disk > /sys/power/state
3. 
  
Actual results:
kernel panic

Expected results:


Additional info:

Comment 1 Zhang Kexin 2009-04-20 05:42:20 UTC
Created attachment 340289 [details]
cpuinfo of the kernel panic machine gs-bl460cg1-01.rhts.bos.redhat.com

Comment 2 Zhang Kexin 2009-04-20 06:50:41 UTC
tried on another rhts machine dell-pe2950-01.rhts.bos.redhat.com, panic did not happen with same operation.

on the paniced machine, there is a modules named lpfc
[root@gs-bl460cg1-01 ~]# lsmod | grep lpfc
lpfc                  352909  0 
scsi_transport_fc      73801  1 lpfc
scsi_mod              196569  9 ib_iser,iscsi_tcp,libiscsi,scsi_transport_iscsi,scsi_dh,lpfc,scsi_transport_fc,cciss,sd_mod

on the non-paniced machine, there is no such module.

Comment 3 Matthew Garrett 2009-04-22 14:56:16 UTC
Can you test with the kernel from https://brewweb.devel.redhat.com/taskinfo?taskID=1772029 when it finishes building?

Comment 4 Zhang Kexin 2009-04-23 02:34:33 UTC
tested the x86_64 kernel, panic does not happen, but suspend seems not work, following is printed out then hang there:

gs-bl460cg1-01.rhts.bos.redhat.com login: Disabling non-boot CPUs ...
CPU 1 is now offline
CPU1 is down
CPU 2 is now offline
CPU2 is down
CPU 3 is now offline
CPU3 is down
CPU 4 is now offline
CPU4 is down
CPU 5 is now offline
CPU5 is down
Breaking affinity for irq 4
Breaking affinity for irq 98
Breaking affinity for irq 106
CPU 6 is now offline
CPU6 is down
CPU 7 is now offline
CPU7 is down
Stopping tasks: ==================================================================================<3>lpfc 0000:10:00.0: 0:0433 Wakeup on signal: rc=xfffffe00
lpfc 0000:10:00.1: 1:0433 Wakeup on signal: rc=xfffffe00
=========|
Shrinking memory... done (66686 pages freed)

while for a successful suspend, info should like this:

CPU 3 is now offline
CPU3 is down
CPU 4 is now offline
CPU4 is down
Breaking affinity for irq 3
Breaking affinity for irq 14
Breaking affinity for irq 66
Breaking affinity for irq 82
Breaking affinity for irq 90
CPU 5 is now offline
CPU5 is down
CPU 6 is now offline
CPU6 is down
CPU 7 is now offline
CPU7 is down
Stopping tasks: ========================================================================================|
Shrinking memory... done (0 pages freed)
Saving image data pages (107864 pages) ...  52%<6>bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
done
Wrote 431456 kbytes in 5.57 seconds (77.46 MB/s)
S|
Power down.
acpi_power_off called

further more, resume does not work out.

Comment 8 Lenny Szubowicz 2013-08-15 12:35:12 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.