dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 31213] New: [drm] *ERROR* with KMS (any kernels 2.6.3x.x) and ati mobility radeon X300
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=31213 Summary: [drm] *ERROR* with KMS (any kernels 2.6.3x.x) and ati mobility radeon X300 Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: djnass_18(a)hotmail.com when loading the 'radeon' driver with modeset=1 (KMS enabled) the following error appears in dmesg | grep drm [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). the result is that OpenGL renderer with be the 'software rasterizer'. and performance is obviously crippled. glxinfo returns: OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.8.1 The error occurs with kernels 2.6.33.4, 2.6.35.7 and even the latest at the time 2.6.36. The pc is a toshiba satellite m40-185 laptop with ati mobility radeon X300 (rv370) gpu. Additionally, I have tried installing the git versions of libdrm, mesa, and xf86-video-ati to this date (29/10/2010) with Gallium support (enabled in turn --enable-gallium, --enable-gallium-radeon and even both, using llvm (version 2.8) compiler. The problem persists. The only way to get 3d accelaration is to disable KMS. then dmesg | grep drm seems to load up fine (see here: http://pastebin.com/vNfyeq7P). But then I have problems with 3d applications 'competing' to stay on top - they don't seem to be able to work well with KDE4 compositing effects. To avoid that I have to disable the compositing effects ( see here for in depth explanation and some Xorg.0.log and dmesg outputs http://www.linuxquestions.org/questions/slackware-14/3d-applications-compet… ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[Bug 100891] failed to send pre message kernel output delays booting/suspending/resuming
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100891 Bug ID: 100891 Summary: failed to send pre message kernel output delays booting/suspending/resuming Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: harn-solo(a)gmx.de Created attachment 131160 --> https://bugs.freedesktop.org/attachment.cgi?id=131160&action=edit dmesg output (kernel 4.9) Starting with kernel version 4.9 the boot process, s3 suspend and s3 resume is delayed by kernel messages like the following [ 17.322912] failed to send pre message 148 ret is 0 [ 17.543482] failed to send message 148 ret is 0 for a very long time, e.g. 10 min (see attachment for a full dmesg log). When the system is fully booted everything else seems to be fine. I'm not sure if it is related at all, but I did a quick bisection: between 4.9-rc2 and 4.9-rc3, with the introduction of commit 3b496626ee8f07919256a4e99cddf42ecd4ba891 I had to supply a new firmware file (topaz_k_smc.bin) otherwise my screen remains black. After supplying the missing firmware-file from from linux-firmware.git I noticed the long boot delay and the messages. Kernel series 4.11-rcX reduces the delays drastically, down to around 1-2 minutes but after a resume from s3 the GPUs gets hot very quickly without fans kicking in until it reaches some sort of emergency mode with short bursts of jet engine like fans. This happens on the kernels 4.9-rc3 up to the latest 4.11-rc, always tested with the latest set of firmware files. My GPU-hardware is a Sapphire R9 380X: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition] (rev f1) 05:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aad8 -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 30620] New: KMS on RS100: no display on VGA
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=30620 Summary: KMS on RS100: no display on VGA Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: zajec5(a)gmail.com I've bug report from user with old notebook with ATI 320M (RS100). She installed openSUSE 11.3 which comes with 2.6.34 and can not get driver display anything. The important part is that notebook's PANEL is broken and she uses VGA for external monitor. There are two KMS cases I got tested by her: 1) "vga=0x31a" ─ black VGA screen right after booting start 2) "" (no vga) ─ black VGA screen right after booting start So I asked to experiment with UMS a little: 3) "vga=0x31a radeon.modeset=0 3" ─ radeonfb loads, VGA works! 4) "vga=0x31a radeon.modeset=0" ─ radeonfb works, black VGA screen on X start Without radeonfb: 5) "radeon.modeset=0 3" ─ pure console works on VGA, no radeonfb 6) "radeon.modeset=0" ─ pure console works on VGA, black VGA on X start My conclusions: 1) KMS can not initialize VGA 2) UMS can not initialize VGA 3) radeonfb *can* initialize VGA 4) There is no conflict with radeonfb, as dropping "vga=0x31a" does not help What else can I ask for to make it debuggable? I thought of Xorg.0.log but it may be hard to get for her as she had to mount some USB storage in console and copy file to it. Taking "dmesg | grep drm" could be easier. Would it be useful? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 15

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100745 Bug ID: 100745 Summary: amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed' Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: mr.nuke.me(a)gmail.com On a Fedora 25 system, under kernel 4.10.9, I have an RX480 with three Dell P2715Q monitors connected via displayport. 1. The machine is left alone, until the monitors are put into sleep mode. 2. The mouse is moved until the monitors show signs of coming up. It is expected that all monitors come up cleanly and an unlock screen is presented. What actually happens is that not all monitors come up. Some monitors indicate that no signal is coming. Which monitor or monitors fail to come up is non-deterministic. Every time this happens, dmesg shows exactly three entries of the form: [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed It doesn't matter how many of the three monitors come up, dmesg always shows this message three times. I've modified the failure point to print the return value of drm_dp_dpcd_read_link_status(), and it comes back as -5. I believe that is -EIEIO Also, switching to VT2, via Ctrl-Alt-F2 brings up all the monitors with 100% success rate. Switching back to VT1 may either: * present a working unlock screen (20% of the time) * present an unlock screen with Xorg being locked up in a poll() call (50% of the time) * or completely crash Xorg (20% of the time) * lock up the machine (10% of the time) This procedure crashes wayland with 100% yield. -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 30325] New: video=1280x720@50 no longer works
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=30325 Summary: video=1280x720@50 no longer works Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: marius.groeger(a)web.de With the current drm-radeon-testing my grub cmdline option video=1280x720@50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 6 weeks ago works and correctly uses the EDID reported 1280x720@50 mode. I did ask the same thing on the dri-devel mailing list and received no answer so I'm filing this bug both as another humble nudge to the authors of the drm video= code, and as a more persistent reminder of the issue. Thanks Marius -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

