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.0
- Fedora 10 kernel 2.6.27, X.org 1.5
- Fedora 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.
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.