Author: Joe Barr
According to the project home page, dmidecode’s purpose is to report “information about your system’s hardware as described in your system BIOS according to the SMBIOS/DMI standard… This information typically includes system manufacturer, model name, serial number, BIOS version, asset tag as well as a lot of other details of varying level of interest and reliability depending on the manufacturer. This will often include usage status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory module slots, and the list of I/O ports (e.g. serial, parallel, USB).”
Alan Cox has since moved on to other things, and dmidecode has been rewritten and is now maintained by Jean Delvare. The code is used in a number of other programs, including most interestingly the Linux kernel.
In a perfect world, all manufacturers would write accurate and complete DMI table entries in the BIOS. Then people could do things like inventory all the PCs in the enterprise down to a tag number in the blink of an eye. Alas, we aren’t anywhere near that in reality.
The amount and accuracy of information provided varies from manufacturer to manufacturer, and from model to model. Here’s what dmidecode reports on the first few items in DMI on my homebuilt system:
# dmidecode 2.5 SMBIOS 2.2 present. 42 structures occupying 1115 bytes. Table at 0x000F0000. Handle 0x0000 DMI type 0, 19 bytes. BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 07/25/2003 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 512 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/360 KB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 KB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported LS-120 boot is supported ATAPI Zip drive boot is supported Handle 0x0001 DMI type 1, 25 bytes. System Information Manufacturer: VIA Technologies, Inc. Product Name: KT400A-8235 Version: Serial Number: UUID: Not Settable Wake-up Type: Power Switch Handle 0x0002 DMI type 2, 8 bytes. Base Board Information Manufacturer: http://www.abit.com.tw/ Product Name: KD7A(VIA KT400A-8235) Version: 1.x Serial Number: Handle 0x0003 DMI type 3, 13 bytes. Chassis Information Manufacturer: Type: Desktop Lock: Not Present Version: Serial Number: Asset Tag: Boot-up State: Unknown Power Supply State: Unknown Thermal State: Unknown Security Status: Unknown Handle 0x0004 DMI type 4, 32 bytes. Processor Information Socket Designation: Socket 7 Type: Central Processor Family: Duron Manufacturer: AMD ID: 81 06 00 00 FF FB 83 03 Signature: Family 6, Model 8, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) Version: AMD Athlon(tm) XP Voltage: 1.6 V External Clock: 135 MHz Max Speed: 2250 MHz Current Speed: 1667 MHz Status: Populated, Enabled Upgrade: ZIF Socket L1 Cache Handle: 0x000A L2 Cache Handle: 0x000B L3 Cache Handle: No L3 Cache
More on page 2…
There’s much more to the report, but that gives you a good taste for how it works and what it shows. And here what Dmidecode found in the BIOS on my IBM ThinkPad:
# dmidecode 2.5 SMBIOS 2.33 present. 61 structures occupying 2127 bytes. Table at 0x000E0010. Handle 0x0000 DMI type 0, 20 bytes. BIOS Information Vendor: IBM Version: 1RETC2WW (3.03 ) Release Date: 04/07/2004 Address: 0xDC000 Runtime Size: 144 kB ROM Size: 1024 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 3.5"/720 KB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Handle 0x0001 DMI type 1, 25 bytes. System Information Manufacturer: IBM Product Name: 2378D2U Version: ThinkPad T40 Serial Number: 99B1481 UUID: 56BCCE81-4685-11CB-B2F9-E60FDC63E229 Wake-up Type: Power Switch Handle 0x0002 DMI type 2, 8 bytes. Base Board Information Manufacturer: IBM Product Name: 2378D2U Version: Not Available Serial Number: J1URU44G11V Handle 0x0003 DMI type 3, 17 bytes. Chassis Information Manufacturer: IBM Type: Notebook Lock: Not Present Version: Not Available Serial Number: Not Available Asset Tag: No Asset Information Boot-up State: Unknown Power Supply State: Unknown Thermal State: Unknown Security Status: Unknown OEM Information: 0x00000000 Handle 0x0004 DMI type 126, 17 bytes. Inactive Handle 0x0005 DMI type 126, 17 bytes. Inactive Handle 0x0006 DMI type 4, 35 bytes. Processor Information Socket Designation: None Type: Central Processor Family: Pentium M Manufacturer: GenuineIntel ID: 95 06 00 00 BF F9 E9 A7 Signature: Type 0, Family 6, Model 9, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) TM (Thermal monitor supported) SBF (Signal break on FERR) Version: Intel(R) Pentium(R) M processor Voltage: 1.4 V External Clock: 400 MHz Max Speed: 1300 MHz Current Speed: 1300 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x000A L2 Cache Handle: 0x000B L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified
As you can see, there is more information available from the IBM ThinkPad than from my homemade system, but neither one provides all the information that it could.
Who cares if the BIOS lies?
Five years ago I wrote about an anonymous friend of mine who struggled mightily to get Red Hat Linux 6.0 installed on an old CompuAdd computer. I called him Ramon Fernandez, taking the name of a character from Wallace Stevens’s poem “The Idea of Order at Key West.”
The installation problem was difficult to find, and even Red Hat’s best efforts didn’t find the cure. Red Hat 5.2 had installed on the same computer, but 6.0 was a no-go almost from the get-go. The problem was a lying BIOS. Ramon found it himself, having had a hand in creating the BIOS years ago. OS/2 knew the BIOS was lying, and worked around it. DOS didn’t know it was lying, it just didn’t care. Red Hat 5.2 hadn’t cared either. But the Red Hat 6.0 install cared, very much. Once Ramon removed the false claims about APM from the BIOS, Red Hat 6.0 installed without so much as a whimper.
Ramon sent me an email saying, “Taking APM out of the BIOS did the trick. So maybe the only systems in the world that could experience this problem are the CompuAdd EISA/VESA motherboard systems.” Probably so, but there are plenty of examples of other equally quirky hardware/BIOS combinations out there.
With memories of Ramon’s travails once more ricocheting around in my brain, I couldn’t help but wonder about a couple of things. First, why, if the DMI information is often unreliable, does the Linux kernel use it instead of sniffing the hardware? Second, given the same possibility of tainted data, why has so much effort gone into retrieving it and making it easily available? In both cases, why not just sniff the hardware instead?
For an answer to the first question, I turned to Linus Torvalds. He replied:
It doesn’t really.
The only thing the kernel really uses DMI for tends to be to black-list
certain motherboards.Oh, and there’s a few odd drivers that are very specific to certain
machines (the Sony-specific magic button driver) that use DMI to figure
out whether they are on a specific machine. I.e. they just trigger on the
fact that “Oh, this is a Sony VAIO,” simply because the hardware can’t be
sanely probed for.See arch/i386/kernel/dmi_scan.c for most of the blacklisting. It’s
things like knowing that certain laptops have strange problems with
keyboards, and that a number of ACPI implementations are crap, so it just
blacklists them.
With that straightened out, I asked basically the same question of dmidecode project leader Jean Delvare. He gave me not one, but three reasons, saying:
There are several reasons why dmidecode (and DMI data in general) is
still precious, even with the aforementioned possible lack of
reliability.First, some data present in the DMI table are unique, you will not find
them anywhere else, or at least not in a standard way. This includes
serial numbers, asset numbers, BIOS revision. These are not things you
can physically detect, so fetching the info from the DMI table is the
way to go. This is used by the Linux kernel to uniquely identify
motherboards. In fact this is the most important use of DMI I am aware
of.Second, probing the hardware is sometimes dangerous. Trusting the DMI
data instead may not be as reliable but at least is believed to be safe.
You can even, at least in the theory, grab the DMI data from one
machine’s BIOS and decode it on another one. The advantage is
admittedly mostly theoretical, since 1) locks on hardware probing are
rare and 2) grabbing the DMI data of a different machine has no
practical use I can think of (except for debugging dmidecode, but this is
a meta-use, so to say).Third, the DMI table gathers information from various different
subsystems, and you don’t have to know anything about these, and don’t
even have to care about the architecture you are on to get info about
them. Again it is a matter of reliability versus ease of gathering, but
sometimes you prefer a rough idea in a pinch to a refined idea requiring
much more work. Getting all the details you need from CPU, memory, PCI,
and more doesn’t sound easy.
When you download the tarball for the latest version of dmidecode, you also get three other programs: biosdecode, ownership, and vpddecode. The first of these might be useful regardless of what type of computer it’s run on. Ownership is useful primarily on Compaq (now HP) machines, and vpddecode primarily on IBM equipment.
Conclusion
The dmidecode project is interesting on many levels. For one thing, it’s almost invisible code in that is often used by other projects instead of by itself. For another, it touches on the sometimes contentious communication between free and proprietary. IBM, for example, which has been one of Linux’s most important backers in the industry, has not been as forthcoming as it might be with system data.
Both points are well illustrated in the linkage between lm_sensors — another project with a need to know about system hardware — and dmidecode. Jean Delvare, by the way, is involved in both projects. As Delvare told me in email, “The dmidecode tool has its history tied straight to another one, lm_sensors. The reason for that is that the lm_sensors project could possibly harm IBM ThinkPad laptops, and dmidecode could be used to detect these.”
You can still find reports and warnings about mixing lm_sensors IBM ThinkPads. Delvare went on to say:
To finish with the lm_sensors connection, I may add that the dmidecode 1.x source was duplicated in the project from version 2.6.5 to version 2.8.1. After that, we switch to an IBM-specific detection method, based on what vpddecode implements. vpddecode was developed as a C prototype of the decoding algorithm, and I reimplemented it in Perl for the lm_sensors project. vpddecode was made possible thanks to IBM releasing a Web page about the VPD structure. The cooperation we got from IBM mostly ends here, as they never released or otherwise provided the technical data we needed to properly blacklist only the IBM ThinkPad laptops with the fatal defect.
The blacklisting Delvare mentions leads us to dmi_scan.c, which Torvalds mentioned earlier. It’s yet another twist and link in this story. But it’s one that deserves an article of its own. Stay tuned.
