Bug 34491 - Resuming from Suspend to RAM causes poor 2D performance
Summary: Resuming from Suspend to RAM causes poor 2D performance
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-19 15:30 UTC by Richard
Modified: 2013-08-18 18:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg kernel log following a boot, suspend to RAM and then resume (66.89 KB, text/plain)
2011-02-19 15:30 UTC, Richard
no flags Details
Xorg log from a different boot (28.29 KB, text/plain)
2011-02-19 16:43 UTC, Richard
no flags Details

Description Richard 2011-02-19 15:30:19 UTC
Created attachment 43562 [details]
dmesg kernel log following a boot, suspend to RAM and then resume

I am using KDE 4.6.0 on Gentoo Linux's testing tree with the Linux 2.6.38-rc5 kernel. Resuming from a suspend to RAM kills 2D performance. This issue also occurs with Linux 2.6.38-rc4.

I discovered this while I was testing a power management patch for Martin Peres. His patch provided a proc interface for changing my card's performance level. If I set the performance level and suspend to RAM, the system will not resume at all and I cannot even ssh into it. Without setting a performance level with his patch applied, the system will resume from a suspend to RAM, but 2D performance is awful. Resuming from a suspend to RAM also results in poor 2D performance even if his patch is not applied.

There are some messages in the dmesg kernel log that seem to describe what is going wrong, but I do not understand them. I have attached the output.
Comment 1 Richard 2011-02-19 16:43:45 UTC
Created attachment 43566 [details]
Xorg log from a different boot

mupuf_laptop asked me to include the Xorg server log. I triggered this condition again to generate the log.

Unfortunately, dmesg is not displaying any of the things it exhibited during the previous boot, despite the 2D performance being poor like the previous time.

I couldn't get this issue to manifest itself consistently with the 2.6.38-rc4 kernel earlier in the week. Sometimes it would be slow and at others it would simply display graphical corruption. Now that I have some time, it seems that the 2.6.38-rc5 kernel is also being inconsistent, although I have not seen any graphical corruption yet.
Comment 2 Ilia Mirkin 2013-08-18 18:09:09 UTC
It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team


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.