From neteng@tide.iadfw.net  Fri Mar 30 11:43:49 2001
Return-Path: <neteng@tide.iadfw.net>
Received: from tide.iadfw.net (tide.iadfw.net [206.66.12.73])
	by hub.freebsd.org (Postfix) with ESMTP id E447037B71E
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 30 Mar 2001 11:43:48 -0800 (PST)
	(envelope-from neteng@tide.iadfw.net)
Received: (from root@localhost)
	by tide.iadfw.net (8.11.3/8.11.3) id f2UJhmP00968;
	Fri, 30 Mar 2001 13:43:48 -0600 (CST)
	(envelope-from neteng)
Message-Id: <200103301943.f2UJhmP00968@tide.iadfw.net>
Date: Fri, 30 Mar 2001 13:43:48 -0600 (CST)
From: ler@airmail.net
Reply-To: ler@airmail.net
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: KERNEL/VFS PANIC/SMP/4.3-BETA/8-MAR-2001 Source
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         26224
>Category:       kern
>Synopsis:       VFS Panic/SMP/CFLOW(HEAVY network)/Heavy NFS
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    dillon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 30 11:50:00 PST 2001
>Closed-Date:    Sun Jun 09 13:12:24 PDT 2002
>Last-Modified:  Sun Jun 09 13:12:24 PDT 2002
>Originator:     Larry Rosenman <ler@airmail.net>
>Release:        FreeBSD 4.3-BETA i386
>Organization:
Internet America, Inc. 
>Environment:
System: FreeBSD tide.iadfw.net 4.3-BETA FreeBSD 4.3-BETA #0: Wed Mar 28 15:59:32 CST 2001 neteng@tide.iadfw.net:/usr/obj/usr/src/sys/TIDE2-DEBUG i386


Dual P-II 300 512MB Ram/4GB+ SWAP 

Heavy NFS
	
>Description:
	
See above.  Kernel/Core/Config will be at ftp://ftp.lerctr.org/freebsd/
with the PR number in the file name as soon as I get the PR number. 


>How-To-Repeat:

This happens approximately every 2-3 weeks.  This machine catches Netflow data
from the Cisco Routers at Internet America.  System is running CFLOWD 2-1-b6 
software.  It's main data store is NFS mounted from a NetApp Filer. 


>Fix:


>Release-Note:
>Audit-Trail:

