calls in sb_cmd2() and sb_getmixer(). The lock has already be grabbed
before these functions are called.
This is a RELENG_5 candidate.
PR: 71189
Submitted by: stephane
MFC after: 3 days
FreeBSD Hardware Notes, source code and cvs comments from
FreeBSD and NetBSD.
- Update page title and DESCRIPTION section to reflect the fact that
this driver supports much more than Handspring Visor now.
MFC after: 3 days
PREEMPTION kernel option added,
ucycom(4) for Cypress CY7C637xx and CY7C640/1xx families
of USB to RS232 bridges added,
debug.witness_* tunable renamed to debug.witness.*,
vge(4) for VIA VT6122 gigabit ethernet chip added, and
mkuzip(8) for GEOM_UZIP added.
Update release notes:
remove %include.historic; section for now,
4BSD is the default schedular now, and
update links to sound(4)-related manual pages.
contain O_UID, O_GID and O_JAIL opcodes, the F_NOT or F_OR logical
operator bits get clobbered. Making it impossible to use the ``NOT'' or
``OR'' operators with uid, gid and jail based constraints.
The ipfw_insn instruction template contains a ``len'' element which
stores two pieces of information, the size of the instruction
(in 32-bit words) in the low 6 bits of "len" with the 2 remaining
bits to implement OR and NOT.
The current code clobbers the OR and NOT bits by initializing the
``len'' element to the size, rather than OR'ing the bits. This change
fixes this by changing the initialization of cmd->len to an OR operation
for the O_UID, O_GID and O_JAIL opcodes.
This may be a MFC candidate for RELENG_5.
Reviewed by: andre
Approved by: luigi
PR: kern/63961 (partially)
the pseudo header. We really need the TCP packet length here. This happens
to end up in ip->ip_len in tcp_input.c, but here we should get it from the
len function variable instead.
Submitted by: yongari
Tested by: Nicolas Linard, yongari (sparc64 + hme)
MFC after: 5 days
fully initialed when the pmap layer tries to call sched_pini() early in the
boot and results in an quick panic. Use ke_pinned instead as was originally
done with Tor's patch.
Approved by: julian
value was only enough for 8GB of RAM, the new value can do 16GB. This still
isn't optimal since it doesn't scale. Fixing this for amd64 looks to be
fairly easy, but for i386 will be quite difficult.
Reviewed by: peter
o use zlib(3) function which computes maximum length of the output
buffer instead of rolling own version;
o allow size of input file to be not multiple of cluster size by applying
zero padding.
