Subject: Re: CVS commit: src/sys/arch/sgimips
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 12/14/2003 12:15:16
In article <E270EB07-2DCF-11D8-ABE9-000A957650EC@wasabisystems.com>
> > 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):
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
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.