Messages in this thread | | | Subject | Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal. | From | "Alex G." <> | Date | Wed, 25 Apr 2018 10:00:53 -0500 |
| |
On 04/25/2018 09:01 AM, Borislav Petkov wrote: > On Mon, Apr 23, 2018 at 11:19:25PM -0500, Alex G. wrote: >> That tells you what FFS said about the error. > > I betcha those status and command values have a human-readable counterparts. > > Btw, what do you abbreviate with "FFS"?
Firmware-first.
>> It's immediately obvious if there's a glaring FFS bug and if we get bogus >> data. If you distrust firmware as much as I do, then you will find great >> value in having such info in the logs. It's probably not too useful to a >> casual user, but then neither is a majority of the system log. > > No no, you're missing the point - I *want* all data in the error log > which helps debug a hardware issue. I just want it humanly readable so > that I don't have to jot down the values and go scour the manuals to map > what it actually means.
We could probably use more of the native AER print functions, but that's beyond the scope of this patch. I tried something like this [1], but have given up following the PCI maintainer's radio silence. I don't care _that_ much about the log format.
[1] http://www.spinics.net/lists/linux-pci/msg71422.html
>> You're missing the timing and assuming you will get the hotplug interrupt. >> In this example, you have 22ms between the link down and presence detect >> state change. This is a fairly fast removal. >> >> Hotplug dependencies aside (you can have the kernel run without PCIe hotplug >> support), I don't think you want to just linger in NMI for dozens of >> milliseconds waiting for presence detect confirmation. > > No, I don't mean that. I mean something like deferred processing:
Like the exact thing that this patch series implements? :)
> you > get an error, you notice it is a device which supports physical removal > so you exit the NMI handler and process the error in normal, process > context which allows you to query the device and say, "Hey device, are > you still there?"
Like the exact way the AER handler works?
> If it is not, you drop all the hw I/O errors reported for it.
Like the PCI error recovery mechanisms that AER invokes?
> Hmmm? Hmmm
| |