From owner-freebsd-current@FreeBSD.ORG Tue Apr 12 21:39:30 2011 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 C58A71065670; Tue, 12 Apr 2011 21:39:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 918ED8FC16; Tue, 12 Apr 2011 21:39:30 +0000 (UTC) Received: by pxi6 with SMTP id 6so5862pxi.17 for ; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=85VK5oy9JvUPHsgnLAI5DCDGm3/vGskmR9kDxaLWchg=; b=P4AY2DTPCAue6NtUumSGvWgchJruT8mT/czwWkc+oYLYQNhQdRXF0A2Dm7lqMbvAZj 68nurU+YPz7Bs68OfttxDVL9BMGrlE7I5ACphOZMb/GlPQ9dlPEMAUSjprsApczBi0dh HHuw2L7a6pllwfprGfcyQYZ8e4g3DKUjFyCBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dModY+uwUsADg+9j6mZ1SBFP3w3skGtYWsvhyTjKbmEl89EL3aqyVB02+RY1i91s0u +/8XNxp6OH/erhmlSfiNbEr9WaQquDwhsuKDhBoCuz8ebWfYuhIOgDVkkBz2AvEA9a4G N6HTYoYUl4lgn78jQbDpynXpy/1N1/OgcZOGw= MIME-Version: 1.0 Received: by 10.143.153.13 with SMTP id f13mr209395wfo.380.1302644370251; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Tue, 12 Apr 2011 14:39:30 -0700 (PDT) In-Reply-To: <4DA4BF6A.7010806@FreeBSD.org> References: <4DA3EE8F.8050306@FreeBSD.org> <201104122132.23809.naylor.b.david@gmail.com> <4DA4B247.6010901@FreeBSD.org> <20110412210354.GC1421@michelle.cdnetworks.com> <4DA4BF6A.7010806@FreeBSD.org> Date: Tue, 12 Apr 2011 14:39:30 -0700 Message-ID: From: Garrett Cooper To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, FreeBSD-Current , David Naylor Subject: Re: [regression] unable to boot: no GEOM devices found. 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: Tue, 12 Apr 2011 21:39:30 -0000 On Tue, Apr 12, 2011 at 2:08 PM, Alexander Motin wrote: > YongHyeon PYUN wrote: >> On Tue, Apr 12, 2011 at 11:12:55PM +0300, Alexander Motin wrote: >>> David Naylor wrote: >>>> On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: >>>>> David Naylor wrote: >>>>>> I am running -current and since a few days ago (at least 2011/04/11)= I am >>>>>> unable to boot. >>>>>> >>>>>> The boot process stops when it looks to find a bootable device. =A0T= he >>>>>> prompt (when pressing '?') does not display any device and yielding = one >>>>>> second (or more) to the kernel (by pressing '.') does not improve th= e >>>>>> situation. >>>>>> >>>>>> A known working date is 2011/02/20. >>>>>> >>>>>> I am running amd64 on a nVidia MCP51 chipset. >>>>> MCP51... again... >>>>> >>>>>> I am willing to help any way I can. >>>>> You could start from capturing and showing verbose dmesg. Full or at >>>>> least in parts related to disks. >>>> I captured the dmesg output for both the old (working) kernel and the = new >>>> (bad) kernel. =A0See attached for the difference between the two. =A0I= f you need >>>> the full dmesg please let me know. >>>> >>>> One thing I found is that the old kernel would not boot if I simply re= booted >>>> from the bad kernel. =A0I had to do a hard power off before the old ke= rnel would >>>> work again. =A0Is some device state surviving between reboots? >>> +ata2: reiniting channel .. >>> +ata2: SATA connect time=3D0ms status=3D00000113 >>> +ata2: reset tp1 mask=3D01 ostat0=3D58 ostat1=3D00 >>> +ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 >>> +ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 >>> +ata2: reinit done .. >>> +unknown: FAILURE - ATA_IDENTIFY timed out LBA=3D0 >>> >>> As soon as all devices detected but not responding to commands, I would >>> suppose that there is something wrong with ATA interrupts. There is a >>> long chain of interrupt problems in this chipset. I have already tried >>> to debug one case where ATA wasn't generating interrupts at all. >>> Unfortunately, without success -- requests were executing, but not >>> generating interrupts, it wasn't looked like ATA driver problem. >>> >>> What's about possible candidate to revision triggering your problem, I >>> would look on this message: >>> +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 >>> >>> At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and >>> it is interrupt related. >> >> Does the driver disable MSI for MCP51? > > ata(4) doesn't uses MSI by default and I doubt this controller supports > them any way. But if I am not mixing something, there were very strange > situations with MSI on that chipset, when enabling them one one device > caused interrupt problems on another. > >> I think jhb's patch fixed one MSI issue of all MCP chipset. > > I am not telling it is wrong. It could just trigger something. Could the OP try disabling MSI[X] to see whether or not the issue still occurs then? -Garrett