From anders@fupp.net  Mon Sep 11 07:54:34 2006
Return-Path: <anders@fupp.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id EB98016A412
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Sep 2006 07:54:34 +0000 (UTC)
	(envelope-from anders@fupp.net)
Received: from fupp.net (totem.fix.no [80.91.36.20])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC5043D45
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Sep 2006 07:54:34 +0000 (GMT)
	(envelope-from anders@fupp.net)
Received: from localhost (totem.fix.no [80.91.36.20])
	by fupp.net (Postfix) with ESMTP id A357B8D9888;
	Mon, 11 Sep 2006 09:54:32 +0200 (CEST)
Received: from fupp.net ([80.91.36.20])
 by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP
 id 50875-01-8; Mon, 11 Sep 2006 09:54:31 +0200 (CEST)
Received: by fupp.net (Postfix, from userid 1000)
	id D12758D9874; Mon, 11 Sep 2006 09:54:31 +0200 (CEST)
Message-Id: <20060911075431.D12758D9874@fupp.net>
Date: Mon, 11 Sep 2006 09:54:31 +0200 (CEST)
From: Anders Nordby <anders@FreeBSD.org>
Reply-To: Anders Nordby <anders@FreeBSD.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: adrian@creative.net.au, tmseck@netcologne.de
Subject: Kernel panic while using thread features in Squid 2.6
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         103127
>Category:       kern
>Synopsis:       Kernel panic while using thread features in Squid 2.6
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jmg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 11 08:00:44 GMT 2006
>Closed-Date:    Sat Oct 07 19:16:08 GMT 2006
>Last-Modified:  Sat Oct 07 19:16:08 GMT 2006
>Originator:     Anders Nordby <anders@FreeBSD.org>
>Release:        FreeBSD 6.1-RELEASE-p5 i386
>Organization:
-
>Environment:
System: FreeBSD cache3.foobar.no 6.1-RELEASE-p5 FreeBSD 6.1-RELEASE-p5 #0: Thu Sep  7 15:53:24 CEST 2006     root@cache3.foobar.no:/usr/obj/usr/src/sys/CACHE  i386

Squid Cache: Version 2.6.STABLE3
configure options: '--bindir=/usr/local/sbin' '--sbindir=/usr/local/sbin' '--datadir=/usr/local/etc/squid' '--libexecdir=/usr/local/libexec/squid' '--localstatedir=/usr/local/squid' '--sysconfdir=/usr/local/etc/squid' '--enable-removal-policies=lru heap' '--disable-linux-netfilter' '--disable-linux-tproxy' '--disable-epoll' '--enable-auth=basic ntlm digest' '--enable-basic-auth-helpers=NCSA PAM MSNT SMB YP' '--enable-digest-auth-helpers=password' '--enable-external-acl-helpers=ip_user session unix_group wbinfo_group' '--enable-ntlm-auth-helpers=SMB' '--enable-async-io' '--with-pthreads' '--enable-storeio=ufs diskd null aufs' '--enable-kqueue' '--enable-err-languages=Azerbaijani Bulgarian Catalan Czech Danish Dutch  English Estonian Finnish French German Greek Hebrew  Hungarian Italian Japanese Korean Lithuanian  Polish Portuguese Romanian Russian-1251 Russian-koi8-r  Serbian Simplify_Chinese Slovak Spanish Swedish  Traditional_Chinese Turkish' '--enable-default-err-language=E
 nglish' '--enable-dlmalloc' '--enable-snmp' '--enable-async-io=50' '--prefix=/usr/local' 'i386-portbld-freebsd6.1' 'LDFLAGS=' 'CFLAGS=-O2 -fno-strict-aliasing -pipe  ' 'CPPFLAGS=' 'host_alias=i386-portbld-freebsd6.1' 'build_alias=i386-portbld-freebsd6.1' 'target_alias=i386-portbld-freebsd6.1' 'CC=cc'
>Description:

Recently I've been trying to switch to threads-based scheduling of
disk I/O requests, that is to use the aufs cache store type. It seems fast,
by using it Squid doesn't block on disk I/O so easily when under load.

