From owner-freebsd-bugs@FreeBSD.ORG Tue Feb 18 20:00:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9633AAA2 for ; Tue, 18 Feb 2014 20:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8238E1D88 for ; Tue, 18 Feb 2014 20:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1IK01dm075303 for ; Tue, 18 Feb 2014 20:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1IK01X1075300; Tue, 18 Feb 2014 20:00:01 GMT (envelope-from gnats) Date: Tue, 18 Feb 2014 20:00:01 GMT Message-Id: <201402182000.s1IK01X1075300@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/163585: cpuset(1) by twice kill SMP functionality X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: John Baldwin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:00:01 -0000 The following reply was made to PR kern/163585; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, olevole@olevole.ru Cc: Subject: Re: kern/163585: cpuset(1) by twice kill SMP functionality Date: Tue, 18 Feb 2014 14:49:25 -0500 I suspect you were using 'cpuset -c -l N -p ' rather than 'cpuset -l N -p ' in which case this is working as designed. When you use '-c', you change the mask of the global cpuset that the process belongs to, not the mask that is private to the process itself. The cpuminer bug referenced was exactly due to this (it was using CPU_WHICH_CPUSET incorrectly which is identical to using cpuset -c) -- John Baldwin