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

[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


On Thu, Sep 7, 2017 at 10:51 AM, Jean Delvare <address@hidden> wrote:
> Hi Kevin,
>
> On Thu, 7 Sep 2017 08:54:49 +0300, Kevin Wilson wrote:
>> 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
>
> I naively thought all distribution kernels had CONFIG_IKCONFIG_PROC=y,
> but I was wrong.
>
>> But:
>> 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.
>
>> 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