From owner-freebsd-current@freebsd.org Sun Oct 23 08:41:26 2016 Return-Path: Delivered-To: freebsd-current@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 2D390C1EC92 for ; Sun, 23 Oct 2016 08:41:26 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 B9C6230C; Sun, 23 Oct 2016 08:41:25 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id c78so60571242wme.1; Sun, 23 Oct 2016 01:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wr/LuBGVGk1nvdtmNTorraZ8sMKosx6mAS21JeJPOL4=; b=XsIrzCiIBHf9RpIuzHMkc7jpmFQ6mWo634mTkG172wWXaahwRA/seGPWJTGCRXVLwJ IY42rOQZiVzqYTuNXezD1udiPsAr+FfkbEH6b7sKXEOsdTaek+txxMKsMUy22jIUsRNa 5XXPZeDVpi8QuG2y0SFR2oxwj4YPwHOiRF8yfHV8HKWPRAf7kwksqjCAea+7HZG7AOW4 IqxXuiIXx2gEIpaj92BQMrmoH34X+PEbPAyiFj3NcXovnpCoyZfX8qcUtSg41yxraC9f xen+NkXSC1ZhG0lZPYvQqe0L37pUnAP6KmXzLdxua7idSDnoWysHpgHfr4tGIZEss5Hb 0IMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wr/LuBGVGk1nvdtmNTorraZ8sMKosx6mAS21JeJPOL4=; b=cUDVpcXpg5BMYWMwwQx6vOWsreul3/5huz0iux0qaNd3Cijgl3tV1kUbSXYi+wYlNo StjgqTKSkPzhgN7oTQKn7/rluCyF3VJleBEO+aj4C+APymXViecOuu5AKx55xVRElsZp 4OFaxdMj0KnUpNaM+TtWjK3qEBFMQwtCd+h6BowDE1+scP8K1mbT8oczBKeuMyD5nzWr XXY/cZbZO5lh35x+YOfppNiKEBSifkn6vMK1EWGLqlEEpAHYAoSCrD1e70U5UldZAbU7 wAbKRXVHS1NX2hbVCzJAoMtnZhb4Zif+bhY1UN62To1VMS6++XWga1Hh3DwGsnXMiUGq gUDA== X-Gm-Message-State: AA6/9RkMef+rP6Md27xUYPkDYEchclyGZVWY/9JktgIrHc5+UDn0q5280ZH+FFOB4b444ner/9NTnV0Vnc/LwA== X-Received: by 10.28.227.4 with SMTP id a4mr16824206wmh.84.1477212084155; Sun, 23 Oct 2016 01:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.24.21 with HTTP; Sun, 23 Oct 2016 01:41:23 -0700 (PDT) In-Reply-To: <20161022162311.d7ewekapcuiubuxh@ivaldir.etoilebsd.net> References: <20161022162311.d7ewekapcuiubuxh@ivaldir.etoilebsd.net> From: Guy Yur Date: Sun, 23 Oct 2016 11:41:23 +0300 Message-ID: Subject: Re: installworld fails on missing tzsetup when WITHOUT_DIALOG is set To: Baptiste Daroussin Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 08:41:26 -0000 On Sat, Oct 22, 2016 at 7:23 PM, Baptiste Daroussin wrote: > On Sat, Oct 22, 2016 at 06:51:28PM +0300, Guy Yur wrote: >> Hi, >> ... > > My proposal is a bit different: build tzsetup without dialog support :) > > https://reviews.freebsd.org/D8325 > > Best regards, > Bapt Thanks. Guy From owner-freebsd-current@freebsd.org Sun Oct 23 10:23:26 2016 Return-Path: Delivered-To: freebsd-current@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 E49D8C1B222 for ; Sun, 23 Oct 2016 10:23:26 +0000 (UTC) (envelope-from baptiste.daroussin@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 754F0877 for ; Sun, 23 Oct 2016 10:23:26 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id c78so63120676wme.1 for ; Sun, 23 Oct 2016 03:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Xk6XCSOtHfCLBHskGIdbqTGRAVT2amIqu94LxpoZObs=; b=xCSiylt83E8UwVZZQQvfZtrXDDDmlVFUXePFwPen486jZzOS0Q6vZLF88tF7wHTNvj BNy2u6zMXm5Ov7kMrTQSKtThUAXOzJv07DV2et8qfpS+ccA/ob8RD6ghRppoJueh3dvR 5jNAbYjVX12hGj0iJElekw0398SDVdujANTCy4/fttb8mY4Yq+DTnD7eOjzMAetRJbPR SWSAH6DnXR6/VCqZoVc6oaYz4R36qH36v4GmkMJvfL0o//zmJV/GTc2J3gweLbbN7tjp h07bGO2SMg/F7OFOk4g+IP7Yf5a0nWDHGRuP4BstTnjZP+ovKvD1OUvHQuQcko0FjqZe phkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Xk6XCSOtHfCLBHskGIdbqTGRAVT2amIqu94LxpoZObs=; b=HG5TFsiCnfI7YqvK9DWSTNk/WqiyvRgdZaBTQJV3jtLPDN3tO3rUo0W4tAmVKyFFV+ sSg+GAngSmIC5oF8Gz8lIIwIXCh04LFxgBaigv6tJ1glGTjT+QFl5FhWkXotvUXwJ1Df 7Xxr/u1Z7xH985AI6aApx2I1QOvaghEyHwiDU9twEpaNxPdKP4zeveW5NPDRyHumGDvy vEKrbwna9lQIV+hd7FUf832hBX23iVIKVaHDK+0yvhNPOuCT3UFRvV/T4PZMLjT9vj9v KAWwAaWKCthNz+W2s4Np0DxDDlzFQGZl2RXuIi1JnHJaTTAzRtHM8pu1/VwU60d/9/ou KpFQ== X-Gm-Message-State: ABUngvePPJNqSpyH79od1yXO2ZsQudcC1Par+VZZ0MzPFu274KKeVy0oc4QM0TblIX6f+Q== X-Received: by 10.194.200.162 with SMTP id jt2mr6980398wjc.172.1477218204887; Sun, 23 Oct 2016 03:23:24 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id s133sm8471833wmd.19.2016.10.23.03.23.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Oct 2016 03:23:23 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 23 Oct 2016 12:23:23 +0200 From: Baptiste Daroussin To: Guy Yur Cc: freebsd-current Subject: Re: installworld fails on missing tzsetup when WITHOUT_DIALOG is set Message-ID: <20161023102323.jeucmbxp4zufopat@ivaldir.etoilebsd.net> References: <20161022162311.d7ewekapcuiubuxh@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3lqn6givyebh43aa" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 10:23:27 -0000 --3lqn6givyebh43aa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2016 at 11:41:23AM +0300, Guy Yur wrote: > On Sat, Oct 22, 2016 at 7:23 PM, Baptiste Daroussin wr= ote: > > On Sat, Oct 22, 2016 at 06:51:28PM +0300, Guy Yur wrote: > >> Hi, > >> ... > > > > My proposal is a bit different: build tzsetup without dialog support :) > > > > https://reviews.freebsd.org/D8325 > > > > Best regards, > > Bapt >=20 > Thanks. FYI it is in Best regards, Bapt --3lqn6givyebh43aa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYDI+LAAoJEGOJi9zxtz5aMjkP/RFB6hsaO/aZaaB2gd2cq3jJ blo3/i2qEN1iDL15tfv6eKhH9EFUtu/zpiFM3EzUdzG99LQ2Kdxj+zouyFgeRY/N YeO0eQEw9mAHr+Ts5tPthmxZq2lL7h+Fe+041MiMbWTK8Ym7IKCV4+Q5nSm7sWHA FQ4Q9NWfjLdlPng093TmL6O7t8DIo3ihNr21fk34ZeA3THwLLPspnSweLsTx6tcs utJcj7+U0t1TSwFXC3uIVUBf3HgdimeSKe9MABRt1ATS6iNW3O1dbOWns9xPJeDm sUO4O5Z0VUTfcpluf1aWD3eA6n4QF6Fe3J4KwDKZEppMxyJuCSIscn+BLvVQiDgc ddnBZvQHyrTZjj2eNF2twyNYHYTJflqe+BUvQmGnETAXrla9lJSdYYCW6GfeG6Fe 7aqJTDLuE79UyjivQ83xmvb9BY0a1Ic2X3BdDKUt24ZfRpM7E/KRPN7kHzZV64v2 +1Ccz3YhBoCkwYEq2WiJl5oj8OwwkW/7EnQM5zUY1OiWfC6ldz38S2vdw4mOwjT0 l70AUkPNpzvddfyfZHq2C5RNeid6Cs4TtISpkfC3ScD8efx/sYkNHRArr56xalYK nBTsizGurvklLSPliZkqXyvENlQA9hICjSVhdayZZAQnCIUAkhjngdGDv3L2KiK7 GvzvPFaKiHszjRG1UnRA =tGr+ -----END PGP SIGNATURE----- --3lqn6givyebh43aa-- From owner-freebsd-current@freebsd.org Sun Oct 23 11:28:57 2016 Return-Path: Delivered-To: freebsd-current@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 6464EC1E593 for ; Sun, 23 Oct 2016 11:28:57 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 2AE2BB11 for ; Sun, 23 Oct 2016 11:28:56 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1byGuJ-0025FJ-N4>; Sun, 23 Oct 2016 13:25:39 +0200 Received: from x4e3481f4.dyn.telefonica.de ([78.52.129.244] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1byGuJ-000hRs-EC>; Sun, 23 Oct 2016 13:25:39 +0200 Date: Sun, 23 Oct 2016 13:25:38 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: CURRENT: re(4) crashing system Message-ID: <20161023132538.6bf55fb2@hermann> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 78.52.129.244 X-Mailman-Approved-At: Sun, 23 Oct 2016 11:32:50 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 11:28:57 -0000 I tried to report earlier here that CURRENT does have some serious problems right now and one of those problems seems to be triggered by the recent re(4) driver. The problem is also present in recen 11-STABLE! Below, you'll find pciconf-output reagrding the device on a Lenovo E540 Laptop I can test on and trigger the problem. The phenomenon is that this NIC does not negotiate 1000baseTX, it is always falling back to 100baseTX although the device claims to be a 1 GBit capable device. When I try to put the device manually into 1000basTX mode via ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) driver) it is possible to crash the system. The system also crashes when plugging/unplugging the LAN cord - I guess the renegotiation is triggering this crash immediately. I tried with several switches and routers capable of 1 GBit and it seems to be independent from the network hardware in use. I tried to capture a backtrace when the kernel crashes, but I do not know how to save the the kernel debugger output. Although I configured according the handbook debugging, there is no coredump at all. Advice is appreciated - if anybody is interesetd in solving this. Thank you very much in advance and kind regards, Oliver [...] re0@pci0:3:0:0: class=0x020000 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 64, base 0xf0d04000, size 4096, enabled bar [20] = type Memory, range 64, base 0xf0d00000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint MSI 1 max data 128(128) RO link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 01000000684ce000 ecap 0018[170] = LTR 1 ecap 001e[178] = unknown 1 From owner-freebsd-current@freebsd.org Sun Oct 23 16:24:45 2016 Return-Path: Delivered-To: freebsd-current@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 BF04BC1E76A for ; Sun, 23 Oct 2016 16:24:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 7F632A60 for ; Sun, 23 Oct 2016 16:24:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1byLZi-002rZI-Ez>; Sun, 23 Oct 2016 18:24:42 +0200 Received: from x4e3481f4.dyn.telefonica.de ([78.52.129.244] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1byLZi-0015Gi-2C>; Sun, 23 Oct 2016 18:24:42 +0200 Date: Sun, 23 Oct 2016 18:24:36 +0200 From: "O. Hartmann" To: freebsd-current Subject: was: CURRENT [r307305]: r307823 still crashing Message-ID: <20161023182436.4d3bac4f.ohartman@zedat.fu-berlin.de> In-Reply-To: <20161015121321.25007de8.ohartman@zedat.fu-berlin.de> References: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> <20161015121321.25007de8.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/R.u+dO9C5.vTo_05aRUiKoi"; protocol="application/pgp-signature" X-Originating-IP: 78.52.129.244 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 16:24:45 -0000 --Sig_/R.u+dO9C5.vTo_05aRUiKoi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 15 Oct 2016 12:13:21 +0200 "O. Hartmann" schrieb: > Am Sat, 15 Oct 2016 10:22:42 +0200 > "O. Hartmann" schrieb: >=20 > > Am Fri, 14 Oct 2016 10:48:33 +0200 > > "O. Hartmann" schrieb: > > =20 > > > Systems I updated to recent CURRENT start crashing spontaneously. > > >=20 > > > recent crashing system is on > > > 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r307305: Fri Oct 14 08:37:59 CE= ST 2016 > > >=20 > > > other (no access since it is remote and not accessible until later th= e day) has > > > been updated ~ 12 hours ago and it is alos rebooting/crashing without= any > > > warnings. Can be triggered on heavy load. > > >=20 > > > Only system with r307263 and stable so far is an older two-socket XEON > > > Core2Duao based machine, all crashing boxes have CPUs newer or equal = than > > > IvyBridge. > > >=20 > > > Does anyone also see these crashes? I tried to compile a debug kernel= on one > > > host, but that's the remote machine I have access to later, it failed= compiling > > > the kernel - under load it crashed often. After ZFS scrubbing kickied= in, it > > > vanished from the net ;-/ > > >=20 > > > kind regards, > > > oh > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" =20 > >=20 > > Still 307341 is crashing undpredicted ( FreeBSD 12.0-CURRENT #5 r307341= : Sat Oct 15 > > 09:36:16 CEST 2016). > >=20 > > I'm back to r307157, which seems to be "stable". > > =20 >=20 > Seems, I'm the only one at the moment having those problems :-( >=20 > I now have a laptop avalable and start putting debugging options into the= kernel. But > the laptop, so far, doesn't expose the problems of crashes described abo= ve. The laptop > is the only system so far without ZFS! >=20 > The most frequent crashing box is a CURRENT server with the largest ZFS v= olume. When on > most recent CURRENT (>r307157, see above), starting a scrubbing on a RAID= Z volume with ~ > 12 TB brutto size AND running a poudriere job, triggers the crash every 1= - 18 minutes. > Another box with only /home as ZFS volume on a dedicated hdd crashes afte= r minutes or > hours. A laptop, also CURRENT (now at r307349) without ZFS is working sta= ble as long as > I do not pull the LAN wire (a problem I described also in the list, I try= to capture the > screen when crashing right now). I spent now the last three days trying to figure out whether my custom conf= ig is faulty or CURRENT has a serious bug. Even with GENERIC and in single user mode (it= takes then longer) CURRENT, now at r307823, is crashing. The crashes seem to be unrel= ated to X11, but I can trigger this crash faster when using firefox. I also can trigger = it faster when doing a "svn update" on a ZFS pool containing /usr/ports. Everyone who uses= ZFS on /usr/src or /usr/ports and updates via subversion knows that over time t= he update process takes 10 - 15 minutes on ZFS volumes - compared to several minutes = on UFS. And while svn traverses the folder /usr/ports, the crash occurs. I'm still wondering about the fact nobody else is facing such a periodicall= y crashing. The crash is, I already reported this, with CURRENT on several boxes with o= r without ZFS. How can I track a memory leak? How can I write to disk the backtrace given by the debugger when crashing? = My box I can freely test is using the nVidia BLOB and vt(), so I can not see the backtra= ce. I got a very bad screenshot on one of my laptops, but its so ugly/unreadable, I thi= nk it is unsuable to be presented within this list at a reasonable size (200 kB max = ist too small). --Sig_/R.u+dO9C5.vTo_05aRUiKoi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYDOREAAoJEOgBcD7A/5N8MbsH/iN4jAEKYGvBd18wtjt4F7b1 8vCDVZ52bOICsp5d+1M1d+J1KZhdvh12Wr04ClBAOMuvkHRgDENaccZHrxruoEBQ rcjHBrfJgiwluMLdS0kmGM0bjjQo/+bTGj4nFrW1FNPcrQyPfyEw+Lko7BncX7sR vTWlup+li3kI1/J1NwImPYipl6y821vUjJNZ4bQVVBobtJ5rKxT64S6qg6Y8zV/C +3Cc66QV54T2AONhNdCWUfIcJ4TvAZPdJl4d3nCvTZv2mS8SpAXbWeQoPUKSSoyG ybOkIoCJ8GtjdH+/E8KA0MfZ60xPtQWBxImz3h/WIQ9dp3IYdW7J8+yGgpv5gCs= =B63N -----END PGP SIGNATURE----- --Sig_/R.u+dO9C5.vTo_05aRUiKoi-- From owner-freebsd-current@freebsd.org Sun Oct 23 19:24:13 2016 Return-Path: Delivered-To: freebsd-current@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 184D0C1EAFF for ; Sun, 23 Oct 2016 19:24:13 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.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 BEAF2363 for ; Sun, 23 Oct 2016 19:24:12 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-b57ff700000036e5-44-580d0d26d536 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 88.E6.14053.62D0D085; Sun, 23 Oct 2016 15:19:03 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u9NJJ1wS024376; Sun, 23 Oct 2016 15:19:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u9NJIw40010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Oct 2016 15:19:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u9NJIvOs003612; Sun, 23 Oct 2016 15:18:57 -0400 (EDT) Date: Sun, 23 Oct 2016 15:18:57 -0400 (EDT) From: Benjamin Kaduk To: "O. Hartmann" cc: freebsd-current Subject: Re: was: CURRENT [r307305]: r307823 still crashing In-Reply-To: <20161023182436.4d3bac4f.ohartman@zedat.fu-berlin.de> Message-ID: References: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> <20161015121321.25007de8.ohartman@zedat.fu-berlin.de> <20161023182436.4d3bac4f.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrqvOyxth8G8Cr8WcNx+YLP7O+sPk wOQx49N8Fo9T2w8yBjBFcdmkpOZklqUW6dslcGXsWvOUrWA1e8XnZQtZGhhvsXYxcnBICJhI 7FlZ3cXIxSEk0MYksXpKIwuEs5FRYmvvMSjnEJPEkUWf2CCcBkaJngVNTF2MnBwsAtoSJ77M Zgax2QRUJGa+2cgGYosI6EucazoNZjMLGEq8XHePHWSdsICNxIG7liBhTgEnieeTtoCN4RVw kFh98zzU/NeMEr1bvoLNFBXQkVi9fwoLRJGgxMmZT1ggZmpJLJ++jWUCo8AsJKlZSFILGJlW Mcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW6KWmlG5iBIUkpyTvDsZ/d70OMQpwMCrx8J64 xBMhxJpYVlyZe4hRkoNJSZT3qCx3hBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3hOcvBFCvCmJ lVWpRfkwKWkOFiVx3v9uX8OFBNITS1KzU1MLUotgsjIcHEoSvG48QI2CRanpqRVpmTklCGkm Dk6Q4TxAw19wgwwvLkjMLc5Mh8ifYtTlWPDj9lomIZa8/LxUKXHeKyBFAiBFGaV5cHPAqWQ3 k+orRnGgt4R5f4FU8QDTENykV0BLmICWCMbzgCwpSURISTUwxtT8eZobV1J5+mmij3Bw1cZv GavSZoVv/LPv1Rxe4aKjYZ+2FxderQjJnDyvPl36wr57HE2X30//rfTmkdGviAqDGQdm1mz5 ++7hGnG9LtZDcz2FpbVP717h1vTlSV6zwsVFBiefPLMrO50wQzCq2dCg5d6VSaXej/h5uvRq QjX2pUnkd/8RU2Ipzkg01GIuKk4EAA3/f74AAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 19:24:13 -0000 On Sun, 23 Oct 2016, O. Hartmann wrote: > How can I track a memory leak? I think I did not read enough of the context, but vmstat and top can track memory usage as a general thing. > How can I write to disk the backtrace given by the debugger when > crashing? My box I can freely test is using the nVidia BLOB and vt(), so > I can not see the backtrace. I got a very bad screenshot on one of my > laptops, but its so ugly/unreadable, I think it is unsuable to be > presented within this list at a reasonable size (200 kB max ist too > small). The backtrace should be part of the crash dump that is written to the (directly connected, non-encrypted, non-USB) swap device. "call doadump" at the debugger prompt (even typing blind) is supposed to make sure there's a dump taken. With respect to the screenshot, you should be able to post the image on an external site and send a link to the list, at least. -Ben From owner-freebsd-current@freebsd.org Mon Oct 24 05:14:05 2016 Return-Path: Delivered-To: freebsd-current@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 E3B35C1F5FF for ; Mon, 24 Oct 2016 05:14:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 ADAE1DAF for ; Mon, 24 Oct 2016 05:14:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 128so91659275pfz.0 for ; Sun, 23 Oct 2016 22:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vpA63WCk38xgLNFL7+hsmGBjjHeYsNkGYr35H9iq6uI=; b=jVbykxmEEdtkm+WlPBRWzaN0BGOwrJjM67bfM/calUA1pxhmtGDzg3Dd/Dw6zv3ZEl SHc+1/FbgqUHyvL2LiVUVvrqjCaqbyZzSMbzbBZZMrwl3gnsmP4LJafbFtAoeGjMOWZA Sd3rtsEzpdtwWBJnHeNPZ6hb7geQqXsU/i6wohuYXp4UDdSiT0HrCJhHX1QUf5T5ZMKu hsSDS06wkW1+XgeJx4cROIpfNhItJNfQWGgbxVSFc/ovQ/L5MWpZQmwf/Lu0B2qw8A+j yjh4Nuk7fFOFmxiJYSlHXNlzAxwdYdunEE0xB6LfjK/qv450eQc1kcr6CB3+XxTaZO9i u4tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=vpA63WCk38xgLNFL7+hsmGBjjHeYsNkGYr35H9iq6uI=; b=CRByclK0VW+yJgNEVbt5wo/feeWDE8ImJO6adR63ziKZtoq2CIMzl15nK4wuQxp11N fkFcATmNQyVguA0/+XlpEb/xmBLHXmcGo7fQWin/Jo3+wVsDcOT0SqRUNNMdcvKW1Hk0 C17VVDOK0CEsne8y2fTI2YBqxB+o/Lt89AC8RWsTDjkN0JIB7Krlm0oZzFwJwdyTdS9q bYvsXfm0dp2pjGx9WveHhWd+eF0ZOLHxIAsRRGJ4zAEAEPeCZNmket+XNJdDY0MbWqCD StpgDSV2yiA0Ud81OVEfZ6EykjRAe64USDLoeJbMamOPOc4+99ChftkYZh+CTeHZgGtn k+RQ== X-Gm-Message-State: ABUngvdK4fDygjQAleF+Ub0ZhJ7ZiAY1eRg2JThANK91PWFpyMGAVqDlbPr5ai/4hu08gQ== X-Received: by 10.99.163.1 with SMTP id s1mr21041466pge.126.1477286045283; Sun, 23 Oct 2016 22:14:05 -0700 (PDT) Received: from localhost ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id r194sm21248178pfr.94.2016.10.23.22.14.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Oct 2016 22:14:04 -0700 (PDT) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Mon, 24 Oct 2016 14:14:00 +0900 Date: Mon, 24 Oct 2016 14:14:00 +0900 To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161024051359.GA1185@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.com References: <20161023132538.6bf55fb2@hermann> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161023132538.6bf55fb2@hermann> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 05:14:06 -0000 On Sun, Oct 23, 2016 at 01:25:38PM +0200, Hartmann, O. wrote: > I tried to report earlier here that CURRENT does have some serious > problems right now and one of those problems seems to be triggered by > the recent re(4) driver. The problem is also present in recen 11-STABLE! > > Below, you'll find pciconf-output reagrding the device on a Lenovo E540 > Laptop I can test on and trigger the problem. > > The phenomenon is that this NIC does not negotiate 1000baseTX, it is > always falling back to 100baseTX although the device claims to be a 1 > GBit capable device. > > When I try to put the device manually into 1000basTX mode via > > ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) driver) > > it is possible to crash the system. The system also crashes when > plugging/unplugging the LAN cord - I guess the renegotiation is > triggering this crash immediately. > > I tried with several switches and routers capable of 1 GBit and it > seems to be independent from the network hardware in use. > > I tried to capture a backtrace when the kernel crashes, but I do not > know how to save the the kernel debugger output. Although I configured > according the handbook debugging, there is no coredump at all. > > Advice is appreciated - if anybody is interesetd in solving this. > There were several instability reports on re(4). I vaguely guess it would be related with some missing initializations for certain controllers. Unfortunately, there is no publicly available datasheet for those controllers and it's not likely to get access to it in near future. It seems vendor's FreeBSD driver accesses lots of magic registers as well as loading DSP fixups. I have no idea what it wants to do and re(4) used to heavily rely on power-on default register values. Engineering samples I have do not show instabilities so it wouldn't be easy to identify the issue. Probably the first step to address the issue would be identifying those chips and narrowing down the scope of guessing. Would you show me the dmesg output(re(4) and regphy(4) only)? pciconf(8) output is useless here since RealTek uses the same PCI id for PCIe variants. BTW, I was told that the vendor's FreeBSD driver seems to work fine for normal usage pattern. The vendor's driver triggered an instant panic and lacked H/W offloading features in the past. It might have changed though. From owner-freebsd-current@freebsd.org Mon Oct 24 12:03:51 2016 Return-Path: Delivered-To: freebsd-current@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 E8FCDC1FCB1 for ; Mon, 24 Oct 2016 12:03:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 AE20D9D6 for ; Mon, 24 Oct 2016 12:03:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bydyh-002ww8-BW>; Mon, 24 Oct 2016 14:03:43 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bydyh-002YtS-0w>; Mon, 24 Oct 2016 14:03:43 +0200 Date: Mon, 24 Oct 2016 14:03:37 +0200 From: "O. Hartmann" To: YongHyeon PYUN Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20161024051359.GA1185@michelle.fasterthan.co.kr> References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 12:03:52 -0000 On Mon, 24 Oct 2016 14:14:00 +0900 YongHyeon PYUN wrote: > On Sun, Oct 23, 2016 at 01:25:38PM +0200, Hartmann, O. wrote: > > I tried to report earlier here that CURRENT does have some serious > > problems right now and one of those problems seems to be triggered by > > the recent re(4) driver. The problem is also present in recen 11-STABLE! > > > > Below, you'll find pciconf-output reagrding the device on a Lenovo E540 > > Laptop I can test on and trigger the problem. > > > > The phenomenon is that this NIC does not negotiate 1000baseTX, it is > > always falling back to 100baseTX although the device claims to be a 1 > > GBit capable device. > > > > When I try to put the device manually into 1000basTX mode via > > > > ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) driver) > > > > it is possible to crash the system. The system also crashes when > > plugging/unplugging the LAN cord - I guess the renegotiation is > > triggering this crash immediately. > > > > I tried with several switches and routers capable of 1 GBit and it > > seems to be independent from the network hardware in use. > > > > I tried to capture a backtrace when the kernel crashes, but I do not > > know how to save the the kernel debugger output. Although I configured > > according the handbook debugging, there is no coredump at all. > > > > Advice is appreciated - if anybody is interesetd in solving this. > > > > There were several instability reports on re(4). I vaguely guess > it would be related with some missing initializations for certain > controllers. Unfortunately, there is no publicly available > datasheet for those controllers and it's not likely to get access > to it in near future. It seems vendor's FreeBSD driver accesses > lots of magic registers as well as loading DSP fixups. I have no > idea what it wants to do and re(4) used to heavily rely on power-on > default register values. Engineering samples I have do not show > instabilities so it wouldn't be easy to identify the issue. > > Probably the first step to address the issue would be identifying > those chips and narrowing down the scope of guessing. Would you > show me the dmesg output(re(4) and regphy(4) only)? pciconf(8) > output is useless here since RealTek uses the same PCI id for > PCIe variants. > > BTW, I was told that the vendor's FreeBSD driver seems to work fine > for normal usage pattern. The vendor's driver triggered an instant > panic and lacked H/W offloading features in the past. It might > have changed though. The problemacy with re(4) drivers arose again, when I bought some "green" equipment, mainly switches, which reduces power emission on short cables or non-connected ports. This brought down some servers with re(4) chipsets immediately and I had no clue what happend. I do not know whether this is a single fate so to speak, or this problem will arise for others, too. We exchanged on serving hardware all Realtek NICs with those from Intel, and luckily some server mainboards already have Intel PHY or NICs. The Broadcom devices we have on some older Fujitus hardware is also stable like a charme, even with the new power saving switches. While we can swap on server or workstation platforms the NIC, it is almost impossible on laptops and the number of laptops with realtek chips seems to grow. It is a pity that the venodr of the chipsets reject supporting other OSes than Windows - or in some rare cases only Linux. After you wrote the answer, I checked on the net who's suiatble drivers and the situation seems bad for almost all OSes apart from commercial ones like Windooze and Apple OS X. As soon as I get hands on the laptop again, I'll send the requested informations. I know that I played around with re(4) and rgephy(4) in the kernel, the rgephy(4) showed up on the dmesg, but I didn't see any effect - except that it offered some additional "media xxx-options-xxx" mostly appended with "flow" - but rying brought also down the system as pluggin or unplugging. The last kernel I compiled was then without rgephy(4) - the NIC worked as expected, but pluggin/unplugging or having some power-down activities on a Netgear SoHo green-pwer switch brings the system down as usual. From owner-freebsd-current@freebsd.org Mon Oct 24 17:43:31 2016 Return-Path: Delivered-To: freebsd-current@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 DBF4FC1F028 for ; Mon, 24 Oct 2016 17:43:31 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8561A2FA for ; Mon, 24 Oct 2016 17:43:31 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000:0:0:0:1]) by acme.spoerlein.net (8.15.2/8.15.2) with ESMTPS id u9OHhRnV032509 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Oct 2016 19:43:27 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Mon, 24 Oct 2016 19:43:27 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Kevin Oberman Cc: Hans Petter Selasky , FreeBSD Current Subject: Re: FreeBSD 11.x grinds to a halt after about 48h of uptime Message-ID: <20161024174327.GB2734@acme.spoerlein.net> Mail-Followup-To: Kevin Oberman , Hans Petter Selasky , FreeBSD Current References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:43:31 -0000 On Sat, 2016-10-15 at 09:36:27 -0700, Kevin Oberman wrote: > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > wrote: > > > On 10/15/16 18:18, Ulrich Spörlein wrote: > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine ever > >> since I upgraded it to 11-CURRENT years ago. I have no idea when this > >> started, actually, but what always happens is this: > >> > >> - System and X11 is up and running, I keep it running over night as I'm > >> too lazy to reboot and restart everthing. > >> - There's a bunch of xterms, Chrome, Clementine-Player and some other > >> programs running > >> - Coming back to the machine the next day (or the day after) it will > >> exit the screensaver just fine and then either I can use it for a couple > >> of seconds before it freezes, or it's pretty much dead already. The > >> mouse cursor still moves for a bit, but the also freezes (so it this a > >> GPU problem??) > >> > >> Now what I currently see on the screen is a clock widget stuck at 18:04 > >> but conky itself has last updated at 18:00:18 ... > >> > >> This time I had some SSH sessions from another machine to see some more > >> useful things. There was nothing in various logs under /var/log (I also > >> can't run dmesg anymore ...) > >> I had top(1) running in a loop, this is the last output: > >> > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 > >> 18:00:12 > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > >> > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > >> > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > >> COMMAND > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% > >> idle > >> 3122 uqs 15 28 0 7113M 5861M uwait 0 > >> 94:44 13.96% chrome > >> 2887 uqs 28 22 0 1394M 237M > >> select 2 172:53 6.98% chrome > >> 2890 uqs 11 21 0 > >> 1034M 178M select 5 231:21 1.95% chrome > >> 1062 root 9 > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > >> 3002 uqs > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% > >> chrome > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% > >> chrome > >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% > >> intr > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% > >> chrome > >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% > >> conky > >> 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% > >> systat > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% > >> chrome > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% > >> chrome > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% > >> chrome > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% > >> chrome > >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% > >> clementine-player > >> 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% > >> pagedaemon > >> > >> I also had systat -vm running and it continued to update its screen ... > >> for a short while, this is the last update before SSH died: > >> > >> > >> Mem usage: 0k%Phy 5%Kmem > >> Mem: KB REAL VIRTUAL VN PAGER SWAP > >> PAGER > >> Tot Share Tot Share Free in out in > >> out > >> Act 11051k 67868 71051992 255448 61840 count > >> All 11051k 67924 71058776 262100 pages > >> Proc: > >> Interrupts > >> r p d s w Csw Trp Sys Int Sof Flt ioflt 224 > >> total > >> 25 730 11 724 109 404 101 13 cow 2 > >> ehci0 16 > >> zfod 3 > >> ehci1 23 > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 > >> cpu0:timer > >> | | | | | | | | | | %ozfod > >> xhci0 264 > >> daefr 3 em0 > >> 265 > >> 50 dtbuf prcfr 94 > >> hdac1 266 > >> Namei Name-cache Dir-cache 349167 desvn totfr > >> ahci0 270 > >> Calls hits % hits % 349155 numvn react 5 > >> cpu1:timer > >> 121 121 100 253501 frevn pdwak 1 > >> cpu2:timer > >> pdpgs 29 > >> cpu7:timer > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 > >> cpu3:timer > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 > >> cpu6:timer > >> tps 0 0 0 0 0 0 9261404 act 12 > >> cpu5:timer > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 > >> cpu4:timer > >> %busy 0 0 0 0 0 0 cache > >> vgapci0 > >> 61840 free > >> 712304 buf > >> > >> > >> Why do I have a Chrome tab using about 6G? What other sort of debugging > >> output can be helpful to get to the bottom of this? The machine still > >> responds to pings just fine, TCP connections get set up but the SSH > >> handshake never completes. > >> > >> This always happens between 30-50h and is super annoying and has been > >> going on for >1year. Help? > >> > >> Note, I cut the power to the monitor overnight to save electricity, can > >> this mess up something in the Radeon card or X server? What combinations > >> would be most useful to try next? > >> > >> > > Hi, > > > > Sounds like a memory leak. Can you track the memory use over time? > > > > Did you look at the output from: > > > > vmstat -m ? > > > > --HPS > > > I have noted significant memory leakage in chromium for some time. If I > leave it running overnight, my system is essentially frozen. If I terminate > the chromium process, it slowly comes back to life. I always keep a gkrellm > session on-screen where the memory and swap utilization is continuously > displayed and that clearly shows resources declining. That is not what is happening to my system though, it actually deadlocks. There's no way to recover from it, it seems. So I killed Chromium overnight each day, and I'm at this: % top -Sbores last pid: 44526; load averages: 0.10, 0.11, 0.56 up 7+09:53:30 19:33:25 156 processes: 2 running, 153 sleeping, 1 waiting Mem: 315M Active, 550M Inact, 5671M Wired, 515M Buf, 9324M Free ARC: 1852M Total, 541M MFU, 196M MRU, 16K Anon, 93M Header, 1022M Other Swap: 4096M Total, 2186M Used, 1910M Free, 53% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2755 uqs 10 20 0 1697M 311M select 1 47:23 0.00% conky 2736 uqs 32 20 0 699M 116M select 7 94:29 0.00% clementine-player 3000 uqs 12 20 0 1126M 69380K select 5 9:48 0.00% digikam 960 root 9 20 0 448M 59076K select 0 250:22 0.00% Xorg 72608 uqs 8 20 0 939M 55432K uwait 5 0:01 0.00% chrome 72599 uqs 9 52 0 929M 55116K uwait 0 0:00 0.00% chrome 2567 root 1 20 0 89948K 42964K select 1 1:51 0.00% bsnmpd 70476 uqs 1 20 0 93656K 25712K select 2 0:05 0.00% xterm 2730 uqs 5 20 0 208M 14988K select 1 0:22 0.00% clock-applet 880 root 1 20 0 22628K 12500K select 3 0:20 0.00% ntpd 2726 uqs 4 20 0 206M 12456K select 6 0:09 0.00% mateweather-applet 44352 uqs 1 20 0 75224K 12348K select 4 0:00 0.00% xterm 43049 uqs 1 20 0 75224K 11792K select 5 0:00 0.00% xterm 3074 uqs 2 20 0 308M 9692K select 1 0:02 0.00% kdeinit4 2671 uqs 1 20 0 144M 9488K select 1 0:13 0.00% openbox 3072 uqs 1 20 0 210M 8284K select 3 0:00 0.00% kdeinit4 2724 uqs 4 20 0 154M 8256K select 2 0:19 0.00% wnck-applet 2701 uqs 5 20 0 177M 8144K select 2 0:01 0.00% mate-panel 7d running, pretty good. But look closer, the system is doing pretty much nothing but did swap out 2G. What? > Try closing your chromium at night and see if that fixes the problem. It's better, but I'm not sure it's a real fix. I've now turned off "hardware acceleration" in Chromium, though chrome://gpu didn't real inspire confidence that it was actually using any h/w accel at all. > If you have never tried gkrellm (sysutils/gkrellm2), it is a the best > system monitor I have found. though pulls in a lot of dependencies. It also > can run as a server with remote systems displaying the data. Handy to > monitor servers. I had a cacti-setup that would also monitor my workstation (through a OpenVPN tunnel), but that has bit-rotted and Apache only gives me 500s on that cacti URL and nothing in the logs, oh well ...) Hooking up a serial console and testing whether DDB works is probably the next best step to take ... Cheers, Uli From owner-freebsd-current@freebsd.org Mon Oct 24 18:58:45 2016 Return-Path: Delivered-To: freebsd-current@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 A15E2C1FD19 for ; Mon, 24 Oct 2016 18:58:45 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7314123B; Mon, 24 Oct 2016 18:58:45 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=201508; t=1477335523; bh=7leVxVI1v 4T2hokQPoUAcRNomZkvm8tuPRtMvF3S3/s=; b=AwKgw7HvXwR/AUu3wyk4hMRiR GlBgCXQzwFROfcQQJTOwtx32FhosHbvZpA6yHky8aJrt6EBlHzKJkWTYNlykXPxf 25iHiVA3drY3Kzdx5xX42dhAtf8ZBs9jfp+gJrDFqLEPM6zJM21DHBpdOlRhpncG tia7W7FEkP4vyTJCAA= Received: from toshi.auburn.protected-networks.net (gw.auburn.protected-networks.net [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id B479F211DA; Mon, 24 Oct 2016 14:58:43 -0400 (EDT) To: freebsd-current Cc: kib@freebsd.org From: Michael Butler Subject: SVN r307866 compilation problem Message-ID: Date: Mon, 24 Oct 2016 14:58:43 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 18:58:45 -0000 It seems that compilation of -current fails in the case that KDB is not defined. I'm assuming that the following diff achieves what was intended: imb@vm01:/usr/src/sys/x86/x86> svn diff Index: cpu_machdep.c =================================================================== --- cpu_machdep.c (revision 307875) +++ cpu_machdep.c (working copy) @@ -540,9 +540,9 @@ nmi_call_kdb(u_int cpu, u_int type, struct trapframe *frame, bool do_panic) { +#ifdef KDB /* machine/parity/power fail/"kitchen sink" faults */ if (isa_nmi(frame->tf_err) == 0) { -#ifdef KDB /* * NMI can be hooked up to a pushbutton for debugging. */ From owner-freebsd-current@freebsd.org Mon Oct 24 20:01:52 2016 Return-Path: Delivered-To: freebsd-current@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 E2804C2054E for ; Mon, 24 Oct 2016 20:01:52 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A89ADED for ; Mon, 24 Oct 2016 20:01:52 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bylRN-001ZZj-O8>; Mon, 24 Oct 2016 22:01:49 +0200 Received: from x55b232f1.dyn.telefonica.de ([85.178.50.241] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bylRN-003FEG-BV>; Mon, 24 Oct 2016 22:01:49 +0200 Date: Mon, 24 Oct 2016 22:01:48 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: r307877: buildkernel fails: x86/cpu_machdep.c:564:1: error: function definition is not allowed here { Message-ID: <20161024220148.6ce8b3c7@hermann> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.50.241 X-Mailman-Approved-At: Mon, 24 Oct 2016 20:17:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:01:53 -0000 r307877 fails to buildkernel with the error shown below: [...] /usr/src/sys/x86/x86/cpu_machdep.c:564:1: error: function definition is not allowed here { ^ /usr/src/sys/x86/x86/cpu_machdep.c:574:2: error: expected '}' } ^ /usr/src/sys/x86/x86/cpu_machdep.c:541:1: note: to match this '{' { ^ 2 errors generated. *** Error code 1 From owner-freebsd-current@freebsd.org Mon Oct 24 20:53:38 2016 Return-Path: Delivered-To: freebsd-current@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 82696C1FB68 for ; Mon, 24 Oct 2016 20:53:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04BF7E77 for ; Mon, 24 Oct 2016 20:53:37 +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 u9OKrWlA044868 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Oct 2016 23:53:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9OKrWlA044868 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9OKrUTU044867; Mon, 24 Oct 2016 23:53:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 24 Oct 2016 23:53:30 +0300 From: Konstantin Belousov To: Michael Butler Cc: freebsd-current Subject: Re: SVN r307866 compilation problem Message-ID: <20161024205330.GD54029@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.7.1 (2016-10-04) 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-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:53:38 -0000 On Mon, Oct 24, 2016 at 02:58:43PM -0400, Michael Butler wrote: > It seems that compilation of -current fails in the case that KDB is not > defined. > > I'm assuming that the following diff achieves what was intended: > > imb@vm01:/usr/src/sys/x86/x86> svn diff > Index: cpu_machdep.c > =================================================================== > --- cpu_machdep.c (revision 307875) > +++ cpu_machdep.c (working copy) > @@ -540,9 +540,9 @@ > nmi_call_kdb(u_int cpu, u_int type, struct trapframe *frame, bool > do_panic) > { > > +#ifdef KDB > /* machine/parity/power fail/"kitchen sink" faults */ > if (isa_nmi(frame->tf_err) == 0) { > -#ifdef KDB > /* > * NMI can be hooked up to a pushbutton for debugging. > */ Um, no. isa_nmi() should be checked and panic avoided regardless of the panic_on_nmi setting, if no hw error was reported. It is #endif that was misplaced. This and another change, are committed as r307880. Thank you for the report. From owner-freebsd-current@freebsd.org Mon Oct 24 20:54:12 2016 Return-Path: Delivered-To: freebsd-current@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 59AA5C1FCA1 for ; Mon, 24 Oct 2016 20:54:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7FBC20C for ; Mon, 24 Oct 2016 20:54: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 u9OKs7Dm044882 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Oct 2016 23:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9OKs7Dm044882 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9OKs7nl044881; Mon, 24 Oct 2016 23:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 24 Oct 2016 23:54:07 +0300 From: Konstantin Belousov To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: r307877: buildkernel fails: x86/cpu_machdep.c:564:1: error: function definition is not allowed here { Message-ID: <20161024205407.GE54029@kib.kiev.ua> References: <20161024220148.6ce8b3c7@hermann> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024220148.6ce8b3c7@hermann> User-Agent: Mutt/1.7.1 (2016-10-04) 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-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:54:12 -0000 On Mon, Oct 24, 2016 at 10:01:48PM +0200, Hartmann, O. wrote: > r307877 fails to buildkernel with the error shown below: > > [...] > /usr/src/sys/x86/x86/cpu_machdep.c:564:1: error: function definition is > not allowed here { > ^ > /usr/src/sys/x86/x86/cpu_machdep.c:574:2: error: expected '}' > } > ^ > /usr/src/sys/x86/x86/cpu_machdep.c:541:1: note: to match this '{' > { > ^ > 2 errors generated. Should be fixed in r307880. Thank you for the report. From owner-freebsd-current@freebsd.org Tue Oct 25 01:13:20 2016 Return-Path: Delivered-To: freebsd-current@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 CDD86C1F658 for ; Tue, 25 Oct 2016 01:13:20 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 8FB2F381 for ; Tue, 25 Oct 2016 01:13:20 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-qk0-x230.google.com with SMTP id x11so42634557qka.1 for ; Mon, 24 Oct 2016 18:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=jYLP6Z7Wjw+aqR4j90DIa36dLLcqiSmdTXi8Mgv1NR4=; b=Wn019Dob14tYgKsYi+5x2NhqPJy84Az3lTjjfDckKheWmdgJPz9z5ZdPUm64yZp80G CEmo1s/jWDLebwyyxUZkkNrDWoGfmtxJi/8iAx6ZNIWzW2DCwEg5q9R3+OuuwfHb4Mb3 6Cf5JZ6gA+sOR6KIB12IMn2l50+6tdLExNYy/yuV96vReG9W8ZEsFxDSyA08TEJkB/Pc Z9ews54UKSUShh+aj8qvLkgNCAv7mXkPznXI0Z1rcIigwyauH5mzodk4uhK+wlzi6qb6 sUo+ZEhwmunxY3pFKsEzsnsExsJx+lj8g9nYynMEkPpibWYInqA2fGqWKPuFxxWGSqVW W76Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jYLP6Z7Wjw+aqR4j90DIa36dLLcqiSmdTXi8Mgv1NR4=; b=gQ4JkJLvLdrybqOCDW0MOhK7ZSleSXhM9ufuqdu+EDIR+J7AtiN5rE+Mj0q+exBqo3 BkLoIWOSiJ9uhv/Br+1xC8VqcyOx4dxdvfik+eOS2kXJBv/5FP8FvKcmQeYPJ7au/8uJ E0NPMZdEKYr2qWQ2Lux46BRM+QSUDdmTLBsxJXFZj+qBqayPvr2iQrKlR9uz1iUvz+U4 uHZRbPAPVc6kn2GMZXCAUglA1vr+Nkntof45Is7WYcwUme1h7kpxeRtmwkni2ZvSv8qP Ib212YgwBZfE81qJak4J2ATZLtlU+0/pg/xyjMgroN2gCTZ4BJYkW+Iuv8pGr3Ys36L9 9I0w== X-Gm-Message-State: ABUngveRThqepvpzUJhqs0/dZTstPVVjUTft23tmQZD3ItmgXMpQaN/ooYGSseb/9/HAJ3qbmLUgILiGWAZwNkBKTcYBBWTl4YBOT9E0lxusm6EGaiwNz3Ej8oWyyWbcBBMYdlXZG9A8SSD7mob78q/Qzw4= X-Received: by 10.55.71.15 with SMTP id u15mr5043888qka.144.1477357999500; Mon, 24 Oct 2016 18:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.173 with HTTP; Mon, 24 Oct 2016 18:13:04 -0700 (PDT) From: "Lundberg, Johannes" Date: Tue, 25 Oct 2016 10:13:04 +0900 Message-ID: Subject: WRITE_FPDMA_QUEUED error when installing on MBP 2014 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 01:13:20 -0000 SGkgQWxsDQoNCkkgcmVhZCB0aGF0IHBlb3BsZSBzdWNjZXNzZnVsbHkgaW5zdGFsbGVkIEZyZWVC U0Qgb24gMjAxNCdzIE1hY0Jvb2sgUHJvcy4NCg0KSSBqdXN0IGdvdCBhIHVzZWQgbWFjaGluZSAo aW4gZXhjZWxsZW50IHNoYXBlKSBhbmQgdHJ5IHRvIGluc3RhbGwgRnJlZUJTRA0KY3VycmVudCBm cm9tIFVTQiBtZW1vcnkgYmVzaWRlcyBPU1ggYW5kIExpbnV4Lg0KDQpFdmVyeSB0aW1lIHVucGFj a2luZyBmYWlscyB3aXRoIFdSSVRFX0ZQRE1BX1FVRVVFRCB0aW1lb3V0IGVycm9yLg0KDQpJJ20g d29ycmllZCB0aGF0IHRoZSBTU0QgY2FuIGJlIGRhbWFnZWQgc28gSSBsaWtlZCB0byBjb25maXJt IGlmIGFueW9uZQ0Ka25vd3MgaWYgdGhlcmUgaXMgYW55IGtub3duIGlzc3VlcyBsaWtlIHRoaXM/ IFRoZSBlcnJvciBpcyByZXBvcnRlZCBmb3IgYWRhDQphbmQgbm90IGRhIGJ1dCBjb3VsZCBpdCBi ZSBhIHNvdXJjZSBlcnJvciAoVVNCIG1lbW9yeSwgZG93bmxvYWRlZCBtZW1zdGljaw0KaW1hZ2Up Pw0KDQpBICdkZCBpZj0vZGV2L3NkYSBvZj0vZGV2L251bGwnIHNob3cgbm8gZXJyb3Igb24gTGlu dXguIFdpbGwgdHJ5IEZyZWVCU0QNCm5leHQuDQoNCkdyYXRlZnVsIGZvciBhbnkgZmVlZGJhY2su DQoNClRoYW5rcyENCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+WtkOOD oeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOAgeen mOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOBmeOA ggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjj gIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavp lqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu 5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM 5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCCi0t LQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMg Y29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVzZSBv ZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMg cHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3JpZ2lu YWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Tue Oct 25 02:05:45 2016 Return-Path: Delivered-To: freebsd-current@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 2312EC1EED4 for ; Tue, 25 Oct 2016 02:05:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 F1A231CD for ; Tue, 25 Oct 2016 02:05:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf0-x231.google.com with SMTP id 128so109423624pfz.0 for ; Mon, 24 Oct 2016 19:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=FHzkiSkFQaacx/n1GnMg4EcghWN95BhLKYqzUocIbBA=; b=Zw03Hm4+CHdlED17xCbjiY6cRHBLRnhtM4LiroDk5RkwmD1pmRKEDolcv8rp/CqhbT tvC569mSGlaMILIY5GIUQ947i3jcECc/THq0rdJv1vEZzcpL3Sz7ivIo8QUgfJO6GT3s wKJUuhZDo+KXVfRTt+FNi3zo26dhAQOAWiSsiq7Gkvp2kC7APJCSXNCsSSBzWyuyYkAZ owk/u4rEgn/JylH/4PY+wD9pSoS1JELrXPJagYeu5tY6XpCxxKEO4A688abXtccuik5D RdIpQec8nnK+cJKUAibTduBX5zhQUjLA8XvC/5Oomxlfw8kpKInaHGpvYvICoAyw20Pk LTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=FHzkiSkFQaacx/n1GnMg4EcghWN95BhLKYqzUocIbBA=; b=R4EPcxbkViwMB2BNoMs8Cd4UPQhCsmpoJT+G1akOaJ5GT8aRTihIHGFkqmaia+Jw6u VJ9RgNwYHSpK6/BrC/kZJvMbFjrCiH/VAoDF7luiUpCdevAlwgcG+DEEUODnU7aBSA7y kkBmmRlMJ88ZjPEn91JM9rlXxU5cr0K2EzHYLQKd52OtQ9i8h8725t+pY5otRa2LJ9a5 CJoPBH4r1shADei4KXfHLw39on+x6zf3jR2BOvojsBQpLiBNNxSRXZNoS83PkymUbxtZ Am0tImZJN/teXiyEFwajCS47lYT7owYezR69qhrOGg3sw7Na1ck9tzZcyt1YMqNxbMO4 zIqA== X-Gm-Message-State: ABUngvf/DwjkZDUj0ksxhrx3J7ILxy+Qw+G8cocz/ZWhhQNGHtv2gOMftVCY/lu4e0NeFw== X-Received: by 10.98.194.68 with SMTP id l65mr34958161pfg.159.1477361144271; Mon, 24 Oct 2016 19:05:44 -0700 (PDT) Received: from localhost ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id x1sm28291735pax.7.2016.10.24.19.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 19:05:43 -0700 (PDT) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Tue, 25 Oct 2016 11:05:38 +0900 Date: Tue, 25 Oct 2016 11:05:38 +0900 To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161025020538.GA1238@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.com References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 02:05:45 -0000 On Mon, Oct 24, 2016 at 02:03:37PM +0200, O. Hartmann wrote: > On Mon, 24 Oct 2016 14:14:00 +0900 > YongHyeon PYUN wrote: > > > On Sun, Oct 23, 2016 at 01:25:38PM +0200, Hartmann, O. wrote: > > > I tried to report earlier here that CURRENT does have some serious > > > problems right now and one of those problems seems to be triggered by > > > the recent re(4) driver. The problem is also present in recen 11-STABLE! > > > > > > Below, you'll find pciconf-output reagrding the device on a Lenovo E540 > > > Laptop I can test on and trigger the problem. > > > > > > The phenomenon is that this NIC does not negotiate 1000baseTX, it is > > > always falling back to 100baseTX although the device claims to be a 1 > > > GBit capable device. > > > > > > When I try to put the device manually into 1000basTX mode via > > > > > > ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) driver) > > > > > > it is possible to crash the system. The system also crashes when > > > plugging/unplugging the LAN cord - I guess the renegotiation is > > > triggering this crash immediately. > > > > > > I tried with several switches and routers capable of 1 GBit and it > > > seems to be independent from the network hardware in use. > > > > > > I tried to capture a backtrace when the kernel crashes, but I do not > > > know how to save the the kernel debugger output. Although I configured > > > according the handbook debugging, there is no coredump at all. > > > > > > Advice is appreciated - if anybody is interesetd in solving this. > > > > > > > There were several instability reports on re(4). I vaguely guess > > it would be related with some missing initializations for certain > > controllers. Unfortunately, there is no publicly available > > datasheet for those controllers and it's not likely to get access > > to it in near future. It seems vendor's FreeBSD driver accesses > > lots of magic registers as well as loading DSP fixups. I have no > > idea what it wants to do and re(4) used to heavily rely on power-on > > default register values. Engineering samples I have do not show > > instabilities so it wouldn't be easy to identify the issue. > > > > Probably the first step to address the issue would be identifying > > those chips and narrowing down the scope of guessing. Would you > > show me the dmesg output(re(4) and regphy(4) only)? pciconf(8) > > output is useless here since RealTek uses the same PCI id for > > PCIe variants. > > > > BTW, I was told that the vendor's FreeBSD driver seems to work fine > > for normal usage pattern. The vendor's driver triggered an instant > > panic and lacked H/W offloading features in the past. It might > > have changed though. > > The problemacy with re(4) drivers arose again, when I bought some "green" > equipment, mainly switches, which reduces power emission on short cables or > non-connected ports. This brought down some servers with re(4) chipsets > immediately and I had no clue what happend. I do not know whether this is a I'm not sure but it's likely the issue is related with EEE/Green Ethernet handling. EEE is negotiated feature with link partner. If you directly connect your laptop to non-EEE capable link partner like other re(4) box without switches you may be able to tell whether the issue is EEE/Green Ethernet related one or not. > single fate so to speak, or this problem will arise for others, too. We > exchanged on serving hardware all Realtek NICs with those from Intel, and > luckily some server mainboards already have Intel PHY or NICs. The Broadcom > devices we have on some older Fujitus hardware is also stable like a charme, > even with the new power saving switches. > bge(4) also lacks EEE support(Publicly available datasheet is too sanitized one). bge(4) firmware probably does not announce EEE capability by default in link establishment while recent re(4) devices seem to unconditionally announce EEE. Generally EEE handling requires a kind of handshake for link state change from MAC/PHY. > While we can swap on server or workstation platforms the NIC, it is almost > impossible on laptops and the number of laptops with realtek chips seems to > grow. It is a pity that the venodr of the chipsets reject supporting other OSes > than Windows - or in some rare cases only Linux. After you wrote the answer, I > checked on the net who's suiatble drivers and the situation seems bad for > almost all OSes apart from commercial ones like Windooze and Apple OS X. > > As soon as I get hands on the laptop again, I'll send the requested > informations. I know that I played around with re(4) and rgephy(4) in the > kernel, the rgephy(4) showed up on the dmesg, but I didn't see any effect - > except that it offered some additional "media xxx-options-xxx" mostly appended > with "flow" - but rying brought also down the system as pluggin or unplugging. rgephy(4) will show recognized PHY H/W model. Another information I'd like to know is OUI information of the PHY. The OUI information could be get with `devinfo -rv | grep rgephy`. The "flow" output of media indicates it negotiated ethernet flow-control with link partner. rgephy(4) used to announce autonegotiation even when manual setting is requested with ifconfig. It was to workaround HW issues seen in the past. You can disable the use of autonegotiation in manual media selection with flag0 option. See rgephy(4) for more information. Not sure whether that option helps though. > The last kernel I compiled was then without rgephy(4) - the NIC worked as > expected, but pluggin/unplugging or having some power-down activities on a > Netgear SoHo green-pwer switch brings the system down as usual. If you use re(4) without rgephy(4) it will use ukphy(4) which is completely dumb on link state detection of re(4) controller. Link state detection requires non-PHY register access on re(4) so using ukphy(4) is not recommended. From owner-freebsd-current@freebsd.org Tue Oct 25 05:03:42 2016 Return-Path: Delivered-To: freebsd-current@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 4AEFCC20B55 for ; Tue, 25 Oct 2016 05:03:42 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 E8078CFF for ; Tue, 25 Oct 2016 05:03:41 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1byttj-003Ayo-L9>; Tue, 25 Oct 2016 07:03:39 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1byttj-003oPT-CD>; Tue, 25 Oct 2016 07:03:39 +0200 Date: Tue, 25 Oct 2016 07:03:38 +0200 From: "Hartmann, O." To: YongHyeon PYUN Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161025070338.76ad6711@hermann> In-Reply-To: <20161025020538.GA1238@michelle.fasterthan.co.kr> References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 05:03:42 -0000 On Tue, 25 Oct 2016 11:05:38 +0900 YongHyeon PYUN wrote: > On Mon, Oct 24, 2016 at 02:03:37PM +0200, O. Hartmann wrote: > > On Mon, 24 Oct 2016 14:14:00 +0900 > > YongHyeon PYUN wrote: > > > > > On Sun, Oct 23, 2016 at 01:25:38PM +0200, Hartmann, O. wrote: > > > > I tried to report earlier here that CURRENT does have some > > > > serious problems right now and one of those problems seems to > > > > be triggered by the recent re(4) driver. The problem is also > > > > present in recen 11-STABLE! > > > > > > > > Below, you'll find pciconf-output reagrding the device on a > > > > Lenovo E540 Laptop I can test on and trigger the problem. > > > > > > > > The phenomenon is that this NIC does not negotiate 1000baseTX, > > > > it is always falling back to 100baseTX although the device > > > > claims to be a 1 GBit capable device. > > > > > > > > When I try to put the device manually into 1000basTX mode via > > > > > > > > ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) > > > > driver) > > > > > > > > it is possible to crash the system. The system also crashes when > > > > plugging/unplugging the LAN cord - I guess the renegotiation is > > > > triggering this crash immediately. > > > > > > > > I tried with several switches and routers capable of 1 GBit and > > > > it seems to be independent from the network hardware in use. > > > > > > > > I tried to capture a backtrace when the kernel crashes, but I > > > > do not know how to save the the kernel debugger output. > > > > Although I configured according the handbook debugging, there > > > > is no coredump at all. > > > > > > > > Advice is appreciated - if anybody is interesetd in solving > > > > this. > > > > > > There were several instability reports on re(4). I vaguely guess > > > it would be related with some missing initializations for certain > > > controllers. Unfortunately, there is no publicly available > > > datasheet for those controllers and it's not likely to get access > > > to it in near future. It seems vendor's FreeBSD driver accesses > > > lots of magic registers as well as loading DSP fixups. I have no > > > idea what it wants to do and re(4) used to heavily rely on > > > power-on default register values. Engineering samples I have do > > > not show instabilities so it wouldn't be easy to identify the > > > issue. > > > > > > Probably the first step to address the issue would be identifying > > > those chips and narrowing down the scope of guessing. Would you > > > show me the dmesg output(re(4) and regphy(4) only)? pciconf(8) > > > output is useless here since RealTek uses the same PCI id for > > > PCIe variants. > > > > > > BTW, I was told that the vendor's FreeBSD driver seems to work > > > fine for normal usage pattern. The vendor's driver triggered an > > > instant panic and lacked H/W offloading features in the past. It > > > might have changed though. > > > > The problemacy with re(4) drivers arose again, when I bought some > > "green" equipment, mainly switches, which reduces power emission on > > short cables or non-connected ports. This brought down some servers > > with re(4) chipsets immediately and I had no clue what happend. I > > do not know whether this is a > > I'm not sure but it's likely the issue is related with EEE/Green > Ethernet handling. EEE is negotiated feature with link partner. If > you directly connect your laptop to non-EEE capable link partner > like other re(4) box without switches you may be able to tell > whether the issue is EEE/Green Ethernet related one or not. Me either since when I discovered a problem the first time with CURRENT, that was the Friday before last week's Friday, there was a unlucky coicidence: I got the new switch, FreeBSD introduced a serious bug and I changed the NICs. The laptop, the last in the row of re(4) equipted systems on which I use the Realtek NIC, does well now with Green IT technology, but crashes on plugging/unplugging - not on each event, but at least in one of ten. I guess the Green IT issue is more a unlucky guess of mine and went hand in hand with the problem I face with CURRENT right now on some older, Non UEFI machines. > > > single fate so to speak, or this problem will arise for others, > > too. We exchanged on serving hardware all Realtek NICs with those > > from Intel, and luckily some server mainboards already have Intel > > PHY or NICs. The Broadcom devices we have on some older Fujitus > > hardware is also stable like a charme, even with the new power > > saving switches. > > bge(4) also lacks EEE support(Publicly available datasheet is too > sanitized one). bge(4) firmware probably does not announce EEE > capability by default in link establishment while recent re(4) > devices seem to unconditionally announce EEE. Generally EEE > handling requires a kind of handshake for link state change from > MAC/PHY. > > > While we can swap on server or workstation platforms the NIC, it is > > almost impossible on laptops and the number of laptops with realtek > > chips seems to grow. It is a pity that the venodr of the chipsets > > reject supporting other OSes than Windows - or in some rare cases > > only Linux. After you wrote the answer, I checked on the net who's > > suiatble drivers and the situation seems bad for almost all OSes > > apart from commercial ones like Windooze and Apple OS X. > > > > As soon as I get hands on the laptop again, I'll send the requested > > informations. I know that I played around with re(4) and rgephy(4) > > in the kernel, the rgephy(4) showed up on the dmesg, but I didn't > > see any effect - except that it offered some additional "media > > xxx-options-xxx" mostly appended with "flow" - but rying brought > > also down the system as pluggin or unplugging. > > rgephy(4) will show recognized PHY H/W model. Another information > I'd like to know is OUI information of the PHY. The OUI > information could be get with `devinfo -rv | grep rgephy`. > > The "flow" output of media indicates it negotiated ethernet > flow-control with link partner. rgephy(4) used to announce > autonegotiation even when manual setting is requested with > ifconfig. It was to workaround HW issues seen in the past. > You can disable the use of autonegotiation in manual media > selection with flag0 option. See rgephy(4) for more information. > Not sure whether that option helps though. > > > The last kernel I compiled was then without rgephy(4) - the NIC > > worked as expected, but pluggin/unplugging or having some > > power-down activities on a Netgear SoHo green-pwer switch brings > > the system down as usual. > > If you use re(4) without rgephy(4) it will use ukphy(4) which is > completely dumb on link state detection of re(4) controller. Link > state detection requires non-PHY register access on re(4) so using > ukphy(4) is not recommended. As requested the informations about re0 and rgephy0 on the laptop (Lenovo E540) [...] rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: port 0x3000-0x30ff mem 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff at device 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x50800000 re0: MAC rev. 0x00100000 miibus0: on re0 re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 28:d2:44:79:87:32 re0: netmap queues/slots: TX 1/256, RX 1/256 re0: link state changed to DOWN re0: link state changed to UP [...] I use options netmap in kernel config, but the problem is also present without this option - just for the record. Kind regards, oh From owner-freebsd-current@freebsd.org Tue Oct 25 18:24:55 2016 Return-Path: Delivered-To: freebsd-current@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 3E388C211E0; Tue, 25 Oct 2016 18:24:55 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 31FE72B9; Tue, 25 Oct 2016 18:24:55 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5E18326C; Tue, 25 Oct 2016 18:24:55 +0000 (UTC) Date: Tue, 25 Oct 2016 18:24:52 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: glebius@FreeBSD.org, marcel@FreeBSD.org, imp@FreeBSD.org, andrew@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1173646143.55.1477419895393.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #4159 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:24:55 -0000 FreeBSD_HEAD_i386 - Build #4159 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4159/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4159/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4159/console Change summaries: 307944 by andrew: Add MULTIDELAY support to the am335x dmtimer. This will be useful for testing Cortex-A8 support in GENERIC. Sponsored by: ABT Systems Ltd 307943 by andrew: Remove the need for the delay to be zero when MULTIDELAY is undefined, it may be useful to only enable this in some configs. Sponsored by: ABT Systems Ltd 307942 by imp: Really make WITHOUT_FORTH (MK_FORTH==no) work. The recent inclusion of FICL definitions not in ficl/ficl32 files broke this generally. This makes that stuff conditional on BOOT_FORTH. Also, move definitions related to the architecture (FICL_CPUARCH and friends) into Makefile.ficl that all parts of the tree that include files with ficl need to include (but only if MK_FORTH == yes). In addition, had to fix library ordering issue with LIBSTAND to keep it last. Without boot forth, there's no references to memset to bring in memset.o from libstand.a to satisfy libgeliboot.a's use of it. Listing libstand last solves this issue (and it's the proper place for libstand to boot). 307937 by glebius: Fix unchecked array reference in the VGA device emulation code. Submitted by: Ilja Van Sprundel Patch by: tychon Security: SA-16:32 307936 by glebius: The argument validation in r296956 was not enough to close all possible overflows in sysarch(2). Submitted by: Kun Yang Patch by: kib Security: SA-16:15 307928 by andrew: Remove armadaxp_idcache_wbinv_all, it's a static function in the ELF trampoline and not used outside this. Sponsored by: ABT Systems Ltd 307927 by marcel: Be more precise when including headers so that we're less likely to depend on namespace pollution and as such become more portable. This means including headers like or , but also making sure we include system/host headers before local headers. While here: define ENOATTR as ENOMSG in mtree.c. There is no ENOATTR on Linux. With this, makefs is ready for compilation on macOS and Linux. 307926 by glebius: Check m_getcl() return value. CID: 611376 307925 by andrew: Remove arm11x6_setttb and armv7_setttb as they are unused. While here remove unneeded code from the ARMv7 cpu assembly code. Sponsored by: ABT Systems Ltd 307923 by marcel: Allow building makefs(8) from another Makefile (such as one in a seperate directory hierarchy used to build tools). This boils down to replacing the use of ${.CURDIR} with either ${SRCDIR} or ${SRCTOP}. SRCDIR is defined as the directory in which the Makefile lives that bmake(1) is currently reading. Use SRCTOP when reaching outside of makefs's directory. The end of the build log: [...truncated 7618 lines...] /usr/obj/usr/src/rescue/rescue/usr/src/usr.sbin/chown created for /usr/src/usr.sbin/chown --- obj_subdir_sbin --- --- obj_subdir_sbin/ipf/ipresend --- ===> sbin/ipf/ipresend (obj) --- obj_subdir_rescue --- --- obj_crunchdir_iscsid --- cd /usr/src/rescue/rescue/../../usr.sbin/iscsid && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue /usr/obj/usr/src/make.i386/bmake DIRPRFX=rescue/rescue/iscsid/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_share --- --- obj --- /usr/obj/usr/src/share/doc/psd/05.sysman created for /usr/src/share/doc/psd/05.sysman --- obj_subdir_share/doc/psd/06.Clang --- ===> share/doc/psd/06.Clang (obj) --- obj --- /usr/obj/usr/src/share/doc/psd/06.Clang created for /usr/src/share/doc/psd/06.Clang --- obj_subdir_share/doc/psd/12.make --- ===> share/doc/psd/12.make (obj) --- obj_subdir_lib --- --- obj --- /usr/obj/usr/src/lib/libpam/modules/pam_unix created for /usr/src/lib/libpam/modules/pam_unix --- obj_subdir_share --- --- obj --- --- obj_subdir_lib --- --- obj_subdir_lib/libpam/static_libpam --- ===> lib/libpam/static_libpam (obj) --- obj_subdir_share --- /usr/obj/usr/src/share/doc/psd/12.make created for /usr/src/share/doc/psd/12.make --- obj_subdir_rescue --- --- obj --- --- obj_subdir_share --- --- obj_subdir_share/doc/psd/15.yacc --- ===> share/doc/psd/15.yacc (obj) --- obj_subdir_rescue --- /usr/obj/usr/src/rescue/rescue/usr/src/usr.sbin/iscsid created for /usr/src/usr.sbin/iscsid --- obj_subdir_share --- --- obj_subdir_share/doc/psd/16.lex --- ===> share/doc/psd/16.lex (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/ipf/ipresend created for /usr/src/sbin/ipf/ipresend --- obj_subdir_sbin/ipfw --- ===> sbin/ipfw (obj) --- obj_subdir_share --- --- obj_subdir_share/doc/psd/15.yacc --- --- obj --- /usr/obj/usr/src/share/doc/psd/15.yacc created for /usr/src/share/doc/psd/15.yacc --- obj_subdir_share/doc/psd/16.lex --- --- obj --- --- obj_subdir_sys --- ===> sys (obj) --- obj_subdir_share --- /usr/obj/usr/src/share/doc/psd/16.lex created for /usr/src/share/doc/psd/16.lex --- obj_subdir_share/doc/psd/17.m4 --- ===> share/doc/psd/17.m4 (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/ipfw created for /usr/src/sbin/ipfw --- obj_subdir_sbin/natd --- ===> sbin/natd (obj) --- obj_subdir_lib --- --- obj --- /usr/obj/usr/src/lib/libpam/static_libpam created for /usr/src/lib/libpam/static_libpam --- obj_subdir_lib/libpcap --- ===> lib/libpcap (obj) --- obj_subdir_share --- --- obj --- /usr/obj/usr/src/share/doc/psd/17.m4 created for /usr/src/share/doc/psd/17.m4 --- obj_subdir_share/doc/psd/18.gprof --- ===> share/doc/psd/18.gprof (obj) --- obj_subdir_sys --- --- obj_subdir_sys/boot --- ===> sys/boot (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/natd created for /usr/src/sbin/natd --- obj_subdir_sbin/iscontrol --- ===> sbin/iscontrol (obj) --- obj_subdir_lib --- --- obj --- /usr/obj/usr/src/lib/libpcap created for /usr/src/lib/libpcap --- obj_subdir_lib/libpjdlog --- ===> lib/libpjdlog (obj) --- obj_subdir_share --- --- obj --- /usr/obj/usr/src/share/doc/psd/18.gprof created for /usr/src/share/doc/psd/18.gprof --- obj_subdir_share/doc/psd/20.ipctut --- ===> share/doc/psd/20.ipctut (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/iscontrol created for /usr/src/sbin/iscontrol --- obj_subdir_lib --- --- obj --- --- obj_subdir_sbin --- --- obj_subdir_sbin/pfctl --- ===> sbin/pfctl (obj) --- obj_subdir_share --- --- obj --- --- obj_subdir_lib --- /usr/obj/usr/src/lib/libpjdlog created for /usr/src/lib/libpjdlog --- obj_subdir_share --- /usr/obj/usr/src/share/doc/psd/20.ipctut created for /usr/src/share/doc/psd/20.ipctut --- obj_subdir_lib --- --- obj_subdir_lib/libproc --- ===> lib/libproc (obj) --- obj_subdir_share --- --- obj_subdir_share/doc/psd/21.ipc --- ===> share/doc/psd/21.ipc (obj) --- obj --- /usr/obj/usr/src/share/doc/psd/21.ipc created for /usr/src/share/doc/psd/21.ipc --- obj_subdir_share/doc/psd/22.rpcgen --- ===> share/doc/psd/22.rpcgen (obj) --- obj_subdir_sys --- --- obj_subdir_sys/boot/ficl --- ===> sys/boot/ficl (obj) bmake[5]: "/usr/src/sys/boot/ficl/Makefile" line 4: Cannot open /usr/src/sys/boot/ficl/../Makefile.ficl --- obj_subdir_lib --- --- obj_subdir_lib/libproc/tests --- ===> lib/libproc/tests (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/pfctl created for /usr/src/sbin/pfctl --- obj_subdir_sbin/pflogd --- ===> sbin/pflogd (obj) --- obj_subdir_share --- --- obj --- /usr/obj/usr/src/share/doc/psd/22.rpcgen created for /usr/src/share/doc/psd/22.rpcgen --- obj_subdir_share/doc/psd/23.rpc --- ===> share/doc/psd/23.rpc (obj) --- obj_subdir_sbin --- --- obj --- /usr/obj/usr/src/sbin/pflogd created for /usr/src/sbin/pflogd --- obj_subdir_share --- --- obj --- --- obj_subdir_lib --- --- obj --- --- obj_subdir_sbin --- --- obj_subdir_sbin/quotacheck --- ===> sbin/quotacheck (obj) --- obj_subdir_share --- /usr/obj/usr/src/share/doc/psd/23.rpc created for /usr/src/share/doc/psd/23.rpc --- obj_subdir_lib --- /usr/obj/usr/src/lib/libproc/tests created for /usr/src/lib/libproc/tests --- obj --- --- obj_subdir_share --- --- obj_subdir_share/doc/psd/24.xdr --- ===> share/doc/psd/24.xdr (obj) --- obj_subdir_lib --- --- obj_subdir_lib/libprocstat --- ===> lib/libprocstat (obj) --- obj_subdir_sys --- bmake[5]: Fatal errors encountered -- cannot continue bmake[5]: stopped in /usr/src/sys/boot/ficl *** [obj_subdir_sys/boot/ficl] Error code 1 bmake[4]: stopped in /usr/src/sys/boot 1 error bmake[4]: stopped in /usr/src/sys/boot *** [obj_subdir_sys/boot] Error code 2 bmake[3]: stopped in /usr/src/sys 1 error bmake[3]: stopped in /usr/src/sys *** [obj_subdir_sys] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_share --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /usr/src/share/doc/psd/24.xdr *** [obj_subdir_share/doc/psd/24.xdr] Error code 2 bmake[5]: stopped in /usr/src/share/doc/psd 1 error bmake[5]: stopped in /usr/src/share/doc/psd *** [obj_subdir_share/doc/psd] Error code 2 bmake[4]: stopped in /usr/src/share/doc 1 error bmake[4]: stopped in /usr/src/share/doc *** [obj_subdir_share/doc] Error code 2 bmake[3]: stopped in /usr/src/share 1 error bmake[3]: stopped in /usr/src/share *** [obj_subdir_share] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_sbin --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/sbin/quotacheck *** [obj_subdir_sbin/quotacheck] Error code 2 bmake[3]: stopped in /usr/src/sbin 1 error bmake[3]: stopped in /usr/src/sbin *** [obj_subdir_sbin] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/lib/libprocstat *** [obj_subdir_lib/libprocstat] Error code 2 bmake[3]: stopped in /usr/src/lib 1 error bmake[3]: stopped in /usr/src/lib *** [obj_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src 4 errors bmake[2]: stopped in /usr/src *** [_obj] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson3300711734356396921.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::103:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Oct 25 18:47:21 2016 Return-Path: Delivered-To: freebsd-current@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 0140DC21D1F for ; Tue, 25 Oct 2016 18:47:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-32.reflexion.net [208.70.210.32]) (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 A5B6CA44 for ; Tue, 25 Oct 2016 18:47:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27309 invoked from network); 25 Oct 2016 18:41:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 18:41:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 14:40:47 -0400 (EDT) Received: (qmail 16205 invoked from network); 25 Oct 2016 18:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 18:40:47 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C49FDEC903A; Tue, 25 Oct 2016 11:40:38 -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.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Message-Id: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> Date: Tue, 25 Oct 2016 11:40:38 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:47:21 -0000 [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . In truss's enter_syscall there is (from a live gdb on truss, after the = segmentation fault): 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 (gdb) print narg $6 =3D 0 (that last is for context for the get_syscall arguments). FYI: 580828064 =3D 0x229EBBA0 Context: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Oct 25 18:47:21 2016 Return-Path: Delivered-To: freebsd-current@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 3233EC21D21 for ; Tue, 25 Oct 2016 18:47:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-27.reflexion.net [208.70.210.27]) (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 D6E4BA45 for ; Tue, 25 Oct 2016 18:47:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5533 invoked from network); 25 Oct 2016 18:40:38 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 18:40:38 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 14:40:47 -0400 (EDT) Received: (qmail 16136 invoked from network); 25 Oct 2016 18:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 18:40:47 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8E626EC8814; Tue, 25 Oct 2016 11:40:38 -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.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Message-Id: Date: Tue, 25 Oct 2016 11:40:38 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:47:21 -0000 [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . In truss's enter_syscall there is (from a live gdb on truss, after the = segmentation fault): 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 (gdb) print narg $6 =3D 0 (that last is for context for the get_syscall arguments). FYI: 580828064 =3D 0x229EBBA0 Context: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Oct 25 19:04:29 2016 Return-Path: Delivered-To: freebsd-current@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 9AE72C2230E for ; Tue, 25 Oct 2016 19:04:29 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 808B47B5; Tue, 25 Oct 2016 19:04:29 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A9FDB26E; Tue, 25 Oct 2016 19:04:29 +0000 (UTC) Date: Tue, 25 Oct 2016 19:04:29 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <594779757.56.1477422269613.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #836 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:04:29 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/836/------------------------------------------ [...truncated 10327 lines...] --- cleanobj --- --- h_strncpy.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_strncpy NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=h_strncpy cleandir) --- cleandir_subdir_sbin --- --- cleanobj --- --- cleandir_subdir_share --- --- cleandepend --- rm -f .depend .depend.* --- cleandir_subdir_lib --- --- cleandir_subdir_lib/libc/tests/locale --- --- clean --- rm -f mbrtowc_test mbrtowc_test.full mbrtowc_test.debug t_mbrtowc.o --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_lib --- --- cleandepend --- rm -f .depend.mbrtowc_test .depend.mbrtowc_test.* GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_lib/libbsdstat --- ===> lib/libbsdstat (cleandir) --- cleandir_subdir_lib/libc --- --- cleanobj --- --- cleandir_subdir_share --- --- cleandir_subdir_share/doc/pjdfstest --- ===> share/doc/pjdfstest (cleandir) --- cleandir_subdir_lib --- --- mbstowcs_test.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale && DEPENDFILE=.depend.mbstowcs_test NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=mbstowcs_test cleandir) --- cleandir_subdir_lib/libc/tests/ssp --- --- clean --- rm -f h_strncpy h_strncpy.full h_strncpy.debug h_strncpy.o --- cleandepend --- rm -f .depend.h_strncpy .depend.h_strncpy.* GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- h_vsnprintf.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_vsnprintf NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=h_vsnprintf cleandir) --- cleandir_subdir_lib/libbsdstat --- --- cleanobj --- --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_lib --- --- cleandir_subdir_lib/libc --- --- h_vsprintf.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_vsprintf NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=h_vsprintf cleandir) --- cleandir_subdir_lib/libc/tests/locale --- --- clean --- --- cleandir_subdir_share --- --- cleandir_subdir_share/doc/papers --- ===> share/doc/papers (cleandir) --- cleandir_subdir_lib --- rm -f mbstowcs_test mbstowcs_test.full mbstowcs_test.debug t_mbstowcs.o --- cleandepend --- rm -f .depend.mbstowcs_test .depend.mbstowcs_test.* GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- mbsnrtowcs_test.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale && DEPENDFILE=.depend.mbsnrtowcs_test NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=mbsnrtowcs_test cleandir) --- cleandir_subdir_lib/libc/tests/ssp --- --- h_vsnprintf.cleandir --- --- clean --- rm -f h_vsnprintf h_vsnprintf.full h_vsnprintf.debug h_vsnprintf.o --- cleandepend --- rm -f .depend.h_vsnprintf .depend.h_vsnprintf.* GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- cleandir_subdir_share --- --- cleandir_subdir_share/doc/papers/beyond4.3 --- ===> share/doc/papers/beyond4.3 (cleandir) --- cleandir_subdir_lib --- --- h_vsprintf.cleandir --- --- clean --- rm -f h_vsprintf h_vsprintf.full h_vsprintf.debug h_vsprintf.o --- cleandir_subdir_share --- --- cleandir_subdir_share/dtrace --- ===> share/dtrace (cleandir) --- cleandir_subdir_lib --- --- cleandepend --- rm -f .depend.h_vsprintf .depend.h_vsprintf.* GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_share --- --- cleandir_subdir_share/doc --- --- cleanobj --- --- cleandir_subdir_lib --- --- cleanobj --- --- cleanobj --- --- cleandir_subdir_share --- --- cleandir_subdir_share/doc/papers/bufbio --- ===> share/doc/papers/bufbio (cleandir) --- cleandir_subdir_lib --- --- cleandir_subdir_lib/libc/tests/locale --- --- clean --- --- cleandir_subdir_sys --- ===> sys (cleandir) --- cleandir_subdir_lib --- rm -f mbsnrtowcs_test mbsnrtowcs_test.full mbsnrtowcs_test.debug t_mbsnrtowcs.o --- cleandepend --- rm -f .depend.mbsnrtowcs_test .depend.mbsnrtowcs_test.* GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_lib --- --- cleanobj --- --- cleandir_subdir_share --- --- cleandir_subdir_share/dtrace --- --- cleanobj --- --- cleandir_subdir_lib --- --- mbtowc_test.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale && DEPENDFILE=.depend.mbtowc_test NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=mbtowc_test cleandir) --- cleandir_subdir_share --- --- cleandir_subdir_share/doc --- --- cleandir_subdir_share/doc/papers/contents --- ===> share/doc/papers/contents (cleandir) --- cleandir_subdir_sys --- --- cleandir_subdir_sys/boot --- ===> sys/boot (cleandir) --- cleandir_subdir_usr.bin --- ===> usr.bin (cleandir) --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_share/doc/papers/devfs --- ===> share/doc/papers/devfs (cleandir) --- cleandir_subdir_sys --- --- cleandir_subdir_sys/boot/ficl --- ===> sys/boot/ficl (cleandir) --- cleandir_subdir_lib --- --- clean --- --- cleandir_subdir_sys --- bmake[5]: "/builds/workspace/FreeBSD_HEAD/src/sys/boot/ficl/Makefile" line 4: Cannot open /builds/workspace/FreeBSD_HEAD/src/sys/boot/ficl/../Makefile.ficl --- cleandir_subdir_lib --- rm -f mbtowc_test mbtowc_test.full mbtowc_test.debug t_mbtowc.o --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_lib --- --- cleandepend --- rm -f .depend.mbtowc_test .depend.mbtowc_test.* GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- cleandir_subdir_share --- --- cleandir_subdir_share/doc/papers/diskperf --- ===> share/doc/papers/diskperf (cleandir) --- cleandir_subdir_lib --- --- wcscspn_test.cleandir --- (cd /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale && DEPENDFILE=.depend.wcscspn_test NO_SUBDIR=1 /builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/make.amd64/bmake -f Makefile _RECURSING_PROGS=t PROG=wcscspn_test cleandir) --- cleandir_subdir_share --- --- cleanobj --- --- cleandir_subdir_sys --- bmake[5]: Fatal errors encountered -- cannot continue bmake[5]: stopped in /builds/workspace/FreeBSD_HEAD/src/sys/boot/ficl *** [cleandir_subdir_sys/boot/ficl] Error code 1 bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/sys/boot 1 error bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/sys/boot *** [cleandir_subdir_sys/boot] Error code 2 bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/sys 1 error bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/sys --- cleandir_subdir_share --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /builds/workspace/FreeBSD_HEAD/src/share/doc/papers/diskperf --- cleandir_subdir_sys --- *** [cleandir_subdir_sys] Error code 2 bmake[2]: stopped in /builds/workspace/FreeBSD_HEAD/src --- cleandir_subdir_share --- *** [cleandir_subdir_share/doc/papers/diskperf] Error code 2 bmake[5]: stopped in /builds/workspace/FreeBSD_HEAD/src/share/doc/papers 1 error bmake[5]: stopped in /builds/workspace/FreeBSD_HEAD/src/share/doc/papers *** [cleandir_subdir_share/doc/papers] Error code 2 bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/share/doc 1 error bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/share/doc *** [cleandir_subdir_share/doc] Error code 2 bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/share 1 error bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/share *** [cleandir_subdir_share] Error code 2 bmake[2]: stopped in /builds/workspace/FreeBSD_HEAD/src --- cleandir_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[7]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale *** [wcscspn_test.cleandir] Error code 2 bmake[6]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale 1 error bmake[6]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests/locale *** [cleandir_subdir_lib/libc/tests/locale] Error code 2 bmake[5]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests 1 error bmake[5]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc/tests *** [cleandir_subdir_lib/libc/tests] Error code 2 bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc 1 error bmake[4]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib/libc *** [cleandir_subdir_lib/libc] Error code 2 bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib 1 error bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/lib *** [cleandir_subdir_lib] Error code 2 bmake[2]: stopped in /builds/workspace/FreeBSD_HEAD/src --- cleandir_subdir_usr.bin --- A failure has been detected in another branch of the parallel make bmake[3]: stopped in /builds/workspace/FreeBSD_HEAD/src/usr.bin *** [cleandir_subdir_usr.bin] Error code 2 bmake[2]: stopped in /builds/workspace/FreeBSD_HEAD/src 4 errors bmake[2]: stopped in /builds/workspace/FreeBSD_HEAD/src *** [_cleanobj] Error code 2 bmake[1]: stopped in /builds/workspace/FreeBSD_HEAD/src 1 error bmake[1]: stopped in /builds/workspace/FreeBSD_HEAD/src *** [buildworld] Error code 2 make: stopped in /builds/workspace/FreeBSD_HEAD/src 1 error make: stopped in /builds/workspace/FreeBSD_HEAD/src [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // dir [Pipeline] } [Pipeline] // node [Pipeline] node Running on master in /usr/local/jenkins/workspace/FreeBSD_HEAD [Pipeline] { [Pipeline] step From owner-freebsd-current@freebsd.org Tue Oct 25 19:11:22 2016 Return-Path: Delivered-To: freebsd-current@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 E065DC225AE for ; Tue, 25 Oct 2016 19:11:22 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CD1CBE7F for ; Tue, 25 Oct 2016 19:11:22 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: by mailman.ysv.freebsd.org (Postfix) id CC3F1C225AD; Tue, 25 Oct 2016 19:11:22 +0000 (UTC) Delivered-To: current@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 CBE02C225AC for ; Tue, 25 Oct 2016 19:11:22 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: from nmsh3.e.nsc.no (nmsh3.e.nsc.no [193.213.121.74]) by mx1.freebsd.org (Postfix) with ESMTP id B8674E7D; Tue, 25 Oct 2016 19:11:21 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: from terraplane.org (ti0027a400-1368.bb.online.no [88.88.96.95]) by nmsh3.nsc.no (8.14.7/8.14.7) with ESMTP id u9PIFXgk014503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2016 20:15:36 +0200 (MEST) Received: from terraplane.org (localhost [127.0.0.1]) by terraplane.org (8.14.5/8.14.5) with ESMTP id u9PIRVUF060182; Tue, 25 Oct 2016 20:27:31 +0200 (CEST) (envelope-from rumrunner@terraplane.org) Received: (from rumrunner@localhost) by terraplane.org (8.14.5/8.13.8/Submit) id u9PIRVeA060181; Tue, 25 Oct 2016 20:27:31 +0200 (CEST) (envelope-from rumrunner) Date: Tue, 25 Oct 2016 20:27:30 +0200 From: Eivind Nicolay Evensen To: Baptiste Daroussin Cc: current@freebsd.org Subject: Re: [RFC] remove GNU rcs from FreeBSD 12 Message-ID: <20161025182730.GA60030@klump.hjerdalen.lokalnett> References: <20160911133804.a7j7p3x2viqzcpec@ivaldir.etoilebsd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160911133804.a7j7p3x2viqzcpec@ivaldir.etoilebsd.net> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:11:23 -0000 On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote: > hi, > > For long we are planning to remove GNU rcs from base, after a failed attempt > before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD > 12. Whatever the outcome may be and for whatever my opinion is worth, I hope rcs will stay in base. I don't care about the licensing. I don't care if a switch to openrcs happens either, as long as it works. For years, one has been able to rely upon this operating system having certain pieces of software available. Losing that makes it a worse choice than before. I've already had to readd cvs to my freebsd tree since that was removed, but if it keeps getting worse and worse and there's soon a freebsd kernel and some random bits of freebsd userland available through ports, there's not much reason to keep using it as an operating system, because then it is not an operating system anymore, rather an emulation of another "system" built around that concept. Eivind N. E. From owner-freebsd-current@freebsd.org Tue Oct 25 21:00:20 2016 Return-Path: Delivered-To: freebsd-current@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 49F3FC2175C; Tue, 25 Oct 2016 21:00:20 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3D0727A0; Tue, 25 Oct 2016 21:00:20 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B6FB9271; Tue, 25 Oct 2016 21:00:20 +0000 (UTC) Date: Tue, 25 Oct 2016 21:00:16 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhb@FreeBSD.org, cem@FreeBSD.org, imp@FreeBSD.org, br@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <300289089.58.1477429220756.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1173646143.55.1477419895393.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1173646143.55.1477419895393.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #4160 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 21:00:20 -0000 FreeBSD_HEAD_i386 - Build #4160 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4160/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4160/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4160/console Change summaries: 307951 by imp: Fix two backwards tests. CID: 1365227, 1365228 307950 by imp: Add it to the right place 307949 by imp: Add missing file 307948 by jhb: Use binary and (&) instead of logical to extract the mask of a capability. CID: 1365227 Submitted by: cem 307947 by br: Change fs image name so it will not be regenerated (we have both big and little-endian images in tree). Also we don't known the endianness of the platform the image was generated on. Sponsored by: DARPA, AFRL Sponsored by: HEIF5 307946 by cem: uhso(4): Fix a null pointer dereference The directly following m_defrag() call can wait, so there is no reason this call can't as well. Reported by: Coverity CID: 1353551 Sponsored by: Dell EMC Isilon From owner-freebsd-current@freebsd.org Tue Oct 25 21:32:12 2016 Return-Path: Delivered-To: freebsd-current@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 2AEB1C21E90 for ; Tue, 25 Oct 2016 21:32:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 DFD9E6C3 for ; Tue, 25 Oct 2016 21:32:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17291 invoked from network); 25 Oct 2016 21:31:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 21:31:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 17:32:18 -0400 (EDT) Received: (qmail 22302 invoked from network); 25 Oct 2016 21:32:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 21:32:17 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 151B0EC903A; Tue, 25 Oct 2016 14:32:09 -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.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540) Message-Id: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> Date: Tue, 25 Oct 2016 14:32:08 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 21:32:12 -0000 [I'll be submitting some of the below information to bugzilla.] While trying to build lang/gcc6 on a BPI-M3 (Cortex-A7, ALLWINNER) I got = "xgcc: internal compiler error: Bad system call (program cc1)", which = means a SIGSYS (signal 12) resulted. [I will note that I'v never seen this issue (so far) on the rpi2: This = may be KERNCONF=3DALLWINNER specific. But I've not yet updated to = -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've = been using for a long time.] This was under/on: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 [Note this was cross-built and then a matching svnlite co was done on = the BPi-M3. So the source timestamps on the BPi-M3 are newer than the = times from the cross build.] root@bananapi-m3:/usr/ports # svnlite info /usr/ports/ | grep "Re[lv]" Relative URL: ^/head Revision: 424540 Last Changed Rev: 424540 dmesg | tail shows: pid 29581 (cc1), uid 0: exited on signal 12 (core dumped) pid 29613 (cc1), uid 0: exited on signal 12 (core dumped) pid 29622 (cc1), uid 0: exited on signal 12 (core dumped) pid 29651 (cc1), uid 0: exited on signal 12 (core dumped) pid 29660 (cc1), uid 0: exited on signal 12 (core dumped) pid 29798 (cc1), uid 0: exited on signal 12 (core dumped) pid 30422 (cc1), uid 0: exited on signal 12 (core dumped) pid 30426 (cc1), uid 0: exited on signal 12 (core dumped) pid 30428 (cc1), uid 0: exited on signal 12 (core dumped) pid 30431 (cc1), uid 0: exited on signal 12 (core dumped) (All the lang/gcc6 prerequisites built okay on the BPi-M3.) Unfortunately direct execution of the cc1 command on the libgcc2.i from = a use of -save-temps does not fail. For some reason the failure is only = when xgcc causes the cc1 command execution. Also unfortunately truss gets a segmentation fault of its own trying the = handle watching the SIGSYS related activity. (A truss bugzilla report = has been made.) Thus the following tail of the truss output for leading = up to the SIGSYS does not cover the SIGSYS related activity itself: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # tail truss.log 31183 100086: close(3) =3D 0 (0x0) 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"./longlong.h",O_NOCTTY,00) ERR#2 'No such = file or directory' 31183 100086: openat(AT_FDCWD,"../.././gcc/longlong.h",O_NOCTTY,00) = ERR#2 'No such file or directory' 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../include/longlong.h",O_NOCTTY,00) =3D 3 (0x3) 31183 100086: fstat(3,{ mode=3D-rw-r--r-- = ,inode=3D573594,size=3D61185,blksize=3D32768 }) =3D 0 (0x0) 31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) =3D = 61185 (0xef01) 31183 100086: close(3) =3D 0 (0x0) 31183 100086: = mmap(0x0,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,16384,0x100000000= ) Via using gdb on truss [with truss running xgcc and xgcc in turn running = its cc1 instance]: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss . . . [the below is in enter_syscall] . . . 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (t->cs.name =3D=3D NULL after line 380). . . Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 FYI: 580828064 =3D 0x229EBBA0 (sc =3D=3D NULL results from line 385 so sc->nargs on line 386 gets a = SIGSEGV.) Just for completness: (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 Supporting details follow. . . The specific error reports are: xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _muldi3.o] Error 4 gmake[5]: *** Waiting for unfinished jobs.... xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _negdi2.o] Error 4 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _cmpdi2.o] Error 4 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _ucmpdi2.o] Error 4 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd1= 1.0/libgcc' gmake[4]: *** [Makefile:14874: all-stage1-target-libgcc] Error 2 The specific xgcc commands were: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep = -DL_negdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _cmpdi2.o -MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep = -DL_cmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _ucmpdi2.o -MT _ucmpdi2.o -MD -MP -MF _ucmpdi2.dep = -DL_ucmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Unfortunately gdb does not report much directly. . . root@bananapi-m3:/usr/ports # gdb = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/cc1 = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11= .0/libgcc/cc1.core 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 "armv6-marcel-freebsd"... Core was generated by = `/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -quiet -I = . -I . -I'. Program terminated with signal 12, Bad system call. Reading symbols from /usr/local/lib/libmpc.so.3...done. Loaded symbols for /usr/local/lib/libmpc.so.3 Reading symbols from /usr/local/lib/libmpfr.so.4...done. Loaded symbols for /usr/local/lib/libmpfr.so.4 Reading symbols from /usr/local/lib/libgmp.so.10...done. Loaded symbols for /usr/local/lib/libgmp.so.10 Reading symbols from /lib/libz.so.6...Reading symbols from = /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...Reading symbols from = /usr/lib/debug//lib/libcxxrt.so.1.debug...done. done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libm.so.5...Reading symbols from = /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0xbfbf732c in ?? () (gdb) bt #0 0xbfbf732c in ?? () Cannot access memory at address 0x0 (gdb) info reg r0 0x4e 78 r1 0x0 0 r2 0x17c8506 24937734 r3 0x65 101 r4 0xbfbf7488 -1077971832 r5 0xbfbf7484 -1077971836 r6 0xbfbf7488 -1077971832 r7 0x229eab40 580823872 r8 0x0 0 r9 0xbfbfa23c -1077960132 r10 0xbfbf7484 -1077971836 r11 0x0 0 r12 0x17ef3b1 25097137 sp 0xbfbf7180 -1077972608 lr 0x65 101 pc 0xbfbf732c -1077972180 fps 0x0 0 cpsr 0xa0000010 -1610612720 Using -v -save-temps on one of the failing xgcc command lines gives: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS -v -save-temps xgcc: warning: -pipe ignored because -save-temps specified Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/specs = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgc= c Target: armv6-portbld-freebsd11.0 Configured with: = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/configure = --disable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc6 = --libexecdir=3D/usr/local/libexec/gcc6 --program-suffix=3D6 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc6/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc6 --build=3Darmv6-portbld-freebsd11.0 Thread model: posix gcc version 6.2.0 (FreeBSD Ports Collection)=20 COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc' = '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -E -quiet = -v -I . -I . -I ../.././gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -iprefix = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/arm= v6-portbld-freebsd11.0/6.2.0/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed = -MD _muldi3.d -MF _muldi3.dep -MP -MT _muldi3.o -D LIBICONV_PLUG -D = LIBICONV_PLUG -D IN_GCC -D IN_LIBGCC2 -D HAVE_CC_TLS -D L_muldi3 -D = HIDE_EXPORTS -isystem /usr/local/armv6-portbld-freebsd11.0/include = -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -isystem = ./include = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -mcpu=3Dcortex-a7 -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -Wextra -Wall = -Wno-narrowing -Wwrite-strings -Wcast-qual -Wformat=3D0 = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -fno-strict-aliasing -fbuilding-libgcc -fno-stack-protector -fPIC = -fno-inline -fomit-frame-pointer -fvisibility=3Dhidden -g -g -g = -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/include" ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/inc= lude" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-p= ortbld-freebsd11.0/include" ignoring duplicate directory "." ignoring duplicate directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../.././gcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc' = '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 = -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=3Dcortex-a7 = -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -auxbase-strip _muldi3.o -g -g -g = -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual = -Wformat=3D0 -Wstrict-prototypes -Wmissing-prototypes = -Wold-style-definition -version -fno-strict-aliasing -fbuilding-libgcc = -fno-stack-protector -fPIC -fno-inline -fomit-frame-pointer = -fvisibility=3Dhidden -o libgcc2.s GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 Compiler executable checksum: 8858bcab14af90339532fc36ec745f79 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # ls -lt | head total 12712 -rw------- 1 root wheel 12181504 Oct 25 16:57 cc1.core -rw-r--r-- 1 root wheel 0 Oct 25 16:57 libgcc2.s -rw-r--r-- 1 root wheel 108880 Oct 25 16:57 libgcc2.i -rw-r--r-- 1 root wheel 7636 Oct 25 16:57 _muldi3.dep -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _ucmpdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _cmpdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _negdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _muldi3.o -rw-r--r-- 1 root wheel 1784 Oct 25 10:16 _dvmd_lnx_s.o Unfortunately direct execution of the reported cc1 command on the = libgcc2.i in question does not fail. Attempting to run the xgcc command under truss got a segmentation fault = in truss itself: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # truss -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Segmentation fault (core dumped) [There is a separate buzilla report about this truss failure.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Oct 25 23:02:58 2016 Return-Path: Delivered-To: freebsd-current@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 203C9C2266C for ; Tue, 25 Oct 2016 23:02:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1282D920; Tue, 25 Oct 2016 23:02:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 45252274; Tue, 25 Oct 2016 23:02:58 +0000 (UTC) Date: Tue, 25 Oct 2016 23:02:58 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <452372424.59.1477436578215.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <594779757.56.1477422269613.JavaMail.jenkins@jenkins-9.freebsd.org> References: <594779757.56.1477422269613.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #837 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 23:02:58 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/837/ From owner-freebsd-current@freebsd.org Wed Oct 26 16:43:48 2016 Return-Path: Delivered-To: freebsd-current@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 7263DC2296D for ; Wed, 26 Oct 2016 16:43:48 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E25BFC2; Wed, 26 Oct 2016 16:43:47 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000:0:0:0:1]) by acme.spoerlein.net (8.15.2/8.15.2) with ESMTPS id u9QGhhlE077603 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Oct 2016 18:43:44 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Wed, 26 Oct 2016 18:43:43 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Kevin Oberman , kib@FreeBSD.org, Hans Petter Selasky , FreeBSD Current Subject: 11.x deadlocking during pfault (was Re: FreeBSD 11.x grinds to a halt after about 48h of uptime) Message-ID: <20161026164343.GC2734@acme.spoerlein.net> Mail-Followup-To: Kevin Oberman , kib@FreeBSD.org, Hans Petter Selasky , FreeBSD Current References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> <20161024174327.GB2734@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161024174327.GB2734@acme.spoerlein.net> User-Agent: Mutt/1.7.0 (2016-08-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 16:43:48 -0000 On Mon, 2016-10-24 at 19:43:27 +0200, Ulrich Spörlein wrote: > On Sat, 2016-10-15 at 09:36:27 -0700, Kevin Oberman wrote: > > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > > wrote: > > > > > On 10/15/16 18:18, Ulrich Spörlein wrote: > > > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine ever > > >> since I upgraded it to 11-CURRENT years ago. I have no idea when this > > >> started, actually, but what always happens is this: > > >> > > >> - System and X11 is up and running, I keep it running over night as I'm > > >> too lazy to reboot and restart everthing. > > >> - There's a bunch of xterms, Chrome, Clementine-Player and some other > > >> programs running > > >> - Coming back to the machine the next day (or the day after) it will > > >> exit the screensaver just fine and then either I can use it for a couple > > >> of seconds before it freezes, or it's pretty much dead already. The > > >> mouse cursor still moves for a bit, but the also freezes (so it this a > > >> GPU problem??) > > >> > > >> Now what I currently see on the screen is a clock widget stuck at 18:04 > > >> but conky itself has last updated at 18:00:18 ... > > >> > > >> This time I had some SSH sessions from another machine to see some more > > >> useful things. There was nothing in various logs under /var/log (I also > > >> can't run dmesg anymore ...) > > >> I had top(1) running in a loop, this is the last output: > > >> > > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 > > >> 18:00:12 > > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > > >> > > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other > > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > > >> > > >> > > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > > >> COMMAND > > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% > > >> idle > > >> 3122 uqs 15 28 0 7113M 5861M uwait 0 > > >> 94:44 13.96% chrome > > >> 2887 uqs 28 22 0 1394M 237M > > >> select 2 172:53 6.98% chrome > > >> 2890 uqs 11 21 0 > > >> 1034M 178M select 5 231:21 1.95% chrome > > >> 1062 root 9 > > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > > >> 3002 uqs > > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% > > >> chrome > > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% > > >> chrome > > >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% > > >> intr > > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% > > >> chrome > > >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% > > >> conky > > >> 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% > > >> systat > > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% > > >> chrome > > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% > > >> chrome > > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% > > >> chrome > > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% > > >> chrome > > >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% > > >> clementine-player > > >> 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% > > >> pagedaemon > > >> > > >> I also had systat -vm running and it continued to update its screen ... > > >> for a short while, this is the last update before SSH died: > > >> > > >> > > >> Mem usage: 0k%Phy 5%Kmem > > >> Mem: KB REAL VIRTUAL VN PAGER SWAP > > >> PAGER > > >> Tot Share Tot Share Free in out in > > >> out > > >> Act 11051k 67868 71051992 255448 61840 count > > >> All 11051k 67924 71058776 262100 pages > > >> Proc: > > >> Interrupts > > >> r p d s w Csw Trp Sys Int Sof Flt ioflt 224 > > >> total > > >> 25 730 11 724 109 404 101 13 cow 2 > > >> ehci0 16 > > >> zfod 3 > > >> ehci1 23 > > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 > > >> cpu0:timer > > >> | | | | | | | | | | %ozfod > > >> xhci0 264 > > >> daefr 3 em0 > > >> 265 > > >> 50 dtbuf prcfr 94 > > >> hdac1 266 > > >> Namei Name-cache Dir-cache 349167 desvn totfr > > >> ahci0 270 > > >> Calls hits % hits % 349155 numvn react 5 > > >> cpu1:timer > > >> 121 121 100 253501 frevn pdwak 1 > > >> cpu2:timer > > >> pdpgs 29 > > >> cpu7:timer > > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 > > >> cpu3:timer > > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 > > >> cpu6:timer > > >> tps 0 0 0 0 0 0 9261404 act 12 > > >> cpu5:timer > > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 > > >> cpu4:timer > > >> %busy 0 0 0 0 0 0 cache > > >> vgapci0 > > >> 61840 free > > >> 712304 buf > > >> > > >> > > >> Why do I have a Chrome tab using about 6G? What other sort of debugging > > >> output can be helpful to get to the bottom of this? The machine still > > >> responds to pings just fine, TCP connections get set up but the SSH > > >> handshake never completes. > > >> > > >> This always happens between 30-50h and is super annoying and has been > > >> going on for >1year. Help? > > >> > > >> Note, I cut the power to the monitor overnight to save electricity, can > > >> this mess up something in the Radeon card or X server? What combinations > > >> would be most useful to try next? > > >> > > >> > > > Hi, > > > > > > Sounds like a memory leak. Can you track the memory use over time? > > > > > > Did you look at the output from: > > > > > > vmstat -m ? > > > > > > --HPS > > > > > > I have noted significant memory leakage in chromium for some time. If I > > leave it running overnight, my system is essentially frozen. If I terminate > > the chromium process, it slowly comes back to life. I always keep a gkrellm > > session on-screen where the memory and swap utilization is continuously > > displayed and that clearly shows resources declining. > > That is not what is happening to my system though, it actually > deadlocks. There's no way to recover from it, it seems. > > So I killed Chromium overnight each day, and I'm at this: > > % top -Sbores > last pid: 44526; load averages: 0.10, 0.11, 0.56 up 7+09:53:30 19:33:25 > 156 processes: 2 running, 153 sleeping, 1 waiting > > Mem: 315M Active, 550M Inact, 5671M Wired, 515M Buf, 9324M Free > ARC: 1852M Total, 541M MFU, 196M MRU, 16K Anon, 93M Header, 1022M Other > Swap: 4096M Total, 2186M Used, 1910M Free, 53% Inuse > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 2755 uqs 10 20 0 1697M 311M select 1 47:23 0.00% conky > 2736 uqs 32 20 0 699M 116M select 7 94:29 0.00% clementine-player > 3000 uqs 12 20 0 1126M 69380K select 5 9:48 0.00% digikam > 960 root 9 20 0 448M 59076K select 0 250:22 0.00% Xorg > 72608 uqs 8 20 0 939M 55432K uwait 5 0:01 0.00% chrome > 72599 uqs 9 52 0 929M 55116K uwait 0 0:00 0.00% chrome > 2567 root 1 20 0 89948K 42964K select 1 1:51 0.00% bsnmpd > 70476 uqs 1 20 0 93656K 25712K select 2 0:05 0.00% xterm > 2730 uqs 5 20 0 208M 14988K select 1 0:22 0.00% clock-applet > 880 root 1 20 0 22628K 12500K select 3 0:20 0.00% ntpd > 2726 uqs 4 20 0 206M 12456K select 6 0:09 0.00% mateweather-applet > 44352 uqs 1 20 0 75224K 12348K select 4 0:00 0.00% xterm > 43049 uqs 1 20 0 75224K 11792K select 5 0:00 0.00% xterm > 3074 uqs 2 20 0 308M 9692K select 1 0:02 0.00% kdeinit4 > 2671 uqs 1 20 0 144M 9488K select 1 0:13 0.00% openbox > 3072 uqs 1 20 0 210M 8284K select 3 0:00 0.00% kdeinit4 > 2724 uqs 4 20 0 154M 8256K select 2 0:19 0.00% wnck-applet > 2701 uqs 5 20 0 177M 8144K select 2 0:01 0.00% mate-panel > > > 7d running, pretty good. But look closer, the system is doing pretty > much nothing but did swap out 2G. What? > > > Try closing your chromium at night and see if that fixes the problem. > > It's better, but I'm not sure it's a real fix. I've now turned off > "hardware acceleration" in Chromium, though chrome://gpu didn't real > inspire confidence that it was actually using any h/w accel at all. > > > > If you have never tried gkrellm (sysutils/gkrellm2), it is a the best > > system monitor I have found. though pulls in a lot of dependencies. It also > > can run as a server with remote systems displaying the data. Handy to > > monitor servers. > > I had a cacti-setup that would also monitor my workstation (through a > OpenVPN tunnel), but that has bit-rotted and Apache only gives me 500s > on that cacti URL and nothing in the logs, oh well ...) > > Hooking up a serial console and testing whether DDB works is probably > the next best step to take ... Sigh, I forgot to shut down Chrome overnight, and my system is deadlocked again. I can still switch virtual desktops in X11 and a running xterm accepts keyboard input, but it is 18:35 now and I see that my X11 clock has last updated at 17:18 and conky is stuck at 17:14:11 my top-in-a-loop is stuck here and no longer loops: last pid: 73731; load averages: 0.23, 0.24, 0.23 up 9+07:34:15 17:14:10 160 processes: 3 running, 146 sleeping, 11 zombie Mem: 9302M Active, 763M Inact, 5682M Wired, 752M Buf, 113M Free ARC: 1731M Total, 549M MFU, 129M MRU, 16K Anon, 91M Header, 963M Other Swap: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 960 root 9 21 0 451M 55796K CPU7 7 299:15 2.98% Xorg 53884 uqs 27 22 0 904M 250M CPU4 4 105:05 2.98% chrome 54081 uqs 15 21 0 3601M 2527M uwait 6 38:11 0.98% chrome 2736 uqs 33 20 0 697M 84620K select 5 95:38 0.00% clementine-player 2755 uqs 10 20 0 2111M 721M select 0 60:47 0.00% conky 78943 uqs 1 20 0 21532K 3328K select 7 13:12 0.00% systat 54048 uqs 15 25 5 1093M 159M uwait 4 9:51 0.00% chrome 3000 uqs 12 20 0 1126M 53248K select 7 9:50 0.00% digikam 53999 uqs 19 25 5 1525M 514M uwait 5 6:28 0.00% chrome 2703 uqs 1 20 0 169M 5948K select 0 5:40 0.00% mate-volume-control 2707 uqs 1 20 0 60240K 2516K select 7 5:21 0.00% autocutsel 54077 uqs 15 20 0 1803M 821M uwait 6 3:51 0.00% chrome 78869 uqs 1 20 0 93480K 6636K select 7 3:38 0.00% sshd 38396 uqs 1 20 0 75224K 3896K select 0 3:18 0.00% xterm 2567 root 1 20 0 89948K 43892K select 6 2:25 0.00% bsnmpd 876 root 9 52 0 30120K 3468K uwait 7 2:20 0.00% nscd 883 root 1 20 0 10444K 1708K select 0 2:16 0.00% powerd 2586 haldaemon 2 20 0 56620K 3920K select 1 2:04 0.00% hald systat -vm: 10 users Load 0.21 0.23 0.23 Oct 26 17:14 Mem usage: 0k%Phy 5%Kmem Mem: KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 10545k 51036 67451248 249344 61912 count 120 3 All 10550k 55504 67480212 275720 pages 807 3 Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 149 ioflt 845 total 6 781 12 9327 6923 24k 318 18 6649 20 cow 2 ehci0 16 5064 zfod 3 ehci1 23 4.7%Sys 0.0%Intr 1.7%User 0.0%Nice 93.6%Idle 16 ozfod 106 cpu0:timer | | | | | | | | | | %ozfod xhci0 264 ==> 927 daefr 45 em0 265 51 dtbuf 545 prcfr 94 hdac1 266 Namei Name-cache Dir-cache 349167 desvn 1787 totfr 175 ahci0 270 Calls hits % hits % 337762 numvn react 50 cpu1:timer 935 901 96 170078 frevn pdwak 48 cpu3:timer 1435985 pdpgs 66 cpu2:timer Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 77 cpu7:timer KB/t 0.00 22.59 0.00 0.00 0.00 0.00 5819100 wire 75 cpu4:timer tps 17 168 0 0 0 0 9723008 act 51 cpu6:timer MB/s 0.00 3.70 0.00 0.00 0.00 0.00 636300 inact 53 cpu5:timer %busy 0 3 0 0 0 0 cache vgapci0 61912 free 770732 buf I'm unable to scroll back the vmstat -m output in my tmux pane (running on a different system, this is super strange), so all I can show is this: inodedep 16 12293K - 2770872 512 bmsafemap 9 49K - 2136243 256,8192 newblk 28 24582K - 4111401 256 indirdep 4 1K - 865983 128,16384 freefrag 6 1K - 682027 128 freeblks 3 1K - 1318985 256 freefile 3 1K - 1272832 64 diradd 2 1K - 1306741 128 mkdir 0 0K - 5120 128 dirrem 0 0K - 1305358 128 newdirblk 0 0K - 2610 64 freework 9 1K - 1566489 64,128 sbdep 0 0K - 45661 64 savedino 0 0K - 186280 256 softdep 6 3K - 6 512 ufs_dirhash 1533 767K - 109513 16,32,64,128,256,512,1024,2048,4096 ufs_quota 1 2048K - 1 ufs_mount 18 55K - 18 512,2048,4096,8192 vm_pgdata 1 2048K - 2 128 UMAHash 23 5385K - 108 512,1024,2048,4096,8192,16384,32768,65536 memdesc 1 4K - 1 4096 atkbddev 2 1K - 2 64 entropy 1 1K - 894489 32,4096 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 SCSI ENC 25 100K - 120744 16,64,256,2048,32768 io_apic 1 2K - 1 2048 MCA 18 3K - 18 64,128 msi 16 2K - 16 128 nexusdev 5 1K - 5 16 hdaa 5 54K - 5 2048,16384,32768 hdac 1 1K - 1 1024 hdacc 1 1K - 1 32 linux 29 2K - 29 64 solaris 295750 228696K - 140520323 16,32,64,128,256,512,1024,2048,4096,8192,32768 kstat_data 6 1K - 6 64 eli data 22 4K - 6218901 64,256,512,1024,2048,4096,8192,16384,32768,65536 ksem 1 8K - 1 8192 nullfs_hash 1 2048K - 1 nullfs_node 9 1K - 41 64 nullfs_mount 9 1K - 9 32 fdesc_mount 1 1K - 1 16 gem_name 46 14K - 122 32,4096 drm_global 2 1K - 2 128,256 drm_dma 1 1K - 1 32 drm_sarea 1 1K - 1 16 drm_driver 91 2278K - 125 16,32,64,128,256,512,1024,2048,4096,8192,32768 drm_minor 2 1K - 2 128 drm_files 1 1K - 3 512 drm_ctxbitmap 1 4K - 1 4096 drm_sman 41 6K - 42 128 drm_hashtab 3 4129K - 4 128,32768 drm_kms 69 19K - 163 16,32,64,128,256,512,2048,4096,8192 drm_vblank 7 1K - 7 32,256 ttm_pd 16 17K - 18 16,128,2048,65536 ttm_rman 2 1K - 2 256 ttm_zone 2 1K - 2 64 ttm_poolmgr 1 1K - 1 512 Now what? The xterm I have running locally with a stuck top is showing the top 3 chrome processes in pfault state and it has "Swap: 11M In" in the header, so clearly 11.x is prone to deadlock during page faults and or swapping. It has last updated on 17:14:13 (compare to the other top at 17:14:10 not showing pfault state yet). From owner-freebsd-current@freebsd.org Wed Oct 26 16:45:21 2016 Return-Path: Delivered-To: freebsd-current@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 15B12C22A5B for ; Wed, 26 Oct 2016 16:45:21 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B64E4196; Wed, 26 Oct 2016 16:45:20 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000:0:0:0:1]) by acme.spoerlein.net (8.15.2/8.15.2) with ESMTPS id u9QGjI3t077669 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Oct 2016 18:45:18 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Wed, 26 Oct 2016 18:45:18 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Kevin Oberman , kib@FreeBSD.org, Hans Petter Selasky , FreeBSD Current Subject: Re: 11.x deadlocking during pfault (was Re: FreeBSD 11.x grinds to a halt after about 48h of uptime) Message-ID: <20161026164518.GD2734@acme.spoerlein.net> Mail-Followup-To: Kevin Oberman , kib@FreeBSD.org, Hans Petter Selasky , FreeBSD Current References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> <20161024174327.GB2734@acme.spoerlein.net> <20161026164343.GC2734@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161026164343.GC2734@acme.spoerlein.net> User-Agent: Mutt/1.7.0 (2016-08-17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 16:45:21 -0000 On Wed, 2016-10-26 at 18:43:43 +0200, Ulrich Spörlein wrote: > On Mon, 2016-10-24 at 19:43:27 +0200, Ulrich Spörlein wrote: > > On Sat, 2016-10-15 at 09:36:27 -0700, Kevin Oberman wrote: > > > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > > > wrote: > > > > > > > On 10/15/16 18:18, Ulrich Spörlein wrote: > > > > > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine ever > > > >> since I upgraded it to 11-CURRENT years ago. I have no idea when this > > > >> started, actually, but what always happens is this: > > > >> > > > >> - System and X11 is up and running, I keep it running over night as I'm > > > >> too lazy to reboot and restart everthing. > > > >> - There's a bunch of xterms, Chrome, Clementine-Player and some other > > > >> programs running > > > >> - Coming back to the machine the next day (or the day after) it will > > > >> exit the screensaver just fine and then either I can use it for a couple > > > >> of seconds before it freezes, or it's pretty much dead already. The > > > >> mouse cursor still moves for a bit, but the also freezes (so it this a > > > >> GPU problem??) > > > >> > > > >> Now what I currently see on the screen is a clock widget stuck at 18:04 > > > >> but conky itself has last updated at 18:00:18 ... > > > >> > > > >> This time I had some SSH sessions from another machine to see some more > > > >> useful things. There was nothing in various logs under /var/log (I also > > > >> can't run dmesg anymore ...) > > > >> I had top(1) running in a loop, this is the last output: > > > >> > > > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 > > > >> 18:00:12 > > > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > > > >> > > > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > > > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other > > > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > > > >> > > > >> > > > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > > > >> COMMAND > > > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% > > > >> idle > > > >> 3122 uqs 15 28 0 7113M 5861M uwait 0 > > > >> 94:44 13.96% chrome > > > >> 2887 uqs 28 22 0 1394M 237M > > > >> select 2 172:53 6.98% chrome > > > >> 2890 uqs 11 21 0 > > > >> 1034M 178M select 5 231:21 1.95% chrome > > > >> 1062 root 9 > > > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > > > >> 3002 uqs > > > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > > > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% > > > >> chrome > > > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% > > > >> chrome > > > >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% > > > >> intr > > > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% > > > >> chrome > > > >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% > > > >> conky > > > >> 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% > > > >> systat > > > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% > > > >> chrome > > > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% > > > >> chrome > > > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% > > > >> chrome > > > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% > > > >> chrome > > > >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% > > > >> clementine-player > > > >> 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% > > > >> pagedaemon > > > >> > > > >> I also had systat -vm running and it continued to update its screen ... > > > >> for a short while, this is the last update before SSH died: > > > >> > > > >> > > > >> Mem usage: 0k%Phy 5%Kmem > > > >> Mem: KB REAL VIRTUAL VN PAGER SWAP > > > >> PAGER > > > >> Tot Share Tot Share Free in out in > > > >> out > > > >> Act 11051k 67868 71051992 255448 61840 count > > > >> All 11051k 67924 71058776 262100 pages > > > >> Proc: > > > >> Interrupts > > > >> r p d s w Csw Trp Sys Int Sof Flt ioflt 224 > > > >> total > > > >> 25 730 11 724 109 404 101 13 cow 2 > > > >> ehci0 16 > > > >> zfod 3 > > > >> ehci1 23 > > > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 > > > >> cpu0:timer > > > >> | | | | | | | | | | %ozfod > > > >> xhci0 264 > > > >> daefr 3 em0 > > > >> 265 > > > >> 50 dtbuf prcfr 94 > > > >> hdac1 266 > > > >> Namei Name-cache Dir-cache 349167 desvn totfr > > > >> ahci0 270 > > > >> Calls hits % hits % 349155 numvn react 5 > > > >> cpu1:timer > > > >> 121 121 100 253501 frevn pdwak 1 > > > >> cpu2:timer > > > >> pdpgs 29 > > > >> cpu7:timer > > > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 > > > >> cpu3:timer > > > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 > > > >> cpu6:timer > > > >> tps 0 0 0 0 0 0 9261404 act 12 > > > >> cpu5:timer > > > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 > > > >> cpu4:timer > > > >> %busy 0 0 0 0 0 0 cache > > > >> vgapci0 > > > >> 61840 free > > > >> 712304 buf > > > >> > > > >> > > > >> Why do I have a Chrome tab using about 6G? What other sort of debugging > > > >> output can be helpful to get to the bottom of this? The machine still > > > >> responds to pings just fine, TCP connections get set up but the SSH > > > >> handshake never completes. > > > >> > > > >> This always happens between 30-50h and is super annoying and has been > > > >> going on for >1year. Help? > > > >> > > > >> Note, I cut the power to the monitor overnight to save electricity, can > > > >> this mess up something in the Radeon card or X server? What combinations > > > >> would be most useful to try next? > > > >> > > > >> > > > > Hi, > > > > > > > > Sounds like a memory leak. Can you track the memory use over time? > > > > > > > > Did you look at the output from: > > > > > > > > vmstat -m ? > > > > > > > > --HPS > > > > > > > > > I have noted significant memory leakage in chromium for some time. If I > > > leave it running overnight, my system is essentially frozen. If I terminate > > > the chromium process, it slowly comes back to life. I always keep a gkrellm > > > session on-screen where the memory and swap utilization is continuously > > > displayed and that clearly shows resources declining. > > > > That is not what is happening to my system though, it actually > > deadlocks. There's no way to recover from it, it seems. > > > > So I killed Chromium overnight each day, and I'm at this: > > > > % top -Sbores > > last pid: 44526; load averages: 0.10, 0.11, 0.56 up 7+09:53:30 19:33:25 > > 156 processes: 2 running, 153 sleeping, 1 waiting > > > > Mem: 315M Active, 550M Inact, 5671M Wired, 515M Buf, 9324M Free > > ARC: 1852M Total, 541M MFU, 196M MRU, 16K Anon, 93M Header, 1022M Other > > Swap: 4096M Total, 2186M Used, 1910M Free, 53% Inuse > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 2755 uqs 10 20 0 1697M 311M select 1 47:23 0.00% conky > > 2736 uqs 32 20 0 699M 116M select 7 94:29 0.00% clementine-player > > 3000 uqs 12 20 0 1126M 69380K select 5 9:48 0.00% digikam > > 960 root 9 20 0 448M 59076K select 0 250:22 0.00% Xorg > > 72608 uqs 8 20 0 939M 55432K uwait 5 0:01 0.00% chrome > > 72599 uqs 9 52 0 929M 55116K uwait 0 0:00 0.00% chrome > > 2567 root 1 20 0 89948K 42964K select 1 1:51 0.00% bsnmpd > > 70476 uqs 1 20 0 93656K 25712K select 2 0:05 0.00% xterm > > 2730 uqs 5 20 0 208M 14988K select 1 0:22 0.00% clock-applet > > 880 root 1 20 0 22628K 12500K select 3 0:20 0.00% ntpd > > 2726 uqs 4 20 0 206M 12456K select 6 0:09 0.00% mateweather-applet > > 44352 uqs 1 20 0 75224K 12348K select 4 0:00 0.00% xterm > > 43049 uqs 1 20 0 75224K 11792K select 5 0:00 0.00% xterm > > 3074 uqs 2 20 0 308M 9692K select 1 0:02 0.00% kdeinit4 > > 2671 uqs 1 20 0 144M 9488K select 1 0:13 0.00% openbox > > 3072 uqs 1 20 0 210M 8284K select 3 0:00 0.00% kdeinit4 > > 2724 uqs 4 20 0 154M 8256K select 2 0:19 0.00% wnck-applet > > 2701 uqs 5 20 0 177M 8144K select 2 0:01 0.00% mate-panel > > > > > > 7d running, pretty good. But look closer, the system is doing pretty > > much nothing but did swap out 2G. What? > > > > > Try closing your chromium at night and see if that fixes the problem. > > > > It's better, but I'm not sure it's a real fix. I've now turned off > > "hardware acceleration" in Chromium, though chrome://gpu didn't real > > inspire confidence that it was actually using any h/w accel at all. > > > > > > > If you have never tried gkrellm (sysutils/gkrellm2), it is a the best > > > system monitor I have found. though pulls in a lot of dependencies. It also > > > can run as a server with remote systems displaying the data. Handy to > > > monitor servers. > > > > I had a cacti-setup that would also monitor my workstation (through a > > OpenVPN tunnel), but that has bit-rotted and Apache only gives me 500s > > on that cacti URL and nothing in the logs, oh well ...) > > > > Hooking up a serial console and testing whether DDB works is probably > > the next best step to take ... > > Sigh, I forgot to shut down Chrome overnight, and my system is > deadlocked again. I can still switch virtual desktops in X11 and a > running xterm accepts keyboard input, but it is 18:35 now and I see that > my X11 clock has last updated at 17:18 and conky is stuck at 17:14:11 > > my top-in-a-loop is stuck here and no longer loops: > > last pid: 73731; load averages: 0.23, 0.24, 0.23 up 9+07:34:15 17:14:10 > 160 processes: 3 running, 146 sleeping, 11 zombie > > Mem: 9302M Active, 763M Inact, 5682M Wired, 752M Buf, 113M Free > ARC: 1731M Total, 549M MFU, 129M MRU, 16K Anon, 91M Header, 963M Other > Swap: > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 960 root 9 21 0 451M 55796K CPU7 7 299:15 2.98% Xorg > 53884 uqs 27 22 0 904M 250M CPU4 4 105:05 2.98% chrome > 54081 uqs 15 21 0 3601M 2527M uwait 6 38:11 0.98% chrome > 2736 uqs 33 20 0 697M 84620K select 5 95:38 0.00% clementine-player > 2755 uqs 10 20 0 2111M 721M select 0 60:47 0.00% conky > 78943 uqs 1 20 0 21532K 3328K select 7 13:12 0.00% systat > 54048 uqs 15 25 5 1093M 159M uwait 4 9:51 0.00% chrome > 3000 uqs 12 20 0 1126M 53248K select 7 9:50 0.00% digikam > 53999 uqs 19 25 5 1525M 514M uwait 5 6:28 0.00% chrome > 2703 uqs 1 20 0 169M 5948K select 0 5:40 0.00% mate-volume-control > 2707 uqs 1 20 0 60240K 2516K select 7 5:21 0.00% autocutsel > 54077 uqs 15 20 0 1803M 821M uwait 6 3:51 0.00% chrome > 78869 uqs 1 20 0 93480K 6636K select 7 3:38 0.00% sshd > 38396 uqs 1 20 0 75224K 3896K select 0 3:18 0.00% xterm > 2567 root 1 20 0 89948K 43892K select 6 2:25 0.00% bsnmpd > 876 root 9 52 0 30120K 3468K uwait 7 2:20 0.00% nscd > 883 root 1 20 0 10444K 1708K select 0 2:16 0.00% powerd > 2586 haldaemon 2 20 0 56620K 3920K select 1 2:04 0.00% hald > > > systat -vm: > > 10 users Load 0.21 0.23 0.23 Oct 26 17:14 > Mem usage: 0k%Phy 5%Kmem > Mem: KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 10545k 51036 67451248 249344 61912 count 120 3 > All 10550k 55504 67480212 275720 pages 807 3 > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt 149 ioflt 845 total > 6 781 12 9327 6923 24k 318 18 6649 20 cow 2 ehci0 16 > 5064 zfod 3 ehci1 23 > 4.7%Sys 0.0%Intr 1.7%User 0.0%Nice 93.6%Idle 16 ozfod 106 cpu0:timer > | | | | | | | | | | %ozfod xhci0 264 > ==> 927 daefr 45 em0 265 > 51 dtbuf 545 prcfr 94 hdac1 266 > Namei Name-cache Dir-cache 349167 desvn 1787 totfr 175 ahci0 270 > Calls hits % hits % 337762 numvn react 50 cpu1:timer > 935 901 96 170078 frevn pdwak 48 cpu3:timer > 1435985 pdpgs 66 cpu2:timer > Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 77 cpu7:timer > KB/t 0.00 22.59 0.00 0.00 0.00 0.00 5819100 wire 75 cpu4:timer > tps 17 168 0 0 0 0 9723008 act 51 cpu6:timer > MB/s 0.00 3.70 0.00 0.00 0.00 0.00 636300 inact 53 cpu5:timer > %busy 0 3 0 0 0 0 cache vgapci0 > 61912 free > 770732 buf > > > I'm unable to scroll back the vmstat -m output in my tmux pane (running on a > different system, this is super strange), so all I can show is this: > > > inodedep 16 12293K - 2770872 512 > bmsafemap 9 49K - 2136243 256,8192 > newblk 28 24582K - 4111401 256 > indirdep 4 1K - 865983 128,16384 > freefrag 6 1K - 682027 128 > freeblks 3 1K - 1318985 256 > freefile 3 1K - 1272832 64 > diradd 2 1K - 1306741 128 > mkdir 0 0K - 5120 128 > dirrem 0 0K - 1305358 128 > newdirblk 0 0K - 2610 64 > freework 9 1K - 1566489 64,128 > sbdep 0 0K - 45661 64 > savedino 0 0K - 186280 256 > softdep 6 3K - 6 512 > ufs_dirhash 1533 767K - 109513 16,32,64,128,256,512,1024,2048,4096 > ufs_quota 1 2048K - 1 > ufs_mount 18 55K - 18 512,2048,4096,8192 > vm_pgdata 1 2048K - 2 128 > UMAHash 23 5385K - 108 512,1024,2048,4096,8192,16384,32768,65536 > memdesc 1 4K - 1 4096 > atkbddev 2 1K - 2 64 > entropy 1 1K - 894489 32,4096 > apmdev 1 1K - 1 128 > madt_table 0 0K - 1 4096 > SCSI ENC 25 100K - 120744 16,64,256,2048,32768 > io_apic 1 2K - 1 2048 > MCA 18 3K - 18 64,128 > msi 16 2K - 16 128 > nexusdev 5 1K - 5 16 > hdaa 5 54K - 5 2048,16384,32768 > hdac 1 1K - 1 1024 > hdacc 1 1K - 1 32 > linux 29 2K - 29 64 > solaris 295750 228696K - 140520323 16,32,64,128,256,512,1024,2048,4096,8192,32768 > kstat_data 6 1K - 6 64 > eli data 22 4K - 6218901 64,256,512,1024,2048,4096,8192,16384,32768,65536 > ksem 1 8K - 1 8192 > nullfs_hash 1 2048K - 1 > nullfs_node 9 1K - 41 64 > nullfs_mount 9 1K - 9 32 > fdesc_mount 1 1K - 1 16 > gem_name 46 14K - 122 32,4096 > drm_global 2 1K - 2 128,256 > drm_dma 1 1K - 1 32 > drm_sarea 1 1K - 1 16 > drm_driver 91 2278K - 125 16,32,64,128,256,512,1024,2048,4096,8192,32768 > drm_minor 2 1K - 2 128 > drm_files 1 1K - 3 512 > drm_ctxbitmap 1 4K - 1 4096 > drm_sman 41 6K - 42 128 > drm_hashtab 3 4129K - 4 128,32768 > drm_kms 69 19K - 163 16,32,64,128,256,512,2048,4096,8192 > drm_vblank 7 1K - 7 32,256 > ttm_pd 16 17K - 18 16,128,2048,65536 > ttm_rman 2 1K - 2 256 > ttm_zone 2 1K - 2 64 > ttm_poolmgr 1 1K - 1 512 > > > Now what? > > The xterm I have running locally with a stuck top is showing the top 3 chrome > processes in pfault state and it has "Swap: 11M In" in the header, so clearly > 11.x is prone to deadlock during page faults and or swapping. It has last > updated on 17:14:13 (compare to the other top at 17:14:10 not showing pfault > state yet). Addendum: I still see the HDD indication light flickering every couple of seconds, so something is still doing I/O. My SSH sessions into the machine haven't time out, and the screensaver (just DPMS blank) is also still kicking in correctly. From owner-freebsd-current@freebsd.org Wed Oct 26 22:24:43 2016 Return-Path: Delivered-To: freebsd-current@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 C33CEC2351D for ; Wed, 26 Oct 2016 22:24:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-44.reflexion.net [208.70.210.44]) (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 7B6E427B for ; Wed, 26 Oct 2016 22:24:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20049 invoked from network); 26 Oct 2016 22:24:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Oct 2016 22:24:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Wed, 26 Oct 2016 18:24:39 -0400 (EDT) Received: (qmail 32764 invoked from network); 26 Oct 2016 22:24:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Oct 2016 22:24:39 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 913A7EC9105; Wed, 26 Oct 2016 15:24:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540) From: Mark Millard In-Reply-To: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> Date: Wed, 26 Oct 2016 15:24:34 -0700 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2DC2BFC1-613E-4491-84A4-3EC505B10B9D@dsl-only.net> References: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:24:43 -0000 [A top post noting that user "ast" CSW's are involved and other details = in the sequence leading up to the failure.] Using "ktrace -i -t +fw" it looks like every repeat of the problem ends = up with the following sort of sequence (a variation is shown later): 34629 cc1 CALL = mmap(0,0x4000,0x3,0x1002,0xfff= fffff,0x1c,0,0) 34629 cc1 RET mmap 568225792/0x21de7000 34629 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CSW stop user "ast" 34629 cc1 CSW resume user "ast" 34629 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ec000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CALL [-17504] 34629 cc1 RET [-17504] -1 errno 78 Function not implemented 34629 cc1 PSIG SIGSYS SIG_DFL code=3DSI_KERNEL 34629 cc1 NAMI "cc1.core" 34630 as CSW stop kernel "piperd" 34630 as Events dropped. 34630 as RET read 0 34630 as CALL close(0) 34630 as RET close 0 . . . I'll note that for the source this was compiling I used gdb truss with = run -feH -o truss.log and it reported: (gdb) print t->cs.number $5 =3D 580828064 FYI: 580828064 =3D 0x229EBBA0 where the truss segmentation fault was at line 385 of the following = (sc=3D=3DNULL in the context): > 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); > 381 if (t->cs.name =3D=3D NULL) > (gdb)=20 > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", > 383 t->proc->abi->type, t->cs.number); > 384=09 > 385 sc =3D get_syscall(t->cs.name, narg); > 386 t->cs.nargs =3D sc->nargs; > 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); > 388=09 > 389 t->cs.sc =3D sc; The 229E matched the upper part of local PFLT activity around the user = "ast" CSW's, including just before the bad call. But the details do vary some based on the source file being compiled. = For example here the user "ast" CSW's are just before the mmap but are = still just after the 0x229ea000 PFLT: 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0xbfbf2000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CSW stop user "ast" 34698 cc1 CSW resume user "ast" 34698 cc1 CALL = mmap(0,0x4000,0x3,0x1002,0xfff= fffff,0,0,0) 34698 cc1 RET mmap 568225792/0x21de7000 34698 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CALL [-25840] 34698 cc1 RET [-25840] -1 errno 78 Function not implemented 34698 cc1 PSIG SIGSYS SIG_DFL code=3DSI_KERNEL 34698 cc1 NAMI "cc1.core" 34699 as CSW stop kernel "piperd" 34699 as Events dropped. 34699 as RET read 0 34699 as CALL close(0) 34699 as RET close 0 -25840 in 2's complement is: 0xF...F9B10 Here doing the gdb truss instead reports: (gdb) print t->cs.number $1 =3D 580819728 and 580819728 =3D 0x229E9B10 and the 229E part matches several PFLT's in the area, including just = before the bad call as well as just before the user "ast"s. Between them = are some PFLT's that do not match. I would guess that the 229E in t->cs.number in truss is from the PFLT = just before the failing syscall in each case. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Oct-25, at 2:32 PM, Mark Millard wrote: > [I'll be submitting some of the below information to bugzilla.] >=20 > While trying to build lang/gcc6 on a BPI-M3 (Cortex-A7, ALLWINNER) I = got "xgcc: internal compiler error: Bad system call (program cc1)", = which means a SIGSYS (signal 12) resulted. >=20 > [I will note that I'v never seen this issue (so far) on the rpi2: This = may be KERNCONF=3DALLWINNER specific. But I've not yet updated to = -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've = been using for a long time.] >=20 > This was under/on: >=20 > root@bananapi-m3:/usr/ports # uname -apKU > FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon = Oct 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 >=20 > [Note this was cross-built and then a matching svnlite co was done on = the BPi-M3. So the source timestamps on the BPi-M3 are newer than the = times from the cross build.] >=20 > root@bananapi-m3:/usr/ports # svnlite info /usr/ports/ | grep "Re[lv]" > Relative URL: ^/head > Revision: 424540 > Last Changed Rev: 424540 >=20 > dmesg | tail shows: >=20 > pid 29581 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29613 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29622 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29651 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29660 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29798 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30422 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30426 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30428 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30431 (cc1), uid 0: exited on signal 12 (core dumped) >=20 > (All the lang/gcc6 prerequisites built okay on the BPi-M3.) >=20 > Unfortunately direct execution of the cc1 command on the libgcc2.i = from a use of -save-temps does not fail. For some reason the failure is = only when xgcc causes the cc1 command execution. >=20 > Also unfortunately truss gets a segmentation fault of its own trying = the handle watching the SIGSYS related activity. (A truss bugzilla = report has been made.) Thus the following tail of the truss output for = leading up to the SIGSYS does not cover the SIGSYS related activity = itself: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # tail truss.log > 31183 100086: close(3) =3D 0 (0x0) > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' > 31183 100086: openat(AT_FDCWD,"./longlong.h",O_NOCTTY,00) ERR#2 'No = such file or directory' > 31183 100086: openat(AT_FDCWD,"../.././gcc/longlong.h",O_NOCTTY,00) = ERR#2 'No such file or directory' > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../include/longlong.h",O_NOCTTY,00) =3D 3 (0x3) > 31183 100086: fstat(3,{ mode=3D-rw-r--r-- = ,inode=3D573594,size=3D61185,blksize=3D32768 }) =3D 0 (0x0) > 31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) =3D = 61185 (0xef01) > 31183 100086: close(3) =3D 0 (0x0) > 31183 100086: = mmap(0x0,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,16384,0x100000000= ) >=20 > Via using gdb on truss [with truss running xgcc and xgcc in turn = running its cc1 instance]: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss > . . . [the below is in enter_syscall] . . . > 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); > 381 if (t->cs.name =3D=3D NULL) > (gdb)=20 > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", > 383 t->proc->abi->type, t->cs.number); > 384=09 > 385 sc =3D get_syscall(t->cs.name, narg); > 386 t->cs.nargs =3D sc->nargs; > 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); > 388=09 > 389 t->cs.sc =3D sc; >=20 > (t->cs.name =3D=3D NULL after line 380). . . >=20 > Looking at the two things that the fprintf on lines 382 and 383 would = report: >=20 > (gdb) print t->proc->abi->type > $4 =3D 0x10166 "FreeBSD ELF32" >=20 > (gdb) print t->cs.number > $5 =3D 580828064 >=20 > FYI: 580828064 =3D 0x229EBBA0 >=20 > (sc =3D=3D NULL results from line 385 so sc->nargs on line 386 gets a = SIGSEGV.) >=20 > Just for completness: >=20 > (gdb) print *t > $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 > s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} >=20 > (gdb) print sc > $3 =3D (struct syscall *) 0x0 >=20 >=20 >=20 > Supporting details follow. . . >=20 > The specific error reports are: >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _muldi3.o] Error 4 > gmake[5]: *** Waiting for unfinished jobs.... >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _negdi2.o] Error 4 >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _cmpdi2.o] Error 4 >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _ucmpdi2.o] Error 4 >=20 > gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd1= 1.0/libgcc' > gmake[4]: *** [Makefile:14874: all-stage1-target-libgcc] Error 2 >=20 > The specific xgcc commands were: >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep = -DL_negdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _cmpdi2.o -MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep = -DL_cmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _ucmpdi2.o -MT _ucmpdi2.o -MD -MP -MF _ucmpdi2.dep = -DL_ucmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 >=20 > Unfortunately gdb does not report much directly. . . >=20 > root@bananapi-m3:/usr/ports # gdb = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/cc1 = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11= .0/libgcc/cc1.core > 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 "armv6-marcel-freebsd"... > Core was generated by = `/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -quiet -I = . -I . -I'. > Program terminated with signal 12, Bad system call. > Reading symbols from /usr/local/lib/libmpc.so.3...done. > Loaded symbols for /usr/local/lib/libmpc.so.3 > Reading symbols from /usr/local/lib/libmpfr.so.4...done. > Loaded symbols for /usr/local/lib/libmpfr.so.4 > Reading symbols from /usr/local/lib/libgmp.so.10...done. > Loaded symbols for /usr/local/lib/libgmp.so.10 > Reading symbols from /lib/libz.so.6...Reading symbols from = /usr/lib/debug//lib/libz.so.6.debug...done. > done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. > done. > Loaded symbols for /usr/lib/libc++.so.1 > Reading symbols from /lib/libcxxrt.so.1...Reading symbols from = /usr/lib/debug//lib/libcxxrt.so.1.debug...done. > done. > Loaded symbols for /lib/libcxxrt.so.1 > Reading symbols from /lib/libm.so.5...Reading symbols from = /usr/lib/debug//lib/libm.so.5.debug...done. > done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. > done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. > done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0xbfbf732c in ?? () > (gdb) bt > #0 0xbfbf732c in ?? () > Cannot access memory at address 0x0 > (gdb) info reg > r0 0x4e 78 > r1 0x0 0 > r2 0x17c8506 24937734 > r3 0x65 101 > r4 0xbfbf7488 -1077971832 > r5 0xbfbf7484 -1077971836 > r6 0xbfbf7488 -1077971832 > r7 0x229eab40 580823872 > r8 0x0 0 > r9 0xbfbfa23c -1077960132 > r10 0xbfbf7484 -1077971836 > r11 0x0 0 > r12 0x17ef3b1 25097137 > sp 0xbfbf7180 -1077972608 > lr 0x65 101 > pc 0xbfbf732c -1077972180 > fps 0x0 0 > cpsr 0xa0000010 -1610612720 >=20 >=20 > Using -v -save-temps on one of the failing xgcc command lines gives: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/l > ang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS -v -save-temps > xgcc: warning: -pipe ignored because -save-temps specified > Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/specs > = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgc= c > Target: armv6-portbld-freebsd11.0 > Configured with: = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/configure = --disable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc6 = --libexecdir=3D/usr/local/libexec/gcc6 --program-suffix=3D6 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc6/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc6 --build=3Darmv6-portbld-freebsd11.0 > Thread model: posix > gcc version 6.2.0 (FreeBSD Ports Collection)=20 > COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6 > .2.0/libgcc/../gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -E -quiet = -v -I . -I . -I ../.././gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -iprefix = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/arm= v6-portbld-freebsd11.0/6.2.0/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed = -MD _muldi3.d -MF _muldi3.dep -MP -MT _muldi3.o -D LIBICONV_PLUG -D = LIBICONV_PLUG -D IN_GCC -D IN_LIBGCC2 -D HAVE_CC_TLS -D L_muldi3 -D = HIDE_EXPORTS -isystem /usr/local/armv6-portbld-freebsd11.0/include = -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -isystem = ./include = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -mcp > u=3Dcortex-a7 -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -Wextra -Wall = -Wno-narrowing -Wwrite-strings -Wcast-qual -Wformat=3D0 = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -fno-strict-aliasing -fbuilding-libgcc -fno-stack-protector -fPIC = -fno-inline -fomit-frame-pointer -fvisibility=3Dhidden -g -g -g = -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i > ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/include" > ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/sys-include" > ignoring nonexistent directory "./include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include-fixed" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/inc= lude" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include-fixed" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-p= ortbld-freebsd11.0/include" > ignoring duplicate directory "." > ignoring duplicate directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/." > #include "..." search starts here: > #include <...> search starts here: > . > ../.././gcc > /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc > /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc > = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed > /usr/local/include > /usr/include > End of search list. > COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6 > .2.0/libgcc/../gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 = -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=3Dcortex-a7 = -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -auxbase-strip _muldi3.o -g -g -g = -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual = -Wformat=3D0 -Wstrict-prototypes -Wmissing-prototypes = -Wold-style-definition -version -fno-strict-aliasing -fbuilding-libgcc = -fno-stack-protector -fPIC -fno-inline -fomit-frame-pointer = -fvisibility=3Dhidden -o libgcc2.s > GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 > GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 > Compiler executable checksum: 8858bcab14af90339532fc36ec745f79 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # ls -lt | head > total 12712 > -rw------- 1 root wheel 12181504 Oct 25 16:57 cc1.core > -rw-r--r-- 1 root wheel 0 Oct 25 16:57 libgcc2.s > -rw-r--r-- 1 root wheel 108880 Oct 25 16:57 libgcc2.i > -rw-r--r-- 1 root wheel 7636 Oct 25 16:57 _muldi3.dep > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _ucmpdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _cmpdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _negdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _muldi3.o > -rw-r--r-- 1 root wheel 1784 Oct 25 10:16 _dvmd_lnx_s.o >=20 > Unfortunately direct execution of the reported cc1 command on the = libgcc2.i in question does not fail. >=20 > Attempting to run the xgcc command under truss got a segmentation = fault in truss itself: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # truss -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork > /usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS > Segmentation fault (core dumped) >=20 > [There is a separate buzilla report about this truss failure.] >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Oct 27 01:00:12 2016 Return-Path: Delivered-To: freebsd-current@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 97711C22840 for ; Thu, 27 Oct 2016 01:00:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 659C75E5 for ; Thu, 27 Oct 2016 01:00:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id e6so6052940pfk.3 for ; Wed, 26 Oct 2016 18:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8t0EE3zoBz65+6+StAWvTEQ2jm2DXSBr91yISMAqnDk=; b=DUMtDyqLU8jFKjiUY6gGVnMZTJxycgm02GyO+W6tgwdZMMjeXVhYBEeO3wGzwpc3H6 hfVpVDLWDODnXA547IIrWSDfclbNT1YKdnH6qsSScaLRFljyCNfebHFoyYKtAMT3FPjl qoLwU2BN3oxy3Up/WSmh3+p4Pz63kX71T/IRQt19VkOyfjB1iSzkpd812I/j+sNnlWnc a6v8q57NDYjCB5CqaMY6Gc2oJXzMjEcUErLOyIHSl+p5Dtd65OHP83xJHLvaQLNmvpBe byKpGFmzwO7FpuiBqsHaBLv8KR2QAm2nIqgJ7o5ivXZIdTdrIyYk3tvCTd5orL+SgD+9 ejtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=8t0EE3zoBz65+6+StAWvTEQ2jm2DXSBr91yISMAqnDk=; b=T6iX9wKfJkbIRf7a/DRW+OLZw6ZvGKOtfX6jbyD2YmRmNB3KxAfvBvKzS17lPGMUmP fpj1wA7QmVj2FgyQsY2Pi4gVMpsCjFUuWVkQaoztLZxNQhzIUYqKS9ZILXNCkgUwIxy0 ZD9iwqb4ab2dULupJohNFFtg22FmaPzFj0crO+AD2TETA77Km3sVjTwFnBFVOthaPXiU /YCKisFPE/Voz/cRTsA66MbjJLSRv9XKXD/uqwnlbqjyLS8HD043HmLud/73VWJe/5R7 YLqoOWz5GrT+gRylUHetRuGG/VyUJhkGhJq0bCO38OP8ze8cLN4z/D25q6L+pGdINw/B XepA== X-Gm-Message-State: ABUngvcx6OKCHA4tNFnic54379pqufpU59BShq3M5xtYBISFtxwpzRKR2fz6VuwW/vIxpg== X-Received: by 10.98.28.206 with SMTP id c197mr9102231pfc.113.1477530010771; Wed, 26 Oct 2016 18:00:10 -0700 (PDT) Received: from localhost ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id b83sm6745454pfl.41.2016.10.26.18.00.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 18:00:10 -0700 (PDT) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Thu, 27 Oct 2016 10:00:04 +0900 Date: Thu, 27 Oct 2016 10:00:04 +0900 To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161027010004.GA1215@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.com References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> <20161025070338.76ad6711@hermann> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161025070338.76ad6711@hermann> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 01:00:12 -0000 On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote: > On Tue, 25 Oct 2016 11:05:38 +0900 > YongHyeon PYUN wrote: > [...] > > I'm not sure but it's likely the issue is related with EEE/Green > > Ethernet handling. EEE is negotiated feature with link partner. If > > you directly connect your laptop to non-EEE capable link partner > > like other re(4) box without switches you may be able to tell > > whether the issue is EEE/Green Ethernet related one or not. > > Me either since when I discovered a problem the first time with > CURRENT, that was the Friday before last week's Friday, there was a > unlucky coicidence: I got the new switch, FreeBSD introduced a serious > bug and I changed the NICs. > > The laptop, the last in the row of re(4) equipted systems on which I > use the Realtek NIC, does well now with Green IT technology, but > crashes on plugging/unplugging - not on each event, but at least in one > of ten. Hmm, it seems you know how to trigger the issue. When you unplug UTP cable was there active network traffic on re(4) device? It would be helpful to know which event triggers the crash(e.g. unplugging or plugging). And would you show me backtrace of panic? > I guess the Green IT issue is more a unlucky guess of mine and went > hand in hand with the problem I face with CURRENT right now on some > older, Non UEFI machines. > Ok. [...] > > As requested the informations about re0 and rgephy0 on the laptop > (Lenovo E540) > > [...] > > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > re0: port > 0x3000-0x30ff mem 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff at device > 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled > re0: Chip rev. 0x50800000 > re0: MAC rev. 0x00100000 This looks like 8168GU controller. [...] > I use options netmap in kernel config, but the problem is also present > without this option - just for the record. > Yup, netmap(4) has nothing to do with the crash. Thanks. From owner-freebsd-current@freebsd.org Thu Oct 27 12:51:06 2016 Return-Path: Delivered-To: freebsd-current@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 09A2CC2289F for ; Thu, 27 Oct 2016 12:51:06 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 99CD25E6; Thu, 27 Oct 2016 12:51:05 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id b80so32135708wme.1; Thu, 27 Oct 2016 05:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=k8XSr+5jgrLXk5wHP5q73ZWArSm7wtFeI4pvMZTcLL4=; b=jaGDGICAgAthmeTRnJFnwg7SzqU43LrgC7AVsBjL7JyljvdCRURp8LmxeCNzaxMQ6p 0ry5LGSqABDxcn8S2BsduKU/H9Twj1jOC++JEsu48o0BIJRmfQ8dxNa0unKeTVmLK9n8 vxNc3cb8mwIslYHHuj3ygXr7wS9mBwpeGERIEWhiR8SBmX4e+vKh0lhnCvrmKmugdEGj 07gH4xwR3R+gclcOsUx1u87nq6McOwbVX7ZfBcDYAmB85PZfuuqLPV//bCLZtTRg/dYD g48U/OcocmLJADyWV7ziEvMh0iRyn/35bHvcLzmgdRMV+4tC55y7FhsB9z7jVRMH2jEY jqRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=k8XSr+5jgrLXk5wHP5q73ZWArSm7wtFeI4pvMZTcLL4=; b=g/XlquxfpXFShqWXSgMmKfjFbUiEGCXn9i4Uk4Ju0Dz5ti7tx/jhoU4qT1EuOk82ta JMvYsJMFxjC/aMarOOMjgWUzy9HFrwJdSi9B6sSjLdHnUHxCbebNRlU8m69lrt24FOla 4BTgVxkn3Kwsv6qK3d9aZ1kNl4xHWb1xmk+1UtNWelN9Y66YuA1hWu8OcPFRVMYUNOdV fxYCQIbxthM1ttqoutnLeQo9QtU5dv0sgBIGiCiDKJetzc2OnR9z3TsnNh6fqAJiv0E/ F+GG7iSFWRR0oqJlAg/JY3lMbrHW/sxT7Q3EiqDP3IFc1amDyYerg2mKN4QGUlSI5cwd +1Zw== X-Gm-Message-State: ABUngve6L028MF3HUPt9Y49nlhKe4YYKgkGDpYydMKlQQ2vPgVWKDFZZVKMUmMtiYrAtAZUUPOfztgZI1XyMeQ== X-Received: by 10.28.12.77 with SMTP id 74mr8902726wmm.115.1477572663680; Thu, 27 Oct 2016 05:51:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.132 with HTTP; Thu, 27 Oct 2016 05:51:03 -0700 (PDT) In-Reply-To: <20161026164518.GD2734@acme.spoerlein.net> References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> <20161024174327.GB2734@acme.spoerlein.net> <20161026164343.GC2734@acme.spoerlein.net> <20161026164518.GD2734@acme.spoerlein.net> From: Daniel Nebdal Date: Thu, 27 Oct 2016 14:51:03 +0200 Message-ID: Subject: Re: 11.x deadlocking during pfault (was Re: FreeBSD 11.x grinds to a halt after about 48h of uptime) To: Kevin Oberman , kib@freebsd.org, Hans Petter Selasky , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:51:06 -0000 On Wed, Oct 26, 2016 at 6:45 PM, Ulrich Sp=C3=B6rlein wro= te: > > On Wed, 2016-10-26 at 18:43:43 +0200, Ulrich Sp=C3=B6rlein wrote: > > On Mon, 2016-10-24 at 19:43:27 +0200, Ulrich Sp=C3=B6rlein wrote: > > > On Sat, 2016-10-15 at 09:36:27 -0700, Kevin Oberman wrote: > > > > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > > > > wrote: > > > > > > > > > On 10/15/16 18:18, Ulrich Sp=C3=B6rlein wrote: > > > > > > > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine e= ver > > > > >> since I upgraded it to 11-CURRENT years ago. I have no idea when= this > > > > >> started, actually, but what always happens is this: > > > > >> > > > > >> - System and X11 is up and running, I keep it running over night= as I'm > > > > >> too lazy to reboot and restart everthing. > > > > >> - There's a bunch of xterms, Chrome, Clementine-Player and some = other > > > > >> programs running > > > > >> - Coming back to the machine the next day (or the day after) it = will > > > > >> exit the screensaver just fine and then either I can use it for = a couple > > > > >> of seconds before it freezes, or it's pretty much dead already. = The > > > > >> mouse cursor still moves for a bit, but the also freezes (so it = this a > > > > >> GPU problem??) > > > > >> > > > > >> Now what I currently see on the screen is a clock widget stuck a= t 18:04 > > > > >> but conky itself has last updated at 18:00:18 ... > > > > >> > > > > >> This time I had some SSH sessions from another machine to see so= me more > > > > >> useful things. There was nothing in various logs under /var/log = (I also > > > > >> can't run dmesg anymore ...) > > > > >> I had top(1) running in a loop, this is the last output: > > > > >> > > > > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03= :28 > > > > >> 18:00:12 > > > > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > > > > >> > > > > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > > > > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012= M Other > > > > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > > > > >> > > > > >> > > > > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME = WCPU > > > > >> COMMAND > > > > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H = 772.95% > > > > >> idle > > > > >> 3122 uqs 15 28 0 7113M 5861M uwait= 0 > > > > >> 94:44 13.96% chrome > > > > >> 2887 uqs 28 22 0 1394= M 237M > > > > >> select 2 172:53 6.98% chrome > > > > >> 2890 uqs 11 2= 1 0 > > > > >> 1034M 178M select 5 231:21 1.95% chrome > > > > >> 1062 root = 9 > > > > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > > > > >> 300= 2 uqs > > > > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > > > > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 = 0.00% > > > > >> chrome > > > > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 = 0.00% > > > > >> chrome > > > > >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 = 0.00% > > > > >> intr > > > > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 = 0.00% > > > > >> chrome > > > > >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 = 0.00% > > > > >> conky > > > > >> 3174 root 1 20 0 21532K 3188K select 0 4:20 = 0.00% > > > > >> systat > > > > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 = 0.00% > > > > >> chrome > > > > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 = 0.00% > > > > >> chrome > > > > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 = 0.00% > > > > >> chrome > > > > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 = 0.00% > > > > >> chrome > > > > >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 = 0.00% > > > > >> clementine-player > > > > >> 20 root 2 -16 - 0K 32K psleep 6 2:25 = 0.00% > > > > >> pagedaemon > > > > >> > > > > >> I also had systat -vm running and it continued to update its scr= een ... > > > > >> for a short while, this is the last update before SSH died: > > > > >> > > > > >> > > > > >> Mem usage: 0k%Phy 5%Kmem > > > > >> Mem: KB REAL VIRTUAL VN PAGER= SWAP > > > > >> PAGER > > > > >> Tot Share Tot Share Free in out= in > > > > >> out > > > > >> Act 11051k 67868 71051992 255448 61840 count > > > > >> All 11051k 67924 71058776 262100 pages > > > > >> Proc: > > > > >> Interrupts > > > > >> r p d s w Csw Trp Sys Int Sof Flt ioflt = 224 > > > > >> total > > > > >> 25 730 11 724 109 404 101 13 cow = 2 > > > > >> ehci0 16 > > > > >> zfod = 3 > > > > >> ehci1 23 > > > > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod = 16 > > > > >> cpu0:timer > > > > >> | | | | | | | | | | %ozfod > > > > >> xhci0 264 > > > > >> daefr = 3 em0 > > > > >> 265 > > > > >> 50 dtbuf prcfr = 94 > > > > >> hdac1 266 > > > > >> Namei Name-cache Dir-cache 349167 desvn totfr > > > > >> ahci0 270 > > > > >> Calls hits % hits % 349155 numvn react = 5 > > > > >> cpu1:timer > > > > >> 121 121 100 253501 frevn pdwak = 1 > > > > >> cpu2:timer > > > > >> pdpgs = 29 > > > > >> cpu7:timer > > > > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn = 12 > > > > >> cpu3:timer > > > > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire = 41 > > > > >> cpu6:timer > > > > >> tps 0 0 0 0 0 0 9261404 act = 12 > > > > >> cpu5:timer > > > > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact = 6 > > > > >> cpu4:timer > > > > >> %busy 0 0 0 0 0 0 cache > > > > >> vgapci0 > > > > >> 61840 free > > > > >> 712304 buf > > > > >> > > > > >> > > > > >> Why do I have a Chrome tab using about 6G? What other sort of de= bugging > > > > >> output can be helpful to get to the bottom of this? The machine = still > > > > >> responds to pings just fine, TCP connections get set up but the = SSH > > > > >> handshake never completes. > > > > >> > > > > >> This always happens between 30-50h and is super annoying and has= been > > > > >> going on for >1year. Help? > > > > >> > > > > >> Note, I cut the power to the monitor overnight to save electrici= ty, can > > > > >> this mess up something in the Radeon card or X server? What comb= inations > > > > >> would be most useful to try next? > > > > >> > > > > >> > > > > > Hi, > > > > > > > > > > Sounds like a memory leak. Can you track the memory use over time= ? > > > > > > > > > > Did you look at the output from: > > > > > > > > > > vmstat -m ? > > > > > > > > > > --HPS > > > > > > > > > > > > I have noted significant memory leakage in chromium for some time.= If I > > > > leave it running overnight, my system is essentially frozen. If I t= erminate > > > > the chromium process, it slowly comes back to life. I always keep a= gkrellm > > > > session on-screen where the memory and swap utilization is continuo= usly > > > > displayed and that clearly shows resources declining. > > > > > > That is not what is happening to my system though, it actually > > > deadlocks. There's no way to recover from it, it seems. > > > > > > So I killed Chromium overnight each day, and I'm at this: > > > > > > % top -Sbores > > > last pid: 44526; load averages: 0.10, 0.11, 0.56 up 7+09:53:30 = 19:33:25 > > > 156 processes: 2 running, 153 sleeping, 1 waiting > > > > > > Mem: 315M Active, 550M Inact, 5671M Wired, 515M Buf, 9324M Free > > > ARC: 1852M Total, 541M MFU, 196M MRU, 16K Anon, 93M Header, 1022M Oth= er > > > Swap: 4096M Total, 2186M Used, 1910M Free, 53% Inuse > > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WC= PU COMMAND > > > 2755 uqs 10 20 0 1697M 311M select 1 47:23 0.0= 0% conky > > > 2736 uqs 32 20 0 699M 116M select 7 94:29 0.0= 0% clementine-player > > > 3000 uqs 12 20 0 1126M 69380K select 5 9:48 0.0= 0% digikam > > > 960 root 9 20 0 448M 59076K select 0 250:22 0.0= 0% Xorg > > > 72608 uqs 8 20 0 939M 55432K uwait 5 0:01 0.0= 0% chrome > > > 72599 uqs 9 52 0 929M 55116K uwait 0 0:00 0.0= 0% chrome > > > 2567 root 1 20 0 89948K 42964K select 1 1:51 0.0= 0% bsnmpd > > > 70476 uqs 1 20 0 93656K 25712K select 2 0:05 0.0= 0% xterm > > > 2730 uqs 5 20 0 208M 14988K select 1 0:22 0.0= 0% clock-applet > > > 880 root 1 20 0 22628K 12500K select 3 0:20 0.0= 0% ntpd > > > 2726 uqs 4 20 0 206M 12456K select 6 0:09 0.0= 0% mateweather-applet > > > 44352 uqs 1 20 0 75224K 12348K select 4 0:00 0.0= 0% xterm > > > 43049 uqs 1 20 0 75224K 11792K select 5 0:00 0.0= 0% xterm > > > 3074 uqs 2 20 0 308M 9692K select 1 0:02 0.0= 0% kdeinit4 > > > 2671 uqs 1 20 0 144M 9488K select 1 0:13 0.0= 0% openbox > > > 3072 uqs 1 20 0 210M 8284K select 3 0:00 0.0= 0% kdeinit4 > > > 2724 uqs 4 20 0 154M 8256K select 2 0:19 0.0= 0% wnck-applet > > > 2701 uqs 5 20 0 177M 8144K select 2 0:01 0.0= 0% mate-panel > > > > > > > > > 7d running, pretty good. But look closer, the system is doing pretty > > > much nothing but did swap out 2G. What? > > > > > > > Try closing your chromium at night and see if that fixes the proble= m. > > > > > > It's better, but I'm not sure it's a real fix. I've now turned off > > > "hardware acceleration" in Chromium, though chrome://gpu didn't real > > > inspire confidence that it was actually using any h/w accel at all. > > > > > > > > > > If you have never tried gkrellm (sysutils/gkrellm2), it is a the be= st > > > > system monitor I have found. though pulls in a lot of dependencies.= It also > > > > can run as a server with remote systems displaying the data. Handy = to > > > > monitor servers. > > > > > > I had a cacti-setup that would also monitor my workstation (through a > > > OpenVPN tunnel), but that has bit-rotted and Apache only gives me 500= s > > > on that cacti URL and nothing in the logs, oh well ...) > > > > > > Hooking up a serial console and testing whether DDB works is probably > > > the next best step to take ... > > > > Sigh, I forgot to shut down Chrome overnight, and my system is > > deadlocked again. I can still switch virtual desktops in X11 and a > > running xterm accepts keyboard input, but it is 18:35 now and I see tha= t > > my X11 clock has last updated at 17:18 and conky is stuck at 17:14:11 > > > > my top-in-a-loop is stuck here and no longer loops: > > > > last pid: 73731; load averages: 0.23, 0.24, 0.23 up 9+07:34:15 = 17:14:10 > > 160 processes: 3 running, 146 sleeping, 11 zombie > > > > Mem: 9302M Active, 763M Inact, 5682M Wired, 752M Buf, 113M Free > > ARC: 1731M Total, 549M MFU, 129M MRU, 16K Anon, 91M Header, 963M Other > > Swap: > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU= COMMAND > > 960 root 9 21 0 451M 55796K CPU7 7 299:15 2.98%= Xorg > > 53884 uqs 27 22 0 904M 250M CPU4 4 105:05 2.98%= chrome > > 54081 uqs 15 21 0 3601M 2527M uwait 6 38:11 0.98%= chrome > > 2736 uqs 33 20 0 697M 84620K select 5 95:38 0.00%= clementine-player > > 2755 uqs 10 20 0 2111M 721M select 0 60:47 0.00%= conky > > 78943 uqs 1 20 0 21532K 3328K select 7 13:12 0.00%= systat > > 54048 uqs 15 25 5 1093M 159M uwait 4 9:51 0.00%= chrome > > 3000 uqs 12 20 0 1126M 53248K select 7 9:50 0.00%= digikam > > 53999 uqs 19 25 5 1525M 514M uwait 5 6:28 0.00%= chrome > > 2703 uqs 1 20 0 169M 5948K select 0 5:40 0.00%= mate-volume-control > > 2707 uqs 1 20 0 60240K 2516K select 7 5:21 0.00%= autocutsel > > 54077 uqs 15 20 0 1803M 821M uwait 6 3:51 0.00%= chrome > > 78869 uqs 1 20 0 93480K 6636K select 7 3:38 0.00%= sshd > > 38396 uqs 1 20 0 75224K 3896K select 0 3:18 0.00%= xterm > > 2567 root 1 20 0 89948K 43892K select 6 2:25 0.00%= bsnmpd > > 876 root 9 52 0 30120K 3468K uwait 7 2:20 0.00%= nscd > > 883 root 1 20 0 10444K 1708K select 0 2:16 0.00%= powerd > > 2586 haldaemon 2 20 0 56620K 3920K select 1 2:04 0.00%= hald > > > > > > systat -vm: > > > > 10 users Load 0.21 0.23 0.23 Oct 26 17:14 > > Mem usage: 0k%Phy 5%Kmem > > Mem: KB REAL VIRTUAL VN PAGER SWAP= PAGER > > Tot Share Tot Share Free in out in= out > > Act 10545k 51036 67451248 249344 61912 count 120 3 > > All 10550k 55504 67480212 275720 pages 807 3 > > Proc: Interr= upts > > r p d s w Csw Trp Sys Int Sof Flt 149 ioflt 845 t= otal > > 6 781 12 9327 6923 24k 318 18 6649 20 cow 2 e= hci0 16 > > 5064 zfod 3 e= hci1 23 > > 4.7%Sys 0.0%Intr 1.7%User 0.0%Nice 93.6%Idle 16 ozfod 106 c= pu0:timer > > | | | | | | | | | | %ozfod x= hci0 264 > > =3D=3D> 927 daefr = 45 em0 265 > > 51 dtbuf 545 prcfr 94 h= dac1 266 > > Namei Name-cache Dir-cache 349167 desvn 1787 totfr 175 a= hci0 270 > > Calls hits % hits % 337762 numvn react 50 c= pu1:timer > > 935 901 96 170078 frevn pdwak 48 c= pu3:timer > > 1435985 pdpgs 66 c= pu2:timer > > Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 77 c= pu7:timer > > KB/t 0.00 22.59 0.00 0.00 0.00 0.00 5819100 wire 75 c= pu4:timer > > tps 17 168 0 0 0 0 9723008 act 51 c= pu6:timer > > MB/s 0.00 3.70 0.00 0.00 0.00 0.00 636300 inact 53 c= pu5:timer > > %busy 0 3 0 0 0 0 cache v= gapci0 > > 61912 free > > 770732 buf > > > > > > I'm unable to scroll back the vmstat -m output in my tmux pane (running= on a > > different system, this is super strange), so all I can show is this: > > > > > > inodedep 16 12293K - 2770872 512 > > bmsafemap 9 49K - 2136243 256,8192 > > newblk 28 24582K - 4111401 256 > > indirdep 4 1K - 865983 128,16384 > > freefrag 6 1K - 682027 128 > > freeblks 3 1K - 1318985 256 > > freefile 3 1K - 1272832 64 > > diradd 2 1K - 1306741 128 > > mkdir 0 0K - 5120 128 > > dirrem 0 0K - 1305358 128 > > newdirblk 0 0K - 2610 64 > > freework 9 1K - 1566489 64,128 > > sbdep 0 0K - 45661 64 > > savedino 0 0K - 186280 256 > > softdep 6 3K - 6 512 > > ufs_dirhash 1533 767K - 109513 16,32,64,128,256,512,1024,= 2048,4096 > > ufs_quota 1 2048K - 1 > > ufs_mount 18 55K - 18 512,2048,4096,8192 > > vm_pgdata 1 2048K - 2 128 > > UMAHash 23 5385K - 108 512,1024,2048,4096,8192,16= 384,32768,65536 > > memdesc 1 4K - 1 4096 > > atkbddev 2 1K - 2 64 > > entropy 1 1K - 894489 32,4096 > > apmdev 1 1K - 1 128 > > madt_table 0 0K - 1 4096 > > SCSI ENC 25 100K - 120744 16,64,256,2048,32768 > > io_apic 1 2K - 1 2048 > > MCA 18 3K - 18 64,128 > > msi 16 2K - 16 128 > > nexusdev 5 1K - 5 16 > > hdaa 5 54K - 5 2048,16384,32768 > > hdac 1 1K - 1 1024 > > hdacc 1 1K - 1 32 > > linux 29 2K - 29 64 > > solaris 295750 228696K - 140520323 16,32,64,128,256,512,10= 24,2048,4096,8192,32768 > > kstat_data 6 1K - 6 64 > > eli data 22 4K - 6218901 64,256,512,1024,2048,4096,= 8192,16384,32768,65536 > > ksem 1 8K - 1 8192 > > nullfs_hash 1 2048K - 1 > > nullfs_node 9 1K - 41 64 > > nullfs_mount 9 1K - 9 32 > > fdesc_mount 1 1K - 1 16 > > gem_name 46 14K - 122 32,4096 > > drm_global 2 1K - 2 128,256 > > drm_dma 1 1K - 1 32 > > drm_sarea 1 1K - 1 16 > > drm_driver 91 2278K - 125 16,32,64,128,256,512,1024,= 2048,4096,8192,32768 > > drm_minor 2 1K - 2 128 > > drm_files 1 1K - 3 512 > > drm_ctxbitmap 1 4K - 1 4096 > > drm_sman 41 6K - 42 128 > > drm_hashtab 3 4129K - 4 128,32768 > > drm_kms 69 19K - 163 16,32,64,128,256,512,2048,= 4096,8192 > > drm_vblank 7 1K - 7 32,256 > > ttm_pd 16 17K - 18 16,128,2048,65536 > > ttm_rman 2 1K - 2 256 > > ttm_zone 2 1K - 2 64 > > ttm_poolmgr 1 1K - 1 512 > > > > > > Now what? > > > > The xterm I have running locally with a stuck top is showing the top 3 = chrome > > processes in pfault state and it has "Swap: 11M In" in the header, so c= learly > > 11.x is prone to deadlock during page faults and or swapping. It has la= st > > updated on 17:14:13 (compare to the other top at 17:14:10 not showing p= fault > > state yet). > > Addendum: I still see the HDD indication light flickering every couple > of seconds, so something is still doing I/O. My SSH sessions into the > machine haven't time out, and the screensaver (just DPMS blank) is also > still kicking in correctly. > Just out of general interest, how is your swap set up? Is it on a zvol or something exotic like that, or is it just a normal partition? --=20 Daniel Nebdal From owner-freebsd-current@freebsd.org Thu Oct 27 13:09:18 2016 Return-Path: Delivered-To: freebsd-current@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 60BA7C22D7C for ; Thu, 27 Oct 2016 13:09:18 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 1E0FF19F for ; Thu, 27 Oct 2016 13:09:18 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-yb0-x236.google.com with SMTP id f97so15214029ybi.1 for ; Thu, 27 Oct 2016 06:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ygqnwk8Vrp5Lv1N1eDciXhTyjrSKhRgijA5mQjjbucM=; b=p+ixRL0K3yAK3bM8YJ5KYFIeHvvlzWkRKHIaugO3uI16+r4Gq8POTyXzlyR8jWjsrv v0XLaOF71S5APc+l99IC55EQjs+YkerunI+qrGMeW3RtWJw+m70vinCZxTXl3PSfAqPF n2RjzH5OIX7fKmYZfYCkRsec87sHh8D+S275/zwk2dvMuQEBbIJOg/Ib1tqybWKgd51r whFZUc/hj6CNolyamlMLhM3ThXF4TNjb5cCvVDbrGVZ8vFHLryb5XsQo1j0pX9X7qIon DwfJVVb6hG3TEZ9nITIQU5iH8h0Ht2OS5jk1e81ygX1fdWNhFQ6oEt068h0sDNOT18rh 2urA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ygqnwk8Vrp5Lv1N1eDciXhTyjrSKhRgijA5mQjjbucM=; b=X4o48INunUmuIPRUa/zTugMr32A4E2iPTz+QqJNmpF7jH/MeFbqjLeGCHrUoQD+oYG d4TRDD0csNFpLo6QGhMFc644E+gj3gohoHqBrkGJETfv+KjwjZV64u5EquzK4n05Bngv HXKQqIt+YcI0LFXwEMAtJp1zty4dmdcqT0WubxgvQ9BzZ821NyjdPfrOoykeyVLitPgN 1WMAcIYsSX0C+wrsiAHRffx/Ab//4OBCuJx0OOIEYbaP/tgNWMYKA2ji6zcByLh8t+JF cWWT2MENjuyIm4dYPcB8pEfHNVbMvFwzJ22MijefqKlK0QIJ1qUHCEK7MvtSUclLapl/ tg5w== X-Gm-Message-State: ABUngve9osYYXPz9PWJWk7EzUf/yYYLF7DPk5i04NIp6umjeS0Xbaqu2an5NYJAQCb0+n7ZF4O53n9B1EWyzDQ== X-Received: by 10.36.73.19 with SMTP id z19mr6098247ita.29.1477573757190; Thu, 27 Oct 2016 06:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.67.196 with HTTP; Thu, 27 Oct 2016 06:09:16 -0700 (PDT) In-Reply-To: References: <20160922130141.GA9643@dft-labs.eu> From: Ben Woods Date: Thu, 27 Oct 2016 21:09:16 +0800 Message-ID: Subject: Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) To: Mateusz Guzik , Ben Woods , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 13:09:18 -0000 On 24 September 2016 at 18:13, Ben Woods wrote: > On 22 September 2016 at 21:01, Mateusz Guzik wrote: > >> On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote: >> > #13 0xffffffff80b4d91c in turnstile_broadcast (ts=0x0, queue=1) at >> > /usr/src/sys/kern/subr_turnstile.c:837 >> > #14 0xffffffff80ae5e1f in __rw_wunlock_hard (c=0xfffff803f886d960, >> > tid=, file=, line=> > optimized out>) >> > at /usr/src/sys/kern/kern_rwlock.c:1027 >> >> can you please: >> f 14 >> x/xg c >> >> >> -- >> Mateusz Guzik >> > > Thanks for the help Mateusz. > > (kgdb) f 14 > #14 0xffffffff80ae5e1f in __rw_wunlock_hard (c=0xfffff803f886d960, > tid=, file=, line= optimized out>) > at /usr/src/sys/kern/kern_rwlock.c:1027 > 1027 turnstile_broadcast(ts, queue); > Current language: auto; currently minimal > (kgdb) x/xg c > 0xfffff803f886d960: 0xfffff8032893aa00 > > Regards, > Ben > Hi everyone, Just a heads up that after updating my FreeBSD 12-current machine to r307773 I am still getting this kernel panic. Note that I have compiled the kernel with VIMAGE support if that makes any difference. Mateusz: any further ideas on what it could be? Any help is appreciated :) Regards, Ben From owner-freebsd-current@freebsd.org Thu Oct 27 13:21:37 2016 Return-Path: Delivered-To: freebsd-current@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 5E982C152F7 for ; Thu, 27 Oct 2016 13:21:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF88C0F for ; Thu, 27 Oct 2016 13:21:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA04393 for ; Thu, 27 Oct 2016 16:21:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bzkca-000DbX-IH for freebsd-current@FreeBSD.org; Thu, 27 Oct 2016 16:21:28 +0300 To: FreeBSD Current From: Andriy Gapon Subject: pmcstat -T -P instructions -t $pid ==> NMI Message-ID: <0479e273-1e86-13d0-ccd4-2fb6f57cff91@FreeBSD.org> Date: Thu, 27 Oct 2016 16:20:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 13:21:37 -0000 I observe a problem on a relatively recent, but not the latest, head. r306752 amd64 on AMD hardware. If I run pmcstat -T -P instructions -t $pid with a pid of a busy userland process, then I shortly get a (stray) NMI. Apparently hwpmc does not recognize that NMI. Any suggestions, help, me-toos? Thank you! -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Oct 27 17:46:54 2016 Return-Path: Delivered-To: freebsd-current@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 29B3CC24EE0 for ; Thu, 27 Oct 2016 17:46:54 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.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 14526C91 for ; Thu, 27 Oct 2016 17:46:53 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bzolL-000MXA-Dx for freebsd-current@freebsd.org; Thu, 27 Oct 2016 11:46:47 -0600 Date: Thu, 27 Oct 2016 11:46:47 -0600 From: The Doctor To: freebsd-current@freebsd.org Subject: POSIX Threads Message-ID: <20161027174647.GA85196@doctor.nl2k.ab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 17:46:54 -0000 Any known issues with Posix threads in FreeBSD 11? While I am at it, What about python and pip? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! From owner-freebsd-current@freebsd.org Thu Oct 27 18:08:13 2016 Return-Path: Delivered-To: freebsd-current@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 28F97C24314 for ; Thu, 27 Oct 2016 18:08:13 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::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 E409D85E for ; Thu, 27 Oct 2016 18:08:12 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bzp67-000Ix4-Ad; Thu, 27 Oct 2016 20:08:15 +0200 Date: Thu, 27 Oct 2016 20:08:15 +0200 From: Kurt Jaeger To: The Doctor Cc: freebsd-current@freebsd.org Subject: Re: POSIX Threads Message-ID: <20161027180815.GJ51420@home.opsec.eu> References: <20161027174647.GA85196@doctor.nl2k.ab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161027174647.GA85196@doctor.nl2k.ab.ca> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 18:08:13 -0000 Hi! > Any known issues with Posix threads in FreeBSD 11? Any specific scenario you have in mind ? Searching bugzilla for 'threads', I found: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209233 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209748 Maybe if you ask on freebsd-threads@freebsd.org, which discusses threads in general ? > While I am at it, What about python and pip? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212950 is not 11-specific, but a pip-PR nonetheless. I did not search for python, too many hits 8-} -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Thu Oct 27 16:58:20 2016 Return-Path: Delivered-To: freebsd-current@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 CD25FC241B4; Thu, 27 Oct 2016 16:58:20 +0000 (UTC) (envelope-from cipher_nl@hotmail.com) Received: from BAY004-OMC1S23.hotmail.com (bay004-omc1s23.hotmail.com [65.54.190.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A47CEF58; Thu, 27 Oct 2016 16:58:20 +0000 (UTC) (envelope-from cipher_nl@hotmail.com) Received: from EUR03-VE1-obe.outbound.protection.outlook.com ([65.54.190.59]) by BAY004-OMC1S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 27 Oct 2016 09:57:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bdgmIE4On5Gi1aPc1RnaS4f/dzEYkMTtFFJ8s2njDdQ=; b=S+oEyJLfGRAFy4PEHEYju2blH29urJ8ThWguQ14vEXIE423zU/Z0vnWSBPeRDiMA4QOFpBU5UR0MfdJT9+XgoSfAGRhEpDDs7Fg3/1iZ1lZgWCSXVFneyeg+g34l6LEdqwG+qPtgDeMLXXw//a+OX64BCFB7Hl4qq1qKqt5CDYyjl8txTIRWAMvXmCN9+WwngFaFPiolBYhB6ncSFrkeqO39Drm5ia+0FzP9409BEo6fz82p9F17a/czA0tUrm+99i6JBCZaKeKeo81g0YvFwPnm2W60UByHZrs+f1Vq40N1/CvzDDcV6cklcTISH0yA3Z8eH8g6kvB78GBUnBRmag== Received: from VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com (10.152.18.58) by VE1EUR03HT012.eop-EUR03.prod.protection.outlook.com (10.152.18.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 16:57:12 +0000 Received: from DB5PR08MB0664.eurprd08.prod.outlook.com (10.152.18.52) by VE1EUR03FT045.mail.protection.outlook.com (10.152.19.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5 via Frontend Transport; Thu, 27 Oct 2016 16:57:11 +0000 Received: from DB5PR08MB0664.eurprd08.prod.outlook.com ([10.169.33.14]) by DB5PR08MB0664.eurprd08.prod.outlook.com ([10.169.33.14]) with mapi id 15.01.0693.009; Thu, 27 Oct 2016 16:57:11 +0000 From: "D. E" To: "freebsd-current@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: DeLock 10x SATA AHCI controller not working properly Thread-Topic: DeLock 10x SATA AHCI controller not working properly Thread-Index: AQHSMHCviPHyPq4yz0a1wHBT6JyVeQ== Date: Thu, 27 Oct 2016 16:57:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=hotmail.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [p/jfwkVuh8J6eZHDupn/Ii5/64W351Kr] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; VE1EUR03HT012; 6:2tVW1ZtOScBiOMoOCE2ZGaFZwEd/A7APw2+akrxZak01Mfh968+GSVOrtntZq47/pr23ID2vlcjAnLJp00irGxueWEMA4QEV4jj8k24+xbWsn+DJIcmNUl4C/CcsMAgNWrRORdIKFO1UB6x+0mA4lkUUmOcLY+6zgvbcYsQaEzS0C+e0V07rcjZKUQDzLSL11zslwXA9jY9/dBN6slnUuw/nBCM3V7Zme+3lcbpH6nQYHPv4WFiDj3wRclN8ZgTKyjJbXiliQCZQKpnNxkIjrFjLNcQpgy/bl92HJThHzpUxtBvQJLSGfYo4qfMZmdS7; 5:N5M/PSXHJsk/T50SjQsIiSgDZ62F5CptbZGEEkz6JHRNV4xEFZIKB3rLVTFPOLdJf1gY5F2KwCQVHW5CXas9jaqKemB4O1rzH4cqURFoy23YiD4Xkbs3TWRWskAUZAzR8UQqinGt7NeP6VCjTNzK1g==; 24:m7AQo1z5QS/Z8mxkiieweRIKgZdolhqJDDvwNjE43mTm/tmrVe9+I90SGPIVd79Wy01tESwWjWDs0hC8AH+MAxR59PdeE/ZnqoHnSwyF+BM=; 7:KpdBxFlIVrgYSogjiz3RM7I1LJkuowjtTA0zASfH6GhSMKaRCUHAVglVCce98m8AbxLRwwztgXMyyXQAjl47YZZXxK2//I+es4KwEfqkM778wEQ+aZMnfi4JwdxGx1qwwY3RTGcyDv50k36PNNwFQzv9cXcs7loqSQCcmU5FvkB8zXPZ9xLq8hnVm7m7J0uhlSNUO6WIuVzYTBqo05pBaqIpBq/+oR/YofQQOU1/ymW/UEEEzi0OwMZMsbVRPF30x9rsS0VMF2cBvkDq3dpwfIroyu8bVBy6o2S14mtevtifZiaqYPbtU3XPZG8wjhPKO+tG0Dh1g1nkvs+xd4TYz4s31x2ntWkmKluf+PyWN8I= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1EUR03HT012; H:DB5PR08MB0664.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: da53c847-c1a2-4c16-8513-08d3fe8a4b98 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:VE1EUR03HT012; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:VE1EUR03HT012; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR03HT012; x-forefront-prvs: 0108A997B2 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 16:57:11.5679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR03HT012 X-OriginalArrivalTime: 27 Oct 2016 16:57:15.0428 (UTC) FILETIME=[2B607640:01D23073] X-Mailman-Approved-At: Thu, 27 Oct 2016 18:14:18 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 16:58:20 -0000 Dear list, I hope you guys can help me with my new AHCI controller that doesn't work w= ell with FreeBSD yet. *** Introduction I have bought this very neat $80 SATA AHCI controller: http://www.delock.co= m/produkte/G_89384/merkmale.html This controller is PCI-express 2.0 with 2 lanes, so 1GB/s bandwidth shared = across 10 ports. For just $80 this is a great deal! It is also VERY power e= fficient, unlike SAS adapters which can use up to 8W when doing nothing. Th= e controller itself it a 2-port Asmedia AHCI SATA controller with two port = multipliers on it. Thus, each 5 ports are sharing one SATA/600 link. It pus= hes beyond 900MB/s when fully utilised. The controller is detected by FreeBSD 11.0-RELEASE-p1 amd64 as a regular AH= CI controller. It appears to work, in that it detects the disks that are co= nnected to it and it can do I/O. *** The problem This controller generates various I/O errors and timeouts. But only in spec= ific circumstances, where I think that NCQ or simultaneous access is a fact= or. Because when i start a simple dd read command for each harddrive connec= ted to the controller, there are no errors or timeouts in the dmesg. But wh= en importing a pool, creating a pool or scrubbing a pool that is empty, tim= eouts and I/O errors are 100% reproducable in just a few seconds. This is a= fter dd commands have been running for hours straight without any hickup. In other words, I believe this controller needs some kind of quirk. The con= troller is reported to be working properly on Linux. *** What I already tried I tried disabling MSI and MSI-X interrupts. I tried disabling NCQ although = with limited effect: ZFS can be tuned to use one outstanding I/O, but I sti= ll got errors now and then. Is there any way of doing some easy quirks to localize the problem and also= get this controller working reliably, albeit slower? *** Example errors when working with ZFS: ahcich7: Timeout on slot 23 port 0 ahcich7: is 00000000 cs 00000000 ss 00000000 rs 00800000 tfd 50 serr 000000= 00 cmd 0004cf17 (ada9:ahcich7:0:0:0): READ_DMA. ACB: c8 00 00 ff 02 40 00 00 00 00 00 00 (ada9:ahcich7:0:0:0): CAM status: Command timeout (ada9:ahcich7:0:0:0): Retrying command ahcich17: Timeout on slot 30 port 0 ahcich17: is 00000000 cs 00000000 ss 00000000 rs 40000000 tfd 50 serr 00000= 000 cmd 0004c317 (aprobe0:ahcich17:0:0:0): SETFEATURES SET TRANSFER MODE. ACB: ef 03 00 00 0= 0 40 00 00 00 00 46 00 (aprobe0:ahcich17:0:0:0): CAM status: Command timeout (aprobe0:ahcich17:0:0:0): Retrying command *** Detection logs: # pciconf -lv ahci1@pci0:4:0:0: class=3D0x010601 card=3D0x10601b21 chip=3D0x06251b21 rev= =3D0x01 hdr=3D0x00 vendor =3D 'ASMedia Technology Inc.' class =3D mass storage subclass =3D SATA # dmesg pci4: on pcib4 ahci1: mem 0xfdafe000-0xfdafffff irq 16 at device 0.= 0 on pci4 ahci1: AHCI v1.31 with 12 6Gbps ports, Port Multiplier not supported ahcich6: at channel 0 on ahci1 ahcich7: at channel 1 on ahci1 ahcich10: at channel 4 on ahci1 ahcich11: at channel 5 on ahci1 ahcich12: at channel 6 on ahci1 ahcich13: at channel 7 on ahci1 ahcich14: at channel 8 on ahci1 ahcich15: at channel 9 on ahci1 ahcich16: at channel 10 on ahci1 ahcich17: at channel 11 on ahci1 # devinfo -r pci4 pcib4 bus numbers: 4 ahci1 Interrupt request lines: 0x109 pcib4 memory window: 0xfdafe000-0xfdafffff ahcich6 I/O memory addresses: 0xfdafe100-0xfdafe17f ahcich7 I/O memory addresses: 0xfdafe180-0xfdafe1ff ahcich10 I/O memory addresses: 0xfdafe300-0xfdafe37f ahcich11 I/O memory addresses: 0xfdafe380-0xfdafe3ff ahcich12 I/O memory addresses: 0xfdafe400-0xfdafe47f ahcich13 I/O memory addresses: 0xfdafe480-0xfdafe4ff ahcich14 I/O memory addresses: 0xfdafe500-0xfdafe57f ahcich15 I/O memory addresses: 0xfdafe580-0xfdafe5ff ahcich16 I/O memory addresses: 0xfdafe600-0xfdafe67f ahcich17 I/O memory addresses: 0xfdafe680-0xfdafe6ff PS. please click 'Reply All' when replying, since I am not subscribed to th= e list, meaning that I cannot easily reply on your reply unless you also se= nd it to my email directly, using 'Reply All'. Thanks!= From owner-freebsd-current@freebsd.org Thu Oct 27 17:39:31 2016 Return-Path: Delivered-To: freebsd-current@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 1F66AC24CF8 for ; Thu, 27 Oct 2016 17:39:31 +0000 (UTC) (envelope-from cipher_nl@hotmail.com) Received: from COL004-OMC4S15.hotmail.com (col004-omc4s15.hotmail.com [65.55.34.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC2EC837 for ; Thu, 27 Oct 2016 17:39:30 +0000 (UTC) (envelope-from cipher_nl@hotmail.com) Received: from EUR02-AM5-obe.outbound.protection.outlook.com ([65.55.34.201]) by COL004-OMC4S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 27 Oct 2016 10:38:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M4vO0ysqzRJrYl7Gyfwjl1Dlw9mwOeFlpnKfC4QbHRw=; b=CyIkdWhrY0SrcKsQ4qznxTMDYW0Ik3k4fZsbw6j68NFbZc83nbw2yFEQy5+W7MCMb92nNgR2BjN6TReWqsJ4krk3vP0aMlYoQYrZKob3z3l7gzdY2Z5LBsXMsgdj5yXKZFz05dMFpcqSsMFh6lHMg/qEQK+uoOnICIe2X9fN4OfKTblJstdmInb2qstRsnNec7XB75wb0b4X8+gMmfrM7J6y1wPtkJacEGVJ9TaK34482XWpFiPth4Lx73DERga2g1FtdCnxWatMwdlUrvSi8XQnjbHAYKvexf1595kKwTNM8A3nnSvJUv2GHT8kDYdzQPOY/oUiFD8eEPd2zWOaFw== Received: from VE1EUR02FT046.eop-EUR02.prod.protection.outlook.com (10.152.12.51) by VE1EUR02HT094.eop-EUR02.prod.protection.outlook.com (10.152.12.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 17:38:21 +0000 Received: from DB5PR08MB0664.eurprd08.prod.outlook.com (10.152.12.54) by VE1EUR02FT046.mail.protection.outlook.com (10.152.12.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5 via Frontend Transport; Thu, 27 Oct 2016 17:38:21 +0000 Received: from DB5PR08MB0664.eurprd08.prod.outlook.com ([10.169.33.14]) by DB5PR08MB0664.eurprd08.prod.outlook.com ([10.169.33.14]) with mapi id 15.01.0693.009; Thu, 27 Oct 2016 17:38:21 +0000 From: "D. E" To: "freebsd-current@freebsd.org" Subject: DeLock 10x SATA AHCI controller not working properly Thread-Topic: DeLock 10x SATA AHCI controller not working properly Thread-Index: AQHSMHi2h1QoeoJ6dUiYUf0D2GT3oQ== Date: Thu, 27 Oct 2016 17:38:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=hotmail.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [R/Gj1AYaQ1PNjBwHBOCyCxYy8Je2731n] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; VE1EUR02HT094; 6:HhTytqft+a6pzBfdcQYiQQ/y9sAbCdvUfn3n+CCTS4yLj0KP9xO4Vt9b6k47CBBytx0p7ZKsuxfO6x22m8d4/e/TPEVWOeAcGgYH79nw5K+KfQUQA4LkWJyx4TeNanq5GV1PsuswDoeayM7KisrQu7voRrdTJE8N9/WbTDVifT30rO5mFsIovKjzBFd9ZcOGx8f48xbUCndDFyXU7c/HeOcGbirv1tgXpMMNUPTvqeAA7z1MRv9xm+EF/RjT/mDB3GpTmKn0tv72tXN8hLVdfYMSYNKyOzC9xvvqOGFmkXog9S/lrU5b1FlTN0YK13v7; 5:8ku8ascntqy3iRz301wdx8IS9xSOFrsoJFNjUnAGp80ER6RgfII7y70C2UgtcYf+i5ry3Ltd3IAsfRrk4nMRYBXTzvKjpC8o6k99uQtehbwuHR1vPeWHWu2KhVCeX5E5/QHjtSvwJrPsXzGFts4YVw==; 24:9SpS+6Akb8qt0+ePx7a+ZlhYCcHPTqcq75GYNiXSB7fz2M2LdCKzkAPFvr9N6L2HXZX/kcnxyOG9sWPo0GF2jnlvWkOOkduEty2CqIL5XPQ=; 7:yjdWoMG9vRAbl/BCrkJ5J3/mS1eBONBgho0Q6ROwkiF9x1WmLzIkp+xBjXMyXGAxSi0a7RcJMdz2zpyR4jZaIXfylf7vvgflqhnvk66CNpL0ks4gXd+cd2F5oZENEcnA7PQIPnmAhnCEHngMHPPcUJdBw3HR+iFsBUKI42d8ty5WSbwMdTh4C2T69IMMAbp6HipmKlNN0LLIHhPiI4uTjxaSf8lj0qhYOjDfTaifKac7a76NwsCaWl6wrmrQXdaTwve969iRkuPRQ35Gj8GflvADC1Db71qphK36j2HNgP3gJiH79uXMkoigIi2cc/Dr7NO0pI3ZjKegp85B4W+VwlzQHz232ou2pMLEVO5k07k= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1EUR02HT094; H:DB5PR08MB0664.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 5ecad9fb-08c2-4585-7bdb-08d3fe900bd1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:VE1EUR02HT094; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:VE1EUR02HT094; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR02HT094; x-forefront-prvs: 0108A997B2 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 17:38:21.5094 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT094 X-OriginalArrivalTime: 27 Oct 2016 17:38:24.0085 (UTC) FILETIME=[EACFA050:01D23078] X-Mailman-Approved-At: Thu, 27 Oct 2016 18:15:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 17:39:31 -0000 Dear list, I hope you guys can help me with my new AHCI controller that doesn't work w= ell with FreeBSD yet. *** Introduction I have bought this very neat $80 SATA AHCI controller: http://www.delock.co= m/produkte/G_89384/merkmale.html This controller is PCI-express 2.0 with 2 lanes, so 1GB/s bandwidth shared = across 10 ports. For just $80 this is a great deal! It is also VERY power e= fficient, unlike SAS adapters which can use up to 8W when doing nothing. Th= e controller itself it a 2-port Asmedia AHCI SATA controller with two port = multipliers on it. Thus, each 5 ports are sharing one SATA/600 link. It pus= hes beyond 900MB/s when fully utilised. The controller is detected by FreeBSD 11.0-RELEASE-p1 amd64 as a regular AH= CI controller. It appears to work, in that it detects the disks that are co= nnected to it and it can do I/O. *** The problem This controller generates various I/O errors and timeouts. But only in spec= ific circumstances, where I think that NCQ or simultaneous access is a fact= or. Because when i start a simple dd read command for each harddrive connec= ted to the controller, there are no errors or timeouts in the dmesg. But wh= en importing a pool, creating a pool or scrubbing a pool that is empty, tim= eouts and I/O errors are 100% reproducable in just a few seconds. This is a= fter dd commands have been running for hours straight without any hickup. In other words, I believe this controller needs some kind of quirk. The con= troller is reported to be working properly on Linux. *** What I already tried I tried disabling MSI and MSI-X interrupts. I tried disabling NCQ although = with limited effect: ZFS can be tuned to use one outstanding I/O, but I sti= ll got errors now and then. Is there any way of doing some easy quirks to localize the problem and also= get this controller working reliably, albeit slower? *** Example errors when working with ZFS: ahcich7: Timeout on slot 23 port 0 ahcich7: is 00000000 cs 00000000 ss 00000000 rs 00800000 tfd 50 serr 000000= 00 cmd 0004cf17 (ada9:ahcich7:0:0:0): READ_DMA. ACB: c8 00 00 ff 02 40 00 00 00 00 00 00 (ada9:ahcich7:0:0:0): CAM status: Command timeout (ada9:ahcich7:0:0:0): Retrying command ahcich17: Timeout on slot 30 port 0 ahcich17: is 00000000 cs 00000000 ss 00000000 rs 40000000 tfd 50 serr 00000= 000 cmd 0004c317 (aprobe0:ahcich17:0:0:0): SETFEATURES SET TRANSFER MODE. ACB: ef 03 00 00 0= 0 40 00 00 00 00 46 00 (aprobe0:ahcich17:0:0:0): CAM status: Command timeout (aprobe0:ahcich17:0:0:0): Retrying command *** Detection logs: # pciconf -lv ahci1@pci0:4:0:0: class=3D0x010601 card=3D0x10601b21 chip=3D0x06251b2= 1 rev=3D0x01 hdr=3D0x00 vendor =3D 'ASMedia Technology Inc.' class =3D mass storage subclass =3D SATA # dmesg pci4: on pcib4 ahci1: mem 0xfdafe000-0xfdafffff irq 16 at device 0.= 0 on pci4 ahci1: AHCI v1.31 with 12 6Gbps ports, Port Multiplier not supported ahcich6: at channel 0 on ahci1 ahcich7: at channel 1 on ahci1 ahcich10: at channel 4 on ahci1 ahcich11: at channel 5 on ahci1 ahcich12: at channel 6 on ahci1 ahcich13: at channel 7 on ahci1 ahcich14: at channel 8 on ahci1 ahcich15: at channel 9 on ahci1 ahcich16: at channel 10 on ahci1 ahcich17: at channel 11 on ahci1 # devinfo -r pci4 pcib4 bus numbers: 4 ahci1 Interrupt request lines: 0x109 pcib4 memory window: 0xfdafe000-0xfdafffff ahcich6 I/O memory addresses: 0xfdafe100-0xfdafe17f ahcich7 I/O memory addresses: 0xfdafe180-0xfdafe1ff ahcich10 I/O memory addresses: 0xfdafe300-0xfdafe37f ahcich11 I/O memory addresses: 0xfdafe380-0xfdafe3ff ahcich12 I/O memory addresses: 0xfdafe400-0xfdafe47f ahcich13 I/O memory addresses: 0xfdafe480-0xfdafe4ff ahcich14 I/O memory addresses: 0xfdafe500-0xfdafe57f ahcich15 I/O memory addresses: 0xfdafe580-0xfdafe5ff ahcich16 I/O memory addresses: 0xfdafe600-0xfdafe67f ahcich17 I/O memory addresses: 0xfdafe680-0xfdafe6ff PS. please click 'Reply All' when replying, since I am not subscribed to th= e list, meaning that I cannot easily reply on your reply unless you also se= nd it to my email directly, using 'Reply All'. Thanks!= From owner-freebsd-current@freebsd.org Thu Oct 27 19:52:53 2016 Return-Path: Delivered-To: freebsd-current@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 35255C23D00 for ; Thu, 27 Oct 2016 19:52:53 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 E929B251 for ; Thu, 27 Oct 2016 19:52:52 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bzqjD-000irM-OG>; Thu, 27 Oct 2016 21:52:43 +0200 Received: from x5ce12cdc.dyn.telefonica.de ([92.225.44.220] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bzqjD-000LCT-Dl>; Thu, 27 Oct 2016 21:52:43 +0200 Date: Thu, 27 Oct 2016 21:52:38 +0200 From: "O. Hartmann" To: YongHyeon PYUN Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161027215238.49c1a037.ohartman@zedat.fu-berlin.de> In-Reply-To: <20161027010004.GA1215@michelle.fasterthan.co.kr> References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> <20161025070338.76ad6711@hermann> <20161027010004.GA1215@michelle.fasterthan.co.kr> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/NTHGmNAIAXvTVoCf1yM/1El"; protocol="application/pgp-signature" X-Originating-IP: 92.225.44.220 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 19:52:53 -0000 --Sig_/NTHGmNAIAXvTVoCf1yM/1El Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 27 Oct 2016 10:00:04 +0900 YongHyeon PYUN schrieb: > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote: > > On Tue, 25 Oct 2016 11:05:38 +0900 > > YongHyeon PYUN wrote: > > =20 >=20 > [...] >=20 > > > I'm not sure but it's likely the issue is related with EEE/Green > > > Ethernet handling. EEE is negotiated feature with link partner. If > > > you directly connect your laptop to non-EEE capable link partner > > > like other re(4) box without switches you may be able to tell > > > whether the issue is EEE/Green Ethernet related one or not. =20 > >=20 > > Me either since when I discovered a problem the first time with > > CURRENT, that was the Friday before last week's Friday, there was a > > unlucky coicidence: I got the new switch, FreeBSD introduced a serious > > bug and I changed the NICs. > >=20 > > The laptop, the last in the row of re(4) equipted systems on which I > > use the Realtek NIC, does well now with Green IT technology, but > > crashes on plugging/unplugging - not on each event, but at least in one > > of ten. =20 >=20 > Hmm, it seems you know how to trigger the issue. When you unplug > UTP cable was there active network traffic on re(4) device? > It would be helpful to know which event triggers the crash(e.g. > unplugging or plugging). And would you show me backtrace of panic? Yes, as I wrote, plugging and unplugging. Usually, there is no traffic I'm = aware of, simply the - a hunch - attempt to renegotiate the connection triggers the c= rash. As I can force by bringing up and down the port on the switch. Of course you can get a panic/backtrace, but I need the weekend. I complai= ned in another thread about the inability of getting a core - I use ELI encrypt= ed swap, so I shot myself at that point. >=20 > > I guess the Green IT issue is more a unlucky guess of mine and went > > hand in hand with the problem I face with CURRENT right now on some > > older, Non UEFI machines. > > =20 >=20 > Ok. >=20 > [...] > >=20 > > As requested the informations about re0 and rgephy0 on the laptop > > (Lenovo E540)=20 > >=20 > > [...] > >=20 > > rgephy0: PHY 1 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, > > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > >=20 > > re0: port > > 0x3000-0x30ff mem 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff at device > > 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled > > re0: Chip rev. 0x50800000 > > re0: MAC rev. 0x00100000 =20 >=20 > This looks like 8168GU controller. >=20 > [...] >=20 > > I use options netmap in kernel config, but the problem is also present > > without this option - just for the record. > > =20 >=20 > Yup, netmap(4) has nothing to do with the crash. >=20 > Thanks. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Sig_/NTHGmNAIAXvTVoCf1yM/1El Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYElsGAAoJEOgBcD7A/5N8pw8H/1uNdTn79FsV8THnUXoP2llw dzJtY4klCOsrYZW1dZceLWebJ6TYmOfeOwWxsEq1jq8287VAWan9TqJLdGBoDmhT hMzdI95RYIqkKr9bcRN+9CDB8I+/x0KcfZla+8LXG2doIBrgp6F92fI8wnwqivCC bNTTEqAhAOGfsE4ajFHNaw3yfHFyUrYBR2M2TxeCMt/afLj259KvFeYt2AxWD/iA RA9a17ctjcW1SaCu8lkg/aakWxmZ4upUoxf8MxL8ojMJxGagec3Au2/NQLuUcrnz 62nhLQEujabnV9vxaOVX160yggTsI0l3BJ49LjfAFptsRaWFgdxKZRcW7kA4M0E= =dl83 -----END PGP SIGNATURE----- --Sig_/NTHGmNAIAXvTVoCf1yM/1El-- From owner-freebsd-current@freebsd.org Thu Oct 27 20:13:52 2016 Return-Path: Delivered-To: freebsd-current@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 85F31C22277 for ; Thu, 27 Oct 2016 20:13:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 D9D3AE2A; Thu, 27 Oct 2016 20:13:51 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id b75so41109004lfg.3; Thu, 27 Oct 2016 13:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=hcquva6Jx7g8aGLeMG4sM7j5EiQLk33ybXh0WkoolYE=; b=qJxKCUzsJrZ1MPqcNrei+HcBkxjItUdWO8o8gKECcKTH9HHDzmsqD/3u5SjmgX4CIh OszRSNA2j26ReEy8Bh7EHXwxEMwrtll05g5JatEkhLPEZDIbCIJNdachuML6ygWslkfP aGTyx8kY9N08YFiOTTqo8mBFUDf/55UgVetedbo66dLvgPyTkTdwutWcf1ZobijCXteH +3zLkHcW7p4GES3N/FBIpP0OAuRVmUDsRVPb1rnq35O6EUSo7bkekDmR8w9S6egLOaIs Jc2+7sI30L96Be650G8o6XRr/UevX4t7YyS5biMOLhHrENPWghSk3tPwrClkPCxcE8HF UYWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=hcquva6Jx7g8aGLeMG4sM7j5EiQLk33ybXh0WkoolYE=; b=IgmkmkIqTdiqx47GynGVBUEx5H5c1zAj8NG1izqFDgfEw8EgZVmnYU9EfTiWBZ8yf7 7sJjmDS45pxGCYWyI9mxRsLOy7hUXapkU0LyDJHDC6k18sM+100l4Gd5c6yzn0eualoj CtpIiXog+ZA+d/SvISTjh7QDr4mXcUCIfB/uv7/epe3PJTrPnXBccV5mtCgcW1WabTa5 3dI+lxQvr1+gnL8MBX6HLehNRvviK74OtWOF4VNLNQHi+g1CX/ybxlVyjNXKOEGPKpjD Rnv/JW39kR3gyikOyyozXgYjPjOfjaI3lXCCr5TOg1wIcOd6Co81r25yAPGSA3LV3RQY ZQUQ== X-Gm-Message-State: ABUngvfTSl9JRO0XYeh6dt7ulhlzyZWZaeAMIAoKQpDSXgWdhMdv5ggVzZDKjtTxmBqllWBKyRywAsJGsS+WZQ== X-Received: by 10.25.28.70 with SMTP id c67mr7541767lfc.93.1477599229220; Thu, 27 Oct 2016 13:13:49 -0700 (PDT) MIME-Version: 1.0 Sender: uspoerlein@gmail.com Received: by 10.25.190.205 with HTTP; Thu, 27 Oct 2016 13:13:48 -0700 (PDT) In-Reply-To: References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> <20161024174327.GB2734@acme.spoerlein.net> <20161026164343.GC2734@acme.spoerlein.net> <20161026164518.GD2734@acme.spoerlein.net> From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Thu, 27 Oct 2016 22:13:48 +0200 X-Google-Sender-Auth: qjDuFldbZwoU210-vmHjtz1FZTs Message-ID: Subject: Re: 11.x deadlocking during pfault (was Re: FreeBSD 11.x grinds to a halt after about 48h of uptime) To: Daniel Nebdal Cc: Kevin Oberman , kib@freebsd.org, Hans Petter Selasky , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 20:13:52 -0000 2016-10-27 14:51 GMT+02:00 Daniel Nebdal : > > On Wed, Oct 26, 2016 at 6:45 PM, Ulrich Sp=C3=B6rlein w= rote: > > > > On Wed, 2016-10-26 at 18:43:43 +0200, Ulrich Sp=C3=B6rlein wrote: > > > On Mon, 2016-10-24 at 19:43:27 +0200, Ulrich Sp=C3=B6rlein wrote: > > > > On Sat, 2016-10-15 at 09:36:27 -0700, Kevin Oberman wrote: > > > > > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > > > > > wrote: > > > > > > > > > > > On 10/15/16 18:18, Ulrich Sp=C3=B6rlein wrote: > > > > > > > > > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine= ever > > > > > >> since I upgraded it to 11-CURRENT years ago. I have no idea wh= en this > > > > > >> started, actually, but what always happens is this: > > > > > >> > > > > > >> - System and X11 is up and running, I keep it running over nig= ht as I'm > > > > > >> too lazy to reboot and restart everthing. > > > > > >> - There's a bunch of xterms, Chrome, Clementine-Player and som= e other > > > > > >> programs running > > > > > >> - Coming back to the machine the next day (or the day after) i= t will > > > > > >> exit the screensaver just fine and then either I can use it fo= r a couple > > > > > >> of seconds before it freezes, or it's pretty much dead already= . The > > > > > >> mouse cursor still moves for a bit, but the also freezes (so i= t this a > > > > > >> GPU problem??) > > > > > >> > > > > > >> Now what I currently see on the screen is a clock widget stuck= at 18:04 > > > > > >> but conky itself has last updated at 18:00:18 ... > > > > > >> > > > > > >> This time I had some SSH sessions from another machine to see = some more > > > > > >> useful things. There was nothing in various logs under /var/lo= g (I also > > > > > >> can't run dmesg anymore ...) > > > > > >> I had top(1) running in a loop, this is the last output: > > > > > >> > > > > > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:= 03:28 > > > > > >> 18:00:12 > > > > > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > > > > > >> > > > > > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Fr= ee > > > > > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 10= 12M Other > > > > > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > > > > > >> > > > > > >> > > > > > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIM= E WCPU > > > > > >> COMMAND > > > > > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6= H 772.95% > > > > > >> idle > > > > > >> 3122 uqs 15 28 0 7113M 5861M uwa= it 0 > > > > > >> 94:44 13.96% chrome > > > > > >> 2887 uqs 28 22 0 13= 94M 237M > > > > > >> select 2 172:53 6.98% chrome > > > > > >> 2890 uqs 11 = 21 0 > > > > > >> 1034M 178M select 5 231:21 1.95% chrome > > > > > >> 1062 root = 9 > > > > > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > > > > > >> 3= 002 uqs > > > > > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrom= e > > > > > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:1= 5 0.00% > > > > > >> chrome > > > > > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:0= 5 0.00% > > > > > >> chrome > > > > > >> 12 root 24 -64 - 0K 384K WAIT -1 10:5= 3 0.00% > > > > > >> intr > > > > > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:3= 6 0.00% > > > > > >> chrome > > > > > >> 2822 uqs 9 20 0 217M 81300K select 0 5:1= 0 0.00% > > > > > >> conky > > > > > >> 3174 root 1 20 0 21532K 3188K select 0 4:2= 0 0.00% > > > > > >> systat > > > > > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:0= 3 0.00% > > > > > >> chrome > > > > > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:5= 3 0.00% > > > > > >> chrome > > > > > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:5= 2 0.00% > > > > > >> chrome > > > > > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:4= 6 0.00% > > > > > >> chrome > > > > > >> 2876 uqs 19 20 0 580M 37164K select 3 2:4= 2 0.00% > > > > > >> clementine-player > > > > > >> 20 root 2 -16 - 0K 32K psleep 6 2:2= 5 0.00% > > > > > >> pagedaemon > > > > > >> > > > > > >> I also had systat -vm running and it continued to update its s= creen ... > > > > > >> for a short while, this is the last update before SSH died: > > > > > >> > > > > > >> > > > > > >> Mem usage: 0k%Phy 5%Kmem > > > > > >> Mem: KB REAL VIRTUAL VN PAG= ER SWAP > > > > > >> PAGER > > > > > >> Tot Share Tot Share Free in o= ut in > > > > > >> out > > > > > >> Act 11051k 67868 71051992 255448 61840 count > > > > > >> All 11051k 67924 71058776 262100 pages > > > > > >> Proc: > > > > > >> Interrupts > > > > > >> r p d s w Csw Trp Sys Int Sof Flt iofl= t 224 > > > > > >> total > > > > > >> 25 730 11 724 109 404 101 13 cow = 2 > > > > > >> ehci0 16 > > > > > >> zfod= 3 > > > > > >> ehci1 23 > > > > > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfo= d 16 > > > > > >> cpu0:timer > > > > > >> | | | | | | | | | | %ozfo= d > > > > > >> xhci0 264 > > > > > >> daef= r 3 em0 > > > > > >> 265 > > > > > >> 50 dtbuf prcf= r 94 > > > > > >> hdac1 266 > > > > > >> Namei Name-cache Dir-cache 349167 desvn totf= r > > > > > >> ahci0 270 > > > > > >> Calls hits % hits % 349155 numvn reac= t 5 > > > > > >> cpu1:timer > > > > > >> 121 121 100 253501 frevn pdwa= k 1 > > > > > >> cpu2:timer > > > > > >> pdpg= s 29 > > > > > >> cpu7:timer > > > > > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intr= n 12 > > > > > >> cpu3:timer > > > > > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire= 41 > > > > > >> cpu6:timer > > > > > >> tps 0 0 0 0 0 0 9261404 act = 12 > > > > > >> cpu5:timer > > > > > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inac= t 6 > > > > > >> cpu4:timer > > > > > >> %busy 0 0 0 0 0 0 cach= e > > > > > >> vgapci0 > > > > > >> 61840 free > > > > > >> 712304 buf > > > > > >> > > > > > >> > > > > > >> Why do I have a Chrome tab using about 6G? What other sort of = debugging > > > > > >> output can be helpful to get to the bottom of this? The machin= e still > > > > > >> responds to pings just fine, TCP connections get set up but th= e SSH > > > > > >> handshake never completes. > > > > > >> > > > > > >> This always happens between 30-50h and is super annoying and h= as been > > > > > >> going on for >1year. Help? > > > > > >> > > > > > >> Note, I cut the power to the monitor overnight to save electri= city, can > > > > > >> this mess up something in the Radeon card or X server? What co= mbinations > > > > > >> would be most useful to try next? > > > > > >> > > > > > >> > > > > > > Hi, > > > > > > > > > > > > Sounds like a memory leak. Can you track the memory use over ti= me? > > > > > > > > > > > > Did you look at the output from: > > > > > > > > > > > > vmstat -m ? > > > > > > > > > > > > --HPS > > > > > > > > > > > > > > > I have noted significant memory leakage in chromium for some tim= e. If I > > > > > leave it running overnight, my system is essentially frozen. If I= terminate > > > > > the chromium process, it slowly comes back to life. I always keep= a gkrellm > > > > > session on-screen where the memory and swap utilization is contin= uously > > > > > displayed and that clearly shows resources declining. > > > > > > > > That is not what is happening to my system though, it actually > > > > deadlocks. There's no way to recover from it, it seems. > > > > > > > > So I killed Chromium overnight each day, and I'm at this: > > > > > > > > % top -Sbores > > > > last pid: 44526; load averages: 0.10, 0.11, 0.56 up 7+09:53:30= 19:33:25 > > > > 156 processes: 2 running, 153 sleeping, 1 waiting > > > > > > > > Mem: 315M Active, 550M Inact, 5671M Wired, 515M Buf, 9324M Free > > > > ARC: 1852M Total, 541M MFU, 196M MRU, 16K Anon, 93M Header, 1022M O= ther > > > > Swap: 4096M Total, 2186M Used, 1910M Free, 53% Inuse > > > > > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME = WCPU COMMAND > > > > 2755 uqs 10 20 0 1697M 311M select 1 47:23 0= .00% conky > > > > 2736 uqs 32 20 0 699M 116M select 7 94:29 0= .00% clementine-player > > > > 3000 uqs 12 20 0 1126M 69380K select 5 9:48 0= .00% digikam > > > > 960 root 9 20 0 448M 59076K select 0 250:22 0= .00% Xorg > > > > 72608 uqs 8 20 0 939M 55432K uwait 5 0:01 0= .00% chrome > > > > 72599 uqs 9 52 0 929M 55116K uwait 0 0:00 0= .00% chrome > > > > 2567 root 1 20 0 89948K 42964K select 1 1:51 0= .00% bsnmpd > > > > 70476 uqs 1 20 0 93656K 25712K select 2 0:05 0= .00% xterm > > > > 2730 uqs 5 20 0 208M 14988K select 1 0:22 0= .00% clock-applet > > > > 880 root 1 20 0 22628K 12500K select 3 0:20 0= .00% ntpd > > > > 2726 uqs 4 20 0 206M 12456K select 6 0:09 0= .00% mateweather-applet > > > > 44352 uqs 1 20 0 75224K 12348K select 4 0:00 0= .00% xterm > > > > 43049 uqs 1 20 0 75224K 11792K select 5 0:00 0= .00% xterm > > > > 3074 uqs 2 20 0 308M 9692K select 1 0:02 0= .00% kdeinit4 > > > > 2671 uqs 1 20 0 144M 9488K select 1 0:13 0= .00% openbox > > > > 3072 uqs 1 20 0 210M 8284K select 3 0:00 0= .00% kdeinit4 > > > > 2724 uqs 4 20 0 154M 8256K select 2 0:19 0= .00% wnck-applet > > > > 2701 uqs 5 20 0 177M 8144K select 2 0:01 0= .00% mate-panel > > > > > > > > > > > > 7d running, pretty good. But look closer, the system is doing prett= y > > > > much nothing but did swap out 2G. What? > > > > > > > > > Try closing your chromium at night and see if that fixes the prob= lem. > > > > > > > > It's better, but I'm not sure it's a real fix. I've now turned off > > > > "hardware acceleration" in Chromium, though chrome://gpu didn't rea= l > > > > inspire confidence that it was actually using any h/w accel at all. > > > > > > > > > > > > > If you have never tried gkrellm (sysutils/gkrellm2), it is a the = best > > > > > system monitor I have found. though pulls in a lot of dependencie= s. It also > > > > > can run as a server with remote systems displaying the data. Hand= y to > > > > > monitor servers. > > > > > > > > I had a cacti-setup that would also monitor my workstation (through= a > > > > OpenVPN tunnel), but that has bit-rotted and Apache only gives me 5= 00s > > > > on that cacti URL and nothing in the logs, oh well ...) > > > > > > > > Hooking up a serial console and testing whether DDB works is probab= ly > > > > the next best step to take ... > > > > > > Sigh, I forgot to shut down Chrome overnight, and my system is > > > deadlocked again. I can still switch virtual desktops in X11 and a > > > running xterm accepts keyboard input, but it is 18:35 now and I see t= hat > > > my X11 clock has last updated at 17:18 and conky is stuck at 17:14:11 > > > > > > my top-in-a-loop is stuck here and no longer loops: > > > > > > last pid: 73731; load averages: 0.23, 0.24, 0.23 up 9+07:34:15 = 17:14:10 > > > 160 processes: 3 running, 146 sleeping, 11 zombie > > > > > > Mem: 9302M Active, 763M Inact, 5682M Wired, 752M Buf, 113M Free > > > ARC: 1731M Total, 549M MFU, 129M MRU, 16K Anon, 91M Header, 963M Othe= r > > > Swap: > > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WC= PU COMMAND > > > 960 root 9 21 0 451M 55796K CPU7 7 299:15 2.9= 8% Xorg > > > 53884 uqs 27 22 0 904M 250M CPU4 4 105:05 2.9= 8% chrome > > > 54081 uqs 15 21 0 3601M 2527M uwait 6 38:11 0.9= 8% chrome > > > 2736 uqs 33 20 0 697M 84620K select 5 95:38 0.0= 0% clementine-player > > > 2755 uqs 10 20 0 2111M 721M select 0 60:47 0.0= 0% conky > > > 78943 uqs 1 20 0 21532K 3328K select 7 13:12 0.0= 0% systat > > > 54048 uqs 15 25 5 1093M 159M uwait 4 9:51 0.0= 0% chrome > > > 3000 uqs 12 20 0 1126M 53248K select 7 9:50 0.0= 0% digikam > > > 53999 uqs 19 25 5 1525M 514M uwait 5 6:28 0.0= 0% chrome > > > 2703 uqs 1 20 0 169M 5948K select 0 5:40 0.0= 0% mate-volume-control > > > 2707 uqs 1 20 0 60240K 2516K select 7 5:21 0.0= 0% autocutsel > > > 54077 uqs 15 20 0 1803M 821M uwait 6 3:51 0.0= 0% chrome > > > 78869 uqs 1 20 0 93480K 6636K select 7 3:38 0.0= 0% sshd > > > 38396 uqs 1 20 0 75224K 3896K select 0 3:18 0.0= 0% xterm > > > 2567 root 1 20 0 89948K 43892K select 6 2:25 0.0= 0% bsnmpd > > > 876 root 9 52 0 30120K 3468K uwait 7 2:20 0.0= 0% nscd > > > 883 root 1 20 0 10444K 1708K select 0 2:16 0.0= 0% powerd > > > 2586 haldaemon 2 20 0 56620K 3920K select 1 2:04 0.0= 0% hald > > > > > > > > > systat -vm: > > > > > > 10 users Load 0.21 0.23 0.23 Oct 26 17:14 > > > Mem usage: 0k%Phy 5%Kmem > > > Mem: KB REAL VIRTUAL VN PAGER SW= AP PAGER > > > Tot Share Tot Share Free in out = in out > > > Act 10545k 51036 67451248 249344 61912 count 120 3 > > > All 10550k 55504 67480212 275720 pages 807 3 > > > Proc: Inte= rrupts > > > r p d s w Csw Trp Sys Int Sof Flt 149 ioflt 845= total > > > 6 781 12 9327 6923 24k 318 18 6649 20 cow 2= ehci0 16 > > > 5064 zfod 3= ehci1 23 > > > 4.7%Sys 0.0%Intr 1.7%User 0.0%Nice 93.6%Idle 16 ozfod 106= cpu0:timer > > > | | | | | | | | | | %ozfod = xhci0 264 > > > =3D=3D> 927 daefr = 45 em0 265 > > > 51 dtbuf 545 prcfr 94= hdac1 266 > > > Namei Name-cache Dir-cache 349167 desvn 1787 totfr 175= ahci0 270 > > > Calls hits % hits % 337762 numvn react 50= cpu1:timer > > > 935 901 96 170078 frevn pdwak 48= cpu3:timer > > > 1435985 pdpgs 66= cpu2:timer > > > Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 77= cpu7:timer > > > KB/t 0.00 22.59 0.00 0.00 0.00 0.00 5819100 wire 75= cpu4:timer > > > tps 17 168 0 0 0 0 9723008 act 51= cpu6:timer > > > MB/s 0.00 3.70 0.00 0.00 0.00 0.00 636300 inact 53= cpu5:timer > > > %busy 0 3 0 0 0 0 cache = vgapci0 > > > 61912 free > > > 770732 buf > > > > > > > > > I'm unable to scroll back the vmstat -m output in my tmux pane (runni= ng on a > > > different system, this is super strange), so all I can show is this: > > > > > > > > > inodedep 16 12293K - 2770872 512 > > > bmsafemap 9 49K - 2136243 256,8192 > > > newblk 28 24582K - 4111401 256 > > > indirdep 4 1K - 865983 128,16384 > > > freefrag 6 1K - 682027 128 > > > freeblks 3 1K - 1318985 256 > > > freefile 3 1K - 1272832 64 > > > diradd 2 1K - 1306741 128 > > > mkdir 0 0K - 5120 128 > > > dirrem 0 0K - 1305358 128 > > > newdirblk 0 0K - 2610 64 > > > freework 9 1K - 1566489 64,128 > > > sbdep 0 0K - 45661 64 > > > savedino 0 0K - 186280 256 > > > softdep 6 3K - 6 512 > > > ufs_dirhash 1533 767K - 109513 16,32,64,128,256,512,102= 4,2048,4096 > > > ufs_quota 1 2048K - 1 > > > ufs_mount 18 55K - 18 512,2048,4096,8192 > > > vm_pgdata 1 2048K - 2 128 > > > UMAHash 23 5385K - 108 512,1024,2048,4096,8192,= 16384,32768,65536 > > > memdesc 1 4K - 1 4096 > > > atkbddev 2 1K - 2 64 > > > entropy 1 1K - 894489 32,4096 > > > apmdev 1 1K - 1 128 > > > madt_table 0 0K - 1 4096 > > > SCSI ENC 25 100K - 120744 16,64,256,2048,32768 > > > io_apic 1 2K - 1 2048 > > > MCA 18 3K - 18 64,128 > > > msi 16 2K - 16 128 > > > nexusdev 5 1K - 5 16 > > > hdaa 5 54K - 5 2048,16384,32768 > > > hdac 1 1K - 1 1024 > > > hdacc 1 1K - 1 32 > > > linux 29 2K - 29 64 > > > solaris 295750 228696K - 140520323 16,32,64,128,256,512,= 1024,2048,4096,8192,32768 > > > kstat_data 6 1K - 6 64 > > > eli data 22 4K - 6218901 64,256,512,1024,2048,409= 6,8192,16384,32768,65536 > > > ksem 1 8K - 1 8192 > > > nullfs_hash 1 2048K - 1 > > > nullfs_node 9 1K - 41 64 > > > nullfs_mount 9 1K - 9 32 > > > fdesc_mount 1 1K - 1 16 > > > gem_name 46 14K - 122 32,4096 > > > drm_global 2 1K - 2 128,256 > > > drm_dma 1 1K - 1 32 > > > drm_sarea 1 1K - 1 16 > > > drm_driver 91 2278K - 125 16,32,64,128,256,512,102= 4,2048,4096,8192,32768 > > > drm_minor 2 1K - 2 128 > > > drm_files 1 1K - 3 512 > > > drm_ctxbitmap 1 4K - 1 4096 > > > drm_sman 41 6K - 42 128 > > > drm_hashtab 3 4129K - 4 128,32768 > > > drm_kms 69 19K - 163 16,32,64,128,256,512,204= 8,4096,8192 > > > drm_vblank 7 1K - 7 32,256 > > > ttm_pd 16 17K - 18 16,128,2048,65536 > > > ttm_rman 2 1K - 2 256 > > > ttm_zone 2 1K - 2 64 > > > ttm_poolmgr 1 1K - 1 512 > > > > > > > > > Now what? > > > > > > The xterm I have running locally with a stuck top is showing the top = 3 chrome > > > processes in pfault state and it has "Swap: 11M In" in the header, so= clearly > > > 11.x is prone to deadlock during page faults and or swapping. It has = last > > > updated on 17:14:13 (compare to the other top at 17:14:10 not showing= pfault > > > state yet). > > > > Addendum: I still see the HDD indication light flickering every couple > > of seconds, so something is still doing I/O. My SSH sessions into the > > machine haven't time out, and the screensaver (just DPMS blank) is also > > still kicking in correctly. > > > > Just out of general interest, how is your swap set up? Is it on a zvol > or something exotic like that, or is it just a normal partition? Regular swap on a direct partition, no ZVOL involved. In fact, for *that* deadlock above, I ran "swapoff -a" before I left it overnight, to make sure that it's not the swap that is the problem. And a 2nd addendum: as it was still writing/reading from disk _somehow_, I pushed the power button to see if it would do the ACPI shutdown thing. It did! It took a while, but eventually the X server was killed and I saw it syncing the disk and then it did an orderly shutdown. Very strange, and I've been having this for a year or so. Always with a recent build, obviously. From owner-freebsd-current@freebsd.org Fri Oct 28 13:02:13 2016 Return-Path: Delivered-To: freebsd-current@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 8936DC2293A for ; Fri, 28 Oct 2016 13:02:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F2CD57FD for ; Fri, 28 Oct 2016 13:02:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07344 for ; Fri, 28 Oct 2016 16:02:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c06nT-000Elu-1S for freebsd-current@FreeBSD.org; Fri, 28 Oct 2016 16:02:11 +0300 Subject: Re: pmcstat -T -P instructions -t $pid ==> NMI To: FreeBSD Current References: <0479e273-1e86-13d0-ccd4-2fb6f57cff91@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Fri, 28 Oct 2016 16:01:14 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0479e273-1e86-13d0-ccd4-2fb6f57cff91@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:02:13 -0000 On 27/10/2016 16:20, Andriy Gapon wrote: > > I observe a problem on a relatively recent, but not the latest, head. > r306752 amd64 on AMD hardware. > If I run > pmcstat -T -P instructions -t $pid > with a pid of a busy userland process, then I shortly get a (stray) NMI. > Apparently hwpmc does not recognize that NMI. Because the problem was readily reproducible, I managed to gather some hwpmc debug traces. The following are last messages collected from a crash dump that I made after getting an NMI on CPU#0: index cpu timestamp trace ------ --- ---------------- ----- 97230 1 1089795818106 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97229 1 1089795792315 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97228 1 1089795767010 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97227 1 1089795741843 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97226 1 1089795716970 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97225 1 1089795691881 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97224 1 1089795666756 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97223 1 1089795641637 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97222 1 1089795616422 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97221 1 1089795590715 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97220 0 1089795590076 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 97219 1 1089795560493 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 97218 1 1089795520646 MDP:SWI:1: pc=0xfffff8002f355e00 pp=0xfffff80021f56400 enable-msr=0 97217 1 1089795519677 MDP:STA:2: amd-start config=0x5300c0 97216 1 1089795519420 MDP:STA:1: amd-start cpu=1 ri=0 97215 1 1089795518154 MDP:WRI:1: amd-write cpu=1 ri=0 v=ffffffffffff00fe 97214 1 1089795517311 CSW:SWI:1: cpu=1 ri=17 new=65282 97213 1 1089795514866 MDP:CFG:1: cpu=1 ri=0 pm=0xfffff8001c6e0500 97212 1 1089795510620 CSW:SWI:1: cpu=1 proc=0xfffff8013b1fe000 (1666, burnK7) pp=0xfffff80021f56400 97211 0 1089795494715 MDP:SWO:1: pc=0xfffff8001c6e0800 pp=0xfffff80021f56400 enable-msr=0 97210 0 1089795494448 MDP:CFG:1: cpu=0 ri=0 pm=0x0 97209 0 1089795494003 CSW:SWO:1: cpu=0 ri=17 tmp=-2839 (samp) 97208 0 1089795493811 MDP:REA:2: amd-read (post-munge) id=0 -> 65282 97207 0 1089795493644 MDP:REA:2: amd-read (pre-munge) id=0 -> 281474976645374 97206 0 1089795493299 MDP:REA:1: amd-read id=0 class=2 97205 0 1089795491453 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 97204 0 1089795490487 MDP:STO:1: amd-stop ri=0 97203 0 1089795489399 CSW:SWO:1: cpu=0 proc=0xfffff8013b1fe000 (1666, burnK7) pp=0xfffff80021f56400 97202 0 1089795460401 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 97201 0 1089795433574 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 97200 0 1089795371727 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 97199 0 1089795328556 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 97198 0 1089795303542 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 97197 0 1089795278288 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 97196 0 1089795253226 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 I think that what we see here is the target process being migrated from CPU#0 to CPU#1 and the corresponding reconfiguration of the performance counters on both CPUs. I interpret event #97220 to be the unclaimed NMI. Events #97204 and #97205 look curious. They seem like a possible "race" between amd_stop_pmc() and amd_intr(). As I understand, amd_stop_pmc() is called from the context switch code when the target process gets off CPU. I suspect that under the right conditions it's possible for wrmsr to cause a counter overflow, such that an interrupt (if enabled) is generated after wrmsr is executed, even if wrmsr disables the counter. In amd_intr() we have this code: wrmsr(evsel, config & ~AMD_PMC_ENABLE); wrmsr(perfctr, AMD_RELOAD_COUNT_TO_PERFCTR_VALUE(v)); /* Restart the counter if logging succeeded. */ error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, TRAPF_USERMODE(tf)); if (error == 0) wrmsr(evsel, config | AMD_PMC_ENABLE); I suspect that in the scenario above, if it is indeed possible, the last wrmsr would re-enable the counter that's supposed to be stopped. I think that writing back the original value should be more correct, that is: wrmsr(evsel, config); I'll test if this change would help. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Oct 28 13:51:44 2016 Return-Path: Delivered-To: freebsd-current@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 C6CF7C24702 for ; Fri, 28 Oct 2016 13:51:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5F91FCB for ; Fri, 28 Oct 2016 13:51:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07461 for ; Fri, 28 Oct 2016 16:51:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c07ZI-000EoJ-1K for freebsd-current@FreeBSD.org; Fri, 28 Oct 2016 16:51:36 +0300 Subject: Re: pmcstat -T -P instructions -t $pid ==> NMI To: FreeBSD Current References: <0479e273-1e86-13d0-ccd4-2fb6f57cff91@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Fri, 28 Oct 2016 16:50:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:51:44 -0000 On 28/10/2016 16:01, Andriy Gapon wrote: > I suspect that under the right conditions it's possible for wrmsr to cause a > counter overflow, such that an interrupt (if enabled) is generated after wrmsr > is executed, even if wrmsr disables the counter. > > In amd_intr() we have this code: > wrmsr(evsel, config & ~AMD_PMC_ENABLE); > wrmsr(perfctr, AMD_RELOAD_COUNT_TO_PERFCTR_VALUE(v)); > > /* Restart the counter if logging succeeded. */ > error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, > TRAPF_USERMODE(tf)); > if (error == 0) > wrmsr(evsel, config | AMD_PMC_ENABLE); > > I suspect that in the scenario above, if it is indeed possible, the last wrmsr > would re-enable the counter that's supposed to be stopped. > > I think that writing back the original value should be more correct, that is: > wrmsr(evsel, config); > > I'll test if this change would help. So, I have tried this change: --- a/sys/dev/hwpmc/hwpmc_amd.c +++ b/sys/dev/hwpmc/hwpmc_amd.c @@ -577,6 +577,7 @@ amd_start_pmc(int cpu, int ri) PMCDBG1(MDP,STA,2,"amd-start config=0x%x", config); + KASSERT(cpu == PCPU_GET(cpuid), ("requested cpu is not current cpu")); wrmsr(pd->pm_evsel, config); return 0; } @@ -613,6 +614,7 @@ amd_stop_pmc(int cpu, int ri) /* turn off the PMC ENABLE bit */ config = pm->pm_md.pm_amd.pm_amd_evsel & ~AMD_PMC_ENABLE; + KASSERT(cpu == PCPU_GET(cpuid), ("requested cpu is not current cpu")); wrmsr(pd->pm_evsel, config); return 0; } @@ -676,6 +678,7 @@ amd_intr(int cpu, struct trapframe *tf) perfctr = AMD_PMC_PERFCTR_0 + i; v = pm->pm_sc.pm_reloadcount; config = rdmsr(evsel); + PMCDBG1(MDP,INT,2, "enabled=%d", config & AMD_PMC_ENABLE); KASSERT((config & ~AMD_PMC_ENABLE) == (pm->pm_md.pm_amd.pm_amd_evsel & ~AMD_PMC_ENABLE), @@ -689,12 +692,13 @@ amd_intr(int cpu, struct trapframe *tf) error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, TRAPF_USERMODE(tf)); if (error == 0) - wrmsr(evsel, config | AMD_PMC_ENABLE); + wrmsr(evsel, config); } atomic_add_int(retval ? &pmc_stats.pm_intr_processed : &pmc_stats.pm_intr_ignored, 1); + PMCDBG1(MDP,INT,3, "reval=%d", retval); return (retval); } And I couldn't reproduce the problem with it. Also, in the debug log I see the following, for instance: 315466 1 1068994822044 MDP:INT:3: reval=1 315465 1 1068994821176 MDP:INT:2: enabled=4194304 315464 1 1068994820930 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 315463 1 1068994796610 MDP:INT:3: reval=1 315462 1 1068994795833 MDP:INT:2: enabled=4194304 315461 1 1068994795589 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 315460 1 1068994771107 MDP:INT:3: reval=1 315459 1 1068994770176 MDP:INT:2: enabled=4194304 315458 1 1068994769933 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 315457 0 1068994766498 MDP:SWO:1: pc=0xfffff8001c6e0e00 pp=0x0 enable-msr=0 315456 0 1068994765449 CSW:SWO:1: cpu=0 proc=0xfffff80073767a50 (1655, pmcstat) pp=0x0 315455 1 1068994742201 MDP:INT:3: reval=1 315454 1 1068994739535 MDP:INT:2: enabled=4194304 315453 1 1068994739169 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 315452 1 1068994700076 MDP:SWI:1: pc=0xfffff8007318ea00 pp=0xfffff80021f56400 enable-msr=0 315451 1 1068994698957 MDP:STA:2: amd-start config=0x5300c0 315450 1 1068994698699 MDP:STA:1: amd-start cpu=1 ri=0 315449 1 1068994697513 MDP:WRI:1: amd-write cpu=1 ri=0 v=ffffffffffff0000 315448 1 1068994696676 CSW:SWI:1: cpu=1 ri=17 new=65536 315447 1 1068994694784 MDP:CFG:1: cpu=1 ri=0 pm=0xfffff8001c6e0900 315446 1 1068994691210 CSW:SWI:1: cpu=1 proc=0xfffff8017b0d3a50 (1654, burnK7) pp=0xfffff80021f56400 315445 0 1068994674368 MDP:SWO:1: pc=0xfffff8001c6e0e00 pp=0xfffff80021f56400 enable-msr=0 315444 0 1068994674033 MDP:CFG:1: cpu=0 ri=0 pm=0x0 315443 0 1068994673597 CSW:SWO:1: cpu=0 ri=17 tmp=-3205 (samp) 315442 0 1068994673412 MDP:REA:2: amd-read (post-munge) id=0 -> 65536 315441 0 1068994673247 MDP:REA:2: amd-read (pre-munge) id=0 -> 281474976645120 315440 0 1068994673006 MDP:REA:1: amd-read id=0 class=2 315439 0 1068994672443 MDP:INT:3: reval=1 315438 0 1068994670981 MDP:INT:2: enabled=0 315437 0 1068994670591 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 315436 0 1068994669599 MDP:STO:1: amd-stop ri=0 315435 0 1068994668389 CSW:SWO:1: cpu=0 proc=0xfffff8017b0d3a50 (1654, burnK7) pp=0xfffff80021f56400 315434 0 1068994642304 MDP:INT:3: reval=1 315433 0 1068994641339 MDP:INT:2: enabled=4194304 315432 0 1068994640412 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 315431 0 1068994598561 MDP:INT:3: reval=1 315430 0 1068994596854 MDP:INT:2: enabled=4194304 315429 0 1068994596590 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 315428 0 1068994533426 MDP:INT:3: reval=1 315427 0 1068994532643 MDP:INT:2: enabled=4194304 315426 0 1068994532390 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 315425 0 1068994508088 MDP:INT:3: reval=1 315424 0 1068994507167 MDP:INT:2: enabled=4194304 315423 0 1068994506915 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 I think that event #315438 confirms my hypothesis and that previously we would get a stray NMI after that event. There is a dozen such events per more than a million of interrupts. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Oct 28 15:15:13 2016 Return-Path: Delivered-To: freebsd-current@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 451B9C248AB for ; Fri, 28 Oct 2016 15:15:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23CCB2FC; Fri, 28 Oct 2016 15:15:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id D38A010AF89; Fri, 28 Oct 2016 11:15:11 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Andriy Gapon Subject: Re: pmcstat -T -P instructions -t $pid ==> NMI Date: Fri, 28 Oct 2016 07:43:40 -0700 Message-ID: <1578218.qqa780aDhB@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <0479e273-1e86-13d0-ccd4-2fb6f57cff91@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 28 Oct 2016 11:15:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 15:15:13 -0000 On Friday, October 28, 2016 04:50:40 PM Andriy Gapon wrote: > On 28/10/2016 16:01, Andriy Gapon wrote: > > I suspect that under the right conditions it's possible for wrmsr to cause a > > counter overflow, such that an interrupt (if enabled) is generated after wrmsr > > is executed, even if wrmsr disables the counter. > > > > In amd_intr() we have this code: > > wrmsr(evsel, config & ~AMD_PMC_ENABLE); > > wrmsr(perfctr, AMD_RELOAD_COUNT_TO_PERFCTR_VALUE(v)); > > > > /* Restart the counter if logging succeeded. */ > > error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, > > TRAPF_USERMODE(tf)); > > if (error == 0) > > wrmsr(evsel, config | AMD_PMC_ENABLE); > > > > I suspect that in the scenario above, if it is indeed possible, the last wrmsr > > would re-enable the counter that's supposed to be stopped. > > > > I think that writing back the original value should be more correct, that is: > > wrmsr(evsel, config); > > > > I'll test if this change would help. > > So, I have tried this change: > > --- a/sys/dev/hwpmc/hwpmc_amd.c > +++ b/sys/dev/hwpmc/hwpmc_amd.c > @@ -577,6 +577,7 @@ amd_start_pmc(int cpu, int ri) > > PMCDBG1(MDP,STA,2,"amd-start config=0x%x", config); > > + KASSERT(cpu == PCPU_GET(cpuid), ("requested cpu is not current cpu")); > wrmsr(pd->pm_evsel, config); > return 0; > } > @@ -613,6 +614,7 @@ amd_stop_pmc(int cpu, int ri) > > /* turn off the PMC ENABLE bit */ > config = pm->pm_md.pm_amd.pm_amd_evsel & ~AMD_PMC_ENABLE; > + KASSERT(cpu == PCPU_GET(cpuid), ("requested cpu is not current cpu")); > wrmsr(pd->pm_evsel, config); > return 0; > } > @@ -676,6 +678,7 @@ amd_intr(int cpu, struct trapframe *tf) > perfctr = AMD_PMC_PERFCTR_0 + i; > v = pm->pm_sc.pm_reloadcount; > config = rdmsr(evsel); > + PMCDBG1(MDP,INT,2, "enabled=%d", config & AMD_PMC_ENABLE); > > KASSERT((config & ~AMD_PMC_ENABLE) == > (pm->pm_md.pm_amd.pm_amd_evsel & ~AMD_PMC_ENABLE), > @@ -689,12 +692,13 @@ amd_intr(int cpu, struct trapframe *tf) > error = pmc_process_interrupt(cpu, PMC_HR, pm, tf, > TRAPF_USERMODE(tf)); > if (error == 0) > - wrmsr(evsel, config | AMD_PMC_ENABLE); > + wrmsr(evsel, config); > } > > atomic_add_int(retval ? &pmc_stats.pm_intr_processed : > &pmc_stats.pm_intr_ignored, 1); > > + PMCDBG1(MDP,INT,3, "reval=%d", retval); > return (retval); > } > > > > And I couldn't reproduce the problem with it. > Also, in the debug log I see the following, for instance: > 315466 1 1068994822044 MDP:INT:3: reval=1 > 315465 1 1068994821176 MDP:INT:2: enabled=4194304 > 315464 1 1068994820930 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 > 315463 1 1068994796610 MDP:INT:3: reval=1 > 315462 1 1068994795833 MDP:INT:2: enabled=4194304 > 315461 1 1068994795589 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 > 315460 1 1068994771107 MDP:INT:3: reval=1 > 315459 1 1068994770176 MDP:INT:2: enabled=4194304 > 315458 1 1068994769933 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 > 315457 0 1068994766498 MDP:SWO:1: pc=0xfffff8001c6e0e00 pp=0x0 enable-msr=0 > 315456 0 1068994765449 CSW:SWO:1: cpu=0 proc=0xfffff80073767a50 (1655, > pmcstat) pp=0x0 > 315455 1 1068994742201 MDP:INT:3: reval=1 > 315454 1 1068994739535 MDP:INT:2: enabled=4194304 > 315453 1 1068994739169 MDP:INT:1: cpu=1 tf=0xfffffe03c45ecf30 um=1 > 315452 1 1068994700076 MDP:SWI:1: pc=0xfffff8007318ea00 > pp=0xfffff80021f56400 enable-msr=0 > 315451 1 1068994698957 MDP:STA:2: amd-start config=0x5300c0 > 315450 1 1068994698699 MDP:STA:1: amd-start cpu=1 ri=0 > 315449 1 1068994697513 MDP:WRI:1: amd-write cpu=1 ri=0 v=ffffffffffff0000 > 315448 1 1068994696676 CSW:SWI:1: cpu=1 ri=17 new=65536 > 315447 1 1068994694784 MDP:CFG:1: cpu=1 ri=0 pm=0xfffff8001c6e0900 > 315446 1 1068994691210 CSW:SWI:1: cpu=1 proc=0xfffff8017b0d3a50 (1654, > burnK7) pp=0xfffff80021f56400 > 315445 0 1068994674368 MDP:SWO:1: pc=0xfffff8001c6e0e00 > pp=0xfffff80021f56400 enable-msr=0 > 315444 0 1068994674033 MDP:CFG:1: cpu=0 ri=0 pm=0x0 > 315443 0 1068994673597 CSW:SWO:1: cpu=0 ri=17 tmp=-3205 (samp) > 315442 0 1068994673412 MDP:REA:2: amd-read (post-munge) id=0 -> 65536 > 315441 0 1068994673247 MDP:REA:2: amd-read (pre-munge) id=0 -> 281474976645120 > 315440 0 1068994673006 MDP:REA:1: amd-read id=0 class=2 > 315439 0 1068994672443 MDP:INT:3: reval=1 > 315438 0 1068994670981 MDP:INT:2: enabled=0 > 315437 0 1068994670591 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 > 315436 0 1068994669599 MDP:STO:1: amd-stop ri=0 > 315435 0 1068994668389 CSW:SWO:1: cpu=0 proc=0xfffff8017b0d3a50 (1654, > burnK7) pp=0xfffff80021f56400 > 315434 0 1068994642304 MDP:INT:3: reval=1 > 315433 0 1068994641339 MDP:INT:2: enabled=4194304 > 315432 0 1068994640412 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 > 315431 0 1068994598561 MDP:INT:3: reval=1 > 315430 0 1068994596854 MDP:INT:2: enabled=4194304 > 315429 0 1068994596590 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=0 > 315428 0 1068994533426 MDP:INT:3: reval=1 > 315427 0 1068994532643 MDP:INT:2: enabled=4194304 > 315426 0 1068994532390 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 > 315425 0 1068994508088 MDP:INT:3: reval=1 > 315424 0 1068994507167 MDP:INT:2: enabled=4194304 > 315423 0 1068994506915 MDP:INT:1: cpu=0 tf=0xffffffff81d769d0 um=1 > > I think that event #315438 confirms my hypothesis and that previously we would > get a stray NMI after that event. There is a dozen such events per more than a > million of interrupts. I think your patch is probably correct. hwpmc_core.c seems to have the same issue. I think it could be fixed similarly though it doesn't seem to have ever triggered. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Oct 28 15:15:14 2016 Return-Path: Delivered-To: freebsd-current@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 E7CE1C248C0; Fri, 28 Oct 2016 15:15:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE16930B; Fri, 28 Oct 2016 15:15:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9C1CD10AF8A; Fri, 28 Oct 2016 11:15:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Date: Fri, 28 Oct 2016 07:29:52 -0700 Message-ID: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 28 Oct 2016 11:15:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 15:15:15 -0000 On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: > [The following has been reported in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .] > > In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to track things down I ran into truss getting a SIGSEGV when it tries to handle the situation. . . > > In truss's enter_syscall there is (from a live gdb on truss, after the segmentation fault): > > 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi, t->cs.number); > 381 if (t->cs.name == NULL) > (gdb) > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n", > 383 t->proc->abi->type, t->cs.number); > 384 > 385 sc = get_syscall(t->cs.name, narg); > 386 t->cs.nargs = sc->nargs; > 387 assert(sc->nargs <= nitems(t->cs.s_args)); > 388 > 389 t->cs.sc = sc; > > (gdb) print *t > $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064, args = 0x2061b0c0, nargs = 0, > s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}} > > (gdb) print sc > $3 = (struct syscall *) 0x0 > > So line 386 listed above gets a segmentation fault for sc->nargs when t->cs.name is a NULL pointer: sc ends up NULL. > > Looking at the two things that the fprintf on lines 382 and 383 would report: > > (gdb) print t->proc->abi->type > $4 = 0x10166 "FreeBSD ELF32" > > (gdb) print t->cs.number > $5 = 580828064 > > (gdb) print narg > $6 = 0 > > (that last is for context for the get_syscall arguments). > > FYI: 580828064 = 0x229EBBA0 I have a patchset I have tested some in a git branch that I believe fixes handling of unknown system calls. Please try this: https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown (Add .diff to get a diff you can apply with patch) -- John Baldwin From owner-freebsd-current@freebsd.org Fri Oct 28 19:21:18 2016 Return-Path: Delivered-To: freebsd-current@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 44691C23FC8 for ; Fri, 28 Oct 2016 19:21:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 06D7BAF7 for ; Fri, 28 Oct 2016 19:21:17 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1c0CiI-0047Q3-Qy>; Fri, 28 Oct 2016 21:21:14 +0200 Received: from x4e3495b6.dyn.telefonica.de ([78.52.149.182] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1c0CiI-0022l5-Gm>; Fri, 28 Oct 2016 21:21:14 +0200 Date: Fri, 28 Oct 2016 21:21:13 +0200 From: "Hartmann, O." To: YongHyeon PYUN Cc: FreeBSD CURRENT Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161028212113.5c4a2ca2@hermann> In-Reply-To: <20161027010004.GA1215@michelle.fasterthan.co.kr> References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> <20161025070338.76ad6711@hermann> <20161027010004.GA1215@michelle.fasterthan.co.kr> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 78.52.149.182 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 19:21:18 -0000 On Thu, 27 Oct 2016 10:00:04 +0900 YongHyeon PYUN wrote: > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote: > > On Tue, 25 Oct 2016 11:05:38 +0900 > > YongHyeon PYUN wrote: > > > > [...] > > > > I'm not sure but it's likely the issue is related with EEE/Green > > > Ethernet handling. EEE is negotiated feature with link partner. If > > > you directly connect your laptop to non-EEE capable link partner > > > like other re(4) box without switches you may be able to tell > > > whether the issue is EEE/Green Ethernet related one or not. > > > > Me either since when I discovered a problem the first time with > > CURRENT, that was the Friday before last week's Friday, there was a > > unlucky coicidence: I got the new switch, FreeBSD introduced a > > serious bug and I changed the NICs. > > > > The laptop, the last in the row of re(4) equipted systems on which I > > use the Realtek NIC, does well now with Green IT technology, but > > crashes on plugging/unplugging - not on each event, but at least in > > one of ten. > > Hmm, it seems you know how to trigger the issue. When you unplug > UTP cable was there active network traffic on re(4) device? > It would be helpful to know which event triggers the crash(e.g. > unplugging or plugging). And would you show me backtrace of panic? > > > I guess the Green IT issue is more a unlucky guess of mine and went > > hand in hand with the problem I face with CURRENT right now on some > > older, Non UEFI machines. > > > > Ok. > > [...] > > > > As requested the informations about re0 and rgephy0 on the laptop > > (Lenovo E540) > > > > [...] > > > > rgephy0: PHY 1 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, > > 1000baseT-FDX-master, 1000baseT-FDX-flow, > > 1000baseT-FDX-flow-master, auto, auto-flow > > > > re0: > > port 0x3000-0x30ff mem 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff > > at device 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled > > re0: Chip rev. 0x50800000 > > re0: MAC rev. 0x00100000 > > This looks like 8168GU controller. > > [...] > > > I use options netmap in kernel config, but the problem is also > > present without this option - just for the record. > > > > Yup, netmap(4) has nothing to do with the crash. > > Thanks. Attached, you'll find the backtrace of the crash. This time it was really easy - just one pull of the LAN cabling - and we are happy :-/ Please let me know if you need something else. I will return to normal operations (disabling debugging) due to CURRENT is very unstable at the moment on other hosts beyond r307157. Kind regards, oh From owner-freebsd-current@freebsd.org Sat Oct 29 00:02:29 2016 Return-Path: Delivered-To: freebsd-current@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 D7CEEC24219 for ; Sat, 29 Oct 2016 00:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-59.reflexion.net [208.70.210.59]) (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 957D9DE5 for ; Sat, 29 Oct 2016 00:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10755 invoked from network); 28 Oct 2016 23:02:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Oct 2016 23:02:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Fri, 28 Oct 2016 19:02:36 -0400 (EDT) Received: (qmail 3659 invoked from network); 28 Oct 2016 23:02:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Oct 2016 23:02:36 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3181CEC8F25; Fri, 28 Oct 2016 16:02:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> Date: Fri, 28 Oct 2016 16:02:26 -0700 Cc: freebsd-current@freebsd.org, freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 00:02:29 -0000 On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: > On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>=20 >> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>=20 >> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>=20 >> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >> 381 if (t->cs.name =3D=3D NULL) >> (gdb)=20 >> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >> 383 t->proc->abi->type, t->cs.number); >> 384=09 >> 385 sc =3D get_syscall(t->cs.name, narg); >> 386 t->cs.nargs =3D sc->nargs; >> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >> 388=09 >> 389 t->cs.sc =3D sc; >>=20 >> (gdb) print *t >> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D= 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name = =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>=20 >> (gdb) print sc >> $3 =3D (struct syscall *) 0x0 >>=20 >> So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. >>=20 >> Looking at the two things that the fprintf on lines 382 and 383 would = report: >>=20 >> (gdb) print t->proc->abi->type >> $4 =3D 0x10166 "FreeBSD ELF32" >>=20 >> (gdb) print t->cs.number >> $5 =3D 580828064 >>=20 >> (gdb) print narg >> $6 =3D 0 >>=20 >> (that last is for context for the get_syscall arguments). >>=20 >> FYI: 580828064 =3D 0x229EBBA0 >=20 > I have a patchset I have tested some in a git branch that I believe = fixes handling of > unknown system calls. Please try this: >=20 > = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >=20 > (Add .diff to get a diff you can apply with patch) >=20 > --=20 > John Baldwin Sorry it took so long to try the build. . . I got a compile failure for use of bool in my stable/11 context for the = BPI-M3 build that the truss problem was discovered with (quoting the = build log below): > --- main.o --- > cc -target armv6-gnueabihf-freebsd11.0 = --sysroot=3D/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp = -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe = -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD = -MF.depend.main.o -MTma > in.o -std=3Dgnu99 -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs=20 > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/usr.bin/truss/main.c -o main.o > In file included from /usr/src/usr.bin/truss/main.c:53: > /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name 'bool' > bool unknown; /* Uknown system call */ > ^ > 1 error generated. > *** [main.o] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.bin/truss > 1 error In C99 bool is a macro from and _Bool is the C99 type = itself. So apparently (or an equivalent) was not directly or = indirectly included. (The macros true and false and = __bool_true_false_are_defined are also from .) Which way do you want the C99 typing to be handled for this: native C99 = with no required? Use ? Side note: I'll see about getting my normal stable/11 build environment going for = the BPI-M3 instead of using the crochet from my first-time build for the = target. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 29 10:22:29 2016 Return-Path: Delivered-To: freebsd-current@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 AFC29C26138 for ; Sat, 29 Oct 2016 10:22:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-55.reflexion.net [208.70.210.55]) (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 70D7C91F for ; Sat, 29 Oct 2016 10:22:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1046 invoked from network); 29 Oct 2016 10:23:24 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Oct 2016 10:23:24 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Sat, 29 Oct 2016 06:22:31 -0400 (EDT) Received: (qmail 734 invoked from network); 29 Oct 2016 10:22:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2016 10:22:30 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 92C39EC90F1; Sat, 29 Oct 2016 03:22:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: Date: Sat, 29 Oct 2016 03:22:25 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <05266324-67D0-4487-BF94-58B831C79F5B@dsl-only.net> References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 10:22:29 -0000 On 2016-Oct-28, at 4:02 PM, Mark Millard wrote: > On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: >=20 >> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >>> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>>=20 >>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>>=20 >>> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>>=20 >>> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >>> 381 if (t->cs.name =3D=3D NULL) >>> (gdb)=20 >>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >>> 383 t->proc->abi->type, t->cs.number); >>> 384=09 >>> 385 sc =3D get_syscall(t->cs.name, narg); >>> 386 t->cs.nargs =3D sc->nargs; >>> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >>> 388=09 >>> 389 t->cs.sc =3D sc; >>>=20 >>> (gdb) print *t >>> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc = =3D 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, = name =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >>> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>>=20 >>> (gdb) print sc >>> $3 =3D (struct syscall *) 0x0 >>>=20 >>> So line 386 listed above gets a segmentation fault for sc->nargs = when t->cs.name is a NULL pointer: sc ends up NULL. >>>=20 >>> Looking at the two things that the fprintf on lines 382 and 383 = would report: >>>=20 >>> (gdb) print t->proc->abi->type >>> $4 =3D 0x10166 "FreeBSD ELF32" >>>=20 >>> (gdb) print t->cs.number >>> $5 =3D 580828064 >>>=20 >>> (gdb) print narg >>> $6 =3D 0 >>>=20 >>> (that last is for context for the get_syscall arguments). >>>=20 >>> FYI: 580828064 =3D 0x229EBBA0 >>=20 >> I have a patchset I have tested some in a git branch that I believe = fixes handling of >> unknown system calls. Please try this: >>=20 >> = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >>=20 >> (Add .diff to get a diff you can apply with patch) >>=20 >> --=20 >> John Baldwin >=20 > Sorry it took so long to try the build. . . >=20 > I got a compile failure for use of bool in my stable/11 context for = the BPI-M3 build that the truss problem was discovered with (quoting the = build log below): >=20 >> --- main.o --- >> cc -target armv6-gnueabihf-freebsd11.0 = --sysroot=3D/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp = -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe = -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD = -MF.depend.main.o -MTma >> in.o -std=3Dgnu99 -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs=20 >> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/usr.bin/truss/main.c -o main.o >> In file included from /usr/src/usr.bin/truss/main.c:53: >> /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name = 'bool' >> bool unknown; /* Uknown system call */ >> ^ >> 1 error generated. >> *** [main.o] Error code 1 >>=20 >> make[4]: stopped in /usr/src/usr.bin/truss >> 1 error >=20 >=20 > In C99 bool is a macro from and _Bool is the C99 type = itself. So apparently (or an equivalent) was not directly or = indirectly included. (The macros true and false and = __bool_true_false_are_defined are also from .) >=20 > Which way do you want the C99 typing to be handled for this: native = C99 with no required? Use ? >=20 >=20 > Side note: >=20 > I'll see about getting my normal stable/11 build environment going for = the BPI-M3 instead of using the crochet from my first-time build for the = target. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net [Once I got back to this test yet again I arbitrarily added a #include = to allow truss to build during buildworld.] The way I normally build (instead of crochet) did not get the original = cc1 problem in its original form. So as of yet I've not managed to = reproduce the test case accurately: Back to crochet. I will note that in my "with debug symbols" and -mcpu=3Dcortex-a7 style = of buildworld buildkernel type of boot context I got an explicit message = in the xgcc/cc1 test that may indicate the original problem for cc1: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: Undefined = symbol "__aeabi_uidiv" [bugzilla https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213785 ] At this stage in trying to bootstrap lang/gcc6 as the first gcc compiler = on the BPi-M3: # ldd /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: libmpc.so.3 =3D> /usr/local/lib/libmpc.so.3 (0x21aff000) libmpfr.so.4 =3D> /usr/local/lib/libmpfr.so.4 (0x21b25000) libgmp.so.10 =3D> /usr/local/lib/libgmp.so.10 (0x21bba000) libz.so.6 =3D> /lib/libz.so.6 (0x21c5b000) libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x21c77000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x21d1d000) libm.so.5 =3D> /lib/libm.so.5 (0x21d3f000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x21d62000) libc.so.7 =3D> /lib/libc.so.7 (0x21e00000) So /usr/local/lib/ is not yet providing gcc's own library of primitives = for xgcc or cc1 to use and when FreeBSD is missing something = like__aeabi_uidiv that xgcc/cc1 expects to use there could then be = problems: # ls -l /usr/local/lib total 127288 -r-xr-xr-x 1 root wheel 10168 Oct 25 07:39 bindtextdomain.so drwxr-xr-x 2 root wheel 512 Oct 25 05:57 gettext -rw-r--r-- 1 root wheel 72026 Oct 25 05:40 libasprintf.a lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so -> = libasprintf.so.0.0.0 lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so.0 -> = libasprintf.so.0.0.0 -rwxr-xr-x 1 root wheel 64717 Oct 25 05:40 libasprintf.so.0.0.0 -rw-r--r-- 1 root wheel 58917550 Oct 25 08:52 libbfd.a -rwxr-xr-x 1 root wheel 4421893 Oct 25 05:56 = libgettextlib-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextlib.so -> = libgettextlib-0.19.8.1.so -rw-r--r-- 1 root wheel 1611908 Oct 25 05:56 libgettextpo.a lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so -> = libgettextpo.so.0.5.4 lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so.0 -> = libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1134132 Oct 25 05:56 libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1005228 Oct 25 05:56 = libgettextsrc-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextsrc.so -> = libgettextsrc-0.19.8.1.so -rw-r--r-- 1 root wheel 2935784 Oct 25 08:01 libgmp.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so -> = libgmp.so.10.1.3 lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so.10 -> = libgmp.so.10.1.3 -rwxr-xr-x 1 root wheel 1709666 Oct 25 08:01 libgmp.so.10.1.3 -rw-r--r-- 1 root wheel 1112250 Oct 25 08:01 libgmpxx.a lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so -> = libgmpxx.so.4.3.3 lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so.4 -> = libgmpxx.so.4.3.3 -rwxr-xr-x 1 root wheel 657771 Oct 25 08:01 libgmpxx.so.4.3.3 -rw-r--r-- 1 root wheel 238518 Oct 25 05:40 libintl.a lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so -> = libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so.8 -> = libintl.so.8.1.5 -rw-r--r-- 1 root wheel 157207 Oct 25 05:40 libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 12 Oct 25 05:40 libintl.so.9 -> = libintl.so.8 -rw-r--r-- 1 root wheel 565968 Oct 25 09:02 libmpc.a lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so -> = libmpc.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so.3 -> = libmpc.so.3.0.0 -rwxr-xr-x 1 root wheel 346999 Oct 25 09:02 libmpc.so.3.0.0 -rw-r--r-- 1 root wheel 2053300 Oct 25 08:05 libmpfr.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so -> = libmpfr.so.4.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so.4 -> = libmpfr.so.4.1.5 -rwxr-xr-x 1 root wheel 1294011 Oct 25 08:05 libmpfr.so.4.1.5 -rw-r--r-- 1 root wheel 38488604 Oct 25 08:52 libopcodes.a -rw-r--r-- 1 root wheel 7155654 Oct 25 05:36 libpkg.a lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so -> = libpkg.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so.3 -> = libpkg.so.3.0.0 -rwxr-xr-x 1 root wheel 5621424 Oct 25 05:36 libpkg.so.3.0.0 drwxr-xr-x 4 root wheel 512 Oct 25 07:37 perl5 Part of the issue may be that unlike my usual procedure for gcc* builds: OPTIONS_FILE_UNSET+=3DBOOTSTRAP for the BPI-M3 lang/gcc6 build I used: OPTIONS_FILE_SET+=3DBOOTSTRAP This might explain why I did not see a problem on the rpi2 historically. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Oct 29 14:33:51 2016 Return-Path: Delivered-To: freebsd-current@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 976B0C2683B for ; Sat, 29 Oct 2016 14:33:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 17CD9F00 for ; Sat, 29 Oct 2016 14:33:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1c0Uhb-003CoI-94>; Sat, 29 Oct 2016 16:33:43 +0200 Received: from x4e3495b6.dyn.telefonica.de ([78.52.149.182] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1c0Uha-003Eej-Ck>; Sat, 29 Oct 2016 16:33:43 +0200 Date: Sat, 29 Oct 2016 16:33:36 +0200 From: "O. Hartmann" To: Benjamin Kaduk Cc: freebsd-current Subject: Re: was: CURRENT [r308087] still crashing: Backtrace provided Message-ID: <20161029163336.46bb24c4.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> <20161015121321.25007de8.ohartman@zedat.fu-berlin.de> <20161023182436.4d3bac4f.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/q.wjP7/8QobIIk_Bsu_0AUT"; protocol="application/pgp-signature" X-Originating-IP: 78.52.149.182 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 14:33:51 -0000 --Sig_/q.wjP7/8QobIIk_Bsu_0AUT Content-Type: multipart/mixed; boundary="MP_/unDILOyI.YaXKvvM8HMUDK9" --MP_/unDILOyI.YaXKvvM8HMUDK9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sun, 23 Oct 2016 15:18:57 -0400 (EDT) Benjamin Kaduk schrieb: > On Sun, 23 Oct 2016, O. Hartmann wrote: >=20 > > How can I track a memory leak? =20 >=20 > I think I did not read enough of the context, but vmstat and top can track > memory usage as a general thing. >=20 > > How can I write to disk the backtrace given by the debugger when > > crashing? My box I can freely test is using the nVidia BLOB and vt(), so > > I can not see the backtrace. I got a very bad screenshot on one of my > > laptops, but its so ugly/unreadable, I think it is unsuable to be > > presented within this list at a reasonable size (200 kB max ist too > > small). =20 >=20 > The backtrace should be part of the crash dump that is written to the > (directly connected, non-encrypted, non-USB) swap device. "call doadump" > at the debugger prompt (even typing blind) is supposed to make sure > there's a dump taken. >=20 > With respect to the screenshot, you should be able to post the image on an > external site and send a link to the list, at least. >=20 > -Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Hello Benjamin, thank you for your response. Attached, you'll find the backtrace developers= seem to have requested for. It was a bit hard, since FreeBSD, vt() and nVidia is= broken (black or distorted console, on UEFI it is black/locked as long as the nvid= ia-modeset,ko module is loaded). I figured out that I could blindly type "dump" when the = box has crashed and resided at the debugger promt. I hope this time I could provide the help to fix this really nasty problem.= On more recent hardware, Haswell and beyond, I was able to run CURRENT even with ZF= S and poudriere on a hard memory pressure without crash within three days. On old= er machines, one older Fujitsu dual socket Core2Duo XEON (2x 4 core, 2x 16 GB RAM banks)= as well as two of my private boxes (1x IvyBridge XEON, one i3-3220, both wit a non-U= EFI-working ASROCK Z77 Pro4 board) crash, if FreeBSD is > r307157. Staying on those sys= tems with r307157 leaves the machine "rock-solid" - the XEON box last now for a week = uptime.=20 Since the only box I can more or less freely test with is the slowest of al= l, the i3-3220. So it takes a while until I have recompiled a world. Thanks you very much in advance, Oliver=20 --MP_/unDILOyI.YaXKvvM8HMUDK9 Content-Type: application/octet-stream; name=core.txt.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=core.txt.0 dGhvci53YWxzdGF0dC5keW52cG4uZGUgZHVtcGVkIGNvcmUgLSBzZWUgL3Zhci9jcmFzaC92bWNv cmUuMAoKU2F0IE9jdCAyOSAxNjoxOTo1MiBDRVNUIDIwMTYKCkZyZWVCU0QgdGhvci53YWxzdGF0 dC5keW52cG4uZGUgMTIuMC1DVVJSRU5UIEZyZWVCU0QgMTIuMC1DVVJSRU5UICM0IHIzMDgwODc6 IFNhdCBPY3QgMjkgMTQ6Mzk6NDkgQ0VTVCAyMDE2ICAgICByb290QHRob3Iud2Fsc3RhdHQuZHlu dnBuLmRlOi91c3Ivb2JqL3Vzci9zcmMvc3lzL1RIT1IgIGFtZDY0CgpwYW5pYzogCgpHTlUgZ2Ri IDYuMS4xIFtGcmVlQlNEXQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24s IEluYy4KR0RCIGlzIGZyZWUgc29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlLCBhbmQgeW91IGFyZQp3ZWxjb21lIHRvIGNoYW5nZSBpdCBhbmQvb3IgZGlz dHJpYnV0ZSBjb3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zLgpUeXBlICJzaG93 IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4KVGhlcmUgaXMgYWJzb2x1dGVseSBubyB3 YXJyYW50eSBmb3IgR0RCLiAgVHlwZSAic2hvdyB3YXJyYW50eSIgZm9yIGRldGFpbHMuClRoaXMg R0RCIHdhcyBjb25maWd1cmVkIGFzICJhbWQ2NC1tYXJjZWwtZnJlZWJzZCIuLi4KClVucmVhZCBw b3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6Cktlcm5lbCBwYWdlIGZhdWx0IHdp dGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBhYmxlIGxvY2tzIGhlbGQ6CmV4Y2x1c2l2ZSBydyB0 Y3BpbnAgKHRjcGlucCkgciA9IDAgKDB4ZmZmZmY4MDA2YjJiNGUxOCkgbG9ja2VkIEAgL3Vzci9z cmMvc3lzL25ldGluZXQvaW5fcGNiLmM6MTk2MQpzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZm ZmY4MDgyMTE5MCBhdCB3aXRuZXNzX2RlYnVnZ2VyKzB4NzAKIzEgMHhmZmZmZmZmZjgwODIyNTA3 IGF0IHdpdG5lc3Nfd2FybisweDQ2NwojMiAweGZmZmZmZmZmODBiMDI2NzcgYXQgdHJhcF9wZmF1 bHQrMHg1NwojMyAweGZmZmZmZmZmODBiMDFkOWIgYXQgdHJhcCsweDI4YgojNCAweGZmZmZmZmZm ODBhZTJmODEgYXQgY2FsbHRyYXArMHg4CiM1IDB4ZmZmZmZmZmY4MDdiNjYxYyBhdCBfcndfd2xv Y2tfY29va2llKzB4YmMKIzYgMHhmZmZmZmZmZjgwOGQzYmM3IGF0IGV0aGVyX291dHB1dCsweGQ3 CiM3IDB4ZmZmZmZmZmY4MDkyNTgzNCBhdCBpcF9vdXRwdXQrMHgxNjk0CiM4IDB4ZmZmZmZmZmY4 MDk5YzU1ZSBhdCB0Y3Bfb3V0cHV0KzB4MTdjZQojOSAweGZmZmZmZmZmODA5OThhNGEgYXQgdGNw X2RvX3NlZ21lbnQrMHgyOTFhCiMxMCAweGZmZmZmZmZmODA5OTU1YjQgYXQgdGNwX2lucHV0KzB4 ZTA0CiMxMSAweGZmZmZmZmZmODA5MjE5MzEgYXQgaXBfaW5wdXQrMHgxODEKIzEyIDB4ZmZmZmZm ZmY4MDhlZDVkNSBhdCBzd2lfbmV0KzB4MTc1CiMxMyAweGZmZmZmZmZmODA3N2YzMDYgYXQgaW50 cl9ldmVudF9leGVjdXRlX2hhbmRsZXJzKzB4OTYKIzE0IDB4ZmZmZmZmZmY4MDc3Zjk4NiBhdCBp dGhyZWFkX2xvb3ArMHhhNgojMTUgMHhmZmZmZmZmZjgwNzdjYTE0IGF0IGZvcmtfZXhpdCsweDg0 CiMxNiAweGZmZmZmZmZmODBhZTM0YmUgYXQgZm9ya190cmFtcG9saW5lKzB4ZQoKCkZhdGFsIHRy YXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAyOyBhcGljIGlk ID0gMDIKZmF1bHQgdmlydHVhbCBhZGRyZXNzCT0gMHgzYjgKZmF1bHQgY29kZQkJPSBzdXBlcnZp c29yIHJlYWQgZGF0YSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgy MDoweGZmZmZmZmZmODA3YjY3OWIKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZm ZTAxZjA3ZjMyOTAKZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZTAxZjA3ZjMz MTAKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJ PSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdz CT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9 IDEyIChzd2kxOiBuZXRpc3IgMCkKClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L21vZHVsZXMv bnZpZGlhLW1vZGVzZXQua28uLi5kb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3QvbW9kdWxl cy9udmlkaWEtbW9kZXNldC5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9tb2R1bGVzL252 aWRpYS5rby4uLmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9tb2R1bGVzL252aWRpYS5r bwojMCAgZG9hZHVtcCAodGV4dGR1bXA9MCkgYXQgcGNwdS5oOjIyMgoyMjIJcGNwdS5oOiBObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5LgoJaW4gcGNwdS5oCihrZ2RiKSAjMCAgZG9hZHVtcCAodGV4 dGR1bXA9MCkgYXQgcGNwdS5oOjIyMgojMSAgMHhmZmZmZmZmZjgwNDlmZmFiIGluIGRiX2R1bXAg KGR1bW15PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgZHVtbXkyPWZhbHNlLCAKICAgIGR1bW15Mz0w LCBkdW1teTQ9MHgwKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1NDYKIzIgIDB4 ZmZmZmZmZmY4MDQ5ZmRhOSBpbiBkYl9jb21tYW5kIChjbWRfdGFibGU9PHZhbHVlIG9wdGltaXpl ZCBvdXQ+KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDUzCiMzICAweGZm ZmZmZmZmODA0OWZiMDQgaW4gZGJfY29tbWFuZF9sb29wICgpCiAgICBhdCAvdXNyL3NyYy9zeXMv ZGRiL2RiX2NvbW1hbmQuYzo1MDYKIzQgIDB4ZmZmZmZmZmY4MDRhMmY2ZiBpbiBkYl90cmFwICh0 eXBlPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgCiAgICBjb2RlPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0 PikgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjQ4CiM1ICAweGZmZmZmZmZmODA3ZmY2 OTMgaW4ga2RiX3RyYXAgKHR5cGU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKICAgIGNvZGU9PHZh bHVlIG9wdGltaXplZCBvdXQ+LCB0Zj08dmFsdWUgb3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX2tkYi5jOjY1NAojNiAgMHhmZmZmZmZmZjgwYjAyNWQxIGluIHRy YXBfZmF0YWwgKGZyYW1lPTB4ZmZmZmZlMDFmMDdmMzFkMCwgZXZhPTk1MikKICAgIGF0IC91c3Iv c3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6Nzk2CiM3ICAweGZmZmZmZmZmODBiMDI4MWQgaW4g dHJhcF9wZmF1bHQgKGZyYW1lPTB4ZmZmZmZlMDFmMDdmMzFkMCwgdXNlcm1vZGU9MCkKICAgIGF0 IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NjU4CiM4ICAweGZmZmZmZmZmODBiMDFk OWIgaW4gdHJhcCAoZnJhbWU9MHhmZmZmZmUwMWYwN2YzMWQwKQogICAgYXQgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L3RyYXAuYzo0MjEKIzkgIDB4ZmZmZmZmZmY4MGFlMmY4MSBpbiBjYWxsdHJh cCAoKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjIzNgojMTAg MHhmZmZmZmZmZjgwN2I2NzliIGluIF9fcndfd2xvY2tfaGFyZCAoYz08dmFsdWUgb3B0aW1pemVk IG91dD4sIAogICAgdGlkPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgZmlsZT08dmFsdWUgb3B0aW1p emVkIG91dD4sIAogICAgbGluZT08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fcndsb2NrLmM6ODMwCiMxMSAweGZmZmZmZmZmODA3YjY2MWMgaW4gX3J3X3ds b2NrX2Nvb2tpZSAoYz0weGZmZmZmODAwNmIwYmY3MTAsIAogICAgZmlsZT0weGZmZmZmZmZmODBj YTgzNjIgIi91c3Ivc3JjL3N5cy9uZXQvaWZfZXRoZXJzdWJyLmMiLCBsaW5lPTMwNCkKICAgIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcndsb2NrLmM6Mjk2CiMxMiAweGZmZmZmZmZmODA4ZDNi YzcgaW4gZXRoZXJfb3V0cHV0IChpZnA9MHhmZmZmZjgwMDAzNmYwODAwLCAKICAgIG09PHZhbHVl IG9wdGltaXplZCBvdXQ+LCBkc3Q9MHhmZmZmZjgwMDZiMmI0ZTYwLCBybz0weGZmZmZmODAwNmIy YjRlNDApCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0L2lmX2V0aGVyc3Vici5jOjMwNAojMTMgMHhm ZmZmZmZmZjgwOTI1ODM0IGluIGlwX291dHB1dCAobT0weGZmZmZmODAwMDM1NTY1MDAsIAogICAg b3B0PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0Piwgcm89PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBmbGFn cz0wLCBpbW89MHgwLCAKICAgIGlucD08dmFsdWUgb3B0aW1pemVkIG91dD4pIGF0IC91c3Ivc3Jj L3N5cy9uZXRpbmV0L2lwX291dHB1dC5jOjY2NAojMTQgMHhmZmZmZmZmZjgwOTljNTVlIGluIHRj cF9vdXRwdXQgKHRwPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikKICAgIGF0IC91c3Ivc3JjL3N5cy9u ZXRpbmV0L3RjcF9vdXRwdXQuYzoxNDMyCiMxNSAweGZmZmZmZmZmODA5OThhNGEgaW4gdGNwX2Rv X3NlZ21lbnQgKG09PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKICAgIHRoPTx2YWx1ZSBvcHRpbWl6 ZWQgb3V0Piwgc289MHhmZmZmZjgwMDEwYjJmYTIwLCAKICAgIHRwPTx2YWx1ZSBvcHRpbWl6ZWQg b3V0PiwgZHJvcF9oZHJsZW49NDAsIHRsZW49PHZhbHVlIG9wdGltaXplZCBvdXQ+LCAKICAgIGlw dG9zPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgdGlfbG9ja2VkPUNhbm5vdCBhY2Nlc3MgbWVtb3J5 IGF0IGFkZHJlc3MgMHgxCikKICAgIGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5j OjMyMDkKIzE2IDB4ZmZmZmZmZmY4MDk5NTViNCBpbiB0Y3BfaW5wdXQgKG1wPTx2YWx1ZSBvcHRp bWl6ZWQgb3V0PiwgCiAgICBvZmZwPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgcHJvdG89PHZhbHVl IG9wdGltaXplZCBvdXQ+KQogICAgYXQgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lucHV0LmM6 MTQ2NQojMTcgMHhmZmZmZmZmZjgwOTIxOTMxIGluIGlwX2lucHV0IChtPTB4MCkKICAgIGF0IC91 c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX2lucHV0LmM6ODA5CiMxOCAweGZmZmZmZmZmODA4ZWQ1ZDUg aW4gc3dpX25ldCAoYXJnPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikKICAgIGF0IC91c3Ivc3JjL3N5 cy9uZXQvbmV0aXNyLmM6ODk5CiMxOSAweGZmZmZmZmZmODA3N2YzMDYgaW4gaW50cl9ldmVudF9l eGVjdXRlX2hhbmRsZXJzICgKICAgIHA9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBpZT08dmFsdWUg b3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjYy CiMyMCAweGZmZmZmZmZmODA3N2Y5ODYgaW4gaXRocmVhZF9sb29wIChhcmc9PHZhbHVlIG9wdGlt aXplZCBvdXQ+KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTI3NQojMjEg MHhmZmZmZmZmZjgwNzdjYTE0IGluIGZvcmtfZXhpdCAoCiAgICBjYWxsb3V0PTB4ZmZmZmZmZmY4 MDc3ZjhlMCA8aXRocmVhZF9sb29wPiwgYXJnPTB4ZmZmZmY4MDAwMzUzNmI2MCwgCiAgICBmcmFt ZT0weGZmZmZmZTAxZjA3ZjNhYzApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjEw MzgKIzIyIDB4ZmZmZmZmZmY4MGFlMzRiZSBpbiBmb3JrX3RyYW1wb2xpbmUgKCkKICAgIGF0IC91 c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzo2MTEKIzIzIDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQpDdXJyZW50IGxhbmd1YWdlOiAgYXV0bzsgY3VycmVudGx5IG1pbmltYWwK KGtnZGIpIAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzIC1heGx3dwoKIFVJRCAgIFBJRCAgUFBJRCBDUFUg UFJJIE5JICAgICAgVlNaICAgICBSU1MgTVdDSEFOICAgU1RBVCBUVCAgICAgIFRJTUUgQ09NTUFO RAogICAwICAgICAwICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAgMCBzd2FwaW4gICBE THMgICAtICAgMDowMC41OCBba2VybmVsXQogICAwICAgICAxICAgICAwICAgMCAgMjIgIDAgICAg IDU0MjQgICAgIDg2OCB3YWl0ICAgICBETHMgICAtICAgMDowMC4wMSBbaW5pdF0KICAgMCAgICAg MiAgICAgMCAgIDAgLTE2ICAwICAgICAgICAwICAgICAgIDAgY3J5cHRvX3cgREwgICAgLSAgIDA6 MDAuMDAgW2NyeXB0b10KICAgMCAgICAgMyAgICAgMCAgIDAgLTE2ICAwICAgICAgICAwICAgICAg IDAgY3J5cHRvX3IgREwgICAgLSAgIDA6MDAuMDAgW2NyeXB0byByZXR1cm5zXQogICAwICAgICA0 ICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAgMCAtICAgICAgICBSTCAgICAtICAgMDow MC4wNCBbY2FtXQogICAwICAgICA1ICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAgMCAt ICAgICAgICBETCAgICAtICAgMDowMC4wMCBbY3RsXQogICAwICAgICA2ICAgICAwICAgMCAgLTgg IDAgICAgICAgIDAgICAgICAgMCBrbWVtIGFyZSBMTCAgICAtICAgMDowMC4wMSBbemZza2Vybl0K ICAgMCAgICAgNyAgICAgMCAgIDAgLTE2ICAwICAgICAgICAwICAgICAgIDAgd2FpdGluZ18gREwg ICAgLSAgIDA6MDAuMDAgW3NjdHBfaXRlcmF0b3JdCiAgIDAgICAgIDggICAgIDAgICAwIC0xNiAg MCAgICAgICAgMCAgICAgICAwIC0gICAgICAgIERMICAgIC0gICAwOjAwLjAwIFtyYW5kX2hhcnZl c3RxXQogICAwICAgICA5ICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAgMCAtICAgICAg ICBETCAgICAtICAgMDowMC4wMCBbc29haW9kMV0KICAgMCAgICAxMCAgICAgMCAgIDAgLTE2ICAw ICAgICAgICAwICAgICAgIDAgYXVkaXRfd28gREwgICAgLSAgIDA6MDAuMDAgW2F1ZGl0XQogICAw ICAgIDExICAgICAwICAgMCAxNTUgIDAgICAgICAgIDAgICAgICAgMCAtICAgICAgICBSTCAgICAt ICAgMDo0Ny4zMiBbaWRsZV0KICAgMCAgICAxMiAgICAgMCAgIDAgLTYwICAwICAgICAgICAwICAg ICAgIDAgLSAgICAgICAgV0wgICAgLSAgIDA6MDAuMTggW2ludHJdCiAgIDAgICAgMTMgICAgIDAg ICAwIC0xNiAgMCAgICAgICAgMCAgICAgICAwIHNsZWVwICAgIERMICAgIC0gICAwOjAwLjAwIFtu Z19xdWV1ZV0KICAgMCAgICAxNCAgICAgMCAgIDAgIC04ICAwICAgICAgICAwICAgICAgIDAgLSAg ICAgICAgREwgICAgLSAgIDA6MDAuMDYgW2dlb21dCiAgIDAgICAgMTUgICAgIDAgICAwIC02OCAg MCAgICAgICAgMCAgICAgICAwIC0gICAgICAgIERMICAgIC0gICAwOjAwLjAyIFt1c2JdCiAgIDAg ICAgMTYgICAgIDAgICAwIC0xNiAgMCAgICAgICAgMCAgICAgICAwIC0gICAgICAgIERMICAgIC0g ICAwOjAwLjAwIFtzb2Fpb2QyXQogICAwICAgIDE3ICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAg ICAgICAgMCAtICAgICAgICBETCAgICAtICAgMDowMC4wMCBbc29haW9kM10KICAgMCAgICAxOCAg ICAgMCAgIDAgLTE2ICAwICAgICAgICAwICAgICAgIDAgLSAgICAgICAgREwgICAgLSAgIDA6MDAu MDAgW3NvYWlvZDRdCiAgIDAgICAgMTkgICAgIDAgICAwIC0xNiAgMCAgICAgICAgMCAgICAgICAw IGlkbGUgICAgIERMICAgIC0gICAwOjAwLjAwIFtlbmNfZGFlbW9uMF0KICAgMCAgICAyMCAgICAg MCAgIDAgLTE2ICAwICAgICAgICAwICAgICAgIDAgcHNsZWVwICAgREwgICAgLSAgIDA6MDAuMDAg W3BhZ2VkYWVtb25dCiAgIDAgICAgMjEgICAgIDAgICAwIC0xNiAgMCAgICAgICAgMCAgICAgICAw IHBzbGVlcCAgIERMICAgIC0gICAwOjAwLjAwIFt2bWRhZW1vbl0KICAgMCAgICAyMiAgICAgMCAg IDAgLTE2ICAwICAgICAgICAwICAgICAgIDAgLSAgICAgICAgREwgICAgLSAgIDA6MDAuMDAgW2J1 ZnNwYWNlZGFlbW9uXQogICAwICAgIDIzICAgICAwICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAg MCBwc2xlZXAgICBETCAgICAtICAgMDowMC4wMCBbYnVmZGFlbW9uXQogICAwICAgIDI0ICAgICAw ICAgMCAtMTYgIDAgICAgICAgIDAgICAgICAgMCB2bHJ1d3QgICBETCAgICAtICAgMDowMC4wMCBb dm5scnVdCiAgIDAgICAgMjUgICAgIDAgICAwICAxNiAgMCAgICAgICAgMCAgICAgICAwIHN5bmNl ciAgIERMICAgIC0gICAwOjAwLjAwIFtzeW5jZXJdCiAgIDAgICAgMjYgICAgIDAgICAwICAxNiAg MCAgICAgICAgMCAgICAgICAwIGNfZmxvd2NsIERMICAgIC0gICAwOjAwLjAwIFtmbG93Y2xlYW5l cl0KICAgMCAgIDM3MSAgICAgMSAgIDAgIDUyICAwICAgIDEyNzUyICAgIDIxNjQgc2VsZWN0ICAg RHMgICAgLSAgIDA6MDAuMDAgW21vdXNlZF0KICAgMCAgIDM4MiAgICAgMSAgIDAgIDIwICAwICAg ICA5NTkyICAgIDQ5OTIgc2VsZWN0ICAgRHMgICAgLSAgIDA6MDAuMDMgW2RldmRdCiAgIDAgICA0 NTEgICAgIDEgICAwICAyMCAgMCAgICAxMjc1MiAgICAyMjUyIHNlbGVjdCAgIERzICAgIC0gICAw OjAwLjAwIFttb3VzZWRdCiAgIDAgICA1MjIgICAgIDEgICAwICA1MiAgMCAgICAxMDUwOCAgICAy MDkyIHBhdXNlICAgIERzICAgIC0gICAwOjAwLjAwIFtkYWVtb25dCiA5MjggICA1MjMgICA1MjIg ICAwICA1MiAgMCAgICA2MjA4NCAgICA4NDA4IG5hbnNscCAgIEQgICAgIC0gICAwOjAwLjEwIFtu c2xjZF0KICAgMCAgIDUzMiAgICAgMSAgIDAgIDIwICAwICAgIDEyNjEyICAgIDI1MTIgc2VsZWN0 ICAgRHMgICAgLSAgIDA6MDAuMDggW3N5c2xvZ2RdCiAgIDEgICA1NDAgICAgIDEgICAwICAyMCAg MCAgICAxMjU2MCAgICAyNDk2IHNlbGVjdCAgIERzICAgIC0gICAwOjAwLjAxIFtycGNiaW5kXQog Mzg5ICAgNjM3ICAgICAxICAgMCAgNTIgIDAgICAyOTQwOTIgICAxNTkwOCB1d2FpdCAgICBEcyAg ICAtICAgMDowMC4wOCBbc2xhcGRdCiAgIDAgICA2NzUgICAgIDEgICAwICA1MiAgMCAgICAxMDg0 MCAgICAyMjUyIHBhdXNlICAgIERzICAgIC0gICAwOjAwLjAwIFtuZnN1c2VyZF0KICAgMCAgIDY3 NiAgIDY3NSAgIDAgIDIwICAwICAgIDEwODQwICAgIDIyNTYgc2VsZWN0ICAgRCAgICAgLSAgIDA6 MDAuMDAgW25mc3VzZXJkXQogICAwICAgNjc3ICAgNjc1ICAgMCAgMjAgIDAgICAgMTA4NDAgICAg MjI1NiBzZWxlY3QgICBEICAgICAtICAgMDowMC4wMCBbbmZzdXNlcmRdCiAgIDAgICA2NzggICA2 NzUgICAwICAyMCAgMCAgICAxMDg0MCAgICAyMjU2IHNlbGVjdCAgIEQgICAgIC0gICAwOjAwLjAw IFtuZnN1c2VyZF0KICAgMCAgIDY3OSAgIDY3NSAgIDAgIDIwICAwICAgIDEwODQwICAgIDIyNTYg c2VsZWN0ICAgRCAgICAgLSAgIDA6MDAuMDAgW25mc3VzZXJkXQogICAwICAgNjg5ICAgICAxICAg MCAgMjAgIDAgICAyNzQ2NTYgICAgMzI0OCBzZWxlY3QgICBEcyAgICAtICAgMDowMC4wMCBbcnBj LnN0YXRkXQogICAwICAgNjk2ICAgICAxICAgMCAgNTIgIDAgICAgMTI1NjggICAgMzI2MCBycGNz dmMgICBEcyAgICAtICAgMDowMC4wMCBbcnBjLmxvY2tkXQogNTU2ICAgNzI2ICAgICAxICAgMCAg MjEgIDAgICAgMTUyNjQgICAgMzE5NiBzZWxlY3QgICBEcyAgICAtICAgMDowMC4wMiBbZGJ1cy1k YWVtb25dCiAgIDAgICA3NjEgICAgIDEgICAwICAyMCAgMCAgICAyMjc2OCAgIDEyNjI0IHNlbGVj dCAgIERzICAgIC0gICAwOjAwLjEwIFtudHBkXQogMTk0ICAgNzg4ICAgICAxICAgMCAgMjAgIDAg ICAgNDM4MjAgICAgMzQwNCBzZWxlY3QgICBEcyAgICAtICAgMDowMC4wMCBbc2FuZWRdCiAgIDAg ICA4NDcgICAgIDEgICAwICA1MiAgMCAgICA1OTk4OCAgICA3NjEyIHNlbGVjdCAgIERzICAgIC0g ICAwOjAwLjAwIFtzc2hkXQogICAwICAgODUyICAgICAxICAgMCAgMjAgIDAgICAgNjY5MDggICAg OTA1NiBrcXJlYWQgICBEcyAgICAtICAgMDowMC4wOSBbY3Vwc2RdCiA5NzAgICA4NTQgICAgIDEg ICAwICA1MiAgMCAgICA2NzQ4MCAgIDEwNTEyIHNlbGVjdCAgIEQgICAgIC0gICAwOjAwLjE1IFtj b2xvcmRdCiAgIDAgICA4NjkgICAgIDEgICAwICAyMCAgMCAgICA4ODE2NCAgICA5NjE2IHNlbGVj dCAgIERzICAgIC0gICAwOjAwLjAwIFtzZW5kbWFpbF0KICAyNSAgIDg3MiAgICAgMSAgIDAgIDIw ICAwICAgIDI1MDA0ICAgIDY3OTIgcGF1c2UgICAgRHMgICAgLSAgIDA6MDAuMDAgW3NlbmRtYWls XQogICAwICAgODc2ICAgICAxICAgMCAgMjAgIDAgICAgMTQ3MDggICAgMjYzNiBuYW5zbHAgICBE cyAgICAtICAgMDowMC4wMCBbY3Jvbl0KICAgMCAgIDg5OCAgICAgMSAgIDAgIDUyICAwICAgICA4 MzY4ICAgIDIwOTYgYWNjZXB0ICAgRHMgICAgLSAgIDA6MDAuMDAgW25mc2NiZF0KICAgMCAgIDg5 OSAgIDg5OCAgIDAgIDUyICAwICAgICA4MzY4ICAgIDIwOTYgcnBjc3ZjICAgRCAgICAgLSAgIDA6 MDAuMDAgW25mc2NiZF0KICAgMCAgIDkyNSAgICAgMSAgIDAgIDUyICAwICAgIDE0NzQ4ICAgIDI0 MTIgc2VsZWN0ICAgRHMgICAgLSAgIDA6MDAuMDAgW2luZXRkXQogICAwICAgOTQ3ICAgICAxICAg MCAgNTIgIDAgICAgMTA1NDQgICAgMjI1NiBrcXJlYWQgICBEcyAgICAtICAgMDowMC4wMCBbYXV0 b3VubW91bnRkXQogICAwICAgOTUxICAgICAxICAgMCAgNTIgIDAgICAgMTA1NDQgICAgMjI1MiBh dXRvZnNjdiBEcyAgICAtICAgMDowMC4wMCBbYXV0b21vdW50ZF0KICAgMCAgIDk1NiAgICAgMSAg IDAgIDUyICAwICAgIDEwNTI4ICAgIDIyNDggdHR5aW4gICAgRHMrICAgLSAgIDA6MDAuMDAgW2dl dHR5XQogICAwICAgOTU3ICAgICAxICAgMCAgNTIgIDAgICAgMTA1MjggICAgMjI0OCB0dHlpbiAg ICBEcysgICAtICAgMDowMC4wMCBbZ2V0dHldCiAgIDAgICA5NTggICAgIDEgICAwICA1MiAgMCAg ICAxMDUyOCAgICAyMjQ4IHR0eWluICAgIERzKyAgIC0gICAwOjAwLjAwIFtnZXR0eV0KICAgMCAg IDk1OSAgICAgMSAgIDAgIDUyICAwICAgIDEwNTI4ICAgIDIyNDggdHR5aW4gICAgRHMrICAgLSAg IDA6MDAuMDAgW2dldHR5XQogICAwICAgOTYwICAgICAxICAgMCAgNTIgIDAgICAgMTA1MjggICAg MjI0OCB0dHlpbiAgICBEcysgICAtICAgMDowMC4wMCBbZ2V0dHldCiAgIDAgICA5NjEgICAgIDEg ICAwICA1MiAgMCAgICAxMDUyOCAgICAyMjQ4IHR0eWluICAgIERzKyAgIC0gICAwOjAwLjAwIFtn ZXR0eV0KICAgMCAgIDk2MiAgICAgMSAgIDAgIDUyICAwICAgIDEwNTI4ICAgIDIyNDggdHR5aW4g ICAgRHMrICAgLSAgIDA6MDAuMDAgW2dldHR5XQogICAwICAgOTYzICAgICAxICAgMCAgNTIgIDAg ICAgMTA1MjggICAgMjI0OCB0dHlpbiAgICBEcysgICAtICAgMDowMC4wMCBbZ2V0dHldCiAgIDAg ICA5NjQgICAgIDEgICAwICA1MiAgMCAgICAxMDUyOCAgICAyMjQ4IHR0eWluICAgIERzKyAgIC0g ICAwOjAwLjAwIFtnZXR0eV0KICAgMCAgIDk2NSAgICAgMSAgIDAgIDM3ICAwICAgIDM5NzA4ICAg IDM3NjggcGF1c2UgICAgRCAgICAgLSAgIDA6MDAuMDEgW3hkbV0KICAgMCAgIDk2NyAgIDk2NSAg IDAgIDIwICAwIDEyNzU2NjUyICAgNzEwODQgc2VsZWN0ICAgRHMgICAgLSAgIDA6MDAuODkgW1hv cmddCiAgIDAgICA5NzAgICA5NjUgICAwICAyNyAgMCAgICA3MTAxNiAgICA3NzEyIHdhaXQgICAg IERzICAgIC0gICAwOjAwLjAwIFt4ZG1dCjIwMDIgICA5ODAgICA5NzAgICAwICA1MiAgMCAgICAx MzI0OCAgICAyNjA0IHdhaXQgICAgIERzICAgIC0gICAwOjAwLjAwIFtzaF0KMjAwMiAgIDk5MCAg IDk4MCAgIDAgIDUyICAwICAgMTEyNjEyICAgIDk1NDggd2FpdCAgICAgRCAgICAgLSAgIDA6MDAu MDAgW3dtYWtlcl0KMjAwMiAgIDk5MSAgIDk5MCAgIDAgIDIwICAwICAgIDMzNTk2ICAgIDM2MDQg c2VsZWN0ICAgRHMgICAgLSAgIDA6MDAuNDQgW2dwZy1hZ2VudF0KMjAwMiAgIDk5MiAgIDk5MCAg IDAgIDIwICAwICAgMTI2Mjc2ICAgMTg0NzIgc2VsZWN0ICAgRCAgICAgLSAgIDA6MDAuMDAgW3dt YWtlcl0KMjAwMiAgMTAwMSAgIDk5MiAgIDAgIDI0ICAwICAzMTMxMjA0IDI2NjMzMDggc2VsZWN0 ICAgRHMgICAgLSAgMjE6MTIuNzIgW2ZpcmVmb3hdCjIwMDIgIDEwMDYgICAgIDEgICAwICA1MiAg MCAgICAyNjQ1MiAgICAzNjI4IHNlbGVjdCAgIEQgICAgIC0gICAwOjAwLjAwIFtkYnVzLWxhdW5j aF0KMjAwMiAgMTAwNyAgICAgMSAgIDAgIDIwICAwICAgIDE1MjY0ICAgIDMwMzIgc2VsZWN0ICAg RHMgICAgLSAgIDA6MDAuMDAgW2RidXMtZGFlbW9uXQogICAwICAxMDA5ICAgICAxICAgMCAgMjAg IDAgICAgNDY4NjQgICAgNjQ0MCBzZWxlY3QgICBEICAgICAtICAgMDowMC4wMCBbdXBvd2VyZF0K ICAgMCAgMTAxMSAgICAgMSAgIDAgIDIxICAwICAgIDcwMjE2ICAgIDczNDAgbiAgICAgICAgRCAg ICAgLSAgIDA6MDAuMDAgW2NvbnNvbGUta2l0LWRhZW1vbl0KIDU2NSAgMTAxMyAgICAgMSAgIDAg IDIwICAwICAgIDkxNjUyICAgMTI5ODQgc2VsZWN0ICAgRCAgICAgLSAgIDA6MDAuMDAgW3BvbGtp dGRdCjIwMDIgIDEwMzQgICA5OTIgICAwICAyMCAgMCAgICA3NDA1MiAgIDExNjEyIHNlbGVjdCAg IERzICAgIC0gICAwOjAwLjAwIFt4dGVybV0KMjAwMiAgMTAzNiAgMTAzNCAgIDAgIDI3ICAwICAg IDEzMjQ4ICAgIDMxODQgd2FpdCAgICAgRHMgICAgLSAgIDA6MDAuMDAgW3NoXQogICAwICAxMDM5 ICAxMDM2ICAgMCAgMjEgIDAgICAgNjY0ODQgICAgNzUxMiBzZWxlY3QgICBEICAgICAtICAgMDow MC4wMSBbc3Vkb10KICAgMCAgMTA0MCAgMTAzOSAgIDAgIDIxICAwICAgIDUwMDA4ICAgIDMxNjAg d2FpdCAgICAgRCAgICAgLSAgIDA6MDAuMDAgW3N1XQogICAwICAxMDQxICAxMDQwICAgMCAgMjUg IDAgICAgMjE3ODQgICAgMzc2OCB0dHlpbiAgICBEKyAgICAtICAgMDowMC4wMCBbY3NoXQoyMDAy ICAxMTExICAgOTkyICAgMCAgMjAgIDAgICAgNzQwNTIgICAxMTg0MCBzZWxlY3QgICBEcyAgICAt ICAgMDowMC4wMCBbeHRlcm1dCjIwMDIgIDExMTMgIDExMTEgICAwICAyMCAgMCAgICAxMzI0OCAg ICAzMjEyIHdhaXQgICAgIERzICAgIC0gICAwOjAwLjAwIFtzaF0KICAgMCAgMTEyNCAgMTExMyAg IDAgIDIwICAwICAgIDY2NDg0ICAgIDc1NTYgc2VsZWN0ICAgRCsgICAgLSAgIDA6MDAuMDEgW3N1 ZG9dCiAgIDAgIDExMjUgIDExMjQgICAwICAyNiAgMCAgICAgNTAyOCAgICAxMDIwIHdhaXQgICAg IEQrICAgIC0gICAwOjAwLjAwIFttYWtlXQogICAwICAxMTI4ICAxMTI1ICAgMCAgNTIgIDAgICAg MTMyNDggICAgMzI3MiB3YWl0ICAgICBEKyAgICAtICAgMDowMC4wMCBbc2hdCiAgIDAgNDIxMDAg IDExMjggICAwICA1MiAgMCAgICAxMzI0OCAgICAzMjcyIHdhaXQgICAgIEQrICAgIC0gICAwOjAw LjAwIFtzaF0KICAgMCA0MjEwNyA0MjEwMCAgIDAgIDUyICAwICAgICA1MDI4ICAgIDExODAgd2Fp dCAgICAgRCsgICAgLSAgIDA6MDAuMDAgW21ha2VdCiAgIDAgNDIxMjMgNDIxMDcgICAwICAyNiAg MCAgICAgNTAyOCAgICAyMTA0IHdhaXQgICAgIEQrICAgIC0gICAwOjAwLjAwIFttYWtlXQogICAw IDQyMjU3IDQyMTIzICAgMCAgMjcgIDAgICAgMTMyNDggICAgMzA2NCB3YWl0ICAgICBEKyAgICAt ICAgMDowMC4wMCBbc2hdCiAgIDAgNDIyNTggNDIyNTcgICAwICA1MiAgMCAgICAgNTAyOCAgICAy MTIwIHdhaXQgICAgIEQrICAgIC0gICAwOjAwLjAwIFttYWtlXQogICAwIDQyMzI0IDQyMjU4ICAg MCAgMzcgIDAgICAgIDUwMjggICAgMjEyNCB3YWl0ICAgICBEKyAgICAtICAgMDowMC4wMCBbbWFr ZV0KICAgMCA0ODI2OSA0MjMyNCAgIDAgIDUyICAwICAgIDExMTcyICAgIDgwMjQgd2FpdCAgICAg RCsgICAgLSAgIDA6MDAuMDAgW21ha2VdCiAgIDAgNDkwMDUgNDgyNjkgICAwICA1MiAgMCAgICAg NTAyOCAgICAxNDA0IHdhaXQgICAgIEQrICAgIC0gICAwOjAwLjAwIFttYWtlXQogICAwIDQ5MDE1 IDQ5MDA1ICAgMCAgNzIgIDAgICAgIDUwMjggICAgMTY0NCBrbWVtIGFyZSBMKyAgICAtICAgMDow MC4wMCBbbWFrZV0KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLXMKCiAyODUwMzUzMyBjcHUgY29u dGV4dCBzd2l0Y2hlcwogIDEyNzU1NTcgZGV2aWNlIGludGVycnVwdHMKICAxMTI1ODczIHNvZnR3 YXJlIGludGVycnVwdHMKIDMwMjI5ODUyIHRyYXBzCiA1ODM2OTg5MSBzeXN0ZW0gY2FsbHMKICAg ICAgIDI2IGtlcm5lbCB0aHJlYWRzIGNyZWF0ZWQKICAgICAyNTg4ICBmb3JrKCkgY2FsbHMKICAg IDQ2NDAzIHZmb3JrKCkgY2FsbHMKICAgICAgICAwIHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3 YXAgcGFnZXIgcGFnZWlucwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAg ICAgIDAgc3dhcCBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdl ZCBvdXQKICAgMTQ5MDUwIHZub2RlIHBhZ2VyIHBhZ2VpbnMKICAgMTQ5MTU1IHZub2RlIHBhZ2Vy IHBhZ2VzIHBhZ2VkIGluCiAgICAgICAyMSB2bm9kZSBwYWdlciBwYWdlb3V0cwogICAgICAgNDIg dm5vZGUgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgICAgMCBwYWdlIGRhZW1vbiB3YWtldXBz CiAgICAgICAgMCBwYWdlcyBleGFtaW5lZCBieSB0aGUgcGFnZSBkYWVtb24KICAgICAgICAwIHBh Z2VzIHJlYWN0aXZhdGVkCiAgMTgwNjkxOCBjb3B5LW9uLXdyaXRlIGZhdWx0cwogICAgICAyOTUg Y29weS1vbi13cml0ZSBvcHRpbWl6ZWQgZmF1bHRzCiAxNTY2NzI5NiB6ZXJvIGZpbGwgcGFnZXMg emVyb2VkCiAgICAgNTQ2OSB6ZXJvIGZpbGwgcGFnZXMgcHJlemVyb2VkCiAgICAgIDEzNSBpbnRy YW5zaXQgYmxvY2tpbmcgcGFnZSBmYXVsdHMKIDE5NDQwMzExIHRvdGFsIFZNIGZhdWx0cyB0YWtl bgogICAxNTY2NzMgcGFnZSBmYXVsdHMgcmVxdWlyaW5nIEkvTwogICAgICAgIDAgcGFnZXMgYWZm ZWN0ZWQgYnkga2VybmVsIHRocmVhZCBjcmVhdGlvbgogICAxMTIyMDUgcGFnZXMgYWZmZWN0ZWQg YnkgIGZvcmsoKQogIDIwODgyMDIgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAg cGFnZXMgYWZmZWN0ZWQgYnkgcmZvcmsoKQogICAgICAgIDAgcGFnZXMgY2FjaGVkCiAxODE5MDQ1 OSBwYWdlcyBmcmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgICAgICAgMCBw YWdlcyBmcmVlZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICAxOTIwNjIgcGFnZXMgYWN0aXZlCiAg IDYwNTY1MCBwYWdlcyBpbmFjdGl2ZQogICAgICAgIDAgcGFnZXMgaW4gVk0gY2FjaGUKICAgOTI0 MDQxIHBhZ2VzIHdpcmVkIGRvd24KICAgMzAxMjg0IHBhZ2VzIGZyZWUKICAgICA0MDk2IGJ5dGVz IHBlciBwYWdlCiAgICAgICAgMCB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNhY2hlIGhp dHMgKDAlIHBvcyArIDAlIG5lZykgc3lzdGVtIDAlIHBlci1kaXJlY3RvcnkKICAgICAgICAgIGRl bGV0aW9ucyAwJSwgZmFsc2VoaXRzIDAlLCB0b29sb25nIDAlCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1z dGF0IC1tCgogICAgICAgICBUeXBlIEluVXNlIE1lbVVzZSBIaWdoVXNlIFJlcXVlc3RzICBTaXpl KHMpCiAgICAgIGVudHJvcHkgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNDYgIDQwOTYKICAg ICAgc29sYXJpcyAzMDkyOTEgOTg1NjRLICAgICAgIC0gMTA5Nzc0NDIxICAxNiwzMiw2NCwxMjgs MjU2LDUxMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDMyNzY4CiAgICAgICAgIGhkYWEgICAgMTAgICAg NjNLICAgICAgIC0gICAgICAgMTAgIDEyOCwxMDI0LDIwNDgsNDA5NiwxNjM4NCwzMjc2OAogICAg ICAgICBoZGFjICAgICAyICAgICAySyAgICAgICAtICAgICAgICAyICAxMDI0CiAgICAgICAgaGRh Y2MgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDMyCiAgICAgICBmZWVkZXIgICAgMzYg ICAgIDRLICAgICAgIC0gICAgICAxNDYgIDMyLDEyOAogICAgICAgIG1peGVyICAgICA3ICAgIDI4 SyAgICAgICAtICAgICAgICA3ICA0MDk2CiAgIGtzdGF0X2RhdGEgICAgIDYgICAgIDFLICAgICAg IC0gICAgICAgIDYgIDY0CiAgICAgICAgICBVU0IgICAgOTYgICAxNzFLICAgICAgIC0gICAgICAx MTQgIDE2LDMyLDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2LDE2Mzg0LDMyNzY4CiAgICAgICBV U0JkZXYgICAgNzIgICAgMTdLICAgICAgIC0gICAgICAgNzQgIDMyLDY0LDEyOCwyNTYsNTEyLDQw OTYKICAgICAgQ0FNIFNJTSAgICAxMiAgICAgM0sgICAgICAgLSAgICAgICAxMiAgMjU2CiAgICAg IENBTSBYUFQgICAgNjcgICAgIDZLICAgICAgIC0gICAgICAzNjAgIDE2LDMyLDY0LDEyOCwyNTYs NTEyLDEwMjQsMjA0OCw2NTUzNgogICAgICBDQU0gREVWICAgIDE4ICAgIDM2SyAgICAgICAtICAg ICAgIDMxICAyMDQ4CiAgICAgIENBTSBDQ0IgICAgIDAgICAgIDBLICAgICAgIC0gICAxMjQ0NzMg IDIwNDgKICAgICBDQU0gcGF0aCAgICAyNSAgICAgMUsgICAgICAgLSAgICAgIDEzOSAgMzIKICBk ZGJfY2FwdHVyZSAgICAgMSAgICA2NEsgICAgICAgLSAgICAgICAgMSAgNjU1MzYKICAgICBhY3Bp aW50ciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQKICAgICAgIGFjcGljYSAgNTY2 NiAgIDU4MEsgICAgICAgLSAgICA1ODY0NCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4 LDQwOTYKICAgICAgICB2dGJ1ZiAgICAyMCAgMTY0MEsgICAgICAgLSAgICAgICAzOCAgNDA5Ngog ICAgICAgICAgIHZ0ICAgICA5ICAgICA1SyAgICAgICAtICAgICAgICA5ICA1MTIKICAgICBzeXNt b3VzZSAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMyAgMjA0OAogICAgICAgYXV0b2ZzICAg ICA1ICAgIDE3SyAgICAgICAtICAgICAgICA1ICAxNiwxMjgsODE5MgogICAgIGFjcGl0YXNrICAg ICAxICAgIDY0SyAgICAgICAtICAgICAgICAxICA2NTUzNgogICAgICBhY3Bpc2VtICAgIDc2ICAg IDEwSyAgICAgICAtICAgICAgIDc2ICAxMjgKICAgQ0FNIHBlcmlwaCAgICAxNiAgICAgNEsgICAg ICAgLSAgICAgIDY4NiAgMTYsMzIsNjQsMTI4LDI1NgogICAgICBhY3BpZGV2ICAgIDQ3ICAgICAz SyAgICAgICAtICAgICAgIDQ3ICA2NApDQU0gSS9PIFNjaGVkdWxlciAgICAgNSAgICAgNUsgICAg ICAgLSAgICAgICAgNSAgMTAyNAogICAgQ0FNIHF1ZXVlICAgIDMwICAgIDEwSyAgICAgICAtICAg ICAgIDc1ICAxNiwzMiw1MTIKICAgICAgc2NzaV9jZCAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICAgOCAgMTYKICAgICAgIERFVkZTMyAgIDIyNiAgICA1N0sgICAgICAgLSAgICAgIDI1MyAgMjU2 CiAgICAgICBERVZGUzEgICAxOTQgICAgOTdLICAgICAgIC0gICAgICAyMTcgIDUxMgogICBERVZG U19SVUxFICAgIDU4ICAgIDI3SyAgICAgICAtICAgICAgIDU4ICA2NCw1MTIKICAgICAgICBERVZG UyAgICAyNCAgICAgMUsgICAgICAgLSAgICAgICAyNSAgMTYsMTI4CiAgICAgICBERVZGU1AgICAg MTYgICAgIDFLICAgICAgIC0gICAgICAgMjMgIDY0CiAgZmRlc2NfbW91bnQgICAgIDEgICAgIDFL ICAgICAgIC0gICAgICAgIDEgIDE2Ck5GU0QgVjRjbGllbnQgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDI1NgogTkZTRCBsY2tmaWxlICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAx ICAyNTYKICBORlNEIHN0cmluZyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIKTkZT RCB1c3Jncm91cCAgIDEzMyAgICA0OUsgICAgICAgLSAgICAgIDEzNiAgMTI4LDgxOTIKIE5GU0Qg c2Vzc2lvbiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTAyNAogICAgcGZzX25vZGVz ICAgIDIxICAgICA2SyAgICAgICAtICAgICAgIDIxICAyNTYKICBwZnNfdm5jYWNoZSAgICAgNiAg ICAgMUsgICAgICAgLSAgICAgICAgOCAgNjQKICB0bXBmcyBtb3VudCAgICAgMiAgICAgMUsgICAg ICAgLSAgICAgICAgMiAgMTI4CiAgIHRtcGZzIG5hbWUgIDIxMDkgICAgNDRLICAgICAgIC0gICAg NzY3NDYgIDE2LDMyCiAgICAgIGdnX2RhdGEgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEg IDIwNDgKICAgICAgICAgR0VPTSAgIDM2NCAgICA1OUsgICAgICAgLSAgICAgMzYyMyAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDgxOTIsMTYzODQKICAgIHJhaWRfZGF0YSAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgIDQ0NCAgMzIsMTI4LDI1NgogICAgICAgaXNhZGV2ICAgICA3ICAg ICAxSyAgICAgICAtICAgICAgICA3ICAxMjgKICAgICAgIGN0bG1lbSAgICAgNiAgIDE5M0sgICAg ICAgLSAgICAgICAgNiAgMTYsMzIsNjU1MzYKICAgICBwY2lfbGluayAgICAxNiAgICAgMksgICAg ICAgLSAgICAgICAxNiAgNjQsMTI4CiAgICBhY3BpX3BlcmYgICAgIDQgICAgIDJLICAgICAgIC0g ICAgICAgIDQgIDUxMgogICAgICAgICBjZGV2ICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA1 ICAyNTYKICAgICBmaWxlZGVzYyAgICAxMCAgICA0MUsgICAgICAgLSAgICAgICAzNCAgMTYsNDA5 Niw4MTkyCiAgICAgICAgc2lnaW8gICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDY0CiAg ICAgZmlsZWNhcHMgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMjMgIDE2CiAgICAgIGtkdHJh Y2UgICA5MzEgICAyMTVLICAgICAgIC0gICAgNTA0NTIgIDY0LDI1NgogICAgICAgICBrZW52ICAg MTIyICAgIDEzSyAgICAgICAtICAgICAgMTI2ICAxNiwzMiw2NCwxMjgsODE5MgogICAgICAga3F1 ZXVlICAgMTEzICAgIDIzSyAgICAgICAtICAgIDQ5MDM2ICA2NCwyNTYsNTEyLDIwNDgKICAgIHBy b2MtYXJncyAgICA2OCAgICAgNUsgICAgICAgLSAgICA1MDIxNyAgMTYsMzIsNjQsMTI4LDI1Ngog ICAgICAgIGhob29rICAgIDEzICAgICAzSyAgICAgICAtICAgICAgIDEzICAzMiwyNTYKICAgICAg aXRocmVhZCAgIDEwOCAgICAxOEsgICAgICAgLSAgICAgIDEwOCAgMzIsMTI4LDI1NgogICAgICAg S1RSQUNFICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAgIGxpbmtlciAg IDE1MiAgNTM2MUsgICAgICAgLSAgICAgIDE3MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwy MDQ4LDMyNzY4LDY1NTM2CiAgICAgICAgbG9ja2YgICAgNjAgICAgIDdLICAgICAgIC0gICAgODA1 OTUgIDY0LDEyOAogICBsb2dpbmNsYXNzICAgICAzICAgICAxSyAgICAgICAtICAgICAgICA0ICA2 NAogICAgICAgIGNhY2hlICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAzMgogICAgICAg ZGV2YnVmIDIwMjkzIDQwNTk4SyAgICAgICAtICAgIDIxMTU2ICAxNiwzMiw2NCwxMjgsMjU2LDUx MiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2Mzg0LDMyNzY4LDY1NTM2CiAgICAgICAgIHRlbXAgICAg NDAgICAgIDJLICAgICAgIC0gMTM1MDc1NDMgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OCw4MTkyLDE2Mzg0LDY1NTM2CiAgICAgICBtb2R1bGUgICAzMTYgICAgNDBLICAgICAgIC0gICAg ICAzMTcgIDEyOAogICAgIG10eF9wb29sICAgICAzICAgIDg0SyAgICAgICAtICAgICAgICAzICA4 MTkyCiAgICAgICAgICBvc2QgICAgNTAgICAgIDJLICAgICAgIC0gICAgNDY4MzUgIDE2LDMyLDY0 LDEyOCwyNTYKICAgICBwbWNob29rcyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4 CiAgICAgICAgIHBncnAgICAgNDUgICAgIDZLICAgICAgIC0gICAgMTYzNjEgIDEyOAogICAgICBz ZXNzaW9uICAgIDQyICAgICA2SyAgICAgICAtICAgICAgIDYzICAxMjgKICAgICAgICAgcHJvYyAg ICAgMiAgICAzMksgICAgICAgLSAgICAgICAgMiAgMTYzODQKICAgICAgc3VicHJvYyAgIDI2MCAg IDQ3MEsgICAgICAgLSAgICA0OTE4MSAgNTEyLDQwOTYKICAgICAgICAgY3JlZCAgICA3MCAgICAx OEsgICAgICAgLSAgICAgMTc4NCAgMjU2CiAgICAgIHJhbWRpc2sgICAgIDEgIDEwMjRLICAgICAg IC0gICAgICAgIDEgIAogICAgICAgcGxpbWl0ICAgIDQwICAgIDEwSyAgICAgICAtICAgICAgNzI3 ICAyNTYKICAgICAgdWlkaW5mbyAgICAxMSAgICAgNksgICAgICAgLSAgICAgICAzNSAgMTI4LDQw OTYKICAgICAgIGR1bXBlciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNTEyCkNBTSBk ZXYgcXVldWUgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMTIgIDY0CiAgICAgICBzeXNjdGwg ICAgIDAgICAgIDBLICAgICAgIC0gICAgNTk0MTIgIDE2LDMyLDY0CiAgICBzeXNjdGxvaWQgIDcw MjkgICAzNjVLICAgICAgIC0gICAgIDcxNDIgIDE2LDMyLDY0LDEyOAogICAgc3lzY3RsdG1wICAg ICAwICAgICAwSyAgICAgICAtICAgIDExOTkwICAxNiwzMiw2NCwyNTYsMTAyNAogICAgICBzY3Np X2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA3ICAxNgogICAgICB0aWRoYXNoICAgICAx ICAgIDMySyAgICAgICAtICAgICAgICAxICAzMjc2OAogICAgICBjYWxsb3V0ICAgICA1ICAyMTg0 SyAgICAgICAtICAgICAgICA1ICAKICAgICAgICAgdW10eCAgMTcyOCAgIDIxNksgICAgICAgLSAg ICAgMTcyOCAgMTI4CiAgICAgcDEwMDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDE2CiAgICAgICAgIFNXQVAgICAgIDIgIDg3NDFLICAgICAgIC0gICAgICAgIDIgIDY0CiAgICAg ICAgICBidXMgICA4ODMgICAgODRLICAgICAgIC0gICAgIDQ1MjcgIDE2LDMyLDY0LDEyOCwyNTYs MTAyNAogICAgICAgYnVzLXNjICAgIDk5ICAxOTExSyAgICAgICAtICAgICAgODY5ICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2Mzg0LDY1NTM2CiAgICAgIGRldnN0 YXQgICAgMjQgICAgNDlLICAgICAgIC0gICAgICAgMjQgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAg IDExMiAgICAgOUsgICAgICAgLSAgICAgIDExMiAgNjQsMTI4CiAgICB0YXNrcXVldWUgICAgMTcg ICAgMThLICAgICAgIC0gICAgICAgMTcgIDE2LDMyLDI1Niw4MTkyCiAgICAgICAgIGtvYmogICAx NTggICA2MzJLICAgICAgIC0gICAgICA4NjAgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAg MUsgICAgICAgLSAgICAgICAgMSAgMzIKICAgICAgICAgcm1hbiAgIDI2MSAgICAzMEsgICAgICAg LSAgICAgIDYxNyAgMzIsMTI4CiAgICAgICAgIHNidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAg IDQzMTEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2LDgxOTIsMTYzODQsMzI3 NjgsNjU1MzYKICAgICAgIHNnbGlzdCAgICA1MCAgICA3OEsgICAgICAgLSAgICAgICA2NiAgMzIs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYsODE5Miw2NTUzNgogICAgdG9wb25vZGVzICAgIDEy ICAgICAySyAgICAgICAtICAgICAgIDEyICAxMjgKICAgIHRhc2txdWV1ZSAgIDI3MCAgICAzMUsg ICAgICAgLSAgICAgIDQ3NCAgMTYsMzIsNjQsMTI4LDI1NgogICAgIHRlcm1pbmFsICAgICA5ICAg ICAzSyAgICAgICAtICAgICAgICA5ICAyNTYKICAgICAgIFVuaXRubyAgICAyNyAgICAgMksgICAg ICAgLSAgIDE2ODU3NSAgMzIsNjQKICAgICAgICAgdm1lbSAgICAgMyAgIDY1NksgICAgICAgLSAg ICAgICAxMCAgMjA0OCw4MTkyLDE2Mzg0LDMyNzY4LDY1NTM2CiAgICAgIFdpdG5lc3MgIDE1Mzkg IDMyODJLICAgICAgIC0gICAgIDE1MzkgIDIwNDgsMTYzODQKICAgICBpb2N0bG9wcyAgICAgMSAg ICAgOEsgICAgICAgLSAgICAgIDE0MiAgMjU2LDEwMjQsNDA5Niw4MTkyCiAgICAgICBzZWxlY3Qg ICAxNDAgICAgMThLICAgICAgIC0gICAgICAxNDAgIDEyOAogICAgICAgICAgaW92ICAgICAwICAg ICAwSyAgICAgICAtICA0OTQ0OTIyICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAgICAgbXNn ICAgICA0ICAgIDMwSyAgICAgICAtICAgICAgICA0ICAyMDQ4LDQwOTYsODE5MiwxNjM4NAogICAg ICAgICAgc2VtICAgICA0ICAgMTA2SyAgICAgICAtICAgICAgICA0ICAyMDQ4LDQwOTYKICAgICAg ICAgIHNobSAgICAgNCAgICAzOEsgICAgICAgLSAgICAgICAxOSAgMjA0OCwzMjc2OAogICAgICAg ICAgdHR5ICAgIDEzICAgIDEzSyAgICAgICAtICAgICAgIDEzICAxMDI0CiAgICAgICAgICBwdHMg ICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogICAgIG1idWZfdGFnICAgICAwICAg ICAwSyAgICAgICAtICAgICAgICAyICAzMgogICAgICAgICBrc2VtICAgICAxICAgICA4SyAgICAg ICAtICAgICAgICAxICA4MTkyCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAg ICAgIDEgIDgxOTIKICAgICAgIHNvbmFtZSAgICAzMyAgICAgNEsgICAgICAgLSAgICA0MDIxMSAg MTYsMzIsNjQsMTI4CiAgICAgICAgICBwY2IgICAgNDUgIDExNzZLICAgICAgIC0gICAgICAzOTIg IDE2LDMyLDEyOCwxMDI0LDIwNDgsODE5MgogICAgICAgICAgYWNsICAgICAwICAgICAwSyAgICAg ICAtIDEzMzU5Njc4ICA0MDk2CiAgICAgdmZzY2FjaGUgICAgIDQgIDIxMjlLICAgICAgIC0gICAg ICAgIDQgIDUxMiwxNjM4NCw2NTUzNgogICAgIHZmc19oYXNoICAgICAxICAxMDI0SyAgICAgICAt ICAgICAgICAxICAKICAgICAgIHZub2RlcyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg MjU2CiAgICAgICAgbW91bnQgICAyODUgICAgMTRLICAgICAgIC0gICAgICA0MzAgIDE2LDMyLDY0 LDEyOCwyNTYKICAgICBTQ1NJIEVOQyAgICAyNSAgIDEwMEsgICAgICAgLSAgICAgIDMwNiAgMTYs NjQsMjU2LDIwNDgsMzI3NjgKICB2bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgICAg MTg4NSAgMTAyNAogICAgICBmYWR2aXNlICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTgxICAz MgogICAgICBHU1MtQVBJICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NAogICAgICAg IGljb252ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAxMjgKICAgICAgICAgIEJQRiAg ICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4CiAgICBmbG93dGFibGUgICAgIDYgICA1 NTJLICAgICAgIC0gICAgICAgIDYgIDgxOTIKICAgICAgICBpZm5ldCAgICAgNSAgICAgOUsgICAg ICAgLSAgICAgICAgNSAgMTI4LDIwNDgKICAgICAgIGlmYWRkciAgICAyMCAgICAgN0sgICAgICAg LSAgICAgICAyMCAgMzIsMjU2LDUxMiw0MDk2CiAgZXRoZXJfbXVsdGkgICAgIDcgICAgIDFLICAg ICAgIC0gICAgICAgIDcgIDE2LDY0CiAgICAgICAgY2xvbmUgICAgIDggICAgIDFLICAgICAgIC0g ICAgICAgIDggIDEyOAogICAgICBsbHRhYmxlICAgIDExICAgICA0SyAgICAgICAtICAgICAgIDEy ICAyNTYsNTEyCiAgICAgcm91dGV0YmwgICAgIDkgICAgIDJLICAgICAgIC0gICAgICAgMTAgIDMy LDEyOCw1MTIKICAgICBuZXRncmFwaCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQK bmV0Z3JhcGhfbm9kZSAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4LDI1NgogICAg ICAgICBpZ21wICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA0ICAxMjgKICAgICAgICAgaXBp ZCAgICAgMiAgICAyNEsgICAgICAgLSAgICAgICAgMiAgODE5MiwxNjM4NAogICBpbl9tZmlsdGVy ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxMDI0CiAgICAgaW5fbXVsdGkgICAgIDIg ICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogIGlwX21vcHRpb25zICAgICAyICAgICAxSyAg ICAgICAtICAgICAgICAyICA2NCwyNTYKZW5jYXBfZXhwb3J0X2hvc3QgICAgIDEgICAgIDFLICAg ICAgIC0gICAgICAgIDEgIDEwMjQKICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAgMSAgMTYKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg NjQKICAgICBzY3RwX2lmYSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAg c2N0cF9pZm4gICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgc2N0cF9pdGVy ICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAxICAyNTYKICAgIGhvc3RjYWNoZSAgICAgMSAg ICAzMksgICAgICAgLSAgICAgICAgMSAgMzI3NjgKICAgICAgdGNwZnVuYyAgICAgMSAgICAgMUsg ICAgICAgLSAgICAgICAgMSAgMzIKICAgICBzeW5jYWNoZSAgICAgMSAgICA2NEsgICAgICAgLSAg ICAgICAgMSAgNjU1MzYKICBpbnBjYnBvbGljeSAgICA0MSAgICAgMksgICAgICAgLSAgICAgIDQ3 MCAgMzIKICBpcHNlY3BvbGljeSAgICA4MiAgICAyMUsgICAgICAgLSAgICAgIDk1NiAgMjU2CiAg ICAgZHVtbXluZXQgICAgIDMgICAgIDNLICAgICAgIC0gICAgICAgIDMgIDUxMiwxMDI0CiAgSXBG dy9JcEFjY3QgICAgNTAgICAgNTNLICAgICAgIC0gICAgICAgODMgIDE2LDMyLDY0LDEyOCwyNTYs NTEyLDEwMjQsMjA0OCw0MDk2LDgxOTIsMTYzODQKICAgICAgICAgIE5MTSAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICAgMSAgMTYKICAgICAgIGNyeXB0byAgICAgMSAgICAgMUsgICAgICAgLSAg ICAgICAgMSAgNTEyCiAgICAgICAgeGZvcm0gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNTgg IDE2LDMyCiAgICAgICAgICBycGMgICAgNDEgICAgMzBLICAgICAgIC0gICAgICAxMDkgIDE2LDMy LDY0LDEyOCwyNTYsNTEyLDEwMjQsODE5MgphdWRpdF9ldmNsYXNzICAgMTg5ICAgICA2SyAgICAg ICAtICAgICAgMjMzICAzMgogICAgICBwYWdlZGVwICAgICA3ICAxNzkySyAgICAgICAtICAgICAg IDM3ICAyNTYKICAgICBpbm9kZWRlcCAgICAgNyAgNzE2OEsgICAgICAgLSAgICAgICA5MSAgNTEy CiAgICBibXNhZmVtYXAgICAgIDcgICAgNTZLICAgICAgIC0gICAgICAgNTAgIDI1Niw4MTkyCiAg ICAgICBuZXdibGsgICAgIDcgMTQzMzZLICAgICAgIC0gICAgICAxMjEgIDI1NgogICAgIGluZGly ZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA2ICAxMjgsMzI3NjgKICAgICBmcmVlZnJh ZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxNCAgMTI4CiAgICAgZnJlZWJsa3MgICAgIDAg ICAgIDBLICAgICAgIC0gICAgICAgMjIgIDI1NgogICAgIGZyZWVmaWxlICAgICAwICAgICAwSyAg ICAgICAtICAgICAgIDIyICA2NAogICAgICAgZGlyYWRkICAgICAwICAgICAwSyAgICAgICAtICAg ICAgIDM4ICAxMjgKICAgICAgICBta2RpciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAg MTI4CiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMzIgIDEyOAogICAg bmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAxICA2NAogICAgIGZyZWV3b3Jr ICAgICA3ICAgICAxSyAgICAgICAtICAgICAgIDQ2ICAxNiwxMjgKICAgICAgamFkZHJlZiAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICA0MCAgMTI4CiAgICAgIGpyZW1yZWYgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAgMzQgIDEyOAogICAgICBqbmV3YmxrICAgICAwICAgICAwSyAgICAgICAt ICAgICAgMTE0ICAxMjgKICAgIGpmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAx NCAgMTI4CiAgICAgICAgIGpzZWcgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNDggIDEyOAog ICAgICBqc2VnZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgMjAyICA2NAogICAgICAgIHNi ZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDM3ICA2NAogICAgIHNhdmVkaW5vICAgICAw ICAgICAwSyAgICAgICAtICAgICAgICA3ICAyNTYKICAgICAgamJsb2NrcyAgICAxNCAgICAgNUsg ICAgICAgLSAgICAgICAxOSAgMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgIHNvZnRkZXAgICAg IDcgICAgIDRLICAgICAgIC0gICAgICAgIDcgIDUxMgogIHVmc19kaXJoYXNoICAgMTQ0ICAgIDM3 SyAgICAgICAtICAgICAgMTYyICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgIHVm c19xdW90YSAgICAgMSAgMTAyNEsgICAgICAgLSAgICAgICAgMSAgCiAgICB1ZnNfbW91bnQgICAg MjEgICAgODhLICAgICAgIC0gICAgICAgMjEgIDUxMiw0MDk2LDgxOTIKICAgIHZtX3BnZGF0YSAg ICAgMiAgMTAyNUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgIFVNQUhhc2ggICAgMzMgICA3 MDdLICAgICAgIC0gICAgICAxNTggIDUxMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2Mzg0LDMyNzY4 LDY1NTM2CiAgICAgICAgICBwbWMgIDEwNjYgIDY2NzlLICAgICAgIC0gICAgIDEwNjYgIDE2LDMy LDEyOCwyNTYsNTEyLDEwMjQsNDA5Niw4MTkyLDY1NTM2CiAgICAgIG1lbWRlc2MgICAgIDEgICAg IDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAgIGNwdWN0bCAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgMzIKICAgICAgICAgIGljbCAgICAgMyAgICAgMUsgICAgICAgLSAgICAg ICAgMyAgMTYsNjQKICAgICAgIGFwbWRldiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg MTI4CiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAg ICAgICBpU0NTSSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAgICAgICBrYmRt dXggICAgIDcgICAgMjJLICAgICAgIC0gICAgICAgIDcgIDE2LDUxMiwxMDI0LDIwNDgsMTYzODQK ICAgICAgICAgIExFRCAgICAyNiAgICAgMksgICAgICAgLSAgICAgICAyNiAgMTYsMTI4CiAgICAg IGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAgICAgICAgIE1D QSAgICAxMiAgICAgMksgICAgICAgLSAgICAgICAxMiAgMzIsNjQsMTI4CiAgICAgICAgICBtc2kg ICAgMTkgICAgIDNLICAgICAgIC0gICAgICAgMTkgIDEyOAogICAgIG5leHVzZGV2ICAgICA2ICAg ICAxSyAgICAgICAtICAgICAgICA2ICAxNgogICAgICAgbnZpZGlhICA1NjMyIDE0ODA1SyAgICAg ICAtICAgIDQzNjg4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Niw4MTkyLDE2 Mzg0LDMyNzY4LDY1NTM2Cm52aWRpYS1tb2Rlc2V0ICAgMTQ3ICAgMjI3SyAgICAgICAtICAgNjk3 NzQ5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NiwxNjM4NCwzMjc2OAoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCnZtc3RhdCAtegoKSVRFTSAgICAgICAgICAgICAgICAgICBTSVpFICBMSU1J VCAgICAgVVNFRCAgICAgRlJFRSAgICAgIFJFUSBGQUlMIFNMRUVQCgpVTUEgS2VnczogICAgICAg ICAgICAgICAzODQsICAgICAgMCwgICAgIDI2NCwgICAgICAgNiwgICAgIDI2NCwgICAwLCAgIDAK VU1BIFpvbmVzOiAgICAgICAgICAgICAxMTUyLCAgICAgIDAsICAgICAyNjUsICAgICAgIDIsICAg ICAyNjUsICAgMCwgICAwClVNQSBTbGFiczogICAgICAgICAgICAgIDExMiwgICAgICAwLCAgIDc1 NzU5LCAgICAzNzk2LCAgIDgzNDkyLCAgIDAsICAgMApVTUEgSGFzaDogICAgICAgICAgICAgICAy NTYsICAgICAgMCwgICAgICA3NSwgICAgICA0NSwgICAgIDEwOCwgICAwLCAgIDAKNCBCdWNrZXQ6 ICAgICAgICAgICAgICAgIDMyLCAgICAgIDAsICAgICA4MjUsICAgIDEyODMsICAgNzc1MDIsICAg MCwgICAwCjYgQnVja2V0OiAgICAgICAgICAgICAgICA0OCwgICAgICAwLCAgICAgMTMyLCAgICAx NDQ1LCAgIDE4ODc5LCAgIDAsICAgMAo4IEJ1Y2tldDogICAgICAgICAgICAgICAgNjQsICAgICAg MCwgICAgIDEyMywgICAgMTQyNywgICAxOTQwNywgIDExLCAgIDAKMTIgQnVja2V0OiAgICAgICAg ICAgICAgIDk2LCAgICAgIDAsICAgICAzNzksICAgICA0MDAsICAgIDgwNDUsICAgMCwgICAwCjE2 IEJ1Y2tldDogICAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgMTY1LCAgICAxMzIzLCAgIDI3 OTQ2LCAgIDAsICAgMAozMiBCdWNrZXQ6ICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgIDEx NCwgICAgMTI5NiwgICAzODQxNSwgMTM1LCAgIDAKNjQgQnVja2V0OiAgICAgICAgICAgICAgNTEy LCAgICAgIDAsICAgICAxNjgsICAgICA3MDcsICAgNDA0OTQsMTczNSwgICAwCjEyOCBCdWNrZXQ6 ICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAgMjU1LCAgICAgMjI1LCAgICA2MTMyLDE2OTU2 LCAgIDAKMjU2IEJ1Y2tldDogICAgICAgICAgICAyMDQ4LCAgICAgIDAsICAgICAyMjEsICAgICAx MDMsICAgMTA2MzgsICAgNCwgICAwCnZtZW0gYnRhZzogICAgICAgICAgICAgICA1NiwgICAgICAw LCAgIDczMzYwLCAgICAxNDc0LCAgIDc1NjI2LCA1MjgsICAgMApWTSBPQkpFQ1Q6ICAgICAgICAg ICAgICAyNjQsICAgICAgMCwgICA4Njk5NiwgICAgIDI4OSwgMTM2MjMxMiwgICAwLCAgIDAKUkFE SVggTk9ERTogICAgICAgICAgICAgMTQ0LCAgICAgIDAsICAxMjIyMjYsICAgMTk1NzgsIDI1MTEx NzEsICAgMCwgICAwCk1BUDogICAgICAgICAgICAgICAgICAgIDI0MCwgICAgICAwLCAgICAgICAz LCAgICAgIDYxLCAgICAgICAzLCAgIDAsICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAxMjgs ICAgICAgMCwgICAgICA0MCwgICAgIDM2MywgICAgICA0NCwgICAwLCAgIDAKTUFQIEVOVFJZOiAg ICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgIDQzOTMsICAgIDExNTYsIDMwNDA3MDgsICAgMCwg ICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgMjUxMiwgICAgICAwLCAgICAgIDcxLCAgICAgIDQz LCAgIDQ4OTkzLCAgIDAsICAgMApmYWtlcGc6ICAgICAgICAgICAgICAgICAxMDQsICAgICAgMCwg ICAgMjM4OSwgICAgIDM4NSwgICAgMjQxNiwgICAwLCAgIDAKbXRfem9uZTogICAgICAgICAgICAg IDE2NDAwLCAgICAgIDAsICAgICAzOTAsICAgICAgIDAsICAgICAzOTAsICAgMCwgICAwCjE2OiAg ICAgICAgICAgICAgICAgICAgICAxNiwgICAgICAwLCAgIDMwMTE0LCAgIDEzNzEwLDE4NDkwOTc3 LCAgIDAsICAgMAozMjogICAgICAgICAgICAgICAgICAgICAgMzIsICAgICAgMCwgICA5MjU5OCwg ICAgNDM3MCwxMDE2MzA3MzEsICAgMCwgICAwCjY0OiAgICAgICAgICAgICAgICAgICAgICA2NCwg ICAgICAwLCAgMTEwOTI5LCAgIDU4MTQ1LCAzMzg0MzkxLCAgIDAsICAgMAoxMjg6ICAgICAgICAg ICAgICAgICAgICAxMjgsICAgICAgMCwgICAxMjM2NCwgICAgMTc3MiwgMTI3MzA4MiwgICAwLCAg IDAKMjU2OiAgICAgICAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgODU0MjUsICAgIDM4MjUs ICA4NjY1ODAsICAgMCwgICAwCjUxMjogICAgICAgICAgICAgICAgICAgIDUxMiwgICAgICAwLCAg ICAxNjc4LCAgICAxNDMwLCAyMTg3NTA3LCAgIDAsICAgMAoxMDI0OiAgICAgICAgICAgICAgICAg IDEwMjQsICAgICAgMCwgICAgMzgzNCwgICAgIDIxNCwgMTE3ODI3MywgICAwLCAgIDAKMjA0ODog ICAgICAgICAgICAgICAgICAyMDQ4LCAgICAgIDAsICAgIDE3MDgsICAgICAgNDIsICAxMjY4MTIs ICAgMCwgICAwCjQwOTY6ICAgICAgICAgICAgICAgICAgNDA5NiwgICAgICAwLCAgIDExMjEzLCAg ICAgICA3LDEzODk1OTMxLCAgIDAsICAgMAo4MTkyOiAgICAgICAgICAgICAgICAgIDgxOTIsICAg ICAgMCwgICAgIDEyMSwgICAgICAgNCwgICAgMzA1OCwgICAwLCAgIDAKMTYzODQ6ICAgICAgICAg ICAgICAgIDE2Mzg0LCAgICAgIDAsICAgICAgNDMsICAgICAgIDcsICAxMTA5MTgsICAgMCwgICAw CjMyNzY4OiAgICAgICAgICAgICAgICAzMjc2OCwgICAgICAwLCAgICAgIDYzLCAgICAgICA3LCAg MTEwOTg1LCAgIDAsICAgMAo2NTUzNjogICAgICAgICAgICAgICAgNjU1MzYsICAgICAgMCwgICAg ICAzNywgICAgICAgNiwgICAgIDIxOCwgICAwLCAgIDAKNjQgcGNwdTogICAgICAgICAgICAgICAg ICA4LCAgICAgIDAsICAgNjcwMDEsICAgICA1ODMsICAgNjcwMDEsICAgMCwgICAwClNMRUVQUVVF VUU6ICAgICAgICAgICAgICA4OCwgICAgICAwLCAgICAgODY1LCAgICAgMjgyLCAgICAgODY1LCAg IDAsICAgMApGaWxlczogICAgICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgIDM1OCwgICAg IDY3MSwgMTYwNTI5MCwgICAwLCAgIDAKZmlsZWRlc2MwOiAgICAgICAgICAgICAxMTA0LCAgICAg IDAsICAgICAgOTcsICAgICAgNjgsICAgNDkwMTgsICAgMCwgICAwCnJsX2VudHJ5OiAgICAgICAg ICAgICAgICA0MCwgICAgICAwLCAgICAgMTc4LCAgICAgOTExLCAgICAgMTc4LCAgIDAsICAgMApU VVJOU1RJTEU6ICAgICAgICAgICAgICAxMzYsICAgICAgMCwgICAgIDg2NSwgICAgIDExNSwgICAg IDg2NSwgICAwLCAgIDAKdW10eCBwaTogICAgICAgICAgICAgICAgIDk2LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnVtdHhfc2htOiAgICAgICAgICAgICAgICA4 OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApNQUMgbGFiZWxz OiAgICAgICAgICAgICAgNDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKUFJPQzogICAgICAgICAgICAgICAgICAxMzIwLCAgICAgIDAsICAgICAgOTYsICAgICAg NjYsICAgNDkwMTcsICAgMCwgICAwClRIUkVBRDogICAgICAgICAgICAgICAgMTI4MCwgICAgICAw LCAgICAgODMzLCAgICAgIDMxLCAgICAxNDMzLCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAg ICAgICAgOTYsICAgICAgMCwgICAgIDYwMCwgICAgIDE3OSwgICAgMTEwMCwgICAwLCAgIDAKYXVk aXRfcmVjb3JkOiAgICAgICAgICAxMjQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgMzIzNjg2NSwgICAgODE5 MCwgICAgMjIwMiwgIDUzNzgzMiwgICAwLCAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgMjU2 LCAzMjM2ODY1LCAgICAgICAyLCAgICAyMjk0LCAgOTAwMjY5LCAgIDAsICAgMAptYnVmX2NsdXN0 ZXI6ICAgICAgICAgIDIwNDgsIDUwNTc2MCwgICAgOTYxNCwgICAgIDI2MiwgICAgOTg2NywgICAw LCAgIDAKbWJ1Zl9qdW1ib19wYWdlOiAgICAgICA0MDk2LCAyNTI4NzksICAgICAgIDAsICAgICAg ODEsICAgNjI0MDIsICAgMCwgICAwCm1idWZfanVtYm9fOWs6ICAgICAgICAgOTIxNiwgMjI0Nzgx LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAptYnVmX2p1bWJvXzE2azogICAg ICAgMTYzODQsIDE2ODU4NCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTmV0 R3JhcGggaXRlbXM6ICAgICAgICAgIDcyLCAgIDQxMjMsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCk5ldEdyYXBoIGRhdGEgaXRlbXM6ICAgICA3MiwgICA0MTIzLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApnX2JpbzogICAgICAgICAgICAgICAgICA0MDAs ICAgICAgMCwgICAgICAgMCwgICAgIDQ0MSwgIDQ5MjI5NCwgICAwLCAgIDAKRE1BUl9NQVBfRU5U Ulk6ICAgICAgICAgMTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnR0eWlucTogICAgICAgICAgICAgICAgIDE2MCwgICAgICAwLCAgICAgMjcwLCAgICAgMTE0 LCAgICAxMDA1LCAgIDAsICAgMAp0dHlvdXRxOiAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwg ICAgIDE0MiwgICAgIDExMywgICAgIDUzNCwgICAwLCAgIDAKbnZtZV9yZXF1ZXN0OiAgICAgICAg ICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmNyeXB0 b3A6ICAgICAgICAgICAgICAgICA4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApjcnlwdG9kZXNjOiAgICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKaWNsX3BkdTogICAgICAgICAgICAgICAgIDgwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmlzY3NpX291dHN0YW5k aW5nOiAgICAgICA0OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MAp2dG5ldF90eF9oZHI6ICAgICAgICAgICAgMjQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKRlBVX3NhdmVfYXJlYTogICAgICAgICAgODMyLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkNUTCBJTzogICAgICAgICAgICAgICAg IDY3MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApiZWlvOiAg ICAgICAgICAgICAgICAgICAzNjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKY2Zpc2NzaV9kYXRhX3dhaXQ6ICAgICAgIDcyLCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCnRhc2txX3pvbmU6ICAgICAgICAgICAgICA0OCwgICAg ICAwLCAgICAgICAwLCAgICAxMDc5LCAgICAxNDgxLCAgIDAsICAgMApnX3Noc2VjX3pvbmU6ICAg ICAgICAxMzEwNzIsICAgMzIwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK Vk5PREU6ICAgICAgICAgICAgICAgICAgNjI0LCAgICAgIDAsICAxODQwNjIsICAgICAgMzYsICAz MDE2MDAsICAgMCwgICAwClZOT0RFUE9MTDogICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAg IDE1LCAgICAgMzgxLCAgICAgIDE1LCAgIDAsICAgMApCVUYgVFJJRTogICAgICAgICAgICAgICAx NDQsICAgICAgMCwgICAgMTQ0NywgICA1MTIzMCwgICAgMjcwNywgICAwLCAgIDAKTkFNRUk6ICAg ICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDEsICAgICAxNjMsIDY4NTQzNzYsICAg MCwgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgIDEwOCwgICAgICAwLCAgMTg3Mzk1LCAgICAx MzI1LCAgNDkzMTkwLCAgIDAsICAgMApTVFMgVkZTIENhY2hlOiAgICAgICAgICAxNDgsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTCBWRlMgQ2FjaGU6ICAgICAg ICAgICAgMzI4LCAgICAgIDAsICAgIDI1MDksICAgICA0MTksICAgIDYzMzIsICAgMCwgICAwCkxU UyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMApuYW5kZnMgbm9kZSB6b25lOiAgICAgICAzMTIsICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKYXV0b2ZzX3JlcXVlc3Q6ICAgICAgICA1Mjgw LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmF1dG9mc19ub2Rl OiAgICAgICAgICAgIDIwOCwgICAgICAwLCAgICAgICAyLCAgICAgIDc0LCAgICAgICAyLCAgIDAs ICAgMAptcW5vZGU6ICAgICAgICAgICAgICAgICA0MTYsICAgICAgMCwgICAgICAgMywgICAgICAz MywgICAgICAgMywgICAwLCAgIDAKbXF1ZXVlOiAgICAgICAgICAgICAgICAgMjY0LCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm12ZGF0YTogICAgICAgICAgICAg ICAgICA2NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAptcW5v dGlmaWVyOiAgICAgICAgICAgICAyMTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKVURGIHRyYW5zbGF0aW9uIGJ1ZmZlciwgem9uZTogICAgNTEwLCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwClVERiBOb2RlIHpvbmU6ICAgICAg ICAgICA0MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApVREYg RGlyc3RyZWFtIHpvbmU6ICAgICAgNzIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKRElSSEFTSDogICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICA0NTYs ICAgICAgNTYsICAgICA1MDYsICAgMCwgICAwCk5DTE5PREU6ICAgICAgICAgICAgICAgIDUyOCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwcm9jZGVzYzogICAg ICAgICAgICAgICAxMzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKQUlPOiAgICAgICAgICAgICAgICAgICAgMjI0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCkFJT1A6ICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApBSU9DQjogICAgICAgICAgICAgICAg ICA3NTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKQUlPTDog ICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCkFJT0xJTzogICAgICAgICAgICAgICAgIDI4MCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMApNb3VudHBvaW50czogICAgICAgICAgIDEwMjQsICAg ICAgMCwgICAgICAxOSwgICAgICAzMywgICAgICAxOSwgICAwLCAgIDAKcmVmZXJlbmNlX2NhY2hl OiAgICAgICAgIDQwLCAgICAgIDAsICAgICAgMjIsICAgIDE1NjIsICAgNzMyNTgsICAgMCwgICAw CnJlZmVyZW5jZV9oaXN0b3J5X2NhY2hlOiAgICAgIDgsICAgICAgMCwgICAgICAxMiwgICAgMTIz MywgICA3MzI0OCwgICAwLCAgIDAKcmFuZ2Vfc2VnX2NhY2hlOiAgICAgICAgIDY0LCAgICAgIDAs ICAgMjAxOTgsICAgMTIyOTAsICAxNjA0NzYsICAgMCwgICAwCnppb19jYWNoZTogICAgICAgICAg ICAgIDk4NCwgICAgICAwLCAgICAgIDQ1LCAgICAxMjY3LCAyMDU5MDc1LCAgIDAsICAgMAp6aW9f bGlua19jYWNoZTogICAgICAgICAgNDgsICAgICAgMCwgICAgICAzNCwgICAgMjUzOSwgIDc1NTEy MCwgICAwLCAgIDAKemlvX2J1Zl81MTI6ICAgICAgICAgICAgNTEyLCAgICAgIDAsICAxNzg3NDEs ICAgIDEyMDEsICA1NjAwOTEsICAgMCwgICAwCnppb19kYXRhX2J1Zl81MTI6ICAgICAgIDUxMiwg ICAgICAwLCAgICA4OTExLCAgICAgMTk2LCAgIDEwNTIyLCAgIDAsICAgMAp6aW9fYnVmXzEwMjQ6 ICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgMTIzNywgICAgIDk5OSwgICAgMjY2MCwgICAwLCAg IDAKemlvX2RhdGFfYnVmXzEwMjQ6ICAgICAxMDI0LCAgICAgIDAsICAgIDIyMDMsICAgICAgNjEs ICAgIDI0OTUsICAgMCwgICAwCnppb19idWZfMTUzNjogICAgICAgICAgMTUzNiwgICAgICAwLCAg ICAgNDMwLCAgICAgMzI2LCAgICAxMTUwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTUzNjogICAg IDE1MzYsICAgICAgMCwgICAgMTg0NiwgICAgICA3MiwgICAgMjEzMiwgICAwLCAgIDAKemlvX2J1 Zl8yMDQ4OiAgICAgICAgICAyMDQ4LCAgICAgIDAsICAgICAyNDQsICAgICAxNTIsICAgIDE3NjIs ICAgMCwgICAwCnppb19kYXRhX2J1Zl8yMDQ4OiAgICAgMjA0OCwgICAgICAwLCAgICAzNTYyLCAg ICAgIDM0LCAgICAzODUxLCAgIDAsICAgMAp6aW9fYnVmXzI1NjA6ICAgICAgICAgIDI1NjAsICAg ICAgMCwgICAgIDEyNSwgICAgICA5MSwgICAgIDMwNCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzI1 NjA6ICAgICAyNTYwLCAgICAgIDAsICAgIDMzMzEsICAgICAgNjgsICAgIDM2MjUsICAgMCwgICAw Cnppb19idWZfMzA3MjogICAgICAgICAgMzA3MiwgICAgICAwLCAgICAgIDkxLCAgICAgIDQ0LCAg ICAgMjA4LCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMzA3MjogICAgIDMwNzIsICAgICAgMCwgICAg MzE5MSwgICAgICAyMiwgICAgMzQ0OCwgICAwLCAgIDAKemlvX2J1Zl8zNTg0OiAgICAgICAgICAz NTg0LCAgICAgIDAsICAgICAgNzQsICAgICAgNDksICAgICAxODMsICAgMCwgICAwCnppb19kYXRh X2J1Zl8zNTg0OiAgICAgMzU4NCwgICAgICAwLCAgICAzMTU4LCAgICAgICA3LCAgICAzMjQxLCAg IDAsICAgMAp6aW9fYnVmXzQwOTY6ICAgICAgICAgIDQwOTYsICAgICAgMCwgICAxMDk1MCwgICAg MjcwMiwgICA3MTE4NCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQwOTY6ICAgICA0MDk2LCAgICAg IDAsICAgIDI5ODUsICAgICAgMTAsICAgIDMxODksICAgMCwgICAwCnppb19idWZfNTEyMDogICAg ICAgICAgNTEyMCwgICAgICAwLCAgICAgICA2LCAgICAgICA5LCAgICAgNDk1LCAgIDAsICAgMAp6 aW9fZGF0YV9idWZfNTEyMDogICAgIDUxMjAsICAgICAgMCwgICAgNjM1NSwgICAgICAxNSwgICAg NjU2OCwgICAwLCAgIDAKemlvX2J1Zl82MTQ0OiAgICAgICAgICA2MTQ0LCAgICAgIDAsICAgICAg IDUsICAgICAgIDgsICAgICAzMTgsICAgMCwgICAwCnppb19kYXRhX2J1Zl82MTQ0OiAgICAgNjE0 NCwgICAgICAwLCAgICA0Mzk2LCAgICAgICA5LCAgICA0NTE4LCAgIDAsICAgMAp6aW9fYnVmXzcx Njg6ICAgICAgICAgIDcxNjgsICAgICAgMCwgICAgICAgMywgICAgICAgNywgICAgIDMzNywgICAw LCAgIDAKemlvX2RhdGFfYnVmXzcxNjg6ICAgICA3MTY4LCAgICAgIDAsICAgIDU3NTYsICAgICAg MTEsICAgIDU4ODcsICAgMCwgICAwCnppb19idWZfODE5MjogICAgICAgICAgODE5MiwgICAgICAw LCAgICAgMjk3LCAgICAgIDU5LCAgIDIzMTEwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfODE5Mjog ICAgIDgxOTIsICAgICAgMCwgICAgMzIwMiwgICAgICAgNSwgICAgMzMzOSwgICAwLCAgIDAKemlv X2J1Zl8xMDI0MDogICAgICAgIDEwMjQwLCAgICAgIDAsICAgICAgIDMsICAgICAgIDcsICAgICA1 MjMsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMDI0MDogICAxMDI0MCwgICAgICAwLCAgICAyMjU5 LCAgICAgICAwLCAgICAyNTM2LCAgIDAsICAgMAp6aW9fYnVmXzEyMjg4OiAgICAgICAgMTIyODgs ICAgICAgMCwgICAgICAgNSwgICAgICAxNSwgICAgNTM4NSwgICAwLCAgIDAKemlvX2RhdGFfYnVm XzEyMjg4OiAgIDEyMjg4LCAgICAgIDAsICAgIDIzNDYsICAgICAgIDQsICAgIDI1NzQsICAgMCwg ICAwCnppb19idWZfMTQzMzY6ICAgICAgICAxNDMzNiwgICAgICAwLCAgICAgICA0LCAgICAgICA1 LCAgICAgMTYzLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTQzMzY6ICAgMTQzMzYsICAgICAgMCwg ICAgMTczNywgICAgICAgNSwgICAgMTkzMCwgICAwLCAgIDAKemlvX2J1Zl8xNjM4NDogICAgICAg IDE2Mzg0LCAgICAgIDAsICAgIDk4MzYsICAgICAgNTQsICAgMjk1NzIsICAgMCwgICAwCnppb19k YXRhX2J1Zl8xNjM4NDogICAxNjM4NCwgICAgICAwLCAgICAyMTY3LCAgICAgICAxLCAgICAyMzY5 LCAgIDAsICAgMAp6aW9fYnVmXzIwNDgwOiAgICAgICAgMjA0ODAsICAgICAgMCwgICAgICAgNCwg ICAgICAxMCwgICAgMjI1MiwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzIwNDgwOiAgIDIwNDgwLCAg ICAgIDAsICAgIDE2MTYsICAgICAgIDQsICAgIDE5OTUsICAgMCwgICAwCnppb19idWZfMjQ1NzY6 ICAgICAgICAyNDU3NiwgICAgICAwLCAgICAgICA1LCAgICAgICA2LCAgICAxNTgyLCAgIDAsICAg MAp6aW9fZGF0YV9idWZfMjQ1NzY6ICAgMjQ1NzYsICAgICAgMCwgICAgIDkwMiwgICAgICAgMywg ICAgMTIxOSwgICAwLCAgIDAKemlvX2J1Zl8yODY3MjogICAgICAgIDI4NjcyLCAgICAgIDAsICAg ICAgIDEsICAgICAgMTIsICAgIDExNjAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8yODY3MjogICAy ODY3MiwgICAgICAwLCAgICAgODUyLCAgICAgICAyLCAgICAxMTYyLCAgIDAsICAgMAp6aW9fYnVm XzMyNzY4OiAgICAgICAgMzI3NjgsICAgICAgMCwgICAgICAgMCwgICAgICAgNiwgICAgIDkwMCwg ICAwLCAgIDAKemlvX2RhdGFfYnVmXzMyNzY4OiAgIDMyNzY4LCAgICAgIDAsICAgICA2NTMsICAg ICAgIDQsICAgIDEwMTQsICAgMCwgICAwCnppb19idWZfNDA5NjA6ICAgICAgICA0MDk2MCwgICAg ICAwLCAgICAgICAyLCAgICAgICA1LCAgICAxMTg3LCAgIDAsICAgMAp6aW9fZGF0YV9idWZfNDA5 NjA6ICAgNDA5NjAsICAgICAgMCwgICAgIDc1MiwgICAgICAyMSwgICAgMTQ2MSwgICAwLCAgIDAK emlvX2J1Zl80OTE1MjogICAgICAgIDQ5MTUyLCAgICAgIDAsICAgICAgIDIsICAgICAgIDcsICAg IDEwNzEsICAgMCwgICAwCnppb19kYXRhX2J1Zl80OTE1MjogICA0OTE1MiwgICAgICAwLCAgICAg MzgxLCAgICAgMTA5LCAgICAxMDcxLCAgIDAsICAgMAp6aW9fYnVmXzU3MzQ0OiAgICAgICAgNTcz NDQsICAgICAgMCwgICAgICAgOSwgICAgICAgNiwgICAgIDYyMiwgICAwLCAgIDAKemlvX2RhdGFf YnVmXzU3MzQ0OiAgIDU3MzQ0LCAgICAgIDAsICAgICAzMTUsICAgICAgOTYsICAgICA5MjMsICAg MCwgICAwCnppb19idWZfNjU1MzY6ICAgICAgICA2NTUzNiwgICAgICAwLCAgICAgICAwLCAgICAg ICA3LCAgICAgNjEyLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfNjU1MzY6ICAgNjU1MzYsICAgICAg MCwgICAgIDIxNSwgICAgICAzNCwgICAgMTI2NCwgICAwLCAgIDAKemlvX2J1Zl84MTkyMDogICAg ICAgIDgxOTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDYsICAgICA3OTgsICAgMCwgICAwCnpp b19kYXRhX2J1Zl84MTkyMDogICA4MTkyMCwgICAgICAwLCAgICAgMzM1LCAgICAgICAxLCAgICAx MDU2LCAgIDAsICAgMAp6aW9fYnVmXzk4MzA0OiAgICAgICAgOTgzMDQsICAgICAgMCwgICAgICAg MCwgICAgICAgNiwgICAgIDQ4NywgICAwLCAgIDAKemlvX2RhdGFfYnVmXzk4MzA0OiAgIDk4MzA0 LCAgICAgIDAsICAgICAyMDksICAgICAgIDMsICAgICA4ODMsICAgMCwgICAwCnppb19idWZfMTE0 Njg4OiAgICAgIDExNDY4OCwgICAgICAwLCAgICAgICAwLCAgICAgICA1LCAgICAgMzc5LCAgIDAs ICAgMAp6aW9fZGF0YV9idWZfMTE0Njg4OiAxMTQ2ODgsICAgICAgMCwgICAgIDE2MSwgICAgICAg NSwgICAgIDg1OCwgICAwLCAgIDAKemlvX2J1Zl8xMzEwNzI6ICAgICAgMTMxMDcyLCAgICAgIDAs ICAgICAyNDAsICAgICAgNjgsICAgIDcxMDYsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMzEwNzI6 IDEzMTA3MiwgICAgICAwLCAgIDExMzE3LCAgICAgIDQzLCAgIDE4OTMyLCAgIDAsICAgMAp6aW9f YnVmXzE2Mzg0MDogICAgICAxNjM4NDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzE2Mzg0MDogMTYzODQwLCAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTk2NjA4OiAgICAgIDE5NjYwOCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZf MTk2NjA4OiAxOTY2MDgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKemlvX2J1Zl8yMjkzNzY6ICAgICAgMjI5Mzc2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8yMjkzNzY6IDIyOTM3NiwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzI2MjE0NDogICAgICAy NjIxNDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2Rh dGFfYnVmXzI2MjE0NDogMjYyMTQ0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19idWZfMzI3NjgwOiAgICAgIDMyNzY4MCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMzI3NjgwOiAzMjc2ODAsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8zOTMyMTY6 ICAgICAgMzkzMjE2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19kYXRhX2J1Zl8zOTMyMTY6IDM5MzIxNiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzQ1ODc1MjogICAgICA0NTg3NTIsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQ1ODc1MjogNDU4 NzUyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZf NTI0Mjg4OiAgICAgIDUyNDI4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp6aW9fZGF0YV9idWZfNTI0Mjg4OiA1MjQyODgsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl82NTUzNjA6ICAgICAgNjU1MzYwLCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82NTUz NjA6IDY1NTM2MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6 aW9fYnVmXzc4NjQzMjogICAgICA3ODY0MzIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzc4NjQzMjogNzg2NDMyLCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfOTE3NTA0OiAgICAgIDkxNzUw NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9i dWZfOTE3NTA0OiA5MTc1MDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKemlvX2J1Zl8xMDQ4NTc2OiAgICAgMTA0ODU3NiwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTA0ODU3NjogMTA0ODU3NiwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEzMTA3MjA6 ICAgICAxMzEwNzIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19kYXRhX2J1Zl8xMzEwNzIwOiAxMzEwNzIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTU3Mjg2NDogICAgIDE1NzI4NjQsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzE1NzI4NjQ6 IDE1NzI4NjQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlv X2J1Zl8xODM1MDA4OiAgICAgMTgzNTAwOCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTgzNTAwODogMTgzNTAwOCwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzIwOTcxNTI6ICAgICAyMDk3 MTUyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRh X2J1Zl8yMDk3MTUyOiAyMDk3MTUyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19idWZfMjYyMTQ0MDogICAgIDI2MjE0NDAsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzI2MjE0NDA6IDI2MjE0NDAs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8zMTQ1 NzI4OiAgICAgMzE0NTcyOCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fZGF0YV9idWZfMzE0NTcyODogMzE0NTcyOCwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzM2NzAwMTY6ICAgICAzNjcwMDE2LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8zNjcw MDE2OiAzNjcwMDE2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19idWZfNDE5NDMwNDogICAgIDQxOTQzMDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQxOTQzMDQ6IDQxOTQzMDQsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl81MjQyODgwOiAgICAg NTI0Mjg4MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9f ZGF0YV9idWZfNTI0Mjg4MDogNTI0Mjg4MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMAp6aW9fYnVmXzYyOTE0NTY6ICAgICA2MjkxNDU2LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82MjkxNDU2OiA2Mjkx NDU2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZf NzM0MDAzMjogICAgIDczNDAwMzIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKemlvX2RhdGFfYnVmXzczNDAwMzI6IDczNDAwMzIsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl84Mzg4NjA4OiAgICAgODM4ODYwOCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZf ODM4ODYwODogODM4ODYwOCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fYnVmXzEwNDg1NzYwOiAgICAxMDQ4NTc2MCwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTA0ODU3NjA6IDEwNDg1NzYwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTI1ODI5 MTI6ICAgIDEyNTgyOTEyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnppb19kYXRhX2J1Zl8xMjU4MjkxMjogMTI1ODI5MTIsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xNDY4MDA2NDogICAgMTQ2ODAwNjQsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzE0 NjgwMDY0OiAxNDY4MDA2NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fYnVmXzE2Nzc3MjE2OiAgICAxNjc3NzIxNiwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTY3NzcyMTY6IDE2Nzc3MjE2LCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmx6NF9jdHg6ICAgICAg ICAgICAgICAxNjM4NCwgICAgICAwLCAgICAgICAwLCAgICAgICA3LCAgIDE5MTMwLCAgIDAsICAg MApzYV9jYWNoZTogICAgICAgICAgICAgICAxNDQsICAgICAgMCwgIDE3NzA3OCwgICAgIDk4Nywg IDIyMDAxNywgICAwLCAgIDAKZG5vZGVfdDogICAgICAgICAgICAgICAgOTYwLCAgICAgIDAsICAx NzkyOTMsICAgIDMxMzEsICAyMjA3MzQsICAgMCwgICAwCmFyY19idWZfaGRyX3RfZnVsbDogICAg IDM0NCwgICAgICAwLCAgIDk2MjA2LCAgICAgIDc3LCAgMjg1NzM5LCAgIDAsICAgMAphcmNfYnVm X2hkcl90X2wyb25seTogICAgIDg4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCmFyY19idWZfdDogICAgICAgICAgICAgICA1NiwgICAgICAwLCAgIDExODc2LCAg IDEzMTg3LCAgMzExNTE2LCAgIDAsICAgMApkbXVfYnVmX2ltcGxfdDogICAgICAgICAzNDQsICAg ICAgMCwgIDE4OTI4MCwgICAgODU5OSwgIDU0MTQwMywgICAwLCAgIDAKemlsX2x3Yl9jYWNoZTog ICAgICAgICAgMTkyLCAgICAgIDAsICAgICAgIDEsICAgICAyOTksICAgICAzOTcsICAgMCwgICAw Cnpmc196bm9kZV9jYWNoZTogICAgICAgIDI2NCwgICAgICAwLCAgMTc3MDc4LCAgICAgNjcyLCAg MjIwMDE3LCAgIDAsICAgMApwaXBlOiAgICAgICAgICAgICAgICAgICA3NjAsICAgICAgMCwgICAg ICAyOCwgICAgIDEwMiwgICAzMjQ1OCwgICAwLCAgIDAKa3NpZ2luZm86ICAgICAgICAgICAgICAg MTEyLCAgICAgIDAsICAgICAxNTAsICAgICA4NjUsICAgNjIwNTgsICAgMCwgICAwCml0aW1lcjog ICAgICAgICAgICAgICAgIDM1MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMApLTk9URTogICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgICAzMSwgICAg IDM3MiwgICAgIDE4NSwgICAwLCAgIDAKZmxvd3M6ICAgICAgICAgICAgICAgICAgIDQwLCAyMTY4 NzYsICAgICAgMTQsICAgIDEwNDAsICAgICA1NzIsICAgMCwgICAwCnNvY2tldDogICAgICAgICAg ICAgICAgIDg2NCwgMjU5OTc2LCAgICAgMTE5LCAgICAgIDY1LCAgICA0Njk2LCAgIDAsICAgMApp cHE6ICAgICAgICAgICAgICAgICAgICAgNTYsICAxNTgzMywgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKdWRwX2lucGNiOiAgICAgICAgICAgICAgNDY0LCAyNTk5NzYsICAgICAg MTIsICAgICAxNDAsICAgICAyNTksICAgMCwgICAwCnVkcGNiOiAgICAgICAgICAgICAgICAgICAz MiwgMjYwMDI4LCAgICAgIDEyLCAgICAxMTA0LCAgICAgMjU5LCAgIDAsICAgMAp0Y3BfaW5wY2I6 ICAgICAgICAgICAgICA0NjQsIDI1OTk3NiwgICAgICAyOSwgICAgIDEyMywgICAgIDE4MywgICAw LCAgIDAKdGNwY2I6ICAgICAgICAgICAgICAgICAxMDE2LCAyNTk5NzYsICAgICAgMjgsICAgICAg NjQsICAgICAxODMsICAgMCwgICAwCnRjcHR3OiAgICAgICAgICAgICAgICAgICA4OCwgIDI3ODEw LCAgICAgICAxLCAgICAgMjY5LCAgICAgIDQxLCAgIDAsICAgMApzeW5jYWNoZTogICAgICAgICAg ICAgICAxNjgsICAxNTM2NCwgICAgICAgMCwgICAgIDE4NCwgICAgICAgOCwgICAwLCAgIDAKaG9z dGNhY2hlOiAgICAgICAgICAgICAgIDk2LCAgMTUzNzUsICAgICAgMzcsICAgICAzNzMsICAgICAg MzcsICAgMCwgICAwCnNhY2tob2xlOiAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAs ICAzMTY4MCwgICAgICAgMCwgICAgIDU5NCwgICAxNjMyNSwgICAwLCAgIDAKc2N0cF9lcDogICAg ICAgICAgICAgICAxNDgwLCAyNTk5NzYsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnNjdHBfYXNvYzogICAgICAgICAgICAgMjQwMCwgIDQwMDAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApzY3RwX2xhZGRyOiAgICAgICAgICAgICAgNDgsICA4MDAxMiwg ICAgICAgMCwgICAgIDMzMiwgICAgICAgMSwgICAwLCAgIDAKc2N0cF9yYWRkcjogICAgICAgICAg ICAgNzI4LCAgODAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBf Y2h1bms6ICAgICAgICAgICAgIDE1MiwgNDAwMDEwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApzY3RwX3JlYWRxOiAgICAgICAgICAgICAxNjAsIDQwMDAwOCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9zdHJlYW1fbXNnX291dDogICAgMTEyLCA0 MDAwMTUsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfYXNjb25mOiAg ICAgICAgICAgICA0MCwgNDAwMDU5LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MApzY3RwX2FzY29uZl9hY2s6ICAgICAgICAgNDgsIDQwMDA2MCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKdWRwbGl0ZV9pbnBjYjogICAgICAgICAgNDY0LCAyNTk5NzYsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnJpcGNiOiAgICAgICAgICAgICAgICAg IDQ2NCwgMjU5OTc2LCAgICAgICAwLCAgICAgMTIwLCAgICAgIDI4LCAgIDAsICAgMAp1bnBjYjog ICAgICAgICAgICAgICAgICAyNDAsIDI1OTk4NCwgICAgICA3OCwgICAgIDE3OCwgICAgNDIyMywg ICAwLCAgIDAKcnRlbnRyeTogICAgICAgICAgICAgICAgMjA4LCAgICAgIDAsICAgICAgIDQsICAg ICAxODYsICAgICAgIDUsICAgMCwgICAwCklQRlcgY291bnRlcnM6ICAgICAgICAgICAxNiwgICAg ICAwLCAgICAgIDI4LCAgICAgOTk2LCAgICAgIDI4LCAgIDAsICAgMApJUEZXIGR5bmFtaWMgcnVs ZTogICAgICAxMjgsICAxNjM5OSwgICAgICAgOCwgICAgIDUxOSwgICAgIDQ3MSwgICAwLCAgIDAK c2VsZmQ6ICAgICAgICAgICAgICAgICAgIDY0LCAgICAgIDAsICAgICAyNjksICAgIDEyODEsMjY4 NTI3MzQsICAgMCwgICAwClNXQVBNRVRBOiAgICAgICAgICAgICAgIDI4OCwgMTAxMTUzMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTIGlub2RlOiAgICAgICAgICAgICAg MTUyLCAgICAgIDAsICAgIDU0NDYsICAgICAxMTgsICAgIDU0NjgsICAgMCwgICAwCkZGUzEgZGlu b2RlOiAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMApGRlMyIGRpbm9kZTogICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNTQ0NiwgICAg IDExOSwgICAgNTQ2OCwgICAwLCAgIDAKVE1QRlMgZGlyZW50OiAgICAgICAgICAgIDY0LCAgICAg IDAsICAgIDEzOTcsICAgICA2NDksICAgNzU5NzAsICAgMCwgICAwClRNUEZTIG5vZGU6ICAgICAg ICAgICAgIDIzMiwgICAgICAwLCAgICAxMzk4LCAgICAgMTMyLCAgIDc1OTcwLCAgIDAsICAgMApU TVBGUyBkaXJlbnQ6ICAgICAgICAgICAgNjQsICAgICAgMCwgICAgICA0OSwgICAgMTAwNSwgICAg ICA1MCwgICAwLCAgIDAKVE1QRlMgbm9kZTogICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgICAg NTAsICAgICAyMDUsICAgICAgNTEsICAgMCwgICAwCm52aWRpYV9zdGFja190OiAgICAgICAxMjI4 OCwgICAgICAwLCAgICAgICA4LCAgICAgICA3LCAgIDEzMzQ3LCAgIDAsICAgMAoKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQp2bXN0YXQgLWkKCmludGVycnVwdCAgICAgICAgICAgICAgICAgICAgICAgICAgdG90 YWwgICAgICAgcmF0ZQppcnExNjogZWhjaTAgICAgICAgICAgICAgICAgICAgICAgICA3MjQxICAg ICAgICAyODEKaXJxMjM6IGVoY2kxICAgICAgICAgICAgICAgICAgICAgICA0NjM2MCAgICAgICAx ODAwCmNwdTA6dGltZXIgICAgICAgICAgICAgICAgICAgICAgIDIwNjY2MjAgICAgICA4MDIyNgpp cnEyNjQ6IGhkYWMwICAgICAgICAgICAgICAgICAgICAgICAgIDE4ICAgICAgICAgIDEKaXJxMjY2 OiBoZGFjMSAgICAgICAgICAgICAgICAgICAgIDE3MjYxOSAgICAgICA2NzAxCmlycTI2NzogZW0w OnJ4MCAgICAgICAgICAgICAgICAgICAgOTQwMDIgICAgICAgMzY0OQppcnEyNjg6IGVtMDpyeDEg ICAgICAgICAgICAgICAgICAgNDMzOTMzICAgICAgMTY4NDUKaXJxMjY5OiBlbTA6dHgwICAgICAg ICAgICAgICAgICAgICA0ODgwOSAgICAgICAxODk1CmlycTI3MDogZW0wOnR4MSAgICAgICAgICAg ICAgICAgICAyMjM4NzYgICAgICAgODY5MQppcnEyNzM6IGFoY2kxICAgICAgICAgICAgICAgICAg ICAgMTIyOTk5ICAgICAgIDQ3NzUKY3B1MTp0aW1lciAgICAgICAgICAgICAgICAgICAgICAgMTQ1 NjQzMiAgICAgIDU2NTM5CmNwdTM6dGltZXIgICAgICAgICAgICAgICAgICAgICAgIDE1NDU3Mzkg ICAgICA2MDAwNQpjcHUyOnRpbWVyICAgICAgICAgICAgICAgICAgICAgICAxMzk1Nzg1ICAgICAg NTQxODQKaXJxMjc0OiB2Z2FwY2kwICAgICAgICAgICAgICAgICAgIDEyNTcwMCAgICAgICA0ODgw ClRvdGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgIDc3NDAxMzMgICAgIDMwMDQ3MQoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCnBzdGF0IC1UCgozNTgvMjU5OTc1IGZpbGVzCjBNLzY1NTM1TSBzd2FwIHNw YWNlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KcHN0YXQgLXMKCkRldmljZSAgICAgICAgICA1MTItYmxvY2tz ICAgICBVc2VkICAgIEF2YWlsIENhcGFjaXR5Ci9kZXYvZ3B0L3N3YXAgICAgMTM0MjE3NDcyICAg ICAgICAwIDEzNDIxNzQ3MiAgICAgMCUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppb3N0YXQKCiAgICAgICB0 dHkgICAgICAgICAgICBhZGEwICAgICAgICAgICAgIGFkYTEgICAgICAgICAgICAgYWRhMiAgICAg ICAgICAgICBjcHUKIHRpbiAgdG91dCAgS0IvdCB0cHMgIE1CL3MgICBLQi90IHRwcyAgTUIvcyAg IEtCL3QgdHBzICBNQi9zICB1cyBuaSBzeSBpbiBpZAogICAwICAgICA2IDI1LjQzICAgNyAgMC4x NyAgMjQuNjUgIDU4ICAxLjM5ICAxNS4zMyAgIDAgIDAuMDAgIDI3ICAwIDE4ICAxIDU0CgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0K --MP_/unDILOyI.YaXKvvM8HMUDK9-- --Sig_/q.wjP7/8QobIIk_Bsu_0AUT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYFLNBAAoJEOgBcD7A/5N8moYIANu3G3LzhRP9qKgScGmZEdAh jJhv+7cqKInOIgDksxpmfkwinmyy4MoKQqj771gK1te/l3eprauIU+erhf5af3Cs w9rrMR2RzturUjVBX5F17KWoIcZFZYlnykEygoxty1Iuqb+7x/gfdiPGn+N8vQZG 4VHhBugx7JskU5xS1KScObsEdttm4t3LwBoE+TEAylya6/Tkz6vS++gTdKMEzk1U aP3PI2Op8mR4Xa5QiNpRdLR4ShJK046H2IBzylvc/7JOAF+Q2MmIVGcqWfHln5F9 FwysKWBC87skaLMiA9ruQXAdWitLAcZVoltVxDYlPCBl5p8Dogc/isAy45axETc= =9iYb -----END PGP SIGNATURE----- --Sig_/q.wjP7/8QobIIk_Bsu_0AUT-- From owner-freebsd-current@freebsd.org Sat Oct 29 14:59:56 2016 Return-Path: Delivered-To: freebsd-current@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 80988C26E48 for ; Sat, 29 Oct 2016 14:59:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 35477B5B for ; Sat, 29 Oct 2016 14:59:55 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1c0V6w-003Hy5-3E>; Sat, 29 Oct 2016 16:59:54 +0200 Received: from x4e3495b6.dyn.telefonica.de ([78.52.149.182] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1c0V6v-003GJs-Ow>; Sat, 29 Oct 2016 16:59:54 +0200 Date: Sat, 29 Oct 2016 16:59:47 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r308090: buildkernel failure: undefined reference to ... Message-ID: <20161029165947.23d7db64.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/EY2RvWic_ikax8=twNHRXjn"; protocol="application/pgp-signature" X-Originating-IP: 78.52.149.182 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 14:59:56 -0000 --Sig_/EY2RvWic_ikax8=twNHRXjn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Most recent r308090 fails to buildkernel with lots of " undefined reference= to ...", as shown below.=20 [...] Building /usr/obj/usr/src/sys/THOR/kernel.full linking kernel.full refcount.o:(.data+0x8): undefined reference to `sysctl___vfs_zfs' freebsd32_misc.o: In function `freebsd32_utimes': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1255: undefined reference to `kern_utimesat' freebsd32_misc.o: In function `freebsd32_lutimes': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1277: undefined reference to= `kern_lutimes' freebsd32_misc.o: In function `freebsd32_futimes': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1298: undefined reference to= `kern_futimes' freebsd32_misc.o: In function `freebsd32_futimesat': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1319: undefined reference to `kern_utimesat' freebsd32_misc.o: In function `freebsd32_futimens': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1341: undefined reference to `kern_futimens' freebsd32_misc.o: In function `freebsd32_utimensat': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1362: undefined reference to `kern_utimensat' freebsd32_misc.o: In function `freebsd32_lseek': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1489: undefined reference to= `sys_lseek' freebsd32_misc.o: In function `freebsd32_truncate': [...] /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1504: undefined reference to= `sys_truncate' freebsd32_misc.o: In function `freebsd32_getdirentries': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1548: undefined reference to `kern_getdirentries' freebsd32_misc.o: In function `freebsd32_stat': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1778: undefined reference to= `kern_statat' freebsd32_misc.o: In function `freebsd32_fstatat': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1844: undefined reference to= `kern_statat' freebsd32_misc.o: In function `freebsd32_lstat': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:1860: undefined reference to= `kern_statat' freebsd32_misc.o: In function `freebsd32_posix_fallocate': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:2992: undefined reference to `kern_posix_fallocate' freebsd32_misc.o: In function `freebsd32_posix_fadvi= se': /usr/src/sys/compat/freebsd32/freebsd32_misc.c:3003: undefined reference to `kern_posix_fadvise' [...] kern_descrip.o: In function `_fdrop': /usr/src/sys/kern/kern_descrip.c:2908: undefined reference to `M_FADVISE' /usr/src/sys/kern/kern_descrip.c:2908: undefined reference to `M_FADVISE' /usr/src/sys/kern/kern_descrip.c:2908: undefined reference to `M_FADVISE' /usr/src/sys/kern/kern_descrip.c:2908: undefined reference to `M_FADVISE' /usr/src/sys/kern/kern_descrip.c:2908: undefined reference to `M_FADVISE' kern_descrip.o:/usr/src/sys/kern/kern_descrip.c:2908: more undefined refere= nces to `M_FADVISE' follow kern_descrip.o: In function `sys_nfstat': [...] /usr/src/sys/kern/vfs_bio.c:1216: undefined reference to `sys_sync' vfs_cache.o:(.data+0x8): undefined reference to `sdt_provider_vfs' vfs_cache.o:(.data+0xf8): undefined reference to `sdt_provider_vfs' vfs_cache.o:(.data+0x1b8): undefined reference to `sdt_provider_vfs' vfs_cache.o:(.data+0x248): undefined reference to `sdt_provider_vfs' vfs_cache.o:(.data+0x338): undefined reference to `sdt_provider_vfs' vfs_cache.o:(.data+0x3c8): more undefined references to `sdt_provider_vfs' = follow vfs_extattr.o: In function `sys_extattr_set_fd': /usr/src/sys/kern/vfs_extattr.c:229: undefined reference to `getvnode' [...] /usr/src/sys/ufs/ffs/ffs_alloc.c:3102: undefined reference to `getvnode' vnode_if.o:(.data+0x38): undefined reference to `sdt_provider_vfs' vnode_if.o:(.data+0xf8): undefined reference to `sdt_provider_vfs' vnode_if.o:(.data+0x228): undefined reference to `sdt_provider_vfs' vnode_if.o:(.data+0x2e8): undefined reference to `sdt_provider_vfs' vnode_if.o:(.data+0x418): undefined reference to `sdt_provider_vfs' vnode_if.o:(.data+0x4d8): more undefined references to `sdt_provider_vfs' f= ollow *** Error code 1 --Sig_/EY2RvWic_ikax8=twNHRXjn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYFLljAAoJEOgBcD7A/5N8+24IAJYLzKwWMGOzKAVa55cPUCSV 3kAnxr+hM2du+KMiigJHgZkXGUCURcgERimd6u1Eylq9ofP/eZtqrltTjTtXdS92 XDEksOW44aBXUcDFCwZfpA3yxDIt6iYGobIDN2o30Uahu0dFfNOJQe7SqrrEMYzb 6CaFJX7fhsnrSjOJxibaa3CCBXlsCZdOEedBNQT3VuCkOP/aojRBbDg+15JS/HQ7 Yq0m+on5gK04rnMV3M3EGR+xTphNOibfcv0/fZlsUSNKTz/jkqXU7QaoWWoWF+Ei 3BmlunGehQnjVXderH3cYW7FxOl/rW0vGS+1NrcRbdjoHIQS4ezNyIREJPK8z14= =2mrC -----END PGP SIGNATURE----- --Sig_/EY2RvWic_ikax8=twNHRXjn-- From owner-freebsd-current@freebsd.org Sat Oct 29 21:18:04 2016 Return-Path: Delivered-To: freebsd-current@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 74260C267CF for ; Sat, 29 Oct 2016 21:18:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (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 312B2A40 for ; Sat, 29 Oct 2016 21:18:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15818 invoked from network); 29 Oct 2016 21:17:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2016 21:17:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Sat, 29 Oct 2016 17:18:06 -0400 (EDT) Received: (qmail 12710 invoked from network); 29 Oct 2016 21:18:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2016 21:18:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B30F5EC8AEF; Sat, 29 Oct 2016 14:18:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> Date: Sat, 29 Oct 2016 14:18:01 -0700 Cc: freebsd-current@freebsd.org, freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 21:18:04 -0000 [I re-established the crotchet-build based failure context finally. = Unfortunately truss just dies in a new place.] On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: > On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>=20 >> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>=20 >> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>=20 >> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >> 381 if (t->cs.name =3D=3D NULL) >> (gdb)=20 >> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >> 383 t->proc->abi->type, t->cs.number); >> 384=09 >> 385 sc =3D get_syscall(t->cs.name, narg); >> 386 t->cs.nargs =3D sc->nargs; >> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >> 388=09 >> 389 t->cs.sc =3D sc; >>=20 >> (gdb) print *t >> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D= 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name = =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>=20 >> (gdb) print sc >> $3 =3D (struct syscall *) 0x0 >>=20 >> So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. >>=20 >> Looking at the two things that the fprintf on lines 382 and 383 would = report: >>=20 >> (gdb) print t->proc->abi->type >> $4 =3D 0x10166 "FreeBSD ELF32" >>=20 >> (gdb) print t->cs.number >> $5 =3D 580828064 >>=20 >> (gdb) print narg >> $6 =3D 0 >>=20 >> (that last is for context for the get_syscall arguments). >>=20 >> FYI: 580828064 =3D 0x229EBBA0 >=20 > I have a patchset I have tested some in a git branch that I believe = fixes handling of > unknown system calls. Please try this: >=20 > = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >=20 > (Add .diff to get a diff you can apply with patch) >=20 >=20 > --=20 > John Baldwin [Watch out for inlining consequences in how gdb presents things. Also I = extracted from my explorations and changed the presentation order to = eliminate junk.] Summary: st->syscalls ends up NULL from reallocf refusing a huge = allocation because t->cs.number=3D=3D580828064, which would make for a = huge offset in st->syscalls[number] . new_count * = sizeof(st->syscalls[0]) would be rather large (new_count =3D=3D = number+1) . reallocf's result needs to be tested and/or reasonable-value-checks on = t->cs.number (a.k.a. number) need to be made and unreasonable value = handled some other way. The supporting details: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss GNU gdb 6.1.1 [FreeBSD] . . . (gdb) run -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Starting program: /usr/bin/truss -faeH -o truss.log . . . . Program received signal SIGSEGV, Segmentation fault. 0x20241ebc in memset () from /lib/libc.so.7 Current language: auto; currently minimal (gdb) bt #0 0x20241ebc in memset () from /lib/libc.so.7 #1 0x0000aec8 in get_syscall (t=3D, = number=3D580828064, nargs=3D0) at /usr/src/usr.bin/truss/syscalls.c:956 #2 0x0000ab8c in enter_syscall (info=3D0x20612000, t=3D0x2061b0a0, = pl=3D) at /usr/src/usr.bin/truss/setup.c:380 #3 0x0000a798 in eventloop (info=3D) at = /usr/src/usr.bin/truss/setup.c:664 #4 0x000098d4 in $a.6 () at /usr/src/usr.bin/truss/main.c:207 #5 0x000098d4 in $a.6 () at /usr/src/usr.bin/truss/main.c:207 (gdb) up #1 0x0000aec8 in get_syscall (t=3D, = number=3D580828064, nargs=3D0) at /usr/src/usr.bin/truss/syscalls.c:956 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * . . . 0x20241eac : cmp r1, #4 ; 0x4 0x20241eb0 : bge 0x20241dd4 0x20241eb4 : cmp r1, #0 ; 0x0 0x20241eb8 : moveq pc, lr 0x20241ebc : strb r3, [r12], #1 . . . (gdb) info reg r0 0x0 0 r1 0x8a7aee84 -1971655036 r2 0x8a7aee84 -1971655036 r3 0x0 0 r4 0x1 1 r5 0x2062000c 543293452 r6 0x20620000 543293440 r7 0x229ebba1 580828065 r8 0x2061b0b0 543273136 r9 0x0 0 r10 0x229ebba0 580828064 r11 0xbfbfe478 -1077943176 r12 0x0 0 sp 0xbfbfe450 -1077943216 lr 0xaec8 44744 pc 0x20241ebc 539238076 fps 0x0 0 cpsr 0xa0000010 -1610612720 . . . (gdb)=20 946 static void 947 grow_syscall_table(struct syscall_table *st, u_int number) 948 { 949 u_int new_count; 950=09 951 new_count =3D number + 1; 952 if (st->count >=3D new_count) 953 return; 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); (gdb)=20 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); 958 } 959=09 960 /* 961 * If/when the list gets big, it might be desirable to do it 962 * as a hash table or binary search. 963 */ 964 struct syscall * 965 get_syscall(struct threadinfo *t, u_int number, u_int nargs) (gdb)=20 966 { 967 struct syscall_table *st; 968 struct syscall *sc; 969 const char *name; 970 u_int i; 971=09 972 st =3D lookup_syscall_table(t->proc->abi->abi); 973 grow_syscall_table(st, number); 974 sc =3D st->syscalls[number]; 975 if (sc !=3D NULL) (gdb)=20 976 return (sc); . . . 951 new_count =3D number + 1; 952 if (st->count >=3D new_count) 953 return; 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); 958 } 959=09 960 /* (gdb) up #2 0x0000ab8c in enter_syscall (info=3D0x20612000, t=3D0x2061b0a0, = pl=3D) at /usr/src/usr.bin/truss/setup.c:380 380 sc =3D get_syscall(t, t->cs.number, narg); (gdb) list 375 if (narg !=3D 0 && t->proc->abi->fetch_args(info, narg) = !=3D 0) { 376 free_syscall(t); 377 return; 378 } 379=09 380 sc =3D get_syscall(t, t->cs.number, narg); 381 if (sc->unknown) 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 (gdb) print *t=20 $1 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617028}, proc =3D = 0x20617018, tid =3D 100103, in_syscall =3D 1, cs =3D {sc =3D 0x0, number = =3D 580828064, nargs =3D 0, args =3D 0x2061b0c0, s_args =3D 0x2061b0e8},=20= before =3D {tv_sec =3D 1477771714, tv_nsec =3D 696971654}, after =3D = {tv_sec =3D 1477771714, tv_nsec =3D 697117646}} (gdb) print narg $2 =3D 0 . . . (gdb) print t->cs.number $9 =3D 580828064 . . . (gdb) print *(t->proc) $6 =3D {entries =3D {le_next =3D 0x20617000, le_prev =3D 0x20617048}, = pid =3D 808, abi =3D 0x1ee68, threadlist =3D {lh_first =3D 0x2061b0a0}} (gdb) print *(t->proc->abi) $7 =3D {type =3D 0x1026b "FreeBSD ELF32", abi =3D SYSDECODE_ABI_FREEBSD, = fetch_args =3D 0xda44 , fetch_retval =3D 0xdb64 = } (gdb) print t->proc->abi->abi $8 =3D SYSDECODE_ABI_FREEBSD So for t->cs.number=3D=3D580828064 : 380 sc =3D get_syscall(t, t->cs.number, narg); . . . 965 get_syscall(struct threadinfo *t, u_int number, u_int nargs) . . . 973 grow_syscall_table(st, number); 974 sc =3D st->syscalls[number]; would get very far away from st->syscalls after indexing by the large = number=3D=3D580828064 --if the grow could even complete for = number=3D=3D580828064 : 947 grow_syscall_table(struct syscall_table *st, u_int number) 948 { . .. 951 new_count =3D number + 1; . . . 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); st->syscalls was NULL after reallocf returned the value NUKL. =3D=3D=3D Mark Millard markmi at dsl-only.net