VOLUME_UP and VOLUME_DOWN as observed on my Sun Type 7 USB keyboard, and
according to the documentation mentioned above.
"works here" macallan@ and myself
unaligned data address causing the fault - this will always fail.
If anybody knows a portable way to get the data address involved in the
fault, please fix the test case as originally intended.
---
MBR_BOOTCODE
optional MBR bootcode which should be installed by fdisk(8)
(default: empty)
- specified MBR_BOOTCODE must exist in ${DESTDIR}/usr/mdec
- if MBR_BOOTCODE is not specified,
MBR_DEFAULT_BOOTCODE (default: mbr) will be used
if the target ${MACHINE} has the one in /usr/mdec
INSTALLBOOTOPTIONS
options passed to installboot(8), e.g., -o console=com0
(default: empty)
---
Proposed by Brook Milligan on current-users@:
http://mail-index.NetBSD.org/current-users/2012/04/16/msg019892.html
Also make USE_MBR work on ${MACHINE}s which don't have the default
/usr/mdec/mbr bootcode. (no such port has the liveimage target yet though)
XXX: tools fdisk(8) implicitly uses host's /usr/mdec/mbr for the default
XXX: bootcode even for non-x86 targets if host is x86
like pm_kernel_cpus. Remove unecessary intersection with kcpuset_running.
Do not reset tp_userpmap if pmap_kernel().
- Remove pmap_tlb_mailbox_t wrapping, which is pointless after recent changes.
- pmap_tlb_invalidate, pmap_tlb_intr: constify for packet structure.
Adjust various man pages and other documentation to point to capfile(5)
instead of termcap(5).
Remove getcap(3) as curses hasn't been building it for a long time.
Punt wrterm.c as tset no longer uses it.
instead, which is the main thread instead of the currently executing thread
which is not what we want, since we've been running and nother thread might
have just started.
kcpuset(9) and thus replace hardcoded CPU bitmasks. This removes the
limitation of maximum CPUs.
- Support up to 256 CPUs on amd64 architecture by default.
Bug fixes, improvements, completion of Xen part and testing on 64-core
AMD Opteron(tm) Processor 6282 SE (also, as Xen HVM domU with 128 CPUs)
by Manuel Bouyer.
so KASSERT(!mutex_owned()) shouldn't be used to assert that the current
LWP does not have the mutex. Compilation problem: explicitly include
sys/mutex.h from rnd.h so evbarm builds again.
be NULL), so that transport-specific details of transfer mode setting/printing
can be handled more easily.
Move scsipi_async_event_xfer_mode() and scsipi_print_xfer_mode() to
scsi_base.c and split in parallel scsi and FC/SAS parts.
size of struct scsipi_bustype has changed, welcome to 6.99.5
copying the passed string (which is not ToG compliant), instead of using
it directly in the environment arrat as it should. Needs to be pulled up
to NetBSd-6.
That one is tedious to test under x86: alignment exceptions are
not reported by this architecture unless you ask for them explicitely (by
setting the PSL_AC bit). The brokenness does not end there: %cr2 should
contain the address where the unaligned access occured, alas, it does not.
I am not aware of other architectures where this could happen. Still, my
knowledge is limited; if there is one, feel free to send me a mail and I
will update the test accordingly.
Adding insult to injury, this test can fail in various funny ways with VMs:
- under x86 QEMU, no trap() happens. As ring 3 code stays almost untouched by
QEMU VMM, I suppose the exception can only be triggered when the host
itself is capable of catching unaligned accesses.
- under Virtual Box with HVM support, i386 works fine, but amd64 fails with a
SIGILL (Illegal instruction) that happens right before entering the
signal handler. No idea why, and trying to debug it with gdb freezes the VM
(including ddb breaks).
Anyway, tested with:
- i386: P4 host, anita, Virtual Box HVM (Mac OS X)
- amd64: anita, Virtual Box HVM (Mac OS X)
XXX I would appreciate if someone could test it under a real amd64 host with
an up-to-date kernel, so I can reasonably assume that the culprit is
Virtual Box and not our amd64 port (my test machine being off line
I cannot do it myself). Results from other arches would be a plus too.
Initial issue reported by Nicolas Joly on port-amd64. Thanks!
check for potentially exploitable overflows in asn1_d2i_read_bio
BUF_mem_grow and BUF_mem_grow_clean. Refuse attempts to shrink buffer
in CRYPTO_realloc_clean. (CVE-2012-2110)
