sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

[PowerPC64LE] Endian fix for opal_hmi.c

Another boring one. We need to endian swap before checking flags.

Sponsored by: Tag1 Consulting, Inc.

[PowerPC] Fix panic when attempting to handle an HMI from an idle thread

In IRC, sfs_ finally managed to get a good trace of a kernel panic that was
happening when attempting to use webengine.

As i

[PowerPC] Fix panic when attempting to handle an HMI from an idle thread

In IRC, sfs_ finally managed to get a good trace of a kernel panic that was
happening when attempting to use webengine.

As it turns out, we were using vtophys() from interrupt context on an idle
thread in opal_hmi_handler2().

Since this involves locking the kernel pmap on PPC64 at the moment, this
ended up tripping a KASSERT in mtx_lock(), which then caused a parallel
panic stampede.

So, avoid this by preallocating the flags variable and storing it in PCPU.

Fixes "panic: mtx_lock() by idle thread 0x... on sleep mutex kernelpmap".

Differential Revision: https://reviews.freebsd.org/D22962

show more ...

Merge ^/head r352308 through r352318.

powerpc64/powernv: Add opal NVRAM driver for PowerNV systems

Add a very basic NVRAM driver for OPAL which can be used by the IBM
powerpc-utils nvram utility, not to be confused with the base nvram u

powerpc64/powernv: Add opal NVRAM driver for PowerNV systems

Add a very basic NVRAM driver for OPAL which can be used by the IBM
powerpc-utils nvram utility, not to be confused with the base nvram utility,
which only operates on powermac_nvram.

The IBM utility handles all partitions itself, treating the nvram device as
a plain store.

An alternative would be to manage partitions in the kernel, and augment the
base nvram utility to deal with different backing stores, but that
complicates the driver significantly. Instead, present the same interface
IBM's utlity expects, and we get the usage for free.

Tested by: bdragon

show more ...

MFHead @349234

Sponsored by: The FreeBSD Foundation

powernv: Port HMI handler to use the message framework

When an HMI occurs a message event also gets created with the details of the
exception. Hook into the messaging framework to retrieve the HMI

powernv: Port HMI handler to use the message framework

When an HMI occurs a message event also gets created with the details of the
exception. Hook into the messaging framework to retrieve the HMI message.
Nothing is done with it yet, except to panic on unhandled exception.

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

powerpc: Drop OPAL_HANDLE_HMI2 for now, to avoid panicking

It's possible for a Hypervisor Maintenance Interrupt (HMI) to occur while in
the pmap code, holding locks. This can cause WITNESS to panic

powerpc: Drop OPAL_HANDLE_HMI2 for now, to avoid panicking

It's possible for a Hypervisor Maintenance Interrupt (HMI) to occur while in
the pmap code, holding locks. This can cause WITNESS to panic due to lock
errors in calling pmap_kextract(). Since we don't yet handle the flags
returned by OPAL_HANDLE_HMI2, just stop using it, so that we don't call into
pmap_kextract().

Reported by: pkubaj

show more ...

MFHead@r345677

powernv: Add Hypervisor Maintenance Interrupt handler

Attempting to build www/firefox on POWER9 resulted in a HMI exception being
thrown, a fatal trap currently. This is typically caused by timer f

powernv: Add Hypervisor Maintenance Interrupt handler

Attempting to build www/firefox on POWER9 resulted in a HMI exception being
thrown, a fatal trap currently. This is typically caused by timer facility
errors, but examination of the Hypervisor Maintenance Exception Register
(HMER) yielded only that an exception had recovered, with no information of
the actual exception cause.

When an HMI occurs, OPAL_HANDLE_HMI or OPAL_HANDLE_HMI2 must be called to
handle the exception at the firmware level. If the exception is handled, we
can continue.

This adds only the preliminary handler, enough to prevent package building
from panicking. An enhancement in the future is to use the flags returned
by OPAL_HANDLE_HMI2 to print more useful error messages, and log maintenance
events.

Reviewed by: luporl
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19634

show more ...