[dmidecode] [PATCH] dmidecode: Add option to filter output based upon handle.

[Jerry Hoemann]

Add option "--handle HANDLE" to dmiopt to allow user to filter
ouput to only those entrie(s) that match HANDLE.

Signed-off-by: Jerry Hoemann <***@hpe.com>
---
dmidecode.c | 2 ++
dmiopt.c | 22 +++++++++++++++++++++-
dmiopt.h | 1 +
man/dmidecode.8 | 4 ++++
4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/dmidecode.c b/dmidecode.c
index f8c3b30..023ed58 100644
--- a/dmidecode.c
+++ b/dmidecode.c
@@ -4732,6 +4732,7 @@ static void dmi_table_decode(u8 *buf, u32 len, u16 num, u16 ver, u32 flags)

to_dmi_header(&h, data);
display = ((opt.type == NULL || opt.type[h.type])
+ && ((opt.handle == ~0U) || (opt.handle == h.handle))
&& !((opt.flags & FLAG_QUIET) && (h.type == 126 || h.type == 127))
&& !opt.string);

@@ -5144,6 +5145,7 @@ int main(int argc, char * const argv[])
/* Set default option values */
opt.devmem = DEFAULT_MEM_DEV;
opt.flags = 0;
+ opt.handle = ~0U;

if (parse_command_line(argc, argv)<0)
{
diff --git a/dmiopt.c b/dmiopt.c
index a36cf16..6c74c7f 100644
--- a/dmiopt.c
+++ b/dmiopt.c
@@ -240,6 +240,19 @@ static int parse_opt_oem_string(const char *arg)
return 0;
}

+static u32 parse_opt_handle(const char *arg)
+{
+ u32 val;
+ char *next;
+
+ val = strtoul(arg, &next, 0);
+ if ((next && *next != '\0') || val > 0xffff)
+ {
+ fprintf(stderr, "Invalid handle nubmer: %s\n", arg);
+ return ~0;
+ }
+ return val;
+}

