[Intel-gfx] [intel-gfx] How to determine supported HDMI versions of an Intel GPU

[Sedat Dilek]

[ Please CC me I am not subscribed to any CCed mailing-lists ]

Hi Daniel,

I hope you are well.

While searching for a new monitor I wanted to buy a miniHDMI->HDMI
adapter or cable to connect it.

My Samsung laptop has a Intel HD graphics 3000 GPU and a miniHDMI connector.

Unfortunately, I have no idea how to get information about supported
HDMI versions and or supported resolutions when there is *no* external
monitor connected.

root# xrandr --listmonitors
Monitors: 1
0: +XWAYLAND0 1366/293x768/165+0+0  XWAYLAND0

root# egrep -i 'hdmi|snb' /var/log/Xorg.0.log
101:[81.251] (II) modeset(0): glamor X acceleration enabled on
Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2)
105:[81.255] (II) modeset(0): Output HDMI-1 has no monitor section
176:[81.264] (II) modeset(0): EDID for output HDMI-1
180:[81.264] (II) modeset(0): Output HDMI-1 disconnected
337:[87.548] (II) config/udev: Adding input device HDA Intel PCH
HDMI/DP,pcm=3 (/dev/input/event11)

I am here on Linux v5.15.10 and using KDE/Wayland 5.23.4.

Do you need further information?

Thanks in advance.

Regards,
- Sedat -

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

[Sedat Dilek]

On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers  wrote:
>
> On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner  wrote:
> > > tglx just picked up 2 other patches of mine, bumping just in case he's
> > > not picking up patches while on vacation. ;)
> >
> > I'm only half on vacation :)
> >
> > So I can pick it up.
>
> Thanks, will send half margaritas.
>

Sends some Turkish Cay.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint

[Sedat Dilek]

On Fri, Aug 9, 2019 at 8:52 PM Chris Wilson  wrote:
>
> Quoting Matthew Auld (2019-08-09 19:47:02)
> > On Thu, 8 Aug 2019 at 18:23, Chris Wilson  wrote:
> > >
> > > The filesystem reconfigure API is undergoing a transition, breaking our
> > > current code. As we only set the default options, we can simply remove
> > > the call to s_op->remount_fs(). In the future, when HW permits, we can
> > > try re-enabling huge page support, albeit as suggested with new per-file
> > > controls.
> > >
> > > Reported-by: Sergey Senozhatsky 
> > > Reported-by: Sedat Dilek 
> > > Suggested-by: Hugh Dickins 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Matthew Auld 
> > > Cc: Hugh Dickins 
> > > Cc: Al Viro 
> > > Cc: Sergey Senozhatsky 
> > Reviewed-by: Matthew Auld 
>
> Thanks, picked up with the s/within/within_size/ fix.
> -Chris

For the records and followers:

[1] 
https://cgit.freedesktop.org/drm-intel/commit/?h=for-linux-next=72e67f04637432f91e4cc5e8e4f7eb4e38461e8e

Re: [Intel-gfx] [PATCHv2 0/3] convert i915 to new mount API

[Sedat Dilek]

On Mon, Aug 5, 2019 at 6:05 PM Sergey Senozhatsky
 wrote:
>
> Hello,
>
> Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops.
>
> It also appears that we need to EXPORTs put_filesystem(), so i915
> can properly put filesystem after it is done with kern_mount().
>
> v2:
> - export put_filesystem() [Chris]
> - always put_filesystem() in i915_gemfs_init() [Chris]
> - improve i915_gemfs_init() error message [Chris]
>
> Sergey Senozhatsky (3):
>   fs: export put_filesystem()
>   i915: convert to new mount API
>   i915: do not leak module ref counter
>

Fee free to add:

Reported-by: Sedat Dilek 

[1] 
https://lore.kernel.org/lkml/CA+icZUXh068m8UFeHDXCKDi0YfL2Z=woony7j7djlqat1cz...@mail.gmail.com/

>  drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++
>  fs/filesystems.c  |  1 +
>  2 files changed, 25 insertions(+), 9 deletions(-)
>
> --
> 2.22.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

[Sedat Dilek]

On Wed, Jul 31, 2019 at 2:25 PM Sedat Dilek  wrote:
>
> On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson  wrote:
> >
> > Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > > > >
> > > > > > Objtool reports:
> > > > > >
> > > > > >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: 
> > > > > > .altinstr_replacement+0x36: redundant UACCESS disable
> > > > > >
> > > > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > > > > >
> > > > > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page 
> > > > > > fault exception case")
> > > > > > Reported-by: Thomas Gleixner 
> > > > > > Reported-by: Sedat Dilek 
> > > > > > Acked-by: Peter Zijlstra (Intel) 
> > > > > > Tested-by: Nick Desaulniers 
> > > > > > Tested-by: Sedat Dilek 
> > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > > > > Signed-off-by: Josh Poimboeuf 
> > > > >
> > > > > Reviewed-by: Thomas Gleixner 
> > > >
> > > > Which tree do you plan to apply it to? I can put in drm-intel, and with
> > > > the fixes tag it will percolate through to 5.3 and beyond, but if you
> > > > want to apply it directly to squash the build warnings, feel free.
> > >
> > > It would be nice to get it into 5.3. I can route it linuxwards if you give
> > > an Acked-by, but I'm happy to hand it to you :)
> >
> > Acked-by: Chris Wilson 
>
> Thomas did you take this through tip tree after Chris' ACK?
>

Hi,

Gentle ping...
Thomas and Chris: Will someone of you pick this up?
As "objtool: Improve UACCESS coverage" [1] went trough tip tree I
highly appreciate to do so with this one.

Thanks.

Regards,
- Sedat -

[1] https://git.kernel.org/linus/882a0db9d143e5e8dac54b96e83135bccd1f68d1
[2] https://github.com/ClangBuiltLinux/linux/issues/617
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

[Sedat Dilek]

On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson  wrote:
>
> Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > > >
> > > > > Objtool reports:
> > > > >
> > > > >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: 
> > > > > .altinstr_replacement+0x36: redundant UACCESS disable
> > > > >
> > > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > > > >
> > > > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page 
> > > > > fault exception case")
> > > > > Reported-by: Thomas Gleixner 
> > > > > Reported-by: Sedat Dilek 
> > > > > Acked-by: Peter Zijlstra (Intel) 
> > > > > Tested-by: Nick Desaulniers 
> > > > > Tested-by: Sedat Dilek 
> > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > > > Signed-off-by: Josh Poimboeuf 
> > > >
> > > > Reviewed-by: Thomas Gleixner 
> > >
> > > Which tree do you plan to apply it to? I can put in drm-intel, and with
> > > the fixes tag it will percolate through to 5.3 and beyond, but if you
> > > want to apply it directly to squash the build warnings, feel free.
> >
> > It would be nice to get it into 5.3. I can route it linuxwards if you give
> > an Acked-by, but I'm happy to hand it to you :)
>
> Acked-by: Chris Wilson 

Thomas did you take this through tip tree after Chris' ACK?

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 4.10-rc7

[Sedat Dilek]

Hi Linus,

here in my environment I hit a pm/runtime problem.
For people seeing this too, [1] has the fix "PM / runtime: Avoid
false-positive warnings from might_sleep_if()".
Just for the records.

Regards,
- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=a9306a63631493afc75893a4ac405d4e1cbae6aa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] PM / runtime: Avoid false-positive warnings from might_sleep_if()

[Sedat Dilek]

On Sat, Feb 4, 2017 at 12:58 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Thursday, February 02, 2017 02:34:42 PM Sedat Dilek wrote:
>> On Wed, Feb 1, 2017 at 1:22 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
>> > On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki
>> > <rafael.j.wyso...@intel.com> wrote:
>> >> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
>> >>>
>> >>> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org>
>> >>> wrote:
>> >>>>
>> >>>> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I have already reported this issue in [1].
>> >>>>> One of the issue was solved.
>> >>>>> Unfortunately, it looks like there is still a different problem here
>> >>>>> (Ubuntu/precise AMD64).
>> >>>>>
>> >>>>> I tried v4.10-rc1 and latest Linus tree up to...
>> >>>>>
>> >>>>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
>> >>>>> "mm/filemap: fix parameters to test_bit()"
>> >>>>>
>> >>>>> Here we go...
>> >>>>>
>> >>>>> [   29.636047] BUG: sleeping function called from invalid context at
>> >>>>> drivers/base/power/runtime.c:1032
>> >>>>> [   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: 
>> >>>>> Xorg
>> >>>>> [   29.636058] 1 lock held by Xorg/1500:
>> >>>>> [   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
>> >>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> >>>>> [   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
>> >>>>> 4.10.0-rc1-6-iniza-amd64 #1
>> >>>>> [   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> >>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> >>>>> [   29.636111] Call Trace:
>> >>>>> [   29.636120]  dump_stack+0x85/0xc2
>> >>>>> [   29.636124]  ___might_sleep+0x196/0x260
>> >>>>> [   29.636127]  __might_sleep+0x53/0xb0
>> >>>>> [   29.636131]  __pm_runtime_resume+0x7a/0x90
>> >>>>> [   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
>> >>>>> [   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> >>>>> [   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
>> >>>>> [   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> >>>>> [   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
>> >>>>> [i915]
>> >>>>> [   29.636275]  ? trace_hardirqs_on+0xd/0x10
>> >>>>> [   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
>> >>>>> [i915]
>> >>>>> [   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 
>> >>>>> [i915]
>> >>>>> [   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> >>>>> [   29.636347]  ? __might_fault+0x4e/0xb0
>> >>>>> [   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> >>>>> [   29.636376]  ? __might_fault+0x4e/0xb0
>> >>>>> [   29.636395]  drm_ioctl+0x206/0x450 [drm]
>> >>>>> [   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> >>>>> [   29.636425]  ? __fget+0x5/0x200
>> >>>>> [   29.636429]  do_vfs_ioctl+0x91/0x6f0
>> >>>>> [   29.636431]  ? __fget+0x111/0x200
>> >>>>> [   29.636433]  ? __fget+0x5/0x200
>> >>>>> [   29.636436]  SyS_ioctl+0x79/0x90
>> >>>>> [   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
>> >>>>>
>> >>>>> On suspend/resume I see the same call trace.
>> >>>>> [2] points to the "BUG" line.
>> >>>>
>> >>>> Well, this appears to be an i915 issue, but not a serious one.
>> >>>>
>> >>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
>> >>>> intel_runtime_pm_get()) is called with disabled interrupts.  If I
>> >>>> understand t

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

[Sedat Dilek]

On Fri, May 27, 2016 at 10:19 AM, Chris Bainbridge
<chris.bainbri...@gmail.com> wrote:
> On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [   17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>> [   17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
>> *ERROR* uncleared pch fifo underrun on pch transcoder A
>> [   17.630685] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
>> *ERROR* PCH transcoder A FIFO underrun
>
> Guessing this is https://bugs.freedesktop.org/show_bug.cgi?id=95736

Hi Matt, Hi Daniel,

can you look at fdo #95736, please?

I still see this on all my Linux-kernels up to Linus upstream of today.

Thanks.

Regards,
- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi,
>>
>> I have already reported this issue in [1].
>> One of the issue was solved.
>> Unfortunately, it looks like there is still a different problem here
>> (Ubuntu/precise AMD64).
>>
>> I tried v4.10-rc1 and latest Linus tree up to...
>>
>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
>> "mm/filemap: fix parameters to test_bit()"
>>
>> Here we go...
>>
>> [   29.636047] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
>> [   29.636058] 1 lock held by Xorg/1500:
>> [   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
>> 4.10.0-rc1-6-iniza-amd64 #1
>> [   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.636111] Call Trace:
>> [   29.636120]  dump_stack+0x85/0xc2
>> [   29.636124]  ___might_sleep+0x196/0x260
>> [   29.636127]  __might_sleep+0x53/0xb0
>> [   29.636131]  __pm_runtime_resume+0x7a/0x90
>> [   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
>> [   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> [   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
>> [   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> [   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>> [   29.636275]  ? trace_hardirqs_on+0xd/0x10
>> [   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
>> [   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>> [   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> [   29.636347]  ? __might_fault+0x4e/0xb0
>> [   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> [   29.636376]  ? __might_fault+0x4e/0xb0
>> [   29.636395]  drm_ioctl+0x206/0x450 [drm]
>> [   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> [   29.636425]  ? __fget+0x5/0x200
>> [   29.636429]  do_vfs_ioctl+0x91/0x6f0
>> [   29.636431]  ? __fget+0x111/0x200
>> [   29.636433]  ? __fget+0x5/0x200
>> [   29.636436]  SyS_ioctl+0x79/0x90
>> [   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>
>> On suspend/resume I see the same call trace.
>> [2] points to the "BUG" line.
>
> Well, this appears to be an i915 issue, but not a serious one.
>
> Clearly, a function that may sleep (pm_runtime_get_sync() in
> intel_runtime_pm_get()) is called with disabled interrupts.  If I
> understand the code correctly, though, it actually is not going to
> sleep in this particular case, because pm_runtime_get_sync() has
> already been called once for this device in the same code path which
> means that this particular instance will return immediately, so this
> is a false-positive (most likely).
>
> Let me see if I the might_sleep_if() assertion in
> __pm_runtime_resume(() can be moved to a better place.
>

Hi Rafael,

did you had a chance to look at this?
The problem still remains in Linux v4.10-rc5.

Thanks.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi,
>>
>> I have already reported this issue in [1].
>> One of the issue was solved.
>> Unfortunately, it looks like there is still a different problem here
>> (Ubuntu/precise AMD64).
>>
>> I tried v4.10-rc1 and latest Linus tree up to...
>>
>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
>> "mm/filemap: fix parameters to test_bit()"
>>
>> Here we go...
>>
>> [   29.636047] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
>> [   29.636058] 1 lock held by Xorg/1500:
>> [   29.636060]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
>> 4.10.0-rc1-6-iniza-amd64 #1
>> [   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.636111] Call Trace:
>> [   29.636120]  dump_stack+0x85/0xc2
>> [   29.636124]  ___might_sleep+0x196/0x260
>> [   29.636127]  __might_sleep+0x53/0xb0
>> [   29.636131]  __pm_runtime_resume+0x7a/0x90
>> [   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
>> [   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> [   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
>> [   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> [   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>> [   29.636275]  ? trace_hardirqs_on+0xd/0x10
>> [   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
>> [   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>> [   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> [   29.636347]  ? __might_fault+0x4e/0xb0
>> [   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> [   29.636376]  ? __might_fault+0x4e/0xb0
>> [   29.636395]  drm_ioctl+0x206/0x450 [drm]
>> [   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> [   29.636425]  ? __fget+0x5/0x200
>> [   29.636429]  do_vfs_ioctl+0x91/0x6f0
>> [   29.636431]  ? __fget+0x111/0x200
>> [   29.636433]  ? __fget+0x5/0x200
>> [   29.636436]  SyS_ioctl+0x79/0x90
>> [   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>
>> On suspend/resume I see the same call trace.
>> [2] points to the "BUG" line.
>
> Well, this appears to be an i915 issue, but not a serious one.
>
> Clearly, a function that may sleep (pm_runtime_get_sync() in
> intel_runtime_pm_get()) is called with disabled interrupts.  If I
> understand the code correctly, though, it actually is not going to
> sleep in this particular case, because pm_runtime_get_sync() has
> already been called once for this device in the same code path which
> means that this particular instance will return immediately, so this
> is a false-positive (most likely).
>
> Let me see if I the might_sleep_if() assertion in
> __pm_runtime_resume(() can be moved to a better place.
>

OK.
Please CC me if you have something to test for.
Thanks, Rafael.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppala
<mika.kuopp...@linux.intel.com> wrote:
> Sedat Dilek <sedat.di...@gmail.com> writes:
>
>> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki <raf...@kernel.org> 
>> wrote:
>>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula <jani.nik...@intel.com> wrote:
>>>>> On Wed, 28 Dec 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
>>>>>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek <pa...@ucw.cz> wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>>> [ Add some pm | i915 | x86 folks ]
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>>>>>>> and I see some call-traces.
>>>>>>>> It is reproducible on suspend and resume.
>>>>>>>>
>>>>>>>> I cannot say which area touches the problem or if these are several
>>>>>>>> independent problems.
>>>>>>>>
>>>>>>>> For a full dmesg-log see attachments (my linux-config is attached, 
>>>>>>>> too).
>>>>>>>>
>>>>>>>> Here some hunks...
>>>>>>>>
>>>>>>>> [   29.003601] BUG: sleeping function called from invalid context at
>>>>>>>> drivers/base/power/runtime.c:1032
>>>>>>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: 
>>>>>>>> Xorg
>>>>>>>> [   29.003610] 1 lock held by Xorg/1469:
>>>>>>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>>>>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>>>>>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>>>>>>> 4.10.0-rc1-1-iniza-small #1
>>>>>>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>>>>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>>>>>>> [   29.003656] Call Trace:
>>>>>>>
>>>>>>> Just a note, at least 2 machines here refuse to resume with
>>>>>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>>>>>> common cause...
>>>>>>>
>>>>>>
>>>>>> [ Correct linux-pm ML and add Mika & Jani ]
>>>>>>
>>>>>> Thanks for the feedback.
>>>>>>
>>>>>> There are some cpu/hotplug fixes post-v4.10-rc1.
>>>>>> Give that a try.
>>>>>>
>>>>>> Yesterday, after answers from drm-intel folks I have seen that a
>>>>>> cpu/hotplug commit [1] was reverted in
>>>>>> drm-intel.git#drm-intel-nightly.
>>>>>> I haven't tried that.
>>>>>>
>>>>>> It's good when Thomas knows of this and gets in contact with drm-intel 
>>>>>> folks.
>>>>>>
>>>>>> Regards,
>>>>>> - Sedat -
>>>>>>
>>>>>> [1] 
>>>>>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>>>>>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>>>>>
>>>>>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>>>>>
>>>>>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>>>>>> Author: Thomas Gleixner <t...@linutronix.de>
>>>>>> Date: Wed Dec 21 20:19:49 2016 +0100
>>>>>> cpu/hotplug: Prevent overwriting of callbacks
>>>>>>
>>>>>> It started hanging all machines in CI s3 test:
>>>>>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>>>>>
>>>>>> Bisected-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
>>>>>> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
>>>>>
>>>>> Thomas -
>>>>>
>>>>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>>>>> suspend/r

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula <jani.nik...@intel.com> wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
>>>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek <pa...@ucw.cz> wrote:
>>>>> Hi!
>>>>>
>>>>>> [ Add some pm | i915 | x86 folks ]
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>>>>> and I see some call-traces.
>>>>>> It is reproducible on suspend and resume.
>>>>>>
>>>>>> I cannot say which area touches the problem or if these are several
>>>>>> independent problems.
>>>>>>
>>>>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>>>>
>>>>>> Here some hunks...
>>>>>>
>>>>>> [   29.003601] BUG: sleeping function called from invalid context at
>>>>>> drivers/base/power/runtime.c:1032
>>>>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>>>>> [   29.003610] 1 lock held by Xorg/1469:
>>>>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>>>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>>>>> 4.10.0-rc1-1-iniza-small #1
>>>>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>>>>> [   29.003656] Call Trace:
>>>>>
>>>>> Just a note, at least 2 machines here refuse to resume with
>>>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>>>> common cause...
>>>>>
>>>>
>>>> [ Correct linux-pm ML and add Mika & Jani ]
>>>>
>>>> Thanks for the feedback.
>>>>
>>>> There are some cpu/hotplug fixes post-v4.10-rc1.
>>>> Give that a try.
>>>>
>>>> Yesterday, after answers from drm-intel folks I have seen that a
>>>> cpu/hotplug commit [1] was reverted in
>>>> drm-intel.git#drm-intel-nightly.
>>>> I haven't tried that.
>>>>
>>>> It's good when Thomas knows of this and gets in contact with drm-intel 
>>>> folks.
>>>>
>>>> Regards,
>>>> - Sedat -
>>>>
>>>> [1] 
>>>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>>>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>>>
>>>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>>>
>>>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>>>> Author: Thomas Gleixner <t...@linutronix.de>
>>>> Date: Wed Dec 21 20:19:49 2016 +0100
>>>> cpu/hotplug: Prevent overwriting of callbacks
>>>>
>>>> It started hanging all machines in CI s3 test:
>>>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>>>
>>>> Bisected-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
>>>> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
>>>
>>> Thomas -
>>>
>>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>>> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
>>> of callbacks"), and after the revert in the tree that feeds to the CI,
>>> we're back on track.
>>>
>>> I found [1], was hoping to get feedback from Mika whether that helps
>>> before reporting. Chris also suggested [2] as a quick fix but I don't
>>> know if anyone tried that.
>>>
>>
>> Hi Jani,
>>
>> I know you were not CCed in the original thread, please see [5].
>>
>> The patchset from Thomas you mention [1] does fix one of the problems
>> I have seen, please see [6].
>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>
>> Can you give a clear statement if the quick-fix from Chris is in
>> combination with the above revert or not?
>> Against v4.10-rc1?
>> Tested together with the patchset of Thomas?
>
> Please test the Linus' tree from today, it should work.
>

Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula <jani.nik...@intel.com> wrote:
> On Wed, 28 Dec 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek <pa...@ucw.cz> wrote:
>>> Hi!
>>>
>>>> [ Add some pm | i915 | x86 folks ]
>>>>
>>>> Hi,
>>>>
>>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>>> and I see some call-traces.
>>>> It is reproducible on suspend and resume.
>>>>
>>>> I cannot say which area touches the problem or if these are several
>>>> independent problems.
>>>>
>>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>>
>>>> Here some hunks...
>>>>
>>>> [   29.003601] BUG: sleeping function called from invalid context at
>>>> drivers/base/power/runtime.c:1032
>>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>>> [   29.003610] 1 lock held by Xorg/1469:
>>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>>> 4.10.0-rc1-1-iniza-small #1
>>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>>> [   29.003656] Call Trace:
>>>
>>> Just a note, at least 2 machines here refuse to resume with
>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>> common cause...
>>>
>>
>> [ Correct linux-pm ML and add Mika & Jani ]
>>
>> Thanks for the feedback.
>>
>> There are some cpu/hotplug fixes post-v4.10-rc1.
>> Give that a try.
>>
>> Yesterday, after answers from drm-intel folks I have seen that a
>> cpu/hotplug commit [1] was reverted in
>> drm-intel.git#drm-intel-nightly.
>> I haven't tried that.
>>
>> It's good when Thomas knows of this and gets in contact with drm-intel folks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>
>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>
>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>> Author: Thomas Gleixner <t...@linutronix.de>
>> Date: Wed Dec 21 20:19:49 2016 +0100
>> cpu/hotplug: Prevent overwriting of callbacks
>>
>> It started hanging all machines in CI s3 test:
>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>
>> Bisected-by: Mika Kuoppala <mika.kuopp...@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
>
> Thomas -
>
> Indeed, basically all of the boxes in the intel-gfx CI hang at the
> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
> of callbacks"), and after the revert in the tree that feeds to the CI,
> we're back on track.
>
> I found [1], was hoping to get feedback from Mika whether that helps
> before reporting. Chris also suggested [2] as a quick fix but I don't
> know if anyone tried that.
>

Hi Jani,

I know you were not CCed in the original thread, please see [5].

The patchset from Thomas you mention [1] does fix one of the problems
I have seen, please see [6].
With these post-v4.10-rc1 patches applied a clean revert of Revert
"cpu/hotplug: Prevent overwriting of callbacks" is not possible.

Can you give a clear statement if the quick-fix from Chris is in
combination with the above revert or not?
Against v4.10-rc1?
Tested together with the patchset of Thomas?

Thanks.

Regards,
- Sedat -

[5] http://marc.info/?t=14827939021=1=2
[6] http://marc.info/?l=linux-kernel=148282459901267=2


> BR,
> Jani.
>
>
> [1] https://lkml.org/lkml/2016/12/26/156
> [2] http://paste.debian.net/904973/
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches the problem or if these are several
>> independent problems.
>>
>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>
>> Here some hunks...
>>
>> [   29.003601] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> [   29.003610] 1 lock held by Xorg/1469:
>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> 4.10.0-rc1-1-iniza-small #1
>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.003656] Call Trace:
>
> Just a note, at least 2 machines here refuse to resume with
> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
> common cause...
>

[ Correct linux-pm ML and add Mika & Jani ]

Thanks for the feedback.

There are some cpu/hotplug fixes post-v4.10-rc1.
Give that a try.

Yesterday, after answers from drm-intel folks I have seen that a
cpu/hotplug commit [1] was reverted in
drm-intel.git#drm-intel-nightly.
I haven't tried that.

It's good when Thomas knows of this and gets in contact with drm-intel folks.

Regards,
- Sedat -

[1] 
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
[2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly

P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

This reverts commit dc280d93623927570da279e99393879dbbab39e7
Author: Thomas Gleixner 
Date: Wed Dec 21 20:19:49 2016 +0100
cpu/hotplug: Prevent overwriting of callbacks

It started hanging all machines in CI s3 test:
https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html

Bisected-by: Mika Kuoppala 
Signed-off-by: Jani Nikula 

- EOT -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
>> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>>> > [ Add some pm | i915 | x86 folks ]
>>> >
>>> > Hi,
>>> >
>>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> > and I see some call-traces.
>>> > It is reproducible on suspend and resume.
>>> >
>>> > I cannot say which area touches the problem or if these are several
>>> > independent problems.
>>> >
>>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>>> >
>>> > Here some hunks...
>>> >
>>> > [   29.003601] BUG: sleeping function called from invalid context at
>>> > drivers/base/power/runtime.c:1032
>>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> > [   29.003610] 1 lock held by Xorg/1469:
>>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> > 4.10.0-rc1-1-iniza-small #1
>>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> > [   29.003656] Call Trace:
>>> > [   29.003663]  dump_stack+0x85/0xc2
>>> > [   29.003666]  ___might_sleep+0x196/0x260
>>> > [   29.003668]  __might_sleep+0x53/0xb0
>>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>>> > [   29.003755]  ? find_get_entry+0x5/0x240
>>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 
>>> > [i915]
>>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>>> > [i915]
>>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>>> > [   29.003918]  ? __fget+0x5/0x200
>>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>>> > [   29.003925]  ? __fget+0x111/0x200
>>> > [   29.003926]  ? __fget+0x5/0x200
>>> > [   29.003929]  SyS_ioctl+0x79/0x90
>>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>>> > 0010
>>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>>> > 7fb9e09e7bb7
>>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>>> > 0009
>>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>>> > 0101010101010101
>>> > [   29.003945] R10:  R11: 3202 R12: 
>>> > 0008
>>> > [   29.003947] R13: 00f5 R14:  R15: 
>>> > 
>>>
>>> This should be independent of suspend/resume and should be fixed with
>>> https://patchwork.freedesktop.org/patch/116373/
>>>
>>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>>> Author: Chris Wilson <ch...@chris-wilson.co.uk>
>>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>>
>>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>>
>>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>>> course.
>>
>> Also note that our CI is unhappy with -rc1, and it was not due to i915
>> patches. So very likely something else is also broken.
>>
>
> Can you explain what "CI" me

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

[Sedat Dilek]

On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>> > [ Add some pm | i915 | x86 folks ]
>> >
>> > Hi,
>> >
>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> > and I see some call-traces.
>> > It is reproducible on suspend and resume.
>> >
>> > I cannot say which area touches the problem or if these are several
>> > independent problems.
>> >
>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>> >
>> > Here some hunks...
>> >
>> > [   29.003601] BUG: sleeping function called from invalid context at
>> > drivers/base/power/runtime.c:1032
>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> > [   29.003610] 1 lock held by Xorg/1469:
>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> > 4.10.0-rc1-1-iniza-small #1
>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> > [   29.003656] Call Trace:
>> > [   29.003663]  dump_stack+0x85/0xc2
>> > [   29.003666]  ___might_sleep+0x196/0x260
>> > [   29.003668]  __might_sleep+0x53/0xb0
>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> > [   29.003755]  ? find_get_entry+0x5/0x240
>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>> > [i915]
>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> > [   29.003918]  ? __fget+0x5/0x200
>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>> > [   29.003925]  ? __fget+0x111/0x200
>> > [   29.003926]  ? __fget+0x5/0x200
>> > [   29.003929]  SyS_ioctl+0x79/0x90
>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>> > 0010
>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>> > 7fb9e09e7bb7
>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>> > 0009
>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>> > 0101010101010101
>> > [   29.003945] R10:  R11: 3202 R12: 
>> > 0008
>> > [   29.003947] R13: 00f5 R14:  R15: 
>> > 
>>
>> This should be independent of suspend/resume and should be fixed with
>> https://patchwork.freedesktop.org/patch/116373/
>>
>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>> Author: Chris Wilson <ch...@chris-wilson.co.uk>
>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>
>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>
>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>> course.
>
> Also note that our CI is unhappy with -rc1, and it was not due to i915
> patches. So very likely something else is also broken.
>

Can you explain what "CI" means and its function in drm-intel development?

The mentioned patch is 4/4 of a series [1].
The single patch does not apply on top of Linux v4.10-rc1.

1/4 does not apply, etc.

2/4 is already in Linus tree [2].
Can you explain why the other 3 did not got into v4.10-rc1?

So, what is your advise to test Chris' patch?

- Sedat -

[1] https://patchwork.freedesktop.org/series/13950/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4bcbe2a90a1127a6dad72fbda27e77705d9e0f4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

[Sedat Dilek]

On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
>> have reported. )
>> The call-trace is reproducible with my setup and seen on every boot.
>>
>> Not sure if this is a problem in intel-gfx or fbdev.
>
> Personally, I blamed backlight,
> https://patchwork.freedesktop.org/patch/95769/

[ CC Peter, Johannes and Thorsten "The regression reporter" ]

Peter has 2 fixes from Johannes in peterz/queue.git#locking/urgent
which fix the issue for me.

[1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
[2/2] locking/barriers: suppress sparse warnings in lockless_dereference()

I tried today's Linus tree with those two fixes.

Chris backlight fix is no more needed here.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=locking/urgent=f9d089b7830bbaa6ccaad29dff5fbb01d2a69945
[2] 
http://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=locking/urgent=1804f7121995e8ca341427d848c0c8d267147720
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

[Sedat Dilek]

On Mon, Aug 1, 2016 at 3:33 PM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Fri, 15 Jul 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>
> FWIW, "d-i-n" is ambiguous (drm-intel-next vs. drm-intel-nightly) and we
> don't use that ourselves.
>

Oh, sorry with d-i-n I meant drm-intel-nightly.
Normally, I also point to the "integration manifest"
like...drm-intel-nightly: 2016y-08m-02d-14h-10m-12s UTC integration
manifest.
You do not test d-i-n yourself?
Strange.
The Ubuntu kernel-team is regularly building packages see [1] if you
did not know.

- Sedat -

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/

> BR,
> Jani.
>
>
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
>> have reported. )
>> The call-trace is reproducible with my setup and seen on every boot.
>>
>> Not sure if this is a problem in intel-gfx or fbdev.
>>
>> My linux-config and full dmesg-output is attached.
>>
>> If you need additional informations, please let me know.
>>
>> Regards,
>> - Sedat -
>>
>> [1] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100693.html
>> [2] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html
>>
>> P.S.: INFO: possible circular locking dependency detected
>>
>> [   16.955703] fbcon: inteldrmfb (fb0) is primary device
>> [   16.956579]
>> [   16.956580] ==
>> [   16.956581] [ INFO: possible circular locking dependency detected ]
>> [   16.956583] 4.7.0-rc7-4-iniza-small #1 Not tainted
>> [   16.956583] ---
>> [   16.956585] kworker/u16:1/79 is trying to acquire lock:
>> [   16.956618]  (>mode_config.mutex){+.+.+.}, at:
>> [] drm_modeset_lock_all+0x40/0x120 [drm]
>> [   16.956619]
>> [   16.956619] but task is already holding lock:
>> [   16.956626]  ((fb_notifier_list).rwsem){.+}, at:
>> [] __blocking_notifier_call_chain+0x35/0x70
>> [   16.956627]
>> [   16.956627] which lock already depends on the new lock.
>> [   16.956627]
>> [   16.956627]
>> [   16.956627] the existing dependency chain (in reverse order) is:
>> [   16.956631]
>> [   16.956631] -> #1 ((fb_notifier_list).rwsem){.+}:
>> [   16.956635][] lock_acquire+0x119/0x220
>> [   16.956639][] down_write+0x49/0x80
>> [   16.956642][]
>> blocking_notifier_chain_register+0x21/0xb0
>> [   16.956646][] fb_register_client+0x18/0x20
>> [   16.956648][] 
>> backlight_device_register+0x12b/0x240
>> [   16.956710][]
>> intel_backlight_device_register+0xa2/0x170 [i915]
>> [   16.956764][]
>> intel_connector_register+0xe/0x10 [i915]
>> [   16.956778][]
>> drm_connector_register+0x4a/0x80 [drm]
>> [   16.956792][]
>> drm_modeset_register_all+0x163/0x1c0 [drm]
>> [   16.956805][] drm_dev_register+0xc2/0xd0 [drm]
>> [   16.956848][] i915_driver_load+0x753/0x13e0 
>> [i915]
>> [   16.956892][] i915_pci_probe+0x4f/0x70 [i915]
>> [   16.956896][] local_pci_probe+0x45/0xa0
>> [   16.956899][] pci_device_probe+0xdd/0x130
>> [   16.956901][] driver_probe_device+0x18e/0x2d0
>> [   16.956902][] __driver_attach+0x97/0xa0
>> [   16.956905][] bus_for_each_dev+0x66/0xa0
>> [   16.956908][] driver_attach+0x1e/0x20
>> [   16.956910][] bus_add_driver+0x1b8/0x230
>> [   16.956911][] driver_register+0x60/0xe0
>> [   16.956913][] __pci_register_driver+0x60/0x70
>> [   16.956949][] i915_init+0x5d/0x64 [i915]
>> [   16.956952][] do_one_initcall+0x3d/0x160
>> [   16.956954][] do_init_module+0x60/0x1dc
>> [   16.956957][] load_module+0x2012/0x2610
>> [   16.956959][] SYSC_init_module+0x126/0x140
>> [   16.956962][] SyS_init_module+0xe/0x10
>> [   16.956964][] 
>> entry_SYSCALL_64_fastpath+0x23/0xc1
>> [   16.956966]
>> [   16.956966] -> #0 (>mode_config.mutex){+.+.+.}:
>> [   16.956968][] __lock_acquire+0x19ed/0x1aa0
>> [   16.956970][] lock_acquire+0x119/0x220
>> [   16.956971][] mutex_lock_nested+0x69/0x3c0
>> [   16.956988][] drm_modeset_lock_all+0x40/0x120 
>> [drm]
>> [   16.956998][]
>> drm_fb_helper_restore_fbdev_mode_unl

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

[Sedat Dilek]

On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
>> have reported. )
>> The call-trace is reproducible with my setup and seen on every boot.
>>
>> Not sure if this is a problem in intel-gfx or fbdev.
>
> Personally, I blamed backlight,
> https://patchwork.freedesktop.org/patch/95769/
>

Thanks, I try the patch when I am at home in front of my machine.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: build failure after merge of the drm tree

[Sedat Dilek]

On 7/15/16, Stephen Rothwell  wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
> 'intel_opregion_get_panel_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
>
> Caused by commit
>
>   6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
>   aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell 
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> --
> 2.8.1
>

I fell over the same issue when testing drm-intel-nightly and sent a patch.

- Sedat -

https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH d-i-n] drm/i915: Fix build failure in intel_opregion_get_panel_type()

[Sedat Dilek]

Tested against drm-intel-nightly (2016y-07m-14d-20h-15m-29s UTC).

Fixes: aeddda06c1a704bb9 ("drm/i915: Ignore panel type from OpRegion on SKL")
CC: intel-gfx@lists.freedesktop.org
CC: Ville Syrjälä <ville.syrj...@linux.intel.com>
CC: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Sedat Dilek <sedat.di...@gmail.com>
---
 drivers/gpu/drm/i915/intel_opregion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index c804630d10d2..adca262d591a 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1078,7 +1078,7 @@ intel_opregion_get_panel_type(struct drm_i915_private 
*dev_priv)
 * vswing instead. Low vswing results in some display flickers, so
 * let's simply ignore the OpRegion panel type on SKL for now.
 */
-   if (IS_SKYLAKE(dev)) {
+   if (IS_SKYLAKE(dev_priv)) {
DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
return -ENODEV;
}
-- 
2.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [v4.7-rc5] i915: *ERROR* (CPU pipe|PCH transcoder) A FIFO underrun

[Sedat Dilek]

Hi Daniel,

I had already reported this issue in a email-thread called
"[v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A
FIFO underrun".

This is still happening here on Sandybridge (and Ivybridge GPU
reported by Chris Bainbridge).
I have updated the bug-report in [1].

Chris B. reports in the BR:

"Bisect result:

ed4a6a7ca853253f9b86f3005d76345482a71283 is the first bad commit
commit ed4a6a7ca853253f9b86f3005d76345482a71283
Author: Matt Roper 
Date:   Tue Feb 23 17:20:13 2016 -0800

drm/i915: Add two-stage ILK-style watermark programming (v11)"

Any news on that issue?

Regards,
- Sedat -

[1] https://bugs.freedesktop.org/show_bug.cgi?id=95736
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

[Sedat Dilek]

On 5/28/16, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On 5/27/16, Chris Bainbridge <chris.bainbri...@gmail.com> wrote:
>> On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote:
>>> Hi Daniel,
>>>
>>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>>
>>> [   17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>>> *ERROR* CPU pipe A FIFO underrun
>>> [   17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
>>> *ERROR* uncleared pch fifo underrun on pch transcoder A
>>> [   17.630685] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
>>> *ERROR* PCH transcoder A FIFO underrun
>>
>> Guessing this is https://bugs.freedesktop.org/show_bug.cgi?id=95736
>>
>
> I did some last testing (for this weekend) with drm-intel-nightly
> (2016y-05m-27d-12h-32m-45s UTC) on top of Linux v4.6 final.
>
> This did not help as I see the same *ERROR* outputs.
>

With drm-intel-nightly (2016y-05m-30d-17h-51m-33s-UTC) the outputs
look a bit different and more helpful?

[   19.139790] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
[   19.140274] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
*ERROR* uncleared pch fifo underrun on pch transcoder A
[   19.140299] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
*ERROR* PCH transcoder A FIFO underrun

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

[Sedat Dilek]

On 5/27/16, Chris Bainbridge <chris.bainbri...@gmail.com> wrote:
> On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [   17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>> [   17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
>> *ERROR* uncleared pch fifo underrun on pch transcoder A
>> [   17.630685] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
>> *ERROR* PCH transcoder A FIFO underrun
>
> Guessing this is https://bugs.freedesktop.org/show_bug.cgi?id=95736
>

Thanks for the hint!

Did you try with reverting this "first bad" commit mentionned in your
BR (or a "series of commits")?

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

[Sedat Dilek]

On 5/25/16, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 25 May 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [   17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>> [   17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
>> *ERROR* uncleared pch fifo underrun on pch transcoder A
>> [   17.630685] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
>> *ERROR* PCH transcoder A FIFO underrun
>>
>> Attached are my linux-config, dmesg-output anx Xorg-log.
>>
>> Any other informations you need?
>
> For starters, please try the fixes pull I just sent on top [1]. There's
> a couple of watermark fixes.
>
> BR,
> Jani.
>
>
>
> [1] http://mid.gmane.org/87zirebjm7@intel.com
>
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
>

I pulled in drm-intel.git#tags/drm-intel-next-fixes-2016-05-25 on top
of above mentionned latest Linus Git and the problem still remains!

$ dmesg | egrep i915 | grep -i error
[   19.583713] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
[   19.586363] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
*ERROR* uncleared pch fifo underrun on pch transcoder A
[   19.586399] [drm:intel_pch_fifo_underrun_irq_handler [i915]]
*ERROR* PCH transcoder A FIFO underrun

I have attached my dmesg-output only, the linux-config I had sent earlier.

- Sedat -
[0.00] Linux version 4.6.0-10530.2-iniza-small 
(sedat.di...@gmail.com@fambox) (gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~12.04) 
) #1 SMP Thu May 26 07:20:40 CEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-10530.2-iniza-small 
root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro intel_pstate=disable
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] Disabled fast string operations
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable
[0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved
[0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable
[0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffd8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00011fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: SAMSUNG ELECTRONICS CO., LTD. 
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x11fe00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable

Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found

[Sedat Dilek]

On Thu, Mar 31, 2016 at 12:36 PM, Dave Gordon <david.s.gor...@intel.com> wrote:
> On 24/03/16 12:47, Chris Wilson wrote:
>>
>> On Thu, Mar 24, 2016 at 12:29:32PM +, Dave Gordon wrote:
>>>
>>> On 24/03/16 09:54, Chris Wilson wrote:
>>>>
>>>> On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
>>>>>
>>>>> [ build-script, build and config logs attached ]
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I am just seeing this (or noticed for the first time, here on
>>>>> Ubuntu/precise AMD64)...
>>>>>
>>>>> $ zgrep -A1 -B1 ACLOCAL_FLAGS:
>>>>>
>>>>> build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
>>>>> autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
>>>>> sh: 1: ACLOCAL_FLAGS: not found
>>>>> autoreconf: configure.ac: tracing
>>>>> --
>>>>> libtoolize: copying file `m4/lt~obsolete.m4'
>>>>> sh: 1: ACLOCAL_FLAGS: not found
>>>>> autoreconf: running: /usr/bin/autoconf
>>>>>
>>>>> What does this mean and it is ignore-able?
>>>>
>>>>
>>>> libtool vs automake. Haven't found the right fix yet.
>>>>
>>>> If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
>>>> I think that's what we'll have to do :|
>>>> -Chris
>>>
>>>
>>> Is this a confusion between an (undefined) Make-variable vs a shell
>>> variable? The syntax above with parentheses $(VAR) would be right
>>> for expanding a Make-variable, but it looks like it's being passed
>>> as-is to the shell, which interprets it as command-substitution and
>>> tries to run the (non-existent) *command* ACLOCAL_FLAGS
>>
>>
>> Yes. The issue is that recently libtool spits out
>> an obtuse error if it sees ${ACLOCAL_FLAGS} in ACLOCAL_AMFLAGS
>>
>> libtoolize:   error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
>> ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
>> autoreconf: libtoolize failed with exit status: 1
>>
>> i.e. it misses that we both include the user aclocal directory as well
>> as our own -I m4.
>>
>> So I tried using it as a make variable instead, but then it is evaluated
>> as the shell $() command!
>> -Chris
>
>
> Perhaps try setting AC_CONFIG_MACRO_DIRS to [/opt/xorg/share/aclocal, m4]
> instead, and not use ACLOCAL_AMFLAGS? Or at least not to extend the include
> path.
>

How do I do that?
( My build-script is attached. )

- Sedat -


build_xf86-video-intel-with-llvm.sh
Description: Bourne shell script
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [intelddx] TearFree still status "Experimental support"?

[Sedat Dilek]

On Thu, Mar 24, 2016 at 12:19 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 11:56 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> Hi Chris,
>>
>> is TearFree feature still "experimental" in current 
>> xf86-video-intel.git#master?
>> It is enabled by default!
>>
>> [ configure-log ]
>> ...
>> xf86-video-intel 2.99.917 will be compiled with:
>>   Xorg Video ABI version: 15.0 (xorg-server-1.15.1)
>>   pixman version: pixman-1-0.30.2
>>   Acceleration backends: none *sna uxa
>>   Additional debugging support? valgrind
>>   Support for Kernel Mode Setting? yes
>>   Support for legacy User Mode Setting (for i810)? yes
>>   Support for Direct Rendering Infrastructure: *DRI2
>>   Support for Xv motion compensation (XvMC and libXvMC): yes
>>   Support for display hotplug notifications (udev): yes
>>   Build additional tools and utilities? xf86-video-intel-backlight-helper
>>   Experimental support: TearFree <--- XXX
>> ...
>>
>> [ configure.ac ]
>> ...
>> AC_ARG_ENABLE(tear-free,
>>  AS_HELP_STRING([--enable-tear-free],
>> [Enable use of TearFree by default [default=no]]),
>>  [TEARFREE="$enableval"],
>>  [TEARFREE="no"])
>> if test "x$TEARFREE" = "xyes"; then
>> AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
>> xp_msg="$xp_msg TearFree" <--- Line needs to be killed ???
>> fi
>> ...
>> if test -n "$xp_msg"; then
>> echo "  Experimental support:$xp_msg"
>> fi
>> ...
>>
>> Thanks.
>>
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742
>> [2] 
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n927
>
> See attached patch.
>

Looks like I misread in configure.ac, TearFree is not enabled by default.

[ configure.ac ]

AC_ARG_ENABLE(tear-free,
 AS_HELP_STRING([--enable-tear-free],
[Enable use of TearFree by default [default=no]]),
 [TEARFREE="$enableval"],
 [TEARFREE="no"])
if test "x$TEARFREE" = "xyes"; then
AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
xp_msg="$xp_msg TearFree"
fi

So forget this braino.

- Sedat -

[1] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1

[Sedat Dilek]

On Thu, Mar 24, 2016 at 2:09 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Thu, Mar 24, 2016 at 12:47:51PM +, Dave Gordon wrote:
>> On 24/03/16 11:11, Sedat Dilek wrote:
>> > From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
>> >From: Sedat Dilek<sedat.di...@gmail.com>
>> >Date: Thu, 24 Mar 2016 12:01:37 +0100
>> >Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
>> >  automake problem
>> >
>> >---
>> >  Makefile.am | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/Makefile.am b/Makefile.am
>> >index c60e8a729271..396f41fdc4df 100644
>> >--- a/Makefile.am
>> >+++ b/Makefile.am
>> >@@ -18,7 +18,7 @@
>> >  #  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>> >  #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
>> > SOFTWARE.
>> >
>> >-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>> >+ACLOCAL_AMFLAGS = -I m4
>> >
>> >  SUBDIRS = man libobj xvmc src tools
>> >
>> >--
>>
>> Looks like the issue is related to trying to layer the Make-variable
>> expansion.
>>
>> In the shell (and most other languages) an assignment like:
>>
>> $ ACLOCAL_AMFLAGS="${ACLOCAL_FLAGS} -I m4"
>>
>> would take the current value of the existing ACLOCAL_FLAGS variable
>> and use it construct the value of the new variable ACLOCAL_AMFLAGS.
>> Thus if ACLOCAL_were "--XXX" this would yield "-XXX -I m4". Then
>> later we'd see:
>>
>> $ aclocal ${ACLOCAL_AMFLAGS} ...
>>
>> which would use the value as previously defined.
>>
>> Make doesn't do that. It sets ACLOCAL_AMFLAGS to "$(ACLOCAL_FLAGS)
>> -I m4" and then later, when ACLOCAL_AMFLAGS is *used* it expands it,
>> and then notices that the expanded version still contains a $(var)
>> construct and expands *that* ... and so on until there are none
>> left. This is sometimes useful, but often confusing. So GNU make (as
>> POSIX, from 2012 on) supports another type of assignment,
>>
>> VAR ::= expression
>>
>> which does the expansion of  just once, at this point,
>> and stores the result rather than the  itself. So, try
>> changing the line
>>
>> ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>>
>> in the Makefile into:
>>
>> ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>>
>> and see whether that helps :)
>
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> => autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
> ...
>
> With setenv ACLOCAL_FLAGS "-I /opt/xorg/share/aclocal":
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/ ${ACLOCAL_FLAGS} 
> -I m4
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize:   error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
> ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
>
> Using ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>
> It looks like using
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> is obsolete in autoreconf (GNU Autoconf) 2.69.
> So looks like the answer is
> AC_PREREQ([2.69])
> ACLOCAL_AMFLAGS = -I m4

Not sure what the real fix of the reported "ACLOCAL_FLAGS issue" is.

As said in my initial asking I have here on Ubuntu/precise AMD64 autoconf v2.68.
Being no autotools-guru, version and feature check might make sense.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] commit 1b82b7b48d17b4b3401e9d82b0fe86df06c8d451 breaks here

[Sedat Dilek]

On Thu, Mar 24, 2016 at 12:40 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Thu, Mar 24, 2016 at 12:33:24PM +0100, Sedat Dilek wrote:
>> Caused by "sna/present: Cancel pending unflips when resizing the screen".
>
> Sorry,
>
> commit c326ed192bcaeea41bb93b7077ec37a1437a4409
> Author: Chris Wilson <ch...@chris-wilson.co.uk>
> Date:   Thu Mar 24 11:38:35 2016 +
>
> sna/present: Add missing "static inline" for disabled present stubs

Builds fines.
Thanks.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] commit 1b82b7b48d17b4b3401e9d82b0fe86df06c8d451 breaks here

[Sedat Dilek]

Caused by "sna/present: Cancel pending unflips when resizing the screen".

...
make[3]: Entering directory
`/home/wearefam/src/xserver-xorg-video-intel/xf86-video-intel-git/src'
  CC backlight.lo
  CC fd.lo
  CC intel_device.lo
  CC intel_options.lo
  CC intel_module.lo
  CCLD   intel_drv.la
sna/.libs/libsna.a(kgem.o): In function `sna_present_cancel_flip':
kgem.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_accel.o): In function `sna_present_cancel_flip':
sna_accel.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_acpi.o): In function `sna_present_cancel_flip':
sna_acpi.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_blt.o): In function `sna_present_cancel_flip':
sna_blt.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_composite.o): In function `sna_present_cancel_flip':
sna_composite.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_cpu.o): In function `sna_present_cancel_flip':
sna_cpu.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_damage.o): In function `sna_present_cancel_flip':
sna_damage.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_display.o): In function `sna_present_cancel_flip':
sna_display.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_display_fake.o): In function `sna_present_cancel_flip':
sna_display_fake.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_driver.o): In function `sna_present_cancel_flip':
sna_driver.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_glyphs.o): In function `sna_present_cancel_flip':
sna_glyphs.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_gradient.o): In function `sna_present_cancel_flip':
sna_gradient.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_io.o): In function `sna_present_cancel_flip':
sna_io.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_render.o): In function `sna_present_cancel_flip':
sna_render.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_stream.o): In function `sna_present_cancel_flip':
sna_stream.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_trapezoids.o): In function `sna_present_cancel_flip':
sna_trapezoids.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_trapezoids_boxes.o): In function
`sna_present_cancel_flip':
sna_trapezoids_boxes.c:(.text+0x0): multiple definition of
`sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_trapezoids_imprecise.o): In function
`sna_present_cancel_flip':
sna_trapezoids_imprecise.c:(.text+0x0): multiple definition of
`sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_trapezoids_mono.o): In function
`sna_present_cancel_flip':
sna_trapezoids_mono.c:(.text+0x0): multiple definition of
`sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_trapezoids_precise.o): In function
`sna_present_cancel_flip':
sna_trapezoids_precise.c:(.text+0x0): multiple definition of
`sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_tiling.o): In function `sna_present_cancel_flip':
sna_tiling.c:(.text+0x0): multiple definition of `sna_present_cancel_flip'
sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here
sna/.libs/libsna.a(sna_transform.o): In function `sna_present_cancel_flip':
sna_transform.c:(.text+0x0): multiple definition of 

Re: [Intel-gfx] [intelddx] TearFree still status "Experimental support"?

[Sedat Dilek]

On Thu, Mar 24, 2016 at 11:56 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> Hi Chris,
>
> is TearFree feature still "experimental" in current 
> xf86-video-intel.git#master?
> It is enabled by default!
>
> [ configure-log ]
> ...
> xf86-video-intel 2.99.917 will be compiled with:
>   Xorg Video ABI version: 15.0 (xorg-server-1.15.1)
>   pixman version: pixman-1-0.30.2
>   Acceleration backends: none *sna uxa
>   Additional debugging support? valgrind
>   Support for Kernel Mode Setting? yes
>   Support for legacy User Mode Setting (for i810)? yes
>   Support for Direct Rendering Infrastructure: *DRI2
>   Support for Xv motion compensation (XvMC and libXvMC): yes
>   Support for display hotplug notifications (udev): yes
>   Build additional tools and utilities? xf86-video-intel-backlight-helper
>   Experimental support: TearFree <--- XXX
> ...
>
> [ configure.ac ]
> ...
> AC_ARG_ENABLE(tear-free,
>  AS_HELP_STRING([--enable-tear-free],
> [Enable use of TearFree by default [default=no]]),
>  [TEARFREE="$enableval"],
>  [TEARFREE="no"])
> if test "x$TEARFREE" = "xyes"; then
> AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
> xp_msg="$xp_msg TearFree" <--- Line needs to be killed ???
> fi
> ...
> if test -n "$xp_msg"; then
> echo "  Experimental support:$xp_msg"
> fi
> ...
>
> Thanks.
>
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742
> [2] 
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n927

See attached patch.

- Sedat -
From 8a65d6d78a2881f715e5fcbc86b236889eb7819a Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.di...@gmail.com>
Date: Thu, 24 Mar 2016 12:03:49 +0100
Subject: [PATCH] configure: TearFree: Remove "Experimental support" status

Signed-off-by: Sedat Dilek <sedat.di...@gmail.com>
---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b121515fdf8f..840fb3d96947 100644
--- a/configure.ac
+++ b/configure.ac
@@ -743,7 +743,6 @@ AC_ARG_ENABLE(tear-free,
 	  [TEARFREE="no"])
 if test "x$TEARFREE" = "xyes"; then
 	AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
-	xp_msg="$xp_msg TearFree"
 fi
 
 AC_ARG_ENABLE(create2,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1

[Sedat Dilek]

On Thu, Mar 24, 2016 at 12:01 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Thu, Mar 24, 2016 at 11:44:45AM +0100, Sedat Dilek wrote:
>> [ Please see attached files (build-script, full logs etc.) ]
>>
>> With my selfmade llvm-toolchain v3.8.0 I see these errors/warnings...
>
>> conftest.c:(.text+0x12): undefined reference to `strlcpy'
>> clang-3.8: error: linker command failed with exit code 1 (use -v to
>> see invocation)
>
> We don't even use strlcat!  Try:
>
> diff --git a/configure.ac b/configure.ac
> index c18ad96..b121515 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -62,9 +62,6 @@ AC_DISABLE_STATIC
>  AC_PROG_LIBTOOL
>  AC_SYS_LARGEFILE
>
> -# Check for common libc routines redefined by os.h
> -AC_CHECK_FUNCS([strlcpy strlcat strndup], [], [])
> -
>  # Platform specific settings
>  case $host_os in
>*linux*)
>
>

So I collected all three "issues" here and sent you the generated logs.

Hope this helps.

Feel free to add my credits.

- Sedat -
From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.di...@gmail.com>
Date: Thu, 24 Mar 2016 12:01:37 +0100
Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
 automake problem

---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index c60e8a729271..396f41fdc4df 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@
 #  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
+ACLOCAL_AMFLAGS = -I m4
 
 SUBDIRS = man libobj xvmc src tools
 
-- 
2.7.4

From 7677aa3c3b6e1105ce7784bfb8d1a3b9233059ba Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.di...@gmail.com>
Date: Thu, 24 Mar 2016 12:03:49 +0100
Subject: [PATCH 2/3] configure: TearFree: Remove "Experimental support" status

---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index c18ad96c26d1..0457d52c04df 100644
--- a/configure.ac
+++ b/configure.ac
@@ -746,7 +746,6 @@ AC_ARG_ENABLE(tear-free,
 	  [TEARFREE="no"])
 if test "x$TEARFREE" = "xyes"; then
 	AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
-	xp_msg="$xp_msg TearFree"
 fi
 
 AC_ARG_ENABLE(create2,
-- 
2.7.4

From 1f951b5d65bc9b5b78606f06025a78facd5b402d Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.di...@gmail.com>
Date: Thu, 24 Mar 2016 12:05:25 +0100
Subject: [PATCH 3/3] configure: Remove unused common libc routines check

---
 configure.ac | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0457d52c04df..840fb3d96947 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,9 +62,6 @@ AC_DISABLE_STATIC
 AC_PROG_LIBTOOL
 AC_SYS_LARGEFILE
 
-# Check for common libc routines redefined by os.h
-AC_CHECK_FUNCS([strlcpy strlcat strndup], [], [])
-
 # Platform specific settings
 case $host_os in
   *linux*)
-- 
2.7.4



config.log.gz
Description: GNU Zip compressed data


configure-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_configure-fixes_llvm-3-8-0.txt.gz
Description: GNU Zip compressed data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [intelddx] TearFree still status "Experimental support"?

[Sedat Dilek]

Hi Chris,

is TearFree feature still "experimental" in current xf86-video-intel.git#master?
It is enabled by default!

[ configure-log ]
...
xf86-video-intel 2.99.917 will be compiled with:
  Xorg Video ABI version: 15.0 (xorg-server-1.15.1)
  pixman version: pixman-1-0.30.2
  Acceleration backends: none *sna uxa
  Additional debugging support? valgrind
  Support for Kernel Mode Setting? yes
  Support for legacy User Mode Setting (for i810)? yes
  Support for Direct Rendering Infrastructure: *DRI2
  Support for Xv motion compensation (XvMC and libXvMC): yes
  Support for display hotplug notifications (udev): yes
  Build additional tools and utilities? xf86-video-intel-backlight-helper
  Experimental support: TearFree <--- XXX
...

[ configure.ac ]
...
AC_ARG_ENABLE(tear-free,
 AS_HELP_STRING([--enable-tear-free],
[Enable use of TearFree by default [default=no]]),
 [TEARFREE="$enableval"],
 [TEARFREE="no"])
if test "x$TEARFREE" = "xyes"; then
AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default])
xp_msg="$xp_msg TearFree" <--- Line needs to be killed ???
fi
...
if test -n "$xp_msg"; then
echo "  Experimental support:$xp_msg"
fi
...

Thanks.

- Sedat -

[1] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742
[2] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n927
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1

[Sedat Dilek]

[ Please see attached files (build-script, full logs etc.) ]

With my selfmade llvm-toolchain v3.8.0 I see these errors/warnings...

$ egrep -B2 -i 'linker command failed|undefined reference to' config.log
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../..
-L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib
/tmp/conftest-467d35.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
/tmp/conftest-467d35.o: In function `main':
conftest.c:(.text+0x12): undefined reference to `strlcpy'
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)
--
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../..
-L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib
/tmp/conftest-934a03.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
/tmp/conftest-934a03.o: In function `main':
conftest.c:(.text+0x12): undefined reference to `strlcat'
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)
--
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../..
-L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib
/tmp/conftest-36ad4e.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
/tmp/conftest-36ad4e.o: In function `main':
conftest.c:(.text+0x12): undefined reference to `clock_gettime'
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)

Furthermore, my 'clang -v' output...

$ clang -v
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

If you need more inputs/informations, please let me know.

Hope this helps.

- Sedat -
diff --git a/Makefile.am b/Makefile.am
index c60e8a729271..396f41fdc4df 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@
 #  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
+ACLOCAL_AMFLAGS = -I m4
 
 SUBDIRS = man libobj xvmc src tools
 


config.log.gz
Description: GNU Zip compressed data


configure-intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
Description: GNU Zip compressed data


build_xf86-video-intel-with-llvm.sh
Description: Bourne shell script
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found

[Sedat Dilek]

On Thu, Mar 24, 2016 at 10:54 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
>> [ build-script, build and config logs attached ]
>>
>> Hi Chris,
>>
>> I am just seeing this (or noticed for the first time, here on
>> Ubuntu/precise AMD64)...
>>
>> $ zgrep -A1 -B1 ACLOCAL_FLAGS:
>> build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
>> autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
>> sh: 1: ACLOCAL_FLAGS: not found
>> autoreconf: configure.ac: tracing
>> --
>> libtoolize: copying file `m4/lt~obsolete.m4'
>> sh: 1: ACLOCAL_FLAGS: not found
>> autoreconf: running: /usr/bin/autoconf
>>
>> What does this mean and it is ignore-able?
>
> libtool vs automake. Haven't found the right fix yet.
>
> If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
> I think that's what we'll have to do :|

[ TRYOUT ]

$ grep ACLOCAL -nr ./
./Makefile.am:21:ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4

I dropped ACLOCAL_FLAG part in Makefile.am (see attached diff) and get...

--- 
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_ACLOCAL_FLAGS-dropped_llvm-3-8-0.txt
2016-03-24 11:13:06.429252959 +0100
+++ 
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt
  2016-03-24 10:25:35.913229371 +0100
@@ -1,6 +1,7 @@
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
-autoreconf: running: aclocal -I m4
+autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
+sh: 1: ACLOCAL_FLAGS: not found
 autoreconf: configure.ac: tracing
 autoreconf: running: libtoolize --install --copy
 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
@@ -14,6 +15,7 @@ libtoolize: copying file `m4/ltoptions.m
 libtoolize: copying file `m4/ltsugar.m4'
 libtoolize: copying file `m4/ltversion.m4'
 libtoolize: copying file `m4/lt~obsolete.m4'
+sh: 1: ACLOCAL_FLAGS: not found
 autoreconf: running: /usr/bin/autoconf
 autoreconf: running: /usr/bin/autoheader
 autoreconf: running: automake --add-missing --copy --no-force

BTW, my libtool-version is 2.4.2-1ubuntu1.

configure-log is attached.

( In my config.log file I see an error with Clang v3.8.0 - I will send
a separate email. )

- Sedat -
diff --git a/Makefile.am b/Makefile.am
index c60e8a729271..396f41fdc4df 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@
 #  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
+ACLOCAL_AMFLAGS = -I m4
 
 SUBDIRS = man libobj xvmc src tools
 
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --install --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:35: installing `./missing'
benchmarks/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking dependency style of clang... gcc3
checking for clang option to accept ISO C99... none needed
checking how to run the C preprocessor... clang-cpp
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdi

Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found

[Sedat Dilek]

On Thu, Mar 24, 2016 at 10:54 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
>> [ build-script, build and config logs attached ]
>>
>> Hi Chris,
>>
>> I am just seeing this (or noticed for the first time, here on
>> Ubuntu/precise AMD64)...
>>
>> $ zgrep -A1 -B1 ACLOCAL_FLAGS:
>> build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
>> autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
>> sh: 1: ACLOCAL_FLAGS: not found
>> autoreconf: configure.ac: tracing
>> --
>> libtoolize: copying file `m4/lt~obsolete.m4'
>> sh: 1: ACLOCAL_FLAGS: not found
>> autoreconf: running: /usr/bin/autoconf
>>
>> What does this mean and it is ignore-able?
>
> libtool vs automake. Haven't found the right fix yet.
>
> If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
> I think that's what we'll have to do :|

As usual a fast reply - Thanks.

If you have a fix, I will try it.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found

[Sedat Dilek]

[ build-script, build and config logs attached ]

Hi Chris,

I am just seeing this (or noticed for the first time, here on
Ubuntu/precise AMD64)...

$ zgrep -A1 -B1 ACLOCAL_FLAGS:
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: configure.ac: tracing
--
libtoolize: copying file `m4/lt~obsolete.m4'
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: running: /usr/bin/autoconf

What does this mean and it is ignore-able?

Thanks.

Regards,
- Sedat -

P.S.: autoconf version mumbo-jumbo

$ dpkg -S /usr/bin/autoconf
autoconf: /usr/bin/autoconf

$ dpkg -l | grep autoconf
ii  autoconf2.68-1ubuntu2
 automatic configure script builder

- EOT -


build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
Description: GNU Zip compressed data


config.log.gz
Description: GNU Zip compressed data


build_xf86-video-intel-with-llvm.sh
Description: Bourne shell script
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Intel Graphics for Linux (Release Date: 16 Feb, 2016)

[Sedat Dilek]

Hi,

what packages with versions is recent "Intel Graphics for Linux"
(2016-02-16) shipping?
Version "2015q4" [2] was giving some detailed informations, but recent
version does not.
Its release-notes are pointing to a installer [3].

BTW, when will there be a new intel-ddx v2.99.918?

Thanks in advance.

Regards,
- Sedat -

[1] https://01.org/linuxgraphics
[2] https://01.org/linuxgraphics/downloads/2015q4-intel-graphics-stack-release
[3] https://01.org/linuxgraphics/downloads/intel-graphics-installer-linux-1.4.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1

[Sedat Dilek]

On Wed, Sep 23, 2015 at 11:37 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Wed, Sep 23, 2015 at 10:48 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan <shua...@osg.samsung.com> wrote:
>>> On 09/23/2015 02:56 AM, Daniel Vetter wrote:
>>>> Another regression for Jairo to track.
>>>> -Daniel
>>>
>>> Saw the same problem in 4.3-rc2 as well. Not a one time
>>> deal and easily reproducible.
>>>
>>
>> Looks like the patch "drm/i915: Add primary plane to mask if it's
>> visible" is the correct fix.
>> Did not try it.
>>
>> - sed@ -
>>
>> [1] 
>> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a
>>
>
> Pulled in d-i-f [1] on top of Linux v4.3-rc2 and the issue is gone.
>

The patch is now in Linus tree.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=721a09f7393de6c28a07516dccd654c6e995944a

> - sed@ -
>
> [1] http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes
>
>>> thanks,
>>> -- Shuah
>>>>
>>>> On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote:
>>>>> Hi,
>>>>>
>>>>> I have reported the same issue in [0]...
>>>>>
>>>>> You write in [1]...
>>>>>
>>>>> [ cut here ]
>>>>> WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377
>>>>> assert_planes_disabled+0xe4/0x150 [i915]()
>>>>> plane A assertion failure, should be disabled but not
>>>>> ...
>>>>>
>>>>> I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64.
>>>>>
>>>>> Regards,
>>>>> - Sedat -
>>>>>
>>>>> [0] http://marc.info/?t=14417666342=1=2
>>>>> [1] http://marc.info/?l=linux-kernel=144227950327112=2
>>>>
>>>
>>>
>>> --
>>> Shuah Khan
>>> Sr. Linux Kernel Developer
>>> Open Source Innovation Group
>>> Samsung Research America (Silicon Valley)
>>> shua...@osg.samsung.com | (970) 217-8978
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled

[Sedat Dilek]

On Sun, Sep 13, 2015 at 9:06 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> [ TO INTEL DRM DRIVERS maintainers ]
>>
>> Hi,
>>
>> out of curiosity and to play with the new bindeb-pkg make-target I
>> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
>> Debian-kernel packages.
>>
>> I see several bugs and call-traces.
>>
>> Two hit a warning in i915 (one snippet here, full dmesg-log and
>> kernel-config are attached).
>>
>> [   20.920943] [ cut here ]
>> [   20.920982] WARNING: CPU: 0 PID: 114 at
>> drivers/gpu/drm/i915/intel_display.c:1377
>> assert_planes_disabled+0xe4/0x150 [i915]()
>> [   20.920983] plane A assertion failure, should be disabled but not
>> [   20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi
>> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel
>> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm
>> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage
>> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit
>> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth
>> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea
>> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device
>> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst
>> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii
>> [   20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted
>> 4.2.0-10463.1-iniza-small #1
>> [   20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   20.921033] Workqueue: events_unbound async_run_entry_fn
>> [   20.921037]  a06a9d60 8800378af718 813df89b
>> 8800378af760
>> [   20.921039]  8800378af750 8107cdc6 8800c200
>> 
>> [   20.921042]   8800bf90b000 8800bf90b000
>> 8800378af7b0
>> [   20.921043] Call Trace:
>> [   20.921046]  [] dump_stack+0x4b/0x70
>> [   20.921050]  [] warn_slowpath_common+0x86/0xc0
>> [   20.921052]  [] warn_slowpath_fmt+0x4c/0x50
>> [   20.921081]  [] assert_planes_disabled+0xe4/0x150 [i915]
>> [   20.921106]  [] intel_disable_pipe+0x4f/0x2d0 [i915]
>> [   20.921129]  [] ironlake_crtc_disable+0x85/0x7d0 [i915]
>> [   20.921151]  [] ?
>> intel_crtc_disable_planes+0xde/0xf0 [i915]
>> [   20.921176]  [] intel_atomic_commit+0x108/0x1370 [i915]
>> [   20.921192]  [] ? drm_atomic_check_only+0x1d7/0x5a0 
>> [drm]
>> [   20.921205]  [] ?
>> drm_atomic_get_connector_state+0x49/0x110 [drm]
>> [   20.921216]  [] drm_atomic_commit+0x37/0x60 [drm]
>> [   20.921223]  []
>> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper]
>> [   20.921234]  []
>> drm_mode_set_config_internal+0x65/0x110 [drm]
>> [   20.921240]  [] restore_fbdev_mode+0xbe/0xe0
>> [drm_kms_helper]
>> [   20.921246]  []
>> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
>> [   20.921251]  [] drm_fb_helper_set_par+0x2d/0x50
>> [drm_kms_helper]
>> [   20.921280]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
>> [   20.921283]  [] fbcon_init+0x53e/0x5d0
>> [   20.921286]  [] visual_init+0xca/0x130
>> [   20.921289]  [] do_bind_con_driver+0x167/0x3a0
>> [   20.921292]  [] do_take_over_console+0xac/0x1d0
>> [   20.921294]  [] do_fbcon_takeover+0x57/0xb0
>> [   20.921296]  [] fbcon_event_notify+0x752/0x860
>> [   20.921299]  [] ? 
>> __blocking_notifier_call_chain+0x35/0x70
>> [   20.921301]  [] notifier_call_chain+0x5d/0x80
>> [   20.921304]  [] __blocking_notifier_call_chain+0x4d/0x70
>> [   20.921306]  [] blocking_notifier_call_chain+0x16/0x20
>> [   20.921308]  [] fb_notifier_call_chain+0x1b/0x20
>> [   20.921311]  [] register_framebuffer+0x204/0x330
>> [   20.921317]  []
>> drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper]
>> [   20.921344]  [] intel_fbdev_initial_config+0x1b/0x20 
>> [i915]
>> [   20.921346]  [] async_run_entry_fn+0x37/0xe0
>> [   20.921349]  [] process_one_work+0x1e1/0x620
>> [   20.921352]  [] ? process_one_work+0x156/0x620
>> [   20.921353]  [] worker_thread+0x69/0x480
>> [   20.921355]  [] ? cancel_delayed_work_sync+0x20/0x20
>> [   20.921357]  [] kthread+0x10a/0x120
>> [   20.921360]  [] ? kthread_create_on_node+0x200/0x200
>> [   20.921364]  [] ret_from_fork+0x3f/0x70
>> [   20.921366]  [] ? kthr

Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1

[Sedat Dilek]

On Wed, Sep 23, 2015 at 10:48 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan <shua...@osg.samsung.com> wrote:
>> On 09/23/2015 02:56 AM, Daniel Vetter wrote:
>>> Another regression for Jairo to track.
>>> -Daniel
>>
>> Saw the same problem in 4.3-rc2 as well. Not a one time
>> deal and easily reproducible.
>>
>
> Looks like the patch "drm/i915: Add primary plane to mask if it's
> visible" is the correct fix.
> Did not try it.
>
> - sed@ -
>
> [1] 
> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a
>

Pulled in d-i-f [1] on top of Linux v4.3-rc2 and the issue is gone.

- sed@ -

[1] http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes

>> thanks,
>> -- Shuah
>>>
>>> On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote:
>>>> Hi,
>>>>
>>>> I have reported the same issue in [0]...
>>>>
>>>> You write in [1]...
>>>>
>>>> [ cut here ]
>>>> WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377
>>>> assert_planes_disabled+0xe4/0x150 [i915]()
>>>> plane A assertion failure, should be disabled but not
>>>> ...
>>>>
>>>> I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64.
>>>>
>>>> Regards,
>>>> - Sedat -
>>>>
>>>> [0] http://marc.info/?t=14417666342=1=2
>>>> [1] http://marc.info/?l=linux-kernel=144227950327112=2
>>>
>>
>>
>> --
>> Shuah Khan
>> Sr. Linux Kernel Developer
>> Open Source Innovation Group
>> Samsung Research America (Silicon Valley)
>> shua...@osg.samsung.com | (970) 217-8978
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [regression] Re: [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled

[Sedat Dilek]

On Wed, Sep 23, 2015 at 9:18 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> Adding Jairo to track this regression.

Hi,

commit 721a09f7393de6c28a07516dccd654c6e995944a
"drm/i915: Add primary plane to mask if it's visible"

...pending in drm-intel.git#drm-intel-fixes fixes the issue here.

- sed@ -

[1] 
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a

> -Daniel
>
> On Wed, Sep 23, 2015 at 08:23:04AM +0200, Sedat Dilek wrote:
>> On Sun, Sep 13, 2015 at 9:06 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> > On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>> >> [ TO INTEL DRM DRIVERS maintainers ]
>> >>
>> >> Hi,
>> >>
>> >> out of curiosity and to play with the new bindeb-pkg make-target I
>> >> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
>> >> Debian-kernel packages.
>> >>
>> >> I see several bugs and call-traces.
>> >>
>> >> Two hit a warning in i915 (one snippet here, full dmesg-log and
>> >> kernel-config are attached).
>> >>
>> >> [   20.920943] [ cut here ]
>> >> [   20.920982] WARNING: CPU: 0 PID: 114 at
>> >> drivers/gpu/drm/i915/intel_display.c:1377
>> >> assert_planes_disabled+0xe4/0x150 [i915]()
>> >> [   20.920983] plane A assertion failure, should be disabled but not
>> >> [   20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi
>> >> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel
>> >> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm
>> >> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage
>> >> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit
>> >> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth
>> >> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea
>> >> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device
>> >> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst
>> >> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii
>> >> [   20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted
>> >> 4.2.0-10463.1-iniza-small #1
>> >> [   20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> >> [   20.921033] Workqueue: events_unbound async_run_entry_fn
>> >> [   20.921037]  a06a9d60 8800378af718 813df89b
>> >> 8800378af760
>> >> [   20.921039]  8800378af750 8107cdc6 8800c200
>> >> 
>> >> [   20.921042]   8800bf90b000 8800bf90b000
>> >> 8800378af7b0
>> >> [   20.921043] Call Trace:
>> >> [   20.921046]  [] dump_stack+0x4b/0x70
>> >> [   20.921050]  [] warn_slowpath_common+0x86/0xc0
>> >> [   20.921052]  [] warn_slowpath_fmt+0x4c/0x50
>> >> [   20.921081]  [] assert_planes_disabled+0xe4/0x150 
>> >> [i915]
>> >> [   20.921106]  [] intel_disable_pipe+0x4f/0x2d0 [i915]
>> >> [   20.921129]  [] ironlake_crtc_disable+0x85/0x7d0 
>> >> [i915]
>> >> [   20.921151]  [] ?
>> >> intel_crtc_disable_planes+0xde/0xf0 [i915]
>> >> [   20.921176]  [] intel_atomic_commit+0x108/0x1370 
>> >> [i915]
>> >> [   20.921192]  [] ? drm_atomic_check_only+0x1d7/0x5a0 
>> >> [drm]
>> >> [   20.921205]  [] ?
>> >> drm_atomic_get_connector_state+0x49/0x110 [drm]
>> >> [   20.921216]  [] drm_atomic_commit+0x37/0x60 [drm]
>> >> [   20.921223]  []
>> >> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper]
>> >> [   20.921234]  []
>> >> drm_mode_set_config_internal+0x65/0x110 [drm]
>> >> [   20.921240]  [] restore_fbdev_mode+0xbe/0xe0
>> >> [drm_kms_helper]
>> >> [   20.921246]  []
>> >> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
>> >> [   20.921251]  [] drm_fb_helper_set_par+0x2d/0x50
>> >> [drm_kms_helper]
>> >> [   20.921280]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
>> >> [   20.921283]  [] fbcon_init+0x53e/0x5d0
>> >> [   20.921286]  [] visual_init+0xca/0x130
>> >> [   20.921289]  [] do_bind_con_driver+0x167/0x3a0
>> >> [   20.921292]  [] do_take_ov

Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1

[Sedat Dilek]

On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan <shua...@osg.samsung.com> wrote:
> On 09/23/2015 02:56 AM, Daniel Vetter wrote:
>> Another regression for Jairo to track.
>> -Daniel
>
> Saw the same problem in 4.3-rc2 as well. Not a one time
> deal and easily reproducible.
>

Looks like the patch "drm/i915: Add primary plane to mask if it's
visible" is the correct fix.
Did not try it.

- sed@ -

[1] 
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a

> thanks,
> -- Shuah
>>
>> On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote:
>>> Hi,
>>>
>>> I have reported the same issue in [0]...
>>>
>>> You write in [1]...
>>>
>>> [ cut here ]
>>> WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377
>>> assert_planes_disabled+0xe4/0x150 [i915]()
>>> plane A assertion failure, should be disabled but not
>>> ...
>>>
>>> I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64.
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> [0] http://marc.info/?t=14417666342=1=2
>>> [1] http://marc.info/?l=linux-kernel=144227950327112=2
>>
>
>
> --
> Shuah Khan
> Sr. Linux Kernel Developer
> Open Source Innovation Group
> Samsung Research America (Silicon Valley)
> shua...@osg.samsung.com | (970) 217-8978
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"

[Sedat Dilek]

On Tue, Sep 22, 2015 at 11:27 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Tue, Sep 22, 2015 at 10:46:09AM +0200, Sedat Dilek wrote:
>> On Mon, Sep 21, 2015 at 2:52 PM, Chris Wilson <ch...@chris-wilson.co.uk> 
>> wrote:
>> > On Mon, Sep 21, 2015 at 02:48:03PM +0200, Sedat Dilek wrote:
>> >> On Mon, Sep 21, 2015 at 11:42 AM, Chris Wilson <ch...@chris-wilson.co.uk> 
>> >> wrote:
>> >> > On Sun, Sep 20, 2015 at 08:20:21PM +0200, Sedat Dilek wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8.
>> >> >>
>> >> >> I cannot see my LightDM login-manager, my system hangs in VT-1.
>> >> >>
>> >> >> When I revert...
>> >> >>
>> >> >> commit 650da13c7257019728cfca361dfcbe34a6c526ef
>> >> >> "sna: Coldplug unknown connections as well"
>> >> >
>> >> > All it is doing is a RRGetInfo() call after 2 seconds if the display
>> >> > manager hasn't already done so. Easiest step forward is to look at the
>> >> > ddx logs to see timings on who calls what and then try and get the
>> >> > lightdm + unity logs to see why they changed behaviour.
>> >> >
>> >>
>> >> Yes, I can look at the LightDM and Unity logs.
>> >> Shall I build my intelddx with debugging enabled?
>> >
>> > The only thing of interest will be the timings given by the full debug
>> > log. I don't expect to see a problem as such, but could be proven wrong.
>> >
>> >> >> ...everything is as usual.
>> >> >
>> >> > Apart from the kernel issue...
>> >> >
>> >>
>> >> Which kernel-issue?
>> >>
>> >> On shutdown and after LightDM closes, my system hangs 4ever in VT-1,
>> >> so reverting above commit does not really help.
>> >
>> > That ^ strongly suggests an issue lower down the stack.
>> >
>>
>> I have built my intelddx via...
>>
>> $ ./configure --prefix=/opt/xorg --disable-dri1 --enable-dri2
>> --disable-dri3 --disable-tear-free --enable-debug=full
>>
>> ...(for more see my config.log).
>>
>> And added the following boot-params to the 3.13.y-Ubuntu-kernel 
>> command-line...
>>
>> Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-64-generic
>> root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro drm.debug=7
>> log_buf_len=4M
>>
>> ...(for more see kern-log.txt and syslog.txt).
>>
>> My libdrm is v2.6.56 and mesa is v10.6.8 (for more see Xorg log).
>>
>> SNA ColdPlug seems to be activated...
>>
>> [32.436] sna_mode_coldplug()
>>
>> No sure where to look for LightDM and Unity logs.
>
> /var/log/lightdm/:0*
>

Hi,

I have...

$ LC_ALL=C ls /var/log/lightdm/
lightdm.log  x-0-greeter.log  x-0-greeter.log.old  x-0.log
x-1-greeter.log  x-1-greeter.log.old  x-1.log  x-2-greeter.log
x-2-greeter.log.old  x-2.log

> Not sure where unity ends up.
>
>> Hope this helps.
>
> It did,
>
> commit 31d42ed5637a1b2223d48d0db4d7c512b27aee07
> Author: Chris Wilson <ch...@chris-wilson.co.uk>
> Date:   Tue Sep 22 10:23:24 2015 +0100
>
> sna: Check for udev events before reading
>
> When performing RRGetInfo() we drain any pending uevents before checking
> the CRTC/connector statuses. However, some versions of libudev do a
> blocking read and so when we call RRGetInfo() from a Timer callback
> (outside of the usual sigtimer interrupts) that blocking read lasts
> indefinitely.
>
> Reported-by: Sedat Dilek <sedat.di...@gmail.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>

Yupp, this fixes the issue for me.

Merci.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"

[Sedat Dilek]

On Mon, Sep 21, 2015 at 11:42 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Sun, Sep 20, 2015 at 08:20:21PM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8.
>>
>> I cannot see my LightDM login-manager, my system hangs in VT-1.
>>
>> When I revert...
>>
>> commit 650da13c7257019728cfca361dfcbe34a6c526ef
>> "sna: Coldplug unknown connections as well"
>
> All it is doing is a RRGetInfo() call after 2 seconds if the display
> manager hasn't already done so. Easiest step forward is to look at the
> ddx logs to see timings on who calls what and then try and get the
> lightdm + unity logs to see why they changed behaviour.
>

Yes, I can look at the LightDM and Unity logs.
Shall I build my intelddx with debugging enabled?

>> ...everything is as usual.
>
> Apart from the kernel issue...
>

Which kernel-issue?

On shutdown and after LightDM closes, my system hangs 4ever in VT-1,
so reverting above commit does not really help.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Revert "sna: Coldplug unknown connections as well"

[Sedat Dilek]

Hi,

I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8.

I cannot see my LightDM login-manager, my system hangs in VT-1.

When I revert...

commit 650da13c7257019728cfca361dfcbe34a6c526ef
"sna: Coldplug unknown connections as well"

...everything is as usual.

Please let me know when you need more informations.

Regards,
- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"

[Sedat Dilek]

On Sun, Sep 20, 2015 at 8:20 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> Hi,
>
> I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8.
>
> I cannot see my LightDM login-manager, my system hangs in VT-1.
>
> When I revert...
>
> commit 650da13c7257019728cfca361dfcbe34a6c526ef
> "sna: Coldplug unknown connections as well"
>
> ...everything is as usual.
>
> Please let me know when you need more informations.
>

When doing a power-off... my machine hangs - after LightDM has
stopped/closed - in VT-1 - with this revert.

I will return to 2.99.917-459-g300319e2044c which was good here.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 4.3-rc1

[Sedat Dilek]

Hi,

I have reported the same issue in [0]...

You write in [1]...

[ cut here ]
WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377
assert_planes_disabled+0xe4/0x150 [i915]()
plane A assertion failure, should be disabled but not
...

I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64.

Regards,
- Sedat -

[0] http://marc.info/?t=14417666342=1=2
[1] http://marc.info/?l=linux-kernel=144227950327112=2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled

[Sedat Dilek]

On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> [ TO INTEL DRM DRIVERS maintainers ]
>
> Hi,
>
> out of curiosity and to play with the new bindeb-pkg make-target I
> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
> Debian-kernel packages.
>
> I see several bugs and call-traces.
>
> Two hit a warning in i915 (one snippet here, full dmesg-log and
> kernel-config are attached).
>
> [   20.920943] [ cut here ]
> [   20.920982] WARNING: CPU: 0 PID: 114 at
> drivers/gpu/drm/i915/intel_display.c:1377
> assert_planes_disabled+0xe4/0x150 [i915]()
> [   20.920983] plane A assertion failure, should be disabled but not
> [   20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel
> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm
> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage
> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit
> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth
> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea
> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device
> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst
> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii
> [   20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted
> 4.2.0-10463.1-iniza-small #1
> [   20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   20.921033] Workqueue: events_unbound async_run_entry_fn
> [   20.921037]  a06a9d60 8800378af718 813df89b
> 8800378af760
> [   20.921039]  8800378af750 8107cdc6 8800c200
> 
> [   20.921042]   8800bf90b000 8800bf90b000
> 8800378af7b0
> [   20.921043] Call Trace:
> [   20.921046]  [] dump_stack+0x4b/0x70
> [   20.921050]  [] warn_slowpath_common+0x86/0xc0
> [   20.921052]  [] warn_slowpath_fmt+0x4c/0x50
> [   20.921081]  [] assert_planes_disabled+0xe4/0x150 [i915]
> [   20.921106]  [] intel_disable_pipe+0x4f/0x2d0 [i915]
> [   20.921129]  [] ironlake_crtc_disable+0x85/0x7d0 [i915]
> [   20.921151]  [] ?
> intel_crtc_disable_planes+0xde/0xf0 [i915]
> [   20.921176]  [] intel_atomic_commit+0x108/0x1370 [i915]
> [   20.921192]  [] ? drm_atomic_check_only+0x1d7/0x5a0 [drm]
> [   20.921205]  [] ?
> drm_atomic_get_connector_state+0x49/0x110 [drm]
> [   20.921216]  [] drm_atomic_commit+0x37/0x60 [drm]
> [   20.921223]  []
> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper]
> [   20.921234]  []
> drm_mode_set_config_internal+0x65/0x110 [drm]
> [   20.921240]  [] restore_fbdev_mode+0xbe/0xe0
> [drm_kms_helper]
> [   20.921246]  []
> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
> [   20.921251]  [] drm_fb_helper_set_par+0x2d/0x50
> [drm_kms_helper]
> [   20.921280]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
> [   20.921283]  [] fbcon_init+0x53e/0x5d0
> [   20.921286]  [] visual_init+0xca/0x130
> [   20.921289]  [] do_bind_con_driver+0x167/0x3a0
> [   20.921292]  [] do_take_over_console+0xac/0x1d0
> [   20.921294]  [] do_fbcon_takeover+0x57/0xb0
> [   20.921296]  [] fbcon_event_notify+0x752/0x860
> [   20.921299]  [] ? 
> __blocking_notifier_call_chain+0x35/0x70
> [   20.921301]  [] notifier_call_chain+0x5d/0x80
> [   20.921304]  [] __blocking_notifier_call_chain+0x4d/0x70
> [   20.921306]  [] blocking_notifier_call_chain+0x16/0x20
> [   20.921308]  [] fb_notifier_call_chain+0x1b/0x20
> [   20.921311]  [] register_framebuffer+0x204/0x330
> [   20.921317]  []
> drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper]
> [   20.921344]  [] intel_fbdev_initial_config+0x1b/0x20 
> [i915]
> [   20.921346]  [] async_run_entry_fn+0x37/0xe0
> [   20.921349]  [] process_one_work+0x1e1/0x620
> [   20.921352]  [] ? process_one_work+0x156/0x620
> [   20.921353]  [] worker_thread+0x69/0x480
> [   20.921355]  [] ? cancel_delayed_work_sync+0x20/0x20
> [   20.921357]  [] kthread+0x10a/0x120
> [   20.921360]  [] ? kthread_create_on_node+0x200/0x200
> [   20.921364]  [] ret_from_fork+0x3f/0x70
> [   20.921366]  [] ? kthread_create_on_node+0x200/0x200
> [   20.921367] ---[ end trace 85fce5c152ff4528 ]---
>
> Some intelgfx hardware infos (see attached Xorg.0.log)...
>
> [27.487] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
> Graphics 3000
> [27.565] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) 
> backend
>
> Please have a look at it.
>
> If this is a known issue, please let me know and kindly point me to a
&g

Re: [Intel-gfx] [PATCH] ACPI / video: Fix circular lock dependency issue in the video-detect code

[Sedat Dilek]

On Fri, Aug 14, 2015 at 11:39 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:

 --f46d04447e7fc2306e051d3753a5
 Content-Type: text/plain; charset=UTF-8

 On Thu, Aug 13, 2015 at 6:53 PM, Hans de Goede hdego...@redhat.com wrote:
  Before this commit, the following would happen:
 
  a) acpi_video_get_backlight_type() gets called
  b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
  c) acpi_video_init_backlight_type() locks its function static init_mutex
  d) acpi_video_init_backlight_type() calls backlight_register_notifier()
  e) backlight_register_notifier() takes its notifier-chain lock
 
  And when the backlight notifier chain gets called we've:
 
  1) blocking_notifier_call_chain() gets called
  2) blocking_notifier_call_chain() takes the notifier-chain lock
  3) blocking_notifier_call_chain() calls acpi_video_backlight_notify()
  4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type()
  5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
  6) acpi_video_init_backlight_type() locks its function static init_mutex
 
  So in the first call sequence we have:
 
  a) init_mutex gets locked
  b) notifier-chain gets locked
 
  and in the second call sequence we have:
 
  1) notifier-chain gets locked
  2) init_mutex gets locked
 
  And we've a circular locking dependency. This specific locking dependency
  is fixable without using the big hammer otherwise known as a workqueue,
  but further analysis shows a similar problem with the backlight notifier
  chain lock vs register_count_mutex from drivers/acpi/acpi_video.c,
  and fixing that becomes problematic.
 
  So this commit simply fixes this with the big hammer, performance
  wise this is a non issue as we expect the work to get scheduled
  exactly zero or one times during normal system use.
 

 This patch on top of Linux v4.2-rc6 fixes the issue for me.

 Feel free to add my...

Reported-by: Sedat Dilek sedat.di...@gmail.com
Tested-by: Sedat Dilek sedat.di...@gmail.com

 Applied, thanks!


Thanks for carrying this one.
Isn't this a for-4.2/acpi-video-fixes?
Why did you apply this in your linux-next Git branch?

- sed@ -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=7231ed1a813e0a9d249bbbe58e66ca058aee83e1

 Rafael

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] ACPI / video: Fix circular lock dependency issue in the video-detect code

[Sedat Dilek]

On Fri, Aug 14, 2015 at 12:16 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Friday, August 14, 2015 11:36:41 AM Sedat Dilek wrote:
 On Fri, Aug 14, 2015 at 11:39 AM, Rafael J. Wysocki r...@rjwysocki.net 
 wrote:
  On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
 
  --f46d04447e7fc2306e051d3753a5
  Content-Type: text/plain; charset=UTF-8
 
  On Thu, Aug 13, 2015 at 6:53 PM, Hans de Goede hdego...@redhat.com 
  wrote:
   Before this commit, the following would happen:
  
   a) acpi_video_get_backlight_type() gets called
   b) acpi_video_get_backlight_type() calls 
   acpi_video_init_backlight_type()
   c) acpi_video_init_backlight_type() locks its function static init_mutex
   d) acpi_video_init_backlight_type() calls backlight_register_notifier()
   e) backlight_register_notifier() takes its notifier-chain lock
  
   And when the backlight notifier chain gets called we've:
  
   1) blocking_notifier_call_chain() gets called
   2) blocking_notifier_call_chain() takes the notifier-chain lock
   3) blocking_notifier_call_chain() calls acpi_video_backlight_notify()
   4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type()
   5) acpi_video_get_backlight_type() calls 
   acpi_video_init_backlight_type()
   6) acpi_video_init_backlight_type() locks its function static init_mutex
  
   So in the first call sequence we have:
  
   a) init_mutex gets locked
   b) notifier-chain gets locked
  
   and in the second call sequence we have:
  
   1) notifier-chain gets locked
   2) init_mutex gets locked
  
   And we've a circular locking dependency. This specific locking 
   dependency
   is fixable without using the big hammer otherwise known as a workqueue,
   but further analysis shows a similar problem with the backlight notifier
   chain lock vs register_count_mutex from drivers/acpi/acpi_video.c,
   and fixing that becomes problematic.
  
   So this commit simply fixes this with the big hammer, performance
   wise this is a non issue as we expect the work to get scheduled
   exactly zero or one times during normal system use.
  
 
  This patch on top of Linux v4.2-rc6 fixes the issue for me.
 
  Feel free to add my...
 
 Reported-by: Sedat Dilek sedat.di...@gmail.com
 Tested-by: Sedat Dilek sedat.di...@gmail.com
 
  Applied, thanks!
 

 Thanks for carrying this one.
 Isn't this a for-4.2/acpi-video-fixes?

 I have no branch like that.


I wanted to say it's for 4.2-rc7.

 Why did you apply this in your linux-next Git branch?

 Because that's what I do normally with patches I'm going to push to Linus.


OK, thanks.

- sed@ -

 Thanks,
 Rafael

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Sedat Dilek]

On Fri, Aug 14, 2015 at 10:24 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 13-08-15 16:33, Hans de Goede wrote:

 Hi,

 On 12-08-15 21:26, Ville Syrjälä wrote:

 On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:

 On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 Hi,

 this my first build of a 4.2-rcN Linux-kernel and I see this...


 Just FYI:

 I am *not* seeing this with drm-intel-nightly from below url.

 Also, I plan to test Linux v4.2-rc5.


 [ CC Linus ]

 Knock Knock Knock.

 This issue still remains here (with CONFIG_DRM_I915=m)...

 [   18.269792] ==
 [   18.269798] [ INFO: possible circular locking dependency detected ]
 [   18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
 [   18.269810] ---
 [   18.269816] modprobe/727 is trying to acquire lock:
 [   18.269822]  (init_mutex){+.+.+.}, at: [a0090f2d]
 acpi_video_get_backlight_type+0x17/0x164 [video]
 [   18.269840]
 [   18.269840] but task is already holding lock:
 [   18.269848]  ((backlight_notifier)-rwsem){..}, at:
 [810a6519] __blocking_notifier_call_chain+0x39/0x70
 [   18.269864]
 [   18.269864] which lock already depends on the new lock.
 [   18.269864]
 [   18.269875]
 [   18.269875] the existing dependency chain (in reverse order) is:
 [   18.269884]
 ...

 Full dmesg log and kernel-config attached.

 Shall I add Rusty and modules/modprobe folks?


 Just got back from vacation and was greeted by this same lockdep splat.

 On a hunch I reverted

 commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
 Author: Hans de Goede hdego...@redhat.com
 Date:   Tue Jun 16 16:27:52 2015 +0200

  ACPI / video: Move backlight notifier to video_detect.c

 and the problem seems to be gone. Hans, any thoughts?


 Looking into this atm, lockdep clearly is right.

 Sorry about this I have put a lot of thinking into avoiding
 these kind of issues with this patch-set, but I did not realize
 there was another lock hiding inside the notifier-chain.

 Further analysis shows that the lock inside the notifier-chain
 causes similar problems vs register_count_mutex from
 drivers/acpi/acpi_video.c. I'm working on a fix for this
 atm.


 Heh, look at what I just found (I'm shifting my work focus
 in the direction of nouveau) :

 https://bugzilla.redhat.com/show_bug.cgi?id=1152876

 So it looks like we have had the root cause of this issue
 for a long time already, maybe my recent backlight selection
 logic cleanup / rework has made it easier to trigger the
 lockdep warning for this though.

 Anyhow assuming people are ok with the fix I submitted
 yesterday we've a fix for this now.


Yay :-)

- sed@ -

 Regards,

 Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Sedat Dilek]

On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
 On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
 On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
  Hi,
 
  this my first build of a 4.2-rcN Linux-kernel and I see this...
 
 
  Just FYI:
 
  I am *not* seeing this with drm-intel-nightly from below url.
 
  Also, I plan to test Linux v4.2-rc5.
 

 [ CC Linus ]

 Knock Knock Knock.

 This issue still remains here (with CONFIG_DRM_I915=m)...

 [   18.269792] ==
 [   18.269798] [ INFO: possible circular locking dependency detected ]
 [   18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
 [   18.269810] ---
 [   18.269816] modprobe/727 is trying to acquire lock:
 [   18.269822]  (init_mutex){+.+.+.}, at: [a0090f2d]
 acpi_video_get_backlight_type+0x17/0x164 [video]
 [   18.269840]
 [   18.269840] but task is already holding lock:
 [   18.269848]  ((backlight_notifier)-rwsem){..}, at:
 [810a6519] __blocking_notifier_call_chain+0x39/0x70
 [   18.269864]
 [   18.269864] which lock already depends on the new lock.
 [   18.269864]
 [   18.269875]
 [   18.269875] the existing dependency chain (in reverse order) is:
 [   18.269884]
 ...

 Full dmesg log and kernel-config attached.

 Shall I add Rusty and modules/modprobe folks?

 Just got back from vacation and was greeted by this same lockdep splat.

 On a hunch I reverted

 commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
 Author: Hans de Goede hdego...@redhat.com
 Date:   Tue Jun 16 16:27:52 2015 +0200

 ACPI / video: Move backlight notifier to video_detect.c

 and the problem seems to be gone. Hans, any thoughts?


Reverting this commit on top of Linux v4.2-rc6 causes troubles here.

$ LC_ALL=C git revert 93a291dfaf9c328ca5a9cea1733af1
error: could not revert 93a291dfaf9c... ACPI / video: Move backlight
notifier to video_detect.c
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add paths' or 'git rm paths'
hint: and commit the result with 'git commit'

Provide a suitable patch and I test for you.

- Sedat -


 - Sedat -

  - Sedat -
 
  [1] 
  http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
  [2] 
  http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
 
  [   24.001043] [drm] Memory usable by graphics device = 2048M
  [   24.001118] [drm] Replacing VGA console driver
  [   24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  [   24.011646] [drm] Driver supports precise vblank timestamp query.
  [   24.012480] vgaarb: device changed decodes:
  PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
  [   24.028005]
  [   24.028014] ==
  [   24.028020] [ INFO: possible circular locking dependency detected ]
  [   24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
  [   24.028032] ---
  [   24.028038] modprobe/740 is trying to acquire lock:
  [   24.028043]  (init_mutex){+.+.+.}, at: [a006af2d]
  acpi_video_get_backlight_type+0x17/0x164 [video]
  [   24.028060]
  [   24.028060] but task is already holding lock:
  [   24.028068]  ((backlight_notifier)-rwsem){..}, at:
  [810a6499] __blocking_notifier_call_chain+0x39/0x70
  [   24.028083]
  [   24.028083] which lock already depends on the new lock.
  [   24.028083]
  [   24.028095]
  [   24.028095] the existing dependency chain (in reverse order) is:
  [   24.028103]
  [   24.028103] - #1 ((backlight_notifier)-rwsem){..}:
  [   24.028113][810da56f] lock_acquire+0xcf/0x280
  [   24.028121][817d6269] down_write+0x49/0x80
  [   24.028129][810a6611]
  blocking_notifier_chain_register+0x21/0xb0
  [   24.028138][814619f8] 
  backlight_register_notifier+0x18/0x20
  [   24.028147][a006b010]
  acpi_video_get_backlight_type+0xfa/0x164 [video]
  [   24.028158][a00a20e9] 0xa00a20e9
  [   24.028164][810020f8] do_one_initcall+0x88/0x1c0
  [   24.028172][817cc9d2] do_init_module+0x61/0x1ec
  [   24.028179][8111fb78] load_module+0x2008/0x25c0
  [   24.028187][81120256] SyS_init_module+0x126/0x140
  [   24.028194][817d8e32] 
  entry_SYSCALL_64_fastpath+0x16/0x7a
  [   24.028202]
  [   24.028202] - #0 (init_mutex){+.+.+.}:
  [   24.028211][810d989d] __lock_acquire+0x1f5d/0x21c0
  [   24.028218][810da56f] lock_acquire+0xcf/0x280
  [   24.028225][817d4275] mutex_lock_nested+0x65/0x3c0
  [   24.028233][a006af2d

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Sedat Dilek]

On Thu, Aug 13, 2015 at 4:33 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 12-08-15 21:26, Ville Syrjälä wrote:

 On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:

 On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 Hi,

 this my first build of a 4.2-rcN Linux-kernel and I see this...


 Just FYI:

 I am *not* seeing this with drm-intel-nightly from below url.

 Also, I plan to test Linux v4.2-rc5.


 [ CC Linus ]

 Knock Knock Knock.

 This issue still remains here (with CONFIG_DRM_I915=m)...

 [   18.269792] ==
 [   18.269798] [ INFO: possible circular locking dependency detected ]
 [   18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
 [   18.269810] ---
 [   18.269816] modprobe/727 is trying to acquire lock:
 [   18.269822]  (init_mutex){+.+.+.}, at: [a0090f2d]
 acpi_video_get_backlight_type+0x17/0x164 [video]
 [   18.269840]
 [   18.269840] but task is already holding lock:
 [   18.269848]  ((backlight_notifier)-rwsem){..}, at:
 [810a6519] __blocking_notifier_call_chain+0x39/0x70
 [   18.269864]
 [   18.269864] which lock already depends on the new lock.
 [   18.269864]
 [   18.269875]
 [   18.269875] the existing dependency chain (in reverse order) is:
 [   18.269884]
 ...

 Full dmesg log and kernel-config attached.

 Shall I add Rusty and modules/modprobe folks?


 Just got back from vacation and was greeted by this same lockdep splat.

 On a hunch I reverted

 commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
 Author: Hans de Goede hdego...@redhat.com
 Date:   Tue Jun 16 16:27:52 2015 +0200

  ACPI / video: Move backlight notifier to video_detect.c

 and the problem seems to be gone. Hans, any thoughts?


 Looking into this atm, lockdep clearly is right.

 Sorry about this I have put a lot of thinking into avoiding
 these kind of issues with this patch-set, but I did not realize
 there was another lock hiding inside the notifier-chain.

 Further analysis shows that the lock inside the notifier-chain
 causes similar problems vs register_count_mutex from
 drivers/acpi/acpi_video.c. I'm working on a fix for this
 atm.


[PATCH] ACPI / video: Fix circular lock dependency issue in the
video-detect code (see [1])

...fixes the issue for me.

- sed@ -

[1] https://patchwork.kernel.org/patch/7009441/

 Regards,

 Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Sedat Dilek]

On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 this my first build of a 4.2-rcN Linux-kernel and I see this...


Just FYI:

I am *not* seeing this with drm-intel-nightly from below url.

Also, I plan to test Linux v4.2-rc5.

- Sedat -

[1] 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
[2] 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb

 [   24.001043] [drm] Memory usable by graphics device = 2048M
 [   24.001118] [drm] Replacing VGA console driver
 [   24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [   24.011646] [drm] Driver supports precise vblank timestamp query.
 [   24.012480] vgaarb: device changed decodes:
 PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
 [   24.028005]
 [   24.028014] ==
 [   24.028020] [ INFO: possible circular locking dependency detected ]
 [   24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
 [   24.028032] ---
 [   24.028038] modprobe/740 is trying to acquire lock:
 [   24.028043]  (init_mutex){+.+.+.}, at: [a006af2d]
 acpi_video_get_backlight_type+0x17/0x164 [video]
 [   24.028060]
 [   24.028060] but task is already holding lock:
 [   24.028068]  ((backlight_notifier)-rwsem){..}, at:
 [810a6499] __blocking_notifier_call_chain+0x39/0x70
 [   24.028083]
 [   24.028083] which lock already depends on the new lock.
 [   24.028083]
 [   24.028095]
 [   24.028095] the existing dependency chain (in reverse order) is:
 [   24.028103]
 [   24.028103] - #1 ((backlight_notifier)-rwsem){..}:
 [   24.028113][810da56f] lock_acquire+0xcf/0x280
 [   24.028121][817d6269] down_write+0x49/0x80
 [   24.028129][810a6611]
 blocking_notifier_chain_register+0x21/0xb0
 [   24.028138][814619f8] 
 backlight_register_notifier+0x18/0x20
 [   24.028147][a006b010]
 acpi_video_get_backlight_type+0xfa/0x164 [video]
 [   24.028158][a00a20e9] 0xa00a20e9
 [   24.028164][810020f8] do_one_initcall+0x88/0x1c0
 [   24.028172][817cc9d2] do_init_module+0x61/0x1ec
 [   24.028179][8111fb78] load_module+0x2008/0x25c0
 [   24.028187][81120256] SyS_init_module+0x126/0x140
 [   24.028194][817d8e32] entry_SYSCALL_64_fastpath+0x16/0x7a
 [   24.028202]
 [   24.028202] - #0 (init_mutex){+.+.+.}:
 [   24.028211][810d989d] __lock_acquire+0x1f5d/0x21c0
 [   24.028218][810da56f] lock_acquire+0xcf/0x280
 [   24.028225][817d4275] mutex_lock_nested+0x65/0x3c0
 [   24.028233][a006af2d]
 acpi_video_get_backlight_type+0x17/0x164 [video]
 [   24.028243][a006b0b2]
 acpi_video_backlight_notify+0x19/0x2f [video]
 [   24.028253][810a629d] notifier_call_chain+0x5d/0x80
 [   24.028260][810a64b1]
 __blocking_notifier_call_chain+0x51/0x70
 [   24.028269][810a64e6]
 blocking_notifier_call_chain+0x16/0x20
 [   24.028278][81461d37] 
 backlight_device_register+0x197/0x240
 [   24.028286][a062bb23]
 intel_backlight_register+0xb3/0x180 [i915]
 [   24.028336][a05fe136]
 intel_modeset_gem_init+0x176/0x190 [i915]
 [   24.028371][a0633112] i915_driver_load+0xf12/0x14d0 
 [i915]
 [   24.028406][a00ec861] drm_dev_register+0xb1/0x100 [drm]
 [   24.028425][a00ef62d] drm_get_pci_dev+0x8d/0x1e0 [drm]
 [   24.028439][a057e1fb] i915_pci_probe+0x3b/0x60 [i915]
 [   24.028463][814317e5] local_pci_probe+0x45/0xa0
 [   24.028470][81432bad] pci_device_probe+0xcd/0x120
 [   24.028477][8152d3a6] driver_probe_device+0x136/0x2e0
 [   24.028485][8152d5e4] __driver_attach+0x94/0xa0
 [   24.028491][8152b336] bus_for_each_dev+0x66/0xa0
 [   24.028499][8152cede] driver_attach+0x1e/0x20
 [   24.028506][8152cad8] bus_add_driver+0x1b8/0x230
 [   24.028513][8152e580] driver_register+0x60/0xe0
 [   24.028520][814310a4] __pci_register_driver+0x64/0x70
 [   24.028527][a00ef860] drm_pci_init+0xe0/0x110 [drm]
 [   24.028540][a069a0a0] i915_init+0xa0/0xa8 [i915]
 [   24.028563][810020f8] do_one_initcall+0x88/0x1c0
 [   24.028570][817cc9d2] do_init_module+0x61/0x1ec
 [   24.028577][8111fb78] load_module+0x2008/0x25c0
 [   24.028584][81120256] SyS_init_module+0x126/0x140
 [   24.028591][817d8e32] entry_SYSCALL_64_fastpath+0x16/0x7a
 [   24.028598]
 [   24.028598] other info that might

Re: [Intel-gfx] [PATCH] sna: Correct misspelled cacheing-caching in comments

[Sedat Dilek]

On Wed, Jun 24, 2015 at 12:04 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Jun 23, 2015 at 07:45:42AM +0200, Sedat Dilek wrote:
 I have seen this typo once and added an entry to codespell's dictionary.txt 
 file.

 $ diff -uprN /usr/share/codespell/dictionary.txt.orig 
 /usr/share/codespell/dictionary.txt
 --- /usr/share/codespell/dictionary.txt.orig2015-06-09 
 20:49:25.0 +0200
 +++ /usr/share/codespell/dictionary.txt 2015-06-23 07:37:35.893689539 +0200
 @@ -625,6 +625,7 @@ burried-buried
  busineses-business, businesses,
  busness-business
  bussiness-business
 +cacheing-caching
  caculater-calculator
  cacuses-caucuses
  cahracters-characters

 There some other places where this typo occurs:

 [ src/sna/kgem.c ]

  298:static void assert_cacheing(struct kgem *kgem, struct kgem_bo *bo)
  324:#define assert_cacheing(kgem, bo)
 2455:  assert_cacheing(kgem, bo);
 2841:  assert_cacheing(kgem, bo);

 It's up to Chris what to do with this.

 I just can't get paste reading 'caching' as two hard Cs and so it feels
 weird.

 commit f414ed4e40292e91e9c6850fb01a26334e6b43c7
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Wed Jun 24 11:02:28 2015 +0100

 sna: Fix misspelling of caching

 Apply s/cacheing/caching/ because I am alone in my belief of how to
 spell cacheing correctly :)

 Suggested-by: Sedat Dilek sedat.di...@gmail.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk


Thanks.

Just FYI... codespell got it, now.

commit b003c6167fdf441d2ba89534d402015723b66560
Add misspelled cacheing-caching

- sed@ -

[1] 
https://github.com/lucasdemarchi/codespell/commit/b003c6167fdf441d2ba89534d402015723b66560
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] sna: Correct misspelled cacheing-caching in comments

[Sedat Dilek]

I have seen this typo once and added an entry to codespell's dictionary.txt 
file.

$ diff -uprN /usr/share/codespell/dictionary.txt.orig 
/usr/share/codespell/dictionary.txt
--- /usr/share/codespell/dictionary.txt.orig2015-06-09 20:49:25.0 
+0200
+++ /usr/share/codespell/dictionary.txt 2015-06-23 07:37:35.893689539 +0200
@@ -625,6 +625,7 @@ burried-buried
 busineses-business, businesses,
 busness-business
 bussiness-business
+cacheing-caching
 caculater-calculator
 cacuses-caucuses
 cahracters-characters

There some other places where this typo occurs:

[ src/sna/kgem.c ]

 298:static void assert_cacheing(struct kgem *kgem, struct kgem_bo *bo)
 324:#define assert_cacheing(kgem, bo)
2455:  assert_cacheing(kgem, bo);
2841:  assert_cacheing(kgem, bo);

It's up to Chris what to do with this.

Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
 src/sna/sna_dri2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 2cde0c6aa0dc..2a1f8475b735 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -228,7 +228,7 @@ sna_dri2_cache_bo(struct sna *sna,
if (!c)
goto err;
 
-   DBG((%s: cacheing handle=%d (name=%d, flags=%d, active_scanout=%d)\n, 
__FUNCTION__, bo-handle, name, flags, bo-active_scanout));
+   DBG((%s: caching handle=%d (name=%d, flags=%d, active_scanout=%d)\n, 
__FUNCTION__, bo-handle, name, flags, bo-active_scanout));
 
c-bo = bo;
c-name = name;
@@ -333,7 +333,7 @@ sna_dri2_get_back(struct sna *sna,
c-name = back-name;
c-flags = back-flags;
list_add(c-link, priv-cache);
-   DBG((%s: cacheing handle=%d (name=%d, flags=%d, 
active_scanout=%d)\n, __FUNCTION__, c-bo-handle, c-name, c-flags, 
c-bo-active_scanout));
+   DBG((%s: caching handle=%d (name=%d, flags=%d, 
active_scanout=%d)\n, __FUNCTION__, c-bo-handle, c-name, c-flags, 
c-bo-active_scanout));
}
} else {
if (c-link != priv-cache)
-- 
2.4.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Fix typos found with codespell v1.7

[Sedat Dilek]

To get codespell v1.7 check [2].

[1] https://github.com/lucasdemarchi/codespell
[2] https://github.com/lucasdemarchi/codespell/releases

Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
 NEWS| 14 +++---
 man/intel.man   |  4 ++--
 src/legacy/i810/i810_common.h   |  4 ++--
 src/legacy/i810/i810_hwmc.c |  2 +-
 src/legacy/i810/i810_reg.h  |  2 +-
 src/legacy/i810/xvmc/I810XvMC.c |  6 +++---
 src/render_program/exa_wm.g4i   |  2 +-
 src/sna/brw/brw_eu_emit.c   |  2 +-
 src/sna/gen7_render.c   |  2 +-
 src/sna/gen8_render.c   |  2 +-
 src/sna/kgem_debug_gen4.c   |  2 +-
 src/sna/kgem_debug_gen5.c   |  2 +-
 src/sna/kgem_debug_gen6.c   |  2 +-
 src/sna/sna_display.c   |  2 +-
 src/sna/sna_trapezoids_boxes.c  |  2 +-
 src/uxa/intel_memory.c  |  2 +-
 16 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/NEWS b/NEWS
index 604b9cce9d90..0e2003329f5c 100644
--- a/NEWS
+++ b/NEWS
@@ -21,7 +21,7 @@ should make one more snapshot before an imminent release.
Before kernel 3.19, O_NONBLOCK support is broken and so we must avoid
reading if we are not expecting an event.
 
- * Backwards compatibilty fix for fake triple buffering with PRIME and
+ * Backwards compatibility fix for fake triple buffering with PRIME and
Xorg-1.15
https://bugs.freedesktop.org/show_bug.cgi?id=85144#c12
 
@@ -51,7 +51,7 @@ should make one more snapshot before an imminent release.
 Snapshot 2.99.916 (2014-09-08)
 ==
 Quick update for MST in UXA - we need to hook up the RandR outputs for
-dynamicaly added connectors.
+dynamically added connectors.
 
 
 Snapshot 2.99.915 (2014-09-08)
@@ -503,7 +503,7 @@ release.
backlight property is queried whilst the connector is disabled
https://bugs.freedesktop.org/show_bug.cgi?id=70406
 
- * Pad GETCONNECTOR ioctl for compatability between 32/64-bit userspace
+ * Pad GETCONNECTOR ioctl for compatibility between 32/64-bit userspace
and kernel
 
  * Handle long glyph runs correctly
@@ -523,7 +523,7 @@ snapshot beforehand to push out the bug fixes from the last 
week.
 
  * Fix video output using sprites when changing the image size
 
- * Apply more restrictive tile constaints for 915g class devices
+ * Apply more restrictive tile constraints for 915g class devices

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1232546
 
  * Ensure all overlapping rectangles are drawn for XRenderFillRectangles
@@ -1132,7 +1132,7 @@ operation.
  * Explicitly prevent ring-switching for synchronized rendering to
scanouts (for vsync).
 
- * Clip dirty region to slave pixmaps (otherwise UDL is nigh unusuable)
+ * Clip dirty region to slave pixmaps (otherwise UDL is nigh unusable)
https://bugs.freedesktop.org/show_bug.cgi?id=59539
 
 
@@ -1226,7 +1226,7 @@ Release 2.20.15 (2012-12-03)
 
 And lo, enabling more of the common acceleration paths for gen4 revealed
 another lurking bug - something is wrong with how we prepare Y-tiling
-surfaces for rendering. For the time being, we can surreptiously disable
+surfaces for rendering. For the time being, we can surreptitiously disable
 them for gen4 and avoid hitting GPU hangs.
 
  * Avoid clobbering the render state after failing to convert the
@@ -1515,7 +1515,7 @@ Release 2.20.5 (2012-08-26)
 Another silly bug found, another small bugfix release. The goal was for
 the driver to bind to all Intel devices supported by the kernel.
 Unfortunately we were too successful and started claiming Pouslbo,
-Medfield and Cedarview devices which are still encumbered by propietary
+Medfield and Cedarview devices which are still encumbered by proprietary
 IP and not supported by this driver.
 
 Bugs fixed since 2.20.4:
diff --git a/man/intel.man b/man/intel.man
index 17515206478b..91fc6df32a1d 100644
--- a/man/intel.man
+++ b/man/intel.man
@@ -431,11 +431,11 @@ First DVI SDVO output
 Second DVI SDVO output
 
 .SS TMDS-1, TMDS-2, HDMI-1, HDMI-2
-DVI/HDMI outputs. Avaliable common properties include:
+DVI/HDMI outputs. Available common properties include:
 .TP
 \fBBROADCAST_RGB\fP - method used to set RGB color range
 Adjusting this property allows you to set RGB color range on each
-channel in order to match HDTV requirment(default 0 for full
+channel in order to match HDTV requirement(default 0 for full
 range). Setting 1 means RGB color range is 16-235, 0 means RGB color
 range is 0-255 on each channel.  (Full range is 0-255, not 16-235)
 
diff --git a/src/legacy/i810/i810_common.h b/src/legacy/i810/i810_common.h
index 4cc10e8b615a..8355708c1ec7 100644
--- a/src/legacy/i810/i810_common.h
+++ b/src/legacy/i810/i810_common.h
@@ -52,7 +52,7 @@
 
 #define ALIGN(i,m) (((i) + (m) - 1)  ~((m) - 1))
 
-/* Using usleep() makes things noticably slow. */
+/* Using usleep() makes things noticeably slow. */
 #if 0
 #define DELAY(x) usleep(x)
 #else
@@ -185,7 +185,7 @@ enum

Re: [Intel-gfx] [PATCH] Fix typos found with codespell v1.7

[Sedat Dilek]

On Tue, Jun 9, 2015 at 9:48 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Jun 09, 2015 at 09:14:35PM +0200, Sedat Dilek wrote:
 - *  Initialize the hardware motion compenstation extention for this
 + *  Initialize the hardware motion compenstation extension for this

 Did it miss the second mispelling on this line?

 Pushed, thanks for the spelling fixes.


You mean compensation?
AFAICS the shipped dictionary can be enhanced (or I have overseen this one).

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Fix typos found with codespell v1.7

[Sedat Dilek]

On Wed, Jun 10, 2015 at 12:01 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Jun 9, 2015 at 9:48 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Jun 09, 2015 at 09:14:35PM +0200, Sedat Dilek wrote:
 - *  Initialize the hardware motion compenstation extention for this
 + *  Initialize the hardware motion compenstation extension for this

 Did it miss the second mispelling on this line?

 Pushed, thanks for the spelling fixes.


 You mean compensation?
 AFAICS the shipped dictionary can be enhanced (or I have overseen this one).


# dpkg -L codespell | grep dict
/usr/share/codespell/dictionary.txt

# grep compensation /usr/share/codespell/dictionary.txt
compensantion-compensation

So you might add...

compenstation-compensation

...in /path/to/codespell/dictionary.txt file.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: Partly revert sna: Compilation fixes for stable distros

[Sedat Dilek]

On Fri, Jun 5, 2015 at 4:51 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 04:39:32PM +0200, Sedat Dilek wrote:
 On Fri, Jun 5, 2015 at 4:31 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, Jun 05, 2015 at 04:23:36PM +0200, Sedat Dilek wrote:
  Fixes a problem having no mouse cursor in the LightDM login-screen
  on Ubuntu/precise (see [1]).
 
  [1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/068096.html
 
  Fixes: 7d30ccea214b (sna: Compilation fixes for stable distros)
  Signed-off-by: Sedat Dilek sedat.di...@gmail.com
  ---
   src/sna/kgem.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/src/sna/kgem.c b/src/sna/kgem.c
  index de604b0f3d77..720644b26750 100644
  --- a/src/sna/kgem.c
  +++ b/src/sna/kgem.c
  @@ -140,7 +140,6 @@ search_snoop_cache(struct kgem *kgem, unsigned int 
  num_pages, unsigned flags);
   #define LOCAL_I915_PARAM_HAS_WT  27
   #define LOCAL_I915_PARAM_MMAP_VERSION30
 
  -#define LOCAL_I915_EXEC_BLT  (20)
   #define LOCAL_I915_EXEC_IS_PINNED(110)
   #define LOCAL_I915_EXEC_NO_RELOC (111)
   #define LOCAL_I915_EXEC_HANDLE_LUT   (112)
  @@ -1400,7 +1399,7 @@ static bool test_can_blt_y(struct kgem *kgem)
memset(execbuf, 0, sizeof(execbuf));
execbuf.buffers_ptr = (uintptr_t)object;
execbuf.buffer_count = 1;
  - execbuf.flags = LOCAL_I915_EXEC_BLT;
  + execbuf.flags = I915_EXEC_BLT;
 
  Again, I am confused. The effect is instead of executing on BLT we ended
  up on BSD. Which is fine for the purposes of this test and the test did
  succeed.
 
  What's the result of this function after your patch? It should still be
  true. So I think we are looking at a funky underlying bug here...
 

 How can I test that or check?

 diff --git a/src/sna/kgem.c b/src/sna/kgem.c
 index 2058364..66f0087 100644
 --- a/src/sna/kgem.c
 +++ b/src/sna/kgem.c
 @@ -1753,6 +1753,9 @@ no_context_switch(struct kgem *kgem, int new_mode)
 (void)new_mode;
  }

 +#undef DBG
 +#define DBG(x) ErrorF x
 +
  void kgem_init(struct kgem *kgem, int fd, struct pci_device *dev, unsigned 
 gen)
  {
 struct drm_i915_gem_get_aperture aperture;
 @@ -2054,6 +2057,9 @@ void kgem_init(struct kgem *kgem, int fd, struct 
 pci_device *dev, unsigned gen)
 kgem_init_swizzling(kgem);
  }

 +#undef DBG
 +#define DBG(x)
 +

 Then look for kgem_init: can blit to Y-tiled surfaces?


Got some other tuff to do this weekend and really have less time.
If it is that important to you, please let me know, then I will test.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

[ Please CC me I am not subscribed to this ML ]

Hi,

I have upgraded my llvm-toolchain to v3.6.1 and while at this updated
my Linux graphics driver stack on Ubuntu/precise AMD64.

This is the cool stuff...

libdrm-2-4-61
mesa-10-5-6 and mesa-10-5-6-24-g07aa6d78bbc9

GOOD: intelddx-2-99-917-312-ga6dd2655cb41
BAD: intelddx-2-99-917-338-g7d30ccea214b

When I switch to vt-1 and do a sudo service lightdm stop and start,
the mouse cursor is back in the lightdm login-screen.

I am here on Linux v4.1-rc6 if this matters.

Any idea what's going on?

If you need additional information, please let me know.

Regards,
- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

Culprit commit is sna: Compilation fixes for stable distros (see
attached files).

Reverting this commit fixes the issue for me.

$ git log --oneline -3
ee885de7ad39 Revert sna: Compilation fixes for stable distros
7d30ccea214b sna: Ensure compat_output is sane after sorting outputs
1525b0177862 intel-virtual-output: Fix cloning fixed mode outputs

- sed@ -

[1] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=d1bf75f155f87d3a14d647316a0ba1f40d3957a6

On Fri, Jun 5, 2015 at 1:05 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 12:56:48PM +0200, Sedat Dilek wrote:
 Attached are dmesg and X logs.
 Last thing I did was to kill lightdm service.

 Have more fun.

 Ok, no errors reported by the kernel and the cursor seems to be updating
 fine.

 There's a utility xf86-video-intel/tools/cursor which you can run to
 query the current X cursor. Might be a little tricky to run from
 lightdm - ssh in and faff around with xauth. If you can ssh in, also
 grabbing /sys/kernel/debug/dri/0/i915_display_info when the cursor is
 invisible would be useful as well.

 When it cools, bisect :)
 -Chris

 --
 Chris Wilson, Intel Open Source Technology Centre
git bisect start
# good: [e617c1941c4e5ee90b69221013aab799eace925d] sna: Force restoration of SW 
cursor after HW cursor fails
git bisect good e617c1941c4e5ee90b69221013aab799eace925d
# bad: [7d30ccea214b54879fe34f0cab123aa3dc1b362c] sna: Ensure compat_output is 
sane after sorting outputs
git bisect bad 7d30ccea214b54879fe34f0cab123aa3dc1b362c
# good: [e08589de09b2e27b86321473efd4f29e57a18371] sna: Disable tiling 
assertion with unknown swizzling and white lies
git bisect good e08589de09b2e27b86321473efd4f29e57a18371
# bad: [2fa48450c79a27cdd923faa690e5e8e772ae4dad] sna: Avoid using NULL pointer 
inside DBG
git bisect bad 2fa48450c79a27cdd923faa690e5e8e772ae4dad
# good: [7a371f6befb2e49acbaf59c7adec3bcbbfa32622] Merge branch 'master' of 
192.168.1.213:/usr/src/xf86-video-intel
git bisect good 7a371f6befb2e49acbaf59c7adec3bcbbfa32622
# bad: [189ad44c94f500f05264d1666b18a96c82cb25ee] sna/dri2: Only attempt to 
change tiling when required
git bisect bad 189ad44c94f500f05264d1666b18a96c82cb25ee
# bad: [d1bf75f155f87d3a14d647316a0ba1f40d3957a6] sna: Compilation fixes for 
stable distros
git bisect bad d1bf75f155f87d3a14d647316a0ba1f40d3957a6
# first bad commit: [d1bf75f155f87d3a14d647316a0ba1f40d3957a6] sna: Compilation 
fixes for stable distros
commit d1bf75f155f87d3a14d647316a0ba1f40d3957a6
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Jun 1 08:56:43 2015 +

sna: Compilation fixes for stable distros

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

On Fri, Jun 5, 2015 at 12:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 12:05:22PM +0200, Sedat Dilek wrote:
 Hi Chris,

 thanks for the quick reply.

 Attached are my kernel-config, dmesg and X logs plus my build-script.

 Hope this helps you.

 Haven't gone through with finetooth comb yet, but I didn't spot the red
 flag I was looking for in Xorg.log. Can you please reboot with
 drm.debug=7 log_buf_len=4M?


Will do...

 And I might as well warn you that there might a bisect request shortly...

Ohoh, bi-sect-ion @ 35 degree celsius here in
South-Wild-West-Germany... lido (open air bath/pool) waiting :-).

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

On Fri, Jun 5, 2015 at 2:09 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Fri, Jun 5, 2015 at 1:57 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Fri, Jun 5, 2015 at 1:51 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Fri, Jun 05, 2015 at 01:41:25PM +0200, Sedat Dilek wrote:
 Culprit commit is sna: Compilation fixes for stable distros (see
 attached files).

 Reverting this commit fixes the issue for me.

 $ git log --oneline -3
 ee885de7ad39 Revert sna: Compilation fixes for stable distros
 7d30ccea214b sna: Ensure compat_output is sane after sorting outputs
 1525b0177862 intel-virtual-output: Fix cloning fixed mode outputs

 * Scratches head.

 Can you send me your build log for HEAD? (Including the configure
 summary.)

 I am now even more puzzled.

 Pauvre tete, ca fait mal a la tete...


 config.log with clang -v set in the build-script.


clang-errors...

$ egrep -B1 'clang: error: linker' config.log
conftest.c:(.text+0x12): undefined reference to `strlcpy'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--
conftest.c:(.text+0x12): undefined reference to `strlcat'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--
conftest.c:(.text+0x12): undefined reference to `clock_gettime'
clang: error: linker command failed with exit code 1 (use -v to see invocation)


I tried to fix the clock_gettime clang-error by adding '-lrt' to $LIBS...

$ git diff
diff --git a/configure.ac b/configure.ac
index 0b6358b879e8..60b50c0724be 100644
--- a/configure.ac
+++ b/configure.ac
@@ -782,7 +782,7 @@ AC_ARG_ENABLE(valgrind,
   [VG=no])

 LIBS=
-AC_SEARCH_LIBS(clock_gettime, rt, [CLOCK_GETTIME_LIBS=$LIBS])
+AC_SEARCH_LIBS(clock_gettime, rt, [CLOCK_GETTIME_LIBS=$LIBS -lrt])
 AC_SUBST(CLOCK_GETTIME_LIBS)

 sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server`

...which did not help.

Cannot say what's wrong here with my llvm-toolchain.
I have attached my build-script.

Any idea?

- sed@ -


build_llvm-toolchain.sh
Description: Bourne shell script
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

On Fri, Jun 5, 2015 at 3:17 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Fri, Jun 5, 2015 at 2:09 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Fri, Jun 5, 2015 at 1:57 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Fri, Jun 5, 2015 at 1:51 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Fri, Jun 05, 2015 at 01:41:25PM +0200, Sedat Dilek wrote:
 Culprit commit is sna: Compilation fixes for stable distros (see
 attached files).

 Reverting this commit fixes the issue for me.

 $ git log --oneline -3
 ee885de7ad39 Revert sna: Compilation fixes for stable distros
 7d30ccea214b sna: Ensure compat_output is sane after sorting outputs
 1525b0177862 intel-virtual-output: Fix cloning fixed mode outputs

 * Scratches head.

 Can you send me your build log for HEAD? (Including the configure
 summary.)

 I am now even more puzzled.

 Pauvre tete, ca fait mal a la tete...


 config.log with clang -v set in the build-script.


 clang-errors...

 $ egrep -B1 'clang: error: linker' config.log
 conftest.c:(.text+0x12): undefined reference to `strlcpy'
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)
 --
 conftest.c:(.text+0x12): undefined reference to `strlcat'
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)
 --
 conftest.c:(.text+0x12): undefined reference to `clock_gettime'
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)


 I tried to fix the clock_gettime clang-error by adding '-lrt' to $LIBS...

 $ git diff
 diff --git a/configure.ac b/configure.ac
 index 0b6358b879e8..60b50c0724be 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -782,7 +782,7 @@ AC_ARG_ENABLE(valgrind,
[VG=no])

  LIBS=
 -AC_SEARCH_LIBS(clock_gettime, rt, [CLOCK_GETTIME_LIBS=$LIBS])
 +AC_SEARCH_LIBS(clock_gettime, rt, [CLOCK_GETTIME_LIBS=$LIBS -lrt])
  AC_SUBST(CLOCK_GETTIME_LIBS)

  sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server`

 ...which did not help.

 Cannot say what's wrong here with my llvm-toolchain.
 I have attached my build-script.

 Any idea?


I rechecked with the culprit commit reverted...

$ git log --oneline -3
86557c7f2cfa Revert sna: Compilation fixes for stable distros
7d30ccea214b sna: Ensure compat_output is sane after sorting outputs
1525b0177862 intel-virtual-output: Fix cloning fixed mode outputs

$ egrep -B1 'clang: error: linker' config.log
conftest.c:(.text+0x12): undefined reference to `strlcpy'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--
conftest.c:(.text+0x12): undefined reference to `strlcat'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--
conftest.c:(.text+0x12): undefined reference to `clock_gettime'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ egrep 'strlcpy|strlcat|clock_gettime' -nr config.log | grep ac_cv_
1832:ac_cv_func_strlcat=no
1833:ac_cv_func_strlcpy=no
1885:ac_cv_search_clock_gettime=-lrt

...so my llvm-toolchain seems to be OK.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

If I revert the first hunk of the culprit the issue is gone.

I will send a patch.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] sna: Partly revert sna: Compilation fixes for stable distros

[Sedat Dilek]

Fixes a problem having no mouse cursor in the LightDM login-screen
on Ubuntu/precise (see [1]).

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/068096.html

Fixes: 7d30ccea214b (sna: Compilation fixes for stable distros)
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
 src/sna/kgem.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index de604b0f3d77..720644b26750 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -140,7 +140,6 @@ search_snoop_cache(struct kgem *kgem, unsigned int 
num_pages, unsigned flags);
 #define LOCAL_I915_PARAM_HAS_WT27
 #define LOCAL_I915_PARAM_MMAP_VERSION  30
 
-#define LOCAL_I915_EXEC_BLT(20)
 #define LOCAL_I915_EXEC_IS_PINNED  (110)
 #define LOCAL_I915_EXEC_NO_RELOC   (111)
 #define LOCAL_I915_EXEC_HANDLE_LUT (112)
@@ -1400,7 +1399,7 @@ static bool test_can_blt_y(struct kgem *kgem)
memset(execbuf, 0, sizeof(execbuf));
execbuf.buffers_ptr = (uintptr_t)object;
execbuf.buffer_count = 1;
-   execbuf.flags = LOCAL_I915_EXEC_BLT;
+   execbuf.flags = I915_EXEC_BLT;
 
ret = do_ioctl(kgem-fd,
   DRM_IOCTL_I915_GEM_EXECBUFFER2,
-- 
2.4.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: Partly revert sna: Compilation fixes for stable distros

[Sedat Dilek]

On Fri, Jun 5, 2015 at 4:31 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 04:23:36PM +0200, Sedat Dilek wrote:
 Fixes a problem having no mouse cursor in the LightDM login-screen
 on Ubuntu/precise (see [1]).

 [1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/068096.html

 Fixes: 7d30ccea214b (sna: Compilation fixes for stable distros)
 Signed-off-by: Sedat Dilek sedat.di...@gmail.com
 ---
  src/sna/kgem.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/src/sna/kgem.c b/src/sna/kgem.c
 index de604b0f3d77..720644b26750 100644
 --- a/src/sna/kgem.c
 +++ b/src/sna/kgem.c
 @@ -140,7 +140,6 @@ search_snoop_cache(struct kgem *kgem, unsigned int 
 num_pages, unsigned flags);
  #define LOCAL_I915_PARAM_HAS_WT  27
  #define LOCAL_I915_PARAM_MMAP_VERSION30

 -#define LOCAL_I915_EXEC_BLT  (20)
  #define LOCAL_I915_EXEC_IS_PINNED(110)
  #define LOCAL_I915_EXEC_NO_RELOC (111)
  #define LOCAL_I915_EXEC_HANDLE_LUT   (112)
 @@ -1400,7 +1399,7 @@ static bool test_can_blt_y(struct kgem *kgem)
   memset(execbuf, 0, sizeof(execbuf));
   execbuf.buffers_ptr = (uintptr_t)object;
   execbuf.buffer_count = 1;
 - execbuf.flags = LOCAL_I915_EXEC_BLT;
 + execbuf.flags = I915_EXEC_BLT;

 Again, I am confused. The effect is instead of executing on BLT we ended
 up on BSD. Which is fine for the purposes of this test and the test did
 succeed.

 What's the result of this function after your patch? It should still be
 true. So I think we are looking at a funky underlying bug here...


How can I test that or check?

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: Partly revert sna: Compilation fixes for stable distros

[Sedat Dilek]

On Fri, Jun 5, 2015 at 4:51 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 04:39:32PM +0200, Sedat Dilek wrote:
 On Fri, Jun 5, 2015 at 4:31 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, Jun 05, 2015 at 04:23:36PM +0200, Sedat Dilek wrote:
  Fixes a problem having no mouse cursor in the LightDM login-screen
  on Ubuntu/precise (see [1]).
 
  [1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/068096.html
 
  Fixes: 7d30ccea214b (sna: Compilation fixes for stable distros)
  Signed-off-by: Sedat Dilek sedat.di...@gmail.com
  ---
   src/sna/kgem.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/src/sna/kgem.c b/src/sna/kgem.c
  index de604b0f3d77..720644b26750 100644
  --- a/src/sna/kgem.c
  +++ b/src/sna/kgem.c
  @@ -140,7 +140,6 @@ search_snoop_cache(struct kgem *kgem, unsigned int 
  num_pages, unsigned flags);
   #define LOCAL_I915_PARAM_HAS_WT  27
   #define LOCAL_I915_PARAM_MMAP_VERSION30
 
  -#define LOCAL_I915_EXEC_BLT  (20)
   #define LOCAL_I915_EXEC_IS_PINNED(110)
   #define LOCAL_I915_EXEC_NO_RELOC (111)
   #define LOCAL_I915_EXEC_HANDLE_LUT   (112)
  @@ -1400,7 +1399,7 @@ static bool test_can_blt_y(struct kgem *kgem)
memset(execbuf, 0, sizeof(execbuf));
execbuf.buffers_ptr = (uintptr_t)object;
execbuf.buffer_count = 1;
  - execbuf.flags = LOCAL_I915_EXEC_BLT;
  + execbuf.flags = I915_EXEC_BLT;
 
  Again, I am confused. The effect is instead of executing on BLT we ended
  up on BSD. Which is fine for the purposes of this test and the test did
  succeed.
 
  What's the result of this function after your patch? It should still be
  true. So I think we are looking at a funky underlying bug here...
 

 How can I test that or check?

 diff --git a/src/sna/kgem.c b/src/sna/kgem.c
 index 2058364..66f0087 100644
 --- a/src/sna/kgem.c
 +++ b/src/sna/kgem.c
 @@ -1753,6 +1753,9 @@ no_context_switch(struct kgem *kgem, int new_mode)
 (void)new_mode;
  }

 +#undef DBG
 +#define DBG(x) ErrorF x
 +
  void kgem_init(struct kgem *kgem, int fd, struct pci_device *dev, unsigned 
 gen)
  {
 struct drm_i915_gem_get_aperture aperture;
 @@ -2054,6 +2057,9 @@ void kgem_init(struct kgem *kgem, int fd, struct 
 pci_device *dev, unsigned gen)
 kgem_init_swizzling(kgem);
  }

 +#undef DBG
 +#define DBG(x)
 +

 Then look for kgem_init: can blit to Y-tiled surfaces?


I will look into that later, on the move to freibad.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No mouse cursor with intelddx-2-99-917-338-g7d30ccea214b at lightdm-login

[Sedat Dilek]

On Fri, Jun 5, 2015 at 4:27 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Jun 05, 2015 at 04:23:10PM +0200, Sedat Dilek wrote:
 If I revert the first hunk of the culprit the issue is gone.

 Oh, boy. I was blind. I knew I should have just used the ring ids..

 Thanks a lot for the investigation and patch.

intelddx-2-99-917-340-g4a67c534ab75 fixes the issue for me.

Thanks.

- sed@ -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.0-rc5] Warnings in drm_framebuffer_reference() and drm_atomic_check_only()

[Sedat Dilek]

On Fri, Mar 27, 2015 at 12:06 PM, Takashi Iwai ti...@suse.de wrote:
 At Fri, 27 Mar 2015 12:01:33 +0100,
 Sedat Dilek wrote:

 On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai ti...@suse.de wrote:
  At Wed, 25 Mar 2015 14:26:50 +0100,
  Daniel Vetter wrote:
 
  On Tue, Mar 24, 2015 at 07:09:03PM +0100, Sedat Dilek wrote:
   On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote:
Hi,
   
I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over
some warning in the drm area.
   
Please have a look...
   
  
   Hi Daniel,
  
Just to confirm: Both are new in -rc5 and haven't been around in -rc4?
   
  
   Yeah, rc4 was OK but with rc5 I have seen these warnings.
  
Also can you pls give -nightly a spin and see what happens there?
   
  
   drm-intel-nightly (2015y-03m-24d-09h-19m-43s UTC) pulled on top of rc5
   does not show any warnings in the drm | i915 area.
 
  drm-fixes has 2 cherry-picks from -next to address the worst offenders,
  there's one more which is waiting for confirmation:
 
  commit fb9981aa675eb7b398849915364916fd98833cfa
  Author: Damien Lespiau damien.lesp...@intel.com
  Date:   Thu Feb 5 19:24:25 2015 +
 
  drm/i915: Fix atomic state when reusing the firmware fb
 
  Please apply that commit from -next on top of drm-fixes and retest.
 
  The problem is introduced by the commit
  319c1d420a0b62d9dbb88104afebaabc968cdbfa
  drm/i915: Ensure plane-state-fb stays in sync with plane-fb
 
  Obviously it accesses the uninitialized kref in
  get_initial_plane_config().
 
  The commit in next
  f55548b5af87ebfc586ca75748947f1c1b1a4a52
  drm/i915: Don't try to reference the fb in get_initial_plane_config()
 
  fixes the bug itself, but it leads to another similar warnings.  For
  avoiding this, yet another cherry-picks (including the commit you
  mentioned above):
 
  fb9981aa675eb7b398849915364916fd98833cfa
  drm/i915: Fix atomic state when reusing the firmware fb
  2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0
  drm/i915: Store the initial framebuffer in initial_plane_config
 
  then warnings are finally gone.
 
  But, the second one can't be applied cleanly, so I had to adjust many
  codes manually by replacing primary fb references.
 
 
  Takashi

 Hi Takashi, hi Daniel,

 first of all thank you for your replies.
 The last days I did not use my notebook and will try
 drm-intel-fixes-2015-03-26.
 Takashi, is that Git branch on top of rc5 OK for you?

 The fixes have been already merged to Linus tree.



Thanks a lot.
( I looked only at drm-intel Git repository. )

- Sedat -

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c435c1e472ba344ee25f795f4807d4457e61f6c
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.0-rc5] Warnings in drm_framebuffer_reference() and drm_atomic_check_only()

[Sedat Dilek]

On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai ti...@suse.de wrote:
 At Wed, 25 Mar 2015 14:26:50 +0100,
 Daniel Vetter wrote:

 On Tue, Mar 24, 2015 at 07:09:03PM +0100, Sedat Dilek wrote:
  On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote:
   Hi,
  
   I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over
   some warning in the drm area.
  
   Please have a look...
  
 
  Hi Daniel,
 
   Just to confirm: Both are new in -rc5 and haven't been around in -rc4?
  
 
  Yeah, rc4 was OK but with rc5 I have seen these warnings.
 
   Also can you pls give -nightly a spin and see what happens there?
  
 
  drm-intel-nightly (2015y-03m-24d-09h-19m-43s UTC) pulled on top of rc5
  does not show any warnings in the drm | i915 area.

 drm-fixes has 2 cherry-picks from -next to address the worst offenders,
 there's one more which is waiting for confirmation:

 commit fb9981aa675eb7b398849915364916fd98833cfa
 Author: Damien Lespiau damien.lesp...@intel.com
 Date:   Thu Feb 5 19:24:25 2015 +

 drm/i915: Fix atomic state when reusing the firmware fb

 Please apply that commit from -next on top of drm-fixes and retest.

 The problem is introduced by the commit
 319c1d420a0b62d9dbb88104afebaabc968cdbfa
 drm/i915: Ensure plane-state-fb stays in sync with plane-fb

 Obviously it accesses the uninitialized kref in
 get_initial_plane_config().

 The commit in next
 f55548b5af87ebfc586ca75748947f1c1b1a4a52
 drm/i915: Don't try to reference the fb in get_initial_plane_config()

 fixes the bug itself, but it leads to another similar warnings.  For
 avoiding this, yet another cherry-picks (including the commit you
 mentioned above):

 fb9981aa675eb7b398849915364916fd98833cfa
 drm/i915: Fix atomic state when reusing the firmware fb
 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0
 drm/i915: Store the initial framebuffer in initial_plane_config

 then warnings are finally gone.

 But, the second one can't be applied cleanly, so I had to adjust many
 codes manually by replacing primary fb references.


 Takashi

Hi Takashi, hi Daniel,

first of all thank you for your replies.
The last days I did not use my notebook and will try
drm-intel-fixes-2015-03-26.
Takashi, is that Git branch on top of rc5 OK for you?

Regards,
- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linux v4.0-rc5] Warnings in drm_framebuffer_reference() and drm_atomic_check_only()

[Sedat Dilek]

On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote:
 Hi,

 I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over
 some warning in the drm area.

 Please have a look...


Hi Daniel,

 Just to confirm: Both are new in -rc5 and haven't been around in -rc4?


Yeah, rc4 was OK but with rc5 I have seen these warnings.

 Also can you pls give -nightly a spin and see what happens there?


drm-intel-nightly (2015y-03m-24d-09h-19m-43s UTC) pulled on top of rc5
does not show any warnings in the drm | i915 area.

Hope this helps you.

- Sedat -

 Thanks, Daniel


 Trace #1:

 [   19.429883] [ cut here ]
 [   19.429902] WARNING: CPU: 0 PID: 811 at include/linux/kref.h:47
 drm_framebuffer_reference+0x7a/0x90 [drm]()
 [   19.429904] Modules linked in: mac80211 i915(+) snd_hda_codec_hdmi
 snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel
 snd_hda_controller videobuf2_vmalloc snd_hda_codec videobuf2_memops
 rfcomm videobuf2_core bnep v4l2_common i2c_algo_bit cdc_ether
 snd_hwdep iwlwifi joydev parport_pc ppdev option videodev snd_pcm
 usb_wwan drm_kms_helper usbserial usbnet cfg80211 snd_seq_midi
 snd_seq_midi_event btusb snd_rawmidi bluetooth snd_seq drm snd_timer
 psmouse snd_seq_device snd serio_raw samsung_laptop video lpc_ich
 soundcore intel_rst wmi mac_hid lp binfmt_misc parport hid_generic
 usbhid hid r8169 mii usb_storage
 [   19.429947] CPU: 0 PID: 811 Comm: modprobe Not tainted
 4.0.0-rc5-1-iniza-small #1
 [   19.429949] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   19.429951]  a0131f44 8800c8d036e8 81769019
 
 [   19.429955]   8800c8d03728 810757ba
 8800c8d03718
 [   19.429958]  88011a3d11c0 8800c82cf040 8800c231
 8800c1a13000
 [   19.429962] Call Trace:
 [   19.429969]  [81769019] dump_stack+0x4c/0x65
 [   19.429973]  [810757ba] warn_slowpath_common+0x8a/0xc0
 [   19.429977]  [810758aa] warn_slowpath_null+0x1a/0x20
 [   19.429988]  [a010c18a] drm_framebuffer_reference+0x7a/0x90 
 [drm]
 [   19.430003]  [a011e90d] drm_atomic_set_fb_for_plane+0x2d/0x90 
 [drm]
 [   19.430037]  [a0461b48]
 ironlake_get_initial_plane_config+0x288/0x390 [i915]
 [   19.430041]  [810c494d] ? trace_hardirqs_on+0xd/0x10
 [   19.430068]  [a0472151] intel_modeset_init+0x9d1/0x1a50 [i915]
 [   19.430091]  [a0438d7a] ?
 ironlake_irq_postinstall+0xca/0x1b0 [i915]
 [   19.430101]  [a0103a12] ? drm_irq_install+0xc2/0x1a0 [drm]
 [   19.430130]  [a04a682b] i915_driver_load+0xf0b/0x1140 [i915]
 [   19.430134]  [810c470d] ? mark_held_locks+0x6d/0xa0
 [   19.430137]  [8176fe7e] ? __mutex_unlock_slowpath+0xce/0x220
 [   19.430140]  [810c470d] ? mark_held_locks+0x6d/0xa0
 [   19.430143]  [81772476] ? _raw_spin_unlock_irqrestore+0x36/0x70
 [   19.430147]  [810c489d] ? trace_hardirqs_on_caller+0x15d/0x200
 [   19.430151]  [810c494d] ? trace_hardirqs_on+0xd/0x10
 [   19.430161]  [a0106975] drm_dev_register+0xb5/0x110 [drm]
 [   19.430172]  [a0109a6d] drm_get_pci_dev+0x8d/0x200 [drm]
 [   19.430192]  [a03fe22b] i915_pci_probe+0x3b/0x60 [i915]
 [   19.430196]  [813ec7b5] local_pci_probe+0x45/0xa0
 [   19.430199]  [813edb65] ? pci_match_device+0xe5/0x110
 [   19.430202]  [813edca9] pci_device_probe+0xd9/0x130
 [   19.430206]  [814eb25f] driver_probe_device+0x7f/0x260
 [   19.430209]  [814eb523] __driver_attach+0xa3/0xb0
 [   19.430211]  [814eb480] ? __device_attach+0x40/0x40
 [   19.430215]  [814e9193] bus_for_each_dev+0x73/0xb0
 [   19.430218]  [814ead6e] driver_attach+0x1e/0x20
 [   19.430220]  [814ea9a8] bus_add_driver+0x178/0x230
 [   19.430223]  [814ebd94] driver_register+0x64/0xf0
 [   19.430226]  [813ec014] __pci_register_driver+0x64/0x70
 [   19.430237]  [a0109cda] drm_pci_init+0xfa/0x130 [drm]
 [   19.430240]  [a0506000] ? 0xa0506000
 [   19.430258]  [a05060a0] i915_init+0xa0/0xa8 [i915]
 [   19.430262]  [810020fc] do_one_initcall+0x8c/0x1d0
 [   19.430266]  [81767308] ? do_init_module+0x28/0x1ce
 [   19.430269]  [81767341] do_init_module+0x61/0x1ce
 [   19.430273]  [8110746c] load_module+0x1f6c/0x24b0
 [   19.430276]  [81103ae0] ? __symbol_put+0x40/0x40
 [   19.430281]  [81107a66] SyS_init_module+0xb6/0xe0
 [   19.430285]  [81772f4d] system_call_fastpath+0x16/0x1b
 [   19.430287] ---[ end trace a75358bf753fdfc1 ]---


 Trace #2:

 [   19.451698] [ cut here ]
 [   19.451723] WARNING: CPU: 3 PID: 80 at
 drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x33d/0x500
 [drm]()
 [   19.451780

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

Ping?

- Sedat -

On Fri, Nov 14, 2014 at 11:04 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Nov 13, 2014 at 04:28:46PM +0100, Sedat Dilek wrote:
 Hi,

 what is the status of drm-intel-wc-mmap patchset (#2 + #3)?
 I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1).
 Playing with that againt Linux v3.18-rc4.

 Waiting for the misssing testcases and remainig reviews. I tried to
 volunteer Akash for that, but apparently failed.
 -Daniel


 Regards,
 - Sedat -

 From 20a70ef5865104f35bc8e4cd11ca8ae3b7e6051a Mon Sep 17 00:00:00 2001
 From: Chris Wilson ch...@chris-wilson.co.uk
 Date: Tue, 4 Nov 2014 04:51:40 -0800
 Subject: [PATCH 1/3] drm/i915: Make the physical object coherent with GTT
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 Currently objects for which the hardware needs a contiguous physical
 address are allocated a shadow backing storage to satisfy the contraint.
 This shadow buffer is not wired into the normal obj-pages and so the
 physical object is incoherent with accesses via the GPU, GTT and CPU. By
 setting up the appropriate scatter-gather table, we can allow userspace
 to access the physical object via either a GTT mmaping of or by rendering
 into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
 storage coherent with the contiguous shadow is not yet possible.
 Fortuituously, CPU mmaps of objects requiring physical addresses are not
 expected to be coherent anyway.

 This allows the physical constraint of the GEM object to be transparent
 to userspace and allow it to efficiently render into or update them via
 the GTT and GPU.

 v2: Fix leak of pci handle spotted by Ville
 v3: Remove the now duplicate call to detach_phys_object during free.
 v4: Wait for rendering before pwrite. As this patch makes it possible to
 render into the phys object, we should make it correct as well!

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_dma.c |   3 +
  drivers/gpu/drm/i915/i915_drv.h |   6 +-
  drivers/gpu/drm/i915/i915_gem.c | 207 
 +++-
  include/uapi/drm/i915_drm.h |   1 +
  4 files changed, 150 insertions(+), 67 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c 
 b/drivers/gpu/drm/i915/i915_dma.c
 index 1403b01..9b08853 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1027,6 +1027,9 @@ static int i915_getparam(struct drm_device *dev, void 
 *data,
   case I915_PARAM_CMD_PARSER_VERSION:
   value = i915_cmd_parser_get_version();
   break;
 + case I915_PARAM_HAS_COHERENT_PHYS_GTT:
 + value = 1;
 + break;
   default:
   DRM_DEBUG(Unknown parameter %d\n, param-param);
   return -EINVAL;
 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 16a6f6d..0417784 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1864,10 +1864,10 @@ struct drm_i915_gem_object {
   unsigned long user_pin_count;
   struct drm_file *pin_filp;

 - /** for phy allocated objects */
 - struct drm_dma_handle *phys_handle;
 -
   union {
 + /** for phy allocated objects */
 + struct drm_dma_handle *phys_handle;
 +
   struct i915_gem_userptr {
   uintptr_t ptr;
   unsigned read_only :1;
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c
 index 28f91df..124ec85 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -208,40 +208,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, 
 void *data,
   return 0;
  }

 -static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
 +static int
 +i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
  {
 - drm_dma_handle_t *phys = obj-phys_handle;
 + struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
 + char *vaddr = obj-phys_handle-vaddr;
 + struct sg_table *st;
 + struct scatterlist *sg;
 + int i;

 - if (!phys)
 - return;
 + if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
 + return -EINVAL;
 +
 + for (i = 0; i  obj-base.size / PAGE_SIZE; i++) {
 + struct page *page;
 + char *src;
 +
 + page = shmem_read_mapping_page(mapping, i);
 + if (IS_ERR(page))
 + return PTR_ERR(page);
 +
 + src = kmap_atomic(page);
 + memcpy(vaddr, src, PAGE_SIZE);
 + drm_clflush_virt_range(vaddr, PAGE_SIZE);
 + kunmap_atomic(src

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Tue, Feb 3, 2015 at 8:24 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Feb 03, 2015 at 07:57:34PM +0100, Sedat Dilek wrote:
 Ping?

 It's upstream and enabled by default for kernel v3.20+.


Thanks, I have looked into Linux-next (next-20150203) and see both patches:

commit 43566dedde54f9729113f5f9fde77d53e75e61e9
drm/i915: Broaden application of set-domain(GTT)

commit 1816f92363036600f2387bb8273b1e5e1f5b304e
drm/i915: Support creation of unbound wc user mappings for objects

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=43566dedde54f9729113f5f9fde77d53e75e61e9
[2] 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=1816f92363036600f2387bb8273b1e5e1f5b304e
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Fri, Nov 14, 2014 at 11:04 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Nov 13, 2014 at 04:28:46PM +0100, Sedat Dilek wrote:
 Hi,

 what is the status of drm-intel-wc-mmap patchset (#2 + #3)?
 I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1).
 Playing with that againt Linux v3.18-rc4.

 Waiting for the misssing testcases and remainig reviews. I tried to
 volunteer Akash for that, but apparently failed.

Hiho Daniel :-),

what can you recommend for testing gfx performance?
Chris did some remark about only 4M(ops) with x11perf.

What are your experiences with diverse compilers?
Here I use a prebuilt-toolchain LLVM/Clang v3.4.2 toolchain from
llvm.org, this is my default compiler.
Also I have here a gcc v4.9.2 in a /opt/gcc-4.9 environment.
Default in Ubuntu/precise is gcc v4.6.3.

Note: All my /opt/xorg stuff (currently: libdrm | mesa3d | intelddx)
is compiled with LLVM.

Has intel-gpu-tools some sort of performance testing included?

Any other hints qre very much appreciated.

Thanks!

Regards,
- Sedat -

 -Daniel


 Regards,
 - Sedat -

 From 20a70ef5865104f35bc8e4cd11ca8ae3b7e6051a Mon Sep 17 00:00:00 2001
 From: Chris Wilson ch...@chris-wilson.co.uk
 Date: Tue, 4 Nov 2014 04:51:40 -0800
 Subject: [PATCH 1/3] drm/i915: Make the physical object coherent with GTT
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 Currently objects for which the hardware needs a contiguous physical
 address are allocated a shadow backing storage to satisfy the contraint.
 This shadow buffer is not wired into the normal obj-pages and so the
 physical object is incoherent with accesses via the GPU, GTT and CPU. By
 setting up the appropriate scatter-gather table, we can allow userspace
 to access the physical object via either a GTT mmaping of or by rendering
 into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
 storage coherent with the contiguous shadow is not yet possible.
 Fortuituously, CPU mmaps of objects requiring physical addresses are not
 expected to be coherent anyway.

 This allows the physical constraint of the GEM object to be transparent
 to userspace and allow it to efficiently render into or update them via
 the GTT and GPU.

 v2: Fix leak of pci handle spotted by Ville
 v3: Remove the now duplicate call to detach_phys_object during free.
 v4: Wait for rendering before pwrite. As this patch makes it possible to
 render into the phys object, we should make it correct as well!

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_dma.c |   3 +
  drivers/gpu/drm/i915/i915_drv.h |   6 +-
  drivers/gpu/drm/i915/i915_gem.c | 207 
 +++-
  include/uapi/drm/i915_drm.h |   1 +
  4 files changed, 150 insertions(+), 67 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_dma.c 
 b/drivers/gpu/drm/i915/i915_dma.c
 index 1403b01..9b08853 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1027,6 +1027,9 @@ static int i915_getparam(struct drm_device *dev, void 
 *data,
   case I915_PARAM_CMD_PARSER_VERSION:
   value = i915_cmd_parser_get_version();
   break;
 + case I915_PARAM_HAS_COHERENT_PHYS_GTT:
 + value = 1;
 + break;
   default:
   DRM_DEBUG(Unknown parameter %d\n, param-param);
   return -EINVAL;
 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 16a6f6d..0417784 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1864,10 +1864,10 @@ struct drm_i915_gem_object {
   unsigned long user_pin_count;
   struct drm_file *pin_filp;

 - /** for phy allocated objects */
 - struct drm_dma_handle *phys_handle;
 -
   union {
 + /** for phy allocated objects */
 + struct drm_dma_handle *phys_handle;
 +
   struct i915_gem_userptr {
   uintptr_t ptr;
   unsigned read_only :1;
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c
 index 28f91df..124ec85 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -208,40 +208,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, 
 void *data,
   return 0;
  }

 -static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
 +static int
 +i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
  {
 - drm_dma_handle_t *phys = obj-phys_handle;
 + struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
 + char *vaddr = obj-phys_handle-vaddr;
 + struct sg_table *st;
 + struct scatterlist *sg;
 + int i

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

Hi,

what is the status of drm-intel-wc-mmap patchset (#2 + #3)?
I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1).
Playing with that againt Linux v3.18-rc4.

Regards,
- Sedat -
From 20a70ef5865104f35bc8e4cd11ca8ae3b7e6051a Mon Sep 17 00:00:00 2001
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue, 4 Nov 2014 04:51:40 -0800
Subject: [PATCH 1/3] drm/i915: Make the physical object coherent with GTT
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.

This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.

v2: Fix leak of pci handle spotted by Ville
v3: Remove the now duplicate call to detach_phys_object during free.
v4: Wait for rendering before pwrite. As this patch makes it possible to
render into the phys object, we should make it correct as well!

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_dma.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   6 +-
 drivers/gpu/drm/i915/i915_gem.c | 207 +++-
 include/uapi/drm/i915_drm.h |   1 +
 4 files changed, 150 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 1403b01..9b08853 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1027,6 +1027,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 	case I915_PARAM_CMD_PARSER_VERSION:
 		value = i915_cmd_parser_get_version();
 		break;
+	case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+		value = 1;
+		break;
 	default:
 		DRM_DEBUG(Unknown parameter %d\n, param-param);
 		return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16a6f6d..0417784 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1864,10 +1864,10 @@ struct drm_i915_gem_object {
 	unsigned long user_pin_count;
 	struct drm_file *pin_filp;
 
-	/** for phy allocated objects */
-	struct drm_dma_handle *phys_handle;
-
 	union {
+		/** for phy allocated objects */
+		struct drm_dma_handle *phys_handle;
+
 		struct i915_gem_userptr {
 			uintptr_t ptr;
 			unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28f91df..124ec85 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -208,40 +208,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
 	return 0;
 }
 
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
 {
-	drm_dma_handle_t *phys = obj-phys_handle;
+	struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
+	char *vaddr = obj-phys_handle-vaddr;
+	struct sg_table *st;
+	struct scatterlist *sg;
+	int i;
 
-	if (!phys)
-		return;
+	if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+		return -EINVAL;
+
+	for (i = 0; i  obj-base.size / PAGE_SIZE; i++) {
+		struct page *page;
+		char *src;
+
+		page = shmem_read_mapping_page(mapping, i);
+		if (IS_ERR(page))
+			return PTR_ERR(page);
+
+		src = kmap_atomic(page);
+		memcpy(vaddr, src, PAGE_SIZE);
+		drm_clflush_virt_range(vaddr, PAGE_SIZE);
+		kunmap_atomic(src);
+
+		page_cache_release(page);
+		vaddr += PAGE_SIZE;
+	}
+
+	i915_gem_chipset_flush(obj-base.dev);
+
+	st = kmalloc(sizeof(*st), GFP_KERNEL);
+	if (st == NULL)
+		return -ENOMEM;
+
+	if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+		kfree(st);
+		return -ENOMEM;
+	}
+
+	sg = st-sgl;
+	sg-offset = 0;
+	sg-length = obj-base.size;
 
-	if (obj-madv == I915_MADV_WILLNEED) {
+	sg_dma_address(sg) = obj-phys_handle-busaddr;
+	sg_dma_len(sg) = obj-base.size;
+
+	obj-pages = st;
+	obj-has_dma_mapping = true;
+	return 0;
+}
+
+static void
+i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj)
+{
+	int ret;
+
+	BUG_ON(obj-madv == __I915_MADV_PURGED);
+
+	ret = i915_gem_object_set_to_cpu_domain(obj, true);
+	if (ret) {
+		/* In the event of a disaster, 

[Intel-gfx] [PATCH] sna: wc-mmap: Fix warning in configure

[Sedat Dilek]

This fixes the following warning due to a typo:

configure: WARNING: unrecognized options: --enable-wc-map
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index e5877c8..328b4e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -723,7 +723,7 @@ if test x$RENDERNODE = xyes; then
 fi
 
 AC_ARG_ENABLE(wc-mmap,
- AS_HELP_STRING([--enable-wc-map],
+ AS_HELP_STRING([--enable-wc-mmap],
 [Enable use of WriteCombining mmaps [default=no]]),
  [WC_MMAP=$enableval],
  [WC_MMAP=no])
-- 
2.1.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

Hi,

I am playing with wc-mmap [1]... (and sent a trivial patch [0]).

Inspecting my logs...

$ egrep 'wc|mmap'
logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt
  Experimental support: TearFree mmap(wc)

$ egrep -i 'wc|mmap|write|comb' /var/log/Xorg.0.log
[ EMPTY ]

TearFree [1] can be set via an option in xorg.conf.
Doing a very quick look into the sources, such a flag/option is not recognized.

How do I see if wc-mmap is enabled/active on my desktop?

Thanks in advance.

Regards,
- Sedat -

[0] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e96520327bd2ef4fbc7b7b5169a17b966d9f85f3
[1] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=87802b3402ec4a829c6507b4b78fcd03e30b6fe1
[2] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=717e00facd27696c6b8a1a6c343b2f94bfa2b59b
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote:
 Hi,

 I am playing with wc-mmap [1]... (and sent a trivial patch [0]).

 Inspecting my logs...

 $ egrep 'wc|mmap'
 logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt
   Experimental support: TearFree mmap(wc)

 $ egrep -i 'wc|mmap|write|comb' /var/log/Xorg.0.log
 [ EMPTY ]

 TearFree [1] can be set via an option in xorg.conf.
 Doing a very quick look into the sources, such a flag/option is not 
 recognized.

 How do I see if wc-mmap is enabled/active on my desktop?

 Er, hopefully you don't notice anything except it speeds up certain
 operations (quite considerably) :). You have to enable the DBG output to
 see it in action, as it is quite a lowlevel feature (i.e. how we
 interact with the kernel) and should not add any user visible features.
 However, it does also require the kernel patch for it to be enabled.

Can you point me to that kernel-patch?
Is Linux v3.18-rc2+ good enough or do I need d-i-l-n / d-i-n?

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote:
 On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote:
  Hi,
 
  I am playing with wc-mmap [1]... (and sent a trivial patch [0]).
 
  Inspecting my logs...
 
  $ egrep 'wc|mmap'
  logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt
Experimental support: TearFree mmap(wc)
 
  $ egrep -i 'wc|mmap|write|comb' /var/log/Xorg.0.log
  [ EMPTY ]
 
  TearFree [1] can be set via an option in xorg.conf.
  Doing a very quick look into the sources, such a flag/option is not 
  recognized.
 
  How do I see if wc-mmap is enabled/active on my desktop?
 
  Er, hopefully you don't notice anything except it speeds up certain
  operations (quite considerably) :). You have to enable the DBG output to
  see it in action, as it is quite a lowlevel feature (i.e. how we
  interact with the kernel) and should not add any user visible features.
  However, it does also require the kernel patch for it to be enabled.

 Can you point me to that kernel-patch?
 Is Linux v3.18-rc2+ good enough or do I need d-i-l-n / d-i-n?


Hmm... against which trees are those patches?

 http://patchwork.freedesktop.org/patch/35049/
drm/i915: Broaden application of set-domain(GTT)

...is not applicable against d-i-f or d-i-n.

 http://patchwork.freedesktop.org/patch/35471/
drm/i915: Support creation of unbound wc user mappings for objects

That's good for both.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Fri, Nov 7, 2014 at 12:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Nov 07, 2014 at 11:59:26AM +0100, Sedat Dilek wrote:
 On Fri, Nov 7, 2014 at 11:43 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, Nov 07, 2014 at 11:35:01AM +0100, Sedat Dilek wrote:
  On Fri, Nov 7, 2014 at 11:29 AM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   On Fri, Nov 07, 2014 at 11:08:41AM +0100, Sedat Dilek wrote:
   Hi,
  
   I am playing with wc-mmap [1]... (and sent a trivial patch [0]).
  
   Inspecting my logs...
  
   $ egrep 'wc|mmap'
   logs/build-and-install-log_XF86-Video-Intel-v2-99-916-137-g0aa2edb_WCMMAP_llvm-3-4-2.txt
 Experimental support: TearFree mmap(wc)
  
   $ egrep -i 'wc|mmap|write|comb' /var/log/Xorg.0.log
   [ EMPTY ]
  
   TearFree [1] can be set via an option in xorg.conf.
   Doing a very quick look into the sources, such a flag/option is not 
   recognized.
  
   How do I see if wc-mmap is enabled/active on my desktop?
  
   Er, hopefully you don't notice anything except it speeds up certain
   operations (quite considerably) :). You have to enable the DBG output to
   see it in action, as it is quite a lowlevel feature (i.e. how we
   interact with the kernel) and should not add any user visible features.
   However, it does also require the kernel patch for it to be enabled.
 
  Can you point me to that kernel-patch?
  Is Linux v3.18-rc2+ good enough or do I need d-i-l-n / d-i-n?
 

 Hmm... against which trees are those patches?

  http://patchwork.freedesktop.org/patch/35049/
 drm/i915: Broaden application of set-domain(GTT)

 ...is not applicable against d-i-f or d-i-n.

 Try
 http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightlyid=2b03060c7585df31e6e90fef91af4064769bf394

Here some numbers...

$ diff -uprN benchmarks/x11perf-aa10text_no-wcmmap.txt
benchmarks/x11perf-aa10text_wcmmap.txt
--- benchmarks/x11perf-aa10text_no-wcmmap.txt   2014-11-07
12:57:49.932264840 +0100
+++ benchmarks/x11perf-aa10text_wcmmap.txt  2014-11-07
12:53:17.028273399 +0100
@@ -2,16 +2,16 @@ $ x11perf -aa10text
 x11perf - X11 performance program, version 1.2
 The X.Org Foundation server version 11501000 on :0
 from fambox
-Fri Nov  7 12:56:29 2014
+Fri Nov  7 12:51:37 2014

-Sync time adjustment is 0.0814 msecs.
+Sync time adjustment is 0.0817 msecs.

-2400 reps @   0.0002 msec (442.0/sec): Char in 80-char aa
line (Charter 10)
-2400 reps @   0.0002 msec (442.0/sec): Char in 80-char aa
line (Charter 10)
-2400 reps @   0.0002 msec (438.0/sec): Char in 80-char aa
line (Charter 10)
-2400 reps @   0.0002 msec (441.0/sec): Char in 80-char aa
line (Charter 10)
-2400 reps @   0.0002 msec (441.0/sec): Char in 80-char aa
line (Charter 10)
-12000 trep @   0.0002 msec (441.0/sec): Char in 80-char aa
line (Charter 10)
+2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
line (Charter 10)
+2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
line (Charter 10)
+2400 reps @   0.0002 msec (448.0/sec): Char in 80-char aa
line (Charter 10)
+2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
line (Charter 10)
+2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
line (Charter 10)
+12000 trep @   0.0002 msec (449.0/sec): Char in 80-char aa
line (Charter 10)


 -dileks // 07-NOV-2014

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] sna: Experimental support for write-combining mmaps (wc-mmap)

[Sedat Dilek]

On Fri, Nov 7, 2014 at 1:10 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Nov 07, 2014 at 01:00:32PM +0100, Sedat Dilek wrote:
 Here some numbers...

 $ diff -uprN benchmarks/x11perf-aa10text_no-wcmmap.txt
 benchmarks/x11perf-aa10text_wcmmap.txt
 --- benchmarks/x11perf-aa10text_no-wcmmap.txt   2014-11-07
 12:57:49.932264840 +0100
 +++ benchmarks/x11perf-aa10text_wcmmap.txt  2014-11-07
 12:53:17.028273399 +0100
 @@ -2,16 +2,16 @@ $ x11perf -aa10text
  x11perf - X11 performance program, version 1.2
  The X.Org Foundation server version 11501000 on :0
  from fambox
 -Fri Nov  7 12:56:29 2014
 +Fri Nov  7 12:51:37 2014

 -Sync time adjustment is 0.0814 msecs.
 +Sync time adjustment is 0.0817 msecs.

 -2400 reps @   0.0002 msec (442.0/sec): Char in 80-char aa
 line (Charter 10)
 -2400 reps @   0.0002 msec (442.0/sec): Char in 80-char aa
 line (Charter 10)
 -2400 reps @   0.0002 msec (438.0/sec): Char in 80-char aa
 line (Charter 10)
 -2400 reps @   0.0002 msec (441.0/sec): Char in 80-char aa
 line (Charter 10)
 -2400 reps @   0.0002 msec (441.0/sec): Char in 80-char aa
 line (Charter 10)
 -12000 trep @   0.0002 msec (441.0/sec): Char in 80-char aa
 line (Charter 10)
 +2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
 line (Charter 10)
 +2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
 line (Charter 10)
 +2400 reps @   0.0002 msec (448.0/sec): Char in 80-char aa
 line (Charter 10)
 +2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
 line (Charter 10)
 +2400 reps @   0.0002 msec (449.0/sec): Char in 80-char aa
 line (Charter 10)
 +12000 trep @   0.0002 msec (449.0/sec): Char in 80-char aa
 line (Charter 10)

 Hmm, what hw is that? As 4M is a bit on the low side.

[  1378.132] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend

Building intel-ddx with --enable-debug=full I see now...

$ egrep -i 'wc' /var/log/Xorg.0.log
[  1378.126] kgem_init: has wc-mmapping? 1
[  1379.122] __kgem_bo_map__gtt_or_wc: handle=6
[  1379.159] __kgem_bo_map__gtt_or_wc: handle=6
[  1379.303] __kgem_bo_map__gtt_or_wc: handle=6

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] uxa: intel_sync_close() is only available when HAVE_DRI3

[Sedat Dilek]

On Mon, Sep 15, 2014 at 9:58 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Sat, Sep 13, 2014 at 07:45:01PM +0200, Sedat Dilek wrote:
 With LLVM v3.4.2 I got this error reported:
 ...
 intel_driver.c:1182:2: error: implicit declaration of function 
 'intel_sync_close' is invalid in C99 
 [-Werror,-Wimplicit-function-declaration]
 intel_sync_close(screen);
 ^
 In file included from intel_uxa.c:44:
 ./intel_glamor.h:92:1: warning: unused function 
 'intel_glamor_fd_from_pixmap' [-Wunused-function]
 intel_glamor_fd_from_pixmap(ScreenPtr screen,
 ^
 intel_driver.c:1182:2: note: did you mean 'intel_mode_close'?
 ./intel.h:356:13: note: 'intel_mode_close' declared here
 extern void intel_mode_close(intel_screen_private *intel);
 ...

 Looking at uxa/intel.h intel_sync_close() is only available when DRI3 is 
 supported.

 516: #if HAVE_DRI3
 517: Bool intel_sync_init(ScreenPtr screen);
 518: void intel_sync_close(ScreenPtr screen);
 519: #endif

 Fix the issue by embedding intel_sync_close() with a HAVE_DRI3 ifdef check.

 Signed-off-by: Sedat Dilek sedat.di...@gmail.com

 I went with a slightly different approach to keep the ifdefery out of
 the body:

 commit 067115a51b2646538a38ba603c688233c61e23cd
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Mon Sep 15 08:44:41 2014 +0100

 uxa: Stub out intel_sync_init|fini when not compiled in

 In order to fix the build without DRI3, we need to stub out the
 functions not compiled in, such as intel_sync_fini().

 Reported-by: Sedat Dilek sedat.di...@gmail.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

 Thanks for the bug report and patch,

Great!
I was thinking of adding stubs later, but I needed a fast dirty hack.

Thanks for the quick fix!

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] intel_driver.c:1182:2: error: implicit declaration of function 'intel_sync_close' is invalid in C99

[Sedat Dilek]

Building intel-ddx from GIT HEAD breaks here with LLVM v3.4.2 like this...
...
intel_driver.c:1182:2: error: implicit declaration of function
'intel_sync_close' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
intel_sync_close(screen);
^
In file included from intel_uxa.c:44:
./intel_glamor.h:92:1: warning: unused function
'intel_glamor_fd_from_pixmap' [-Wunused-function]
intel_glamor_fd_from_pixmap(ScreenPtr screen,
^
intel_driver.c:1182:2: note: did you mean 'intel_mode_close'?
./intel.h:356:13: note: 'intel_mode_close' declared here
extern void intel_mode_close(intel_screen_private *intel);
^
...

Please have a look at the full build-log.
Thanks.

- Sedat -

P:S:: GIT HEAD is here...

commit 48f6406a62c06a09b173d82b8eb79761188ff717 (Use intel_uxa.h in
all uxa-specific files)

P.S.S.: FYI... v2.99.916 is OK.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --install --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:35: installing `./missing'
libobj/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking dependency style of clang... gcc3
checking for clang option to accept ISO C99... none needed
checking how to run the C preprocessor... clang-cpp
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __clang__ is declared... yes
checking whether __INTEL_COMPILER is declared... no
checking whether __SUNPRO_C is declared... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking if clang supports -Werror=unknown-warning-option... yes
checking if clang supports -Werror=unused-command-line-argument... yes
checking if clang supports -Wall... yes
checking if clang supports -Wpointer-arith... yes
checking if clang supports -Wmissing-declarations... yes
checking if clang supports -Wformat=2... yes
checking if clang supports -Wstrict-prototypes... yes
checking if clang supports -Wmissing-prototypes... yes
checking if clang supports -Wnested-externs... yes
checking if clang supports -Wbad-function-cast... yes
checking if clang supports -Wold-style-definition... yes
checking if clang supports -Wdeclaration-after-statement... yes
checking if clang supports -Wunused... yes
checking if clang supports -Wuninitialized... yes
checking if clang supports -Wshadow... yes
checking if clang supports -Wcast-qual... yes
checking if clang supports -Wmissing-noreturn... yes
checking if clang supports -Wmissing-format-attribute... yes
checking if clang supports -Wredundant-decls... yes
checking if clang supports -Werror=implicit... yes
checking if clang supports -Werror=nonnull... yes
checking if clang supports -Werror=init-self... yes
checking if clang supports -Werror=main... yes
checking if clang supports -Werror=missing-braces... yes
checking if clang supports -Werror=sequence-point... yes
checking if clang supports -Werror=return-type... yes
checking if clang supports -Werror=trigraphs... yes
checking if clang supports -Werror=array-bounds... yes
checking if clang 

Re: [Intel-gfx] intel_driver.c:1182:2: error: implicit declaration of function 'intel_sync_close' is invalid in C99

[Sedat Dilek]

On Sat, Sep 13, 2014 at 7:15 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Building intel-ddx from GIT HEAD breaks here with LLVM v3.4.2 like this...
 ...
 intel_driver.c:1182:2: error: implicit declaration of function
 'intel_sync_close' is invalid in C99
 [-Werror,-Wimplicit-function-declaration]
 intel_sync_close(screen);
 ^
 In file included from intel_uxa.c:44:
 ./intel_glamor.h:92:1: warning: unused function
 'intel_glamor_fd_from_pixmap' [-Wunused-function]
 intel_glamor_fd_from_pixmap(ScreenPtr screen,
 ^
 intel_driver.c:1182:2: note: did you mean 'intel_mode_close'?
 ./intel.h:356:13: note: 'intel_mode_close' declared here
 extern void intel_mode_close(intel_screen_private *intel);
 ^
 ...

 Please have a look at the full build-log.
 Thanks.

 - Sedat -

 P:S:: GIT HEAD is here...

 commit 48f6406a62c06a09b173d82b8eb79761188ff717 (Use intel_uxa.h in
 all uxa-specific files)

 P.S.S.: FYI... v2.99.916 is OK.

Looking at the sources...

./src/uxa/intel.h-516-#if HAVE_DRI3
./src/uxa/intel.h-517-Bool intel_sync_init(ScreenPtr screen);
./src/uxa/intel.h:518:void intel_sync_close(ScreenPtr screen);
./src/uxa/intel.h-519-#endif

...and in my logs...

$ grep DRI3 
../logs/build-and-install-log_XF86-Video-Intel-v2-99-916-38-g48f6406_llvm-3-4-2.txt
checking for X11_DRI3... yes
checking if DRI3 is defined... no
checking whether to include DRI3 support... no

Then intel_sync_close() should be embedded into a HAVE_DRI3 check?

$ git diff
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index f31f7bd..9f527fd 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -1179,7 +1179,9 @@ static Bool I830CloseScreen(CLOSE_SCREEN_ARGS_DECL)
intel-dri3 = DRI_NONE;
}

+#if HAVE_DRI3
intel_sync_close(screen);
+#endif

xf86GARTCloseScreen(scrn-scrnIndex);

Regards,
- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] uxa: intel_sync_close() is only available when HAVE_DRI3

[Sedat Dilek]

With LLVM v3.4.2 I got this error reported:
...
intel_driver.c:1182:2: error: implicit declaration of function 
'intel_sync_close' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
intel_sync_close(screen);
^
In file included from intel_uxa.c:44:
./intel_glamor.h:92:1: warning: unused function 'intel_glamor_fd_from_pixmap' 
[-Wunused-function]
intel_glamor_fd_from_pixmap(ScreenPtr screen,
^
intel_driver.c:1182:2: note: did you mean 'intel_mode_close'?
./intel.h:356:13: note: 'intel_mode_close' declared here
extern void intel_mode_close(intel_screen_private *intel);
...

Looking at uxa/intel.h intel_sync_close() is only available when DRI3 is 
supported.

516: #if HAVE_DRI3
517: Bool intel_sync_init(ScreenPtr screen);
518: void intel_sync_close(ScreenPtr screen);
519: #endif

Fix the issue by embedding intel_sync_close() with a HAVE_DRI3 ifdef check.

Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
 src/uxa/intel_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index f31f7bd..9f527fd 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -1179,7 +1179,9 @@ static Bool I830CloseScreen(CLOSE_SCREEN_ARGS_DECL)
intel-dri3 = DRI_NONE;
}
 
+#if HAVE_DRI3
intel_sync_close(screen);
+#endif
 
xf86GARTCloseScreen(scrn-scrnIndex);
 
-- 
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] intelgfx-git: Tear-free disabled in the logs

[Sedat Dilek]

On Sat, Jun 7, 2014 at 4:08 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Sat, Jun 07, 2014 at 02:00:46PM +0200, Sedat Dilek wrote:
 On Sat, Jun 7, 2014 at 1:47 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  Hi,
 
  I am still playing with DRI3... beyond this I saw that TearFree option
  can be explicitly set (sna: Allow TearFree to be enabled by default
  via configure), now.
 

 I have added TearFree option to my /etc/X11/xorg.conf and still see...

 $ egrep -i 'sna|uxa|tear' /var/log/Xorg.0.log
 [  2501.150] (II) intel(0): SNA compiled from 2.99.911-275-g717e00f
 [  2501.151] (**) intel(0): Option AccelMethod sna
 [  2501.151] (**) intel(0): Option TearFree true
 [  2501.152] (**) intel(0): Tear free disabled
 [  2501.154] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) 
 backend

 That should be fine. I just broke the log by reporting TearFree before
 the test whether to enable it.

