Date: Fri, 8 Mar 1996 11:13:55 -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: <199603081813.LAA17284@phaeton.artisoft.com> In-Reply-To: <199603080316.TAA02977@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 07:16:52 pm
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... I have to say that my subtext on this whole thing has always been the need for an orthoganal configuration management API. I would not have said anything, if I hadn't thought that it was going to hell. I wish I had known about the 2842 VLB being probed by the EISA probe code earlier, but we can't all know everything. This discussion was not intended to blow up out of proportion as it has done. > 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. I still maintain this position. > 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. Let's stop here for a second. I don't think the major work of the probe for the VLB card is the scan of the EISA slot address space. It's getting the configuration information about the card, and that doesn't take EISA configuration data to do it. So I don't think the 2842 should be being found by triggering a scan of the EISA slot address space. To put this another way, I shouldn't have to have an eisa0 in my config file to use a VLB card. It's confusing -- as confusing as having the ability to option out the non-optional npx0 device. I think if we back up and agree that the probe [of configuration parameters associated with the card] should be seperate from the EISA slot scan, then we will have made progress. I don't *want* "an alternate method to trigger the search", I want to not do the slot search on non-EISA machines. Yes, this means that there is a need for some additional stub code to actually find the card, but it doesn't change how the configuration information is extracted from the card. > 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 All things plugged into EISA slots are supposed to be configured, period. So it's a non-sequitur to talk about "can be configured" here. Everything that goes into an EISA slot is capable of having an EISA configuration file (I have a utility to generate these for ISA cards that came with my EISA machine; you must enter the IRQ, DRQ, I/O, and memory address ranges as part of the generation process). And if it is in an EISA slot, it *should* have an EISA config. > >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". The dup of the EISA process into the PnP space is an implementation detail on the implementation of ISA PnP. As part of the configuration management, you have to probe the non-relocatable devices for which you have drivers to determine the existance of "immobile" cards; then for all mobile cards, you relocate them. I think the 2842 is in the same category as the WD8013: it's a card that is software relocatable, but which is not PnP and thus should probably not be relocated. It's one of the base line devices that have a single graph vector for location. For a real EISA device, it's acceptable to relocate the thing, since EISA devices are configured per slot and each OS (or BIOS POST for DOS for the INT 13 hook). That means any OS that knows about dealing with EISA the correct way will find the relocated card. This isn't true of VLB cards, especially VLB cards for boot devices. I think that the 2842 needs to be probed later than the typical EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable devices. It think it needs to have an invariant configuration graph vector, *unlike* things which are found by the EISA probe. I think it is incorrect to probe the thing as an EISA device (are there any motherboards that have EISA and VLB at the same time? That would be a good counter-argument...). > >At the very least, we should admit that looking for EISA stuff on a > >non-EISA machine is a kludge. > > Complain to Adaptec. They didn't write the probe code. I have no problem with them assigning slot space for a VLB card (it's an artifact of the bus interface ASIC that they used anyway). What I do have a problem with is the implied probe order not treating it as a non-relocatable ISA device because it had been found in EISA space when we finally get to the point where we can do a graph reduction topology sort to relocate the relocatable cards. EISA cards are relocatable. Relocating ISA or VLB cards that aren't succeptable to ISA PnP drivers means that the cards could disappear from DOS or another OS with a hard-coded config.sys line for ATAPI for a CDROM on that controller, or whatever. > >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. Wrong. It identifies it as an EISA device, and EISA devices are fair game to be relocated by a PnP configuration manager. Look at the Windows95 PnP problems that FreeBSD has had with ethernet cards. Look at the IRQ 12 collisions that occur for PS/2 mice, still, on Windows95 hardware with PnP enabled. > 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. It can tell that you don't have an EISA motherboard, which is the same thing, by negative induction. The issue is not the invasiveness of the EISA probe; its with the classification of the card as an EISA card. And with the requirement that I have the EISA code configured into a kernel for a non-EISA system. > >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. I agree. Don't use the slot scan to locate the card; it isn't a substitute for the majority of the work done by the probe code anyway. Move the scan identification into an EISA-specific stub, and create an ISA specific stub for the non-relocatable VLB card. > >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. I think you are stuck on using the fact that it exports EISA slot data to trigger the probe (the manority of which is not dependent on the fact that it's "EISA"). I think this is wrong, for the ordering reasons stated above. > >> 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. The VLB bus is not bridged. The agregate bus-on time for N VLB cards going in sequence is the issue for deciding to "tune" the VLB cards down. > >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. So call it a variant ISA probe. So call it writing a probe. Or abstract the "relocatable" attribute of the 2842 by virtue of detecting it's not really EISA (using the same code that would be required for an ISA probe stub), and increase the complexity of the EISA code by making it do a variant insertion in the configuration topology graph to tag it as non-relocatable (note: this last approach strikes me as singularly bogus, and is why I am against using the EISA code to detect the non-EISA card). > >No. I think it is incorrect to use the EISA slot space mechanism to > >probe the controller. > > Complain to Adaptec. Again... I think you are stuck on using the fact that it exports EISA slot data to trigger the probe (the manority of which is not dependent on the fact that it's "EISA"). I think this is wrong, for the ordering reasons stated above. > >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. Precisely! Once you can manipulate the configuration space, EISA cards are as relocatable as ISA PnP cards! But this VLB ccard, which you lie and say is an EISA card by virtue of whose probe comes true, can *not* be relocated! You have to indirect all EISA configuration space code through the driver, and then call common routines for *all other drivers*, and for this one fake an immobile configuration space! Bletch! Talk about unnecessary complexity! > >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? EISA cards become relocatable within the conflict space. > 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. The manufacturer intended to avoid having to design VLB ASIC's when it already had EISA ASIC's. The manufacturer did not intend for the BIOS on the machine to use EISA configuration methods to handle VLB cards when the machine had no EISA slots and therefore doesn't have EISA-specific BIOS anyway. The "EISA-ness" of the 2842 is an artifact of sloppy design, not of engineering intent. Do you not agree that EISA cards should be relocatable by a resonable configuration manager that knows EISA? Or that the 2842, a VLB card, should *not* be relocatable because there is no standard mechanism for handling an EISA relocation of a non-EISA card? Or that the 2842 would have to have a fake configuration space, which would greatly complicate the configuration space manipulation for *real* EISA cards? Look, it's *fine* with me that you call my suggestion "writing an ISA probe" (even if I think it's possible to reuse most of the code), so long as the ability to relocate EISA cards is not adversly affected by the fact that the 2842 lies about being an EISA card. 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?199603081813.LAA17284>