Regression: 20 ACPI interrupts per second on EEEPC 4G

Regression: 20 ACPI interrupts per second on EEEPC 4G

[Alan Jenkins]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On latest git, powertop shows 20 ACPI interrupts per second.  
Previously, this was closer to 1 per second.  See attached output (a vs 
b, "a" is from 2.6.29-rc8).

This is from a pretty sparse KDE desktop.  Normally I run 
gnome-power-manager, but I killed it to make sure that wasn't causing 
any problems.

alan@alan-eeepc:/sys/firmware/acpi/interrupts$ grep -v "invalid" *
error:       0
ff_gbl_lock:       0    enabled
ff_pwr_btn:       0     enabled
ff_rt_clk:       0      disabled
gpe03:       0  disabled
gpe04:       0  disabled
gpe05:       0  disabled
gpe09:       0  disabled
gpe0B:       0  disabled
gpe0C:       0  disabled
gpe0D:       0  disabled
gpe0E:       0  disabled
gpe18:   60975  enabled
gpe_all:   60975
sci:   60975

which I presume means lots of EC interrupts.

[    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66, data = 0x62

Any ideas?

Thanks
Alan

[-- Attachment #2: a --]
[-- Type: text/plain, Size: 3622 bytes --]

PowerTOP 1.11   (C) 2007, 2008 Intel Corporation 

Collecting data for 100 seconds 


Cn	          Avg residency
C0 (cpu running)        ( 0.0%)
polling		  0.0ms ( 0.0%)
C1		  0.1ms ( 0.0%)
C2		  0.0ms ( 0.0%)
C3		 93.5ms (100.0%)
P-states (frequencies)
Wakeups-from-idle per second : 10.7	interval: 100.0s
no ACPI power usage estimate available
Top causes for wakeups:
  17.0% (  2.0)       <interrupt> : ehci_hcd:usb1, uhci_hcd:usb2 
  15.1% (  1.8)       <interrupt> : extra timer interrupt 
  12.7% (  1.5)             udevd : ehci_work (ehci_watchdog) 
   8.6% (  1.0)              Xorg : schedule_hrtimeout_range (hrtimer_wakeup) 
   8.5% (  1.0)          kwrapper : do_nanosleep (hrtimer_wakeup) 
   8.5% (  1.0)              kwin : schedule_hrtimeout_range (hrtimer_wakeup) 
   8.5% (  1.0)   USB device  1-5 : UB6225 (ENE) 
   4.2% (  0.5)   hald-addon-stor : schedule_hrtimeout_range (hrtimer_wakeup) 
   2.4% (  0.3)       <interrupt> : ata_piix 
   2.1% (  0.2)    NetworkManager : atl2_open (atl2_watchdog) 
   1.8% (  0.2)       <interrupt> : acpi 
   1.7% (  0.2)              kded : schedule_hrtimeout_range (hrtimer_wakeup) 
   1.7% (  0.2)     <kernel core> : page_writeback_init (wb_timer_fn) 
   1.6% (  0.2)              init : schedule_hrtimeout_range (hrtimer_wakeup) 
   1.0% (  0.1)   <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 
   1.0% (  0.1)     <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 
   0.8% (  0.1)         ssh-agent : schedule_hrtimeout_range (hrtimer_wakeup) 
   0.8% (  0.1)         klauncher : schedule_hrtimeout_range (hrtimer_wakeup) 
   0.3% (  0.0)   <kernel module> : acpi_thermal_check (acpi_thermal_run) 
   0.3% (  0.0)       scsi_scan_2 : blk_add_timer (blk_rq_timed_out_timer) 
   0.3% (  0.0)     <kernel core> : blk_add_timer (blk_rq_timed_out_timer) 
   0.3% (  0.0)              hald : schedule_hrtimeout_range (hrtimer_wakeup) 
   0.2% (  0.0)          kdesktop : schedule_hrtimeout_range (hrtimer_wakeup) 
   0.2% (  0.0)     <kernel core> : queue_delayed_work (delayed_work_timer_fn) 
   0.2% (  0.0)            kicker : schedule_hrtimeout_range (hrtimer_wakeup) 
   0.1% (  0.0)       <interrupt> : PS/2 keyboard/mouse/touchpad 
   0.1% (  0.0)              cron : do_nanosleep (hrtimer_wakeup) 
   0.1% (  0.0)     <kernel core> : addrconf_verify (addrconf_verify) 
   0.1% (  0.0)     <kernel core> : inet_initpeers (peer_check_expire) 
   0.1% (  0.0)          rsyslogd : futex_wait (hrtimer_wakeup) 

A USB device is active 100.0% of the time:
USB device  1-5 : UB6225 (ENE)

Suggestion: Enable USB autosuspend by pressing the U key or adding 
usbcore.autosuspend=1 to the kernel command line in the grub config

Suggestion: increase the VM dirty writeback time from 4.99 to 15 seconds with:
  echo 1500 > /proc/sys/vm/dirty_writeback_centisecs 
This wakes the disk up less frequently for background VM activity

Suggestion: Disable 'hal' from polling your cdrom with:  
hal-disable-polling --device /dev/cdrom 'hal' is the component that auto-opens a
window if you plug in a CD but disables SATA power saving from kicking in.

Recent USB suspend statistics
Active  Device name
100.0%	USB device  1-5 : UB6225 (ENE)
  0.0%	USB device usb5 : UHCI Host Controller (Linux 2.6.29-rc8eeepc uhci_hcd)
  0.0%	USB device usb4 : UHCI Host Controller (Linux 2.6.29-rc8eeepc uhci_hcd)
  0.0%	USB device usb3 : UHCI Host Controller (Linux 2.6.29-rc8eeepc uhci_hcd)
  0.0%	USB device usb2 : UHCI Host Controller (Linux 2.6.29-rc8eeepc uhci_hcd)
100.0%	USB device usb1 : EHCI Host Controller (Linux 2.6.29-rc8eeepc ehci_hcd)

[-- Attachment #3: b --]
[-- Type: text/plain, Size: 3611 bytes --]

PowerTOP 1.11   (C) 2007, 2008 Intel Corporation 

Collecting data for 100 seconds 


Cn	          Avg residency
C0 (cpu running)        ( 0.3%)
polling		  0.0ms ( 0.0%)
C1		  0.0ms ( 0.0%)
C2		  1.1ms ( 0.0%)
C3		 42.1ms (99.7%)
P-states (frequencies)
Wakeups-from-idle per second : 23.9	interval: 100.0s
no ACPI power usage estimate available
Top causes for wakeups:
  64.2% ( 19.7)       <interrupt> : acpi 
  10.6% (  3.3)          events/0 : queue_delayed_work (delayed_work_timer_fn) 
   9.0% (  2.8)       <interrupt> : extra timer interrupt 
   3.4% (  1.0)              kwin : hrtimer_start_range_ns (hrtimer_wakeup) 
   3.3% (  1.0)              Xorg : hrtimer_start_range_ns (hrtimer_wakeup) 
   3.3% (  1.0)          kwrapper : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.8% (  0.2)       <interrupt> : ata_piix 
   0.8% (  0.2)    NetworkManager : atl2_open (atl2_watchdog) 
   0.7% (  0.2)     <kernel core> : page_writeback_init (wb_timer_fn) 
   0.7% (  0.2)              kded : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.6% (  0.2)              init : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.4% (  0.1)     <kernel core> : add_timer (neigh_periodic_timer) 
   0.4% (  0.1)   <kernel module> : add_timer (neigh_periodic_timer) 
   0.3% (  0.1)         ssh-agent : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.3% (  0.1)          kdesktop : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.2% (  0.1)           konsole : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.2% (  0.1)   knetworkmanager : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.2% (  0.1)              kmix : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.1% (  0.0)            kicker : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.1% (  0.0)              hald : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.1% (  0.0)           async/1 : blk_add_timer (blk_rq_timed_out_timer) 
   0.1% (  0.0)           pdflush : blk_plug_device (blk_unplug_timeout) 
   0.1% (  0.0)     <kernel core> : queue_delayed_work (delayed_work_timer_fn) 
   0.0% (  0.0)       <interrupt> : PS/2 keyboard/mouse/touchpad 
   0.0% (  0.0)       <interrupt> : uhci_hcd:usb5, HDA Intel, i915@pci:0000:00:02.0 
   0.0% (  0.0)   <kernel module> : queue_delayed_work (delayed_work_timer_fn) 
   0.0% (  0.0)         hd-audio0 : schedule_timeout_uninterruptible (process_timeout) 
   0.0% (  0.0)              cron : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.0% (  0.0)          rsyslogd : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.0% (  0.0)        khungtaskd : schedule_timeout_interruptible (process_timeout) 
   0.0% (  0.0)   <kernel module> : add_timer (addrconf_verify) 
   0.0% (  0.0)     <kernel core> : add_timer (peer_check_expire) 

A USB device is active 100.0% of the time:
USB device  1-5 : UB6225 (ENE)

Suggestion: Enable USB autosuspend by pressing the U key or adding 
usbcore.autosuspend=1 to the kernel command line in the grub config

Suggestion: increase the VM dirty writeback time from 5.00 to 15 seconds with:
  echo 1500 > /proc/sys/vm/dirty_writeback_centisecs 
This wakes the disk up less frequently for background VM activity

Recent USB suspend statistics
Active  Device name
100.0%	USB device  1-5 : UB6225 (ENE)
  0.0%	USB device usb5 : UHCI Host Controller (Linux 2.6.30-rc1eeepc uhci_hcd)
  0.0%	USB device usb4 : UHCI Host Controller (Linux 2.6.30-rc1eeepc uhci_hcd)
  0.0%	USB device usb3 : UHCI Host Controller (Linux 2.6.30-rc1eeepc uhci_hcd)
  0.0%	USB device usb2 : UHCI Host Controller (Linux 2.6.30-rc1eeepc uhci_hcd)
100.0%	USB device usb1 : EHCI Host Controller (Linux 2.6.30-rc1eeepc ehci_hcd)

Re: Regression: 20 ACPI interrupts per second on EEEPC 4G

[Alexey Starikovskiy]

Hi Alan,

This patch looks to be a suspect: 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
Please check if reversing it helps

Regards,
Alex.

Alan Jenkins wrote:
> On latest git, powertop shows 20 ACPI interrupts per second.  
> Previously, this was closer to 1 per second.  See attached output (a 
> vs b, "a" is from 2.6.29-rc8).
>
> This is from a pretty sparse KDE desktop.  Normally I run 
> gnome-power-manager, but I killed it to make sure that wasn't causing 
> any problems.
>
> alan@alan-eeepc:/sys/firmware/acpi/interrupts$ grep -v "invalid" *
> error:       0
> ff_gbl_lock:       0    enabled
> ff_pwr_btn:       0     enabled
> ff_rt_clk:       0      disabled
> gpe03:       0  disabled
> gpe04:       0  disabled
> gpe05:       0  disabled
> gpe09:       0  disabled
> gpe0B:       0  disabled
> gpe0C:       0  disabled
> gpe0D:       0  disabled
> gpe0E:       0  disabled
> gpe18:   60975  enabled
> gpe_all:   60975
> sci:   60975
>
> which I presume means lots of EC interrupts.
>
> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66, data 
> = 0x62
>
> Any ideas?
>
> Thanks
> Alan

Re: Regression: 20 ACPI interrupts per second on EEEPC 4G

[Alan Jenkins]

Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
>> On latest git, powertop shows 20 ACPI interrupts per second.  
>> Previously, this was closer to 1 per second.  See attached output (a 
>> vs b, "a" is from 2.6.29-rc8).
>>
>> This is from a pretty sparse KDE desktop.  Normally I run 
>> gnome-power-manager, but I killed it to make sure that wasn't causing 
>> any problems.
>>

>> gpe18:   60975  enabled
>> gpe_all:   60975
>> sci:   60975
>>
>> which I presume means lots of EC interrupts.
>>
>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66, data 
>> = 0x62
>>

> This patch looks to be a suspect: 
> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
> Please check if reversing it helps

No, I still get 20 ACPI interrupts per second.

I tried without powertop, just in case that was provoking it, but it 
still happens:

alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
    2583
    2680

Thanks
Alan

[BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Alan Jenkins]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>> Alan Jenkins wrote:
>>> On latest git, powertop shows 20 ACPI interrupts per second. 
>>> Previously, this was closer to 1 per second.  See attached output (a
>>> vs b, "a" is from 2.6.29-rc8).
>>>
>>> This is from a pretty sparse KDE desktop.  Normally I run
>>> gnome-power-manager, but I killed it to make sure that wasn't
>>> causing any problems.
>>>
>
>>> gpe18:   60975  enabled
>>> gpe_all:   60975
>>> sci:   60975
>>>
>>> which I presume means lots of EC interrupts.
>>>
>>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66,
>>> data = 0x62
>>>
>
>> This patch looks to be a suspect:
>> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
>> Please check if reversing it helps
>
> No, I still get 20 ACPI interrupts per second.
>
> I tried without powertop, just in case that was provoking it, but it
> still happens:
>
> alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
>    2583
>    2680

I did wonder whether this was due to thermal polling.  So look what I
found with bisection :-).


b1569e99c795bf83b4ddf41c4f1c42761ab7f75e is first bad commit
commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e
Author: Matthew Garrett <mjg59@srcf.ucam.org>
Date:   Wed Dec 3 17:55:32 2008 +0000

    ACPI: move thermal trip handling to generic thermal layer

    The ACPI code currently carries its own thermal trip handling,
meaning that
    any other thermal implementation will need to reimplement it. Move
the code
    to the generic thermal layer.


Regards
Alan

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[yakui_zhao]

On Sun, 2009-04-12 at 23:54 +0800, Alan Jenkins wrote:
> Alan Jenkins wrote:
> > Alexey Starikovskiy wrote:
> >> Alan Jenkins wrote:
> >>> On latest git, powertop shows 20 ACPI interrupts per second. 
> >>> Previously, this was closer to 1 per second.  See attached output (a
> >>> vs b, "a" is from 2.6.29-rc8).
> >>>
> >>> This is from a pretty sparse KDE desktop.  Normally I run
> >>> gnome-power-manager, but I killed it to make sure that wasn't
> >>> causing any problems.
> >>>
> >
> >>> gpe18:   60975  enabled
> >>> gpe_all:   60975
> >>> sci:   60975
> >>>
> >>> which I presume means lots of EC interrupts.
> >>>
> >>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66,
> >>> data = 0x62
> >>>
> >
> >> This patch looks to be a suspect:
> >> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
> >> Please check if reversing it helps
> >
> > No, I still get 20 ACPI interrupts per second.
> >
> > I tried without powertop, just in case that was provoking it, but it
> > still happens:
> >
> > alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
> >    2583
> >    2680
> 
> I did wonder whether this was due to thermal polling.  So look what I
> found with bisection :-).
Does the issue still exist if the following commit is reverted?
Thanks.
> 
> 
> b1569e99c795bf83b4ddf41c4f1c42761ab7f75e is first bad commit
> commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e
> Author: Matthew Garrett <mjg59@srcf.ucam.org>
> Date:   Wed Dec 3 17:55:32 2008 +0000
> 
>     ACPI: move thermal trip handling to generic thermal layer
> 
>     The ACPI code currently carries its own thermal trip handling,
> meaning that
>     any other thermal implementation will need to reimplement it. Move
> the code
>     to the generic thermal layer.
> 
> 
> Regards
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Alan Jenkins]

