From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 25 21:36:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9DCC106566B for ; Thu, 25 Aug 2011 21:36:02 +0000 (UTC) (envelope-from crmartin@sgi.com) Received: from relay.sgi.com (relay3.sgi.com [192.48.152.1]) by mx1.freebsd.org (Postfix) with ESMTP id A318B8FC08 for ; Thu, 25 Aug 2011 21:36:02 +0000 (UTC) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.102.206]) by relay3.corp.sgi.com (Postfix) with ESMTP id 41B27AC007 for ; Thu, 25 Aug 2011 14:16:12 -0700 (PDT) Received: from [10.3.0.220] (10.3.0.220) by xmail.sgi.com (137.38.102.30) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 25 Aug 2011 16:16:10 -0500 Message-ID: <4E56BB99.6030706@sgi.com> Date: Thu, 25 Aug 2011 15:16:09 -0600 From: Charlie Martin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.3.0.220] Subject: Where to ask about a 7.2 bug, and debugging sys/queue.h errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:36:02 -0000 We're having a crash in some internal code running on FreeBSD 7.2 (specifically 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE and yeah, I know it's quite a bit behind) in which after 18-30 hours of running load tests, the code panics with: panic: Bad link elm 0xffffff0044c09600 next->prev != elm cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8019119a = db_trace_self_wrapper+0x2a panic() at 0xffffffff80307c72 = panic+0x182 devfs_populate_loop() at 0xffffffff802a43a8 = devfs_populate_loop+0x548 First question: where's the most appropriate place to ask about this kind of bug on a back version. Second: does this remind anyone of any bugs? Googling came up with a few somewhat similar things but hasn't provided much insight so far. Third: I tried compiling with the sys/queue.h QUEUE_MACRO_DEBUG defined in order to get more useful information from the panic. The kernel build fails in pmap.c when this macro is defined, giving an error saying the CTASSERT macro is resolving to a negative array size. Is there any particular secret to using this macro (like, no one goes there any more?) Thanks -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: CRMartin@sgi.com Website: www.sgi.com