initramfs scripts hard-coded to load i915; blocks loading non-intel drm modules

Bug #392039 reported by sam tygier on 2009-06-25
62
This bug affects 12 people
Affects Status Importance Assigned to Milestone
fglrx-installer (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned
initramfs-tools (Ubuntu)
High
Scott James Remnant (Canonical)
Karmic
High
Scott James Remnant (Canonical)
udev (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned
usplash (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned

Bug Description

i installed fglrx through jockey. rebooted. i get no acceleration, moving windows around is very jerky. using a:
08:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3600 Series

Xorg.0.log say:
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *

ProblemType: Bug
Architecture: amd64
Date: Thu Jun 25 10:44:39 2009
DistroRelease: Ubuntu 9.10
Package: xorg-driver-fglrx 2:8.620-0ubuntu1
ProcCmdLine: root=UUID=256757a3-27af-4475-a2e2-f1d4f485c8b9 ro quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-10.12-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu6
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
 xserver-xorg-video-ati 1:6.12.2-2ubuntu2
SourcePackage: fglrx-installer
Uname: Linux 2.6.30-10-generic x86_64
dmi.bios.date: 11/07/2007
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: S2696
dmi.board.vendor: Tyan Computer Corporation
dmi.chassis.type: 6
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/07/2007:svn:pn:pvr:rvnTyanComputerCorporation:rnS2696:rvr:cvn:ct6:cvr:
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.30-10-generic

sam tygier (samtygier) wrote :
Felix Kuehling (felix-kuehling) wrote :

Running Ubuntu 9.10 with kernel 2.6.30? I won't even ask how you got as far as you did. ;) But here is what I think the problem is:

Looks like the drm kernel module is loaded. See this message in BootDmesg.txt: "[drm] Initialized drm 1.1.0 20060810". Therefore the fglrx kernel module fails to load later on with "[fglrx:firegl_init_module] *ERROR* firegl_stub_register failed". Without the fglrx module loaded, you won't get DRI.

You need to unload the drm kernel module before fglrx can be loaded.

sam tygier (samtygier) wrote :

>Running Ubuntu 9.10 with kernel 2.6.30? I won't even ask how you got as far as you did. ;)
really, i just enabled fglrx in jockey.

drm was in use by i915. i did
sudo modprobe -r i915
sudo modprobe -r drm
modprobe fglrx

and restarted X. now moving windows is smooth, and i can enable compiz.

so why is drm getting loaded when fglrx is enabled?

Bryce Harrington (bryce) on 2009-06-26
summary: - fglrx DRI initialization failed
+ [HD 3600] fglrx DRI initialization failed

I've posted a new version of the -fglrx driver to our xorg-edgers PPA,
would you mind testing it either on Jaunty or Karmic and see if it
resolves this bug?

Get fglrx 8.620 here:

  https://edge.launchpad.net/~xorg-edgers/+archive/ppa

Changed in fglrx-installer (Ubuntu):
status: New → Incomplete
sam tygier (samtygier) wrote :

the xorg-edgers version seems to be the same as the karmic version. at least the numbers are the same.

Do you perhaps have an integrated card that is still showing up on the PCI
bus that is using the i915 driver? If you can disable that in the BIOS,
that should help out and prevent such issues.

2009/6/25 sam tygier <email address hidden>

> >Running Ubuntu 9.10 with kernel 2.6.30? I won't even ask how you got as
> far as you did. ;)
> really, i just enabled fglrx in jockey.
>
> drm was in use by i915. i did
> sudo modprobe -r i915
> sudo modprobe -r drm
> modprobe fglrx
>
> and restarted X. now moving windows is smooth, and i can enable compiz.
>
> so why is drm getting loaded when fglrx is enabled?
>
> --
> fglrx DRI initialization failed
> https://bugs.launchpad.net/bugs/392039
> You received this bug notification because you are subscribed to fglrx-
> installer in ubuntu.
>

--
Mario Limonciello
<email address hidden>

I am also seeing this on my dv7 laptop,

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series

Linux imac-karmic 2.6.30-8-generic #9-Ubuntu SMP Wed Jun 3 15:38:38 UTC 2009 x86_64 GNU/Linux

ii fglrx-kernel-source 2:8.620-0ubuntu2 Kernel module source for the ATI graphics ac

Removing i915, then drm resolved the issue for me also. Adding to my local blacklist for now.

Changed in fglrx-installer (Ubuntu):
status: Incomplete → Confirmed
summary: - [HD 3600] fglrx DRI initialization failed
+ [Mobility Radeon HD] fglrx DRI initialization failed

mario,
There is no integrated graphics card on the motherboard (there is no video connector on the motherboard back plate, and it does not show in lspci).

Jaromir Obr (jaromir-obr) wrote :
Download full text (4.1 KiB)

Hello,
same problem on notebook Toshiba Satellite A300d-18i with graphics Ati Radeon Mobility HD3400
SW: Ubuntu 9.10 alpha 3, kernel 2.6.28-13-generic x86_64

Blacklisting of i915 didn't help me. Gnome freezes with black screen upon start.
Driver seems to be crashing:
--------------------------------------
Jul 26 22:22:37 turion kernel: [ 34.648939] Pid: 3127, comm: Xorg Tainted: P D 2.6.28-13-generic #45-Ubuntu
Jul 26 22:22:37 turion kernel: [ 34.648941] RIP: 0010:[<ffffffff802e263f>] [<ffffffff802e263f>] kfree+0x4f/0x100
Jul 26 22:22:37 turion kernel: [ 34.648945] RSP: 0018:ffff8800b814bd48 EFLAGS: 00010202
Jul 26 22:22:37 turion kernel: [ 34.648947] RAX: 00000363fdc96820 RBX: ffffe563fdc96820 RCX: ffff880001037f80
Jul 26 22:22:37 turion kernel: [ 34.648950] RDX: ffffe20000000000 RSI: ffff8800be186ca8 RDI: 00007fff5e1dc2c0
Jul 26 22:22:37 turion kernel: [ 34.648952] RBP: ffff8800b814bd78 R08: 0000000000000000 R09: 0000000000000002
Jul 26 22:22:37 turion kernel: [ 34.648954] R10: ffff8800b814bd4d R11: 0000000000000001 R12: 0000000000000005
Jul 26 22:22:37 turion kernel: [ 34.648956] R13: 00007fff5e1dc2c0 R14: ffff8800bdcb8000 R15: 0000000000000000
Jul 26 22:22:37 turion kernel: [ 34.648959] FS: 00007f63561b66f0(0000) GS:ffff8800bf802b80(0000) knlGS:00000000f79dcb90
Jul 26 22:22:37 turion kernel: [ 34.648961] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jul 26 22:22:37 turion kernel: [ 34.648963] CR2: ffffe563fdc96820 CR3: 00000000bd9f1000 CR4: 00000000000006a0
Jul 26 22:22:37 turion kernel: [ 34.648965] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 26 22:22:37 turion kernel: [ 34.648967] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul 26 22:22:37 turion kernel: [ 34.648970] Process Xorg (pid: 3127, threadinfo ffff8800b814a000, task ffff8800bc86c320)
Jul 26 22:22:37 turion kernel: [ 34.648972] Stack:
Jul 26 22:22:37 turion kernel: [ 34.648973] 0000010046495441 ffff8800bd063d30 0000000000000005 ffff8800b814bda8
Jul 26 22:22:37 turion kernel: [ 34.648977] ffff8800bdcb8000 0000000000000000 ffff8800b814bd88 ffffffffa0165ef9
Jul 26 22:22:37 turion kernel: [ 34.648980] 0000000000000002 ffffffffa0196ed9 ffff8800b814bdc8 00007fff5e1dc2c0
Jul 26 22:22:37 turion kernel: [ 34.648984] Call Trace:
Jul 26 22:22:37 turion kernel: [ 34.648987] [<ffffffffa0165ef9>] KCL_MEM_SmallBufferFree+0x9/0x10 [fglrx]
Jul 26 22:22:37 turion kernel: [ 34.649090] [<ffffffffa0196ed9>] firegl_acpi_eval_method+0x159/0x320 [fglrx]
Jul 26 22:22:37 turion kernel: [ 34.649150] [<ffffffffa0196d80>] ? firegl_acpi_eval_method+0x0/0x320 [fglrx]
Jul 26 22:22:37 turion kernel: [ 34.649208] [<ffffffffa0173bfa>] ? firegl_ioctl+0x1ea/0x250 [fglrx]
Jul 26 22:22:37 turion kernel: [ 34.649260] [<ffffffffa01690a1>] ? ip_firegl_ioctl+0x11/0x20 [fglrx]
Jul 26 22:22:37 turion kernel: [ 34.649307] [<ffffffff802f62ed>] ? vfs_ioctl+0x7d/0xa0
Jul 26 22:22:37 turion kernel: [ 34.649312] [<ffffffff8069804c>] ? thread_return+0x37/0x36b
Jul 26 22:22:37 turion kernel: [ 34.649318] [<ffffffff802f6655>] ? do_vfs_ioctl+0x75/0x230
Jul 26 22:22:37 turion kernel: [ 34.649321] [<fffff...

Read more...

Bryce Harrington (bryce) on 2009-08-13
tags: added: karmic
Dana Goyette (danagoyette) wrote :

hmm, I was mentioning the issue on IRC, and Kano told me to check in /usr/share/initramfs-tools/scripts/init-top/framebuffer
... and lo and behold, it's hardcoded to load i915:

       if modprobe -q intel_agp && modprobe -q i915; then
                FB=kms
        fi
        ;;

The so suggested that I change the conditional to "grep -q i915 /proc/modules", and add udev to PREREQ.

Perhaps we should change the description: "initramfs-tools framebuffer script loads i915 even when hardware not present"

Dana Goyette (danagoyette) wrote :

er, "the so" is me altering a sentence, and then getting sidetracked in the middle of it. Should be "He".

summary: - [Mobility Radeon HD] fglrx DRI initialization failed
+ initramfs scripts hard-coded to load i915; blocks loading fglrx

In reply to #9:
I applied 'aticonfig --acpi-services=off' (see bug 31460) and it helped me. Now module 'fglrx' is running even together with 'i915' and acceleration works well. Tested with kernels 2.6.28-13 and 2.6.31-9.

my configuration:
Ubuntu 9.10 Karmic, amd64
fglrx 8.660

Jaromir Obr (jaromir-obr) wrote :

I'm sorry, I meant bug 314600.

Kano (master-kanotix) wrote :

The used code is complete nonsense:

        if modprobe -q intel_agp && modprobe -q i915; then
                FB=kms
        fi
        ;;

The thing is: EVERY module can be modprobed and stays in memory and returns 0 exit status when the hardware is NOT present. It would get active if the hardware is hotplugged, which is very unlikely for a onboard vga card to happen. So the same would be:

modprobe -q intel_agp
modprobe -q i915
FB=kms

As the code should set the FB var to kms only when i915 is "correctly" loaded then you could wait for udev and then check if i915 is loaded. As soon as kms is active in the kernel config i915 has pci ids so udev will load it. intel-apg is always loaded by udev, no matter how the kernel is configured. Basically the same applies to radeon module, so maybe think of a better check, but the modprobe is definitely completely useless and wrong for other hardware.

The code snippet above is causing a lot of issues for ati, nvidia, and other non-intel graphics users (I've marked some other bugs as duplicates of this one because the root problem is in initramfs). Someone please mark this as a high priority bug.

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
summary: - initramfs scripts hard-coded to load i915; blocks loading fglrx
+ initramfs scripts hard-coded to load i915; blocks loading non-intel drm
+ modules
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Medium
tags: added: ubuntu-boot

We shouldn't modprobe like this at all. udev will load that module automatically anyway (and load the right ATI one instead if they don't have i915)

my post-α6 usplash changes should address this

Changed in fglrx-installer (Ubuntu Karmic):
status: Confirmed → Invalid

Setting to high as seems to keep services from loading.

Alberto - any thoughts or status.

Changed in initramfs-tools (Ubuntu Karmic):
importance: Medium → High
assignee: nobody → Alberto Milone (albertomilone)

Rick, did you intend to steal this bug? I've already said that I'm working on this

Changed in initramfs-tools (Ubuntu Karmic):
assignee: Alberto Milone (albertomilone) → Scott James Remnant (scott)

The fglrx driver version included in current Karmic (8.660) works even when i915 is loaded. This bug should no longer occur with current Karmic. Note that the current Catalyst release (9.9 based on 8.65) is still affected by this problem though.

I just wanted to reiterate the workaround (via blacklisting) as I had in a duplicate bug -
Workaround by blacklisting:
Create a file (with your favorite plain-text editor, and root permissions) in /etc/modprobe.d/. Call it blacklist-intel.conf and copy/paste the following two lines:
blacklist i915
blacklist intel_agp

Now, run:
sudo update-initramfs -u

A restart is necessary for the change to take effect.

Changed in initramfs-tools (Ubuntu Karmic):
milestone: none → ubuntu-9.10-beta
Changed in initramfs-tools (Ubuntu Karmic):
importance: High → Critical
Steve Langasek (vorlon) wrote :

My understanding is that this only affects systems that have /usr/share/initramfs-tools/scripts/init-top/framebuffer in the initramfs, which as of alpha 6 only happens to systems that have cryptsetup installed. Should this bug really be regarded as a critical beta blocker in that case? Or have I missed other reasons why this bug would be affecting people?

ibotty (ibotty) wrote :

the question if this is a critical beta blocker or not depends on your understanding of importance of cryptography. i would strongly oppose any (desktop) distribution that does not have working X with encrypted disks.

Changed in initramfs-tools (Ubuntu Karmic):
importance: Critical → High

Things found out so far:

 1. The mystery of what loads the fbcon driver on i915 systems without cryptsetup has been solved, the intel Xorg driver hardcodes a "modprobe fbcon" into it

 2. The fbcon driver needs to be loaded when you have a framebuffer, but can't just be a "depends" of the modules since the KMS ones (i915, radeon, etc.) allow mode setting to be optional. A simple fix for this is a udev rule in 80-drivers.rules with the others:

        SUBSYSTEM=="graphics", RUN+="/sbin/modprobe -b fbcon"

 3. hooks/kernelextras could probably be massively simplified to just add the kms modules, it should not "force_load fbcon" and should just add it

 4. vesafb is in a special /initrd directory, this can probably go away and be replaced by a manual_add_modules in hooks/kernelextras

 5. scripts/init-top/framebuffer can mostly just go away, we should let udev load the graphics driver and thus fbcon

Unsolved things:

 a. How should we load usplash when it's included in the initramfs? If we do this on a udev rule, that's fair enough.

 b. But then, how do we load vesafb if we don't have a different graphics driver?

Solved unsolved things:

 - have the framebuffer script still handle vga=* video=*, and if neither are specified have it check for a udev-loaded driver and otherwise load vesafb

 - then we can just load usplash from a hook as before

Richard Hansen (rhansen) wrote :

Somewhat off topic, but isn't uvesafb preferred over vesafb?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.92bubuntu50

---------------
initramfs-tools (0.92bubuntu50) karmic; urgency=low

  LP: #392039, #431812.
  * hooks/framebuffer:
    - rename from hooks/kernelextras, this is much more descriptive and
      actually matches the associated script
    - copy kernel-mode-setting drivers (drivers/gpu) into the initramfs
    - include the vesafb driver, which we previously relied on being in
      the special initrd directory
    - don't force load fbcon
    - don't force load things from the initrd directory
  * scripts/init-top/framebuffer:
    - add udev as a pre-requisite
    - remove mknods since udev will make those now
    - remove intel_agp and i915 code
    - don't unset MODPROBE_OPTIONS, just override for the modprobe call
      (since we want video= to override the blacklist)
    - if we didn't pick up a framebuffer from vga= or video=, and don't
      have one from udev, wait for udev to finish then if we still don't
      have one, load vesafb
    - settle after loading drivers to ensure the device is ready
  * debian/control:
    - increase dependency on udev to that which loads fbcon
    - add breaks on older usplash to force upgrade

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:25:00 -0700

Changed in initramfs-tools (Ubuntu Karmic):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udev - 147~-5

---------------
udev (147~-5) karmic; urgency=low

  * debian/udev.initramfs-top:
    - Rename from udev.initramfs-bottom and move from local-premount to
      init-top
    - Add a pre-requisite on all_generic_ide so that gets a chance before
      we load IDE devices.
  * rules/rules.d/80-drivers.rules:
    - load the fbcon driver when a framebuffer is created.
      LP: #392039, #431812.

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:22:52 -0700

Changed in udev (Ubuntu Karmic):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package usplash - 0.5.38

---------------
usplash (0.5.38) karmic; urgency=low

  LP: #392039, #431812.
  * debian/control:
    - increase dependency on initramfs-tools for new framebuffer handling
  * initramfs/hooks/usplash:
    - change pre-requisite to framebuffer
  * initramfs/scripts/init-top/usplash:
    - remove mknod and modprobe calls now udev takes care of that

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:27:10 -0700

Changed in usplash (Ubuntu Karmic):
status: New → Fix Released
Changed in initramfs-tools (Ubuntu Karmic):
status: Fix Released → Fix Committed
Changed in initramfs-tools (Ubuntu Karmic):
status: Fix Committed → Fix Released
sky (my-free-space-2006) on 2009-11-05
Changed in fglrx-installer (Ubuntu):
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers