NetBSD Problem Report #40764

From apb@cequrux.com  Fri Feb 27 08:49:55 2009
Return-Path: <apb@cequrux.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 3D61863B946
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 27 Feb 2009 08:49:55 +0000 (UTC)
Message-Id: <20090227084650.B154DE9377A@apb-laptoy.apb.alt.za>
Date: Fri, 27 Feb 2009 08:46:50 +0000 (UTC)
From: apb@cequrux.com
To: gnats-bugs@gnats.NetBSD.org
Subject: fsck says "unrecognised wapbl type" after crash
X-Send-Pr-Version: 3.95

>Number:         40764
>Category:       kern
>Synopsis:       fsck says "unrecognised wapbl type" after crash
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 27 08:50:00 +0000 2009
>Last-Modified:  Thu Mar 03 14:50:01 +0000 2016
>Originator:     Alan Barrett
>Release:        NetBSD 5.99.7
>Organization:
Not much
>Environment:
System: NetBSD 5.99.7 i386
>Description:
After a crash, fsck has the following complaint about a file
system that was in active use at the time of the crash:

    fsck -f -y -P /dev/rcgd2a
    ** /dev/rcgd2a
    ** File system is journaled; replaying journal
    Unrecognized wapbl type: 0x00000000
    UNABLE TO READ JOURNAL FOR REPLAY
    CONTINUE? yes

>How-To-Repeat:
The system was (and still is) running NetBSD-current/i386, built from
sources as of 2009-02-22 20:15 UTC.  (That time is a few minutes before
the removal of softdep.)

The file system was mounted with "mount_ffs -o log".  The file system
was in active use by an rsync process performing a backup from another
file system.  The system crashed, for reasons unknown (I was unble
to get into ddb, and there is no crash dump).  After the crash, fsck
reported the problem described above.

>Fix:
Unknown

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40764: fsck says "unrecognised wapbl type" after crash
Date: Sun, 1 Mar 2009 17:41:09 +0000

 On Fri, Feb 27, 2009 at 08:50:00AM +0000, apb@cequrux.com wrote:

 > After a crash, fsck has the following complaint about a file
 > system that was in active use at the time of the crash:
 > 
 >     fsck -f -y -P /dev/rcgd2a
 >     ** /dev/rcgd2a
 >     ** File system is journaled; replaying journal
 >     Unrecognized wapbl type: 0x00000000
 >     UNABLE TO READ JOURNAL FOR REPLAY
 >     CONTINUE? yes

 Does cgd pass cache flush ioctls to the underlying disk?

 Andrew

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40764: fsck says "unrecognised wapbl type" after crash
Date: Sun, 1 Mar 2009 21:55:00 +0200

 On Sun, 01 Mar 2009, Andrew Doran wrote:
 >  >     fsck -f -y -P /dev/rcgd2a
 >  >     ** /dev/rcgd2a
 >  >     ** File system is journaled; replaying journal
 >  >     Unrecognized wapbl type: 0x00000000
 >  >     UNABLE TO READ JOURNAL FOR REPLAY
 >  >     CONTINUE? yes
 >  
 >  Does cgd pass cache flush ioctls to the underlying disk?

 The cgdioctl() function in sys/dev/cgd.c seems to pass all unrecognised
 ioctls through to dk_ioctl().

 Perhaps the disk driver is not doing the right thing?  The disk is an
 external USB device, attached via sd at scsibus at umass at uhub.

 --apb (Alan Barrett)

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40764: fsck says "unrecognised wapbl type" after crash
Date: Mon, 16 Mar 2009 09:17:38 +0200

 On Sun, 01 Mar 2009, Andrew Doran wrote:
 >  Does cgd pass cache flush ioctls to the underlying disk?

 It didn't then, but it does now.

 See PR 41024 for another problem with the same file system.  The problem
 in PR 41024 is very common, though I have just managed to get enough
 information together to report it properly.  The problem in this PR
 (40764) has been seen only once, after a crash of the general type
 reported in PR 41024.

 --apb (Alan Barrett)

