On 2023/3/22 AM12:09, Luck, Tony wrote:
>> Actually, firmware will do some platform dependent sanity checks and returns
>> different error codes. In this case, user injects to a invalid device, platform
>> returns "Invalid Access". And user is expected to see:
>>
>> # select a invalid core or device to inject
>> # echo 1 > error_inject
>> echo: write error: Invalid argument
>>
>> Then user is expected to check his injection argument first.
>
> Thanks. This makes sense. You want EINVAL when the user chose
> bad arguments, and some other code for problem in BIOS.
Yes, exactly.
>
> If the BIOS has an issue, is it possible, or likely, that it is a temporary
> problem? If so, EBUSY may be OK. The message " Device or resource busy"
> might encourage the user to wait and try again.
>
> If it is not going to get better by itself, then one of:
>
> #define EIO 5 /* I/O error */
> #define ENXIO 6 /* No such device or address */
>
> might be a better choice.
Yes, BIOS may temporarily not complete error injection (ACPI_EINJ_EXECUTE_OPERATION)
on time, in which case, kernel return EIO.
for (;;) {
rc = apei_exec_run(&ctx, ACPI_EINJ_CHECK_BUSY_STATUS);
if (rc)
return rc;
val = apei_exec_ctx_get_output(&ctx);
if (!(val & EINJ_OP_BUSY))
break;
if (einj_timedout(&timeout))
return -EIO;
In summary, you are asking that:
- report -EINVAL for "Invalid Access" case
- keeps reporting -EBUSY for "Unknown Failure" case unchanged.
- and keeps EIO for temporarily time out unchanged.
right? (This patch is doing so)
>
> -Tony
Thanks.
Best Regards,
Shuai
