Date: Sun, 22 Mar 2009 10:33:10 +0000 (UTC) From: Marius Strobl <marius@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/sparc64/include smp.h src/sys/sparc64/sparc64 genassym.c mp_machdep.c Message-ID: <200903221033.n2MAXGwo002750@repoman.freebsd.org>
index | next in thread | raw e-mail
marius 2009-03-22 10:33:10 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_7)
sys/sparc64/include smp.h
sys/sparc64/sparc64 genassym.c mp_machdep.c
Log:
SVN rev 190257 on 2009-03-22 10:33:10Z by marius
MFC: r183142, r186395, 190106
- Newer firmware versions no longer provide SUNW,stop-self so just
disable interrupts and loop forever instead. We still could use
SUNW,stop-self if implemented but acording to comments in OpenBSD,
E{2,4}50 tend to have fragile firmware versions which wedge when
using the OFW test service, so given that we don't really depend
on SUNW,stop-self just nuke it altogether instead of risking
problems.
- Hide all MP-related bits in <machine/smp.h> underneath #ifdef SMP.
- Inline ipi_all_but_self(9) and ipi_selected(9). We don't expose any
additional bits but save a few cycles by doing so.
- Remove ipi_all(9), which actually only called panic(9). It can't be
implemented natively anyway and having it removed at least causes
MI users to already fail when linking.
- At least Fire V880 have a small hardware glitch which causes the
reception of IDR_NACKs for CPUs we actually haven't tried to send
an IPI to, even not as part of the initial try. According to tests
this apparently can be safely ignored though, so just return if
checking for the individual IDR_NACKs indicates no outstanding
dispatch. Serializing the sending of IPIs between MD and MI code
by the combined usage of smp_ipi_mtx makes no difference to this
phenomenon. [1]
- Provide relevant debugging bits already with the initial panic
in case of problems with the IPI dispatch, which would have
allowed to diagnose the above problem without a specially built
kernel.
- In case of cheetah_ipi_selected() base the delay we wait for
other CPUs which also might want to dispatch IPIs on the total
amount of CPUs instead of just the number of CPUs we let this
CPU send IPIs to because in the worst case all CPUs also want
to IPI us at the same time.
- There's no need to wrap kdb_active in #ifdef KDB as it's always
available.
Reported and access for extensive tests provided by: beat [1]
Revision Changes Path
1.22.2.3 +38 -6 src/sys/sparc64/include/smp.h
1.70.2.6 +6 -0 src/sys/sparc64/sparc64/genassym.c
1.36.2.9 +21 -57 src/sys/sparc64/sparc64/mp_machdep.c
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903221033.n2MAXGwo002750>