*** Bug 16304 has been marked as a duplicate of this bug. ***

Assuming these are vblank interrupts, activity should stop after 5s or so once you become idle.

If an application is continually requesting vblank events with swapbuffers calls or SGI_video_sync calls however, I'd expect to see continuing interrupts.  Also if an application is drawing, even to offscreen memory, you'd get interrupts as commands were submitted to and completed by the GPU.

On Sunday, July 25, 2010, Kan-Ru Chen wrote:
> Hi,
> 
> On Sat, 24 Jul 2010 11:19:50 +0200, Enrico Bandiello <enban@postal.uv.es>
> wrote:
> > On 07/23/2010 07:25 PM, Jesse Barnes wrote:
> > > On Fri, 23 Jul 2010 13:47:31 +0200 (CEST)
> > > "Rafael J. Wysocki"<rjw@sisk.pl>  wrote:
> > >
> > >> This message has been generated automatically as a part of a summary
> report
> > >> of recent regressions.
> > >>
> > >> The following bug entry is on the current list of known regressions
> > >> from 2.6.34.  Please verify if it still should be listed and let the
> tracking team
> > >> know (either way).
> > >>
> > >>
> > >> Bug-Entry        : http://bugzilla.kernel.org/show_bug.cgi?id=16307
> > >> Subject          : i915 in kernel 2.6.35-rc3, high number of wakeups
> > >> Submitter        : Enrico Bandiello<enban@postal.uv.es>
> > >> Date             : 2010-06-26 16:57 (28 days old)
> > >> Message-ID       :<4C26317A.5070309@postal.uv.es>
> > >> References       :
> http://marc.info/?l=linux-kernel&m=127757403404259&w=2
> > >
> > > Just updated the bug for this one.  Enrico, you say this behavior is
> > > recent.  Can you bisect between 2.6.34 and when the problem started?
> > >
> > Hi. I just tried, but can't find anything useful until now (surely it's 
> > my fault: it was my first attempt at bisection). Please let me try again 
> > in the next days.
> 
> I also noticed that interrupts keeps high in powertop. I bisected it
> today:
> 
> # bad: [e44a21b7268a022c7749f521c06214145bd161e4] Linux 2.6.35-rc2
> # good: [e40152ee1e1c7a63f4777791863215e3faa37a86] Linus 2.6.34
> git bisect start 'v2.6.35-rc2' 'v2.6.34'
> # good: [2086ca482f89950410527425913ca48d948e9622] i2c-algo-pca: Fix coding
> style issues
> git bisect good 2086ca482f89950410527425913ca48d948e9622
> # bad: [1756ac3d3c41341297ea25b818b7fce505bb2a9a] Merge branch 'virtio' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus
> git bisect bad 1756ac3d3c41341297ea25b818b7fce505bb2a9a
> # bad: [ec2a7587e0a91d5c1afe23a0a73edfce06c5e4e0] Merge branch 'msm-video' of
> git://codeaurora.org/quic/kernel/dwalker/linux-msm
> git bisect bad ec2a7587e0a91d5c1afe23a0a73edfce06c5e4e0
> # good: [e0bc5d4a54938eedcde14005210e6c08aa9727e4] Merge branch
> 'i2c-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
> git bisect good e0bc5d4a54938eedcde14005210e6c08aa9727e4
> # good: [ac3ee84c604502240122c47b52f0542ec8774f15] Merge branch
> 'dbg-early-merge' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb
> git bisect good ac3ee84c604502240122c47b52f0542ec8774f15
> # bad: [f4b7fb94c576265ceffc43031805ade32fa80c6a] drm/radeon/kms: take vram
> mutex pointer before derefing object.
> git bisect bad f4b7fb94c576265ceffc43031805ade32fa80c6a
> # bad: [0bcb1d844ac638a4c4280f697d5bfac9791e9a70] Merge branch
> 'drm-radeon-lockup' into drm-core-next
> git bisect bad 0bcb1d844ac638a4c4280f697d5bfac9791e9a70
> # bad: [77ffb5979de59efd1a6b280b10d647b09285bee0] drm/i915/pch: Use minimal
> number of FDI lanes (v2)
> git bisect bad 77ffb5979de59efd1a6b280b10d647b09285bee0
> # bad: [ab00a9ef8d4ce7de4d5b15cbf4101feeb8cf7f4d] drm/i915: Un-magic a DPCD
> register write
> git bisect bad ab00a9ef8d4ce7de4d5b15cbf4101feeb8cf7f4d
> # skip: [0f3ee801b332d6ff22285386675fe5aaedf035c3] drm/i915: Allow LVDS on
> pipe A on gen4+
> git bisect skip 0f3ee801b332d6ff22285386675fe5aaedf035c3
> # good: [5bf4c9c469ffc64b85fed1f3d2b0c8b19909ed13] drm/i915: use encoder_list
> for hotplug callback
> git bisect good 5bf4c9c469ffc64b85fed1f3d2b0c8b19909ed13
> # bad: [d275f6614e160fa71d6e2201eb34c9b41fd8473c] drm/i915: Clear the LVDS
> pipe B select bit when moving the LVDS to pipe A.
> git bisect bad d275f6614e160fa71d6e2201eb34c9b41fd8473c
> # good: [c1c43977e6fc789cbde094303fa9ace629a35aca] drm/i915: passing drm
> connector param for load detection
> git bisect good c1c43977e6fc789cbde094303fa9ace629a35aca
> # good: [6443170f6d862a1cc89e61e4bb2410b714b875f4] drm/i915: Remove dead KMS
> encoder save/restore code.
> git bisect good 6443170f6d862a1cc89e61e4bb2410b714b875f4
> 
> The bisect stopped between d275f66 and 0f3ee80 so I reverted the
> following three commits:
> 
> b3b095b drm/i915: enable LVDS on Cougarpoint
> d275f66 drm/i915: Clear the LVDS pipe B select bit when moving the LVDS to
> pipe A.
> 0f3ee80 drm/i915: Allow LVDS on pipe A on gen4+
> 
> Now the powertop only shows about 0.2 interrupts per second. Hope this
> information is useful.

