Long transmission times on SMC8432T - fix (hack) included

Chip: DC21041

I have just finished doing battle with this card and the tulip drivers for 
Linux. The problem I was getting is that packets seemed to be disappearing 
(in some versions of the driver) or pings seemed to take an inordinately 
long time - several seconds being common, and occasionally 24 seconds. 
Further investigation (entailing lots of additional debug output from the 
driver) revealed that the delays were all in transmission. Yes, on rare 
occasions it would take nearly 24 seconds between putting the packet in a 
descriptor, and receiving the expected interrupt (obviously this was a 
controlled situation where there wasn't much else going on).

As the card is connected to a cable modem with a 10Mb interface, I was 
starting the driver with "options=12" to ensure that it was using the 
correct media. It didn't help to start it without this option.

To cut a long story short, after substituting many variables, it turned out 
that the problem is with the way tulip.o configures the card - the card 
ends up thinking the link is intermittently going down.

I ended up putting together the tools to see what Windows was setting the 
registers to in order to see why Windows might work and Linux doesn't. I 
also had Windows configured to fix the interface speed. It turned out there 
were three key registers that were different:

Linux:
	CSR6 : 0xfffe2002 (or sometimes 0xfffe2102)
	CSR13: 0xffffef05
	CSR14: 0xffffff3f

Windows:

	CSR6 : 0x7ffc6002
	CSR13: 0xffffef01
	CSR14: 0xffff4f3f

For those who don't want to look up the bits, the differences are that window:

	Disables all capture effect features
	Turns off auto configuration
	Turns off auto sensing
	Turns off auto polarity
	Turns off link test

Rather than find the correct place to do this, I just implemented a rather 
gross hack in my local copy of the driver by putting the following in just 
before the appropriate write to CSR1. There were two other changes I made 
that may or may not be important (mentioned below).

	if ((inl(dev->base_addr + CSR13) & 0xffff) != 0xef01 ||
	    (inl(dev->base_addr + CSR14) & 0xffff) != 0x6f3f)
	{
		outl(0, dev->base_addr + CSR13);
		outl(0xffff4f3f, dev->base_addr + CSR14);
		outl(0xffff0008, dev->base_addr + CSR15);
		outl(inl(dev->base_addr + CSR6) & ~0x80030100,
				dev->base_addr + CSR6);
		outl(0xef01, dev->base_addr + CSR13);
	}

It's crude, but effective - my ping times are down to much saner values - 
and I figure that this information is likely to allow somebody else with 
better knowledge of the code to put a more correct fix in place (since it's 
working for me now, I didn't care to figure out which of the many points at 
which these registers are written needed to be adjusted).

I had also disabled the setting of the full duplex flag in CSR6 elsewhere 
in the code. With options=12 I can't see why this flag would need to be on.

As an additional note, it would seem to me self evident that if the 
medialock is true, the driver should not be setting up the timer to 
schedule media switches. I took the slightly different approach of merely 
making the timer routine return quickly if medialock was on.

In hunting this one down I came across a lot of people who seemed to have 
the same problem. Many places I looked suggested the solution was to delay 
by 2us before writing to CSR1, but this turned out to be incorrect - both 
ineffective and unnecessary (although there may be a problem on some clone 
CPUs that could be rectified by that).

Keywords:
DC21041 DC21041A DC 21041 DC 21041A SMC8432T SMC 8432T SMC 8432 SMC8432 
stalls high pings large pings long pings transmit timeouts transmission 
timeout time out time outs times out timed out dropped packets lost packets 
link fail link failure linux works under windows win98 win95 winnt very slow

_______________________________________________
tulip mailing list, [email protected]
To change to digest mode or unsubscribe visit
http://www.scyld.com/mailman/listinfo/tulip