From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Lukasz Kosewski <lkosewsk@nit.ca>, Andrew Morton <akpm@osdl.org>,
Arjan van de Ven <arjan@infradead.org>,
vgoyal@in.ibm.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: SCSI aic7xxx driver: Initialization Failure over a kdump reboot
Date: Sun, 30 Jan 2005 13:27:49 -0200 [thread overview]
Message-ID: <20050130152749.GF5186@logos.cnet> (raw)
In-Reply-To: <20050107043832.GR27371@parcelfarce.linux.theplanet.co.uk>
On Fri, Jan 07, 2005 at 04:38:32AM +0000, Matthew Wilcox wrote:
> On Thu, Jan 06, 2005 at 11:53:27PM -0500, Lukasz Kosewski wrote:
> > I have an idea of something I might do for 2.6.11, but I doubt anyone
> > will actually agree with it. Say we keep a counter of how many times
> > interrupt x has been fired off since the last timer interrupt
> > (obviously, a timer interrupt resets the counter). Then we can pick an
> > arbitrary threshold for masking out this interrupt until another device
> > actually pines for it.
> >
> > Or something. The point is, we need a general solution to the problem,
> > not poking about in every single driver trying to tie it down.
>
> Something like note_interrupt() in kernel/irq/spurious.c?
BTW I wonder if its feasible to add an interface on top of kernel/irq/spurious.c for
notifying drivers about interrupts storms, so they can take appropriate action
(try to reset the device).
For example I've seen a 8390 based pcnet_cs driven (Linksys EtherFast 10/100+ + 56K Modem) PCMCIA
card go nuts and trigger infinite interrupt storms on custom PowerPC hardware under certain situations,
and resetting the device after a high limit of bogus interrupts "brought the hardware back", stabilizing
the system.
Would be nice to be able to change the current hardcoded nr-of-interrupt limits, and
have a notification mechanism.
Not sure if this kind of problem is common enough that adding a generic API
is worth it, though ?
next prev parent reply other threads:[~2005-01-30 18:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-06 12:35 SCSI aic7xxx driver: Initialization Failure over a kdump reboot Vivek Goyal
2005-01-06 12:12 ` Arjan van de Ven
2005-01-07 3:50 ` Andrew Morton
2005-01-07 4:53 ` Lukasz Kosewski
2005-01-07 4:38 ` Matthew Wilcox
2005-01-30 15:27 ` Marcelo Tosatti [this message]
2005-01-30 18:27 ` Arjan van de Ven
2005-01-30 15:57 ` Marcelo Tosatti
2005-01-07 7:36 ` Vivek Goyal
2005-01-07 14:55 ` Lukasz Kosewski
2005-01-07 14:50 ` linux-os
2005-01-07 15:44 ` Vivek Goyal
2005-01-07 16:52 ` Vivek Goyal
2005-01-07 17:36 ` Denis Vlasenko
2005-01-07 5:27 ` Vivek Goyal
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=20050130152749.GF5186@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkosewsk@nit.ca \
--cc=matthew@wil.cx \
--cc=vgoyal@in.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.