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!usc!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: my bug list
Message-ID: <1993Mar30.020058.3999@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca> <DERAADT.93Mar25202827@newt.fsa.ca>
Date: Tue, 30 Mar 93 02:00:58 GMT
Lines: 102
In article <DERAADT.93Mar25202827@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes:
>In article <DERAADT.93Mar25200858@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes:
>> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> >I think you'll find that the majority of the problem here is the PC bus
>> >architecture being device-indeterminate. THere is no mechanism whereby I
>> >can ask a device "what are you?". This is distictly different from most
>> >of the bus architectures out there today (like VME/BI/QBUS/FutureBus/SBUS/
>> >etc.).
>>
>> This has absolutely diddly squat to do with a hardware inventory. VMEbus
>> on a Sun does not have a hardware inventory list either. Somehow it
>> works just fine in sun3 and sun4 machines, eh?
>
>To follow up a bit more..
>
>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.
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?
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).
>About a month ago I suggested a simpler change. I wanted simply that
>the "irq" value could be entered as "?" and the device driver's
>probe() routine could find the IRQ. isa/isa.c already checks for IRQ
>collisions... Unfortunately I've had very poor luck with making the
>changes because whoever wrote the original ISA IRQ code in 386BSD
>seemed to know next to nothing about how to the BSD probing code
>works. At least that person could have read the papers that describe
>it <hmph!>, and they'd have found out that greater flexibility is
>required. Interrupts should be enabled during config time, so that you
>can see if you really found the device!
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).
>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,
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.
>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.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------