Date: Thu, 12 Apr 2012 14:30:19 GMT From: Gavin Mu <gavin.mu@gmail.com> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Message-ID: <201204121430.q3CEUJDk085743@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: Gavin Mu <gavin.mu@gmail.com>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: bug-followup@freebsd.org, Kurt Lidl <lidl@pix.net>
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 <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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204121430.q3CEUJDk085743>