sudo modprobe radeon gives
modprobe: ERROR: could not insert 'radeon': Invalid argument
I have tried oibaf drivers ppa
and also have compiled a custom rt kernel (for audio use), with no joy.
I have tried removing the hw xorg drivers reinstalling xorg-core, but again, no luck.

I've changed the status to critical since I am unable to load the radeon driver at all.
However, I am getting a report from glxinfo that looks like the radeon driver is loaded, unless it is running in software.

I've attached a separate screen via the displayport, and the radeon driver loads and I get the second monitor as a secondary screen, from which I can access kscreen through the settings dialog and then set as the primary.
Throughout this time, the secondary display is working but is dark in comparison to what I would expect, but the primary screen, the imac, is a black screen except for tear type artefacts like barely visible equidistant lines floating upwards.
I would guess that the edid is reported incorrectly, as the imac screen is reported in the settings dialog as 'laptop'.
I'm going to try obtaining and setting an edid etc now.

*** This bug has been marked as a duplicate of bug 98046 ***

I'm not sure if it is a duplicate or not as it happens of bug 98046

Please provide a full dmesg output as attachment.

"modprobe: ERROR: could not insert 'radeon': Invalid argument" either means that your hardware isn't supported for some reason or you manually provided an invalid setting.

Created attachment 140775 [details]
dmesg output with radeon inserted via modprobe

dmesg output - I've attempted to modprobe the radeon module, but the module reports that there is no ums.  If I insert it with nomodeset, it fails.

Created attachment 140776 [details]
results log from ubuntu firmware checking tool

This is the output from the ubuntu firmware inspection tool, which includes relevant snippets of kern.log etc

Hey Christian Konig, thanks for all your hard work on the driver, I've been checking bug 98046 which details something similar, and have seen your work on improving the pll code, which I have been examining to see if I can understand more about this situation, but I'm a noob with graphics processing at this level.

James Cameron in discussion on bug 98046 has examined the pll issue and has resorted to forcing the install of kernel 3.13.0-117-generic.  He has traced the bad commit to 32167016076f714f0e35e287fbead7de0f1fb179

I'm afraid I haven't done any git bisecting of kernels etc and don't even know how, yet, to look up what this commit is - I have some reading to do; I'd like to learn.

This is affecting my imac 2009, which for me was some outlay, as I don't work, and with its virtually unchangeable graphics card is really getting my goat, as I'd really been looking forward to using wayland.

If the modprobe error happens only when nomodeset is on the kernel command line, that's expected, as the radeon driver cannot work with nomodeset. Sounds like the real issue here is the black screen without nomodeset, which is covered by bug 98046?

The issue with commit 32167016076f714f0e35e287fbead7de0f1fb179 is that it fixed things quite a bunch of people, but unfortunately also broke things for some other.

So far we tried to mitigate problems by avoiding known to be problematic configurations, but but it is really hard to find documentation for such old hardware.

Is there any way to selectively swap out that portion of the driver for the inoffensive parts of code for the imac (and perhaps other problematic models) that I have?
Is there any point in me investing time to learn to bisect and learn the coding specifics of plls and calculations etc?
At the moment it is either do something like that, or put up with the vesa driver and cope with the memory loss (I use this machine for audio), or swap out the graphics card.
In the last instance, do you know Christian, if it is possible to find a list of affected cards?
I can exchange my radeon 4850 for a 6970M 2GB, increasing the ram, but there is no point at all, if it doesn't work with the radeon driver, and I will have to pick up my game, quite substantially as a programmer, if I want to edit that myself.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/854.