Date: Sun, 5 Feb 95 14:37:50 MST From: terry@cs.weber.edu (Terry Lambert) To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Cc: wilko@yedi.iaf.nl, bugs@warlock.win.net, freebsd-hackers@FreeBSD.org Subject: Re: FIX FOR CACHE/DMA RANGE PROBLEMS (was Re: new SNAP) Message-ID: <9502052137.AA03308@cs.weber.edu> In-Reply-To: <199502052107.NAA19794@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Feb 5, 95 01:07:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > How about checking for the EISA ID ? > > > > The EISA standard doesn't provide a requirement for the amount of per slot > > CMOS memory (I found this out when trying to write a UNIX EISA config > > utility, it being my opinion that requiring DOS to configure a machine > > is an abortion). > > What does this have to do with checking the EISA Card ID regs to determine > if the ultrastore card is eisa? Or are you talking about isa cards (like > the 2842) that have EISA id regs so they can be found via an EISA probe? > I thought the problem with the ultrastore probe was that it didn't do a > standard EISA probe, but instead relied on the fact that the eisa cards > will respond in the same way as isa cards. 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. I'd like to see the EISA probe seperated from the concept of an EISA vs an ISA driver. The driver capability flags for DMA, etc. that I was talking about were supposed to be per bus attach instance -- ie: with a 24f and 34f in the same machine, only the incapable controoler should get bounced. Sorry if this wasn't clear from context. > > This may be something that requires VM86() to allow us to call the EISA > > BIOS for it to work properly. > > I would love to be able to do an EISA config from within FreeBSD. More over, > the aic7770 driver could get all of the per target info from the EISA config > area instead of relying on Adaptec's BIOS to do this for you at POST. Yes. This is the major thing that PCI has over EISA, IMO (besides PCI-PCI bridging for loosely coupled SMP), since PCI has a defined memory area, you don't have to screw around with the BIOS to get what you want out of it. One way (it is evil, I don't recommend it) to ignore the issue is to deal with EISA disk controllers in the first slot only. This would give you at most one DMA device, but at least you could unambiguously read the per target information. This screws up *badly* for multiple DMA using controllers, since that case ends up requiring both sets of code. Bletch. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502052137.AA03308>