dri-devel May 2015

dri-devel@lists.freedesktop.org

191 participants
1132 discussions

[Bug 68571] New: GPU lockup on AMD Radeon HD6850 with DPM=1
by bugzilla-daemon＠bugzilla.kernel.org 20 Sep '16

20 Sep '16

https://bugzilla.kernel.org/show_bug.cgi?id=68571 Bug ID: 68571 Summary: GPU lockup on AMD Radeon HD6850 with DPM=1 Product: Drivers Version: 2.5 Kernel Version: 3.13-rc6 / 3.12 Hardware: x86-64 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: kilobug(a)kilobug.org Regression: No Hi, When using dpm with my Radeon HD6850 I get frequent "GPU lockup", with the screen freezing for a few seconds. Sometimes (but not often) the system completely freezes (hard reset required). It happens both during playing OpenGL games and during normal (not GPU intensive) activities, slightly more often during games. I have the issue with both kernel 3.12 (manually enabling the DPM) and 3.13-rc6 (in which it's enabled by default). With DPM disabled, all is working fine. I'm using Mesa 10.0.1, but had the problem with Mesa 9.2.2 on kernel 3.12 too (didn't try Mesa 9.2.2 with kernel 3.13-rc6). I'm using Debian GNU/Linux 64-bits, all packages are from the Debian archive (Mesa 10 and Linux 3.13-rc6 from experimental), but I don't think the problem is Debian-specific so I prefer to report it here. I include a "dmesg" containing two of those lockups. The card itself is a Saphire HD6850 with 1Gb of GDDR5 memory, the CPU is a Intel(R) Core(TM)2 Duo CPU E8400, memory is 2x2Gb of DDR2, the motherboard a ASUSTeK P5E3. Feel free to ask for any additional information, or any test I could perform. Regards, -- You are receiving this mail because: You are watching the assignee of the bug.

1 83

[Bug 69076] New: weston+rs690: triangle flickering
by bugzilla-daemon＠freedesktop.org 09 Sep '16

09 Sep '16

https://bugs.freedesktop.org/show_bug.cgi?id=69076 Priority: medium Bug ID: 69076 Assignee: dri-devel(a)lists.freedesktop.org Summary: weston+rs690: triangle flickering Severity: major Classification: Unclassified OS: Linux (All) Reporter: david.heidelberger(a)ixit.cz Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI How to reproduce: 1.boot 2. kdm (xorg/mesa init) 3. systemctl stop kdm 4. weston // problematic 5. alt-ctrl-bckspace 6. systemctl start kdm 7. desktop (without effects or 3D) 8. logout 9. systemctl stop kdm 10. weston (without described flickering) Screenshots: http://212.158.157.7/20130907_001.jpg (weston start - triangle damaged title) http://212.158.157.7/20130907_002.jpg (first input in terminal) http://212.158.157.7/20130907_003.jpg (terminal filled) On every redraw (input from keyboard), all damaged content (triangles) flicker. Kernel 3.9.1, mesa git, llvm git, weston+wayland git. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion
by bugzilla-daemon＠freedesktop.org 01 Sep '16

01 Sep '16

https://bugs.freedesktop.org/show_bug.cgi?id=89746 Bug ID: 89746 Summary: Mesa and LLVM 3.6+ break opengl for genymotion Product: Mesa Version: 10.5 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: spupazza(a)hotmail.com QA Contact: dri-devel(a)lists.freedesktop.org I found out LLVM 3.6 + Mesa 10.5 (and newer) might have some sort of regression breaking opengl with radeonsi drivers at least. I use genymotion (android emulator) which relies on virtualbox and make use of opengl acceleration. On 2 different machines with 2 different distros (ubuntu 14.10/15.04 and manjaro 0.9 pre4) I had the same problem: as soon as LLVM 3.6 or 3.7git (the latter with utopic when I added paulo dias ppa) gets installed genymotion stop working (the screen of the vm disappear 1-2 seconds after the machine gets started, and while the screen disappear the machine keeps running in the background). On the terminal I get this error: Port 22468 will be used for OpenGL data connections Unknown TCPCLI command 1003 LLVM ERROR: 'main' label emitted multiple times to assembly file With LLVM 3.5 genymotion (with the same distros and machines) was working just fine. Another proof that the issue is with LLVM is that as to temporarily sort this problem out, I installed the proprietary drivers (fgrlx) and the issue vanished (since proprietary drivers do not make use of LLVM). To reproduce the bug, you need a radeon vga (possibly one using the radeonsi drivers so with GCN architecture) , install vitualbox and genymotion, Setup a virtual device and having installed LLVM 3.6 or newer. Then start the device you created. I reported this bug to the llvm bug-tracker system and they told me to report it to you. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2015