| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
an initialized but otherwise unused variable. Explicitly check a pointer
against NULL.
There are no functional changes. Checked by: md5
|
|
|
|
|
|
| |
and moea_protect().
Tested by: grehan@ and rink@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
well as avoiding a switch statement. This change has no significant impact
to performance when branch prediction is successful at predicting the sizes
of objects passed to free(), but in the case that the object sizes are
semi-random, this change has the potential to prevent many branch prediction
misses, thus improving performance substantially.
Take advantage of alignment guarantees in ipalloc(), and pad object sizes to
something less than a power of two when possible. This has the potential
to substantially reduce internal fragmentation for objects allocated via
posix_memalign().
Avoid an unnecessary pow2_ceil() call in arena_ralloc().
Submitted by: djam8193ah@hotmail.com
|
|
|
|
| |
and continuing through the multimedia support section.
|
|
|
|
|
|
|
|
|
|
| |
is never taken since there aren't any 802.11a ural(4) sticks available
on the market.
PR: kern/99676
Submitted by: KIYOHARA Takashi
Reviewed by: damien
MFC after: 1 week
|
|
|
|
| |
or (in my case) no longer feel that oversight is necessary.
|
|
|
|
| |
Convert the remaining K&R-style function declarations to ANSI-style.
|
|
|
|
|
|
| |
unmangled for C++ programs.
Submitted by: Niklas Sorensson <nik@cs.chalmers.se>
|
|
|
|
|
|
|
|
|
| |
and instead creating a small allocation for each malloc(0) call. The
optional SysV compatibility behavior remains unchanged.
Add a couple of assertions.
Fix a couple of typos in error message strings.
|
| |
|
|
|
|
|
|
| |
o add netbsd portability glue
MFC after: 2 weeks
|
|
|
|
|
|
| |
potential boot disks during the probe so they are read for mount root.
Reviewed by: ps, scottl
|
|
|
|
|
|
|
|
|
|
| |
the mbuf chain. If we ever get a buggy caller, a bogus "off" should
be caught by the sanity check at the function entry. Null "m" here
means a very unusual condition of a totally broken mbuf chain (wrong
m_pkthdr.len or whatever), so we can just page fault later.
Found by: Coverity Prevent(tm)
CID: 825
|
|
|
|
| |
Submitted by: Vadim Goncharov
|
|
|
|
| |
- Add the forgotten new option in usage().
|
|
|
|
|
| |
PR: kern/99632
Submitted by: clsung
|
|
|
|
| |
- Some typo fixes.
|
|
|
|
|
|
|
|
|
|
|
|
| |
tree... John Baldwin noted that sio might pass values between probe
and attach via softc. It appears that sio does leave the hardware in
a known state after probing, so other drivers that try to probe might
leave it in a worse state. It doesn't seem to pass any data in softc,
however, that I could find... I think we should not be probing for
anything but nonPnP isa, but that's a change for another day.
Submitted by: Frank Behrens
PR: 87845
|
|
|
|
|
| |
Approved by: cperciva (mentor)
MFC after: 1 week
|
| |
|
|
|
|
|
| |
branch long jump and not the branch long call. Support for that is
forthcoming.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
except in places dealing with ifaddr creation or destruction; and
in such special places incomplete ifaddrs should never be linked
to system-wide data structures. Therefore we can eliminate all the
superfluous checks for "ifa->ifa_addr != NULL" and get ready
to the system crashing honestly instead of masking possible bugs.
Suggested by: glebius, jhb, ru
|
|
|
|
| |
Funnily enough, rev. 1.15 changed the __Net and __Open cases only.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a local 'semid' variable which was the array index and used uap->semid
as the original IPC id. During the kern_semctl() conversion those two
variables were collapsed into a single 'semid' variable breaking the
places that needed the original IPC ID. To fix, add a new 'semidx'
variable to hold the array index and leave 'semid' unmolested as the IPC
id. While I'm here, explicitly document that the (undocumented, at least
in semctl(2)) SEM_STAT command curiously expects an array index in the
'semid' parameter rather than an IPC id.
Submitted by: maxim
|
|
|
|
| |
Submitted by: Anton Yuzhaninov <citrin rambler-co.ru>
|
|
|
|
| |
its run time may be lost.
|
|
|
|
|
|
|
|
| |
used since FreeBSD-SA-06:04.ipfw.
Adopt send_reject6 to what had been done for legacy IP: no longer
send or permit sending rejects for any but the first fragment.
Discussed with: oleg, csjp (some weeks ago)
|
|
|
|
| |
OKed by: rwatson (some weeks ago)
|
|
|
|
| |
comment.
|
| |
|
|
|
|
|
| |
Pointed out by: netchild
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, another thread could get a pointer to the
interface by scanning the system-wide list and sleep
on the global vlan mutex held by vlan_unconfig().
The interface was gone by the time the other thread
woke up.
In order to be able to call vlan_unconfig() on a detached
interface, remove the purely cosmetic bzero'ing of IF_LLADDR
from the function because a detached interface has no addresses.
Noticed by: a stress-testing script by maxim
Reviewed by: glebius
|
|
|
|
| |
Fix some style and consistency points.
|
| |
|
|
|
|
|
|
| |
Jumbos on them, yet. The 5780 is equivalent to the 5714.
Submitted by: brad@OpenBSD, davidch
|
|
|
|
| |
Pointed out by: ume via IRC
|
| |
|
|
|
|
|
| |
Add else statement in sched_calc_pri.
Fix a bug when checking interrupt thread in sched_add.
|
|
|
|
| |
which really hurts performance on FreeBSD.
|
|
|
|
|
|
|
|
|
|
|
|
| |
tested and then set. [1]
Reorganise things to eliminate this, we now ensure that enc0 can not be
destroyed which as the benefit of no longer needing to lock in
ipsec_filter and ipsec_bpf. The cloner will create one interface during the
init so we can guarantee that encif will be valid before any SPD entries are
added to ipsec.
Spotted by: glebius [1]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cards: the chips are all marked "RTL8111B", but they put stickers on the
back that say "RTL8168B/8111B". The manual says there's only one HWREV code
for both the 8111B and 8168B devices, which is 0x30000000, but the cards
they sent me actually report HWREV of 0x38000000. Deciding to trust the
hardware in front of me rather than a possibly incorrect manual (it wouldn't
be the first time the HWREVs were incorrectly documented), I changed the
8168 revision code. It turns out this was a mistake though: 0x30000000
really is a valid for the 8168.
There are two possible reasons for there to be two different HWREVs:
1) 0x30000000 is used only for the 8168B and 0x38000000 is only for
the 8111B.
2) There were 8111/8168 rev A devices which both used code 0x30000000,
and the 8111B/8168B both use 0x38000000.
The product list on the RealTek website doesn't mention the existence of
any 8168/8111 rev A chips being in production though, and I've never seen
one, so until I get clarification from RealTek, I'm going to assume that
0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only.
So, the HWREV code for the 8168 has been put back to 0x30000000,
a new 8111 HWREV code has been added, and there are now separate
entries for recognizing both devices in the device list. This will
allow all devices to work, though if it turns out I'm wrong I may
need to change the ID strings
|
| |
|