On 10/19/2013 04:56 PM, Chen Gong wrote:
On Fri, Oct 18, 2013 at 05:31:21PM +0530, Naveen N. Rao wrote:
Date: Fri, 18 Oct 2013 17:31:21 +0530
From: "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxxxxxxx>
To: "Chen, Gong" <gong.chen@xxxxxxxxxxxxxxx>, tony.luck@xxxxxxxxx,
bp@xxxxxxxxx, joe@xxxxxxxxxxx, m.chehab@xxxxxxxxxxx
CC: arozansk@xxxxxxxxxx, linux-acpi@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v3 8/9] ACPI, APEI, CPER: Cleanup CPER memory error
output format
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.0
[...]
@@ -358,17 +349,21 @@ void cper_estatus_print(const char *pfx,
struct acpi_generic_data *gdata;
unsigned int data_len, gedata_len;
int sec_no = 0;
+ char newpfx[64];
__u16 severity;
- printk("%s""Generic Hardware Error Status\n", pfx);
severity = estatus->error_severity;
- printk("%s""severity: %d, %s\n", pfx, severity,
- cper_severity_str(severity));
+ if (severity != CPER_SEV_FATAL)
Shouldn't this just be (severity == CPER_SEV_CORRECTED)?
Thanks,
Naveen
IMO, only fatal error can't be handlered gracefully in current
kernel plus H/W. Once it can be recovered by H/W and OS, we
can call it recovered.
Sure, but we don't recover in all scenarios. So, calling it corrected
seems incorrect to me.
- Naveen
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
