From owner-freebsd-stable@freebsd.org Sun Oct 25 03:21:56 2015 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 5EE97A18D57 for ; Sun, 25 Oct 2015 03:21:56 +0000 (UTC) (envelope-from tpearson@raptorengineeringinc.com) Received: from mail.pearsoncomputing.net (pearsoncomputing.net [192.119.205.242]) (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 F40E8320 for ; Sun, 25 Oct 2015 03:21:54 +0000 (UTC) (envelope-from tpearson@raptorengineeringinc.com) Received: from localhost (localhost [127.0.0.1]) by mail.pearsoncomputing.net (Postfix) with ESMTP id 8D9BE6403CC for ; Sat, 24 Oct 2015 22:21:46 -0500 (CDT) Received: from mail.pearsoncomputing.net ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dlKUjrLtuETy for ; Sat, 24 Oct 2015 22:21:44 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.pearsoncomputing.net (Postfix) with ESMTP id 43DD3640DB5 for ; Sat, 24 Oct 2015 22:21:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.pearsoncomputing.net 43DD3640DB5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineeringinc.com; s=5DF8A618-71A7-11E4-BA59-1A98DAB8A1D6; t=1445743304; bh=wo/HH6YhKUeGiIFxSRHJINGLoKEPSb/mvm90QK6VX90=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=bOoPEYrVJUIqzO3UjbmKJjXcFKkZmJtUqbVhJFnZINZLlvUooAMqMWkTy+cha6Fts 8SWB0ryZhyqQ5svzTTeLa5KTQ0KP3dsQPL2+MOE74KNK4cMCat0lgQ+r59w8xVyHPt tgLP/I+qVi5zbRD1mtM5PauXu8CRM7WdCLeX3P+Q= X-Virus-Scanned: amavisd-new at pearsoncomputing.net Received: from mail.pearsoncomputing.net ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ng_C8ugSC7TD for ; Sat, 24 Oct 2015 22:21:43 -0500 (CDT) Received: from [192.168.3.54] (apollo.starlink.edu [192.168.3.54]) by mail.pearsoncomputing.net (Postfix) with ESMTP id DFA466403CC for ; Sat, 24 Oct 2015 22:21:43 -0500 (CDT) Message-ID: <562C4AC7.7070001@raptorengineeringinc.com> Date: Sat, 24 Oct 2015 22:21:43 -0500 From: Timothy Pearson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100922 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Stable 10.1 kernel boot hang References: <5629C996.60107@raptorengineeringinc.com> In-Reply-To: <5629C996.60107@raptorengineeringinc.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 25 Oct 2015 03:21:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/2015 12:45 AM, Timothy Pearson wrote: > Hi all, > > We are attempting to upgrade some older FreeBSD machines to use the ASUS > KGPE-D16 mainboard, however the kernel on 10.1 hangs during boot while > enumerating PCIe devices. Linux boots with no issues. > > Verbose boot log: > > Type '?' for a list of commands, 'help' for more detailed help. > OK set boot_verbose="1" > OK boot > Booting... > |/-\|/-\KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=000000000009fc00 > SMAP type=02 base=000000000009fc00 len=0000000000000400 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=00000000bfb86000 > SMAP type=02 base=00000000bfc86000 len=000000001037a000 > SMAP type=02 base=00000000f0b00000 len=0000000000004000 > SMAP type=02 base=00000000fec00000 len=0000000000001000 > SMAP type=02 base=00000000fed00000 len=0000000000001000 > SMAP type=01 base=0000000100000000 len=0000000140000000 > Table 'FACP' at 0xbfca3680 > Table 'SSDT' at 0xbfca3780 > Table 'MCFG' at 0xbfca4630 > Table 'TCPA' at 0xbfca4670 > Table 'APIC' at 0xbfca46b0 > APIC: Found table at 0xbfca46b0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 2: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 3 ACPI ID 3: enabled > SMP: Added CPU 3 (AP) > MADT: Found CPU APIC ID 4 ACPI ID 4: enabled > SMP: Added CPU 4 (AP) > MADT: Found CPU APIC ID 5 ACPI ID 5: enabled > SMP: Added CPU 5 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 6: enabled > SMP: Added CPU 6 (AP) > MADT: Found CPU APIC ID 7 ACPI ID 7: enabled > SMP: Added CPU 7 (AP) > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-RELEASE-p9 #0 57b23e7(releng/10.1)-dirty: Wed May 13 > 00:53:02 CDT 2015 > > root@pfsense-build:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10 > amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff824d2000. > Calibrating TSC clock ... TSC clock: 2000060881 Hz > CPU: AMD Opteron(tm) Processor 6129 (2000.06-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f91 Family = 0x10 Model = 0x9 > Stepping = 1 > > Features=0x178bfbff > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x837ff > TSC: P-state invariant > L1 2MB data TLB: 48 entries, fully associative > L1 2MB instruction TLB: 16 entries, fully associative > L1 4KB data TLB: 48 entries, fully associative > L1 4KB instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way > associative > L2 2MB data TLB: 128 entries, 2-way associative > L2 2MB instruction TLB: 0 entries, 2-way associative > L2 4KB data TLB: 512 entries, 4-way associative > L2 4KB instruction TLB: 512 entries, 4-way associative > L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative > real memory = 9663676416 (9216 MB) > Physical memory chunk(s): > 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x00000000024fc000 - 0x00000000bfc85fff, 3178799104 bytes (776074 pages) > 0x0000000100000000 - 0x0000000231518fff, 5122396160 bytes (1250585 pages) > avail memory = 8263753728 (7880 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > INTR: Adding local APIC 2 as a target > INTR: Adding local APIC 3 as a target > INTR: Adding local APIC 4 as a target > INTR: Adding local APIC 5 as a target > INTR: Adding local APIC 6 as a target > INTR: Adding local APIC 7 as a target > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 8 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > APIC: CPU 2 has ACPI ID 2 > APIC: CPU 3 has ACPI ID 3 > APIC: CPU 4 has ACPI ID 4 > APIC: CPU 5 has ACPI ID 5 > APIC: CPU 6 has ACPI ID 6 > APIC: CPU 7 has ACPI ID 7 > x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 > x86bios: SSEG 0x098000-0x098fff at 0xfffffe001a367000 > x86bios: EBDA 0x09f000-0x09ffff at 0xfffff8000009f000 > x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 > XEN: CPU 0 has VCPU ID 0 > XEN: CPU 1 has VCPU ID 1 > XEN: CPU 2 has VCPU ID 2 > XEN: CPU 3 has VCPU ID 3 > XEN: CPU 4 has VCPU ID 4 > XEN: CPU 5 has VCPU ID 5 > XEN: CPU 6 has VCPU ID 6 > XEN: CPU 7 has VCPU ID 7 > random device not loaded; using insecure entropy > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > ULE: setup cpu 4 > ULE: setup cpu 5 > ULE: setup cpu 6 > ULE: setup cpu 7 > ACPI: RSDP 0xf16b0 00024 (v02 CORE ) > ACPI: XSDT 0xbfca10e0 0007C (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: FACP 0xbfca3680 000F4 (v03 CORE COREBOOT 00000000 CORE 00000000) > ACPI: DSDT 0xbfca1280 023F2 (v02 ASUS COREBOOT 00000001 INTL 20140114) > ACPI: FACS 0xbfca1240 00040 > ACPI: SSDT 0xbfca3780 00EA6 (v02 CORE COREBOOT 0000002A CORE 0000002A) > ACPI: MCFG 0xbfca4630 0003C (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: TCPA 0xbfca4670 00032 (v02 CORE COREBOOT 00000000 CORE 00000000) > ACPI: APIC 0xbfca46b0 000A4 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: SRAT 0xbfca4760 00150 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: SLIT 0xbfca48b0 00030 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: IVRS 0xbfca48e0 000E0 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: HPET 0xbfca49c0 00038 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: SRAT 0xbfca4a00 00150 (v01 CORE COREBOOT 00000000 CORE 00000000) > ACPI: SLIT 0xbfca4b50 00030 (v01 CORE COREBOOT 00000000 CORE 00000000) > MADT: Found IO APIC ID 32, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 32 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 33, Interrupt 24 at 0xf8000000 > ioapic1: Changing APIC ID to 33 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-55 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000300ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > firmware: 'iwn2030fw' version 0: 707392 bytes loaded at 0xffffffff81978f5c > firmware: 'iwn4965fw' version 0: 187972 bytes loaded at 0xffffffff81a25b4c > firmware: 'iwn5000fw' version 0: 340696 bytes loaded at 0xffffffff81a53a3c > firmware: 'iwn5150fw' version 0: 337400 bytes loaded at 0xffffffff81aa6dc4 > firmware: 'iwn6000fw' version 0: 454608 bytes loaded at 0xffffffff81af946c > firmware: 'wpifw' version 153229: 150100 bytes loaded at 0xffffffff81e011e4 > firmware: 'iwn6000g2afw' version 0: 444128 bytes loaded at > 0xffffffff81b684ec > firmware: 'iwn6000g2bfw' version 0: 460912 bytes loaded at > 0xffffffff81bd4c7c > firmware: 'iwn6050fw' version 0: 469780 bytes loaded at 0xffffffff81c4559c > snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] > feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 > feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 > firmware: 't4fw_cfg' version 0: 3059 bytes loaded at 0xffffffff816569c4 > firmware: 't4fw_cfg_uwire' version 0: 21284 bytes loaded at > 0xffffffff816575b7 > firmware: 't4fw' version 0: 512512 bytes loaded at 0xffffffff8165c8db > firmware: 't5fw_cfg' version 0: 3435 bytes loaded at 0xffffffff816d9b8c > firmware: 't5fw' version 0: 513024 bytes loaded at 0xffffffff816da8f7 > firmware: 'mw88W8363fw' version 0: 94940 bytes loaded at 0xffffffff81cc3c6c > firmware: 'mwlboot' version 0: 2280 bytes loaded at 0xffffffff81cdaf48 > firmware: 'rsu-rtl8712fw' version 120: 122328 bytes loaded at > 0xffffffff81dc4e24 > firmware: 'runfw' version 0: 8192 bytes loaded at 0xffffffff81de2fe4 > wlan: mac acl policy registered > firmware: 'rt2561fw' version 0: 8192 bytes loaded at 0xffffffff81d65334 > firmware: 'rt2561sfw' version 0: 8192 bytes loaded at 0xffffffff81d673e4 > firmware: 'urtwn-rtl8188eufw' version 111: 13904 bytes loaded at > 0xffffffff81de591c > firmware: 'urtwn-rtl8192cfwT' version 111: 16076 bytes loaded at > 0xffffffff81de901c > firmware: 'urtwn-rtl8192cfwU' version 111: 16076 bytes loaded at > 0xffffffff81decf94 > firmware: 'rt2661fw' version 0: 8192 bytes loaded at 0xffffffff81d69494 > firmware: 'rt2860fw' version 0: 8192 bytes loaded at 0xffffffff81d6b544 > firmware: 'mxge_eth_z8e' version 377284: 120629 bytes loaded at > 0xffffffff81cdba00 > wlan: <802.11 Link Layer> > firmware: 'mxge_ethp_z8e' version 387604: 121317 bytes loaded at > 0xffffffff81cf91f0 > firmware: 'mxge_rss_eth_z8e' version 534724: 151912 bytes loaded at > 0xffffffff81d16c90 > firmware: 'mxge_rss_ethp_z8e' version 544468: 152837 bytes loaded at > 0xffffffff81d3beb0 > ipw_bss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_bss: If you agree with the license, set > legal.intel_ipw.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_bss_fw, 0xffffffff8060b5d0, 0) error 1 > ipw_ibss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_ibss: If you agree with the license, set > legal.intel_ipw.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_ibss_fw, 0xffffffff8060b680, 0) error 1 > ipw_monitor: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_monitor: If you agree with the license, set > legal.intel_ipw.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_monitor_fw, 0xffffffff8060b730, 0) > error 1 > iwi_bss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_iwi/. > iwi_bss: If you agree with the license, set > legal.intel_iwi.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (iwi_bss_fw, 0xffffffff80632da0, 0) error 1 > iwi_ibss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_iwi/. > iwi_ibss: If you agree with the license, set > legal.intel_iwi.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (iwi_ibss_fw, 0xffffffff80632e50, 0) error 1 > iwi_monitor: You need to read the LICENSE file in > /usr/share/doc/legal/intel_iwi/. > iwi_monitor: If you agree with the license, set > legal.intel_iwi.license_ack=1 in /boot/loader.conf. > module_register_init: MOD_LOAD (iwi_monitor_fw, 0xffffffff80632f00, 0) > error 1 > firmware: 'iwn1000fw' version 0: 337520 bytes loaded at 0xffffffff8187c94c > firmware: 'iwn2000fw' version 0: 695876 bytes loaded at 0xffffffff818cf06c > Hardware, Intel Secure Key RNG: RDRAND is not present > Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present > null: > Falling back to random adaptor > random: initialized > nfslock: pseudo-device > crypto: > VESA: INT 0x10 vector 0xc000:0x3d14 > VESA: information block > 0000 56 45 53 41 00 03 cb 40 00 c0 00 00 00 00 22 00 > 0010 00 99 04 00 00 00 df 40 00 c0 f2 40 00 c0 06 41 > 0020 00 c0 03 00 ff ff 00 00 00 00 00 00 00 00 00 00 > 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > VBE mode info request: 3 > VESA: 1 mode(s) found > VESA: v3.0, 256k memory, flags:0x0, mode table:0xfffffe001a3fe022 (99000022) > VESA: SeaBIOS VBE(C) 2011 > VESA: SeaBIOS Developers SeaBIOS VBE Adapter Rev. 1 > io: > VMBUS: load > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > hpt27xx: RocketRAID 27xx controller driver v1.1 > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > hptnr: R750/DC7280 controller driver v1.0.1 > cryptosoft0: on motherboard > crypto: assign cryptosoft0 driver id 0, flags 100663296 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > padlock0: No ACE support. > acpi0: on motherboard > ACPI: All ACPI Tables successfully acquired > PCIe: Memory Mapped configuration base @ 0xe0000000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: Power Button (fixed) > cpu0: Processor \_PR_.CP00 (ACPI ID 0) -> APIC ID 0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > cpu1: Processor \_PR_.CP01 (ACPI ID 1) -> APIC ID 1 > cpu1: on acpi0 > cpu2: Processor \_PR_.CP02 (ACPI ID 2) -> APIC ID 2 > cpu2: on acpi0 > cpu3: Processor \_PR_.CP03 (ACPI ID 3) -> APIC ID 3 > cpu3: on acpi0 > cpu4: Processor \_PR_.CP04 (ACPI ID 4) -> APIC ID 4 > cpu4: on acpi0 > cpu5: Processor \_PR_.CP05 (ACPI ID 5) -> APIC ID 5 > cpu5: on acpi0 > cpu6: Processor \_PR_.CP06 (ACPI ID 6) -> APIC ID 6 > cpu6: on acpi0 > cpu7: Processor \_PR_.CP07 (ACPI ID 7) -> APIC ID 7 > cpu7: on acpi0 > hpet0: iomem 0xfed00000-0xfed00fff irq 0,8 > on acpi0 > hpet0: vendor 0x4353, rev 0x1, 5681818181818Hz, 3 timers, legacy route > hpet0: t0: irqs 0x00c0ffff (0), periodic > hpet0: t1: irqs 0x00c0ffff (0), periodic > hpet0: t2: irqs 0x00c0ffff (0), periodic > Timecounter "HPET" frequency 5681818181818 Hz -- Insufficient hz, needs > at least 1454 > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x820-0x823 on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 4 7 10 11 12 14 15 > Validation 0 255 N 0 4 7 10 11 12 14 15 > After Disable 0 255 N 0 4 7 10 11 12 14 15 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: decoding 4 range 0x3b0-0x3df > pcib0: decoding 4 range 0xd00-0x4fff > pcib0: decoding 3 range 0xa0000-0xbffff > pcib0: decoding 3 range 0xe0000000-0xf0bfffff > pcib0: decoding 3 range 0xf8000000-0xf80fffff > pcib0: decoding 4 range 0-0xcf7 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1002, dev=0x5a10, revid=0x02 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0102, statreg=0x2018, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > MSI supports 4 messages > found-> vendor=0x1022, dev=0x1200, revid=0x00 > domain=0, bus=0, slot=24, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1201, revid=0x00 > domain=0, bus=0, slot=24, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1202, revid=0x00 > domain=0, bus=0, slot=24, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1203, revid=0x00 > domain=0, bus=0, slot=24, func=3 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1204, revid=0x00 > domain=0, bus=0, slot=24, func=4 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1200, revid=0x00 > domain=0, bus=0, slot=25, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1201, revid=0x00 > domain=0, bus=0, slot=25, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1202, revid=0x00 > domain=0, bus=0, slot=25, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1203, revid=0x00 > domain=0, bus=0, slot=25, func=3 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1204, revid=0x00 > domain=0, bus=0, slot=25, func=4 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > The machine just hangs at this point. ACPI cannot be disabled as the > board does not support the APIC fallback required. > > Any ideas? > _ Just to follow up on this setting hw.pci.mcfg=0 allowed the boot to proceed. Apparently the ACPI PCIe MCFG pointer is messed up in the boot firmware. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWLErDAAoJEK+E3vEXDOFbjMUIAJ0LBQK0nRUR7JPAP8hc5ksC 3Un31iySPe8eJEi7Lf5eePhScSXpSl0ig1epzK7jJ9S+31nsDoTupRRO3rK7WiD0 EBl3yoSUfY3CgrUSkSMOpgXsDw/q+MOnEjAqbv98g8+Qy0pGI8CPgiqs0uKmkGPi lqiTvlwu9Al/N11w21enuRicREgDg0wg3jdQOajgeKJciC9UdTe2DcJu2KDkfut9 2F+WZKIIW3G1u5mLiSGhPM+JbkmM75NaySgYJg1D+oJtYUaLLWTu/Q7EWCTBLmkD AZ0Y35QPt1lg8+0cIPyNackPp2fKIpu919/avTOsZNa25DRv14e86bstAnQKkVo= =xdfV -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Mon Oct 26 02:59:47 2015 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 8177C8C6A; Mon, 26 Oct 2015 02:59:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 2DE1313D6; Mon, 26 Oct 2015 02:59:45 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f799c6d000001933-47-562d971edd9b 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A3.A0.06451.E179D265; Sun, 25 Oct 2015 22:59:42 -0400 (EDT) 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 t9Q2xf8d028728; Sun, 25 Oct 2015 22:59:41 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9Q2xbBC005829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Oct 2015 22:59:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9Q2xbd4023860; Sun, 25 Oct 2015 22:59:37 -0400 (EDT) Date: Sun, 25 Oct 2015 22:59:37 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2015 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrCs3XTfMYOInLotd106zW8x584HJ Yvvmf4wWh5uFHFg8ZnyazxLAGMVlk5Kak1mWWqRvl8CVceXWA8aCXx1sFfeO3WVrYFx5j6WL kYNDQsBEYul8wS5GTiBTTOLCvfVsILaQwGImientdl2MXED2RkaJTdMnskI4h5gkZvxYyQjh NDBKNB+YyQ7SwiKgLfH3/ktmEJtNQE3i8d5mVoixihKbT01iBtkmIiAvseC8PUiYWcBaYu66 9WAlwgK2Ek/XX2ABsXkFHCV+fJjABGKLCuhIrN4/BSouKHFy5hMWiF4tieXTt7FMYBSYhSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjODQlOTfwfjtoNIhRgEO RiUe3hc8umFCrIllxZW5hxglOZiURHnP1gKF+JLyUyozEosz4otKc1KLDzFKcDArifBmtQHl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeOOnAjUKFqWmp1akZeaU IKSZODhBhvMADf81BWR4cUFibnFmOkT+FKMxx6Np19YycayZcn8tkxBLXn5eqpQ4byPIOAGQ 0ozSPLhp4PSym0n1FaM40HPCvBtBqniAqQlu3iugVUxAq/KfaYKsKklESEk1MPq/m8h7XJqL +deiW7ESScxb/hhM8pacEmg3S/TVeu0niyX+Ni5dVqXOHLZSVy/itMjuM1tnebrf0/z5MKrs gmTx5t+/Fqw1vKD5cLVzhHhrK7fMGXvdfrcNuUJhDTvOxC0/Lv9M5WFBJ9NfP4bHKrY8jxvC T4cekNjxdrOU7AZO3aXqBbqmeUosxRmJhlrMRcWJABFBCNsKAwAA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 02:59:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2015 The third quarter of 2015, from July to September, was again a period of busy activity for FreeBSD: for the second quarter in a row we have the largest report yet published. The Foundation continues to play a strong role, bringing both a developer and evangelist presence to conferences, funding much of the hardware that the cluster administration team uses to keep things running, and sponsoring many development projects for FreeBSD. This quarter we also hear from some of the student projects funded by Google Summer of Code 2015, ranging a wide gamut from the bootloader to additional ARM support, but also at a range of completion status. Some of the GSoC output is in the tree already, but others could benefit from additional attention to help out our budding new contributors as their schedules fill with the return to classes. ZFS and the network stack continue to be strong areas for FreeBSD, with both receiving active maintenance and feature improvements during this quarter. Substantial work continues on arm64, potentially putting it on the path toward a promotion to Tier-1 status, and a new port to the RISC-V architecture has made great headway in a short period of time. But it is not just our strengths and exciting new areas that have seen attention this cycle; there are also some parts of the system that are frequently perceived as unchanging infrastructure that have received attention and improvements, with truss and (k)gdb receiving significant overhauls, new implementations for the man page tools being brought in, the website receiving a new skin, and a brand new system for translating documentation that greatly lowers the barrier to entry. Nonetheless, despite its record length, this report does not and cannot cover all of the work being done on FreeBSD throughout the reporting period -- there are many bug fixes too minor to mention here, and developers too busy working on the next project to write up an entry for the previous project. It is not just the developers committing to Subversion that comprise the ongoing activities of FreeBSD, but also the users testing unreleased code or reporting bugs in released code, and participants on the mailing lists and forums helping each other solve their problems. Even the chats on IRC that wander far from the stated topic of a channel contribute to the community around FreeBSD; it is that community whose effectiveness and helpfulness is a key component of the effectiveness and usefulness of FreeBSD itself. Not just to the developers listed in this report, but to everyone in the community, thank you for making FreeBSD a great operating system. --Ben Kaduk __________________________________________________________________ Please submit status reports for the fourth quarter of 2015 (from October to December) by January 7, 2016. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * The FreeBSD Core Team Projects * automtud: Better Jumbo Frame Support * bhyve * Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 * DTrace and TCP * FreeBSD on the Acer C720 Chromebook * High Availability Clustering in CTL * Multipath TCP for FreeBSD * Porting bhyve to ARM-based Platforms * Root Remount * The Graphics Stack on FreeBSD * The nosh Project * UEFI Boot and Framebuffer Support * ZFS Code Sync with Latest Illumos * ZFS Support for UEFI Boot/Loader Kernel * Adding PCIe Hot-plug Support * Cavium LiquidIO Smart NIC Driver * CloudABI: Pure Capabilities Runtime Environment * FreeBSD Xen * ioat(4) Driver Import * IPsec Upgrades Architectures * Atomics * FreeBSD on Cavium ThunderX (arm64) * FreeBSD on the HiKey ARMv8 Board * FreeBSD/arm64 * FreeBSD/RISC-V Port Userland Programs * mandoc and roff Toolchain * pkg 1.6 * sesutil(8) * truss(1) * Updates to GDB Ports * Bringing GitLab into the Ports Collection * GNOME on FreeBSD * KDE on FreeBSD * Node.js Modules * Ports Collection * Ports on PowerPC * Xfce on FreeBSD Documentation * PO Translation Project * Website CSS Update Google Summer of Code * Allwinner A10/A20 Support * mtree Parsing and Manipulation Library * Multiqueue Testing * Update Ficl in Bootloader Miscellaneous * The FreeBSD Foundation * ZFSguru __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. Our primary cluster has been hosted as a guest in California for many years. Our ongoing project is relocating the core functionality to a location in New Jersey with a formal hosting arrangement. This is an equipment refresh, consolidation for better use of resources, and for better continuity of service. There is a significant amount of behind-the-scenes work to make this happen. The original cluster was implemented with a common, shared, assumed-to-be secure network with ubiquitous NFS everywhere. This structure does not lend itself well to being distributed across geographically diverse locations, particularly when Internet transit is required. The bulk of the work is rebuilding services to be portable, stand-alone components that do not depend on shared-network access and are safe enough to use across the insecure Internet. Highlights this quarter: * Many internal distribution systems switched from rsync to a distribution mesh using "syncthing". * We have implemented more code/data signing infrastructure with out-of-band verification. * New 32-core reference build hosts are online. * Internal admbugs switched from bugzilla 4.4 to 5.0 and packages were made available for the bugmeister team. * Finally switched from varnish3 to varnish4. * We exorcised hub.FreeBSD.org, the last survivor of the 2012 security incident. * vuxml and the legacy portaudit build system were converted to components and integrated. * https://download.FreeBSD.org/ is nearing completion (please do not use until officially announced). * A Taiwan node was brought into service for pkg, ftp, svn, and vuxml mirroring. * One of the freebsd-update mirrors was converted from lighttpd to nginx due to a data corruption bug. * We completed detachment of the svn repository from the old cluster and moved it to its new location. Ongoing: * The cluster runs a mixture of 11-current and 10-stable as part of our "eat our own dogfood" project. For this to be useful, we do monthly cluster refreshes to keep up with current code. * We build internal base system snapshots every few days and packages every day. * We also provide support for non-clusteradm-operated services including jenkins, reviews, portsnap, freebsd-update, bugzilla, package builders, git, and mercurial. This varies from as little as maintaining SSL front-ends through operating servers, distributing data or building packages/binaries to run. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 10.2-RELEASE announcement URL: https://www.freebsd.org/releases/10.2R/announce.html FreeBSD development snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ FreeBSD 10.3-RELEASE schedule URL: https://www.freebsd.org/releases/10.3R/schedule.html FreeBSD 11.0-RELEASE schedule URL: https://www.freebsd.org/releases/11.0R/schedule.html 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. In mid-August, the FreeBSD Release Engineering Team released FreeBSD 10.2-RELEASE, two weeks earlier than the original schedule anticipated. The FreeBSD Release Engineering Team would like to thank all that have tested the BETA and RC builds and reported issues during the release cycle. The FreeBSD Release Engineering Team, with approval from the FreeBSD Core Team, appointed Marius Strobl as the Deputy Lead. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The biggest task handled by the Core Team during this quarter was developing and publishing the new Code of Conduct. The Code of Conduct describes how people are expected to behave on all FreeBSD official communication channels, as well as how developers and other people involved with the project are to behave when representing the project in public. The Code of Conduct was generally well received and elicited numerous comments and suggestions for improvements from the community, many of which have been integrated. The next task handled by Core was the restoration of Babak Farrokhi's ports commit bit. Babak resides in Iran. A few years ago, legal advice suggested that allowing contributions from Iranian residents might violate US trade sanctions. After several years, Core was asked to revisit the issue. On the advice of counsel, Core decided that it could restore commit privileges to commmitters residing in Iran. The CTM service came under security review. Given that the lack of use of routine authenticity checking made the injection of trivial exploit code relatively easy, the service was held to be too risky to continue as an official part of the FreeBSD base system. CTM has very few remaining users but they should be able to install CTM from the Ports Collection in order to continue doing so. Core learned that ISC was ceasing its hosting service, which has entailed a rapid rework of plans on the movement of significant portions of the FreeBSD cluster to that data center. Cluster administration has taken ownership of the situation and is making progress. Core fielded an enquiry about NextBSD and whether this should be the future direction for the whole FreeBSD project. Core's position is that NextBSD is an interesting project, and we regard it, like the other BSD projects, as a potential source of good ideas. However, we currently have no plans to adopt NextBSD as the official FreeBSD distribution. Beyond these issues, Core also spent time in various routine activities. During this quarter we issued three new src commit bits, and took none in for safekeeping. Welcome to Allan Jude, Marcelo Araujo, and Andriy Voskoboinyk. __________________________________________________________________ automtud: Better Jumbo Frame Support Links jmgurney/automtud on github URL: https://github.com/jmgurney/automtud Contact: John-Mark Gurney The automtud script will allow a FreeBSD machine to send jumbo frames to machines that support them, while using normal-sized frames for other machines. There are various advantages to using jumbo frames, such as reduced protocol overhead. It also means that TCP streams will not be segmented as much, although TSO helps mitigate the disadvantages of such segmentation. In cases where LRO does not work well, fewer packets will be received. The script currently does not restore the system to its original state when it exits. This means that you must manually change the interface MTU and delete host routes after stopping the script. Open tasks: 1. Fix up various Ethernet drivers to better support jumbo frames. Most Ethernet drivers, though they support scatter/gather, use a physically contiguous zone to do so, which can cause resource shortages. 2. More testing is needed to ensure that things behave as expected. This means that when running the script, communication to all machines functions normally, without slowdown or connectivity issues. Check vmstat -z | grep mbuf to ensure that such issues are not due to running out of jumbo_9k or jumbo_16k buffers due to Ethernet driver issues. __________________________________________________________________ bhyve Links bhyve FAQ and talks URL: http://www.bhyve.org NE2000 device emulation GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/NE2000EmulationForBhyve Porting bhyve to ARM GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm ptnetmap support in bhyve GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/ptnetmapOnBhyve Windows support URL: http://docs.FreeBSD.org/cgi/mid.cgi?561187FB.8040506 Illumos support URL: http://docs.FreeBSD.org/cgi/mid.cgi?56118B2B.2040101 Contact: Peter Grehan Contact: Neel Natu Contact: Tycho Nightingale Contact: Allan Jude Contact: Michael Dexter bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, NetBSD/amd64, Illumos, and Windows Vista/7/8/10/2008r2/2012r2/2016 x64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. A combined bhyve and ZFS BoF was held during vBSDCon 2015, hosted by Michael Dexter and Allan Jude. Questions asked about bhyve included live migration and suspend/resume support, and configurations using ZFS. Three bhyve-related projects were selected for GSoC 2015: NE2000 device emulation, porting bhyve to ARM, and ptnetmap support. The major enhancement for bhyve this quarter was support for external firmware, along with a port of the Intel edk2 UEFI firmware. This allows bhyve to run Windows in headless mode, and also Illumos. Open tasks: 1. Improve the documentation. 2. bhyveucl is a work-in-progress script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl. 3. Add support for virtio-scsi. 4. Flexible networking backends: wanproxy, vhost-net. 5. Support running bhyve as non-root. 6. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 7. Implement an abstraction layer for video (no X11 or SDL in base system). 8. Suspend/resume support. 9. Live migration. 10. Nested VT-x support (bhyve in bhyve). 11. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 Links LLVM 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html Clang 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html PR 201377 Ports exp-run URL: https://bugs.freebsd.org/201377 Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Contact: Davide Italiano We have updated clang, llvm, lldb, compiler-rt, and libc++ in base to the 3.7.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This brings us completely up-to-date with the latest upstream versions of these projects. Meanwhile, Ed Maste is working on importing the llvm.org version of libunwind. Like the 3.5.x and 3.6.x releases, these components require C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. Currently, there are no solid plans to MFC these versions to any stable branches, due to the difficulties this would introduce for the usual upgrade scenarios. Thanks to Ed Maste and Andrew Turner for their help with this import, and thanks to Antoine Brodin for several ports exp-runs. During the first ports exp-run, some major problems were found, one introduced by a clang bug which caused pow() to generate floating point exceptions in some cases. This in turn caused libpng to fail to build, and one bug in libjpeg-turbo, which was caused by undefined behavior. These two problems took some time to fix, after which another exp-run was done, and this resulted in about a dozen newly failed ports. For almost all of these new failures, fixes were submitted and linked to the original PR 201377 for the exp-run. Open tasks: 1. Commit ports fixes for dependencies of PR 201377. 2. Test and report issues with the new tool chain. __________________________________________________________________ DTrace and TCP Links Commit adding trace points replacing TCPDEBUG URL: https://svnweb.freebsd.org/changeset/base/287759 Contact: George Neville-Neil With the advent of DTrace we are able to replace many of the internal kernel debugging options, such as TCPDEBUG, with statically defined tracepoints (SDTs). Tracepoints have now been added to the system that replicate the functionality of the TCPDEBUG kernel option. No new kernel options need to be added -- they are standard with any kernel that has DTrace, which is included in the default GENERIC kernels in 10.X and HEAD. This project is sponsored by Limelight Networks. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook Links Blog post on how to get things working URL: http://blog.grem.de/pages/c720.html Blog post with links to commits in HEAD URL: http://blog.grem.de/sysadmin/FreeBSD-On-AcerC720-Merged-2015-07-25-23-30.html Backported patch for 10.2-RELEASE URL: http://blog.grem.de/sysadmin/FreeBSD-10.2-On-AcerC720-2015-09-19-17-00. html Contact: Michael Gmelin The Acer C720 Chromebook is an affordable (under $200) and powerful little laptop that provides a battery life of up to six hours running FreeBSD. It is a great machine for travelling and coding in general. The machine is fully functional, meaning that all essential devices work: keyboard, trackpad, light sensor, backlight control, display in VESA mode (fast), external Display on HDMI (only VESA mirror mode), sound, USB ports, SD card slot, camera, and Atheros wireless. This quarter, this project extended previous work on the boot process and keyboard driver as well as the smbus(4) driver. It added three new drivers: ig4(4) for the I2C bus, cyapa(4) for the trackpad, and isl(4), for the ambient light sensor. Much of the development was originally done in late 2014. Since then, the patches have been massively improved and merged into HEAD, so that all relevant devices work without manual patching. For those who are unable to run HEAD, there is a backported patch to 10.2-RELEASE. Thanks to everyone who helped in the process. I couldn't have done it without you (you know who you are). __________________________________________________________________ High Availability Clustering in CTL Contact: Alexander Motin CAM Target Layer (CTL), when originally developed by Copan/SGI, had support for High Availability clustering. Unfortunately, significant portions of the HA code were never published with the main body of the source code. Now, the missing part has been reimplemented from scratch, fixed, and improved. This code supports dual-node HA with Asynchronous LUN Unit Access (ALUA) in four modes: * Active/Unavailable without interlink between nodes, where the secondary node can report nothing except its presence. * Active/Standby with the secondary node handling only basic LUN discovery and reservation, synchronizing state and command execution with the primary node through the interlink. * Active/Active with both nodes processing commands and accessing the backing storage, synchronizing state and command execution with the primary node through the interlink. * Active/Active with the secondary node having no backing storage access, but instead working as a proxy, transferring all commands to the first node for execution through the interlink. In the case of lost interlink connectivity to primary node, the secondary node falls into the Transitioning state, which is like Unavailable and cannot answer most requests, but makes the initiator wait for recovery or cluster failover. CTL also got a large number of other improvements, including support for emulation of CD/DVD drives and removable disks, live LUN reconfiguration, and so on. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. This project is sponsored by iXsystems, Inc.. __________________________________________________________________ Multipath TCP for FreeBSD Links MPTCP for FreeBSD Project Website URL: http://caia.swin.edu.au/urp/newtcp/mptcp/ MPTCP for FreeBSD Source Repository URL: https://bitbucket.org/nw-swin/caia-mptcp-freebsd/ Contact: Nigel Williams Multipath TCP (MPTCP) is an extension to TCP that allows for the use of multiple network interfaces on a standard TCP session. The addition of new addresses and scheduling of data across them occurs transparently from the perspective of the TCP application. The goal of this project is to deliver an MPTCP kernel patch that interoperates with the reference MPTCP implementation, along with additional enhancements to aid network research. The v0.5 patch was released, which is the first patch of the re-written implementation. We are in the process of documenting the new design and addressing some feedback as provided from the community. Work has commenced on improved input handling, as the current method of receiving and reassembling segments has been the cause of some instability and stalls during connection shutdown. This will involve re-using the subflow receive buffers and an upcall to enqueue a MP-layer reassembly task without the need to take a lock on the MP control block. The improvements should also allow bypassing mptcp_usrreq for standard TCP connections. The MPTCP commit history was synchronized with hg-beta.FreeBSD.org, and we have made the repository available on BitBucket (see links). Future patch releases will be tagged there. The tree is now merged with FreeBSD head weekly. An updated v0.51 patch is ready for release. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Release the v0.51 patch. 2. Populate documentation and the issue tracker on the BitBucket repository. 3. Improvements to receive-side code before further testing. 4. Prepare a technical report detailing the design of the current patch. __________________________________________________________________ Porting bhyve to ARM-based Platforms Links Project Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm Contact: Mihai Carabas Contact: Peter Grehan This summer we have started porting bhyve onto ARMv7 platforms. The low-level routines for ARM processors were rewritten while trying to preserve the hypervisor API originally created for the x86 architectures. We managed to bring up a FreeBSD guest up to the point of initializing interrupts. There is still work to be done in order to virtualize the interrupts and the timer. Our short-term plan after finishing the interrupts and the timer is porting to a real hardware platform (Cubie2). Open tasks: 1. Virtualize interrupts and timer. 2. Port to a real hardware platform. 3. Create SMP support for bhyve-on-arm. 4. Port to ARMv8. __________________________________________________________________ Root Remount Links Userland code review URL: https://reviews.freebsd.org/D3693 Contact: Edward Tomasz Napierala A feature long missing from FreeBSD was the ability to boot up with a temporary rootfs, configure the kernel to be able to access the real rootfs, and then replace the temporary root with the real one. In Linux, this functionality is known as pivot_root. The reroot project aims to provide similar functionality in a different, slightly more user-friendly, way. Simply put, from the user's point of view it is as simple as running reboot -r. The system performs a partial shutdown, killing all processes and unmounting the rootfs, and then partial bringup, mounting the new rootfs, running init, and running the startup scripts as usual. The kernel part of the project has been committed to 11-CURRENT. The userland part is at the "finishing touches" stage, and is expected to be committed soon. A merge to stable/10 is planned and reroot support is planned be included in FreeBSD 10.3. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics stack roadmap and supported hardware matrix URL: https://wiki.FreeBSD.org/Graphics Graphics stack team blog URL: http://blogs.freebsdish.org/graphics/ Ports development tree on GitHub URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team The Mesa ports were updated to 10.6.8. At the same time, the ports received a major overhaul to make sure all ports are correctly configured. Dual version support was removed. There is only one Mesa version for all supported FreeBSD versions. The libosmesa port, which provided the off-screen version of Mesa, was merged into the Mesa framework. Another big item that was included in the Mesa port is OpenCL. There are two GPU-based OpenCL implementations: lang/clover for supported Radeon cards, and lang/beignet for supported Intel cards (currently only Ivybridge). Thanks go to Johannes Dieterich, O. Hartmann, and Koop Mast for making this happen. Now that Mesa is up-to-date, we can apply the same update procedure to the X.Org server. It is currently at 1.14, and an update to 1.17 is ready. It will be committed shortly. On the kernel side, progress has been made with the i915 update. The driver is able to attach. There are some reports that the X.Org server starts but Mesa is unhappy, so acceleration does not work yet. If you want to test, instructions will be posted on the wiki in the i915 update article (see links). At this stage, we can only accept patches, though -- we will not be able to provide support. We attended two conferences: XDC 2015 in Toronto and EuroBSDcon 2015 in Stockholm. Reports will be posted on the blog. Open tasks: 1. See the Graphics wiki page for up-to-date information. __________________________________________________________________ The nosh Project Links Introduction and blurb URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html FreeBSD binary packages URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/freebsd-binary-packages.html Installation How-To URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/timorous-admin-installation-how-to.html Roadmap URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/roadmap.html Commands URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/commands.html A slightly outdated nosh Guide URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/index.html Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems, and for managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d system, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It comprises a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. The past few months have seen a growth in the import mechanism, with full import of /etc/fstab and /etc/ttys available in version 1.18 in July, and importing PC-BSD Warden and FreeBSD 9 jails, and full import of gbde and geli mount/unmount mechanisms in version 1.21 in October. It has also gained the ability to automatically re-generate host.conf and sysctl.conf whenever their source files change. Other developments in the past few months include fully independent shutdown support, no longer relying upon an externally provided shutdown command from another toolset, and a full suite of binary packages. As of version 1.20, it became possible to have a fully-nosh-managed system, on both FreeBSD and Linux, using just precompiled binary packages. The biggest task remaining is one that was set a while ago: the creation of enough native service bundles and ancillary utilities to entirely supplant the rc.d system. A lot of this has been achieved, with the original target list of 157 items now down to just 39 remaining. These are the tricky ones, of course, where help is most needed. Open tasks: 1. There are still a few rc scripts left that should be easy to convert, such as /etc/rc.d/gptboot and /etc/rc.d/growfs as oneshot services, /etc/rc.d/routing, and /etc/rc.d/kldxref. 2. FreeBSD's /etc/rc.d/bluetooth is over 360 lines long. In 2011, Iain Hibbert wrote a "simpler" bluetooth for NetBSD. This can perhaps be used as a simpler basis for a nosh translation. 3. Add kernel support for passing a -b option to pid 1, and support for a boot_bare variable in the loader, to allow "emergency" (where even no shell dotfiles are loaded) and "rescue" mode bootstraps, akin to Linux. (History: The -b mechanism and idea date back to version 2.57d of Miquel van Smoorenburg's System 5 init clone, dated 1995-12-03, and was already known as "emergency boot" by 1997.) 4. Add support to FreeBSD's fsck(8) for outputting machine-readable progress reports to a designated file descriptor, so that nosh can provide progress bars for multiple fscks running in parallel. nosh already provides this functionality on Linux, where fsck(8) does provide machine-readable output. 5. Identify when the configuration import system needs to be triggered, such as when bsdconfig alters configuration files, and create the necessary hooks to import external configuration changes into nosh. 6. Investigate how FreeBSD/PC-BSD could be improved by taking advantage of some available nosh package mechanisms. __________________________________________________________________ UEFI Boot and Framebuffer Support Contact: Ed Maste Contact: Marcel Moolenaar A number of UEFI bug fixes were committed over the last quarter, improving compatibility with different UEFI implementations. This includes improvements to EFI's vt(4) framebuffer driver, efifb, to handle systems with high resolution displays and unusual framebuffer stride values. In particular, this improves compatibility with a large number of recent Apple MacBook Pros and other Macs. Open tasks: 1. Test FreeBSD head and FreeBSD-STABLE snapshots on a variety of UEFI implementations. __________________________________________________________________ ZFS Code Sync with Latest Illumos Contact: Alexander Motin The ZFS codebase received a significant batch of merges, and is now in sync with the latest Illumos. Among other things, this update includes: * LZ4 is now the default compression algorithm. * Improved prefetch for faster send/receive. * Reduced RAM usage by almost 50% for L2ARC. * Improved I/O aggregation. * Fine-grained checksumming in send/receive stream. * Reduced import time for pools with many datasets. * Reworked and simplified predictive prefetcher. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. __________________________________________________________________ ZFS Support for UEFI Boot/Loader Contact: Eric McCorkle UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem, as described in the previous report. The ZFS-enabled loader.efi can be treated as a chainloader when using ZFS-enabled GRUB. During this quarter, several successful tests have been reported on simple ZFS setups, using both boot1.efi with loader.efi as well as GRUB and loader.efi. Successful tests have been reported for UFS with the patched boot1.efi and loader.efi as well. Open tasks: 1. Test reports are needed for more complex ZFS setups, such as with log/l2arc vdevs, mirroring, striping, and raidz. 2. Pending successful reports, the patch needs to be reviewed and committed. __________________________________________________________________ Adding PCIe Hot-plug Support Links PCIe Hot-plug Perforce Branch URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/pciehotplug Commit adding bridge save/restore URL: https://svnweb.FreeBSD.org/changeset/base/r281874 Github branch with patches URL: https://github.com/FreeBSDFoundation/freebsd/tree/pciehp Contact: John-Mark Gurney PCI Express (PCIe) hot-plug is used on both laptops and servers to allow peripheral devices to be added or removed while the system is running. Laptops commonly include hot-pluggable PCIe as either an ExpressCard slot or a Thunderbolt interface. ExpressCard has built-in USB support that is already supported by FreeBSD, but ExpressCard PCIe devices like Gigabit Ethernet adapters and eSATA cards are only supported when they are present at boot, and their removal may cause FreeBSD to crash. The goal of this project is to allow these devices to be inserted and removed while FreeBSD is running. This work will provide the basic infrastructure to support adding and removing devices, though it is expected that additional work will be needed to update individual drivers to support hot-plug. Current testing is focused on getting a simple UART device functional. Basic hot swap is currently functional. A set of the patches for the work done in this project is now available on github.com. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Get suspend/resume functional by saving and restoring the necessary registers. This should be addressed by r281874. 2. Make sure that upon suspend, devices are removed so that we are not fooled if they are replaced with different devices while the machine is suspended. 3. Improve how state transitions are handled, possibly by using a proper state machine. __________________________________________________________________ Cavium LiquidIO Smart NIC Driver Links LiquidIO product page URL: http://www.cavium.com/LiquidIO_Application_Acceleration_Adapters.html Contact: Stanislaw Kardach Contact: Zyta Racia This project aims to add support for the LiquidIO family of high-performance programmable accelerator 10/40-gigabit Ethernet network adapters. The currently developed kernel driver supports CN6640- and CN6880-based PCIe cards, enabling these features: * A CNNIC API for controlling/interacting with the smart NIC from user and kernel space including: + Handling multiple concurrent applications running on the same device + A request/reply mechanism for (a)synchronous ordered/unordered communication + Remote memory operations + Device shutdown/reset * A basic NIC module utilizing the CNNIC API and a Cavium-provided NIC firmware. This module provides: + Single/multi-queue TX + Hardware TCP/UDP checksum offloading + Large Receive Offload + Promiscous mode * Sysctl-based device statistics and configuration view * Custom firmware loading via user-built modules and FreeBSD's firmware(9) mechanism. The project is currently being developed in house and is being prepared for upstream. We plan on making it available in FreeBSD 11. This project is sponsored by Cavium, and Semihalf. Open tasks: 1. Upstream the code to FreeBSD head. __________________________________________________________________ CloudABI: Pure Capabilities Runtime Environment Links CloudABI project page URL: https://github.com/NuxiNL/cloudlibc CloudABI Ports Collection URL: https://github.com/NuxiNL/cloudabi-ports CloudABI presentation at FrOSCon URL: https://www.youtube.com/watch?v=LTHSZGVvLw4 Contact: Ed Schouten CloudABI is a POSIX-like runtime environment that uses Capsicum as its sole access control mechanism. CloudABI allows you to develop software that is better hardened against security vulnerabilities, is easier to test, and is easier to migrate across systems. As of August, all of the kernel modifications that are needed to run CloudABI programs have been integrated into FreeBSD head. After loading the cloudabi64 kernel module, you can either run CloudABI programs directly from the shell or by using the cloudabi-run tool (sysutils/cloudabi-utils). cloudabi-run allows you to inject sockets, files, and directories into the launched program in a more structured way. In the meantime, work has started on developing a Ports Collection that contains cross-compiled utilities and libraries for CloudABI. The intent is that this framework generates native packages for a number of operating systems, making it possible to develop CloudABI applications on any operating system, regardless of whether that operating system actually supports CloudABI. If you are interested in CloudABI, be sure to go to the project page on GitHub, watch recordings of talks at conferences, or wait for the upcoming edition of the FreeBSD Journal, which will feature an article on CloudABI. This project is sponsored by Nuxi, the Netherlands. Open tasks: 1. CloudABI is currently only available for amd64. It would make sense to port CloudABI to additional architectures like aarch64. 2. Support for CloudABI has only been integrated into FreeBSD. If we manage to upstream support for CloudABI into other operating systems, it should be possible to run the same binary on multiple operating systems without recompilation. 3. The CloudABI Ports Collection currently has only 60 packages. Although these packages already the building blocks of some interesting software, we are always interested in expanding. __________________________________________________________________ FreeBSD Xen Links FreeBSD PVH DomU wiki page URL: http://wiki.xen.org/wiki/FreeBSD_PVH FreeBSD PVH Dom0 wiki page URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Porting FreeBSD as a Xen ARM guest URL: http://www.xenproject.org/component/allvideoshare/video/latest/bsdcan-2015-how-to-port-bsd-as-a-xen-on-arm-guest.html Contact: Roger Pau Monn? Contact: Julien Grall Xen is a hypervisor using a microkernel design, providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen support for FreeBSD on x86 as a guest was introduced in version 8 and ARM support is currently being worked on. Support for running FreeBSD as an amd64 Xen host (Dom0) is available in HEAD. On the x86 front, most of the work during this quarter focused on the implementation of PVH inside Xen. Consequently, most of the activity happened inside of the hypervisor. Patches for a clean PVH implementation have been posted, with the aim of having them merged in the next Xen release (4.7). Once that is done, work will continue adding new features to both FreeBSD and Xen to have feature parity with traditional PV guests/hosts. Apart from this, work is ongoing to import a new netfront from Linux in order to support new features, like split event channel and multiple queue support. On the ARM front, this quarter's work focused on getting FreeBSD/arm64 booting as a Xen guest. The current activity is to upstream patches preparing Xen drivers to support arm64. This includes a rework of the console driver. This project is sponsored by Citrix Systems R&D. Open tasks: 1. Generalize the event channel code so it can be used on ARM. 2. Improve backend (netback, blkback) performance. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve the generic bounce buffer code for unmapped bios in order to support the alignment requirements of the blkfront driver. __________________________________________________________________ ioat(4) Driver Import Links Wikipedia article on IOAT URL: https://en.wikipedia.org/wiki/I/O_Acceleration_Technology Commit importing ioat(4) URL: https://svnweb.FreeBSD.org/base?view=revision&revision=r287117 Contact: Jim Harris Contact: Conrad Meyer A new driver, ioat(4), was added to the tree. ioat(4) supports Intel's I/O Acceleration Technology devices which are found on some Intel server systems. These devices are DMA offload engines, which can accelerate some I/O-heavy applications by offloading memory copies from the main CPU to the I/OAT unit. This acceleration is not transparent; applications must be adapted to take advantage of the hardware. Some I/OAT models support more advanced copying modes, such as XOR; these modes are not yet supported in the ioat(4) driver. This project is sponsored by Intel Corporation, and EMC / Isilon Storage Division. Open tasks: 1. Further testing, especially on a range of device models other than BDXDE (looking for volunteers here). 2. Support for the more advanced copy modes. __________________________________________________________________ IPsec Upgrades Contact: George Neville-Neil Contact: John-Mark Gurney Contact: Ermal Lu? IPsec is now enabled by default in the GENERIC kernel configuration, and work is proceeding to speed things up in various ways. The latest changes are the addition, by John-Mark Gurney, Ermal Lu?, and George V. Neville-Neil, of AES modes both in hardware and in software. Part of this work also includes more benchmarks undertaken using Conductor in the netperf project. Results have been reported at BSDCan and vBSDcon with more to come at EuroBSDcon and BSDCon Brasil. This project is sponsored by Netgate, and The FreeBSD Foundation. Open tasks: 1. Performance improvements and other tweaks are ongoing. __________________________________________________________________ Atomics Contact: Konstantin Belousov Contact: Alan Cox Contact: Bruce Evans Atomic operations serve two fundamental purposes. First, they are the building blocks for expressing synchronization algorithms in a single, machine-independent way using high-level languages. In essense, atomics abstract the different building blocks supported by the various architectures on which FreeBSD runs, making it easier to develop and reason about lock-less code by hiding hardware-level details. Atomics also provide the barrier operations that allow software to control the effects on memory of out-of-order and speculative execution in modern processors as well as optimizations by compilers. This capability is especially important to multithreaded software, such as the FreeBSD kernel, when running on systems where multiple processors communicate through a shared main memory. Each machine architecture defines a memory model, which specifies the possible effects on memory of out-of-order and speculative execution. More precisely, it specifies the extent to which the machine may visibly reorder memory accesses to optimize performance. Unfortunately, there are almost as many models as architectures. Some architectures, for example IA32 or Sparcv9 TSO, are relatively strongly ordered. In contrast, others, like PowerPC or ARM, are very relaxed. In effect, atomics define a very relaxed abstract memory model for FreeBSD's machine-independent code that can be efficiently realized on any of these architectures. Most FreeBSD development and testing still happens on x86 machines, which, when combined with x86's strongly ordered memory model, leads to errors in the use of atomics, specifically, barriers. In other words, the code is not properly written to FreeBSD's abstract memory model, but the strong ordering of the x86 architecture hides this fact. The architectures impacted by the code that incorrectly uses atomics are less popular or have limited availability, and the resulting bugs from the misuse of atomics are hard to diagnose. The goal of this project is to audit and upgrade the usage of lockless facilities, hopefully fixing bugs before they are observed in the wild. FreeBSD defines its own set of atomics operations, like many other operating systems. But unlike other operating systems, FreeBSD models its atomics and barriers on the release consistency model, which is also known as acquire/release model. This is the same model which is used by the C11 and C++11 language standards as well as the new 64-bit ARM architecture. Despite having syntactical differences, C11 and FreeBSD atomics share essentially the same semantics. Consequently, ample tutorials about the C11 memory model and algorithms expressed with C11 atomics can be trivially reused under FreeBSD. One facility of C11 that was missing from FreeBSD atomics was fences. Fences are bidirectional barrier operations which could not be expressed by the existing atomic+barrier accesses. They were added in r285283. Due to the strong memory model implemented by x86 processors, atomic_load_acq() and atomic_store_rel() can be implemented by plain load and store instructions with only a compiler barrier. No additional ordering constraints are required. This simplification of atomic_store_rel() was done some time ago in r236456. The atomic_load_acq() change was done in r285934, after careful review of all its uses in the kernel and user-space to ensure that no hidden dependency on a stronger implementation was left. The only reordering in memory accesses which is allowed on x86 is that loads may be reordered with older stores to different locations. This results from the use of store buffers at the micro-architecural level. So, to ensure sequentially consistent behavior on x86, a store/load barrier needs to be issued, which can be done with an MFENCE instruction or by any locked read-modify-write operation. The latter approach is recommended by the optimization guides from Intel and AMD. It was noted that careful selection of the scratch memory location, which is modified by the locked RMW operation, can reduce the cost of the barrier by avoiding false data dependencies. The corresponding optimization was committed in r284901. The atomic(9) man page was often a cause of confusion due to both erroneous and ambiguous statements. The most significant of these issues were addressed in changes r286513 and r286784. Some examples of our preemptive fixes to the misuse of atomics that would only become evident on weakly ordered machines are: * A very important lockless algorithm, used in both the kernel and libc, is the timekeeping functionality implemented in kern/kern_tc.c and the userspace __vdso_gettimeofday. This algorithm relied on x86 total store order (TSO) behavior. It was fixed in r284178 and r285286. * The kern/kern_intr.c lockless updates to the it_need indicator were corrected in r285607. * An issue with kern/subr_smp.c:smp_rendezvous_cpus() not guaranteeing the visibility of updates done on other CPUs to the caller was fixed in r285771. * The pthread_once() implementation was fixed to include missed barriers in r287556. This project is sponsored by The FreeBSD Foundation (Konstantin Belousov's work). __________________________________________________________________ FreeBSD on Cavium ThunderX (arm64) Contact: Dominik Ermel Contact: Wojciech Macek Contact: Zbigniew Bodek Cavium's ThunderX is a high-performance 64-bit ARMv8 CPU, available in configurations with up to 48 cores per package. ThunderX is the initial reference platform for the FreeBSD/arm64 porting effort. Additional Semihalf-sponsored work on ThunderX support brought brand new features such as: * Multi-socket operation: FreeBSD now runs on a two-node ThunderX server board with a total of 96 CPU cores! * Virtual Networking Interface Card driver: The VNIC driver consists of 4 elements (BGX, MDIO, and Physical and Virtual Functions) and is the second driver in FreeBSD to utilize SR-IOV capabilities. ThunderX is now able to use built-in networking interfaces at 1-40 Gbps. Moreover, previously introduced functionalities have been improved and committed to HEAD. This includes: * PCIe drivers for both internal and external controllers * ITS (Interrupt Translation Services) fixes * Platform-specific changes for ThunderX * Various other fixes to the kernel (PCI, UMA, etc.) The remaining features are being reviewed and will be integrated into HEAD soon. However, the GENERIC kernel already supports and runs on ThunderX. This project is sponsored by The FreeBSD Foundation, ARM Ltd., Cavium, and Semihalf. Open tasks: 1. Upstream the remaining features: 2-socket support, VNIC driver, and PCIe fixes __________________________________________________________________ FreeBSD on the HiKey ARMv8 Board Links HiKey wiki entry URL: https://wiki.FreeBSD.org/arm64/HiKey Hardware description URL: https://www.96boards.org/products/ce/hikey/ Contact: Andrew Turner The HiKey is a low-cost ARMv8 development board from the Linaro 96boards initiative. It contains a HiSilicon Kirin 6220 with eight ARMv8 cores and 1GB of ram. FreeBSD has been ported to run on the HiKey with a minimal set of drivers. As of this report, FreeBSD supports the micro-SD slot and USB host, and will boot off the SD card to multi-user mode using a recent arm64 snapshot. The kernel is missing a number of device drivers. However, it is at a usable state for people interested in testing FreeBSD on ARMv8 hardware. This project is sponsored by ABT Systems Ltd, and ARM Ltd. Open tasks: 1. A driver for SDIO and the onboard WiFi. 2. Fix the MMC driver to access the eMMC. 3. Support the USB in OTG mode. 4. Support a display via HDMI. 5. Add thermal management. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 wiki page URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Contact: Ed Maste Numerous cleanups and fixes have been applied to the arm64 kernel. This includes fixes to exception handling, asynchronous signals, ddb, and pmap. ddb has been updated to better handle accessing memory that may be unmapped. The pmap code was made more complete by implementing more functions as needed. Further work on SMP means that FreeBSD now boots on all 48 cores on the Cavium ThunderX platform. This includes adding support for the ARM GICv3 interrupt controllers and fixing the memory mapping to be shareable between CPUs. The test suite has been run on both qemu and hardware. Most of the test cases are passing, with around 30 tests either broken or failing. Work on diagnosing the issues with the remaining test cases is ongoing. This project is sponsored by The FreeBSD Foundation, and ABT Systems Ltd. Open tasks: 1. Port to more SoCs. __________________________________________________________________ FreeBSD/RISC-V Port Links FreeBSD wiki RISC-V URL: https://wiki.freebsd.org/riscv Single user boot log URL: https://people.freebsd.org/~br/riscv-singleuser.txt Contact: Ruslan Bukin Contact: Arun Thomas Contact: Ed Maste RISC-V is an open source Instruction Set Architecture (ISA) designed at UC Berkeley. It is freely available for all uses without requiring fees or license agreements. The RISC-V team intends to provide freely available BSD licensed CPU designs. Ruslan Bukin (University of Cambridge) now has FreeBSD booting to a single user shell on a RISC-V simulator. The porting effort started only two months ago and is very much a work in progress, requiring significant refactoring and clean up before it reaches a committable state. Nonetheless, this is exceptional progress in a short time. The porting effort also identified a number of proposed ISA improvements. The port currently uses the GNU tool chain (GCC and binutils), and runs on the Spike simulator. Improved RISC-V support in Clang/LLVM and related tools is highly desired. This project is sponsored by DARPA, AFRL. __________________________________________________________________ mandoc and roff Toolchain Links Heirloom doctools URL: https://github.com/n-t-roff/heirloom-doctools mandoc URL: http://mdocml.bsd.lv/ Contact: Baptiste Daroussin mandoc is a suite of tools for compiling mdoc, the roff macro language of choice for BSD manual pages. mandoc is the default renderer for manpages on FreeBSD head. This quarter, the apropos(1) utility was switched to use mandoc's version, which offers a new database format (in SQLite) bringing more powerful, fine-grained ways to search man pages. While mandoc is very good for man pages, we also provide lots of other documentation in plain roff format. The Heirloom toolchain is being studied to replace groff in base. The Heirloom nroff toolchain has multiple benefits: it has very good unicode support and very good compatibility with groff. A great deal of work as been done testing the Heirloom nroff toolchain with all the roff documents in the base system (including man pages), and upstream has been very proactive in fixing reported bugs. The soelim(1) utility has been replaced with a BSD-licensed version which is good enough to work with all available roff toolchains to ease the transition. This version of the soelim(1) utility, originally written solely for FreeBSD, is now part of the mandoc tool suite. In coordination with Ingo Schwarze from OpenBSD, the col(1) utility has been cleaned up and updated to recognize both SUSv2-style escape-digit and BSD-style escape-control-char sequences in the input stream. The checknr(1) utility has been cleaned up and extended to support modern roff(7) macros, including synchronizing code from NetBSD and the Heirloom doctools version. Many roff fixes were made to documentation and man pages, having been discovered while testing the new toolchain. __________________________________________________________________ pkg 1.6 Contact: FreeBSD pkg Team pkg 1.6.0 has been released. Many changes have been made since pkg 1.5: * The dependency solver is greatly improved * Lots of fixes in the three-way merge code * pkg add can now work without a version specified in the dependency line * pkg check -d now also checks the required libraries * Improved support for partial upgrades * Improved zsh completion support * Improved Linux support: all regression tests now pass on Linux * Messages can now be context-aware, showing a given message always, or only during installation, upgrade (conditional on the previous version), or removal * @keywords now accept new entries to add context-aware messages * Added the ability to generate graphiz's dot format representation of the solver's problem * pkg search now defaults to showing the pkg-comments of the matched packages * Lots of bug fixes and code cleanup * Improvements in cross-installation support Open tasks: 1. Add a notion of priority to the list of files to ensure that certain files are the first to be replaced. This was a blocker for packaging base. 2. Investigate replacing openssl by mbedtls. __________________________________________________________________ sesutil(8) Links Wikipedia: SCSI Enclosure Services (SES) URL: https://en.wikipedia.org/wiki/SCSI_Enclosure_Services Contact: Baptiste Daroussin Contact: Allan Jude sesutil(8) was originally created as a more universal way to blink the "locate" LEDs on most hot-swappable drive enclosures. This work is based on the original SES tools created by Matthew Jacob in 2000, which have been available in the share/examples section of the source tree, but were not built by default. The new utility extends the original code with a number of very useful features: * Print a map of all objects connected to the SES controller * Map device names (/dev/da5) to SES slot number * Blink the Locate and/or Fault LED of a drive by its SES slot number or device name * Check the status of the entire SES controller This project is sponsored by Gandi, and ScaleEngine Inc.. Open tasks: 1. Test sesutil(8) against more hardware. 2. Diagnose an issue where the locate command sometimes needs to be sent twice to activate the LED. 3. Add support for libxo output types. __________________________________________________________________ truss(1) Contact: John Baldwin Contact: Bryan Drewery The interface between the ABI-specific backends and the truss core was refactored, reducing duplicated code. This prompted additional follow-on work to add support for more ABIs, including aarch64 and CloudABI. ptrace(2) was extended to return more information about the currently executing system call. This restored behavior that had been present in a previous version of truss: knowing the correct number of arguments for all system calls. The fork-following support in truss was reworked to use native fork following in ptrace(2) rather than forking a new truss process for each child of a traced process. Support for decoding more arguments has been added in the last quarter as well. Open tasks: 1. Create a new libsysdecode library to hold shared code between truss(1) and kdump(1). 2. Decode more system call arguments. 3. Add appropriate system call decoding specifications for freebsd32 system calls. 4. Implement an ABI for 64-bit Linux binaries under FreeBSD/amd64. __________________________________________________________________ Updates to GDB Links Extend libkvm to support cross-debugging of vmcores URL: https://reviews.FreeBSD.org/D3341 Contact: John Baldwin Support for following children after forks for FreeBSD was implemented and merged upstream to GDB's master branch, and was included in GDB 7.10. Work has continued on porting kgdb to newer gdb. The amd64, i386, powerpc, powerpc64, and sparc64 backends have all been ported and are now available via a new KGDB option in the devel/gdb port. The MD backends for libkvm have been rewritten to support cross-debugging crashdumps, and the kgdb targets for amd64 and i386 have been reworked to support cross-debugging. Both i386 and amd64 kgdb binaries have been able to cross-debug the other architecture's vmcores with these changes. This changeset for libkvm is not yet in the tree, but is awaiting more testing. Open tasks: 1. Test the libkvm changes on platforms other than amd64, i386, and powerpc64. 2. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 3. Add support for more platforms (arm, mips, aarch64) to upstream gdb for both userland and kgdb. 4. Write a new 1:1-only thread target for FreeBSD that can be sent upstream. 5. Add support for debugging powerpc vector registers. __________________________________________________________________ Bringing GitLab into the Ports Collection Links PR for the new port URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=202468 Installation guide URL: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md GitLab Source Tree URL: https://github.com/gitlabhq/gitlabhq/ Contact: Torsten Z?lsdorff Contact: Michael Fausten GitLab is a web-based Git repository manager with many features, used by more than 100.000 organizations, including NASA and Alibaba. It also is a very long-standing entry on the "Wanted Ports" list on the FreeBSD Wiki. In the last month there was steady progress, finally resulting in the PR for adding the new port. In addition to the many dependencies Philip M. Gollucci is working on, there was already a large amount of work done. Along with many new or updated rubygems, Rails 4.1 was resurrected. A large group of committers were involved in the process and guided us through the various problems and pitfalls. Because of the number of dependencies -- we nearly hit 100 -- making progress takes some time. In the meantime, a new major version of GitLab has already been released, requiring even more dependencies and updates. Work on this version is in progress, but the first goal is to get the latest stable version from the 7.14 branch into the ports tree. This project is sponsored by anyMOTION GRAPHICS GmbH, D?seldorf, Germany. Open tasks: 1. Closing all the PRs of the dependencies 2. Committing the GitLab port itself 3. Updating the port to the latest version of the 8.x branch __________________________________________________________________ GNOME on FreeBSD Links FreeBSD Gnome website URL: http://www.FreeBSD.org/gnome Devel repository URL: https://github.com/freebsd/freebsd-ports-gnome Upstream build bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/using-gnome.html Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter, GNOME 3.16 and MATE 1.10 were committed to the ports tree, followed up by some incremental improvements. A chapter covering the use of USE_GNOME within individual ports' Makefiles was written and committed to the Porter's Handbook. GNOME 3.18 has been ported. There are, however, some issues that need to be resolved before it can be committed to the ports tree. Open tasks: 1. The FreeBSD GNOME website is stale. Work is under way to improve it. 2. Please give feedback on and suggest improvements to the chapter in the Porter's Handbook on the USE_GNOME functionality. 3. Continue working on investigating the issues blocking GNOME 3.18. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD website URL: https://freebsd.kde.org/ KDE ports staging area URL: https://freebsd.kde.org/area51.php KDE on FreeBSD wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD mailing list URL: https://mail.kde.org/mailman/listinfo/kde-freebsd Development repository for integrating KDE 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Contact: KDE on FreeBSD team Overall, we have updated the following ports this quarter: * CMake 3.3.1 (r396266) * Qt 4.8.7 (r397043) * QtCreator 3.5.0 (r395935) * Fixed some dependencies, typos and plists in Qt5-ports (r396044-r396047), spotted by Ralf Nolden In our development repository, we have done the following work: * Updated PyQt-bindings for qt4 to 4.11.4 and added qt5 bindings 5.5, contributed by Guido Falsi, and modified by Tobias Berner (area51) * Updated qt5 to 5.5.0. Ralf Nolden has contributed a handful of useful new ports, for example lang/qt5-l10n (area51/qt-5.5) * The plasma5 branch has been kept up to date with KDE's upstream and contains ports for Frameworks 5.14.0, Plasma Desktop 5.4.2 and Applications 15.08.1 (area51/plasma5) Open tasks: 1. Work on getting the stuff from plasma5 branch into ports. (This is a major update to nearly all KDE applications, so testers are very welcome.) 2. Finalize the work on PyQt5. 3. Port qt5-webengine. Qt-5.5 will probably be the last release shipping a www/webkit-qt5 port. __________________________________________________________________ Node.js Modules Links Node.js modules URL: https://www.assembla.com/spaces/cozycloud/subversion/source Pre-draft documentation URL: https://people.FreeBSD.org/~olivierd/porters-handbook/using-nodejs.html Contact: Olivier Duchateau Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. The goal of this project is to make it easy to install the modules available in the npm package registry. Currently, the repository contains more than 100 new ports, in particular: * CoffeeScript (a programming language that transcompiles to JavaScript) * node-gyp (allows building Node.js addons, often written in C or C++) * Request (a simplified HTTP client) We have also written several helpers for the porting, available in our experimental repository. Open tasks: 1. Bring in grunt.js (and modules), the JavaScript task runner. 2. Put more effort into support for node-gyp in the USES framework __________________________________________________________________ Ports Collection Links Ports Collection website URL: http://www.FreeBSD.org/ports/ Contributing to the Ports Collection URL: https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html Port Monitoring service URL: http://portsmon.FreeBSD.org/index.html Team Website URL: http://www.FreeBSD.org/portmgr/index.html Blog URL: http://blogs.freebsdish.org/portmgr/ Twitter feed URL: http://www.twitter.com/freebsd_portmgr/ Facebook page URL: http://www.facebook.com/portmgr Google+ page URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Ports Management Team As of the end of Q3 the ports tree holds just over 25,000 ports, and the PR count is above 2,000. The summer period saw less activity on the ports tree than during the previous quarter, with fewer than 7,000 commits performed by 120 active committers. Unfortunately, the number of problem reports closed also decreased significantly, with fewer than 1,500 problem reports fixed during Q3. In Q3 several commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (fluffy), or on committer's request (xmj, stefan, brix). One new developer was granted a ports commit bit (Jason Unovitch junovitch@FreeBSD.org), and one returning committer (Babak Farrokhi) had his commit bit reinstated. On the management side, no changes were made to the portmgr team during Q3. On the QA side, 25 exp-runs were performed to validate sensitive updates or cleanups. Amongst those, the noticeable changes are the update to pkg 1.6, the automake14 removal, and several important port updates such as doxygen to 1.8.10, gnome3 to 3.16, cmake to 3.3.1, and the Qt4 ports to 4.8.7. The default jdk was also set to openjdk8. Some infrastructure changes included the addition of new options helpers: opt_VARS, opt_VARS_OFF, opt_IMPLIES, and opt_PREVENTS. Some macros were also removed, such as UNIQUENAME and LATEST_LINK. Open tasks: 1. We would like to remind everyone that the ports tree is built and run by volunteers, and any help is greatly appreciated. This is more important than ever, since the number of problem reports cannot seem to stop increasing. So if you use ports or packages, please consider jumping in and helping! This is also true for existing porters: it would be great if you would consider the next step, which is to share your knowledge and mentor someone more junior with the ports tree internals. And if you already do these tasks, many thanks to you! __________________________________________________________________ Ports on PowerPC Contact: Alexey Dokuchaev The Ports Collection typically receives less attention on Tier-2 architectures than on Tier-1 architectures, although several build-runs were performed at various points in the past, and broken ports were marked as such at those times. Some of the Tier-2 platforms, such as PowerPC and ARM, have improved considerably recently, both on FreeBSD's and the compilers' sides, but as the tree is not rebuilt on the cluster very often, it was suspected that many ports are marked BROKEN while they in fact now build and run correctly. Over the past several weeks, 26 ports that were indeed broken on at least PowerPC had been fixed, 58 ports that were incorrectly marked as broken (leftovers from the old times) were marked as working, and fewer than 40 ports still have issues requiring further work. Open tasks: 1. The Ports Collection could benefit a lot from more frequent sweeps targeting Tier-2 systems. 2. Recent work on QEMU-backed emulators and the much-anticipated cross-building of ports are essential pieces to bring FreeBSD packages on par with the base system's support, architecture-wise. __________________________________________________________________ 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: * science/xfce4-equake-plugin 1.3.8 * sysutils/xfce4-power-manager 1.5.2 * x11/libexo 0.10.7 * x11/xfce4-embed-plugin 1.6.0 * x11/xfce4-verve-plugin 1.1.0 * x11/xfce4-whiskermenu-plugin 1.5.1 * x11-wm/xfce4-desktop 4.12.3 * www/midori 0.5.11 We also follow the unstable releases (available in our experimental repository) of: * sysutils/xfce4-panel-switch 1.0.2 (utility to backup panel layouts) * x11/xfce4-dashboard 0.5.1 In the trunk branch, x11-wm/xfce4-panel contains a patch to support sysutils/xfce4-panel-switch (available through the panel preferences). Open tasks: 1. Test the new stable release of GLib 2.46.x with the kqueue/kevent backend enabled (it was disabled with revision r393663). Currently several features are broken, especially in Thunar, xfce4-panel, and Xfdashboard. __________________________________________________________________ PO Translation Project Links PO Translations URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/fdp-primer/po-translations.html German translation of the Leap Seconds article URL: https://www.FreeBSD.org/doc/de_DE.ISO8859-1/articles/leap-seconds/ Dutch translation of the Explaining BSD article URL: https://www.FreeBSD.org/doc/nl_NL.ISO8859-1/articles/explaining-bsd/ FreeBSD Translators mailing list URL: https://lists.FreeBSD.org/pipermail/freebsd-translators/ Contact: FreeBSD Documentation Team Contact: FreeBSD Translators Contact: Warren Block The FreeBSD documentation translation process has been in need of modernization for quite some time. The existing process was just too difficult for translators to keep translations up to date. With help from Benedict Reuschling, Shaun McCance, Ryan Lortie, Hiroki Sato, and many others, the availability of a new PO translation system was announced in August. PO translations handle most of the overhead of the translation process. Translators do not have to keep track of commits to the upstream English version. The actual work of translating is quicker and easier. PO editors show how much of the document has been translated. If a translation is already available for a given string, it can be easily reused. Early testing has been very successful. Most issues involve discovering and documenting the new processes rather than fixing bugs. New translations of English documents have already been committed. There will certainly be additional changes and improvements, but the system works. We will continue to discover how to share work between translation teams and the project as a whole. This work will be much easier now that the initial hurdle of being able to use PO software has been passed. Open tasks: 1. Continue testing. The system is new to us and there are bound to be bugs and situations with unexpected results. 2. Improve documentation on using the new PO translations. Much of this involves things that rarely happened with the old system, like adding a completely new language directory. 3. Add new translations for existing documents. There is much less work to create and update a translated document now. Existing and new translators are working on adding and updating translations of the English documentation. 4. Figure out how to generate and share translation memory with other members of a language team or translators outside the team. 5. Test new PO editors like Pootle and Virtaal. 6. Determine a method to allow translators commit access for translations. 7. Develop and test code to translate manual pages. __________________________________________________________________ Website CSS Update Links FreeBSD Main Site URL: https://www.FreeBSD.org/ Contact: Warren Block The FreeBSD website has remained essentially unchanged in appearance for many years. Like other legacy systems, it is difficult to change. It is heavily used and therefore subject to non-trivial bikeshedding. The CSS shrunk the reader's font from the size they had requested. It specified hardcoded font and object sizes in pixels. On wide monitors, only the middle third of the screen was used. Hardware has changed from what existed when this version of the site was created. Screens have become larger and wider, and increased in resolution at the same time. It was time for a change. Font sizes were set to percentages, with none smaller than 100%. The width of the main box was changed to 90%. Other small adjustments were added. These limited changes produced a rendered site that better respects the reader's settings, is much easier to read, and shows more information. Although no content changed, the appearance was so different that some viewers thought we had redesigned the site. It is gratifying to know that so many people are using it. We would also like to thank people for the response, which was overwhelmingly positive and hardly bikesheddy at all. Open tasks: 1. Fix other outdated assumptions in the CSS. Alternately, rework the entire site. However, that is a much more complex and ambitious project than it might seem. __________________________________________________________________ Allwinner A10/A20 Support Links Wiki page URL: https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner Contact: Luiz Otavio O Souza Contact: Pratik Singhal The Allwinner A10 and A20 chips are ARM CPUs found in increasingly common development boards and other devices, such as the Cubieboard/Cubieboard 2 and the Banana Pi. With the end of a GSoC project by Pratik Singhal, our A10 and A20 support has improved. Pratik helped with the implementation and testing of the SD card and SATA support for the Allwinner chips. Luiz Otavio O Souza added support for the dwc network interface on the A20, which is capable of gigabit speeds. Glen Barber kindly added support for official FreeBSD images for Cubieboard 2 and the Banana Pi. This project is sponsored by Google Summer of Code 2015 (partly). Open tasks: 1. Some drivers are still missing: audio, video/HDMI/framebuffer, IR, I2C, SPI, PWM. 2. Fix if_dwc for better performance. __________________________________________________________________ mtree Parsing and Manipulation Library Links Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/mtreeParsingLibrary Contact: Michal Ratajsky Contact: Brooks Davis FreeBSD includes several programs that work with file system hierarchy descriptions in the mtree(5) format. These descriptions, also called specifications, have a broad range of uses, from automatically creating directory structures to security auditing. Each of the programs, namely mtree, bsdtar, install, and makefs, has its own implementation of the mtree format. This not only adds maintenance overhead, but also makes interoperability difficult, as each of the implementations only supports a limited subset of the format. The goal of this project was to create a new libmtree library, implementing everything the mtree format has to offer, and wrapping it with an expressive API which all the listed programs can use. We also wanted libmtree to be portable, as one of the major users of the mtree format is libarchive, the library implementing most of bsdtar. Currently, the library is functionally complete, ready to be downloaded and receive everyone's attention. We have also decided to bundle the mtree program along with it. The bundled mtree has also been modified for better portability. The project included modifying libarchive, install and makefs to use libmtree. These modified versions are also available. Please see the Wiki page for more information, download locations, and an example of using the libmtree API. This project is sponsored by Google Summer of Code 2015. Open tasks: 1. Test and review the library code and API, and the modifications made to the programs. 2. Fix the known problems that are mentioned on the Wiki page. __________________________________________________________________ Multiqueue Testing Links Project Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/MultiqueueTestingProject Contact: Tiwei Bie Contact: Hiren Panchasara Contact: George Neville-Neil Contact: Robert Watson The aim of this project is to design and implement infrastructure to validate that a number of the network stack's multiqueue behaviours are functioning as expected. At present, most of this project has been implemented. It mainly consists of two parts: 1. A general mechanism to collect the per-ring per-cpu statistics that can be used by all NIC drivers, and extensions to netstat(1) to report these statistics. 2. A suite of network stack behavior testing programs that consists of: + a virtual multiqueue ethernet interface (vme) + a UDP packet generator based on vme + a UDP server based on socket(2) + a TCP client based on lwip and vme + a TCP server based on socket(2) However, it still needs further refinements to make it suitable for committing to FreeBSD head. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ Update Ficl in Bootloader Links Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/UpdateFiclInBootloader Contact: Colin Lord The FreeBSD bootloader has used Ficl 3 for quite some time. This project was intended to update the version of Ficl in use to Ficl 4. Ficl 4 is not only faster but also has a smaller memory footprint, both being important advantages for a bootloader. As part of the Google Summer of Code program, I worked on importing the Ficl 4 sources to get a bootloader running Ficl 4. The first half of the summer consisted of setting up my test environment, as well as arranging the sources in the tree properly and modifying the build files to point to the new locations. Once that was complete, the sources had to be modified to build correctly and to add back in some of the FreeBSD-specific parts from Ficl 3. Unfortunately, after all those tasks were completed, a few bugs in the Ficl project were discovered that delayed the bootloader update, so it is not finished. The Illumos project has faced similar issues with Ficl 4 so I received some good tips from them, but since school has started back up I have not been able to put much work into fixing the bugs. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ The FreeBSD Foundation Links Foundation website URL: http://www.FreeBSDFoundation.org/ FreeBSD Journal URL: http://freebsdjournal.com/ 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 development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also 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: Anne Dickison and Deb Goodkin attended OSCON to promote FreeBSD. Robert Watson organized and ran the Cambridge FreeBSD Developer Summit 2015 ("BSDCam"). We provided travel grants to two FreeBSD developers to attend the summit. Three Foundation board/staff members attended too. George V. Neville-Neil attended the ARM Partner Meeting where he met with 15 silicon and systems vendors to present the unique traits and qualities of FreeBSD and work on setting up partnerships with the companies building and deploying ARM hardware. George and Robert Watson collaborated in Cambridge on developing further FreeBSD-based teaching material at undergraduate and masters levels. Part of this project was funded by the Foundation. George planned and ran the DevSummit at vBSDCon 2015. We were proud to be a sponsor of vBSDCon 2015, Sept 11-13 in Washington DC. George V. Neville-Neil and Ed Maste presented "Supporting a BSD Project" at the conference. Dru Lavigne, Glen Barber, George V. Neville-Neil, and Ed Maste attended and represented the Foundation at both vBSDCon and the FreeBSD Developer Summit that preceded it. We had many people stop by our table to make a donation, and it was another great opportunity to talk and work with people face-to-face. Cheryl Blain and John Baldwin promoted the Foundation and FreeBSD at the SNIA 2015 Storage Developer Conference, in Santa Clara, California, Sept 21-24. The Foundation was also a sponsor. We sponsored Andy Turner to attend Linaro Connect in San Francisco, Sept 21-25. Ed Maste, our project development director, attended the X.Org Developer's Conference (XDC) in Toronto, Ontario. We sponsored the 2015 nginx Conference and sent FreeBSD community member John Baldwin. George Neville-Neil continued planning the 2015 Silicon Valley Vendor Summit, including securing the venue. Benedict Reuschling and Erwin Lansing helped plan and organize the EuroBSDCon FreeBSD Developer Summit. This included setting up the working groups, securing the venue, and getting the T-shirts made. Benedict helped organize, and he and Dru Lavigne participated in the FreeBSD Hackathon in the Linuxhotel in Essen, Germany. It was a successful weekend of fixing bugs and collaborating with others. Dru Lavigne taught a FreeBSD class in Berlin, Germany July 29-31. We were a sponsor of womENcourage 2015, in Uppsala Sweden, Sept 24-26. Dru was the moderator for a panel on Open Source as a Career Path. All the panelists were FreeBSD contributors including Dan Langille, Allan Jude, Benedict Reuschling, and Deb Goodkin. We also had a table at the job fair and talked to a lot of students and professors about the benefits of working on FreeBSD as an alternative to an internship, teaching about FreeBSD in university classes, and hosting FreeBSD events at their schools. Dan taught a workshop on How to Contribute to an Open Source project. Deb participated in this workshop and started a discussion on offering a similar workshop at BSD and non-BSD conferences. The workshop would be titled "How to Contribute to FreeBSD", and participants would learn how to contribute documentation to the Project. We continued to publish our monthly newsletters, keeping the community informed on what we are doing, including event recaps, testimonials, project updates, and upcoming events. We received testimonials from Microsoft, NYCBus, and ScaleEngine. We also continued to approach companies to provide us with testimonials to help promote their use of FreeBSD. Anne Dickison rebooted the Faces of FreeBSD series and is working with FreeBSD contributors on writing their stories. She continued to produce more FreeBSD Swag and literature to promote FreeBSD, as well as advocating for FreeBSD over our social channels and with new partnerships. We reached our 2015 goal of 10,000 FreeBSD Journal subscribers, and we published a new Open Journal article on our website, to help promote the Journal. We also started offering a new subscription bundle, where you can buy all the 2014 issues. The July/August issue was published. Justin T. Gibbs began teaching a semester-long FreeBSD class at a middle school in Boulder, Colorado. We are using the BeagleBone Black (BBB) to run FreeBSD connected to Macs and PCs. We have received a lot of support, both internally, and from the Project, to get the FreeBSD images to work on the BBB with the Macs and PCs. It has been a great collaborative effort with community members, and this will help future classes in being able to support inexpensive platforms for teaching FreeBSD. Work continued on creating a FreeBSD curriculum for a half day workshop. Hopefully this will be available in late Spring. We provided legal support for the Project including granting trademark permission for some users and companies who requested permission to put the FreeBSD logo on their websites and marketing literature. We met with commercial users to get their input on what they would like to see supported in FreeBSD. We also do this to help connect FreeBSD developers with commercial users to help facilitate collaboration. FreeBSD Foundation employee and Release Engineer Glen Barber was extremely busy during this quarter, working on a number of exciting areas of the FreeBSD Project. Some of the highlights include: * Code cleanup and bug fixes to several parts of the release build code, and finishing adding support for automatically uploading cloud provider images, which was merged to the stable/10 branch before the code freeze. The 10.2-RELEASE cycle spanned a 9-week timeframe overall, starting from the code slush. * With the FreeBSD Release Engineering Team, released two BETA builds and three RC builds for the 10.2-RELEASE cycle, with the final release announced mid-August, two weeks ahead of the original schedule. * With the FreeBSD Cluster Administrators Team, assisted with a number of general updates and enhancements to the FreeBSD infrastructure. __________________________________________________________________ ZFSguru Links Home page URL: http://zfsguru.com Forum post on Gnome 3 debugging URL: http://zfsguru.com/forum/zfsgurudevelopment/1038 Contact: Jason Edwards ZFSguru started as a front-end to ZFS but has since grown into a multifunctional server appliance with its own unique features. While the project is still in early development, it already offers multiple unique features not found in other projects. Unlike similar projects, nothing is stripped away from the base operating system, meaning ZFSguru behaves as a normal FreeBSD installation and thus is very versatile. The web-interface is designed to unite both novice and advanced users, providing both very easy to use basic functionality as well as features to be appreciated by more experienced users. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. On the 15th of August, version 0.3 of ZFSguru was released. Some highlights of the new version: * New build infrastructure allows for frequent releases of system images and services in a semi-automated way. * A new GuruDB database allows for a growing number of system images and servers, and provides good caching to accelerate pages. * The installation procedure was given a major overhaul. * In addition to the LiveCD, USB images are now available. The USB image supports both legacy MBR bootcode and UEFI boot. * Many libraries in the web-interface have been overhauled, in addition to many other additions to the web interface. * Many improvements were made to optional add-on services, such as the new Gnome 3 graphical environment. Other progress made in the months July, August, and September: * System image builds 001, 002, 003, and 004 have been released for all supported branches: 10.0, 10.1, 10.2, 10.3 (-STABLE), and 11.0 (-CURRENT). * Work on the 0.4 web-interface has started, which focuses on improving network support in the web-interface. * Work on a new visual theme for the web-interface has started. The new interface is likely to be included in the upcoming 0.4 release. * A new master server is being prepared, which is likely to be operational in December. * A new website is being worked on, to be launched the first of January, 2016. Open tasks: 1. The new Gnome 3 desktop does not work for everyone and still has issues. Anyone capable of diagnosing these issues can give the Gnome 3 LiveCD a try. Please see the linked forum thread for more information. 2. Several ports fail to compile with our own build infrastructure, and require bug reports in order to get them fixed upstream. 3. A 'State of the Project 2015' is due in Q4, providing an overview for future development of the project. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJWLZXJAAoJECjZpvNk63US9QkMIIp+DgtLqA1bt02ldMvtOQi8 UX2TkKTHJrJLtSl5Iv5JUJ9IaZR1gYRkTYS0vINCOMXwTsp3y+xb6ESiR5H0iJRF Jnw5gy8HBi8ZY+MLasFG/KdYTcIUVcfUxloak96FFDOA23ru+LWy4t8YxMMiBIde xnebJXxoKo1RxCePbbAyS6vri/jvP9KZth8rE0V8CgUbFo3IuROMrvYS7jVhzhrL yOJn2vER6LXEM8j11c8RYMNOtSrwCLrO2CI5u2frTAvPXEXPLx4WSX/Gw0R3mVS/ l12bjBK3i89q2XWiiglbXiMxK3JBHKtIZZowHwHCCwhgd2cxEHiP3XaKFtxFlQ1c Isk4hHp/rbzozdG6HX9m52Qg90ieQXjcCoJ46apV50VLK4eSe+WdD1/mhC8VE7GU o3Ako+zJlUnW9SKY82YG2ENQFqa2/CPEDM6N/l7cFqD9ixaNLWBjR1fJ3b2cvKiS m3nbMHPeJnNTMo83l9RNoZm0jGvNLikW+f47yjuoTXbFb54= =0xZT -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Mon Oct 26 20:27:21 2015 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 D60DCA1E804 for ; Mon, 26 Oct 2015 20:27:21 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD4B1E15 for ; Mon, 26 Oct 2015 20:27:21 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: by wicll6 with SMTP id ll6so131436139wic.0 for ; Mon, 26 Oct 2015 13:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=+jSEOzfcBkcQB0ntOAPDPYG+nzS5OmMXYq/flYxhaBI=; b=piKr5tVXDKvWm1G9ZGJDzNceklkMIhhdPyYhVXsbnEVa4Y4EjWqAGp8uZnZRuICt4/ C5NdYIubtHXf9aIGnyB4B7KWWjiqg6PxsWsivVBi4K2o5OIBapT94z4Fy4TNyl+w+48O QqTMNdXF7Ev+mdNFaGBmzQ+tX46mRh5j5nrZPXxBvJT+pDTGQzN6DtJEvriKFDfVCsp9 qcTZJGwxBb5koZRr+l1SGSbakh/FQO6sgI6OkgSc/MQhmAvk0KW9SCMQQhOMTGLx8tpA XiTH7/iaxQYHnSIsFQdbf4y5mZU3kO+42P0dmPKPxWkvOUCcz0gAWFTDWQLW0kdwGOLr xJZA== X-Received: by 10.194.88.69 with SMTP id be5mr23960796wjb.125.1445891239896; Mon, 26 Oct 2015 13:27:19 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by smtp.gmail.com with ESMTPSA id r9sm40928581wjz.35.2015.10.26.13.27.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Oct 2015 13:27:18 -0700 (PDT) From: Alban Hertroys Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: hostapd loses connectivity on ath0 Message-Id: <61705059-E85C-4887-BBCD-D2690D27D24A@gmail.com> Date: Mon, 26 Oct 2015 21:27:17 +0100 To: freebsd-stable Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 20:27:22 -0000 At random times my devices suddenly fail to connect to Wifi on my ath0 = device. Issueing /etc/rc.d/hostapd restart usually resolves the issue, = but at some point that also hung. Shutting down to single user mode in the hung state only partially = succeeded, in the sense that ifconfig, hostapd and a few other = network-related processes kept "running" - I assume the hangup of = hostapd was caused by a hung process somewhere in that tree. The system is: uname -a FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 r286718: = Thu Aug 13 10:00:32 CEST 2015 = dalroi@solfertje:/usr/obj/usr/src/sys/ANTELOPE amd64 It's quite possible that I've misconfigured something, so here's the = relevant lines of my configs=E2=80=A6 rc.conf: # Outside interface ifconfig_fxp0=3D"DHCP" ifconfig_fxp0_ipv6=3D"inet6 accept_rtadv" # Wireless wlans_ath0=3D"wlan0" create_args_wlan0=3D"wlanmode hostap" ifconfig_wlan0=3D"mode ng channel 9:ht/40" ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv" # Bridged interfaces (see example at man 4 bridge) cloned_interfaces=3D"bridge0" ifconfig_bridge0=3D"addm em0 stp em0 addm wlan0 stp wlan0 up" ifconfig_bridge0_alias0=3D"inet 10.236.150.1/24" ifconfig_bridge0_ipv6_alias0=3D"inet6 fe80::6efd:b9ff:fe68:db36%bridge0" # Internal wired ethernet (should that be above the bridge declaration?) ifconfig_em0=3D"up" ifconfig_em0_ipv6=3D"inet6 accept_rtadv" hostapd_enable=3D"YES" #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D hostapd.conf: interface=3Dwlan0 driver=3Dbsd debug=3D1 ctrl_interface=3D/var/run/hostapd ctrl_interface_group=3Dwheel ssid=3Dfoo country_code=3DNL ieee80211d=3D1 hw_mode=3Dg wpa=3D2 wpa_passphrase=3Dnonononono wpa_key_mgmt=3DWPA-PSK wpa_pairwise=3DCCMP The ath0 device is: pciconf -lv ath0 =20 ath0@pci0:5:6:0: class=3D0x028000 card=3D0x0300168c = chip=3D0x002d168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9227 Wireless Network Adapter' class =3D network In case it's relevant: All connected devices get their IPv4 addresses = through DHCP from this machine, the machine itself gets it's IPv4 = external address from my upstream provider, the internal addresses are = hardwired per interface. DHCP is configured to use hostnames (instead of = IP's) that get looked up in Bind9 on the same machine. Google did find some people on the internet with apparently the same = problem, but nobody seems to have found (or posted) a resolution. Am I doing something wrong? If not, is this a known issue? What's the = next step? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@freebsd.org Mon Oct 26 21:10:44 2015 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 29496A1E394 for ; Mon, 26 Oct 2015 21:10:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 EA6F71377 for ; Mon, 26 Oct 2015 21:10:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbhv6 with SMTP id hv6so65921388igb.0 for ; Mon, 26 Oct 2015 14:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PTKj9sx7fZr/tdcOhKiilWmHaculbQmIPWSOXDDaZxA=; b=BfhSXAC98J/uCGY8rS0lJRUT7z9Wst3BpLz+kDNLsCLsjaay7t2A3VXF+oGoeTqdZq PvmjJFcmcSxBQrYCjpmfIdt/pIwb/Bm+HsgzyMfagneu4YgyxLHiLRAbdLi2WUk0nQEd q1o0Xh+6bnvTRxM43uFWFZ5pT2vkXndG+UUk/JeSR0k5pCKMnggP9huN+23joL08T32a OqtNy+mIKIY4llPvwd6ICvOtarmbxa4Cf5ShroXcJMz9uGF4lm+u3zpgk+FavWLxokB7 aLEoDzr+WwOA8yo1MRIDh/xeMhgwaPT1oj5Trs5DsDWzF6IPrq3ybuCGuSx7IRNt9wUf VMsQ== MIME-Version: 1.0 X-Received: by 10.50.61.243 with SMTP id t19mr20195500igr.22.1445893843008; Mon, 26 Oct 2015 14:10:43 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 14:10:42 -0700 (PDT) In-Reply-To: <61705059-E85C-4887-BBCD-D2690D27D24A@gmail.com> References: <61705059-E85C-4887-BBCD-D2690D27D24A@gmail.com> Date: Mon, 26 Oct 2015 14:10:42 -0700 Message-ID: Subject: Re: hostapd loses connectivity on ath0 From: Adrian Chadd To: Alban Hertroys Cc: freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 21:10:44 -0000 hiya, you should try -head. But there's some long standing issues hiding around in the AR9227 code somewhere where they occasionally go deaf and I never figured out why... :( -a On 26 October 2015 at 13:27, Alban Hertroys wrote: > At random times my devices suddenly fail to connect to Wifi on my ath0 de= vice. Issueing /etc/rc.d/hostapd restart usually resolves the issue, but at= some point that also hung. > > Shutting down to single user mode in the hung state only partially succee= ded, in the sense that ifconfig, hostapd and a few other network-related pr= ocesses kept "running" - I assume the hangup of hostapd was caused by a hun= g process somewhere in that tree. > > The system is: > > uname -a > FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 r286718: Th= u Aug 13 10:00:32 CEST 2015 dalroi@solfertje:/usr/obj/usr/src/sys/ANTEL= OPE amd64 > > It's quite possible that I've misconfigured something, so here's the rele= vant lines of my configs=E2=80=A6 > > rc.conf: > > # Outside interface > ifconfig_fxp0=3D"DHCP" > ifconfig_fxp0_ipv6=3D"inet6 accept_rtadv" > > # Wireless > wlans_ath0=3D"wlan0" > > create_args_wlan0=3D"wlanmode hostap" > > ifconfig_wlan0=3D"mode ng channel 9:ht/40" > ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv" > > # Bridged interfaces (see example at man 4 bridge) > cloned_interfaces=3D"bridge0" > ifconfig_bridge0=3D"addm em0 stp em0 addm wlan0 stp wlan0 up" > ifconfig_bridge0_alias0=3D"inet 10.236.150.1/24" > ifconfig_bridge0_ipv6_alias0=3D"inet6 fe80::6efd:b9ff:fe68:db36%bridge0" > > # Internal wired ethernet (should that be above the bridge declaration?) > ifconfig_em0=3D"up" > ifconfig_em0_ipv6=3D"inet6 accept_rtadv" > > hostapd_enable=3D"YES" > > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > hostapd.conf: > > interface=3Dwlan0 > driver=3Dbsd > debug=3D1 > ctrl_interface=3D/var/run/hostapd > ctrl_interface_group=3Dwheel > ssid=3Dfoo > country_code=3DNL > ieee80211d=3D1 > hw_mode=3Dg > wpa=3D2 > wpa_passphrase=3Dnonononono > wpa_key_mgmt=3DWPA-PSK > wpa_pairwise=3DCCMP > > > The ath0 device is: > pciconf -lv ath0 > ath0@pci0:5:6:0: class=3D0x028000 card=3D0x0300168c chip=3D0x002d1= 68c rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR9227 Wireless Network Adapter' > class =3D network > > In case it's relevant: All connected devices get their IPv4 addresses thr= ough DHCP from this machine, the machine itself gets it's IPv4 external add= ress from my upstream provider, the internal addresses are hardwired per in= terface. DHCP is configured to use hostnames (instead of IP's) that get loo= ked up in Bind9 on the same machine. > > > Google did find some people on the internet with apparently the same prob= lem, but nobody seems to have found (or posted) a resolution. > > Am I doing something wrong? If not, is this a known issue? What's the nex= t step? > > Alban Hertroys > -- > If you can't see the forest for the trees, > cut the trees and you'll find there is no forest. > > _______________________________________________ > 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 Oct 26 23:35:37 2015 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 B79A9A1E666 for ; Mon, 26 Oct 2015 23:35:37 +0000 (UTC) (envelope-from cursos@barradecomercio.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 9D0791CD6 for ; Mon, 26 Oct 2015 23:35:37 +0000 (UTC) (envelope-from cursos@barradecomercio.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9A249A1E65E; Mon, 26 Oct 2015 23:35: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 99B77A1E65D for ; Mon, 26 Oct 2015 23:35:37 +0000 (UTC) (envelope-from cursos@barradecomercio.org) Received: from core-215-7-server.dyd.es (core-215-7-server.dyd.es [93.159.215.7]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6E01CD4 for ; Mon, 26 Oct 2015 23:35:36 +0000 (UTC) (envelope-from cursos@barradecomercio.org) To: From: "Capacitaciones" Reply-To: "=?utf-8?Q?Capacitaci=C3=B3n?=" Date: Tue, 27 Oct 2015 00:34:38 +0100 Message-ID: <562eb88eaa423@barradecomercio_ip-zone_com-6> X-CcmId: 07004745525d55505f0b0440555b0e3a0b16181b5d5f533e505c540a040457585155010608080900 Feedback-ID: 24833:24833-193:1:Mailrelay X-Report-Abuse: Please report abuse for this campaign here http://barradecomercio.mailrelay-ii.com/ccm/abuse?a=24833&m=193&s=915119 X-OriginalSender: cursos@barradecomercio.org Subject: =?utf-8?Q?DIPLOMADO=20en-linea=20-=20Estudia=20f=C3=A1cil=20a=20tu=20?= =?utf-8?Q?ritmo=20Comercio=20Exterior?= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Oct 2015 23:35:37 -0000 =0ADIPLOMADO en-linea - Estudia f=C3=A1cil a tu ritmo Comercio Exterior =09=09 =09=09=09=C2=BFNo puedes ver el correo correctamente?=C2=A0Da click aqu= =C3=AD para la versi=C3=B3n en internet =09=09 =09=09=09Diplomado on-line de Comercio Exterior.=0AIniciamos CADA MES.=0APr= omoci=C3=B3n por pago=C2=A0en una sola exhibici=C3=B3n este mes. $14,940.00= MXN =09=09 =09=09=09 =09=09El objetivo del Diplomado on-line de Comercio Exterior es facilitar e= l estudio de las disposiciones aduaneras, a trav=C3=A9s de un m=C3=A9todo d= id=C3=A1ctico en el cual se le permite el acceso al estudiante a las clases= impartidas por los maestros mediante videos que puede consultar en cualqui= er momento, lecturas previas, pr=C3=A1cticas, y evaluaciones semanales con = un sistema de calificaci=C3=B3n inmediata que permite medir el avance de fo= rma clara y sencilla en un total de 20 sesiones.=0A=0A=0A=0A =09=09Se incluyen salas virtuales de consulta con los profesores para aclar= ar dudas que surjan sobre la aplicaci=C3=B3n de las disposiciones legales q= ue rigen nuestro sistema aduanero, con la certeza y precisi=C3=B3n que se r= equiere para evitar problemas en el despacho de las mercanc=C3=ADas, visita= s domiciliarias, revisi=C3=B3n de mercanc=C3=ADas en transporte y facultade= s de comprobaci=C3=B3n por parte de las autoridades fiscales y aduaneras.= =0A =09=09=C2=A0 =09=09 =09=09=09=0A=0AInscripci=C3=B3nes:=0A=0ALic. Alejandra Hern=C3=A1ndez Mej= =C3=ADa=0A =09=09=09=C2=A0 =09=09 =09=09=09(55) 57.61.64.06 / 01.800.823.95.64 =09=09 =09=09=09ahernandez@barradecomercio.org.mx=0A=0ADescarga hoja de=C2=A0promo= ci=C3=B3n =09=09=0A=0ABarra Nacional de Comercio Exterior=C2=AE 2015 Todos los derech= os reservados =09=09 =09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09Eliminar Contacto =09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09Agregar Contacto =09=09=09=09=0A=0A From owner-freebsd-stable@freebsd.org Tue Oct 27 05:05:12 2015 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 62A9FA06FB7 for ; Tue, 27 Oct 2015 05:05:12 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 382CF1D5F for ; Tue, 27 Oct 2015 05:05:11 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with comcast id a5511r0014yXVJQ0155AMA; Tue, 27 Oct 2015 05:05:10 +0000 Received: from jdc.koitsu.org ([69.181.142.213]) by resomta-po-06v.sys.comcast.net with comcast id a5591r0014cTVs501559gn; Tue, 27 Oct 2015 05:05:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EB7371AF13D; Mon, 26 Oct 2015 22:05:08 -0700 (PDT) Date: Mon, 26 Oct 2015 22:05:08 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: stable/10: high load average when box is idle Message-ID: <20151027050508.GA7612@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445922310; bh=a1JFMuBDopH+A/MgWSd8kqGIYG7z01iklPrKPGcSYwg=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=RkVk2Tz7XMMc8sRhmH5DgOEP4XWeZaJuMsPzav81Rn0UKYlpVMJH1aYhtto+ELZ9H Y7FtW7ObUnJl4/KazjI+QsexcAqUEzRKVMfwTZuuHRnudKyFkoRWo1omtKfKbf1bJI 6PTnCkWwDUiYZc+uxB/Hj9AYAVVk+LvMtbtjCFd4lpY8SmjXECqBPsVZYI2mGWjk8O wE8YzoiI+N3PS8dEa89hHL3XQJ6yuGk3cDkDOoYxPRAezfmo9nsRx2zqUqOi7D0UMd AhzFaV2YV7kfXohN9ERy/2cuX3f4MUiTW/Lz7/Qi36hZdPblssFgvrjhkf7Z0VwpJ7 znmE9k4l/sEpA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 05:05:12 -0000 (I am not subscribed to the mailing list, please keep me CC'd) Issue: a stable/10 system that has an abnormally high load average (e.g. 0.15, but may be higher depending on other variables which I can't account for) when the machine is definitely idle (i.e. cannot be traced to high interrupt usage per vmstat -i, cannot be traced to a userland process or kernel thread, etc.). This problem has been discussed many times on the FreeBSD mailing lists and the FreeBSD forum (including some folks seeing it on 9.x, but my complaint here is focused on 10.x so please focus there). I'd politely like to request that anyone experiencing this, or who has experienced it (and if you know when it stopped or why, including what you may have done, include that), to chime in on this ticket from 2012 (made for 9.x but style of issue still applies; c#5 is quite valid): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 For those still experiencing it, I'd suggest reading c#8 and seeing if sysctl kern.eventtimer.periodic=1 relieves the problem for you. (At this time I would not suggest leaving that set indefinitely, as it does seem to increase the interrupt rate in cpuX:timer in vmstat -i. But for me kern.eventtimer.periodic=1 "fixes" the issue) Thanks. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@freebsd.org Tue Oct 27 10:19:25 2015 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 0C78CA1E50F for ; Tue, 27 Oct 2015 10:19:25 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from dg.fsn.hu (dg.fsn.hu [84.2.225.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dg.fsn.hu", Issuer "dg.fsn.hu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B65F41B04 for ; Tue, 27 Oct 2015 10:19:24 +0000 (UTC) (envelope-from bra@fsn.hu) Received: by dg.fsn.hu (Postfix, from userid 1003) id 085BE23D2; Tue, 27 Oct 2015 11:10:38 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.007248, version=1.2.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 17.4036] X-CRM114-CacheID: sfid-20151027_11103_C9BEFE98 X-CRM114-Status: Good ( pR: 17.4036 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Oct 27 11:10:38 2015 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 562f4d9e484251701111545 X-DSPAM-Factors: 27, is+unavailable, 0.01000, overflow", 0.01000, Java, 0.01000, could, 0.01000, could, 0.01000, but, 0.01000, but, 0.01000, only+this, 0.01000, reports, 0.01000, a+redis, 0.01000, out+from, 0.01000, Also, 0.01000, Also, 0.01000, some+hours, 0.01000, Date*Oct+2015, 0.01000, this+after, 0.01000, 20+0, 0.01000, 00%25, 0.01000, ideas+about, 0.01000, Received*online.co.hu+[195.228.243.99]), 0.01000, or, 0.01000, or, 0.01000, Received*Tue, 0.01000, this+I've, 0.01000, never, 0.01000, an, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from [IPv6:::1] (japan.t-online.co.hu [195.228.243.99]) by dg.fsn.hu (Postfix) with ESMTPSA id A90E423CF for ; Tue, 27 Oct 2015 11:10:35 +0100 (CET) To: freebsd-stable From: "Nagy, Attila" Subject: Stuck processes in unkillable (STOP) state, listen queue overflow Message-ID: <562F4D98.9060200@fsn.hu> Date: Tue, 27 Oct 2015 11:10:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 10:19:25 -0000 Hi, Recently I've started to see a lot of cases, where the log is full with "listen queue overflow" messages and the process behind the network socket is unavailable. When I open a TCP to it, it opens but nothing happens (for example I get no SMTP banner from postfix, nor I get a log entry about the new connection). I've seen this with Java programs, postfix and redis, basically everything which opens a TCP and listens on the machine. For example, I have a redis process, which listens on 6381. When I telnet into it, the TCP opens, but the program doesn't respond. When I kill it, nothing happens. Even with kill -9 yields only this state: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN 776 redis 2 20 0 24112K 2256K STOP 3 16:56 0.00% redis- When I tcpdrop the connections of the process, tcpdrop reports success for the first time and failure for the second (No such process), but the connections remain: # sockstat -4 | grep 776 redis redis-serv 776 6 tcp4 *:6381 *:* redis redis-serv 776 9 tcp4 *:16381 *:* redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 # sockstat -4 | grep 776 | awk '{print "tcpdrop "$6" "$7}' | /bin/sh tcpdrop: getaddrinfo: * port 6381: hostname nor servname provided, or not known tcpdrop: getaddrinfo: * port 16381: hostname nor servname provided, or not known tcpdrop: 127.0.0.1 16381 127.0.0.1 10460: No such process tcpdrop: 127.0.0.1 16381 127.0.0.1 35795: No such process tcpdrop: 127.0.0.1 30027 127.0.0.1 16379: No such process tcpdrop: 127.0.0.1 58802 127.0.0.1 16384: No such process tcpdrop: 127.0.0.1 16381 127.0.0.1 24354: No such process tcpdrop: 127.0.0.1 16381 127.0.0.1 56999: No such process tcpdrop: 127.0.0.1 16381 127.0.0.1 39488: No such process tcpdrop: 127.0.0.1 6381 127.0.0.1 39491: No such process # sockstat -4 | grep 776 redis redis-serv 776 6 tcp4 *:6381 *:* redis redis-serv 776 9 tcp4 *:16381 *:* redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 $ procstat -k 776 PID TID COMM TDNAME KSTACK 776 100725 redis-server - mi_switch sleepq_timedwait_sig _sleep kern_kevent sys_kevent amd64_syscall Xfast_syscall 776 100744 redis-server - mi_switch thread_suspend_switch thread_single exit1 sigexit postsig ast doreti_ast I can do nothing to get out from this state, only reboot helps. The OS is stable/10@r289313, but I could observe this behaviour with earlier releases too. The dmesg is full with lines like these: sonewconn: pcb 0xfffff8004dc54498: Listen queue overflow: 193 already in queue awaiting acceptance (3142 occurrences) sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already in queue awaiting acceptance (3068 occurrences) sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already in queue awaiting acceptance (3057 occurrences) sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already in queue awaiting acceptance (3037 occurrences) sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already in queue awaiting acceptance (3015 occurrences) sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already in queue awaiting acceptance (3035 occurrences) I guess this is the effect of the process freeze, not the cause (the listen queue fills up because the app can't handle the incoming connections). I'm not sure it matters, but some of the machines (and the above) runs on an ESX hypervisor (but as far as I can remember, I could see this on physical machines too, but I'm not sure about that). Also -so far- I could only see this where some "exotic" stuff ran, like a java or erlang based server (opendj, elasticsearch and rabbitmq). Also not sure about which triggers this. I've never seen this after some hours of uptime, at least some days or a week must've been passed to get stuck like the above. Any ideas about this? Thanks, From owner-freebsd-stable@freebsd.org Tue Oct 27 14:02:19 2015 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 27DB2A1EB73 for ; Tue, 27 Oct 2015 14:02:19 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.5.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtpserv.uni-tuebingen.de", Issuer "Global-UNITUE-CA 01" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C34371E42 for ; Tue, 27 Oct 2015 14:02:18 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from webmail1.uni-tuebingen.de (webmail1.uni-tuebingen.de [134.2.5.194]) by mx08.uni-tuebingen.de (8.14.3/8.14.3) with ESMTP id t9RDgipU010733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Oct 2015 14:42:44 +0100 Received: from webmail1.uni-tuebingen.de (localhost [127.0.0.1]) by webmail1.uni-tuebingen.de (Postfix) with ESMTPS id 9F5B1114CBEE4 for ; Tue, 27 Oct 2015 14:42:42 +0100 (CET) Received: from roceehbwz.rue23.uni-tuebingen.de (roceehbwz.rue23.uni-tuebingen.de [134.2.216.120]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Tue, 27 Oct 2015 14:42:42 +0100 Date: Tue, 27 Oct 2015 14:42:42 +0100 Message-ID: <20151027144242.Horde.3Xc1_RqzaVMAZ12X6OPXfdN@webmail.uni-tuebingen.de> From: Zara Kanaeva To: freebsd-stable@freebsd.org Subject: Re: Stuck processes in unkillable (STOP) state, listen queue overflow In-Reply-To: <562F4D98.9060200@fsn.hu> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6614 X-purgate-ID: 154962::1445953364-00000C17-64E2A6D4/0/0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 14:02:19 -0000 Hello, I have the same experience with apache and mapserver. It happens on physical machine and ends with spontaneous reboot. This machine is updated from FREEBSD 9.0 RELEASE to FREEBSD 10.2-PRERELEASE. Perhaps this machine doesn't have enough RAM (only 8GB), but I think that must not be a reason for a spontaneous reboot. I had no such behavior with the same machine and FREEBSD 9.0 RELEASE on it (I am not 100% sure, I have yet no possibility to test it). Regards, Z. Kanaeva. Zitat von "Nagy, Attila" : > Hi, > > Recently I've started to see a lot of cases, where the log is full > with "listen queue overflow" messages and the process behind the > network socket is unavailable. > When I open a TCP to it, it opens but nothing happens (for example I > get no SMTP banner from postfix, nor I get a log entry about the new > connection). > > I've seen this with Java programs, postfix and redis, basically > everything which opens a TCP and listens on the machine. > > For example, I have a redis process, which listens on 6381. When I > telnet into it, the TCP opens, but the program doesn't respond. > When I kill it, nothing happens. Even with kill -9 yields only this state: > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN > 776 redis 2 20 0 24112K 2256K STOP 3 16:56 > 0.00% redis- > > When I tcpdrop the connections of the process, tcpdrop reports > success for the first time and failure for the second (No such > process), but the connections remain: > # sockstat -4 | grep 776 > redis redis-serv 776 6 tcp4 *:6381 *:* > redis redis-serv 776 9 tcp4 *:16381 *:* > redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 > redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 > redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 > redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 > redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 > redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 > redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 > redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 > # sockstat -4 | grep 776 | awk '{print "tcpdrop "$6" "$7}' | /bin/sh > tcpdrop: getaddrinfo: * port 6381: hostname nor servname provided, > or not known > tcpdrop: getaddrinfo: * port 16381: hostname nor servname provided, > or not known > tcpdrop: 127.0.0.1 16381 127.0.0.1 10460: No such process > tcpdrop: 127.0.0.1 16381 127.0.0.1 35795: No such process > tcpdrop: 127.0.0.1 30027 127.0.0.1 16379: No such process > tcpdrop: 127.0.0.1 58802 127.0.0.1 16384: No such process > tcpdrop: 127.0.0.1 16381 127.0.0.1 24354: No such process > tcpdrop: 127.0.0.1 16381 127.0.0.1 56999: No such process > tcpdrop: 127.0.0.1 16381 127.0.0.1 39488: No such process > tcpdrop: 127.0.0.1 6381 127.0.0.1 39491: No such process > # sockstat -4 | grep 776 > redis redis-serv 776 6 tcp4 *:6381 *:* > redis redis-serv 776 9 tcp4 *:16381 *:* > redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 > redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 > redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 > redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 > redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 > redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 > redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 > redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 > > $ procstat -k 776 > PID TID COMM TDNAME KSTACK > 776 100725 redis-server - mi_switch > sleepq_timedwait_sig _sleep kern_kevent sys_kevent amd64_syscall > Xfast_syscall > 776 100744 redis-server - mi_switch > thread_suspend_switch thread_single exit1 sigexit postsig ast > doreti_ast > > I can do nothing to get out from this state, only reboot helps. > > The OS is stable/10@r289313, but I could observe this behaviour with > earlier releases too. > > The dmesg is full with lines like these: > sonewconn: pcb 0xfffff8004dc54498: Listen queue overflow: 193 > already in queue awaiting acceptance (3142 occurrences) > sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 > already in queue awaiting acceptance (3068 occurrences) > sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 > already in queue awaiting acceptance (3057 occurrences) > sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 > already in queue awaiting acceptance (3037 occurrences) > sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 > already in queue awaiting acceptance (3015 occurrences) > sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 > already in queue awaiting acceptance (3035 occurrences) > > I guess this is the effect of the process freeze, not the cause (the > listen queue fills up because the app can't handle the incoming > connections). > > I'm not sure it matters, but some of the machines (and the above) > runs on an ESX hypervisor (but as far as I can remember, I could see > this on physical machines too, but I'm not sure about that). > Also -so far- I could only see this where some "exotic" stuff ran, > like a java or erlang based server (opendj, elasticsearch and > rabbitmq). > > Also not sure about which triggers this. I've never seen this after > some hours of uptime, at least some days or a week must've been > passed to get stuck like the above. > > Any ideas about this? > > Thanks, > _______________________________________________ > 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" -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kanaeva@geographie.uni-tuebingen.de ------- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. From owner-freebsd-stable@freebsd.org Tue Oct 27 16:25:11 2015 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 2CA63A1F0D5 for ; Tue, 27 Oct 2015 16:25:11 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from dg.fsn.hu (dg.fsn.hu [84.2.225.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dg.fsn.hu", Issuer "dg.fsn.hu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB00510E5 for ; Tue, 27 Oct 2015 16:25:10 +0000 (UTC) (envelope-from bra@fsn.hu) Received: by dg.fsn.hu (Postfix, from userid 1003) id B5E8D291D; Tue, 27 Oct 2015 17:25:02 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.003469, version=1.2.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 25.6787] X-CRM114-CacheID: sfid-20151027_17250_0BCD04C7 X-CRM114-Status: Good ( pR: 25.6787 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Oct 27 17:25:02 2015 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 562fa55e580599734046062 X-DSPAM-Factors: 27, is+unavailable, 0.01000, overflow", 0.01000, Java, 0.01000, could, 0.01000, could, 0.01000, but, 0.01000, but, 0.01000, only+this, 0.01000, reports, 0.01000, (3068, 0.01000, a+redis, 0.01000, out+from, 0.01000, Also, 0.01000, Also, 0.01000, References*tuebingen.de>, 0.01000, some+hours, 0.01000, possibility, 0.01000, Date*Oct+2015, 0.01000, this+after, 0.01000, 20+0, 0.01000, postsig+ast, 0.01000, think+that, 0.01000, happens+(for, 0.01000, 00%25, 0.01000, ideas+about, 0.01000, >+Zitat, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from [IPv6:::1] (japan.t-online.co.hu [195.228.243.99]) by dg.fsn.hu (Postfix) with ESMTPSA id 08C6D291B; Tue, 27 Oct 2015 17:25:01 +0100 (CET) Subject: Re: Stuck processes in unkillable (STOP) state, listen queue overflow To: Zara Kanaeva , freebsd-stable@freebsd.org References: <20151027144242.Horde.3Xc1_RqzaVMAZ12X6OPXfdN@webmail.uni-tuebingen.de> From: "Nagy, Attila" Message-ID: <562FA55D.6050503@fsn.hu> Date: Tue, 27 Oct 2015 17:25:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151027144242.Horde.3Xc1_RqzaVMAZ12X6OPXfdN@webmail.uni-tuebingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Oct 2015 16:25:11 -0000 Hi, (following topposting) I have seen this with 16 and 32 GiB of RAM, but anyways, it shouldn't matter. Do you use zfs? Although it doesn't seem to be stuck on IO... On 10/27/15 14:42, Zara Kanaeva wrote: > Hello, > > I have the same experience with apache and mapserver. It happens on > physical machine and ends with spontaneous reboot. This machine is > updated from FREEBSD 9.0 RELEASE to FREEBSD 10.2-PRERELEASE. Perhaps > this machine doesn't have enough RAM (only 8GB), but I think that must > not be a reason for a spontaneous reboot. > > I had no such behavior with the same machine and FREEBSD 9.0 RELEASE > on it (I am not 100% sure, I have yet no possibility to test it). > > Regards, Z. Kanaeva. > > Zitat von "Nagy, Attila" : > >> Hi, >> >> Recently I've started to see a lot of cases, where the log is full >> with "listen queue overflow" messages and the process behind the >> network socket is unavailable. >> When I open a TCP to it, it opens but nothing happens (for example I >> get no SMTP banner from postfix, nor I get a log entry about the new >> connection). >> >> I've seen this with Java programs, postfix and redis, basically >> everything which opens a TCP and listens on the machine. >> >> For example, I have a redis process, which listens on 6381. When I >> telnet into it, the TCP opens, but the program doesn't respond. >> When I kill it, nothing happens. Even with kill -9 yields only this >> state: >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME >> WCPU COMMAN >> 776 redis 2 20 0 24112K 2256K STOP 3 16:56 >> 0.00% redis- >> >> When I tcpdrop the connections of the process, tcpdrop reports >> success for the first time and failure for the second (No such >> process), but the connections remain: >> # sockstat -4 | grep 776 >> redis redis-serv 776 6 tcp4 *:6381 *:* >> redis redis-serv 776 9 tcp4 *:16381 *:* >> redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 >> redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 >> redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 >> redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 >> redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 >> redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 >> redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 >> redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 >> # sockstat -4 | grep 776 | awk '{print "tcpdrop "$6" "$7}' | /bin/sh >> tcpdrop: getaddrinfo: * port 6381: hostname nor servname provided, or >> not known >> tcpdrop: getaddrinfo: * port 16381: hostname nor servname provided, >> or not known >> tcpdrop: 127.0.0.1 16381 127.0.0.1 10460: No such process >> tcpdrop: 127.0.0.1 16381 127.0.0.1 35795: No such process >> tcpdrop: 127.0.0.1 30027 127.0.0.1 16379: No such process >> tcpdrop: 127.0.0.1 58802 127.0.0.1 16384: No such process >> tcpdrop: 127.0.0.1 16381 127.0.0.1 24354: No such process >> tcpdrop: 127.0.0.1 16381 127.0.0.1 56999: No such process >> tcpdrop: 127.0.0.1 16381 127.0.0.1 39488: No such process >> tcpdrop: 127.0.0.1 6381 127.0.0.1 39491: No such process >> # sockstat -4 | grep 776 >> redis redis-serv 776 6 tcp4 *:6381 *:* >> redis redis-serv 776 9 tcp4 *:16381 *:* >> redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 >> redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 >> redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 >> redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 >> redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 >> redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 >> redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 >> redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 >> >> $ procstat -k 776 >> PID TID COMM TDNAME KSTACK >> 776 100725 redis-server - mi_switch >> sleepq_timedwait_sig _sleep kern_kevent sys_kevent amd64_syscall >> Xfast_syscall >> 776 100744 redis-server - mi_switch >> thread_suspend_switch thread_single exit1 sigexit postsig ast doreti_ast >> >> I can do nothing to get out from this state, only reboot helps. >> >> The OS is stable/10@r289313, but I could observe this behaviour with >> earlier releases too. >> >> The dmesg is full with lines like these: >> sonewconn: pcb 0xfffff8004dc54498: Listen queue overflow: 193 already >> in queue awaiting acceptance (3142 occurrences) >> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already >> in queue awaiting acceptance (3068 occurrences) >> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already >> in queue awaiting acceptance (3057 occurrences) >> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already >> in queue awaiting acceptance (3037 occurrences) >> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already >> in queue awaiting acceptance (3015 occurrences) >> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 already >> in queue awaiting acceptance (3035 occurrences) >> >> I guess this is the effect of the process freeze, not the cause (the >> listen queue fills up because the app can't handle the incoming >> connections). >> >> I'm not sure it matters, but some of the machines (and the above) >> runs on an ESX hypervisor (but as far as I can remember, I could see >> this on physical machines too, but I'm not sure about that). >> Also -so far- I could only see this where some "exotic" stuff ran, >> like a java or erlang based server (opendj, elasticsearch and rabbitmq). >> >> Also not sure about which triggers this. I've never seen this after >> some hours of uptime, at least some days or a week must've been >> passed to get stuck like the above. >> >> Any ideas about this? >> >> Thanks, >> _______________________________________________ >> 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 Wed Oct 28 13:34:16 2015 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 04A09A1F160 for ; Wed, 28 Oct 2015 13:34:16 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C0661593 for ; Wed, 28 Oct 2015 13:34:15 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wicfx6 with SMTP id fx6so198514135wic.1 for ; Wed, 28 Oct 2015 06:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris_ac_uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to; bh=MdaqPqdSHKyGbFJIaKmLC8TM49QVktaA/CyB3FvSkqc=; b=q9Le2JuuiHOFLG8BZwUwV2C6HsBcvQu0+zA1tPBdgTlFquclbUwZPze2m56vzjMDzx kQrS2nxbAEH6wH7GG003BZRA2t5uyqI3N0iRcctvFY6TEiB7XMuEcKvmUTuG65UocuV8 8r9KPFHt8q78wKI5c0x/dgTEvlBnepIHJJRXmzL9Xhg/QoHjltuifZL+5n0n+Xz7NjRe jeOlaN5FAcUzKXEVaZmvxcp8szhzna3HF8PqX7R373RQDTvB50jCkji2LRxAxdIR8lDM qf/UcPr6ehTL2teYAuI7UAnNl0Tku4F40BcygWYdHIvlel6BVmUInA6W01arYz6Qczz0 ITAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=MdaqPqdSHKyGbFJIaKmLC8TM49QVktaA/CyB3FvSkqc=; b=ehThaFPByAqeOBQvugoV0DwMXtiohDUdMd0azAUb0K68hQShdoNfqqL+C8a3pWoGQs 9VQw4dZ8ubgHC1Tv7IWXFnMov16jUkpjtlTxbc9grMyU/4YyopXI9bAypiGSIi/GDn+d gQxmkdgwRNUM8z/vOWzzabJy4/iusPgNyWNSXVA+uWnoazu8U7G+5MK55XBdt2sefsku cvEq7N28SM/Yw6SeTuw2eFy/eMXXDy1kbl0gcEX2d+mIXB+7UDgkvw/JBWHRopGsBgMn 1JDTdu+eU9cxFqBdysuOqJYeiGuWCrsN1GK5sNfRRF4S6nkN9luAsrRL7TiWZK+wHvMM drLg== X-Gm-Message-State: ALoCoQnSkcFSYbBpTmBCHTjSs6eRGsODQNl2gRNTWwLWgFlZ1Sj8jIKdEbv7qDib/e8gr44A8SBi X-Received: by 10.180.198.12 with SMTP id iy12mr3012173wic.72.1446039253948; Wed, 28 Oct 2015 06:34:13 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id uj4sm50061479wjc.34.2015.10.28.06.34.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 06:34:13 -0700 (PDT) Date: Wed, 28 Oct 2015 06:34:13 -0700 (PDT) X-Google-Original-Date: Wed, 28 Oct 2015 13:34:12 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id t9SDYCSI020353 for ; Wed, 28 Oct 2015 13:34:12 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id t9SDYCwD020352 for freebsd-stable@freebsd.org; Wed, 28 Oct 2015 13:34:12 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201510281334.t9SDYCwD020352@mech-as222.men.bris.ac.uk> To: freebsd-stable@freebsd.org Subject: ia64 10.2-stable r289997: fatal kernel trap Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Oct 2015 13:34:16 -0000 I haven't finished the dump yet, but in case this is a known issue, I updated ia64 to 10.2-STABLE #16 r289997. On reboot in multi-user mode: Starting file system checks: /dev/da0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0p2: clean, 10613586 free (169426 frags, 1305520 blocks, 1.0% fragmentation) Mounting local file systems:. Writing entropy file:. Setting hostname: xxxx fatal kernel trap (cpu 0): trap vector = 0x14 (Page Not Present) cr.iip = 0xa000000001e72830 cr.ipsr = 0x1210080a6018 (ac,mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=1,bn) cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed) cr.ifa = 0x101a400000001 curthread = 0xe0000000122716d0 pid = 173, comm = kldload panic: trap cpuid = 0 KDB: stack backtrace: Uptime: 9s Dumping 8172 MB (25 chunks) chunk 0: 1 pages ... ok chunk 1: 159 pages ... ok chunk 2: 256 pages ... ok chunk 3: 7680 pages ... ok chunk 4: 8192 pages ... ok chunk 5: 239734 pages ... ok chunk 6: 748 pages ... ok chunk 7: 533 pages ... ok chunk 8: 21 pages ... ok chunk 9: 1048574 pages / Thanks Anton From owner-freebsd-stable@freebsd.org Thu Oct 29 01:09:01 2015 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 4A4FCA1FEDA for ; Thu, 29 Oct 2015 01:09:01 +0000 (UTC) (envelope-from bad_hdd@list.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.181.253]) by mx1.freebsd.org (Postfix) with ESMTP id 153BE1FB2 for ; Thu, 29 Oct 2015 01:08:59 +0000 (UTC) (envelope-from bad_hdd@list.ru) Received: from f25.i.mail.ru (f25.i.mail.ru [128.140.169.154]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id 3E7CA9616F48 for ; Thu, 29 Oct 2015 04:06:12 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=evrdxZ19BPNtya80D7ll2TAyV26scs9uHRXllwrmaQM=; b=lAFque2iXPhSG+K/UhqEPhywGJgEIMVyIPSsJGy+kdyIXfDnonUQMIGpcZuSpUDt8mT3b3G6isyqqw1TyiYfhh+QP9N8DHQzcyz/s97WSZiMHffpZ6UPLQr2vu0kYOBeUY+qedXNZMELMcHF0/riPwcS1JeDPm/1iZDC+nRayYc=; Received: from [5.228.103.234] (ident=mail) by f25.i.mail.ru with local (envelope-from ) id 1ZrbfG-00019T-9o for freebsd-stable@freebsd.org; Thu, 29 Oct 2015 04:06:02 +0300 Received: from [5.228.103.234] by e.mail.ru with HTTP; Thu, 29 Oct 2015 04:06:02 +0300 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= To: freebsd-stable@freebsd.org Subject: =?UTF-8?B?UmU6IFN0dWNrIHByb2Nlc3NlcyBpbiB1bmtpbGxhYmxlIChTVE9QKSBzdGF0?= =?UTF-8?B?ZSwgbGlzdGVuIHF1ZXVlIG92ZXJmbG93?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [5.228.103.234] Date: Thu, 29 Oct 2015 04:06:02 +0300 Reply-To: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= X-Priority: 3 (Normal) Message-ID: <1446080762.820771804@f25.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 01:09:01 -0000 Ckdvb2QgZGF5IGV2ZXJ5b25lICEKRnJvbSBteSBwb2ludCBvZiB2aWV3IGl0IHNlZW1zIGxpa2Ug eW91J3JlIGV4cGVyaWVuY2luZyB0aGUgImRvd25ncmFkZWQiIGhhcmR3YXJlIHBlcmZvcm1hbmNl IHdoaWNoIGNhdXNlcyB5b3UgdGhlIHByb2JsZW1zIHlvdSBtZWV0LgpUcnkgdG8gc3dpdGNoIGZv ciB0aGUgIm5ldy1vbmUiIHBvd2VyIHN1cHBseSBhdCBsZWFzdC4KV2h5IEkgdGhpbmsgc28gPyBC ZWNhdXNlIHRoZSBiYWQgcG93ZXIgc3VwcGxpZXMgYXJlIG1ldCBtdWNoIG1vcmUgb2Z0ZW4gdGhh biB0aGUgYmFkIHNvdXJjZSBjb2RlIGZvciBGcmVlQlNELiBPZiBjb3Vyc2UgSSBjYW4ndCB0ZWxs IHlvdSB5b3UncmUgY29tcGxldGVseSB3cm9uZy4KQmVzdCByZWdhcmRzLCBEaW1pdHJ5Lgo+0KHR gNC10LTQsCwgMjgg0L7QutGC0Y/QsdGA0Y8gMjAxNSwgMTI6MDAgVVRDINC+0YIgZnJlZWJzZC1z dGFibGUtcmVxdWVzdEBmcmVlYnNkLm9yZzoKPgo+U2VuZCBmcmVlYnNkLXN0YWJsZSBtYWlsaW5n IGxpc3Qgc3VibWlzc2lvbnMgdG8KPmZyZWVic2Qtc3RhYmxlQGZyZWVic2Qub3JnCj4KPlRvIHN1 YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdAo+aHR0 cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc3RhYmxlCj5v ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg dG8KPmZyZWVic2Qtc3RhYmxlLXJlcXVlc3RAZnJlZWJzZC5vcmcKPgo+WW91IGNhbiByZWFjaCB0 aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0Cj5mcmVlYnNkLXN0YWJsZS1vd25lckBmcmVl YnNkLm9yZwo+Cj5XaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBz byBpdCBpcyBtb3JlIHNwZWNpZmljCj50aGFuICJSZTogQ29udGVudHMgb2YgZnJlZWJzZC1zdGFi bGUgZGlnZXN0Li4uIgo+Cj4KPlRvZGF5J3MgVG9waWNzOgo+Cj7CoMKgwqAxLiBSZTogU3R1Y2sg cHJvY2Vzc2VzIGluIHVua2lsbGFibGUgKFNUT1ApIHN0YXRlLCBsaXN0ZW4gcXVldWUKPsKgwqDC oMKgwqDCoG92ZXJmbG93IChaYXJhIEthbmFldmEpCj7CoMKgwqAyLiBSZTogU3R1Y2sgcHJvY2Vz c2VzIGluIHVua2lsbGFibGUgKFNUT1ApIHN0YXRlLCBsaXN0ZW4gcXVldWUKPsKgwqDCoMKgwqDC oG92ZXJmbG93IChOYWd5LCBBdHRpbGEpCj4KPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAx Cj5EYXRlOiBUdWUsIDI3IE9jdCAyMDE1IDE0OjQyOjQyICswMTAwCj5Gcm9tOiBaYXJhIEthbmFl dmEgPCB6YXJhLmthbmFldmFAZ2dpLnVuaS10dWViaW5nZW4uZGUgPgo+VG86ICBmcmVlYnNkLXN0 YWJsZUBmcmVlYnNkLm9yZwo+U3ViamVjdDogUmU6IFN0dWNrIHByb2Nlc3NlcyBpbiB1bmtpbGxh YmxlIChTVE9QKSBzdGF0ZSwgbGlzdGVuIHF1ZXVlCj5vdmVyZmxvdwo+TWVzc2FnZS1JRDoKPjwg MjAxNTEwMjcxNDQyNDIuSG9yZGUuM1hjMV9ScXphVk1BWjEyWDZPUFhmZE5Ad2VibWFpbC51bmkt dHVlYmluZ2VuLmRlID4KPgo+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04 OyBmb3JtYXQ9Zmxvd2VkOyBEZWxTcD1ZZXMKPgo+SGVsbG8sCj4KPkkgaGF2ZSB0aGUgc2FtZSBl eHBlcmllbmNlIHdpdGggYXBhY2hlIGFuZCBtYXBzZXJ2ZXIuIEl0IGhhcHBlbnMgb24gCj5waHlz aWNhbCBtYWNoaW5lIGFuZCBlbmRzIHdpdGggc3BvbnRhbmVvdXMgcmVib290LiBUaGlzIG1hY2hp bmUgaXMgCj51cGRhdGVkIGZyb20gRlJFRUJTRCA5LjAgUkVMRUFTRSB0byBGUkVFQlNEIDEwLjIt UFJFUkVMRUFTRS4gUGVyaGFwcyAKPnRoaXMgbWFjaGluZSBkb2Vzbid0IGhhdmUgZW5vdWdoIFJB TSAob25seSA4R0IpLCBidXQgSSB0aGluayB0aGF0IG11c3QgCj5ub3QgYmUgYSByZWFzb24gZm9y IGEgc3BvbnRhbmVvdXMgcmVib290Lgo+Cj5JIGhhZCBubyBzdWNoIGJlaGF2aW9yIHdpdGggdGhl IHNhbWUgbWFjaGluZSBhbmQgRlJFRUJTRCA5LjAgUkVMRUFTRSAKPm9uIGl0IChJIGFtIG5vdCAx MDAlIHN1cmUsIEkgaGF2ZSB5ZXQgbm8gcG9zc2liaWxpdHkgdG8gdGVzdCBpdCkuCj4KPlJlZ2Fy ZHMsIFouIEthbmFldmEuCj4KPlppdGF0IHZvbiAiTmFneSwgQXR0aWxhIiA8IGJyYUBmc24uaHUg PjoKPgo+PiBIaSwKPj4KPj4gUmVjZW50bHkgSSd2ZSBzdGFydGVkIHRvIHNlZSBhIGxvdCBvZiBj YXNlcywgd2hlcmUgdGhlIGxvZyBpcyBmdWxsIAo+PiB3aXRoICJsaXN0ZW4gcXVldWUgb3ZlcmZs b3ciIG1lc3NhZ2VzIGFuZCB0aGUgcHJvY2VzcyBiZWhpbmQgdGhlIAo+PiBuZXR3b3JrIHNvY2tl dCBpcyB1bmF2YWlsYWJsZS4KPj4gV2hlbiBJIG9wZW4gYSBUQ1AgdG8gaXQsIGl0IG9wZW5zIGJ1 dCBub3RoaW5nIGhhcHBlbnMgKGZvciBleGFtcGxlIEkgCj4+IGdldCBubyBTTVRQIGJhbm5lciBm cm9tIHBvc3RmaXgsIG5vciBJIGdldCBhIGxvZyBlbnRyeSBhYm91dCB0aGUgbmV3IAo+PiBjb25u ZWN0aW9uKS4KPj4KPj4gSSd2ZSBzZWVuIHRoaXMgd2l0aCBKYXZhIHByb2dyYW1zLCBwb3N0Zml4 IGFuZCByZWRpcywgYmFzaWNhbGx5IAo+PiBldmVyeXRoaW5nIHdoaWNoIG9wZW5zIGEgVENQIGFu ZCBsaXN0ZW5zIG9uIHRoZSBtYWNoaW5lLgo+Pgo+PiBGb3IgZXhhbXBsZSwgSSBoYXZlIGEgcmVk aXMgcHJvY2Vzcywgd2hpY2ggbGlzdGVucyBvbiA2MzgxLiBXaGVuIEkgCj4+IHRlbG5ldCBpbnRv IGl0LCB0aGUgVENQIG9wZW5zLCBidXQgdGhlIHByb2dyYW0gZG9lc24ndCByZXNwb25kLgo+PiBX aGVuIEkga2lsbCBpdCwgbm90aGluZyBoYXBwZW5zLiBFdmVuIHdpdGgga2lsbCAtOSB5aWVsZHMg b25seSB0aGlzIHN0YXRlOgo+PiAgIFBJRCBVU0VSTkFNRSAgICAgICBUSFIgUFJJIE5JQ0UgICBT SVpFICAgIFJFUyBTVEFURSAgIEMgVElNRSAgICBXQ1BVIENPTU1BTgo+PiAgIDc3NiByZWRpcyAg ICAgICAgICAgIDIgIDIwICAgIDAgMjQxMTJLICAyMjU2SyBTVE9QICAgIDMgMTY6NTYgCj4+IDAu MDAlIHJlZGlzLQo+Pgo+PiBXaGVuIEkgdGNwZHJvcCB0aGUgY29ubmVjdGlvbnMgb2YgdGhlIHBy b2Nlc3MsIHRjcGRyb3AgcmVwb3J0cyAKPj4gc3VjY2VzcyBmb3IgdGhlIGZpcnN0IHRpbWUgYW5k IGZhaWx1cmUgZm9yIHRoZSBzZWNvbmQgKE5vIHN1Y2ggCj4+IHByb2Nlc3MpLCBidXQgdGhlIGNv bm5lY3Rpb25zIHJlbWFpbjoKPj4gIyBzb2Nrc3RhdCAtNCB8IGdyZXAgNzc2Cj4+IHJlZGlzICAg IHJlZGlzLXNlcnYgNzc2ICAgNiAgdGNwNCAgICo6NjM4MSAqOioKPj4gcmVkaXMgICAgcmVkaXMt c2VydiA3NzYgICA5ICB0Y3A0ICAgKjoxNjM4MSAqOioKPj4gcmVkaXMgICAgcmVkaXMtc2VydiA3 NzYgICAxMCB0Y3A0ICAgMTI3LjAuMC4xOjE2MzgxIDEyNy4wLjAuMToxMDQ2MAo+PiByZWRpcyAg ICByZWRpcy1zZXJ2IDc3NiAgIDExIHRjcDQgICAxMjcuMC4wLjE6MTYzODEgMTI3LjAuMC4xOjM1 Nzk1Cj4+IHJlZGlzICAgIHJlZGlzLXNlcnYgNzc2ICAgMTMgdGNwNCAgIDEyNy4wLjAuMTozMDAy NyAxMjcuMC4wLjE6MTYzNzkKPj4gcmVkaXMgICAgcmVkaXMtc2VydiA3NzYgICAxNCB0Y3A0ICAg MTI3LjAuMC4xOjU4ODAyIDEyNy4wLjAuMToxNjM4NAo+PiByZWRpcyAgICByZWRpcy1zZXJ2IDc3 NiAgIDE3IHRjcDQgICAxMjcuMC4wLjE6MTYzODEgMTI3LjAuMC4xOjI0MzU0Cj4+IHJlZGlzICAg IHJlZGlzLXNlcnYgNzc2ICAgMTggdGNwNCAgIDEyNy4wLjAuMToxNjM4MSAxMjcuMC4wLjE6NTY5 OTkKPj4gcmVkaXMgICAgcmVkaXMtc2VydiA3NzYgICAxOSB0Y3A0ICAgMTI3LjAuMC4xOjE2Mzgx IDEyNy4wLjAuMTozOTQ4OAo+PiByZWRpcyAgICByZWRpcy1zZXJ2IDc3NiAgIDIwIHRjcDQgICAx MjcuMC4wLjE6NjM4MSAxMjcuMC4wLjE6Mzk0OTEKPj4gIyBzb2Nrc3RhdCAtNCB8IGdyZXAgNzc2 IHwgYXdrICd7cHJpbnQgInRjcGRyb3AgIiQ2IiAiJDd9JyB8IC9iaW4vc2gKPj4gdGNwZHJvcDog Z2V0YWRkcmluZm86ICogcG9ydCA2MzgxOiBob3N0bmFtZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQs IAo+PiBvciBub3Qga25vd24KPj4gdGNwZHJvcDogZ2V0YWRkcmluZm86ICogcG9ydCAxNjM4MTog aG9zdG5hbWUgbm9yIHNlcnZuYW1lIHByb3ZpZGVkLCAKPj4gb3Igbm90IGtub3duCj4+IHRjcGRy b3A6IDEyNy4wLjAuMSAxNjM4MSAxMjcuMC4wLjEgMTA0NjA6IE5vIHN1Y2ggcHJvY2Vzcwo+PiB0 Y3Bkcm9wOiAxMjcuMC4wLjEgMTYzODEgMTI3LjAuMC4xIDM1Nzk1OiBObyBzdWNoIHByb2Nlc3MK Pj4gdGNwZHJvcDogMTI3LjAuMC4xIDMwMDI3IDEyNy4wLjAuMSAxNjM3OTogTm8gc3VjaCBwcm9j ZXNzCj4+IHRjcGRyb3A6IDEyNy4wLjAuMSA1ODgwMiAxMjcuMC4wLjEgMTYzODQ6IE5vIHN1Y2gg cHJvY2Vzcwo+PiB0Y3Bkcm9wOiAxMjcuMC4wLjEgMTYzODEgMTI3LjAuMC4xIDI0MzU0OiBObyBz dWNoIHByb2Nlc3MKPj4gdGNwZHJvcDogMTI3LjAuMC4xIDE2MzgxIDEyNy4wLjAuMSA1Njk5OTog Tm8gc3VjaCBwcm9jZXNzCj4+IHRjcGRyb3A6IDEyNy4wLjAuMSAxNjM4MSAxMjcuMC4wLjEgMzk0 ODg6IE5vIHN1Y2ggcHJvY2Vzcwo+PiB0Y3Bkcm9wOiAxMjcuMC4wLjEgNjM4MSAxMjcuMC4wLjEg Mzk0OTE6IE5vIHN1Y2ggcHJvY2Vzcwo+PiAjIHNvY2tzdGF0IC00IHwgZ3JlcCA3NzYKPj4gcmVk aXMgICAgcmVkaXMtc2VydiA3NzYgICA2ICB0Y3A0ICAgKjo2MzgxICo6Kgo+PiByZWRpcyAgICBy ZWRpcy1zZXJ2IDc3NiAgIDkgIHRjcDQgICAqOjE2MzgxICo6Kgo+PiByZWRpcyAgICByZWRpcy1z ZXJ2IDc3NiAgIDEwIHRjcDQgICAxMjcuMC4wLjE6MTYzODEgMTI3LjAuMC4xOjEwNDYwCj4+IHJl ZGlzICAgIHJlZGlzLXNlcnYgNzc2ICAgMTEgdGNwNCAgIDEyNy4wLjAuMToxNjM4MSAxMjcuMC4w LjE6MzU3OTUKPj4gcmVkaXMgICAgcmVkaXMtc2VydiA3NzYgICAxMyB0Y3A0ICAgMTI3LjAuMC4x OjMwMDI3IDEyNy4wLjAuMToxNjM3OQo+PiByZWRpcyAgICByZWRpcy1zZXJ2IDc3NiAgIDE0IHRj cDQgICAxMjcuMC4wLjE6NTg4MDIgMTI3LjAuMC4xOjE2Mzg0Cj4+IHJlZGlzICAgIHJlZGlzLXNl cnYgNzc2ICAgMTcgdGNwNCAgIDEyNy4wLjAuMToxNjM4MSAxMjcuMC4wLjE6MjQzNTQKPj4gcmVk aXMgICAgcmVkaXMtc2VydiA3NzYgICAxOCB0Y3A0ICAgMTI3LjAuMC4xOjE2MzgxIDEyNy4wLjAu MTo1Njk5OQo+PiByZWRpcyAgICByZWRpcy1zZXJ2IDc3NiAgIDE5IHRjcDQgICAxMjcuMC4wLjE6 MTYzODEgMTI3LjAuMC4xOjM5NDg4Cj4+IHJlZGlzICAgIHJlZGlzLXNlcnYgNzc2ICAgMjAgdGNw NCAgIDEyNy4wLjAuMTo2MzgxIDEyNy4wLjAuMTozOTQ5MQo+Pgo+PiAkIHByb2NzdGF0IC1rIDc3 Ngo+PiAgIFBJRCAgICBUSUQgQ09NTSAgICAgICAgICAgICBURE5BTUUgS1NUQUNLCj4+ICAgNzc2 IDEwMDcyNSByZWRpcy1zZXJ2ZXIgICAgIC0gICAgICAgICAgICAgICAgbWlfc3dpdGNoIAo+PiBz bGVlcHFfdGltZWR3YWl0X3NpZyBfc2xlZXAga2Vybl9rZXZlbnQgc3lzX2tldmVudCBhbWQ2NF9z eXNjYWxsIAo+PiBYZmFzdF9zeXNjYWxsCj4+ICAgNzc2IDEwMDc0NCByZWRpcy1zZXJ2ZXIgICAg IC0gICAgICAgICAgICAgICAgbWlfc3dpdGNoIAo+PiB0aHJlYWRfc3VzcGVuZF9zd2l0Y2ggdGhy ZWFkX3NpbmdsZSBleGl0MSBzaWdleGl0IHBvc3RzaWcgYXN0IAo+PiBkb3JldGlfYXN0Cj4+Cj4+ IEkgY2FuIGRvIG5vdGhpbmcgdG8gZ2V0IG91dCBmcm9tIHRoaXMgc3RhdGUsIG9ubHkgcmVib290 IGhlbHBzLgo+Pgo+PiBUaGUgT1MgaXMgc3RhYmxlLzEwQHIyODkzMTMsIGJ1dCBJIGNvdWxkIG9i c2VydmUgdGhpcyBiZWhhdmlvdXIgd2l0aCAKPj4gZWFybGllciByZWxlYXNlcyB0b28uCj4+Cj4+ IFRoZSBkbWVzZyBpcyBmdWxsIHdpdGggbGluZXMgbGlrZSB0aGVzZToKPj4gc29uZXdjb25uOiBw Y2IgMHhmZmZmZjgwMDRkYzU0NDk4OiBMaXN0ZW4gcXVldWUgb3ZlcmZsb3c6IDE5MyAKPj4gYWxy ZWFkeSBpbiBxdWV1ZSBhd2FpdGluZyBhY2NlcHRhbmNlICgzMTQyIG9jY3VycmVuY2VzKQo+PiBz b25ld2Nvbm46IHBjYiAweGZmZmZmODAwNGQ5ZWQxODg6IExpc3RlbiBxdWV1ZSBvdmVyZmxvdzog MTkzIAo+PiBhbHJlYWR5IGluIHF1ZXVlIGF3YWl0aW5nIGFjY2VwdGFuY2UgKDMwNjggb2NjdXJy ZW5jZXMpCj4+IHNvbmV3Y29ubjogcGNiIDB4ZmZmZmY4MDA0ZDllZDE4ODogTGlzdGVuIHF1ZXVl IG92ZXJmbG93OiAxOTMgCj4+IGFscmVhZHkgaW4gcXVldWUgYXdhaXRpbmcgYWNjZXB0YW5jZSAo MzA1NyBvY2N1cnJlbmNlcykKPj4gc29uZXdjb25uOiBwY2IgMHhmZmZmZjgwMDRkOWVkMTg4OiBM aXN0ZW4gcXVldWUgb3ZlcmZsb3c6IDE5MyAKPj4gYWxyZWFkeSBpbiBxdWV1ZSBhd2FpdGluZyBh Y2NlcHRhbmNlICgzMDM3IG9jY3VycmVuY2VzKQo+PiBzb25ld2Nvbm46IHBjYiAweGZmZmZmODAw NGQ5ZWQxODg6IExpc3RlbiBxdWV1ZSBvdmVyZmxvdzogMTkzIAo+PiBhbHJlYWR5IGluIHF1ZXVl IGF3YWl0aW5nIGFjY2VwdGFuY2UgKDMwMTUgb2NjdXJyZW5jZXMpCj4+IHNvbmV3Y29ubjogcGNi IDB4ZmZmZmY4MDA0ZDllZDE4ODogTGlzdGVuIHF1ZXVlIG92ZXJmbG93OiAxOTMgCj4+IGFscmVh ZHkgaW4gcXVldWUgYXdhaXRpbmcgYWNjZXB0YW5jZSAoMzAzNSBvY2N1cnJlbmNlcykKPj4KPj4g SSBndWVzcyB0aGlzIGlzIHRoZSBlZmZlY3Qgb2YgdGhlIHByb2Nlc3MgZnJlZXplLCBub3QgdGhl IGNhdXNlICh0aGUgCj4+IGxpc3RlbiBxdWV1ZSBmaWxscyB1cCBiZWNhdXNlIHRoZSBhcHAgY2Fu J3QgaGFuZGxlIHRoZSBpbmNvbWluZyAKPj4gY29ubmVjdGlvbnMpLgo+Pgo+PiBJJ20gbm90IHN1 cmUgaXQgbWF0dGVycywgYnV0IHNvbWUgb2YgdGhlIG1hY2hpbmVzIChhbmQgdGhlIGFib3ZlKSAK Pj4gcnVucyBvbiBhbiBFU1ggaHlwZXJ2aXNvciAoYnV0IGFzIGZhciBhcyBJIGNhbiByZW1lbWJl ciwgSSBjb3VsZCBzZWUgCj4+IHRoaXMgb24gcGh5c2ljYWwgbWFjaGluZXMgdG9vLCBidXQgSSdt IG5vdCBzdXJlIGFib3V0IHRoYXQpLgo+PiBBbHNvIC1zbyBmYXItIEkgY291bGQgb25seSBzZWUg dGhpcyB3aGVyZSBzb21lICJleG90aWMiIHN0dWZmIHJhbiwgCj4+IGxpa2UgYSBqYXZhIG9yIGVy bGFuZyBiYXNlZCBzZXJ2ZXIgKG9wZW5kaiwgZWxhc3RpY3NlYXJjaCBhbmQgCj4+IHJhYmJpdG1x KS4KPj4KPj4gQWxzbyBub3Qgc3VyZSBhYm91dCB3aGljaCB0cmlnZ2VycyB0aGlzLiBJJ3ZlIG5l dmVyIHNlZW4gdGhpcyBhZnRlciAKPj4gc29tZSBob3VycyBvZiB1cHRpbWUsIGF0IGxlYXN0IHNv bWUgZGF5cyBvciBhIHdlZWsgbXVzdCd2ZSBiZWVuIAo+PiBwYXNzZWQgdG8gZ2V0IHN0dWNrIGxp a2UgdGhlIGFib3ZlLgo+Pgo+PiBBbnkgaWRlYXMgYWJvdXQgdGhpcz8KPj4KPj4gVGhhbmtzLAo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiAgZnJl ZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4+ICBodHRwczovL2xpc3RzLmZy ZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKPj4gVG8gdW5zdWJzY3Jp YmUsIHNlbmQgYW55IG1haWwgdG8gIiBmcmVlYnNkLXN0YWJsZS11bnN1YnNjcmliZUBmcmVlYnNk Lm9yZyAiCj4KPgo+Cj4tLSAKPkRpcGwuLUluZi4gWmFyYSBLYW5hZXZhCj5IZWlkZWxiZXJnZXIg QWthZGVtaWUgZGVyIFdpc3NlbnNjaGFmdGVuCj5Gb3JzY2h1bmdzc3RlbGxlICJUaGUgcm9sZSBv ZiBjdWx0dXJlIGluIGVhcmx5IGV4cGFuc2lvbnMgb2YgaHVtYW5zIgo+YW4gZGVyIFVuaXZlcnNp dD90IFQ/YmluZ2VuCj5HZW9ncmFwaGlzY2hlcyBJbnN0aXR1dAo+VW5pdmVyc2l0P3QgVD9iaW5n ZW4KPlJ1ZW1lbGluc3RyLiAxOS0yMwo+NzIwNzAgVHVlYmluZ2VuCj4KPlRlbC46ICs0OS0oMCk3 MDcxLTI5NzIxMzIKPmUtbWFpbDogIHphcmEua2FuYWV2YUBnZW9ncmFwaGllLnVuaS10dWViaW5n ZW4uZGUKPi0tLS0tLS0KPi0gVGhlb3J5IGlzIHdoZW4geW91IGtub3cgc29tZXRoaW5nIGJ1dCBp dCBkb2Vzbid0IHdvcmsuCj4tIFByYWN0aWNlIGlzIHdoZW4gc29tZXRoaW5nIHdvcmtzIGJ1dCB5 b3UgZG9uJ3Qga25vdyB3aHkuCj4tIFVzdWFsbHkgd2UgY29tYmluZSB0aGVvcnkgYW5kIHByYWN0 aWNlOgo+wqDCoMKgwqDCoMKgwqDCoMKgTm90aGluZyB3b3JrcyBhbmQgd2UgZG9uJ3Qga25vdyB3 aHkuCj4KPgo+Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+TWVzc2FnZTogMgo+ RGF0ZTogVHVlLCAyNyBPY3QgMjAxNSAxNzoyNTowMSArMDEwMAo+RnJvbTogIk5hZ3ksIEF0dGls YSIgPCBicmFAZnNuLmh1ID4KPlRvOiBaYXJhIEthbmFldmEgPCB6YXJhLmthbmFldmFAZ2dpLnVu aS10dWViaW5nZW4uZGUgPiwKPmZyZWVic2Qtc3RhYmxlQGZyZWVic2Qub3JnCj5TdWJqZWN0OiBS ZTogU3R1Y2sgcHJvY2Vzc2VzIGluIHVua2lsbGFibGUgKFNUT1ApIHN0YXRlLCBsaXN0ZW4gcXVl dWUKPm92ZXJmbG93Cj5NZXNzYWdlLUlEOiA8IDU2MkZBNTVELjYwNTA1MDNAZnNuLmh1ID4KPkNv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtODsgZm9ybWF0PWZsb3dlZAo+Cj5I aSwKPgo+KGZvbGxvd2luZyB0b3Bwb3N0aW5nKQo+SSBoYXZlIHNlZW4gdGhpcyB3aXRoIDE2IGFu ZCAzMiBHaUIgb2YgUkFNLCBidXQgYW55d2F5cywgaXQgc2hvdWxkbid0IAo+bWF0dGVyLgo+RG8g eW91IHVzZSB6ZnM/IEFsdGhvdWdoIGl0IGRvZXNuJ3Qgc2VlbSB0byBiZSBzdHVjayBvbiBJTy4u Lgo+Cj5PbiAxMC8yNy8xNSAxNDo0MiwgWmFyYSBLYW5hZXZhIHdyb3RlOgo+PiBIZWxsbywKPj4K Pj4gSSBoYXZlIHRoZSBzYW1lIGV4cGVyaWVuY2Ugd2l0aCBhcGFjaGUgYW5kIG1hcHNlcnZlci4g SXQgaGFwcGVucyBvbiAKPj4gcGh5c2ljYWwgbWFjaGluZSBhbmQgZW5kcyB3aXRoIHNwb250YW5l b3VzIHJlYm9vdC4gVGhpcyBtYWNoaW5lIGlzIAo+PiB1cGRhdGVkIGZyb20gRlJFRUJTRCA5LjAg UkVMRUFTRSB0byBGUkVFQlNEIDEwLjItUFJFUkVMRUFTRS4gUGVyaGFwcyAKPj4gdGhpcyBtYWNo aW5lIGRvZXNuJ3QgaGF2ZSBlbm91Z2ggUkFNIChvbmx5IDhHQiksIGJ1dCBJIHRoaW5rIHRoYXQg bXVzdCAKPj4gbm90IGJlIGEgcmVhc29uIGZvciBhIHNwb250YW5lb3VzIHJlYm9vdC4KPj4KPj4g SSBoYWQgbm8gc3VjaCBiZWhhdmlvciB3aXRoIHRoZSBzYW1lIG1hY2hpbmUgYW5kIEZSRUVCU0Qg OS4wIFJFTEVBU0UgCj4+IG9uIGl0IChJIGFtIG5vdCAxMDAlIHN1cmUsIEkgaGF2ZSB5ZXQgbm8g cG9zc2liaWxpdHkgdG8gdGVzdCBpdCkuCj4+Cj4+IFJlZ2FyZHMsIFouIEthbmFldmEuCj4KCg== From owner-freebsd-stable@freebsd.org Thu Oct 29 10:00:39 2015 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 AFC50A1EFB3 for ; Thu, 29 Oct 2015 10:00:39 +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 7054215CC for ; Thu, 29 Oct 2015 10:00:38 +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 D3C0328436; Thu, 29 Oct 2015 11:00:34 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-49-111.net.upcbroadband.cz [89.177.49.111]) (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 D229428422; Thu, 29 Oct 2015 11:00:32 +0100 (CET) Message-ID: <5631EE40.3020404@quip.cz> Date: Thu, 29 Oct 2015 11:00:32 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: stable/10: high load average when box is idle References: <20151027050508.GA7612@icarus.home.lan> In-Reply-To: <20151027050508.GA7612@icarus.home.lan> 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.20 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, 29 Oct 2015 10:00:39 -0000 Jeremy Chadwick wrote on 10/27/2015 06:05: > (I am not subscribed to the mailing list, please keep me CC'd) > > Issue: a stable/10 system that has an abnormally high load average (e.g. > 0.15, but may be higher depending on other variables which I can't > account for) when the machine is definitely idle (i.e. cannot be traced > to high interrupt usage per vmstat -i, cannot be traced to a userland > process or kernel thread, etc.). > > This problem has been discussed many times on the FreeBSD mailing lists > and the FreeBSD forum (including some folks seeing it on 9.x, but my > complaint here is focused on 10.x so please focus there). > > I'd politely like to request that anyone experiencing this, or who has > experienced it (and if you know when it stopped or why, including what > you may have done, include that), to chime in on this ticket from 2012 > (made for 9.x but style of issue still applies; c#5 is quite valid): > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 > > For those still experiencing it, I'd suggest reading c#8 and seeing if > sysctl kern.eventtimer.periodic=1 relieves the problem for you. (At > this time I would not suggest leaving that set indefinitely, as it does > seem to increase the interrupt rate in cpuX:timer in vmstat -i. But for > me kern.eventtimer.periodic=1 "fixes" the issue) Is it on real HW server or in some kind of virtualization? I am seeing load 0.5 - 1.2 on three virtual machines in VMware. The machines are without any traffic. Just fresh instalation of FreeBSD 10.1 and some services without any public content. Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Oct 29 10:09:13 2015 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 D4B6EA1F33E for ; Thu, 29 Oct 2015 10:09:13 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A61B91BB6 for ; Thu, 29 Oct 2015 10:09:13 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-12v.sys.comcast.net with comcast id ay9B1r0035BUCh401y9Buq; Thu, 29 Oct 2015 10:09:11 +0000 Received: from jdc.koitsu.org ([69.181.142.213]) by resomta-po-16v.sys.comcast.net with comcast id ay9A1r0074cTVs501y9AEn; Thu, 29 Oct 2015 10:09:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5E7801AF13D; Thu, 29 Oct 2015 03:09:10 -0700 (PDT) Date: Thu, 29 Oct 2015 03:09:10 -0700 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org Subject: Re: stable/10: high load average when box is idle Message-ID: <20151029100910.GA52255@icarus.home.lan> References: <20151027050508.GA7612@icarus.home.lan> <5631EE40.3020404@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5631EE40.3020404@quip.cz> User-Agent: Mutt/1.5.24 (2015-08-30) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446113351; bh=sYV+6ea9x8bsRKdti9b46z+27wP/SuA5NP8v93rYAiY=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=INjCnUn2RNwjIWa2uMQsGLolAgDzQ6gkAbA5Jdg7UjtHkiV5YQH5pOGMGE1ZvQtqV mNuq7KZivXL16obV56XZN8Sql2ZW1hncpVseVtz51QJfZPmaXShQkmd4ispc2k/Q6F 9pJ0ofoqZLkhSgp9iH/FhX0M2+8mnCVX/zHvUo13pmls8AAOOB/d9ABU80vEf+xN3n PIXuyi24/oQqUtrToNQG0jv0sjOa/SYEGboSPxIlxYdJX8W36cDXVnevWE7zCQVsh9 WCu2eQjs2EI2qTrG3gyl0mRP0YWF+qnju2eV9ugDZBpjX/oqgzxmoxIhOcUEr5kRGl qD2F3P405nJuQ== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 10:09:14 -0000 On Thu, Oct 29, 2015 at 11:00:32AM +0100, Miroslav Lachman wrote: > Jeremy Chadwick wrote on 10/27/2015 06:05: > >(I am not subscribed to the mailing list, please keep me CC'd) > > > >Issue: a stable/10 system that has an abnormally high load average (e.g. > >0.15, but may be higher depending on other variables which I can't > >account for) when the machine is definitely idle (i.e. cannot be traced > >to high interrupt usage per vmstat -i, cannot be traced to a userland > >process or kernel thread, etc.). > > > >This problem has been discussed many times on the FreeBSD mailing lists > >and the FreeBSD forum (including some folks seeing it on 9.x, but my > >complaint here is focused on 10.x so please focus there). > > > >I'd politely like to request that anyone experiencing this, or who has > >experienced it (and if you know when it stopped or why, including what > >you may have done, include that), to chime in on this ticket from 2012 > >(made for 9.x but style of issue still applies; c#5 is quite valid): > > > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 > > > >For those still experiencing it, I'd suggest reading c#8 and seeing if > >sysctl kern.eventtimer.periodic=1 relieves the problem for you. (At > >this time I would not suggest leaving that set indefinitely, as it does > >seem to increase the interrupt rate in cpuX:timer in vmstat -i. But for > >me kern.eventtimer.periodic=1 "fixes" the issue) > > Is it on real HW server or in some kind of virtualization? I am seeing load > 0.5 - 1.2 on three virtual machines in VMware. The machines are without any > traffic. Just fresh instalation of FreeBSD 10.1 and some services without > any public content. I've seen it on both bare-metal and VMs. Please see c#8 in the ticket; there's an itemised list of where I've seen it, but I'm sure it's not limited to just those. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@freebsd.org Thu Oct 29 11:47:15 2015 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 9308AA20F12 for ; Thu, 29 Oct 2015 11:47:15 +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 52379131F for ; Thu, 29 Oct 2015 11:47:14 +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 67CF028435; Thu, 29 Oct 2015 12:47:09 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-49-111.net.upcbroadband.cz [89.177.49.111]) (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 6BFDA2842F; Thu, 29 Oct 2015 12:47:03 +0100 (CET) Message-ID: <56320737.2060901@quip.cz> Date: Thu, 29 Oct 2015 12:47:03 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Jeremy Chadwick CC: freebsd-stable@freebsd.org Subject: Re: stable/10: high load average when box is idle References: <20151027050508.GA7612@icarus.home.lan> <5631EE40.3020404@quip.cz> <20151029100910.GA52255@icarus.home.lan> In-Reply-To: <20151029100910.GA52255@icarus.home.lan> 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.20 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, 29 Oct 2015 11:47:15 -0000 Jeremy Chadwick wrote on 10/29/2015 11:09: > On Thu, Oct 29, 2015 at 11:00:32AM +0100, Miroslav Lachman wrote: >> Jeremy Chadwick wrote on 10/27/2015 06:05: >>> (I am not subscribed to the mailing list, please keep me CC'd) >>> >>> Issue: a stable/10 system that has an abnormally high load average (e.g. >>> 0.15, but may be higher depending on other variables which I can't >>> account for) when the machine is definitely idle (i.e. cannot be traced >>> to high interrupt usage per vmstat -i, cannot be traced to a userland >>> process or kernel thread, etc.). >>> >>> This problem has been discussed many times on the FreeBSD mailing lists >>> and the FreeBSD forum (including some folks seeing it on 9.x, but my >>> complaint here is focused on 10.x so please focus there). >>> >>> I'd politely like to request that anyone experiencing this, or who has >>> experienced it (and if you know when it stopped or why, including what >>> you may have done, include that), to chime in on this ticket from 2012 >>> (made for 9.x but style of issue still applies; c#5 is quite valid): >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541 >>> >>> For those still experiencing it, I'd suggest reading c#8 and seeing if >>> sysctl kern.eventtimer.periodic=1 relieves the problem for you. (At >>> this time I would not suggest leaving that set indefinitely, as it does >>> seem to increase the interrupt rate in cpuX:timer in vmstat -i. But for >>> me kern.eventtimer.periodic=1 "fixes" the issue) >> >> Is it on real HW server or in some kind of virtualization? I am seeing load >> 0.5 - 1.2 on three virtual machines in VMware. The machines are without any >> traffic. Just fresh instalation of FreeBSD 10.1 and some services without >> any public content. > > I've seen it on both bare-metal and VMs. Please see c#8 in the ticket; > there's an itemised list of where I've seen it, but I'm sure it's not > limited to just those. OK, I have read your c#8 and did some tests on our affected VMs. With sysctl kern.eventtimer.periodic=1 it is better. Where previously load were about 0.40 is 0.15 now. One of these three systems is FreeBSD 10.2 and on this machine the positive effect of kern.eventtimer.periodic=1 is more visible - load is now 0.00 - 0.05. I don't know if this is some coincidence or something is different in 10.2. Settings of kern.eventtimer is the same on all VMs kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.et.LAPIC.frequency: 35071418 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.choice: LAPIC(600) i8254(100) RTC(0) kern.eventtimer.singlemul: 4 kern.eventtimer.idletick: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.periodic: 1 Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Oct 29 14:24:53 2015 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 C3711A210D0 for ; Thu, 29 Oct 2015 14:24:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D08319B5 for ; Thu, 29 Oct 2015 14:24:53 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1473768B for ; Thu, 29 Oct 2015 17:24:52 +0300 (MSK) Reply-To: lev@FreeBSD.org To: freebsd-stable From: Lev Serebryakov Subject: 10-STABLE buildworld fails at very early stage X-Enigmail-Draft-Status: N0110 Organization: FreeBSD Message-ID: <56322C32.3050702@FreeBSD.org> Date: Thu, 29 Oct 2015 17:24:50 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 14:24:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have this in /etc/src.conf (it is only one line here): MAKEOBJDIRPREFIX=/usr/home/build/obj % cd /usr/src % sudo svn up Updating '.': At revision 290139. % sudo make buildworld [one screen of output] set -e; cd /usr/src/tools/build; make buildincludes; make installinclude s sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/home/build/obj/legacy/usr/lib install: /usr/home/build/obj/legacy/usr/lib: No such file or directory *** Error code 71 Stop. make[3]: stopped in /usr/src/tools/build *** Error code 1 % uname -v FreeBSD 10.2-PRERELEASE #7 r286065: Thu Jul 30 21:27:35 MSK 2015 root@:/usr/obj/usr/src/sys/BLOB % - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1iwQAKB0mwW2w9Ablws1vxcTUmCC zEPI7zcGi/wu/Xw6w8exsYvwr5nsEKyTCrc9zV2CmwuXoY23Xqk4r1Atl0XXL9eF 5P2fjzNxK8w1NI6PYY6kmw64JpcA1MQKZwizNzE+uhoKkTkX9PQYYGbVOJlNT6v6 7OaQYbsGPwlyRXC0nRWZW1izClIs7XqMFwo+q0oX12/oPZypwPxQsk6KsPym+WQN uL3ENoa13AnGbc7YY4omO/6Yvi3yIP1tIRUSre1s+ES7/gIKw62uHT0JuCpdCoEL G1cC9Zq4irGQYJlgR2HEjypTJ09Flzs4rgOmmV/Oj8xJw8N/JGJp0X9NkDHMtkSO KF+x1cwm+lJeDVNoz0NsJXfMpo33SiKwaTYQiQUhvRQOUpVsWzaC4KV5aNfRFa3/ uDkV7KCJETOQuYC4H7SCRn2KFRp6uxAh/UMXj3XZpwx5VzDI3CxgBx6DMxJF4/zD +eKIPPdcbGY1rRW5I375Cw/pZv3rYMni3ruPQibXeezD9TJ6YP48gTWKwtcpKiTe UmJ5IE6gn3PhyPBZjGBqsfnvxLMBw29GwqEE6bBRtQbYrhy3GfBJeShkc2nCR7c2 yv8zcgP2yBjBs+SyBrJvGkHEUxM4gaomkVqMvDsGgFixneOoSquna88S2YCA6mBY Ik+aukkDLIYCxqbbE6AA =+GmP -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Thu Oct 29 15:46:38 2015 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 50A00A21176 for ; Thu, 29 Oct 2015 15:46:38 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.5.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtpserv.uni-tuebingen.de", Issuer "Global-UNITUE-CA 01" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAB80127E for ; Thu, 29 Oct 2015 15:46:37 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from webmail2.uni-tuebingen.de (webmail2.uni-tuebingen.de [134.2.5.195]) by mx08.uni-tuebingen.de (8.14.3/8.14.3) with ESMTP id t9TFkTS8006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2015 16:46:29 +0100 Received: from webmail2.uni-tuebingen.de (localhost [127.0.0.1]) by webmail2.uni-tuebingen.de (Postfix) with ESMTPS id D63562CF6C1; Thu, 29 Oct 2015 16:46:25 +0100 (CET) Received: from roceehbwz.rue23.uni-tuebingen.de (roceehbwz.rue23.uni-tuebingen.de [134.2.216.120]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Thu, 29 Oct 2015 16:46:25 +0100 Date: Thu, 29 Oct 2015 16:46:25 +0100 Message-ID: <20151029164625.Horde.xUq7LWav-EtuUEJ1LMs31F1@webmail.uni-tuebingen.de> From: Zara Kanaeva To: =?utf-8?b?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= Cc: freebsd-stable@freebsd.org Subject: Re: Stuck processes in unkillable (STOP) state, listen queue overflow References: <1446080762.820771804@f25.i.mail.ru> In-Reply-To: <1446080762.820771804@f25.i.mail.ru> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 11490 X-purgate-ID: 154962::1446133589-00000C17-CD542F68/0/0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 15:46:38 -0000 Hello Дмитрий, thank you very much for your message. First of all: I like FreeBSD (the installation logic, the good documentation etc.), this is why I use FreeBSD as Server OS. But in my case I must desagree your strong theoretical probability consideration. In my case I have one machine (7 years old), that had 1-2 spontaneous rebootes in a year. In my case I got a lot of "already in queue awaiting acceptance"-Errors and the machine rebootes immediately after this. I will get soon a new replacement for this old machine with at least 32 GB RAM and (of course) new power supply. So I will see if my problem (perhaps it is only my problem) still persist. Greetings, Z. Kanaeva. Zitat von Дмитрий Долбнин : > Good day everyone ! > From my point of view it seems like you're experiencing the > "downgraded" hardware performance which causes you the problems you > meet. > Try to switch for the "new-one" power supply at least. > Why I think so ? Because the bad power supplies are met much more > often than the bad source code for FreeBSD. Of course I can't tell > you you're completely wrong. > Best regards, Dimitry. >> Среда, 28 октября 2015, 12:00 UTC от freebsd-stable-request@freebsd.org: >> >> Send freebsd-stable mailing list submissions to >> freebsd-stable@freebsd.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> or, via email, send a message with subject or body 'help' to >> freebsd-stable-request@freebsd.org >> >> You can reach the person managing the list at >> freebsd-stable-owner@freebsd.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of freebsd-stable digest..." >> >> >> Today's Topics: >> >>    1. Re: Stuck processes in unkillable (STOP) state, listen queue >>       overflow (Zara Kanaeva) >>    2. Re: Stuck processes in unkillable (STOP) state, listen queue >>       overflow (Nagy, Attila) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 27 Oct 2015 14:42:42 +0100 >> From: Zara Kanaeva < zara.kanaeva@ggi.uni-tuebingen.de > >> To: freebsd-stable@freebsd.org >> Subject: Re: Stuck processes in unkillable (STOP) state, listen queue >> overflow >> Message-ID: >> < 20151027144242.Horde.3Xc1_RqzaVMAZ12X6OPXfdN@webmail.uni-tuebingen.de > >> >> Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes >> >> Hello, >> >> I have the same experience with apache and mapserver. It happens on >> physical machine and ends with spontaneous reboot. This machine is >> updated from FREEBSD 9.0 RELEASE to FREEBSD 10.2-PRERELEASE. Perhaps >> this machine doesn't have enough RAM (only 8GB), but I think that must >> not be a reason for a spontaneous reboot. >> >> I had no such behavior with the same machine and FREEBSD 9.0 RELEASE >> on it (I am not 100% sure, I have yet no possibility to test it). >> >> Regards, Z. Kanaeva. >> >> Zitat von "Nagy, Attila" < bra@fsn.hu >: >> >>> Hi, >>> >>> Recently I've started to see a lot of cases, where the log is full >>> with "listen queue overflow" messages and the process behind the >>> network socket is unavailable. >>> When I open a TCP to it, it opens but nothing happens (for example I >>> get no SMTP banner from postfix, nor I get a log entry about the new >>> connection). >>> >>> I've seen this with Java programs, postfix and redis, basically >>> everything which opens a TCP and listens on the machine. >>> >>> For example, I have a redis process, which listens on 6381. When I >>> telnet into it, the TCP opens, but the program doesn't respond. >>> When I kill it, nothing happens. Even with kill -9 yields only this state: >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME >>> WCPU COMMAN >>> 776 redis 2 20 0 24112K 2256K STOP 3 16:56 >>> 0.00% redis- >>> >>> When I tcpdrop the connections of the process, tcpdrop reports >>> success for the first time and failure for the second (No such >>> process), but the connections remain: >>> # sockstat -4 | grep 776 >>> redis redis-serv 776 6 tcp4 *:6381 *:* >>> redis redis-serv 776 9 tcp4 *:16381 *:* >>> redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 >>> redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 >>> redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 >>> redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 >>> redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 >>> redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 >>> redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 >>> redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 >>> # sockstat -4 | grep 776 | awk '{print "tcpdrop "$6" "$7}' | /bin/sh >>> tcpdrop: getaddrinfo: * port 6381: hostname nor servname provided, >>> or not known >>> tcpdrop: getaddrinfo: * port 16381: hostname nor servname provided, >>> or not known >>> tcpdrop: 127.0.0.1 16381 127.0.0.1 10460: No such process >>> tcpdrop: 127.0.0.1 16381 127.0.0.1 35795: No such process >>> tcpdrop: 127.0.0.1 30027 127.0.0.1 16379: No such process >>> tcpdrop: 127.0.0.1 58802 127.0.0.1 16384: No such process >>> tcpdrop: 127.0.0.1 16381 127.0.0.1 24354: No such process >>> tcpdrop: 127.0.0.1 16381 127.0.0.1 56999: No such process >>> tcpdrop: 127.0.0.1 16381 127.0.0.1 39488: No such process >>> tcpdrop: 127.0.0.1 6381 127.0.0.1 39491: No such process >>> # sockstat -4 | grep 776 >>> redis redis-serv 776 6 tcp4 *:6381 *:* >>> redis redis-serv 776 9 tcp4 *:16381 *:* >>> redis redis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460 >>> redis redis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795 >>> redis redis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379 >>> redis redis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384 >>> redis redis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354 >>> redis redis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999 >>> redis redis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488 >>> redis redis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491 >>> >>> $ procstat -k 776 >>> PID TID COMM TDNAME KSTACK >>> 776 100725 redis-server - mi_switch >>> sleepq_timedwait_sig _sleep kern_kevent sys_kevent amd64_syscall >>> Xfast_syscall >>> 776 100744 redis-server - mi_switch >>> thread_suspend_switch thread_single exit1 sigexit postsig ast >>> doreti_ast >>> >>> I can do nothing to get out from this state, only reboot helps. >>> >>> The OS is stable/10@r289313, but I could observe this behaviour with >>> earlier releases too. >>> >>> The dmesg is full with lines like these: >>> sonewconn: pcb 0xfffff8004dc54498: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3142 occurrences) >>> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3068 occurrences) >>> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3057 occurrences) >>> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3037 occurrences) >>> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3015 occurrences) >>> sonewconn: pcb 0xfffff8004d9ed188: Listen queue overflow: 193 >>> already in queue awaiting acceptance (3035 occurrences) >>> >>> I guess this is the effect of the process freeze, not the cause (the >>> listen queue fills up because the app can't handle the incoming >>> connections). >>> >>> I'm not sure it matters, but some of the machines (and the above) >>> runs on an ESX hypervisor (but as far as I can remember, I could see >>> this on physical machines too, but I'm not sure about that). >>> Also -so far- I could only see this where some "exotic" stuff ran, >>> like a java or erlang based server (opendj, elasticsearch and >>> rabbitmq). >>> >>> Also not sure about which triggers this. I've never seen this after >>> some hours of uptime, at least some days or a week must've been >>> passed to get stuck like the above. >>> >>> Any ideas about this? >>> >>> Thanks, >>> _______________________________________________ >>> 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 " >> >> >> >> -- >> Dipl.-Inf. Zara Kanaeva >> Heidelberger Akademie der Wissenschaften >> Forschungsstelle "The role of culture in early expansions of humans" >> an der Universit?t T?bingen >> Geographisches Institut >> Universit?t T?bingen >> Ruemelinstr. 19-23 >> 72070 Tuebingen >> >> Tel.: +49-(0)7071-2972132 >> e-mail: zara.kanaeva@geographie.uni-tuebingen.de >> ------- >> - Theory is when you know something but it doesn't work. >> - Practice is when something works but you don't know why. >> - Usually we combine theory and practice: >>          Nothing works and we don't know why. >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 27 Oct 2015 17:25:01 +0100 >> From: "Nagy, Attila" < bra@fsn.hu > >> To: Zara Kanaeva < zara.kanaeva@ggi.uni-tuebingen.de >, >> freebsd-stable@freebsd.org >> Subject: Re: Stuck processes in unkillable (STOP) state, listen queue >> overflow >> Message-ID: < 562FA55D.6050503@fsn.hu > >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Hi, >> >> (following topposting) >> I have seen this with 16 and 32 GiB of RAM, but anyways, it shouldn't >> matter. >> Do you use zfs? Although it doesn't seem to be stuck on IO... >> >> On 10/27/15 14:42, Zara Kanaeva wrote: >>> Hello, >>> >>> I have the same experience with apache and mapserver. It happens on >>> physical machine and ends with spontaneous reboot. This machine is >>> updated from FREEBSD 9.0 RELEASE to FREEBSD 10.2-PRERELEASE. Perhaps >>> this machine doesn't have enough RAM (only 8GB), but I think that must >>> not be a reason for a spontaneous reboot. >>> >>> I had no such behavior with the same machine and FREEBSD 9.0 RELEASE >>> on it (I am not 100% sure, I have yet no possibility to test it). >>> >>> Regards, Z. Kanaeva. >> > > _______________________________________________ > 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" -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kanaeva@geographie.uni-tuebingen.de ------- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. From owner-freebsd-stable@freebsd.org Thu Oct 29 16:03:41 2015 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 E52EAA21694 for ; Thu, 29 Oct 2015 16:03:41 +0000 (UTC) (envelope-from alonsoschaich@fastmail.fm) 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 B428B1115 for ; Thu, 29 Oct 2015 16:03:41 +0000 (UTC) (envelope-from alonsoschaich@fastmail.fm) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 77DAD200BE for ; Thu, 29 Oct 2015 12:03:40 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute5.internal (MEProxy); Thu, 29 Oct 2015 12:03:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=UqMKINsNLZdy9Eo9oapQMO8CIZY=; b=ddfUx/ sEiHCPnOp4KiXDS3X5Xp9TcSkVHs1h6guGTJN3SAj2IjnuLel3e6H76FJp/MH3hC JBpIHazunPLyTLVinweAOHXWuUMVsT7UyjyzybNO4/s7AlTQsiy8F4CQHnUusBaL 8/y4zheusdHBIy93+zAKmvnvhlLaEjNUONQK4= 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-sasl-enc:x-sasl-enc; s=smtpout; bh=UqMKINsNLZdy9Eo 9oapQMO8CIZY=; b=Bj0zcFGr+HQ4kVKpX9vXMe8dAtusQLEHIDT7N7JsRLIqYx5 CnmlBxINfhG+zFMA5xHIZhWdLEna0DMUTETxrm/RYe0CWabpOOSmy/2WxJ8cRdDv ySAP3MCcZEmK2lnNIyWpippHhsYhOoebf7cXiN7hueKxmFI8RhamjYX3r88o= Received: by web4.nyi.internal (Postfix, from userid 99) id 4D9F4113013; Thu, 29 Oct 2015 12:03:40 -0400 (EDT) Message-Id: <1446134620.1705238.423745281.4EA8E7BA@webmail.messagingengine.com> X-Sasl-Enc: JcBFDHWwhJQkm6zcq6M+t6pc2/jglKl4PAB68rus/A68 1446134620 From: Schaich Alonso To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-55962f6b In-Reply-To: <20151029164625.Horde.xUq7LWav-EtuUEJ1LMs31F1@webmail.uni-tuebingen.de> References: <1446080762.820771804@f25.i.mail.ru> <20151029164625.Horde.xUq7LWav-EtuUEJ1LMs31F1@webmail.uni-tuebingen.de> Subject: Re: Stuck processes in unkillable (STOP) state, listen queue overflow Date: Thu, 29 Oct 2015 17:03:40 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 16:03:42 -0000 On Thu, Oct 29, 2015, at 16:46, Zara Kanaeva wrote: > Hello =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9, >=20 > thank you very much for your message. >=20 > First of all: I like FreeBSD (the installation logic, the good=20=20 > documentation etc.), this is why I use FreeBSD as Server OS. But in my=20= =20 > case I must desagree your strong theoretical probability=20=20 > consideration. In my case I have one machine (7 years old), that had=20=20 > 1-2 spontaneous rebootes in a year. In my case I got a lot of "already=20= =20 > in queue awaiting acceptance"-Errors and the machine rebootes=20=20 > immediately after this. >=20 > I will get soon a new replacement for this old machine with at least=20=20 > 32 GB RAM and (of course) new power supply. So I will see if my=20=20 > problem (perhaps it is only my problem) still persist. >=20 > Greetings, Z. Kanaeva. >=20 I've had resetting network interfaces combined with the queue overflow warnings on 3 different machines with 5 different NICs and 3 differnt PSUs. It disappeared when I updated to FreeBSD-10 two years ago, so I assumed the cause of this to have either been fixed or workarounded. From owner-freebsd-stable@freebsd.org Thu Oct 29 16:54:41 2015 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 2C262A202A9 for ; Thu, 29 Oct 2015 16:54:41 +0000 (UTC) (envelope-from smkelly@smkelly.org) 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 EF8101CFD for ; Thu, 29 Oct 2015 16:54:40 +0000 (UTC) (envelope-from smkelly@smkelly.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4CA7E208AF for ; Thu, 29 Oct 2015 12:54:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 29 Oct 2015 12:54:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=smkelly.org; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=d1dkIn2oevSuCr9FZca2sVS9GJQ =; b=mLpAF1WujJV01TacWosWgmvrdCd4a1xIGVmBWIgxFjwphdYdPGdqY6F23Q0 lLx1SGMg5EpvJ79Fz/8uEUmf2zMO/aDY4/+gx2dwAOkrmoh6ISFRb8mPr/81Oe/J gIbmnPcCTWSpu9Ztw+qROkg2JRPMUYIzcVnt9ASaAJnw0VD4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=d1 dkIn2oevSuCr9FZca2sVS9GJQ=; b=mgH77TEA2nYRCP6em1+eaUbEp8/eruUg+G JChH9+fx6HAoMbNYG8iEFlG6HKbMLx2qaXFv6ULaZKROnLeWzluJT1D3JVxknpA+ peMklX+EiN7ffbtli+wZhauwisH/i99PXCGJrPqehhshMYu8G2cifREhZ3nC/t+7 dQD7Jg+zc= X-Sasl-enc: yfi/stil/bMFiI+4y1SR73VK24w82Q69fo9Ql3ivM+do 1446137678 Received: from tardis.gwp.corp.flightaware.com (unknown [38.100.147.146]) by mail.messagingengine.com (Postfix) with ESMTPA id EA90CC00014 for ; Thu, 29 Oct 2015 12:54:38 -0400 (EDT) From: Sean Kelly Subject: ZFS, SSDs, and TRIM performance Message-Id: <449F8F4D-425D-46B5-BB9C-BE5A0CD11C55@smkelly.org> Date: Thu, 29 Oct 2015 11:54:38 -0500 To: FreeBSD-STABLE Mailing List Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3106\)) X-Mailer: Apple Mail (2.3106) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 16:54:41 -0000 Me again. I have a new issue and I=E2=80=99m not sure if it is hardware = or software. I have nine servers running 10.2-RELEASE-p5 with Dell = OEM=E2=80=99d Samsung XS1715 NVMe SSDs. They are paired up in a single = mirrored zpool on each server. They perform great most of the time. = However, I have a problem when ZFS fires off TRIMs. Not during vdev = creation, but like if I delete a 20GB snapshot. If I destroy a 20GB snapshot or delete large files, ZFS fires off tons = of TRIMs to the disks. I can see the kstat.zfs.misc.zio_trim.success and = kstat.zfs.misc.zio_trim.bytes sysctls skyrocket. While this is = happening, any synchronous writes seem to block. For example, we=E2=80=99r= e running PostgreSQL which does fsync()s all the time. While these TRIMs = happen, Postgres just hangs on writes. This causes reads to block due to = lock contention as well. If I change sync=3Ddisabled on my tank/pgsql dataset while this is = happening, it unblocks for the most part. But obviously this is not an = ideal way to run PostgreSQL. I=E2=80=99m working with my vendor to get some Intel SSDs to test, but = any ideas if this could somehow be a software issue? Or does the Samsung = XS1715 just suck at TRIM and SYNC? We=E2=80=99re thinking of just setting the vfs.zfs.trim.enabled=3D0 = tunable for now since WAL segment turnover actually causes TRIM = operations a lot, but unfortunately this is a reboot. But disabling TRIM = does seem to fix the issue on other servers I=E2=80=99ve tested with the = same hardware config. --=20 Sean Kelly smkelly@smkelly.org http://smkelly.org From owner-freebsd-stable@freebsd.org Thu Oct 29 18:22:32 2015 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 3D62EA21438 for ; Thu, 29 Oct 2015 18:22:32 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E448D1C4B for ; Thu, 29 Oct 2015 18:22:31 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wmff134 with SMTP id f134so30000898wmf.0 for ; Thu, 29 Oct 2015 11:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay_co_uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=P5xsC5WiZPkuEqzrjU8Gl/DghjQ2hRRtoGeIkyJIxww=; b=FPRDsA2SQfFE55VMr7yOI/s0DGQoAKMm1rvLxpJL04HAzW+BHAg7YHYdoxza+vQ0PJ DLcoqI5grIwrnNK0Al5KcSE2C5KnYTL1zYLlZCr3UzFYCk0y+F5jAGlrEox7MrmuEP5E FVBh3ByY8d62UL94/i6//M3nENWpc3cWTGzB14nw5lWopX6tZSvGGbmzDZV4sjKG0t/3 amYwxJN4sypReNUgZIzGqSlwAZ/UmhdOGJSp2mu+YmxK2oDJtzAQOo6sDuAs8yjmyHvW 8WVBNdJoHx7OA0nohMPK+ogM9ui5lUHYJtM2MRycbkxm4GZ6h/eo6eiR2gAB1b+Usi5Y hl1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=P5xsC5WiZPkuEqzrjU8Gl/DghjQ2hRRtoGeIkyJIxww=; b=Z8d57kC6b3WBhx0GYHefjHVAqWi/jSHqRaX18Y9md0CMq5HNKrdrKhXwW4qe59Rwb0 W4bnFM5EOvKx31Jdg1QN44raAW5aVtiZiDoUdNA6WI1fmLDuAruYvMpvRm+rKpjFHypP YgLe+bqUuJaFLJ/5VxQ6bMLaQ34GLn+gmDQvi5NBxaO0eHbf3L9ffPVh76MuFl+sIn5r ryUhrLe7y93Btvr5NKlsSDPfL8qyfiMbzQG84oMixuAslzRJZv+84GZYVQexhwN+yakl POL6XeL2DE/WnfpI1Guih+LifeB3gxyfqMIK5Z3whey7o9SiE0akxxpsqKfX5on5U5eG t6kA== X-Gm-Message-State: ALoCoQnkWi844/Gkk71T2kemlqDwK1YNemK1LVhuQiSiAjvVNS8s2hHH4aqkafKgUiuk0COqk7tz X-Received: by 10.28.16.132 with SMTP id 126mr8028300wmq.86.1446142950122; Thu, 29 Oct 2015 11:22:30 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id b12sm10399280wma.6.2015.10.29.11.22.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 11:22:29 -0700 (PDT) Subject: Re: ZFS, SSDs, and TRIM performance To: freebsd-stable@freebsd.org References: <449F8F4D-425D-46B5-BB9C-BE5A0CD11C55@smkelly.org> From: Steven Hartland Message-ID: <563263ED.1070402@multiplay.co.uk> Date: Thu, 29 Oct 2015 18:22:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <449F8F4D-425D-46B5-BB9C-BE5A0CD11C55@smkelly.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Oct 2015 18:22:32 -0000 If you running NVMe, are you running a version which has this: https://svnweb.freebsd.org/base?view=revision&revision=285767 I'm pretty sure 10.2 does have that, so you should be good, but best to check. Other questions: 1. What does "gstat -d -p" show during the stalls? 2. Do you have any other zfs tuning in place? On 29/10/2015 16:54, Sean Kelly wrote: > Me again. I have a new issue and I’m not sure if it is hardware or software. I have nine servers running 10.2-RELEASE-p5 with Dell OEM’d Samsung XS1715 NVMe SSDs. They are paired up in a single mirrored zpool on each server. They perform great most of the time. However, I have a problem when ZFS fires off TRIMs. Not during vdev creation, but like if I delete a 20GB snapshot. > > If I destroy a 20GB snapshot or delete large files, ZFS fires off tons of TRIMs to the disks. I can see the kstat.zfs.misc.zio_trim.success and kstat.zfs.misc.zio_trim.bytes sysctls skyrocket. While this is happening, any synchronous writes seem to block. For example, we’re running PostgreSQL which does fsync()s all the time. While these TRIMs happen, Postgres just hangs on writes. This causes reads to block due to lock contention as well. > > If I change sync=disabled on my tank/pgsql dataset while this is happening, it unblocks for the most part. But obviously this is not an ideal way to run PostgreSQL. > > I’m working with my vendor to get some Intel SSDs to test, but any ideas if this could somehow be a software issue? Or does the Samsung XS1715 just suck at TRIM and SYNC? > > We’re thinking of just setting the vfs.zfs.trim.enabled=0 tunable for now since WAL segment turnover actually causes TRIM operations a lot, but unfortunately this is a reboot. But disabling TRIM does seem to fix the issue on other servers I’ve tested with the same hardware config. > From owner-freebsd-stable@freebsd.org Thu Oct 29 21:59:10 2015 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 58752A2107B for ; Thu, 29 Oct 2015 21:59:10 +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 184921110 for ; Thu, 29 Oct 2015 21:59:09 +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 9C13A28435; Thu, 29 Oct 2015 22:59:01 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-49-111.net.upcbroadband.cz [89.177.49.111]) (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 6946D2842E; Thu, 29 Oct 2015 22:59:00 +0100 (CET) Message-ID: <563296A4.70501@quip.cz> Date: Thu, 29 Oct 2015 22:59:00 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Jeremy Chadwick CC: freebsd-stable@freebsd.org Subject: Re: stable/10: high load average when box is idle References: <20151027050508.GA7612@icarus.home.lan> <5631EE40.3020404@quip.cz> <20151029100910.GA52255@icarus.home.lan> <56320737.2060901@quip.cz> In-Reply-To: <56320737.2060901@quip.cz> 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.20 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, 29 Oct 2015 21:59:10 -0000 Miroslav Lachman wrote on 10/29/2015 12:47: > Jeremy Chadwick wrote on 10/29/2015 11:09: [...] >> I've seen it on both bare-metal and VMs. Please see c#8 in the ticket; >> there's an itemised list of where I've seen it, but I'm sure it's not >> limited to just those. > > OK, I have read your c#8 and did some tests on our affected VMs. > With sysctl kern.eventtimer.periodic=1 it is better. Where previously > load were about 0.40 is 0.15 now. > One of these three systems is FreeBSD 10.2 and on this machine the > positive effect of kern.eventtimer.periodic=1 is more visible - load is > now 0.00 - 0.05. > I don't know if this is some coincidence or something is different in 10.2. > > Settings of kern.eventtimer is the same on all VMs > > kern.eventtimer.et.LAPIC.flags: 7 > kern.eventtimer.et.LAPIC.frequency: 35071418 > kern.eventtimer.et.LAPIC.quality: 600 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.et.RTC.flags: 17 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.choice: LAPIC(600) i8254(100) RTC(0) > kern.eventtimer.singlemul: 4 > kern.eventtimer.idletick: 0 > kern.eventtimer.timer: LAPIC > kern.eventtimer.periodic: 1 Just for the record - I added graphs of CPU load from these three VMs FreeBSD 10.1 http://imagebin.ca/v/2Kkyq29M13d3 FreeBSD 10.1 http://imagebin.ca/v/2KkzUccxJEoE FreeBSD 10.2 http://imagebin.ca/v/2Kl00mS4RQ3n And coresponding CPU idle percentages FreeBSD 10.1 http://imagebin.ca/v/2Kl0R0U1pRhg FreeBSD 10.1 http://imagebin.ca/v/2Kl0cYiB0mS4 FreeBSD 10.2 http://imagebin.ca/v/2Kl0lIipTKXc As I mentioned the difference with / without kern.eventtimer.periodic=1 is more visible on FreeBSD 10.2. The flat line on the graphs is interval where I disabled almost all services - crontab too - so no measurements in this time. Effect of kern.eventtimer.periodic=1 is visible from 18:00 when I started all usual services. Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Oct 30 13:37:00 2015 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 93457A21E4F for ; Fri, 30 Oct 2015 13:37:00 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: from oslo.ath.cx (oslo.ath.cx [144.76.166.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 5DC2B1160; Fri, 30 Oct 2015 13:37:00 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: from oslo.ath.cx (localhost [IPv6:::1]) by oslo.ath.cx (Postfix) with SMTP id 910A21557; Fri, 30 Oct 2015 14:36:56 +0100 (CET) Date: Fri, 30 Oct 2015 14:36:56 +0100 From: "Herbert J. Skuhra" To: Lev Serebryakov Cc: freebsd-stable Subject: Re: 10-STABLE buildworld fails at very early stage Message-ID: <20151030133656.GC27206@oslo.ath.cx> References: <56322C32.3050702@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56322C32.3050702@FreeBSD.org> User-Agent: Mutt/1.5.24+24 (41af5a753d6f) (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 13:37:00 -0000 On Thu, Oct 29, 2015 at 05:24:50PM +0300, Lev Serebryakov wrote: > > I have this in /etc/src.conf (it is only one line here): > > MAKEOBJDIRPREFIX=/usr/home/build/obj > > > % cd /usr/src > % sudo svn up > Updating '.': > At revision 290139. > % sudo make buildworld > [one screen of output] > set -e; cd /usr/src/tools/build; make buildincludes; make installinclude > s > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a > /usr/home/build/obj/legacy/usr/lib > install: /usr/home/build/obj/legacy/usr/lib: No such file or directory > *** Error code 71 > > Stop. > make[3]: stopped in /usr/src/tools/build > *** Error code 1 > % uname -v > FreeBSD 10.2-PRERELEASE #7 r286065: Thu Jul 30 21:27:35 MSK 2015 > root@:/usr/obj/usr/src/sys/BLOB Does it work if you do: % setenv MAKEOBJDIRPREFIX /usr/home/build/obj >From man make.conf(5): CAVEATS Note, that MAKEOBJDIRPREFIX and MAKEOBJDIR are environment variables and should not be set in make.conf or as command line arguments to make(1), but in make's environment. -- Herbert From owner-freebsd-stable@freebsd.org Fri Oct 30 13:47:35 2015 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 91DE0A1E0DD for ; Fri, 30 Oct 2015 13:47:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C69715E4 for ; Fri, 30 Oct 2015 13:47:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 703287F9; Fri, 30 Oct 2015 16:47:32 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: 10-STABLE buildworld fails at very early stage References: <56322C32.3050702@FreeBSD.org> <20151030133656.GC27206@oslo.ath.cx> To: "Herbert J. Skuhra" Cc: freebsd-stable From: Lev Serebryakov Organization: FreeBSD Message-ID: <563374F3.4090107@FreeBSD.org> Date: Fri, 30 Oct 2015 16:47:31 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151030133656.GC27206@oslo.ath.cx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 13:47:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 30.10.2015 16:36, Herbert J. Skuhra wrote: >> I have this in /etc/src.conf (it is only one line here): >> >> MAKEOBJDIRPREFIX=/usr/home/build/obj >> >> >> % cd /usr/src % sudo svn up Updating '.': At revision 290139. % >> sudo make buildworld [one screen of output] set -e; cd >> /usr/src/tools/build; make buildincludes; make installinclude s >> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 >> libegacy.a /usr/home/build/obj/legacy/usr/lib install: >> /usr/home/build/obj/legacy/usr/lib: No such file or directory *** >> Error code 71 >> >> Stop. make[3]: stopped in /usr/src/tools/build *** Error code 1 % >> uname -v FreeBSD 10.2-PRERELEASE #7 r286065: Thu Jul 30 21:27:35 >> MSK 2015 root@:/usr/obj/usr/src/sys/BLOB > > Does it work if you do: > > % setenv MAKEOBJDIRPREFIX /usr/home/build/obj Nope, same error: rm -rf /usr/home/build/obj/usr/src/tmp rm -rf /usr/home/build/obj/usr/src/lib32 mkdir -p /usr/home/build/obj/usr/src/tmp/lib mkdir -p /usr/home/build/obj/usr/src/tmp/usr mkdir -p /usr/home/build/obj/usr/src/tmp/legacy/bin mkdir -p /usr/home/build/obj/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/home/build/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr/home/build/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/home/build/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/home/build/obj/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /usr/home/build/obj/usr/src/tmp ... sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/home/build/obj/usr/src/tmp/legacy/usr/lib install: libegacy.a: No such file or directory Looks like some problem with Makefile, as here is creation of /bin and /usr "legacy" directories. - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWM3TyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePn9MP/AmfVBYzcq06HZB+KGDExmSk cjeXEgi5Aq21YDdNnD6tFTVtK330nb+nW+ZnWvziogz6kJL09hxh05wF55jaCtza dUSFPv1Fd6EDvax5hWYUxOiMALcdYr6I13vDAU/fpzWO7CJtl403T4Z18Yumx9FT Uc/vz2clKE3fLZi/dJV9zg59H/ESELu9TDdxZIL1HVZ/EucCjSRwJtvAn9cjEUhA +qR2LgOCJkYAsSFiajw86BDBA0EfSYMl+Kfl0VcbT5tf5mQ8uAUtxL63di1j/dlB fNVsLpcb5XSSraJj4qexnqQt/0jnU0NvIyPKxFo0IkQ3cqFTxR2iAZpP2iXEPHfJ KSVp2uS198EIdr3jCvcuHFP/iAWCAtukmpc90i56Vf/yBBkXZs6v9f0ywL93WrCa gEm2ESajK6XvyqAg8HwbA8NTIrDkMD8BOTnYhS7Ed0vpQa0cGblWA9yw9kRjoDV4 WSQjseRJNjaLzzAmX57dKNWp3x+D8kipd5dGHxxgtmNjlFiR/hnEoIF3kBkufrUk 1xn2jIw/rVScpeHBnnJ7bNJbWc1NMlYyCpfbj8rFOsypxjIIpMR+OofeMKbQ/Izz FEguAVgnHujG9BgYEj2g0qoe872f3NAoDZwyE8S/qk39eWHF1Bkd2P6SvXIXOUQN jn2n4WjTpUTMNDBcZT8s =aM01 -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Fri Oct 30 18:43:06 2015 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 6B227A22F65 for ; Fri, 30 Oct 2015 18:43:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3490D1578 for ; Fri, 30 Oct 2015 18:43:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:a8fb:9ce8:eba7:e5e6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 57891839; Fri, 30 Oct 2015 21:43:03 +0300 (MSK) Date: Fri, 30 Oct 2015 21:42:56 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <3910457450.20151030214250@serebryakov.spb.ru> To: "Herbert J. Skuhra" , freebsd-stable Subject: Re: 10-STABLE buildworld fails at very early stage In-Reply-To: <563374F3.4090107@FreeBSD.org> References: <56322C32.3050702@FreeBSD.org> <20151030133656.GC27206@oslo.ath.cx> <563374F3.4090107@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="----------0D80D30B5323A4092" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 18:43:06 -0000 ------------0D80D30B5323A4092 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Lev, Friday, October 30, 2015, 4:47:31 PM, you wrote: > Looks like some problem with Makefile, as here is creation of /bin > and /usr "legacy" directories. I've found this: http://lists.freebsd.org/pipermail/freebsd-current/2013-August/043439.html and it looks like my case exactly (but on -STABLE!). "svn status" doesn't show that there is something not-checked-out in "/usr/src" and, yes, this is very surprising to have some build-generated files in /usr/src! --=20 Best regards, Lev mailto:lev@serebryakov.spb.ru ------------0D80D30B5323A4092 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJWM7owXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePZmIP/3/AEWSs6l9bOH62PltvnIyR v37sU5Os7wA1clTVHZbH8YlgJ4lIvJHtEhJhijffSxiCdLKhNq+4m5Whrej5n9Ac fosC+VMb9g+4ossI02Ob1V8Q6Lv3RYQed5lMHuRJkbcIUTo/RLsNVHGS/Gik4JC2 rlmOpCeyphfqBOWIXqXQKsgCmYGluW7AWfoVAQHzkzwrKiSe9KM/DxUXOcwSH83h IrURTY24gesLwsWkotCB3Q53DJIYNlY4uCTMaZGFWtKZ5JREzXYzKJcRQjgJOMBF kRXa87gkdos4ItY7guyJzjIRoEiO0/hfuNc8Tnu7A/mSrX7WQDDtX4gNFAxcrQ9R zn86f+OLLvlx4FV2bGKV8kg99fBPHTeJdJ5J8xNA/KVMbk5jMciVZ/mIETeq9g+4 XzUIFVsdum2YeFd3tsspv5x0QFvFsjn3ePoqHVkzcK+DT1KOMqJRzJn8OTG8Jzi9 AcNL6OFc2I3b1gyKVxwIXniOyNrKisGYY2cg5nZvxdRr0qnqT6aqcO2vECgjfmIy yYCvdInwnFmLC2f8eCOES5MMSK7Etf4Crn862CXE8lJUUcusniCsCavUzzV2cfoU nR5gyieY17M7qGopx/jDGqm7IiKXLqlvYGZTuQ+JqF2ARi5Nvs4RQMml6mBXNHgU gl32c2gwQd4QD2BK3Rs6 =p7QE -----END PGP MESSAGE----- ------------0D80D30B5323A4092-- From owner-freebsd-stable@freebsd.org Fri Oct 30 18:48:07 2015 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 C5506A1F02C; Fri, 30 Oct 2015 18:48:07 +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 6E0DD1804; Fri, 30 Oct 2015 18:48:07 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3nnXhM0Gp9z1VQ; Fri, 30 Oct 2015 19:48:03 +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=1446230879; x=1448822880; bh=i3q r+9cu6SOyOhWJJDfqSKQJ1hRSwDNXLO1L85w3vU0=; b=h4PusJ1Xxd3E0Ca4tD/ K0rhYk7xexPTVit0Ef60aR6npOCpMUqMG3Ehr5qGhfuoBkMlNIFDFpf0GY24l2te tufgdXKFgZU5Y+jqHtxL9chkSz+N9v3EC0zV9wSx/rtdnZb03DuvqqRyRecpHhkm AMIvB0w+fxr3GsX0GgBrdIYQ= 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 6qn9fXfNBepo; Fri, 30 Oct 2015 19:47:59 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3nnXhH5Pbkz1VN; Fri, 30 Oct 2015 19:47:59 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3nnXhH4W4Cz175; Fri, 30 Oct 2015 19:47:59 +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); Fri, 30 Oct 2015 19:47:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 30 Oct 2015 19:47:59 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org, current@freebsd.org Subject: Re: Segmentation fault running ntpd Organization: Jozef Stefan Institute In-Reply-To: <20151030113449.GF13438@albert.catwhisker.org> References: <20150718120956.GC1155@albert.catwhisker.org> <86pozwbvds.fsf@desk.des.no> <20151030113449.GF13438@albert.catwhisker.org> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 18:48:07 -0000 Not sure if it's the same issue, but it sure looks like it is. I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5 to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just replaced the /usr/sbin/ntpd with a new one; then I restarted the ntpd. On all host but one this was successful: the new ntpd starts fine and works normally. But on one of these machines the ntpd process immediately crashes with SIGSEGV. That machine has an Intel Xeon cpu. It is not apparent to me in what way this machine differs from others, Played with some variations of ntpd on that host, here are some findings: - the new ntpd (that came with 10.2-RELEASE-p6) runs fine if it does *not* daemonize, i.e. ntpd with an option -n or -d stays attached to a terminal and works fine; the same happens when run under ktrace -d -i ntpd ... it works fine, even when it daemonizes; - the ntpd built from fresh net/ntp-devel behaves exactly the same: crashes on that machine when it daemonizes - a previous ntpd (from 10.2-RELEASE-p5) works fine, so I ended up downgrading ntpd to that previous version on that machine. Also a ntpd from a recent 10-STABLE when copied to that host runs fine there! I haven't tried yet to build it with debugging, or capture a core dump. Puzzling... Mark 2015-10-30 12:34, je David Wolfskill napisal > On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote: >> David Wolfskill writes: >> > ... >> > bound to 172.17.1.245 -- renewal in 43200 seconds. >> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) >> > Starting Network: lo0 em0 iwn0 lagg0. >> > ... >> >> Did you find a solution? I'm wondering if the ntpd problems people >> are >> reporting on freebsd-security@ are related. I vaguely recall hearing >> that this had been traced to a pthread bug, but can't find anything >> about it in commit logs or mailing list archives. >> .... > > I don't recall finding "a solution" per se; that said, I also don't > recall seeing an occurrence of the above for enough time that I'm not > sure when I sent that message. :-} > > As a reality check: > > g1-252(11.0-C)[1] ls -lT /*.core > -rw-r--r-- 1 root wheel 13783040 Aug 18 04:19:03 2015 /ntpd.core > g1-252(11.0-C)[2] > > So -- among other points -- my last sighting of whatever was causing > that was the day I built: > > FreeBSD 11.0-CURRENT #157 r286880M/286880:1100079: Tue Aug 18 > 04:45:25 PDT 2015 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > Note that the machines where I run head get updated daily (unless > there's enough of a problem with head that I can't build it or can't > boot it (and I'm unable to circumvent the issue within a reasonable > time)) -- and while I do attempt to run ntpd on the machines, the above > failure is more "annoying" than "crippling" in my particular case. > > And I'm presently running: > > FreeBSD 11.0-CURRENT #227 r290138M/290138:1100084: Thu Oct 29 > 05:12:58 PDT 2015 > root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > and building head @r290190 as I type. > > And FWIW, I *suspect* that one of the issues involved (in my case) > was a ... lack of determinism ... in events involving getting the > (wireless) network connectivity into a usable state as part of the > initial transition to multi-user mode. (I only have evidence at > the moment of the issue on my laptop; my build machine, which only > uses a wired NIC, has no /ntpd.core file. It and my laptop are updated > pretty much in lock-step; it runs a completely GENERIC kernel, while > the laptop runs a modestly customized one based on GENERIC.) > > Peace, > david From owner-freebsd-stable@freebsd.org Fri Oct 30 19:54:08 2015 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 C5F56A21439 for ; Fri, 30 Oct 2015 19:54:08 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: from oslo.ath.cx (oslo.ath.cx [144.76.166.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 8FDC01CEB; Fri, 30 Oct 2015 19:54:08 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: from oslo.ath.cx (localhost [IPv6:::1]) by oslo.ath.cx (Postfix) with SMTP id 95BA310D8; Fri, 30 Oct 2015 20:54:05 +0100 (CET) Date: Fri, 30 Oct 2015 20:54:05 +0100 From: "Herbert J. Skuhra" To: Lev Serebryakov Cc: freebsd-stable Subject: Re: 10-STABLE buildworld fails at very early stage Message-ID: <20151030195405.GA1097@oslo.ath.cx> References: <56322C32.3050702@FreeBSD.org> <20151030133656.GC27206@oslo.ath.cx> <563374F3.4090107@FreeBSD.org> <3910457450.20151030214250@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3910457450.20151030214250@serebryakov.spb.ru> User-Agent: Mutt/1.5.24+24 (41af5a753d6f) (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 30 Oct 2015 19:54:08 -0000 On Fri, Oct 30, 2015 at 09:42:56PM +0300, Lev Serebryakov wrote: > Hello Lev, > > Friday, October 30, 2015, 4:47:31 PM, you wrote: > > > Looks like some problem with Makefile, as here is creation of /bin > > and /usr "legacy" directories. > I've found this: > http://lists.freebsd.org/pipermail/freebsd-current/2013-August/043439.html > and it looks like my case exactly (but on -STABLE!). > > "svn status" doesn't show that there is something not-checked-out in > "/usr/src" and, yes, this is very surprising to have some build-generated > files in /usr/src! OK, I couldn't reproduce this because I am not building as root. Building as root and setting MAKEOBJDIRPREFIX in src.conf is creating: /usr/src/tools/build/.depend /usr/src/tools/build/libegacy.a /usr/src/tools/build/pwcache.o % svnlite status --no-ignore ? tools/build/.depend I tools/build/libegacy.a I tools/build/pwcache.o There is already a check for MAKEOBJDIRPREFIX in make.conf: make: "/usr/src/Makefile" line 138: MAKEOBJDIRPREFIX can only be set in environment, not as a global (in make.conf(5)) or command-line variable. No idea how to add SRCCONF to the check. -- Herbert