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 7F9A3C79F9E for ; Tue, 8 Sep 2026 04:42:36 +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=hJLeCMdqd6TSEDK9WG0cSqnRlBzGjW40fDYzbVzdnDo=; b=SIi7CmEranjI4E Fqod1D16ro/9aOeLyXyRxRXJxbTL2SKKhQyO+WxAaCRZlIxCFAgPSxGCxJpYPgI/NWXBw/Qk6ScQa LJez5XoBAm/f82WnqCV/PLmf/7bYrTD4kC1VBBk06ps7K1ZgSyNsA6Vf/FWKX3yQNxUNcyqfwmBQg paHwu+x9/fOEYJxUR4bLjLJVQx5L4FFxUaflCXZIXvSrBzpXaiAtm2/PE6ShfBE0CceXSVf984MCS OSFqScky/S+PMuryEaHdKySO6K9YcImPDb1jkdUted3Xo8uMiDo+H4bzePB/uPNPHto2FI3RPztPF pSJrq0vkrTX+21q/bzCQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3nf2-000000081vr-44yr; Tue, 08 Sep 2026 04:42:20 +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 1x3nf0-000000081us-0p7P for linux-riscv@lists.infradead.org; Tue, 08 Sep 2026 04:42:19 +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=pJTC0xXNuB6/FR3SFnQD89wasUY2SzDpeY/IZfDA5kY=; b=drlqnM6MJd1QipihzHmVJOJRhK RGMPHGb7pK+htvEo71E5ODyA2DmlsQ6c4159CLGxIKE1pzapMO6MQcUieiavXiZ+S6tSK6xKnOMxE Sz+NC/zU/a3NdoNDHrb+3p4EGW7Tx/85zkHWb5TIyyMEDrnplXrF9e3b09qPCSZkg43FSBEWjax8G baHMDvzObQiP/tVxB9+JbR6M8+YECbHgRMLUREkv0Z6vVqzXslvhLFVAv08h0zws8M26wg4C8OAFG ECnSvQdyA8Ld7qzVpSTCNxKIsT35avz0BbFjJix6hhVTHrTcHKFWHEj6IPdhGIu0AsQZXAFV43xAP CTw/HkJg==; 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 1x3nes-0000000423P-0ynJ; Tue, 08 Sep 2026 06:42:10 +0200 Date: Tue, 8 Sep 2026 06:42:09 +0200 From: Aurelien Jarno To: spacemit@lists.linux.dev Cc: linux-riscv@lists.infradead.org Subject: Re: Random corruption on SpacemiT K1 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-20260907_214218_246039_D9DA4325 X-CRM114-Status: GOOD ( 30.56 ) 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 RGVhciBhbGwsCgpJIGhhdmUgZG9uZSBzb21lIHNtYWxsIHByb2dyZXNzIG9uIHRoYXQgaXNzdWUu IEhlbHAgaXMgc3RpbGwgd2FudGVkIGFuZCAKd291bGQgYmUgYXBwcmVjaWF0ZWQuCgpPbiAyMDI2 LTA4LTMwIDIyOjUyLCBBdXJlbGllbiBKYXJubyB3cm90ZToKPiBEZWFyIGFsbCwKPiAKPiBGb3Ig dGhlIGxhc3Qgd2Vla3MsIEkgaGF2ZSBiZWVuIHRyYWNraW5nIGEgcmFuZG9tIG1lbW9yeSBjb3Jy dXB0aW9uIGFuZAo+IHJlbGF0aXZlbHkgcmFyZSBvbiBTcGFjZW1pVCBLMSAoQmFuYW5hIFBpIEYz IGFuZCBNaWxrLVYgSnVwaXRlcikuIEl0IAo+IHN0YXJ0ZWQgdXBncmFkaW5nIHRvIGdsaWJjIDIu NDMsIHdoaWNoIGRvZXMgbWVtc2V0KCkgdGhyb3VnaCB2ZWN0b3IgCj4gaW5zdHJ1Y3Rpb25zLiAg SXQgaXMgcmVwcm9kdWNpYmxlIHVzaW5nIHRoZSBEZWJpYW4gNy4xLjctMX5icG8xMysxIAo+IGtl cm5lbCwgYnV0IEkgaGF2ZSBhbHNvIGJlZW4gYWJsZSB0byByZXByb2R1Y2UgaXQgd2l0aCBhIHZh bmlsbGEgNy4yLjIgCj4ga2VybmVsLCB1c2luZyBhIHNpbWlsYXIgY29uZmlndXJhdGlvbiB0byB0 aGUgRGViaWFuIGtlcm5lbC4gVGhlIGJvYXJkIAo+IHVzZXMgT3BlblNCSSAxLjkgYW5kIHRoZSB2 ZW5kb3IgVS1Cb290LgoKSSBoYXZlIGJlZW4gYWJsZSB0byBydWxlIG91dCBPcGVuU0JJIGZyb20g dGhlIGlzc3VlLCBJIGhhdmUgY2hlY2tlZCAKdGhlcmUgaXMgbm90IHRyYXAgdG9wIE9wZW5TQkkg d2hlbiB0aGUgcHJvYmxlbSBoYXBwZW5zLgoKPiBUeXBpY2FsbHkgaXQgbWFuaWZlc3RzIGl0c2Vs ZiB3aXRoIHRoZSBmb2xsb3dpbmcga2luZCBvZiBlcnJvciwgd2hlbiAKPiBydW5uaW5nIGcrKyBm cm9tIEdDQyAxNiBhcyBwYXJ0IG9mIGJ1aWxkaW5nIHNvZnR3YXJlIChlLmcuIE9wZW5KREssIAo+ IEJsZW5kZXIsIERvbGZpbiwgUXQ2KTogICAKPiAKPiBBc3NlbWJsZXIgbWVzc2FnZXM6Cj4ge3N0 YW5kYXJkIGlucHV0fToyODQ1ODg6IEVycm9yOiB1bmtub3duIHBzZXVkby1vcDogYC51bGViMScK PiB7c3RhbmRhcmQgaW5wdXR9OjI4NDU4ODogRXJyb3I6IHVucmVjb2duaXplZCBvcGNvZGUgYMO/ 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/w792bDg3NCcKPiAKPiBUaGUgYnJv a2VuIGNoYXJzIGFyZSAweGZmIGFuZCBpdCBzZWVtcyB0aGVyZSBhcmUgYWx3YXlzIDI0MCAoYnV0 IHdpdGggCj4gcG9vciBzdGF0aXN0aWNzKS4gU29tZXRpbWVzIGl0IGluc3RlYWQgY2F1c2VzIGEg R0NDIElDRSBpbnN0ZWFkLgoKSSBoYXZlIGlkZW50aWZpZWQgdGhhdCB0aGUgMHhmZiBjb21lcyBm cm9tIHRoZSBwb2lzb25pbmcgZG9uZSBmb3IgdjAgaW4KX19yaXNjdl92X3ZzdGF0ZV9kaXNjYXJk KCksIHdoaWNoIHNob3VsZCBvbmx5IGhhcHBlbiBmb3IgYSBzeXNjYWxsLiAKSW5kZWVkIGNoYW5n aW5nIHRoZSB2YWx1ZSB0byBkaWZmZXJlbnQgb25lcyBwcm9wYWdhdGVzIHRvIHRoZSBhYm92ZSAK ZXJyb3IgbWVzc2FnZS4KCkZ1cnRoZXJtb3JlIEkgaGF2ZSBmb3VuZCB0aGF0IGNoYW5naW5nIENP TkZJR19SSVNDVl9JU0FfVl9QUkVFTVBUSVZFIApkb2Vzbid0IGNoYW5nZSBhbnl0aGluZywgYW5k IHRoYXQgY2hhbmdpbmcgUklTQ1ZfSVNBX1ZfVUNPUFlfVEhSRVNIT0xEIApjaGFuZ2VzIHRoZSBu dW1iZXIgb2YgYnJva2VuIGJ5dGVzLgoKRGlzYWJsaW5nIHRoZSB2ZWN0b3JlZCB1c2VyIGNvZGUg ZW50aXJlbHkgd2l0aCB0aGUgZm9sbG93aW5nIHBhdGNoIHNlZW1zCnRvIHByZXZlbnQgdGhlIGlz c3VlIChvciBtYWtlIGl0IHN1ZmZpY2llbnRseSByYXJlIHRoYXQgSSBoYXZlIG5vdCAKZW5jb3Vu dGVyZWQgaXQpOgoKLS0tIGEvYXJjaC9yaXNjdi9saWIvcmlzY3Zfdl9oZWxwZXJzLmMKKysrIGIv YXJjaC9yaXNjdi9saWIvcmlzY3Zfdl9oZWxwZXJzLmMKQEAgLTI1LDcgKzI1LDcgQEAgYXNtbGlu a2FnZSBpbnQgZW50ZXJfdmVjdG9yX3VzZXJjb3B5KHZvaWQgKmRzdCwgdm9pZCAqc3JjLCBzaXpl X3QgbiwKICAgICAgICBzaXplX3QgcmVtYWluLCBjb3BpZWQ7CiAKICAgICAgICAvKiBza2lwIGhh c192ZWN0b3IoKSBjaGVjayBiZWNhdXNlIGl0IGhhcyBiZWVuIGRvbmUgYnkgdGhlIGFzbSAgKi8K LSAgICAgICBpZiAoIW1heV91c2Vfc2ltZCgpKQorICAgICAgIGlmICghbWF5X3VzZV9zaW1kKCkg fHwgdHJ1ZSkKICAgICAgICAgICAgICAgIGdvdG8gZmFsbGJhY2s7CiAKICAgICAgICBrZXJuZWxf dmVjdG9yX2JlZ2luKCk7CgpPdmVyYWxsLCB3aGlsZSB0aGUgY29ycnVwdGlvbiBoYXBwZW5zIHJh bmRvbWx5LCB0aGUgY29ycnVwdGlvbiBpdHNlbGYgCnNlZW1zIHRvIGJlIGRldGVybWluaXN0aWMs IGFuZCB0aGUgZGF0YSBzb3VyY2Ugb2YgdGhlIGNvcnJ1cHRpb24gaXMgCmlkZW50aWZpZWQuIEJ1 dCBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRob3NlIHZhbHVlcyBwcm9wYWdhdGUgdG8gdXNlciAK c3BhY2UuIEl0IGlzIG5vdCBjbGVhciB0byBtZSBpZiBpdCBpcyBhIGJ1ZyBzb21ld2hlcmUgaW4g dGhlIGNvbnRleHQgCnN3aXRjaGluZyBjb2RlLCBvciBhIGJ1ZyBpbiBfX2FzbV92ZWN0b3JfdXNl cmNvcHlfc3VtX2VuYWJsZWQgZml4dXAgCmNvZGUsIHdpdGggdGhlIHZhbHVlcyBqdXN0IGJlaW5n IHRoZSBvbmUgYXQgdGhlIGVudHJ5IG9mIHRoZSBmdW5jdGlvbi4KQWxzbyBJIGNhbid0IGNvbXBs ZXRlbHkgcnVsZSBvdXQgYSBDUFUgYnVnLgoKPiBVc2luZyBnbGliYyAyLjQ0IGluc3RlYWQgb2Yg Z2xpYmMgMi40Mywgd2hpY2ggZG9lcyBhIGxvdCBvZiBzdHJpbmcgCj4gb3BlcmF0aW9ucyB0aHJv dWdoIHZlY3RvciBpbnN0cnVjdGlvbnMsIGluY3JlYXNlcyB0aGUgcHJvYmFiaWxpdHkgdG8gCj4g aGF2ZSBjb3JydXB0aW9uLCBtYWtlcyBpdCBhIGJpdCBtb3JlIHJlcHJvZHVjaWJsZSwgYnV0IGl0 IGFsd2F5cyBzZWVtcyAKPiB0byBtYW5pZmVzdCBhcyBhIEdDQyBJQ0UuIEl0IHR5cGljYWxseSBo YXBwZW5zIHdpdGhpbmcgb25lIGhvdXIgd2hlbiAKPiBydW5uaW5nIG9uIHRoZSA4IGNvcmVzIGlu c3RlYWQgb2YgZXZlcnkgMSBvciAyIGRheXMuIEZyb20gdGhlcmUgSSBoYXZlIAo+IGJlZW4gYWJs ZSB0byBkZXRlcm1pbmUgdGhlIGZvbGxvd2luZyB0aGluZ3M6CgpJIGhhdmUgc3RvcHBlZCB1c2lu ZyBnbGliYyAyLjQ0IGFzIGEgcmVwcm9kdWNlciwgYW5kIGl0IGdlbmVyYXRlIApkaWZmZXJlbnQg dHlwZSBvZiBjcmFzaGVzLCBhbmQgdGhlcmUgY291bGQgYmUgYW5vdGhlciBzZXQgb2YgYnVncyBv biB0b3AgCm9mIHRoZSBvbmUgSSBhbSB0cnlpbmcgdG8gaWRlbnRpZnkuIFRoaXMgaG93ZXZlciBt ZWFucyBpdCB0YWtlcyBhIGxvdCBvZiAKdGltZSB0byB0ZXN0IGFueSBjaGFuZ2UuCiAKPiAtIERp c2FibGluZyB2ZWN0b3IgaW5zdHJ1Y3Rpb25zIChieSBwYXRjaGluZyB0aGUgRFRCIHRvIHJlbW92 ZSAidiIsIAo+ICAgInp2aGYiIGFuZCAienZ0ayIpIGZpeGVzIHRoZSBpc3N1ZQo+IAo+IC0gRGlz YWJsaW5nIFRIUCAoYnkgc2V0dGluZyAvc3lzL2tlcm5lbC9tbS90cmFuc3BhcmVudF9odWdlcGFn ZS9lbmFibGVkIAo+ICAgdG8gbmV2ZXIgaW5zdGVhZCBvZiBhbHdheXMpIGFsc28gc2VlbXMgdG8g Zml4IHRoZSBpc3N1ZS4gS2VlcGluZyBpdCAKPiAgIGVuYWJsZWQgd2l0aCBkZWZyYWc9bmV2ZXIg b3IgdXNlX3plcm9fcGFnZT0wIGRvZXNuJ3QgY2hhbmdlIGFueXRoaW5nLgoKSSBkb24ndCB0aGlu ayB0aGlzIGlzIGEgZ29vZCBkaXJlY3Rpb24sIG15IGltcHJlc3Npb24gaXMgdGhhdCBpdCBqdXN0 IApjaGFuZ2VzIHRpbWluZyBhIGJpdCwgd2hpY2gganVzdCBoaWRlIHRoZSBpc3N1ZSwgb3IgcmVx dWlyZSBkaWZmZXJlbnQgCmNvbmRpdGlvbiB0byB0cmlnZ2VyIGl0LgoKUmVnYXJkcwpBdXJlbGll biAKCi0tIApBdXJlbGllbiBKYXJubyAgICAgICAgICAgICAgICAgICAgICAgICAgR1BHOiA0MDk2 Ui8xREREOEM5QgphdXJlbGllbkBhdXJlbDMyLm5ldCAgICAgICAgICAgICAgICAgICAgIGh0dHA6 Ly9hdXJlbDMyLm5ldAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbGludXgtcmlzY3YgbWFpbGluZyBsaXN0CmxpbnV4LXJpc2N2QGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1y aXNjdgo= 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 5534619F115 for ; Tue, 8 Sep 2026 04:42:18 +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=1788842540; cv=none; b=F+QLV+lftKM15V8u80zNDJpieMffH0gITD8YzWvVYnwX8FWH2KJ62RFBtaRtGoATfWgzVW+SBDFUoGoOpfNJWAX5zMQ1LnOQmeBDNaHC3PHaft6lXvOnxv1Xe2YoTLdfD3Fo92fjGpAoNWZ+Oq0hYW+xO8i05jYBRXqDaSicFRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788842540; c=relaxed/simple; bh=x6kQx25IJwgp05TqroMqPHrWpz0ht9yREBOZISt2VuQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tJ4UAR+X3oWcFF8df8g5RaQvyX9thjr201ClYFhCYD5sc7w2NQ+YwExCNRii6K3uInEl0XBDyRD5AGwVRy+2ypx/KpnCd7JGn/4+Yc93+PiD97+itcUY4aHK8VTz+rQhukV6Az4QcmGpdtxckfCcTNKIENYYiknIjdjVQHfpBeE= 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=drlqnM6M; 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="drlqnM6M" 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=pJTC0xXNuB6/FR3SFnQD89wasUY2SzDpeY/IZfDA5kY=; b=drlqnM6MJd1QipihzHmVJOJRhK RGMPHGb7pK+htvEo71E5ODyA2DmlsQ6c4159CLGxIKE1pzapMO6MQcUieiavXiZ+S6tSK6xKnOMxE Sz+NC/zU/a3NdoNDHrb+3p4EGW7Tx/85zkHWb5TIyyMEDrnplXrF9e3b09qPCSZkg43FSBEWjax8G baHMDvzObQiP/tVxB9+JbR6M8+YECbHgRMLUREkv0Z6vVqzXslvhLFVAv08h0zws8M26wg4C8OAFG ECnSvQdyA8Ld7qzVpSTCNxKIsT35avz0BbFjJix6hhVTHrTcHKFWHEj6IPdhGIu0AsQZXAFV43xAP CTw/HkJg==; 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 1x3nes-0000000423P-0ynJ; Tue, 08 Sep 2026 06:42:10 +0200 Date: Tue, 8 Sep 2026 06:42:09 +0200 From: Aurelien Jarno To: spacemit@lists.linux.dev Cc: linux-riscv@lists.infradead.org Subject: Re: Random corruption on SpacemiT K1 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) Dear all, I have done some small progress on that issue. Help is still wanted and=20 would be appreciated. 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). It=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 board=20 > uses OpenSBI 1.9 and the vendor U-Boot. 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. > Typically it manifests itself with the following kind of error, when=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 with=20 > 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.=20 Indeed changing the value to different ones propagates to the above=20 error message. Furthermore I have found that changing CONFIG_RISCV_ISA_V_PREEMPTIVE=20 doesn't change anything, and that changing RISCV_ISA_V_UCOPY_THRESHOLD=20 changes the number of broken bytes. Disabling the vectored user code entirely with the following patch seems to prevent the issue (or make it sufficiently rare that I have not=20 encountered it): --- a/arch/riscv/lib/riscv_v_helpers.c +++ b/arch/riscv/lib/riscv_v_helpers.c @@ -25,7 +25,7 @@ asmlinkage int enter_vector_usercopy(void *dst, void *src= , size_t n, size_t remain, copied; =20 /* skip has_vector() check because it has been done by the asm */ - if (!may_use_simd()) + if (!may_use_simd() || true) goto fallback; =20 kernel_vector_begin(); Overall, while the corruption happens randomly, the corruption itself=20 seems to be deterministic, and the data source of the corruption is=20 identified. But I don't understand how those values propagate to user=20 space. It is not clear to me if it is a bug somewhere in the context=20 switching code, or a bug in __asm_vector_usercopy_sum_enabled fixup=20 code, with the values just being the one at the entry of the function. Also I can't completely rule out a CPU bug. > Using glibc 2.44 instead of glibc 2.43, which does a lot of string=20 > operations through vector instructions, increases the probability to=20 > have corruption, makes it a bit more reproducible, but it always seems=20 > to manifest as a GCC ICE. It typically happens withing one hour when=20 > running on the 8 cores instead of every 1 or 2 days. From there I have=20 > been able to determine the following things: I have stopped using glibc 2.44 as a reproducer, and it generate=20 different type of crashes, and there could be another set of bugs on top=20 of the one I am trying to identify. This however means it takes a lot of=20 time to test any change. =20 > - Disabling vector instructions (by patching the DTB to remove "v",=20 > "zvhf" and "zvtk") fixes the issue >=20 > - Disabling THP (by setting /sys/kernel/mm/transparent_hugepage/enabled= =20 > to never instead of always) also seems to fix the issue. Keeping it=20 > enabled with defrag=3Dnever or use_zero_page=3D0 doesn't change anythin= g. I don't think this is a good direction, my impression is that it just=20 changes timing a bit, which just hide the issue, or require different=20 condition to trigger it. Regards Aurelien=20 --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net