From: "Paul Goyette" <pgoyette@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40764 CVS commit: src/sys/kern
Date: Sat, 6 Feb 2016 22:48:07 +0000

 Module Name:	src
 Committed By:	pgoyette
 Date:		Sat Feb  6 22:48:07 UTC 2016

 Modified Files:
 	src/sys/kern: kern_module.c

 Log Message:
 In module_do_load(), consolidate checking for a pre-existing module,
 and return a single error value EEXIST.  When making a recursive
 call (to load required modules), treat a pre-existing module as
 success.

 Without this change, when a module was loaded by specific request
 (as opposed to being loaded as a requirement of some other module),
 we would always load the module from the file-system, and then
 after making various sanity/compatability checks we would destroy
 the new copy if there was a pre-existing copy.

 Fixes PR kern/40764

 XXX Note that if the module exists, we bypass all of the various
 XXX "compatability" checks, including whether or not the existing
 XXX module is of any particular class!  (In the previous code, we
 XXX checked to see if the newly-loaded copy had the correct class,
 XXX but not the pre-existing copy, which could have been loaded
 XXX from a different path/filename.)


 To generate a diff of this commit:
 cvs rdiff -u -r1.109 -r1.110 src/sys/kern/kern_module.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/40764 CVS commit: [netbsd-7-0] src/sys/kern
Date: Thu, 3 Mar 2016 14:46:07 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Thu Mar  3 14:46:07 UTC 2016

 Modified Files:
 	src/sys/kern [netbsd-7-0]: kern_ksyms.c kern_module.c

 Log Message:
 Pull up following revision(s) (requested by pgoyette in ticket #1108):
 	sys/kern/kern_module.c: revision 1.107-1.110
 	sys/kern/kern_ksyms.c: revision 1.82
 Add some additional status messages for kern.module.verbose=TRUE

 Remove extraneous ')' from previous.

 KNF

 In module_do_load(), consolidate checking for a pre-existing module,
 and return a single error value EEXIST.  When making a recursive
 call (to load required modules), treat a pre-existing module as
 success.

 Without this change, when a module was loaded by specific request
 (as opposed to being loaded as a requirement of some other module),
 we would always load the module from the file-system, and then
 after making various sanity/compatability checks we would destroy
 the new copy if there was a pre-existing copy.

 Fixes PR kern/40764

 XXX Note that if the module exists, we bypass all of the various
 XXX "compatability" checks, including whether or not the existing
 XXX module is of any particular class!  (In the previous code, we
 XXX checked to see if the newly-loaded copy had the correct class,
 XXX but not the pre-existing copy, which could have been loaded
 XXX from a different path/filename.)


 To generate a diff of this commit:
 cvs rdiff -u -r1.72 -r1.72.4.1 src/sys/kern/kern_ksyms.c
 cvs rdiff -u -r1.97.2.1 -r1.97.2.1.2.1 src/sys/kern/kern_module.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/40764 CVS commit: [netbsd-7] src/sys/kern
Date: Thu, 3 Mar 2016 14:47:08 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Thu Mar  3 14:47:08 UTC 2016

 Modified Files:
 	src/sys/kern [netbsd-7]: kern_ksyms.c kern_module.c

 Log Message:
 Pull up following revision(s) (requested by pgoyette in ticket #1108):
 	sys/kern/kern_module.c: revision 1.107-1.110
 	sys/kern/kern_ksyms.c: revision 1.82
 Add some additional status messages for kern.module.verbose=TRUE

 Remove extraneous ')' from previous.

 KNF

 In module_do_load(), consolidate checking for a pre-existing module,
 and return a single error value EEXIST.  When making a recursive
 call (to load required modules), treat a pre-existing module as
 success.

 Without this change, when a module was loaded by specific request
 (as opposed to being loaded as a requirement of some other module),
 we would always load the module from the file-system, and then
 after making various sanity/compatability checks we would destroy
 the new copy if there was a pre-existing copy.

 Fixes PR kern/40764

 XXX Note that if the module exists, we bypass all of the various
 XXX "compatability" checks, including whether or not the existing
 XXX module is of any particular class!  (In the previous code, we
 XXX checked to see if the newly-loaded copy had the correct class,
 XXX but not the pre-existing copy, which could have been loaded
 XXX from a different path/filename.)


 To generate a diff of this commit:
 cvs rdiff -u -r1.72 -r1.72.2.1 src/sys/kern/kern_ksyms.c
 cvs rdiff -u -r1.97.2.1 -r1.97.2.2 src/sys/kern/kern_module.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.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.