dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[Bug 77269] New: libdrm (git) 2.4.52 make check fail
by bugzilla-daemon＠freedesktop.org 12 Dec '16

12 Dec '16

https://bugs.freedesktop.org/show_bug.cgi?id=77269 Priority: medium Bug ID: 77269 Assignee: dri-devel(a)lists.freedesktop.org Summary: libdrm (git) 2.4.52 make check fail Severity: normal Classification: Unclassified OS: All Reporter: monts.here2(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: libdrm Product: DRI ====config======== Core i3 haswell uname -a Linux em1 3.15.0-0.rc0.git9.2.fc21.x86_64 #1 SMP Mon Apr 7 13:25:48 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) =======config======== ./autogen.sh --enable-udev --disable-radeon --disable-nouveau make -j8 make -j check <===== fails ../build-aux/test-driver: line 95: 23128 Aborted (core dumped) "$@" > $log_file 2>&1 FAIL: updatedraw PASS: gem_flink ../build-aux/test-driver: line 95: 23130 Aborted (core dumped) "$@" > $log_file 2>&1 FAIL: setversion PASS: gem_readwrite PASS: gem_mmap make[5]: Entering directory `/opt/src/drm/tests' Making all in modeprint make[6]: Entering directory `/opt/src/drm/tests/modeprint' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/modeprint' Making all in kmstest make[6]: Entering directory `/opt/src/drm/tests/kmstest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/kmstest' Making all in modetest make[6]: Entering directory `/opt/src/drm/tests/modetest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/modetest' Making all in vbltest make[6]: Entering directory `/opt/src/drm/tests/vbltest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/vbltest' make[6]: Entering directory `/opt/src/drm/tests' make[6]: Nothing to be done for `all-am'. make[6]: Leaving directory `/opt/src/drm/tests' make[5]: Leaving directory `/opt/src/drm/tests' ============================================================================ Testsuite summary for libdrm 2.4.52 ============================================================================ # TOTAL: 11 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=DRI ============================================================================ make[4]: *** [test-suite.log] Error 1 make[4]: Leaving directory `/opt/src/drm/tests' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/opt/src/drm/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/opt/src/drm/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/opt/src/drm/tests' make: *** [check-recursive] Error 1 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 67435] New: HDMI audio silent on Radeon Mobility HD4650
by bugzilla-daemon＠freedesktop.org 07 Nov '16

07 Nov '16

https://bugs.freedesktop.org/show_bug.cgi?id=67435 Priority: medium Bug ID: 67435 Assignee: dri-devel(a)lists.freedesktop.org Summary: HDMI audio silent on Radeon Mobility HD4650 Severity: normal Classification: Unclassified OS: All Reporter: kris(a)syntosis.net Hardware: All Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI I cannot get any audio through the HDMI port, internal speakers work as they should. Kernel option is properly set, and everything is unmuted. Audio worked fine in the 3.9 kernels, and stopped working somewhere in 3.10 Currently using 3.11-rc2 and still have the same issue. relevant info from dmesg: ------- Kernel command line: BOOT_IMAGE=/vmlinuz-3.11.0-rc2 radeon.dpm=1 radeon.audio=1 video=1360x768 rootfstype=btrfs root=/dev/sda3 [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV730 0x1002:0x9480 0x104D:0x9035). [drm] register mmio base: 0xD0020000 [drm] register mmio size: 65536 radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode [drm] PCIE GART of 512M enabled (table at 0x000000000025D000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff88013856dc00 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff88013856dc0c radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffc90010d9c598 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon 0000:01:00.0: irq 50 for MSI/MSI-X radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ring test on 5 succeeded in 1 usecs [drm] UVD initialized successfully. [drm] Enabling audio support [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] ib test on ring 5 succeeded [drm:radeon_atombios_get_lvds_info] *ERROR* Bad LCD record 217 [drm] radeon atom DIG backlight initialized [drm] Radeon Display Connectors [drm] Connector 0: [drm] LVDS-1 [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 2: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] radeon: dpm initialized [drm] fb mappable at 0xC035F000 [drm] vram apper at 0xC0000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device radeon 0000:01:00.0: registered panic notifier [drm] Initialized radeon 2.34.0 20080528 for 0000:01:00.0 on minor 0 ---- -- You are receiving this mail because: You are the assignee for the bug.

1 19

[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 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 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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014