[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #9 from Darren D. --- (In reply to Christian König from comment #8) > > Well, don't give up. That sounds like a rather normal learning curve to me. > > Just let us know when you have any result or are stuck at some point. I've made some slow but sure progress, but now I'm stuck--I'm reporting as per your request, but it sounds like a config bug perhaps and not bad code? [myusername at computer myusername] cd kernel/linux/ [myusername at computer linux]$ git bisect log # bad: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2 # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect start 'v4.2' 'v4.1' # good: [c11d716218910c3aa2bac1bb641e6086ad649555] Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good c11d716218910c3aa2bac1bb641e6086ad649555 # bad: [e44ac588cd61c960226d61c379e2873a95544a51] drivers/block/nvme-core.c: fix build with gcc-4.4.4 git bisect bad e44ac588cd61c960226d61c379e2873a95544a51 # bad: [e382608254e06c8109f40044f5e693f2e04f3899] Merge tag 'trace-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace git bisect bad e382608254e06c8109f40044f5e693f2e04f3899 # bad: [c5fd936e992dd2829167d2adc63e151675ca6898] drm/nouveau: Pause between setting gpu to D3hot and cutting the power git bisect bad c5fd936e992dd2829167d2adc63e151675ca6898 [myusername at dcomputer linux]$ The kernel I build after I tell git bisect the above revision is bad freezes on "loading initial ramdisk." I've attempted to rebuild the kernel after cleaning the source tree, and in the event my CPU needs the intel microcode, I've verified the intel-ucode package is installed and that the following are enabled in my .config file: CONFIG_MICROCODE=y, CONFIG_MICROCODE_INTEL=y, CONFIG_MICROCODE_INTEL_EARLY=y, CONFIG_MICROCODE_EARLY=y, and CONFIG_MICROCODE_OLD_INTERFACE=y Neither of the above resolved the freezeup. Should I simply build everything into the kernel I can instead of as modules, so the kernel ideally won't need whatever should be in the initramfs but isn't, and can boot up successully? If this isn't the correct place to ask I'll be happy to report it elsewhere, but if you have any suggestions that could help me along, I'll implement those and make another attempt. -- 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/20151115/22b55efa/attachment-0001.html>
[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.
https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #13 from Aneroid --- Ok. But this strange error: "radeon :01:00.0: VCE init error (-22)." What does it mean ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 107001] Radeon HDMI audio lost after resuming from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=107001 Timo Valtoaho changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #10 from Christian König --- That looks promising. Here are a few hints how to proceed. > git bisect good c11d716218910c3aa2bac1bb641e6086ad649555 First of all you don't need to always specify the commit, git knows that by itself. E.g. "git bisect good" without the commit hash should be sufficient. (In reply to Darren D. from comment #9) > git bisect bad c5fd936e992dd2829167d2adc63e151675ca6898 > > The kernel I build after I tell git bisect the above revision is bad freezes > on "loading initial ramdisk." That's unfortunate but happens sometimes. Since c5fd936e992dd2829167d2adc63e151675ca6898 is bad the problem must be somewhere between v4.1 and c5fd936e992dd2829167d2adc63e151675ca6898. Since it is a radeon driver problem I suggest you limit bisect to only test the changes made to radeon. Please try the command "git bisect start c5fd936e992dd2829167d2adc63e151675ca6898 v4.1 drivers/gpu/drm/radeon/". If that still doesn't work try "git bisect skip" if you have a commit that won't work at all. If that also doesn't work just go on with "git bisect good/bad" and try to figure out when the issue with the ramdisk started. -- 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/20151115/0c5ff04f/attachment.html>
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #45 from Daniele Ruffini --- Created attachment 119679 --> https://bugs.freedesktop.org/attachment.cgi?id=119679&action=edit journalctl | grep amdgpu Went on for a while, cut short because the error was just repeating -- 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/20151115/55375e5b/attachment.html>
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #46 from Daniele Ruffini --- Just forgot to mention that the bug for me happens totally randomly. No Unigine Heave. No intensive graphic usage. It seems to happen when something new is displayed tough but i wasn't able to recreate it metodically. Amd Radeon HD380 4GB. -- 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/20151115/28599b89/attachment.html>
[Bug 92962] KDE hangs and system freezes while journalctl lists complains of kernel (nouveau). Nvidia graphics
https://bugs.freedesktop.org/show_bug.cgi?id=92962 Bug ID: 92962 Summary: KDE hangs and system freezes while journalctl lists complains of kernel (nouveau). Nvidia graphics Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel at lists.freedesktop.org Reporter: stakanov at freenet.de Created attachment 119680 --> https://bugs.freedesktop.org/attachment.cgi?id=119680&action=edit output dmesg with system freezes complaining about nouveau This bug has originally reported to the bugzilla of opensuse and I was asked to report it here. Ref: https://bugzilla.opensuse.org/show_bug.cgi?id=954746 In this installation of Tumbleweed running Kernel 4.3: 4.3.0-1-default #1 SMP PREEMPT Mon Nov 2 15:35:09 UTC 2015 (7b374a4) x86_64 x86_64 x86_64 GNU/Linux I get system freezes (generally necessitating hard reset) and impossibility to run more than one user session at a time. The attachments of journal and dmesg show the error message received. I allow myself to cc the developer of opensuse Takashi Iwai tiwai at suse.com. This system worked well with 3.x kernels and up to 4.2 With the current kernel I get the lockups. Board is an old Ashrock 939DualVsta and Graphics is Nvidia GT216 based on primary PCI-e slot of the mainboard. -- 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/20151115/d196b136/attachment.html>
[Bug 92962] KDE hangs and system freezes while journalctl lists complains of kernel (nouveau). Nvidia graphics
https://bugs.freedesktop.org/show_bug.cgi?id=92962 --- Comment #1 from stakanov at freenet.de --- Created attachment 119681 --> https://bugs.freedesktop.org/attachment.cgi?id=119681&action=edit exerpt of systemdjournal complaining about nouveau -- 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/20151115/ef9683b5/attachment-0001.html>
[Bug 92962] KDE hangs and system freezes while journalctl lists complains of kernel (nouveau). Nvidia graphics
https://bugs.freedesktop.org/show_bug.cgi?id=92962 Pierre Moreau changed: What|Removed |Added Component|DRM/other |Driver/nouveau Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Product|DRI |xorg QA Contact||xorg-team at lists.x.org -- 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/20151115/cd935f2e/attachment.html>
[PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms!
When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as possible. However, if it is a slow
request, we want to sleep as quickly as possible. The tradeoff between
waiting and sleeping is roughly the time it takes to sleep on a request,
on the order of a microsecond. Based on measurements from big core, I
have set the limit for busywaiting as 2 microseconds.
The code currently uses the jiffie clock, but that is far too coarse (on
the order of 10 milliseconds) and results in poor interactivity as the
CPU ends up being hogged by slow requests. To get microsecond resolution
we need to use a high resolution timer. The cheapest of which is polling
local_clock(), but that is only valid on the same CPU. If we switch CPUs
because the task was preempted, we can also use that as an indicator that
the system is too busy to waste cycles on spinning and we should sleep
instead.
__i915_spin_request was introduced in
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
Reported-by: Jens Axboe
Link: https://lkml.org/lkml/2015/11/12/621
Cc: Jens Axboe
Cc; "Rogozhkin, Dmitry V"
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
Cc: Eero Tamminen
Cc: "Rantala, Valtteri"
Cc: stable at kernel.vger.org
---
drivers/gpu/drm/i915/i915_gem.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 740530c571d1..2a88158bd1f7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1146,14 +1146,36 @@ static bool missed_irq(struct drm_i915_private
*dev_priv,
return test_bit(ring->id, &dev_priv->gpu_error.missed_irq_rings);
}
+static u64 local_clock_us(unsigned *cpu)
+{
+ u64 t;
+
+ *cpu = get_cpu();
+ t = local_clock() >> 10;
+ put_cpu();
+
+ return t;
+}
+
+static bool busywait_stop(u64 timeout, unsigned cpu)
+{
+ unsigned this_cpu;
+
+ if (time_after64(local_clock_us(&this_cpu), timeout))
+ return true;
+
+ return this_cpu != cpu;
+}
+
static int __i915_spin_request(struct drm_i915_gem_request *req, int state)
{
- unsigned long timeout;
+ u64 timeout;
+ unsigned cpu;
if (i915_gem_request_get_ring(req)->irq_refcount)
return -EBUSY;
- timeout = jiffies + 1;
+ timeout = local_clock_us(&cpu) + 2;
while (!need_resched()) {
if (i915_gem_request_completed(req, true))
return 0;
@@ -1161,7 +1183,7 @@ static int __i915_spin_request(struct
drm_i915_gem_request *req, int state)
if (signal_pending_state(state, current))
break;
- if (time_after_eq(jiffies, timeout))
+ if (busywait_stop(timeout, cpu))
break;
cpu_relax_lowlatency();
--
2.6.2
[PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals
The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.
Fixes regression from
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
Signed-off-by: Chris Wilson
Cc: Jens Axboe
Cc; "Rogozhkin, Dmitry V"
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
Cc: Eero Tamminen
Cc: "Rantala, Valtteri"
Cc: stable at kernel.vger.org
---
drivers/gpu/drm/i915/i915_gem.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5cf4a1998273..740530c571d1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1146,7 +1146,7 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
return test_bit(ring->id, &dev_priv->gpu_error.missed_irq_rings);
}
-static int __i915_spin_request(struct drm_i915_gem_request *req)
+static int __i915_spin_request(struct drm_i915_gem_request *req, int state)
{
unsigned long timeout;
@@ -1158,6 +1158,9 @@ static int __i915_spin_request(struct
drm_i915_gem_request *req)
if (i915_gem_request_completed(req, true))
return 0;
+ if (signal_pending_state(state, current))
+ break;
+
if (time_after_eq(jiffies, timeout))
break;
@@ -1197,6 +1200,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
struct drm_i915_private *dev_priv = dev->dev_private;
const bool irq_test_in_progress =
ACCESS_ONCE(dev_priv->gpu_error.test_irq_rings) &
intel_ring_flag(ring);
+ int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
DEFINE_WAIT(wait);
unsigned long timeout_expire;
s64 before, now;
@@ -1221,7 +1225,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
before = ktime_get_raw_ns();
/* Optimistic spin for the next jiffie before touching IRQs */
- ret = __i915_spin_request(req);
+ ret = __i915_spin_request(req, state);
if (ret == 0)
goto out;
@@ -1233,8 +1237,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
for (;;) {
struct timer_list timer;
- prepare_to_wait(&ring->irq_queue, &wait,
- interruptible ? TASK_INTERRUPTIBLE :
TASK_UNINTERRUPTIBLE);
+ prepare_to_wait(&ring->irq_queue, &wait, state);
/* We need to check whether any gpu reset happened in between
* the caller grabbing the seqno and now ... */
@@ -1252,7 +1255,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
break;
}
- if (interruptible && signal_pending(current)) {
+ if (signal_pending_state(state, current)) {
ret = -ERESTARTSYS;
break;
}
--
2.6.2
[Bug 92936] Tonga powerplay isssues
https://bugs.freedesktop.org/show_bug.cgi?id=92936 --- Comment #3 from Andy Furniss --- I found today by luck that this issue does not exist if there are 2 displays alive when I boot. The second display being an HDMI TV, which as it's not me using it I --off with xrandr after startx - but I can't then get UVD usage to break powerplay in this senario. -- 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/20151115/dfbe8916/attachment.html>
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #47 from Andy Furniss --- Seems like you are using an old kernel - though what I call old may be current for what's released. The hanging for me stopped with 4.4, but 4.3 is release. If you are using 4.3 maybe booting with the option - amdgpu.enable_scheduler=1 will help. If you are used to compiling your own kernels then using one from - http://cgit.freedesktop.org/~agd5f/linux/ like drm-next-4.4 should be stable. Or if you want to test/use the new powerplay try amdgpu-powerplay -- 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/20151115/584df35c/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 --- Comment #1 from Bogar Boris --- I got the same trouble on arch with mesa-git and llvm-svn. Working fine with the stable release. -- 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/20151115/08bf9833/attachment.html>
[PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms!
On Sun, Nov 15, 2015 at 01:32:44PM +, Chris Wilson wrote:
> +static bool busywait_stop(u64 timeout, unsigned cpu)
> +{
> + unsigned this_cpu;
> +
> + if (time_after64(local_clock_us(&this_cpu), timeout))
> + return true;
Just a note to say that we can use the unsigned long version rather than
pass around u64 as this test will wraparound correctly (if we discard
the high bits on x86-32).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 92953] Segfault loading UT4 map/server
https://bugs.freedesktop.org/show_bug.cgi?id=92953 --- Comment #3 from bellamorte42 at gmail.com --- Probably relevant, the War Thunder launcher no longer loads. -- 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/20151115/7df30baf/attachment.html>
[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.
https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #14 from Alex Deucher --- (In reply to Aneroid from comment #13) > Ok. > > But this strange error: "radeon :01:00.0: VCE init error (-22)." > What does it mean ? The video encoding engine failed to initialize. This is a known issue on certain SI parts, but is harmless unless you need to use the encoding engine. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/vmwgfx: constify fence_ops structure
The fence_ops structures are never modified, so declare this one as const,
as is already done for the others.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 8e689b4..4d09da1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -226,7 +226,7 @@ out:
return ret;
}
-static struct fence_ops vmw_fence_ops = {
+static const struct fence_ops vmw_fence_ops = {
.get_driver_name = vmw_fence_get_driver_name,
.get_timeline_name = vmw_fence_get_timeline_name,
.enable_signaling = vmw_fence_enable_signaling,
