* [regression?] i915 generating wakeups even when idle
@ 2010-12-07 21:03 Andrew Lutomirski
2010-12-07 21:31 ` Andrew Lutomirski
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-07 21:03 UTC (permalink / raw)
To: intel-gfx
Hi all-
Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
2.6.36.1, i915 started generating exactly 50 interrupts per second
(suspiciously equal to my refresh rate) when X is running. I have the
Xorg driver 2.12.0 (specifically
xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
console but leave X running, the interrupts stop.
Any ideas what to look at?
--Andy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [regression?] i915 generating wakeups even when idle
2010-12-07 21:03 [regression?] i915 generating wakeups even when idle Andrew Lutomirski
@ 2010-12-07 21:31 ` Andrew Lutomirski
2010-12-07 22:12 ` Jesse Barnes
2010-12-07 22:13 ` Chris Wilson
0 siblings, 2 replies; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-07 21:31 UTC (permalink / raw)
To: intel-gfx
On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> Hi all-
>
> Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> 2.6.36.1, i915 started generating exactly 50 interrupts per second
> (suspiciously equal to my refresh rate) when X is running. I have the
> Xorg driver 2.12.0 (specifically
> xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> console but leave X running, the interrupts stop.
>
> Any ideas what to look at?
Quitting compiz fixes it. Suspending compiz also fixes it.
If I turn on "sync to vblank" in compiz, I get wakeups. If I turn it
off, I don't get wakeups. I'm having trouble reproducing this on
nouveau, but I don't know if that means anything.
--Andy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [regression?] i915 generating wakeups even when idle
2010-12-07 21:31 ` Andrew Lutomirski
@ 2010-12-07 22:12 ` Jesse Barnes
2010-12-07 22:13 ` Chris Wilson
1 sibling, 0 replies; 12+ messages in thread
From: Jesse Barnes @ 2010-12-07 22:12 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx
On Tue, 7 Dec 2010 16:31:24 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> > Hi all-
> >
> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
> > (suspiciously equal to my refresh rate) when X is running. I have the
> > Xorg driver 2.12.0 (specifically
> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> > console but leave X running, the interrupts stop.
> >
> > Any ideas what to look at?
>
> Quitting compiz fixes it. Suspending compiz also fixes it.
>
> If I turn on "sync to vblank" in compiz, I get wakeups. If I turn it
> off, I don't get wakeups. I'm having trouble reproducing this on
> nouveau, but I don't know if that means anything.
Sounds like compiz is always calling one of the vblank using GL
functions, even when idle? Do you have any small apps running that
update continuously (e.g. terminal cursor, applet animations, etc)?
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [regression?] i915 generating wakeups even when idle
2010-12-07 21:31 ` Andrew Lutomirski
2010-12-07 22:12 ` Jesse Barnes
@ 2010-12-07 22:13 ` Chris Wilson
2010-12-07 22:26 ` Andrew Lutomirski
2010-12-08 18:17 ` Andrew Lutomirski
1 sibling, 2 replies; 12+ messages in thread
From: Chris Wilson @ 2010-12-07 22:13 UTC (permalink / raw)
To: Andrew Lutomirski, intel-gfx
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> > Hi all-
> >
> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
> > (suspiciously equal to my refresh rate) when X is running. Â I have the
> > Xorg driver 2.12.0 (specifically
> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). Â When I switch to a text
> > console but leave X running, the interrupts stop.
> >
> > Any ideas what to look at?
>
> Quitting compiz fixes it. Suspending compiz also fixes it.
So it is the vblank interrupt. The vblank interrupt is get alive for a few
seconds after the last use. If it keeps going, then either the system is
as idle as you believe or we lost track of the last user and forget to
switch off the interrupt.
drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
gory details of who/when triggers the vblank interrupt.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [regression?] i915 generating wakeups even when idle
2010-12-07 22:13 ` Chris Wilson
@ 2010-12-07 22:26 ` Andrew Lutomirski
2010-12-08 18:17 ` Andrew Lutomirski
1 sibling, 0 replies; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-07 22:26 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> > Hi all-
>> >
>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>> > (suspiciously equal to my refresh rate) when X is running. I have the
>> > Xorg driver 2.12.0 (specifically
>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
>> > console but leave X running, the interrupts stop.
>> >
>> > Any ideas what to look at?
>>
>> Quitting compiz fixes it. Suspending compiz also fixes it.
>
> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> seconds after the last use. If it keeps going, then either the system is
> as idle as you believe or we lost track of the last user and forget to
> switch off the interrupt.
>
> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> gory details of who/when triggers the vblank interrupt.
Will do tomorrow. I'm currently hampered by:
47: 9073 9455 PCI-MSI-edge <A0>Bs3^A<88><FF><FF>
in /proc/interrupts after a reboot (I *think*, but I'm not entirely
sure, that that's supposed to be i915).
--Andy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [regression?] i915 generating wakeups even when idle
2010-12-07 22:13 ` Chris Wilson
2010-12-07 22:26 ` Andrew Lutomirski
@ 2010-12-08 18:17 ` Andrew Lutomirski
2010-12-08 18:33 ` [TERRIBLE PATCH] " Andrew Lutomirski
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-08 18:17 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> > Hi all-
>> >
>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>> > (suspiciously equal to my refresh rate) when X is running. I have the
>> > Xorg driver 2.12.0 (specifically
>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
>> > console but leave X running, the interrupts stop.
>> >
>> > Any ideas what to look at?
>>
>> Quitting compiz fixes it. Suspending compiz also fixes it.
>
> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> seconds after the last use. If it keeps going, then either the system is
> as idle as you believe or we lost track of the last user and forget to
> switch off the interrupt.
>
> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> gory details of who/when triggers the vblank interrupt.
> -Chris
It's the seconds on the clock. That causes activity once per second,
which looks like this:
[ 708.109447] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109464] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 708.109524] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.109543] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 708.109574] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109590] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.109602] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109616] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.109704] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109729] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.109743] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109757] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.109774] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.109787] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.109800] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109813] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.109828] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.109843] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109856] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109869] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109882] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109896] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.109909] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.109921] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 708.109944] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.109963] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.109977] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.109991] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110067] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110090] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110105] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110120] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110138] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110152] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110166] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110180] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110196] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110211] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110232] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110247] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110261] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110278] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110292] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110305] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110319] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110335] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110350] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110388] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110404] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 708.110424] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 708.110449] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110463] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110478] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110501] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110515] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110528] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110542] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110558] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110573] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110591] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110606] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110621] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110636] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110651] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110667] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110682] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110697] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110712] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110727] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110743] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110758] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110773] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110788] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110803] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110818] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110833] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110848] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110863] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110878] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110894] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110909] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.110929] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.110943] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.110957] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.110974] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.110988] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.111023] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.111038] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.111056] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.111071] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.111092] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.111106] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.111121] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.111138] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.111152] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.111166] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.111179] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.111195] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 708.111210] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.111261] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.111409] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 708.111961] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.111977] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.111992] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112123] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.112194] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.112235] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.112250] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112266] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.112281] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.112297] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.112311] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112326] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.112354] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112369] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112384] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112428] [drm:drm_ioctl], pid=2464, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.112446] [drm:drm_ioctl], pid=2464, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.112464] [drm:drm_ioctl], pid=2464, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 708.112519] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.112534] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.112661] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.112710] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.112832] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.112999] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.113099] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.113185] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 708.113201] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 708.113212] [drm:drm_wait_vblank], waiting on vblank count 35136, crtc 1
[ 708.113222] [drm:drm_wait_vblank], returning 35136 to client
[ 708.113299] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.113384] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 708.113401] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 708.113412] [drm:drm_wait_vblank], waiting on vblank count 35136, crtc 1
[ 708.113421] [drm:drm_wait_vblank], returning 35136 to client
[ 708.113433] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 708.113445] [drm:drm_queue_vblank_event], event on vblank count
35137, current 35136, crtc 1
[ 708.113464] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.114264] [drm:drm_handle_vblank_events], vblank event on 35137,
current 35137
[ 708.114408] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.114500] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 708.114523] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 708.114589] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 708.114606] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 708.114769] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.114871] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.114987] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115060] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115075] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115088] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115101] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115115] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115127] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115142] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115155] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115168] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115181] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115196] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 708.115208] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 708.115221] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.115341] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 708.615109] [drm:intel_gpu_idle_timer], idle timer fired, downclocking
[ 709.109395] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109414] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 709.109474] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109493] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 709.109525] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109540] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.109553] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109567] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.109662] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109687] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.109701] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109715] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.109732] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.109746] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.109758] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109771] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.109786] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.109801] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109814] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109828] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109841] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109856] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.109868] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.109881] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 709.109904] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109923] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109937] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109951] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109965] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.109986] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.109999] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110082] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110101] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110116] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110130] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110144] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110159] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110176] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110198] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110212] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110227] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110243] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110258] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110271] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110285] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110300] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110315] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110353] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110369] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 709.110389] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev
0xe200, auth=1
[ 709.110413] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110428] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110443] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110466] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110480] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110494] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110508] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110523] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110539] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110557] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110572] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110587] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110602] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110617] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110632] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110647] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110662] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110677] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110693] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110708] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110723] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110738] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110753] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110768] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110783] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110798] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110813] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110828] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110843] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110858] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110874] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.110894] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110908] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110922] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110939] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.110954] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.110967] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.110982] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.110997] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.111034] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.111055] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.111069] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.111083] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.111101] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.111115] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.111129] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.111143] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.111159] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev
0xe200, auth=1
[ 709.111174] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.111224] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.111373] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 709.111944] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.111960] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.111974] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112085] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.112159] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.112201] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.112216] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112231] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.112247] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.112263] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.112276] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112290] [drm:drm_ioctl], pid=2464, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.112317] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112332] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112346] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112390] [drm:drm_ioctl], pid=2464, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.112408] [drm:drm_ioctl], pid=2464, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.112425] [drm:drm_ioctl], pid=2464, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 709.112479] [drm:drm_ioctl], pid=2464, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.112494] [drm:drm_ioctl], pid=2464, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.112622] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.112672] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.112945] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.113264] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.113458] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.113545] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 709.113562] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 709.113575] [drm:drm_wait_vblank], waiting on vblank count 35186, crtc 1
[ 709.113586] [drm:drm_wait_vblank], returning 35186 to client
[ 709.113663] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.113750] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 709.113768] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 709.113780] [drm:drm_wait_vblank], waiting on vblank count 35186, crtc 1
[ 709.113791] [drm:drm_wait_vblank], returning 35186 to client
[ 709.113803] [drm:drm_ioctl], pid=1889, cmd=0xc018643a, nr=0x3a, dev
0xe200, auth=1
[ 709.113817] [drm:drm_queue_vblank_event], event on vblank count
35187, current 35186, crtc 1
[ 709.113837] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.116037] [drm:intel_crtc_idle_timer], idle timer fired, downclocking
[ 709.120544] [drm:drm_handle_vblank_events], vblank event on 35187,
current 35187
[ 709.120636] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.120769] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev
0xe200, auth=1
[ 709.120791] [drm:drm_ioctl], pid=1889, cmd=0xc0086465, nr=0x65, dev
0xe200, auth=1
[ 709.120856] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev
0xe200, auth=1
[ 709.120873] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev
0xe200, auth=1
[ 709.120907] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120921] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120936] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120948] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120962] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120975] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.120987] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121045] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121060] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121076] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121090] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121105] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121119] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121133] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev
0xe200, auth=1
[ 709.121147] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev
0xe200, auth=1
[ 709.121161] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.121281] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 709.621159] [drm:intel_gpu_idle_timer], idle timer fired, downclocking
[ 709.754767] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
Turning off the second hand does this:
[ 782.144158] [drm:vblank_disable_fn], disabling vblank on crtc 1
[ 783.764295] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 783.764712] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 783.773979] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 783.775272] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 783.775369] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 783.776339] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 787.682508] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 789.266658] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 789.266784] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 789.506046] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 789.506129] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 789.750636] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 794.768923] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 794.769177] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 799.754985] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 800.271319] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 800.271551] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 805.773517] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 805.773618] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 809.745476] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 811.275774] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 811.275984] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 816.778302] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 816.778511] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 819.754823] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 822.280557] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 822.280724] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 827.782699] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 827.782872] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 829.755157] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 833.284924] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
[ 833.285179] [drm:drm_ioctl], pid=1889, cmd=0x6458, nr=0x58, dev
0xe200, auth=1
Maybe that "several seconds" (5, according to the source) timer is way
too long. Is there any reason that drm_vblank_put doesn't turn off
interrupts immediately (or, at the latest, on the very next vblank
interrupt)? After all, preventing deep sleep whenever there is
display activity every five seconds seems like a waste of power.
--Andy
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-08 18:17 ` Andrew Lutomirski
@ 2010-12-08 18:33 ` Andrew Lutomirski
2010-12-09 17:20 ` Jesse Barnes
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-08 18:33 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
>>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>> > Hi all-
>>> >
>>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>>> > (suspiciously equal to my refresh rate) when X is running. I have the
>>> > Xorg driver 2.12.0 (specifically
>>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
>>> > console but leave X running, the interrupts stop.
>>> >
>>> > Any ideas what to look at?
>>>
>>> Quitting compiz fixes it. Suspending compiz also fixes it.
>>
>> So it is the vblank interrupt. The vblank interrupt is get alive for a few
>> seconds after the last use. If it keeps going, then either the system is
>> as idle as you believe or we lost track of the last user and forget to
>> switch off the interrupt.
>>
>> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
>> gory details of who/when triggers the vblank interrupt.
>> -Chris
>
> It's the seconds on the clock. That causes activity once per second,
> which looks like this:
>
[...]
>
> Maybe that "several seconds" (5, according to the source) timer is way
> too long. Is there any reason that drm_vblank_put doesn't turn off
> interrupts immediately (or, at the latest, on the very next vblank
> interrupt)? After all, preventing deep sleep whenever there is
> display activity every five seconds seems like a waste of power.
This patch fixes it. It's obviously not ready for prime time, but if
you're OK with the idea I can fix it up and submit it.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9d3a503..49eca3f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
- mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
+ mod_timer(&dev->vblank_disable_timer, jiffies);
}
EXPORT_SYMBOL(drm_vblank_put);
>
> --Andy
>
>>
>> --
>> Chris Wilson, Intel Open Source Technology Centre
>>
>
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-08 18:33 ` [TERRIBLE PATCH] " Andrew Lutomirski
@ 2010-12-09 17:20 ` Jesse Barnes
2010-12-09 17:47 ` Andrew Lutomirski
0 siblings, 1 reply; 12+ messages in thread
From: Jesse Barnes @ 2010-12-09 17:20 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx
On Wed, 8 Dec 2010 13:33:20 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> >>> > Hi all-
> >>> >
> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
> >>> > Xorg driver 2.12.0 (specifically
> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> >>> > console but leave X running, the interrupts stop.
> >>> >
> >>> > Any ideas what to look at?
> >>>
> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
> >>
> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> >> seconds after the last use. If it keeps going, then either the system is
> >> as idle as you believe or we lost track of the last user and forget to
> >> switch off the interrupt.
> >>
> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> >> gory details of who/when triggers the vblank interrupt.
> >> -Chris
> >
> > It's the seconds on the clock. That causes activity once per second,
> > which looks like this:
> >
>
> [...]
>
> >
> > Maybe that "several seconds" (5, according to the source) timer is way
> > too long. Is there any reason that drm_vblank_put doesn't turn off
> > interrupts immediately (or, at the latest, on the very next vblank
> > interrupt)? After all, preventing deep sleep whenever there is
> > display activity every five seconds seems like a waste of power.
>
> This patch fixes it. It's obviously not ready for prime time, but if
> you're OK with the idea I can fix it up and submit it.
>
> Signed-off-by: Andy Lutomirski <luto@mit.edu>
>
> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 9d3a503..49eca3f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
>
> /* Last user schedules interrupt disable */
> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
> + mod_timer(&dev->vblank_disable_timer, jiffies);
> }
> EXPORT_SYMBOL(drm_vblank_put);
This will just move the problem around a bit; 5s is arguably too long
to wait before disabling interrupts, but having a second hand or
blinking : in your clock is the real issue here. Why don't you disable
that instead?
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-09 17:20 ` Jesse Barnes
@ 2010-12-09 17:47 ` Andrew Lutomirski
2010-12-09 18:23 ` Jesse Barnes
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-09 17:47 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx
On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Wed, 8 Dec 2010 13:33:20 -0500
> Andrew Lutomirski <luto@mit.edu> wrote:
>
>> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
>> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> >>> > Hi all-
>> >>> >
>> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
>> >>> > Xorg driver 2.12.0 (specifically
>> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
>> >>> > console but leave X running, the interrupts stop.
>> >>> >
>> >>> > Any ideas what to look at?
>> >>>
>> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
>> >>
>> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
>> >> seconds after the last use. If it keeps going, then either the system is
>> >> as idle as you believe or we lost track of the last user and forget to
>> >> switch off the interrupt.
>> >>
>> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
>> >> gory details of who/when triggers the vblank interrupt.
>> >> -Chris
>> >
>> > It's the seconds on the clock. That causes activity once per second,
>> > which looks like this:
>> >
>>
>> [...]
>>
>> >
>> > Maybe that "several seconds" (5, according to the source) timer is way
>> > too long. Is there any reason that drm_vblank_put doesn't turn off
>> > interrupts immediately (or, at the latest, on the very next vblank
>> > interrupt)? After all, preventing deep sleep whenever there is
>> > display activity every five seconds seems like a waste of power.
>>
>> This patch fixes it. It's obviously not ready for prime time, but if
>> you're OK with the idea I can fix it up and submit it.
>>
>> Signed-off-by: Andy Lutomirski <luto@mit.edu>
>>
>> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index 9d3a503..49eca3f 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
>>
>> /* Last user schedules interrupt disable */
>> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
>> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
>> + mod_timer(&dev->vblank_disable_timer, jiffies);
>> }
>> EXPORT_SYMBOL(drm_vblank_put);
>
> This will just move the problem around a bit; 5s is arguably too long
> to wait before disabling interrupts, but having a second hand or
> blinking : in your clock is the real issue here. Why don't you disable
> that instead?
I did.
But I might also scroll a webpage every second or so (or have a
webpage loaded at some point that updates itself every second) and I
see no reason to prevent the system from going into its maximum sleep
state in between updates.
IOW, I think we should optimize for mostly-idle machines in addition
to completely-idle machines.
--Andy
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-09 17:47 ` Andrew Lutomirski
@ 2010-12-09 18:23 ` Jesse Barnes
2010-12-09 18:32 ` Andrew Lutomirski
0 siblings, 1 reply; 12+ messages in thread
From: Jesse Barnes @ 2010-12-09 18:23 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx
On Thu, 9 Dec 2010 12:47:52 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Wed, 8 Dec 2010 13:33:20 -0500
> > Andrew Lutomirski <luto@mit.edu> wrote:
> >
> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> >> >>> > Hi all-
> >> >>> >
> >> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> >> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
> >> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
> >> >>> > Xorg driver 2.12.0 (specifically
> >> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> >> >>> > console but leave X running, the interrupts stop.
> >> >>> >
> >> >>> > Any ideas what to look at?
> >> >>>
> >> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
> >> >>
> >> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> >> >> seconds after the last use. If it keeps going, then either the system is
> >> >> as idle as you believe or we lost track of the last user and forget to
> >> >> switch off the interrupt.
> >> >>
> >> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> >> >> gory details of who/when triggers the vblank interrupt.
> >> >> -Chris
> >> >
> >> > It's the seconds on the clock. That causes activity once per second,
> >> > which looks like this:
> >> >
> >>
> >> [...]
> >>
> >> >
> >> > Maybe that "several seconds" (5, according to the source) timer is way
> >> > too long. Is there any reason that drm_vblank_put doesn't turn off
> >> > interrupts immediately (or, at the latest, on the very next vblank
> >> > interrupt)? After all, preventing deep sleep whenever there is
> >> > display activity every five seconds seems like a waste of power.
> >>
> >> This patch fixes it. It's obviously not ready for prime time, but if
> >> you're OK with the idea I can fix it up and submit it.
> >>
> >> Signed-off-by: Andy Lutomirski <luto@mit.edu>
> >>
> >> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >> index 9d3a503..49eca3f 100644
> >> --- a/drivers/gpu/drm/drm_irq.c
> >> +++ b/drivers/gpu/drm/drm_irq.c
> >> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> >>
> >> /* Last user schedules interrupt disable */
> >> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
> >> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
> >> + mod_timer(&dev->vblank_disable_timer, jiffies);
> >> }
> >> EXPORT_SYMBOL(drm_vblank_put);
> >
> > This will just move the problem around a bit; 5s is arguably too long
> > to wait before disabling interrupts, but having a second hand or
> > blinking : in your clock is the real issue here. Why don't you disable
> > that instead?
>
> I did.
>
> But I might also scroll a webpage every second or so (or have a
> webpage loaded at some point that updates itself every second) and I
> see no reason to prevent the system from going into its maximum sleep
> state in between updates.
>
> IOW, I think we should optimize for mostly-idle machines in addition
> to completely-idle machines.
It's probably safe to reduce the timeout quite a bit (maybe to 500ms or
so); the idea behind 5s was just to avoid whacking the interrupt
hardware too frequently and to avoid situations where we continually
enable/disable interrupts over a short period of time due to an app
that's only periodically using vblank interrupts.
So it would probably be best to make the 5*DRM_HZ into its own define,
DRM_VBLANK_IDLE_TIMEOUT or similar, and reduce it by a lot, maybe to as
low as a few frames; it could even be dynamic based on the refresh rate.
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-09 18:23 ` Jesse Barnes
@ 2010-12-09 18:32 ` Andrew Lutomirski
2010-12-09 18:44 ` Jesse Barnes
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Lutomirski @ 2010-12-09 18:32 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx
On Thu, Dec 9, 2010 at 1:23 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Thu, 9 Dec 2010 12:47:52 -0500
> Andrew Lutomirski <luto@mit.edu> wrote:
>
>> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > On Wed, 8 Dec 2010 13:33:20 -0500
>> > Andrew Lutomirski <luto@mit.edu> wrote:
>> >
>> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
>> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>> >> >>> > Hi all-
>> >> >>> >
>> >> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>> >> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>> >> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
>> >> >>> > Xorg driver 2.12.0 (specifically
>> >> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
>> >> >>> > console but leave X running, the interrupts stop.
>> >> >>> >
>> >> >>> > Any ideas what to look at?
>> >> >>>
>> >> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
>> >> >>
>> >> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
>> >> >> seconds after the last use. If it keeps going, then either the system is
>> >> >> as idle as you believe or we lost track of the last user and forget to
>> >> >> switch off the interrupt.
>> >> >>
>> >> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
>> >> >> gory details of who/when triggers the vblank interrupt.
>> >> >> -Chris
>> >> >
>> >> > It's the seconds on the clock. That causes activity once per second,
>> >> > which looks like this:
>> >> >
>> >>
>> >> [...]
>> >>
>> >> >
>> >> > Maybe that "several seconds" (5, according to the source) timer is way
>> >> > too long. Is there any reason that drm_vblank_put doesn't turn off
>> >> > interrupts immediately (or, at the latest, on the very next vblank
>> >> > interrupt)? After all, preventing deep sleep whenever there is
>> >> > display activity every five seconds seems like a waste of power.
>> >>
>> >> This patch fixes it. It's obviously not ready for prime time, but if
>> >> you're OK with the idea I can fix it up and submit it.
>> >>
>> >> Signed-off-by: Andy Lutomirski <luto@mit.edu>
>> >>
>> >> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> >> index 9d3a503..49eca3f 100644
>> >> --- a/drivers/gpu/drm/drm_irq.c
>> >> +++ b/drivers/gpu/drm/drm_irq.c
>> >> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
>> >>
>> >> /* Last user schedules interrupt disable */
>> >> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
>> >> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
>> >> + mod_timer(&dev->vblank_disable_timer, jiffies);
>> >> }
>> >> EXPORT_SYMBOL(drm_vblank_put);
>> >
>> > This will just move the problem around a bit; 5s is arguably too long
>> > to wait before disabling interrupts, but having a second hand or
>> > blinking : in your clock is the real issue here. Why don't you disable
>> > that instead?
>>
>> I did.
>>
>> But I might also scroll a webpage every second or so (or have a
>> webpage loaded at some point that updates itself every second) and I
>> see no reason to prevent the system from going into its maximum sleep
>> state in between updates.
>>
>> IOW, I think we should optimize for mostly-idle machines in addition
>> to completely-idle machines.
>
> It's probably safe to reduce the timeout quite a bit (maybe to 500ms or
> so); the idea behind 5s was just to avoid whacking the interrupt
> hardware too frequently and to avoid situations where we continually
> enable/disable interrupts over a short period of time due to an app
> that's only periodically using vblank interrupts.
>
> So it would probably be best to make the 5*DRM_HZ into its own define,
> DRM_VBLANK_IDLE_TIMEOUT or similar, and reduce it by a lot, maybe to as
> low as a few frames; it could even be dynamic based on the refresh rate.
How about triggering it off the vblank interrupt instead of a timer?
So when a vblank happens and no one has asked for a vblank interrupt
since the previous one (or two or whatever), turn it off.
--Andy
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
2010-12-09 18:32 ` Andrew Lutomirski
@ 2010-12-09 18:44 ` Jesse Barnes
0 siblings, 0 replies; 12+ messages in thread
From: Jesse Barnes @ 2010-12-09 18:44 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx
On Thu, 9 Dec 2010 13:32:04 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> On Thu, Dec 9, 2010 at 1:23 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Thu, 9 Dec 2010 12:47:52 -0500
> > Andrew Lutomirski <luto@mit.edu> wrote:
> >
> >> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >> > On Wed, 8 Dec 2010 13:33:20 -0500
> >> > Andrew Lutomirski <luto@mit.edu> wrote:
> >> >
> >> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> >> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto@mit.edu> wrote:
> >> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> >> >> >>> > Hi all-
> >> >> >>> >
> >> >> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> >> >> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
> >> >> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
> >> >> >>> > Xorg driver 2.12.0 (specifically
> >> >> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> >> >> >>> > console but leave X running, the interrupts stop.
> >> >> >>> >
> >> >> >>> > Any ideas what to look at?
> >> >> >>>
> >> >> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
> >> >> >>
> >> >> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> >> >> >> seconds after the last use. If it keeps going, then either the system is
> >> >> >> as idle as you believe or we lost track of the last user and forget to
> >> >> >> switch off the interrupt.
> >> >> >>
> >> >> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> >> >> >> gory details of who/when triggers the vblank interrupt.
> >> >> >> -Chris
> >> >> >
> >> >> > It's the seconds on the clock. That causes activity once per second,
> >> >> > which looks like this:
> >> >> >
> >> >>
> >> >> [...]
> >> >>
> >> >> >
> >> >> > Maybe that "several seconds" (5, according to the source) timer is way
> >> >> > too long. Is there any reason that drm_vblank_put doesn't turn off
> >> >> > interrupts immediately (or, at the latest, on the very next vblank
> >> >> > interrupt)? After all, preventing deep sleep whenever there is
> >> >> > display activity every five seconds seems like a waste of power.
> >> >>
> >> >> This patch fixes it. It's obviously not ready for prime time, but if
> >> >> you're OK with the idea I can fix it up and submit it.
> >> >>
> >> >> Signed-off-by: Andy Lutomirski <luto@mit.edu>
> >> >>
> >> >> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >> >> index 9d3a503..49eca3f 100644
> >> >> --- a/drivers/gpu/drm/drm_irq.c
> >> >> +++ b/drivers/gpu/drm/drm_irq.c
> >> >> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> >> >>
> >> >> /* Last user schedules interrupt disable */
> >> >> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
> >> >> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
> >> >> + mod_timer(&dev->vblank_disable_timer, jiffies);
> >> >> }
> >> >> EXPORT_SYMBOL(drm_vblank_put);
> >> >
> >> > This will just move the problem around a bit; 5s is arguably too long
> >> > to wait before disabling interrupts, but having a second hand or
> >> > blinking : in your clock is the real issue here. Why don't you disable
> >> > that instead?
> >>
> >> I did.
> >>
> >> But I might also scroll a webpage every second or so (or have a
> >> webpage loaded at some point that updates itself every second) and I
> >> see no reason to prevent the system from going into its maximum sleep
> >> state in between updates.
> >>
> >> IOW, I think we should optimize for mostly-idle machines in addition
> >> to completely-idle machines.
> >
> > It's probably safe to reduce the timeout quite a bit (maybe to 500ms or
> > so); the idea behind 5s was just to avoid whacking the interrupt
> > hardware too frequently and to avoid situations where we continually
> > enable/disable interrupts over a short period of time due to an app
> > that's only periodically using vblank interrupts.
> >
> > So it would probably be best to make the 5*DRM_HZ into its own define,
> > DRM_VBLANK_IDLE_TIMEOUT or similar, and reduce it by a lot, maybe to as
> > low as a few frames; it could even be dynamic based on the refresh rate.
>
> How about triggering it off the vblank interrupt instead of a timer?
> So when a vblank happens and no one has asked for a vblank interrupt
> since the previous one (or two or whatever), turn it off.
That could work ok, but it would add a little more code to the
interrupt handler that isn't time critical; we'd also have to be
careful of the locking.
If you want to submit a patch to do that it's fine with me, but it
should be separate from increasing the timeout.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-12-09 18:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-07 21:03 [regression?] i915 generating wakeups even when idle Andrew Lutomirski
2010-12-07 21:31 ` Andrew Lutomirski
2010-12-07 22:12 ` Jesse Barnes
2010-12-07 22:13 ` Chris Wilson
2010-12-07 22:26 ` Andrew Lutomirski
2010-12-08 18:17 ` Andrew Lutomirski
2010-12-08 18:33 ` [TERRIBLE PATCH] " Andrew Lutomirski
2010-12-09 17:20 ` Jesse Barnes
2010-12-09 17:47 ` Andrew Lutomirski
2010-12-09 18:23 ` Jesse Barnes
2010-12-09 18:32 ` Andrew Lutomirski
2010-12-09 18:44 ` Jesse Barnes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.