Bug 82431 - Garbled screen on boot
Summary: Garbled screen on boot
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
Depends on:
Reported: 2014-08-15 04:34 UTC by Fede
Modified: 2017-09-19 00:59 UTC (History)
1 user (show)

See Also:
Kernel Version: All after 3.13.6-20
Tree: Mainline
Regression: No

Image of issue (962.76 KB, image/jpeg)
2014-08-15 04:38 UTC, Fede

Description Fede 2014-08-15 04:34:08 UTC
When using any kernel higher than 3.13.6-20 (all the way to 3.16), my Toshiba M840's screen gets garbled after Grub (grub itself is fine).

In particular, because my whole drive is encrypted, I see the garbled screen when the prompt for the encryption key comes up.

I have the issue with my OpenSUSE installation and when booting off Archlinux's installer.

I'm not sure if this is relevant but this happens on UEFI, if I change the setting back to BIOS compatibility, at least on the Archlinux's installer, the issue goes away. I can't test this on OpenSUSE since it is already set to UEFI and will not boot on BIOS compatibility mode.

The issue has quite an impact since I can't bootup in a usable way, any Linux distribution with a kernel newer than the one stated above.

I did a kernel bisect and found the below commit to be the cause of the issue:

[919cf555c04e16dafb1fba56904eb23889a812c3] drm/radeon: disable dpm on BTC
919cf555c04e16dafb1fba56904eb23889a812c3 is the first bad commit
commit 919cf555c04e16dafb1fba56904eb23889a812c3
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sat Jan 11 10:55:55 2014 -0500

    drm/radeon: disable dpm on BTC

    Still unstable on some boards.


    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: 3.13 <stable@vger.kernel.org> # 3.13

:040000 040000 c03cf693d8be0e49e0b431b968c4934324344d57 f4fa27f78f5ff03216036f8bcdc3978b274b812f M      drivers


Details about my GFX card:

21: PCI 100.0: 0300 VGA compatible controller (VGA)             
  [Created at pci.319]
  Unique ID: VCu0.dkF2+KIVH8C
  Parent ID: vSkL.zuRwVyuZRN1
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "ATI VGA compatible controller"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x6840 
  SubVendor: pci 0x1179 "Toshiba America Info Systems"
  SubDevice: pci 0xfb81 
  Driver: "radeon"
  Driver Modules: "drm"
  Memory Range: 0xb0000000-0xbfffffff (ro,non-prefetchable)
  Memory Range: 0xc0000000-0xc001ffff (rw,non-prefetchable)
  I/O Ports: 0x3000-0x3fff (rw)
  Memory Range: 0xc0040000-0xc005ffff (ro,non-prefetchable,disabled)
  IRQ: 43 (76519 events)
  Module Alias: "pci:v00001002d00006840sv00001179sd0000FB81bc03sc00i00"
  Driver Info #0:
    Driver Status: radeon is active
    Driver Activation Cmd: "modprobe radeon"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #9 (PCI bridge)
Comment 1 Fede 2014-08-15 04:38:56 UTC
Created attachment 146691 [details]
Image of issue

At times only a thin dotted line can be seen on the top, other times the content is displayed flickering, starting from the center of the screen and wrapped around the screen from right to left. When it does not flicker, the screen looks as shown in the attachment.
Comment 2 Alex Deucher 2014-08-15 04:46:27 UTC
I doubt that commit is the problematic one.  However, you can revert to the previous behavior by passing radeon.dpm=1 on the kernel command line in grub.

This looks like a duplicate of:
Does your grub config have GRUB_GFXPAYLOAD_LINUX=keep in it?  If so, does removing that help?
Comment 3 Fede 2014-08-15 05:18:41 UTC
Hi Alex,

In deed, adding radeon.dpm=1 works. I tested it after submitting the bug report since I went thru what the actual patch changed. Currently running kernel 3.16.0-5 and it works as long as radeon.dpm=1 is passed to the kernel. 

GRUB_GFXPAYLOAD_LINUX=keep (nor text) did make any difference.

Can this be permanently fixed for everyone affected?
Comment 4 Alex Deucher 2014-08-15 05:24:25 UTC
(In reply to Fede from comment #3)
> Hi Alex,
> In deed, adding radeon.dpm=1 works.

> Can this be permanently fixed for everyone affected?

The issues with dpm on btc asics were fixed in 3.16 and it's enabled again on those asics in 3.17.
Comment 5 Fede 2014-08-15 06:43:22 UTC
So the issue is fixed in 3.17? Using that kernel I should not need to use radeon.dpm=1 anymore?
Comment 6 Alex Deucher 2014-08-15 07:05:56 UTC
dpm is enabled by default in 3.17 so you don't need to append radeon.dpm=1 anymore to enable it.

Note You need to log in before you can comment on or make changes to this bug.