Pull up following revision(s) (requested by riastradh in ticket #2000):
external/cddl/osnet/dev/sdt/sdt.c: revision 1.25
dtrace_sdt: Don't ignore the first stack frame in sdt probes.
The aframes argument to dtrace_probe_create gives the number of stack
frames that are ignored in stack(), the first frame of which is
`caller'.
This is for, e.g., profiler interrupts where the interrupt frame
itself isn't interesting; it's the code that was interrupted that was
interesting (hence profile_aframes = PROF_ARTIFICIAL_FRAMES is often
nonzero, or even several frames deep).
But for sdt, the direct caller is the interesting part -- when we
have something like:
foo()
[16 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1229):
external/cddl/osnet/dev/sdt/sdt.c: revision 1.25
dtrace_sdt: Don't ignore the first stack frame in sdt probes.
The aframes argument to dtrace_probe_create gives the number of stack
frames that are ignored in stack(), the first frame of which is
`caller'.
This is for, e.g., profiler interrupts where the interrupt frame
itself isn't interesting; it's the code that was interrupted that was
interesting (hence profile_aframes = PROF_ARTIFICIAL_FRAMES is often
nonzero, or even several frames deep).
But for sdt, the direct caller is the interesting part -- when we
have something like:
foo()
[16 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #167):
external/cddl/osnet/dev/sdt/sdt.c: revision 1.25
dtrace_sdt: Don't ignore the first stack frame in sdt probes.
The aframes argument to dtrace_probe_create gives the number of stack
frames that are ignored in stack(), the first frame of which is
`caller'.
This is for, e.g., profiler interrupts where the interrupt frame
itself isn't interesting; it's the code that was interrupted that was
interesting (hence profile_aframes = PROF_ARTIFICIAL_FRAMES is often
nonzero, or even several frames deep).
But for sdt, the direct caller is the interesting part -- when we
have something like:
foo()
[16 lines not shown]
PR bin/59942 Fix handling of count=0
Apply (modified) patch from Andrus Suvalau in PR bin/59942
(The actual change is very simple)
This looks to have been broken since version 1.1 - simply short
circuiting processing because count==0 is wrong, there is much
else that needs to be done before copying nothing (including
verifying args that follow it).
It is almost certain that files=0 will need a similar change.
That one looks like it will be even easier - simply deleting
the test for files_cnt being 0 in args.c/f_files() should be
enough I believe - but as I haven't seen any system with a
tape drive in decades, I am unable to test any changes properly,
so I will leave that to someone who can test it properly.
PR bin/59942 Add tests for count=0
Add zerocount test case from Andrus Suvalau in PR bin/59942
Test that dd count-o skip=N actually skips before copying nothing
Add another test case (zerocountextras) to test several other things
that the implementation of count=0 was getting wrong (see addenda
to the same PR)
These new test cases are expected to fail until bin/dd has been updated
(which will happen soon after this test has been committed and
had time to settle)
Clean up this test a bit.
1. Use printf instead of echo
2. Use $( ) instead of ``
3. Check exit status of commands being tested
4. Misc other stuff (use -ne rather than != when comparing numbers, ...)
fdt_dma: extend dma_req with controller-specific ancillary data
To support the i.MX23's DMA controller, it is necessary to pass
controller-specific ancillary data (i.MX23: pio words) to the controller with
each request.
Apply patch, requested by bouyer in ticket #1998:
sys/arch/i386/i386/vector.S (apply patch)
xen: PR 58561: make sure kernel preemption won't cause write of
evtchn_upcall_mask of the wrong virtual CPU.
(file accidently missed in the original commit for ticket #1998)
Pull up following revision(s) (requested by skrll in ticket #1228):
tools/compat/configure.ac: revision 1.113
tools/compat/compat_defs.h: revision 1.131
tools/compat/configure: revision 1.111
(all via patch)
tools build fixes for <sys/endian.h> changes, from skrll
Pull up following revision(s) (requested by skrll in ticket #166):
tools/compat/configure.ac: revision 1.113
tools/compat/compat_defs.h: revision 1.131
tools/compat/configure: revision 1.111
tools build fixes for <sys/endian.h> changes, from skrll
Pull up following revision(s) (requested by riastradh in ticket #1227):
sys/dev/pci/if_iwm.c: revision 1.89
Fix DMA sync sizes.
Don't panic for inconsistent queue counter, just print an error to console.
Pull up following revision(s) (requested by riastradh in ticket #1999):
sys/dev/pci/if_iwm.c: revision 1.89
Fix DMA sync sizes.
Don't panic for inconsistent queue counter, just print an error to console.
Pull up following revision(s) (requested by bouyer in ticket #165):
sys/arch/amd64/include/frameasm.h: revision 1.56
sys/arch/xen/x86/xen_intr.c: revision 1.32
sys/arch/i386/include/frameasm.h: revision 1.36
sys/arch/i386/i386/locore.S: revision 1.206
sys/arch/amd64/amd64/cpufunc.S: revision 1.71
sys/arch/i386/i386/i386_trap.S: revision 1.25
sys/arch/i386/i386/spl.S: revision 1.59
sys/arch/amd64/amd64/locore.S: revision 1.236
sys/arch/amd64/amd64/spl.S: revision 1.50
sys/arch/x86/x86/fpu.c: revision 1.94
sys/arch/amd64/amd64/amd64_trap.S: revision 1.56
fputrap: enable interrupts before panic(), for consistency.
noticed while working on PR port-xen/58561
updating curcup()->ci_vcpu->evtchn_upcall_mask requires 2 intructions, e.g.
movq CPUVAR(VCPU),%r ## temp_reg ;
movb $1,EVTCHN_UPCALL_MASK(%r ## temp_reg);
With preemption enabled we may be moved to another CPU between the
2 intructions and we end up updating the evtchn_upcall_mask of another VCPU
[26 lines not shown]
