Subject: Re: SMC9432TX driver (tx) users
To: Ustimenko Semen <semen@iclub.nsu.ru>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: current-users
Date: 11/03/1998 11:08:02
[ 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 <semen@iclub.nsu.ru> 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