From owner-freebsd-current@FreeBSD.ORG Fri Nov 13 06:15:08 2009 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 94F47106566B; Fri, 13 Nov 2009 06:15:08 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id 2594D8FC15; Fri, 13 Nov 2009 06:15:08 +0000 (UTC) Received: by gxk20 with SMTP id 20so3387526gxk.14 for ; Thu, 12 Nov 2009 22:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vUTwUGgyFk04YUSe5pbleVBMzI0jYfPkGe1rT2lte9o=; b=JJAguO05nGs0JCkxivYP7LcOiDmD7tWyYZ7udPT9VxaT53WzoRF9SX/MUg/l/GvtGr MxLF1UpXTHJZHY/lFdGVYx3jWqCqnBBNdGE3pL0VmvVhMQ7FgQqBmnmQ1ho5XlCns0kJ HaC7brpRIqLVs5cIelI2edLGN/z0WKzNO+JzA= 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=l0JlIHPFaZ9TiKdm9O/KJYqe7O86BC4nYH6IWdqu0a9Ss8Lr/CywBYMKQcJFKTGvjf 7ZGrlgf6KRLakpPdXvTVKNqCzLhCaY7XDCzLjxuXOWF2SMyFGGnqWLdrF7mhZ1IAvbjN oKRA/kBilh+e4OMpU7vfzb3Py9wEPY3I62QkY= MIME-Version: 1.0 Received: by 10.150.233.2 with SMTP id f2mr7000213ybh.259.1258092907509; Thu, 12 Nov 2009 22:15:07 -0800 (PST) In-Reply-To: <1258087983.2303.23.camel@balrog.2hip.net> References: <4AD710D6.70404@buchlovice.org> <1258087983.2303.23.camel@balrog.2hip.net> Date: Thu, 12 Nov 2009 22:15:07 -0800 Message-ID: From: Matt Reimer To: Robert Noland Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, =?ISO-8859-2?Q?Radek_Val=E1=B9ek?= , freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" 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: Fri, 13 Nov 2009 06:15:08 -0000 2009/11/12 Robert Noland : > On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote: >> 2009/10/15 Radek Val=E1=B9ek : >> > Everything works fine for me, until I rewrite kernel/world after syste= m >> > upgrade to latest one (releng_8). After this am I no longer able to bo= ot >> > from zfs raidz1 pool with following messages: >> > >> >>/ ZFS: i/o error - all block copies unavailable >> > />/ ZFS: can't read MOS >> > />/ ZFS: unexpected object set type lld >> > />/ ZFS: unexpected object set type lld >> > />/ >> > />/ FreeBSD/i386 boot >> > />/ Default: z:/boot/kernel/kernel >> > />/ boot: >> > />/ ZFS: unexpected object set type lld >> > />/ >> > />/ FreeBSD/i386 boot >> > />/ Default: tank:/boot/kernel/kernel >> > />/ boot: >> >> Radek, >> >> Try the attached patch (sponsored by VPOP Technologies). I found an >> overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was >> causing my 6x1TB raidz2 array to fail to boot. ... >> The kernel source for the corresponding functionality is in >> /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_= map_alloc(). >> There all these variables are uint64_t, but I think unnecessarily. I >> tried changing the boot loader's vdev_raidz_read() variables to all >> uint64_t but then gptzfsboot would reboot itself, likely due to a >> stack overflow. The attached patch just changes a few variables that, >> after a quick analysis, seemed likely to overflow. >> >> If this looks good, would someone commit it? > > ps@ grabbed it up already, but I may handle the MFC for him. =A0I have > some other minor fixups in my tree right now... like teaching printf to > handle %llx. =A0Thanks for finding this... It's been really frustrating > that I couldn't produce a failing system. Is it possible for this patch to get into 8.0-RELEASE, or is it too late? I suppose it doesn't matter that much since the loader isn't built with LOADER_ZFS_SUPPORT by default anyway, so folks are going to have to compile it themselves. Matt