Re: [PATCH v3] x86/mce: Honour bios-set CMCI threshold

From: Naveen N. Rao
Date: Wed Oct 17 2012 - 11:48:18 EST


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),
+ &mce_bios_cmci_threshold

Ok, I just noticed this (we must've missed it during review) but why is
this read-only? If it has to be read-only, why do we have a node for
this in sysfs instead of simply issuing the printk statements below and
people who are interested in this, can grep dmesg?

This was added so that user-space tools could find out if we're
using thresholds for CMCI.

That I figured out.

What I can't figure out is why userspace tools need to know that - the
fact that some MCI_CTL2 has a 0 CMCI threshold because BIOS forgot to
set it correctly? IOW, this is a rather evolved workaround for b0rked
BIOS (the gazillionth BIOS f*ckup, btw if someone is counting :)) and,
on top of that, we have a read-only, special sysfs node which is pretty
useless to me.

Why?


This is not about the CMCI threshold being 0, but rather about the threshold not being 1. Linux used to program a threshold of 1 always but with this boot option, a firmware-set non-zero threshold is honoured.

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.


Regards,
Naveen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/