From: Olof Johansson <olof@lixom.net>
To: Mark Haverkamp <markh@osdl.org>
Cc: Olof Johansson <olof@lixom.net>,
"linuxppc64-dev@ozlabs.org" <linuxppc64-dev@ozlabs.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
moilanen@austin.ibm.com, james.smart@emulex.com
Subject: Re: iommu_alloc failure and panic
Date: Tue, 31 Jan 2006 10:13:48 +1100 [thread overview]
Message-ID: <20060130231348.GC9368@pb15.lixom.net> (raw)
In-Reply-To: <1138635178.5150.1.camel@markh3.pdx.osdl.net>
On Mon, Jan 30, 2006 at 07:32:58AM -0800, Mark Haverkamp wrote:
> On Sat, 2006-01-28 at 12:34 +1300, Olof Johansson wrote:
> > On Fri, Jan 27, 2006 at 02:39:50PM -0800, Mark Haverkamp wrote:
> >
> > > I would have thought that the npages would be 1 now.
> >
> > No, npages is the size of the allocation coming from the driver, that
> > won't chance. The table blocksize just says how wide the cacheline size
> > is, i.e. how far it should advance between allocations.
> >
> > This is a patch that should probably have been added a while ago, to
> > give a bit more info. Can you apply it and give it a go?
> >
> >
> > Thanks,
> >
> > Olof
> >
>
>
> Here are the last few lines of the log before it crashed.
>
>
> Jan 30 07:29:14 linux kernel: table size 10000 used f752
Ok, that's a 256MB table, which is standard, and it seems to have been
filled with mappings. in some cases there's a few entries left but it's
likely that fragmentation causes the 10-entry alloc to fail, quite
normal.
There's two things to look at, unfortunately I fall short on both of
them myself:
1) There's a way to get more than the default 256MB DMA window for a PCI
slot. I'm not aware of the exact details, but you need recent firmware
and you configure it in the ASM menues (the web interface for the
service processor). Cc:ing Jake Moilanen in case he has any more up to
date info.
2) The emulex driver has been prone to problems in the past where it's
been very aggressive at starting DMA operations, and I think it can
be avoided with tuning. What I don't know is if it's because of this,
or simply because of the large number of targets you have. Cc:ing James
Smart.
-Olof
next prev parent reply other threads:[~2006-01-30 23:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-27 16:57 Mark Haverkamp
2006-01-27 20:40 ` Olof Johansson
2006-01-27 22:39 ` Mark Haverkamp
2006-01-27 23:34 ` Olof Johansson
2006-01-27 23:37 ` Mark Haverkamp
2006-01-30 15:32 ` Mark Haverkamp
2006-01-30 23:13 ` Olof Johansson [this message]
2006-01-31 1:18 ` Doug Maxey
2006-01-31 13:41 ` James Smart
2006-01-31 21:33 ` Mark Haverkamp
2006-01-27 23:48 ` Anton Blanchard
2006-01-28 0:00 ` Mark Haverkamp
2006-01-28 1:19 ` Anton Blanchard
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=20060130231348.GC9368@pb15.lixom.net \
--to=olof@lixom.net \
--cc=james.smart@emulex.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=markh@osdl.org \
--cc=moilanen@austin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome