[tulip] Kingston KNE111TX Full Duplex LED

[John Connett]

I think I may be getting somewhere with this.  Using the v0.92t driver
as a base, I inserted code to output the value of CSR9 before and
after all the obvious places it could be changed (it's possible I
might have missed some aliases).

Disconnecting and reconnecting as before didn't show any places where 
CSR9 was being changed and the LEDs were well behaved.

I ran "tulip-diag -fa" to check the value of CSR9 and it looked good. 
Just to be sure, I ran "tulip-diag -fa" again and the value had
changed!

My current thoughts are that the problem only occurs if you look for
it with "tulip-diag -fa".  An inspection of the code shows that
tulip-diag can modify CSR9 directly, bypassing the driver.  As this
program needs to be run as root this is unlikely to be an issue for
most uses.

So the suggested fix:
> Donald Becker wrote:
> > OK, better spot: just after start_link(dev) around line 848 in
> > tulip.c
> > 
> >         start_link(dev);
> > +       outl(0xf0000000, ioaddr + CSR9);
but with the 0xf0000000 replaced with 0x80000000 appears to be
effective.
--
John Connett (jrc@art-render.com)


Donald Becker wrote:
> 
> On Fri, 9 Mar 2001, John Connett wrote:
> > Donald Becker wrote:
> > > OK, better spot: just after start_link(dev) around line 848 in tulip.c
> > >
> > >         start_link(dev);
> > > +       outl(0xf0000000, ioaddr + CSR9);
> > >
> > > This worked on the PNIC2 card here.
> >
> > After some more experimenting, and using tulip-diag -fa to examine the
> > value of CSR9, it appears that the top 4 bits of CSR9 are set to zero
> > under some circumstances.  This seems to happen when
> > disconnecting/reconnecting to test autonegotiation.  Typically, a
> > message of the form:
> >
> >     eth0: PNIC transmit timed out, [...], resetting ...
> >
> > is output to the console.  Are there other locations where CSR9 should
> > be reloaded?
> 
> There are three actions that rewrite CSR9
>    - reading/writing the EEPROM
>    - reading/writing the MII registers
>    - reading/writing the boot Flash
> 
> [[ Note: putting the LED settings in CSR9 was a very bad design. ]]
> 
> The only actions that the driver should do is reading the EEPROM once
> during probe and, for some chips, reading the MII transceiver
> registers.
> 
> The driver shouldn't try to read the MII transceiver for the PNIC2, but
> there may be a code path during error recovery that causes this.
> Do you have the exact timeout message?
> What did you do to trigger the timeout (just disconnect the cable)?
> 
> Donald Becker                           becker@scyld.com
> Scyld Computing Corporation             http://www.scyld.com
> 410 Severn Ave. Suite 210               Second Generation Beowulf Clusters
> Annapolis MD 21403                      410-990-9993