controller. These controllers are also known as L1C(AR8131) and
L2C(AR8132) respectively. These controllers resembles the first
generation controller L1 but usage of different descriptor format
and new register mappings over L1 register space requires a new
driver. There are a couple of registers I still don't understand
but the driver seems to have no critical issues for performance and
stability. Currently alc(4) supports the following hardware
features.
o MSI
o TCP Segmentation offload
o Hardware VLAN tag insertion/stripping
o Tx/Rx interrupt moderation
o Hardware statistics counters(dev.alc.%d.stats)
o Jumbo frame
o WOL
AR8131/AR8132 also supports Tx checksum offloading but I disabled
it due to stability issues. I'm not sure this comes from broken
sample boards or hardware bugs. If you know your controller works
without problems you can still enable it. The controller has a
silicon bug for Rx checksum offloading, so the feature was not
implemented.
I'd like to say big thanks to Atheros. Atheros kindly sent sample
boards to me and answered several questions I had.
HW donated by: Atheros Communications, Inc.
by prefetched than helped. On i386 systems and systems with less than 4GB,
prefetch is now disabled by default. I've added a prefetch enable tunable, to
enable prefetching for those systems. The prefetch disable tunable will continue
to unconditionally disable prefetching.
driver should read updated status back after issuing a SCB command.
To send a command to controller and read updated status back,
driver should synchronize both memory read and write operations
with device. Fix bus_dmamap_sync operation specifier used in
fxp_dma_wait() by adding both memory read and memory write
operations.
With the de_CH (swiss german) locale, numbers should look like this:
numbers: 1'234.45
monetary values: Fr. 1'234.45
Previously, the thousands separator was missing for numbers, and
"." for monetary values, and "," was incorrectly used as decimal
point.
PR: conf/75502
Submitted by: Benjamin Lutz <benlutz@datacomm.ch>
MFC after: 1 week
If packet leaves ipfw to other kernel subsystem (dummynet, netgraph, etc)
it carries pointer to matching ipfw rule. If this packet then reinjected back
to ipfw, ruleset processing starts from that rule. If rule was deleted
meanwhile, due to existed race condition panic was possible (as well as
other odd effects like parsing rules in 'reap list').
P.S. this commit changes ABI so userland ipfw related binaries should be
recompiled.
MFC after: 1 month
Tested by: Mikolaj Golub
not exist to let the user know that it will be created for the next run.
2. Delete more stuff we're not going to use from the temproot prior to
creating the mtree database to dramatically reduce its size (162K -> 37K).
3. We've been deleting the zero-size files from temproot for a long time
now, so remove the spurious "-size +0" from the find command in the
comparison loop, and remove what is now a really stale comment.
the implementation can guarantee forward progress in the event of
a stuck interrupt or interrupt storm. This is especially critical
for fast interrupt handlers, as they can cause a hard hang in that
case. When first called, arm_get_next_irq() is passed -1.
Obtained from: Juniper Networks, Inc.
vm_map_pmap_enter(). The immediate effect of this change is that automatic
prefaulting by mmap() for small mappings is performed on POSIX shared memory
objects just the same as it is on ordinary files.
o don't increment extracted tid, this was a vestige of IEEE80211_NONQOS_TID
being defined as 0 (w/ real tid's +1)
o handle 4-address frames (add IEEE80211_IS_DSTODS to check if an 802.11
header is DSTODS)
Submitted by: cbzimmer
Reviewed by: avatar
for FreeBSD-CURRENT, the code that checked for and returned the
error was broken. Change it to check for VI_DOOMED set after
vn_lock() and return an error for that case. I believe this
should only happen for forced dismounts.
Approved by: kib (mentor)
probe. The current device order is unchanged. This commit just adds the
infrastructure and ABI changes so that it is easier to merge later changes
into 8.x.
- Driver attachments now have an associated pass level. Attachments are
not allowed to probe or attach to drivers until the system-wide pass level
is >= the attachment's pass level. By default driver attachments use the
"last" pass level (BUS_PASS_DEFAULT). Driver's that wish to probe during
an earlier pass use EARLY_DRIVER_MODULE() instead of DRIVER_MODULE() which
accepts the pass level as an additional parameter.
- A new method BUS_NEW_PASS has been added to the bus interface. This
method is invoked when the system-wide pass level is changed to kick off
a rescan of the device tree so that drivers that have just been made
"eligible" can probe and attach.
- The bus_generic_new_pass() function provides a default implementation of
BUS_NEW_PASS(). It first allows drivers that were just made eligible for
this pass to identify new child devices. Then it propogates the rescan to
child devices that already have an attached driver by invoking their
BUS_NEW_PASS() method. It also reprobes devices without a driver.
- BUS_PROBE_NOMATCH() is only invoked for devices that do not have
an attached driver after being scanned during the final pass.
- The bus_set_pass() function is used during boot to raise the pass level.
Currently it is only called once during root_bus_configure() to raise
the pass level to BUS_PASS_DEFAULT. This has the effect of probing all
devices in a single pass identical to previous behavior.
Reviewed by: imp
Approved by: re (kib)
a _BBN value of 0 if it was for the first bridge encountered since some
older systems returned _BBN of 0 for all bridges. However, some newer
systems enumerate bridges with non-zero _BBN before bus 0 which is
perfectly valid. Handle both cases by trusting the first bridge that has
a _BBN of 0 and falling back to reading from non-standard config registers
only for subsequent bridges with a _BBN of 0. We also only perform this
check for segment (domain) 0. We assume that _BBN is always correct
for segments other than 0.
Tested by: Josef Moellers josef.moellers at fujitsu
MFC after: 1 week
