From owner-freebsd-current Mon Jan 20 23:33:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA04312 for current-outgoing; Mon, 20 Jan 1997 23:33:35 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA04307 for ; Mon, 20 Jan 1997 23:33:32 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.8.4/8.8.4) id RAA08177 for freebsd-current@freebsd.org; Tue, 21 Jan 1997 17:33:29 +1000 Received: by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) id RAA09694; Tue, 21 Jan 1997 17:26:09 +1000 (EST) Date: Tue, 21 Jan 1997 17:26:09 +1000 (EST) From: Stephen McKay Message-Id: <199701210726.RAA09694@ogre.devetir.qld.gov.au> To: freebsd-current@freebsd.org cc: syssgm@devetir.qld.gov.au Subject: Re: VM bogon? Was: Re: NIS breakage Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Murray wrote: >Peter Wemm wrote: >> 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. > >This is happening on an AMD386sx/40. :-( The problem with vi printing something like 'select: Bad address' has been around for ages. My 386sx16 high-page-rate test box printed this for almost every keystroke. This was the case around November last year (and for months previous to this). Sadly, I cannot verify -current behaviour, as the box has not been reconstructed after the last panic -> fs corruption disaster. Too much "real" work. :-( I did not track it down, but assume it has to do with almost all of the process being absent from main memory when the select condition is triggered, and thus, the page(s) containing the fd_sets being absent. It may also be related to the lack of kernel write protection on the 386 not causing page-in of the affected page. Hmm. I've just been looking at copyout(). If the target pages are not present, then their page table page might not be present either. In this case, won't the attempt to check the target pages' writability cause a fault? This fault would then be translated to EFAULT (Bad address) by copyout_fault. It looks like there should be an extra check for the existence of page table page(s) or the fault redirection stuff should be done after the 386 check. Stephen.