* Re: [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu [not found] ` <CALqGcGobS4WFpMaiZm0PQ1z8cV-aakMs9cbAuO+u3vfmvJWpdA@mail.gmail.com> @ 2015-12-22 15:37 ` Sebastian Andrzej Siewior 2015-12-23 12:40 ` Christoph Mathys 2016-01-05 14:41 ` Daniel Vetter 0 siblings, 2 replies; 4+ messages in thread From: Sebastian Andrzej Siewior @ 2015-12-22 15:37 UTC (permalink / raw) To: Christoph Mathys; +Cc: Linux RT Users, Daniel Vetter, Jani Nikula, intel-gfx * Christoph Mathys | 2015-12-21 14:19:10 [+0100]: >While playing with 4.1.13-rt15 I stumbled across the following thread >where Luis reports the same problem with i915 gpu: >i915: sleeping function called from invalid context at >intel_pipe_update_start/end >http://www.spinics.net/lists/linux-rt-users/msg13543.html > >Sebastian suggested to set i915.use_mmio_flip to -1. I tried this, and >this avoids the callstack that I've posted before >(intel_mmio_flip_work). The BUG below is now the dominant one: perfect. |BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 |in_atomic(): 0, irqs_disabled(): 1, pid: 2109, name: Xorg |hardirqs last disabled at (23744596): [<ffffffffa02bca93>] intel_pipe_update_start+0x113/0x640 [i915] |Call Trace: | [<ffffffff81802c33>] dump_stack+0x4a/0x61 | [<ffffffff8108713a>] ___might_sleep+0x13a/0x200 | [<ffffffff8180a5e4>] rt_spin_lock+0x24/0x60 | [<ffffffff8108b47c>] ? migrate_disable+0x6c/0xe0 | [<ffffffff810a95fb>] prepare_to_wait+0x2b/0xa0 | [<ffffffffa02bcb48>] intel_pipe_update_start+0x1c8/0x640 [i915] | [<ffffffff810a9ac0>] ? prepare_to_wait_event+0x130/0x130 | [<ffffffffa02a7fc6>] intel_begin_crtc_commit+0x166/0x1e0 [i915] | [<ffffffffa02146f2>] drm_plane_helper_commit+0x112/0x2c0 [drm_kms_helper] | [<ffffffffa021493a>] drm_plane_helper_update+0x9a/0xf0 I have to admit, the i915 tries very hard to avoid running on -RT. Could you try the s/local_irq_disable();/local_irq_disable_nort();/ patch mentioned in the thread? Anyone of the i915 hackers an idea how could get the i915 working without disabling interrupts? Is really required? Sebastian ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu 2015-12-22 15:37 ` [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu Sebastian Andrzej Siewior @ 2015-12-23 12:40 ` Christoph Mathys 2016-01-05 14:38 ` [Intel-gfx] " Daniel Vetter 2016-01-05 14:41 ` Daniel Vetter 1 sibling, 1 reply; 4+ messages in thread From: Christoph Mathys @ 2015-12-23 12:40 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Linux RT Users, Daniel Vetter, Jani Nikula, intel-gfx On Tue, Dec 22, 2015 at 4:37 PM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > I have to admit, the i915 tries very hard to avoid running on -RT. Could > you try the s/local_irq_disable();/local_irq_disable_nort();/ patch > mentioned in the thread? It did not crash so far, I did some usual work and executed glmark2 several times. The BUG has not surfaced again. BUT, the latency is still far from ideal, it takes only seconds for the maximum latency to spike into the range of milliseconds. By the way, this is now 4.1.15-rt17 with the changes from here: http://www.spinics.net/lists/linux-rt-users/msg13543.html During some tests with cyclictests --breaktrace I've seen more BUG messages, but they might relate to the kernel tracing. Unfortunately, I could not make much of the --breaktrace. [ 4629.753864] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 [ 4629.753865] in_atomic(): 1, irqs_disabled(): 0, pid: 1913, name: Xorg [ 4629.753866] 2 locks held by Xorg/1913: [ 4629.753879] #0: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa0211a6c>] drm_modeset_lock_crtc+0x4c/0x100 [drm] [ 4629.753887] #1: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa0211871>] drm_modeset_lock+0x41/0x130 [drm] [ 4629.753888] CPU: 4 PID: 1913 Comm: Xorg Tainted: G E 4.1.15-i915-patch-realtime-1-rt17+ #4 [ 4629.753889] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75, BIOS DD3-1-1D 08/21/2013 [ 4629.753891] ffffffff81c862ce ffff8803e92538b8 ffffffff81805313 0000000000005b10 [ 4629.753892] ffff8803e8baa660 ffff8803e92538e8 ffffffff8108813a ffff8803e92538d8 [ 4629.753893] ffff8803fe6d0070 ffff8803fe6d0070 ffff8803fe6d0068 ffff8803e9253918 [ 4629.753893] Call Trace: [ 4629.753897] [<ffffffff81805313>] dump_stack+0x4a/0x61 [ 4629.753899] [<ffffffff8108813a>] ___might_sleep+0x13a/0x200 [ 4629.753901] [<ffffffff8180ccc4>] rt_spin_lock+0x24/0x60 [ 4629.753916] [<ffffffffa02f61d6>] gen6_read32+0x46/0x380 [i915] [ 4629.753925] [<ffffffffa02d4b42>] gm45_get_vblank_counter+0x32/0x40 [i915] [ 4629.753934] [<ffffffffa02e11b5>] ftrace_raw_event_i915_pipe_update_start+0x65/0xb0 [i915] [ 4629.753944] [<ffffffffa0324c23>] intel_pipe_update_start+0x2a3/0x640 [i915] [ 4629.753946] [<ffffffff810aaac0>] ? prepare_to_wait_event+0x130/0x130 [ 4629.753956] [<ffffffffa030ffc6>] intel_begin_crtc_commit+0x166/0x1e0 [i915] [ 4629.753961] [<ffffffffa026e6f2>] drm_plane_helper_commit+0x112/0x2c0 [drm_kms_helper] [ 4629.753963] [<ffffffffa026e93a>] drm_plane_helper_update+0x9a/0xf0 [drm_kms_helper] [ 4629.753970] [<ffffffffa0201bc8>] __setplane_internal+0x248/0x350 [drm] [ 4629.753975] [<ffffffffa0201df5>] drm_mode_cursor_universal+0x125/0x210 [drm] [ 4629.753981] [<ffffffffa0201f5f>] drm_mode_cursor_common+0x7f/0x1b0 [drm] [ 4629.753987] [<ffffffffa0206411>] drm_mode_cursor_ioctl+0x41/0x50 [drm] [ 4629.753992] [<ffffffffa01f60a9>] drm_ioctl+0x349/0x690 [drm] [ 4629.753998] [<ffffffffa02063d0>] ? drm_mode_setcrtc+0x630/0x630 [drm] [ 4629.753999] [<ffffffff81096585>] ? local_clock+0x25/0x30 [ 4629.754001] [<ffffffff810b3443>] ? lock_release_holdtime.part.31+0xd3/0x1a0 [ 4629.754002] [<ffffffff81204088>] do_vfs_ioctl+0x328/0x5e0 [ 4629.754004] [<ffffffff812102a5>] ? __fget+0x5/0x210 [ 4629.754004] [<ffffffff8121051a>] ? __fget_light+0x2a/0xa0 [ 4629.754005] [<ffffffff812043c1>] SyS_ioctl+0x81/0xa0 [ 4629.754007] [<ffffffff8180d804>] tracesys_phase2+0x88/0x8d [ 361.526236] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 [ 361.526237] in_atomic(): 1, irqs_disabled(): 0, pid: 667, name: irq/51-i915 [ 361.526237] no locks held by irq/51-i915/667. [ 361.526239] CPU: 4 PID: 667 Comm: irq/51-i915 Tainted: G E 4.1.15-i915-patch-realtime-1-rt17+ #4 [ 361.526240] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75, BIOS DD3-1-1D 08/21/2013 [ 361.526242] ffffffff81c862ce ffff8803fe6e7b58 ffffffff81805313 0000000000000000 [ 361.526243] ffff8803ff3d4cc0 ffff8803fe6e7b88 ffffffff8108813a 0000000000000296 [ 361.526244] ffff8803fe6d0070 ffff8803fe6d0070 ffff8803fe6d0068 ffff8803fe6e7bb8 [ 361.526244] Call Trace: [ 361.526249] [<ffffffff81805313>] dump_stack+0x4a/0x61 [ 361.526251] [<ffffffff8108813a>] ___might_sleep+0x13a/0x200 [ 361.526253] [<ffffffff8180ccc4>] rt_spin_lock+0x24/0x60 [ 361.526281] [<ffffffffa02f61d6>] gen6_read32+0x46/0x380 [i915] [ 361.526283] [<ffffffff81142270>] ? trace_event_buffer_lock_reserve+0x40/0x80 [ 361.526293] [<ffffffffa02e782f>] gen6_ring_get_seqno+0x2f/0x40 [i915] [ 361.526301] [<ffffffffa02e0eef>] ftrace_raw_event_i915_gem_request_notify+0x5f/0x90 [i915] [ 361.526309] [<ffffffffa02d843d>] notify_ring.isra.12+0xcd/0x240 [i915] [ 361.526316] [<ffffffffa02d8a0c>] snb_gt_irq_handler+0x12c/0x180 [i915] [ 361.526323] [<ffffffffa02dab97>] ironlake_irq_handler+0x1c7/0xfe0 [i915] [ 361.526324] [<ffffffff81087f0d>] ? finish_task_switch+0x4d/0x140 [ 361.526325] [<ffffffff810cf7e7>] irq_forced_thread_fn+0x27/0x70 [ 361.526326] [<ffffffff810cfd99>] irq_thread+0x149/0x1f0 [ 361.526327] [<ffffffff810cf7c0>] ? irq_thread_fn+0x40/0x40 [ 361.526328] [<ffffffff810cf860>] ? wake_threads_waitq+0x30/0x30 [ 361.526329] [<ffffffff810cfc50>] ? irq_thread_check_affinity+0x70/0x70 [ 361.526330] [<ffffffff81081854>] kthread+0xe4/0x100 [ 361.526332] [<ffffffff810b649d>] ? trace_hardirqs_on+0xd/0x10 [ 361.526333] [<ffffffff81081770>] ? kthread_create_on_node+0x240/0x240 [ 361.526334] [<ffffffff8180db22>] ret_from_fork+0x42/0x70 [ 361.526335] [<ffffffff81081770>] ? kthread_create_on_node+0x240/0x240 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel-gfx] [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu 2015-12-23 12:40 ` Christoph Mathys @ 2016-01-05 14:38 ` Daniel Vetter 0 siblings, 0 replies; 4+ messages in thread From: Daniel Vetter @ 2016-01-05 14:38 UTC (permalink / raw) To: Christoph Mathys Cc: Sebastian Andrzej Siewior, Daniel Vetter, intel-gfx, Linux RT Users On Wed, Dec 23, 2015 at 01:40:06PM +0100, Christoph Mathys wrote: > On Tue, Dec 22, 2015 at 4:37 PM, Sebastian Andrzej Siewior > <bigeasy@linutronix.de> wrote: > > I have to admit, the i915 tries very hard to avoid running on -RT. Could > > you try the s/local_irq_disable();/local_irq_disable_nort();/ patch > > mentioned in the thread? > > It did not crash so far, I did some usual work and executed glmark2 > several times. The BUG has not surfaced again. BUT, the latency is > still far from ideal, it takes only seconds for the maximum latency to > spike into the range of milliseconds. By the way, this is now > 4.1.15-rt17 with the changes from here: > http://www.spinics.net/lists/linux-rt-users/msg13543.html > > During some tests with cyclictests --breaktrace I've seen more BUG > messages, but they might relate to the kernel tracing. Unfortunately, > I could not make much of the --breaktrace. Waking the GT takes a while, and for a bunch of reasons we need to be able to do this from irq context, hence spin_lock_irq. Doesn't RT convert that to a mutex? Otherwise not sure what would prevent interrupts in your backtrace ... -Daniel > > [ 4629.753864] BUG: sleeping function called from invalid context at > kernel/locking/rtmutex.c:917 > [ 4629.753865] in_atomic(): 1, irqs_disabled(): 0, pid: 1913, name: Xorg > [ 4629.753866] 2 locks held by Xorg/1913: > [ 4629.753879] #0: (crtc_ww_class_acquire){+.+.+.}, at: > [<ffffffffa0211a6c>] drm_modeset_lock_crtc+0x4c/0x100 [drm] > [ 4629.753887] #1: (crtc_ww_class_mutex){+.+.+.}, at: > [<ffffffffa0211871>] drm_modeset_lock+0x41/0x130 [drm] > [ 4629.753888] CPU: 4 PID: 1913 Comm: Xorg Tainted: G E > 4.1.15-i915-patch-realtime-1-rt17+ #4 > [ 4629.753889] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75, > BIOS DD3-1-1D 08/21/2013 > [ 4629.753891] ffffffff81c862ce ffff8803e92538b8 ffffffff81805313 > 0000000000005b10 > [ 4629.753892] ffff8803e8baa660 ffff8803e92538e8 ffffffff8108813a > ffff8803e92538d8 > [ 4629.753893] ffff8803fe6d0070 ffff8803fe6d0070 ffff8803fe6d0068 > ffff8803e9253918 > [ 4629.753893] Call Trace: > [ 4629.753897] [<ffffffff81805313>] dump_stack+0x4a/0x61 > [ 4629.753899] [<ffffffff8108813a>] ___might_sleep+0x13a/0x200 > [ 4629.753901] [<ffffffff8180ccc4>] rt_spin_lock+0x24/0x60 > [ 4629.753916] [<ffffffffa02f61d6>] gen6_read32+0x46/0x380 [i915] > [ 4629.753925] [<ffffffffa02d4b42>] gm45_get_vblank_counter+0x32/0x40 [i915] > [ 4629.753934] [<ffffffffa02e11b5>] > ftrace_raw_event_i915_pipe_update_start+0x65/0xb0 [i915] > [ 4629.753944] [<ffffffffa0324c23>] intel_pipe_update_start+0x2a3/0x640 [i915] > [ 4629.753946] [<ffffffff810aaac0>] ? prepare_to_wait_event+0x130/0x130 > [ 4629.753956] [<ffffffffa030ffc6>] intel_begin_crtc_commit+0x166/0x1e0 [i915] > [ 4629.753961] [<ffffffffa026e6f2>] > drm_plane_helper_commit+0x112/0x2c0 [drm_kms_helper] > [ 4629.753963] [<ffffffffa026e93a>] drm_plane_helper_update+0x9a/0xf0 > [drm_kms_helper] > [ 4629.753970] [<ffffffffa0201bc8>] __setplane_internal+0x248/0x350 [drm] > [ 4629.753975] [<ffffffffa0201df5>] drm_mode_cursor_universal+0x125/0x210 [drm] > [ 4629.753981] [<ffffffffa0201f5f>] drm_mode_cursor_common+0x7f/0x1b0 [drm] > [ 4629.753987] [<ffffffffa0206411>] drm_mode_cursor_ioctl+0x41/0x50 [drm] > [ 4629.753992] [<ffffffffa01f60a9>] drm_ioctl+0x349/0x690 [drm] > [ 4629.753998] [<ffffffffa02063d0>] ? drm_mode_setcrtc+0x630/0x630 [drm] > [ 4629.753999] [<ffffffff81096585>] ? local_clock+0x25/0x30 > [ 4629.754001] [<ffffffff810b3443>] ? lock_release_holdtime.part.31+0xd3/0x1a0 > [ 4629.754002] [<ffffffff81204088>] do_vfs_ioctl+0x328/0x5e0 > [ 4629.754004] [<ffffffff812102a5>] ? __fget+0x5/0x210 > [ 4629.754004] [<ffffffff8121051a>] ? __fget_light+0x2a/0xa0 > [ 4629.754005] [<ffffffff812043c1>] SyS_ioctl+0x81/0xa0 > [ 4629.754007] [<ffffffff8180d804>] tracesys_phase2+0x88/0x8d > > [ 361.526236] BUG: sleeping function called from invalid context at > kernel/locking/rtmutex.c:917 > [ 361.526237] in_atomic(): 1, irqs_disabled(): 0, pid: 667, name: irq/51-i915 > [ 361.526237] no locks held by irq/51-i915/667. > [ 361.526239] CPU: 4 PID: 667 Comm: irq/51-i915 Tainted: G > E 4.1.15-i915-patch-realtime-1-rt17+ #4 > [ 361.526240] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75, > BIOS DD3-1-1D 08/21/2013 > [ 361.526242] ffffffff81c862ce ffff8803fe6e7b58 ffffffff81805313 > 0000000000000000 > [ 361.526243] ffff8803ff3d4cc0 ffff8803fe6e7b88 ffffffff8108813a > 0000000000000296 > [ 361.526244] ffff8803fe6d0070 ffff8803fe6d0070 ffff8803fe6d0068 > ffff8803fe6e7bb8 > [ 361.526244] Call Trace: > [ 361.526249] [<ffffffff81805313>] dump_stack+0x4a/0x61 > [ 361.526251] [<ffffffff8108813a>] ___might_sleep+0x13a/0x200 > [ 361.526253] [<ffffffff8180ccc4>] rt_spin_lock+0x24/0x60 > [ 361.526281] [<ffffffffa02f61d6>] gen6_read32+0x46/0x380 [i915] > [ 361.526283] [<ffffffff81142270>] ? trace_event_buffer_lock_reserve+0x40/0x80 > [ 361.526293] [<ffffffffa02e782f>] gen6_ring_get_seqno+0x2f/0x40 [i915] > [ 361.526301] [<ffffffffa02e0eef>] > ftrace_raw_event_i915_gem_request_notify+0x5f/0x90 [i915] > [ 361.526309] [<ffffffffa02d843d>] notify_ring.isra.12+0xcd/0x240 [i915] > [ 361.526316] [<ffffffffa02d8a0c>] snb_gt_irq_handler+0x12c/0x180 [i915] > [ 361.526323] [<ffffffffa02dab97>] ironlake_irq_handler+0x1c7/0xfe0 [i915] > [ 361.526324] [<ffffffff81087f0d>] ? finish_task_switch+0x4d/0x140 > [ 361.526325] [<ffffffff810cf7e7>] irq_forced_thread_fn+0x27/0x70 > [ 361.526326] [<ffffffff810cfd99>] irq_thread+0x149/0x1f0 > [ 361.526327] [<ffffffff810cf7c0>] ? irq_thread_fn+0x40/0x40 > [ 361.526328] [<ffffffff810cf860>] ? wake_threads_waitq+0x30/0x30 > [ 361.526329] [<ffffffff810cfc50>] ? irq_thread_check_affinity+0x70/0x70 > [ 361.526330] [<ffffffff81081854>] kthread+0xe4/0x100 > [ 361.526332] [<ffffffff810b649d>] ? trace_hardirqs_on+0xd/0x10 > [ 361.526333] [<ffffffff81081770>] ? kthread_create_on_node+0x240/0x240 > [ 361.526334] [<ffffffff8180db22>] ret_from_fork+0x42/0x70 > [ 361.526335] [<ffffffff81081770>] ? kthread_create_on_node+0x240/0x240 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel-gfx] [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu 2015-12-22 15:37 ` [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu Sebastian Andrzej Siewior 2015-12-23 12:40 ` Christoph Mathys @ 2016-01-05 14:41 ` Daniel Vetter 1 sibling, 0 replies; 4+ messages in thread From: Daniel Vetter @ 2016-01-05 14:41 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Christoph Mathys, Daniel Vetter, intel-gfx, Linux RT Users On Tue, Dec 22, 2015 at 04:37:26PM +0100, Sebastian Andrzej Siewior wrote: > * Christoph Mathys | 2015-12-21 14:19:10 [+0100]: > > >While playing with 4.1.13-rt15 I stumbled across the following thread > >where Luis reports the same problem with i915 gpu: > >i915: sleeping function called from invalid context at > >intel_pipe_update_start/end > >http://www.spinics.net/lists/linux-rt-users/msg13543.html > > > >Sebastian suggested to set i915.use_mmio_flip to -1. I tried this, and > >this avoids the callstack that I've posted before > >(intel_mmio_flip_work). The BUG below is now the dominant one: > perfect. > > |BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 > |in_atomic(): 0, irqs_disabled(): 1, pid: 2109, name: Xorg > |hardirqs last disabled at (23744596): [<ffffffffa02bca93>] intel_pipe_update_start+0x113/0x640 [i915] > |Call Trace: > | [<ffffffff81802c33>] dump_stack+0x4a/0x61 > | [<ffffffff8108713a>] ___might_sleep+0x13a/0x200 > | [<ffffffff8180a5e4>] rt_spin_lock+0x24/0x60 > | [<ffffffff8108b47c>] ? migrate_disable+0x6c/0xe0 > | [<ffffffff810a95fb>] prepare_to_wait+0x2b/0xa0 > | [<ffffffffa02bcb48>] intel_pipe_update_start+0x1c8/0x640 [i915] > | [<ffffffff810a9ac0>] ? prepare_to_wait_event+0x130/0x130 > | [<ffffffffa02a7fc6>] intel_begin_crtc_commit+0x166/0x1e0 [i915] > | [<ffffffffa02146f2>] drm_plane_helper_commit+0x112/0x2c0 [drm_kms_helper] > | [<ffffffffa021493a>] drm_plane_helper_update+0x9a/0xf0 > > I have to admit, the i915 tries very hard to avoid running on -RT. Could > you try the s/local_irq_disable();/local_irq_disable_nort();/ patch > mentioned in the thread? > > Anyone of the i915 hackers an idea how could get the i915 working > without disabling interrupts? Is really required? It's a correctness problem - if we don't disable everything we might miss the timeframe and your screen will tear. Hence why we essentially need to run this little section of code with hard-rt semantics. There's other display chips with proper design which don't need hacks like this one here. Now of course you might want to accept a broken screen in exchange for non-broken hard rt for the things you really care about, but I'm not sure how to encode this. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-01-05 14:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CALqGcGpLJ+x_Gg7i4W4UCe4+GJEfdFNo-UryyOyQZJ1q5AAWJQ@mail.gmail.com>
[not found] ` <CALqGcGo_CBrQynU1TeymxQJbL_LJgN9d5ADho_jM-DRB6c312w@mail.gmail.com>
[not found] ` <CALqGcGobS4WFpMaiZm0PQ1z8cV-aakMs9cbAuO+u3vfmvJWpdA@mail.gmail.com>
2015-12-22 15:37 ` [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu Sebastian Andrzej Siewior
2015-12-23 12:40 ` Christoph Mathys
2016-01-05 14:38 ` [Intel-gfx] " Daniel Vetter
2016-01-05 14:41 ` Daniel Vetter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox