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