Screens slow to repaint since 10.1 install

Sorry to be posting so many times today, but I've doing doing non-stop investigating of this problem and sometimes a new post seems more noticeable than an edit. Moderator, please correct me if I shouldn't do this.

What I have definitely determined so far is this:

Root can run an X-session with identical apps running (I even used the same .xinitrc file as normal user "jon") and get far better performance; scrolling a page like New York Times front page keeps photos intact instead of "shaking" dark areas up and down and generally acting out of sync. Refresh time is as good as under 9.2. I am writing this using IceWM, my normal user window manager, as root, in an X session (obviously). Far better performance.

So it can't very well be a driver, can it? It has to be something to do with those permissions that, changing them, cleared up the problem for the other user who was experiencing the same thing.

If only I could find out what permissions I need to change. The ones I've changed by guesswork so far, have remained changed between logins (both root and jon) but they also made not a speck of difference. I cannot discover any /dev entries that seem to reflect the ATI Rage 128 Ultra TF card (to give it its full name) that is in my system, and has worked beautifully ever since Mandrake 8.0. It works beautifully NOW, at this moment, because I am running as root.

But we all learned in kindergarten that the worst thing you can do in Linux is run for an extended period as root. I've always been very careful about that, and this is just an experiment and I will revert to being "jon" in a few minutes and put up with the relatively poor performance I'm not used to.

I hope this clarifies the state of my "research" so far. I've learned a few tricks over the two years I've used Linux exclusively, but I'm no guru and don't even understand a lot of the basic principles.

So I hope solving this won't be beyond me --with the usual splendid help from others here. Opjose in particular has helped me a lot with my difficult lm_sensors problem recently, and with this one. But others, from moderators down to newbies with two or three posts, have also been very helpful, and regardless of this problem's outcome, I owe them all a big debt of gratitude.

That, by the way, is why I'm a contributing member! Because this is a place where people help one another, instead of sniping (well, almost always).

OK, back to jerky refreshes and intermittent garbage on the screen! Before my luck runs out operating as root.

Hope to hear more good advice soon.

One way to find which driver is associated with which device(s), is to kill the display manager and try rmmod'ing the driver from memory.

Then check to see which entry may have disappeared from /dev

Some entries are created only when a kernel driver is loaded.

If you are utilizing an ATI display card with ATI drivers, then it may also be using dkms...

You may also want to list the contents of the RPM(s) to give you a clue as well.

e.g.

rpm -qlp NAMEOFRPM.rpm

Opjose, I listed the contents of /dev to a file and then killed the display manager and did

rmmod --force via-agp

Then I listed the contents of /dev to a second file.

Compared the two files and the only missing entry in the "after" file was agpgart.

So I changed permissions on that file to world writable and logged out and restarted X. I checked to see that it was still world writable and it was. But the display still acts the same.

Baffled as to why the same setup that works fine for root causes jerky repainting (you scroll and some of the colors bob around like Jell-O before they settle into place) and, probably, the "patchwork" and blackout intervals now and then. If it's permissions in question--and what else could it be? then what should I look for next?

I didn't know what names of rpm's to look for in the command you suggested. Not sure that they would signify anything to me anyway.

I did two things:

1. I found a file /uxr/X11R6/lib/modules/atidrivers/r128_drv.o

which I think may have been installed by the rpm "ati.2-4.3.20030708-1.mdk" ("experimental ATI drivers from gatos.sourceforge.net") that I installed last night.

I tried modprobe on r128_drv.o and got Fatal Error module not found. Then I copied the file to "r128" and tried modprobe again and it installed it as a module.

Upon rebooting it was still there. However, it seems to have no effect on operations.

--------------------------

2. The second, and more fruitful--or discouraging, depending on how you look at it--experiment was to temporarily create a new user, that I called jonrkc.
I put a very minimal .xinitrc in jonrkc's home directory, including xterm and IceWM, and had jonrkc start an X session.

Lo and behold, his display worked as well as root's does. It appears to be only user jon (my usual self...) that has the problem; therefore I suspect the fault must lie in my own files somewhere.

Any idea at all how to approach from this angle?

A new "virgin" user has a good display, like root. Jon, who's been accumulating files since January 2003, has a messed-up (though usable) display.

That, I think, is the most significant thing I've discovered so far. What do you think?

Ah, this is MUCH easier to solve.

As root

service dm stop

find /home/jonr -exec chown jonr {} \;

find /home/jonr -exec chgrp jonr {} \;

find /home/jonr -exec chmod 755 {} \;

Then

service dm start and try again.

It sounds like you've nailed the problem down.

Originally posted by opjose Ah, this is MUCH easier to solve. As root service dm stop find /home/jonr -exec chown jonr {} \; find /home/jonr -exec chgrp jonr {} \; find /home/jonr -exec chmod 755 {} \; Then service dm start and try again. It sounds like you've nailed the problem down.

I made the above into a script and ran it; can't see any difference as a result but it certainly didn't hurt anything...

I think part of the problem, frankly, was having "smooth scrolling" turned on in Firefox--where I was noticing the blurry images. It blurs them (during movement) for any user. When I created the new user "smooth" scrolling was turned off and I didn't think of that then. With it turned off, I'd say images repaint about as well, to my eye, for "jon" as for root or the other experimental user.

I have now disabled opaque window movement in IceWM and that helps save my eyes, too.

I know something's amiss in my files, because I can't use IceWM's "logout" function to logout anymore. If I'm doing an X session as root with IceWM, it works. Not for jon! This started happening a couple of days ago....

As for repainting a whole window when changing focus between windows, I'd say the speed's about the same for root and for normal user. Not as fast as in Mdk 9.2. I do think 10.1 is just all around slower.

The real test will be to see if the screen blacks out, gets patchy-worky, blacks out again, and then comes back to normal. It hasn't done that yet this morning but I'm only on my second cup of coffee.

A side note, probably unrelated: I got sick and tired of complaining messages from gconf about stale NFS locks and non-existent configuration files and on and on, during X session startups, and removed the gconf package from my system via the packaging utility. Everything works just fine without it! I just did this a few minutes ago.

Thanks for the time you've put into helping me with this! I still am not sure what the problem is, beyond Mdk 10.1 simply being inferior to 9.2--which is increasingly seeming to be the real issue.

Have to keep up with "progress," alas.

Still getting the blackout-patchwork episodes. Sigh.

I think I'll try running X as root for several hours today. I usually have my wits enough
about me that I can avoid wiping everything out. I'll put a sticky with "ROOT!" on the
base of the monitor bezel as a reminder...

Will report tonight or tomorrow if I got glitches running as root.

Thanks for your patience...

Sunday evening. I thought for a while getting rid of gconf might have solved the problem, but then had another glitch after that, and had one this morning, too.

So far all the glitches have been while running IceWM, my favorite window manager. It's been acting a little oddly lately; for example, I cannot log out of it via its own menu, but have to use ALT+CTL+Backspace. I uninstalled it completely and reinstalled two different versions of it, same result. I was unwilling to give up my hard-won configuration file or theme directory, however. Same result, with two different versions.

So now I'm running indefinitely with blackbox as window manager. So far, no glitches. I will continue with blackbox during the coming days to see if it looks as though the window manager is implicated. Maybe existing versions of IceWM have run into a problem with Manddrake 10.1 or the 2.6.x kernel?

I couldn't find anything specific about that with Google, though.

Am experiencing slow screen repainting from time to time with blackbox. I still get the feeling there's something not quite right with Mdk 10.1, at least the way I have it installed.

Opjose--the other night I went to the ATI website and found updated Linux drivers available for download. But in order to download the right driver, the user needs to run a test to determine what version of XFree86 is being dealt with. I downloaded the "check.sh" file and was unable to run it regardless of how I changed permissions and even console ownership (a thing I'd never ever messed with before) in order to do it. I kept getting this message:

ATI Technologies [in red!]
=====================================================================
Your possibly not running this script from the console
or maybe you simply dont have the console ownership.
Unable to determine XFree86 Version. Stopping now.

What do you think of that? (BTW, the misspellings are ATI's, not mine. I do enough of my
own without taking credit for others'.)

The ATI drivers were written for XFree86 not Xorg...

so if you are using Mandrake 10.1 the script will fail.

Originally posted by opjose The ATI drivers were written for XFree86 not Xorg... so if you are using Mandrake 10.1 the script will fail.

Ah, so...

I'm inclined to think the driver's OK (maybe not as good as it could be, but basically glitch-less) since root and
my imaginary user seemed to do so well yesterday.

Will just continue to tinker and stick to blackbox and see what happens, I guess. My best guess at present is
that IceWM (a software I cannot praise highly enough, so I'm certainly not knocking it) has run into trouble with
the latest Mandrake. Or the kernel used in it. Or both.

IceWM development is not exactly speedy, either....

I have an old onboard video card ATI Mach 64 (2D) and have the same problem with IceWM and 10.1. On my home computer with an ATI (Powercolor) 9600XT, IceWM and 10.1 there is no repainting problem. I've noticed there is no improvement when I log in as root on my machine. Just some additional info.

Originally posted by jagibbs I have an old onboard video card S3 Virge (2D) and have the same problem with IceWM and 10.1. On my home computer with an ATI (Powercolor) 9600XT, IceWM and 10.1 there is no repainting problem. I've noticed there is no improvement when I log in as root on my machine. Just some additional info.

Sounds like a solid clue to me! Thanks very much for the input.

Looks like I might need a more up-to-date video card to go with this updated OS and kernel. Woe is me, where does this stuff end?!

And from what I've read selecting a video card that's really good with Linux is not the easiest thing to do. I sure don't want to get into the Nvidia driver maze that I've read about so many places.

I can afford a modestly priced new card but knowing what to buy is going to be the hard part. I don't need anything dramatic--I never play games more demanding than Solitaire! I lost interest in online video recently when it became apparent it wasn't worth the time and frustration trying to get RealPlayer to work for the millionth time, and getting a new version of it every three weeks (or so it felt). I couldn't make heads nor tail of Mplayer. Etc. etc.

here's some real good info I just found

http://www.gentoo.org/doc/en/nvidia-...tyle=printable

If you scroll down to the bottom of the page in the troubleshooting section, I find an exact description of my particular problem. I do not have over 4GB of memory though. When checking my "/proc/mtrr" file I have one entry that is listed as uncachable. The problem is, my BIOS is a real crappy Dell BIOS (A10) and does not have any MTRR options... Anyone know of how I could change the MTRR setting in the BIOS to "discrete" instead of "continuous" if there's no option for it??? I also have the most current BIOS.

-- sorry about the previous edit. I realized I had the ATI Mach 64 onboard card instead of the S3 Virge.

Originally posted by jagibbs here's some real good info I just found http://www.gentoo.org/doc/en/nvidia-...tyle=printable If you scroll down to the bottom of the page in the troubleshooting section, I find an exact description of my particular problem. I do not have over 4GB of memory though. When checking my "/proc/mtrr" file I have one entry that is listed as uncachable.

Well, it turns out all my entries have "write-back" in them, so I guess I'm in the clear in that regard. Thanks for the link. It does remind me to go into BIOS in a few minutes and check the amount of video RAM assigned. I'm pretty sure I can increase it.

One possibility down, 125,576,342 left to troubleshoot!