Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@puffin.external.hp.com>
To: John Marvin <jsm@udlkern.fc.hp.com>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] kernel panic
Date: Wed, 23 May 2001 12:59:57 -0600	[thread overview]
Message-ID: <200105231859.MAA00753@puffin.external.hp.com> (raw)
In-Reply-To: Your message of "Wed, 23 May 2001 02:53:15 MDT." <200105230853.CAA07709@udlkern.fc.hp.com>

John Marvin wrote:
...
> 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                 |
> 	scsi_dispatch_cmd               |
> 	<NEXT INTERRUPT>    >-----------+

Uh oh. that's a bug. From irq.c:do_irq_mask() 

...
                mask_irq(irq_num);
                do_irq(&region->action[irq], irq_num, regs);
                unmask_irq(irq_num);
...

So it shouldn't be possible to take another interrupt
while in do_irq().

...
> to Richard Hirst, and he said a later version of the sym53c8xx driver
> processes things differently (using scsi_done instead of scsi_old_done)
> so that this shouldn't happen. However, I believe it shouldn't be
> happening anyway, because we should be preventing the isr from being
> re-entered in the general irq handling code.

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. 

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

  parent reply	other threads:[~2001-05-23 19:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-23  8:53 [parisc-linux] kernel panic John Marvin
2001-05-23 16:21 ` Matthew Wilcox
2001-05-23 18:59 ` Grant Grundler [this message]
2001-05-23 19:13   ` Matthew Wilcox
2001-05-24 14:16     ` Richard Hirst
2001-05-25  4:31       ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2002-09-07 20:46 [parisc-linux] Kernel Panic marc 
2002-09-07 22:08 ` Grant Grundler
2002-09-02 16:37 marc 
2002-09-02 16:51 ` Randolph Chung
2001-05-22  8:10 [parisc-linux] kernel panic John Marvin
2001-05-23  2:18 ` Ryan Bradetich
2001-05-23 16:48   ` Stan Sieler
2001-05-22  3:57 Ryan Bradetich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200105231859.MAA00753@puffin.external.hp.com \
    --to=grundler@puffin.external.hp.com \
    --cc=jsm@udlkern.fc.hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox