kern/182382: sysctl to set TCP CC method on BIG ENDIAN systems fails
jau at oxit.fi
Wed Sep 25 19:50:01 UTC 2013
>Synopsis: sysctl to set TCP CC method on BIG ENDIAN systems fails
>Arrival-Date: Wed Sep 25 19:50:00 UTC 2013
>Originator: Jukka Ukkonen
FreeBSD yggdrasil 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r255867M: Wed Sep 25 12:57:17 EEST 2013 root at yggdrasil:/usr/obj/usr/src/sys/GENERIC powerpc
fails on big endian systems.
On a PowerPC it only complains...
net.inet.tcp.cc.algorithm=htcp: No such process
It does not matter what one put in place of "htcp" as the new default CC method.
The complaint will always be otherwise exactly the same.
All of the required modules are there...
10 7 0xd1a00000 12000 h_ertt.ko
11 1 0xd1a12000 14000 cc_cdg.ko
12 1 0xd1a26000 12000 cc_htcp.ko
13 1 0xd1a38000 12000 cc_cubic.ko
14 1 0xd1a4a000 12000 cc_vegas.ko
15 1 0xd1a5c000 12000 cc_hd.ko
16 1 0xd1a6e000 13000 cc_chd.ko
but the CC method will not change.
It seems that on PowerPC in the kernel function cc_default_algo()
req->newptr will point to a whole lot of \xff bytes.
On a sparc64 system the kernel will instantly panic with an MMU error message.
On a PPC which is less pedantic about memory reference alignments and stuff
one will only get a ESRCH in return, because a landslide of "\xff\xff..." usw.
does not match any of the known CC method names.
See kern/178079, which someone has marked as networking specific error,
for a similar complaint about Sparc64.
Notice that this is NOT about networking as such.
This is about getting wrong data in the call arguments passed from sysctl()
proper to the CC specific function.
So, this is about sysctl() internals, not about networking.
or use your pet CC method name in place of htcp. (cubic, vegas, cdg, chd, ...)
Doing this on a PowerPC will only fail to change your CC method.
Do this on a Sparc64 and meet Mr. Panic Reboot.
Not known yet.
More information about the freebsd-bugs