From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 14:33:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 466C316A4CE; Fri, 1 Oct 2004 14:33:58 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF2043D41; Fri, 1 Oct 2004 14:33:57 +0000 (GMT) (envelope-from scottl@FreeBSD.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i91EYrUb077936; Fri, 1 Oct 2004 08:34:53 -0600 (MDT) (envelope-from scottl@FreeBSD.org) Message-ID: <415D6A9E.5030903@FreeBSD.org> Date: Fri, 01 Oct 2004 08:33:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <200410010741.i917fJUo076107@pooker.samsco.org> <20041001083144.GT39252@elvis.mu.org> In-Reply-To: <20041001083144.GT39252@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: re@FreeBSD.org cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 14:33:58 -0000 Alfred Perlstein wrote: > * Scott Long [041001 00:40] wrote: > >> | if_em wedging under | | | "wedging" under | >> | high pps | Not done | - | high | > > > I've seen this for months... > mlaier figured this one out. Hopefully we can MFC it today for BETA7. > >> |------------------+-------------+----------------+----------------------| >> | | | | A process cannot be | >> | | | | interrupted while | >> | | | | waiting on a lock. | >> | rpc.lockd(8) | | | Fixing this requires | >> | stability | -- | -- | that the RPC code be | >> | | | | taught how to deal | >> | | | | with lock | >> | | | | cancellation and | >> | | | | interruption events. | > > > Thinking about it... I think Darwin has the fix, I'll see if I can > merge it. > That would be wonderful! > >> |------------------+-------------+----------------+----------------------| >> | | | | Truss appears to | >> | | | | have another | >> | | | | problem. It is | >> | | | | repeatable by | >> | | | | running "truss -f | >> | More truss | Not done | -- | fsck -p /", | >> | problems | | | suspending it with | >> | | | | ^Z, and then killing | >> | | | | truss. It will leave | >> | | | | behind the fsck | >> | | | | processes which will | >> | | | | be unkillable. | > > > This fixes it: > > Index: kern_sig.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v > retrieving revision 1.290 > diff -u -r1.290 kern_sig.c > --- kern_sig.c 31 Aug 2004 07:34:53 -0000 1.290 > +++ kern_sig.c 1 Oct 2004 08:27:12 -0000 > @@ -1775,6 +1775,16 @@ > !((prop & SA_CONT) && (p->p_flag & P_STOPPED_SIG))) > return; > /* > + * SIGKILL: Remove procfs STOPEVENTs. > + */ > + if (sig == SIGKILL) { > + /* from procfs_ioctl.c: PIOCBIC */ > + p->p_stops = 0; > + /* from procfs_ioctl.c: PIOCCONT */ > + p->p_step = 0; > + wakeup(&p->p_step); > + } > + /* > * Some signals have a process-wide effect and a per-thread > * component. Most processing occurs when the process next > * tries to cross the user boundary, however there are some > I see that you already committed this, thanks! Let it settle for a few days and we'll get it into RC1. > > >> | | | | The LOR reported in | >> | | | | PR kern/55175 needs | >> | filedesc LOR | Not done | -- | to be fixed. | >> | | | | Filedesc locking | >> | | | | needs to be heavily | >> | | | | reviewed in general. | > > > Oy this thing... :) > > The only thing blocking this was that we need to access the filedesc > as the process shuts down for nfs locks, Darwin has a workaround that > I'll see if i can incorporate. > Is this one still actually a problem? I haven't seen anyone complain about it in months. Scott