Now and then I get a kernel panic, however:

root@cache3:/usr/src# kgdb /usr/obj/usr/src/sys/CACHE/kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 conditions.
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-marcel-freebsd".

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 06
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0x0
stack pointer	        = 0x28:0xeb9a7b98
frame pointer	        = 0x28:0xeb9a7bcc
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 542 (squid)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 2d4h20m9s
Dumping 3839 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 3839MB (982778 pages) 3824 3808 3792 3776 3760 3744 3728 3712 3696 3680 3664 3648 3632 3616 3600 3584 3568 3552 3536 3520 3504 3488 3472 3456 3440 3424 3408 3392 3376 3360 3344 3328 3312 3296 3280 3264 3248 3232 3216 3200 3184 3168 3152 3136 3120 3104 3088 3072 3056 3040 3024 3008 2992 2976 2960 2944 2928 2912 2896 2880 2864 2848 2832 2816 2800 2784 2768 2752 2736 2720 2704 2688 2672 2656 2640 2624 2608 2592 2576 2560 2544 2528 2512 2496 2480 2464 2448 2432 2416 2400 2384 2368 2352 2336 2320 2304 2288 2272 2256 2240 2224 2208 2192 2176 2160 2144 2128 2112 2096 2080 2064 2048 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 
 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16

#0  doadump () at pcpu.h:165
165	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0672901 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2  0xc0672c59 in panic (fmt=0xc087f113 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:558
#3  0xc08493e6 in trap_fatal (frame=0xeb9a7b58, eva=0)
    at /usr/src/sys/i386/i386/trap.c:836
#4  0xc08490ef in trap_pfault (frame=0xeb9a7b58, usermode=0, eva=0)
    at /usr/src/sys/i386/i386/trap.c:744
#5  0xc0848d05 in trap (frame=
      {tf_fs = -916914168, tf_es = -916914136, tf_ds = -896335832, tf_edi = -917610112, tf_esi = -342197140, tf_ebp = -342197300, tf_isp = -342197372, tf_ebx = 4, tf_edx = -919717272, tf_ecx = -917610156, tf_eax = -1064162880, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 32, tf_eflags = 66118, tf_esp = -1067102273, tf_ss = -917610156}) at /usr/src/sys/i386/i386/trap.c:434
#6  0xc08361fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0x00000000 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
root@cache3:/usr/src# exit

The panics seems to happen when load is low as well as high.

>How-To-Repeat:

Install FreeBSD 6.1, and then ports/www/squid26:

cd /usr/ports/www/squid26
make SQUID_CONFIGURE_ARGS="--enable-dlmalloc --enable-snmp --enable-async-io=50"
 WITH_SQUID_AUFS=yes OPTIONS="" install

Set up some aufs cache dirs on different disks (I am using SCSI disks in HP
Proliant DL 380):

cache_dir aufs /data/cache 15000 64 512
cache_dir aufs /data01/cache 15000 64 512
cache_dir aufs /data02/cache 15000 64 512
cache_dir aufs /data03/cache 15000 64 512
cache_dir aufs /data04/cache 15000 64 512

	
>Fix:
N/A

I am going to be trying libthr(3), meanwhile, to see if I can avoid the
problem then.

Let me know if there is anything more I can do to help debug the problem.
>Release-Note:
>Audit-Trail:

