Change default behaviour of ld(1) to not recursively copy DT_NEEDED
This is the default behaviour of the newer binutils as well as most alternative linkers.
All the ports tree has been fixed to be able to link properly with this new behaviour.
Rui Paulo [Wed, 31 Jul 2013 02:13:18 +0000 (02:13 +0000)]
When using tcpdump -I -i wlanN and wlanN is not a monitor mode VAP,
tcpdump will print an error message saying rfmon is not supported.
Give a concise explanation as to how one might solve this problem by
creating a monitor mode VAP.
Scott Long [Tue, 30 Jul 2013 22:57:12 +0000 (22:57 +0000)]
Add a 'surrender' mode to fsck_ffs. With the -S flag, once hard read errors
are encountered, the fsck will stop instead of wasting time chewing through
possibly other errors.
Xin LI [Tue, 30 Jul 2013 21:20:12 +0000 (21:20 +0000)]
MFV r253782:
To quote Illumos issue #3888:
When 'zfs recv -F' is used with an incremental recv it rolls
back any changes made since the last snapshot in case new
changes were made to the file system while the recv is in
progress (without -F the recv would fail when it does it's
final check to commit the recv-ed data as the recv-ed data
conflicts with the newly written data).
However, if there is a snapshot taken after the recv began
rolling back to the 'latest' snapshot will not help and the
recv will still fail. 'zfs recv -F' should be extended to
destroy any snapshots created since the source snapshot when
finishing the recv (effectively rolling back through all
snapshots, instead of just to the latest snapshot).
Illumos ZFS issues:
3888 zfs recv -F should destroy any snapshots created since the
incremental source
Xin LI [Tue, 30 Jul 2013 20:37:32 +0000 (20:37 +0000)]
MFV r253780:
To quote Illumos #3875:
The problem here is that if we ever end up in the error
path, we drop the locks protecting access to the zfsvfs_t
prior to forcibly unmounting the filesystem. Because z_os
is NULL, any thread that had already picked up the zfsvfs_t
and was sitting in ZFS_ENTER() when we dropped our locks
in zfs_resume_fs() will now acquire the lock, attempt to
use z_os, and panic.
Illumos ZFS issues:
3875 panic in zfs_root() after failed rollback
Sean Bruno [Tue, 30 Jul 2013 18:54:24 +0000 (18:54 +0000)]
Check for ipmi_attached in ipmi_isa_probe as a suggested alternative to
ipmi_isa_attach. This keeps unintended but harmless noise about "ipmi1"
from appearing in the boot up sequence.
Submitted by: jbh@ (suggested by)
Sponsored by: Yahoo! Inc.
Sean Bruno [Tue, 30 Jul 2013 18:44:29 +0000 (18:44 +0000)]
empirical testing showed that 3 seconds is just too slow for GET_DEVICE_ID
to return on newer Dell hardware. Bump to 6 second timeouts until someone
has a better idea on how to handle this
Alexander Motin [Tue, 30 Jul 2013 14:50:44 +0000 (14:50 +0000)]
Allow three IOCTLs to be used on suspended pool, restoring state that
existed before IOCTL code refactoring merged change 4445fffb from illumos
at r248571.
This change allows `zpool clear` to be used again to recover suspended pool.
It seems the only was supposed by the code to restore pool operation after
reconnecting lost disks that were required for data completeness. There
are still cases where `zpool clear` command can just safely stuck due to
deadlocks inside ZFS kernel part, but probably that is better then having
no chances to recover at all.
Alexander Motin [Tue, 30 Jul 2013 13:00:09 +0000 (13:00 +0000)]
Add NO_RC16 quirk to make da driver avoid using READ CAPACITY(16) command
if possible. Use it for Kingston JetFlash USB sticks, that are known to
return garbage in response to that command.
This patch implements __get_cpuid_max() as an inline and __cpuid()
and __cpuid_count() as macros to be compatible with GCC's cpuid.h.
It also adds bit_<foo> constants for the various feature bits as
described in version 039 (May 2011) of Intel's SDM Volume 2 in the
description of the CPUID instruction. The list of bit_<foo>
constants is a bit exhaustive (GCC doesn't do near this many). More
bits could be added from a newer version of SDM if desired.
Patch by John Baldwin!
This should fix several ports which depend on this functionality being
available.
David E. O'Brien [Mon, 29 Jul 2013 20:58:09 +0000 (20:58 +0000)]
Decouple yarrow from random(4) device.
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.
* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.
* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
random_adaptor is basically an adapter that plugs in to random(4).
random_adaptor can only be plugged in to random(4) very early in bootup.
Unplugging random_adaptor from random(4) is not supported, and is probably a
bad idea anyway, due to potential loss of entropy pools.
We currently have 3 random_adaptors:
+ yarrow
+ rdrand (ivy.c)
+ nehemeiah
* Remove platform dependent logic from probe.c, and move it into
corresponding registration routines of each random_adaptor provider.
probe.c doesn't do anything other than picking a specific random_adaptor
from a list of registered ones.
* If the kernel doesn't have any random_adaptor adapters present then the
creation of /dev/random is postponed until next random_adaptor is kldload'ed.
* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
system wide one.
David E. O'Brien [Mon, 29 Jul 2013 20:26:27 +0000 (20:26 +0000)]
Decouple yarrow from random(4) device.
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.
* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.
* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
random_adaptor is basically an adapter that plugs in to random(4).
random_adaptor can only be plugged in to random(4) very early in bootup.
Unplugging random_adaptor from random(4) is not supported, and is probably a
bad idea anyway, due to potential loss of entropy pools.
We currently have 3 random_adaptors:
+ yarrow
+ rdrand (ivy.c)
+ nehemeiah
* Remove platform dependent logic from probe.c, and move it into
corresponding registration routines of each random_adaptor provider.
probe.c doesn't do anything other than picking a specific random_adaptor
from a list of registered ones.
* If the kernel doesn't have any random_adaptor adapters present then the
creation of /dev/random is postponed until next random_adaptor is kldload'ed.
* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
system wide one.
John Baldwin [Mon, 29 Jul 2013 18:44:52 +0000 (18:44 +0000)]
Various fixes to the mlxen(4) driver:
- Remove an incorrect assertion that can trigger when downing an interface.
- Stop the interface during detach to avoid panics when unloading the
driver.
- A few locking fixes to be more consistent with other FreeBSD drivers:
- Protect if_drv_flags with the driver lock, not atomic ops
- Hold the driver lock when adjusting multicast state.
- Hold the driver lock while adjusting if_capenable.
PR: kern/180791 [1,2]
Submitted by: Shakar Klein @ Mellanox [1,2]
MFC after: 3 days
Alexander Motin [Sun, 28 Jul 2013 20:07:34 +0000 (20:07 +0000)]
Partially close race between calls of orphan() method from GEOM and close()
method from ZFS core, that reliably causes use-after-free panic if SSD vdev
detached during inititial erase.
Alexander Motin [Sun, 28 Jul 2013 19:56:08 +0000 (19:56 +0000)]
Fix returning incorrect bio_resid value with failed BIO_DELETE requests.
Neither residual length reported for ATA/SCSI command nor one from another
BIO_DELETE request are in any way related to the value to be returned.
Hiroki Sato [Sun, 28 Jul 2013 19:49:39 +0000 (19:49 +0000)]
- Relax the restriction on the member interfaces with LLAs. Two or more
LLAs on the member interfaces are actually harmless when the parent
interface does not have a LLA.
- Add net.link.bridge.allow_llz_overlap. This is a knob to allow LLAs on
a bridge and the member interfaces at the same time. The default is 0.
Marius Strobl [Sun, 28 Jul 2013 12:29:10 +0000 (12:29 +0000)]
- Add const-qualifiers to the arguments of isonum_*().
- According to ISO 9660 7.1.2, isonum_712() should return a signed value.
- Try to get isonum_*() closer to style(9).
When creation of the v_pollinfo raced and our instance of vpollinfo
must be destroyed, knlist_clear() and seldrain() calls could be
avoided, since vpollinfo was not used. More, the knlist_clear()
calling protocol requires the knlist locked, which is not true at the
call site.
Split the destruction into the helper destroy_vpollinfo_free(), and
call it when raced, instead of destroy_vpollinfo().
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Adrian Chadd [Sun, 28 Jul 2013 04:53:00 +0000 (04:53 +0000)]
Refactor the VAP transmit path code into a utility function that both
the normal and the mesh transmit paths can use.
The API is a bit horrible because it both consumes the mbuf and frees
the node reference regardless of whether it succeeds or not.
It's a hold-over from how the code behaves; it'd be nice to have it
not free the node reference / mbuf if TX fails and let the caller
decide what to do.
Pedro F. Giffuni [Sun, 28 Jul 2013 01:02:17 +0000 (01:02 +0000)]
DTrace: re-apply r249426 now that the underlying issues have been solved.
Merge change from illumos:
3519 DTrace fails to resolve const types from fbt
3520 dtrace internal error -- token type 316 is not a valid D
compilation token
3521 clean up dtrace unit tests
Pedro F. Giffuni [Sun, 28 Jul 2013 00:45:20 +0000 (00:45 +0000)]
DTrace: re-merge remainder of r249367 (original from Illumos).
Bring back some important fixes from Illumos:
3022 DTrace: keys should not affect the sort order when sorting by value
3023 it should be possible to dereference dynamic variables
3024 D integer narrowing needs some work
We particularly avoid the LD_NOLAZYLOAD changes that Illumos made
as those don't apply to FreeBSD and were causing problems in
interactive mode.
Alexander Motin [Sat, 27 Jul 2013 22:44:55 +0000 (22:44 +0000)]
Synchronize device cache on close only if there were some write operations.
While these operations are not really needed otherwise, at least for SCSI
they may cause extra errors if some other initiator holds write exclusive
reservation on the LUN (SYNCHRONIZE CACHE handled as "write" operation).
Mark Johnston [Sat, 27 Jul 2013 21:31:48 +0000 (21:31 +0000)]
Use kern_ioctl() rather than ioctl() for testing the FBT provider, since the
latter doesn't exist in FreeBSD. All the tests under fbtprovider pass now.
Sean Bruno [Sat, 27 Jul 2013 16:32:34 +0000 (16:32 +0000)]
At some point after stable/7 the ACPI and ISA interfaces to the IPMI controller
no longer have the parent in the device tree. This causes the identify
function in ipmi_isa.c to attempt to probe and poke at the ISA IPMI interface
Move the check for ipmi_attached out of the ipmi_isa_attach function and into
the ipmi_isa_identify function. Remove the check of the device tree for
ipmi devices attached.
This probing appears to make Broadcom management firmware on Dell machines
crash and emit NMI EISA warnings at various times requiring power cycles
of the machines to restore.
Bump MAX_TIMEOUT to 6 seconds as a hack for super slow IPMI interfaces that
need longer to respond to our intial probes on startup.
Tested on Dell R410, R510, R815, HP DL160G6
This is MFC candidate for 9.2R
Reviewed by: peter
MFC after: 2 weeks
Sponsored by: Yahoo! Inc.
Marius Strobl [Sat, 27 Jul 2013 15:28:31 +0000 (15:28 +0000)]
- Set the System Identifier in the Primary Volume Descriptor to FreeBSD
rather than NetBSD.
- Correctly set the Expiration Time in the Primary Volume Descriptor;
according to ISO 9660 8.4.26.1 unspecified date and time are denoted
by the digit 0 in RBP 1 to 16 but the number 0 in RBP 17. [1]
- Merge iso9660_rrip.c rev. 1.11 from NetBSD: name_len should be read
as unsigned byte. [2]
Note: This is according to ISO 9660 9.1.10.
- Rock Ridge TF entries should use a length of 5, because after the 4
bytes of generic SUSP header there is one byte of flags. See typedef
of ISO_RRIP_TF in iso9660_rrip.h. [1]
Submitted by: Thomas Schmitt [1]
Obtained from: NetBSD [2]
MFC after: 3 days
Alexander Motin [Sat, 27 Jul 2013 15:02:19 +0000 (15:02 +0000)]
Introduce 3 seconds timeout on `graid stop` command (mostly with -f flag).
Since completion waiting goes in g_event thread, it may cause GEOM deadlock
if consumer on top (for example, ZFS) uses g_event thread for closing.