Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!tfs.com!julian From: julian@TFS.COM (Julian Elischer) Subject: Re: Buslogic 742 Message-ID: <CGnrDt.JMp@tfs.com> Sender: usenet@tfs.com Organization: TRW Financial Systems, Oakland, CA References: <IgrahoK00iUx473292@andrew.cmu.edu> <1993Nov14.163302.26421@csus.edu> <AMURAI.93Nov16220920@tama.spec.co.jp> Date: Wed, 17 Nov 1993 22:49:05 GMT Lines: 53 In article <AMURAI.93Nov16220920@tama.spec.co.jp>, Atsushi Murai <amurai@tama.spec.co.jp> wrote: >In article <1993Nov14.163302.26421@csus.edu> rmallory@silicon.csci.csusb.edu (Rob Mallory) writes: > > Timothy J Kniveton (tim+@CMU.EDU) wrote: > : I've heard good things about Buslogic 742 EISA controller. Any > : comments? Is the 747 compatible with BSD? From what I have heard and read, the 747 is SW compatible with the 742. > I recently installed the November RELEASE kernel of FreeBSD on my > 66DX2/4(big)MB w/ toshiba scsi2 and have noticed _Major_ improvements > over the October kernel release. I assume this improvement relates > to the groovy little message at boottime: "bt0: ........ eisa dma" No, I believe the improvements may come from better Vm code and some improvements in the fs cache code.. > The author - Julian might be follow up for you. but let me write >down a memo for you. Atushi is too modest.. He did a lot of good work on the 742 driver and made it work on some versions for which it used to break. > The message "bt0:..." is just show a current board configurataion >thorough the specified I/O port. Another word, bt742 driver DOES NOT >set it up like eisa dma mode nor 33MB/sec bursting..... Don't forget >set the board by EISA-Config utility. I agree.. the driver leaves the setting as it finds them, but it does print them out so that you know what's going on.. > I'm curious myself on exactly how close to an optimum driver for the > *BSD's are in their current src-trees (33MB/sec bursting transfer mode?) well, if the board will do it the driver won't get in the way. I do allow multiple requests to be placed against a single target at a time, so inter-command latency is about 0.. i.e you probably can't make it run too much faster other than batching adjacent requests, and other such tricks. > >Atsushi. >-- >Atsushi Murai Email: amurai@spec.co.jp >System Planning and Engineering Co,.Ltd. Voice: +81-33833-5341 julian