From owner-freebsd-hackers Sun Feb 5 22:04:15 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA13458 for hackers-outgoing; Sun, 5 Feb 1995 22:04:15 -0800 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA13452 for ; Sun, 5 Feb 1995 22:04:14 -0800 Received: (from gibbs@localhost) by estienne.cs.berkeley.edu (8.6.9/8.6.9) id WAA20721; Sun, 5 Feb 1995 22:04:09 -0800 From: "Justin T. Gibbs" Message-Id: <199502060604.WAA20721@estienne.cs.berkeley.edu> Subject: Re: FIX FOR CACHE/DMA RANGE PROBLEMS To: steve2@genesis.nred.ma.us (Steve Gerakines) Date: Sun, 5 Feb 1995 22:04:09 -0800 (PST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199502060141.RAA14930@genesis.nred.ma.us> from "Steve Gerakines" at Feb 5, 95 05:41:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2272 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > Yes. The Ultrastor is a problem; I was trying to be a bit more generic. > > The start of this thread was condemning generic problems with DMA, of > > which the Ultrastor identification problem is only one (small) example. > > What exactly is the problem with the Ultrastor probe?? Please be specific. > I wrote the 24F (EISA) probe virtually line by line from the spec. The > only problem I know of which is now fixed, is that there was a faulty test > to see if a 24F card was in wd emulation mode. The problem is that it doesn't first check the EISA device id registers before doing inb/outb to the board. You should be able to 100% positive id a board via the EISA id regs. Take a look in either aha1742.c or aic7770.c to see how EISA boards should be found. > >From what I can follow in this thread you're talking about two different > things here. The driver will certainly detect a 24F and use the proper > card settings. It does not (and as far as I know no driver does) check > test to see if the EISA chipset is buggy. This is a different issue. I'm worried about the uha driver walking over an already probed boards address area when there is no reason why it should. > I'm not sure what changed in 2.x but it would be nice to have config > support for all the different bus types rather than hardcoding all the > different methods in each driver. Better yet, it would be nice to just > nuke config entirely. The different bus probe routines should be split out from the bus independant portions of the driver. I agree that it would be nice to differentiate between isa/eisa in config. The distinction is already made for PCI. To get an idea about how I think the drivers should handle multiple bus support, look at the aic7xxx driver layout: i386/scsi/aic7xxx.c /* Bus independant code */ ^^^^<== change to "bus"?? sys/pci/aic7870.c /* PCI probe */ i386/isa/aic7770.c /* EISA/VL probe - the VL model has EISA id * regs - should really be in * i386/eisa */ > > - Steve > steve2@genesis.nred.ma.us > -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================