From: Anders Nordby <anders@FreeBSD.org>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org
Cc: Suleiman Souhlal <ssouhlal@FreeBSD.org>,
	Pawel Worach <pawel.worach@gmail.com>
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Tue, 12 Sep 2006 21:55:47 +0200

 Using libthr instead of pthread didn't help at all.
 
 It might be a kqueue issue after all. On recommendation by Pawel Worach,
 I set these sysctls:
 
 debug.trace_on_panic=1
 debug.debugger_on_panic=0
 
 Then I could get more debugging info:
 
 # dmesg -M /var/crash/vmcore.0 -N /usr/obj/usr/src/sys/CACHE/kernel.debug
 (..)
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 06
 fault virtual address   = 0x0
 fault code              = supervisor read, page not present
 instruction pointer     = 0x20:0x0
 stack pointer           = 0x28:0xeb886b98
 frame pointer           = 0x28:0xeb886bcc
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 545 (squid)
 trap number             = 12
 panic: page fault
 cpuid = 0
 KDB: stack backtrace:
 kdb_backtrace(100,c9599480,28,eb886b58,c) at kdb_backtrace+0x29
 panic(c087f113,c08ce651,0,fffff,c959d49b) at panic+0x114
 trap_fatal(eb886b58,0,c9599480,c8f8a708,c) at trap_fatal+0x2ce
 trap_pfault(eb886b58,0,0) at trap_pfault+0x1d7
 trap(8,c9590028,ce020028,c9feb0b4,eb886c30) at trap+0x2fd
 calltrap() at calltrap+0x5
 --- trap 0xc, eip = 0, esp = 0xeb886b98, ebp = 0xeb886bcc ---
 (null)(c9560800,eb886c1c,c9599480,1,0) at 0
 kern_kevent(c9599480,3,37,80,eb886cc8) at kern_kevent+0xc9
 kevent(c9599480,eb886d04,6,4bacc,202) at kevent+0x55
 syscall(3b,3b,bfbf003b,82180b1,0) at syscall+0x2bf
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (363, FreeBSD ELF32, kevent), eip = 0xb71e24af, esp =
 0xbfbfe9cc, ebp = 0xbfbfea18 ---
 Uptime: 21h18m39s
 Dumping 3839 MB (2 chunks)
   chunk 0: 1MB (159 pages) ... ok
   chunk 1: 3839MB (982778 pages) 3824 3808 3792 3776 3760 3744 3728 3712
 3696 3680 3664 3648 3632 3616 3600 3584 3568 3552 3536 3520 3504 3488
 3472 3456 3440 3424 3408 3392 3376 3360 3344 3328 3312 3296 3280 3264
 3248 3232 3216 3200 3184 3168 3152 3136 3120 3104 3088 3072 3056 3040
 3024 3008 2992 2976 2960 2944 2928 2912 2896 2880 2864 2848 2832 2816
 2800 2784 2768 2752 2736 2720 2704 2688 2672 2656 2640 2624 2608 2592
 2576 2560 2544 2528 2512 2496 2480 2464 2448 2432 2416 2400 2384 2368
 2352 2336 2320 2304 2288 2272 2256 2240 2224 2208 2192 2176 2160 2144
 2128 2112 2096 2080 2064 2048 2032 2016 2000 1984 1968 1952 1936 1920
 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696
 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472
 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248
 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024
 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736
 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448
 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160
 144 128 112 96 80 64 48 32 16
 
 Checking those kevent's, I get:
 
 (kgdb) l *kevent+0x55
 0xc06542fd is in kevent (/usr/src/sys/kern/kern_event.c:571).
 566                             return (error);
 567                     tsp = &ts;
 568             } else
 569                     tsp = NULL;
 570
 571             return (kern_kevent(td, uap->fd, uap->nchanges,
 uap->nevents,
 572                 &k_ops, tsp));
 573     }
 574
 575     /*
 (kgdb) l *kern_kevent+0xc9
 0xc0654439 is in kern_kevent (/usr/src/sys/kern/kern_event.c:637).
 632                             goto done;
 633                     changes = keva;
 634                     for (i = 0; i < n; i++) {
 635                             kevp = &changes[i];
 636                             kevp->flags &= ~EV_SYSFLAGS;
 637                             error = kqueue_register(kq, kevp, td,
 1);
 638                             if (error) {
 639                                     if (nevents != 0) {
 640                                             kevp->flags = EV_ERROR;
 641                                             kevp->data = error;
 (kgdb) 
 
 This is in FreeBSD 6.1-RELEASE-p5. One physical processor, but two logical
 (HyperThreading enabled).
 
 Regards,
 Anders.

From: Anders Nordby <anders@fupp.net>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org
Cc: Suleiman Souhlal <ssouhlal@FreeBSD.org>,
	Pawel Worach <pawel.worach@gmail.com>,
	Thomas-Martin Seck <tmseck@netcologne.de>
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Wed, 13 Sep 2006 20:58:03 +0200

 --LZvS9be/3tNcYl/X
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Hi,
 
 After talking with Pawel, I tried the attached patch to get some kqueue
 debug info. I just got it:
 
 Sep 13 20:18:56 cache3 kernel: NULL f_event in new kn
 Sep 13 20:18:56 cache3 kernel: f_event == NULL
 
 Then Squid stops responding to new requests, and I can not even kill it
 with kill -9:
 
 root@cache3:~# pgrep -l squid
 547 squid
 root@cache3:~# kill -9 547
 root@cache3:~# pgrep -l squid
 547 squid
 
 Have to reboot to get the system working again, but it seems now it
 doesn't panic.
 
 Regards,
 
 -- 
 Anders.
 
 --LZvS9be/3tNcYl/X
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="kqueue-debug.patch"
 
 --- sys/kern/kern_event.c.orig	Wed Sep 13 08:44:57 2006
 +++ sys/kern/kern_event.c	Wed Sep 13 08:51:03 2006
 @@ -900,6 +900,8 @@
  				goto done;
  			}
  			KN_LIST_LOCK(kn);
 +			if (kn->kn_fop->f_event == NULL)
 +				printf("NULL f_event in new kn\n");
  		} else {
  			/*
  			 * The user may change some filter values after the
 @@ -912,6 +914,8 @@
  			kn->kn_sfflags = kev->fflags;
  			kn->kn_sdata = kev->data;
  			kn->kn_kevent.udata = kev->udata;
 +			if (kn->kn_fop->f_event == NULL)
 +				printf("NULL f_event in existing kn\n");
  		}
  
  		/*
 @@ -921,6 +925,12 @@
  		 * is called on a zombie process.  It will call filt_proc
  		 * which will remove it from the list, and NULL kn_knlist.
  		 */
 +		if (kn->kn_fop->f_event == NULL) {
 +			printf("f_event == NULL\n");
 +			KN_LIST_UNLOCK(kn);
 +			error = EAGAIN;
 +			goto done;
 +		}
  		event = kn->kn_fop->f_event(kn, 0);
  		KQ_LOCK(kq);
  		if (event)
 
 --LZvS9be/3tNcYl/X--

