[ CC'd to port-mips as well ]

Markus W Kilbinger wrote:

> >>>>> "Izumi" == Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:
> 
> First: Thanks for all infos!
> 
>     Izumi> Well, AFAIK the problem on cobalt PCI implementation
>     Izumi> affects memory mapped PCI devices (like siop), so I'm not
>     Izumi> sure if it fixes your "data corruption" problem. (patch
>     Izumi> attached, including MI changes filed in kern/27423)
> 
> No, the data corruption problem remains, but my qube2 became much more
> stable with your pci related patches! Beside the data corruption
> problems now I 'only' see panics under heavy load of the following
> kind:
> 
>   trap: TLB miss (load or instr. fetch) in kernel mode
>   status=0x2403, cause=0x8808, epc=0x80229214, vaddr=0xc874e000
>   pid=196 cmd=ttcp usp=0x7fffda10 ksp=0xc8749b08
>   Stopped in pid 196.1 (ttcp) at  netbsd:r5k_pdcache_wb_range_32+0x58: cache   0
>   x19,0x1a0(a0)
>   db> t
>   r5k_pdcache_wb_range_32+58 (c874de60,c874e3e0,5ea,5ea) ra 8022e468 sz 0
>   8022e3d8+90 (c874de60,c874e3e0,5ea,5ea) ra 0 sz 0
>   User-level: pid 196.1
>   db>

I'm a little rusty on cache ops...

The vaddr shows this is the first cache op after a page boundary.  We
have no TLB entry for that page and because this is a hit op we take an
exception.  EXL is set in cp0 status, so we're not going to use the TLB
miss exception handler but come through the general exception handler
and that's when we panic.

I wonder why the trace is truncated (I'm guessing that the call to
mips_dcache_wb_range() is the BUS_DMASYNC_PREWRITE bus_dmamap_sync()
call in tlp_start()), and also if cp0 status.EXL should be clear at
this stage?

I'll have a think about this later on, but just wanted to get some
random mumblings out now.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/