Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Apr 2001 00:36:31 +0100 (BST)
From:      Andrew Gordon <arg@arg1.demon.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:  <Pine.BSF.4.21.0104020008080.9790-100000@server.arg.sj.co.uk>

next in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104020008080.9790-100000>