From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 7 18:30:42 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730A51065675 for ; Mon, 7 Jul 2008 18:30:42 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 346EA8FC2B for ; Mon, 7 Jul 2008 18:30:41 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 07 Jul 2008 03:27:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.30,317,1212390000"; d="scan'208,217";a="303800667" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga002.jf.intel.com with ESMTP; 07 Jul 2008 11:31:28 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 11:30:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 11:30:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug in calcru in he 6.2 and 6.3 kernels Thread-Index: AcjgX4549npikuUFTkSt0ltL0OdqBA== From: "Murty, Ravi" To: X-OriginalArrivalTime: 07 Jul 2008 18:30:40.0480 (UTC) FILETIME=[8EF20600:01C8E05F] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Bug in calcru in he 6.2 and 6.3 kernels X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 18:30:42 -0000 Hello everyone, =20 Finally found what my last problem was. We were running top in a loop and running some workloads that called sched_bind() to bind threads to specific CPUs. The problem was that (and I am using ULE) sched_bind calls a function to notify another CPU of a thread and then mi_switches out of it. Since mi_switch sets the "oncpu" field of the thread to NOCPU and given the thread is still running, calcru would come in and assert the fact that "If I am running I better no be on NOCPU".. It appears that in other parts of the kernel (e.g. forward_signal) this is acceptable (i.e. it is okay to be running and oncpu is NOCPU).=20 =20 Thanks Ravi =20