From owner-freebsd-stable@FreeBSD.ORG  Wed Aug  6 21:10:54 2014
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@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 5923552E;
 Wed,  6 Aug 2014 21:10:54 +0000 (UTC)
Received: from hergotha.csail.mit.edu
 (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 15D962742;
 Wed,  6 Aug 2014 21:10:53 +0000 (UTC)
Received: from hergotha.csail.mit.edu (localhost [127.0.0.1])
 by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s76LAh4K079488;
 Wed, 6 Aug 2014 17:10:43 -0400 (EDT)
 (envelope-from wollman@hergotha.csail.mit.edu)
Received: (from wollman@localhost)
 by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s76LAhhE079487;
 Wed, 6 Aug 2014 17:10:43 -0400 (EDT) (envelope-from wollman)
Date: Wed, 6 Aug 2014 17:10:43 -0400 (EDT)
Message-Id: <201408062110.s76LAhhE079487@hergotha.csail.mit.edu>
From: wollman@bimajority.org
To: killing@multiplay.co.uk
Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers
References: <21474.34330.572142.206098@hergotha.csail.mit.edu>
 <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk>
Organization: none
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 06 Aug 2014 17:10:43 -0400 (EDT)
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,
 HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
 hergotha.csail.mit.edu
Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 21:10:54 -0000

In article <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk>,
killing@multiplay.co.uk writes:
>The stack from the panic would be a good start.

As I said, it's in the middle of the USB code, which does not appear,
from my previous bisection, to be connected with the bug at all.  (The
panic is the result of an unhandled trap that happens during
interrupt-driven probing, and it's nearly always in the USB code.  By
loading different modules I can make it happen at slightly different
times and places.)  Six months ago, I found that enabling any form of
memory debugging suppresses the symptoms, although it also kills
performance, of course.  I haven't tried that yet this time around.

Once I get a serial console hooked up I'll be in a better position to
capture the full data (although obviously not a core dump).

-GAWollman