Date: Thu, 17 Jan 2013 18:35:18 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Chris Ross <cross+freebsd@distal.com> Cc: Kurt Lidl <lidl@pix.net>, freebsd-sparc64@FreeBSD.org, Marius Strobl <marius@alchemy.franken.de> Subject: Re: Changes to kern.geom.debugflags? Message-ID: <50F82846.6030104@FreeBSD.org> In-Reply-To: <D3EE961A-D099-4CA9-9B2B-B69E171B95F1@distal.com> References: <7AA0B5D0-D49C-4D5A-8FA0-AA57C091C040@distal.com> <6A0C1005-F328-4C4C-BB83-CA463BD85127@distal.com> <20121225232507.GA47735@alchemy.franken.de> <8D01A854-97D9-4F1F-906A-7AB59BF8850B@distal.com> <A947C892-5379-4F70-BFA0-0A7AB94DF0C6@distal.com> <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> <20121230032403.GA29164@pix.net> <56B28B8A-2284-421D-A666-A21F995C7640@distal.com> <EEB60849-3192-46E2-8626-EC6824182515@distal.com> <20130104234616.GA37999@alchemy.franken.de> <BD3E2E30-457F-4D8A-8057-3ECED966419F@distal.com> <D3EE961A-D099-4CA9-9B2B-B69E171B95F1@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 08/01/2013 03:53 Chris Ross said the following:
>
> On Jan 7, 2013, at 17:41 , Chris Ross <cross+freebsd@distal.com> wrote:
>> Okay. I've completed this search. SVN rev 242228 works, boots up, the first call
>> to dnode_read() (in sys/boot/zfs/zfsimpl.c) (well, "first" call after the console is initialized)
>> shows (due to a printf I added) :
>>
>> dnode_read(): offset 512, bsize 16384, dn_datablkszsec 32
>>
>> I notice in all of the many following calls that bsize is always 512 or 16384, and
>> dn_datablkszsec is sometimes as small as 1, or as large as 68, but always non-zero.
>>
>> SVN revision 242230 fails in the same way the head of stable/9 does. The first output
>> I see from my printf in dnode_read() is (and the following trap):
>>
>> dnode_read(): offset 512, bsize 0, dn_datablkszsec 0
>> ERROR: Last Trap: Division by Zero
>>
>> I didn't test 242229,. but could if needed, because both 242229 and 242230 were
>> ZFS changes in the boot code, and by the same person.
>
> Out of curiosity, I did try 242229. It boots. So. the problem occurred with 242230, which
> came from 241289. FYI.
Chris,
thank you for triaging and analyzing this problem. And sorry for the long delay
(caused by the New Year craziness you mentioned earlier).
The problem is that arch_zfs_probe methods are expected only to probe for ZFS
disks/partitions, but they are not allowed to execute any other ZFS operations.
I assumed this to be true and forgot to check sparc64_zfs_probe. Mea culpa.
Could you please test the following patch?
Thank you!
diff --git a/sys/boot/sparc64/loader/main.c b/sys/boot/sparc64/loader/main.c
index fa9d068..06a9f70 100644
--- a/sys/boot/sparc64/loader/main.c
+++ b/sys/boot/sparc64/loader/main.c
@@ -142,6 +142,10 @@ static vm_offset_t heapva;
static char bootpath[64];
static phandle_t root;
+#ifdef LOADER_ZFS_SUPPORT
+static struct zfs_devdesc zfs_currdev;
+#endif
+
/*
* Machine dependent structures that the machine independent
* loader part uses.
@@ -732,7 +736,6 @@ static void
sparc64_zfs_probe(void)
{
struct vtoc8 vtoc;
- struct zfs_devdesc zfs_currdev;
char alias[64], devname[sizeof(alias) + sizeof(":x") - 1];
char type[sizeof("device_type")];
char *bdev, *dev, *odev;
@@ -805,9 +808,6 @@ sparc64_zfs_probe(void)
zfs_currdev.root_guid = 0;
zfs_currdev.d_dev = &zfs_dev;
zfs_currdev.d_type = zfs_currdev.d_dev->dv_type;
- (void)strncpy(bootpath, zfs_fmtdev(&zfs_currdev),
- sizeof(bootpath) - 1);
- bootpath[sizeof(bootpath) - 1] = '\0';
}
}
#endif /* LOADER_ZFS_SUPPORT */
@@ -878,6 +878,14 @@ main(int (*openfirm)(void *))
if ((*dp)->dv_init != 0)
(*dp)->dv_init();
+#ifdef LOADER_ZFS_SUPPORT
+ if (zfs_currdev.pool_guid != 0) {
+ (void)strncpy(bootpath, zfs_fmtdev(&zfs_currdev),
+ sizeof(bootpath) - 1);
+ bootpath[sizeof(bootpath) - 1] = '\0';
+ }
+#endif
+
/*
* Now that sparc64_zfs_probe() might have altered bootpath,
* export it.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F82846.6030104>