Bug 609607

This sounds again like radeon KMS isn't initialized in time before X gets started. radeon driver without KMS doesn't seem to work (radeon.modeset=0). 

Sure, that radeon module gets added to the initrd. Please run 'mkinitrd' and
add the output as comment to this bugzilla.

hello,

here it is:
Kernel image:   /boot/vmlinuz-2.6.34-8-default
Initrd image:   /boot/initrd-2.6.34-8-default
KMS drivers:    intel-agp radeon

thanks

Hmm. So radeon module gets added to initrd. Maybe in initrd something is missing
which then is available in system. Could you attach your /var/log/boot.msg?

(In reply to comment #3)
> Hmm. So radeon module gets added to initrd. Maybe in initrd something is
> missing
> which then is available in system. Could you attach your /var/log/boot.msg?

Of course with KMS enabled.

Then boot with KMS disabled into runlevel 3, login and run 'modprobe radeon'.
Afterwards attach the lines in /var/log/messages when the kernel module gets
loaded.

Maybe there is a significant difference.

i have booted with radeon.modeset=0 and here it is:

May 28 08:54:43 linux kernel: [  358.312984] [drm] Initialized drm 1.1.0 20060810
May 28 08:54:43 linux kernel: [  358.660116] pci 0000:01:00.0: power state changed by ACPI to D0
May 28 08:54:43 linux kernel: [  358.660130] pci 0000:01:00.0: power state changed by ACPI to D0
May 28 08:54:43 linux kernel: [  358.660141] pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
May 28 08:54:43 linux kernel: [  358.660147] pci 0000:01:00.0: setting latency timer to 64
May 28 08:54:43 linux kernel: [  358.660379] [drm] Initialized radeon 1.33.0 20080528 for 0000:01:00.0 on minor 0

sorry i have forgotten to post it with modeset=1... so here it is:

May 28 17:40:11 linux kernel: [  127.200539] [drm] Initialized drm 1.1.0 20060810
May 28 17:40:11 linux kernel: [  127.559519] [drm] radeon kernel modesetting enabled.
May 28 17:40:11 linux kernel: [  127.559612] radeon 0000:01:00.0: power state changed by ACPI to D0
May 28 17:40:11 linux kernel: [  127.559623] radeon 0000:01:00.0: power state changed by ACPI to D0
May 28 17:40:11 linux kernel: [  127.559634] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
May 28 17:40:11 linux kernel: [  127.559640] radeon 0000:01:00.0: setting latency timer to 64
May 28 17:40:11 linux kernel: [  127.562309] [drm] initializing kernel modesetting (RV410 0x1002:0x5653).
May 28 17:40:11 linux kernel: [  127.568731] [drm] register mmio base: 0xC8100000
May 28 17:40:11 linux kernel: [  127.568735] [drm] register mmio size: 65536
May 28 17:40:11 linux kernel: [  127.568888] ATOM BIOS: Quanta/Acer
May 28 17:40:11 linux kernel: [  127.569108] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
May 28 17:40:11 linux kernel: [  127.569119] [drm] 3 Power State(s)
May 28 17:40:11 linux kernel: [  127.569121] [drm] State 0 Battery 
May 28 17:40:11 linux kernel: [  127.569123] [drm] 	1 PCIE Lanes
May 28 17:40:11 linux kernel: [  127.569125] [drm] 	1 Clock Mode(s)
May 28 17:40:11 linux kernel: [  127.569128] [drm] 		0 engine/memory: 105000/120000
May 28 17:40:11 linux kernel: [  127.569130] [drm] State 1 Battery 
May 28 17:40:11 linux kernel: [  127.569132] [drm] 	1 PCIE Lanes
May 28 17:40:11 linux kernel: [  127.569133] [drm] 	1 Clock Mode(s)
May 28 17:40:11 linux kernel: [  127.569135] [drm] 		0 engine/memory: 210000/183000
May 28 17:40:11 linux kernel: [  127.569138] [drm] State 2 Default (default)
May 28 17:40:11 linux kernel: [  127.569140] [drm] 	16 PCIE Lanes
May 28 17:40:11 linux kernel: [  127.569141] [drm] 	1 Clock Mode(s)
May 28 17:40:11 linux kernel: [  127.569143] [drm] 		0 engine/memory: 358000/345000
May 28 17:40:11 linux kernel: [  127.569155] [drm] radeon: power management initialized
May 28 17:40:11 linux kernel: [  127.569159] [drm] Generation 2 PCI interface, using max accessible memory
May 28 17:40:11 linux kernel: [  127.569165] radeon 0000:01:00.0: VRAM: 128M 0xD0000000 - 0xD7FFFFFF (128M used)
May 28 17:40:11 linux kernel: [  127.569169] radeon 0000:01:00.0: GTT: 512M 0xB0000000 - 0xCFFFFFFF
May 28 17:40:11 linux kernel: [  127.569239] [drm] radeon: irq initialized.
May 28 17:40:11 linux kernel: [  127.569772] [drm] Detected VRAM RAM=128M, BAR=128M
May 28 17:40:11 linux kernel: [  127.569776] [drm] RAM width 128bits DDR
May 28 17:40:11 linux kernel: [  127.569881] [TTM] Zone  kernel: Available graphics memory: 441920 kiB.
May 28 17:40:11 linux kernel: [  127.569884] [TTM] Zone highmem: Available graphics memory: 1035076 kiB.
May 28 17:40:11 linux kernel: [  127.569905] [drm] radeon: 128M of VRAM memory ready
May 28 17:40:11 linux kernel: [  127.569907] [drm] radeon: 512M of GTT memory ready.
May 28 17:40:11 linux kernel: [  127.569931] [drm] GART: num cpu pages 131072, num gpu pages 131072
May 28 17:40:11 linux kernel: [  127.572296] [drm] PCIE GART of 512M enabled (table at 0xD0040000).
May 28 17:40:11 linux kernel: [  127.572306] [drm] radeon: 2 quad pipes, 1 z pipes initialized.
May 28 17:40:11 linux kernel: [  127.572314] [drm] radeon: cp idle (0x10000C03)
May 28 17:40:11 linux kernel: [  127.572363] [drm] Loading R400 Microcode
May 28 17:40:11 linux kernel: [  127.572367] platform radeon_cp.0: firmware: requesting radeon/R420_cp.bin
May 28 17:40:11 linux kernel: [  127.948906] [drm] radeon: ring at 0x00000000B0000000
May 28 17:40:11 linux kernel: [  127.948930] [drm] ring test succeeded in 1 usecs
May 28 17:40:11 linux kernel: [  127.949106] [drm] radeon: ib pool ready.
May 28 17:40:11 linux kernel: [  127.949171] [drm] ib test succeeded in 0 usecs
May 28 17:40:11 linux kernel: [  127.949222] [drm] Default TV standard: NTSC
May 28 17:40:11 linux kernel: [  127.949342] [drm] Default TV standard: NTSC
May 28 17:40:11 linux kernel: [  127.949416] [drm] Radeon Display Connectors
May 28 17:40:11 linux kernel: [  127.949418] [drm] Connector 0:
May 28 17:40:11 linux kernel: [  127.949419] [drm]   VGA
May 28 17:40:11 linux kernel: [  127.949422] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
May 28 17:40:11 linux kernel: [  127.949424] [drm]   Encoders:
May 28 17:40:11 linux kernel: [  127.949426] [drm]     CRT1: INTERNAL_DAC1
May 28 17:40:11 linux kernel: [  127.949428] [drm] Connector 1:
May 28 17:40:11 linux kernel: [  127.949430] [drm]   LVDS
May 28 17:40:11 linux kernel: [  127.949432] [drm]   DDC: 0x1a8 0x1a8 0x1ac 0x1ac 0x1b0 0x1b0 0x1b4 0x1b4
May 28 17:40:11 linux kernel: [  127.949434] [drm]   Encoders:
May 28 17:40:11 linux kernel: [  127.949436] [drm]     LCD1: INTERNAL_LVDS
May 28 17:40:11 linux kernel: [  127.949438] [drm] Connector 2:
May 28 17:40:11 linux kernel: [  127.949440] [drm]   S-video
May 28 17:40:11 linux kernel: [  127.949441] [drm]   Encoders:
May 28 17:40:11 linux kernel: [  127.949443] [drm]     TV1: INTERNAL_DAC2
May 28 17:40:11 linux kernel: [  127.949445] [drm] Connector 3:
May 28 17:40:11 linux kernel: [  127.949446] [drm]   DVI-I
May 28 17:40:11 linux kernel: [  127.949448] [drm]   HPD1
May 28 17:40:11 linux kernel: [  127.949450] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
May 28 17:40:11 linux kernel: [  127.949452] [drm]   Encoders:
May 28 17:40:11 linux kernel: [  127.949454] [drm]     DFP1: INTERNAL_TMDS1
May 28 17:40:12 linux kernel: [  128.238259] [drm] fb mappable at 0xD00C0000
May 28 17:40:12 linux kernel: [  128.238262] [drm] vram apper at 0xD0000000
May 28 17:40:12 linux kernel: [  128.238264] [drm] size 4096000
May 28 17:40:12 linux kernel: [  128.238266] [drm] fb depth is 24
May 28 17:40:12 linux kernel: [  128.238267] [drm]    pitch is 5120
May 28 17:40:12 linux kernel: [  128.238273] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
May 28 17:40:12 linux kernel: [  128.238394] Console: switching to colour dummy device 80x25
May 28 17:40:12 linux kernel: [  128.631205] bootsplash: scaling image from 1024x768 to 1280x800
May 28 17:40:12 linux kernel: [  128.763403] Console: switching to colour frame buffer device 160x50
May 28 17:40:12 linux kernel: [  128.792035] fb0: radeondrmfb frame buffer device
May 28 17:40:12 linux kernel: [  128.792040] registered panic notifier
May 28 17:40:12 linux kernel: [  128.792053] [drm] Initialized radeon 2.3.0 20080528 for 0000:01:00.0 on minor 0

Sorry, what I need is the following. 

1) loading the radeon with KMS after boot (in runlevel 3)
2) loading the radeon with KMS during boot

For 2) there is /var/log/boot.msg. Not sure whether you already added that in one of your comments. Boot with radeon.modeset=1.

For 1) we need to make sure that radeon is not in the initrd. For that you need to set NO_KMS_IN_INITRD="yes" in /etc/sysconfig/kernel, then recreated initrd
with mkinitrd. After boot into runlevel 3 run 'modprobe radeon modeset=1'.
Then copy the appropriate lines of /var/log/messages to Bugzilla.

hmm!? it`s a live cd! and it is my production system.

so it is a problem to set sysconfig-Variable and then to reboot.

i will try to make a backup at the weekend. 

i try to post the answer on monday, ok?

Ah. It's a LiveCD. Then KMS cannot work since none of the KMS kernel modules (intel, radeon, nouveau) is included in the initrd of the LiveCD. It would be possible only for intel, since there the agp kernel module (intel-agp) is predefined. For nouveau/radeon it depends on the mainboard chipset.

Alex, I would like to know how other Linux distributions handle the issue, that
radeon kernel module isn't initialized in time when not already loaded in initrd.

but should it not work without kms??

init 5 with modeset=0 shows a black screen!!?!

Yes, but apparently the UMS support is broken.

ok! if i can help! please tell me!

(In reply to comment #9)
> Alex, I would like to know how other Linux distributions handle the issue, that
> radeon kernel module isn't initialized in time when not already loaded in
> initrd.

You need to include the modules in the initrd.  You need radeon and and the drm
modules (and fbcon if you want console at boot) and for AGP cards, you need the
AGP modules.  If you didn't want to include the AGP modules, you could force
radeon to use the on-chip gart by passing radeon.agpmode=-1 on the kernel
command line.

(In reply to comment #13)
> (In reply to comment #9)
> You need to include the modules in the initrd.  You need radeon and and the 
> drm modules (and fbcon if you want console at boot) 

AFAICS that would be drm, drm_kms_helper, i915, nouveau, radeon.

> and for AGP cards, you need the AGP modules.  

And that would be intel-agp, sis-agp, via-agp. 

The issue is that there are no deps from the drm to the appropriate agp module. In an installed system the required agp module is loaded automatically during boot. Then afterwards the drm module once the Xserver gets started. 

Since that's not possible in initrd Egbert patched mkinitrd in a way that the correct agp/drm module gets loaded in initrd. But that doesn't work for a LiveCD due to obvious reasons.

> If you didn't want to include the AGP modules, you could force
> radeon to use the on-chip gart by passing radeon.agpmode=-1 on the kernel
> command line.

That would be something for Tobias to try. And Alex, do you happen to know
how Fedora/Ubuntu resolve that timing issue with radeon with their LiveCD? 
BTW, we've never seen that timing issue with nouveau.

if i should try something, you have to explain me detailed what to do. Because my english isn`t very good and my linux knowledge is so lala! :-)