On Tuesday, August 31, 2010, Kan-Ru Chen wrote:
> On Mon, Aug 30, 2010 at 7:13 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.34 and 2.6.35.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.34 and 2.6.35.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16307
> > Subject         : i915 in kernel 2.6.35-rc3, high number of wakeups
> > Submitter       : Enrico Bandiello <enban@postal.uv.es>
> > Date            : 2010-06-26 16:57 (65 days old)
> > Message-ID      : <<4C26317A.5070309@postal.uv.es>>
> > References      : http://marc.info/?l=linux-kernel&m=127757403404259&w=2
> 
> Same with v2.6.36-rc3
> 
> $ sudo powertop -d -t 20
> ...
> Wakeups-from-idle per second : 196.2    interval: 20.0s
> no ACPI power usage estimate available
> Top causes for wakeups:
>   25.4% ( 59.6)   [i915@pci:0000:00:02.0] <interrupt>

First-Bad-Commit: http://git.kernel.org/linus/0f3ee801b332d6ff22285386675fe5aaedf035c3
(drm/i915: Allow LVDS on pipe A on gen4+)

Also needed to be reverted to fix the issue:

References: http://git.kernel.org/linus/b3b095b3b2b052f3c665b0d9e3e551fb65062db3
(drm/i915: enable LVDS on Cougarpoint)

References: http://git.kernel.org/linus/d275f6614e160fa71d6e2201eb34c9b41fd8473c
(drm/i915: Clear the LVDS pipe B select bit when moving the LVDS to pipe A)

What's the problematic platform? lspci?

It might be just a h/w issue or we might have found a deeper problem with our hotplug code.

From the inital lkml report linked above: 


