- 14 7月, 2012 1 次提交
-
-
由 Jean 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=43282Signed-off-by: NJean Delvare <jdelvare@suse.de> Acked-by: NHuang Ying <ying.huang@intel.com> Acked-by: NGary Hade <garyhade@us.ibm.com> Cc: stable@vger.kernel.org [3.4+] Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 6月, 2012 1 次提交
-
-
由 Huang 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: NPawel Sikora <pluto@agmk.net> Signed-off-by: NHuang Ying <ying.huang@intel.com> Tested-by: NJean Delvare <khali@linux-fr.org> Cc: stable@vger.kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 3月, 2012 1 次提交
-
-
由 Gary 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: NGary Hade <garyhade@us.ibm.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 3月, 2012 1 次提交
-
-
由 Bob 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: NBob Moore <robert.moore@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 1月, 2012 1 次提交
-
-
由 Myron 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 04c25997, 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: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 1月, 2012 4 次提交
-
-
由 Myron 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() (29718521) and enhanced acpi_read() so it works in interrupt context as long as the address has been previously mapped (620242ae). 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: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Huang 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: NPavel Ivanov <paivanof@gmail.com> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Huang 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: NHuang Ying <ying.huang@intel.com> Tested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Use the normal %pR-like format for MMIO and I/O port ranges. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 8月, 2011 1 次提交
-
-
由 Matthew 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: NStuart Hayes <Stuart_Hayes@Dell.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 7月, 2011 2 次提交
-
-
由 Huang 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: NHuang Ying <ying.huang@intel.com> Reviewed-by: NAndi Kleen <ak@linux.intel.com> Reviewed-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Huang 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: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 9月, 2010 1 次提交
-
-
由 Huang Ying 提交于
In ERST debug/test support patch, a dynamic allocated buffer is used. The may-failed memory allocation should be tried firstly before free the previous buffer. APEI resource management memory allocation related error path is fixed too. v2: - Fix error messages for APEI resources management Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 09 8月, 2010 1 次提交
-
-
由 Huang Ying 提交于
Fix a typo of error path of apei_resources_request. release_mem_region and release_region should be interchange. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 6月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by: NTejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
-
- 20 5月, 2010 1 次提交
-
-
由 Huang Ying 提交于
APEI stands for ACPI Platform Error Interface, which allows to report errors (for example from the chipset) to the operating system. This improves NMI handling especially. In addition it supports error serialization and error injection. For more information about APEI, please refer to ACPI Specification version 4.0, chapter 17. This patch provides some common functions used by more than one APEI tables, mainly framework of interpreter for EINJ and ERST. A machine readable language is defined for EINJ and ERST for OS to execute, and so to drive the firmware to fulfill the corresponding functions. The machine language for EINJ and ERST is compatible, so a common framework is defined for them. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-