You are not logged in.
By 'working' I mean 'not crashing'. I can install xorg 1.8 just fine, but rebooting every half an hour is not my thing. The crashes happen even if I'm just typing away at the xterm.
[karol@black ~]$ lspci -v | grep -i -A8 VGA
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA controller])
Subsystem: IBM NetVista A30p
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 88000000 (32-bit, prefetchable) [size=128M]
Memory at 80000000 (32-bit, non-prefetchable) [size=512K]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
There are some bug reports in both our and upstream bugtrackers but the issues are still open.
I'm quite happy w/ xorg 1.6 I have so it's not a life-or-death situation by any means. If you got it working, please tell me how you did it - there's a myriad of "switches" to flip and I'm too lazy / busy to try them all out. I've tried a few and got nowhere, so I'm asking you, my fellow Archers.
Offline
Unfortunately, I believe this is a driver bug that has existed for almost a year now. There is a small group of people working on it, but progress has been slow. I stopped using linux on one of my machines because of this bug....the alternative is using old versions of the intel driver and Xorg (like you do).
Scott
Last edited by firecat53 (2010-07-10 21:57:26)
Offline
I have a 945GM chipset and used to experience constant hard-crashes with the new Xorg. My "solution" was to compile my own kernel-2.6.35-rc4. It worked for me, so I thought I'd mention it.
Offline
> It worked for me, so I thought I'd mention it.
Mind posting the config? Any patches?
Offline
The 82845 and 945gm are obviously different chipsets....what works for the other Intel chips, even the 855 series which is extremely close to the 845, doesn't work for the 845. There are a couple of contributers to the bug fixing that have managed working 855 configurations but no one has yet solved the 845 driver problem. This bug had been a b#$%& to fix, apparently.
Scott
Offline
The 82845 and 945gm are obviously different chipsets....what works for the other Intel chips, even the 855 series which is extremely close to the 845, doesn't work for the 845. There are a couple of contributers to the bug fixing that have managed working 855 configurations but no one has yet solved the 845 driver problem. This bug had been a b#$%& to fix, apparently.
Scott
Yes, I'm aware of it all, but I still don't get certain things, like where does the problem "live": in the kernel, in the Intel driver, libdrm or somewhere else?
Offline
I have found that the hard locking which occurs using the version of the xorg intel driver xf86-video-intel 2.11.0-1 from the main arch repos is improved by using the latest intel drivers for xorg (xf86-video-intel 2.12.0-1). FTR, I am using this on an old Dell Optiplex GX260 with an intel 845GE chipset.
The best thing that happens is that it doesn't take down Xorg when the gpu hang occurs, it just disables 2D acceleration. So while still annoying to say the least, at least you can save whatever it is you were working on and reboot back for another few hours.
Last edited by carbonero (2010-07-11 15:38:17)
Offline
> improved by using the latest intel drivers
'Improved' meaning not breaking at all? I tested the new intel from AUR yesterday and it crashed too.
Offline
> improved by using the latest intel drivers
'Improved' meaning not breaking at all? I tested the new intel from AUR yesterday and it crashed too.
Interesting, I didn't use the PKGBUILD from the AUR, I just modified the existing PKGBUILD from the arch repos (via ABS) to pull everything vanilla from upstream - though there shouldn't really be anything different from my hacked together version and the xf86-video-intel-newest package in AUR.
Though when I said improved, I meant that it did not lock up Xorg or anything, it just fell back to software rendering of everything (ie everything is rendered via cpu and extremely sluggish. You can still operate the computer though, despite the gpu being hung.
Last edited by carbonero (2010-07-11 15:41:46)
Offline
It's important that everyone not only posts bug reports with Intel, but nags that shit out of them. Intel has a history of very low quality graphic drivers.
Offline
@ carbonero
The sluggishness goes away or do you have to reboot?
@ skottish
Got any names and addresses? ;-)
Last edited by karol (2010-07-11 15:47:42)
Offline
@ carbonero
The sluggishness goes away or do you have to reboot?@ skottish
Got any names and addresses? ;-)
Offline
I think nobody likes duplicates of a known bug so I'm not sure if this is the right way to poke them.
Offline
> It worked for me, so I thought I'd mention it.
Mind posting the config? Any patches?
I just pastebin'd the entire .config. Note that it's pretty slimmed-down and extremely custom-tailored for my Acer 5610 laptop.
I also use xf86-video-intel-newest to solve some "scanline appearance" and general artefact issues I used to have. Everything "works"(insofar as any Intel gfx "works" nowadays) relatively well now.
Last edited by Ronin-Sage (2010-07-11 16:54:51)
Offline
> extremely custom-tailored for my Acer 5610 laptop
I don't think it will fly then, but thanks anyway.
Offline
@ carbonero
The sluggishness goes away or do you have to reboot?@ skottish
Got any names and addresses? ;-)
The sluggishness goes away after a reboot cycle.
Offline
> The sluggishness goes away after a reboot cycle.
<sigh> I really need to find that magic wand that makes bugs go away. But first I have to steal Santa's sleigh and go somewhere that's not 35-45 oC hot.
Firefox saves the sessions, vim has an excellent recovery option so I'm covered against data loss. I just don't like being interrupted w/ a forced reboot.
Offline
Alright so out of desperation I tried to add the parameter
i915.powersave=0
in the kernel boot parameters just to see if it would make any difference in the sluggishness that I experienced with the xf86-video-intel 2.12.0 drivers. Surprisingly it has, and after about 6 hours of usage with a lot of stress testing (ie playing two videos simultaneously, browsing, etc) there still hasn't been a gpu hang ... well yet anyway. The only thing that has happened is when a particular flash advert decided to sneak through, the kernel left these three lines:
render error detected, EIR: 0x00000010
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
however it just kept on going after that without a hitch.
I'm not sure if this is a workaround or not, but I will try to keep everyone posted.
Offline
@ carbonero
'i915.powersave=0' + xf86-video-intel 2.12.0 you say? I'll give it a shot.
Edit: I've checked that I've tried it already but chickened out because window repositioning (I'm using dwm) was abysmal. [1] I'm gonna try again.
[1]
- opening new terminals and rearranging the current tag took ~2 secs
- scrolling in firefox is outright awful
- redrawing the cursor is gone
Last edited by karol (2010-07-12 21:49:34)
Offline
@ carbonero
'i915.powersave=0' + xf86-video-intel 2.12.0 you say? I'll give it a shot.Edit: I've checked that I've tried it already but chickened out because window repositioning (I'm using dwm) was abysmal. [1] I'm gonna try again.
[1]
- opening new terminals and rearranging the current tag took ~2 secs
- scrolling in firefox is outright awful
- redrawing the cursor is gone
I cannot speak for firefox performance on my side here (primarily using uzbl and now more recently dwb), but I also use dwm. Though the new Xorg releases don't really rely on an xorg.conf for the setup configuration anymore, I wonder if there is anything that could be different between our settings that could account for the difference in stability/useability?
Offline
[karol@black ~]$ dmesg | tail
EXT3-fs (sda4): using internal journal
EXT3-fs (sda4): mounted filesystem with writeback data mode
Adding 265068k swap on /dev/sda2. Priority:-1 extents:1 across:265068k
e100: eth0 NIC Link is Up 100 Mbps Full Duplex
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
render error detected, EIR: 0x00000000
[drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 197 at 196)
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
eth0: no IPv6 routers present
Cool, huh?
I get the correct resolution (1440x900) but the cpu utilization hoovers around 10% instead around 1% - and no movie watching.
I must have done sth wrong.
It's 2 AM and it's still 20 oC outside and much too humid for my taste. I think my circuits need some ice-cream. BRB
Last edited by karol (2010-07-13 00:15:01)
Offline
Okay, so I fired up chromium and openbox to see if that would trigger the gpu hang and lo and behold ... the nasty little blighter decided to pop up in dmesg :-(
This still begs the question though of why I am able to use this thing for hours before something happens under dwm, but happens pretty quickly under even a simple window manager like openbox...
It's 2 AM and it's still 20 oC outside and much too humid for my taste. I think my circuits need some ice-cream. BRB
We're getting rain here tomorrow, so that will most likely be my situation tomorrow heh
Offline
Same hardware here, having this issue for about two years now with linux in general, about six months ago I start using arch, to my surprise it didn't crash that much and when it did a least it took me to the console login, so no data was lost. a month ago I switch to arch completely and just for the fun of it I have four arch DE in my single computer the results are as follow:
Gnome=no crashes smooth performance even with composite enabled (the simple one build in gnome)
KDE=freezes on some heavy loaded webpages with flash media, a strange garbaged screen occurs when I am using some software in root mode like dolphin then it crash and takes me to login window. this could be kde I have no idea.
Xfce=freezes with heavy flash media once in a while. can be restarted by killing x.
LXDE=no crashes/freezes (I use it just for internet surfing)
all of the above with up to date software.
Coming from Ubuntu lucid I may said that the driver has been improved, and probably cutting the fat out of the system may improve performance. I use gnome as my main system and all I can say is that finally I can use my computer for something else other than trying to fix xorg and intel. I was really moved to buy a new one but Arch just give me some more juice out of this old machine. same intel card than described in the first post. this is definitely not my Ubuntu 8.04 which was flying in amazing compositing effects but a least is back to a tool I can work on.
All of my systems are fresh installs, all of them with the xorg 1.8 and the ..34.. kernel since the beginning, there is no xorg.conf file on any, I haven't had a crash in which I need to do a hard restart.
Natural Spanish speaker person babbling English...
Natural Linux user babbling Archlinux...
Offline
I use dwm and work mainly in urxvt so it's as light as can be - the cpu is idling, memory consumption below 70 MB - and it does crash w/ the intel driver currently in repo.
When it crashes, in most cases the display is frozen, I can move the mouse around but can't click anything. Sometimes X will throw me back directly to the console.In either case I can't restart X, I have to restart the whole system.
Offline