Re: [Fwd: 2.6.10-rc3: tulip-driver: tulip_stop_rxtx() failed]

[frahm]

I am sorry, I forgot the modification for "i" in the loop and teh udelay:

> I expect one of three things to fix this:
> o The comet card needs more time than we've allocated.
>   Could you also try larger values for "i" in the loop?
>   e.g. 2000/10 or 4000/10
> 
> o The loop is too "tight" and poking the card every 10us is interfering
>   with DMA.  The solution is to change the udelay(10) to 50 or 100
>   (and the corresponding "i" value initialization).

Here is the output of dmesg (I carefully removed the old tulip module and 
inserted its new version after each recompilation.)

--- i=2000/10, udelay(10)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)
--- i=4000/10, udelay(10)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)
--- i=1300/50, udelay(50)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)
--- i=4000/50, udelay(50)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)
--- i=1300/100, udelay(100)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)
--- i=4000/100, udelay(100)
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 10 for device 0000:00:0e.0
PCI: Sharing IRQ 10 with 0000:00:0a.0
tulip0:  MII transceiver #1 config 1000 status 786d advertising 05e1.
eth1: ADMtek Comet rev 17 at 0001a400, 00:0C:F6:03:DA:D3, IRQ 10.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113)
eth1: Setting full-duplex based on MII#1 link partner capability of 4061.
0000:00:0e.0: tulip_stop_rxtx() failed (CSR5 0xfc06c012 CSR6 0xff970111)

There is no modification in the values of CSR5 and CSR6. I suppose this 
implies a Chip defect which is quite plausible since a I have cheap Sitecom 
card which is perhaps not 100% compatible with the tulip-driver ? 

> o Chip defect. When DMA is stopped, CSR5 Transmit State and Receive
>   State machines are expected to be zero. It's possible this chip
>   just never sets those states. I suppose we could check CSR6 bits
>   to confirm the ST and SR bits are clear before printing the message.
>   The CSR6 value above will tell me if that's feasible.

Greetings, Klaus.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/