| Message ID | 20180425203957.18224-4-mr.nuke.me@gmail.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: > There seems to be a culture amongst BIOS teams to want to crash the > OS when an error can't be handled in firmware. Marking GHES errors as > "fatal" is a very common way to do this. > > However, a number of errors reported by GHES may be fatal in the sense > a device or link is lost, but are not fatal to the system. When there > is a disagreement with firmware about the handleability of an error, > print a warning message. > > Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> > --- > drivers/acpi/apei/ghes.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index 8ccb9cc10fc8..34d0da692dd0 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -539,6 +539,12 @@ static void ghes_do_proc(struct ghes *ghes, > sec_sev, err, > gdata->error_data_length); > } > + > + } > + > + if ((sev >= GHES_SEV_PANIC) && (ghes_actual_severity(ghes) < sev)) { > + pr_warn("FIRMWARE BUG: Firmware sent fatal error that we were able to correct"); > + pr_warn("BROKEN FIRMWARE: Complain to your hardware vendor"); Pasting the same comment from last time since you missed it: "No, I don't want any of that crap issuing stuff in dmesg and then people opening bugs and running around and trying to replace hardware. We either can handle the error and log a normal record somewhere or we cannot and explode. The complaining about the FW doesn't bring shit."
On 04/26/2018 06:20 AM, Borislav Petkov wrote: > Pasting the same comment from last time since you missed it: > > "No, I don't want any of that crap issuing stuff in dmesg and then people > opening bugs and running around and trying to replace hardware. > > We either can handle the error and log a normal record somewhere or we > cannot and explode. The complaining about the FW doesn't bring shit." " Borislav, if you don't like the third patch in the series, feel free to leave it out. THings will work beautifully with or without it." :) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 26, 2018 at 12:47:30PM -0500, Alex G. wrote: > " Borislav, if you don't like the third patch in the series, feel free to > leave it out. THings will work beautifully with or without it." Then don't send it.
On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: > On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: > > There seems to be a culture amongst BIOS teams to want to crash the > > OS when an error can't be handled in firmware. Marking GHES errors as > > "fatal" is a very common way to do this. > > > > However, a number of errors reported by GHES may be fatal in the sense > > a device or link is lost, but are not fatal to the system. When there > > is a disagreement with firmware about the handleability of an error, > > print a warning message. > > + > > + if ((sev >= GHES_SEV_PANIC) && (ghes_actual_severity(ghes) < sev)) { > > + pr_warn("FIRMWARE BUG: Firmware sent fatal error that we were able to correct"); > > + pr_warn("BROKEN FIRMWARE: Complain to your hardware vendor"); > > Pasting the same comment from last time since you missed it: > > "No, I don't want any of that crap issuing stuff in dmesg and then people > opening bugs and running around and trying to replace hardware. We want to see warnings. Maybe they can be toned done. We even have dedicated distros for firmware testing. > Good mailing practices for 400: avoid top-posting and trim the reply. Good mailing practices -- limit use of four letter words on public lists. Pavel
On 05/02/2018 02:10 PM, Pavel Machek wrote: > On Thu 2018-04-26 13:20:57, Borislav Petkov wrote: >> On Wed, Apr 25, 2018 at 03:39:51PM -0500, Alexandru Gagniuc wrote: >>> There seems to be a culture amongst BIOS teams to want to crash the >>> OS when an error can't be handled in firmware. Marking GHES errors as >>> "fatal" is a very common way to do this. >>> >>> However, a number of errors reported by GHES may be fatal in the sense >>> a device or link is lost, but are not fatal to the system. When there >>> is a disagreement with firmware about the handleability of an error, >>> print a warning message. > > >>> + >>> + if ((sev >= GHES_SEV_PANIC) && (ghes_actual_severity(ghes) < sev)) { >>> + pr_warn("FIRMWARE BUG: Firmware sent fatal error that we were able to correct"); >>> + pr_warn("BROKEN FIRMWARE: Complain to your hardware vendor"); >> >> Pasting the same comment from last time since you missed it: >> >> "No, I don't want any of that crap issuing stuff in dmesg and then people >> opening bugs and running around and trying to replace hardware. > > We want to see warnings. Maybe they can be toned done. We even have > dedicated distros for firmware testing. I'm told that had we had this warning when the r740 BIOS was in development, we would have solved a lot of the issues that I'm currently working on. That would, in turn, have exposed bigger issues, and we would have had a platform to fix and test those bigger issues. Hardware vendors who test on linux might be scratching their heads at this error, though they tend to figure out what they're doing wrong, and fix it. One argument against was "expensive support calls", on which I call BS. The firmware resources are expensive, but those are there whether or not the customers call to complain. Alex >> Good mailing practices for 400: avoid top-posting and trim the reply. > > Good mailing practices -- limit use of four letter words on public lists. Then can't show word 'four'. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 8ccb9cc10fc8..34d0da692dd0 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -539,6 +539,12 @@ static void ghes_do_proc(struct ghes *ghes, sec_sev, err, gdata->error_data_length); } + + } + + if ((sev >= GHES_SEV_PANIC) && (ghes_actual_severity(ghes) < sev)) { + pr_warn("FIRMWARE BUG: Firmware sent fatal error that we were able to correct"); + pr_warn("BROKEN FIRMWARE: Complain to your hardware vendor"); } }
There seems to be a culture amongst BIOS teams to want to crash the OS when an error can't be handled in firmware. Marking GHES errors as "fatal" is a very common way to do this. However, a number of errors reported by GHES may be fatal in the sense a device or link is lost, but are not fatal to the system. When there is a disagreement with firmware about the handleability of an error, print a warning message. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> --- drivers/acpi/apei/ghes.c | 6 ++++++ 1 file changed, 6 insertions(+)