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=3D221075 --- 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 correspondi= ng bridge drivers, but no KPI, no global structure or anything like that. Moreover, according to attachments 184813 and 184814, the drivers in questi= on 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 sim= ply 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 ZF= S. Given that I'm not familiar with how ZFS interfaces with GEOM, I have no id= ea 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 dependen= cy 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 he= ad you just might be lucky that timing differences resulting from geom_flashma= p(4) also being in the mix don't lead to a race. --=20 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>