Re: [PATCH 01/34] System Firmware Interface

From: Prarit Bhargava
Date: Tue Jul 19 2011 - 09:53:10 EST

On 07/19/2011 09:25 AM, Andi Kleen wrote:
> Playing the devils advocate here, but this is really unclear...

Sorry, I'll try to be more specific.

>> There is some additional information I'd like to throw out here as
>> well. SMBIOS also provides information on the system state after the
>> BIOS/EFI is finished and before the kernel has been booted. This has
>> been *invaluable* to me when diagnosing some wonky hardware from OEMs.
> Hmm this is for SMBIOS tables that changes at runtime?
> Why exactly is the kernel booting a good point to dump that?

Let me back up :) as I clearly didn't do a good job of explaining this.

I have systems/have had systems in which NO kernel would boot because of
faulty hardware. That hardware was identified as bad during the BIOS
POST but no information on it could be determined because we didn't make
it very far through boot :/. As you know Andi, booting with bad memory
or a bad cpu is excruciatingly difficult to diagnose.

The SMBIOS does provide access to a system log in which details on
failed hardware (again, failed hardware having been identified by the
BIOS) and that information was immensely useful to me during the system
boot. (see the Type 15 System Event Log Structure).

Plugging that into the existing "dmi" code was a headache. The code is
just not laid out to make expansion of dmi devices easy.

>> I want to expand the SMBIOS layer to dump that information out when I
> What information exactly?
> And dumping = print to system log?

Yes, to the system log.

>> tl;dr: There are some other useful bits of SMBIOS we could take
>> advantage of but the current "dmi" layer is difficult to work with.
> Like what?

Like the above example ;) ... but there are other things like the type
of memory in the system from a HW debug point of view become important.
My #1 goal is to get the SMBIOS version # exported via sysfs and to get
the type 15 stuff output as debug info.


> -Andi
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at