Jason R Thorpe wrote:
> Hm.  I see what you're saying, but I don't think there is actually a
> problem; this is more likely to be a deficiency in the documentation.

Ok ... I still think there are some problems with the driver.

Perhaps I should first try to correct/clarify the bus_dma manual page
to have a base for discussions ?


>  > If the driver code is correct (and the manual page is wrong) the architecture
>  > specific implementation of _bus_dmamap_sync for i386 must be converted from
>  > a no-op to a serializing assembly instruction for BUS_DMASYNC_POSTREAD 
>  > synchronization.
>  > ( Otherwise you might get out of order CPU reads of in order DMA read 
>  > operations )
> 
> Err... the i386 version makes a run-time (not compile-time!) test for
> a NULL pointer, and jumps through it if non-NULL.  This should act as
> a memory clobber for the compiler whether or not the function pointer
> is NULL, thus providing the serializing instruction (I agree with you
> that it would be bad for the compiler to reorder in this case, I just
> think that the compiler already has information that tells it not to
> do so :-)

I was not worried about the compiler reordering reads - P6 family processors
do this automatically on their own with cacheable memory.
( Intel Architecture Software Developer's Manual, Vol 3 , 7.2.2 Memory Ordering
in the P6 Family Processors )
Adding a serializing instruction (as described in 7.2.4 of the same Intel 
manual) to
the i386 bus_dmamap_sync should fix this.
 
> Out of curiosity, are you chasing an actual bug you've experienced, or
> is this purely a result of code observation?

Code observation.
Basically I use code reviews as a reality check of my understanding of the 
netbsd kernel / processors /
chipsets. Since I debugged some race conditions with a proprietary 82557 
driver a few years ago
the corresponding netbsd driver was an ideal reading target.


Stephan

 
----------------------
Stephan Uphoff 
ups@stups.com
9275 Martin Road
Roswell, GA 30076
770-518-4058