From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 07:21:20 2008 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 3C7E5106566B for ; Mon, 1 Sep 2008 07:21:20 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id BB5958FC20 for ; Mon, 1 Sep 2008 07:21:19 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so703513eyi.7 for ; Mon, 01 Sep 2008 00:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lABDBmAqBRwcy/J/DT2Pb5YF2PZ+oVzLT0AwKlRkeDs=; b=SZUiSJgrzX/w2W6jdbRxaxSJAc+H6zBL4rLDv5X/APIz7erB8lbO5LELORcCXB9fIg ExPwXftZSgRkmlXNAxYOUuCqPkFkR+IukOl/hXlXwfAi1XeKlPv7kFIRM1D+VtJKyZQO FQCQqz2aZdSaQHxJ72L03XAjlMY6LmXaljUCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Z/kzrJ959jYhftmGHPP3x8H73rVswks8q9rgvOgDafcYrnstmcu5CYkAWwQXXv5CaW 6z2TbCtrO5TTCIYI/xOKA7YyKI65XDXHsrhL0YJqSXSkZo+TnW9CIOYa9roJdeNJ32Gl U0ukYie5UParP/ez2TzJGDpcqWvKK4T7eNsiY= Received: by 10.210.22.16 with SMTP id 16mr6058226ebv.92.1220253676632; Mon, 01 Sep 2008 00:21:16 -0700 (PDT) Received: by 10.210.44.20 with HTTP; Mon, 1 Sep 2008 00:21:16 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2008 09:21:16 +0200 From: "Pascal Hofstee" To: "Christian Weisgerber" In-Reply-To: <20080830010551.GA2090@lorvorc.mips.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808231056.18305.jhb@freebsd.org> <200808290951.44955.jhb@freebsd.org> <20080830010551.GA2090@lorvorc.mips.inka.de> Cc: freebsd-current@freebsd.org Subject: Re: No root filesystem 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: Mon, 01 Sep 2008 07:21:20 -0000 On Sat, Aug 30, 2008 at 3:05 AM, Christian Weisgerber wrote: > John Baldwin: > >> So the reports I've seen of this all involve the Nvidia MCP55 ATA chipset, and >> only the ata controller loses its marbles (so to speak). > > I also observe that k8temp doesn't attach. Maybe Pascal can check this. > It's not part of GENERIC, so k8temp.ko needs to be explicitly loaded > by the loader for this. > > k8temp0: on hostb3 Ok .. this morning i went ahead and collected two boot -v logs. One for the old (working) kernel and one for the new (broken) kernel. For this i made sure not to load the snd_hda module as that tended to bloat the verbose boot output beyond the limit that i could still get to the interesting data at the next boot. The two verbose bootlogs can be found at: http://shadowrun.homeunix.net/boot.verbose.working for the old kernel http://shadowrun.homeunix.net/boot.verbose.broken for the new kernel http://shadowrun.homeunix.net/boot.verbose.diff for the differences between the two. The part that really stood out for me is the section of found devices on pcib0: slot 8 INTA routed to irq 22 via \\_SB_.LMAC The working kernel shows several devices there that do Not show up on the new kernel, according to http://www.pcidatabase.com this concerns the following devices all by"Advanced Micro Devices" -found-> vendor=0x1022, dev=0x1100, revid=0x00 0x1100 HyperTransport Technology Configuration -found-> vendor=0x1022, dev=0x1101, revid=0x00 0x1101 Address Map -found-> vendor=0x1022, dev=0x1102, revid=0x00 0x1102 DRAM Controller -found-> vendor=0x1022, dev=0x1103, revid=0x00 0x1103 Miscellaneous Control I believe this to be rather significant especially because of the way the old kernel hooks up my SATA disks: (ata2-master -> ata2 | ata3-master -> ata3) -> atapci1 -> pci0 -> pcib0 Also i can confirm that indeed k8temp for me also does not even probe with the new kernel. Beyond that i do not see anything majorly different between the two verbose boot logs. I hope this information will provide enough insight into the observed problem :) -- Pascal Hofstee