Re: [parisc-linux] irq.c patch to fix lockups on recent kernels

[Grant Grundler <grundler@dsl2.external.hp.com>]

Randolph Chung wrote:
> After talking to Grant about this, I'm not convinced this is the right
> fix. It seems like do_cpu_irq_mask is already called with eiem masked,
> so I'm not sure why masking it again might make a difference....

No. eiem == External Interrupt Enable Mask.
Only the I-bit is disabled when do_cpu_irq_mask() is entered.
Bits in the EIRR are already cleared by assembler code to indicate
we are handling those interrupts.
If any bits in EIRR are set when re-enabling I-bit (in PSW),
we should get another external interrupt.

In -pa17, I removed the mfctl/mtctl calls since I-bit is supposed
to be disabled to block *all* interrupts. But supposing some
driver calls cli() and re-enables interrupts in general, the
EIRR bits (ie interrupt "vectors" in ia64 speak) we are processing 
could run into the same problem that I saw with xtime_lock.
Thus, restoring the code I removed in -pa17 that mucks with eiem
would mask issues with sti/cli in the drivers.

Conversely, any interrupt handler sittin on the interrupt stack
for long periods of time will block stuff too...the symptoms I've
heard so far don't match this scenario though.

> Can someone more familiar with this part of the kernel please take a
> look?

The patch looks fine to me. I suspect it's masking
a problem with sti()/cli() usage someplace though.

thanks,
grant