From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Anders Nordby <anders@fupp.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org,
        Thomas-Martin Seck <tmseck@netcologne.de>,
        Suleiman Souhlal <ssouhlal@FreeBSD.org>
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Sat, 16 Sep 2006 13:50:44 -0700

 Anders Nordby wrote this message on Wed, Sep 13, 2006 at 20:58 +0200:
 > After talking with Pawel, I tried the attached patch to get some kqueue
 > debug info. I just got it:
 > 
 > Sep 13 20:18:56 cache3 kernel: NULL f_event in new kn
 > Sep 13 20:18:56 cache3 kernel: f_event == NULL
 
 This means that the f_attach method for that event isn't setting f_event
 properly...  We need to figure out which event this is happening w/...
 
 Try the following modifications:
 > --- sys/kern/kern_event.c.orig	Wed Sep 13 08:44:57 2006
 > +++ sys/kern/kern_event.c	Wed Sep 13 08:51:03 2006
 > @@ -900,6 +900,8 @@
 >  				goto done;
 >  			}
 >  			KN_LIST_LOCK(kn);
 > +			if (kn->kn_fop->f_event == NULL)
  {
 > +				printf("NULL f_event in new kn\n");
 			printf("kn: ident: %d, filter: %d\n", kn->kn_ident, kn->kn_filter);
 }
 >  		} else {
 >  			/*
 >  			 * The user may change some filter values after the
 
 I have a feeling that this is a similar panic that jhb is seeing...
 Which means that filter will be EVFILT_VNODE (-4)...
 
 -- 
   John-Mark Gurney				Voice: +1 415 225 5579
 
      "All that I will do, has been done, All that I have, has not."

From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Anders Nordby <anders@fupp.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org,
        Thomas-Martin Seck <tmseck@netcologne.de>,
        Suleiman Souhlal <ssouhlal@FreeBSD.org>
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Sat, 16 Sep 2006 13:59:08 -0700

 --oC1+HKm2/end4ao3
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Anders Nordby wrote this message on Wed, Sep 13, 2006 at 20:58 +0200:
 > After talking with Pawel, I tried the attached patch to get some kqueue
 > debug info. I just got it:
 > 
 > Sep 13 20:18:56 cache3 kernel: NULL f_event in new kn
 > Sep 13 20:18:56 cache3 kernel: f_event == NULL
 > 
 > Then Squid stops responding to new requests, and I can not even kill it
 > with kill -9:
 
 Please try the attached patch.. It appears that the badfo_kqfilter was
 returning sucess instead of error since it was introcuded many years
 ago...  This many still cause other problems w/ squid, but will fix
 the panics...
 
 -- 
   John-Mark Gurney				Voice: +1 415 225 5579
 
      "All that I will do, has been done, All that I have, has not."
 
 --oC1+HKm2/end4ao3
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="badfo_kqfilter.patch"
 
 Index: kern_descrip.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
 retrieving revision 1.297
 diff -u -r1.297 kern_descrip.c
 --- kern_descrip.c	21 Jul 2006 20:24:00 -0000	1.297
 +++ kern_descrip.c	16 Sep 2006 20:58:40 -0000
 @@ -2632,7 +2632,7 @@
  badfo_kqfilter(struct file *fp, struct knote *kn)
  {
  
 -	return (0);
 +	return (EINVAL);
  }
  
  static int
 
 --oC1+HKm2/end4ao3--

From: Anders Nordby <anders@fupp.net>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org,
	Thomas-Martin Seck <tmseck@netcologne.de>,
	Suleiman Souhlal <ssouhlal@FreeBSD.org>,
	John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Cc: jhb@FreeBSD.org
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Mon, 18 Sep 2006 10:33:43 +0200

 Hi,
 
 On Sat, Sep 16, 2006 at 01:50:44PM -0700, John-Mark Gurney wrote:
 >> After talking with Pawel, I tried the attached patch to get some kqueue
 >> debug info. I just got it:
 >> 
 >> Sep 13 20:18:56 cache3 kernel: NULL f_event in new kn
 >> Sep 13 20:18:56 cache3 kernel: f_event == NULL
 > 
 > This means that the f_attach method for that event isn't setting f_event
 > properly...  We need to figure out which event this is happening w/...
 > 
 > Try the following modifications:
 >> (..)
 > > +			if (kn->kn_fop->f_event == NULL)
 >  {
 > > +				printf("NULL f_event in new kn\n");
 
 This modification was already done with the patch from Pawel, check the
 audit-trail of this PR. By using that patch, I got the messages "NULL
 f_event in new kn" and "f_event == NULL".
 
 Cheers,
 
 -- 
 Anders.

From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Anders Nordby <anders@fupp.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org,
        Thomas-Martin Seck <tmseck@netcologne.de>,
        Suleiman Souhlal <ssouhlal@FreeBSD.org>, jhb@FreeBSD.org
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Mon, 18 Sep 2006 09:27:36 -0700

 Anders Nordby wrote this message on Mon, Sep 18, 2006 at 10:33 +0200:
 > Hi,
 > 
 > On Sat, Sep 16, 2006 at 01:50:44PM -0700, John-Mark Gurney wrote:
 > >> After talking with Pawel, I tried the attached patch to get some kqueue
 > >> debug info. I just got it:
 > >> 
 > >> Sep 13 20:18:56 cache3 kernel: NULL f_event in new kn
 > >> Sep 13 20:18:56 cache3 kernel: f_event == NULL
 > > 
 > > This means that the f_attach method for that event isn't setting f_event
 > > properly...  We need to figure out which event this is happening w/...
 > > 
 > > Try the following modifications:
 > >> (..)
 > > > +			if (kn->kn_fop->f_event == NULL)
 > >  {
     ^^^
 > > > +				printf("NULL f_event in new kn\n");
 > 
 > This modification was already done with the patch from Pawel, check the
 > audit-trail of this PR. By using that patch, I got the messages "NULL
 > f_event in new kn" and "f_event == NULL".
 
 You missed my modifications to the patch...  They were done in addition
 to his patch, and as I said in that email, they should fix the problem,
 it's not an information gathering exercise...
 
 -- 
   John-Mark Gurney				Voice: +1 415 225 5579
 
      "All that I will do, has been done, All that I have, has not."
State-Changed-From-To: open->feedback 
State-Changed-By: jmg 
State-Changed-When: Wed Sep 20 21:04:55 UTC 2006 
State-Changed-Why:  
waiting for people to test the patch of badfo_kqfilter that is attached 
to the bug.. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=103127 

From: Anders Nordby <anders@fupp.net>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-threads@FreeBSD.org,
	Thomas-Martin Seck <tmseck@netcologne.de>,
	Suleiman Souhlal <ssouhlal@FreeBSD.org>
Cc:  
Subject: Re: threads/103127: Kernel panic while using thread features in Squid 2.6
Date: Thu, 21 Sep 2006 09:24:09 +0200

 Hi,
 
 On Sat, Sep 16, 2006 at 01:59:08PM -0700, John-Mark Gurney wrote:
 > Please try the attached patch.. It appears that the badfo_kqfilter was
 > returning sucess instead of error since it was introcuded many years
 > ago...  This many still cause other problems w/ squid, but will fix
 > the panics...
 > --- kern_descrip.c	21 Jul 2006 20:24:00 -0000	1.297
 > +++ kern_descrip.c	16 Sep 2006 20:58:40 -0000
 > @@ -2632,7 +2632,7 @@
 >  badfo_kqfilter(struct file *fp, struct knote *kn)
 >  {
 >  
 > -	return (0);
 > +	return (EINVAL);
 >  }
 >  
 >  static int
 
 This patch fixes the kernel panics that I have reported about in this
 PR. I have 9 cache servers with Squid2.6 that had this problem. After
 patching them, one by one, they haven't had any panics anymore.
 
 Cheers,
 
 -- 
 Anders.
Responsible-Changed-From-To: freebsd-threads->jmg 
Responsible-Changed-By: jmg 
Responsible-Changed-When: Fri Sep 22 20:43:26 UTC 2006 
Responsible-Changed-Why:  
I have a patch for this, which once we decide the correct return value 
will be committed... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=103127 
State-Changed-From-To: feedback->patched 
State-Changed-By: jmg 
State-Changed-When: Sun Sep 24 02:30:09 UTC 2006 
State-Changed-Why:  
I'll MFC this shortly... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=103127 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/103127: commit references a PR
Date: Sun, 24 Sep 2006 02:30:00 +0000 (UTC)

 jmg         2006-09-24 02:29:53 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/kern             kern_descrip.c 
   Log:
   return EBADF instead of successfully attaching (and then panicing) when
   an fd is dieing..
   
   Convinced by:   jhb
   PR:             103127
   
   Revision  Changes    Path
   1.298     +1 -1      src/sys/kern/kern_descrip.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: Brett Glass <brett@lariat.net>
To: bug-followup@FreeBSD.org, anders@FreeBSD.org
Cc:  
Subject: Re: kern/103127: Kernel panic while using thread features in
  Squid 2.6
Date: Sun, 24 Sep 2006 13:38:07 -0600

 So, the change will be to return EBADF (rather than EINVAL) from the function
 badfo_kqfilter.... Correct? (I need to know this because I have an 
 immediate need to patch a kernel to stop crashes.) Will this patch 
 make it into 6.2-BETA2? Into 6.2-RC1?
 
 --Brett Glass
 
State-Changed-From-To: patched->closed 
State-Changed-By: jmg 
State-Changed-When: Sat Oct 7 19:15:29 UTC 2006 
State-Changed-Why:  
this has been MFC'd, it's closed 

Reminded by:	pav 

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