From: Larry Rosenman <ler@ler-freebie.iadfw.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/26224: vfs panic
Date: Fri, 30 Mar 2001 14:16:33 -0600

 Kernel Back Trace:
 
 #0  0xc015e726 in dumpsys ()
 (kgdb) bt
 #0  0xc015e726 in dumpsys ()
 #1  0xc015e547 in boot ()
 #2  0xc015e911 in panic ()
 #3  0xc01311f1 in db_panic ()
 #4  0xc0131191 in db_command ()
 #5  0xc0131256 in db_command_loop ()
 #6  0xc0133363 in db_trap ()
 #7  0xc02344fd in kdb_trap ()
 #8  0xc0246a9c in trap ()
 #9  0xc02347b8 in Debugger ()
 #10 0xc015e908 in panic ()
 #11 0xc0245a82 in bsl1 ()
 #12 0xc018be57 in vfs_msync ()
 #13 0xc018c372 in sync_fsync ()
 #14 0xc018a5eb in sched_sync ()
 #15 0xc0234f20 in fork_trampoline ()
 cannot read proc at 0
 (kgdb) 
 
 dump is huge (200+meg GZIPPED, will be up as soon as it ftp's. 
 
 LER
 
 
 -- 
 Larry Rosenman, Sr. Network Engineer, Internet America, Inc.
 Phone: +1 214-861-2571, FAX: +1 214-861-2663
 E-Mail: ler@airmail.net
 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201 US
 
 

From: Larry Rosenman <ler@ler-freebie.iadfw.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/26224
Date: Fri, 30 Mar 2001 15:01:13 -0600

 The tarball is at:
 
 ftp://ftp.lerctr.org/freebsd/pr_kern_26224.tar.gz
 
 -rw-r--r--    1 101      150       202454691 Mar 30 20:41 pr_kern_26224.tar.gz
 
 
 $ gzcat pr*|tar tvf - 
 -rw-r--r--  0/0     3600 Mar 30 13:38 2001 conf.72
 -rw-r--r--  0/0  2054675 Mar 30 12:24 2001 kernel.72
 -rw-------  0/0  536870912 Mar 30 12:24 2001 vmcore.72
 $ 
 
 
 Let me know what else you need.
 
 Larry Rosenman
 

From: Larry Rosenman <ler@lerctr.org>
To: freebsd-gnats-submit@FreeBSD.org, ler@airmail.net,
	bright@wintelcom.net
Cc:  
Subject: Re: kern/26224: VFS Panic/SMP/CFLOW(HEAVY network)/Heavy NFS
Date: Fri, 22 Jun 2001 18:50:22 -0500

 Here is a NEW panic on this one, and ALL has been compiled with -O..
 
 (kgdb) bt
 #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
 #1  0xc01600bc in boot (howto=260) at
 /usr/src/sys/kern/kern_shutdown.c:309
 #2  0xc0160491 in panic (fmt=0xc0260874 "from debugger")
     at /usr/src/sys/kern/kern_shutdown.c:556
 #3  0xc0131791 in db_panic (addr=-1071409727, have_addr=0, count=-1, 
     modif=0xd62d8d68 "") at /usr/src/sys/ddb/db_command.c:433
 #4  0xc013172f in db_command (last_cmdp=0xc028c560,
 cmd_table=0xc028c3c0, 
     aux_cmd_tablep=0xc02a7120) at /usr/src/sys/ddb/db_command.c:333
 #5  0xc01317f6 in db_command_loop () at
 /usr/src/sys/ddb/db_command.c:455
 #6  0xc013399f in db_trap (type=3, code=0) at
 /usr/src/sys/ddb/db_trap.c:71
 #7  0xc0239300 in kdb_trap (type=3, code=0, regs=0xd62d8e78)
     at /usr/src/sys/i386/i386/db_interface.c:158
 #8  0xc024bba4 in trap (frame={tf_fs = -1072365544, tf_es = -1037500400, 
       tf_ds = 16777232, tf_edi = 0, tf_esi = 256, tf_ebp = -701657408, 
       tf_isp = -701657436, tf_ebx = -1071338626, tf_edx = -1071117005, 
       tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, 
       tf_eip = -1071409727, tf_cs = 8, tf_eflags = 598, tf_esp =
 -1071117021, 
       tf_ss = -1071214638}) at /usr/src/sys/i386/i386/trap.c:569
 #9  0xc02395c1 in Debugger (msg=0xc0268fd2 "panic") at
 machine/cpufunc.h:64
 #10 0xc0160488 in panic (
     fmt=0xc024ab7e "rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x")
     at /usr/src/sys/kern/kern_shutdown.c:554
 #11 0xc024ab7e in bsl1 ()
 ---Type <return> to continue, or q <return> to quit---
 #12 0xc02203e8 in vm_pageout_scan (pass=0) at
 /usr/src/sys/vm/vm_pageout.c:929
 #13 0xc0220cbf in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1386
 #14 0xc0239d40 in fork_trampoline ()
 cannot read proc at 0
 
 Anyone want to take a look at the core? 
 
 
 -- 
 Larry Rosenman                     http://www.lerctr.org/~ler
 Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From: Networking role account <neteng@tide.iadfw.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: re: kern/26224:  VFS Panic/SMP/CFLOW(HEAVY network)/Heavy NFS