sna: Fix reporting of TearFree [1] fixes the issue for me.

- Sedat -

P.S.: Next time feel free to give appropriate credits (here:
Reported-by), thanks.

[1] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=ecd80a3a997b11307445c50621d4e86e241a5b22
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] intelgfx-git: Tear-free disabled in the logs

[Sedat Dilek]

On Sat, Jun 7, 2014 at 1:47 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 I am still playing with DRI3... beyond this I saw that TearFree option
 can be explicitly set (sna: Allow TearFree to be enabled by default
 via configure), now.


I have added TearFree option to my /etc/X11/xorg.conf and still see...

$ egrep -i 'sna|uxa|tear' /var/log/Xorg.0.log
[  2501.150] (II) intel(0): SNA compiled from 2.99.911-275-g717e00f
[  2501.151] (**) intel(0): Option AccelMethod sna
[  2501.151] (**) intel(0): Option TearFree true
[  2501.152] (**) intel(0): Tear free disabled
[  2501.154] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend

- Sedat -


xorg.conf_intelddx-sna_tearfree
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] intelgfx-git: Tear-free disabled in the logs

[Sedat Dilek]

On Sat, Jun 7, 2014 at 1:47 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 I am still playing with DRI3... beyond this I saw that TearFree option
 can be explicitly set (sna: Allow TearFree to be enabled by default
 via configure), now.

