#
95ee2897 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
ee06552d |
|
02-Jun-2023 |
John Baldwin <jhb@FreeBSD.org> |
<sys/memrange.h>: Include <sys/ioccom.h>. This makes this header more self-contained. Reviewed by: imp, markj Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D40387
|
#
c9114f9f |
|
23-Mar-2021 |
Mitchell Horne <mhorne@FreeBSD.org> |
Add new vnode dumper to support live minidumps This dumper can instantiate and write the dump's contents to a file-backed vnode. Unlike existing disk or network dumpers, the vnode dumper should not be invoked during a system panic, and therefore is not added to the global dumper_configs list. Instead, the vnode dumper is constructed ad-hoc when a live dump is requested using the new ioctl on /dev/mem. This is similar in spirit to a kgdb session against the live system via /dev/mem. As described briefly in the mem(4) man page, live dumps are not guaranteed to result in a usuable output file, but offer some debugging value where forcefully panicing a system to dump its memory is not desirable/feasible. A future change to savecore(8) will add an option to save a live dump. Reviewed by: markj, Pau Amma <pauamma@gundo.com> (manpages) Discussed with: kib MFC after: 3 weeks Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D33813
|
#
2d838cd8 |
|
02-Sep-2020 |
Mark Johnston <markj@FreeBSD.org> |
Add the MEM_EXTRACT_PADDR ioctl to /dev/mem. This allows privileged userspace processes to find information about the physical page backing a given mapping. It is useful in applications such as DPDK which perform some of their own memory management. Reviewed by: kib, jhb (previous version) MFC after: 2 weeks Sponsored by: Juniper Networks, Inc. Sponsored by: Klara Inc. Differential Revision: https://reviews.freebsd.org/D26237
|
#
7f417bfa |
|
03-May-2016 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/sys: minor spelling fixes. While the changes are minor, these headers are very visible. MFC after: 2 weeks
|
#
2fea6431 |
|
17-Jan-2011 |
Jung-uk Kim <jkim@FreeBSD.org> |
Add reader/writer lock around mem_range_attr_get() and mem_range_attr_set(). Compile sys/dev/mem/memutil.c for all supported platforms and remove now unnecessary dev_mem_md_init(). Consistently define mem_range_softc from mem.c for all platforms. Add missing #include guards for machine/memdev.h and sys/memrange.h. Clean up some nearby style(9) nits. MFC after: 1 month
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
c66d2b38 |
|
16-Mar-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
a20ad05b |
|
04-Aug-2004 |
Mark Murray <markm@FreeBSD.org> |
Fix module builds for i386 and amd64.
|
#
93f39ea8 |
|
15-Sep-2002 |
David Malone <dwmalone@FreeBSD.org> |
Some BIOSs are using MTRR values that are only documented under NDA to control the mapping of things like the ACPI and APM into memory. The problem is that starting X changes these values, so if something was using the bits of BIOS mapped into memory (say ACPI or APM), then next time they access this memory the machine would hang. This patch refuse to change MTRR values it doesn't understand, unless a new "force" option is given. This means X doesn't change them by accident but someone can override that if they really want to. PR: 28418 Tested by: Christopher Masto <chris@netmonger.net>, David Bushong <david@bushong.net>, Santos <casd@myrealbox.com> MFC after: 1 week
|
#
b0f4bb51 |
|
14-Apr-2002 |
David Malone <dwmalone@FreeBSD.org> |
Make the MTRR code a bit more defensive - this should help people trying to run X on some Athlon systems where the BIOS does odd things (mines an ASUS A7A266, but it seems to also help on other systems). Here's a description of the problem and my fix: The problem with the old MTRR code is that it only expects to find documented values in the bytes of MTRR registers. To convert the MTRR byte into a FreeBSD "Memory Range Type" (mrt) it uses the byte value and looks it up in an array. If the value is not in range then the mrt value ends up containing random junk. This isn't an immediate problem. The mrt value is only used later when rewriting the MTRR registers. When we finally go to write a value back again, the function i686_mtrrtype() searches for the junk value and returns -1 when it fails to find it. This is converted to a byte (0xff) and written back to the register, causing a GPF as 0xff is an illegal value for a MTRR byte. To work around this problem I've added a new mrt flag MDF_UNKNOWN. We set this when we read a MTRR byte which we do not understand. If we try to convert a MDF_UNKNOWN back into a MTRR value, then the new function, i686_mrt2mtrr, just returns the old value of the MTRR byte. This leaves the memory range type unchanged. I have seen one side effect of the fix, which is that ACPI calls after X has been run seem to hang my machine. As running X would previously panic the machine, this is still an improvement ;-) I'd like to MFC this before the 4.6 code freeze - please let me know if it causes any problems. PR: 28418, 25958 Tested by: jkh, Christopher Masto <chris@netmonger.net> MFC after: 2 weeks
|
#
664a31e4 |
|
28-Dec-1999 |
Peter Wemm <peter@FreeBSD.org> |
Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL" is an application space macro and the applications are supposed to be free to use it as they please (but cannot). This is consistant with the other BSD's who made this change quite some time ago. More commits to come.
|
#
ac3595b0 |
|
30-Aug-1999 |
Mike Smith <msmith@FreeBSD.org> |
Make the error return from mem_range_attr_get actually do something useful (return an error to the caller)
|
#
4a034f21 |
|
30-Apr-1999 |
Mike Smith <msmith@FreeBSD.org> |
Add a hook that can be called to initialise a slave processor's memory range attributes after they have been extracted from the master. Hook up the i686 MP code to do this for each AP. Be more careful about printing the default memory type for the i686. Suggestions from: luoqi
|
#
f5973459 |
|
06-Apr-1999 |
Mike Smith <msmith@FreeBSD.org> |
Generic memory range attribute interface.
|