From owner-freebsd-current Mon Jan 13 03:39:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA07405 for current-outgoing; Mon, 13 Jan 1997 03:39:32 -0800 (PST) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA07400 for ; Mon, 13 Jan 1997 03:39:28 -0800 (PST) Received: (from adam@localhost) by veda.is (8.8.4/8.7.3) id LAA05006 for freebsd-current@freebsd.org; Mon, 13 Jan 1997 11:47:30 GMT From: Adam David Message-Id: <199701131147.LAA05006@veda.is> Subject: sigs 10,11 (and other hiccups) To: freebsd-current@freebsd.org Date: Mon, 13 Jan 1997 11:47:29 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Once in awhile lately, I've been seeing spates of bus errors and segment violations. Typically, many processes get hit at around the same time and any new process started will immediatetly segv. After some time passing and unaffected processes have continued to run, the situation clears up by itself and things appear normal again. This has been for several months, but seems to have become more frequent recently, under similar typical loads. Other strange effects these days are when programs fail with errors such as: /some/path/Ì: no such file or directory /dev/: no such file or directory /dev/~adam: no such file or directory This has also been this way for several months, tracking current, but seems to have reduced to very infrequent during past weeks. The machine has 16 MB physical RAM and has /usr mounted from NFS. These problems are unrelated to binaries being moved on the NFS server. Also probably unrelated, I have noticed that gdb often reloads binaries and symbols when restarting programs (either on the server or client side of NFS), although the files have not changed. Yet another irregularity (I have only seen this on the NFS client machine so far)... cvs update -dP sometimes fails with stuff like: cvs update: in directory gnu/usr.bin/groff/mm/mm: cvs [update aborted]: *PANIC* administration files missing I have only seen this happen to directories which have been completely removed to the Attic, cvs update has previously skipped the directory several times without complaining and then this. Removing the directory allows the next cvs update to complete normally, but shouldn't -P have already removed it on a previous run? -- Adam David