NBFT parser SSNS flags #2215
NBFT parser SSNS flags #2215
Conversation
|
Note that connection failures are still being reported by the kernel, resulting in some confusing clutter on the console:
|
tbzatek
force-pushed
the
nbft-flags-1
branch
2 times, most recently
from
e896130 to
056cd4b
Compare
tbzatek
force-pushed
the
nbft-flags-1
branch
3 times, most recently
from
75b8410 to
432758b
Compare
|
Ready for review. The second commit is slightly controversial since it creates a dummy Cc: @mwilck |
nbft.c
Outdated
|
|
||
| /* | ||
| * In case this SSNS is marked as 'unavailable', | ||
| * make another connection attempt. |
There was a problem hiding this comment.
did you mean "do not make another connection attempt"?
There was a problem hiding this comment.
Well this is for discussion, for now all my changes mimic the existing behaviour, i.e. connecting to anything defined. With TP8029 in place we can decide in which circumstances a connection attempt should be or not be made.
Another question outlined in #2219 is about making two-phase connection attempts where unavailable records will only get attempted to be reconnected sometime after switchroot, e.g. via a systemd unit.
There was a problem hiding this comment.
if the SSNS record is unavailable that's because the primary boot phase set it that way. I think unavailable records should be retried by nvme-cli.
Yes, we want to make another connection attempt.
There was a problem hiding this comment.
@tbzatek, I am not suggesting changes to your code.
I was just referring to the comment: "make another connection attempt", but will execute a continue and will not make another attempt if the unavailable flag is set, unless I'm misreading the code.
There was a problem hiding this comment.
Ah, sorry 😮, right, the comment was slightly confusing, reworded.
|
just a rebase to include the libnvme changes. |
|
@tbzatek The compilers are not happy. It seems these versions are not able to track dependencies correctly. Maybe initialized the to a default value? |
New 'unavailable' and 'discovered' flags. JSON only for the moment. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Useful for debugging the libnvme NBFT parser. Specify '-vv' for debugging messages. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
nvme-cli logging offers multiple levels now. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
In case a SSNS is marked as 'unavailable' by the firmware, let's give it another try but silence any errors. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
For unavailable SSNSs, pause logging to make connection attempts truly silent. Kernel errors are still being logged, e.g. nvme nvme8: failed to connect socket: -110 Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
In case of complex NBFT tables, multiple messages printed out start to get confusing. Better to print SSNS indexes for easier identification in further debugging. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
|
Thanks! |
This adds support for the newly introduced
unavailableSSNS flag. Certain firmware (UEFI) implementations may include SSNS records in the ACPI NBFT table that failed to connect and optionally provide a detailed reason (TP-8029, not subject to this pull request).In userspace I thought it might be beneficial to do another connection attempt, with expectation of failure. Such failure should not be reported nor should fail the whole connection process (
nvme connect-all --nbft). Failure messages would still be reported in verbose mode.As currently designed, three connection attempts are made: the pre-OS/UEFI phase, dracut and another try via the
nvmf-connect-nbft.servicesystemd unit. Between these attempts networking may change, new routes added, tunnels established, etc.Needs linux-nvme/libnvme#781 and
linux-nvme/libnvme#782