Date: Mon, 31 Jul 2017 21:03:35 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221075] regression: 11.1 is unable to mount ZFS / on boot Message-ID: <bug-221075-3630-t8vsTsk9Yg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221075-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-221075-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221075 --- Comment #12 from Marius Strobl <marius@FreeBSD.org> --- (In reply to seschwar from comment #10) Unfortunately, I don't see how r318197 could have an impact on ZFS either; that revision only touches bits related to mmc(4), mmcsd(4) and corresponding bridge drivers, but no KPI, no global structure or anything like that. Moreover, according to attachments 184813 and 184814, the drivers in question also don't attach on that machine (is the card reader you mention a USB one?). The partial merges only refer to e. g. ARM-specific bridge drivers that simply don't exist in stable/11, so these omissions should impact you even less. The one thing that comes to my mind is that since r318197, mmcsd(4) depends on geom_flasmap(4) and that the latter might cause some interaction with ZFS. Given that I'm not familiar with how ZFS interfaces with GEOM, I have no idea what actually could be going wrong, though. As far as geom_flasmap(4) is concerned, I can't spot an obvious bug in that regard and its code doesn't differ between head and stable/11. One - not necessarily conclusive - way to test the theory of interaction between geom_flasmap(4) and ZFS would be to use a kernel built from a configuration with mmcsd(4) removed, so this dependency isn't dragged in. In general, I'd suggest to look for unmerged fixes to GEOM and to the parts of ZFS that interface with GEOM. When interfacing mmcsd(4) with geom_flashmap(4), I've had a hard time with races in GEOM; if g_retaste(9) is called (so that an additional provider - now additionally offered by a GEOM class due to a change in configuration - should get picked up) while re-tasting is already in progress, the already ongoing re-tasting won't take note of the new provider and the new re-taste event won't actually result in an additional re-taste cycle being scheduled. If ZFS is suffering from the same or a similar bug, this doesn't necessarily mean that the problem you are hitting is present in stable/11 only; with head you just might be lucky that timing differences resulting from geom_flashmap(4) also being in the mix don't lead to a race. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221075-3630-t8vsTsk9Yg>