[Bug 30227] New: Radom X.org freeze by a GPU lockup
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=30227 Summary: Radom X.org freeze by a GPU lockup Product: DRI Version: XOrg CVS Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: kronat(a)tiscali.it Created an attachment (id=38743) --> (https://bugs.freedesktop.org/attachment.cgi?id=38743) dmesg after the fail Apparently random GPU lockup (ati r300), with X.org freeze. It happens more frequently if I compile and I switch over many applications (firefox, terminal, opera). Attached there is the dmesg after the fail (I could continue to work on others console - ctrl+alt+f1,2,3..). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 16

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100742 Bug ID: 100742 Summary: dpm auto doesn't clock the GPU high enough for SteamVR apps Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: haagch(a)frickel.club RX 480, Ryzen 1600X, tested on linux 4.10 and linux drm-next-4.12-wip, latest upstream linux-firmware git. Same behavior on both kernels. I recorded this video, showing umr top, sclk and mclk, while running the simple "Atlas Demo Scene" in the Destinations SteamVR app: https://www.youtube.com/watch?v=U_mceDSBF7o With the "auto" setting the GPU power level is not set high enough for SteamVR to render at the Vive's native 90 fps, so reprojection (interpolation to 90 fps) needs to kick in constantly. Speculation time: The SteamVR frametime graph shows the purple GPU load from the application ("Destinations") completely below the 11 ms which the application is probably is probably targeting, so dpm has clocked the GPU fast enough for the application to run at 90 fps. But then the application submits frames to the SteamVR compositor which also takes some GPU time and pushes the "total" GPU time taken to render one frame in the app and then display it in the compositor over the target 11 ms time. Is this correct? Does dpm somehow analyze a per process GPU load? At least in this case the GPU needs to clock fast enough to allow the application + the SteamVR compositor to both render in under 11 ms per frame. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100726 Bug ID: 100726 Summary: [REGRESSION][BISECTED] Severe flickering with an R9 290 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: hiwatari.seiji(a)gmail.com As of the commit: d8d1721cfb3162abbda078d67a928792d6552b84 : A series of fixup patches meant to fix the usage of DMA on stack, plus one warning fixup My R9 290 produces heavy flickering artifacts in 1 of 3 or 4 cases when starting Linux. I am using the amdgpu kernel module, and have not tested this with radeon. When the bug occurs, the system is completely unusable. Since the occurence of this bug is not really deterministic, bisecting it was not that easy. I hope I didn't make any mistake. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 29941] New: radeon/KMS: Screen hotplugging does not work any more
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=29941 Summary: radeon/KMS: Screen hotplugging does not work any more Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: direx(a)betriebsdirektor.de I noticed that in recent kernel versions the runtime detection of newly added monitors does not work properly. When I plug in my TV (DVI2HDMI) after booting I cannot enable it. xrandr correctly shows a new screen and I can even enable the output, but the TV screen stays black. Restarting X does not help. The driver also seems to recognize the port status after plugging it in (/sys/class/drm/card0-DVI-I-2/status) changes from "disconnected" to "connected". When I plug the HDMI cable in _before_ booting my computer the TV works just fine. GFX: Radeon HD 3870 Linux: 2.6-git (issue appeared in 2.6.35) with KMS Mesa: git libdrm: git xf86-video-ati: git -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 29787] New: random XRandR failures (i2c related?)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=29787 Summary: random XRandR failures (i2c related?) 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: aelschuring(a)hotmail.com A few weeks ago, X started displaying weird errors during normal use. These range from simple output resets to application crashes due to X BadAlloc responses. In detail, this is what I see happening: - output blink. Usually the screen goes dark for about a second. When the screen returns, I see either: - display position getting cancelled (xrandr --pos 0x0) on my left screen when this happens I can usually get it back to the correct position via the xrandr command line tool, but sometimes that triggers a WM crash - display rotation getting cancelled (xrandr --rotate normal) on the right screen. When this happens: - quodlibet (python-gtk app) crashing with BadAlloc (serial 255 error_code 11 request_code 53 minor_code 0). It will keep crashing like this until I restart X - whatever other app I had running on the right screen has disappeared as well - window manager (e17) crashing. It can recover succesfully, though - when I re-enable screen rotation, the display gets completely garbled I have started seeing this happen with 2.6.35-rc3 (was running 2.6.34-rc6 before that), and with 2.6.35.1 this happens a lot less frequently (from once a day to twice in a week). >From the latest crash, I can give the following info from xsession-errors: (E17 init) E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0 E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896 (output blinking starts) E17 INIT: XINERAMA SCREEN: [0], 1280x1024+0+0 E17 INIT: XINERAMA CHOSEN: [153045780], 0x153045764+0+153046580 (e17 crash, try to recover) E17 INIT: XINERAMA CHOSEN: [1], 1920x1080+1280+0 E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+0 (rotation lost on [1], position lost on [0]) E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0 E17 INIT: XINERAMA CHOSEN: [141138596], 0x141138580+0+141139396 E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896 (restoring rotation confuses E17) ###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 6 requests ago: file nsX11ErrorHandler.cpp, line 182 UNKNOWN [/usr/lib/xulrunner-1.9.2/libxul.so +0x001CA781] (firefox crashing) Now, the reason for the E17 crash looks like a use-after-free bug. Question is: who is freeing the Xinerama structures, and why are they freed at all? I never had these problems before, and when using stock 2.6.32 (from Debian) I don't have these problems either, so I'm ruling out hardware failure. I can see the following lines logged by the kernel (KMS enabled on radeon 9550): [12045.280155] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID [13500.386132] [drm:radeon_vga_detect] *ERROR* VGA-1: probed a monitor but no|invalid EDID [13797.568760] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID And I believe these are harmless (and reported in #27708). I can see these messages being reported for as long my kernel logs go back. But when the crashes occur, they are followed by these lines: [35753.097508] i2c i2c-1: sendbytes: NAK bailout. [35762.752866] i2c i2c-1: sendbytes: NAK bailout. [35772.912023] i2c i2c-1: readbytes: ack/nak timeout Which I believe are not so harmless. Or they could be a red herring, I'm not qualified to tell. Since the same time, I've been seeing a lot of lines logged by g-s-d, like gdk_pixbuf_format_get_name: assertion `format != NULL' failed But I do not believe these are relevant. -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017