Russell, Thanks for your hints. My problem turned out to be the cerf89x0 driver from Intrinsyc. Data access on the CS8900 is such that you must first write an address register before reading or writing the data register. cerf89x0 was doing this in an unprotected manner where transmits run off a timer could run on top of the receive handler. Sometimes the address register would get hosed. I guess FTP NAT response timing was just right.
I may take a look at updating the cs89x0 to support CERFCUBE and try to get it back into the main line kernel. We don't need 2 drivers for the same chipset. rtg On Monday 17 December 2001 15:08, Russell King - ARM Linux wrote: > On Mon, Dec 17, 2001 at 02:37:37PM -0700, Tim Gardner wrote: > > Good call! I have tried a couple of different exterior ethernet adapters > > with no effect. However, the interior ethernet driver is the built-in > > cerf89x0.c from Intrinsyc. Swapping the interior and exterior interfaces > > seems to work. Now to find the problem in the Intrinsyc driver... > > Just out of interest, with the internal interface on your internal lan, try > > ping <internal cerf ip> -c 1 -s 64 > ping <internal cerf ip> -c 1 -s 65 > ping <internal cerf ip> -c 1 -s 66 > ping <internal cerf ip> -c 1 -s 67 > > Do any return an error? > > _______________________________________________ > http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm > Please visit the above address for information on this list. -- Tim Gardner - [EMAIL PROTECTED] 406-443-5357 TriplePoint, Inc. - http://www.tpi.com PGP: http://www.tpi.com/PGP/Tim.txt _______________________________________________ http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm Please visit the above address for information on this list.
