New upstream version 3.3upstream/3.3

1 files changed, 33 insertions, 10 deletions

diff --git a/man/dmidecode.8 b/man/dmidecode.8
index df861e1..64dc7e7 100644
--- a/man/dmidecode.8
+++ b/man/dmidecode.8
@@ -1,10 +1,12 @@
-.TH DMIDECODE 8 "March 2012" "dmidecode"
+.TH DMIDECODE 8 "January 2019" "dmidecode"
+.\"
 .SH NAME
 dmidecode \- \s-1DMI\s0 table decoder
+.\"
 .SH SYNOPSIS
 .B dmidecode
 .RB [ OPTIONS ]
-
+.\"
 .SH DESCRIPTION
 .B dmidecode
 is a tool for dumping a computer's \s-1DMI\s0 (some say \s-1SMBIOS\s0) table
@@ -58,7 +60,7 @@ displayed value.
 Decoded values. The information presented of course depends on the type
 of record. Here, we learn about the board's manufacturer, model, version
 and serial number.
-
+.\"
 .SH OPTIONS
 .TP
 .BR "-d" ", " "--dev-mem FILE"
@@ -72,9 +74,10 @@ displayed. Meta-data and handle references are hidden.
 Only display the value of the \s-1DMI\s0 string identified by \fBKEYWORD\fR.
 \fBKEYWORD\fR must be a keyword from the following list: \fBbios-vendor\fR,
 \fBbios-version\fR, \fBbios-release-date\fR,
+\fBbios-revision\fR, \fBfirmware-revision\fR,
 \fBsystem-manufacturer\fR, \fBsystem-product-name\fR,
 \fBsystem-version\fR, \fBsystem-serial-number\fR,
-\fBsystem-uuid\fR, \fBsystem-family\fR,
+\fBsystem-uuid\fR, \fBsystem-sku-number\fR, \fBsystem-family\fR,
 \fBbaseboard-manufacturer\fR, \fBbaseboard-product-name\fR,
 \fBbaseboard-version\fR, \fBbaseboard-serial-number\fR,
 \fBbaseboard-asset-tag\fR, \fBchassis-manufacturer\fR,
@@ -158,10 +161,9 @@ is run on a system with BIOS that boasts new SMBIOS specification, which
 is not supported by the tool yet, it will print out relevant message in
 addition to requested data on the very top of the output. Thus informs the
 output data is not reliable.
-
+.\"
 .SH "DMI TYPES"
 The \s-1SMBIOS\s0 specification defines the following \s-1DMI\s0 types:
-
 .TS
 r l
 __
@@ -246,7 +248,7 @@ dmidecode --type 0,13
 dmidecode --type bios
 .IP \(bu
 dmidecode --type BIOS
-
+.\"
 .SH BINARY DUMP FILE FORMAT
 The binary dump files generated by --dump-bin and read using --from-dump
 are formatted as follows:
@@ -255,16 +257,37 @@ The SMBIOS or DMI entry point is located at offset 0x00.
 It is crafted to hard-code the table address at offset 0x20.
 .IP \(bu "\w'\(bu'u+1n"
 The DMI table is located at offset 0x20.
-
+.\"
+.SH UUID FORMAT
+There is some ambiguity about how to interpret the UUID fields prior to SMBIOS
+specification version 2.6. There was no mention of byte swapping, and RFC 4122
+says that no byte swapping should be applied by default. However, SMBIOS
+specification version 2.6 (and later) explicitly states that the first 3 fields
+of the UUID should be read as little-endian numbers (byte-swapped).
+Furthermore, it implies that the same was already true for older versions of
+the specification, even though it was not mentioned. In practice, many hardware
+vendors were not byte-swapping the UUID. So, in order to preserve
+compatibility, it was decided to interpret the UUID fields according to RFC
+4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to
+interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS
+version is 2.6 or later. The Linux kernel follows the same logic.
+.\"
 .SH FILES
 .I /dev/mem
-.I /sys/firmware/dmi/tables/smbios_entry_point (Linux only)
-.I /sys/firmware/dmi/tables/DMI (Linux only)
+.br
+.I /sys/firmware/dmi/tables/smbios_entry_point
+(Linux only)
+.br
+.I /sys/firmware/dmi/tables/DMI
+(Linux only)
+.\"
 .SH BUGS
 More often than not, information contained in the \s-1DMI\s0 tables is inaccurate,
 incomplete or simply wrong.
+.\"
 .SH AUTHORS
 Alan Cox, Jean Delvare
+.\"
 .SH "SEE ALSO"
 .BR biosdecode (8),
 .BR mem (4),