dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 77892] New: [RV635] when GPU locks up, reset happens but X is unresponsive except mouse
by bugzilla-daemon＠freedesktop.org 31 Aug '16

31 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=77892 Priority: medium Bug ID: 77892 Assignee: dri-devel(a)lists.freedesktop.org Summary: [RV635] when GPU locks up, reset happens but X is unresponsive except mouse Severity: critical Classification: Unclassified OS: Linux (All) Reporter: shawn.starr(a)rogers.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI For a long time now, I don't recall which 3.x broke this but there's been many changes since and now, when the GPU does randomly reset, the display goes blank, X display is restored, but I can only move mouse, cannot interact with X. Can someone point me to some debugging approaches to see if there's some lock being held somewhere thats causing this? I am able to ssh into the laptop so, this seems to point to some sort of lock thats not released. Bisecting radeon drm will be difficult if I have to start from near the beginning of r600g drm support. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 61941] New: Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
by bugzilla-daemon＠bugzilla.kernel.org 19 Aug '16

19 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=61941 Bug ID: 61941 Summary: Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1 Product: Drivers Version: 2.5 Kernel Version: >=3.11.0 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: itumaykin(a)gmail.com Regression: No Created attachment 109311 --> https://bugzilla.kernel.org/attachment.cgi?id=109311&action=edit lspci -vvv Hello. I have 3.11 kernel with radeon.dpm enabled via kernel boot option. Sometimes under unknown circumstances my GPU resets. It happens seldom and randomly during a common desktop workflow: web browsing, document typing, video playback. No games or video benchmarks or any other GPU-eating stuff. During such lockup my screen turns black, but backlight is still on. After a while image reappears, though it is blurry and after 10-15 seconds my screen is back to normal state completely. Also sometimes after such reset I am able to continue working, but sometimes screen is stuck with one image that appeared after screen restoration and I have to reboot machine to fix this. Everything else seems to work fine during lockups, for example music is playing without any problems. I can't say for sure, but it looks like this bug happens more often when some video is played in Firefox. (JIC: I don't have Adobe Flash installed.) My OS is Gentoo amd64 with vanilla kernel 3.11.{0,1}. And this happens with power_dpm_state set to "balanced". I've attached two dmesg outputs after such lockups. I do understand that it is probably too vague description to fix this and I am ready to provide any other additional info. -- You are receiving this mail because: You are watching the assignee of the bug.

1 25

[Bug 81382] New: Text console blanking does not go away
by bugzilla-daemon＠freedesktop.org 15 Aug '16

15 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=81382 Priority: medium Bug ID: 81382 Assignee: dri-devel(a)lists.freedesktop.org Summary: Text console blanking does not go away Severity: normal Classification: Unclassified OS: All Reporter: vda.linux(a)googlemail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 102847 --> https://bugs.freedesktop.org/attachment.cgi?id=102847&action=edit dmesg I log in as root on a text virtual console. After about 10 minutes screen blanks. Surprisingly, pressing a key does *not* unblank the screen! Machine is still alive (I can ssh into it), and typed keys even reach the console: I can type e.g. "ls -lR /usr" and I see disk indicator blinking, ls process is visible in the ps in ssh session, etc. This does not happen in X. This is observed on Lenovo T60, on RHEL7 kernel and also on recent upstream kernel 3.15.5. Investigation had revealed that VT unblanking code, after all the hard work it done to turn display back on, calls ATOM_LCD_BLOFF (backlight off, numeric value 2) function. Digging further, I discovered that fb_blank(blank=0) almost at its end calls fb_notifier_call_chain(FB_EVENT_BLANK). Which calls backlight.c::fb_notifier_callback(), which tries to set brightness via radeon_atom_backlight_update_status(), which does atombios_set_backlight_level(radeon_atom_bl_level()), but radeon_atom_bl_level() is zero (it's an uint8_t, brightness level). So it's essentially atombios_set_backlight_level(0) and it switches backlight off. In drivers/gpu/drm/radeon/*, bd->props.brightness, surprisingly, is only set in radeon_atom_backlight_init() and radeon_legacy_backlight_init(), all other locations are only reading it. So, if this init code sets it to 0, then VT unblanking code will use this zero value as brightness to restore, causing this bug. And indeed, that's what happens on the machine exhibiting this bug: [ 2.301563] radeon_atom_get_backlight_level_from_reg: RADEON_BIOS_2_SCRATCH [ 2.301633] radeon_atom_get_backlight_level_from_reg: bios_2_scratch:00000000 [ 2.301704] radeon_atom_backlight_init: bd->props.brightness=0 [ 2.301780] radeon_atom_backlight_update_status: atombios_set_back The full dmesg of the RHEL7 boot with many debug printks added is attached. (Sorry, I started debugging it on RHEL7, I believe mainline does not differ significantly). It shows the following: After "setterm -blank 1 && sleep 60", VT blanking triggers at ~362 seconds, and at ~370 seconds VT is trying to unblank because of keyboard activity. The bug is evident here: [ 370.852058] fb_blank: fb_notifier_call_chain(FB_EVENT_BLANK)... [ 370.852061] fbcon_event_notify: case FB_EVENT_BLANK: fbcon_fb_blanked(blank:0) [ 370.852063] fbcon_fb_blanked: do_unblank_screen(0) [ 370.852064] do_unblank_screen: entered on cpu 0 [ 370.852066] do_unblank_screen: !console_blanked on cpu 0 [ 370.852068] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852071] radeon_atom_backlight_update_status: atombios_set_backlight_level() [ 370.852072] radeon_atom_bl_level: level = bd->props.brightness:0 [ 370.852074] atombios_set_backlight_level(level:0) [ 370.852077] atombios_set_backlight_level: atom_execute_table(ATOM_LCD_BLOFF) ^^^^^^^^^^^^^^^^^^^^ THIS TURNS OFF DISPLAY ^^^^^^^^^^^^^^^^^ [ 370.852083] atom_execute_table_locked(index:23,*params:ffff8802) returns 0 [ 370.852085] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852940] fb_blank returns 0 [ 370.852942] fbcon_blank: update_screen()... [ 370.862313] do_unblank_screen: done on cpu 0 Note: PCI error seen during blanking is not causing this bug. It happens on first blanking (including Xserver screen blankings, which do not exhibit this bug), and never repeats. Google says it's a known issue on Radeon, comes from PCIe lanes reconfiguration. I am unsure how to proceed from here. Maybe init code needs fixing to properly read backlight brightness on this hardware? I think radeon people are more qualified to take it from here. I'm willing to test patches. -- You are receiving this mail because: You are the assignee for the bug.

