Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 528308 - Kernel panic on rebooting after implement suspend and resume [NEEDINFO]
Summary: Kernel panic on rebooting after implement suspend and resume
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: hal
Version: 5.4.z
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-11 06:17 UTC by lihuang
Modified: 2014-06-03 12:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-03 12:48:32 UTC
Target Upstream Version:
pm-rhel: needinfo? (lihuang)


Attachments (Terms of Use)
Call Trace (15.59 KB, text/plain)
2009-10-11 06:17 UTC, lihuang
no flags Details
sosreport (1005.22 KB, application/x-bzip2)
2009-10-11 06:20 UTC, lihuang
no flags Details
lshal (111.15 KB, text/plain)
2009-10-16 06:12 UTC, lihuang
no flags Details
log (11.79 KB, text/plain)
2009-10-22 07:52 UTC, lihuang
no flags Details

Description lihuang 2009-10-11 06:17:41 UTC
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:

Comment 1 lihuang 2009-10-11 06:20:16 UTC
Created attachment 364361 [details]
sosreport

Attached please find the sosreport. Needinfo me if additional information is need.

Comment 2 Prarit Bhargava 2009-10-14 13:01:59 UTC
lihuang, any chance you could hook up a serial console and capture the panic?

P.

Comment 3 Prarit Bhargava 2009-10-14 13:15:50 UTC
(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.

Comment 4 Matthew Garrett 2009-10-14 13:28:47 UTC
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?

Comment 5 lihuang 2009-10-16 06:12:59 UTC
Created attachment 365019 [details]
lshal

Comment 6 Matthew Garrett 2009-10-16 08:58:58 UTC
Can you test suspend from the text console?

Comment 7 lihuang 2009-10-16 09:13:18 UTC
(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

Comment 8 Matthew Garrett 2009-10-16 09:23:21 UTC
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?

Comment 9 lihuang 2009-10-16 13:11:28 UTC
(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

Comment 10 Matthew Garrett 2009-10-16 13:23:08 UTC
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?

Comment 11 lihuang 2009-10-18 10:01:58 UTC
      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

Comment 12 Matthew Garrett 2009-10-22 05:59:18 UTC
Does the machine then reboot correctly with any of these options?

Comment 13 lihuang 2009-10-22 07:52:20 UTC
Created attachment 365662 [details]
log

Attached please find the log.

Comment 14 Matthew Garrett 2009-10-22 08:41:27 UTC
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.

Comment 17 RHEL Program Management 2014-03-07 12:51:37 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 18 RHEL Program Management 2014-06-03 12:48:32 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).


Note You need to log in before you can comment on or make changes to this bug.