From owner-freebsd-scsi@FreeBSD.ORG Fri Jul 5 14:20:01 2013 Return-Path: Delivered-To: freebsd-scsi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5E6C7E for ; Fri, 5 Jul 2013 14:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 86F431F89 for ; Fri, 5 Jul 2013 14:20: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 r65EK0kP083947 for ; Fri, 5 Jul 2013 14:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r65EK03e083946; Fri, 5 Jul 2013 14:20:00 GMT (envelope-from gnats) Date: Fri, 5 Jul 2013 14:20:00 GMT Message-Id: <201307051420.r65EK03e083946@freefall.freebsd.org> To: freebsd-scsi@FreeBSD.org Cc: From: Markus Gebert Subject: Re: kern/179932: [ciss] ciss i/o stall problem with HP Bl Gen8 (and HP Bl Gen7 + Storage Blade) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Markus Gebert List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:20:01 -0000 The following reply was made to PR kern/179932; it has been noted by GNATS. From: Markus Gebert To: Steven Hartland Cc: freebsd-scsi@FreeBSD.org, "bug-followup@FreeBSD.org" Subject: Re: kern/179932: [ciss] ciss i/o stall problem with HP Bl Gen8 (and HP Bl Gen7 + Storage Blade) Date: Fri, 5 Jul 2013 16:14:26 +0200 --Apple-Mail=_9D4196B5-B411-44BB-BDE1-8695E2E76451 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Steven Thanks for your input. On 05.07.2013, at 15:43, Steven Hartland = wrote: > Might also want to get the output from "show sleepchain" for all = threads > too as that will easily identify sleep lock dead locks. Is there an easy way to do this for all threads with one command? The = first server that crashed had 800 threads=85 If not, we should probably = script this outside of ddb using thread ids from the alltrace output. Or = is there a subset of threads you're particularly interested in? > Also whats the check_disk process? This is Nagios' check_disk plugin we use to check the filesystem usage = on all mountpoints. It runs quite frequently, that's why multiple may be = get started until we notice and break into the debugger. Markus --Apple-Mail=_9D4196B5-B411-44BB-BDE1-8695E2E76451 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 killing@multiplay.co.uk> = wrote:

too as that will easily identify sleep = lock dead locks.

Is = there an easy way to do this for all threads with one command? The first = server that crashed had 800 threads=85 If not, we should probably script = this outside of ddb using thread ids from the alltrace output. Or is = there a subset of threads you're particularly interested = in?

Also whats the check_disk = process?

This is Nagios' check_disk = plugin we use to check the filesystem usage on all mountpoints. It runs = quite frequently, that's why multiple may be get started until we notice = and break into the = debugger.

Markus

= --Apple-Mail=_9D4196B5-B411-44BB-BDE1-8695E2E76451--