Subject: Re: CVS commit: src/sys/arch/sgimips
To: None <thorpej@wasabisystems.com>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-mips
Date: 12/14/2003 12:15:16
In article <E270EB07-2DCF-11D8-ABE9-000A957650EC@wasabisystems.com>
thorpej@wasabisystems.com wrote:

> > With a quick glance, structure of wm(4) actually smells Intel-ism ;-p
> > uint8_t/uint16_t values in 32 bit DMA descriptors always cause
> > endian issue (and might cause race conditions on RISC CPUs.)
> 
> If you haven't already checked in this patch, please do, as long as you 
> can confirm it still works on i386 :-)

John Klos reported -current wm(4) was working (except hw cksum):
http://mail-index.netbsd.org/port-macppc/2003/10/20/0012.html
and fxp(4) (i82557.c) also has some uint8_t/uint16_t members
in its descriptors but it doesn't have #ifdefs to swap the members,
(and i82559 works fine on my macppc and sparc64)
so it seems Intel's bus masters are capable to access such members
in proper size (width/address) even on DMA transfers, so my patch
may not be needed for wm(4).

On the other hand, uint8_t/uint16_t members in DMA descriptors
might cause some race conditions if hosts don't have the method
to update memory in uint8_t/uint16_t width with single instruction.

I think -current fxp(4) has the problem (and I posted a patch
http://mail-index.netbsd.org/port-alpha/2003/11/08/0004.html
on port-alpha but it isn't confirmed by anyone yet),
but I'm not sure if -current wm(4) actually has the similar problem.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp