NetBSD Problem Report #52102

From www@NetBSD.org  Wed Mar 22 19:11:06 2017
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 "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D08EC7A25E
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 22 Mar 2017 19:11:06 +0000 (UTC)
Message-Id: <20170322191105.664CF7A2AF@mollari.NetBSD.org>
Date: Wed, 22 Mar 2017 19:11:05 +0000 (UTC)
From: flxd@NetBSD.org
Reply-To: flxd@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: shark: ffs_newvnode panic when unpacking sets installing -current
X-Send-Pr-Version: www-1.0

>Number:         52102
>Category:       port-shark
>Synopsis:       shark: ffs_newvnode panic when unpacking sets installing -current
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    skrll
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 22 19:15:00 +0000 2017
>Closed-Date:    Wed Nov 22 20:22:11 +0000 2017
>Last-Modified:  Wed May 29 16:00:08 +0000 2019
>Originator:     Felix Deichmann
>Release:        7.99.66 (from around 2017-03-21)
>Organization:
>Environment:
NetBSD 7.99.66 (INSTALL) shark
>Description:
sysinst/tar/ffs_newvnode panics when trying to unpack the first set during installation of -current on shark (netbsd-INSTALL.aout kernel).
The set has been downloaded via HTTP before, nothing happened yet.


     Status: Running
    Command: progress -zf /targetroot/usr/INSTALL/kern-GENERIC.tgz tar --chroot
-xhepf -

--------------------------------------------------------------------------------
  0% |                                   |  9216        8.91 KiB/s    15:55 ETAffs_newvnode: dup alloc ino=2 on /targetroot: mode 41ed/41ed gen 5882b71e/5882b71e size 200 blocks 4
Stopped in pid 89.1 (tar) at    f00091cc:       mov     pc, r14
db> bt
0xf34abbbc: f010894c
0xf34abbd4: f0108b14
0xf34abc64: f00a15f4
0xf34abca4: f0140c0c
0xf34abcec: f00aab6c
0xf34abd14: f00aadd4
0xf34abd3c: f0146ac0
0xf34abe0c: f0141e7c
0xf34abe8c: f013be10
0xf34abebc: f013bf48
0xf34abee4: f013c014
0xf34abf5c: f000d0ac
0xf34abfac: f000d20c
db>


The "put together" bt using the corresponding netbsd.gdb gives:

0xf010894c <vpanic+12>
0xf0108b14 <snprintf>
0xf00a15f4 <ffs_newvnode+344>
0xf0140c0c <vcache_new+120>
0xf00aab6c <ufs_makeinode+60>
0xf00aadd4 <ufs_create+56>
0xf0146ac0 <VOP_CREATE+56>
0xf0141e7c <vn_open+252>
0xf013be10 <do_open+168>
0xf013bf48 <do_sys_openat+132>
0xf013c014 <sys_open+48>
0xf000d0ac <syscall+312>
0xf000d20c <swi_handler+208>


netbsd.gdb available...!
>How-To-Repeat:
see above
>Fix:

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Wed, 22 Mar 2017 21:01:22 +0100

 This sounds like disk corruption to me, can you verify with older versions,
 check cabling and power supply etc?

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Wed, 22 Mar 2017 21:03:28 +0100

 Another data point: there have been rumours in the past that "modern"
 2.5" hard ata disks would not properly implement PIO (which is the only
 transfer mode supporte on shark, IIRC).

 Martin

From: Felix Deichmann <m4j0rd0m0@gmail.com>
To: gnats-bugs@netbsd.org
Cc: Felix Deichmann <flxd@netbsd.org>, Martin Husemann <martin@duskware.de>
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Thu, 23 Mar 2017 06:59:49 +0100

 2017-03-22 21:05 GMT+01:00 Martin Husemann <martin@duskware.de>:
 >  This sounds like disk corruption to me, can you verify with older versions,
 >  check cabling and power supply etc?

 I checked other 2.5" disks (also an older one with ~4 GB), same result.
 I tried another cable set (different cable itself, different 40 to 44
 pin adapter), same result.
 I'll use a 3.5" disk with an external power supply later today, just
 to rule out possibilities.

 Another observation, not sure if it's related:
 disklabel run from sysinst fails the first time it tries to configure
 the disk. Restarting the installation after that writes "disk label
 corrupt" messages over the menus, but then disklabel will succeed with
 the second try.

 NetBSD 7.1 panics at the exact same point during installation, but
 with a different message ("lock error")!
 NetBSD 6.1.5 installs perfectly fine.

From: Martin Husemann <martin@duskware.de>
To: Felix Deichmann <m4j0rd0m0@gmail.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Thu, 23 Mar 2017 08:54:55 +0100

 On Thu, Mar 23, 2017 at 06:59:49AM +0100, Felix Deichmann wrote:
 > NetBSD 6.1.5 installs perfectly fine.

 OK, so it is not the disk itself, and cabling etc. is very unlikely too.
 How much memory does your machine have?

 Martin

From: Felix Deichmann <m4j0rd0m0@gmail.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Thu, 23 Mar 2017 12:07:08 +0100

 2017-03-23 8:54 GMT+01:00 Martin Husemann <martin@duskware.de>:
 > OK, so it is not the disk itself, and cabling etc. is very unlikely too.
 > How much memory does your machine have?

 It's a DNARD Rev. 5 with 32 MB (from 2 modules), pre-owned by uwe@. :)

 Felix