1 45

[Bug 85241] New: audio over HDMI on AMD E-350 with radeon driver
by bugzilla-daemon＠bugzilla.kernel.org 15 Aug '16

15 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=85241 Bug ID: 85241 Summary: audio over HDMI on AMD E-350 with radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.14 and higher 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: wmyrda(a)auticon.pl Regression: No I have problem with HDMI and audio on my Asus AMD E-350 platform which started around kernel 3.14 with sigle error message "[drm:dce4_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0" which become even more severe with kernels 3.15 & 3.16 as now logs are flooded with "sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD" My setup is PC with Asus E-350 connected directly to the TV with HDMI cable (it has been in the past to the 5.1 analog system hence the entry of "options snd-hda-intel model=3stack-6ch-dig" in /etc/modprobe.d/alsa.conf) on software side it is Gentoo with libdrm & mesa & xf86-video-ati --- git versions updated on the regular basis about every 1-2 weeks pulseaudio 5.0 xorg 1.16.1 here are some logs. If more info is needed please let me know dmesg 3.14.19 http://pastebin.com/AHyV1nRk Xorg.0.log http://pastebin.com/J66tUcU5 audio 3.16.3 http://www.alsa-project.org/db/?f=7e2075...92b0b5c23e audio 3.15.10 http://www.alsa-project.org/db/?f=bbb92a...14bd0bc831 audio 3.14.19 http://www.alsa-project.org/db/?f=5d2f93...2a7a6697a6 -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 85087] New: [NVD9] Thinkpad T420 - freezes under load
by bugzilla-daemon＠freedesktop.org 10 Aug '16

10 Aug '16

