|Summary:||Host panic on the 2ndsuspend-RAM|
|Product:||Red Hat Enterprise Linux 5||Reporter:||jiyang <jiyang>|
|Component:||hal||Assignee:||Richard Hughes <rhughes>|
|Status:||CLOSED WONTFIX||QA Contact:||desktop-bugs <desktop-bugs>|
|Version:||5.5||CC:||jiyang, lihuang, ndai|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-06-02 13:22:10 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description jiyang 2009-08-14 02:43:18 UTC
Description of problem: when suspend by "echo mem > /sys/power/state" on host RHEL5U4 w/out ksm two times,the first time will work well,but the second host will panic. Version-Release number of selected component (if applicable): I find the issue on kernel:2.6.18-162.el5,cpu:intel,kvm-83-105.el5 and reproduce it on kernel:2.6.18-157.el5,cpu:intel,kvm-83-88.el5 How reproducible: 100% Steps to Reproduce: 1.run echo mem > /sys/power/state 2.press the power button to resume host to resume host 3.run echo mem > /sys/power/state 2-3 times Actual results: the first time host can suspend and resume successful,but when the second time,the host panic,the power light is on,but can not connection by ssh and can not do any other operations. Expected results: every time,host can suspend successfully,and press the power button to resume successfully Additional info:
Comment 1 jiyang 2009-08-14 02:45:04 UTC
Created attachment 357384 [details] after the first suspend and resume,the dmesg
Comment 2 jiyang 2009-08-14 02:46:36 UTC
Created attachment 357385 [details] after the second suspend,host panic,then restart,the dmesg
Comment 3 jiyang 2009-08-14 06:46:20 UTC
sorry,the above "Description of problem" is not clear,the issue has nothing with ksm and kvm.Redescription follow as: when suspend by "echo mem > /sys/power/state" on host two times,the first time will work well,but the second,host will panic.I can not collect the message by serial console,it will dispaly messy code when resume and when the second suspend. Version-Release number of selected component (if applicable): I find the issue on RHEL5U4,kernel:2.6.18-162.el5,cpu:intel and reproduce it on RHEL5U3,kernel:2.6.18-128.el5,cpu:intel How reproducible: 100% Steps to Reproduce: 1.run echo mem > /sys/power/state 2.press the power button to resume host to resume host 3.run echo mem > /sys/power/state 2-3 times Actual results: the first time host can suspend and resume successful,but when the second time,the host panic,the power light is on,but can not connection by ssh and can not do any other operations. Expected results: every time,host can suspend successfully,and press the power button to resume successfully
Comment 4 Matthew Garrett 2009-08-18 18:30:59 UTC
What hardware is this?
Comment 8 Matthew Garrett 2009-08-19 10:18:09 UTC
Ok. Does the panic generate any readable output?
Comment 10 Matthew Garrett 2009-08-19 10:47:30 UTC
Does it work correctly running Fedora 11?
Comment 11 Mark Xie 2009-08-24 11:12:43 UTC
Here is anther phenomenon(Comment here as I'm not sure if it's a new bug or not): it can restore OK if suspend to ram by "echo mem >/sys/power/state" at a pseudo terminal in the GUI environment, but it will failed to restore if do the same suspend from a real terminal such as tty1, tty2, etc. The screen keeps black, the keyboard will out of response, nothing can do to weak up the system.... Steps: 1, boot the RHEL5.4 2, make sure ksm.ko is not loaded (As ksm.ko has some issue itself, unload it to make sure this issue is not related to ksm) 3, do "init 3" 4, Login to tty1 as root, do "echo mem >/sys/power/state" 5, Press the power button of the machine, the black screen will show out. version: RHEL 5.4 20090819.0 Server X86_64 (Infect, this issue happens on all the rhel 5.4 x86_64) # uname -a Linux dhcp-66-70-3.nay.redhat.com 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux additional info: #cat /proc/cpuinfo .... processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 cpu MHz : 2826.229 cache size : 6144 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 cx16 xtpr lahf_lm bogomips : 5652.39 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Comment 12 Mark Xie 2009-08-24 11:15:11 UTC
Should I open a new bug? or comment it here will be OK?
Comment 13 Matthew Garrett 2009-08-24 11:18:39 UTC
Mark, that's unrelated. It's also unlikely that suspending from the console will be supported in RHEL 5.
Comment 14 Mark Xie 2009-08-24 12:42:20 UTC
OK, I see, thanks a lot, Matthew.
Comment 15 Matthew Garrett 2009-09-28 22:27:16 UTC
Still waiting to know if this works on F11.
Comment 16 lihuang 2009-09-29 05:45:41 UTC
On the same box in comment #5. reproduced the original issue with F11 x86_64. (steps in comment #0 ) Also tested the scenario on my Lenovo X200 laptop. F11 - works well RHEL5u4 - Can resume from the 2nd suspend. But screen is very very dark ... Thanks Lijun Huang
Comment 17 Matthew Garrett 2009-11-03 20:11:01 UTC
Does this work if X is not running?
Comment 19 jiyang 2009-11-05 06:04:29 UTC
Created attachment 367577 [details] the dmesg after resume,when the screen is dark
Comment 20 Matthew Garrett 2009-11-05 14:43:43 UTC
Not a kernel issue. The system needs appropriate graphics quirks in hal.
Comment 24 RHEL Product and Program Management 2014-03-07 13:53:40 UTC
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Comment 25 RHEL Product and Program Management 2014-06-02 13:22:10 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).