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