I have tried that in this case but it didn't help,
because the receive skb data pointers all point to
the KSEG0 view of the data anyway.
I looked into similar problems a while back. If I remeber correctly, the data
pointers do point to kseg0. It is up to the driver to do appropriate
dma_cache_invalidate() (or some functions to that effect) at certain places.
Yes, the tulip driver calls pci_unmap_single() on the receive
buffer, but for mips (in asm-mips/pci.h) this call does
nothing. And this is what is so confusing. Only if the
receive buffer was forced to be in KSEG1 would this make
What is the CPU? It seems logical to suspect about the dma cache routines.
Yes, I have scrubbed over my patch to the cache routines
many times, especially since on the IDT 334 the cache-way
selection for indexed cache ops is weird--they left the
way-bit up at bit 12 as if it were an 8KB cache, when
in reality it is only a 2KB cache.