|Summary:||Garbled screen on boot|
|Component:||Video(DRI - non Intel)||Assignee:||drivers_video-dri|
|Kernel Version:||All after 3.13.6-20||Tree:||Mainline|
|Attachments:||Image of issue|
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 <firstname.lastname@example.org> Date: Sat Jan 11 10:55:55 2014 -0500 drm/radeon: disable dpm on BTC Still unstable on some boards. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=73053 https://bugzilla.kernel.org/show_bug.cgi?id=68571 Signed-off-by: Alex Deucher <email@example.com> Cc: 3.13 <firstname.lastname@example.org> # 3.13 :040000 040000 c03cf693d8be0e49e0b431b968c4934324344d57 f4fa27f78f5ff03216036f8bcdc3978b274b812f M drivers Thanks! 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: https://bugs.freedesktop.org/show_bug.cgi?id=43655 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.