On (07/15/15 11:51), Michel Dänzer wrote:
> On 14.07.2015 22:41, Sergey Senozhatsky wrote:
> >
> > sometimes `xset dpms force off' just turns off the panel for a second,
> > sometimes -- until I generate a `wakeup' event (key press, etc.)
>
> FWIW, the former case is because releasing the enter
On (07/14/15 17:11), Daniel Vetter wrote:
> Have you forwarded to a more recent -nightly? I just merged a patch which
> might have fixed this ...
>
Hello,
yep, I use the most recent -next usually (update it everyday),
when it boots. I can't reproduce the problem so far, hopefully
the commit you
On 14.07.2015 22:41, Sergey Senozhatsky wrote:
>
> sometimes `xset dpms force off' just turns off the panel for a second,
> sometimes -- until I generate a `wakeup' event (key press, etc.)
FWIW, the former case is because releasing the enter key generates an
input event, which changes the DPMS
On (07/14/15 14:44), Daniel Vetter wrote:
> > that helped. seems to be working only on -next.
>
> You mean you only get a backtrace on -next, right?
yeah, sure :-)
> Otherwise I'd be confused ;-)
>
> Next up. Please boot with drm.debug=0xe, repro the issue and attach
> complete dmesg (from
On (07/13/15 17:05), Daniel Vetter wrote:
> It goes boom somewhere from the cursor ioctl code, which means X is
> probably involved. Usual suspects are vt-switching, suspend/resume or
> cursor vs. DPMS. You can force a DPMS off from within X with
>
> $ xset dpms force off
>
that helped. seems
On Tue, Jul 14, 2015 at 10:41:42PM +0900, Sergey Senozhatsky wrote:
> On (07/14/15 14:44), Daniel Vetter wrote:
> > > that helped. seems to be working only on -next.
> >
> > You mean you only get a backtrace on -next, right?
>
> yeah, sure :-)
>
> > Otherwise I'd be confused ;-)
> >
> > Next
On Tue, Jul 14, 2015 at 08:39:50PM +0900, Sergey Senozhatsky wrote:
> On (07/13/15 17:05), Daniel Vetter wrote:
> > It goes boom somewhere from the cursor ioctl code, which means X is
> > probably involved. Usual suspects are vt-switching, suspend/resume or
> > cursor vs. DPMS. You can force a
On (07/13/15 16:46), Maarten Lankhorst wrote:
> > [ 1239.783961] [] dump_stack+0x4c/0x65
> > [ 1239.783965] [] ? up+0x39/0x3e
> > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5
> > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915]
> > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48
> >
On (07/13/15 16:35), Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote:
> > 4.2.0-rc2-next-20150713
>
> Is this also an issue in the 4.2-rc series or only in -next?
don't know how to reproduce this, but I'll check.
-ss
> >
> > [ 1239.783862]
4.2.0-rc2-next-20150713
[ 1239.783862] [ cut here ]
[ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368
i915_gem_track_fb+0xdc/0x106 [i915]()
[ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits)
[ 1239.783895] Modules linked in:
[
On Mon, Jul 13, 2015 at 11:44:15PM +0900, Sergey Senozhatsky wrote:
> On (07/13/15 16:35), Daniel Vetter wrote:
> > On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote:
> > > 4.2.0-rc2-next-20150713
> >
> > Is this also an issue in the 4.2-rc series or only in -next?
>
> don't
Op 13-07-15 om 14:51 schreef Sergey Senozhatsky:
> 4.2.0-rc2-next-20150713
>
> [ 1239.783862] [ cut here ]
> [ 1239.783892] WARNING: CPU: 0 PID: 364 at
> drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]()
> [ 1239.783894]
On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote:
> 4.2.0-rc2-next-20150713
Is this also an issue in the 4.2-rc series or only in -next?
-Daniel
>
> [ 1239.783862] [ cut here ]
> [ 1239.783892] WARNING: CPU: 0 PID: 364 at
>
13 matches
Mail list logo
