Date: Tue, 2 Aug 2005 19:41:44 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: freebsd-alpha@freebsd.org, Wilko Bulte <wb@freebie.xs4all.nl>, =?iso-8859-1?B?Sm9z6SBNLiBGYW5kafFv?= <bsdalpha@fadesa.es> Subject: Re: KZPCC-CE SCSI controller Message-ID: <20050802174144.GA71814@cicely12.cicely.de> In-Reply-To: <20050802172322.GC71672@dragon.NUXI.org> References: <42EE1A34.6510B1CE@fadesa.es> <20050801151501.GA53593@freebie.xs4all.nl> <20050802172322.GC71672@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 02, 2005 at 10:23:22AM -0700, David O'Brien wrote: > On Mon, Aug 01, 2005 at 05:15:01PM +0200, Wilko Bulte wrote: > > Yes, asr(4) is not in the default Alpha kernels. > .. > > Would be interesting to know if it works or not, then we can go and > > add it into the default GENERIC for FreeBSD/alpha install cds. > > It will not work as-is. I suspect it could be made to work using the > ugly hack we have elsewhere in src/sys: > > #ifdef __alpha__ > #undef vtophys > #define vtophys(va) alpha_XXX_dmamap((vm_offset_t)va) So this driver is not busdma'ed yet? Igh - this will invalidate it for lots of machines, not just alpha. Since I'm working on > 2G support and AFAIK the asked machine can have more than that this may be a problem. I intent to panic if a driver calls vtophys on a large mem alpha. Otherwise I see no option to protect systems from failing in spectacular ways. I don't think we can expect users to not accidently activate such drivers - especially as those problems may be hidden for a while. We could get such drivers working by using a large direct map, but since most of the problematic cards can only do 32bit addressing this wouldn't help that much. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050802174144.GA71814>