From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 17:45:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAD3C72; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 893E22AD0; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E6A8B917; Mon, 22 Jul 2013 13:45:45 -0400 (EDT) From: John Baldwin To: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 12:08:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> In-Reply-To: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307221208.22060.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 13:45:45 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:45:47 -0000 On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: > I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: > > # atkbdc0 controls both the keyboard and the PS/2 mouse > #device atkbdc # AT keyboard controller > #device atkbd # AT keyboard > > then I'm able to mount root again (it was failing with ENOXDEV). > > The working kernel was as follows: > > $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA > @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA > gcc version 4.2.1 20070831 patched [FreeBSD] > FreeBSD > 9.1-STABLE > BAYONETTA > $ cd /usr/src; git log 0304216 > commit 03042167f73c213732b44218a24d8e1bbea00f8c > Merge: 2edcad2 974abfb > Author: Garrett Cooper > Date: Mon Jun 24 19:00:45 2013 -0700 > > Merge remote-tracking branch 'upstream/stable/9' into stable/9 > > The working kernel [with atkbdc] was as follows: > > FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 > $ git log c178034 > commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 > Author: avg > Date: Tue Jul 9 08:30:31 2013 +0000 > > zfsboottest.sh: remove checks for things that are not strictly required > > MFC after: 10 days > > (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). > > I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: > > commit 28f961058b0667841d7e9d8639bfd02ed8689faa > Author: jhb > Date: Wed Jul 17 14:04:18 2013 +0000 > > MFC 252576: > Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If > we are probing a PCI-PCI bridge it is because we found one by enumerating > the devices on a PCI bus, so the bridge is definitely present. A few > BIOSes report incorrect status (_STA) for some bridges that claimed they > were not present when in fact they were. > > While here, move this check earlier for Host-PCI bridges so attach fails > before doing any work that needs to be torn down. > > PR: kern/91594 > Approved by: re (marius) I strongly doubt that this is related. It would be most helpful if you could obtain a dmesg from the new kernel however (perhaps via a serial console) to rule it out. All you would need to see is if the new kernel sees more "pcib" devices than the old one to see if this change even has an effect on your system. -- John Baldwin