In article <33B47346-9A53-462D-9719-D4E39F13AFFD@gmail.com>
thierry.rangeard@gmail.com wrote:

> I tried nothing special, it was during a scp transfert with a large  
> 100MB file. As you could see in the stack trace the stopped process  
> was ssh.

Yes, it could happen during large network xfers.

> Trap: TLB miss (load.inst.fetch) in Kernelmode status=0x2403,
> cause=0x8, epc=0x810cfde0, vaddr=0xcc708000 pid 911
> cmd=sshd usp=ox7fffd4f0 Ksp=0xcc6ebb08
> stopped in pid 911.1 (ssh) at kernel:r5k_pdcache_wb_range_32+0x9c:  
> cache 0x19, 0x3c0(a0)

This is in cobalt/cobalt/bus.c:_bus_dmamap_sync().
When I replaced this mips_dcache_wb_range() with
mips_dcache_wbinv_range() the panic still happened,
so it seems that wrong VA passed from bus_dmamap_sync()
on BUS_DMASYNC_PREWRITE (i.e. TX of tlp(4)) causes
the problem, but I can't see why it happens only on
TX, not RX (i.e. BUS_DMASYNC_PREREAD).

On the other hand, I can't reproduce this problem
on R5000 O2, so I wonder if it's Rm52xx specific or
tlp(4) specific.

Could anyone try if the similar panic could happen
with other NIC on a PCI slot of Qube2?

> Is there a sysctl parameter that I can use ?

The attached patch could hide a panic (as workaround),
but maybe I (or someone) should check Rm52xx manual more closely.
(I'm afraid there are some more Rm52xx specific CP0 hazards
 not handled currently)
---
Index: arch/cobalt/cobalt/bus.c
===================================================================
RCS file: /cvsroot/src/sys/arch/cobalt/cobalt/bus.c,v
retrieving revision 1.24
diff -u -r1.24 bus.c
--- arch/cobalt/cobalt/bus.c	1 Mar 2006 12:38:11 -0000	1.24
+++ arch/cobalt/cobalt/bus.c	17 Mar 2006 17:40:58 -0000
@@ -621,7 +621,11 @@
 			break;
 
 		case BUS_DMASYNC_PREWRITE:
+#if 0	/* XXX */
 			mips_dcache_wb_range(addr + offset, minlen);
+#else
+			mips_dcache_wbinv_range_index(addr + offset, minlen);
+#endif
 			break;
 		}
 #ifdef BUS_DMA_DEBUG

---
Izumi Tsutsui