Screens slow to repaint since 10.1 install
 

Since finally getting a Mandrake 10.1 OE install to succeed, I've noticed my screen is often much slower to repaint than before with 8.0, 8.2, 9.0, 9.1, or 9.2. Always before 10.1 repainting was virtually unnoticeable, it was so fast.

I still use IceWM window manager (though I experiment with others). My hardware hasn't changed except for replacing my Microtek 15-inch monitor with a Princeton 19-inch one. I'd expect repainting to be slower on the much larger display area, but not to the point that, as often, only the window decorations and titlebar are visible, and the contents of the windows take three or four seconds to appear. (Also I don't understand why the decorations and titlebars don't disappear, too.)

Another thing I've been experiencing, and I think it started before the new monitor was installed, is that occasionally there will be a spontaneous garbling of the entire screen,with a patchwork of colored pixels, sometimes but not always preceded by a brief blanking. Then it clears up by itself.

I noticed the same faulty "patchwork" effect many times since installing 10.1, on the screen while the system is powering down, as though the default blue background fails to get displayed right, and garbage replaces it. The text is always legible, however.

ATI Rage 128 video card; current display is at 1024x1208, 24-bit depth.

Any ideas?

I have the exact same issue but with CE. I did a bare minimum install of 10.1CE (Kernel, X, and IceWM only) and right away noticed the 1-4 second repaint times. Currently using 17" CRT monitor @ 75Hz 1024x768 @ 24bit on an onboard S3 Virge graphics card (8MB ram). Computer is PIII 550 with 384MB ram.

At home I'm running the same software setup BUT with KDE also installed in addition to IceWM. The KDE will repaint faster on that system then the IceWM on this system. That system is: PIII 800 with 1.5GB ram, 19" LCD DVI monitor on a ATI Radeon 9600XT with generic built in drivers.

I realize the second system is much better in terms of ram and video card, but the first should not be so slow in IceWM. I've tried 3-4 other distros in the past week (Debian Sarge, Libranet, Damn Small Linux) on the slower system and none had this issue. It's really frustrating though.

jonr:

Both things are probably related.

The patchwork you are referring to is X windows attempting to write to the display card's VRAM region (frame buffer) directly but having problems in the process.

Something is amiss, and I'd start by guessing that it's the AGP driver.

The ATI drivers may have their own AGP drivers which may be conflicting with detected motherboard chipset AGP drivers.

For instance my Intel Based motherboard causes the system to load the intel-agp driver while at the same time the Nvidia drivers try to load the NvAGP drivers under Mandrake 10.0.

You may want to check into this.

Well, I can tell you I'm relieved to know it's not (probably) my brand-new Princeton VL1916 monitor at fault!

Maybe somebody will come along to this thread with a helpful hint for us. Sure would be nice to have a manageable tweak that would restore the fast repaint times. With IceWM and KDE both (yes, I have used KDE) I used to get virtually instantaneous repainting---usually, in fact, unnoticeable to my eye. And I only have that pretty old Rage 128 card and a mere 560 MHz Pentiuim III processor.

I've also noticed that the problem seems intermittent. There seems no rhyme nor reason to it.

I'm beginning to suspect, though, that the painting of "garbage" on the screen, usually accompanied by a brief interval of black screen, has to do with some websites automatically refreshing their pages with no user intervention. I could test this by operating for several hours with my Internet connection turned off, though I kinda hate to...

Opjose, you posted as I was posting, so I missed this first time around.

Thanks for the tip--can you give me a clue or two as to how to start checking this possibility, or point me to a page that will help?

P. S. If it sheds any light (which I doubt!), my motherboard is an MSI Microstar MS6309, dating from ca. 1999.

Check the contents of /etc/modules.conf

Also look at the output of lsmod

lsmod will display all of the currently loaded kernel modules.

Look for anything which may read AGP or agpgart

Check the drivers documentation... for instance the Nvidia documentation packed with their downloadable driver documents all of the AGP issues for Nvidia cards and ways to work around them.

The Official release also has a specific ATI related "kernel" rpm that should also be installed for the same kernel you are using.

If you have an SMP kernel installed, consider trying the uniprocessor kernel.

Also make sure that ACPI is enabled if your system can handle it.

