* [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.