This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 499779 - i915 fails on G41 chipset
i915 fails on G41 chipset
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-08 02:18 EDT by Rodd Clarkson
Modified: 2009-12-02 20:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-02 20:14:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output of dmesg file when booting with nomodeset (31.39 KB, text/plain)
2009-05-08 18:00 EDT, Rodd Clarkson
no flags Details
dmesg output after running modprobe i915 (35.07 KB, text/plain)
2009-05-08 18:07 EDT, Rodd Clarkson
no flags Details

  None (edit)
Description Rodd Clarkson 2009-05-08 02:18:16 EDT
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@redhat.com) 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.
Comment 1 Rodd Clarkson 2009-05-08 02:22:23 EDT
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
Comment 2 Kristian Høgsberg 2009-05-08 09:41:38 EDT
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
Comment 3 Rodd Clarkson 2009-05-08 17:59:38 EDT
(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.
Comment 4 Rodd Clarkson 2009-05-08 18:00:39 EDT
Created attachment 343183 [details]
Output of dmesg file when booting with nomodeset
Comment 5 Rodd Clarkson 2009-05-08 18:06:54 EDT
(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
Comment 6 Rodd Clarkson 2009-05-08 18:07:36 EDT
Created attachment 343187 [details]
dmesg output after running modprobe i915
Comment 7 Rodd Clarkson 2009-05-08 18:08:04 EDT
thanks for you quick response.


Rodd
Comment 8 Chuck Ebbert 2009-05-09 11:58:03 EDT
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));
Comment 9 Kristian Høgsberg 2009-05-12 13:40:50 EDT
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.
Comment 10 Bug Zapper 2009-06-09 11:25:59 EDT
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
Comment 11 Rodd Clarkson 2009-06-25 01:10:29 EDT
(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.
Comment 12 Rodd Clarkson 2009-06-25 01:11:37 EDT
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.
Comment 13 Rodd Clarkson 2009-11-29 19:40:32 EST
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.
Comment 14 Rodd Clarkson 2009-12-02 20:14:45 EST
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)

Note You need to log in before you can comment on or make changes to this bug.