From owner-freebsd-sparc64@FreeBSD.ORG Sat Dec 29 20:21:21 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 695358D0 for ; Sat, 29 Dec 2012 20:21:21 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 167E88FC0A for ; Sat, 29 Dec 2012 20:21:20 +0000 (UTC) Received: from [192.168.1.122] (ip98-166-181-220.hr.hr.cox.net [98.166.181.220]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id qBTKLFqd026713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 Dec 2012 15:21:17 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Changes to kern.geom.debugflags? From: Chris Ross In-Reply-To: <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> Date: Sat, 29 Dec 2012 15:21:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49AEC210-6BB6-4778-B71C-2E3B86E0902C@distal.com> References: <7AA0B5D0-D49C-4D5A-8FA0-AA57C091C040@distal.com> <6A0C1005-F328-4C4C-BB83-CA463BD85127@distal.com> <20121225232507.GA47735@alchemy.franken.de> <8D01A854-97D9-4F1F-906A-7AB59BF8850B@distal.com> <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> To: Chris Ross X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [206.138.151.250]); Sat, 29 Dec 2012 15:21:17 -0500 (EST) Cc: freebsd-sparc64@freebsd.org, Marius Strobl X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 20:21:21 -0000 On Dec 29, 2012, at 3:01 PM, Chris Ross = wrote: > On Dec 27, 2012, at 1:15 PM, Chris Ross = wrote: >> So, I've started with the tiring process of "printf debugging". I = have gotten out of >> the loader code, and can show that it's inside of the call to the zfs = devsw dv_init() >> call where it's failing. >=20 > Okay. Many many iterations, and I found out where it's crashing. In > sys/boot/zfs/zfsimpl.c, in dnode_read(), the first line of the while = loop > is: >=20 > uint64_t bn =3D offset / bsize; >=20 > And, bsize is calculated from: >=20 > int bsize =3D dnode->dn_datablkszsec << SPA_MINBLOCKSHIFT; >=20 > When running the code, though, I can confirm that bsize is 0 before = the divide > is hit, thus causing the divide by zero trap. >=20 > I'm going to guess this is a problem with dnode->dn_datablkszsec. = Has anything > changed recently in zfs_fmtdev, or more likely zfs_get_root() or = objset_get_dnode(), > which is the callchain right before dnode_read() ? So, the dnode in question is the MOS os_meta_dnode, for the MOS that's = in the SPA for the root. (Mind you, the internals of ZFS are all a black box = to me, so I don't understand what I just said). Anyone have any idea why the dn_datablkszsec would be unset or wrote = for said meta dnode? That seems to be the crux of the problem. Where does = that all get initialized? - Chris