Re: iommu_alloc failure and panic

From: Doug Maxey <dwm@maxeymade.com>
To: Olof Johansson <olof@lixom.net>
Cc: Mark Haverkamp <markh@osdl.org>,
	"linuxppc64-dev@ozlabs.org" <linuxppc64-dev@ozlabs.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	james.smart@emulex.com
Subject: Re: iommu_alloc failure and panic
Date: Mon, 30 Jan 2006 19:18:47 -0600	[thread overview]
Message-ID: <200601310118.k0V1Il7Z018408@falcon30.maxeymade.com> (raw)
In-Reply-To: <20060130231348.GC9368@pb15.lixom.net>

On Tue, 31 Jan 2006 10:13:48 +1100, Olof Johansson wrote:
>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.
>

ASM > System Configuration > I/O Adapter Enlarged Capacity.

This only applies to the last slot on a PHB.  AKA superslot.

>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
>_______________________________________________
>Linuxppc64-dev mailing list
>Linuxppc64-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc64-dev
>