From owner-svn-src-all@freebsd.org Wed Apr 3 06:36:42 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A201155F77E; Wed, 3 Apr 2019 06:36:42 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D073D95185; Wed, 3 Apr 2019 06:36:41 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8D510A01B; Wed, 3 Apr 2019 06:36:41 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x336afDC022384; Wed, 3 Apr 2019 06:36:41 GMT (envelope-from rpokala@FreeBSD.org) Received: (from rpokala@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x336aft4022383; Wed, 3 Apr 2019 06:36:41 GMT (envelope-from rpokala@FreeBSD.org) Message-Id: <201904030636.x336aft4022383@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rpokala set sender to rpokala@FreeBSD.org using -f From: Ravi Pokala Date: Wed, 3 Apr 2019 06:36:41 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-12@freebsd.org Subject: svn commit: r345836 - stable/12/sys/dev/jedec_dimm X-SVN-Group: stable-12 X-SVN-Commit-Author: rpokala X-SVN-Commit-Paths: stable/12/sys/dev/jedec_dimm X-SVN-Commit-Revision: 345836 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D073D95185 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 06:36:42 -0000 Author: rpokala Date: Wed Apr 3 06:36:41 2019 New Revision: 345836 URL: https://svnweb.freebsd.org/changeset/base/345836 Log: MFC r345611: Teach jedec_dimm(4) to be more forgiving of non-fatal errors. It looks like some DIMMs claim to have a TSOD, but actually don't. Some claim they weren't able to change the SPD page, but they did. Neither of those should be fatal errors. Modified: stable/12/sys/dev/jedec_dimm/jedec_dimm.c Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/dev/jedec_dimm/jedec_dimm.c ============================================================================== --- stable/12/sys/dev/jedec_dimm/jedec_dimm.c Wed Apr 3 06:18:24 2019 (r345835) +++ stable/12/sys/dev/jedec_dimm/jedec_dimm.c Wed Apr 3 06:36:41 2019 (r345836) @@ -271,12 +271,16 @@ jedec_dimm_attach(device_t dev) } /* The MSBit of the TSOD-presence byte reports whether or not the TSOD - * is in fact present. If it is, read manufacturer and device info from - * it to confirm that it's a valid TSOD device. It's an error if any of - * those bytes are unreadable; it's not an error if the device is simply - * not known to us (tsod_match == NULL). - * While DDR3 and DDR4 don't explicitly require a TSOD, essentially all - * DDR3 and DDR4 DIMMs include one. + * is in fact present. (While DDR3 and DDR4 don't explicitly require a + * TSOD, essentially all DDR3 and DDR4 DIMMs include one.) But, as + * discussed in [PR 235944], it turns out that some DIMMs claim to have + * a TSOD when they actually don't. (Or maybe the firmware blocks it?) + * + * If the SPD data says the TSOD is present, try to read manufacturer + * and device info from it to confirm that it's a valid TSOD device. + * If the data is unreadable, just continue as if the TSOD isn't there. + * If the data was read successfully, see if it is a known TSOD device; + * it's okay if it isn't (tsod_match == NULL). */ rc = smbus_readb(sc->smbus, sc->spd_addr, tsod_present_offset, &byte); if (rc != 0) { @@ -290,12 +294,14 @@ jedec_dimm_attach(device_t dev) if (rc != 0) { device_printf(dev, "failed to read TSOD Manufacturer ID\n"); - goto out; + rc = 0; + goto no_tsod; } rc = jedec_dimm_readw_be(sc, TSOD_REG_DEV_REV, &devid); if (rc != 0) { device_printf(dev, "failed to read TSOD Device ID\n"); - goto out; + rc = 0; + goto no_tsod; } tsod_match = jedec_dimm_tsod_match(vendorid, devid); @@ -310,6 +316,7 @@ jedec_dimm_attach(device_t dev) } } } else { +no_tsod: tsod_match = NULL; tsod_present = false; } @@ -622,9 +629,12 @@ jedec_dimm_dump(struct jedec_dimm_softc *sc, enum dram rc = smbus_writeb(sc->smbus, (JEDEC_DTI_PAGE | JEDEC_LSA_PAGE_SET1), 0, 0); if (rc != 0) { + /* Some SPD devices (or SMBus controllers?) claim the + * page-change command failed when it actually + * succeeded. Log a message but soldier on. + */ device_printf(sc->dev, "unable to change page: %d\n", rc); - goto out; } /* Add 256 to the store location, because we're in the second * page.