yakui_zhao wrote:
> On Sun, 2009-04-12 at 23:54 +0800, Alan Jenkins wrote:
>   
>> Alan Jenkins wrote:
>>     
>>> Alexey Starikovskiy wrote:
>>>       
>>>> Alan Jenkins wrote:
>>>>         
>>>>> On latest git, powertop shows 20 ACPI interrupts per second. 
>>>>> Previously, this was closer to 1 per second.  See attached output (a
>>>>> vs b, "a" is from 2.6.29-rc8).
>>>>>
>>>>> This is from a pretty sparse KDE desktop.  Normally I run
>>>>> gnome-power-manager, but I killed it to make sure that wasn't
>>>>> causing any problems.
>>>>>
>>>>>           
>>>>> gpe18:   60975  enabled
>>>>> gpe_all:   60975
>>>>> sci:   60975
>>>>>
>>>>> which I presume means lots of EC interrupts.
>>>>>
>>>>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66,
>>>>> data = 0x62
>>>>>
>>>>>           
>>>> This patch looks to be a suspect:
>>>> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
>>>> Please check if reversing it helps
>>>>         
>>> No, I still get 20 ACPI interrupts per second.
>>>
>>> I tried without powertop, just in case that was provoking it, but it
>>> still happens:
>>>
>>> alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
>>>    2583
>>>    2680
>>>       
>> I did wonder whether this was due to thermal polling.  So look what I
>> found with bisection :-).
>>     
> Does the issue still exist if the following commit is reverted?
> Thanks.
>   
>> b1569e99c795bf83b4ddf41c4f1c42761ab7f75e is first bad commit

I was waiting for a more detailed request.  It's not immediately obvious
how it should be reverted, given the associated commits which surround it.

Since you asked, I had a go.  I got a lot of merge conflicts, so I had
to keep on reverting other patches.  This fixed it:

      Revert "ACPI: thermal: use .notify method instead of installing
handler directly"
      Revert "ACPI: Adjust Kelvin offset to match local implementation"
      Revert "trivial: Fix misspelling of "Celsius"."
      Revert "proc tty: remove struct tty_operations::read_proc"
      Revert "proc tty: add struct tty_operations::proc_fops"
      Revert "proc 2/2: remove struct proc_dir_entry::owner"
      Revert "thermal: support forcing support for passive cooling"

      Revert "ACPI: update thermal for bus_id removal"
      Revert "ACPI: move thermal trip handling to generic thermal layer"

and then if I un-revert the last two, I can reproduce it again.  I hope
that makes sense :-).

Alan

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Matthew Garrett]

Ok, I think I've got it. Does this fix things? Ridiculous thinko...

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 9cd15e8..564ea14 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -909,7 +909,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
 			thermal_zone_device_register("acpitz", trips, tz,
 						     &acpi_thermal_zone_ops,
 						     0, 0, 0,
-						     tz->polling_frequency);
+						     tz->polling_frequency*100);
 	if (IS_ERR(tz->thermal_zone))
 		return -ENODEV;
 

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Joe Perches]

On Mon, 2009-04-13 at 18:05 +0100, Matthew Garrett wrote:
> Ok, I think I've got it. Does this fix things? Ridiculous thinko...
> 
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 9cd15e8..564ea14 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -909,7 +909,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
>  			thermal_zone_device_register("acpitz", trips, tz,
>  						     &acpi_thermal_zone_ops,
>  						     0, 0, 0,
> -						     tz->polling_frequency);
> +						     tz->polling_frequency*100);
>  	if (IS_ERR(tz->thermal_zone))
>  		return -ENODEV;

Perhaps this is clearer?
It also makes cleans up a for loop with a naked ;

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 9cd15e8..e8a6490 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -883,6 +880,10 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
 	int result;
 	acpi_status status;
 	int i;
+	int tc1;
+	int tc2;
+	int passive_delay;
+	int polling_delay;
 
 	if (tz->trips.critical.flags.valid)
 		trips++;
@@ -894,22 +895,25 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
 		trips++;
 
 	for (i = 0; i < ACPI_THERMAL_MAX_ACTIVE &&
-			tz->trips.active[i].flags.valid; i++, trips++);
+		    tz->trips.active[i].flags.valid; i++)
+		trips++;
 
-	if (tz->trips.passive.flags.valid)
-		tz->thermal_zone =
-			thermal_zone_device_register("acpitz", trips, tz,
-						     &acpi_thermal_zone_ops,
-						     tz->trips.passive.tc1,
-						     tz->trips.passive.tc2,
-						     tz->trips.passive.tsp*100,
-						     tz->polling_frequency*100);
-	else
-		tz->thermal_zone =
-			thermal_zone_device_register("acpitz", trips, tz,
-						     &acpi_thermal_zone_ops,
-						     0, 0, 0,
-						     tz->polling_frequency);
+	if (tz->trips.passive.flags.valid) {
+		tc1 = tz->trips.passive.tc1;
+		tc2 = tz->trips.passive.tc2;
+		passive_delay = tz->trips.passive.tsp * 100;
+	} else {
+		tc1 = 0;
+		tc2 = 0;
+		passive_delay = 0;
+	}
+	polling_delay = tz->polling_frequency * 100;
+
+	tz->thermal_zone =
+		thermal_zone_device_register("acpitz", trips, tz,
+					     &acpi_thermal_zone_ops,
+					     tc1, tc2, passive_delay,
+					     polling_delay);
 	if (IS_ERR(tz->thermal_zone))
 		return -ENODEV;
 

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Alan Jenkins]

