From owner-freebsd-hackers@freebsd.org Sat May 20 16:53:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EF37D76E0B for ; Sat, 20 May 2017 16:53:13 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from h1929017.stratoserver.net (jstimpfle.de [85.214.245.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 593F41C07 for ; Sat, 20 May 2017 16:53:12 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from jfs by h1929017.stratoserver.net with local (Exim 4.84_2) (envelope-from ) id 1dC7cl-0005ro-RL; Sat, 20 May 2017 18:53:03 +0200 Date: Sat, 20 May 2017 18:53:03 +0200 From: Jens Stimpfle To: Sebastian Huber , freebsd-hackers@freebsd.org Subject: Re: Improved Red-black tree implementation Message-ID: <20170520165303.GA22452@jstimpfle.de> References: <20170514050220.GA768@jstimpfle.de> <591EA74A.3080500@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <591EA74A.3080500@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 21 May 2017 04:09:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 16:53:13 -0000 On Fri, May 19, 2017 at 10:05:30AM +0200, Sebastian Huber wrote: > I use the BSD for RTEMS with a shared extract and insert color > implementation (this is similar to Linux): > > https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/rbtree.h#n206 > https://git.rtems.org/rtems/tree/cpukit/score/src/rbtreeextract.c > https://git.rtems.org/rtems/tree/cpukit/score/src/rbtreeinsert.c > > I did also some primitive benchmarking: > > https://github.com/sebhub/rb-bench Thanks Sebastian, I had actually found you bench already and tested an earlier version of my code. It did quite well on my machine, although I would expect it to be faster than BSD ("SIL RB3"): https://raw.githubusercontent.com/jstimpfle/rb-bench/31f111f9c7664d72d5f103bb46adcb28a1cea61a/reports/test-amdx2250.png The second plot is broken maybe because my machine is too fast for the bench... > It would be quite nice to have a implementation which encodes > the color in one of the pointers to save some memory. I have looked at your project and will send you email off-list. Just a few points here: Considering memory savings, have you considered 2-pointer trees (no parent pointer)? They need a temporary search stack for insertion and deletion, but not for iteration ("threaded trees"). The RTEMS red-black tree API seems to be implemented by removing convenience / type-safety from the BSD API to save memory (no multiple instances compiled). While relatively straightforward, replacing tree.h with rb3ptr's BSD shim here would be a lot of layers on top of rb3ptr's core just to expose something like that core again, in the end. And as advertised in another mail, with minimal use of macros convenience and type-safety can be increased without requiring multiple compilation, probably even saving code size. But that would mean changing all client code to use the wrapper API / BSD shim... Jens From owner-freebsd-hackers@freebsd.org Sun May 21 17:00:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9445D77850 for ; Sun, 21 May 2017 17:00:32 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 8486A1D20 for ; Sun, 21 May 2017 17:00:32 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-vk0-x229.google.com with SMTP id y190so31138827vkc.1 for ; Sun, 21 May 2017 10:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/bCBS9cfgh/wAGQaOknkSo5MQ7jfoVAkVkpaWJdT1Eo=; b=dI9eOvvG6TlITqFSwOt2/LGxIrGP67/cpi7iSS3glmAUmNho8NKvzR1EOytaF+tO02 5uXolZDsNuDvQJM3k7Bzmr1A/6zTUbijZyYHy3tQQzhNyTCk57aQnHfHkzr+FBUPS+4d QDrE/dbIzKzBs2Q8Sd+9TMBJ9bLt7kdQD4OgYAtvUukRSBI5dhWguA/RvFxv4pcKYowD PieUI3is+IXX3MmA5M0ZJXsgUOyjPPseQS11+izqQfsPMNHkOLQ4CHw1vQVuxgmqzweJ 40m61bv8LFrp914b/8kVtw0U5YoZDy/4zgQmUytT1yL1wHKiZcxUAWRw8vp2nifVMah4 ln/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/bCBS9cfgh/wAGQaOknkSo5MQ7jfoVAkVkpaWJdT1Eo=; b=B8VYLm9HiExOh1wGUQUe2T1OdYmZTNNF/BqGSepIsnJngUIFRxyB6z73Ofv8UgsJJs n+b/9rcXkblsSWLTFGSjSuzGFQvx4KrHRc31igReLsLFVsgyx8GHOFhTEGPhXC6cOGDD 4vGnuWdxaAw5ojvAxUHl+C7bjS8IbESM4/m/Reu95uDYRej+3yhF9/F5Zqz9d5zipCJ6 ANIsx+IA9ZOd19CtO9A7Ag2O0XJ1js34H8SRx5JI/qnGSDUY7dudevY9jKsfUXhOxxWH AreLHlITBkgA1hcPfEKcQnRhsGhHPMfdhm8AbaEyP5HbOhysMq7tO2SRBwF4dv7Lxaak ChNw== X-Gm-Message-State: AODbwcADj8DUSHL80x4mKi+wVLnShhr+uHPoFkLbeYIN+mugb09yjt6P 7pYVrrLk7qA5jTN8jtGzHJYQGSWCGu1K X-Received: by 10.31.165.79 with SMTP id o76mr6671321vke.91.1495386030524; Sun, 21 May 2017 10:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.204.195 with HTTP; Sun, 21 May 2017 10:00:29 -0700 (PDT) From: Aijaz Baig Date: Sun, 21 May 2017 22:30:29 +0530 Message-ID: Subject: Debugging nullfs kernel module - cannot access memory at address To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 17:00:32 -0000 I am trying to debug the nullfs kernel module so to that end, I do the following: On the target machine: kldstat gives Id Refs Address Size Name 1 10 0xffffffff80200000 17e10c8 kernel 2 1 0xffffffff819e2000 4cf0 vmxnet.ko 3 1 0xffffffff819e7000 16e0 echo.ko 4 1 0xffffffff81c11000 23dc vmmemctl.ko 5 1 0xffffffff81c14000 641b nullfs.ko nm /boot/kernel/nullfs.ko | grep mount 00000000000018f0 t null_getwritemount 0000000000000540 t nullfs_mount 0000000000000930 t nullfs_unmount U vfs_mountedfrom U vop_getwritemount_desc On the local machine (which connects to the target via a named pipe acting as a serial console (I am using virtual machines): (kgdb) tr0 kdb_sysctl_enter (oidp=, arg1=, arg2=0xfffffe004e7cc7f0, req=) at /usr/src/sys/kern/subr_kdb.c:446 446 kdb_why = KDB_WHY_UNSET; Current language: auto; currently minimal (kgdb) getsyms During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff8099497a. Id Refs Address Size Name 1 10 0x80200000 17e10c8 kernel 2 1 0x819e2000 4cf0 vmxnet.ko 3 1 0x819e7000 16e0 echo.ko 4 1 0x81c11000 23dc vmmemctl.ko 5 1 0x81c14000 641b nullfs.ko Select the list above with the mouse, paste into the screen and then press ^D. Yes, this is annoying. 5 1 0x81c14000 641b nullfs.ko add symbol table from file "/usr/obj/usr/src/sys/AIJAZ-DEBUG/modules/usr/src/sys/modules/nullfs/nullfs.ko.debug" at .text_addr = 0x81c14000 .data_addr = 0x81c14000 .bss_addr = 0x81c14000 (kgdb) add-kld nullfs.ko add symbol table from file "/boot/kernel/nullfs.ko.symbols" at .text_addr = 0xffffffff81c14000 set_sysinit_set_addr = 0xffffffff81c15c90 set_sysuninit_set_addr = 0xffffffff81c15cb0 .rodata.str1.1_addr = 0xffffffff81c15cc8 set_modmetadata_set_addr = 0xffffffff81c15e48 set_sysctl_set_addr = 0xffffffff81c15e58 .data_addr = 0xffffffff81c15e60 .bss_addr = 0xffffffff81c16360 (y or n) y Reading symbols from /boot/kernel/nullfs.ko.symbols... location expression too complex...done. (kgdb) b nullfs_mount Cannot access memory at address 0x81c14540 As one can see from the output of 'nm' and 'kldstat' above, the addresses are indeed proper. I even tried setting a "hardware breakpoint" at the above address (kgdb) hbreak *0x81c14540 Hardware assisted breakpoint 1 at 0x81c14540: file /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c, line 74. (kgdb) c Continuing. Warning: Cannot insert breakpoint 1. Error accessing memory address 0x81c14540: Input/output error. On searching for this error on Linux, it appears that this is taken care of by turning off CONFIG_DEBUG_RODATA as part of the kernel config (which as per this: http://elinux.org/Overwrite_detection_for_kernel_text_and_read-only_data link appears to be some sort of a protection mechanism which detects when the text section of the kernel is being overwritten for some reason). This helps with the setting of software breakpoints which would otherwise be not set. Is there something similar for FreeBSD systems as well?? Keen to hear -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Sun May 21 17:46:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BE8ED76724 for ; Sun, 21 May 2017 17:46:15 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [207.172.210.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA8AC152E for ; Sun, 21 May 2017 17:46:14 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:418:3fd::1f] (haymarket.m5p.com [IPv6:2001:418:3fd::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v4LHihVW029027; Sun, 21 May 2017 13:44:48 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Belated followup Re: TCP6 problem To: Bob Bishop Cc: freebsd-hackers@freebsd.org References: <82600781-7892-63ea-feac-35a140dbf95d@m5p.com> <1D3B8C36-6144-4040-8939-61EB933B5080@gid.co.uk> <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> From: George Mitchell Message-ID: <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> Date: Sun, 21 May 2017 13:44:37 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RGaiwDWExwEwAA9IA12DiJvTTLq7o8pTe" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.1 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sun, 21 May 2017 13:44:51 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 17:46:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RGaiwDWExwEwAA9IA12DiJvTTLq7o8pTe Content-Type: multipart/mixed; boundary="r7eqMcA4vWmI7PhLJDWTFnSqEPN3tG2bb"; protected-headers="v1" From: George Mitchell To: Bob Bishop Cc: freebsd-hackers@freebsd.org Message-ID: <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> Subject: Belated followup Re: TCP6 problem References: <82600781-7892-63ea-feac-35a140dbf95d@m5p.com> <1D3B8C36-6144-4040-8939-61EB933B5080@gid.co.uk> <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> In-Reply-To: <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> --r7eqMcA4vWmI7PhLJDWTFnSqEPN3tG2bb Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/30/17 19:09, George Mitchell wrote: > On 04/30/17 18:39, Bob Bishop wrote: >> Hi, >> >>> On 30 Apr 2017, at 20:22, George Mitchell wr= ote: >>> >>> In certain cases, TCP6 stopped working between machines on my local >>> net and the outside world when I updated to 10.3-RELEASE-p18 on my >>> network. [etc] >> >> Try a quick test without pf, if only to eliminate it. >> [...] >=20 > A quick naive test (service pf stop) seemed to just make things worse, > so let me wait until a lower traffic time like tomorrow morning and > reboot with "pf_enable" set false. -- George >=20 I haven't solved this problem yet, but it has become moot because my IPv6 tunnel provider died. -- George --r7eqMcA4vWmI7PhLJDWTFnSqEPN3tG2bb-- --RGaiwDWExwEwAA9IA12DiJvTTLq7o8pTe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlkh0gsACgkQwRES3m+p 4flciRAAsUjfS2ZyhErjUujl/YX1hxp21Awf2snBi7JU6WHYXDzJprbvBeHXwmS0 z0GMjq3TDkKEjSlBWozuVOb53iR3hSjySepQjlKrCfezaX1KlYegjG9+jCl9SE+K 1RnuMITdvW3WNc7s3iGsqq9zvfPkDGmw/9UqVk7w9k8+k2MRV1yhZ0adlWTi6Hfy nGs2bFYzpSAQ9RYX29c6wZ16ZEkVKE9FyWMa7RM61sN3bO1BNTy2qCFYdytBMsGy +wuvXdFHxQHOHEQXnZuAQ2g9KbqbdomzU/Sgt1K++8JWYxI2+mcbZad2/VdYaNZ1 mGFfGaTht9m7Y9QMpHEYkD2liiyCTCuV5IuD2+zxrHhD7v1RUZqssMZC9xWLOfWp oLZBkfBoEpeT3d93Yc0yx6tx4IpVNkXWh/bChjMdSnVrspbClcaC2VS//CYpRnaR xXTuIOJy5zm/GUutlfybpoONG95ROCXLOYxnTYu6fDjPMzoq8K3WIX1UM65yj8gI 8z1FfG1CPnemZVqy7ndvidK3vE2si3k7Y45/SUeMlgdGzyxnFKnOxGRzk4CMl7cd PewCzIkEp5iUc/NIKH3WrvcDb2IMdn6JXk8XRroOovmkKvlT7xpaoSV2eUKB5uno xcM74KRJqiUvJx+ahsMp4sCiK8pMyokp4aP3r0Cd3JUHSwwc6rU= =FK5I -----END PGP SIGNATURE----- --RGaiwDWExwEwAA9IA12DiJvTTLq7o8pTe-- From owner-freebsd-hackers@freebsd.org Mon May 22 00:00:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34CC0D78C34; Mon, 22 May 2017 00:00:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 BF492178B; Mon, 22 May 2017 00:00:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f44.google.com with SMTP id d127so131870311wmf.0; Sun, 21 May 2017 17:00:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Leu/A6DTSZfKrpzRZ+lcUyrGk3+9X4A94zsjKLxspGs=; b=TVY3gyJj/0xJOnoQG55WSDoyVMsmgFptOQOIXmEarCYSwm7baTjtj73feAn8NhIM3v r64r1nl2M+R0iHQIu3s1Whl6RKhQ1M3rSCPB/ZxEaEDMiVRzF7B1rBFkYFCrxozAMJp/ KSCp7MjMnI9XrDEORi5NJ00FJHr0tmunzykzVZgVgvGaz3rJyj7yc0ESroYMyY4IerVn j2JQybxE9x2CEuyGNrMjjxb5Ol9FT/icGSEZtEhnaY+yxnr/D6G+qTCqrmFa9wQ3hcLn yUqw8WlPkkN4WHjb91+3Tgn4I+f3uIm/PuhtopJxcUf/rPWHoLBypWnr2nD8HBd66Uuo HDKw== X-Gm-Message-State: AODbwcCsIaeXuOyR3dQFCe4nlzyPzSYW6b7L6QR4C5buD6DB1iEMtX6v nAwfGllCcMqzpQ== X-Received: by 10.223.164.81 with SMTP id e17mr8910200wra.133.1495410714666; Sun, 21 May 2017 16:51:54 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com. [74.125.82.44]) by smtp.gmail.com with ESMTPSA id j44sm6560273wre.67.2017.05.21.16.51.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 May 2017 16:51:54 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id 7so45697444wmo.1; Sun, 21 May 2017 16:51:53 -0700 (PDT) X-Received: by 10.80.184.117 with SMTP id k50mr15386803ede.113.1495410713873; Sun, 21 May 2017 16:51:53 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Sun, 21 May 2017 16:51:53 -0700 (PDT) In-Reply-To: References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> From: Conrad Meyer Date: Sun, 21 May 2017 16:51:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Proposal for a design for signed kernel/modules/etc To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 00:00:12 -0000 Hi Eric, On Wed, Mar 29, 2017 at 7:22 PM, Eric McCorkle wrote: >... > == Specifics == > >... > > * A signed ELF will definitely contain a .sign section containing a > single detached signature in PKCS#7 format with DER encoding. I'm concerned about the complexity of parsing PKCS#7 (including ASN.1) in places that need to validate signed objects. In particular, the kernel (for runtime-loaded objects). Complex parsers are a common source of security bugs, so PKCS#7 doesn't seem like a good fit for security-critical code like the kernel syscall interface. Could a more minimal format take the place of PKCS#7 in .sign sections? Thanks, Conrad From owner-freebsd-hackers@freebsd.org Mon May 22 05:17:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11350D773AD for ; Mon, 22 May 2017 05:17:21 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C40131919 for ; Mon, 22 May 2017 05:17:20 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dCfiS-0007tj-4K; Mon, 22 May 2017 07:17:12 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dCfiR-0002gM-TN; Mon, 22 May 2017 07:17:12 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A7D2F2A0929; Mon, 22 May 2017 07:17:51 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dOcjPTo8BYv3; Mon, 22 May 2017 07:17:51 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 2F85B2A092A; Mon, 22 May 2017 07:17:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rb3qoEWFJYLX; Mon, 22 May 2017 07:17:51 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 1CD192A0929; Mon, 22 May 2017 07:17:51 +0200 (CEST) Subject: Re: Improved Red-black tree implementation To: Jens Stimpfle , freebsd-hackers@freebsd.org References: <20170514050220.GA768@jstimpfle.de> <591EA74A.3080500@embedded-brains.de> <20170520165303.GA22452@jstimpfle.de> From: Sebastian Huber Message-ID: <59227456.9020805@embedded-brains.de> Date: Mon, 22 May 2017 07:17:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20170520165303.GA22452@jstimpfle.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23406/Mon May 22 02:55:22 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 05:17:21 -0000 On 20/05/17 18:53, Jens Stimpfle wrote: >> It would be quite nice to have a implementation which enc= odes >> >the color in one of the pointers to save some memory. > I have looked at your project and will send you email off-list. Just a > few points here: > > Considering memory savings, have you considered 2-pointer trees (no > parent pointer)? They need a temporary search stack for insertion and > deletion, but not for iteration ("threaded trees"). The RB and Eternally Confuzzled variants don't use a parent pointer as=20 far as I remember. > > The RTEMS red-black tree API seems to be implemented by removing > convenience / type-safety from the BSD API to save memory (no multiple > instances compiled). While relatively straightforward, replacing tree.h > with rb3ptr's BSD shim here would be a lot of layers on top of rb3ptr's > core just to expose something like that core again, in the end. Yes, type-safety was no major requirement in my case. > > And as advertised in another mail, with minimal use of macros > convenience and type-safety can be increased without requiring multiple > compilation, probably even saving code size. But that would mean > changing all client code to use the wrapper API / BSD shim... For BSD inclusion I guess the API and ABI must be compatible. You can=20 add new features optionally. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@freebsd.org Mon May 22 10:25:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5D88D77895 for ; Mon, 22 May 2017 10:25:42 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 90D0214DD for ; Mon, 22 May 2017 10:25:42 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9024AD77894; Mon, 22 May 2017 10:25:42 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E0C4D77892 for ; Mon, 22 May 2017 10:25:42 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C73814DA for ; Mon, 22 May 2017 10:25:41 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v4MA1TWa056265 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 May 2017 12:01:45 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org From: Dirk-Willem van Gulik Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: anti-dog-piling and ntpd leap files Message-Id: Date: Mon, 22 May 2017 12:01:29 +0200 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (weser.webweaving.org [148.251.234.232]); Mon, 22 May 2017 12:01:45 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 10:25:42 -0000 Just wondering - how is the new ntpd leapfile fetching supposed to work. = I spot a dead normal entry: May 22 03:01:00 lowcloud-storage /usr/sbin/cron[6258]: (root) = CMD (periodic daily) in /var/log/cron - and see the periodic scripts getting ran one by one. Yet regularly - I see 3 of them still sitting pretty =E2=80=94 even = though their sleeps are all below < 24hours: ps ... root 10324 0.0 0.0 13144 2788 - I 03:57 = 0:00.00 /bin/sh /etc/periodic/daily/480.leapfile-ntpd root 10327 0.0 0.0 6244 1996 - I 03:57 = 0:00.00 sleep 79926 root 16376 0.0 0.0 13144 1960 - IJ 05:10 = 0:00.00 /bin/sh /etc/periodic/daily/480.leapfile-ntpd root 16379 0.0 0.0 6244 1496 - IJ 05:10 = 0:00.00 sleep 64660 root 17537 0.0 0.0 13144 1960 - IJ 05:28 = 0:00.00 /bin/sh /etc/periodic/daily/480.leapfile-ntpd root 17540 0.0 0.0 6244 1496 - IJ 05:28 = 0:00.00 sleep 77582 That is not supposed to happen ? Correct ? Dw. From owner-freebsd-hackers@freebsd.org Mon May 22 11:53:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEB3CD7659F for ; Mon, 22 May 2017 11:53:12 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 67A8B189C for ; Mon, 22 May 2017 11:53:12 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr0-x242.google.com with SMTP id 6so6670644wrb.1 for ; Mon, 22 May 2017 04:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=z2Uu6+x/5PZBnC3l0Ja6G3HBzw1sRVaSdABMYZW7mvQ=; b=JotJ6vGQ9q9ImJKuDTYfV1TvkX6Q+DqMdGKsbGR3AwmZyV8nYphSI4lN2AnwdMutJe gNMlU7NYkLYQ1v1NKMpwBycZ/FySMF1UOYVR9D77tqkmHy23LHrAuPdQZfsl6Pjs9vds LUZ0hLhAjk/vhHVre2zQtbaBo5WTyBoqff6ov4tPfYLfEMnL3aC+pXOnsc3/Ac6oW8LZ MHYQTucgtZdkvZyWQDytN8eERx+rR68e6Uqv2YtCI3lVUmDhBweN++EV9ib9n2ZIfuLE p3uT7qTOPfXTZhiHfwFrzxb3qxhnmaDniqxS75b5GVU31Xj2GPmF1dvVr6fgzJ3Ts4Dx w1ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=z2Uu6+x/5PZBnC3l0Ja6G3HBzw1sRVaSdABMYZW7mvQ=; b=eIwyDuEHbZvYklGcA/Lq3KkqaypSBYkciBMbPVCQCIpL/4z0RsLyZmbsYZopCA8Oz1 vwVzR5IkJYaSWNPWkuJNLVXXSYepy8LKGsKz1Iv8wUeqZZ/Qm31PzPK4J7BE0EtA3Ixw v7ncJhArAueF96ADRQ5CyyLTE0mRXgZecV69gCFsvPIDVlh28QqGVIHa8YT8snohswj/ d9u/6NuHUpRaM6bJ8qvNdOiyGZJSNRNt4wDIhJsaAT6EihEBK7vqVWg3uiPn+IioOPSN lasdFMbYQBUAGpSfklM31Ob3mzPdbnBrmx1vIRuWN9e0vfsA5SS4er/Y5DZgfB0YUxuK ebiA== X-Gm-Message-State: AODbwcBv7T+EQ63cRHIDLlVysclsM8EN1gSUz+drNH+xFv/NFsmltMJQ 9ESCkTt3XbM3FHdK X-Received: by 10.223.161.20 with SMTP id o20mr13261716wro.102.1495453990558; Mon, 22 May 2017 04:53:10 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id p5sm29413040wma.17.2017.05.22.04.53.09 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 May 2017 04:53:09 -0700 (PDT) Date: Mon, 22 May 2017 12:53:07 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: anti-dog-piling and ntpd leap files Message-ID: <20170522125307.76c9de6d@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 11:53:13 -0000 On Mon, 22 May 2017 12:01:29 +0200 Dirk-Willem van Gulik wrote: > Just wondering - how is the new ntpd leapfile fetching supposed to > work. I spot a dead normal entry: >=20 > May 22 03:01:00 lowcloud-storage /usr/sbin/cron[6258]: (root) > CMD (periodic daily) >=20 > in /var/log/cron - and see the periodic scripts getting ran one by > one. >=20 > Yet regularly - I see 3 of them still sitting pretty =E2=80=94 even though > their sleeps are all below < 24hours: >=20 > ps ... .. >=20 > That is not supposed to happen ? Correct ? =46rom the ps output it looks like there's one normal 480.leapfile-ntpd process and two more running in jails. From owner-freebsd-hackers@freebsd.org Mon May 22 12:08:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A92CCD779AE for ; Mon, 22 May 2017 12:08:55 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 499FC1614 for ; Mon, 22 May 2017 12:08:54 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v4MC7ZKn059878 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 14:07:35 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: anti-dog-piling and ntpd leap files From: Dirk-Willem van Gulik In-Reply-To: <20170522125307.76c9de6d@gumby.homeunix.com> Date: Mon, 22 May 2017 14:07:35 +0200 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> References: <20170522125307.76c9de6d@gumby.homeunix.com> To: RW X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (weser.webweaving.org [148.251.234.232]); Mon, 22 May 2017 14:07:35 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:08:55 -0000 > On 22 May 2017, at 13:53, RW via freebsd-hackers = wrote: >=20 > On Mon, 22 May 2017 12:01:29 +0200 > Dirk-Willem van Gulik wrote: >=20 >> Just wondering - how is the new ntpd leapfile fetching supposed to >> work. I spot a dead normal entry: ... >> That is not supposed to happen ? Correct ? >=20 > =46rom the ps output it looks like there's one normal = 480.leapfile-ntpd > process and two more running in jails. Thank you. Palm, face, etc. Been staring at this for quite bit.=20 Much appreciated, Dw. From owner-freebsd-hackers@freebsd.org Mon May 22 13:04:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADF68D78C78 for ; Mon, 22 May 2017 13:04:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 5F6551BB9 for ; Mon, 22 May 2017 13:04:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yb0-x234.google.com with SMTP id p143so30135446yba.2 for ; Mon, 22 May 2017 06:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RnkdTkQFlJ5KchOTAzJKV4GgUfnhHfZXksvackKTzbc=; b=S8NYfvQIQMXW0BdQaZl51XoB3cSgkDIbn12Vu9+wvsvHdeIsaxlqUS6IPPRWHyt8aN AM9GEntC14OeXG5JrJnVgxIDxFLpDkbStHzlPqRq9UVaM2ptF5eYGVkOaaXnR3Abt/YB Msn1Z7nwDnggwh8ZV2CW6nV38nrEXoq+LSejOnTaEEup0l/GpRbQ3azNLw9Xqq0AXf+v W8MSFfGwwgzr/UkkbfSR7nvUfsdh4us6dobiP6dk10os8GcW6WdqwIcSnurhZXC8c88D BryTxqSvhjeHLbIfN4WfgmNSnRoa07I0LvTsQmnIYPkGsWBBtLr15LMG7gTdDW79OEwS c8jg== 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=RnkdTkQFlJ5KchOTAzJKV4GgUfnhHfZXksvackKTzbc=; b=ftFUoc95Drz2lwTmQ7Z2SmAKFrgA7MbypCjUDa4I2odV7T1HeMKlaB8CIl2wgD+Y1/ HmwcX7vuJq0+6mcZ82nyviFMV5ogMZtMF54K3DvROJuvoXXgTL7n7nhI9atibjvksOcQ TxbCz9FSVoWQEYkLOzmXLG3gp86juzPrv0lVjcR/cDiOisqlBPRW4tjfELA5uQbLPeU1 d0CnrklAheNEs3zia4EnPczPU1OA3s+n0w61oDScxIn3jpEg2INie9E7SUo/wkEexzFs dAeBo8E5K0T7vnge5Q8zdSlMwU2u5UtnRHEK87RQn1n5OiE+Y2HclYkF1K88ecY3LX7V 0ZIQ== X-Gm-Message-State: AODbwcCh+XxnAYVZEULQrfo7jEzYCHlf3de6xHhT/oAFlOYzMCQYgv2b wTCvhx/v9zjPFx4hXu7SVSiJCPuRPA== X-Received: by 10.37.194.66 with SMTP id s63mr17430402ybf.119.1495458268383; Mon, 22 May 2017 06:04:28 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Mon, 22 May 2017 06:04:27 -0700 (PDT) In-Reply-To: <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> From: Alan Somers Date: Mon, 22 May 2017 07:04:27 -0600 X-Google-Sender-Auth: b-nPnkSgdIQ5Zo6xovy3KDhPCco Message-ID: Subject: Re: anti-dog-piling and ntpd leap files To: Dirk-Willem van Gulik Cc: RW , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:04:29 -0000 On Mon, May 22, 2017 at 6:07 AM, Dirk-Willem van Gulik wrote: > >> On 22 May 2017, at 13:53, RW via freebsd-hackers wrote: >> >> On Mon, 22 May 2017 12:01:29 +0200 >> Dirk-Willem van Gulik wrote: >> >>> Just wondering - how is the new ntpd leapfile fetching supposed to >>> work. I spot a dead normal entry: > ... >>> That is not supposed to happen ? Correct ? >> >> From the ps output it looks like there's one normal 480.leapfile-ntpd >> process and two more running in jails. > > > Thank you. Palm, face, etc. Been staring at this for quite bit. > > Much appreciated, > > Dw. BTW, in 11.1 the sleeps will all be < 1 hour and they won't be backgrounded anymore. From owner-freebsd-hackers@freebsd.org Mon May 22 13:31:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F050D787EC for ; Mon, 22 May 2017 13:31:09 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 561621E0F for ; Mon, 22 May 2017 13:31:09 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr0-x244.google.com with SMTP id w50so6954909wrc.0 for ; Mon, 22 May 2017 06:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=6qi1k91NmuGSQciPmi0+fKTnSllbCBOghfLHMVaHdiM=; b=K/162llKGksK6QFsAeLUYuffh9rqRPL+65EyCV4Eb/fmwAkJbHeP1Q9shNKet5SU1e CXsc4wge36LaXf/GCJq+ZXLCFmiFcrOL2ywOTQ4FmH2s1yJ2EtwbXXQ4LnDoYpsqTe6h z0HYrSt8aX9u8n2rjDvKMPH99VLZ3qUKxJqvWQxWRdpQLwbwREf8xYnk9w7weiHWPP4E /LIj9btiRVtZKGqv02O8rhX1ZACgCnzTAIQ7Xw7uyih3qgtlYVHhlC6/zFcX4EY1SlsH rzZ+4efWI1JsplPbbc0g3HjOVTCCowBCyotFRM/NBNIRgzgyNMWhnv7Bp9zBV5GVs58h KWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6qi1k91NmuGSQciPmi0+fKTnSllbCBOghfLHMVaHdiM=; b=oYSnSeZL0HVHRPQSadLD53fpoyIf5HY24FsgYWBQGDymSqrvAMuDyOBU3rxaKzv0Ih L215VWlWFxso38dk+BIqsDclv51oEhZ2xR5rwzH3sjRPM6f66mwFWCD6fHxm2sT7W954 HAXgk4u1yv3toSD2sRG24b6S4Fi9ipDuPFEFXBKBvlsYdTnwpCbtQ6cQA5SziePNN66i WAtsjXcU2xMpvmMPDyyLuAmDStBYjLCTyKm+xRnE+e+KA8fDuBbXJkaarAH+UKQ7JrpD P6HdXb9kWQQh8hQBI9bhaP7xuYZE0X9njuZgSUhXM9kXUGlQ5iB1BBZRV3W9TG0V33uw lpAw== X-Gm-Message-State: AODbwcCobx53ZWn1OYX5DrXsU0MVUt6sFqSo60Ls1b7BT1SQ1ve9ikwX ilPAru4bYaRSoi3F X-Received: by 10.223.139.199 with SMTP id w7mr13173663wra.92.1495459866943; Mon, 22 May 2017 06:31:06 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id n49sm18139478wrn.30.2017.05.22.06.31.04 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 May 2017 06:31:05 -0700 (PDT) Date: Mon, 22 May 2017 14:31:02 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: anti-dog-piling and ntpd leap files Message-ID: <20170522143102.70035d8d@gumby.homeunix.com> In-Reply-To: References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:31:09 -0000 On Mon, 22 May 2017 07:04:27 -0600 Alan Somers wrote: > >>> Just wondering - how is the new ntpd leapfile fetching supposed to > >>> work. I spot a dead normal entry: > > BTW, in 11.1 the sleeps will all be < 1 hour and they won't be > backgrounded anymore. That doesn't sound like a good idea. If they aren't backgrounded they'll block the rest of periodic daily for up to an hour. Not much of a problem on a server, but it would be when periodic is run from anacron at boot time. From owner-freebsd-hackers@freebsd.org Mon May 22 14:09:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643C8D78220 for ; Mon, 22 May 2017 14:09:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 16FFC16F0 for ; Mon, 22 May 2017 14:09:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22b.google.com with SMTP id b68so60299027ywe.3 for ; Mon, 22 May 2017 07:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Hh/sJI4i1lmAJygdR6tM0Inj2bW10X/U0+DhN1HckBE=; b=Y7PATuCHpLyoxADfWNu+OLgsMdGxJvRmHV4nRrEq30+r9IaacTFhk+PM1HC/3Vil/+ bziEeZ6txoMI3Q1o7OntTCnN414WiVnHP+TancpeGQLgdygF8pdII92ViayG0BwPId0Y 8+3r79wNaxdkLD61V6PQ6E6LpQ3ULy7rTBzXuSFSUEAXERIziA/cZIaQFcDXvFiO7M5f NzSaDiV5L6l0+1dZ5cbuoceBnz1PzukPQWZNiDEYCNk9qGcjNuUhaidpmTDcAkaCwltG WbSSa3nALpzdRi0V5iMIDkIvlFQ8iL0gG4boAMV0RbugI/d/GDcmVr9KCWHn7h55s85p QhTw== 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=Hh/sJI4i1lmAJygdR6tM0Inj2bW10X/U0+DhN1HckBE=; b=fC3dQxKOwy7gj6OddXG67v0ykeiUZgww9YWb2may/INuW7fCeY8BaTPK7pG+gBaJPb q3g2iekc+fBvHie3lzrHZ4EDJ4d3X/LDKy2vicPgwnpPsUfAQrma7bra4ghR+hJBmW4m DuDDWun958Wvpa/SKPOz+E9x/hVepmTAUyhcNR14rsy4b8w01RaK2K4LBSygjDIE6AGQ tA256wjdkumqP5Hc8aKwbxVH3tLyEEsP/YvTYnGIfEIgzcgqNcMZTHNOJE9q6AanIJmA raL4OsNPIBShBBEvV37vJkJNRlRg3wKWExJtGxh78mzjqONPhuv5KmEUK+X09kwq1S1u gB0g== X-Gm-Message-State: AODbwcC/bmIqgrzkAfEStxdxV4NcpwQnxIjGTKG8MY/Rnj68kDDjuvqc AxUZgimHLq0d+cFMKvtlS4Xm+IqEYg== X-Received: by 10.129.75.72 with SMTP id y69mr21531714ywa.123.1495462195121; Mon, 22 May 2017 07:09:55 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Mon, 22 May 2017 07:09:54 -0700 (PDT) In-Reply-To: <20170522143102.70035d8d@gumby.homeunix.com> References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> <20170522143102.70035d8d@gumby.homeunix.com> From: Alan Somers Date: Mon, 22 May 2017 08:09:54 -0600 X-Google-Sender-Auth: qQHaHQC7jHM553ckWfpagrGumk8 Message-ID: Subject: Re: anti-dog-piling and ntpd leap files To: RW Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 14:09:56 -0000 On Mon, May 22, 2017 at 7:31 AM, RW via freebsd-hackers wrote: > On Mon, 22 May 2017 07:04:27 -0600 > Alan Somers wrote: > > >> >>> Just wondering - how is the new ntpd leapfile fetching supposed to >> >>> work. I spot a dead normal entry: > >> >> BTW, in 11.1 the sleeps will all be < 1 hour and they won't be >> backgrounded anymore. > > That doesn't sound like a good idea. If they aren't backgrounded > they'll block the rest of periodic daily for up to an hour. Not much of > a problem on a server, but it would be when periodic is run from anacron > at boot time. Actually, there are already many periodic scripts from ports that include foreground sleeps, mostly notably 410.pkg-audit. Do those cause problems for anacron? I wouldn't think so, because anacron knows to restart a job that didn't complete the last time it was run. From owner-freebsd-hackers@freebsd.org Mon May 22 12:12:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44E6CD77CE3 for ; Mon, 22 May 2017 12:12:12 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA561A28 for ; Mon, 22 May 2017 12:12:11 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 2B60DBB4; Mon, 22 May 2017 07:12:10 -0500 (CDT) Date: Mon, 22 May 2017 07:12:09 -0500 From: Mark Linimon To: Dirk-Willem van Gulik Cc: RW , freebsd-hackers@freebsd.org Subject: Re: anti-dog-piling and ntpd leap files Message-ID: <20170522121208.GA1417@lonesome.com> References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 22 May 2017 14:13:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:12:12 -0000 On Mon, May 22, 2017 at 02:07:35PM +0200, Dirk-Willem van Gulik wrote: > Thank you. Palm, face, etc. Been staring at this for quite bit. Happens to all of us. mcl From owner-freebsd-hackers@freebsd.org Mon May 22 19:11:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C64E3D79BC4 for ; Mon, 22 May 2017 19:11:36 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from h1929017.stratoserver.net (jstimpfle.de [85.214.245.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90E2D1E2D for ; Mon, 22 May 2017 19:11:35 +0000 (UTC) (envelope-from jfs@jstimpfle.de) Received: from jfs by h1929017.stratoserver.net with local (Exim 4.84_2) (envelope-from ) id 1dCsjn-0007Jf-CK for freebsd-hackers@freebsd.org; Mon, 22 May 2017 21:11:27 +0200 Date: Mon, 22 May 2017 21:11:27 +0200 From: Jens Stimpfle To: freebsd-hackers@freebsd.org Subject: Re: Improved Red-black tree implementation Message-ID: <20170522191127.GB27949@jstimpfle.de> References: <20170514050220.GA768@jstimpfle.de> <591EA74A.3080500@embedded-brains.de> <20170520165303.GA22452@jstimpfle.de> <59227456.9020805@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59227456.9020805@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 22 May 2017 19:36:09 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 19:11:36 -0000 On Mon, May 22, 2017 at 07:17:10AM +0200, Sebastian Huber wrote: > >Considering memory savings, have you considered 2-pointer trees (no > >parent pointer)? They need a temporary search stack for insertion and > >deletion, but not for iteration ("threaded trees"). > > The RB and Eternally Confuzzled variants don't use a parent pointer as far > as I remember. I don't know "RB", but a few more words since both do not do too well in your bench, performance-wise. I know that Eternally Confuzzled uses a possibly easier to implement ("top-down") algorithm which is expected to be slower. A 2-ptr tree with a conventional implementation need not be much slower than a 3-ptr, or could in fact be faster due to memory savings. Here are measurements including an unpolished 2-ptr tree. Amd X2-250 (x86-64): ==================== SIL 3-pointer Red-black tree: 0.699s 0.646s 0.635s SIL 2-pointer Red-black tree: 0.856s 0.856s 0.856s STL std::set: 0.750s 0.751s 0.750s BSD RB tree: 0.804s 0.832s 0.828s Raspberry Pi 2 (ARM ???) ======================== SIL 3-pointer Red-black tree: 3.844s 3.841s 3.839s SIL 2-pointer Red-black tree: 4.002s 4.231s 3.954s STL std::set: 3.742s 3.786s 3.776s BSD RB tree: 4.112s 4.107s 4.105s That particular benchmark generates a random permutation of [0,2^16) in a flat array of C ints. It adds 2^15 random elements from that array to an empty tree and then makes another 2^15 operations, randomly chosen to be add, delete, or find (in 128-bursts) on random elements from the array. The variance in the measurements accounts for the randomly chosen array elements. There is no variance if I chose neighbouring elements or when the bench data is small enough to fit in the L1 cache (it's also about 100x faster). The measurements do not account for the performance disadvantage of 2-ptr that is having to "find", i.e. create a search stack, an (intrusively linked) element that you already hold in your hands, if you want to delete it or use it as a hint to add a similar element. This is to my knowledge the only case where maybe 2x slowdown can be expected. Jens From owner-freebsd-hackers@freebsd.org Mon May 22 23:11:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5079CD79B12 for ; Mon, 22 May 2017 23:11:10 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FB191964 for ; Mon, 22 May 2017 23:11:09 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABDFC310EEF4BBFFFE2CB4D9.dip0.t-ipconnect.de [IPv6:2003:d2:abdf:c310:eef4:bbff:fe2c:b4d9]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8244D172093 for ; Tue, 23 May 2017 01:11:07 +0200 (CEST) Date: Tue, 23 May 2017 01:11:05 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Improved Red-black tree implementation Message-ID: <20170522231105.GA24328@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170514050220.GA768@jstimpfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170514050220.GA768@jstimpfle.de> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 23:11:10 -0000 On Sun, May 14, 2017 at 07:02:20AM +0200, Jens Stimpfle wrote: > the BSD tree.h Red-black tree implementation has a design issue in that > it doesn't share code between generated instances. Each instanciated > tree costs about 3K of machine code (on amd64). Making multiple > instances means increased pressure on the instruction cache (often 64K > these days). NetBSD at least has created sys/rbtree.h and matching code in src/common/lib/libc/gen/rb.c ages ago. Joerg From owner-freebsd-hackers@freebsd.org Tue May 23 06:33:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C016D7A1E1 for ; Tue, 23 May 2017 06:33:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-13.reflexion.net [208.70.210.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E20161BB6 for ; Tue, 23 May 2017 06:33:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26532 invoked from network); 23 May 2017 06:37:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 May 2017 06:37:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 23 May 2017 02:33:48 -0400 (EDT) Received: (qmail 19644 invoked from network); 23 May 2017 06:33:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 May 2017 06:33:48 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B6125EC8B7B; Mon, 22 May 2017 23:33:47 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: TARGET_ARCH=powerpc: how to cause a dump from kernel thread without disturbing that thread's stack? Message-Id: Date: Mon, 22 May 2017 23:33:47 -0700 To: FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 06:33:51 -0000 I've been trying to track down an occasional kernel panic on an old PowerMac G5 so-called "Quad Core" used with 32-bit PowerPC FreeBSD. The panics report absurdly large exception figures and such --and it turns out the content matches some very low memory (not necessarily properly aligned for its starting address). The following is an as-if investigative example. The eventual details may differ. But, presuming that theses tests in these places were appropriate, I'd like to be able to cause a dump without making calls that update the contents of the stack for the kernel thread: I want see the original stack contents in the dump for its history. content. The calls to panic in the example code below would disturb the history available on the kernel-thread's stack, something I'd like to avoid. Is there a known FreeBSD technique for preserving such memory contents when getting a dump at a specific place? void powerpc_interrupt(struct trapframe *framep) { struct thread *td; struct trapframe *oldframe; register_t ee; td =3D curthread; if ((void*)framep <=3D (void*)0x1000) panic("0:bad framep: %p\n", = (void*)framep); if (0x2f00 <=3D framep->exc) panic("0:bad framep->exc: %x (%p)\n", = framep->exc, (void*)framep); CTR2(KTR_INTR, "%s: EXC=3D%x", __func__, framep->exc); switch (framep->exc) { . . . default: /* Re-enable interrupts if applicable. */ ee =3D framep->srr1 & PSL_EE; if (ee !=3D 0) mtmsr(mfmsr() | ee); if ((void*)framep <=3D (void*)0x1000) panic("1:bad framep: %p\n", = (void*)framep); if (0x2f00 <=3D framep->exc) panic("1:bad framep->exc: %x (%p)\n", = framep->exc, (void*)framep); trap(framep); } } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue May 23 07:33:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34FBDD7AABB for ; Tue, 23 May 2017 07:33:37 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6BC51475 for ; Tue, 23 May 2017 07:33:36 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dD4Js-0006pq-CJ for freebsd-hackers@freebsd.org; Tue, 23 May 2017 09:33:28 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dD4Js-0003rF-1o for freebsd-hackers@freebsd.org; Tue, 23 May 2017 09:33:28 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0FAE42A0929 for ; Tue, 23 May 2017 09:34:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vBzmkK5Br9m0 for ; Tue, 23 May 2017 09:34:08 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 9E7572A092A for ; Tue, 23 May 2017 09:34:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kHAG6uZq_jx8 for ; Tue, 23 May 2017 09:34:08 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id AF7CC2A0929 for ; Tue, 23 May 2017 09:34:07 +0200 (CEST) To: FreeBSD From: Sebastian Huber Subject: Why is _POSIX_SOURCE used instead of __BSD_VISIBLE in ? Message-ID: <742294fc-99db-3f9c-17a6-9aee7f42b066@embedded-brains.de> Date: Tue, 23 May 2017 09:33:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23409/Tue May 23 02:57:08 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 07:33:37 -0000 Hello, the Termios header , , etc. use sometimes=20 _POSIX_SOURCE directly to determine if a thing should be exposed to the=20 user, e.g. #ifndef _POSIX_SOURCE #define ONLCR 0x00000002 /* map NL to CR-NL (ala CRMOD) */ #define TABDLY 0x00000004 /* tab delay mask */ #define TAB0 0x00000000 /* no tab delay and=20 expansion */ #define TAB3 0x00000004 /* expand tabs to spaces */ #define ONOEOT 0x00000008 /* discard EOT's (^D) on output) *= / #define OCRNL 0x00000010 /* map CR to NL on output */ #define ONOCR 0x00000020 /* no CR output at column 0 */ #define ONLRET 0x00000040 /* NL performs CR function */ #endif /*_POSIX_SOURCE */ This circumvents the feature mechanisms of . Why is=20 __BSD_VISIBLE not used for this? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Tue May 23 13:00:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 114CCD7A23D; Tue, 23 May 2017 13:00:18 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [213.41.150.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A86F1939; Tue, 23 May 2017 13:00:16 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.2.3] (schroedinger.eikeo.com [192.168.2.3]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-8) with ESMTPSA id v4NCrhND028864 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 23 May 2017 14:53:49 +0200 Subject: Re: Issue with pkg upgrade on diskless workstation To: Mark Linimon Cc: FreeBSD Hackers , freebsd-ports@freebsd.org References: <20170514082046.GA15092@lonesome.com> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Message-ID: Date: Tue, 23 May 2017 14:53:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 13:00:18 -0000 BERTRAND Joël a écrit : > Mark Linimon a écrit : >> I am running a powerpc64 machine diskless but only with some awful hacks. >> I can make them available if need be, but I hope that someone else has a >> better recommendation for you. >> >> mcl >> > > Before the last pkg binary upgrade, this workstation ran fine. What kind > of hack do you use ? Some (bad) news. I have downloaded and built pkg from git repository. It runs better but is unable to achieve upgrade. Now, it stalls after it has downloaded all packages to upgrade: # /usr/local/sbin/pkg upgrade ... Number of packages to be removed: 3 Number of packages to be installed: 31 Number of packages to be upgraded: 254 Number of packages to be reinstalled: 45 The process will require 1 GiB more space. Proceed with this action? [y/N]: y pkg uses 100% of a CPU core: last pid:3557;load averages: 1.06, 1.14, 1.15 up 18+20:22:27 14:47:00 109 processes: 2 running, 105 sleeping, 2 zombie CPU: 25.3% user, 0.0% nice, 0.6% system, 0.2% interrupt, 73.9% idle Mem: 2465M Active, 3935M Inact, 1251M Wired, 743M Buf, 157M Free Swap: 8192M Total, 10M Used, 8182M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 3336 root 1 103 0 1029M 990M CPU3 3 67:09 98.60% pkg As I have written, this workstation is a diskless machine: $ df -h Filesystem Size Used Avail Capacity Mounted on 192.168.10.128:/srv/pythagore 523G 53G 444G 11% / devfs 1,0K 1,0K 0B 100% /dev procfs 4,0K 4,0K 0B 100% /proc fdescfs 1,0K 1,0K 0B 100% /dev/fd 192.168.10.128:/home 3,6T 439G 3,0T 12% /home Mount options for / are nfsv3,tcp,soft,intr,rw,async,nolockd (nolockd is mandatory to avoid locking error on server side). For /home, nfsv3,tcp,soft,intr,rw,async. I suppose that is bug is NFS related, but I'm not able to found a workaround. gdb crashes when I try to attach it on pkg process : root@pythagore:~ # gdb -p 3336 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Attaching to process 3336 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) NFS server is a 7.0.2 NetBSD (that runs without any trouble). Best regards, JKB From owner-freebsd-hackers@freebsd.org Tue May 23 13:55:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F771D7A66C for ; Tue, 23 May 2017 13:55:09 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 52614179A for ; Tue, 23 May 2017 13:55:09 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id u75so130341858qka.3 for ; Tue, 23 May 2017 06:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ipsouqz7YYRBJehuECEpeeTz3nMiPAToxEtcjYBJnsM=; b=FvS3ESeRmjvm/w0GYLZ5UKVh12gWjXnLtOE7XOKHO+cNX0hqGNivkeJkwvC7/35893 cBQyB1HOKPiBuAQS6u/fdzuOPcdF8wOdbwhyQ63mSFzd7RfcG/wpTniPZk5iHiBAfUNd dOD3uTTs+3ppGfNmDefRXuRyzr93NWBPDvpLFlkewzCd+qX6a71jpXgSObjF4BfAd+61 Pq3m/N5QQ9iPDk+Wz72pK7fRi5B8wTjSUWfZPZ0UT22r8Bin8v4drllMvAm08pZ/eKim l7W23kYivn+szjxxbszViqMyMAk9nGM+Qjs8D3ooYMnUkWXqxa4GvvibIviTTz6+rnCF 1MkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ipsouqz7YYRBJehuECEpeeTz3nMiPAToxEtcjYBJnsM=; b=TuvECJ+nXYIZgcDQRktMFQ14DPYfBczWwGnR9h3zc3oK/Fhm2iNqxw3vCrJRW32B3b 8qxLulotHDTaoaYpdoiOHOrx7jWt3ImARGc0C2OgfBkwPjBd+efh2U/FERG+LE9w4AYu 1/S2g97bg/V/aoPlUb15lezJHj/CSsS6vVw8mAOCa64So8vpfzmSGEdLEAfYuzYRAwSw iTz4P/BsHw+FygVGRSLjAMRhTN5FJuz3GqpS3UYnVZYqpLdz0QQpIfZfcXppXyD4jdH7 HGfdvVs2XqfLdKhQZSX20VdJTCHWXlw2G9D5Sn2NKgy0heEtd3TiNgdp+sS7M5YgSMvS Ryaw== X-Gm-Message-State: AODbwcB7SDzDXNT/8oCf8DDMDUKTKhOyOzqix2CGFkqOyOxYYJ3PpsLu +/WSj2MOyV+s4jkcYPUUvFzfCt/SxAV6 X-Received: by 10.55.221.8 with SMTP id n8mr24842146qki.103.1495547708208; Tue, 23 May 2017 06:55:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.49.85 with HTTP; Tue, 23 May 2017 06:55:07 -0700 (PDT) From: karnajit wangkhem Date: Tue, 23 May 2017 19:25:07 +0530 Message-ID: Subject: Seventh argument seen in mmap on i386 To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 23 May 2017 13:59:58 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 13:55:09 -0000 Hi All, I am trying to understand this scenario where a seventh argument is seen in case of freebsd.x-i386. As per the mmap man page, the libc function prototype takes in 6 arguments. Ktrace shows the following // Freebsd-11.0 =E2=80=93 i386 box 44416 a.out CALL mmap(0,0x1000,0x7,0x1002,0xffffffff,0,0) 44416 a.out RET mmap 671535104/0x2806d000 // Freebsd-11.0 =E2=80=93 amd64 box 366 a.out CALL mmap(0,0x1000,0x7,0x1002,0xffffffff,0) 366 a.out RET mmap 34366287872/0x80063f000 Also, the disassemble code show that an extra argument was pushed in i386 case -> 0x80485e6 <+38>: movl %esp, %ebx 0x80485e8 <+40>: movl $0x0, 0x18(%ebx) 0x80485ef <+47>: movl $0x0, 0x14(%ebx) 0x80485f6 <+54>: movl $0xffffffff, 0x10(%ebx) ; imm =3D 0xFFFFFFFF 0x80485fd <+61>: movl $0x1002, 0xc(%ebx) ; imm =3D 0x1002 0x8048604 <+68>: movl $0x7, 0x8(%ebx) 0x804860b <+75>: movl $0x1000, 0x4(%ebx) ; imm =3D 0x1000 0x8048612 <+82>: movl $0x0, (%ebx) Please help me understand why this extra argument is seen in case of i386. Regards, Karan From owner-freebsd-hackers@freebsd.org Tue May 23 14:06:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE770D7AA9B for ; Tue, 23 May 2017 14:06:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9441F7C for ; Tue, 23 May 2017 14:06:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4NE61u7077295 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 May 2017 17:06:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4NE61u7077295 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4NE61Pl077294; Tue, 23 May 2017 17:06:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 May 2017 17:06:01 +0300 From: Konstantin Belousov To: karnajit wangkhem Cc: freebsd-hackers@freebsd.org Subject: Re: Seventh argument seen in mmap on i386 Message-ID: <20170523140601.GD1622@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 14:06:11 -0000 On Tue, May 23, 2017 at 07:25:07PM +0530, karnajit wangkhem wrote: > Hi All, > > > > I am trying to understand this scenario where a seventh argument is seen in > case of freebsd.x-i386. As per the mmap man page, the libc function > prototype takes in 6 arguments. > > > Ktrace shows the following > > // Freebsd-11.0 ??? i386 box > > 44416 a.out CALL > mmap(0,0x1000,0x7,0x1002,0xffffffff,0,0) > > 44416 a.out RET mmap 671535104/0x2806d000 > > > > // Freebsd-11.0 ??? amd64 box > > 366 a.out CALL > mmap(0,0x1000,0x7,0x1002,0xffffffff,0) > > 366 a.out RET mmap 34366287872/0x80063f000 > > > > Also, the disassemble code show that an extra argument was pushed in i386 > case > > > > -> 0x80485e6 <+38>: movl %esp, %ebx > > 0x80485e8 <+40>: movl $0x0, 0x18(%ebx) > > 0x80485ef <+47>: movl $0x0, 0x14(%ebx) > > 0x80485f6 <+54>: movl $0xffffffff, 0x10(%ebx) ; imm = 0xFFFFFFFF > > 0x80485fd <+61>: movl $0x1002, 0xc(%ebx) ; imm = 0x1002 > > 0x8048604 <+68>: movl $0x7, 0x8(%ebx) > > 0x804860b <+75>: movl $0x1000, 0x4(%ebx) ; imm = 0x1000 > > 0x8048612 <+82>: movl $0x0, (%ebx) > > > > > > Please help me understand why this extra argument is seen in case of i386. off_t is 64bit. It is not seventh arg, it is offset which takes two words. From owner-freebsd-hackers@freebsd.org Tue May 23 14:46:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA80ED7A043 for ; Tue, 23 May 2017 14:46:59 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 687AC1FBF for ; Tue, 23 May 2017 14:46:59 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from host-4-75.office.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 86A1D64CF for ; Tue, 23 May 2017 14:46:54 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/86A1D64CF; dkim=none; dkim-atps=neutral Subject: Re: Issue with pkg upgrade on diskless workstation To: freebsd-hackers@freebsd.org References: <20170514082046.GA15092@lonesome.com> From: Matthew Seaman Message-ID: Date: Tue, 23 May 2017 15:46:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J08H4m5aP8CK5UhCW57qlshllS9J08mxs" X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,RCVD_IN_RP_RNBL, RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 14:47:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J08H4m5aP8CK5UhCW57qlshllS9J08mxs Content-Type: multipart/mixed; boundary="LxasCtt3aPHuOxVjVwLgKMOggnD1DO6N7"; protected-headers="v1" From: Matthew Seaman To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: Issue with pkg upgrade on diskless workstation References: <20170514082046.GA15092@lonesome.com> In-Reply-To: --LxasCtt3aPHuOxVjVwLgKMOggnD1DO6N7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017/05/23 13:53, BERTRAND Jo=EBl wrote: > I suppose that is bug is NFS related, but I'm not able to found a > workaround. gdb crashes when I try to attach it on pkg process : Have you tried toggling the value of NFS_WITH_PROPER_LOCKING in pkg.conf? It defaults to off, which switches to an alternate but not as good locking strategy when pkg detects that its database (/var/db/pkg) is on an NFS mount -- if you have a usable lockd, try setting that to tru= e. Yes, the base system gdb doesn't work very well to debug pkg(8) built from source. Try installing gdb from ports -- although I realise there may be a bit of a chicken and egg problem there. Cheers, Matthew --LxasCtt3aPHuOxVjVwLgKMOggnD1DO6N7-- --J08H4m5aP8CK5UhCW57qlshllS9J08mxs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJZJEtdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTncJwP+QGDVeOtVWAUw/foZmDZtBya 8FQb/IkAJorByUinDs/9rUlh8jxnerYrUNbXrDjpYx8yyJ9MZqkp6reGYt1F5RbX jDQpC8/4FpwEliuctVCb94gI/TU/UtAVp72ZrrkigBGv/Af+1jtkHlP2IkCcR/E1 tgEVlpVL9zL0StF+nzXyXsxdhqRso1wEPxwENx84Ovns40ymab/iyEMFK6LPD1HY VuM+ERm5D6uTbnLaCvPupurCX7pHglJwB9pkfKjrmkxwlvfzSxPDIcVUFFyF7FIR sS9fEMaZkq3pe/Yo+gzqKoIpPVUHa2uaw6dvWMdEIOI4tyFrHZiiy+ULttxZBb2M RKWQmYxYYW7akdViy8epT/BmmvD283j/EJ712UVThk0gf2QH035qe44YIX+J4CGB FtNaCtwrRSYh4KlRQ6hiUuLdFBd/HI+aaZqdr016dQs+Hh0pyloEjvK6SKOqxAhZ 6OlbeeGHdQ1cJi9vUhjyhgM/bVI61hOKouAS5FDHa74awrpBK3E407WKNTRR4K5v njJ3KpPoNS9P5NzIy5c/HSJBkT0BtlxdAO/VwyI93UuKFcwL7t9JeMrCpBi3S9sV Vd9kUjyQjPesXdEI+LaPH/wMow/r1kBB77znVcRApcqdD5Liicsfk2haRgprYgWJ nk4SsMvJRcpTAkpsdUVk =2wDL -----END PGP SIGNATURE----- --J08H4m5aP8CK5UhCW57qlshllS9J08mxs-- From owner-freebsd-hackers@freebsd.org Tue May 23 21:54:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F5C4D7B97B for ; Tue, 23 May 2017 21:54:58 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [213.41.150.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A0C21A0F; Tue, 23 May 2017 21:54:57 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.254.1] (bertrand@rayleigh.systella.fr [192.168.254.1]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-8) with ESMTPSA id v4NLsfmv027613 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 23 May 2017 23:54:41 +0200 Subject: Re: Issue with pkg upgrade on diskless workstation To: Matthew Seaman , freebsd-hackers@freebsd.org, pkgsrc-users@pkgsrc.org References: <20170514082046.GA15092@lonesome.com> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Message-ID: Date: Tue, 23 May 2017 23:54:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 21:54:58 -0000 Matthew Seaman a écrit : > On 2017/05/23 13:53, BERTRAND Joël wrote: >> I suppose that is bug is NFS related, but I'm not able to found a >> workaround. gdb crashes when I try to attach it on pkg process : > > Have you tried toggling the value of NFS_WITH_PROPER_LOCKING in > pkg.conf? It defaults to off, which switches to an alternate but not as > good locking strategy when pkg detects that its database (/var/db/pkg) > is on an NFS mount -- if you have a usable lockd, try setting that to true. I have tried with and without NFS_WITH_PROPER_LOCKING with the same result. pkg stalls after: Number of packages to be removed: 3 Number of packages to be installed: 31 Number of packages to be upgraded: 254 Number of packages to be reinstalled: 45 The process will require 1 GiB more space. Proceed with this action? [y/N]: y Server (legendre) runs NetBSD 7.0.2 with rpc.lockd (that perfectly works with Linux and NetBSD NFSv3 clients). Only FreeBSD clients (for example pythagore) trigger errors on server side: May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore May 23 23:21:03 legendre rpc.lockd: duplicate lock from pythagore.5118 May 23 23:21:03 legendre rpc.lockd: no matching entry for pythagore Regards, JKB From owner-freebsd-hackers@freebsd.org Tue May 23 22:31:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7ED1D783BD for ; Tue, 23 May 2017 22:31:05 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 69D681051 for ; Tue, 23 May 2017 22:31:05 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x244.google.com with SMTP id k15so41621304wmh.3 for ; Tue, 23 May 2017 15:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=l71OpBVdj9u1qdl8m7qR3tUOFVvqexWiAFIjhCPvAVA=; b=pFY+Ff38mfVsoT4t3QhmYDnLbxtnFiaNnjyQq85crHgOYIOB+gqlM6zHAD5D2SJy7+ 5KCJxwMq193JEBqskJtfXa5dY4Rr6NhG//5TBwe186X9jk240gTzJlp+cBh1mc0Df6pE 5dqWZkcHy72kLPyKbHnFVGXdvj+JHXuN0Vqeucve78lnDDHFaTRxmg7bv8/YOwP2EPVs K3Km8VAmg/XV2tJF6iS1uvCE3s95P/VQcn1cSC0+/jFL5VVx9zGrHpBJND4rtkMUTh+5 MCMW2fWHxvBFJO3T5fkHhMjS4oYS2sWDXyG5QYR5/zZrCbwyZhb01XKAZC0fHO3dtso1 vsaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=l71OpBVdj9u1qdl8m7qR3tUOFVvqexWiAFIjhCPvAVA=; b=QKsH2YwI5rVtLd5RwGGBgkUY9Hm+hE8rznX1A7DxAp6J/nCq71Z70n+8MuoD2aV9J9 2wuP9jQ7lBVXNupVIiPN1+U/IobnY/BvVHWoGLR10bq/TbGzJfYe9v8d8FMntXH4RAOQ 0TxDtxK/2EWNfvxRUQoIBVaY7ZWmYG9bHBksPjimSgTmdl/hh4h6potakOSXNJVDXw96 tFSdNLKK9keDr0jp62JDc0WsaqCLR82DnJ920zbH3oNdP+tNF+z5keKxUbMTrtSTBMxB PVdukRZNZ4fP3xLFnoMuf0K4iV2mh/hKE6HDsIcO+y7GnLdBYhzXUbvpjEFNfvQNxncm rfew== X-Gm-Message-State: AODbwcA7ZU+TBVbRdQ+1wq2Y/HwfUIaFS+q6JOKyPEf9SQJrkKOJyGqX 8CuVtCDwjAif13Xd X-Received: by 10.223.161.194 with SMTP id v2mr19051539wrv.132.1495578663422; Tue, 23 May 2017 15:31:03 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id w18sm1620251wmw.26.2017.05.23.15.31.01 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 May 2017 15:31:02 -0700 (PDT) Date: Tue, 23 May 2017 23:30:57 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: anti-dog-piling and ntpd leap files Message-ID: <20170523233057.59cd2393@gumby.homeunix.com> In-Reply-To: References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> <20170522143102.70035d8d@gumby.homeunix.com> X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 22:31:05 -0000 On Mon, 22 May 2017 08:09:54 -0600 Alan Somers wrote: > On Mon, May 22, 2017 at 7:31 AM, RW via freebsd-hackers > wrote: > > That doesn't sound like a good idea. If they aren't backgrounded > > they'll block the rest of periodic daily for up to an hour. Not > > much of a problem on a server, but it would be when periodic is run > > from anacron at boot time. > > Actually, there are already many periodic scripts from ports that > include foreground sleeps, mostly notably 410.pkg-audit. I didn't know that and I think there is a POLA violation there because if you run "time periodic daily" from a terminal there is no warning that delays are being skipped. This happens in the new version too. > Do those > cause problems for anacron? I wouldn't think so, because anacron > knows to restart a job that didn't complete the last time it was run. It's more about knowing when they run. I have some local scripts that aren't entirely atomic, nothing catastrophic would happen if they were interrupted, but I'd rather they completed. I've been avoiding shutting down during what I thought was a very narrow window, but turns out to be 75 minutes wider than I thought. Another thing is that periodic tasks can be I/O and CPU intensive and some people may be good reason to get them out of the way at boot time, rather than have them randomly kick-in. The updated version is an improvement because the single delay can be configured, but you have to know it's there. From owner-freebsd-hackers@freebsd.org Tue May 23 23:08:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5287BD78C44 for ; Tue, 23 May 2017 23:08:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 EF7E11157 for ; Tue, 23 May 2017 23:08:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id l74so81785135ywe.2 for ; Tue, 23 May 2017 16:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dGmzOieipNteT0zUq09w2Gf0gwblQQjJ3gpTZMGY8oQ=; b=PXb/uL926mTtxFUuvF025FZpPqpTmLL4C8rNXWcnhn1vy6HkbFWRgBPox4V5la+ugC GMyhcjKJ8KxkEwi4s39rnqOA7/eNAyQoTmidJrHlOO6/k6T0ZNH7PXgbzNFhUPY6wc8I QEDO2E0/+8xwEFz+jkQqGIGHTFVfYuwOMGZXYil12cwIj7LYcJ2hlwFWF+a4Z3fbHEZU Vc7zJ8rlU2hpR7u76lFDG6sJAAZ08XpmEEoTiI2wpiZDGD2dHzE7+miniO2q4eSEibJl LhLeHx6P+Qv1LwKJKydhOvV5+EfjosW9D6F0o8RBkm9lwto1tJrGnJv1NWEgiuDsEr7f k4FQ== 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=dGmzOieipNteT0zUq09w2Gf0gwblQQjJ3gpTZMGY8oQ=; b=Y24qzxpdYxNhBXShPAjfzr/SSpYvs7RM7H0H3yr3CG1mbPIja6eWskMxTYOMu4OqH8 kd+1htluiSG/fJiznoYlVswqaxbjv2K6bdoR/e+sD851YU4+MvfI0IBSL2qaMnwszf72 pKiF8gcKj/7UiUgOROjDiUDvIJjfFUphdeXIb2zzT0tUYkDBy9I/eqNcQffBMt/EjpXH xVUS8WS/TPIdiOEX7+ykkgDDqbdvBvH2G6AWCnEWMIhNQA1w3H/Upk2jy8U+cvkjBUml 0J99Q4SFTLfReriWJwOP4ZCbdU77zr1/Cazym+WKTEGauXXJvAnhFM6j0Ob1ZlJIKyQ8 y19Q== X-Gm-Message-State: AODbwcB7JkFiVRDOVfuiLR9WYpeRMGTL8nkeXUhUPWUxF07MMWj+SWiX U44ujgUq00LEWAgOtmuB5CN4BpY37Q== X-Received: by 10.13.212.68 with SMTP id w65mr4216223ywd.279.1495580881097; Tue, 23 May 2017 16:08:01 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Tue, 23 May 2017 16:08:00 -0700 (PDT) In-Reply-To: <20170523233057.59cd2393@gumby.homeunix.com> References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> <20170522143102.70035d8d@gumby.homeunix.com> <20170523233057.59cd2393@gumby.homeunix.com> From: Alan Somers Date: Tue, 23 May 2017 17:08:00 -0600 X-Google-Sender-Auth: rnsXCUR7gFuhUXj7f5JD5LsGRsU Message-ID: Subject: Re: anti-dog-piling and ntpd leap files To: RW Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 23:08:02 -0000 On Tue, May 23, 2017 at 4:30 PM, RW via freebsd-hackers wrote: > On Mon, 22 May 2017 08:09:54 -0600 > Alan Somers wrote: > >> On Mon, May 22, 2017 at 7:31 AM, RW via freebsd-hackers >> wrote: > >> > That doesn't sound like a good idea. If they aren't backgrounded >> > they'll block the rest of periodic daily for up to an hour. Not >> > much of a problem on a server, but it would be when periodic is run >> > from anacron at boot time. >> >> Actually, there are already many periodic scripts from ports that >> include foreground sleeps, mostly notably 410.pkg-audit. > > I didn't know that and I think there is a POLA violation there because > if you run "time periodic daily" from a terminal there is no warning > that delays are being skipped. This happens in the new version too. I don't see this as a problem, because when you run "periodic daily" from the terminal there is no need for any sleeping. The sleeps only matter when periodic is run by cron at a predictable time. And the periodic mechanism is only used for batch-like scripts that shouldn't care about the precise time at which they run. > >> Do those >> cause problems for anacron? I wouldn't think so, because anacron >> knows to restart a job that didn't complete the last time it was run. > > It's more about knowing when they run. I have some local scripts that > aren't entirely atomic, nothing catastrophic would happen if they were > interrupted, but I'd rather they completed. I've been avoiding > shutting down during what I thought was a very narrow window, but > turns out to be 75 minutes wider than I thought. > > Another thing is that periodic tasks can be I/O and CPU intensive and > some people may be good reason to get them out of the way at boot time, > rather than have them randomly kick-in. Like I said, the sleeps are only useful when periodic is run at a predictable time, which is not the case when you run anacron at boot. It would be reasonable to disable sleeping in that case, just like when running from the terminal. Can you suggest how? -Alan From owner-freebsd-hackers@freebsd.org Wed May 24 05:56:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DB80D79E4A for ; Wed, 24 May 2017 05:56:04 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A08916B8 for ; Wed, 24 May 2017 05:56:03 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dDPH6-0007LD-Sl for freebsd-hackers@freebsd.org; Wed, 24 May 2017 07:56:00 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dDPH6-0000Qj-10 for freebsd-hackers@freebsd.org; Wed, 24 May 2017 07:56:00 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 15F0D2A0929 for ; Wed, 24 May 2017 07:56:42 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vrTu4OzuHPrK for ; Wed, 24 May 2017 07:56:39 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CC47B2A092A for ; Wed, 24 May 2017 07:56:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rOruI1905HNH for ; Wed, 24 May 2017 07:56:39 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id A5BDB2A0929 for ; Wed, 24 May 2017 07:56:39 +0200 (CEST) Subject: Re: Why is _POSIX_SOURCE used instead of __BSD_VISIBLE in ? From: Sebastian Huber To: FreeBSD References: <742294fc-99db-3f9c-17a6-9aee7f42b066@embedded-brains.de> Message-ID: <2517757f-0c8c-c500-a6ce-aec2f08e2aeb@embedded-brains.de> Date: Wed, 24 May 2017 07:55:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <742294fc-99db-3f9c-17a6-9aee7f42b066@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23412/Wed May 24 02:55:55 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 05:56:04 -0000 On 23/05/17 09:33, Sebastian Huber wrote: > Hello, > > the Termios header , , etc. use sometimes=20 > _POSIX_SOURCE directly to determine if a thing should be exposed to=20 > the user, e.g. > > #ifndef _POSIX_SOURCE > #define ONLCR 0x00000002 /* map NL to CR-NL (ala CRMOD) */ > #define TABDLY 0x00000004 /* tab delay mask */ > #define TAB0 0x00000000 /* no tab delay and=20 > expansion */ > #define TAB3 0x00000004 /* expand tabs to spaces *= / > #define ONOEOT 0x00000008 /* discard EOT's (^D) on=20 > output) */ > #define OCRNL 0x00000010 /* map CR to NL on output */ > #define ONOCR 0x00000020 /* no CR output at column 0 */ > #define ONLRET 0x00000040 /* NL performs CR function */ > #endif /*_POSIX_SOURCE */ > > This circumvents the feature mechanisms of . Why is=20 > __BSD_VISIBLE not used for this? > This was already changed in one spot: https://github.com/freebsd/freebsd/commit/e63fa4cfabc535a5f9ec7ea2b383692= 931c13465 There are not many places left using _POSIX_SOURCE directly. To me this=20 looks like someone forgot to update the Termios headers to use the=20 visibility defines. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Wed May 24 06:08:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18930D7B1FE for ; Wed, 24 May 2017 06:08:04 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE8281B99 for ; Wed, 24 May 2017 06:08:03 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dDPSi-0007sx-GW for freebsd-hackers@freebsd.org; Wed, 24 May 2017 08:08:00 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dDPSi-0005B1-1V for freebsd-hackers@freebsd.org; Wed, 24 May 2017 08:08:00 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EC2D62A0929 for ; Wed, 24 May 2017 08:08:41 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pIlGsUa2S9ln for ; Wed, 24 May 2017 08:08:41 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 918562A092A for ; Wed, 24 May 2017 08:08:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1vGnRrbLEP8J for ; Wed, 24 May 2017 08:08:41 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 72A992A0929 for ; Wed, 24 May 2017 08:08:41 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] Use __BSD_VISIBLE for Termios headers Date: Wed, 24 May 2017 08:07:58 +0200 Message-Id: <20170524060758.25529-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.12.0 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23412/Wed May 24 02:55:55 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 06:08:04 -0000 The Termios headers and used sometimes _POSIX_SOURCE directly to determine if a thing should be exposed to the user. This circumvented the feature mechanisms of . Use __BSD_VISIBLE instead. --- include/termios.h | 8 ++++---- sys/sys/_termios.h | 44 ++++++++++++++++++++++---------------------- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/include/termios.h b/include/termios.h index ed8e328d7fd..333ab1cd6cc 100644 --- a/include/termios.h +++ b/include/termios.h @@ -42,12 +42,12 @@ typedef __pid_t pid_t; #define _PID_T_DECLARED #endif -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define OXTABS TAB3 #define MDMBUF CCAR_OFLOW #endif -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define CCEQ(val, c) ((c) == (val) && (val) != _POSIX_VDISABLE) #endif @@ -57,7 +57,7 @@ typedef __pid_t pid_t; #define TCSANOW 0 /* make change immediate */ #define TCSADRAIN 1 /* drain output, then change */ #define TCSAFLUSH 2 /* drain output, flush input */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define TCSASOFT 0x10 /* flag - don't alter h.w. state */ #endif @@ -95,7 +95,7 @@ __END_DECLS #endif /* !_TERMIOS_H_ */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #include #include #endif diff --git a/sys/sys/_termios.h b/sys/sys/_termios.h index de434bd5aa7..e6783cb8e50 100644 --- a/sys/sys/_termios.h +++ b/sys/sys/_termios.h @@ -42,15 +42,15 @@ */ #define VEOF 0 /* ICANON */ #define VEOL 1 /* ICANON */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VEOL2 2 /* ICANON together with IEXTEN */ #endif #define VERASE 3 /* ICANON */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VWERASE 4 /* ICANON together with IEXTEN */ #endif #define VKILL 5 /* ICANON */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VREPRINT 6 /* ICANON together with IEXTEN */ #define VERASE2 7 /* ICANON */ #endif @@ -58,18 +58,18 @@ #define VINTR 8 /* ISIG */ #define VQUIT 9 /* ISIG */ #define VSUSP 10 /* ISIG */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VDSUSP 11 /* ISIG together with IEXTEN */ #endif #define VSTART 12 /* IXON, IXOFF */ #define VSTOP 13 /* IXON, IXOFF */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VLNEXT 14 /* IEXTEN */ #define VDISCARD 15 /* IEXTEN */ #endif #define VMIN 16 /* !ICANON */ #define VTIME 17 /* !ICANON */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define VSTATUS 18 /* ICANON together with IEXTEN */ /* 19 spare 2 */ #endif @@ -91,16 +91,16 @@ #define ICRNL 0x00000100 /* map CR to NL (ala CRMOD) */ #define IXON 0x00000200 /* enable output flow control */ #define IXOFF 0x00000400 /* enable input flow control */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define IXANY 0x00000800 /* any char will restart after stop */ #define IMAXBEL 0x00002000 /* ring bell on input queue full */ -#endif /*_POSIX_SOURCE */ +#endif /* * Output flags - software output processing */ #define OPOST 0x00000001 /* enable following output processing */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define ONLCR 0x00000002 /* map NL to CR-NL (ala CRMOD) */ #define TABDLY 0x00000004 /* tab delay mask */ #define TAB0 0x00000000 /* no tab delay and expansion */ @@ -109,12 +109,12 @@ #define OCRNL 0x00000010 /* map CR to NL on output */ #define ONOCR 0x00000020 /* no CR output at column 0 */ #define ONLRET 0x00000040 /* NL performs CR function */ -#endif /*_POSIX_SOURCE */ +#endif /* * Control flags - hardware control of terminal */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define CIGNORE 0x00000001 /* ignore control flags */ #endif #define CSIZE 0x00000300 /* character size mask */ @@ -128,7 +128,7 @@ #define PARODD 0x00002000 /* odd parity, else even */ #define HUPCL 0x00004000 /* hang up on last close */ #define CLOCAL 0x00008000 /* ignore modem status lines */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define CCTS_OFLOW 0x00010000 /* CTS flow control of output */ #define CRTSCTS (CCTS_OFLOW | CRTS_IFLOW) #define CRTS_IFLOW 0x00020000 /* RTS flow control of input */ @@ -146,30 +146,30 @@ * input flag. */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define ECHOKE 0x00000001 /* visual erase for line kill */ -#endif /*_POSIX_SOURCE */ +#endif #define ECHOE 0x00000002 /* visually erase chars */ #define ECHOK 0x00000004 /* echo NL after line kill */ #define ECHO 0x00000008 /* enable echoing */ #define ECHONL 0x00000010 /* echo NL even if ECHO is off */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define ECHOPRT 0x00000020 /* visual erase mode for hardcopy */ #define ECHOCTL 0x00000040 /* echo control chars as ^(Char) */ -#endif /*_POSIX_SOURCE */ +#endif #define ISIG 0x00000080 /* enable signals INTR, QUIT, [D]SUSP */ #define ICANON 0x00000100 /* canonicalize input lines */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define ALTWERASE 0x00000200 /* use alternate WERASE algorithm */ -#endif /*_POSIX_SOURCE */ +#endif #define IEXTEN 0x00000400 /* enable DISCARD and LNEXT */ #define EXTPROC 0x00000800 /* external processing */ #define TOSTOP 0x00400000 /* stop background jobs from output */ -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define FLUSHO 0x00800000 /* output being flushed (state) */ #define NOKERNINFO 0x02000000 /* no kernel output from VSTATUS */ #define PENDIN 0x20000000 /* XXX retype pending input (state) */ -#endif /*_POSIX_SOURCE */ +#endif #define NOFLSH 0x80000000 /* don't flush after interrupt */ /* @@ -191,7 +191,7 @@ #define B9600 9600 #define B19200 19200 #define B38400 38400 -#ifndef _POSIX_SOURCE +#if __BSD_VISIBLE #define B7200 7200 #define B14400 14400 #define B28800 28800 @@ -203,7 +203,7 @@ #define B921600 921600 #define EXTA 19200 #define EXTB 38400 -#endif /* !_POSIX_SOURCE */ +#endif typedef unsigned int tcflag_t; typedef unsigned char cc_t; -- 2.12.0 From owner-freebsd-hackers@freebsd.org Wed May 24 08:00:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1ADC4D7BDF1 for ; Wed, 24 May 2017 08:00:54 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 CEC7319EE for ; Wed, 24 May 2017 08:00:53 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id c13so148631302qtc.1 for ; Wed, 24 May 2017 01:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zHvN2eN4lkybiMRNjEzDSpBZFM25xxAfIo80CU8PopA=; b=X1JDlsJTamtCSW2Op4oI+k8+xf/XnHmxB2s+6knNAPUczLmUSDEU37rBKMahN8LfFu 3whEkM6P/S7aGsSJzGNOlLIF5FBgvXgz7Xv/lXrteT4Pm08P+QVtgFwqag576R8b22dx 4RAAR9JxaDTvB+lnXXthm9LjLFvUgzYuUSUE/QwKtirGH1BOonGvZh/eICA6MFN2iBXf fZMv0FPD8g9HaEiXWY3cal3pVAw73uq9gGfST7uHz62D3l1jrv9e1Ag+7QKNsqrTUZih nUltFoe+C4/4EU7VjBSBRg6dm83NVB7GUFwK2hoyKjyILv7QKsVK8PRa1EDYVrfGRLHr X4wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zHvN2eN4lkybiMRNjEzDSpBZFM25xxAfIo80CU8PopA=; b=IDhixnu6brJ/EnKQAr+0DLUO+oGEWrnBW9bTfIG0U6NdJkQjIa00jPLBV4n7KR5VTE gYIoiUcLcPkNO5+UfYaCJuL/Hu5mEGyrYu+pXJcLgu6uj5KvxYH+dmxcAT29OwYYdTtl IVNHkbjdqPeLsjK19H97dHttbKpYSppa77/DqBHjutNNjfKTSUVmBVdg61i3tjVpW/HM jEd3QVIGxquJu27pDNWYz+BgtC1xK9uDCPoJvlrZTyUbaZ2ddlPuccBkOjrBQc6QNl68 520O1GM2bhf5UMr7HeOEPg5m53asD3Jca15gFvQvTZkMkk8JBD48BkjwjMqTSchKVWOn gCyg== X-Gm-Message-State: AODbwcDC0triYMCdiXrji7d1/bXjQ6x5NPqJDe0BlQYdfBBWasVXrO86 EcoEm2gcsWujafehJdKyr7HDkzMXLbu5 X-Received: by 10.200.40.46 with SMTP id 43mr33988746qtq.132.1495612852314; Wed, 24 May 2017 01:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.241 with HTTP; Wed, 24 May 2017 01:00:51 -0700 (PDT) From: Shrikanth Kamath Date: Wed, 24 May 2017 01:00:51 -0700 Message-ID: Subject: Difference between p_vmspace quota between stable/11 and stable/10 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:00:54 -0000 I have a certain application(32 bit user space running in compat mode in 64 bit system X86) which does a fork, and the child process does a series of mmap calls as part of a scaling test. I am currently debugging an issue with this application which hits a ENOMEM when it is run on a stable/11 based setup and fails subsequent mmap and/or any malloc calls v/s stable/10 where the issue is not seen.. I probed the vm_map_find function using DTrace when "execname" was my application in question, and got these readings fbt:kernel:vm_map_find:entry /self->trace == 1/ /*enabled only during sys_mmap call of this application */ { @bytes[args[4]] = sum(args[4]); printf("request length [%x]", args[4]); } For stable_10 --> Total of 124 requests (length requested was 0x500000) with the test successful 124 * 0x500000 (5MB) ~ 620MB For stable_11 --> Total of 109 mmap requests (0x500000/0x200000/0x3ff000 are the different vm_size_t length arguments in vm_map_find). The test fails after 386MB has been approved. 24 * 0x500000 (5MB) ~ 120MB 82 * 0x200000 (2MB) ~ 164MB 3 * 0x3ff000 (4MB) ~ 12MB The process parent rlimits are # cat /proc/5058/rlimit cpu -1 -1 fsize -1 -1 data 3221225472 3221225472 stack 16777216 16777216 core -1 -1 rss 67108864 33265819648 memlock 67108864 33265819648 nproc 512 512 nofile 1024 1024 sbsize -1 -1 vmem -1 -1 npts -1 -1 swap -1 -1 kqueues -1 -1 umtx -1 -1 The requests started failing in stable/11 with just 386 MB approved v/s stable/10 which was successful in approving ~620MB. My stable/11 is from early days and is at GRN 302410 (probably 10 months old) Any pointers or tips on what to probe further will be very helpful. Is there any limits breach that I should probe further? The limits set when a process is forked? Should I probe the p->vmspace initiazliation? Thanks, -- Shrikanth R K From owner-freebsd-hackers@freebsd.org Wed May 24 08:55:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47901D7B096 for ; Wed, 24 May 2017 08:55:22 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 25D6A18C7 for ; Wed, 24 May 2017 08:55:22 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 252F6D7B094; Wed, 24 May 2017 08:55:22 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D30D7B093 for ; Wed, 24 May 2017 08:55:22 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 AF76B18C6 for ; Wed, 24 May 2017 08:55:21 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id d127so59332105wmf.0 for ; Wed, 24 May 2017 01:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=H6u9MvIrBfQ9Aou3fqTNM0evYE5ija6UqOoCWDJLwRk=; b=SkLo0H5Axc/wWeeAEAGoMyNR8j8ZpvR3BzrFAwYMis39PZ68g6KvUMpHuvWXANCC8B yfcjBNOZ0iFH/+iKxzcd/t5nc4hSE2P4VeINzNwzeALRzal/A1zdmJAnUhJ6egK6U9xB 8voa0ybT8XxgsxOZzaCrzuOd73T6VPq5U5rbARXIIiTHRuRYsH3VsZ2jOLuP8S1bTkEK 7Ptc7enIJ8WuqduuRFWt1fB9l6q1Nkl8ZK/hKzKu7HQEyFnfyi2CpsEXN1o/kvrUu9r8 2DeKqX+RX9qCvTDh4TBw8GhqUtIhm2GL/OMjdivqHbzf/fp4+uAnqJX820JyYw0K0DqI bWdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=H6u9MvIrBfQ9Aou3fqTNM0evYE5ija6UqOoCWDJLwRk=; b=fM3+2voLqTL/jSs4s9PEZmxv/RN+S+Lst5hSDW1Qd/lmDyeIftcOu329/RJSrlNkZz SjmveU41BcI58MOLL0Kuvw006Pv8tqyKt93pxn2GisInWDcjSUUH1Z9w7UAwqfUeStUl fFQ46K8RpGGhPx7suH0gJicKq1ewYXZTAwaDzhsW1QFVt9Vav1ADEJba9s+88TFeBKxs FQ5t6PY8JBJ7Vzi8nRdHPQSco52L/gOoasa3mzzz6dHcTVnqIa8sPLuDKaZ3kbNdr8yP Q+yjT/QP7SiKyYnN06BbijrEZ9WhRozxx6rvYv+kVcb5zqTQFF25jeeE3tW80gpxo4Zl cETw== X-Gm-Message-State: AODbwcChovSEuVPblOt8HUq/9134wxyaMB2ujgjAsRJgME0EIcipIph9 IIxvJ0ySHQFhdytl X-Received: by 10.223.168.97 with SMTP id l88mr18963862wrc.54.1495616117983; Wed, 24 May 2017 01:55:17 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id e187sm4868791wmf.31.2017.05.24.01.55.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 01:55:16 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 24 May 2017 09:55:14 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: hackers@FreeBSD.org Subject: Serial line terminal size. Message-ID: <20170524085514.GA4210@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:55:22 -0000 There's a problem with serial consoles - after logging in, the terminal size is not set, ie it looks like this (notice the "0 rows; 0 columns;"): speed 9600 baud; 0 rows; 0 columns; lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk brkint -inpck -ignpar -parmrk oflags: opost onlcr -ocrnl tab0 -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; eol2 = ; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; This makes some things - like vi(1) or tcsh(1) - handle the screen in a rather strange, and quite broken, way. I'd like to make this work correctly by default by applying the patch below. It should be completely non-intrusive (the -z flag makes resizewin(1) not do anything if the terminal size is not zero, and it's not zero for network protocols and vt(4)), but since this involves running things by default, including for root - I thought I'd better ask. Thanks! https://reviews.freebsd.org/D10642 Index: etc/root/dot.login =================================================================== --- etc/root/dot.login +++ etc/root/dot.login @@ -5,5 +5,8 @@ # see also csh(1), environ(7). # +# Query terminal size; useful for serial lines. +if ( -x /usr/bin/resizewin ) /usr/bin/resizewin -z + # Uncomment to display a random cookie each login: # if ( -x /usr/bin/fortune ) /usr/bin/fortune -s Index: etc/root/dot.profile =================================================================== --- etc/root/dot.profile +++ etc/root/dot.profile @@ -8,3 +8,5 @@ export TERM PAGER=more export PAGER + +if [ -x /usr/bin/resizewin ] ; then /usr/bin/resizewin -z ; fi Index: share/skel/dot.login =================================================================== --- share/skel/dot.login +++ share/skel/dot.login @@ -5,4 +5,5 @@ # see also csh(1), environ(7). # +if ( -x /usr/bin/resizewin ) /usr/bin/resizewin -z if ( -x /usr/bin/fortune ) /usr/bin/fortune freebsd-tips Index: share/skel/dot.profile =================================================================== --- share/skel/dot.profile +++ share/skel/dot.profile @@ -21,4 +21,7 @@ # set ENV to a file invoked each time sh is started for interactive use. ENV=$HOME/.shrc; export ENV +# Query terminal size; useful for serial lines. +if [ -x /usr/bin/resizewin ] ; then /usr/bin/resizewin -z ; fi + if [ -x /usr/bin/fortune ] ; then /usr/bin/fortune freebsd-tips ; fi From owner-freebsd-hackers@freebsd.org Wed May 24 09:07:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38942D7B9CB for ; Wed, 24 May 2017 09:07:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4AD61707 for ; Wed, 24 May 2017 09:07:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4O97DZa030630 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 May 2017 12:07:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4O97DZa030630 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4O97DIY030629; Wed, 24 May 2017 12:07:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 May 2017 12:07:13 +0300 From: Konstantin Belousov To: Shrikanth Kamath Cc: freebsd-hackers@freebsd.org Subject: Re: Difference between p_vmspace quota between stable/11 and stable/10 Message-ID: <20170524090713.GG1622@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 09:07:19 -0000 On Wed, May 24, 2017 at 01:00:51AM -0700, Shrikanth Kamath wrote: > I have a certain application(32 bit user space running in compat mode > in 64 bit system X86) which does a fork, and the child process does a > series of mmap calls as part of a scaling test. I am currently > debugging an issue with this application which hits a ENOMEM when it > is run on a stable/11 based setup and fails subsequent mmap and/or any > malloc calls v/s stable/10 where the issue is not seen.. I probed the > vm_map_find function using DTrace when "execname" was my application > in question, and got these readings > > fbt:kernel:vm_map_find:entry > /self->trace == 1/ /*enabled only during sys_mmap call of this application */ > { > @bytes[args[4]] = sum(args[4]); > printf("request length [%x]", args[4]); > } > > For stable_10 --> Total of 124 requests (length requested was > 0x500000) with the test successful > 124 * 0x500000 (5MB) ~ 620MB > > For stable_11 --> Total of 109 mmap requests > (0x500000/0x200000/0x3ff000 are the different vm_size_t length > arguments in vm_map_find). The test fails after 386MB has been > approved. > 24 * 0x500000 (5MB) ~ 120MB > 82 * 0x200000 (2MB) ~ 164MB > 3 * 0x3ff000 (4MB) ~ 12MB > > > The process parent rlimits are > > # cat /proc/5058/rlimit > > cpu -1 -1 > fsize -1 -1 > data 3221225472 3221225472 > stack 16777216 16777216 > core -1 -1 > rss 67108864 33265819648 > memlock 67108864 33265819648 > nproc 512 512 > nofile 1024 1024 > sbsize -1 -1 > vmem -1 -1 > npts -1 -1 > swap -1 -1 > kqueues -1 -1 > umtx -1 -1 > > The requests started failing in stable/11 with just 386 MB approved > v/s stable/10 which was successful in approving ~620MB. > > My stable/11 is from early days and is at GRN 302410 (probably 10 months old) > Any pointers or tips on what to probe further will be very helpful. Is > there any limits breach that I should probe further? The limits set > when a process is forked? > Should I probe the p->vmspace initiazliation? I doubt that limits are relevant for your issue. Look at the process address map at the moment when the request failed, I suspect that it is fragmented. Use procstat -v to examine the address space. You may spawn the tool from your program when mmap(2) fails. From owner-freebsd-hackers@freebsd.org Wed May 24 09:25:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45F6AD7BF16 for ; Wed, 24 May 2017 09:25:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D115F1123 for ; Wed, 24 May 2017 09:25:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4O9PUsD034260 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 May 2017 12:25:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4O9PUsD034260 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4O9PUsP034256; Wed, 24 May 2017 12:25:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 May 2017 12:25:30 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Use __BSD_VISIBLE for Termios headers Message-ID: <20170524092530.GH1622@kib.kiev.ua> References: <20170524060758.25529-1-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170524060758.25529-1-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 09:25:37 -0000 On Wed, May 24, 2017 at 08:07:58AM +0200, Sebastian Huber wrote: > The Termios headers and used sometimes > _POSIX_SOURCE directly to determine if a thing should be exposed to the > user. > > This circumvented the feature mechanisms of . Use > __BSD_VISIBLE instead. > --- > include/termios.h | 8 ++++---- > sys/sys/_termios.h | 44 ++++++++++++++++++++++---------------------- > 2 files changed, 26 insertions(+), 26 deletions(-) Committed as r318780, thank you. From owner-freebsd-hackers@freebsd.org Wed May 24 09:22:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED210D7BE86 for ; Wed, 24 May 2017 09:22:48 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 A8C8B1F99 for ; Wed, 24 May 2017 09:22:48 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id f55so149791537qta.3 for ; Wed, 24 May 2017 02:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZVUPQHk6r+aZVjELLrZxFvh7XE+x1Md170O/D79BC/w=; b=L0mUd9gm5KwfD5cMx4rc+l0P2K/B+GEuNpCFSdIUj9c2JQKlwsKEVmGXlHzuy7AvMg IcpZLKfd7Wn7OPIQR2iT1fBGuN1kH0AFOsiT38zEPT+2wBDl/jkRN/ZSzrBFAW/aQvoJ CMnXEqUt3o5BwzAujh+EYaR8Ji1aSbCwR70dRYLsqcwIOVyDp1BfzJY+j9raMJAgnbyG qzXn4IUETnO230gqe2ELuU07uYfqTrK8xvOSEGVfNQs6ZGEnS4z2u1pb+K8FhOcop6Cc N/LwHpRizdK4XfcO2FATu/VT/QO4QH9kh+vstTGYcbnY7tGua4gwYPd7k4u8wxFOfkQ4 4vGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZVUPQHk6r+aZVjELLrZxFvh7XE+x1Md170O/D79BC/w=; b=dH6SeebP+GvdOAKKwjITXjKHoCG915JtbOJbaeuaa0o3Ie59sQZYznZYZUMR0UoWqZ g/JOq/swrazigodAFZUa/Ja4kdC5qPIgizG2gfgdQoUWLol8t+toX0kGiPGGk4lAM66w ImFF07UqGOvkenWBYQL498RDk/J9SiTThz5t2vzlXBY9lfVx857RTWmbNlc4MPEIOmqz T4lB2D+BqGETN39M14FNUiOifYm/fE+ZR4m6xY/WQT3zNPGRkQhvr/dw3ALoRXQW+GLP 5XqF8qT9zssw5NA86ImKGpEZPYjntPhTXcysr2MH+8/DySaXRiSCwLs5/trbIsWtLENp ebfA== X-Gm-Message-State: AODbwcD0YJNDitaiZyKTdERFTaz6EcXvFUdIrusO2hRq+TFO9/yB1QhQ ZS3Dw54/dJFeTTqpv/Keo3VO7JCoNg== X-Received: by 10.200.34.132 with SMTP id f4mr32076370qta.183.1495617767881; Wed, 24 May 2017 02:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.49.85 with HTTP; Wed, 24 May 2017 02:22:47 -0700 (PDT) In-Reply-To: <20170523140601.GD1622@kib.kiev.ua> References: <20170523140601.GD1622@kib.kiev.ua> From: karnajit wangkhem Date: Wed, 24 May 2017 14:52:47 +0530 Message-ID: Subject: Re: Seventh argument seen in mmap on i386 To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 24 May 2017 12:00:13 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 09:22:49 -0000 Thanks. That was helpful. On Tue, May 23, 2017 at 7:36 PM, Konstantin Belousov wrote: > On Tue, May 23, 2017 at 07:25:07PM +0530, karnajit wangkhem wrote: > > Hi All, > > > > > > > > I am trying to understand this scenario where a seventh argument is seen > in > > case of freebsd.x-i386. As per the mmap man page, the libc function > > prototype takes in 6 arguments. > > > > > > Ktrace shows the following > > > > // Freebsd-11.0 ??? i386 box > > > > 44416 a.out CALL > > mmap(0,0x1000,0x7,0x1002< > MAP_PRIVATE|MAP_ANON>,0xffffffff,0,0) > > > > 44416 a.out RET mmap 671535104/0x2806d000 > > > > > > > > // Freebsd-11.0 ??? amd64 box > > > > 366 a.out CALL > > mmap(0,0x1000,0x7,0x1002< > MAP_PRIVATE|MAP_ANON>,0xffffffff,0) > > > > 366 a.out RET mmap 34366287872/0x80063f000 > > > > > > > > Also, the disassemble code show that an extra argument was pushed in i386 > > case > > > > > > > > -> 0x80485e6 <+38>: movl %esp, %ebx > > > > 0x80485e8 <+40>: movl $0x0, 0x18(%ebx) > > > > 0x80485ef <+47>: movl $0x0, 0x14(%ebx) > > > > 0x80485f6 <+54>: movl $0xffffffff, 0x10(%ebx) ; imm = 0xFFFFFFFF > > > > 0x80485fd <+61>: movl $0x1002, 0xc(%ebx) ; imm = 0x1002 > > > > 0x8048604 <+68>: movl $0x7, 0x8(%ebx) > > > > 0x804860b <+75>: movl $0x1000, 0x4(%ebx) ; imm = 0x1000 > > > > 0x8048612 <+82>: movl $0x0, (%ebx) > > > > > > > > > > > > Please help me understand why this extra argument is seen in case of > i386. > > off_t is 64bit. It is not seventh arg, it is offset which takes two words. > From owner-freebsd-hackers@freebsd.org Wed May 24 15:45:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8A39D7B679 for ; Wed, 24 May 2017 15:45:51 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [207.172.210.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A3E3C1A04 for ; Wed, 24 May 2017 15:45:51 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::1f] (haymarket.m5p.com [IPv6:2001:470:1f07:15ff::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v4OFiLWe026519; Wed, 24 May 2017 11:44:26 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Belated followup Re: TCP6 problem To: Bob Bishop Cc: freebsd-hackers@freebsd.org References: <82600781-7892-63ea-feac-35a140dbf95d@m5p.com> <1D3B8C36-6144-4040-8939-61EB933B5080@gid.co.uk> <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> From: George Mitchell Message-ID: <33e202f5-42bd-fe08-edc8-579208c33017@m5p.com> Date: Wed, 24 May 2017 11:44:15 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BdO7WUtbM1Wo2lqESO53cjpGsWf3lKQok" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]); Wed, 24 May 2017 11:44:28 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 15:45:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BdO7WUtbM1Wo2lqESO53cjpGsWf3lKQok Content-Type: multipart/mixed; boundary="pDClskWf9Utn8UliatmSQ1gHO44jDUEId"; protected-headers="v1" From: George Mitchell To: Bob Bishop Cc: freebsd-hackers@freebsd.org Message-ID: <33e202f5-42bd-fe08-edc8-579208c33017@m5p.com> Subject: Re: Belated followup Re: TCP6 problem References: <82600781-7892-63ea-feac-35a140dbf95d@m5p.com> <1D3B8C36-6144-4040-8939-61EB933B5080@gid.co.uk> <4438fbf6-e7db-fa6b-4f6a-96796c21aeb4@m5p.com> <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> In-Reply-To: <1145505c-53d5-fcc4-c8ed-a88de1d51967@m5p.com> --pDClskWf9Utn8UliatmSQ1gHO44jDUEId Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/21/17 13:44, George Mitchell wrote: > [...] > I haven't solved this problem yet, but it has become moot because my > IPv6 tunnel provider died. -- George >=20 Sorry for the noise. After setting up a new tunnel through Hurricane Electric's tunnelbroker.net, this problem has gone away. -- George --pDClskWf9Utn8UliatmSQ1gHO44jDUEId-- --BdO7WUtbM1Wo2lqESO53cjpGsWf3lKQok Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlklqk8ACgkQwRES3m+p 4fkEaA/6A+lrBtwtRoAoQOvnvdTH/cgdqhmM1jZ3UbwpB3Kl0Tryx/KS1ODmaF+x b1yibIB089QxAx409OX9e59dAc6Q2wLud1iLoolu89LWwQbKr4fUEfi/MG7DPlyq aK/bYn4sSP6k4jtzVglw/etZaQMMkpS/f2p8/uvF67Dv7z2Yf8ejXnqk5Z3EN9cN pb9rkIWcwi4NSx2bHi/dsBolQdc5ndPt+FumHjmGMJsG3QmhhpBXP33o8fds3LzB aHvCSBeDO1szqnXIp85FVAwscMMALqMoGj6m4OzA39mdOiBDAWve85rRjArNAb79 Wp0wGYEgaRh/KXEW71haAjejTuJi2ICVoOibKgyWTMEyqUlN0eYRT5cA05fwvlap re1jtv05y4d1tWXZ6PjRuOVRsw/UbZIVXWK+M9o2hQmgA+66a3u++lnI9+9YxC+G 2LfEpNa9eX46ZFtUspcUShFrtI6uPFeTOfMH21pNaWwiYMCoTc4pxCKW4QuX49z0 jHOPne4bLZQWiLB9EHJsGNOtNqIfQqahvHBc7pFDAoAQLAvUCzCnUke7K7nGPmOC DsEsFedFl34lx4/x6hdtjnAkPdxSXp8ckxyTYMVkO+XWsHtoFwu1mSGlUwyw83Qu gWe+Lt4dLBJOQ9ZLSgKaQk+JM1A11jE5Xf+iNiWBSB6imFyQtKs= =DgBA -----END PGP SIGNATURE----- --BdO7WUtbM1Wo2lqESO53cjpGsWf3lKQok-- From owner-freebsd-hackers@freebsd.org Thu May 25 08:13:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06890D81EBD for ; Thu, 25 May 2017 08:13:41 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 B711910AD for ; Thu, 25 May 2017 08:13:40 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id a72so171705320qkj.2 for ; Thu, 25 May 2017 01:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vemppGDg1iRY9CtTyPoL3F82RV+s1zptpvX0OhHrqdc=; b=NvrBxRni2rJvoDwDpeYs+l356i0JGFsZLDPE4guS2YgcLDZ+4juvrCEjtPw/Qpqjoa v4G4yWCFAPH4oFw6gXenXT/Y4Vl5LpwZHxMDAE8zL0xF0AwktJHCoQKeUVFZvMDBYvfz Zi5UVki7QgGCVbc2s5xig7gjAru0T22Rk8QwnjqB26n9Iq2ja0VKaNvGzmdtiBuU0cAL t5NnKmF1uPiziK1iZsh9WaWCzarj5MbEd8l54Kl2CwFl77yY58BVvfw/jP+Iylqoooi3 SZBxMMneqlEpzXWBm5m8rFX31xUiwdiP7SamDeoKv5+w2X+xC2ZJueX+c1s5fEpndU9F 6lgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vemppGDg1iRY9CtTyPoL3F82RV+s1zptpvX0OhHrqdc=; b=n46T9PevNI7hkKxqFVTeLgxQ155GrIT5u+I4ve8ocNAv8dSXx9QQJmGSIKgSmx9H96 eY08JK7xzSOk5fYjInjiLk97EP1GoLGYirpf09UB7pPDHr4QXBUk5TCwgFGUYZzW8/H3 jzufxKAQJ8fxbbWUe/OZMRHz4M5WK756xyu8GrnrZIliCSo0AWCPRcxKhi7HzAp0DAl+ hjk6qd80VMY6JzJgcGw2E40Qd53eo5zT35B+71wnWptujIk7+nflgZ8V04ALQeeOZdjl iVocilhpANMGyG4PC6mwPCkLP0+y+DqMaspYjAvjCPgFSxuZehcVb8AOUyHjYWVaPDcS E8Pw== X-Gm-Message-State: AODbwcBR8WivsGv8SKAUurvEZJ1z3pk+tkxSDP5EQr2a74wBRK6AWztE 7Kg1sxJpdn0SqhaMgfOpqw2d88lbCQ== X-Received: by 10.55.73.133 with SMTP id w127mr37212503qka.4.1495700019503; Thu, 25 May 2017 01:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.241 with HTTP; Thu, 25 May 2017 01:13:39 -0700 (PDT) From: Shrikanth Kamath Date: Thu, 25 May 2017 01:13:39 -0700 Message-ID: Subject: Re: Difference between p_vmspace quota between stable/11 and stable/10 To: Konstantin Belousov , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 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 May 2017 08:13:41 -0000 Thanks for the reply Konstantin, I captured the procstat -v snapshots for the forked process (got the readings for both stable/10 vs stable/11). I am still trying to figure how to interpret these mappings, In stable/11 the first few lines of procstat -v show PID START END PRT RES PRES REF SHD FLAG TP PATH 19933 0x8048000 0x877e000 r-x 933 1003 2 1 CN-- vn /packages/mnt/junos-platform/sbin/dcd 19933 0x877e000 0x87f2000 rw- 70 0 1 0 C--- vn /packages/mnt/junos-platform/sbin/dcd 19933 0x87f2000 0x8a73000 rw- 59 59 1 0 C--- df 19933 0xc8797000 0xc87a1000 rw- 10 10 1 0 CN-- df The same for stable/10 show PID START END PRT RES PRES REF SHD FL TP PATH 43678 0x8048000 0x8779000 r-x 943 1014 2 1 CN-- vn /packages/mnt/junos-platform/sbin/dcd 43678 0x8779000 0x87ed000 rw- 70 0 1 0 C--- vn /packages/mnt/junos-platform/sbin/dcd 43678 0x87ed000 0x2cc00000 rw- 145872 145872 1 0 C-S- df 43678 0xc8792000 0xc879c000 rw- 10 10 1 0 C--- df The third entry in two cases show a stark difference, does this indicated the space that was setup was much lower compared to stable/10? -- Shrikanth R K From: Konstantin Belousov To: Shrikanth Kamath Cc: freebsd-hackers@freebsd.org Subject: Re: Difference between p_vmspace quota between stable/11 and stable/10 Message-ID: <20170524090713.GG1622@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii On Wed, May 24, 2017 at 01:00:51AM -0700, Shrikanth Kamath wrote: > I have a certain application(32 bit user space running in compat mode > in 64 bit system X86) which does a fork, and the child process does a > series of mmap calls as part of a scaling test. I am currently > debugging an issue with this application which hits a ENOMEM when it > is run on a stable/11 based setup and fails subsequent mmap and/or any > malloc calls v/s stable/10 where the issue is not seen.. I probed the > vm_map_find function using DTrace when "execname" was my application > in question, and got these readings > > fbt:kernel:vm_map_find:entry > /self->trace == 1/ /*enabled only during sys_mmap call of this application */ > { > @bytes[args[4]] = sum(args[4]); > printf("request length [%x]", args[4]); > } > > For stable_10 --> Total of 124 requests (length requested was > 0x500000) with the test successful > 124 * 0x500000 (5MB) ~ 620MB > > For stable_11 --> Total of 109 mmap requests > (0x500000/0x200000/0x3ff000 are the different vm_size_t length > arguments in vm_map_find). The test fails after 386MB has been > approved. > 24 * 0x500000 (5MB) ~ 120MB > 82 * 0x200000 (2MB) ~ 164MB > 3 * 0x3ff000 (4MB) ~ 12MB > > > The process parent rlimits are > > # cat /proc/5058/rlimit > > cpu -1 -1 > fsize -1 -1 > data 3221225472 3221225472 > stack 16777216 16777216 > core -1 -1 > rss 67108864 33265819648 > memlock 67108864 33265819648 > nproc 512 512 > nofile 1024 1024 > sbsize -1 -1 > vmem -1 -1 > npts -1 -1 > swap -1 -1 > kqueues -1 -1 > umtx -1 -1 > > The requests started failing in stable/11 with just 386 MB approved > v/s stable/10 which was successful in approving ~620MB. > > My stable/11 is from early days and is at GRN 302410 (probably 10 months old) > Any pointers or tips on what to probe further will be very helpful. Is > there any limits breach that I should probe further? The limits set > when a process is forked? > Should I probe the p->vmspace initiazliation? I doubt that limits are relevant for your issue. Look at the process address map at the moment when the request failed, I suspect that it is fragmented. Use procstat -v to examine the address space. You may spawn the tool from your program when mmap(2) fails. -- Shrikanth R K From owner-freebsd-hackers@freebsd.org Thu May 25 13:51:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0640D81D34 for ; Thu, 25 May 2017 13:51:59 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 A83D71776 for ; Thu, 25 May 2017 13:51:59 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x243.google.com with SMTP id k15so52048624wmh.3 for ; Thu, 25 May 2017 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=X8Tx5hP01nTOomifEOX+lng9F6pPk3Z/2cbBVrwp6Qg=; b=Ma2H7TqRU5cej+d6gCqb35PTvp/s+OWYIDYflFcU/3GhBjydHKwMPkpZItC4u0ehbL WKhO1zLoeX6/MdUMecEPOMb3dyyck+Mo1QRegmbARrgV1Ne/MLVWKPSyGS/Xv2RmXaAR JbErKOctVae519m4+KnmZgc46VZJ1c0m+wKJm/aVGZsjXvBUA8KvMnTQWeIG117fe28J phFhoKWV5iJUUdyZ/583w6DGr20iZl/FD58c+TqQZzunLKvNMRd3+ODZ4yIPYcG4ZlHt qPYSsUYPh77lCWqIvGyoUYQAASh1uVy/bR3JSC4OOVsVDc5naGYAc0oQHJn4RkcAnYxG ksqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=X8Tx5hP01nTOomifEOX+lng9F6pPk3Z/2cbBVrwp6Qg=; b=JyLXpM/8/G6QRczxgwoBAHBeIsmD6FmjDAhDPQgdShluRNU+4htC3Il9l5AUsMvcrr DmkmOb/nq8Tl3GwwmnqVL+YjHLIqAHya1pp6d9mVeYuQ/GzRG2+VcrAzpZGGdnBIhgCf oWLyf3K4BoEYQazGDSh7nM2tfuROSK0QJSKyz/bo2bga4cq+gc49n94XYoa0jEFkMC2l OHa/GwmMJN0gzg7a31k47KGpeI3dYdt/rkxQeVCZj5glj31YsRAjLor1pXhVdXWoLRR4 76f89i2lktKqbj8MiVEV9+kguM5uhKuusjJNG8UGxwfcLeLxZK4LBBl062G7MOXiw5vA pUkA== X-Gm-Message-State: AODbwcAaVKsahhAoz8xRpzk20Oh5nQ7tSFJxImwNVT2hfTdQ+9UTjq7h qLVLCdNJWf0Vif86 X-Received: by 10.28.69.73 with SMTP id s70mr10548295wma.36.1495720317750; Thu, 25 May 2017 06:51:57 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id f78sm7072425wme.19.2017.05.25.06.51.55 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 May 2017 06:51:56 -0700 (PDT) Date: Thu, 25 May 2017 14:51:53 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: anti-dog-piling and ntpd leap files Message-ID: <20170525145153.79d1d03d@gumby.homeunix.com> In-Reply-To: References: <20170522125307.76c9de6d@gumby.homeunix.com> <1104C7A7-5893-4602-9E34-5C212D987DAE@webweaving.org> <20170522143102.70035d8d@gumby.homeunix.com> <20170523233057.59cd2393@gumby.homeunix.com> X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 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 May 2017 13:52:00 -0000 On Tue, 23 May 2017 17:08:00 -0600 Alan Somers wrote: > Like I said, the sleeps are only useful when periodic is run at a > predictable time, which is not the case when you run anacron at boot. > It would be reasonable to disable sleeping in that case, just like > when running from the terminal. Can you suggest how? I'd use uptime (probably using sysctl kern.boottime). Either skip the delay if uptime < 1hour or alternately limit the delay to uptime/20. From owner-freebsd-hackers@freebsd.org Thu May 25 14:55:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AE49D819CB for ; Thu, 25 May 2017 14:55:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 008A11C0B for ; Thu, 25 May 2017 14:55:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4PEtW3D027835 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 May 2017 17:55:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4PEtW3D027835 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4PEtWKu027810; Thu, 25 May 2017 17:55:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 May 2017 17:55:32 +0300 From: Konstantin Belousov To: Shrikanth Kamath Cc: freebsd-hackers@freebsd.org Subject: Re: Difference between p_vmspace quota between stable/11 and stable/10 Message-ID: <20170525145532.GU1622@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 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 May 2017 14:55:40 -0000 On Thu, May 25, 2017 at 01:13:39AM -0700, Shrikanth Kamath wrote: > Thanks for the reply Konstantin, I captured the procstat -v snapshots > for the forked process (got the readings for both stable/10 vs > stable/11). I am still trying to figure how to interpret these > mappings, > > In stable/11 the first few lines of procstat -v show > > PID START END PRT RES PRES REF SHD FLAG TP PATH > > 19933 0x8048000 0x877e000 r-x 933 1003 2 1 CN-- > vn /packages/mnt/junos-platform/sbin/dcd > 19933 0x877e000 0x87f2000 rw- 70 0 1 0 C--- > vn /packages/mnt/junos-platform/sbin/dcd > 19933 0x87f2000 0x8a73000 rw- 59 59 1 0 C--- df > 19933 0xc8797000 0xc87a1000 rw- 10 10 1 0 CN-- df > > The same for stable/10 show > > PID START END PRT RES PRES REF SHD FL TP PATH > > 43678 0x8048000 0x8779000 r-x 943 1014 2 1 CN-- > vn /packages/mnt/junos-platform/sbin/dcd > 43678 0x8779000 0x87ed000 rw- 70 0 1 0 C--- > vn /packages/mnt/junos-platform/sbin/dcd > 43678 0x87ed000 0x2cc00000 rw- 145872 145872 1 0 C-S- df > 43678 0xc8792000 0xc879c000 rw- 10 10 1 0 C--- df > > > The third entry in two cases show a stark difference, does this > indicated the space that was setup was much lower compared to > stable/10? > I am not sure what you mean by 'the space that was setup was much lower'. Right after the mapping for the program' initialized data segment, follows a BSS segment which grows into the sbrk segment. The mapping in stable/10 map which starts at address 0x87ed000 looks like grown sbrk segment due to this. System does not mmap() something there, unless mmap is explicitely asked to, by the 'address' argument, and perhaps MAP_FIXED flag. Note that even in stable/10, jemalloc(3) uses mmap and not sbrk, so I have no idea what that mapping is. Either you reconfigured jemalloc() to use sbrk, or called sbrk in the program explicitely, or called mmap() with the address hint in sbrk area. You should ktrace your program to see what caused creation of the mapping. From owner-freebsd-hackers@freebsd.org Sat May 27 02:14:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07E4FD8394B for ; Sat, 27 May 2017 02:14:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD1521CFA for ; Sat, 27 May 2017 02:14:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19680 invoked from network); 27 May 2017 02:15:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2017 02:15:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 26 May 2017 22:14:30 -0400 (EDT) Received: (qmail 30784 invoked from network); 27 May 2017 02:14:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 02:14:30 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5C8C9EC7B46; Fri, 26 May 2017 19:14:29 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) Message-Id: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> Date: Fri, 26 May 2017 19:14:28 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 02:14:38 -0000 I lucked out and got a vmcore.9 for a random panic that I could manage to backtrace for one of my test builds of -r317820. It appears that not all that much happened before it got the panic so much context was better preserved this time. (I do not explore from ddb as I've had that panic and mess up the dump just made by replacing it. So this is a manual backtrace from the debug.minidump=3D0 style vmcore.9 file. objdump was used on the /boot/kernel/kernel to find code.) Being able to see the problem is very sensitive to kernel memory layout. This is why I'm sticking with -r317820 built production style: the kind of context the problem was first observed in. Attempting a debug kernel build simply did not repeat the problem for days (vs. the usual hours for builds like this). So below is the backtrace: (I do not show what trap_fatal calls: starting with trap_fatal and going toward larger memory addresses. . .) [vmcore.9's offset in file when no 0x prefix] 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| 0x008f3454 mr r3,r26 0x008f3458 bl 008f2030 0x008f345c b 008f34c8 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| * 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| 0x008e7d28 mfmsr r0 0x008e7d2c or r0,r0,r9 0x008e7d30 mtmsr r0 0x008e7d34 isync 0x008e7d38 mr r3,r25 0x008e7d3c bl 008f222c 0x008e7d40 lwz r11,0(r1) 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| r0 r1 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| The struct trapframe starts is 0x 013e8588 in the vmcore.9 file. The 0x00108f8 is as shown below: 0x001008ec isync 0x001008f0 addi r3,r1,8 0x001008f4 bl 008e7ba4 0x001008f8 mfmsr r3 0x001008fc andi. r3,r3,32767 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| r2 r3 r4 r5 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| r6 r7 r8 r9 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| r10 r11 r12 r13 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| r14 r15 r16 r17 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| r18 r19 r20 r21 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| r22 r32 r24 r25 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| r26 r27 r28 r29 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| r30 r31 lr cr xer ctr srr0 srr1 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| Note: objdump shows no code at 0x0090a030. 0x0090a030 is inside what objdump -x reports as the section .hash (Idx 2). exc dar dsisr (booke dbcer0) 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| The 0x00007000 above is the framep->exc (exception code) (program in this case). 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| At this point the above does not match the below part of the stack trace. The lr part of struct trapframe was: 0x00535ad0 so showing around that: 00535ab8 stwu r1,-32(r1) 00535abc mflr r0 00535ac0 stw r29,20(r1) 00535ac4 stw r30,24(r1) 00535ac8 stw r31,28(r1) 00535acc stw r0,36(r1) 00535ad0 mr r31,r1 00535ad4 mr r29,r3 Back to the stack backtrace. . . 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| 0x005359c8 bl 008ea420 0x005359cc mr r3,r28 0x005359d0 mr r4,r27 0x005359d4 mr r5,r25 0x005359d8 bl 005356ec 0x005359dc mfsprg r9,0 I show around 0x005356ec from the sched_add+0x19c bl that is above because the routine is not referenced in the stack tracce but the above indicates that it should have been called: 0x005356ec stwu r1,-32(r1) 0x005356f0 mflr r0 0x005356f4 stw r28,16(r1) 0x005356f8 stw r29,20(r1) 0x005356fc stw r30,24(r1) 0x00535700 stw r31,28(r1) 0x00535704 stw r0,36(r1) . . . Back to the stack backtrace again. . . 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| 0x004a8780 mr r3,r28 0x004a8784 li r4,4 0x004a8788 bl 0053583c = 0x004a878c lwz r9,0(r28) 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| 0x004a9700 bl 005000ec 0x004a9704 mr r3,r27 0x004a9708 bl 004a86bc = 0x004a970c lwz r11,0(r1) 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 |x.....V.... = .^V.| 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| 0x00517960 lwz r3,264(r29) 0x00517964 li r4,0 0x00517968 bl 004a965c 0x0051796c lwz r11,0(r1) 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| 0x008ab264 mr r3,r27 0x008ab268 mr r4,r28 0x008ab26c bl 00517540 0x008ab270 li r3,0 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| 0x008ad100 mr r3,r26 0x008ad104 mr r4,r27 0x008ad108 li r5,0 0x008ad10c bl 008aafc0 0x008ad110 lwz r11,0(r1) 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| So 0x13e8820 from vmcore.9 has start of struct trapeframe. The 0x8e1e48 is from: 0x008e1e34 lwz r0,56(r28) 0x008e1e38 mtctr r0 0x008e1e3c mr r3,r28 0x008e1e40 lwz r4,64(r28) 0x008e1e44 bctrl 0x008e1e48 addi r29,r29,-1 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| srr0 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| The 0x00833c14 from the trap frame is the srr0 (conceptual lr): 0x008e3c04 stw r31,28(r1) 0x008e3c08 stw r0,36(r1) 0x008e3c0c mr r31,r1 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = 0x008e3c14 mflr r30 0x008e3c18 lwz r0,-32(r30) 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| exc 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| The 0x00009000 above is the framep->exc (exception code) (decrementer in this case). 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| (trap [above] means no lr filled in here) 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| 0x008e318c bl 008ad8b8 0x008e3190 lwz r29,0(r29) 0x008e3194 mtctr r29 0x008e3198 bctrl 0x008e319c bl 008ad7b8 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| 0x00536e78 bl 008e3144 0x00536e7c stw r28,136(r27) 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| 0x004a3ca0 bl 008ea420 0x004a3ca4 mr r3,r27 0x004a3ca8 mr r4,r26 0x004a3cac mtctr r25 0x004a3cb0 bctrl 0x004a3cb4 lwz r0,108(r28) 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| 0x008f18c0 lwz r3,8(r1) 0x008f18c4 lwz r4,12(r1) 0x008f18c8 lwz r5,16(r1) 0x008f18cc bl 004a3bbc 0x008f18d0 addi r1,r1,16 0x008f18d4 b 001008f8 So that is an example context for the failure. It has taken weeks to get this. It may be some time before I get another for comparison/contrast. And sticking with the same build vs. trying some more to find a better way to get more evidence is not obvious to me at this point. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat May 27 05:29:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 984CDD84F5F for ; Sat, 27 May 2017 05:29:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E97E1D1D for ; Sat, 27 May 2017 05:29:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5357 invoked from network); 27 May 2017 05:32:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 May 2017 05:32:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 01:29:16 -0400 (EDT) Received: (qmail 19300 invoked from network); 27 May 2017 05:29:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 05:29:16 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9310FEC7B46; Fri, 26 May 2017 22:29:15 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [better bt; more] Date: Fri, 26 May 2017 22:29:14 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> Message-Id: <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 05:29:18 -0000 [Additional information that does not need to interlace with the prior material, so see after. A somewhat better backtrace reported by ddb. And so on.] On 2017-May-26, at 7:14 PM, Mark Millard wrote: > I lucked out and got a vmcore.9 for a random > panic that I could manage to backtrace for > one of my test builds of -r317820. It appears > that not all that much happened before it got > the panic so much context was better preserved > this time. >=20 > (I do not explore from ddb as I've had that > panic and mess up the dump just made by > replacing it. So this is a manual backtrace > from the debug.minidump=3D0 style vmcore.9 > file. objdump was used on the > /boot/kernel/kernel to find code.) >=20 > Being able to see the problem is very > sensitive to kernel memory layout. This > is why I'm sticking with -r317820 built > production style: the kind of context > the problem was first observed in. > Attempting a debug kernel build simply > did not repeat the problem for days > (vs. the usual hours for builds like > this). >=20 >=20 > So below is the backtrace: >=20 > (I do not show what trap_fatal calls: > starting with trap_fatal and going toward > larger memory addresses. . .) >=20 > [vmcore.9's > offset > in file > when no > 0x prefix] >=20 > 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| > 0x008f3454 mr r3,r26 > 0x008f3458 bl 008f2030 > 0x008f345c b 008f34c8 >=20 > 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| > * > 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| > 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| > 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| > 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | > 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| > 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| > 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| > 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| > 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| > 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| > 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| > 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| > 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| > 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| > 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| > 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| > 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| > 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >=20 > 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| > 0x008e7d28 mfmsr r0 > 0x008e7d2c or r0,r0,r9 > 0x008e7d30 mtmsr r0 > 0x008e7d34 isync > 0x008e7d38 mr r3,r25 > 0x008e7d3c bl 008f222c > 0x008e7d40 lwz r11,0(r1) >=20 > 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| > 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >=20 > r0 r1 > 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| > The struct trapframe starts is 0x 013e8588 in the > vmcore.9 file. The 0x00108f8 is as shown below: >=20 > 0x001008ec isync > 0x001008f0 addi r3,r1,8 > 0x001008f4 bl 008e7ba4 > 0x001008f8 mfmsr r3 > 0x001008fc andi. r3,r3,32767 >=20 > 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| > r2 r3 r4 r5 >=20 > 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| > r6 r7 r8 r9 >=20 > 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| > r10 r11 r12 r13 >=20 > 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| > r14 r15 r16 r17 >=20 > 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| > r18 r19 r20 r21 >=20 > 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| > r22 r32 r24 r25 >=20 > 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| > r26 r27 r28 r29 >=20 > 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| > r30 r31 lr cr >=20 > xer ctr srr0 srr1 > 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > Note: objdump shows no code at 0x0090a030. 0x0090a030 is > inside what objdump -x reports as the section .hash (Idx > 2). >=20 > exc dar dsisr (booke dbcer0) > 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| > The 0x00007000 above is the framep->exc (exception code) > (program in this case). >=20 > 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >=20 > At this point the above does not match the below > part of the stack trace. >=20 > The lr part of struct trapframe was: 0x00535ad0 so > showing around that: >=20 > 00535ab8 stwu r1,-32(r1) > 00535abc mflr r0 > 00535ac0 stw r29,20(r1) > 00535ac4 stw r30,24(r1) > 00535ac8 stw r31,28(r1) > 00535acc stw r0,36(r1) > 00535ad0 mr r31,r1 > 00535ad4 mr r29,r3 >=20 > Back to the stack backtrace. . . >=20 > 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| > 0x005359c8 bl 008ea420 > 0x005359cc mr r3,r28 > 0x005359d0 mr r4,r27 > 0x005359d4 mr r5,r25 > 0x005359d8 bl 005356ec > 0x005359dc mfsprg r9,0 >=20 > I show around 0x005356ec > from the sched_add+0x19c bl that is above > because the routine is not referenced > in the stack tracce but the above indicates > that it should have been called: > 0x005356ec stwu r1,-32(r1) > 0x005356f0 mflr r0 > 0x005356f4 stw r28,16(r1) > 0x005356f8 stw r29,20(r1) > 0x005356fc stw r30,24(r1) > 0x00535700 stw r31,28(r1) > 0x00535704 stw r0,36(r1) > . . . >=20 > Back to the stack backtrace again. . . >=20 > 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| > 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| > 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >=20 > 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| > 0x004a8780 mr r3,r28 > 0x004a8784 li r4,4 > 0x004a8788 bl 0053583c = > 0x004a878c lwz r9,0(r28) >=20 > 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| > 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >=20 > 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| > 0x004a9700 bl 005000ec > 0x004a9704 mr r3,r27 > 0x004a9708 bl 004a86bc = > 0x004a970c lwz r11,0(r1) >=20 > 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| > 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| > 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >=20 > 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| > 0x00517960 lwz r3,264(r29) > 0x00517964 li r4,0 > 0x00517968 bl 004a965c > 0x0051796c lwz r11,0(r1) >=20 > 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| > 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| > 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| > 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| > 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >=20 > 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| > 0x008ab264 mr r3,r27 > 0x008ab268 mr r4,r28 > 0x008ab26c bl 00517540 > 0x008ab270 li r3,0 >=20 > 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| > 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| > 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| > 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >=20 > 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| > 0x008ad100 mr r3,r26 > 0x008ad104 mr r4,r27 > 0x008ad108 li r5,0 > 0x008ad10c bl 008aafc0 > 0x008ad110 lwz r11,0(r1) >=20 > 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| > 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| > 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| > 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| > 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| > 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| > 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >=20 > 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| > So 0x13e8820 from vmcore.9 has start of struct trapeframe. > The 0x8e1e48 is from: > 0x008e1e34 lwz r0,56(r28) > 0x008e1e38 mtctr r0 > 0x008e1e3c mr r3,r28 > 0x008e1e40 lwz r4,64(r28) > 0x008e1e44 bctrl > 0x008e1e48 addi r29,r29,-1 >=20 > 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| > 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| > 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| > 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| > 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| > 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| > 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| > 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| > 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| > 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| > 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| > 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >=20 > srr0 > 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| > The 0x00833c14 from the trap frame is the srr0 (conceptual lr): > 0x008e3c04 stw r31,28(r1) > 0x008e3c08 stw r0,36(r1) > 0x008e3c0c mr r31,r1 > 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = > 0x008e3c14 mflr r30 > 0x008e3c18 lwz r0,-32(r30) >=20 > 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >=20 > exc > 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| > The 0x00009000 above is the framep->exc (exception code) > (decrementer in this case). >=20 > 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >=20 > 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| > (trap [above] means no lr filled in here) >=20 > 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >=20 > 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| > 0x008e318c bl 008ad8b8 > 0x008e3190 lwz r29,0(r29) > 0x008e3194 mtctr r29 > 0x008e3198 bctrl > 0x008e319c bl 008ad7b8 >=20 > 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >=20 > 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| > 0x00536e78 bl 008e3144 > 0x00536e7c stw r28,136(r27) >=20 >=20 > 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| > 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| > 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| > 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| > 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| > 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >=20 > 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| > 0x004a3ca0 bl 008ea420 > 0x004a3ca4 mr r3,r27 > 0x004a3ca8 mr r4,r26 > 0x004a3cac mtctr r25 > 0x004a3cb0 bctrl > 0x004a3cb4 lwz r0,108(r28) >=20 > 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| > 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 > 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| > 0x008f18c0 lwz r3,8(r1) > 0x008f18c4 lwz r4,12(r1) > 0x008f18c8 lwz r5,16(r1) > 0x008f18cc bl 004a3bbc > 0x008f18d0 addi r1,r1,16 > 0x008f18d4 b 001008f8 >=20 >=20 > So that is an example context for the failure. >=20 > It has taken weeks to get this. It may be some > time before I get another for comparison/contrast. >=20 > And sticking with the same build vs. trying some more > to find a better way to get more evidence is not > obvious to me at this point. I should have mentioned that this is TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac G5 "Quad Core". I've had 2 more examples, with the same 0x0090a030 srr0 and such (vmcore.0 and vmcore.1) (I have added one more little block of code for detecting an earlier problem symptom not being currently seen so the build is slight different from the earlier report.) Looking around in vmcore.0 I find 3 examples of "00 90 a0 30" in areas overlapping with objdump -x's coverage. . . 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| [ ] (from sorted objdump -x output:) 00c775a8 l O .data 00000dc0 seqprog 00c78368 l O .data 0000000c seeprom_long_ewen [ ] 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| . . . 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| [ ] (from sorted objdump -x output:) 00f64780 g O .bss 00020000 __pcpu 00f84780 l O .bss 00000004 ap_letgo For vmcore.1 I went ahead and tried exploring some with ddb --and had no new panics. . . (Hand transcriptions of pictures) fatal kernel trap: exception =3D 0x700 (program) srr0 =3D 0x90a030 srr1 =3D 0x81032 lr =3D 0x535ad0 curthread =3D 0x147d6c0 pic =3D 11, comm =3D idle: cpu0 [ thread pid 11 tid 100003 ] Stopped at _etext+0xb8fc: illegal instruction 0 db> bt 0xdf5e55d0: at sched_wakeup+0xa4 0xdf5e55f0: at setrunnable+0x9c 0xdf5e5610: at sleepq_resume_thread+0x17c 0xdf5e5640: at sleepq_timeout+0xc8 0xdf5e5680: at softclock_call_cc+0x1f0 0xdf5e56f0: at callout_process+0x27c 0xdf5e57a0: at timercb+0x4c4 0xdf5e5820: at decr_intr+0xf0 0xdf5e5840: at powerpc_interrupt_0xf4 0xdf5e5870: at kernel DECR trap by cpu_idle_60x+0x88 (so: srr0) srr1=3D0x9032 r1 =3D0xdf5e5930 cr =3D0x40000042 xer =3D0x20000000 ctr =3D0x8e3bf8 saved LR(0xfffffffd) is invalid. db> show reg (but reformatted r0 =3D0x4 r1 =3D0xdf5e5590 r2 =3D0x147d6c0 r3 =3D0x54 testppc64size+0x34 r4 =3D0x591d000 r5 =3D0 r6 =3D0 r7 =3D0xf r8 =3D0 r9 =3D0xd4c03c cold r10 =3D0x147d6c0 r11 =3D0xdf5e55d0 r12 =3D0 r13 =3D0 r14 =3D0xd4bdec sdt_probe_func r15 =3D0xcb9898 std_lockstat___spin__release r16 =3D0xd4c45c callwheelmask r17 =3D0xd4c45c callwheelmask r18 =3D0x55925 r19 =3D0x559a4 r20 =3D0x559 dsmisssize+0x469 r21 =3D0x591d000 r22 =3D0x566430 sleeppq_timeout r23 =3D0x114 dsmisssize+0x24 r24 =3D0 r25 =3D0 r26 =3D0x1 r27 =3D0 r28 =3D0xeba780 tdq_cpu r29 =3D0x147d6c0 r30 =3D0xd1caac r31 =3D0xdf5e5590 srr0 =3D0x90a030 srr1 =3D0x81032 lr =3D0x535ad0 shed_affinity+0x18 ctr =3D0 cr =3D0x20009034 xer =3D0 dar =3D0x419df5d4 dsisr=3D0x24000000 _etext+0xb8fc: illegal instruction 0 Just for completeness: acttrace also showed: Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) 0xd25a59f0: at powrpc_dispatch_intr+0xc8 0xd25a5a20: at openpic_dispatch+0x90 0xd25a5a50: at powerpc_interrupt+0xc0 0xd25a5a80: at user EXI trap by 0x181c68c (so: ssr0) r1 =3D0xffffdb30 cr =3D0x44020624 xer=3D0 ctr=3D0x41989570 Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) saved LR(0x4c) in invalid Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) saved LR(0x4c) in invalid =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat May 27 07:42:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C238D8434D for ; Sat, 27 May 2017 07:42:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2119614E2 for ; Sat, 27 May 2017 07:42:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23056 invoked from network); 27 May 2017 07:42:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2017 07:42:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 03:42:21 -0400 (EDT) Received: (qmail 3295 invoked from network); 27 May 2017 07:42:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 07:42:21 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5D05FEC7B46; Sat, 27 May 2017 00:42:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [better bt; more] From: Mark Millard In-Reply-To: <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> Date: Sat, 27 May 2017 00:42:19 -0700 Cc: Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> To: Justin Hibbits , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 07:42:23 -0000 [Top post of the answer to what is wrong. I have submitted 219589 for this.] TARGET_ARCH=3Dpowerpc64 got a fix to bugzilla 205458, avoiding inappropriate restoration of openfirmware's sprg0 value. It turns out that TARGET_ARCH=3Dpowerpc needs to detect when it is running on powerpc64 and do the same thing if it is to avoid trashing memory and running unreliably on PowerMac G5's. The issue is that for powerpc64 it is inappropriate to restore the sprg0 value to its openfirmware value. This is because the FreeBSD real-mode handling is involved instead of the openfirmware's original virtual mode, making openfirware's value simply inappropriate. Quoting Nathan W. from Comment #4 of 205458: > Where this explodes is if OF uses an unmapped SLB entry. > The SLB fault handler runs in real mode and refers to the > PCPU pointer in SPRG0, which blows up the kernel. Having > a value of SPRG0 that works for the kernel is less fatal > than preserving OF's value in this case. I know that part of the code does detect the powerpc64 context vs. not and does things differently to emulate being powerpc like on powerpc64 (such as limiting RAM use as a consequence). The powerpc64 vs. not status needs to be recorded and used to control a sprg0 restoration choice: avoid restoring openfirmware's value on powerpc64; otherwise restore it. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-May-26, at 10:29 PM, Mark Millard wrote: [Additional information that does not need to interlace with the prior material, so see after. A somewhat better backtrace reported by ddb. And so on.] On 2017-May-26, at 7:14 PM, Mark Millard wrote: > I lucked out and got a vmcore.9 for a random > panic that I could manage to backtrace for > one of my test builds of -r317820. It appears > that not all that much happened before it got > the panic so much context was better preserved > this time. >=20 > (I do not explore from ddb as I've had that > panic and mess up the dump just made by > replacing it. So this is a manual backtrace > from the debug.minidump=3D0 style vmcore.9 > file. objdump was used on the > /boot/kernel/kernel to find code.) >=20 > Being able to see the problem is very > sensitive to kernel memory layout. This > is why I'm sticking with -r317820 built > production style: the kind of context > the problem was first observed in. > Attempting a debug kernel build simply > did not repeat the problem for days > (vs. the usual hours for builds like > this). >=20 >=20 > So below is the backtrace: >=20 > (I do not show what trap_fatal calls: > starting with trap_fatal and going toward > larger memory addresses. . .) >=20 > [vmcore.9's > offset > in file > when no > 0x prefix] >=20 > 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| > 0x008f3454 mr r3,r26 > 0x008f3458 bl 008f2030 > 0x008f345c b 008f34c8 >=20 > 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| > * > 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| > 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| > 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| > 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | > 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| > 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| > 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| > 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| > 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| > 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| > 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| > 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| > 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| > 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| > 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| > 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| > 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| > 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >=20 > 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| > 0x008e7d28 mfmsr r0 > 0x008e7d2c or r0,r0,r9 > 0x008e7d30 mtmsr r0 > 0x008e7d34 isync > 0x008e7d38 mr r3,r25 > 0x008e7d3c bl 008f222c > 0x008e7d40 lwz r11,0(r1) >=20 > 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| > 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >=20 > r0 r1 > 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| > The struct trapframe starts is 0x 013e8588 in the > vmcore.9 file. The 0x00108f8 is as shown below: >=20 > 0x001008ec isync > 0x001008f0 addi r3,r1,8 > 0x001008f4 bl 008e7ba4 > 0x001008f8 mfmsr r3 > 0x001008fc andi. r3,r3,32767 >=20 > 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| > r2 r3 r4 r5 >=20 > 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| > r6 r7 r8 r9 >=20 > 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| > r10 r11 r12 r13 >=20 > 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| > r14 r15 r16 r17 >=20 > 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| > r18 r19 r20 r21 >=20 > 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| > r22 r32 r24 r25 >=20 > 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| > r26 r27 r28 r29 >=20 > 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| > r30 r31 lr cr >=20 > xer ctr srr0 srr1 > 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > Note: objdump shows no code at 0x0090a030. 0x0090a030 is > inside what objdump -x reports as the section .hash (Idx > 2). >=20 > exc dar dsisr (booke dbcer0) > 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| > The 0x00007000 above is the framep->exc (exception code) > (program in this case). >=20 > 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >=20 > At this point the above does not match the below > part of the stack trace. >=20 > The lr part of struct trapframe was: 0x00535ad0 so > showing around that: >=20 > 00535ab8 stwu r1,-32(r1) > 00535abc mflr r0 > 00535ac0 stw r29,20(r1) > 00535ac4 stw r30,24(r1) > 00535ac8 stw r31,28(r1) > 00535acc stw r0,36(r1) > 00535ad0 mr r31,r1 > 00535ad4 mr r29,r3 >=20 > Back to the stack backtrace. . . >=20 > 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| > 0x005359c8 bl 008ea420 > 0x005359cc mr r3,r28 > 0x005359d0 mr r4,r27 > 0x005359d4 mr r5,r25 > 0x005359d8 bl 005356ec > 0x005359dc mfsprg r9,0 >=20 > I show around 0x005356ec > from the sched_add+0x19c bl that is above > because the routine is not referenced > in the stack tracce but the above indicates > that it should have been called: > 0x005356ec stwu r1,-32(r1) > 0x005356f0 mflr r0 > 0x005356f4 stw r28,16(r1) > 0x005356f8 stw r29,20(r1) > 0x005356fc stw r30,24(r1) > 0x00535700 stw r31,28(r1) > 0x00535704 stw r0,36(r1) > . . . >=20 > Back to the stack backtrace again. . . >=20 > 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| > 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| > 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >=20 > 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| > 0x004a8780 mr r3,r28 > 0x004a8784 li r4,4 > 0x004a8788 bl 0053583c = > 0x004a878c lwz r9,0(r28) >=20 > 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| > 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >=20 > 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| > 0x004a9700 bl 005000ec > 0x004a9704 mr r3,r27 > 0x004a9708 bl 004a86bc = > 0x004a970c lwz r11,0(r1) >=20 > 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| > 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| > 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >=20 > 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| > 0x00517960 lwz r3,264(r29) > 0x00517964 li r4,0 > 0x00517968 bl 004a965c > 0x0051796c lwz r11,0(r1) >=20 > 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| > 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| > 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| > 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| > 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >=20 > 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| > 0x008ab264 mr r3,r27 > 0x008ab268 mr r4,r28 > 0x008ab26c bl 00517540 > 0x008ab270 li r3,0 >=20 > 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| > 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| > 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| > 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >=20 > 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| > 0x008ad100 mr r3,r26 > 0x008ad104 mr r4,r27 > 0x008ad108 li r5,0 > 0x008ad10c bl 008aafc0 > 0x008ad110 lwz r11,0(r1) >=20 > 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| > 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| > 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| > 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| > 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| > 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| > 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >=20 > 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| > So 0x13e8820 from vmcore.9 has start of struct trapeframe. > The 0x8e1e48 is from: > 0x008e1e34 lwz r0,56(r28) > 0x008e1e38 mtctr r0 > 0x008e1e3c mr r3,r28 > 0x008e1e40 lwz r4,64(r28) > 0x008e1e44 bctrl > 0x008e1e48 addi r29,r29,-1 >=20 > 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| > 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| > 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| > 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| > 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| > 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| > 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| > 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| > 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| > 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| > 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| > 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >=20 > srr0 > 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| > The 0x00833c14 from the trap frame is the srr0 (conceptual lr): > 0x008e3c04 stw r31,28(r1) > 0x008e3c08 stw r0,36(r1) > 0x008e3c0c mr r31,r1 > 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = > 0x008e3c14 mflr r30 > 0x008e3c18 lwz r0,-32(r30) >=20 > 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >=20 > exc > 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| > The 0x00009000 above is the framep->exc (exception code) > (decrementer in this case). >=20 > 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >=20 > 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| > (trap [above] means no lr filled in here) >=20 > 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >=20 > 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| > 0x008e318c bl 008ad8b8 > 0x008e3190 lwz r29,0(r29) > 0x008e3194 mtctr r29 > 0x008e3198 bctrl > 0x008e319c bl 008ad7b8 >=20 > 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >=20 > 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| > 0x00536e78 bl 008e3144 > 0x00536e7c stw r28,136(r27) >=20 >=20 > 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| > 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| > 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| > 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| > 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| > 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >=20 > 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| > 0x004a3ca0 bl 008ea420 > 0x004a3ca4 mr r3,r27 > 0x004a3ca8 mr r4,r26 > 0x004a3cac mtctr r25 > 0x004a3cb0 bctrl > 0x004a3cb4 lwz r0,108(r28) >=20 > 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| > 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 > 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| > 0x008f18c0 lwz r3,8(r1) > 0x008f18c4 lwz r4,12(r1) > 0x008f18c8 lwz r5,16(r1) > 0x008f18cc bl 004a3bbc > 0x008f18d0 addi r1,r1,16 > 0x008f18d4 b 001008f8 >=20 >=20 > So that is an example context for the failure. >=20 > It has taken weeks to get this. It may be some > time before I get another for comparison/contrast. >=20 > And sticking with the same build vs. trying some more > to find a better way to get more evidence is not > obvious to me at this point. I should have mentioned that this is TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac G5 "Quad Core". I've had 2 more examples, with the same 0x0090a030 srr0 and such (vmcore.0 and vmcore.1) (I have added one more little block of code for detecting an earlier problem symptom not being currently seen so the build is slight different from the earlier report.) Looking around in vmcore.0 I find 3 examples of "00 90 a0 30" in areas overlapping with objdump -x's coverage. . . 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| [ ] (from sorted objdump -x output:) 00c775a8 l O .data 00000dc0 seqprog 00c78368 l O .data 0000000c seeprom_long_ewen [ ] 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| . . . 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| [ ] (from sorted objdump -x output:) 00f64780 g O .bss 00020000 __pcpu 00f84780 l O .bss 00000004 ap_letgo For vmcore.1 I went ahead and tried exploring some with ddb --and had no new panics. . . (Hand transcriptions of pictures) fatal kernel trap: exception =3D 0x700 (program) srr0 =3D 0x90a030 srr1 =3D 0x81032 lr =3D 0x535ad0 curthread =3D 0x147d6c0 pic =3D 11, comm =3D idle: cpu0 [ thread pid 11 tid 100003 ] Stopped at _etext+0xb8fc: illegal instruction 0 db> bt 0xdf5e55d0: at sched_wakeup+0xa4 0xdf5e55f0: at setrunnable+0x9c 0xdf5e5610: at sleepq_resume_thread+0x17c 0xdf5e5640: at sleepq_timeout+0xc8 0xdf5e5680: at softclock_call_cc+0x1f0 0xdf5e56f0: at callout_process+0x27c 0xdf5e57a0: at timercb+0x4c4 0xdf5e5820: at decr_intr+0xf0 0xdf5e5840: at powerpc_interrupt_0xf4 0xdf5e5870: at kernel DECR trap by cpu_idle_60x+0x88 (so: srr0) srr1=3D0x9032 r1 =3D0xdf5e5930 cr =3D0x40000042 xer =3D0x20000000 ctr =3D0x8e3bf8 saved LR(0xfffffffd) is invalid. db> show reg (but reformatted r0 =3D0x4 r1 =3D0xdf5e5590 r2 =3D0x147d6c0 r3 =3D0x54 testppc64size+0x34 r4 =3D0x591d000 r5 =3D0 r6 =3D0 r7 =3D0xf r8 =3D0 r9 =3D0xd4c03c cold r10 =3D0x147d6c0 r11 =3D0xdf5e55d0 r12 =3D0 r13 =3D0 r14 =3D0xd4bdec sdt_probe_func r15 =3D0xcb9898 std_lockstat___spin__release r16 =3D0xd4c45c callwheelmask r17 =3D0xd4c45c callwheelmask r18 =3D0x55925 r19 =3D0x559a4 r20 =3D0x559 dsmisssize+0x469 r21 =3D0x591d000 r22 =3D0x566430 sleeppq_timeout r23 =3D0x114 dsmisssize+0x24 r24 =3D0 r25 =3D0 r26 =3D0x1 r27 =3D0 r28 =3D0xeba780 tdq_cpu r29 =3D0x147d6c0 r30 =3D0xd1caac r31 =3D0xdf5e5590 srr0 =3D0x90a030 srr1 =3D0x81032 lr =3D0x535ad0 shed_affinity+0x18 ctr =3D0 cr =3D0x20009034 xer =3D0 dar =3D0x419df5d4 dsisr=3D0x24000000 _etext+0xb8fc: illegal instruction 0 Just for completeness: acttrace also showed: Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) 0xd25a59f0: at powrpc_dispatch_intr+0xc8 0xd25a5a20: at openpic_dispatch+0x90 0xd25a5a50: at powerpc_interrupt+0xc0 0xd25a5a80: at user EXI trap by 0x181c68c (so: ssr0) r1 =3D0xffffdb30 cr =3D0x44020624 xer=3D0 ctr=3D0x41989570 Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) saved LR(0x4c) in invalid Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) saved LR(0x4c) in invalid =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat May 27 08:17:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47083D84E52 for ; Sat, 27 May 2017 08:17:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEA2D14EE for ; Sat, 27 May 2017 08:17:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30373 invoked from network); 27 May 2017 08:21:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2017 08:21:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 04:17:24 -0400 (EDT) Received: (qmail 32529 invoked from network); 27 May 2017 08:17:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 08:17:24 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4B1DBEC7B46; Sat, 27 May 2017 01:17:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [better bt; more] From: Mark Millard In-Reply-To: <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> Date: Sat, 27 May 2017 01:17:22 -0700 Cc: Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> To: Justin Hibbits , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 08:17:26 -0000 [I suggest a patch this time.] On 2017-May-27, at 12:42 AM, Mark Millard wrote: > [Top post of the answer to what is wrong. I > have submitted 219589 for this.] >=20 > TARGET_ARCH=3Dpowerpc64 got a fix to > bugzilla 205458, avoiding inappropriate > restoration of openfirmware's sprg0 > value. >=20 > It turns out that TARGET_ARCH=3Dpowerpc > needs to detect when it is running on > powerpc64 and do the same thing if it > is to avoid trashing memory and running > unreliably on PowerMac G5's. >=20 > The issue is that for powerpc64 it is > inappropriate to restore the sprg0 > value to its openfirmware value. This > is because the FreeBSD real-mode > handling is involved instead of the > openfirmware's original virtual mode, > making openfirware's value simply > inappropriate. >=20 > Quoting Nathan W. from Comment > #4 of 205458: >=20 >> Where this explodes is if OF uses an unmapped SLB entry. >> The SLB fault handler runs in real mode and refers to the >> PCPU pointer in SPRG0, which blows up the kernel. Having >> a value of SPRG0 that works for the kernel is less fatal >> than preserving OF's value in this case. >=20 > I know that part of the code does detect > the powerpc64 context vs. not and does > things differently to emulate being powerpc > like on powerpc64 (such as limiting > RAM use as a consequence). >=20 > The powerpc64 vs. not status needs to be > recorded and used to control a sprg0 > restoration choice: avoid restoring > openfirmware's value on powerpc64; > otherwise restore it. I expect that the following patch would fix the problem: # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 317820) +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -147,7 +147,8 @@ * PCPU data cannot be used until this routine is called ! */ #ifndef __powerpc64__ - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); + if (cpu_features & PPC_FEATURE_64 !=3D PPC_FEATURE_64) + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); #endif } #endif This is based on cpu_features already having had PPC_FEATURE_64 masked in before this if things are running on a PowerMac G5 or other powerpc64. =3D=3D=3D Mark Millard markmi at dsl-only.net [The original (better) panic evidence. . .] On 2017-May-26, at 10:29 PM, Mark Millard wrote: > [Additional information that does not need to > interlace with the prior material, so see > after. A somewhat better backtrace reported > by ddb. And so on.] >=20 >=20 > On 2017-May-26, at 7:14 PM, Mark Millard = wrote: >=20 >> I lucked out and got a vmcore.9 for a random >> panic that I could manage to backtrace for >> one of my test builds of -r317820. It appears >> that not all that much happened before it got >> the panic so much context was better preserved >> this time. >>=20 >> (I do not explore from ddb as I've had that >> panic and mess up the dump just made by >> replacing it. So this is a manual backtrace >> from the debug.minidump=3D0 style vmcore.9 >> file. objdump was used on the >> /boot/kernel/kernel to find code.) >>=20 >> Being able to see the problem is very >> sensitive to kernel memory layout. This >> is why I'm sticking with -r317820 built >> production style: the kind of context >> the problem was first observed in. >> Attempting a debug kernel build simply >> did not repeat the problem for days >> (vs. the usual hours for builds like >> this). >>=20 >>=20 >> So below is the backtrace: >>=20 >> (I do not show what trap_fatal calls: >> starting with trap_fatal and going toward >> larger memory addresses. . .) >>=20 >> [vmcore.9's >> offset >> in file >> when no >> 0x prefix] >>=20 >> 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| >> 0x008f3454 mr r3,r26 >> 0x008f3458 bl 008f2030 >> 0x008f345c b 008f34c8 >>=20 >> 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| >> * >> 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| >> 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| >> 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| >> 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | >> 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| >> 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| >> 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| >> 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| >> 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| >> 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| >> 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| >> 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| >> 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| >> 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| >> 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| >> 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| >> 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| >> 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >>=20 >> 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| >> 0x008e7d28 mfmsr r0 >> 0x008e7d2c or r0,r0,r9 >> 0x008e7d30 mtmsr r0 >> 0x008e7d34 isync >> 0x008e7d38 mr r3,r25 >> 0x008e7d3c bl 008f222c >> 0x008e7d40 lwz r11,0(r1) >>=20 >> 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| >> 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >>=20 >> r0 r1 >> 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| >> The struct trapframe starts is 0x 013e8588 in the >> vmcore.9 file. The 0x00108f8 is as shown below: >>=20 >> 0x001008ec isync >> 0x001008f0 addi r3,r1,8 >> 0x001008f4 bl 008e7ba4 >> 0x001008f8 mfmsr r3 >> 0x001008fc andi. r3,r3,32767 >>=20 >> 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| >> r2 r3 r4 r5 >>=20 >> 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| >> r6 r7 r8 r9 >>=20 >> 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| >> r10 r11 r12 r13 >>=20 >> 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| >> r14 r15 r16 r17 >>=20 >> 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| >> r18 r19 r20 r21 >>=20 >> 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| >> r22 r32 r24 r25 >>=20 >> 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| >> r26 r27 r28 r29 >>=20 >> 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| >> r30 r31 lr cr >>=20 >> xer ctr srr0 srr1 >> 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >> Note: objdump shows no code at 0x0090a030. 0x0090a030 is >> inside what objdump -x reports as the section .hash (Idx >> 2). >>=20 >> exc dar dsisr (booke dbcer0) >> 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| >> The 0x00007000 above is the framep->exc (exception code) >> (program in this case). >>=20 >> 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >>=20 >> At this point the above does not match the below >> part of the stack trace. >>=20 >> The lr part of struct trapframe was: 0x00535ad0 so >> showing around that: >>=20 >> 00535ab8 stwu r1,-32(r1) >> 00535abc mflr r0 >> 00535ac0 stw r29,20(r1) >> 00535ac4 stw r30,24(r1) >> 00535ac8 stw r31,28(r1) >> 00535acc stw r0,36(r1) >> 00535ad0 mr r31,r1 >> 00535ad4 mr r29,r3 >>=20 >> Back to the stack backtrace. . . >>=20 >> 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| >> 0x005359c8 bl 008ea420 >> 0x005359cc mr r3,r28 >> 0x005359d0 mr r4,r27 >> 0x005359d4 mr r5,r25 >> 0x005359d8 bl 005356ec >> 0x005359dc mfsprg r9,0 >>=20 >> I show around 0x005356ec >> from the sched_add+0x19c bl that is above >> because the routine is not referenced >> in the stack tracce but the above indicates >> that it should have been called: >> 0x005356ec stwu r1,-32(r1) >> 0x005356f0 mflr r0 >> 0x005356f4 stw r28,16(r1) >> 0x005356f8 stw r29,20(r1) >> 0x005356fc stw r30,24(r1) >> 0x00535700 stw r31,28(r1) >> 0x00535704 stw r0,36(r1) >> . . . >>=20 >> Back to the stack backtrace again. . . >>=20 >> 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| >> 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| >> 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >>=20 >> 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| >> 0x004a8780 mr r3,r28 >> 0x004a8784 li r4,4 >> 0x004a8788 bl 0053583c = >> 0x004a878c lwz r9,0(r28) >>=20 >> 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| >> 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >>=20 >> 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| >> 0x004a9700 bl 005000ec >> 0x004a9704 mr r3,r27 >> 0x004a9708 bl 004a86bc = >> 0x004a970c lwz r11,0(r1) >>=20 >> 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| >> 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| >> 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >>=20 >> 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| >> 0x00517960 lwz r3,264(r29) >> 0x00517964 li r4,0 >> 0x00517968 bl 004a965c >> 0x0051796c lwz r11,0(r1) >>=20 >> 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| >> 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| >> 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| >> 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >>=20 >> 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| >> 0x008ab264 mr r3,r27 >> 0x008ab268 mr r4,r28 >> 0x008ab26c bl 00517540 >> 0x008ab270 li r3,0 >>=20 >> 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| >> 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| >> 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| >> 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >>=20 >> 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| >> 0x008ad100 mr r3,r26 >> 0x008ad104 mr r4,r27 >> 0x008ad108 li r5,0 >> 0x008ad10c bl 008aafc0 >> 0x008ad110 lwz r11,0(r1) >>=20 >> 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| >> 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| >> 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| >> 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| >> 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| >> 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >>=20 >> 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| >> So 0x13e8820 from vmcore.9 has start of struct trapeframe. >> The 0x8e1e48 is from: >> 0x008e1e34 lwz r0,56(r28) >> 0x008e1e38 mtctr r0 >> 0x008e1e3c mr r3,r28 >> 0x008e1e40 lwz r4,64(r28) >> 0x008e1e44 bctrl >> 0x008e1e48 addi r29,r29,-1 >>=20 >> 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| >> 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| >> 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| >> 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| >> 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| >> 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| >> 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| >> 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| >> 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| >> 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| >> 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| >> 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >>=20 >> srr0 >> 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| >> The 0x00833c14 from the trap frame is the srr0 (conceptual lr): >> 0x008e3c04 stw r31,28(r1) >> 0x008e3c08 stw r0,36(r1) >> 0x008e3c0c mr r31,r1 >> 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = >> 0x008e3c14 mflr r30 >> 0x008e3c18 lwz r0,-32(r30) >>=20 >> 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >>=20 >> exc >> 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| >> The 0x00009000 above is the framep->exc (exception code) >> (decrementer in this case). >>=20 >> 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >>=20 >> 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| >> (trap [above] means no lr filled in here) >>=20 >> 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >>=20 >> 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| >> 0x008e318c bl 008ad8b8 >> 0x008e3190 lwz r29,0(r29) >> 0x008e3194 mtctr r29 >> 0x008e3198 bctrl >> 0x008e319c bl 008ad7b8 >>=20 >> 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >>=20 >> 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| >> 0x00536e78 bl 008e3144 >> 0x00536e7c stw r28,136(r27) >>=20 >>=20 >> 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| >> 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| >> 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| >> 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| >> 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| >> 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >>=20 >> 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| >> 0x004a3ca0 bl 008ea420 >> 0x004a3ca4 mr r3,r27 >> 0x004a3ca8 mr r4,r26 >> 0x004a3cac mtctr r25 >> 0x004a3cb0 bctrl >> 0x004a3cb4 lwz r0,108(r28) >>=20 >> 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| >> 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>=20 >> 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| >> 0x008f18c0 lwz r3,8(r1) >> 0x008f18c4 lwz r4,12(r1) >> 0x008f18c8 lwz r5,16(r1) >> 0x008f18cc bl 004a3bbc >> 0x008f18d0 addi r1,r1,16 >> 0x008f18d4 b 001008f8 >>=20 >>=20 >> So that is an example context for the failure. >>=20 >> It has taken weeks to get this. It may be some >> time before I get another for comparison/contrast. >>=20 >> And sticking with the same build vs. trying some more >> to find a better way to get more evidence is not >> obvious to me at this point. >=20 > I should have mentioned that this is > TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac > G5 "Quad Core". >=20 > I've had 2 more examples, with the same 0x0090a030 > srr0 and such (vmcore.0 and vmcore.1) (I have added > one more little block of code for detecting an earlier > problem symptom not being currently seen so the build > is slight different from the earlier report.) >=20 > Looking around in vmcore.0 I find 3 examples of > "00 90 a0 30" in areas overlapping with objdump -x's > coverage. . . >=20 > 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > [ ] >=20 > (from sorted objdump -x output:) > 00c775a8 l O .data 00000dc0 seqprog > 00c78368 l O .data 0000000c seeprom_long_ewen >=20 > [ ] > 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| > . . . > 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| > [ ] >=20 > (from sorted objdump -x output:) > 00f64780 g O .bss 00020000 __pcpu > 00f84780 l O .bss 00000004 ap_letgo >=20 >=20 > For vmcore.1 I went ahead and tried exploring > some with ddb --and had no new panics. . . > (Hand transcriptions of pictures) >=20 > fatal kernel trap: > exception =3D 0x700 (program) > srr0 =3D 0x90a030 > srr1 =3D 0x81032 > lr =3D 0x535ad0 > curthread =3D 0x147d6c0 > pic =3D 11, comm =3D idle: cpu0 >=20 > [ thread pid 11 tid 100003 ] > Stopped at _etext+0xb8fc: illegal instruction 0 > db> bt > 0xdf5e55d0: at sched_wakeup+0xa4 > 0xdf5e55f0: at setrunnable+0x9c > 0xdf5e5610: at sleepq_resume_thread+0x17c > 0xdf5e5640: at sleepq_timeout+0xc8 > 0xdf5e5680: at softclock_call_cc+0x1f0 > 0xdf5e56f0: at callout_process+0x27c > 0xdf5e57a0: at timercb+0x4c4 > 0xdf5e5820: at decr_intr+0xf0 > 0xdf5e5840: at powerpc_interrupt_0xf4 > 0xdf5e5870: at kernel DECR trap > by cpu_idle_60x+0x88 (so: srr0) > srr1=3D0x9032 > r1 =3D0xdf5e5930 > cr =3D0x40000042 > xer =3D0x20000000 > ctr =3D0x8e3bf8 > saved LR(0xfffffffd) is invalid. >=20 > db> show reg (but reformatted > r0 =3D0x4 > r1 =3D0xdf5e5590 > r2 =3D0x147d6c0 > r3 =3D0x54 testppc64size+0x34 > r4 =3D0x591d000 > r5 =3D0 > r6 =3D0 > r7 =3D0xf > r8 =3D0 > r9 =3D0xd4c03c cold > r10 =3D0x147d6c0 > r11 =3D0xdf5e55d0 > r12 =3D0 > r13 =3D0 > r14 =3D0xd4bdec sdt_probe_func > r15 =3D0xcb9898 std_lockstat___spin__release > r16 =3D0xd4c45c callwheelmask > r17 =3D0xd4c45c callwheelmask > r18 =3D0x55925 > r19 =3D0x559a4 > r20 =3D0x559 dsmisssize+0x469 > r21 =3D0x591d000 > r22 =3D0x566430 sleeppq_timeout > r23 =3D0x114 dsmisssize+0x24 > r24 =3D0 > r25 =3D0 > r26 =3D0x1 > r27 =3D0 > r28 =3D0xeba780 tdq_cpu > r29 =3D0x147d6c0 > r30 =3D0xd1caac > r31 =3D0xdf5e5590 > srr0 =3D0x90a030 > srr1 =3D0x81032 > lr =3D0x535ad0 shed_affinity+0x18 > ctr =3D0 > cr =3D0x20009034 > xer =3D0 > dar =3D0x419df5d4 > dsisr=3D0x24000000 > _etext+0xb8fc: illegal instruction 0 >=20 >=20 > Just for completeness: acttrace also showed: >=20 > Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) > 0xd25a59f0: at powrpc_dispatch_intr+0xc8 > 0xd25a5a20: at openpic_dispatch+0x90 > 0xd25a5a50: at powerpc_interrupt+0xc0 > 0xd25a5a80: at user EXI trap > by 0x181c68c (so: ssr0) > r1 =3D0xffffdb30 > cr =3D0x44020624 > xer=3D0 > ctr=3D0x41989570 >=20 > Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) > saved LR(0x4c) in invalid >=20 > Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) > saved LR(0x4c) in invalid From owner-freebsd-hackers@freebsd.org Sat May 27 08:32:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5ADC4D81835 for ; Sat, 27 May 2017 08:32:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F5471488 for ; Sat, 27 May 2017 08:32:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24469 invoked from network); 27 May 2017 08:32:24 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 May 2017 08:32:24 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 04:32:24 -0400 (EDT) Received: (qmail 2212 invoked from network); 27 May 2017 08:32:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 08:32:23 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 00EDEEC7B46; Sat, 27 May 2017 01:32:22 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [better bt; more] Date: Sat, 27 May 2017 01:32:22 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> To: Justin Hibbits , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <67C79408-0DDC-4A22-BFEC-6EC5DD80F076@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 08:32:26 -0000 [It helps to type all my ()'s. Trying again, using idiom from elsewhere in the file. . .] On 2017-May-27, at 1:17 AM, Mark Millard wrote: > [I suggest a patch this time.] >=20 > On 2017-May-27, at 12:42 AM, Mark Millard wrote: >=20 >> [Top post of the answer to what is wrong. I >> have submitted 219589 for this.] >>=20 >> TARGET_ARCH=3Dpowerpc64 got a fix to >> bugzilla 205458, avoiding inappropriate >> restoration of openfirmware's sprg0 >> value. >>=20 >> It turns out that TARGET_ARCH=3Dpowerpc >> needs to detect when it is running on >> powerpc64 and do the same thing if it >> is to avoid trashing memory and running >> unreliably on PowerMac G5's. >>=20 >> The issue is that for powerpc64 it is >> inappropriate to restore the sprg0 >> value to its openfirmware value. This >> is because the FreeBSD real-mode >> handling is involved instead of the >> openfirmware's original virtual mode, >> making openfirware's value simply >> inappropriate. >>=20 >> Quoting Nathan W. from Comment >> #4 of 205458: >>=20 >>> Where this explodes is if OF uses an unmapped SLB entry. >>> The SLB fault handler runs in real mode and refers to the >>> PCPU pointer in SPRG0, which blows up the kernel. Having >>> a value of SPRG0 that works for the kernel is less fatal >>> than preserving OF's value in this case. >>=20 >> I know that part of the code does detect >> the powerpc64 context vs. not and does >> things differently to emulate being powerpc >> like on powerpc64 (such as limiting >> RAM use as a consequence). >>=20 >> The powerpc64 vs. not status needs to be >> recorded and used to control a sprg0 >> restoration choice: avoid restoring >> openfirmware's value on powerpc64; >> otherwise restore it. >=20 > I expect that the following patch would > fix the problem: >=20 > # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 317820) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -147,7 +147,8 @@ > * PCPU data cannot be used until this routine is called ! > */ > #ifndef __powerpc64__ > - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > + if (cpu_features & PPC_FEATURE_64 !=3D PPC_FEATURE_64) > + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > #endif > } > #endif >=20 > This is based on cpu_features already having had > PPC_FEATURE_64 masked in before this if things > are running on a PowerMac G5 or other powerpc64. Fixing the ()'s mistake above: # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 317820) +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -147,7 +147,8 @@ * PCPU data cannot be used until this routine is called ! */ #ifndef __powerpc64__ - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); + if (!(cpu_features & PPC_FEATURE_64)) + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); #endif } #endif =3D=3D=3D Mark Millard markmi at dsl-only.net [The original (better) panic evidence. . .] On 2017-May-26, at 10:29 PM, Mark Millard wrote: > [Additional information that does not need to > interlace with the prior material, so see > after. A somewhat better backtrace reported > by ddb. And so on.] >=20 >=20 > On 2017-May-26, at 7:14 PM, Mark Millard = wrote: >=20 >> I lucked out and got a vmcore.9 for a random >> panic that I could manage to backtrace for >> one of my test builds of -r317820. It appears >> that not all that much happened before it got >> the panic so much context was better preserved >> this time. >>=20 >> (I do not explore from ddb as I've had that >> panic and mess up the dump just made by >> replacing it. So this is a manual backtrace >> from the debug.minidump=3D0 style vmcore.9 >> file. objdump was used on the >> /boot/kernel/kernel to find code.) >>=20 >> Being able to see the problem is very >> sensitive to kernel memory layout. This >> is why I'm sticking with -r317820 built >> production style: the kind of context >> the problem was first observed in. >> Attempting a debug kernel build simply >> did not repeat the problem for days >> (vs. the usual hours for builds like >> this). >>=20 >>=20 >> So below is the backtrace: >>=20 >> (I do not show what trap_fatal calls: >> starting with trap_fatal and going toward >> larger memory addresses. . .) >>=20 >> [vmcore.9's >> offset >> in file >> when no >> 0x prefix] >>=20 >> 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| >> 0x008f3454 mr r3,r26 >> 0x008f3458 bl 008f2030 >> 0x008f345c b 008f34c8 >>=20 >> 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| >> * >> 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| >> 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| >> 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| >> 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | >> 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| >> 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| >> 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| >> 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| >> 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| >> 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| >> 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| >> 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| >> 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| >> 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| >> 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| >> 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| >> 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| >> 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >>=20 >> 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| >> 0x008e7d28 mfmsr r0 >> 0x008e7d2c or r0,r0,r9 >> 0x008e7d30 mtmsr r0 >> 0x008e7d34 isync >> 0x008e7d38 mr r3,r25 >> 0x008e7d3c bl 008f222c >> 0x008e7d40 lwz r11,0(r1) >>=20 >> 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| >> 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >>=20 >> r0 r1 >> 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| >> The struct trapframe starts is 0x 013e8588 in the >> vmcore.9 file. The 0x00108f8 is as shown below: >>=20 >> 0x001008ec isync >> 0x001008f0 addi r3,r1,8 >> 0x001008f4 bl 008e7ba4 >> 0x001008f8 mfmsr r3 >> 0x001008fc andi. r3,r3,32767 >>=20 >> 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| >> r2 r3 r4 r5 >>=20 >> 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| >> r6 r7 r8 r9 >>=20 >> 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| >> r10 r11 r12 r13 >>=20 >> 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| >> r14 r15 r16 r17 >>=20 >> 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| >> r18 r19 r20 r21 >>=20 >> 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| >> r22 r32 r24 r25 >>=20 >> 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| >> r26 r27 r28 r29 >>=20 >> 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| >> r30 r31 lr cr >>=20 >> xer ctr srr0 srr1 >> 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >> Note: objdump shows no code at 0x0090a030. 0x0090a030 is >> inside what objdump -x reports as the section .hash (Idx >> 2). >>=20 >> exc dar dsisr (booke dbcer0) >> 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| >> The 0x00007000 above is the framep->exc (exception code) >> (program in this case). >>=20 >> 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >>=20 >> At this point the above does not match the below >> part of the stack trace. >>=20 >> The lr part of struct trapframe was: 0x00535ad0 so >> showing around that: >>=20 >> 00535ab8 stwu r1,-32(r1) >> 00535abc mflr r0 >> 00535ac0 stw r29,20(r1) >> 00535ac4 stw r30,24(r1) >> 00535ac8 stw r31,28(r1) >> 00535acc stw r0,36(r1) >> 00535ad0 mr r31,r1 >> 00535ad4 mr r29,r3 >>=20 >> Back to the stack backtrace. . . >>=20 >> 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| >> 0x005359c8 bl 008ea420 >> 0x005359cc mr r3,r28 >> 0x005359d0 mr r4,r27 >> 0x005359d4 mr r5,r25 >> 0x005359d8 bl 005356ec >> 0x005359dc mfsprg r9,0 >>=20 >> I show around 0x005356ec >> from the sched_add+0x19c bl that is above >> because the routine is not referenced >> in the stack tracce but the above indicates >> that it should have been called: >> 0x005356ec stwu r1,-32(r1) >> 0x005356f0 mflr r0 >> 0x005356f4 stw r28,16(r1) >> 0x005356f8 stw r29,20(r1) >> 0x005356fc stw r30,24(r1) >> 0x00535700 stw r31,28(r1) >> 0x00535704 stw r0,36(r1) >> . . . >>=20 >> Back to the stack backtrace again. . . >>=20 >> 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| >> 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| >> 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >>=20 >> 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| >> 0x004a8780 mr r3,r28 >> 0x004a8784 li r4,4 >> 0x004a8788 bl 0053583c = >> 0x004a878c lwz r9,0(r28) >>=20 >> 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| >> 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >>=20 >> 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| >> 0x004a9700 bl 005000ec >> 0x004a9704 mr r3,r27 >> 0x004a9708 bl 004a86bc = >> 0x004a970c lwz r11,0(r1) >>=20 >> 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| >> 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| >> 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >>=20 >> 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| >> 0x00517960 lwz r3,264(r29) >> 0x00517964 li r4,0 >> 0x00517968 bl 004a965c >> 0x0051796c lwz r11,0(r1) >>=20 >> 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| >> 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| >> 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| >> 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >>=20 >> 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| >> 0x008ab264 mr r3,r27 >> 0x008ab268 mr r4,r28 >> 0x008ab26c bl 00517540 >> 0x008ab270 li r3,0 >>=20 >> 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| >> 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| >> 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| >> 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >>=20 >> 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| >> 0x008ad100 mr r3,r26 >> 0x008ad104 mr r4,r27 >> 0x008ad108 li r5,0 >> 0x008ad10c bl 008aafc0 >> 0x008ad110 lwz r11,0(r1) >>=20 >> 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| >> 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| >> 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| >> 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| >> 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| >> 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >>=20 >> 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| >> So 0x13e8820 from vmcore.9 has start of struct trapeframe. >> The 0x8e1e48 is from: >> 0x008e1e34 lwz r0,56(r28) >> 0x008e1e38 mtctr r0 >> 0x008e1e3c mr r3,r28 >> 0x008e1e40 lwz r4,64(r28) >> 0x008e1e44 bctrl >> 0x008e1e48 addi r29,r29,-1 >>=20 >> 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| >> 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| >> 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| >> 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| >> 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| >> 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| >> 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| >> 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| >> 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| >> 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| >> 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| >> 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >>=20 >> srr0 >> 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| >> The 0x00833c14 from the trap frame is the srr0 (conceptual lr): >> 0x008e3c04 stw r31,28(r1) >> 0x008e3c08 stw r0,36(r1) >> 0x008e3c0c mr r31,r1 >> 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = >> 0x008e3c14 mflr r30 >> 0x008e3c18 lwz r0,-32(r30) >>=20 >> 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >>=20 >> exc >> 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| >> The 0x00009000 above is the framep->exc (exception code) >> (decrementer in this case). >>=20 >> 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >>=20 >> 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| >> (trap [above] means no lr filled in here) >>=20 >> 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >>=20 >> 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| >> 0x008e318c bl 008ad8b8 >> 0x008e3190 lwz r29,0(r29) >> 0x008e3194 mtctr r29 >> 0x008e3198 bctrl >> 0x008e319c bl 008ad7b8 >>=20 >> 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >>=20 >> 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| >> 0x00536e78 bl 008e3144 >> 0x00536e7c stw r28,136(r27) >>=20 >>=20 >> 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| >> 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| >> 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| >> 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| >> 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| >> 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >>=20 >> 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| >> 0x004a3ca0 bl 008ea420 >> 0x004a3ca4 mr r3,r27 >> 0x004a3ca8 mr r4,r26 >> 0x004a3cac mtctr r25 >> 0x004a3cb0 bctrl >> 0x004a3cb4 lwz r0,108(r28) >>=20 >> 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| >> 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>=20 >> 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| >> 0x008f18c0 lwz r3,8(r1) >> 0x008f18c4 lwz r4,12(r1) >> 0x008f18c8 lwz r5,16(r1) >> 0x008f18cc bl 004a3bbc >> 0x008f18d0 addi r1,r1,16 >> 0x008f18d4 b 001008f8 >>=20 >>=20 >> So that is an example context for the failure. >>=20 >> It has taken weeks to get this. It may be some >> time before I get another for comparison/contrast. >>=20 >> And sticking with the same build vs. trying some more >> to find a better way to get more evidence is not >> obvious to me at this point. >=20 > I should have mentioned that this is > TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac > G5 "Quad Core". >=20 > I've had 2 more examples, with the same 0x0090a030 > srr0 and such (vmcore.0 and vmcore.1) (I have added > one more little block of code for detecting an earlier > problem symptom not being currently seen so the build > is slight different from the earlier report.) >=20 > Looking around in vmcore.0 I find 3 examples of > "00 90 a0 30" in areas overlapping with objdump -x's > coverage. . . >=20 > 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > [ ] >=20 > (from sorted objdump -x output:) > 00c775a8 l O .data 00000dc0 seqprog > 00c78368 l O .data 0000000c seeprom_long_ewen >=20 > [ ] > 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| > . . . > 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| > [ ] >=20 > (from sorted objdump -x output:) > 00f64780 g O .bss 00020000 __pcpu > 00f84780 l O .bss 00000004 ap_letgo >=20 >=20 > For vmcore.1 I went ahead and tried exploring > some with ddb --and had no new panics. . . > (Hand transcriptions of pictures) >=20 > fatal kernel trap: > exception =3D 0x700 (program) > srr0 =3D 0x90a030 > srr1 =3D 0x81032 > lr =3D 0x535ad0 > curthread =3D 0x147d6c0 > pic =3D 11, comm =3D idle: cpu0 >=20 > [ thread pid 11 tid 100003 ] > Stopped at _etext+0xb8fc: illegal instruction 0 > db> bt > 0xdf5e55d0: at sched_wakeup+0xa4 > 0xdf5e55f0: at setrunnable+0x9c > 0xdf5e5610: at sleepq_resume_thread+0x17c > 0xdf5e5640: at sleepq_timeout+0xc8 > 0xdf5e5680: at softclock_call_cc+0x1f0 > 0xdf5e56f0: at callout_process+0x27c > 0xdf5e57a0: at timercb+0x4c4 > 0xdf5e5820: at decr_intr+0xf0 > 0xdf5e5840: at powerpc_interrupt_0xf4 > 0xdf5e5870: at kernel DECR trap > by cpu_idle_60x+0x88 (so: srr0) > srr1=3D0x9032 > r1 =3D0xdf5e5930 > cr =3D0x40000042 > xer =3D0x20000000 > ctr =3D0x8e3bf8 > saved LR(0xfffffffd) is invalid. >=20 > db> show reg (but reformatted > r0 =3D0x4 > r1 =3D0xdf5e5590 > r2 =3D0x147d6c0 > r3 =3D0x54 testppc64size+0x34 > r4 =3D0x591d000 > r5 =3D0 > r6 =3D0 > r7 =3D0xf > r8 =3D0 > r9 =3D0xd4c03c cold > r10 =3D0x147d6c0 > r11 =3D0xdf5e55d0 > r12 =3D0 > r13 =3D0 > r14 =3D0xd4bdec sdt_probe_func > r15 =3D0xcb9898 std_lockstat___spin__release > r16 =3D0xd4c45c callwheelmask > r17 =3D0xd4c45c callwheelmask > r18 =3D0x55925 > r19 =3D0x559a4 > r20 =3D0x559 dsmisssize+0x469 > r21 =3D0x591d000 > r22 =3D0x566430 sleeppq_timeout > r23 =3D0x114 dsmisssize+0x24 > r24 =3D0 > r25 =3D0 > r26 =3D0x1 > r27 =3D0 > r28 =3D0xeba780 tdq_cpu > r29 =3D0x147d6c0 > r30 =3D0xd1caac > r31 =3D0xdf5e5590 > srr0 =3D0x90a030 > srr1 =3D0x81032 > lr =3D0x535ad0 shed_affinity+0x18 > ctr =3D0 > cr =3D0x20009034 > xer =3D0 > dar =3D0x419df5d4 > dsisr=3D0x24000000 > _etext+0xb8fc: illegal instruction 0 >=20 >=20 > Just for completeness: acttrace also showed: >=20 > Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) > 0xd25a59f0: at powrpc_dispatch_intr+0xc8 > 0xd25a5a20: at openpic_dispatch+0x90 > 0xd25a5a50: at powerpc_interrupt+0xc0 > 0xd25a5a80: at user EXI trap > by 0x181c68c (so: ssr0) > r1 =3D0xffffdb30 > cr =3D0x44020624 > xer=3D0 > ctr=3D0x41989570 >=20 > Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) > saved LR(0x4c) in invalid >=20 > Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) > saved LR(0x4c) in invalid _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat May 27 09:12:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69A03D84799 for ; Sat, 27 May 2017 09:12:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24F821747 for ; Sat, 27 May 2017 09:12:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26242 invoked from network); 27 May 2017 09:12:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 May 2017 09:12:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 05:12:56 -0400 (EDT) Received: (qmail 13951 invoked from network); 27 May 2017 09:12:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 09:12:55 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3F9D8EC7B46; Sat, 27 May 2017 02:12:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [patch now fixed] Date: Sat, 27 May 2017 02:12:54 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> <67C79408-0DDC-4A22-BFEC-6EC5DD80F076@dsl-only.net> To: Justin Hibbits , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: <67C79408-0DDC-4A22-BFEC-6EC5DD80F076@dsl-only.net> Message-Id: <9D70C580-C545-4EA0-AB76-FE757C1AF60A@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 09:12:58 -0000 [Testing shows the prior patch makes the PowerMac G5 so-called "Quad Core" hang very early.] I forgot to deal with the prepare side of things. So, now with both prepare and restore code fixes, this code boots. # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c = = Index: = /usr/src/sys/powerpc/ofw/ofw_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 317820) +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -111,26 +111,27 @@ * Assume that interrupt are disabled at this point, or * SPRG1-3 could be trashed */ -#ifdef __powerpc64__ - __asm __volatile("mtsprg1 %0\n\t" - "mtsprg2 %1\n\t" - "mtsprg3 %2\n\t" - : - : "r"(ofmsr[2]), - "r"(ofmsr[3]), - "r"(ofmsr[4])); -#else - __asm __volatile("mfsprg0 %0\n\t" - "mtsprg0 %1\n\t" - "mtsprg1 %2\n\t" - "mtsprg2 %3\n\t" - "mtsprg3 %4\n\t" - : "=3D&r"(ofw_sprg0_save) - : "r"(ofmsr[1]), - "r"(ofmsr[2]), - "r"(ofmsr[3]), - "r"(ofmsr[4])); +#ifndef __powerpc64__ + if (!(cpu_features & PPC_FEATURE_64)) + __asm __volatile("mfsprg0 %0\n\t" + "mtsprg0 %1\n\t" + "mtsprg1 %2\n\t" + "mtsprg2 %3\n\t" + "mtsprg3 %4\n\t" + : "=3D&r"(ofw_sprg0_save) + : "r"(ofmsr[1]), + "r"(ofmsr[2]), + "r"(ofmsr[3]), + "r"(ofmsr[4])); + else #endif + __asm __volatile("mtsprg1 %0\n\t" + "mtsprg2 %1\n\t" + "mtsprg3 %2\n\t" + : + : "r"(ofmsr[2]), + "r"(ofmsr[3]), + "r"(ofmsr[4])); } =20 static __inline void @@ -147,7 +148,8 @@ * PCPU data cannot be used until this routine is called ! */ #ifndef __powerpc64__ - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); + if (!(cpu_features & PPC_FEATURE_64)) + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); #endif } #endif =3D=3D=3D Mark Millard markmi at dsl-only.net [The original (better) panic evidence. . .] On 2017-May-26, at 10:29 PM, Mark Millard wrote: > [Additional information that does not need to > interlace with the prior material, so see > after. A somewhat better backtrace reported > by ddb. And so on.] >=20 >=20 > On 2017-May-26, at 7:14 PM, Mark Millard = wrote: >=20 >> I lucked out and got a vmcore.9 for a random >> panic that I could manage to backtrace for >> one of my test builds of -r317820. It appears >> that not all that much happened before it got >> the panic so much context was better preserved >> this time. >>=20 >> (I do not explore from ddb as I've had that >> panic and mess up the dump just made by >> replacing it. So this is a manual backtrace >> from the debug.minidump=3D0 style vmcore.9 >> file. objdump was used on the >> /boot/kernel/kernel to find code.) >>=20 >> Being able to see the problem is very >> sensitive to kernel memory layout. This >> is why I'm sticking with -r317820 built >> production style: the kind of context >> the problem was first observed in. >> Attempting a debug kernel build simply >> did not repeat the problem for days >> (vs. the usual hours for builds like >> this). >>=20 >>=20 >> So below is the backtrace: >>=20 >> (I do not show what trap_fatal calls: >> starting with trap_fatal and going toward >> larger memory addresses. . .) >>=20 >> [vmcore.9's >> offset >> in file >> when no >> 0x prefix] >>=20 >> 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| >> 0x008f3454 mr r3,r26 >> 0x008f3458 bl 008f2030 >> 0x008f345c b 008f34c8 >>=20 >> 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| >> * >> 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| >> 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| >> 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| >> 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | >> 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| >> 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| >> 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| >> 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| >> 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| >> 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| >> 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| >> 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| >> 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| >> 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| >> 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| >> 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| >> 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| >> 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >>=20 >> 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| >> 0x008e7d28 mfmsr r0 >> 0x008e7d2c or r0,r0,r9 >> 0x008e7d30 mtmsr r0 >> 0x008e7d34 isync >> 0x008e7d38 mr r3,r25 >> 0x008e7d3c bl 008f222c >> 0x008e7d40 lwz r11,0(r1) >>=20 >> 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| >> 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >>=20 >> r0 r1 >> 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| >> The struct trapframe starts is 0x 013e8588 in the >> vmcore.9 file. The 0x00108f8 is as shown below: >>=20 >> 0x001008ec isync >> 0x001008f0 addi r3,r1,8 >> 0x001008f4 bl 008e7ba4 >> 0x001008f8 mfmsr r3 >> 0x001008fc andi. r3,r3,32767 >>=20 >> 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| >> r2 r3 r4 r5 >>=20 >> 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| >> r6 r7 r8 r9 >>=20 >> 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| >> r10 r11 r12 r13 >>=20 >> 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| >> r14 r15 r16 r17 >>=20 >> 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| >> r18 r19 r20 r21 >>=20 >> 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| >> r22 r32 r24 r25 >>=20 >> 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| >> r26 r27 r28 r29 >>=20 >> 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| >> r30 r31 lr cr >>=20 >> xer ctr srr0 srr1 >> 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >> Note: objdump shows no code at 0x0090a030. 0x0090a030 is >> inside what objdump -x reports as the section .hash (Idx >> 2). >>=20 >> exc dar dsisr (booke dbcer0) >> 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| >> The 0x00007000 above is the framep->exc (exception code) >> (program in this case). >>=20 >> 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >>=20 >> At this point the above does not match the below >> part of the stack trace. >>=20 >> The lr part of struct trapframe was: 0x00535ad0 so >> showing around that: >>=20 >> 00535ab8 stwu r1,-32(r1) >> 00535abc mflr r0 >> 00535ac0 stw r29,20(r1) >> 00535ac4 stw r30,24(r1) >> 00535ac8 stw r31,28(r1) >> 00535acc stw r0,36(r1) >> 00535ad0 mr r31,r1 >> 00535ad4 mr r29,r3 >>=20 >> Back to the stack backtrace. . . >>=20 >> 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| >> 0x005359c8 bl 008ea420 >> 0x005359cc mr r3,r28 >> 0x005359d0 mr r4,r27 >> 0x005359d4 mr r5,r25 >> 0x005359d8 bl 005356ec >> 0x005359dc mfsprg r9,0 >>=20 >> I show around 0x005356ec >> from the sched_add+0x19c bl that is above >> because the routine is not referenced >> in the stack tracce but the above indicates >> that it should have been called: >> 0x005356ec stwu r1,-32(r1) >> 0x005356f0 mflr r0 >> 0x005356f4 stw r28,16(r1) >> 0x005356f8 stw r29,20(r1) >> 0x005356fc stw r30,24(r1) >> 0x00535700 stw r31,28(r1) >> 0x00535704 stw r0,36(r1) >> . . . >>=20 >> Back to the stack backtrace again. . . >>=20 >> 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| >> 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| >> 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >>=20 >> 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| >> 0x004a8780 mr r3,r28 >> 0x004a8784 li r4,4 >> 0x004a8788 bl 0053583c = >> 0x004a878c lwz r9,0(r28) >>=20 >> 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| >> 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >>=20 >> 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| >> 0x004a9700 bl 005000ec >> 0x004a9704 mr r3,r27 >> 0x004a9708 bl 004a86bc = >> 0x004a970c lwz r11,0(r1) >>=20 >> 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| >> 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| >> 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >>=20 >> 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| >> 0x00517960 lwz r3,264(r29) >> 0x00517964 li r4,0 >> 0x00517968 bl 004a965c >> 0x0051796c lwz r11,0(r1) >>=20 >> 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| >> 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| >> 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| >> 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >>=20 >> 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| >> 0x008ab264 mr r3,r27 >> 0x008ab268 mr r4,r28 >> 0x008ab26c bl 00517540 >> 0x008ab270 li r3,0 >>=20 >> 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| >> 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| >> 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| >> 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >>=20 >> 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| >> 0x008ad100 mr r3,r26 >> 0x008ad104 mr r4,r27 >> 0x008ad108 li r5,0 >> 0x008ad10c bl 008aafc0 >> 0x008ad110 lwz r11,0(r1) >>=20 >> 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| >> 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| >> 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| >> 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| >> 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| >> 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >>=20 >> 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| >> So 0x13e8820 from vmcore.9 has start of struct trapeframe. >> The 0x8e1e48 is from: >> 0x008e1e34 lwz r0,56(r28) >> 0x008e1e38 mtctr r0 >> 0x008e1e3c mr r3,r28 >> 0x008e1e40 lwz r4,64(r28) >> 0x008e1e44 bctrl >> 0x008e1e48 addi r29,r29,-1 >>=20 >> 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| >> 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| >> 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| >> 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| >> 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| >> 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| >> 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| >> 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| >> 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| >> 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| >> 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| >> 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >>=20 >> srr0 >> 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| >> The 0x00833c14 from the trap frame is the srr0 (conceptual lr): >> 0x008e3c04 stw r31,28(r1) >> 0x008e3c08 stw r0,36(r1) >> 0x008e3c0c mr r31,r1 >> 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = >> 0x008e3c14 mflr r30 >> 0x008e3c18 lwz r0,-32(r30) >>=20 >> 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >>=20 >> exc >> 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| >> The 0x00009000 above is the framep->exc (exception code) >> (decrementer in this case). >>=20 >> 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >>=20 >> 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| >> (trap [above] means no lr filled in here) >>=20 >> 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >>=20 >> 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| >> 0x008e318c bl 008ad8b8 >> 0x008e3190 lwz r29,0(r29) >> 0x008e3194 mtctr r29 >> 0x008e3198 bctrl >> 0x008e319c bl 008ad7b8 >>=20 >> 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >>=20 >> 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| >> 0x00536e78 bl 008e3144 >> 0x00536e7c stw r28,136(r27) >>=20 >>=20 >> 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| >> 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| >> 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| >> 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| >> 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| >> 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >>=20 >> 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| >> 0x004a3ca0 bl 008ea420 >> 0x004a3ca4 mr r3,r27 >> 0x004a3ca8 mr r4,r26 >> 0x004a3cac mtctr r25 >> 0x004a3cb0 bctrl >> 0x004a3cb4 lwz r0,108(r28) >>=20 >> 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| >> 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>=20 >> 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| >> 0x008f18c0 lwz r3,8(r1) >> 0x008f18c4 lwz r4,12(r1) >> 0x008f18c8 lwz r5,16(r1) >> 0x008f18cc bl 004a3bbc >> 0x008f18d0 addi r1,r1,16 >> 0x008f18d4 b 001008f8 >>=20 >>=20 >> So that is an example context for the failure. >>=20 >> It has taken weeks to get this. It may be some >> time before I get another for comparison/contrast. >>=20 >> And sticking with the same build vs. trying some more >> to find a better way to get more evidence is not >> obvious to me at this point. >=20 > I should have mentioned that this is > TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac > G5 "Quad Core". >=20 > I've had 2 more examples, with the same 0x0090a030 > srr0 and such (vmcore.0 and vmcore.1) (I have added > one more little block of code for detecting an earlier > problem symptom not being currently seen so the build > is slight different from the earlier report.) >=20 > Looking around in vmcore.0 I find 3 examples of > "00 90 a0 30" in areas overlapping with objdump -x's > coverage. . . >=20 > 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > [ ] >=20 > (from sorted objdump -x output:) > 00c775a8 l O .data 00000dc0 seqprog > 00c78368 l O .data 0000000c seeprom_long_ewen >=20 > [ ] > 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| > . . . > 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| > [ ] >=20 > (from sorted objdump -x output:) > 00f64780 g O .bss 00020000 __pcpu > 00f84780 l O .bss 00000004 ap_letgo >=20 >=20 > For vmcore.1 I went ahead and tried exploring > some with ddb --and had no new panics. . . > (Hand transcriptions of pictures) >=20 > fatal kernel trap: > exception =3D 0x700 (program) > srr0 =3D 0x90a030 > srr1 =3D 0x81032 > lr =3D 0x535ad0 > curthread =3D 0x147d6c0 > pic =3D 11, comm =3D idle: cpu0 >=20 > [ thread pid 11 tid 100003 ] > Stopped at _etext+0xb8fc: illegal instruction 0 > db> bt > 0xdf5e55d0: at sched_wakeup+0xa4 > 0xdf5e55f0: at setrunnable+0x9c > 0xdf5e5610: at sleepq_resume_thread+0x17c > 0xdf5e5640: at sleepq_timeout+0xc8 > 0xdf5e5680: at softclock_call_cc+0x1f0 > 0xdf5e56f0: at callout_process+0x27c > 0xdf5e57a0: at timercb+0x4c4 > 0xdf5e5820: at decr_intr+0xf0 > 0xdf5e5840: at powerpc_interrupt_0xf4 > 0xdf5e5870: at kernel DECR trap > by cpu_idle_60x+0x88 (so: srr0) > srr1=3D0x9032 > r1 =3D0xdf5e5930 > cr =3D0x40000042 > xer =3D0x20000000 > ctr =3D0x8e3bf8 > saved LR(0xfffffffd) is invalid. >=20 > db> show reg (but reformatted > r0 =3D0x4 > r1 =3D0xdf5e5590 > r2 =3D0x147d6c0 > r3 =3D0x54 testppc64size+0x34 > r4 =3D0x591d000 > r5 =3D0 > r6 =3D0 > r7 =3D0xf > r8 =3D0 > r9 =3D0xd4c03c cold > r10 =3D0x147d6c0 > r11 =3D0xdf5e55d0 > r12 =3D0 > r13 =3D0 > r14 =3D0xd4bdec sdt_probe_func > r15 =3D0xcb9898 std_lockstat___spin__release > r16 =3D0xd4c45c callwheelmask > r17 =3D0xd4c45c callwheelmask > r18 =3D0x55925 > r19 =3D0x559a4 > r20 =3D0x559 dsmisssize+0x469 > r21 =3D0x591d000 > r22 =3D0x566430 sleeppq_timeout > r23 =3D0x114 dsmisssize+0x24 > r24 =3D0 > r25 =3D0 > r26 =3D0x1 > r27 =3D0 > r28 =3D0xeba780 tdq_cpu > r29 =3D0x147d6c0 > r30 =3D0xd1caac > r31 =3D0xdf5e5590 > srr0 =3D0x90a030 > srr1 =3D0x81032 > lr =3D0x535ad0 shed_affinity+0x18 > ctr =3D0 > cr =3D0x20009034 > xer =3D0 > dar =3D0x419df5d4 > dsisr=3D0x24000000 > _etext+0xb8fc: illegal instruction 0 >=20 >=20 > Just for completeness: acttrace also showed: >=20 > Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) > 0xd25a59f0: at powrpc_dispatch_intr+0xc8 > 0xd25a5a20: at openpic_dispatch+0x90 > 0xd25a5a50: at powerpc_interrupt+0xc0 > 0xd25a5a80: at user EXI trap > by 0x181c68c (so: ssr0) > r1 =3D0xffffdb30 > cr =3D0x44020624 > xer=3D0 > ctr=3D0x41989570 >=20 > Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) > saved LR(0x4c) in invalid >=20 > Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) > saved LR(0x4c) in invalid From owner-freebsd-hackers@freebsd.org Sat May 27 11:03:16 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DD5AD8329A for ; Sat, 27 May 2017 11:03:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1722C19EF for ; Sat, 27 May 2017 11:03:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13283 invoked from network); 27 May 2017 11:03:14 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2017 11:03:14 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 07:03:14 -0400 (EDT) Received: (qmail 28060 invoked from network); 27 May 2017 11:03:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 11:03:14 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6DFA5EC8171; Sat, 27 May 2017 04:03:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [patch now fixed] Date: Sat, 27 May 2017 04:03:12 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> <62BF8E69-E7E6-4C4F-AB33-38B03E903CDA@dsl-only.net> <67C79408-0DDC-4A22-BFEC-6EC5DD80F076@dsl-only.net> <9D70C580-C545-4EA0-AB76-FE757C1AF60A@dsl-only.net> To: Justin Hibbits , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: <9D70C580-C545-4EA0-AB76-FE757C1AF60A@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 11:03:16 -0000 While the patch probably is still appropriate, testing has shown that it is not sufficient to prevent the periodic/random panics that I have been getting. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-May-27, at 2:12 AM, Mark Millard wrote: > [Testing shows the prior patch makes the PowerMac > G5 so-called "Quad Core" hang very early.] >=20 > I forgot to deal with the prepare side of things. > So, now with both prepare and restore code fixes, > this code boots. >=20 > # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c = = Index: = /usr/src/sys/powerpc/ofw/ofw_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 317820) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -111,26 +111,27 @@ > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > -#ifdef __powerpc64__ > - __asm __volatile("mtsprg1 %0\n\t" > - "mtsprg2 %1\n\t" > - "mtsprg3 %2\n\t" > - : > - : "r"(ofmsr[2]), > - "r"(ofmsr[3]), > - "r"(ofmsr[4])); > -#else > - __asm __volatile("mfsprg0 %0\n\t" > - "mtsprg0 %1\n\t" > - "mtsprg1 %2\n\t" > - "mtsprg2 %3\n\t" > - "mtsprg3 %4\n\t" > - : "=3D&r"(ofw_sprg0_save) > - : "r"(ofmsr[1]), > - "r"(ofmsr[2]), > - "r"(ofmsr[3]), > - "r"(ofmsr[4])); > +#ifndef __powerpc64__ > + if (!(cpu_features & PPC_FEATURE_64)) > + __asm __volatile("mfsprg0 %0\n\t" > + "mtsprg0 %1\n\t" > + "mtsprg1 %2\n\t" > + "mtsprg2 %3\n\t" > + "mtsprg3 %4\n\t" > + : "=3D&r"(ofw_sprg0_save) > + : "r"(ofmsr[1]), > + "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > + else > #endif > + __asm __volatile("mtsprg1 %0\n\t" > + "mtsprg2 %1\n\t" > + "mtsprg3 %2\n\t" > + : > + : "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > } >=20 > static __inline void > @@ -147,7 +148,8 @@ > * PCPU data cannot be used until this routine is called ! > */ > #ifndef __powerpc64__ > - __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > + if (!(cpu_features & PPC_FEATURE_64)) > + __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); > #endif > } > #endif From owner-freebsd-hackers@freebsd.org Sat May 27 11:40:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F38B6D845F0 for ; Sat, 27 May 2017 11:40:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9C2A1221 for ; Sat, 27 May 2017 11:40:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21737 invoked from network); 27 May 2017 11:40:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 May 2017 11:40:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 27 May 2017 07:40:41 -0400 (EDT) Received: (qmail 1586 invoked from network); 27 May 2017 11:40:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 May 2017 11:40:41 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 54AAFEC8171; Sat, 27 May 2017 04:40:40 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [compare reg values] Date: Sat, 27 May 2017 04:40:39 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> Message-Id: <83A22794-AD54-4D27-951A-986E6FA693DB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 11:40:43 -0000 [I compare a new panic's register values to prior panic's values.] On 2017-May-26, at 10:29 PM, Mark Millard wrote: > [Additional information that does not need to > interlace with the prior material, so see > after. A somewhat better backtrace reported > by ddb. And so on.] >=20 >=20 > On 2017-May-26, at 7:14 PM, Mark Millard = wrote: >=20 >> I lucked out and got a vmcore.9 for a random >> panic that I could manage to backtrace for >> one of my test builds of -r317820. It appears >> that not all that much happened before it got >> the panic so much context was better preserved >> this time. >>=20 >> (I do not explore from ddb as I've had that >> panic and mess up the dump just made by >> replacing it. So this is a manual backtrace >> from the debug.minidump=3D0 style vmcore.9 >> file. objdump was used on the >> /boot/kernel/kernel to find code.) >>=20 >> Being able to see the problem is very >> sensitive to kernel memory layout. This >> is why I'm sticking with -r317820 built >> production style: the kind of context >> the problem was first observed in. >> Attempting a debug kernel build simply >> did not repeat the problem for days >> (vs. the usual hours for builds like >> this). >>=20 >>=20 >> So below is the backtrace: >>=20 >> (I do not show what trap_fatal calls: >> starting with trap_fatal and going toward >> larger memory addresses. . .) >>=20 >> [vmcore.9's >> offset >> in file >> when no >> 0x prefix] >>=20 >> 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| >> 0x008f3454 mr r3,r26 >> 0x008f3458 bl 008f2030 >> 0x008f345c b 008f34c8 >>=20 >> 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| >> * >> 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| >> 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| >> 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| >> 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | >> 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| >> 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| >> 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| >> 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| >> 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| >> 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| >> 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| >> 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| >> 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| >> 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| >> 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| >> 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| >> 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| >> 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >>=20 >> 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| >> 0x008e7d28 mfmsr r0 >> 0x008e7d2c or r0,r0,r9 >> 0x008e7d30 mtmsr r0 >> 0x008e7d34 isync >> 0x008e7d38 mr r3,r25 >> 0x008e7d3c bl 008f222c >> 0x008e7d40 lwz r11,0(r1) >>=20 >> 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| >> 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >>=20 >> r0 r1 >> 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| >> The struct trapframe starts is 0x 013e8588 in the >> vmcore.9 file. The 0x00108f8 is as shown below: >>=20 >> 0x001008ec isync >> 0x001008f0 addi r3,r1,8 >> 0x001008f4 bl 008e7ba4 >> 0x001008f8 mfmsr r3 >> 0x001008fc andi. r3,r3,32767 >>=20 >> 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| >> r2 r3 r4 r5 >>=20 >> 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| >> r6 r7 r8 r9 >>=20 >> 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| >> r10 r11 r12 r13 >>=20 >> 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| >> r14 r15 r16 r17 >>=20 >> 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| >> r18 r19 r20 r21 >>=20 >> 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| >> r22 r32 r24 r25 >>=20 >> 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| >> r26 r27 r28 r29 >>=20 >> 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| >> r30 r31 lr cr >>=20 >> xer ctr srr0 srr1 >> 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >> Note: objdump shows no code at 0x0090a030. 0x0090a030 is >> inside what objdump -x reports as the section .hash (Idx >> 2). >>=20 >> exc dar dsisr (booke dbcer0) >> 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| >> The 0x00007000 above is the framep->exc (exception code) >> (program in this case). >>=20 >> 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >>=20 >> At this point the above does not match the below >> part of the stack trace. >>=20 >> The lr part of struct trapframe was: 0x00535ad0 so >> showing around that: >>=20 >> 00535ab8 stwu r1,-32(r1) >> 00535abc mflr r0 >> 00535ac0 stw r29,20(r1) >> 00535ac4 stw r30,24(r1) >> 00535ac8 stw r31,28(r1) >> 00535acc stw r0,36(r1) >> 00535ad0 mr r31,r1 >> 00535ad4 mr r29,r3 >>=20 >> Back to the stack backtrace. . . >>=20 >> 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| >> 0x005359c8 bl 008ea420 >> 0x005359cc mr r3,r28 >> 0x005359d0 mr r4,r27 >> 0x005359d4 mr r5,r25 >> 0x005359d8 bl 005356ec >> 0x005359dc mfsprg r9,0 >>=20 >> I show around 0x005356ec >> from the sched_add+0x19c bl that is above >> because the routine is not referenced >> in the stack tracce but the above indicates >> that it should have been called: >> 0x005356ec stwu r1,-32(r1) >> 0x005356f0 mflr r0 >> 0x005356f4 stw r28,16(r1) >> 0x005356f8 stw r29,20(r1) >> 0x005356fc stw r30,24(r1) >> 0x00535700 stw r31,28(r1) >> 0x00535704 stw r0,36(r1) >> . . . >>=20 >> Back to the stack backtrace again. . . >>=20 >> 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| >> 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| >> 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >>=20 >> 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| >> 0x004a8780 mr r3,r28 >> 0x004a8784 li r4,4 >> 0x004a8788 bl 0053583c = >> 0x004a878c lwz r9,0(r28) >>=20 >> 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| >> 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >>=20 >> 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| >> 0x004a9700 bl 005000ec >> 0x004a9704 mr r3,r27 >> 0x004a9708 bl 004a86bc = >> 0x004a970c lwz r11,0(r1) >>=20 >> 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| >> 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| >> 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >>=20 >> 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| >> 0x00517960 lwz r3,264(r29) >> 0x00517964 li r4,0 >> 0x00517968 bl 004a965c >> 0x0051796c lwz r11,0(r1) >>=20 >> 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| >> 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| >> 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| >> 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >>=20 >> 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| >> 0x008ab264 mr r3,r27 >> 0x008ab268 mr r4,r28 >> 0x008ab26c bl 00517540 >> 0x008ab270 li r3,0 >>=20 >> 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| >> 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| >> 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| >> 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >>=20 >> 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| >> 0x008ad100 mr r3,r26 >> 0x008ad104 mr r4,r27 >> 0x008ad108 li r5,0 >> 0x008ad10c bl 008aafc0 >> 0x008ad110 lwz r11,0(r1) >>=20 >> 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| >> 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| >> 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| >> 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >> 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| >> 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| >> 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >>=20 >> 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| >> So 0x13e8820 from vmcore.9 has start of struct trapeframe. >> The 0x8e1e48 is from: >> 0x008e1e34 lwz r0,56(r28) >> 0x008e1e38 mtctr r0 >> 0x008e1e3c mr r3,r28 >> 0x008e1e40 lwz r4,64(r28) >> 0x008e1e44 bctrl >> 0x008e1e48 addi r29,r29,-1 >>=20 >> 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| >> 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| >> 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| >> 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| >> 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| >> 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| >> 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| >> 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| >> 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| >> 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| >> 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| >> 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >>=20 >> srr0 >> 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| >> The 0x00833c14 from the trap frame is the srr0 (conceptual lr): >> 0x008e3c04 stw r31,28(r1) >> 0x008e3c08 stw r0,36(r1) >> 0x008e3c0c mr r31,r1 >> 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = >> 0x008e3c14 mflr r30 >> 0x008e3c18 lwz r0,-32(r30) >>=20 >> 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >>=20 >> exc >> 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| >> The 0x00009000 above is the framep->exc (exception code) >> (decrementer in this case). >>=20 >> 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >>=20 >> 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| >> (trap [above] means no lr filled in here) >>=20 >> 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >>=20 >> 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| >> 0x008e318c bl 008ad8b8 >> 0x008e3190 lwz r29,0(r29) >> 0x008e3194 mtctr r29 >> 0x008e3198 bctrl >> 0x008e319c bl 008ad7b8 >>=20 >> 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >>=20 >> 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| >> 0x00536e78 bl 008e3144 >> 0x00536e7c stw r28,136(r27) >>=20 >>=20 >> 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| >> 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| >> 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| >> 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >> 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| >> 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| >> 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >>=20 >> 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| >> 0x004a3ca0 bl 008ea420 >> 0x004a3ca4 mr r3,r27 >> 0x004a3ca8 mr r4,r26 >> 0x004a3cac mtctr r25 >> 0x004a3cb0 bctrl >> 0x004a3cb4 lwz r0,108(r28) >>=20 >> 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| >> 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>=20 >> 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| >> 0x008f18c0 lwz r3,8(r1) >> 0x008f18c4 lwz r4,12(r1) >> 0x008f18c8 lwz r5,16(r1) >> 0x008f18cc bl 004a3bbc >> 0x008f18d0 addi r1,r1,16 >> 0x008f18d4 b 001008f8 >>=20 >>=20 >> So that is an example context for the failure. >>=20 >> It has taken weeks to get this. It may be some >> time before I get another for comparison/contrast. >>=20 >> And sticking with the same build vs. trying some more >> to find a better way to get more evidence is not >> obvious to me at this point. >=20 > I should have mentioned that this is > TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac > G5 "Quad Core". >=20 > I've had 2 more examples, with the same 0x0090a030 > srr0 and such (vmcore.0 and vmcore.1) (I have added > one more little block of code for detecting an earlier > problem symptom not being currently seen so the build > is slight different from the earlier report.) >=20 > Looking around in vmcore.0 I find 3 examples of > "00 90 a0 30" in areas overlapping with objdump -x's > coverage. . . >=20 > 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| > [ ] >=20 > (from sorted objdump -x output:) > 00c775a8 l O .data 00000dc0 seqprog > 00c78368 l O .data 0000000c seeprom_long_ewen >=20 > [ ] > 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| > . . . > 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| > [ ] >=20 > (from sorted objdump -x output:) > 00f64780 g O .bss 00020000 __pcpu > 00f84780 l O .bss 00000004 ap_letgo Making some comparisons across two examples of the panic, prior vs. newest. . . The srr0 was different by 0x40: > For vmcore.1 I went ahead and tried exploring > some with ddb --and had no new panics. . . > (Hand transcriptions of pictures) >=20 > fatal kernel trap: > exception =3D 0x700 (program) > srr0 =3D 0x90a030 vs.=3D 0x90a070 > srr1 =3D 0x81032 > lr =3D 0x535ad0 > curthread =3D 0x147d6c0 > pic =3D 11, comm =3D idle: cpu0 >=20 > [ thread pid 11 tid 100003 ] > Stopped at _etext+0xb8fc: illegal instruction 0 > db> bt > 0xdf5e55d0: at sched_wakeup+0xa4 > 0xdf5e55f0: at setrunnable+0x9c > 0xdf5e5610: at sleepq_resume_thread+0x17c > 0xdf5e5640: at sleepq_timeout+0xc8 > 0xdf5e5680: at softclock_call_cc+0x1f0 > 0xdf5e56f0: at callout_process+0x27c > 0xdf5e57a0: at timercb+0x4c4 > 0xdf5e5820: at decr_intr+0xf0 > 0xdf5e5840: at powerpc_interrupt+0xf4 > 0xdf5e5870: at kernel DECR trap > by cpu_idle_60x+0x88 (so: srr0) > srr1=3D0x9032 > r1 =3D0xdf5e5930 > cr =3D0x40000042 > xer =3D0x20000000 > ctr =3D0x8e3bf8 > saved LR(0xfffffffd) is invalid. Below I show an alternate example values were they are different, where the patch that I attempted was also involved for the new figures. > db> show reg (but reformatted > r0 =3D0x4 > r1 =3D0xdf5e5590 > r2 =3D0x147d6c0 > r3 =3D0x54 testppc64size+0x34 vs.=3D0x78 dlmisssize+0x8 > r4 =3D0x591d000 vs.=3D0x5aa4360 > r5 =3D0 > r6 =3D0 > r7 =3D0xf > r8 =3D0 > r9 =3D0xd4c03c cold > r10 =3D0x147d6c0 > r11 =3D0xdf5e55d0 > r12 =3D0 > r13 =3D0 > r14 =3D0xd4bdec sdt_probe_func > r15 =3D0xcb9898 std_lockstat___spin__release > r16 =3D0xd4c45c callwheelmask > r17 =3D0xd4c45c callwheelmask > r18 =3D0x55925 vs.=3D0x15c267 fdt_property+0x113 > r19 =3D0x559a4 vs.=3D0x15c2e6 fdt_property+0x192 > r20 =3D0x559 dsmisssize+0x469 vs.=3D0x15c2 dsmisssize+0x14d2 > r21 =3D0x591d000 vs.=3D0x5aa4360 > r22 =3D0x566430 sleepq_timeout > r23 =3D0x114 dsmisssize+0x24 > r24 =3D0 > r25 =3D0 > r26 =3D0x1 > r27 =3D0 > r28 =3D0xeba780 tdq_cpu > r29 =3D0x147d6c0 > r30 =3D0xd1caac > r31 =3D0xdf5e5590 srr0 =3D0x90a030 _etext+0xb8fc vs.=3D0x90c070 _etext+0xb8fc > srr1 =3D0x81032 > lr =3D0x535ad0 shed_affinity+0x18 > ctr =3D0 > cr =3D0x20009034 vs.=3D0x20009044 > xer =3D0 > dar =3D0x419df5d4 vs.=3D0x41d276f4 > dsisr=3D0x24000000 vs.=3D0xa0000000 > _etext+0xb8fc: illegal instruction 0 >=20 >=20 > Just for completeness: acttrace also showed: >=20 > Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) > 0xd25a59f0: at powrpc_dispatch_intr+0xc8 > 0xd25a5a20: at openpic_dispatch+0x90 > 0xd25a5a50: at powerpc_interrupt+0xc0 > 0xd25a5a80: at user EXI trap > by 0x181c68c (so: ssr0) > r1 =3D0xffffdb30 > cr =3D0x44020624 > xer=3D0 > ctr=3D0x41989570 The newer example panic had CPU3 more like CPU 1 and 2 below. > Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) > saved LR(0x4c) in invalid >=20 > Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) > saved LR(0x4c) in invalid =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat May 27 17:14:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05F3FD84960 for ; Sat, 27 May 2017 17:14:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 BC92D1137 for ; Sat, 27 May 2017 17:14:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id l14so15608770ywk.1 for ; Sat, 27 May 2017 10:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=TL4re/6TgnKeaE+pnxErEtg1D5hINJcHKrOMYLXybW0=; b=EmCoGGizc1SF9mhtrzvYc+mbgpb0up0sAiirsYN7ueDRU7hQtRZS98VmBuJ2EfSQZc HZVncI3cE/gA1TSi12nJC5GLbPudhQmVSeUye0Z70J7A47+qSBkyJBfkilYhuF8jssXy s0cwvwYoAhEllzA8cxhUXQ9VQQGH5mFkvwoq5zPuEIgVNPUfG9ol6rr0UKTUupxhDsyw ojo14kgvNF/iUz3ADKDSkB7d1dysZaVNfh9GUKaGpHsaj3aoDPrl/5/u/zDX8pUfUrSH 0BMnmEpXjZVd9druZoOleSxgz4nQMWsISLH5dnmW4A0Y/ZoXptiDApafkzkYMrP1fVHW IvDA== 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:from:date:message-id:subject :to; bh=TL4re/6TgnKeaE+pnxErEtg1D5hINJcHKrOMYLXybW0=; b=BmtLZA4OLJNm9b/6LIdsPnsjNks0T+FQE1NANG9FC4W/iXe3y5U+n3fKULPXzoa5qh LBqa8IOanCr49FAYFTqodGZDWxZDD0mxJjaOZvPEIp2QNyZ7ZeUtVB9czvVvRwL0LPGe 7haqejgVrMCUdtE+IXgpsFGtC7B1qsDhRqR2TbfK96PilwAGyLDfA5rCd3iONgxB4tvp LySjAXMyxHzVH9H79sPEZN9c3OrX2ga2sMFPrRFNbd0Hv+OreJrVKu0ecTZX7OhtRmHM ydHInMwvc5bZIhtVvVCvXip39TQArRYbj+T/Ezio2bv9vClt6MOFZ5LZaaXBWF6ONrbs PVeA== X-Gm-Message-State: AODbwcDS291FseMvnu0SVueLfL2C4y+j8YEYW3gSkQAgmFDr7dAAuapC iLfnSwl8AWlnr8+tZVBuqZ42rf5zpM5n X-Received: by 10.13.235.13 with SMTP id u13mr4645878ywe.222.1495905266703; Sat, 27 May 2017 10:14:26 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.206.199 with HTTP; Sat, 27 May 2017 10:14:26 -0700 (PDT) From: Alan Somers Date: Sat, 27 May 2017 11:14:26 -0600 X-Google-Sender-Auth: sVbkqy4roI0e7IdDS0TLa2qZSio Message-ID: Subject: CFT: CI for GitHub on FreeBSD To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 17:14:28 -0000 I found it mildly frustrating that there was no hosted CI service for FreeBSD that worked with GitHub projects, so I made my own. You can see it in action here: https://github.com/asomers/mio-aio/pull/6 * https://162.213.36.222/buildbot/#/builders/2/builds/28 I'm using BuildBot running within an Iocage jail on a VPS. I want to automatically build pull requests as well as commits, so I have it configured to create a new jail for every build. That also allows me to use a shared worker for multiple projects. I think that this system could probably scale up to a few dozen projects on the same server. Eventually, navigating the UI will probably be the bottleneck. Awkwardly, I'm using Docker to manage the worker. That's because both BuildBot and GitLab have built-in support for Docker. It probably wouldn't be too hard to add Iocage support to BuildBot, but it would be impossible to do that for GitLab's hosted service. Unfortunately, the FreeBSD port of Docker has a few bugs, and I'm not sure where to report them. The repo at https://github.com/kvasdopil/docker looks unmaintained. Is anybody working on Docker for FreeBSD these days? As an alternative to BuildBot, I tried out GitLab. It's UI is superior to BuildBot's, because each project get its own UI and yet they can still share workers. However, I ultimately decided not to use GitLab because there's no free or cheap way to do automated OSX builds for it, and many of the projects I'm interested in support OSX as well. They've become addicted to Travis CI's free OSX builds and would be loath to give them up. The service is pretty much ready for beta testing at this point, as soon as I get a static IP and a DNS entry. What I need are a few small projects to test it out. What I'd like to have would be a more up-to-date Docker port. Any takers? -Alan * The IP is dynamic at this point, so the link may be dead if you're reading this in the archives