Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Apr 2019 03:06:28 +0000
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
Message-ID:  <bug-233863-21-Rugtzxf3LS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References:  <bug-233863-21@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863

--- Comment #17 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
Created attachment 203812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203812&action=
=3Dedit
Investigatory sys/powerpc/powerpc/mp_machdep.c patch to avoid stuck-sleeping
problem

So far in preliminary testing on the PowerMac11,2, avoiding
the hardware priority change from "or 31,31,31" use when looping
to find ap_letgo changed has avoided my hack reporting any cases
of applying the workaround. (Nor does the code now do a
"or 6,6,6" to put back the orginal hardware priority.)

I changed things to be more like sequentially consistent handling
and made the bsp slightly more like the APs in hopes of getting
more similar timing to when platform_smp_timebase_sync happens.

I changed code in machdep_ap_bootstrap and in cpu_mp_unleash .

I've also tested a 2-socket/1-core-each 970 G5 PowerMac11,2 a
little. It still booted fine and still has never reported the
workaround ever having to been applied. I will build 32-bit
powerpc FreeBSD and try it as well, including on a
2-socket/1-core-each 7455 G4 PowerMac3,6.

I'm actually not surprised that only the multi-core context
actually behaves differently for "or 31,31,31" use (setting
lowest priority mode): I do not see that being something that
happens across sockets but only more locally.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233863-21-Rugtzxf3LS>