Matthew Garrett wrote:
> Ok, I think I've got it. Does this fix things? Ridiculous thinko...
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 9cd15e8..564ea14 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -909,7 +909,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
>  			thermal_zone_device_register("acpitz", trips, tz,
>  						     &acpi_thermal_zone_ops,
>  						     0, 0, 0,
> -						     tz->polling_frequency);
> +						     tz->polling_frequency*100);
>  	if (IS_ERR(tz->thermal_zone))
>  		return -ENODEV;
>  
>
>   

Yup, that does it.

Thanks!
Alan

[PATCH] thermal: Fix polling frequency for systems without passive cooling

[Matthew Garrett]

The polling interval (in deciseconds) was accidently interpreted as 
being in milliseconds in one codepath, resulting in excessively frequent 
polling. Ensure that the conversion is performed.

Signed-off-by: Matthew Garrett <mjg@redhat.com>

---

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 9cd15e8..564ea14 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -909,7 +909,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
 			thermal_zone_device_register("acpitz", trips, tz,
 						     &acpi_thermal_zone_ops,
 						     0, 0, 0,
-						     tz->polling_frequency);
+						     tz->polling_frequency*100);
 	if (IS_ERR(tz->thermal_zone))
 		return -ENODEV;

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] thermal: Fix polling frequency for systems without passive cooling

