Date: Sun, 22 Apr 2012 20:40:13 GMT From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Message-ID: <201204222040.q3MKeDtu098088@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR sparc64/165025; it has been noted by GNATS.
From: Marius Strobl <marius@alchemy.franken.de>
To: Gavin Mu <gavin.mu@gmail.com>
Cc: bug-followup@freebsd.org, Kurt Lidl <lidl@pix.net>
Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64
Date: Sun, 22 Apr 2012 22:32:11 +0200
On Thu, Apr 12, 2012 at 10:27:31PM +0800, Gavin Mu wrote:
> On Mon, Mar 5, 2012 at 2:06 AM, Marius Strobl <marius@alchemy.franken.de> 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.
Hrm, some OFW implementations might have reference counting bugs,
causing OF_close() to also close some parent(s) when these in fact
are still used by another opened child device. Have you tried how
it works when just commenting out the OF_close() in ofwd_close() but
leaving the rest of ofw_disk.c as is? If that works, we probably
can add a cleanup handler which closes all opened disk devices
before leaving the loader, still taking advantage of caching opened
disks.
>
> for OF_open("normal disk controller without disk") issue, I did not
> find how to work around or fix yet.
Currently, I can't think of a way to solve this with the available
OFW interfaces. Have you checked whether OpenSolaris includes the
source of the OFW ZFS loader bits and how it's done there or
generally how a Solaris instalaltion handles this (f.e. does it
create any additional aliases for ZFS providers and uses these
instead etc)?
>
> Is there any documents about how this open firmware work? I googled
> but can not find anything useful.
>
For the most part, there's just IEEE 1275. There once was a bit of
related information on http://playground.sun.com/1275/, which
unfortunately disappeared some time after Oracle took over.
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204222040.q3MKeDtu098088>