Re: [PATCH V3] acpi: apei: clear error status before acknowledging the error

On 8/29/2017 2:16 AM, Borislav Petkov wrote: On Mon, Aug 28, 2017 at 10:53:41AM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing

Re: [PATCH V3] acpi: apei: clear error status before acknowledging the error

On 8/29/2017 2:16 AM, Borislav Petkov wrote: On Mon, Aug 28, 2017 at 10:53:41AM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/30/2017 11:14 AM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 09:42:08AM -0600, Baicar, Tyler wrote: I think with my two patches we will have the desired functionality: GHES_SEV_CORRECTABLE -> AER_CORRECTABLE -> Print AER info, but do not call do_recovery GHES_SEV_RECOV

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/30/2017 11:14 AM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 09:42:08AM -0600, Baicar, Tyler wrote: I think with my two patches we will have the desired functionality: GHES_SEV_CORRECTABLE -> AER_CORRECTABLE -> Print AER info, but do not call do_recovery GHES_SEV_RECOV

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/30/2017 9:31 AM, Sinan Kaya wrote: On 8/30/2017 11:16 AM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 10:05:44AM -0400, Sinan Kaya wrote: Link reset is not the only recovery mechanism. In the case of nonfatal errors, it is assumed that the endpoint CSR is still reachable. Error is

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/30/2017 9:31 AM, Sinan Kaya wrote: On 8/30/2017 11:16 AM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 10:05:44AM -0400, Sinan Kaya wrote: Link reset is not the only recovery mechanism. In the case of nonfatal errors, it is assumed that the endpoint CSR is still reachable. Error is

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/29/2017 2:20 AM, Borislav Petkov wrote: On Mon, Aug 28, 2017 at 11:11:54AM -0600, Tyler Baicar wrote: Currently the GHES code only calls into the AER driver for recoverable type errors. This is incorrect because errors of other severities do not get logged by the AER driver and do not get

Re: [PATCH] acpi: apei: call into AER handling regardless of severity

On 8/29/2017 2:20 AM, Borislav Petkov wrote: On Mon, Aug 28, 2017 at 11:11:54AM -0600, Tyler Baicar wrote: Currently the GHES code only calls into the AER driver for recoverable type errors. This is incorrect because errors of other severities do not get logged by the AER driver and do not get

Re: [PATCH V2] acpi: apei: clear error status before acknowledging the error

On 8/24/2017 2:14 AM, Borislav Petkov wrote: On Thu, Aug 03, 2017 at 04:12:31PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing

Re: [PATCH V2] acpi: apei: clear error status before acknowledging the error

On 8/24/2017 2:14 AM, Borislav Petkov wrote: On Thu, Aug 03, 2017 at 04:12:31PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing

Re: [PATCH V2] acpi: apei: clear error status before acknowledging the error

Hello Boris, And input on this patch? Thanks, Tyler On 8/3/2017 4:12 PM, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would

Re: [PATCH V2] acpi: apei: clear error status before acknowledging the error

Hello Boris, And input on this patch? Thanks, Tyler On 8/3/2017 4:12 PM, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would

Re: [PATCH v3] acpi: apei: fix the wrongly iterate generic error status block

On 8/16/2017 2:14 AM, Dongjiu Geng wrote: The revision 0x300 generic error data entry is different from the old version, but currently iterating through the GHES estatus blocks does not take into account this difference. This will lead to failure to get the right data entry if GHES has revision

Re: [PATCH v3] acpi: apei: fix the wrongly iterate generic error status block

On 8/16/2017 2:14 AM, Dongjiu Geng wrote: The revision 0x300 generic error data entry is different from the old version, but currently iterating through the GHES estatus blocks does not take into account this difference. This will lead to failure to get the right data entry if GHES has revision

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 3:34 PM, gengdongjiu wrote: Hi Tyler , Hello Boris, His patch fixes the define for apei_estatus_for_each_section which in turn should fix ghes_do_proc(). So my patch should no longer be needed. I'm going to test this out just to verify if fixes the issue I found. I have verified

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 3:34 PM, gengdongjiu wrote: Hi Tyler , Hello Boris, His patch fixes the define for apei_estatus_for_each_section which in turn should fix ghes_do_proc(). So my patch should no longer be needed. I'm going to test this out just to verify if fixes the issue I found. I have verified

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 10:55 AM, Borislav Petkov wrote: On Wed, Aug 16, 2017 at 12:42:43AM +0800, gengdongjiu wrote: I ever discuss it with Tyler about it, as shown below link, thanks https://lkml.org/lkml/2017/8/14/355 Tyler's patch fixes ghes_do_proc() - yours cper_estatus_print(). How is that

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 10:55 AM, Borislav Petkov wrote: On Wed, Aug 16, 2017 at 12:42:43AM +0800, gengdongjiu wrote: I ever discuss it with Tyler about it, as shown below link, thanks https://lkml.org/lkml/2017/8/14/355 Tyler's patch fixes ghes_do_proc() - yours cper_estatus_print(). How is that

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

On 8/11/2017 5:41 PM, gengdongjiu wrote: 2017-08-11 21:19 GMT+08:00 Baicar, Tyler <tbai...@codeaurora.org>: I removed the apei_estatus_for_each_section because it was only being used in this one spot even though several other parts of the code do the same iteration (it is done several

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

On 8/11/2017 5:41 PM, gengdongjiu wrote: 2017-08-11 21:19 GMT+08:00 Baicar, Tyler : I removed the apei_estatus_for_each_section because it was only being used in this one spot even though several other parts of the code do the same iteration (it is done several times in the CPER code). I made

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

can be simpleness and reserve the macro of apei_estatus_for_each_section can be used by other place to avoid duplicated code, such as prints the estatus blocks. On 2017/8/11 1:48, Baicar, Tyler wrote: Hello, I have already posted a patch fixing this. Please see: https://lkml.org/lkml/2017/8/3

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

can be simpleness and reserve the macro of apei_estatus_for_each_section can be used by other place to avoid duplicated code, such as prints the estatus blocks. On 2017/8/11 1:48, Baicar, Tyler wrote: Hello, I have already posted a patch fixing this. Please see: https://lkml.org/lkml/2017/8/3

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On 8/10/2017 4:04 PM, gengdongjiu wrote: On 2017/8/9 8:52, Rafael J. Wysocki wrote: On Tuesday, August 8, 2017 6:32:20 PM CEST Will Deacon wrote: On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: Currently iterating through the GHES estatus blocks does not take into account the

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On 8/10/2017 4:04 PM, gengdongjiu wrote: On 2017/8/9 8:52, Rafael J. Wysocki wrote: On Tuesday, August 8, 2017 6:32:20 PM CEST Will Deacon wrote: On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: Currently iterating through the GHES estatus blocks does not take into account the

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

Hello, I have already posted a patch fixing this. Please see: https://lkml.org/lkml/2017/8/3/824 This makes the loop identical to the CPER code which prints the estatus blocks to the kernel logs. Thanks, Tyler On 8/10/2017 12:06 PM, Dongjiu Geng wrote: The revision 0x300 generic error

Re: [PATCH] acpi: apei: fix the wrongly parse generic error status block

Hello, I have already posted a patch fixing this. Please see: https://lkml.org/lkml/2017/8/3/824 This makes the loop identical to the CPER code which prints the estatus blocks to the kernel logs. Thanks, Tyler On 8/10/2017 12:06 PM, Dongjiu Geng wrote: The revision 0x300 generic error

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:44 AM, Baicar, Tyler wrote: On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:44 AM, Baicar, Tyler wrote: On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:11 AM, James Morse wrote: Hi Tyler, On 31/07/17 17:15, Baicar, Tyler wrote: On 7/29/2017 12:53 AM, Borislav Petkov wrote: On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:11 AM, James Morse wrote: Hi Tyler, On 31/07/17 17:15, Baicar, Tyler wrote: On 7/29/2017 12:53 AM, Borislav Petkov wrote: On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus or the estatus is empty/invalid. Right now we

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus or the estatus is empty/invalid. Right now we

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/29/2017 12:53 AM, Borislav Petkov wrote: On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/29/2017 12:53 AM, Borislav Petkov wrote: On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status

Re: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption

On 6/30/2017 4:10 AM, Robert Richter wrote: Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS

Re: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption

On 6/30/2017 4:10 AM, Robert Richter wrote: Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS

Re: [PATCH v5] trace: ras: add ARM processor error information trace event

On 6/27/2017 1:25 AM, Borislav Petkov wrote: On Tue, Jun 27, 2017 at 02:51:22PM +0800, Xie XiuQi wrote: How about we report the full info via arm_err_info_event which just for someone who want the detail information, and leave arm_event closed. If someone do not care the error detail, who could

Re: [PATCH v5] trace: ras: add ARM processor error information trace event

On 6/27/2017 1:25 AM, Borislav Petkov wrote: On Tue, Jun 27, 2017 at 02:51:22PM +0800, Xie XiuQi wrote: How about we report the full info via arm_err_info_event which just for someone who want the detail information, and leave arm_event closed. If someone do not care the error detail, who could

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/21/2017 3:21 AM, Will Deacon wrote: Hi Tyler, On Tue, Jun 20, 2017 at 12:26:01PM -0600, Baicar, Tyler wrote: On 6/20/2017 12:20 PM, Will Deacon wrote: On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: I have sent you the rebased patches. I took Christoph's uuid-types tree

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/21/2017 3:21 AM, Will Deacon wrote: Hi Tyler, On Tue, Jun 20, 2017 at 12:26:01PM -0600, Baicar, Tyler wrote: On 6/20/2017 12:20 PM, Will Deacon wrote: On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: I have sent you the rebased patches. I took Christoph's uuid-types tree

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/20/2017 12:20 PM, Will Deacon wrote: On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: I have sent you the rebased patches. I took Christoph's uuid-types tree and added this patch onto it: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") And the

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/20/2017 12:20 PM, Will Deacon wrote: On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote: I have sent you the rebased patches. I took Christoph's uuid-types tree and added this patch onto it: 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types") And the

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/20/2017 2:47 AM, Andy Shevchenko wrote: On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote: On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote: To have better coordination, please, look at my WIP branch regarding UUID stuff:

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/20/2017 2:47 AM, Andy Shevchenko wrote: On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote: On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote: To have better coordination, please, look at my WIP branch regarding UUID stuff:

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/19/2017 12:41 PM, Baicar, Tyler wrote: On 6/19/2017 4:22 AM, Will Deacon wrote: On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: Hi Stephen, Christoph, Tyler, On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/19/2017 12:41 PM, Baicar, Tyler wrote: On 6/19/2017 4:22 AM, Will Deacon wrote: On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: Hi Stephen, Christoph, Tyler, On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/19/2017 4:22 AM, Will Deacon wrote: On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: Hi Stephen, Christoph, Tyler, On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: Apologies for this: I've just dropped

Re: linux-next: manual merge of the uuid tree with the arm64 tree

On 6/19/2017 4:22 AM, Will Deacon wrote: On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote: On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote: Hi Stephen, Christoph, Tyler, On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote: Apologies for this: I've just dropped

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 10:55 AM, Borislav Petkov wrote: On Tue, May 16, 2017 at 10:44:43AM -0600, Baicar, Tyler wrote: I meant to respond to this comment after I sent the v16 patch series, but you beat me to it :) These prefixes are common to all the GHES/CPER printing to the kernel logs. I don't mean

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 10:55 AM, Borislav Petkov wrote: On Tue, May 16, 2017 at 10:44:43AM -0600, Baicar, Tyler wrote: I meant to respond to this comment after I sent the v16 patch series, but you beat me to it :) These prefixes are common to all the GHES/CPER printing to the kernel logs. I don't mean

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 8:29 AM, Borislav Petkov wrote: On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 8:29 AM, Borislav Petkov wrote: On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On 5/8/2017 11:28 AM, James Morse wrote: Hi Tyler, On 19/04/17 00:05, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On 5/8/2017 11:28 AM, James Morse wrote: Hi Tyler, On 19/04/17 00:05, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then

