libnvme(9)

πŸ“¦ version 3.2, in arch rolling

πŸ’– libnvme(9) β€” the API Manual, but make it make sense πŸ’–

okay bestie, so this is a page out of the libnvme API manual β€” yes, that libnvme β€” and today's main character is a struct. Pull up a chair, grab a strawberry πŸ“, and let's get into it, because this little guy is literally the receipt for every error your NVMe drive ever had.


✨ NAME ✨

struct nvme_error_log_page β€” the Error Information Log Entry (that's Log Identifier 01h for the people keeping score πŸŽ€)

so basically: one entry in the error log. one bad day, fully documented.


🌸 SYNOPSIS 🌸

struct nvme_error_log_page {
    __le64 error_count;
    __le16 sqid;
    __le16 cmdid;
    __le16 status_field;
    __le16 parm_error_location;
    __le64 lba;
    __le32 nsid;
    __u8 vs;
    __u8 trtype;
    __u8 csi;
    __u8 opcode;
    __le64 cs;
    __le16 trtype_spec_info;
    __u8 rsvd[21];
    __u8 log_page_version;
 };

look at her. sixteen fields of pure "what went wrong and where." no notes. πŸ’…


πŸ¦‹ Members πŸ¦‹

bestie these are the fields, and I'm gonna go through every single one because nothing gets skipped in this house πŸ‘‘

  • error_count β€” Error Count: it's a 64-bit incrementing error count, aka a unique identifier for this specific error. It starts at 1h, gets incremented for each unique error log entry, and it's retained across power off conditions (so yes, it survives the nap 😴). A value of 0h means invalid entry β€” that's what you'll see when there are lost entries, or when there are fewer errors than the maximum number of entries the controller supports. And if this field hits FFFFFFFFh, then it shall be set to 1h when incremented (i.e., it rolls over to 1h). Heads up though: prior to NVMe 1.4, processing of incrementing beyond FFFFFFFFh is unspecified β€” so, undefined vibes, proceed with caution πŸ’€.
  • sqid β€” Submission Queue ID: tells you the Submission Queue Identifier of the command that this error info is associated with. But if the error isn't specific to a particular command, then this field shall be set to FFFFh. not everything is about one command, sometimes it's just the universe, yk?
  • cmdid β€” Command ID: the Command Identifier of the command the error is associated with. Same deal as above β€” if the error isn't specific to a particular command, then this field shall be set to FFFFh.
  • status_field β€” okay so this one has bits, pay attention 🫢:
    • Bits 15-1: Status Field β€” indicates the Status Field for the command that completed. If the error isn't specific to a particular command, then this field reports the most applicable status value.
    • Bit 0: Phase Tag β€” may indicate the Phase Tag posted for the command.
  • parm_error_location β€” Parameter Error Location: indicates the byte and bit of the command parameter that the error is associated with, if applicable. If the parameter spans multiple bytes or bits, then the location indicates the first byte and bit of the parameter. Breakdown time:
    • Bits 10-8: Bit in command that contained the error. Valid values are 0 to 7.
    • Bits 7-0: Byte in command that contained the error. Valid values are 0 to 63.
  • lba β€” LBA: this field indicates the first LBA that experienced the error condition, if applicable. pointing at the exact spot like 🎯
  • nsid β€” Namespace: this field indicates the NSID of the namespace that the error is associated with, if applicable.
  • vs β€” Vendor Specific Information Available: if there's additional vendor specific error information available, this field provides the log page identifier associated with that page. A value of 0h indicates that no additional information is available. Valid values are in the range of 80h to FFh. so if it's not 0h, go look at that other page, there's lore πŸ‘€
  • trtype β€” Transport Type (TRTYPE): indicates the Transport Type of the transport associated with the error. The values in this field are the same as the TRTYPE values in the Discovery Log Page Entry. If the error isn't transport related, this field shall be cleared to 0h. If it is transport related, this field shall be set to the type of the transport β€” see enum nvme_trtype.
  • csi β€” Command Set Indicator: this field contains the command set indicator for the command that the error is associated with.
  • opcode β€” Opcode: this field contains the opcode for the command that the error is associated with. yeah. it's giving "which command did this."
  • cs β€” Command Specific Information: this field contains command specific information. If it's used, the command definition specifies the information returned. so the individual command gets to decide what lives here. main character energy for the command ngl πŸ‘‘
  • trtype_spec_info β€” Transport Type Specific Information. that's it, that's the description, she's mysterious like that ✨
  • rsvd β€” Reserved: [62:42]. do not perceive her. she is reserved. πŸ™ˆ
  • log_page_version β€” this field shall be set to 1h. If it's set, then csi and opcode will have valid values. so 1h = those two fields are actually saying something real, no cap.

⚠️ tiny PSA before you go: rsvd is reserved, so leave her alone, and remember that incrementing past FFFFFFFFh before NVMe 1.4 is unspecified β€” don't come crying to me if it does something unhinged 😭

so that's the whole page, every field, every bit, every FFFFh and 0h accounted for. go forth and decode your error logs like the icon you are πŸ§šπŸ’œ

β€” much love from the struct nvme_error_log_page page itself, dated October 2026, part of the libnvme(9) lineup. slay, stay hydrated, and check your status fields bestie πŸ’…πŸŒˆβ­

πŸ“¦ where this page comes from