From owner-cvs-all@FreeBSD.ORG  Sun Aug 22 18:57:41 2004
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3221516A4CE; Sun, 22 Aug 2004 18:57:41 +0000 (GMT)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 2987143D39; Sun, 22 Aug 2004 18:57:41 +0000 (GMT)
	(envelope-from green@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.11/8.12.11) with ESMTP id i7MIvf7L039930;
	Sun, 22 Aug 2004 18:57:41 GMT
	(envelope-from green@repoman.freebsd.org)
Received: (from green@localhost)
	by repoman.freebsd.org (8.12.11/8.12.11/Submit) id i7MIvf8a039929;
	Sun, 22 Aug 2004 18:57:41 GMT
	(envelope-from green)
Message-Id: <200408221857.i7MIvf8a039929@repoman.freebsd.org>
From: Brian Feldman <green@FreeBSD.org>
Date: Sun, 22 Aug 2004 18:57:41 +0000 (UTC)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org,
	cvs-all@FreeBSD.org
X-FreeBSD-CVS-Branch: HEAD
Subject: cvs commit: src/sys/dev/sound/pci maestro.c
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Aug 2004 18:57:41 -0000

green       2004-08-22 18:57:41 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/sound/pci    maestro.c 
  Log:
  The new contigmalloc code is exposing a lot of misuses of busdma memory
  allocation. Notably, in this case, the driver tries to allocate several
  pieces of memory and then fails if the pieces allocated after the first
  do not come after it physically, and within a specific range (8MB I
  believe).  Of course, this could just as easily fail for any number of
  reasons, but it almost always fails now that contiguous allocations start
  at the end of possible specified memory locations rather than the beginning.
  
  Allocate all the possibly-needed memory up front, even though it's a waste,
  to get around this.  The least bogus solution would be to take the physical
  address from the first allocation and create a new tag that specified that
  further allocations must follow it within that 8MB window, then use that
  when allocating new channels, but that's left for anyone else that really
  feels like doing it.
  
  Tested by:      Erwin Lansing <erwin@lansing.dk>
  
  Revision  Changes    Path
  1.24      +15 -21    src/sys/dev/sound/pci/maestro.c