fatal trap 12 in pagedaemon on dual-core opteron machine
rob at hudson-trading.com
Tue Aug 2 15:16:16 GMT 2005
Thanks for the debug.mpsafenet reccomendation.
It did solve our stability problem with our mulitcast application. I ran
over 100 replays of the data that caused the panic, and we no longer panic
Unfortunately, our tcp applications now utilize a much higher percentage
of cpu. We now regularly get a load of 3, and the interactive response
of the machine is much worse. It takes up to 30 seconds to log in to the
machine when our tcp applications are running, and the lag while working
on the machine makes it feel like we're using a 1200 baud modem rather
than gigabit ethernet.
Our tcp apps function similarly to our multicast apps, they simultaneously
listen to tcp data, record the data, and re-broadcast the data using
multicast. The load while listening to the same data with
debug.mpsafenet=1 is 0.2, and on an i386 fbsd 4.11 machine the load is
comparable at 0.25, and there is no noticeable lag while working on the
At our average data load I was not able to measure a big drop off in
tcp performance, but I am concerned by the increased cpu load and
interactivity performance. We are not willing to use debug.mpsafenet=0 if
this performance drop is the price to pay.
After reading some of Robert Watson's notes on fine tuning the
multi-threaded network stack it seems that many fixes are being applied to
current, but not all of them are applied to stable. We are not willing to
run CURRENT on our productions machines. Does anyone know if patches are
planned for STABLE (either for increasing performance with GIANT on, or
for making the multi-threaded network stack more stable)?
On Mon, 11 Jul 2005, Gary wrote:
>I can confirm that I've had numerous crashes that seem to be network
>related using 5.4R AMD64 on a dual AMD Tyan S2882 Thunder K8S PRO.
>Removing the Berkley Packet Filter and IPFilter from the kernel reduced
>the frequency of the crashes. Moving from the onboard bge to the onboard
>fxp interface didn't seem to make much difference. Running the GENERIC
>uniprocessor kernel seemed to eliminate the problems.
>I got conformation that there seems to be locking issues with the multi
>threaded implementation of the network stack from Gleb Smirnoff
>(glebius at freebsd.org). Gleb suggested setting "debug.mpsafenet=0" to
>turn off multi-threaded networking (as far as I understand):
>This initially looked like it fixed the problem, but my system crashed
>again a day later.
More information about the freebsd-amd64