| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
1. The PBVM is in region 4, so if we want to make use of it, we
need region 4 freed up.
2. Region 4 and above cannot be represented by an off_t by virtue
of that type being signed. This is problematic for truss(1),
ktrace(1) and other such programs.
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX does not require the shell to fork for a subshell environment, and we
use that possibility in various ways (command substitutions with a single
command and most subshells that are the final command of a shell process).
Therefore do not tie subshells to forking in the man page.
Command substitutions with expansions are a bit strange, causing a fork for
$(...$(($x))...) because $x might expand to y=2; they will probably be
changed later but this is how they work now.
|
|
|
|
|
| |
Pointed out by: bschmidt
MFC after: 1 day
|
|
|
|
|
|
|
|
| |
Instead of directly calling ffs_snapgone(), use UFS_SNAPGONE() with
usual layering.
Requested by: bde
MFC after: 1 week
|
|
|
|
|
|
| |
POSIX.1-2008.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.
This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.
|
|
|
|
|
|
| |
since before r127501. Strictly speaking, the buffer pages are not
"wired". They remain in the paging queues. However, they are pinned in
memory using vm_page_hold().
|
| |
|
|
|
|
| |
- Add merge script for integrating amd64 slice into i386 disk image
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not needed.
These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.
I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.
|
|
|
|
|
| |
* Restore the chip default of the DCU backoff threshold to 0x2,
mirroring what ath9k does.
|
|
|
|
|
|
|
|
|
| |
preparation
for fixing them based on the ath9k related TXQ fixes.
I've done this so people can go over the history of the diffs to the original
AR5212 routines (which AR5416 and later chips use) to see what's changed.
|
|
|
|
| |
MFC after: 1 Week
|
|
|
|
|
| |
over the TX queue setup code from ath9k for the AR5416 and later
chips.
|
|
|
|
|
|
| |
in addition to CVSUP, and add support for alternate SVN roots for src.
Requested by: jhb
|
|
|
|
|
|
|
|
|
| |
enables broadcast filtering. Make sure to clear the bit to receive
broadcast frames. While I'm here rename the bit definition to
reflect reality.
Reported by: brad@OpenBSD
MFC after: 1 week
|
|
|
|
|
|
| |
Partialy revert the previous change.
MFC after: 1 Week.
|
|
|
|
|
|
| |
- A closer inspection of the OpenSolaris code indicates the block store
workaround is only necessary in case of BUS_DMASYNC_POSTREAD.
- Mark some unused parameters as such.
|
|
|
|
|
|
|
| |
Initialize a variable when it is really needed.
To avoid code duplication move the miss label to line up and jump on it.
MFC after: 1 Week
|
|
|
|
| |
nodes.
|
| |
|
|
|
|
|
| |
latency. This is more or less a theoretical problem though as it
typically indicates way bigger problems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases as udp6_connect() without an earlier bind(2) to an
address, v4-mapped scokets allowed and a non mapped destination
address, we can end up here with both v4 and v6 indicated:
inp_vflag = (INP_IPV4|INP_IPV6|INP_IPV6PROTO)
In that case however laddrp is NULL as the IPv6 path does not
pass in a copy currently.
Reported by: Pawel Worach (pawel.worach gmail.com)
Tested by: Pawel Worach (pawel.worach gmail.com)
MFC after: 6 days
X-MFC with: r219579
|
|
|
|
| |
MFC after: 1 Week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
configurations and make it opt-in for those who want it. LINT will
still build it.
While it may be a perfect win in some scenarios, it still troubles users
(see PRs) in general cases. In addition we are still allocating resources
even if disabled by sysctl and still leak arp/nd6 entries in case of
interface destruction.
Discussed with: qingli (2010-11-24, just never executed)
Discussed with: juli (OCTEON1)
PR: kern/148018, kern/155604, kern/144917, kern/146792
MFC after: 2 weeks
|
|
|
|
| |
by the HAL at some point in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."
The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.
The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.
This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)
The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
|
|
|
|
|
|
| |
Since ath9k does some slightly different bit fiddling when setting up
the TX queues, it may that the TX queue setup/reset functions will need
overriding later on.
|
|
|
|
| |
code.
|
| |
|
| |
|
|
|
|
|
|
|
| |
- Change name to reflect this
- Install all kernel modules
- Choose image size that i386 and amd64 can be combined into one image
- Mount tmpfs over /boot/zfs for zpool imports
|
|
|
|
|
|
|
| |
segment so that it's always mapped by the loader.
o Change the alternate fault handlers to account for PBVM. Since
currently the region is handled by the VHPT, no alternate faults
will be generated for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
been undergoing test for some weeks. This improves the RX
mbuf handling to avoid system hang due to depletion. Thanks
to all those who have been testing the code, and to Beezar
Liu for the design changes.
Next the igb driver is updated for similar RX changes, but
also to add new features support for our upcoming i350 family
of adapters.
MFC after a week
|
|
|
|
|
| |
the bounds of user space. Redefine VM_MAX_ADDRESS as ~0UL, even though
it's not used anywhere in the source tree.
|
|
|
|
|
|
|
|
| |
chipsets that do not have an HT slave at 0:0:0:0. The Linux quirk is
actually specific to Nvidia chipsets and the check I had added was in
the wrong place.
Prodded by: nathanw
|
|
|
|
|
| |
If you don't want to use resolvconf(8) to update /etc/resolv.conf,
you can put resolvconf_enable="NO" into /etc/dhclient-enter-hooks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Always enable the HyperTransport MSI mapping window for HyperTransport
to PCI bridges (these show up as HyperTransport slave devices).
The mapping windows in PCI-PCI bridges are enabled by existing code
in the PCI-PCI bridge driver as MSI requests propagate up the device
tree, but Host-PCI bridges don't really show up in that tree.
- If the PCI device at domain 0 bus 0 slot 0 function 0 is not a
HyperTransport device, then blacklist MSI on any other HT devices in
the system. Linux has a similar quirk.
PR: kern/155442
Tested by: Zack Dannar zdannar of gmail
MFC after: 1 week
|
|\
| |
| |
| | |
Helped by: jhb
|
| |
|
|
|
|
| |
Helped by: jhb
|
|
|
|
| |
Approved by: miwi@ (mentor)
|
|
|
|
| |
Approved by: miwi@ (mentor)
|
|
|
|
|
|
|
|
|
|
|
| |
which are not yet fully initialized (i.e. ones with p_state == PRS_NEW).
Without it, we could panic in _thread_lock_flags().
Note that there may be other instances of FOREACH_PROC_IN_SYSTEM() that
require similar fix.
Reported by: pho, keramida
Discussed with: kib
|
|
|
|
|
| |
Submitted by: arundel (via doc@)
MFC after: 3 days
|
|
|
|
| |
Submitted by: gcooper
|