Hi Mark,

took some time, but you've got a reply!

On Wed, 2 Jun 1999, Mark Brinicombe wrote:
> On Wed, 2 Jun 1999, Reinoud Zandijk wrote:
> > ahum... I just had a UVM memory fault... and the kernel couldn't
> > continue...
> 
> Oh dear these are never good. Normally this should drop you to a db>
> prompt (the in-kernel debugger). If so one thing that is always useful is
> to use the trace command command. This should list the kernel stack trace
> back and indicate which function the fault occurred in.

hmmm. maybe I tried, but am not sure now... if I did I would surely made a
note of it... but I can't find it.

> > The circumstances were :
> >   - running NetBSD 1.4 release + your rpc_machdep.c
> >   - having run Xvidc unsuccesfully with fvwm
> >   - compiling fvwm1 :-(
> 
> Was that the 1.4 kernel sources with my rpc_machdep.c or -current kernel
> sources ? 

Well, it was the release source with your rpc_machdep.c. I've reported two
other bug-reports (ea0 not working in -current and a complete machine
freeze when running smbclient) , and discussed some minor bugs/`features'
in a mailing to the mailing-list, but haven't converted them into
bug-reports yet. See my postings / bugreports for details!

> > well, the compilation process just died and the kernel went into the
> > debugger. As far as I can see, it was the getty.. I got a getty.core in my
> > /. I'll include it, maybe you can see something in it. Also syslogd and
> > update were coredumped; maybe because during the core-dumping, I got
> > segmentation faults too :-((
> 
> This does not sound good at all... I have seen syslog core dump before and
> parhaps getty may under strange terminal realted problems but I update is
> one binary I would not expect to core dump or SEGV since this is a very
> simple program that just calls the sync() system call every so often.
> Wondering if this is a problem related to the runtime linker and dynamic
> binaries.

Could be... I noticed an other bug-reports mention sudden freezes.... 
could have the same source. 

> > the Xvidc didn't run from scratch... I had to chmod it first :-), then
> > rerun the `ldconfig -c' for the ld.so 's .... now it is complaining about
> > the mouse... I'm not using wscons as far as I know (is it posible anyway 
> > ?)
> 
> opps forgot that in my instructions. the execute permissions get lost in
> the ftp and it needs to run as root so may needs the setuid bit set
> depending on how it gets launched.
> 
> What is the mouse error ? The riscpc does not use the wscons (though it
> will in the future when I implement the machine specific code wscons
> needs).

Well, the mouse problem was the inability to read from /dev/mouse. I had
to change the access rights with `chmod a+r /dev/mouse'. When do you plan
for the completion of wscons? Will it be a significant change? Will Xvidc
benefit from it? Will Xvidc share keyboard, mouse and videomode info with
the kernel? I surely hope so! then there'll be at last no double
configurations needed!

BTW, no bug-report yet, but noticed it last night : XV works OK with Xvidc
rel. 1 (the second one), but suffers from redraw-problems when showing
jpegs in a window; everything goes OK when showing the same picture at
Xroot. You can erase parts with another window, and then (sometimes, yuck
:-( ) it tries to redraw parts; only small trokes are actually drawn.
Maybe I can get a screenshot for you.

Cheers,

Reinoud