From owner-freebsd-alpha Mon Dec 9 10:39:48 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE79537B401; Mon, 9 Dec 2002 10:39:46 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E16643ED1; Mon, 9 Dec 2002 10:39:42 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA06431; Mon, 9 Dec 2002 13:39:36 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gB9Id6u02924; Mon, 9 Dec 2002 13:39:06 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15860.58186.22476.565069@grasshopper.cs.duke.edu> Date: Mon, 9 Dec 2002 13:39:06 -0500 (EST) To: Robert Watson Cc: alpha@FreeBSD.ORG Subject: Re: cvs commit: www/en/projects/busdma index.sgml style.css (fwd) In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Robert Watson writes: > > Hey Alpha Folks, > > Was wondering what the status of busdma support on Alpha is, in particular > regarding dmamap_load_mbuf(). In order to maximize the portability of AFAIK, the busdma interface for nic drivers is totally untested on alpha, as there are no nic drivers for common hardware that I'm aware of which use busdma. Has anybody converted dc, fxp or xl yet? The busdma infrastructure works for a limited definition of "works" on alpha. By this I mean: Address limited (ISA) devices work fine (aside for a platform dependant bug on DS10). We use the pci chipset capabilities present in most alphas to do scatter/gather DMA so that any physical address can be mapped to a DMA address < 16MB. Unfortunately, PCI devices which use busdma (most PCI scsi drivers) end up using the direct map. This refers to a DMA window which typically maps host physical addresses 0..1GB at PCI address 1GB..2GB (or 2GB...4GB on 21264s) On most platforms, this restricts the usable memory to the size of the direct map, which is 1GB on older machines and 2GB on 21264 based systems. There is currently no infrastructure available for the platform to inform the MI busdma code of the size of the direct map so that it can switch over to scatter/gather once the physical address is outside the direct mapped window. Making large memory machines work *might* be as simple as switching over to using scatter/gather for addresses outside the direct map. However, I suspect we'd quickly feel pinched by having only 16MB available for DMA. What Tru64 and NetBSD do, and what we should do, is to allocate another DMA window for doing Scatter/Gather for PCI devices on large memory machines. If anybody ever does this, then we should be able to run with any size memory, provided all the drivers in the system use busdma. It would be "easy" for somebody to implement this without needing excessive amounts of hardware. Its fairly easy to shrink the direct-map window to 64MB in size so that even a 128MB machine would need scatter/gather. I can provide an interested party patches or access to docs. I'd be happy to help anybody interested in this task, but I feel reluctant to take it on myself due to time commitments at my day job. FWIW, some of this is fresh in my mind, as I was recently fooling around with expanding the direct map on miatas. This is a no-go, due to where the SRM places the memory space for the PCI devices in the system. (just past 2GB). Hope that helps, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message