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)
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
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
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 <[email protected]>
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
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 <[email protected]>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 | [email protected]
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 | [email protected]
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 <[email protected]>
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;
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
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 <[email protected]>
---
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 | [email protected]
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 <[email protected]>
Acked-by: Zhang Rui <[email protected]>
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;
>
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 <[email protected]>
> 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
>
applied
thanks,
Len Brown, Intel Open Source Technology Center