<apologies for the lag, please include me on replies so a copy hits 
my main INBOX - Reply-To set accordingly>

On Tue, 23 May 2006, Izumi Tsutsui wrote:

>> Further datapoint: This only appears to happen if you try reboot 
>> from a netbooted kernel (userspace on local disk).
>
> Is it 100% reproducible?

Strangely enough, no.

> It *sometimes* happened even with kernels booted from sd0
> on my R5K IP32.

Hmm, odd. It's a bit annoying when it happens, have to go hunt for a 
paper clip to stick in the hard-reset pin-hole. :( Presumably some 
kind of PROM interaction?

> It's current NetBSD/mips spec, which assumes all physical RAM can 
> be accessed via KSEG0. On IP32, RAM higher than 256MB is located at 
> 0x20000000 or 0x40000000 so it can't be handled by the current 
> kernel, and someone has to rewrite mips pmap to fix it.

So not anytime soon then. I'll gladly test any proposed patches, if 
someone /were/ to try. (700MB IP32 box).

> Maybe it's R10k issue caused by SGI's (silly) hardware design,
> but not easy to fix, I guess.

It's actually up 2 days now, the longest so far:

$ uptime
  3:17PM  up 2 days, 12:01, 3 users, load averages: 0.15, 0.14, 0.09

But mostly cause I've not done anything too stressful with it the 
last few days. Even idle, it's prone to rebooting at 4am-ish if cron 
jobs add a bit of load.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
We cannot do everything at once, but we can do something at once.
 		-- Calvin Coolidge