[SOLVED] Intel 82845G

Mol_Bolom · 02-11-2010, 07:23 PM

<Edit May 31, 2011>
For Slackware 13.37 See posts (See #44 first.) 30, 36, and 37.

For Debian Squeeze, see post 38, 41.

<Edit May 21, 2010>
Purchased an Nvidia agp card (128mb)...Will no longer edit this thread...Sorry, hopefully everyone else will have better luck.

<EDIT April 25, 2010>
Finally got fed up with this, so I compiled the old xorg, libdrm, and mesa from slackware 12.2 source directory. After much fuddling around, I finally got it to work decent enough.

Through my travels of trying to fix this mess, I've read through a lot of bug reports and it seems that the 845G (rev 01) is the buggiest of them all. I think there is a fix for rev 02 and 03, but I'm not sure. Only have this computer to test on.

Either way, I'll still keep an eye out, and once there seems to be a fix, I'll upgrade, but until then, I'm running Slackware -current and xorg, mesa, and libdrm from Slackware 12.2...
</EDIT>

I've seen a few threads talking about this, and I figured why not start another one specific for the 845G in the Slackware forum. Though in this one, I just want to see what are all the errors everyone has been having with this chip, and what happens.

I have come across several bug reports at Arch, Gentoo, as well as Kernel and several other places. Once I can find them all I'll post them.

http://bugs.archlinux.org/task/17920...&sev=4&status=
http://bugs.archlinux.org/task/17705
Bug #15207

My problem mostly is a batchbuffer error, however depending on what configurations I use it does change.

Slackware:
13.0
Current

Kernels:
2.6.32.7 (generic and smp)
2.6.32-rc6 (with & without kms)
2.6.32-rc7 (with & without kms, with or without i830 and/or i810, with or without vesafb)

libdrm:
2.4.17 (1 packaged by witek, another from git)

Intel:
2.8.0
2.8.1
2.9.0
2.9.1
2.10.0 (1 packaged by witek, another from source)

Common errors that I get with most configurations. This specific one is on the kernel 2.6.33-rc7 with CONFIG-DRM-I830=y. I am not certain but I think I was using libdrm 2.4.17 and intel 2.9.1.

Code:

(WW) intel(0): i830_uxa_prepare_access: bo map failed
(WW) intel(0): i830_uxa_prepare_access: bo map failed

Fatal server error:
Failed to submit batchbuffer: Input/output error


Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) ImPS/2 Generic Wheel Mouse: Close
(II) UnloadModule: "evdev"
(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
(II) AIGLX: Suspending AIGLX clients for VT switch

dmesg

Code:

[ 1141.820029] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 1141.820039] render error detected, EIR: 0x00000000
[ 1141.820055] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 358445 at 358443)

Depending on which drivers/drm/kernel config I use I can get one of several unstable systems.

Complete hang, can not ssh in to look over the system and have to hard boot. Keyboard, mouse, poweroff switch doesn't work.

Partial hang, black screen. Can ssh in, don't have to hard boot. Keyboard, mouse, doesn't work.

X crash, black screen or unstable xorg. Can ctrl-alt-backspace/F#.

witek · 02-12-2010, 03:07 AM

Thanks to files prepared by 'matters' I finally made 2.10.0 working for me. I just had to explicitly enable kms during boot by adding this line to lilo:

Code:

append = "i915.modeset=1"

This made my video finally stable. New issues appeared however, namely, xine crashes X and mplayer works only with openGL video output, standard output fails. The files are here
http://advamacs.com/pub/intel-slackw...ting%20driver/

Mol_Bolom · 02-12-2010, 12:45 PM

I've tried them before, and still have all of the packages you and matters created on my computer. Anyway, I'm trying them again, perhaps the last time I didn't use both at the same time.

