From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 24 09:03:34 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3888A1065673; Thu, 24 Mar 2011 09:03:34 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id C134E8FC12; Thu, 24 Mar 2011 09:03:33 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id BE6EA146008; Thu, 24 Mar 2011 10:03:32 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UmvTe1FoN9jH; Thu, 24 Mar 2011 10:03:30 +0100 (CET) Received: from [10.9.8.1] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 3D0B286FF4; Thu, 24 Mar 2011 10:03:30 +0100 (CET) Message-ID: <4D8B08E1.5060008@FreeBSD.org> Date: Thu, 24 Mar 2011 10:03:29 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Moll References: <20110307192239.GA31314@alchemy.franken.de> <20110310185423.GA50419@alchemy.franken.de> <20110319152838.GA8594@alchemy.franken.de> <20110321175632.GA19345@darkthrone.kvedulv.de> <20110321175933.GD2086@garage.freebsd.pl> <20110322191117.GH15528@alchemy.franken.de> <20110323232411.GC82490@darkthrone.kvedulv.de> In-Reply-To: <20110323232411.GC82490@darkthrone.kvedulv.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Roger Hammerstein , pjd@freebsd.org, freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: sparc64 hang with zfs v28 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 09:03:34 -0000 zfs_ioctl_compat_post() calls depending on the ioctl zfs_ioctl_compat_fix_stats() or zfs_ioctl_compat_pool_get_props() Both functions unpack the "zc->zc_nvlist_dst" into "nv" at the very beginning and I might be missing something here (works very well on i386/amd64) or there might be a problem elsewhere. nvlist_unpack() from libnvpair (nvpair.c) calls nvlist_xunpack(), issuing a nvlist_xalloc(), followerd by a nvlist_common() in NVS_OP_DECODE mode - that's where it dies. nvlist_common() deals directly with endianess. sys/cddl/contrib/opensolaris/common/zfs/zfs_ioctl_compat.c sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c Dňa 24.03.2011 00:24, Michael Moll wrote / napísal(a): > Hi All, > > On Tue, Mar 22, 2011 at 08:11:17PM +0100, Marius Strobl wrote: > >> Uhm, looks like r219089 changed some xcopy{in,out}() into >> ddi_copy{in,out}(), i.e. copy{in,out}() into bcopy(), which >> is just wrong for copying in data in from/out to userspace. >> However, looking at the other uses of ddi_copy{in,out}() it >> generally seems that ddi_copy{in,out}() should be defined to >> copy{in,out}(). With the attached patch at least my simple >> test cases works again. > > That looks good, I will test more tomorrow but when netbooting I can > import a zpool now. The only thing is that when upgrading the kernel and > using the old world it still hangs: > http://space.kvedulv.de/zfs_v28/at.txt > > zfs_ioctl_compat_post() is probably the problematic function. > > Regards