Created attachment 364360 [details] Call Trace Description of problem: after issue reboot . the machine (OPTIPLEX 760) got kernel panic immediately. Version-Release number of selected component (if applicable): kernel-2.6.18-164.2.1.el5 How reproducible: 100% ( OPTIPLEX 760 ) Steps to Reproduce: 1. Suspend the test machine ( System -> Suspend ) 2. Resume by pressing the power button 3. Reboot Actual results: Attached please find the Call Trace Expected results: Additional info:
Created attachment 364361 [details] sosreport Attached please find the sosreport. Needinfo me if additional information is need.
lihuang, any chance you could hook up a serial console and capture the panic? P.
(In reply to comment #2) > lihuang, any chance you could hook up a serial console and capture the panic? > > P. Duh. I should have seen the attachment on this BZ ;) P.
Looks like memory corruption. Does this happen if suspend is run from the text console, not X? What does lshal look like for this machine?
Created attachment 365019 [details] lshal
Can you test suspend from the text console?
(In reply to comment #6) > Can you test suspend from the text console? after resume from suspend. the screen keep in dark,but I can use login by ssh. after implement reboot from the ssh session. host panic again. Thanks Lijun Huang
So you suspend, resume, ssh in, type reboot and then the host panics? If you don't reboot, can you run commands from the ssh session?
(In reply to comment #8) > So you suspend, resume, ssh in, type reboot and then the host panics? If you > don't reboot, can you run commands from the ssh session? Yes. the machine works well if not reboot
I suspect that this is an issue triggered by X failing when the graphics are not set up correctly. Can you try suspending from X as root with the following command: pm-suspend --quirk-vbe-post and see if it resumes without a panic? If not, can you test some of the other --quirk options that are shown by pm-suspend --help?
options suspend resume --quirk-dpms-on OK OK --quirk-dpms-suspend OK OK --quirk-radeon-off OK OK --quirk-s3-bios OK X (hang) --quirk-s3-mode OK X (rebooted) --quirk-vbe-post OK OK --quirk-vbemode-restore OK X (hang) --quirk-vbestate-restore OK X (hang) --quirk-vga-mode3 OK OK
Does the machine then reboot correctly with any of these options?
Created attachment 365662 [details] log Attached please find the log.
Ok. hal needs to provide an fdi file that enables quirk-vbe-post on this platform. If this is not done, the X server will be confused and write to inappropriate areas of memory - this results in an oops on resume if X is in the foreground, or an oops on reboot when gdm is shut down.
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.
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).
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days