Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Jan 1997 09:28:25 +0800
From:      Peter Wemm <peter@spinner.DIALix.COM>
To:        Bill Paul <wpaul@freefall.freebsd.org>
Cc:        mark@grondar.za (Mark Murray), current@freebsd.org, peter@freebsd.org, dyson@freebsd.org
Subject:   VM bogon? Was: Re: NIS breakage 
Message-ID:  <199701200128.JAA21134@spinner.DIALix.COM>
In-Reply-To: Your message of "Sun, 19 Jan 1997 09:12:44 PST." <199701191712.JAA09406@freefall.freebsd.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul wrote:
[..]
> > At times, it is difficult to get sendmail to answer (only difficult, not
> > impossible like before - it just takes a LOOONG time).
> > It also logs these:
> > Jan 19 17:25:27 grunt sendmail[166]: NOQUEUE: SYSERR(root): getrequests: ac
    cept: Bad address
> > 
> > NIS is _horribly_ fragile - If I change passwords, the following happens
> > (logged to syslog):
> > 
> > Jan 19 16:57:28 grunt portmap[161]: svc_run: - select failed: Bad address
> > Jan 19 16:57:28 grunt portmap[161]: svc_run returned unexpectedly
> > Jan 19 16:57:28 grunt /kernel: pid 161 (portmap), uid 1: exited on signal 6

[..]

This is looking like a manifestation of a VM system problem.. :-(  We've
had a few PR's now where people report that 'vi crashes after being left
idle for 5 minutes', and so on.  It all seems to be with select() or read()
etc specifying *valid* addresses that work on one time arount a loop with
ktrace, and a short while later get an EFAULT on a perfectly valid address.
Having accept() fail with an EFAULT is a new one that I've not seen 
before.  In this case, the two variables being copyout()'ed are on the 
stack.    John????

BTW, are these failure cases happening on P5 or P6's?  Perhaps the
fpu-based "fast" P5 copyin/copyout are to blame here?  Mark, if you are
seeing this on a P5 machine and can reproduce this easily, try looking up
the option for NPX_DISABLE_I586_OPTIMIZED_COPYIO in npx.c and see if you
can figure out how to configure npx's flags to disable this floating point.
 I think it's "device npx0 ..... flags 4"  or something like that.  Perhaps
"flags 7" might be best to eliminate the possibility. 

Cheers,
-Peter





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701200128.JAA21134>