Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!doc.ic.ac.uk!cc.ic.ac.uk!jensting
From: jensting@ic.ac.uk (Jens Tingleff)
Subject: Re: [FreeBSD]: problems with WD8003
Message-ID: <1993Oct23.120518.3515@cc.ic.ac.uk>
Nntp-Posting-Host: dinghy.ee
Organization: Elec. Eng. Imperial College, London
References: <2a9foo$iog@jadzia.CSOS.ORST.EDU>
Date: Sat, 23 Oct 93 12:05:17 BST
Lines: 90
[WD8003 problems. I had the same and mailed the FreeBSD list. Here is what I got]
To: rickrac@knock1.mgh.harvard.edu (Jimmy Rearick),
RMERCER@balaclava.cybercon.nb.ca, j.tingleff@ic.ac.uk
Cc: FreeBSD-bugs@freefall.cdrom.com
Subject: Re: FreeBSD ed0: shared memory corrupt [and other 'ed' problems]
From: David Greenman <davidg@implode.rain.com>
Reply-To: davidg@implode.rain.com
Date: Fri, 22 Oct 93 20:50:16 -0700
Sender: root@corbin.rain.com
Status: R
Okay, to summarize: several people have reported that they are having "shared
memory corrupt - invalid packet length xxxxx" problems.
There are a variety of things that are causing this problem (and other
problems related to the 'ed' device). Fortunately (for me), none of them are
problems with the 'ed' driver itself. I'm reasonably confident that these
problems are by-and-large caused by one of the following:
1) bugs in EPSILON where drivers that are at the same address as the 'ed'
device in the generic kernel scribble on the ASIC registers (not the NIC
registers) during their probe (the isolan driver is the curprit) and this
hoses the 8003 boards real well. If it was the NIC registers that were being
scribbled on, then this condition would be recovered when the device calls the
reset code (which reinitializes the NIC registers). In the current release of
the driver, the ASIC registers are not rewritten because the code to write
these registers is in the probe routines for the various board types, so there
is no way to do this after the probe has occurred during startup. This could
be changed, but the advantages are minimal (this condition is rare), and
changing the driver to do the ASIC initialization outside of the probe would
require a lot of work. ...Maybe in a future release. This problem has been
solved in "1.0 final" by only calling device probe routines for a given
address until a device is found at that address - thus avoiding the problem of
another probe routine hosing an already configured device.
2) The vm_fault panics are likely caused by bugs in EPSILON related to
incorrect allocation of memory for DMA buffers during the initial bootstrap,
or could also be caused by #1 (but I doubt it). Nonetheless, I think this
problem will go away if you use "1.0 final". If not, let us know! Similar
problems can happen more generally if the ISA BUSCLK is too fast, or you have
other hardware problems (like one or more cards aren't seated fully). This
seems to be much more of a problem for unix/BSD systems than for DOS, so it is
quite possible that the problem can go un-noticed until you try and bring up a
OS of this type. Regarding board seating: I know of a site where an SMC
8013EPC board (Elite 16) wasn't seated all the way and it looked to the system
like a (broken) 8003 on irq 0 - even with the EZSETUP program...and occasionally
wouldn't be seen at all...does this sound familiar?
3) ...and last there are configuration problems or conflicts. Make sure
that you don't have anything else on irq 5 (it's common for COM3 or COM4 to
use this irq, too). Even more important, make sure that you don't have any
BIOS extension ROMs in the D8000-DC000 range as this will certainly cause
these types of problems. Since DOS error reporting is so lousy, it is possible
that the interface could work marginally under DOS, and you wouldn't know you
have a problem. If you aren't certain about possible conflicts, then try using
a different address for the share memory and/or interrupt and/or IO address
for the card if you experiance problems such as this. (of course you'll have
to rebuild a kernel for the new addresses as well). If the problems persist,
check the hardware as closely as you can,...and if they still persist,
well...there's the release notes for the 'ed' driver in /sys/i386/doc; these
might help a little, ....and as a last resort, yell at us again, and we'll do
what we can to help you.
4) Some clone boards identify themselves as the wrong type of board, and
this can confuse the autoconfiguration into thinking that the board is
something that it's not. I've anticipated this, and have provided kernel
config file overrides to force various board characteristics. See the release
notes in /sys/i386/doc for more information. The Compex board is one example
of this - it identifies itself as an 8003E when it's really like an 8013EBT.
5) Some motherboards incorrectly cache the ISA memory region. This
absolutely must be disabled for shared memory ethernet boards to work.
6) Defective hardware. This can happen sometimes; no matter how good the
software is, it can't make broken hardware work. The only thing I could
suggest here is to try another board of the same type (if possible), or try to
use it under DOS or other OS.
'Hope this helps. Please, somebody forward this to USENET, my ability to post
at the moment is severely curtailed.
-DG
David Greenman
FreeBSD development team
--
Mr Jens Tingleff, M.Sc.EE. PhD student at
Imperial College, Dept of EE, Exhibition Road, London SW7 2BT, England
jensting@ic.ac.uk or jensting@dinghy.ee.ic... (used to be jensting@diku.dk)
"The Duc de Ventre says he will carry that ghastly schlup to his mausoleum" N L