From owner-freebsd-bugs@freebsd.org Thu May 11 15:05:43 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2DC4D68D71 for ; Thu, 11 May 2017 15:05:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2B98D70 for ; Thu, 11 May 2017 15:05:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4BF5hTX066862 for ; Thu, 11 May 2017 15:05:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219216] sched_bind() blocks if the entropy pool is starved Date: Thu, 11 May 2017 15:05:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:05:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219216 --- Comment #1 from Konstantin Belousov --- The description of the problem is not very useful. When the panic 'spinlock held too long' occurs, presumably for the sched lo= cks, catch exact kernel messages (same as you did) and also the backtrace for the thread which is reported as the owner of the spinlock. I will see if more information is needed after that. Note that if CPU speed is artificially reduced, then spinlock sections might take much longer time to execute, which would, in turn, trigger the detector for the stuck spinlock. I do not claim that this is your case, but it could be. sched_bind() does not depend on rnd. --=20 You are receiving this mail because: You are the assignee for the bug.=