Messages in this thread |  | | Date | Fri, 16 Feb 2007 19:00:19 -0500 | Subject | Re: MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange connection slowdown on pcnet32) | From | (Lennart Sorensen) |
| |
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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |