From owner-freebsd-hackers Tue Nov 3 23:18:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA06264 for freebsd-hackers-outgoing; Tue, 3 Nov 1998 23:18:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06248; Tue, 3 Nov 1998 23:18:35 -0800 (PST) (envelope-from semen@iclub.nsu.ru) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.8.8/8.8.5) with SMTP id NAA14688; Wed, 4 Nov 1998 13:15:30 +0600 (NS) Date: Wed, 4 Nov 1998 13:15:29 +0600 (NS) From: Ustimenko Semen To: Jason Thorpe cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG, current-users@netbsd.org Subject: Re: SMC9432TX driver (tx) users In-Reply-To: <199811031908.LAA25745@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 3 Nov 1998, Jason Thorpe wrote: > [ I've added current-users@netbsd.org, because NetBSD users have seen > timeouts with the driver for the EPIC that I wrote, and I believe it > is a hardware problem... ] > > With my 9432TX (in an AlphaStation 500 running NetBSD/alpha) I have seen > these device timeouts. Note, NetBSD's "epic" driver is NOT the same as > FreeBSD's "tx" driver; I wrote "epic" from scratch. However, I have NOT > been able to find the source of these timeouts. People have reported to > me that they are more common in 10Mbps mode, apparently. Sometimes the > card just wedges completely, and I have to reboot to get it to come back. > Sometimes, not even a reboot solves the problem. Not long time ago, there was a problem with card. It hangs just after initialization, on first outgoing packet. I have added check of link status before queueing packets, and the problem (i hope) has disappeared. The problems often appear at slow computers (like 486-DX4 (100)) at 100Mbps under heavy load, like ping -f -s 65000 ... from some quicker station. Internal buffer and rx ring overflow, sometimes following with card shutup. Usually fixed with ifconfig tx0 down up. If only we can make driver spend less time in interrupt... But at least we need to recopy received packet or allocate place for new one. > There is an application note which describes a hardware bug, and a work > around for it. Here is the workaround from my "epic" driver: > ... > Application Note says that we need to set clock source only at initialization... Thank you for pointing me on it, this may be better solution that link checkup before transmition. > I would be VERY interested to know the FreeBSD experience with this > hardware, even given the completely different driver software being > used. They said that this card works fine both at 10 and 100 Mbps. Even without timeouts. But sometimes it fails to autoselect 10Mbps modes, sometimes to force card to 10Mbps mode. I think this is the bug(s) in PHY used (QS6612, have You seen another?). I'll ask OpenBSD users too. Thenk you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message