Strange transmit corruption in jsm driver on geode sc1200 system

[Lennart Sorensen <lsorense@csclub.uwaterloo.ca>]

I am seeing a very strange problem with the jsm driver.

I am using a Digi Neo 2 DB9 card on a system with a Geode SC1200 cpu.
This is essentially an EXAR XC17D152 chip rebranded for Digi.

Kernel is based on debian's 2.6.16-17 which is 2.6.16.25 with a few
patches.

When I use minicom to transmit a chunk of text by sending a text file,
the data is transmitted in the wrong order.

testfile:
0123456789ABCDEF

Received text:
123056749AB8DEFC

If I use the same driver and the same card on a P4 system, everything
works fine.

The driver is doing memcpy_toio to tranfer data to the transmit FIFO
(which is a 64byte memory mapped block of memory on the PCI bus as far
as I can tell).  The data in the transmit queue is in the right order
being passed to memcpy_toio, but somehow by the time it is in the uart
and goes out the transmiter, every 4th byte is moved 3 bytes back.
Transmitting a single character at a time works fine of course since
there is nothing to swap it around with, and it is only copying a single
byte to the UART rather than a block of bytes.

I read something about the geodes doing memory write reordering, but
that it is supposed to magically not screw up PCI writes.  I have no
idea if it is or not though.

I have no problem with pcnet32 or any of the other PCI devices I use.

Does anyone have any suggestions for something to try?

The cpu in question has this information:
processor       : 0
vendor_id       : CyrixInstead
cpu family      : 5
model           : 9
model name      : Unknown
stepping        : 1
cpu MHz         : 266.760
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu tsc msr cx8 cmov mmx cxmmx
bogomips        : 535.33

I noticed that cyrix.c has some code for controlling reordering and
such, although it doesn't seem to match this particular cpu's ID, so it
isn't called.  I have no idea if it should have.

--
Len Sorensen