/*
* Command line options handling
@@ -249,10 +262,11 @@ static int parse_opt_oem_string(const char *arg)
int parse_command_line(int argc, char * const argv[])
{
int option;
- const char *optstring = "d:hqs:t:uV";
+ const char *optstring = "d:hqs:t:uHV";
struct option longopts[] = {
{ "dev-mem", required_argument, NULL, 'd' },
{ "help", no_argument, NULL, 'h' },
+ { "handle", required_argument, NULL, 'H' },
{ "quiet", no_argument, NULL, 'q' },
{ "string", required_argument, NULL, 's' },
{ "type", required_argument, NULL, 't' },
@@ -295,6 +309,11 @@ int parse_command_line(int argc, char * const argv[])
return -1;
opt.flags |= FLAG_QUIET;
break;
+ case 'H':
+ opt.handle = parse_opt_handle(optarg);
+ if (opt.handle == ~0U)
+ return -1;
+ break;
case 't':
opt.type = parse_opt_type(opt.type, optarg);
if (opt.type == NULL)
@@ -351,6 +370,7 @@ void print_help(void)
" -q, --quiet Less verbose output\n"
" -s, --string KEYWORD Only display the value of the given DMI string\n"
" -t, --type TYPE Only display the entries of given type\n"
+ " -H, --handle HANDLE Only display the entries of given handle\n"
" -u, --dump Do not decode the entries\n"
" --dump-bin FILE Dump the DMI data to a binary file\n"
" --from-dump FILE Read the DMI data from a binary file\n"
diff --git a/dmiopt.h b/dmiopt.h
index c676308..34adf3a 100644
--- a/dmiopt.h
+++ b/dmiopt.h
@@ -35,6 +35,7 @@ struct opt
u8 *type;
const struct string_keyword *string;
char *dumpfile;
+ u32 handle;
};
extern struct opt opt;

diff --git a/man/dmidecode.8 b/man/dmidecode.8
index e3b6b2a..858e56e 100644
--- a/man/dmidecode.8
+++ b/man/dmidecode.8
@@ -101,6 +101,10 @@ typically from files under
.IR /sys/devices/virtual/dmi/id .
Most of these files are even readable by regular users.
.TP
+.BR "-H" ", " "--handle HANDLE"
+Only display the entries whose handle matches \fBHANDLE\fR. \fBHANDLE\fR
+is a 16 bit integer.
+.TP
.BR "-t" ", " "--type TYPE"
Only display the entries of type \fBTYPE\fR. \fBTYPE\fR can be either a
\s-1DMI\s0 type number, or a comma-separated list of type numbers, or a

[Jean Delvare]

Hi Jerry,

Post by Jerry Hoemann
Add option "--handle HANDLE" to dmiopt to allow user to filter
ouput to only those entrie(s) that match HANDLE.

I am curious what you need this feature for? Handle numbers are
arbitrary and not portable, so it never occurred to me that someone
could need to query for a specific handle.

Post by Jerry Hoemann
---
dmidecode.c | 2 ++
dmiopt.c | 22 +++++++++++++++++++++-
dmiopt.h | 1 +
man/dmidecode.8 | 4 ++++
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/dmidecode.c b/dmidecode.c
index f8c3b30..023ed58 100644
--- a/dmidecode.c
+++ b/dmidecode.c
@@ -4732,6 +4732,7 @@ static void dmi_table_decode(u8 *buf, u32 len, u16 num, u16 ver, u32 flags)
to_dmi_header(&h, data);
display = ((opt.type == NULL || opt.type[h.type])
+ && ((opt.handle == ~0U) || (opt.handle == h.handle))

This is more parentheses than needed.

Post by Jerry Hoemann
&& !((opt.flags & FLAG_QUIET) && (h.type == 126 || h.type == 127))
&& !opt.string);
@@ -5144,6 +5145,7 @@ int main(int argc, char * const argv[])
/* Set default option values */
opt.devmem = DEFAULT_MEM_DEV;
opt.flags = 0;
+ opt.handle = ~0U;
if (parse_command_line(argc, argv)<0)
{
diff --git a/dmiopt.c b/dmiopt.c
index a36cf16..6c74c7f 100644
--- a/dmiopt.c
+++ b/dmiopt.c
@@ -240,6 +240,19 @@ static int parse_opt_oem_string(const char *arg)
return 0;
}
+static u32 parse_opt_handle(const char *arg)
+{
+ u32 val;
+ char *next;
+
+ val = strtoul(arg, &next, 0);
+ if ((next && *next != '\0') || val > 0xffff)

"next" can't be NULL, so the first test will always succeed.

Also, checking for "*next != '\0'" alone doesn't guarantee that the
input is valid: if arg is an empty string, it is not valid, but *next
will be '\0'. As a result,

# dmidecode --handle ""

will happily display the DMI entry with handle 0x0000. This is not
consistent with the behavior of --oem-string:

# dmidecode --oem-string ""
Invalid OEM string number:

So for consistency with the other options, I would prefer if you check
for "next == arg" to detect an error in the input. (This also is
admittedly not perfect, but if anyone is unhappy with that, it should
be fixed for all options at once, for consistency.)

Post by Jerry Hoemann
+ {
+ fprintf(stderr, "Invalid handle nubmer: %s\n", arg);

Typo: number.

Post by Jerry Hoemann
+ return ~0;
+ }
+ return val;
+}
/*
* Command line options handling
@@ -249,10 +262,11 @@ static int parse_opt_oem_string(const char *arg)
int parse_command_line(int argc, char * const argv[])
{
int option;
- const char *optstring = "d:hqs:t:uV";
+ const char *optstring = "d:hqs:t:uHV";

You are missing a colon after "H" here. This causes getopt to not feed
optarg when "-H" is passed, ultimately leading to a segmentation fault
in parse_opt_handle.

Post by Jerry Hoemann
struct option longopts[] = {
{ "dev-mem", required_argument, NULL, 'd' },
{ "help", no_argument, NULL, 'h' },
+ { "handle", required_argument, NULL, 'H' },
{ "quiet", no_argument, NULL, 'q' },
{ "string", required_argument, NULL, 's' },
{ "type", required_argument, NULL, 't' },

Please use the same order in short options list and long options list.
The former fits better in the current scheme.

Post by Jerry Hoemann
@@ -295,6 +309,11 @@ int parse_command_line(int argc, char * const argv[])
return -1;
opt.flags |= FLAG_QUIET;
break;
+ opt.handle = parse_opt_handle(optarg);
+ if (opt.handle == ~0U)
+ return -1;
+ break;
opt.type = parse_opt_type(opt.type, optarg);
if (opt.type == NULL)

Later in this function, there is a check for mutually exclusive
options. I believe it should be extended to check this new option.

Note that the combination of --handle with -s could make sense in
theory, if for example you want to get a processor-specific string on a
multi-processor system, but it is not currently handled due to the
logic in dmi_table_decode(). So for now they should be checked and
advertised as mutually exclusive as well.

Post by Jerry Hoemann
@@ -351,6 +370,7 @@ void print_help(void)
" -q, --quiet Less verbose output\n"
" -s, --string KEYWORD Only display the value of the given DMI string\n"
" -t, --type TYPE Only display the entries of given type\n"
+ " -H, --handle HANDLE Only display the entries of given handle\n"

"entry" (see below).

Post by Jerry Hoemann
" -u, --dump Do not decode the entries\n"
" --dump-bin FILE Dump the DMI data to a binary file\n"
" --from-dump FILE Read the DMI data from a binary file\n"
diff --git a/dmiopt.h b/dmiopt.h
index c676308..34adf3a 100644
--- a/dmiopt.h
+++ b/dmiopt.h
@@ -35,6 +35,7 @@ struct opt
u8 *type;
const struct string_keyword *string;
char *dumpfile;
+ u32 handle;

Extra space before "handle".

Post by Jerry Hoemann
};
extern struct opt opt;
diff --git a/man/dmidecode.8 b/man/dmidecode.8
index e3b6b2a..858e56e 100644
--- a/man/dmidecode.8
+++ b/man/dmidecode.8
@@ -101,6 +101,10 @@ typically from files under
.IR /sys/devices/virtual/dmi/id .
Most of these files are even readable by regular users.
.TP
+.BR "-H" ", " "--handle HANDLE"
+Only display the entries whose handle matches \fBHANDLE\fR. \fBHANDLE\fR
+is a 16 bit integer.

The use of plural ("entries") is confusing because each handle number
must be unique according to the SMBIOS specification.

"16-bit" used as an adjective takes an hyphen, as far as I know.

Post by Jerry Hoemann
+.TP
.BR "-t" ", " "--type TYPE"
Only display the entries of type \fBTYPE\fR. \fBTYPE\fR can be either a
\s-1DMI\s0 type number, or a comma-separated list of type numbers, or a

I would appreciate if options -H, -t and -s would show up in the same
order everywhere. A the moment, you have s(O)Ht in parse_command_line(),
stH in --help and sHt in the manual page. Especially the last two
should be the same because they are user-visible.

Thanks,

[Elliott, Robert (Persistent Memory)]

-----Original Message-----
Sent: Friday, June 29, 2018 4:09 AM
Subject: Re: [PATCH] dmidecode: Add option to filter output based
upon handle
Hi Jerry,

Post by Jerry Hoemann
Add option "--handle HANDLE" to dmiopt to allow user to filter
ouput to only those entrie(s) that match HANDLE.

I am curious what you need this feature for? Handle numbers are
arbitrary and not portable, so it never occurred to me that someone
could need to query for a specific handle.

The ACPI NFIT (NVDIMM Firmware Interface Table) reports the SMBIOS
handle of each NVDIMM (in a field called Physical ID). So, this
helps follow that to find the rest of the information about the
NVDIMM that is being provided by system firmware.
See https://patchwork.kernel.org/patch/9835987/.

Similarly, the ACPI PMTT (Platform Memory Topology Table) and HMAT
(Heterogeneous Memory Attribute Table) include SMBIOS handles for
the DIMMs whose attributes they are describing.

---
Robert Elliott, HPE Persistent Memory



_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

[Jean Delvare]

Post by Elliott, Robert (Persistent Memory)

-----Original Message-----
Sent: Friday, June 29, 2018 4:09 AM
Subject: Re: [PATCH] dmidecode: Add option to filter output based
upon handle
Hi Jerry,

Post by Jerry Hoemann
Add option "--handle HANDLE" to dmiopt to allow user to filter
ouput to only those entrie(s) that match HANDLE.

I am curious what you need this feature for? Handle numbers are
arbitrary and not portable, so it never occurred to me that someone
could need to query for a specific handle.

The ACPI NFIT (NVDIMM Firmware Interface Table) reports the SMBIOS
handle of each NVDIMM (in a field called Physical ID). So, this
helps follow that to find the rest of the information about the
NVDIMM that is being provided by system firmware.
See https://patchwork.kernel.org/patch/9835987/.
Similarly, the ACPI PMTT (Platform Memory Topology Table) and HMAT
(Heterogeneous Memory Attribute Table) include SMBIOS handles for
the DIMMs whose attributes they are describing.

Oh, OK. I expected the information to be consumed inside the kernel
rather than from user-space.

I'm fine with adding the option to dmidecode either way, it can
certainly be useful even if only for development / debugging.

[Jerry Hoemann]

Post by Jean Delvare
Hi Jerry,

Post by Jerry Hoemann
Add option "--handle HANDLE" to dmiopt to allow user to filter
ouput to only those entrie(s) that match HANDLE.

I am curious what you need this feature for? Handle numbers are
arbitrary and not portable, so it never occurred to me that someone
could need to query for a specific handle.

Covered in your exchange w/ Robert.

Post by Jean Delvare

Post by Jerry Hoemann
---
dmidecode.c | 2 ++
dmiopt.c | 22 +++++++++++++++++++++-
dmiopt.h | 1 +
man/dmidecode.8 | 4 ++++
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/dmidecode.c b/dmidecode.c
index f8c3b30..023ed58 100644
--- a/dmidecode.c
+++ b/dmidecode.c
@@ -4732,6 +4732,7 @@ static void dmi_table_decode(u8 *buf, u32 len, u16 num, u16 ver, u32 flags)
to_dmi_header(&h, data);
display = ((opt.type == NULL || opt.type[h.type])
+ && ((opt.handle == ~0U) || (opt.handle == h.handle))

This is more parentheses than needed.

changed.

Post by Jean Delvare

Post by Jerry Hoemann
&& !((opt.flags & FLAG_QUIET) && (h.type == 126 || h.type == 127))
&& !opt.string);
@@ -5144,6 +5145,7 @@ int main(int argc, char * const argv[])
/* Set default option values */
opt.devmem = DEFAULT_MEM_DEV;
opt.flags = 0;
+ opt.handle = ~0U;
if (parse_command_line(argc, argv)<0)
{
diff --git a/dmiopt.c b/dmiopt.c
index a36cf16..6c74c7f 100644
--- a/dmiopt.c
+++ b/dmiopt.c
@@ -240,6 +240,19 @@ static int parse_opt_oem_string(const char *arg)
return 0;
}
+static u32 parse_opt_handle(const char *arg)
+{
+ u32 val;
+ char *next;
+
+ val = strtoul(arg, &next, 0);
+ if ((next && *next != '\0') || val > 0xffff)

"next" can't be NULL, so the first test will always succeed.

Defensive programming.

Changed.

Post by Jean Delvare
Also, checking for "*next != '\0'" alone doesn't guarantee that the
input is valid: if arg is an empty string, it is not valid, but *next
will be '\0'. As a result,
# dmidecode --handle ""
will happily display the DMI entry with handle 0x0000. This is not

Okay, getopt_long handles totally missing argument, but not the degenerate case.

Fixed.

Post by Jean Delvare
# dmidecode --oem-string ""
So for consistency with the other options, I would prefer if you check
for "next == arg" to detect an error in the input. (This also is

Note, next != arg doesn't gurantee against badly formated argument.

e.g. --handle 1w4

This is badly formated, next != arg, and val == 1.

So test should be:

if (next == arg || *next != '\0' || val > 0xffff)

Post by Jean Delvare
admittedly not perfect, but if anyone is unhappy with that, it should
be fixed for all options at once, for consistency.)

I'll fix the other uses of strtoul in a separate patch.

Post by Jean Delvare

Post by Jerry Hoemann
+ {
+ fprintf(stderr, "Invalid handle nubmer: %s\n", arg);

Typo: number.

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
+ return ~0;
+ }
+ return val;
+}
/*
* Command line options handling
@@ -249,10 +262,11 @@ static int parse_opt_oem_string(const char *arg)
int parse_command_line(int argc, char * const argv[])
{
int option;
- const char *optstring = "d:hqs:t:uV";
+ const char *optstring = "d:hqs:t:uHV";

You are missing a colon after "H" here. This causes getopt to not feed
optarg when "-H" is passed, ultimately leading to a segmentation fault
in parse_opt_handle.

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
struct option longopts[] = {
{ "dev-mem", required_argument, NULL, 'd' },
{ "help", no_argument, NULL, 'h' },
+ { "handle", required_argument, NULL, 'H' },
{ "quiet", no_argument, NULL, 'q' },
{ "string", required_argument, NULL, 's' },
{ "type", required_argument, NULL, 't' },

Please use the same order in short options list and long options list.
The former fits better in the current scheme.

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
@@ -295,6 +309,11 @@ int parse_command_line(int argc, char * const argv[])
return -1;
opt.flags |= FLAG_QUIET;
break;
+ opt.handle = parse_opt_handle(optarg);
+ if (opt.handle == ~0U)
+ return -1;
+ break;
opt.type = parse_opt_type(opt.type, optarg);
if (opt.type == NULL)

Later in this function, there is a check for mutually exclusive
options. I believe it should be extended to check this new option.
Note that the combination of --handle with -s could make sense in
theory, if for example you want to get a processor-specific string on a
multi-processor system, but it is not currently handled due to the
logic in dmi_table_decode(). So for now they should be checked and
advertised as mutually exclusive as well.

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
@@ -351,6 +370,7 @@ void print_help(void)
" -q, --quiet Less verbose output\n"
" -s, --string KEYWORD Only display the value of the given DMI string\n"
" -t, --type TYPE Only display the entries of given type\n"
+ " -H, --handle HANDLE Only display the entries of given handle\n"

"entry" (see below).

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
" -u, --dump Do not decode the entries\n"
" --dump-bin FILE Dump the DMI data to a binary file\n"
" --from-dump FILE Read the DMI data from a binary file\n"
diff --git a/dmiopt.h b/dmiopt.h
index c676308..34adf3a 100644
--- a/dmiopt.h
+++ b/dmiopt.h
@@ -35,6 +35,7 @@ struct opt
u8 *type;
const struct string_keyword *string;
char *dumpfile;
+ u32 handle;

Extra space before "handle".

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
};
extern struct opt opt;
diff --git a/man/dmidecode.8 b/man/dmidecode.8
index e3b6b2a..858e56e 100644
--- a/man/dmidecode.8
+++ b/man/dmidecode.8
@@ -101,6 +101,10 @@ typically from files under
.IR /sys/devices/virtual/dmi/id .
Most of these files are even readable by regular users.
.TP
+.BR "-H" ", " "--handle HANDLE"
+Only display the entries whose handle matches \fBHANDLE\fR. \fBHANDLE\fR
+is a 16 bit integer.

The use of plural ("entries") is confusing because each handle number
must be unique according to the SMBIOS specification.

OK. Wasn't sure handles were unique. The code works either way.

I'll change to the singular form here and the other locations.

Post by Jean Delvare
"16-bit" used as an adjective takes an hyphen, as far as I know.

Fixed.

Post by Jean Delvare

Post by Jerry Hoemann
+.TP
.BR "-t" ", " "--type TYPE"
Only display the entries of type \fBTYPE\fR. \fBTYPE\fR can be either a
\s-1DMI\s0 type number, or a comma-separated list of type numbers, or a

I would appreciate if options -H, -t and -s would show up in the same
order everywhere. A the moment, you have s(O)Ht in parse_command_line(),
stH in --help and sHt in the manual page. Especially the last two
should be the same because they are user-visible.

Will make order: stH

Post by Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support

[Elliott, Robert (Persistent Memory)]

-----Original Message-----
From: Hoemann, Jerry
Sent: Friday, June 29, 2018 3:03 PM
Subject: Re: [PATCH] dmidecode: Add option to filter output based upon handle

...

Post by Jean Delvare

Post by Jerry Hoemann
diff --git a/man/dmidecode.8 b/man/dmidecode.8
index e3b6b2a..858e56e 100644
--- a/man/dmidecode.8
+++ b/man/dmidecode.8
@@ -101,6 +101,10 @@ typically from files under
.IR /sys/devices/virtual/dmi/id .
Most of these files are even readable by regular users.
.TP
+.BR "-H" ", " "--handle HANDLE"
+Only display the entries whose handle matches \fBHANDLE\fR. \fBHANDLE\fR
+is a 16 bit integer.

The use of plural ("entries") is confusing because each handle number
must be unique according to the SMBIOS specification.

OK. Wasn't sure handles were unique. The code works either way.
I'll change to the singular form here and the other locations.

That'll be true for well-behaved system firmware, and it is reasonable
for the help messages to be worded based on that understanding.

If system firmware messes that up, though (hopefully only in pre-production
code), it's helpful for dmidecode to print all of the matching structures.

---
Robert Elliott, HPE Persistent Memory



_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

[Jean Delvare]

Post by Elliott, Robert (Persistent Memory)

Post by Jerry Hoemann

Post by Jean Delvare
The use of plural ("entries") is confusing because each handle number
must be unique according to the SMBIOS specification.

OK. Wasn't sure handles were unique. The code works either way.
I'll change to the singular form here and the other locations.

That'll be true for well-behaved system firmware, and it is reasonable
for the help messages to be worded based on that understanding.
If system firmware messes that up, though (hopefully only in pre-production
code), it's helpful for dmidecode to print all of the matching structures.

Agreed.

Last year, as part of a SUSE Hackweek, I looked into extending
dmidecode to have an SMBIOS standard conformance checking mode [1].
This is still only a prototype and it did not cover the full list of
constraints, so I never published my work, but if there is an interest
in this, I could spend some time polishing the patch set and post it.
The code does not check for handle uniqueness yet, but that would be
easy to implement.

[1] https://hackweek.suse.com/17/projects/dmi-table-conformance-checker

[Elliott, Robert (Persistent Memory)]

-----Original Message-----
Sent: Saturday, June 30, 2018 3:00 AM
Subject: Re: [PATCH] dmidecode: Add option to filter output based upon handle

...

Last year, as part of a SUSE Hackweek, I looked into extending
dmidecode to have an SMBIOS standard conformance checking mode [1].
This is still only a prototype and it did not cover the full list of
constraints, so I never published my work, but if there is an interest
in this, I could spend some time polishing the patch set and post it.
The code does not check for handle uniqueness yet, but that would be
easy to implement.
[1] https://hackweek.suse.com/17/projects/dmi-table-conformance-checker
--
Jean Delvare
SUSE L3 Support

I would encourage our test teams to incorporate such a test if it existed.

The fwts project at git://kernel.ubuntu.com/hwe/fwts.git includes a few
SMBIOS tests, but they are not very extensive. It's mainly focused on
ACPI and UEFI.

dmicheck: DMI/SMBIOS table tests.
--------------------------------------------------------------------------------
Test 1 of 3: Find and test SMBIOS Table Entry Points.
This test tries to find and sanity check the SMBIOS data structures.
PASSED: Test 1, Found SMBIOS Table Entry Point at 0x788fb000
SMBIOS Entry Point Structure:
Anchor String : _SM_
Checksum : 0xe9
Entry Point Length : 0x1f
Major Version : 0x02
Minor Version : 0x08
Maximum Struct Size : 0x90
Entry Point Revision : 0x00
Formatted Area : 0x00 0x00 0x00 0x00 0x00
Intermediate Anchor : _DMI_
Intermediate Checksum : 0x2c
Structure Table Length : 0x2ddf
Structure Table Address: 0x788a0000
# of SMBIOS Structures : 0x0105
SBMIOS BCD Revision : 28

PASSED: Test 1, SMBIOS Table Entry Point Checksum is valid.
PASSED: Test 1, SMBIOS Table Entry Point Length is valid.
PASSED: Test 1, SMBIOS Table Entry Intermediate Anchor String _DMI_ is valid.
PASSED: Test 1, SMBIOS Table Entry Point Intermediate Checksum is valid.
PASSED: Test 1, SMBIOS Table Entry Structure Table Address and Length looks valid.

Test 2 of 3: Test DMI/SMBIOS tables for errors.
PASSED: Test 2, Entry @ 0x788a0000 'Cache Information (Type 7)'
PASSED: Test 2, Entry @ 0x788a001d 'Cache Information (Type 7)'
PASSED: Test 2, Entry @ 0x788a003a 'Cache Information (Type 7)'
PASSED: Test 2, Entry @ 0x788a0057 'Processor Information (Type 4)'
...[walks through all the records] ...

Test 3 of 3: Test DMI/SMBIOS3 tables for errors.
SKIPPED: Test 3, Cannot find SMBIOS30 table entry, skip the test.

(and an ARM-specific test)



_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel