Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030252AbWAaBTK (ORCPT ); Mon, 30 Jan 2006 20:19:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030249AbWAaBTJ (ORCPT ); Mon, 30 Jan 2006 20:19:09 -0500 Received: from falcon30.maxeymade.com ([24.173.215.190]:12776 "EHLO falcon30.maxeymade.com") by vger.kernel.org with ESMTP id S1030255AbWAaBTI (ORCPT ); Mon, 30 Jan 2006 20:19:08 -0500 Message-Id: <200601310118.k0V1Il7Z018408@falcon30.maxeymade.com> X-Mailer: exmh maxeymade.com version 2.7.2.1 01/17/2005 with nmh-1.1 In-reply-to: <20060130231348.GC9368@pb15.lixom.net> To: Olof Johansson cc: Mark Haverkamp , "linuxppc64-dev@ozlabs.org" , linux-kernel , james.smart@emulex.com Subject: Re: iommu_alloc failure and panic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jan 2006 19:18:47 -0600 From: Doug Maxey Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2309 Lines: 67 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 > - 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/