[dmidecode] Fixing "DMI table is broken!" error

[Kevin Wilson]

Hi,
I hope someone can advise me about the following problem:

I have an x86_64 machine with Ubuntu 14.04.5 on it.
When I run:
dmidecode
I get the following error:

# dmidecode 2.12
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.

Invalid entry length (0). DMI table is broken! Stop


I guess this can be due to some faulty hw (like RAM), or maybe
something with BIOS.

Is there a way I can find which is the hw part/BIOS setting which
causes this error message
and fix it ?

Regards,
Kevin

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

[Erwan Velu]

Can you make a try with the latest version please ?

Post by Kevin Wilson
Hi,
I have an x86_64 machine with Ubuntu 14.04.5 on it.
dmidecode
# dmidecode 2.12
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.
Invalid entry length (0). DMI table is broken! Stop
I guess this can be due to some faulty hw (like RAM), or maybe
something with BIOS.
Is there a way I can find which is the hw part/BIOS setting which
causes this error message
and fix it ?
Regards,
Kevin
_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

_______________________________________________
http

[Kevin Wilson]

Hi, Erwan,
Thanks.
I ran this sequence now:
git clone https://git.savannah.nongnu.org/git/dmidecode.git
make
and
./dmidecode

And got the same:

# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.

Invalid entry length (0). DMI table is broken! Stop

Any ideas ?

Regards,
Kevin

Post by Erwan Velu
Can you make a try with the latest version please ?

Post by Kevin Wilson
Hi,
I have an x86_64 machine with Ubuntu 14.04.5 on it.
dmidecode
# dmidecode 2.12
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.
Invalid entry length (0). DMI table is broken! Stop
I guess this can be due to some faulty hw (like RAM), or maybe
something with BIOS.
Is there a way I can find which is the hw part/BIOS setting which
causes this error message
and fix it ?
Regards,
Kevin
_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-dev

[Kevin Wilson]

Hi,

I need to add, maybe this gives some hint:

I also have these results:

dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.5 present.
# Writing 3566 bytes to foo.dump.
# Writing 31 bytes to foo.dump.

$dmidecode --from-dump foo.dump
# dmidecode 2.12
Reading SMBIOS/DMI data from file foo.dump.
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.

Invalid entry length (0). DMI table is broken! Stop.

Kevin

Post by Kevin Wilson
Hi, Erwan,
Thanks.
git clone https://git.savannah.nongnu.org/git/dmidecode.git
make
and
./dmidecode
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.
Invalid entry length (0). DMI table is broken! Stop
Any ideas ?
Regards,
Kevin

Post by Erwan Velu
Can you make a try with the latest version please ?

Post by Kevin Wilson
Hi,
I have an x86_64 machine with Ubuntu 14.04.5 on it.
dmidecode
# dmidecode 2.12
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Table at 0xBF7D9000.
Invalid entry length (0). DMI table is broken! Stop
I guess this can be due to some faulty hw (like RAM), or maybe
something with BIOS.
Is there a way I can find which is the hw part/BIOS setting which
causes this error message
and fix it ?
Regards,
Kevin
_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-

[Jean Delvare]

Hi Kevin,

Post by Kevin Wilson
dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.5 present.
# Writing 3566 bytes to foo.dump.
# Writing 31 bytes to foo.dump.
$dmidecode --from-dump foo.dump
# dmidecode 2.12
Reading SMBIOS/DMI data from file foo.dump.
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Invalid entry length (0). DMI table is broken! Stop.

Can you send the file to me in private?

Also, what does:

$ zgrep STRICT_DEVMEM /proc/config.gz

return?

[Kevin Wilson]

Hi,
First:
zgrep STRICT_DEVMEM /proc/config.gz
gzip: /proc/config.gz: No such file or directory

And also:
ls -al /proc/config.gz
ls: cannot access /proc/config.gz: No such file or director

But:
cat /boot/config-4.4.0-31-generic | grep STRICT_DEVMEM
CONFIG_STRICT_DEVMEM=y


And the kernel I use is the one who came with Ubuntu, 14.04.5 LTS
, without any changes.

Regards,
Kevin

Post by Jean Delvare
Hi Kevin,

Post by Kevin Wilson
dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.5 present.
# Writing 3566 bytes to foo.dump.
# Writing 31 bytes to foo.dump.
$dmidecode --from-dump foo.dump
# dmidecode 2.12
Reading SMBIOS/DMI data from file foo.dump.
SMBIOS 2.5 present.
94 structures occupying 3566 bytes.
Invalid entry length (0). DMI table is broken! Stop.

Can you send the file to me in private?
$ zgrep STRICT_DEVMEM /proc/config.gz
return?
--
Jean Delvare
SUSE L3 Support

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

[Jean Delvare]

Hi Kevin,

Post by Jean Delvare
zgrep STRICT_DEVMEM /proc/config.gz
gzip: /proc/config.gz: No such file or directory
ls -al /proc/config.gz
ls: cannot access /proc/config.gz: No such file or director

I naively thought all distribution kernels had CONFIG_IKCONFIG_PROC=y,
but I was wrong.

