Re: iommu_alloc failure and panic

[Olof Johansson <olof@lixom.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/