You are not logged in.
I tried 2.7.0 from testing, clean xorg.conf etc. KWin's performance still sucks (e.g. fading effects are very rugged), and now I can't even run glxgears and etracer anymore, they segfault on me:
[ 1841.719982] glxgears[26154]: segfault at 1300 ip b7a5068d sp bff9aed0 error 4 in libdricore.so[b7973000+1de000]
I tried rebuilding mesa and xf86-video-intel from AUR, but to no avail. Anybody experiencing the same problems?
It's been noted before that the DRI permissions thing is a non-issue, but I believe it would be more accurate to say that it's *typically* a non-issue and isn't something that's been 100%-resolved upstream.
Anyway, you may want to try a "sudo chmod 666 /dev/dri/card0" and see if that helps.
Again, it's something that should be unnecessary, but I clearly remember having to do this in some cases.
Offline
@Ronin-Sage: spot on, the DRI permissions were causing problems. I added the appropriate entry to my xorg.conf and it works.
FWIW, in comparison to 2.6.3, glxgears performance has dropped from ~200 to 50fps but etracer has improved from ~1 to ~5 fps (using KMS).
Offline
I recommend trying the intel driver from GIT. So far, all stability issues I had with the driver in testing are gone. Performance seems to be at acceptable level as well. 480'ish at glxgears, with UXA and KMS.
Last edited by Tera (2009-05-10 12:32:53)
Offline
I haven't noticed any performance difference with 2.7.0 from testing.
I have noticed however that my display seems to run at 24bit color again, which is quite nice! This is with the newest 2.7.0-3.
Offline
@Ronin-Sage I experienced the exact samen issue. Tried the drivers in extra, EXA worked fine but UXA all segfaults. Compiled the git driver from AUR same issue. When changing the permissions every thing worked fine.
Offline
I'll say that the combo has been a hilarious amount of trouble for me. Things are all sorts of broken over here with X blowing up sometimes, Compiz hardly works at all, a slew of other problems. It's feeling like my machine is on eggshells and things might go totally unusable any day now, as it seems with every single xorg/intel update things have become less and less usable.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
SomeGuyDude,
Why not switch to the xf86-video-intel-legacy driver for the time being?
Offline
Doesn't seem to fix anything. It's weird. Things are SMOOTH, but I get lockups and freezes. For example, I literally cannot kill X or reload the WM under Compiz. Trying to do so makes the screen go black save the unresponsive cursor. Happens with the legacy or without.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
hmm then it sounds like you have an issue with something unrelated to the driver. Have you tried pairing down your xorg.conf? or move it to a backup file and try X with no xorg.conf. If that fails then have X auto create an xorg.conf for you.
Which chipset do you have?
Offline
Intel 945GM set, the actual thing listed is a 950-something.
I've tried with and without an xorg.conf in the past day, toying with forcing UXA or not. Still no change.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
Intel 945GM set, the actual thing listed is a 950-something.
I've tried with and without an xorg.conf in the past day, toying with forcing UXA or not. Still no change.
Same situation here. I just can hope that the things improve with the kernel 2.6.30 and the 2.8 driver release
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
From what everyone's saying, 2.6.30 does indeed fix everything. But I don't have the fortitude to use the package in the AUR, so I'll just wait it out.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
@SomeGuyDude,
I've had some random and rare lockups too, which became more frequent when I update xf86-video-intel to 2.7.1, intel-dri to 7.4.2, libgl to 7.4.2 and mesa to 7.4.2. Also with these packages I had problems with assaultcube. The game played well but it didn't quit and I had to kill it by using ssh from another computer. Reverting to xf86-video-intel to 2.7.0 and intel-dri, libgl and mesa to 7.4.1 solved the problem, as suggested in this thread
http://bbs.archlinux.org/viewtopic.php?id=72279
I'm using
Option "Tiling" "false"
in xorg.conf.
Hope this helps
Giuseppe Borzi' - Registered Linux user #34028
Offline
From what everyone's saying, 2.6.30 does indeed fix everything.
Unfortunately, it doesn't. While some are claiming that 2.6.29 already gives back full performace, for me, it is 2.6.30 with KMS which brings back the speed of old times. It does not, however, remedy the lockups I am experiencing with UXA.
While there are many who have lockups with UXA and a few who experience them with EXA on the newer drivers, I find it quite curious that you experience lockups with the legacy driver. I don't remember anyone else reporting this on the forums. A quick look at the freedesktop bugzilla showed me nothing. Have you checked for the bug and filed it if it isn't reported? While the intel guys are ignoring bugs filed for old drivers exclusively, if the bugs persist, they do have a look at them.
Offline
Thing is, I don't know how to really track the bug. It occurs, but I seem to be totally alone in experiencing it so I do wonder if somehow I screwed something up without realizing it.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
I'm using a system running on an Intel 945GM Chipset(950 GMA gfx), and although performance isn't quite up to par compared to Q2 2008 packages, everything is probably as stable as ever. Packages:
xorg-server-1.6.1-1
libgl-7.4.2-1
mesa-7.4.2-1
intel-dri-7.4.2.-1
xf86-video-intel-2.7.1-1
xorg.conf snippet:
Option "mtrr" "on"
Option "Legacy3D" "false"
Option "Tiling" "false"
Note that I'm running on a custom-compiled kernel-2.6.30rc6, so maybe it's an issue related to kernel-2.6.29 in your case.
Possibly relevant grub kernel line options:
video=intelfb:ywrap,enable_mtrr_cleanup,nopat,vram:224
Lastly, I have "INTEL_BATCH=1" set.
Offline
So, I basically had to reinstall everything and delete all configuration files/folders. Everything's stable again. The performance isn't flawless but hey I can deal with that.
And in the midst of such perfection,
I can't help but feel diseased.
Offline
Good News here. I have 945 gm and arch 64bits. I installed intel-git driver from aur, kernel 2.6.30 rc6, no xorg.conf, dri2 and kms activated and is fast and stable! I can use kde4 effects and play with mupen with decent performance. I have dri2 so i'm using UXA.
Excuse my poor English.
Offline
From what everyone's saying, 2.6.30 does indeed fix everything.
I have a 915, and wake up from sleep still does not work, and the external display still does not work either. And from a performance point of view, I see no change.
Offline
I'm trying to get KMS in my Arch x86_64 / Kernel 2.6.31 / xf86-video-intel 2.9.1 driver / Intel GMA X3100 (GM965) graphics card.
In dmesg output occurs this error:
[drm: i915_driver_load] *ERROR* Failed to map registers
Someone knows what means this error?
I think that solving this problem I can load the KMS normally!!!
PS: I'm a brazilian user, so excuse my bad english.
Offline