From: Martin Husemann <martin@duskware.de>
To: Felix Deichmann <m4j0rd0m0@gmail.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Thu, 23 Mar 2017 12:13:59 +0100

 On Thu, Mar 23, 2017 at 12:07:08PM +0100, Felix Deichmann wrote:
 > It's a DNARD Rev. 5 with 32 MB (from 2 modules), pre-owned by uwe@. :)

 Just curious, as I didn't see any problems like this on my 64MB and 96MB
 machines.

 Could you partition the disk into two halves, install 6.x on one of
 them and then bisect with newer kernels to see when newfs of the other
 half starts failing?

 Martin

From: Felix Deichmann <flxd@NetBSD.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-shark/52102: shark: ffs_newvnode panic when unpacking sets
 installing -current
Date: Sat, 26 Aug 2017 19:31:16 +0200

 Am 23.03.2017 um 12:13 schrieb Martin Husemann:
 > Just curious, as I didn't see any problems like this on my 64MB and 96MB
 > machines.

 I could also upgrade my shark to 64MB and 96MB in the meantime, but the
 problem persists.

 > Could you partition the disk into two halves, install 6.x on one of
 > them and then bisect with newer kernels to see when newfs of the other
 > half starts failing?

 Back to 32 MB RAM (to stay reproducible), I bisected it to this commit:

   http://mail-index.netbsd.org/source-changes/2014/03/10/msg052571.html

 Reverting src/sys/arch/arm/arm32/vm_machdep.c to 1.68 in HEAD fixes the
 problem.

 Felix

Responsible-Changed-From-To: port-shark-maintainer->skrll
Responsible-Changed-By: skrll@NetBSD.org
Responsible-Changed-When: Thu, 31 Aug 2017 08:09:39 +0000
Responsible-Changed-Why:
Take


From: "Nick Hudson" <skrll@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52102 CVS commit: src/sys/arch/arm/arm32
Date: Sat, 2 Sep 2017 12:24:39 +0000

 Module Name:	src
 Committed By:	skrll
 Date:		Sat Sep  2 12:24:39 UTC 2017

 Modified Files:
 	src/sys/arch/arm/arm32: pmap.c

 Log Message:
 Perform tracking of unmanaged mappings for VIVT and call vac_me_harder
 as appropriate.

 PR/52102 shark: ffs_newvnode panic when unpacking sets installing -current

 Thanks to Felix Deichmann for bisecting the problem and testing the fix.


 To generate a diff of this commit:
 cvs rdiff -u -r1.355 -r1.356 src/sys/arch/arm/arm32/pmap.c

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

From: "Felix Deichmann" <flxd@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52102 CVS commit: src/sys/arch/arm/arm32
Date: Sun, 8 Oct 2017 12:08:31 +0000

 Module Name:	src
 Committed By:	flxd
 Date:		Sun Oct  8 12:08:31 UTC 2017

 Modified Files:
 	src/sys/arch/arm/arm32: pmap.c

 Log Message:
 Revert attempt at tracking unmanaged mappings for VIVT as it was incomplete and
 buggy. PR port-shark/52102
 From skrll@. Tested by martin@ and me.


 To generate a diff of this commit:
 cvs rdiff -u -r1.357 -r1.358 src/sys/arch/arm/arm32/pmap.c

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

From: "Felix Deichmann" <flxd@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52102 CVS commit: src/sys/arch/arm/arm32
Date: Sun, 8 Oct 2017 12:09:44 +0000

 Module Name:	src
 Committed By:	flxd
 Date:		Sun Oct  8 12:09:44 UTC 2017

 Modified Files:
 	src/sys/arch/arm/arm32: vm_machdep.c

 Log Message:
 In vmapbuf use pmap_enter(pmap_kernel(), ...) and not pmap_kenter_pa as the
 former handles multiple mappings for VIPT AND VIVT correctly whereas the latter
 doesn't work for VIVT. PR port-shark/52102
 From skrll@. Tested by martin@ and me.


 To generate a diff of this commit:
 cvs rdiff -u -r1.70 -r1.71 src/sys/arch/arm/arm32/vm_machdep.c

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

From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52102 CVS commit: [netbsd-8] src/sys/arch/arm/arm32
Date: Tue, 24 Oct 2017 09:12:08 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Tue Oct 24 09:12:07 UTC 2017

 Modified Files:
 	src/sys/arch/arm/arm32 [netbsd-8]: vm_machdep.c

 Log Message:
 Pull up following revision(s) (requested by skrll in ticket #315):
 	sys/arch/arm/arm32/vm_machdep.c: 1.71-1.72
 In vmapbuf use pmap_enter(pmap_kernel(), ...) and not pmap_kenter_pa as the
 former handles multiple mappings for VIPT AND VIVT correctly whereas the latter
 doesn't work for VIVT. PR port-shark/52102
 From skrll@. Tested by martin@ and me.
 --
 Fix eva argument to pmap_remove and passed prot bits in flags for
 pmap_enter, i.e. fix previous.


 To generate a diff of this commit:
 cvs rdiff -u -r1.70 -r1.70.10.1 src/sys/arch/arm/arm32/vm_machdep.c

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

State-Changed-From-To: open->closed
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Wed, 22 Nov 2017 20:22:11 +0000
State-Changed-Why:
Closed


From: "Frank Kardel" <kardel@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52102 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/52102 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/52102 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/52102 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/52102 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.

>Unformatted:

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.