kib [Fri, 13 Dec 2013 05:54:30 +0000 (05:54 +0000)]
MFC r259042:
Do not force to run atexit handlers, which text comes from a dso owning
the handle passed to __cxa_finalize() but which are registered by other
dso, when the process is inside exit(3).
This is a series of commits inspired on Google's gcc-4.2.1 for
Android that were taken from the gcc pre-4.3 under the GPLv2.
gcc: Backport fixes for -W parentheses in C++
This fixes GCC 19564.
gcc: merge rs6000 change from FSF pre-gcc43
Don't set MASK_PPC_GFXOPT for 8540 or 8548.
Merge vrp-tree fix from gcc-4.3
Fix missed conversion from / to >> (GCC PR32521)
Merge in GCCr120505 to include definition of TREE_OVERFLOW_P
gcc: warn about integer overflow in constant expressions in the C++ frontend.
gcc: Add a new option -Wvla to warn variable length array.
libcpp: preprocessor speedup patches from upstream gcc.
gcc: add femit-struct-debug support to reduce Reduce dwarf debug size
gcc: Fix postreload-gcse treatment of call-clobbered registers.
gcc: Record some previous commits in the ChangeLog.gcc43 file.
andreast [Thu, 12 Dec 2013 13:00:07 +0000 (13:00 +0000)]
MFC: r258427, r258694
r258694:
Make RTAS calls, which call setfault() to recover from machine checks,
preserve any existing fault buffer. RTAS calls are meant to be safe from
interrupt context (and are indeed used there to implement the xics PIC
driver). Without this, calling into RTAS in interrupt context would have
the effect of clearing any existing onfault state of the interrupted
thread, potentially leading to a panic.
r258427:
For PCI<->PCI bridges, #address-cells may be 3. Allow this when parsing the
ibm,dma-window properties. This is especially a concern when
#ibm,dma-address-cells is not specified and we have to use the regular
#address-cells property.
andreast [Thu, 12 Dec 2013 12:36:40 +0000 (12:36 +0000)]
MFC: r258051, r258052
r258052:
Following the approach with ACPI DMAR on x86, split IOMMU handling into
a variant PCI bus instead of trying to shoehorn it into the PCI host bridge
adapter. Besides matching better the architecture on other platforms, this
also allows systems with multiple partitionable endpoints per PCI host
bridge to work correctly.
r258051:
Actually add IOMMU domain to the list of known mappings. This fixes a bug
where multiple devices in the same IOMMU domain would be allocated
conflicting mappings unless they also shared a DMA tag.
andreast [Thu, 12 Dec 2013 12:29:35 +0000 (12:29 +0000)]
MFC: r258722, r258757
r258722:
Give some output about the CPU clock on IBMPOWER machines, currently read
from OF. Linux does it similar, means they also read the OF values and
display them.
r258757:
Use the Open Firmware-based CPU frequency determination as a generic
fallback if we can't measure CPU frequency. This is also useful on a
variety of embedded systems using FDT.
andreast [Thu, 12 Dec 2013 12:17:20 +0000 (12:17 +0000)]
MFC: r256932, r256938, r256953
r256932:
Add a new function (OF_getencprop()) that undoes the transformation applied
by encode-int. Specifically, it takes a set of 32-bit cell values and
changes them to host byte order. Most non-string instances of OF_getprop()
should be using this function, which is a no-op on big-endian platforms.
r256938:
A few other common cases for encode-int decoding: OF_getencprop_alloc()
and OF_searchencprop(). I thought about using the element size parameter
to OF_getprop_alloc() to do endian-switching automatically, but it breaks
use with structs and a *lot* of FDT code (which can hopefully be moved to
these new APIs).
mdf [Thu, 12 Dec 2013 02:03:42 +0000 (02:03 +0000)]
MFC r258658:
Fix a segfault / internal compiler error.
Among other causes, when gcc throws a warning before parsing any tokens,
the cur_token pointer is at the beginning of malloc'd memory.
Dereferencing cur_token[-1] can cause a segfault.
Code taken from OpenBSD
http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/libcpp/errors.c
which was a more complete fix than the one I originally coded.
rmacklem [Wed, 11 Dec 2013 23:28:31 +0000 (23:28 +0000)]
MFC: r257901
Fix an NFSv4.1 client specific case where a forced dismount would hang.
The hang occurred in nfsv4_setsequence() when it couldn't find an
available session slot and is fixed by checking for a forced dismount
in progress and just returning for this case.
dumbbell [Wed, 11 Dec 2013 23:06:03 +0000 (23:06 +0000)]
MFC r259104:
drm/radeon: radeon_dp_i2c_aux_ch() must return 0 on FreeBSD
The code was unmodified compared to Linux and returned the amount of
received bytes from the i2c bus. This led to non-working i2c bus and
failure to eg. read monitor's EDID, if connected to DisplayPort.
andreast [Wed, 11 Dec 2013 22:36:20 +0000 (22:36 +0000)]
MFC r257991, r257992, 257993, 258504
r257991:
Consolidate Apple firmware hacks and improve them by switching on the
presence of mac-io devices in the tree, which uniquely identifies Apple
hardware.
r257992:
Allow OF_decode_addr() to also be able to map resources on big-endian
devices. To this end, make PCI device detection rely on the device_type
field rather than name, as per the standard.
r257993:
Make tsec work with the device tree present on the RB800. The previous code
assumed that the MDIO bus was a direct child of the Ethernet interface. It
may not be and indeed on many device trees is not. While here, add proper
locking for MII transactions, which may be on a bus shared by several MACs.
r258504:
Save and restore the trap vectors when doing OF calls on pSeries machines.
It turned out that on pSeries machines the call into OF modified the trap
vectors and this made further behaviour unpredictable.
With this commit I'm now able to boot multi user on a network booted
environment on my IntelliStation 285. This is a POWER5+ machine.
dumbbell [Wed, 11 Dec 2013 22:26:09 +0000 (22:26 +0000)]
MFC r259101:
drm/radeon: agp_info->ai_aperture_size is in bytes, not Mbytes
This fixes radeon_agp_init() and gtt_size is now correct. However, this
is not enough to make Radeon AGP cards work: ttm_agp_backend.c isn't
implemented yet.
andreast [Wed, 11 Dec 2013 22:00:03 +0000 (22:00 +0000)]
MFC r259007
Increase PHYS_AVAIL_SZ because on pSeries machines we can have many logical
regions which represent the total amount of memory. The size of these regions
is not the physical size of the chip but it is a logical one and it is given
by the OpenFirmware, it is selectable at boot time and varies between 16MB and
256MB in my case. There is an 'automatic' option which would select the size as
64MB in case you have around 16GB of RAM.
To make sure we can allocate RAM with the automatic option bump this value
of PHYS_AVAIL_SZ to 256.
andreast [Wed, 11 Dec 2013 21:37:32 +0000 (21:37 +0000)]
MFC r258615
Take care to handle the full 16 byte buffer in the get/put routines. Also,
skip the VTERM header once when receiving data from the hypervisor call when
we have a HVTERMPROT connection.
gjb [Wed, 11 Dec 2013 19:26:56 +0000 (19:26 +0000)]
MFC r257805, r257806, r257807, r257942:
r257805:
Add a 'mini-memstick.img' release target, which will use the
'bootonly.iso' components to create a smaller memory stick image.
This is useful for system recovery, where a full memstick.img image
is not necessarily needed (or wanted). In addition, it is possible
to do bootonly-style installation, where the base.txz, kernel.txz,
etc. are fetched from a remote source.
Provide backwards-compatible target (mini-memstick), to keep in sync
with the targets documented in release/Makefile.
r257806:
Remove extra target from 'memstick' that I forgot to remove before
previous commit.
r257807:
Update release(7) to include 'mini-memstick'.
pfg [Wed, 11 Dec 2013 19:25:17 +0000 (19:25 +0000)]
MFC r256448, r257029;
Make di_blocks unsigned in UFS1 as is the case already for UFS2.
Most of the code between UFS1 and UFS2 is shared so this change
is pretty safe. Not only this makes UFS1 and 2 consistent but it
also matches what NetBSD and MacOS X have for some years now.
UFS2: make di_extsize unsigned.
di_extsize is the EA size and as such it should be unsigned.
Adjust related types for consistency.
dim [Wed, 11 Dec 2013 07:43:30 +0000 (07:43 +0000)]
MFC r259111:
Use correct casts in gcc's emmintrin.h for the first arguments of the
following builtin functions:
* __builtin_ia32_pslldi128() takes __v4si instead of __v8hi
* __builtin_ia32_psllqi128() takes __v2di instead of __v8hi
* __builtin_ia32_psradi128() takes __v4si instead of __v8hi
This should fix the following errors when building the LINT kernel with
gcc:
sys/crypto/aesni/aesni_wrap.c:191: error: incompatible type for argument 1 of
'__builtin_ia32_psradi128'
sys/crypto/aesni/aesni_wrap.c:195: error: incompatible type for argument 1 of
'__builtin_ia32_pslldi128'
dim [Wed, 11 Dec 2013 07:34:34 +0000 (07:34 +0000)]
MFC r259100:
Pull in r196658 from upstream clang trunk:
CodeGen: Don't emit linkage on thunks that aren't emitted because they're
vararg.
This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense for
vararg functions.
[LLVM] PR18098.
This should fix clang "Broken module found, compilation aborted" errors when
building the qt4-based dvbcut port.
rmacklem [Wed, 11 Dec 2013 00:39:56 +0000 (00:39 +0000)]
MFC: r257598
During code inspection, I spotted that there was a code path where
CLNT_CONTROL() would be called on "client" after it was
released via CLNT_RELEASE(). It was unlikely that this
code path gets executed and I have not heard of any problem
report caused by this bug. This patch fixes the code so that
this cannot happen.
np [Wed, 11 Dec 2013 00:17:13 +0000 (00:17 +0000)]
MFC r258692 (gnn).
Add constants for use in interrogating various fiber and copper connectors
most often used with network interfaces.
The SFF-8472 standard defines the information that can be retrieved
from an optic or a copper cable plugged into a NIC, most often
referred to as SFP+. Examples of values that can be read
include the cable vendor's name, part number, date of manufacture
as well as running data such as temperature, voltage and tx
and rx power.
Copious comments on how to use these values with an I2C interface
are given in the header file itself.
nwhitehorn [Tue, 10 Dec 2013 22:55:22 +0000 (22:55 +0000)]
MFC r257345,257382,257388:
Implement extended LUN support. If PIM_EXTLUNS is set by a SIM, encode
the upper 32-bits of the LUN, if possible, into the target_lun field as
passed directly from the REPORT LUNs response. This allows extended LUN
support to work for all LUNs with zeros in the lower 32-bits, which covers
most addressing modes without breaking KBI. Behavior for drivers not
setting PIM_EXTLUNS is unchanged. No user-facing interfaces are modified.
Extended LUNs are stored with swizzled 16-bit word order so that, for
devices implementing LUN addressing (like SCSI-2), the numerical
representation of the LUN is identical with and without PIM_EXTLUNS. Thus
setting PIM_EXTLUNS keeps most behavior, and user-facing LUN IDs, unchanged.
This follows the strategy used in Solaris. A macro (CAM_EXTLUN_BYTE_SWIZZLE)
is provided to transform a lun_id_t into a uint64_t ordered for the wire.
This is the second part of work for full 64-bit extended LUN support and is
designed to a bridge for stable/10 to the final 64-bit LUN code. The
third and final part will involve widening lun_id_t to 64 bits and will
not be MFCed. This third part will break the KBI but will keep the KPI
unchanged so that all drivers that will care about this can be updated now
and not require code changes between HEAD and stable/10.
gavin [Tue, 10 Dec 2013 13:42:59 +0000 (13:42 +0000)]
Merge r257065 (by adrian) from head:
Fix a use-after-free node reference issue when waiting for a return
from a management frame transmission.
This bug is a bit loopy, so here goes.
The underlying cause is pretty easy to understand - the node isn't
referenced before passing into the callout, so if the node is deleted
before the callout fires, it'll dereference free'd memory.
The code path however is slightly more convoluted.
The functions _say_ mgt_tx - ie management transmit - which is partially
true. Yes, that callback is attached to the mbuf for some management
frames. However, it's only for frames relating to scanning and
authentication attempts. It helpfully drives the VAP state back to
"SCAN" if the transmission fails _OR_ (as I subsequently found out!)
if the transmission succeeds but the state machine doesn't make progress
towards being authenticated and active.
Now, the code itself isn't terribly clear about this.
It _looks_ like it's just handling the transmit failure case.
However, when you look at what goes on in the transmit success case, it's
moving the VAP state back to SCAN if it hasn't changed state since
the time the callback was scheduled. Ie, if it's in ASSOC or AUTH still,
it'll go back to SCAN. But if it has transitioned to the RUN state,
the comparison will fail and it'll not transition things back to the
SCAN state.
So, to fix this, I decided to leave everything the way it is and merely
fix the locking and remove the node reference.
The _better_ fix would be to turn this callout into a "assoc/auth request"
timeout callback and make the callout locked, thus eliminating all races.
However, until all the drivers have been fixed so that transmit completions
occur outside of any locking that's going on, it's going to be impossible
to do this without introducing LORs. So, I leave some of the evilness
in there.
dim [Tue, 10 Dec 2013 07:28:26 +0000 (07:28 +0000)]
MFC r259083:
For WARNS <= 3, change the clang warning flag -Wno-conversion to
-Wno-enum-conversion. In earlier clang versions (before 3.2), the
latter did not exist, and suppressing enum conversion warnings was
really the goal of this warning suppression flag.
This should enable the same kind of warning again as was fixed by
r259072 ("incompatible integer to pointer conversion passing 'Elf_Addr'
(aka 'unsigned int') to parameter of type 'void *'"), and which was only
emitted by gcc.
dim [Tue, 10 Dec 2013 07:25:25 +0000 (07:25 +0000)]
MFC r259053:
Pull in r196590 from upstream clang trunk (by rdivacky):
Move the body of GCCInstallationDetector ctor into an init() function
and call it from its only user. The linux toolchain. This saves quite
a lot of directory searching on other platforms.
See http://docs.freebsd.org/cgi/mid.cgi?51E6FAF5.3080802 for the
original discussion. With this fix, the search for gcc installations is
completely eliminated on FreeBSD.
MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and
r259103.
r257654:
cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns
out it's a write-only register with strange side effects on read.
r257772:
cxgbe(4): Tidy up the display for payload memory statistics (pm_stats).
r258441:
cxgbe(4): update the internal list of device features.
r258689:
Disable an assertion that relies on some code[1] that isn't in HEAD yet.
r258698:
cxgbetool: "modinfo" command to display SFP+ module information.
r258879:
cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program
scheduling classes in the chip and to bind tx queue(s) to a scheduling
class respectively. These can be used for various kinds of tx traffic
throttling (to force selected tx queues to drain at a fixed Kbps rate,
or a % of the port's total bandwidth, or at a fixed pps rate, etc.).
r259048:
Two new cxgbetool subcommands to set up scheduler classes and to bind
them to NIC queues.
r259103:
cxgbe(4): save a copy of the RSS map for each port for the driver's use.
peter [Sat, 7 Dec 2013 18:23:29 +0000 (18:23 +0000)]
Hoist all the mergeinfo up to the root in preparation for enforcing merges
to the root only. All MFC's were rerecorded to the root.
Going forward, if an MFC includes mergeinfo, it will need to be made to
the root and committed from the root. Merges with --ignore-ancestry
or diff | patch can go anywhere.
The mergeinfo in HEAD is in a bad state from years of neglect and manual
tampering and this was branched into 10.x. This confuses the coalescing
code and prevents it from doing its job.
cperciva [Fri, 6 Dec 2013 20:48:53 +0000 (20:48 +0000)]
MFC r258894: Make rc(8) re-source rc.conf upon receipt of SIGALRM.
The rc system aggressively caches the contents of /etc/rc.conf in order to
improve boot performance; this produces arguably astonishing (non-)results
if /etc/rc.conf is modified during the boot process. This commit provides
a mechanism for explicitly requesting that rc.conf be reloaded.
royger [Thu, 5 Dec 2013 18:08:05 +0000 (18:08 +0000)]
MFC 258176:
Fix accounting for hw.realmem on the i386 and amd64 platforms.
sys/i386/i386/machdep.c:
sys/amd64/amd64/machdep.c:
The value reported by FreeBSD as "real memory" when booting
doesn't match what is later reported by sysctl as hw.realmem.
This is due to the fact that the value printed during the
boot process is fetched from smbios data (when possible),
and accounts for holes in physical memory. On the other
hand, the value of hw.realmem is unconditionally set to be
one larger than the highest page of the physical address
space.
Fix this by setting hw.realmem to the same value printed
during boot, this makes hw.realmem honour it's name and
account properly for physical memory present in the system.
Submitted by: Roger Pau Monné
Reviewed by: gibbs
Approved by: gibbs (mentor)
Approved by: re (gjb)
royger [Thu, 5 Dec 2013 18:06:12 +0000 (18:06 +0000)]
MFC 257876:
On XenServer the "halt" message is used instead of "poweroff", which
makes FreeBSD halt but not poweroff (as expected when issuing a
shutdown from the VM manager). Fix this by using the same handler
for both "halt" and "poweroff".
NB: The "halt" signal seems to be used on XenServer only. The OSS
Xen toolstack (xl) uses "poweroff" instead.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
Approved by: gibbs (mentor)
Approved by: re (gjb)
rodrigc [Wed, 4 Dec 2013 07:55:49 +0000 (07:55 +0000)]
MFC 258591
In vnet_route_uninit(), free some memory that is allocated in vnet_route_init().
To reproduce the problem:
(1) Take a GENERIC kernel config, and add options for: VIMAGE, WITNESS,
INVARIANTS.
(2) Run this command in a loop:
jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo
rodrigc [Wed, 4 Dec 2013 07:50:18 +0000 (07:50 +0000)]
MFC r258588
In sys/netpfil/ipfw/ip_fw_nat.c:vnet_ipfw_nat_uninit() we call "IPFW_WLOCK(chain);".
This lock gets deleted in sys/netpfil/ipfw/ip_fw2.c:vnet_ipfw_uninit().
Therefore, vnet_ipfw_nat_uninit() *must* be called before vnet_ipfw_uninit(),
but this doesn't always happen, because the VNET_SYSINIT order is the same for both functions.
In sys/net/netpfil/ipfw/ip_fw2.c and sys/net/netpfil/ipfw/ip_fw_nat.c,
IPFW_SI_SUB_FIREWALL == IPFW_NAT_SI_SUB_FIREWALL == SI_SUB_PROTO_IFATTACHDOMAIN
and
IPFW_MODULE_ORDER == IPFW_NAT_MODULE_ORDER
Consequently, if VIMAGE is enabled, and jails are created and destroyed,
the system sometimes crashes, because we are trying to use a deleted lock.
To reproduce the problem:
(1) Take a GENERIC kernel config, and add options for: VIMAGE, WITNESS,
INVARIANTS.
(2) Run this command in a loop:
jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo
(see http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021280.html )
Fix the problem by increasing the value of IPFW_NAT_SI_SUB_FIREWALL,
so that vnet_ipfw_nat_uninit() runs after vnet_ipfw_uninit().
rodrigc [Wed, 4 Dec 2013 07:46:53 +0000 (07:46 +0000)]
MFC r258737
In keg_dtor(), print out the keg name in the "Freed UMA keg was not empty"
message printed to the console. This makes it easier to track down
the source of certain memory leaks.
tuexen [Tue, 3 Dec 2013 20:55:37 +0000 (20:55 +0000)]
MFC r258574:
Only initialize some mutexes for the default VNET.
In r208160, sctp_it_ctl was made a global variable, across all VNETs.
However, sctp_init() is called for every VNET that is created. This results
in the same global mutexes which are part of sctp_it_ctl being initialized. This can result
in crashes if many jails are created.
To reproduce the problem:
(1) Take a GENERIC kernel config, and add options for: VIMAGE, WITNESS,
INVARIANTS.
(2) Run this command in a loop:
jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo
(see http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021280.html )
Witness will warn about the same mutex being initialized.
Fix the problem by only initializing these mutexes in the default VNET.
MFC r258765:
In
http://svnweb.freebsd.org/changeset/base/258221
I introduced a bug which initialized global locks
whenever the SCTP stack initialized. This was fixed in
http://svnweb.freebsd.org/changeset/base/258574
by rodrigc@. He just initialized the locks for
the default vnet. This fix reverts to the old
behaviour before r258221, which explicitly makes
sure it is only called once, because this works also on
other platforms.
kib [Tue, 3 Dec 2013 19:42:46 +0000 (19:42 +0000)]
MFC r258663:
Use sysctl KERN_PROC_SIGTRAMP to retrieve the signal trampoline
location for the native amd64 ABI. This fixes unwinding over the
signal frame after trampoline was moved to the shared page.
bdrewery [Fri, 29 Nov 2013 21:13:30 +0000 (21:13 +0000)]
MFC r258347,r258349:
Support SNI in libfetch
SNI is Server Name Indentification which is a protocol for TLS that
indicates the host that is being connected to at the start of the
handshake. It allows to use Virtual Hosts on HTTPS.
PR: kern/183583
Approved by: bapt (implicit)
Approved by: re (gjb)
gjb [Fri, 29 Nov 2013 19:44:30 +0000 (19:44 +0000)]
MFC r258537, r258587:
r258537 (hrs):
Add ICONV_{GET,SET}_ILSEQ_INVALID iconvctl. GNU iconv returns
EILSEQ when there is an invalid character in the output codeset
while it is valid in the input. However, POSIX requires iconv()
to perform an implementation-defined conversion on the character.
So, Citrus iconv converts such a character to a special character
which means it is invalid in the output codeset.
This is not a problem in most cases but some software like libxml2
depends on GNU's behavior to determine if a character is output
as-is or another form such as a character entity (&#NNN;).
r258587 (peter):
Move the iconv wrapper source from libc_nonshared to libc/iconv so
that it is all in the one place again. Rename libc/iconv/iconv.c
to bsd_iconv.c. Compile the wrappers into libc.a so that
WITHOUT_DYNAMICROOT works again.
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
delphij [Thu, 28 Nov 2013 22:06:37 +0000 (22:06 +0000)]
MFC r257879:
Fix typo in r256646: We want to generate lists of directories in
INDEX-OLD and INDEX-NEW and compare them, not generate the same
list of directories from INDEX-OLD twice...
Pointy hats to: cperciva & everybody who didn't proofread
EN-13:04 enough
Errata Notice: FreeBSD-EN-13:05.freebsd-update
Approved by: re (gjb)
dumbbell [Thu, 28 Nov 2013 10:04:53 +0000 (10:04 +0000)]
MFC r258549 and r258553:
drm: Dereference pointers given to qsort_r()'s cmp callback
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.
Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.
This bug triggered an infinite loop in KDE/xserver:
1. KDE has a kded module called "randrmonitor" which queries xserver
for current monitors at startup and then listens to RandR
notifications from xserver.
2. xserver handles the query from "randrmonitor" by polling the
video device using the "drm_mode_getconnector()" ioctl. This
ioctl returns a list of connectors and, for those with a
connected monitor, the available modes. Each modes list is sorted
by the kernel before returning. When xserver gets the connectors
list, it sorts the modes lists again.
In the case of this bug, when two modes are equal (in xserver's
compare function PoV), their order is kept stable (ie. the
kernel order is kept for those two modes). And because the list
was shuffled by the kernel, the order of two equal modes was
frequently changed in the final modes list in xserver.
3. xserver compares the returned connectors list with the list
obtained earlier. In particular, it compares the sorted
modes lists for each connector. If a property of a connector
changes (eg. modes), xserver sends a "RRNotify_OutputChange"
notification.
Because of the change of order between equal modes, xserver sent
a notification after each polling of the connectors.
4. "randrmonitor" receives a notification, triggered by its query. The
notification doesn't contain the new connectors list, therefore, it
asks for the new list using the same function: go back to step #2.
dumbbell [Thu, 28 Nov 2013 09:30:05 +0000 (09:30 +0000)]
MFC r258262:
drm: Support DRM_CAP_TIMESTAMP_MONOTONIC capability
This fixes DPMS with KDE and radeonkms. Without this, the display would
freeze when the monitor is put into sleep state, and only resumes after
several dozens of minutes once the monitor is powered on again.
Tested by: Mathias Picker <Mathias.Picker@virtual-earth.de>
Approved by: re (kib)
brooks [Tue, 26 Nov 2013 16:13:48 +0000 (16:13 +0000)]
MFC: r258456
Fix mergemaster -U by forcing FreeBSD 9 compatiblity in mtree when mtree is
nmtree.
The mtree output used by mergemaster in this case was clearly not meant for
computer consumption and an approach based on -f <file1> -f <file2> would
probably be a better idea, but this is a minimal change.
brooks [Tue, 26 Nov 2013 16:12:40 +0000 (16:12 +0000)]
MFC r258437:
Sync with NetBSD. The functional change is to make the output when
comparing a directory to an mtree file more compatible with fmtree when
FreeBSD 9 compatiblity mode is on. This output is clearly intended for
humans not computers, but some tools such as mergemaster's -U option rely
on it.
gibbs [Tue, 26 Nov 2013 14:50:39 +0000 (14:50 +0000)]
[Forced commit to correct checkin comment for r256757]
MFC: r256423
Allow FreeBSD to be booted from CDROM media on XenServer 6.2 and
prior releases.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
Approved by: re (gjb)
sys/dev/xen/blkfront/blkfront.c:
On XenServer versions up to an including 6.2, paravirtualized
CDROM support is broken. When running in an HVM domain,
ignore paravirtualized instances of CDROM media, and instead
rely on native drivers attaching to emulated hardware. This
functions correctly on all currently known Xen based
platforms.
------------------------------------------------------------------------
dim [Mon, 25 Nov 2013 22:56:46 +0000 (22:56 +0000)]
MFC r258350:
Pull in r191896 from upstream llvm trunk:
CaptureTracking: Plug a loophole in the "too many uses" heuristic.
The heuristic was added to avoid spending too much compile time in a
specially crafted test case (PR17461, PR16474) with many uses on a
select or bitcast instruction can still trigger the slow case. Add a
check for that case.
This only affects compile time, don't have a good way to test it.
This fixes the excessive compile time spent on a specific file of the
graphics/rawtherapee port.
avg [Mon, 25 Nov 2013 16:31:31 +0000 (16:31 +0000)]
MFC r258353: zfs page_busy: fix the boundaries of the cleared range
This is a fix for a regression introduced in r246293.
vm_page_clear_dirty expects the range to have DEV_BSIZE aligned boundaries,
otherwise it extends them. Thus it can happen that the whole page is
marked clean while actually having some small dirty region(s).
This commit makes the range properly aligned and ensures that only
the clean data is marked as such.
It would interesting to evaluate how much benefit clearing with DEV_BSIZE
granularity produces. Perhaps instead we should clear the whole page
when it is completely overwritten and don't bother clearing any bits
if only a portion a page is written.
emaste [Mon, 25 Nov 2013 15:58:48 +0000 (15:58 +0000)]
MFC r258135: x86: Allow users to change PSL_RF via ptrace(PT_SETREGS...)
Debuggers may need to change PSL_RF. Note that tf_eflags is already stored
in the signal context during signal handling and PSL_RF previously could
be modified via sigreturn, so this change should not provide any new
ability to userspace.
For background see the thread at:
http://lists.freebsd.org/pipermail/freebsd-i386/2007-September/005910.html
emaste [Mon, 25 Nov 2013 15:54:18 +0000 (15:54 +0000)]
MFC r258426: libexecinfo: Include terminating null in byte count
Otherwise, a formatted string with a strlen equal to the remaining
buffer space would have the last character omitted (because vsnprintf
always null-terminates), and later the assert in backtrace_symbols_fmt
would fail.
gber [Mon, 25 Nov 2013 15:34:57 +0000 (15:34 +0000)]
MFC: r258387,r258425
Split raw reading/programming into smaller chunks to avoid allocating too
big chunk of kernel memory. Validate size of data. Add error handling to
avoid calling copyout() when data has not been read correctly. Also MFC of
change r258425 which fixes problem introduced by r258387.
Reviewed by: zbb
Reported by: x90c <geinblues@gmail.com>
Approved by: re
cperciva [Sun, 24 Nov 2013 23:30:23 +0000 (23:30 +0000)]
MFC r258086:
Strip the -pN patch level from the VERSION string which gets encoded into
CTF data. Otherwise FreeBSD Update builds think every kernel file has
changed every time there's a security advisory, since the FreeBSD Update
build code isn't smart enough to look inside CTF data to ignore those
changes.
tijl [Sat, 23 Nov 2013 12:17:05 +0000 (12:17 +0000)]
MFC r258316:
Bug fixes in iconv(3) UTF-7 support.
- Add ' to the list of directly encoded characters and * to the list of
optionally directly encoded characters as per RFC 2152.
- In _citrus_UTF7_mbtoutf16 on end of input when the next output character
has only been partially decoded, save a copy of the buffer of input
characters (not just its length). On the next call with more input
characters this buffer is reprocessed together with the new input to
form a fully decoded output character.
- At the end of a base64 encoded sequence fully discard '-' (BASE64_OUT)
by decrementing psenc->chlen and i. This is needed to make room in
psenc->ch (input buffer) in case the next input character starts a new
base64 encoded sequence. And also, if this is the end of input and no
output character can be returned, this brings the encoder in the initial
state as indicated by _citrus_UTF7_stdenc_get_state_desc_generic which
is used by the caller to distinguish between no output and partial
output.
- In _citrus_UTF7_mbrtowc_priv pass the s parameter (input pointer)
directly to _citrus_UTF7_mbtoutf16 instead of a copy (s0). This way s
is updated correctly in case of errors.
- In _citrus_UTF7_mbrtowc_priv when called with psenc->surrogate set
(previous call did not have enough input), retrieve the previously
decoded UTF-16 character from (psenc->cache >> psenc->bits) instead of
(psenc->cache >> 2).
projects / FreeBSD / stable / 10.git / log