summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/apei
AgeCommit message (Collapse)Author
2012-07-14ACPI, APEI: Fixup common access width firmware bugJean Delvare
Many firmwares have a common register definition bug where 8-bit access width is specified for a 32-bit register. Ideally this should be fixed in the BIOS, but earlier versions of the kernel did not complain, so fix that up silently. This closes kernel bug #43282: https://bugzilla.kernel.org/show_bug.cgi?id=43282 Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Huang Ying <ying.huang@intel.com> Acked-by: Gary Hade <garyhade@us.ibm.com> Cc: stable@vger.kernel.org [3.4+] Signed-off-by: Len Brown <len.brown@intel.com>
2012-06-12ACPI, APEI, Avoid too much error reporting in runtimeHuang Ying
This patch fixed the following bug. https://bugzilla.kernel.org/show_bug.cgi?id=43282 This is caused by a firmware bug checking (checking generic address register provided by firmware) in runtime. The checking should be done in address mapping time instead of runtime to avoid too much error reporting in runtime. Reported-by: Pawel Sikora <pluto@agmk.net> Signed-off-by: Huang Ying <ying.huang@intel.com> Tested-by: Jean Delvare <khali@linux-fr.org> Cc: stable@vger.kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30Merge branch 'apei' into releaseLen Brown
Conflicts: drivers/acpi/apei/apei-base.c This was a conflict between 15afae604651d4e17652d2ffb56f5e36f991cfef (CPI, APEI: Fix incorrect APEI register bit width check and usage) and 653f4b538f66d37db560e0f56af08117136d29b7 (ACPICA: Expand OSL memory read/write interfaces to 64 bits) The former changed a parameter in the call to acpi_os_read_memory64() and the later replaced all calls to acpi_os_read_memory64() with calls to acpi_os_read_memory(). Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30CPER failed to handle generic error records with multiple sectionsJiang Liu
The function apei_estatus_print() and apei_estatus_check() forget to move ahead the gdata pointer when dealing with multiple generic error data sections. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30ACPI, APEI: Fix incorrect APEI register bit width check and usageGary Hade
The current code incorrectly assumes that (1) the APEI register bit width is always 8, 16, 32, or 64 and (2) the APEI register bit width is always equal to the APEI register access width. ERST serialization instructions entries such as: [030h 0048 1] Action : 00 [Begin Write Operation] [031h 0049 1] Instruction : 03 [Write Register Value] [032h 0050 1] Flags (decoded below) : 01 Preserve Register Bits : 1 [033h 0051 1] Reserved : 00 [034h 0052 12] Register Region : [Generic Address Structure] [034h 0052 1] Space ID : 00 [SystemMemory] [035h 0053 1] Bit Width : 03 [036h 0054 1] Bit Offset : 00 [037h 0055 1] Encoded Access Width : 03 [DWord Access:32] [038h 0056 8] Address : 000000007F2D7038 [040h 0064 8] Value : 0000000000000001 [048h 0072 8] Mask : 0000000000000007 break this assumption by yielding: [Firmware Bug]: APEI: Invalid bit width in GAR [0x7f2d7038/3/0] I have found no ACPI specification requirements corresponding with the above assumptions. There is even a good example in the Serialization Instruction Entries section (ACPI 4.0 section 17.4,1.2, ACPI 4.0a section 2.5.1.2, ACPI 5.0 section 18.5.1.2) that mentions a serialization instruction with a bit range of [6:2] which is 5 bits wide, _not_ 8, 16, 32, or 64 bits wide. Compile and boot tested with 3.3.0-rc7 on a IBM HX5. Signed-off-by: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30ACPI, APEI, EINJ, new parameter to control trigger actionChen Gong
Some APEI firmware implementation will access injected address specified in param1 to trigger the error when injecting memory error, which means if one SRAR error is injected, the crash always happens because it is executed in kernel context. This new parameter can disable trigger action and control is taken over by the user. In this way, an SRAR error can happen in user context instead of crashing the system. This function is highly depended on BIOS implementation so please ensure you know the BIOS trigger procedure before you enable this switch. v2: notrigger should be created together with param1/param2 Tested-by: Tony Luck <tony.luck@lintel.com> Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30ACPI, APEI, EINJ, limit the range of einj_paramChen Gong
On the platforms with ACPI4.x support, parameter extension is not always doable, which means only parameter extension is enabled, einj_param can take effect. v2->v1: stopping early in einj_get_parameter_address for einj_param Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-30ACPI, APEI, Fix ERST header length checkJiang Liu
This fixes a trivial copy & paste error in ERST header length check. It's just for future safety because sizeof(struct acpi_table_einj) equals to sizeof(struct acpi_table_erst) with current ACPI5.0 specification. It applies to v3.3-rc6. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-03-22ACPICA: Expand OSL memory read/write interfaces to 64 bitsBob Moore
This change expands acpi_os_read_memory and acpi_os_write_memory to a full 64 bits. This allows 64 bit transfers via the acpi_read and acpi_write interfaces. Note: The internal acpi_hw_read and acpi_hw_write interfaces remain at 32 bits, because 64 bits is not needed to access the standard ACPI registers. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-23Use acpi_os_map_memory() instead of ioremap() in einj driverLuck, Tony
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 <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-23ACPI, APEI, EINJ, cleanup 0 vs NULL confusionDan Carpenter
This function is returning pointers. Sparse complains here: drivers/acpi/apei/einj.c:262:32: warning: Using plain integer as NULL pointer Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-23ACPI, APEI, EINJ Allow empty Trigger Error Action TableNiklas Söderlund
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.pdf Signed-off-by: Niklas Söderlund <niklas.soderlund@ericsson.com> Acked-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-21ACPI, APEI: Add 64-bit read/write support for APEI on i386Myron Stowe
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 <myron.stowe@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-18Merge branch 'release' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux 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 ...
2012-01-18Merge branches 'einj', 'intel_idle', 'misc', 'srat' and 'turbostat-ivb' into ↵Len Brown
release
2012-01-18acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi specTony Luck
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 <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI APEI: Convert atomicio routinesMyron Stowe
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() -- iounmap Later 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 <myron.stowe@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, Resolve false conflict between ACPI NVS and APEIHuang Ying
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 <paivanof@gmail.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, EINJ, Refine the fix of resource conflictXiao, Hui
Current fix for resource conflict is to remove the address region <param1 & param2, ~param2+1> 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 <hui.xiao@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, EINJ, Fix resource conflict on some machineHuang Ying
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 <0000000010000000-0000000010000008> for GARs. This patch removes the injecting memory address range from trigger table resources to avoid conflict. Signed-off-by: Huang Ying <ying.huang@intel.com> Tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, Printk queued error record before panicHuang Ying
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 <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, GHES, Distinguish interleaved error report in kernel logHuang Ying
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 <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, Remove table not found messageHuang Ying
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 <bhelgaas@google.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, Print resource errors in conventional formatBjorn Helgaas
Use the normal %pR-like format for MMIO and I/O port ranges. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17ACPI, APEI, GHES: Add PCIe AER recovery supportHuang Ying
aer_recover_queue() is called when recoverable PCIe AER errors are notified by firmware to do the recovery work. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-13module_param: make bool parameters really bool (drivers & misc)Rusty Russell
module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2011-11-17pstore: pass reason to backend write callbackKees Cook
This allows a backend to filter on the dmesg reason as well as the pstore reason. When ramoops is switched to pstore, this is needed since it has no interest in storing non-crash dmesg details. Drop pstore_write() as it has no users, and handling the "reason" here has no obviously correct value. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-11-17pstore: pass allocated memory region back to callerKees Cook
The buf_lock cannot be held while populating the inodes, so make the backend pass forward an allocated and filled buffer instead. This solves the following backtrace. The effect is that "buf" is only ever used to notify the backends that something was written to it, and shouldn't be used in the read path. To replace the buf_lock during the read path, isolate the open/read/close loop with a separate mutex to maintain serialized access to the backend. Note that is is up to the pstore backend to cope if the (*write)() path is called in the middle of the read path. [ 59.691019] BUG: sleeping function called from invalid context at .../mm/slub.c:847 [ 59.691019] in_atomic(): 0, irqs_disabled(): 1, pid: 1819, name: mount [ 59.691019] Pid: 1819, comm: mount Not tainted 3.0.8 #1 [ 59.691019] Call Trace: [ 59.691019] [<810252d5>] __might_sleep+0xc3/0xca [ 59.691019] [<810a26e6>] kmem_cache_alloc+0x32/0xf3 [ 59.691019] [<810b53ac>] ? __d_lookup_rcu+0x6f/0xf4 [ 59.691019] [<810b68b1>] alloc_inode+0x2a/0x64 [ 59.691019] [<810b6903>] new_inode+0x18/0x43 [ 59.691019] [<81142447>] pstore_get_inode.isra.1+0x11/0x98 [ 59.691019] [<81142623>] pstore_mkfile+0xae/0x26f [ 59.691019] [<810a2a66>] ? kmem_cache_free+0x19/0xb1 [ 59.691019] [<8116c821>] ? ida_get_new_above+0x140/0x158 [ 59.691019] [<811708ea>] ? __init_rwsem+0x1e/0x2c [ 59.691019] [<810b67e8>] ? inode_init_always+0x111/0x1b0 [ 59.691019] [<8102127e>] ? should_resched+0xd/0x27 [ 59.691019] [<8137977f>] ? _cond_resched+0xd/0x21 [ 59.691019] [<81142abf>] pstore_get_records+0x52/0xa7 [ 59.691019] [<8114254b>] pstore_fill_super+0x7d/0x91 [ 59.691019] [<810a7ff5>] mount_single+0x46/0x82 [ 59.691019] [<8114231a>] pstore_mount+0x15/0x17 [ 59.691019] [<811424ce>] ? pstore_get_inode.isra.1+0x98/0x98 [ 59.691019] [<810a8199>] mount_fs+0x5a/0x12d [ 59.691019] [<810b9174>] ? alloc_vfsmnt+0xa4/0x14a [ 59.691019] [<810b9474>] vfs_kern_mount+0x4f/0x7d [ 59.691019] [<810b9d7e>] do_kern_mount+0x34/0xb2 [ 59.691019] [<810bb15f>] do_mount+0x5fc/0x64a [ 59.691019] [<810912fb>] ? strndup_user+0x2e/0x3f [ 59.691019] [<810bb3cb>] sys_mount+0x66/0x99 [ 59.691019] [<8137b537>] sysenter_do_call+0x12/0x26 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-11-01Merge branch 'pstore' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux * 'pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux: pstore: make pstore write function return normal success/fail value pstore: change mutex locking to spin_locks pstore: defer inserting OOPS entries into pstore
2011-10-26Merge branch 'sched-core-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (46 commits) llist: Add back llist_add_batch() and llist_del_first() prototypes sched: Don't use tasklist_lock for debug prints sched: Warn on rt throttling sched: Unify the ->cpus_allowed mask copy sched: Wrap scheduler p->cpus_allowed access sched: Request for idle balance during nohz idle load balance sched: Use resched IPI to kick off the nohz idle balance sched: Fix idle_cpu() llist: Remove cpu_relax() usage in cmpxchg loops sched: Convert to struct llist llist: Add llist_next() irq_work: Use llist in the struct irq_work logic llist: Return whether list is empty before adding in llist_add() llist: Move cpu_relax() to after the cmpxchg() llist: Remove the platform-dependent NMI checks llist: Make some llist functions inline sched, tracing: Show PREEMPT_ACTIVE state in trace_sched_switch sched: Remove redundant test in check_preempt_tick() sched: Add documentation for bandwidth control sched: Return unused runtime on group dequeue ...
2011-10-12pstore: make pstore write function return normal success/fail valueChen Gong
Currently pstore write interface employs record id as return value, but it is not enough because it can't tell caller if the write operation is successful. Pass the record id back via an argument pointer and return zero for success, non-zero for failure. Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-10-10x86, nmi: Wire up NMI handlers to new routinesDon Zickus
Just convert all the files that have an nmi handler to the new routines. Most of it is straight forward conversion. A couple of places needed some tweaking like kgdb which separates the debug notifier from the nmi handler and mce removes a call to notify_die. [Thanks to Ying for finding out the history behind that mce call https://lkml.org/lkml/2010/5/27/114 And Boris responding that he would like to remove that call because of it https://lkml.org/lkml/2011/9/21/163] The things that get converted are the registeration/unregistration routines and the nmi handler itself has its args changed along with code removal to check which list it is on (most are on one NMI list except for kgdb which has both an NMI routine and an NMI Unknown routine). Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Corey Minyard <minyard@acm.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Robert Richter <robert.richter@amd.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Corey Minyard <minyard@acm.org> Cc: Jack Steiner <steiner@sgi.com> Link: http://lkml.kernel.org/r/1317409584-23662-4-git-send-email-dzickus@redhat.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-10-04llist: Make some llist functions inlineHuang Ying
Because llist code will be used in performance critical scheduler code path, make llist_add() and llist_del_all() inline to avoid function calling overhead and related 'glue' overhead. Signed-off-by: Huang Ying <ying.huang@intel.com> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1315461646-1379-2-git-send-email-ying.huang@intel.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-08-16pstore: change mutex locking to spin_locksDon Zickus
pstore was using mutex locking to protect read/write access to the backend plug-ins. This causes problems when pstore is executed in an NMI context through panic() -> kmsg_dump(). This patch changes the mutex to a spin_lock_irqsave then also checks to see if we are in an NMI context. If we are in an NMI and can't get the lock, just print a message stating that and blow by the locking. All this is probably a hack around the bigger locking problem but it solves my current situation of trying to sleep in an NMI context. Tested by loading the lkdtm module and executing a HARDLOCKUP which will cause the machine to panic inside the nmi handler. Signed-off-by: Don Zickus <dzickus@redhat.com> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-08-11ACPI APEI: Add Kconfig option IRQ_WORK for GHESChen Gong
IRQ_WORK is used by GHES, but it is selected by PERF_EVENT. For now PERF_EVENT is selected by x86 by default, but in concept, IRQ_WORK should be selected by GHES, not by others. Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-11APEI: Fix WHEA _OSC callMatthew Garrett
Bit 0 of the support parameter to the OSC call should be set in order to indicate that the OS supports the WHEA mechanism. Stuart Hayes tracked an APEI issue on some Dell platforms down to this. Reported-by: Stuart Hayes <Stuart_Hayes@Dell.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03Merge branch 'apei' into apei-releaseLen Brown
Some trivial conflicts due to other various merges adding to the end of common lists sooner than this one. arch/ia64/Kconfig arch/powerpc/Kconfig arch/x86/Kconfig lib/Kconfig lib/Makefile Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03ACPI, APEI, EINJ Param support is disabled by defaultHuang Ying
EINJ parameter support is only usable for some specific BIOS. Originally, it is expected to have no harm for BIOS does not support it. But now, we found it will cause issue (memory overwriting) for some BIOS. So param support is disabled by default and only enabled when newly added module parameter named "param_extension" is explicitly specified. Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: Matthew Garrett <mjg@redhat.com> Acked-by: Don Zickus <dzickus@redhat.com> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03APEI GHES: 32-bit buildfixLen Brown
drivers/acpi/apei/ghes.c:542: warning: integer overflow in expression drivers/acpi/apei/ghes.c:619: warning: integer overflow in expression ghes.c:(.text+0x46289): undefined reference to `__udivdi3'   in function ghes_estatus_cache_add(). Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03ACPI, APEI, GHES: Add hardware memory error recovery supportHuang Ying
memory_failure_queue() is called when recoverable memory errors are notified by firmware to do the recovery work. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03ACPI, APEI, GHES, Error records content based throttleHuang Ying
printk is used by GHES to report hardware errors. Ratelimit is enforced on the printk to avoid too many hardware error reports in kernel log. Because there may be thousands or even millions of corrected hardware errors during system running. Currently, a simple scheme is used. That is, the total number of hardware error reporting is ratelimited. This may cause some issues in practice. For example, there are two kinds of hardware errors occurred in system. One is corrected memory error, because the fault memory address is accessed frequently, there may be hundreds error report per-second. The other is corrected PCIe AER error, it will be reported once per-second. Because they share one ratelimit control structure, it is highly possible that only memory error is reported. To avoid the above issue, an error record content based throttle algorithm is implemented in the patch. Where after the first successful reporting, all error records that are same are throttled for some time, to let other kinds of error records have the opportunity to be reported. In above example, the memory errors will be throttled for some time, after being printked. Then the PCIe AER error will be printked successfully. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-03ACPI, APEI, GHES, printk support for recoverable error via NMIHuang Ying
Some APEI GHES recoverable errors are reported via NMI, but printk is not safe in NMI context. To solve the issue, a lock-less memory allocator is used to allocate memory in NMI handler, save the error record into the allocated memory, put the error record into a lock-less list. On the other hand, an irq_work is used to delay the operation from NMI context to IRQ context. The irq_work IRQ handler will remove nodes from lock-less list, printk the error record and do some further processing include recovery operation, then free the memory. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-22pstore: Make "part" unsignedMatthew Garrett
We'll never have a negative part, so just make this an unsigned int. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-07-22pstore: Add extra context for writes and erasesMatthew Garrett
EFI only provides small amounts of individual storage, and conventionally puts metadata in the storage variable name. Rather than add a metadata header to the (already limited) variable storage, it's easier for us to modify pstore to pass all the information we need to construct a unique variable name to the appropriate functions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-07-22pstore: Extend API for more flexibility in new backendsMatthew Garrett
Some pstore implementations may not have a static context, so extend the API to pass the pstore_info struct to all calls and allow for a context pointer. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-07-13ACPI, APEI, Add WHEA _OSC supportHuang Ying
APEI firmware first mode must be turned on explicitly on some machines, otherwise there may be no GHES hardware error record for hardware error notification. APEI bit in generic _OSC call can be used to do that, but on some machine, a special WHEA _OSC call must be used. This patch adds the support to that WHEA _OSC call. Signed-off-by: Huang Ying <ying.huang@intel.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13ACPI, APEI, GHES, Support disable GHES at boot timeHuang Ying
Some machine may have broken firmware so that GHES and firmware first mode should be disabled. This patch adds support to that. Signed-off-by: Huang Ying <ying.huang@intel.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13ACPI, APEI, GHES, Prevent GHES to be built as moduleHuang Ying
GHES (Generic Hardware Error Source) is used to process hardware error notification in firmware first mode. But because firmware first mode can be turned on but can not be turned off, it is unreasonable to unload the GHES module with firmware first mode turned on. To avoid confusion, this patch makes GHES can be enabled/disabled in configuration time, but not built as module and unloaded at run time. Signed-off-by: Huang Ying <ying.huang@intel.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13ACPI, APEI, Use apei_exec_run_optional in APEI EINJ and ERSTHuang Ying
This patch changes APEI EINJ and ERST to use apei_exec_run for mandatory actions, and apei_exec_run_optional for optional actions. Cc: Thomas Renninger <trenn@novell.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13ACPI, APEI, Add apei_exec_run_optionalHuang Ying
Some actions in APEI ERST and EINJ tables are optional, for example, ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for error injection, and firmware may choose to do nothing here. While some other actions are mandatory, for example, firmware must provide ACPI_EINJ_GET_ERROR_TYPE implementation. Original implementation treats all actions as optional (that is, can have no instructions), that may cause issue if firmware does not provide some mandatory actions. To fix this, this patch adds apei_exec_run_optional, which should be used for optional actions. The original apei_exec_run should be used for mandatory actions. Cc: Thomas Renninger <trenn@novell.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>