[Zhang Rui]

On Wed, 2009-04-15 at 03:16 +0800, Matthew Garrett wrote:
> The polling interval (in deciseconds) was accidently interpreted as 
> being in milliseconds in one codepath, resulting in excessively frequent 
> polling. Ensure that the conversion is performed.
> 
> Signed-off-by: Matthew Garrett <mjg@redhat.com>

Acked-by: Zhang Rui <rui.zhang@intel.com>

Len,
I think we can ship this patch in 2.6.30-rc3.

thanks,
rui
> 
> ---
> 
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 9cd15e8..564ea14 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -909,7 +909,7 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
>  			thermal_zone_device_register("acpitz", trips, tz,
>  						     &acpi_thermal_zone_ops,
>  						     0, 0, 0,
> -						     tz->polling_frequency);
> +						     tz->polling_frequency*100);
>  	if (IS_ERR(tz->thermal_zone))
>  		return -ENODEV;
> 

Re: [PATCH] thermal: Fix polling frequency for systems without passive cooling

[Len Brown]

applied

thanks,
Len Brown, Intel Open Source Technology Center

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Zhang Rui]

On Sun, 2009-04-12 at 23:54 +0800, Alan Jenkins wrote:
> Alan Jenkins wrote:
> > Alexey Starikovskiy wrote:
> >> Alan Jenkins wrote:
> >>> On latest git, powertop shows 20 ACPI interrupts per second. 
> >>> Previously, this was closer to 1 per second.  See attached output (a
> >>> vs b, "a" is from 2.6.29-rc8).
> >>>
> >>> This is from a pretty sparse KDE desktop.  Normally I run
> >>> gnome-power-manager, but I killed it to make sure that wasn't
> >>> causing any problems.
> >>>
> >
> >>> gpe18:   60975  enabled
> >>> gpe_all:   60975
> >>> sci:   60975
> >>>
> >>> which I presume means lots of EC interrupts.
> >>>
> >>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66,
> >>> data = 0x62
> >>>
> >
> >> This patch looks to be a suspect:
> >> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
> >> Please check if reversing it helps
> >
> > No, I still get 20 ACPI interrupts per second.
> >
> > I tried without powertop, just in case that was provoking it, but it
> > still happens:
> >
> > alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
> >    2583
> >    2680
> 
> I did wonder whether this was due to thermal polling.  So look what I
> found with bisection :-).
> 
so the problem is gone if you revert this patch, right?

