sparc64/165025: [PATCH] zfsboot support for sparc64

Gavin Mu gavin.mu at gmail.com
Thu Apr 12 14:30:20 UTC 2012


The following reply was made to PR sparc64/165025; it has been noted by GNATS.

From: Gavin Mu <gavin.mu at gmail.com>
To: Marius Strobl <marius at alchemy.franken.de>
Cc: bug-followup at freebsd.org, Kurt Lidl <lidl at 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 at 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


More information about the freebsd-sparc64 mailing list