[tulip] Kingston KNE111TX Full Duplex LED
Thu, 29 Mar 2001 11:37:19 +0100
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
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
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
John Connett (email@example.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
> 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 firstname.lastname@example.org
> Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
> Annapolis MD 21403 410-990-9993