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!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!fsa.ca!deraadt From: deraadt@fsa.ca (Theo de Raadt) Subject: Re: my bug list In-Reply-To: terry@cs.weber.edu's message of 30 Mar 93 02: 00:58 GMT Message-ID: <DERAADT.93Apr10132500@newt.fsa.ca> Sender: news@fsa.ca Nntp-Posting-Host: newt.fsa.ca Organization: little lizard city 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> Date: Sat, 10 Apr 1993 20:25:00 GMT Lines: 90 In article <1993Mar30.020058.3999@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >The vax does not supply a hardware inventory list either. The entire information > >as to where devices can be found is the config file. It is of course legal > >in the config file to do something like this.. > > > >device we0 at isa? port ? net irq ? iomem ? iosiz ? vector weintr > > > >assuming of course that the weprobe() routine was able to figure out all > >the rest. Terry -- you DON'T need a hardware inventory list to be able to > >do this! The probe routine could have a list of possible sequences of places > >to *try* to find the device. > ... > 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? This is an illegal specification. device specifications always must specify at least one thing fixed and known. I'd suggest the hardware address. Wait till you see how much worse this mess gets with the 3com 3c509.. > Note that we can't preidentify cards, since a checksum of a memory range is > only valid if we exclude the use of clone devices (they fail WD checksum). the rom checksum idea is a stupid idea anyways. There are better ways to check for sure if it is a we controller. > Agreed on the interrupts being enabled; disagreed that an interrupt alone > is sufficient to identify a device; 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). You CAN do a lot better. There are zillions of things that are different about these controllers. Send a command that causes an interrupt! Ethernet cards are complex things. They operate in different ways. Try one of those different ways. You might have to configure the card quite a ways, but you can tell. > >The BSD method for finding devices is... > > > > cause an interrupt from the device to CHECK if it really exists. > The problem is determining which device gave the interrupt if you have > multiple devices which will probe out to the same interrupt; in any case, It is illegal and unlikely in ISA hardware to have multiple devices at the same irq. Check it out Terry! The XXintr() routines will NOT be called correctly. > 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). > Much better to provide a shutdown routine (read: wait until 0.2 or 0.1.5 > if Bill agrees to include such a massive change that will be required of > every device driver. Why not just incorporate the shutdown code into XXprobe()? That's where it belongs. Look at a vax NET2 device driver.... > >Now, all the devices which people are having trouble with CAN cause an > >interrupt. But interrupts are fully disabled while booting! The code > >that needs rewriting is in isa/isa.c gets rewritten, in case anyone > >who knows more about the ISA bus wants to venture in and make it work > >so interrupts are fully enabled while the probe routines are being > >run. (Look at the vax code to see how it's supposed to be written.) > I agree that the "interrupts disabled during boot" is ridiculous (assuming > all interrupts have been redirected to interrupt counting routines so they > can be picked up during boot); but fixing this alone is not enough to > identify *which* possible device on IRQ2 the interrupt came from. > >It's amazing how much "Not Invented Here Syndrome" is happening here.. > A lot of it, at least in this area (booting) is a result of enforcement > of copyright laws -- the VAX stuff isn't exactly public domain, and neither > is the Xenix or Linux stuff that has been suggested. The VAX stuff is there to look at, freely. Ftp yourself a copy of NET2 from uunet. In sys/vax/ there's a bunch of directories of device drivers. Since we're talking about network interfaces, I'd suggest you look at sys/vax/if/*.c Every file has the standard UCB copyright on it. It's free as free to look at. I don't understand why you said it wasn't free. <tdr. -- This space not left unintentionally unblank. deraadt@fsa.ca