From owner-freebsd-current@FreeBSD.ORG Sat Aug 8 15:51:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63EB01065673; Sat, 8 Aug 2009 15:51:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id AFA078FC15; Sat, 8 Aug 2009 15:51:20 +0000 (UTC) Received: by fxm24 with SMTP id 24so2282944fxm.36 for ; Sat, 08 Aug 2009 08:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Wf78j3bj4AhyJ3WkOjNgDDcs45ww7olDw6DE4mr3FYA=; b=XRPnWLRc8KI7Jk/j3vqk1MjSe4uoODnGSGP/fYp7Hp93me4BlEcVOon/zp/MPcPkHh TUo5InvRvDQg+cPb+4UqlAUBvF0HKK+GCgHddUSSYoDY1h3C0EWGqng+bGe+DFu/4qkt LQIbtf2lXQrZrpvid+FyJYM1yY5yFod9b7nrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VWFIq/c3eCg1nL/X7A/6jXf0BRFicM6J9YTnvdodhwo7Zkc7HEyLOclCUBYQS/YEJF j3O2h5obCtK9O5X0uU6XjrbEoliwlJe+kejOQvdevh8SpG9vItUJHU7ryvpC8f3ANAA+ 9KrOwsYCEmPytKlzgnzoVe27S9cmkGG7QTSVQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.120.76 with SMTP id c12mr119353far.2.1249746679545; Sat, 08 Aug 2009 08:51:19 -0700 (PDT) In-Reply-To: References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> Date: Sat, 8 Aug 2009 17:51:19 +0200 X-Google-Sender-Auth: 494379ba0939acfd Message-ID: <3bbf2fe10908080851j61efcf67g8e638aff9a9c5ba9@mail.gmail.com> From: Attilio Rao To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marc UBM Bocklet Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 15:51:21 -0000 2009/8/8 Robert Watson : > On Sat, 8 Aug 2009, Marc UBM Bocklet wrote: > >>>>>> I've got it narrowed down between "2009.06.30.06.00.00" and today. A >>>>>> kernel with the "old" date boots, a freshly csupped and compiled kernel >>>>>> hangs with the usual symptoms (waiting for interrupt driven hooks). >>>>>> >>>>>> I'll try csupping to just before the big cam commit to see if there is >>>>>> any connection. When I said earlier that I was not running with the ahci >>>>>> patch, I was partly wrong. I did not have device ahci in my kernel config >>>>>> file nor had it loaded as a module, but I had the patch applied. >>>>> >>>>> "2009.07.09.06.00.00" fixes the problem. Could it be that there are >>>>> some subtle interactions in the cam subsystem that are stirred by the recent >>>>> mega-commit? >>>> >>>> Is there any other info I can / should provide to help debugging this? >>> >>> Any news on this? This pretty much prevents me from running 8.0 :-/ >> >> I've a friend with a similar problem (also HighPoint controller, also "run >> interrupt driven hooks: still waiting for xpt_config"), who gets a panic. >> I'll try to get the panic string and a backtrace, if I do, I'll post it >> here. > > xpt_config basically means that you're waiting on a device driver attached > to CAM to finish probing, which could point at a number of potential problem > sources (including things like interrupt routing problems). At least in the > 7.x line, I've seen firewire and USB at various times cause this issue. It > might be interesting to compile down to the smallest set of cam-related > drivers required to support necessary hardware (omit firewire, for example) > and see if you see any improvement. Pinning it down to a specific driver > would have significant debugging value :-). Beyon that, I think that debugging in CAM can be improved by a good factor using alredy existing general infrastructure (KTR logging points, new ddb commands, etc). We need someone which is willing to spend some time on that. Attilio -- Peace can only be achieved by understanding - A. Einstein