From owner-freebsd-stable@FreeBSD.ORG Sat Sep 23 22:29:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9C9916A403 for ; Sat, 23 Sep 2006 22:29:59 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FABC43D45 for ; Sat, 23 Sep 2006 22:29:58 +0000 (GMT) (envelope-from janm@transactionware.com) Received: (qmail 77604 invoked from network); 23 Sep 2006 22:30:18 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 23 Sep 2006 22:30:18 -0000 Received: (qmail 44182 invoked by uid 1026); 23 Sep 2006 22:30:18 -0000 Received: from 192.168.2.2 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(192.168.2.2):. Processed in 3.233312 secs); 23 Sep 2006 22:30:18 -0000 Received: from unknown (HELO transactzbkv04) (192.168.2.2) by new.transactionware.com with SMTP; 23 Sep 2006 22:30:14 -0000 From: "Jan Mikkelsen" To: "'Scott Long'" Date: Sun, 24 Sep 2006 08:30:06 +1000 Message-ID: <000f01c6df5f$d260e350$0202a8c0@transactzbkv04> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <451368CA.1030404@samsco.org> Importance: Normal Cc: freebsd-stable@freebsd.org Subject: RE: Patch: sym(4) "VTOBUS FAILED" panics on amd64, amd64/89550 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2006 22:30:00 -0000 Hi, Scott Long wrote: > > I can't see any mention of virtual address alignment in the=20 > bus_dma man > > page. Can it take care of virtual address alignment? If so, how? > > =20 >=20 > busdma makes no guarantees on virtual addresses. Thanks for the confirmation. I assume this is also true for = contigmalloc. =20 > Sigh, sorry I never got this fixed. The custom memory=20 > allocator made me > unhappy, and I never had time to dig into it. Do real docs=20 > on sym exist > somewhere? I'm not against sitting down and re-writing the physical > memory handling to both work and conform to the FreeBSD APIs. Yes. This problem is caused by the custom allocator rather than any "special" requirement for memory allocation. It looks (to me) like the custom allocator could just be ripped out and replaced with calls to contigmalloc/bus_dma/malloc(9). Ultimately the internal allocator will = grow a pool by calling contigmalloc or bus_dma (depending on the pool), so calling those functions from the contexts in which the internal = allocator is called should be OK (or an existing bug).=20 Calling malloc(9) might even be more appropriate than contigmalloc(9) = where the allocated memory does not get used for DMA. The driver currently = uses bus_dma for memory that requires DMA, contigmalloc otherwise. The work seems to be in maintaining a virtual to physical mapping for = the objects the driver cares about (ie: all the vtobus() calls). It looks = like it might be possible to use a pmap_* call to do this, but that seems to require a pmap_t. Is there bus_dma approach other than remembering? Is there a pointer to a document on the preferred memory management = model for FreeBSD drivers? I might have a look at this on Monday. Regards, Jan.