Hello,

Since kernel 2.5.60 the perfmon doesn't send SIGPROF to the designated
task. The problem can be solved by replacing perfmon.c by an older
version (eg: from a kernel 2.5.59). Upgrading to perfmon 1.4 doesn't
solve this bug.
My testcase is the program "realfeel4" from peter Chubb available on the
perfmon website (and attached to this e-mail). 

On a kernel 2.5.6{0,4} : 
# ./realfeel4
897.533 MHz
secondsPerTick=1.11417e-09
ticksPerSecond=897532585.408894
sample_period = 6282728
smallest = 18446744073709551615, largest = 0, nsamples = 0, sigma = 0,
sigmasqr = 0

While we should expect something like on a kernel 2.5.59:
# ./realfeel4 
897.527 MHz
secondsPerTick=1.11417e-09
ticksPerSecond=897526816.648964
sample_period = 6282687
smallest = 4859, largest = 8216, nsamples = 1426, sigma = 7948200,
sigmasqr = 44510579922
Mean 5573.77, stddev 382.946


nsamples = 0 means it didn't receive any signal: that's bad :-)

It seems the reason of the bug is the new, indirect, way to deliver the
signals. Now perfmon relies on do_notify_resume_user() to call
pfm_ovfl_block_reset(). I think the bugs stands somewhere there because
do_notify_resume_user() isn't called so often (when I tested it, only
once the timer of realfeel4 was over). Unfortunatly I didn't understand
all the mechanism of the signals and in addition ia64_leave_kernel() is
coded in assembly, that doesn't help ;-).

I would be very greetful if someone could have a look at it or, at
least, could give me some clues about how the kernel decides when to
call do_notify_resume_user().

Eric