cpu could have been bogged down with non-transferable load and still not
migrated a new thread to an idle cpu. This required some benchmarking and
tuning to get right as the comment above it suggests.
otherwise they are initialized twice when the code is statically
configured in the kernel because the module load method gets
invoked before the user application calls ip_mrouter_init
o add a mutex to synchronize the module init/done operations; this
sort of was done using the value of ip_mroute but X_ip_mrouter_done
sets it to NULL very early on which can lead to a race against
ip_mrouter_init--using the additional mutex means this is safe now
o don't call ip_mrouter_reset from ip_mrouter_init; this now happens
once at module load and X_ip_mrouter_done does the appropriate
cleanup work to insure the data structures are in a consistent
state so that a subsequent init operation inherits good state
Reviewed by: juli
- In sched_add(), do the idle check prior to the transfer check so that we
don't try to transfer load from an idle cpu. This fixes panics caused by
IPIs on UP machines running SMP kernels.
Reported/Debugged by: seanc
to each other.
Correct the recovery thread's loop so that it
will terminate properly on shutdown. We also
clear the recovery_thread proc pointer so that
any additional calls to aic_terminate_recovery_thread()
will not attempt to kill a thread that doesn't
exist. Lastly, code the loop so that termination
will still be successfull even if the termination
request occurs just prior to us entering the loop
or while the recovery thread is off recovering
commands.
ó++ ABI document at http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor
The ABI was initially defined for ia64, but GCC3 and Intel compilers
have adopted it on other platforms.
This is the patch from PR bin/59552 with a number of changes by
me.
PR: bin/59552
Submitted by: Bradley T Hughes (bhughes at trolltech dot com)
C++ ABI document at http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor
The ABI was initially defined for ia64, but GCC3 and Intel compilers
have adopted it on other platforms.
This is the patch from PR bin/59552 with a number of changes by
me.
PR: bin/59552
Submitted by: Bradley T Hughes (bhughes at trolltech dot com)
which means "always stay in the standard mode of PPPoE operation
regardless of any junk floating around."
As the referenced PR stated clearly, the old default setting of 0
was extremely dangerous because it opened a possibility for a
spurious frame not only to put down a single PPPoE node running
FreeBSD, but to plague *every* FreeBSD node in a PPPoE network in
such a way that those nodes would keep poisoning each other until
rebooted simultaneously.
PR: kern/47920
Reviewed by: Gleb Smirnoff <glebius <at> cell.sick.ru>
MFC after: 1 week
that would cause an infinite loop any time we
manually flush the good status FIFO. Also make
our loop delay unconditional to ensure we don't
miss any FIFO allocations by the hardware.
than a char array. Emitting the data as a big char array works fine in
the typical case, where a .sys file may be ~50K in size. Unfortunately,
some .sys files can be several hundred Kbytes in size, or even several
megabytes in size. One extreme case is the Intel centrino wireless
driver, which is 2.4MB. This causes us to emit an ndis_driver_data.h
file that's on the order of 15MB in size, and gcc consumes enormous
amounts of virtual memory while trying to compile it. On my laptop,
with 128MB of RAM and 256MB of swap space, gcc consumed all available
VM and crashed without being able to compile if_ndis.o.
By emitting the array as assembler, we bypass the C compiler and consume
much less memory. I was able to easily test compile if_ndis.ko with the
centrino driver on my laptop after this change.
This is merely a convenience, and should not have any operational effect
on the NDISulator itself.
nonstandard. They differ in the values of certain fields in
the PPPoE frame. Previously, ng_pppoe would start in standard
mode, yet switch to nonstandard one upon reception of a single
nonstandard frame. After having done so, ng_pppoe would be unable
to interact with standard PPPoE peers. Thus, a DoS condition
existed that could be triggered by a buggy peer or malicious party.
Since few people have expressed their displeasure WRT this problem,
the default operation of ng_pppoe is left untouched for now. However,
a new value for the sysctl net.graph.nonstandard_pppoe is introduced,
-1, which will force ng_pppoe stay in standard mode regardless of any
bogus frames floating around.
PR: kern/47920
Submitted by: Gleb Smirnoff <glebius <at> cell.sick.ru>
MFC after: 1 week
