Charles Hannum <mycroft@gnu.ai.mit.edu> writes:

>Andrew Gillham <gillhaa@ghost.whirlpool.com> writes:

>> 
>> FWIW, the OpenBSD webpage mentions it fixed "a major i386 interrupt race"
>> or something like that.  Perhaps it's related?  Maybe you could boot one
>> of their kernels and see if the problem is just as bad.

>Don't take this personally...

>That comment on their web page is, quite frankly, pure bullshit.
>AFAIK, it was written when a race condition in AST processing was
>fixed.  Ignoring that the bug was identified by a NetBSD developer and
>fixed quite some time ago, and that it only affects ASTs and thus
>could not possibly be related to what Jukka is talking about, it's
>also extremely minor and completely self-correcting.


What's the PR number on this?

I'm seeing over two orders of magnitude variation in signal-delivery
rate, between a process signalling itself (a la lmbench), and
signalling a non-current process (e.g., from a hardware interrupt.)  I
wonder if this AST problem could be related.  I can't find a PR that
seems to match Charles' description. Is it in the NetBSD PR database?