From pst@Shockwave.COM  Sat Apr 11 01:37:25 1998
Received: from precipice.shockwave.com (ppp-206-170-7-21.rdcy01.pacbell.net [206.170.7.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08567
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 11 Apr 1998 01:37:21 -0700 (PDT)
          (envelope-from pst@Shockwave.COM)
Received: (from pst@localhost)
	by precipice.shockwave.com (8.8.8/8.8.8) id BAA01156;
	Sat, 11 Apr 1998 01:37:18 -0700 (PDT)
	(envelope-from pst)
Message-Id: <199804110837.BAA01156@precipice.shockwave.com>
Date: Sat, 11 Apr 1998 01:37:18 -0700 (PDT)
From: Paul Traina <pst@Shockwave.COM>
Reply-To: pst@Shockwave.COM
To: FreeBSD-gnats-submit@freebsd.org
Subject: panic: handle_workitem_freeblocks: block count (softupdates)
X-Send-Pr-Version: 3.2

>Number:         6274
>Category:       kern
>Synopsis:       panic: handle_workitem_freeblocks: block count (softupdates)
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 11 01:40:00 PDT 1998
>Closed-Date:    Tue Dec 22 08:27:24 PST 1998
>Last-Modified:  Tue Dec 22 08:28:02 PST 1998
>Originator:     Paul Traina
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Shockwave Engineering
>Environment:

3.0 current as of last night, softupdates code from julian's page
as of 5pm this afternoon.

>Description:

During a build of XFree86, the system panic'ed with the following message.
Also, fsck -p was unable to fix the filesystem.  fsck -y seems successful,
for the most part, however I still have a directory I can't delete.

pst@precipice$ R gdb -k kernel.0 vmcore.0 
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
IdlePTD 247000
initial pcb at 1f1640
panicstr: handle_workitem_freeblocks: block count
panic messages:
---
panic: handle_workitem_freeblocks: block count

syncing disks... 32 29 23 13 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up

dumping to dev 30401, offset 119984
dump 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  0xf0118cae in boot ()
(kgdb) where
#0  0xf0118cae in boot ()
#1  0xf0118f8f in panic ()
#2  0xf017e1fa in handle_workitem_freeblocks ()
#3  0xf017c2fc in softdep_process_worklist ()
#4  0xf013a2cb in sched_sync ()
#5  0xf010c138 in kproc_start ()
#6  0xf01a1f99 in fork_trampoline ()
Cannot access memory at address 0x24e000.

I have core and kernel files.

System had only the one partition with softupdates enabled.

I am using both MFS and devfs for other partitions, just FYI:

/dev/sd0s2a on / (local, writes: sync 27 async 78))
devfs on dummy_mount (local)
mfs:21 on /tmp (asynchronous, local, writes: sync 28 async 61))
/dev/sd0s2e on /var (local, writes: sync 224 async 265))
/dev/sd0s2f on /usr (local, writes: sync 8 async 196))
/dev/sd0s2g on /a (local, writes: sync 497 async 1789))
devfs on /dev (local)
procfs on /proc (local)

Here is kernel config, for grins:

#
# GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks
#
# For more information read the handbook part System Administration -> 
# Configuring the FreeBSD Kernel -> The Configuration File. 
# The handbook is available in /usr/share/doc/handbook or online as
# latest version from the FreeBSD World Wide Web server 
# <URL:http://www.FreeBSD.ORG/>
#
# An exhaustive list of options and more detailed explanations of the 
# device lines is present in the ./LINT configuration file. If you are 
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
#	$Id: GENERIC,v 1.90 1997/04/14 00:35:20 gibbs Exp $
machine		"i386"
cpu		"I586_CPU"
ident		PRECIPICE
maxusers	60
options		SOFTUPDATES
options		INET			#InterNETworking
options		FFS			#Berkeley Fast Filesystem
options		MSDOSFS			#MSDOS Filesystem
options		"CD9660"		#ISO 9660 Filesystem
options		PROCFS			#Process filesystem
options		DEVFS			#Device filesystem
options		MFS			#memory filesystem
options		"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
options		UCONSOLE		#Allow users to grab the console
options		USERCONFIG		#boot -c editor
options		VISUAL_USERCONFIG	#visual boot -c editor
options		INCLUDE_CONFIG_FILE
options		KTRACE
options		SYSVSHM
options		SYSVSEM
options		SYSVMSG
options		DDB
options		DDB_UNATTENDED
options		"VM86"
options		"USER_LDT"
config		kernel	root on sd0
controller	isa0
controller	pci0
controller	pnp0
controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk		fd0	at fdc0 drive 0
controller	ahc0
options		AHC_TAGENABLE
options		AHC_ALLOW_MEMIO
options		AHC_SCBPAGING_ENABLE
controller	scbus0
device		sd0
device		st0
device		cd0
device		sc0	at isa? port "IO_KBD" tty irq 1 vector scintr
device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr
device		sio0	at isa? port "IO_COM1" tty flags 0x10 irq 4 vector siointr
device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr
device		sio2	at isa? port "IO_COM3" tty irq 5 vector siointr
#device		sio3	at isa? disable port "IO_COM4" tty irq 9 vector siointr
device		lpt0	at isa? port? tty irq 7 vector lptintr
device		psm0	at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr
device		ed0	at isa? port 0x280 net irq ? iomem 0xd8000 vector edintr
device          apm0    at isa?
device		pcm0	at isa? port ? tty irq 11 drq 1 flags 0x13 vector pcmintr
device		bktr0
pseudo-device	ether
pseudo-device	loop
pseudo-device	bpfilter 4
pseudo-device	pty	32
pseudo-device	gzip		# Exec gzipped a.out's
pseudo-device	vn


