Pmctools: Known Bugs

The current bug list may be viewed at the following issue tracker.

Old bug list

This page lists known bugs in the PMC code.

Profiling of multi-threaded programs has bugs. The symptoms are that multi-threaded programs do not exit cleanly. (Reported by David Fresse).
pmcstat -P appears to be missing samples (reported by Niklas Sorensson).
PCSAMPLE event logs should indicate a CPU# that the sample was taken on. We could reuse the pl_usermode 'int' field for this, keeping the CPU# in a higher numbered bitfield.
On the AMD64, an INVARIANTS-enabled kernel reports a memory leak at module unload time for memory type "pmc". It appears that a log buffer is being leaked (from the size of the leak).
Forcibly unloading the hwpmc(4) module when it is in use shows up other leaks. (Reported by wkoszek@).
A WITNESS/INVARIANTS enabled AMD64 kernel reports the following lock-order reversal:

hwpmc: TSC/1/0x20 K8/4/0x1ff
lock order reversal:
1st 0xffffffff80564ea0 pmc shared lock (pmc shared lock) @ /home/fcpi/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:2527
2nd 0xffffffff80564fc0 proctree (proctree) @ /home/fcpi/src/sys/kern/kern_fork.c:301
KDB: stack backtrace:
witness_checkorder() at witness_checkorder+0x4f9
_sx_slock() at _sx_slock+0x4d
fork1() at fork1+0xf5
kthread_create() at kthread_create+0x96
pmclog_configure_log() at pmclog_configure_log+0x12f
pmc_syscall_handler() at pmc_syscall_handler+0x1e6
syscall() at syscall+0x215
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (0, FreeBSD ELF64, nosys), rip = 0x8008dfa9c, rsp = 0x7fffffffe4e8, rbp = 0x7fffffffe510 ---

Only dump kernel and process mappings once per owner process and only when a sampling PMC is configured. Currently we always log mappings, but this information is useless for log files that are being used in counting mode.
(reported by v.sriram) pmc_start(3) sometimes does not cause the hardware counter to be started. Inserting a sleep(3) call after the pmc_start() call makes stuff work. I thought I had fixed this bug!
(reported by ssouhlal@) running pmcstat -S on a dual AMD64 results in an occasional double fault. This is mitigated by using a separate stack for NMI interrupts. Bumping up the KSTACK size does not help.
(reported by rwatson) pmcstat -S on a P4 HTT box caused a stray NMI if interrupted with a ^C. See -current for analysis: the NMI is probably being handled after the WRMSR in p4_stop_pmc turns off the PMC. Issue 30
(reported by alfred) hwpmc does not deal with sparse CPU numbering correctly.