I thought you could try LiveCD with radeon.agpmode=-1, but this is not going to work since radeon module isn't included in the initrd of our LiveCD. So just forgot about what I said. Nothing to test for you at the moment.

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #9)
> > You need to include the modules in the initrd.  You need radeon and and the 
> > drm modules (and fbcon if you want console at boot) 
> 
> AFAICS that would be drm, drm_kms_helper, i915, nouveau, radeon.
> 
> And that would be intel-agp, sis-agp, via-agp. 

yes. and fbcon for console on the fbdev provided by the drm.

> 
> The issue is that there are no deps from the drm to the appropriate agp module.
> In an installed system the required agp module is loaded automatically during
> boot. Then afterwards the drm module once the Xserver gets started. 
> 
> Since that's not possible in initrd Egbert patched mkinitrd in a way that the
> correct agp/drm module gets loaded in initrd. But that doesn't work for a
> LiveCD due to obvious reasons.

I'm not following.  What's the problem with including them in the initrd?

> 
> > If you didn't want to include the AGP modules, you could force
> > radeon to use the on-chip gart by passing radeon.agpmode=-1 on the kernel
> > command line.
> 
> That would be something for Tobias to try. And Alex, do you happen to know
> how Fedora/Ubuntu resolve that timing issue with radeon with their LiveCD? 
> BTW, we've never seen that timing issue with nouveau.

x700 mobility cards are pcie so agp is not used at all.  Other distros just
include the drm and agp modules in the initrd that they can be loaded at boot
time as needed.

> I'm not following.  What's the problem with including them in the initrd?

The correct agp/drm module combination wouldn't be loaded in initrd. Also they
need to be loaded in the right order. First agp, then drm.

> x700 mobility cards are pcie so agp is not used at all.  Other distros just
> include the drm and agp modules in the initrd that they can be loaded at boot
> time as needed.

Thanks for letting us know this. Not sure how they make sure the right agp/drm
module in the right order are loaded though.

Need to continue the discussion with Egbert/Matthias on monday.

(In reply to comment #18)
> > I'm not following.  What's the problem with including them in the initrd?
> 
> The correct agp/drm module combination wouldn't be loaded in initrd. Also they
> need to be loaded in the right order. First agp, then drm.
> 

The proper agp modules should load based on the agp bridge pci ids, so there shouldn't be any issue with needing to know what agp module before hand. (as a side note, you'll also need amd64-agp for 64-bit AMD platforms with agp).  Also, I haven't looked at the agp code in a while, but IIRC, I think the drm will request the agp module if it hasn't loaded yet.

> The proper agp modules should load based on the agp bridge pci ids, so there
> shouldn't be any issue with needing to know what agp module before hand. 

This is news to me.

> (as a side note, you'll also need amd64-agp for 64-bit AMD platforms with 
> agp). 

That one appears to be compiled into the kernel.

> Also, I haven't looked at the agp code in a while, but IIRC, I think the drm
> will request the agp module if it hasn't loaded yet.

My experience has always been that this is *not* the case.

