From owner-freebsd-sparc Thu Jan 16 11:37:34 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3081037B401 for ; Thu, 16 Jan 2003 11:37:32 -0800 (PST) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EB8E43EB2 for ; Thu, 16 Jan 2003 11:37:31 -0800 (PST) (envelope-from groudier@free.fr) Received: from [192.168.1.129] (213.36.54.206) by mail.libertysurf.net (6.5.026) id 3DEB487600D3E7E6; Thu, 16 Jan 2003 20:37:29 +0100 Date: Thu, 16 Jan 2003 21:36:55 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: groudier@localhost.my.domain To: Thomas Moestl Cc: Roderick van Domburg , Subject: Re: panic: trap: fast data access mmu miss In-Reply-To: <20030114201030.GA947@crow.dom2ip.de> Message-ID: <20030116210625.B1829-100000@localhost.my.domain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 14 Jan 2003, Thomas Moestl wrote: > On Tue, 2003/01/14 at 21:30:36 +0100, G=E9rard Roudier wrote: [...] > > > I think I've already ruled out most causes; I'm suspecting that > > > malloc() might be failing due to massive use of M_NOWAIT in the > > > related code. > > > > If less than 20K of memory is massive allocation, then your mail may we= ll > > come from twenty years ago IT age and I can only be dreaming at the > > moment. :-) > > > > The driver fails during initialisation after having allocated less than > > 20K in PAGE size chunk for the controller and probably less than 2 PAGE= S > > if PAGE size is large. > > I was not refering to sym alone. The IOMMU code itself also uses > M_NOWAIT to allocate DVMA memory and resource descriptors, and it's > not unlikely that previosly intialized drivers have used it and > drained the pool. The last round of updates increased the number of > allocations the IOMMU code does, hence this suspicion (it turns out > to be rather unlikely after reading some more allocator code though :) Thanks for the clarification. I just have some general comments about: :) Most (almost all) resources allocated at drivers/modules initialisation are never freeed. As a result, these resources should be available at the moment they are requested and waiting or not for availability will not add any magic that can prevent from shortage, in my opinion. Speaking about sym, it tries to recover from resource shortage after initialisation and should succeed most of the time. I just don't want the driver to allocate everything at initialisation since this can be hudge wastage in average. And yes, the driver will also use NOWAIT option after initialisation, since waiting for resources would either need complex synchronisation or would break IO ordering requirements. Note that we could allocate the needed resources and no more in SIMs if FreeBSD/CAM provided the slave_alloc()/slave_configure()/slave_destroy() semantic as in Linux 2.5. May-be Justin should consider this to be implemented in CAM. :) And on the other hand, SIMs could wait for resources during initialisation if aggressive parallelism that may lead to resource shortage occurs on kernel boot, since there is generally no ordering requirements during initialisation step. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message