From: Dipankar Sarma <dipankar@in.ibm.com>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Greg KH <greg@kroah.com>, Andrew Morton <akpm@osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
Fastboot mailing list <fastboot@lists.osdl.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [Fastboot] Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
Date: Sat, 4 Jun 2005 19:13:06 +0530 [thread overview]
Message-ID: <20050604134306.GB7439@in.ibm.com> (raw)
In-Reply-To: <200506041618.24736.vda@ilport.com.ua>
On Sat, Jun 04, 2005 at 04:18:24PM +0300, Denis Vlasenko wrote:
> On Friday 03 June 2005 21:36, Eric W. Biederman wrote:
> >
> > As I recall the drivers were not getting the interrupts but the interrupts
> > were happening. To stop being spammed the kernel disables the irq line,
> > at the interrupt controller. Then when the driver registered the
> > interrupt it would never receive the interrupt.
>
> Shouldn't kernel keep all interrupt lines initially disabled
> (sans platform-specific magic), and enable each like only when
> a device driver requests IRQ? This sounds simpler to do...
This doesn't help kdump folks. Interrupt pending from a device
from the first boot can flood the system when another driver
sharing the irq gets enabled in the second boot (kdump boot).
The disabling of interrupts need to be done on a per-device
basis for kdump to avoid this problem.
That said, I am not sure what is the issue with the console
drivers. What good is the irq for the console driver if
it hasn't requested for it ? Why should disabling it affect
consoles ? The interrupt will get enabled as soon as the driver
requests for it as per Vivek's patch. Am I missing something here ?
Thanks
Dipankar
next prev parent reply other threads:[~2005-06-04 13:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 11:25 [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel Vivek Goyal
2005-06-03 11:54 ` Richard B. Johnson
2005-06-03 15:24 ` Alan Stern
2005-06-03 18:26 ` Eric W. Biederman
2005-06-03 18:21 ` Greg KH
2005-06-03 18:36 ` Eric W. Biederman
2005-06-04 13:18 ` Denis Vlasenko
2005-06-04 13:43 ` Dipankar Sarma [this message]
2005-06-04 14:03 ` [Fastboot] " Dipankar Sarma
2005-06-04 21:14 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2005-06-04 10:31 Maneesh Soni
2005-06-07 3:07 Vivek Goyal
2005-06-07 5:07 ` Grant Grundler
2005-06-07 9:59 ` Eric W. Biederman
2005-06-07 16:21 ` Grant Grundler
2005-06-07 18:42 ` [Fastboot] " Eric W. Biederman
2005-06-08 4:02 ` Grant Grundler
2005-06-08 4:38 ` Eric W. Biederman
2005-06-08 6:38 ` Vivek Goyal
2005-06-08 11:23 ` 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=20050604134306.GB7439@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=vda@ilport.com.ua \
/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