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

[Jean Delvare]

Hi Kevin,

On Thu, 7 Sep 2017 11:34:20 +0300, Kevin Wilson wrote:
> 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.

> 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 :-)

-- 
Jean Delvare
SUSE L3 Support