[PATCH] dmicheck: fix handling of type 16 capacities > 2 TiB
Elliott, Robert (Persistent Memory)
elliott at hpe.com
Wed Oct 3 21:34:06 UTC 2018
> -----Original Message-----
> From: Alex Hung [mailto:alex.hung at canonical.com]
> Sent: Wednesday, October 3, 2018 4:20 AM
> To: Elliott, Robert (Persistent Memory) <elliott at hpe.com>
> Cc: fwts-devel <fwts-devel at lists.ubuntu.com>
> Subject: Re: [PATCH] dmicheck: fix handling of type 16 capacities > 2 TiB
>
> On Wed, Oct 3, 2018 at 10:09 AM Elliott, Robert (Persistent Memory)
> <elliott at hpe.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Alex Hung <alex.hung at canonical.com>
> > > Sent: Tuesday, October 02, 2018 7:33 PM
> > > To: Elliott, Robert (Persistent Memory) <elliott at hpe.com>
> > > Cc: fwts-devel <fwts-devel at lists.ubuntu.com>
> > > Subject: Re: [PATCH] dmicheck: fix handling of type 16 capacities > 2
> > > TiB
> > >
> > > Hi Robert,
> > >
> > > Thanks for the patch, and this seems to be similar to
> > > http://patchwork.ozlabs.org/patch/974876/.
> > >
> > > Do you have comments on the other one, ex. yours is more complete?
> >
> > I think they're functionally the same; that patch is simpler.
> > An if clause might better facilitate ensuring the structure length
> > includes the Extended Maximum Capacity field in the 0x8000000 case,
> > and verifying this rule from the conformance list in annex A:
> > "Either Maximum Capacity or Extended Maximum Capacity must be set
> > to a known, non-zero value."
> >
>
> I personally think the spec is ambiguous about 0x8000000 in Maximum
> Capacity. It seems to indicate Extended Maximum Capacity should be
> used but also is a valid number for 2TB (Table 70 – Physical Memory
> Array (Type 16) structure).
SMBIOS 2.7.0 (2010) introduced the Extended Maximum Capacity field
and added this rule:
"0x80000000 or greater must be represented in the Extended Maximum
Capacity field."
A system compliant with an earlier version wasn't subject to that
rule, so might report a value greater than 0x80000000. However,
the largest memory capacity per CPU in an x86 server at that time
was 192 GiB, meaning 1.5 TiB for an 8P system; that still doesn't
push this field above 0x80000000.
> However, 0x8000000 should be a valid value in Maximum Capacity in
> either case, and both patches work for me.
I confirmed that patch also works on a system with exactly
3 TiB of memory.
More information about the fwts-devel
mailing list