The default behavior is to infer the logical and physical sector sizes from
the block device backend. However older versions of Windows only work with
specific logical/physical combinations:
- Vista and Windows 7: 512/512
- Windows 7 SP1: 512/512 or 512/4096
For this reason allow the sector size to be specified using the following
block device option: sectorsize=logical[/physical]
Reported by: Leon Dang (ldang@nahannisys.com)
Reviewed by: grehan
MFC after: 2 weeks
For RE purposes, we use the default (/R within the chroot), so
this helps avoid copying files multiple times and xz(1)-compressing
additional times when not needed.
Again, this Makefile is not for general consumption.
Sponsored by: The FreeBSD Foundation
a 474-line kludge of a shell script to pre-create the directory
hierarchy on ftp-master.
This is not in any way connected to the build, and there is no
intention to do so. This only intent here is to try to make
things a little bit easier for me. But I've probably just made
things worse.
Sponsored by: The FreeBSD Foundation
not one that needs to be negotiated. Use the host capabilities
field and not the negotiated field when verifying that indirect
descriptors are supported.
Found with the Redhat Windows viostor driver, which clears
the indirect capability in the negotiated caps and then starts
using them.
Reported and tested by: Leon Dang (ldang@nahannisys.com)
MFC after: 2 weeks
Summary:
The Freescale PCIe Root Complex shows up as a Processor class device, PowerPC
subclass, so the generic PCI code ignores it for a bridge. This adds support
for it.
As part of this, update the Freescale PCI hostbridge driver, to allow probing
beyond the root complex, instead of only allowing "proper" PCI-PCI bridges.
Reviewers: #powerpc, marcel, nwhitehorn
Reviewed By: nwhitehorn
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D2442
Relnotes: yes
because the i386 pmap on which the new armv6 pmap is based had it, and in
r281707 pmap_lazyfix() was removed from the i386 pmap.
Discussed with: kib
Submitted by: Michal Meloun (via Svatopluk Kraus)
main ARMv6 target, the Raspberry Pi, doesn't support Thumb-2.
This as been tested with a Thumb-2 userland, however building one is
currently unsupported as there are known toolchain issues breaking some
binaries. Further work will also be needed to decide on the method of
selecting which instruction set to build for, and to benchmark both to
find how building everything as Thumb-2 will affect performance.
Relnotes: yes
Introduce further adjustments to the renaming of libmd
symbols: make sure that we do not generate dangling weak
aliases, as this causes build failures on MIPS.
Tested by: sbruno
This allows to ensure that we do not write to a file that was opened
for reading only or vice versa.
Also, use the correct capability in in zfs_ioc_send_new().
Differential Revision: https://reviews.freebsd.org/D2382
Reviewed by: delphij
MFC after: 17 days
Sponsored by: ClusterHQ
positive value since it adds the current tick to its result. This differs
from the behaviour in Linux, whose implementation does not add the extra
tick, so subtract the extra tick in the OFED compat layer implementation.
This addresses some incorrect handling of IB MAD timeouts, since some IB
code depends on msecs_to_jiffies(0) returning 0.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
results.
Right now the scan infrastructure assumes the channel is under net80211
control, and that when receiving beacon frames for scanning, the
current channel is indeed what ic_curchan is set to.
But firmware NICs with firmware scan support need more than this -
they can do background scans whilst hiding the off-channel behaviour
from net80211. Ie, net80211 still thinks everything is associated
and on the main channel, but it's getting scan results from all the
background traffic.
However sta_add() pays attention to ic_curchan and discards scan
results that aren't on the right channel. CCK beacon frames can be
decoded from adjacent channels so the receive path and sta_add
discard these as appropriate. This is fine for software scanning
like for ath(4), but not for firmware NICs. So with those, the
whole concept of background firmware scanning won't work without
major hacks (eg, overriding ic_curchan before calling the beacon
input / scan add.)
As part of my scan overhaul, modify sta_add() and the scan_add()
APIs to take an explicit current channel. The normal RX path
will set it to ic_curchan so it's a no-op. However, drivers may
decide to (eventually!) override the scan method to set the
"right" current channel based on what the firmware reports the
scan state is.
So for example, iwn, rsu and other NICs will eventually do this:
* driver issues scan start firmware command;
* firmware sends a "scan start on channel X" notify;
* firmware sends a bunch of beacon RX's as part of
the scan results;
* .. and the driver will replace scan_add() curchan with channel X,
so scan results are correct.
* firmware sends a "scan start on channel Y" notify;
* firmware sends more beacons...
* .. the driver replaces scan_add() curchan with channel Y.
Note:
* Eventually, net80211 should eventually grow the idea of a per-packet
current channel. It's possible in various modes (eg WAVE, P2P, etc)
that individual frames can come in from different channels and that
is under firmware control rather than driver/net80211 control, so
we should support that.
lies within the last block of the bit set and no bits are set beyond the
offset, terminate the search immediately instead of continuing as though
there are further blocks in the set and subsequently returning an incorrect
result.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
list of pending dynamic type definitions, a match on the type name is not
sufficient - we need to compare the type encodings as well. For example,
bitfields have their own distinct type definitions which share the name of
the underlying integer type, and these types aren't generally
interchangeable.
This bug was causing the following libdtrace error when attempting to trace
the th_flags member of a struct tcphdr:
cg: bad field: off 104 type <32877> bits 539620016
Reported by: rwatson
MFC after: 3 weeks
(Makefile.inc1): add dependency of xinstall on libmd to
avoid failure of parallel bootstrap.
(lib/libmd/*.h): do not redefine symbols if already
defined as macros (libcrypt uses the same sources internally,
redefining symbols with a prefix of its own).
Fixes build failures caused by previous change to libmd.
Reported by: ian
Pointy hat to: thomas
Several improvements to the Synaptics driver to support
semi-multitouch trackpads and some other fixes:
- Two finger scrolling support for "semi-MT" touchpads. Those include
many of the older Synaptics touchpads before "true" multitouch support
(indicated by capMultiFinger). Semi-MT touchpads can report a second
finger position, but the X or Y coordinate may be swapped with some
coordinate of the first finger. This is a result of how the hardware
works internally. Therefore, all that can be reliably extracted is the
bounding box of the two finger positions. Semi-MT touchpads can be
recognized by the capAdvancedGestures capability bit. After setting the
mode byte, advanced gestures mode has to be enabled. Then, data packets
compatible with the capMultiFinger format are sent, so the same two
finger scrolling code can be leveraged. Enabling advanced gestures mode
on true multitouch touchpads should be harmless. Linux seems to always
enable advanced gestures mode.
- Put mode setting logic into own functions synaptics_preferred_mode()
and synaptics_set_mode() to have this in one place.
synaptics_passthrough_on() and synaptics_passthrough_off() currently
always use 0xc1 as the mode byte, which may be wrong for touchpads that
don't have capExtended.
- Expose X and Y resolution of touchpad to userland. Also expose minimum
and maximum X and Y coordinates. This is useful for programs in
userspace that read raw PSM packets (with PSM_LEVEL_NATIVE enabled) and
need to interpret the coordinates.
- Also send "extended w mode" packets (see section 3.2.9 of
511-000275-01_RevB.pdf) to userspace if PSM_LEVEL_NATIVE is enabled.
This is useful for userspace programs/drivers such as
xf86-input-synaptics that can handle these packets.
- Fix parsing of nExtendedQueries, and request extended/continued
capability bits depending on this value.
- capReportsMax, capClearPad, capAdvancedGestures and capCoveredPad must
be extracted from status[0] and not status[2], I think.
Submitted by: Jan Kokemüller jan.kokemueller at gmail.com
static-linked to run at a fixed position, is still installed to maintain
compatibility with existing configurations. The makefile now also creates
and installs ubldr.bin, a stripped binary (no elf headers) with an entry
point offset of 0 that can be loaded by u-boot at any address and launched
with "go ${loadaddr}".
To use ubldr.bin, U-Boot must still be built with the CONFIG_API option,
but no longer needs the CONFIG_ELF option.
recv() and send()'s calls to recvfrom() and sendto() are much like
waitpid()'s call to wait4(), and likewise need not allow PLT interposing on
the called function.
return a value.
Despite what I said in my prior commit, it turns out this one platform
was checking the return value from the old self-reloc code (which returned
a hard-coded 0).
The function was defined as taking 4 parameters and returning EFI_STATUS,
but all existing callers (in asm code) passed only two parameters and don't
use the return value. The function signature now matches that usage, and
doesn't refer to efi-specific types.
Parameters and variables now use the cannonical typenames set up by elf.h
(Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will
prevent suprises as new platforms come along and use this code.
The function was renamed from _reloc() to self_reloc() to emphasize its
difference from the other elf relocation code found in boot/common.
Differential Revision: https://reviews.freebsd.org/D2490
Add a prefix to all symbols in libmd to avoid incompatibilites
with same-named, but not binary compatible, symbols from libcrypto.
Also introduce Weak aliases to avoid the need to rebuild dependent
binaries and a major version bump.
PR: 199119
Differential Revision: D2216
Reviewed by: roberto, delphij
MFC after: 2 weeks
and BSD-style escape-control-char sequences in the input stream.
Submitted by: schwarze at OpenBSD
Discussed with: schwarze at OpenBSD
Obtained from: OpenBSD
