[Bug 235944] jedec_dimm(4) does not attach to KFA2 (aka Galax) Hall of Fame DDR4 sticks

[bugzilla-noreply at freebsd.org]

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

--- Comment #14 from Andriy Gapon <avg at FreeBSD.org> ---
(In reply to Ravi Pokala from comment #13)
Oh, I recall this now.  Thank you for refreshing my memory.  And I could have
checked the code more thoroughly myself.  So, sorry for the noise.

In one part-specific datasheet I noticed this curious bit:
https://www.onsemi.com/pub/Collateral/N34C04-D.PDF
> 17. The N34C04MU3ETG will respond with NoACK following the dummy Data Byte,
> while the N34C04MU3EKTG will respond with ACK.

Maybe that NoACK (NACK) is what we are seeing here as an SMBus error.
Although the code mapped PIIX4_SMBHSTSTAT_ERR | PIIX4_SMBHSTSTAT_INTR to
SMB_EBUSERR rather than to SMB_ENOACK, I am not sure if that mapping is
(universally) correct.

E.g., in one AMD BKDG document I see this:
> Bits            Description
> 2               DeviceErr. Read; Write-1-to-clear; Set-by-hardware.
>                 Reset: 0.
>                 1=An error of one of the following occurred:
>                 • Illegal command field.
>                 • Unclaimed cycle
>                 • Host device time-out.
> 1               SMBusInterrupt. Read; Write-1-to-clear; Set-by-hardware.
>                 Reset: 0. 1=Completion of the last host command.

A combination of these bits can mean an "unclaimed cycle" and maybe that means
"NACK" in the SMBus protocol terminology.

So, it would be interesting to see
- what specific EEPROM part the DIMM in question uses (a looking glass can
help)
- what happens if we ignore the error from the page change write

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