dcphy(4) (CID 9283).
- In dc_detach(), check whether ifp is NULL as dc_attach() may call the
former without ifp being allocated (CID 4288).
Found with: Coverity Prevent(tm)
!DC_IS_ADMTEK in dc_miibus_statchg(). This change broke link
establishment of Intel 21143 with dcphy(4) where it stuck in
"ability detect" state without completing auto-negotiation.
Also nuke dc_if_media as it's not actually used.
Submitted by: marius
Create std.XLP for configuration options, which is included by the
conf files. The files XLP, XLPN32 and XLP64 will have mostly ABI related
options.
Also move uart and pci to mips/nlm/std.xlp since all XLP configurations
needs these devices.
Obtained from: prabhath at netlogicmicro com (intial version)
p->p_boundary_count. Race could cause the execve(2) from the threaded
process to hung since thread boundary counter was incorrect and
single-threading never finished.
Reported by: pluknet, pho
Tested by: pho
MFC after: 1 week
Tested on Qemu/KVM, VirtualBox, and BHyVe.
Currently built as modules-only on i386/amd64. Man pages not yet hooked
up, pending review.
Submitted by: Bryan Venteicher bryanv at daemoninthecloset dot org
Reviewed by: bz
MFC after: 4 weeks or so
for the ath(4) driver.
Currently, there's nothing stopping reset, channel change and general
TX/RX from overlapping with each other. This wasn't a big deal with
pre-11n traffic as it just results in some dropped frames.
It's possible this may have also caused some inconsistencies and
badly-setup hardware.
Since locks can't be held across all of this (the Linux solution)
due to LORs with the network stack locks, some state counter
variables are used to track what parts of the code the driver is
currently in.
When the hardware is being reset, it disables the taskqueue and
waits for pending interrupts, tx, rx and tx completion before
it begins the reset or channel change.
TX and RX both abort if called during an active reset or channel
change.
Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS
is set. Instead, completed TX and RX frames are passed back up to
net80211 before the reset occurs.
This is not without problems:
* Raw frame xmit are just dropped, rather than placed on a queue.
The net80211 stack should be the one which queues these frames
rather than the driver.
* It's all very messy. It'd be better if these hardware operations
were serialised on some kind of work queue, rather than hoping
they can be run in parallel.
* The taskqueue block/unblock may occur in parallel with the
newstate() function - which shuts down the taskqueue and restarts
it once the new state is known. It's likely these operations should
be refcounted so the taskqueue is restored once no other areas
in the code wish to suspend operations.
* .. interrupt disable/enable should likely be refcounted as well.
With this work, the driver does not drop frames during stuck beacon
or fatal errors and thus 11n traffic continues to run correctly.
Default and full resets however do still drop frames and it's possible
this may occur, causing traffic loss and session stalls.
Sponsored by: Hobnob, Inc.
It blocks CAM SWI usage on requests completion, unneeded because of polling
and denied during kernel dumping because of blocked scheduler.
Before r198899 there was periph flag CAM_PERIPH_POLLED, but that was wrong,
because there is whole SIM is polled or handled by SWI, not a single periph.
Tested by: kib
MFC after: 1 month
completely skipping them, create ahcich devices for them to allocate unit
numbers, but mark them as disabled to prevent driver probe and attach.
Last time some BIOSes tend to report unused channels as "not implemented".
This change makes ahcichX devices numbering consistent, independently of
connected disks. It makes per-channel driver hints usable and CAM devices
wiring possible on such systems.
for having kernel text non-writable, because we still need to
apply relocations. On top of that, the PBVM page table has all
pages marked as RWX, so it's an inconsistency to begin with.
The pmap update_page/invalidate_page/invalidate_all operations has to be
done only on active cpus. In the simplest case, if the process is not
active on any other CPUs, we can just do the operation on the current CPU.
This change replaces the call to smp_rendezvous() for these operations with
smp_rendezvous_cpus() in case there more than one active CPU, or with a direct
function call if there is just one active CPU.
This change give significant performance increase in fork/exec benchmarks
on XLR/XLS/XLP with 32 cpus.
Reviewed by: alc
I/O from userspace, capable of line rate at 10G, see
http://info.iet.unipi.it/~luigi/netmap/
At this time I am bringing in only the generic code (sys/dev/netmap/
plus two headers under sys/net/), and some sample applications in
tools/tools/netmap. There is also a manpage in share/man/man4 [1]
In order to make use of the framework you need to build a kernel
with "device netmap", and patch individual drivers with the code
that you can find in
sys/dev/netmap/head.diff
The file will go away as the relevant pieces are committed to
the various device drivers, which should happen in a few days
after talking to the driver maintainers.
Netmap support is available at the moment for Intel 10G and 1G
cards (ixgbe, em/lem/igb), and for the Realtek 1G card ("re").
I have partial patches for "bge" and am starting to work on "cxgbe".
Hopefully changes are trivial enough so interested third parties
can submit their patches. Interested people can contact me
for advice on how to add netmap support to specific devices.
CREDITS:
Netmap has been developed by Luigi Rizzo and other collaborators
at the Universita` di Pisa, and supported by EU project CHANGE
(http://www.change-project.eu/)
The code is distributed under a BSD Copyright.
[1] In my opinion is a bad idea to have all manpage in one directory.
We should place kernel documentation in the same dir that contains
the code, which would make it much simpler to keep doc and code
in sync, reduce the clutter in share/man/ and incidentally is
the policy used for all of userspace code.
Makefiles and doc tools can be trivially adjusted to find the
manpages in the relevant subdirs.
controllers.
More and more RealTek controllers started to implement EEE feature.
Vendor driver seems to load a kind of firmware for EEE with
additional PHY fixups. It is known that the EEE feature may need
ASPM support. Unfortunately there is no documentation for EEE of
the controller so enabling ASPM may cause more problems.
This enables locking consumers to pass their own structures around as const and
be able to assert locks embedded into those structures.
Reviewed by: ed, kib, jhb
Unnecessarily complex LE format used on Marvell controller was
main reason not to enable 64bit DMA addressing in driver. If high
32bit address of DMA address of TX/RX buffer is changed, driver has
to generate a new LE. In TX path, driver will keep track of lastly
used high 32bit address of DMA address and generate a new LE
whenever it sees high address change in the DMA address. In RX path,
driver will always use two LEs to specify 64bit DMA address of RX
buffer. If the high 32bit address of DMA address of RX buffer is
the same as previous DMA address of RX buffer, driver does not have
to use two LEs but driver will use two LEs for simplicity in RX
ring management.
One of draw back for switching to 64bit DMA addressing is that the
large amount of LEs are used to specify 64bit DMA address such that
number of available LEs for TX/RX buffers are considerably reduced.
To mitigate the issue, increase number of available LEs from 256 to
384 for TX and from 256 to 512 for RX. For 32bit architectures,
msk(4) does not use 64bit DMA addressing to save resources.
Tested by: das
based on Solarflare SFC9000 family controllers. The driver supports jumbo
frames, transmit/receive checksum offload, TCP Segmentation Offload (TSO),
Large Receive Offload (LRO), VLAN checksum offload, VLAN TSO, and Receive Side
Scaling (RSS) using MSI-X interrupts.
This work was sponsored by Solarflare Communications, Inc.
My sincere thanks to Ben Hutchings for doing a lot of the hard work!
Sponsored by: Solarflare Communications, Inc.
MFC after: 3 weeks
yielding a new public interface, vm_page_alloc_contig(). This new function
addresses some of the limitations of the current interfaces, contigmalloc()
and kmem_alloc_contig(). For example, the physically contiguous memory that
is allocated with those interfaces can only be allocated to the kernel vm
object and must be mapped into the kernel virtual address space. It also
provides functionality that vm_phys_alloc_contig() doesn't, such as wiring
the returned pages. Moreover, unlike that function, it respects the low
water marks on the paging queues and wakes up the page daemon when
necessary. That said, at present, this new function can't be applied to all
types of vm objects. However, that restriction will be eliminated in the
coming weeks.
From a design standpoint, this change also addresses an inconsistency
between vm_phys_alloc_contig() and the other vm_phys_alloc*() functions.
Specifically, vm_phys_alloc_contig() manipulated vm_page fields that other
functions in vm/vm_phys.c didn't. Moreover, vm_phys_alloc_contig() knew
about vnodes and reservations. Now, vm_page_alloc_contig() is responsible
for these things.
Reviewed by: kib
Discussed with: jhb
can be enabled via the hw.mfi.msi tunable. Many mfi(4) controllers also
support MSI-X, but in testing it seems that many adapters do not work with
MSI-X but do work with MSI.
MFC after: 2 weeks
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered
a couple of misplaced opcode definitions and some missing continual mbox command
cases, so might as well update them here.
maximum IP datagram size (65535 bytes) +
Ethernet header size (14 bytes) +
2 * VLAN tag size (4 bytes) [1].
[1] We need to multiply by 2 to account for the double VLAN tag
provision added in IEEE 802.1ad.
Submitted by: David Somayajulu (david.somayajulu qlogic.com)
MFC after: 4 days
for regular files. Since other file types don't write into the
buffer cache, calling ncl_flush() is almost a no-op. However, it does
clear the NMODIFIED flag and this shouldn't be done by nfs_fsync() for
directories.
MFC after: 2 weeks
directly from g7, the pcpu pointer. This guarantees correct behavior
when the thread migrates to a different CPU.
Commit message stolen from r205431. Additional testing by Peter Jeremy.
MFC after: 3 days
