Rafal Boni wrote:

> Interestingly, if I attach gdb to the csh process and set a breakpoint
> at __vfork14, I hit the breakpoint in gdb and when I continue get the
> output I expected.  Makes me almost wonder if this isn't somehow related
> to the runtime linker or maybe zorched relocs in libc.  Or maybe some
> key bit of code *is* actually missing a cache flush and the stop in
> gdb takes care of it.  I'm still not sure if it actually means or points
> to anything specific, but it was odd enough that it was worth reporting.

This seems reasonably likely.  I haven't had much time to look at this,
but I tried an up-to-date 2.0 branch on both sbmips (on a rhone) and
evbmips (on an Alchemy Pb1500).  The rhone gets:

	login: root
	[ ... ]

	Welcome to NetBSD!

	pid 241 (csh), uid 0: exited on signal 11 (core dumped)
	Badly placed ()'s.
	rhone# 

but the Pb1500 works fine and hasn't had a process die or a panic yet
and I've built a few packages and had a general play around on it.

Now, the Alchemy CPUs are the only MIPS CPUs NetBSD currently supports
that have a fully coherent cache - even the instruction cache snoops the
data cache so both the I$ and the D$ never need flushing.

I can't recall any recent changes to the cache code, and I'm also not
sure why -current works any better...

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