From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 12 14:30:20 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F96106566B for ; Thu, 12 Apr 2012 14:30:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 08FE58FC12 for ; Thu, 12 Apr 2012 14:30:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3CEUJMT085746 for ; Thu, 12 Apr 2012 14:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3CEUJDk085743; Thu, 12 Apr 2012 14:30:19 GMT (envelope-from gnats) Date: Thu, 12 Apr 2012 14:30:19 GMT Message-Id: <201204121430.q3CEUJDk085743@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Gavin Mu Cc: Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Mu List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:30:20 -0000 The following reply was made to PR sparc64/165025; it has been noted by GNATS. From: Gavin Mu To: Marius Strobl Cc: bug-followup@freebsd.org, Kurt Lidl Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Date: Thu, 12 Apr 2012 22:27:31 +0800 On Mon, Mar 5, 2012 at 2:06 AM, Marius Strobl wrote: > Typically, opening and closing devices via OFW causes quite a delay, > the exact impact depends on the firmware version and the devices > involved though. Therefore, it would be advisable to keep using the > current approach of caching opened packages. In what way does this > fail with ZFS? The error message on Fire V100 is: Fast Data Access MMU Miss > Basically, IEEE 1275 just says that support for > opening a package more than once depends on the particular package > but nothing about concurrently opening different packages. Not > being able to concurrently open different packages also doesn't > make all that much of a sense as opening one package also means > to subsequentially open all the parents up to the root if not > already opened and I think to actually have tested opening disks > concurrently when writing the current code. Could this fail due > to one device actually being opened twice, once via the full path > and once via its alias? There is no such scene though the code lacks the checking for full path/devalias. I have tried many times to find the root cause but I think it is difficult without open firmware knowledge. currently I found that following scenes will cause this issue with my test code: 1. do OF_seek(ihandle_t a) just after OF_close(ihandle_t b). in real world, OF_seek(a) is the step to read ZFS data just after OF_close() another disk during zfs init/probe. 2. do OF_seek(ihandle_t a) just after OF_open("available controller without disk"). For example there is no disk3 on my machine though there is disk controller. OF_open("disk3:") will report: Can't read disk label. Can't open disk label package in ofw_disk.c, OF_close() has been commented out for powerpc architecture, and can not find detail reason from code history, so I am thinking if we need also disable OF_close() for sparc64. for OF_open("normal disk controller without disk") issue, I did not find how to work around or fix yet. Is there any documents about how this open firmware work? I googled but can not find anything useful. Regards, Gavin Mu