Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 2010 08:39:12 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-arch@freebsd.org, gary.jennejohn@freenet.de
Cc:        Alexander Motin <mav@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, Scott Long <scottl@samsco.org>
Subject:   Re: Increasing MAXPHYS
Message-ID:  <201003220839.12907.jhb@freebsd.org>
In-Reply-To: <20100322124018.7430f45e@ernst.jennejohn.org>
References:  <4BA4E7A9.3070502@FreeBSD.org> <4BA6517C.3050509@FreeBSD.org> <20100322124018.7430f45e@ernst.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote:
> On Sun, 21 Mar 2010 19:03:56 +0200
> Alexander Motin <mav@FreeBSD.org> wrote:
> 
> > Scott Long wrote:
> > > Are there non-CAM drivers that look at MAXPHYS, or that silently assume 
that
> > > MAXPHYS will never be more than 128k?
> > 
> > That is a question.
> > 
> 
> I only did a quick&dirty grep looking for MAXPHYS in /sys.
> 
> Some drivers redefine MAXPHYS to be 512KiB.  Some use their own local
> MAXPHYS which is usually 128KiB.
> 
> Some look at MAXPHYS to figure out other things; the details escape me.
> 
> There's one driver which actually uses 100*MAXPHYS for something, but I
> didn't check the details.
> 
> Lots of them were non-CAM drivers AFAICT.

The problem is the drivers that _don't_ reference MAXPHYS.  The driver author 
at the time "knew" that MAXPHYS was 128k, so he did the MAXPHYS-dependent 
calculation and just put the result in the driver (e.g. only supporting up to 
32 segments (32 4k pages == 128k) in a bus dma tag as a magic number to 
bus_dma_tag_create() w/o documenting that the '32' was derived from 128k or 
what the actual hardware limit on nsegments is).  These cannot be found by a 
simple grep, they require manually inspecting each driver.

-- 
John Baldwin



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