From: Grant Grundler <grundler@dsl2.external.hp.com>
To: John Marvin <jsm@udlkern.fc.hp.com>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] rp2470 hang...getting closer
Date: Tue, 22 Oct 2002 19:19:12 -0600 [thread overview]
Message-ID: <20021023011912.A23F5482F@dsl2.external.hp.com> (raw)
In-Reply-To: Message from John Marvin <jsm@udlkern.fc.hp.com> of "Mon, 21 Oct 2002 18:41:48 MDT." <200210220041.SAA17351@udlkern.fc.hp.com>
John Marvin wrote:
...
> Upon return from
> handle_interruption we turn on the I bit, but then later we disable I and
> Q before calling rfir in the return path from handle_interruption, so this
> is not an issue.
Ah ok - my bad. I should have checked.
When doing any bottom half stuff, I think it should be ok for
I-bit to be enabled.
> Note that we are currently turning the I bit on when we return from
> handle_interruption, so this, so removing the local_irq_enable() is not
> going to actually change any behaviour.
hmmm. It changes the timing a bit but basically you are right.
I'm worried about the nesting of traps/interrupts in this case.
My gut feeling says we never want to enable I-bit for handling faults/traps.
Maybe to enable console output in a kernel_die() code path.
The obvious deadlock sequence to me is:
spin_lock_irqsave() -> trap -> interrupt -> spin_lock()
or
spin_lock_irqsave() -> trap -> interrupt/bottom half -> spin_lock()
I use "interrupt" to mean "External Interrupts" as defined by parisc arch.
> I just don't think it is necessary, and the enablement upon return may
> be wrong also.
yeah. I suspect it is.
...
> Now, I've also spent some time looking at the I bit enablement at the head
> of intr_return in entry.S. I don't think that is correct either. But
> just removing it is not the correct answer.
Please let me know if (a) you are chasing this down or (b) you
already found the correct answer. I'm very tempted to just try
removing it and see what breaks. I may not be able to debug the
resulting mess though...
...
> Note, I don't think any of this is going to explain the problem specific
> to the rp2470.
When scsi_lock_irqsave() blocks interrupts, we can't take any
external interrupt. It results in a deadlock.
I'm suspecting that's also what was causing the deadlock on xtime_lock.
I added code to set EIEM to 0 in do_cpu_irq_mask() to avoid that deadlock.
I can't do the same for sym2 driver.
thanks,
grant
next prev parent reply other threads:[~2002-10-23 1:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-22 0:41 [parisc-linux] rp2470 hang...getting closer John Marvin
2002-10-23 1:19 ` Grant Grundler [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-13 4:40 Grant Grundler
2002-10-13 13:56 ` Thibaut VARENE
2002-10-21 0:57 ` Grant Grundler
2002-10-21 2:21 ` Matthew Wilcox
2002-10-21 3:33 ` Grant Grundler
2002-10-21 14:59 ` Matthew Wilcox
2002-10-21 15:26 ` Matthew Wilcox
2002-10-21 21:58 ` Grant Grundler
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=20021023011912.A23F5482F@dsl2.external.hp.com \
--to=grundler@dsl2.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