Skip to contentSkip to conversation

flush_cache_all() hoses my Indy

DISCUSSION Mike Shaver 2 participants 2 messages Dec 22, 1997 MIPS

lore
Share & tools
lore
#0 lore raw

OK, I've been tracking a bug that only seems to appear on the Indy I have at home right now (belongs to the housemates). After sgiseeq_init allocates the ring buffers, it calls flush_cache_all(). On this system, that zeroes out the ring buffer pointers (rx and tx -- likely the entire dev->priv block and more) and then setup_tx_ring gets understandably upset. =)

Anyway, I'm not enough of a MIPS guru to really say much more, but I'll poke around tonight and see if I can stumble across anything useful.

Linux reports:
MIPS 4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
CPU Revision 0460

hinv tells me:
1 200 MHZ IP22 Processor
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
CPU: MIPS R4400 Processor Chip Revision: 6.0 Instruction cache size: 16 Kbytes
Data cache size: 16 Kbytes

More than this I do not know, but I'll run any test that doesn't risk permanent damage.

Mike

#1 lore raw
Quoted 7 lines · Mike Shaver

OK, I've been tracking a bug that only seems to appear on the Indy I have at home right now (belongs to the housemates). After sgiseeq_init allocates the ring buffers, it calls flush_cache_all(). On this system, that zeroes out the ring buffer pointers (rx and tx -- likely the entire dev->priv block and more) and then setup_tx_ring gets understandably upset. =)

Quoted 5 lines

Anyway, I'm not enough of a MIPS guru to really say much more, but I'll poke around tonight and see if I can stumble across anything useful.

Linux reports:
MIPS 4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE

There is a bug in the l2 flushing for theSC/MC versions, it uses the wrong cacheops. I've fixed it in my home tree.

Ralf