| Summary: | [NV42] Resuming Dell Precision M70 crashes | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Roy Bixler <rcbixler> | ||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | git | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 73831 [details]
"dmesg" output on rebooting after crash
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. Can you confirm whether this still happens on the latest kernel (3.11-rc7)? Yes, it still happens with 3.11-rc7. 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? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/34. |
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.
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.