thanks,
rui
> 
> b1569e99c795bf83b4ddf41c4f1c42761ab7f75e is first bad commit
> commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e
> Author: Matthew Garrett <mjg59@srcf.ucam.org>
> Date:   Wed Dec 3 17:55:32 2008 +0000
> 
>     ACPI: move thermal trip handling to generic thermal layer
> 
>     The ACPI code currently carries its own thermal trip handling,
> meaning that
>     any other thermal implementation will need to reimplement it. Move
> the code
>     to the generic thermal layer.
> 
> 
> Regards
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Matthew Garrett]

On Sun, Apr 12, 2009 at 04:54:34PM +0100, Alan Jenkins wrote:

> I did wonder whether this was due to thermal polling.  So look what I
> found with bisection :-).

Huh. Could you send me the acpidump output?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [BISECTED] 20 ACPI interrupts per second on EEEPC 4G

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Alan Jenkins wrote:
>   
>> Alexey Starikovskiy wrote:
>>     
>>> Alan Jenkins wrote:
>>>       
>>>> On latest git, powertop shows 20 ACPI interrupts per second. 
>>>> Previously, this was closer to 1 per second.  See attached output (a
>>>> vs b, "a" is from 2.6.29-rc8).
>>>>
>>>> This is from a pretty sparse KDE desktop.  Normally I run
>>>> gnome-power-manager, but I killed it to make sure that wasn't
>>>> causing any problems.
>>>>
>>>>         
>>>> gpe18:   60975  enabled
>>>> gpe_all:   60975
>>>> sci:   60975
>>>>
>>>> which I presume means lots of EC interrupts.
>>>>
>>>> [    0.134068] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66,
>>>> data = 0x62
>>>>
>>>>         
>>> This patch looks to be a suspect:
>>> 34ff4dbccccce54c83b1234d39b7ad9e548a75dd,
>>> Please check if reversing it helps
>>>       
>> No, I still get 20 ACPI interrupts per second.
>>
>> I tried without powertop, just in case that was provoking it, but it
>> still happens:
>>
>> alan@alan-eeepc:/sys/firmware/acpi/interrupts$ cat sci; sleep 5; cat sci
>>    2583
>>    2680
>>     
>
> I did wonder whether this was due to thermal polling.  So look what I
> found with bisection :-).
>   
Great!
>
> b1569e99c795bf83b4ddf41c4f1c42761ab7f75e is first bad commit
> commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e
> Author: Matthew Garrett <mjg59@srcf.ucam.org>
> Date:   Wed Dec 3 17:55:32 2008 +0000
>
>     ACPI: move thermal trip handling to generic thermal layer
>
>     The ACPI code currently carries its own thermal trip handling,
> meaning that
>     any other thermal implementation will need to reimplement it. Move
> the code
>     to the generic thermal layer.
>
>
> Regards
> Alan
>