[Bug 93895] GPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (works fine with fglrx)
https://bugs.freedesktop.org/show_bug.cgi?id=93895 --- Comment #7 from Alex Deucher --- Check your xorg log and make sure acceleration is enabled. -- 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/20160131/5e629dfa/attachment.html>
[Bug 93895] GPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (works fine with fglrx)
https://bugs.freedesktop.org/show_bug.cgi?id=93895 --- Comment #6 from Azari --- I have something new to report after doing more testing. It seems that if I launch weston with the pixman backend (weston --use-pixman), that works, but meanwhile, startx with 'exec twm' in .xinitrc doesn't work on first attempt, it causes the lockup. However, after the lockup, if i try to startx again (still with twm), it suddenly works and i can start applications in twm and use the desktop. I managed to reproduce this with Xfce as well, the first 'startxfce4' after bootup will fail and lockup the GPU, and after it resets, I try again and Xfce works. One thing of note is that when I finally do manage to get a DE started (after the GPU has locked up and reset once), glxinfo shows only "gallium on llvmpipe"; no hardware acceleration available. So whatever is causing the lockup is something that X does at startup (even when a minimal X window manager like twm is used), but weston-pixman doesn't 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/20160131/0d459d22/attachment.html>
[PATCH 12/12] drm/dp: Add drm_dp_link_choose() helper
On Mon, 14 Dec 2015, Thierry Reding wrote:
> From: Thierry Reding
>
> This helper chooses an appropriate configuration, according to the
> bitrate requirements of the video mode and the capabilities of the
> DisplayPort sink.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 55
> +
> include/drm/drm_dp_helper.h | 5
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index da519acfeba7..95825155dc89 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -512,6 +512,61 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
> drm_dp_link *link)
> }
> EXPORT_SYMBOL(drm_dp_link_configure);
>
> +/**
> + * drm_dp_link_choose() - choose the lowest possible configuration for a mode
> + * @link: DRM DP link object
> + * @mode: DRM display mode
> + * @info: DRM display information
> + *
> + * According to the eDP specification, a source should select a configuration
> + * with the lowest number of lanes and the lowest possible link rate that can
> + * match the bitrate requirements of a video mode. However it must ensure not
> + * to exceed the capabilities of the sink.
Eventually this would have to take into account the intersection of
per-sink and per-source supported rates, including the intermediate
frequencies. Until then, i915 couldn't switch over.
BR,
Jani.
> + *
> + * Returns: 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_choose(struct drm_dp_link *link,
> +const struct drm_display_mode *mode,
> +const struct drm_display_info *info)
> +{
> + /* available link symbol clock rates */
> + static const unsigned int rates[3] = { 162000, 27, 54 };
> + /* available number of lanes */
> + static const unsigned int lanes[3] = { 1, 2, 4 };
> + unsigned long requirement, capacity;
> + unsigned int rate = link->max_rate;
> + unsigned int i, j;
> +
> + /* bandwidth requirement */
> + requirement = mode->clock * info->bpc * 3;
> +
> + for (i = 0; i < ARRAY_SIZE(lanes) && lanes[i] <= link->max_lanes; i++) {
> + for (j = 0; j < ARRAY_SIZE(rates) && rates[j] <= rate; j++) {
> + /*
> + * Capacity for this combination of lanes and rate,
> + * factoring in the ANSI 8B/10B encoding.
> + *
> + * Link rates in the DRM DP helpers are really link
> + * symbol frequencies, so a tenth of the actual rate
> + * of the link.
> + */
> + capacity = lanes[i] * (rates[j] * 10) * 8 / 10;
> +
> + if (capacity >= requirement) {
> + DRM_DEBUG_KMS("using %u lanes at %u kHz
> (%lu/%lu kbps)\n",
> + lanes[i], rates[j], requirement,
> + capacity);
> + link->lanes = lanes[i];
> + link->rate = rates[j];
> + return 0;
> + }
> + }
> + }
> +
> + return -ERANGE;
> +}
> +EXPORT_SYMBOL(drm_dp_link_choose);
> +
> /*
> * I2C-over-AUX implementation
> */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 20ae0e413b64..f3eacf62add8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -27,6 +27,8 @@
> #include
> #include
>
> +#include
> +
> /*
> * Unless otherwise noted, all values are from the DP 1.1a spec. Note that
> * DP and DPCD versions are independent. Differences from 1.0 are not noted,
> @@ -832,6 +834,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
> drm_dp_link *link);
> int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_link_choose(struct drm_dp_link *link,
> +const struct drm_display_mode *mode,
> +const struct drm_display_info *info);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
--
Jani Nikula, Intel Open Source Technology Center
[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.
https://bugs.freedesktop.org/show_bug.cgi?id=90481 xsellier at gmail.com changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |xsellier at gmail.com |.org| --- Comment #4 from xsellier at gmail.com --- Created attachment 121426 --> https://bugs.freedesktop.org/attachment.cgi?id=121426&action=edit kern.log 4.4.0-amd64 -- 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/20160131/66720e42/attachment.html>
[PATCH] drm/radeon: Avoid double gpu reset by adding a timeout on IB ring tests.
ence->seq;
> >
> > - r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr,
> > MAX_SCHEDULE_TIMEOUT); +r = radeon_fence_wait_seq_timeout(fence->rdev,
> > seq, intr, timeout);>
> > if (r < 0) {
> >
> > return r;
> >
> > + } else if (r == 0) {
> > + return -ETIMEDOUT;
> >
> > }
> >
> > r = fence_signal(&fence->base);
> >
> > @@ -564,6 +567,22 @@ int radeon_fence_wait(struct radeon_fence *fence,
> > bool intr)>
> > }
> >
> > /**
> >
> > + * radeon_fence_wait - wait for a fence to signal
> > + *
> > + * @fence: radeon fence object
> > + * @intr: use interruptible sleep
> > + *
> > + * Wait for the requested fence to signal (all asics).
> > + * @intr selects whether to use interruptable (true) or non-interruptable
> > + * (false) sleep when waiting for the fence.
> > + * Returns 0 if the fence has passed, error for all other cases.
> > + */
> > +int radeon_fence_wait(struct radeon_fence *fence, bool intr)
> > +{
> > + return radeon_fence_wait_timeout(fence, intr, MAX_SCHEDULE_TIMEOUT);
> > +}
> > +
> > +/**
> >
> >* radeon_fence_wait_any - wait for a fence to signal on any ring
> >*
> >* @rdev: radeon device pointer
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
> > b/drivers/gpu/drm/radeon/radeon_vce.c index 7eb1ae7..7d80dad 100644
> > --- a/drivers/gpu/drm/radeon/radeon_vce.c
> > +++ b/drivers/gpu/drm/radeon/radeon_vce.c
> > @@ -810,7 +810,8 @@ int radeon_vce_ib_test(struct radeon_device *rdev,
> > struct radeon_ring *ring)>
> > goto error;
> >
> > }
> >
> > - r = radeon_fence_wait(fence, false);
> > + r = radeon_fence_wait_timeout(fence, false, msecs_to_jiffies(
> > + (radeon_lockup_timeout) ? radeon_lockup_timeout :
> > MAX_SCHEDULE_TIMEOUT));>
> > if (r) {
> >
> > DRM_ERROR("radeon: fence wait failed (%d).\n", r);
> >
> > } else {
> >
> > diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
> > b/drivers/gpu/drm/radeon/uvd_v1_0.c index c6b1cbc..35caa89 100644
> > --- a/drivers/gpu/drm/radeon/uvd_v1_0.c
> > +++ b/drivers/gpu/drm/radeon/uvd_v1_0.c
> > @@ -522,7 +522,8 @@ int uvd_v1_0_ib_test(struct radeon_device *rdev,
> > struct radeon_ring *ring)>
> > goto error;
> >
> > }
> >
> > - r = radeon_fence_wait(fence, false);
> > + r = radeon_fence_wait_timeout(fence, false, msecs_to_jiffies(
> > + (radeon_lockup_timeout) ? radeon_lockup_timeout :
> > MAX_SCHEDULE_TIMEOUT));>
> > if (r) {
> >
> > DRM_ERROR("radeon: fence wait failed (%d).\n", r);
> > goto error;
--
Matthew
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5584 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160131/d944bd7d/attachment-0001.bin>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #84 from Ioannis Panagiotopoulos --- (In reply to Thomas DEBESSE from comment #83) I did further testing. I used a script on init.d to assign the values before xserver starts, and managed to get a working system with the parameters set on low, battery. I created 2 scripts to run after the system boot with dpm enabled, to toggle between low/battery to high/performance and vice versa. Changing from low to high succeeds and x server runs well. I even run a 3d game for about 10 minutes without problem. However when using the script to change back to low/battery, the system crashes with black screen. I tested this case 3 times and crashed all 3 when set from high to low. --- Comment #85 from Jonas --- I just tried the hawaii_k_smc.bin as in comment #77, and it worked great. I could play every game I have installed without problem. Some games still don't work as they should (worse performance than my old 7770), but most of them work great. Now I'm using latest .bin files as pointed out in comment #32 and it still works great. So, it's definitely getting better, at least for some of us :). Thanks for your hard work! -- 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/20160131/e46da16d/attachment-0001.html>
[PATCH libdrm 3/3] libkms: add libdrm to Requires.private
Analogous to last two changes (amdgpu and radeon).
Cc: Jakob Bornecrantz
Signed-off-by: Emil Velikov
---
libkms/libkms.pc.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/libkms/libkms.pc.in b/libkms/libkms.pc.in
index 511535a..1421b3e 100644
--- a/libkms/libkms.pc.in
+++ b/libkms/libkms.pc.in
@@ -8,3 +8,4 @@ Description: Library that abstract aways the different mm
interface for kernel d
Version: 1.0.0
Libs: -L${libdir} -lkms
Cflags: -I${includedir}/libkms
+Requires.private: libdrm
--
2.6.2
[PATCH libdrm 2/3] radeon: add libdrm to Requires.private
Equivalent to the amdgpu commit before. Additionally, when libdrm is
installed to a 'non-default' location, users of libdrm_radeon will fail
to build, as radeon_cs.h (and maybe others) won't have their
dependencies (drm.h radeon_drm.h) fulfilled.
Cc: Michel Dänzer
Cc: Christian König
Signed-off-by: Emil Velikov
---
radeon/libdrm_radeon.pc.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/radeon/libdrm_radeon.pc.in b/radeon/libdrm_radeon.pc.in
index 68ef0ab..432993a 100644
--- a/radeon/libdrm_radeon.pc.in
+++ b/radeon/libdrm_radeon.pc.in
@@ -8,3 +8,4 @@ Description: Userspace interface to kernel DRM services for
radeon
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -ldrm_radeon
Cflags: -I${includedir} -I${includedir}/libdrm
+Requires.private: libdrm
--
2.6.2
[PATCH libdrm 1/3] amdgpu: add libdrm as private requirement/dependency
Otherwise libdrm.so won't end up in the --libs, when one static links
libdrm_amdgpu.
Cc: Michel Dänzer
Cc: Christian König
Signed-off-by: Emil Velikov
---
amdgpu/libdrm_amdgpu.pc.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/amdgpu/libdrm_amdgpu.pc.in b/amdgpu/libdrm_amdgpu.pc.in
index 417865e..f1c552a 100644
--- a/amdgpu/libdrm_amdgpu.pc.in
+++ b/amdgpu/libdrm_amdgpu.pc.in
@@ -8,3 +8,4 @@ Description: Userspace interface to kernel DRM services for
amdgpu
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -ldrm_amdgpu
Cflags: -I${includedir} -I${includedir}/libdrm
+Requires.private: libdrm
--
2.6.2
[Bug 93936] Snail shadertoy displays black quad
https://bugs.freedesktop.org/show_bug.cgi?id=93936 --- Comment #3 from pavol at klacansky.com --- This prints forever: EE /var/tmp/portage/media-libs/mesa-11.1.1/work/mesa-11.1.1/src/gallium/drivers/r600/r600_state_common.c:815 r600_shader_select - Failed to build shader variant (type=1) -1 EE /var/tmp/portage/media-libs/mesa-11.1.1/work/mesa-11.1.1/src/gallium/drivers/r600/r600_shader.c:161 r600_pipe_shader_create - translation from TGSI failed ! -- 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/20160131/78194e7b/attachment.html>
[Bug 93936] Snail shadertoy displays black quad
https://bugs.freedesktop.org/show_bug.cgi?id=93936 --- Comment #2 from Michel D�nzer --- Seems to work fine with radeonsi FWIW. Is there anything interesting in Firefox's stderr output? Maybe the r600 driver is failing to compile a shader. -- 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/20160131/04480def/attachment.html>
