Bug 60020 - [NV42] Resuming Dell Precision M70 crashes
Summary: [NV42] Resuming Dell Precision M70 crashes
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-29 14:04 UTC by Roy Bixler
Modified: 2013-09-03 22:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg output - first bootup (51.89 KB, text/plain)
2013-01-29 14:04 UTC, Roy Bixler
no flags Details
"dmesg" output on rebooting after crash (52.00 KB, text/plain)
2013-01-29 14:05 UTC, Roy Bixler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roy Bixler 2013-01-29 14:04:44 UTC
Created attachment 73830 [details]
dmesg output - first bootup

I am running Debian wheezy and I have found that, with the nouveau driver loaded, suspend/resume results in a hung system.  Originally, I was using the proprietary NVidia driver and suspend/resume worked with it.  However, I switched to the Nouveau driver after I found that the system was unstable with the NVidia driver while watching videos.  I have made sure that all traces of the NVidia driver have been removed before reproducing the bug.  Except for this problem, the Nouveau driver works well -- no more crashes while watching videos.

I have also confirmed that suspend/resume works after I unload the nouveau driver.  I use the following commands:

echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod nouveau
pm-suspend

I have also done a test of suspend/resume with Nouveau loaded after activating pm_trace (i.e. echo 1 > /sys/power/pm_trace).  I attach a couple of "dmesg" outputs.  The most interesting lines from the second "dmesg" command from rebooting after the crash are the following:

[    0.726626] PM: Hibernation image not present or could not be loaded.
[    0.726635] registered taskstats version 1
[    0.727033]   Magic number: 0:56:725
[    0.727036]   hash matches drivers/base/power/main.c:571
[    0.727078] pci 0000:01:00.0: hash matches
[    0.727139] rtc_cmos 00:06: setting system clock to 1996-05-07 08:42:38 UTC (831458558)

Complete "dmesg" output attached.
Comment 1 Roy Bixler 2013-01-29 14:05:38 UTC
Created attachment 73831 [details]
"dmesg" output on rebooting after crash
Comment 2 Roy Bixler 2013-01-31 18:29:14 UTC
I just wanted to add some clarification about reproducing the bug.  I find that resume crashes if nouveau is loaded early as the framebuffer.  In that case, the trick of removing the nouveau driver after stopping the X server and before invoking pm-suspend has no effect (i.e. resume still results in a hung system).  What does make a difference is if I blacklist the nouveau driver so that the initial framebuffer console only uses standard VGA mode. When the X server starts, the module is loaded.  In this case, stopping the X server, removing the nouveau module and invoking pm-suspend results in a system that resumes more or less correctly.  In fact, on the first resume, the video is even restored.  On subsequent resumes, the video is not restored, but it is possible to get it back by starting the X server.  Going back to the console using Control-Alt-Fn also works.
Comment 3 Ilia Mirkin 2013-08-31 01:54:32 UTC
Can you confirm whether this still happens on the latest kernel (3.11-rc7)?
Comment 4 Roy Bixler 2013-09-03 21:56:52 UTC
Yes, it still happens with 3.11-rc7.
Comment 5 Ilia Mirkin 2013-09-03 22:05:05 UTC
How hung is the machine? Can you ssh into it? If so, would be great to see the logs on hang after resume. If not, can you try using netconsole/serial console? Does booting with nouveau.config=NvForcePost=1 help?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.