Date: Sun, 29 Apr 2012 16:30:15 GMT From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Message-ID: <201204291630.q3TGUFaP086676@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: bug-followup@FreeBSD.org, gavin.mu@gmail.com Cc: Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Date: Sun, 29 Apr 2012 18:10:19 +0200 On Sun, Apr 22, 2012 at 08:40:13PM +0000, Marius Strobl wrote: > 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. > With the machines I have at hand, I can't reproduce this problem, i.e. ofw_disk.c as is works just fine for booting from a mirror. This suggests that what you are seeing actually is a bug in the specific firmware implementation rather than a general limitation imposed by OFW. Could you please give the following patch a try? It implements what I've described above, i.e. combines both caching opened devices and properly closing all opened disks when leaving the loader. http://people.freebsd.org/~marius/ofw_disk_close_on_cleanup.diff Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204291630.q3TGUFaP086676>