Date: Thu, 7 Mar 1996 13:36:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( Message-ID: <199603072036.NAA14706@phaeton.artisoft.com> In-Reply-To: <199603071805.KAA26152@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 10:05:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I would guess you didn't even look. Have you looked at eisaconf.c? > >> or aic7770.c? > > > >You have guessed wrong (don't worry, this is the usual guess, and it's > >usually wrong). > > Perhaps you read it last night, but you certainly acted as if you > thought eisaconf worked just like isa_configure() in all of your mail > yesturday. I don't thin so, Quickstraw. > >The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub > >routine. I *STILL* do not think EISA ID's should be looked for if > >the system doesn't claim to be an EISA bus. > > An eisa and isa stub routine to what? The routine that collects > the IDs? The routine that matches drivers to ids? The routinesx > for irq/ioport, etc registration? It sounds like you want me to > duplicate the probe in aic7770.c, but prepend everything with isa_ > instead of eisa_. All for one card that acts just like an eisa > card? What a waste of code and effort. No; I want a dup of the EISA process in the ISA PnP space so that it's just a case of making a reference to the routines (and *remove* the "eisa_" designations entirely). > Most isa cards don't care about the eisa ids, so why create yet > another interface to them for the few isa cards that do. No matter > your aversion to looking for eisa ids in a non eisa machine, it > will have to happen regardless if you have a 2842 in your machine. > If you don't like it, or don't need it, disable eisa0. That's just the 2842, and it's an ISA driver configuration architecture problem with the ISA code. At the very least, we should admit that looking for EISA stuff on a non-EISA machine is a kludge. [ ... ] > I know of one person who has a conceptual problem with this approach(you). Well, it doesn't seem that many people are thinking in terms of a unified configuration manager ala Windows95 and WindowsNT. I expect the number of people doing so to increase over time as people desire better autoconfiguration out of FreeBSD. > Show me one person experiencing actual failures after appling the > patch I posted yesturday. The number of people running VLB is ver small... you have given me a very restricted search space with your demand. > >You are (intentionally?) missing the point. > > You claim it doesn't add more code by saying I can call the same functions. > I'm saying I can't. How am I missing the point. The point is you *should* be *able* to call the same functions for ISA, and for PnP, which uses non-invasive probing (unless you have an old IBM manufactured parallel port card), you *can*. > >1) The ISA code, unless it's PnP, can't distinguish slots, so it > > would have a damn hard time requiring looping through them. > > You know as well as I do that the eisa slot locations are fixed > at 0xz000 for z 0-16. How do you think the eisaconf code finds the eisa ids? > I don't see how this is relevent (again). This is a *card* problem, not a generic problem resolved for anthing other than the Adaptec card by calling the EISA code. > >2) This is a VLB card, not an ISA card. I would not suggest > > calling the probe from ISA any more than I would suggest > > calling it from EISA. It is *NOT* an EISA device. > > What features does VLB have that make it of any use to differentiate > between VLB and ISA probes? A) Default settings for driver configurable bus-on times, since VLB steals DRAM refresh cycles. VLB on time needs to be agregated and adjusted *down* where necessary. B) Use of bounce buffers on bus mastering VLB cards other than the *one* detected by the EISA probe by virtue of it's "EISA" nature. As you pointed out previously, *yes*, there are broken EISA and VLB DMA for > 16M. If you have a bus master controller already detected, it is possible to determine if DMA needs to be bounced. My approach would be to bounce *all* I/O until it is determined it is safe to not bounce. This is easier than it appears, since you could use an unused field in the disklabel, the root FS header, or some other location that defaults to "0" that says "check for ability to bounce" and gets written to "1" (always bounce, DMA is limited to 16M) or a "2" (don't bounce, DMA is OK above 16M) -- and only triggers if there is more than 16M detected in the machine. This would make the NiCE HiNT chipset EISA's (the only EISA machines where this is a problem) and the VLB machines you noted in a pervious posting *work* instead of *failing* by default. So the DMA argument doesn't support the EISA/VLB probe argument. > >3) The ISA code needs to "create device nodes" in a similar > > fashion to EISA for PnP. This is a case of confusing ISA > > devices that can be mapped by a configuration manager with > > those that can't. Read the Microsoft PnP document. > > It does need to create nodes, but does that mean that the ISA code > bperforms a PNP probe and then scans the eisa slot space just to satisfy the > 2842? No. I think it is incorrect to use the EISA slot space mechanism to probe the controller. The probe includes IRQ, DMA, and other info, that unless it's a real EISA card, isn't going to be in the EISA configuration space for VLB... even if such a space exists, the user didn't run the DOS EISA configuration utility for the card to set it. It is at least 75% of the way to an EISA-independent probe. > >What I suggest is calling the probe in multiple locations with two > >stub routines: one EISA for eisaconf and one VLB (ISA, barring a > >fixed handling of VLB). If you want to call this "adding an ISA probe", > >fine. It's nowhere near the same order of effort as doing that, IMO. > > What probe routine? Eisa_match? As I said before, you will have to break it out and provide EISA specific stubs. For ISA, you have to search the allowable space (and that is a data issue, as long as the probe is non-invasive). > >I can't fault you on the complexity argument: it will add a bit of > >logical complexity in the process of providing a logical abstraction. > >On the other hand, the abstraction can be made orthoganal so that it > >is easier to document and program to for other devices that can then > >seperate PnP mapping from driver attachment (substituting ISA PnP for > >probing in the same way eisaconf substitutes slot iteration for > >probing), so it seems like an acceptable tradeoff to me. > > > > I disagree. With me agreeing with you on the complexity argument? -- I was agreeing with you, reluctantly.. Or with my statement about orthogonality in a configuration management interface? -- If Microsoft can do it in Windows95, anyone can do it. Microsoft programmers are *not* gods. Regards, Terry Lambert terry@lambert.org --- 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?199603072036.NAA14706>