[...]
 Do I need some special requirements to have Tear-Free running here?
 ( For example: Linux-kernel and/or Linux-GfxStack, etc. )


Still the same with d-i-n kernel from Ubuntu kernel-team.

- Sedat -

[1] 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/linux-image-3.15.0-997-generic_3.15.0-997.201406070420_amd64.deb
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Running DRI3 on intel-gfx

[Sedat Dilek]

On Fri, Jun 6, 2014 at 5:47 PM, Jamey Sharp ja...@minilop.net wrote:
 On Wed, Jun 04, 2014 at 06:58:47PM +0200, Sedat Dilek wrote:
 How do I see if DRI3 is enabled for mesa on my SandyBridge intel-gfxcard?

 glxinfo log-file attached...

 $ LC_ALL=C LIBGL_DEBUG=verbose glxinfo 2 /dev/null  /tmp/glxinfo.txt

 You threw out the information you wanted by redirecting the debug output
 to /dev/null. :-)

 $ LC_ALL=C LIBGL_DEBUG=verbose glxinfo /dev/null
 libGL: screen 0 does not appear to be DRI3 capable
 libGL: pci id for fd 4: 8086:0d26, driver i965
 ...

 I didn't realize that LIBGL_DEBUG=verbose would report that. It would
 have been handy to know when I was trying to figure out the same thing a
 few weeks ago.


