In most cases kernel.bootfile is populated from the information
provided by loader(8). There are certain scenarios when loader
is not available, for instance when kernel is loaded by u-boot
or some other BootROM directly. In this case the default value
"/kernel" points to invalid location and breaks some functinality,
like using installkernel on self-hosted system or dtrace's CTF
lookup. This can be fixed by setting the value manually but the
default that reflects correct location is better than default that
points to invalid one.
Current default was set around FreeBSD 1, when "/kernel" was the
actual path. Transition to /boot/kernel/kernel happened circa FreeBSD 3.
PR: 221550
Reviewed by: ian, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18902
CAM_RESRC_UNAVAIL instead of CAM_REQUEUE_REQ. This makes CAM delay a bit
before retrying, so that the retries actually get a chance to succeed.
Reviewed by: sbruno
MFC after: 2 weeks
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D19696
It makes the code slightly easier to follow, and might make
it easier to fix the resouce accounting to also account for
the interpreter.
The PROC_UNLOCK() is moved earlier - I don't see anything
it should protect; the lim_max() is a wrapper around lim_rlimit(),
and that, differently from lim_rlimit_proc(), doesn't require
the proc lock to be held.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D19689
was unlocked and yet the bucket-unlock flag was not
changed to false. This can cause a panic if INVARIANTS
is on and we go through the right path (though rare).
Reported by: syzbot+179a1ad49f3c4c215fa2@syzkaller.appspotmail.com
Reviewed by: tuexen@
MFC after: 1 week
* Cache moea64_need_lock in a local variable; gcc generates slightly better
code this way, it doesn't need to reload the value from memory each read.
* VPN cropping is only needed on PowerPC ISA 2.02 and older cores, a subset
of those that need serialization, so move this under the need_lock check,
so those that don't need the lock don't even need to check this.
This allows for directives such as
makeoptions DTS+=/out/of/tree/myboard.dts
# in tree! Same rules applied as if this were in a dtb/ module
makeoptions DTS+=otherboard.dts
to be specified in config(5) and have these built/installed alongside th
kernel. The assumption that overlays live in an overlays/ directory is only
made for in-tree DTSO, but we still make the assumption that out-of-tree
arm64 DTS will be in vendored directories (for now).
This lowers the cost to hacking on an overlay or dts by being able to
quickly throw it in a custom config, especially if it doesn't fit one of the
current dtb/modules quite appropriately or it's not intended for commit
there.
The build/install targets were split out of dtb.mk to centralize the build
logic and leave out the all/realinstall/CLEANFILES additions... it was
believed that we didn't want to pollute the kernel build with these.
The build rules were converted to suffix rules at the suggestion of Ian to
clean things up a little bit in a world where we can have mixed
in-tree/out-of-tree DTS/DTSO specified.
Reviewed by: ian
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19351
Assuming that the autoboot sequence was interrupted, we've done enough
cursor manipulation that the prompt for the password will be sufficiently
obscured a couple of lines up. Clear the screen and reset the cursor
position here, too.
MFC after: 1 week
A sysid of 0 denotes the local system, and some handlers for remote
locking commands do not attempt to deal with local locks. Note that
F_SETLK_REMOTE is only available to privileged users as it is intended
to be used as a testing interface.
Reviewed by: kib
Reported by: syzbot+9c457a6ae014a3281eb8@syzkaller.appspotmail.com
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19702
The current kernel C-type macros might obscurely hide the fact that
the input argument might be used multiple times.
This breaks code like:
isalpha(*ptr++)
Use static inline functions instead of macros to fix this.
Reviewed by: kib @
Differential Revision: https://reviews.freebsd.org/D19694
MFC after: 1 week
Sponsored by: Mellanox Technologies
was not taken modulo the window size in VGLClear().
Segmented modes also need a kernel fix to almost work. The ioctl to set
the window origin is broken.
These bugs are rarely problems since non-VESA modes only need
segmentation to support multiple pages but libvgl doesn't support
multiple pages and treats these modes as non-segmented, and VESA modes
are usually mapped linearly except on old hardware so they really are
non-segmented.
Relevant vendor changes:
PR #1153: fixed 2 bugs in ZIP reader
PR #1143: ensure archive_read_disk_entry_from_file() uses ARCHIVE_READ_DISK
Changes to file flags code, support more file flags on FreeBSD:
UF_OFFLINE, UF_READONLY, UF_SPARSE, UF_REPARSE, UF_SYSTEM
UF_ARCHIVE is not supported by intention (yet)
AR724X_GPIO_PINS used for this family is defined as 18
The datasheet for the AR7241 describes 20 pins, allow all to be used.
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D17580
TMPFS_PAGES_MINRESERVED controls how much memory is reserved for the system
and not used by tmpfs.
On very small memory systems, the default value may be too high and this
prevents these small memory systems from using reroot, which is required
for them to install firmware updates.
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D13583
to match the change in its declaration. Change the declaration back to
"byte color" since setting of the border color is not supported for more
than 256 colors.
VGLBitmapString() and VGLSetBorder() so as to not truncate to 8 bits.
Complete the corresponding fix for VGLGetXY() and VGLPutXY() (parts
of the man page were out of date).
Since the font format is undocumented, it is unclear how non-multiples
of 8 should be padded to bytes in the font file. Use the same
representation as bdf text format (big- endian, with padding in the
lower bits).
There seems to be no alternative to reading each plane independently using
3 slow i/o's per plane (this delivers 8 nearby pixels, but we don't buffer
the results so run 8 times slower than necessary.
All the code for this was there, but it was ifdefed out and replaced by
simpler code that cannot work in planar modes. The ifdefed out code
was correct except it was missing a volatile declaration, so compilers
optimized the multiple dummy reads in it to a single read.
While geom_flashmap has always supported label names for its slices, it does
so by appending "s.labelname" to the provider device name, meaning you still
have to know the name and unit of the hardware device to use the labels.
These changes add support for device-independent geom_flashmap labels, using
the standard geom_label infrastructure. geom_flashmap now creates a softc
struct attached to its geom, and as it creates slices it stores the label
into an array in the softc. The new geom_label_flashmap uses those labels
when tasting a geom_flashmap provider.
Differential Revision: https://reviews.freebsd.org/D19535
are successfully returned by the card (usually due to an abort being issued
as part of timeout recovery). Remove what amounts to an insufficient
KASSERT, and don't overwrite the state value. State should probably be
re-designed, and that will be done with a future commit.
Reported by: phk, bei.io
Reviewed by: imp, mav
Differential Revision: D19677
Support for 16-bit and 32-bit Truecolor modes was supposed to be
complete in r70991 of main.c and in nearby revisions for other files, but
it was broken by the overruns in most cases (all cases were the mouse
is enabled, and most cases where bitmaps are used). r70991 also
uninintentionally added support for depths 9-15, 17-23 and 25-31.
Depth 24 was more obviously broken and its support is ifdefed out. In
the other ranges, only depth 15 is common. It was broken by buffer
overruns in all cases.
bitmap.c:
- the static buffer was used even when it was too small (but it was
large enough to often work accidentally in depth 16)
- the size of the dynamically allocated buffer was too small
- the sizing info bitmap->PixelBytes was not inititialzed in the bitmap
constructor. It often ended up as 0 for MEMBUFs, so using it in more
places gave more null pointer accesses. (It is per-bitmap, but since
conversion between bitmaps of different depths is not supported (except
from 4 bits by padding to 8), it would work better if it were global.)
main.c:
- depths were rounded down instead of up to a multiple of 8, so PixelBytes
was 1 too small for depths above 8 except 16, 24 and 32.
- PixelBytes was not initialized for 4-bit planar modes. It isn't really
used for frame buffer accesses in these modes, but needs to be 1 in
MEMBUF images.
mouse.c:
- the mouse cursor buffers were too small.
vgl.h:
- PixelBytes was not initialized in the static bitmap constructor. It
should be initialized to the value for the current mode, but that is
impossible in a static constructor. Initialize it to -1 so as to
fail if it is used without further initialization.
All modes that are supposed to be supported now don't crash in
nontrivial tests, and almost work. Missing uses of PixelBytes now
give in-bounds wrong pointers instead of overruns. Misconversions of
bitmaps give multiple miscolored mouse cursors instead of 1 white one,
and similarly for bitmaps copied through a MEMBUF.
The values of the d_slice and d_partition fields of a disk_devdesc have a
few values with special meanings in the disk_open() routine. Through various
evolutions of the loader code over time, a d_partition value of -1 has
meant both "use the first ufs partition found in the bsd label" and "don't
open a bsd partition at all, open the raw slice."
This defines a new special value of -2 to mean open the raw slice, and it
gives symbolic names to all the special values used in d_slice and
d_partition, and adjusts all existing uses of those fields to use the new
constants.
The phab review for this timed out without being accepted, but I'm still
citing it below because there is useful commentary there.
Differential Revision: https://reviews.freebsd.org/D19262
There are only 19 bytes available for the name of an interrupt plus the
name(s) of handlers/drivers using it. There is a mechanism from the days of
shared interrupts that replaces some of the handler names with '+' when they
don't all fit into 19 bytes.
In modern times there is typically only one device on an interrupt, but long
device names are the norm, especially with embedded systems. Also, in systems
with multiple interrupt controllers, the names of the interrupts themselves
can be long. For example, 'gic0,s54: imx6_anatop0' doesn't fit, and
replacing the device driver name with a '+' provides no useful info at all.
When there is only one handler but its name was too long to fit, this
change truncates enough leading chars of the handler name (replacing them
with a '-' char to indicate that some chars are missing) to use all 19
bytes, preserving the unit number typically on the end of the name. Using
the prior example, this results in: 'gic0,s54:-6_anatop0' which provides
plenty of info to figure out which device is involved.
PR: 211946
Reviewed by: gonzo@ (prior version without the '-' char)
Differential Revision: https://reviews.freebsd.org/D19675
args (neither MAP_PRIVATE nor MAP_SHARED). It was broken in r271635
and/or r271724 by stricter checking. The compatibility code in r271724
doesn't work for my old binaries (actually new binaries with old
libraries).
PR: needed to test the fix for PR 162373
For 32-bit Linuxulator, ipc() syscall was historically
the entry point for the IPC API. Starting in Linux 4.18, direct
syscalls are provided for the IPC. Enable it.
MFC after: 1 month
