[ Redirect to -geom, bcc'd to -current for transition ] On Sat, Jun 13, 2015 at 04:10:38PM +0200 I heard the voice of José García Juanino, and lo! it spake thus: > Hi FreeBSD current, > > I get a reproducible panic following these steps: > > 1- Mount a geli encrypted DVD: [...] > 4- Open again the lid a wait. The system resumes, but panics after a > few seconds: > > panic: Function g_eli_orphan_spoil_assert() called for cd0.eli. This is presumably what's hooked up in g_eli_create(): /* * Spoiling cannot happen actually, because we keep provider open for * writing all the time or provider is read-only. */ gp->spoiled = g_eli_orphan_spoil_assert; The backtrace makes me think that coming out of resume will cause a media change event on the cd0 device, which sounds a _little_ odd, but may be necessary due to Stupid Reality Crap. That pushes a spoil event down to g_eli. And g_eli seems to assume that can't happen to a thing it's got around an open. With the caveat that I'm no expert on ELI or GEOM, and any advice I might give could just be the trigger for a nasal demon invasion of our world, one thing you might try is taking that event as a hint to just blow away the .eli device; treat it like an orphan. So changing that callback to using the g_eli_orphan func instead. e.g., something like Index: g_eli.c =================================================================== --- g_eli.c (revision 284359) +++ g_eli.c (working copy) _at__at_ -730,7 +730,7 _at__at_ g_eli_create(struct gctl_req *req, struct g_class * Spoiling cannot happen actually, because we keep provider open for * writing all the time or provider is read-only. */ - gp->spoiled = g_eli_orphan_spoil_assert; + gp->spoiled = g_eli_orphan; gp->orphan = g_eli_orphan; gp->dumpconf = g_eli_dumpconf; /* (not even remotely tested; beware of leopard) -- Matthew Fuller (MF4839) | fullermd_at_over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.Received on Sat Jun 13 2015 - 20:46:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC