Bug 28662

Summary: i915 in kernel 2.6.38-rc4, high number of wakeups
Product: Drivers Reporter: Kan-Ru Chen (kanru.kernel)
Component: Video(DRI - Intel)Assignee: drivers_video-dri-intel (drivers_video-dri-intel)
Status: CLOSED UNREPRODUCIBLE    
Severity: normal CC: chris, enban, florian, maciej.rutecki, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.38-rc4 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 21782    
Attachments: trace-cmd report

Description Kan-Ru Chen 2011-02-09 07:06:09 UTC 
Hi,

I believe this has been fixed in 2.6.36 release, tracked by https://bugzilla.kernel.org/show_bug.cgi?id=16307

However this appeared again since 2.6.37, below is the powertop output:

112.1 wakeups/second, 0.2 GPU ops/second and 0.0 VFS ops/sec
 0.7 ms/s	 56.1	Interrupt	[43] i915
 0.9 ms/s	 22.9	Interrupt	[6] tasklet(softirq)
 175.8 us/s	 9.7	kWork	ieee80211_iface_work
 126.7 us/s	 5.8	Timer	tick_sched_timer
 94.2 us/s	 5.1	Timer	hrtimer_wakeup

PowerTOP version	1.97 beta 1
Kernel version	Linux version 2.6.38-rc4 (kanru@anar) (gcc version 4.4.5 (Debian 4.4.5-10) ) #8 SMP Wed Feb 9 12:14:46 CST 2011
System name	Acer Aspire 3810T V1.28
CPU information	2x Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz

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.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (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-E 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)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
01:00.0 Network controller: Intel Corporation WiFi Link 5100
02:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0)
Comment 1 Chris Wilson 2011-02-09 11:53:56 UTC 
Are you absolutely sure it's not vblank... ;-)

I put back the patch we reverted last time, but only for gen5+ (so as to exclude your system).

Can you either grab drm-intel-next and run 'trace-cmd record -e i915:i915_reg_rw'
or add a printk inside the interrupt handler and attach the output?
Comment 2 Kan-Ru Chen 2011-02-09 18:57:45 UTC 
Created attachment 47002 [details]
trace-cmd report

Yes, I tested with the kernel 2.6.38-rc4 with drm-intel-next branch merged.

It was single user mode, no X, cursor off. Powertop still shows average 55 interrupt/sec. trace-cmd report attached.
Comment 3 Chris Wilson 2011-02-09 19:11:36 UTC 
It's unvarying, a repeat of:

          <idle>-0     [000]   161.866936: i915_reg_rw:          read reg=0x20a4, len=4, val=(0x40, 0x0)
          <idle>-0     [000]   161.866938: i915_reg_rw:          read reg=0x70024, len=4, val=(0x80440204, 0x0)
          <idle>-0     [000]   161.866938: i915_reg_rw:          write reg=0x70024, len=4, val=(0x80440204, 0x0)
          <idle>-0     [000]   161.866939: i915_reg_rw:          read reg=0x71024, len=4, val=(0x400206, 0x0)
          <idle>-0     [000]   161.866940: i915_reg_rw:          write reg=0x71024, len=4, val=(0x400206, 0x0)
          <idle>-0     [000]   161.866941: i915_reg_rw:          write reg=0x20a4, len=4, val=(0x40, 0x0)
          <idle>-0     [000]   161.866942: i915_reg_rw:          read reg=0x20a4, len=4, val=(0x0, 0x0)
          <idle>-0     [000]   161.866943: i915_reg_rw:          read reg=0x70024, len=4, val=(0x440002, 0x0)
          <idle>-0     [000]   161.866943: i915_reg_rw:          write reg=0x70024, len=4, val=(0x440002, 0x0)
          <idle>-0     [000]   161.866944: i915_reg_rw:          read reg=0x71024, len=4, val=(0x400000, 0x0)
          <idle>-0     [000]   161.866945: i915_reg_rw:          write reg=0x20a4, len=4, val=(0x0, 0x0)
          <idle>-0     [000]   161.866946: i915_reg_rw:          read reg=0x20a4, len=4, val=(0x0, 0x0)
          <idle>-0     [000]   161.866947: i915_reg_rw:          read reg=0x70024, len=4, val=(0x440000, 0x0)
          <idle>-0     [000]   161.866948: i915_reg_rw:          read reg=0x71024, len=4, val=(0x400000, 0x0)
Comment 4 Kan-Ru Chen 2011-02-10 01:55:34 UTC 
(In reply to comment #3)
> It's unvarying, a repeat of:
> 
>           <idle>-0     [000]   161.866936: i915_reg_rw:          read
> reg=0x20a4, len=4, val=(0x40, 0x0)
>           <idle>-0     [000]   161.866938: i915_reg_rw:          read

Should it varying?
Comment 5 Chris Wilson 2011-02-10 09:46:47 UTC 
It shouldn't be there at all! I was just surmising the info, before thinking about the next step...
Comment 6 Florian Mickler 2011-03-29 21:14:27 UTC 
Is this still a problem on 2.6.38.y ?
Comment 7 Kan-Ru Chen 2011-03-30 00:52:42 UTC 
I don't see this problem in my 2.6.38 kernel. Dunno which commit fixed this, they seem non related.
Comment 8 Florian Mickler 2011-03-30 20:05:23 UTC 
Alright, thanks for the update! I'm closing this as unreproducible. If it returns, just post a note.