Correction from my earlier report: the required boot option is radeon.modeset=0 instead of ati.kms=0. 
Oops, my apologies. 

The rest remains correct.

The dvd contain just free rpm

Summary: corrupted video after installation => Add radeon-firmware in the Isos

An unusable machine in the default install is not very nice.

We usually don't include non-free software in the install DVD, but I think having an exception to allow including on the DVD the firmwares that are necessary to use some hardware would be a good idea. For the firmwares whose licences meet the following requirements :
https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware

CC: (none) => boklm

Created attachment 1124 [details]
the Radeon firmware license

This is the Radeon firmware license, (barring recent changes). 

I quote: "permission to install, reproduce, copy and distribute copies, in binary form only"

The only notable restriction is "No reverse engineering, decompilation, or disassembly of this Software is permitted." which may bother a very few hardware developers. 
Also the standard clause about keeping the license.

(In reply to comment #4)
> Created attachment 1124 [details]
> the Radeon firmware license
> 
> This is the Radeon firmware license, (barring recent changes). 
> 
> I quote: "permission to install, reproduce, copy and distribute copies, in
> binary form only"

The license does not allow modifications, so this is non-free. And current policy is to not include any non-free package on the DVD.

I do not dispute the firmware's place in nonfree: it is not. 
But it can be distributed, and the redistribution rights are transitive. 

To keep the distribution's "purity" is still possible, but with the
Debian-style workarounds (external media for the required firmware, for
example). If no firmware is installed, the bootloader should also add the
radeon.modeset=0 option automatically: it is necessary for each and every
AMD/ATI video card. 

I would very much prefer the firmware to be included (less hassle). 
There will also be less noise about unusable computers in the reviews and
forums. 

Please note that with firmware-less KMS, the video is corrupted in the CLI too,
not just X: the firmware must be in the initrd for anything to be displayed
correctly.

Could perhaps be something for the errata. Or for the installer or a Debian style workarround usinf an external media...

CC: (none) => oliver.bgr

(In reply to comment #6)

> I would very much prefer the firmware to be included (less hassle). 
> There will also be less noise about unusable computers in the reviews and
> forums. 

I agree with this comment. I believe that free is better, unless high problems caused by this firmware not loaded or in alternative the option at boot.

CC: (none) => stblack

I agree with inclusion of the firmware as well.  Errata as well as any form of post-install fix ignores the fact that on some machines the first boot will yield not only an unusable GUI but an unusable CLI as well, and it is unrealistic to expect anybody, much less newbies, to boot a rescue disk and chroot to get a usable system.

In my view it is contradictory to make a non-free repository available and then refuse to have it participate in the install.  It is perfectly appropriate to give users the option to install a completely free system (or the option to deviate from a completely free system), as we have in the past with video drivers.  But I fail to see what is achieved by shipping a "pure" physical media.  We might as well require that users yank their BIOS ROMs and replace them with a FOSS BIOS before they can boot the install disk.  Except that because there isn't a FOSS BIOS, we don't.  The situation with firmware is no different.

It's time to accept the reality that whether we like it or not, FOSS is not yet ready to exist in a vacuum as far as most users are concerned.  FOSS can stand or fall on its own merits; it doesn't need posturing like this to interfere with acceptance of its merits.

CC: (none) => ftg

I think XFdrake should not offer to set up eg ati driver if kernel-firmware-extra is not installed, at least on r600+

CC: (none) => anssi.hannula

(In reply to comment #10)
> I think XFdrake should not offer to set up eg ati driver if
> kernel-firmware-extra is not installed, at least on r600+

In this case, this goes a bit further: recent radeon cards do not provide any usable display without the firmware, even on the CLI. The computer is stuck (for non-technical users) from the start. 
Do not pass through XFdrake, do not get a display. 

Annoying for tinkerers, but blocking for pure users. 


(In reply to comment #9)
> I agree with inclusion of the firmware as well.  Errata as well as any form of
> post-install fix ignores the fact that on some machines the first boot will
> yield not only an unusable GUI but an unusable CLI as well, and it is
> unrealistic to expect anybody, much less newbies, to boot a rescue disk and
> chroot to get a usable system.

Well, it can also be done with some grub/kernel boot instruction editing. 
Somewhat easier than the rescue/chroot trick. 

I'd prefer to have the firmware (of course), but here is a possible "pure" solution, requiring little skill (not perfect, but rather easy). 

- The grub line can be set correctly by the installer for the initial boot. 
- A message at login time (CLI+GUI) warns the user the configuration is sub-optimal, and gives a simple command (CLI) and a big red button (GUI) to automagically configure urpmi, activate nonfree (display warning), install the firmware and regenerate the initrd. That would be a few lines of bash, even including a few checks for maximum cleanliness. 
On the other hand, this requires either a local mirror or network access. 

Still, this is a usable solution, if we want to stay "pure" free software (still not enough for the FSF, anyway). 


> In my view it is contradictory to make a non-free repository available and then
> refuse to have it participate in the install.  It is perfectly appropriate to
<cut>
One thing to check is the redistribution rights. They must be transitive (if you give someone a cd, they are still allowed to give it to others). Works here. 
Other than that, the question of freedom and firmware vs software can be debated ad nauseam: there is rarely a simple answer when personal ethics are involved. 

Your solution to put firmware on the cd but give an option to not install anything non-free might be a good compromise, but that may be out-of-scope for Mageia 2. 


Does anybody know what other missing firmware could prevent boot?

Not boot, but in a network installation an ethernet card using broadcom-wl.

Ciao
Stblack

Note that this is a duplicate of bug 1471. This has hit a lot of people - and who knows how many more tried and discarded Mageia 1 without coming to the forum to find out how to work round it. At the very least, the installer should automatically add the radeon.modeset=0 boot option if it can't install the firmware.

CC: (none) => mageia

(In reply to comment #13)
> Note that this is a duplicate of bug 1471. This has hit a lot of people - and
> who knows how many more tried and discarded Mageia 1 without coming to the
> forum to find out how to work round it. At the very least, the installer should
> automatically add the radeon.modeset=0 boot option if it can't install the
> firmware.


Thanks for mentioning bug 1471!

I don't want to close this bug, because the description and the summary are so very clear: they give a good overview of the possible solutions for bug 1471. I'll set 1471 to depend on this one.

Blocks: (none) => 1471

Well I think the summary for 1471 is just as clear - but then I would ;-).

A bugzilla search for "radeon firmware" finds two other likely duplicates, bug 1951 and bug 3421.

(In reply to comment #15)
> Well I think the summary for 1471 is just as clear - but then I would ;-).
> 
> A bugzilla search for "radeon firmware" finds two other likely duplicates, bug
> 1951 and bug 3421.

Thanks again :D

This report here is a general one, while the three other reports are about 3 specific Ati Radeon cards.

Solving this one hopefully solves all three of them, but that isn't 100 % sure, so I'll set the other two to depend on this one, too

Blocks: (none) => 1951, 3421

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

CC: (none) => herbert

(In reply to comment #17)
> *** Bug 4165 has been marked as a duplicate of this bug. ***

I'm fine with that, just note that the firmware is present in the kernel sources and usually is built and installed when the kernel is built and installed, so in _my_ case it would be not a question of nonfree and not a problem to build a firmware package from the kernel source rpm

(In reply to comment #16)
> (In reply to comment #15)
> > Well I think the summary for 1471 is just as clear - but then I would ;-).
> > 
> > A bugzilla search for "radeon firmware" finds two other likely duplicates, bug
> > 1951 and bug 3421.
> 
> Thanks again :D
> 
> This report here is a general one, while the three other reports are about 3
> specific Ati Radeon cards.
> 
> Solving this one hopefully solves all three of them, but that isn't 100 % sure,
> so I'll set the other two to depend on this one, too

Hallo Marja,

sadly I've to confirm the bug with mageia2a3.
I tried a clean install with netinstall iso. KDE was choosen and installation went through clean. 
But after reboot to fresh installed system were disturbed screens (X11) and broken console (no input).

The system is an older Athlon XP mainbord with VIA chipset, onboard Broadcom GBit ethernet, AGP RADEON and Yamaha soundcard (details on request).

After using failsafe boot mode I've got the chance to search for reasons.
In output of "dmesg" I found "failed to load firmware <file>" for both "radeon" and "tg3" modules.

Module "radeon" was probably not working. I've found the missing files in package "radeon-firmware". 
This package is available in normal repositories but wasn't installed. After installing manually and rebuilding initrd the System behaves normally.

The "tg3" module has complained without firmware about missing capabilities, but has done it's job.

The 3rd candidate for missing firmware was module "snd_ymfpci". But there are not so clear messages about missing firmware parts.
in Addition in this case the startup messages were cluttered because of parallel messages of other booting systems. The message of interest was "firmware request failed: -2".
Otherwise the driver seems to load correctly. But without firmware there are only the sounds of silence...

The firmwares of "tg3" and "snd_ymfpci" are both in package "kernel-firmware-nonfree". After installing the package network and soundcheck were working without mistakes.

In this installation case were no objections aginst non-free firmwares.

Summary:
1. Kernel modules without required firmwares behaves strange; from showstopping to performance degrading.
2. In case of failing firmware should the customer be informed. Then he can decide on problem solution. 
  Kernel modules with failed firmware should be unloaded (rmmod) and possibly blacklisted with reasons.
3. Customers should be hinted to solutions for properly working systems. Harddrake has the potential knowledge.
4. Newbees are thrilled, if installation media detects hardware properly and installed system won't (e.g. graphics).
5. Firmware without distribution restrictions should be supplied, especially for graphics and networking.
6. Restrict distro later (on demand) to pure free software accelerates public adoption. 
  Possibly assign an "negative" metatask package for displaying/removing not fully "free" software. Breaking an working installation by user is also freedom.

with regards, juergen

CC: (none) => preugen

Greetings,

I just tested Mageia2 beta1 with the x86_64 DVDs, and the problem is still there, with no notable change, at least for my test hardware: 
- no firmware (no proprietary software or firmware on the free DVD, I know); 
- no default to radeon.modeset=0 in the grub configuration either. 

I wonder: does the "radeon.modeset=0" parameter have any impact on systems without radeon video cards? I'm afraid I can't test this, but if not, it could be a default parameter in all /boot/grub/menu.lst files. 

Could anyone with access a non AMD video card test this, please? 

Best regards.

IBM Thinkpad T40 here, GPU: Radeon Mobility 7500 ( also listed as M7 LW ).
System failed installing from mga2a3 iso, installed a month ago by boot.iso, network install, updated yesterday (=beta1?).

As per bug 3502 i saw many "Failed to allocate" lines, but for other user it failed booting.

Simply adding kernel parameter radeon.modeset=0 solved it for us too.

Installing radeon-firmware is an alternative and seem to make it faster.

CC: (none) => fri

(In reply to comment #21)
> Simply adding kernel parameter radeon.modeset=0 solved it for us too.
> 
> Installing radeon-firmware is an alternative and seem to make it faster.

That is as intended: all radeon video cards need the firmware files for KMS (i.e. optimal) operation. The modeset=0 trick is only intended as a temporary workaround, so the firmware files can be installed. 

It just should be the default when the firmware is missing, for obvious reasons.

Cheers.

(In reply to comment #22)
> (In reply to comment #21)
> > Simply adding kernel parameter radeon.modeset=0 solved it for us too.
> > 
> > Installing radeon-firmware is an alternative and seem to make it faster.
> 
> That is as intended: all radeon video cards need the firmware files for KMS

Just fyi. My 7 year old Radeon 9200 SE doesn't have any firmware available,
and worked fine without any, prior to Mageia 2.  With Magiea 2, I have to
set radeon.modeset=0 to avoid the thousands of lines of error messages.

It is inconsistent though, as sometimes I don't get the error messages
and increasing the vmalloc to 256MB reduces the frequency of me getting
the errors, but doesn't eliminate it.

CC: (none) => davidwhodgins

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

CC: (none) => mike.crecelius

With a clean default Gnome install from the Release 2 Beta1 64bit DVD, I boot to a locked up computer. Rebooting into safe mode, then changing from Radeon or RadeonHD to Radeon-Vesa in XFdrake allows me to boot into a basic GUI. After doing the updates, enabling non-free, etc then I install the proprietary driver.

This is for Radeon HD 6000 series connected by HDMI to a HDTV.

CC: (none) => bcm.alaska

(In reply to comment #23)
> > That is as intended: all radeon video cards need the firmware files for KMS
> 
> Just fyi. My 7 year old Radeon 9200 SE doesn't have any firmware available,
> and worked fine without any, prior to Mageia 2.  With Magiea 2, I have to
> set radeon.modeset=0 to avoid the thousands of lines of error messages.
Probably because KMS was not yet the default for the Radeon 9200? 
Needing the firmware is a rather recent development. 
The R9200 firmware is the usual all-in-one radeon-firmware package. 

The beta2 still needs radeon.modeset=0 at first boot. I know it is in the errata, but non-technical users will not look at it, and they're the one to need it most. 

It would probably be better to configure it by default. This would give everyone a working system at first boot (and typing the line is a bother when you do not use qwerty: you get the a.m to guess on azerty, for example). 

It should be possible to automagically remove the line from the bootloader with a post-install script in radeon-firmware, with bonus points for leaving it in failsafe mode.

Even without this last luxury, I think it is much better to give users a working setup by default. The current version will give bad reviews from blogs with more reach than technical know-how (I'll not give names, but I'm thinking of some) and tonnes of questions/complaints in the forums, with users unable to understand they all have the same damn problem (happened for Mageia 1). 

Mageia and the community would be better off without the noise and botheration. 

Best regards, and thank you for all your work.

+1 to passing radeon.modeset=0 to the kernel.  Is there anything I can do to help this along?

I can understand not including the closed source binaries, but, IMHO, leaving a system where a hard reset is required should be a blocker for Mageia 2.  Most users will install Mageia and only look at the Errata, if they ever do, when they have a problem and not before the install.  This is especially true of hardware that has a history of support in Linux.

Also, this setup completely screws over people with 1 computer.  On 2 of my 3 systems I couldn't even use a command-line web-browser because the video was screwed up there too.

BTW, what happens if one tests the video during install with Beta 2?  I will hopefully be doing my install this weekend, but I might not get a chance and I think the outcome of this test will be very important.

--Jeff

CC: (none) => jeffrobinsSAE

firmwares are available if you boot boot-nonfree.iso instead of boot.iso...

(In reply to comment #28)
> firmwares are available if you boot boot-nonfree.iso instead of boot.iso...


Just out of curiosity, why wasn't this done directly in isolinux, with the option to enable nonfree if available (from anywhere, network or ISO) ?  That would have been much nicer for those of us doing LAN network installs that boot isolinux directly.  As well as not requiring re-burning the boot-nonfree.iso every time the drivers change.

And out of additional curiosity, why the pushback about adding the kernel parameter ?  What's the downside ?

It seems like a bug in the KMS module if non-available firmware results in freeze or completely missing output. From my reading of the driver, it should fallback to non-accelerated mode or just abort completely.

Is it documented somewhere that the driver may also break everything if no firmware is present?

If not, with what hardware generations exactly does missing firmware cause this issue (different hardware generations need firmware for different operations)?

Is this any help?

http://www.x.org/wiki/radeonBuildHowTo#Missing_firmware

(In reply to comment #28)
> firmwares are available if you boot boot-nonfree.iso instead of boot.iso...

But how does this help the majority of non-technical users who install from the DVD?

Come on. I reported this problem just before Mageia 1 was released. It has been the subject of numerous duplicate bug reports, questions in the forum, and who knows how many potential Mageia users turned away because they didn't get a bootable system after installation. Why don't you want to fix it?

This is not a question of willing to fix it or not, this is a licensing question.

Please elaborate.  We already provide the needed firmware in a nonfree repository for anyone to download if they want it, and we are now providing it on an alternate ISO.  So,

1) What licensing issue is there with having stage2 hook up nonfree (or the local copy on the ISO) if the user requests it ?

2) What *possble* licensing issue could be involved in adding a kernel init parameter to a grub menu ?

Thierry, sorry if I seem to be putting you on the spot.  I realize that you may not necessarily be on either side of this argument, but may simply be commenting here tp provide information.  However, much of the frustration with this bug ariss from the fact that the protagonists seem to be conducting the negotiations about this issue out of the public eye.  To those of us who don't live on IRC and rely on bug reports and the dev ML, this just looks like a pissing contest between free software purists and those who want something that works out-of-the-box for newbies.  Personally I'm willing to consider arguments on either side, but the trouble is that none are being made.  Personally, I have no idea why a nonfree boot.iso is acceptable, but an option to hook up nonfree from a network-accessed distro seems not to be.  It would be very nice to know what's really going on.  It's really hard to make any constructive suggestions without that kind of openness.

Does the option have to be supplied on the boot command line, or can it be done in /etc/modprobe.conf? If the latter, can't the installer detect whether the radeon-firmware package is available, and if not, add the necessary option to /etc/modprobe.conf. If the radeon-firmware package is subsequently installed, the post-installation step could update /etc/modprobe.conf to remove the option.

A refinement would be to put a dummy radeon-firmware package in the free repository that just does the patch to /etc/modprobe.conf. Then if the user enables the non-free repository and does an update, it could be automatically replaced by the real radeon-firmware package (just like for libfreetype6).

As Frank says, the frustration here is that I can't see why a fix like this has any licensing issues.

I reread the license again and while I can see a case for a problem with distributing the binaries as default, I still can't see a problem with adding the parameter to the boot command-line.

I also noticed that this still hasn't been assigned to a particular person.  Is this just a case of the right person not knowing about the bug or is there currently no one who handles this portion of Mageia?  

Which portion of the installer needs to be modified to detect the missing binaries and add the parameter?  Is this a dracut problem or a mkinitrd problem?  I'm afraid that I'm not familiar at all with this portion of Mageia.

I am willing to look at the issue if someone can point me in the proper direction, but I will be starting from almost zero knowledge so it may take awhile and many attempts at a proper patch.

Part of the problem certainly is that at least I'm not yet sure where the fix needs to be. Sure, I agree that modeset=0 should be used if no firmware is present and the card would become unusable otherwise.

One solution could probably be either some udev rule or a modprobe rule. However, I'm not 100% sure what such rule should look like, though. Care would have to be taken so that it works even in initramfs, and also in livecd.

Another solution would be to alter /sbin/display_driver_helper script. Probably two changes:
1. in '--is-kms-allowed', so that it would disallow KMS if no firmware is present for the affected cards. This should cause DrakX to automatically add 'nokmsboot'
kernel boot option, which prevents loading any KMS drivers in initrd (like is done for proprietary drivers and 'vesa' X driver).
2. in '--load', so that it would add modeset=0 when loading 'radeon' when no firmware is present (this is called in the real system after initrd has exited).

I only just thought of the second solution, and it seems rather nice (unless I forgot something). What do other people think?

I just finished my Beta2 install and this is what I found:

1) There was no way to test the video setup during the install.
   - Not completely sure if this is good or bad

2) There were no default boot options that gave me a readable screen.
   - I tried, from the text menu, linux, linux-nonfb and failsafe

Anssi, are you willing to look at this, can it be assigned to you?

I can look at the disabling-modesetting part, yes (in the next few weeks I hope). I don't have any Radeon hardware, though, but I think I can do the testing with other drivers and then switch it to 'radeon' driver when I'm ready.

Note, however, for the record, that modeset=0
- as far as I understand, lowers performance and might make some multi-head
  configurations not working (it has in the past, at least), and
- does only work for Radeon HD 4xxx and older. Newer cards only work properly with
  modesetting, so they'll have to be set to use the 'vesa' driver if no firmware
  is installed.


For the record, I would not be against putting such non-free firmware on installer DVD as suggested by Nicolas Vigier in comment #3.

Thanks Anssi, assigning it to you then :)

Assignee: bugsquad => anssi.hannula

(In reply to comment #40)
>I don't have any Radeon hardware, though, but I think I can do the
>testing with other drivers and then switch it to 'radeon' driver when I'm
>ready.

Do you have a free PCIe slot? I'd pitch-in 5 USD towards getting you a card.  I got my HD6450 for 25 USD.

> Note, however, for the record, that modeset=0
> - does only work for Radeon HD 4xxx and older. Newer cards only work properly
> with
>   modesetting, so they'll have to be set to use the 'vesa' driver if no
> firmware
>   is installed.

I have an integrated on-board display that reports as Radeon HD 6310 and the modesetting works for it.  

I do have the system with the add-in HD 6450, but I can't install Mageia 2 Beta 2 on it because I need it for everyday use and I don't have enough space for another operating system on it.

(In reply to comment #42)
> Do you have a free PCIe slot? I'd pitch-in 5 USD towards getting you a card.  I
> got my HD6450 for 25 USD.

Nope, I'm using a laptop as my desktop. Otherwise I probably would've just bought a radeon card myself just for testing this issue :)

> > Note, however, for the record, that modeset=0
> > - does only work for Radeon HD 4xxx and older. Newer cards only work properly
> > with
> >   modesetting, so they'll have to be set to use the 'vesa' driver if no
> > firmware
> >   is installed.
> 
> I have an integrated on-board display that reports as Radeon HD 6310 and the
> modesetting works for it.  

Yes, modesetting is expected to work (with firmware), but AFAICS using radeon.modeset=0 should not work properly (since there's no UMS support for Evergreen and newer). Unless it is just some rebranded older chipset...

The modesetting works without the firmware.  I'm pretty sure it isn't just a rebranded older chipset.  This page seems to have some early details on it and the page is only from November 2010 (http://hothardware.com/Reviews/AMD-Zacate-E350-Processor-Performance-Preview/).  

The modesetting is the only way to get the Beta 2 up and running without using a rescue disk.  The KDE default installation doesn't install ssh-server by default and I still have to manually edit hosts.allow, at least when using server security, to connect to the machine using ssh.

Beta 2 seems fairly stable, at least with the latest updates.  Maybe I'll put it on my other computer next weekend and test it out.  I'd rather not as I will have to spend a great deal of time moving files and folders around for a good backup.

--Jeff

(In reply to comment #44)
> The modesetting works without the firmware.  I'm pretty sure it isn't just a
> rebranded older chipset.  This page seems to have some early details on it and
> the page is only from November 2010
> (http://hothardware.com/Reviews/AMD-Zacate-E350-Processor-Performance-Preview/). 

With "modesetting" do you mean kernel modesetting (KMS), or usermode modesetting (UMS, radeon.modeset=0)?
In comment #43 I meant KMS with it.

Kernel modesetting should not work for Northern Islands and newer (which your card is AFAICS) without firmware. If it seems to work anyway, can you attach your 'dmesg' output?

Also, usermode modesetting should not be supported for Sumo and newer (which your card also is AFAICS). If it seems to work anyway, could you attach both 'dmesg' and '/var/log/Xorg.0.log'?

> The modesetting is the only way to get the Beta 2 up and running without using
> a rescue disk.  The KDE default installation doesn't install ssh-server by
> default and I still have to manually edit hosts.allow, at least when using
> server security, to connect to the machine using ssh.

Hmm, this makes it even less clear what you mean with "modesetting". Kernel mode-setting is currently enabled by default, and this bug report is about disabling it (radeon.modeset=0) when no firmware is present. When kernel mode-setting is disabled, usermode modesetting is used (if available, see above).



Also, generally, has anyone who has experienced the issues in this bugreport managed to provide a 'dmesg' of a system which froze or become otherwise unusable when firmware is not present? As it really shouldn't happen AFAICS, the driver shouldn't mess up anything if it sees no firmware (in theory, at least...)... And I don't remember seeing any such log files so far. I'm willing to implement the radeon.modeset=0 workaround without seeing such logs, though, but it would be nice to know what exactly happens.

I meant adding the radeon.modeset=0 to the kernel command-line in Grub.  I will uninstall the radeon-firmware package and get the information you requested.  It may take me a while as I'm about to go to lunch. :)

(In reply to comment #45)
> Also, generally, has anyone who has experienced the issues in this bugreport
> managed to provide a 'dmesg' of a system which froze or become otherwise
> unusable when firmware is not present?

Yes. See comment 1 in bug 1471.

Uninstalling radeon-firmware does not remove the firmware from the boot image, so I can't reproduce the problem.  I think it's not running initrd, like it does on install, but it may be another program that isn't being run.

I will file a bug report on that tonight.

(In reply to comment #46)
> I meant adding the radeon.modeset=0 to the kernel command-line in Grub.  I will
> uninstall the radeon-firmware package and get the information you requested. 
> It may take me a while as I'm about to go to lunch. :)

OK, reading the code your HD 6310 is actually supported for UMS by the code, even if it is not listed at all in http://www.x.org/wiki/RadeonFeatureUMS .

Can you also confirm whether console restore works when using radeon.modeset=0 without firmware. I.e. try switching between the virtual consoles (ctrl+alt+f1, ctrl+alt+f2, ctrl+alt+f3, ...) and see if the consoles appear or not.

(In reply to comment #47)
> (In reply to comment #45)
> > Also, generally, has anyone who has experienced the issues in this bugreport
> > managed to provide a 'dmesg' of a system which froze or become otherwise
> > unusable when firmware is not present?
> 
> Yes. See comment 1 in bug 1471.

OK, thanks. I would've liked to see the full log, but it now looks like it might not be worth the effort to get the driver to fail to load "nicely" (without corrupting display), considering that there are so many card families and firmware types out there, and most of the testing is probably done with firmware present (as other distros generally include it)... as just adding radeon.modeset=0 or not loading the driver should workaround the issue, and we would need to add such handling anyway.

(In reply to comment #48)
> Uninstalling radeon-firmware does not remove the firmware from the boot image,
> so I can't reproduce the problem.  I think it's not running initrd, like it
> does on install, but it may be another program that isn't being run.
> 
> I will file a bug report on that tonight.

You can run:
  bootloader-config --action rebuild-initrds
to rebuild the boot iniramfs images after removing/installing the firmware (note: installing radeon-firmware should automatically do this, uninstalling it doesn't).

Created attachment 1795 [details]
dmesg output with no firmware and not using radeon.modeset=0

Created attachment 1796 [details]
Xorg log with no firmware and not using radeon.modeset=0

Created attachment 1797 [details]
dmesg output with no firmware and USING radeon.modeset=0

Created attachment 1798 [details]
Xorg log with no firmware and USING radeon.modeset=0

Virtual Consoles:
1) Using radeon.modeset=0
   F1 gives a graphical login.  All other combinations give a blank screen, not even a blinking cursor.  My dual input monitor keeps switching between inputs looking for a signal. The system is hooked up to the monitor using VGA.

2) With firmware
   F1 never changes to a login prompt, but stays as boot text status output.  F2 to F6 are text logins and F7 is a graphical login.

Please tell me if there is anything else you would like/need.

I have a AMD Radeon HD6870 pcie card in my installation. My monitor is HDTV (via hdmi connection) with a native resolution of 1920 x1080. I set it to generic flat screen 1920x1080, at the same resolution. I have a partition available for installing and testing beta's on. I chainload to it. I'd be happy to do any tests that would be useful with this hardware, although my somewhat knowledge is limited. I just did an install of the Beta 2 DVD, from the actual DVD itself rather than my usual harddrive or network install. I added the zarb.org FTP as an additional source during the installation. It was a default KDE install this time. First boot was a lockup (rseiub). Safe mode the second, had to change to cntl+alt+f2 and XFdrake to radeon-vesa. I was never prompted if I wanted the proprietary driver, despite adding the sources where it was available. In KDE some fonts were so tiny as to be illegible, for example the fonts in the menu and on the icons. Others were normal, including in MCC, fortunately. I enabled nonfree and tainted, and still wasn't presented with the option to use the AMD proprietary driver. I manually added the dkms-fglrx, and eventually managed to add enough of the required packages, and after several reboots, XFdrake in console F2 while in safe mode offered to install the proprietary driver. Another reboot and everything including the fonts are fine.

In short, I'd suggest;

Ask during installation whether or not to use non-free repositories, and offer the proprietary driver if available.
Do what you need to do to make the mostly free radeon driver work if it is chosen. If it's not possible to make the proprietary driver or the radeon driver work then install the radeon-vesa driver and address the tiny font issue with that driver.

In the past I've just gone to safe mode on the first or second boot and used XFdrake to install the proprietary driver, which isn't a good solution at all, but this time it was much harder than that to get that to work.

I'd be happy to do a fresh beta 2 test install, if you'd like me to try anything. My beta install is fine now, but I'd like to help anyway I can to have this installer issue fixed before final.

Ping ?

CC: (none) => ennael1

I can do fresh test installs on a couple IBM thinkpads T42 and T43, and possibly  Radeon HD 6850 on my main work machine.
Tell me when you need testing.

As per comment #40, I'm going to look at this as soon as I have enough time (hopefully this week).

Just FYI, I tried a boot-nonfree.iso install, with mixed results.

The problem symptoms with the missing firmware come in three visible flavors:

1) a finite but very long (5-10 minutes) loop of kernel panics
2) a finite, but very long (longer than the kernel panic loop) loop of kernel storage allocation failures
3) the eventual maybe-I-get-a-tty-and-maybe-I-don't result.

This stuff goes by pretty fast, so it's hard to be certain, but it looks like using boot-nonfree gets rid of the kernel panic loop, and leaves *some* of the storage allocation failure loop (but much less than originally, maybe 10-15 seconds).  IIRC, X did come up.

So, there's something that actually installing the firmware rpm does that boot-nonfree isn't doing.  In practice, it wasn't a problem, since the system did actually come up and start X, but it's going to be visible to reviewers.

Some questions to help me decide what Radeon chipsets need to have kernel modesetting disabled when there is no firmware:

Has anyone experienced this issue with an older non-HD series card (r500 and older), when no firmware is present and no boot option is given?

Has anyone with a Radeon HD card been *not* affected by this bug, i.e. X server started fine without firmware without kernel boot options, using the normal "ati" (or "radeon") driver (see /etc/X11/xorg.conf or /var/log/Xorg.0.log)?

Unless anyone comments, I assume "no" to both, and disable kernel modesetting on all Radeon HD cards when no firmware is present, and for cards too new for user modesetting I'll just switch them to "vesa" driver when no firmware is present.

I have a spare Radeon x1300 Pro, which seems to be based on the R516 Graphics Processor.  I will try and test the card tonight.

I've done a trawl through bugzilla and come up with the following list of affected cards. I'm not an expert on Radeon numbering, but it looks like there are three older devices mentioned:

  Mobility 7500
  9200 SE
  X300

The full list is:

Bug #956

  Unknown

Bug #1268

  Radeon 3200

Bug #1360

  Mobility Radeon HD 3650

Bug #1472

  Mobility Radeon HD 3430 (ChipID = 0x95c2)
  Mobility Radeon HD 3410
  HD 3200
  HD 4570
  HD 3450

Bug #1951

  Radeon HD 2600

Bug #3421

  HD 6200 (ChipID = 0x9804)

Bug #3466

  Radeon Mobility 7500

  Radeon 9200 SE

  Radeon HD 6000

  Radeon HD 6450

Bug #3502

  Radeon X300 (RV370, ChipID = 0x5b60)

  Radeon Mobility 7500

Bug #4165

  Radeon RV670

Bug #4359

  ChipID = 0x9804

Bug #4776

  Radeon HD 6700M

Bug #5006

  Radeon HD 4670 (ChipID = 0x9490)

OK, thanks for the summary. I'll have to disable firmwareless KMS on all radeons then.

In the meantime, I ordered a used 9250SE (AGP) in case I'll have time to look at the underlying issue closer.

I experienced this issue with a Radeon Xpress 200M chipset, but I don't know which category it belongs to.

CC: (none) => remi

it's an old r400

KMS is now automatically disabled when configuring a Radeon card using the free driver without firmware. Also, when configuring a Radeon card that has only KMS support (approximately Radeon HD 6400 and newer), the 'vesa' driver will be used instead if no firmware is installed.

This was done in these today's updates:
drakx-kbd-mouse-x11-0.100-1.mga2
ldetect-lst-0.1.300-1.mga2

Please reopen if you can still reproduce the issue with those updated packages.


For the record, I would not be against providing the firmware in the installer.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

(In reply to comment #67)
> For the record, I would not be against providing the firmware in the installer.

This has been disccussed several times, and while I supported keeping the firmwares that were previously embedded in kernel modules, the consensus was to include only free firmwares [1].

Anyway, this cannot be done technically while those packages are in non-free/release since drakx-installer-stage2 is in core/release.

Also there's no point in including them in stage2 while they're in non-free, since by default they would not be included

[1] Note that eg Fedora include more stuff than us (including radeon Intel/AMD microcode)

I would support you if open a new BR (or a new thread on mga-dev) about that.
AFAIC those are not proprietary programs running on the CPU.

(In reply to comment #67)
> KMS is now automatically disabled when configuring a Radeon card using the free
> driver without firmware. Also, when configuring a Radeon card that has only KMS
> support (approximately Radeon HD 6400 and newer), the 'vesa' driver will be
> used instead if no firmware is installed.
> 
> This was done in these today's updates:
> drakx-kbd-mouse-x11-0.100-1.mga2
> ldetect-lst-0.1.300-1.mga2
> 
> Please reopen if you can still reproduce the issue with those updated packages.
> 
> 
> For the record, I would not be against providing the firmware in the installer.

Thanks for taking care of this thorn in our collective side.  I'll try a fresh install this week.

(In reply to comment #67)
> KMS is now automatically disabled when configuring a Radeon card using the free
> driver without firmware. Also, when configuring a Radeon card that has only KMS
> support (approximately Radeon HD 6400 and newer), the 'vesa' driver will be
> used instead if no firmware is installed.

Just one question: does the radeon-firmware postinstall script remove the kernel module options you added?

CC: (none) => reinout

I'm not sure exactly how what I see squares with what you did, but a fresh install now boots with no problem at all, but also no X, vesa or otherwise.  I take it that means my chip (an HD3200/3300 IIRC) just gets KMS disabled, which disables X until I install the firmware and re-select the ati or fglrx driver.

If that's as you intended, this works fine.  Thansk again.

(In reply to comment #70)
> Just one question: does the radeon-firmware postinstall script remove the
> kernel module options you added?

Yes.

(In reply to comment #71)
> I'm not sure exactly how what I see squares with what you did, but a fresh
> install now boots with no problem at all, but also no X, vesa or otherwise.  I
> take it that means my chip (an HD3200/3300 IIRC) just gets KMS disabled, which
> disables X until I install the firmware and re-select the ati or fglrx driver.
> 
> If that's as you intended, this works fine.  Thansk again.

It is not, X should go up just fine without KMS... I want to see dmesg and Xorg.0.log.

I would like to help by testing on my HD 4570 laptop but I know how to do it.

More precisely should I build my own iso with the fore-mentioned corrected packages or can I copy them direcly in the bootable installation USB key ?

Any help appreciated.

(In reply to comment #73)
> I would like to help by testing on my HD 4570 laptop but I know how to do it.
> 
> More precisely should I build my own iso with the fore-mentioned corrected
> packages or can I copy them direcly in the bootable installation USB key ?
> 
> Any help appreciated.

See https://forums.mageia.org/en/viewtopic.php?f=4&t=2187

>It is not, X should go up just fine without KMS... I want to see dmesg and
Xorg.0.log.

I'm attaching dmesg.  Unfortunately, Xorg.0.log and Xorg.0.log.old both reflect later boots after I installed the firmware and the proprietary driver.  I know that dmesg.old is good, because it reflects a kernel boot line using UUID, which I replace during post-processing with /dev/sdX.

Created attachment 1935 [details]
dmesg from first boot

>Unfortunately, Xorg.0.log and Xorg.0.log.old both reflect
later boots after I installed the firmware and the proprietary driver.

One interpretation of this is that the initial boot was to runlevel 3 with no attempt to start X.

During the install, I saw the new prompt, and had no other interaction to configure X or the display.  When I got to Summary, Graphical displayed as "Automatic", and the "not configured" highlight was *not* present, so I didn't click it or try to interact with it further.

(In reply to comment #76)
> Created attachment 1935 [details]
> dmesg from first boot

This log is from a boot with firmware installed and modesetting enabled. Can't see why X wouldn't start, though.

(In reply to comment #78)
> (In reply to comment #76)
> > Created attachment 1935 [details]
> > dmesg from first boot
> 
> This log is from a boot with firmware installed and modesetting enabled. Can't
> see why X wouldn't start, though.

Hmm. I *thought* it was from the first boot, but I could be wrong.  I'll be trying a fresh install on a different system in the next day or so, and I'll capture the logs from that.  If I see the same symptom, that should clinch it.  If i don't, I still have extra partitions on the original system and I'll redo it there.

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

I did a Beta 3 DVD install last night on my machine with Integrated HD6310 and Mageia booted into KDE without a problem.  I then added the radeon-firmware package and rebooted.  I haven't seen any issues yet.

Created attachment 2275 [details]
Xorg.0.log with a segfault of X

I did a fresh install of mga2rc from the DVD on my laptop with Radeon HD4570 and X fails to launch and repeatedly crashes whether or not the option radeon.modeset=0 is set or not. I attach both dmesg and a Xorg.log.
As it is still a test machine, I don't touch anything in case someone needs further details.
Installed desktop is GNOME.

Created attachment 2276 [details]
dmesg of the faulty radeon laptop

Unfortunately this one is no more resolved

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

This new problem has already been reported in bug #5426. I suggest you add a comment there, to keep the discussion in one place.

I came here from the errata page (https://wiki.mageia.org/en/Mageia_2_Errata#Laptop_with_both_Intel_and_ATI_graphics_hardware)
I switch to #5426 and close again this one but I think the errata page should be updated.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

The link from the errata page in my previous comment is wrong. It should be https://wiki.mageia.org/en/Mageia_2_Errata#Radeon_HD_Issues that needs an update because the proposed solution radeon.modeset=0 doesn't help with mga2rc.

(In reply to comment #87)
and what should we make ? remove all the paragraph ?

remove completly https://wiki.mageia.org/en/Mageia_2_Errata#Radeon_HD_Issues  ?

https://wiki.mageia.org/en/Mageia_2_Errata#Laptop_with_both_Intel_and_ATI_graphics_hardware is enough ?

it's a wiki so feel free to update, personally I'm a little lost with the video card :)

(In reply to comment #88)
From now on and considering my own experience only I would say :
1/ Don't use DVD to install Mageia 2 RC if the video card is a Radeon HD, use the LIVE CD instead.
Or for more advanced users (read, command line friendly):
1/ At first reboot after the installation, choose boot in safe mode
2/ activate non free repository
3/ install radeon firmware
Or if non free software matters
1/ At first reboot after the installation, choose boot in safe mode
2/ modify the /etc/xorg.conf to change the driver from 'ati' to 'vga'
3/ Say goodbye to bleeding edge desktop effects (I even don't know if gnome-shell will launch)

Now about modifying such an important wiki page than the errata page, I am not involved enough in mageia project, nor aware of the big picture about that ATI firmware problem to modify this page. But I will be pleased to help and do it, if some one officially involved (board, council, team member) validates the points above.

(In reply to comment #89)
> (In reply to comment #88)
> From now on and considering my own experience only I would say :
> 1/ Don't use DVD to install Mageia 2 RC if the video card is a Radeon HD, use
> the LIVE CD instead.
> Or for more advanced users (read, command line friendly):
> 1/ At first reboot after the installation, choose boot in safe mode
> 2/ activate non free repository
> 3/ install radeon firmware
> Or if non free software matters
> 1/ At first reboot after the installation, choose boot in safe mode
> 2/ modify the /etc/xorg.conf to change the driver from 'ati' to 'vga'
> 3/ Say goodbye to bleeding edge desktop effects (I even don't know if
> gnome-shell will launch)
> 
> Now about modifying such an important wiki page than the errata page, I am not
> involved enough in mageia project, nor aware of the big picture about that ATI
> firmware problem to modify this page. But I will be pleased to help and do it,
> if some one officially involved (board, council, team member) validates the
> points above.

Thanks for your suggestion :)

I'm from documentation team and to me the steps look very clear, apart from, but I'm not a native English speaker, the line "Or if non free software matters". I don't really grasp what that line means. Does it mean: "If you don't want to use non free software"?

I don't have such a card to test the steps with.

@ Anssi, Claire, Dave

Can you please improve and/or validate the text above?

Taking the suggestion from comment 89, I'd reword it as
follows, keeping in mind my hardware is old, so I can't
confirm the suggestions work ...

1/ If you have a Radeon HD video chip, instead of using
the DVD to install Mageia 2, you may get better results
using the the LIVE CD instead.

Or for more advanced users, who are used to using the
command line tools ... 
1/ At first reboot after the installation, choose boot in
safe mode.
2/ Use drakrpm-edit-media to activate the Nonfree repository.
3/ Install the radeon firmware package, then reboot.

Or you prefer not to use proprietary non-free software, 
1/ At first reboot after the installation, choose boot in
safe mode
2/ modify the /etc/xorg.conf to change the driver from 'ati'
to 'vesa'
3/ Keep in mind that many desktop effects, and advanced
graphics features will not be available, without the
proprietary drivers.

One minor tweak, "Or you prefer" -> "Or if you prefer".

Two other things to note:
1) The 'vesa' driver doesn't support many common widescreen resolutions, so is not really a usable option on many machines.
2) I have one machine where the 'radeon' driver doesn't work even with the firmware installed. So sometimes the only option is to install the 'fglrx' driver.

Will a user have network access in safe boot? It may be better to have them select vesa during the install at Summary, so that they can get to a nonfree repository after booting.

> Or for more advanced users, who are used to using the
> command line tools ... 
> 1/ At first reboot after the installation, choose boot in
> safe mode.
> 2/ Use drakrpm-edit-media to activate the Nonfree repository.
> 3/ Install the radeon firmware package, then reboot.

The package is called radeon-firmware-20120322-3, to be precise.

(In reply to comment #90)
[...]
> I'm from documentation team and to me the steps look very clear, apart from,
> but I'm not a native English speaker, the line "Or if non free software
> matters". I don't really grasp what that line means. Does it mean: "If you
> don't want to use non free software"?
[...]
First I would like to apologize for my late answer. Yes it is exactly what my sentence means. Btw I'm far from being a native English speaker, (French is my native language).

@Dave, Frank & Reinout : Many thanks for your help to improve my first draft.

@Manuel in reply to bug 3466 comment 85 : I'm not sure that bug 5426, which is about hybrid graphics, matches exactly this case.

@François : not all the people reporting problems in bug 5426 have hybrid graphics, see comments by Frank and me.