Bug 98046

Summary: iMac11,1 (RV770/M98L [Mobility Radeon HD 4850]) needs nomodeset to boot
Product: xorg Reporter: Nicolas Jungers <freedbug>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: jamesstewartmiller, quozl
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.log of a failed boot
none
dmesg output on 16.04
none
dmesg of first failed commit
none
possible fix
none
possible fix
none
dmesg with "drm/radeon: adjust pll flags for RV770"
none
xorg.0.log
none
xorg.0.log.old
none
results.log from the ubuntu firmware checking tool none

Description Nicolas Jungers 2016-10-04 18:07:35 UTC
Created attachment 127000 [details]
Xorg.log of a failed boot

My iMac11,1 was running Ubuntu since the beginning and till 14.04 fine but gave a black screen, with sometimes horizontal lines flowing since 15.04.

After applying the Apple patches Mac EFI Security Update 2015-002 (https://support.apple.com/kb/DL1848?locale=en_US) and 27-inch iMac SMC Firmware Update 1.0 (https://support.apple.com/kb/DL1030?locale=en_US), my iMac was unable to boot in graphical mode without the nomodeset kernel parameter.

Grub console is sluggish (but not for Ubuntu 11.10 and 12.04), sleep doesn't work and overall graphic performances are bad.

I had to install OSX El Capitan for flashing the iMac and I didn't have issues in OSX.

I join an Xorg.log of a failed boot (without nomodeset).
Comment 1 Alex Deucher 2016-10-04 18:22:30 UTC
Please attach your dmesg output.  Was it the firmware updates the caused the regression or an Ubunutu update?  If it's an Ubuntu update, can you narrow down what update caused the regression?  If it's a firmware update, you'll probably have to take that up with Apple.
Comment 2 Nicolas Jungers 2016-10-04 18:27:33 UTC
Created attachment 127003 [details]
dmesg output on 16.04
Comment 3 James Cameron 2017-04-18 06:28:52 UTC
Created attachment 130894 [details]
dmesg of first failed commit

Same with another iMac11,1, but no firmware update.  Kernels before 3.14 are fine.  Kernels from 3.14 show blank display or sometimes flickering horizontal lines.

I've done a git bisect and first failing commit is 32167016076f714f0e35e287fbead7de0f1fb179 "drm/radeon: rework finding display PLL numbers v2" by Christian König.

Happy to test kernels or enable debugging, let me know.
Comment 4 James Cameron 2017-04-18 09:16:59 UTC
Tested 4.11.0-rc7 as-is, and drm.debug=0xe, display was flickering horizontal lines, and got PLL setup of;

[drm:radeon_compute_pll_avivo [radeon]] 360000 - 366660, pll dividers - fb: 22.0 ref: 2, post 3

Tested 4.11.0-rc7 by reverting all the PLL changes (overkill);

72edd83cc9e58 ("drm/radeon: fix PLLs on RS880 and older v2")
4b21ce1b4b5d2 ("drm/radeon: lower the ref * post PLL maximum once more")
3b333c55485f ("drm/radeon: avoid high jitter with small frac divs")
c2fb3094669a ("drm/radeon: improve PLL limit handling in post div calculation")
24315814239a ("drm/radeon: use fixed PPL ref divider if needed")
f8a2645ecede ("drm/radeon: improve PLL params if we don't match exactly v2")
32167016076f ("drm/radeon: rework finding display PLL numbers v2")

display was good, and got PLL setup of;

[drm:radeon_compute_pll_avivo [radeon]] 36000, pll dividers - fb: 54.0 ref: 5, post 3
Comment 5 Alex Deucher 2017-04-18 14:27:21 UTC
Created attachment 130899 [details] [review]
possible fix

Does this patch help?
Comment 6 Alex Deucher 2017-04-18 14:30:30 UTC
Created attachment 130900 [details] [review]
possible fix

Narrow the focus to just rv770.
Comment 7 James Cameron 2017-04-18 22:54:39 UTC
Created attachment 130908 [details]
dmesg with "drm/radeon: adjust pll flags for RV770"

Thanks, but no, not fixed by 3cc2ebbca98 "drm/radeon: adjust pll flags for RV770".  Result was blank display.  Captured dmesg by ssh, attached.
Comment 8 Justin Thiessen 2017-08-23 06:41:06 UTC
Hi,

I'm still seeing this issue with an iMac11,1 with the identical graphics (RV770/M98L [Mobility Radeon HD 4850])

This is with kubuntu 17.04:

kernel: 4.10.0-32-generic

radeon driver info:
--------------------
libdrm-radeon1:amd64                   2.4.76-1
xserver-xorg-video-radeon              1:7.9.0-0ubuntu1

I only get a working main display using 'nomodeset', which of course is disabling the radeon driver.

Any suggested patches or things to try?

Thanks,

Justin Thiessen
Comment 9 James Cameron 2017-08-23 08:13:26 UTC
Other than reverting the series in comment 4, I've no solution.  Once I had that workaround, I was mostly happy.  I wanted to find the underlying problem and upstream it, but ran out of time.

At one stage I was using "avivotool regs pll1" to confirm the PLL registers, comparing between last working kernel version, latest kernel, and my kernel with the series reverted.

My notes have outstanding questions that I didn't get to resolve; 

1. how to achieve a dot clock of 360000 instead of 366660, given that 360000 works for me?

2. why is RADEON_PLL_PREFER_LOW_REF_DIV set given that the bit is only used when RADEON_PLL_LEGACY is set?

3. why set RADEON_PLL_PREFER_MINM_OVER_MAXP given that it limits the ref_div to 7 yet the system has already chosen 2 instead of 5.

Hope that helps.
Comment 10 Justin Thiessen 2017-08-25 12:33:29 UTC
Thanks James - I'll give this a shot
Comment 11 Justin Thiessen 2017-08-26 12:12:39 UTC
so with the reversions from comment 4 (some conflict resolution by hand necessary, but seemed straightforward), the radeon driver loads and the primary display gets initialized and seems to work.

seems like either:
* the screen dimming is broken resulting in a dark primary screen when that kicks in

or 

* after suspend the secondary display becomes primary and the internal screen is dark.

haven't yet dug into this.

looks like i'm seeing occasional artifacts as well.

This is with kubuntu 17.04, kernel:

4.10.0-32-generic #36-Ubuntu SMP

Definitely progress, considering
Comment 12 James Cameron 2017-08-27 08:48:13 UTC
Great.  Sounds like what I observed.  I seem to recall there were two sysfs entries for brightness, and both were effective.  I don't have automatic dimming enabled, so didn't notice a problem.  I don't suspend at all, because it has never worked after resume.  I'd forgotten to check.
Comment 13 jamesstewartmiller 2018-07-22 07:18:25 UTC
Did you have any luck with this?

I have a late 2009 imac and on installing kubuntu 18.04 the radeon driver fails with a dark screen or defaults to vesa complaining  - modprobe: ERROR: could not insert 'radeon': Invalid argument   if I use the nomodeset option from boot (via refind).
I've reported this in bug 107324.
Comment 14 jamesstewartmiller 2018-07-22 07:53:48 UTC
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.
Comment 15 jamesstewartmiller 2018-07-22 08:11:51 UTC
Created attachment 140762 [details]
xorg.0.log

this is with the external screen attached.  I've attached another file of xorg.0.log.old with no screen attached and a failed boot.
Comment 16 jamesstewartmiller 2018-07-22 08:12:20 UTC
Created attachment 140763 [details]
xorg.0.log.old

failed boot log
Comment 17 jamesstewartmiller 2018-07-22 08:13:29 UTC
*** Bug 107324 has been marked as a duplicate of this bug. ***
Comment 18 jamesstewartmiller 2018-07-22 08:17:38 UTC
I am currently running a rt compiled kernel for audio use at the latest patch level, so 4.9.98, but I get the same problem on the generic installed kernel that is 4.17 I think.  I'll check now.
Comment 19 jamesstewartmiller 2018-07-22 08:21:40 UTC
the generic is 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Comment 20 jamesstewartmiller 2018-07-22 08:41:41 UTC
looks like the edid is fried.

his is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Only trying 6 as per your request.
256-byte EDID successfully retrieved from i2c bus 6
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
        Identifier "Color LCD"
        ModelName "Color LCD"
        VendorName "APP"
        # Monitor Manufactured week 28 of 2009
        # EDID version 1.4
        # Digital Display
        DisplaySize 600 340
        Gamma 2.20
        Option "DPMS" "true"

        #Extension block found. Parsing...
extb[4]: 0x23 (0x20)
Hmm, you have data blocks, but not video ones... weird
Something strange happened. Please contact the author,

I'll try updating the apple firmware to see if that might help.
Comment 21 jamesstewartmiller 2018-07-22 11:08:55 UTC
Created attachment 140768 [details]
results.log from the ubuntu firmware checking tool

from https://wiki.ubuntu.com/FirmwareTestSuite/
Comment 22 Michel Dänzer 2018-07-23 08:13:52 UTC
(In reply to jamesstewartmiller from comment #14)
> I would guess that the edid is reported incorrectly, as the imac screen is
> reported in the settings dialog as 'laptop'.

FWIW, sounds rather like the settings app just incorrectly assumes that only laptops have eDP outputs.
Comment 23 jamesstewartmiller 2018-07-23 19:05:16 UTC
Thanks, I thought that the display size was incorrect, but I have since seen how the size is calculated.
Comment 24 James Cameron 2018-07-24 02:18:05 UTC
Thanks for asking, James.  No, I've no progress to report since my previous comments here.  I'm still using a local kernel on the affected machine, and haven't had time to resolve the outstanding questions I listed.  Let me know if you need any information.
Comment 25 Martin Peres 2019-11-19 07:57:56 UTC
-- 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/xorg/driver/xf86-video-ati/issues/164.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.