Well, I just got bit by this one, and thought I would
publish the details to help others who may fall into this
pit.  Also, I suppose it is good to keep this in the
memory of those who may do something about it.

I am/was installing the GENERIC NetBSD 1.1 kernel
on my 486 machine at home.  In this machine I have a WD/SMC
8013 ethernet card, set via hardware jumper to i/o address
0x300, irq 10, iomem 0xcc000.  The kernel probe finds it,
but reports that its irq is 9 != kernel (10), which was the
first evidence of trouble.  Running the DOS "EZSETUP" utility
supplied by SMC now reports that there is no card in the
system.  Figuring the card might be flakey, I grabbed
another SMC8013, checked it out with EZSETUP under DOS to
make sure it is OK, and give it a whirl, the same message
under NetBSD, and the same effect afterwards, the card is
no longer in existence as far as the vendor setup software
is concerned.    (Sounds ugly, eh?)  2 cards down, and ....

Grubbing thru these mailing lists, I now find this is a more
or less well known problem, and that the explanation is that
some shabby probe code for a CD-rom (mcd0 ??) is rewriting the
NVRAM on my network card, and that I can fumble around with DOS
debug to restore them to working order (I just hope the 6-byte
network address is on a sticker on the card).

Thanks to Andrew Wheadon for publishing the recipe for doing
this a month or two ago in this list.  I just escaped having
this disaster on my machine at work because I was already
running a reduced custom kernel on that machine when I changed
to an 8013 card on that system.  The fix recipe as I understand
it is:

1) boot DOS and fire up DEBUG, use i xx to read (like inp()),
and o xx val to write (like outp()).

2) look at 0x308 - 0x30d to see if the boards 6-byte ethernet
address is there.

3) look at 0x30e to see if a board type is there (like 0x28 or 0x29,
but see if_edreg.h for a complete list of codes (maybe)).

4) if (2) and (3) are screwed up, make them right using debug, then
make 0x30f be a checksum value such that the sum of 0x308-0x30f
modulo 256 is 0xff

5) choose a different io address than 0x300 for the card so this
whole scenario is not repeated (until such time as the offending
probe routine is made less intrusive).  It turns out this is not
so easily achieved.  The ed0 and ed1 entries in the GENERIC kernels
use irq 9 and there is NO WAY to configure a WD8013 to use irq-9.
Now we all know why WD8013 users are choosing the 0x300 io address
and getting into this pickle.

Let me re-emphasize this.  There is no way to install with a
GENERIC kernel over the network with an 8013 card.  Luckily I have
a machine at work running NetBSD and I can put a custom kernel
on a boot floppy and take that home to this machine I am working
with.

It would be nice to put this into a BUGS entry for the ed driver.
In fact it would be nice for the man page for each driver to have
a collection of useful lore like this for the relevant hardware.....
(I am reminded of the kermit .bwr files)

	Tom

-- 
	Tom Trebisky			Steward Observatory
	ttrebisky@as.arizona.edu	University of Arizona
	(520) 621-5135			Tucson, Arizona 85721

--RAA09689.830739125/aspc15.as.arizona.edu--




 
om Trebisky			Steward Observatory
trebisky@as.arizona.edu	University of Arizona
520) 621-5135			Tucson, Arizona 85721