NetBSD Problem Report #53990

From www@NetBSD.org  Mon Feb 18 07:14:13 2019
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 26DE07A154
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 18 Feb 2019 07:14:13 +0000 (UTC)
Message-Id: <20190218071412.6B9537A1DF@mollari.NetBSD.org>
Date: Mon, 18 Feb 2019 07:14:12 +0000 (UTC)
From: jaypatelani@gmail.com
Reply-To: jaypatelani@gmail.com
To: gnats-bugs@NetBSD.org
Subject: NetBSD 8.0 AMD64 panic ffs_newvnode
X-Send-Pr-Version: www-1.0

>Number:         53990
>Category:       port-amd64
>Synopsis:       NetBSD 8.0 AMD64 panic ffs_newvnode
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 18 07:15:00 +0000 2019
>Last-Modified:  Wed May 29 16:00:03 +0000 2019
>Originator:     Jay
>Release:        8.0
>Organization:
www.Unitedbsd.com
>Environment:
NetBSD os108 8.0 NetBSD 8.0 (GENERIC)#0 The Jul 17 mkrepro@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 
>Description:
Hello, 

Was doing Cvs checkout xsrc for netbsd-8 and connection was interrupted then I did remove xsrc dir and again tried to fetch source since then I got this error : http://imgur.com/gallery/qYrhAN3


>How-To-Repeat:

>Fix:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode
Date: Mon, 18 Feb 2019 08:29:19 +0100

 Please boot single user and force a file system check of the affected
 file system. This usually is a sign of earlier corruption.

 Martin

From: Jay Patel <jaypatel.ani@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode
Date: Mon, 18 Feb 2019 13:13:06 +0530

 --0000000000003ba8aa0582264712
 Content-Type: text/plain; charset="UTF-8"

 File system force check in single user mode :
 http://imgur.com/gallery/LqEykmq

 Regards,
 Jay

 On Mon, Feb 18, 2019, 1:00 PM Martin Husemann <martin@duskware.de wrote:

 > The following reply was made to PR port-amd64/53990; it has been noted by
 > GNATS.
 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode
 > Date: Mon, 18 Feb 2019 08:29:19 +0100
 >
 >  Please boot single user and force a file system check of the affected
 >  file system. This usually is a sign of earlier corruption.
 >
 >  Martin
 >
 >

 --0000000000003ba8aa0582264712
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"auto"><div>File system force check in single user mode :=C2=A0<=
 /div><div dir=3D"auto"><a href=3D"http://imgur.com/gallery/LqEykmq">http://=
 imgur.com/gallery/LqEykmq</a></div><div dir=3D"auto"><br></div><div dir=3D"=
 auto">Regards,=C2=A0</div><div dir=3D"auto">Jay<br><br><div class=3D"gmail_=
 quote" dir=3D"auto"><div dir=3D"ltr">On Mon, Feb 18, 2019, 1:00 PM Martin H=
 usemann &lt;<a href=3D"mailto:martin@duskware.de">martin@duskware.de</a> wr=
 ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
 border-left:1px #ccc solid;padding-left:1ex">The following reply was made t=
 o PR port-amd64/53990; it has been noted by GNATS.<br>
 <br>
 From: Martin Husemann &lt;<a href=3D"mailto:martin@duskware.de" target=3D"_=
 blank" rel=3D"noreferrer">martin@duskware.de</a>&gt;<br>
 To: gnats-bugs@NetBSD.org<br>
 Cc: <br>
 Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode<br>
 Date: Mon, 18 Feb 2019 08:29:19 +0100<br>
 <br>
 =C2=A0Please boot single user and force a file system check of the affected=
 <br>
 =C2=A0file system. This usually is a sign of earlier corruption.<br>
 <br>
 =C2=A0Martin<br>
 <br>
 </blockquote></div></div></div>

 --0000000000003ba8aa0582264712--

From: Jay Patel <jaypatel.ani@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode
Date: Mon, 18 Feb 2019 21:13:07 +0530

 --000000000000e95ad605822cfb13
 Content-Type: text/plain; charset="UTF-8"

 Hello,

 I did fsck -f single mode. booted NetBSD then "cvs update -dP xsrc" but it
 again throws same error. and at reboot generated two savecore files. here
 are links of those uploaded files :
 1. https://transfer.sh/xbS0k/netbsd.2.gz
 2. https://transfer.sh/KTIGg/netbsd.2.core.gz


 and crash output :

 sudo crash -M netbsd.2.core -N /netbsd
 Password:
 Crash version 8.0, image version 8.0.
 System panicked: ffs_newvnode: dup alloc ino=24113408 on /: mode 81a4/81a4
 gen 3718e969/3718e969 size 260 blocks 8
 Backtrace from time of crash is available.
 crash> bt
 _KERNEL_OPT_NVGA_RASTERCONSOLE() at 0
 ?() at fffffe812dd449c0
 vpanic() at vpanic+0x166
 snprintf() at snprintf
 ffs_newvnode() at ffs_newvnode+0x530
 vcache_new() at vcache_new+0x95
 ufs_makeinode() at ufs_makeinode+0x38
 ufs_create() at ufs_create+0x31
 VOP_CREATE() at VOP_CREATE+0x51
 vn_open() at vn_open+0x323
 do_open() at do_open+0x112
 do_sys_openat() at do_sys_openat+0x68
 sys_open() at sys_open+0x24
 syscall() at syscall+0x1ec
 --- syscall (number 5) ---
 7d48dd63e2ca:

 Regards,
 Jay


 On Mon, Feb 18, 2019 at 1:00 PM Martin Husemann <martin@duskware.de> wrote:

 > The following reply was made to PR port-amd64/53990; it has been noted by
 > GNATS.
 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode
 > Date: Mon, 18 Feb 2019 08:29:19 +0100
 >
 >  Please boot single user and force a file system check of the affected
 >  file system. This usually is a sign of earlier corruption.
 >
 >  Martin
 >
 >

 -- 
 Jay Patel
 *https://unitedbsd.com/ <https://unitedbsd.com/>*


 *usually found @ https://riot.im/app/#/room/#bsd:matrix.org
 <https://riot.im/app/#/room/%23bsd:matrix.org>*

 --000000000000e95ad605822cfb13
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
 ir=3D"ltr"><div>Hello,<br><br></div>I did fsck -f single mode. booted NetBS=
 D then &quot;cvs update -dP xsrc&quot; but it again throws same error. and =
 at reboot generated two savecore files. here are links of those uploaded fi=
 les : <br>1. <a href=3D"https://transfer.sh/xbS0k/netbsd.2.gz" target=3D"_b=
 lank" rel=3D"noreferrer">https://transfer.sh/xbS0k/netbsd.2.gz</a><br>2. <a=
  href=3D"https://transfer.sh/KTIGg/netbsd.2.core.gz">https://transfer.sh/KT=
 IGg/netbsd.2.core.gz</a></div><div dir=3D"ltr"><br><br></div><div>and crash=
  output :<br><br><div class=3D"m_-2230655819188950121gmail-de1">sudo crash =
 -M netbsd.2.core -N /netbsd</div>
 <div class=3D"m_-2230655819188950121gmail-de1">Password: </div>
 <div class=3D"m_-2230655819188950121gmail-de1">Crash version 8.0, image ver=
 sion 8.0.</div>
 <div class=3D"m_-2230655819188950121gmail-de1">System panicked: ffs_newvnod=
 e: dup alloc ino=3D24113408 on /: mode 81a4/81a4 gen 3718e969/3718e969 size=
  260 blocks 8</div>
 <div class=3D"m_-2230655819188950121gmail-de2">Backtrace from time of crash=
  is available.</div>
 <div class=3D"m_-2230655819188950121gmail-de1">crash&gt; bt</div>
 <div class=3D"m_-2230655819188950121gmail-de1">_KERNEL_OPT_NVGA_RASTERCONSO=
 LE() at 0</div>
 <div class=3D"m_-2230655819188950121gmail-de1">?() at fffffe812dd449c0</div=
 >
 <div class=3D"m_-2230655819188950121gmail-de1">vpanic() at vpanic+0x166</di=
 v>
 <div class=3D"m_-2230655819188950121gmail-de2">snprintf() at snprintf</div>
 <div class=3D"m_-2230655819188950121gmail-de1">ffs_newvnode() at ffs_newvno=
 de+0x530</div>
 <div class=3D"m_-2230655819188950121gmail-de1">vcache_new() at vcache_new+0=
 x95</div>
 <div class=3D"m_-2230655819188950121gmail-de1">ufs_makeinode() at ufs_makei=
 node+0x38</div>
 <div class=3D"m_-2230655819188950121gmail-de1">ufs_create() at ufs_create+0=
 x31</div>
 <div class=3D"m_-2230655819188950121gmail-de2">VOP_CREATE() at VOP_CREATE+0=
 x51</div>
 <div class=3D"m_-2230655819188950121gmail-de1">vn_open() at vn_open+0x323</=
 div>
 <div class=3D"m_-2230655819188950121gmail-de1">do_open() at do_open+0x112</=
 div>
 <div class=3D"m_-2230655819188950121gmail-de1">do_sys_openat() at do_sys_op=
 enat+0x68</div>
 <div class=3D"m_-2230655819188950121gmail-de1">sys_open() at sys_open+0x24<=
 /div>
 <div class=3D"m_-2230655819188950121gmail-de2">syscall() at syscall+0x1ec</=
 div>
 <div class=3D"m_-2230655819188950121gmail-de1">--- syscall (number 5) ---</=
 div>
 7d48dd63e2ca:<br><br></div><div>Regards,<br></div><div>Jay<br></div><div di=
 r=3D"ltr"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
 lass=3D"gmail_attr">On Mon, Feb 18, 2019 at 1:00 PM Martin Husemann &lt;<a =
 href=3D"mailto:martin@duskware.de" target=3D"_blank" rel=3D"noreferrer">mar=
 tin@duskware.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
 tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
 ding-left:1ex">The following reply was made to PR port-amd64/53990; it has =
 been noted by GNATS.<br>
 <br>
 From: Martin Husemann &lt;<a href=3D"mailto:martin@duskware.de" target=3D"_=
 blank" rel=3D"noreferrer">martin@duskware.de</a>&gt;<br>
 To: gnats-bugs@NetBSD.org<br>
 Cc: <br>
 Subject: Re: port-amd64/53990: NetBSD 8.0 AMD64 panic ffs_newvnode<br>
 Date: Mon, 18 Feb 2019 08:29:19 +0100<br>
 <br>
 =C2=A0Please boot single user and force a file system check of the affected=
 <br>
 =C2=A0file system. This usually is a sign of earlier corruption.<br>
 <br>
 =C2=A0Martin<br>
 <br>
 </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"m=
 _-2230655819188950121gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr=
 "><div><div dir=3D"ltr">Jay Patel</div><div dir=3D"ltr"><a href=3D"https=
 ://unitedbsd.com/" target=3D"_blank" rel=3D"noreferrer">https://unitedbsd.c=
 om/</a></div><div>usually found @ <a href=3D"https://riot.im/app/#/r=
 oom/%23bsd:matrix.org" target=3D"_blank" rel=3D"noreferrer">https://riot.im=
 /app/#/room/#bsd:matrix.org</a><br><br></div><div dir=3D"ltr"><br><br><=
 br></div></div></div></div></div></div></div></div></div>

 --000000000000e95ad605822cfb13--

