[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Patterned slow-down over the entire GNOME desktop

Then I have to say i can't confirm what you see. I'm not seeing
appreciable extended periods of high cpu utilization for my rawhide
synced gnome desktop running the nv driver and selinux permissive mode
with my normal application usage patterns.  Or even when I try to
produce it by randomly starting a variety of applications.  You might
be experiencing something triggered by a specific application that I'm
not running. You never told us which process was actually cpu spiking
in your posts so far.
Gnumeric, gnome-terminal, firefox, rhythmbox, applets.
 Is it the end-user applications, gnome
infrastructure, X.. the kernel related processes?  Are thereother
interesting configurations in play mounted network filesystems? raid?
I have a mounted samba share, but I doubt that has anything to do with it.
There's no raid.

There are certaintly funtastic issues with gnome at
the moment (like the multiple gnome-terminal problem) on my system,
Which problem is that? I have one where switching to consoles 1-6,8,9
makes the screen go pink with a garbled rectangle in one corner, instead
of showing the login prompt - it's really fun, especially when X freezes
on console 7. (and yes, this was with the nv driver).

I'm not seeing this behavior at all I can switch consoles all the live
long day on my rawhide box.  I was refering to the problem with
gnome-terminal hanging which has been reported in either test-list and
devel-list by several people in the last week or so... its a problem
specific to gnome-terminal and has nothing to do with problems are are
suggesting here which you are suggesting are rather application
Well, I haven't had any problems with the gnome-terminal hanging :)
Really, most bugs are dependent on configuration issues to detect.
I happen to have every Fedora package installed (with 90% of the services disabled, of course), so sometimes I get to see fun bugs that nobody else ever does. For example, did you know that libsafe (used to be in extras) will break prelink for every app? I found that out recently, and filed a bug, but now I see libsafe is gone from the repo (I did prelink successfully after that, so that's not the issue here).

Ivan"looking forward to when arjan/jeff stop blaming nvidia for every
problem on the fedora desktop, and hell freezes over" G.

Shrug, hopefully you can find someone who can confirm the problems you
are experiencing.  I don't see this going very far towards resolution
without more specifics or some cross-referencing multiple affected
Right. I wouldn't normally consider slowness surprising, but it's the pattern that looks weird to me. My thinking is that some kind of core gnome library is doing something wrong.
P.S. The nv driver makes my LCD say:

All of these tests have used the LCD moniter?  I have a crt on my
system.  Do you need to enable the FlatPanel option for the nv driver?
I have no idea - I don't normally mess with xorg.conf at all (or use the nv driver). I would expect kudzu (or something) to do more work to detect what kind of monitor I have - at least get the frequency/resolutions right.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]