(In reply to comment #20)
> > The proper agp modules should load based on the agp bridge pci ids, so there
> > shouldn't be any issue with needing to know what agp module before hand.

The order is still undefined. The dri modules cannot depend on the agp module, because the right agp module doesn't depend on the drm vendor, but on the north bridge vendor.

> > Also, I haven't looked at the agp code in a while, but IIRC, I think the drm
> > will request the agp module if it hasn't loaded yet.
> 
> My experience has always been that this is *not* the case.

I'm unsure whether that is even possible. Only udev knows which agp module is to be loaded. Except for if you try all of them.

Alex, don't you still "need" agpgart for setting up GART memory for additional texture space, even with PCIe cards? Not strictly required for operation, but helpful?

(In reply to comment #21)

> Alex, don't you still "need" agpgart for setting up GART memory for additional
> texture space, even with PCIe cards? Not strictly required for operation, but
> helpful?

agpgart is only needed for AGP cards.  The internal non-AGP gart mechanisms (pci/pcie/igp) are handled completely within the radeon drm.

This is not the case for the intel driver. I'm currently trying to understand, why or rather how this works on other distributions. The drm driver does NOT have the agpgart module as prerequisite, but doesn't work if the agpgart is not loaded before.

I see three possibilities:
- It works by coincidence (agpgart is just loaded before drm)
- There is some mechanism designed for loading agp before drm (like we have ATM)
- All agpgart modules are compiled into the kernel

Testing...

(In reply to comment #23)
> - All agpgart modules are compiled into the kernel

Fedora 13 is using this method.

The following steps have to be taken to create a live CD:

- Egbert's mkinitrd scriptlet has to be blown up to include *all* agp modules
  and *all* drm modules (including firmwares)
- The udev rule 79-kms.rules that prohibits loading of the drm module has to be
  nuked
- Egbert's boot script 05-kms.sh that is called *after* udev has to be replaced
  by a script that's called *before* udev and just loads *all* agp modules.
  Which basically resembles a kernel that has all agp modules built in

Then the right drm module will be loaded by udev, and agp will already be active by then.

Coolo, what is different between live CDs and a regular installation? Which steps are done differently? I know that the mkinitrd is created in a different way, but how so?

I'd like to hve a solution that works for live CDs but does not break regular installations...

the live cd of the live cds are done by kiwi. More I can't really say - you need to talk to the maintainers of kiwi and mkinitrd.

Oh well.

(In reply to comment #27)
> the live cd of the live cds are done by kiwi. More I can't really say - you
> need to talk to the maintainers of kiwi and mkinitrd.

Thanks. Adding Marcus/Micha. Marcus/Micha, can you share us more details in which way initrd is created differently for LiveCD?

AFAIK kiwi has it's own mkinitrd variant.

(In reply to comment #25)
> The following steps have to be taken to create a live CD:
> 
> - Egbert's mkinitrd scriptlet has to be blown up to include *all* agp modules
>   and *all* drm modules (including firmwares)
> - The udev rule 79-kms.rules that prohibits loading of the drm module has to
>   be nuked
> - Egbert's boot script 05-kms.sh that is called *after* udev has to be 
>   replacedby a script that's called *before* udev and just loads *all* agp 
>   modules. Which basically resembles a kernel that has all agp modules built 
>   in
> 
> Then the right drm module will be loaded by udev, and agp will already be
> active by then.

Ok. Since it's to late for 11.3 meanwhile. For openSUSE > 11.3 let's do the Fedora way and make sure that all agpgart modules are compiled *into* the kernel. Additionally

- Egbert's mkinitrd scriptlet has to be blown up to include *all* drm modules 
  (including firmwares)
- The udev rule 79-kms.rules that prohibits loading of the drm module has to
  be nuked

*** Bug 627097 has been marked as a duplicate of this bug. ***

I've enabled the AGP modules on x86/x86_64.

(In reply to comment #33)
> I've enabled the AGP modules on x86/x86_64.

Means agp drivers are now builtin. Thanks, Jeff!

*** Bug 649973 has been marked as a duplicate of this bug. ***

(In reply to comment #33)
> I've enabled the AGP modules on x86/x86_64.

Jeff, sure that you did this also for i586? I'm running 2.6.37-rc3-git1-4-pae
from Kernel:HEAD / openSUSE_11.3 and I still agp kernel modules

# zcat /proc/config.gz |grep -i agp
CONFIG_AGP=y
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=m

*** Bug 656897 has been marked as a duplicate of this bug. ***

Jeff?

Ok, for x86_64-desktop:
desktop:CONFIG_AGP=y
desktop:CONFIG_AGP_AMD64=y
desktop:CONFIG_AGP_INTEL=y
desktop:CONFIG_AGP_SIS=y
desktop:CONFIG_AGP_VIA=y

For i386-desktop:
desktop:CONFIG_AGP=y
desktop:CONFIG_AGP_ALI=m
desktop:CONFIG_AGP_ATI=m
desktop:CONFIG_AGP_AMD=m
desktop:CONFIG_AGP_AMD64=y
desktop:CONFIG_AGP_INTEL=y
desktop:CONFIG_AGP_NVIDIA=m
desktop:CONFIG_AGP_SIS=y
desktop:CONFIG_AGP_SWORKS=m
desktop:CONFIG_AGP_VIA=y
desktop:CONFIG_AGP_EFFICEON=m


I think the issue was that I changed the ones on x86_64 and copied the changes to i386, which has more options. A bunch of them depend on X86_32.


Which of these are actually needed to be static on i386?

Thanks for the detailed question. Any agp driver needs to be static, also on i586.
Is that an issue? Build failures, whatever? Then we can discuss about the less important drivers.

Jeff, any questions remaining?

Egbert, could you take care about the remaining topics?

- Egbert's mkinitrd scriptlet has to be blown up to include *all* drm modules 
  (including firmwares)
- The udev rule 79-kms.rules that prohibits loading of the drm module has to
  be nuked

Egbert, we talked about that one this morning. :-)

I thought I'd changed these options already, but it seems I didn't. They're fixed on Factory now.

(In reply to comment #42)
> Egbert, could you take care about the remaining topics?
> 
> - Egbert's mkinitrd scriptlet has to be blown up to include *all* drm modules 
>   (including firmwares)

60644  State:new        By:sndirsch     When:2011-02-12T13:50:27
        submit:         home:sndirsch:branches:Base:System/mkinitrd  ->
                        Base:System
        Descr: - scripts/setup-kms.sh: add all KMS modules to initrd 
                 (bnc #609607, comment #42) 

> - The udev rule 79-kms.rules that prohibits loading of the drm module has to
>   be nuked

60643  State:new        By:sndirsch     When:2011-02-12T13:50:22
        submit:         home:sndirsch:branches:Base:System/udev  -> 
                        Base:System
        Descr: - removed 79-kms.rules (bnc #609607, comment #42) 

Frederic, if you could test my changes by building a new LiveCD, that would
be great.

Why *all* drm modules and not just the ones used on that system? BTW, the firmware dependencies are documented inside each module and mkinitrd handles those automatically.

(In reply to comment #46)
> Why *all* drm modules and not just the ones used on that system? 

You are aware of that we're talking about the LiveCD ?!?

> BTW, the firmware dependencies are documented inside each module and mkinitrd 
> handles those automatically.

Yes, this works fine. Therefore adding i915, radeon, and nouveau has been sufficient. :-)

(In reply to comment #45)
> (In reply to comment #42)
> > Egbert, could you take care about the remaining topics?
> > 
> > - Egbert's mkinitrd scriptlet has to be blown up to include *all* drm modules 
> >   (including firmwares)
> 
> 60644  State:new        By:sndirsch     When:2011-02-12T13:50:27
>         submit:         home:sndirsch:branches:Base:System/mkinitrd  ->
>                         Base:System
>         Descr: - scripts/setup-kms.sh: add all KMS modules to initrd 
>                  (bnc #609607, comment #42)

The LiveCD is created by kiwi, which uses its own mkinitd version, see comment 30. So patching the mkinitd package won't help here.

I guess someone needs to explain Marcus what to do. The kiwi configs have a hard coded list of modules, kms.sh does more afaik.

(In reply to comment #45)
> > - The udev rule 79-kms.rules that prohibits loading of the drm module has to
> >   be nuked
> 
> 60643  State:new        By:sndirsch     When:2011-02-12T13:50:22
>         submit:         home:sndirsch:branches:Base:System/udev  -> 
>                         Base:System
>         Descr: - removed 79-kms.rules (bnc #609607, comment #42) 

Meanwhile already accepted also for openSUSE:Factory. -:)

(In reply to comment #49)
> I guess someone needs to explain Marcus what to do. The kiwi configs have a
> hard coded list of modules, kms.sh does more afaik.

Thanks. I've contacted him meanwhile and he's going to patch kiwi accordingly
for openSUSE 11.4 (kiwi/system/boot/ix86/netboot/suse-11.4/config.xml).

Please forget aobut kms.sh. It has always been dead code, since "nomodeset" has a "special" meaning ..

My patch was for setup-kms.sh.

Closing as fixed for openSUSE 11.4 RC2.

This is an autogenerated message for OBS integration:
This bug (609607) was mentioned in
https://build.opensuse.org/request/show/47305 Factory / kernel-source
https://build.opensuse.org/request/show/58563 Factory / kernel-source