| Summary: | [NVC1] Uneven, jerky mouse movement, increasing CPU usage | ||
|---|---|---|---|
| Product: | xorg | Reporter: | James Moe <jimoe> |
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | fdsfgs |
| Version: | 7.7 (2012.06) | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| URL: | https://www.wikigenes.org/e/author/e/1450518.html | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
James Moe
2013-09-26 01:56:25 UTC
Does this still happen with the latest software, i.e. kernel 3.10, mesa 9.2, xf86-video-nouveau 1.0.9? (Kernel 3.11+ apparently has some issues for some NVC1 users, although feel free to try it.) Also, does this happen on an untainted kernel? (i.e. without virtualbox modules ever being loaded). Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) to tell where cpu time is going. Running perf record -g -p $gnome_shell_pid; perf report may be instructive. >Does this still happen with the latest software, i.e. kernel 3.10, > mesa 9.2, xf86-video-nouveau 1.0.9? > I do not know. My system is not that up to date. v3.7.10-1.16-desktop x86_64 > Also, does this happen on an untainted kernel? > Yes. > Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) ... > There is no "perf" executable in that directory. (In reply to comment #2) > >Does this still happen with the latest software, i.e. kernel 3.10, > > mesa 9.2, xf86-video-nouveau 1.0.9? > > > I do not know. My system is not that up to date. v3.7.10-1.16-desktop x86_64 Perhaps I was unclear. The implication was "update your system to these packages and see if it still happens". > > > Also, does this happen on an untainted kernel? > > > Yes. To be clear, loading the virtualbox modules taints the kernel. > > > Lastly, you can use 'perf' (in tools/perf in the linux-kernel sources) ... > > > There is no "perf" executable in that directory. Yes there is, if you build it. I'm sure there are plenty of wikis about it on the internet if you have trouble getting it to work. opensuse v13.1 linux v3.11.6-4-desktop x86_64 gnome 3.10.1 nouveau video driver 1.0.9 After upgrading to opensuse 13.1 the issue is longer evident. linux 3.11.10-7-desktop x86_64 gnome 3.10.2 Gallium 0.4 on NVC1 This issue has surfaced again in a slightly different form recently, within the last two weeks. The mouse data stream is interrupted and restarted at random intervals, in generally less than a minute. By "interrupted" I mean that the current mouse state is cleared; if button1 is down, it appears no longer down. And "restarted" means that the mouse state is restored immediately after it is interrupted but it appears as a new state: button1 is now down. It makes button1 click-drag a chancy process as the stream is sometimes interrupted/restarted quickly enough that it appears as a double-click followed by click-drag. Still using a kernel "tainted" by VirtualBox. This new aspect has no obvious affect on CPU usage. linux 3.11.10-7-desktop x86_64 gnome 3.10.2 Gallium 0.4 on NVC1 This issue has surfaced again in a slightly different form recently, within the last two weeks. The mouse data stream is interrupted and restarted at random intervals, in generally less than a minute. By "interrupted" I mean that the current mouse state is cleared; if button1 is down, it appears no longer down. And "restarted" means that the mouse state is restored immediately after it is interrupted but it appears as a new state: button1 is now down. It makes button1 click-drag a chancy process as the stream is sometimes interrupted/restarted quickly enough that it appears as a double-click followed by click-drag. Still using a kernel "tainted" by VirtualBox. This new aspect has no obvious affect on CPU usage. As always, step 1 is "try the latest". That means kernel 3.14.x, mesa 10.1. I'm specifically thinking about commit 7d3428cd4b2ad51af86fdbdf8284ca38fa95e601 in the kernel, which fixed some lag issues for a compton user. openSuse 13.2 linux 3.16.6-2-desktop x86_64 Gnome 3.14.1 Gallium 0.4 on NVC1 nVidia geforce gt 730 It's baaaack. The mouse movement is not jerky like the original report. The CPU usage increases quite quickly this time around. The usage value (from TOP) starts at about 2 - 3% for gnome-session, increases to about 15% in 24 hours. I have installed opensuse 13.2 on two other computers that have ATI graphics adapters; they do not exhibit this issue. If I do not boot every morning, the desktop is likely to freeze by the third day of uptime. Try the latest software and see if this happens there: Kernel:stable for a 3.18 kernel X11:XOrg for the X Stack + Mesa Report back anyway... opensuse 13.2 linux 3.16.7-21-desktop x86_64 nvidia GF108 [GeForce GT 730] gnome 3.14.5 xf86-video-nouveau 1.0.11 The increasing CPU usage is still an issue. Apparently I am the only person to have this problem. :-( I have been using Xfce; I switched back to Gnome for a while because I prefer it. It was disappointing that this has not been resolved. It seems to be a nvidia-related (or nouveau?) problem. None of the other linux systems exhibit the CPU usage; the other computers have ATI (built-in or addon) video controllers. openSUSE Leap 42.1 linux 4.1.12-1-default x86_64 Gnome 3.16.2 nouveau 2.4.65 nvidia gt 730 This issue has not been affected by any updates in the last two years. I just updated to updated openSUSE Leap 42.1 which has fairly recent versions of Gnome, etc. I am deeply disappointed that Gnome's CPU usage proceeded to climb from its initial usage of about 2% to 5% 12 hours later. It follows an identical pattern as originally reported. Have you tried using 'perf' to determine what's sucking up the CPU? How do I use perf to monitor Gnome's CPU usage? (In reply to James Moe from comment #13) > How do I use perf to monitor Gnome's CPU usage? Well, presumably it's not "gnome" using CPU, it's some specific process. So then you just do perf record -g -p pid (In reply to Ilia Mirkin from comment #14) > > How do I use perf to monitor Gnome's CPU usage? > > Well, presumably it's not "gnome" using CPU, it's some specific process. So > then you just do > > perf record -g -p pid > Would I use "perf top" to identify suspect processes? Since I do not know which process is the problem, I cannot provide a PID for the "-p" option. (In reply to James Moe from comment #15) > (In reply to Ilia Mirkin from comment #14) > > > How do I use perf to monitor Gnome's CPU usage? > > > > Well, presumably it's not "gnome" using CPU, it's some specific process. So > > then you just do > > > > perf record -g -p pid > > > Would I use "perf top" to identify suspect processes? Since I do not know > which process is the problem, I cannot provide a PID for the "-p" option. I've never used 'perf top' although it could perhaps be useful here. You could identify the process with 'top'. Using TOP the most likely suspect is "gnome-shell". How long should I collect data to get a good profile of its usage? I dunno... a minute or two should be fine. I'm assuming that it's consistently using 5-10% cpu? Created attachment 119744 [details]
perf data just after starting Gnome
perf ran for about 2 minutes to collect this data. It was run just after starting Gnome.
Unfortunately I can't decode that. It relies on the exact symbols on your machine... could you also run "perf report" and see if anything interesting pops up? Note that the first column with percents tells you how much time is spent in that function and all its descendents, while the second percentage tells you how much time is spent in *just* that function (but not the functions it calls). Created attachment 119745 [details]
perf data after Gnome had been running about 18 hours
perf data of gnome-shell after 18 hours of uptime. TOP shows that gnome-shell had increased its average CPU usage by a factor of three, from 2.5% to 7%.
Created attachment 119752 [details]
perf data - the initial screenfull of each data set
Great... that points to something in nouveau. But you need debug symbols to make it useful. Please get debug symbols, and then open up that top 38% node and see what's inside :) > Please get debug symbols
>
Which symbol set(s)? I already have the kernel-syms.
Sbcglobal Email Account Support ¶¶+1 855 856 6451¶¶☻ Sbcglobal.Net Email Problem ?1-855-856-6451? Sbcglobal Email Phone Support Number ··1-855-856-6451·· Sbcglobal Email Tech Support Number ```1-855-856-6451```` Sbcglobal.Net Email Support Number ©1-855-856-6451© Sbcglobal Customer Support @18558566451°°° Sbcglobal Email Customer Service Phone Number @**1-855-856-6451 Sbcglobal Email Toll Free Number(1-855)-856-6451 Sbcglobal Email Technical Contact Number**1-855-856-6451** Sbcglobal.Net Email Customer Support ~1-855-856-6451~ Sbcglobal.Net Email Phone Support ®®18558566451®® Sbcglobal Email Toll Free Number$$$ 18558566451 $$$ Sbcglobal Email Phone Support Number 1-855-856-6451 ***1.855.856.6451***sbcglobal.net email customer support @ @ 1-855-856-6451@ @ sbcglobal.net email phone supportSbcglobal Email Toll Free Number$$$ 18558566451 $$$ Sbcglobal Email Phone Support Number 1-855-856-6451 ***1.855.856.6451***sbcglobal.net email customer support USA @ @ 1-855-856-6451@ @ sbcglobal.net email phone supportSbcglobal Email Toll Free Number$$$ 18558566451 $$$ USA Sbcglobal Email Phone Support Number 1-855-856-6451 Was this ever resolved? (In reply to James Moe from comment #26) > Was this ever resolved? No, although someone else came in the other day to #nouveau complaining about high CPU usage when there's tons of output on an xterm. I've seen that behavior myself although I haven't investigated it. -- 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/59. |
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.