Date: Tue, 10 Jul 2001 08:14:04 -0500

 Per David Malone's suggestion, here is lists from frames 11 and 12.
 
 
 Script started on Tue Jul 10 08:08:40 2001
 tide# gdb -k -c vmcore.76 kernel.debug.76=20
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain condition=
 s.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-unknown-freebsd"...
 SMP 2 cpus
 IdlePTD 3358720
 initial pcb at 2abc80
 panicstr: from debugger
 panic messages:
 ---
 panic: rslock: cpu: 1, addr: 0xd8b74e6c, lock: 0x01000001
 mp_lock =3D 01000001; cpuid =3D 1; lapic.id =3D 01000000
 panic: from debugger
 mp_lock =3D 01000002; cpuid =3D 1; lapic.id =3D 01000000
 boot() called on cpu#1
 Uptime: 4d4h11m35s
 
 dumping to dev #da/0x20008, offset 7311018
 dump 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 49=
 5 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 4=
 76 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 =
 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439=
  438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 42=
 0 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 4=
 01 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 =
 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364=
  363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 34=
 5 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 3=
 26 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 =
 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289=
  288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 27=
 0 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 2=
 51 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 =
 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214=
  213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 19=
 5 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 1=
 76 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 =
 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139=
  138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 12=
 0 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 1=
 01 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77=
  76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52=
  51 50 49 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=20
 ---
 #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
 469		if (dumping++) {
 (kgdb) bt
 #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
 #1  0xc01600bc in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3=
 09
 #2  0xc0160491 in panic (fmt=3D0xc0260874 "from debugger")
     at /usr/src/sys/kern/kern_shutdown.c:556
 #3  0xc0131791 in db_panic (addr=3D-1071409727, have_addr=3D0, count=3D-1,=
 =20
     modif=3D0xd62d8d68 "") at /usr/src/sys/ddb/db_command.c:433
 #4  0xc013172f in db_command (last_cmdp=3D0xc028c560, cmd_table=3D0xc028c3c=
 0,=20
     aux_cmd_tablep=3D0xc02a7120) at /usr/src/sys/ddb/db_command.c:333
 #5  0xc01317f6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
 #6  0xc013399f in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_trap.=
 c:71
 #7  0xc0239300 in kdb_trap (type=3D3, code=3D0, regs=3D0xd62d8e78)
     at /usr/src/sys/i386/i386/db_interface.c:158
 #8  0xc024bba4 in trap (frame=3D{tf_fs =3D -1072365544, tf_es =3D -10375004=
 00,=20
       tf_ds =3D 16777232, tf_edi =3D 0, tf_esi =3D 256, tf_ebp =3D -7016574=
 08,=20
       tf_isp =3D -701657436, tf_ebx =3D -1071338626, tf_edx =3D -1071117005=
 ,=20
       tf_ecx =3D 32, tf_eax =3D 18, tf_trapno =3D 3, tf_err =3D 0,=20
       tf_eip =3D -1071409727, tf_cs =3D 8, tf_eflags =3D 598, tf_esp =3D -1=
 071117021,=20
       tf_ss =3D -1071214638}) at /usr/src/sys/i386/i386/trap.c:569
 #9  0xc02395c1 in Debugger (msg=3D0xc0268fd2 "panic") at machine/cpufunc.h:=
 64
 #10 0xc0160488 in panic (
     fmt=3D0xc024ab7e "rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x")
     at /usr/src/sys/kern/kern_shutdown.c:554
 #11 0xc024ab7e in bsl1 ()
 ---Type <return> to continue, or q <return> to quit---
 #12 0xc02203e8 in vm_pageout_scan (pass=3D0) at /usr/src/sys/vm/vm_pageout.=
 c:929
 #13 0xc0220cbf in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1386
 #14 0xc0239d40 in fork_trampoline ()
 cannot read proc at 0
 (kgdb) fr 11
 #11 0xc024ab7e in bsl1 ()
 (kgdb) list
 464	dumpsys(void)
 465	{
 466		int	error;
 467=09
 468		savectx(&dumppcb);
 469		if (dumping++) {
 470			printf("Dump already in progress, bailing...\n");
 471			return;
 472		}
 473		if (!dodump)
 (kgdb) fr 12
 #12 0xc02203e8 in vm_pageout_scan (pass=3D0) at /usr/src/sys/vm/vm_pageout.=
 c:929
 929					vput(vp);
 (kgdb) list
 924				s =3D splvm();
 925				next =3D TAILQ_NEXT(&marker, pageq);
 926				TAILQ_REMOVE(&vm_page_queues[PQ_INACTIVE].pl, &marker, pageq);
 927				splx(s);
 928				if (vp !=3D NULL)
 929					vput(vp);
 930			}
 931		}
 932=09
 933		/*
 (kgdb) print vp
 $1 =3D (struct vnode *) 0xd8b74e00
 (kgdb) print *vp
 $2 =3D {v_flag =3D 8192, v_usecount =3D 2, v_writecount =3D 0, v_holdcnt =
 =3D 0,=20
   v_id =3D 5102252, v_mount =3D 0xc20c6600, v_op =3D 0xc1e36d00, v_freelist=
  =3D {
     tqe_next =3D 0xd8b6d200, tqe_prev =3D 0xc02ac518}, v_mntvnodes =3D {
     le_next =3D 0xd8b78cc0, le_prev =3D 0xd8b6d224}, v_cleanblkhd =3D {
     tqh_first =3D 0x0, tqh_last =3D 0xd8b74e2c}, v_dirtyblkhd =3D {tqh_firs=
 t =3D 0x0,=20
     tqh_last =3D 0xd8b74e34}, v_synclist =3D {le_next =3D 0x0,=20
     le_prev =3D 0xc1df5c30}, v_numoutput =3D 0, v_type =3D VREG, v_un =3D {
     vu_mountedhere =3D 0x0, vu_socket =3D 0x0, vu_spec =3D {vu_specinfo =3D=
  0x0,=20
       vu_specnext =3D {sle_next =3D 0x0}}, vu_fifoinfo =3D 0x0}, v_lease =
 =3D 0x0,=20
   v_lastw =3D 0, v_cstart =3D 0, v_lasta =3D 0, v_clen =3D 0, v_object =3D =
 0xd8cd9b40,=20
   v_interlock =3D {lock_data =3D 16777217}, v_vnlock =3D 0xc2296780, v_tag =
 =3D VT_NFS,=20
   v_data =3D 0xd8c89140, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =
 =3D {
     tqh_first =3D 0xc2106340, tqh_last =3D 0xc2106350}, v_dd =3D 0xd8b74e00=
 ,=20
   v_ddid =3D 0, v_pollinfo =3D {vpi_lock =3D {lock_data =3D 0}, vpi_selinfo=
  =3D {
       si_pid =3D 0, si_note =3D {slh_first =3D 0x0}, si_flags =3D 0}, vpi_e=
 vents =3D 0,=20
     vpi_revents =3D 0}, v_vxproc =3D 0x0}
 (kgdb) tide#=20
 
 Script done on Tue Jul 10 08:10:31 2001

From: Larry Rosenman <ler@lerctr.org>
To: Thomas Moestl <tmoestl@gmx.net>
Cc: IA Network Engineering <neteng@airmail.net>,
	Frank Durda IV <uhclem@airmail.net>, jamesn@airmail.net,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/26224
Date: Tue, 14 Aug 2001 01:53:09 -0500

 * Larry Rosenman <ler@lerctr.org> [010725 19:05]:
 > * Thomas Moestl <tmoestl@gmx.net> [010725 17:05]:
 > > On Wed, 2001/07/25 at 16:49:52 -0500, Larry Rosenman wrote:
 > > > * Thomas Moestl <tmoestl@gmx.net> [010725 13:11]:
 > > > > On Wed, 2001/07/25 at 12:41:14 -0500, Larry Rosenman wrote:
 > > > > > Any news on the kern/26224 bug? 
 > > > > 
 > > > > For -STABLE, the simplelocks can most probably just be removed
 > > > > totally, so that this bug won't occur. For -CURRENT, this will need to
 > > > > be done in a different way, but locking is in a state of flux there
 > > > > anyway.
 > > > > 
 > > > > Tor Egge had a patch to remove the locks, I'll ask him again if he
 > > > > thinks that it is ready for commit.
 > > > Thanks.  The lockup version of this just bit me again. :-( 
 > > > 
 > > > I'm willing to be a guinea pig, if you need one.
 > > 
 > > I have attached a patch I want to post to -stable soon for people to
 > > test. I'm sure that it fixes this panic (the lock is just removed;
 > > this section is also protected by the mp_lock, so it should be
 > > safe). However, this is largely untested (I don't have an SMP box, and
 > > on UP simplelocks are disabled). So, be warned, I could have
 > > overlooked something, so other panics might surface...
 > > On the other hand, you could probably test this patch well, because
 > > your box seems rather stressed ;)
 > Ok, it's applied, and booted.  We'll see.  This one seems to hit me
 > every 3-4 weeks. 
 Even WITH this fix in, I just had the lockup version hit me.
 Unfortunately, ctrl/break did *NOT* bring up DDB.  The basic TCP stack
 was working (ping, telnet got to the connected to xxx part), but the
 box wouldn't give a login prompt nor serve www pages. 
 
 I don't know how to get the debug info. 
 
 The box was up for 19+ days (almost 20, not sure exactly). 
 
 How would you recomment proceeding? 
 
 
 
 
 > 
 > Thanks!
 > 
 > LER
 > 
 > > 
 > > 	- thomas
 > 
 > > Index: vfs_subr.c
 > > ===================================================================
 > > RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
 > > retrieving revision 1.249.2.9
 > > diff -u -r1.249.2.9 vfs_subr.c
 > > --- vfs_subr.c	2001/06/26 04:20:08	1.249.2.9
 > > +++ vfs_subr.c	2001/07/25 21:35:01
 > > @@ -730,12 +730,10 @@
 > >  	/*
 > >  	 * Destroy the copy in the VM cache, too.
 > >  	 */
 > > -	simple_lock(&vp->v_interlock);
 > >  	if (VOP_GETVOBJECT(vp, &object) == 0) {
 > >  		vm_object_page_remove(object, 0, 0,
 > >  			(flags & V_SAVE) ? TRUE : FALSE);
 > >  	}
 > > -	simple_unlock(&vp->v_interlock);
 > >  
 > >  	if (!TAILQ_EMPTY(&vp->v_dirtyblkhd) || !TAILQ_EMPTY(&vp->v_cleanblkhd))
 > >  		panic("vinvalbuf: flush failed");
 > 
 > 
 > -- 
 > Larry Rosenman                     http://www.lerctr.org/~ler
 > Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
 
 -- 
 Larry Rosenman                     http://www.lerctr.org/~ler
 Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From: Larry Rosenman <ler@lerctr.org>
To: Thomas Moestl <tmoestl@gmx.net>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/26224
Date: Thu, 16 Aug 2001 15:34:51 -0500

 * Thomas Moestl <tmoestl@gmx.net> [010816 12:59]:
 > On Tue, 2001/08/14 at 01:53:09 -0500, Larry Rosenman wrote:
 > > * Larry Rosenman <ler@lerctr.org> [010725 19:05]:
 > > > * Thomas Moestl <tmoestl@gmx.net> [010725 17:05]:
 > > > > I have attached a patch I want to post to -stable soon for people to
 > > > > test. I'm sure that it fixes this panic (the lock is just removed;
 > > > > this section is also protected by the mp_lock, so it should be
 > > > > safe). However, this is largely untested (I don't have an SMP box, and
 > > > > on UP simplelocks are disabled). So, be warned, I could have
 > > > > overlooked something, so other panics might surface...
 > > > > On the other hand, you could probably test this patch well, because
 > > > > your box seems rather stressed ;)
 > > > Ok, it's applied, and booted.  We'll see.  This one seems to hit me
 > > > every 3-4 weeks. 
 > > Even WITH this fix in, I just had the lockup version hit me.
 > > Unfortunately, ctrl/break did *NOT* bring up DDB.  The basic TCP stack
 > > was working (ping, telnet got to the connected to xxx part), but the
 > > box wouldn't give a login prompt nor serve www pages. 
 > 
 > Hmmm. Did that lockup version happen before? A certain deadlock should
 > also be fixed by the patch, but I'd guess that you are hitting a
 > different issue.
 Yes, we've seen the lockup before.
 > 
 > > I don't know how to get the debug info. 
 > 
 > Dumb question: you do have ddb in your kernel, and crtrl-break is
 > wired to enter ddb in the key map you use?
 > It is unusual for the type of bug that I'm expecting that network
 > interrupts are still being processed while tty interrupts are not.
 YES.  We just found that for SYSCONS, the DDB key is CTRL/PRTSC.  Will
 try to get the DDB next time it fails (2-3 weeks :-( ). 
 > 
 > For this type of bug, it is not easy to get debug information,
 > especially if there is no easy way to trigger it.
 > One method to get into ddb anyway was to trigger an NMI via the ISA
 > bus, but this does not work with most newer main boards.
 > For SMP machines, however, Tor Egge has posted a patch to one of the
 > mailing lists (-current or -hackers, I think) that rewires the
 > interrupt of a serial port to the NMI using the APIC, that might help
 > you (although it probably should be used with care).
 We'll see what happens on next fail. Thanks!
 
 
 > 
 > 	- thomas
 > 
 > P.S.: sorry for the late answer, I have been kind of busy lately ;)
 No Problem, I understand. 
 
 LER
 
 
 -- 
 Larry Rosenman                     http://www.lerctr.org/~ler
 Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
State-Changed-From-To: open->feedback 
State-Changed-By: silby 
State-Changed-When: Sat Jan 5 14:27:49 PST 2002 
State-Changed-Why:  
Many NFS bugs have been fixed recently in 4.4-stable; please 
upgrade to -stable and see if the problems still exist (it 
seems likely that they may now have been fixed.) 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26224 
Responsible-Changed-From-To: freebsd-bugs->dillon 
Responsible-Changed-By: silby 
Responsible-Changed-When: Tue Jan 8 17:47:27 PST 2002 
Responsible-Changed-Why:  
Over to Dillon, Mr. NFS. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26224 

From: Larry Rosenman <ler@airmail.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: kern/26224
Date: Fri, 18 Jan 2002 12:51:30 -0600

 I had another crash today, still on the 4.3-STABLE code, with Tmoestl's code to 
 not do the locking.
 
 It did the "low level network" but nothing else. I *DO* have the core dump, from 
 a 2nd panic from ddb.  The firstone caused lock_acquire to page fault on 
 location 0x30.  
 
 I know there has been a LOT of work done.  Is the general consensus to come up 
 to 4.5-RC and see what happens?  
 
 Thanks.
 
 -- 
 Larry Rosenman, Sr. Network Engineer, Internet America, Inc.
 E-Mail: ler@airmail.net 
 Phone: +1 214-861-2571, Fax: 214-861-2663
 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201

