- About Us
# 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.
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.