dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[Bug 76284] New: [radeon] dota2, applying new screen resolution corrupts display
by bugzilla-daemon＠freedesktop.org 26 Jun '14

26 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=76284 Priority: medium Bug ID: 76284 Assignee: dri-devel(a)lists.freedesktop.org Summary: [radeon] dota2, applying new screen resolution corrupts display Severity: minor Classification: Unclassified OS: Linux (All) Reporter: sylvain.bertrand(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/radeonsi Product: Mesa In dota2, with a radeon GPU, evergreen and southern islands, when I apply a new resolution, the display is corrupted, nearly unusable. up-to-date fedora rawhide. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 42603] New: Watching video with radeon oss driver sometimes leads to kernel panic
by bugzilla-daemon＠bugzilla.kernel.org 26 Jun '14

26 Jun '14

https://bugzilla.kernel.org/show_bug.cgi?id=42603 Summary: Watching video with radeon oss driver sometimes leads to kernel panic Product: Drivers Version: 2.5 Kernel Version: 3.0.17 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: bugzilla.kernel.org(a)boris64.net Regression: No Created an attachment (id=72119) --> (https://bugzilla.kernel.org/attachment.cgi?id=72119) picture of panic Watching video (mostly flashvideo and dvb-s/c in kaffeine) sometimes leads to kernel panic with the radeon oss driver. This is somehow not reproducable, but happens about once a week. It happens for quite some time (1/2 a year?) now, also happened on older kernels, actually since i own this card... Attached is a screenshot of the panic. Used software: kernel-3.0.17 xorg-server-1.11.3 mesa+xf86-video-radeon: latest git snapshot(s) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 2

[Bug 42616] New: Radeon Kernel Mode Setting sets wrong mode
by bugzilla-daemon＠bugzilla.kernel.org 26 Jun '14

26 Jun '14

https://bugzilla.kernel.org/show_bug.cgi?id=42616 Summary: Radeon Kernel Mode Setting sets wrong mode Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: thomas.jones(a)utoronto.ca Regression: No I have a Radeon HD 3470, connected to a Dell P2010H monitor via Display Port. The monitor's native resolution is 1600x900, and everything works correctly with UMS, however if I use KMS I cannot use that mode, I can use at least 1024x768, 1280x1024, and 1152x864 with KMS, but no matter how I try I cannot get it to work in 1600x900. I have tried with the CVT timings, (reduced blanking and not) and with the ones provided in the monitor's EDID. If I attempt to set any of those modes (the 1600x900) with KMS on the monitor claims that I'm using an unsupported mode. UMS works just fine though. I'm running Fedora, and I don't think this is a regression in the kernel since I don't think this computer has ever worked with KMS. Right now what I've done is I have set the kernel command line to boot with 1152x864 and KMS, then I tried to use xrandr to change modes and the monitor just complained. dmesg doesn't seem to have anything useful to say, and neither does Xorg.0.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 8

[Bug 68151] New: Backlight brightness change causes freeze (radeon with KMS)
by bugzilla-daemon＠bugzilla.kernel.org 20 Jun '14

20 Jun '14

https://bugzilla.kernel.org/show_bug.cgi?id=68151 Bug ID: 68151 Summary: Backlight brightness change causes freeze (radeon with KMS) Product: Drivers Version: 2.5 Kernel Version: 3.13-rc6 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: fabian(a)ritter-vogt.de Regression: No Created attachment 120871 --> https://bugzilla.kernel.org/attachment.cgi?id=120871&action=edit Output of hwinfo If I change the backlight brightness using the brightness keys on my keyboard, sometimes the system freezes. SysRq doesn't work. Mobility radeon 5470 with KMS enabled. I first noticed this when upgrading openSUSE from 12.3 (3.7.10) to 13.1 (3.11.6). I have to use "acpi_backlight=vendor" to disable acpi_video0, which isn't working and has a higher priority than radeon_bl0. Reproducible: Always The hwinfo was created with the older, working kernel running. -- You are receiving this mail because: You are watching the assignee of the bug.

1 4

[Bug 66452] New: JUNIPER UVD accelerated playback of WMV3 streams does not work
by bugzilla-daemon＠freedesktop.org 18 Jun '14

18 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=66452 Priority: medium Bug ID: 66452 Assignee: dri-devel(a)lists.freedesktop.org Summary: JUNIPER UVD accelerated playback of WMV3 streams does not work Severity: normal Classification: Unclassified OS: Linux (All) Reporter: eugene.shalygin+bugzilla.FDO(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI When playing WMV3 streams using mplayer (or mplayer2 or ffplay or mpv) the output is corrupted: it looks like black rectangle with color mess at the top (https://imageshack.com/a/img22/534/yw2a.png). acceleration of h264 works fine, so I conclude that UVD is initialized succesfully Radeon Mobility HD 5850 Kernel 3.10.0, libdrm and mesa are from git master (30.06.2013) sample file: http://samples.mplayerhq.hu/asf-wmv/asf_with_chapters.wmv -- You are receiving this mail because: You are the assignee for the bug.

1 10

[PATCH 0/6] File Sealing & memfd_create()
by David Herrmann 17 Jun '14

17 Jun '14

Hi This series introduces the concept of "file sealing". Sealing a file restricts the set of allowed operations on the file in question. Multiple seals are defined and each seal will cause a different set of operations to return EPERM if it is set. The following seals are introduced: * SEAL_SHRINK: If set, the inode size cannot be reduced * SEAL_GROW: If set, the inode size cannot be increased * SEAL_WRITE: If set, the file content cannot be modified Unlike existing techniques that provide similar protection, sealing allows file-sharing without any trust-relationship. This is enforced by rejecting seal modifications if you don't own an exclusive reference to the given file. So if you own a file-descriptor, you can be sure that no-one besides you can modify the seals on the given file. This allows mapping shared files from untrusted parties without the fear of the file getting truncated or modified by an attacker. Several use-cases exist that could make great use of sealing: 1) Graphics Compositors If a graphics client creates a memory-backed render-buffer and passes a file-decsriptor to it to the graphics server for display, the server _has_ to setup SIGBUS handlers whenever mapping the given file. Otherwise, the client might run ftruncate() or O_TRUNC on the on file in parallel, thus crashing the server. With sealing, a compositor can reject any incoming file-descriptor that does _not_ have SEAL_SHRINK set. This way, any memory-mappings are guaranteed to stay accessible. Furthermore, we still allow clients to increase the buffer-size in case they want to resize the render-buffer for the next frame. We also allow parallel writes so the client can render new frames into the same buffer (client is responsible of never rendering into a front-buffer if you want to avoid artifacts). Real use-case: Wayland wl_shm buffers can be transparently converted 2) Geneal-purpose IPC IPC mechanisms that do not require a mutual trust-relationship (like dbus) cannot do zero-copy so far. With sealing, zero-copy can be easily done by sharing a file-descriptor that has SEAL_SHRINK | SEAL_GROW | SEAL_WRITE set. This way, the source can store sensible data in the file, seal the file and then pass it to the destination. The destination verifies these seals are set and then can parse the message in-line. Note that these files are usually one-shot files. Without any trust-relationship, a destination can notify the source that it released a file again, but a source can never rely on it. So unless the destination releases the file, a source cannot clear the seals for modification again. However, this is inherent to situations without any trust-relationship. Real use-case: kdbus messages already use a similar interface and can be transparently converted to use these seals Other similar use-cases exist (eg., audio), but these two I am personally working on. Interest in this interface has been raised from several other camps and I've put respective maintainers into CC. If more information on these use-cases is needed, I think they can give some insights. The API introduced by this patchset is: * fcntl() extension: Two new fcntl() commands are added that allow retrieveing (SHMEM_GET_SEALS) and setting (SHMEM_SET_SEALS) seals on a file. Only shmfs implements them so far and there is no intention to implement them on other file-systems. All shmfs based files support sealing. Patch 2/6 * memfd_create() syscall: The new memfd_create() syscall is a public frontend to the shmem_file_new() interface in the kernel. It avoids the need of a local shmfs mount-point (as requested by android people) and acts more like MAP_ANON than O_TMPFILE. Patch 3/6 The other 4 patches are cleanups, self-tests and docs. The commit-messages explain the API extensions in detail. Man-page proposals are also provided. Last but not least, the extensive self-tests document the intended behavior, in case it is still not clear. Technically, sealing and memfd_create() are independent, but the described use-cases would greatly benefit from the combination of both. Hence, I merged them into the same series. Please also note that this series is based on earlier works (ashmem, memfd, shmgetfd, ..) and unifies these attempts. Comments welcome! Thanks David David Herrmann (4): fs: fix i_writecount on shmem and friends shm: add sealing API shm: add memfd_create() syscall selftests: add memfd_create() + sealing tests David Herrmann (2): (man-pages) fcntl.2: document SHMEM_SET/GET_SEALS commands memfd_create.2: add memfd_create() man-page arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + fs/fcntl.c | 12 +- fs/file_table.c | 27 +- include/linux/shmem_fs.h | 17 + include/linux/syscalls.h | 1 + include/uapi/linux/fcntl.h | 13 + include/uapi/linux/memfd.h | 9 + kernel/sys_ni.c | 1 + mm/shmem.c | 267 +++++++- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/memfd/.gitignore | 2 + tools/testing/selftests/memfd/Makefile | 29 + tools/testing/selftests/memfd/memfd_test.c | 972 +++++++++++++++++++++++++++++ 14 files changed, 1338 insertions(+), 15 deletions(-) create mode 100644 include/uapi/linux/memfd.h create mode 100644 tools/testing/selftests/memfd/.gitignore create mode 100644 tools/testing/selftests/memfd/Makefile create mode 100644 tools/testing/selftests/memfd/memfd_test.c -- 1.9.0

15 48

[Bug 75917] New: backlight switches of when starting X since kernel-3.13
by bugzilla-daemon＠freedesktop.org 16 Jun '14

16 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=75917 Priority: medium Bug ID: 75917 Assignee: dri-devel(a)lists.freedesktop.org Summary: backlight switches of when starting X since kernel-3.13 Severity: normal Classification: Unclassified OS: All Reporter: nl(a)gnuffy.net Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI After updating from linux 3.12.8 to 3.13 my display backlight switches off when starting X. The kernel doesn't crash, it just switched off the backlight. Hardware name: Acer Aspire 3820T/JM31_CP, BIOS V1.19 10/27/2010 This is a notebook with an intel/radeon hybrid graphics. I use intel for my X. I report this as radeon problem because git bisect (on linux-stable tree) showed the following commit as the cause of my problem: 10ebc0bc09344ab6310309169efc73dfe6c23d72 is the first bad commit commit 10ebc0bc09344ab6310309169efc73dfe6c23d72 Author: Dave Airlie <airlied at redhat.com> Date: Mon Sep 17 14:40:31 2012 +1000 drm/radeon: add runtime PM support (v2) This hooks radeon up to the runtime PM system to enable dynamic power management for secondary GPUs in switchable and powerxpress laptops. v2: agd5f: clean up, add module parameter Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Alex Deucher <alexander.deucher at amd.com> Please let me know if you need addititonal information. -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 44800] New: Radeon HD 6450 CAICOS screen corruption and kernel crashes
by bugzilla-daemon＠freedesktop.org 16 Jun '14

16 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=44800 Bug #: 44800 Summary: Radeon HD 6450 CAICOS screen corruption and kernel crashes Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: marko.kohtala(a)gmail.com Created attachment 55597 --> https://bugs.freedesktop.org/attachment.cgi?id=55597 Artefacts in X I got Radeon HD 6450 1GB DDR3 last fall and have been unable to use it. I currently run fairly recent 32-bit Debian versions on top of 64-bit vanilla kernel 3.2.1 (currently with minor patch to makefile and a debug output patch https://bugs.freedesktop.org/attachment.cgi?id=53428). I've tried with 32-bit kernel and some older kernels without noticing any difference. I've tried installing Windows and ran some OpenCL tests. All worked fine so I'd expect the hardware is working correctly. I tried if kernel options iomem=off mem=2G would help. They did not help. mem=2G was needed because jmicron driver for ATA failed without iomem. I attach some more files I collected while trying if it has gotten fixed. Now I'm back to running a loaned nVidia card to be able to report this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 16

[Bug 75234] New: UVD initialization fails while dGPU is powered on by DRI_PRIME
by bugzilla-daemon＠freedesktop.org 13 Jun '14

13 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=75234 Priority: medium Bug ID: 75234 Assignee: dri-devel(a)lists.freedesktop.org Summary: UVD initialization fails while dGPU is powered on by DRI_PRIME Severity: normal Classification: Unclassified OS: All Reporter: rakothedin(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 94396 --> https://bugs.freedesktop.org/attachment.cgi?id=94396&action=edit dmesg The discrete graphics in my laptop (Intel HD 4000 + Radeon 7750M) doesn't initialize UVD successfully when it is powered on by DRI_PRIME. Interestingly when the laptop is booted UVD is initialized. My kernel is 3.14-rc3 from OpenSUSE head repository. Userspace is from git. Attached file is my dmesg. The errors at time 859.063821 correspond to the case when I ran glxgears with DRI_PRIME. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 76531] New: linux-3.14-rc7 radeon/nouveau runtime-suspend never coming back
by bugzilla-daemon＠freedesktop.org 08 Jun '14

08 Jun '14

https://bugs.freedesktop.org/show_bug.cgi?id=76531 Priority: medium Bug ID: 76531 Assignee: dri-devel(a)lists.freedesktop.org Summary: linux-3.14-rc7 radeon/nouveau runtime-suspend never coming back Severity: normal Classification: Unclassified OS: Linux (All) Reporter: bonbons67(a)internet.lu Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/other Product: DRI Most recent testing: 3.14-rc7 mainline. As suggested on IRC by imirkin, returning -EBUSY instead of -EINVAL from nouveau_pmops_runtime_suspend() avoids driver to fall too far to the ground. When returning -EINVAL connectors get being seen as "disconnected" and there is no way to get them connected anymore. When returning -EBUSY the connectors stay functional but DE (enlightenment) complains about missing crtc and all that is visible is black background and a cursor that response to mouse/trackpad. Way to reproduce: Have xorg running, then for each avtive output call: xrandr --output $OUTPUT --off When last output got marked off runtime-suspend kicks in. Same/similar behavior has been observed on radeon (I don't remember the exact kernel releases, but older ones got console to display when switching VTs while newer failed to do so). -- You are receiving this mail because: You are the assignee for the bug.

1 4

← Newer
1
...
54
55
56
57
58
59
60
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014