From owner-freebsd-current Sun Apr 20 09:51:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA00657 for current-outgoing; Sun, 20 Apr 1997 09:51:49 -0700 (PDT) Received: from rosie.scsn.net (scsn.net [206.25.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA00650 for ; Sun, 20 Apr 1997 09:51:46 -0700 (PDT) Received: from cola110.scsn.net ([206.25.247.110]) by rosie.scsn.net (Post.Office MTA v3.0 release 117 ID# 0-32322U5000L100S10000) with ESMTP id AAA160 for ; Sun, 20 Apr 1997 12:46:15 -0400 Received: (from root@localhost) by cola110.scsn.net (8.8.5/8.6.12) id MAA00438 for current@FreeBSD.org; Mon, 21 Apr 1997 12:53:21 -0400 (EDT) From: "Donald J. Maddox" Message-Id: <199704211653.MAA00438@cola110.scsn.net> Subject: Panics in kern_lock.c:lockstatus To: current@FreeBSD.org Date: Mon, 21 Apr 1997 12:53:20 -0400 (EDT) Reply-To: dmaddox@scsn.net X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have been getting panics that look like the following fairly consistently of late: ------------------------------------------------------------------ Fatal trap 12: page fault while in kernel mode fault virtual address = 0x44 fault code = supervisor read, page not present instruction pointer = 0x8:0xf010e020 stack pointer = 0x10:0xf3dddf0c frame pointer = 0x10:0xf3dddf0c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 326 (reboot) interrupt mask = kernel: type 12 trap, cod=0 Stopped at _lockstatus+0x8: cmpw $0,0x10(%edx) db> -------------------------------------------------------------------- I haven't yet found a way to reproduce it with 100% reliability, but the following often works: 1) Start something that does a lot of disk access, like # cd /usr/src # make clean cleandir cleandepend 2) In another shell, issue the the command: `ps -ax | grep make` repeatedly in quick succession. Sometimes it takes 20 or more repetitions to work, but eventually it will just hang, and any subsequent invocations of ps will _always_ hang. Top, however, will still work, and shows the shell that started the original ps command in the 'thrd_s' state. All the subsequent invocations of ps will show either 'thrd_s' or 'pfslck' state. 3) After this, eventually the panic will occur. The example above occured while rebooting with 'shutdown -r now', but this does not always cause a panic. ------------------------------------------------------------------- All of the above was done from xterms, using tcsh as the shell, running as root. The system is -current as of about 2 am this morning, but I have been seeing this panic sporadically ever since the lite2 merge. -- Donald J. Maddox (dmaddox@scsn.net)