variable was assigned the image offset in bytes and not in blocks
(i.e. sectors). This had image_data() return FALSE, which meant that
we didn't assign a cluster when we needed and also meant that we
didn't write parts of the L2 table when we should have. The result
being that the actual data clusters were written at the wrong offset.
Improve support for QCOW version 2. We're having the right layout
and even know how many refcnt blocks we need. All we need to do is
populate the refcnt blocks for every cluster we write and allocate
a cluster when we need a new refcnt block. The allocation part is
tricky in that it'll interleave with the assignment of clusters to
L2 tables and data. Since version 2 is not quite done, keep it
compiled out for now.
and explain some internal working of the library, neccessary to
understand the knobs effects.
Reviewed by: bjk, pluknet
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
stack into the stacks of the created threads. Add knob
LIBPTHREAD_SPLITSTACK_MAIN to restore the older behaviour.
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
- Remove tools/regression/pjdfstest
- Add upgrade directions for contrib/pjdfstest
- Add a note to UPDATING for the move (the reachover Makefiles are coming
soon)
Functional differences:
- ftruncate testcases are added from upstream (github)
Non-functional differences:
- The copyright for the project has been updated to 2012
- pjd's contact information has been updated
Discussed with: -testing, jmmv, pjd
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
1. Do not install FILES/SCRIPTS multiple times if PROGS is specified; this is
already handled via bsd.prog.mk when it's called recursively (PR: 191055,
191955).
2. Some variables, like BINDIR and PROGNAME, default to a value if unset
whereas others get appended to, like CFLAGS. Add support for the former case
(PR: 191056)
3. Make "checkdpadd" and "clean" available targets for recursive execution.
Reviewed by: marcel, sjg
Phabric: D822
PR: 191055, 191056, 191955
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
depend on the .MAKE special target
This will allow users to do something like the following to print out the
results of the running the simulated make target with bmake, like some of the
other top-level make targets in Makefile.inc1:
% make -f Makefile.inc1 -n distribution TARGET=i386 TARGET_ARCH=i386
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
addresses. (The chip doesn't really care, it's just that it needs to be
told explicitly if unicast DMACs are checked for "hits" in the hash that
is used after the TCAM entries are all used up).
or I_T NEXUS LOSS, clear all minor UAs for the LUN, redundant in this case.
All SAM specifications tell that target MAY do it, but libiscsi initiator
seems require it to be done, terminating connection with error if some more
UAs happen to be reported during iSCSI connection.
MFC after: 3 days
made automountd(8) mix them up: trying to access the second one would
trigger mount for the first one.
foo host:/foo
foobar host:/foobar
PR: 193584
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
the wired attribute of the mapping. As result, some pmap
implementations clear the wired state of the page table entries, which
breaks invariants and allows the entries to be lost. Avoid calling
vm_map_pmap_enter() for the MADV_WILLNEED on the wired entry, the
pages must be already mapped.
Noted and reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Since the code stats and mkdirs in 2 separate steps, it is possible that
the directory will be created in the meantime by something else (e.g.
concurrent install).[1]
While here alter the code to properly report stat failure, previously it
would always claim it was mkdir which failed.
Noted by: royger [1]
MFC after: 1 week
made autofs mix them up: the second one wasn't visible in ls(1) output,
and trying to access it would trigger mount for the first one.
foobar host:/foobar
foo host:/foo
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
For now restrict it to amd64. Other architectures might be
re-added later once tested.
Remove the drivers from the global NOTES and files files and move
them to the amd64 specifics.
Remove the drivers from the i386 modules build and only leave the
amd64 version.
Rather than depending on "inet" depend on "pci" and make sure that
ixl(4) and ixlv(4) can be compiled independently [2]. This also
allows the drivers to build properly on IPv4-only or IPv6-only
kernels.
PR: 193824 [2]
Reviewed by: eric.joyner intel.com
MFC after: 3 days
References:
[1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
