From owner-freebsd-ppc@freebsd.org Sun Mar 24 19:10:17 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C34B153324E for ; Sun, 24 Mar 2019 19:10:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AF96C926CB for ; Sun, 24 Mar 2019 19:10:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7074F153324C; Sun, 24 Mar 2019 19:10:16 +0000 (UTC) Delivered-To: ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C7EF153324A for ; Sun, 24 Mar 2019 19:10:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB840926C4 for ; Sun, 24 Mar 2019 19:10:15 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2F72710731 for ; Sun, 24 Mar 2019 19:10:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2OJAFC8074953 for ; Sun, 24 Mar 2019 19:10:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2OJAFDT074951 for ppc@FreeBSD.org; Sun, 24 Mar 2019 19:10:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Sun, 24 Mar 2019 19:10:14 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 19:10:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #6 from Mark Millard --- (In reply to Dennis Clarke from comment #5) The following notes are currently based on variations on head -r335044 . It has usefdt=3D1 enabled always (by changing the code) but does not have smp disabled (even manually). The context does not involve reverting the newer kernel maximum figure that I used to revert. I have a hack that avoid the fans problem on the 2-socket/2cores-each G5 that I currently have access to. It also avoids problems with other processes that also get stuck waiting for sleep. But it is a hack that is not even approximately a general/proper solution to the original problem, it just avoids the consequences. The hack involves an experimentally found approximate bound that it tests against. That bound might vary for related G5 contexts. I've another hack that makes it rare that booting gets hung up: it narrows a race condition's time frame. But I've have observed a few examples of hang-up out of hundreds of boots. The hack basically proves what is going on for the hang-ups based on the large change of behavior for narrowing the race-condition's time frame. There is a patch-review active for llvm's libunwind that makes it handle r2 (the TOC register) correctly for powerpc64 both for system-clang based buildworld's and devel/powerpc64-gcc based buildworld's, both ELFv1 ABI and ELFv2 ABI. This makes thrown C++ exceptions work. (This does not cover WITH_LIB32=3D for exception handling when WITH_LLVM_LIBUNWIND=3D is in use in the buildworld.) --=20 You are receiving this mail because: You are the assignee for the bug.=