Thanks for the hint.

$ LC_ALL=C LIBGL_DEBUG=verbose glxinfo /dev/null
libGL: pci id for fd 4: 8086:0116, driver i965
libGL: OpenDriver: trying /opt/xorg/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /opt/xorg/lib/dri/i965_dri.so
libGL: Can't open configuration file /home/wearefam/.drirc: No such
file or directory.
libGL: Can't open configuration file /home/wearefam/.drirc: No such
file or directory.

Not any wiser whats up with DRI3.

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Running DRI3 on intel-gfx

[Sedat Dilek]

Hi,

I took [1] as a base to test DRI3 on Ubuntu/precise AMD64.
Unfortunately, the packages from this repo have no DRI3 support.

So, I packaged some missing stuff, built mesa-10.1.4 and intel-ddx
from Git manually.
In the end I got somehow running a DRI3 system here.

 $ grep -A2 intel_drv /var/log/Xorg.0.log
[  1238.417] (II) Loading
/usr/lib/x86_64-linux-gnu/xorg/extra-modules/intel_drv.so
[  1238.417] (II) Module intel: vendor=X.Org Foundation
[  1238.417]compiled for 1.15.1, module version = 2.99.911

$ egrep -i 'dri2|dri3|present' /var/log/Xorg.0.log
[  1238.415] Initializing built-in extension Present
[  1238.415] Initializing built-in extension DRI3
[  1238.415] Initializing built-in extension DRI2
[  1238.454] (II) Loading sub module dri3
[  1238.454] (II) LoadModule: dri3
[  1238.454] (II) Module dri3 already built-in
[  1238.454] (II) Loading sub module dri2
[  1238.454] (II) LoadModule: dri2
[  1238.454] (II) Module dri2 already built-in
[  1238.454] (II) Loading sub module present
[  1238.454] (II) LoadModule: present
[  1238.454] (II) Module present already built-in
[  1238.455] (II) intel(0): [DRI2] Setup complete
[  1238.455] (II) intel(0): [DRI2]   DRI driver: i965
[  1238.455] (II) intel(0): [DRI2]   VDPAU driver: i965
[  1238.455] (II) intel(0): direct rendering: DRI2 DRI3 enabled
[  1238.455] (II) intel(0): hardware support for Present enabled
[  1238.496] (II) GLX: Initialized DRI2 GL provider for screen 0

DRI2 or DRI3 running here?

Thanks to Maarten and Chris for some help and hints.

Regards,
- Sedat -


[1] https://launchpad.net/~ubuntu-x-swat/+archive/t-lts-backport
[  1238.412] 
X.Org X Server 1.15.1
Release Date: 2014-04-13
[  1238.412] X Protocol Version 11, Revision 0
[  1238.412] Build Operating System: Linux 3.13.0-29-generic x86_64 Ubuntu
[  1238.412] Current Operating System: Linux fambox 3.13.0-29-generic #52~precise1-Ubuntu SMP Wed May 28 15:49:28 UTC 2014 x86_64
[  1238.412] Kernel command line: BOOT_IMAGE=/vmlinuz.lts-trusty root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro
[  1238.412] Build Date: 04 June 2014  03:32:31PM
[  1238.412] xorg-server 2:1.15.1-0ubuntu3~precise+dileks1 (For technical support please see http://www.ubuntu.com/support) 
[  1238.412] Current version of pixman: 0.30.2
[  1238.412] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[  1238.412] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1238.412] (==) Log file: /var/log/Xorg.0.log, Time: Wed Jun  4 15:50:21 2014
[  1238.412] (==) Using system config directory /usr/share/X11/xorg.conf.d
[  1238.413] (==) No Layout section.  Using the first Screen section.
[  1238.413] (==) No screen section available. Using defaults.
[  1238.413] (**) |--Screen Default Screen Section (0)
[  1238.413] (**) |   |--Monitor default monitor
[  1238.413] (==) No monitor specified for screen Default Screen Section.
	Using a default monitor configuration.
