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 74A5DC88E75 for ; Fri, 18 Sep 2026 04:35:08 +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=NE9rYLFJuz6PXF79Q7AV4im3PmsPoz+TbHxVqjhP624=; b=lGq4xiFxTKKabK 2sMWQ3ubb2oCs97nRNwgNtD7/S9ngwrCr+Y6S26lpv004s/bR8LYrbnIFzlE6rSgCmP1hzgpHM/Ki 9TTVDStgcWdACwqTsaa6MfBP6XWYJjIZTWzpH3/9q2vNslOkJ+WUY7R3auZOUhiLniO/BnMY/qqzl QNQ8ggjOycqI7e9gwsmA9j4JoaEHOnFnWuceniBkUXgScBs9r/95h8k69/i4qTSHvj2ZC2Dz5u6Se odBz6zLhg8YBW7vLVHsD5hcma3MJidM2ZaB1ZI53YdsjMBvyU+yWkO+YevvJ4IMUnTjcRRuWhGP/9 ZkjWMGHGxAZlWgmf5TGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x7QJH-0000000DSfP-31Nk; Fri, 18 Sep 2026 04:34:51 +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 1x7QJE-0000000DSeE-20e8 for linux-riscv@lists.infradead.org; Fri, 18 Sep 2026 04:34:50 +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=jMZYBazdiY2OeMs68QlA4oobhnvN+ZgUafNXD/I6otg=; b=fj9R5EdLsTSC7vDyLbknhfrWhx TYSuDHkJ0zhMkv42+uoJbMoQJ6HNs+bOgCDeGR3q0rlDeXM18esdjSVA4Or54LF6RKweO4MWPjtk7 0GxsoYi85Thwf7GSFaosz+oewsOMeoT27hrJtI0enVBcyE8yLtbcz5u9s8W/dsdTSE9bbx/B2qkjI 2B/u8nhq1d7+QPCXX26rAaGWDrPntCT1bFC/8H93wiZYXKvmJNifcSsW3Qr99ov6psDHWz4swjf8w kf45nag0/oZkGSZ5FuPZCe2vGuMgaROSZ8dPfQeld0sLsm6bSiwz245F6d1UJkvHNZ1+Dggg9bNMB 2Lq3KVQw==; 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 1x7QJ5-00000000BUn-2F7u; Fri, 18 Sep 2026 06:34:39 +0200 Date: Fri, 18 Sep 2026 06:34:39 +0200 From: Aurelien Jarno To: Palmer Dabbelt Cc: spacemit@lists.linux.dev, linux-riscv@lists.infradead.org, tchiu@tenstorrent.com, kmehltretter@gmail.com 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-20260917_213448_660999_FA4D8E43 X-CRM114-Status: GOOD ( 57.70 ) 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 SGkgUGFsbWVyLAoKVGhhbmtzIGZvciB5b3VyIGFuc3dlci4KCk9uIDIwMjYtMDktMTcgMTI6MTgs IFBhbG1lciBEYWJiZWx0IHdyb3RlOgo+IE9uIFR1ZSwgMTUgU2VwIDIwMjYgMTQ6MTQ6MTAgUERU ICgtMDcwMCksIGF1cmVsaWVuQGF1cmVsMzIubmV0IHdyb3RlOgo+ID4gSGksCj4gPiAKPiA+IFNv bWUgbW9yZSB1cGRhdGUsIGV2ZW4gaWYgdGhlIHByb2dyZXNzIGlzIHF1aXRlIGxvdy4KPiAKPiBX ZWxsLCB0aGFua3MgZm9yIGRpZ2dpbmcgaW50byB0aGlzLgo+IAo+ID4gCj4gPiBPbiAyMDI2LTA5 LTA5IDE4OjQ1LCBBdXJlbGllbiBKYXJubyB3cm90ZToKPiA+ID4gW0FkZGVkIEFuZHkgYW5kIEth cmwgaW4gQ2M6IGFzIHRoZXkgaGF2ZSBiZWVuIGludm9sdmVkIGluIHRoZQo+ID4gPiB2ZWN0b3Jl ZCB1c2VyIGNvcHkgY29kZSBhbmQgZmlnaHRpbmcgc2ltaWxhciBpc3N1ZXNdCj4gPiA+IAo+ID4g PiBIaSwKPiA+ID4gCj4gPiA+IFNvbWUgbW9yZSBwcm9ncmVzcyBvbiB0aGF0IHRvcGljLgo+ID4g PiAKPiA+ID4gT24gMjAyNi0wOS0wOCAwNjo0MiwgQXVyZWxpZW4gSmFybm8gd3JvdGU6Cj4gPiA+ ID4gRGVhciBhbGwsCj4gPiA+ID4gPiBJIGhhdmUgZG9uZSBzb21lIHNtYWxsIHByb2dyZXNzIG9u IHRoYXQgaXNzdWUuIEhlbHAgaXMgc3RpbGwKPiA+ID4gd2FudGVkIGFuZCA+IHdvdWxkIGJlIGFw cHJlY2lhdGVkLgo+ID4gPiA+ID4gT24gMjAyNi0wOC0zMCAyMjo1MiwgQXVyZWxpZW4gSmFybm8g d3JvdGU6Cj4gPiA+ID4gPiBEZWFyIGFsbCwKPiA+ID4gPiA+ID4gPiBGb3IgdGhlIGxhc3Qgd2Vl a3MsIEkgaGF2ZSBiZWVuIHRyYWNraW5nIGEgcmFuZG9tIG1lbW9yeQo+ID4gPiBjb3JydXB0aW9u IGFuZAo+ID4gPiA+ID4gcmVsYXRpdmVseSByYXJlIG9uIFNwYWNlbWlUIEsxIChCYW5hbmEgUGkg RjMgYW5kIE1pbGstVgo+ID4gPiBKdXBpdGVyKS4gSXQgPiA+IHN0YXJ0ZWQgdXBncmFkaW5nIHRv IGdsaWJjIDIuNDMsIHdoaWNoIGRvZXMKPiA+ID4gbWVtc2V0KCkgdGhyb3VnaCB2ZWN0b3IgPiA+ IGluc3RydWN0aW9ucy4gIEl0IGlzIHJlcHJvZHVjaWJsZSB1c2luZwo+ID4gPiB0aGUgRGViaWFu IDcuMS43LTF+YnBvMTMrMSA+ID4ga2VybmVsLCBidXQgSSBoYXZlIGFsc28gYmVlbiBhYmxlIHRv Cj4gPiA+IHJlcHJvZHVjZSBpdCB3aXRoIGEgdmFuaWxsYSA3LjIuMiA+ID4ga2VybmVsLCB1c2lu ZyBhIHNpbWlsYXIKPiA+ID4gY29uZmlndXJhdGlvbiB0byB0aGUgRGViaWFuIGtlcm5lbC4gVGhl IGJvYXJkID4gPiB1c2VzIE9wZW5TQkkgMS45Cj4gPiA+IGFuZCB0aGUgdmVuZG9yIFUtQm9vdC4K PiA+IAo+ID4gSSBoYXZlIGJlZW4gYWJsZSB0byBhbHNvIHJlcHJvZHVjZSB0aGUgaXNzdWUgd2l0 aCB0aGUgdmVuZG9yIE9wZW5TQkkuIEl0Cj4gPiBpcyBhbHNvIHJlcHJvZHVjaWJsZSB3aXRoIGxp bnV4IDcuMi42Lgo+ID4gCj4gPiA+ID4gSSBoYXZlIGJlZW4gYWJsZSB0byBydWxlIG91dCBPcGVu U0JJIGZyb20gdGhlIGlzc3VlLCBJIGhhdmUKPiA+ID4gY2hlY2tlZCA+IHRoZXJlIGlzIG5vdCB0 cmFwIHRvIE9wZW5TQkkgd2hlbiB0aGUgcHJvYmxlbSBoYXBwZW5zLgo+ID4gPiA+ID4gPiBUeXBp Y2FsbHkgaXQgbWFuaWZlc3RzIGl0c2VsZiB3aXRoIHRoZSBmb2xsb3dpbmcga2luZCBvZgo+ID4g PiBlcnJvciwgd2hlbiA+ID4gcnVubmluZyBnKysgZnJvbSBHQ0MgMTYgYXMgcGFydCBvZiBidWls ZGluZyBzb2Z0d2FyZQo+ID4gPiAoZS5nLiBPcGVuSkRLLCA+ID4gQmxlbmRlciwgRG9sZmluLCBR dDYpOiAgID4gPiA+ID4gQXNzZW1ibGVyCj4gPiA+IG1lc3NhZ2VzOgo+ID4gPiA+ID4ge3N0YW5k YXJkIGlucHV0fToyODQ1ODg6IEVycm9yOiB1bmtub3duIHBzZXVkby1vcDogYC51bGViMScKPiA+ ID4gPiA+IHtzdGFuZGFyZCBpbnB1dH06Mjg0NTg4OiBFcnJvcjogdW5yZWNvZ25pemVkIG9wY29k ZSBgw7/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/Dv8O/w7/Dv8O/w7/Dv8O/w7/D v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv3ZsODc0Jwo+ID4gPiA+ ID4gPiA+IFRoZSBicm9rZW4gY2hhcnMgYXJlIDB4ZmYgYW5kIGl0IHNlZW1zIHRoZXJlIGFyZSBh bHdheXMgMjQwCj4gPiA+IChidXQgd2l0aCA+ID4gcG9vciBzdGF0aXN0aWNzKS4gU29tZXRpbWVz IGl0IGluc3RlYWQgY2F1c2VzIGEgR0NDCj4gPiA+IElDRSBpbnN0ZWFkLgo+ID4gPiA+ID4gSSBo YXZlIGlkZW50aWZpZWQgdGhhdCB0aGUgMHhmZiBjb21lcyBmcm9tIHRoZSBwb2lzb25pbmcgZG9u ZQo+ID4gPiBmb3IgdjAgaW4KPiA+ID4gPiBfX3Jpc2N2X3ZfdnN0YXRlX2Rpc2NhcmQoKSwgd2hp Y2ggc2hvdWxkIG9ubHkgaGFwcGVuIGZvciBhCj4gPiA+IHN5c2NhbGwuID4gSW5kZWVkIGNoYW5n aW5nIHRoZSB2YWx1ZSB0byBkaWZmZXJlbnQgb25lcyBwcm9wYWdhdGVzIHRvCj4gPiA+IHRoZSBh Ym92ZSA+IGVycm9yIG1lc3NhZ2UuCj4gPiA+ID4gPiBGdXJ0aGVybW9yZSBJIGhhdmUgZm91bmQg dGhhdCBjaGFuZ2luZwo+ID4gPiBDT05GSUdfUklTQ1ZfSVNBX1ZfUFJFRU1QVElWRSA+IGRvZXNu J3QgY2hhbmdlIGFueXRoaW5nLCBhbmQgdGhhdAo+ID4gPiBjaGFuZ2luZyBSSVNDVl9JU0FfVl9V Q09QWV9USFJFU0hPTEQgPiBjaGFuZ2VzIHRoZSBudW1iZXIgb2YgYnJva2VuCj4gPiA+IGJ5dGVz Lgo+ID4gPiAKPiA+ID4gVGhlIHZhbHVlcyBmcm9tIF9fcmlzY3Zfdl92c3RhdGVfZGlzY2FyZCgp IGVuZC11cCB0aGVyZSBiZWNhdXNlIHRoZXkKPiA+ID4gYXJlIHRoZSBsYXN0IHZhbHVlcyB3cml0 dGVuIHRvIHRoZSB2ZWN0b3IgcmVnaXN0ZXJzLiBJIGhhdmUgYWRkZWQKPiA+ID4gc29tZSBwb2lz b25pbmcgaW4gX19hc21fdmVjdG9yX3VzZXJjb3B5X3N1bV9lbmFibGVkIGJlZm9yZSB0aGUgbG9v cCwKPiA+ID4gYW5kIHRob3NlIHZhbHVlcyBhcHBlYXIgaW5zdGVhZC4gVXNpbmcgZGlmZmVyZW50 IHZhbHVlcyBwZXIgdmVjdG9yCj4gPiA+IHJlZ2lzdGVyLCBJIGhhdmUgZm91bmQgdGhhdCB0aGUg Y29ycnVwdGlvbiBjb21lcyBmcm9tIGEgcGFydGlhbCBsb2FkCj4gPiA+IG9mIHRoZSB2bGU4LnYg aW5zdHJ1Y3Rpb24sIHdoaWxlIHRoZSByZXN1bHQgb2YgdGhlIHBvaXNvbmluZyBhbmQgdGhlCj4g PiA+IHBhcnRpYWwgbG9hZCBhcmUKPiA+ID4gdGhlbiBib3RoIHdyaXR0ZW4gYnkgdGhlIHZzZTgu djoKPiA+ID4gCj4gPiA+ICBsb29wOgo+ID4gPiAgICAgICAgIHZzZXR2bGkgaVZMLCBpTnVtLCBl OCwgRUxFTV9MTVVMX1NFVFRJTkcsIHRhLCBtYQo+ID4gPiAgICAgICAgIGZpeHVwIHZsZTgudiB2 RGF0YSwgKHBTcmMpLCAxMGYKPiA+ID4gICAgICAgICBzdWIgaU51bSwgaU51bSwgaVZMCj4gPiA+ ICAgICAgICAgYWRkIHBTcmMsIHBTcmMsIGlWTAo+ID4gPiAgICAgICAgIGZpeHVwIHZzZTgudiB2 RGF0YSwgKHBEc3QpLCAxMWYKPiA+ID4gICAgICAgICBhZGQgcERzdCwgcERzdCwgaVZMCj4gPiA+ ICAgICAgICAgYm5leiBpTnVtLCBsb29wCj4gPiAKPiA+IEkgaGF2ZSBpbnN0cnVtZW50ZWQgdGhh dCBjb2RlLCBiYXNpY2FsbHkgYWRkaW5nIGEgZnVuY3Rpb24gdG8gY2hlY2sgdGhlCj4gPiBjb3B5 IGFmdGVyd2FyZHMgKG9ubHkgdXNpbmcgc2NhbGFyIGluc3RydWN0aW9ucyksIGFuZCByZXBvcnQg dmFsdWVzIGluCj4gPiBjYXNlIG9mIGVycm9ycy4gU28gZmFyIEkgaGF2ZSBiZWVuIGFibGUgdG8g Y2F0Y2ggdGhlIGlzc3VlIDQgdGltZXMgdGhhdAo+ID4gd2F5IChpbmNsdWRpbmcgb25lIHdoZXJl IEkgaGF2ZW4ndCBzZWVuIGFueSB2aXNpYmxlIGNvbnNlcXVlbmNlIG9uIHRoZQo+ID4gdXNlcmxh bmQpLgo+ID4gCj4gPiBUaGlzIGlzIHdoYXQgSSBvYnNlcnZlZDoKPiA+IC0gVGhlIGlzc3VlIGFs d2F5cyBoYXBwZW5zIGZvciB0aGUgZmlyc3QgYnl0ZXMgb2YgdGhlIHVzZXIgY29weSwgd2hpY2gK PiA+IGluIGFsbCBjYXNlcyB3ZXJlIHN1cHBvc2VkIHRvIGJlIHVwIHRvIDQwOTYgYnl0ZXMgbG9u Zy4KPiA+IC0gT24gdGhlIGZpcnN0IGl0ZXJhdGlvbiBvZiB0aGUgbG9vcCBvbmx5IHRoZSBmaXJz dCAxNiBieXRlcyBhcmUgbG9hZGVkCj4gPiBieSB0aGUgdmxlOC52IGluc3RydWN0aW9uIGJ1dCB0 aGUgZnVsbCAyNTYgYnl0ZXMgYXJlIHdyaXR0ZW4gdG8gdGhlCj4gPiBkZXN0aW5hdGlvbiBieSB0 aGUgdnNlOC52IGluc3RydXRpb24uCj4gCj4gVGhhdCBzb3VuZHMgbGlrZSBzb21lIHNvcnQgb2Yg dHJhcCBoYW5kbGluZyBpc3N1ZTogc29tZXRoaW5nJ3MgZmlsbGluZyBvdXQKPiB0aGUgZmlyc3Qg d29yZCBvZiB0aGUgdmVjdG9yLCBidXQgdGhlbiBub3QgdGhlIHJlc3QsIGJ1dCB0aGVuIG5vdCB0 cmlnZ2VyaW5nCj4gYSByZXN0YXJ0IG9mIHRoZSBpbnN0cnVjdGlvbi4gIFdlIHRhbGtlZCBzb21l IG9uIElSQyBhbmQgaXQgc291bmRzIGxpa2UgdGhhdAoKWWVzLCBpdCdzIHJlYWxseSBsb29rcyBs aWtlIHRoZSBpbnN0cnVjdGlvbiBpcyBpbnRlcnJ1cHRlZCBidXQgbm90IApyZXN0YXJ0ZWQsIGlu c3RlYWQgdGhlIGZvbGxvd2luZyBpbnN0cnVjdGlvbiBpcyBleGVjdXRlZC4KCj4gdHJhcCBpc24n dCBnZXR0aW5nIGludG8gTGludXgsIHNvIGl0J3MgcG9zc2libGUgc29tZXRoaW5nIGluIE0tbW9k ZSBpcwo+IG1hbmdsaW5nIGl0IC0tIHRoaXMgaXMgd2hlcmUgd2Ugc3RhcnQgdG8gZ2V0IGludG8g dnN0YXJ0L2lkZW1wb3RlbnQKCklmIHlvdSBtZWFuIHNiaV9taXNhbGlnbmVkX3ZfbGRfZW11bGF0 b3IoKSBhbmQgCnNiaV9taXNhbGlnbmVkX3Zfc3RfZW11bGF0b3IoKSwgSSBoYXZlIGFscmVhZHkg cnVsZWQgdGhlIG1vdXQuIFRoZXkgYXJlIApub3QgY2FsbGVkIGJlY2F1c2UgYm90aCB1c2VybGFu ZCAoZ2xpYmMgMi40MykgYW5kIGtlcm5lbCAodmVjdG9yIHVzZXIgCmNvcHkpIGFyZSB1c2luZyBl OCwgc28gdGhlcmUgYXJlIG5vIHBvc3NpYmxlIGFsaWdubWVudCBpc3N1ZXMuCgoKPiBpbnN0cnVj dGlvbiB0ZXJyaXRvcnkgYW5kIHRoYXQncyBub3Qgd2VsbCB0ZXN0ZWQgYnkgcnVubmluZyBvbiBR RU1VLCBzbyBpdAo+IHdvdWxkbid0IGJlIHN1cGVyIHN1cnByaXNpbmcgd2UncmUganVzdCBzdHVt YmxpbmcgaW50byBhIGJ1ZyB0aGVyZS4KCkkgZG9uJ3QgdGhpbmsgaXQncyBhIHZzdGFydCBpc3N1 ZS4gSWYgdnN0YXJ0IHdlcmUgd3JvbmdseSByZXN0b3JlZCB0byAwLCAKdGhlIHdob2xlIHZlY3Rv ciB3b3VsZCBiZSBsb2FkZWQgYWdhaW4sIGluZWZmaWNpZW50IGJ1dCBjb3JyZWN0LiBJZiAKdnN0 YXJ0IHdlcmUgcmVzdG9yZWQgdG8gYW5vdGhlciB3cm9uZyB2YWx1ZSwgdGhlIGVuZCBvZiB2ZWN0 b3Igd291bGQgCmFsc28gYmUgbG9hZGVkLCBvdmVycmlkaW5nIHRoZSB2YWx1ZXMgZnJvbSByaXNj dl92X3ZzdGF0ZV9kaXNjYXJkKCkuIFRoZSAKb25seSB2c3RhcnQgY2FzZSB0aGF0IGNvdWxkIGV4 cGxhaW4gdGhhdCBpcyB2c3RhcnQgPj0gdmwsIGJ1dCBJIGRvbid0IAp0aGluayB0aGlzIGlzIGFs bG93ZWQuCgo+IEkgaGF2ZSBhIEszIHRoYXQgSSd2ZSBiZWVuIG1lYW5pbmcgdG8gcGxheSBhcm91 bmQgd2l0aCwgSSdtIGdvaW5nIHRvIGdvIHRyeQo+IHRvIHNlZSBpZiBJIGNhbiBnZXQgaXQgcnVu bmluZyBhbmQgcmVwcm9kdWNlIHRoaXMgb25lLgoKSnVzdCB0byBiZSBjbGVhciwgSSBvbmx5IG9i c2VydmVkIGNvcnJ1cHRpb24gaW4gdGhlIHZlY3RvcmVkIHVzZXIgY29weSAKY29kZSBvbiB0aGUg SzEuIEJ1dCB0aGUgSzMgaXMgYWZmZWN0ZWQgYnkgc2ltaWxhciByYW5kb20gY29ycnVwdGlvbiB0 aGFuIAp0aGUgSzEgdGhhdCBkaXNhcHBlYXIgd2hlbiBkaXNhYmxpbmcgdGhlIHZlY3RvciB1bml0 LiBJIGJlbGlldmUgdGhhdCB0aGUgCmNvcnJ1cHRpb24gaGFwcGVucyBhdCBtdWx0aXBsZSBwbGFj ZXMsIGFuZCB0aGF0IGJ5IGNoYW5jZSBvbiB0aGUgSzEgaXQgCmNhbiBiZSBvYnNlcnZlZCBvbiB0 aGUgdmVjdG9yZWQgdXNlciBjb3B5LgoKVG8gcmVwcm9kdWNlIHRoZSBpc3N1ZSwgSSB1c2Ugb24g YSBEZWJpYW4gaW5zdGFsbGF0aW9uIChvciBvbiB0aGUgCm9yaWdpbmFsIEJpYW5idSBpbnN0YWxs YXRpb24pIHRoZSBmb2xsb3dpbmcgY29tbWFuZHMgaW4gYSBsb29wOgotIHNidWlsZCAtZCBzaWQg YmxlbmRlcgotIHNidWlsZCAtZCBzaWQgLS1idWlsZC1kZXAtcmVzb2x2ZXI9YXB0aXR1ZGUgLS1l eHRyYS1yZXBvc2l0b3J5PSJkZWIgaHR0cDovL2RlYi5kZWJpYW4ub3JnL2RlYmlhbiBleHBlcmlt ZW50YWwgbWFpbiIgLS1hZGQtZGVwZW5kcyAibGliYzYgKD49IDIuNDQpIiBibGVuZGVyCgpUaGUg c2Vjb25kIGNvbW1hbmQgdXNlcyBnbGliYyAyLjQ0LCB3aGljaCB1c2VzIG1vcmUgdmVjdG9yIGlu c3RydWN0aW9ucyAKdmlhIGlmdW5jLCBzbyBpdCBjcmFzaGVzIGZhc3Rlci4gU3RpbGwgaXQgY2Fu IHRha2VzIGEgZmV3IGhvdXJzIHVudGlsIGl0IApoYXBwZW5zLiBPbiB0aGUgSzEgaXQgdGFrZXMg b24gYXZlcmFnZSA1IGhvdXJzLCBzb21ldGltZXMgaXQgdGFrZXMgdXAgdG8gCjE4IGhvdXJzIGJl Zm9yZSBJIGNhbiByZXByb2R1Y2UgdGhlIGlzc3VlLgoKPiA+IC0gT24gdGhlIHNlY29uZCBpdGVy YXRpb24gb2YgdGhlIGxvb3AsIHRoZSB2bGU4LnYgY2F1c2VzIGEgdHJhcCwgd2hpY2gKPiA+IGVu ZHMgdXAgaW4gdGhlIDEwZiBmaXh1cC4gQXQgZml4dXAgbGV2ZWwsIHZsPTB4MTAwLCB2bGVuYj0w eDIwLAo+ID4gdnN0YXJ0PTB4MCBhbmQgdnR5cGU9MHhjMy4KPiA+IC0gQ29uc2lkZXJpbmcgdGhl IDIgZmlyc3QgaXRlcmF0aW9ucyBvZiB0aGUgbG9vcCAoaS5lLiA1MTIgYnl0ZXMpLAo+ID4gbmVp dGhlciB0aGUgc291cmNlIG5vciBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgY3Jvc3MgYSBwYWdlLgo+ ID4gCj4gPiBBbGwgdGhhdCBzYWlkLCBpdCBpcyB3aGF0IEkgY2FuICpvYnNlcnZlKi4gSSBoYXZl IG5vIGlkZWEgaWYgdGhlIGZpcnN0Cj4gPiBpdGVyYXRpb24gb2YgdGhlIGxvb3AgYWxzbyBnb2Vz IHRocm91Z2ggZml4dXAgb3Igbm90LiBBbHNvIGluIGFkZGl0aW9uCj4gPiB0byBwcmVjaXNlIHRy YXBzICh3aGljaCBkZWZpbml0ZWx5IGhhcHBlbiBmb3IgdGhlIHNlY29uZCBpdGVyYXRpb24pLCBJ UlEKPiA+IGNvdWxkIGhhcHBlbiBhdCBhbnkgbW9tZW50LiBJIHVzZSBDT05GSUdfUklTQ1ZfSVNB X1ZfUFJFRU1QVElWRT1uIGZvciBteQo+ID4gdGVzdCwgaW4gb3JkZXIgdG8gbGltaXQgdGhlIGNv ZGUgcGF0aHMgdG8gcmV2aWV3LCBzbyBkdXJpbmcgdGhhdCBjb3B5Cj4gPiBwcmVlbXB0IGlzIGRp c2FibGVkLCBidXQgSVJRIGlzIG5vdC4KCkkgdHJpZWQgZGlzYWJsaW5nIHRoZSBJUlEgYXJvdW5k IHRoZSB2ZWN0b3JlZCB1c2VyIGNvcHksIGJ1dCBpdCBkaWRuJ3QgCmNoYW5nZSBhbnl0aGluZy4K ClJlZ2FyZHMKQXVyZWxpZW4KCi0tIApBdXJlbGllbiBKYXJubyAgICAgICAgICAgICAgICAgICAg ICAgICAgR1BHOiA0MDk2Ui8xREREOEM5QgphdXJlbGllbkBhdXJlbDMyLm5ldCAgICAgICAgICAg ICAgICAgICAgIGh0dHA6Ly9hdXJlbDMyLm5ldAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbGludXgtcmlzY3YgbWFpbGluZyBsaXN0CmxpbnV4LXJpc2N2 QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1yaXNjdgo= 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 BF227305677 for ; Fri, 18 Sep 2026 04:34:47 +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=1789706090; cv=none; b=AjohpNZP/VmjlSsPrkgrgFiryJq6AifmP1pNu/oxp3oMXYpvX1xcuwP424FRPSjO27Sv5LLRCEzijret7J7uBQ2s8nRtP1PyHVlHULbs/CFlupI8yv2rGfIVOhKZYD6vWgeWkKYXOEkhLBQ9/1zLgBzsqgkfbiDL5XCqkb6iAQg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789706090; c=relaxed/simple; bh=pb7QWmmUVRzsDSjLMF/UZX3+6dT+6Z79T5y9CAx2Epg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dXfFXMk/zA94Snlyx8o+lMsW9WXxctymLeS/uGlSmZVOgbP+RzfMpMa5Rl6MPnzQBskyRMNUTyLbYiiExDkv54jF/3mLoF5N5hl1OWY+BZKRRUS7hUe5ehZctPzBeMECCxtSBqMe7RaIxL9Nt8wexr51ozauT3fFrdnVYmM+9fY= 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=fj9R5EdL; 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="fj9R5EdL" 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=jMZYBazdiY2OeMs68QlA4oobhnvN+ZgUafNXD/I6otg=; b=fj9R5EdLsTSC7vDyLbknhfrWhx TYSuDHkJ0zhMkv42+uoJbMoQJ6HNs+bOgCDeGR3q0rlDeXM18esdjSVA4Or54LF6RKweO4MWPjtk7 0GxsoYi85Thwf7GSFaosz+oewsOMeoT27hrJtI0enVBcyE8yLtbcz5u9s8W/dsdTSE9bbx/B2qkjI 2B/u8nhq1d7+QPCXX26rAaGWDrPntCT1bFC/8H93wiZYXKvmJNifcSsW3Qr99ov6psDHWz4swjf8w kf45nag0/oZkGSZ5FuPZCe2vGuMgaROSZ8dPfQeld0sLsm6bSiwz245F6d1UJkvHNZ1+Dggg9bNMB 2Lq3KVQw==; 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 1x7QJ5-00000000BUn-2F7u; Fri, 18 Sep 2026 06:34:39 +0200 Date: Fri, 18 Sep 2026 06:34:39 +0200 From: Aurelien Jarno To: Palmer Dabbelt Cc: spacemit@lists.linux.dev, linux-riscv@lists.infradead.org, tchiu@tenstorrent.com, kmehltretter@gmail.com 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 Palmer, Thanks for your answer. On 2026-09-17 12:18, Palmer Dabbelt wrote: > On Tue, 15 Sep 2026 14:14:10 PDT (-0700), aurelien@aurel32.net wrote: > > Hi, > >=20 > > Some more update, even if the progress is quite low. >=20 > Well, thanks for digging into this. >=20 > >=20 > > On 2026-09-09 18:45, Aurelien Jarno wrote: > > > [Added Andy and Karl in Cc: as they have been involved in the > > > vectored 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, > > > > > I have done some small progress on that issue. Help is still > > > wanted and > would be appreciated. > > > > > On 2026-08-30 22:52, Aurelien Jarno wrote: > > > > > Dear all, > > > > > > > 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). It > > started upgrading to glibc 2.43, which does > > > memset() through vector > > instructions. It is reproducible using > > > the Debian 7.1.7-1~bpo13+1 > > kernel, but I have also been able to > > > reproduce it with a vanilla 7.2.2 > > kernel, using a similar > > > configuration to the Debian kernel. The board > > uses OpenSBI 1.9 > > > and the vendor U-Boot. > >=20 > > I have been able to also reproduce the issue with the vendor OpenSBI. It > > is also reproducible with linux 7.2.6. > >=20 > > > > I have been able to rule out OpenSBI from the issue, I have > > > checked > there is not trap to OpenSBI when the problem happens. > > > > > > Typically it manifests itself with the following kind of > > > error, when > > running g++ from GCC 16 as part of building software > > > (e.g. OpenJDK, > > Blender, Dolfin, Qt6): > > > > 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' > > > > > > > The broken chars are 0xff and it seems there are always 240 > > > (but with > > poor statistics). Sometimes it instead causes a GCC > > > ICE instead. > > > > > 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. > Indeed changing the value to different ones propagates to > > > the above > error message. > > > > > Furthermore I have found that changing > > > CONFIG_RISCV_ISA_V_PREEMPTIVE > doesn't change anything, and that > > > changing RISCV_ISA_V_UCOPY_THRESHOLD > changes the number of broken > > > bytes. > > >=20 > > > The values from __riscv_v_vstate_discard() end-up there because they > > > are the last values written to the vector registers. I have added > > > some poisoning in __asm_vector_usercopy_sum_enabled before the loop, > > > and those values appear instead. Using different values per vector > > > register, I have found that the corruption comes from a partial load > > > of the vle8.v instruction, while the result of the poisoning and the > > > partial load are > > > then both written by the vse8.v: > > >=20 > > > loop: > > > vsetvli iVL, iNum, e8, ELEM_LMUL_SETTING, ta, ma > > > fixup vle8.v vData, (pSrc), 10f > > > sub iNum, iNum, iVL > > > add pSrc, pSrc, iVL > > > fixup vse8.v vData, (pDst), 11f > > > add pDst, pDst, iVL > > > bnez iNum, loop > >=20 > > I have instrumented that code, basically adding a function to check the > > copy afterwards (only using scalar instructions), and report values in > > case of errors. So far I have been able to catch the issue 4 times that > > way (including one where I haven't seen any visible consequence on the > > userland). > >=20 > > This is what I observed: > > - The issue always happens for the first bytes of the user copy, which > > in all cases were supposed to be up to 4096 bytes long. > > - On the first iteration of the loop only the first 16 bytes are loaded > > by the vle8.v instruction but the full 256 bytes are written to the > > destination by the vse8.v instrution. >=20 > That sounds like some sort of trap handling issue: something's filling out > the first word of the vector, but then not the rest, but then not trigger= ing > a restart of the instruction. We talked some on IRC and it sounds like t= hat Yes, it's really looks like the instruction is interrupted but not=20 restarted, instead the following instruction is executed. > trap isn't getting into Linux, so it's possible something in M-mode is > mangling it -- this is where we start to get into vstart/idempotent If you mean sbi_misaligned_v_ld_emulator() and=20 sbi_misaligned_v_st_emulator(), I have already ruled the mout. They are=20 not called because both userland (glibc 2.43) and kernel (vector user=20 copy) are using e8, so there are no possible alignment issues. > instruction territory and that's not well tested by running on QEMU, so it > wouldn't be super surprising we're just stumbling into a bug there. I don't think it's a vstart issue. If vstart were wrongly restored to 0,=20 the whole vector would be loaded again, inefficient but correct. If=20 vstart were restored to another wrong value, the end of vector would=20 also be loaded, overriding the values from riscv_v_vstate_discard(). The=20 only vstart case that could explain that is vstart >=3D vl, but I don't=20 think this is allowed. > I have a K3 that I've been meaning to play around with, I'm going to go t= ry > to see if I can get it running and reproduce this one. Just to be clear, I only observed corruption in the vectored user copy=20 code on the K1. But the K3 is affected by similar random corruption than=20 the K1 that disappear when disabling the vector unit. I believe that the=20 corruption happens at multiple places, and that by chance on the K1 it=20 can be observed on the vectored user copy. To reproduce the issue, I use on a Debian installation (or on the=20 original Bianbu installation) the following commands in a loop: - sbuild -d sid blender - sbuild -d sid --build-dep-resolver=3Daptitude --extra-repository=3D"deb h= ttp://deb.debian.org/debian experimental main" --add-depends "libc6 (>=3D 2= =2E44)" blender The second command uses glibc 2.44, which uses more vector instructions=20 via ifunc, so it crashes faster. Still it can takes a few hours until it=20 happens. On the K1 it takes on average 5 hours, sometimes it takes up to=20 18 hours before I can reproduce the issue. > > - On the second iteration of the loop, the vle8.v causes a trap, which > > ends up in the 10f fixup. At fixup level, vl=3D0x100, vlenb=3D0x20, > > vstart=3D0x0 and vtype=3D0xc3. > > - Considering the 2 first iterations of the loop (i.e. 512 bytes), > > neither the source nor destination addresses cross a page. > >=20 > > All that said, it is what I can *observe*. I have no idea if the first > > iteration of the loop also goes through fixup or not. Also in addition > > to precise traps (which definitely happen for the second iteration), IRQ > > could happen at any moment. I use CONFIG_RISCV_ISA_V_PREEMPTIVE=3Dn for= my > > test, in order to limit the code paths to review, so during that copy > > preempt is disabled, but IRQ is not. I tried disabling the IRQ around the vectored user copy, but it didn't=20 change anything. Regards Aurelien --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net