Re: [PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

On 5/8/2017 11:40 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:23PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in

Re: [PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

On 5/8/2017 11:40 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:23PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On 4/25/2017 11:21 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification

Re: [PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

On 4/25/2017 11:21 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:18PM -0600, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification

Re: [PATCH V15 04/11] efi: parse ARM processor error

On 4/24/2017 11:52 AM, Borislav Petkov wrote: On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote: I guess it's not really needed. It just may be useful considering there can be numerous error info structures, numerous context info structures, and a variable length vendor information

Re: [PATCH V15 04/11] efi: parse ARM processor error

On 4/24/2017 11:52 AM, Borislav Petkov wrote: On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote: I guess it's not really needed. It just may be useful considering there can be numerous error info structures, numerous context info structures, and a variable length vendor information

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/21/2017 4:28 PM, Sinan Kaya wrote: GED driver is currently set up as a platform driver. On modern operating systems, most of the drivers are compiled as kernel modules. It is possible that a GED interrupt event is received and the driver such as GHES/GPIO/I2C to service it is not available

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/21/2017 4:28 PM, Sinan Kaya wrote: GED driver is currently set up as a platform driver. On modern operating systems, most of the drivers are compiled as kernel modules. It is possible that a GED interrupt event is received and the driver such as GHES/GPIO/I2C to service it is not available

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On 4/21/2017 6:21 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:15PM -0600, Tyler Baicar wrote: The ACPI 6.1 spec added a timestamp to the HEST generic data HEST? I see the timestamp in Table 18-343 Generic Error Data Entry where those things are "One or more Generic Error Data

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On 4/21/2017 6:21 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:15PM -0600, Tyler Baicar wrote: The ACPI 6.1 spec added a timestamp to the HEST generic data HEST? I see the timestamp in Table 18-343 Generic Error Data Entry where those things are "One or more Generic Error Data

Re: [PATCH V15 04/11] efi: parse ARM processor error

On 4/21/2017 11:55 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:16PM -0600, Tyler Baicar wrote: Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This

Re: [PATCH V15 04/11] efi: parse ARM processor error

On 4/21/2017 11:55 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:16PM -0600, Tyler Baicar wrote: Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On 4/21/2017 11:26 AM, Borislav Petkov wrote: On Fri, Apr 21, 2017 at 10:04:35AM -0600, Baicar, Tyler wrote: This is basically what I already had in v14...you asked to move it into a different if-statement? https://lkml.org/lkml/2017/4/12/397 Well, clearly I've been smoking some nasty potent

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On 4/21/2017 11:26 AM, Borislav Petkov wrote: On Fri, Apr 21, 2017 at 10:04:35AM -0600, Baicar, Tyler wrote: This is basically what I already had in v14...you asked to move it into a different if-statement? https://lkml.org/lkml/2017/4/12/397 Well, clearly I've been smoking some nasty potent

Re: [PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

On 4/19/2017 12:31 PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:13PM -0600, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS.

Re: [PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

On 4/19/2017 12:31 PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 05:05:13PM -0600, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS.

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 4/16/2017 9:16 PM, Xie XiuQi wrote: On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 4/16/2017 9:16 PM, Xie XiuQi wrote: On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which

Re: [PATCH 1/3] arm64: hugetlb: Fix huge_pte_offset to return poisoned page table entries

On 4/12/2017 8:04 AM, Punit Agrawal wrote: When memory failure is enabled, a poisoned hugepage pte is marked as a swap entry. huge_pte_offset() does not return the poisoned page table entries when it encounters PUD/PMD hugepages. This behaviour of huge_pte_offset() leads to error such as below

Re: [PATCH 1/3] arm64: hugetlb: Fix huge_pte_offset to return poisoned page table entries

On 4/12/2017 8:04 AM, Punit Agrawal wrote: When memory failure is enabled, a poisoned hugepage pte is marked as a swap entry. huge_pte_offset() does not return the poisoned page table entries when it encounters PUD/PMD hugepages. This behaviour of huge_pte_offset() leads to error such as below

Re: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

On 4/13/2017 2:47 PM, Borislav Petkov wrote: On Thu, Apr 13, 2017 at 02:30:21PM -0600, Baicar, Tyler wrote: I do not agree with this. The struct being passed to this function is already named acpi_hest_generic_data in the existing code and all over this code is named gdata not just d. And I'm

Re: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

On 4/13/2017 2:47 PM, Borislav Petkov wrote: On Thu, Apr 13, 2017 at 02:30:21PM -0600, Baicar, Tyler wrote: I do not agree with this. The struct being passed to this function is already named acpi_hest_generic_data in the existing code and all over this code is named gdata not just d. And I'm

Re: [PATCH V14 03/10] efi: parse ARM processor error

On 4/12/2017 10:51 AM, Borislav Petkov wrote: On Tue, Mar 28, 2017 at 01:30:33PM -0600, Tyler Baicar wrote: Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This

Re: [PATCH V14 03/10] efi: parse ARM processor error

On 4/12/2017 10:51 AM, Borislav Petkov wrote: On Tue, Mar 28, 2017 at 01:30:33PM -0600, Tyler Baicar wrote: Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This

Re: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

On 4/12/2017 7:34 AM, Borislav Petkov wrote: Subject: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Use a verb in your patch subjects: "Add support for ..." or so. Hello Boris, Will do in the next version. On Tue, Mar 28, 2017 at 01:30:32PM -0600, Tyler

Re: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

On 4/12/2017 7:34 AM, Borislav Petkov wrote: Subject: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Use a verb in your patch subjects: "Add support for ..." or so. Hello Boris, Will do in the next version. On Tue, Mar 28, 2017 at 01:30:32PM -0600, Tyler

Re: [PATCH V14 01/10] acpi: apei: read ack upon ghes record consumption

On 4/11/2017 11:15 AM, Borislav Petkov wrote: On Tue, Mar 28, 2017 at 01:30:31PM -0600, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS.

Re: [PATCH V14 01/10] acpi: apei: read ack upon ghes record consumption

On 4/11/2017 11:15 AM, Borislav Petkov wrote: On Tue, Mar 28, 2017 at 01:30:31PM -0600, Tyler Baicar wrote: A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS.

Re: [PATCH V2] acpi: apei: check for pending errors when probing HED type GHES entries

Hello James, On 3/30/2017 11:30 AM, James Morse wrote: On 29/03/17 16:54, Tyler Baicar wrote: If a HED type error occurs prior to GHES probing, the kernel will never report the error. The HED driver will see that no notifiers are registered, and clear the interrupt. This becomes a more

Re: [PATCH V2] acpi: apei: check for pending errors when probing HED type GHES entries

Hello James, On 3/30/2017 11:30 AM, James Morse wrote: On 29/03/17 16:54, Tyler Baicar wrote: If a HED type error occurs prior to GHES probing, the kernel will never report the error. The HED driver will see that no notifiers are registered, and clear the interrupt. This becomes a more

Re: [PATCH] acpi: apei: check for pending errors when probing HED type GHES entries

On 3/28/2017 4:00 PM, Al Stone wrote: On 03/28/2017 02:14 PM, Tyler Baicar wrote: If a HED type error occurs prior to GHES probing, the kernel will never report the error. The HED driver will see that no notifiers are registers, and clear the interrupt. ..."registers" or "registered"? Oops :)

Re: [PATCH] acpi: apei: check for pending errors when probing HED type GHES entries

On 3/28/2017 4:00 PM, Al Stone wrote: On 03/28/2017 02:14 PM, Tyler Baicar wrote: If a HED type error occurs prior to GHES probing, the kernel will never report the error. The HED driver will see that no notifiers are registers, and clear the interrupt. ..."registers" or "registered"? Oops :)

Re: [PATCH V14 10/10] arm/arm64: KVM: add guest SEA support

Hello Christoffer, On 3/28/2017 2:26 PM, Christoffer Dall wrote: On Tue, Mar 28, 2017 at 01:30:40PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel.

Re: [PATCH V14 10/10] arm/arm64: KVM: add guest SEA support

Hello Christoffer, On 3/28/2017 2:26 PM, Christoffer Dall wrote: On Tue, Mar 28, 2017 at 01:30:40PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel.

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello, On 3/28/2017 3:53 AM, gengdongjiu wrote: Hi, On 2017/3/22 6:47, Tyler Baicar wrote: + fault_ipa = kvm_vcpu_get_fault_ipa(vcpu); + + /* The host kernel will handle the synchronous external abort. There +* is no need to pass the error into the guest. +*/ +

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello, On 3/28/2017 3:53 AM, gengdongjiu wrote: Hi, On 2017/3/22 6:47, Tyler Baicar wrote: + fault_ipa = kvm_vcpu_get_fault_ipa(vcpu); + + /* The host kernel will handle the synchronous external abort. There +* is no need to pass the error into the guest. +*/ +

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello, On 3/27/2017 10:19 PM, gengdongjiu wrote: Hi Tyler, I have a question for below code. On 2017/3/25 0:01, Christoffer Dall wrote: is_iabt = kvm_vcpu_trap_is_iabt(vcpu); - if (unlikely(!is_iabt && kvm_vcpu_dabt_isextabt(vcpu))) { + if (unlikely(!is_iabt &&

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello, On 3/27/2017 10:19 PM, gengdongjiu wrote: Hi Tyler, I have a question for below code. On 2017/3/25 0:01, Christoffer Dall wrote: is_iabt = kvm_vcpu_trap_is_iabt(vcpu); - if (unlikely(!is_iabt && kvm_vcpu_dabt_isextabt(vcpu))) { + if (unlikely(!is_iabt &&

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello Christoffer, On 3/24/2017 10:01 AM, Christoffer Dall wrote: On Tue, Mar 21, 2017 at 04:47:05PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel.

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello Christoffer, On 3/24/2017 10:01 AM, Christoffer Dall wrote: On Tue, Mar 21, 2017 at 04:47:05PM -0600, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel.

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello Marc, On 3/24/2017 8:03 AM, Marc Zyngier wrote: On 21/03/17 22:47, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar

Re: [PATCH V13 10/10] arm/arm64: KVM: add guest SEA support

Hello Marc, On 3/24/2017 8:03 AM, Marc Zyngier wrote: On 21/03/17 22:47, Tyler Baicar wrote: Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar ---

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

On 3/23/2017 10:12 AM, Punit Agrawal wrote: On 23/03/17 14:33, James Morse wrote: Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

On 3/23/2017 10:12 AM, Punit Agrawal wrote: On 23/03/17 14:33, James Morse wrote: Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when

  1   2   3   >