From owner-freebsd-hackers Tue Nov 3 11:11:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23287 for freebsd-hackers-outgoing; Tue, 3 Nov 1998 11:11:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23282; Tue, 3 Nov 1998 11:11:02 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id LAA25745; Tue, 3 Nov 1998 11:08:02 -0800 (PST) Message-Id: <199811031908.LAA25745@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Ustimenko Semen Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG, current-users@netbsd.org Subject: Re: SMC9432TX driver (tx) users Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 03 Nov 1998 11:08:02 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ 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... ] On Tue, 3 Nov 1998 18:24:37 +0600 (NS) Ustimenko Semen wrote: > If you use tx driver under FreeBSD, can you send me private > message if you have ANY problems useing it. > > Even if the problem is only > tx0: timeout %d packets, ... 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. There is an application note which describes a hardware bug, and a work around for it. Here is the workaround from my "epic" driver: /* * Fixup the clock source on the EPIC. */ void epic_fixup_clock_source(sc) struct epic_softc *sc; { int i; /* * According to SMC Application Note 7-15, the EPIC's clock * source is incorrect following a reset. This manifests itself * as failure to recognize when host software has written to * a register on the EPIC. The appnote recommends issuing at * least 16 consecutive writes to the CLOCK TEST bit to correctly * configure the clock source. */ for (i = 0; i < 16; i++) bus_space_write_4(sc->sc_st, sc->sc_sh, EPIC_TEST, TEST_CLOCKTEST); } This function is called in various places when we think the chip might be catatonic. See src/sys/dev/ic/smc83c170.c in NetBSD-current. This may not be the only problem the hardware has, or I may not be fixing up the clock source in all the right places... I would be VERY interested to know the FreeBSD experience with this hardware, even given the completely different driver software being used. Thanks! Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 650 940 5942 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message