From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18595 invoked by alias); 17 Jun 2018 21:39:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 18585 invoked by uid 89); 17 Jun 2018 21:39:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=noise, chip X-HELO: mail-wr0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=cT+QEify0UkXSsaDvFYBX3jCIe0gWqnD5E4FfeL5jxM=; b=HEf6oJV/phFDMfAM7QZoVHwQnTRx3yDAfCajmX12XdWxRwv1Sa2xpCh1hpXFm9s5b5 IySMDOQRNsBxRzUBR3lA5WaKqYWsOyk8NjubP0llutdSgHoCf2h0Cz9F8+XwkPOY4Kgs fqMDYgN0iFldvXUDlI/toGEyF1sLOqgpmUm63LMBwbWdBoQPtxcmbJm7lRhT43iyHThf g+HIdD5uowNVVdpKtUXxTgswZVpYuB/pIZktYSIm1h94GjFJodElAzG0oG3DvzfWDcTG VrZqg1wjHbf7tzq/xj43rtBHaZAQdOfvwFUqZWX+9S1BrGSRDZmJbKO+ULFTTuAkSVfB NCRA== X-Gm-Message-State: APt69E3CbpUjUmPzQmOBwvEb95l+pSCr5TcRR4TPhM8KvM0m4CIhU4vK wMPD+SMoXbGE59kRmsfB8CQN+A== X-Google-Smtp-Source: ADUXVKJFiht8CcdtQE0KUhf3ICgFCnBVbw3VzWYKFSEbJwYMsf6MRTCnNAYvyEjpqQDHmPsoS1oF3g== X-Received: by 2002:adf:dc52:: with SMTP id m18-v6mr8653644wrj.84.1529271592834; Sun, 17 Jun 2018 14:39:52 -0700 (PDT) Date: Sun, 17 Jun 2018 21:39:00 -0000 From: Sergei Trofimovich To: libc-alpha@sourceware.org, linux-kernel@vger.kernel.org, x86@kernel.org Cc: "H.J. Lu" Subject: Re: x86_64: movdqu rarely stores bad data (movdqu works fine). Kernel bug, fried CPU or glibc bug? Message-ID: <20180617223941.3e1e4973@sf> In-Reply-To: <20180616222250.618cecaa@sf> References: <20180616222250.618cecaa@sf> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/0/IHR=MHGvQz/5AQoC5jeZa"; protocol="application/pgp-signature" X-SW-Source: 2018-06/txt/msg00467.txt.bz2 --Sig_/0/IHR=MHGvQz/5AQoC5jeZa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 895 On Sat, 16 Jun 2018 22:22:50 +0100 Sergei Trofimovich wrote: > TL;DR: on master string/test-memmove glibc test fails on my machine > and I don't know why. Other tests work fine. > ... > This fails: > loop { > movdqu [src++],%xmm0 > movntdq %xmm0,[dst++] > } > sfence > This works: > loop { > movdqu [src++],%xmm0 > movdqu %xmm0,[dst++] > } > sfence > ... > If there is no obvious problems with glibc's memove() or my small test > what can I do to rule-out/pin-down hardware or kernel problem? Found the cause: bad RAM module. After I've tweaked test to allocate most of available physical RAM I've got fully reproducible failure. I unplugged RAM modules one by one and ran the test. That way I've nailed down to one bad chip. Removing single bad chip restored string/test-memmove test on this machine \o/ Sorry for the noise! --=20 Sergei --Sig_/0/IHR=MHGvQz/5AQoC5jeZa Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSZKa0VG5avZRlY01hxoe52YR/zqgUCWybVHgAKCRBxoe52YR/z qq6fAJ9NIvK9XdOxNwHE20NPbDnGiUWY/ACfWHSy5bqY6Qpg3IIyibb5PfcaW1Q= =B3bY -----END PGP SIGNATURE----- --Sig_/0/IHR=MHGvQz/5AQoC5jeZa--