I wonder if a summary report of detected RAM might be worthwhile, e.g., “4 RAM
slots, 2 RAM DIMMs detected” - it’d be better still if the kernel could report
the relationship between RAM present and memory controller channels (e.g., does
it appear that RAM is spread across them for interleaving?).
just a thought while the code is being tilled,
Erik
> On May 16, 2021, at 14:07, Jason Thorpe wrote:
>
>>
>> On May 16, 2021, at 1:06 PM, matthew green wrote:
>>
>>> Modified Files:
>>> src/sys/dev/i2c [thorpej-i2c-spi-conf]: spdmem_i2c.c
>>>
>>> Log Message:
>>> The last change had an unfortunate side-effect on empty DIMM slots, so
>>> roll that back. Instead, if we used direct config, then probe for the
>>> module in the attach routine and report if the module is not present,
>>> rather than assuming that it is.
>>
>> this seems odd to me.
>>
>> if we're using direct config, shouldn't match() be fully
>> able to determine present or not, avoiding having to have
>> an attach() that fake-fails?
>
> The problem is if a device tree has a node for a SPD DIMM, but the DIMM
> *isn’t actually present* (i.e. the node is for “DIMM might live here, go
> check!”). Returning “no match” in this situation would result in a “… not
> configured” message for a non-existent DIMM.
>
>>
>> thanks.
>>
>>
>> .mrg.
>
> -- thorpej
