History log of /freebsd/sys/kern/kern_shutdown.c (Results 176 – 200 of 643)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 7adc598a 03-Jun-2012 Andriy Gapon <avg@FreeBSD.org>

free wdog_kern_pat calls in post-panic paths from under SW_WATCHDOG

Those calls are useful with hardware watchdog drivers too.

MFC after: 3 weeks


# 2d5e7d2e 30-May-2012 Will Andrews <will@FreeBSD.org>

IFC @ r236291.
Diff reductions to the enclosure driver made in r235911.


# 31ccd489 28-May-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r236168.


# ac6e25ec 22-May-2012 Hartmut Brandt <harti@FreeBSD.org>

Make dumptid non-static. It is used by libkvm to detect whether
this is a VNET-kernel or not. gcc used to put the static symbol into
the symbol table, clang does not. This fixes the 'netstat: no name

Make dumptid non-static. It is used by libkvm to detect whether
this is a VNET-kernel or not. gcc used to put the static symbol into
the symbol table, clang does not. This fixes the 'netstat: no namelist'
error seen on clang+VNET systems.

show more ...


# 6a068746 15-May-2012 Alexander Motin <mav@FreeBSD.org>

MFC


# 38f1b189 26-Apr-2012 Peter Grehan <grehan@FreeBSD.org>

IFC @ r234692

sys/amd64/include/cpufunc.h
sys/amd64/include/fpu.h
sys/amd64/amd64/fpu.c
sys/amd64/vmm/vmm.c

- Add API to allow vmm FPU state init/save/restore.

FP stuff discussed with: kib


Revision tags: release/8.3.0_cvs, release/8.3.0
# 5d7380f8 28-Jan-2012 Attilio Rao <attilio@FreeBSD.org>

Avoid to check the same cache line/variable from all the locking
primitives by breaking stop_scheduler into a per-thread variable.
Also, store the new td_stopsched very close to td_*locks members as

Avoid to check the same cache line/variable from all the locking
primitives by breaking stop_scheduler into a per-thread variable.
Also, store the new td_stopsched very close to td_*locks members as
they will be accessed mostly in the same codepaths as td_stopsched and
this results in avoiding a further cache-line pollution, possibly.

STOP_SCHEDULER() was pondered to use a new 'thread' argument, in order to
take advantage of already cached curthread, but in the end there should
not really be a performance benefit, while introducing a KPI breakage.

In collabouration with: flo
Reviewed by: avg
MFC after: 3 months (or never)
X-MFC: r228424

show more ...


# 8fa0b743 23-Jan-2012 Xin LI <delphij@FreeBSD.org>

IFC @230489 (pending review).


# 90d82653 09-Jan-2012 Andriy Gapon <avg@FreeBSD.org>

enable stop_scheduler_on_panic by default

My plan is to make this behavior unconditional before 10.0 release.

X-MFC after: r228424 (if ever)


# 80dbff4e 04-Jan-2012 Sean Bruno <sbruno@FreeBSD.org>

IFC to head to catch up the bhyve branch

Approved by: grehan@


Revision tags: release/9.0.0
# bf8696b4 17-Dec-2011 Andriy Gapon <avg@FreeBSD.org>

introduce cngrab/cnungrab stub calls in some places where they make sense

MFC after: 2 months


# 1c5151f3 14-Dec-2011 David E. O'Brien <obrien@FreeBSD.org>

Match other formatting.


# 3d7618d8 13-Dec-2011 David E. O'Brien <obrien@FreeBSD.org>

Disallow various debug.kdb sysctl's when securelevel is raised.

PR: 161350


# 3eb9ab52 13-Dec-2011 Eitan Adler <eadler@FreeBSD.org>

Document a large number of currently undocumented sysctls. While here
fix some style(9) issues and reduce redundancy.

PR: kern/155491
PR: kern/155490
PR: kern/155489
Submitted by: Galimov Albert

Document a large number of currently undocumented sysctls. While here
fix some style(9) issues and reduce redundancy.

