From owner-freebsd-current@freebsd.org Fri Jul 6 09:14:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00E0C10323E6 for ; Fri, 6 Jul 2018 09:14:41 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 680B0753AF; Fri, 6 Jul 2018 09:14:40 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id h10-v6so3448742wre.6; Fri, 06 Jul 2018 02:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZbaalADxuEa7eUlbieqS/MDloxcK57I4cJ8Xg7LeCgI=; b=cfTcvToHMlhe4Z/GZXC0f5K1zqlCJNow9fayabNhEbYw2Gn4L7ZlfplagtfF8IDESA CK28kXxmFpwrePnsqJuHgyshcr6Ee4GMP81sVYejyiq+DQGs8J9o+S2G6NCOtLBPrkko AAXAyQ0ZUBqyhgvt0PSZSJwBfqM725lHq6Th6BzpR+oNgiGi+bND0v4+iakS4MnF1Jln S1EgyAGz1h7RI1KzJevM/YGvsdBTgBAPA/jh6SVV7mHLu6HYkPnJ2uFAVnR9t4zL0lG7 gwxU17rE5HwFIHXJNiDChpsfHyjZt+O+RkBgxrutnGpol8XemUtaWPGAHtjXLunRp9Wh Ifig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZbaalADxuEa7eUlbieqS/MDloxcK57I4cJ8Xg7LeCgI=; b=XQHb2ZKY2zrFbfj7b1xHtPO90Z1yFTsC/0khaPPjn5RgdXPvM2ajzoKJlDKGCKU4XE keTfeMqydTY/EnJFEU+x8YIdPVb8IumhMUGWy+bhjIF9zGrFS20EQg8CDujwAZ3oE7mv OS1twxmfNPR1mieq6StJkGKNvIm0GIuVEV5QF1i++U3nlhIJi0JS9fyVaW2Z57CQe296 65p0obTyhSkAZIK9HYfU+ahnSlx7x3TX6upRHJTH1j+qCJtwjnV3Rg+pOc3njMVqhQuQ Oa9ZWjNJxbeKiWwiDIkwzJG1SzbEiUZR0I2DQfB1NOoSsnGGTiAtOoqREljeICZ3Qn/3 PfHw== X-Gm-Message-State: AOUpUlGlMBkQdIZEPa3nPR1Y9w1gZsFlundVIv2ZhdjDPeI4CvKvwP7r WYkmwXQa4N+qGMsIq939P0XBhtg03yScg0TUeck= X-Google-Smtp-Source: AAOMgpeN82LkWMWD0HSIAijtb5e08rYIGSQMGLfSpOl5Ci6X+9Acxtp3A9xSqReCH1mR+za4vwZ1umesIA/k9iiMecU= X-Received: by 2002:adf:e584:: with SMTP id l4-v6mr971985wrm.190.1530868478929; Fri, 06 Jul 2018 02:14:38 -0700 (PDT) MIME-Version: 1.0 References: <4c5411dd-9f6b-7245-6ade-e11040f74687@FreeBSD.org> <24f5d737-a205-6fcc-0a33-a84601d2ff7a@nomadlogic.org> <29ce4eab-6667-d2ca-b5d8-3deeef28f142@selasky.org> <20180705193646.GM5562@kib.kiev.ua> <5dc2a315-4b71-9ff0-0a37-576649e9144b@FreeBSD.org> <4797c607-c261-77f7-eccf-45056bf56694@daemonic.se> <20180706084729.GN5562@kib.kiev.ua> In-Reply-To: <20180706084729.GN5562@kib.kiev.ua> From: Johannes Lundberg Date: Fri, 6 Jul 2018 10:14:01 +0100 Message-ID: Subject: Re: atomic changes break drm-next-kmod? To: Konstantin Belousov Cc: Niclas Zeising , Warner Losh , jhb@freebsd.org, Hans Petter Selasky , Pete Wright , ohartmann@walstatt.org, freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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: Fri, 06 Jul 2018 09:14:41 -0000 On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov wrote: > On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote: > > On 07/06/18 00:02, Warner Losh wrote: > > > > > > > > > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin > > > wrote: > > > > > > On 7/5/18 12:36 PM, Konstantin Belousov wrote: > > > > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky > wrote: > > > >> On 07/05/18 20:59, Hans Petter Selasky wrote: > > > >>> On 07/05/18 19:48, Pete Wright wrote: > > > >>>> > > > >>>> > > > >>>> On 07/05/2018 10:10, John Baldwin wrote: > > > >>>>> On 7/3/18 5:10 PM, Pete Wright wrote: > > > >>>>>> > > > >>>>>> On 07/03/2018 15:56, John Baldwin wrote: > > > >>>>>>> On 7/3/18 3:34 PM, Pete Wright wrote: > > > >>>>>>>> On 07/03/2018 15:29, John Baldwin wrote: > > > >>>>>>>>> That seems like kgdb is looking at the wrong CPU. Can > > > you use > > > >>>>>>>>> 'info threads' and look for threads not stopped in > > > 'sched_switch' > > > >>>>>>>>> and get their backtraces? You could also just do > 'thread > > > apply > > > >>>>>>>>> all bt' and put that file at a URL if that is easiest. > > > >>>>>>>>> > > > >>>>>>>> sure thing John - here's a gist of "thread apply all bt" > > > >>>>>>>> > > > >>>>>>>> > > > https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed > > > > > > > >>>>>>> That doesn't look right at all. Are you sure the kernel > > > matches the > > > >>>>>>> vmcore? Also, which kgdb version are you using? > > > >>>>>>> > > > >>>>>> yea i agree that doesn't look right at all. here is my > setup: > > > >>>>>> > > > >>>>>> $ which kgdb > > > >>>>>> /usr/bin/kgdb > > > >>>>>> $ kgdb > > > >>>>>> GNU gdb 6.1.1 [FreeBSD] > > > >>>>>> $ ls -lh /var/crash/vmcore.1 > > > >>>>>> -rw------- 1 root wheel 1.6G Jul 3 15:03 > > > /var/crash/vmcore.1 > > > >>>>>> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug > > > >>>>>> -r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54 > > > >>>>>> /usr/lib/debug/boot/kernel/kernel.debug > > > >>>>>> > > > >>>>>> and i invoke kgdb like so: > > > >>>>>> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug > > > /var/crash/vmcore.1 > > > >>>>>> > > > >>>>>> here's a gist of my full gdb session: > > > >>>>>> http://termbin.com/krsn > > > >>>>>> > > > >>>>>> dunno - maybe i have a bad core dump? regardless, more > than > > > happy to > > > >>>>>> help so let me know if i should try anything else or > patches > > > etc.. > > > >>>>> Can you try installing gdb from ports and using > > > /usr/local/bin/kgdb? > > > >>>>> > > > >>>> > > > >>>> that seems to have done the trick, at least the output looks > more > > > >>>> encouraging. > > > >>>> > > > >>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > > >>>> KDB: enter: panic > > > >>>> > > > >>>> __curthread () at ./machine/pcpu.h:231 > > > >>>> 231 __asm("movq %%gs:%1,%0" : "=r" (td) > > > >>>> > > > >>>> > > > >>>> here's my full kgdb session: > > > >>>> http://termbin.com/qa4f > > > >>>> > > > >>>> i don't see any threads not in "sched_switch" though :( > > > >>> > > > >>> Hi, > > > >>> > > > >>> The problem may be that the patch to enable atomic inlining > of all > > > >>> macros forgot to set the SMP keyword which means SMP is not > > > defined at > > > >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED > > > empty! > > > > Problem is that out-of-tree modules build does not have opt*.h > files > > > > from the kernel. UP config is a valid one, flipping some > option's > > > > default value does not solve the problem. > > > > > > Yes, but using the lock prefix in a generic module is ok (it will > still > > > work, just not quite as fast) whereas the lack of lock is fatal on > > > SMP. I would amend Hans' patch slightly to honor the opt_* setting > > > for KLD_TIED (but that is only true if KLD_TIED means "built as > part of > > > a kernel build, so has valid opt_foo.h headers" and not > > > 'a standalone module where someone put MODULES_TIED=1 on the > command > > > line > > > to make'). > > > > > > > > > I agree with this default. It's sensible to default to (a) the most > > > popular thing and (b) thing that always works, especially when (a) and > > > (b) are identical. > > > > > > Don't make me start the "Do we really need an SMP option, why not make > > > it always on" thread :) The number of relevant uniprocessor x86 boxes > > > that benefit from omitting SMP is so small as to be irrelevant, IMHO. > A > > > MP kernel runs just fine on them... > > > > > > Warner > > > > Where are we on this? > > It is important to get it fixed, it's already been 4 days, which means 4 > > days of all modern FreeBSD desktop systems being broken, and possibly > > other systems with kernel modules from ports as well. > > > > > > Another question, how hard would it be to expose how the kernel was > > built to modules built from ports, so that they can figure out stuff > > like SMP and others, that might affect the module build? > Point the KERNBUILDDIR variable to the directory of the kernel build. > This is the directory where *.o and opt*.h are located. Then everything > would just work. > Is the solution that we require everyone to build a kernel before they can build the standalone modules or am I missing something here? _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >