Bug 499779

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)