|
Bugzilla – Full Text Bug Listing |
| Summary: | mkinitrd: ATI firmware cannot be loaded by radeon module due to udevd not running yet | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Stefan Dirsch <sndirsch> |
| Component: | X.Org | Assignee: | Michal Marek <mmarek> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | eich, forgotten_Si7ddX0wxG, johann-nikolaus.andreae, jslaby, kkaempf, robin.knapp, sndirsch |
| Version: | Milestone 4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
mkinitrd-kms-firmware.diff
/var/log/messages |
||
|
Description
Stefan Dirsch
2010-04-13 17:47:58 UTC
So does it help to replace #%depends: start in /lib/mkinitrd/scripts/boot-kms.sh with #%depends: start udev ? Run mkinitrd_setup; mkinitrd afterwards. I'll try this tonight. But I'm not sure whether this might conflict with udev's automatic hw detection and might introduce new (timing) issues. Maybe this is no problem at all if the modules interpret "nomodeset" by themself For the automatic detection - I'm not sure what /lib/udev/rules.d/79-kms.rules does (prevent automatic loading?), but it's missing in initrd. Maybe related? You're right. With /lib/udev/rules.d/79-kms.rules missing in initrd and kms script running after udev script, the modules might be loaded in the wrong order, i.e. i915 might get loaded before intel-agp, which would be fatal. This is what we wanted to avoid. :-) Yes, it works. Without the udev rule it gets loaded by udev automatically; with the rule it gets loaded by the kms script after udev. It would be nice if the order of modules could be specified somehow using udev rules or modprobe.d config so it gets loaded automatically in the correct order, that would also automagically fix the live cd issue I mentioned in bug 595653 comment 23 Maybe something like this as a modprobe.d config file: install i915 /sbin/modprobe intel-agp; /sbin/modprobe --ignore-install i915 btw, is this really needed in the latest kernel? # grep i915 /lib/modules/$(uname -r)/modules.dep kernel/drivers/gpu/drm/i915/i915.ko: kernel/drivers/char/agp/intel-agp.ko ... Won't this force the correct order? Robin, you're right (again). The deps for i915 and intel-agp are meanwhile hardwired in the kernel modules by the symbol "intel_agp_enabled", defined as extern in i915 (drivers/gpu/drm/i915/i915_drv.c) and exported by intel_agp (drivers/char/agp/intel-agp.c). So this would work even on LiveCD - for Intel. Unfortunately it doesn't for ATI and NVIDIA. So I believe what needs to be done *here* is to move kms boot script behind udev boot script and add the kms udev rule (which prevents drm modules from loading) to initrd as well. Okay, I couldn't test it as my X600 Mobility seems to work without the agp driver. Well, it's a PCI-Express card, so that makes sense. So adding the KMS udev script and adding udev to the kms-boot.sh %depend line should work on all systems. Yes, exactly. :-) Created attachment 354863 [details] mkinitrd-kms-firmware.diff * loading firmware files for KMS modules needs udev; hence make sure that udev is started before loading KMS modules. But then we also need the KMS udev rule, so that the KMS is not accidently loaded before the appropriate agp module, which would be fatal. (bnc #596268) Michal, could you apply the patch to mkinitrd package. A changelog entry is given as well. Fixed by http://gitorious.org/opensuse/mkinitrd/commit/88b392abf6f2d98dee1b349856fdda370c545eb8 and submitted to Base:System. Any chance to submit it also for openSUSE::Factory after accpepting the SR? I'm asking since you're the maintainer of Base:System/mkinitrd. *** Bug 598014 has been marked as a duplicate of this bug. *** Confirmed. radeon/RS780_pfp.bin gets loaded in openSUSE 11.3 M5 after upgrading to mkinitrd-2.5.10-68.2.x86_64 from Base:System However, boot.msg now shows <3>[ 3.033332] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" <3>[ 3.033342] [drm:r600_startup] *ERROR* Failed to load firmware! (apparently without any ill effects ?!) A bit more concerning is the need for "selinux=0" during boot. But it might as well be related to running the M5 kernel. Lets see what M6 brings ;-) (In reply to comment #18) > Confirmed. radeon/RS780_pfp.bin gets loaded in openSUSE 11.3 M5 after upgrading > to mkinitrd-2.5.10-68.2.x86_64 from Base:System > > However, boot.msg now shows > <3>[ 3.033332] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" > <3>[ 3.033342] [drm:r600_startup] *ERROR* Failed to load firmware! > > (apparently without any ill effects ?!) Probably unrelated to being loaded in initrd. But you can double check by adding 'nomodeset 3' to kernel boot command line. Then unload "radeon" kernel module and reload it again manually via modrobe. (In reply to comment #19) > A bit more concerning is the need for "selinux=0" during boot. But it might as > well be related to running the M5 kernel. Lets see what M6 brings ;-) What happens if you don't use that option? (In reply to comment #20) > > Probably unrelated to being loaded in initrd. But you can double check by > adding 'nomodeset 3' to kernel boot command line. Then unload "radeon" kernel > module and reload it again manually via modrobe. Ok, will do in a moment. > > (In reply to comment #19) > > A bit more concerning is the need for "selinux=0" during boot. But it might as > > well be related to running the M5 kernel. Lets see what M6 brings ;-) > > What happens if you don't use that option? The kernel stops booting with a selinux privilege violation. (I couldn't capture the kernel msg :-() (In reply to comment #20) > > Probably unrelated to being loaded in initrd. But you can double check by > adding 'nomodeset 3' to kernel boot command line. Then unload "radeon" kernel > module and reload it again manually via modrobe. The 'radeon' module is not loaded after boot. modprobing it results in Apr 20 12:31:43 linux-lkbf kernel: [ 52.536362] [drm] Initialized drm 1.1.0 20060810 Apr 20 12:31:43 linux-lkbf kernel: [ 52.592933] [drm] VGACON disable radeon kernel modesetting. Apr 20 12:31:43 linux-lkbf kernel: [ 52.597777] pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 Apr 20 12:31:43 linux-lkbf kernel: [ 52.601959] pci 0000:01:05.0: setting latency timer to 64 Apr 20 12:31:43 linux-lkbf kernel: [ 52.602211] [drm] Initialized radeon 1.32.0 20080528 for 0000:01:05.0 on minor 0 (In reply to comment #20) > > What happens if you don't use that option? This is shown on the console boot/93-boot.sh: line 28: [: =: unary operator expected boot/93-boot.sh: line 34: [: =: unary operator expected Machine in enforcing mode and cannot execute load_policy To disable selinux, add selinux=0 to the kernel command line. Not continuing (In reply to comment #22) > (In reply to comment #20) > > > > Probably unrelated to being loaded in initrd. But you can double check by > > adding 'nomodeset 3' to kernel boot command line. Then unload "radeon" kernel > > module and reload it again manually via modrobe. > > The 'radeon' module is not loaded after boot. > > modprobing it results in > > Apr 20 12:31:43 linux-lkbf kernel: [ 52.536362] [drm] Initialized drm 1.1.0 > 20060810 > Apr 20 12:31:43 linux-lkbf kernel: [ 52.592933] [drm] VGACON disable radeon > kernel modesetting. I found that when booting with "nomodeset", loading the radeon module does not enable modesetting. Or maybe it's caused by the udev rules. Try this: modprobe --ignore-install radeon modeset=1 (In reply to comment #22) > The 'radeon' module is not loaded after boot. Weird. It should be loaded, just with KMS disabled. > modprobing it results in > > Apr 20 12:31:43 linux-lkbf kernel: [ 52.536362] [drm] Initialized drm 1.1.0 > 20060810 > Apr 20 12:31:43 linux-lkbf kernel: [ 52.592933] [drm] VGACON disable radeon > kernel modesetting. > Apr 20 12:31:43 linux-lkbf kernel: [ 52.597777] pci 0000:01:05.0: PCI INT A > -> GSI 18 (level, low) -> IRQ 18 > Apr 20 12:31:43 linux-lkbf kernel: [ 52.601959] pci 0000:01:05.0: setting > latency timer to 64 > Apr 20 12:31:43 linux-lkbf kernel: [ 52.602211] [drm] Initialized radeon > 1.32.0 20080528 for 0000:01:05.0 on minor 0 So no issues with loading ATI firmware? Sure that KMS is active? Verify with cat /sys/module/radeon/parameters/modeset 0 means disabled, 1 enabled, -1 default (i.e. KMS enabled). If it is 0 try with 'modprobe radeon modeset=1'. Do you now see any issues with loading the firmware? (In reply to comment #25) > > So no issues with loading ATI firmware? Sure that KMS is active? Verify with > > cat /sys/module/radeon/parameters/modeset > > 0 means disabled, 1 enabled, -1 default (i.e. KMS enabled). Its 0. > > If it is 0 try with 'modprobe radeon modeset=1'. Do you now see any issues with > loading the firmware? Nothing different from comment #18 Created attachment 355544 [details]
/var/log/messages
system messages from 'modprobe'ing radeon
(In reply to comment #23) > (In reply to comment #20) > > > > What happens if you don't use that option? > > This is shown on the console > > boot/93-boot.sh: line 28: [: =: unary operator expected > boot/93-boot.sh: line 34: [: =: unary operator expected > Machine in enforcing mode and cannot execute load_policy > To disable selinux, add selinux=0 to the kernel command line. > Not continuing I believe that's a differeent issue. Could you open a seperate bugreport for that? Thanks. (In reply to comment #26) > > If it is 0 try with 'modprobe radeon modeset=1'. Do you now see any issues > > withloading the firmware? > > Nothing different from comment #18 Ok. So it's unrelated to initrd. :-) (In reply to comment #28) > (In reply to comment #23) > > (In reply to comment #20) > > > > > > What happens if you don't use that option? > > > > This is shown on the console > > > > boot/93-boot.sh: line 28: [: =: unary operator expected > > boot/93-boot.sh: line 34: [: =: unary operator expected > > Machine in enforcing mode and cannot execute load_policy > > To disable selinux, add selinux=0 to the kernel command line. > > Not continuing > > I believe that's a differeent issue. Could you open a seperate bugreport for > that? Thanks. Done. bnc#598075 *** Bug 598126 has been marked as a duplicate of this bug. *** (In reply to comment #29) > (In reply to comment #26) > > > If it is 0 try with 'modprobe radeon modeset=1'. Do you now see any issues > > > withloading the firmware? > > > > Nothing different from comment #18 > > Ok. So it's unrelated to initrd. :-) Klaus, you have kernel-firmware installed, do you? iirc, no. But I have to check @home to be sure. (In reply to comment #33) > iirc, no. But I have to check @home to be sure. You don't? This would explain a lot. :-) (In reply to comment #34) > (In reply to comment #33) > > iirc, no. But I have to check @home to be sure. > > You don't? This would explain a lot. :-) Indeed, kernel-firmware was _not_ installed. How does this package get installed ? Which dependencies trigger its installation ? Hmm, installing kernel-firmware doesn't change anything from comment #18 Its still <6>[ 3.079877] [drm] Loading RS780 Microcode <6>[ 3.082330] platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin <6>[ 3.086042] platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin <6>[ 3.089781] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin <3>[ 3.093427] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" <3>[ 3.095796] [drm:r600_startup] *ERROR* Failed to load firmware! (radeon/R600_rlc.bin does not exist !) kernel-desktop already includes /lib/firmware/2.6.34-rc3-3-desktop/radeon/*, so kernel-firmware is apparently not needed. (In reply to comment #36) > Hmm, installing kernel-firmware doesn't change anything from comment #18 Did you remake your initrd? (In reply to comment #37) > kernel-desktop already includes /lib/firmware/2.6.34-rc3-3-desktop/radeon/*, so > kernel-firmware is apparently not needed. It is. I don't see a reason why we would need the firmware twice though. Indeed there are firmware files in /lib/firmware/2.6.34-rc4-4-desktop/radeon/ and /lib/firmware/radeon/, but apparenly two files are missing in /lib/firmware/2.6.34-rc4-4-desktop/radeon/. Apart from that the directories are identical. Only in /lib/firmware/radeon/: R600_rlc.bin Only in /lib/firmware/radeon/: R700_rlc.bin R600_rlc.bin is exactly the file you were missing. You need to run mkinitrd after installing the kernel-firmware package to add it to initrd. Otherwise it cannot be loaded from initrd. (In reply to comment #39) > Indeed there are firmware files in /lib/firmware/2.6.34-rc4-4-desktop/radeon/ > and /lib/firmware/radeon/, but apparenly two files are missing in > /lib/firmware/2.6.34-rc4-4-desktop/radeon/. Apart from that the directories are > identical. Ah, so this would qualify as a kernel packaging bug ?! > > Only in /lib/firmware/radeon/: R600_rlc.bin > Only in /lib/firmware/radeon/: R700_rlc.bin > > R600_rlc.bin is exactly the file you were missing. You need to run mkinitrd > after installing the kernel-firmware package to add it to initrd. Otherwise it > cannot be loaded from initrd. Yeah, sorry to overlook the obvious. Will recreate initrd and test again when I'm back home. (In reply to comment #40) > (In reply to comment #39) > > Indeed there are firmware files in /lib/firmware/2.6.34-rc4-4-desktop/radeon/ > > and /lib/firmware/radeon/, but apparenly two files are missing in > > /lib/firmware/2.6.34-rc4-4-desktop/radeon/. Apart from that the directories are > > identical. > > Ah, so this would qualify as a kernel packaging bug ?! Maybe. Please report the issue and let me know about the results (or add me to Cc). I even don't understand why we have (about) the same firmware files at two different locations ... *** Bug 597566 has been marked as a duplicate of this bug. *** (In reply to comment #40) > > Yeah, sorry to overlook the obvious. Will recreate initrd and test again when > I'm back home. Working fine now. All firmware files load properly and the console/bootsplash -> X11 switch is smooth. However, this display went dark after ~30 secs and the kernel oopsed (dead numlock). Fill file a separate bug for this :-/ (In reply to comment #41) > > Maybe. Please report the issue and let me know about the results (or add me to > Cc). I even don't understand why we have (about) the same firmware files at two > different locations ... Filed as bnc#598624 *** Bug 598869 has been marked as a duplicate of this bug. *** |