On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote: > Well so far it really looks like enabling OOSTORE on the Geode > SC1200/GX1 really does make a difference. A bit of searching seems to > indicate the person that originally submitted the patch that enabled > load/store reordering on the MediaGX/Geode though it might need OOSTORE, > but was convinced by others it didn't. Looks like it really does need > it. The failure that occoured before within a few seconds of starting a > large transfer, no longer fails and all I did was enable > CONFIG_X86_OOSTORE, and recompile pcnet32.ko and load the new module on > the running system. Moving back to the pcnet32.ko built without OOSTORE > enabled hits the failure again within seconds, until ifconfig eth1 > down/up reinitialized it's descriptor ring, after which it survices > another bit of transfer and then fails again.
Well forcing load/store serialize on the CPU doesn't help, disalbing memory bypass doesn't help. Enabling the X86_OOSTORE does help. What a stupid CPU design. So far nothing has managed to fix the __memcpy_toio in the jsm driver getting data out of order when sending on an exar pci uart chip. Only calling memcpy with one byte at a time seems to work there. Works fine on every other cpu of course. What else am I going to discover is wrong with this CPU. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html