From: Bryce Harrington <bryce@osdl.org>
To: "Moore, Eric" <Eric.Moore@lsil.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [OOPS] -git8,9: NULL pointer dereference in mptspi_dv_renegotiate_work
Date: Sat, 30 Sep 2006 14:55:44 -0700 [thread overview]
Message-ID: <20060930215544.GB7957@osdl.org> (raw)
In-Reply-To: <664A4EBB07F29743873A87CF62C26D702A994F@NAMAIL4.ad.lsil.com>
On Fri, Sep 29, 2006 at 10:22:50PM -0600, Moore, Eric wrote:
> On Fri 9/29/2006 6:27 PM, Bryce Harrington wrote:
>
> > Does this look better?
> >
> > http://crucible.osdl.org/runs/2265/sysinfo/amd01.3.console
>
>
> It appears that the problem is we're not receiving interrupts.
> The first command after interrupts enabled is not getting a response
> back from firmware, thus timing out. I noticed in the log its
> saying interrupt is at 185, but apparently the INT line is not getting
> raised.
>
> In addition, I understand why the panic. You've compiled the drivers
> into the kernel, instead of module. i.e. if you compiled as module,
> mptspi wouldn't been called while mptbase is loaded, as in your case.
> I guess we would need to add sanity check for that case. I'm usually
> testing as modules.
Ah, that could explain it; when doing testing we do compile everything
in. So it sounds like we could eliminate the panic by compiling as a
module, however is it intended that the driver should work when compiled
in as well? If so, I'd be happy to do additional testing to verify any
fixes worth trying out.
> Besides, we need to undertand why your interrupt controller is not
> generating interrupts.
We typically boot every -mm, -git, -rc and mainline kernel on this
machine, but it's only been relatively recently that this particular
behavior has occurred. Could this suggest that there was a regression
due to recent changes?
Thanks,
Bryce
next prev parent reply other threads:[~2006-09-30 21:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-30 0:10 [OOPS] -git8,9: NULL pointer dereference in mptspi_dv_renegotiate_work Moore, Eric
2006-09-30 0:10 ` Moore, Eric
2006-09-30 0:27 ` Bryce Harrington
[not found] ` <664A4EBB07F29743873A87CF62C26D702A994F@NAMAIL4.ad.lsil.com>
2006-09-30 21:55 ` Bryce Harrington [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-09-29 18:29 Moore, Eric
2006-09-29 18:29 ` Moore, Eric
2006-09-29 21:41 ` Bryce Harrington
2006-09-28 20:25 Bryce Harrington
2006-09-28 21:51 ` Andrew Morton
2006-09-28 22:54 ` Bryce Harrington
2006-09-29 0:26 ` Andrew Morton
2006-09-29 17:17 ` Bryce Harrington
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=20060930215544.GB7957@osdl.org \
--to=bryce@osdl.org \
--cc=Eric.Moore@lsil.com \
--cc=akpm@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.