From owner-freebsd-current@freebsd.org Thu Jul 5 22:02:10 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 3F86C1035A31 for ; Thu, 5 Jul 2018 22:02:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 C2E0C78DD2 for ; Thu, 5 Jul 2018 22:02:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id q9-v6so9122787ioj.8 for ; Thu, 05 Jul 2018 15:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WQ8emALUJCah+bpXRk1kxDWNKNniBYtsSow3e4nXgwk=; b=wh+LTf4xtlAQ5FJtVdD7s9K3eD750fNsiuoE5oVsi7JH5TldmoMm6KX/fulAntffXC IQhJv3QxoZ+N3ys/ru5oHItZDxHgx9JjVNIm+lC/WidORGvNno01tPFSfdzIenvrlHVV SNb7fJSZT6U4/D+PL9yD8I2kCvUMz7IuUxPdlkeunfxyq9A2ecqWBV5llf9pq8KlhEai bGaZ5EfJZeFWDGyN5e4lWP0BDPRXpJTta6Txa+jKS3YoXXXYgH3fsiV6WB/jffWEGinL KIKFH5lIYxc1Xe7p5vpKZACZhPPp1lCCNvgc0xlXuVikLZMuEvVxpGQePaVxUdj4hS5G 8kag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WQ8emALUJCah+bpXRk1kxDWNKNniBYtsSow3e4nXgwk=; b=lFB9S4AvB6Uoxv0ZSaYisd+RLTviINA8Ete9kNfyZBp6J7J/Sq64ku8jCUbO7xEmbZ /rorgASsxJblDCFR3ARiEJ0qpIAha/Y7WO18qiU5iXcl1tLFrdpi0Yl2fM2BZ3OcVonf eh3joyDOQCDx/0myLCxfNAMTd6IfUmWxVhjUZm/mmIQBGxETpOTWwHCiDBkkAMdBpXzP e5YHcVr3qCMszHJBbXuSgel1UFfdpE4XwGKu1KX+Pt/97UY96Gy3oCNO1FbDXptDBKkr AbNsGnNk1uC3sNbxZdVUxaLbmSTt5UqQuuYRxJOHBcUaGHNisLLZLw/eX0TENEkkSuU1 DBAA== X-Gm-Message-State: APt69E1qm867s3nCvQjtaEA073WdLOD7b9Wo9EViuL2k3suwGbWfZZN7 CiWu5Yg4Sgv71euFi2IECbYjlWJU9mFRfFny01NOhQ== X-Google-Smtp-Source: AAOMgpfHusbfzmcROI7wInyoaPqnUHGuEyx5PiiBEuwb8gqMQwo+O4jekr7AzknKjX4pV2RIWBKNZ7Y3TmBSSIkZjig= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr6294711ioa.299.1530828129060; Thu, 05 Jul 2018 15:02:09 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:1183:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 15:02:08 -0700 (PDT) X-Originating-IP: [74.62.67.99] In-Reply-To: <5dc2a315-4b71-9ff0-0a37-576649e9144b@FreeBSD.org> References: <845aca10-8c01-fa3b-087f-f957df4e7531@nomadlogic.org> <063ae5c3-0584-1284-dd9d-ab8b5790baf1@FreeBSD.org> <0bf8e57b-fdb4-4c1a-3d0d-a734f8187ca8@nomadlogic.org> <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> From: Warner Losh Date: Thu, 5 Jul 2018 16:02:08 -0600 X-Google-Sender-Auth: ka8ekKW3X_yTqoK429v0qbBIKAo Message-ID: Subject: Re: atomic changes break drm-next-kmod? To: John Baldwin Cc: Konstantin Belousov , Hans Petter Selasky , Pete Wright , Niclas Zeising , "O. Hartmann" , 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: Thu, 05 Jul 2018 22:02:10 -0000 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