From: "Frank Kardel" <kardel@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53990 CVS commit: src/sys/ufs/ffs
Date: Sun, 14 Apr 2019 15:55:24 +0000

 Module Name:	src
 Committed By:	kardel
 Date:		Sun Apr 14 15:55:24 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs: ffs_alloc.c

 Log Message:
 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
    a) less than
         #_of_initialized_inodes(cg->cg_initediblk)
         - inodes_per_filesystem_block
       are allocated in the cylinder group
    b) cg->cg_irotor points to a uninterupted run of
       allocated inodes in the inode bitmap up to the
       end of dynamically initialized inodes
       (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.
 Further conditions to occur after the above:
    c) no panic
    d) no (forced) fsck
    e) and more than cg->cg_initediblk - inodes_per_filesystem_block
       allocated inodes.

 Fix:
 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.163 -r1.164 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53990 CVS commit: [netbsd-8] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:51:40 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:51:40 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-8]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1272):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.156.6.1 -r1.156.6.2 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53990 CVS commit: [netbsd-7] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:53:31 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:53:31 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.2 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53990 CVS commit: [netbsd-7-1] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:54:31 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:54:31 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7-1]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.1.6.1 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53990 CVS commit: [netbsd-7-0] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:55:18 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:55:18 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7-0]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.1.2.1 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.