[Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Apr 20 03:06:31 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863

--- Comment #17 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
Created attachment 203812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203812&action=edit
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.

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


More information about the freebsd-ppc mailing list