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:
(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.
Home