marius [Tue, 29 Jul 2014 13:08:56 +0000 (13:08 +0000)]
MFC: r269050 (partial)
Copying and zeroing pages via temporary mappings involves updating the
corresponding page tables followed by accesses to the pages in question.
This sequence is subject to the situation exactly described in the "AMD64
Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23,
"7.3.1 Special Coherency Considerations" [1, p. 171 f.]. Therefore, issuing
the INVLPG right after modifying the PTE bits is crucial.
For pmap_copy_page(), this has been broken in r124956.
MFC r268735:
Improve support for Intel Lynx Point USB 3.0 controllers by using the
USB 2.0 port mask in addition to the USB 3.0 port mask. The hardware
does not always accept when writing -1U to the port switching
registers.
MFC 255284:
It was reported via email that the cu_sent field used by the
krpc client side UDP was observed as way out of range and
caused the rpc.lockd daemon to hang trying to do an RPC.
Inspection of the code found two places where the RPC request
is re-queued, but the value of cu_sent was not incremented.
Since cu_sent is always decremented when the RPC request is
dequeued, I think this could have caused cu_sent to go out of
range. This patch adds lines to increment cu_sent for these
two cases.
Initialize r_flags the same way in all cases using a sanitized copy of
flags that has several bits cleared. The RF_WANTED and RF_FIRSTSHARE
bits are invalid in this context, and we want to defer setting RF_ACTIVE
in r_flags until later. This should make rman_get_flags() return
the correct answer in all cases.
Add a KASSERT() to catch callers which incorrectly pass the RF_WANTED
or RF_FIRSTSHARE flags.
Do a strict equality check on the share type bits of flags. In
particular, do an equality check on RF_PREFETCHABLE. The previous
code would allow one type of mismatch of RF_PREFETCHABLE but disallow
the other type of mismatch. Also, ignore the the RF_ALIGNMENT_MASK
bits since alignment validity should be handled by the amask check.
This field contains an integer value, but previous code did a strange
bitwise comparison on it.
Leave the original value of flags unmolested as a minor debug aid.
Change the start+amask overflow check to a KASSERT() since it is just
meant to catch a highly unlikely programming error in the caller.
Only pass ip[46].addr when _addrl contains a value
Partial MFC r204759:
Redirect stdin from /dev/null when starting a jail:
At least in RELENG_7 this fixes some start problems for some programs
from the ports. It is also more correct, as a jail shall not expect
input (interactivity) from the jail-host.
jhb [Tue, 24 Jun 2014 19:58:42 +0000 (19:58 +0000)]
MFC 253392:
Workaround some broken BIOSes that specify edge-sensitive but active-low
settings for ACPI-enumerated serial ports by forcing any IRQs that use
an ISA IRQ value with these settings to active-high instead of active-low.
This is known to occur with the BIOS on an Intel D2500CCE motherboard.
delphij [Thu, 12 Jun 2014 00:19:05 +0000 (00:19 +0000)]
MFC r227519, r227520:
r227519 (das)
Sync the style, comments, and variable names of arc4random.c with
OpenBSD's version (r1.22). No functional changes, as verified with
md5.
r227520 (das)
Further reduce diffs with OpenBSD's arc4random. The main functional
change here is to ensure that when a process forks after arc4random
is seeded, the parent and child don't observe the same random sequence.
OpenBSD's fix introduces some additional overhead in the form of a
getpid() call.
The only significant remaining difference between our arc4random and
OpenBSD's is in how we seed the generator in arc4_stir().
hselasky [Wed, 11 Jun 2014 05:45:48 +0000 (05:45 +0000)]
MFC r267240:
Resolve a deadlock setting the USB configuration index from userspace
on USB HUBs by moving the code into the USB explore threads. The
deadlock happens because child devices of the USB HUB don't have the
expected reference count when called from outside the explore
thread. Only the HUB device itself, which the IOCTL interface locks,
gets the correct reference count.
marius [Thu, 5 Jun 2014 13:24:12 +0000 (13:24 +0000)]
MFC: r266793, r266799, r266808
- Fix compilation with PAE support enabled by merging r233362 and, thus,
doing away with the unnecessary uint8_t pointer casting.
physical addresses.
- Nuke the unused softc of emujoy(4).
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
Sponsored by: Bally Wulff Games & Entertainment GmbH
mav [Thu, 5 Jun 2014 06:00:08 +0000 (06:00 +0000)]
MFC r266538:
Make ng_mppc to not disable the node in case of multiple packet loss.
Quite often it can be just packet reorder, and killing link in such case
is inconvenient. Add few sysctl's to control that behavior.
kib [Thu, 5 Jun 2014 00:50:55 +0000 (00:50 +0000)]
MFC r266846:
When usermode loaded non-default segment selector into the %gs,
correctly prepare KGSBASE msr to restore the user descriptor base on
the last swapgs during return to usermode.
jhb [Wed, 4 Jun 2014 18:22:34 +0000 (18:22 +0000)]
MFC 266281:
Clear the data buffer length field when freeing a command structure so that
it doesn't leak through when the command structure is reused for a user
command without a data buffer.
delphij [Tue, 27 May 2014 18:45:02 +0000 (18:45 +0000)]
MFC r266520:
Explicitly link libzfs against libavl as it is done in OpenSolaris
(4543:12bb2876a62e). Without this, some third party applications
may break because the lack of AVL related symbols.
FreeBSD base system are not affected because the FreeBSD ZFS command
line tools were all linked against libavl and thus hide the underlying
issue.
hselasky [Sun, 25 May 2014 18:26:43 +0000 (18:26 +0000)]
MFC r266541:
- Fix a bug where the TLBPC value was forced to being odd for IN
direction isochronous transfers.
- Remove setting of fields which does not belong to the respective
TRBs. These fields are currently set as zero and this is more a
cosmetic change.
pho [Fri, 23 May 2014 05:35:43 +0000 (05:35 +0000)]
MFC r265534:
msync(2) must return ENOMEM and not EINVAL when the address is outside the
allowed range or when one or more pages are not mapped. This according to
The Open Group Base Specifications Issue 7.
truckman [Thu, 22 May 2014 00:46:03 +0000 (00:46 +0000)]
MFC r266426
Slightly restructure the final loop in rman_reserve_resource_bound().
Replace with the existing loop termination test with a similar
condition from the nested "if" that may terminate the loop a bit
sooner, but still not too early. This condition can then be removed
from the nested "if". Relocate an operator to be style(9) compliant.
marius [Mon, 19 May 2014 09:26:35 +0000 (09:26 +0000)]
MFC: r253654
Set the device description after we call uart_probe(). In uart_probe()
we call device-specific probe functions, which can (and typically will)
set the device description based on low-level device probe information.
In the end we never actually used the device description that we so
carefully maintained in the PCI match table. By setting the device
description after we call uart_probe(), we'll print the more user-
friendly description by default.
jhb [Sun, 18 May 2014 15:31:02 +0000 (15:31 +0000)]
MFC 264766:
- Fix an off by one error when checking for the stop event. This
resulted in not showing the most recent event by default.
- When the stop even is hit, break out of the outer loop to stop
fetching more events.
marius [Thu, 15 May 2014 09:55:21 +0000 (09:55 +0000)]
Revert the following MFCs done as part of r265147:
r249438, r249466, r249481, r250025, r253958
leaving the MFCs of r241028 and r241444 in place. While the CAM queuing
changes in question are pretty much self-contained and work fine with all
kinds of SAS, SATA and USB devices, for reasons unknown they cause a hang
with Initio INIC-1610P USB disks not seen with later branches containing
these rewrites. In turn, r241444 actually is sufficient to fix the panic
and problems I was seeing and that lead me to bringing CAM queuing up to
date.
marius [Wed, 14 May 2014 15:22:42 +0000 (15:22 +0000)]
MFC: r204665
- Make function of finding an available drive name a macro.
- Move check of /dev/ prefix and copy into a function to save code duplication.
This also fixes a bug where the /dev/ prefix could not be used when creating
volumes on the command line.
MFC: r209051
Initialize variables before usage.
Found by: clang static analyzer
Found by: Coverity Prevent[tm] (CID 7736, 7760)
marius [Wed, 14 May 2014 13:48:29 +0000 (13:48 +0000)]
MFC: r265454
- Allow foot shooting with the resetconfig command via the -f option.
- Fix typos preventing -f to actually work with the create command.
- Initialize flags to zero rather than using stack garbage when handling
the grow command.
Sponsored by: Bally Wulff Games & Entertainment GmbH
davidcs [Mon, 12 May 2014 15:59:09 +0000 (15:59 +0000)]
MFC r265703
Modify Copyright information and other strings to reflect
Qlogic Corporation's purchase of Broadcom's NetXtreme business.
Added clean option to Makefile
Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
marius [Thu, 8 May 2014 14:28:51 +0000 (14:28 +0000)]
MFC: r251394
CAM_DEV_QFREEZE handling should only be done on request submission but
neither on completion nor by SIM drivers in the first place. This issue
has been revealed by r249466 (MFC'ed to stable/8 in r265147).
alc [Wed, 7 May 2014 16:28:36 +0000 (16:28 +0000)]
MFC r262338
When the kernel is running in a virtual machine, it cannot rely upon the
processor family to determine if the workaround for AMD Family 10h Erratum
383 should be enabled. To enable virtual machine migration among a
heterogeneous collection of physical machines, the hypervisor may have
been configured to report an older processor family with a reduced feature
set. Effectively, the reported processor family and its features are like
a "least common denominator" for the collection of machines.
Therefore, when the kernel is running in a virtual machine, instead of
relying upon the processor family, we now test for features that prove
that the underlying processor is not affected by the erratum. (The
features that we test for are unlikely to ever be emulated in software
on an affected physical processor.)
marius [Wed, 30 Apr 2014 14:09:26 +0000 (14:09 +0000)]
MFC: r241028
Change queue overflow checks from DIAGNOSTIC+panic() to KASSERT() to make
them enabled on HEAD by default. It is probably better to do single compare
then hunt for unexpected memory corruption.
MFC: r241444
Increase device CCB queue array size by CAM_RL_VALUES - 1 (4) elements.
It is required to store extra recovery requests in case of bus resets.
On ATA/SATA this fixes assertion panics on HEAD with INVARIANTS enabled or
possible memory corruptions otherwise if timeout/reset happens when device
CCB queue is already full.
Remove multilevel freezing mechanism, implemented to handle specifics of
the ATA/SATA error recovery, when post-reset recovery commands should be
allocated when queues are already full of payload requests. Instead of
removing frozen CCBs with specified range of priorities from the queue
to provide free openings, use simple hack, allowing explicit CCBs over-
allocation for requests with priority higher (numerically lower) then
CAM_PRIORITY_OOB threshold.
Simplify CCB allocation logic by removing SIM-level allocation queue.
After that SIM-level queue manages only CCBs execution, while allocation
logic is localized within each single device.
MFC: r253958
Change CCB queue resize logic to be able safely handle overallocations:
- (re)allocate queue space in power of 2 chunks with 64 elements minimum
and never shrink it; with only 4/8 bytes per element size is insignificant.
- automatically reallocate the queue to double size if it is overflowed.
- if queue reallocation failed, store extra CCBs in unsorted TAILQ,
fetching them back as soon as some queue element is freed.
To free space in CCB for TAILQ linking, change highpowerq from keeping
high-power CCBs to keeping devices frozen due to high-power CCBs.
This encloses all pieces of queue resize logic inside of cam_queue.[ch],
removing some not obvious duties from xpt_release_ccb().
ian [Mon, 28 Apr 2014 14:20:21 +0000 (14:20 +0000)]
MFC uftdi(4) driver changes...
r264010: Support speeds up to 12mbaud on newer chips.
r264018: Update list of supported FTDI chips.
r264031: Use 2K IO buffers for improved throughput.
r264149: Add ioctl(2) calls to access bitbang, MPSSE, CPU_FIFO,
and other modes.
r264800: Various fixes to r264149 pointed out by Coverity scan.
Take into account when zpool history block grows exceeding 128KB in zpool(8)
and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in
spa_history_create_obj()).
marius [Tue, 22 Apr 2014 13:02:12 +0000 (13:02 +0000)]
MFC: r229379
Add support for Intel EG20T serial ports
MFC: r248340
Add support for Exar XR17V358 8-port serial device to puc(4)
MFC: r248472
Correct the definition for Exar XR17V258IV: we must use a config_function
to specify the offset into the PCI memory spare at which each serial port
will find its registers. This was already done for other Exar PCI serial
devices; it was accidentally omitted for this specific device.
MFC: r251713
Fix whitespace and normalize some entries.
MFC: r251715
All of Oxford/PLX OX16PCI954, OXm16PCI954 and OXu16PCI954 share the
exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS
EX-41098-2 equipped with these), while at least the OX16PCI954 defaults
to a 1.8432 MHz one. According to the datasheets of these chips, the
only difference in PCI configuration space is that OXu16PCI954 have
a revision ID of 1 while the other two are at 0. So employ the latter
for determining the default clock rates of this family.
MFC: r264257, r264327, r264514
Distinguish between the different variants and configurations of Sunix
{MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S.
Among others, this fixes the hang seen when trying to probe the none-
existent second UART on an actually 1-port chip.
Obtained from: NetBSD (BAR layouts)
Sponsored by: Bally Wulff Games & Entertainment GmbH
====
Author: Dr. Stephen Henson <steve@openssl.org>
Treat a zero length passed to ssleay_rand_add a no op: the existing logic
zeroes the md value which is very bad. OpenSSL itself never does this
internally and the actual call doesn't make sense as it would be passing
zero bytes of entropy.
Thanks to Marcus Meissner <meissner@suse.de> for reporting this bug.
====
This is a direct commit to stable/8 and stable/9. -HEAD and stable/10
already have this fix as part of OpenSSL 1.0.1g.
projects / FreeBSD / stable / 8.git / log