From owner-freebsd-stable Sun Apr 1 16:36:38 2001 Delivered-To: freebsd-stable@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 975DB37B718 for ; Sun, 1 Apr 2001 16:36:33 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: by arg1.demon.co.uk (Postfix, from userid 300) id 123259B14; Mon, 2 Apr 2001 00:36:32 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 09D8C5D12; Mon, 2 Apr 2001 00:36:32 +0100 (BST) Date: Mon, 2 Apr 2001 00:36:31 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: freebsd-stable@freebsd.org Cc: grog@lemis.com Subject: 4.3-RC processes stuck sleeping on "inode" (?vinum) problem update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Further to my previous report: - This is definitely a problem in 4.3RC: I rolled back to 31st Jan sources (world & kernel), and the system has now been up for 36 hours (as opposed to at most 6 hours running 4.3RC). - New evidence makes me lean towards thinking that Vinum is responsible (though this is by no means conclusive): 1. I had previously only had my nfsd processes getting stuck (plus the 'reboot' process itself if I tried to reboot), however, while doing a 'cvs checkout' onto the vinum filesystem to build my jan31 world, the cvs process got stuck in "inode" too. 2. That same cvs checkout completed OK on a non-vinum filesystem. 3. I have just noticed in my console logs, that in the "ps" output showing the nfsd processes stuck in "inode", the "(syncer)" process is stuck in "vrlock" which is a vinum wait channel. Report proforma from http://www.vinumvm.org/vinum/how-to-debug.html ** What problems are you having? Processes stuck sleeping on "inode" - usually the "nfsd" process as this box's primary work is as a fileserver. ** Which version of FreeBSD are you running? 4.x-STABLE. Version from 24 March shows the problem, 31st January does not. ** Have you made any changes to the system sources, including Vinum? isdn4bsd sources in this build tree have been updated to -CURRENT, but the machine showing the bug does not have isdn in the kernel (nor any ISDN hardware). ** Supply the output of the vinum list command. serv20(root)# vinum list 5 drives: D drive0 State: up Device /dev/da0s1aAvail: 0/17500 MB (0%) D drive1 State: up Device /dev/da1s1a Avail: 0/17500 MB (0%) D drive2 State: up Device /dev/da2s1a Avail: 0/17500 MB (0%) D drive3 State: up Device /dev/da3s1a Avail: 0/17500 MB (0%) D drive4 State: up Device /dev/da4s1a Avail: 0/17500 MB (0%) 1 volumes: V home State: up Plexes: 1 Size: 68 GB 1 plexes: P home.p0 R5 State: up Subdisks: 5 Size: 68 GB 5 subdisks: S home.p0.s0 State: up PO: 0 B Size: 17 GB S home.p0.s1 State: up PO: 512 kB Size: 17 GB S home.p0.s2 State: up PO: 1024 kB Size: 17 GB S home.p0.s3 State: up PO: 1536 kB Size: 17 GB S home.p0.s4 State: up PO: 2048 kB Size: 17 GB ** Supply an extract of the Vinum history file. 29 Mar 2001 21:16:16.489308 quit 29 Mar 2001 21:31:05.467472 *** vinum started *** 29 Mar 2001 21:31:05.473094 start 29 Mar 2001 21:31:07.982066 *** Created devices *** 30 Mar 2001 09:30:57.334342 *** vinum started *** 30 Mar 2001 09:30:57.350901 start 30 Mar 2001 09:30:59.852519 *** Created devices *** 30 Mar 2001 10:31:39.452862 *** vinum started *** 30 Mar 2001 10:31:39.458490 start 30 Mar 2001 10:31:41.937394 *** Created devices *** 2 Apr 2001 00:27:33.416553 *** vinum started *** 2 Apr 2001 00:27:40.083946 *** vinum started *** [Note: no vinum admin was done in the period. Logging doesn't seem to be very consistent: whether or not you get "vinum started" in the log on reboot seems to depend on whether you needed to go to single-user for manual fsck]. ** Supply an extract of the file /var/log/messages. There really isn't anything interesting in /var/log/messages: just normal boot-up dmesg output, plus the odd: Mar 30 10:31:54 serv20 /kernel: WARNING: / was not properly dismounted ** If you have a crash, please supply a backtrace from the dump No crash - the system normally remains fully operational when the problem occurs, apart from a few processes stuck sleeping on "inode". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message