Enrico Bandiello <enban@postal.uv.es> wrote:
> Hi all. I was testing kernel 2.6.35-rc3 and I noticed that maybe there's
> a little regression: the module "i915" shows an high number of wakeups in
> powertop (60-72) on an otherwise idle laptop. This is not happening on
> kernel 2.6.34 that works fine (few or no i915 wakeups when idle ).
> I'm using a Toshiba Satellite L300 and my distro is a Debian
> testing/unstable mix.
> 
> lspci output:
> 
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory 
> Controller Hub (rev 07)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
> Chipset Integrated Graphics Controller (rev 07)
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
> Integrated Graphics Controller (rev 07)
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #4 (rev 03)
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #5 (rev 03)
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
> Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
> Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
> Port 1 (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
> Port 2 (rev 03)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
> Port 5 (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #3 (rev 03)
> 00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #6 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
> Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller 
> (rev 03)
> 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI 
> Controller (rev 03)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
> (rev 03)
> 03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless 
> Network Adapter (rev 01)
> 
> This is the first time I write on LKML, so forgive please me if there're
> errors in this bug(?) report and feel free to contact me if you need 
> more info.
> And please CC me, because I'm not subscribed to LKML.
> 
> Thank you very much, have a nice day.

Hi.I can confirm the same behaviour with kernel 2.6.36-rc3, on the sistem described in the first report. I will try now to revert the commits in reply #5 to see if that address the issue.

Wakeups-from-idle per second : 237.1    interval: 60.0s
Power usage (ACPI estimate): 16.4W (1.1 hours) 
Top causes for wakeups:
  43.5% ( 74.8)   [i915] <interrupt>
  17.6% ( 30.3)   PS/2 keyboard/mouse/touchpad interrupt
  10.7% ( 18.4)   firefox-bin
   6.4% ( 10.9)   [extra timer interrupt]
   4.9% (  8.5)   icedove-bin


Fell free to ask for more information, if you need it.

Thank you all for your interest in resolving the issue.

When looking at the wakeups, can we focus on a completely idle system so we don't have any secondary interrupts caused by rendering - if possible just using X with a single xterm client, that is no firefox, icedove or compositing WM.

To test the fix, you should just be able to comment out the:

+       if (IS_I965G(dev))
+               intel_encoder->crtc_mask |= (1 << 0);

added in the first patch.

This is the result obtained applying the fix in Comment #9 (from Chris Wilson):

Wakeups-from-idle per second : 176.7    interval: 60.0s
Power usage (ACPI estimate): 15.5W (0.5 hours) 
Top causes for wakeups:
  39.5% ( 55.8)   xulrunner-stub
  35.1% ( 49.5)   [extra timer interrupt]
   9.1% ( 12.8)   [ath] <interrupt>
   6.8% (  9.6)   [acpi] <interrupt>
   5.5% (  7.8)   [ahci] <interrupt>
   0.7% (  1.0)   kwin
   0.7% (  1.0)   ntpd
   0.4% (  0.6)   hald-addon-stor
   0.3% (  0.4)   [TLB shootdowns] <kernel IPI>
   0.2% (  0.3)   [Rescheduling interrupts] <kernel IPI>
   0.2% (  0.3)   Xorg
   0.2% (  0.3)   plasma-desktop
   0.2% (  0.2)   [kernel core] enqueue_task_rt (sched_rt_period_timer)
   0.1% (  0.2)   wicd-monitor
   0.1% (  0.2)   init
   0.1% (  0.2)   kded4
   0.1% (  0.1)   kworker/0:0
   0.1% (  0.1)   kworker/0:1
   0.1% (  0.1)   krunner
   0.1% (  0.1)   ssh-agent
   0.0% (  0.1)   hald
   0.0% (  0.1)   [i915] <interrupt>


As you can see, the problem appears to be gone. This report was obtained under an idle session in KDE. I will test this fix a for a couple of days and will report the results. In the meanwhile, tank you very much for you help. This problem was preventing me to use kernels > 2.6.34.*

As always, fell free to ask for more informations if you need them for a definitive fix.

I've queued the two line revert:

commit 1129e60b2b193f484cb888130acfda0ee77d7598
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 7 23:39:28 2010 +0100

    Revert "drm/i915: Allow LVDS on pipe A on gen4+"
    
    This reverts commit 0f3ee801b332d6ff22285386675fe5aaedf035c3.
    
    Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle
    system due to i915 interrupts. So restrict the LVDS to pipe B once more,
    whilst the issue is properly diagnosed.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307
    Reported-and-tested-by: Enrico Bandiello <enban@postal.uv.es>
    Reported-and-tested-by: Florian Mickler <florian@mickler.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Adam Jackson <ajax@redhat.com>
    Cc: stable@kernel.org

but I don't consider the issue fixed until we understand what the bug is and can enable LVDS on pipe A safely.

I'm marking this regression as resolved and will close it, as soon as the fix is mainline.

Note also, that I didn't really report-and-test this, more appropriately would probably be "Poked-By:"...

Cheers,
Flo

Fixed by commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82 .

A patch referencing this bug report has been merged in Linux v3.6-rc1:

commit 0b9f43a0ee7e89013a3d913ce556715fd8acb674
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 5 10:07:11 2012 +0200

    drm/i915: allow pipe A for lvds on gen4