[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#550392: marked as done (firmware-linux: Radeon kernel modesetting requires pre-initramfs firmware loading)

Your message dated Sat, 10 Oct 2009 00:24:49 +0100
with message-id <1255130689.25061.11.camel@localhost>
and subject line Re: Bug#550392: firmware-linux: Radeon kernel modesetting requires pre-initramfs firmware loading
has caused the Debian Bug report #550392,
regarding firmware-linux: Radeon kernel modesetting requires pre-initramfs firmware loading
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
550392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550392
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: firmware-linux
Version: 0.18
Severity: wishlist
Tags: patch

(Yes I know, I'm way ahead of the curve. Since I had to tackle this problem, I figured I might just as well publish my results)

Starting with kernel 2.6.32, the radeon in-kernel driver will stall the boot process while waiting for the microcode to be supplied. The 2.6.31 kernel did not do this (was it in-kernel before?). I'm using kernel modesetting, and have not tried the non-kms case but I suspect it will stall as well (but maybe later in the boot process). Entries in dmesg look like:

[    0.316326] [drm] Loading R300 Microcode
[    0.316332] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
[   60.316136] radeon_cp: Failed to load firmware "radeon/R300_cp.bin"
[   60.316177] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[...]
[   60.318534] [drm] Forcing AGP to PCI mode
[   60.318847] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
[...]
[   60.319458] [drm] Loading R300 Microcode
[   60.319463] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
[  120.316114] radeon_cp: Failed to load firmware "radeon/R300_cp.bin"
[  120.316156] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[  120.316194] radeon 0000:01:00.0: failled initializing CP (-2).
[  120.316230] radeon 0000:01:00.0: Disabling GPU acceleration

So the machine will appear to hang for two minutes. The regular firmware loading sequences do not appear to work when KMS is enabled (radeon.modeset=1), because the kernel will only try to load this firmware once: before running /init !

This means that even when the firmware and the udev firmware agent are available in the initramfs, the firmware load will fail because /sys isn't mounted yet. And without /sys, there is no way to abort the firmware load either.

I'm attaching the script I use to get around this issue. Basically, what I'm doing is reproducing part of the initialization performed by /init before spawning the Udev firmware agent. I'm not really sure what to do about /sys though: the current implementation introduces a race condition where /sys might get unmounted after /init has run. It might be better to just leave /sys mounted and have /init mount it again, but I'm not sure about the implications (my tests showed no negative consequences). This script must be installed as /sbin/hotplug - no code has run yet to alter the path to the hotplug event manager...

I'm filing this against firmware-linux because that's where the Radeon firmware lives. If there is a better place where this should be fixed, please feel free to redirect. And if you already have a better solution in place, feel free to ignore me :)


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (800, 'testing'), (550, 'stable'), (101, 'unstable'), (100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-rc3 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

firmware-linux depends on no packages.

firmware-linux recommends no packages.

Versions of packages firmware-linux suggests:
ii  initramfs-tools               0.93.4     tools for generating an initramfs
ii  linux-image-2.6.30-2-686 [lin 2.6.30-8   Linux 2.6.30 image on PPro/Celeron
ii  linux-image-2.6.31-rc9 [linux 20090909   Linux kernel binary image for vers
ii  linux-image-2.6.32-rc3 [linux 20091008   Linux kernel binary image for vers

-- no debconf information

#!/bin/sh
#
## Simple firmware hotplug handler. When kernel modesetting is enabled for ATi
## Radeon graphics cards, the firmware load is triggered even before running
## /init (but still after initramfs is unpacked). This means that the hotplug
## script itself becomes responsible for mounting /sys, because otherwise the
## firmware can't be loaded.
## Ignoring the firmware request is not an option - the kernel will simply keep
## waiting for data until the timeout has passed, which is 60 seconds by
## default. Aborting the firmware load can be performed by echo'ing -1 to the
## firmware control file, but that also requires /sys to be mounted.

# no console - messages won't be visible
#echo "HOTPLUG Loading, please wait..."


# only respond to firmware requests
if [ -n "$FIRMWARE" ]; then
	MTSYS=
	[ -d /sys ] || mkdir /sys
	[ -d /sys/kernel ] || MTSYS=1
	[ -z "$MTSYS" ] || mount -t sysfs -o nodev,noexec,nosuid none /sys

	# try the udev firmware loader first
	if [ -x /lib/udev/firmware.agent ]; then
		. /lib/udev/firmware.agent
	else
		# poor-man's loader script
		if [ -r /lib/firmware/$FIRMWARE ]; then
			echo 1 > /sys/$DEVPATH/loading
			cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
			echo 0 > /sys/$DEVPATH/loading
		else
			echo -1 > /sys/$DEVPATH/loading
		fi
	fi
	# perform cleanup so as not to confuse /init
	[ -z "$MTSYS" ] || umount /sys
fi


exit 0

--- End Message ---
--- Begin Message --- 
On Fri, 2009-10-09 at 21:25 +0200, Arno Schuring wrote:
> Package: firmware-linux
> Version: 0.18
> Severity: wishlist
> Tags: patch
> 
> (Yes I know, I'm way ahead of the curve. Since I had to tackle this
> problem, I figured I might just as well publish my results)
> 
> Starting with kernel 2.6.32, the radeon in-kernel driver will stall
> the boot process while waiting for the microcode to be supplied. The
> 2.6.31 kernel did not do this (was it in-kernel before?).

We separated the firmware starting in 2.6.29-1, and this change was
accepted upstream for 2.6.32.

> I'm using kernel modesetting, and have not tried the non-kms case but
> I suspect it will stall as well (but maybe later in the boot process).

If KMS is not used, radeon would not normally be loaded until the X
server started.  But it seems you are building this driver in.

[...]
> So the machine will appear to hang for two minutes. The regular
> firmware loading sequences do not appear to work when KMS is enabled
> (radeon.modeset=1), because the kernel will only try to load this
> firmware once: before running /init !

If you build the driver in, you may need to build the firmware in too
(CONFIG_FIRMWARE_IN_KERNEL=y).

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: