yet determined, some PCI devices (at least fxp(4) and re(4)) sometimes
appear to perform DMA operations while this is happening, and we get
uncorrectable DMA errors. ideally, this "shouldn't happen", but none
of the investigation so far has reveal the problem, and my source
investigation of both opensolaris and linux show that their perform
the invaliation when unmapping.
"handles" PR#43274 as well as other issues...
XXX: candidate for netbsd-5
initial import of pigz 2.1.6 sources.
from http://www.zlib.net/pigz/:
"""
pigz, which stands for parallel implementation of gzip, is a fully functional replacement for gzip that exploits multiple processors and multiple cores to the
hilt when compressing data. pigz was written by Mark Adler, and uses the zlib and pthread libraries.
How is it pronounced?
I'm glad you asked. It is pronounced "pig-zee". It is not pronounced like the plural of pig.
"""
once i am done adding bz2 support to pigz, i plan to obsolete my usr.bin/gzip.
from http://www.zlib.net/pigz/:
"""
pigz, which stands for parallel implementation of gzip, is a fully functional replacement for gzip that exploits multiple processors and multiple cores to the hilt when compressing data. pigz was written by Mark Adler, and uses the zlib and pthread libraries.
How is it pronounced?
I'm glad you asked. It is pronounced "pig-zee". It is not pronounced like the plural of pig.
"""
once i am done adding bz2 support to pigz, i plan to obsolete my usr.bin/gzip.
problems with large mappings. i've seen my system hang for a total
of 45 seconds when radeondrm is opened by X11, and it is the checks
in this function that take so long.
the diff -u is more obvious than a description:
-X11FLAGS.VERSION= -DOSMAJORVERSION=1 -DOSMINORVERSION=6 # XXX
+X11FLAGS.VERSION= -DOSMAJORVERSION=5 -DOSMINORVERSION=99 # XXX
variable assignments from here, kernel memory does not leak to
userspace.
Bug found, a little bit suprisingly, by the atf ps test which failed
due to the column width between the -o holdcnt column being too
wide due to the contents displayed being garbage.
/null/dev: we're interested in /dev/pts and nullfs doesn't traverse
underlying mountpoints.
(I had code for nullfs mountpoint traversal in the tree i used to
test this originally... but I assume the rest of the world doesn't.
Before this change the test would still fail, but fail in the wrong
place and due to the wrong reason.)
which are known to fail, e.g.:
atf_tc_set_md_var(tc, "xfail", "PR kern/43456");
Expected failures do not count towards the ultimate pass/fail result
from the test run:
pain-rustique:39:~/<2>src/tests/fs/ptyfs> atf-run t_nullpts | atf-report
Tests root: /home/pooka/src/wholesrc2/src/tests/fs/ptyfs
t_nullpts (1/1): 1 test cases
nullrevoke: Expected failure: PR kern/43456
Summary for 1 test programs:
0 passed test cases.
0 failed test cases.
1 expected failures.
0 skipped test cases.
pain-rustique:40:~/<2>src/tests/fs/ptyfs> echo $?
0
However, an xfail test which passes will count as a failure, i.e.
xfail inverts test case success/fail. This way we can get a better
sense from the ultimate verdict of the NetBSD atf run by seeing if
there were any unexpected failures, i.e. new regressions.
This feature will be present in the upcoming atf 0.10 release,
possibly with finer grained control.
patch reviewed by jmmv
kernel ABI (i.e. not i386 or amd64). Due to the "half function,
half macro, all noodles" nature of pmap.h, it's too entangling and
too brittle to keep up with an ifdeffy MI implementation.
82G41, 82B43, E7221, 82965GME, and "Iron Lake". Device
types (i915, i965, G33, and G4X variants) from the Linux Intel AGP
driver, and (for 82G41) from Henry Bent in PR#42906.
There are a few more varieties that should be relatively low-hanging
fruit ("Pineview" and "Sandy Bridge"), but will require a little bit
of rejiggering of the "chiptype".
OK mrg@
after the file system is setup by VFS_MOUNT(). This way recursive vnode
locks are no longer needed here and mounts on null mounts no longer fail
as described in PR #43439 (mount_null panic: lockdebug_wantlock: locking
against myself).
Based on a proposal from and
Reviewed by: David A. Holland <dholland@netbsd.org>
* RUMP_MEMLIMIT works
* allocating memory with PR_NOWAIT will fail immediately if no memory
is available and PR_WAITOK will wait for memory to be available
the rump kernel by specifying RUMP_MEMLIMIT. In case allocation
over that limit is attempted, essentially pool reclaim and uvm_wait()
is done. The default is to allow to allocate as much as the host
will give.
XXX: uvm_km_alloc and malloc(9) do not currently conform. the
former is easy, the latter requires kern_malloc.c (rump malloc is
currently directly relegated to host malloc).
pooka