Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Fri, 30 Nov 2007 22:14:08 -0500 Mark Lord [EMAIL PROTECTED] wrote: latency. If your app cant take any latency, you should set those... and the side effect is that the kernel will not do long-latency C-states or P-state transitions.. .. I don't mind the cpufreq changing (actually, I want it to drop in cpugfreq to save power and keep the fan off), but the C-states just kill this app. semi-OT: I was finding that disabling cpufreq altogether on the Vaio speeds up `quilt push 1000' by a lot - around 30% iirc. There do seem to be some unsophisticated decisions in there and we're losing quite a bit of performance as a result. - 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
Acer Aspire 9813WKMI fan runs all the time after suspend to ram
Notebook fan runs all the time after suspend to ram. After suspend to disk fan works OK. after suspend to ram: cat /proc/acpi/fan/FAN0/state status: off cat /proc/acpi/thermal_zone/TZ00/temperature temperature: 27 C cat /proc/acpi/thermal_zone/TZ01/temperature temperature: 39 C cat /proc/acpi/thermal_zone/TZ00/trip_points critical (S5): 107 C active[0]: 53 C: devices=FAN0 cat /proc/acpi/thermal_zone/TZ01/trip_points critical (S5): 106 C dmesg after boot: [0.00] Linux version 2.6.24-rc3-ge1cca7e8-15-default ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #e1cca7e8d484390169777b423a7fe46c7021fec1 SMP 2007/25/30 01:25:2 [0.00] Command line: root=/dev/disk/by-id/scsi- SATA_SAMSUNG_HM120JIS09GJ30LB71446-part5 vga=0x348 resume=/dev/sda6 splash=silent [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009b400 (usable) [0.00] BIOS-e820: 0009b400 - 000a (reserved) [0.00] BIOS-e820: 000dc000 - 000e (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fe9 (usable) [0.00] BIOS-e820: 7fe9 - 7fe9a000 (ACPI NVS) [0.00] BIOS-e820: 7fe9a000 - 8000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed0 - fed00400 (reserved) [0.00] BIOS-e820: fed14000 - fed1a000 (reserved) [0.00] BIOS-e820: fed1c000 - fed9 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff00 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 155) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 523920) 1 entries of 3200 used [0.00] end_pfn_map = 1048576 [0.00] DMI present. [0.00] ACPI: RSDP 000F62A0, 0024 (r2 ACRSYS) [0.00] ACPI: XSDT 7FE91BC9, 0064 (r1 ACRSYS ACRPRDCT 604 LTP0) [0.00] ACPI: FACP 7FE98C2A, 00F4 (r3 ACRSYS ACRPRDCT 604 ALAN1) [0.00] ACPI: DSDT 7FE925BB, 65FB (r1 ACRSYS ACRPRDCT 604 INTL 20050624) [0.00] ACPI: FACS 7FE99FC0, 0040 [0.00] ACPI: APIC 7FE98D1E, 0068 (r1 INTEL CALISTGA 604 LOHR 5A) [0.00] ACPI: HPET 7FE98D86, 0038 (r1 INTEL CALISTGA 604 LOHR 5A) [0.00] ACPI: MCFG 7FE98DBE, 003C (r1 INTEL CALISTGA 604 LOHR 5A) [0.00] ACPI: APIC 7FE98DFA, 0068 (r1 ACRSYS ACRPRDCT 604 LTP0) [0.00] ACPI: SLIC 7FE98E62, 0176 (r1 ACRSYS ACRPRDCT 604 LTP0) [0.00] ACPI: BOOT 7FE98FD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) [0.00] ACPI: SSDT 7FE91C2D, 0500 (r1 PmRefCpuPm 3000 INTL 20050624) [0.00] ACPI: BIOS bug: multiple APIC/MADT found, using 0 [0.00] ACPI: If acpi_apic_instance=2 works better, notify linux-acpi@vger.kernel.org [0.00] No NUMA configuration found [0.00] Faking a node at -7fe9 [0.00] Entering add_active_range(0, 0, 155) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 523920) 1 entries of 3200 used [0.00] Bootmem setup node 0 -7fe9 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 155 [0.00] 0: 256 - 523920 [0.00] On node 0 totalpages: 523819 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1403 pages reserved [0.00] DMA zone: 2536 pages, LIFO batch:0 [0.00] DMA32 zone: 7106 pages used for memmap [0.00] DMA32 zone: 512718 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 [0.00] ACPI:
[PATCH] acpi: remove duplicated warning message
Remove duplicated warning message in acpi_power_transition()
This warning message is printed by acpi_bus_set_power() so we don't
need to print it again.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index af1769a..b4af974 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -458,11 +458,9 @@ int acpi_power_transition(struct acpi_device *device, int
state)
}
end:
- if (result) {
+ if (result)
device-power.state = ACPI_STATE_UNKNOWN;
- printk(KERN_WARNING PREFIX Transitioning device [%s] to D%d\n,
- device-pnp.bus_id, state);
- } else {
+ else {
/* We shouldn't change the state till all above operations succeed */
device-power.state = state;
}
--
Miguel Botón
-
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
Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
On Sat, 1 Dec 2007 02:17:40 -0800 Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 30 Nov 2007 22:14:08 -0500 Mark Lord [EMAIL PROTECTED] wrote: latency. If your app cant take any latency, you should set those... and the side effect is that the kernel will not do long-latency C-states or P-state transitions.. .. I don't mind the cpufreq changing (actually, I want it to drop in cpugfreq to save power and keep the fan off), but the C-states just kill this app. semi-OT: I was finding that disabling cpufreq altogether on the Vaio speeds up `quilt push 1000' by a lot - around 30% iirc. I assume this is using the ondemand governor and not userspace? (some older distros mistakingly used userspace and yes, that will suck) # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand (to make it easily cut-n-pastable to check) There do seem to be some unsophisticated decisions in there and we're losing quite a bit of performance as a result. if you can give a simple recipe for one of these, we can add it to our workload testsuite that at least some of us use every time we change either the C states or the cpufreq stuff (and yes we want to improve things) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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
Re: 20000+ wake-ups/second in 2.6.24. Bug?
On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord [EMAIL PROTECTED] wrote: Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. Some people have seen that not loading yenta at all will just make this not happen at all... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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
Re: 20000+ wake-ups/second in 2.6.24. Bug?
Arjan van de Ven wrote: On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord [EMAIL PROTECTED] wrote: Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. ... Ahh. Okay, this machine here did not have the problem on 2.6.23. Some people have seen that not loading yenta at all will just make this not happen at all... ... No yenta/cardbus here -- it's all PCIe. If you have any debug patches that could detect or help next time I see it, then feel free to toss them this way. Cheers! - 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
Re: 20000+ wake-ups/second in 2.6.24. Bug?
On Sunday, 2 of December 2007, Mark Lord wrote: Arjan van de Ven wrote: On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord [EMAIL PROTECTED] wrote: Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. ... Ahh. Okay, this machine here did not have the problem on 2.6.23. So on this particular machine it is a regression. I'm tempted to add it to the list of recent regressions in case it appears on someone else's system on which 2.6.23 works correctly. Objections? Rafael - 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
20000+ wake-ups/second in 2.6.24. Bug?
Mark Lord wrote: Arjan van de Ven wrote: On Fri, 30 Nov 2007 22:31:17 -0500 Mark Lord [EMAIL PROTECTED] wrote: ... Speaking of which.. what's with powertop on 2.6.24 ??? It's gone from 100-200 wakeups/sec to 2 wakeups/sec !!! ho hum.. Lenovo T61? I have some reports that that happens once in a while (but it's not limited to .24 and it's also real, it's not a powertop bug but it actually is waking up that much).. .. No, it's my hefty Dell Inspiron 9400. And I just figured out the powertop: it needed the kernel timers patch from the powertop site that was originally for 2.6.21.. ... Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. - 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
Re: 20000+ wake-ups/second in 2.6.24. Bug?
On Sat, 01 Dec 2007 18:55:48 -0500 Mark Lord [EMAIL PROTECTED] wrote: Arjan van de Ven wrote: On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord [EMAIL PROTECTED] wrote: Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. ... Ahh. Okay, this machine here did not have the problem on 2.6.23. Some people have seen that not loading yenta at all will just make this not happen at all... ... No yenta/cardbus here -- it's all PCIe. but.. is yenta loaded or built into the kernel? or is the config option off? Also, do you have a TI firewire bridge? (just asking the common patterns we've sort of kinda seen so far) If you have any debug patches that could detect or help next time I see it, then feel free to toss them this way. one thing to try (just as data collection) is to do lspci -vvxxx before it happens, and then again after it happens and then diff to see if something changed ;( (yes this is very crude; we've not been able to chase this one down at all so far). -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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
Re: 20000+ wake-ups/second in 2.6.24. Bug?
Hi, On Sunday 02 December 2007, Arjan van de Ven wrote in Re: 2+ wake-ups/second in 2.6.24. Bug?: Mark Lord [EMAIL PROTECTED] wrote: 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. Just as an Information - I see the same problem here, with an ubuntu 2.6.22 kernel. I did not report it so far, as I couldnt reliably reproduce it with an upstream kernel. Just as an additional datapoint (Lenovo T60 here). For me it happens only when using battery. Thats another reason I havent reported it so far - it only happened while on the road with work to do. If there is any testing needed - just say it. Greetings, Andres signature.asc Description: This is a digitally signed message part.
lost e-mail
I lost some e-mail between Nov-24 and today when my laptop went nuts on the road. Dunno if the cause was that my latop updated itself to FC9 early release, or if I did something foolish when slinging around mail archives between desktop and laptop. In any case, if you sent me something in the last week and you're wondering why I didn't reply, please re-send. thanks, -Len - 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
Re: ACPI related Warning in 2.6.24-rc3-git2
Applied to ACPI tree.
Linus,
I reproduced this issue on my T61, and saw it go away w/ this patch.
I'll be sending you a pull request probably Sunday night w/ this
pach in it. But if you are in a hurry to cut rc4 before then,
consider this an Acked-by: Len Brown [EMAIL PROTECTED]
thanks,
-Len
On Thursday 29 November 2007 03:22, Zhao Yakui wrote:
Subject: ACPI : Delete the IRQ operation in throttling controll via PTC
From : Zhao Yakui [EMAIL PROTECTED]
The IRQ operation(enable/disable) should be avoided when throttling is
controlled via PTC method. It is replaced by the migration of task.
Signed-off-by: Zhao Yakui [EMAIL PROTECTED]
---
drivers/acpi/processor_throttling.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
Index: linux-2.6.24-rc3-git3/drivers/acpi/processor_throttling.c
===
--- linux-2.6.24-rc3-git3.orig/drivers/acpi/processor_throttling.c
+++ linux-2.6.24-rc3-git3/drivers/acpi/processor_throttling.c
@@ -29,6 +29,7 @@
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
+#include linux/sched.h
#include linux/cpufreq.h
#include linux/proc_fs.h
#include linux/seq_file.h
@@ -413,7 +414,7 @@ static int acpi_throttling_rdmsr(struct
} else {
msr_low = 0;
msr_high = 0;
- rdmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL,
+ rdmsr_safe(MSR_IA32_THERM_CONTROL,
(u32 *)msr_low , (u32 *) msr_high);
msr = (msr_high 32) | msr_low;
*value = (acpi_integer) msr;
@@ -438,7 +439,7 @@ static int acpi_throttling_wrmsr(struct
HARDWARE addr space,NOT supported yet\n);
} else {
msr = value;
- wrmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL,
+ wrmsr_safe(MSR_IA32_THERM_CONTROL,
msr 0x, msr 32);
ret = 0;
}
@@ -572,21 +573,32 @@ static int acpi_processor_get_throttling
return -ENODEV;
pr-throttling.state = 0;
- local_irq_disable();
+
value = 0;
ret = acpi_read_throttling_status(pr, value);
if (ret = 0) {
state = acpi_get_throttling_state(pr, value);
pr-throttling.state = state;
}
- local_irq_enable();
return 0;
}
static int acpi_processor_get_throttling(struct acpi_processor *pr)
{
- return pr-throttling.acpi_processor_get_throttling(pr);
+ cpumask_t saved_mask;
+ int ret;
+
+ /*
+ * Migrate task to the cpu pointed by pr.
+ */
+ saved_mask = current-cpus_allowed;
+ set_cpus_allowed(current, cpumask_of_cpu(pr-id));
+ ret = pr-throttling.acpi_processor_get_throttling(pr);
+ /* restore the previous state */
+ set_cpus_allowed(current, saved_mask);
+
+ return ret;
}
static int acpi_processor_get_fadt_info(struct acpi_processor *pr)
@@ -717,21 +729,29 @@ static int acpi_processor_set_throttling
if (state pr-throttling_platform_limit)
return -EPERM;
- local_irq_disable();
value = 0;
ret = acpi_get_throttling_value(pr, state, value);
if (ret = 0) {
acpi_write_throttling_state(pr, value);
pr-throttling.state = state;
}
- local_irq_enable();
return 0;
}
int acpi_processor_set_throttling(struct acpi_processor *pr, int state)
{
- return pr-throttling.acpi_processor_set_throttling(pr, state);
+ cpumask_t saved_mask;
+ int ret;
+ /*
+ * Migrate task to the cpu pointed by pr.
+ */
+ saved_mask = current-cpus_allowed;
+ set_cpus_allowed(current, cpumask_of_cpu(pr-id));
+ ret = pr-throttling.acpi_processor_set_throttling(pr, state);
+ /* restore the previous state */
+ set_cpus_allowed(current, saved_mask);
+ return ret;
}
int acpi_processor_get_throttling_info(struct acpi_processor *pr)
On Wed, 2007-11-28 at 14:42 +0800, Pallipadi, Venkatesh wrote:
Yakui,
Can you look at this. Seems to be coming from commit f79f06ab9f86
FixedHW support tries to read MSR with interrupts disabled.
Thanks,
Venki
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rafael J. Wysocki
Sent: Tuesday, November 27, 2007 7:37 AM
To: Lukas Hejtmanek
Cc: [EMAIL PROTECTED]; ACPI Devel Maling List; Len
Brown; Alexey Starikovskiy
Subject: Re: ACPI related Warning in 2.6.24-rc3-git2
On Tuesday, 27 of November 2007, Lukas Hejtmanek wrote:
Hello,
in recent kernel, I got the following warnings while
booting. It's ACPI
related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
Appropriate Ccs added.
Did it happen before?
[ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3
[ 13.114885]
