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.
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.
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.
Joe Barr
NewsForge
The Online Newspaper for Linux and Open Source
http://www.newsforge.com/
Date 2004.11.29 3:00
Topic
http://www.newsforge.com/article.pl?sid=04/11/18/2012237
Return