Date: Fri, 08 Mar 1996 21:46:44 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Terry Lambert <terry@lambert.org> Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: The continueing 2842/eisaconf argument Message-ID: <199603090546.VAA22456@freefall.freebsd.org> In-Reply-To: Your message of "Fri, 08 Mar 1996 11:13:55 MST." <199603081813.LAA17284@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. I maintain that the way that the 2842 is currently probed in no way gepordizes the ability to create a configuration management API. Much of what you say below is simply not true... >> 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. EISA configuration data (assuming you mean the stuff accessible through BIOS calls) is not used by any driver in FreeBSD. Even if it was accessible to FreeBSD (and there's no reason it can't be with VM86() or having the boot blocks save off the data) it would have to be interpreted by each individual driver in order to be of any use. So, although eisaconf may some day provide a mechanism for accessing this data, it certainly won't attempt processing it on its own. Every eisa card we support provides some other way for either read/write or write only access to the data the driver needs. >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. It has to be up to each driver to request and then interpret this information if it makes sense for them to do so. Many cards could care less about what's up in configuration space. The 3c579 is one, the 2842 is another. If we have to support EISA devices that don't want configuration data we can also support VLB devices that doesn't use configuration space information with no additional complexity. Its really a question of capability and use. Just because the Win32 API provides 5 volumes of "capabilities" doesn't mean I use them all. >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. The 2742 and the 2842 will continue to get most of the information about the card in the exact same way regardless of the availibility of configuration space data. You're also not talking about stub code, but an additional probe that iterates through the slot address space since the 2842 can't reference the eisa code in your model since you don't want to have to have eisa0 in your config file. This is just like going back to the days when we didn't have an eisaconf and every eisa (or eisa like) driver duplicated this exact scan of the address space. Bug fixes to one probe didn't propogate to the others. I don't see forcing people to include eisa0 in their config files as a problem since config will eventually die a horrible death, and the aic7xxx lkm will export its lkm dependancy graph so that if you don't have the eisaconf lkm in your system for some strange reason, it gives you a nice warning message. If you can talk about eisa configuration space, I think its fair for me to say that config, in its present state, will go away. >> 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. Having an EISA config file doesn't mean that your ISA device responds to accesses at 0xzc80 and provides an EISA ID. THe 3c509 does when its installed in an EISA system and properly configured. The 1542 does not. Having the config file is simply a way of aiding the ECU in telling you where conflicts are or restricing your configuration settings. Once the ECU session is over, there's nothing their to tell FreeBSD about these ISA devices. >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. You can switch the dip switches on your 2842 all day, and FreeBSD will still find it. You can also move your 2742 from slot to slot all day and FreeBSD will still find it. Relocating the card doesn't prevent you from booting from it in either case so long as the card's bios is enabled. Booting is a BIOS issue. I can make a 2742 not bootable by disabling its BIOS too. >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. The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq register after the first time its written to (by the EISA configuration just after POST). Most EISA cards can't relocate their I/O range, but the Buslogic cards can relocate relocate their registers through a range of ISA compatibily areas. The point is that the way you deal with registering relocatability has to be generic so you can deal with devices that vary in their degrees of flexibility regardless of their bus type. >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...). Many, many EISA 486 systems have VL and EISA slots. I own one of these systems. >> >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. Not all EISA devices are relocatable in the same ways. I can find plenty of EISA devices that have the same relocation deficiencies as the 2842. This is not a valid argument. >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. Not all EISA cards are relocatable after their first initialization. We have to deal with these anyway. >> 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. No, it identifies it as an ISA device. And, some non PnP ISA cards just like some EISA cards (EISA is not PnP BTW), allow you to dynamically change the IRQ. So, what's your point? If we had a configuration manager we woudn't allow flexible devices to conflict with non-flexible ones which has absolutly nothing to do with the 2842 being probed through eisaconf. The 2842, just like all the other devices using eisaconf will have to register just what it is that they can have changed and what they cannot (and the range they can be configured to. Not all cards support all IRQs for example). >> 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. Assuming EISA and VLB are mutiually exclusive which they are not. >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 3c509 in eisa configuration mode must be probed through eisaconf to be found. It is reported as an ISA device. The 2842 is also found through eisaconf and is reported as an ISA device. Both show up as ISA device in lsdev too since their kdc parents are kdc_isa. Where does the 2842 get classified as an EISA device? >> >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. And I either make it always be in your kernel, or make it part of "eisa0", or I duplicate it. What a waste. >> >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. The ordering reasons don't hold water. Nothing is gained by postponing the probe of the 2842. Its just as "relocatable" as other EISA devices and its probe is non-invasive (and already performed by the eisaconf code). >> >> 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. This as well as most tuning parameters should be left up to the user. I don't see FreeBSD trying to modify your DRAM refresh rates. Its counter intuitive for the user to go in and set the bus on time for their adapter using the vendor supplied tools for this purpose (EISA config utility for the 2742, SCSI-Select for the 2842) and not have the OS honor them. >> >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). Your making up problems Terry. Probe order is determined by bus type. Resource allocation is determined by the relative flexibility of devices regardless of bus type. >> 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! Bullshit! ISA PnP cards can relocate their I/O area most EISA cards can't. Some EISA cards do not allow relocation of anything after the EISA BIOS is done. Furthermore, the data up in configuration space doesn't control the settings of the card. You have to write to the cards own registers to do that which FreeBSD already has the capability to do without having access to configuration space. >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! This just isn't true. All devices can call the same functions to register their resources, but it will only be at attach time that they will know if they have to change their settings and to what. >> What is the gain in doing this? > >EISA cards become relocatable within the conflict space. The 2842 doesn't prevent this. >Do you not agree that EISA cards should be relocatable by a resonable >configuration manager that knows EISA? Sure. Eisaconf is already poised to do this and the 2842 will fit right in there. >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? Hey, you can change the 2842's IRQ so it will tell that to the configuration manager. The 2742 cannot change its IRQ, and it will tell the configuration manager that. If you can handle one case, you can handle the other. >Or that the 2842 would have to have a fake configuration space, which >would greatly complicate the configuration space manipulation for >*real* EISA cards? eisaconf will never manipulate configuration space directly, ever. Its not needed to support dynamic configuration of EISA devices. The 2742 just like the 2842 will not be making any calls into eisaconf to retrieve information from configuration space, so it doesn't matter if there is or is not any configuration space data for the 2742 or the 2842. Other drivers may have different requirements. > 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?199603090546.VAA22456>