Messages in this thread | | | Date | Fri, 13 Nov 2009 16:23:01 +0000 | Subject | Re: i686 quirk for AMD Geode | From | (Lennart Sorensen) |
| |
On Thu, Nov 12, 2009 at 01:18:05PM +0100, Pavel Machek wrote: > Interesting...geode gx being buggy? I know pentium was famous for the > fdiv bug, but never heard of geode gx problems... > > Are they something kernel can work around, or do those chips just have > to be avoided? Anything malicious user can use to crash the system? > Anything malicious user can use to gain extra priviledge?
Well the one problem I have encountered is in the jsm driver (exar pci uart driver).
On a typical PC with a P3, P4, Core 2, athlong, etc, it works perfectly. It works perfectly on a Geode LX as well. On a Geode SC1200 (which is a GX with companion chip in one) it transmits out of order in a consistent way.
If you transmit a chunk of data that looks like this:
0123456789abcdef
The data that comes out of the UART is:
123056749ab8defc
The fix to avoid the problem is:
- memcpy_toio(&ch->ch_neo_uart->txrxburst, ch->ch_wqueue + tail, s); + for(i=0;i<s;i++) { + memcpy_toio(&(ch->ch_neo_uart->txrxburst[i]), ch->ch_wqueue + tail + i, 1); + }
Calling memcpy_toio on the Geode SC1200 on anything larger than 1 byte causes the data to be delivered (at least on the PCI bus) reordered in that very consistent manner.
The alignment doesn't affect it (I tested that). Simply doing more than 1 byte at a time with memcpy_toio to the pci device messes up.
So as a result we run with this patch applied even though it certainly is less efficient, but at least it works.
Every other CPU works fine that I have ever tried the driver on.
-- Len Sorensen
| |