device, the device is probed multiple times (so each device is
detected N times after unloading/loading the module N-1 times).
The real fix is (quote Doug and Warner):
> : In an ideal world, there should be some kind of BUS_UNIDENTIFY method
> : which a driver could use to delete the devices it created in
> : BUS_IDENTIFY.
>
> Or the bus would have a driver deleted routine that got called and it
> would remove all instances of the devclass attached to it.
Reviewed by: Doug Rabson & Warner Losh
to mmap it PROT_EXEC. This also depends on the architecture, as some
architextures (e.g. i386) do not distinguish between read and exec pages
Inspired by: http://linux.bkbits.net:8080/linux-2.4/cset@1.1267.1.85
Reviewed by: alc
mappings required by mdstart_swap(). On i386, if the ephemeral mapping
is already in the sf_buf mapping cache, a swap-backed md performs
similarly to a malloc-backed md. Even if the ephemeral mapping is not
cached, this implementation is still faster. On 64-bit platforms, this
change has the effect of using the direct virtual-to-physical mapping,
avoiding ephemeral mapping overheads, such as TLB shootdowns on SMPs.
On a 2.4GHz, 400MHz FSB P4 Xeon configured with 64K sf_bufs and
"mdmfs -S -o async -s 128m md /mnt"
before:
dd if=/dev/md0 of=/dev/null bs=64k
134217728 bytes transferred in 0.430923 secs (311465697 bytes/sec)
after with cold sf_buf cache:
dd if=/dev/md0 of=/dev/null bs=64k
134217728 bytes transferred in 0.367948 secs (364773576 bytes/sec)
after with warm sf_buf cache:
dd if=/dev/md0 of=/dev/null bs=64k
134217728 bytes transferred in 0.252826 secs (530870010 bytes/sec)
malloc-backed md:
dd if=/dev/md0 of=/dev/null bs=64k
134217728 bytes transferred in 0.253126 secs (530240978 bytes/sec)
I've added -fno-strict-aliasing for now so we can ease into this.
I wanted to shoot for -O3, but the inlining caused problems due to GCC's
size heuristics; so also add -frename-registers, which is one of the things
-O3 would have given us.
entry size and the ELF version. Also, avoid a potential integer
overflow when determining whether the ELF header fits entirely
within the first page.
Reviewed by: jdp
A panic when attempting to execute an ELF binary with a bogus program
header table entry size was
Reported by: Christer Öberg <christer.oberg@texonet.com>
the tap driver, even with Giant over the cdev operation vector, due to
a non-atomic test-and-set of the si_drv1 field in the dev_t. This bug
exists with Giant under high memory pressure, as malloc() may sleep
in tapcreate(), but is less likely to occur. The resolution will
probably be to cover si_drv1 using the global tapmtx since no softc is
available, but I need to think about this problem more generally
across a range of drivers using si_drv1 in combination with SI_CHEAPCLONE
to defer expensive allocation to open().
Correct what appears to be a bug in the original if_tap implementation,
in which tapopen() will panic if a tap device instance is opened more
than once due to an incorrect assertion -- only triggered if INVARIANTS
is compiled in (i.e., when built into a kernel). Return EBUSY instead.
Expand mtx_lock() coverage using tp->tap_mtx to include tp->ether_addr.
- 0 should have been -1 in previous commit (just to stay consistent),
- Spell null pointers as NULL, not 0,
- Fixed the comment about pr_usesysctl to not confuse it with boolean.
Pointed by: bde
use sf_buf_free() instead of sf_buf_mext() to consolidate all actions
that require the page queues lock in one critical section. While I'm
here remove unnecessary splvm() and splx() calls.
just print the header (if any) and exit, thus matching the behavior on -stable
and other OS's.
Also adds support for <x> being a comma-separated list of processes, and does
a much better checking for invalid-values of <x>, such as 'ps -p someword'.
Reviewed by: mentioned on freebsd-current
MFC after: 10 days
clip/destroy the dB value contained in the wi(4)'s receive frames,
it doesn't match with the flag set in the radiotap header
(unperturbed dB versus dBm).
Also set HOOK_HACK to true (remove the related #ifdef's) as we have the
hooks in the kernel this was missed during the merge from the port.
Noticed by: Amir S. (for the HOOK_HACK part)
Approved by: bms(mentor)
