Subject: Re: 2.0_RC4 and -current instability, data corruption and system
To: None <port-cobalt@NetBSD.org>
From: Lists - Kush-T <lists@kush-t.co.uk>
List: port-cobalt
Date: 11/05/2004 00:27:28
On Thu, 2004-11-04 at 18:55, Markus W Kilbinger wrote:
> >>>>> "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?
>
> Manuel> Probably a bug in the cache management routines, but I
> Manuel> can't tell more. I'm not familiar with this part of code.
>
> Maybe somebody else within these lists can help here?
>
> 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?
>
> Manuel> No, sorry, there is a missing "no" here. As far as I know,
> Manuel> the tlp driver should be fine.
>
> Ah, ok (at least some kind of de-confusion for me ;-)).
>
> Thanks for your comments!
>
> Markus.
>
I'm sure there's something about this problem in the gentoo port:
http://www.spinics.net/lists/mips/msg15066.html
I'll post again when I find the proper details...
pete