*BSD News Article 21792


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!uwm.edu!ogicse!psgrain!agora!davidg
From: davidg@agora.rain.com (David Greenman)
Newsgroups: comp.os.386bsd.questions
Subject: Re: ed0: device timeout
Message-ID: <CECCBt.HCn@agora.rain.com>
Date: 3 Oct 93 21:43:02 GMT
Article-I.D.: agora.CECCBt.HCn
Organization: Open Communications Forum
Lines: 49

rickrac@knock1.mgh.harvard.edu (Jimmy Rearick) writes:
>I keep getting this error message when my FreeBSD system boots.
>   ed0: device timeout
>What could be causing this?  I can't connect to anything on our network.
>Thanks.

and...

sjg@zen.void.oz.au (Simon J. Gerraty) writes:
>I have the same problem with ed0 (and a WD8003E).
>
>I had assumed it was simply lack of receiving a packet on the ethernet
>- my machine is currently alone on the net.  Jim's comments blow that
>theory though.

Nope, it's not because there aren't any packets on the net.

>My only other theory was that I had the IRQ set wrong (set by a jumper
>jon the WD8003 and I have no doco so I'm guessing.  If anyone has docs
>for an old 8bit WD8003E please mail me).  I believe that the IRQ for
>the 3C503 is set by software though.  If correct then this theory dies
>too.  

Yup, that's the problem. Why do you mention the 3c503? I don't recall
anybody bringing this up in the past.

>I know my IO address is ok as the device is probed and attached ok:
>
>Sep 12 17:47:57 zen /386bsd: ed0ed0: address 00:00:c0:dc:60:10, type WD8003E (8bit) 
>Sep 12 17:47:57 zen /386bsd:  at 0x280-0x29f irq 10 maddr 0xd0000 msize 8192 on isa
                                              ^^^^^^
Well, the evidence is right in front of you - the 8003E is an 8bit card, so
how is it possible to use irq 10? Answer: It isn't; irqs between 9-15 
are on the 16bit extension slot of the ISA bus.

>That ed0ed0: bit bugs me too, but the printf's look ok.

This tells me that you aren't using NetBSD or FreeBSD, because in these
two systems, the probe/attach code in the kernel has been changed and
the driver printf's were made to work with that.

>So if any one has solved the device timeout I'd love to hear too as my
>other machine is comming back next week and I'll want NFS running.

It's not a bug in the code...this error occurs whenever a transmit is
started on the interface and it never gets a completion interrupt. Or
in other words: you have the board/kernel configured wrong.

-DG