From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 20 16:11:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0558106564A; Mon, 20 Jun 2011 16:11:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AD6DD8FC13; Mon, 20 Jun 2011 16:11:47 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5KG7lNo063175 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2011 10:07:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201106200849.10862.jhb@freebsd.org> Date: Mon, 20 Jun 2011 10:07:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7B9E5AE3-C895-4D07-B923-A2F178B7B9BF@bsdimp.com> References: <201106200849.10862.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 20 Jun 2011 10:07:48 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Ansar Mohammed Subject: Re: Shooting trouble on a PCI bus hang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:11:48 -0000 On Jun 20, 2011, at 6:49 AM, John Baldwin wrote: > On Sunday, June 19, 2011 12:35:49 pm Ansar Mohammed wrote: >> I appreciate that. The system works fine with NetBSD, LInux and = Windows XP, >> so I doubt its hardware. >>=20 >> Interesting though that OpenBSD has the same issue. >>=20 >> A question about the debug kernel load process: as it hangs on * >> pci_print_verbose* in pci.c, can I deduce that this is the exact code >> segment that is the issue? >=20 > Well, if that was the last device on the bus it might be in a device = driver > probe routine. You can try adding more printfs to device_probe(), = etc. to=20 > output each driver name as it probes each device perhaps. We've also had problems with interrupt storms after the drivers have all = probed, and people blame the last printf :) It sounds, however, with the OpenBSD datapoint that something is being = initialized bogusly, perhaps tripping over an erratum that the other = systems avoid or have specific code to work around. Warner=