Configuration this time around...(So I don't forget)...

2.6.33-rc7 (Configuration suffix -Feb12)
libdrm kmsmatters
intel kmsmatters

First run, without i915.modeset=1 (I forgot while booting, so eh, I'll test it for now. Made a note and hung it above my keyboard to remind me later).

Problems:

With only monitor added to xorg.conf, using xrandr to set the resolution caused a jittery mouse.

After using old xorg.conf, mouse wasn't displayed at all. AIGLX off, Composite off, and a few other things disabled or not used

After removing all disabled in the xorg.conf file, mouse wasn't visible for a few seconds, but so far running fine.

Well, now need to see if it runs for more than 13 hours. Fingers crossed.

Mol_Bolom · 02-12-2010, 05:45 PM

Figures, didn't work...

Failed to submit batchbuffer.

However, a one thing was different this time around.

Direct 3D was horrible. Half the rendering that I had before, around 16 through 18 fps.

From dmesg: [ 0.932771 ] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking

However, I've gotten that error message before, depending on other configurations, so not new.

The crash was normal, though. Only rxvt was usable, and visible. Firefox was gone, but still useable, the mouse cursor changed when over edit boxes, and the window could be resized and moved.

This crash happened after I rebooted a little over an hour ago from this post with append="i915.modeset=1".

So, back to the drawing board...

Mol_Bolom · 02-12-2010, 05:45 PM

Ok, just tried with the newer kernel rc8, and no go. Looks like this batchbuffer thing just wont give up. Now not only does it crash, but while it runs direct rendering is about half what it was before.

Well, I'll give it one more week before I finally throw in the towel and go back to 12.2. Fingers crossed that I'll get it running.

Mol_Bolom · 02-13-2010, 01:31 PM

AHA, I think I've finally broken it down to where the problem lies...

I think it has something to do with this crt monitor. It's an Envision EN-910e, which is a large monitor with Horiz 30.0-95.0, Vert 50.0-160.0. As long as I have no xorg.conf, it seems to run smoothly, even direct rendering is showing nominal fps...

Well, after going through this link. I started wondering about the inteldrmfb driver, and reading on, I started thinking that the intel driver, xrandr, and xorg might not be used for changing resolutions. Instead it might be the fb driver that needs to be changed.

None the less, I recompiled the kernel (rc8), without any fb drivers, except the i915, removed the vga lines from lilo.conf, and removed the xorg.conf file, and so far, everything is running far more smoother, just with a horrible stretched 1024x768 resolution.

One more step closer, I hope...

<edit> Nope...That's not it. Just got lucky it lasted longer.

Mol_Bolom · 03-04-2010, 12:48 PM

Ok, an update.

I upgraded to the newer current, still using my custom 2.6.33 kernel with kms enabled.

Before upgrading, I had upgraded libdrm to 2.4.18 which slowed down X crashes. Instead of a few minutes to a few hours it was mostly a few hours til a crash.

Well, after upgrading to current yet again two nights ago, X crashed within minutes. So I compiled the newer libdrm 2.4.19. Which didn't help. However, while running xfce using the vesa driver I read a post about how xine would crash X. So I watched a dvd and yep, it crashed. So today I compiled the newer intel driver (2.10.901) and watched a full dvd without a single crash. I even exited X several times and haven't had to reboot yet. So far so good.

Mol_Bolom · 03-09-2010, 07:38 PM

Ok, something new with the dri issues.

Upgraded Slackware-current again just a few hours ago.

Kernel: 2.6.34-rc1
Libdrm: 2.4.19
Intel: 2.10.901

dmesg (Not the same, and X didn't crash)

Code:

[ 4234.570018] render error detected, EIR: 0x00000010
[ 4234.570018] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
[ 4234.570076] render error detected, EIR: 0x00000010

3D games run extremely slow, completely unplayable.

Now going to reboot with a custom 2.6.33 kernel. Then slowly downgrade libdrm and intel and see what happens.

<Edit> Didn't notice this in the last run, but with the 2.6.33 custom kernel I'm getting this in my Xorg.0.log

Code:

(EE) AIGLX error: Calling driver entry point failed
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0

<Edit2> Slackware's 2.6.33-smp kernel, same thing. Time to start downgrading...

<Edit3> Downgraded libdrm and intel to -current's. Still no AIGLX...Now to figure out why...

<Edit4> Removed xorg.conf file, no difference. Also, google turning up a lot of results, but nothing useful as of yet about the AIGLX prob.

<Edit5> Tried UrbanTerror. Not only are the graphics slow, but the music and sfx is distorted. So perhaps the two problems are related. (However, direct rendering: yes, and no problem with sound card...)...

<Edit6> Well, I can't figure it out, and besides while trying out different things, BAM, batchbuffer...Well, I guess that's it. I give up. I'll try to compile the intel driver without kms and a few other things before I finally throw in the towel, but for the most part I've had it. Eh, at least I learned how to customize the kernel, more xorg config, and a whole lot of other stuff (Heh, at least I've had less trouble than many people when I upgraded to current, so that's a plus,

).

Oh, by the way, I have dozens of Intel_gpu_dump, dmesg, and xorg logs since Feb 6th, should I learn how to post them to the patchwork kernel/freedesktop or just delete them?

Mol_Bolom · 03-10-2010, 11:40 AM

Well, something new today. I disabled monitor tracking and ACPI S3 Video REPOST in BIOS (Just for the heck of it) to which I don't get the same resolutions, nor does X get the monitor info from the Xorg.conf file. <edit: Re-enabled Monitor tracking, no change> <Edit: Reverted back to intel 2.10.901, libdrm 2.4.19, reset BIOS, still no change. So the comp just decided to do things differently today...Alrighty then>.

Also, there is a slight problem I haven't seen before, a rather odd problem that is worsened when I run xfce, on dwm 5.2 it's a tad bit different.

Testing Assaultcube and Urbanterror, in xfce, I have to shut down X completely because the monitor shuts off. However, on dwm the games shut down the monitor and all I have to do is kill the game and dwm is still running. (Thank the gods for learning how to use ssh).

dmesg showed this after xfce broke. (Didn't get this error running dwm).

Code:

[ 2262.045866] [drm:i915_gem_object_pin_and_relocate] *ERROR* Failure to install fence: -28
[ 2262.101998] [drm:i915_gem_object_pin_and_relocate] *ERROR* Failure to install fence: -28
[ 2262.102031] [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 7 of 9, total 3457024 bytes: -28
[ 2262.102039] [drm:i915_gem_do_execbuffer] *ERROR* 299 objects [10 pinned], 63172608 object bytes [9879552 pinned], 10403840/117571584 gtt bytes

Xorg.0.log showed this repeatedly, very repeatedly...(Might have something to do with changing screen resolutions to 1024x768 on xfce. Running dwm, Xorg.0.log only gives one of these).

Code:

(II) intel(0): EDID vendor "EPI", prod id 43413
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x1024"x0.0  157.50  1280 1344 1504 1728  1024 1025 1028 1072 +hsync +vsync (91.1 kHz)
(II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
(II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
(II) intel(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) intel(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
(II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
(II) intel(0): Modeline "640x480"x0.0   36.00  640 696 752 832  480 481 484 509 -hsync -vsync (43.3 kHz)
(II) intel(0): Modeline "800x600"x0.0   56.25  800 832 896 1048  600 601 604 631 +hsync +vsync (53.7 kHz)
(II) intel(0): Modeline "1024x768"x0.0   94.50  1024 1072 1168 1376  768 769 772 808 +hsync +vsync (68.7 kHz)
(II) intel(0): Modeline "1280x960"x0.0  148.50  1280 1344 1504 1728  960 961 964 1011 +hsync +vsync (85.9 kHz)
(II) intel(0): Modeline "1600x1200"x0.0  202.50  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (93.8 kHz)

Interesting none the less. Eh, maybe I'll play around with it like this for a while and see what happens.

Mol_Bolom · 03-13-2010, 11:54 PM

(Hopefully I'm not annoying the heck out of anyone by keeping this thread alive when it should have died before it was written,

)

Anyway. Just upgraded a few moments ago, and now 3D rendering is close to what I started out with in this message.

However, Assaultcube was the only one I was able to test and was extremely dark and couldn't increase the brightness. As well as the problems I've been having have worsen terribly. So, if by perchance anyone wants to, could they add the versions of X and mesa that were used with -current back in the beginning of February. It was that version with the 2.6.33 kernel, libdrm 2.4.19, and intel 2.10.901 that was the best configuration (or I should say that lasted the longest before a crash). Though I'm not sure what I could do with that information, too bloody much code to go through in mesa and X to figure out what, why, and how.

I've been reading through a lot of stuff, and am thinking about trying drm-intel at git.kernel.org. Though a LOT to learn, eh, might be interesting to try it out. First run, it was going to download way too much (at 0% it got to 4mb's before I canceled it).

<edit Mar-18-2010>
Since I'm still trying to figure all this out, and I'm certain this is annoying someone, I'll no longer "post" to the thread.

Anyhoo, something different happened just a few minutes ago.

Now using intel 2.10.902, libdrm from git, kernel 2.6.33.1. Have been running with this for two days now, and no problems outside of the usual. This time, however, X crashed while viewing LQ on seamonkey.

dmesg

Code:

[  685.054037] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[  685.054051] render error detected, EIR: 0x00000000
[  685.054072] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 17407 at 17406)
[  687.248026] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[  687.248034] render error detected, EIR: 0x00000000
[  687.285838] X used greatest stack depth: 5468 bytes left
[  688.495418] seamonkey-bin[1408]: segfault at a955303c ip b770c012 sp adcff2a0 error 6 in libpthread-2.11.1.so[b7702000+15000]

Xorg.0.log

Code:

(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
(EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.

Fatal server error:
Failed to map batchbuffer: Input/output error

<Edit March - 25 - 2010>
Well this is interesting, I forced an EIR stuck by attempting to play an flv in mplayer by selecting fbdev, however, X crashed, BUT I could restart it without rebooting.

Code:

[ 3653.439800] render error detected, EIR: 0x00000010
[ 3653.439810] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
[ 3653.439831] render error detected, EIR: 0x00000010

Also, yesterday I had 14 hours uptime before a crash. Either it's because I'm using Midori and seamonkey more often, or something really weird is going on. Nothing's changed since last edit.

<Edit April 13, 2010>
Well, a few days ago I compiled Mesa 7.8.1 and today I've been fighting with xserver 1.8.0 (Doesn't install the directories appropriately, actually though, mesa did the same thing. Some issue that a simple edit of the slackbuilds borks). Upgraded evdev without any issues, though. So far the only problems I have are the usual, X crash with the exact same bloody thing, while running the newer kernel (Need to try the last kernel I compiled which has a fix for the 855G, keep forgetting about it), and another problem in which I can only run X as root (Googled for hours and the only thing I can tell is all my permissions are correct, so still in the dark).

Either way, I've been searching all day for information on how to compile, and what deps are needed, for the newer xorg and I've found absolutely nothing. Some point to wiki.x.org, some to other places, but nothing that has actually explained it. Unfortunately stuck with elinks, links, or lynx for a browser at the moment.

Well, back to google...

pluckypigeon · 04-26-2010, 12:55 AM

I have found your posts interesting, thanks.

Did you ever solve these problems? I've suffered with the same problems, although on a different distro. I also have the i845g.

Thanks again

Mol_Bolom · 04-26-2010, 10:50 AM

Well, unfortunately, I never did solve it. I've been following along with bugs #27187 (specific to 855g) and #26345 (specific to 845g), and found bug #24789 not long ago.

I spent all yesterday compiling xorg 1.4.2, mesa 7.0.3, and libdrm 2.3.0, and so I've got a stable system (I need a break for the moment,

). Though, the main reason for compiling the older versions was to get it to compile and work, now I have a template to work with and can now start working on compiling newer versions and testing them.

Still have a few things to work out, though. One of the biggest issues of downgrading, which I presume is going to be a problem for when I upgrade is linking problems. The first time I tried downgrading I had a lot of failed packages, then I downgraded from the slackware 12.2 mirror, then recompiled everything which worked. I seemed to have some problems with the configure scripts. Took me a while to figure out that the xorg-server lines MESA_VERSION=${MESA_VERSION:-7.0.2}, and CFLAGS="$SLKCFLAGS" \ were wrong. Mesa version on slack 12.2 is 7.0.3 not 7.0.2, and the \ at the end of the CFLAGS line shouldn't be there, and completely in the dark as to why several of the sources wouldn't compile the first time, but that's probably my fault for not noticing or finding the variables that needed to be changed.

Anyway, I'm not finished yet, I'm just burnt out,

. Going to take a break for a while, then try to tackle this again.

P.S. If anyone happens to have any tips and/or tricks for retrieving xorg upgrades/downgrades of each individual source without having to manually download every single separate file from a browser, I'm all eyeballs,

.

Mol_Bolom · 04-26-2010, 10:50 AM

<Edit> double post.

Though, I might mention that from what I've read, it seems that the 845G (rev 01) is the buggiest, but I don't think I should try and upgrade my sons computer (rev 02) to test to see if that is the case.

BobNutfield · 04-26-2010, 03:24 PM

I have a couple of other threads regarding this chip. I have found no combination of anything works EXCEPT stock Slackware 13 with the vesa driver. With that I get relatively decent flash performance and a 1024 X 768 desktop on this old P4 laptop. Of course there are no graphic goodies available, but for general computing it works. I tried a number of hardware friendly distros just trying to find SOMETHING that would work with the 82845G. Nothing would work using any driver except VESA (even Pupply would not work with anything else.)

When this laptop had Windows XP on it, graphics performance with pretty weak there, too. There is apparently 128MB of graphics memory in this chip from about 2003. As a matter of fact, Ubuntu Jaunty did not even support it.

God help anyone with this chip looking for anything other than general desktop computing.

Bob

Mol_Bolom · 04-26-2010, 04:07 PM

@BobNutfield

The problem is when they changed the driver to be more reliant on the kernel rather than xorg (I still don't understand it fully, but that's my best guess). Earlier versions of xorg worked fine with the 845G, just from memory, that's Zenwalk 5.2, Slackware 12.2, Vector 5.9, Puppy 4.1.1 & 3.0.1 and I don't recall the other distros versions that I've tried, Mepis, Slax, Ubuntu, and a few others. Which I believe were xorg versions 1.4.2 and earlier.

The developers are working hard on the problem, so there's still hope,

.

Anyway, I will still keep watching the bug reports and hoping there will be a cure soon.