Searched hist:186395 (Results 1 - 1 of 1) sorted by relevance
| /freebsd-10.2-release/sys/sparc64/sparc64/ | ||
| H A D | mp_machdep.c | diff 186395 Mon Dec 22 15:39:29 MST 2008 marius - According 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. - 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. Reported and access for extensive tests provided by: Beat Gaetzi [1] |
Completed in 98 milliseconds