https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235944
--- Comment #14 from Andriy Gapon <a...@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. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
