efirt: add a tunable to disable printing faults during EFIRT calls

[kib]

Summary

PR: 285797

[jrtc27]

Only amd64 and arm64 implement and build efirt, are the arm and riscv changes truly needed?

[kib]

In D49592#1130720, @jrtc27 wrote:

Only amd64 and arm64 implement and build efirt, are the arm and riscv changes truly needed?

I thought that they do have efirt, or at least are close to have it. I am happy to drop the arches from the patch.

[kib]

Drop arm and riscv.

[bakul_iitbombay.org]

LGTM!

[markj]

This seems fine, but every user who sees repeated faults will have to enable the sysctl to prevent the dmesg from filling up.

An alternate policy would be to print the trap info once, then suppress printing for future traps, with a sysctl to disable the suppression. I think this would give nicer out-of-the-box behaviour.

[kib]

More fine-grained control of the efirt faults prints, and the count of total occurrences.

[markj]

sys/dev/efidev/efirt.c

134

139

[bakul_iitbombay.org]

I can live with this but note that if the "fault" occurs in normal operation for some machines, even a single message would be confusing, particularly if you are running into another bug! I spend a bunch of time tracking this down as I was also seeing some other errors which turned out to be an unrelated hardware issue.

[markj]

In D49592#1131695, @bakul_iitbombay.org wrote:

I can live with this but note that if the "fault" occurs in normal operation for some machines, even a single message would be confusing, particularly if you are running into another bug! I spend a bunch of time tracking this down as I was also seeing some other errors which turned out to be an unrelated hardware issue.

Perhaps the first print should also explain that this is perhaps "normal", and mention the sysctl that can be used to silence it.

[kib]

In D49592#1131695, @bakul_iitbombay.org wrote:

I can live with this but note that if the "fault" occurs in normal operation for some machines, even a single message would be confusing, particularly if you are running into another bug! I spend a bunch of time tracking this down as I was also seeing some other errors which turned out to be an unrelated hardware issue.

The fault is definitely not normal, it is most likely an indicator of the bug in BIOS, but also might be in our interface to BIOS.