https://bugs.freedesktop.org/show_bug.cgi?id=85087 Bug ID: 85087 Summary: [NVD9] Thinkpad T420 - freezes under load Product: DRI Version: XOrg CVS Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: david.heidelberger(a)ixit.cz Dist: Ubuntu 14.04 Kernel: 3.13 - 3.17.1 Mesa/DDX: Ubuntu default - oibaf git generated Setting: to discrete GPU (PRIME disabled). When loading Nouveau or in third icon of KDE loading (probably kwin load compositing) it froze. No SYSRQ, no ssh working. It's completly frozen. It's not my laptop, so i'll try proviede debug information, but it will take time. [ 0.767676] [drm] Initialized drm 1.1.0 20060810 [ 0.797073] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0d9170a1 [ 0.797158] nouveau [ DEVICE][0000:01:00.0] Chipset: GF119 (NVD9) [ 0.797244] nouveau [ DEVICE][0000:01:00.0] Family : NVC0 [ 0.797346] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 0.866415] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid [ 0.866503] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN [ 0.866698] nouveau [ VBIOS][0000:01:00.0] BIT signature found [ 0.866784] nouveau [ VBIOS][0000:01:00.0] version 75.19.53.00.00 [ 0.867372] nouveau 0000:01:00.0: irq 27 for MSI/MSI-X [ 0.867381] nouveau [ PMC][0000:01:00.0] MSI interrupts enabled [ 0.867509] nouveau W[ PFB][0000:01:00.0][0x00000000][ffff88003600a800] reclocking of this ram type unsupported [ 0.867654] nouveau [ PFB][0000:01:00.0] RAM type: DDR3 [ 0.867766] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB [ 0.867878] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags [ 0.869561] nouveau [ VOLT][0000:01:00.0] GPU voltage: 850000uv [ 0.900042] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external [ 0.900163] nouveau [ PTHERM][0000:01:00.0] fan management: automatic [ 0.900285] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes [ 0.900423] nouveau [ CLK][0000:01:00.0] 07: core 270 MHz memory 405 MHz [ 0.900561] nouveau [ CLK][0000:01:00.0] 0f: core 810 MHz memory 800 MHz [ 0.900851] nouveau [ CLK][0000:01:00.0] --: core 270 MHz memory 405 MHz [ 0.905408] nouveau [ DRM] VRAM: 1024 MiB [ 0.905516] nouveau [ DRM] GART: 1048576 MiB [ 0.905626] nouveau [ DRM] TMDS table version 2.0 [ 0.905736] nouveau [ DRM] DCB version 4.0 [ 0.905844] nouveau [ DRM] DCB outp 00: 01800323 00010034 [ 0.905956] nouveau [ DRM] DCB outp 01: 02811300 00000000 [ 0.906068] nouveau [ DRM] DCB outp 02: 028223a6 0f220010 [ 0.906180] nouveau [ DRM] DCB outp 03: 02822362 00020010 [ 0.906291] nouveau [ DRM] DCB outp 04: 048333b6 0f220010 [ 0.906402] nouveau [ DRM] DCB outp 05: 04833372 00020010 [ 0.906513] nouveau [ DRM] DCB outp 06: 088443c6 0f220010 [ 0.906632] nouveau [ DRM] DCB outp 07: 08844382 00020010 [ 0.906745] nouveau [ DRM] DCB conn 00: 00000040 [ 0.906937] nouveau [ DRM] DCB conn 01: 00000100 [ 0.907122] nouveau [ DRM] DCB conn 02: 00101246 [ 0.907323] nouveau [ DRM] DCB conn 03: 00202346 [ 0.907507] nouveau [ DRM] DCB conn 04: 00410446 [ 0.908716] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 0.908836] [drm] Driver supports precise vblank timestamp query. [ 0.914353] nouveau [ DRM] MM: using COPY0 for buffer copies [ 1.232769] nouveau [ DRM] allocated 1920x1080 fb: 0x60000, bo ffff88020ee67400 [ 1.232978] fbcon: nouveaufb (fb0) is primary device [ 1.309034] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device [ 1.309054] nouveau 0000:01:00.0: registered panic notifier [ 1.311511] [drm] Initialized nouveau 1.2.0 20120801 for 0000:01:00.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 84431] New: Kernel crash when unloading radeon module for switcheroo card
by bugzilla-daemon＠bugzilla.kernel.org 05 Aug '16

05 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=84431 Bug ID: 84431 Summary: Kernel crash when unloading radeon module for switcheroo card Product: Drivers Version: 2.5 Kernel Version: all Hardware: All 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 149991 --> https://bugzilla.kernel.org/attachment.cgi?id=149991&action=edit Fix crash after rmmod radeon on PX systems. Calling rmmod radeon on PX system cause kernel crash. Reason is function vga_switcheroo_init_domain_pm_ops() which setting dev->pm_domain function of PCI device. When radeon module is unloaded pointer dev->pm_domain is set to vga_switcheroo function which try to call radeon function (which does not exists in memory after rmmod radeon). I bet that nouveau has same problem. I'm attaching simple patch which set dev->pm_domain of PCI device back to NULL when removing radeon device so vga_switcheroo will not be called. But I think that proper way for fixing this bug - which is in vga_switcheroo - should be to add function like "vga_switcheroo_exit_domain_pm_ops()" which will set pm_domain back to origin value (which is in my case NULL). With my patch on PX system I can call rmmod radeon, modprobe radeon, rmmod radeon, ... many times without no crash. -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

[Bug 96721] New: radeon: unable to handle kernel paging request with counter strike: go
by bugzilla-daemon＠bugzilla.kernel.org 02 Aug '16

02 Aug '16

https://bugzilla.kernel.org/show_bug.cgi?id=96721 Bug ID: 96721 Summary: radeon: unable to handle kernel paging request with counter strike: go Product: Drivers Version: 2.5 Kernel Version: 4.0 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: haagch.christoph(a)googlemail.com Regression: No Created attachment 174121 --> https://bugzilla.kernel.org/attachment.cgi?id=174121&action=edit dmesg Playing counter strike: global offensive with mesa git and PRIME on 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) After a while the graphical output froze with BUG: unable to handle kernel paging request at ffff8002a30769f8. IP: [<ffffffff8140a01b>] reservation_object_add_shared_fence+0x17b/0x2b0 Call Trace: [<ffffffffa0064705>] ttm_eu_fence_buffer_objects+0x55/0xb0 [ttm] [<ffffffffa02312eb>] radeon_cs_parser_fini+0x20b/0x230 [radeon] [<ffffffffa0231ba1>] radeon_cs_ioctl+0x3b1/0x810 [radeon] [<ffffffffa001bcaf>] drm_ioctl+0x1df/0x680 [drm] [<ffffffffa01f704c>] radeon_drm_ioctl+0x4c/0x80 [radeon] [<ffffffffa02fbbf4>] radeon_kms_compat_ioctl+0x14/0x30 [radeon] [<ffffffff81226560>] compat_SyS_ioctl+0xf0/0x1250 [<ffffffff810f37e4>] ? compat_SyS_futex+0x84/0x1a0 [<ffffffff81569572>] ? __schedule+0x382/0xa00 [<ffffffff8156ffc6>] sysenter_dispatch+0x7/0x25 Full dmesg attached. I don't think I have debug symbols here, so no further details at this time. It only happened after quite a while, so it's not easily reproducable. Just putting it here because I haven't seen a report like this. -- You are receiving this mail because: You are watching the assignee of the bug.

1 2

[Bug 64475] New: Slow work and low brightness in Euro Track Simulator II game with HD6850
by bugzilla-daemon＠freedesktop.org 29 Jul '16

29 Jul '16

https://bugs.freedesktop.org/show_bug.cgi?id=64475 Priority: medium Bug ID: 64475 Assignee: dri-devel(a)lists.freedesktop.org Summary: Slow work and low brightness in Euro Track Simulator II game with HD6850 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: commiethebeastie(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 79172 --> https://bugs.freedesktop.org/attachment.cgi?id=79172&action=edit Euro Truck Simulator screenshot I tried to run the game with STEAM_RUNTIME="1" R600_LLVM=0 R600_HYPERZ=0 steam Driver "radeon" Option "SwapbuffersWait" "on" Option "ColorTiling" "off" Option "ColorTiling2D" "off" Option "EnablePageFlip" "on" Option "AccelMethod" "EXA" and STEAM_RUNTIME="1" R600_LLVM=1 R600_HYPERZ=1 R600_DEBUG=sb steam Driver "radeon" Option "SwapbuffersWait" "off" Option "ColorTiling" "on" Option "ColorTiling2D" "on" Option "EnablePageFlip" "off" Option "AccelMethod" "EXA" options But all times the game runs slowly and with low brightness. In the mirrors is visible to normal brightness. Also I can put apitrace file here. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-5471e39) OpenGL core profile shading language version string: 1.40 Linux localhost 3.9.0-next-20130509 #1 SMP PREEMPT Thu May 9 12:49:14 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 28

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards
by bugzilla-daemon＠freedesktop.org 28 Jul '16

28 Jul '16

https://bugs.freedesktop.org/show_bug.cgi?id=87682 Bug ID: 87682 Summary: Horizontal lines in radeon driver on kernel 3.15 and upwards Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: qwrules(a)gmail.com Created attachment 111292 --> https://bugs.freedesktop.org/attachment.cgi?id=111292&action=edit Youtube video depicting the artefacts. This is what I get if I run any kernel newer than 3.14: https://www.youtube.com/watch?v=nx2-Fvihzxg Those artefacts appear as soon as new kernel is selected in GRUB, and remain after logging into X session. The last kernel working without artefacts is v3.15-rc2-trusty for Ubuntu, and 3.14.7 for Arch. All later kernels have those artefacts. I updated mesa and xorg to those form ppaibaf/graphics-drivers ppa on Ubuntu, and on using git version on Arch but it did not change a thing. This regression is solely kernel-related. GPU: Mobility Radeon HD 3200 (RS780M) System tested: Arch, Ubuntu 14.04, 14.10 Kernels affected: 3.15 and onwards (tested up to 3.19-rc1) -- You are receiving this mail because: You are the assignee for the bug.

2 27

[PATCH] drm/amdgpu: Delete an unnecessary check before the function call "kfree"
by SF Markus Elfring 28 Jul '16

28 Jul '16

From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Sun, 28 Jun 2015 10:27:35 +0200 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index fec487d..a85cd08 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1575,8 +1575,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev) amdgpu_fence_driver_fini(adev); amdgpu_fbdev_fini(adev); r = amdgpu_fini(adev); - if (adev->ip_block_enabled) - kfree(adev->ip_block_enabled); + kfree(adev->ip_block_enabled); adev->ip_block_enabled = NULL; adev->accel_working = false; /* free i2c buses */ -- 2.4.4

4 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015