Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!newsserver.jvnc.net!yale.edu!ira.uka.de!smurf.sub.org!flatlin!bad From: bad@flatlin.ka.sub.org (Christoph Badura) Subject: Re: my bug list Organization: Guru Systems/Funware Department Date: Wed, 31 Mar 1993 20:45:38 GMT Message-ID: <C4rto3.Dr1@flatlin.ka.sub.org> References: <DERAADT.93Mar11154207@newt.fsa.ca> <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca> <1993Mar30.003656.2601@fcom.cc.utah.edu> Lines: 109 In <1993Mar30.003656.2601@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <DERAADT.93Mar25200858@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes: >You can't do a device/slot reset on an ISA bus. Right, you CAN'T do a slot reset on the ISA bus. You can ONLY reset the processor. >In order to cause a real >reset, you have to drop out of protected mode and hit the keyboard soft >reset code. I don't know what you mean by "real reset" or to which keyboard soft reset code you allude. To reset the processor you only have to issue a command to the keyboard controller. I don't see why that shouldn't be possible from protected mode. >This is not necessarily possible on all ISA machines due to >the way one has to drop out of protected mode generally causes a reset -- Since the only ISA machines of interest are 386/486 based ones one doesn't have to reset the processor to switch back to real mode. That was only necessary on the 286 (and the keyboard controller reset logic was kludged together for exactly this purpose). For a good example on how to repeatedly switch back and forth between real and protected mode you, Terry, should take a look at the SVR4 bootstrap loader. >Yes, it's possible to work around, in three ways: >1) The bad way (a change to the probe routine). Actually this would be the best way for the WD8013. If you had taken a look at the driver source, you would have noticed that the probe routine tries to reset the card before it tries to check wether the card is present. Apparently that part of the code doesn't work reliably. Therefore it seems that the probe routine is broken and should be fixed. >2) The elegant way (a change to the device interface). >3) The best way (use the EISA bus instead of the ISA bus). >>Obviously, that's because the probe routine is not causing an interrupt >>from the card. That's because the probe routine tries to cause an >>interrupt, but unfortunately, the card has not been reset, so it ignores >>the particular probe sequence. Theo is wrong here because the WD8003 driver doesn't try to trigger an interrupt from the card. >Soloution 1 is the expedient suggested by you and several others. The >problem is that it relies on the assumption that a device of the type being >probed exists. This is a fallacy, since it means I can *NOT* have multiple >devices on the same interrupt, only one of which gets attached as a result >of a successful probe. You are using the IRQ as a device discriminator, >and this is invalid, since it blows out the ability to distribute kernels >which whill run on multiple hardware configurations. This is true because >you must attach the intterupt before the probe is complete for the probe >to succeed. This is rats ass bogus. Nonsense. BSD style driver autoconfiguration is supposed to work the following way: the probe routine tries to determine that that specified device is indeed present at the specified address(es). If it finds a device it is supposed to trigger an interrupt from the hardware. The autoconfiguration code notices the interrupt and records vector and level for that device. There is an implicit (and not unreasonable) assumption that at this time no other device will trigger an interrupt. Nowhere is the assumption made that the device being probed for actually is present in the hardware configuration. Obviously this scheme can be enhanced to check wether the received interrupt level and vector are indeed the same as those specified in the config file. Obviously this scheme allows probing for devices that share interrupts, since only one device interrupts at any given time. (Just for the record: my Logitech BusMouse powers up with interrupts enabled and generates them right away.) >Soloution 2 depends on modifying every device driver to include a "shutdown" >routine. This is necessary anyway for taking the UART's out of FIFO mode >when using Chris' new com drivers, since the BIOS initialization routine >is too stupid to initialize the hardware from *any* potential state to a >known state; In this special case there is no need for a "shutdown" routine as the com driver's close routine can put the UART's out of FIFO mode. (It should stop the UART's receiver too if possible.) Anyway the driver interface needs to be changed for network devices only since one can use the device's close routine for this purpose. >I disagree. If the probe did not depend on the interrupt and/or the card >being in a known state (as would be the case if the inventory were present >and stateless), a single device/slot reset would be possible without >assuming the probe would succeed. This is completely self contradictory. If the probe routine didn't depend on the card being in a known state a single device/slot reset wouldn't be necessary in the first place! And in fact the we driver doesn't depend on the fact and tries to put the card into a known state instead. -- Christoph Badura --- bad@flatlin.ka.sub.org Personally, I don't care whether someone is cool enough to quote Doug Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall