On Wed, Oct 11, 2017 at 12:50:04PM +0000, David Laight wrote: > From: David Laight > > Sent: 11 October 2017 11:04 > ... > > > > On that system (XEON E5-2600) dmesg contains (retyped): > > > > acpi: PNP0A08:00: _OSC: platform does not support [AER] > > > > > > Per the PCI Firmware spec r3.0, sec 4.5.1, on ACPI platforms, the OS > > > is supposed to use _OSC to ask the firmware for permission before > > > using AER. In this case, the firmware declined to grant us > > > permission, so we're not supposed to do anything at all with AER. > > > > I read that as 'BIOS knows nothing about AER' rather than 'BIOS > > refused to hand over control' - but I could be wrong. > > > > I'm not sure where to look to see if the actual hardware does. > > I'm guessing that Intel Haswell-E should. > > I've four Haswell root port bridges with the AER block at offset 148. > None of them have anything in the three 'root error registers'. > > So the firmware/bios can't be using the registers - which means the > OS could use them. The current Linux behavior is based on the spec I cited above, which says If any bits in the Control Field are returned cleared (masked to zero) by the _OSC control method, the respective feature is designated unsupported by the platform and must not be enabled by the operating system. Some of these features may be controlled by platform firmware prior to operating system boot or during runtime for a legacy operating system, while others may be disabled/inoperative until native operating system support is available. If Linux is handling _OSC correctly (always a question, since it's quite complicated), it sounds like your platform is telling Linux not to enable AER. You could experimentally make Linux enable AER anyway, but it's hard for me to see how we could do that safely in general. The short answer probably is "complain to your platform vendor". Bjorn