Post by Jean Delvare
cat /boot/config-4.4.0-31-generic | grep STRICT_DEVMEM
CONFIG_STRICT_DEVMEM=y

You found it, but it turns out not to be the issue in the end anyway.

Post by Jean Delvare
And the kernel I use is the one who came with Ubuntu, 14.04.5 LTS
, without any changes.

From the dump you sent to me, it appears that the DMI table is present
and readable (so not a /dev/mem access problem as I originally
suspectes), but the very beginning of the table is corrupted. Hard to
tell for sure but I think the first 9 bytes have been overwritten by.
As there is no indexing on DMI tables, this prevents us from parsing
the whole table.

I remember seeing a similar case, already on a Fujitsu server. The
problem was a conflict with the ACPI Platform Error Interface (APEI)
mechanism, as APEI was configured to make use of the same memory area
where the DMI table was mapped.

Can you try booting with "erst_disable" added to the bootloader
command line to see is that makes the problem go away? (ERST is one
of the APEI components.)

[Kevin Wilson]

Hi, Jean,
Wow! This worked!! dmidecode shows all the tables now, no error
whatsoever. Thanks a lot for your quick reply and this solution!

BTW: Is there any potential issue about using this "erst_disable"
kernel parameter if I will want to continue working with it ?
Do you have any ideas?

I just want to add that another strange thing that I see on this server is that
/sys/devices/system/node
there is no node 0 but only node1. I had to disable 3 faulty DIMMS via BIOS,
but on a different machine on which I also disabled the same 3 faulty DIMMs
(just for test) and rebooted it did show "node0" and "node1" after reboot.
This has nothing to do with dmidecocde, still something else seems
faulty on that machine. Maybe the BIOS does not provide to the kernel
everything as it should.

Regards,
Kevin

Post by Jean Delvare
Hi Kevin,

Post by Jean Delvare
zgrep STRICT_DEVMEM /proc/config.gz
gzip: /proc/config.gz: No such file or directory
ls -al /proc/config.gz
ls: cannot access /proc/config.gz: No such file or director

I naively thought all distribution kernels had CONFIG_IKCONFIG_PROC=y,
but I was wrong.

Post by Jean Delvare
cat /boot/config-4.4.0-31-generic | grep STRICT_DEVMEM
CONFIG_STRICT_DEVMEM=y

You found it, but it turns out not to be the issue in the end anyway.

Post by Jean Delvare
And the kernel I use is the one who came with Ubuntu, 14.04.5 LTS
, without any changes.

From the dump you sent to me, it appears that the DMI table is present
and readable (so not a /dev/mem access problem as I originally
suspectes), but the very beginning of the table is corrupted. Hard to
tell for sure but I think the first 9 bytes have been overwritten by.
As there is no indexing on DMI tables, this prevents us from parsing
the whole table.
I remember seeing a similar case, already on a Fujitsu server. The
problem was a conflict with the ACPI Platform Error Interface (APEI)
mechanism, as APEI was configured to make use of the same memory area
where the DMI table was mapped.
Can you try booting with "erst_disable" added to the bootloader
command line to see is that makes the problem go away? (ERST is one
of the APEI components.)
--
Jean Delvare
SUSE L3 Support

_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel

[Jean Delvare]

Hi Kevin,

Post by Kevin Wilson
Wow! This worked!! dmidecode shows all the tables now, no error
whatsoever. Thanks a lot for your quick reply and this solution!

You're welcome.

Ideally you shouldn't have to do that manually. Either the BIOS of your
system is broken, or there's a bug in the kernel. Looking for a BIOS
update may help.

Post by Kevin Wilson
BTW: Is there any potential issue about using this "erst_disable"
kernel parameter if I will want to continue working with it ?
Do you have any ideas?

This isn't my area, so I had to do a fair bit of research to answer
this question.

My understanding is that ERST provides a relatively small amount of
persistent storage, which is preserved across reboots. This is one of
the possible backends of the pstore virtual filesystem, which can be
used to save important debugging information in case of a system crash.
As the storage is persistent, the saved information (typically the
kernel logs buffer) can be retrieved for analysis after the system has
restarted.

There are other possible backends serving the same purpose, for example
(U)EFI systems can use EFI variables to store the information.

I don't know if this has much use in practice, as in many cases the
same information can be written to the disk, and when it can't, anyone
who really cares about recovering the system and crash information
reliably would probably setup kdump.

So my guess is that you won't miss much if you keep ERST disabled. When
the system is running normally, it shouldn't make any difference. In
fact many systems out there don't even implement ERST, I think this is
essentially a feature of servers and high end workstation. My desktop
and laptop don't have it.

Then again, please keep in mind that my knowledge on the topic is
fairly limited, so take the above analysis with a grain of salt, and if
you are really worried, feel free to ask people who know more about the
topic (please include me in these discussions.) I can't believe people
would have been working on pstore for 7 years if it did not serve a
purpose in at least some cases, so maybe I'm overlooking something.

If anyone reading this knows more, please speak up :-)