Re: [parisc-linux] kernel panic

[Richard Hirst <rhirst@linuxcare.com>]

On Wed, May 23, 2001 at 08:13:17PM +0100, Matthew Wilcox wrote:
> On Wed, May 23, 2001 at 12:59:57PM -0600, Grant Grundler wrote:
> > Exactly. But if the driver is mucking with IRQ enable/disable,
> > does that mean the enable/disable code has to keep reference counts?
> > Don't recall any archs doing that when we did the initial implementation. 
> 
> cli -> disables irqs on all processors
> __cli -> disables irqs on local processor
> sti -> enables irqs on all processors
> __sti -> enable irqs on local processor
> 
> spin_lock_irqsave -> disables interrupts locally, puts the previous
> state into the state variable you supplied and acquires the spinlock
> spin_lock_irqrestore -> releases the spinlock and restores previous
> state from state variable
> 
> no need to keep enable/disable counts, the previous state gets stored
> for you.  if you're using cli and sti inappropriately, you lose.

You mean like scsi_request_fn() calling  spin_unlock_irq(&io_request_lock);
when called at interrupt level?

> OK, the problem is that you are getting into a interrupt loop.
> I see the following repeated sequence on the stack:
>
>       intr_extint         <-----------+
>       do_irq_mask                     |
>       do_irq                          |
>       dino_isr                        |
>       sym53c8xx_intr                  |
>       scsi_old_done                   |
>       rw_intr                         |
>       scsi_io_completion              |
>       __scsi_end_request              |
>       scsi_queue_next_request         |
>       scsi_request_fn                 | <<<< re-enables interrupts
>       scsi_dispatch_cmd               |
>       <NEXT INTERRUPT>    >-----------+

I also found

        spin_lock(&lock) can also be used in your interrupt handler if your
        device only uses one interrupt: the kernel guarantees that a interrupt
        handler is never reentered, even if the interrupt handler runs with
        enabled interrupts.

in <http://kt.zork.net/kernel-traffic/kt20000703_74.txt>

Richard