dri-devel July 2016

dri-devel@lists.freedesktop.org

199 participants
1323 discussions

[Bug 58981] New: Bisected regression; boot failure with Radeon 9250 PCI 256MB + KMS
by bugzilla-daemon＠bugzilla.kernel.org 28 Jan '20

28 Jan '20

https://bugzilla.kernel.org/show_bug.cgi?id=58981 Summary: Bisected regression; boot failure with Radeon 9250 PCI 256MB + KMS Product: Drivers Version: 2.5 Kernel Version: 2.6.35,3.2.45,3.10-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: jdietrch(a)fastmail.fm Regression: Yes I have a Radeon 9250 PCI 256MB video card in my machine. I discovered that this machine would not boot with 3.2.45 when KMS was enabled by default in the kernel config. Immediately after the grub menu, the screen would go black and nothing more would happen. Or sometimes columns of character-sized "marks" would appear on the screen. In either case, though, the machine would not boot. So I went back to 2.6.33 and found that booting with KMS did work just fine there. So I used git bisect to find where the problem arose, and that pointed to this commit which was merged for 2.6.35: commit 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 Author: Jerome Glisse <jglisse(a)redhat.com> Date: Wed Apr 7 10:21:31 2010 +0000 drm/radeon/kms: enable use of unmappable VRAM V2 I confirmed this result of git bisect by checking out 2.6.35 final and reverting that one commit, and the resulting kernel booted fine with KMS enabled by default. I also tried 3.10-rc2 and that booted fine when I added radeon.modeset=0 to the kernel commandline. I will attach files with dmesg output and lspci. Please let me know if there is anything else I can do. I'll be happy to test a proposed fix if that would be helpful. Thank you, James Dietrich -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 6

[Bug 64721] New: Radeon HD6450 fails on all distro's out of box.
by bugzilla-daemon＠bugzilla.kernel.org 02 Dec '19

02 Dec '19

https://bugzilla.kernel.org/show_bug.cgi?id=64721 Bug ID: 64721 Summary: Radeon HD6450 fails on all distro's out of box. Product: Drivers Version: 2.5 Kernel Version: Linux 3.2.04-amd64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: ichapman(a)videotron.ca Regression: No I think I'm at the right place to report video card frustrations. Radeon HD450 fails to work out of the box with any Linux. With Debian Wheezy I need to edit the grub line starting with linux and add vga=791 to do anything. vga=771 fails With Knoppix 7.0 I need vga=771 and that's okay, but vga=791 the left half of screen is on right and right on left. The cursor moves to right falls off the screen and re-appears on left side. Very strange. With DebianMint I need vga=771 or 791 to get it to work. On my Acer Aspire laptop with a Radeon HD6310 I do not need any of this vga= stuff. I am sure that this is not a driver problem. All the vga=xxx does is kick it somewhere so that I loads the driver. My Motherboard is M2V-Mx from Asus and once the /etc/default/grub is fixed with GRUB_CMDLINE_LINUX="vga=791" or 771 it's okay. (sudo update-grub of course) I recently junked my Nvidia 8500GT video because the driver for that became sick, the worst feature was not being able to display the layout of the pcb tool unless I disabled the driver and used cpu sw rendering on the video but that's an other story. Ian. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
by bugzilla-daemon＠freedesktop.org 25 Nov '19

25 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97055 Bug ID: 97055 Summary: Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: darktjm(a)gmail.com Created attachment 125267 --> https://bugs.freedesktop.org/attachment.cgi?id=125267&action=edit dmesg from my latest boot (with some wifi messages at end deleted for privacy) I have an HP Pavilion 17-g133cl with A10 Carrizo+Topaz. I struggled for hours/days to get this to actually display anything at all using the amdgpu driver. In the mean time, efifb works perfectly every time (except of course no 3d, no X resolution switching, no brightness control, and slow enough that video playing is also impossible). Since it seemed like there were just issues powering up the display controller correctly, I decided at first to add my notes to https://bugzilla.kernel.org/show_bug.cgi?id=117591 but my symptoms (and cures) are, indeed, different. After much blind playing with my system (I have no way to ssh in, and the keyboard is flaky as well, so that was a lot of fun), I made the following observations: - kernel power management options appeared to have no effect - sometimes (very rarely), it just starts working, regardless - once it starts working for more than 1 minute, it stays working - often, it starts partially working, by giving me a flickering display - often, it starts working with a stable display, only to start flickering again after a few seconds (very rarely even going completely black gain) - my first way of fixing it is fairly reliable, but almost always requires at least one blind reboot before it starts giving my a display: xrandr --output eDP --crtc 1 (added to my .xinitrc) - if, when it finally comes up, it is flickering, it can be cured by toggling the crtc between 0 and 1 often enough until it remains stable for at least a minute. - if crtc 1 is enabled when X is killed, the machine goes blank and hangs hard; switching consoles while X is up works, though (although the consoles remain black). - changing the crtc to 1 in X does nothing for the console; only X displays anything. I have not tried to write a libdrm program to make the console switch to crtc 1, nor have I managed to trace where the crtc list comes from, or how to force it in the amdgpu driver itself. - if, instead of playing with the crtc, I play with power management again, I seem to be able to get it working by booting once with power management enabled, then rebooting with it disabled, and then it works (video in console as well as X, and no crtc switching necessary). However, that may just have been how it decides to work today, and tomorrow it will no longer work. I get identical behavior with kernels 4.6.2, 4.6.3, 4.6.4, 4.7-rc4 (which I decided to try given the supposed major amdgpu overhaul), 4.4.15 (which I decided to try given that the poster of the kernel.org bug was using Ubuntu's 4.4 kernel) (all on Gentoo; with the exception of 4.7-rc4, this is with Gentoo's fbdecor patches, but I obviously have that disabled while working through this problem). Overall, this is very weird and frustrating. I've had power management issues with previous Radeon laptops (all of them), but the gpu pm issue usually manifested as hard locks while playing games with power management enabled, not this crap. I have a feeling that anything that gets it to work only gets it to work due to random chance, and it's just that I'm beating at it often enough that I finally hit the jackpot at some point, and it keeps working correctly until I power cycle for an extended period again. I also get the feeling that I must be a major masochist to keep using ATI/AMD hardware, given that in 15+ years of using it I've never had an experience better than "meh, mostly works". If I weren't dead broke, I'd have chucked this machine over a freeway overpass and bought something else. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[PATCH 0/2] drm/mipi-dsi: support low power transmission
by Inki Dae 20 Nov '19

