Subject: Re: 2.0_RC4 and -current instability,
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
List: port-mips
Date: 11/04/2004 19:38:38
>>>>> "Manuel" == Manuel Bouyer <bouyer@antioche.eu.org> writes:

    Manuel> Could be a cache sync issue. What CPU is there in this box
    Manuel> ? Also what devices do you use for disk and network I/O ?

    >> cpu0 at mainbus0: QED RM5200 CPU (0x28a0) Rev. 10.0 with built-in FPU Rev. 10.0
    >> cpu0: 32KB/32B 2-way set-associative L1 Instruction cache, 48 TLB entries
    >> cpu0: 32KB/32B 2-way set-associative write-back L1 Data cache

    Manuel> 32B lines, this matchs what you've reported.

Does this help (anybody) to understand what's going wrong here then?

    >> 'tlp0' and 'viaide0' are all onboard devices.

    Manuel> tlp0 should have bus_dma related bugs, as it's known to
    Manuel> work on alpha, sparc64, and others hardware where
    Manuel> bus_dma_sync() isn't a NOP.

That means the tlp driver is buggy in cobalt mips machines?

Beside performance issues pure tlp traffic (e. g. routing) doesn't
seem to be problematic (but I didn't test this explicitly)...

Within my testings once I've put in a 3com 3c905b nic which was
detected und configured properly (ex0), but the performance was so bad
(20-30 kB/sec) that I gave it up.

    Manuel> viaide doesn't use custom DMA callbacks, so it should be
    Manuel> safe too.

('safe too'!? Thougth, tlp is not save, see above)
But here I see the main problem... strange!

Markus.