Install a handler for firmware work request error messages.

[jhb]

Summary

Install a handler for firmware work request error messages.

If a driver sends an malformed or disallowed work request, the firmware
responds with a work request error. Previously the driver treated this is
as an unexpected message and panicked. Now it decodes the error message
to aid in debugging.

Test Plan

• Broke the VF driver to send TX_PKT to trigger an error message.

[np]

If this is going to be in t4_sge.c (vs. t4_hw.c) then it can follow FreeBSD style like the rest of the file. So no -ve errnos, return (foo) instead of return foo, etc.

Is it ok to try to carry on after a WRERR? I think we should panic the system at least for fatal errors, if not for all errors.

What about printf(9) vs. log(9) given that the CPL handlers are running in an ithread?

[jhb]

In D6950#145783, @np wrote:

If this is going to be in t4_sge.c (vs. t4_hw.c) then it can follow FreeBSD style like the rest of the file. So no -ve errnos, return (foo) instead of return foo, etc.

One of my questions actually was if this should go in t4_hw.c (that is, do you think the Linux driver would take this upstream as well?)

Is it ok to try to carry on after a WRERR? I think we should panic the system at least for fatal errors, if not for all errors.

In the case of the errors I saw with the VF driver the EQ just died (which did break trying to kldunload as quiescing hung forever), but the system was otherwise fine. Those were non-fatal though. We could panic for fatal ones I guess and maybe mark the EQ as "dead" for non-fatal errors.

What about printf(9) vs. log(9) given that the CPL handlers are running in an ithread?

printf is certainly fine in an ithread. Would you prefer log(9)?

[jhb]

• Rebase.
• Use log() instead of printf().