On 27 May 2001, Andi Kleen wrote:
> I think the right way to fix it is to do a final atomic check for
> softirqs when the kernel is exited. To be atomic this check neededs to
> be done with interrupts off until the kernel exited. [...]
check out my first softirq patch, it does exactly this. (bu
"David S. Miller" <[EMAIL PROTECTED]> writes:
> > the attached softirq-2.4.5-B0 patch fixes this problem by calling
> > do_softirq() from local_bh_enable() [if the bh count is 0, to avoid
> > recursion].
>
> Yikes! I do not like this fix.
>
> I'd rather local_bh_enable() not become a more
On Sun, 27 May 2001, David S. Miller wrote:
> Hooray, some sanity in this thread finally :-)
[ finally i had some sleep after a really long debugging session :-| ]
> > the attached softirq-2.4.5-B0 patch fixes this problem by calling
> > do_softirq() from local_bh_enable() [if the bh count
Ingo Molnar writes:
> the bug/misbehavior causing bad latencies turned out to be the following:
> if a hardirq triggers a softirq, but syscall-level code on the same CPU
> disabled local bhs via local_bh_disable(), then we 'miss' the execution of
> the softirq, until the next IRQ. (or next di
4 matches
Mail list logo
