On 16/09/2024 04:48, Mark Millard wrote:
Graham Perrin <grahamperrin_at_gmail.com> wrote on
Date: Wed, 22 May 2024 20:32:42 UTC :
Reproducible at <https://bitmovin.com/demos/drm>.
<https://codeberg.org/grahamperrin/freebsd-src/issues/10>
This is a list message that is directly explicit about
various things in the report instead of being indirect.
The GENERIC panics are at the VNPASS indicated below in
sys/kern/vfs_cache.c :
/*
* Resolve a directory to a pathname.
*
* The name of the directory can always be found in the namecache or fetched
* from the filesystem. There is also guaranteed to be only one parent, meaning
* we can just follow vnodes up until we find the root.
*
* The vnode must be referenced.
*/
static int
vn_fullpath_dir(struct vnode *vp, struct vnode *rdir, char *buf, char **retbuf,
size_t *len, size_t addend)
{
#ifdef KDTRACE_HOOKS
struct vnode *startvp = vp;
#endif
struct vnode *vp1;
size_t buflen;
int error;
bool slash_prefixed;
VNPASS(vp->v_type == VDIR || VN_IS_DOOMED(vp), vp);
. . .
For reference:
/usr/main-src/sys/sys/vnode.h:#define VN_IS_DOOMED(vp)
__predict_false((vn_irflag_read(vp) & VIRF_DOOMED) != 0)
…
Big thanks to Mark for investigating.
When I first wrote here, in May, I had no idea that htop could trigger
the panics. I knew little more than, a panic occurring with every
(-CURRENT GENERIC) attempt to use Widevine in www/chromium.
… As far as I can see, htop touches the problem area but
itself is not the problem. The handling of the "worker"
related context for the type of kernel call seems to be
what is at issue, likely no matter what process happens
to make the same basic kernel call that ends up with
"worker" in the context.
===
Mark Millard
marklmi at yahoo.com
Built as shown at
<https://github.com/htop-dev/htop/issues/1537#issuecomment-2354268992>,
it's now possible for Chromium to detect (and play) Widevine content,
with GENERIC, whilst htop runs.
For myself, I have set aside a copy of FreeBSD Project-packaged
htop-3.3.0_4.pkg
Regards Graham
