From owner-freebsd-current@FreeBSD.ORG Wed Oct 26 19:48:01 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 0625816A421; Wed, 26 Oct 2005 19:48:01 +0000 (GMT) In-Reply-To: <200510262027.50488.thierry@herbelot.com> from Thierry Herbelot at "Oct 26, 2005 08:27:48 pm" To: thierry@herbelot.com Date: Wed, 26 Oct 2005 19:48:01 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051026194801.0625816A421@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@FreeBSD.ORG Subject: Re: error messages with ed(4) and current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 19:48:01 -0000 > Hello, > > I've resurrected one of my two ISA-based ed(4) boards, which is used to > exchange NFS traffic between a client (under -current) and a server (under > 6-RC1). The client is building world over NFS with both src and obj stored on > the server. > > The client is running -current as this this the only version able to set the > media on the NIC (thanks Warner). > > The error messages are : > Oct 26 09:01:18 newmail-fb6 kernel: ed2: device timeout > Oct 26 09:22:30 newmail-fb6 kernel: ed2: device timeout > Oct 26 17:31:51 newmail-fb6 kernel: ed2: device timeout Getting a few watchdog timeouts is not unexpected in this case, since it means you lost an interrupt somewhere, which I suppose can happen if the host CPU is slow or very heavily loaded (which I guess it would be if you're building world). Hopefully it recovers quickly. > the NIC is detected as : > %grep ed2 /var/run/dmesg.boot > ed2 at port 0x300-0x31f iomem 0xd8000 irq 10 on isa0 > ed2: Ethernet address: 52:54:4c:1b:90:1b > ed2: type RTL8019 (16 bit) FYI, this is a bogus station address. There are two bits in an ethernet address that have special meaning. If bit 0 in the first octet is set, then the address is a multicast group address rather than a unicast address. (Hence ff:ff:ff:ff:ff:ff is technically a special case of multicast.) If bit 1 in the first octet is set, the address is locally defined rather than globally assigned. Bit 1 is set in your address (the 2 in '52') which means either the code to read the station address from the NIC is broken, or the EEPROM on your card is scrambled. Or both. Another dead giveaway that the address is bogus is that 52:54:4c is not registered in the IEEE's OUI database: http://standards.ieee.org/regauth/oui/index.shtml -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose =============================================================================