There's a lot of waits inside tools, but nothing that promises that we haven't
started doing the next subdir in the top level.
Shows up as warnings in the cleandir stage on releng builds:
cleandir ===> external/mit/xorg/server/drivers/xf86-video-suncg6
cleandir ===> lib/libpam/modules/pam_deny
sh: /home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk: not found
nbmake[9]: "../../Makefile.xf86-driver" line 23: warning: "/home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk '/^PACKAGE_VERSION=/ { match($1, "[0-9]+\\.[0-9]+\\.[0-9]+"); version = substr($1, RSTART, RLENGTH); } END { print version }' /home/source/ab/HEAD-llvm/xsrc/external/mit/xf86-video-ati/dist/configure" returned non-zero status
sh: /home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk: not found
similar to the rest of the file.
I'm wondering if I'm not fixing a huge bug here. The ECX8 value we were
using was wrong: ECX8 is bit 1, not bit 0. Bit 0 is ALTINST, an alternate
ISA, which is now known to be backdoored.
So it looks like we were explicitly enabling the backdoor.
Not tested, because I don't have a VIA cpu.
software to effortlessly create and manage virtual machines via NVMM.
It is mostly complete, only nvmm_assist_mem needs to be filled -- I have
a draft for that, but it needs some more care. This Mem Assist should
not be needed when emulating a system in x2apic mode, so theoretically
the current form of libnvmm is sufficient to emulate a whole class of
systems.
Generally speaking, there are so many modes in x86 that it is difficult
to handle each corner case without introducing a ton of checks that just
slow down the common-case execution. Currently we check a limited number
of things; we may add more checks in the future if they turn out to be
needed, but that's rather low priority.
Libnvmm is compiled and installed only on amd64. A man page (reviewed by
wiz@) is provided.
Throw away length 1 packets without a warning: we already throw away messages
with (len < sizeof(*msg)) a short while after, but print a warning.
Hardware is allowed to pad USB packets which % wMaxPacketSize length with
such packets for hardware implementation simplicity reasons.
This is described in
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/usb-short-packets
From Artturi Alm in tech-net, with amendment from pgoyette.
The command shows only 256 addresses at maximum even if a bridge caches more
addresses. It occurs because the kernel doesn't return an error if the command
passes a short buffer that can't store all cached addresses; the kernel fills
cached addresses as much as possible and returns it without telling that the
result is truncated.
Fix the issue by telling a required size of a buffer if a buffer passed from the
command is not enough, which lets the command retry with an enough buffer.
Reported by k-goda@IIJ
this is almost a direct copy of the arm code, which is simply
as the basic structures about physical memory are the same
between arm and arm64. the main change i made was to use
the direct map instead of a virtual dump page that is remapped
to whatever physical page is being dumped.
i also changed the existing cpu_kcore_hdr_t to include the
missing number of ram segments.
note that this is not a complete solution for crash dumps yet,
as the libkvm code needs some work. i'm fairly positive that
this side is correct, as i can see the data i expect to see,
but libkvm's _kvm_kvtop() function returns garbage so far.
there is no "minidump" support here yet, ala amd64, but we
probably want it eventually.
ok skrll@.
under the new binutils: error: PHDR segment not covered by LOAD segment
[including bsd.init.mk includes ../Makefile.inc which disables PIE like
all the other bootloaders do]
prompts to exit when they're done, rather than forcing them to
turn into interactive shells and start reading input ...
Completes a part of the previous changes (just 10+ weeks late...)
Should fix the prompt expansion issue reported by Caóc on
current-users.
