lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/689ab584/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/8892ab2c/attachment.html>
|RESOLVED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/a9297ec0/attachment.html>
. Maybe X11 frames are not captured efficiently. Thank you again for help
with resolving it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/c766a93a/attachment.html>
If I hibernate from the console, thaw, and switch between the console
and X, the gpu hangs itself. The machine becomes unresponsive except
for the power button.
The syslog says:
21:12:16 kernel: [drm] GPU HANG: ecode 8:0:0x0f71, in Xorg [2047],
reason: Hang on render ring, action: res
On 7 October 2016 at 09:12, Alexandre Courbot wrote:
> On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel
> wrote:
>> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that
>> both GF 100 and NV50 are affected by the same issue, and that a related issue
>> has been solved alrea
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/2f11d4e2/attachment-0001.html>
This is a prep step to eventually split out the drm-misc branches all
into their own repo. To get there we first need to split out the
integration tree mangling.
Since dim doesn't auto-update and since the transition is a good
reason to switch over to worktrees and it's tricky it's not scripted.
T
With the remotes stored in nightly.conf and git worktrees we can avoid
hard-coding them in even more places.
Signed-off-by: Daniel Vetter
---
dim | 12
1 file changed, 12 deletions(-)
diff --git a/dim b/dim
index 7e3708599943..92841b046c2c 100755
--- a/dim
+++ b/dim
@@ -80,8 +80,6
Needs new url-mapping information in nightly.conf to work properly.
Signed-off-by: Daniel Vetter
---
dim | 48
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/dim b/dim
index 3bd5416327a8..7e3708599943 100755
--- a/dim
+++ b/dim
@@
With our proliferation of branches it's become long useless. Nowadays
my MO is to revert the offending commit in the rerere-cache branch
explicitly, remove drm-intel-nightly/.git/rr-cache and then re-run
rebuild-nightly. That works much better, hence nuke this helper.
Signed-off-by: Daniel Vetter
If available by default. This saves quite a pile of disk-space that
imo making it the default is justified.
Note that this will break the rebuild-nightly script for now,
follow-up patches will fix that.
Signed-off-by: Daniel Vetter
---
dim | 23 ---
1 file changed, 16 insert
The goals here are multiple:
- simpler configuration through autodetection
- allows seamless upgrading to git worktree for the aux checkouts
- eventually I want to split up drm-misc into a separate remote ...
And yes this is just a start.
Signed-off-by: Daniel Vetter
---
dim | 112 +
Exits script to annoy people roughly every 100th time ...
Also switch to the magic @{upstream} reference, in case the remote is
not called origin (which is pretty normal in case of using git
worktree).
Signed-off-by: Daniel Vetter
---
dim | 6 +-
1 file changed, 5 insertions(+), 1 deletion(
Just maybe a bit more visibility, the scripts are growing.
Signed-off-by: Daniel Vetter
---
TODO | 27 +++
dim | 17 -
qf | 11 ---
3 files changed, 27 insertions(+), 28 deletions(-)
create mode 100644 TODO
diff --git a/TODO b/TODO
new file mo
Hi all,
This is the first step to split out the drm-misc trees into their own git repo.
This just moves the integration trees into drm-nightly.git. Those are separate
since I really like the idea of sharing one integration tree related to gfx.
Next up is teaching all the branch related dim comman
On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer wrote:
>
> [ Adding Dan Williams and dri-devel ]
>
> On 14/10/16 03:28 AM, Shawn Starr wrote:
>> Hello AMD folks,
>>
>> I have discovered a problem in Linus master that affects AMDGPU, nobody would
>> notice this in drm-next-4.9-wip since its not in
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/63201eee/attachment.html>
On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote:
> On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson
> wrote:
> > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
> >> This is the alternative approach for solving a deadlock situation with
> >> array-fences.
> >>
> >> Currently wit
op.org/archives/dri-devel/attachments/20161016/c9ba9950/attachment.html>
Pushed patches 1-4 in this series (with some very small style changes
to make checkpatch happy), drm-intel-nightly also rebuilt.
On Fri, 2016-10-14 at 17:31 -0400, Lyude wrote:
> While it (mostly) works, the code for handling watermarks on Skylake
> has been
> kind of ugly for a while. As well a l
l gstreamer to convert to
NV12 in the first place.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/f2fe2afa/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/4dd249bf/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/358dd5ec/attachment-0001.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/289a10b1/attachment.html>
hives/dri-devel/attachments/20161016/4a41a048/attachment.html>
On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
> This is the alternative approach for solving a deadlock situation with
> array-fences.
>
> Currently with fence-array, we have a potential deadlock situation. If we
> fence_add_callback() on an array-fence, the array-fence's lock is aqu
ertically doubled image too, with correct colors though.
Tested, it produces similar corrupted video.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/ec79b142/attachment-0001.html>
On Sun, Oct 16, 2016 at 12:03:53PM -0400, Rob Clark wrote:
> Currently with fence-array, we have a potential deadlock situation. If we
> fence_add_callback() on an array-fence, the array-fence's lock is aquired
> first, and in it's ->enable_signaling() callback, it will install cb's on
> it's arra
f check or do you consider this fixed?
I'll add a check. Thanks for confirming.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/atta
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/dda446b3/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161016/b5e1133f/attachment.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/7650c81e/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/c6e49937/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/cad2600f/attachment.html>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/ab459cbf/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/2d32f720/attachment.html>
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/bddcd856/attachment-0001.html>
On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson
wrote:
> On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
>> This is the alternative approach for solving a deadlock situation with
>> array-fences.
>>
>> Currently with fence-array, we have a potential deadlock situation. If we
>> fence_ad
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/f252da11/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/f482a326/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/5183e836/attachment.html>
On Sun, Oct 16, 2016 at 1:38 PM, Chris Wilson
wrote:
> On Sun, Oct 16, 2016 at 12:03:53PM -0400, Rob Clark wrote:
>> Currently with fence-array, we have a potential deadlock situation. If we
>> fence_add_callback() on an array-fence, the array-fence's lock is aquired
>> first, and in it's ->enab
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/9833543c/attachment.html>
esn't meant that the same
approach would be feasible for the Open Source one of course.
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/3bc584a9/attachment.html>
This is the alternative approach for solving a deadlock situation with
array-fences.
Currently with fence-array, we have a potential deadlock situation. If we
fence_add_callback() on an array-fence, the array-fence's lock is aquired
first, and in it's ->enable_signaling() callback, it will instal
Currently with fence-array, we have a potential deadlock situation. If we
fence_add_callback() on an array-fence, the array-fence's lock is aquired
first, and in it's ->enable_signaling() callback, it will install cb's on
it's array-member fences, so the array-member's lock is acquired second.
Bu
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/37c427e4/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=153911
--- Comment #3 from Pierre Moreau ---
Oh, an Optimus latopt I guess, where the Intel GPU is the main one?
Having a look at the source code, it appears that all the
`NV_(FATAL|ERROR|WARN|INFO|DEBUG)` macros do not take into account the Nouveau
lo
On Thu, Oct 13, 2016 at 4:17 PM, Chris Wilson
wrote:
> On Thu, Oct 13, 2016 at 04:04:05PM -0400, Rob Clark wrote:
>> We were holding the wrong lock to be using fence_is_signaled_locked().
>> And holding the child_list_lock over something that could end up calling
>> fence cb's angers lockdep:
>>
This change will also make Coverity happy by avoiding a theoretical NULL
pointer dereference; yet another reason is to use the above helper function
to tighten the code and make it more readable.
Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
---
Found this in one of my old branches.
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/8849decb/attachment.html>
rrizo.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161016/caa273ab/attachment.html>
Hello:
I meet a problem with eDP in rk3288 with the linux next 20161006, it
is just like the early stage of 4.4
kernel. I have added a eDP panel entry in the firefly reload board,
once the kernel loaded analogix_dp-rockchip.ko, after printed the
following two lines, the kernel stop working.
54 matches
Mail list logo
