Ok, I committed the patch with one additinal change which is to
comment out the assertion causing the reported IPV6 issues.
I tracked it down but can't fix it right now. Basically what is
happening is that IPV6 packets are being forwarded to the "netisr_cpu 0"
thread, so some of the UDP and TCP processing is taking place there
instead of in the tcp or udp protocol threads. Actually, I think it
might be taking place in both threads (on the same cpu) which might
create its own issues.
The chain of events starts with the netisr_register() call made in
netinet6/ip6_input.c and fans out from there.
The tcp timer assertions are being left intact as they assert the
caller is on the correct cpu, which we are even though we are in the
wrong protocol thread.
I think that will work out for now. What we really need to do is
implement a proper ip6_demux.c which would then forward the packets
to (at least) the proper protocol threads instead of the
"netisr_cpu 0" protocol thread.
-Matt
