From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 01:33:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94D90978 for ; Tue, 8 Jan 2013 01:33:36 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 351F018C for ; Tue, 8 Jan 2013 01:33:35 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so10116597wgb.17 for ; Mon, 07 Jan 2013 17:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gv/gBUhlLspdDSE/x3jGEbZ24OqbZ20niJuIcFcj8OM=; b=CefmH38NG9B/PIsMD6ogiFJ530/s7iZ2/bou7orpccB1UXbouueS8PlJh4aNRdKWGI ajEiCa3AW4nDUTwftEDBk8PTUHlceJZZAL5JqTOUGTWkrJEeoZHLiUsCqhpM6C4GdoDm Yv37sueUKuOvHIHhIIwmdhBEpUxF0e+GpdqzN8Rpl6GtAUjUSmEllzR2S/gqMwazJpYO OWuIidlsLF/7iP3AU888lWjruZYo8YRzN5vie0iXRoxCcDuqtSzeDxnRGR1tW3ux6+MQ 1N7Xpo7pc7t6grbWPqPI75vZcM5VpYo1dl7nTvAjOja5dHgeVQbv7nCBVWnCQPApJrkC 5rew== MIME-Version: 1.0 X-Received: by 10.180.100.163 with SMTP id ez3mr12040134wib.24.1357608809320; Mon, 07 Jan 2013 17:33:29 -0800 (PST) Received: by 10.216.100.194 with HTTP; Mon, 7 Jan 2013 17:33:29 -0800 (PST) In-Reply-To: <50EB63A9.50903@delphij.net> References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> Date: Mon, 7 Jan 2013 19:33:29 -0600 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Brandon Gooch To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:33:36 -0000 On Mon, Jan 7, 2013 at 6:09 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/07/13 16:02, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > >> Hi, > >> > >> I've recently (by mid-December I think) noticed that sysctl -a > >> can sometimes cause kernel trap 12. Tried enabling INVARIANTS > >> and the problem mysteriously disappeared. After some experiments > >> on this, it seems that this can be triggered by sysctl -a but the > >> system have an 1 in 10 chance to survive. When INVARIANTS is > >> enabled however, I can not trigger the panic. "sysctl hw" > >> triggers the panic sometimes, but not always. > >> > >> Do anybody have clue on this? The system hangs hard when it > >> panics so kernel debugger won't work. When it panics, the fault > >> instruction pointer is always 0x20:0xffffffff808d61c9, which is > >> sys/kern/subr_turnstile.c:297: > >> > >>> /* Resort td on the list if needed. */ if > >>> (!turnstile_adjust_thread(ts, td)) { > >>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; } > >> > >> This sounds like a race condition but I haven't yet able to track > >> it down... > > > > Could you try to isolate the sub-leaf under hw which causes the > > panic ? Just shot in the dark, do you have Intel GPU gemified > > driver loaded ? > > It seems that it was not hw itself that causes the problem (I thought > about isolating to sub-leaf and at one point believed it was > hw.acpi.battery but doing so repeatedly doesn't panic the system, with > or without INVARIANTS; doing 'sysctl hw' sometimes causes panic but > not always). > > The laptop is running nVidia but it's using i7-3610QM which does have > Intel GPU, but I have not loaded drm2.ko and the panic is reproducible > in single user mode. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > Xin, did you compile the NVIDIA driver port with clang? I was having this issue until I set an exception for the NVIDIA driver port to be built with GCC. Actually, I just remembered (and checked), and what I'm actually doing is setting CFLAGS for the NVIDIA driver port to -O0, and building with clang. Clang optimizes out important bits, I didn't investigate deeply enough to determine what was actually going awry... -Brandon