[  1238.413] (==) Automatically adding devices
[  1238.413] (==) Automatically enabling devices
[  1238.413] (==) Automatically adding GPU devices
[  1238.413] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[  1238.413] 	Entry deleted from font path.
[  1238.413] (WW) The directory /usr/share/fonts/X11/100dpi/ does not exist.
[  1238.413] 	Entry deleted from font path.
[  1238.413] (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
[  1238.413] 	Entry deleted from font path.
[  1238.413] (WW) The directory /usr/share/fonts/X11/100dpi does not exist.
[  1238.413] 	Entry deleted from font path.
[  1238.413] (WW) The directory /usr/share/fonts/X11/75dpi does not exist.
[  1238.413] 	Entry deleted from font path.
[  1238.413] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/Type1,
	built-ins
[  1238.413] (==) ModulePath set to /usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules
[  1238.413] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[  1238.413] (II) Loader magic: 0x7f97ddb92c60
[  1238.413] (II) Module ABI versions:
[  1238.413] 	X.Org ANSI C Emulation: 0.4
[  1238.413] 	X.Org Video Driver: 15.0
[  1238.413] 	X.Org XInput driver : 20.0
[  1238.413] 	X.Org Server Extension : 8.0
[  1238.413] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1238.415] (--) PCI:*(0:0:2:0) 8086:0116:144d:c0c7 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x3000/64
[  1238.415] Initializing built-in extension Generic Event Extension
[  1238.415] Initializing built-in extension SHAPE
[  1238.415] Initializing built-in extension MIT-SHM
[  1238.415] Initializing built-in extension XInputExtension
[  1238.415] Initializing built-in extension XTEST
[  1238.415] Initializing 

