dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 67713] New: Atombios stuck in a loop on Trinity 7500G
by bugzilla-daemon＠freedesktop.org 03 Nov '16

03 Nov '16

https://bugs.freedesktop.org/show_bug.cgi?id=67713 Priority: medium Bug ID: 67713 Assignee: dri-devel(a)lists.freedesktop.org Summary: Atombios stuck in a loop on Trinity 7500G Severity: normal Classification: Unclassified OS: All Reporter: mike(a)fireburn.co.uk Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 83583 --> https://bugs.freedesktop.org/attachment.cgi?id=83583&action=edit Dmesg A trinity system freezes if X is in the forefront Caught this when I was in a VT - I'll attach the dmesg RADEON_VA=0 is coded in /etc/environment as a solution to frequent freeze ups (I'm not sure if this is still required or not) bug 65958 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7500G] [1002:990a] Let me know if there's anything else you need -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)
by bugzilla-daemon＠freedesktop.org 02 Nov '16

02 Nov '16

https://bugs.freedesktop.org/show_bug.cgi?id=90666 Bug ID: 90666 Summary: Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: bla(a)thera.be Switching to console worked, in my attempt for 4.0 it didn't work at all. Including stack traces which might help fix some errors though. This is zbook 14 - dual gpu with intel/vga_switcheroo. Linux feather 4.1.0-rc5-bla+ #4 SMP PREEMPT Tue May 26 19:17:04 CEST 2015 x86_64 GNU/Linux This is plain 4.1.0-rc5 with 2 more commits from main git. No `my' changes. Rest is Debian Jessie: ii xserver-xorg-video-ati 1:7.5.0-1 [ 28.837695] ------------[ cut here ]------------ [ 28.838452] WARNING: CPU: 0 PID: 4639 at drivers/gpu/drm/drm_ioctl.c:144 drm_setversion+0x176/0x180() [ 28.839231] No drm_driver.set_busid() implementation provided by 0xffffffff824e77c0. Use drm_dev_set_unique() to set the unique name explicitly. [ 28.839285] Modules linked in: [ 28.840540] nfnetlink_queue nfnetlink_log nfnetlink btrfs xor tpm_infineon raid6_pq intel_rapl iosf_mbi x86_pkg_temp_thermal joydev crc32_pclmul iwlmvm iwlwifi xhci_pci xhci_hcd e1000e intel_smartconnect tpm_tis tpm_rng tpm [ 28.842975] CPU: 0 PID: 4639 Comm: Xorg Not tainted 4.1.0-rc5-bla+ #4 [ 28.844343] Hardware name: Hewlett-Packard HP ZBook 14/198F, BIOS L71 Ver. 01.20 07/28/2014 [ 28.845571] 00000000ffffffff 00000000671b4f82 ffffffff82175639 ffffffff81d55e44 [ 28.846843] ffff880087c47d10 ffffffff810e423c ffff880087c47de0 ffff88043a007000 [ 28.848186] ffff880438b10cc0 fffffffffffffff2 0000000000000007 ffffffff810e42c8 [ 28.849439] Call Trace: [ 28.850708] [<ffffffff81d55e44>] ? dump_stack+0x4a/0x74 [ 28.851873] [<ffffffff810e423c>] ? warn_slowpath_common+0x7c/0xb0 [ 28.853236] [<ffffffff810e42c8>] ? warn_slowpath_fmt+0x58/0x80 [ 28.854588] [<ffffffff81581806>] ? drm_setversion+0x176/0x180 [ 28.855845] [<ffffffff81581256>] ? drm_ioctl+0x316/0x5b0 [ 28.856977] [<ffffffff81581690>] ? drm_noop+0x30/0x30 [ 28.858051] [<ffffffff81221dee>] ? do_filp_open+0x3e/0xb0 [ 28.859291] [<ffffffff81224388>] ? do_vfs_ioctl+0x308/0x510 [ 28.860191] [<ffffffff81175f9c>] ? __audit_syscall_entry+0xbc/0x110 [ 28.861068] [<ffffffff8105c01b>] ? syscall_trace_enter_phase1+0x13b/0x1a0 [ 28.861920] [<ffffffff812245c6>] ? SyS_ioctl+0x36/0x80 [ 28.862775] [<ffffffff81d638d7>] ? system_call_fastpath+0x12/0x6a [ 28.863634] ---[ end trace fdbd327690626ad6 ]--- [ [ 29.315320] ------------[ cut here ]------------ [ 29.315328] WARNING: CPU: 0 PID: 4639 at drivers/gpu/drm/drm_ioctl.c:144 drm_setversion+0x176/0x180() [ 29.315334] No drm_driver.set_busid() implementation provided by 0xffffffff824e77c0. Use drm_dev_set_unique() to set the unique name explicitly. [ 29.315336] Modules linked in: [ 29.315337] nfnetlink_queue nfnetlink_log nfnetlink btrfs xor tpm_infineon raid6_pq intel_rapl iosf_mbi x86_pkg_temp_thermal joydev crc32_pclmul iwlmvm iwlwifi xhci_pci xhci_hcd e1000e intel_smartconnect tpm_tis tpm_rng tpm [ 29.315351] CPU: 0 PID: 4639 Comm: Xorg Tainted: G W 4.1.0-rc5-bla+ #4 [ 29.315353] Hardware name: Hewlett-Packard HP ZBook 14/198F, BIOS L71 Ver. 01.20 07/28/2014 [ 29.315354] 00000000ffffffff 00000000671b4f82 ffffffff82175639 ffffffff81d55e44 [ 29.315357] ffff880087c47d10 ffffffff810e423c ffff880087c47de0 ffff88043a007000 [ 29.315360] ffff880436fd8cc0 fffffffffffffff2 0000000000000007 ffffffff810e42c8 [ 29.315362] Call Trace: [ 29.315368] [<ffffffff81d55e44>] ? dump_stack+0x4a/0x74 [ 29.315373] [<ffffffff810e423c>] ? warn_slowpath_common+0x7c/0xb0 [ 29.315376] [<ffffffff810e42c8>] ? warn_slowpath_fmt+0x58/0x80 [ 29.315378] [<ffffffff81581806>] ? drm_setversion+0x176/0x180 [ 29.315380] [<ffffffff81581256>] ? drm_ioctl+0x316/0x5b0 [ 29.315382] [<ffffffff81581690>] ? drm_noop+0x30/0x30 [ 29.315386] [<ffffffff81221dee>] ? do_filp_open+0x3e/0xb0 [ 29.315389] [<ffffffff81224388>] ? do_vfs_ioctl+0x308/0x510 [ 29.315393] [<ffffffff81175f9c>] ? __audit_syscall_entry+0xbc/0x110 [ 29.315396] [<ffffffff8105c01b>] ? syscall_trace_enter_phase1+0x13b/0x1a0 [ 29.315398] [<ffffffff8122e163>] ? __fget+0x63/0xa0 [ 29.315400] [<ffffffff812245c6>] ? SyS_ioctl+0x36/0x80 [ 29.315404] [<ffffffff81d638d7>] ? system_call_fastpath+0x12/0x6a [ 29.315406] ---[ end trace fdbd327690626ad7 ]--- [ 29.317397] dmar: DRHD: handling fault status reg 2 [ 29.317400] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7300000000 DMAR:[fault reason 05] PTE Write access is not set [ 29.581646] dmar: DRHD: handling fault status reg 2 [ 29.581651] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7300000000 DMAR:[fault reason 05] PTE Write access is not set [ 29.591198] dmar: DRHD: handling fault status reg 2 [ 29.591205] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7300000000 DMAR:[fault reason 05] PTE Write access is not set -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 84156] New: Half of lighting gets broken in older apps
by bugzilla-daemon＠freedesktop.org 30 Oct '16

30 Oct '16

https://bugs.freedesktop.org/show_bug.cgi?id=84156 Priority: medium Bug ID: 84156 Assignee: dri-devel(a)lists.freedesktop.org Summary: Half of lighting gets broken in older apps Severity: normal Classification: Unclassified OS: All Reporter: smoki00790(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa This is from old bug 77785 and about old games where seems like GLSL is not used. In examples i can mention it happens when truck/vehicle turn on lights. Useful apitrace from 18 WoS: Pedal to the Metal game - it is OpenGL game running under wine: https://dl.dropboxusercontent.com/u/74553632/pttm_trace2.7z The same issue i found that can be reproduced is with 3DMark2001 http://www.futuremark.com/benchmarks/legacy (which is mostly for benchmarking DirectX8 features. So it happens too in 'Car Chase' test, but only when wine is used with UseGLSL disabled. http://wiki.winehq.org/UsefulRegistryKeys -- You are receiving this mail because: You are the assignee for the bug.

1 6

[PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices
by David Herrmann 24 Oct '16

24 Oct '16

Hi This series introduces a link between DRM connectors and backlight-class devices. It tries to solve some long standing issues: * User-space currently has a hard-time figuring out which backlight device to use, and which backlight device belongs to which display. So far, most systems only provide backlight-devices for internal displays, so figuring out the connection is easy, but that might change with more capable external connectors. If multiple backlights are available, the easiest solution is to simply write to all of them and hope at least one of them works. This obviously fails if the devices interact badly, so it's not really a solution. * User-space needs root privileges to write to sysfs. There are no char-devs that can be used to control access-management to the backlight API, so /sys is the only interface available. So far, udev policy has been "/sys is read-only for non-root" and it's not going to change. char-devs are *THE* standard way to provide non-root user-space APIs, so use them! Several solutions have been discussed so far, but we never agreed on one. I'm aware of at least the following solutions: * Provide char-devs for backlight devices and a sysfs link from connectors to backlight devices. This way, user-space can managed access to char-devs *and* get proper topology information. However, this might be an n:m relationship (n:1 for displays exposed as multiple connectors, 1:m for boards with multiple backlights? whatever..) and it sounds like a waste of resources to add char-devs just to write brightness values. * Do everything in privileged user-space. One daemon that provides an unprivileged-API and forwards writes to /sys. It reads topology information from udev hwdb. This circumvents the ugly sysfs API and not really solves the problem. It should work, though ugly. * Add a DRM connector property that takes brightness values. This is the nicest solution for user-space, but introduces a whole lot of issues on the kernel side. There already is a backlight-class and we had a hard-time trying to move it into DRM drivers, so no-one ever did the work. This series tries to solve this problem with a much simpler approach: Instead of moving backlights into DRM, we simply link DRM properties to a backlight device. That is, the kernel manages a link between a connector and a backlight device (or n backlight devices) which can be modified by udev in case the kernel got it wrong (we don't want huge board-fixup-tables in the kernel). User-space can now use the simpl DRM API to manage backlights, and the kernel does not need any special driver code to make it work. Patch #1 and #2 are cleanups and can be applied right away. #3 adds in-kernel backlight APIs and #4 implements the connector-backlight link. Comments welcome! David David Herrmann (4): backlight: use static initializers backlight: use spin-lock to protect device list backlight: add kernel-internal backlight API drm: link connectors to backlight devices drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_backlight.c | 387 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc.c | 45 +++-- drivers/gpu/drm/drm_drv.c | 11 + drivers/gpu/drm/drm_sysfs.c | 53 +++++ drivers/video/backlight/backlight.c | 91 +++++++-- include/drm/drm_backlight.h | 44 ++++ include/drm/drm_crtc.h | 3 + include/linux/backlight.h | 17 ++ 10 files changed, 622 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/drm/drm_backlight.c create mode 100644 include/drm/drm_backlight.h -- 2.1.0

6 24

[Bug 84771] New: nouveau MMIO read write FAULT HUB_INIT timed out errors
by bugzilla-daemon＠bugzilla.kernel.org 22 Oct '16

22 Oct '16

https://bugzilla.kernel.org/show_bug.cgi?id=84771 Bug ID: 84771 Summary: nouveau MMIO read write FAULT HUB_INIT timed out errors Product: Drivers Version: 2.5 Kernel Version: 3.17-rc4 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: christtchin(a)gmail.com Regression: No Created attachment 150771 --> https://bugzilla.kernel.org/attachment.cgi?id=150771&action=edit dmesg of regular boot + startx Trying to run Arch Linux on a Lenovo Y400 with an nvidia GT750M graphics card. When trying to boot the nouveau drivers consistently spit out multiple errors. Computer continues the boot process. Errors also occur whenever I try to run anything with hardware acceleration, such as Xorg. It is a similar output to the one that occurs during boot: PBUS, PIBUS, and PGRAPH errors. Attached is a dmesg log of a regular boot and startx. Also a log of opening up Xorg: http://pastebin.com/w48Dx4qq And a log of opening up weston: http://pastebin.com/1VPFgapP -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 83531] New: radeon 6650m cannot boot without radeon.runpm=0
by bugzilla-daemon＠bugzilla.kernel.org 21 Oct '16

21 Oct '16

https://bugzilla.kernel.org/show_bug.cgi?id=83531 Bug ID: 83531 Summary: radeon 6650m cannot boot without radeon.runpm=0 Product: Drivers Version: 2.5 Kernel Version: 3.13-3.15.10 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: kvbevsauce(a)gmail.com Regression: No my laptop is a lenovo z575 with an amd a6-3420 apu and a 6650m for hybrid graphics. I am running fedora 20 with the latest kernel of 3.15.10 ever since I updated to kernel 3.13 sometime ago when hybrid DPM was enabled my laptop will not boot without the above kernel parameter. i have the plymouth boot screen disabled so it shows text based boot. the moment the boot text "fedora 20 hisenbug" shows up, between 3 and 5 seconds later the cursor will stop blinking and the system will be frozen. sometimes more boot text shows up after sometimes not. any help to get dynamic power management working. -- You are receiving this mail because: You are watching the assignee of the bug.

1 2

[Bug 90997] [apitrace] GPU lockup with Dishonored and Gallium Nine
by bugzilla-daemon＠freedesktop.org 29 Sep '16

29 Sep '16

https://bugs.freedesktop.org/show_bug.cgi?id=90997 Bug ID: 90997 Summary: [apitrace] GPU lockup with Dishonored and Gallium Nine 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: commendsarnex(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Hi guys, If I try to play Dishonored with Gallium Nine, I get a gpu lockup. If I play the game with normal wine, there is no issue. This apitrace consistently causes the lockup with Nine, but plays normally with wine. Apitrace: https://idontevenlift.no-ip.org/Dishonored.trace.xz I've attached a run of the apitrace with R600_DEBUG=ps,vs,trace_cs. There is no rlockup file created from the trace_cs, I've searched the whole computer and tried multiple times. I am using LLVM git, Mesa git, and kernel 4.0.5. My GPU is a Radeon HD 7950[Tahiti]. Thanks, sarnex -- You are receiving this mail because: You are the assignee for the bug.

1 4

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015