From matt@megaweapon.zigg.com  Mon Jan 18 17:51:45 1999
Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20701
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Jan 1999 17:51:41 -0800 (PST)
          (envelope-from matt@megaweapon.zigg.com)
Received: (from matt@localhost)
	by megaweapon.zigg.com (8.9.2/8.9.2) id UAA46096;
	Mon, 18 Jan 1999 20:46:32 -0500 (EST)
	(envelope-from matt)
Message-Id: <199901190146.UAA46096@megaweapon.zigg.com>
Date: Mon, 18 Jan 1999 20:46:32 -0500 (EST)
From: Matt Behrens <matt@megaweapon.zigg.com>
Reply-To: matt@megaweapon.zigg.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: softupdates freezes system under heavy load
X-Send-Pr-Version: 3.2

>Number:         9560
>Category:       kern
>Synopsis:       softupdates freezes system under heavy load
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 18 18:00:01 PST 1999
>Closed-Date:    Mon Mar 29 16:22:28 PST 1999
>Last-Modified:  Mon Mar 29 16:24:23 PST 1999
>Originator:     Matt Behrens
>Release:        FreeBSD 3.0.0-19990112-SNAP i386
>Organization:
zigg.com
>Environment:

486 DX2-50
Diamond Speedstar Pro SVGA 1MB ISA
Generic (?) VLB IO/FDD/IDE controller
- Conner 1275 MB CFS1275A
- Maxtor 3663 MB 83840 A6
Adaptec AHA-1542 ISA
- Conner tape drive (not used during this problem)
AT Keyboard
Soundblaster compatible (not configured)
Kingston EtheRx ISA NE2000 compatible
32MB (4 4MB 4x9 30-pin SIMMs)

>Description:

Under heavy load, when using softupdates, the system will occasionally
stop processing, except for syscons, which seems to still be working.
The drive will thrash violently until the system is powered down.
A trace from DDB gave the following information:

Debugger(f021f865) at Debugger+0x37
sc_alloc_history_buffer(f025267c,2,0,f025267c,7011d) at sc_alloc_history_buffer+
0xcd0
scdevtotty(f025267c,0,0,0,f0612c00) at scdevtotty+0x35c
atkbd_attach_unit(f025267c,0,0,f32b7e24,f01effce) at atkbd_attach_unit+0x4e7
is_physical_memory(0,c0084040,f0610010,f0130010,7011d) at is_physical_memory+0x2
cc
Xintr1(0,0,f01a7188,c0000000,0) at Xintr1+0x5e
wdintr(0,c0000000,f0610010,10,c0000000) at wdintr+0x5b8
Xintr14(80000000,f32b0010,f01d0010,f32b7f88,f32a6200) at Xintr14+0x61
doreti_popl_es_fault(f32b7f88) at doreti_popl_es_fault+0x49
vn_syncer_add_to_worklist(f32abbf7,f02192a5,f0230588,f01f30fs,f01ef5c0) at vn_sy
ncer_add_to_worklist+0x13c
kproc_start(f0230588) at kproc_start+0x32
fork_trampoline(e4ec1589,c766f025,25e4ee05,800008f0,25e4f025) at fork_trampoline
+0x30

Attempting to panic the system to sync it from DDB got stuck on
the sync phase due to wd error 58.  Upon rebooting, the system can
successfully be fsck -p'd back into an intact filesystem, reporting
INCORRECT BLOCK COUNT and UNREF FILE errors.  When finished, several
of the files that were last created are missing from the disk.

This system works fine if drives are not mounted with softupdates,
performing the same tasks (one of these instances was caused by
untarring XFree86 in the ports collection, just minutes after a
reboot) very reliably.


No known solid method of repeating the problem.  It seems to occur
under heavy load but cannot necessarily be repeated with certaincy.

>How-To-Repeat:
>Fix:
	
None known.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Mon Mar 29 16:22:28 PST 1999 
State-Changed-Why:  
Upgrade to a recent 3.1, although you should be aware that softupdates 
has been "stable" for a while now. Still, 19990112 is an old 
snap. 
>Unformatted:
