lkml.org 
[lkml]   [2009]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: i686 quirk for AMD Geode
From
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


\
 
 \ /
  Last update: 2009-11-13 17:25    [W:0.973 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site