Embedded Intel Atom® Processors
Intel Atom® Hardware, Software, Firmware, Graphics
998 Discussions

IEGD 10.1 libGL_ga.so.1.2 for GMA 500



I've been trying to resolve some OpenGL problems on my Z510-based platform which has a GMA-500 gpu. I also have an N270 platform (with a 945GSE gpu) where the OpenGL support is working perfectly fine with the very same IEGD drivers (but using libGLgn3.so instead for libGL).

The only notable difference between the two is that the N270 (945GSE) seems to set up an MTRR at 0x0d0000000 of length 256MB properly, while the Z510 platform (GMA500) seems to attempt to set up a 256MB MTRR @ memory location 0x3F800000, which is an invalid starting point for such an MTRR length. The MTRR needs to begin at a 256MB boundary.

Because of this, the Z510 platform reports a failure to set up a Write-Combining range when Xorg initializes. I suspect that this discrepancy is resulting in the failure of OpenGL to run properly when using a lot of memory-mapped texturing. The OpenGL program will update the display for a few frames, and then it will fail to update the display after those few frames. However, the OpenGL library calls seem to move along like nothing is wrong.

I am using Linux kernel 2.6.30 with Xorg 1.6.1 and getting over this hurdle is the last thing I need in order to have a perfectly working. My software deployment is very close to that of Moblin 2.0.

0 Kudos
6 Replies

Your problem is more likely that you are attmepting to use a later kernel rev and X-Server version than IEGD currently supports. For the IEGD 10.1 release, it lists these as supported:

Moblin 2.0 Linux kernel 2.6.29-rc2, X server 1.6.0Fedora 10 kernel 2.6.27, X.org 1.5Fedora Core 7* (2.6.21 – 1.3194 and X.org 7.2)Wind River Linux* (kernel 2.6.21, X.org 7.2, X server 1.3)Red Hat Linux* Embedded (kernel 2.6.23, X.org 7.2, X server 1.3)

So as you can see kernel 2.6.29 and Xserver 1.6.0 are the latest supported currently.

Kernel .30 *might* be manually patchable but you will need to look at the IKM script and code to see how we patch the .29 kernel for GART and DRM (DRM is critical for operation). I've heard that the X API changed between 1.6.0 and 1.6.1 so you may need to wait for a newer version (10.2?) to get that capability. The alternative would be to use something that matches the kernel and X-Server versions on the supported list.

Hope that helps.


Any chance I could see the dmesg output of IEGD running on a working system? This would also help me answer questions that I have on the platform regarding what I should be seeing vs. what I am expecting to see.

The only comparison I have right now is a 965-based core2 Q6600 system, and a 945GSE-based Atom N270 platform.


Here are the pertinent areas from a working development system where we are working on supporting later kernel versions.


[ 0.375170] Linux agpgart interface v0.103

[ 0.377494] loop: module loaded


[ 3.903629] [IEGD]: Registering iegd gart module

[ 3.903719] [IEGD]: Initialize IEGD agpgart and drm

[ 3.903894] [IEGD]: Intel US15 chipset detected

[ 3.904582] [IEGD]: Detected 3836K stolen memory.

[ 3.961604] EXT3 FS on sda1, internal journal

[ 3.969661] iegd-intel 0000:00:00.0: AGP aperture is 256M @ 0x3fc00000

[ 3.969734] [IEGD]: Registering iegd drm module

[ 3.969741] Initializing DRM for Intel US15 SCH

[ 3.969777] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

[ 3.969791] pci 0000:00:02.0: setting latency timer to 64

[ 3.969843] mtrr: base(0x3fc00000) is not aligned on a size(0x10000000) boundary

[ 3.970101] [drm] Initialized iegd 1.0.1 20081022 for 0000:00:02.0 on minor 0

[ 4.355644] kjournald starting. Commit interval 15 seconds

[ 4.355861] EXT3 FS on sda2, internal journal

[ 4.355883] EXT3-fs: mounted filesystem with writeback data mode.

[ 5.488569] fuse init (API version 7.11)

[ 8.835580] Adding 819304k swap on /dev/sda3. Priority:-1 extents:1 across:819304k

[ 9.251755] warning: `avahi-daemon' uses deprecated v2 capabilities in a way that may be insecure.

[ 9.367946] e1000e 0000:01:00.0: irq 24 for MSI/MSI-X

[ 9.419200] e1000e 0000:01:00.0: irq 24 for MSI/MSI-X

[ 9.420584] ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 10.771048] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

[ 10.771067] 0000:01:00.0: eth0: 10/100 speed: disabling TSO

[ 10.771799] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[ 20.774011] eth0: no IPv6 routers present

[ 34.679550] mtrr: base(0x3fc00000) is not aligned on a size(0x10000000) boundary

[ 35.405642] mtrr: base(0x3fc00000) is not aligned on a size(0x10000000) boundary



Did you reach some solution here ? I am currently running 10.3 with Moblin 2.1 on Asus EeePC (US15W) and it seems that mtrr's are still messed up like this. The Xorg driver cannot set its write-compining range and falls to 32Mb of videoram.

In my case it seems to try 256Mb range at 0x3f800000... which goes above available sysram. It is similarly the address informed as AGP Apperture as mentioned here. Another note was that the VideoRam request in xorg.conf doesn't seem to have affect on size request at all.


Same situation here about "mtrr: base(0x3f800000) is not aligned on a size(0x10000000) boundary", anyone can tell me what's going on?


The MTRR setup is intentional. The memory manager works differently on the US15w from 945GSE and we need to setup the MTRR in a slightly odd way to compensate. This is "under the hood" stuff that should affect operation- that error should not affect any operation. We might be able to eliminate that warning but it is a low priority issue.

If you are experiencing issues using a lot of textures or heavy memory usage- porblems there are usually related to actually running out of graphics memory which OGL and Linux and appstend to not handle elegantly. Basically what we have found is that people do not handle an "out of memory" error from the driver and try to keep running even though things needed are not in memory because of the out of memory situation.

Take a close look at this if you are having issues.

Hope this helps.