> @Tony: I'll send it upwards soonish in case there are no objections.
> This way no stable backport will be needed.
Acked-by: Tony Luck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
On Thu, Oct 18, 2012 at 11:13:14AM +0530, Naveen N. Rao wrote:
> On 10/17/2012 10:58 PM, Luck, Tony wrote:
> >BUT (squared) do you even really need to know that thresholds were set? You
> >could look at bits {52:38} in the MCi_STATUS information for the bank to see
> >how many corrected errors had
On 10/17/2012 10:58 PM, Luck, Tony wrote:
BUT (squared) do you even really need to know that thresholds were set? You
could look at bits {52:38} in the MCi_STATUS information for the bank to see
how many corrected errors had been logged.
Ah, nice. I think we should be able to use this instead o
On Wed, Oct 17, 2012 at 05:28:11PM +, Luck, Tony wrote:
> > What's wrong with userspace tools parsing /proc/cmdline and seeing that
> > mce_bios_cmci_threshold has been set since this is the only way to set
> > it anyway?
>
> The argument might be on the command line, but may have been rejecte
> What's wrong with userspace tools parsing /proc/cmdline and seeing that
> mce_bios_cmci_threshold has been set since this is the only way to set
> it anyway?
The argument might be on the command line, but may have been rejected
because the BIOS didn't set the thresholds? So then you'd have to lo
On Wed, Oct 17, 2012 at 09:17:39PM +0530, Naveen N. Rao wrote:
> Userspace tools need this sysfs attribute so they know how to react on
> receipt of a corrected error event: whether this is the first event or
> if such events have already been threshold-ed.
What's wrong with userspace tools parsin
On 10/17/2012 06:39 PM, Borislav Petkov wrote:
On Wed, Oct 17, 2012 at 04:57:30PM +0530, Naveen N. Rao wrote:
On 10/17/2012 04:29 PM, Borislav Petkov wrote:
+static struct dev_ext_attribute dev_attr_bios_cmci_threshold = {
+ __ATTR(bios_cmci_threshold, 0444, device_show_int, NULL),
+
On Wed, Oct 17, 2012 at 04:57:30PM +0530, Naveen N. Rao wrote:
> On 10/17/2012 04:29 PM, Borislav Petkov wrote:
> >>>
> >>>+static struct dev_ext_attribute dev_attr_bios_cmci_threshold = {
> >>>+ __ATTR(bios_cmci_threshold, 0444, device_show_int, NULL),
> >>>+ &mce_bios_cmci_threshold
> >
> >Ok,
On 10/17/2012 04:29 PM, Borislav Petkov wrote:
+static struct dev_ext_attribute dev_attr_bios_cmci_threshold = {
+ __ATTR(bios_cmci_threshold, 0444, device_show_int, NULL),
+ &mce_bios_cmci_threshold
Ok, I just noticed this (we must've missed it during review) but why is
this read-
On Fri, Sep 21, 2012 at 05:09:04PM +0530, Naveen N. Rao wrote:
> Hi Tony,
> Can you kindly take in this patch if there are no further comments?
>
> Thanks,
> Naveen
>
> On 09/12/2012 05:55 PM, Naveen N. Rao wrote:
> >The ACPI spec doesn't provide for a way for the bios to pass down
> >recommended
Hi Tony,
Can you kindly take in this patch if there are no further comments?
Thanks,
Naveen
On 09/12/2012 05:55 PM, Naveen N. Rao wrote:
The ACPI spec doesn't provide for a way for the bios to pass down
recommended thresholds to the OS on a _per-bank_ basis. This patch adds
a new boot option, w
The ACPI spec doesn't provide for a way for the bios to pass down
recommended thresholds to the OS on a _per-bank_ basis. This patch adds
a new boot option, which if passed, allows bios to initialize the CMCI
threshold. In such a case, we simply skip programming any threshold
value.
As fail-safe,
12 matches
Mail list logo
