sigsuspend, thread shouldn't wait, in old code, it may be
ignored.
When a signal handler is invoked in sigsuspend, thread gets
two different signal masks, one is in thread structure,
sigprocmask() can retrieve it, another is in ucontext
which is a third parameter of signal handler, the former is
the result of sigsuspend mask ORed with sigaction's sa_mask
and current signal, the later is the mask in thread structure
before sigsuspend is called. After signal handler is called,
the mask in ucontext should be copied into thread structure,
and becomes CURRENT signal mask, then sigsuspend returns to
user code.
Reviewed by: deischen
Tested by: Sean McNeil <sean@mcneil.com>
that the command succeeded. Sheesh! This makes CDROMs no longer cause an
instant panic at boot. Thanks to Jake Burkholder for providing a remote
test setup.
Also make device resets work, thanks to another typo.
pass any traffic. Unfortunately this means no full-duplex link with auto-
negotiation on hme(4) using DP83840A PHYs again.
I really thought I had tested this also on a Netra t1 100...
- add locking
- disable ALTQ3_COMPAT by default (do not remove the code to keep the diff
towards KAME small)
- put some more code under ALTQ3 conditional compilation as it should be
- account for if_xname
- some more minor compile fixes
As people started wondering:
The strange path layout "altq/altq" is there to avoid "-Isys/contrib" and
make it "-Isys/contrib/altq" instead, as we will need at least <altq/altq.h>
and <altq/if_altq.h> for kernel compilation.
The "freebsd4_..." in the privious commit is just the best tag name in the
KAME tree I could find to classify this in order to track its history. It
does *not* mean that this will go to 4-STABLE or anything of that kind.
HEAD at this point). This will not exactly live in a vendor branch, but have
the vendor backing to make it easier to exchange diffs.
This will be followed by a diff which takes most of the .c files off the
vendor branch in order to:
- add locking
- disable ALTQ3_COMPAT code (which is outdated and "un-lockable")
There is work in progress to refine the configuration API. Import this "as
is" now to have more exposure time before 5-STABLE.
This is only the import, it will be some more days until you will actually
be able to compile ALTQ support into your kernel so don't hold your breath.
HEADUPs will be posted on current@ and net@ before this is actually enabled.
No-objection: re(scottl), core(rwatson)
ruleset, the pcb is looked up once per ipfw_chk() activation.
This is done by extracting the required information out of the PCB
and caching it to the ipfw_chk() stack. This should greatly reduce
PCB looking contention and speed up the processing of UID/GID based
firewall rules (especially with large UID/GID rulesets).
Some very basic benchmarks were taken which compares the number
of in_pcblookup_hash(9) activations to the number of firewall
rules containing UID/GID based contraints before and after this patch.
The results can be viewed here:
o http://people.freebsd.org/~csjp/ip_fw_pcb.png
Reviewed by: andre, luigi, rwatson
Approved by: bmilekic (mentor)
driver tries to submit the same request repeatedly, on finding the
controller cmd queue to be full.
Submitted by:ps, vkashyap
Reviewed by:re
Approved by:re
ifp->if_output() basedd on debug.mpsafenet. That way once bpfwrite()
can be called without Giant, it will acquire Giant (if desired) before
entering the network stack.
the need to synchronize access to the structure. I believe this
should fit into the stack under the necessary circumstances, but
if not we can either add synchronization or use a thread-local
malloc for the duration.
versions of various routers seen:
- Introduce igmp_mtx.
- Protect global variable 'router_info_head' and list fields
in struct router_info with this mutex, as well as
igmp_timers_are_running.
- find_rti() asserts that the caller acquires igmp_mtx.
- Annotate a failure to check the return value of
MALLOC(..., M_NOWAIT).
(bogus, application name space) mcount function name on amd64. Override
it here instead.
I've done it this way to avoid touching gcc source while 3.4 is in
progress, and this is the smallest, lowest impact I could come up with.
Adding a patch touches about 10-14 lines of Makefile, this touches only 1.
This will likely go away with the 3.4 import.
I spoke with Alexander about this a few days ago, but waited until after
sorting out some of the other bugs in the userland profiling.
is the actual name here) on EBus and which are PCF8584 (on systems having
a boot-bus controller the i2c are said to not be a PCF8584). Similar to the
SUNW,envctrl devices, onboard slaves for monitoring fans, temperatures and
such hang off of these i2c devices. But there's also stuff like EEPROMs
housing the hostid of the system and the boards usally have a connector to
add custom slave devices (on CP1500 there's actually a second PCF8584 with
its own I2C bus for these).
This driver already works fine but I'm not yet sure if access to the slave
devices on CP1400/CP1500 marked as "reserved for factory use" in the docs
should be blocked (most likely these are the voltage controllers wich aren't
meant to be controller by software and even not by the firmware). Once the
issues with polled mode are fixed in the common pcf(4) part in pcf.c, this
front-end should probably honour the poll-mode property of the i2c devices.
Tested on Ultra AXe and CP1500 (Netra t1 100).
OK'ed by: joerg, nsouch
- Use "envctrl" as the name when registering this module rather than "pcf";
we can't have "pcf" as the name for all pcf(4) front-ends or we would get
conflicts.
OK'ed by: joerg
