Date: Thu, 07 Mar 1996 19:16:52 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Terry Lambert <terry@lambert.org> Cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 2842 and the disappearing file-system :-( Message-ID: <199603080316.TAA02977@freefall.freebsd.org> In-Reply-To: Your message of "Thu, 07 Mar 1996 13:36:15 MST." <199603072036.NAA14706@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Again you have decided that if you at first miss the target, to choose a totally different target for your next attempt. Lets remember what started this whole thread... The 2842VLB SCSI card, a non PnP device, sticks its identifier in the EISA slot address space for identification. FreeBSD currently always looks for these IDs in the EISA slot address space even if the EISA motherboard ID at 0x0C80 is not found so that it can detect these cards. You complained that the EISA code should not probe the slot address space if the motherboard ID was not found. And thus this argument began. Since then, you've tried to make this into an agument for a configuration manager. Well, you have no argument from me for a configuration manager. In fact I wrote eisaconf with the sole intention of making it a prototype for a configuration manager that would encompass other device types. What you will, and have seen me argue against is the need to construct additional mechanisms into how we probe devices to cover a single VLB card that was designed to be probed like an EISA device. Having more than one way to trigger a scan of the EISA slot address space for devices is confusing at best, and leads to bugs at worst. The probe for EISA devices has proven non-invasive on the 100s of machines that currently have eisa0 in their config files and the same scan would be required anyway to support the 2842, so there is no technical reason to provide an alternate method for triggering the search. Furthermore, eisaconf must already properly report other ISA cards that can be configured in "eisa compatibility mode" as living on the ISA bus (the 3c509 for example) so it is already suited to the task of handing the 2842 with absolutly no additional code or complexity: ahc1: <Adaptec 284X SCSI host adapter> at 0x7c00-0x7cff irq 12 on isa >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). But the 2842 is not a PnP device and forcing the ISA PnP mechanism to deal with non PnP hardware is a violation of layering in a configuration manager scenario. The configuration manager should moderate between the ISA PnP probe mechanism and the list of "possible probe locations" provided by ISA devices and their "bus manager". >> 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. And yet this was exactly the problem that spurred this thread. >At the very least, we should admit that looking for EISA stuff on a >non-EISA machine is a kludge. Complain to Adaptec. >> 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. Probing the 2842 as an EISA device does not preclude a configuration manager aproach to solving our current device probe mess. >> 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. Anyone who currently has eisa0 in there kernel is proving the point that the probe of the eisa slot address space is non-invasive. The probe can't tell if you have a VLB motherboard in order to prevent the probe, and it can't know if you have a 2842 either without looking, so it always does the scan. >> >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*. The match routines and forcing a scan of the eisa address space makes no sense in a generic ISA probe (deals with non PnP hardware) configuration sub-manager. >> >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. Exactly! The Adaptec card behaves like an eisa device so you either have it use the EISA probe mechanism or you have it be an ISA probe that does the scan itself since it would be a layering violation to have it call into the EISA probe to force it to scan the slot address space even if it wasn't an EISA machine, call the eisa match routine to see if a proper ID was found, and then turn around and register itself with the ISA device manager. >> >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. This is a device driver issue, not a VLB bus issue, since only the driver knows if it is talking to a VLB card. >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. Again, this is not a VLB issue. I'm all for a generic way to determine if bounce buffering is necessary, but this wasn't the issue we were discussing. >So the DMA argument doesn't support the EISA/VLB probe argument. It certainly doesn't support that there should be a separate VLB probe. > 16MB dma problems transend busses. >> >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. Complain to Adaptec. >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. For all of the EISA cards that I've added eisaconf probes for, the IRQ, DMA and most other interresting information is availible in registers initialized by the the EISA BIOS. The 2842 has the same registers availible that the 2742 so it is not an issue. Think of the 2842 as an EISA card that doesn't have an overlay file and so doesn't store anything in configuration space. We can't even read configuration space yet, but the eisaconf code will have to deal with devices that have nothing set up there anyway which is simple since it will simply leave it up to the device driver to interpret the data once the eisaconf code can provide a means to access it. >> >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). What is the gain in doing this? >> >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? No, with your assertion that having the ISA PnP support akin to how eisaconf works, solves the 2842 issue. Coercing the 2842 to fit into an ISA PnP model (it uses a dip switch block combined with a "SCSI-Select" utility) is far worse than probing it as an EISA device as the manufacturer intended. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603080316.TAA02977>