[parisc-linux] kernel panic
Thu, 24 May 2001 15:16:14 +0100
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