20 Nov '19

This patch considers low power transmisson to two clock behaviors, non-continuous and continuous clock mode. These two clock behaviors can transmit data in high speed or low power. So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each host driver can setup its host controller properly. Patch 1: Add MIPI_DSI_MODE_LPM flag. If panel driver sets this flag, then msg->flags will have MIPI_DSI_MSG_USE_LPM so that host driver can transmit data in low power. Patch 2: Just exynos part for supporting non-continuous and continuous clock mode. Inki Dae (2): drm/mipi-dsi: consider low power transmission drm/exynos: mipi-dsi: consider non-continuous clock mode drivers/gpu/drm/drm_mipi_dsi.c | 6 ++++++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 +++++++++++++++++++ include/drm/drm_mipi_dsi.h | 2 ++ 3 files changed, 27 insertions(+) -- 1.7.9.5

3 6

[Bug 80684] New: I2C-over-AUX drops single bytes
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=80684 Priority: medium Bug ID: 80684 Assignee: dri-devel(a)lists.freedesktop.org Summary: I2C-over-AUX drops single bytes Severity: normal Classification: Unclassified OS: All Reporter: stefan.bruens(a)rwth-aachen.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI I get frequent errors for the EDID checksum, obviously single bytes are dropped from the EDID. Good EDID: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 55 50 21 00 00 <-- 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d Bad EDID example: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 1c 16 20 58 2c 25 00 55 50 21 00 00 9e <-- 0x71 is missing 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d 00 The position of the dropped byte changes, sometimes the EDID is complete, sometimes several bytes are dropped. The bad EDIDs are *often* accompanied with [drm:radeon_process_aux_ch] dp_aux_ch flags not zero messages. Most probably the common i2c-over-aux code drops the byte, as it starts the transfer again in case of -EBUSY. If I change radeon_process_aux_ch to return -EIO in case of (ReplyStatus == 2), I no longer have any bad checksums. Hardware is Radeon 7750 + Dell U2713HM, connected via DP. Same monitor with Intel Haswell and different cable works without any errors. Kernel is 3.15.1, i.e. without the i2c bus mutex, dont know if this fixes the problems as well. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 92977] Display artifacts when using MST
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=92977 Bug ID: 92977 Summary: Display artifacts when using MST Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: dan.doel(a)gmail.com Created attachment 119730 --> https://bugs.freedesktop.org/attachment.cgi?id=119730&action=edit image 1 - half of window uses different colors I've been trying out the support for tiled MST monitors on Radeon drivers, and seem to be encountering some visual anomalies that seem like they are likely to be related to this component. My setup is two UP2414Q monitors, which have native resolutions of 3840x2160. Over DisplayPort 1.2, they are capable of running as two 1920x2160@60 displays each. I have a nvidia card that is capable of driving them in this mode, so I am reasonably sure that the hardware isn't the problem (unless it is the Radeon card, but that seems unlikely). First, there seems to be a color anomaly with the primary display. The right half of the display has different colors from the left (see first image). I noticed that this may be due to the left half displaying a different color depth than the right. The second image shows the gnome overlay, and while the shadows are smooth on the right, there is banding on the left. My second monitor seems to have both sides in this reduced color mode, and enough fiddling with settings after a boot causes both halves of the primary monitor to be configured that way as well, but needless to say, the reduced color depth (if that's what it is) is undesirable. Second, the secondary monitor has some visual artifacts to the left of center (a vertical band about an inch wide) as well as to the far right (a vertical band around 1/4 inch wide). The third image should give some idea what it looks like. A better photo might show that things in that region look somewhat interlaced, and are repeated horizontally. I apologize for the poor quality of the images, but screenshots don't capture these artifacts, so I had to use my phone. I'm running with packages from Fedora 23, so xorg-server 1.18.0, xf86-video-ati 7.6.0-0.4.20150729git5510cd6, kernel 4.2.5-300. If you'd like any other information, let me know. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 32556] New: screen flickers all the time with desktop image appearing only briefly
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32556 Summary: screen flickers all the time with desktop image appearing only briefly Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: 3ntr0p13(a)gmail.com Created an attachment (id=41344) --> (https://bugs.freedesktop.org/attachment.cgi?id=41344) dmesg Machine is the same as in bug report 28331 although with different software components: Acer Aspire L5100 with an AMD Athlon 64 X2 Dual Core Processor 4000+, this time running a 64 bits debian squeeze. The machine is a small factor desktop machine designed around laptop components, so the graphic card is an integrated radeon x1200. When running a linux vanilla kernel 2.6.37-rc6, the screen flickers all the time making the machine unusable, while with debian kernel 2.6.32-5 such "flick to black" event occur from time to time, making it annoying but usable. While booting with radeon.modeset=0 the problem doesn't exhibits itself The following packages version from debian squeeze are installed: xserver-xorg 1:7.5+8 xserver-xorg-core 2:1.7.7-10 xserver-xorg-video-radeon 1:6.13.1-2+squeeze1 Please find attached Xorg.0.log, dmesg, register dumps for ums and kms for that machine (when booted on 2.6.37-rc6). Regards, Gildas -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 38

[Bug 32422] New: Large images displayed in Firefox appear corrupted
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32422 Summary: Large images displayed in Firefox appear corrupted Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: da_fox(a)mad.scientist.com Created an attachment (id=41150) --> (https://bugs.freedesktop.org/attachment.cgi?id=41150) Picture describing a thousand words. "A picture says more than a thousand words" (aka see attachment) This is what happens when I try to view the XKCD "Online Communities 2" map (http://xkcd.com/802_large/) or other large images in firefox. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 21

[Bug 97157] MST displays fail to wake
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97157 Bug ID: 97157 Summary: MST displays fail to wake Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: dan.doel(a)gmail.com Created attachment 125450 --> https://bugs.freedesktop.org/attachment.cgi?id=125450&action=edit dmesg output Since moving to kernel 4.6, I've been having regular problems with my MST monitors failing to wake after being put to sleep. This only seems to occur after the machine has been on for a sufficient amount of time, but I usually experience it within a day of booting, and typically after the displays have been powered off for an extended period of time. There are two MST monitors, but typically only one fails to wake. Also, it is more often that the secondary display is the one that fails. However, I have had the primary display fail to come back (while the secondary one succeeds), and I have had both fail to come back as well. Sometimes, only a complete power off is able to make the monitors wake up; a reboot is not always sufficient. The dmesg displays some errors, and I've poked around a bit. It seems likely that this is related to commit f3d58dccdbf9f8c0a229d555d4b295d52e743039, which was first included in 4.6. This commit basically causes dpms to work at all with MST monitors; before it was a no-op that didn't actually put the monitors into power saving. That doesn't help narrow the problem down much, though, since a significant portion of the mst dpms code probably wasn't being exercised before that. Also, it seems notable that the error message (which seems more like a debug message) in the STANDBY/SUSPEND/OFF case keeps reporting higher numbers, as though it keeps going through the ON case, which increments the variable, but not making it through the portion of the OFF case that decrements the variable. I'll attach dmesg journal output that might be relevant. I believe the error/debug messages timestamped 'Jul 31 11:03:49' correspond to the first time one of the displays failed to wake up. I tried various ways of toggling the dpms off and on after that, so those are the subsequent error messages in the log. As far as specs go, I have: Radeon HD7870 (Pitcairn) Kernel 4.6.4 (4.6.3 also affected) 2 UP2414Q mst displays xorg-server 1.18.4 Modesetting driver Let me know if there's any more information I can try to provide. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 94153] Unresponsive system on boot with radeon + HD 3870
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=94153 Bug ID: 94153 Summary: Unresponsive system on boot with radeon + HD 3870 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: g47qk(a)ukr.net Created attachment 121755 --> https://bugs.freedesktop.org/attachment.cgi?id=121755&action=edit dmesg.log saved via the serial port I'm using a HD 3870 with Debian 9 Stretch x64 (Testing). When booting to a command line, when drivers are loaded, the screen goes into power saving mode, and the system becomes unresponsive. Booting with `nomodeset' works OK. If I run "#modprobe radeon modeset=1", the screen goes power saving mode, the system stops responding and the caps lock key no longer works (kernel panic?). I've also tested with a Fedora 23 Workstation Live-CD (64-bit), Ubuntu 15.10 Desktop (64-bit) Live-CD, SystemRescueCd-x86-4.7.0 with the same results (unresponsive on driver load). I've tested a ATI X1600 Pro in the same system, and everything works fine. #lspci -nnn | grep VGA 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV670 [Radeon HD 3870] [1002:9501] -- You are receiving this mail because: You are the assignee for the bug.

1 13

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2016