appear to be never called:
(1) If a function is never called according to its call count but it
must have been called because its child time is nonzero, then print
it in the flat profile. Previously, if its call count was zero
then we only printed it in the flat profile if its self time was
nonzero.
(2) If a function has a zero call count but has a nonzero self or child
time, then print its total self time in the self time per call
column as a percentage of the total (self + child) time. It is
not possible to print the times per call in this case because the
call count is zero. Previously, this was handled by leaving both
per-call columns blank. The self time is printed in another column
but there was no way to recover the total time.
(1) partially fixes the case of the "never called" function main() and
prepares for (2) to apply to main() and other functions. Profiling
of main() was lost in the conversion from a.out to ELF, so main()'s
call count has always been zero for many years; then in the common
case where main() is a tiny function, it gets no profiling ticks, so
main() was completely lost in the flat profile.
(2) improves mainly cases like kernel threads. Most kernel threads
appear to be never called because they are always started before
userland can run to turn on profiling. As for main(), the fact that
they are called is not very interesting and their callers are
uninteresting, but their relative self time is interesting since they
are long-running.
Almost always printing percentages in the per-call columns would be
more useful than almost always printing 0.0ms. 0.1ms is now a long
time, so only very large functions take that long per call. The accuracy
per call can approach 1-10 nsec provided programs are run for about
100000 times as long as is necessary to get this accuracy with high
resolution kernel profiling.
you want to see, e.g., sendmail arguments mail(1) will use.
-H is not an independent flag, it's a modifier. Also explicitly
say that -H will cause mail(1) to exit as soon as it prints the headers.
MFC after: 5 days
the 5GHz band.
o Enable 802.11a channels scanning for 2915ABG adapters.
o Fix a typo (negociated->negotiated).
With hints from NetBSD.
MFC after: 2 days
- Rename vxfoo() functions to vx_foo() to improve readability and
consistency with other drivers.
- Prefix most the softc members with 'vx_' (the other members already had
the prefix).
- Switch to using callout_init_mtx() and callout_*() rather than
timeout() and untimeout().
- Add some missing calls to if_free() in some failure cases in vx_attach().
- Use if_printf() and remove the unit number from the softc.
- Remove uses of the 'register' keyword and spls.
- Add locked variants of vx_init() and vx_start().
- Add a mutex to the softc and lock it in various appropriate places.
- Setup the interrupt handler last during attach.
Tested by: imp
MFC after: 1 week
It allows to specify options for NFS root file system.
Currently supported options are: soft, intr, conn, lockd.
I'm adding this functionality mostly for 'lockd' option, which is only
honored when performing the initial mount and will be silently ignored
if used while updating the mount options.
This will allow to use flock(2) without the need of using varmfs or
rpc.lockd and friends.
Example of use:
boot.nfsroot.options="intr,lockd"
MFC after: 2 weeks
- http is a lightweight, multithreaded HTTP query tool, which performs
a timed measurement of the rate at which it can download files using
single-fetch HTTP/1.0. Other than specifying the IP and a URL path,
it requires zero configuration.
- httpd is a lightweight, multithreaded HTTP server tool, which exports
a single file of choice to the HTTP client, and responds with it no
matter what the request. Other than specifying the file to export,
it requires zero configuration.
The goal of these tools is to measure the network costs associated with
HTTP serving, rather than file system, HTTP protocol parsing, error
handling, etc, and as such, parts relating to less interesting components
of HTTP testing are intentionally omitted. Both are linked against
libpthread by default.
if (foo);
bar();
to:
if (foo)
bar();
Really, really nasty bug and a very nice catch of mine.
Unfortunately, I'll not become a hero of the day, because the code is
commented out.
module name to something that wouldn't conflict with
sys/dev/firewire/firewire.c.
Submitted by: Cai, Quanqing <caiquanqing at gmail dot com>
PR: kern/82727
MFC after: 3 days
Add a flags argument to wait_for_lock so that O_NONBLOCK can be
passed to open if a user doesn't want the open to sleep until the
lock becomes available.
Submitted by: Amir Shalem (partially modified)
- Don't keep the SPDIF state in the driver private struct since it
can be overriden by hand with pciconf(8), query it when needed instead.
Regarding the locking I let Ariff explain it himself:
---snip---
About the locking, that is what I'm intended to do since the beginning.
The reason I'm not putting that along since my first patchset was
because several people especially from amd46 camp reported that it cause
lots of LORs, which is weird considering that I've never encounter such
in a pretty much strict locking environment (i386). However, since our
previous discussion with Pyun YongHyeon about strict locking, I've
decided to bring it back for all the affected drivers, not just for
es137x. It turns out that the root of the problem was within dsp.c
during device open, which has been fixed since dsp.c revision 1.84.
---snip---
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
code which may help.
People with a ich compatible soundcard which want to help out should
change the "#if 1" to a "#if 0" and try if the soundcard still works.
Reports about working or not-working soundcards with this change to
multimedia@ please.
PR: 73987
- Remove references to cpu_critical_*() as they no longer exist.
- Explain that any preemptions that occur during a critical section are
deferred until the current thread exits the section.
- Remove a bogus example usage of a critical section.
- Note that one can interlock critical sections with spin mutexes in
certain situations.
MFC after: 3 days
for mutual exclusion:
A brief description of the problem:
1) Proc A picks up non-blocking lock on file X
2) Proc B attempts to pickup lock, fails then waits
3) Proc C attempts to pickup lock, fails then waits
4) Proc A releases lock
5) Proc B acquires lock, release it to pickup a non-blocking version
6) Proc C acquires lock, release it to pickup a non-blocking version
7) Both process B and C race each other to pickup lock again
This occurs mainly because the processes do not keep the lock after they have
been waiting on it. They drop it, attempt to re-acquire it. (They use the wait
to notify when the lock has become available then race to pick it up). This
results in additional CPU utilization during the race, and can also result
in processes picking locks up out of order.
This change attempts to correct this problem by eliminating the test/acquire
race and having the operating system handle it.
Reported by: kris
Tested by: kris
MFC after: 1 week
opt_device_polling.h
- Include opt_device_polling.h into appropriate files.
- Embrace with HAVE_KERNEL_OPTION_HEADERS the include in the files that
can be compiled as loadable modules.
Reviewed by: bde
