[Bug 92836] amdgpu does not resume properly from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=92836 --- Comment #7 from David Walker --- apci_osi=Linux doesn't seem to help. I have found that it does recover sometimes, albeit rarely, and more often when running Gnome with Wayland, rather than X11, and sometimes only after control-alt-backspace. I haven't done all that much testing, though, so this all may simply be coincidence. Any other debugging I could do? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/84b90227/attachment.html>
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 Bug ID: 92858 Summary: AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: ysxikrhn at vomoto.com Created attachment 119469 --> https://bugs.freedesktop.org/attachment.cgi?id=119469=edit dmesg_log_file_from_booting_kernel_4.3-rc7 I utilize an AMD Radeon 7770 (CAPE VERDE) GPU, which until kernel 4.2 and above, provided accelerated OpenGL as it was supposed to. As per http://xorg.freedesktop.org/wiki/RadeonFeature/, this is a Southern Islands card and should be utilizing the radeon drm module and the radeonsi dri driver. Although the computer still boots and the card initializes with kernels later than 4.1.x, but there is no 3d acceleration, or at least not via the GPU itself--the llvmpipe software rasterizer works but doesn't provide the OpenGL support nor speed that the radeonsi driver does. My computer is currently running Netrunner rolling (Manjaro based) and updated to the latest packages in the Manjaro repos. The installed graphics stack consists of mesa 11.0.4, libdrm 2.4.65, and xf86-video-ati 1:7.5.0-2. I initially noticed this bug and/or issue because Plasma/KF5 couldn't use OpenGL or OpenGLES acceleration under 4.2 and later kernels. This lead me to investigate why it didn't. I've confirmed the lack of hardware-accelerated OpenGL under kernels 4.2.x and later via glxifo. If I run it when I'm booted under kernel 4.1.12 or earlier, the output indicates the driver is providing openGL 4.1 core profile, OpenGL 3.0, and OpenGLES 3.0. If, however, I boot up any kernel 4.2 or higher, mesa uses the llvmpipe software rasterizer. If I boot kernel 4.3-rc7, which is the latest available under Manjaro as of today, the correct drm driver (radeon.ko) is being initialized as evidenced by: "1.906749] [drm] radeon kernel modesetting enabled" and "456843] fb: switching to radeondrmfb from VESA VGA" in the dmesg. The firmware is also being loaded, as per: "2.457304] [drm] Loading verde Microcode" However, later in the boot process something causes GPU acceleration to be disabled: 2.558871] [drm] radeon: irq initialized.[3.340560] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [3.340564] radeon :01:00.0: disabling GPU acceleration The section pasted above of the dmesg from kernel 4.3-rc-7 indicates the driver is failing on the "drm:r600_ringtest"...however, this is not a r600 card but a Southern Islands. Steps taken while attempting to resolve the issue: I'd initiallly thought it could be a firmware issue, with the linux-firmware package in the distro perhaps not having been updated to support the latest kernels, but even when I installed linux-firmware-git from the AUR to replace the standard linux-firmware package and then booted linux 4.3-rc7, mesa was still using llvmpipe instead of radeonsi, due to no GPU accel. I've also compiled the 4.3.0 kernel using the tarball directly from kernel.org, and a default kernel configuration file from ubuntu. When I booted into the 4.3.0 upstream kernel, GPU acceleration was still disabled. As neither the source nor the kernel config were from Manjaro, doesn't this rule out a distro bug and indicate the issue is upstream? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/fa803629/attachment.html>
[Bug 92850] Segfault loading War Thunder
https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #3 from Nicolai Hähnle --- Backtrace: When running in gdb, enter the "bt" command after the crash. That will give you the backtrace. Debug symbols: If you compile Mesa yourself, I believe running the configure script with --enable-debug in addition to the other usual options and recompiling everything should do the trick. If you're using some distribution package, there should usually be packages with a -dbg name that will install the required debug symbols. Apitrace: Even if apitrace does not give you an error message, the trace itself (i.e. the generated .trace file) could be useful for reproducing the issue. Zip it (xz is popular) and upload it somewhere if possible. Also, please provide the full output of glxinfo and dmesg for bugs like this. _However_, even with all that said, it is entirely possible that the version override is messing something up. If other people have been using Mesa with the override successfully, they might have other hardware and just been lucky enough to be using a driver that happens to work with the override. Generally, using such overrides pretty much means all bets are off. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/d3144a3e/attachment.html>
[Bug 91202] output to DVI-I is blank
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #7 from Guido Winkelmann --- Can confirm the problem with an R9 285 chip (graphics card is called ASUS STRIX-R9285-DC2OC-2GD5). The monitor receives no input (switching to power saving mode) when run at its preferred resolution of 2560x1440. It will work with any other resolution, but switching it back 2560x1440 will disable it again. This is with Kernel 4.3 and the amdgpu driver from today's git master. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/dc47f381/attachment.html>
[Bug 106431] On ASUS A8JN laptop with G72M GPU dmesg is flooded with error messages
https://bugzilla.kernel.org/show_bug.cgi?id=106431 --- Comment #9 from poma --- Please push to linux-next and mainline 4.3. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 106431] On ASUS A8JN laptop with G72M GPU dmesg is flooded with error messages
https://bugzilla.kernel.org/show_bug.cgi?id=106431 --- Comment #8 from poma --- Tested with: 4.3.0-2.fc22.i686 i.e. 4.3.0-1.fc24.i686 + nv-drm-vblank.patch https://bugzilla.kernel.org/attachment.cgi?id=191861 Tested-by: poma -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] man: use placeholders for man section number
xsltproc generates man pages with suffix 7
but Makefile.am uses MISC_MAN_SUFFIX which is defined as 5
in xorg-macros.m4 on Solaris.
This leads to the build error:
sed: can't read drm-mm.5: No such file or directory
Also Linux man section 7 corresponds to Solaris section 5.
---
man/Makefile.am | 9 ++---
man/drm-kms.xml | 10 +-
man/drm-memory.xml | 32
man/drm.xml | 10 +-
man/drmAvailable.xml| 2 +-
man/drmHandleEvent.xml | 4 ++--
man/drmModeGetResources.xml | 4 ++--
7 files changed, 37 insertions(+), 34 deletions(-)
diff --git a/man/Makefile.am b/man/Makefile.am
index 00eb423..c5f0a35 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -53,10 +53,13 @@ XSLTPROC_PROCESS_MAN = \
$(miscman_aliases_DATA): $(miscman_DATA)
$(AM_V_GEN)if test -n "$@" ; then $(SED) -i -e 's/^\.so
\([a-z_]\+\)\.\([0-9]\)$$/\.so man\2\/\1\.\2/' "$@" ; fi
-SUFFIXES = .$(LIB_MAN_SUFFIX) .$(MISC_MAN_SUFFIX) .xml
+SUFFIXES = .$(LIB_MAN_SUFFIX) .$(MISC_MAN_SUFFIX) .xml .sed
-.xml.$(LIB_MAN_SUFFIX):
+.sed.$(LIB_MAN_SUFFIX):
$(XSLTPROC_PROCESS_MAN)
-.xml.$(MISC_MAN_SUFFIX):
+.sed.$(MISC_MAN_SUFFIX):
$(XSLTPROC_PROCESS_MAN)
+
+.xml.sed:
+ $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < "$<" > "$@"
diff --git a/man/drm-kms.xml b/man/drm-kms.xml
index 5f04157..f26d119 100644
--- a/man/drm-kms.xml
+++ b/man/drm-kms.xml
@@ -24,7 +24,7 @@
drm-kms
-7
+__miscmansuffix__
@@ -133,7 +133,7 @@
through the API which is used as backing storage. The
framebuffer itself is only an abstract object with
no data. It
just refers to memory buffers that must be created with the
-
drm-memory7
+
drm-memory__miscmansuffix__
API.
@@ -176,7 +176,7 @@
After you have a working connector+CRTC+mode combination, you need
to create a framebuffer that is used for scanout. Memory buffer
allocation is driver-depedent and described in
-
drm-memory7.
+
drm-memory__miscmansuffix__.
You need to create a buffer big enough for your selected mode. Now
you can create a framebuffer object that uses your memory-buffer as
scanout buffer. You can do this with
@@ -316,8 +316,8 @@ static int modeset_find_crtc(int fd, drmModeRes
*res, drmModeConnector *conn)
See Also
-
drm7,
-
drm-memory7,
+
drm__miscmansuffix__,
+
drm-memory__miscmansuffix__,
drmModeGetResources3,
drmModeGetConnector3,
drmModeGetEncoder3,
diff --git a/man/drm-memory.xml b/man/drm-memory.xml
index 6b4f075..2a91903 100644
--- a/man/drm-memory.xml
+++ b/man/drm-memory.xml
@@ -24,7 +24,7 @@
drm-memory
-7
+__miscmansuffix__
@@ -214,7 +214,7 @@ struct drm_mode_destroy_dumb {
Objects are referenced from user-space using handles.
These are, for
all intents and purposes, equivalent to file descriptors but avoid
the overhead. Newer kernel drivers also support the
-
drm-prime7
+
drm-prime__miscmansuffix__
infrastructure which can return real file-descriptor for
gem-handles
using the linux dma-buf API. Objects may be published
with a name so
that other applications and processes can access them. The name
@@ -235,9 +235,9 @@ struct drm_mode_destroy_dumb {
use-cases including scanout, rendering, cursors and CPU-access. See
the libgbm library for more information or look at the
driver-dependent man-pages (for example
-
drm-intel7
+
drm-intel__miscmansuffix__
or
-
drm-radeon7).
+
drm-radeon__miscmansuffix__).
Gem-buffers can be closed with the
DRM_IOCTL_GEM_CLOSE ioctl. It takes
as argument
@@ -266,7 +266,7 @@ struct drm_gem_close {
to the current DRM-Master, can guess the name
and open or access the gem-object. If you want more fine-grained
access control, you can use the new
-
drm-prime7
+
drm-prime__miscmansuffix__
API to retrieve file-descriptors for gem-handles. To create a name
for a gem-handle, you use the
DRM_IOCTL_GEM_FLINK ioctl. It takes
as argument
@@ -322,12 +322,12 @@ struct drm_gem_open {
OpenGL so it is not provided. But if you need more detailed
information for a specific driver, you may have a look into the
driver-manpages, including
-
drm-intel7,
-
drm-radeon7
+
drm-intel__miscmansuffix__,
+
drm-radeon__miscmansuffix__
and
-
drm-nouveau7.
+
drm-nouveau__miscmansuffix__.
However, the
-
drm-prime7
+
[Bug 92806] 1 second freezes during new effects UT4
https://bugs.freedesktop.org/show_bug.cgi?id=92806 --- Comment #9 from bellamorte42 at gmail.com --- Thaanks for the info. Should I close this or wait for the problem to be resolved? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/0d748d69/attachment.html>
[Bug 92850] Segfault loading War Thunder
https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #2 from bellamorte42 at gmail.com --- Well, as I said apitrace didn't yield any error messages. I'm using mesa git from a few days ago. I've used probably 5 versions of mesa git with similar results. The 4.1COMPAT is required to work around the devs shoddy coding resulting in a black screen (I think it's due to using EXT_dsa instead of ARB as another bug report stated). Other people have been using Mesa apparently without crashing but with old Ubuntu and the 4.1COMPAT. I don't know how to provide a backtrace with debugging symbols, I'm still a little new to this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/b8d519dd/attachment.html>
[Bug 92850] Segfault loading War Thunder
https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #1 from Nicolai Hähnle --- Hi, thanks for the report. Which version of Mesa are you using? Could you please provide a backtrace with debug symbols installed? I notice you're using a MESA_GL_VERSION_OVERRIDE. Might the crash be related to that? Is apitrace able to produce useful traces in a crash like this for reproduction? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151107/31c13e8b/attachment-0001.html>
[Bug 106851] WARNING: CPU: 0 PID: 686 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80() + drm:radeon_pm_late_init [radeon]] *ERROR*
https://bugzilla.kernel.org/show_bug.cgi?id=106851 --- Comment #7 from lbl --- It doesn't seem to happen with kernel 4.3 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 106431] On ASUS A8JN laptop with G72M GPU dmesg is flooded with error messages
https://bugzilla.kernel.org/show_bug.cgi?id=106431 --- Comment #7 from poma --- See Also: https://bugs.freedesktop.org/show_bug.cgi?id=92852 -- You are receiving this mail because: You are watching the assignee of the bug.
