Hi again
thanks to all who replied. From what I've learned here, and after re-reading
the code, there are possible races in the event code itelf that could
cause events to be missed, in the multiprocessor case with instruction
reordering by the processors.
I tried to insert "lock;" instructions in sensible places in the assembly,
but it seems that not all instructions can have a lock prefix.
If I put a lock before a movb or a testb, the assembler doesn't complain but
the kernel panics with a "privileged instruction fault trap" on the
instruction.
Does it mean that these instructions can't be reordered by the CPU, so the
lock prefix doesn't make sense ?
If not, I guess a 
lock
addl $0, 0(%esp)
would work (this is what x86_lfence() does) ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--