Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!wupost!bigboy.sbc.com!news.mtholyoke.edu!news.byu.edu!ns.novell.com!gateway.univel.com!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.215055.21172@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <DERAADT.93Mar26160807@newt.fsa.ca> <1993Mar29.142429.12369@cm.cf.ac.uk> <1993Mar29.144932.23840@uvm.edu>
Date: Tue, 30 Mar 93 21:50:55 GMT
Lines: 70
In article <1993Mar29.144932.23840@uvm.edu> wollman@sadye.emba.uvm.edu (Garrett Wollman) writes:
>In article <1993Mar29.142429.12369@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul) writes:
>>Unlike the western digital cards there isn't
>>even an id so you can see if it's actually an isolan.
>
>And then he writes:
>
>>These cards have a
>>sixteen byte area of rom which contains the ethernet address and two
>>ports which are used to access the Lance registers.
>
>Ummm, you're contradicting yourself, Paul. If it has an Ethernet
>address on it, then it has an ID so you can see if it's actually an
><X>. Every Ethernet/802.3 address ever assigned has 24 bits of vendor
>ID in it.
I think Paul's problem is locating the address of the ID, and, if located,
ensuring that the 1 in 2^24 possibility of misidentifying some memory
from something else as belonging to a card.
If I remember correctly (from about 8 months ago), locating the ID won't
give you which ports to use (they are selected seperately).
Theo points out [ in a later posting ] that one can cause the card to
generate an interrupt. This won't necessarity work if other interrupts
are occurring at the same time (like a COM card or a printer card might
be causing if the boot is a result of power on and a slow printer or
modem is still resetting (an outgrowth of not disabling any interrupts
during boot)... and that "false interrupt" occurs at a potentially
valid location for the card currently being probed for.
Multiple cards also present a problem; even if identified, you can't tell
the difference between "card A at port a + card B at port b" and "card A
at port b + card B at port a".
There is also the issue, not yet discussed, of shared interrupts; for
instance, I might have two Control Systems Hostess boards in the same
machine sharing IRQ 4. Identification of which card caused the interrupt
is done by asking the card. This is fine if the cards sharing the
interrupt are homogenous and can use the same method; what if they aren't?
A probe routine can't be guaranteed of the source of the interrupt if
it's shared, for instance, between a multiport com card like the Hostess
and some other [non-Hostess] device.
In either of the above two cases, simply stopping when one card is
identified is not sufficient to get both cards working, nor is a single
pass sufficient to identify al hardare sharing interrupts.
Restricting the scope of the problem by providing more information is a
natural workaround; however, this puts us back in the boat of not being
fully auto-configurable, our stated goal (ie: we provide more data to
the config).
I don't think the problem of autoconfiguration, at least on an ISA bus,
yields 100% to any potential attack; we are going to have to continue
providing static configuration information to all but a small subset
of all devices.
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
-------------------------------------------------------------------------------