On 04.02.17 20:54, Jason Harmening wrote:
I suspect this broke rmlocks for mips because the rmlock implementation
takes the address of the per-CPU pc_rm_queue when building tracker
lists. That address may be later accessed from another CPU and will
then translate to the wrong physical region if the address was taken
relative to the globally-constant pcpup VA used on mips.
Regardless, for mips get_pcpup() should be implemented as
pcpu_find(curcpu) since returning an address that may mean something
different depending on the CPU seems like a big POLA violation if
nothing else.
I'm more concerned about the report of powerpc breakage. For powerpc we
simply take each pcpu pointer from the pc_allcpu list (which is the same
value stored in the cpuid_to_pcpu array) and pass it through the ap_pcpu
global to each AP's startup code, which then stores it in sprg0. It
should be globally unique and won't have the variable-translation issues
seen on mips. Andreas, are you certain this change was responsible the
breakage you saw, and was it the same sort of hang observed on mips?
I'm really sure. 313036 booted fine, allowed me to execute heavy
compilation jobs, np. 313037 on the other side gave me various patterns
of panics. During startup, but I also succeeded to get into multiuser
and then the panic happend during port building.
I have no deeper inside where pcpu data is used. Justin mentioned netisr?
Andreas
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
