The pci bus driver handles the power state, it also manages
configuration state saving and restoring for its child devices. Thus a
PCI device driver does not have to worry about those things. In fact, I
observe a hard system hang when trying to suspend a system with active
radeonkms driver where both the bus driver and radeonkms driver try to
do the same thing. I suspect that it could be because of an access to a
PCI configuration register after the device is placed into D3 state.
Reviewed by: dumbbell, jhb
MFC after: 13 days
Differential Revision: https://reviews.freebsd.org/D3561
All requests arriving for processing after OFFLINE flag set are rejected
with BUSY status. Races around OFFLINE flag setting are closed by calling
taskqueue_drain_all().
in the routine, which queues an ERROR chunk, instead on relyinh
on the callers to do so. Since one caller missed this, this actially
fixes a bug.
MFC after: 1 week
at the end of string buffer, and the code context do expects this to behave
correctly (e.g. strchr).
Note that we do not believe there is real-world impact for gstat(8)'s usage
because the strings are length checked, and the on-stack buffer belongs to
main() and we can expect to have zeros in them.
MFC after: 2 weeks
running thread.
It is currently implemented only on amd64 and i386; on these
architectures, it is implemented by raising an NMI on the CPU on which
the target thread is currently running. Unlike stack_save_td(), it may
fail, for example if the thread is running in user mode.
This change also modifies the kern.proc.kstack sysctl to use this function,
so that stacks of running threads are shown in the output of "procstat -kk".
This is handy for debugging threads that are stuck in a busy loop.
Reviewed by: bdrewery, jhb, kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3256
since on amd64 the first argument to a function is generally not on the
stack.
Revert an old DTrace bug fix to some code that assumed that
sizeof(struct amd64_frame) == 16.
Reviewed by: jhb, kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3255
5930 fasttrap_pid_enable() panics when prfind() fails in forking process
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Gordon Ross <gordon.ross@nexenta.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
Author: Bryan Cantrill <bryan@joyent.com>
illumos/illumos-gate@9df7e4e12e
If MAKEOBJDIRPREFIX is set, use it for default OBJROOT.
If MAKEOBJDIR is empty or not a suitable value (no '/')
set a default that works.
Reviewed by: bdrewery
The only operation which is prevented by the hold is the kernel stack
swapout for the faulted thread, which should be fine to allow.
Remove useless checks for NULL curproc or curproc->p_vmspace from the
trap_pfault() wrappers on x86 and powerpc.
Reviewed by: alc (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
illumos/illumos-gate@cf6106c8a0https://www.illumos.org/issues/5987
The existing ZFS prefetch code (dmu_zfetch.c) has some problems:
1. It's nearly impossible to understand. e.g. there are an abundance of kstats
but it's hard to know what they mean (see below).
2. For some workloads, it detects patterns that aren't really there (e.g.
strided patterns, backwards scans), and generates needless i/os prefetching
blocks that will never be referenced.
3. It has lock contention issues. These are caused primarily by
dmu_zfetch_colinear() calling dmu_zfetch_dofetch() (which can block waiting for
i/o) with the zf_rwlock held for writer, thus blocking all other threads
accessing this file.
I suggest that we rewrite this code to detect only forward, sequential streams.
[... truncated ...]
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Approved by: Gordon Ross <gordon.ross@nexenta.com>
Author: Matthew Ahrens <mahrens@delphix.com>
illumos/illumos-gate@1437283407https://www.illumos.org/issues/5997
ZFS already supports storing the vdev FRU in a vdev property. There is code in
libzfs to work with this property, and there is code in the zfs-retire FMA
module that looks for that information. But there is no code actually setting
or updating the FRU.
To address this, ZFS is changed to send a handful of new events whenever a vdev
is added, attached, cleared, or onlined, as well as when a pool is created or
imported. The syseventd zfs module will handle these and update the FRU field
when necessary.
Reviewed by: Dan Fields <dan.fields@nexenta.com>
Reviewed by: Josef Sipek <josef.sipek@nexenta.com>
Reviewed by: Richard Elling <richard.elling@gmail.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Hans Rosenfeld <hans.rosenfeld@nexenta.com>
Porting notes: only the kernel bits for the new events are imported
CTL HA functionality was originally implemented by Copan many years ago,
but large part of the sources was never published. This change includes
clean room implementation of the missing code and fixes for many bugs.
This code supports dual-node HA with ALUA in four modes:
- Active/Unavailable without interlink between nodes;
- Active/Standby with second node handling only basic LUN discovery and
reservation, synchronizing with the first node through the interlink;
- Active/Active with both nodes processing commands and accessing the
backing storage, synchronizing with the first node through the interlink;
- Active/Active with second node working as proxy, transfering all
commands to the first node for execution through the interlink.
Unlike original Copan's implementation, depending on specific hardware,
this code uses simple custom TCP-based protocol for interlink. It has
no authentication, so it should never be enabled on public interfaces.
The code may still need some polishing, but generally it is functional.
Relnotes: yes
Sponsored by: iXsystems, Inc.
This silence a warning brought up by valgrind whenever if_nametoindex
is used. This was already discussed in PR 166483, but the code
committed in r234329 guards the initilization with #ifdef PURIFY.
Therefore, valgrind still complains. Since this code is not performance
critical, always zero out the local variable to silence valgrind.
PR: 166483
Discussed with: eadler@
MFC after: 4 weeks
Auto-tuning threshold discussions aside, it turns out that if you want
to lower this on say, rather memory-packed machines, you either set maxusers
or kern.maxfiles, or you set it in sysctl. The former is a non-exact
way to tune this; the latter doesn't actually affect anything in the
startup scripts.
This first occured because I wondered why the hell screen would take upwards
of 10 seconds to spawn a new screen. I then found python doing the same
thing during fork/exec of child processes - it calls close() on each FD
up to the current openfiles limit. On a 1TB machine this is like, 26 million
FDs per process. Ugh.
So:
* This allows it to be set early in /boot/loader.conf;
* It can be used to work around the ridiculous situation of
screen, python, etc doing a close() on potentially millions of FDs
even though you only have four open.
Tested:
* 4GB, 32GB, 64GB, 128GB, 384GB, 1TB systems with autotune, ensuring
screen and python forking doesn't result in some pretty hilariously
bad behaviour.
TODO:
* Note that the default login.conf sets openfiles-cur to unlimited,
effectively obeying kern.maxfilesperproc. Perhaps we should fix
this.
* .. and even if we do, we need to also ensure that daemons get
a soft limit of something reasonable and capped - they can request
more FDs themselves.
MFC after: 1 week
Sponsored by: Norse Corp, Inc.
getppid() after a debugger process that is not the parent has attached.
Reviewed by: kib (earlier version)
Differential Revision: https://reviews.freebsd.org/D3615
named node, open(2) cannot create directories. But do allow the flag
combination to succeed if the directory already exists.
Declare the open("name", O_DIRECTORY | O_CREAT | O_EXCL) always
invalid for the same reason, since open(2) cannot create directory.
Note that there is an argument that O_DIRECTORY | O_CREAT should be
invalid always, regardless of the target directory existence or
O_EXCL. The current fix is conservative and allows the call to
succeed in the situation where it succeeded before the patch.
Reported by: Tom Ridge <freebsd@tom-ridge.com>
Reviewed by: rwatson
PR: 202892
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
