frame includes FCS (requires applications to be updated, but since
we weren't doing the out-of-line FCS stuff anyway app changes
were needed already)
o add a flag to indicate padding exists between the 802.11 header and
the payload (e.g. for Atheros cards)
o diff reducation against netbsd
MFC after: 1 week
in mddestroy() to properly free already allocated memory.
This fixes a panic when we want to create too big memory backed device
with preallocate memory (-o reserve).
- Remove redundant { }.
MFC after: 1 week
address, nor do we need the alignment requirements, so eliminate them.
This likely means that we can now collapse some of the entries as we
have no need of them anymore (they match other entries and were there
only to get the right attr memory offset of the enet addr).
designed to help detect tamper-after-free scenarios, a problem more
and more common and likely with multithreaded kernels where race
conditions are more prevalent.
Currently MemGuard can only take over malloc()/realloc()/free() for
particular (a) malloc type(s) and the code brought in with this
change manually instruments it to take over M_SUBPROC allocations
as an example. If you are planning to use it, for now you must:
1) Put "options DEBUG_MEMGUARD" in your kernel config.
2) Edit src/sys/kern/kern_malloc.c manually, look for
"XXX CHANGEME" and replace the M_SUBPROC comparison with
the appropriate malloc type (this might require additional
but small/simple code modification if, say, the malloc type
is declared out of scope).
3) Build and install your kernel. Tune vm.memguard_divisor
boot-time tunable which is used to scale how much of kmem_map
you want to allott for MemGuard's use. The default is 10,
so kmem_size/10.
ToDo:
1) Bring in a memguard(9) man page.
2) Better instrumentation (e.g., boot-time) of MemGuard taking
over malloc types.
3) Teach UMA about MemGuard to allow MemGuard to override zone
allocations too.
4) Improve MemGuard if necessary.
This work is partly based on some old patches from Ian Dowse.
cards work. These changes depend on the expanded funce parsing that
just was committed to pccard_cis.c. In NetBSD the ethernet address
was read out of attr memory directly. We rely on the kernel pccard
parser to pulll this information out of what appears to be an obsolete
funce with the information in it.
# I'm still getting the no rx interrupt sometimes with some hub/switches
# for reasons unknown... But usually only one and only when dhclient
# runs.
as type 0, rather than the usualy type 4. Assume that this format is
from an old standard and go with it. The Fujitsu FMV-186A and Silicom
Ethernet cards I have both have tuples with this format, and they are
both pretty old cards.
# if somebody knows for sure, please let me know.
in BSD class, ie. if provider below us uses the same metadata, don't
create slices based on the metadata.
This allows to create slices on geoms with rank != 1 without hacks.
Discussed with: phk
Approved by: phk
MFC after: 2 weeks
aware of any fe based cards that do anything except network (well,
maybe the fujitsu scsi/lan card, but I've only seen two of those on
ebay in the last 3 years).
replacement address for an rdr rule. Some rdr rules have no address family
(when the replacement is a table and no other criterion implies one AF).
In this case, pf would fail to select a replacement address and drop the
packet due to translation failure.
Found by: Gustavo A. Baratto
virtual COM port. This makes the use of the Dell OpenManage tools on FreeBSD
considerably easier, and is based on Chuck Cranor's original patch for 4.6.
Reviewed by: imp
Tested by: dpk at dpk dot net
MFC after: 1 week
bridge in the device tree which lacks the mandatory (also by the OFW PCI
bus binding spec) "reg" property. Change the code to just ignore nodes
missing the "reg" property instead of panicing when encountering such a
node. Also ignore nodes without a "name" property (guaranteed by the OFW
PCI bus binding spec). This brings the behaviour of the MD OFW PCI code
regarding such incomplete nodes in line with the EBus and the SBus code.
Tested by: Cyril Tikhomiroff <tikho@anor.net>
MFC after: 1 month