Re: [Intel-gfx] Running DRI3 on intel-gfx

[Sedat Dilek]

On Wed, Jun 4, 2014 at 6:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed, Jun 04, 2014 at 06:37:44PM +0200, Sedat Dilek wrote:
  DRI2 or DRI3 running here?
 

 I did some more testing and played with UXA/SNA for intel-ddx.

 $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_UXA
 [  8471.151] (II) intel(0): DRI2: Enabled
 [  8471.151] (II) intel(0): DRI3: Enabled
 [  8471.194] (II) GLX: Initialized DRI2 GL provider for screen 0

 $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_SNA
 [  8574.658] (II) intel(0): direct rendering: DRI2 DRI3 enabled
 [  8574.658] (II) intel(0): hardware support for Present enabled
 [  8574.666] (II) GLX: Initialized DRI2 GL provider for screen 0

 Still unsure if I had success.

 Yes, the DDX is ready. Try enabling LIBGL_DEBUG to check that mesa is
 using DRI3.

How do I see if DRI3 is enabled for mesa on my SandyBridge intel-gfxcard?

glxinfo log-file attached...

$ LC_ALL=C LIBGL_DEBUG=verbose glxinfo 2 /dev/null  /tmp/glxinfo.txt

To check for which keywords?

- Sedat -
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
GLX_INTEL_swap_event, GLX_EXT_buffer_age
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_create_context_es2_profile, 
GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, 
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, 
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event, GLX_EXT_buffer_age
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string: 3.0 Mesa 10.1.4 (git-f564097)
OpenGL shading language version string: 1.30
OpenGL extensions:
GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, 
GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, 
GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, 
GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, 
GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, 
GL_EXT_rescale_normal, GL_EXT_separate_specular_color, 
GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, 
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB, GL_ARB_multitexture, 
GL_EXT_framebuffer_sRGB, GL_IBM_multimode_draw_arrays, 
GL_IBM_texture_mirrored_repeat, GL_3DFX_texture_compression_FXT1, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, 
GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
GL_EXT_secondary_color, GL_EXT_texture_env_add, 
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, 
GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, 
GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, 
GL_ARB_texture_compression, GL_EXT_framebuffer_object

Re: [Intel-gfx] Running DRI3 on intel-gfx

[Sedat Dilek]

On Wed, Jun 4, 2014 at 6:58 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Wed, Jun 4, 2014 at 6:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed, Jun 04, 2014 at 06:37:44PM +0200, Sedat Dilek wrote:
  DRI2 or DRI3 running here?
 

 I did some more testing and played with UXA/SNA for intel-ddx.

 $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_UXA
 [  8471.151] (II) intel(0): DRI2: Enabled
 [  8471.151] (II) intel(0): DRI3: Enabled
 [  8471.194] (II) GLX: Initialized DRI2 GL provider for screen 0

 $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_SNA
 [  8574.658] (II) intel(0): direct rendering: DRI2 DRI3 enabled
 [  8574.658] (II) intel(0): hardware support for Present enabled
 [  8574.666] (II) GLX: Initialized DRI2 GL provider for screen 0

 Still unsure if I had success.

 Yes, the DDX is ready. Try enabling LIBGL_DEBUG to check that mesa is
 using DRI3.

 How do I see if DRI3 is enabled for mesa on my SandyBridge intel-gfxcard?

 glxinfo log-file attached...

 $ LC_ALL=C LIBGL_DEBUG=verbose glxinfo 2 /dev/null  /tmp/glxinfo.txt

 To check for which keywords?


Not sure if a lsof'd libxcb-dri3 is a good sign...

$ sudo lsof 2 /dev/null | grep ^Xorg | egrep 'intel|i965|dri3'
Xorg  1370   root  mem   REG7,0
25201405 694976 /opt/xorg/lib/dri/i965_dri.so
Xorg  1370   root  mem   REG7,0
139160 88 /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0
Xorg  1370   root  mem   REG7,0
2317299 694968 /opt/xorg/lib/xorg/modules/drivers/intel_drv.so
Xorg  1370   root  mem   REG7,0
10288  30113 /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0

- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT

[Sedat Dilek]

Hi Chris,

is this going into any drm-intel GIT tree?
I found it useful and saw it in your kernel-tree [1].

- Sedat -

[1] 
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?id=bf91098a1232db771feac66f88720c181ef61967

On Wed, Aug 14, 2013 at 1:35 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 Chasing wild speculation that we may be writing the wrong addresses
 into the GTT for stolen objects, I would like to inspect those values.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Sedat Dilek sedat.di...@gmail.com
 ---

 Sedak, can you please apply this patch and then attach the contents of
 /sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?

 ---
  drivers/gpu/drm/i915/i915_debugfs.c | 47 
 -
  1 file changed, 46 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 10d864c..4edf65a 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -390,6 +390,51 @@ static int i915_gem_object_info(struct seq_file *m, 
 void* data)
 return 0;
  }

 +static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device *dev)
 +{
 +   struct drm_i915_private *dev_priv = dev-dev_private;
 +   gen6_gtt_pte_t __iomem *gtt_entries;
 +   gen6_gtt_pte_t scratch_pte;
 +   gen6_gtt_pte_t zero[8] = {};
 +   int i, j, last_zero = 0;
 +   int ret;
 +
 +   if (INTEL_INFO(dev)-gen  6)
 +   return 0;
 +
 +   ret = mutex_lock_interruptible(dev-struct_mutex);
 +   if (ret)
 +   return ret;
 +
 +   gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv-gtt.gsm;
 +   scratch_pte = 
 dev_priv-gtt.base.pte_encode(dev_priv-gtt.base.scratch.addr, 
 I915_CACHE_LLC);
 +   for (i = 0; i  gtt_total_entries(dev_priv-gtt); i += 8) {
 +   gen6_gtt_pte_t pte[8];
 +   int this_zero;
 +
 +   for (j = 0; j  8; j++) {
 +   pte[j] = ioread32(gtt_entries[i+j]);
 +   if (pte[j] == scratch_pte)
 +   pte[j] = 0;
 +   }
 +
 +   this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
 +   if (last_zero  this_zero) {
 +   if (last_zero++ == 1)
 +   seq_puts(m, ...\n);
 +   continue;
 +   }
 +
 +   seq_printf(m, [%08x] %08x %08x %08x %08x %08x %08x %08x 
 %08x\n,
 +  i, pte[0], pte[1], pte[2], pte[3], pte[4], pte[5], 
 pte[6], pte[7]);
 +   last_zero = this_zero;
 +   }
 +
 +   mutex_unlock(dev-struct_mutex);
 +
 +   return 0;
 +}
 +
  static int i915_gem_gtt_info(struct seq_file *m, void *data)
  {
 struct drm_info_node *node = (struct drm_info_node *) m-private;
 @@ -422,7 +467,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void 
 *data)
 seq_printf(m, Total %d objects, %zu bytes, %zu GTT size\n,
count, total_obj_size, total_gtt_size);

 -   return 0;
 +   return i915_gem_gtt_contents(m, dev);
  }

  static int i915_gem_pageflip_info(struct seq_file *m, void *data)
 --
 1.8.4.rc2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915: split PCI IDs out into i915_drm.h v4

[Sedat Dilek]

Hi,

this is really cool!

Looking at this from [1]:

[ include/drm/i915_pciids.h ]
...
+#define INTEL_SNB_M_IDS(info) \
+ INTEL_VGA_DEVICE(0x0106, info), \
+ INTEL_VGA_DEVICE(0x0116, info), \ --- I have this one! GT2 mobile?
+ INTEL_VGA_DEVICE(0x0126, info)
+
+#define INTEL_IVB_M_IDS(info) \
+ INTEL_VGA_DEVICE(0x0156, info), /* GT1 mobile */ \
+ INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */

I remember to have seen GT2 for my Sandybridge system (Samsung
series-5 ultrabook) in the logs.
Other defines have comments like this.

[ lspci -vmnn ]

Device: 00:02.0
Class:  VGA compatible controller [0300]
Vendor: Intel Corporation [8086]
Device: 2nd Generation Core Processor Family Integrated Graphics
Controller [0116]
SVendor:Samsung Electronics Co Ltd [144d]
SDevice:Device [c0c7]
Rev:09

Was the comments forgotten for SNB-mobile GPUs?

Regards,
- Sedat -

[1] 
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=for-linux-nextid=09e60dcc1f6a2f3bbf6b97e957061e97f8cd297c
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915: split PCI IDs out into i915_drm.h v4

[Sedat Dilek]

On Sun, Sep 1, 2013 at 4:10 PM, Sedat Dilek sedat.di...@gmail.com wrote:

[...]

 [ include/drm/i915_pciids.h ]
 ...
 +#define INTEL_SNB_M_IDS(info) \
 + INTEL_VGA_DEVICE(0x0106, info), \
 + INTEL_VGA_DEVICE(0x0116, info), \ --- I have this one! GT2 mobile?
 + INTEL_VGA_DEVICE(0x0126, info)
 +
 +#define INTEL_IVB_M_IDS(info) \
 + INTEL_VGA_DEVICE(0x0156, info), /* GT1 mobile */ \
 + INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */

 I remember to have seen GT2 for my Sandybridge system (Samsung
 series-5 ultrabook) in the logs.

$ grep -i sandy /var/log/Xorg.0.log
[18.160] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend

BTW, is there somewhere on the Wild Wild Internet a doc/wiki where I
can have a human-readable list of Intel GPU hardware (there exist
GenX and GTY)?
The X RadeonFeature wiki has a section Decoder ring for engineering
vs marketing names in [1].

As a last thing, I noticed that brand-names like SandyBridge are
written differently in the Linux graphics stack (kernel-drm, libdrm,
mesa3d and intel-ddx). I can't say what is the official brand-name.
( The reason why I ask is for example searching for patterns in the sources. )

$ dmesg | grep -i sandy
[0.081443] Performance Events: PEBS fmt1+, 16-deep LBR,
SandyBridge events, full-width counters, Intel PMU driver.

$ grep -i sandy /var/log/Xorg.0.log
[18.160] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend

Thanks.

- Sedat -

[1] http://wiki.x.org/wiki/RadeonFeature/#index5h2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915: split PCI IDs out into i915_drm.h v4

[Sedat Dilek]

On Sun, Sep 1, 2013 at 5:05 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Sun, Sep 01, 2013 at 04:28:39PM +0200, Sedat Dilek wrote:
 On Sun, Sep 1, 2013 at 4:10 PM, Sedat Dilek sedat.di...@gmail.com wrote:

 [...]

  [ include/drm/i915_pciids.h ]
  ...
  +#define INTEL_SNB_M_IDS(info) \
  + INTEL_VGA_DEVICE(0x0106, info), \
  + INTEL_VGA_DEVICE(0x0116, info), \ --- I have this one! GT2 mobile?
  + INTEL_VGA_DEVICE(0x0126, info)
  +
  +#define INTEL_IVB_M_IDS(info) \
  + INTEL_VGA_DEVICE(0x0156, info), /* GT1 mobile */ \
  + INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */
 
  I remember to have seen GT2 for my Sandybridge system (Samsung
  series-5 ultrabook) in the logs.

 $ grep -i sandy /var/log/Xorg.0.log
 [18.160] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) 
 backend

 BTW, is there somewhere on the Wild Wild Internet a doc/wiki where I
 can have a human-readable list of Intel GPU hardware (there exist
 GenX and GTY)?
 The X RadeonFeature wiki has a section Decoder ring for engineering
 vs marketing names in [1].

 As a last thing, I noticed that brand-names like SandyBridge are
 written differently in the Linux graphics stack (kernel-drm, libdrm,
 mesa3d and intel-ddx). I can't say what is the official brand-name.
 ( The reason why I ask is for example searching for patterns in the sources. 
 )

 $ dmesg | grep -i sandy
 [0.081443] Performance Events: PEBS fmt1+, 16-deep LBR,
 SandyBridge events, full-width counters, Intel PMU driver.

 $ grep -i sandy /var/log/Xorg.0.log
 [18.160] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) 
 backend

 We have to be careful as Sandybridge isn't a brand or product name but a
 code name, and Intel marketing gets upset if we put the codenames into
 user visible strings. (I can understand their need for control over
 product image and branding, but the codenames are much easier to
 understand!) The popular form for the *bridge, *well, *trail, *view is
 as one word with a single leading capital letter. The codenames are,
 I believe, or at least once were, the names of geographic features
 around the Intel campuses. And different types of features (rivers,
 hills, etc) were used to denote different types/combinations of chips.

 Wikipedia is the best source for such information as product to code
 name to features. Though ark.intel.com has all the information if you
 have a glossary (wikipedia) to hand, and have product names to search.

No success with searching 1st for sandybridge (one word) :-(, so
official docs have a space (Sandy Bridge)

[1] says:
Sandy Bridge is the codename for both the Intel microarchitecture
innovation following Nehalem and generally for the associated family
of 32nm processors based upon that microarchitecture.

For the GPU there is Processor Graphics.
So mine seems to be called Intel® HD Graphics 3000.
Hmm, I remember darkly intel-ddx uses the latter.
Anyway, somehow all that stuff is still confusing me.

- Sedat -

[1] http://ark.intel.com/products/codename/29900/Sandy-Bridge?q=Sandy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx