kernel.git/drivers/acpi/processor_idle.c, branch linux-2.6.32.y

ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled

2013-06-10T09:42:39Z

commit b88a634a903d9670aa5f2f785aa890628ce0dece upstream. If cpuidle is disabled, that means that: per_cpu(acpi_cpuidle_device, pr->id) is set to NULL as the acpi_processor_power_init ends up failing at retval = cpuidle_register_driver(&acpi_idle_driver) (in acpi_processor_power_init) and never sets the per_cpu idle device. So when acpi_processor_hotplug on CPU online notification tries to reference said device it crashes: cpu 3 spinlock event irq 62 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [] acpi_processor_setup_cpuidle_cx+0x3f/0x105 PGD a259b067 PUD ab38b067 PMD 0 Oops: 0002 [#1] SMP odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 1 Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[] [] acpi_processor_setup_cpuidle_cx+0x3f/0x105 RSP: e02b:ffff88001742dca8 EFLAGS: 00010202 RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000 RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800 RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200 R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800 R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0 FS: 00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000) Stack: 0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800 0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0 ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336 Call Trace: [] acpi_processor_hotplug+0x7c/0x9f [] ? schedule_delayed_work_on+0x16/0x20 [] acpi_cpu_soft_notify+0x90/0xca [] notifier_call_chain+0x4d/0x70 [] __raw_notifier_call_chain+0x9/0x10 [] __cpu_notify+0x1b/0x30 [] _cpu_up+0x103/0x14b [] cpu_up+0xd9/0xec [] store_online+0x94/0xd0 [] dev_attr_store+0x1b/0x20 [] sysfs_write_file+0xf4/0x170 This patch fixes it. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

ACPI: skip checking BM_STS if the BIOS doesn't ask for it

2010-08-02T17:21:24Z

commit 718be4aaf3613cf7c2d097f925abc3d3553c0605 upstream. It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886 Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: Be in TS_POLLING state during mwait based C-state entry

2010-03-15T15:49:36Z

commit d306ebc28649b89877a22158fe0076f06cc46f60 upstream. ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using the write to the monitored address to wake up mwait'ing CPU. This patch changes the code to retain TS_POLLING bit if we are entering an mwait based deep C-state. The patch has been verified to reduce the number of resched IPIs in general and also improves the performance/power on workloads with low system utilization (i.e., when mwait based deep C-states are being used). Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f" http://marc.info/?l=linux-kernel&m=126441481427331&w=4 Reported-by: Lin Ming Tested-by: Alex Shi Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: fix High cpu temperature with 2.6.32

2010-02-23T15:37:57Z

commit 370d5cd88509b93b76eb2f5f97efbd71c25061cb upstream. Since the rewrite of the CPU idle governor in 2.6.32, two laptops have surfaced where the BIOS advertises a C2 power state, but for some reason this state is not functioning (as verified in both cases by powertop before the patch in .32). The old governor had the accidental behavior that if a non-working state was chosen too many times, it would end up falling back to C1. The new governor works differently and this accidental behavior is no longer there; the result is a high temperature on these two machines. This patch adds these 2 machines to the DMI table for C state anomalies; by just not using C2 both these machines are better off (the TSC can be used instead of the pm timer, giving a performance boost for example). Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14742 Signed-off-by: Arjan van de Ven Reported-by: Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C

2010-01-28T23:02:54Z

upstream in 2.6.33-rc: 5d76b6f6c17572e662f5c99c2023adae92100855 Refreshed here for 2.6.32.y, applies w/ offset back to 2.6.29.y. Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec, and the ACPI spec is clear that is correct FADT-supplied C2. However, the ACPI spec explicitly states that _CST-supplied C-states have no latency limits. So move the 100usec C2 test out of the code shared by FADT and _CST code-paths, and into the FADT-specific path. This bug has not been visible until Nehalem, which advertises a CPU-C2 worst case exit latency on servers of 205usec. That (incorrect) figure is being used by BIOS writers on mobile Nehalem systems for the AC configuration. Thus, Linux ignores C2 leaving just C1, which is saves less power, and also impacts performance by preventing the use of turbo mode. http://bugzilla.kernel.org/show_bug.cgi?id=15064 Tested-by: Alex Chiang Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: kill "unused variable ‘i’" warning

2009-09-27T18:58:36Z

Commit 3d5b6fb47a8e68fa311ca2c3447e7f8a7c3a9cf3 ("ACPI: Kill overly verbose "power state" log messages") removed the actual use of this variable, but didn't remove the variable itself, resulting in build warnings like drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’: drivers/acpi/processor_idle.c:1169: warning: unused variable ‘i’ Just get rid of the now unused variable. Signed-off-by: Linus Torvalds

ACPI: Kill overly verbose "power state" log messages

2009-09-27T08:01:40Z

I was recently lucky enough to get a 64-CPU system, so my kernel log ends up with 64 lines like: ACPI: CPU0 (power states: C1[C1] C2[C3]) This is pretty useless clutter because this info is already available after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as well as /proc/acpi/processor/CPU*/power. So just delete the code that prints the C-states in processor_idle.c. Signed-off-by: Roland Dreier Signed-off-by: Len Brown

Merge branch 'processor-procfs-2.6.32' into release

2009-09-19T06:10:40Z

ACPI: Move definition of PREFIX from acpi_bus.h to internal..h

2009-08-28T23:57:27Z

Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown

clockevent: Prevent dead lock on clockevents_lock

2009-08-19T16:15:10Z

Currently clockevents_notify() is called with interrupts enabled at some places and interrupts disabled at some other places. This results in a deadlock in this scenario. cpu A holds clockevents_lock in clockevents_notify() with irqs enabled cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled cpu C doing set_mtrr() which will try to rendezvous of all the cpus. This will result in C and A come to the rendezvous point and waiting for B. B is stuck forever waiting for the spinlock and thus not reaching the rendezvous point. Fix the clockevents code so that clockevents_lock is taken with interrupts disabled and thus avoid the above deadlock. Also call lapic_timer_propagate_broadcast() on the destination cpu so that we avoid calling smp_call_function() in the clockevents notifier chain. This issue left us wondering if we need to change the MTRR rendezvous logic to use stop machine logic (instead of smp_call_function) or add a check in spinlock debug code to see if there are other spinlocks which gets taken under both interrupts enabled/disabled conditions. Signed-off-by: Suresh Siddha Signed-off-by: Venkatesh Pallipadi Cc: "Pallipadi Venkatesh" Cc: "Brown Len" LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com> Signed-off-by: Thomas Gleixner