Date: Fri, 12 Jul 2002 08:54:28 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: zipzippy@sonic.net Cc: current@freebsd.org Subject: Re: What to do with witness verbiage (is this new?)? Message-ID: <200207121554.g6CFsSwr014353@gw.catspoiler.org> In-Reply-To: <20020712153339.GA414@blarf.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jul, Alex Zepeda wrote: > On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: > >> It'll drop into ddb every time you get a witness error and you'll have >> to tell ddb to continue. This could be a might annoying if you are >> getting errors ever ten seconds ... > > I'm seeing this: > > ../../../vm/uma_core.c:1332: could sleep with "kernel linker" locked from ../../../kern/kern_linker.c:1797 > > very early on (before rc.sysctl is read -- okay I'm still using the old rc > scripts). I see that one also and I know what the problem is. Unfortunately I don't know of a good way of fixing it. The problem is that SYSCTL_OUT() is being called while a lock is held, and SYSCTL_OUT() can potentially block. I've posted a lot more information about this error in another thread. Check the archives for the subject '/usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel li', I guess my original subject got truncated. > Is there any way to set debug.witness_ddb=1 from the loader? Dunno, but you could tweak the source to change the default value and recompile, or you could binary patch the kernel. It's not worth doing it in this case though. > This is entirely repeatable (just boot up the machine), also seems to > happen a few times at random while the system is running. I figure if I > could get it to panic in the repeatable case... You can also reproduce it by running "sysctl -a", but I'll save you the trouble. Here's the stack trace: witness_sleep() uma_zalloc_arg() vm_map_entry_create() vm_map_clip_start() vm_map_wire() vslock() sysctl_old_user() sysctl_kern_function_list_iterate() link_elf_each_function_name() sysctl_kern_function_list() ... There were some other similar cases in the kernel that I've already fixed because they were easy, but I don't know of a good fix for the general case. I'm planning to solicit ideas from the freebsd-arch list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207121554.g6CFsSwr014353>