[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #168 from Mark Millard <markmi at dsl-only.net> ---
(In reply to Don Lewis from comment #163)

Table 73 ("Memory Device (Type 17) structure") of:

http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf

(System Management BIOS (SMBIOS) Reference Specification)

reports:

Total width, in bits, of this memory device, including
any check or error-correction bits. If there are no
error-correction bits, this value should be equal to
Data Width. If the width is unknown, the field is set
to FFFFh.

Also:

Data width, in bits, of this memory device. A Data Width
of 0 and a Total Width of 8 indicates that the device is
being used solely to provide 8 error-correction bits. If
the width is unknown, the field is set to FFFFh.

(It is indicates as applying to specification versions:
2.1+ .)



So for the 128 in:

Memory Device
. . .
        Error Information Handle: 0x002D
        Total Width: 128 bits
        Data Width: 64 bits

Total Width != Data Width is supposed to imply
error correction bits but I doubt that many.

It seems odd and is probably not according to the
specification. So it is not clear that the ECC
status can be inferred. The factor of 2 between
64 and 128 is more likely from something like
dual-channel or some such with any error correction
bits ignored if present/in-use.

This tends to suggest that interpreting the dmidecode
output for such things can be a problem to rely on.

-- 
You are receiving this mail because:
You are the assignee for the bug.