On 9 Feb, Bruce Evans wrote:
> Pagefaults occur in copyin() (called from addupc_task() which is called
> from ast()) while sched_lock is held. This is not good. Incrementing
> the profiling counters is supposed to be pushed to ordinary process
> context so that things like copyin() can work (they have to be able
> to fault in pages, so they have to be able to sleep...), so using
> sched_lock to lock things here is wrong.
Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not
familiar with the kernel and that's the only place I find something
related to profiling if I grep for "profil" and look at the results. If
yes, what is to to?
>> If I run it withhin X11, the machine deadlocks hard (no response from
>> the numlock led on the keyboard), withhin a virtual console I get a lot
>> of "kernel trap ..." and the program runs fine.
> It's surprising that it doesn't always deadlock.
First I thought I have a hardware problem, I was able to profile the
program 4-5 times withhin X11 at a day before. Without changing anything
except the options to the program I wasn't able to profile it later.
Loose bits sink chips.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message