NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/57564 test after the commit
The following reply was made to PR port-evbarm/57564; it has been noted by GNATS.
From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Ramiro Aceves <ea1abz%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost, Martin Husemann <martin%duskware.de@localhost>,
port-arm-maintainer%NetBSD.org@localhost, port-evbarm-maintainer%netbsd.org@localhost
Subject: Re: kern/57564 test after the commit
Date: Wed, 9 Aug 2023 07:21:16 +0000
This is very weird... The relevant code is this:
#define COUNT(f) do { \
lwp_t *l = curlwp; \
KPREEMPT_DISABLE(l); \
struct nchcpu *nchcpu = curcpu()->ci_data.cpu_nch; \
nchcpu->cur.f++; \
KPREEMPT_ENABLE(l); \
} while (/* CONSTCOND */ 0);
Somewhere, between
lwp_t *l = curlwp;
and
KPREEMPT_DISABLE(l);
l has become null. My first guess would be that the exception vector
failed to restore all the registers or something. But every time it's
tripped exactly the same assertion, with the same stack trace in
cache_lookup, right? If the exception vector were broken, I would
expect to see other random things failing or panicking.
Can you send me the vfs_cache.o file from your kernel build, and/or
share the output of `list *(cache_lookup+0x7c0)' in `gdb netbsd.gdb'?
Maybe the compiler has done something screwy here on armv6.
Home |
Main Index |
Thread Index |
Old Index