Re: [patch] Re: Serial Oopsen caused by global IRQ chanes

[William Lee Irwin III <wli@holomorphy.com>]

On Sat, Jul 27, 2002 at 08:43:04PM +0200, Ingo Molnar wrote:
> the attached patch fixes a synchronize_irq() bug: if the interrupt is 
> freed while an IRQ handler is running (irq state is IRQ_INPROGRESS) then 
> synchronize_irq() will return early, which is incorrect.
> there was another do_IRQ() bug that in fact necessiated the bad code that
> caused the synchronize_irq() bug - we kept the IRQ_INPROGRESS bit set for
> not active interrupt sources - after they happen for the first time. Now
> the only effect this has is on i8259A irq handling - we used to keep these
> irqs disabled after the first 'spurious' interrupt happened.  Now what the
> i8259A code really wants to do IMO is to keep the interrupt disabled if
> there is no handler defined for that interrupt source. The patch adds
> exactly this. I dont remember why this was needed in the first place (irq
> probing? avoidance of interrupt storms?), but with the patch the behavior
> should be equivalent.

I'm having trouble with this one, I seem to get lots of these messages:

pu: 12, clocks: 99983, slice: 3029
CPU12<T0:99968,T1:60576,D:15,S:3029,C:99983>
CPU 12 IS NOW UP!
Bringing up 13
cpu: 13, clocks: 99983, slice: 3029
CPU13<T0:99968,T1:57552,D:10,S:3029,C:99983>
CPU 13 IS NOW UP!
Bringing up 14
cpu: 14, clocks: 99983, slice: 3029
CPU14<T0:99968,T1:54528,D:5,S:3029,C:99983>
CPU 14 IS NOW UP!
Bringing up 15
cpu: 15, clocks: 99983, slice: 3029
CPU15<T0:99968,T1:51504,D:0,S:3029,C:99983>
CPU 15 IS NOW UP!
CPUS done 4294967295
Linux NET4.0 for Linux 2.4

... and then the kernel deadlocks after free_initmem()'s printk().


Cheers,
Bill