Description of problem: I've got a intel g41 chipset, and being aware that there's a need for kernel patches to get the chipset recognised, I've been looking at kernels in koji. I'm using rawhide, but noticed the kernel-2.6.30-0.76.rc4.fc12 build which I tried and which failed to boot. I left it as that as it was f12 and I'm on f11. Recently kernel-2.6.29.2-132.fc11 was built (but krn) and I've tried this, only to get the same problem when booting. The blue lines all happen on the bottom, but the boot goes no further. If I push escape, I get the following error message (using the f11 kernel): Starting udev: udevd-event[158]: `/sbin/modprobe -b pci:v00008086d00002E32sv00001458sd0000D000bc03sc00i00' abnormal exit. I've been back and tried the two f12 kernels in koji and they give the same message. Also, I noticed that there's some text on the screen before I push ESC that looks a lot like the kernel reporting that something has gone wrong, but it disappears too fast and I don't know how to get my hands on it. Version-Release number of selected component (if applicable): [root@localhost log]# rpm -qa | grep kernel *kernel-2.6.30-0.78.rc4.git3.fc12.i586 *kernel-2.6.30-0.76.rc4.fc12.i586 *kernel-2.6.29.2-132.fc11.i586 kernel-2.6.29.2-130.fc11.i586 kernel-2.6.29.1-111.fc11.i586 kernel-firmware-2.6.30-0.78.rc4.git3.fc12.noarch kernel-firmware-2.6.29.2-132.fc11.noarch kerneloops-0.12-5.fc11.i586 How reproducible: Everytime with the kernels marked * above. All the other kernels boot fine, but DRM doesn't work on my intel chipset.
This is the bug that I'm trying to solve (and the reason why I'm trying these kernels) https://bugzilla.redhat.com/show_bug.cgi?id=493307
I don't have G41 HW, and I don't like the sound of this... can you try booting with nomodeset on the kernel command line, just to see if that makes a difference. Or boot up in one of your working kernels, do echo blacklist i915 > /etc/modprobe.d/blacklist-i915 reboot into -132 and try to load the i915 manually using modprobe i915 and see if that works. Attach the output of dmesg after loading the module. thanks, Kristian
(In reply to comment #2) > can you try booting > with nomodeset on the kernel command line, just to see if that makes a > difference. I tried with just nomodeset, and the boot up seemed to finish, but X didn't start and everything locked up. So I tried with 'nomodeset 3' and the boot finished and went to a working command line. Tried starting X (startx) and all locks up.
Created attachment 343183 [details] Output of dmesg file when booting with nomodeset
(In reply to comment #2) > Or boot up in one of your working kernels, do > > echo blacklist i915 > /etc/modprobe.d/blacklist-i915 > > reboot into -132 and try to load the i915 manually using > > modprobe i915 > > and see if that works. Attach the output of dmesg after loading the module. The first time I tried this I got through the boot and X started. I then tried to switch to a terminal and there were no VT's and the keyboard locked. I then rebooted and added the magic '3' to the boot process. This got me to run level 3. I ran modprobe i915 &> /tmp/output to try and capture the on screen output but this doesn't work for some reason. There's about 5 pages of stuff and after switching to another VT to try and copy it into a file and switching back, I can't scroll up the screen (using PageUP/PageDOWN) to get to the pages above. The information in dmesg seems to be a nice summary of what I'm seeing on the screen, so I'm starting with this, but if you want all the screen output then I'll take photos or do something. After doing this I tried starting X and it froze requiring a reboot. dmesg out was gain by running dmesg > /tmp/dmesg.modprobe_i915
Created attachment 343187 [details] dmesg output after running modprobe i915
thanks for you quick response. Rodd
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 i915 0000:00:02.0: setting latency timer to 64 i915 0000:00:02.0: irq 24 for MSI/MSI-X [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12 ------------[ cut here ]------------ kernel BUG at drivers/gpu/drm/drm_gem.c:432! BUG_ON(!mutex_is_locked(&dev->struct_mutex));
Ok, that's a known issue. It's the reason that G41 wasn't supported before and something the intel developers are working on. Some G41 bioses have the entire aperture configured as "stolen" memory, which means we can't map pages into it with the current AGP code. We need to either change the AGP code or just pull the AGP code into GEM. Not sure what the best workaround is. Keep the i915 module blacklisted and run X without DRI for now.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #9) > Ok, that's a known issue. It's the reason that G41 wasn't supported before and > something the intel developers are working on. Some G41 bioses have the entire > aperture configured as "stolen" memory, which means we can't map pages into it > with the current AGP code. We need to either change the AGP code or just pull > the AGP code into GEM. > > Not sure what the best workaround is. Keep the i915 module blacklisted and run > X without DRI for now. Is this being tracked in bugs.freedesktop.org and if so can someone point me to the bug. This work around isn't great. I know it's probably too late to pull out, but it leaves some g41 uses with unbootable systems with no knowledge why.
Also, I note the 2.7.99 (a prerelease of 2.8 is out, but can't tell if it addresses this problem.) I'm hoping that this might be a priority for f12, but not sure how to make it so.
My system doesn't boot with this chipset in f12 (either the installer, or the installation). I can run nomodeset, but performance is slow and unstable (it crashes). I would have thought this should have been sorted by know since the upstream bug claims if FIXED.
Okay, I got this fixed, but you need to set the variables in the BIOS correctly, which is hard to figure out when you can't get it to boot and the message about this is in the Xorg logs. Not sure there's much you can do about that. I would have thought the more video memory the better but I can only dedicate 128MB to the system, which isn't much (it will do up to 264 + 64MB)