Any hint on how to destroy the following?

pst@precipice$ R rm -rf BAD
rm: BAD/xc/exports/: Directory not empty
rm: BAD/xc: Directory not empty
rm: BAD: Directory not empty

pst@precipice$ cd BAD/xc/exports
pst@precipice$ ls -ld .
drwxr-xr-x  4 root  wheel  512 Apr 11 01:14 .
pst@precipice$ cd ..
pst@precipice$ ls -ld exports
drwxr-xr-x  4 root  wheel  512 Apr 11 01:14 exports
pst@precipice$ R rmdir exports
rmdir: exports: Directory not empty
pst@precipice$ ls -la exports
total 2
drwxr-xr-x  4 root  wheel  512 Apr 11 01:14 .
drwxr-xr-x  3 root  wheel  512 Apr 10 18:21 ..
pst@precipice$ ls -ld exports
drwxr-xr-x  4 root  wheel  512 Apr 11 01:14 exports




>How-To-Repeat:


	

>Fix:
	
	

>Release-Note:
>Audit-Trail:

From: Luoqi Chen <luoqi@chen.ml.org>
To: freebsd-gnats-submit@freebsd.org, pst@Shockwave.COM
Cc:  Subject: Re: kern/6274: panic: handle_workitem_freeblocks: block count (softupdates)
Date: Thu, 30 Apr 1998 00:43:15 -0400

 I have a pretty good idea of what have happened and a fix. It was
 caused by a vinvalbuf() being mistakenly replaced by vtruncbuf()
 in function ffs_ftruncate(). Here is the diff,
 
 Index: ffs_inode.c
 ===================================================================
 RCS file: /fun/cvs/src/sys/ufs/ffs/ffs_inode.c,v
 retrieving revision 1.40
 diff -u -r1.40 ffs_inode.c
 --- ffs_inode.c 1998/03/30 09:55:55     1.40
 +++ ffs_inode.c 1998/04/23 21:15:22
 @@ -212,7 +212,7 @@
                         (void) chkdq(oip, -oip->i_blocks, NOCRED, 0);
  #endif
                         softdep_setup_freeblocks(oip, length);
 -                       (void) vtruncbuf(ovp, cred, p, length,
 fs->fs_bsize);
 +                       (void) vinvalbuf(ovp, 0, cred, p, 0, 0);
                         oip->i_flag |= IN_CHANGE | IN_UPDATE;
                         return (ffs_update(ovp, &tv, &tv, 0));
                 }
 
 This portion of code is executed when a file is truncated to
 zero length. vtruncbuf() only invalidates all the cached data
 bufs but none of the meta data ones. This will cause a serious problem
 when the file is extended immediately. The first 12 direct blocks
 should be allocated fine, but before the 13th block is allocated,
 the first indirect block is allocated (lblkno = -12). Since we
 have a valid cached buf for this indirect block, it will be reused,
 and NOT be zeroed (because it is clean). Now that the direct block
 pointers in the indirect block are not zero, they will be reused too
 even though they are marked free in cylinder group's bitmap. The next
 time you truncate this file down to zero size, you will get a
 "freeing free block" panic, or in the case those free blocks have been
 allocated to other files AND you didn't extend the file to its original
 size, you would have freed more blocks than expected, thus the
 "block count" panic.
 
 vinvalbuf() on the other hands invalidates all bufs associated with
 this file, data and meta-data alike. The reason that vinvalbuf() was
 replaced by vtruncbuf() is that vtruncbuf() would not cause unnecessary
 sync operations. But the case that the file is truncated to zero size,
 vinvalbuf() will discard all bufs and therefore will not cause any sync
 either. So switch back to vinvalbuf() is the correct solution.
 
 In the non-softupdate case, replacing vinvalbuf() with vtruncbuf() will
 not cause similar problem, because these indirect blocks are
 subsequently
 freed synchonously.
 
 I have communicated this to John Dyson about a week ago, but haven't
 got any response from him yet (thrown away by anti-spam filter?). I hope
 this fix could be committed soon. This seems to be the last bug in the
 softupdate code -- it has been rock solid for me since the fix.
 
 -lq
State-Changed-From-To: open->closed 
State-Changed-By: luoqi 
State-Changed-When: Tue Dec 22 08:27:24 PST 1998 
State-Changed-Why:  
Fix committed. 
>Unformatted:
