This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

dmidecode: What's it good for?

By Joe Barr on November 29, 2004 (8:00:00 AM)

Share    Print    Comments   

You know you're living in a cutthroat world when your BIOS lies to your operating system at boot time. Yet that's exactly what often happens, to one degree or another, depending on the manufacturer and model of the system. Some of the BIOS lies cause problems for Linux and some don't. The dmidecode project provides the means to learn exactly what claims your BIOS is making about your hardware. Strange as it might seem, it's useful information, even when it's not 100% reliable.

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.

 

Share    Print    Comments   

Comments

on dmidecode: What's it good for?

Note: Comments are owned by the poster. We are not responsible for their content.

another great and more complete tool

Posted by: Anonymous Coward on November 30, 2004 06:22 PM
LSHW (list hardware) uses DMI and many other tricks to report with quite good accuracy what hardware is inside your machine. It supports PCs, Macs, Alphas and many other platforms (DMI is limited to PCs).
You can find it at <A HREF="http://ezix.org/software/lshw.html" title="ezix.org">http://ezix.org/software/lshw.html</a ezix.org>

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya