Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2003 21:36:55 +0100 (CET)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>
To:        Thomas Moestl <tmoestl@gmx.net>
Cc:        Roderick van Domburg <r.s.a.vandomburg@student.utwente.nl>, <freebsd-sparc64@FreeBSD.ORG>
Subject:   Re: panic: trap: fast data access mmu miss
Message-ID:  <20030116210625.B1829-100000@localhost.my.domain>
In-Reply-To: <20030114201030.GA947@crow.dom2ip.de>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030116210625.B1829-100000>