| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
stats obtained from the hal)
|
| |
|
| |
|
| |
|
|
|
|
| |
were reaped but was never used and is inaccessible
|
| |
|
|
|
|
|
| |
re-used within net80211 to mark 802.11 frags so allowing them to
leak through to the driver caused packets to be dropped in ath
|
|
|
|
|
|
|
| |
r188412, this broke the GU-1000T adapters.
Submitted by: yongari
Pointy hat: me
|
|
|
|
| |
Submitted by: yongari
|
|
|
|
|
|
|
| |
make sis_rxeof() handle that too. Previously it used to receive the
frame and reset controller.
PR: kern/131414
|
|
|
|
| |
Submitted by: Pavel Roskin <proski@gnu.org>
|
|
|
|
|
|
|
|
| |
is possible to tear down the taskqueue before the thread has run and the
taskqueue loop would sleep forever.
Reviewed by: sam
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
references to iv_bss and the sta table; this is equivalent and causes
direct reclaim of the old bss node when any references in packets inflight
are reclaimed (previously the old node would sit in the bss table until
the inactivity processing reclaimed it)
o remove ieee80211_node_reclaim now that it's only use is gone
Reviewed by: avatar, cbzimmer
|
|
|
|
|
|
| |
values in ARM_RAS_START and ARM_RAS_END at context switch time.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
thread0 pcb, while the board-dependant code already set a good trapframe.
Reported by: Mark Tinguely <tinguely at casselton d0t net>
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
| |
When calling setttyent() after calling endttyent(), pts_valid will never
be set to 1, because the readdir()-loop will likely never vind a pts
that has a higher number than before.
Simplify the code by removing pts_valid. We'll just set maxpts to -1
when we don't have a valid count yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.
I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.
This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
|
|
|
|
|
|
|
| |
It seems ttyslot() calls rindex(), to strip the device name to the last
slash, but this is obviously invalid. /dev/pts/0 should be stripped
until pts/0. Because /etc/ttys only supports TTY names in /dev/, just
strip this piece of the pathname.
|
|
|
|
|
|
|
|
| |
parent interface tasks to complete. This had been added to the ioctl path but
it is also need elsewhere like detach so its safe to teardown.
Reported by: Hans Petter Selasky
Submitted by: sam
|
|
|
|
| |
Approved by: kib (mentor)
|
|
|
|
| |
Reviewed by: imp
|
|
|
|
|
|
| |
statically.
Instead, bring in a stripped down version of sbwrite(), and add the offset
to every bwrite() calls.
|
|
|
|
|
|
|
|
|
|
| |
checked whether this applies to builds in /sys/*/compile/* as well):
- Create empty opt_*.h files were missing
- Hook up svr4 to the build. It compiles fine here, so no reason to
disconnect it in the Makefile. were missing
- Hook up svr4 to the build. It compiles fine here, so no reason to
disconnect it in the Makefile.
|
| |
|
|
|
|
|
| |
PR: kern/128219
Submitted by: Thinker K.F. Li <thinker at branda dot to>
|
| |
|
|
|
|
| |
Reviewed by: scottl
|
|
|
|
| |
Add speeds S800, S1600 and S3200
|
|
|
|
|
|
|
|
|
|
| |
kernel. Rather than just kick off the page daemon, we actively retire
more mappings. The inner loop now looks a lot like the inner loop of
pmap_remove_all.
Also, get_pv_entry can't return NULL now, so remove panic if it did.
Reviewed by: alc@
|
|
|
|
|
| |
here, but inconsistently. Change all instances of it to kernel_pmap
to match rest of code.
|
|
|
|
| |
Submitted by: cognet
|
|
|
|
| |
Pointy hat: sam
|
|
|
|
|
|
|
| |
freed while the periph lock is not held. While here, wait until after
freeing the softc before reacquiring the periph lock.
Tested by: sbruno
|
|
|
|
|
|
|
|
|
| |
- Always read the character device pointer while the associated devfs vnode
is locked. Also, use dev_ref() to obtain a new reference on the vnode for
the mountpoint. This reference is released on unmount. This mirrors the
earlier fix to FFS.
Reviewed by: kib
|
|
|
|
|
|
|
|
| |
cleanup. Before the GEOM consumer would not have been closed.
- Bump the reference on the character device being mounted while the
associated devfs vnode is locked.
Reviewed by: kib
|
|
|
|
| |
Submitted by: Pavel Roskin <proski@gnu.org>
|
|
|
|
|
|
|
|
|
|
|
| |
guaranteed to initialize its two last arguments. Therefore, there is a
warning in the subsequent caller ar5416FillVpdTable(), which doesn't
initialize those arguments.
Change getLowerUpperIndex() to assign values to indexL and indexR even
in the case of assertion failure.
Submitted by: Pavel Roskin <proski@gnu.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because we now have a reliable library function that converts file
descriptors to character device names, let stat(1) use this. This means
it can now do the following:
$ stat -f %N
/dev/pts/0
I've changed main() to set file properly, so output() is never called
with file set to NULL.
Approved by: dougb (older version, still used devname)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A more elegant way of obtaining a name of a character device by its file
descriptor on FreeBSD, is to use the FIODGNAME ioctl. Because a valid
file descriptor implies a file descriptor is visible in /dev, it will
always resolve a valid device name.
I'm adding a more friendly wrapper for this ioctl, called fdevname(). It
is a lot easier to use than devname() and also has better error
handling. When a device name cannot be resolved, it will just return
NULL instead of a generated device name that makes no sense.
Discussed with: kib
|
| |
|
| |
|
|
|
|
|
| |
PR: kern/131575
MFC after: 2 days
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like the old TTY layer, the current MPSAFE TTY layer does not make
any attempt to serialize calls of write(). Data is copied into the
kernel in 256 (TTY_STACKBUF) byte chunks. If a write() call occurs at
the same time, the data may interleave. This is especially likely when
the TTY starts blocking, because the output queue reaches the high
watermark.
I've implemented this by adding a new flag, TTY_BUSY_OUT, which is used
to mark a TTY as having a thread stuck in write(). Because I don't want
non-blocking processes to be possibly blocked by a sleeping thread, I'm
still allowing it to bypass the protection. According to this message,
the Linux kernel returns EAGAIN in such cases, but I think that's a
little too restrictive:
http://kerneltrap.org/index.php?q=mailarchive/linux-kernel/2007/5/2/85418/thread
PR: kern/118287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from the parent to the child process if they have an operation vector
of &badfileops. This narrows a set of races involving system calls that
allocate a new file descriptor, potentially block for some extended
period, and then return the file descriptor, when invoked by a threaded
program that concurrently invokes fork(2). Similar approches are used
in both Solaris and Linux, and the wideness of this race was introduced
in FreeBSD when we moved to a more optimistic implementation of
accept(2) in order to simplify locking.
A small race necessarily remains because the fork(2) might occur after
the finit() in accept(2) but before the system call has returned, but
that appears unavoidable using current APIs. However, this race is
vastly narrower.
The fix can be validated using the newfileops_on_fork regression test.
PR: kern/130348
Reported by: Ivan Shcheklein <shcheklein at gmail dot com>
Reviewed by: jhb, kib
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
in 'sc_state'. This allows the lpt_release_ppbus() calls in those two
routines to actually release the ppbus and thus fixes the hangs noticed
with the lpt(4) driver since the recent ppbus changes. The old lpt(4)
driver didn't actually check the HAVEBUS flag in lpt_release_ppbus() which
is why these bugs weren't noticed before.
|