From owner-freebsd-scsi@FreeBSD.ORG Mon Aug 4 11:56:36 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14C3038F for ; Mon, 4 Aug 2014 11:56:36 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id CB8652B24; Mon, 4 Aug 2014 11:56:34 +0000 (UTC) Message-ID: <53DF74CA.1060201@FreeBSD.org> Date: Mon, 04 Aug 2014 15:55:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sumit Saxena , John-Mark Gurney Subject: Re: Kernel panic: message secondary GPT header is not in the last LBA References: <559aba5a124ee1e32ddffb1380399e28@mail.gmail.com> <20140624130840.GK1560@funkthat.com> <6f92e2e229eaea86429826ce5085e495@mail.gmail.com> <20140710092108.GU45513@funkthat.com> c0e8d27445599f47adb6df0eb5465882@mail.gmail.com <0c7840168feaf80c91d4e9067d916998@mail.gmail.com> c3f72a4da049262aa68d61cf6ddab59b@mail.gmail.com In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, Kashyap Desai X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 11:56:36 -0000 On 01.08.2014 09:15, Sumit Saxena wrote: >>>>> Can you run: >>>>> addr2line -e /boot/kernel/kernel.symbols 0xffffffff80803574 Hi, You didn't show the result of the above command. >>>>> This should give us the line number that the panic is happening on, >>>>> and help debug it.. >>>>> >>>>> Also, is this FreeBSD 10.0-R? or is there a patch level associated w/ >>>>> it? Easiest way to figure out is to include uname -a in the email so >>>>> we know exactly what kernel source you are using.. >>> >>> I am using releases FreeBSD 10.0, no patch on top of that. >>>> >>>> Thanks for your help. I am able to capture vmcore on kenel panic, but >>> can't >>>> share that over overmail(size is 386MB) and does not have any common >>>> location to share vmcore with you. >>>> Do you have any common location, where I can share vmcore. Meanwhile I >>>> will also do some debugging from my end also. Any pointers from you >>>> for debugging the vmcore will be highly appreciated, as I am keen to >>>> learn FreebSD kernel debugging techniques. >>>> I have attached core.txt for your reference. The core.txt was almost empty. >>> I have observed that the issue hits, if there are some drives with GPT >>> partition are attached to the controller. >> >> Has anyone observed the same issue, when there are drives present in the >> setup with GPT partitions? > Gentle ping!! -- WBR, Andrey V. Elsukov From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 6 19:46:37 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC66DCCE; Wed, 6 Aug 2014 19:46:37 +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 5CC5D2BD4; Wed, 6 Aug 2014 19:46:36 +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 s76JkYrY078648; Wed, 6 Aug 2014 15:46:34 -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 s76JkYY6078645; Wed, 6 Aug 2014 15:46:34 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21474.34330.572142.206098@hergotha.csail.mit.edu> Date: Wed, 6 Aug 2014 15:46:34 -0400 From: Garrett Wollman To: freebsd-stable@freebsd.org Subject: 9.3-RELEASE still instapanics on multi-mps(4) servers X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid 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 15:46:34 -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 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 19:46:37 -0000 Remember about six months ago when I tested 9-stable on one of my big NFS servers, and had it panic in the middle of the USB probe, but ultimately bisected the problem to an update to the mps(4) driver? I had to stop investigating and get the server working (which I did, by installing 9.2 instead of something newer and presumably faster). I'm at the point now where I'd like to upgrade my file servers to 9.3, and I can't, because of this issue, so it's time to start tracking down the bug again. I have two test servers now. 9.3 works just fine on one of them, and panics on the other. The one it works on is slightly older, and has an mpt(4) controller for the boot drives, as opposed to the system where the panic happens, which is mps(4)-only. Both systems have two SAS2116 controllers for external drives; the ones on the working system have drives attached, and the ones on the non-working system are not connected to anything (and in fact disabled in the BIOS for now). Any experts want to suggest where to start (besides, obviously, attaching a serial console, which I haven't done yet)? I saw one change in the svn logs for 9.3 prior to the release which looked like it might be a relevant fix, but it clearly hasn't improved anything for my servers. -GAWollman From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 6 20:26:50 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46716518; Wed, 6 Aug 2014 20:26:50 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1E22162; Wed, 6 Aug 2014 20:26:49 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6BA5D20E7088C; Wed, 6 Aug 2014 20:26:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 0FC0A20E70885; Wed, 6 Aug 2014 20:26:37 +0000 (UTC) Message-ID: <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk> From: "Steven Hartland" To: "Garrett Wollman" , References: <21474.34330.572142.206098@hergotha.csail.mit.edu> Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers Date: Wed, 6 Aug 2014 21:26:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:26:50 -0000 The stack from the panic would be a good start. ----- Original Message ----- From: "Garrett Wollman" To: Cc: Sent: Wednesday, August 06, 2014 8:46 PM Subject: 9.3-RELEASE still instapanics on multi-mps(4) servers > Remember about six months ago when I tested 9-stable on one of my big > NFS servers, and had it panic in the middle of the USB probe, but > ultimately bisected the problem to an update to the mps(4) driver? I > had to stop investigating and get the server working (which I did, by > installing 9.2 instead of something newer and presumably faster). I'm > at the point now where I'd like to upgrade my file servers to 9.3, and > I can't, because of this issue, so it's time to start tracking down > the bug again. > > I have two test servers now. 9.3 works just fine on one of them, and > panics on the other. The one it works on is slightly older, and has > an mpt(4) controller for the boot drives, as opposed to the system > where the panic happens, which is mps(4)-only. Both systems have two > SAS2116 controllers for external drives; the ones on the working > system have drives attached, and the ones on the non-working system > are not connected to anything (and in fact disabled in the BIOS for > now). > > Any experts want to suggest where to start (besides, obviously, > attaching a serial console, which I haven't done yet)? I saw one > change in the svn logs for 9.3 prior to the release which looked like > it might be a relevant fix, but it clearly hasn't improved anything > for my servers. > > -GAWollman > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 6 21:10:54 2014 Return-Path: Delivered-To: freebsd-scsi@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-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 6 21:33:40 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD69E12B; Wed, 6 Aug 2014 21:33:40 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 71D3D2B10; Wed, 6 Aug 2014 21:33:40 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 9121920E7088B; Wed, 6 Aug 2014 21:33:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN, RDNS_DYNAMIC, STOX_REPLY_TYPE, TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 992EB20E70885; Wed, 6 Aug 2014 21:33:34 +0000 (UTC) Message-ID: From: "Steven Hartland" To: References: <21474.34330.572142.206098@hergotha.csail.mit.edu> <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk> <201408062110.s76LAhhE079487@hergotha.csail.mit.edu> Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers Date: Wed, 6 Aug 2014 22:33:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 21:33:40 -0000 TBH that sounds like dodgy hardware. We had a similar thing a few years back with a machine which would panic mfi badly all the time where as other machines where solid as a rock. If its random then you could be facing the same thing. I our case it turned out to be a faulty Intel CPU. There where on other signs of issues just random panic in mfi. So given the similarity and you said it only effects one out of two machines have the HW replaced and see if the problem goes away. Regards Stev ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, August 06, 2014 10:10 PM Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers > 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 > > From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 7 02:26:37 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AECEEFC for ; Thu, 7 Aug 2014 02:26:37 +0000 (UTC) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51D202F7D for ; Thu, 7 Aug 2014 02:26:36 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id k15so3439255qaq.13 for ; Wed, 06 Aug 2014 19:26:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=baXJlnJOdv+fSB9iLTza93S1AzAzgx3zU8cX5i/N5Go=; b=DRI6pbCAZ8e/PfHy8Nlc0ez73S5+aYJLo+bgPOgqoN6QzeKcDddXAf7y/ZxWgKP9qh 76k7cYusY7WzRugYGig7PzURBrEaiu2lSgo9EMXz10O6n0hABlRvLmJ9Zc4IwY30C9yZ 4IXdSYCDT6fXMYof171QqvNJJ6VrrIdjKI7QTZXYwq5ckCYJWcUPFhNNRidV8dSzHWxb c/BaAe5LML6hvBEqRU8r2VP74rzvQHloSoY/w9QTdtnQ5BorfBdPx5ROC1ie97T98nWl WowVj5P4IsfgYJ70zMr9gvglAeSmyguK71kE1Dzb03jrxqiYP1BObol4PE1FUCTseEay ydig== X-Gm-Message-State: ALoCoQkCn6fbsWOnTermHOtbyGJzljBTtLcgGMvpKwhoC2fhPPO386yOqEkK1uztUF0xlKVHWMb8 X-Received: by 10.140.43.245 with SMTP id e108mr8689388qga.76.1407378395357; Wed, 06 Aug 2014 19:26:35 -0700 (PDT) Received: from [97.62.248.155] (155.sub-97-62-248.myvzw.com. [97.62.248.155]) by mx.google.com with ESMTPSA id k6sm874951qgf.5.2014.08.06.19.26.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 19:26:33 -0700 (PDT) References: <21474.34330.572142.206098@hergotha.csail.mit.edu> <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk> <201408062110.s76LAhhE079487@hergotha.csail.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <45558B49-C3DD-4FD0-8E04-38BC30A1AC35@longcount.org> X-Mailer: iPhone Mail (11D257) From: Mark Saad Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers Date: Wed, 6 Aug 2014 22:26:23 -0400 To: Steven Hartland Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-scsi@freebsd.org" , "freebsd-stable@freebsd.org" , "" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 02:26:37 -0000 > On Aug 6, 2014, at 5:33 PM, "Steven Hartland" wr= ote: >=20 > TBH that sounds like dodgy hardware. We had a similar thing a few years > back with a machine which would panic mfi badly all the time where as > other machines where solid as a rock. >=20 Why details can you provide about the hardware ? Could you upload a dmesg.bo= ot to=20 www.nycbug.org/index.cgi?action=3Ddmesgd&do=3Dhome > If its random then you could be facing the same thing. >=20 > I our case it turned out to be a faulty Intel CPU. There where on other > signs of issues just random panic in mfi. >=20 > So given the similarity and you said it only effects one out of two machin= es > have the HW replaced and see if the problem goes away. >=20 > Regards > Stev >=20 > ----- Original Message ----- From: > To: > Cc: ; > Sent: Wednesday, August 06, 2014 10:10 PM > Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers >=20 >=20 >> 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Mark saad | mark.saad@longcount.org=20=