From: Larry Rosenman <ler@airmail.net>
To: freebsd-gnats-submit@freebsd.org, dillon@freebsd.org
Cc: neteng@airmail.net
Subject: kern/26224
Date: Mon, 21 Jan 2002 17:20:44 -0600

 Due to policy reasons, and the fact that 4.5-RELEASE is due within the next week
 or so, I will wait till after the 4.5 Release is cut to upgrade. 
 
 I will follow-up after that.  Please do *NOT* close this PR till I concur that
 the problem doesn't stil occur (unfortunately it takes upwards of 20+ days for 
 it to reproduce.)
 
 Thanks.
 
 
 
 -- 
 Larry Rosenman, Sr. Network Engineer, Internet America, Inc.
 E-Mail: ler@airmail.net 
 Phone: +1 214-861-2571, Fax: 214-861-2663
 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201

From: Larry Rosenman <ler@lerctr.org>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: kern/26224
Date: 31 May 2002 17:38:06 -0500

 I think we can close this one.  It hasn't happened since we upgraded to
 4.5, and we also stopped using cflowd itself, so we don't put nearly the
 load on it we used to. 
 
 
 -- 
 Larry Rosenman                     http://www.lerctr.org/~ler
 Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
 
State-Changed-From-To: feedback->closed 
State-Changed-By: dillon 
State-Changed-When: Sun Jun 9 13:10:24 PDT 2002 
State-Changed-Why:  
Larry request a close.  My fingers are crossed :-) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26224 
>Unformatted:
