From owner-freebsd-bugs@freebsd.org Tue Jul 25 23:10:45 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31CA3DA9F18 for ; Tue, 25 Jul 2017 23:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEF56AE93 for ; Tue, 25 Jul 2017 23:10:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v6PNAiXM008992 for ; Tue, 25 Jul 2017 23:10:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen... Date: Tue, 25 Jul 2017 23:10:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: truckman@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 23:10:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219399 --- Comment #134 from Don Lewis --- (In reply to Don Lewis from comment #124) The AMD documentation that I've found is pretty much silent about cross-modifying code. My interpretation of the pseudo-code that I found in= the Intel documentation is that nothing other than the lock followed by CPUID is necessary. They don't mention anything about the need for fence instructio= ns. Is this a Ryzen bug? Yes, it looks like one to me. Do I care, probably no= t.=20 I don't need to run contrived cross-modifying code. I don't think this aff= ects FreeBSD. I suspect that anyplace that we do something like this there is likely be some code that changes the page permissions to remove write access and adds execute access between where the code is written and where it is executed. That is probably sufficient distance to flush out the inconsiste= nt state from the CPU before it tries to execute the code. If this was not the case, I would expect that FreeBSD would hardly run at all on Ryzen. In any case, I think there is a software workaround. Just do a read access= of the newly written instructions before the CPUID. Maybe a fence instruction= is needed as well. I'm surprised that this problem seems to be worse with SMT. I would think = that cross-modifying between threads on the same core would be the best case and running on cores belonging to different CCXes would be the worst case ... --=20 You are receiving this mail because: You are the assignee for the bug.=