PR: kern/155491
PR: kern/155490
PR: kern/155489
Submitted by: Galimov Albert <wtfcrap@mail.ru>
Approved by: bde
Reviewed by: jhb
MFC after: 1 week

show more ...


# 35370593 11-Dec-2011 Andriy Gapon <avg@FreeBSD.org>

panic: add a switch and infrastructure for stopping other CPUs in SMP case

Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on vi

panic: add a switch and infrastructure for stopping other CPUs in SMP case

Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.

Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state

Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.

This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.

The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.

PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)

show more ...


# 3ee1a36e 22-Nov-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r227804

Pull in the virtio drivers from head.


# 6472ac3d 07-Nov-2011 Ed Schouten <ed@FreeBSD.org>

Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.

The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else,

Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.

The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.

show more ...


# 70d8f36a 27-Oct-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r226824


# 27449604 01-Oct-2011 Alexander Motin <mav@FreeBSD.org>

MFC


# 8451d0dd 16-Sep-2011 Kip Macy <kmacy@FreeBSD.org>

In order to maximize the re-usability of kernel code in user space this
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates

In order to maximize the re-usability of kernel code in user space this
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.

Reviewed by: rwatson
Approved by: re (bz)

show more ...


# fab4c373 16-Sep-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r225592

sys/dev/bvm/bvm_console.c - move up to the new alt-break order.


# 58379067 12-Sep-2011 Attilio Rao <attilio@FreeBSD.org>

dump_write() returns ENXIO if the dump is trying to be written outside
of the device boundry.
While this is generally ok, the problem is that all the consumers
handle similar cases (and expect to cat

dump_write() returns ENXIO if the dump is trying to be written outside
of the device boundry.
While this is generally ok, the problem is that all the consumers
handle similar cases (and expect to catch) ENOSPC for this (for a
reference look at minidumpsys() and dumpsys() constructions). That
ends up in consumers not recognizing the issue and amd64 failing to
retry if the number of pages grows up during minidump.
Fix this by returning ENOSPC in dump_write() and while here add some
more diagnostic on involved values.

Sponsored by: Sandvine Incorporated
In collabouration with: emaste
Approved by: re (kib)
MFC after: 10 days

show more ...


# fa2b39a1 08-Sep-2011 Attilio Rao <attilio@FreeBSD.org>

Improve the informations reported in case of busy buffers during the shutdown:
- Axe out the SHOW_BUSYBUFS option and uses a tunable for selectively
enable/disable it, which is defaulted for not prin

Improve the informations reported in case of busy buffers during the shutdown:
- Axe out the SHOW_BUSYBUFS option and uses a tunable for selectively
enable/disable it, which is defaulted for not printing anything (0
value) but can be changed for printing (1 value) and be verbose (2
value)
- Improves the informations outputed: right now, there is no track of
the actual struct buf object or vnode which are referenced by the
shutdown process, but it is printed the related struct bufobj object
which is not really helpful
- Add more verbosity about the state of the struct buf lock and the
vnode informations, with the latter to be activated separately by the
sysctl

Sponsored by: Sandvine Incorporated
Reviewed by: emaste, kib
Approved by: re (ksmith)
MFC after: 10 days

show more ...


# cf914969 15-Aug-2011 Justin T. Gibbs <gibbs@FreeBSD.org>

Integrate FreeBSD/head into projects/zfsd/head as of SVN revision 224870.


# 7a0b13ed 25-Jul-2011 Andriy Gapon <avg@FreeBSD.org>

remove RESTARTABLE_PANICS option

This is done per request/suggestion from John Baldwin
who introduced the option. Trying to resume normal
system operation after a panic is very unpredictable
and da

remove RESTARTABLE_PANICS option

This is done per request/suggestion from John Baldwin
who introduced the option. Trying to resume normal
system operation after a panic is very unpredictable
and dangerous. It will become even more dangerous
when we allow a thread in panic(9) to penetrate all
lock contexts.
I understand that the only purpose of this option was
for testing scenarios potentially resulting in panic.

Suggested by: jhb
Reviewed by: attilio, jhb
X-MFC-After: never
Approved by: re (kib)

show more ...


12345678910>>...26