filters). After the ipfw to pfil move ip_input() expects M_FASTFWD_OURS
tagged packets to have ip_len and ip_off in host byte order instead of
network byte order.
PR: kern/71652
Submitted by: mlaier (patch)
and sent to the DIVERT socket while the original packet continues with the
next rule. Unlike a normally diverted packet no IP reassembly attemts are
made on tee'd packets and they are passed upwards totally unmodified.
Note: This will not be MFC'd to 4.x because of major infrastucture changes.
PR: kern/64240 (and many others collapsed into that one)
doesn't do this is beyond me, but that will be investigated later. This
results in programming the chip with the correct frequency, which in turn
allows devices to negotiate up to the full 20MB/s.
and the previously malloc'ed snapshot lock.
Malloc struct snapdata instead of just the lock.
Replace snapshot fields in cdev with pointer to snapdata (saves 16 bytes).
While here, give the private readblock() function a vnode argument
in preparation for moving UFS to access GEOM directly.
preparation for integration of p4::phk_bufwork. In the future,
local filesystems will talk to GEOM directly and they will consequently
be able to issue BIO_DELETE directly. Since the removal of the fla
driver, BIO_DELETE has effectively been a no-op anyway.
the loss of a page modified (PG_M) bit in a race between processors.
Quoting Tor:
One scenario where the old code could cause a lost PG_M bit is a
multithreaded linux program (or FreeBSD program using the
linuxthreads port) where one thread was starting a subprocess.
The thread doing fork() would call vmspace_fork(), which would then
call vm_map_copy_entry() which would call pmap_protect() on an area
possibly accessed by other threads.
Additionally, make the clearing of PG_M by pmap_protect() unconditional if
write permission is removed. Previously, PG_M could persist on a read-only
unmanaged page. That seems inconsistent and confusing.
In collaboration with: tegge@
MT5 candidate
PR: 61852
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
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
scheduler specific extension to it. Put it in the extension as
the implimentation details of how the pinning is done needn't be visible
outside the scheduler.
Submitted by: tegge (of course!) (with changes)
MFC after: 3 days
VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY.
The vge driver has been added to GENERIC for i386, pc98 and amd64,
but not to sparc or ia64 since I don't have the ability to test
it there. The vge(4) driver supports VLANs, checksum offload and
jumbo frames.
Also added the lge(4) and nge(4) drivers to GENERIC for i386 and
pc98 since I was in the neighborhood. There's no reason to leave them
out anymore.
to device driver unloading. Adding these two now and MT5'ing them will
allow us to preserve binary compatibility on RELENG_5 when these facilities
are MFC'ed.
MT5 Candiate.
holds sndstat_lock across a call to uiomove(), which is not legal
to do with a mutex because of the possibility that the data transfer
could sleep because of a page fault. It is not possible to just
unlock the mutex for the uiomove() call without introducing another
locking mechanism to prevent the body of sndstat_read() from being
re-entered. Converting sndstat_lock to an sx lock is the least
complicated change.
This is a candidate for RELENG_5.
LOR: 030
MFC after: 4 days
example the maximum segment size is 64K while the boundary is set
to 8K due to controller limitations. It is impossible to NOT cross
the boundary for any segment size that's larger than the boundary.
So, once we inherited the boundary from the parent tag, make sure
to reduce the maximum segment size to the boundary if it was larger.
MT5 candidate.
branch prediction optimization for LINT, because the kernel was too
large. This commit now removes it altogether since it causes build
failures for GENERIC kernels and the various applicable trends are
such that one can expect that it these failure will cause more
problems than they're worth in the future. These trends include:
1. Alpha was demoted from tier 1 to tier 2 due to lack of active
support. The number of people willing to fix build breakages
is not likely to increase and those developers that do have the
gumption to test MI changes on alpha are not likely to spend
time fixing unexpected build failures first.
2. The kernel will only increase in size. Even though stripped-down
kernels do link without problems now, compiler optimizations (like
inlining) and new (non-optional) functionality will likely cause
stripped-down kernels to break in the future as well.
So, with my asbestos suit on, get rid of potential problems before
they happen.
MT5 candidate.
redundant at this point and should be retired). Don't free subdevs if
we don't attach any devices. This was leaving stale device_t's
around. Don't touch the device if it isn't attached since the name
isn't meaningful then. Switch from strncpy (properly used) to
strlcpy.
From a patch submitted by Peter Pentchev
device_t instances when no driver attaches. They are left around, and
we need to remember them.
# The usbd_device_handle->subdevs[] array likely is completely bogus
# at this point, but one change at a time, since its removal will need
# to have similar code replace it extracted from newbus.
Part of the patch submitted by Peter Pentchev after an excellent
analysis of the underlying problems.
MFC After: 1 week
across frames. Basically, if the current frame is for the
'dblfault_handler' function, then get the next %eip and %ebp values to use
from the original TSS of the thread that has the saved state when the
double fault triggered.
MFC after: 4 days
produced better results for a test program I had here, it didn't
substantially change the number of crashes that I saw. Both the old
code and the new code seemed to produce the same crashes from the usb
layer. Since the new code also solves a close() crash, go with it
until the underlying issues wrt devices going away can be addressed.
