Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!sdd.hp.com!nigel.msen.com!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 21:10:37 GMT Message-ID: <C4rutp.F14@flatlin.ka.sub.org> References: <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca> <DERAADT.93Mar25202827@newt.fsa.ca> <1993Mar30.020058.3999@fcom.cc.utah.edu> Lines: 62 In <1993Mar30.020058.3999@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >I agree that a hardware inventory, per se, is not required, *proivided* that >you have a means of identifying which cards IRQ goes with which port; for >instance, I could have two we devices defined in one box; how do you >probe: >device we0 at isa? port ? net irq ? iomem ? iosiz ? vector weintr >device we1 at isa? port ? net irq ? iomem ? iosiz ? vector weintr >and come up with what IRQ goes with what port? Simple. You probe for the first port and if you think you found a card, you execute a code sequence that under all circumstances triggers an interrupt from the card. Since at this time no other device interrupts you can easily figure out which IRQ the card uses. Further, if you don't get an interrupt you know that you either have a hardware malfunction or the card isn't of the type you're probing for. In either case you can fail the probe. Please, Terry, go read the paper "Building Berkeley UNIX Kernels with Config". It explains in excruciating detail the autoconfiguration process and the necessary driver support. You'll find the paper in the /usr/othersrc/share/doc/smm/02.config directory. >Agreed on the interrupts being enabled; disagreed that an interrupt alone >is sufficient to identify a device; Theo didn't suggest that the device should be identified on an interrupt allone. He suggested that the probe routines actually check that the device interrupts as expected. And failing to interrupt is sufficient to fail the probe routine. >for instance, 386BSD 0.1 came with >almost all it's network cards at IRQ 2; the probe was responsible for >identifying the network card, usually by checksumming the ROM or other >silly method (which is about the best you can do). Right, and if it used an interrupt as an *additional* check, there would have been fewer problems. >The problem is determining which device gave the interrupt if you have >multiple devices which will probe out to the same interrupt; Since we don't deal with multiprocessor machines that probe *concurrently* for different devices this is, obviously, a non-issue. >in any case, >the probe routine for the WD8013 if it expects the be able to identify a >card after warm boot after running and a shutdown routine is not provided >will require resetting the card as if it were there, with unpredictable >results if another card is there (although it's pretty safe if a card isn't >there). And if you could be bothered to actually read the source you would have noticed that the WD8013 probe routine actually tries to reset the card. -- 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