| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code
has been changed.
Requested by: phk
|
|
|
|
|
|
|
|
|
| |
on ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
|
|
|
|
| |
RS-530(449)/X.21 interface.
|
|
|
|
|
| |
vm_page_flag_clear(PG_BUSY). The object lock is held the entire time.
Thus, whether or not the PG_BUSY flag is set is invisible to others.
|
| |
|
|
|
|
|
|
|
|
|
| |
ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
|
|
|
|
|
|
|
|
|
| |
on ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
|
|
|
|
| |
Spotted by: njl
|
|
|
|
|
|
| |
interpret the rest of the msdosfs_args structure.
Detected by: marcel
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
o s/u_long/unsigned long/
o s/uint32_t/unsigned int/g
o s/uint64_t/unsigned long/g
Trigger case: multimedia/mpeg2codec
|
| |
|
|
|
|
| |
Noticed by: "Jayel Villamin" <jarthel operamail com>
|
| |
|
|
|
|
|
|
|
| |
should push software state to the hardware (was ERESTART which caused the
system call to be retried)
Submitted by: Tor Egge
|
|
|
|
| |
on the advice of Alan Cox.
|
|
|
|
|
|
| |
for its presence before RTFREE().
Noticed by: ru
|
|
|
|
|
|
|
|
|
| |
Andre:
First lets get major new features into the kernel in a clean and nice way,
and then start optimizing. In this case we don't have any obfusication that
makes later profiling and/or optimizing difficult in any way.
Requested by: csjp, sam
|
| |
|
|
|
|
|
| |
Discussed with: gallatin@
Tested by: ken@
|
|
|
|
|
|
|
|
| |
either src or dst) fails. This closes a potential data loss case
(where the fsync failed with ENOSPC, for example).
Submitted by: Mohan Srinivasan mohans at yahoo-inc dot com
Obtained from: Yahoo!
|
|
|
|
|
|
|
|
| |
Kick off a readahead only when sequential access is detected. This
eliminates wasteful readaheads in random file access.
Submitted by: Mohan Srinivasan mohans at yahoo-inc dot com
Obtained from: Yahoo!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mechanism used by pfil. This shared locking mechanism will remove
a nasty lock order reversal which occurs when ucred based rules
are used which results in hard locks while mpsafenet=1.
So this removes the debug.mpsafenet=0 requirement when using
ucred based rules with IPFW.
It should be noted that this locking mechanism does not guarantee
fairness between read and write locks, and that it will favor
firewall chain readers over writers. This seemed acceptable since
write operations to firewall chains protected by this lock tend to
be less frequent than reads.
Reviewed by: andre, rwatson
Tested by: myself, seanc
Silence on: ipfw@
MFC after: 1 month
|
|
|
|
|
|
| |
struct ieee80211com after net80211 import.
Submitted by: Tor Egge
|
|
|
|
| |
used by sync part of driver, so put them back.
|
| |
|
|
|
|
|
|
|
|
| |
prematurely report that they were full and/or to panic the kernel
with the message ``ffs_clusteralloc: allocated out of group''.
Submitted by: Henry Whincup <henry@jot.to>
MFC after: 1 week
|
|
|
|
| |
Submitted by: rushani, sumikawa
|
|
|
|
|
| |
Reviewed by: andre
MFC after: 1 week
|
|
|
|
|
|
| |
This depends on ACPI and RTC registers.
Reviewed by: njl
|
|
|
|
| |
Obtained from: OpenBSD
|
|
|
|
|
| |
when this mode is used.
- Manual page update.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
completely. For some reason (that I am still curious about) we started to no
longer manage to finish the initialization before the timeouts run the first
time leading to panics when using uninitialized mutex etc.
The root of this problem is that we currently first link a domain to the
domains list and only later initialize the domain's protocols. This should
be reworked in the future, but with the current API it is not possible in
all situations. We settle with this lazy fix for now.
Tested by: gnn, ru, myself
|
| |
|
|
|
|
|
|
|
| |
- Make route cacheing optional, configurable via IFF_LINK0 flag.
- Turn it off by default.
Reminded by: suz
|
|
|
|
|
|
|
|
| |
implementation.
Tested by: Savchuk Taras
Reviewed by: archie
Approved by: julian (mentor)
|
| |
|
|
|
|
|
|
|
|
| |
to arp resolve "secondary" local addresses.
Found and submitted by: ru
With additions from: OpenBSD (rev. 1.47)
Reviewed by: ru
|
| |
|
|
|
|
|
| |
Approved by: imp (mentor)
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
stepped the process to the system call), we need to clear the trap flag
from the new frame unless the debugger had set PF_FORK on the parent.
Otherwise, the child will receive a (likely unexpected) SIGTRAP when it
executes the first instruction after returning to userland.
Reviewed by: bde
MFC after: 3 days
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
which included commits to RCS files with non-trunk default branches.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Changes listed only since last public release 0.9.12.14; for changes
prior to that consult the CVS logs at http://madwifi.sourceforge.net]
o reorg directory structure to have a single set of public binary builds
shared by all systems
o support for new parts (all shipping pci/cardbus parts to this date work)
o new capabilities for identifying various chip features
o set/get tx power cap for supporting 802.11h information element
o revised api for set/get tx queue properties
o support for updating CTS in frames when doing packet bursting
o support for querying which tx queues have pending interrupts
|
| |
| |
| |
| |
| |
| |
| | |
We still use "normal" mode, AHCI mode is in the works still.
HW donated by: Sentex
HW donated by: Yahoo!
|