From owner-freebsd-stable@freebsd.org Sun Feb 12 19:36:41 2017 Return-Path: Delivered-To: freebsd-stable@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 5C896CDC891 for ; Sun, 12 Feb 2017 19:36:41 +0000 (UTC) (envelope-from marketing@saraexim.in) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 2BF1E1B5A for ; Sun, 12 Feb 2017 19:36:40 +0000 (UTC) (envelope-from marketing@saraexim.in) Received: by mail-oi0-x233.google.com with SMTP id u143so41371993oif.3 for ; Sun, 12 Feb 2017 11:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saraexim-in.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=d81PJQHbR+zfEjEPa20J9qOhCPAP1O7LOJOzGn0ygnk=; b=aYYfe/mtuP8hvPfqIxv2qWq2DfijjZEW+2WePaYSFYfkvLOE+KfH9VyiRCnHZSCFfr u42N9kb0S2qDD20QezRnopiw+qrJ0VNWYvvEKctyEi0JhEfD2+Y3uD0rUy1J+PHXw8us eL2tszz02AsYuLQE6BbdAprccHTfgV5QfCcnrm5ainEORI9NLcFXPyxtpTSqcBfUCtcD tNhurHEDNlX4BS+fLnnEK8zKyJNZh3Mw/0MzEmdZ+auZJCb6bH0quv3faZcwS9nX2+ew 1jB5y3R1tiQXSFzksuoZFmq362I3JYXLyLCsDmAXe3pmTnSKadJSblrqF1xttYoFAWeV Q//g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d81PJQHbR+zfEjEPa20J9qOhCPAP1O7LOJOzGn0ygnk=; b=UeqHElNON5zCgYkgNOLHhvjHs8zX9C0UVeL7SLV6zo9gv+jhGoZUKWD+NATGduOATA 61QA6UAndgA/HPsfEcl3LyfnUua/v3mPrjBgwVIVhZkPKNU30FEjyTMgYum6ZcCS03Ru RUHv9/UHOM5QovD2PzkbwehPu3JZpYleze1HjjWvHrS0gXDTb7jZJ4Jhll1wUFQFK2bO 8st0c8c17HskXY+u5COAeBEENCS6smt2kJ7+PFiZCtNbyiTR5E9mPIwjGIpTLymGalnj gDJztWcff7EAmAZA8l0rRo0AFVRroB5zJhAXI4wMnfSrK605kmYv8RoKggMo3iFPplMn 4Dkg== X-Gm-Message-State: AMke39k6LCKobEo5DTkhHEaM2iWYkGNPcaaaOxvH4jkBp56G6eGTY7ne7QwUzz0q9K5x8dqI+oZKnhdMk7DHqw== X-Received: by 10.202.81.77 with SMTP id f74mr10193410oib.207.1486928199476; Sun, 12 Feb 2017 11:36:39 -0800 (PST) Received: from 776393159873 named unknown by gmailapi.google.com with HTTPREST; Sun, 12 Feb 2017 11:35:45 -0800 MIME-Version: 1.0 Received: by 10.176.4.194 with HTTP; Tue, 10 Jan 2017 00:34:38 -0800 (PST) From: Sara International Date: Sun, 12 Feb 2017 11:35:45 -0800 Message-ID: Subject: Eco-friendly Jute and Cotton Bags for gifting your customers To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:36:41 -0000 Hello Sir/ Ma'am, Attached is the standard catalog of jute and cotton bags. We are Sara International, a leading manufacturer, exporter, and seller of jute, cotton, and canvas handbags. Our prices are very attractive, and the quality of our bags and prints are finest in the industry. We supply our bags to businesses all over the world= . Please visit our website at (www . saraexim . co) for more information about our company and products. If you are not the person in your organization to orders bags or promotional items, please forward this email to the relevant individual or department. Thank you. Best Regards *Mousumi Nandan * SARA | Business Development Executive Mobile: +91 987 45678 47 Office: +91 33 400 88 333 Email: mousumi.sarainternational@gmail.com sales.sarainternational@gmail.com info.sarainternational@gmail.com Sara International =E2=80=9CWe believe in building long term relationship=E2=80=9D 55 Ezra Street, 2nd Floor, Kolkata West Bengal, India How this email was sent From owner-freebsd-stable@freebsd.org Mon Feb 13 17:49:51 2017 Return-Path: Delivered-To: freebsd-stable@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 D10F6CDDCE8 for ; Mon, 13 Feb 2017 17:49:51 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 891B215FB for ; Mon, 13 Feb 2017 17:49:51 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: by mail-ot0-x236.google.com with SMTP id 65so73937878otq.2 for ; Mon, 13 Feb 2017 09:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/KdG0tMd4Ik117QcC+zuHUwjb1YcA4zKlWxlDofOkfk=; b=LEepHbw0KjlunxOJei1f5MlVYRb80sjklmdBlwWsuiLEOvSeSK155cte4jLYubO4eE 3ZPyHIeuCOP+kb3+7buBeNrpsYkx5mL76Onz4sijjesM8KajABaFGtoD2Zw0kivs6LT2 PhbQV9Bc3cNwVOz/YHu3gSazwXxYchx3b2RUdIkLXMd00HRWMCUwb4U3Wy8/WdXtckYR Iio7Hd6fQeo3o0dO3tTx8YhFD79eU2W+8ynqryr4swT1gJOZbakCW+db/MCHDEc0Nu0C yybvY5FD+fIj3qKQ1bBnff5+ll01Kjpim50PoFPxYx1uZgYKg1HioidYkIYL8aHb9b5e 7k4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/KdG0tMd4Ik117QcC+zuHUwjb1YcA4zKlWxlDofOkfk=; b=kEyoTHC+KwrQmqzDGd0vqv28H/zk4BgSI8sPwbeEbNvnObOR1KHtD1Ua/Ro92M4oF1 xJ6wiTR2uMxHeeRUTtdxIqYKiIyS0XudW5s8l87kZoS+PNuhZoMLTCay8lckcPgM8TUN 86GQGTGPsNBj3HGD/hMyFhupMnzMW/DQhQAFF46Qapja5wBBtXJnYg5/Ttjpxezgkjpc 3cSitjcp27XGHQ7Mop9hOxk56Ce2YNiufhyuhmMQB0cuW8kUA6ZrI2awrEZOwzyiWFgE HJv95wKJDGmbfFIXb5VRy86qLphC9UTQuCgq+HLHVrAAaNYtywrmRzLNMrnl+JjvCCW1 uvjw== X-Gm-Message-State: AMke39mlUwilKLeTjQdeCeIQaF0rCou2HUxEmwHUr23jP5KJMADX/1mEw8MS/nspzx2fSw== X-Received: by 10.98.198.90 with SMTP id m87mr26757838pfg.153.1487008190292; Mon, 13 Feb 2017 09:49:50 -0800 (PST) Received: from vanyel.ee.washington.edu (vanyel.ee.washington.edu. [128.208.232.99]) by smtp.gmail.com with ESMTPSA id s8sm22222315pfj.30.2017.02.13.09.49.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 09:49:48 -0800 (PST) Sender: Lee Damon Subject: Re: FBSD 10.3 + ZFS + Sun x4500 = utter lock up. To: freebsd-stable@freebsd.org References: <44ecebcb-fb48-d828-7f08-47a981b732d2@castle.org> From: Lee Damon Message-ID: Date: Mon, 13 Feb 2017 09:49:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:49:51 -0000 In what was arguably a silly attempt I changed all IRQ interrupts to go to CPU0 and .. the host has stayed up through multiple attempts to crash it. I'm not calling it fixed yet but there appears to be hope. Right now I have a script -- /usr/local/etc/rc.d/cpuset.sh -- that's doing the work. This seems a sub-optimal place to do it as there is a possibility of crash before the script is executed on boot. Is there any option in bootloader or related for setting these or is cpuset(1) my only option? thanks, nomad >> FreeBSD [redacted] 10.3-STABLE FreeBSD 10.3-STABLE #2 r313008: Tue Jan >> 31 01:50:49 PST 2017 lvd@[redacted]:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> I'm trying to get FBSD 10.3 working on a Sun x4500 (don't ask) for use >> as a ZFS-based backup server. However, whenever any amount of data is >> put into a zpool and then zpool scrub is run the host locks up hard. On >> reboot it complains that a "Hyper transport sync flood occurred". >> >> I found >> https://lists.freebsd.org/pipermail/freebsd-stable/2012-January/065542.html >> >> which seems to match but when I try the cpuset command mentioned there I >> get an error: >> >> ; sudo cpuset -c -l 0 -x 58 >> cpuset: setaffinity: Invalid argument >> >> Looks like the -c was invalid. After removing that I was informed -x 58 >> wasn't valid. Sure enough, there's no mpt0 or IRQ 58 on the host: >> >> ; vmstat -i >> interrupt total rate >> irq17: ohci2 8578 2 >> irq18: ohci3 473 0 >> irq19: ohci0 ohci1+ 4924 1 >> irq24: mvs0 457 0 >> irq32: mvs1 453 0 >> irq38: mvs2 451 0 >> irq46: mvs3 8063 1 >> irq52: em0 152354 35 >> irq53: em1 140 0 >> irq68: mvs4 450 0 >> irq76: mvs5 454 0 >> cpu0:timer 208311 48 >> cpu1:timer 98318 23 >> cpu2:timer 105704 24 >> cpu3:timer 106202 24 >> Total 695332 162 >> >> Looking around with some help from #freebsd on efnet I found mvs0-5 >> which are connected to the Marvel drive controllers on the host. I then >> used >> ; sudo cpuset -l 0 -x ## >> where I replaced ## with 24, 32, 38, 46, 68, and 76. >> >> After rebuilding the zpool I started writing to it. It took a lot less >> time to crash - I didn't even need to run zpool scrub - but instead of >> completely locking up it just rebooted. I did not see reference to the >> hyper transport problem while watching it boot but given the poor >> performance of the serial console I can't be 100% sure it wasn't there. >> >> So now I turn here to ask for guidance. Is anyone currently successfully >> running 10.x on a x4500 and if so, how are you doing it? If not, how can >> I get this working? >> >> thanks, >> nomad >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Mon Feb 13 19:00:48 2017 Return-Path: Delivered-To: freebsd-stable@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 B025FCDD627 for ; Mon, 13 Feb 2017 19:00:48 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 86B73CBC for ; Mon, 13 Feb 2017 19:00:48 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0096020A1D for ; Mon, 13 Feb 2017 14:00:40 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 13 Feb 2017 14:00:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qrwtfGahXYYUG/riQcfdaYjaPqY=; b=NQ7G1g fAsBTuPyvd9Bisfgbt9feI+dIF+gD+hCXHcOf/8kEaI2lH5PiDD2w3aY7ZQfF5l1 2VQ/UD8H7pKo5NeRWQ9AvL8T2HalWqamsr6y4i3jwbSoDj+otPklZXy9XXahsGY9 GfYStZuqjR40Pi6Q7b3LYeYpDEVlEYO9feikE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qrwtfGahXYYUG/ riQcfdaYjaPqY=; b=jnX5OtpCbKKy8nYDw5HquhmJWK8Ae5iweE1HCtvmoX2YjJ RocavDtoPUoVy8Oi5EZdNrwHzSXEhrzszo6KGdTed5gi4zz+7lZp+8a3Yuel6R70 yT0C/4iTV3dBvawFgN+GZ3ErOAYz4h/H+yNL4terZjEfTZDEyOq/qCOEJ5aFo= X-ME-Sender: X-Sasl-enc: jyfzlIIXfYrQrChgAksAhLf2vC82pHcEJO3UgwpvNRUC 1487012440 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 892A57E2E5 for ; Mon, 13 Feb 2017 14:00:40 -0500 (EST) To: freebsd-stable@freebsd.org From: tech-lists Subject: how can I make freebsd wait for usb to become active? Or delay mountroot? Message-ID: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> Date: Mon, 13 Feb 2017 19:00:39 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:00:48 -0000 Hello stable@, system: 11-stable r313553 In the kernel there is an option for scsi delay. Is there also one for usb? Perhaps not in the kernel but elsewhere. I can't find it. The problem is seen especially where the bootable device is usb. The boot process starts and dumps me at mountroot where I wait for a short time until the usb stick is properly detected (bright white writing at the console). The usb stick is plugged into a usb3 port. For example: [snip] usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 ugen0.1: <0x1022 XHCI root HUB> at usbus0 uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 acpi_tz0: _CRT value is absurd, ignored (255.1C) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number 1415TP277450E0H6H cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open ada0: Serial Number JA1006103G0ALV ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC" frequency 1597045198 Hz quality 1000 Trying to mount root from ufs:/dev/da0p2 [rw]... uhub3: 5 ports with 5 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus4 usbus2 usbus0 ugen0.2: at usbus0 umass0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:3:0: Attached to scbus3 uhub2: 5 ports with 5 removable, self powered uhub4: 5 ports with 5 removable, self powered ugen0.3: at usbus0 ukbd0 on uhub0 ukbd0: on usbus0 kbd2 at ukbd0 Root mount waiting for: usbus4 ugen4.2: at usbus4 mountroot: waiting for device /dev/da0p2... Mounting from ufs:/dev/da0p2 failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/da0p2 vfs.root.mountfrom.options=rw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> Trying to mount root from ufs:/dev/da0p2 []... mountroot: waiting for device /dev/da0p2... Mounting from ufs:/dev/da0p2 failed with error 19. mountroot> [snip] Then this happens: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: < USB DISK 3.0 PMAP> Removable Direct Access SPC-4 SCSI device da0: Serial Number 070B4722335D3288 da0: 400.000MB/s transfers da0: 30176MB (61800448 512 byte sectors) da0: quirks=0x3 so now at the mountroot prompt I enter ufs:/dev/da0p2 (which is a value that mountroot already had) and carry on booting: mountroot> Trying to mount root from ufs:/dev/da0p2 []... re0: link state changed to DOWN re0: link state changed to UP ums0 on uhub0 ums0: on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=2 uhid0 on uhub0 uhid0: on usbus0 [...] The same sort of thing happens on an 11-stable r313043 desktop, only this time I'm not booting from usb. The system comes up, I get a login prompt, then five or ten seconds later usb wakes up having detected the usb3 external HD. How can I fix this? thanks, -- J. From owner-freebsd-stable@freebsd.org Mon Feb 13 19:10:52 2017 Return-Path: Delivered-To: freebsd-stable@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 A20BCCDDF7D for ; Mon, 13 Feb 2017 19:10:52 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F1541B21 for ; Mon, 13 Feb 2017 19:10:52 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0B5DF3A4; Mon, 13 Feb 2017 14:10:45 -0500 (EST) From: Paul Mather Message-Id: <7DD96F71-7A21-4125-BB6B-53458A400FDC@gromit.dlib.vt.edu> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: how can I make freebsd wait for usb to become active? Or delay mountroot? Date: Mon, 13 Feb 2017 14:10:44 -0500 In-Reply-To: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> Cc: freebsd-stable@freebsd.org To: tech-lists References: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:10:52 -0000 On Feb 13, 2017, at 2:00 PM, tech-lists wrote: > Hello stable@, >=20 > system: 11-stable r313553 >=20 > In the kernel there is an option for scsi delay. Is there also one for > usb? Perhaps not in the kernel but elsewhere. I can't find it. >=20 > The problem is seen especially where the bootable device is usb. The > boot process starts and dumps me at mountroot where I wait for a short > time until the usb stick is properly detected (bright white writing at > the console). The usb stick is plugged into a usb3 port. For example: >=20 > [snip] >=20 > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > usbus3: 12Mbps Full Speed USB v1.0 > ugen0.1: <0x1022 XHCI root HUB> at usbus0 > uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on = usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 480Mbps High Speed USB v2.0 > ugen4.1: at usbus4 > uhub4: on usbus4 > acpi_tz0: _CRT value is absurd, ignored (255.1C) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number 1415TP277450E0H6H > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO = 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not = present > - tray open > ada0: Serial Number JA1006103G0ALV > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > Timecounter "TSC" frequency 1597045198 Hz quality 1000 > Trying to mount root from ufs:/dev/da0p2 [rw]... > uhub3: 5 ports with 5 removable, self powered > uhub1: 5 ports with 5 removable, self powered > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus4 usbus2 usbus0 > ugen0.2: at usbus0 > umass0 on uhub0 > umass0: > on usbus0 > umass0: SCSI over Bulk-Only; quirks =3D 0x8100 > umass0:3:0: Attached to scbus3 > uhub2: 5 ports with 5 removable, self powered > uhub4: 5 ports with 5 removable, self powered > ugen0.3: at usbus0 > ukbd0 on uhub0 > ukbd0: on = usbus0 > kbd2 at ukbd0 > Root mount waiting for: usbus4 > ugen4.2: at usbus4 > mountroot: waiting for device /dev/da0p2... > Mounting from ufs:/dev/da0p2 failed with error 19. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/da0p2 > vfs.root.mountfrom.options=3Drw >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot> Trying to mount root from ufs:/dev/da0p2 []... > mountroot: waiting for device /dev/da0p2... > Mounting from ufs:/dev/da0p2 failed with error 19. >=20 > mountroot> >=20 > [snip] >=20 > Then this happens: >=20 > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > da0: < USB DISK 3.0 PMAP> Removable Direct Access SPC-4 SCSI device > da0: Serial Number 070B4722335D3288 > da0: 400.000MB/s transfers > da0: 30176MB (61800448 512 byte sectors) > da0: quirks=3D0x3 >=20 > so now at the mountroot prompt I enter ufs:/dev/da0p2 (which is a = value > that mountroot already had) and carry on booting: >=20 > mountroot> Trying to mount root from ufs:/dev/da0p2 []... > re0: link state changed to DOWN > re0: link state changed to UP > ums0 on uhub0 > ums0: on = usbus0 > ums0: 16 buttons and [XYZT] coordinates ID=3D2 > uhid0 on uhub0 > uhid0: on = usbus0 >=20 > [...] >=20 > The same sort of thing happens on an 11-stable r313043 desktop, only > this time I'm not booting from usb. The system comes up, I get a login > prompt, then five or ten seconds later usb wakes up having detected = the > usb3 external HD. >=20 > How can I fix this? This topic cropped up on the freebsd-arm mailing list very recently. = One solution is to add this to /boot/loader.conf: kern.cam.boot_delay=3D"10000" That instructs the system to wait 10 seconds (10000 milliseconds) during = boot to give time for the CAM subsystem probes to complete. (USB = storage devices use the CAM subsystem.) It was also noted by Konstantin Belousov in that thread = (https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015626.html= = ) that a newer option is available: > Right solution after r313350 is to set > vfs.root_mount_always_wait=3D1 > loader tunable. The knob should be merged to 11 in two weeks. Cheers, Paul. From owner-freebsd-stable@freebsd.org Mon Feb 13 19:39:31 2017 Return-Path: Delivered-To: freebsd-stable@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 60E80CDDEEB for ; Mon, 13 Feb 2017 19:39:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32DD113CC for ; Mon, 13 Feb 2017 19:39:30 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v1DJds48010309 for ; Mon, 13 Feb 2017 11:40:00 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> References: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> From: "Chris H" Subject: Re: how can I make freebsd wait for usb to become active? Or delay mountroot? Date: Mon, 13 Feb 2017 11:40:00 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <858090ca400d6f91c461b1d62c94edab@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:39:31 -0000 On Mon, 13 Feb 2017 19:00:39 +0000 tech-lists wrote > Hello stable@, > > system: 11-stable r313553 > > In the kernel there is an option for scsi delay. It should be enough to bump the kern.cam.scsi_delay= a couple hundred at a time, until you find the "sweet spot". You might also try the autoboot_delay= option instead. It might give your USB port enough time to come ready. > Is there also one for > usb? Perhaps not in the kernel but elsewhere. I can't find it. > > The problem is seen especially where the bootable device is usb. The > boot process starts and dumps me at mountroot where I wait for a short > time until the usb stick is properly detected (bright white writing at > the console). The usb stick is plugged into a usb3 port. For example: > > [snip] > > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > usbus3: 12Mbps Full Speed USB v1.0 > ugen0.1: <0x1022 XHCI root HUB> at usbus0 > uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 480Mbps High Speed USB v2.0 > ugen4.1: at usbus4 > uhub4: on usbus4 > acpi_tz0: _CRT value is absurd, ignored (255.1C) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number 1415TP277450E0H6H > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > - tray open > ada0: Serial Number JA1006103G0ALV > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > Timecounter "TSC" frequency 1597045198 Hz quality 1000 > Trying to mount root from ufs:/dev/da0p2 [rw]... > uhub3: 5 ports with 5 removable, self powered > uhub1: 5 ports with 5 removable, self powered > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus4 usbus2 usbus0 > ugen0.2: at usbus0 > umass0 on uhub0 > umass0: > on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x8100 > umass0:3:0: Attached to scbus3 > uhub2: 5 ports with 5 removable, self powered > uhub4: 5 ports with 5 removable, self powered > ugen0.3: at usbus0 > ukbd0 on uhub0 > ukbd0: on usbus0 > kbd2 at ukbd0 > Root mount waiting for: usbus4 > ugen4.2: at usbus4 > mountroot: waiting for device /dev/da0p2... > Mounting from ufs:/dev/da0p2 failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/da0p2 > vfs.root.mountfrom.options=rw > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/da0p2 []... > mountroot: waiting for device /dev/da0p2... > Mounting from ufs:/dev/da0p2 failed with error 19. > > mountroot> > > [snip] > > Then this happens: > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > da0: < USB DISK 3.0 PMAP> Removable Direct Access SPC-4 SCSI device > da0: Serial Number 070B4722335D3288 > da0: 400.000MB/s transfers > da0: 30176MB (61800448 512 byte sectors) > da0: quirks=0x3 > > so now at the mountroot prompt I enter ufs:/dev/da0p2 (which is a value > that mountroot already had) and carry on booting: > > mountroot> Trying to mount root from ufs:/dev/da0p2 []... > re0: link state changed to DOWN > re0: link state changed to UP > ums0 on uhub0 > ums0: on usbus0 > ums0: 16 buttons and [XYZT] coordinates ID=2 > uhid0 on uhub0 > uhid0: on usbus0 > > [...] > > The same sort of thing happens on an 11-stable r313043 desktop, only > this time I'm not booting from usb. The system comes up, I get a login > prompt, then five or ten seconds later usb wakes up having detected the > usb3 external HD. > > How can I fix this? > > thanks, > -- > J. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Feb 14 01:55:32 2017 Return-Path: Delivered-To: freebsd-stable@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 56D1FCDDE37 for ; Tue, 14 Feb 2017 01:55:32 +0000 (UTC) (envelope-from adventure30@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3248C16E3 for ; Tue, 14 Feb 2017 01:55:32 +0000 (UTC) (envelope-from adventure30@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 31B05CDDE35; Tue, 14 Feb 2017 01:55:32 +0000 (UTC) Delivered-To: stable@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 31617CDDE33 for ; Tue, 14 Feb 2017 01:55:32 +0000 (UTC) (envelope-from adventure30@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 E883316E2 for ; Tue, 14 Feb 2017 01:55:31 +0000 (UTC) (envelope-from adventure30@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id c7so13233309itd.1 for ; Mon, 13 Feb 2017 17:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=jhJ5KCHbHIXtXPLbiy2eMBzjt750xCP6MoqruTWcqM4=; b=qbOXukDUHmKL6JvrCOMMail2BFQbBu9iEs6oh8Khp9hKCg19KEI842xRPmYpIKOrWF vzGRpHxbEx3X6ANhvU3ia3sLhwzVoYYQqU7lAPswBzlZSYGx8OzRTE/RtGfF7E6i0KQK uuWk+tIWGFFrdPNcz1K2rIn1lwrT+WoQxHNw1NUJV0vc4yNa/We1EUgIVEEKzlkfkKDv iF509EO12ErGe75wz7H8nL8UAI8FsT8Fv2GZuMOxl2sXY5rIyQPoiQShMGvRGRQ/UDCs xTFafkq9JP6iL7J83WKrUKBQnX8efKpeHKLjf63ODgoFnHb+Ftai2EsVzP1HkwqdKk4o mWXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=jhJ5KCHbHIXtXPLbiy2eMBzjt750xCP6MoqruTWcqM4=; b=nuOURuwJoBxUD9g1/mLPz1yZnuQZWZ9KMT2X1LEYNxddOpuzM+DYnUJnbJQ+/cTAri 5FQF1yiw4337A1qaAmwJkoI+M5xFBDTOhfEQPpFBOHLmr5xKbLH67562qV3jvVrZg/Ze pXKdoy9X75QrDFORAqHQp3DisJhkvz8PfNYOl/5jgavf8cb4W7yONYleQL5pFrEI5y0v ZS51tkCnDHYr27p3plL8q9O/uyu7qMUy/SI8v5Y7RyEjVohX6UgprL9vW04P3vovGw9a Wm+y6A5fH97HnSBOY2mEC8EGLlUOS1sCyN6cnaG/p8gUqM87u77YrGSCQ0tsxBWXWaxW /ZhQ== X-Gm-Message-State: AMke39n8bkx8aC+CaSj8Bgjeovmd62s0lXW4SGR8dY+HJ9GxyDGRMfRpi4WBafO+NjqbEA== X-Received: by 10.36.40.142 with SMTP id h136mr1482448ith.95.1487037331271; Mon, 13 Feb 2017 17:55:31 -0800 (PST) Received: from ?IPv6:2001:470:1f11:380:a587:8319:5fda:764c? ([2001:470:1f11:380:a587:8319:5fda:764c]) by smtp.gmail.com with ESMTPSA id r85sm2591609itc.13.2017.02.13.17.55.30 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Feb 2017 17:55:30 -0800 (PST) From: Gene Content-Type: multipart/signed; boundary="Apple-Mail=_0D0979CF-1C12-47C9-A6E1-DBBD25DD6743"; protocol="application/pgp-signature"; micalg=pgp-sha256 Subject: subscribe Message-Id: <914D1568-73CF-442D-9929-91BCCB1DDEDE@gmail.com> Date: Mon, 13 Feb 2017 19:55:28 -0600 To: stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:55:32 -0000 --Apple-Mail=_0D0979CF-1C12-47C9-A6E1-DBBD25DD6743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTICE: The foregoing message contains confidential information = (including attachments) intended only for the use of the addressee(s) = named above. If you are not the addressee, or the person responsible for = delivering it to the addressee, you are hereby notified, reading, = disseminating, distributing, printing, or copying this message is = strictly prohibited. If you have received this message in error, please = notify us by replying to the message immediately. Also, please proceed = to erase the original message directly following your reply. Thank you. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_0D0979CF-1C12-47C9-A6E1-DBBD25DD6743 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYomORAAoJECuWvT/jFkeEoWcQAJTQf1xoVJty/CkhZUmKAz4c 3GLAAPjk6SLXEDET5JYug8vM22q0ysFAtW0qXRvpj2SatFbUxdNAbVmrEjGLxTY2 AkPdEeLaDF0MIXq0pMHT3ck7kAXHIEUiw9789N01LTLs+wyet6m7G+5gQWZLjUiE B8o0gQdXwjEQz+yBUbzClhVfz+k+S2N7XWUqEFtsSA0ToOsxB5PubW6wcWLNCceM u5tFxL6TQDyaZ+zX8hlRrbwtxFQA3ZLiKTVCA8tpfZabpFvvAWQoc3BQZUEHYgLq fcD2IK2CAOmIjSwTzzOyUxgR1EX9pRM4CIDE973SADTTdyvmeo0kngBVrXku6PFn EMjmHMu7r67qrQjNvCjPZpma6Evitbc9RzS+GiTxpzpdzBh4o+wakYaPgJU/sZ/c Cq04qKXewvkQNrN5lMupt4g6VchIj6RgMEXi18Cio2AhFogRNJnHEIIveYT1ICBs kJFIZpFQxaBDsNje+yXzNqXdPILTHqYUOBCRrfNRJrh6HaOSespezmnmoYdiiOIX xTkS6x9OkbhbpEYprr8vWFR2ahb6Cq4MqDuqSi/nN2i34lymfPs5my5YMV5pEnpP pDQioWA1sQyYXFczrZteg7N9fmpcMo675gdmatlLYCGRR/To/UBvyuFroJH9bnW/ 8lafzLRRwId3M9xE8bqC =gkOD -----END PGP SIGNATURE----- --Apple-Mail=_0D0979CF-1C12-47C9-A6E1-DBBD25DD6743-- From owner-freebsd-stable@freebsd.org Tue Feb 14 04:25:52 2017 Return-Path: Delivered-To: freebsd-stable@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 80B2ECDEECF; Tue, 14 Feb 2017 04:25:52 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 C475A1819; Tue, 14 Feb 2017 04:25:51 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-13fff7000000093f-34-58a285988f07 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 7A.3C.02367.89582A85; Mon, 13 Feb 2017 23:20:41 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v1E4Ke02016508; Mon, 13 Feb 2017 23:20:40 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v1E4Kaj6028452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2017 23:20:38 -0500 Date: Mon, 13 Feb 2017 22:20:35 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2016 Message-ID: <20170214042034.GA30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1p3ZuijC4OYvaYtd106zW8x584HJ Yvvmf4wWh5uFHFg8ZnyazxLAGMVlk5Kak1mWWqRvl8CVsf86a8GVJcwVa961sDQwzjrO1MXI ySEhYCIxafJRti5GLg4hgTYmiQ0Ld7FAOBsZJU53fWaEcK4ySbzr2sDexcjBwSKgKjH/rjBI N5uAmsT6FdeYQWwRAXmJfU3v2UFsZgFriX8PGplByoUF7CRunc0GCfMCLTuw8wAjhC0ocXLm ExaIch2JnVvvsIGUMwtISyz/xwERlpdo3jobbLqogLJEw4wHzBMY+Wch6Z6FpHsWQvcsJN0L GFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAUru4vqDsY5f70OMQpwMCrx 8E44sDBCiDWxrLgy9xCjJAeTkihv7CagEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFejbhFEUK8 KYmVValF+TApaQ4WJXFecY3GCCGB9MSS1OzU1ILUIpisDAeHkgTv8RagRsGi1PTUirTMnBKE NBMHJ8hwHqDhv0BqeIsLEnOLM9Mh8qcYLTlO3Tj9konjzMkrQHJX94TXTEIsefl5qVLivN7A 9CEkANKQUZoHNxOUfCSy99e8YhQHelGY9wTIWB5g4oKb+gpoIRPQQta4hSALSxIRUlINjEUe W9cnH2PP63tmstJ/9lKrz52+O270PjIucJ62ZvqBO9cClIu/b7L9+zvBfeX725bvk8zqJXgL 3G/uvegoYvX2jvHly9ezmMx3bb4pcaB73eeqRNGqiq5v19Yz75mcerv4LcPHo7Fr5qVWrTg2 /9y0X34PhP+aOTBdvb5jzgaB2HWTNFdOt3ypxFKckWioxVxUnAgAIxrTUBkDAAA= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 04:25:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report - 4th Quarter 2016 Another year has passed (and another has gotten well underway, while we worked to assemble this report). Over the past two years that I have been part of the monthly@ team that assembles these reports, it has been enlightening to watch the individual entries pass through my emacs and/or vim. These reports give me a picture of what is going on with FreeBSD that I could not get just from reading commit mail; I hope that is also true for our readers. This quarter brings the usual mix of continuations of many stalwart projects and entires of new participants, as well as the return of some items after a few quarters' hiatus. Enjoy and be enlightened! --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from January to March 2017 is April 7, 2017. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation Projects * Ceph on FreeBSD * OpenBSM * Sysctl Exporter for Prometheus * The Graphics Stack on FreeBSD Kernel * FreeBSD on Hyper-V and Azure * I2C, GPIO, and SPI Support for MinnowBoard Architectures * FreeBSD on ARM Boards * FreeBSD/arm64 * FreeBSD/EC2 Userland Programs * libarchive * Reproducible Builds in FreeBSD * Updates to GDB * Using LLVM's LLD Linker as FreeBSD's System Linker Ports * GCC (GNU Compiler Collection) * LXQt on FreeBSD * Mono * Wine * Xfce on FreeBSD __________________________________________________________________ FreeBSD Team Reports FreeBSD Release Engineering Team Links FreeBSD 11.0-RELEASE Announcement URL: https://www.FreeBSD.org/releases/11.0R/announce.html FreeBSD 11.0-RELEASE Release Notes URL: https://www.FreeBSD.org/releases/11.0R/relnotes.html FreeBSD Development Snapshots URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team in concert with the FreeBSD Security Team finalized FreeBSD 11.0-RELEASE. FreeBSD 11.0-RELEASE was announced on October 10, 2016, roughly four weeks after the original schedule. The FreeBSD Release Engineering Team would like to specifically thank Colin Percival and all members of the FreeBSD Security Team for their extra diligence in ensuring that user-facing upgrade paths were properly addressed and documented. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.FreeBSD.org/index.html Ports Management Team URL: https://www.FreeBSD.org/portmgr/index.html FreeBSD portmgr on Twitter (@FreeBSD_portmgr) URL: https://twitter.com/FreeBSD_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Tree has reached the marker of 27,000 ports, with the PR count risen slightly to around 2,250. Of these PRs, 572 are unassigned. The last quarter saw 6871 commits by 176 committers. The number of open and the number of unassigned PRs both increased lightly since last quarter. Two commit bits were taken in for safe keeping in the last quarter: jmg after 19 months of inactivity, and edwin at his own request. We welcomed three new committers: Nikolai Lifanov (lifanov), Jason Bacon, and Mikhail Pchelin (misha). On the management side, adamw and feld were elected as new portmgr members, and rene was promoted to full member. feld is already involved in ports-secteam. On the infrastructure side, two new USES (lxqt and varnish) were introduced. Some default versions were also updated: varnish 4 (new), GCC 4.8 to 4.9, Perl 5.20 to 5.24, and Python 3.4 to 3.5. Two major ports reached their end-of-life at December 31st and were removed: Perl 5.18 and Linux Fedora 10 (the default is Linux CentOS 6). Because FreeBSD 9.3, 10.1, and 10.2 also reached end-of-life, support for those versions was removed from the Ports Tree. Some major ports were updated to their latest versions: pkg to 1.9.4, Firefox to 50.1.0, Firefox-esr to 45.6.0, Chromium to 54.0.2840.100, and Ruby to 2.1.10 / 2.2.6 / 2.3.3. www/node was updated to version 7; version 6 was split off as www/node6 for long-term support. Behind the scenes, antoine ran 39 exp-runs to verify package updates, framework changes, and changes to the base system. bdrewery installed new package builders and added builds for FreeBSD 11 for mips, mips64, and armv6. He also improved the balancing, monitoring, automation of the package builders. Open tasks: 1. If you have some spare time, please take up a PR for testing and committing. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The major concern for Core during the last quarter of 2016 has been about maintaining the effectiveness of secteam. The team is primarily in need of better project management, both to improve communication generally and to allow the other team members to concentrate on the technical aspects of handling vulnerabilities. To that end, there has been agreement in principle for either the FreeBSD Foundation or one of the companies that are major FreeBSD users to employ someone specifically in this role. Core confirmed that the new support model would go into effect with 11.0-RELEASE despite the postponement of the switch to a packaged base release mechanism. For details of the new support model, please follow the links from the security page of the FreeBSD website. Core requested the removal of the misc/jive port, on the grounds that it had no function other than to turn text into an offensively racist parody. This proved controversial, with many seeing this as a first step in bowdlerizing the entire ports tree. That is certainly not Core's intention. Core's aim here is to help secure the future of the FreeBSD project by making it welcoming to all contributors, regardless of ethnicity, gender, sexuality or other improper bases for discrimintation. While misc/jive may once have been seen as harmless fun, today the implicit approval implied by having it in the ports tree sends a message at odds with the project's aims. The Marketing team and the associated marketing@FreeBSD.org mailing list were wound up, due to lack of activity. Messages to marketing@FreeBSD.org will be forwarded to the FreeBSD Foundation's marketing team instead. Core member Allan Jude, who was already the clusteradm liason, became a full member of clusteradm. An emergency correction to the 11.0 release notes was authorised, as it was giving the misleading impression that 802.11n wireless support had only just been added, and this misapprehension was being repeated in the press. In reality, FreeBSD has had 802.11n support for many years, and the announcement should have said that support had been added to many additional device drivers. Discussions about a proposal to improve Unicode support are on-going. FreeBSD is already standards conformant, but the propsal is to switch to a __STDC_ISO_10646_ implementation, similar to what Linux glibc currently uses. Opinions are divided on the technical merits of the new approach. There were the usual quota of queries about licensing and other legal matters: * Plans to create a GPLv3 overlay for the base system were shelved in the light of faster than expected progress at enabling building the world using an external toolchain. * The trademarks page on the website was updated to show the current owners of a number of trademarks in their approved form. * In the absence of a tool to extract and summarize all of the relevant information, the obligation in the BSD license that "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution." is fulfilled by providing a tarball of the system sources with their embedded copyright statements. * The European Court of Justice's "Right to be Forgotten" only applies to search engines, and the FreeBSD project is not one of those, so it need not take any action. * Core is following closely discussions within the LLVM project regarding a change of license which, if implemented, might require an audit of the entire ports tree to discover all packages that contain binaries linked against libc++ and ensure that they are licensed compatibly with LLVM. However, indications are that the LLVM project will not adopt such changes. * The "Open Source Exception" in the firmware license means that committing a "binary blob" driver for the Nvidia Jetson TK1 XHCI device is acceptable. During this quarter four new commit bits were awarded. Please welcome Dexuan Cui, David Bright, Konrad Witaszczyk, and Piotr Stefaniak. We were sorry to see Edwin Lansing hang up his commit bits and step down from portmgr. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Our work is 100% funded by your donations. We raised $1,527,540 in 2016 from 1471 donors! Thank you to everyone who made a donation to help us continue our efforts in 2017 to support the FreeBSD Project and community worldwide! You can make a donation here to our 2017 fundraising campaign: https://www.FreeBSDfoundation.org/donate/. OS Improvements The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. This also includes funding separate project grants like the arm64 port, blacklistd access control daemon, and integration of VIMAGE support, to make sure that FreeBSD remains a viable solution for research, education, computing, products and more. Large projects supported last year include: * arm64 port * VIMAGE Integration * Toolchain work * blacklistd access control daemon The Foundation team worked on a technology roadmap for 2017-2018 during our board meeting in November. Staff and board members continued hosting bi-weekly conference calls to facilitate efforts for individuals to collaborate on different technologies. You can find out more about the support we provided by reading individual updates from Ed Maste, Konstatin Belousov, and Edward Napierala in this report. Release Engineering The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years. Last quarter, our full-time staff member worked with the FreeBSD Release Engineering and Security Teams to finalize 11.0-RELEASE. He also added support for the powerpcspe architecture to the 12-CURRENT snapshot builds, and continued work on packaging the base system with pkg(8). He also continued producing 10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds throughout the quarter. You can find out more about the support we provided to the Release Engineering Team by reading their status update in this report. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. This year, we purchased the following hardware to improve the build, continuous integration, and platform processes: * A server to reduce the build time from over an hour to 20 minutes for the continuous integration process. You can find out more information here: https://ci.FreeBSD.org/ . * Two ThunderX servers for native package builds for the FreeBSD/arm64 architecture. * Two servers to improve release engineering builds. * Four servers to improve package builds. * Four servers as build slaves to increase the number of builds in the continuous integration process. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. Here is a list highlighting some of the advocacy and education work we did last year: * Attended and/or sponsored 24 events around the world * Provided 15 Travel Grants to developers * Created new and updated marketing literature including: + Updated FreeBSD 10 Brochure + New TeachBSD postcard to spread the word about the program + Google Summer of Code flyer + FreeBSD 11 Brochure + Updated Recruiting Flyer + Updated Get Involved Flyer + FreeBSD as a Platform for Research Flyer * Created a series of FreeBSD How-to Guides: + Installing FreeBSD with VirtualBox (Mac/Windows) + Installing a Desktop Environment on FreeBSD + Installing FreeBSD for Raspberry Pi + Installing PC-BSD as a Primary Operating System + FreeBSD Setup Tips * Acquired New Testimonials: + Accelerations Systems + NeoSmart Technologies + Chelsio Communications + Crescent River Port Pilots' Association + IXC + Stormshield * Updated the FreeBSD Project and Foundation Branding: + New FreeBSD Foundation website and logo + Updated Brand Assets page to include more information about the FreeBSD Project and FreeBSD Foundation logos. We published our September/October and November/December Journal issues at https://www.FreeBSDfoundation.org/journal/ . We also published monthly newsletters to highlight work being done to support FreeBSD, tell you about upcoming events, and provide other information to keep you in the loop of what we are doing to support the FreeBSD Project and community: https://www.FreeBSDfoundation.org/news-and-events/newsletter/ . Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We also sponsored or attended the following events last quarter: * Ohio LinuxFest, October, Columbus, Ohio * Grace Hopper 2016, October, Houston, TX * COSC 2016, October, Beijing, China * Bay Area FreeBSD Vendor and Devoloper's Summit and MeetBSD 2016, November, Berkely, CA * USENIX LISA '16, December, Boston, MA * OSC 2016, December, Beijing, China Get the whole list of conferences we supported in 2016 at: https://www.FreeBSDfoundation.org/blog/recap-of-2016-advocacy-efforts/ . Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. We also provided legal support for the core team to investigate the status of certain patents. FreeBSD Community Engagement Anne Dickison, our Marketing Director, has been overseeing the efforts to rewrite the Project's Code of Conduct to help make this a safe, inclusive, and welcoming community. The updated Code of Conduct and Report Guidelines are going through the final review process, and will be handed off to the Core Team for approval in Q1 2017. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ Projects Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My FreeBSD Fork URL: https://github.com/wjwithagen/ceph/tree/wip.FreeBSD Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability: * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. But I aim to run a Ceph storage cluster of storage nodes that are running ZFS. User stations would be running bhyve on RBD disks that are stored in Ceph. The FreeBSD build of Ceph includes most of the tools Ceph provides. Note that the RBD-dependent items will not work, since FreeBSD does not have RBD (yet). The most notable progress since the last report: * RBD is actually buildable and can be used to manage RADOS BLOCK DEVICEs. * All tests run to completion for the current selection of tools, though the neded (minor) patches have yet to be pulled into HEAD. * Cmake is now the only way of building Ceph. * The threading/polling code has been reworked for the simple socket code. It now uses a self-pipe, instead of using an odd shutdown()-signaling Linux feature. * The EventKqueue code was modified to work around the "feature" that starting threads destroys the kqueue handles. The code was just finshed, so it is not yet submitted to the main repository. * We investigated differences between FreeBSD and Linux for SO_REUSEADDR and SO_REUSEPORT. Fortunately, the code is only used during testing, so disabling these features only delays progress in the tests. * A jenkins instances is regularly testing both ceph/ceph/master and wjwithagen/ceph/wip.FreeBSD, so there is regular verification of buildability and the tests: http://cephdev.digiware.nl:8180/jenkins/ . Build Prerequisites Compiling and building Ceph is tested on 12-CURRENT with its clang 3.9.0, but 11-RELEASE will probably also work, given experience with clang 3.7.0 from 11-CURRENT. Interestingly, when 12-CURRENT had clang 3.8.0, that did not work as well as either 3.7.0 or 3.9.0. The clang 3.4 present in 10-STABLE does not have the required capabilities to compile everything. The following setup will get things running for FreeBSD: 1. Install bash and link it in /bin 2. It is no longer necessary to add a definition of ENODATA to /usr/include/errno.h 3. Clone the github repo (http://github.com/wjwithagen/ceph.git) and checkout the "wip.FreeBSD" branch 4. Run ./do_FreeBSD.sh to start the build. The old build method using automake is no longer used; see the README.FreeBSD for more details. Parts not (yet) included: * KRBD: Kernel Rados Block Devices is implemented in the Linux kernel, but not in the FreeBSD kernel. Perhaps ggated could be used as a template since it does some of the same things as KRBD, just between 2 disks. It also has a userspace counterpart, which could ease development. * BlueStore: FreeBSD and Linux have different AIO APIs, and that incompatibility needs to be resolved somehow. Additionally, there is discussion in FreeBSD about aio_cancel not working for all devicetypes. * CephFS: Cython tries to access an internal field in struct dirent, which does not compile. * Tests that verify the correct working of the above are also excluded from the testset. Open tasks: 1. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Compile and test the user space RBD (Rados Block Device). This currently works, but testing has been limitted. 3. Investigate and see if an in-kernel RBD device could be developed akin to FreeBSD's ggate. 4. Investigate the keystore, which could be embedded in the kernel on Linux, and currently prevents building CephFS and some other components. The first question whether it is really required, or if only KRBD require it. 5. Scheduler information is not used at the moment, because the schedulers work rather differently between FreeBSD and Linux. But at a certain point in time, this would need some attention in src/common/Thread.cc. 6. Integrate the FreeBSD /etc/rc.d initscripts in the Ceph stack. This helps with testing, but also enables running Ceph on production machines. 7. Build a testcluster and start running some of the teuthology integration tests on it. 8. Design a virtual disk implementation that can be used with bhyve and attached to an RBD image. __________________________________________________________________ OpenBSM Links OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation URL: http://www.openbsm.org OpenBSM on GitHub URL: https://github.com/openbsm/openbsm FreeBSD Audit Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/audit.html OpenBSM 1.2 alpha 5 announcement URL: https://lists.FreeBSD.org/pipermail/trustedbsd-announce/2016-December/000008.html DARPA CADETS project URL: https://www.cl.cam.ac.uk/research/security/cadets/ Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD Audit Mailing Mist OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the user-space side of the CAPP Audit implementations in FreeBSD and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux. This quarter saw increased development activity, fueled by the DARPA CADETS project, resulting in the release of OpenBSM 1.2 alpha 5. Among this release's changes are the ability to specify the kernel's maximum audit queue length, sandboxing support for auditreduce(1) and praudit(1) on FreeBSD and other systems that support Capsicum, as well as the addition of event identifiers for more FreeBSD system calls. The complete list of changes is documented in the NEWS file on GitHub. The new release will be merged into FreeBSD HEAD and the supported STABLE branches shortly. This project was sponsored by DARPA/AFRL (in part). Open tasks: 1. Test the new release on different versions of FreeBSD, Mac OS X, and Linux. In particular, testing on the latest versions of Mac OS X would be greatly appreciated. 2. Fix problems that have been reported via GitHub and the FreeBSD bug tracker. 3. Implement the features mentioned in the TODO list on GitHub. __________________________________________________________________ Sysctl Exporter for Prometheus Links The Prometheus Project URL: https://prometheus.io/ Node Exporter URL: https://github.com/prometheus/node_exporter Sysctl Exporter URL: https://svnweb.FreeBSD.org/base/head/usr.sbin/prometheus_sysctl_exporter/ Contact: Ed Schouten Prometheus is an Open Source monitoring system that was originally built at SoundCloud in 2012. Since 2016, this project is part of the Cloud Native Computing Foundation, together with other projects like Kubernetes. Prometheus scrapes its targets by periodically sending HTTP GET requests. Targets then respond by sending key-value pairs of metrics and their sample value. Prometheus has a query language, PromQL, that can be used to aggregate sample values and specify alerting conditions. Tools like Grafana can be used to create fancy dashboards using such queries. The Prometheus project provides a utility called node_exporter that gathers basic system metrics and serves them over HTTP. This utility tends to be rather complex, as it has to extract metrics from many different sources. On Linux, files in /proc have no uniform format, meaning that for every kernel framework a custom collector needs to be written. On FreeBSD the sitiuation is better, as the data exported through sysctl is already structured in such a way that it can easily be translated to Prometheus' metrics format. The goal of this project is thus to provide a generic exporter for the entire sysctl tree. Not only does this prevent unnecessary bloat and indirection, it may also make the life of a kernel developer a lot easier. One can easily use Prometheus to graph the occurrence of an event over time by (temporarily) adding a counter to the kernel. An initial version of the sysctl exporter has been integrated into the FreeBSD base system in December. It can be run through inetd by uncommenting the example provided in inetd.conf. Unfortunately, this exporter cannot be merged back to FreeBSD 10.x/11.x, as it depends on KBI-breaking changes to sysctl(9). Open tasks: 1. Are you using Prometheus or are you interested in using it? Be sure to give both Prometheus and this sysctl exporter a try! 2. It would be nice if we created a set of useful alerting rules and placed those in /usr/share/examples. For example, how can one use this exporter to monitor the state of GEOM-based RAID arrays? Is such information even exported through sysctl? 3. Prometheus uses a rather clever format for exporting histograms. Histograms are useful for expressing the amount of time taken to complete certain events (for example, disk operations). Would it be possible to add histograms as native data types to sysctl? If so, is there any chance they can be implemented without picking up any kernel locks? __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics Stack Roadmap and Supported Hardware Matrix URL: https://wiki.FreeBSD.org/Graphics GitHub Repository URL: https://github.com/FreeBSDDesktop/freebsd-base-graphics Ports Development Repository URL: https://github.com/FreeBSD/freebsd-ports-graphics Fork of libudevd-devd Shim URL: https://github.com/FreeBSDDesktop/libudev-devd Graphics Team Blog URL: https://planet.FreeBSD.org/graphics Contact: FreeBSD Graphics Team Contact: Matthew Macy Good progress on graphics support was made during the weeks around Christmas and the new year with the import of Linux 4.9's DRM for i915 and amdgpu into the drm-next branch of the github repository. The amdgpu KMS driver is already somewhat usable, with a few major known issues remaining. It now supports GPUs as far back as Southern Islands and up to Polaris. The 4.9 update also appears to have fixed a regression in i915 that was introduced by the 4.8 merge late this past summer. The drm-next branch now supports the Intel integrated graphics unit up to Kaby Lake CPUs. To facilitate out-of-the-box support on CURRENT, most of the branch-local VM changes were reverted and the graphics fault routines converted to use pg_populate. This new interface is the source of a couple of regressions causing panics on i915 and severe artifacts with amdgpu on integrated GPUs. Mark Johnston (markj@) has volunteered to analyze these issues. Please show your support and encouragement to Mark for helping to move this project towards the finish line. The xserver-mesa-next-udev branch was created for the ports development repository, and holds Mesa 13.0 and fixes for newer AMD GPUs. It uses a fork of the libudev-devd shim, also bringing Mesa closer to the Linux upstream. I plan to keep updating drm and amdgpu (for use on my desktop and potentially longer term for GPGPU computations) as well as work with Mark to address the existing bugs in i915 (assuming that two new porters are approved). However, the Linux i915 developers seem to aggressively explore the space of possible implementations and use of Linux internal APIs, making it prohibitively time consuming to track upstream. I am helping someone to learn the ropes of how to replay a subset of changes from a Linux release into FreeBSD in the hope that he will take over the mantle of drm-next i915 maintainer. Assuming the issues listed above are addressed, a port of the linuxkpi, DRM, and KMS drivers for use on standard amd64 CURRENT installations is planned. Together with upgrades to the relevant graphics ports, this will provide experimental support for new AMD and Intel GPUs. __________________________________________________________________ Kernel FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD Virtual Machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang This project provides native virtualized interfaces for FreeBSD systems running on Hyper-V virtualization, improving on the performance of traditional emulated evices. Per-ring polling, multi-packet RNDIS messages, and system RSS integration have been implemented, further optimizing the throughput and latency of the Hyper-V network driver. Live virtual machine backup is implemented (for now, only for UFS), after the VSS (Volume Shadow Copy Service), which it depends on, was implemented. PCIe pass-through is implemented, and the patches to implement NIC SR-IOV are being reviewed on Phabricator. vDSO support for speeding up gettimeofday(2) is now implemented. The FreeBSD 11.0 image on Azure (https://azure.microsoft.com/en-us/marketplace/partners/microsoft/FreeBSD110/) is now available, in addition to the existing 10.3 image. We fixed an issue where SCSI disks would sometimes fail to attach, resolving bug 215171 ([Hyper-V] Fail to attach SCSI disk from LUN 8 on Win2008R2/Win2012/Win2012R2). This project was sponsored by Microsoft. __________________________________________________________________ I2C, GPIO, and SPI Support for MinnowBoard Links Blog Post URL: https://kernelnomicon.org/?p=767 MinnowBoard Website URL: https://www.minnowboard.org Contact: Oleksandr Tymoshenko The MinnowBoard is an Atom-based x86 board (Intel E38xx Series SoC) in a maker-friendly form-factor: it provides convenient access to pins that can be used to connect peripherals using one of the standard buses: GPIO, SPI, or I2C. These buses are more common in the ARM/MIPS world than in x86, so while FreeBSD was able to boot just fine, it lacked support for these buses on the MinnowBoard. As of r310645, HEAD support all three buses via the ig4(4), bytgpio(4), and intelspi drivers. The ig4(4) and bytgpio(4) changes were backported to 11-STABLE; intelspi will be MFCed in couple of weeks. __________________________________________________________________ Architectures FreeBSD on ARM Boards Links FreeBSD on Allwinner (Sunxi) Systems URL: https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner FreeBSD Commit Adding Support for IR Interfaces URL: https://svnweb.FreeBSD.org/base?view=revision&revision=307984 Contact: Ganbold Tsagaankhuu The changes necessary to support the Allwinner Consumer IR interface in FreeBSD have been committed. The receive (RX) side is supported now and the driver is using the evdev framework. It was tested on the Cubieboard2 (A20 SoC) using lirc with dfrobot's simple IR remote controller. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 Wiki Page URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Contact: Oleksandr Tymoshenko Support for accessing floating-point registers from the kernel has been added. This uses the same KPI as i386 and amd64. This will allow for handling places where the floating-point state may be modified, for example when calling into UEFI. Support for the optional ARMv8 AES instructions was added to the kernel. This makes use of the ability to store and restore the floating point state. Tests have shown a significant improvement in AES performance on ThunderX hardware. The Cortex Strings memcpy and memmove functions have been imported into the kernel. These are optimised implementations of these common functions. FreeBSD now boots on the SoftIron Overdrive 3000 using ACPI. The needed changes for this have been submitted to phabricator for review. This includes booting with SMP enabled, and all currently supported devices. Support for the Raspberry Pi 3 has been committed. Most devices work, with the exception of WiFi and Bluetooth, as these are attached via an as-yet unsupported SDIO bus. This project was sponsored by The FreeBSD Foundation, and ABT Systems Ltd. __________________________________________________________________ FreeBSD/EC2 Contact: Colin Percival This report covers work since the last FreeBSD/EC2 status report (2015Q1). FreeBSD/EC2 is now part of the regular FreeBSD release build, with snapshots and releases being automatically uploaded and copied to all available regions. Due to legal restrictions, this does not currently include the GovCloud or China (Beijing) regions; anyone wishing to use FreeBSD in those regions is encouraged to contact the author. The AWS Marketplace reports that approximately 800 users are running roughly 2000 FreeBSD EC2 instances. This does not count the likely significantly larger number of EC2 instances launched directly through the EC2 API and Console, but at least places a lower bound on usage. FreeBSD 11.0-RELEASE shipped with support for the "enhanced networking" capabilities of EC2 C3, C4, R3, I2, D2, and M4 (excluding m4.16xlarge) instances. This provides significantly higher network performance than the virtual networking available on older EC2 instances and with older versions of FreeBSD. FreeBSD 11.0-RELEASE and later also use indirect segment disk I/Os, which yield approximately 20% higher throughput with equal or lower latency, and support the 128-vCPU x1.32xlarge instance type. FreeBSD now supports the Amazon Simple Systems Manager service ("run command"). Open tasks: 1. Complete a pending reorganization of the accounts used for FreeBSD/EC2 releases. 2. Support "second generation enhanced networking" via the new Elastic Network Adapter found in P2, R4, X1, and m4.16xlarge instances. 3. Provide tools for improved functionality via the Simple Systems Manager service: listing installed packages, checking for updates, adding/removing users, [your favourite sysadmin task goes here]. 4. Add support for EC2's IPv6 networking to the default FreeBSD/EC2 configuration. 5. Continue ongoing interoperability testing between FreeBSD's NFS client and the Amazon Elastic File System (NFS-as-a-service). __________________________________________________________________ Userland Programs libarchive Links Official Libarchive Homepage URL: http://www.libarchive.org Libarchive on GitHub URL: https://github.com/libarchive/libarchive Contact: Tim Kientzle Contact: Martin Matuska Libarchive is a BSD-licensed archive and compression library originally developed as part of FreeBSD. It supports a wide variety of input and output formats and also includes three command-line tools: bsdcat, bsdcpio and bsdtar. The FreeBSD tar and cpio utilities are taken directly from Libarchive, and many other important utilities like ar, unzip, and the pkg package manager make use of libarchive's functions. Libarchive development in 2016 has been focusing on bug fixes and code cleanup, including fixing several critical security issues. Automated testing with Travis CI and Jenkins has been introduced and libarchive has been added to the Google OSS-Fuzz project. Fuzzing helped detect several hidden problems like buffer overflows and memory leaks. Over the last few months, NFSv4 ACL support for the pax and restricted pax (the default for bsdtar) formats has been completed and merged to FreeBSD-CURRENT. NFSv4 ACL entries can now be stored to and restored from tar archives. Open tasks: 1. More extensive CI testing with FreeBSD on different platforms and releases. Currently only 11.0-RELEASE-amd64 gets tested via an automated Jenkins job. 2. As every commit to libarchive may influence the build process of FreeBSD ports, the ability to trigger a (semi-)automated exp-run for the ports tree would be great. __________________________________________________________________ Reproducible Builds in FreeBSD Links Base System Reproducible Builds Wiki Page URL: https://wiki.FreeBSD.org/ReproducibleBuilds Ports Reproducible Builds Wiki Page URL: https://wiki.FreeBSD.org/PortsReproducibleBuilds Reproducible Builds Website URL: https://reproducible-builds.org/ Contact: Baptiste Daroussin Contact: Ed Maste Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers. A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-for-bit identical copies of all specified artifacts. Baptiste Daroussin and Ed Maste attended the second Reproducible Builds Summit last December, in Berin. We discussed issues of common interest to operating system providers, including other BSDs and Linux distributions. Following the summit, changes were committed to the FreeBSD base system to address outstanding sources of non-reproducibility. It is now possible to build the FreeBSD base system (kernel and userland) completely reproducibly, although it currently requires a few non-default settings. Approximately 80% of the ports tree builds reproducibly, with a few work-in-progress patches. Now that the base system can be built reproducibly, focus will move on to the ports tree. This project was sponsored by The FreeBSD Foundation, and The Linux Foundation. Open tasks: 1. Integrate FreeBSD ports builds into the reprodcible-builds.org continuous integration infrastructure. 2. Integrate reproducible build patches into the ports tree. 3. Investigate sources of non-reproducibility in individual ports. __________________________________________________________________ Updates to GDB Contact: John Baldwin Contact: Luca Pizzamiglio The devel/gdb port has been updated to GDB 7.12. 7.12 includes additional fixes related to tracing vfork()s. Some of these fixes depend on changes to ptrace() in the kernel to report a new ptrace stop when the parent of a vfork() resumes. Support for FreeBSD/mips userland binaries has been committed upstream. These patches, along with support for debugging FreeBSD/mips kernels, should be added to the port soon. Open tasks: 1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 2. Add support for more platforms (arm, aarch64) to upstream gdb for both userland and kgdb. 3. Add support for debugging powerpc vector registers. 4. Add support for $_siginfo. 5. Implement 'info proc' commands. 6. Implement 'info os' commands. 7. Debug gdb hangs related to the 'kill' command. __________________________________________________________________ Using LLVM's LLD Linker as FreeBSD's System Linker Links FreeBSD LLD Wiki Page URL: https://wiki.FreeBSD.org/LLD FreeBSD/LLD Tracking PR (LLVM Bugzilla) URL: http://llvm.org/pr23214 Contact: Rafael Espíndola Contact: Ed Maste LLD is the linker in the LLVM family of projects. It is a high-performance linker that supports the ELF, COFF and Mach-O object formats. It aims to be compatible with the common linkers used for each file format. For ELF this is the GNU Binary File Descriptor (BFD) ld and GNU gold. However, LLD's authors are not constrained by strict compatibility where it would hamper performance or desired functionality. LLD developers made significant progress over the last quarter. With changes committed to both LLD and FreeBSD we reached a major milestone: it is now possible to link the entire FreeBSD/amd64 base system (kernel and userland) with LLD. Now that the base system links with LLD, we have started investigating linking applications in the ports tree with LLD. Through this process we are identifying limitations or bugs in both LLD and a number of FreeBSD ports. With a few work-in-progress patches we can link approximately 95% of the ports collection with LLD on amd64. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Fix libtool to detect LLD and pass the same command line arguments as for GNU ld and gold. 2. Investigate the remaining amd64 port build failures. 3. Investigate and improve LLD on arm64, i386, arm, and other non-amd64 architectures. 4. Extensive testing. __________________________________________________________________ Ports GCC (GNU Compiler Collection) Links GCC Home Page URL: https://gcc.gnu.org Contact: Gerald Pfeifer Contact: Andreas Tobler Contact: Antoine Brodin Long awaited, the update to GCC 4.9 as the default version of GCC in the Ports Collection (lang/gcc port, USE_GCC=yes in Makefiles) has arrived, an update from GCC 4.8. This brings quite a number of improvements; see https://gcc.gnu.org/gcc-4.9/changes.html for details. lang/gcc49 has moved to the GCC 4.9.4 release which marks the closure of the GCC 4.9 branch and release series. (Yes, this means we should rather get the next version upgrade for lang/gcc in place soon. That update per se is straightforward, but any help in addressing the fallout of broken ports would be great -- please let us know if you want to help!) lang/gcc6 has been updated first to GCC 6.2 and then GCC 6.3, bringing a fair number of fixes, and should now be suitable for production use. Open tasks: 1. Update lang/gcc (and hence USE_GCC=yes) to GCC 5. 2. Support for AArch64. __________________________________________________________________ LXQt on FreeBSD Links LXQt Project URL: http://lxqt.org/ FreeBSD LXQt Project URL: https://wiki.FreeBSD.org/LXQt LXQt Development Repository URL: https://www.assembla.com/spaces/lxqt/subversion/source Contact: Olivier Duchateau Contact: Jesper Schmitz Mouridsen LXQt is the Qt port of and the upcoming version of LXDE, the Lightweight Desktop Environment. It is the product of a merge between the LXDE-Qt and Razor-qt projects. The porting effort remains very much a work in progress: LXQt requires some components of Plasma 5, the new major KDE workspace. We imported some core components (it was necessary to update to x11/qterminal 0.7.0): * devel/lxqt-build-tools * devel/liblxqt * devel/qtxdg * x11/libfm-qt Standalone applications: * graphics/lximage-qt * x11-fm/pcmanfm-qt We also have updates for: * x11/qterminal 0.7.1 * x11-toolkits/qtermwidget 0.7.1 * Updating the Porter's Handbook for LXQt support (https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=215650) Open tasks: 1. Improve support in sysutils/lxqt-admin (especially date and time settings). __________________________________________________________________ Mono Links Mono Homepage URL: http://www.mono-project.com/ .NET Core Homepage URL: https://github.com/dotnet/core Mono Project Page URL: https://wiki.FreeBSD.org/Mono Contact: Mono on FreeBSD team During the last quarter, many ports within the mono project have been updated: * Mono: 4.6.2.7 * MonoDevelop: 6.1.1.15, 6.1.2.44 * FSharp: 4.0.1.20 USES=mono has been extended to allow for easier use of Nuget packages. This extension has been used adopted by FSharp, MonoDevelop and OpenRA. Work has started on porting Microsoft's open-sourced .NET Core. Thanks to the work of another team, the native components of coreclr and corefx already support FreeBSD, however, there is further work required in bootstrapping the build process and compiling the managed code. Open tasks: 1. Port .NET Core. 2. Test patches for Mono. __________________________________________________________________ Wine Links Wine Homepage URL: https://www.winehq.org/ Project Page URL: https://wiki.freebsd.org/Wine Contact: Gerald Pfeifer Contact: David Naylor The stable version of Wine (aka emulators/wine) has seen three maintenance releases in the last half year, and Xinerama support (in case you have more than one screen) and GNUTLS (helpful for Evernote or World of Warcraft, for example) are now active by default. The development version (aka emulators/wine-devel) has seen steady progress and reached the RC phase of Wine 2.0. We are looking forward to a new major release soon that combines the progress of a year of active development with the stability of a release. Open tasks: 1. Port WoW64 __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce FreeBSD Xfce Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * audio/xfce4-mpc-plugin 0.5.0 (committed in devel repository) * deskutils/xfce4-notifyd 0.3.4 * graphics/ristretto 0.8.1 * sysutils/xfce4-diskperf-plugin 2.6.0 * sysutils/xfce4-battery-plugin 1.1.0 (committed in devel repository) * sysutils/xfce4-fsguard-plugin 1.1.0 (committed in devel repository) * sysutils/xfce4-netload-plugin 1.3.0 (committed in devel repository) * sysutils/xfce4-systemload-plugin 1.2.0 (committed in devel repository) * sysutils/xfce4-wavelan-plugin 0.6.0 (committed in devel repository) * x11/xfce4-clipman-plugin 1.4.1 * x11/xfce4-conf 4.12.1 * x11/xfce4-dashboard 0.6.1 * x11/xfce4-terminal 0.8.2 * x11/xfce4-whiskermenu-plugin 1.6.2 * x11-clocks/xfce4-datetime-plugin 0.7.0 (committed in devel repository) * x11-wm/xfce4-panel 4.12.1 * www/xfce4-smartbookmark-plugin 0.5.0 (committed in devel repository) We also follow the unstable releases (available in our experimental repository) of: * sysutils/xfce4-settings 4.13.0 (it requires Gtk+ > 3.20) * x11/libexo 0.11.2 * x11/xfce4-whiskermenu-plugin 2.0.3 Open tasks: 1. Apply the changes discussed in D8416 (simplify the MASTER_SITES macro in port Makefiles). 2. Commit the stable panel plugins. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJYooROAAoJECjZpvNk63USnIwMIO4lgSyECoViv1/WVXQdWkNr cQ70ARRSDDc1q3mN6Y0FTsxyvllR/u1BOdcJz5M/oWnbh87TISp3ocL2t4Ehm2ti gY4o4sLNtQlRV+45klHuxdDCrTbnOmUUuxKdIMPypDlHg3SI06Ki7oDptaP16EXM wc8zOwZZHeOCKQ1PDE1rll3BpDGCeB+BbdElIRdWY280gKeuN7/LuyTjYt171ohw Z3pGzomE7JTGulwyu86mo1M1C0R3ZhngrichpGkxD/x+uwsNJFyj2l39yFDnTtwu NZx1xmWjPgtprPFBtjIEViGPVHg58hzSVSDYpALR5dRsno/QpO57GArshq3sBuAn w8NmgmtZM82MdrrL7SwtRWbc9bIpyqJr3D25GQnJnhXJKacmPhnOlcSCtd9XGaqS VFRJ/4GODcxVXXN0h6euJEwgSheBFCd4lc8wHGWmTw6/qrQzJURVFErOCt3uayJf 7IHeQVqErAbBm/ZHEUdRlFvXKcduE9z8/TWcdJ/1TAoCMwY= =Vpv4 -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Tue Feb 14 08:00:43 2017 Return-Path: Delivered-To: freebsd-stable@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 44307CDEA1C for ; Tue, 14 Feb 2017 08:00:43 +0000 (UTC) (envelope-from k@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (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 9177D1E6F for ; Tue, 14 Feb 2017 08:00:42 +0000 (UTC) (envelope-from k@free.de) Received: (qmail 46708 invoked from network); 14 Feb 2017 08:53:58 +0100 Received: from smtp.free.de (HELO [91.204.5.154]) (k@free.de@[91.204.6.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 14 Feb 2017 08:53:58 +0100 Subject: Re: FreeBSD Quarterly Status Report - Fourth Quarter 2016 To: freebsd-stable@freebsd.org References: <20170214042034.GA30306@kduck.kaduk.org> From: Kai Gallasch Organization: FREE! Message-ID: Date: Tue, 14 Feb 2017 08:53:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170214042034.GA30306@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Fk0TXvgs4ahaFGWPFUJgUBM00EV1IcP3G" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 08:00:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fk0TXvgs4ahaFGWPFUJgUBM00EV1IcP3G Content-Type: multipart/mixed; boundary="4c8Am3b3QNF47AVFBkQruamXGEccrG4Xh" From: Kai Gallasch To: freebsd-stable@freebsd.org Message-ID: Subject: Re: FreeBSD Quarterly Status Report - Fourth Quarter 2016 References: <20170214042034.GA30306@kduck.kaduk.org> In-Reply-To: <20170214042034.GA30306@kduck.kaduk.org> --4c8Am3b3QNF47AVFBkQruamXGEccrG4Xh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14.02.2017 05:20 Benjamin Kaduk wrote: > Core requested the removal of the misc/jive port, on the grounds that > it had no function other than to turn text into an offensively racis= t > parody. This proved controversial, with many seeing this as a first > step in bowdlerizing the entire ports tree. That is certainly not > Core's intention. Core's aim here is to help secure the future of th= e > FreeBSD project by making it welcoming to all contributors, regardle= ss > of ethnicity, gender, sexuality or other improper bases for > discrimintation. While misc/jive may once have been seen as harmless= > fun, today the implicit approval implied by having it in the ports t= ree > sends a message at odds with the project's aims. Am I dreaming? Has this "disease" finally reached my beloved FreeBSD after all this years? In my opinion it is just not Cores business making decisions besides the technical and organizational aspect. As long as any port has a handful of users and someone is willing to support it, its existence in the tree is justified. And basically I don't care if there is a port in the tree, where little harmless kittens are being shot at. Thank you Core! You made my day! K. --4c8Am3b3QNF47AVFBkQruamXGEccrG4Xh-- --Fk0TXvgs4ahaFGWPFUJgUBM00EV1IcP3G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYoreUAAoJEHBlTXxPsfWIz7AQAKWl13vu4kj6FtLv8ns9LuH0 orIf+76SqCnc2HotyWFbrOI1VfJKHJnu0gCbQOEparJxqIFYwO5bbt2Yt+UXnG1x pbbJE4Cg2WKm80vH5ozCPJA+xu20Z7T+GBzfMqCsZIhwHK4DzZjOJOR0ZxgZlcw3 uUx0r4QBau2niUpdUlt0Wdg3ARtgrlgza70WaCEAnZEt9LhT+ylt0g2wsGACwKG8 sfPG/zbldkkb2M+HT5MiIBPNx10omLfPTi+RmRf/Kq7O+T31vG0FjtQtvSu697Cg 9N3fshacdWBybbqnTsZ5YDBv/72Fk/2ttdXIhTjol2lOVQE/C3WGRJII3h4V+o6L wIr3p3kl7DCZt1/ryzdK9EjDJNT1PMRjvJGWyZmbJ1p0bsJLVFUITmTNBLigj6sv wbzAR1TqPUBm+T+S3pFRi3QDu4+Te72PJgSuQQe5EyRNWz5uBrJsNPnbALxnHkVO m/PagiYvGUrl0VljQDiEixcyff2P5aBW+gSqPSQc5NXwkERntHiQTozYi3l4KJVO 7h9/uvIuJnExa0XtLEEsCwbKT1VzxVaZIZoC11RECvvOeMlSMzTtqao75cQsetcz uOvQprSJ/mD74162AYIqZ2cCQ8DB2b146FyPMlZ9jJvHqFe+gNqXATL1ExXhK4Jp PyvsPvM3HQ9YJ8cP/qgJ =R80L -----END PGP SIGNATURE----- --Fk0TXvgs4ahaFGWPFUJgUBM00EV1IcP3G-- From owner-freebsd-stable@freebsd.org Tue Feb 14 14:55:53 2017 Return-Path: Delivered-To: freebsd-stable@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 5AE11CDF327 for ; Tue, 14 Feb 2017 14:55:53 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF61125A for ; Tue, 14 Feb 2017 14:55:53 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 6D6AA4AB; Tue, 14 Feb 2017 09:55:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FreeBSD Quarterly Status Report - Fourth Quarter 2016 From: Paul Mather In-Reply-To: Date: Tue, 14 Feb 2017 09:55:50 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20170214042034.GA30306@kduck.kaduk.org> To: Kai Gallasch X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:55:53 -0000 On Feb 14, 2017, at 2:53 AM, Kai Gallasch wrote: > On 14.02.2017 05:20 Benjamin Kaduk wrote: >> Core requested the removal of the misc/jive port, on the grounds that >> it had no function other than to turn text into an offensively racist >> parody. This proved controversial, with many seeing this as a first >> step in bowdlerizing the entire ports tree. That is certainly not >> Core's intention. Core's aim here is to help secure the future of the >> FreeBSD project by making it welcoming to all contributors, regardless >> of ethnicity, gender, sexuality or other improper bases for >> discrimintation. While misc/jive may once have been seen as harmless >> fun, today the implicit approval implied by having it in the ports tree >> sends a message at odds with the project's aims. > > > Am I dreaming? Has this "disease" finally reached my beloved FreeBSD > after all this years? > > In my opinion it is just not Cores business making decisions besides the > technical and organizational aspect. As long as any port has a handful > of users and someone is willing to support it, its existence in the tree > is justified. And basically I don't care if there is a port in the tree, > where little harmless kittens are being shot at. > > Thank you Core! > You made my day! If they lifted your day so much, you should send them a donation. :-) Cheers, Paul. PS: Thank you Core, IMHO you did the right thing. From owner-freebsd-stable@freebsd.org Tue Feb 14 15:00:46 2017 Return-Path: Delivered-To: freebsd-stable@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 E57DBCDF542 for ; Tue, 14 Feb 2017 15:00:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 B9EAD148A for ; Tue, 14 Feb 2017 15:00:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A4ED820B9E for ; Tue, 14 Feb 2017 10:00:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 14 Feb 2017 10:00:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=MZZFoyDVm6aOsHo hcSxddwABzYM=; b=vFu6yY9fPLHbwUYqWaz4ufg5nMA8R8LBia1765PByMMKp2/ 5l/DFaTUuj7pxsPzoSKFCzZrKGNkS26MfQ/jdcozEpurEbRo+awWRnLy0IRbzbAU tw4+X4ysNpV7tjb72KWXdDQ9kGrLSSq25ZCW/XFgTAddhZDNAgdu2ZpHSBT0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=MZZFoyDVm6aOsHohcSxddwABzYM=; b=SJgi0RCZgeGTQcDx4Awv EQibgyiwd0zlyfpRNpzOoqNOgVVINuBgcmu15WA2N/MoSbMb4bH87UD6LLbWzmC2 oiy3q/VH+p0r7oeDdLfo0LSWLdI+Hq2XSYsgFVtcCkjmco+WJNMB9LDTgslQzMu+ LCZIBQtBUdWuKEjKOifJIjA= X-ME-Sender: X-Sasl-enc: V9KsnPs8LZhhkgOCqdYBVWw3efm5DzMbkxShZ8Xt+0y3 1487084445 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E7307E354 for ; Tue, 14 Feb 2017 10:00:45 -0500 (EST) Subject: Re: how can I make freebsd wait for usb to become active? Or delay mountroot? To: freebsd-stable@freebsd.org References: <4d398907-f6ed-e212-824e-f6f8e5aa6b88@zyxst.net> <7DD96F71-7A21-4125-BB6B-53458A400FDC@gromit.dlib.vt.edu> From: tech-lists Message-ID: <1c5ef2e9-9943-a970-7a75-d65fcc27f3ea@zyxst.net> Date: Tue, 14 Feb 2017 15:00:42 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7DD96F71-7A21-4125-BB6B-53458A400FDC@gromit.dlib.vt.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 15:00:47 -0000 On 13/02/2017 19:10, Paul Mather wrote: > > This topic cropped up on the freebsd-arm mailing list very recently. > One solution is to add this to /boot/loader.conf: > > kern.cam.boot_delay="10000" > > That instructs the system to wait 10 seconds (10000 milliseconds) > during boot to give time for the CAM subsystem probes to complete. > (USB storage devices use the CAM subsystem.) >> vfs.root_mount_always_wait=1 loader tunable. The knob should be >> merged to 11 in two weeks. I'll try that second suggestion as I'm already past r313350 thanks for the advice -- J. From owner-freebsd-stable@freebsd.org Tue Feb 14 18:32:40 2017 Return-Path: Delivered-To: freebsd-stable@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 17C1ECDECC7 for ; Tue, 14 Feb 2017 18:32:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 05A821D63 for ; Tue, 14 Feb 2017 18:32:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 050DBCDECC5; Tue, 14 Feb 2017 18:32:40 +0000 (UTC) Delivered-To: stable@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 049BDCDECC4; Tue, 14 Feb 2017 18:32:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBBD31D60; Tue, 14 Feb 2017 18:32:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v1EIWWlo065990 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2017 10:32:33 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v1EIWWTQ065989; Tue, 14 Feb 2017 10:32:32 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Feb 2017 10:32:32 -0800 From: Gleb Smirnoff To: current@FreeBSD.org, stable@FreeBSD.org Subject: removing SVR4 binary compatibilty layer Message-ID: <20170214183232.GB58829@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:32:40 -0000 Hello! After some discussion on svn mailing list [1], there is intention to remove SVR4 binary compatibilty layer from FreeBSD head, meaning that FreeBSD 12.0-RELEASE, available in couple of years would be shipped without it. There is no intention of merge of the removal. The stable@ mailing list added for wider audience. P.S. I account any objector as taker of maintainership :) [1] https://lists.freebsd.org/pipermail/svn-src-head/2017-February/096502.html -- Totus tuus, Glebius. From owner-freebsd-stable@freebsd.org Wed Feb 15 07:26:30 2017 Return-Path: Delivered-To: freebsd-stable@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 EDA00CDF6FA for ; Wed, 15 Feb 2017 07:26:30 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D04B5198A for ; Wed, 15 Feb 2017 07:26:30 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id CAA59CDF6F8; Wed, 15 Feb 2017 07:26:30 +0000 (UTC) Delivered-To: stable@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 C9DE4CDF6F5; Wed, 15 Feb 2017 07:26:30 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 88D351988; Wed, 15 Feb 2017 07:26:30 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id s186so144565282qkb.1; Tue, 14 Feb 2017 23:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8gFnkueOjVAgHbWYdPfvRMBb7hT6bOsH6DqG7eHo3JQ=; b=QJnaLVh7w3xsGsRrv6YOKLE4qETs3FTe5UxXaeIyni39yseFOEjcnysSEMdy1IkWoC ySoP0D4LmILvwjiVYmYIzyaIvqUvOsNRk1Noay23cvmmT3LSTrad+txW8ZbQy/CF0Nua K2bOAJaZ6kL90x1pwuA2JqhWRnZjy84Fsuj9WtpcRqOWnRzFvi/7v3l/5VJjjoMvYuaQ voEKmfipvvp68vdhG4/K5hC02NMPERg/NosvHzLqgdM14MyinF4AhtBgmPH0EVazfR1j eKg6IYbUty3G6DnUHYzibY67wuwNcI+hEUyVor939wCeQOyXg8mb6jhYuWWE1xYsHh3O y7Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8gFnkueOjVAgHbWYdPfvRMBb7hT6bOsH6DqG7eHo3JQ=; b=HUl/DdNgcQidwKDF5lfwJYELQwyh9gljSWQYGg5lMEPVc6LIg8MxvwDmNAuzsG1nVt HFBhKmKxFNvn2jWbgv4tl0AN/vJXsaXZ4hfMAHbFhO+Qx3PyZd08hikcJPZcU5vKcNz/ yNkPLk6GdTL6mSEMClZ0By0kLsnaCplKO+cCbwSkn99HSEVLsdRieeHhlgKNMeGSpI80 keig1TPRG/IiJ3kngc/kdIDsFjlhVmszfa2jXwmhsI45JSTCF0Gbu+MJ2VIXIVJDMgvs J07dzjMznQ8BF3qbqNx2ChrgBeGf2jaT3s4duiaSuP31oRZkt5GiagMaKrRSW6d6ciwP 2DqQ== X-Gm-Message-State: AMke39mvALcIstvzdqkYQqR7/ApPoLgSyykw3Yoa4l0ngVCAUHsMG1UcHjc/vKbbOAtu1ALYeDdmyzrYRoy78A== X-Received: by 10.55.130.132 with SMTP id e126mr30592016qkd.16.1487143589695; Tue, 14 Feb 2017 23:26:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.176 with HTTP; Tue, 14 Feb 2017 23:26:29 -0800 (PST) In-Reply-To: <20170214183232.GB58829@FreeBSD.org> References: <20170214183232.GB58829@FreeBSD.org> From: mokhi Date: Wed, 15 Feb 2017 10:56:29 +0330 Message-ID: Subject: Re: removing SVR4 binary compatibilty layer To: Gleb Smirnoff Cc: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 07:26:31 -0000 Hi, Is this removing is because no-interest on maintaining it? If it helps, I am working to use the `kern_* instead sys_*` as mentioned patch in that discussion suggests for svr4, if this helps. -- Best wishes, MMokhi. From owner-freebsd-stable@freebsd.org Wed Feb 15 07:53:18 2017 Return-Path: Delivered-To: freebsd-stable@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 92D4DCDFF6C; Wed, 15 Feb 2017 07:53:18 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv71.fwdcdn.com (frv71.fwdcdn.com [212.42.77.71]) by mx1.freebsd.org (Postfix) with ESMTP id 46DA7AE8; Wed, 15 Feb 2017 07:53:17 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from [10.10.17.73] (helo=frv158.fwdcdn.com) by frv71.fwdcdn.com QID:1cdu8Y-000Dc5-WB/RC:2; Wed, 15 Feb 2017 09:36:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6fP8EhkC51TDHAsRTImUQYcJni27ALYuzyTNvwcyXn8=; b=BSDRYbp7QtteA3aU38J+cDk7lg IA24yMlvJZbXYlPi9k7rDTfe21G4oUjSF27EIiVeADzDVwJ+T/rkWKrW+ipZQJ6kqTClX0XijqIQR /SmtgeNtwQ5+bWJJKdel1sITXu5y8QIYMEI37zjpuxkb6CgoRsf1fCUpZczPiHBVJXUU=; Received: from [46.119.57.93] (helo=nonamehost) by frv158.fwdcdn.com with esmtpsa ID 1cdu8I-000PNX-Q6 ; Wed, 15 Feb 2017 09:36:10 +0200 Date: Wed, 15 Feb 2017 09:36:09 +0200 From: Ivan Klymenko To: hiren panchasara Cc: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org, "Andrey V. Elsukov" Subject: Re: [SOLVED] [#2] panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE Message-ID: <20170215093609.78a77ead@nonamehost> In-Reply-To: <20170127003310.15c5a828@nonamehost> References: <20161021220413.1d130f5c@nonamehost> <20161228095808.64d617de@nonamehost> <20161228174142.GB17818@strugglingcoder.info> <20161228195333.120e844f@nonamehost> <20161228175729.GC17818@strugglingcoder.info> <20170127003310.15c5a828@nonamehost> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=46.119.57.93; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 07:53:18 -0000 On Fri, 27 Jan 2017 00:33:10 +0200 Ivan Klymenko wrote: > On Wed, 28 Dec 2016 09:57:29 -0800 > hiren panchasara wrote: > > > On 12/28/16 at 07:53P, Ivan Klymenko wrote: > > > On Wed, 28 Dec 2016 09:41:42 -0800 > > > hiren panchasara wrote: > > > > > > > Can you open a bug report at https://bugs.freebsd.org/bugzilla/ > > > > with necessary details? Looks like virtualbox is involved > > > > here? > > > > > > I can not, because that does not make sense. > > > PR are not considered for months and years. > > > It was the last hope for the mail lists. > > > Probably i must to change the operating system. > > > > Apologies for that. As you know people get busy in such opensource > > projects. > > > > The panic appears in tcp land so if you provide enough information, > > I'll try to look at it. Again, I cannot promise anything more than > > an honest attempt. > > > > Cheers, > > Hiren > > The reason most panics served as tuning Netisr: > net.isr.numthreads=4 > net.isr.maxthreads=4 > net.isr.bindthreads=1 > > Apparently, this subsystem at some moment had been broken. > > Best regards, The next problem of panic was associated with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 Feb 3 10:22:37 ns kernel: panic: sbsndptr: sockbuf 0xfffff802077c5bd8 and mbuf 0xfffff80019f26d00 clashing Feb 3 10:22:37 ns kernel: cpuid = 4 Feb 3 10:22:37 ns kernel: KDB: stack backtrace: Feb 3 10:22:37 ns kernel: #0 0xffffffff80b3ebb7 at kdb_backtrace+0x67 Feb 3 10:22:37 ns kernel: #1 0xffffffff80af39b6 at vpanic+0x186 Feb 3 10:22:37 ns kernel: #2 0xffffffff80af3823 at panic+0x43 Feb 3 10:22:37 ns kernel: #3 0xffffffff80b8e3da at sbsndptr+0xda Feb 3 10:22:37 ns kernel: #4 0xffffffff80d34119 at tcp_output+0x1129 Feb 3 10:22:37 ns kernel: #5 0xffffffff80d301ee at tcp_do_segment+0x288e Feb 3 10:22:37 ns kernel: #6 0xffffffff80d2d1f2 at tcp_input+0x14d2 Feb 3 10:22:37 ns kernel: #7 0xffffffff80c94372 at ip_input+0x192 Feb 3 10:22:37 ns kernel: #8 0xffffffff80c2a4fd at netisr_dispatch_src+0xad Feb 3 10:22:37 ns kernel: #9 0xffffffff80c124f9 at ether_demux+0x149 Feb 3 10:22:37 ns kernel: #10 0xffffffff82b6971c at vboxNetFltFreeBSDinput+0x27c Feb 3 10:22:37 ns kernel: #11 0xffffffff80b5204a at taskqueue_run_locked+0x14a Feb 3 10:22:37 ns kernel: #12 0xffffffff80b51e3f at taskqueue_run+0xbf Feb 3 10:22:37 ns kernel: #13 0xffffffff80aad33f at intr_event_execute_handlers+0x20f Feb 3 10:22:37 ns kernel: #14 0xffffffff80aad5a6 at ithread_loop+0xc6 Feb 3 10:22:37 ns kernel: #15 0xffffffff80aa9de5 at fork_exit+0x85 Feb 3 10:22:37 ns kernel: #16 0xffffffff8101022e at fork_trampoline+0xe Feb 3 10:22:37 ns kernel: Uptime: 21h36m52s Feb 3 10:22:37 ns kernel: Dumping 7804 out of 32688 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% I have added an option hw.igb.num_queues=1 to /boot/loader.conf and the server is running without panic over a few weeks is stable. Panic my servers have multiple causes. Best regards, From owner-freebsd-stable@freebsd.org Wed Feb 15 08:14:32 2017 Return-Path: Delivered-To: freebsd-stable@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 E0A9ECE07F3 for ; Wed, 15 Feb 2017 08:14:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CC0E2188D for ; Wed, 15 Feb 2017 08:14:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C64A3CE07F1; Wed, 15 Feb 2017 08:14:32 +0000 (UTC) Delivered-To: stable@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 C3F7ECE07EF; Wed, 15 Feb 2017 08:14:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A353F188B; Wed, 15 Feb 2017 08:14:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v1F8EVjW070735 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Feb 2017 00:14:31 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v1F8EVEB070734; Wed, 15 Feb 2017 00:14:31 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Feb 2017 00:14:30 -0800 From: Gleb Smirnoff To: mokhi Cc: current@freebsd.org, stable@freebsd.org Subject: Re: removing SVR4 binary compatibilty layer Message-ID: <20170215081430.GC58829@FreeBSD.org> References: <20170214183232.GB58829@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 08:14:33 -0000 On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote: m> Is this removing is because no-interest on maintaining it? m> m> If it helps, I am working to use the `kern_* instead sys_*` as m> mentioned patch in that discussion suggests for svr4, if this helps. Well, we all "maintain" it, meaning that we keep it compilable. However, I'm sure that no one checks the functionality. There are no regression tests, and seems to be no users. I recently found that if you run GENERIC and 'kldload svr4.ko', the socket layer compatibility will be broken, since SVR4 requires COMPAT_OLDSOCK. And that has been for decades, and no one notices that. I bet there are simply no users. Towing this piece of code into the future is just a waste of time. -- Totus tuus, Glebius. From owner-freebsd-stable@freebsd.org Wed Feb 15 08:26:38 2017 Return-Path: Delivered-To: freebsd-stable@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 99B00CE0B3D for ; Wed, 15 Feb 2017 08:26:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 87ED41FEB for ; Wed, 15 Feb 2017 08:26:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 821E5CE0B3B; Wed, 15 Feb 2017 08:26:38 +0000 (UTC) Delivered-To: stable@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 81682CE0B39; Wed, 15 Feb 2017 08:26:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDEC1FE8; Wed, 15 Feb 2017 08:26:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id A164F273B2; Wed, 15 Feb 2017 08:26:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v1F8QZgH076857; Wed, 15 Feb 2017 08:26:35 GMT (envelope-from phk@phk.freebsd.dk) To: Gleb Smirnoff cc: mokhi , current@freebsd.org, stable@freebsd.org Subject: Re: removing SVR4 binary compatibilty layer In-reply-to: <20170215081430.GC58829@FreeBSD.org> From: "Poul-Henning Kamp" References: <20170214183232.GB58829@FreeBSD.org> <20170215081430.GC58829@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76855.1487147195.1@critter.freebsd.dk> Date: Wed, 15 Feb 2017 08:26:35 +0000 Message-ID: <76856.1487147195@critter.freebsd.dk> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 08:26:38 -0000 -------- In message <20170215081430.GC58829@FreeBSD.org>, Gleb Smirnoff writes: >Well, we all "maintain" it, meaning that we keep it compilable. However, >I'm sure that no one checks the functionality. There are no regression >tests, and seems to be no users. And probably nobody ever bothered to check the code comprehensively for security risks... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-stable@freebsd.org Wed Feb 15 09:28:37 2017 Return-Path: Delivered-To: freebsd-stable@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 6B7A8CDEFA5 for ; Wed, 15 Feb 2017 09:28:37 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0107BC for ; Wed, 15 Feb 2017 09:28:37 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 48883CDEFA3; Wed, 15 Feb 2017 09:28:37 +0000 (UTC) Delivered-To: stable@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 47C98CDEF9E; Wed, 15 Feb 2017 09:28:37 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 04EC97BA; Wed, 15 Feb 2017 09:28:37 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id s186so146553633qkb.1; Wed, 15 Feb 2017 01:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7wz1nEDWP5lG9Oca2gK1+dEHsEcPAXv7RI9amFVcYK8=; b=F0OtLE8hqVnxAreYgHNeHceHEkXgDVnM5Z9Ia1w7i+2iLa0k8Q7EQzXxg3XgHEji3I 8ba5gYkWEzN1HrpWlJXgP8HcgIPpdqf3bzDlsuDhBxSw7ITchRRVwhX29g0MrfPeRdL6 YcMAjJsE/pjqDK/auTzVlR4SXUhAbcTFwx10g82gP37YGOqrXGzspF8fLpD52Z/NPqHb lKbAbrUFaWNOShF96jrjzv8QRbSpp/e8YrNJzaFBMe+TF7g0s2uAvgalfsz3i7zL8R7f 24DzC4Q60OsOguI0vsODxLVP89ZatY1PF8eKl7+MAcfa9+iDA9QxJb2N9GojjQYoyLB2 /upg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7wz1nEDWP5lG9Oca2gK1+dEHsEcPAXv7RI9amFVcYK8=; b=VoJKMk8sjztjiph6PL8Rf/eohDbm707Qp/Dkr6dE+j+oZa64zpUR+xN3qa/EYxPfne Sio63hRhp55JcPX7098vrckzRSondHa9u4uwdHwADgeLxOWko8TgmRsUc/mcy4h4NBIP JdyjgS6Yea2uDc3THE+4IA6eCC7pzFnxN4fbxUvZtYdTXkZnksv5i2pmS7Lw0g7UbsZS h2zfA1nwEv+BGyJCEBh35nuSHQi40ho9VNS9oKCClGKInz1Vbe540u6yjsAvMmeBfWyF 1VH1n4ec656twbq76jWR3/uR+8mkqVX7FUGkenGue4Ndouor6hED9sOl4QWDitkCkQch Wmgw== X-Gm-Message-State: AMke39kTapZYAhkKqVB1HC/3a+VQpRGUeeK51b8FbR+BqD19GmQ5KBKuX+KxMTfX8s/IdJvQQZmTHqIm+J43Xg== X-Received: by 10.55.7.2 with SMTP id 2mr36703610qkh.228.1487150916175; Wed, 15 Feb 2017 01:28:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.176 with HTTP; Wed, 15 Feb 2017 01:28:35 -0800 (PST) In-Reply-To: <76856.1487147195@critter.freebsd.dk> References: <20170214183232.GB58829@FreeBSD.org> <20170215081430.GC58829@FreeBSD.org> <76856.1487147195@critter.freebsd.dk> From: mokhi Date: Wed, 15 Feb 2017 12:58:35 +0330 Message-ID: Subject: Re: removing SVR4 binary compatibilty layer To: Poul-Henning Kamp Cc: Gleb Smirnoff , current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 09:28:37 -0000 Well, I'd like to offer help keeping it (because on a personal opinion, I'd like being compatible `:-D). But the reasons are pretty reasonable and convincing :-). I have no more objections against removing it when security risks involves. -- Best wishes, MMokhi. From owner-freebsd-stable@freebsd.org Wed Feb 15 14:57:02 2017 Return-Path: Delivered-To: freebsd-stable@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 D1EB0CDFB5F for ; Wed, 15 Feb 2017 14:57:02 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 7A5AB83C; Wed, 15 Feb 2017 14:57:02 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3vNj6s45Gxz1Jd; Wed, 15 Feb 2017 15:56:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1487170609; x=1489762610; bh=4vi NOMYxBoQaC5Bxn027ZAwkV23mAZz001REfzBydQk=; b=BaDZE04mHeFalTFSQdE DGnlTUvS8qO2N6sdyjDcshcBCHmoAvx29HweQcdYGLTAjJ/1EUt7h216UUE8IJok tlgDZL92kY2JQwPV0g1BGU/bfcTKGmuFErDFuMW6pEKrTjzXa1wddMQKNYsxmXjs 4jRcaOHcttGwWkhhG71CHM28= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id uctXztIR73S6; Wed, 15 Feb 2017 15:56:49 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3vNj6d0k84z1JY; Wed, 15 Feb 2017 15:56:41 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3vNj6c6zLHzvw; Wed, 15 Feb 2017 15:56:40 +0100 (CET) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Wed, 15 Feb 2017 15:56:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Feb 2017 15:56:40 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Cc: Eric van Gyzen Subject: Re: net.inet.udp.log_in_vain strange syslog reports Organization: Jozef Stefan Institute In-Reply-To: <7dca33f9-e817-7d79-bddd-332e745a1c05@FreeBSD.org> References: <76681a24b7935674585b5ac585f4575c@ijs.si> <667fa3e1dd8e7cebbf4566467a7987bf@ijs.si> <7dca33f9-e817-7d79-bddd-332e745a1c05@FreeBSD.org> Message-ID: <318110819f687c06e6d412955bbac6b1@ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 14:57:02 -0000 2017-02-06 18:04, Eric van Gyzen wrote: > On 02/06/2017 10:19, Mark Martinec wrote: >> Hope the fix finds its way into 11.1 (or better yet, as a patch level >> in 10.0). Should I open a bug report? > > It will quite likely get into 11.1. As for a 10.x patch, you would > have > to ask re@ (I think), but I doubt it. These messages are really just > informative and can't be used for any filtering, since the source > address could be spoofed. I meant to say 11.0-p*, but nevermind. In a similar vein, I noticed also the following in our logs, with net.inet.tcp.log_in_vain=1. Looks like messages got concatenated somehow: Jan 25 01:37:53 mildred kernel: TCP: [2607:ff10:c5:509a::10]:26459 to [2001:1470:ff80::80:16]:4911 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:14898 to [2001:1470:ff80::80:16]:5222 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 25 23:55:09 mildred kernel: TCP: [2607:ff10:c5:509a::10]:58022 to [2001:1470:ff80::80:16]:9981 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:34680 to [2001:1470:ff80::80:16]:10243 tcpflags 0x2; tcp_input: Connection attempt to closedport Jan 25 23:55:09 mildred kernel: TCP: [2607:ff10:c5:509a::10]:30991 to [2001:1470:ff80::80:16]:8554 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:20012 to [2001:1470:ff80::80:16]:8443 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 25 23:55:09 mildred kernel: TCP: [2607:ff10:c5:509a::10]:14166 to [2001:1470:ff80::80:16]:6666 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:34680 to [2001:1470:ff80::80:16]:8010 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 25 23:55:09 mildred kernel: TCP: [2607:ff10:c5:509a::10]:47957 to [2001:1470:ff80::80:16]:3460 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:34680 to [2001:1470:ff80::80:16]:13579 tcpflags 0x2; tcp_input: Connection attempt to closedport Jan 25 23:55:09 mildred kernel: TCP: [2607:ff10:c5:509a::10]:20012 to [2001:1470:ff80::80:16]:9001 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:30651 to [2001:1470:ff80::80:16]:9000 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 12 04:50:58 mildred kernel: TCP: [2607:ff10:c5:509a::1]:42266 to [2001:1470:ff80::80:16]:49153 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::1]:35372 to [2001:1470:ff80::80:16]:62078 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 18 03:01:59 mildred kernel: TCP: [2607:ff10:c5:509a::10]:58022 to [2001:1470:ff80::80:16]:9200 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:46640 to [2001:1470:ff80::80:16]:8181 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 18 03:01:59 mildred kernel: TCP: [2607:ff10:c5:509a::10]:36877 to [2001:1470:ff80::80:16]:7218 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:46640 to [2001:1470:ff80::80:16]:7071 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 18 03:01:59 mildred kernel: TCP: [2607:ff10:c5:509a::10]:30651 to [2001:1470:ff80::80:16]:9000 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:36877 to [2001:1470:ff80::80:16]:2332 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 18 03:01:59 mildred kernel: TCP: [2607:ff10:c5:509a::10]:46640 to [2001:1470:ff80::80:16]:7548 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:46640 to [2001:1470:ff80::80:16]:5986 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 19 02:52:34 mildred kernel: TCP: [2607:ff10:c5:509a::1]:42266 to [2001:1470:ff80::80:16]:49153 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::1]:35372 to [2001:1470:ff80::80:16]:62078 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 19 02:52:34 mildred kernel: TCP: [2607:ff10:c5:509a::1]:61788 to [2001:1470:ff80::80:16]:20000 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::1]:34680 to [2001:1470:ff80::80:16]:10243 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 19 02:52:34 mildred kernel: TCP: [2607:ff10:c5:509a::1]:41249 to [2001:1470:ff80::80:16]:44818 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::1]:49717 to [2001:1470:ff80::80:16]:8649 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 20 04:49:15 mildred kernel: TCP: [2607:ff10:c5:509a::1]:36877 to [2001:1470:ff80::143:1]:50100 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::1]:42266 to [2001:1470:ff80::143:1]:49153 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 20 10:03:52 mildred kernel: TCP: [2607:ff10:c5:509a::10]:31430 to [2001:1470:ff80::143:1]:8099 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:46640 to [2001:1470:ff80::143:1]:9943 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 20 10:03:52 mildred kernel: TCP: [2607:ff10:c5:509a::10]:9696 to [2001:1470:ff80::143:1]:16010 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:34680 to [2001:1470:ff80::143:1]:25105 tcpflags 0x2; tcp_input: Connection attempt to closedport Jan 20 10:03:52 mildred kernel: TCP: [2607:ff10:c5:509a::10]:34680 to [2001:1470:ff80::143:1]:4040 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:23668 to [2001:1470:ff80::143:1]:5577 tcpflags 0x2; tcp_input: Connection attempt to closed port Jan 20 10:03:52 mildred kernel: TCP: [2607:ff10:c5:509a::10]:1940 to [2001:1470:ff80::143:1]:49152 tcpflags 0x2; tcp_input: Connection attempt to closed TCP: [2607:ff10:c5:509a::10]:6440 to [2001:1470:ff80::143:1]:5672 tcpflags 0x2; tcp_input: Connection attempt to closed pport Mark From owner-freebsd-stable@freebsd.org Wed Feb 15 15:18:01 2017 Return-Path: Delivered-To: freebsd-stable@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 BE8A4CE03C9 for ; Wed, 15 Feb 2017 15:18:01 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id A906B1EBF for ; Wed, 15 Feb 2017 15:18:01 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E4067564DF; Wed, 15 Feb 2017 09:18:00 -0600 (CST) Subject: Re: net.inet.udp.log_in_vain strange syslog reports To: Mark Martinec , freebsd-stable@freebsd.org References: <76681a24b7935674585b5ac585f4575c@ijs.si> <667fa3e1dd8e7cebbf4566467a7987bf@ijs.si> <7dca33f9-e817-7d79-bddd-332e745a1c05@FreeBSD.org> <318110819f687c06e6d412955bbac6b1@ijs.si> From: Eric van Gyzen Message-ID: <57f7fe65-c854-c52d-ce33-3a2a919d0ce9@FreeBSD.org> Date: Wed, 15 Feb 2017 09:17:54 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <318110819f687c06e6d412955bbac6b1@ijs.si> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:18:01 -0000 On 02/15/2017 08:56, Mark Martinec wrote: > In a similar vein, I noticed also the following in our logs, > with net.inet.tcp.log_in_vain=1. > > Looks like messages got concatenated somehow: > > Jan 25 01:37:53 mildred kernel: TCP: [2607:ff10:c5:509a::10]:26459 to > [2001:1470:ff80::80:16]:4911 tcpflags 0x2; tcp_input: Connection attempt to > closed TCP: [2607:ff10:c5:509a::10]:14898 to [2001:1470:ff80::80:16]:5222 > tcpflags 0x2; tcp_input: Connection attempt to closed port The length of the truncated "TCP:...closed" message is just under 128, which is the PRINTF_BUFR_SIZE as defined in sys/amd64/conf/GENERIC. You could try increasing this value and rebuilding your kernel to see if that fixes the truncation. Don't increase it very much, since it's used to declare a buffer on the stack, and stack space is quite limited. For this case, 180 should be enough. Eric From owner-freebsd-stable@freebsd.org Wed Feb 15 18:46:45 2017 Return-Path: Delivered-To: freebsd-stable@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 AFAE9CE0FCB for ; Wed, 15 Feb 2017 18:46:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 96486267 for ; Wed, 15 Feb 2017 18:46:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8FC10CE0FC9; Wed, 15 Feb 2017 18:46:45 +0000 (UTC) Delivered-To: stable@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 8F256CE0FC7; Wed, 15 Feb 2017 18:46:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29F9D265; Wed, 15 Feb 2017 18:46:44 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v1FIkTeM044527 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Feb 2017 05:46:34 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v1FIkMs4059571 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 05:46:22 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v1FIkLAv059570; Thu, 16 Feb 2017 05:46:21 +1100 (AEDT) (envelope-from peter) Date: Thu, 16 Feb 2017 05:46:21 +1100 From: Peter Jeremy To: Gleb Smirnoff Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: Re: removing SVR4 binary compatibilty layer Message-ID: <20170215184621.GF84013@server.rulingia.com> References: <20170214183232.GB58829@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <20170214183232.GB58829@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:46:45 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Feb-14 10:32:32 -0800, Gleb Smirnoff wrote: > After some discussion on svn mailing list [1], there is intention >to remove SVR4 binary compatibilty layer from FreeBSD head, meaning >that FreeBSD 12.0-RELEASE, available in couple of years would >be shipped without it. There is no intention of merge of the removal. >The stable@ mailing list added for wider audience. Can I suggest that we put some warnings into the SVr4 image activation code and MFC that to at least 11 to try and smoke out anyone who might actually be using it. --=20 Peter Jeremy --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYpKH9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0rXgP/iOiWqZEY4Y3oiZYLfVltHma wBmmaz+qY/WGWABzctbaMGQYhLTDwP++21Hoy0h+mKCi6ODycWI6VRZbUQrCPISq F/4MwGF0wY7m4813E6mFj5axcpLTNrHGkE06GqDpMbQRpSoTwBaaM25Svn8uLkYa cKoppj8nLfFsnsCCu1kGyVewoocTby3SU6KAPO5UVwi0QYjro+FXOajjyCStDLOE PcQjNSONP6wvQyShNDIJt6ELE46Da5pfm3zHG59dUj/Vq+APZJyLieN0rck1Kx4n yc5RF1/ksuGBLhRsMJ81KtYVY5PUuLb4W3vhFumg72G7/RmSZhtd6+3OeiWSnkoa A/zTWxnX85u8z+jCcmOYFic0SNVJ5Qli8BIEv/p3E4QezAl9g9KvXp7vge/PawrJ HTMGxsmBFoBtQxO6xgY7IEVcsaLqApzLYrr7u4+rfN7V5pdjrdCKS0R0hURxbfqG LfVGrRKSlCMxJXGfAkm8B7mza4+j6EJivrbJNhEPcLar8RLgxvrrSOTdiEDS6ox/ bwDrTsCZqcvwePZYtcH8BfTh//M4SRLwcEF7HbCN64freJemcf6YCnJg2O/PnueI WdFqtfucMSTBXg1/JGkmRA/5qyYOAx9r/6Slyxl4psolac+p+J8QCtzm7OeFS5r/ hDRKEPN9v+3Q/LsIMmXx =bUvi -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-stable@freebsd.org Wed Feb 15 20:46:29 2017 Return-Path: Delivered-To: freebsd-stable@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 0BB83CE039B for ; Wed, 15 Feb 2017 20:46:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (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 9F059BCE for ; Wed, 15 Feb 2017 20:46:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30284 invoked from network); 15 Feb 2017 20:46:27 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2017 20:46:27 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Wed, 15 Feb 2017 15:46:27 -0500 (EST) Received: (qmail 20568 invoked from network); 15 Feb 2017 20:46:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Feb 2017 20:46:27 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5E071EC867B; Wed, 15 Feb 2017 12:46:26 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: removing SVR4 binary compatibilty layer Message-Id: Date: Wed, 15 Feb 2017 12:46:25 -0800 To: glebius@FreeBSD.org, FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:46:29 -0000 Gleb Smirnoff glebius at FreeBSD.org wrote on Tue Feb 14 18:32:40 UTC 2017 : > After some discussion on svn mailing list [1], there is intention > to remove SVR4 binary compatibilty layer from FreeBSD head, meaning > that FreeBSD 12.0-RELEASE, available in couple of years would > be shipped without it. There is no intention of merge of the removal. > The stable@ mailing list added for wider audience. Can we presume no invalidation of the TARGET_ARCH=powerpc ABI? It is SVR4 based as I remember (unlike TARGET_ARCH=powerpc64 ). === Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Wed Feb 15 21:02:32 2017 Return-Path: Delivered-To: freebsd-stable@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 7DB55CE089D for ; Wed, 15 Feb 2017 21:02:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 4AC60135E for ; Wed, 15 Feb 2017 21:02:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id c7so2310889itd.1 for ; Wed, 15 Feb 2017 13:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lBHe6/pz5fBNRXtZmjXFmQCTjeek//STCGQYzWHVJ5Q=; b=uAOSxottnmDBk9yUDEUYeQF5lWsZPfBVnAwVJitorg/xn9oYZBAjzwBQWqGHEWUTEx u5eSDv7Xat4UyOhnSmNVv9Zxjw7J4jW+yDmcoDdhPsB1/APNfGdDm7FYf+tL8RPD2hc/ bRkFUPcqX6R0TnU27xHtGd7L4XzaQEAXJr3MImeTLtpEUsRU+KdeexMCznj6COgXiHrT 91UnT5fGQUp18v55SFDaZPIEtBlV2KYbXhhekmzCwSSKBinYrcjRgBsArGIyJP1PZr1S 5+y6AUUZHcyY9Q7pPYn68g0UP6bBxWSl/iBwPPrTQnBxrFzeVLmgGGRuPN38EDS6u8Wp y/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lBHe6/pz5fBNRXtZmjXFmQCTjeek//STCGQYzWHVJ5Q=; b=mJRxTXJ/euxA86IARhlFl7ngwCls3EEW2XLxUkCvzl3h3s7v55QcCY432fjAHI+9Kf gTTRnmF7qRQTK99gGkosINuG+4KBBltdxebhchLGLTtZQtjgyQahdictWVHY8DPK0cuq GjPlFMXHShgP633QpLNe/g1OfMD+/lIuK7xwU9kdOiyh6NIPVaRwplFirbNuT3BE9NKL 4ctpX9NkQm2yhxqNNu8ciRb77fcO7PVk4F3VE1VavY+MzKtoeUCUIdlp+EbGdgoUuyGK 0SSY4cJw4xPaWCNp1LUAJJT4EAPM2/FJbY82SaHJzM7DxOM5dn9PnN8jNSQiv3/oU/Z3 Sl/A== X-Gm-Message-State: AMke39kynonP5rKkVyxuoVq4H5IB93Jp3cswIEITVznzcCcpbOmZ48JAue6jZfF0UpLLeaCY1DP2WW0vSIfRZg== X-Received: by 10.36.116.71 with SMTP id o68mr11813276itc.60.1487192551533; Wed, 15 Feb 2017 13:02:31 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Wed, 15 Feb 2017 13:02:30 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Wed, 15 Feb 2017 14:02:30 -0700 X-Google-Sender-Auth: EmBZWkBV_ALILfv2w38XnbqbH5g Message-ID: Subject: Re: removing SVR4 binary compatibilty layer To: Mark Millard Cc: Gleb Smirnoff , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:02:32 -0000 On Wed, Feb 15, 2017 at 1:46 PM, Mark Millard wrote: > Gleb Smirnoff glebius at FreeBSD.org wrote > on Tue Feb 14 18:32:40 UTC 2017 : > >> After some discussion on svn mailing list [1], there is intention >> to remove SVR4 binary compatibilty layer from FreeBSD head, meaning >> that FreeBSD 12.0-RELEASE, available in couple of years would >> be shipped without it. There is no intention of merge of the removal. >> The stable@ mailing list added for wider audience. > > Can we presume no invalidation of the TARGET_ARCH=powerpc ABI? > It is SVR4 based as I remember (unlike TARGET_ARCH=powerpc64 ). This is just the SVR4 image activation. The ABI stuff that you are talking about is different. It won't affect that. Warner From owner-freebsd-stable@freebsd.org Thu Feb 16 14:10:14 2017 Return-Path: Delivered-To: freebsd-stable@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 5E720CE086E for ; Thu, 16 Feb 2017 14:10:14 +0000 (UTC) (envelope-from bounce+f02dc0.d7f7e-freebsd-stable=freebsd.org@mg.cool-bird.cn) Received: from mail.a13.static.mgsend.net (mail.a13.static.mgsend.net [104.130.123.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20EAE110A for ; Thu, 16 Feb 2017 14:10:14 +0000 (UTC) (envelope-from bounce+f02dc0.d7f7e-freebsd-stable=freebsd.org@mg.cool-bird.cn) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.cool-bird.cn; q=dns/txt; s=pic; t=1487254214; h=Content-Transfer-Encoding: Mime-Version: Content-Type: Subject: From: To: Reply-To: Message-Id: List-Unsubscribe: Date: Sender; bh=x2HY/x9yIPNNPcMnwbK0zkQyKQQJoiLCSI4mYjbOe4U=; b=buCNJOukwpy1TxIumTcCXC1CNj9ScPdLI/jZrQTk4gZdhYGt08mzxatUKa27CamScUQcMyRn n+mpZY9H7ZviNXqUNMHb9/7+2hdQDTziTrMBcg6ItpoP6tl7jLCYebGkb7+ul3RaEKSizSbo njDGLrRmbARu8SogzZfQwlX8I+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=mg.cool-bird.cn; s=pic; q=dns; h=Sender: Date: List-Unsubscribe: Message-Id: Reply-To: To: From: Subject: Content-Type: Mime-Version: Content-Transfer-Encoding; b=vqHcjeNYW+m9fQ7PBQmBMlKr+SZjZGe+EzcwyewptAUJ2GJIU6Xbahj2moqWt0SI06preO sp+zibf3qSJF1vF9z0BAGh87e6WX7v4B8lywMW9LhwAMeOVSf+UXIeDmbHCJwQ3oCkwzoBcs 1DphiPi8sFky2q9uhKR4aESVcnrBc= Sender: mkt=suntelecom.cn@mg.cool-bird.cn Date: Thu, 16 Feb 2017 14:10:13 +0000 X-Mailgun-Sending-Ip: 104.130.123.13 X-Mailgun-Sid: WyIwMzM1ZCIsICJmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyIsICJkN2Y3ZSJd X-Mailgun-Batch-Id: 4508b3e6-96f5-4157-a892-de349ee93d5e Received: by luna.mailgun.net with HTTP; Thu, 16 Feb 2017 14:09:53 +0000 Message-Id: <20170216140953.26854.81306.8EBBAC21@mg.cool-bird.cn> X-Mailgun-Variables: {"email_id": "11734", "send_id": "17068", "user_id": "12429", "company_id": "10544", "campaigns_id": "16023"} Reply-To: mkt@suntelecom.cn X-Mailgun-Track-Opens: true X-Mailgun-Track-Clicks: true X-Mailgun-Track: true X-Mailgun-Tag: user_12429 X-Mailgun-Tag: comp_10544 X-Mailgun-Tag: send_17068 To: freebsd-stable From: Sun Telecom Subject: Patchcord Production Line Solutions_Sun Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:10:14 -0000 From owner-freebsd-stable@freebsd.org Thu Feb 16 21:54:47 2017 Return-Path: Delivered-To: freebsd-stable@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 DFB71CE218B for ; Thu, 16 Feb 2017 21:54:47 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "internet06.ebureau.com", Issuer "internet06.ebureau.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2BC11B23 for ; Thu, 16 Feb 2017 21:54:47 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id 44E6F7023A6F for ; Thu, 16 Feb 2017 15:47:02 -0600 (CST) X-Virus-Scanned: amavisd-new at mydomain = ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru9T8m479U8k for ; Thu, 16 Feb 2017 15:47:01 -0600 (CST) Received: from square.office.ebureau.com (unknown [10.10.20.22]) by internet06.ebureau.com (Postfix) with ESMTPSA id D91097023A65 for ; Thu, 16 Feb 2017 15:47:01 -0600 (CST) From: Dustin Wenz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Jailed periodic daily scripts smashing CPU Message-Id: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> Date: Thu, 16 Feb 2017 15:47:01 -0600 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:54:48 -0000 I have a number of servers with roughly 60 jails running on each of = them. On these hosts, I've had to disable the periodic security scans = due to overly high disk load when they run (which is redundant in jails = anyway). However, I still have an issue at 3:01am where the CPU is = consumed by dozens of 'xz -c' processes. This is apparently daily log = rolling, which I can't exactly disable. The effect is that our processing applications experience a major = slowdown for about 15 seconds every morning, which is just enough that = it's starting to get people's attention. What is the best way to mitigate this? I'm aware of the cron jitter = feature, but I'm not sure of the 60-second jitter maximum would be = enough (especially if I wanted to start utilizing more jails). - .Dustin= From owner-freebsd-stable@freebsd.org Thu Feb 16 22:20:31 2017 Return-Path: Delivered-To: freebsd-stable@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 84316CE2BFA for ; Thu, 16 Feb 2017 22:20:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4398328F0 for ; Thu, 16 Feb 2017 22:20:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id u68so15386363ywg.0 for ; Thu, 16 Feb 2017 14:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=qZZcPuAWsj5FnDYTN6qnQIvSt77KM7p3UE1P6hH2mSY=; b=FPn7g8BkjF2fWK7E+UxB4+/2X1+X93tkG95+FfFhOP2UgT8TuFw4ouJnKWhXmx4V6V uX3pTowCVcWzBsTAgsfVdGzppzX3UcmUNmq6oXahkeErjZ7aOm/8mDecXpQQ3RYZyVvo Qs5jzDFlHowCPSMM90MydAfQkpOs9Pt56ifNeYw8RzDelw7mlLGRedT6Og0Ig6LtBeus s4vmXeUXsDM0iVKP0T8OFMUC5u6FQgJ8cl3mttVHuoJtNvR6yxcg0HxOrFYefSspxzQ6 edckJuRfLqD5sy4dRWQIdgigMx9WKXZ5jAAePS+mb3OXcU9tlFbz+1l4iMnCPZ0TOr2z HeRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=qZZcPuAWsj5FnDYTN6qnQIvSt77KM7p3UE1P6hH2mSY=; b=Ud7PWlDNM0EIt8lF7eZd14LsjrbmW3mIbNnYE8Vi280cDh+WATNsR4MMvWiCJ9Zkes hU2W610bvqBdw6cLAh9SzH6uL/JonUiutfEif7DTEJlTrmbxOszbs3gPWwsQJLeV6NI7 2/4s6Fsbw1W5vG7HPqS4lC+Dioct5SsAUZ+o+zBAt36XhUoKm+OYQs66dQgTP8BWl2Cf IsEU8YMD0C5U5DabU6HQ2R0eIoP15CHgEKSy/4wv67hKzEuVvKCwd8nOoZUSAC6vlGVX 0yXVbhIUje4w6Xw2v4D8pth1Z3cy+a+Elth/KgwnLTzU02hHVgP6tpANpQt3+ExayU2G BNeg== X-Gm-Message-State: AMke39kXVqqeY0oy9ARfvZpg8Dg2xMCZ1kzeSEG4D7tEnYcZALwRbNdmwdJWSKmiS2KC/YrGejxwE+XVqhZHuw== X-Received: by 10.129.173.71 with SMTP id l7mr3360539ywk.351.1487283630304; Thu, 16 Feb 2017 14:20:30 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Thu, 16 Feb 2017 14:20:29 -0800 (PST) In-Reply-To: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> From: Alan Somers Date: Thu, 16 Feb 2017 15:20:29 -0700 X-Google-Sender-Auth: 2iiu2dNvJ8hbbUeYPgMh27cpolE Message-ID: Subject: Re: Jailed periodic daily scripts smashing CPU To: Dustin Wenz Cc: FreeBSD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:20:31 -0000 Is the problem caused by newsyslog or by the periodic scripts? Newsyslog normally runs from cron directly, not through periodic. In any case, here are a few suggestions: 1) Turn on cron jitter, as you suggested. Even if 60s isn't enough, it can't hurt. 2) Try gz compression instead of xz compression to see if it's faster 3) Manually edit the jails' /etc/crontab files to hardcode some variability into their newsyslog and/or periodic run times 4) If the problem is actually being caused by periodic instead of newsyslog, tell me which script it is and how much jitter you want. I am coincidentally changing how periodic manages jitter right now. -Alan On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz wrote= : > I have a number of servers with roughly 60 jails running on each of them.= On these hosts, I've had to disable the periodic security scans due to ove= rly high disk load when they run (which is redundant in jails anyway). Howe= ver, I still have an issue at 3:01am where the CPU is consumed by dozens of= 'xz -c' processes. This is apparently daily log rolling, which I can't exa= ctly disable. > > The effect is that our processing applications experience a major slowdow= n for about 15 seconds every morning, which is just enough that it's starti= ng to get people's attention. > > What is the best way to mitigate this? I'm aware of the cron jitter featu= re, but I'm not sure of the 60-second jitter maximum would be enough (espec= ially if I wanted to start utilizing more jails). > > - .Dustin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Feb 16 22:40:45 2017 Return-Path: Delivered-To: freebsd-stable@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 95B64CE2343 for ; Thu, 16 Feb 2017 22:40:45 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "internet06.ebureau.com", Issuer "internet06.ebureau.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73DEC14CB; Thu, 16 Feb 2017 22:40:45 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id 2919D7024EB2; Thu, 16 Feb 2017 16:40:43 -0600 (CST) X-Virus-Scanned: amavisd-new at mydomain = ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qltUR5edoKj0; Thu, 16 Feb 2017 16:40:42 -0600 (CST) Received: from square.office.ebureau.com (unknown [10.10.20.22]) by internet06.ebureau.com (Postfix) with ESMTPSA id 89CE27024EA8; Thu, 16 Feb 2017 16:40:42 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Jailed periodic daily scripts smashing CPU From: Dustin Wenz In-Reply-To: Date: Thu, 16 Feb 2017 16:40:42 -0600 Cc: FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <46236914-07E5-4128-947E-E2EBD04542BE@ebureau.com> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> To: Alan Somers X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:40:45 -0000 The biggest offender that I see is = /usr/local/etc/periodic/daily/411.pkg-backup During the high CPU event, my process list contains hundreds of these: 83811 - RJ 0:03.42 xz -c 83816 - S 0:00.02 /usr/local/sbin/pkg shell .dump 83818 - SJ 0:00.02 /usr/local/sbin/pkg shell .dump 83820 - SJ 0:00.03 /usr/local/sbin/pkg shell .dump 83824 - RJ 0:03.41 xz -c 83831 - RJ 0:03.58 xz -c I could probably get away with disabling that in my case. However, instead of jitter, I think I'd prefer if the periodic jobs ran = at a lower priority than my user processes. Either through nice, or = idprio. I want them to get done as fast as possible, but I don't want = them to affect my application. - .Dustin > On Feb 16, 2017, at 4:20 PM, Alan Somers wrote: >=20 > Is the problem caused by newsyslog or by the periodic scripts? > Newsyslog normally runs from cron directly, not through periodic. In > any case, here are a few suggestions: > 1) Turn on cron jitter, as you suggested. Even if 60s isn't enough, > it can't hurt. > 2) Try gz compression instead of xz compression to see if it's faster > 3) Manually edit the jails' /etc/crontab files to hardcode some > variability into their newsyslog and/or periodic run times > 4) If the problem is actually being caused by periodic instead of > newsyslog, tell me which script it is and how much jitter you want. I > am coincidentally changing how periodic manages jitter right now. >=20 > -Alan >=20 > On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz = wrote: >> I have a number of servers with roughly 60 jails running on each of = them. On these hosts, I've had to disable the periodic security scans = due to overly high disk load when they run (which is redundant in jails = anyway). However, I still have an issue at 3:01am where the CPU is = consumed by dozens of 'xz -c' processes. This is apparently daily log = rolling, which I can't exactly disable. >>=20 >> The effect is that our processing applications experience a major = slowdown for about 15 seconds every morning, which is just enough that = it's starting to get people's attention. >>=20 >> What is the best way to mitigate this? I'm aware of the cron jitter = feature, but I'm not sure of the 60-second jitter maximum would be = enough (especially if I wanted to start utilizing more jails). >>=20 >> - .Dustin >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Feb 16 23:50:03 2017 Return-Path: Delivered-To: freebsd-stable@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 0465CCE2887 for ; Thu, 16 Feb 2017 23:50:03 +0000 (UTC) (envelope-from wfc@mintsol.com) Received: from scully.mintsol.com (scully.mintsol.com [199.182.77.206]) (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 D11BF182A; Thu, 16 Feb 2017 23:50:02 +0000 (UTC) (envelope-from wfc@mintsol.com) Received: from mintsol.com (officecc.mintsol.com [96.85.114.33]) by scully.mintsol.com with esmtp; Thu, 16 Feb 2017 18:44:53 -0500 id 00D0715C.0000000058A63975.0000654E Received: from localhost (localhost [127.0.0.1]) (IDENT: uid 1002) by mintsol.com with esmtp; Thu, 16 Feb 2017 18:44:53 -0500 id 00000598.58A63975.00000424 Date: Thu, 16 Feb 2017 18:44:53 -0500 (EST) From: Walter Cramer To: Dustin Wenz cc: Alan Somers , FreeBSD Subject: Re: Jailed periodic daily scripts smashing CPU In-Reply-To: <46236914-07E5-4128-947E-E2EBD04542BE@ebureau.com> Message-ID: <20170216174749.V86669@mulder.mintsol.com> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> <46236914-07E5-4128-947E-E2EBD04542BE@ebureau.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:50:03 -0000 Adding something like: 'sleep $(( $(sysctl -n security.jail.param.jid) * 15 )) && ' in front of more resource-intensive commands in /etc/crontab can reliably spread out the load from a larger number of jails. (But if you start and stop jails frequently enough to spread out the current list of jail id numbers, this method degrades.) Low priority for 'periodic daily' jobs might not help much, due to disk saturation, CPU cache thrashing, etc. -Walter On Thu, 16 Feb 2017, Dustin Wenz wrote: > The biggest offender that I see is /usr/local/etc/periodic/daily/411.pkg-backup > > During the high CPU event, my process list contains hundreds of these: > > 83811 - RJ 0:03.42 xz -c > 83816 - S 0:00.02 /usr/local/sbin/pkg shell .dump > 83818 - SJ 0:00.02 /usr/local/sbin/pkg shell .dump > 83820 - SJ 0:00.03 /usr/local/sbin/pkg shell .dump > 83824 - RJ 0:03.41 xz -c > 83831 - RJ 0:03.58 xz -c > > I could probably get away with disabling that in my case. > > However, instead of jitter, I think I'd prefer if the periodic jobs ran at a lower priority than my user processes. Either through nice, or idprio. I want them to get done as fast as possible, but I don't want them to affect my application. > > - .Dustin > > >> On Feb 16, 2017, at 4:20 PM, Alan Somers wrote: >> >> Is the problem caused by newsyslog or by the periodic scripts? >> Newsyslog normally runs from cron directly, not through periodic. In >> any case, here are a few suggestions: >> 1) Turn on cron jitter, as you suggested. Even if 60s isn't enough, >> it can't hurt. >> 2) Try gz compression instead of xz compression to see if it's faster >> 3) Manually edit the jails' /etc/crontab files to hardcode some >> variability into their newsyslog and/or periodic run times >> 4) If the problem is actually being caused by periodic instead of >> newsyslog, tell me which script it is and how much jitter you want. I >> am coincidentally changing how periodic manages jitter right now. >> >> -Alan >> >> On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz wrote: >>> I have a number of servers with roughly 60 jails running on each of them. On these hosts, I've had to disable the periodic security scans due to overly high disk load when they run (which is redundant in jails anyway). However, I still have an issue at 3:01am where the CPU is consumed by dozens of 'xz -c' processes. This is apparently daily log rolling, which I can't exactly disable. >>> >>> The effect is that our processing applications experience a major slowdown for about 15 seconds every morning, which is just enough that it's starting to get people's attention. >>> >>> What is the best way to mitigate this? I'm aware of the cron jitter feature, but I'm not sure of the 60-second jitter maximum would be enough (especially if I wanted to start utilizing more jails). >>> >>> - .Dustin >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Feb 17 01:20:20 2017 Return-Path: Delivered-To: freebsd-stable@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 DA00ECE138D for ; Fri, 17 Feb 2017 01:20:20 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 A0161167B for ; Fri, 17 Feb 2017 01:20:19 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1BC8128455; Fri, 17 Feb 2017 02:20:11 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 55A0F28468; Fri, 17 Feb 2017 02:20:10 +0100 (CET) Subject: Re: Jailed periodic daily scripts smashing CPU To: Dustin Wenz , freebsd-stable@freebsd.org References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <58A64FCA.5080302@quip.cz> Date: Fri, 17 Feb 2017 02:20:10 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 01:20:20 -0000 Dustin Wenz wrote on 2017/02/16 22:47: > I have a number of servers with roughly 60 jails running on each of them. On these hosts 60 is way more than we have on our jailers. Daily / security scripts are very disk IO intensive so we end up with changing time in /etc/crontab in each jail for periodic tasks. The best way is to randomize these times on jail creation time. Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Feb 17 07:34:44 2017 Return-Path: Delivered-To: freebsd-stable@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 5496ECE2E15 for ; Fri, 17 Feb 2017 07:34:44 +0000 (UTC) (envelope-from Guy.TABRAR@uk.bnpparibas.com) Received: from lonmail9.bnpparibas.com (lonmail9.bnpparibas.com [155.140.133.144]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lonmail9.bnpparibas.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1F9012A3 for ; Fri, 17 Feb 2017 07:34:43 +0000 (UTC) (envelope-from Guy.TABRAR@uk.bnpparibas.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uk.bnpparibas.com; i=@uk.bnpparibas.com; l=1527; q=dns/txt; s=20151010; t=1487316883; x=1518852883; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=HOl29uvCkFqS1/mU/yJBJvl11SlW5iJre3I53pSV5Io=; b=rOJKwWLkZVlyMu0hpH2x4nlswZC5WhZvh8nNTBEjRMDDKBGtGTXeJtUl knnPFC1UcJgPD3tfvGc9WiDRLvabebbh5oWNDolWrhmUXSBUsHHLlf54i XyV2wXfTZiERp2SdhVqejBbQnHdyvp4UZ9kk3cYlcj+NGrIbBxiO0iSb9 N13/VKO16wSypmcjtr2oSs/si9ltYGAPdIPuX2cBe+4vduOqEI9q1+j1z 290XWMDEtY5wOPvU8EePpDsIqSur4rSlTXnglRL8C6aq9Kj7IwNcBhovd Q0BOeEf4PW6GoJ2QdPA342X9xZW/s8RzxZVXPVLqFBhoZFRGbFj4zE69U A==; X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208";a="13194838" X-HopCount: * X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208";a="162536102" From: Guy TABRAR To: Miroslav Lachman <000.fbsd@quip.cz>, Dustin Wenz , "freebsd-stable@freebsd.org" Subject: RE: Jailed periodic daily scripts smashing CPU Thread-Topic: Jailed periodic daily scripts smashing CPU Thread-Index: AQHSiJ9TB9MTlD6pxEuH83YkTHTCp6FsZrcAgABmoEA= Date: Fri, 17 Feb 2017 07:29:32 +0000 Message-ID: <2112385FC012E541A52D6A28563A5572011894C8@LONS00110044.mercury.intra> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> <58A64FCA.5080302@quip.cz> In-Reply-To: <58A64FCA.5080302@quip.cz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-CFilter-Loop: Reflected Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 07:34:44 -0000 What about: @daily sleep ${RANDOM:0:2}m ; /some/cron/job.sh Which gives you a jitter of up to 99 minutes. Cheers, Guy -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd= .org] On Behalf Of Miroslav Lachman Sent: 17 February 2017 01:20 To: Dustin Wenz; freebsd-stable@freebsd.org Subject: Re: Jailed periodic daily scripts smashing CPU Dustin Wenz wrote on 2017/02/16 22:47: > I have a number of servers with roughly 60 jails running on each of = > them. On these hosts 60 is way more than we have on our jailers. Daily / security scripts are ve= ry disk IO intensive so we end up with changing time in /etc/crontab in eac= h jail for periodic tasks. The best way is to randomize these times on jail creation time. Miroslav Lachman _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you = are not the intended recipient (or have received this e-mail in error) plea= se notify the sender immediately and delete this e-mail. Any unauthorised c= opying, disclosure or distribution of the material in this e-mail is prohib= ited. Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for additi= onal disclosures. From owner-freebsd-stable@freebsd.org Fri Feb 17 16:47:27 2017 Return-Path: Delivered-To: freebsd-stable@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 D4FAACE3025 for ; Fri, 17 Feb 2017 16:47:27 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "internet06.ebureau.com", Issuer "internet06.ebureau.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B246C1556; Fri, 17 Feb 2017 16:47:27 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id 18CED703335F; Fri, 17 Feb 2017 10:47:25 -0600 (CST) X-Virus-Scanned: amavisd-new at mydomain = ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4XwSA5PVV-E; Fri, 17 Feb 2017 10:47:24 -0600 (CST) Received: from square.office.ebureau.com (unknown [10.10.20.22]) by internet06.ebureau.com (Postfix) with ESMTPSA id 49E2D7033355; Fri, 17 Feb 2017 10:47:24 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Jailed periodic daily scripts smashing CPU From: Dustin Wenz In-Reply-To: <20170216174749.V86669@mulder.mintsol.com> Date: Fri, 17 Feb 2017 10:47:23 -0600 Cc: FreeBSD , Alan Somers Content-Transfer-Encoding: quoted-printable Message-Id: <7D7C8824-319C-4891-8B35-82F9B461FE5D@ebureau.com> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> <46236914-07E5-4128-947E-E2EBD04542BE@ebureau.com> <20170216174749.V86669@mulder.mintsol.com> To: Walter Cramer X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:47:27 -0000 If I needed to go down the road of spreading out the daily maintenance = over a longer period of time, I'd probably use your solution of building = in a delay based on the jail id, or possibly Guy Tabrar's extreme jitter = example. The pkg-backup job appears somewhat flawed, in my view. The xz = compressor is totally CPU bound for a moderate number of jails . Sure, = running it at low priority isn't as cache friendly, but it's certainly = better then the host becoming unresponsive. The other issue is that in = most cases the package archive doesn't change, and so running a daily = backup without checking for changes is wasteful. In my case, ZFS handles = all the rolling backups that I could ever need, so using pkg-backup for = that purpose is redundant. - .Dustin > On Feb 16, 2017, at 5:44 PM, Walter Cramer wrote: >=20 > Adding something like: >=20 > 'sleep $(( $(sysctl -n security.jail.param.jid) * 15 )) && ' >=20 > in front of more resource-intensive commands in /etc/crontab can = reliably spread out the load from a larger number of jails. >=20 > (But if you start and stop jails frequently enough to spread out the = current list of jail id numbers, this method degrades.) >=20 > Low priority for 'periodic daily' jobs might not help much, due to = disk saturation, CPU cache thrashing, etc. > -Walter >=20 > On Thu, 16 Feb 2017, Dustin Wenz wrote: >=20 >> The biggest offender that I see is = /usr/local/etc/periodic/daily/411.pkg-backup >>=20 >> During the high CPU event, my process list contains hundreds of = these: >>=20 >> 83811 - RJ 0:03.42 xz -c >> 83816 - S 0:00.02 /usr/local/sbin/pkg shell .dump >> 83818 - SJ 0:00.02 /usr/local/sbin/pkg shell .dump >> 83820 - SJ 0:00.03 /usr/local/sbin/pkg shell .dump >> 83824 - RJ 0:03.41 xz -c >> 83831 - RJ 0:03.58 xz -c >>=20 >> I could probably get away with disabling that in my case. >>=20 >> However, instead of jitter, I think I'd prefer if the periodic jobs = ran at a lower priority than my user processes. Either through nice, or = idprio. I want them to get done as fast as possible, but I don't want = them to affect my application. >>=20 >> - .Dustin >>=20 >>=20 >>> On Feb 16, 2017, at 4:20 PM, Alan Somers = wrote: >>>=20 >>> Is the problem caused by newsyslog or by the periodic scripts? >>> Newsyslog normally runs from cron directly, not through periodic. = In >>> any case, here are a few suggestions: >>> 1) Turn on cron jitter, as you suggested. Even if 60s isn't enough, >>> it can't hurt. >>> 2) Try gz compression instead of xz compression to see if it's = faster >>> 3) Manually edit the jails' /etc/crontab files to hardcode some >>> variability into their newsyslog and/or periodic run times >>> 4) If the problem is actually being caused by periodic instead of >>> newsyslog, tell me which script it is and how much jitter you want. = I >>> am coincidentally changing how periodic manages jitter right now. >>>=20 >>> -Alan >>>=20 >>> On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz = wrote: >>>> I have a number of servers with roughly 60 jails running on each of = them. On these hosts, I've had to disable the periodic security scans = due to overly high disk load when they run (which is redundant in jails = anyway). However, I still have an issue at 3:01am where the CPU is = consumed by dozens of 'xz -c' processes. This is apparently daily log = rolling, which I can't exactly disable. >>>>=20 >>>> The effect is that our processing applications experience a major = slowdown for about 15 seconds every morning, which is just enough that = it's starting to get people's attention. >>>>=20 >>>> What is the best way to mitigate this? I'm aware of the cron jitter = feature, but I'm not sure of the 60-second jitter maximum would be = enough (especially if I wanted to start utilizing more jails). >>>>=20 >>>> - .Dustin >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat Feb 18 01:32:52 2017 Return-Path: Delivered-To: freebsd-stable@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 A4F37CE353F; Sat, 18 Feb 2017 01:32:52 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 87DC41343; Sat, 18 Feb 2017 01:32:52 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id BAEAC5A9F12; Sat, 18 Feb 2017 01:32:50 +0000 (UTC) Date: Sat, 18 Feb 2017 01:32:50 +0000 From: Brooks Davis To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Calling ATM NIC users: en(4), fatm(4), hatm(4), patm(4) Message-ID: <20170218013250.GA72688@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 01:32:52 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Our current ATM stack supports a small number of NICs that were current in the late 90s[0]. None of them have been manufactured in a long time and while you can buy hatm(4) devices on e-bay, it's increasingly difficult to find a motherboard that will accept them. I'd like to propose removing support for these NICs along with the remaining ATM stack in FreeBSD 12. This will give any existing users a supported OS until at least September 30, 2021 per our published EOL date for FreeBSD 11. Would removal on this schedule cause you realistic hardship? If so, please let us know. -- Brooks [0] 1997 press release for the most advanced ATM NIC we support http://www.prnewswire.com/news-releases/fore-systems-introduces-industrys-most-advanced-atm-adapter-for-enterprise-networking-77407267.html --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYp6RBAAoJEKzQXbSebgfAbDAH/20gM5KICd8/FS2gbHMl1dkv bnRQIK5jzqcCHOF3FTODgHwb4NScLTkQsMYIZgxJi/+EHJRg8iZXkab6VzezoQnH 9PJCYr+Tc1nI+j6okwdFELuy6/pkRt/kOEtQo35e7YXSvyEZOR+99855NSsImC1p /oC5IdjR9ENoK6e+7VXHya4dFsqFpt9PvdZnvDGm9NDE4+56p86s3Bw0USgC4ujP PNGQKKOBGTaf0Ovi67gHj3fz+a/ZcrgVZdVxLJeZxAwHoW7QgxhSEdLq5tD7MNKQ KhoN62GHnyIY0s5juvPnlb+l50ZYlxVF6XuT5QTm79DhpyLdPLHCjpzVyGsPcrY= =QsQU -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-stable@freebsd.org Sat Feb 18 15:35:27 2017 Return-Path: Delivered-To: freebsd-stable@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 B1EA1CE4A6F for ; Sat, 18 Feb 2017 15:35:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 754FD1A96; Sat, 18 Feb 2017 15:35:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cf72h-000K3N-Pv; Sat, 18 Feb 2017 15:35:23 +0000 Date: Sat, 18 Feb 2017 15:35:23 +0000 From: Gary Palmer To: Dustin Wenz Cc: Walter Cramer , FreeBSD , Alan Somers Subject: Re: Jailed periodic daily scripts smashing CPU Message-ID: <20170218153523.GA51196@in-addr.com> References: <321260F8-95D8-4C21-90B5-FDB0F6FF98F9@ebureau.com> <46236914-07E5-4128-947E-E2EBD04542BE@ebureau.com> <20170216174749.V86669@mulder.mintsol.com> <7D7C8824-319C-4891-8B35-82F9B461FE5D@ebureau.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D7C8824-319C-4891-8B35-82F9B461FE5D@ebureau.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 15:35:27 -0000 On Fri, Feb 17, 2017 at 10:47:23AM -0600, Dustin Wenz wrote: > If I needed to go down the road of spreading out the daily maintenance over a longer period of time, I'd probably use your solution of building in a delay based on the jail id, or possibly Guy Tabrar's extreme jitter example. > > The pkg-backup job appears somewhat flawed, in my view. The xz compressor is totally CPU bound for a moderate number of jails . Sure, running it at low priority isn't as cache friendly, but it's certainly better then the host becoming unresponsive. The other issue is that in most cases the package archive doesn't change, and so running a daily backup without checking for changes is wasteful. In my case, ZFS handles all the rolling backups that I could ever need, so using pkg-backup for that purpose is redundant. > Hi, At least in my copy of the /usr/local/etc/periodic/daily/411.pkg-backup script, there is an option to enable backing up the pkg db in the jails from the host OS. If you put daily_backup_pkgng_enable=NO into the periodic.conf in the jails and daily_backup_pkg_jails=YES in the host there should be no more than a single thread consuming CPU doing the pkg backups as they're done sequentially rather than in parallel. In general I think a method of forcing a jail to start it's jobs later based on JID (or some other metric as JID could get rather large and sparse if you stop/start jails a lot) is a good idea that should be looked at for inclusion in base Regards, Gary > > > On Feb 16, 2017, at 5:44 PM, Walter Cramer wrote: > > > > Adding something like: > > > > 'sleep $(( $(sysctl -n security.jail.param.jid) * 15 )) && ' > > > > in front of more resource-intensive commands in /etc/crontab can reliably spread out the load from a larger number of jails. > > > > (But if you start and stop jails frequently enough to spread out the current list of jail id numbers, this method degrades.) > > > > Low priority for 'periodic daily' jobs might not help much, due to disk saturation, CPU cache thrashing, etc. > > -Walter > > > > On Thu, 16 Feb 2017, Dustin Wenz wrote: > > > >> The biggest offender that I see is /usr/local/etc/periodic/daily/411.pkg-backup > >> > >> During the high CPU event, my process list contains hundreds of these: > >> > >> 83811 - RJ 0:03.42 xz -c > >> 83816 - S 0:00.02 /usr/local/sbin/pkg shell .dump > >> 83818 - SJ 0:00.02 /usr/local/sbin/pkg shell .dump > >> 83820 - SJ 0:00.03 /usr/local/sbin/pkg shell .dump > >> 83824 - RJ 0:03.41 xz -c > >> 83831 - RJ 0:03.58 xz -c > >> > >> I could probably get away with disabling that in my case. > >> > >> However, instead of jitter, I think I'd prefer if the periodic jobs ran at a lower priority than my user processes. Either through nice, or idprio. I want them to get done as fast as possible, but I don't want them to affect my application. > >> > >> - .Dustin > >> > >> > >>> On Feb 16, 2017, at 4:20 PM, Alan Somers wrote: > >>> > >>> Is the problem caused by newsyslog or by the periodic scripts? > >>> Newsyslog normally runs from cron directly, not through periodic. In > >>> any case, here are a few suggestions: > >>> 1) Turn on cron jitter, as you suggested. Even if 60s isn't enough, > >>> it can't hurt. > >>> 2) Try gz compression instead of xz compression to see if it's faster > >>> 3) Manually edit the jails' /etc/crontab files to hardcode some > >>> variability into their newsyslog and/or periodic run times > >>> 4) If the problem is actually being caused by periodic instead of > >>> newsyslog, tell me which script it is and how much jitter you want. I > >>> am coincidentally changing how periodic manages jitter right now. > >>> > >>> -Alan > >>> > >>> On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz wrote: > >>>> I have a number of servers with roughly 60 jails running on each of them. On these hosts, I've had to disable the periodic security scans due to overly high disk load when they run (which is redundant in jails anyway). However, I still have an issue at 3:01am where the CPU is consumed by dozens of 'xz -c' processes. This is apparently daily log rolling, which I can't exactly disable. > >>>> > >>>> The effect is that our processing applications experience a major slowdown for about 15 seconds every morning, which is just enough that it's starting to get people's attention. > >>>> > >>>> What is the best way to mitigate this? I'm aware of the cron jitter feature, but I'm not sure of the 60-second jitter maximum would be enough (especially if I wanted to start utilizing more jails). > >>>> > >>>> - .Dustin > >>>> _______________________________________________ > >>>> freebsd-stable@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >