>>>>> "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>

No silent lockups as before (til now)...

    Izumi> On the other hand, there is a patch for MIPS r5k cache:
    Izumi> http://mail-index.netbsd.org/port-sgimips/2003/01/06/0001.html

Seems to be already almost in -current...

And http://mail-index.netbsd.org/port-mips/2003/04/27/0000.html does
also not prevent these panics and te data corruption.

    Izumi> Anyway, I also have a NetBSD/arc machine (R4400) running
    Izumi> 2.0G as file server and it has no data corruption for 2
    Izumi> months, so I don't think there is MIPS _common_ VM issue,
    Izumi> but I also see some problem reports on r5k O2. (I wonder if
    Izumi> current mips pmap handles 2-way set associative
    Izumi>  cache on r5k CPUs)

So, if I've read the lists correctly there _is_ some r5k related
cache/pmap problem left which causes similar problems on sgimips...

Is anybody working on that?

Thanks again,

Markus.