[ On Monday, June 16, 2003 at 19:20:15 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: First Boot fails!
>
> On Mon, Jun 16, 2003 at 12:05:09PM +0900, henry nelson wrote:
> > On Mon, Jun 16, 2003 at 02:29:54AM +0900, Izumi Tsutsui wrote:
> > > But anyway sun4c machines with sw flush cache (SS1, SS1+ and IPC)
> > > have another problem which causes ramdom segfaults (port-sparc/14180).
> > 
> > Please confirm (or not) that 1.5.3 is "safe" with regard to sw flush cache
> > problem on IPC, etc.
> 
> Yes, it is. Well, the bug could be there too, but we've never been able to
> make it show up before UBC integration.

Older systems appear to be more stable, but I can confirm they are not
100% stable.  Since my SS2 died and I've been running my old 1.3.2
system on an SS1+ I've observed many more program crashes than were
happening on the SS2 -- and those that successfully dump core always
have very trashed stacks, just as the Xserver was exhibiting when I ran
it on an SS1 (but no longer exhibits when running on an SS20).

The cache bugs are simply tickled _far_ more often after UBC
integration, but as far as I can tell they've always been lurking there
and occasionally do happen on older NetBSD releases as well,
particularly to large processes that use a lot of CPU and which also
context switch a lot (such as Xserver).

They may even be there for SunOS -- i.e. they may be hardware bugs that
even SunOS has not successfully worked around, but rather has simply
avoided for the most part just as early NetBSD releases have avoided
them.  However it's been a rather long time though since I ran SunOS on
any such sparc system.  :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>