This is imported from NetBSD. The author--Joerg Sonnenberger--agreed
to apply a two-clause BSD license, just so the license was clear.
This source tree location matches NetBSD, and is the first place someone
might look for such a tool.
Obtained from: Joerg Sonnenberger via NetBSD
MFC after: 3 days
Sponsored by: Dell EMC
This adds support to camcontrol(8) and libcam(3) for getting and setting
the time on SCSI protocol drives. This is more commonly found on tape
drives, but is a SPC (SCSI Primary Commands) command, and may be found
on any device that speaks SCSI.
The new camcontrol timestamp subcommand allows getting the current device
time or setting the time to the current system time or any arbitrary time.
sbin/camcontrol/Makefile:
Add timestamp.c.
sbin/camcontrol/camcontrol.8:
Document the new timestamp subcommand.
sbin/camcontrol/camcontrol.c:
Add the timestamp subcommand to camcontrol.
sbin/camcontrol/camcontrol.h:
Add the timestamp() function prototype.
sbin/camcontrol/timestamp.c:
Timestamp setting and reporting functionality.
sys/cam/scsi/scsi_all.c:
Add two new CCB building functions, scsi_set_timestamp() and
scsi_report_timestamp(). Also, add a new helper function,
scsi_create_timestamp().
sys/cam/scsi/scsi_all.h:
Add CDB and parameter data for the the set and report timestamp
commands.
Add function declarations for the new CCB building and helper
functions.
Submitted by: Sam Klopsch
Sponsored by: Spectra Logic
MFC After: 2 weeks
It is quite specific mode of operation without storing on-disk metadata.
It can be useful in some cases in combination with some external control
tools handling mirror creation and disks hot-plug.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
the BIOCSETIF ioctl.
The kernel always copies an entire struct ifreq and IPv4 addresses will
always fit in an ifreq.
On systems with pointers larger than 64-bits, the computed size will be
less than the size of struct ifreq, potentially resulting in the kernel
attempting to copyin memory from outside the allocation.
Reviewed by: jhb
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8445
and uses TCP for the Unmount RPC if the mount is over TCP.
Without this patch, umount does an Unmount RPC over UDP for all NFS mounts.
Suggested by: cperciva
Reviewed by: cperciva
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8503
instead. Since we're little endian, we can get away with it. Also,
since the counters in quesitons would require billions of iops for
tens of billions of seconds to overflow, and since such data rates are
unlikely for people using i386 for a while, that's OK. The fastest
cards today can't do even a million IOPs.
Noticed by: dim@
Sponsored by: Netflix, Inc
it in human readable form. Include a pointer to the public spec that
was followed to implement this in the code. Samsung also implements
page 0xca on some of their drives, but the format is slighly
different, so the code skips printing zero keys. Samsung's log page
has additional, unknown data after the end of Intel defined data which
isn't displayed.
Supported by: Netfix, Inc
number is printed, even though you'd need like a billion IOPs for a 10
billion seconds to overflow the 64-bit counters (~300 years).
Sponsored by: Netflix, Inc
are valid or not. While many pages are reserved in the standard, that
doesn't make them invalid and future versions of the standard may
define then.
Sponsored by: Netflix, Inc
(gpt)zfsboot will read one-time boot directives from a special ZFS pool
area. The area was previously described as "Boot Block Header", but
currently it is know as Pad2, marked as reserved and is zeroed out on
pool creation. The new code interprets data in this area, if any, using
the same format as boot.config. The area is immediately wiped out.
Failure to parse the directives results in a reboot right after the
cleanup. Otherwise the boot sequence proceeds as usual.
zfsbootcfg writes zfsboot arguments specified on its command line to the
Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and
vfs.zfs.boot.primary_vdev kenv variables that are set by loader during
boot. Please see the manual page for more.
Thanks to all who reviewed, contributed and made suggestions! There are
many potential improvements to the feature, please see the review for
details.
Reviewed by: wblock (docs)
Discussed with: jhb, tsoome
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D7612
Currently, '/etc/rc.d/swaplate stop' removes all swap devices. This can be
very slow and may not even be possible if there is a lot of swap space in
use. However, removing swap devices is only needed for late swap devices
that may depend on daemons that subsequent shutdown steps stop. Normal swap
devices such as hard disk partitions will remain available throughout the
shutdown process and need not be removed.
In swapoff, interpret -aL to remove late swap devices only, and use this in
etc/rc.d/swaplate. The meaning of -aL in swapon remains unchanged (add all
swap devices, both normal and late).
PR: 187081
Reviewed by: wblock (man page only), ngie
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8126
In r307684, I changed rescan_or_reset_bus() to bzero stack-allocated CCBs
before sending them to the kernel because there was stack garbage in there
that wound up meaning that bogus CCB flags were set.
While this fixed the 'camcontrol rescan all' case (XPT_DEV_MATCH CCBs were
failing previously), it broke the 'camcontrol rescan 0' (or any other
number) case when INVARIANTS are turned on. Rescanning a single bus
reliably produced an assert in cam_periph_runccb():
panic: cam_periph_runccb: ccb=0xfffff80044ffe000, func_code=0x708, flags=0xffffdde0
The flags values don't make sense from the code. Changing the CCBs in
rescan_or_reset_bus() from stack to heap allocated avoids the problem.
It would be better to understand why userland stack allocated CCBs don't
work properly, since there may be other code that breaks if stack allocated
CCBs don't work.
sbin/camcontrol/camcontrol.c:
In rescan_or_reset_bus(), allocate the CCBs using malloc(3) instead
of on the stack to avoid an assertion in cam_periph_runccb().
MFC after: 3 days
Sponsored by: Spectra Logic
the header. Otherwise stack garbage can lead to random flags getting set.
This showed up as 'camcontrol rescan all' failing with EINVAL because the
address type wasn't CAM_DATA_VADDR.
sbin/camcontrol/camcontrol.c:
In rescan_or_reset_bus(), bzero the stack-allocated CCBs before
use instead of clearing the body.
MFC after: 3 days
Sponsored by: Spectra Logic
Ignore the ECN bits on 'tos' and 'set-tos' and allow to use
DCSP names instead of having to embed their TOS equivalents
as plain numbers.
Obtained from: OpenBSD
Sponsored by: OPNsense
Differential Revision: https://reviews.freebsd.org/D8165
r301059 accidently introduced a subtle change for point to point interfaces
where an extra space is inserted before the netmask. This can cause issues
for scripts that parse ifconfig output.
Submitted by: Kevin Bowling <kevin.bowling@kev009.com>
Reviewed by: hiren
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8199
shell, ensure that we do sleep for at least the specified time, in
presence of signals.
Interrupted sleep(3) is followed by _exit(), which might cause 'Going
nowhere without my init' panic if init(8) exits before the reboot(2)
really started, or before SIGTSTP stopped init(8) (both events are
initiated by the parallel reboot(8) operation).
I do not see other calls to sleep(STALL_TIMEOUT) as having the same
disasterous consequences and kept them as is until the similar change
is proven required.
Reported and tested by: Andy Farkas <chuzzwassa@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
A premature optimization lead to caching a native-sector sized memory
allocation. If the program examined a 512 byte sector disk, then a 4096
byte sector disk, the program would overrun the cached 512 byte buffer.
Just remove the optimization to fix the bug. This was introduced with the 4Kn
dump support in r298076.
Reported by: markj
Reviewed by: markj, rpokala
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8162
Move sentence to a new line as advised by igor.
PR: 212474
Approved by: bcr (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D8104
I was unable to pin point the exact version of Mach the fdisk utility appeared as I could not find documentation older than version 2.5 & no source code or repo history.
fdisk utility appears as a separate utility[3] in v2.5. Due to this, I have avoided stating the exact version fdisk first appeared in Mach.
Add authors section.
[1] https://groups.google.com/d/topic/comp.unix.bsd/Hhi45vAHxDg/discussion
[2] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_install.ps
[3] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_manpages.ps
PR: 212470
Approved by: bcr (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D8104
I was unable to pin point the exact version of Mach the fdisk utility appeared as I could not find documentation older than version 2.5 & no source code or repo history.
fdisk utility appears as a separate utility[3] in v2.5. Due to this, I have avoided stating the exact version fdisk first appeared in Mach.
Add authors section.
Make correction pointed by igor
[1] https://groups.google.com/d/topic/comp.unix.bsd/Hhi45vAHxDg/discussion
[2] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_install.ps
[3] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_manpages.ps
PR: 212469
Approved by: bcr (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D8104
Move sentence to a new line as advised by igor.
PR: 212441
Approved by: bcr (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D8104
Move sentence to a new line as advised by igor
PR: 212439
Approved by: bcr (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D8104
