From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AE98DC982FD for ; Thu, 24 Sep 2026 04:52:39 +0000 (UTC) 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-Owner; bh=oieoRlWZXCCRqOKKR3cdG4hU9h4VdZh8ErAtbZSUifI=; b=25y3WUpNGekuiT l2Bi/rGVALPUsMG584N7V+ojKYsrIAfGixYP9aTPgEiCiNmq8T3oNPkFtdKsHQhXT44EfCSu532NE bGsI0dobdYtDX5bn9wsYJXC6/zGt9KR9ilTz8/89gZZiZVoAPbVsN9UxJqVfG3sELUh7x4zGGbefN OYxL8f8ArmULsE1MBc3ifrogi3N8WSKnJdz8NitsLNg86Yi2BLTKh/aoQ+9Ii9Uvqrg3TFeT2/nNE ZJxOT8hmHD4Dtjpz4xy9jUkHgcd6Jv26VicTzmAw8q9LBla7phmQUO8ElvDZ+tTHPN5ipl+y4Qm0d qkTzSBtFTH9V3xr/QS7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x9bRb-0000000A1ld-0b62; Thu, 24 Sep 2026 04:52:27 +0000 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x9bRX-0000000A1lE-3Jw1 for linux-riscv@lists.infradead.org; Thu, 24 Sep 2026 04:52:25 +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-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=A1FDhp6qEnhVheCdkCeYR2VOVfYNNI9vtB0izgIO5b8=; b=Z9qqdwHru7CVYd9khdvB3J5Gjd fcNlwbcCYSmDLQrHH99L6g7J5MMskmlQ8I6ewsnvFqdISHrf291ZBjYMIgMOA+REBLBgKcm/fiuDf 7lBK3D2fWxmFUEwxM2dx0QrW8sG+kqv5jo8XRFt1vZVVDMh7P4ljFxhbmOuWaIySMtWdTZurD0WLz Vq174oJ5z4Wb1DX5r9Bq6cjiXb7S/7k/6Lrhj5zoYkdiLIUcqRXIH9DohSx1prDCexIEDJD1ftkQl KaPH/uWYAOi3QraNrtJdJMVrVCaxhqm1+nCfOVgiCHfePM3yN5Cfq/Lhjhq1cw31IVwktaeSDPMxb mCpVsM1Q==; 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 1x9bRW-00000008K5r-0akf; Thu, 24 Sep 2026 06:52:22 +0200 Date: Thu, 24 Sep 2026 06:52:21 +0200 From: Aurelien Jarno To: Andy Chiu Cc: spacemit@lists.linux.dev, linux-riscv@lists.infradead.org, Karl Mehltretter Subject: Re: Random corruption on SpacemiT K1 (and K3) with RVV Message-ID: References: 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-20260923_215223_993644_91715820 X-CRM114-Status: GOOD ( 43.55 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org SGkgQW5keSwKCk9uIDIwMjYtMDktMjIgMTY6MzMsIEFuZHkgQ2hpdSB3cm90ZToKPiBIaSBBdXJl bGllbiwKPiAKPiBTb3JyeSBmb3IgcmVwbHlpbmcgbGF0ZS4gSSBkaWQgcnVuIGEgY29tcGlsYXRp b24gdGVzdCB3aXRoIHZlY3Rvcml6ZWQKPiBnbGliYyBpbiBxZW11IGFmdGVyIHNlZWluZyB0aGlz IHRocmVhZCBzaG9ydGx5LCBidXQgdGhlbiBmb2N1cyBvbgo+IHNvbWV0aGluZyBlbHNlIGFzIGl0 IGRpZG4ndCBjYXRjaCBhbnkgY29ycnVwdGlvbiB3ZSd2ZSBzZWVuIGhlcmUuCgpUaGFua3MgZm9y IHlvdXIgZmVlZGJhY2suIE5vdGUgdGhhdCBhdCB0aGlzIHN0YWdlIEkgaGF2ZSBub3QgYmVlbiBh YmxlIAp0byByZXByb2R1Y2UgdGhlIGlzc3VlIHdpdGggUUVNVS4gSSBndWVzcyBpdCdzIHZlcnkg dGltaW5nIGRlcGVuZGVudCwgCmFsc28gSSBhbSBub3Qgc3VyZSBpZiBRRU1VIHNpbXVsYXRlcyBw YXJ0aWFsbHkgZXhlY3V0ZWQgaW5zdHJ1Y3Rpb25zIAoob3V0c2lkZSBvZiBwYWdlIGZhdWx0cyku Cgo+IE9uIFdlZCwgU2VwIDA5LCAyMDI2IGF0IDA2OjQ1OjE0UE0gKzAyMDAsIEF1cmVsaWVuIEph cm5vIHdyb3RlOgo+ID4gW0FkZGVkIEFuZHkgYW5kIEthcmwgaW4gQ2M6IGFzIHRoZXkgaGF2ZSBi ZWVuIGludm9sdmVkIGluIHRoZSB2ZWN0b3JlZCAKPiA+IHVzZXIgY29weSBjb2RlIGFuZCBmaWdo dGluZyBzaW1pbGFyIGlzc3Vlc10KPiA+IAo+ID4gSGksCj4gPiAKPiA+IFNvbWUgbW9yZSBwcm9n cmVzcyBvbiB0aGF0IHRvcGljLgo+ID4gCj4gPiBPbiAyMDI2LTA5LTA4IDA2OjQyLCBBdXJlbGll biBKYXJubyB3cm90ZToKPiA+ID4gRGVhciBhbGwsCj4gPiA+IAo+ID4gPiBJIGhhdmUgZG9uZSBz b21lIHNtYWxsIHByb2dyZXNzIG9uIHRoYXQgaXNzdWUuIEhlbHAgaXMgc3RpbGwgd2FudGVkIGFu ZCAKPiA+ID4gd291bGQgYmUgYXBwcmVjaWF0ZWQuCj4gPiA+IAo+ID4gPiBPbiAyMDI2LTA4LTMw IDIyOjUyLCBBdXJlbGllbiBKYXJubyB3cm90ZToKPiA+ID4gPiBEZWFyIGFsbCwKPiA+ID4gPiAK PiA+ID4gPiBGb3IgdGhlIGxhc3Qgd2Vla3MsIEkgaGF2ZSBiZWVuIHRyYWNraW5nIGEgcmFuZG9t IG1lbW9yeSBjb3JydXB0aW9uIGFuZAo+ID4gPiA+IHJlbGF0aXZlbHkgcmFyZSBvbiBTcGFjZW1p VCBLMSAoQmFuYW5hIFBpIEYzIGFuZCBNaWxrLVYgSnVwaXRlcikuIEl0IAo+ID4gPiA+IHN0YXJ0 ZWQgdXBncmFkaW5nIHRvIGdsaWJjIDIuNDMsIHdoaWNoIGRvZXMgbWVtc2V0KCkgdGhyb3VnaCB2 ZWN0b3IgCj4gPiA+ID4gaW5zdHJ1Y3Rpb25zLiAgSXQgaXMgcmVwcm9kdWNpYmxlIHVzaW5nIHRo ZSBEZWJpYW4gNy4xLjctMX5icG8xMysxIAo+ID4gPiA+IGtlcm5lbCwgYnV0IEkgaGF2ZSBhbHNv IGJlZW4gYWJsZSB0byByZXByb2R1Y2UgaXQgd2l0aCBhIHZhbmlsbGEgNy4yLjIgCj4gPiA+ID4g a2VybmVsLCB1c2luZyBhIHNpbWlsYXIgY29uZmlndXJhdGlvbiB0byB0aGUgRGViaWFuIGtlcm5l bC4gVGhlIGJvYXJkIAo+ID4gPiA+IHVzZXMgT3BlblNCSSAxLjkgYW5kIHRoZSB2ZW5kb3IgVS1C b290Lgo+IAo+IFRoZSBLVk0gZml4LCB3aGljaCBpcyBpbiA3LjMgbm93LCBpcyBpcnJlbGF2YW50 IHRvIHRoaXMgYnVnIChzZWUgYmVsb3cpLAo+IGJlY2F1c2UgdGhlIGZpeCB0YXJnZXRzIHByZWVt cHRpYmxlIGtlcm5lbC1tb2RlIHZlY3RvciwgYnV0IHdlIGNhbgo+IHRyaWdnZXIgdGhpcyBidWcg d2l0aCBDT05GSUdfUklTQ1ZfSVNBX1ZfUFJFRU1QVElWRSB1bnNldC4gTm9udGhlbGVzcywKPiBp ZiB3ZSB3YW50IHRvIHRlc3Qgb24gdGhlIGxhdGVzdCBjb2RlLCBmZWVsIGZyZWUgdG8gZ3JhYiB0 aGUgc2VyaWVzIGF0Cj4gWzNdIGFuZCBib290IHdpdGggcmlzY3Zfbm92c3RhdGVvcHQgdG8gcHJl c2V2ZSB0aGUgY29udGV4dCBwb2lzb25pbmcKPiBiZWhhdmlvci4KClRoYW5rcywgSSdsbCB0cnkg dGhhdC4KCj4gPiA+IAo+ID4gPiBJIGhhdmUgYmVlbiBhYmxlIHRvIHJ1bGUgb3V0IE9wZW5TQkkg ZnJvbSB0aGUgaXNzdWUsIEkgaGF2ZSBjaGVja2VkIAo+ID4gPiB0aGVyZSBpcyBub3QgdHJhcCB0 b3AgT3BlblNCSSB3aGVuIHRoZSBwcm9ibGVtIGhhcHBlbnMuCj4gPiA+IAo+ID4gPiA+IFR5cGlj YWxseSBpdCBtYW5pZmVzdHMgaXRzZWxmIHdpdGggdGhlIGZvbGxvd2luZyBraW5kIG9mIGVycm9y LCB3aGVuIAo+ID4gPiA+IHJ1bm5pbmcgZysrIGZyb20gR0NDIDE2IGFzIHBhcnQgb2YgYnVpbGRp bmcgc29mdHdhcmUgKGUuZy4gT3BlbkpESywgCj4gPiA+ID4gQmxlbmRlciwgRG9sZmluLCBRdDYp OiAgIAo+ID4gPiA+IAo+ID4gPiA+IEFzc2VtYmxlciBtZXNzYWdlczoKPiA+ID4gPiB7c3RhbmRh cmQgaW5wdXR9OjI4NDU4ODogRXJyb3I6IHVua25vd24gcHNldWRvLW9wOiBgLnVsZWIxJwo+ID4g PiA+IHtzdGFuZGFyZCBpbnB1dH06Mjg0NTg4OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29kZSBg w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/ w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/ w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv3ZsODc0Jwo+ID4gPiA+IAo+ ID4gPiA+IFRoZSBicm9rZW4gY2hhcnMgYXJlIDB4ZmYgYW5kIGl0IHNlZW1zIHRoZXJlIGFyZSBh bHdheXMgMjQwIChidXQgd2l0aCAKPiA+ID4gPiBwb29yIHN0YXRpc3RpY3MpLiBTb21ldGltZXMg aXQgaW5zdGVhZCBjYXVzZXMgYSBHQ0MgSUNFIGluc3RlYWQuCj4gPiA+IAo+ID4gPiBJIGhhdmUg aWRlbnRpZmllZCB0aGF0IHRoZSAweGZmIGNvbWVzIGZyb20gdGhlIHBvaXNvbmluZyBkb25lIGZv ciB2MCBpbgo+ID4gPiBfX3Jpc2N2X3ZfdnN0YXRlX2Rpc2NhcmQoKSwgd2hpY2ggc2hvdWxkIG9u bHkgaGFwcGVuIGZvciBhIHN5c2NhbGwuIAo+ID4gPiBJbmRlZWQgY2hhbmdpbmcgdGhlIHZhbHVl IHRvIGRpZmZlcmVudCBvbmVzIHByb3BhZ2F0ZXMgdG8gdGhlIGFib3ZlIAo+ID4gPiBlcnJvciBt ZXNzYWdlLgo+ID4gPiAKPiA+ID4gRnVydGhlcm1vcmUgSSBoYXZlIGZvdW5kIHRoYXQgY2hhbmdp bmcgQ09ORklHX1JJU0NWX0lTQV9WX1BSRUVNUFRJVkUgCj4gPiA+IGRvZXNuJ3QgY2hhbmdlIGFu eXRoaW5nLCBhbmQgdGhhdCBjaGFuZ2luZyBSSVNDVl9JU0FfVl9VQ09QWV9USFJFU0hPTEQgCj4g PiA+IGNoYW5nZXMgdGhlIG51bWJlciBvZiBicm9rZW4gYnl0ZXMuCj4gCj4gVHVybm5pbmcgb2Zm IENPTkZJR19SSVNDVl9JU0FfVl9QUkVFTVBUSVZFIG1ha2VzIHRoZSB1Y29weSBmYWxsIGJhY2sg dG8KPiB0aGUgc2NhbGFyIGNvcHkgb24gYSBwYWdlIGZhdWx0LCBiZWNhdXNlIGZhdWx0aGFuZGxl cl9kaXNhYmxlZCgpIHdvdWxkCj4gcmV0dXJuIHRydWUgYWZ0ZXIga2VybmVsX3ZlY3Rvcl9iZWdp bigpLiBTbyBpZiB3ZSBhcmUgc3VzcGVjdGluZyBhCj4gY29ycnVwdGlvbiBhdCB2ZWN0b3IgcmVz dGFydCwgdGhlbiBpdCBpcyBub3QsIHRoZXJlIGlzIG5vIHJlc3RhcnRpbmcgb2YKPiBzdWNoIGlu c3RydWN0aW9uLgo+IAo+IFRoZSBvbmx5IHBvc3NpYmxlIHdheSB0byBoYXZlIGEgcmVzdGFydGVk IHZlY3RvciBsZC9zdCBoZXJlIHVuZGVyCj4gIUNPTkZJR19SSVNDVl9JU0FfVl9QUkVFTVBUSVZF IGlzIHRoZW4gYW4gaXJxIHJlc3RhcnQuIEkgZG9uJ3Qga25vdyBpZgo+IHlvdSB0ZXN0IHRoaXMg Y29kZSB3aXRoICFDT05GSUdfUklTQ1ZfSVNBX1ZfUFJFRU1QVElWRSAqKmFuZCoqIHdpdGgKPiBp cnFzX2Rpc2FibGVkKCkgPT0gdHJ1ZSBpbiB0aGUgdXNlciBjb3B5IGNvZGUuIElmIHdlIHN0aWxs IG9ic2VydmVkCj4gYSBjb3JydXB0aW9uIHVuZGVyIHRoaXMgY2FzZSwgdGhlbiBpdCBzdWdnZXN0 cyB0aGF0IHRoZSBjb3JydXB0aW9uCj4gaGFwcGVucyBldmVuIGVhcmlsZXIuIEl0IGlzIHRoZW4g ZWl0aGVyIHRoZSBmYXVsdGluZyBpbnN0cnVjdGlvbiBpdHNlbGYsCj4gb3IgdGhlIGNvcnJ1cHRp b24gaGFwcGVucyBldmVuIGVhcmlsZXIuCgpJIGhhdmUgYWxyZWFkeSB0cmllZCB3aXRoIGJvdGgg Q09ORklHX1JJU0NWX0lTQV9WX1BSRUVNUFRJVkU9biBhbmQgCndyYXBwaW5nIHRoZSB2ZWN0b3Jl ZCB1c2VyIGNvcHkgY2FsbCBpbiBiZXR3ZWVuIGxvY2FsX2lycV9zYXZlKGZsYWdzKSAKYW5kIGxv Y2FsX2lycV9yZXN0b3JlKGZsYWdzKS4gVGhlIHByb2JsZW0gaXMgc3RpbGwgcmVwcm9kdWNpYmxl LgoKSSBoYXZlIGFsc28gdHJpZWQgdG8gaW5zdHJ1bWVudCB0aGUgdmVjdG9yZWQgdXNlciBjb3B5 IGNvZGUgYnkgc2F2aW5nIAp0aGUgaW5zcmV0IGNycyBiZWZvcmUgYW5kIGFmdGVyIHRoZSB2bGU4 LnYgaW5zdHJ1Y3Rpb24gdG8gZGV0ZWN0IGEgCnBvc3NpYmxlIGludGVycnVwdGVkIGluc3RydWN0 aW9uIChhcyBzdWdnZXN0ZWQgb24gSVJDKSwgYnV0IGFkZGluZyB0aGlzIApjb2RlIHNlZW1zIHRv IGhhdmUgImZpeGVkIiB0aGUgaXNzdWUuCgo+ID4gVGhlIHZhbHVlcyBmcm9tIF9fcmlzY3Zfdl92 c3RhdGVfZGlzY2FyZCgpIGVuZC11cCB0aGVyZSBiZWNhdXNlIHRoZXkgYXJlIAo+ID4gdGhlIGxh c3QgdmFsdWVzIHdyaXR0ZW4gdG8gdGhlIHZlY3RvciByZWdpc3RlcnMuIEkgaGF2ZSBhZGRlZCBz b21lIAo+ID4gcG9pc29uaW5nIGluIF9fYXNtX3ZlY3Rvcl91c2VyY29weV9zdW1fZW5hYmxlZCBi ZWZvcmUgdGhlIGxvb3AsIGFuZCAKPiA+IHRob3NlIHZhbHVlcyBhcHBlYXIgaW5zdGVhZC4gVXNp bmcgZGlmZmVyZW50IHZhbHVlcyBwZXIgdmVjdG9yIHJlZ2lzdGVyLCAKPiAKPiBEbyB5b3Uga25v dyB3aGF0IGlzIHRoZSBhZGRyZXNzIG9mIGNvcnJ1cHRlZCBkYXRhPyBJZiBpdCBhbHdheXMgc3Rh cnRzIGF0Cj4gYSBwYWdlIGJvdW5kYXJ5IChlLmcgb2Zmc2V0IDB4MDAwMDAgZm9yIFRIUCkgdGhl biBpdCBzdWdnZXN0cyBhIHN0cm9uZwo+IGNvcnJlbGF0aW9uIHdpdGggZmF1bHQgaGFuZGxpbmcu CgpPbiB0aGUgSzEsIGZvciB0aGUgZmV3IGNhc2VzIEkgY2FwdHVyZWQsIG5vbmUgb2YgdGhlbSBp bnZvbHZlZCA0ayBwYWdlIApjcm9zc2luZyBvbiBlaXRoZXIgc291cmNlIG9yIGRlc3RpbmF0aW9u LiBUaGUgb25seSBpbnZhcmlhbnQgSSBoYXZlIApmb3VuZCBpcyB0aGF0IGZvciBzb21lIHJlYXNv biB0aGUgZmlyc3QgaXRlcmF0aW9uIG9mIHRoZSBsb29wIG9ubHkgCmxvYWRzIDE2IGJ5dGVzLCBh bmQgd3JpdGUgMjU2IGJ5dGVzLiBUaGUgc2Vjb25kIGl0ZXJhdGlvbiBvZiB0aGUgbG9vcCAKdGhl biBnb2VzIHRvIHRoZSBsb2FkIGZpeHVwIGFuZCBleGl0cy4KCk9uIHRoZSBLMywgSSBoYXZlIG5l dmVyIG9ic2VydmVkIGEgY29ycnVwdGlvbiBhdCB0aGUgdmVjdG9yIHVzZXIgY29weSwgCmJ1dCBJ IHN0aWxsIG9ic2VydmVkIHJhcmUgbWVtb3J5IGNvcnJ1cHRpb25zIGNhdXNpbmcgZ2NjIHRvIGNy YXNoLCBhbmQgCndoaWNoIGRpc2FwcGVhcmVkIHdoZW4gZGlzYWJsaW5nIHZlY3RvciBpbnN0cnVj dGlvbnMgYXQgdGhlIGRldmljZSB0cmVlCmxldmVsLCBsaWtlIG9uIHRoZSBLMS4gQnV0IHRoYXQg Y291bGQgYmUgdHdvIGRpZmZlcmVudCBpc3N1ZXMgbGlua2VkIHRvIAp2ZWN0b3IgaW5zdHJ1Y3Rp b25zLgoKUmVnYXJkcwpBdXJlbGllbgoKLS0gCkF1cmVsaWVuIEphcm5vICAgICAgICAgICAgICAg ICAgICAgICAgICBHUEc6IDQwOTZSLzFEREQ4QzlCCmF1cmVsaWVuQGF1cmVsMzIubmV0ICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL2F1cmVsMzIubmV0CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1yaXNjdiBtYWlsaW5nIGxpc3QKbGludXgt cmlzY3ZAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpbnV4LXJpc2N2Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from hall.aurel32.net (hall.aurel32.net [195.154.119.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8526F3E5EDB for ; Thu, 24 Sep 2026 04:52:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.154.119.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790225547; cv=none; b=rqodwqwvdjChKivrwPUwDpEA6Rjz+UI1EHvbFnsZpEYqVB5QMvDv38Uxe07wI5UYzWfJpTfRxBmVkBbBx3jBB6B7a8N9knk30aadMSkhdZwJf+9n52PtPSTyXw35dQVyxWRq1erU10el2HkI7VPKssSXVgQ/I+NYSKTgcWVns48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790225547; c=relaxed/simple; bh=Sm7rxm9F59RolhH/a1WLNbmEdD9CcgKjDn3oyDUbc1M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hl8/4ohHB6faYSxroBuGhBjsDiw3xG6Rr40UXVzCLOkizs7eSrYMyYcySElLAb4FcgjxBpJYFqGoZanVkjwu28vt5tKrFHatohIcT/lnJgeQH4KF7o+cXtZWR4c2aUJcrVfXAhTlaOPKnFM6wpn1Flz0jWMgPK/GhvTDKSRsNnk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=aurel32.net; spf=pass smtp.mailfrom=aurel32.net; dkim=pass (2048-bit key) header.d=aurel32.net header.i=@aurel32.net header.b=Z9qqdwHr; arc=none smtp.client-ip=195.154.119.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=aurel32.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aurel32.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aurel32.net header.i=@aurel32.net header.b="Z9qqdwHr" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=A1FDhp6qEnhVheCdkCeYR2VOVfYNNI9vtB0izgIO5b8=; b=Z9qqdwHru7CVYd9khdvB3J5Gjd fcNlwbcCYSmDLQrHH99L6g7J5MMskmlQ8I6ewsnvFqdISHrf291ZBjYMIgMOA+REBLBgKcm/fiuDf 7lBK3D2fWxmFUEwxM2dx0QrW8sG+kqv5jo8XRFt1vZVVDMh7P4ljFxhbmOuWaIySMtWdTZurD0WLz Vq174oJ5z4Wb1DX5r9Bq6cjiXb7S/7k/6Lrhj5zoYkdiLIUcqRXIH9DohSx1prDCexIEDJD1ftkQl KaPH/uWYAOi3QraNrtJdJMVrVCaxhqm1+nCfOVgiCHfePM3yN5Cfq/Lhjhq1cw31IVwktaeSDPMxb mCpVsM1Q==; 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 1x9bRW-00000008K5r-0akf; Thu, 24 Sep 2026 06:52:22 +0200 Date: Thu, 24 Sep 2026 06:52:21 +0200 From: Aurelien Jarno To: Andy Chiu Cc: spacemit@lists.linux.dev, linux-riscv@lists.infradead.org, Karl Mehltretter Subject: Re: Random corruption on SpacemiT K1 (and K3) with RVV Message-ID: References: Precedence: bulk X-Mailing-List: spacemit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/2.4.1 (2026-07-04) Hi Andy, On 2026-09-22 16:33, Andy Chiu wrote: > Hi Aurelien, >=20 > Sorry for replying late. I did run a compilation test with vectorized > glibc in qemu after seeing this thread shortly, but then focus on > something else as it didn't catch any corruption we've seen here. Thanks for your feedback. Note that at this stage I have not been able=20 to reproduce the issue with QEMU. I guess it's very timing dependent,=20 also I am not sure if QEMU simulates partially executed instructions=20 (outside of page faults). > On Wed, Sep 09, 2026 at 06:45:14PM +0200, Aurelien Jarno wrote: > > [Added Andy and Karl in Cc: as they have been involved in the vectored= =20 > > user copy code and fighting similar issues] > >=20 > > Hi, > >=20 > > Some more progress on that topic. > >=20 > > On 2026-09-08 06:42, Aurelien Jarno wrote: > > > Dear all, > > >=20 > > > I have done some small progress on that issue. Help is still wanted a= nd=20 > > > would be appreciated. > > >=20 > > > On 2026-08-30 22:52, Aurelien Jarno wrote: > > > > Dear all, > > > >=20 > > > > For the last weeks, I have been tracking a random memory corruption= and > > > > relatively rare on SpacemiT K1 (Banana Pi F3 and Milk-V Jupiter). I= t=20 > > > > started upgrading to glibc 2.43, which does memset() through vector= =20 > > > > instructions. It is reproducible using the Debian 7.1.7-1~bpo13+1= =20 > > > > kernel, but I have also been able to reproduce it with a vanilla 7.= 2.2=20 > > > > kernel, using a similar configuration to the Debian kernel. The boa= rd=20 > > > > uses OpenSBI 1.9 and the vendor U-Boot. >=20 > The KVM fix, which is in 7.3 now, is irrelavant to this bug (see below), > because the fix targets preemptible kernel-mode vector, but we can > trigger this bug with CONFIG_RISCV_ISA_V_PREEMPTIVE unset. Nontheless, > if we want to test on the latest code, feel free to grab the series at > [3] and boot with riscv_novstateopt to preseve the context poisoning > behavior. Thanks, I'll try that. > > >=20 > > > I have been able to rule out OpenSBI from the issue, I have checked= =20 > > > there is not trap top OpenSBI when the problem happens. > > >=20 > > > > Typically it manifests itself with the following kind of error, whe= n=20 > > > > running g++ from GCC 16 as part of building software (e.g. OpenJDK,= =20 > > > > Blender, Dolfin, Qt6): =20 > > > >=20 > > > > Assembler messages: > > > > {standard input}:284588: Error: unknown pseudo-op: `.uleb1' > > > > {standard input}:284588: Error: unrecognized opcode `=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BFvl874' > > > >=20 > > > > The broken chars are 0xff and it seems there are always 240 (but wi= th=20 > > > > poor statistics). Sometimes it instead causes a GCC ICE instead. > > >=20 > > > I have identified that the 0xff comes from the poisoning done for v0 = in > > > __riscv_v_vstate_discard(), which should only happen for a syscall.= =20 > > > Indeed changing the value to different ones propagates to the above= =20 > > > error message. > > >=20 > > > Furthermore I have found that changing CONFIG_RISCV_ISA_V_PREEMPTIVE= =20 > > > doesn't change anything, and that changing RISCV_ISA_V_UCOPY_THRESHOL= D=20 > > > changes the number of broken bytes. >=20 > Turnning off CONFIG_RISCV_ISA_V_PREEMPTIVE makes the ucopy fall back to > the scalar copy on a page fault, because faulthandler_disabled() would > return true after kernel_vector_begin(). So if we are suspecting a > corruption at vector restart, then it is not, there is no restarting of > such instruction. >=20 > The only possible way to have a restarted vector ld/st here under > !CONFIG_RISCV_ISA_V_PREEMPTIVE is then an irq restart. I don't know if > you test this code with !CONFIG_RISCV_ISA_V_PREEMPTIVE **and** with > irqs_disabled() =3D=3D true in the user copy code. If we still observed > a corruption under this case, then it suggests that the corruption > happens even eariler. It is then either the faulting instruction itself, > or the corruption happens even eariler. I have already tried with both CONFIG_RISCV_ISA_V_PREEMPTIVE=3Dn and=20 wrapping the vectored user copy call in between local_irq_save(flags)=20 and local_irq_restore(flags). The problem is still reproducible. I have also tried to instrument the vectored user copy code by saving=20 the insret crs before and after the vle8.v instruction to detect a=20 possible interrupted instruction (as suggested on IRC), but adding this=20 code seems to have "fixed" the issue. > > The values from __riscv_v_vstate_discard() end-up there because they ar= e=20 > > the last values written to the vector registers. I have added some=20 > > poisoning in __asm_vector_usercopy_sum_enabled before the loop, and=20 > > those values appear instead. Using different values per vector register= ,=20 >=20 > Do you know what is the address of corrupted data? If it always starts at > a page boundary (e.g offset 0x00000 for THP) then it suggests a strong > correlation with fault handling. On the K1, for the few cases I captured, none of them involved 4k page=20 crossing on either source or destination. The only invariant I have=20 found is that for some reason the first iteration of the loop only=20 loads 16 bytes, and write 256 bytes. The second iteration of the loop=20 then goes to the load fixup and exits. On the K3, I have never observed a corruption at the vector user copy,=20 but I still observed rare memory corruptions causing gcc to crash, and=20 which disappeared when disabling vector instructions at the device tree level, like on the K1. But that could be two different issues linked to=20 vector instructions. Regards Aurelien --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net