dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=89327 Bug ID: 89327 Summary: Loss of HDMI audio on auto screen off (energy saving) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: john.ettedgui(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Since moving to 4.0-rc1 when my screen goes off (energy saving), I lose the hdmi audio, standard stuff. When I move the mouse I get the screen back but not the audio anymore. Switching it back on with xrandr works. Thanks -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 83748] New: Only black content on screen, in the Tokyo flashback of the game "The Secret World"
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=83748 Priority: medium Bug ID: 83748 Assignee: dri-devel(a)lists.freedesktop.org Summary: Only black content on screen, in the Tokyo flashback of the game "The Secret World" Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.ettedgui(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Hey, I am trying to play the game "The Secret World" on my system. It is a Windows game so I am using Wine to run it. Initially the game runs, and I can see everything (cinematics and in-game stuff), but for some reason once I enter the Tokyo flashback, I cannot see the cinematic or anything in that dungeon. In the cinematic my screen seems to be completely black. Once back in-game, all content is dark/black, but I can kind of see where walls are or the overall shape of my character. Maybe that's what it would be with a null contrast and 0 brightness? Also the game is still running, I can interact with the npcs (if I manage to find them) etc... I tried using stable mesa 10.2.7 instead of daily git but it was the same. I then tried running the game on the same machine using the Catalyst drivers and all the visuals were there, both in the cinematic and in-game, so as far as I can see the issue shouldn't be in Wine. I don't understand why I'm getting that problem only in that part of the game, I've passed it using Catalyst, and now I'm able to continue the game normally with the gallium driver after this strange part... I am not sure what logs to add to this, since it is a visual issue and I don't see any kind of error message about it (although it could be hidden in the wine verbose logs I suppose). My system: Radeon 7970 running with Mesa, daily git or 10.2.7. llvm either daily git or 3.5.0 Arch Linux 64b with Linux kernel 3.16.2 I've tried both wine and wine-csmt, both have the same issue. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 69120] New: With dpm=1 vdpau is not usable
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=69120 Priority: medium Bug ID: 69120 Assignee: dri-devel(a)lists.freedesktop.org Summary: With dpm=1 vdpau is not usable Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.ettedgui(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Hello, with radeon.dpm=0 (or not set), vdpau output works very fine. But if I switch to radeon.dpm=1 it becomes unusable. mplayer tells me that my computer is too slow, video stutters to a crazy extent, same in xbmc. With dpm set to 1, I am still able to watch videos "normally" if not using vdpau. I have a Radeon 4670, Linux 3.11, Mesa 9.2 and Radeon 1:7.2.0. I tried to change power_dpm_state and power_dpm_force_performance_level to see if it would help. power_dpm_state stays at performance but even if I set power_dpm_force_performance_level to high, but it always reverts to auto... This doesn't help at all... I am not sure what else to attach. Thank you -- You are receiving this mail because: You are the assignee for the bug.

1 29

[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.
by bugzilla-daemon＠freedesktop.org 04 Jul '18

04 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=90481 Bug ID: 90481 Summary: Radeon R9 270X gpu lockup in game spec ops: the line. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: vim(a)xmail.net Created attachment 115834 --> https://bugs.freedesktop.org/attachment.cgi?id=115834&action=edit kernel log with drm.debug=1 Playing in spec ops: the line from steam causes gpu lockup. Behaviour differs. Firstly system freeze, after a few seconds screen becomes black. Sometimes works only sysrq, sometimes i can switch to VT and log in (screen still is black, but sudo reboot works). Sometimes it unfreeze and everything works again. System: Fedora 22 x86_64 kernel: 4.0.2-300.fc22.x86_64 mesa: 10.5.4-1.20150505.fc22 xorg-server: 1.17.1-11.fc22 libdrm: 2.4.61-3.fc22 xorg-x11-drv-ati.x86_64: 7.5.0-3.fc22 window manager: kwin-5.3.0-2.fc22 video card Radeon R9 270X OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.5.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: reproduce always. After 15-40 minutes of playing. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion
by Tejun Heo 19 Jun '18

19 Jun '18

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not. This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Markus Trippelsdorf <markus(a)trippelsdorf.de> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org --- Markus, it's almost trivial but it would be great if you can test this one too. David, may I route this wq#for-linus? Thanks. drivers/gpu/drm/drm_crtc_helper.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 4598130..211ed7e 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work) struct drm_connector *connector; enum drm_connector_status old_status, status; bool repoll = false, changed = false; - int ret; mutex_lock(&dev->mode_config.mutex); list_for_each_entry(connector, &dev->mode_config.connector_list, head) { @@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work) dev->mode_config.funcs->output_poll_changed(dev); } - if (repoll) { - ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); - if (ret) - DRM_ERROR("delayed enqueue failed %d\n", ret); - } + if (repoll) + queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); } void drm_kms_helper_poll_disable(struct drm_device *dev)

4 4

[Bug 28771] New: Vsync always on
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=28771 Summary: Vsync always on Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se With kernel 2.6.35, there doesn't seem to be a way to turn off vsync/vblank. E.g. "vblank_mode=0 glxgears" has no effect. This seems to be the same for both r300c and r300g. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30 -- xserver: 1.8.1.901 -- mesa: a5c44986a3f19936df448fe4ae47ca77ece9b0ce -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc3 -- 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 73931] New: rmmod radeon and kernel crash
by bugzilla-daemon＠bugzilla.kernel.org 08 Jun '18

08 Jun '18

https://bugzilla.kernel.org/show_bug.cgi?id=73931 Bug ID: 73931 Summary: rmmod radeon and kernel crash Product: Drivers Version: 2.5 Kernel Version: 3.14 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: pali.rohar(a)gmail.com Regression: No Created attachment 132051 --> https://bugzilla.kernel.org/attachment.cgi?id=132051&action=edit rmmod_radeon_kernel_panic After calling rmmod radeon, kernel show lots of error lines and then crash. It looks like that radeon module does not cleanup hwmon interface at exit. After calling rmmod radeon there is still hwmon interface: $ readlink /sys/class/hwmon/hwmon1 ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon1 And after calling ls, or cat in hwmon1 kernel crash... See attachment from syslog. $ lspci -nn 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] [1002:6660] -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

[Bug 81620] New: radeon: fence wait failed (-35) after hybrid suspend on 3.15
by bugzilla-daemon＠freedesktop.org 30 May '18

30 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=81620 Priority: medium Bug ID: 81620 Assignee: dri-devel(a)lists.freedesktop.org Summary: radeon: fence wait failed (-35) after hybrid suspend on 3.15 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: iive(a)yahoo.com Hardware: x86 (IA32) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 103217 --> https://bugs.freedesktop.org/attachment.cgi?id=103217&action=edit dmesg of suspend/resume session with radeon.ko dpm debug turned on My hardware is Radeon HD5670 (Redwood). To reproduce the problem boot vanilla 3.15.x kernel. Run in KMS mode (no Xorg server needed). Then suspend to ram-and-disk with the following command: `echo suspend > /sys/power/disk; echo disk > /sys/power/state` Resume from the power button. In `dmesg` you can find: [ 83.997399] [drm] ring test on 5 succeeded in 1 usecs [ 83.997403] [drm] UVD initialized successfully. [ 83.997450] [drm] ib test on ring 0 succeeded in 0 usecs [ 83.997494] [drm] ib test on ring 3 succeeded in 1 usecs [ 94.137259] radeon 0000:01:00.0: ring 5 stalled for more than 10000msec [ 94.137263] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000004 last fence id 0x0000000000000002 on ring 5) [ 94.137265] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35). [ 94.137268] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). At this point if Xorg server is started any attempt to vdpau hardware decoding would fail. If the computer is left working, without reboot, at some point timeout would trigger and GPU restart might be attempted, usually hanging the system. (I took the following log from older GPU restart, probably successful). [ 0.000000] Linux version 3.15.2 (root) (gcc version 4.8.3 (GCC) ) #2 SMP [12398.387691] radeon 0000:01:00.0: ring 5 stalled for more than 242796msec [12398.387699] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000005 last fence id 0x0000000000000004 on ring 5) [12398.425151] radeon 0000:01:00.0: Saved 23 dwords of commands on ring 0. [12398.425167] radeon 0000:01:00.0: GPU softreset: 0x00000009 [12398.425169] radeon 0000:01:00.0: GRBM_STATUS = 0xF5703828 [12398.425171] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0xFC000007 [12398.425173] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007 [12398.425175] radeon 0000:01:00.0: SRBM_STATUS = 0x200800C0 [12398.425177] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 [12398.425179] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [12398.425181] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x40000000 [12398.425183] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00008004 [12398.425185] radeon 0000:01:00.0: R_008680_CP_STAT = 0x80228647 [12398.425187] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [12398.441572] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B [12398.441626] radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000100 [12398.442782] radeon 0000:01:00.0: GRBM_STATUS = 0x00003828 [12398.442783] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007 [12398.442785] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007 [12398.442787] radeon 0000:01:00.0: SRBM_STATUS = 0x200800C0 [12398.442789] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 [12398.442791] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [12398.442793] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 [12398.442795] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 [12398.442796] radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 [12398.442798] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [12398.442813] radeon 0000:01:00.0: GPU reset succeeded, trying to resume [12398.512161] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [12398.516583] [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000). The bug vanishes if only suspend to ram or suspend to disk is used. I tried to do a bisect, but a number of rc kernels seem to hang on me, long before radeon module is loaded. At this point bisect I suspected that the new async suspend/resume code might be at fault, as I was seeing video card been turned off (aka monitor going off) and then turning on a moment before shutting down completely. So I found the commits of the async suspend (from an article) and reverted them. Reverting 200421a80f6e0a9e39d698944cc35cba103eb6ce, 3c31b52f96f7b559d950b16113c0f68c72a1985e seems to avoid the above effect about monitor turning off, on, then off again. But it does not fix the bug. Reverting 7cd0602d7836c0056fe9bdab014d5ac5ec5cb291, 92858c476ec4e99cf0425f05dee109b6a55eb6f8 and 9e5e7910df824ba02aedd2b5d2ca556426ea6d0b, 76569faa62c46382e080c3e190c66e19515aae1c, de377b3972729f00ee236ae4a97393e282ffe391, 28b6fd6e37792b16a56d324841bdb20ab78e4522, a59ffb2062df3a5c346dbed931fa1e587fd0f0f3 doesn't affect the bug either, so I assume that this bug is not related to suspend/resume async changes. If you cannot reproduce the problem, please advice me what commits to revert. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 72785] New: bfgminer --scrypt on 7xxx+
by bugzilla-daemon＠freedesktop.org 30 May '18

30 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=72785 Priority: medium Bug ID: 72785 Assignee: dri-devel(a)lists.freedesktop.org Summary: bfgminer --scrypt on 7xxx+ Severity: normal Classification: Unclassified OS: All Reporter: haagch.christoph(a)googlemail.com Hardware: All Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa bfgminer --benchmark without scrypt seems to be working fine now. But I think many people would rather compute scrypt right now on their 7xxx+ GPUs, just considering the recent rumors that the radeon 7950 is getting sold out because of litecoin miners. With mesa/llvm it doesn't work yet. llvm 3.5 197392, mesa and stuff are very recent git builds. The kernel is https://github.com/luke-jr/bfgminer/blob/bfgminer/scrypt130511.cl bfgminer is started with bfgminer -v1 --scrypt -S opencl:auto --url=<pool> --userpass=<user:worker:pass> The error is: Initialising kernel scrypt130511.cl without bitalign, 1 vectors and worksize 256 [...] LLVM ERROR: Cannot select: 0x7f0b7cbd40a0: ch = br_cc 0x7f0b7cd32bb0, 0x7f0b7cc28c20, 0x7f0b7cd32fb0, 0x7f0b7cc2bc30, 0x7f0b7cc2ad30 [ORD=19251] [ID=4253] 0x7f0b7cd32fb0: i1,ch = llvm.SI.loop 0x7f0b7cc2c030:1, 0x7f0b7cd333b0, 0x7f0b7cc2c030 [ORD=19250] [ID=4250] 0x7f0b7cd333b0: i64 = TargetConstant<3431> [ID=132] 0x7f0b7cc2c030: i64,ch = llvm.SI.if.break 0x7f0b7cf2f3e0, 0x7f0b7cc2b530, 0x7f0b7cc2c530, 0x7f0b7cd339b0 [ORD=19249] [ID=4249] 0x7f0b7cc2b530: i64 = TargetConstant<3428> [ID=129] 0x7f0b7cc2c530: i1 = setcc 0x7f0b7cc7dd60, 0x7f0b7cc80760, 0x7f0b7cd337b0 [ORD=19248] [ID=212] 0x7f0b7cc7dd60: i64 = add 0x7f0b7cc81560, 0x7f0b7cc81360 [ORD=13153] [ID=187] 0x7f0b7cc81560: i64,ch = CopyFromReg 0x7f0b7c0535d8, 0x7f0b7cc81660 [ORD=13147] [ID=149] 0x7f0b7cc81660: i64 = Register %vreg53 [ID=1] 0x7f0b7cc81360: i64 = Constant<1> [ID=2] 0x7f0b7cc80760: i64 = Constant<4> [ID=4] 0x7f0b7cd339b0: i64,ch = CopyFromReg 0x7f0b7c0535d8, 0x7f0b7cd342b0 [ORD=19249] [ID=185] 0x7f0b7cd342b0: i64 = Register %vreg52 [ID=130] 0x7f0b7cc2bc30: i1 = Constant<-1> [ID=133] In function: search -- You are receiving this mail because: You are the assignee for the bug.

1 43

[Bug 48424] New: Fix warnings/errors reported by clang's scan-build tool
by bugzilla-daemon＠freedesktop.org 12 Apr '18

12 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=48424 Bug #: 48424 Summary: Fix warnings/errors reported by clang's scan-build tool Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) URL: https://gitorious.org/jobermayr/scan-build-mesa OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev(a)lists.freedesktop.org ReportedBy: johannesobermayr(a)gmx.de CC: dri-devel(a)lists.freedesktop.org, nouveau(a)lists.freedesktop.org https://gitorious.org/jobermayr/scan-build-mesa ~ 8 MB to download, 680 MB on disk. Please report false positives here. I will forward them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015