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)
CR0_WP (write protection bit) early on boot. Although it is set later via
cpu_init(), this can help tracking down invalid writes to pages mapped
as read only from ring 0.
No regression observed when booting under anita (QEMU) or a P4 host.
Depending on your hardware or setup, you may trigger code paths I have
overlooked. So if your machine does not start properly, or you get
page faults early during boot, please report them to me.
pass more informations about the bus:
- bustype_type has 2 different bytes, one holding the existing
SCSIPI_BUSTYPE_* (scsi, atapi, ata), and one for a per-SCSIPI_BUSTYPE_*
subtype. Introduce macros to build or extract bustype_type.
- for SCSIPI_BUSTYPE_SCSI, define subtypes for parallel SCSI, Fibre Channel,
SAS and USB, to specify the transport method. SCSIPI_BUSTYPE_SCSI_PSCSI
is 0 so that bustype_type value doesn't change for existing code
- for non-SCSIPI_BUSTYPE_SCSI busses there's no defined subtype yet,
so the bustype_type value doesn't change.
- provide scsi_fc_bustype, scsi_sas_bustype and scsi_usb_bustype
along with scsi_bustype to be used by bus driver where appropriate
- scsipi_print_xfer_mode(): more existing code under a
(SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_PSCSI) case, as
sync/wide parameters only make sense for parallel SCSI.
For (SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_FC) and
(SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_SAS), only print
tagged queing status if enabled. Just be silent for other
bustypes.
This change is prompted by this problem:
right now, FC (e.g. isp(4)) and SAS (e.g. mfi(4)) don't
do anything for ADAPTER_REQ_SET_XFER_MODE, and especially never
call scsipi_async_event(ASYNC_EVENT_XFER_MODE), so sd(4) always
runs untagged. Doing a scsipi_async_event(ASYNC_EVENT_XFER_MODE) with
appropriate parameters is enough to enable tagged queuing,
but then scsipi will print:
sd0: async, 8-bit transfers, tagged queueing
which is harmless (async, 8-bit transfers doens't make sense on SAS anyway)
but will confuse users. With this change scsipi will only print:
sd0: tagged queueing
which is correct.
In the long run, knowning the underlying transport in scsipi will
allow better handling of device which are not parallel SCSI.
Another change adding an extra callback to struct scsipi_bustype {}
will come (so that scsipi_print_xfer_mode(), which is SCSI-specific,
can be moved out of scsipi_base, and split into per-subtype callback),
but this will break kernel ABI and so is not suitable for
netbsd-6, so will be commmited later. The above is enough to get
tagged queuing on FC and SAS in netbsd-6.
rasops_get_cmap() which returns either the ANSI map or an R3G3B2 map,
depending on the rasops_info handed to it so drivers don't have to
duplicate this particular code snippet
