All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Bharata B Rao <bharata@in.ibm.com>
Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com>,
	James Bottomley <James.Bottomley@SteelEye.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"Wade, Roy" <Roy.Wade@lsil.com>,
	fastboot@lists.osdl.org
Subject: Re: [BUG] Fusion MPT Base Driver initialization failure with kdum p
Date: Wed, 13 Jul 2005 16:26:03 +0530	[thread overview]
Message-ID: <20050713105603.GC29375@in.ibm.com> (raw)
In-Reply-To: <1121250903.10622.28.camel@localhost.localdomain>

On Wed, Jul 13, 2005 at 04:05:03PM +0530, Bharata B Rao wrote:
> On Tue, 2005-07-12 at 12:15 -0600, Moore, Eric Dean wrote:
> > I've seen the report. I need more info from Bharata on how
> > to reproduce. Perhaps you can send me email offline which
> > provides specific instructions to how to configure kdump,
> > how to capture the dump, and what you did to crash your system.
> 
> This is how I could reproduce this bug:
> (http://bugzilla.kernel.org/show_bug.cgi?id=4870)
> 
> - Configure the 1st kernel to take a kdump and run 4 instances of LTP on
> it (I used `runltp -p -l logfile -t 12h -x 4)
> - After a few hours, the 1st kernel crashes which results in the booting
> of the 2nd kernel (the kernel which captures kdump). While this is
> booting, mptbase driver fails during initialization leading to the panic
> of the 2nd kernel.

I had also faced this problem and I had simply used Alt-Sysrq-c to force
kexec on panic. As mentioned in the report below the problem goes away
if mpt driver is compiled with MPT_DEBUG_IRQ support. 

In kdump environment, device might not be in a reset state while driver is
initializing in second kernel. Hence we probably need two things from the 
driver to be able to successfully initialize over kdump.

- Reset the underlying device before enabling the interrupts.
- In interrupt handler, make sure the interrupt belongs to the driver 
  before processing it further.  (Shared interrupt lines) 

Thanks
Vivek

      reply	other threads:[~2005-07-13 10:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-12 18:15 [BUG] Fusion MPT Base Driver initialization failure with kdum p Moore, Eric Dean
2005-07-13 10:35 ` Bharata B Rao
2005-07-13 10:56   ` Vivek Goyal [this message]

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=20050713105603.GC29375@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=Eric.Moore@lsil.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=Roy.Wade@lsil.com \
    --cc=bharata@in.ibm.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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 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.