An attempt to switch the TCP congestion control algorithm on a sparc64 system causes an instant panic. The message shown on the console mentions something about NewReno and then something about the MMU. Though I do not have the exact text shown to quote here, it looked to me quite a lot like one of those MMU complaints one gets for improperly aligned data. Notice: I have never seen anything remotely similar happening on an amd64. So, it is supposedly impossible to replicate the problem using a CPU which does not care about the data alignment. Fix: Not the foggiest idea yet. I will keep a crash dump around for a while just in case someone wishes to have a chance to see it. I cannot promise to save it for very long, though. OTOH with the consistency I have been getting new crash dumps when touching the CC algorithm on sparc64 it should be easy enough for anyone to generate ones own crash dump if needs be. ;-) How-To-Repeat: On a sparc64 system follow these steps: First make sure you have the alternate CC modules loaded... kldload /boot/kernel/cc_*.ko Then try this... sysctl net.inet.tcp.cc.algorithm=htcp At least in my case this has been a guaranteed trick to panic the system with a complaint from the MMU.
In a sudden burst of inspiration I decided to check the same thing on PowerPC as well... # sysctl net.inet.tcp.cc.algorithm=htcp net.inet.tcp.cc.algorithm: newreno sysctl: net.inet.tcp.cc.algorithm=htcp: No such process If I replace htcp with e.g. cubic the result is quite analogous. So, the CC code does not seem all that healthy on PowerPC either. This PowerPC test was done using a 3 week old 9.1-STABLE... FreeBSD yggdrasil 9.1-STABLE FreeBSD 9.1-STABLE #0 r248939M: Mon Apr 1 20:22:53 EEST 2013 root@yggdrasil:/usr/obj/usr/src/sys/GENERIC powerpc --jau
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
not reproducible anymore with a fresh -CURRENT on sparc64