ACPI is used for both interrupt handling, DMA and memory mapping (actually APIC is too, but that's another matter...)

Remember you want the video drivers to only load ONE AGP support module... two will conflict...

Another great tool is to kill the DM and type

X --probeonly

so you can view what Xwindows says is up with your display.

BTW: Your MB uses the VIA chipset so you may be having a problem with kernel loaded VIA AGP drivers...

You may want to check the docs for them if you find that they are being loaded.

Muchas gracias, Opjose. I'll try these things as soon as I get back from the grocery store, or else tomorrow at the latest!

to add some more info I thought of...

My PIII 800 system that runs fine (does NOT have the problem) has VIA chipsets and I'm using an AGP card also. (ECS P6VXA)
I've come across threads mentioning slow performance on machines with ethernet cards. My PIII 800 machine that does not have a problem does NOT have ethernet while the one that does repaint slow is on an ethernet LAN. I have also gotten the random "blocky screen" when shutting down at times, but can't remember which system it was on.

OK, opjose

/etc/modules.conf is empty except for commented stuff put there by me in my titanic struggle with lm_sensors. It was completely empty upon installation.

But /etc/modprobe.preload contains these two modules to load at boot, time:

via-agp
evdev

I also found, via lsmod, that agpgart is loaded.

Should I remove agpgart, and if so, how is it done? Anyway, lsmod says "used by via-agp," so I reckon it might not be such a good idea to remove it...?

I could not get X --probeonly to work, and referring to man X, I don't find any "probeonly" option given, but the man pages are very complex and it's entirely possible I didn't see it in the right place. But it wouldn't work. Said invalid option or words to that effect, and gave me the enormous help screen every time.

As for the kernel add-in you mentioned, I'm afraid that's beyond my modest level of competence at this point. If it's an RPM I can get somewhere and just install like any other, I can do that.

I found "experimental" ATI drivers in my list of uninstalled RPM's on the distro disks. But am hesitant to install that RPM for fear of havoc.

Is any of this informative?

Me, too, I sometimes get that "blocky" ugly patchwork replacing the ugly default Mandrake blue at shutdown. And my one and only system does use an ethernet card--all these words just passed through it! ;)

You can force a temporary module unload by typing

rmmod via-agp
rmmod agpgart

You have to remove them in the right order though... if you have it backwards or one module is utilizing another you'll get a busy error.

Doing this DOES NOT hurt anything! It merely unloads the modules.

However if it's being autoloaded then your chipset is probably correctly detected.


Usually these modules are provided on a seperate RPM for your kernel... called ATI-kernel-blah-blah-blah.

X -probeonly

Should work as it's part of X windows...


Anyway, try this...

Run XFdrake as root and try reducing the bit depth to say 16bpp if you have it higher.

Then see if you are still having the same performance issues.

If not it may be that the amount of vram may have to be explicity stated in the XFConfig-4 config file as is often the case with some cards and drivers.



The LAN card SHOULD have nothing to do with this, but if you really want to check it out, merely move it to another slot or just remove it.

Of course you should NEVER EVER have a PCI card plugged into the slot immediately next to the AGP slot, but most people don't do this anyway...


The LAN card MAY be an issue if your system is somewhat starved for bus master capable PCI slots and you've inadvertently plugged a bus mastering card into a slot that does not support bus mastering.

This is far less problematic on newer machines though.

BTW: Here is something else I totally forgot about that has a great inpact upon performance...

http://www.linuxquestions.org/questi...hreadid=261922

Try logging in as root, if as root everything is much faster in the GUI then the above applies to you too.

The actual device name will change dependant upon your video card though.

Update and request
 

Opjose,

I did finally get "X -probeonly" to work, and saw some error messages among other things.

They are all contained in /var/log/Xorg.0.log, too, and I have posted this 500-some-line file at

www.jonrkc./xlog.txt

If you have time to look at that log, I'd be most grateful.

I tried disabling hardware acceleration and found that I'd much rather live with occasional screen glitches than no acceleration!

But I know there are numerous other "options" that can be applied--although for some reason
the XF86Config man page DOES NOT EXIST on my system, I found it on the Web and copied it and read almost
all of it. Much of it is way over my head. I understood quite a bit, and could make different alterations
easily enough if somebody pointed me the right way.

I also downloaded and installed the "experimental" Gatos drivers rpm for the via chipsets, but have no idea what
installing that rpm accomplished, if anything; performance is identical to before. Chances are there's a lot of extra
wrangling I need to do besides just the installation of the rpm.

Anyway, I hope you can look at the log file and especially the error messages and see what you think. It sounds to me
like failure to locate and load the lxga library could be something worth nothing...

Edit: That last sentence should refer to "libglx.a" and the lines in the log file about it are:

Lines 197-225 in the log file show module "glx" being loaded apparently successfully and then attempted to load again with wrong name-type (???) and unloaded. I can't tell if the original stayed in place or not, but lsmod | grep glx shows zero results.

OK, this seems to be IT. I logged in as root and entered an X session (default there is KDE, which should
be even pokier on the whole than what I've been experiencing with IceWM and normal user).

Result: MUCH smoother display scrolling, much speedier refreshing. It's more like what I was having with 9.2 Mdk.

So I will need to fix the problem this other poster was having, on my system. Gulp.

I have posted the directory listing for /dev at www.jonrkc.com/dev.txt

Any idea what device needs making writable? I made two or three world-writable on a guess but it didn't fix the problem for normal user login.