From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5053C606C900 for ; Wed, 4 Nov 2026 21:35:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=N5EYKqji; dkim=fail reason="signature verification failed" (2048-bit key, unprotected) header.d=aurel32.net header.i=@aurel32.net header.a=rsa-sha256 header.s=202004.hall header.b=ob5OVMRV DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=BoAOcvpB0KCVN6I8ofSX6r7LpnunN/RyGPzPwSu/f1k=; b=N5EYKqjivORck/mB2QoxUA+gHB sZ9jD61vDAu/egqLgpRp5xuVl8j+K/Dhy8/bnHWOODC+VUBVu1IXEG6QsnEqdFiBqZukbTh5sglvu wGCgK14QhDaCfTpduV4jWq+mU+Yn1hMhc+UopwOQwSp4w0sW0OQxxcaWTXqtbcIcFcKymuWmc+L8c JIotG32yia4hiAM3ZrupeS9ImhDN10Yf74XJKRFBYeXwggT87oyyVEZJ7Pa5MZqnr6O0X6zPlgAel Pxst2hwTCDhzZpvfDmu69DYN3P8735uAAFpht0xq/35eliaQg/JGS+z4sXwuOTr15lJ4Fh0+tHqXj 3QrrBjVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xOie2-000000074F8-1DSI; Wed, 04 Nov 2026 21:35:46 +0000 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xOidz-000000074Bw-2fwD for linux-riscv@lists.infradead.org; Wed, 04 Nov 2026 21:35:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Content-Transfer-Encoding:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=/7JrcXZgLdpl6NGyBFMTX/zKwhL1anMhZGiNls+BU5o=; b=ob5OVMRVUSBeNDNBiUEPoBb6BH +Z6m1MGzajBADFSlzRZthHp7MmSBtSpFf24Nn5TR2l2QGyf1xK3uKEpZ8mmnjled7Hm/AD+waTcG9 eeZeJnzxDTA1MiDRLmHAb19TTLOJpjA89ThQlx1WUyEG7JVZ3AcESDUMdlyE71QI5sZrZqrV65Xnp Bvzp/6lI+bNIyN26jPpm1d/uvn7XJ0vfLmU0v5cxTSrEhgZwIZt98HD/BNeFvFl/PwacANTzqBxBH EcnNK4GbYzLzLmtK/HkY9QD2L06wMfV+GRkdH5TBHIH5wJKSjN3lINAoL+j1FNCMVLcUYRTPuz5Gj bWZrreuQ==; Received: from authenticated user by hall.aurel32.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xOidm-0000000FWzy-2EF1; Wed, 04 Nov 2026 22:35:30 +0100 Date: Wed, 4 Nov 2026 22:35:29 +0100 From: Aurelien Jarno To: Vivian Wang Cc: Karl Mehltretter , Andy Chiu , spacemit@lists.linux.dev, linux-riscv@lists.infradead.org Subject: Re: Random corruption on SpacemiT K1 (and K3) with RVV Message-ID: References: X-Archived-By: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.4.1 (2026-07-04) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261104_133543_678570_AB224AEB X-CRM114-Status: GOOD ( 16.29 ) X-Spam-Score: -4.4 (----) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Hi, I have finally been able to capture the last few exceptions happening for one event where the vectored user copy code is corrupting data. That was on the SpacemiT K1. I added a hook to handle_exception(), activated only when __asm_vector_usercopy_sum_enabled is running, and recording CPU state at the beginning of the exception, in per-CPU 16-entry tables. On the OpenSBI side, I also instrumented sbi_trap_handler() to log the CAUSE_MISALIGNED_LOAD and CAUSE_LOAD_ACCESS cases. This only fires during the kernel boot when it tries to measure speed of unaligned accesses. The case I captured was a 4096-byte long copy, from 0x2a883310 (userland) to 0xffffffd701e54000 (kernel), presumably from a write syscall. The copy is considered successful, i.e it exits with a0=0. That said after the copy, the source and the destination start to differ after the first 16 bytes, at address 0xffffffd701e54010. The copy started on CPU 5 and ended on CPU 5, and there was only a single exception between the start and the end, so it wasn't rescheduled. The exception happened with epc=0xffffffff80e09204, which corresponds to the location of the "vle8.v v0,(a1)" instruction. I recorded: - cause=0xd - badaddr=0x2a883410 - a0=0xffffffd701e54100 - a1=0x2a883410 - a2=0xf00 - vl=0x100 - vstart=0x0 - vtype=0xc3 As you can see, the exception happened during the second iteration of the loop. It is not clear to me why the first iteration didn't trigger a page fault, as both 0x2a883310 and 0x2a883410 are on the same 4k page. I have also logged the content of v0 at the time of the exception, and I can clearly see that only the first 16 bytes (out of 32 bytes) got loaded during the previous iteration. Its content matches the error reported by GNU as on the userland side. Then the remaining of the loop continued without exception to copy 4096 bytes in total. At this stage, I do not have any other explanation than a CPU bug. That said, I have noticed that the problem started when userland started to use the vector extension, and with the above, I do not have any explanation for the link between the two. I'll try to capture another corruption event (it takes ages) to see if it can help refine the explanation. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv