PC display will not turn on with Llano APUs connected to the VGA port

Created attachment 53026
dmesg log of radeon errors

I have an ASRock A75M motherboard with an A8-3850.

Booting a 3.1 kernel (also tried 3.06), my screen goes blank with modesetting enabled. If I disable modesetting, I am able to boot fine but then X won't work because the X11 driver requires modesetting.

Created attachment 53027
vga bios

Nov 01 12:06:55 [kernel] [ 1.445489] [drm] Initialized drm 1.1.0 20060810
Nov 01 12:06:55 [kernel] [ 1.445828] [drm] radeon defaulting to kernel modesetting.
Nov 01 12:06:55 [kernel] [ 1.445934] [drm] radeon kernel modesetting enabled.
Nov 01 12:06:55 [kernel] [ 1.446077] radeon 0000:00:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Nov 01 12:06:55 [kernel] [ 1.446675] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1849:0x9640).
Nov 01 12:06:55 [kernel] [ 1.446922] [drm] register mmio base: 0xFEF00000
Nov 01 12:06:55 [kernel] [ 1.447024] [drm] register mmio size: 262144
Nov 01 12:06:55 [kernel] [ 1.447234] ATOM BIOS: General
Nov 01 12:06:55 [kernel] [ 1.447361] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
Nov 01 12:06:55 [kernel] [ 1.447538] radeon 0000:00:01.0: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF
Nov 01 12:06:55 [kernel] [ 1.447719] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
Nov 01 12:06:55 [kernel] [ 1.447886] [drm] Detected VRAM RAM=256M, BAR=256M
Nov 01 12:06:55 [kernel] [ 1.447974] [drm] RAM width 32bits DDR
Nov 01 12:06:55 [kernel] [ 1.448195] [TTM] Zone kernel: Available graphics memory: 3950106 kiB.
Nov 01 12:06:55 [kernel] [ 1.448289] [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
Nov 01 12:06:55 [kernel] [ 1.448379] [TTM] Initializing pool allocator.
Nov 01 12:06:55 [kernel] [ 1.448493] [drm] radeon: 256M of VRAM memory ready
Nov 01 12:06:55 [kernel] [ 1.448584] [drm] radeon: 512M of GTT memory ready.
Nov 01 12:06:55 [kernel] [ 1.448685] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Nov 01 12:06:55 [kernel] [ 1.448775] [drm] Driver supports precise vblank timestamp query.
Nov 01 12:06:55 [kernel] [ 1.448897] radeon 0000:00:01.0: radeon: using MSI.
Nov 01 12:06:55 [kernel] [ 1.449013] [drm] radeon: irq initialized.
Nov 01 12:06:55 [kernel] [ 1.449104] [drm] GART: num cpu pages 131072, num gpu pages 131072
Nov 01 12:06:55 [kernel] [ 1.450154] [drm] Loading SUMO Microcode
Nov 01 12:06:55 [kernel] [ 1.458789] radeon 0000:00:01.0: WB enabled
Nov 01 12:06:55 [kernel] [ 1.474954] [drm] ring test succeeded in 2 usecs
Nov 01 12:06:55 [kernel] [ 1.475122] [drm] radeon: ib pool ready.
Nov 01 12:06:55 [kernel] [ 1.475276] [drm] ib test succeeded in 0 usecs
Nov 01 12:06:55 [kernel] [ 1.477539] [drm] Radeon Display Connectors
Nov 01 12:06:55 [kernel] [ 1.477645] [drm] Connector 0:
Nov 01 12:06:55 [kernel] [ 1.477746] [drm] HDMI-A
Nov 01 12:06:55 [kernel] [ 1.477846] [drm] HPD2
Nov 01 12:06:55 [kernel] [ 1.477947] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
Nov 01 12:06:55 [kernel] [ 1.478122] [drm] Encoders:
Nov 01 12:06:55 [kernel] [ 1.478223] [drm] DFP1: INTERNAL_UNIPHY2
Nov 01 12:06:55 [kernel] [ 1.478325] [drm] Connector 1:
Nov 01 12:06:55 [kernel] [ 1.478426] [drm] VGA
Nov 01 12:06:55 [kernel] [ 1.478525] [drm] HPD1
Nov 01 12:06:55 [kernel] [ 1.478626] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
Nov 01 12:06:55 [kernel] [ 1.478779]...

Please attach your xorg log. Which connector(s) are you using?

The problem is happening right at boot. With DRM_RADEON_KMS enabled in my kernel config, the screen goes black immediately after exiting the bootloader. The machines is not wedged because <ctrl-alt-delete> still works.

If recompile with DRM_RADEON_KMS=n, the screen goes black (for longer than I'm used to) but then I see the kernel printks and then a login prompt. When I try to run X with xf86-video-ati I get an error message telling me that SUMO requires KMS. So I'm currently working around by running with the VESA X drivers.

This is a brand new machine which I just brought up yesterday. Windows seems to work fine so I don't think its a hardware issue.

The motherboard comes with a VGA and an HDMI connector. I'm currently using the VGA connector.

I probably should have assigned this to Product:DRI instead Product:xorg since the problem I'm seeing is in the kernel driver and not in the xorg driver.

The DP to VGA bridge chips on a llano APUs are problematic in a lot of cases. You might try a newer kernel or use a digital port (HDMI, DP, DVI) in the meantime.

I've tried 3.0.6, 3.1 and the drm-core-next branch from: git://people.freedesktop.org/~airlied/linux

Is there a radeon linux kernel tree I could test? I'm also happy to test any patches against any tree.

I've ordered an HDMI-DVI cable so I'll give that a shot in a few days.

(In reply to comment #7)
> I've tried 3.0.6, 3.1 and the drm-core-next branch from:
> git://people.freedesktop.org/~airlied/linux
>
> Is there a radeon linux kernel tree I could test? I'm also happy to test any
> patches against any tree.

You can try drm-fixes-staging, but I doubt you'll see any change. I'll be sure to update this bug as I make progress with the NUTMEG chip.

Tested with drm-fixes-staging. Same behavior.

Woot! HDMI works fine.

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

Seeing this here on an Acer Aspire am3470g-uw10p with Radeon HD 6530D. The vga output dies as soon as radeon with KMS is loaded. In process of acquiring HDMI cable to test with HDMI output.

I have tried with 3.3.1 and 3.3.2 and same problem. Using xorg 1.12.1, xf86-video-ati 6.14.4, ati-dri/mesa 8.0.2 on brand new Arch Linux. Also tried Ubuntu 11.10 Live CD and same results.

Adding vga=775 radeon.modeset=0 to kernel boot line gives me a usable console interface and Xorg will actually start that way, but Xorg display is highly corrupted with bands of bright green and red lines.

Ubuntu 12.04 beta 2 gives same result except that it can successfully start a non-corrupted (but incorrect resolution) Xorg server with the kernel boot line above.

I have an identical snippet in my dmesg as the one posted by Mandeep Baines above.

This bug is marked fixed for Ubuntu in Launchpad ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/825777 ) but it doesn't work with a fully up-to-date Arch Linux. I haven't had occasion to try the specific Ubuntu kernel build (3.0.0-17.30) cited as resolving the problem (and it seems to be based on one positive result) and I don't seem to see a patch that would be applicable to a mainline kernel.

lspci:
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI BeaverCreek [Radeon HD 6530D]

So it turns out the monitor didn't have an HDMI input.

The only way I could get it working without an HDMI-DVI cable was to downgrade to Xorg 1.11 and install Catalyst. I'm looking forward to the arrival of an HDMI-capable monitor at that station so I can test the open-source driver more thoroughly (get some quite annoying crashes with Catalyst).

Created attachment 60707
possible fix

This patch fixes things for me.

Doesn't change anything for me.
I tried patching a kernel 3.3.2 and a 3.4.0_rc4 ... should I try with a next-drm or drm-fixes-staging ?

This does not fix the problem for me, either...

Created attachment 60730
dmesg with proposed patch and drm.debug=4

(In reply to comment #16)
> This does not fix the problem for me, either...

(In reply to comment #17)
> Created attachment 60730 [details]
> dmesg with proposed patch and drm.debug=4

Your system doesn't use a NUTMEG chip. It uses TRAVIS for both VGA and LVDS. Please attach a copy of your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Created attachment 60758
dmesg with proposed patch and drm.debug=4

Mine is and the patch doesn't correct the problem.

(please ignore the nouveau stuff this is because I want a dual screen so I put a second card in the machine if not for this problem with the VGA I wouldn't have it)

At least here, I now can boot, however I can't get through a dpms as link training fails.

so one step forward.

Created attachment 60760
vbios

(In reply to comment #19)
> Created attachment 60758 [details]
> dmesg with proposed patch and drm.debug=4
>
> Mine is and the patch doesn't correct the problem.

Does it work if you boot without VGA attached and then enable it later? How about if you disable VGA with xrandr and then re-enable it? E.g.:
xrandr --output VGA-0 --off
xrandr --output VGA-0 --auto

Created attachment 60765
possible fix

Please try this patch in addition to the one in attachment 60707.

Created attachment 60773
dmesg with second patch and drm.debug=4

without the second patch doing

xrandr --output VGA-0 --off
xrandr --output VGA-0 --auto

logs errors in dmesg

[drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max voltage
[drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

---

with the second patch I have exactly the same error...

Created attachment 60774
dmesg booting with monitor unplugged and letting X enabling it (2nd patch applied)

oh sorry the previous log was with monitor connected since boot... with the patch and booting with the monitor unplugged and then plugging it and letting X enable it, it works !

Oh fun. Seeing how the driver seems to mess up things (with your previous comment) with the connectors when booting with both plugged, I tried to boot without the nvidia card and both monitors plugged and the unplugging the VGA monitor during the boot (before X starts) and both screens when off, the VGA one with "no connection" and the DVI with "no signal".

Once X is started both monitors are detected correctly.

Is it somehow linked to the mirror mode the EFI does ?

Well at least I have a hook to get my dual screen working. Just unplug the VGA boot and plug it during boot.

A patch referencing this bug report has been merged in Linux v3.4-rc5:

commit 700698e7c303f5095107c62a81872c2c3dad1702
Author: Alex Deucher <email address hidden>
Date: Fri Apr 27 17:18:59 2012 -0400

    drm/radeon/kms: need to set up ss on DP bridges as well

Does people here have better luck with the patch mentioned previously:

drm/radeon/kms: need to set up ss on DP bridges as well

Well considering the commit pointed is exactly the patch proposed in comment 14 ( https://bugs.freedesktop.org/attachment.cgi?id=60707 ) it is pretty clear that it doesn't do anything for me.

That's why I didn't react at all when the inclusion was advertised.

I have a similar problem: right after boot, my screen works (displays kernel messages) until maybe drm module is loaded (I guess by udev), then it becomes immediately blank and monitor is blinking, and then works again some time after fbcon and radeon modules are manually loaded in boot scripts (before starting X).
It depends on modeset=1; if I use modeset=0 this behaviour doesn't appear, bua X cannot run without KMS.

I have an AMD A4-3300 APU and using a (vanilla) linux kernel 3.5.3 (on Slackware64)

The real problem is that some time (a couple of minutes or so) after video adapter is in idle mode (e.g. if I am not using the PC), monitor blinks (as in low power mode) screen is blank and system is no longer recoverable (unless I use e.g. ssh just to power it off).
I don't know if the two problems are really related or not. Voltage problems?

I have these messages in dmesg, too, when it happens:
"""
[ 2405.888198] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 0, devices 00000001, active_devices 00000001
[ 2405.892352] [drm:radeon_dp_get_link_status], link status 44 44 01 00 44 44
[ 2405.892360] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
[ 2405.892365] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 3.5dB
[ 2405.893921] [drm:radeon_dp_get_link_status], link status 44 44 01 00 48 44
[ 2405.893926] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 6dB
[ 2405.893931] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 6dB
[ 2405.895508] [drm:radeon_dp_get_link_status], link status 44 44 01 00 4c 44
[ 2405.895514] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 9.5dB
[ 2405.895518] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 9.5dB
[ 2405.897079] [drm:radeon_dp_get_link_status], link status 44 44 01 00 41 44
[ 2405.897085] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB
[ 2405.897089] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 0dB
[ 2405.898632] [drm:radeon_dp_get_link_status], link status 44 44 01 00 45 44
[ 2405.898634] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 3.5dB
[ 2405.898636] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 3.5dB
[ 2405.900152] [drm:radeon_dp_get_link_status], link status 44 44 01 00 49 44
[ 2405.900155] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 6dB
[ 2405.900156] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 6dB
[ 2405.901674] [drm:radeon_dp_get_link_status], link status 44 44 01 00 42 44
[ 2405.901676] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB
[ 2405.901677] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V pre_emph 0dB
[ 2405.903194] [drm:radeon_dp_get_link_status], link status 44 44 01 00 46 44
[ 2405.903196] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 3.5dB
[ 2405.903197] [drm:dp_get_adjust_train], using si...

Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6

Created attachment 66808
dmesg booting with 2 monitors plugged drm.debug=4

This drm-fixes-3.6 branch just gives me two black screens when I have them both plugged during the boot. And when X starts I get a 100% processor usage from the X process and nothing displayed. The Xorg.0.log shows nothing out of the ordinary. But I think there is something really wrong because my X server never starts accepting connection from my login manager.

When I boot with only the DVI screen plugged, no problem it boots fine.
After having booted with only the DVI plugging the VGA one works just like before.

When X puts my screens into DPMS off and I try to wake them up, the VGA goes back on correctly with this branch whereas it didn't with vanilla kernel.

So there are some good points and some bad points.

Attached is dmesg | grep -e drm -e radeon when both screens are connected, after X is "started".

You might try this patch on top of my 3.6 fixees tree:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=46b417b3eee694451b5bca8a7863e9174611a2e9

Created attachment 66817
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

With the additional patch, I get the DVI screen displaying things when both a plugged-in but the VGA one now says there is no signal (instead of staying black). So the behavior is somewhat similar to the vanilla kernel in that regard.

Booting with the VGA unplugged and plugging it later gives the same behavior as without that patch (i.e. better than the vanilla kernel).

Attached is the dmesg | grep -e drm -e radeon when the 2 screens are plugged and the VGA says no signal.

Comment on attachment 66817
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Sorry wrong auto-detect of the type...

Created attachment 66819
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Sorry... I appended the new log to the last one instead of overwriting it...
Now there is only the new dmesg information.

Created attachment 66822
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Ok.... I need sleep...
This time is the right dmesg. With both screens plugged during the boot and the patch, but mysteriously this time the DVI screen stayed black and the VGA had no link. And X started to take 100% CPU. So exactly the same behavior as without the patch.

I tried rebooting and then both screens lit up and were black. X using 100% CPU.

the new attachment shows dmesg | grep -e drm -e radeon after both attempts.

You're getting a GPU hang for some reason which may be causing the modeset failure. Can you try with acceleration disabled to take the out of the equation? Try adding:
Option "NoAccel" "TRUE"
to the device section of your xorg.conf

Created attachment 66828
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (X with NoAccel)

I tested a few things and found out that with the patch over drm-fixes-3.6 I generally get the DVI screen working but the VGA has no signal if it is plugged during the boot. The generally is there because sometimes I just get a black screen on the DVI and then X causes a GPU Hangup (The NoAccel suppresses the Hangup). This situation is rare and If the GPU hangup pressing the reset switch (instead of letting the machine off during some time and doing a cold boot) causes it to happen more often.

A "quick" way to do it is booting without the patch starting X without NoAccel and then pressing the reset button and booting with the patch.

Seems the firmware doesn't reset the state of the card properly during POST or something. Last night the problem happened "by itself", so it might happen without trying to provoke it. This morning I tried rebooting a few times but didn't get it to happen without provoking it.

The attachment is dmesg | grep -e drm -e radeon when the DVI screen stays black (VGA saying no signal) and without hangup (provoking it on the previous boot). The last part is X turning the screens off and trying to wake them up. The situation didn't change.

Does your OEM have a newer bios available for your board? It might be worth trying a newer (or maybe older) bios image.

Oh yes there was and now even without the patch my machine displays something on the DVI screen when both screens are plugged and the GPU doesn't hang anymore even without NoAccel (but only from a cold boot, if I reboot/reset I get a black screen and the GPU hangup). So part of the problem was really a firmware issue.

With the patch I can't seem to provoke the GPU hangup anymore.

But my VGA screen continues to be stubbornly off when booting with both screens plugged. Continues to work if I plug my VGA screen after booting.

So now I can start X safely without NoAccel that's one good thing.

BTW my motherboad is an Asus F1A75-M now my firmware is the latest version (2004) upgraded from 1903.

Oh BTW I am booting in uEFI mode using grub-2.00 I don't know if this might change something.

I take back what I said before...
I just did a *very* cold boot (the machine was not connected to the electricity network during the night). I got the black DVI screen and GPU hangup with the patch. So the firmware change didn't do anything in facts...

Sorry for the delay.
The 2nd problem I've reported in comment #30 (when video adapter is in idle, screen blanks and becomes inoperable, error in clock recovery) seems to be resolved here using linux 3.6.0-rc4. BTW I've just one monitor on VGA port.

The 1st problem (at boot, for about 30-40 seconds screen is blanking and monitor LED is blinking; after that, messages appear again in console, before starting X [init 3 mode]) seems to be still present, though.
I will test last drm-fixes-3.6 patches ASAP.

Thank you.

Sorry, I've managed to resolve my first problem (screen blanking after boot for about 30-40 seconds): it is not related to drm, but it depends on fbcon loaded as a module (instead of it being compiled statically).

As explained in /usr/src/linux/Documentation/fb/fbcon.txt if fbcon is compiled as a module (CONFIG_FRAMEBUFFER_CONSOLE=m) it can produce blanking and/or garbage on display if it is not loaded immediately.
If "Framebuffer Console support" is compiled statically (CONFIG_FRAMEBUFFER_CONSOLE=y) there is no blanking here.
"Works for me"
HTH.

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

I can confirm that this bug is still present in Linux 3.8.0, using X Server 7.7 and driver 7.1.0. As graphics are initialized screen just goes black.

-- 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/231.