Create a special resource (= device special file) for management
of tags and maps, as well as for mapping memory into the address
space. DMA resources are managed using the PROTO_IOC_BUSDMA ioctl.
Part 1 implements tag creation, derivation and destruction.
BUS_PROBE_HOOVER is. Drivers like proto(4), when compiled into the
kernel or preloaded, will render your system useless by virtue of
attaching to your PCI busses.
Return BUS_PROBE_GENERIC instead. It's just the next priority up
from BUS_PROBE_HOOVER. No other meaning has been give to its use.
While BUS_PROBE_DEFAULT seems like a better candidate, it's hard
not to think that there must be some reason why these drivers
return -10000 in the first place.
Differential Revision: D2705
code update, with supporting changes in the CORE. Changes for the extended
media types, VF driver has virtual channel protocol changes, and some
register use corrections. This software change should be coordinated with
Firmware updates to your hardware, contact your support channels for that.
MFC after: 1 week
after decoding the instruction matches the one provided by hardware.
Prior to r283293 'vie->num_valid' used to contain the actual length of
the instruction whereas now it contains the maximum instruction length
possible. This introduced a bug when calculating a RIP-relative base address.
Fix this by using 'vie->num_processed' rather than 'vie->num_valid' as the
length of the emulated instruction.
Reported and tested by: tychon
MFC after: 1 week
interpreter list to avoid the problem of holding a non-sleep lock during
a page fault as reported by witness. In addition, it consistently uses
memset()/memcpy() instead of bzero()/bcopy() except in the case where
bcopy() is required (i.e. overlapping copy).
Differential Revision: https://reviews.freebsd.org/D2123
Submitted by: sson
MFC after: 2 weeks
Relnotes: Yes
A hole block pointer can be encountered at any level and the hole
can cover multiple data blocks, but we are reading the data blocks
one by one, so we care only about the current one.
PR: 199804
Reported by: Toomas Soome <tsoome@me.com>
Submitted by: Toomas Soome <tsoome@me.com> (earlier version)
Tested by: Toomas Soome <tsoome@me.com>
MFC after: 11 days
This is done if the installation mode is not requested or auto-detected.
This is useful when a kernel has to be loaded from multiple disks.
For example from a RAID-Z pool or a ZFS pool with multiple top level
vdevs.
Differential Revision: https://reviews.freebsd.org/D2723
Reviewed by: neel
MFC after: 8 days
The intel 7260 driver under development requires this - the scans come
in as normal frames but with the frequency provided. The correct method
is to have the driver provide flags (so we can determine if it's 11b
or 11g); this will have to do in the meantime.
Without this, the channel found is 11b, and no ERP (ie "11g") bits
are negotiated with the AP.
This allows the 7260 in 2ghz mode to operate in 11bg, rather than
just 11b.
Tested:
* intel 7260 driver, 11bg channels
According to the manual page, '-m' should create the user home
directory, however rigorous testing suggests it does not, and
it is unclear if this is an implementation or expectation issue.
Sponsored by: The FreeBSD Foundation
logic is now placed in the mmap hook implementation rather than requiring
it to be placed in sys/vm/vm_mmap.c. This hook allows new file types to
support mmap() as well as potentially allowing mmap() for existing file
types that do not currently support any mapping.
The vm_mmap() function is now split up into two functions. A new
vm_mmap_object() function handles the "back half" of vm_mmap() and accepts
a referenced VM object to map rather than a (handle, handle_type) tuple.
vm_mmap() is now reduced to converting a (handle, handle_type) tuple to a
a VM object and then calling vm_mmap_object() to handle the actual mapping.
The vm_mmap() function remains for use by other parts of the kernel
(e.g. device drivers and exec) but now only supports mapping vnodes,
character devices, and anonymous memory.
The mmap() system call invokes vm_mmap_object() directly with a NULL object
for anonymous mappings. For mappings using a file descriptor, the
descriptors fo_mmap() hook is invoked instead. The fo_mmap() hook is
responsible for performing type-specific checks and adjustments to
arguments as well as possibly modifying mapping parameters such as flags
or the object offset. The fo_mmap() hook routines then call
vm_mmap_object() to handle the actual mapping.
The fo_mmap() hook is optional. If it is not set, then fo_mmap() will
fail with ENODEV. A fo_mmap() hook is implemented for regular files,
character devices, and shared memory objects (created via shm_open()).
While here, consistently use the VM_PROT_* constants for the vm_prot_t
type for the 'prot' variable passed to vm_mmap() and vm_mmap_object()
as well as the vm_mmap_vnode() and vm_mmap_cdev() helper routines.
Previously some places were using the mmap()-specific PROT_* constants
instead. While this happens to work because PROT_xx == VM_PROT_xx,
using VM_PROT_* is more correct.
Differential Revision: https://reviews.freebsd.org/D2658
Reviewed by: alc (glanced over), kib
MFC after: 1 month
Sponsored by: Chelsio
Marcel Moolenaar