09 Feb, 2012
1 commit
-
When checking driver-core tree, found crazying warnings on my setups.
[ 216.025849] calling acpi_processor_init+0x0/0x81 @ 1
[ 216.045332] ACPI: Requesting acpi_cpufreq
[ 216.047454] Monitor-Mwait will be used to enter C-1 state
[ 216.047912] Monitor-Mwait will be used to enter C-3 state
[ 216.065270] ACPI: acpi_idle registered with cpuidle
[ 216.068241] kobject (ffff8870364a1940): tried to init an initialized object, something is seriously wrong.
[ 216.085287] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc2-tip-yh-02428-ge663840-dirty #247
[ 216.105041] Call Trace:
[ 216.105192] [] kobject_init+0x33/0x83
[ 216.124880] [] kobject_init_and_add+0x23/0x57
[ 216.125158] [] cpuidle_add_sysfs+0x49/0x62
[ 216.144850] [] __cpuidle_register_device+0xe6/0x10e
[ 216.145182] [] cpuidle_register_device+0x25/0x4d
[ 216.164912] [] acpi_processor_power_init+0x13e/0x16c
[ 216.165205] [] ? acpi_processor_get_throttling_info+0x128/0x158
[ 216.185012] [] acpi_processor_start+0x62/0x11d
[ 216.204861] [] acpi_processor_add+0x1b0/0x1e7
[ 216.205144] [] acpi_device_probe+0x4e/0x11c
[ 216.225063] [] really_probe+0x99/0x126
[ 216.225328] [] driver_probe_device+0x3b/0x56
[ 216.244846] [] __driver_attach+0x5f/0x82
[ 216.245101] [] ? driver_probe_device+0x56/0x56
[ 216.264668] [] bus_for_each_dev+0x5c/0x88
[ 216.264942] [] driver_attach+0x1e/0x20
[ 216.284639] [] bus_add_driver+0xca/0x21d
[ 216.284903] [] ? local_clock+0xf/0x3c
[ 216.304580] [] ? acpi_fan_init+0x18/0x18
[ 216.304849] [] driver_register+0x91/0xfe
[ 216.324545] [] ? acpi_fan_init+0x18/0x18
[ 216.324813] [] acpi_bus_register_driver+0x43/0x45
[ 216.344563] [] acpi_processor_init+0x30/0x81
[ 216.344845] [] ? acpi_fan_init+0x18/0x18
[ 216.364590] [] do_one_initcall+0x57/0x134
[ 216.364868] [] kernel_init+0x146/0x1c0
[ 216.384512] [] kernel_thread_helper+0x4/0x10
[ 216.384819] [] ? retint_restore_args+0xe/0xe
[ 216.404578] [] ? start_kernel+0x3ab/0x3ab
[ 216.424530] [] ? gs_change+0xb/0xb
[ 216.424793] ------------[ cut here ]------------
[ 216.425038] WARNING: at fs/sysfs/dir.c:502 sysfs_add_one+0x97/0xab()
[ 216.444480] Hardware name: Sun Fire X4800
[ 216.444668] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0/cpuidle'
...It turns out acpi_processor_power_init() get called two time in acpi_processor_add and acpi_processor_start.
Found several lines are duplicated in those two functions even related commit move them.
The related patches are ok. Not sure how it could happen, looks like git problem.
-v2: add back acpi_processor_load_module(pr) to acpi_processor_load_start
Signed-off-by: Yinghai Lu
Cc: Linus Torvalds
Acked-by: Thomas Renninger
Cc: Len Brown
Signed-off-by: Greg Kroah-Hartman
03 Feb, 2012
1 commit
-
This was done to resolve a merge and build problem with the
drivers/acpi/processor_driver.c file.Reported-by: Stephen Rothwell
Signed-off-by: Greg Kroah-Hartman
27 Jan, 2012
1 commit
-
The only left over hole in automatic cpufreq driver loading was the loading
of ACPI cpufreq. This driver should be loaded when ACPI supports a _PDC
method and the CPU vendor wants to use acpi cpufreq.Simply add a request module call to the acpi processor core driver
when this is true. This seems like the simplest solution for this.Cc: Len Brown
Signed-off-by: Andi Kleen
Signed-off-by: Thomas Renninger
Acked-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
24 Jan, 2012
4 commits
-
ioremap() has become more picky and is now spitting out console messages like:
ioremap error for 0xbddbd000-0xbddbe000, requested 0x10, got 0x0
when loading the einj driver. What we are trying to so here is map
a couple of data structures that the EINJ table points to. Perhaps
acpi_os_map_memory() is a better tool for this?
Most importantly it works, but as a side benefit it maps the structures
into kernel virtual space so we can access them with normal C memory
dereferences, so instead of using:
writel(param1, &v5param->apicid);
we can use the more natural:
v5param->apicid = param1;Signed-off-by: Tony Luck
Signed-off-by: Len Brown -
This function is returning pointers. Sparse complains here:
drivers/acpi/apei/einj.c:262:32: warning:
Using plain integer as NULL pointerSigned-off-by: Dan Carpenter
Acked-by: Huang Ying
Signed-off-by: Len Brown -
According to the ACPI spec [1] section 18.6.4 the TRIGGER_ERROR action
table can consists of zero elements.[1] Advanced Configuration and Power Interface Specification
Revision 5.0, December 6, 2011
http://www.acpi.info/DOWNLOADS/ACPIspec50.pdfSigned-off-by: Niklas Söderlund
Acked-by: Huang Ying
Signed-off-by: Len Brown
21 Jan, 2012
4 commits
-
Sony Vaio VPCCW29FX does not resume correctly without
acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.https://bugzilla.kernel.org/show_bug.cgi?id=34722
Signed-off-by: Lan Tianyu
Signed-off-by: Len Brown -
With the conversion of atomicio's routines in place (see commits
6f68c91c55e and 700130b41f4), atomicio.[ch] can be removed, replacing
the APEI specific pre-mapping capabilities with the more generalized
versions that drivers/acpi/osl.c provides.Signed-off-by: Myron Stowe
Signed-off-by: Len Brown -
This patch adds support for RAM to ACPI's mapping capabilities in order
to support APEI error injection (EINJ) actions.This patch re-factors similar functionality introduced in commit
76da3fb3575, bringing it into osl.c in preparation for removing
./drivers/acpi/atomicio.[ch].Signed-off-by: Myron Stowe
Signed-off-by: Len Brown -
Base ACPI (CA) currently does not support atomic 64-bit reads and writes
(acpi_read() and acpi_write() split 64-bit loads/stores into two
32-bit transfers) yet APEI expects 64-bit transfer capability, even
when running on 32-bit systems.This patch implements 64-bit read and write routines for APEI usage.
This patch re-factors similar functionality introduced in commit
04c25997c97, bringing it into the ACPI subsystem in preparation for
removing ./drivers/acpi/atomicio.[ch]. In the implementation I have
replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
64-bit versions for APEI to utilize, as opposed to something more
elegant. My thinking is that we should attempt to see if we can get
ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
interfaces are natively 64-bit capable and then subsequently remove the
replication.Signed-off-by: Myron Stowe
Signed-off-by: Len Brown
20 Jan, 2012
2 commits
-
Delay the setting up of features (cpuidle, throttling by calling
acpi_processor_start()) to the time when the hotplugged
core got onlined the first time and got fully
initialized.Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown -
No functional change.
This is needed because:
When a CPU gets hotplugged, it's totally uninitialized
and offline. cpuinfo_x86 struct (cpu_data(cpu)) is mostly
zero (CPU feature flags, model, family,..).When a CPU gets hotplugged, struct processor is alloc'd,
some sysfs files are set up but acpi_processor_add()
must not try to access a MSR on this CPU or try to read
out CPU feature,family, etc.This must be done in acpi_processor_start().
The next patch will delay the call of acpi_processor_start()
for physically hotpluggedcores, to the time when they are onlined
the first time. There it is safe then to access cpu_data(cpu)
cpuinfo_x86 struct or access MSRs which is needed to
set up cpuidle, throttling and other features.Tested and
Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
19 Jan, 2012
1 commit
-
This includes initial support for the recently published ACPI 5.0 spec.
In particular, support for the "hardware-reduced" bit that eliminates
the dependency on legacy hardware.APEI has patches resulting from testing on real hardware.
Plus other random fixes.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (52 commits)
acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec
intel_idle: Split up and provide per CPU initialization func
ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2
ACPI processor: Remove unneeded cpuidle_unregister_driver call
intel idle: Make idle driver more robust
intel_idle: Fix a cast to pointer from integer of different size warning in intel_idle
ACPI: kernel-parameters.txt : Add intel_idle.max_cstate
intel_idle: remove redundant local_irq_disable() call
ACPI processor: Fix error path, also remove sysdev link
ACPI: processor: fix acpi_get_cpuid for UP processor
intel_idle: fix API misuse
ACPI APEI: Convert atomicio routines
ACPI: Export interfaces for ioremapping/iounmapping ACPI registers
ACPI: Fix possible alignment issues with GAS 'address' references
ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)
ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)
ACPI: Store SRAT table revision
ACPI, APEI, Resolve false conflict between ACPI NVS and APEI
ACPI, Record ACPI NVS regions
ACPI, APEI, EINJ, Refine the fix of resource conflict
...
18 Jan, 2012
6 commits
-
ACPI 5.0 provides extensions to the EINJ mechanism to specify the
target for the error injection - by APICID for cpu related errors,
by address for memory related errors, and by segment/bus/device/function
for PCIe related errors. Also extensions for vendor specific error
injections.Tested-by: Chen Gong
Signed-off-by: Tony Luck
Signed-off-by: Len Brown -
V2: Fix typo: pr->handle -> pr, here: acpi_processor_hotadd_init(pr)
This is a very small part taken from patches which afaik
are coming from Yunhong Jiang (for a Xen not a Linus repo?).Cleanup only: no functional change.
Advantage (beside cleanup) is that other data of the pr (acpi_processor) struct
in the acpi_processor_hotadd_init() is needed later, for example a newly
introduced flag:
pr->flags.need_hotplug_initSigned-off-by: Thomas Renninger
CC: Bjorn Helgaas
CC: Jiang, Yunhong
Signed-off-by: Len Brown -
Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab registering
and unregistering cpuidle is done in processor_idle.c.
Unregistering via:
acpi_bus_unregister_driver(&acpi_processor_driver)
-> acpi_processor_remove()
-> acpi_processor_power_exit()Remove not needed cpuidle_unregister_driver() call from
acpi_processor_exitSigned-off-by: Thomas Renninger
CC: Deepthi Dharwar
Signed-off-by: Len Brown
17 Jan, 2012
20 commits
-
Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown -
For UP processor, it is likely that no _MAT method or MADT table defined.
So currently acpi_get_cpuid(...) always return -1 for UP processor.
This is wrong. It should return valid value for CPU0.In the other hand, BIOS may define multiple CPU handles even for UP
processor, for exampleScope (_PR)
{
Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Processor (CPU1, 0x01, 0x00000410, 0x06) {}
Processor (CPU2, 0x02, 0x00000410, 0x06) {}
Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}We should only return valid value for CPU0's acpi handle.
And return invalid value for others.http://marc.info/?t=132329819900003&r=1&w=2
Cc: stable@vger.kernel.org
Reported-and-tested-by: wallak@free.fr
Signed-off-by: Lin Ming
Signed-off-by: Len Brown -
APEI needs memory access in interrupt context. The obvious choice is
acpi_read(), but originally it couldn't be used in interrupt context
because it makes temporary mappings with ioremap(). Therefore, we added
drivers/acpi/atomicio.c, which provides:
acpi_pre_map_gar() -- ioremap in process context
acpi_atomic_read() -- memory access in interrupt context
acpi_post_unmap_gar() -- iounmapLater we added acpi_os_map_generic_address() (2971852) and enhanced
acpi_read() so it works in interrupt context as long as the address has
been previously mapped (620242a). Now this sequence:
acpi_os_map_generic_address() -- ioremap in process context
acpi_read()/apei_read() -- now OK in interrupt context
acpi_os_unmap_generic_address()
is equivalent to what atomicio.c provides.This patch introduces apei_read() and apei_write(), which currently are
functional equivalents of acpi_read() and acpi_write(). This is mainly
proactive, to prevent APEI breakages if acpi_read() and acpi_write()
are ever augmented to support the 'bit_offset' field of GAS, as APEI's
__apei_exec_write_register() precludes splitting up functionality
related to 'bit_offset' and APEI's 'mask' (see its
APEI_EXEC_PRESERVE_REGISTER block).With apei_read() and apei_write() in place, usages of atomicio routines
are converted to apei_read()/apei_write() and existing calls within
osl.c and the CA, based on the re-factoring that was done in an earlier
patch series - http://marc.info/?l=linux-acpi&m=128769263327206&w=2:
acpi_pre_map_gar() --> acpi_os_map_generic_address()
acpi_post_unmap_gar() --> acpi_os_unmap_generic_address()
acpi_atomic_read() --> apei_read()
acpi_atomic_write() --> apei_write()Note that acpi_read() and acpi_write() currently use 'bit_width'
for accessing GARs which seems incorrect. 'bit_width' is the size of
the register, while 'access_width' is the size of the access the
processor must generate on the bus. The 'access_width' may be larger,
for example, if the hardware only supports 32-bit or 64-bit reads. I
wanted to minimize any possible impacts with this patch series so I
did *not* change this behavior.Signed-off-by: Myron Stowe
Signed-off-by: Len Brown -
Export remapping and unmapping interfaces - acpi_os_map_generic_address()
and acpi_os_unmap_generic_address() - for ACPI generic registers that are
backed by memory mapped I/O (MMIO).The acpi_os_map_generic_address() and acpi_os_unmap_generic_address()
declarations may more properly belong in include/acpi/acpiosxf.h next to
acpi_os_read_memory() but I believe that would require the ACPI CA making
them an official part of the ACPI CA - OS interface.ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure"Signed-off-by: Myron Stowe
Acked-by: Rafael J. Wysocki
Signed-off-by: Len Brown -
Generic Address Structures (GAS) may reside within ACPI tables which
are byte aligned. This patch copies GAS 'address' references to a local
variable, which will be naturally aligned, to be used going forward.ACPI Generic Address Structure (GAS) reference:
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure"Signed-off-by: Myron Stowe
Signed-off-by: Len Brown -
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
In order to know whether or not, we must know what version the SRAT
table has.This patch stores the SRAT table revision for later consumption
by arch specific __init functions.Signed-off-by: Kurt Garloff
Signed-off-by: Len Brown -
Some firmware will access memory in ACPI NVS region via APEI. That
is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
region. The original resource conflict checking in APEI code will
check memory/ioport accessed by APEI via general resource management
mech. But ACPI NVS region is marked as busy already, so that the
false resource conflict will prevent APEI ERST/EINJ to work.To fix this, this patch excludes ACPI NVS regions when APEI components
request resources. So that they will not conflict with ACPI NVS
regions.Reported-and-tested-by: Pavel Ivanov
Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Some firmware will access memory in ACPI NVS region via APEI. That
is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
region. The original resource conflict checking in APEI code will
check memory/ioport accessed by APEI via general resource management
mechanism. But ACPI NVS region is marked as busy already, so that the
false resource conflict will prevent APEI ERST/EINJ to work.To fix this, this patch record ACPI NVS regions, so that we can avoid
request resources for memory region inside it.Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Current fix for resource conflict is to remove the address region from trigger resource, which is highly relies on valid user
input. This patch is trying to avoid such potential issues by fetching the
exact address region from trigger action table entry.Signed-off-by: Xiao, Hui
Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Some APEI firmware implementation will access injected address
specified in param1 to trigger the error when injecting memory error.
This will cause resource conflict with RAM.On one of our testing machine, if injecting at memory address
0x10000000, the following error will be reported in dmesg:APEI: Can not request iomem region for GARs.
This patch removes the injecting memory address range from trigger
table resources to avoid conflict.Signed-off-by: Huang Ying
Tested-by: Tony Luck
Signed-off-by: Len Brown -
On one of our testing machine, the following EINJ command lines:
# echo 0x10000000 > param1
# echo 0xfffffffffffff000 > param2
# echo 0x8 > error_type
# echo 1 > error_injectWill get:
echo: write error: Input/output error
The EIO comes from:
rc = apei_exec_pre_map_gars(&trigger_ctx);
The root cause is as follow. Normally, ACPI atomic IO support is used
to access IO memory. But in EINJ of that machine, it is used to
access RAM to trigger the injected error. And the ioremap() called by
apei_exec_pre_map_gars() can not map the RAM.This patch add RAM mapping support to ACPI atomic IO support to
satisfy EINJ requirement.Signed-off-by: Huang Ying
Tested-by: Tony Luck
Signed-off-by: Len Brown -
Because printk is not safe inside NMI handler, the recoverable error
records received in NMI handler will be queued to be printked in a
delayed IRQ context via irq_work. If a fatal error occurs after the
recoverable error and before the irq_work processed, we lost a error
report.To solve the issue, the queued error records are printked in NMI
handler if system will go panic.Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
In most cases, printk only guarantees messages from different printk
calling will not be interleaved between each other. But, one APEI
GHES hardware error report will involve multiple printk calling,
normally each for one line. So it is possible that the hardware error
report comes from different generic hardware error source will be
interleaved.In this patch, a sequence number is prefixed to each line of error
report. So that, even if they are interleaved, they still can be
distinguished by the prefixed sequence number.Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Because APEI tables are optional, these message may confuse users, for
example,https://bugs.launchpad.net/ubuntu/+source/linux/+bug/599715
Reported-by: Bjorn Helgaas
Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Use the normal %pR-like format for MMIO and I/O port ranges.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
aer_recover_queue() is called when recoverable PCIe AER errors are
notified by firmware to do the recovery work.Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
There is no 64bit read/write support in ACPI atomicio because
readq/writeq is used to implement 64bit read/write, but readq/writeq
is not available on i386. This patch implement 64bit read/write
support in atomicio via two readl/writel.Signed-off-by: Huang Ying
Signed-off-by: Len Brown -
Update all copyrights to 2012.
Signed-off-by: Bob Moore
Signed-off-by: Lin Ming
Signed-off-by: Len Brown -
Allows drivers to determine if any memory or I/O addresses
will conflict with addresses used by ACPI operation regions.
Introduces a new interface, acpi_check_address_range.http://marc.info/?t=132251388700002&r=1&w=2
Reported-and-tested-by: Luca Tettamanti
Signed-off-by: Lin Ming
Signed-off-by: Bob Moore
Signed-off-by: Len Brown -
FADT is now larger than 256 bytes, so all FADT offsets must be
changed from 8 bits to 16 bits.Signed-off-by: Bob Moore
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
