|
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc |
|
| #
d30a28dd |
| 01-Feb-2018 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Fix kernel minidumps
* Refactor minidumps. Fix an overflows due to KVM now being 8TB, fix
improper pdp[] array calculations (cropped up when we want to > 1 PML4e
entry for the kernel),
kernel - Fix kernel minidumps
* Refactor minidumps. Fix an overflows due to KVM now being 8TB, fix
improper pdp[] array calculations (cropped up when we want to > 1 PML4e
entry for the kernel), and refactor the page table entry handling code
to improve efficiency and reduce the dump size.
If we had kept the original pte mapping in the minidump it would have
required ~16GB of disk space JUST to hold a pte array that is mostly 0's.
Now it only requires ~2MB.
Dumping performance is improved because the page table array is primarily
flushed to storage in 4KB block sizes, and now only 2MB or so is written
out in this manner.
* minidump now dumps the PDP array of PD entries (representing 1GB each)
for the entire system VA space (user and kernel) - 256TB. This requires
512*512*8 = 2MB of storage.
PD pages and PT pages are no longer linearized into an array in the
minidump. Instead, their physical addresses are included in the dump
map and libkvm accesses the PTEs through the physical map.
NOTE: Only kernel memory proper is actually populated at this time, but
this leaves the door open for e.g. dumping more information without having
to change the minidump format again.
* Revamp the minidump header, magic string, and version to address the new
reality. libkvm should still be able to recognize the old minidump
format, as well as now the new one.
Reminded-by: everyone
show more ...
|
|
Revision tags: v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0 |
|
| #
86d7f5d3 |
| 26-Nov-2011 |
John Marino <draco@marino.st> |
Initial import of binutils 2.22 on the new vendor branch
Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.
|
|
Revision tags: v2.12.0, v2.13.0, v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0 |
|
| #
be66ad11 |
| 06-Dec-2009 |
Alex Hornung <ahornung@gmail.com> |
dump - Bring in FreeBSD's dumping (new dumps & minidumps)
* Bring in FreeBSD's dumps and minidumps, which use an ELF header instead of
a raw dump.
* Adapt to our needs by, for example, saving the
dump - Bring in FreeBSD's dumping (new dumps & minidumps)
* Bring in FreeBSD's dumps and minidumps, which use an ELF header instead of
a raw dump.
* Adapt to our needs by, for example, saving the dumppcb and dumpthread.
Obtained-from: FreeBSD
show more ...
|