From owner-freebsd-current@freebsd.org Sun Mar 12 00:31:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC203CF9404 for ; Sun, 12 Mar 2017 00:31:54 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A75AE1240 for ; Sun, 12 Mar 2017 00:31:54 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x229.google.com with SMTP id g138so14976841itb.0 for ; Sat, 11 Mar 2017 16:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vhMa18sEnYY0E4fC7UVQyWdo8SmdSMLdmeys3yIgDxY=; b=CXiupsyCa/JDh1NGJN2Qq88Us8brz24Y1TxizbBaKpcWHs+SmogZoSmslwdl7YDIvO NL+9fluaelUzlvpjC/xDMQZRJyzSK5/0iYaVl9NWbHS7wH9PRzK0GU2UF177Qfo//dhC Gc+p0VzX+3clHodLbKDbX3+1RHzFebCy+tTOAYFTfewaAYxK6YQ6Q4/3Ll2hmSpnNU5T MAvXv83tM9xLEAomKoBA62UD3YbeEVsP+eOU36kThAhvi94qJnxVBIVjJ5a3d7sMF1ta sNU702AWdCty6JrjujLlgY95EgXYTc0s+mjt3jy2H84PP2C4JQXlORooCOhUfaFdCZsS 3Umg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vhMa18sEnYY0E4fC7UVQyWdo8SmdSMLdmeys3yIgDxY=; b=ZHlAtMnw3x7CxYCtDRZtWV9mWofSzXiuknaoGJGnTGd33f4ZDP8kH6KytxDn05CcGG 7xrOgNWBQ9cJiX5+qFC4w97GNSDV3u98wZqn9tZ8TNWAVe1X25uJb33FlRjSbYEcRL+M KBrmZj0keuHeG+2f+scgOiesOB3JDYjJLUwG4ZbcVoh/NEeQE93NPdKYorzDoKTQ+Dnv Qg4bwadpo3XsqyyfBA+WrNKseDca/zOJ1IiQSpgEsprs6lkwaE/+7bjcjegBWMdHAP8u C9QjFbbzqpEehcPLnc/Uw4McdlUu9lzHFKnxXrYWguGeVd0CD5OsZfFVVGmIGUlhoMYa FMNA== X-Gm-Message-State: AFeK/H2ijN8+CXQVrkgGcARC8FlqL5zM9hzW1uzCiq2jv28v8tpzY644Q8lu4twv979zdOZMnGjnp+w/ogdvuQ== X-Received: by 10.36.5.67 with SMTP id 64mr5143482itl.97.1489278713581; Sat, 11 Mar 2017 16:31:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sat, 11 Mar 2017 16:31:53 -0800 (PST) From: Roberto Rodriguez Jr Date: Sun, 12 Mar 2017 00:31:53 +0000 Message-ID: Subject: SMBus driver To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 00:31:55 -0000 Hi, pciconf -lvbe none0@pci0:0:20:0: class=0x0c0500 card=0x21f7103c chip=0x780b1022 rev=0x3a hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'FCH SMBus Controller' class = serial bus subclass = SMBus I have 'device smbus' in KERNCONF. I would love to know how to correct this. I looked in sys/dev/smbus but have no idea which file to edit or where to begin understanding why its none0. Thank you dmesg Copyright (c) 1992-2017 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 12.0-CURRENT #0 r315090: Sat Mar 11 23:59:22 UTC 2017 root@krsna:/usr/obj/usr/src/sys/KRSNA amd64 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) VT(efifb): resolution 1366x768 CPU: AMD A6-5200 APU with Radeon(TM) HD Graphics (1996.29-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x700f01 Family=0x16 Model=0x0 Stepping=1 Features=0x178bfbff Features2=0x3ed8220b AMD Features=0x2e500800 AMD Features2=0x154037ff Structured Extended Features=0x8 XSAVE Features=0x1 SVM: NP,NRIP,AFlush,DAssist,NAsids=8 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3540578304 (3376 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC" frequency 1996292475 Hz quality 1000 random: entropy device external interface netmap: loaded module kbd1 at kbdmux0 nexus0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xefffffff,0xf0000000-0xf07fffff,0xf0c00000-0xf0c3ffff irq 44 at device 1.0 on pci0 vgapci0: Boot video device hdac0: mem 0xf0c40000-0xf0c43fff irq 45 at device 1.1 on pci0 pcib1: irq 48 at device 2.1 on pci0 pci1: on pcib1 pcib2: irq 50 at device 2.3 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 51 at device 2.4 on pci0 pci3: on pcib3 ath0: mem 0xf0a00000-0xf0a7ffff irq 36 at device 0.0 on pci3 ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 2457.9 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 pcib4: irq 48 at device 2.5 on pci0 pci4: on pcib4 re0: port 0x2000-0x20ff mem 0xf0900000-0xf0900fff,0xf0800000-0xf0803fff irq 40 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x44800000 re0: MAC rev. 0x00100000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: d0:bf:9c:63:a9:99 re0: netmap queues/slots: TX 1/256, RX 1/256 xhci0: mem 0xf0c48000-0xf0c49fff irq 18 at device 16.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Unable to map MSI-X table usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 ahci0: port 0x3118-0x311f,0x3124-0x3127,0x3110-0x3117,0x3120-0x3123,0x3100-0x310f mem 0xf0c4f000-0xf0c4f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ohci0: mem 0xf0c4e000-0xf0c4efff irq 18 at device 18.0 on pci0 usbus1 on ohci0 usbus1: 12Mbps Full Speed USB v1.0 ehci0: mem 0xf0c4d000-0xf0c4d0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 ohci1: mem 0xf0c4c000-0xf0c4cfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 usbus3: 12Mbps Full Speed USB v1.0 ehci1: mem 0xf0c4b000-0xf0c4b0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 usbus4: 480Mbps High Speed USB v2.0 hdac1: mem 0xf0c44000-0xf0c47fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 sdhci_pci0: mem 0xf0c4a000-0xf0c4a0ff irq 16 at device 20.7 on pci0 sdhci_pci0: 1 slot(s) allocated acpi_lid0: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (226.9C) acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ACPI Error: No handler for Region [RCM0] (0xfffff80002987600) [SystemCMOS] (20170303/evregion-288) ACPI Error: Region SystemCMOS (ID=5) has no handler (20170303/exfldio-428) ACPI Error: Method parse/execution failed [\134_SB.WMID.ESDT] (Node 0xfffff80002991ac0), AE_NOT_EXIST (20170303/psparse-668) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPC0.EC0._Q42] (Node 0xfffff8000299f240), AE_NOT_EXIST (20170303/psparse-668) acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 hwpstate0: on cpu0 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 25 on hdaa1 pcm2: at nid 33 and 18 on hdaa1 ugen1.1: at usbus1 ugen4.1: at usbus4 ugen0.1: <0x1022 XHCI root HUB> at usbus0 ugen2.1: at usbus2 uhub0: on usbus1 uhub1: on usbus2 ugen3.1: at usbus3 uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub3: on usbus4 uhub4: on usbus3 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number 4B6451901019 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: ATA8-ACS SATA 3.x device ada0: Serial Number TM8513TC2A1LKL ada0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) Trying to mount root from ufs:/dev/ada0p2 [rw,noatime]... uhub0: 4 ports with 4 removable, self powered uhub4: 4 ports with 4 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered uhub3: 4 ports with 4 removable, self powered ugen4.2: at usbus4 wlan0: Ethernet address: ac:b5:7d:a2:36:f5 wlan0: link state changed to UP re0: link state changed to DOWN From owner-freebsd-current@freebsd.org Sun Mar 12 00:38:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E9CCF95E0 for ; Sun, 12 Mar 2017 00:38:25 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E93E1627 for ; Sun, 12 Mar 2017 00:38:24 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id mrWackzWL47SdmrWbcH7eQ; Sat, 11 Mar 2017 17:38:18 -0700 X-Authority-Analysis: v=2.2 cv=P9pKvmIu c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=HXM2IViLote7lug4L9AA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id F34BD1C1; Sat, 11 Mar 2017 16:38:15 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2C0cF2V088898; Sat, 11 Mar 2017 16:38:15 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703120038.v2C0cF2V088898@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Roberto Rodriguez Jr cc: FreeBSD Current Subject: Re: buildworld error In-Reply-To: Message from Roberto Rodriguez Jr of "Sat, 11 Mar 2017 23:51:34 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Mar 2017 16:38:15 -0800 X-CMAE-Envelope: MS4wfEG1+BAF7ZXTvv+oZCLycmAnub+dfAi+0PYz/+rKWel0wZiq2JemiDczpZJAr7yeR6VaIN59jEZSeaKTZ0ZyrFezI39fdQiV4cKTsILFCM3C72P8Nxa8 LeuNFt48cl60s06xbjA9DSNHkNuZuJvp+JeTacWEe0TO5tYEzJnR9uFTY+91JunuITJLPlDk/n11j0G8jW07mphi6Xsb859nGMxpfREXfC01Ciur0dFpLGzG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 00:38:25 -0000 In message , Roberto Rodriguez Jr writes: > I figured the script command... here is the new error r315090 > > --- .depend --- > echo setkey.full: /usr/obj/usr/src/tmp/usr/lib/libc.a > /usr/obj/usr/src/tmp/usr/lib/libl.a > /usr/obj/usr/src/tmp/usr/lib/liby.a > /usr/obj/usr/src/tmp/usr/lib/libipsec.a >> .depend > --- setkey.o --- > /usr/local/libexec/ccache/cc -O2 -pipe -march=btver2 > -I/usr/src/sbin/setkey -I/usr/src/lib/libipsec -I/usr/src/lib/libipsec > -I/usr/src/sys/netipsec -DIPSEC_DEBUG -DYY_NO_UNPUT -DINET6 -I. -g -MD > -MF.depend.setkey.o -MTsetkey.o -std=gnu99 -fstack-protector-strong > -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > -Wno-parentheses -Qunused-arguments -c /usr/src/sbin/setkey/setkey.c > -o setkey.o > --- all_subdir_lib --- > --- jemalloc_nstime.po --- > /usr/local/libexec/ccache/cc -pg -O2 -pipe -march=btver2 > -I/usr/src/lib/libc/include -I/usr/src/include > -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 > -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/src/lib/libmd > -I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP > -DNS_CACHING -DSYMBOL_VERSIONING -MD -MF.depend.jemalloc_nstime.po > -MTjemalloc_nstime.po -std=gnu99 -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Qunused-arguments > -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 > -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_nstime.c > -o jemalloc_nstime.po > --- all_subdir_rescue --- > --- suffix.o --- > /usr/local/libexec/ccache/cc -O2 -pipe -DHAVE_CONFIG_H > -I/usr/src/usr.bin/xz/../../lib/liblzma > -I/usr/src/usr.bin/xz/../../contrib/xz/src/common -march=btver2 > -DRESCUE -MD -MF.depend.suffix.o -MTsuffix.o -std=gnu99 > -fstack-protector-strong -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Qunused-arguments -c > /usr/src/usr.bin/xz/../../contrib/xz/src/xz/suffix.c -o suffix.o > --- all_subdir_sbin --- > /usr/src/sbin/setkey/setkey.c:154:15: error: use of undeclared > identifier 'IPSEC_POLICYSCOPE_GLOBAL' > f_scope |= IPSEC_POLICYSCOPE_GLOBAL; > ^ > /usr/src/sbin/setkey/setkey.c:157:15: error: use of undeclared > identifier 'IPSEC_POLICYSCOPE_IFNET' > f_scope |= IPSEC_POLICYSCOPE_IFNET; > ^ > 2 errors generated. > *** [setkey.o] Error code 1 > > make[4]: stopped in /usr/src/sbin/setkey > 1 error > > make[4]: stopped in /usr/src/sbin/setkey > *** [all_subdir_sbin/setkey] Error code 2 > > make[3]: stopped in /usr/src/sbin > 1 error > > make[3]: stopped in /usr/src/sbin > *** [all_subdir_sbin] Error code 2 > > make[2]: stopped in /usr/src > --- all_subdir_rescue --- > A failure has been detected in another branch of the parallel make > > make[6]: stopped in /usr/src/usr.bin/xz > *** [xz_make] Error code 2 > > make[5]: stopped in /usr/obj/usr/src/rescue/rescue > 1 error > > make[5]: stopped in /usr/obj/usr/src/rescue/rescue > *** [objs] Error code 2 > > make[4]: stopped in /usr/src/rescue/rescue > 1 error > > make[4]: stopped in /usr/src/rescue/rescue > *** [all_subdir_rescue/rescue] Error code 2 > > make[3]: stopped in /usr/src/rescue > 1 error > > make[3]: stopped in /usr/src/rescue > *** [all_subdir_rescue] Error code 2 > > make[2]: stopped in /usr/src > --- all_subdir_lib --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /usr/src/lib/libc > *** [all_subdir_lib/libc] Error code 2 > > make[3]: stopped in /usr/src/lib > 1 error > > make[3]: stopped in /usr/src/lib > *** [all_subdir_lib] Error code 2 > > make[2]: stopped in /usr/src > --- all_subdir_secure --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in /usr/src/secure/lib/libcrypto > *** [all_subdir_secure/lib/libcrypto] Error code 2 > > make[4]: stopped in /usr/src/secure/lib > 1 error > > make[4]: stopped in /usr/src/secure/lib > *** [all_subdir_secure/lib] Error code 2 > > make[3]: stopped in /usr/src/secure > 1 error > > make[3]: stopped in /usr/src/secure > *** [all_subdir_secure] Error code 2 > > make[2]: stopped in /usr/src > 4 errors > > make[2]: stopped in /usr/src > *** [everything] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > 1551.754u 434.064s 17:54.86 184.7% 12598+328k 113045+55926io 25455pf+14w That's from a r314812 five days ago. I rebuilt world in one of my development trees since then with no problem. Consider running make delete-old. There might be an old header in /usr/include that's getting in the way. Having said that, world should be self contained so, the assumed scenario above shouldn't happen (except in ports), meaning if make delete-old fixes the problem there may be a buglet in a makefile somewhere. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun Mar 12 00:51:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E9F4CF992E for ; Sun, 12 Mar 2017 00:51:31 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B4C01C9C for ; Sun, 12 Mar 2017 00:51:31 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id m27so15022249iti.1 for ; Sat, 11 Mar 2017 16:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X8FF3Yy/dx8Vtqr90uiG/FwyeT7ZCG+ZDc80LsIcGf4=; b=ToLBUxC/0mB46O7NGWUW4NDZwRxNHFp5PfsYGGsPwekhIpyac7L7x4GeoYEuz4jSNs YUmZ1ApvlI7vFwmJu3rxv1ly7ZlrLSS+0elM3AP3TkUs0H6CVPRuVe/TXdCRP9pU5Alh 6mTrqYh3FYYh5AJ7yeWaIpISa93cAKf9xJFDfWjLfgkPWrU4i2rPv3YfoS34WfDtOseK k96tCnqpNUEZJ4bekGj15k7MZWuBscmOY0boImGkBZQFsk2kqfPICNxwbbcjNEAPM/OP J02dmAK0aaV2aB7aXz6wCAwbz5qt0LPILBBE9og8vBghqAVaN4C9kmqdmQgoagPi7K1I gSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X8FF3Yy/dx8Vtqr90uiG/FwyeT7ZCG+ZDc80LsIcGf4=; b=l8vVptVaMhfBFcHlylHL6lRgydcFdT1gufvng/JSRAtpQp6ez3DgpGmWdB1isODFtc j89OmfuLg1+g2ZL9tiZiHfwubEQClbryudOIDYOgn49X0SiaFU2J8R9dtnEUOhiN5opD Xx+iYdLYAS0G7qrdtV4eGEXKdOabwFKk+6tAagpW+xDS9i0rET3xVcKoB/s85XK1Sn5I yI/dS7kRBxqYySexmYNJb53Wf9pvyyWeES2Ho8xz2zJXbCwbJe9QZBzcqW0vbGD/iMoZ tl3akqpyU52+QLHddp4Z1kACD9M6VZo0uUNigYZLfMuj78hsglQ3V90tpw4e2VMqsIVe FJSQ== X-Gm-Message-State: AFeK/H0TUuyhKcKDz1iGkcirh+cZ6EBu4wqNuIL43+pkW6COAI4BJikzPdXFDal/ZMFZIwhJMGzyzZD9WA8N7A== X-Received: by 10.36.5.67 with SMTP id 64mr5179022itl.97.1489279889914; Sat, 11 Mar 2017 16:51:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sat, 11 Mar 2017 16:51:29 -0800 (PST) In-Reply-To: <201703120038.v2C0cF2V088898@slippy.cwsent.com> References: <201703120038.v2C0cF2V088898@slippy.cwsent.com> From: Roberto Rodriguez Jr Date: Sun, 12 Mar 2017 00:51:29 +0000 Message-ID: Subject: Re: buildworld error To: Cy Schubert Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 00:51:31 -0000 So... cd /usr/src svn up yes|make delete-old rm -rf /usr/obj/* rm -rf /var/tmp/ccache/* make -j4 buildworld Script started on Sun Mar 12 00:47:52 2017 root@krsna:/usr/src # time make -j4 buildworld --- buildworld --- --- buildworld_prologue --- -------------------------------------------------------------- >>> World build started on Sun Mar 12 00:47:54 UTC 2017 -------------------------------------------------------------- --- _worldtmp --- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 mkdir -p /usr/obj/usr/src/tmp/lib mkdir -p /usr/obj/usr/src/tmp/lib/casper mkdir -p /usr/obj/usr/src/tmp/usr mkdir -p /usr/obj/usr/src/tmp/legacy/bin mkdir -p /usr/obj/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/legacy/usr/include >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/tmp mtree -deU -f /usr/src/etc/mtree/BSD.debug.dist -p /usr/obj/usr/src/tmp/legacy/usr/lib >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.debug.dist -p /usr/obj/usr/src/tmp/usr/lib >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/legacy/usr/lib/debug/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/usr/lib/debug/usr >/dev/null mkdir -p /usr/obj/usr/src/tmp/usr/tests mtree -deU -f /usr/src/etc/mtree/BSD.tests.dist -p /usr/obj/usr/src/tmp/usr/tests >/dev/null mkdir -p /usr/obj/usr/src/tmp/usr/lib/debug//usr/tests mtree -deU -f /usr/src/etc/mtree/BSD.tests.dist -p /usr/obj/usr/src/tmp/usr/lib/debug//usr/tests >/dev/null --- _legacy --- -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/usr/src/tmp PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -j 4 -J 15,16 -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1200022 SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no MK_INCLUDES=yes legacy --- legacy --- ===> tools/build (obj,includes,all,install) --- obj --- /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build --- dummy.o --- /usr/local/libexec/ccache/cc -O2 -pipe -MD -MF.depend.dummy.o -MTdummy.o -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/tools/build/dummy.c -o dummy.o --- libegacy.a --- building static egacy library ar -crD libegacy.a `NM='nm' NMFLAGS='' lorder dummy.o | tsort -q` ranlib -D libegacy.a --- _libinstall --- sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib/ --- _bootstrap-tools --- -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/usr/src/tmp PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -j 4 -J 15,16 -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1200022 SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no MK_INCLUDES=yes bootstrap-tools --- _bootstrap-tools-lib/clang/libllvmminimal --- --- _bootstrap-tools-kerberos5/tools/make-roken --- --- _bootstrap-tools-usr.bin/fortune/strfile --- --- _bootstrap-tools-gnu/usr.bin/groff --- --- _bootstrap-tools-lib/clang/libllvmminimal --- ===> lib/clang/libllvmminimal (obj,all,install) --- _bootstrap-tools-kerberos5/tools/make-roken --- ===> kerberos5/tools/make-roken (obj,all,install) --- _bootstrap-tools-usr.bin/fortune/strfile --- ===> usr.bin/fortune/strfile (obj,all,install) --- _bootstrap-tools-gnu/usr.bin/groff --- ===> gnu/usr.bin/groff (obj,all,install) --- obj_subdir_gnu/usr.bin/groff/contrib --- ===> gnu/usr.bin/groff/contrib (obj) --- obj_subdir_gnu/usr.bin/groff/contrib/mm --- ===> gnu/usr.bin/groff/contrib/mm (obj) --- _bootstrap-tools-usr.bin/fortune/strfile --- --- obj --- --- _bootstrap-tools-kerberos5/tools/make-roken --- --- obj --- /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/make-roken created for /usr/src/kerberos5/tools/make-roken --- _bootstrap-tools-usr.bin/fortune/strfile --- /usr/obj/usr/src/tmp/usr/src/usr.bin/fortune/strfile created for /usr/src/usr.bin/fortune/strfile --- _bootstrap-tools-lib/clang/libllvmminimal --- --- obj --- /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/Support created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/TableGen created for /usr/src/lib/clang/libllvmminimal --- _bootstrap-tools-usr.bin/fortune/strfile --- --- .depend --- --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- --- _bootstrap-tools-kerberos5/tools/make-roken --- --- make-roken.c --- --- _bootstrap-tools-usr.bin/fortune/strfile --- echo strfile.full: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend --- _bootstrap-tools-kerberos5/tools/make-roken --- awk -f /usr/src/crypto/heimdal/lib/roken/roken.awk /usr/src/crypto/heimdal/lib/roken/roken.h.in > make-roken.c --- _bootstrap-tools-usr.bin/fortune/strfile --- --- strfile.o --- --- _bootstrap-tools-gnu/usr.bin/groff --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/contrib/mm created for /usr/src/gnu/usr.bin/groff/contrib/mm --- _bootstrap-tools-usr.bin/fortune/strfile --- /usr/local/libexec/ccache/cc -O2 -pipe -g -MD -MF.depend.strfile.o -MTstrfile.o -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/usr.bin/fortune/strfile/strfile.c -o strfile.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font --- ===> gnu/usr.bin/groff/font (obj) --- _bootstrap-tools-usr.bin/fortune/strfile --- --- strfile.full --- /usr/local/libexec/ccache/cc -O2 -pipe -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o strfile.full strfile.o -legacy --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font/devX100 --- ===> gnu/usr.bin/groff/font/devX100 (obj) --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/APInt.o --- /usr/local/libexec/ccache/c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o --- _bootstrap-tools-kerberos5/tools/make-roken --- --- .depend --- echo make-roken.full: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend --- make-roken.o --- /usr/local/libexec/ccache/cc -O2 -pipe -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -g -MD -MF.depend.make-roken.o -MTmake-roken.o -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c make-roken.c -o make-roken.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- --- _bootstrap-tools-kerberos5/tools/make-roken --- --- make-roken.full --- --- _bootstrap-tools-usr.bin/fortune/strfile --- --- strfile.debug --- --- _bootstrap-tools-kerberos5/tools/make-roken --- /usr/local/libexec/ccache/cc -O2 -pipe -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o make-roken.full make-roken.o -legacy --- _bootstrap-tools-gnu/usr.bin/groff --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devX100 created for /usr/src/gnu/usr.bin/groff/font/devX100 --- _bootstrap-tools-usr.bin/fortune/strfile --- objcopy --only-keep-debug strfile.full strfile.debug --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font/devX100-12 --- ===> gnu/usr.bin/groff/font/devX100-12 (obj) --- _bootstrap-tools-usr.bin/fortune/strfile --- --- strfile --- objcopy --strip-debug --add-gnu-debuglink=strfile.debug strfile.full strfile --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devX100-12 created for /usr/src/gnu/usr.bin/groff/font/devX100-12 --- _bootstrap-tools-usr.bin/fortune/strfile --- --- _proginstall --- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/usr/src/tmp/legacy/usr/bin/strfile --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font/devX75 --- ===> gnu/usr.bin/groff/font/devX75 (obj) --- _bootstrap-tools-usr.bin/fortune/strfile --- sh /usr/src/tools/install.sh -o root -g wheel -m 444 strfile.debug /usr/obj/usr/src/tmp/legacy/usr/lib/debug/usr/bin/strfile.debug --- _bootstrap-tools-kerberos5/tools/make-roken --- --- make-roken.debug --- --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/Atomic.o --- --- _bootstrap-tools-kerberos5/tools/make-roken --- objcopy --only-keep-debug make-roken.full make-roken.debug --- _bootstrap-tools-lib/clang/libllvmminimal --- /usr/local/libexec/ccache/c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_Atomic.o -MTSupport/Atomic.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/Atomic.cpp -o Support/Atomic.o --- _bootstrap-tools-kerberos5/tools/make-roken --- --- make-roken --- objcopy --strip-debug --add-gnu-debuglink=make-roken.debug make-roken.full make-roken --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font/devX75-12 --- ===> gnu/usr.bin/groff/font/devX75-12 (obj) --- obj_subdir_gnu/usr.bin/groff/font/devX75 --- --- obj --- --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/CommandLine.o --- /usr/local/libexec/ccache/c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_CommandLine.o -MTSupport/CommandLine.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/CommandLine.cpp -o Support/CommandLine.o --- _bootstrap-tools-gnu/usr.bin/groff --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devX75 created for /usr/src/gnu/usr.bin/groff/font/devX75 --- _bootstrap-tools-kerberos5/tools/make-roken --- --- _proginstall --- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make-roken /usr/obj/usr/src/tmp/legacy/usr/bin/make-roken sh /usr/src/tools/install.sh -o root -g wheel -m 444 make-roken.debug /usr/obj/usr/src/tmp/legacy/usr/lib/debug/usr/bin/make-roken.debug --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/font/devX75-12 --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devX75-12 created for /usr/src/gnu/usr.bin/groff/font/devX75-12 --- obj_subdir_gnu/usr.bin/groff/font/devascii --- ===> gnu/usr.bin/groff/font/devascii (obj) --- obj_subdir_gnu/usr.bin/groff/font/devcp1047 --- ===> gnu/usr.bin/groff/font/devcp1047 (obj) --- obj --- --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/ConvertUTF.o --- /usr/local/libexec/ccache/c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_ConvertUTF.o -MTSupport/ConvertUTF.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/ConvertUTF.cpp -o Support/ConvertUTF.o --- _bootstrap-tools-gnu/usr.bin/groff --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devcp1047 created for /usr/src/gnu/usr.bin/groff/font/devcp1047 --- obj_subdir_gnu/usr.bin/groff/font/devascii --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devascii created for /usr/src/gnu/usr.bin/groff/font/devascii --- obj_subdir_gnu/usr.bin/groff/font/devdvi --- ===> gnu/usr.bin/groff/font/devdvi (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devdvi created for /usr/src/gnu/usr.bin/groff/font/devdvi --- obj_subdir_gnu/usr.bin/groff/font/devhtml --- ===> gnu/usr.bin/groff/font/devhtml (obj) --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/APInt.o --- In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: In file included from /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: In file included from /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: In file included from /usr/include/c++/v1/algorithm:634: In file included from /usr/include/c++/v1/memory:604: /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' file not found #include <__undef___deallocate> ^ --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devhtml created for /usr/src/gnu/usr.bin/groff/font/devhtml --- obj_subdir_gnu/usr.bin/groff/font/devkoi8-r --- ===> gnu/usr.bin/groff/font/devkoi8-r (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devkoi8-r created for /usr/src/gnu/usr.bin/groff/font/devkoi8-r --- obj_subdir_gnu/usr.bin/groff/font/devlatin1 --- ===> gnu/usr.bin/groff/font/devlatin1 (obj) --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/ConvertUTF.o --- In file included from /usr/src/contrib/llvm/lib/Support/ConvertUTF.cpp:50: In file included from /usr/src/contrib/llvm/include/llvm/Support/ConvertUTF.h:93: In file included from /usr/include/c++/v1/string:442: In file included from /usr/include/c++/v1/algorithm:634: In file included from /usr/include/c++/v1/memory:604: /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' file not found #include <__undef___deallocate> ^ --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devlatin1 created for /usr/src/gnu/usr.bin/groff/font/devlatin1 --- obj_subdir_gnu/usr.bin/groff/font/devlbp --- ===> gnu/usr.bin/groff/font/devlbp (obj) --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/CommandLine.o --- In file included from /usr/src/contrib/llvm/lib/Support/CommandLine.cpp:19: In file included from /usr/src/contrib/llvm/include/llvm/Support/CommandLine.h:23: In file included from /usr/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13: In file included from /usr/src/contrib/llvm/include/llvm/ADT/Hashing.h:49: In file included from /usr/src/contrib/llvm/include/llvm/Support/Host.h:17: In file included from /usr/src/contrib/llvm/include/llvm/ADT/StringMap.h:17: In file included from /usr/src/contrib/llvm/include/llvm/ADT/StringRef.h:13: In file included from /usr/src/contrib/llvm/include/llvm/ADT/STLExtras.h:20: In file included from /usr/include/c++/v1/algorithm:634: In file included from /usr/include/c++/v1/memory:604: /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' file not found #include <__undef___deallocate> ^ --- _bootstrap-tools-gnu/usr.bin/groff --- --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devlbp created for /usr/src/gnu/usr.bin/groff/font/devlbp --- obj_subdir_gnu/usr.bin/groff/font/devlj4 --- ===> gnu/usr.bin/groff/font/devlj4 (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devlj4 created for /usr/src/gnu/usr.bin/groff/font/devlj4 --- obj_subdir_gnu/usr.bin/groff/font/devps --- ===> gnu/usr.bin/groff/font/devps (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devps created for /usr/src/gnu/usr.bin/groff/font/devps --- obj_subdir_gnu/usr.bin/groff/font/devutf8 --- ===> gnu/usr.bin/groff/font/devutf8 (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/font/devutf8 created for /usr/src/gnu/usr.bin/groff/font/devutf8 --- obj_subdir_gnu/usr.bin/groff/man --- ===> gnu/usr.bin/groff/man (obj) --- obj --- /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/groff/man created for /usr/src/gnu/usr.bin/groff/man --- obj_subdir_gnu/usr.bin/groff/src --- ===> gnu/usr.bin/groff/src (obj) --- obj_subdir_gnu/usr.bin/groff/src/libs --- ===> gnu/usr.bin/groff/src/libs (obj) --- obj_subdir_gnu/usr.bin/groff/src/libs/libgroff --- ===> gnu/usr.bin/groff/src/libs/libgroff (obj) --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/ConvertUTF.o --- 1 error generated. *** [Support/ConvertUTF.o] Error code 1 make[3]: stopped in /usr/src/lib/clang/libllvmminimal --- _bootstrap-tools-gnu/usr.bin/groff --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/gnu/usr.bin/groff/src/libs/libgroff *** [obj_subdir_gnu/usr.bin/groff/src/libs/libgroff] Error code 2 make[5]: stopped in /usr/src/gnu/usr.bin/groff/src/libs 1 error make[5]: stopped in /usr/src/gnu/usr.bin/groff/src/libs *** [obj_subdir_gnu/usr.bin/groff/src/libs] Error code 2 make[4]: stopped in /usr/src/gnu/usr.bin/groff/src 1 error make[4]: stopped in /usr/src/gnu/usr.bin/groff/src *** [obj_subdir_gnu/usr.bin/groff/src] Error code 2 make[3]: stopped in /usr/src/gnu/usr.bin/groff 1 error make[3]: stopped in /usr/src/gnu/usr.bin/groff *** [_bootstrap-tools-gnu/usr.bin/groff] Error code 2 make[2]: stopped in /usr/src --- _bootstrap-tools-lib/clang/libllvmminimal --- --- Support/APInt.o --- 1 error generated. *** [Support/APInt.o] Error code 1 make[3]: stopped in /usr/src/lib/clang/libllvmminimal --- Support/CommandLine.o --- 1 error generated. *** [Support/CommandLine.o] Error code 1 make[3]: stopped in /usr/src/lib/clang/libllvmminimal 3 errors make[3]: stopped in /usr/src/lib/clang/libllvmminimal *** [_bootstrap-tools-lib/clang/libllvmminimal] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_bootstrap-tools] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src 7.322u 1.210s 0:03.63 234.9% 38797+494k 0+91io 0pf+0w From owner-freebsd-current@freebsd.org Sun Mar 12 00:55:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7266CF9C8F for ; Sun, 12 Mar 2017 00:55:21 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEDB611EE for ; Sun, 12 Mar 2017 00:55:21 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id w124so3147406itb.0 for ; Sat, 11 Mar 2017 16:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5TnZhVdElDN2ivHt3/K0iIzca66DSvRfW68ssPkjd4=; b=g+N0f/2sM5srivz7/ONiRtN7Gc2+SY4gseBL/fa2qjzDolQAokGayyzgkxwypzRWG+ 06yvyXcOSuQ1WxxKhMPZTfBbfP6vkTxRe0U+w5wync5YD5ppX+AE9hWKqSz5DlREnwvi XIxJ5/npJnbqVXJIYszeDmcE0s4+tD3KFGInvBo82wtcLNY87RSvlc8swe+Q7RChnxGw GEtGj30gmaqk9KlV78a+ahCNQL3tnm1Ak1wYYlMi2I2fwtC1Ja06BbaY4JT0KdWV+RhK BqBGUAbpTHXVBoO3tar1ha9HZT5SjrOCFCFnKceJjziaJpTNyqvBfC/vcdB07m+AxEdz zZKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5TnZhVdElDN2ivHt3/K0iIzca66DSvRfW68ssPkjd4=; b=RPjjgnHayn6hFFj6pBIyNMcqCfyBVcxen+b+3E0Awetyp+xgmHxyFoaYwZavHVCMLj YPWA0nCA8I2JyT0HyjCYeryT3AfP0+VlTG7b2WE1aGD+lPbWoGjHzKVHVjjmwMT8OMby tlcj5tgvfocCnVL0F/aNLlXGlzzNSGd3cGEWb2msT/xKEO+ZBRLca3DAWFKv36+gJ4JA ZoOjUBcmjIrxek5mjpLxO6z1JU4HfEBnSvh4vRWM72cQw5u4lyqviUmxYVPtbZaEmX88 11UHMcOfLLWMXOuiTC0KjtwaGU3JOAeDa8ZSgtw08FDB4RTQatVpxOxdFqjACE9nQRcc TPmQ== X-Gm-Message-State: AFeK/H0lbu8TGNfsH0zlnxL/LIeVObp2m3zfWaf35f+4aZJb1OW3NEp2q51+ylNB4LHC9WejXpEoolhy+HG6xA== X-Received: by 10.36.153.134 with SMTP id a128mr5248151ite.90.1489280120947; Sat, 11 Mar 2017 16:55:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sat, 11 Mar 2017 16:55:20 -0800 (PST) In-Reply-To: References: <201703120038.v2C0cF2V088898@slippy.cwsent.com> From: Roberto Rodriguez Jr Date: Sun, 12 Mar 2017 00:55:20 +0000 Message-ID: Subject: Re: buildworld error To: Cy Schubert Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 00:55:22 -0000 Now... make buildworld root@krsna:/usr/src # time make buildworld -------------------------------------------------------------- >>> World build started on Sun Mar 12 00:52:52 UTC 2017 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 mkdir -p /usr/obj/usr/src/tmp/lib mkdir -p /usr/obj/usr/src/tmp/lib/casper mkdir -p /usr/obj/usr/src/tmp/usr mkdir -p /usr/obj/usr/src/tmp/legacy/bin mkdir -p /usr/obj/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/legacy/usr/include >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/tmp mtree -deU -f /usr/src/etc/mtree/BSD.debug.dist -p /usr/obj/usr/src/tmp/legacy/usr/lib >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.debug.dist -p /usr/obj/usr/src/tmp/usr/lib >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/legacy/usr/lib/debug/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.lib32.dist -p /usr/obj/usr/src/tmp/usr/lib/debug/usr >/dev/null mkdir -p /usr/obj/usr/src/tmp/usr/tests mtree -deU -f /usr/src/etc/mtree/BSD.tests.dist -p /usr/obj/usr/src/tmp/usr/tests >/dev/null mkdir -p /usr/obj/usr/src/tmp/usr/lib/debug//usr/tests mtree -deU -f /usr/src/etc/mtree/BSD.tests.dist -p /usr/obj/usr/src/tmp/usr/lib/debug//usr/tests >/dev/null -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/usr/src/tmp PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1200022 SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no MK_INCLUDES=yes legacy ===> tools/build (obj,includes,all,install) /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build /usr/local/libexec/ccache/cc -O2 -pipe -MD -MF.depend.dummy.o -MTdummy.o -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/tools/build/dummy.c -o dummy.o building static egacy library ar -crD libegacy.a `NM='nm' NMFLAGS='' lorder dummy.o | tsort -q` ranlib -D libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib/ -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/usr/src/tmp PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1200022 SSP_CFLAGS= MK_HTML=no NO_LINT=yes MK_MAN=no -DNO_PIC MK_PROFILE=no -DNO_SHARED -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no MK_INCLUDES=yes bootstrap-tools ===> lib/clang/libllvmminimal (obj,all,install) /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/Support created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/TableGen created for /usr/src/lib/clang/libllvmminimal /usr/local/libexec/ccache/c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: In file included from /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: In file included from /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: In file included from /usr/include/c++/v1/algorithm:634: In file included from /usr/include/c++/v1/memory:604: /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' file not found #include <__undef___deallocate> ^ 1 error generated. *** Error code 1 Stop. make[3]: stopped in /usr/src/lib/clang/libllvmminimal *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-current@freebsd.org Sun Mar 12 01:04:27 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7657CF9F58 for ; Sun, 12 Mar 2017 01:04:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C50E1707 for ; Sun, 12 Mar 2017 01:04:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::b41e:b28e:9796:f896] (unknown [IPv6:2001:7b8:3a7:0:b41e:b28e:9796:f896]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F2C432E9EB; Sun, 12 Mar 2017 02:04:22 +0100 (CET) From: Dimitry Andric Message-Id: <5CB065B0-5A7D-4A50-A722-8EA579A67188@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: buildworld error Date: Sun, 12 Mar 2017 02:04:14 +0100 In-Reply-To: Cc: Cy Schubert , FreeBSD Current To: Roberto Rodriguez Jr References: <201703120038.v2C0cF2V088898@slippy.cwsent.com> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 01:04:27 -0000 --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr = wrote: >=20 > Now... > make buildworld ... > In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: > In file included from = /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: > In file included from > /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: > In file included from /usr/include/c++/v1/algorithm:634: > In file included from /usr/include/c++/v1/memory:604: > /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = file not > found > #include <__undef___deallocate> > ^ Yes, this is because of the bad advice to run "make delete-old" before you had run "make installworld". You had an older version of libc++ in /usr/include/c++, but that still required the __undef___deallocate header, which has now been deleted by "make delete-old". Your best chance is to build and install libc++ first, if possible, by doing: cd /usr/src/lib/libc++ make obj make depend make make install Then retry building world. -Dimitry --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljEnpYACgkQsF6jCi4glqPOoACggltzSf6pPy05Y3w7yUk/1XXm 5iMAnAvdwG8GpvxfnIQqIgRT10XeDvjt =1z10 -----END PGP SIGNATURE----- --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7-- From owner-freebsd-current@freebsd.org Sun Mar 12 01:21:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 170C7CF9B23 for ; Sun, 12 Mar 2017 01:21:03 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D318A1103; Sun, 12 Mar 2017 01:21:02 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id m27so13973806iti.0; Sat, 11 Mar 2017 17:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fqnncgU+v0XHU0Q3MrS+JmdoLr4fQVaOG2oSTvXIVVI=; b=KTtvuB7LBVqMXJACyG7K7mqepsp3ZoATc/bJmoXoIVhXXiBlMnUjw14JA8z9AiT6TZ hQDfTOPoUBrQ+iqkvZXfTF2bK04LhHm/aRMc3Xa5v09avjeBGHBEjD/uslFbSVI3c9pg n1ENwwo2Lor8q69AhNVCwbv0/rf0T3wvUzHqopN8QY13hcDUNb+/QvEUyXkpc8vjiQfj 2tojel/Xfq7GlSu6IlrUpv+wT5o6UWtEOWcxYQjXnZxZ0xKl76CApzJac2WT1KW29rc7 zl2j2KbWz82SXRqMHQ0ZPG1R2oVhjTqh69E6COre+JtVu2Hs2pqKzMkNTFGGatcCbJJE Xuqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fqnncgU+v0XHU0Q3MrS+JmdoLr4fQVaOG2oSTvXIVVI=; b=CYVsYLak30jTG4wj4yvZ3lqKyEuTEx69OVB8phl4SoWbcUsEUJIUmJrZjuNlQbo1uN zsmzShwxUVjWeVsdlwxUtGTtBx7Kw/nN01R09X1pD6yUueOjtSch2JylzXsbfDdj2TKC s6X/Ckuy7Pn9uEwAU1f/u2iuI6yNFT/nSkALq/b1lLD7d99dposzW6Pm58sbRsMAeck3 ZaUatg8aSZDIUVFOhyPT763qCicAeD9DvNIZgfvL4OMrsVnW4Bc3ljvlFtF3oRVMCV+Q Aoc8TQzYZ57rQdGOwUcGvGh1EHnIj91Qg3pAT2GtlhshQVNIYfRAwBS2FOz8WYgOeQtQ hX1A== X-Gm-Message-State: AFeK/H0blipwt4C5ci5oDmweEkJWK3BLurbFC+zFJLxriJ3/qTKWd3+VDvqCB8GytseO9RQaBSavJHy8ArOu1g== X-Received: by 10.36.60.198 with SMTP id m189mr5189016ita.117.1489281662202; Sat, 11 Mar 2017 17:21:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sat, 11 Mar 2017 17:21:01 -0800 (PST) Received: by 10.64.226.228 with HTTP; Sat, 11 Mar 2017 17:21:01 -0800 (PST) In-Reply-To: References: <201703120038.v2C0cF2V088898@slippy.cwsent.com> From: Roberto Rodriguez Jr Date: Sun, 12 Mar 2017 01:21:01 +0000 Message-ID: Subject: Re: buildworld error To: dim@freebsd.org Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 01:21:03 -0000 Thanks! Rechecking out src tree. It seems my errors are like u said about 'make delete-old' From owner-freebsd-current@freebsd.org Sun Mar 12 01:46:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DDE5D0673D for ; Sun, 12 Mar 2017 01:46:45 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C266F1043; Sun, 12 Mar 2017 01:46:44 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id msanc4TKJsa1kmsaocJd4y; Sat, 11 Mar 2017 18:46:42 -0700 X-Authority-Analysis: v=2.2 cv=W+NIbVek c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=blgQG4KcO5sFK1PDQnoA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 36555377; Sat, 11 Mar 2017 17:46:41 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2C1keSL088648; Sat, 11 Mar 2017 17:46:40 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703120146.v2C1keSL088648@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric cc: Roberto Rodriguez Jr , Cy Schubert , FreeBSD Current Subject: Re: buildworld error In-Reply-To: Message from Dimitry Andric of "Sun, 12 Mar 2017 02:04:14 +0100." <5CB065B0-5A7D-4A50-A722-8EA579A67188@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Mar 2017 17:46:40 -0800 X-CMAE-Envelope: MS4wfG3D+JpaJeRn3/gy0aLDTRNMF3SNLj/jxnSZHk1fI0uz5SbMKQl5v3qrFezd5jil3u7er35HrqUclrBgirLVoeJBxEyFzRZveJXPyu2bdD4/MeNdQTR+ zk3HntajCzktTs1ldgNv4rVeJb29Am8EmvpMNwC9JVZAtkuyBvIg86CIj6NJkriEyZEWCBx43bTqML913GdZFMX5pJbp0g0KiTl166CSlHf3NHCA8FirXImi NOElSfxuw2N4GZ6pFDDoww== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 01:46:45 -0000 In message <5CB065B0-5A7D-4A50-A722-8EA579A67188@FreeBSD.org>, Dimitry Andric w rites: > > > --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr = > wrote: > >=20 > > Now... > > make buildworld > ... > > In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: > > In file included from = > /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: > > In file included from > > /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: > > In file included from /usr/include/c++/v1/algorithm:634: > > In file included from /usr/include/c++/v1/memory:604: > > /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = > file not > > found > > #include <__undef___deallocate> > > ^ > > Yes, this is because of the bad advice to run "make delete-old" before > you had run "make installworld". You had an older version of libc++ in > /usr/include/c++, but that still required the __undef___deallocate > header, which has now been deleted by "make delete-old". > > Your best chance is to build and install libc++ first, if possible, by > doing: > > cd /usr/src/lib/libc++ > make obj > make depend > make > make install > > Then retry building world. If this actually fixes it, it (the build) is wrong. You shouldn't have to build and install src in order to build another part of src. The procedure has always been documented as make installworld first then make delete-old. Failing to do so will on rare occasions bite you when building a port. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun Mar 12 02:24:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B55A3D074D7 for ; Sun, 12 Mar 2017 02:24:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 81A8A1866 for ; Sun, 12 Mar 2017 02:24:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x235.google.com with SMTP id 77so51638786pgc.1 for ; Sat, 11 Mar 2017 18:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=lv8Ru6HyihUKrpFS2iY3loyB2meaZHbXLitzCovVizY=; b=EO4oslBt8wURpoHoosxJW5pKs42kadV83VEqMcu8URiUhXEaDGCr4LblkDa5QF1BVC 5fiQz1IyZCz6rUv/rmwzw5Ixngk8luDDwM0kE9hzYx/CzooRUYb1RAXILX/KVJHBTlxe y4odBagfvmW989Y+a7v67+DO87uRzcykG5MemVOmd+mV1XL1nUMbTdSISgnLMtkHFi1E jQ9HwSwZw4zBxw1H1/NZZF1dnJuca5MIs/tWliWTkvX3QaGLTC/zEHK5W5EJhwXbPSIU H7dmPC/I/0AR65Mndy71lORk/jYpZifASfV1BXqbrW90+oJvza0jIIHH5FEqyzEvWk4q nYig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=lv8Ru6HyihUKrpFS2iY3loyB2meaZHbXLitzCovVizY=; b=GtEReM5m3PE66Akm2NfzCHuArxyT5jZABZ5UtxvOEjbQUykajJGMmVbV6Oip2tlYut T8oPqfl7MaisbGqbFKkIBjdTZbmFeG4e/mNz/CXt9o8qBmriHabbO/dWUK2/zBv/SsT5 YZ+m/XTnxAredPUzNFpeu0COKaxU8SihXSWJz6YEAzB/MAPcmQYwBKp1dJbnIg+/Xigt 27TAn9s70HUiltXjNi69WnR7dJVT2e50Ok/6Fc0kH0StIEGCM73Ip4JCAWMmz9qFUjGe qTk+yHPyPV0Wt8X2V3aDvl/U3mgRJezbW6qMdr2XgJXulnYUCVuRel10JtXNdVB746bO LWVA== X-Gm-Message-State: AMke39kcFl4soG/nciMnDbW8jd7vw3zs8EyYiPGRPFImUsDsWFjKJB09iSl2WpyQ+203MQ== X-Received: by 10.98.67.193 with SMTP id l62mr29698279pfi.148.1489285448903; Sat, 11 Mar 2017 18:24:08 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id b70sm26179174pfc.100.2017.03.11.18.24.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 11 Mar 2017 18:24:08 -0800 (PST) Subject: Re: buildworld error Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_880B9979-E0BB-49DE-A438-655B56220EB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Sat, 11 Mar 2017 18:24:07 -0800 Cc: FreeBSD Current Message-Id: <12559915-1715-40A4-B628-FFAFCD27ABDA@gmail.com> References: To: Roberto Rodriguez Jr X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:24:09 -0000 --Apple-Mail=_880B9979-E0BB-49DE-A438-655B56220EB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 11, 2017, at 15:51, Roberto Rodriguez Jr = wrote: >=20 > I figured the script command... here is the new error r315090 >=20 > --- .depend --- > echo setkey.full: /usr/obj/usr/src/tmp/usr/lib/libc.a > /usr/obj/usr/src/tmp/usr/lib/libl.a > /usr/obj/usr/src/tmp/usr/lib/liby.a > /usr/obj/usr/src/tmp/usr/lib/libipsec.a >> .depend > --- setkey.o --- > /usr/local/libexec/ccache/cc -O2 -pipe -march=3Dbtver2 > -I/usr/src/sbin/setkey -I/usr/src/lib/libipsec -I/usr/src/lib/libipsec > -I/usr/src/sys/netipsec -DIPSEC_DEBUG -DYY_NO_UNPUT -DINET6 -I. -g -MD > -MF.depend.setkey.o -MTsetkey.o -std=3Dgnu99 -fstack-protector-strong > -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > -Wno-parentheses -Qunused-arguments -c /usr/src/sbin/setkey/setkey.c > -o setkey.o > --- all_subdir_lib --- > --- jemalloc_nstime.po --- > /usr/local/libexec/ccache/cc -pg -O2 -pipe -march=3Dbtver2 > -I/usr/src/lib/libc/include -I/usr/src/include > -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 > -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/src/lib/libmd > -I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP > -DNS_CACHING -DSYMBOL_VERSIONING -MD -MF.depend.jemalloc_nstime.po > -MTjemalloc_nstime.po -std=3Dgnu99 -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Qunused-arguments > -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 > -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_nstime.c > -o jemalloc_nstime.po > --- all_subdir_rescue --- > --- suffix.o --- > /usr/local/libexec/ccache/cc -O2 -pipe -DHAVE_CONFIG_H > -I/usr/src/usr.bin/xz/../../lib/liblzma > -I/usr/src/usr.bin/xz/../../contrib/xz/src/common -march=3Dbtver2 > -DRESCUE -MD -MF.depend.suffix.o -MTsuffix.o -std=3Dgnu99 > -fstack-protector-strong -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Qunused-arguments -c > /usr/src/usr.bin/xz/../../contrib/xz/src/xz/suffix.c -o suffix.o > --- all_subdir_sbin --- > /usr/src/sbin/setkey/setkey.c:154:15: error: use of undeclared > identifier 'IPSEC_POLICYSCOPE_GLOBAL' > f_scope |=3D IPSEC_POLICYSCOPE_GLOBAL; > ^ > /usr/src/sbin/setkey/setkey.c:157:15: error: use of undeclared > identifier 'IPSEC_POLICYSCOPE_IFNET' > f_scope |=3D IPSEC_POLICYSCOPE_IFNET; > ^ Some new symbols were added to sys/netipsec/=E2=80=A6 and unfortunately = the system headers don=E2=80=99t provide that symbol. This should fix the issue =E2=80=94 I=E2=80=99ll run the change through = make tinderbox before committing, then analyze the .depend files, just = to make sure it's bootstrapping properly. Thanks! -Ngie $ svn diff Makefile Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile (revision 315094) +++ Makefile (working copy) @@ -46,7 +46,7 @@ # ipsec_strerror.c is for avoiding shlib reference to non-exported = function. .PATH: ${SRCTOP}/lib/libipsec ${SRCTOP}/sys/netipsec SRCS+=3D pfkey.c pfkey_dump.c key_debug.c ipsec_strerror.c -CFLAGS+=3D -I${SRCTOP}/sys/netipsec +CFLAGS+=3D -I${SRCTOP}/sys SRCS+=3D y.tab.h y.tab.h: parse.y --Apple-Mail=_880B9979-E0BB-49DE-A438-655B56220EB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxLFHAAoJEPWDqSZpMIYViOsP/0f9+KPQJinn37ASWzV+93sZ 7CT2NWCS+5A47Ou+OK2uLrS1roecPhvm85OobIVUupNNphaxsmUn3PhjblytFDoX b+5IVyw5Qqhvu1MHxorItQaMgK326v8yeFuUQ2McMjMTMkIK8bGVBP5XxANYp2Bn JXjMWsFltd9cIo7LGs+T0wfGSwJbkpgVnCM1qCW3mSt5EgDRBI+wHDpPBQ/EJIOe TpQVH3i4wIl/xeBaiA+/ClTYmPs8zWRNK2dCFnTUNJGvgm3Xsdhx0qjlAlAEXlZU 4Cu8TkdRZ8RttdeAqPvLziLf077gzLnUhKUjNg5Kyc1ViACLtptPqouuGcadsuGj YkvZPR5KDMacSwWKznrr7f4QJngyE7XCInaD8eOk1Lk4GMEORP4P2xtVeiJHxDYd jSE9toVZhOox92bwwFsgchiNHDdm0cxShSMKQtWnSWdsU2Q9oj+b2QfeotJuHckc SpY7BvFzmuTBdPPmyUEwZMgduD7J6uUvvlQGN3EfBIL29w28B7+kXQdDr11+KJ7D 6KwHf+W/emU2kmKJyi9dc7jl+tDeCjl6GL8xfnTbBYYt+e7K7PNxkoSv2V5hpa2R rXxZyWCl9giwPqS60rt6rT/mgtqKqBE+5+vlpMqZnwmpsFZtKfhrfFYzC2XBmlXi 3fBu7769qymjSqH3eOqR =n652 -----END PGP SIGNATURE----- --Apple-Mail=_880B9979-E0BB-49DE-A438-655B56220EB6-- From owner-freebsd-current@freebsd.org Sun Mar 12 02:29:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A338D0764C for ; Sun, 12 Mar 2017 02:29:04 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92D9C19FA; Sun, 12 Mar 2017 02:29:03 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 46B8A7E927; Sun, 12 Mar 2017 13:28:59 +1100 (EST) Subject: Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX To: Ian Lepore , FreeBSD Current References: <1489274995.40576.65.camel@freebsd.org> From: Lawrence Stewart Message-ID: <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> Date: Sun, 12 Mar 2017 13:27:36 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1489274995.40576.65.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:29:04 -0000 Hi Ian, On 12/03/2017 10:29, Ian Lepore wrote: > On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote: >> Hi all, >> >> I'm unable to complete buildworld with 2 recent svn revs I've tried >> (r314838 and r315059). I'm building for a slightly resource >> constrained >> production system so am specifying custom settings and a different >> obj >> tree location so I can copy it to the target system. The error >> persists >> after an "rm -rf /usr/obj/*", and if parallel building is disabled. >> >> The underlying build system built from r314838 via simple "make -C >> /usr/src -s -j6 buildworld buildkernel" built and installed fine, so >> the >> problem seems to be around the use of the build customisations. >> >> Any clues? >> >> Cheers, >> Lawrence >> >> >> root@builder-head-amd64:/usr/src # cat cust_make.conf >> KERNCONF=GENERIC-NODEBUG >> MALLOC_PRODUCTION=YES >> >> root@builder-head-amd64:/usr/src # cat cust_src.conf >> WITHOUT_PROFILE=1 >> >> root@builder-head-amd64:/usr/src # make >> __MAKE_CONF=/usr/src/cust_make.conf SRCCONF=/usr/src/cust_src.conf >> MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel >> [...] >> MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> CC="cc -target x86_64-unknown-freebsd12.0 >> --sysroot=/usr/obj/cust/usr/src/tmp >> -B/usr/obj/cust/usr/src/tmp/usr/bin >> -O2 -pipe -std=gnu99 -Qunused-arguments " CXX="c++ -target >> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp >> -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments >> -Wno-c++11-extensions " make .MAKE.MODE="normal curdirOk=yes" >> .MAKE.META.IGNORE_PATHS="" -f rescue.mk exe >> cc -target x86_64-unknown-freebsd12.0 >> --sysroot=/usr/obj/cust/usr/src/tmp >> -B/usr/obj/cust/usr/src/tmp/usr/bin >> -O2 -pipe -std=gnu99 -Qunused-arguments -nostdlib -Wl,-dc -r >> -o >> cat.lo cat_stub.o >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o >> cc: error: no such file or directory: >> '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o' >> *** Error code 1 >> >> There appear to be a lot of missing .o files under the rescue obj >> tree: >> >> root@builder-head-amd64:/usr/src # find >> /usr/obj/cust/usr/src/rescue/rescue//usr -type f >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h >> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost >> >> compared with an obj tree on a different head system: >> >> find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l >> 1552 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd >> .org" > > The MAKEOBJDIRPREFIX variable must be set in the environment, not in > make.conf or on the make command line (documented in build(7)). Your assertion seems at odds with my past experience and my reading of the man page... from build(7): The build may be controlled by defining make(1) variables described in the ENVIRONMENT section below, and by the variables documented in make.conf(5). ... which indicates they are make variables, not environment variables specifically. As a concrete example, TARGET and DESTDIR are listed under the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows: make TARGET=sparc64 buildworld make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld I've certainly always set build vars documented in the "ENVIRONMENT" section of the man page on the make command line without issue. Pretty sure I've set MAKEOBJDIRPREFIX from the make command line also in the past, though perhaps it has been working for me "by accident" and a documentation tweak is in order if the distinction you make is in fact relevant... Cheers, Lawrence From owner-freebsd-current@freebsd.org Sun Mar 12 02:35:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F110D078D5 for ; Sun, 12 Mar 2017 02:35:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 CFC271ED2; Sun, 12 Mar 2017 02:35:35 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x22a.google.com with SMTP id 25so51865724pgy.0; Sat, 11 Mar 2017 18:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=y0PKcwzNmV3c43OTDrvO1A9UrRaCC7SEg3fsTAGYmaU=; b=TYrrj69h0IzfGdfckedcIyM3srMOXhrDpdBulLXAidSEqm5+beo59lzugF80XbS1/U D750sfI07p4fWvuF3R0TwCfvLkz/jYQf8Xrz9NUAYtWf70dhYMdzISS8JDsLc7jfpnIK fNWocnuVdu4mleuurzkg1P7FXj7cnTRr1jYvY4LZZVbhbxO5VJb47oblPeGaSNfSI/ea fjPcAu8umjCgaQtEjYF+HzuaPGRMJrMSn2R7UY9CL0aIkA5g1msYjoZZABtjL5MJjwDr k8CMknKXAJ1IuBOewc7vygIy9mLKyVCdMVusGxWlTLGBTVFjpFbe3sSMkLwXVLBwY+/J Bldw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=y0PKcwzNmV3c43OTDrvO1A9UrRaCC7SEg3fsTAGYmaU=; b=q2ZiCWIzGzk80jsGPHR++LpUcgdLbwDCm/7PHXq0EApddEECVhbElopgi7btCQLTjm vXY0PmhaOpk6KaUGvsjbEJg56DCtpwfHxr8pR8RcvPCblU/BCFDu04wETH0NtruYeiUf Wy9fYoXIKNTACYVS345A2G7UEJkEKzL2kEXVtcZu9dTVX21tC0uGMD2x2NxIghrTkl+W pIskcSdFWFZ6mMftiWUlJCChO/vK9e4tQcipWnvKbq6/DT7DtrnNN0bOnUa8whIa9Vj7 7pXaHa6pVVe6UcE+Qrbcrvf+r5hyRgkYmcH2+Kk4sn77NWYUD5xULoNLN5hWgsGDXWAu CuPA== X-Gm-Message-State: AMke39mI5Xw4Zbdo7Cx2pp0g9gTRKKafm7ep7SwMQv39AjooYETf8PF3ppu0SGa96baMkg== X-Received: by 10.98.133.6 with SMTP id u6mr30360570pfd.48.1489286135198; Sat, 11 Mar 2017 18:35:35 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id t12sm26239137pfg.14.2017.03.11.18.35.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 11 Mar 2017 18:35:34 -0800 (PST) Subject: Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FDB09B60-3DC2-410F-AF10-6449417BCAC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> Date: Sat, 11 Mar 2017 18:35:33 -0800 Cc: Ian Lepore , FreeBSD Current Message-Id: References: <1489274995.40576.65.camel@freebsd.org> <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> To: Lawrence Stewart X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:35:36 -0000 --Apple-Mail=_FDB09B60-3DC2-410F-AF10-6449417BCAC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 11, 2017, at 18:27, Lawrence Stewart = wrote: >=20 > Hi Ian, =E2=80=A6 >> The MAKEOBJDIRPREFIX variable must be set in the environment, not in >> make.conf or on the make command line (documented in build(7)). >=20 > Your assertion seems at odds with my past experience and my reading of > the man page... from build(7): >=20 > The build may be controlled by defining make(1) variables > described in the ENVIRONMENT section below, and by the > variables documented in make.conf(5). >=20 > ... which indicates they are make variables, not environment variables > specifically. As a concrete example, TARGET and DESTDIR are listed = under > the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows: >=20 > make TARGET=3Dsparc64 buildworld > make TARGET=3Dsparc64 DESTDIR=3D/clients/sparc64 = installworld >=20 > I've certainly always set build vars documented in the "ENVIRONMENT" > section of the man page on the make command line without issue. Pretty > sure I've set MAKEOBJDIRPREFIX from the make command line also in the > past, though perhaps it has been working for me "by accident" and a > documentation tweak is in order if the distinction you make is in fact > relevant... Hi Lawrence, Ian=E2=80=99s right per historical behavior, which should still be in = effect today. Unfortunately, setting MAKEOBJDIRPREFIX on the command line will result = in bad things happening because of how bsd.obj.mk works and how = MAKEOBJDIRPREFIX is manipulated in the build itself (see = Makefile.libcompat =E2=80=94 it affects some architectures, but maybe = not sparc64). =46rom =E2=80=A6/Makefile (which should have triggered = this error message to begin with): 171 MAKEOBJDIRPREFIX?=3D /usr/obj 172 _MAKEOBJDIRPREFIX!=3D /usr/bin/env -i PATH=3D${PATH} MK_AUTO_OBJ=3Dno = ${MAKE} \ 173 ${.MAKEFLAGS:MMAKEOBJDIRPREFIX=3D*} __MAKE_CONF=3D${__MAKE_CONF} = \ 174 -f /dev/null -V MAKEOBJDIRPREFIX dummy 175 .if !empty(_MAKEOBJDIRPREFIX) 176 .error MAKEOBJDIRPREFIX can only be set in environment, not as a = global\ 177 (in make.conf(5)) or command-line variable. 178 .endif Are you sure your script/process didn=E2=80=99t catch a relevant build = error? Cheers, -Ngie --Apple-Mail=_FDB09B60-3DC2-410F-AF10-6449417BCAC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxLP1AAoJEPWDqSZpMIYVKekP/29g3k29s6BEwtCft0XqfiSs JAEIQkx5B+YrCphaTyMyYUoWu/m0thgJXqlLrD0vnUQYpHKff525W+YNGnpE7jvS TdkZrm8rOt0HalEfGX3YFhmP7jrGwyjLkmfnd7WhNSQ4KnGCOTrKRzJ8DjcJD2dj cBYZ3czlYd41hvc4spKJQ7Vv+dAVDNRQS3qo//8XNwD2MQVBSnVjWPJacT+B1O9S SUG1M1TvauLgkzGZQgGbzDAIH5SksjwsZL8a9BOpMQ9qlutwZStACYAsgzWhGwHd INViKy9GRbPTFBk2ymDW46s8eqxwhkAiKbUXb4x8coP0239xnUPypspdSGdyHKNH DIu33mXIESCxGcwOQPRQ9qvBSbG+TZ2sNR7X18OPHPGewY1jIsjv+fmEt0VunfkB dZTSLaxT7MFxmYwNHhzVAssqBAE+52TARua12ZLClEltda5E0ql+cy4G+tvjNJeb 1gjkyn2VBZUhaXfP6Gd+jm/4UELRz0vm7rQKXaIhY7Zb7VMeYRkf6YtMvXsPVakN ZVklhVd6ZdHOwLXh2LGLZG2FlGGso+pyWHGp9GnDxinbXQkMW/S0qK9RTGRObXE2 H9BabQL2zDVsb1dSEnBqwmfwl42EJK11OcbA0FnyrcLNTolRRb6banqh5RZqkJIx txSpgRB5plnBWLOBxh0z =2q9C -----END PGP SIGNATURE----- --Apple-Mail=_FDB09B60-3DC2-410F-AF10-6449417BCAC7-- From owner-freebsd-current@freebsd.org Sun Mar 12 02:37:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 315F9D07A69 for ; Sun, 12 Mar 2017 02:37:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 14B7E109F for ; Sun, 12 Mar 2017 02:37:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c05af9bd-06cc-11e7-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id c05af9bd-06cc-11e7-b3c2-c9f38144898e; Sun, 12 Mar 2017 02:36:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2C2bWrc002437; Sat, 11 Mar 2017 19:37:32 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1489286252.40576.68.camel@freebsd.org> Subject: Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX From: Ian Lepore To: Lawrence Stewart , FreeBSD Current Date: Sat, 11 Mar 2017 19:37:32 -0700 In-Reply-To: <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> References: <1489274995.40576.65.camel@freebsd.org> <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:37:36 -0000 On Sun, 2017-03-12 at 13:27 +1100, Lawrence Stewart wrote: > Hi Ian, > > On 12/03/2017 10:29, Ian Lepore wrote: > > > > On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote: > > > > > > Hi all, > > > > > > I'm unable to complete buildworld with 2 recent svn revs I've > > > tried > > > (r314838 and r315059). I'm building for a slightly resource > > > constrained > > > production system so am specifying custom settings and a > > > different > > > obj > > > tree location so I can copy it to the target system. The error > > > persists > > > after an "rm -rf /usr/obj/*", and if parallel building is > > > disabled. > > > > > > The underlying build system built from r314838 via simple "make > > > -C > > > /usr/src -s -j6 buildworld buildkernel" built and installed fine, > > > so > > > the > > > problem seems to be around the use of the build customisations. > > > > > > Any clues? > > > > > > Cheers, > > > Lawrence > > > > > > > > > root@builder-head-amd64:/usr/src # cat cust_make.conf > > > KERNCONF=GENERIC-NODEBUG > > > MALLOC_PRODUCTION=YES > > > > > > root@builder-head-amd64:/usr/src # cat cust_src.conf > > > WITHOUT_PROFILE=1 > > > > > > root@builder-head-amd64:/usr/src # make > > > __MAKE_CONF=/usr/src/cust_make.conf > > > SRCCONF=/usr/src/cust_src.conf > > > MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel > > > [...] > > > MK_AUTO_OBJ=no > > > MK_TESTS=no  UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1 > > > CC="cc -target x86_64-unknown-freebsd12.0 > > > --sysroot=/usr/obj/cust/usr/src/tmp > > > -B/usr/obj/cust/usr/src/tmp/usr/bin > > > -O2 -pipe   -std=gnu99    -Qunused-arguments  "  CXX="c++  - > > > target > > > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp > > > -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments > > > -Wno-c++11-extensions  "  make .MAKE.MODE="normal curdirOk=yes" > > > .MAKE.META.IGNORE_PATHS=""  -f rescue.mk exe > > > cc -target x86_64-unknown-freebsd12.0 > > > --sysroot=/usr/obj/cust/usr/src/tmp > > > -B/usr/obj/cust/usr/src/tmp/usr/bin > > > -O2 -pipe   -std=gnu99    -Qunused-arguments   -nostdlib -Wl,-dc > > > -r > > > -o > > > cat.lo cat_stub.o > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o > > > cc: error: no such file or directory: > > > '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o' > > > *** Error code 1 > > > > > > There appear to be a lot of missing .o files under the rescue obj > > > tree: > > > > > > root@builder-head-amd64:/usr/src # find > > > /usr/obj/cust/usr/src/rescue/rescue//usr -type f > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost > > > > > > compared with an obj tree on a different head system: > > > > > > find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l > > >     1552 > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre > > > ebsd > > > .org" > > The MAKEOBJDIRPREFIX variable must be set in the environment, not > > in > > make.conf or on the make command line (documented in build(7)). > Your assertion seems at odds with my past experience and my reading > of > the man page... from build(7): > > The build may be controlled by defining make(1) variables > described in the ENVIRONMENT section below, and by the > variables documented in make.conf(5). > > ... which indicates they are make variables, not environment > variables > specifically. As a concrete example, TARGET and DESTDIR are listed > under > the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows: > >            make TARGET=sparc64 buildworld >            make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld > > I've certainly always set build vars documented in the "ENVIRONMENT" > section of the man page on the make command line without issue. > Pretty > sure I've set MAKEOBJDIRPREFIX from the make command line also in the > past, though perhaps it has been working for me "by accident" and a > documentation tweak is in order if the distinction you make is in > fact > relevant... > > Cheers, > Lawrence > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > .org" You cited everything from build(7) except the part most on-point for the problem you're having: MAKEOBJDIRPREFIX Defines the prefix for directory names in the tree of built objects.  Defaults to /usr/obj if not defined.  This variable should only be set in the environment and not via /etc/make.conf or the command line. -- Ian From owner-freebsd-current@freebsd.org Sun Mar 12 02:47:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44019D07DCE for ; Sun, 12 Mar 2017 02:47:26 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4CAF16B6; Sun, 12 Mar 2017 02:47:25 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 19ADB7E90F; Sun, 12 Mar 2017 13:47:21 +1100 (EST) Subject: [SOLVED] Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX To: Ian Lepore , FreeBSD Current References: <1489274995.40576.65.camel@freebsd.org> <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> <1489286252.40576.68.camel@freebsd.org> From: Lawrence Stewart Message-ID: <5c36b243-795a-3a00-a6e7-8d960bc18aa1@freebsd.org> Date: Sun, 12 Mar 2017 13:45:58 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1489286252.40576.68.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:47:26 -0000 On 12/03/2017 13:37, Ian Lepore wrote: > On Sun, 2017-03-12 at 13:27 +1100, Lawrence Stewart wrote: >> Hi Ian, >> >> On 12/03/2017 10:29, Ian Lepore wrote: >>> >>> On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote: >>>> >>>> Hi all, >>>> >>>> I'm unable to complete buildworld with 2 recent svn revs I've >>>> tried >>>> (r314838 and r315059). I'm building for a slightly resource >>>> constrained >>>> production system so am specifying custom settings and a >>>> different >>>> obj >>>> tree location so I can copy it to the target system. The error >>>> persists >>>> after an "rm -rf /usr/obj/*", and if parallel building is >>>> disabled. >>>> >>>> The underlying build system built from r314838 via simple "make >>>> -C >>>> /usr/src -s -j6 buildworld buildkernel" built and installed fine, >>>> so >>>> the >>>> problem seems to be around the use of the build customisations. >>>> >>>> Any clues? >>>> >>>> Cheers, >>>> Lawrence >>>> >>>> >>>> root@builder-head-amd64:/usr/src # cat cust_make.conf >>>> KERNCONF=GENERIC-NODEBUG >>>> MALLOC_PRODUCTION=YES >>>> >>>> root@builder-head-amd64:/usr/src # cat cust_src.conf >>>> WITHOUT_PROFILE=1 >>>> >>>> root@builder-head-amd64:/usr/src # make >>>> __MAKE_CONF=/usr/src/cust_make.conf >>>> SRCCONF=/usr/src/cust_src.conf >>>> MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel >>>> [...] >>>> MK_AUTO_OBJ=no >>>> MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >>>> CC="cc -target x86_64-unknown-freebsd12.0 >>>> --sysroot=/usr/obj/cust/usr/src/tmp >>>> -B/usr/obj/cust/usr/src/tmp/usr/bin >>>> -O2 -pipe -std=gnu99 -Qunused-arguments " CXX="c++ - >>>> target >>>> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp >>>> -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments >>>> -Wno-c++11-extensions " make .MAKE.MODE="normal curdirOk=yes" >>>> .MAKE.META.IGNORE_PATHS="" -f rescue.mk exe >>>> cc -target x86_64-unknown-freebsd12.0 >>>> --sysroot=/usr/obj/cust/usr/src/tmp >>>> -B/usr/obj/cust/usr/src/tmp/usr/bin >>>> -O2 -pipe -std=gnu99 -Qunused-arguments -nostdlib -Wl,-dc >>>> -r >>>> -o >>>> cat.lo cat_stub.o >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o >>>> cc: error: no such file or directory: >>>> '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o' >>>> *** Error code 1 >>>> >>>> There appear to be a lot of missing .o files under the rescue obj >>>> tree: >>>> >>>> root@builder-head-amd64:/usr/src # find >>>> /usr/obj/cust/usr/src/rescue/rescue//usr -type f >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h >>>> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost >>>> >>>> compared with an obj tree on a different head system: >>>> >>>> find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l >>>> 1552 >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre >>>> ebsd >>>> .org" >>> The MAKEOBJDIRPREFIX variable must be set in the environment, not >>> in >>> make.conf or on the make command line (documented in build(7)). >> Your assertion seems at odds with my past experience and my reading >> of >> the man page... from build(7): >> >> The build may be controlled by defining make(1) variables >> described in the ENVIRONMENT section below, and by the >> variables documented in make.conf(5). >> >> ... which indicates they are make variables, not environment >> variables >> specifically. As a concrete example, TARGET and DESTDIR are listed >> under >> the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows: >> >> make TARGET=sparc64 buildworld >> make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld >> >> I've certainly always set build vars documented in the "ENVIRONMENT" >> section of the man page on the make command line without issue. >> Pretty >> sure I've set MAKEOBJDIRPREFIX from the make command line also in the >> past, though perhaps it has been working for me "by accident" and a >> documentation tweak is in order if the distinction you make is in >> fact >> relevant... >> >> Cheers, >> Lawrence >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd >> .org" > > You cited everything from build(7) except the part most on-point for > the problem you're having: > > MAKEOBJDIRPREFIX > Defines the prefix for directory names in the tree of > built objects. Defaults to /usr/obj if not defined. This variable > should only be set in the environment and not via /etc/make.conf or the > command line. Oh dear. I *completely* glossed over that... multiple times. Derp. Thank you for the liberal application of clue bat and my apologies for the noise Cheers, Lawrence From owner-freebsd-current@freebsd.org Sun Mar 12 10:36:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF7FDD081F0 for ; Sun, 12 Mar 2017 10:36:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9640610B0 for ; Sun, 12 Mar 2017 10:36:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::c52b:f4eb:5bf4:e273] (unknown [IPv6:2001:7b8:3a7:0:c52b:f4eb:5bf4:e273]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6F6F52EA32; Sun, 12 Mar 2017 11:36:20 +0100 (CET) From: Dimitry Andric Message-Id: <1C4E6A09-86AD-4DC7-AA65-336A1643E070@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: buildworld error Date: Sun, 12 Mar 2017 11:36:11 +0100 In-Reply-To: <201703120146.v2C1keSL088648@slippy.cwsent.com> Cc: Roberto Rodriguez Jr , FreeBSD Current To: Cy Schubert References: <201703120146.v2C1keSL088648@slippy.cwsent.com> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 10:36:23 -0000 --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 12 Mar 2017, at 02:46, Cy Schubert wrote: > > In message <5CB065B0-5A7D-4A50-A722-8EA579A67188@FreeBSD.org>, Dimitry > Andric w > rites: >> >> >> --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=us-ascii >> >> On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr = >> wrote: >>> =20 >>> Now... >>> make buildworld >> ... >>> In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: >>> In file included from = >> /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: >>> In file included from >>> /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: >>> In file included from /usr/include/c++/v1/algorithm:634: >>> In file included from /usr/include/c++/v1/memory:604: >>> /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = >> file not >>> found >>> #include <__undef___deallocate> >>> ^ >> >> Yes, this is because of the bad advice to run "make delete-old" before >> you had run "make installworld". You had an older version of libc++ in >> /usr/include/c++, but that still required the __undef___deallocate >> header, which has now been deleted by "make delete-old". >> >> Your best chance is to build and install libc++ first, if possible, by >> doing: >> >> cd /usr/src/lib/libc++ >> make obj >> make depend >> make >> make install >> >> Then retry building world. > > If this actually fixes it, it (the build) is wrong. You shouldn't have to > build and install src in order to build another part of src. > > The procedure has always been documented as make installworld first then > make delete-old. Failing to do so will on rare occasions bite you when > building a port. Yes, but in this case Roberto ran "make delete-old" *before* installing world, on your advice. That is definitely something that should be avoided. E.g., "make delete-old" should only ever be run with exactly the same source tree that your current world was installed from. And preferably right after "make installworld" and updating /etc. -Dimitry --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljFJKMACgkQsF6jCi4glqMSSQCg4Pbv9YGsRSbSXsl3dLdUOV2l 3BYAni5W3WMifJlYr41du/rfQAjTshvX =hdrh -----END PGP SIGNATURE----- --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B-- From owner-freebsd-current@freebsd.org Sun Mar 12 10:54:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48B47D08875 for ; Sun, 12 Mar 2017 10:54:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB118F9 for ; Sun, 12 Mar 2017 10:54:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 2B5CDD08874; Sun, 12 Mar 2017 10:54:26 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AFD6D08873 for ; Sun, 12 Mar 2017 10:54:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E427018F8 for ; Sun, 12 Mar 2017 10:54:25 +0000 (UTC) (envelope-from Alexander@leidinger.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1489313760; bh=AyTOFMYnYQ6i9aqD5VSLgzziLxrBgzyS2U4A1Mn93YM=; h=Date:From:To:Subject; b=UZ4LaHUXNuTBK01pEHebSFsXnaVnvsRIcB1tfR9BG17rNjZJLwkLsrnS5kOfWkpLk zsytbZ6+cpiOnk1zJiHEYPTV5hdM1GimcXABqtw0ySjqrRq22tJf+VMfWEg+SKM8hB lk04vYMVQ3xF5dE80idmkytodwOYH0dWTng/TmVc59C09a0WTtlsg91yDtyCXav+t6 MSYwiIrhU/Pt7IlgcWPt84H6anYFj+geHf8O5WKacUkbUSNjHNdbZ1HCcFdeFPqZLh 6bFquVQnc2MzxZdWFSOLN3enron6ErPViUsFjihhMr7G4hdCXsoyTHGK7N0ZX/UN02 YnEpS81dE9qWA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1489316063; bh=AyTOFMYnYQ6i9aqD5VSLgzziLxrBgzyS2U4A1Mn93YM=; h=Date:From:To:Subject; b=zoozV126ss7jQTfpTqCyTgzQZxCh9wMlpGboXaywOtlIq5nG1py64RS2i0un4p/Nu jC8oUm+NJLTSHNz65IPHEu1W1eyc9gT4dC47QRterfXNZwe3Tu7Jzph9NhLAvno6+W 68IKykQ5ALmwhHNajbuqYvbhOLfOsKLzL0Z3eJ5w+35DMqU+oSXG53Ed8TrWs0CVRH ppcuopIMxeVadBC2f9qqDoZkgjN0oSgQKtfcRpy2rlo6OrsjwtcvMzAh169p9CYHGi bolIflIqea+2ajUCkjdFQimGMewQvLKye5xgpQaGHaCPI8Ov4ZcwFQpqmdO/uAfm3G xr1VuEnnN1Xzw== Date: Sun, 12 Mar 2017 11:15:59 +0100 Message-ID: <20170312111559.Horde.lhnOKM9_uZAWPdkKxJEvltE@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: deadlock in current (r314698)? User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_RXTphqFrJRtGSU72NZp_weF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 10:54:26 -0000 This message is in MIME format and has been PGP signed. --=_RXTphqFrJRtGSU72NZp_weF Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, do we have a known deadlock with r314698? I have a system which locks up and some seconds later the watchdog=20=20 kicks=20in and reboots. Sometimes it survives a day or two, sometimes it=20= =20 reboots=20more than once a day. I'm rebuilding the kernel with WITNESS=20= =20 now,=20but if someone is aware of a deadlock somewhere please tell. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_RXTphqFrJRtGSU72NZp_weF Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYxR/fAAoJEKrxQhqFIICEWdMQAIRTdEVhysH1TYtXgJVqMu8y HHf4mkSg9SKoh/TFU2qD9kjDwb/9tezZkOnei0toh8qTNO+SDZlCiLzr1OfXXzX3 9zoifi55z2UqPYIhejMGICcJKUD08K+i+U/OT0DW6oz8195UDgPZtIb7i47Wrhj/ ki7RG65AQ/is1L3aSH1Pjzt6by18ZkJYKFzmDNZ3PMiPUiaAyCOxuWLbkZV/cTMi QeJvegaiE69MMo/Pw2BmspvTslZP2QqwtzjooJdBCbMmRdwM6MELm8ndJnFv4Iye V3O3WQ5NZLu5BHx2YFeK4/P7vpGUIqIzY69kN4Sv8ZTBKCPyMEDKi2eLLXzqYN7G io92g6VKtzkypFeX/MtP/HvpyZYH8P8IPOk9VdlFG14Ry0ywefHbbHeUg5ZRO0Fz a8gjE5nGIn5YRdW2Y1NQ65/PqbujuLOFOgS2YPqDMgPQq2jHreApJlKWPNLEnOeD lInRfBo6EMl/31gD4LUd3+KtNuq/NqnmR/OBIt84cdeC7l1EwFqBWc3Xob1Y01bC 1aeOa2t+xNGFNKLVwZfnos0JBoyyLhkpw6+zNdB3LUMZ271GYFlXkObi5GYZtSj+ DwZ9eLJMgkM0ydKg6t/YFbaYmNBBjayTzHmgJcEPuqiKGn/zYpUPh/lTC+2yBmB5 5jMl1nd/vLvJQYOovxfJ =Fg9d -----END PGP SIGNATURE----- --=_RXTphqFrJRtGSU72NZp_weF-- From owner-freebsd-current@freebsd.org Sun Mar 12 11:30:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2E7FCF958D for ; Sun, 12 Mar 2017 11:30:04 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9698D1AA2; Sun, 12 Mar 2017 11:30:04 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-io0-x244.google.com with SMTP id 68so10915141ioh.3; Sun, 12 Mar 2017 04:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jtQSY5WV62KtKZeF42nVXbJBr6VopHSspppoPUsKPqE=; b=kVRWuNMun/Z5ZvYF7iev5rRGpsYvT//leByhVSlmdLlrgW3CY0vAwUhea5M6IVB+FE At4426m+77KWJRjXwsxxGHEojsFYan8Li1K4x4N3wuS08KeFNeU/76Chq0/a93rfKR4I ZAAnLxRtn953LzWZdohEKqAk8F6N8ch8sFYOdHdu33Dv2JwFYLre2TOCgn5wEZOjLLc1 WlA4zCZHT7qLrLbFyAYDm8Ax6toaw+ZUhfMz6Ce6GJGmC4NcbW8WI76Mg4qC1vZ4R6Sz TrgnIEBkKenqty23LmcJ87SWeI0ZsJcV/tNMmeNX0HG0kXq8FDC4zowTT3P2Y9vmxmN/ KUKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jtQSY5WV62KtKZeF42nVXbJBr6VopHSspppoPUsKPqE=; b=JWhxXnNXDCAx6M3Fc+1ns/FX98eGxLb+lk4PviGPJDxq8qes/KCb/a+Yl7CDI7kvNB LQCtSv3nCHc1geGNIGc1xturETvqCa5IjBaym+w0uvBoJGVMcDYcJjxfwGQ3gpQxrEKY d3yPEEPLto/gmgwNCy9ypjx4eoU5VrlDU7H5e6EFaYd5hhdSLye/HQ7RQ9PK2ruuL9EG 8URjS6nDj0e41d7kQZg8OLrlsIvJF4JfVHnQ+mWr3IAmNAci7A8RH74MZ+gD+7oT3kbw 5DVBjJYiGiH6t9hWj6OnPfAgXPtJ1M+YmOSrBkFCL/N4GzCkl6fTqjDi1T4QAJZrJ4zn xv1A== X-Gm-Message-State: AMke39k5CFm6rYHfeRp6ihfg4bYTwq4NCasGCwtzfAOZAsh/r5zZfY9q+h8GMiwqVVWPu8MwMQIYKY3ziO3w1A== X-Received: by 10.107.189.68 with SMTP id n65mr23160872iof.154.1489318203844; Sun, 12 Mar 2017 04:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.24 with HTTP; Sun, 12 Mar 2017 04:30:03 -0700 (PDT) In-Reply-To: <0A045FCC-90FC-43BA-93C5-316E52E33971@FreeBSD.org> References: <4D3C46D7-3EBF-47AE-BFFE-37ECEA4721FD@gmail.com> <5A39D9CC-339D-47C3-918A-F91E9CCC4E3E@fh-muenster.de> <5A56F5AA-F31E-4D7B-8CF4-918EB6F8285A@gmail.com> <9370498b79338dcfbbbc75c657e2b8b1@ultimatedns.net> <94871692b95acb7e3ece204732a10d7f@ultimatedns.net> <497DF4FE-2E2D-482D-A96B-AC4C300EF286@FreeBSD.org> <9bc29f27d01b0c40aa6b990b9c6aacbd@ultimatedns.net> <0A045FCC-90FC-43BA-93C5-316E52E33971@FreeBSD.org> From: Subbsd Date: Sun, 12 Mar 2017 14:30:03 +0300 Message-ID: Subject: Re: Boot failure - svn up from this morning To: Jonathan Anderson Cc: Chris H , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 11:30:04 -0000 Hi, I had the same problems, however, there is one more regression after these changes. It stably reproduces if you use EFI_STAGING_SIZE. I have custom FreeBSD distributive which has a sufficiently large mfsroot which is loaded through UEFI mode. To solve the problem, it was suggested to increase this variable and rebuild /sys/boot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944 Also, it has to be increased periodically for some reason: https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779&r2=305778&pathrev=305779 I've try to ask why than threatens to increase this parameter at once large (or make it dependent on RAM): https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html but there are no answer options. At the moment, on r315141 boot via UEFI is fixed without EFI_STAGING_SIZE. With EFI_STAGING_SIZE=768 i got regression after last changes in panic with follow message: failed to allocate staging area:9 failed to allocate stating area Failed to start image provided by ZFS (5) http://pasteboard.co/IvbhU9Ffu.jpg I believe that there mfsroot may be greater than 64MB soon or later. Also there are no problems with loading big mfsroot images when MBR method is used. PS: I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with constant CURRENT svnup/rebuilds for about a year. So I will be glad if you pay attention to this. PPS: How to reproduce: 1) EFI_STAGING_SIZE=768 in /etc/make.conf 2) make -C /sys/boot clean 3) make -C /sys/boot 4) make -C /sys/boot install 5) reboot Thanks! From owner-freebsd-current@freebsd.org Sun Mar 12 13:25:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F78AD094A5 for ; Sun, 12 Mar 2017 13:25:05 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 782A613A4; Sun, 12 Mar 2017 13:25:03 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.225.12.90]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MhhwJ-1ca5DQ22t9-00MqCW; Sun, 12 Mar 2017 14:24:55 +0100 Date: Sun, 12 Mar 2017 14:24:49 +0100 From: "O. Hartmann" To: Ian Lepore Cc: Lawrence Stewart , FreeBSD Current Subject: Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX Message-ID: <20170312142449.3f412b89@thor.intern.walstatt.dynvpn.de> In-Reply-To: <1489286252.40576.68.camel@freebsd.org> References: <1489274995.40576.65.camel@freebsd.org> <0aa75720-7670-9b64-a536-9958ff332eea@freebsd.org> <1489286252.40576.68.camel@freebsd.org> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/KoPQyiImqJ2tKbvkNoPCPgd"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:deNO5Bli5/kU8r7SlxGudc6Rhb5SCWZfKmtsVzgBkEfubowUweJ /LDlU4G2A+tiqVOuGEC1VUo5CwPHMZMHCR96J5EB1EOE76IGLMEkvdzM5EVjCYf1C2P+A8N j82GZHfuORMO2gare3wk36V3myikXm2BO+FGImMrO+GWHTyNVG5vxIZr9oiCtAlILumlt1r uC12ifrKFLARRL9ZvmfqQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:KiKHltQIg3g=:5/oD1dmYBbJ6zYhciR7d5V BeCorXB7wwTqxr8pkmN5rYCk4r3j8QgkZ8H2PEf6mPLxnt3tsfZbe3NUNJ9oC9VwJcVLx+mCb q8N9+1uQD7qsEcjsTu7V9KvYhjuUqWR/pWG50fLX6KUqQElMet1Vc2DEZ+H41EWHf8Y5aHEzH 8f68Zm9FCU5c3882NC58LpF8US10TpzHHeIcx1f7H5RIrvlHclnZ5Nh2iecweBTrttvJihZ6I T42mfIRC0u4Q8wiyyYtzgCdeCe58x/foA85qWJcUi+8DjrQV13bPGO0FNOCYlKvM/jh7e6n9u ElOwxqCuUAFrD9XkKcgUkbGUrIX6V8VdaIH7hbsfK0BOu65Y0t4H8k2igomQ+cEE2+9u8fIOR PLG1mZe9rbNq5bzeF3jz6CxusmHoLbsfbsQVHebcF3aHdN+vKAx8HsG5YLoMoxiwPAL8wJjsa c+imXorpTMWJFIk55Ol6d+QBJ3Hk0itQkd38SmPZ89cHBxcwVrBRth2g04n/XsXppvuC7aor+ ZsPu9siv3XdnB429feXeJ6gWABvKnS/0LXvNbBEoK3ual8GErwwI3Tt9v0SWoJqpx1zxuJWvb mLqPgQupk7ManDucQrSnRlZQpW1HQb+qJhIVkFDRxH+Y4Ypr9HwbnbLfKcxElqjdZ58qSpucH DzMmVPzjaYhy17FDXXucz3Eg7rIGPjC28CMVHmVgogGOAphv5E5XfgkZ9Qtq5tTrfCMqtx25A xTTNgE80AUl3Vgr0pr8KybJ5xjP9gtOA2t7COS7H0Q4/mtyMRkMPP1eEYno= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 13:25:05 -0000 --Sig_/KoPQyiImqJ2tKbvkNoPCPgd Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Am Sat, 11 Mar 2017 19:37:32 -0700 Ian Lepore schrieb: > On Sun, 2017-03-12 at 13:27 +1100, Lawrence Stewart wrote: > > Hi Ian, > >=20 > > On 12/03/2017 10:29, Ian Lepore wrote: =20 > > >=20 > > > On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote: =20 > > > >=20 > > > > Hi all, > > > >=20 > > > > I'm unable to complete buildworld with 2 recent svn revs I've > > > > tried > > > > (r314838 and r315059). I'm building for a slightly resource > > > > constrained > > > > production system so am specifying custom settings and a > > > > different > > > > obj > > > > tree location so I can copy it to the target system. The error > > > > persists > > > > after an "rm -rf /usr/obj/*", and if parallel building is > > > > disabled. > > > >=20 > > > > The underlying build system built from r314838 via simple "make > > > > -C > > > > /usr/src -s -j6 buildworld buildkernel" built and installed fine, > > > > so > > > > the > > > > problem seems to be around the use of the build customisations. > > > >=20 > > > > Any clues? > > > >=20 > > > > Cheers, > > > > Lawrence > > > >=20 > > > >=20 > > > > root@builder-head-amd64:/usr/src # cat cust_make.conf > > > > KERNCONF=3DGENERIC-NODEBUG > > > > MALLOC_PRODUCTION=3DYES > > > >=20 > > > > root@builder-head-amd64:/usr/src # cat cust_src.conf > > > > WITHOUT_PROFILE=3D1 > > > >=20 > > > > root@builder-head-amd64:/usr/src # make > > > > __MAKE_CONF=3D/usr/src/cust_make.conf > > > > SRCCONF=3D/usr/src/cust_src.conf > > > > MAKEOBJDIRPREFIX=3D/usr/obj/cust buildworld buildkernel > > > > [...] > > > > MK_AUTO_OBJ=3Dno > > > > MK_TESTS=3Dno=A0=A0UPDATE_DEPENDFILE=3Dno=A0=A0_RECURSING_CRUNCH=3D1 > > > > CC=3D"cc -target x86_64-unknown-freebsd12.0 > > > > --sysroot=3D/usr/obj/cust/usr/src/tmp > > > > -B/usr/obj/cust/usr/src/tmp/usr/bin > > > > -O2 -pipe=A0=A0=A0-std=3Dgnu99=A0=A0=A0=A0-Qunused-arguments=A0=A0"= =A0=A0CXX=3D"c++=A0=A0- > > > > target > > > > x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/cust/usr/src/tmp > > > > -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments > > > > -Wno-c++11-extensions=A0=A0"=A0=A0make .MAKE.MODE=3D"normal curdirO= k=3Dyes" > > > > .MAKE.META.IGNORE_PATHS=3D""=A0=A0-f rescue.mk exe > > > > cc -target x86_64-unknown-freebsd12.0 > > > > --sysroot=3D/usr/obj/cust/usr/src/tmp > > > > -B/usr/obj/cust/usr/src/tmp/usr/bin > > > > -O2 -pipe=A0=A0=A0-std=3Dgnu99=A0=A0=A0=A0-Qunused-arguments=A0=A0= =A0-nostdlib -Wl,-dc > > > > -r > > > > -o > > > > cat.lo cat_stub.o > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o > > > > cc: error: no such file or directory: > > > > '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o' > > > > *** Error code 1 > > > >=20 > > > > There appear to be a lot of missing .o files under the rescue obj > > > > tree: > > > >=20 > > > > root@builder-head-amd64:/usr/src # find > > > > /usr/obj/cust/usr/src/rescue/rescue//usr -type f > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h > > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost > > > >=20 > > > > compared with an obj tree on a different head system: > > > >=20 > > > > find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l > > > > =A0=A0=A0=A01552 > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre > > > > ebsd > > > > .org" =20 > > > The MAKEOBJDIRPREFIX variable must be set in the environment, not > > > in > > > make.conf or on the make command line (documented in build(7)). =20 > > Your assertion seems at odds with my past experience and my reading > > of > > the man page... from build(7): > >=20 > > The build may be controlled by defining make(1) variables > > described in the ENVIRONMENT section below, and by the > > variables documented in make.conf(5). > >=20 > > ... which indicates they are make variables, not environment > > variables > > specifically. As a concrete example, TARGET and DESTDIR are listed > > under > > the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows: > >=20 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0make TARGET=3Dsparc64 buildworld > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0make TARGET=3Dsparc64 DESTDIR=3D/clien= ts/sparc64 installworld > >=20 > > I've certainly always set build vars documented in the "ENVIRONMENT" > > section of the man page on the make command line without issue. > > Pretty > > sure I've set MAKEOBJDIRPREFIX from the make command line also in the > > past, though perhaps it has been working for me "by accident" and a > > documentation tweak is in order if the distinction you make is in > > fact > > relevant... > >=20 > > Cheers, > > Lawrence > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > > .org" =20 >=20 > You cited everything from build(7) except the part most on-point for > the problem you're having: >=20 > MAKEOBJDIRPREFIX > Defines the prefix for directory names in the tree of > built objects.=A0=A0Defaults to /usr/obj if not defined.=A0=A0Thi= s variable > should only be set in the environment and not via /etc/make.conf = or the > command line. >=20 > -- Ian >=20 Shouldn't it then be "... This variable must only be set in the environment= "? Every other attempt will fail. It would also be nice to have some more information abou= t the WHY. Using poudriere, one can set this variable within a per-set configuration f= ile aiming for a jail built upon sources on a local machine. Sometimes its really confusin= g when shell environment comes into play and when it all stays within the make domain. Kind regards, O. Hartmann --=20 O. Hartmann Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs. 4 BDS= G). --Sig_/KoPQyiImqJ2tKbvkNoPCPgd Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMVMIQAKCRDS528fyFhY lLvoAf9+9XreZoerLjULu+HFb0jaFBvn67xauk1mFOatAIwzNgzLKfzI2ldS0TiZ GNrsX5tjsulx5Tx1nKfCFJdN+1uqAf93RRixLvSkM0GIob70ykfPs5teOu9n/OGG iuYZ2Z+QA3ps0LX5rwXTi8XzpK1H7DoSGQo0KRCKQIFmbQwxROTC =a7+9 -----END PGP SIGNATURE----- --Sig_/KoPQyiImqJ2tKbvkNoPCPgd-- From owner-freebsd-current@freebsd.org Sun Mar 12 13:41:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BBE8D09B61 for ; Sun, 12 Mar 2017 13:41:15 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1FE31E11; Sun, 12 Mar 2017 13:41:14 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id m27so17049696iti.0; Sun, 12 Mar 2017 06:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r3WFpjzh03mRnVUzuRWttvC5eyai3NvG+GNGhAI81J0=; b=XfksMmmSE3X+kvI+aiVRrjR92kHVNYvgH0Ggo+YIhcJG0JMorx4GtCqIxD81GWRp5g +JlOnDjCOQxYXeWx3w1J52jLGnW7n4gWlgesRQKSvdQ2jMb1od/iOI0b2qNxYCqz5T2j MumN/J5sqIrnZILIZ8batAmLUk9XqeglsCHseZHGINsNjM9vmx4oohgDl2uQ2VLCDLa+ rfcGOPZ58IMsCTdxsl+2/WMJQFe7OnAm5iH9X/h1z9KBtst8nVXQ7Hu8w+yBQv//c3Zn 7ZJ/Dq3gRs2Kdp8QPy8CN7hCGw96y2TGZC3QYEjsxWmtpQp5se5Zcm/wJb+pX1kg21fE NIaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r3WFpjzh03mRnVUzuRWttvC5eyai3NvG+GNGhAI81J0=; b=O17gRuhNNeBhUYZgjgf6AizJc707aKdXSUmovEKimg7Z0RrbXzUGFtfqatJQ3Ly6pI qXo4LUnyP1jrqqQ9orcKjpjl/pdXYYS5Wh3DO9PLlAnZI+3smqO2p9AzyDYp+afXyJ8y 87g1wkviU6a631AA5BBhzDdVnuAuKqtanuNTOvNr6UBJ2HAdkqAXufTeQYADm2+NF9N+ cG28ndxzvpCN4aK8+XtqLGkiTCcscBYESSsTCqhmSuljkCCtzDNTx4C9zYHmEyOaq35S xyasWzJfG5Q1gPGjBouOL640SvT4jc5XtWQCPNVSZiQUX1Rzv1izqhKfpoPtqxjkKXEF ue0g== X-Gm-Message-State: AFeK/H2QRsYmKtX1GZTiVy7k+emItqVkiQy9kKP7nlZJlTaITFu3ejxXZ8mQspeblsgE+vE5eGM8zajdwabUSA== X-Received: by 10.36.124.16 with SMTP id a16mr7239719itd.90.1489326073966; Sun, 12 Mar 2017 06:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Sun, 12 Mar 2017 06:41:13 -0700 (PDT) Received: by 10.64.226.228 with HTTP; Sun, 12 Mar 2017 06:41:13 -0700 (PDT) In-Reply-To: <1C4E6A09-86AD-4DC7-AA65-336A1643E070@FreeBSD.org> References: <201703120146.v2C1keSL088648@slippy.cwsent.com> <1C4E6A09-86AD-4DC7-AA65-336A1643E070@FreeBSD.org> From: Roberto Rodriguez Jr Date: Sun, 12 Mar 2017 13:41:13 +0000 Message-ID: Subject: Re: buildworld error To: Dimitry Andric Cc: Cy Schubert , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 13:41:15 -0000 Hey, Even with a fresh checkout of sources ( today 935am EST). Buildworld/kernel fail 10 seconds into build. Thanks From owner-freebsd-current@freebsd.org Sun Mar 12 17:47:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E80FD09DB7 for ; Sun, 12 Mar 2017 17:47:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 1198211A0 for ; Sun, 12 Mar 2017 17:47:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d8b3be6b-074b-11e7-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id d8b3be6b-074b-11e7-b3c2-c9f38144898e; Sun, 12 Mar 2017 17:46:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2CHlJ1q001580; Sun, 12 Mar 2017 11:47:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489340839.40576.82.camel@freebsd.org> Subject: Re: process killed: text file modification From: Ian Lepore To: Gergely Czuczy , freebsd-current@freebsd.org Date: Sun, 12 Mar 2017 11:47:19 -0600 In-Reply-To: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 17:47:23 -0000 On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote: > > On 2017. 03. 09. 20:47, Gergely Czuczy wrote: > > > > > > > > On 2017. 03. 09. 19:44, John Baldwin wrote: > > > > > > On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote: > > > > > > > > [+freebsd-fs] > > > > > > > > > > > > On 2017. 03. 09. 14:20, Gergely Czuczy wrote: > > > > > > > > > > On 2017. 03. 09. 11:27, Gergely Czuczy wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I'm trying to build a few things from ports on an rpi3, the > > > > > > ports > > > > > > collection is mounted over NFS from another machine. When > > > > > > it's trying > > > > > > to build pkg i'm getting the error message in syslog: > > > > > > > > > > > > rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file > > > > > > modification > > > > > > > > > > > > The report to pkg@: > > > > > > https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/ > > > > > > 002048.html  > > > > > > > > > > > > > > > > > > In ports-mgmt/pkg's config.log It fails at the following > > > > > > entry: > > > > > > configure:3726: checking whether we are cross compiling > > > > > > configure:3734: cc -o conftest -O2 -pipe  -Wno-error > > > > > > -fno-strict-aliasing   conftest.c  >&5 > > > > > > configure:3738: $? = 0 > > > > > > configure:3745: ./conftest > > > > > > configure:3749: $? = 137 > > > > > > configure:3756: error: in  > > > > > > `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': > > > > > > configure:3760: error: cannot run C compiled programs. > > > > > > If you meant to cross compile, use `--host'. > > > > > > See `config.log' for more details > > > > > > > > > > > > # uname -a > > > > > > FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: > > > > > > Thu Mar 9 > > > > > > 08:58:46 CET 2017 > > > > > > aegir@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64. > > > > > > aarch64/tank/rpi3/src/sys/AEGIR  > > > > > > > > > > > > arm64 > > > > > So far, a few additions: > > > > > Time is synced between the NFS server and the client. > > > > > it's an open() call which is getting the kill, and it's not > > > > > the file > > > > > what's being opened, but the process executing it. > > > > > Here's a simple code that reproduces it: > > > > > #include > > > > > > > > > > int main() { > > > > > > > > > >    FILE *f = fopen ("/bar", "w"); > > > > > > > > > >    fclose(f); > > > > >    return 0; > > > > > } > > > > > > > > > > Conditions to reproduce it: > > > > >   - The resulting binary must be executed from the nfs mount > > > > >   - The binary must be built after mounting the NFS share. > > > > > > > > > > I haven't tried building it on a different host, I don't have > > > > > access > > > > > to multiple RPis. Also, if I build the binary, umount/remount > > > > > the NFS > > > > > mount point, which has the binary, execute it, then it works. > > > > > > > > > > I've also tried this with the raspbsd.org's image, I could > > > > > reproduce > > > > > it as well. > > > > > > > > > > Another interesting thing is, when I first booted the RPi up, > > > > > the NFS > > > > > server was a 10.2-STABLE, and later got updated to 11-STABLE. > > > > > While it > > > > > was 10.2 I've tried to build some port, and I don't remember > > > > > having > > > > > this issue. > > > > > > > > > > So, could someone please help me figure this out and fix it? > > > > > This > > > > > stuff should work pretty much. > > > > > > > > > So, this error message comes from here: > > > > https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio > > > > .c?revision=314436&view=markup#l1674  > > > > > > > > > > > > It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np- > > > > >n_vattr.na_mtime) > > > > comparision that fails, np should be the NFS node structure, > > > > from the > > > > vnode's v_data, and n_vattr is the attribute cache. As I've > > > > seen these > > > > two are being updated together, so I don't really see by the > > > > code why > > > > they might differ. Could someone please take a look at it, with > > > > more > > > > experience in the NFS code? -czg > > > Can you print out the two mtimes?  I wonder if what's happening > > > is that > > > your server uses different granularity (for example just seconds) > > > than > > > your client, so on the client we generate a timestamp with a non- > > > zero > > > nanoseconds but when the server receives that timestamp it > > > "truncates" > > > it.  During open() we forcefully re-fetch the timestamp (for CTO > > > consistency) and then notice it doesn't match.  For now I would > > > start > > > with comparing the timestamps and maybe the > > > vfs.timestamp_precision > > > sysctls on client and server (if server is a FreeBSD box). > > Here are the time values: > > Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +  > > -3298114786336  &np->n_vattr.na_mtime: -3298114786616 + > > -3298114786608 > > Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: > > text  > > file modification > > Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +  > > -3298114786336  &np->n_vattr.na_mtime: -3298114786616 + > > -3298114786608 > > Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: > > text  > > file modification > > > > Printed this way: > >                          printf("np->n_mtime: %ji + %ji  > > &np->n_vattr.na_mtime: %ji + %ji", > > (intmax_t)(&np->n_mtime.tv_sec), > > (intmax_t)(&np->n_mtime.tv_nsec), > > (intmax_t)(&np->n_vattr.na_mtime.tv_sec), > > (intmax_t)(&np->n_vattr.na_mtime.tv_nsec)); > Sorry, I made a typo there. Here's it now: > Mar  9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000  > &np->n_vattr.na_mtime: 1489089935 + 221438000 > Mar  9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text > file  > modification > Mar  9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000  > &np->n_vattr.na_mtime: 1489089935 + 221438000 > Mar  9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text > file  > modification > > That's a difference of 2115 micro seconds. I think this is a problem that sysctl vfs.timestamp_precision is supposed to help solve.  Unfortunately, that knob doesn't provide very much control; you can truncate timestamps to full seconds, microseconds, or 1/Hz which may be milliseconds on many systems.  You've got a difference of about 2ms, so only the full seconds granularity might help. It's also not clear to me whether that setting would have to be changed on the server, or the client, or both. -- Ian From owner-freebsd-current@freebsd.org Sun Mar 12 18:22:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23EF9D09E78 for ; Sun, 12 Mar 2017 18:22:49 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 E542E1D59 for ; Sun, 12 Mar 2017 18:22:48 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id g138so20863262itb.0 for ; Sun, 12 Mar 2017 11:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dWEDQmSGeXbKGxU+Gfg2DgAASecZiqfSadz7udWunnU=; b=WNi7XXIjflDZmFETCP/OLSgtJt9fxJM/QdvCV3l0y+OBCLSB56WS1S0jPYrtTszcfa Z0ZHCLW2ohZe4jThR8gSUWKpBVZBMEvQwKFelDl/jmp5fDwS2bSEd3jHupzgHuKsQRfG GZDOTheNifJufLTaZQC2XRrutNGHKneadPYvE0vkh54lHUltmWrMi7HGN2qHbt7UuMUF mdbS2XOWiYnHKpMM9GBM6tlR8B5U+jAobiydydih7aIcHswcab4ev5IeAJoyIB5LU9GQ ERsQBpZqamRlEpP9FkXbNuFfZYW/lnkBtu1hmTJljYeHc70xqKKTxY1D9Jzaffr8SAY7 cxWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dWEDQmSGeXbKGxU+Gfg2DgAASecZiqfSadz7udWunnU=; b=tVeG8vtjoyigHKBOoo1lpluvZ2Vvt98IWDX7priK6bHWkAxTAt+yv80lSkKy7v0s5F xvzvGnJPRiwE2Un3RWsiLCKgtx/200ucEqMgYL+4IN/WN6IJ61TibD+rxD285aE92wRj P1pT5vjermuQTI3NUhtJvE0TBLksfkNSb3uFWsq88j1+CICu5Kkv50lw4Qjq60pZrwHv XRPdEWqidlypWC9SYEkiaYU2CEEg8asjPQiSgJhaVX1b980NNZSAaYyVRIcTDlSD7lHV WoFCNiXaj0DWk3YEg/MaRIuoNQcKpXb5J1o/s3kXlbguB7l3lcQqTRS0bpOwzhcAxxId WMSw== X-Gm-Message-State: AFeK/H1IZFlTN7hFpiYzxfuWm/MzbUTf84vlHBc6S1iYBq0yRM3iESbGFnW9NBimFWac9bPhQmp5EMJ5b7lNZw== X-Received: by 10.36.211.67 with SMTP id n64mr4663988itg.13.1489342968289; Sun, 12 Mar 2017 11:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.24 with HTTP; Sun, 12 Mar 2017 11:22:47 -0700 (PDT) From: Subbsd Date: Sun, 12 Mar 2017 21:22:47 +0300 Message-ID: Subject: FreeBSD-current, panic on UEFI boot after recent changes To: freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 18:22:49 -0000 Hi, ( I apologize if this is a duplicate - first I wrote this as reply-all on https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html thread ) After recent changes and fixes ( https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065093.html ) I still had problems on host with increased EFI_STAGING_SIZE value. I have custom FreeBSD distribution which has a sufficiently large mfsroot which is loaded through UEFI mode. To solve the problem, it was suggested to increase this variable and rebuild /sys/boot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944 Also, it has to be increased periodically for some reason: https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779&r2=305778&pathrev=305779 I've try to ask why than threatens to increase this parameter at once large (or make it dependent on RAM): https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html but there are no answer options. At the moment, on r315141 boot via UEFI is fine with default EFI_STAGING_SIZE (64) With EFI_STAGING_SIZE=768 i got panic after recent changes with follow message: failed to allocate staging area:9 failed to allocate stating area Failed to start image provided by ZFS (5) http://pasteboard.co/IvbhU9Ffu.jpg I believe that there mfsroot may be greater than 64MB soon or later. Also there are no problems with loading big mfsroot images when MBR method is used. PS: I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with constant CURRENT svnup/rebuilds for about a year. So I will be glad if you pay attention to this. PPS: How to reproduce: 1) EFI_STAGING_SIZE=768 in /etc/make.conf 2) make -C /sys/boot clean 3) make -C /sys/boot 4) make -C /sys/boot install 5) reboot Thanks! From owner-freebsd-current@freebsd.org Sun Mar 12 19:35:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E187D09C47 for ; Sun, 12 Mar 2017 19:35:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 090AF10F3; Sun, 12 Mar 2017 19:35:27 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id n9ERc8prWC3JIn9EScx0EI; Sun, 12 Mar 2017 13:32:45 -0600 X-Authority-Analysis: v=2.2 cv=XbT59Mx5 c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=JsQqJ9nhXVJts-AkDfQA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=pxhY87DP9d2VeQe4joPk:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 25E5F3B6; Sun, 12 Mar 2017 12:32:43 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2CJWglX044258; Sun, 12 Mar 2017 12:32:42 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703121932.v2CJWglX044258@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric cc: Cy Schubert , Roberto Rodriguez Jr , FreeBSD Current Subject: Re: buildworld error In-Reply-To: Message from Dimitry Andric of "Sun, 12 Mar 2017 11:36:11 +0100." <1C4E6A09-86AD-4DC7-AA65-336A1643E070@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Mar 2017 12:32:42 -0700 X-CMAE-Envelope: MS4wfGoCalMyX1tO+YBOOnhDlzngPru+adQ5s1L9XLzVC7vIfySVTYMnJgcpNnIFcPp46hJWwWE2VIqseT32A5f8BBVUzkTDVvKb4q9TOnaLvWAo+pdho7Gj GmGY/Z+WLrNIeJcxCi2DiUBVVbBjmakHZzT8cea4YHh52RTQVnTS7qfNrmMVHMWjc65jHHM8Z9WOBdIHqBQ7+agl8Kx4O42pp5eVqrJ8cVfqfyvPjAD6Pmy6 a1TvFIzqr3pCzAjBMV3aVg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:35:28 -0000 In message <1C4E6A09-86AD-4DC7-AA65-336A1643E070@FreeBSD.org>, Dimitry Andric w rites: > > > --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii > > On 12 Mar 2017, at 02:46, Cy Schubert wrote: > > > > In message <5CB065B0-5A7D-4A50-A722-8EA579A67188@FreeBSD.org>, Dimitry > > Andric w > > rites: > >> > >> > >> --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 > >> Content-Transfer-Encoding: quoted-printable > >> Content-Type: text/plain; > >> charset=us-ascii > >> > >> On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr = > >> wrote: > >>> =20 > >>> Now... > >>> make buildworld > >> ... > >>> In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: > >>> In file included from = > >> /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: > >>> In file included from > >>> /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: > >>> In file included from /usr/include/c++/v1/algorithm:634: > >>> In file included from /usr/include/c++/v1/memory:604: > >>> /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = > >> file not > >>> found > >>> #include <__undef___deallocate> > >>> ^ > >> > >> Yes, this is because of the bad advice to run "make delete-old" before > >> you had run "make installworld". You had an older version of libc++ in > >> /usr/include/c++, but that still required the __undef___deallocate > >> header, which has now been deleted by "make delete-old". > >> > >> Your best chance is to build and install libc++ first, if possible, by > >> doing: > >> > >> cd /usr/src/lib/libc++ > >> make obj > >> make depend > >> make > >> make install > >> > >> Then retry building world. > > > > If this actually fixes it, it (the build) is wrong. You shouldn't have to > > build and install src in order to build another part of src. > > > > The procedure has always been documented as make installworld first then > > make delete-old. Failing to do so will on rare occasions bite you when > > building a port. > > Yes, but in this case Roberto ran "make delete-old" *before* installing > world, on your advice. That is definitely something that should be > avoided. That's not what I was talking about. I should have worded that better, as in for next time. People should run make delete-old after the previous installworld and prior to the next buildworld. Even so, the contents of the current /usr/include should not affect the current buildworld. In practice this is still the case. r307800 is a good example of this. I wouldn't be surprised there's more of this in src. > > E.g., "make delete-old" should only ever be run with exactly the same > source tree that your current world was installed from. And preferably > right after "make installworld" and updating /etc. Exactly! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun Mar 12 19:48:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90A29D090B2 for ; Sun, 12 Mar 2017 19:48:09 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BECE1AFB; Sun, 12 Mar 2017 19:48:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id n9TJccYSncWiHn9TKcEYP5; Sun, 12 Mar 2017 13:48:07 -0600 X-Authority-Analysis: v=2.2 cv=JLBLi4Cb c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=XM-aD8IcV8WPzPCBFRYA:9 a=CjuIK1q_8ugA:10 a=ljL5Y125r3EA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 59CF63FF; Sun, 12 Mar 2017 12:48:05 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2CJm4kH027926; Sun, 12 Mar 2017 12:48:04 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703121948.v2CJm4kH027926@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Roberto Rodriguez Jr cc: Dimitry Andric , Cy Schubert , FreeBSD Current Subject: Re: buildworld error In-Reply-To: Message from Roberto Rodriguez Jr of "Sun, 12 Mar 2017 13:41:13 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Mar 2017 12:48:04 -0700 X-CMAE-Envelope: MS4wfMJNrpxH+Z2gk852X2QQQ2mHSWksDcVD4UKMK/4MjucsnlhbLr9kQk/I7PSdibzLFLZwwKPMVE5zwY4AL0XsTi7b7KAS7C9hl8z7llnTVzCS9giazk4C BqjEXwKKpJeu7j4wHgnmGck83pjvC/Yttii681r1V8uLyGLIC6xmY7SjxKh09GcAq5/vDbShZh/08ZWcqh86UpdXeTbwbyurdfw3iusBisMpK4I6phfgN+k7 v+uEZY12MJaZPqnylRx4Ag== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:48:09 -0000 In message , Roberto Rodriguez Jr writes: > Hey, > > Even with a fresh checkout of sources ( today 935am EST). Buildworld/kernel > fail 10 seconds into build. Can you post output, please? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Mar 13 01:08:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D967DD07BA3 for ; Mon, 13 Mar 2017 01:08:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A522B1EE5 for ; Mon, 13 Mar 2017 01:08:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id j5so62885001pfb.2 for ; Sun, 12 Mar 2017 18:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=fSgdORkNtQFybhUaLZEmf0U0oriilBL/6I7O2x3UmT4=; b=XlyP7dlPrTSLfbbWkUKsnPD7d6g0GqTtF68y4LHMgwf9F/1uMKHQztanI32aYmrWcR G7z9E9ru6nm76mhpliMtXqcXCi2fu9LsaSo0x78u6fasWCg+tGObGuQkiIyOKYQPYKWX IsJUwqY6OaBp0iea2zAvrR7u6qV/40e2Ut6FYzy5oDQt07NqJJ5GgdNFtg1tHOB86oX0 5we0JFfTn4Dm7tRH9LI9lgr0OSzXPAHUEK+dYGbZ5ZsEYRPQluhLB5Z5O+vPQEcxnAa5 FqloysBgD/IuGKo8LtbSwq45sAP32c/dzHrPk0PQeSl8d1OD5X2U3jWeB7pDkuWTcMxB mPUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=fSgdORkNtQFybhUaLZEmf0U0oriilBL/6I7O2x3UmT4=; b=fVK0lKH2w1c+n9Y/umvf2ROQ/5bBDEo26ONGvqE/u+zkc1B++x43U+jvAw6quG+sFz lcaZ2cnQthZ8OSHLPTfvHjAmLyjU8O5XNwbbiCvgKkr8K5wI9vgt2d/BMIVkfN/k56Wn JoOKe8/jZn/VXu8GDIIUKxTUZE9nVB6yykKtatS0ndQ75ArN6+xKsf9MRnXyN9kwnn+H dFUTOee1Q06o8vKNNrWiTGcIa9GakymbPKkWmHYKJmaxXqeDvyuBeFVN3Ps5vfNGvaAU s+cikPeoNZ7gyVJBz9ioVhHsvRnPzNGgxihs1GY+3FyG5Tv1tuUOR5yPAZvdI+OLYJuh i5+g== X-Gm-Message-State: AMke39kfsoQwMZMWUzb02VKydifRxjCUWXba1C6csXOLKpYXW2PsV9exH2q0om9VPGHb9g== X-Received: by 10.98.220.65 with SMTP id t62mr35566635pfg.0.1489367316289; Sun, 12 Mar 2017 18:08:36 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 129sm30205778pgj.59.2017.03.12.18.08.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Mar 2017 18:08:35 -0700 (PDT) Subject: Re: buildworld error Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_39689A02-EA6D-4AA7-8966-FE838BEFD795"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <12559915-1715-40A4-B628-FFAFCD27ABDA@gmail.com> Date: Sun, 12 Mar 2017 18:08:33 -0700 Cc: FreeBSD Current Message-Id: <50E8A288-41AC-45E7-8F6C-E3A588510C24@gmail.com> References: <12559915-1715-40A4-B628-FFAFCD27ABDA@gmail.com> To: Roberto Rodriguez Jr X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 01:08:36 -0000 --Apple-Mail=_39689A02-EA6D-4AA7-8966-FE838BEFD795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 11, 2017, at 18:24, Ngie Cooper (yaneurabeya) = wrote: Hi Roberto, The sbin/setkey issue should be resolved by r315181. Thank you = for the report! Cheers, -Ngie --Apple-Mail=_39689A02-EA6D-4AA7-8966-FE838BEFD795 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxfESAAoJEPWDqSZpMIYV414QAM8STzbmsXublp3Z+8MHCQ6Y zAkozOOYzxqm8jwIbbRR9b0tOERCfzYb2g7SBc9mHFWXVm4No/QW9O2mSBMP0VSY Ye0tA6lMinI7IcS8Yq29DtZjiS65nRfOTueAv2o1tAxO8uZYUgC0Y2oHE3bzaHa0 wOXZ6goN9ZgzVSb1rc3sJNtSEG603kkPiXLRaG0szWPWbeUEGtD2+7VIlPYwCnTv 9ytMTjg11ZPb96KXaE4/8m1zrFEQW4W9cJMTIbt4dO0sEvDb1d33RoB9/UlD/82D 8z2GW1zzpkSE4WBh+WpFjZtwhubVjXAJkcE6Skt62HsqHz5tDdx7RT0AFYc0KnkZ SfN4rlQZU8iM50ij6pAC/SETIiIWKagv8WIHThIZsy2h9AAjcIdITIcsIgHQyCtn K7MDOC7+GJjbp7qtPtyOSxL+Pfq8g6CS4zQkhOXvGAY91grjS2UMUGbDFHrOgcTQ 1yToqINhaQmWaR+xYD8PypOSFqN+u1akev06gtOPSAsDv6j0zlCgk6v+GyRWtREb 4OuHb1GbM9Xp+k5s3Odug2jd1m3UnFdE9pKpyEqbg+vRnJ3QM4edZ8fGDa2xeHf9 R4Mdn+uBhYCVIWxS4K3H2newrNx/5XXSnQ+J4Q+IC7CoWCui+H3XOrd0GtTSv/0F gACBVEfuvHsoyGvB7KVx =uf0J -----END PGP SIGNATURE----- --Apple-Mail=_39689A02-EA6D-4AA7-8966-FE838BEFD795-- From owner-freebsd-current@freebsd.org Mon Mar 13 02:00:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 716C4D08DAB for ; Mon, 13 Mar 2017 02:00:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 219041D96 for ; Mon, 13 Mar 2017 02:00:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29200 invoked from network); 13 Mar 2017 01:53:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Mar 2017 01:53:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 12 Mar 2017 21:53:28 -0400 (EDT) Received: (qmail 8024 invoked from network); 13 Mar 2017 01:53:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Mar 2017 01:53:27 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 1A347EC8662; Sun, 12 Mar 2017 18:53:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-Id: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> Date: Sun, 12 Mar 2017 18:53:26 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: FreeBSD Ports , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 02:00:15 -0000 Summary: RAM+(peak swap) was about 26 GiBytes. Also: about 118 GiByte /usr/obj/. . ./llvm40/ area. (2 processors, 2 cores each, all in use; WITH_DEBUG=3D used) The peak usage times were when the 4 cores were each busy running ld at the same time. [So far as I know FreeBSD does not report peak swap usage "since boot". So I do not have a cross check on if I missed seeing a higher peak then I report in the details below.] What all this note spans as part of the build: # more /var/db/ports/devel_llvm40/options # This file is auto-generated by 'make config'. # Options for llvm40-4.0.0.r4 _OPTIONS_READ=3Dllvm40-4.0.0.r4 _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB The system clang 4.0 was used to do the build. A port binutils was used (-B${LOCALBASE}/bin/ in CFLAGS, CXXFLAGS, an CPPFLAGS). The kernel was non-debug generally but buildworld buildkernel did not have MALLOC_PRODUCTION=3D . The llvm40 build did have MALLOC_PRODUCTION=3D . # uname -paKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M powerpc = powerpc64 1200023 1200023 Most of what I have access to for FreeBSD does not have a big enough configuration to do a WITH_DEBUG=3D build of llvm40 on a machine with 4 cores, all in use. One type of environment that does is an old PowerMac G5 so-called "Quad Core" that has 16 GiBytes of RAM, 17 GiBytes of swap, and a 480 GiByte SSD (but extra over provisioned so it appears even smaller for the file system+swap). Watching with top the peak swap usage that I saw was 56% of the 17 GiByte --so call it 10 GiBytes or so. So something like 16 GiBytes RAM + 10 GiBytes swap and so something like 26 GiByte total. I used portmaster with -DK. Afterwards the /usr/obj/ sub-area for llvm40 used totaled to a size of: # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 118 /usr/obj/portswork/usr/ports/devel/llvm40 So around 118 GiBytes of disk space. Showing the major space usage contributions: # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/* = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/* . . . 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/bin . . . 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/lib . . . 12 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/tools . . . 26 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/bin . . . 24 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/lib . . . Side notes that are more system specific: The timestamps on the script output file indicate that the build took about 8 hours 24 minutes. The powerpc64 system used was built with the system clang 4.0 compiler and a port-based binutils. This is despite that clang 4.0 produces code that has any thrown C++ exceptions completely non-functional for powerpc64 (program crashes via signals reporting problems). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Mar 13 19:28:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51998D0AA50 for ; Mon, 13 Mar 2017 19:28:54 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5481A06 for ; Mon, 13 Mar 2017 19:28:54 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3ACD7D0AA4F; Mon, 13 Mar 2017 19:28:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A71AD0AA4E for ; Mon, 13 Mar 2017 19:28:54 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F344A1A05 for ; Mon, 13 Mar 2017 19:28:53 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1cnVe8-0001Nd-KC for current@freebsd.org; Mon, 13 Mar 2017 20:28:44 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1cnVe8-00034N-HD for current@freebsd.org; Mon, 13 Mar 2017 20:28:44 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Mon, 13 Mar 2017 19:28:44 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: info.0 dump good Date: Mon, 13 Mar 2017 12:28:44 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:28:54 -0000 Seems to happen when Xorg has a large webpage or a page idle for a time Dump header from device: /dev/gpt/WDswap Architecture: i386 Architecture Version: 2 Dump Length: 285376512 Blocksize: 512 Dumptime: Mon Mar 13 12:12:37 2017 Hostname: [redacted]com Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb 9 17:32:03 PST = 2017 com:/usr/obj/usr/src/sys/[custom kernel] Panic String: page fault Dump Parity: 1127850006 Bounds: 0 Dump Status: good Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone n= ot a comlete novice can find a bug somewhere? Unsure what email attachment = allows a 273MB file, an ftp server upstream ?? No time to use kdbg for a few mon= ths anyway...= From owner-freebsd-current@freebsd.org Mon Mar 13 21:26:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30213D0ABFD for ; Mon, 13 Mar 2017 21:26:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10ED518FC; Mon, 13 Mar 2017 21:26:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9EBFE10A82D; Mon, 13 Mar 2017 17:26:31 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Roberto Rodriguez Jr , "avg@freebsd.org" Subject: Re: SMBus driver Date: Mon, 13 Mar 2017 14:01:42 -0700 Message-ID: <2999456.G2ZksF5gie@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 13 Mar 2017 17:26:31 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:26:33 -0000 On Sunday, March 12, 2017 12:31:53 AM Roberto Rodriguez Jr wrote: > Hi, > > pciconf -lvbe > > none0@pci0:0:20:0: class=0x0c0500 card=0x21f7103c chip=0x780b1022 > rev=0x3a hdr=0x00 > vendor = 'Advanced Micro Devices, Inc. [AMD]' > device = 'FCH SMBus Controller' > class = serial bus > subclass = SMBus > > I have 'device smbus' in KERNCONF. > I would love to know how to correct this. I looked in sys/dev/smbus but > have no idea which file to edit or where to begin understanding why its > none0. I think this device is supported by the intpm(4) driver? -- John Baldwin From owner-freebsd-current@freebsd.org Mon Mar 13 21:26:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C304D0AC0E for ; Mon, 13 Mar 2017 21:26:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA5E18FD; Mon, 13 Mar 2017 21:26:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id EB1DB10A82E; Mon, 13 Mar 2017 17:26:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Ronald Klop , bapt@freebsd.org Subject: Re: pkg output overflows line Date: Mon, 13 Mar 2017 13:55:05 -0700 Message-ID: <3957920.IgeMF8Imh5@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 13 Mar 2017 17:26:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:26:34 -0000 On Saturday, March 11, 2017 10:01:28 AM Ronald Klop wrote: > Hello, > > Since a week or two the output of pkg overflows the lines of my 80 columns > terminal. > Like this: > > [1/3] intellij-2016.3.4.txz : 20% 59 MiB > 1.2MB/s 03:2 > [1/3] intellij-2016.3.4.txz : 21% 60 MiB > 1.2MB/s 03:2 > [1/3] intellij-2016.3.4.txz : 21% 61 MiB > 983.0kB/s 03:2 > [1/3] intellij-2016.3.4.txz : 21% 62 MiB > 1.2MB/s 03:2 > 4 ETA > > If I enlarge the terminal to 86 columns the output is correct again. > This happens in urxvt (my default), rxvt and in xterm. > > Some regression? I've noticed this same "feature" after the upgrade to 1.10. If possible please let it fit in 80 cols again. :) -- John Baldwin From owner-freebsd-current@freebsd.org Mon Mar 13 21:26:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2138ED0AC23 for ; Mon, 13 Mar 2017 21:26:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F33301936 for ; Mon, 13 Mar 2017 21:26:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 3247410A814; Mon, 13 Mar 2017 17:26:30 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, jbtakk@iherebuywisely.com Subject: Re: info.0 dump good Date: Mon, 13 Mar 2017 14:04:23 -0700 Message-ID: <3454489.WI3XFBSArZ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 13 Mar 2017 17:26:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:26:38 -0000 On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote: > Seems to happen when Xorg has a large webpage or a page idle for a time > > Dump header from device: /dev/gpt/WDswap > Architecture: i386 > Architecture Version: 2 > Dump Length: 285376512 > Blocksize: 512 > Dumptime: Mon Mar 13 12:12:37 2017 > Hostname: [redacted]com > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb 9 17:32:03 PST 2017 > com:/usr/obj/usr/src/sys/[custom kernel] > Panic String: page fault > Dump Parity: 1127850006 > Bounds: 0 > Dump Status: good > > Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone not > a comlete novice can find a bug somewhere? Unsure what email attachment allows > a 273MB file, an ftp server upstream ?? No time to use kdbg for a few months anyway... Do you have a core.txt.0 file? If so it should contain a stack trace from kgdb which is the first thing that would be useful to obtain. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Mar 13 21:30:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EE48D0AE90 for ; Mon, 13 Mar 2017 21:30:25 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCBE51D68; Mon, 13 Mar 2017 21:30:24 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x230.google.com with SMTP id m27so36868246iti.0; Mon, 13 Mar 2017 14:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NiuBEelUN1UcYtghyj8vmrlROsAQrVDt+JQq0MwevHE=; b=LXlwUwZ52Eke2ODM7LFbW58eAxQ+/03FHsyka3MdIZcAFX4qksUWokdmsgP2X1yztR PMw/K9q1NpwOe2ZqORh3FkJ6COPCUp4zI7vyDVVcb1MWIaQKaQNP6fwYsNrqt7tfcbWK 0nhB2k809LecAnpvBFnGmUT1yJBvbPxnaJftv1appdlqTwQGFg1rs0AnHTA3ie4+FDfg /Nr7aNRVSZn/dA81X3SC/d2M8L/qNpEpwiSM5cbMtc/1Bi40hBUnLEEgrA9oaHk3FjtB JLvhStBhSVsXtTwEClERTHGGvnS7eUPBkVSlqtyFNMRMYxwq5CD+R2Q8hwND1IrrIt4/ WMDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NiuBEelUN1UcYtghyj8vmrlROsAQrVDt+JQq0MwevHE=; b=EGSp6I5mdV8IuHW8C7PRhdt65bhBM4NPb3x8OsWQKruoSRVZ8375IXAwAP/btgMSt6 gC3fwa43edDQrcGWsbsI53g/E50EQcz7nPT4aFSxGJZTwWYuRKSn8FSZRuFJh78IXzwP zTlpeaAxvSFPTiiZpHkz8R11RhSWck8gAsJxYZev9daZ0JmS1avB9wwL59O1cNOep5a0 +YgwJ2UKBcvEbA9b3W6F5cJOP/nnzNvzCZPbgPOuJKo92d37iScdVnQb+G8LxsxshMkZ 7uTtS+Leigt8Xd7gYjmdYb4Lyaaf9QmEKpa/sDQeQTdgaWjAhfIwVJkmAWL+xs1NEq8/ ubYQ== X-Gm-Message-State: AFeK/H1oyrgAheM2C7vSPfTv8lQ3rspsCVNngND4uQ1HIjHwRFLm8K4cVklvK15Nw49wc465BySyo98vUlT2tQ== X-Received: by 10.36.124.16 with SMTP id a16mr13365265itd.90.1489440623896; Mon, 13 Mar 2017 14:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Mon, 13 Mar 2017 14:30:23 -0700 (PDT) Received: by 10.64.226.228 with HTTP; Mon, 13 Mar 2017 14:30:23 -0700 (PDT) In-Reply-To: <2999456.G2ZksF5gie@ralph.baldwin.cx> References: <2999456.G2ZksF5gie@ralph.baldwin.cx> From: Roberto Rodriguez Jr Date: Mon, 13 Mar 2017 21:30:23 +0000 Message-ID: Subject: Re: SMBus driver To: John Baldwin Cc: "avg@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:30:25 -0000 Ahoy, Oh excellent! Will try new device soon and report. Thank you very much -R From owner-freebsd-current@freebsd.org Tue Mar 14 00:45:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C055D0975E for ; Tue, 14 Mar 2017 00:45:43 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 F1F501A6D; Tue, 14 Mar 2017 00:45:42 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id m27so38908289iti.0; Mon, 13 Mar 2017 17:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1k59FeEazjz+5Q3WIPzy+t25hEddP4xaGWrxjhdBxYU=; b=Uu6SACn7XWVH0AiSo+lizjIINsYke+4/WwyU84J+PRFcnHD18BWoLfnRdSgJFP40hS GT2hPZXt1IfVbXr+pqe8d/eOGlAiHjYislsJRofvEuZ4Z1FprM3yoIL3KIBZOtheWZVd qxkUsxD3HsjOz32bBxHr7UW3OwLUg95K1xfAzf5Js3vbs5ukFtois3PQiN/40qOd72Wf 5E/iKfNMVAkek0PqxX3i8bn/yzf9HKUZzHh1C1Wkr/EZwqwSpMwI46PM7lYXgg2X0wVt dVxNdut5kZyhNd/N53IEaG3JdMaEPEQot1r9ErVUkAcvdMfjPZRNf3hF4oHIcG2BbWe+ 3FPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1k59FeEazjz+5Q3WIPzy+t25hEddP4xaGWrxjhdBxYU=; b=NQZ0nMjx9LljZlmhrcuZYukQrND4AQzTK6691UkFymZOuKiyRnBpyV0YoD3ctMKiPq rjJlaB9GOnJ6Eolhd/8Mb9O2K15T3uwiAHmXC4K7cfDkZq4as/wnLzt8oO5ModCYjQYt yOYXEivcuFzz1Tw1f39VaZ6yy/32wZeDsGYeHnR/P1EqFCjkmPQ8YKovyzsbGh9OTfta lOKGnq/f1NqE0isqyfq8ffRErwsERG6YVIWdwuvtUnM9GHkY5sdVoyvlNsYOR2y3xIKG uj7yPf/hJiN7A6lSnFUuzSO72EmHSMM/UMxZBQ5lvhfJEFpQIlLm2Sp/CZ5QBwpLT8RT /ZjQ== X-Gm-Message-State: AFeK/H1hERv6GLJGzSyYjtAhlzvw79aQToV78qWBMX43JRYEhTYyyhpR9CxpJsApwb52khIynjwsfau9VyFSxw== X-Received: by 10.36.22.209 with SMTP id a200mr12739454ita.117.1489452342145; Mon, 13 Mar 2017 17:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Mon, 13 Mar 2017 17:45:41 -0700 (PDT) Received: by 10.64.226.228 with HTTP; Mon, 13 Mar 2017 17:45:41 -0700 (PDT) In-Reply-To: References: <2999456.G2ZksF5gie@ralph.baldwin.cx> From: Roberto Rodriguez Jr Date: Tue, 14 Mar 2017 00:45:41 +0000 Message-ID: Subject: Re: SMBus driver To: John Baldwin Cc: FreeBSD Current , avg@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 00:45:43 -0000 Hey, Compiled kernel and it registered the device. Thank you for the support! -R From owner-freebsd-current@freebsd.org Tue Mar 14 06:37:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74811D0B82E for ; Tue, 14 Mar 2017 06:37:13 +0000 (UTC) (envelope-from mulichao@outlook.com) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255014.outbound.protection.outlook.com [40.92.255.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3BE9123F for ; Tue, 14 Mar 2017 06:37:12 +0000 (UTC) (envelope-from mulichao@outlook.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jpMYe9Ay5il57sN/ieObWyIKvvb7s3TiD8mYf5oFxeU=; b=ppNrI4V3fUcaIniWo+9qaSIR7luw0TSNLXwSUq8kXW51KQQBJZu7nDPWAVDXnOLusUOT69xw9gU2Snif9jwoSzRZQsXwWX5Pw7gQvDb2FyQX2jj2zRwIv956/mlI+vhPoYh2Eop9IPmzVrGRlY6VXl5UOs9KoHHlSqDeHE7i6thrKsw2w2AEM37Mmw7Auo+1kpcS/7M6AzYnOF0FN73jvryLEMyjekFYdNgwy3FquULz2QUvlLeoS2iAZScpXlsDlR2+OYEJ2YmIfiuuH9w83gyYGEeUl/0P6dyprb+A2EvMluK57iw/CfjdXew0+Vlm5Ajnt9s9JWukjP5Lv3MR3w== Received: from SG2APC01FT006.eop-APC01.prod.protection.outlook.com (10.152.250.57) by SG2APC01HT127.eop-APC01.prod.protection.outlook.com (10.152.251.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7; Tue, 14 Mar 2017 06:37:09 +0000 Received: from HK2PR02MB0772.apcprd02.prod.outlook.com (10.152.250.51) by SG2APC01FT006.mail.protection.outlook.com (10.152.250.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7 via Frontend Transport; Tue, 14 Mar 2017 06:37:09 +0000 Received: from HK2PR02MB0772.apcprd02.prod.outlook.com ([fe80::6523:244a:cb1b:f3bf]) by HK2PR02MB0772.apcprd02.prod.outlook.com ([fe80::6523:244a:cb1b:f3bf%14]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 06:37:09 +0000 From: Mu Lichao To: "freebsd-current@freebsd.org" Subject: PCI slot and function number for ARI enabled devices Thread-Topic: PCI slot and function number for ARI enabled devices Thread-Index: AQHSnIqKQ1B4saqSW0mDi1v/MWkR0w== Date: Tue, 14 Mar 2017 06:37:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:162ACAD900499B9DA46E63D97BB5A6ACE8E67D92B8E000ADEDE7ADB85F1258C8; UpperCasedChecksum:D2A85C031E80C8ACBDF93067CCB08E2B2A43281F7EB75905BCDCB0441EA6E2AB; SizeAsReceived:7642; Count:36 x-tmn: [dOLkfSLfV8e3HfBBpBtE4htk9P05o0vUZckXSt+4GAM=] x-incomingheadercount: 36 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SG2APC01HT127; 5:xaGCC0xWRgV7xZ3lpuXMz9sbwHCwh+Jx4yxpZ/Vpq623TpSPu+m0x4Mfq8lG9+phkZPiZ93w3REY64DS7IPrzPewk0wX7u9w+t+Q5AQdpQbkLtxBafYTK+Wo52FVShmaNAIpKjWcCKZzUnqP6caxpA==; 24:mMbhgwwr8B/pxv+6a+7/+dwr8XvoDm6SskpOLWROjCntUfCcAYiHorC1scGNjteQVtOmUaoKZuhzgQPkxWBSsysfEJsAQVdhAPXMN/uYLjE=; 7:Hs36NvsSEuWA+RLA42+lsFb160x0qN+RU/O5ZwNyxzFOH1rqYB7udr5kbSw88dkNMvniFlofk1xazBddqqltYUlL3QpcX/vxwXtj5qRRYem0sZbZKa/AVoaZvkfNWlzduMinLb85tbZKUb0fusLQp2YEmW9W7LN1YdQgUTbfnBJPBbCZP4ot/USQG2QKwQn7YljwVHyR8STZ6e0wwv9DtzQQq9K1KixTG38wLOCjkS0qFmaUst7nLwUc4RBtJERDepfihV/AO5ZTeJtWfjrk5JoRMMudIGApcOOyUEs7I68rBoOhg1Lp/Af40Q+bb8RM x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT127; H:HK2PR02MB0772.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 492e0abf-b604-4716-7b91-08d46aa48a30 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045); SRVR:SG2APC01HT127; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT127; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT127; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 06:37:09.0602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT127 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 06:37:13 -0000 Hi, I am trying to enable Intel 82599 10GbE SR-IOV VFs on FreeBSD 12-CURRENT, a= nd after enabled, the SR-IOV VFs can be seen by pciconf(1), but can not be = seen by lspci(1), which is installed from ports/sysutils/pciutils: # pciconf -l | tail -2 ixv0@pci0:1:0:128: class=3D0x020000 card=3D0x002a1fc1 chip=3D0x10ed808= 6 rev=3D0x01 hdr=3D0x00 ixv1@pci0:1:0:130: class=3D0x020000 card=3D0x002a1fc1 chip=3D0x10ed808= 6 rev=3D0x01 hdr=3D0x00 # lspci | grep 82599 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ = Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ = Network Connection (rev 01) After some debugging, I found that it is because of ARI. After ARI is enabl= ed, the slot number is always 0 and the function number can be range betwee= n 0 and 255 when reading from /dev/pci, and this breaks lspci(1). Is it a behavior by design or not? Regards, Lichao Mu From owner-freebsd-current@freebsd.org Tue Mar 14 07:02:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C1B9D0B363 for ; Tue, 14 Mar 2017 07:02:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 5DA7E185C for ; Tue, 14 Mar 2017 07:02:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30511 invoked from network); 14 Mar 2017 07:02:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 07:02:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 03:02:34 -0400 (EDT) Received: (qmail 31434 invoked from network); 14 Mar 2017 07:02:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 07:02:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B63C0EC892D; Tue, 14 Mar 2017 00:02:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) From: Mark Millard In-Reply-To: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> Date: Tue, 14 Mar 2017 00:02:33 -0700 Cc: Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:02:36 -0000 On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). >=20 > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. >=20 > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); > // test_check(); // Adding this line prevents failure. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } >=20 >=20 > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails = (both parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Mar 14 07:19:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20253D0BAEF for ; Tue, 14 Mar 2017 07:19:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 D5C63159C for ; Tue, 14 Mar 2017 07:19:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22710 invoked from network); 14 Mar 2017 06:52:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 06:52:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 02:52:43 -0400 (EDT) Received: (qmail 18463 invoked from network); 14 Mar 2017 06:52:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 06:52:43 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 80BBBEC8662; Mon, 13 Mar 2017 23:52:42 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) Message-Id: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> Date: Mon, 13 Mar 2017 23:52:41 -0700 Cc: Andrew Turner To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:19:25 -0000 I'm still at a loss about how to figure out what stages are messed up. (Memory coherency? Some memory not swapped out? Bad data swapped out? Wrong data swapped in?) But at least I've found a much smaller/simpler example to demonstrate some problem with in my Pine64+_ 2GB context. The Pine64+ 2GB is the only amd64 context that I have access to. The following program fails its check for data having its expected byte pattern in dynamically allocated memory after a fork/swap-out/swap-in sequence. I'll note that the program sleeps for 60s after forking to give time to do something else to cause the parent and child processes to swap out (RES=3D0 as seen in top). Note the source code line: // test_check(); // Adding this line prevents failure. It seem that accessing the region contents before forking and swapping avoids the problem. But there is a problem if the region was only written-to before the fork/swap. Another point is the size of the region matters: <=3D 14K Bytes fails and > 14K Bytes works for as much has I have tested. # more swap_testing.c // swap_testing.c // Built via (c++ was clang++ 4.0 in my case): // // cc -g -std=3Dc11 -Wpedantic swap_testing.c // -O0 and -O2 also gets the problem. #include // for fork(), sleep(.) #include // for pid_t #include // for wait(.) extern void test_setup(void); // Sets up the memory byte pattern. extern void test_check(void); // Tests the memory byte pattern. int main(void) { test_setup(); // test_check(); // Adding this line prevents failure. pid_t pid =3D fork(); int wait_status =3D 0;; if (0 // for bool, true, false #include // for size_t, NULL #include // for malloc(.), free(.) #include // for raise(.), SIGABRT #define region_size (14u*1024u) // Bad dyn_region pattern, parent and child // processes: // 256u, 4u*1024u, 8u*1024u, 9u*1024u, // 12u*1024u, 14u*1024u // Works: // 14u*1024u+1u, 15u*1024u, 16u*1024u, // 32u*1024u, 256u*1024u*1024u typedef volatile unsigned char value_type; struct region_struct { value_type array[region_size]; }; typedef struct region_struct region; static region gbl_region; static region * volatile dyn_region =3D NULL; static value_type value(size_t v) { return (value_type)v; } void test_setup(void) { dyn_region =3D malloc(sizeof(region)); if (!dyn_region) raise(SIGABRT); for(size_t i=3D0u; i 103 if (dyn_failed) raise(SIGABRT); // lldb reports this line = for the __raise call. 104 // when it fails (both = parent and child processes). 105 } (lldb) print dyn_pos (size_t) $0 =3D 2 (That is one after the failure position.) (lldb) print dyn_region (region *volatile) $3 =3D 0x0000000040616000 (lldb) print *dyn_region (region) $1 =3D { array =3D { [0] =3D '\0' [1] =3D '\0' [2] =3D '\0' . . . (all '\0' bytes) . . . [251] =3D '\0' [252] =3D '\0' [253] =3D '\0' [254] =3D '\0' [255] =3D '\0' ... } } (lldb) print gbl_region (region) $2 =3D { array =3D { [0] =3D '\0' [1] =3D '\x01' [2] =3D '\x02' . . . [251] =3D '\xfb' [252] =3D '\xfc' [253] =3D '\xfd' [254] =3D '\xfe' [255] =3D '\xff' ... } } (lldb) disass -n main a.out`main: 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 0x20230 <+4>: stp x29, x30, [sp, #0x20] 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 0x20238 <+12>: stur wzr, [x29, #-0x4] 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork 0x20244 <+24>: mov w8, wzr 0x20248 <+28>: stur w0, [x29, #-0x8] 0x2024c <+32>: stur wzr, [x29, #-0xc] 0x20250 <+36>: ldur w0, [x29, #-0x8] 0x20254 <+40>: cmp w8, w0 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait 0x20264 <+56>: str w0, [sp, #0x10] 0x20268 <+60>: mov w8, #-0x1 0x2026c <+64>: ldur w9, [x29, #-0xc] 0x20270 <+68>: cmp w8, w9 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 0x20278 <+76>: mov w8, wzr 0x2027c <+80>: ldur w9, [x29, #-0x8] 0x20280 <+84>: cmp w8, w9 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 0x20288 <+92>: ldur w8, [x29, #-0x8] 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 0x20290 <+100>: orr w0, wzr, #0x3c 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep 0x20298 <+108>: str w0, [sp, #0xc] 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 0x202a0 <+116>: ldur w0, [x29, #-0x4] 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 0x202ac <+128>: ret =20 (lldb) disass -n value a.out`value: 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 0x204d0 <+4>: str x0, [sp, #0x8] 0x204d4 <+8>: ldrb w8, [sp, #0x8] 0x204d8 <+12>: mov w1, w8 0x204dc <+16>: mov w0, w8 0x204e0 <+20>: str w1, [sp, #0x4] 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 0x204e8 <+28>: ret =20 (lldb) disass -n test_setup a.out`test_setup: 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 0x202b4 <+4>: stp x29, x30, [sp, #0x10] 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 0x202bc <+12>: orr x0, xzr, #0x3800 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc 0x202c4 <+20>: adrp x30, 48 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 0x202cc <+28>: str x0, [x30] 0x202d0 <+32>: ldr x0, [x30] 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 0x202d8 <+40>: orr w0, wzr, #0x6 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise 0x202e0 <+48>: str w0, [sp, #0x4] 0x202e4 <+52>: str xzr, [sp, #0x8] 0x202e8 <+56>: orr x8, xzr, #0x3800 0x202ec <+60>: ldr x9, [sp, #0x8] 0x202f0 <+64>: cmp x9, x8 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 0x202f8 <+72>: ldr x0, [sp, #0x8] 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 0x20300 <+80>: adrp x30, 48 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 0x20308 <+88>: adrp x8, 48 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 0x20310 <+96>: ldr x9, [sp, #0x8] 0x20314 <+100>: add x8, x8, x9 0x20318 <+104>: strb w0, [x8] 0x2031c <+108>: ldr x8, [x30] 0x20320 <+112>: ldr x9, [sp, #0x8] 0x20324 <+116>: add x8, x8, x9 0x20328 <+120>: strb w0, [x8] 0x2032c <+124>: ldr x8, [sp, #0x8] 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 0x20334 <+132>: str x8, [sp, #0x8] 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c 0x2033c <+140>: ldp x29, x30, [sp, #0x10] 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 0x20344 <+148>: ret =20 (lldb) disass -n test_check a.out`test_check: 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 0x2034c <+4>: stp x29, x30, [sp, #0x10] 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c 0x20358 <+16>: mov w8, wzr 0x2035c <+20>: adrp x9, 51 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 0x20364 <+28>: ldrb w10, [x9] 0x20368 <+32>: stur w8, [x29, #-0x4] 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c 0x20370 <+40>: orr x8, xzr, #0x3800 0x20374 <+44>: adrp x9, 51 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 0x2037c <+52>: ldr x9, [x9] 0x20380 <+56>: cmp x9, x8 0x20384 <+60>: cset w10, lo 0x20388 <+64>: stur w10, [x29, #-0x4] 0x2038c <+68>: ldur w8, [x29, #-0x4] 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 0x20394 <+76>: adrp x8, 51 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 0x2039c <+84>: ldr x0, [x8] 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 0x203a4 <+92>: adrp x8, 51 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 0x203ac <+100>: adrp x30, 51 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 0x203b4 <+108>: adrp x9, 48 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 0x203bc <+116>: uxtb w0, w0 0x203c0 <+120>: ldr x10, [x8] 0x203c4 <+124>: add x9, x9, x10 0x203c8 <+128>: ldrb w11, [x9] 0x203cc <+132>: cmp w0, w11 0x203d0 <+136>: cset w11, ne 0x203d4 <+140>: and w11, w11, #0x1 0x203d8 <+144>: strb w11, [x30] 0x203dc <+148>: ldr x9, [x8] 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 0x203e4 <+156>: str x9, [x8] 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c 0x203f0 <+168>: mov w8, wzr 0x203f4 <+172>: adrp x9, 51 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 0x203fc <+180>: ldrb w10, [x9] 0x20400 <+184>: str w8, [sp, #0x8] 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c 0x20408 <+192>: orr x8, xzr, #0x3800 0x2040c <+196>: adrp x9, 51 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 0x20414 <+204>: ldr x9, [x9] 0x20418 <+208>: cmp x9, x8 0x2041c <+212>: cset w10, lo 0x20420 <+216>: str w10, [sp, #0x8] 0x20424 <+220>: ldr w8, [sp, #0x8] 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c 0x2042c <+228>: adrp x8, 51 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 0x20434 <+236>: ldr x0, [x8] 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 0x2043c <+244>: adrp x8, 51 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 0x20444 <+252>: adrp x30, 51 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 0x2044c <+260>: adrp x9, 48 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 0x20454 <+268>: uxtb w0, w0 0x20458 <+272>: ldr x9, [x9] 0x2045c <+276>: ldr x10, [x8] 0x20460 <+280>: add x9, x9, x10 0x20464 <+284>: ldrb w11, [x9] 0x20468 <+288>: cmp w0, w11 0x2046c <+292>: cset w11, ne 0x20470 <+296>: and w11, w11, #0x1 0x20474 <+300>: strb w11, [x30] 0x20478 <+304>: ldr x9, [x8] 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 0x20480 <+312>: str x9, [x8] 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c 0x20488 <+320>: adrp x8, 51 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 0x20490 <+328>: ldrb w9, [x8] 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c 0x20498 <+336>: orr w0, wzr, #0x6 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise 0x204a0 <+344>: str w0, [sp, #0x4] 0x204a4 <+348>: adrp x8, 51 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 0x204ac <+356>: ldrb w9, [x8] 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 0x204b4 <+364>: orr w0, wzr, #0x6 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise -> 0x204bc <+372>: str w0, [sp] 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 0x204c8 <+384>: ret =20 # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a non-debug kernel. (Previous to these experiments my other corruption = examples were not caught by a debug kernel. I'm not hopeful that this simpler = context would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Mar 14 07:58:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3DFFD0B84F for ; Tue, 14 Mar 2017 07:58:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 68FD81972 for ; Tue, 14 Mar 2017 07:58:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7469 invoked from network); 14 Mar 2017 08:00:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 08:00:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 03:58:17 -0400 (EDT) Received: (qmail 2793 invoked from network); 14 Mar 2017 07:58:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 07:58:17 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 72316EC8123; Tue, 14 Mar 2017 00:58:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) From: Mark Millard In-Reply-To: Date: Tue, 14 Mar 2017 00:58:15 -0700 Cc: Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:58:19 -0000 [Another correction I'm afraid --about alternative program variations this time.] On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). The following about the extra test_check() was wrong. > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. This was because I'd carelessly moved some loop variables to globals in a way that depended on the initialization of the globals and the extra call changed those values. I've noted code adjustments below (3 lines). I get the failures with them as well. > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); test_check(); // This test passes. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { gbl_pos =3D 0u; > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 dyn_pos =3D 0u; > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } I'm not bothering to redo the details below for the line number variations. > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails (both = parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Mar 14 13:31:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48567D0BC7C for ; Tue, 14 Mar 2017 13:31:05 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 333D51DB4 for ; Tue, 14 Mar 2017 13:31:05 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5B90B56575; Tue, 14 Mar 2017 08:31:04 -0500 (CDT) Subject: Re: PCI slot and function number for ARI enabled devices To: Mu Lichao , "freebsd-current@freebsd.org" References: From: Eric van Gyzen Message-ID: Date: Tue, 14 Mar 2017 08:30:56 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 13:31:05 -0000 On 03/14/2017 01:37, Mu Lichao wrote: > Hi, > > I am trying to enable Intel 82599 10GbE SR-IOV VFs on FreeBSD 12-CURRENT, and after enabled, the SR-IOV VFs can be seen by pciconf(1), but can not be seen by lspci(1), which is installed from ports/sysutils/pciutils: > # pciconf -l | tail -2 > ixv0@pci0:1:0:128: class=0x020000 card=0x002a1fc1 chip=0x10ed8086 rev=0x01 hdr=0x00 > ixv1@pci0:1:0:130: class=0x020000 card=0x002a1fc1 chip=0x10ed8086 rev=0x01 hdr=0x00 > > # lspci | grep 82599 > 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) > 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) > > After some debugging, I found that it is because of ARI. After ARI is enabled, the slot number is always 0 and the function number can be range between 0 and 255 when reading from /dev/pci, and this breaks lspci(1). > > Is it a behavior by design or not? It is by design. See section 6.13 of the PCIe specification. I imagine lspci will need to be fixed. Eric From owner-freebsd-current@freebsd.org Tue Mar 14 18:07:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9B18D0C190 for ; Tue, 14 Mar 2017 18:07:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 711051A9 for ; Tue, 14 Mar 2017 18:07:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31136 invoked from network); 14 Mar 2017 18:07:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 18:07:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 14:07:20 -0400 (EDT) Received: (qmail 742 invoked from network); 14 Mar 2017 18:07:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 18:07:20 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AEAB4EC8534; Tue, 14 Mar 2017 11:07:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> Date: Tue, 14 Mar 2017 11:07:19 -0700 Cc: Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:07:23 -0000 [This is just a correction to the subject-line text to say arm64 instead of amd64.] On 2017-Mar-14, at 12:58 AM, Mark Millard wrote: [Another correction I'm afraid --about alternative program variations this time.] On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). The following about the extra test_check() was wrong. > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. This was because I'd carelessly moved some loop variables to globals in a way that depended on the initialization of the globals and the extra call changed those values. I've noted code adjustments below (3 lines). I get the failures with them as well. > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); test_check(); // This test passes. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { gbl_pos =3D 0u; > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 dyn_pos =3D 0u; > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } I'm not bothering to redo the details below for the line number variations. > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails (both = parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 14 22:28:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88A80D0D7E8 for ; Tue, 14 Mar 2017 22:28:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-173.reflexion.net [208.70.211.173]) (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 49C4115E5 for ; Tue, 14 Mar 2017 22:28:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8732 invoked from network); 14 Mar 2017 22:31:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 22:31:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 18:28:55 -0400 (EDT) Received: (qmail 26886 invoked from network); 14 Mar 2017 22:28:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 22:28:55 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4CAC6EC8159; Tue, 14 Mar 2017 15:28:54 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Date: Tue, 14 Mar 2017 15:28:53 -0700 References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> To: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List In-Reply-To: <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:28:57 -0000 [test_check() between the fork and the wait/sleep prevents the failure from occurring. Even a small access to the memory at that stage prevents the failure. Details follow.] On 2017-Mar-14, at 11:07 AM, Mark Millard wrote: > [This is just a correction to the subject-line text to say arm64 > instead of amd64.] >=20 > On 2017-Mar-14, at 12:58 AM, Mark Millard wrote: >=20 > [Another correction I'm afraid --about alternative program variations > this time.] >=20 > On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: >=20 >> I'm still at a loss about how to figure out what stages are messed >> up. (Memory coherency? Some memory not swapped out? Bad data swapped >> out? Wrong data swapped in?) >>=20 >> But at least I've found a much smaller/simpler example to demonstrate >> some problem with in my Pine64+_ 2GB context. >>=20 >> The Pine64+ 2GB is the only amd64 context that I have access to. >=20 > Someday I'll learn to type arm64 the first time instead of amd64. >=20 >> The following program fails its check for data >> having its expected byte pattern in dynamically >> allocated memory after a fork/swap-out/swap-in >> sequence. >>=20 >> I'll note that the program sleeps for 60s after >> forking to give time to do something else to >> cause the parent and child processes to swap >> out (RES=3D0 as seen in top). >=20 > The following about the extra test_check() was > wrong. >=20 >> Note the source code line: >>=20 >> // test_check(); // Adding this line prevents failure. >>=20 >> It seem that accessing the region contents before forking >> and swapping avoids the problem. But there is a problem >> if the region was only written-to before the fork/swap. There is a place that if a test_check call is put then the problem does not happen at any stage: I tried putting a call between the fork and the later wait/sleep code: int main(void) { test_setup(); test_check(); // Before fork() [passes] pid_t pid =3D fork(); int wait_status =3D 0;; // test_check(); // After fork(); before wait/sleep.=20 // If used it prevents failure later! if (0 Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BCF7D0DBC7; Tue, 14 Mar 2017 23:47:20 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5DC81CE9; Tue, 14 Mar 2017 23:47:19 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v2ENihnU040775 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 00:44:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id v2ENifKN051896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2017 00:44:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id v2ENiecG025847; Wed, 15 Mar 2017 00:44:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v2ENicbl025846; Wed, 15 Mar 2017 00:44:38 +0100 (CET) (envelope-from ticso) Date: Wed, 15 Mar 2017 00:44:38 +0100 From: Bernd Walter To: Mark Millard Cc: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Message-ID: <20170314234437.GA25820@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:47:20 -0000 On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > [test_check() between the fork and the wait/sleep prevents the > failure from occurring. Even a small access to the memory at > that stage prevents the failure. Details follow.] Maybe a stupid question, since you might have written it somewhere. What medium do you swap to? I've seen broken firmware on microSD cards doing silent data corruption for some access patterns. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@freebsd.org Wed Mar 15 01:19:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B608D0A1D0 for ; Wed, 15 Mar 2017 01:19:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 CED29117C for ; Wed, 15 Mar 2017 01:18:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31086 invoked from network); 15 Mar 2017 01:19:47 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 01:19:47 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 21:18:58 -0400 (EDT) Received: (qmail 13043 invoked from network); 15 Mar 2017 01:18:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 01:18:58 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 40CE3EC7652; Tue, 14 Mar 2017 18:18:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <20170314234437.GA25820@cicely7.cicely.de> Date: Tue, 14 Mar 2017 18:18:56 -0700 Cc: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <830B8C57-C9B0-4902-94D2-A8E7F1CB9ADB@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <20170314234437.GA25820@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:19:00 -0000 On 2017-Mar-14, at 4:44 PM, Bernd Walter wrote: > On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >> [test_check() between the fork and the wait/sleep prevents the >> failure from occurring. Even a small access to the memory at >> that stage prevents the failure. Details follow.] > > Maybe a stupid question, since you might have written it somewhere. > What medium do you swap to? > I've seen broken firmware on microSD cards doing silent data > corruption for some access patterns. The root filesystem is on a USB SSD on a powered hub. Only the kernel is from the microSD card. I have several examples of the USB SSD model and have never observed such problems in any other context. The original issue that started this investigation has been reported by several people on the lists: Failed assertion: "tsd_booted" on arm64 specifically, no other contexts so far as I know. Earlier I had discovered that: A) I could use a swap-in to cause the messages from instances of sh or su that had swapped out earlier. B) The core dumps showed that a large memory region containing the global tsd_booted had all turned to be zero bytes. The assert is just exposing one of those zeros. (tsd_booted is from jemalloc that is in a .so that is loaded.) This prompted me to look for simpler contexts involving swapping that also show memory corruption. So far I've only managed to produce corrupted memory when fork and later swapping are both involved. Being a shared library global is not a requirement for the problem, although such contexts can have an issue. I've not made a simpler example of that yet, although I tried. I have not explored vfork, rfork, or any other alternatives. So far all failure examples end up with zeroed memory when the memory does not match the original pattern from before the fork. At least that is what the core dumps show for all examples that I've looked at. See bugzilla 217138 and 217239. In some respects this example is more analogous to the 217239 context as I remember. My tests on amd64, armv6 (really -mcpu=cortex-a7 so armv7), and powerpc64 have never produced any problems, including never getting the failed assertion. Only arm64. (But I've access to only one arm64 system, a Pine64+ 2GB.) Prior to this I tracked down a different arm64 problem to the fork_trampline code (for the child process) modifying a system register but in a place allowing interrupts that could also change the value. Andrew Turner fixed that one at the time. For this fork/swapping kind of issue I'm not sure that I'll be able to do more than provide the simpler example and the steps that I used. My isolating the internal stage(s) and specific problem(s) at the code level of detail does not seem likely. But whatever is found needs to be able to explain the contrast with an access after the fork but before the swap preventing the failing behavior. So what I've got so far hopefully does provide some hints to someone. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Mar 15 04:33:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A2EFD0D889 for ; Wed, 15 Mar 2017 04:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 C98551D4D for ; Wed, 15 Mar 2017 04:33:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25777 invoked from network); 15 Mar 2017 04:33:09 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 04:33:09 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 15 Mar 2017 00:33:09 -0400 (EDT) Received: (qmail 1852 invoked from network); 15 Mar 2017 04:33:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 04:33:09 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DDA81EC8534; Tue, 14 Mar 2017 21:33:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: Date: Tue, 14 Mar 2017 21:33:08 -0700 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> To: Andrew Turner , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:33:12 -0000 A single Byte access to a 4K Byte aligned region between the fork and wait/sleep/swap-out prevents that specific 4K Byte region from having the (bad) zeros. Sounds like a page sized unit of behavior to me. Details follow. On 2017-Mar-14, at 3:28 PM, Mark Millard wrote: > [test_check() between the fork and the wait/sleep prevents the > failure from occurring. Even a small access to the memory at > that stage prevents the failure. Details follow.] >=20 > On 2017-Mar-14, at 11:07 AM, Mark Millard wrote: >=20 >> [This is just a correction to the subject-line text to say arm64 >> instead of amd64.] >>=20 >> On 2017-Mar-14, at 12:58 AM, Mark Millard = wrote: >>=20 >> [Another correction I'm afraid --about alternative program variations >> this time.] >>=20 >> On 2017-Mar-13, at 11:52 PM, Mark Millard = wrote: >>=20 >>> I'm still at a loss about how to figure out what stages are messed >>> up. (Memory coherency? Some memory not swapped out? Bad data swapped >>> out? Wrong data swapped in?) >>>=20 >>> But at least I've found a much smaller/simpler example to = demonstrate >>> some problem with in my Pine64+_ 2GB context. >>>=20 >>> The Pine64+ 2GB is the only amd64 context that I have access to. >>=20 >> Someday I'll learn to type arm64 the first time instead of amd64. >>=20 >>> The following program fails its check for data >>> having its expected byte pattern in dynamically >>> allocated memory after a fork/swap-out/swap-in >>> sequence. >>>=20 >>> I'll note that the program sleeps for 60s after >>> forking to give time to do something else to >>> cause the parent and child processes to swap >>> out (RES=3D0 as seen in top). >>=20 >> The following about the extra test_check() was >> wrong. >>=20 >>> Note the source code line: >>>=20 >>> // test_check(); // Adding this line prevents failure. >>>=20 >>> It seem that accessing the region contents before forking >>> and swapping avoids the problem. But there is a problem >>> if the region was only written-to before the fork/swap. >=20 > There is a place that if a test_check call is put then the > problem does not happen at any stage: I tried putting a > call between the fork and the later wait/sleep code: I changed the byte sequence patterns to avoid zero values since the bad values are zeros: static value_type value(size_t v) { return (value_type)((v&0xFEu)|0x1u); = } // value now avoids the zero value since the failures // are zeros. With that I can then test accurately what bytes have bad values vs. do not. I also changed to: void partial_test_check(void) { if (value(0u)!=3Dgbl_region.array[0]) raise(SIGABRT); if (value(0u)!=3D(*dyn_region).array[0]) raise(SIGABRT); } since previously [0] had a zero value and so I'd used [1]. On this basis I'm now using the below. See the comments tied to partial_test_check() calls: extern void test_setup(void); // Sets up the memory byte = patterns. extern void test_check(void); // Tests the memory byte patterns. extern void partial_test_check(void); // Tests just [0] of each region // (gbl_region and dyn_region). int main(void) { test_setup(); test_check(); // Before fork() [passes] pid_t pid =3D fork(); int wait_status =3D 0;; // After fork; before waitsleep/swap-out. if (0=3D=3Dpid) partial_test_check(); // Even the above is sufficient by // itself to prevent failure for // region_size 1u through // 4u*1024u! // But 4u*1024u+1u and above fail // with this access to memory. // The failing test is of // (*dyn_region).array[4096u]. // This test never fails here. if (0 This suggests to me that the small access is forcing one or more = things to > be initialized for memory access that fork is not establishing of = itself. > It appears that if established correctly then the swap-out/swap-in > sequence would work okay without needing the manual access to the = memory. >=20 >=20 > So far via this test I've not seen any evidence of problems with the = global > region but only the dynamically allocated region. >=20 > However, the symptoms that started this investigation in a much more > complicated context had an area of global memory from a .so that ended > up being zero. >=20 > I think that things should be fixed for this simpler context first and > that further investigation of the sh/su related should wait to see = what > things are like after this test case works. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Mar 15 06:17:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D00A0D0B534 for ; Wed, 15 Mar 2017 06:17:43 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CB301BDB for ; Wed, 15 Mar 2017 06:17:42 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MIzGn-1cm6RK1k9h-002USD for ; Wed, 15 Mar 2017 07:17:35 +0100 Date: Wed, 15 Mar 2017 07:17:24 +0100 From: "O. Hartmann" To: freebsd-current Subject: ntpd dies nightly on a server with jails Message-ID: <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KghQvvcOKtnh41DEbtxKqRUJfHv9EbwyZxocyahTXRvL9F3uGdF AfmPozY1s4NKpixJ3/dr54P8/oL/x8fZ61zVBrgWV1sbbYkFi4U2aJu/Blp9kDvH2whID5J UmLH2VGVF7G3ERpOc23YFR4sz+MnOhURXAkJWr4a/ZDOmA3dGaFKOQudeobb7Sy+cXqdu9n xOtAMRPye+UqBI41wfo1A== X-UI-Out-Filterresults: notjunk:1;V01:K0:WkWzMRb//fQ=:joVEigS/d3DzhCsHzSZt1k ym4j3dmRRHus1SaxgDFoOPxYOq0E0wQ/mQpIsxkjMl08EvGWD10UdRvCieQAT8h9yjKPAv3fG 8Xgx0+BYDW8r+4u67tMEiw5DAfcoo/pYdEpM1W9+oXvWhFB7Dnh5ch2kqeCpi5+JnYGAdfrBk hzEznkJyKlMRaipOou78cTHn5IsSKLkYiPJPPqcoBdhaPhiCryF0yRTJheUYhoSaZbhc4QdE0 yIRce0FDDScxoB+BlRso4wbzPy+5p7LMjVZ5cioT1xLeVtno1YAU0nds580xFp6C96UEauvPd dpHkbMog9S12Lslr/9AXgL95TyJRnQgWjAlFUsktkixroVZkWLWBo8bD14Q1AMy6Hceo9wQ3u Xg1eUnD1gTaz2QgNDV56ZkclU1JF5pYydmwW1gdW67UvCLcn793hQJItuPK2khG7ylv86voVI d6e0w3BLsVfKny0NGL5iDVFEuAUdt8emHw/zK/MWcSHq0OrOr1niRRHZs7GkOC8OGu8x0rSQ9 HwLwX2EDh7QC1X2MSfqoVTeFtZXmP0D5c+R4hT3mA5eI8d6rxa33t9e4TYXFe/OUusqCTAXfy dSuJLKMGUEecjV6UZ2K8U9ABh7HnO8s/aP8ULoJtJjpMa22PFBaoPQw051HCGMqTW8gmVw4pu A2lhQ0fuxQBq1hcLpktAduzKQJhNyaDdK9CEY0e/guxvQXIIaTW79e9pDVdjO0yVRYSMrUvpf gwzd+Lacx7dodb7oSug6XXxc6bKjD/oisSDFuw7HqAyAs0WzAlY9GPdX+0HSeNiLcvVuL9HVF bcGL1d7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 06:17:43 -0000 Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187: Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. The box is an older two-socket Fujitsu server equipted with two four-core Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. The box has several jails, each jail does NOT run service ntpd. Each jail has its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated IP: 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). The host itself has two main NICs, broadcom based. bcm0 is dedicated to the host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 via whihc the jails communicate with the network. I try to capture log informations via syslog, but FreeBSD's ntpd seems to be very, very sparse with such informations, coverging to null - I can't see anything suiatble in the logs why NTPD dies almost every night leaving the system with a wild reset of time. Sometimes it is a gain of 6 hours, sometimes it is only half an hour. I leave the box at 16:00 local time usually and take care again at ~ 7 o'clock in the morning local time. When the clock is floating that wild, in all cases ntpd isn't running any more. I try to restart with options -g and -G to adjust the time quickly at the beginning, which works fine. Apart from possible misconfigurations of the jails (I'm quite new to jails and their pitfalls), I was wondering what causes ntpd to die. i can't determine exactly the time of its death, so it might be related to diurnal/periodic processes (I use only the most vanilla configurations on periodic, except for checking ZFS's scrubbing enabled). I'ven't had the chance to check whether the hardware is completely all right, but from a superficial point of view there is no issue with high gain of the internal clock or other hardware issues. If there are known issues with jails (the problem occurs since I use those), advice is appreciated. Thanks in advance, O. Hartmann From owner-freebsd-current@freebsd.org Wed Mar 15 17:04:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 674B3D0E24F for ; Wed, 15 Mar 2017 17:04:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 51AD482F for ; Wed, 15 Mar 2017 17:04:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4E227D0E24D; Wed, 15 Mar 2017 17:04:49 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DBE1D0E24C for ; Wed, 15 Mar 2017 17:04:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 1039182D for ; Wed, 15 Mar 2017 17:04:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v2FH4kHH051225 for ; Wed, 15 Mar 2017 17:04:46 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v2FH4kDR051224 for current@freebsd.org; Wed, 15 Mar 2017 10:04:46 -0700 (PDT) (envelope-from david) Date: Wed, 15 Mar 2017 10:04:46 -0700 From: David Wolfskill To: current@freebsd.org Subject: Apparent build race(s), r315238 -> r315298 Message-ID: <20170315170446.GA1341@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2CtqMDJfWc01zJhs" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:04:49 -0000 --2CtqMDJfWc01zJhs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Both the biuld machine ("freebeast") and my laptop encountered errors during the "make -jN buildworld" -- each completed on restart, and the (initially-detected) errors were different: Build machine: =2E.. =3D=3D=3D> usr.bin/mkimg/tests (all) --- all_subdir_gnu --- Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui --- all_subdir_cddl --- --- all_subdir_cddl/usr.bin --- --- all_subdir_cddl/usr.bin/zinject --- =3D=3D=3D> cddl/usr.bin/zinject (all) --- all_subdir_gnu --- --- gdbtui --- cc: error: no such file or directory: '/usr/obj/usr/src/gnu/usr.bin/binutil= s/libbfd/libbfd.a' *** [gdbtui] Error code 1 bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui =2EERROR_TARGET=3D'gdbtui' =2EERROR_META_FILE=3D'/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.= meta' =2EMAKE.LEVEL=3D'6' MAKEFILE=3D'' =2EMAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' =2ECURDIR=3D'/usr/src/gnu/usr.bin/gdb/gdbtui' =2EMAKE=3D'/usr/obj/usr/src/make.amd64/bmake' =2EOBJDIR=3D'/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui' =2ETARGETS=3D'all' DESTDIR=3D'/usr/obj/usr/src/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160604' PATH=3D'/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/us= r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/ob= j/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' =2EMAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.e= nv.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/= bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/shar= e/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/gnu/u= sr.bin/gdb/gdbtui/Makefile /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/= bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr= /src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/gnu/usr.= bin/gdb/gdbtui/../Makefile.inc /usr/src/gnu/usr.bin/gdb/arch/amd64/Makefile= /usr/src/gnu/usr.bin/gdb/gdbtui/../../Makefile.inc /usr/src/gnu/usr.bin/gd= b/gdbtui/../../../Makefile.inc /usr/src/share/mk/bsd.own.mk /usr/src/share/= mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.= libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk= /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share= /mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.= mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share= /mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd= =2Esubdir.mk /usr/src/share/mk/bsd.sys.mk' =2EPATH=3D'. /usr/src/gnu/usr.bin/gdb/gdbtui /usr/src/contrib/gdb/gdb /usr/= src/contrib/gdb/gdb/cli /usr/src/contrib/gdb/gdb/mi /usr/src/contrib/gdb/gd= b/signals /usr/src/contrib/gdb/gdb/tui /usr/src/gnu/usr.bin/gdb/arch/amd64' 1 error bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui =2EERROR_TARGET=3D'gdbtui' =2E... Laptop: =2E.. =3D=3D=3D> usr.bin/mkcsmapper_static (obj,build-tools) --- build-tools_share/syscons/scrnmaps --- --- obj --- =2E.. --- obj_crunchdir_rcp --- --- obj_crunchdir_sync --- --- obj --- --- obj_crunchdir_csh --- --- obj_crunchdir_badsect --- --- build-tools_usr.bin/mkcsmapper_static --- --- lex.o --- /usr/src/usr.bin/mkcsmapper/lex.l:56:25: error: use of undeclared identifie= r 'R_LN' { linenumber++; return (R_LN); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:70:3: error: use of undeclared identifier= 'yylval' yylval.i_value =3D strtoul(yytext, NULL, 0); ^ /usr/src/usr.bin/mkcsmapper/lex.l:71:11: error: use of undeclared identifie= r 'L_IMM' return (L_IMM); ^ /usr/src/usr.bin/mkcsmapper/lex.l:74:11: error: use of undeclared identifie= r 'R_TYPE' { return (R_TYPE); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:75:11: error: use of undeclared identifie= r 'R_NAME' { return (R_NAME); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:76:11: error: use of undeclared identifie= r 'R_SRC_ZONE' { return (R_SRC_ZONE); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:77:11: error: use of undeclared identifie= r 'R_DST_INVALID' { return (R_DST_INVALID); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:78:11: error: use of undeclared identifie= r 'R_DST_ILSEQ' { return (R_DST_ILSEQ); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:79:11: error: use of undeclared identifie= r 'R_DST_UNIT_BITS' { return (R_DST_UNIT_BITS); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:80:11: error: use of undeclared identifie= r 'R_BEGIN_MAP' { return (R_BEGIN_MAP); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:81:11: error: use of undeclared identifie= r 'R_END_MAP' { return (R_END_MAP); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:82:11: error: use of undeclared identifie= r 'R_INVALID' { return (R_INVALID); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:83:11: error: use of undeclared identifie= r 'R_ILSEQ' { return (R_ILSEQ); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:84:11: error: use of undeclared identifie= r 'R_OOB_MODE' { return (R_OOB_MODE); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:85:11: error: use of undeclared identifie= r 'R_ROWCOL' { return (R_ROWCOL); } ^ /usr/src/usr.bin/mkcsmapper/lex.l:91:3: error: use of undeclared identifier= 'yylval' yylval.s_value =3D malloc(len - 1); ^ /usr/src/usr.bin/mkcsmapper/lex.l:92:11: error: use of undeclared identifie= r 'yylval' strlcpy(yylval.s_value, yytext + 1, len - 1); ^ /usr/src/usr.bin/mkcsmapper/lex.l:93:11: error: use of undeclared identifie= r 'L_STRING' return (L_STRING); ^ /usr/src/usr.bin/mkcsmapper/lex.l:96:3: error: use of undeclared identifier= 'yylval' yylval.s_value =3D strdup(yytext); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=3D] 20 errors generated. Building /common/S4/obj/usr/src/usr.bin/mkcsmapper_static/yacc.o --- build-tools_rescue/rescue --- =2E.. --- build-tools_usr.bin/mkcsmapper_static --- *** [lex.o] Error code 1 bmake[3]: stopped in /usr/src/usr.bin/mkcsmapper_static =2EERROR_TARGET=3D'lex.o' =2EERROR_META_FILE=3D'/common/S4/obj/usr/src/usr.bin/mkcsmapper_static/lex.= o.meta' =2EMAKE.LEVEL=3D'3' MAKEFILE=3D'' =2EMAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' =2ECURDIR=3D'/usr/src/usr.bin/mkcsmapper_static' =2EMAKE=3D'/usr/obj/usr/src/make.amd64/bmake' =2EOBJDIR=3D'/usr/obj/usr/src/usr.bin/mkcsmapper_static' =2ETARGETS=3D'build-tools' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160604' PATH=3D'/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/us= r/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' =2EMAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.e= nv.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/= bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/shar= e/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/usr.b= in/mkcsmapper_static/Makefile /usr/src/usr.bin/mkcsmapper/Makefile.inc /usr= /src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/= mk/bsd.cpu.mk /usr/src/tools/build/mk/bsd.prog.mk /usr/src/share/mk/bsd.pro= g.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src= /share/mk/src.init.mk /usr/src/usr.bin/mkcsmapper_static/../Makefile.inc /u= sr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share= /mk/src.libnames.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.nls= =2Emk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/sr= c/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd= =2Eman.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.= mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/sh= are/mk/bsd.sys.mk /usr/src/tools/build/mk/Makefile.boot' =2EPATH=3D'. /usr/src/usr.bin/mkcsmapper_static /usr/src/lib/libc/iconv /us= r/src/usr.bin/mkcsmapper' --- build-tools_rescue/rescue --- --- obj_crunchdir_badsect --- cd /usr/src/rescue/rescue/../../sbin/badsect && MK_AUTO_OBJ=3Dno MK_TESTS= =3Dno UPDATE_DEPENDFILE=3Dno _RECURSING_CRUNCH=3D1 MAKEOBJDIRPREFIX=3D/us= r/obj/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=3Dre= scue/rescue/badsect/ -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE MK_AUTO_OBJ=3Dno obj --- obj_crunchdir_test --- =2E... I have placed suitably-named copies of the typescripts (as well as compressed copies of same) up at . Additional information about the machines and environments (including, e.g., verbose dmesg.boot) is available at . Peace, david --=20 David H. Wolfskill david@catwhisker.org Claims that lack evidence are not a basis for rational decision-making. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --2CtqMDJfWc01zJhs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYyXQuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xki0IAIV4AbHRWGwWJ+lB7C9u0vek LWhhnOv93iMD1YJ49s0iZDJ1DNfH/YNBDFTaugW7Dl6Y1BwXSwbRPc+O/SGU0IgG eloGUjq1+ZRNGLGgK0haXq5O/JHk8ayT8nxOubsCbWqQIz418hctQiAWd42PsPhH ewC96CcBqn7w5B0AtXxrw8AnNHp8stH1YQsN0rvz3Bl5NSAta4RCfVxUo7CF4bV6 0gtYXLfa6dEH9Bt+91QWU/G5550jvrmuc2zhOLoPz06HmPnGTJ6gXV/5oA8k3exj L+zHV2ucuL8nIlJ0R2hMDo+c2ReYvwnhoUXvahASzdwN/7U3kbzZpcxIMu1xRYY= =2+gk -----END PGP SIGNATURE----- --2CtqMDJfWc01zJhs-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:10:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECBF6D0D987 for ; Wed, 15 Mar 2017 18:10:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CCD641FCA for ; Wed, 15 Mar 2017 18:10:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CBD79D0D986; Wed, 15 Mar 2017 18:10:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB7A2D0D985 for ; Wed, 15 Mar 2017 18:10:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C86C1FC6; Wed, 15 Mar 2017 18:10:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B7B8731FF; Wed, 15 Mar 2017 18:10:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 313413729B; Wed, 15 Mar 2017 18:10:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id J84vPKg5iD9U; Wed, 15 Mar 2017 18:09:12 +0000 (UTC) Subject: Re: Apparent build race(s), r315238 -> r315298 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com E9CB837294 To: David Wolfskill , current@freebsd.org References: <20170315170446.GA1341@albert.catwhisker.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> Date: Wed, 15 Mar 2017 11:09:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170315170446.GA1341@albert.catwhisker.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rWcUaK8MTH3s5SFed81kPRXwngRrGFCMV" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rWcUaK8MTH3s5SFed81kPRXwngRrGFCMV Content-Type: multipart/mixed; boundary="Nvr8Kr2xR22iElaHI7w7a5musCENqskMW"; protected-headers="v1" From: Bryan Drewery To: David Wolfskill , current@freebsd.org Message-ID: <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> Subject: Re: Apparent build race(s), r315238 -> r315298 References: <20170315170446.GA1341@albert.catwhisker.org> In-Reply-To: <20170315170446.GA1341@albert.catwhisker.org> --Nvr8Kr2xR22iElaHI7w7a5musCENqskMW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/15/2017 10:04 AM, David Wolfskill wrote: > -------------------------------------------------------------- >>>> stage 1.1: legacy release compatibility shims > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp=20 Ok it is trying to use MAKEOBJDIRPREFIX=3D/usr/obj > Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui But all of the 'Building' lines are tryign to use MAKEOBJDIRPREFIX=3D/common/S4/obj/ ... > --- all_subdir_cddl --- > --- all_subdir_cddl/usr.bin --- > --- all_subdir_cddl/usr.bin/zinject --- > =3D=3D=3D> cddl/usr.bin/zinject (all) > --- all_subdir_gnu --- > --- gdbtui --- > cc: error: no such file or directory: '/usr/obj/usr/src/gnu/usr.bin/bin= utils/libbfd/libbfd.a' But then complains about a missing file in MAKEOBJDIRPREFIX=3D/usr/obj > *** [gdbtui] Error code 1 >=20 > bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui > .ERROR_TARGET=3D'gdbtui' > .ERROR_META_FILE=3D'/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtu= i.meta' > .MAKE.LEVEL=3D'6' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dye= s verbose' > .CURDIR=3D'/usr/src/gnu/usr.bin/gdb/gdbtui' > .MAKE=3D'/usr/obj/usr/src/make.amd64/bmake' =2E.. > .OBJDIR=3D'/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui' And says here that there is an existing directory for MAKEOBJDIRPREFIX=3D/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which is= throwing off its paths for libbfd.a. =2E.. > MAKEOBJDIRPREFIX=3D'/usr/obj' And the meta error agrees it wants MAKEOBJDIRPREFIX=3D/usr/obj So where is /common/S4/obj coming from? Is there a symlink involved here for /usr/obj? --=20 Regards, Bryan Drewery --Nvr8Kr2xR22iElaHI7w7a5musCENqskMW-- --rWcUaK8MTH3s5SFed81kPRXwngRrGFCMV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYyYNNAAoJEDXXcbtuRpfPxHAH/jERhQd8voMQy6NSAM95jjyO RCJFj1s5O/DXtBUw/ECBsGh24wcfOFvKxS50vKI87xmYCbup73EeQRiIeMPnmkgM cdFz+6zgFxNBuf4VEI7s4SjFB0GC36ZNOgcBBwffrJMxBo32gx6vGSS27hMHs5K+ L58OEHJS2Me6CQgoj3JnELbDcqBb665qtbmNhIFpnSQw0UJThj6yzct2KvnMbUuX J4csnftBKs7nRvhGxFjAMKjYjpmNRuIXfyRESxFOljx8gyWLeW1TpJCXD/wcw2JR FSu2HmkIWGWysme4LV0lBGViqavTvxM07R+MpF5X0Ds7lxcfhhF6gYskVr8M1Z0= =Udna -----END PGP SIGNATURE----- --rWcUaK8MTH3s5SFed81kPRXwngRrGFCMV-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:21:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3955D0E11E for ; Wed, 15 Mar 2017 18:21:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BDCA5D84 for ; Wed, 15 Mar 2017 18:21:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BD25ED0E11D; Wed, 15 Mar 2017 18:21:42 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCCD0D0E11C for ; Wed, 15 Mar 2017 18:21:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 8A100D82; Wed, 15 Mar 2017 18:21:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id l66so1643259pfl.3; Wed, 15 Mar 2017 11:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=3Zc6sXn3gFhIVGU+jpvjPiclp5cPujdaAeLhVRWGWLI=; b=IvIORMJPD7pWPQWNU2ni040dvl04060qkQwMCwgoTkHYnt/1HJ04PwV2hqv8IcxW3x GA9oPfubPHDECF7jCMnvZCrJ+AT8N4AkOit8PWsZjZCpd+lE56LDo4UdZ+0Drzu2LhOx 6ikXwdhwyyPnuelD7CRhfdGuedv9rE9df7y29AV61O1iE1qoaoDXl+FAIrzP9FXs96U+ KT0INBqQDO98ucDtxCgwCI63T8xi5fOvbWyaqkpDuG009m1zN2HRk4v36dwln4FMQz4I sUa7HX/f6SC64qB+AZwvv+GUHpCwIoys8cy0xRuYvJ/TdQP1aCUYrKDGjuXUwe8tmNdm 7OBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=3Zc6sXn3gFhIVGU+jpvjPiclp5cPujdaAeLhVRWGWLI=; b=HNzMsiS04Jsxl75BZ4uZzBZ6QLMnJPDhIBZoV6kJAtzhSelVQ2m8PxQZZLlRARYQMn P+QLU79N7bGIiAnd50+/Of1DW8+OxlNWFl5BSIfgBiuV9i4yYNQFY/wknggieQZt5w3l 3fHpxcwwANww+Vxq8+7yW2v9joo3F01gngDBg5wLucnNMXPIEZVyRHacdT1cxhwbP3f+ +JtXecfEdbDO2nODRFHxppssRx4p5w39zMbxCaLIXVo+Gtu9hGbR9b5xgMSyW2/5Gi1C dEOojnz2H9l+Ja6Q8KwR7dLeWbiWGkRCICrXpDLwoZm4ZCWgCtu3i4fM0EboaOT17qba HX6g== X-Gm-Message-State: AFeK/H2EMkW7FgrwWG7tLiIamQeTHlUu5PmwSjqO8p3DDTuL2sGd/WddRzxv9/juUBnwQg== X-Received: by 10.98.69.86 with SMTP id s83mr5310981pfa.232.1489602101927; Wed, 15 Mar 2017 11:21:41 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id x10sm5670880pfi.21.2017.03.15.11.21.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Mar 2017 11:21:41 -0700 (PDT) Subject: Re: Apparent build race(s), r315238 -> r315298 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_708D0D65-D28E-430C-B016-DA253A5D0891"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> Date: Wed, 15 Mar 2017 11:21:40 -0700 Cc: David Wolfskill , current@freebsd.org Message-Id: References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:21:43 -0000 --Apple-Mail=_708D0D65-D28E-430C-B016-DA253A5D0891 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Mar 15, 2017, at 11:09, Bryan Drewery wrote: >=20 > On 3/15/2017 10:04 AM, David Wolfskill wrote: >=20 >> -------------------------------------------------------------- >>>>> stage 1.1: legacy release compatibility shims >> -------------------------------------------------------------- >> cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/tmp >=20 > Ok it is trying to use MAKEOBJDIRPREFIX=3D/usr/obj >=20 >> Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui >=20 > But all of the 'Building' lines are tryign to use > MAKEOBJDIRPREFIX=3D/common/S4/obj/ ... >=20 >> --- all_subdir_cddl --- >> --- all_subdir_cddl/usr.bin --- >> --- all_subdir_cddl/usr.bin/zinject --- >> =3D=3D=3D> cddl/usr.bin/zinject (all) >> --- all_subdir_gnu --- >> --- gdbtui --- >> cc: error: no such file or directory: = '/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a' >=20 > But then complains about a missing file in MAKEOBJDIRPREFIX=3D/usr/obj >=20 >> *** [gdbtui] Error code 1 >>=20 >> bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui >> .ERROR_TARGET=3D'gdbtui' >> = .ERROR_META_FILE=3D'/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.m= eta' >> .MAKE.LEVEL=3D'6' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> .CURDIR=3D'/usr/src/gnu/usr.bin/gdb/gdbtui' >> .MAKE=3D'/usr/obj/usr/src/make.amd64/bmake' > ... >> .OBJDIR=3D'/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui' >=20 > And says here that there is an existing directory for > MAKEOBJDIRPREFIX=3D/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which = is > throwing off its paths for libbfd.a. >=20 > ... >> MAKEOBJDIRPREFIX=3D'/usr/obj' >=20 > And the meta error agrees it wants MAKEOBJDIRPREFIX=3D/usr/obj >=20 >=20 > So where is /common/S4/obj coming from? >=20 > Is there a symlink involved here for /usr/obj? ^/head@r315175 doesn=92t look like it=92s causing a problem = here. I don=92t think my commit here recently (^/head@r313650) was a = problem, but I wonder if it exposed a race or incomplete dependency = logic=85 Thanks! -Ngie --Apple-Mail=_708D0D65-D28E-430C-B016-DA253A5D0891 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYyYY0AAoJEPWDqSZpMIYVNsIQAIHRt78tKtlvzg5Ewkq6iC3Q bPgyyerwVsnyIm+iXURB09brk6wQe4Kusf3M1aqAvWJCrjhzU4NZ27gfM0USvFih XMo1HNNTqdUCeY4RAYGZUt7shzJ94EYHiQ4zVZ7qwKYvn4cVh3fu2JbZLzQp326C t4fqpWi/AqFowC/sS6Sqx/vITnm4/0VR7aDxY6HRWLlRbbm+o5LVk0QzWvXE7WKB msxmMmWyCnvmdauM2SaxMeRJj+Pe52Pyi4NUcsk/h9So105oZRoFOCSgStifRx83 Yn4iYp9AJ5wrDinAk/EhU7xOtbcIb9x6VrA3LnmxZfumON5Oan0kSDQUoMv/yzT0 iuvgjcLRlx9nxFPEPnmEi25SOWIe7gwxbvg9zitbOAYNrOijx8ZVUEho5y2ENDYl AUgh7nxSjT3F+BLyd2KF5rVRt8zbvcgpSzzh6wznMCIhiJbyB50Rqh78jHhHVOLT qqo404M9To6rZlwe4WPyXFP6AGRS5nEFPGws9cNy5vs7fVGJgY5PggR4k7e3f3jf eQgJxSLrZOIvSV/h3/nGxgUFuN3B4nEKBLgh4MbHoU4oZxJiM+Z7ipeqL6xXIIh+ mvsbJaH8K1L3sqwMs/TsvLpPpoblsQnd5uIG4a2j9s4rc9/NzcGwvLU5mAaJSG4L IgeH03r8vXZPhVTtRBNM =TN9W -----END PGP SIGNATURE----- --Apple-Mail=_708D0D65-D28E-430C-B016-DA253A5D0891-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:23:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6B62D0E2EC for ; Wed, 15 Mar 2017 18:23:17 +0000 (UTC) (envelope-from david@catwhisker.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 D038BFDD for ; Wed, 15 Mar 2017 18:23:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id CF8BFD0E2EB; Wed, 15 Mar 2017 18:23:17 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF2F9D0E2EA for ; Wed, 15 Mar 2017 18:23:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 8A706FDC; Wed, 15 Mar 2017 18:23:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v2FINF4W051998; Wed, 15 Mar 2017 18:23:15 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v2FINFWA051997; Wed, 15 Mar 2017 11:23:15 -0700 (PDT) (envelope-from david) Date: Wed, 15 Mar 2017 11:23:15 -0700 From: David Wolfskill To: Bryan Drewery Cc: current@freebsd.org Subject: Re: Apparent build race(s), r315238 -> r315298 Message-ID: <20170315182315.GE1341@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Bryan Drewery , current@freebsd.org References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RBYxkammHF1d4YNT" Content-Disposition: inline In-Reply-To: <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:23:18 -0000 --RBYxkammHF1d4YNT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: > ... > So where is /common/S4/obj coming from? >=20 > Is there a symlink involved here for /usr/obj? > .... Yes; I've had /usr/obj as a symlink (to a different file system) for ... a couple of decades, now.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Claims that lack evidence are not a basis for rational decision-making. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --RBYxkammHF1d4YNT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYyYaTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XRwoH/iuYAQTQ40ZSlnPhOeLglDg6 NThrFG2RB3gcx2iCd82OL3N787OnKuG1kjYgB9YbbElDyqefZRJ6YsK8W5aYSQFh 7xhyoTgFY4RfbuZ7EVbQV01bIENU5PkL0fFP+t9ZtRFcvLE7PBZ1e5W3F5dT4rNO P9eoyOIB4RfqkEJ93NeX9If+MH6o+9TWq6SnY91kSsyl8WFi/QHUXhMimUWFTxLf GEDQAe5N52Rpt+jW34XTbcacVULp41k9/xL/KrEZxKhMm/P3iuPl7UX5j3BPMQKJ 0iT+ubGA/p+9JXOo5lITqlGbgkYkFN2JYbHVI0RfrMHCi6H6y5kvKMPvtYjPz/g= =zGko -----END PGP SIGNATURE----- --RBYxkammHF1d4YNT-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:24:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AC65D0E446 for ; Wed, 15 Mar 2017 18:24:54 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3501012C3 for ; Wed, 15 Mar 2017 18:24:54 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3465BD0E43D; Wed, 15 Mar 2017 18:24:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 340BCD0E43C for ; Wed, 15 Mar 2017 18:24:54 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0162D12C2; Wed, 15 Mar 2017 18:24:54 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x243.google.com with SMTP id o126so2968689pfb.1; Wed, 15 Mar 2017 11:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=1EWfOaqYKuvpgsmdAUKCZtuv2K3Iz6MTl+F1kKAGhN8=; b=gRAnicCQiMoAAx0tVKahG2KP6Z76PT+IqiR72971ath7v1pivtvX7Nd8a6WWAu9M0o ooNMO/vyGwWTkxFuueKRAjzaJ9fi9OqLu0eJu4dp4q1gmhFRunyZ6gfvuYww5ZSQviRH 0GeFNLyqyHtszE99A/0hZpFBuW7SWf3PfJ72vI1/9ESvrtS3qfT8O6RmC7tz71r0gybN A1lTlzG4Zhh/vEi1QLie4I1Wk9jjjU3OnycZ06IK9BzmUs2xmxdxN03MAhsMZtvVtCKQ pVJyn0SPhDV3wbF55EYddxDS/bMWI8VrGY0t0C4EV5UGR8uoyvxGcgufj+y0tdLgmRGJ nvvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=1EWfOaqYKuvpgsmdAUKCZtuv2K3Iz6MTl+F1kKAGhN8=; b=eVmTOL1HLB7bCH3wN4iTpZ9GU+opPAVSYeq7eZxew2m4qOd/jaG0lFyMoSFn0Ocsyo 5i3wx+wm6UDSYWkOg/WWllmocDUPaHY1iknp1arH+1qvzet+cyaeVMnsdLsnhf7nkxJJ 7JbyoQ6cEZy7sI4nvy/+kKvap4EbLQAa0NvwRKydlwxi0r+kXnkEmfpThVVhbtIbGWUs Zk8BJTTf33JCh2hBjwflcAYFEZa2UMQZRQ3I0c+JSc1mesIBC8uxpojolC8EL2Y8Y9Ql RMAZrZ1GtN7LUagvUCYHYgBQiIBQtq6Md5y/x5wkSdZ+cZnSVHklicINt9K1jyyV9ZVC RXJw== X-Gm-Message-State: AFeK/H1JfZwaZYKyHpVf0ieuDFlyAuAdEGVRjz5KhJSHXKHh/9OoSp9iP+ZxisXx1WJGLw== X-Received: by 10.84.135.34 with SMTP id 31mr6338045pli.50.1489602293675; Wed, 15 Mar 2017 11:24:53 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id a8sm5683439pfa.30.2017.03.15.11.24.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Mar 2017 11:24:53 -0700 (PDT) Subject: Re: Apparent build race(s), r315238 -> r315298 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F81AA1B8-6B0B-4871-8E0F-D926D3D19DAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170315182315.GE1341@albert.catwhisker.org> Date: Wed, 15 Mar 2017 11:24:52 -0700 Cc: Bryan Drewery , current@freebsd.org Message-Id: References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:24:54 -0000 --Apple-Mail=_F81AA1B8-6B0B-4871-8E0F-D926D3D19DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 15, 2017, at 11:23, David Wolfskill = wrote: >=20 > On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >> ... >> So where is /common/S4/obj coming from? >>=20 >> Is there a symlink involved here for /usr/obj? >> .... >=20 > Yes; I've had /usr/obj as a symlink (to a different file system) for = ... > a couple of decades, now.... What happens if you revert r314808 and r315088 (the bmake-20170301 = upgrade and supporting commit)? Thanks! -Ngie --Apple-Mail=_F81AA1B8-6B0B-4871-8E0F-D926D3D19DAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYyYb0AAoJEPWDqSZpMIYVpFwP/R8eBV4uD1ueTqD5GrIfN5bP OgGQdmCyQVIIxSo6xmU5rmvW4AHoHEdbysYQYlZ7abLqnobcMSTV0rC7N0qPqPtg Xj24RG1/tfH28B+FT/+AI26ciNARkZAPmdmIl5VTuLknGtpFM1E5ITgFTsVaKSC+ 2vCZEqJgdVK4TbFEFtqvBjXCbiOWe6RebXim1EMQnNTsUoaHvORlw11KliBzXFlg sN5ZuLx68U2V9qy4vgivmaCLgB/SyfejOsJi7bFAuOP48e73zAVsyCJSLm4gqOvm eZSE4N9Y3SdMk2QOcenNOFVVWMgK8sUKAr5oMjIP51KjYVg37I7h9oVtblIxBwPR uKwP6TXNTkiYcH010WchR8+oas6SM4ghreob2sWqVwp/tgdq1HbvXqkawlo+rfiq qQevd52cYO0+H8kxEpM8GkVJD1CiN7EAmP3TTuYdNpZwSCZolM4iHcFoBhk5tpnD rl57TiooA1G3R2cY2dVdMZqma9UpTJVBvktgJNhZdafmjYHs/HNrrgbfzNpdl7wf Zkz6LvvsXBMIV1Jjx2ByDKEFBUBvx5UVqAuJg7d3jd8c2L86f9Z68hCN94hycBd5 wehlyX56HlKwbA+NdNox5HEpyYhQWcTMis3/spN//NEx+SFC2Bgct1Hq4528ijWr bRYmQdH2YTg6U06s4aoz =S4lF -----END PGP SIGNATURE----- --Apple-Mail=_F81AA1B8-6B0B-4871-8E0F-D926D3D19DAE-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:29:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90B55D0E50C for ; Wed, 15 Mar 2017 18:29:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6C414DF for ; Wed, 15 Mar 2017 18:29:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 66C98D0E50B; Wed, 15 Mar 2017 18:29:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 666D1D0E50A for ; Wed, 15 Mar 2017 18:29:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32FC014DE; Wed, 15 Mar 2017 18:29:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x244.google.com with SMTP id l66so1662495pfl.3; Wed, 15 Mar 2017 11:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=+dQdt1O79S0MepArdoJ5CgFZVi44XOrzGcN1P4DJYrA=; b=tnMPEh/xJyjSftgfeNIzmcuA4iKRdP5vN4sha2HVM6gAKtZY7L+3CN6XXHbXxqSJtk uNPU5Ma3JlW1dTL1btKNy6ADudqOZBEmbl0goLI8DC0CZT6HbCXYZm1+Jpet5VM2ZiFk YVB6zpoUZcEEyjFttAj9e4zBI73FQ0qUbJTcbwKh3e8tozKdpCruff9PFGf+5LrCo11q XAhsw3KrQjUCAmeeW9Iq+mLKHsdvTlK/wd/tljs5aIO7MrAJzChBWM68XO9OgScRCpC8 EIS5yyAsp/JnouTrbc5NCZX4FGXH+NM+iB94CECBhqD7/kpbTBO/0aFk9RPiVDv/uwd1 j7ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=+dQdt1O79S0MepArdoJ5CgFZVi44XOrzGcN1P4DJYrA=; b=JshLPRE4ELH94kVUK7Nxrca6ktUt97NP7er+Ay428wsubCsJQu+F6GP5z/+IlMMOhN Dnv91VjEmBpP9aVfezGOLrDhvFyZ2dYCMjdnCZKRfryLcJ+Rfvmlv3CquhNTUNRkkWb4 Z6cL7ofaAEZJwVu5lVIGQUgMDnMFQiV98CirN0lha93pC82mUuH/Az60YUcInKonBGfP 4hZBZVClN1587pT5OPHIlKyD5Hn/BlX7/3FScWWwQ1UmAdjTKJpmFz9uTcduSM4fuq9q riu5JS57fmgfj45TvjqCY0pRS30tvnbwla28+IH/N8fvm9juI65TEwdFmUQ6vuN0ZYT/ Z+cA== X-Gm-Message-State: AFeK/H1yIl4UC2FEd/p7AgB9KB7H+SplP36vRjtLt8ILP4ZPtwwmVdRD9LE3dJTfaCrGtw== X-Received: by 10.98.75.221 with SMTP id d90mr5156750pfj.107.1489602552838; Wed, 15 Mar 2017 11:29:12 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id s65sm5696797pgb.64.2017.03.15.11.29.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Mar 2017 11:29:12 -0700 (PDT) Subject: Re: Apparent build race(s), r315238 -> r315298 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_80F4289E-C6F8-409B-ACA2-529A4ABC03A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Wed, 15 Mar 2017 11:29:11 -0700 Cc: Bryan Drewery , current@freebsd.org Message-Id: References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:29:13 -0000 --Apple-Mail=_80F4289E-C6F8-409B-ACA2-529A4ABC03A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 15, 2017, at 11:24, Ngie Cooper (yaneurabeya) = wrote: >=20 >=20 >> On Mar 15, 2017, at 11:23, David Wolfskill = wrote: >>=20 >> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >>> ... >>> So where is /common/S4/obj coming from? >>>=20 >>> Is there a symlink involved here for /usr/obj? >>> .... >>=20 >> Yes; I've had /usr/obj as a symlink (to a different file system) for = ... >> a couple of decades, now.... >=20 > What happens if you revert r314808 and r315088 (the bmake-20170301 = upgrade and supporting commit)? Alternatively, could you please revert just r313650 in another = branch/workspace (I wonder if changing from .OBJDIR to OBJTOP had some = unintended consequences that unrooted issues with how bmake evaluates = paths)? Thanks! -Ngie --Apple-Mail=_80F4289E-C6F8-409B-ACA2-529A4ABC03A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYyYf3AAoJEPWDqSZpMIYVWdQP/irVTyrP9nfW+644Hwawktnh mvjXYk7WXaSHDmFbwnaZXBKLNkt57K/1QC8HMnAQPlAcLfGll8OzVoxWQaCbdEf3 MjFSKgutdjWCSlwBFVWet7O4eHvKPuJa4NQ66uvAIj/VlJLqC6av9HYOpKo/iotc ppFCDmp6NkHNmU5WLt9tp61G59yqtv/KCFK7B0mth/MFarIx90BuWsPLAwzpbg2W DszfVMpEhfAi0jwC1r415hNgBIMSOZHinuIKE7BFijX8nz3y4hXfnRUC+LSnnfWd Wd1VPlbSzAHSS3nbxHZ7mFp0QctCJ5xdlvJvszRg8GWFvioAJhOmUfNsAqxoqRr+ AFG6bOUmU/o5R+VA+VvzsbyU8rCFaTA5K4aSwDwJlmzUel5gw2+a1n0t9/ZZaGMb XWcdqafH0ktisO55wQp4ePfZqHx3xYyu/2zTp46og6cQPDkc4e0yArc/4fIg0PzH EVypWGXUCvta0/heT8tr6vymSEZiAqNzYCsOFlFXTfDHJq6YoSEkT9HMGzOQklc+ akI12cvPguDGs5XTU2fn0EwnvSZd2NPjhsgAmtJWGGkZoCiz9AmndeWC11wwM2D4 Mep5RMr9KcZbutgqsjzca6V36TbZzTXnuWKLoHhLgOvUAIJdqRLcUsyXVrbGc+wW hGdSHTHauNtKpKjPmE9o =OR1v -----END PGP SIGNATURE----- --Apple-Mail=_80F4289E-C6F8-409B-ACA2-529A4ABC03A5-- From owner-freebsd-current@freebsd.org Wed Mar 15 18:51:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C535D0EFA8 for ; Wed, 15 Mar 2017 18:51:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (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 C202FEFD for ; Wed, 15 Mar 2017 18:51:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11911 invoked from network); 15 Mar 2017 18:51:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 18:51:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 15 Mar 2017 14:51:51 -0400 (EDT) Received: (qmail 16003 invoked from network); 15 Mar 2017 18:51:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 18:51:51 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 796CBEC9026; Wed, 15 Mar 2017 11:51:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> Date: Wed, 15 Mar 2017 11:51:49 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:51:59 -0000 [Something strange happened to the automatic CC: fill-in for my original reply. Also I should have mentioned that for my test program if a variant is made that does not fork the swapping works fine.] On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > On 2017-Mar-15, at 6:15 AM, Scott Bennett wrote: >=20 >> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >> wrote: >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>=20 >>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>> [test_check() between the fork and the wait/sleep prevents the >>>>> failure from occurring. Even a small access to the memory at >>>>> that stage prevents the failure. Details follow.] >>>>=20 >>>> Maybe a stupid question, since you might have written it somewhere. >>>> What medium do you swap to? >>>> I've seen broken firmware on microSD cards doing silent data >>>> corruption for some access patterns. >>>=20 >>> The root filesystem is on a USB SSD on a powered hub. >>>=20 >>> Only the kernel is from the microSD card. >>>=20 >>> I have several examples of the USB SSD model and have >>> never observed such problems in any other context. >>>=20 >>> [remainder of irrelevant material deleted --SB] >>=20 >> You gave a very long-winded non-answer to Bernd's question, so = I'll >> repeat it here. What medium do you swap to? >=20 > My wording of: >=20 > The root filesystem is on a USB SSD on a powered hub. >=20 > was definitely poor. It should have explicitly mentioned the > swap partition too: >=20 > The root filesystem and swap partition are both on the same > USB SSD on a powered hub. >=20 > More detail from dmesg -a for usb: >=20 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on = usbus0 > ugen1.1: at usbus1 > uhub1: on = usbus1 > ugen2.1: at usbus2 > uhub2: on = usbus2 > ugen3.1: at usbus3 > uhub3: on = usbus3 > . . . > uhub0: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > uhub3: 1 port with 1 removable, self powered > ugen3.2: at usbus3 > uhub4 on uhub3 > uhub4: on = usbus3 > uhub4: MTT enabled > uhub4: 4 ports with 4 removable, self powered > ugen3.3: at usbus3 > umass0 on uhub4 > umass0: on = usbus3 > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > umass0:0:0: Attached to scbus0 > . . . > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number > da0: 40.000MB/s transfers >=20 > (Edited a bit because there is other material interlaced, even > internal to some lines. Also: I removed the serial number of the > specific example device.) >=20 >> I will further note that any kind of USB device cannot = automatically >> be trusted to behave properly. USB devices are notorious, for = example, >> for momentarily dropping off-line and then immediately reconnecting. = (ZFS >> reacts very poorly to such events, BTW.) This misbehavior can be = caused >> by either processor involved, i.e., the one controlling either the >> upstream or the downstream device. Hubs are really bad about this, = but >> any USB device can be guilty. You may have a defective storage = device, >> its controller may be defective, or any controller in the chain all = the >> way back to the motherboard may be defective or, not defective, but >> corrupted by having been connected to another device with corrupted >> (infected) firmware that tries to flash itself into the firmware = flash >> chips in its potential victim. >> Flash memory chips, spinning disks, or {S,}{D,}RAM chips can be >> defective. Without parity bits, the devices may return bad data and = lie >> about the presence of corrupted data. That, for example, is where = ZFS >> is better than any kind of classical RAID because ZFS keeps checksums = on >> everything, so it has a reasonable chance of detecting corruption = even >> without parity support and, if there is any redundancy in the pool or = the >> data set, fixing the bad data machine. Even having parity generally >> allows only the detection of single-bit errors, but not of repairing = them. >> You should identify where you page/swap to and then try = substituting >> a different device for that function as a test to eliminate the = possibility >> of a bad storage device/controller. If the problem still occurs, = that >> means there still remains the possibility that another controller or = its >> firmware is defective instead. It could be a kernel bug, it is true, = but >> making sure there is no hardware or firmware error occurring is = important, >> and as I say, USB devices should always be considered suspect unless = and >> until proven innocent. >=20 > [FYI: This is a ufs context, not a zfs one.] >=20 > I'm aware of such things. There is no evidence that has resulted in > suggesting the USB devices that I can replace are a problem. Otherwise > I'd not be going down this path. I only have access to the one arm64 > device (a Pine64+ 2GB) so I've no ability to substitution-test what > is on that board. >=20 > It would be neat if some folks used my code to test other arm64 > contexts and reported the results. I'd be very interested. > (This is easier to do on devices that do not have massive > amounts of RAM, which may limit the range of devices or > device configurations that are reasonable to test.) >=20 > There is that other people using other devices have reported > the behavior that started this investigation. I can produce the > behavior that they reported, although I've not seen anyone else > listing specific steps that lead to the problem or ways to tell > if the symptom is going to happen before it actually does. Nor > have I seen any other core dump analysis. (I have bugzilla > submittals 217138 and 217239 tied to symptoms others have > reported as well as this test program material.) >=20 > Also, considering that for my test program I can control which pages > get the zeroed-problem by read-accessing even one byte of any 4K > Byte page that I want to make work normally, doing so in the child > process of the fork, between the fork and the sleep/swap-out, it does > not suggest USB-device-specific behavior. The read-access is changing > the status of the page in some way as far as I can tell. >=20 > (Such read-accesses in the parent process make no difference to the > behavior.) I should have noted another comparison/contrast between having memory corruption and not in my context: I've tried variants of my test program that do not fork but just sleep for 60s to allow me to force the swap-out. I did this before adding fork and before using parital_test_check, for example. I gradually added things apparently involved in the reports others had made until I found a combination that produced a memory corruption test failure. These tests without fork involved find no problems with the memory content after the swap-in. For my test program it appears that fork-before-swap-out or the like is essential to having the problem occur. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Mar 15 21:10:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C0C1D0DA14 for ; Wed, 15 Mar 2017 21:10:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4FD15AF for ; Wed, 15 Mar 2017 21:10:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 19B57D0DA13; Wed, 15 Mar 2017 21:10:04 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 195EBD0DA0F for ; Wed, 15 Mar 2017 21:10:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E00A215AE; Wed, 15 Mar 2017 21:10:03 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 2671C630D; Wed, 15 Mar 2017 21:10:03 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id B452720C4; Wed, 15 Mar 2017 21:10:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Q-WVNaLAhzqr; Wed, 15 Mar 2017 21:09:58 +0000 (UTC) Subject: Re: Apparent build race(s), r315238 -> r315298 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 71F6C20BF To: David Wolfskill , current@freebsd.org References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Wed, 15 Mar 2017 14:10:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170315182315.GE1341@albert.catwhisker.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8X0h1kwriHO8hsucTWbmfSIoHTeIE4DjM" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:10:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8X0h1kwriHO8hsucTWbmfSIoHTeIE4DjM Content-Type: multipart/mixed; boundary="Jcf7IInX94P6Vc3RjkpmglBR138EJiVjd"; protected-headers="v1" From: Bryan Drewery To: David Wolfskill , current@freebsd.org Message-ID: Subject: Re: Apparent build race(s), r315238 -> r315298 References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> In-Reply-To: <20170315182315.GE1341@albert.catwhisker.org> --Jcf7IInX94P6Vc3RjkpmglBR138EJiVjd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/15/2017 11:23 AM, David Wolfskill wrote: > On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >> ... >> So where is /common/S4/obj coming from? >> >> Is there a symlink involved here for /usr/obj? >> .... >=20 > Yes; I've had /usr/obj as a symlink (to a different file system) for ..= =2E > a couple of decades, now.... Ok, I don't think the symlink is the problem. It's just the meta mode handling forcing a realpath(3) on some of the output which causes the confusion. Still looking... --=20 Regards, Bryan Drewery --Jcf7IInX94P6Vc3RjkpmglBR138EJiVjd-- --8X0h1kwriHO8hsucTWbmfSIoHTeIE4DjM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYya27AAoJEDXXcbtuRpfPOlsH/AxCjgCgS4Jmjqj0zdJdJOMz 5XcHWiJH/qnAtOsyFkY1mSvKIdzMs9puEEVaahMVMNlvvlMN/AhWwDrcUEArvJLc CTc8rxh/+lFKDwdasFR/HA40YiwyvTaqCj6lEuIViJt96obRiGfABE2ktzc3XTNT oK4eEW8rjJ6Uvy2omP0plTktZ2sjem07mAbruk8l2rRTAE2Qn2iDKCF+i3YY4GXD Yym543E/xNJ0/M2qXsXL4RAYaEGczHNIie2PajQ4JFfTf0fYerNPOVphPRu5R8MM alUHCL+8SvZmeNsunGJIb+Gndm98VoW8X2FU05vkyLOfHD0rmJygRuaL6n9ZxNI= =1bhw -----END PGP SIGNATURE----- --8X0h1kwriHO8hsucTWbmfSIoHTeIE4DjM-- From owner-freebsd-current@freebsd.org Wed Mar 15 21:18:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82A0CD0DE5F for ; Wed, 15 Mar 2017 21:18:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2A41D46 for ; Wed, 15 Mar 2017 21:18:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5B95AD0DE5E; Wed, 15 Mar 2017 21:18:56 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B39CD0DE5D for ; Wed, 15 Mar 2017 21:18:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3831D45; Wed, 15 Mar 2017 21:18:56 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4B6CA6681; Wed, 15 Mar 2017 21:18:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7C7BC21EE; Wed, 15 Mar 2017 21:18:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id d7e-FF_wiS74; Wed, 15 Mar 2017 21:18:51 +0000 (UTC) Subject: Re: Apparent build race(s), r315238 -> r315298 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 764C121CF To: David Wolfskill , current@freebsd.org, ngie@FreeBSD.org References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <804688dc-2ddd-e199-8720-5f7916dbef67@FreeBSD.org> Date: Wed, 15 Mar 2017 14:19:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NpoVrLg7B1hqeAWhuFogbrecawEBcqg6J" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:18:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NpoVrLg7B1hqeAWhuFogbrecawEBcqg6J Content-Type: multipart/mixed; boundary="879RQV1hFvuhEMw1qoBWuNqib50owdEw2"; protected-headers="v1" From: Bryan Drewery To: David Wolfskill , current@freebsd.org, ngie@FreeBSD.org Message-ID: <804688dc-2ddd-e199-8720-5f7916dbef67@FreeBSD.org> Subject: Re: Apparent build race(s), r315238 -> r315298 References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> In-Reply-To: --879RQV1hFvuhEMw1qoBWuNqib50owdEw2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/15/2017 2:10 PM, Bryan Drewery wrote: > On 3/15/2017 11:23 AM, David Wolfskill wrote: >> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >>> ... >>> So where is /common/S4/obj coming from? >>> >>> Is there a symlink involved here for /usr/obj? >>> .... >> >> Yes; I've had /usr/obj as a symlink (to a different file system) for .= =2E. >> a couple of decades, now.... >=20 > Ok, I don't think the symlink is the problem. It's just the meta mode > handling forcing a realpath(3) on some of the output which causes the > confusion. >=20 > Still looking... >=20 >=20 This should fix it: https://svnweb.freebsd.org/changeset/base/315332 --=20 Regards, Bryan Drewery --879RQV1hFvuhEMw1qoBWuNqib50owdEw2-- --NpoVrLg7B1hqeAWhuFogbrecawEBcqg6J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYya/RAAoJEDXXcbtuRpfP11wH/3oT49CZjDMkQGYurJIMR4LO XRwP+5Q6q2YHYuQt2eNMcSD6ULX7VmmVidBxvMNiTVLqAAgZX3jP7AsNScguN76I fuKR/iMrl5rBXHhvb1eRFR8uFUkQ6ynoxp7I+ok9RhVniQhFsiOx6B57rpLJAnKU cW2bl3Oscml6Gvx2PLWw5VCv3XcHsie0lRWwX41+kDvFXChRhN1ZlQ/lAghQ8W9Q a+bNZauKRgQCXcaE7zgUEXXxrp2WTM5lZE3nE3RM1b0mlxaUI9gpnShx/yrYJIW1 O4sOLcJQt3zxbcQLN1UwKVY+EHLG31pw/8zytcyf6Us1wdd+uTBv3Z8N+FYbozI= =OaQD -----END PGP SIGNATURE----- --NpoVrLg7B1hqeAWhuFogbrecawEBcqg6J-- From owner-freebsd-current@freebsd.org Wed Mar 15 21:42:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F907D0E5B7 for ; Wed, 15 Mar 2017 21:42:26 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id DE2321CA5 for ; Wed, 15 Mar 2017 21:42:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id DD503D0E5B6; Wed, 15 Mar 2017 21:42:25 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCE85D0E5B5 for ; Wed, 15 Mar 2017 21:42:25 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0136.outbound.protection.outlook.com [104.47.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68D661CA1; Wed, 15 Mar 2017 21:42:24 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L6ccHrligsBqm8nnVhZgkIkVQuGC1suo3hT8RNCohaw=; b=LKvTs6npOTQJKhAKAyaE5r8N1eB87qiEftvdegQUqCGDGHCPIi4hlkNFF407lqznr96l+HWZHjyKSvGloPEVyw1kQk/w89dF2Kjmb3yBme+Vc7kzVIyAv1gRhijm/05fr6CA0OrSPHUTQr7kj+nJx0zwPhaAXmcJQvKhu6DoCmw= Received: from DM5PR05CA0019.namprd05.prod.outlook.com (10.173.226.29) by BN1PR05MB309.namprd05.prod.outlook.com (10.141.63.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 21:42:23 +0000 Received: from BL2FFO11FD015.protection.gbl (2a01:111:f400:7c09::154) by DM5PR05CA0019.outlook.office365.com (2603:10b6:3:d4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Wed, 15 Mar 2017 21:42:23 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Wed, 15 Mar 2017 21:42:21 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 15 Mar 2017 14:42:20 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2FLgKfi021761; Wed, 15 Mar 2017 14:42:20 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 4440F38551F; Wed, 15 Mar 2017 14:42:20 -0700 (PDT) To: "Ngie Cooper (yaneurabeya)" CC: David Wolfskill , Bryan Drewery , , Subject: Re: Apparent build race(s), r315238 -> r315298 In-Reply-To: References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> Comments: In-reply-to: "Ngie Cooper (yaneurabeya)" message dated "Wed, 15 Mar 2017 11:29:11 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79320.1489614140.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Mar 2017 14:42:20 -0700 Message-ID: <79322.1489614140@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(54094003)(199003)(24454002)(9170700003)(106466001)(81166006)(189998001)(110136004)(107886003)(6266002)(117636001)(38730400002)(50466002)(5660300001)(93886004)(6916009)(9686003)(55016002)(1411001)(6246003)(8746002)(2906002)(8676002)(2810700001)(7126002)(47776003)(2950100002)(7696004)(8936002)(77096006)(46406003)(356003)(76506005)(76176999)(97756001)(229853002)(53416004)(4326008)(105596002)(86362001)(53936002)(50226002)(54906002)(305945005)(50986999)(23726003)(39060400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB309; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD015; 1:TvpPwsDc2ozXzL0u/AuEartbP6xwSeX33JkmZPPm9wW2vLO047kLYuc/33VsJJyjUF+2Fh5isofo8LhMdE7LAYPBtFIR6xWKY2gN/XDsIcJVatzud72/n6uesZhNRAEOAzjjyTnvrdnbvLxS6cmhM9kF/udXLK2JvOpS0y9QL7Wv/roAV2dwcXhKOzJX/UWehtxJV5rPqaWZYchInFejuMHcQAyXu/ewrsBQlfRbkkwuzHriKJqEZXCcSC5pwetBhS8EnSfx7vJEyOYJvraLWW3CSYmD+S3zwTjUgputvmgQ4Gch5Rfbrj++8NE5aBE7aGs1Jn082+5TeXMI8uRoQMCWJme9rNHz1glsLuNKaZJwHZQsCgB5xpwknk/RPAoFzXalk1wlG4rXPNkGreE1tJb7TZ/KVNHLD8MGwGzWNto78f9txutKgXlM6q3fXeA4D7eEFdQh3ibnHR1BAu531w/TLqjKRCg6qUWUOjuHy7GSH4IQDdQuGMx6WMx/IWJ5I06JUpB1BEzSgFJ2RKpy2aeFUJ+US91WQ04IkZI0btoUQTLwQDSEtWVcLFMlcLjlQxTZRQjqBR7UB2I7qmx+Ww== X-MS-Office365-Filtering-Correlation-Id: bc6d006e-53d4-4ea3-d50e-08d46bec29c9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 3:K1Y0b5oWc5CcyUW59LRTFX/bjz0S1zcfcGd0U6sBTY6FW0+9MuCt1y2/vrAYRMYzG5/gT6gEyAqbzDRDKNStiSu4+hGu4x6TuEC0yuBfQ8yzdA4tuW8T2YndF1TLwQQ067X0gXJfrSBnmz9Gblq44dbq+EmE0JK/3a+G6YYChyIytLQW0vA+dzcn9SGrJKT/T94HGboK210Gr4buSo4B7McuycH7X0hP5FmTLR8YZUCelFy5SMVoA4chmONzo2wYF5bRAaUNI2vMYpWbT4hWpzoMUICxWvQm/r/4xkktSVgH1gcAchdlriJNdFl9of5CYTqFvnyYi5EVo9vTwU12ujkax8HGWGzHN42tYGPwpEfwEM2iXwkRkwbav5pO2JJW; 25:d6SNNbCNPkI22n793VxMLPZrArtTkdErWKN1l+Vtc43/AATi3XQK1hYLx8N5sz3i3xK7jwtoA6cfo7l7Gn0kb4+2AfCjD6JrSroD/c/duyAiAk1aAP0KI1zKnmuTCsU4OmYORgYwaEAndUdI8Y1TtaYgmxFmrPvPuPfa/BAiuCrsuUyqRzHvJ/fVK1mjdU2tnZrw7fGVc7HrYNnzOYfhnw0h2uw61Js0JxIGpjOtxv8tr+VR7MEqgllFlIgaFKXy9fPp7spZsIW69p9x2uefkH2eZr7FVqNm3ySOJN6bbDHO1GV4m00IRrRZf8HjDVooWO8XzntDBR/6sheUQ7UobvEWwPTYZO+XLgR6vGHFDUdLgH0jzgTL9r5o1yr+ohfaWHh5pBHhsbuNE3ybgUwGYsvaoaoC5tI2jLMg2lR88HedX1cI25d3X6bJbydeLynZ54fR75aAM52OEeqhrcAjYw== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 31:h8L0JWtbaKiNuyGfNQ0z2d6ZQ4thg2sxmcnTNilGp8GN0Q/7B4Hfz9Hcx6vME0+sn/xXk6bwMGSoVQJYqzmWJc+AuqKGq0xNArMa8gMc0TKKq9536YoEEnjqkLTAZ3/Q/B73R+1C5KO4eAAOGDoa4lxxGBE6pg/mW4jzw6ZOE7xzpPY1GI6rOXE+LVyKSW9RuYIOEw/2Es5+KHP0114MTlYIbV6GfWz6S1jq7Ug0b6BAMoPOy0us7exG4Votsgs9ZMZ2MAK0zPpL/zNZrL+NYQ==; 20:frb7OKw/RHT3MoK4HKKIcpBjtdZ2C0uzJCzBaBdbAQSu/YfcEKp/gkrKBe/rPj8Cq+G5qEj4IvvSVfxqzHJCrLotN3Ewl7d2k9R/XvOrE8zIe/u1iHEk3TUCC0caO0Ynkhrw6Z1BaRh5i2ZYhn0hgAxlFeWuEVC1ICfbo2RlAk4Sn/JMeeEnKy6TkwtUz/mmFjJv2DkFG0OX3I9B0hikCP84UGp6RnBhUtiGQ1bok0pN8s+AREnthoRPx+4QuJwA4C76NCjAtA3whu0vj80kFJ8E/FLDDNBgu7QOpeJwsAJzfm7qbr7KxzoI6F/kBAZgz7ikQOYf1GG175VyTQrYImQnx0/qztHr43H6nztEIY+fsVACAzbNNf4XoUbBLVpUFBrnhKjVTgKyykLvGrOAKqJVQVL6rWVPZN5K3CMw2JUQrzGLMeYDT6EHs2rM38hamJpN9xJFlsRwIBp4UPzrwMySnJA034w+19IX0rOh32Yb0I3Bnv9j0HyHuQWSXI0e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13023025)(13024025)(13015025)(13017025)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148)(6042181); SRVR:BN1PR05MB309; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 4:zaMK/0IAEET2kks0YCXJnFU/nZ75jZtuy/hdq6XsO4Iycz7Ilx8UdvU42yZuVl4khJsgcaro6txx2JHw+QnQklGT+XGgv0y4huV04K4iq6PlJew9tEXdIfiOzwQen15FMSSNYcmUCkmPCnCrxHpP5K03WsvucwdrAyyAJXNBF9aB9eYbqa/wSnSRyq6EDFRznvTY2OR/r8xFAgZy3ylUd4MJY+vFa7uzGLPs0wj2uGT+B2E+obee+NdINEXgbFDQEP/5MZ7B4CGmj6Oh/rKSL8DJvFsP9q8YL0ENwDlmx5D+SlKlYpgs2qCPaixdJDed2ILEK6htKFXhjwgyiosQEnPc5IVAF2fA1LtG/3DkC2trI4PtDVcYMXp+10jpOpAiDU1I1Hkjj0Ll9iM0Co11SdT5JPPXeykPTBeWDy6SWzXz98dhNw2L1fxMNOrHxELi55ahp+wkBXOA7aOCPX4Wg9AizXgz7nN0qwb2G9l83NUHi/J52I22KbXkU0ItiK8nOjGYC7HatWGnq5Zlg/I2cWIle0IOOUmQ3nINhLo9vANchU6IIuz1HQHDxrcBv95zrk/CWKzsB7oA9YSQ9m61bp19r8d2YFu1y2LD98h7LkMF8aWlpRQo0yShoVGv8SLnkk1Fsc61sUcq6FWhnByFe3KdfOu+MCZEw7TvWsLnh84fS3nHksw6zWbItNVJHk6Kq3O0HwRuR8SUGhZvSG2hMjVmWNEg+Mg0qHQHc4l58kY= X-Forefront-PRVS: 02475B2A01 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB309; 23:XQs1F+MoS3emEvrYWMB7eRdfe0WwOb/pXvgYa4+yOV?= =?us-ascii?Q?Qvpv7pbb7N5Cw95qzZv0o4wjZyoajjUvuNQTFD2jw3s+nDwUWxL4Cswtnkt8?= =?us-ascii?Q?63y/g9qUGnN/8kaZhWeU95yXLk246AFH2Oo8l/JMRP279uzStIfbq9m3uMKu?= =?us-ascii?Q?rtPG2jtMaq6xzZtPM1yNo6TwRqV9QJuJ1m+hYPJg/r66KpLtR7e7+FMktUfi?= =?us-ascii?Q?eQSa6u0DNAeS5KFIldI4vFt09JAC5+8EnSclI8K5niA5xFGk8OSpMwqbUqca?= =?us-ascii?Q?YpWQY1OMkDNVKOmxJpAyOaLoTpJADoHCZJOqNRHtVpOl5mv6N/HiXcwIXGTA?= =?us-ascii?Q?V/GcEo8ijAVgmhGjE9RtESVutEuwh0VCP8VMvC8fhIwRXqdAKi98JHWCiXqn?= =?us-ascii?Q?La9Mwq3z1Ci/a5YhYRt7IcR3b189mbDLovjugq47RifUIovVDJJwrdWH4OdQ?= =?us-ascii?Q?O/szEt7InGpPpmuxC9ldLm8A3PZga3imD3PSoI5y0mKlVI277dvzn2gt2/ic?= =?us-ascii?Q?1EjOWF7tQSNqzNtkmZYWx+kxDyQrz6iw5KZjcBcqgz6sRjQKc7LdwbC/D6Vq?= =?us-ascii?Q?sMpkCuriWhNEMPXsGlJbeDRCiutQB9uWacajJQEvrAQHDOXzeyAGiXn3kZrZ?= =?us-ascii?Q?A/8wgZIuvfdlmTqd43m9mMlZbmYLvhhryESFPpCeggZhMVB7s490u6R3o3lK?= =?us-ascii?Q?m04/ebadNeDlWfWxBe6a25CPq9WekSesXZXfMpyj39Yb+pkXLXlgJRHzJVHY?= =?us-ascii?Q?1VPr7nAFS2w/dxD9E1ZVGuSrt9qb9LmrjrHOVahbfEncpJBm/ap2tDnD2bGX?= =?us-ascii?Q?p4S8bkcCq6EZgi8Yrro/iBS5hCtGRmc7xcxSfnMdCRq2kMgSSJgBYxRZcdZf?= =?us-ascii?Q?AgtNmKzqtu9i+aA06B+2q/7WPiEJapJ1I0DpNDacsbNCZ1R62hVrlbvYQerB?= =?us-ascii?Q?ZtdhgbSoCm5z6e8NTt6PPjC+MkaIbMT9wSPMXwk7pEOB68jCk/BSehD/bB6l?= =?us-ascii?Q?WCPqzTzsIWfTaJdiN4ec5G4YtR8jVdAhMPxExjGV6rWXaw4Ab+P5k7VzOzmi?= =?us-ascii?Q?pMMaclS82P8xb3c9K5Hpmeg23IHRHFW/cxPXgnOTLbG7jHkvI+WifKCvwzhg?= =?us-ascii?Q?wKGLPBpn4zSNQTIm0U2mtm1GGBJTl+iD8D1nhur8TFI5hMoHItdIGllNkH1v?= =?us-ascii?Q?vOmgEtVWQQKDUIAL/nLUKZw02M1t3lKtDjsf4qoGePaoM3gXhaI1QGqQ=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 6:uuI6DM9FY4rVEy2Z2tORTFvEOYyTrJn/Wu3HNYnksgC0vm94xkjnnllTf+nSROvkauvai74dy8MtLetl2NXUgm1Mu8BnSs5lTVI8gLwVqE5C6BcStmlk6aTrQWQmEC6RaicL8KpgMBNGbvlTrk0gfJH6zrBcbNPOhzf4c+Q8R4lQ5Ni1M8CQgQ8C7q9vM+BCYWzrqDNcUnn8FY3pY+nnxEfqtTrQjmgHayeCkLr/KrZ+f4CVVSxVBjGU1JchlEb8mcppp8p7BC1/33gO7DCA9WNHjyp/yPt8GRD9P/0gCn94n1c37a+P6hR8AWYCwRqgylcbxv6g3i02s55RThd5cg5njUMCyOSQZhGLQbEnfmOlr8rGbyzLjy/whtn/9XNQiy33WDHAWGQSOewWDq+Vk3z1qWRZetF2gKbYGeRHSRY=; 5:U7diRPuKA+rWkaohC/8k7bRglecShcrp3i0I6B4chf/OchYVFmrOIFzbF3L4yFNNy/JQcuOAZWvJM5yAR4IHv+pb2aju7Hl/5cst/yECBBCTpd4+iQw0R7oSdS0pxY9h6UUinJ+XHtAAV8Ar1us4ew==; 24:xDrhcd4qcaN3tdoZfa2RIFfbVs3IiXzPI+6R68bV90YhAIePvutC8FgITpVI2d2kskEtGQC9uAkM8Xp6+Tirg201UhRERZBh+ufn5NIP/SA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 7:4dINgmOtTAKc4jZFCV1JhVaeUfl7LEBt186NAgFHWMqlyKaIDz0FY310+mNb7STcRE1CkaG6IJz4pDf29pA1wzIdSUgKWb7jfjprFyMqZZven/UdTJRWIdi8UNskRmbtadY2j0E8YZTBaxpz1u4FzJlOuqRJQiepyFDcoYRRRrgnJ6aranaERapsqsI+Ts4b2HbxrGGVS/7YscxNoK8yEblTua72EikJvnDcV7FRsBrZd7Ha04vTWKXgf5Wb4q49kGfmbdfZWwDellQ9C0Bc1/ItimJM6F1OjjwG/SGcZ9YFh5YEMqsqveZ2CMMj3U6TWddX8jzISNWbALfMdS1FiQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2017 21:42:21.9729 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB309 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:42:26 -0000 Ngie Cooper (yaneurabeya) wrote: > Alternatively, could you please revert just r313650 in another branch/wo= rkspace (I wonder if changing from .OBJDIR to OBJTOP had some unintended c= onsequences that unrooted issues with how bmake evaluates paths)? The only change to dir handling in recent bmake is handling of -C where arg involves symlinks - provided that refers to same dir as getcwd, the logical value is used. From owner-freebsd-current@freebsd.org Wed Mar 15 22:16:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6142FD0EE04 for ; Wed, 15 Mar 2017 22:16:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 40DFB1AE3 for ; Wed, 15 Mar 2017 22:16:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3D4FDD0EE01; Wed, 15 Mar 2017 22:16:47 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B00CD0EE00; Wed, 15 Mar 2017 22:16:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2CC91AE2; Wed, 15 Mar 2017 22:16:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 2AFDE6F20; Wed, 15 Mar 2017 22:16:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D0B182587; Wed, 15 Mar 2017 22:16:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id RgW5xaXGOk4k; Wed, 15 Mar 2017 22:16:41 +0000 (UTC) Subject: Re: r314708: panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 211022582 To: current@FreeBSD.org, "freebsd-net@freebsd.org" References: <3c8062d7-afcc-44eb-1c05-f32c2b49973d@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <720c92be-ca1e-7973-5a74-38205c4c99c1@FreeBSD.org> Date: Wed, 15 Mar 2017 15:17:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3c8062d7-afcc-44eb-1c05-f32c2b49973d@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFNfRVf9fqe4MaBPRIg7pesFsnqFCCTOm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:16:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nFNfRVf9fqe4MaBPRIg7pesFsnqFCCTOm Content-Type: multipart/mixed; boundary="XvmgFo0toc7WlVl99w7AcuHlSRJuhAhAQ"; protected-headers="v1" From: Bryan Drewery To: current@FreeBSD.org, "freebsd-net@freebsd.org" Message-ID: <720c92be-ca1e-7973-5a74-38205c4c99c1@FreeBSD.org> Subject: Re: r314708: panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241 References: <3c8062d7-afcc-44eb-1c05-f32c2b49973d@FreeBSD.org> In-Reply-To: <3c8062d7-afcc-44eb-1c05-f32c2b49973d@FreeBSD.org> --XvmgFo0toc7WlVl99w7AcuHlSRJuhAhAQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/9/2017 1:31 PM, Bryan Drewery wrote: > This came up at shutdown in r314708. I don't yet know if I will have a > core to diagnose. >=20 >> panic: Assertion err =3D=3D 0 failed at /usr/src/sys/net/iflib.c:2241 >> cpuid =3D 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe34= 9a7f9940 >> vpanic() at vpanic+0x186/frame 0xfffffe349a7f99c0 >> _kassert_panic() at _kassert_panic+0x12f/frame 0xfffffe349a7f9a40 >> _task_fn_rx() at _task_fn_rx+0x19d/frame 0xfffffe349a7f9b20 >> gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame 0xfffffe3= 49a7f9b80 >> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame 0xfffffe= 349a7f9bb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe349a7f9bf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349a7f9bf0 >> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >> KDB: enter: panic >> [ thread pid 0 tid 100038 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >=20 FYI this assertion was removed in r315217 so it's effectively fixed. --=20 Regards, Bryan Drewery --XvmgFo0toc7WlVl99w7AcuHlSRJuhAhAQ-- --nFNfRVf9fqe4MaBPRIg7pesFsnqFCCTOm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYyb1rAAoJEDXXcbtuRpfPWrsH/R/Vw96MVMrbkQWjuVh9TBfy VDQ0NIA/L3tWDRmBQ2uczCLFHiG+5dFocgnEvpPczFsurQ3vvsEGjh3B1k0IR1qY E/mMhEj7nKWS8e2SINZoyrkBqbDfsqtUdmxHvmuvLxEvCV30FGll0j2bPL1VrieA nit9tikfHlzXFK/W0nR/BHncdxTpAOqnEc0wnsK6LXi+DeoYpSglux5y+he2DQam FRWS35b8DGShI5NOJC3Hb9VhivMSbHHNrtnQhhuOKMJA6Y/1GjZircBgd5OjdwpU 79zqNRW4KG38Ijk6fB30IYzjtOUFX/kMVK5v/D8RZ6KbC5epwLtBjLm5i0Acaeo= =Pns6 -----END PGP SIGNATURE----- --nFNfRVf9fqe4MaBPRIg7pesFsnqFCCTOm-- From owner-freebsd-current@freebsd.org Wed Mar 15 22:40:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94704D0E689 for ; Wed, 15 Mar 2017 22:40:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5441B99 for ; Wed, 15 Mar 2017 22:40:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6AA87D0E688; Wed, 15 Mar 2017 22:40:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A4C7D0E686 for ; Wed, 15 Mar 2017 22:40:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 341801B98; Wed, 15 Mar 2017 22:40:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id v190so14963659pfb.1; Wed, 15 Mar 2017 15:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9PEv5nXPc1OqPmou4xL4++mOz+Pr/iOUQ1buFDYhG/g=; b=CcUBqBz4zONNEhDjKK6vr15kaPllTASvSvrekG4JDzQI9u+3RDMpepaMTapz1coX+N pvoG3mpXtEpMzscXG7j1OhvYsZdCQAuRDmSc4sEYiv+mVB7ggUSdnzsm9W1QmrV4EKkQ 5DEpb73rrs/+PcT0us4zGAbISuCSrQaJaN1Lxw0kXUJaz0iBgL0nwLoOE59yLuBGsD1S 7BbvY9G1dh+bRe5ycJJHG8eLJmGReLQquVesTIaj8E5qS+sv/C0vi6lChsOaOAhS+ceY 6NVrf2C4gvvxSd+J9HOUbBJ3LHjKtZ2fbBIdQu3ORsr2VljmcbHFQd+ls3Njhl2dy/lj qw9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9PEv5nXPc1OqPmou4xL4++mOz+Pr/iOUQ1buFDYhG/g=; b=jDQjzfuUugTW5PFIIu+h4ZuOISOcPyzomAKomoPVJ9MPsyEdj/o/LKc9v1c9e7PG/I z1N+rwikSK/3I3P7ViQssp//auKGzf7ko3x8qrHeE6TlGfBg1/OahSiVDEItb0x44X1R yU9sgPnwmxQ96w/miVLbslX8nbwBWI6Pmc2it46Dr03RG5eOAku6XVV+A/8tNl31tIHU ROzEmkhSQ8dJ6S8V/wTeD7QYi7wGLoWA7sYs4ZN2HdkGGeoS7R7LVRUscQSPqtTfJs42 3FkkHom3LJUFx1kRK9MTI6yN4wLyGGmA3tZ0Lt85cLcky32v9Wb8euwkYHA2u6ZLnfPk 0VBw== X-Gm-Message-State: AFeK/H1s1AJrAJtFPbghhoA5XluzUNm40rLYGMdXMmAD04TUtjLJHtf0EBTfyYL2hPsaTQ== X-Received: by 10.98.166.132 with SMTP id r4mr6252864pfl.191.1489617644485; Wed, 15 Mar 2017 15:40:44 -0700 (PDT) Received: from fuji-wireless.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id g64sm6182187pfc.57.2017.03.15.15.40.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 15:40:43 -0700 (PDT) From: "Ngie Cooper (yaneurabeya)" Message-Id: <3C834EEB-FCBD-4FC7-8262-997CD44DD11B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_47FEDDA6-F08C-405B-8F2B-BD6B3A6464FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Apparent build race(s), r315238 -> r315298 Date: Wed, 15 Mar 2017 15:40:42 -0700 In-Reply-To: <804688dc-2ddd-e199-8720-5f7916dbef67@FreeBSD.org> Cc: David Wolfskill , current@freebsd.org, ngie@FreeBSD.org To: Bryan Drewery References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> <804688dc-2ddd-e199-8720-5f7916dbef67@FreeBSD.org> X-Mailer: Apple Mail (2.3259) X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:40:45 -0000 --Apple-Mail=_47FEDDA6-F08C-405B-8F2B-BD6B3A6464FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2017, at 2:19 PM, Bryan Drewery = wrote: >=20 > On 3/15/2017 2:10 PM, Bryan Drewery wrote: >> On 3/15/2017 11:23 AM, David Wolfskill wrote: >>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >>>> ... >>>> So where is /common/S4/obj coming from? >>>>=20 >>>> Is there a symlink involved here for /usr/obj? >>>> .... >>>=20 >>> Yes; I've had /usr/obj as a symlink (to a different file system) for = ... >>> a couple of decades, now.... >>=20 >> Ok, I don't think the symlink is the problem. It's just the meta = mode >> handling forcing a realpath(3) on some of the output which causes the >> confusion. >>=20 >> Still looking... >>=20 >>=20 >=20 > This should fix it: https://svnweb.freebsd.org/changeset/base/315332 = Yeah, that would do it >_>=E2=80=A6 Thanks, -Ngie --Apple-Mail=_47FEDDA6-F08C-405B-8F2B-BD6B3A6464FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYycLqAAoJEPWDqSZpMIYVEioQANOnIdsDQjBsDzzOxHAE3cPM GSU4KGMNkSOtCETnzbh8HEJKH+UjldRtjF5+wU6HOhcf00vwhD37+SKeRQwDnSa3 QvAMyBc5fsEdbLV9hrZl1eO1wYZzLESGBmGNQlAwsIIvbo2CZgXQbqCEqjm17FF7 k+5MD/Q8gjxRR4rrkXIhejygxugL+rnJKRPq/sd6wPX+84g3hQztg3dYaycylWVa F0rWU9iUtiN1nzKSSvqE+W8NMoVdoO9COy/fALuroPYqltjhZpFq15JZhh6fuO27 Kp9sOyf0toh9X6kArYNzKQNnrHrmbXJknFyhNeWyx+XsqEWsX4uCnJVB0FQp9mUw YElKUa41iLXSDU0/pHyQIK2qaLn2YOx1CmSGqeqRQQii4ld51dqa5aV8azdEK6/n 624gTSr+T69WioE1BicOy4O1VSom1mTiSStZOyDFzvHUTUJKaS/Y2QKcxG4H/E0M cvNepOuy/jT+NIsRb/YJnqVGrQ8WkydmrxxlcwJeP58K874Qc7uoXGMF8vtBc1Wv OHAvO3RN9Tpw+tp8HOW7qkfQDTaNx+kjZzBB5PA+HKmyp2O+A00AtlME5GbPTO5e sQDXHrIn2pnt96+v6G7D8M/C85hSzfZXJeBnVxYH6ocat0Gy93Dghoe4It2usjWn uwqJyGOTD0/V23oCqEl9 =sGb0 -----END PGP SIGNATURE----- --Apple-Mail=_47FEDDA6-F08C-405B-8F2B-BD6B3A6464FF-- From owner-freebsd-current@freebsd.org Wed Mar 15 22:44:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D854CD0E8FB for ; Wed, 15 Mar 2017 22:44:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BEF8910DF for ; Wed, 15 Mar 2017 22:44:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id BB782D0E8FA; Wed, 15 Mar 2017 22:44:58 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB1BDD0E8F9 for ; Wed, 15 Mar 2017 22:44:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 04E1510DD; Wed, 15 Mar 2017 22:44:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v2FMitm6054081; Wed, 15 Mar 2017 22:44:55 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v2FMitj1054080; Wed, 15 Mar 2017 15:44:55 -0700 (PDT) (envelope-from david) Date: Wed, 15 Mar 2017 15:44:55 -0700 From: David Wolfskill To: "Ngie Cooper (yaneurabeya)" Cc: Bryan Drewery , current@freebsd.org, ngie@FreeBSD.org Subject: Re: Apparent build race(s), r315238 -> r315298 Message-ID: <20170315224455.GQ1341@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Ngie Cooper (yaneurabeya)" , Bryan Drewery , current@freebsd.org, ngie@FreeBSD.org References: <20170315170446.GA1341@albert.catwhisker.org> <29bb3168-7c3c-8954-4f39-d3ab544ce33d@FreeBSD.org> <20170315182315.GE1341@albert.catwhisker.org> <804688dc-2ddd-e199-8720-5f7916dbef67@FreeBSD.org> <3C834EEB-FCBD-4FC7-8262-997CD44DD11B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qsJIsz+CuDui6lgL" Content-Disposition: inline In-Reply-To: <3C834EEB-FCBD-4FC7-8262-997CD44DD11B@gmail.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:44:58 -0000 --qsJIsz+CuDui6lgL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2017 at 03:40:42PM -0700, Ngie Cooper (yaneurabeya) wrote: > ...=20 > > This should fix it: https://svnweb.freebsd.org/changeset/base/315332 >=20 > Yeah, that would do it >_>=E2=80=A6 > Thanks, > -Ngie After hand-applying r315332 to a head@r315298 set of sources, a "normal" (well, in my environment) build completed without incident. Thanks! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Claims that lack evidence are not a basis for rational decision-making. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qsJIsz+CuDui6lgL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJYycPnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XincH/RXJk0wJOfjlhnOefImU602S xvHyyHpQ6xIheXBVqKvi+hdsKdi3dhgy7oakYLQLN2E2S4fB1AHyQC4XkSL7iti1 rCkBTMLERnn/ZsiQExjNZbKT+M9DMZF4qMr37Nbsj+ggucEMpNUxHNkg3SU77BUM LA+e3RINBmhc4lUry+ugWH3p6nN7Ze0/x0d9JOlund7DA2x1hpO3n9HmMDEbV4vR NuD9fDo7yTZBrc85xJ4LFUclgiOgMZfLFywNwuwKrm6NVyNYK3rlHSa0MQ5K4Mru 94MhdXm9a+5zC9ikHlHKJ6ZsBv3CvPxZOMDhafUZqz91BUkTLfi1Qoo3lSXbuZI= =xQtG -----END PGP SIGNATURE----- --qsJIsz+CuDui6lgL-- From owner-freebsd-current@freebsd.org Wed Mar 15 23:05:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7003D0E1B5 for ; Wed, 15 Mar 2017 23:05:51 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 A880F1F49 for ; Wed, 15 Mar 2017 23:05:51 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id m27so75438685iti.0 for ; Wed, 15 Mar 2017 16:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DjmTwGmhyJKsK3zEcM3qPIFZsjtFacmEXSN7SSsYY2Q=; b=YB8nXfVx0ifFeOZ7VUbQGv/Y839ss806K8P8gdtQdAM8uynDuPRK6FG+UUdPS0wrJt h3jQR5TZQkFIPZw0Ph09wDNfY62u5WkJ0knSHAy+lYcPa8xDjIeQlmOZuiFuYcUddmg/ IXgrNB9c2WwbzEZ2keMFFL3vToqWlJkGLRo0ddBuap14UX0dp+UDAgCcOx1Ljge9r/iU iDU3/O8sXpovfl7URO5uukM5ShN7+IEFnBkyCMOMm8ZDNjgYvrEetweOYbeX5WL8ZgG7 hJvhcN0rt5UVZLgqm9zIMRR8YovO60K01V1e4uGQRKmwIGoYKcd2ezwhhRsGFjJr1BzK 7xwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DjmTwGmhyJKsK3zEcM3qPIFZsjtFacmEXSN7SSsYY2Q=; b=RdP/gZnFSMbggnZa/800ixtS5BwZtKAl6LF0D52AxLI5sRbWkS1GIW4XUY5c3H0soV sskb+JvNpUGoQXHR+kxA8rH36V352ULKwNHmQ6wQv9GoqC9ED5gJuTqrtNFk5fYbpFNL +Icw1yo3aefB5ly3/uvO58DX5dzzzYJDY6dwdrvEPmQ1oInOv7g1X91rUxI1uUoiLx/b 91gcK3LWuxr9DKWROT9n1HrsDnQCPSw71u0QG7fZPtkwbTSOXdt9VDplP1jA5GRcaPW1 /ZhHPaFmJAsBrp7HE3pAD/pYQSCscHsnJ2rWd/AenLykDW8KoWOZfJ2f6s/YbRkRA2ws wk2Q== X-Gm-Message-State: AFeK/H0UNYjGfi+kKG3mMdXfMkfba2zmZBp8IlKQPNxEvPwGo8M8kjlPbaki2JGA8QKkZRrNbqdfnJSOkJmCzQ== X-Received: by 10.36.197.132 with SMTP id f126mr3314702itg.117.1489619150819; Wed, 15 Mar 2017 16:05:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Wed, 15 Mar 2017 16:05:50 -0700 (PDT) From: Roberto Rodriguez Jr Date: Wed, 15 Mar 2017 23:05:50 +0000 Message-ID: Subject: fail world build To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:05:52 -0000 Hello, buildkernel as of r315323 GOOD buildworld FAILS: /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, -1, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of undeclared identifier 'PCIS_ACCEL_PROCESSING' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of undeclared identifier 'PCIC_INSTRUMENT' {PCIC_INSTRUMENT, -1, "non-essential instrumentation"}, ^ 4 errors generated. URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 315328 Node Kind: directory Schedule: normal Last Changed Author: mav Last Changed Rev: 315327 Last Changed Date: 2017-03-15 19:49:45 +0000 (Wed, 15 Mar 2017) Reporting live, :) -R From owner-freebsd-current@freebsd.org Wed Mar 15 23:44:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41D44D0EC81 for ; Wed, 15 Mar 2017 23:44:33 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 0B82012F5 for ; Wed, 15 Mar 2017 23:44:33 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-io0-x235.google.com with SMTP id f84so31396635ioj.0 for ; Wed, 15 Mar 2017 16:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Mc7b7RPGkylVbTtQf112vzOPlOcieUeBpjuvbKQUcBs=; b=XsqctwCJQTeXO0FsHzrsw2GEs2AXngW818XImNXTD9R83d0T2pgIWYhyfw6dSRBq+U rE683WfN6UaRnfOfBASNGZpYRGll+So6vjnI0y8EFqQQWmqrFYzsiTtB0urnJE/1Cgo4 NB2wDCR0QkKgPehyayxd/OXaryq4HBLZxnh2lr5jUQAmSQrUMeZGMunUNd/BqfmMNu2B 5Ajlv09vddXrD0+fHIbx67I01nN82r1PYGnHMTZueT61eDK6yF/9trNfrRsCyN/1dahk 3Mvvf0irUKjkz36ObZaAR/+A4oYxk3dh4vioulVLql7Qcw1BG7Q7ygBqZn522+gseVHD r2xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Mc7b7RPGkylVbTtQf112vzOPlOcieUeBpjuvbKQUcBs=; b=gyXYakyc+5lWx7tUpPzvv/JdH9TgSzckl0fX0w7LXJCGiLjoBOwUhQWa57G3uk5w3j XZ9+iYQhFlR+ZO2KpKtRmHzDn40c/aM60MwbPxBmUNW54SEjRkmHsOD1LI+DJAai+ejw 6B4EgCKhfRYd9svwXNYJrJgjwblxogn+M+mZbFFQS1ZSjBGDGpAtOqV1dQw21s1zZ4PP LmnbW3pllWrRzc3S9EIwjaYww/a+0WF8BvN37F/TJ5iVgbXYQ2ulbBgKc9Ok2b5+ImBB m4ifuIGMqh9fBWBisdra5BEpYRADPeGFwNgTWOlNQab46jCR5bWYdiOGvn08npAX3ANB +aCg== X-Gm-Message-State: AFeK/H0uj2ou3x2V13rdFiliUHA/boYYTfi0zP6uCU98iyu448af3PmtlkEqrfikdiF6hR63nwuFkj45sHUt6g== X-Received: by 10.107.63.135 with SMTP id m129mr7738779ioa.149.1489621472350; Wed, 15 Mar 2017 16:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Wed, 15 Mar 2017 16:44:32 -0700 (PDT) In-Reply-To: <20170315230723.GR1341@albert.catwhisker.org> References: <20170315230723.GR1341@albert.catwhisker.org> From: Roberto Rodriguez Jr Date: Wed, 15 Mar 2017 23:44:32 +0000 Message-ID: Subject: Re: fail world build To: David Wolfskill , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:44:33 -0000 Hey, r315336 --- pciconf.o --- /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, -1, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of undeclared identifier 'PCIS_ACCEL_PROCESSING' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of undeclared identifier 'PCIC_INSTRUMENT' {PCIC_INSTRUMENT, -1, "non-essential instrumentation"}, ^ 4 errors generated. Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 315336 Node Kind: directory Schedule: normal Last Changed Author: jhb Last Changed Rev: 315336 Last Changed Date: 2017-03-15 23:08:11 +0000 (Wed, 15 Mar 2017) From owner-freebsd-current@freebsd.org Thu Mar 16 00:02:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 687F3D0E357 for ; Thu, 16 Mar 2017 00:02:39 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 533731E33 for ; Thu, 16 Mar 2017 00:02:39 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v2FNvYx2060356; Wed, 15 Mar 2017 16:57:35 -0700 (PDT) (envelope-from null@pozo.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: fail world build From: Manfred Antar In-Reply-To: Date: Wed, 15 Mar 2017 16:57:34 -0700 Cc: David Wolfskill , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170315230723.GR1341@albert.catwhisker.org> To: Roberto Rodriguez Jr X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v2FNvYx2060356 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 00:02:39 -0000 > On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr wrote: >=20 > Hey, >=20 > r315336 >=20 > --- pciconf.o --- > /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of > undeclared identifier 'PCIC_ACCEL' > {PCIC_ACCEL, -1, "processing > accelerators"}, > ^ > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of > undeclared identifier 'PCIC_ACCEL' > {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing > accelerators"}, > ^ > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of > undeclared identifier 'PCIS_ACCEL_PROCESSING' > {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing > accelerators"}, > ^ > /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of > undeclared identifier 'PCIC_INSTRUMENT' > {PCIC_INSTRUMENT, -1, "non-essential > instrumentation"}, > ^ > 4 errors generated. >=20 What revision of /usr/include/pci/pcireg.h do you have ? I have r315190 Current r315337: (include)5028}cd /usr/src/usr.sbin/pciconf/ (pciconf)5029}make obj /usr/obj/usr/src/usr.sbin/pciconf created for /usr/src/usr.sbin/pciconf (pciconf)5030}make echo pciconf: /usr/lib/libc.a >> .depend /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.pciconf.o -MTpciconf.= o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c /usr/src/usr.sbin/pciconf/pciconf= .c -o pciconf.o /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.cap.o -MTcap.o -std= =3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-p= arameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredunda= nt-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declar= ations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-con= st-variable -Qunused-arguments -c /usr/src/usr.sbin/pciconf/cap.c -o cap.o /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.err.o -MTerr.o -std= =3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-p= arameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredunda= nt-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declar= ations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-con= st-variable -Qunused-arguments -c /usr/src/usr.sbin/pciconf/err.c -o err.o cc -O2 -pipe -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -= Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -W= shadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-= externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissin= g-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Qunused-arguments -o pciconf pciconf.o cap.o= err.o=20=20 gzip -cn /usr/src/usr.sbin/pciconf/pciconf.8 > pciconf.8.gz (pciconf)5031} This is on amd64 current r315337 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@freebsd.org Thu Mar 16 00:17:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3F50D0E71C for ; Thu, 16 Mar 2017 00:17:44 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 6B4AD1431 for ; Thu, 16 Mar 2017 00:17:44 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id z13so31886871iof.2 for ; Wed, 15 Mar 2017 17:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=94G5bJcWkw3BCM3mulkBqbL85it6zphP/Gp3MU+ijAs=; b=KBhRpohvc7/pec+zCYW6bJ+M5HzwP4WzLS3LtFNvaEieSjMN3+cpledogT3Srg5BWB mc06S+gnjD6m5d4UFgRfImNNlLG2BHeA/izn+n3L2baBqTfJkAGZIP1Wd3J0mZujdxDO fXsTz2JebWOUe+tAGlwWMGt6QhP4vKazZVSsrTv1pAsAOLhY28QFqW2JTaz5xNZQ7ueL kAU8WhfgsvcFfkt1CGBJsy4SBQypvH2EZColOMOL3CP73YvsDg+oE01PUnoomJwJk8xV UEzZk7WnwxtZmZQ5rCwXh7oQZH1oKEUXTJeUMf7mUOXwlqgvCoWbvvxM0why2Op0T7ck nDMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=94G5bJcWkw3BCM3mulkBqbL85it6zphP/Gp3MU+ijAs=; b=W6haCChwQur42jTtqIP+EysEW+ovEYWxZ0XKqQ4jiSATbh8WI6Gep6fk0nIIZ+Ahk2 SsPFEMEVm30Xg6MxA1tdvZYUYQhKN8XbB3ELQLzmAVu35ZMEYmYV/ta7YLkB+n+QEYxY /lDwk4upj4WUczcMltDLuiIgzscZDEUxe420ZcVA2aWBiDasQBVk/Fd4cTUty2zpcm0Q 1Ym7YgNhDj0xI7P1VtFjCzYHVEVywRLIWnl///P+fSKnTtZLY5UMG1FcuHkdffuZMjub J1s6FevE/lhuXAwtWMsVypWV7Oy/+JtB3sC27HbBZv6wkxTfRsdiS46uNJrWamKT90Yo 5nbw== X-Gm-Message-State: AFeK/H3tTawH0sMSaukT5Ln8jIJA4/fIi5SQqEFeZhNxNl28okuNbnnl3PEwgxMlMl6bgTRueIbMA0itVdxgSQ== X-Received: by 10.107.58.131 with SMTP id h125mr8517349ioa.37.1489623463616; Wed, 15 Mar 2017 17:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Wed, 15 Mar 2017 17:17:43 -0700 (PDT) In-Reply-To: References: <20170315230723.GR1341@albert.catwhisker.org> From: Roberto Rodriguez Jr Date: Thu, 16 Mar 2017 00:17:43 +0000 Message-ID: Subject: Re: fail world build To: Manfred Antar Cc: David Wolfskill , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 00:17:44 -0000 Hi, world is amd64-20170309-r314972 # ls /usr/include/pci ls: /usr/include/pci: No such file or directory Havent been able to buildworld since r314495 Thanks -R On Wed, Mar 15, 2017 at 11:57 PM, Manfred Antar wrote: > > > On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr < > rob.rodz.jr9@gmail.com> wrote: > > > > Hey, > > > > r315336 > > > > --- pciconf.o --- > > /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of > > undeclared identifier 'PCIC_ACCEL' > > {PCIC_ACCEL, -1, "processing > > accelerators"}, > > ^ > > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of > > undeclared identifier 'PCIC_ACCEL' > > {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing > > accelerators"}, > > ^ > > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of > > undeclared identifier 'PCIS_ACCEL_PROCESSING' > > {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing > > accelerators"}, > > ^ > > /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of > > undeclared identifier 'PCIC_INSTRUMENT' > > {PCIC_INSTRUMENT, -1, "non-essential > > instrumentation"}, > > ^ > > 4 errors generated. > > > > What revision of /usr/include/pci/pcireg.h do you have ? > I have r315190 > > Current r315337: > > (include)5028}cd /usr/src/usr.sbin/pciconf/ > (pciconf)5029}make obj > /usr/obj/usr/src/usr.sbin/pciconf created for /usr/src/usr.sbin/pciconf > (pciconf)5030}make > echo pciconf: /usr/lib/libc.a >> .depend > /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.pciconf.o > -MTpciconf.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/usr.sbin/pciconf/pciconf.c -o pciconf.o > /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.cap.o -MTcap.o > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k > -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/usr.sbin/pciconf/cap.c -o cap.o > /usr/local/bin/ccache cc -O2 -pipe -MD -MF.depend.err.o -MTerr.o > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k > -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/usr.sbin/pciconf/err.c -o err.o > cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Qunused-arguments -o pciconf pciconf.o cap.o > err.o > gzip -cn /usr/src/usr.sbin/pciconf/pciconf.8 > pciconf.8.gz > (pciconf)5031} > > This is on amd64 current r315337 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From owner-freebsd-current@freebsd.org Thu Mar 16 00:49:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46460D0C4F0 for ; Thu, 16 Mar 2017 00:49:36 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11B8E1717 for ; Thu, 16 Mar 2017 00:49:35 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id oJbac2fR2cWiHoJbbcUWe8; Wed, 15 Mar 2017 18:49:28 -0600 X-Authority-Analysis: v=2.2 cv=JLBLi4Cb c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=VfNxdwTqTdyeTmpNif4A:9 a=32LWEhVkiWU8A0qL:21 a=kcidHoiN3QXm04-0:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 644E57CA; Wed, 15 Mar 2017 17:49:26 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2FKCbvg078762; Wed, 15 Mar 2017 13:12:38 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703152012.v2FKCbvg078762@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "O. Hartmann" cc: freebsd-current Subject: Re: ntpd dies nightly on a server with jails In-Reply-To: Message from "O. Hartmann" of "Wed, 15 Mar 2017 07:17:24 +0100." <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Mar 2017 13:12:37 -0700 X-CMAE-Envelope: MS4wfKZANHIY3q/z0IH97/kn4+/y9HX1OPCYxkd65V7veXocYBkf8aZx33gSYDyzH85sWfPmSl/fFR8h/7pNlwrxV/qE6YD3xBeTxzPKYWhudMqO13Pv5vzt hQoxHtaB2gARZYkKWD9LuQ4Jk/2yNwFbBmEZtoPpQ6EXCAMHuzWNNIItRaPynYPtYRMaqQ5VlV8FOdvrqSVXFW6bw2xAiFWrsrvp+QvsLOXFwm4u/d0PRl83 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 00:49:36 -0000 Hi O.Hartmann, I'll try to answer as much as I can in the noon hour I have left. In message <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187: > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. > > The box is an older two-socket Fujitsu server equipted with two four-core > Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. > > The box has several jails, each jail does NOT run service ntpd. Each jail has > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated IP > : > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > > The host itself has two main NICs, broadcom based. bcm0 is dedicated to the > host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 via > whihc the jails communicate with the network. > > I try to capture log informations via syslog, but FreeBSD's ntpd seems to be > very, very sparse with such informations, coverging to null - I can't see > anything suiatble in the logs why NTPD dies almost every night leaving the > system with a wild reset of time. Sometimes it is a gain of 6 hours, sometime > s > it is only half an hour. I leave the box at 16:00 local time usually and take > care again at ~ 7 o'clock in the morning local time. We will need to turn on debugging. Unfortunately debug code is not compiled into the binary. We have two options. You can either update src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exact same ntp) with the DEBUG option -- this is probably simpler. Then enable debug with -d and -D. -D increases verbosity. I just committed a debug option to both ntp ports to assist here. Next question: Do you see any indication of a core dump? I'd be interested in looking at it if possible. > > When the clock is floating that wild, in all cases ntpd isn't running any mor > e. > I try to restart with options -g and -G to adjust the time quickly at the > beginning, which works fine. This is disconcerting. If your clock is floating wildly without ntpd running there are other issues that might be at play here. At most the clock might drift a little, maybe a minute or two a day but not by a lot. Does the drift cause your clocks to run fast or slow? > > Apart from possible misconfigurations of the jails (I'm quite new to jails an > d > their pitfalls), I was wondering what causes ntpd to die. i can't determine > exactly the time of its death, so it might be related to diurnal/periodic > processes (I use only the most vanilla configurations on periodic, except for > checking ZFS's scrubbing enabled). As I'm a little rushed for time, I didn't catch whether the jails themselves were also running ntpd... just thought I'd ask. I don't see how zfs scrubbing or any other periodic scripts could cause this. > > I'ven't had the chance to check whether the hardware is completely all right, > but from a superficial point of view there is no issue with high gain of the > internal clock or other hardware issues. It's probably a good idea to check. I don't think that would cause ntpd any gas. I've seen RTC battery messages on my gear which haven't caused ntpd any problem. I have two machines which complain about RTC battery being dead, where in fact I have replaced the batteries and the messages still are displayed at boot. I'm not sure if it's possible for a kernel to damage the RTC. In my case that doesn't cause ntpd any problems. It's probably good to check anyway. > > If there are known issues with jails (the problem occurs since I use those), > advice is appreciated. Not that I know of. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Thu Mar 16 02:44:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A593ED0EB61; Thu, 16 Mar 2017 02:44:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86DDF1C1C; Thu, 16 Mar 2017 02:44:36 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dI5ZrvRB0mKVGT7DARKCCYfjXs9sdco1qhDC4drSyBo=; b=EtT2Sm7ldefsNz5zWjI7MuWonA ObYAAwimu1cD1Mxj7PHNSu5gYDYlnNNxbr2EY7NA3+TayS4ByfkBMsMOc3I31+F0Q6XweWwvI/M0t mY5nmsi+XcOhd7MhM5W4p72ycmBbkavN3piLm3sanPOcHuXtAqwAEnsdLaoVvNWXWeVA=; Received: from [2001:470:1f0f:42c:a6ba:dbff:fe29:6695] (port=28462 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1coLP1-0005KR-HR; Wed, 15 Mar 2017 21:44:35 -0500 Date: Wed, 15 Mar 2017 21:44:33 -0500 From: Larry Rosenman To: freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: crash: umount_nfs: Current Message-ID: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> Mail-Followup-To: freebsd-fs@freebsd.org, freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:44:36 -0000 Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT. Lovely crash: borg.lerctr.org dumped core - see /var/crash/vmcore.1 Wed Mar 15 21:38:53 CDT 2017 FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue Mar 14 20:55:36 CDT 2017 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: general protection fault GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 21 instruction pointer = 0x20:0xffffffff80a327ae stack pointer = 0x28:0xfffffe535ebb2800 frame pointer = 0x28:0xfffffe535ebb2830 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3172 (umount) trap number = 9 panic: general protection fault cpuid = 1 time = 1489631515 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe535ebb2440 vpanic() at vpanic+0x19c/frame 0xfffffe535ebb24c0 panic() at panic+0x43/frame 0xfffffe535ebb2520 trap_fatal() at trap_fatal+0x322/frame 0xfffffe535ebb2570 trap() at trap+0x5e/frame 0xfffffe535ebb2730 calltrap() at calltrap+0x8/frame 0xfffffe535ebb2730 --- trap 0x9, rip = 0xffffffff80a327ae, rsp = 0xfffffe535ebb2800, rbp = 0xfffffe535ebb2830 --- __mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfffffe535ebb2830 xprt_unregister() at xprt_unregister+0x28/frame 0xfffffe535ebb2850 clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfffffe535ebb2880 nfs_unmount() at nfs_unmount+0x182/frame 0xfffffe535ebb28d0 dounmount() at dounmount+0x5c1/frame 0xfffffe535ebb2950 sys_unmount() at sys_unmount+0x30f/frame 0xfffffe535ebb2a70 amd64_syscall() at amd64_syscall+0x55a/frame 0xfffffe535ebb2bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe535ebb2bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x800872b9a, rsp = 0x7fffffffde88, rbp = 0x7fffffffe3c0 --- Uptime: 2h43m8s Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux.ko.debug...done. done. Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /usr/lib/debug//boot/kernel/if_lagg.ko.debug...done. done. Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /usr/lib/debug//boot/kernel/coretemp.ko.debug...done. done. Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /usr/lib/debug//boot/kernel/aesni.ko.debug...done. done. Reading symbols from /boot/kernel/filemon.ko...Reading symbols from /usr/lib/debug//boot/kernel/filemon.ko.debug...done. done. Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/lib/debug//boot/kernel/fuse.ko.debug...done. done. Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /usr/lib/debug//boot/kernel/ichsmb.ko.debug...done. done. Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/lib/debug//boot/kernel/smbus.ko.debug...done. done. Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /usr/lib/debug//boot/kernel/ichwd.ko.debug...done. done. Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /usr/lib/debug//boot/kernel/cpuctl.ko.debug...done. done. Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /usr/lib/debug//boot/kernel/cryptodev.ko.debug...done. done. Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtraceall.ko.debug...done. done. Reading symbols from /boot/kernel/profile.ko...Reading symbols from /usr/lib/debug//boot/kernel/profile.ko.debug...done. done. Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtrace.ko.debug...done. done. Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done. done. Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace.ko.debug...done. done. Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/lib/debug//boot/kernel/sdt.ko.debug...done. done. Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /usr/lib/debug//boot/kernel/fasttrap.ko.debug...done. done. Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/lib/debug//boot/kernel/fbt.ko.debug...done. done. Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done. done. Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done. done. Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols found)...done. Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /usr/lib/debug//boot/kernel/ipmi.ko.debug...done. done. Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from /usr/lib/debug//boot/kernel/ipmi_linux.ko.debug...done. done. Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from /usr/lib/debug//boot/kernel/hwpmc.ko.debug...done. done. Reading symbols from /boot/kernel/mfip.ko...Reading symbols from /usr/lib/debug//boot/kernel/mfip.ko.debug...done. done. Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/debug//boot/kernel/ums.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbols found)...done. Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/lib/debug//boot/kernel/netgraph.ko.debug...done. done. Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_ether.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbols found)...done. Reading symbols from /boot/kernel/linux64.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux64.ko.debug...done. done. Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. done. __curthread () at ./machine/pcpu.h:232 232 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff80a52c15 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:386 #3 0xffffffff80a53206 in vpanic (fmt=, ap=0xfffffe535ebb2500) at /usr/src/sys/kern/kern_shutdown.c:779 #4 0xffffffff80a53253 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:710 #5 0xffffffff80ecd5c2 in trap_fatal (frame=0xfffffe535ebb2740, eva=0) at /usr/src/sys/amd64/amd64/trap.c:801 #6 0xffffffff80eccb8e in trap (frame=0xfffffe535ebb2740) at /usr/src/sys/amd64/amd64/trap.c:197 #7 #8 __mtx_lock_flags (c=0xdeadc0dedeadc0f6, opts=0, file=0xffffffff8147e721 "/usr/src/sys/rpc/svc.c", line=380) at /usr/src/sys/kern/kern_mutex.c:239 #9 0xffffffff80cc14b8 in xprt_unregister (xprt=0xfffff8022e0fce00) at /usr/src/sys/rpc/svc.c:380 #10 0xffffffff80cbc058 in clnt_reconnect_destroy (cl=0xfffff80146fa3900) at /usr/src/sys/rpc/clnt_rc.c:500 #11 0xffffffff80969972 in nfs_unmount (mp=, mntflags=) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:1704 #12 0xffffffff80b0b761 in dounmount (mp=0xdeadc0dedeadc0f6, flags=134217728, td=0xfffff8018f2eb000) at /usr/src/sys/kern/vfs_mount.c:1388 #13 0xffffffff80b0b11f in sys_unmount (td=0xfffff8018f2eb000, uap=0xfffffe535ebb2b70) at /usr/src/sys/kern/vfs_mount.c:1215 #14 0xffffffff80ecdfea in syscallenter (td=0xfffff8018f2eb000, sa=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #15 amd64_syscall (td=0xfffff8018f2eb000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:902 #16 Can't read data for section '.eh_frame' in file '/' (kgdb) vmcore / source IS available. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Thu Mar 16 09:07:27 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88F3D0F9DB for ; Thu, 16 Mar 2017 09:07:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 99D341020 for ; Thu, 16 Mar 2017 09:07:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14879 invoked from network); 16 Mar 2017 09:07:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Mar 2017 09:07:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 16 Mar 2017 05:07:25 -0400 (EDT) Received: (qmail 28883 invoked from network); 16 Mar 2017 09:07:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Mar 2017 09:07:25 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 29159EC7ED9; Thu, 16 Mar 2017 02:07:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <201703160607.v2G67Vwe023153@sdf.org> Date: Thu, 16 Mar 2017 02:07:23 -0700 Cc: FreeBSD Current , freebsd-arm@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> <201703160607.v2G67Vwe023153@sdf.org> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:07:27 -0000 On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote: > Mark Millard wrote: >=20 >> [Something strange happened to the automatic CC: fill-in for my = original >> reply. Also I should have mentioned that for my test program if a >> variant is made that does not fork the swapping works fine.] >>=20 >> On 2017-Mar-15, at 9:37 AM, Mark Millard = wrote: >>=20 >>> On 2017-Mar-15, at 6:15 AM, Scott Bennett = wrote: >>>=20 >>>> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >>>> wrote: >>>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>>>=20 >>>>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>>>> [test_check() between the fork and the wait/sleep prevents the >>>>>>> failure from occurring. Even a small access to the memory at >>>>>>> that stage prevents the failure. Details follow.] >>>>>>=20 >>>>>> Maybe a stupid question, since you might have written it = somewhere. >>>>>> What medium do you swap to? >>>>>> I've seen broken firmware on microSD cards doing silent data >>>>>> corruption for some access patterns. >>>>>=20 >>>>> The root filesystem is on a USB SSD on a powered hub. >>>>>=20 >>>>> Only the kernel is from the microSD card. >>>>>=20 >>>>> I have several examples of the USB SSD model and have >>>>> never observed such problems in any other context. >>>>>=20 >>>>> [remainder of irrelevant material deleted --SB] >>>>=20 >>>> You gave a very long-winded non-answer to Bernd's question, so = I'll >>>> repeat it here. What medium do you swap to? >>>=20 >>> My wording of: >>>=20 >>> The root filesystem is on a USB SSD on a powered hub. >>>=20 >>> was definitely poor. It should have explicitly mentioned the >>> swap partition too: >>>=20 >>> The root filesystem and swap partition are both on the same >>> USB SSD on a powered hub. >>>=20 >>> More detail from dmesg -a for usb: >>>=20 >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on = usbus0 >>> ugen1.1: at usbus1 >>> uhub1: = on usbus1 >>> ugen2.1: at usbus2 >>> uhub2: on = usbus2 >>> ugen3.1: at usbus3 >>> uhub3: = on usbus3 >>> . . . >>> uhub0: 1 port with 1 removable, self powered >>> uhub2: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> uhub3: 1 port with 1 removable, self powered >>> ugen3.2: at usbus3 >>> uhub4 on uhub3 >>> uhub4: = on usbus3 >>> uhub4: MTT enabled >>> uhub4: 4 ports with 4 removable, self powered >>> ugen3.3: at usbus3 >>> umass0 on uhub4 >>> umass0: on = usbus3 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> umass0:0:0: Attached to scbus0 >>> . . . >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number >>> da0: 40.000MB/s transfers >>>=20 >>> (Edited a bit because there is other material interlaced, even >>> internal to some lines. Also: I removed the serial number of the >>> specific example device.) >=20 > Thank you. That presents a much clearer picture. >>>=20 >>>> I will further note that any kind of USB device cannot = automatically >>>> be trusted to behave properly. USB devices are notorious, for = example, >>>>=20 >>>> [reasons why deleted --SB] >>>>=20 >>>> You should identify where you page/swap to and then try = substituting >>>> a different device for that function as a test to eliminate the = possibility >>>> of a bad storage device/controller. If the problem still occurs, = that >>>> means there still remains the possibility that another controller = or its >>>> firmware is defective instead. It could be a kernel bug, it is = true, but >>>> making sure there is no hardware or firmware error occurring is = important, >>>> and as I say, USB devices should always be considered suspect = unless and >>>> until proven innocent. >>>=20 >>> [FYI: This is a ufs context, not a zfs one.] >=20 > Right. It's only a Pi, after all. :-) It is a Pine64+ 2GB, not an rpi3. >>>=20 >>> I'm aware of such things. There is no evidence that has resulted in >>> suggesting the USB devices that I can replace are a problem. = Otherwise >>> I'd not be going down this path. I only have access to the one arm64 >>> device (a Pine64+ 2GB) so I've no ability to substitution-test what >>> is on that board. >=20 > There isn't even one open port on that hub that you could plug a > flash drive into temporarily to be the paging device? Why do you think that I've never tried alternative devices? It is just that the result was no evidence that my usually-in-use SSD is having a special/local problem: the behavior continues across all such contexts when the Pine64+ 2GB is involved. (Again I have not had access to an alternate to the one arm64 board. That limits my substitution testing possibilities.) Why would you expect a Flash drive to be better than another SSD for such testing? (The SSD that I usually use even happens to be a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So is the hub that I usually use for that matter.) > You could then > try your tests before returning to the normal configuration. If there > isn't an open port, then how about plugging a second hub into one of > the first hub's ports and moving the displaced device to the second > hub? A flash drive could then be plugged in. That kind of = configuration > is obviously a bad idea for the long run, but just to try your tests = it > ought to work well enough. I have access to more SSDs that I can use than I do to Flash drives. I see no reason to specifically use a Flash drive. > (BTW, if a USB storage device containing a > paging area drops off=3Dline even momentarily and the system needs to = use > it, that is the beginning of the end, even though it may take up to a = few > minutes for everything to lock up. The system does not lock up, even days or weeks later, with having done dozens of experiments that show memory corruption failures over those days. The only processes showing memory corruption so far are those that were the parent or child for a fork that were later swapped out to have zero RES(ident memory) and then even later swapped back in. The context has no such issues. You are inventing problems that do not exist in my context. That is why none of my list submittals mention such problems: they did not occur. > You probably won't be able to do an > orderly shutdown, but will instead have to crash it with the power = switch. > In the case of something like a Pi, this is an unpleasant fact of = life, > to be sure.) Such things did not occur and has nothing to do with my context so far. > I think I buy your arguments, given the evidence you've collected > thus far, including what you've added below. I just like to eliminate > possibilities that are much simpler to deal with before facing = nastinesses > like bugs in the VM subsystem. :-) When I started this I found no evidence of device-specific problems. My investigation activity goes back to long before my list submittals. And I repeat: Other people have reported the symptoms that started this investigation. They did so before I ever started my activities. They were using none of the specific devices that I have access to. Likely the types of devices were frequently even different, such as a rpi3 instead of a Pine64+ 2GB or a different USB drive. I was able to get the symptoms that they reported. >>> It would be neat if some folks used my code to test other arm64 >>> contexts and reported the results. I'd be very interested. >>> (This is easier to do on devices that do not have massive >>> amounts of RAM, which may limit the range of devices or >>> device configurations that are reasonable to test.) >>>=20 >>> There is that other people using other devices have reported >>> the behavior that started this investigation. I can produce the >>> behavior that they reported, although I've not seen anyone else >>> listing specific steps that lead to the problem or ways to tell >>> if the symptom is going to happen before it actually does. Nor >>> have I seen any other core dump analysis. (I have bugzilla >>> submittals 217138 and 217239 tied to symptoms others have >>> reported as well as this test program material.) >>>=20 >>> Also, considering that for my test program I can control which pages >>> get the zeroed-problem by read-accessing even one byte of any 4K >>> Byte page that I want to make work normally, doing so in the child >>> process of the fork, between the fork and the sleep/swap-out, it = does >>> not suggest USB-device-specific behavior. The read-access is = changing >>> the status of the page in some way as far as I can tell. >>>=20 >>> (Such read-accesses in the parent process make no difference to the >>> behavior.) >>=20 >> I should have noted another comparison/contrast between >> having memory corruption and not in my context: >>=20 >> I've tried variants of my test program that do not fork but >> just sleep for 60s to allow me to force the swap-out. I >> did this before adding fork and before using >> parital_test_check, for example. I gradually added things >> apparently involved in the reports others had made >> until I found a combination that produced a memory >> corruption test failure. >>=20 >> These tests without fork involved find no problems with >> the memory content after the swap-in. >>=20 >> For my test program it appears that fork-before-swap-out >> or the like is essential to having the problem occur. >>=20 > A comment about terminology seems in order here. It bothers > me considerably to see you writing "swap out" or "swapping" where > it seems like you mean to write "page out" or "paging". A BSD > system whose swapping mechanism gets activated has already waded > very deeply into the quicksand and frequently cannot be gotten out > in a reasonable amount of time even with manual assistance. It is > often quicker to crash it, reboot, and wait for the fsck(8) cleanups > to complete. Orderly shutdowns, even of the kind that results from > a quick poke to the power button, typically get mired in the same > mess that already has the system in knots. Also, BSD systems since > 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, > just out. A swapped out process, once the system determines that it > has adequate resources again to attempt to run the process, will have > the interrupted text page paged in and the rest will be paged in by > the normal mechanism of page faults and page-in operations. I assume > you must already know all this, which is a large part of why it grates > on me that you appear to be using the wrong terms. You apparently did not read any of the material about how the test is done or are unfamiliar with what "stress -m 1 --vm-bytes 1800M" does when there is only 2GB of RAM. I am deliberately inducing swapping in other processes, including the 2 from my test program (after the fork), not just paging. (stress is a port, not part of the base system.) When I say swap-out and swap-in I mean it. =46rom the source code of my test program: sleep(60); // During this manually force this process to // swap out. I use something like: // stress -m 1 --vm-bytes 1800M // in another shell and ^C'ing it after top // shows the swapped status desired. 1800M // just happened to work on the Pine64+ 2GB // that I was using. I watch with top -PCwaopid . That type of stress run uses about 1.8 GiBytes after a bit, which is enough to cause the swapping of other processes, including the two that I am testing (post-fork). (Some RAM is in use already before the stress run, which explains not needing 2 GiBytes to be in use by stress.) Look at a "top -PCwaopid" display: there are columns for RES(ident memory) and SWAP. I cause my 2 test processes to show zero RES and everything under SWAP, starting sometime during the 60s sleep/wait. Why would I cause swapping? Because buildworld causes such swap-outs at times when there is only 2GBytes of RAM, including processes that forked earlier, and as a result the corrupted memory problems show up later in some processes that were swapped out at the time. The build eventually stops for process failures tied to the corruptions of memory in the failing processes. (At least that is what my testing strongly suggests.) But that is a very complicated context to use for analysis or testing of the problem. My test program is vastly simpler and easier/quicker to set up and test when used with stress as well. Such was the kind of thing I was trying to find. I want the Pine64+ 2GB to work well enough to be able to have buildworld (-j 4) complete correctly without having to restart the build --even when everything has to be rebuilt. So I'm trying to find and provide enough evidence to help someone fix the problems that are observed to block such buildworld activity. Again: others have reported such arm64 problems on the lists before I ever got into this activity. The evidence is that the issues are not a local property of my environment. Swapping is supposed to work. I can do buildworld (-j 4) on armv6 (really -mcpu=3Dcortex-a7 so armv7-a) and the swapping it causes works fine. This is true for both a bpim3 (2 GiBytes of RAM) and a rpi2 (1 GiByte of RAM so even more swapping). On a powerpc64 with 16 GiBytes I've built things that caused 26 GiBytes of swap to be in use some of the time (during 4 ld's running in parallel), with lots of processes having zero for RES(ident memory) and all their space listed under SWAP in a "top -PCwaopid" display. This too has no problems with swapping of previously forked processes (or of any other processes). For the likes of a Pine64+ 2GB to be "self hosted"=20 for source-code based updates, swapping of previously forked processes must work and currently such swapping is unreliable. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Mar 16 06:08:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E86EAD0E0B1; Thu, 16 Mar 2017 06:08:06 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ol.sdf.org", Issuer "ol.sdf.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B57F315F3; Thu, 16 Mar 2017 06:08:06 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@otaku.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id v2G67WMk026837 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 16 Mar 2017 06:07:32 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id v2G67Vwe023153; Thu, 16 Mar 2017 01:07:31 -0500 (CDT) From: Scott Bennett Message-Id: <201703160607.v2G67Vwe023153@sdf.org> Date: Thu, 16 Mar 2017 01:07:31 -0500 To: markmi@dsl-only.net Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, freebsd-stable@freebsd.org References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> In-Reply-To: User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Mar 2017 10:44:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 06:08:07 -0000 Mark Millard wrote: > [Something strange happened to the automatic CC: fill-in for my original > reply. Also I should have mentioned that for my test program if a > variant is made that does not fork the swapping works fine.] > > On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > > > On 2017-Mar-15, at 6:15 AM, Scott Bennett wrote: > > > >> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard > >> wrote: > >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter wrote: > >>> > >>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > >>>>> [test_check() between the fork and the wait/sleep prevents the > >>>>> failure from occurring. Even a small access to the memory at > >>>>> that stage prevents the failure. Details follow.] > >>>> > >>>> Maybe a stupid question, since you might have written it somewhere. > >>>> What medium do you swap to? > >>>> I've seen broken firmware on microSD cards doing silent data > >>>> corruption for some access patterns. > >>> > >>> The root filesystem is on a USB SSD on a powered hub. > >>> > >>> Only the kernel is from the microSD card. > >>> > >>> I have several examples of the USB SSD model and have > >>> never observed such problems in any other context. > >>> > >>> [remainder of irrelevant material deleted --SB] > >> > >> You gave a very long-winded non-answer to Bernd's question, so I'll > >> repeat it here. What medium do you swap to? > > > > My wording of: > > > > The root filesystem is on a USB SSD on a powered hub. > > > > was definitely poor. It should have explicitly mentioned the > > swap partition too: > > > > The root filesystem and swap partition are both on the same > > USB SSD on a powered hub. > > > > More detail from dmesg -a for usb: > > > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 480Mbps High Speed USB v2.0 > > usbus2: 12Mbps Full Speed USB v1.0 > > usbus3: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > ugen1.1: at usbus1 > > uhub1: on usbus1 > > ugen2.1: at usbus2 > > uhub2: on usbus2 > > ugen3.1: at usbus3 > > uhub3: on usbus3 > > . . . > > uhub0: 1 port with 1 removable, self powered > > uhub2: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > uhub3: 1 port with 1 removable, self powered > > ugen3.2: at usbus3 > > uhub4 on uhub3 > > uhub4: on usbus3 > > uhub4: MTT enabled > > uhub4: 4 ports with 4 removable, self powered > > ugen3.3: at usbus3 > > umass0 on uhub4 > > umass0: on usbus3 > > umass0: SCSI over Bulk-Only; quirks = 0x0100 > > umass0:0:0: Attached to scbus0 > > . . . > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Fixed Direct Access SPC-4 SCSI device > > da0: Serial Number > > da0: 40.000MB/s transfers > > > > (Edited a bit because there is other material interlaced, even > > internal to some lines. Also: I removed the serial number of the > > specific example device.) Thank you. That presents a much clearer picture. > > > >> I will further note that any kind of USB device cannot automatically > >> be trusted to behave properly. USB devices are notorious, for example, > >> > >> [reasons why deleted --SB] > >> > >> You should identify where you page/swap to and then try substituting > >> a different device for that function as a test to eliminate the possibility > >> of a bad storage device/controller. If the problem still occurs, that > >> means there still remains the possibility that another controller or its > >> firmware is defective instead. It could be a kernel bug, it is true, but > >> making sure there is no hardware or firmware error occurring is important, > >> and as I say, USB devices should always be considered suspect unless and > >> until proven innocent. > > > > [FYI: This is a ufs context, not a zfs one.] Right. It's only a Pi, after all. :-) > > > > I'm aware of such things. There is no evidence that has resulted in > > suggesting the USB devices that I can replace are a problem. Otherwise > > I'd not be going down this path. I only have access to the one arm64 > > device (a Pine64+ 2GB) so I've no ability to substitution-test what > > is on that board. There isn't even one open port on that hub that you could plug a flash drive into temporarily to be the paging device? You could then try your tests before returning to the normal configuration. If there isn't an open port, then how about plugging a second hub into one of the first hub's ports and moving the displaced device to the second hub? A flash drive could then be plugged in. That kind of configuration is obviously a bad idea for the long run, but just to try your tests it ought to work well enough. (BTW, if a USB storage device containing a paging area drops off=line even momentarily and the system needs to use it, that is the beginning of the end, even though it may take up to a few minutes for everything to lock up. You probably won't be able to do an orderly shutdown, but will instead have to crash it with the power switch. In the case of something like a Pi, this is an unpleasant fact of life, to be sure.) I think I buy your arguments, given the evidence you've collected thus far, including what you've added below. I just like to eliminate possibilities that are much simpler to deal with before facing nastinesses like bugs in the VM subsystem. :-) > > > > It would be neat if some folks used my code to test other arm64 > > contexts and reported the results. I'd be very interested. > > (This is easier to do on devices that do not have massive > > amounts of RAM, which may limit the range of devices or > > device configurations that are reasonable to test.) > > > > There is that other people using other devices have reported > > the behavior that started this investigation. I can produce the > > behavior that they reported, although I've not seen anyone else > > listing specific steps that lead to the problem or ways to tell > > if the symptom is going to happen before it actually does. Nor > > have I seen any other core dump analysis. (I have bugzilla > > submittals 217138 and 217239 tied to symptoms others have > > reported as well as this test program material.) > > > > Also, considering that for my test program I can control which pages > > get the zeroed-problem by read-accessing even one byte of any 4K > > Byte page that I want to make work normally, doing so in the child > > process of the fork, between the fork and the sleep/swap-out, it does > > not suggest USB-device-specific behavior. The read-access is changing > > the status of the page in some way as far as I can tell. > > > > (Such read-accesses in the parent process make no difference to the > > behavior.) > > I should have noted another comparison/contrast between > having memory corruption and not in my context: > > I've tried variants of my test program that do not fork but > just sleep for 60s to allow me to force the swap-out. I > did this before adding fork and before using > parital_test_check, for example. I gradually added things > apparently involved in the reports others had made > until I found a combination that produced a memory > corruption test failure. > > These tests without fork involved find no problems with > the memory content after the swap-in. > > For my test program it appears that fork-before-swap-out > or the like is essential to having the problem occur. > A comment about terminology seems in order here. It bothers me considerably to see you writing "swap out" or "swapping" where it seems like you mean to write "page out" or "paging". A BSD system whose swapping mechanism gets activated has already waded very deeply into the quicksand and frequently cannot be gotten out in a reasonable amount of time even with manual assistance. It is often quicker to crash it, reboot, and wait for the fsck(8) cleanups to complete. Orderly shutdowns, even of the kind that results from a quick poke to the power button, typically get mired in the same mess that already has the system in knots. Also, BSD systems since 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, just out. A swapped out process, once the system determines that it has adequate resources again to attempt to run the process, will have the interrupted text page paged in and the rest will be paged in by the normal mechanism of page faults and page-in operations. I assume you must already know all this, which is a large part of why it grates on me that you appear to be using the wrong terms. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-current@freebsd.org Thu Mar 16 11:41:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B22D2D0D771 for ; Thu, 16 Mar 2017 11:41:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76BE911F1 for ; Thu, 16 Mar 2017 11:41:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.135.62] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1coTmb-0003WS-RB for freebsd-current@freebsd.org; Thu, 16 Mar 2017 12:41:30 +0100 Received: from localhost.my.domain (c720-r314251 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v2GBfQV4004757 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Mar 2017 12:41:27 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v2GBfQXe004756 for freebsd-current@freebsd.org; Thu, 16 Mar 2017 12:41:26 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 16 Mar 2017 12:41:26 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: update an older i386 CURRENT system to amd64 CURRENT Message-ID: <20170316114126.GA4724@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.62 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:41:40 -0000 Hello, I have an older FreeBSD 9.0-CURRENT system which I want to update to 12-CURRENT: # uname -a FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386 To do so without compiling everything from scratch, I transferred /usr/src (r314251) and /usr/obj to this server, the compilation of /usr/obj was done on an amd64 server and the same procedure (transfer of /usr/src and /usr/obj) was also used to update my C720 netbook; the difference is here that the host which should be update is i386. The 'make installkernel' did not work: # pwd /usr/src # file ../obj/usr/src/sys/GENERIC/kernel ../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped # make installkernel -------------------------------------------------------------- >>> Building an up-to-date bmake(1) -------------------------------------------------------------- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make /usr/obj/usr/src/make.i386/bmake -------------------------------------------------------------- >>> Installing kernel GENERIC -------------------------------------------------------------- cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install cc: Exec format error bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to determine compiler type for CC=cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. *** Error code 1 Also the following did not work: # make installkernel MACHINE_ARCH=amd64 MACHINE=amd64 -------------------------------------------------------------- >>> Building an up-to-date bmake(1) -------------------------------------------------------------- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake -------------------------------------------------------------- >>> Installing kernel GENERIC -------------------------------------------------------------- cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install cc: Exec format error bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to determine compiler type for CC=cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. *** Error code 1 Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386 host for update? Or do I have to use a complete recompile or even reinstall, based on a 64-bit memstick system? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Thu Mar 16 14:23:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B2BFD0F23B for ; Thu, 16 Mar 2017 14:23:55 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC7641997 for ; Thu, 16 Mar 2017 14:23:54 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v2GENW7v034074 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 15:23:32 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v2GENWw6034071; Thu, 16 Mar 2017 15:23:32 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 16 Mar 2017 15:23:32 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Matthias Apitz cc: freebsd-current@freebsd.org Subject: Re: update an older i386 CURRENT system to amd64 CURRENT In-Reply-To: <20170316114126.GA4724@c720-r314251> Message-ID: References: <20170316114126.GA4724@c720-r314251> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:23:55 -0000 On Thu, 16 Mar 2017 12:41+0100, Matthias Apitz wrote: > > > Hello, > > I have an older FreeBSD 9.0-CURRENT system which I want to update to > 12-CURRENT: > > # uname -a > FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386 > > To do so without compiling everything from scratch, I transferred > /usr/src (r314251) and /usr/obj to this server, the compilation of > /usr/obj was done on an amd64 server and the same procedure (transfer > of /usr/src and /usr/obj) was also used to update my C720 netbook; the > difference is here that the host which should be update is i386. > > The 'make installkernel' did not work: > > # pwd > /usr/src > # file ../obj/usr/src/sys/GENERIC/kernel > ../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped > > # make installkernel > > -------------------------------------------------------------- > >>> Building an up-to-date bmake(1) > -------------------------------------------------------------- > sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make > /usr/obj/usr/src/make.i386/bmake > -------------------------------------------------------------- > >>> Installing kernel GENERIC > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc > -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" > NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=cc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 > > > Also the following did not work: > > # make installkernel MACHINE_ARCH=amd64 MACHINE=amd64 > > -------------------------------------------------------------- > >>> Building an up-to-date bmake(1) > -------------------------------------------------------------- > sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make > /usr/obj/usr/src/make.amd64/bmake > -------------------------------------------------------------- > >>> Installing kernel GENERIC > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc > -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" > NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=cc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 > > > Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386 > host for update? Or do I have to use a complete recompile or even > reinstall, based on a 64-bit memstick system? I have in the past successfully migrated i386 to amd64 by cheating a bit: overwriting select parts of the base system with their amd64 counterparts from a snapshot (CD or memorystick) while exempting a few vital directories, /boot (not when replacing the kernel), /etc, /root, and /var. Since you're running the GENERIC kernel, all you need is the latest -current snapshot. Here are my notes from when I was "researching (and perfecting?)" the methodology: http://ximalas.info/2015/01/17/migrating-freebsd-from-i386-to-amd64/ YMMV, but this was less of a hassle than following https://wiki.freebsd.org/amd64/i386Migration. Last Easter I transformed four systems from 9-stable i386 UFS to 10-stable amd64 ZFS, using hardware I had selected for replacing the old hardware. The old systems were transferred to the new systems using tar and nc. That way the old systems kept humming while I recompiled base, ports, etc, on their replacements. Here are three things I didn't do/tried before "going live" last year: recursively copying /usr/local/lib to /usr/local/lib/compat/lib32, creating /usr/local/libdata/ldconfig/lib32 containing the line "/usr/local/lib/compat/lib32", and running ldconfig -R. When all parts of the new systems was in amd64 shape, I removed /usr/local/lib/compat/lib32 and /usr/local/libdata/ldconfig/lib32. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Thu Mar 16 14:25:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12F43D0F374 for ; Thu, 16 Mar 2017 14:25:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 E00281BFD for ; Thu, 16 Mar 2017 14:25:25 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7974813610 for ; Thu, 16 Mar 2017 14:25:17 +0000 (UTC) Subject: Re: update an older i386 CURRENT system to amd64 CURRENT To: freebsd-current@freebsd.org References: <20170316114126.GA4724@c720-r314251> From: Allan Jude Message-ID: Date: Thu, 16 Mar 2017 10:25:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316114126.GA4724@c720-r314251> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FqfIBlfq5GnG1vhCDDs0ImO11Xuf1bpi7" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:25:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FqfIBlfq5GnG1vhCDDs0ImO11Xuf1bpi7 Content-Type: multipart/mixed; boundary="tlEtkw8j8lSjxwC76Ixw4NjKAKHlJUiol"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: update an older i386 CURRENT system to amd64 CURRENT References: <20170316114126.GA4724@c720-r314251> In-Reply-To: <20170316114126.GA4724@c720-r314251> --tlEtkw8j8lSjxwC76Ixw4NjKAKHlJUiol Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-03-16 07:41, Matthias Apitz wrote: >=20 >=20 > Hello, >=20 > I have an older FreeBSD 9.0-CURRENT system which I want to update to > 12-CURRENT: >=20 > # uname -a > FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr= 17 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC = i386 >=20 > To do so without compiling everything from scratch, I transferred > /usr/src (r314251) and /usr/obj to this server, the compilation of > /usr/obj was done on an amd64 server and the same procedure (transfer > of /usr/src and /usr/obj) was also used to update my C720 netbook; the > difference is here that the host which should be update is i386. >=20 > The 'make installkernel' did not work: > =20 > # pwd > /usr/src > # file ../obj/usr/src/sys/GENERIC/kernel > ../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, v= ersion 1 (FreeBSD), dynamically linked (uses shared libs), not stripped >=20 > # make installkernel >=20 > -------------------------------------------------------------- >>>> Building an up-to-date bmake(1) > -------------------------------------------------------------- > sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make > /usr/obj/usr/src/make.i386/bmake > -------------------------------------------------------------- >>>> Installing kernel GENERIC > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=3D/usr/obj > MACHINE_ARCH=3Di386 MACHINE=3Di386 CPUTYPE=3D > GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC=3D"cc > -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/li= b > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CXX=3D"c++ -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CPP=3D"cpp -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LIN= K=3D"" > NM=3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy= /usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/u= sr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=3Dkernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=3Dcc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 >=20 >=20 > Also the following did not work: >=20 > # make installkernel MACHINE_ARCH=3Damd64 MACHINE=3Damd64 >=20 > -------------------------------------------------------------- >>>> Building an up-to-date bmake(1) > -------------------------------------------------------------- > sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make > /usr/obj/usr/src/make.amd64/bmake > -------------------------------------------------------------- >>>> Installing kernel GENERIC > -------------------------------------------------------------- > cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=3D/usr/obj > MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D > GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC=3D"cc > -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/li= b > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CXX=3D"c++ -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" CPP=3D"cpp -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LIN= K=3D"" > NM=3Dnm OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" > PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy= /usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/u= sr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=3Dkernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=3Dcc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 >=20 >=20 > Is there a way to use this /usr/src and pre-compiled /usr/obj on an i38= 6 > host for update? Or do I have to use a complete recompile or even > reinstall, based on a 64-bit memstick system? >=20 > Thanks >=20 > matthias >=20 >=20 The problem is that the build system has built a cross compiler in /usr/obj that it uses to do the building etc, and it is 64bit. Your 32bit OS cannot run it (gives Exec format error). You could try (untested, might eat your lunch, and kick your dog) On the AMD64 host: mkdir /tmp/amd64 make installkernel DESTDIR=3D/tmp/amd64 Then manually copy that kernel & modules into /boot/kernel on the i386 system, and reboot into it. Then you'll have a 64bit kernel, and your old i386 world. Then you should be able to do the make installkernel / installworld from the /usr/src and /usr/obj you transferred --=20 Allan Jude --tlEtkw8j8lSjxwC76Ixw4NjKAKHlJUiol-- --FqfIBlfq5GnG1vhCDDs0ImO11Xuf1bpi7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJYyqBMAAoJEBmVNT4SmAt+DgoQALpOopsrWD/eq7LKe9TH4zb3 LL/pUC5CDDspXzv8MkvMyi7xV9t8utcDhpwOA5n7NntSfNI7nY+4oVQcPRvKZqHh v2j0Ox/SLBz/f0v2GExMOUIDZnVaFFUAWmrImbl75vbipwIs3TH8Yzgci8COvnE+ 6DdfdPBHccSfw44u3YZn0f5o8qhDB+Obnu0qXXEuisEOsf3XYFeu6au+LXu+Mn7K tD9hbx3OhAAb0P63OKNAD9mWMRHKN4kpwgPoRTbwcuCMrYWk5XgQbrrz5J90cOL4 yPGOm6vamdcnhRBY662oDj9tbxi1eQjeBngupU4AhDwHDZhajr1b2CMeFI4q9+hv SDhVwhS13h3llkRP1r49Eb+WSi+TQfVKsDajaoZA6v7He89mUUL1KPqDLyEatTfR Uc0tUdi89qczfIyi7fLolHht5C0LtwN/rahozbwDAGQqaXvjjV5s6+zPHl4/uLR1 66iqVgZRQdzh8DhYuxN6NuerkO2UDsX+M+X/hxc4WSXZm4yUqWYlQl31xQhYXAhU X0RuyG3DZFHsUdMN/WPu0flFNQ9Pdno8+mKmHGVALPVddAHUBM49V3MHCZpqfuiR +VIGHqMQ+prXyZaPBa+Nt5JJXgNQHDz4hs/CSFC78BgGoMfWU9CRLzW96KdGPabm cJNflhGi75LjOfoDle97 =p48b -----END PGP SIGNATURE----- --FqfIBlfq5GnG1vhCDDs0ImO11Xuf1bpi7-- From owner-freebsd-current@freebsd.org Thu Mar 16 16:57:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 417C5D0E730 for ; Thu, 16 Mar 2017 16:57:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EAFD18DA for ; Thu, 16 Mar 2017 16:57:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [82.113.99.64] (helo=[10.58.162.64]) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1coYil-0002YR-7c for freebsd-current@freebsd.org; Thu, 16 Mar 2017 17:57:51 +0100 From: Matthias Apitz To: Subject: Re: update an older i386 CURRENT system to amd64 CURRENT Date: Thu, 16 Mar 2017 17:57:49 +0100 User-Agent: Dekko/0.6.20; Qt/5.4.1; ubuntumirclient; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: References: <20170316114126.GA4724@c720-r314251> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.99.64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:57:55 -0000 On Thursday, 16 March 2017 15:25:10 CET, Allan Jude =20= wrote: >=20 > The problem is that the build system has built a cross compiler in > /usr/obj that it uses to do the building etc, and it is 64bit. Your > 32bit OS cannot run it (gives Exec format error). > .... Thanks for all the replies I got. Meanwhile I booted from a r314251 memstick, and all is installed fine. matthias --=20 Sent from my Ubuntu phone http://www.unixarea.de/ From owner-freebsd-current@freebsd.org Thu Mar 16 17:13:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05B8ED0EDE7 for ; Thu, 16 Mar 2017 17:13:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72F68156A for ; Thu, 16 Mar 2017 17:13:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.132.9]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmOLO-1cEfv518pG-00ZtVI; Thu, 16 Mar 2017 18:13:41 +0100 Date: Thu, 16 Mar 2017 18:13:34 +0100 From: "O. Hartmann" To: freebsd-current@freebsd.org Subject: Re: ntpd dies nightly on a server with jails Message-ID: <20170316181318.605a3e4f@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201703152012.v2FKCbvg078762@slippy.cwsent.com> References: <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> <201703152012.v2FKCbvg078762@slippy.cwsent.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/AnUc3gF=nKU3g_pM6PEHylK"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:g8E0WOA7ryyDDWm0IRu72GBYpWCoGm856HyFkfw1EKfibf8WQ7u uKkb6RAaYeRJd769KbIkLtwyzHohBmodb2Xv7IetucOmvl6pdRvCRT7lBplXEMXFKovBWuJ o1m+EZa0eUxTbAZlgDZS/jTwaKYZWr1NwFm4/Ggdysd3Gk6bOTaOl+m6tRm6lZQtp0glvW9 ehRklVy/lrSr8kfqFVBcg== X-UI-Out-Filterresults: notjunk:1;V01:K0:NWwgYRWd2s8=:M3xaKXSRXsxgx6Pt0Llg3Y m4K4FyE2CnC2nHiIFFEEun2LCo4mS1RXbgOSyd/ggvxPSjRzXBDMfNSqnPskxqvewCsWeh1n5 Lva2GQfBPlnL6+NVhmnmzO71NBfbUlEhiBNeB6Zrg7gkvH8b0i3Y0VMPj7XjAP3lliPw+gvHT k4XlmgaHgHMo6uektsP2b89ZPeZrB9Iu6Vvs07cYYvQwzg6ldbCiUgmQcsmvK/5ZlxjHT/QEd A3Kyat+rN35D2KXuiuf8N6kgE+H+x8PfQZIi8iyY9AfDvWg3aop929ksCPSk2C8QoVE/EdTSs VU0ZSRFE0baYJY1L9hYR5bAJbQHj5RXxgodib76yrtrorONyTOhe8qc7u6JiYoZ6RdJQP3ZiT cWIUPNufUtPp6XnsMajT8SMu36IM/ZTPc8YVk1hRyBhfYVd6sWg8HU0vl0p+8y1pdRl0F8kKP 4NUky5bkJVmDgNojcDzhpTbD3CLwV4B4O2+KlqORZXP0kjFJDQqimCfrIH05o45ZQGi3pNOch aESrg8z67nc2Q6pAAQiMhZsxs+2T4fgeE5bW7N1T1Y413Kcg9c34WKPZy03aa0Cd0ycYywhiA rEizB1sBuLv7VbkZYJx9JbrNOt0JUj4WrbXNz2BYsGnDlp800wJwcZhztj9McCYOU2TAHCkw6 ipNz7nRZAJC8ZUI98PylITm6XeEooQrsyCIHIJhWqw2UtRff9FGoa4zYPqxu/KRbMuWKcf5jw bhYL6yXWvQ9F9Q/hnd+PYxWGFoOKiTIYkEFHTBBrnsWOVXEHtmy1pb15RNs= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:13:49 -0000 --Sig_/AnUc3gF=nKU3g_pM6PEHylK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 15 Mar 2017 13:12:37 -0700 Cy Schubert schrieb: Thank you very much for responding. > Hi O.Hartmann, >=20 > I'll try to answer as much as I can in the noon hour I have left. >=20 > In message <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de>,= =20 > "O. H > artmann" writes: > > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r3= 15187: > > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. > >=20 > > The box is an older two-socket Fujitsu server equipted with two four-co= re > > Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. > >=20 > > The box has several jails, each jail does NOT run service ntpd. Each ja= il has > > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedica= ted IP > > : > > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > >=20 > > The host itself has two main NICs, broadcom based. bcm0 is dedicated to= the > > host, bcm1 is shared amongst the jails: each jail has an IP bound to bc= m1 via > > whihc the jails communicate with the network. > >=20 > > I try to capture log informations via syslog, but FreeBSD's ntpd seems = to be > > very, very sparse with such informations, coverging to null - I can't s= ee > > anything suiatble in the logs why NTPD dies almost every night leaving = the > > system with a wild reset of time. Sometimes it is a gain of 6 hours, so= metime > > s > > it is only half an hour. I leave the box at 16:00 local time usually an= d take > > care again at ~ 7 o'clock in the morning local time. =20 >=20 > We will need to turn on debugging. Unfortunately debug code is not compil= ed=20 > into the binary. We have two options. You can either update=20 > src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exa= ct=20 > same ntp) with the DEBUG option -- this is probably simpler. Then enable= =20 > debug with -d and -D. -D increases verbosity. I just committed a debug=20 > option to both ntp ports to assist here. I realised that this wasn't the case when I turned the switch on ntpd simpl= y on - the output was the same as before. So I feared that I have to recompile with de= bugging explicitely switched on ... >=20 > Next question: Do you see any indication of a core dump? I'd be intereste= d=20 > in looking at it if possible. I have, intentionally, switched off core dumping. I will switch that on. Bu= t in all messages being logged and searched for "ntp", I never saw any error resulti= ng in a crash, but I'll look tomorrow closer. >=20 > >=20 > > When the clock is floating that wild, in all cases ntpd isn't running a= ny mor > > e. > > I try to restart with options -g and -G to adjust the time quickly at t= he > > beginning, which works fine. =20 >=20 > This is disconcerting. If your clock is floating wildly without ntpd=20 > running there are other issues that might be at play here. At most the=20 > clock might drift a little, maybe a minute or two a day but not by a lot.= =20 > Does the drift cause your clocks to run fast or slow? Today, I switched off ntpd on the jail-bearing host. After an hour or so th= e gain of the clock wasn't apart from my DCF77 clock - at least not within the granularit= y of the minutes. So I switched on ntpd again. After a while, I checked status via "= service ntpd status", and I would bet off my ass that the result was "is running with PI= D XXX". The next minute I did the same, the clock was off by almost half an hour (alway= s behind real time, never before!) and ntpd wasn't running. A coincidence? I can not tell= , I did a "clear" on the terminal :-( But that was strange. >=20 > >=20 > > Apart from possible misconfigurations of the jails (I'm quite new to ja= ils an > > d > > their pitfalls), I was wondering what causes ntpd to die. i can't deter= mine > > exactly the time of its death, so it might be related to diurnal/period= ic > > processes (I use only the most vanilla configurations on periodic, exce= pt for > > checking ZFS's scrubbing enabled). =20 >=20 > As I'm a little rushed for time, I didn't catch whether the jails=20 > themselves were also running ntpd... just thought I'd ask. I don't see ho= w=20 > zfs scrubbing or any other periodic scripts could cause this. The jails do not have ntpd running since all the docs I read tell, that the= jail-bearing host provides the time. So I checked/ double-checked, that they do not have= ntpd running. By mentioning ZFS and scrubbing I was more thinking about time-adjusting pe= riodic jobs like adjkerntz or friends - if there are any I'm not aware of. I see, it's = more confusing. >=20 > >=20 > > I'ven't had the chance to check whether the hardware is completely all = right, > > but from a superficial point of view there is no issue with high gain o= f the > > internal clock or other hardware issues. =20 >=20 > It's probably a good idea to check. I don't think that would cause ntpd a= ny=20 > gas. I've seen RTC battery messages on my gear which haven't caused ntpd= =20 > any problem. I have two machines which complain about RTC battery being=20 > dead, where in fact I have replaced the batteries and the messages still= =20 > are displayed at boot. I'm not sure if it's possible for a kernel to dama= ge=20 > the RTC. In my case that doesn't cause ntpd any problems. It's probably=20 > good to check anyway. The server hardware in question is quite old, from 2008/09, so it has seen = its best days long ago. I haven't checked so far the battery status, but that is next I d= o or change the battery cell pro actively for a fresh one. My fear is that one of the time servers I try to sync with is compromised a= nd serving wrong times. But I have no clue on that. I have my difficulties understanding the logic behind ntp.conf regarding "r= estrict". It might be possible that I misconfigured in a very stupid way (due to lack of understanding) ntpd that way, that it could be set by any outer-world times= erver. I'll check this tomorrow while in office again. >=20 > >=20 > > If there are known issues with jails (the problem occurs since I use th= ose), > > advice is appreciated. =20 >=20 > Not that I know of. >=20 >=20 I'll check the jails anyway. I was asking since I use on 5 jails lo1 - lo5 = with each having a dedicated loopback IP (127.0.1.1 - 127.0.5.1). And the jail host i= s reporting listening on all (cloned) loopback interfaces with UDP4, port 123. I have another machine in the very same network segment, but without jails.= I'll take the configuration and let that box run a while (it is more recent hardware = (Haswell XEON) and the very same recent CURRENT). =20 Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/AnUc3gF=nKU3g_pM6PEHylK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLQEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMrHvgAKCRDS528fyFhY lJRBAf4xyUZwnc80eZDltNc3Kn1rOg0JwrGA/TcPRjD7aCOL8oLhbXWrvw0RTvbi qh95PkDiIL+zOO2HckAJkmo0LGs9AfdXeEvNlMarWmCqKIW+7WKGOmgA6BMxxrj5 YH1ExY2ggUZ18/dxVmqcFnIavrg1E3cSM6trEkg3MPOoHRvEpWY= =rDBW -----END PGP SIGNATURE----- --Sig_/AnUc3gF=nKU3g_pM6PEHylK-- From owner-freebsd-current@freebsd.org Thu Mar 16 18:25:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0D4DD0F6E8 for ; Thu, 16 Mar 2017 18:25:16 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9A81D91 for ; Thu, 16 Mar 2017 18:25:16 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v2GIP8iu041279; Thu, 16 Mar 2017 11:25:12 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201703161825.v2GIP8iu041279@gw.catspoiler.org> Date: Thu, 16 Mar 2017 11:25:08 -0700 (PDT) From: Don Lewis Subject: Re: ntpd dies nightly on a server with jails To: ohartmann@walstatt.org cc: freebsd-current@freebsd.org In-Reply-To: <20170316181318.605a3e4f@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:25:16 -0000 On 16 Mar, O. Hartmann wrote: > Am Wed, 15 Mar 2017 13:12:37 -0700 > Cy Schubert schrieb: >> > >> > When the clock is floating that wild, in all cases ntpd isn't >> > running any mor e. >> > I try to restart with options -g and -G to adjust the time quickly >> > at the beginning, which works fine. >> >> This is disconcerting. If your clock is floating wildly without ntpd >> running there are other issues that might be at play here. At most >> the clock might drift a little, maybe a minute or two a day but not >> by a lot. Does the drift cause your clocks to run fast or slow? > > Today, I switched off ntpd on the jail-bearing host. After an hour or > so the gain of the clock wasn't apart from my DCF77 clock - at least > not within the granularity of the minutes. So I switched on ntpd > again. After a while, I checked status via "service ntpd status", and > I would bet off my ass that the result was "is running with PID XXX". > The next minute I did the same, the clock was off by almost half an > hour (always behind real time, never before!) and ntpd wasn't running. > A coincidence? I can not tell, I did a "clear" on the terminal :-( But > that was strange. I think that ntp might exit if it sees time going insane. According to this old discussion, the exit is silent: https://forum.pfsense.org/index.php?topic=53906.0 From owner-freebsd-current@freebsd.org Thu Mar 16 20:59:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61AA3D0F3B1 for ; Thu, 16 Mar 2017 20:59:09 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 271F61A31; Thu, 16 Mar 2017 20:59:08 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1cocUD-0002Tm-KW; Thu, 16 Mar 2017 21:59:05 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1cocUD-0000Jo-JE; Thu, 16 Mar 2017 21:59:05 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 16 Mar 2017 20:59:05 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "John Baldwin" CC: "freebsd-current" Subject: Re: info.0 dump good Date: Thu, 16 Mar 2017 13:59:05 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <3454489.WI3XFBSArZ@ralph.baldwin.cx> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:59:09 -0000 On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin wrote: > On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote: > > Seems to happen when Xorg has a large webpage or a page idle for a time > >=20 > > Dump header from device: /dev/gpt/WDswap > > Architecture: i386 > > Architecture Version: 2 > > Dump Length: 285376512 > > Blocksize: 512 > > Dumptime: Mon Mar 13 12:12:37 2017 > > Hostname: [redacted]com > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb 9 17:32:03 = PST 2017 > > com:/usr/obj/usr/src/sys/[custom kernel] > > Panic String: page fault > > Dump Parity: 1127850006 > > Bounds: 0 > > Dump Status: good > >=20 > > Viable to send the bounds, info.0 and vmcore.0 to somewhere where someo= ne not > > a comlete novice can find a bug somewhere? Unsure what email attachm= ent allows > > a 273MB file, an ftp server upstream ?? No time to use kdbg for a few= months anyway... >=20 > Do you have a core.txt.0 file? If so it should contain a stack trace from > kgdb which is the first thing that would be useful to obtain. >=20 > --=20 > John Baldwin Sent the core.text.8 question,=20 as not a kgbd expert, pending, earlier today, not to the list: Now to the list, one of several daily backtraces,=20 and/or lock order reversals, in dmesg, starting X,=20 mounting or unmounting 2nd disks... this from /var/log/messages... kernel: lock order reversal:=20=20 kernel: 1st 0xc21ebd84 ufs (ufs) @ kernel: 2nd 0xc2ca126c syncer (syncer) @ kernel: stack backtrace:=20=20=20 kernel: #0 0xb5c22421 at witness_debugger+0x81=20 kernel: #1 0xb5c22342 at witness_checkorder+0xd12=20 kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64=20 kernel: #3 0xb5c784ad at vop_stdlock+0x4d=20 kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7=20 kernel: #5 0xb5c9c137 at _vn_lock+0xb7=20 kernel: #6 0xb5c8b00a at vputx+0x16a=20 kernel: #7 0xb5c8286c at dounmount+0x5=20 kernel: dc=20=20=20=20 kernel: #8 0xb5c82185 at sys_unmount+0x315=20 kernel: #9 0xb6155fa5 at syscall+0x3b5=20 kernel: #10 0xb6140ede at Xint0x80_syscall+0x2e=20 kernel: lock order reversal:=20=20 kernel: 1st 0xc21ebd84 ufs (ufs) @ kernel: 2nd 0xc0175150 devfs (devfs) @ kernel: stack backtrace:=20=20=20 kernel: #0 0xb5c22421 at witness_debugger+0x81=20 kernel: #1 0xb5c22342 at witnes=20 kernel: s_checkorder+0xd12=20=20=20=20 kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64=20 kernel: #3 0x=20=20=20 kernel: b5c784ad at vop_stdlock+0x4d=20=20 kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7=20 kernel: #5 0xb5c9c137 at _vn_lock+0x=20 kernel: b7=20=20=20=20 kernel: #6 0xb5eb9617 at ffs_flushfiles+0x157=20 kernel: #7 0xb5e9d9aa at soft=20 kernel: dep_flushfiles+0x17a=20=20=20=20 kernel: #8 0xb5ebc04c at ffs_unmount+0x7c=20 kernel: #9 0xb5=20=20=20 kernel: c8299b at dounmount+0x70b=20=20 kernel: #10 0=20=20=20 kernel: xb5c82185 at sys_unmount+0x315=20=20 kernel: #11 0xb6155fa5 at syscall+0x3b5=20 kernel:=20=20=20=20=20 kernel: #12 0xb6140ede at Xint0x80_syscall+0x2e=20 =20 from the following two files: 1st 0xc21ebd84 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 2nd 0xc2ca126c syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762 From owner-freebsd-current@freebsd.org Thu Mar 16 22:22:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B1B5D0FD22 for ; Thu, 16 Mar 2017 22:22:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C010A36; Thu, 16 Mar 2017 22:22:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::6515:bd64:2b15:f93d] (unknown [IPv6:2001:7b8:3a7:0:6515:bd64:2b15:f93d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 100152ED1A; Thu, 16 Mar 2017 23:22:22 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_132B2AE5-4ABE-4B8A-BF3F-31744260BB36"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: process killed: text file modification Date: Thu, 16 Mar 2017 23:22:08 +0100 In-Reply-To: <1489340839.40576.82.camel@freebsd.org> Cc: Gergely Czuczy , FreeBSD Current , Rick Macklem To: Ian Lepore References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 22:22:26 -0000 --Apple-Mail=_132B2AE5-4ABE-4B8A-BF3F-31744260BB36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 12 Mar 2017, at 18:47, Ian Lepore wrote: > > On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote: >> >> On 2017. 03. 09. 20:47, Gergely Czuczy wrote: >>> >>> >>> >>> On 2017. 03. 09. 19:44, John Baldwin wrote: >>>> >>>> On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote: >>>>> >>>>> [+freebsd-fs] >>>>> >>>>> >>>>> On 2017. 03. 09. 14:20, Gergely Czuczy wrote: >>>>>> >>>>>> On 2017. 03. 09. 11:27, Gergely Czuczy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'm trying to build a few things from ports on an rpi3, the >>>>>>> ports >>>>>>> collection is mounted over NFS from another machine. When >>>>>>> it's trying >>>>>>> to build pkg i'm getting the error message in syslog: >>>>>>> >>>>>>> rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file >>>>>>> modification >>>>>>> >>>>>>> The report to pkg@: >>>>>>> https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/ >>>>>>> 002048.html >>>>>>> >>>>>>> >>>>>>> In ports-mgmt/pkg's config.log It fails at the following >>>>>>> entry: >>>>>>> configure:3726: checking whether we are cross compiling >>>>>>> configure:3734: cc -o conftest -O2 -pipe -Wno-error >>>>>>> -fno-strict-aliasing conftest.c >&5 >>>>>>> configure:3738: $? = 0 >>>>>>> configure:3745: ./conftest >>>>>>> configure:3749: $? = 137 >>>>>>> configure:3756: error: in >>>>>>> `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': >>>>>>> configure:3760: error: cannot run C compiled programs. >>>>>>> If you meant to cross compile, use `--host'. >>>>>>> See `config.log' for more details >>>>>>> >>>>>>> # uname -a >>>>>>> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: >>>>>>> Thu Mar 9 >>>>>>> 08:58:46 CET 2017 >>>>>>> aegir@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64. >>>>>>> aarch64/tank/rpi3/src/sys/AEGIR >>>>>>> >>>>>>> arm64 >>>>>> So far, a few additions: >>>>>> Time is synced between the NFS server and the client. >>>>>> it's an open() call which is getting the kill, and it's not >>>>>> the file >>>>>> what's being opened, but the process executing it. >>>>>> Here's a simple code that reproduces it: >>>>>> #include >>>>>> >>>>>> int main() { >>>>>> >>>>>> FILE *f = fopen ("/bar", "w"); >>>>>> >>>>>> fclose(f); >>>>>> return 0; >>>>>> } >>>>>> >>>>>> Conditions to reproduce it: >>>>>> - The resulting binary must be executed from the nfs mount >>>>>> - The binary must be built after mounting the NFS share. >>>>>> >>>>>> I haven't tried building it on a different host, I don't have >>>>>> access >>>>>> to multiple RPis. Also, if I build the binary, umount/remount >>>>>> the NFS >>>>>> mount point, which has the binary, execute it, then it works. >>>>>> >>>>>> I've also tried this with the raspbsd.org's image, I could >>>>>> reproduce >>>>>> it as well. >>>>>> >>>>>> Another interesting thing is, when I first booted the RPi up, >>>>>> the NFS >>>>>> server was a 10.2-STABLE, and later got updated to 11-STABLE. >>>>>> While it >>>>>> was 10.2 I've tried to build some port, and I don't remember >>>>>> having >>>>>> this issue. >>>>>> >>>>>> So, could someone please help me figure this out and fix it? >>>>>> This >>>>>> stuff should work pretty much. >>>>>> >>>>> So, this error message comes from here: >>>>> https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio >>>>> .c?revision=314436&view=markup#l1674 >>>>> >>>>> >>>>> It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np- >>>>>> n_vattr.na_mtime) >>>>> comparision that fails, np should be the NFS node structure, >>>>> from the >>>>> vnode's v_data, and n_vattr is the attribute cache. As I've >>>>> seen these >>>>> two are being updated together, so I don't really see by the >>>>> code why >>>>> they might differ. Could someone please take a look at it, with >>>>> more >>>>> experience in the NFS code? -czg >>>> Can you print out the two mtimes? I wonder if what's happening >>>> is that >>>> your server uses different granularity (for example just seconds) >>>> than >>>> your client, so on the client we generate a timestamp with a non- >>>> zero >>>> nanoseconds but when the server receives that timestamp it >>>> "truncates" >>>> it. During open() we forcefully re-fetch the timestamp (for CTO >>>> consistency) and then notice it doesn't match. For now I would >>>> start >>>> with comparing the timestamps and maybe the >>>> vfs.timestamp_precision >>>> sysctls on client and server (if server is a FreeBSD box). >>> Here are the time values: >>> Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + >>> -3298114786336 &np->n_vattr.na_mtime: -3298114786616 + >>> -3298114786608 >>> Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: >>> text >>> file modification >>> Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + >>> -3298114786336 &np->n_vattr.na_mtime: -3298114786616 + >>> -3298114786608 >>> Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: >>> text >>> file modification >>> >>> Printed this way: >>> printf("np->n_mtime: %ji + %ji >>> &np->n_vattr.na_mtime: %ji + %ji", >>> (intmax_t)(&np->n_mtime.tv_sec), >>> (intmax_t)(&np->n_mtime.tv_nsec), >>> (intmax_t)(&np->n_vattr.na_mtime.tv_sec), >>> (intmax_t)(&np->n_vattr.na_mtime.tv_nsec)); >> Sorry, I made a typo there. Here's it now: >> Mar 9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000 >> &np->n_vattr.na_mtime: 1489089935 + 221438000 >> Mar 9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text >> file >> modification >> Mar 9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000 >> &np->n_vattr.na_mtime: 1489089935 + 221438000 >> Mar 9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text >> file >> modification >> >> That's a difference of 2115 micro seconds. > > I think this is a problem that sysctl vfs.timestamp_precision is > supposed to help solve. Unfortunately, that knob doesn't provide very > much control; you can truncate timestamps to full seconds, > microseconds, or 1/Hz which may be milliseconds on many systems. > You've got a difference of about 2ms, so only the full seconds > granularity might help. > > It's also not clear to me whether that setting would have to be changed > on the server, or the client, or both. I'm also running into this problem, but while using lld. I must set vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both the client and the server, to make it work. Instead of GNU ld, lld uses mmap to write to the output executable. If this executable is more than one page, and resides on an NFS share, running it will almost always result in "text file modification", if vfs_timestamp_precision >= 2. A small test case: http://www.andric.com/freebsd/test-mmap-write.c, which writes a simple "hello world" i386-freebsd executable file, using the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() -> close(). Running this on an NFS share, and then attempting to run the resulting 'helloworld' executable will result in the "text file modification" error, and it will be killed. But if you simply copy the executable to something else, then it runs fine, even if you use -p to retain the properties! IMHO this is a rather surprising problem with the NFS code, and Kostik remarked that the problem seems to be that the VV_TEXT flag is set too early, before the nfs cache is invalidated. Rick, do you have any ideas about this? -Dimitry --Apple-Mail=_132B2AE5-4ABE-4B8A-BF3F-31744260BB36 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljLEB0ACgkQsF6jCi4glqOpwgCgzBHk9e6TPqWu/mGyFRG7aa83 2+UAoPwCmmT7t3/1DO5rQdOzmteWE42R =toeW -----END PGP SIGNATURE----- --Apple-Mail=_132B2AE5-4ABE-4B8A-BF3F-31744260BB36-- From owner-freebsd-current@freebsd.org Thu Mar 16 22:51:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85514D0F735; Thu, 16 Mar 2017 22:51:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660070.outbound.protection.outlook.com [40.107.66.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 226491A69; Thu, 16 Mar 2017 22:51:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Thu, 16 Mar 2017 22:51:08 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Thu, 16 Mar 2017 22:51:08 +0000 From: Rick Macklem To: Larry Rosenman , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Subject: Re: crash: umount_nfs: Current Thread-Topic: crash: umount_nfs: Current Thread-Index: AQHSnf9DKC+Zb1AjDkCvB/ns2F6CGqGYEmLZ Date: Thu, 16 Mar 2017 22:51:08 +0000 Message-ID: References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> In-Reply-To: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lerctr.org; dkim=none (message not signed) header.d=none;lerctr.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: effcb795-7e65-4bfb-cc6c-08d46cbeef5a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:bGFiKvN+TBALjnir/RexWlmMpMxAI4d24CbA32DVgU3R7ihJF5ol3Mo4v+fNegYf32TW4HAM0XJlQ8xFw3GnChiJMpeWWMeEdRT2/iuaDpSRTCsUrrC18CnrVARUassU2c2hoAZepXJhnbKmg9MZ+WvM6bipDt5N2eY6rsfaRDDrQGu3jzFVSNT1/27uptsmNcB498RorHx6bpv8NDnrGm4gleIfGhB3+YwstOPhJG23DXbkNKReTs+zaghwtxZG4OeUsgwjrmHSh7NfNM2+re4ls6Tj4VkXecjRPBvSy1VITCkZkgp++2Qe5xXLoOPQETY8tlyBER4fU9Vpz1lT7A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(250305191791016)(22074186197030)(209352067349851)(75325880899374)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39830400002)(377454003)(252514010)(7696004)(6246003)(2950100002)(3280700002)(3660700001)(229853002)(77096006)(6436002)(55016002)(4326008)(6306002)(54356999)(9686003)(53546008)(76176999)(53936002)(6506006)(33656002)(38730400002)(50986999)(53376002)(5660300001)(2906002)(102836003)(8676002)(2900100001)(305945005)(189998001)(81166006)(74482002)(966004)(2501003)(575784001)(122556002)(86362001)(8936002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 22:51:08.0436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 22:51:11 -0000 I believe the cause of this crash was fixed by a recent commit to head r313735 (which was MFC'd to stable/11 and stable/10). rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Larry Rosenman Sent: Wednesday, March 15, 2017 10:44:33 PM To: freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: crash: umount_nfs: Current Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT= . Lovely crash: borg.lerctr.org dumped core - see /var/crash/vmcore.1 Wed Mar 15 21:38:53 CDT 2017 FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue = Mar 14 20:55:36 CDT 2017 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-L= ER amd64 panic: general protection fault GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/de= bug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 1; apic id =3D 21 instruction pointer =3D 0x20:0xffffffff80a327ae stack pointer =3D 0x28:0xfffffe535ebb2800 frame pointer =3D 0x28:0xfffffe535ebb2830 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 3172 (umount) trap number =3D 9 panic: general protection fault cpuid =3D 1 time =3D 1489631515 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe535ebb2= 440 vpanic() at vpanic+0x19c/frame 0xfffffe535ebb24c0 panic() at panic+0x43/frame 0xfffffe535ebb2520 trap_fatal() at trap_fatal+0x322/frame 0xfffffe535ebb2570 trap() at trap+0x5e/frame 0xfffffe535ebb2730 calltrap() at calltrap+0x8/frame 0xfffffe535ebb2730 --- trap 0x9, rip =3D 0xffffffff80a327ae, rsp =3D 0xfffffe535ebb2800, rbp = =3D 0xfffffe535ebb2830 --- __mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfffffe535ebb2830 xprt_unregister() at xprt_unregister+0x28/frame 0xfffffe535ebb2850 clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfffffe535eb= b2880 nfs_unmount() at nfs_unmount+0x182/frame 0xfffffe535ebb28d0 dounmount() at dounmount+0x5c1/frame 0xfffffe535ebb2950 sys_unmount() at sys_unmount+0x30f/frame 0xfffffe535ebb2a70 amd64_syscall() at amd64_syscall+0x55a/frame 0xfffffe535ebb2bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe535ebb2bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip =3D 0x800872b9a, rsp =3D = 0x7fffffffde88, rbp =3D 0x7fffffffe3c0 --- Uptime: 2h43m8s Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%.= .91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/de= bug//boot/kernel/zfs.ko.debug...done. done. Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /us= r/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/lib/= debug//boot/kernel/linux.ko.debug...done. done. Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /usr/li= b/debug//boot/kernel/if_lagg.ko.debug...done. done. Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/coretemp.ko.debug...done. done. Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /usr/lib/= debug//boot/kernel/aesni.ko.debug...done. done. Reading symbols from /boot/kernel/filemon.ko...Reading symbols from /usr/li= b/debug//boot/kernel/filemon.ko.debug...done. done. Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/lib/d= ebug//boot/kernel/fuse.ko.debug...done. done. Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /usr/lib= /debug//boot/kernel/ichsmb.ko.debug...done. done. Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/lib/= debug//boot/kernel/smbus.ko.debug...done. done. Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /usr/lib/= debug//boot/kernel/ichwd.ko.debug...done. done. Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /usr/lib= /debug//boot/kernel/cpuctl.ko.debug...done. done. Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /usr/= lib/debug//boot/kernel/cryptodev.ko.debug...done. done. Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /usr/= lib/debug//boot/kernel/dtraceall.ko.debug...done. done. Reading symbols from /boot/kernel/profile.ko...Reading symbols from /usr/li= b/debug//boot/kernel/profile.ko.debug...done. done. Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr/lib= /debug//boot/kernel/dtrace.ko.debug...done. done. Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols f= rom /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done. done. Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/systrace.ko.debug...done. done. Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/lib/de= bug//boot/kernel/sdt.ko.debug...done. done. Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/fasttrap.ko.debug...done. done. Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/lib/de= bug//boot/kernel/fbt.ko.debug...done. done. Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /usr/li= b/debug//boot/kernel/dtnfscl.ko.debug...done. done. Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/dtmalloc.ko.debug...done. done. Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols found= )...done. Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /usr/lib/d= ebug//boot/kernel/ipmi.ko.debug...done. done. Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from /usr= /lib/debug//boot/kernel/ipmi_linux.ko.debug...done. done. Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from /usr/lib/= debug//boot/kernel/hwpmc.ko.debug...done. done. Reading symbols from /boot/kernel/mfip.ko...Reading symbols from /usr/lib/d= ebug//boot/kernel/mfip.ko.debug...done. done. Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/de= bug//boot/kernel/ums.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbols fo= und)...done. Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/netgraph.ko.debug...done. done. Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/ng_ether.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbols fo= und)...done. Reading symbols from /boot/kernel/linux64.ko...Reading symbols from /usr/li= b/debug//boot/kernel/linux64.ko.debug...done. done. Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/= lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/= debug//boot/kernel/tmpfs.ko.debug...done. done. __curthread () at ./machine/pcpu.h:232 232 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff80a52c15 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:386 #3 0xffffffff80a53206 in vpanic (fmt=3D, ap=3D0xfffffe535eb= b2500) at /usr/src/sys/kern/kern_shutdown.c:779 #4 0xffffffff80a53253 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:710 #5 0xffffffff80ecd5c2 in trap_fatal (frame=3D0xfffffe535ebb2740, eva=3D0) at /usr/src/sys/amd64/amd64/trap.c:801 #6 0xffffffff80eccb8e in trap (frame=3D0xfffffe535ebb2740) at /usr/src/sys/amd64/amd64/trap.c:197 #7 #8 __mtx_lock_flags (c=3D0xdeadc0dedeadc0f6, opts=3D0, file=3D0xffffffff8147e721 "/usr/src/sys/rpc/svc.c", line=3D380) at /usr/src/sys/kern/kern_mutex.c:239 #9 0xffffffff80cc14b8 in xprt_unregister (xprt=3D0xfffff8022e0fce00) at /usr/src/sys/rpc/svc.c:380 #10 0xffffffff80cbc058 in clnt_reconnect_destroy (cl=3D0xfffff80146fa3900) at /usr/src/sys/rpc/clnt_rc.c:500 #11 0xffffffff80969972 in nfs_unmount (mp=3D, mntflags=3D) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c= :1704 #12 0xffffffff80b0b761 in dounmount (mp=3D0xdeadc0dedeadc0f6, flags=3D13421= 7728, td=3D0xfffff8018f2eb000) at /usr/src/sys/kern/vfs_mount.c:1388 #13 0xffffffff80b0b11f in sys_unmount (td=3D0xfffff8018f2eb000, uap=3D0xfffffe535ebb2b70) at /usr/src/sys/kern/vfs_mount.c:1215 #14 0xffffffff80ecdfea in syscallenter (td=3D0xfffff8018f2eb000, sa=3D) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #15 amd64_syscall (td=3D0xfffff8018f2eb000, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:902 #16 Can't read data for section '.eh_frame' in file '/' (kgdb) vmcore / source IS available. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 16 23:46:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45013D1080E; Thu, 16 Mar 2017 23:46:54 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 238291F79; Thu, 16 Mar 2017 23:46:54 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bIDoYx6bqwxBbncBiO/XdOM4wgEKmL/LRCLQEi7kLgE=; b=lznJtgCfFieGPy+mC6umbBWYMs X/KbafVbDsLs9I5KgV+WFF0yPSf7IMXrZoPu8jX5Bxo0PY5EQmaY80ApL6abRgkwgdF1FI04YBdQE B5WwyaX7a2pyt6VBgDsNJVEJd+t7NO6Axf+5B68AEx/SjYD3wIuuBWlAgs0IM3KD8lFc=; Received: from [74.196.220.26] (port=5083 helo=[192.168.200.198]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cof6b-000LKv-4i; Thu, 16 Mar 2017 18:46:53 -0500 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 16 Mar 2017 18:46:51 -0500 Subject: Re: crash: umount_nfs: Current From: Larry Rosenman To: Rick Macklem , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Message-ID: Thread-Topic: crash: umount_nfs: Current References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 23:46:54 -0000 Err, I=E2=80=99m at r315289=E2=80=A6. --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 =20 =20 On 3/16/17, 5:51 PM, "Rick Macklem" wrote: I believe the cause of this crash was fixed by a recent commit to head r313735 (which was MFC'd to stable/11 and stable/10). =20 rick ________________________________________ From: owner-freebsd-current@freebsd.org on behalf of Larry Rosenman Sent: Wednesday, March 15, 2017 10:44:33 PM To: freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: crash: umount_nfs: Current =20 Recent current, playing with new FreeNAS Corral, client is FreeBSD -CUR= RENT. =20 Lovely crash: =20 borg.lerctr.org dumped core - see /var/crash/vmcore.1 =20 Wed Mar 15 21:38:53 CDT 2017 =20 FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: = Tue Mar 14 20:55:36 CDT 2017 root@borg.lerctr.org:/usr/obj/usr/src/sys/V= T-LER amd64 =20 panic: general protection fault =20 GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copyi= ng" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/li= b/debug//boot/kernel/kernel.debug...done. done. =20 Unread portion of the kernel message buffer: =20 =20 Fatal trap 9: general protection fault while in kernel mode cpuid =3D 1; apic id =3D 21 instruction pointer =3D 0x20:0xffffffff80a327ae stack pointer =3D 0x28:0xfffffe535ebb2800 frame pointer =3D 0x28:0xfffffe535ebb2830 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 3172 (umount) trap number =3D 9 panic: general protection fault cpuid =3D 1 time =3D 1489631515 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe535= ebb2440 vpanic() at vpanic+0x19c/frame 0xfffffe535ebb24c0 panic() at panic+0x43/frame 0xfffffe535ebb2520 trap_fatal() at trap_fatal+0x322/frame 0xfffffe535ebb2570 trap() at trap+0x5e/frame 0xfffffe535ebb2730 calltrap() at calltrap+0x8/frame 0xfffffe535ebb2730 --- trap 0x9, rip =3D 0xffffffff80a327ae, rsp =3D 0xfffffe535ebb2800, rbp =3D= 0xfffffe535ebb2830 --- __mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfffffe535ebb2830 xprt_unregister() at xprt_unregister+0x28/frame 0xfffffe535ebb2850 clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfffffe5= 35ebb2880 nfs_unmount() at nfs_unmount+0x182/frame 0xfffffe535ebb28d0 dounmount() at dounmount+0x5c1/frame 0xfffffe535ebb2950 sys_unmount() at sys_unmount+0x30f/frame 0xfffffe535ebb2a70 amd64_syscall() at amd64_syscall+0x55a/frame 0xfffffe535ebb2bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe535ebb2bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip =3D 0x800872b9a, rsp =3D = 0x7fffffffde88, rbp =3D 0x7fffffffe3c0 --- Uptime: 2h43m8s Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..= 81%..91% =20 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/li= b/debug//boot/kernel/zfs.ko.debug...done. done. Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from= /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/= lib/debug//boot/kernel/linux.ko.debug...done. done. Reading symbols from /boot/kernel/linux_common.ko...Reading symbols fro= m /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /us= r/lib/debug//boot/kernel/if_lagg.ko.debug...done. done. Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/coretemp.ko.debug...done. done. Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /usr/= lib/debug//boot/kernel/aesni.ko.debug...done. done. Reading symbols from /boot/kernel/filemon.ko...Reading symbols from /us= r/lib/debug//boot/kernel/filemon.ko.debug...done. done. Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/fuse.ko.debug...done. done. Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /usr= /lib/debug//boot/kernel/ichsmb.ko.debug...done. done. Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/= lib/debug//boot/kernel/smbus.ko.debug...done. done. Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /usr/= lib/debug//boot/kernel/ichwd.ko.debug...done. done. Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /usr= /lib/debug//boot/kernel/cpuctl.ko.debug...done. done. Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /= usr/lib/debug//boot/kernel/cryptodev.ko.debug...done. done. Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /= usr/lib/debug//boot/kernel/dtraceall.ko.debug...done. done. Reading symbols from /boot/kernel/profile.ko...Reading symbols from /us= r/lib/debug//boot/kernel/profile.ko.debug...done. done. Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr= /lib/debug//boot/kernel/dtrace.ko.debug...done. done. Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbo= ls from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done. done. Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/systrace.ko.debug...done. done. Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/li= b/debug//boot/kernel/sdt.ko.debug...done. done. Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/fasttrap.ko.debug...done. done. Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/li= b/debug//boot/kernel/fbt.ko.debug...done. done. Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /us= r/lib/debug//boot/kernel/dtnfscl.ko.debug...done. done. Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/dtmalloc.ko.debug...done. done. Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols f= ound)...done. Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/ipmi.ko.debug...done. done. Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from = /usr/lib/debug//boot/kernel/ipmi_linux.ko.debug...done. done. Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from /usr/= lib/debug//boot/kernel/hwpmc.ko.debug...done. done. Reading symbols from /boot/kernel/mfip.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/mfip.ko.debug...done. done. Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/li= b/debug//boot/kernel/ums.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbol= s found)...done. Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/netgraph.ko.debug...done. done. Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/ng_ether.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbol= s found)...done. Reading symbols from /boot/kernel/linux64.ko...Reading symbols from /us= r/lib/debug//boot/kernel/linux64.ko.debug...done. done. Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /= usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/= lib/debug//boot/kernel/tmpfs.ko.debug...done. done. __curthread () at ./machine/pcpu.h:232 232 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff80a52c15 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:386 #3 0xffffffff80a53206 in vpanic (fmt=3D, ap=3D0xfffffe535eb= b2500) at /usr/src/sys/kern/kern_shutdown.c:779 #4 0xffffffff80a53253 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:710 #5 0xffffffff80ecd5c2 in trap_fatal (frame=3D0xfffffe535ebb2740, eva=3D0) at /usr/src/sys/amd64/amd64/trap.c:801 #6 0xffffffff80eccb8e in trap (frame=3D0xfffffe535ebb2740) at /usr/src/sys/amd64/amd64/trap.c:197 #7 #8 __mtx_lock_flags (c=3D0xdeadc0dedeadc0f6, opts=3D0, file=3D0xffffffff8147e721 "/usr/src/sys/rpc/svc.c", line=3D380) at /usr/src/sys/kern/kern_mutex.c:239 #9 0xffffffff80cc14b8 in xprt_unregister (xprt=3D0xfffff8022e0fce00) at /usr/src/sys/rpc/svc.c:380 #10 0xffffffff80cbc058 in clnt_reconnect_destroy (cl=3D0xfffff80146fa3900= ) at /usr/src/sys/rpc/clnt_rc.c:500 #11 0xffffffff80969972 in nfs_unmount (mp=3D, mntflags=3D) at /usr/src/sys/fs/nfsclient/nfs_clvfsops= .c:1704 #12 0xffffffff80b0b761 in dounmount (mp=3D0xdeadc0dedeadc0f6, flags=3D13421= 7728, td=3D0xfffff8018f2eb000) at /usr/src/sys/kern/vfs_mount.c:1388 #13 0xffffffff80b0b11f in sys_unmount (td=3D0xfffff8018f2eb000, uap=3D0xfffffe535ebb2b70) at /usr/src/sys/kern/vfs_mount.c:1215 #14 0xffffffff80ecdfea in syscallenter (td=3D0xfffff8018f2eb000, sa=3D) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #15 amd64_syscall (td=3D0xfffff8018f2eb000, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:902 #16 Can't read data for section '.eh_frame' in file '/' (kgdb) =20 vmcore / source IS available. =20 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-current@freebsd.org Fri Mar 17 01:07:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B11B5D0EF2C for ; Fri, 17 Mar 2017 01:07:52 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 6E48917D2 for ; Fri, 17 Mar 2017 01:07:52 +0000 (UTC) (envelope-from rob.rodz.jr9@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id m27so7986810iti.0 for ; Thu, 16 Mar 2017 18:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6IsxZ+SKAGN5tvcGs0jvxDjqBJD0+02hXj12joOogks=; b=bbhySPK9WmlLAChbPIFDREHJ9LLbmZN7KCixGbAvEcT25eLJW5xYwNJSxasTTqpYkD UowWDSxtmepSnGDInBOsZAH/9FCPWebgL7zt0ngbVsrzNU82GUR5Qkn7eQdvcAN++5TN QZIZzLU1Ko3xhB9Zh46AEYZ6ZeKdnFhlXV9ocFzL4gPbABbk+K5xXMOeIYLoPZ9BBXjb eTe8r7rADiU+OZJIXncgxHb/8vZWraeksYNeEv8FgZBUkUn4xbAiJEvfWZW/+IFwzfi1 yRA3WBdZD3OJgSPKJQOB/19ljRlr4y05Yh9QkvC2S38oUP8dLIOfVrE8FvA2DnvDfIsx JZjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6IsxZ+SKAGN5tvcGs0jvxDjqBJD0+02hXj12joOogks=; b=InrHt2IZIsAqT+NVfuidw/9D1PC8WKKiNSs827UnRsfpm+RwV2H/tIthKt+dWOZuuB gye+EzVJWTUgTt19LrCbZOfM0goxCYvZ4goT27yez2m8NewbDxCqt5rj7803j8jQ7Z2Z xDwLUzhqGelJ/jT7Ei6hbzOtN6dgc88JopLJi0JEgEgrngWDtr6xi0Tzq0kcTFwXCTla B8HmHyzKlH6Gvvdk+lyEvd99VKyMnlc3jKNkNKYuSYCVU84Vy9fQg+AugXVx4HrLHZ62 kOs/vOMm8ZK9nY0w/VjI2Yq2Cf6AR9YPUgTo/8s8/hpRekIp8/Rywf1c/ya1nLwJLF4e KWPg== X-Gm-Message-State: AFeK/H3GsfvKAQ6STxOYCfnLFpwvd7VtRRl3b3bfbYE3MYDxJevxysAEGJmLisw+cKcjpnYRBA2teBlSYM7LjQ== X-Received: by 10.36.22.209 with SMTP id a200mr562170ita.117.1489712871666; Thu, 16 Mar 2017 18:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.226.228 with HTTP; Thu, 16 Mar 2017 18:07:51 -0700 (PDT) Received: by 10.64.226.228 with HTTP; Thu, 16 Mar 2017 18:07:51 -0700 (PDT) In-Reply-To: References: <20170315230723.GR1341@albert.catwhisker.org> From: Roberto Rodriguez Jr Date: Fri, 17 Mar 2017 01:07:51 +0000 Message-ID: Subject: Re: fail world build To: FreeBSD Current , David Wolfskill Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 01:07:52 -0000 Using r315340 I simply commented out those 3 lines and buildworld and kernel succesfuly compiled and installed. --- pciconf.o --- /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, -1, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of undeclared identifier 'PCIS_ACCEL_PROCESSING' {PCIC_ACCEL, PCIS_ACCEL_PROCESSING, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of undeclared identifier 'PCIC_INSTRUMENT' {PCIC_INSTRUMENT, Im sure there is fixes on the way since I have yet to update my src tree today :) Its been 15 days of fails and finally a fresh native world ;) Thank You Roberto From owner-freebsd-current@freebsd.org Fri Mar 17 01:57:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4956D0FC09 for ; Fri, 17 Mar 2017 01:57:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670059.outbound.protection.outlook.com [40.107.67.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D94F1DEF; Fri, 17 Mar 2017 01:57:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Fri, 17 Mar 2017 01:57:23 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Fri, 17 Mar 2017 01:57:23 +0000 From: Rick Macklem To: Dimitry Andric , Ian Lepore CC: Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIX Date: Fri, 17 Mar 2017 01:57:23 +0000 Message-ID: References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: harmless.hu; dkim=none (message not signed) header.d=none;harmless.hu; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: f6a7712a-ecd9-46e3-9d1e-08d46cd8f4a6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:UK9g98OHegZFbT37cYu72jKDHRKGc74BMWrAjpg8cDwItd/fA8l5foqu3o7mUm/y+5JpiNq0PsQtYucdWYAxP6qA43UvSG5qSUkBnzBS1C58ve4qD0a6yMWCk/uh4Da0lnbmYrIxv1/KyvRkKJF3RcsuPIeaIwgZVWi7xiQ8dYo1MHIN2udv5aQ+BpJZ6tR8aCkR6eWuztFGBTVQDpu7iAzGdx6ZpZh0L+vpdkv6ZEj9HuMtIswpq2cTQn0QBkbFfDsAIttutFRgh8ed5F37MBlCfUh8PVakd5coNm5sPy6C1Wkmhmf4OzDGJlXtss9KLvntFx/Z2IZ+9tr6UqEXyQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39830400002)(39450400003)(24454002)(2900100001)(229853002)(93886004)(54356999)(76176999)(50986999)(6436002)(33656002)(102836003)(6306002)(6506006)(55016002)(77096006)(54906002)(74482002)(74316002)(9686003)(305945005)(53936002)(7696004)(8936002)(2950100002)(122556002)(81166006)(86362001)(3660700001)(8676002)(2906002)(5660300001)(38730400002)(189998001)(6246003)(966004)(4326008)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 01:57:23.7971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 01:57:26 -0000 Dimitry Andric wrote: [lots of stuff snipped] > I'm also running into this problem, but while using lld. I must set > vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both > the client and the server, to make it work. >=20 > Instead of GNU ld, lld uses mmap to write to the output executable. If > this executable is more than one page, and resides on an NFS share, > running it will almost always result in "text file modification", if > vfs_timestamp_precision >=3D 2. >=20 > A small test case: http://www.andric.com/freebsd/test-mmap-write.c, > which writes a simple "hello world" i386-freebsd executable file, using > the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() -> > close(). Hopefully Kostik will correct me if I have this wrong, but I don't believe = any of the above syscalls guarantee that dirty pages have been flushed. At least for cases without munmap(), the writes of dirty pages can occur af= ter the file descriptor is closed. I run into this in NFSv4, where there is a C= lose (NFSv4 one) that can't be done until VOP_INACTIVE(). If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll see: if (NFS_ISV4(vp) && vp->v_type =3D=3D VREG) { 237 /* 238 * Since mmap()'d files do I/O after VOP_CLOSE(), the = NFSv4 239 * Close operations are delayed until now. Any dirty 240 * buffers/pages must be flushed before the close, so = that the 241 * stateid is available for the writes. 242 */ 243 if (vp->v_object !=3D NULL) { 244 VM_OBJECT_WLOCK(vp->v_object); 245 retv =3D vm_object_page_clean(vp->v_object, 0,= 0, 246 OBJPC_SYNC); 247 VM_OBJECT_WUNLOCK(vp->v_object); 248 } else 249 retv =3D TRUE; 250 if (retv =3D=3D TRUE) { 251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a_td, = 1, 0); 252 (void)nfsrpc_close(vp, 1, ap->a_td); 253 } 254 } Note that nothing like this is done for NFSv3. What might work is implementing a VOP_SET_TEXT() vnode op for the NFS client that does most of the above (except for nfsrpc_close()) and then set= s VV_TEXT. --> That way, all the dirty pages will be flushed to the server before the = executable starts executing. > Running this on an NFS share, and then attempting to run the resulting > 'helloworld' executable will result in the "text file modification" > error, and it will be killed. But if you simply copy the executable to > something else, then it runs fine, even if you use -p to retain the > properties! > > IMHO this is a rather surprising problem with the NFS code, and Kostik > remarked that the problem seems to be that the VV_TEXT flag is set too > early, before the nfs cache is invalidated. Rick, do you have any ideas > about this? I don't think it is the "nfs cache" that needs invalidation, but the dirty pages written by the mmap'd file need to be flushed, before the VV_TEXT is set, I think? If Kostik meant "attribute cache" when he said "nfs cache", I'll note that = the cached attributes (including mtime) are updated by the reply to every write= . (As such, I think it is the writes that must be done before setting VV_TEXT that is needed.) It is a fairly simple patch to create. I'll post one to this thread in a da= y or so unless Kostik thinks this isn't correct and not worth trying. rick From owner-freebsd-current@freebsd.org Fri Mar 17 03:11:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9AF4D0F50F for ; Fri, 17 Mar 2017 03:11:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670074.outbound.protection.outlook.com [40.107.67.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A62116AA; Fri, 17 Mar 2017 03:10:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Fri, 17 Mar 2017 03:10:58 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Fri, 17 Mar 2017 03:10:57 +0000 From: Rick Macklem To: Dimitry Andric , Ian Lepore CC: Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/bY= Date: Fri, 17 Mar 2017 03:10:57 +0000 Message-ID: References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: 150557e9-77af-4c33-a38a-08d46ce33b7a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0189; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:1pSi3cjWgA8WwcjqQn4EHQzm+CB49g5Lam/vfg+yMn83+UA8Now0q7npHP7nOd+S6D+y2hJFJi+a3cZ1vEhED8yGDBIADE6+31ZY5Kis2w+O4A6lnvjRGC4KSDjmFHHGDrwQZRDCIDaMSw3vm9QLYdS4qcjlwOstEVC1a3Bz5W12FGy4Uj/1I7y6PWELYYiHkSw0xNTsCbA3abLKcXLrY5dAVxnwlrPF/r66IcObHM3q8ZWk1vVb/ZmN4a0MSbxfu4jj52R5ckQpR7gF4EJYIVg/KOkJnxPyvEaWyAQG7yjs7t42W2GQI6DaLdK6zAQbpcbz8szYlKDIPvnIL1bJDQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39450400003)(39410400002)(377454003)(43234003)(24454002)(9686003)(6506006)(229853002)(54906002)(6436002)(74482002)(6306002)(7696004)(5660300001)(53936002)(93886004)(2950100002)(8676002)(74316002)(81166006)(55016002)(86362001)(8936002)(5890100001)(77096006)(102836003)(6246003)(50986999)(76176999)(99936001)(54356999)(122556002)(305945005)(38730400002)(2900100001)(3660700001)(4326008)(2906002)(33656002)(3280700002)(966004)(53546008)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB018944EF4248402AD421D825DD390YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 03:10:57.6570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 03:11:00 -0000 --_002_YTXPR01MB018944EF4248402AD421D825DD390YTXPR01MB0189CANP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hope you don't mind a top post... Attached is a little patch you could test maybe? rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Thursday, March 16, 2017 9:57:23 PM To: Dimitry Andric; Ian Lepore Cc: Gergely Czuczy; FreeBSD Current Subject: Re: process killed: text file modification Dimitry Andric wrote: [lots of stuff snipped] > I'm also running into this problem, but while using lld. I must set > vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both > the client and the server, to make it work. > > Instead of GNU ld, lld uses mmap to write to the output executable. If > this executable is more than one page, and resides on an NFS share, > running it will almost always result in "text file modification", if > vfs_timestamp_precision >=3D 2. > > A small test case: http://www.andric.com/freebsd/test-mmap-write.c, > which writes a simple "hello world" i386-freebsd executable file, using > the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() -> > close(). Hopefully Kostik will correct me if I have this wrong, but I don't believe = any of the above syscalls guarantee that dirty pages have been flushed. At least for cases without munmap(), the writes of dirty pages can occur af= ter the file descriptor is closed. I run into this in NFSv4, where there is a C= lose (NFSv4 one) that can't be done until VOP_INACTIVE(). If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll see: if (NFS_ISV4(vp) && vp->v_type =3D=3D VREG) { 237 /* 238 * Since mmap()'d files do I/O after VOP_CLOSE(), t= he NFSv4 239 * Close operations are delayed until now. Any dirt= y 240 * buffers/pages must be flushed before the close, = so that the 241 * stateid is available for the writes. 242 */ 243 if (vp->v_object !=3D NULL) { 244 VM_OBJECT_WLOCK(vp->v_object); 245 retv =3D vm_object_page_clean(vp->v_object,= 0, 0, 246 OBJPC_SYNC); 247 VM_OBJECT_WUNLOCK(vp->v_object); 248 } else 249 retv =3D TRUE; 250 if (retv =3D=3D TRUE) { 251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a_t= d, 1, 0); 252 (void)nfsrpc_close(vp, 1, ap->a_td); 253 } 254 } Note that nothing like this is done for NFSv3. What might work is implementing a VOP_SET_TEXT() vnode op for the NFS client that does most of the above (except for nfsrpc_close()) and then set= s VV_TEXT. --> That way, all the dirty pages will be flushed to the server before the = executable starts executing. > Running this on an NFS share, and then attempting to run the resulting > 'helloworld' executable will result in the "text file modification" > error, and it will be killed. But if you simply copy the executable to > something else, then it runs fine, even if you use -p to retain the > properties! > > IMHO this is a rather surprising problem with the NFS code, and Kostik > remarked that the problem seems to be that the VV_TEXT flag is set too > early, before the nfs cache is invalidated. Rick, do you have any ideas > about this? I don't think it is the "nfs cache" that needs invalidation, but the dirty pages written by the mmap'd file need to be flushed, before the VV_TEXT is set, I think? If Kostik meant "attribute cache" when he said "nfs cache", I'll note that = the cached attributes (including mtime) are updated by the reply to every write= . (As such, I think it is the writes that must be done before setting VV_TEXT that is needed.) It is a fairly simple patch to create. I'll post one to this thread in a da= y or so unless Kostik thinks this isn't correct and not worth trying. rick _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --_002_YTXPR01MB018944EF4248402AD421D825DD390YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="textmod.patch" Content-Description: textmod.patch Content-Disposition: attachment; filename="textmod.patch"; size=1210; creation-date="Fri, 17 Mar 2017 03:10:51 GMT"; modification-date="Fri, 17 Mar 2017 03:10:51 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jLnRleHQJMjAxNy0wMy0xNiAyMTo1NToxNi4y NjMzOTMwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jCTIwMTctMDMtMTYg MjI6Mzg6MzYuNTc1Njg3MDAwIC0wNDAwCkBAIC0xNDAsNiArMTQwLDcgQEAgc3RhdGljIHZvcF9h ZHZsb2NrX3QJbmZzX2FkdmxvY2s7CiBzdGF0aWMgdm9wX2FkdmxvY2thc3luY190IG5mc19hZHZs b2NrYXN5bmM7CiBzdGF0aWMgdm9wX2dldGFjbF90IG5mc19nZXRhY2w7CiBzdGF0aWMgdm9wX3Nl dGFjbF90IG5mc19zZXRhY2w7CitzdGF0aWMgdm9wX3NldF90ZXh0X3QgbmZzX3NldF90ZXh0Owog CiAvKgogICogR2xvYmFsIHZmcyBkYXRhIHN0cnVjdHVyZXMgZm9yIG5mcwpAQCAtMTc2LDYgKzE3 Nyw3IEBAIHN0cnVjdCB2b3BfdmVjdG9yIG5ld25mc192bm9kZW9wcyA9IHsKIAkudm9wX3dyaXRl ID0JCW5jbF93cml0ZSwKIAkudm9wX2dldGFjbCA9CQluZnNfZ2V0YWNsLAogCS52b3Bfc2V0YWNs ID0JCW5mc19zZXRhY2wsCisJLnZvcF9zZXRfdGV4dCA9CQluZnNfc2V0X3RleHQsCiB9OwogCiBz dHJ1Y3Qgdm9wX3ZlY3RvciBuZXduZnNfZmlmb29wcyA9IHsKQEAgLTMzNzMsNiArMzM3NSwyNCBA QCBuZnNfc2V0YWNsKHN0cnVjdCB2b3Bfc2V0YWNsX2FyZ3MgKmFwKQogCXJldHVybiAoZXJyb3Ip OwogfQogCitzdGF0aWMgaW50CituZnNfc2V0X3RleHQoc3RydWN0IHZvcF9zZXRfdGV4dF9hcmdz ICphcCkKK3sKKwlzdHJ1Y3Qgdm5vZGUgKnZwID0gYXAtPmFfdnA7CisKKwkvKgorCSAqIElmIHRo ZSB0ZXh0IGZpbGUgaGFzIGJlZW4gbW1hcCdkLCB0aGUgZGlydHkgcGFnZXMgbXVzdCBiZSBmbHVz aGVkCisJICogc28gdGhhdCB0aGUgbW9kaWZ5IHRpbWUgb2YgdGhlIGZpbGUgd2lsbCBiZSB1cCB0 byBkYXRlLgorCSAqLworCWlmICh2cC0+dl9vYmplY3QgIT0gTlVMTCkgeworCQlWTV9PQkpFQ1Rf V0xPQ0sodnAtPnZfb2JqZWN0KTsKKwkJdm1fb2JqZWN0X3BhZ2VfY2xlYW4odnAtPnZfb2JqZWN0 LCAwLCAwLCBPQkpQQ19TWU5DKTsKKwkJVk1fT0JKRUNUX1dVTkxPQ0sodnAtPnZfb2JqZWN0KTsK Kwl9CisJdnAtPnZfdmZsYWcgfD0gVlZfVEVYVDsKKwlyZXR1cm4gKDApOworfQorCiAvKgogICog UmV0dXJuIFBPU0lYIHBhdGhjb25mIGluZm9ybWF0aW9uIGFwcGxpY2FibGUgdG8gbmZzIGZpbGVz eXN0ZW1zLgogICovCg== --_002_YTXPR01MB018944EF4248402AD421D825DD390YTXPR01MB0189CANP_-- From owner-freebsd-current@freebsd.org Fri Mar 17 06:41:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E94AED108A5 for ; Fri, 17 Mar 2017 06:41:35 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa02a.plala.or.jp (msa02.plala.or.jp [58.93.240.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5D0123F for ; Fri, 17 Mar 2017 06:41:34 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc02.plala.or.jp ([172.23.12.32]) by msa02b.plala.or.jp with ESMTP id <20170317064057.OLST21413.msa02b.plala.or.jp@msc02.plala.or.jp> for ; Fri, 17 Mar 2017 15:40:57 +0900 Received: from localhost ([2400:7800:4d3a:6100:5e51:4fff:fe11:73f3]) by msc02.plala.or.jp with ESMTP id <20170317064057.LDBB18406.msc02.plala.or.jp@localhost> for ; Fri, 17 Mar 2017 15:40:57 +0900 Date: Fri, 17 Mar 2017 15:40:53 +0900 (JST) Message-Id: <20170317.154053.1899648480680625098.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: How to automount an internal ntfs partition ? From: Masachika ISHIZUKA X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa02m; Fri, 17 Mar 2017 15:40:58 +0900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 06:41:36 -0000 Hi. I want to automount an ntfs partition on internal SSD. I did following on FreeBSD 12.0-CURRENT #0 r315059. (1) install sysutils/fusefs-ntfs (2) add fuse_load="YES" to /boot/loader.conf (3) add '/- -noauto' to /etc/auto_master (4) add '/dev/ada0p4 /windows ntfs rw,noauto,uid=XXX,gid=XXX,dmask=022,fmask=133,locale=ja_JP.UTF-8,mountprog=/usr/local/bin/ntfs-3g,nosuid 0 0' to /etc/fstab (5) reboot At startup, the ntfs partition is on map as follows. % mount | grep windows map -noauto on /windows (autofs) % And it is automounted if I accessed it. % ls /windows /windows: $GetCurrent/ ProgramData/ $Recycle.Bin/ Recovery/ $WINRE_BACKUP_PARTITION.MARKER System Volume Information/ Android/ Users/ BOOTNXT Windows/ Documents and Settings@ Windows10Upgrade/ ESD/ bootmgr Intel/ pagefile.sys Logs/ remixos_install.log PerfLogs/ swapfile.sys Program Files (x86)/ tmp/ Program Files/ % And the map is corrent. % mount | grep windows map -noauto on /windows (autofs) /dev/fuse on /windows (fusefs, local, nosuid, synchronous, automounted) % But I don't access for 10 minutes, /windows is unmounted by autounmountd. Then map is disappear. % mount | grep windows % So /windows is no longer automounted. % ls /windows % How can I configure automountd for an internal ntfs partition. It is working well for ufs partitions and fat partitions. # I want to automatic unmount partitions that are not accessed for a long time because it prevent from damage if some panic occurred. # 11.0-RELEASE-p8 is the same result. -- Masachika ISHIZUKA From owner-freebsd-current@freebsd.org Fri Mar 17 08:36:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32A36D0FC30 for ; Fri, 17 Mar 2017 08:36:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEF18128A; Fri, 17 Mar 2017 08:36:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2H8a64b015268 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 10:36:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2H8a64b015268 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2H8a5Pf015267; Fri, 17 Mar 2017 10:36:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2017 10:36:05 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170317083605.GQ16105@kib.kiev.ua> References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:36:12 -0000 On Fri, Mar 17, 2017 at 03:10:57AM +0000, Rick Macklem wrote: > Hope you don't mind a top post... > Attached is a little patch you could test maybe? > > rick > ________________________________________ > From: owner-freebsd-current@freebsd.org on behalf of Rick Macklem > Sent: Thursday, March 16, 2017 9:57:23 PM > To: Dimitry Andric; Ian Lepore > Cc: Gergely Czuczy; FreeBSD Current > Subject: Re: process killed: text file modification > > Dimitry Andric wrote: > [lots of stuff snipped] > > I'm also running into this problem, but while using lld. I must set > > vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both > > the client and the server, to make it work. > > > > Instead of GNU ld, lld uses mmap to write to the output executable. If > > this executable is more than one page, and resides on an NFS share, > > running it will almost always result in "text file modification", if > > vfs_timestamp_precision >= 2. > > > > A small test case: http://www.andric.com/freebsd/test-mmap-write.c, > > which writes a simple "hello world" i386-freebsd executable file, using > > the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() -> > > close(). > Hopefully Kostik will correct me if I have this wrong, but I don't believe any > of the above syscalls guarantee that dirty pages have been flushed. > At least for cases without munmap(), the writes of dirty pages can occur after > the file descriptor is closed. I run into this in NFSv4, where there is a Close (NFSv4 one) > that can't be done until VOP_INACTIVE(). > If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll see: > if (NFS_ISV4(vp) && vp->v_type == VREG) { > 237 /* > 238 * Since mmap()'d files do I/O after VOP_CLOSE(), the NFSv4 > 239 * Close operations are delayed until now. Any dirty > 240 * buffers/pages must be flushed before the close, so that the > 241 * stateid is available for the writes. > 242 */ > 243 if (vp->v_object != NULL) { > 244 VM_OBJECT_WLOCK(vp->v_object); > 245 retv = vm_object_page_clean(vp->v_object, 0, 0, > 246 OBJPC_SYNC); > 247 VM_OBJECT_WUNLOCK(vp->v_object); > 248 } else > 249 retv = TRUE; > 250 if (retv == TRUE) { > 251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a_td, 1, 0); > 252 (void)nfsrpc_close(vp, 1, ap->a_td); > 253 } > 254 } > Note that nothing like this is done for NFSv3. > What might work is implementing a VOP_SET_TEXT() vnode op for the NFS > client that does most of the above (except for nfsrpc_close()) and then sets > VV_TEXT. > --> That way, all the dirty pages will be flushed to the server before the executable > starts executing. > > > Running this on an NFS share, and then attempting to run the resulting > > 'helloworld' executable will result in the "text file modification" > > error, and it will be killed. But if you simply copy the executable to > > something else, then it runs fine, even if you use -p to retain the > > properties! > > > > IMHO this is a rather surprising problem with the NFS code, and Kostik > > remarked that the problem seems to be that the VV_TEXT flag is set too > > early, before the nfs cache is invalidated. Rick, do you have any ideas > > about this? > I don't think it is the "nfs cache" that needs invalidation, but the dirty > pages written by the mmap'd file need to be flushed, before the VV_TEXT > is set, I think? > > If Kostik meant "attribute cache" when he said "nfs cache", I'll note that the > cached attributes (including mtime) are updated by the reply to every write. > (As such, I think it is the writes that must be done before setting VV_TEXT > that is needed.) > > It is a fairly simple patch to create. I'll post one to this thread in a day or so > unless Kostik thinks this isn't correct and not worth trying. > I think that the patch is in right direction, but I am not convinced that it is enough. What we need is to ensure that mtime on server does not change after VV_TEXT is set. Dirty pages indeed would cause the mtime update on flush, but wouldn't dirty buffers writes cause the same issue ? In other words, I think that enchanced VOP_SET_TEXT() for nfs must flush everything to ensure that mtime on server would not change due to further actions by this machine' nfs client. From owner-freebsd-current@freebsd.org Fri Mar 17 11:20:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4289D0BDC1 for ; Fri, 17 Mar 2017 11:20:33 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07FEA1CF5 for ; Fri, 17 Mar 2017 11:20:32 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGzwE-1d1XEQ2sMM-00DpWX for ; Fri, 17 Mar 2017 12:20:24 +0100 Date: Fri, 17 Mar 2017 12:20:18 +0100 From: "O. Hartmann" To: freebsd-current Subject: CURRENT: massive em0 NIC problems since IFLIB changes/introduction Message-ID: <20170317122018.21384497@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0VcdCTTUvf9XNbv6KUwVXSVvQchrOgpvIo9SNzCcKQeXcP2qyE3 2VulHmayGPThvPfFnsFVW28XXVjQjfyZo+Wq8nk8ioYwvho1N3TKpgQfQNpqzVZXhJvZi1b 9867DM4V0UQyji6xygNMg+1elxNXTi3Uxoyg//YeSNOeOdAkG7Ge9YKY/Vb1/0DhkPLFuIL s374hb0DLVBJUV9EbGHaA== X-UI-Out-Filterresults: notjunk:1;V01:K0:dpcjIX3bE2g=:zIN6+QA281pPHKw+HrlSs3 FjtbCzCxij2v7srMo6PrD8uxtAeBUkvgXMHo8NyMxliKjQNZmfnFZiylPkn8WEiOhGRGUeU75 Pl5aa/tgG72Kb/JaHSck+i6c3wnNRrqdYA4HAN4F6U4vLITgQEB3pIq/MiljMkKJ4VdsGoNxW 3LEt6L++URWfVCeluSZK8/21GqMkLMnioSUAL7MyX1yMZ29ii7QiWsNfWbWi9MYtM8Dn12VUX btsH7uLMuhFVMhGOtgMIAJFn96wdStqMsegvzU1uawiRV+/wzgHlRIyiW2EgDpQ8UG4Lj2wpT qL4s09w2GdzqbcSHNWMHo+KULIQSxqBBtJUxCLt5WlVm/c6lFg22OuoRDisxSwsfX4Sy0G6qL PFd2vyZpomzaixA4CyFlm/W9TV+fNRsDeXeAk7oD+vvcDgQDvrFWNg50fcnTvPnuU3NHnt5j2 9uteR7qYq0v4FOI49isQzJtI/aQgDEYZHPsDyxnSsgVMPMdtPLNWpUi3IfMuo2X5SVx3xalJ5 HOJQX4RAM9rC1+f7Tm9QGSus92zdx8nhfCKWLT+BXoVmC03YxJe13BNdCvR+Sr8JV2sSnTPeY +24FeabfmXUtJqyHwvLzq8HV1goHR5tEhoW+4edgIcSkkaTPyNnPA8kHhH2LSQuQcDb2Z2M+L /y/oVOBhpMXC393tCzXQv5R38lmCWEwL5F0vj7CP3RggbKBlW02tEz7Mq2roc5rgaB6G9poN/ /U/kt8ZI3md+j2JGRNBTUuJcKkFMFL+kMycItf7dp8zrkutgsCneChaitOuQv3W2J7qa7DWjy RNKEaJL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 11:20:33 -0000 Since the introduction of the IFLIB changes, I realise severe problems on CURRENT. Running the most recent CURRENT (FreeBSD 12.0-CURRENT #27 r315442: Fri Mar 17 10:46:04 CET 2017 amd64), the problems on a workstation got severe within the past two days: since a couple of weeks the em0 NIC (Intel i217-LM, see below) dies on heavy I/O. I realised this first when "rsync"ing poudriere repositories to a remote NFSv4 (automounted) folder. The em0 device could be revived by ifconfig down/up procedure. But not the i217-LM chip is affected. On another box equipted with a i350 dual port GBit NIC I observed a similar behaviour under (artificially) high I/O load (but I didn't investigate that further since it occured very seldom). Now, since around yesterday, the i217-LM dies without being reviveable with ifconfig down/up: Doing so, my FreeBSD CURRENT machine (Fujitsu Celsius M740) remains with a dead em0 device, reporting "no route" in some occasions but stuck in the dead state. Every attempt to establish manually the route again fails, only rebooting the box gives some relief. On the console, I have some very strange reports: - ping reports suddenly about no buffer space - or I see sometimes massive occurences of "em0: TX(0) desc avail = 1024, pidx = 0" on the console Either way, sending/receiving large files on an established network GBit line which could be saturated by approx 100 MBytes/s tend to make the NIC fail. Since yesterday, it is quite impossible to tranfer larger files in a burst, the NIC dies rapidly and can not be revived anymore except via reboot. Kind regards, O. Hartmann From owner-freebsd-current@freebsd.org Fri Mar 17 11:28:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1650DD0E164 for ; Fri, 17 Mar 2017 11:28:49 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0307512B4 for ; Fri, 17 Mar 2017 11:28:49 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id F38B4D0E162; Fri, 17 Mar 2017 11:28:48 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3338D0E161 for ; Fri, 17 Mar 2017 11:28:48 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B810D12B3 for ; Fri, 17 Mar 2017 11:28:47 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1coq3p-0006jn-25 for current@freebsd.org; Fri, 17 Mar 2017 12:28:45 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1coq3p-0004DH-0w for current@freebsd.org; Fri, 17 Mar 2017 12:28:45 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Fri, 17 Mar 2017 11:28:44 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" Subject: backtrace within dmesg Date: Fri, 17 Mar 2017 04:28:44 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 11:28:49 -0000 from /var/log/messages OR the periodic run OR both Still daily lockups in Xorg when browsers open, sometimes when not.=20 + __stack_chk_init(0)... random: unblocking device. +done. +#3 0xb752ad7e at os_acquire_mutex+0x3e +#4 0xb7434583 at _nv019165rm+0xb +Expensive timeout(9) function: 0xb55a7b40(0xbe67c000) 0.031685381 s +Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.779665921 s +SMP: AP CPU #4 Launched! +SMP: AP CPU #2 Launched! +SMP: AP CPU #5 Launched! + init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600025054 Hz quality= 1000 +WARNING: / was not properly dismounted + 1st 0xddc38f04 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3500 + 2nd 0xbf533200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 +GEOM_SCHED: Loading: mp =3D 0xbffb1084, g_sched_class =3D 0xbffb1084. +#3 0xb752b1dc at os_acquire_spinlock+0x2c +#4 0xb7262374 at _nv011973rm+0x190 + 1st 0xc1191a30 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3364 + 2nd 0xddc506e8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280 + 3rd 0xc2abfc68 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600 +#9 0xb5eafc55 at softdep_sync_buf+0xb55 +#11 0xb5ebe4b4 at ffs_fdatasync+0x24 +#12 0xb6192057 at VOP_FDATASYNC_APV+0xd7 +#13 0xb5c9868d at kern_fsync+0x21d +#14 0xb5c98762 at sys_fdatasync+0x22 +#15 0xb6155fa5 at syscall+0x3b5 +#16 0xb6140ede at Xint0x80_syscall+0x2e +Expensive timeout(9) function: 0xb5bd5c90(0xc01f3000) 2.169794100 s From owner-freebsd-current@freebsd.org Fri Mar 17 11:36:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0D1D0E40A for ; Fri, 17 Mar 2017 11:36:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C23DC17B7 for ; Fri, 17 Mar 2017 11:36:28 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQeET-1ced2y3zpt-00U5Lf for ; Fri, 17 Mar 2017 12:36:26 +0100 Date: Fri, 17 Mar 2017 12:36:25 +0100 From: "O. Hartmann" To: freebsd-current Subject: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gNXboaAcqbuhFJFfu9oAEI/tSkYn8DutIO1wc+7mkFhFHY9juqI PjGQz8mxJM5e0EPj+iSa7lEsKIybRxzWflZWMvUSHzxWnMD+czNcYZeNZAIIXiDvkvOeo8b vm6O9cqyPHyyFRciK00JVpk0/6eK2ugCNQG8yUs/zHhMzWjNZy+dEZNpGV6HsGo9KPhHuHi MAMDb3ej3Yy31nFXKJPaA== X-UI-Out-Filterresults: notjunk:1;V01:K0:SGm8bVj+sHQ=:pjk7GI6nJoccDwBa4iuAIR Tl1Qxk1+6ojJgKU5fZqRhHQ8Nt2ykWNHJj1UAFyF7sTfYJfay3VD1nEU6jsYCs4IuMaysBabZ ffRLiFtPAhgecQUNfLEEDgrXKDdTdVqi2r9hC6LAcZYC/3PEpEeCe7oReGz06bfgA0RdtxcSI MTbJUTMEPnFWTNi2tKhS8qk8V/yJmyQ1GZbtkWPEMIjZf6wOmipusapLkmtY8ia0lsZnduC1f m/rMf7exUf3MZ8I+bxFXFA1fN/Y2SmjimmDQtZsMqh1uktDNq/7DDa+N8IMf/kRUF1tTebjG3 zZIsGV4+8gFii/ysqPAROi00YhbiqUvkzjj7PJv6uA3FFJkXpFvf+XaglOzHnYGm5Vqjw28lB B532hQSHbbmnr8mn3PJ3Mst4hnvhow9+ELWGqMzJpkTvByhE31C/h/2Dk3eQwixI/8L9GGCR8 ZHXn3cgDy5HlU6zfGRhNn18T7mbrwKAdITijeVQbkYi7cP9fqJJ/Dtam08WniwjwQepOs6n5h SrOaaPiwULZEBM6G3zRphL2zRFFWUWx5Ez3WconYzmiVydw33Prx4VfeXn4SeHP4/V++0PX4f QgbzauVwYdhH6pwjVpuYFsv49NZxS9PScRyUBWCE+fOmz6oos8RSBvLAacb2PAMxkHYGBqPrP DuXTFPFySlxfkJIQEBluT+xSsDAxFpvPzfJv4L/DMaZ4H4co3mV7rOqgYf+P3Q0fCpRxZJRXd fRCpn4hCrZWKdIxlQzqqoa/Fl9IzeJLfNxdsOA8jJff+y3zgwq8AR/dqIj58fPLPhyKEFK8ni DR72Gpg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 11:36:29 -0000 Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. FreeBSD does not report the existence or availability of AES-NI feature, which is supposed to be a feature of this type of CPU: dmesg [...] FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM 4.0.0) VT(efifb): resolution 1920x1200 CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.99-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xbfebfbff Features2=0x7dfefbff AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x37ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 32990359552 (31462 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 hardware threads Security policy loaded: TrustedBSD MAC/BSD Extended (mac_bsdextended) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard SMP: AP CPU #1 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #3 Launched! random: entropy device external interface kbd0 at kbdmux0 netmap: loaded module random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 cryptosoft0: on motherboard aesni0: No AESNI support. [...] This system has the most recent firmware I could find on fujitsu.com. Recent dmidecode doesn't work, it reports [...] root@furor:~ # dmidecode # dmidecode 3.0 Scanning /dev/mem for entry point. # No SMBIOS nor DMI entry point found, sorry. A while ago, I filed a report to Fujitsu's customer service. They stupidly ansered with an extraction of Intel's ARK information regarding the CPU type indicating that the CPU does have AES-NI - they completely ignored the fact that I claimed that this is an hardware malfunction. So, after I reported in I've been using FreeBSD UNIX as the operating system, I received a short answer: UNIX is not supported. So, I'll ask here for some advice and will check the possibility whether FreeBSD is incapable of enabling those features or whether this is a firmware/hardware bug I want Fujitsu to fix. Can someone sched some light on this, please? Are there Haswell XEONs known for bugs like this? Thank you very much in advance, Oliver From owner-freebsd-current@freebsd.org Fri Mar 17 12:04:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0A0FD0F600 for ; Fri, 17 Mar 2017 12:04:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 72E4D1CA7 for ; Fri, 17 Mar 2017 12:04:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1coqcP-000HkV-8x; Fri, 17 Mar 2017 15:04:29 +0300 Date: Fri, 17 Mar 2017 15:04:29 +0300 From: Slawa Olhovchenkov To: "O. Hartmann" Cc: freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317120429.GX15630@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 12:04:32 -0000 On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > FreeBSD does not report the existence or availability of AES-NI feature, which > is supposed to be a feature of this type of CPU: What reassons to detect AES-NI by FreeBSD? Other OS detect AES-NI on this server? AES-NI may be disabled by BIOS/vendor/BIOS settings https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/AES-NI-is-disabled-on-my-13-New-S2/td-p/3498468 http://h17007.www1.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_060216/s_enable_AES-NI.html http://en.community.dell.com/support-forums/servers/f/956/t/19509653 From owner-freebsd-current@freebsd.org Fri Mar 17 13:15:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE6CD10CD6 for ; Fri, 17 Mar 2017 13:15:24 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 297EC169E; Fri, 17 Mar 2017 13:15:24 +0000 (UTC) (envelope-from Alexander@leidinger.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1489756502; bh=AJaTWFNqtXUjTyuNpHkKnnhb6BKrH2arAVWjM6vU+k0=; h=Date:From:To:Subject:In-Reply-To; b=3qj0J3wrKb2zC+4pn1Ln4Vs4FwT241SqVpR/gj8/POcr4B7t3oWBv32FlgjLdEUAp Ii4CfoejaA19BaH6d3UrVjQpHgXa0NoMNzpAi5TpkCSh+iKu0vPlfWklgD10tgbaTs KszYFwG1AFXFKhXJuglDig9u+ybiozc2Rc9c80rTUnil+8mb6L1vVd2pRct1HF2sVF r6SJV0UGP3/j+P/FVenUAconraTji+WYCeyqCFEapL9cn3Gmn0pf8/34wEtg7VXcBZ IplffY+OH/TCNYGzwKLQ/Wzrnaas9lxfU01zx/puZdY+GlmILQD//zyBNAVBRZe2rK pH/vZJVWcEbVw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1489756521; bh=AJaTWFNqtXUjTyuNpHkKnnhb6BKrH2arAVWjM6vU+k0=; h=Date:From:To:Subject:In-Reply-To; b=xLD+ZBiye5S94LNsHEeR6QNYLcowQLL7G3DyoaBZI54LkcTRVdQxyz0xnYHfVPPfm QL/WjlpI84mZ6gM3uAmLfKlj6isOhlMlFYfqteWrt9pyoZvsB6/6BiOBDS/nRD+thq +Q1bHS5xvHZqReXDC+r8M5/bCsDcIti2d8l/g3EtDGwlgjIhdPfytFbhGZAdPsy4sm Jz5F3aQk+RXHxuwKQalWo09yxblHC/xPLTk0Bd24pM4+Z2VwL4Ufv9IltjaZfTt23n j3l4iKH95fl8VqEzyYcPkaV4CukDZhzyCQx4ozCcW+5x1DY/yoXzqRvz+PsWcGOhZr DbR6xQ9dmBIuQ== Date: Fri, 17 Mar 2017 14:15:01 +0100 Message-ID: <20170317141501.Horde.YTCr8GuMV2yI1YaUkdRTLlu@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-current@freebsd.org, sbruno@freebsd.org, mmacy@nextbsd.org Subject: Re: CURRENT: massive em0 NIC problems since IFLIB changes/introduction In-Reply-To: <20170317122018.21384497@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_AtAW9EhHBcEoJFkw-6Jexgy"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:15:24 -0000 This message is in MIME format and has been PGP signed. --=_AtAW9EhHBcEoJFkw-6Jexgy Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting "O. Hartmann" (from Fri, 17 Mar 2017=20=20 12:20:18=20+0100): > Since the introduction of the IFLIB changes, I realise severe problems on > CURRENT. I already reported something like this to sbruno@ and M. Macy (in copy). > Running the most recent CURRENT (FreeBSD 12.0-CURRENT #27 r315442: Fri Ma= r 17 > 10:46:04 CET 2017 amd64), the problems on a workstation got severe=20=20 >=20within the > past two days: > > since a couple of weeks the em0 NIC (Intel i217-LM, see below) dies on he= avy > I/O. I realised this first when "rsync"ing poudriere repositories to a re= mote > NFSv4 (automounted) folder. The em0 device could be revived by=20=20 >=20ifconfig down/up > procedure. > But not the i217-LM chip is affected. On another box equipted with a=20= =20 >=20i350 dual > port GBit NIC I observed a similar behaviour under (artificially)=20=20 >=20high I/O load > (but I didn't investigate that further since it occured very seldom). It's not only those chipsets. It may be beneficial if you could provide the pciconf output for those=20= =20 devices.=20Mine is: ---snip--- em0@pci0:2:6:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086=20=20 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82541PI Gigabit Ethernet Controller' ---snip--- > Now, since around yesterday, the i217-LM dies without being reviveable wi= th > ifconfig down/up: Doing so, my FreeBSD CURRENT machine (Fujitsu Celsius M= 740) I don't know if for the chip I see this issue with a simple down/up=20=20 would=20help (it's a headless server in a remote datacenter). For the=20=20 moment=20I'm using the workaround of something like "ping -C 1 =20= =20 ||=20shutdown -r now" in crontab. The system in question is at r314137. > remains with a dead em0 device, reporting "no route" in some occasions bu= t > stuck in the dead state. Every attempt to establish manually the route ag= ain > fails, only rebooting the box gives some relief. > > On the console, I have some very strange reports: > > - ping reports suddenly about no buffer space > - or I see sometimes massive occurences of "em0: TX(0) desc avail =3D=20= =20 >=201024, pidx > =3D 0" on the console I don't see this in messages or console log, but I see that ntpd can't=20= =20 resolve=20hostnames in the logs. > Either way, sending/receiving large files on an established network GBit = line > which could be saturated by approx 100 MBytes/s tend to make the NIC fail= . I can report that the "svnlite update" on the box of of the FreeBSD=20=20 src=20tree is able to trigger the issue in my case. I have to add that before the iflib changes I've seen frequent=20=20 em-watchdog=20timeouts in the logs / dmesg. So for me we have two issues=20= =20 here: =20 - the hardware wasn't 100% supported before the iflib changes (it seems= ) - the iflib changes have lost some watchdog functionality /=20=20 auto-failure-recovery=20feature Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_AtAW9EhHBcEoJFkw-6Jexgy Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy+FVAAoJEKrxQhqFIICEHKoQAKU3nPovl+i/j7kn1DmmSDlQ NNs0DF3+Ist19T8p8aZ0H4H5Xbb/m3eS/lL0iqprtLS2Bc0n0RzLBcJ2BOTtNfps S4NaX3pe4BHVS24A64Yz1+v4w7Gv6Y7mFpT/QfYK9gA7eXfiKfCQeP3cVnNrwNTu BDKYNamxgZtWTs2woIBkUvlskViG4zqwlZXffxPd6j3t3SnvsxScXUwQDcK2RXuZ d+OcGt4GS0Phbg3W8JQJZF9x3o59kHIiXpE+XIbhtKEpyuakuOqm8F2Hx5VtpTnG /u/mREcM72xkQ0PrEKeZ8lpQkMQVhBNrTVuFh7A2bUOg/54U7RQx6M0YVCSZE7H0 Xru6+oyU7DpQtcm9e/gRT9xTP9RERTYECIrkXT+CR3Hm8ZBadKurm9WWZd+DpLn1 8KpQ8b9jfyQKayq+evtoHnZBhow7es4sFsIQF57wCX8xWTy3ZC/tzpSDqvgwS+DI ozKUv2bZqCDreqUBjpD04rukG5qcBZCG5kPPLLeSyGBuerhmiuXaXTiy8VBhQsLK kqi+f/DTxfQo0AzkzaQT4q1VM7EbizazkfxvD+1FqPLT/cC/vjU7CvxH2hNC788a KlzhmxPkRu/0xBQ6ydHiZPl9TPbq/su5ufJB8fyTel0iV1SrR42EpTnZRCgeQlWU NKHef44yHOeNiXv9HgDz =IBfu -----END PGP SIGNATURE----- --=_AtAW9EhHBcEoJFkw-6Jexgy-- From owner-freebsd-current@freebsd.org Fri Mar 17 13:53:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85526D10810 for ; Fri, 17 Mar 2017 13:53:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660049.outbound.protection.outlook.com [40.107.66.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18D631D32; Fri, 17 Mar 2017 13:53:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Fri, 17 Mar 2017 13:53:47 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Fri, 17 Mar 2017 13:53:47 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+ Date: Fri, 17 Mar 2017 13:53:46 +0000 Message-ID: References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> , <20170317083605.GQ16105@kib.kiev.ua> In-Reply-To: <20170317083605.GQ16105@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: 48211e51-80e4-4117-a36c-08d46d3d0892 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:ZQM7FDUkJSMu4Pkh1rNjxps07q/vo6xEYONgNyQ4kpKIRs6Ep8Jw8vIWmN0iSKPC/pbJDm9XipiEPxCvgTA/q17WqYwqd/Bk97srKJ6uLQg3FdMvq3Fzaq45GDUM4I+AbqNDYTOIb2amZwMk1ThlX7NMpLFX9bI9wP34H5+LNU0GfiMd8Ukj05DWHBQmDgAirL0qaiQjRErYGivewCbhtGZy8OE9HyawhtUnq90IMhkfySf6Q7IHicwf2+Q3b6DsM471h9RUhH682w49Jjc/Y8s0Cp658imAvJgaei2Tdn/z2bQecxJdU4SowC55gxVDTNXLmpAAORFCnJxgI8wr7A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39830400002)(39410400002)(377454003)(43234003)(51444003)(24454002)(229853002)(86362001)(77096006)(6506006)(4326008)(5660300001)(102836003)(5890100001)(1411001)(93886004)(122556002)(39060400002)(53936002)(99936001)(6306002)(9686003)(3280700002)(74316002)(50986999)(189998001)(53546008)(76176999)(54356999)(2906002)(6916009)(305945005)(2950100002)(81156014)(8676002)(81166006)(966004)(74482002)(6436002)(38730400002)(6246003)(2900100001)(110136004)(7696004)(55016002)(8936002)(54906002)(33656002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 13:53:46.9092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:53:50 -0000 --_002_YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390YTXPR01MB0189CANP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, I don't mind adding ncl_flush(), but it shouldn't be necessary. I actually had it in the first rendition of the patch, but took it out because it should happen on the VOP_CLOSE() if any writing to the buffer cache happened and that code hasn't changed in many years. What the patch was missing was updating n_mtime after the dirty page flush. Btw, a flush without OBJPC_SYNC happens when the file is VOP_CLOSE()'d unless the default value of vfs.nfs.clean_[ages_on_close is changed, which I think is why the 1sec resolution always seemed to work, at least for the example where there was an munmap before close. Attached is an updated version with that in it, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov Sent: Friday, March 17, 2017 4:36:05 AM To: Rick Macklem Cc: Dimitry Andric; Ian Lepore; Gergely Czuczy; FreeBSD Current Subject: Re: process killed: text file modification On Fri, Mar 17, 2017 at 03:10:57AM +0000, Rick Macklem wrote: > Hope you don't mind a top post... > Attached is a little patch you could test maybe? > > rick > ________________________________________ > From: owner-freebsd-current@freebsd.org on behalf of Rick Macklem > Sent: Thursday, March 16, 2017 9:57:23 PM > To: Dimitry Andric; Ian Lepore > Cc: Gergely Czuczy; FreeBSD Current > Subject: Re: process killed: text file modification > > Dimitry Andric wrote: > [lots of stuff snipped] > > I'm also running into this problem, but while using lld. I must set > > vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both > > the client and the server, to make it work. > > > > Instead of GNU ld, lld uses mmap to write to the output executable. If > > this executable is more than one page, and resides on an NFS share, > > running it will almost always result in "text file modification", if > > vfs_timestamp_precision >=3D 2. > > > > A small test case: http://www.andric.com/freebsd/test-mmap-write.c, > > which writes a simple "hello world" i386-freebsd executable file, using > > the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() -= > > > close(). > Hopefully Kostik will correct me if I have this wrong, but I don't believ= e any > of the above syscalls guarantee that dirty pages have been flushed. > At least for cases without munmap(), the writes of dirty pages can occur = after > the file descriptor is closed. I run into this in NFSv4, where there is a= Close (NFSv4 one) > that can't be done until VOP_INACTIVE(). > If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll se= e: > if (NFS_ISV4(vp) && vp->v_type =3D=3D VREG) { > 237 /* > 238 * Since mmap()'d files do I/O after VOP_CLOSE(),= the NFSv4 > 239 * Close operations are delayed until now. Any di= rty > 240 * buffers/pages must be flushed before the close= , so that the > 241 * stateid is available for the writes. > 242 */ > 243 if (vp->v_object !=3D NULL) { > 244 VM_OBJECT_WLOCK(vp->v_object); > 245 retv =3D vm_object_page_clean(vp->v_objec= t, 0, 0, > 246 OBJPC_SYNC); > 247 VM_OBJECT_WUNLOCK(vp->v_object); > 248 } else > 249 retv =3D TRUE; > 250 if (retv =3D=3D TRUE) { > 251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a= _td, 1, 0); > 252 (void)nfsrpc_close(vp, 1, ap->a_td); > 253 } > 254 } > Note that nothing like this is done for NFSv3. > What might work is implementing a VOP_SET_TEXT() vnode op for the NFS > client that does most of the above (except for nfsrpc_close()) and then s= ets > VV_TEXT. > --> That way, all the dirty pages will be flushed to the server before th= e executable > starts executing. > > > Running this on an NFS share, and then attempting to run the resulting > > 'helloworld' executable will result in the "text file modification" > > error, and it will be killed. But if you simply copy the executable to > > something else, then it runs fine, even if you use -p to retain the > > properties! > > > > IMHO this is a rather surprising problem with the NFS code, and Kostik > > remarked that the problem seems to be that the VV_TEXT flag is set too > > early, before the nfs cache is invalidated. Rick, do you have any idea= s > > about this? > I don't think it is the "nfs cache" that needs invalidation, but the dirt= y > pages written by the mmap'd file need to be flushed, before the VV_TEXT > is set, I think? > > If Kostik meant "attribute cache" when he said "nfs cache", I'll note tha= t the > cached attributes (including mtime) are updated by the reply to every wri= te. > (As such, I think it is the writes that must be done before setting VV_TE= XT > that is needed.) > > It is a fairly simple patch to create. I'll post one to this thread in a = day or so > unless Kostik thinks this isn't correct and not worth trying. > I think that the patch is in right direction, but I am not convinced that it is enough. What we need is to ensure that mtime on server does not change after VV_TEXT is set. Dirty pages indeed would cause the mtime update on flush, but wouldn't dirty buffers writes cause the same issue ? In other words, I think that enchanced VOP_SET_TEXT() for nfs must flush everything to ensure that mtime on server would not change due to further actions by this machine' nfs client. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --_002_YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="textmod.patch" Content-Description: textmod.patch Content-Disposition: attachment; filename="textmod.patch"; size=1343; creation-date="Fri, 17 Mar 2017 13:49:47 GMT"; modification-date="Fri, 17 Mar 2017 13:49:47 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jLnRleHQJMjAxNy0wMy0xNiAyMTo1NToxNi4y NjMzOTMwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2x2bm9wcy5jCTIwMTctMDMtMTcg MDk6MzE6MjMuNjMyODE0MDAwIC0wNDAwCkBAIC0xNDAsNiArMTQwLDcgQEAgc3RhdGljIHZvcF9h ZHZsb2NrX3QJbmZzX2FkdmxvY2s7CiBzdGF0aWMgdm9wX2FkdmxvY2thc3luY190IG5mc19hZHZs b2NrYXN5bmM7CiBzdGF0aWMgdm9wX2dldGFjbF90IG5mc19nZXRhY2w7CiBzdGF0aWMgdm9wX3Nl dGFjbF90IG5mc19zZXRhY2w7CitzdGF0aWMgdm9wX3NldF90ZXh0X3QgbmZzX3NldF90ZXh0Owog CiAvKgogICogR2xvYmFsIHZmcyBkYXRhIHN0cnVjdHVyZXMgZm9yIG5mcwpAQCAtMTc2LDYgKzE3 Nyw3IEBAIHN0cnVjdCB2b3BfdmVjdG9yIG5ld25mc192bm9kZW9wcyA9IHsKIAkudm9wX3dyaXRl ID0JCW5jbF93cml0ZSwKIAkudm9wX2dldGFjbCA9CQluZnNfZ2V0YWNsLAogCS52b3Bfc2V0YWNs ID0JCW5mc19zZXRhY2wsCisJLnZvcF9zZXRfdGV4dCA9CQluZnNfc2V0X3RleHQsCiB9OwogCiBz dHJ1Y3Qgdm9wX3ZlY3RvciBuZXduZnNfZmlmb29wcyA9IHsKQEAgLTMzNzMsNiArMzM3NSwyOSBA QCBuZnNfc2V0YWNsKHN0cnVjdCB2b3Bfc2V0YWNsX2FyZ3MgKmFwKQogCXJldHVybiAoZXJyb3Ip OwogfQogCitzdGF0aWMgaW50CituZnNfc2V0X3RleHQoc3RydWN0IHZvcF9zZXRfdGV4dF9hcmdz ICphcCkKK3sKKwlzdHJ1Y3Qgdm5vZGUgKnZwID0gYXAtPmFfdnA7CisJc3RydWN0IG5mc25vZGUg Km5wOworCisJLyoKKwkgKiBJZiB0aGUgdGV4dCBmaWxlIGhhcyBiZWVuIG1tYXAnZCwgdGhlIGRp cnR5IHBhZ2VzIG11c3QgYmUgZmx1c2hlZAorCSAqIHNvIHRoYXQgdGhlIG1vZGlmeSB0aW1lIG9m IHRoZSBmaWxlIHdpbGwgYmUgdXAgdG8gZGF0ZS4KKwkgKi8KKwlpZiAodnAtPnZfb2JqZWN0ICE9 IE5VTEwpIHsKKwkJbnAgPSBWVE9ORlModnApOworCQlWTV9PQkpFQ1RfV0xPQ0sodnAtPnZfb2Jq ZWN0KTsKKwkJdm1fb2JqZWN0X3BhZ2VfY2xlYW4odnAtPnZfb2JqZWN0LCAwLCAwLCBPQkpQQ19T WU5DKTsKKwkJVk1fT0JKRUNUX1dVTkxPQ0sodnAtPnZfb2JqZWN0KTsKKwkJbXR4X2xvY2soJm5w LT5uX210eCk7CisJCW5wLT5uX210aW1lID0gbnAtPm5fdmF0dHIubmFfbXRpbWU7CisJCW10eF91 bmxvY2soJm5wLT5uX210eCk7CisJfQorCXZwLT52X3ZmbGFnIHw9IFZWX1RFWFQ7CisJcmV0dXJu ICgwKTsKK30KKwogLyoKICAqIFJldHVybiBQT1NJWCBwYXRoY29uZiBpbmZvcm1hdGlvbiBhcHBs aWNhYmxlIHRvIG5mcyBmaWxlc3lzdGVtcy4KICAqLwo= --_002_YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390YTXPR01MB0189CANP_-- From owner-freebsd-current@freebsd.org Fri Mar 17 14:19:22 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B84BCD10EE6 for ; Fri, 17 Mar 2017 14:19:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32B051C56; Fri, 17 Mar 2017 14:19:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2HEJHRc090524 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 16:19:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2HEJHRc090524 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2HEJHYF090523; Fri, 17 Mar 2017 16:19:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2017 16:19:17 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170317141917.GS16105@kib.kiev.ua> References: <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:19:22 -0000 On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote: > Well, I don't mind adding ncl_flush(), but it shouldn't be > necessary. I actually had it in the first > rendition of the patch, but took it out because it should happen > on the VOP_CLOSE() if any writing to the buffer cache happened > and that code hasn't changed in many years. Dirty pages are flushed by writes, so if we have a set of dirty pages and async vm_object_page_clean() is called on the vnode' vm_object, we get a bunch of delayed-write AKA dirty buffers. This is possible even after VOP_CLOSE() was done, e.g. by syncer performing regular run involving vfs_msync(). I agree that the patch would not create new dirty buffers, but it is possible to get them by other means. > > What the patch was missing was updating n_mtime after the dirty > page flush. > > Btw, a flush without OBJPC_SYNC happens when the file is VOP_CLOSE()'d > unless the default value of vfs.nfs.clean_[ages_on_close is changed, which > I think is why the 1sec resolution always seemed to work, at least for the > example where there was an munmap before close. > > Attached is an updated version with that in it, rick From owner-freebsd-current@freebsd.org Fri Mar 17 15:41:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11300D1084D for ; Fri, 17 Mar 2017 15:41:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC17180C; Fri, 17 Mar 2017 15:41:19 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.132.9]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2WgT-1bxUQr43Ft-00sPP9; Fri, 17 Mar 2017 16:41:09 +0100 Date: Fri, 17 Mar 2017 16:41:01 +0100 From: "O. Hartmann" To: Alexander Leidinger Cc: freebsd-current@freebsd.org, sbruno@freebsd.org, mmacy@nextbsd.org Subject: Re: CURRENT: massive em0 NIC problems since IFLIB changes/introduction Message-ID: <20170317164101.0518ac67@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170317141501.Horde.YTCr8GuMV2yI1YaUkdRTLlu@webmail.leidinger.net> References: <20170317122018.21384497@freyja.zeit4.iv.bundesimmobilien.de> <20170317141501.Horde.YTCr8GuMV2yI1YaUkdRTLlu@webmail.leidinger.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/+oGlN1nCeMKHKa.CVT9+i2d"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:1Z27hQPUqlFPeIQ83VQ4qXRy7wSjR+GI2PIbQJikKxCeCacLx+K 4+46a9QIuOLpg3n956eIydXPRQQdSSK+xubjRRRs1uNMMYMrbA1u5g4V64vc1K7d1K8bp84 0CDD0p1RB3osaUx60fgBtuHttKcaPPGyaGW78ZfBL2UpzhbtcJauAAwPjs/LAdsz4AAjxeM d+hDAdRYzHiZV24b0o4RA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zLrOOxnKnhI=:eEhfqu7rhH8oUckB8lp1J8 2V5Z+JDQ9sEUioW59Ghl00NW5tP94Sx0AX51qKFdo3veuKDUNuxQlEPgKu3zSHYLpiYcFQBFt CbBABMxqwUTLgIS6LxsbJ0GwdFUxV5prwK01+tG0eN1HcyeHK3rcPnsx39hOBxNpMukZtJSr8 OIY/lZLE4q305AzRjtpiBnjHxT2MEAakEbqC0fEk+um6295VJPuTRtr0UkUpauZ2aLZDLiqd9 kFrSnbx1yTDFwhs714SIeT759daRKM7ru5UerkfF0lxgk9HIwXhxzctlIlwpsLBBN3Rb1zyJi NIIkFzRaRvLpsiuIHWVcOlj9jgdmmI04woWr6Xbv8qUlyElAaMGHS30gamHpwMPrzIn0TC/X9 bLIH4+TSx0uZqBXzym5tlBIi0WD67YS4fSuFg3WQlIKBf+AbDUs3Sf9kvhrDZRhm0UNk9IS3a 0xc4iF9y6BilSCwFr/vhQhyw27v/DEeRvGlhvScHbJwydb+GIlBEBMj6X9aipV4XoTZRfjnB3 dhidaCVtWYSNjfLL6PFZwo5aukPhBRxigcHTYHP+lT27GnGS56GyxYQWN9taS/f0FcLk0PSlH TBL/IXT66RoVX/RH/JtKFsoz5GsXJf9NdAieDasDtRTpVGgeDU62A+uUuYv0cbAeAF+QYfdhS /9VSZrWcJSslGBLmYsscuXQ1++PfqfCEoffSb6PzsPmWPgmAZ0fSs6P1FxBfvf7miOwVOoqIG zN8T1VOjKBErlWShf1XxaUgqcAbsiTyZrV9ln1IPCGkRtbe7IqNme59DzMk= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:41:20 -0000 --Sig_/+oGlN1nCeMKHKa.CVT9+i2d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Fri, 17 Mar 2017 14:15:01 +0100 Alexander Leidinger schrieb: > Quoting "O. Hartmann" (from Fri, 17 Mar 2017 =20 > 12:20:18 +0100): >=20 > > Since the introduction of the IFLIB changes, I realise severe problems = on > > CURRENT. =20 >=20 > I already reported something like this to sbruno@ and M. Macy (in copy). >=20 > > Running the most recent CURRENT (FreeBSD 12.0-CURRENT #27 r315442: Fri = Mar 17 > > 10:46:04 CET 2017 amd64), the problems on a workstation got severe =20 > > within the > > past two days: > > > > since a couple of weeks the em0 NIC (Intel i217-LM, see below) dies on = heavy > > I/O. I realised this first when "rsync"ing poudriere repositories to a = remote > > NFSv4 (automounted) folder. The em0 device could be revived by =20 > > ifconfig down/up > > procedure. > > But not the i217-LM chip is affected. On another box equipted with a =20 > > i350 dual > > port GBit NIC I observed a similar behaviour under (artificially) =20 > > high I/O load > > (but I didn't investigate that further since it occured very seldom). = =20 >=20 > It's not only those chipsets. >=20 > It may be beneficial if you could provide the pciconf output for those =20 > devices. Mine is: > ---snip--- > em0@pci0:2:6:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 =20 > rev=3D0x05 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82541PI Gigabit Ethernet Controller' > ---snip--- >=20 > > Now, since around yesterday, the i217-LM dies without being reviveable = with > > ifconfig down/up: Doing so, my FreeBSD CURRENT machine (Fujitsu Celsius= M740) =20 >=20 > I don't know if for the chip I see this issue with a simple down/up =20 > would help (it's a headless server in a remote datacenter). For the =20 > moment I'm using the workaround of something like "ping -C 1 =20 > || shutdown -r now" in crontab. >=20 > The system in question is at r314137. >=20 > > remains with a dead em0 device, reporting "no route" in some occasions = but > > stuck in the dead state. Every attempt to establish manually the route = again > > fails, only rebooting the box gives some relief. > > > > On the console, I have some very strange reports: > > > > - ping reports suddenly about no buffer space > > - or I see sometimes massive occurences of "em0: TX(0) desc avail =3D = =20 > > 1024, pidx > > =3D 0" on the console =20 >=20 > I don't see this in messages or console log, but I see that ntpd can't =20 > resolve hostnames in the logs. >=20 > > Either way, sending/receiving large files on an established network GBi= t line > > which could be saturated by approx 100 MBytes/s tend to make the NIC fa= il. =20 >=20 > I can report that the "svnlite update" on the box of of the FreeBSD =20 > src tree is able to trigger the issue in my case. >=20 > I have to add that before the iflib changes I've seen frequent =20 > em-watchdog timeouts in the logs / dmesg. So for me we have two issues =20 > here: > - the hardware wasn't 100% supported before the iflib changes (it seems) > - the iflib changes have lost some watchdog functionality / =20 > auto-failure-recovery feature >=20 > Bye, > Alexander. >=20 In January (18.01.2017), I reported Sean Bruno some strange behaviour of th= e same box alongside with some details (I forgort to send in the Email you're reposndi= ng to, sorry) of the hardware, so here it is again: [...] Again, here is the pciconf output of the device:=20 em0@pci0:0:25:0: class=3D0x020000 card=3D0x11ed1734 chip=3D0x153a8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ethernet Connection I217-LM' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xfb300000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0xfb339000, size 4096, enabl= ed bar [18] =3D type I/O Port, range 32, base 0xf020, size 32, enabled [...] The problem has become a severe state within the past two days. I did on a = daily basis CURRENT buildwords, did poudriere builds several times and tried to sync th= em to the package repository server - and that failed dramatically as described above= starting with yesterday. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/+oGlN1nCeMKHKa.CVT9+i2d Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMwDjQAKCRDS528fyFhY lBcyAf9I2Yyk7obblmKOyhvrIYxhWGkb+gpFXtkIlv9fi3SBy/YLbQZqbigI6eEU U1WoyR3CBV+vbhed5ZWC9gjfc7XfAf4/wPymjNpdBe+7IjO3ErstaWfM+LrDVbYU j61RoJEwG9S67gMzVJmjud+IOWtid/Tmr/OuTRmMPD9hwYJy0iLD =VsU/ -----END PGP SIGNATURE----- --Sig_/+oGlN1nCeMKHKa.CVT9+i2d-- From owner-freebsd-current@freebsd.org Fri Mar 17 16:53:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01FB8D10C32 for ; Fri, 17 Mar 2017 16:53:36 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A56D1356 for ; Fri, 17 Mar 2017 16:53:34 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.168.50]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MFu0Y-1d1aKD2YiM-00Etv8; Fri, 17 Mar 2017 17:53:31 +0100 Date: Fri, 17 Mar 2017 17:53:24 +0100 From: "O. Hartmann" To: Slawa Olhovchenkov Cc: "O. Hartmann" , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170317120429.GX15630@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/yI9ma.EAvgiALh__OfIuIeR"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:cuUbmObyu3suE2Rwy+t6YunYaAZ/afIrBJb386d2NcHBcexJTv5 P7xdEIQpmoNXk0OVWaxZwDpW+tdO0FW9gPG4dNO7PgXaL2a/3heWYAVeC/uYDP0Uz/Mb7Ke k2F3iNYuCclTePl/c35LYD8tWqXVFEiluh8rLpiasZkTOmR+MYsuUC5/8XaKCfds/dB+Dzn oBs4Zk4xVKEBGL6QZ09Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:1r1SEZIRg7g=:iAMwtbnNPdg5Ig5os3o/VI GKMQMGFGGHh1HpVzRAPoDhI4FP5kh95AneDWyDfjU/GiUS/VovI6EADEyNfTuTHtj9GSfYQAO rdBy5LMg0hBwBHofuEoV3ip2EIEmkBcaA9IyRKQyLlfF4KjdZd9ZeDXlmbOoOFQHohmJl0RHy 1rAHy89t9dL+opYCF5BZNA+Qbbp9JZM5F7jhYk7izRLvKtDxHzrwE73P6/6MAt7HEkU5ajIKi f1fZELen3s6gW5ZzNMXg2GbMF9qwXuAkcf4hP4i4opiTx29JI9WcJnTIiq+qKIloo8ooTmM0O XwgnjxrmdDy3FbnWQdN0J9d4Mi0ajLz97Tk5Nd2nrt3iWTZtBHlSnGLNAY04a5JWDRv++5MRI QdYT/7NoooI2hJgwf0X9l12mukBgFd+5Xf3wrSGx2bzlZMoIHOk+5Y/RfGQ3xRQ62RxOT1PIA P9FRtBRSOm5YXaRwKA6VVgSyDO6tI9ynS43fpe1KdfM4v0tMEdXvvnIXDPhyqP9611WXT53Oc FjwdRZ3AhAaNMmrAg7VTXzLsHqVgNH/dhU3x1VOvmSJcsAKSwtb4At/DcH99Fiq4JMhDL/aHH lldbvVC/NaAnOe614CzhnkjErePyQi8+EyONFwtdAhKbOcEH2JcykY6sSpGQKa7ZhDyPG1bku jQsTNJkULYRJNYdAG3wmJmEkK3q2rJAkEVv1L2YeKDrZ7FFTVihtsenS0xz6g+FjSw8ujVdXx rpYwXl6xzzmSOjIphFqbikNYf6+FTeOTv2hKtSgiG+JI13IxpqwOzvVjAOs= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:53:36 -0000 --Sig_/yI9ma.EAvgiALh__OfIuIeR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Fri, 17 Mar 2017 15:04:29 +0300 Slawa Olhovchenkov schrieb: > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: >=20 > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel= (R) > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > >=20 > > FreeBSD does not report the existence or availability of AES-NI feature= , which > > is supposed to be a feature of this type of CPU: =20 >=20 > What reassons to detect AES-NI by FreeBSD? What do you mean? I do not understand! FreeBSD is supposed to read the CPUI= D and therefore the capabilities as every other OS, too. But there may some circu= mstances why FBSD won't. I do not know, that is the reason why I'm asking here. > Other OS detect AES-NI on this server? I havn't ried so far, the box is in heavy use. I'd like to check with some = live USB drive versions and report later. >=20 > AES-NI may be disabled by BIOS/vendor/BIOS settings There is no option for that, I'm looking for several time for that right no= w. Even with TPM enabled - which is considered to be necessary on several firmwares - th= ere is no change. >=20 > https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/AES-NI-is-disa= bled-on-my-13-New-S2/td-p/3498468 > http://h17007.www1.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_060216/s_enab= le_AES-NI.html > http://en.community.dell.com/support-forums/servers/f/956/t/19509653 As I said, even with the brand new firmware from January of this year (2017= ) there is no change - the firmware prior to that showed the same non-existing AES-NI fea= ture. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/yI9ma.EAvgiALh__OfIuIeR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMwUhAAKCRDS528fyFhY lJvNAgCAEGi7jlaiAmUNDrZugYBJCm0geufYkKRIgAc7ZT9RIthYnx0I9V6yTBOX AkUcCmTmISV9G4VNalH8h6ytQNerAf9eiYv6T1paKIi7usAd163iEyhVm9gbykOm xbNhL+6jIlynSmNvnO1q9CeeMUV8YLyl9KBCoXNZVGqq3F1pwMvP =0RZC -----END PGP SIGNATURE----- --Sig_/yI9ma.EAvgiALh__OfIuIeR-- From owner-freebsd-current@freebsd.org Fri Mar 17 17:03:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B1BD10027 for ; Fri, 17 Mar 2017 17:03:13 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 EA8621967 for ; Fri, 17 Mar 2017 17:03:12 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 9F51F131F6 for ; Fri, 17 Mar 2017 17:03:05 +0000 (UTC) Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 To: freebsd-current@freebsd.org References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> From: Allan Jude Message-ID: Date: Fri, 17 Mar 2017 13:02:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tmRUgt3UNqJJDDqxXnHO3IUnxk5uNW1n6" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:03:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tmRUgt3UNqJJDDqxXnHO3IUnxk5uNW1n6 Content-Type: multipart/mixed; boundary="SEkoLj3kKdmu3SMnwHi54hm2hgBsGTXLl"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> --SEkoLj3kKdmu3SMnwHi54hm2hgBsGTXLl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-03-17 12:53, O. Hartmann wrote: > Am Fri, 17 Mar 2017 15:04:29 +0300 > Slawa Olhovchenkov schrieb: >=20 >> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: >> >>> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Int= el(R) >>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. >>> >>> FreeBSD does not report the existence or availability of AES-NI featu= re, which >>> is supposed to be a feature of this type of CPU: =20 >> >> What reassons to detect AES-NI by FreeBSD? >=20 > What do you mean? I do not understand! FreeBSD is supposed to read the = CPUID and > therefore the capabilities as every other OS, too. But there may some c= ircumstances why > FBSD won't. I do not know, that is the reason why I'm asking here. >=20 >> Other OS detect AES-NI on this server? >=20 > I havn't ried so far, the box is in heavy use. I'd like to check with s= ome live USB drive > versions and report later. >=20 >> >> AES-NI may be disabled by BIOS/vendor/BIOS settings >=20 > There is no option for that, I'm looking for several time for that righ= t now. Even with > TPM enabled - which is considered to be necessary on several firmwares = - there is no > change. >=20 >> >> https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/AES-NI-is-d= isabled-on-my-13-New-S2/td-p/3498468 >> http://h17007.www1.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_060216/s_e= nable_AES-NI.html >> http://en.community.dell.com/support-forums/servers/f/956/t/19509653 >=20 > As I said, even with the brand new firmware from January of this year (= 2017) there is no > change - the firmware prior to that showed the same non-existing AES-NI= feature. >=20 I have used the E5-1650 v3 in the FreeBSD test cluster, and AES-NI works fine. I had to enable it in the BIOS though. It is on the CPU features page, and may have an odd name, rather than "AES-NI" AES-NI is unrelated to TPM. --=20 Allan Jude --SEkoLj3kKdmu3SMnwHi54hm2hgBsGTXLl-- --tmRUgt3UNqJJDDqxXnHO3IUnxk5uNW1n6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iQIcBAEBAgAGBQJYzBbBAAoJEBmVNT4SmAt+TEYP/1KnejcBjV9j8dPs9pw9xQkA +4x01NSDSoudimACgjNgOemLGOLOUiO5tsakF9ZXIaKKi/jeXYxnIsjfsPmhFkJm U1oC8lhjxiFdclZZufpEL88Krtp9lTVFnqDFy8OZ/ZRj4yjwe/lgxUJsMX9WjVwq RrScf99DMn5DpltMSUTpZ4cDlE3tAKsA7vv2yHnq07PetBDNtOlTQWh94sjkPjI9 D0MLlPMHt1yLEdM7E/ZU1Vv+Ux0CpAS+ntqAxrIKz96/6bqq0wJp4ng2nvITKMJ5 ST7ZXlW6oOZRn0aXi0i0rsiVojQyZBeD31srT7fDQOULrHJ/JMQ4oRHf5W25oUhQ CqA0ENYF0y8ziCB+cFnP2YTD+5QQn3DOwmaPDQdeqUxLbetmcE58r7H3DsFi6/X/ 9CZj4nzfqHH9BoS9kTtue31jfqMpUVAoOV6lDHu9AS+xYcNCNPZGR0fONG/meRLI 0Y3eIw0ZGBIB+cUdNwBNQi9dc+2xCH6fbLnRToxN2KpZ4syu5IxzHnPnblujPm6G yt54fMVhMbYRFeOU1RHYTseQMaMB3CGSY8XruWUo87jXd3lYsZkIcQafCUvH7jN0 dr9kyN0+dgQ/EKe9clPZ399MDfJ/YmI76fGLCF3kFxFLrDTI9fy6MKjD284ujSOb A0exaT3mGUYmTo2SAonK =JqAf -----END PGP SIGNATURE----- --tmRUgt3UNqJJDDqxXnHO3IUnxk5uNW1n6-- From owner-freebsd-current@freebsd.org Fri Mar 17 17:05:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8171D1010B for ; Fri, 17 Mar 2017 17:05:25 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DF0E1B26; Fri, 17 Mar 2017 17:05:22 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.168.50]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfVU3-1caPEe1K0J-00P9Am; Fri, 17 Mar 2017 18:05:15 +0100 Date: Fri, 17 Mar 2017 18:05:07 +0100 From: "O. Hartmann" To: Cy Schubert Cc: "O. Hartmann" , freebsd-current , Don Lewis Subject: Re: ntpd dies nightly on a server with jails Message-ID: <20170317180507.5c64fb26@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201703152012.v2FKCbvg078762@slippy.cwsent.com> References: <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> <201703152012.v2FKCbvg078762@slippy.cwsent.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/AYNW4EZFsh9hIquzAhaV/tS"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:jwnUb+yGVDXKrDJxhJK/LGQntgaZLdVeUB9Pa4fxX1Tn4oFvn0Y QxUnXW8vFEw/bGV1Cir5KGwzlgI2K7XCd6iIbiE54y8C7USqeLND8F+0ZHgQ4t75T1Zdt9c kElbSd2C1jThkD3BE6SxP+yyeF+oMZKHLl1NYqjiHY+laoWfIDFgRkN5Bsr2jo93cYSGnTg MP8X39POBHqapi7msdoRA== X-UI-Out-Filterresults: notjunk:1;V01:K0:HSMzPqqAPbA=:8BNZKefVE25xd2WfNqg52H ClSQ8fFlEP/07yW8Gif0KLg8/BHB8znCEmaKN2FryGMWBXytAZ8lbSRC+0f7D3jFg6jtMqRCi pHoNcNRe6dSqMJ9L3Pz5arfTrbUcekGqbByOyDUkprbB71Wg7dfU98Bx2GnJ2+jHWa2bbDGlo lTGXCkTf/FutrimzarvWeNhf2rD7/dIc5Cnk4J45af+986CYad2cSqTAwdTfnkmivKhypAmU4 RzdqVPDGeoyRFVXbvPq66dCoPgqWWNYDEFnSNbM7/TAc896igR4hhszKkccxXjSoMy60dSWIK +mWtcrs3TycygJ2RTFk3tGFNSjAzKtBM0SwmJOPOs1s/f7128Jy43wy8ZahUmLleW0iwmBIa3 GirPJIK42EvfUzAEyEJ21oWUQUZTAAfZSf7XJDtj3hscdaERRj15m3D8QhqafQqae1BJHMNxz sXb2gx+9oBcgvuN3KHzBiY1eGGxO9NOmZFVnlTb0jeHziLRih79zM7OHzReKCsqPyRRqU+t7n UsMU/XNf+P9aSJuxAFgFmV+B0EOtkdacWBMnn/G+078tfgVUWBKzBEBp8uFHn3REg3GNZ5beC sYQj9M3YXmhSLPTTbgeTzh9ZoURQwjoEqXY/9FjW+r2ZremJktahKMO3C/rIzBlsxFnnn4v08 lUIUyXZ+rDkp19Xe6h8hw3tXGc5l7Gjhj+kmsmGVc1itnJM+qrCMQ4S8YQgPe066X9/GbvCAQ Bj2C0SRkf+rZPScksEPtZAALeHNtJhPSeHOxWpX834mq79UoOXHMvTv8ECw= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:05:25 -0000 --Sig_/AYNW4EZFsh9hIquzAhaV/tS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 15 Mar 2017 13:12:37 -0700 Cy Schubert schrieb: > Hi O.Hartmann, >=20 > I'll try to answer as much as I can in the noon hour I have left. >=20 > In message <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de>,= =20 > "O. H > artmann" writes: > > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r3= 15187: > > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. > >=20 > > The box is an older two-socket Fujitsu server equipted with two four-co= re > > Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. > >=20 > > The box has several jails, each jail does NOT run service ntpd. Each ja= il has > > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedica= ted IP > > : > > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > >=20 > > The host itself has two main NICs, broadcom based. bcm0 is dedicated to= the > > host, bcm1 is shared amongst the jails: each jail has an IP bound to bc= m1 via > > whihc the jails communicate with the network. > >=20 > > I try to capture log informations via syslog, but FreeBSD's ntpd seems = to be > > very, very sparse with such informations, coverging to null - I can't s= ee > > anything suiatble in the logs why NTPD dies almost every night leaving = the > > system with a wild reset of time. Sometimes it is a gain of 6 hours, so= metime > > s > > it is only half an hour. I leave the box at 16:00 local time usually an= d take > > care again at ~ 7 o'clock in the morning local time. =20 >=20 > We will need to turn on debugging. Unfortunately debug code is not compil= ed=20 > into the binary. We have two options. You can either update=20 > src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exa= ct=20 > same ntp) with the DEBUG option -- this is probably simpler. Then enable= =20 > debug with -d and -D. -D increases verbosity. I just committed a debug=20 > option to both ntp ports to assist here. >=20 > Next question: Do you see any indication of a core dump? I'd be intereste= d=20 > in looking at it if possible. >=20 > >=20 > > When the clock is floating that wild, in all cases ntpd isn't running a= ny mor > > e. > > I try to restart with options -g and -G to adjust the time quickly at t= he > > beginning, which works fine. =20 >=20 > This is disconcerting. If your clock is floating wildly without ntpd=20 > running there are other issues that might be at play here. At most the=20 > clock might drift a little, maybe a minute or two a day but not by a lot.= =20 > Does the drift cause your clocks to run fast or slow? >=20 > >=20 > > Apart from possible misconfigurations of the jails (I'm quite new to ja= ils an > > d > > their pitfalls), I was wondering what causes ntpd to die. i can't deter= mine > > exactly the time of its death, so it might be related to diurnal/period= ic > > processes (I use only the most vanilla configurations on periodic, exce= pt for > > checking ZFS's scrubbing enabled). =20 >=20 > As I'm a little rushed for time, I didn't catch whether the jails=20 > themselves were also running ntpd... just thought I'd ask. I don't see ho= w=20 > zfs scrubbing or any other periodic scripts could cause this. >=20 > >=20 > > I'ven't had the chance to check whether the hardware is completely all = right, > > but from a superficial point of view there is no issue with high gain o= f the > > internal clock or other hardware issues. =20 >=20 > It's probably a good idea to check. I don't think that would cause ntpd a= ny=20 > gas. I've seen RTC battery messages on my gear which haven't caused ntpd= =20 > any problem. I have two machines which complain about RTC battery being=20 > dead, where in fact I have replaced the batteries and the messages still= =20 > are displayed at boot. I'm not sure if it's possible for a kernel to dama= ge=20 > the RTC. In my case that doesn't cause ntpd any problems. It's probably=20 > good to check anyway. >=20 > >=20 > > If there are known issues with jails (the problem occurs since I use th= ose), > > advice is appreciated. =20 >=20 > Not that I know of. >=20 >=20 Just some strange news: I left the server the whole day with ntpd disabled and I didn't watch a gai= n of the RTC by one second, even stressing the machine. But soon after restarting ntpd, I realised immediately a 30 minutes off! Th= is morning, the discrapancy was almost 5 hours - it looked more like a weird ajustment = to another time base than UTC. Over the weekend I'll leave the server with ntpd disabled and only RTC runn= ing. I've the strange feeling that something is intentionally readjusting the ntpd time d= ue to a misconfiguration or a rogue ntp server in the X.CC.pool.ntp.org --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/AYNW4EZFsh9hIquzAhaV/tS Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMwXQwAKCRDS528fyFhY lJjKAf9PBQ+3ap+ojjMsDiUzsMQIMtzzxaNTECyO+R3LamuNsZ3F7bAeIs/Z0z6q /aWm8VfJalzpAgwIZCofgb0SHHCxAf9X7zioQI9mC7DqWA80U8I25BCku5zg68xx q6vGRgVahAxFJTQI0/O00XpIuYqpfFrXX/6cuVJR+u4TxoRZxqDm =8jqD -----END PGP SIGNATURE----- --Sig_/AYNW4EZFsh9hIquzAhaV/tS-- From owner-freebsd-current@freebsd.org Fri Mar 17 17:07:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C010D1020C for ; Fri, 17 Mar 2017 17:07:39 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 1E4C41CD6 for ; Fri, 17 Mar 2017 17:07:39 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1covLj-000MUr-AC; Fri, 17 Mar 2017 20:07:35 +0300 Date: Fri, 17 Mar 2017 20:07:35 +0300 From: Slawa Olhovchenkov To: "O. Hartmann" Cc: freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317170735.GO70430@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:07:39 -0000 On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > Am Fri, 17 Mar 2017 15:04:29 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > FreeBSD does not report the existence or availability of AES-NI feature, which > > > is supposed to be a feature of this type of CPU: > > > > What reassons to detect AES-NI by FreeBSD? > > What do you mean? I do not understand! FreeBSD is supposed to read the CPUID and > therefore the capabilities as every other OS, too. But there may some circumstances why > FBSD won't. I do not know, that is the reason why I'm asking here. This sample can have disabled AES-NI by vendor, in BIOS, for example. As I show by links this is posible. CPUID in you example don't show AES-NI capabilities, for example 1650v4 w/ AES-NI CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff ^^^^^^ AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics In you sample: "TSCDLT,XSAVE" May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug in FreeBSD, AES-NI work and other OS show AES-NI capabilities. From owner-freebsd-current@freebsd.org Fri Mar 17 17:31:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAE0FD10A8D for ; Fri, 17 Mar 2017 17:31:23 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 332461ADC for ; Fri, 17 Mar 2017 17:31:22 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.168.50]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LxLcc-1c9tqn3zXW-0170O9; Fri, 17 Mar 2017 18:31:20 +0100 Date: Fri, 17 Mar 2017 18:31:11 +0100 From: "O. Hartmann" To: Slawa Olhovchenkov Cc: "O. Hartmann" , freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170317170735.GO70430@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170317170735.GO70430@zxy.spb.ru> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/mE3R_Z4p_+.7jfIsOz8p6j4"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:NsK/nTP2fqfBOJoR0JuVNfCh145bR0bGzUk6Jqo6NTV1647Esp4 +08+e2DmyU8tyEGBKTJk39QU0gznytLVK9/T4UDCsBcgpGwiq0H/cJTcHZ3T+Xu5cr17och 1FCJGlrndrtlUT0dx6OHMdKjker+PxsXlgjqvan0eqwBHE98gYXLkDL6/mqBj4Fnoak3BwP fpTkXFdJdQQAHQc2oPs7g== X-UI-Out-Filterresults: notjunk:1;V01:K0:WhBrNSeXGDs=:o7B5sy+YpDyxe/Bpr86XXW IkNZVw20jcI4tVLguq5kH/saj1hBUk+PuoekmsDwwgAFTUbCdGKh3LNDq6EBArxSn+Q41/7sp xqtisUtfxScdA/XnmaxOmzitbPPOQ/hm48VCu+hBwTYALXfMa2LUxV5Fi8FV5iHVHKPs8BQ57 8s+NqtrGPQdK9YX4ZTK/xMJawOhDxrGSfWDdka8P+hzbngzPaHJaWbE563h8DnI22nuJrJma1 da9/SaLxqLQJRQ0SXeq4cYA9n+b7+p3zyd2eJY3oNq8nmhPv2lLoMWzHbP8jKwRBd2XggK8Mm vPgyNPHxEP4mo8EG3piuLgilGVWNKPiMM/Ej0oJKz+ugRm5pAfLsJsy0HlxzhhxAVD2yCWlkV IVPpQTAibvjlkZrMT1W3xN31wTwLd6Kplnaw0hJaQMhf9U7WdGFWqx3jBKrVGa34fyCMMeie+ F4RtplPyVQRZl3y+dEuC54qR2f+yRnsoojS9iY0f4iyXmV5drMZaecP3WZrLnfdMD8huv2ihW EG4RL0R4BvQKREhmzpMabiaxgAB8AUG1a18xdKx67Xh8tvkArsh4CG5RjFViQ0Omoe+BtLbF8 QRXaMbylZnMG1EQveP54DO6gOGBsiU7yFem9UHLHVC3eVqNFbzj0zWOM2cl8vtUxXsmQ2WZaU /dfcAMoUJEFVgn1iy1nRXCzwxiRplmcvjLoyXcrUz+hR/UfTkoZ+y683b2b4zgRoWJdzoRSUv t3lUrQVr7Oeyd/245GLwzgqGWBRfyaH5Ai2NQtIH2lRwqHCyPcXUcgH8gnw= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:31:23 -0000 --Sig_/mE3R_Z4p_+.7jfIsOz8p6j4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Fri, 17 Mar 2017 20:07:35 +0300 Slawa Olhovchenkov schrieb: > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: >=20 > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > Slawa Olhovchenkov schrieb: > > =20 > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > =20 > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an I= ntel(R) > > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > >=20 > > > > FreeBSD does not report the existence or availability of AES-NI fea= ture, which > > > > is supposed to be a feature of this type of CPU: =20 > > >=20 > > > What reassons to detect AES-NI by FreeBSD? =20 > >=20 > > What do you mean? I do not understand! FreeBSD is supposed to read the = CPUID and > > therefore the capabilities as every other OS, too. But there may some c= ircumstances > > why FBSD won't. I do not know, that is the reason why I'm asking here. = =20 >=20 > This sample can have disabled AES-NI by vendor, in BIOS, for example. > As I show by links this is posible. >=20 > CPUID in you example don't show AES-NI capabilities, for example > 1650v4 w/ AES-NI >=20 > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x406f1 Family=3D0x6 Model=3D0x4f Step= ping=3D1 > Features=3D0xbfebfbff > Features2=3D0x7ffefbff > = = ^^^^^^ > AMD Features=3D0x2c100800 > AMD Features2=3D0x121 > Structured Extended > Features=3D0x21cbfbb > XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,Po= stIntr > TSC: P-state invariant, performance statistics >=20 > In you sample: "TSCDLT,XSAVE" >=20 > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some b= ug in FreeBSD, > AES-NI work and other OS show AES-NI capabilities. >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" We have some LGA1151 XEON based 19 inch rack server, also equipted with Has= well E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. You're right, the vendor could have disabled AES-NI by intention - but they= offered this box especially with AES-NI capabilities.=20 See here: http://freebsd.1045724.x6.nabble.com/r285947-broken-AESNI-support-No-aesn= i0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740-td6028895.html I feel a bit pissed off right now due to Fujitsu, because we started testin= g some encrypting features and I'd like to use AES-NI and I run into this issue ag= ain. I need to know that FreeBSD is not the issue with this specific CPU type. I= 'm still frustrated by that stupid comment "UNIX is not supoorted" I got that time t= hen when I reported 2015 the issue to Fujitsu. --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/mE3R_Z4p_+.7jfIsOz8p6j4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWMwdXwAKCRDS528fyFhY lPbeAf4s2Q/Pr9/YJqUTUpdZtqiOo6Ch10ZkQeCSEaVjIi+zzkxkMgg5Kqooj8YD G+JFqLX4jhsojeWoLg/09EfWUbIfAf9sAQc+PylLTB/nhFwtUpuKSt3ViTO9MPee PHcUxPN2RF0I82LyQV9cUcPE9kvnCTj/aYnnfC4Tuui7x3juqi/1 =oxwG -----END PGP SIGNATURE----- --Sig_/mE3R_Z4p_+.7jfIsOz8p6j4-- From owner-freebsd-current@freebsd.org Fri Mar 17 18:20:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71ED1D108CC for ; Fri, 17 Mar 2017 18:20:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 5649918F3 for ; Fri, 17 Mar 2017 18:20:23 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5e737702-0b3e-11e7-8c45-c35e37f62db1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 5e737702-0b3e-11e7-8c45-c35e37f62db1; Fri, 17 Mar 2017 18:20:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2HIKFBi009441; Fri, 17 Mar 2017 12:20:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489774815.40576.182.camel@freebsd.org> Subject: Re: ntpd dies nightly on a server with jails From: Ian Lepore To: "O. Hartmann" Cc: freebsd-current Date: Fri, 17 Mar 2017 12:20:15 -0600 In-Reply-To: <20170317180507.5c64fb26@thor.intern.walstatt.dynvpn.de> References: <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilien.de> <201703152012.v2FKCbvg078762@slippy.cwsent.com> <20170317180507.5c64fb26@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:20:24 -0000 On Fri, 2017-03-17 at 18:05 +0100, O. Hartmann wrote: > Am Wed, 15 Mar 2017 13:12:37 -0700 > Cy Schubert schrieb: > > > > > Hi O.Hartmann, > > > > I'll try to answer as much as I can in the noon hour I have left. > > > > In message <20170315071724.78bb0bdc@freyja.zeit4.iv.bundesimmobilie > > n.de>,  > > "O. H > > artmann" writes: > > > > > > Running a host with several jails on recent CURRENT (12.0-CURRENT > > > #8 r315187: > > > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily > > > basis. > > > > > > The box is an older two-socket Fujitsu server equipted with two > > > four-core > > > Intel(R) Xeon(R) CPU L5420  @ 2.50GHz. > > > > > > The box has several jails, each jail does NOT run service ntpd. > > > Each jail has > > > its dedicated loopback, lo1 throughout lo5 (for the moment) with > > > dedicated IP > > > : > > > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > > > > > > The host itself has two main NICs, broadcom based. bcm0 is > > > dedicated to the > > > host, bcm1 is shared amongst the jails: each jail has an IP bound > > > to bcm1 via > > > whihc the jails communicate with the network. > > > > > > I try to capture log informations via syslog, but FreeBSD's ntpd > > > seems to be > > > very, very sparse with such informations, coverging to null - I > > > can't see > > > anything suiatble in the logs why NTPD dies almost every night > > > leaving the > > > system with a wild reset of time. Sometimes it is a gain of 6 > > > hours, sometime > > > s > > > it is only half an hour. I leave the box at 16:00 local time > > > usually and take > > > care again at ~ 7 o'clock in the morning local time.   > > We will need to turn on debugging. Unfortunately debug code is not > > compiled  > > into the binary. We have two options. You can either update  > > src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's > > the exact  > > same ntp) with the DEBUG option -- this is probably simpler. Then > > enable  > > debug with -d and -D. -D increases verbosity. I just committed a > > debug  > > option to both ntp ports to assist here. > > > > Next question: Do you see any indication of a core dump? I'd be > > interested  > > in looking at it if possible. > > > > > > > > > > > When the clock is floating that wild, in all cases ntpd isn't > > > running any mor > > > e. > > > I try to restart with options -g and -G to adjust the time > > > quickly at the > > > beginning, which works fine.   > > This is disconcerting. If your clock is floating wildly without > > ntpd  > > running there are other issues that might be at play here. At most > > the  > > clock might drift a little, maybe a minute or two a day but not by > > a lot.  > > Does the drift cause your clocks to run fast or slow? > > > > > > > > > > > Apart from possible misconfigurations of the jails (I'm quite new > > > to jails an > > > d > > > their pitfalls), I was wondering what causes ntpd to die. i can't > > > determine > > > exactly the time of its death, so it might be related to > > > diurnal/periodic > > > processes (I use only the most vanilla configurations on > > > periodic, except for > > > checking ZFS's scrubbing enabled).   > > As I'm a little rushed for time, I didn't catch whether the jails  > > themselves were also running ntpd... just thought I'd ask. I don't > > see how  > > zfs scrubbing or any other periodic scripts could cause this. > > > > > > > > > > > I'ven't had the chance to check whether the hardware is > > > completely all right, > > > but from a superficial point of view there is no issue with high > > > gain of the > > > internal clock or other hardware issues.   > > It's probably a good idea to check. I don't think that would cause > > ntpd any  > > gas. I've seen RTC battery messages on my gear which haven't caused > > ntpd  > > any problem. I have two machines which complain about RTC battery > > being  > > dead, where in fact I have replaced the batteries and the messages > > still  > > are displayed at boot. I'm not sure if it's possible for a kernel > > to damage  > > the RTC. In my case that doesn't cause ntpd any problems. It's > > probably  > > good to check anyway. > > > > > > > > > > > If there are known issues with jails (the problem occurs since I > > > use those), > > > advice is appreciated.   > > Not that I know of. > > > > > Just some strange news: > > I left the server the whole day with ntpd disabled and I didn't watch > a gain of the RTC > by one second, even stressing the machine. > > But soon after restarting ntpd, I realised immediately a 30 minutes > off! This morning, > the discrapancy was almost 5 hours - it looked more like a weird > ajustment to another > time base than UTC. > > Over the weekend I'll leave the server with ntpd disabled and only > RTC running. I've the > strange feeling that something is intentionally readjusting the ntpd > time due to a > misconfiguration or a rogue ntp server in the X.CC.pool.ntp.org > The rogue server theory is a bad one, unless you have configured just a single server in your ntp.conf and it is the rogue.  Ntpd requires agreement among the set of configured servers, it will ignore outliers. It would help to have some actual data.  What does ntpq -p show right after starting ntpd?  Then a few minutes later, then again 10 minutes after that, etc.  What is in the /var/db/ntpd.drift file?  Are you using the standard freebsd ntp.conf file as delivered, or have you customized it?  Any non-default settings in your rc.conf related to ntp? -- Ian From owner-freebsd-current@freebsd.org Fri Mar 17 18:27:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE3B6D10C66 for ; Fri, 17 Mar 2017 18:27:07 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FB461FED for ; Fri, 17 Mar 2017 18:27:07 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B6D663145 for ; Fri, 17 Mar 2017 18:27:06 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 628697C5F for ; Fri, 17 Mar 2017 18:27:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id WuXExbP8D16C for ; Fri, 17 Mar 2017 18:27:02 +0000 (UTC) Subject: Re: r314708: panic: tdsendsignal: ksi on queue DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com CDB0E7C5A To: freebsd-current@freebsd.org References: <20170309144646.GB16105@kib.kiev.ua> <20170309231151.GA49720@stack.nl> <20170310104429.GH16105@kib.kiev.ua> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <21c8bb48-df8e-f126-e664-e963274f6d48@FreeBSD.org> Date: Fri, 17 Mar 2017 11:26:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170310104429.GH16105@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tmsQDFvpupFPGQB91xloAm82LFMhmjEXv" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:27:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tmsQDFvpupFPGQB91xloAm82LFMhmjEXv Content-Type: multipart/mixed; boundary="s8pxjajXRrMXgUNFqBjCDFaEVmSii711M"; protected-headers="v1" From: Bryan Drewery To: freebsd-current@freebsd.org Message-ID: <21c8bb48-df8e-f126-e664-e963274f6d48@FreeBSD.org> Subject: Re: r314708: panic: tdsendsignal: ksi on queue References: <20170309144646.GB16105@kib.kiev.ua> <20170309231151.GA49720@stack.nl> <20170310104429.GH16105@kib.kiev.ua> In-Reply-To: <20170310104429.GH16105@kib.kiev.ua> --s8pxjajXRrMXgUNFqBjCDFaEVmSii711M Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/10/2017 2:44 AM, Konstantin Belousov wrote: > On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote: >> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginf= o >> should always be the zombie's p_ksi; otherwise, the siginfo may be los= t >> if there are too many signals pending for the target process or in the= >> system. If the siginfo is lost and the reaper normally passes si_pid t= o >> waitpid() or similar (instead of passing WAIT_ANY or P_ALL), a zombie >> will remain until the reaper terminates. >> >> Conceptually the siginfo is sent to one process at a time only, so the= >> bug is an artifact of the implementation. Perhaps the piece of code >> added in r309886 can be moved or the ksiginfo can be removed from the >> parent's queue. >> >> If such a fix is not possible, it may be better to send a bare SIGCHLD= >> (si_code is SI_KERNEL or 0, depending on how many signals are pending)= >> in this situation and document that reapers must use WAIT_ANY or P_ALL= =2E >> (However, compared to the pre-r309886 situation they can still use >> SIGCHLD to get notified when to call waitpid() or similar.) >> >=20 > IMO it is acceptable for reaper to know and handle the case of lost > siginfo. But also it seems to be not too hard to guarantee the queueing= > of the SIGCHLD for zombie re-parerning. >=20 > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > index c524fe5df37..1a1dcc3a4c7 100644 > --- a/sys/kern/kern_exit.c > +++ b/sys/kern/kern_exit.c > @@ -189,6 +189,7 @@ exit1(struct thread *td, int rval, int signo) > { > struct proc *p, *nq, *q, *t; > struct thread *tdt; > + ksiginfo_t *ksi, *ksi1; > =20 > mtx_assert(&Giant, MA_NOTOWNED); > KASSERT(rval =3D=3D 0 || signo =3D=3D 0, ("exit1 rv %d sig %d", rval,= signo)); > @@ -449,14 +450,23 @@ exit1(struct thread *td, int rval, int signo) > wakeup(q->p_reaper); > for (; q !=3D NULL; q =3D nq) { > nq =3D LIST_NEXT(q, p_sibling); > + ksi =3D ksiginfo_alloc(TRUE); > PROC_LOCK(q); > q->p_sigparent =3D SIGCHLD; > =20 > if (!(q->p_flag & P_TRACED)) { > proc_reparent(q, q->p_reaper); > if (q->p_state =3D=3D PRS_ZOMBIE) { > + if (q->p_ksi =3D=3D NULL) { > + ksi1 =3D NULL; > + } else { > + ksiginfo_copy(q->p_ksi, ksi); > + ksi->ksi_flags |=3D KSI_INS; > + ksi1 =3D ksi; > + ksi =3D NULL; > + } > PROC_LOCK(q->p_reaper); > - pksignal(q->p_reaper, SIGCHLD, q->p_ksi); > + pksignal(q->p_reaper, SIGCHLD, ksi1); > PROC_UNLOCK(q->p_reaper); > } > } else { > @@ -489,6 +499,8 @@ exit1(struct thread *td, int rval, int signo) > kern_psignal(q, SIGKILL); > } > PROC_UNLOCK(q); > + if (ksi !=3D NULL) > + ksiginfo_free(ksi); > } > =20 > /* Ping? Is this still progressing to be committed? --=20 Regards, Bryan Drewery --s8pxjajXRrMXgUNFqBjCDFaEVmSii711M-- --tmsQDFvpupFPGQB91xloAm82LFMhmjEXv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYzCpmAAoJEDXXcbtuRpfP/5UIAMH80G+OVLVc+UOitpwwVvw2 ZsudM2RenoHTZmGKXCIOEyGVRoGqcAFcL2+bzIXK8tWs6ORTvgfmQXJ1esv9Der+ pLAC/ezJ/gBQGuw863uvJEBj35TXhCzdAa01P++P+/R13v3aOJBBHPOqGNez6swz HuoE1mXKi44YUidFOWX/vVaxlHQZVgLbGHWWBCBj1cB8XU+m+vAS+iyLmpeD9y88 CX1DZDwFolZBhMJB4qz1Ce7tIqzj+8J13xhAlFl5IjNkF00RLlBXY75cr5Y9yajx 8EDufXLmCsAYdJK44tZGw2SnyVyf2EoTdFQXM1iQPTdwGh5Kk+mA9xFTYx99kCw= =wJFS -----END PGP SIGNATURE----- --tmsQDFvpupFPGQB91xloAm82LFMhmjEXv-- From owner-freebsd-current@freebsd.org Fri Mar 17 18:27:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4C92D10CAF for ; Fri, 17 Mar 2017 18:27:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE32710F1 for ; Fri, 17 Mar 2017 18:27:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2HIRcGR093765 for ; Fri, 17 Mar 2017 11:27:44 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20170317170735.GO70430@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de>, <20170317170735.GO70430@zxy.spb.ru> From: "Chris H" Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Date: Fri, 17 Mar 2017 11:27:44 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5882ca088f34336fd3fd75667b3d3342@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:27:25 -0000 Apologies for top posting (I generally HATE that too), and also, if someone already shared this link. BUT; I performed a search at my favorite CPU spec site, and it appears that your CPU *does* have AES-NI ( AESNI ): http://www.cpu-world.com/CPUs/Xeon/Intel-Xeon%20E5-1650%20v3.html TL,DR: MMX instructions SSE / Streaming SIMD Extensions SSE2 / Streaming SIMD Extensions SSE3 / Streaming SIMD Extensions SSSE3 / Supplemental Streaming SIMD Extensions 3 SSE4 / SSE4.1 + SSE4.2 / Streaming SIMD Extensions 4 AES / Advanced Encryption Standard instructions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AVX / Advanced Vector Extensions AVX2 / Advanced Vector Extensions 2.0 BMI / BMI1 + BMI2 / Bit Manipulation instructions F16C / 16-bit Floating-Point conversion instructions FMA3 / 3-operand Fused Multiply-Add instructions EM64T / Extended Memory 64 technology / Intel 64 NX / XD / Execute disable bit HT / Hyper-Threading technology VT-x / Virtualization technology VT-d / Virtualization for directed I/O TBT 2.0 / Turbo Boost technology 2.0 TXT / Trusted Execution technology You also indicated that sysutils/dmidecode failed for you. Could that mean that your lib(s) aren't in sync? Which might contribute to this anomaly? Just a thought. HTH --Chris On Fri, 17 Mar 2017 20:07:35 +0300 Slawa Olhovchenkov wrote > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > Slawa Olhovchenkov schrieb: > > > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an > > > Intel(R) > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > > > FreeBSD does not report the existence or availability of AES-NI > > > feature, which > is supposed to be a feature of this type of CPU: > > > > > > What reassons to detect AES-NI by FreeBSD? > > > > What do you mean? I do not understand! FreeBSD is supposed to read the > > CPUID and therefore the capabilities as every other OS, too. But there may > > some circumstances why FBSD won't. I do not know, that is the reason why > > I'm asking here. > > This sample can have disabled AES-NI by vendor, in BIOS, for example. > As I show by links this is posible. > > CPUID in you example don't show AES-NI capabilities, for example > 1650v4 w/ AES-NI > > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > Features=0xbfebfbff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x7ffefbff DBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESN > I,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > > ^^^^^^ AMD > Features=0x2c100800 AMD > Features2=0x121 Structured Extended > Features=0x21cbfbb QM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > TSC: P-state invariant, performance statistics > > In you sample: "TSCDLT,XSAVE" > > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug > in FreeBSD, AES-NI work and other OS show AES-NI capabilities. From owner-freebsd-current@freebsd.org Fri Mar 17 18:37:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C5E7D1006C for ; Fri, 17 Mar 2017 18:37:51 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 647FC1722 for ; Fri, 17 Mar 2017 18:37:51 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2HIcA3s095123 for ; Fri, 17 Mar 2017 11:38:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170317170735.GO70430@zxy.spb.ru>, <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> From: "Chris H" Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Date: Fri, 17 Mar 2017 11:38:16 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2001e35c407e63ae3ff055264fe0811f@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:37:51 -0000 On Fri, 17 Mar 2017 18:31:11 +0100 "O. Hartmann" wrote > Am Fri, 17 Mar 2017 20:07:35 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > > > > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > > Slawa Olhovchenkov schrieb: > > > > > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an > > > Intel(R) > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > > > > > FreeBSD does not report the existence or availability of AES-NI > > > feature, which > > is supposed to be a feature of this type of CPU: > > > > > > > > What reassons to detect AES-NI by FreeBSD? > > > > > > What do you mean? I do not understand! FreeBSD is supposed to read the > > > CPUID and therefore the capabilities as every other OS, too. But there > > > may some circumstances why FBSD won't. I do not know, that is the reason > > > why I'm asking here. > > > This sample can have disabled AES-NI by vendor, in BIOS, for example. > > As I show by links this is posible. > > > > CPUID in you example don't show AES-NI capabilities, for example > > 1650v4 w/ AES-NI > > > > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > > > Features=0xbfebfbff > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x7ffefbff > DBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESN > > I,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > > > > ^^^^^^ AMD > > > > Features=0x2c100800 > AMD > > Features2=0x121 > > > Structured Extended > > > Features=0x21cbfbb > QM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> > > > XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > > TSC: P-state invariant, performance statistics > > > > In you sample: "TSCDLT,XSAVE" > > > > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug > > in FreeBSD, AES-NI work and other OS show AES-NI capabilities. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > We have some LGA1151 XEON based 19 inch rack server, also equipted with > Haswell E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. > > You're right, the vendor could have disabled AES-NI by intention - but they > offered this box especially with AES-NI capabilities. > > See here: > > > http://freebsd.1045724.x6.nabble.com/r285947-broken-AESNI-support-No-aesni0-o > n-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740-td6028895.html > > I feel a bit pissed off right now due to Fujitsu, because we started testing > some encrypting features and I'd like to use AES-NI and I run into this issue > again. > > I need to know that FreeBSD is not the issue with this specific CPU type. I'm > still frustrated by that stupid comment "UNIX is not supoorted" I got that > time then when I reported 2015 the issue to Fujitsu. FWIW It *does* for me - altho an AMD, not INTEL # cat /var/run/dmesg.boot | grep AES Features2=0x3e98320b ^^^^^ HTH --Chris > > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Ãœbermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). From owner-freebsd-current@freebsd.org Fri Mar 17 19:05:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57352D10779 for ; Fri, 17 Mar 2017 19:05:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 011CB1747; Fri, 17 Mar 2017 19:05:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2HJ5E1m053910 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 21:05:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2HJ5E1m053910 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2HJ5Ege053908; Fri, 17 Mar 2017 21:05:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2017 21:05:14 +0200 From: Konstantin Belousov To: Bryan Drewery Cc: freebsd-current@freebsd.org Subject: Re: r314708: panic: tdsendsignal: ksi on queue Message-ID: <20170317190514.GV16105@kib.kiev.ua> References: <20170309144646.GB16105@kib.kiev.ua> <20170309231151.GA49720@stack.nl> <20170310104429.GH16105@kib.kiev.ua> <21c8bb48-df8e-f126-e664-e963274f6d48@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21c8bb48-df8e-f126-e664-e963274f6d48@FreeBSD.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:05:25 -0000 On Fri, Mar 17, 2017 at 11:26:43AM -0700, Bryan Drewery wrote: > On 3/10/2017 2:44 AM, Konstantin Belousov wrote: > > On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote: > >> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo > >> should always be the zombie's p_ksi; otherwise, the siginfo may be lost > >> if there are too many signals pending for the target process or in the > >> system. If the siginfo is lost and the reaper normally passes si_pid to > >> waitpid() or similar (instead of passing WAIT_ANY or P_ALL), a zombie > >> will remain until the reaper terminates. > >> > >> Conceptually the siginfo is sent to one process at a time only, so the > >> bug is an artifact of the implementation. Perhaps the piece of code > >> added in r309886 can be moved or the ksiginfo can be removed from the > >> parent's queue. > >> > >> If such a fix is not possible, it may be better to send a bare SIGCHLD > >> (si_code is SI_KERNEL or 0, depending on how many signals are pending) > >> in this situation and document that reapers must use WAIT_ANY or P_ALL. > >> (However, compared to the pre-r309886 situation they can still use > >> SIGCHLD to get notified when to call waitpid() or similar.) > >> > > > > IMO it is acceptable for reaper to know and handle the case of lost > > siginfo. But also it seems to be not too hard to guarantee the queueing > > of the SIGCHLD for zombie re-parerning. > > > > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > > index c524fe5df37..1a1dcc3a4c7 100644 > > --- a/sys/kern/kern_exit.c > > +++ b/sys/kern/kern_exit.c > > @@ -189,6 +189,7 @@ exit1(struct thread *td, int rval, int signo) > > { > > struct proc *p, *nq, *q, *t; > > struct thread *tdt; > > + ksiginfo_t *ksi, *ksi1; > > > > mtx_assert(&Giant, MA_NOTOWNED); > > KASSERT(rval == 0 || signo == 0, ("exit1 rv %d sig %d", rval, signo)); > > @@ -449,14 +450,23 @@ exit1(struct thread *td, int rval, int signo) > > wakeup(q->p_reaper); > > for (; q != NULL; q = nq) { > > nq = LIST_NEXT(q, p_sibling); > > + ksi = ksiginfo_alloc(TRUE); > > PROC_LOCK(q); > > q->p_sigparent = SIGCHLD; > > > > if (!(q->p_flag & P_TRACED)) { > > proc_reparent(q, q->p_reaper); > > if (q->p_state == PRS_ZOMBIE) { > > + if (q->p_ksi == NULL) { > > + ksi1 = NULL; > > + } else { > > + ksiginfo_copy(q->p_ksi, ksi); > > + ksi->ksi_flags |= KSI_INS; > > + ksi1 = ksi; > > + ksi = NULL; > > + } > > PROC_LOCK(q->p_reaper); > > - pksignal(q->p_reaper, SIGCHLD, q->p_ksi); > > + pksignal(q->p_reaper, SIGCHLD, ksi1); > > PROC_UNLOCK(q->p_reaper); > > } > > } else { > > @@ -489,6 +499,8 @@ exit1(struct thread *td, int rval, int signo) > > kern_psignal(q, SIGKILL); > > } > > PROC_UNLOCK(q); > > + if (ksi != NULL) > > + ksiginfo_free(ksi); > > } > > > > /* > > > Ping? Is this still progressing to be committed? r315159 ? From owner-freebsd-current@freebsd.org Fri Mar 17 19:48:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2782ED10CFD for ; Fri, 17 Mar 2017 19:48:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBB9D13E4; Fri, 17 Mar 2017 19:48:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::4430:14cb:bc65:3899] (unknown [IPv6:2001:7b8:3a7:0:4430:14cb:bc65:3899]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 728D32EDAD; Fri, 17 Mar 2017 20:48:02 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8A484A28-704E-438B-B7AB-1F5F014DD938"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: process killed: text file modification Date: Fri, 17 Mar 2017 20:47:53 +0100 In-Reply-To: <20170317141917.GS16105@kib.kiev.ua> Cc: Rick Macklem , Ian Lepore , Gergely Czuczy , FreeBSD Current To: Konstantin Belousov References: <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:48:11 -0000 --Apple-Mail=_8A484A28-704E-438B-B7AB-1F5F014DD938 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Mar 2017, at 15:19, Konstantin Belousov = wrote: >=20 > On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote: >> Well, I don't mind adding ncl_flush(), but it shouldn't be >> necessary. I actually had it in the first >> rendition of the patch, but took it out because it should happen >> on the VOP_CLOSE() if any writing to the buffer cache happened >> and that code hasn't changed in many years. > Dirty pages are flushed by writes, so if we have a set of dirty pages = and > async vm_object_page_clean() is called on the vnode' vm_object, we get > a bunch of delayed-write AKA dirty buffers. This is possible even = after > VOP_CLOSE() was done, e.g. by syncer performing regular run involving > vfs_msync(). >=20 > I agree that the patch would not create new dirty buffers, but it is = possible > to get them by other means. >=20 >>=20 >> What the patch was missing was updating n_mtime after the dirty >> page flush. >>=20 >> Btw, a flush without OBJPC_SYNC happens when the file is = VOP_CLOSE()'d >> unless the default value of vfs.nfs.clean_[ages_on_close is changed, = which >> I think is why the 1sec resolution always seemed to work, at least = for the >> example where there was an munmap before close. >>=20 >> Attached is an updated version with that in it, rick FWIW, Rick's patch seems to do the trick, both for my test case and lld itself. And even with vfs.timestamp_precision=3D3 on both server and client. -Dimitry --Apple-Mail=_8A484A28-704E-438B-B7AB-1F5F014DD938 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljMPXEACgkQsF6jCi4glqOi3wCfRpH+RjEYSVN4InJXsFdyUdZc v2wAn3AD55eetKriKKscKDN1g527zobq =LD1C -----END PGP SIGNATURE----- --Apple-Mail=_8A484A28-704E-438B-B7AB-1F5F014DD938-- From owner-freebsd-current@freebsd.org Fri Mar 17 19:51:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EBBBD10FDD for ; Fri, 17 Mar 2017 19:51:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 C4F571900 for ; Fri, 17 Mar 2017 19:51:50 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1coxud-000P6b-Ew; Fri, 17 Mar 2017 22:51:47 +0300 Date: Fri, 17 Mar 2017 22:51:47 +0300 From: Slawa Olhovchenkov To: "O. Hartmann" Cc: freebsd-current Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 Message-ID: <20170317195147.GA86500@zxy.spb.ru> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170317170735.GO70430@zxy.spb.ru> <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:51:51 -0000 On Fri, Mar 17, 2017 at 06:31:11PM +0100, O. Hartmann wrote: > Am Fri, 17 Mar 2017 20:07:35 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > > > > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > > Slawa Olhovchenkov schrieb: > > > > > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) > > > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > > > > > FreeBSD does not report the existence or availability of AES-NI feature, which > > > > > is supposed to be a feature of this type of CPU: > > > > > > > > What reassons to detect AES-NI by FreeBSD? > > > > > > What do you mean? I do not understand! FreeBSD is supposed to read the CPUID and > > > therefore the capabilities as every other OS, too. But there may some circumstances > > > why FBSD won't. I do not know, that is the reason why I'm asking here. > > > > This sample can have disabled AES-NI by vendor, in BIOS, for example. > > As I show by links this is posible. > > > > CPUID in you example don't show AES-NI capabilities, for example > > 1650v4 w/ AES-NI > > > > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > Features=0xbfebfbff > > Features2=0x7ffefbff > > ^^^^^^ > > AMD Features=0x2c100800 > > AMD Features2=0x121 > > Structured Extended > > Features=0x21cbfbb > > XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > > TSC: P-state invariant, performance statistics > > > > In you sample: "TSCDLT,XSAVE" > > > > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug in FreeBSD, > > AES-NI work and other OS show AES-NI capabilities. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > We have some LGA1151 XEON based 19 inch rack server, also equipted with Haswell > E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. > > You're right, the vendor could have disabled AES-NI by intention - but they offered this > box especially with AES-NI capabilities. > > See here: > > http://freebsd.1045724.x6.nabble.com/r285947-broken-AESNI-support-No-aesni0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740-td6028895.html > > I feel a bit pissed off right now due to Fujitsu, because we started testing some > encrypting features and I'd like to use AES-NI and I run into this issue again. > > I need to know that FreeBSD is not the issue with this specific CPU type. I'm still > frustrated by that stupid comment "UNIX is not supoorted" I got that time then when I > reported 2015 the issue to Fujitsu. JFYI: 11-STABLE CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU) ^^^^^^^^^^^^^^^^^^^^^^^^ Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xbfebfbff Features2=0x7ffefbff ^^^^^ AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x37ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics From owner-freebsd-current@freebsd.org Fri Mar 17 20:27:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BF5BD102BA for ; Fri, 17 Mar 2017 20:27:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF4511D5 for ; Fri, 17 Mar 2017 20:27:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v2HKQu1c074111; Fri, 17 Mar 2017 13:27:00 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201703172027.v2HKQu1c074111@gw.catspoiler.org> Date: Fri, 17 Mar 2017 13:26:56 -0700 (PDT) From: Don Lewis Subject: Re: ntpd dies nightly on a server with jails To: ohartmann@walstatt.org cc: Cy.Schubert@komquats.com, freebsd-current@freebsd.org In-Reply-To: <20170317180507.5c64fb26@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 20:27:05 -0000 On 17 Mar, O. Hartmann wrote: > Just some strange news: > > I left the server the whole day with ntpd disabled and I didn't watch > a gain of the RTC by one second, even stressing the machine. > > But soon after restarting ntpd, I realised immediately a 30 minutes > off! This morning, the discrapancy was almost 5 hours - it looked more > like a weird ajustment to another time base than UTC. > > Over the weekend I'll leave the server with ntpd disabled and only RTC > running. I've the strange feeling that something is intentionally > readjusting the ntpd time due to a misconfiguration or a rogue ntp > server in the X.CC.pool.ntp.org A ntp should recognize a single bad server and ignore it in favor of the other servers that are sane. It sounds like something is going off the rails once ntpd starts calling adjtime(). What is the output of: sysctl kern.clockrate I'd suggest starting ntpd and running "ntpq -c pe" a few times a minute and capturing its output to monitor the status of ntpd as it starts up and try to capture things going wrong. You should probably disable iburst in ntp.conf to give more visibility in the early startup. For the first few minutes ntpd should just be getting reliable timestamp info and won't start trying to adjust the clock until it has captured endough samples and figured out which servers are best. Then the behaviour of the offset is the thing to watch. If the iniital offset is large enough, ntpd will step the clock once to get it close to zero, otherwise it will just use adjtime to slowy push the offset towards zero. I think though that you will see the offset start gyrating madly. You might want to set /var/db/ntpd.drift to zero beforehand if there is an insane value in there. If the initial drift value is bogus, will try to use it which will push the time offset away from zero so fast that it will decide to keep stepping the clock back to zero before it can capture enough samples from the external servers to determine the true local clock drift rate. From owner-freebsd-current@freebsd.org Fri Mar 17 20:31:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E3E5D106DC for ; Fri, 17 Mar 2017 20:31:00 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 5CB6C16EB for ; Fri, 17 Mar 2017 20:31:00 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-pg0-x22d.google.com with SMTP id n190so48523696pga.0 for ; Fri, 17 Mar 2017 13:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MjY6+z85bxCwosfxn08sTnUpqXGpv1aMByVKeNXREkQ=; b=I/2URZQzKPVlmsHT7ups2+kk/KugO7m3S5JEsWVpMhMFcn/wnOsI7Hi5FL063UP8f7 +dSNev/3HjMVs6SfNZFqMHGzCLjZDvbuBg/v9DxaaDolPGHRGCWcBJijSxUKom9zJeb9 tPgCD7vo/hT0h330qXZ1UQZW6Z0aTUR9MODoABMmTTXWI+P4KeHWuLsKAHFZbpDUTlR1 RhqHHH3c16xsfVy1X4kI3H+F7C2XzYdhCo4lc4r6Oq463iQey2csaIYtjogWx2UtzccY VCWCstbYQ+PA91Eb+5xPhlhXpH2rgYqAFNWSf40//66CqzQekd5UYoYw7ZwLBXk+lLNv wPsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MjY6+z85bxCwosfxn08sTnUpqXGpv1aMByVKeNXREkQ=; b=h9nzmfLbNd/C7zjT6x2pG5T6tZtTPQ888MZ6nmDXo32s+Std2TiZl66482As39M/Dd +khNxq08UG6OE2G2h+P2EqwTR8yLALFLjPAVW3AQ4zhebrEBEx1v/5Unia6wXCmgJl7j Y8fw3myVMZXdG12FSRrSAJlrQG1WVLn9MEDjOBeshP0yicdlS54pGidECF/dxfpF7zU3 2ruhJ76GGG5ampy+Mia4I/vJ+DhRKWtqLMmHtZVfKs30MRG5Sd4nHIq+15j1J7Ce1Yac IXIAN62dVTvpHXW5xxsrFS/z4iMTJL/V1534iexL22orb0PhhqI6VGZ972XuMcK/y/hG QIeA== X-Gm-Message-State: AFeK/H2QTuGcp6q9lcnID8XQFDGFzAfLDhvMxUI6UbEl6bZMjDyPt5KUojveGnl5tBwmSmKIV14r+kAX+kwR2A== X-Received: by 10.99.185.91 with SMTP id v27mr7620060pgo.65.1489782659818; Fri, 17 Mar 2017 13:30:59 -0700 (PDT) MIME-Version: 1.0 Sender: pkelsey@gmail.com Received: by 10.100.166.166 with HTTP; Fri, 17 Mar 2017 13:30:59 -0700 (PDT) In-Reply-To: <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170317170735.GO70430@zxy.spb.ru> <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> From: Patrick Kelsey Date: Fri, 17 Mar 2017 16:30:59 -0400 X-Google-Sender-Auth: xDv-mb6Du0LCoXWdjuqO5lCZb8M Message-ID: Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 To: "O. Hartmann" Cc: Slawa Olhovchenkov , freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 20:31:00 -0000 On Fri, Mar 17, 2017 at 1:31 PM, O. Hartmann wrote: > Am Fri, 17 Mar 2017 20:07:35 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > > > > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > > Slawa Olhovchenkov schrieb: > > > > > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an > Intel(R) > > > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > > > > > FreeBSD does not report the existence or availability of AES-NI > feature, which > > > > > is supposed to be a feature of this type of CPU: > > > > > > > > What reassons to detect AES-NI by FreeBSD? > > > > > > What do you mean? I do not understand! FreeBSD is supposed to read the > CPUID and > > > therefore the capabilities as every other OS, too. But there may some > circumstances > > > why FBSD won't. I do not know, that is the reason why I'm asking here. > > > > This sample can have disabled AES-NI by vendor, in BIOS, for example. > > As I show by links this is posible. > > > > CPUID in you example don't show AES-NI capabilities, for example > > 1650v4 w/ AES-NI > > > > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > Features=0xbfebfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI, > MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x7ffefbff VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA, > SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE, > OSXSAVE,AVX,F16C,RDRAND> > > > > ^^^^^^ > > AMD Features=0x2c100800 > > AMD Features2=0x121 > > Structured Extended > > Features=0x21cbfbb BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> > > XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID, > VID,PostIntr > > TSC: P-state invariant, performance statistics > > > > In you sample: "TSCDLT,XSAVE" > > > > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some > bug in FreeBSD, > > AES-NI work and other OS show AES-NI capabilities. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > We have some LGA1151 XEON based 19 inch rack server, also equipted with > Haswell > E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. > > You're right, the vendor could have disabled AES-NI by intention - but > they offered this > box especially with AES-NI capabilities. > > See here: > > http://freebsd.1045724.x6.nabble.com/r285947-broken- > AESNI-support-No-aesni0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740- > td6028895.html > > I feel a bit pissed off right now due to Fujitsu, because we started > testing some > encrypting features and I'd like to use AES-NI and I run into this issue > again. > > I need to know that FreeBSD is not the issue with this specific CPU type. > I'm still > frustrated by that stupid comment "UNIX is not supoorted" I got that time > then when I > reported 2015 the issue to Fujitsu. > > > It's pretty straightforward to gain confidence that FreeBSD is not the issue here. The 'Features2=' line is printed by printcpuinfo() in sys/x86/x86/identcpu.c based on the bits set in a variable called cpu_feature2 (the printf is currently at line 802). The value of cpu_feature2 is set in identify_cpu() identcpu.c (for amd64, currently at line 1401) based on the result of the cpuid instruction that is executed by a call to do_cpuid(), which itself resides in sys/amd64/include/cpufunc.h. In other words, a single asm instruction is executed and the set bits from the result are printed. Based on some poking around in open source bits (tianocore, coreboot), it appears that AES-NI is something the BIOS can irreversibly disable-until-next-reset by twiddling bits in the appropriate MSR register. There is no code that does this in FreeBSD on purpose, so there would have to be a bug introduced in -CURRENT that somehow clobbers those MSR bits early on - a bug that was also not merged to 11-STABLE (since Slawa shows AESNI enabled on the same processor under 11-STABLE). I will also say that I have dealt with a manufacturer of Xeon hardware in Europe who will not provide a stock BIOS that allows you to enable AES-NI, out of concerns over violating export/import rules governing encryption technology. With that vendor, you have to pass an end-user verification and then they will make you a custom BIOS that gives you the option to enable AES-NI. It took quite some time working through the outer layers of their support organization to even determine that this was the underlying (bureaucratic) issue. Here is another data point: 11.0-RELEASE-p1 running on E5-1650 v3 with AESNI recognized as enabled. You could install that stock FreeBSD release and if it does not show AESNI as enabled on your system, you will clearly know it is not a FreeBSD problem without any question as to whether there is a bug in CURRENT or having to build and install the exact rev of 11-STABLE that Slawa is using. uname: FreeBSD ttest2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 dmesg: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xbfebfbff Features2=0x7ffefbff -Patrick From owner-freebsd-current@freebsd.org Fri Mar 17 20:33:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56B1ED10A14 for ; Fri, 17 Mar 2017 20:33:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 E528A1AB2 for ; Fri, 17 Mar 2017 20:33:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f1c055a3-0b50-11e7-b96d-2378c10e3beb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id f1c055a3-0b50-11e7-b96d-2378c10e3beb; Fri, 17 Mar 2017 20:33:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2HKXDo1009605; Fri, 17 Mar 2017 14:33:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489782793.40576.185.camel@freebsd.org> Subject: Re: ntpd dies nightly on a server with jails From: Ian Lepore To: Don Lewis , ohartmann@walstatt.org Cc: Cy.Schubert@komquats.com, freebsd-current@freebsd.org Date: Fri, 17 Mar 2017 14:33:13 -0600 In-Reply-To: <201703172027.v2HKQu1c074111@gw.catspoiler.org> References: <201703172027.v2HKQu1c074111@gw.catspoiler.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 20:33:28 -0000 On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote: > On 17 Mar, O. Hartmann wrote: > > > > > Just some strange news: > > > > I left the server the whole day with ntpd disabled and I didn't > > watch > > a gain of the RTC by one second, even stressing the machine. > > > > But soon after restarting ntpd, I realised immediately a 30 minutes > > off! This morning, the discrapancy was almost 5 hours - it looked > > more > > like a weird ajustment to another time base than UTC. > > > > Over the weekend I'll leave the server with ntpd disabled and only > > RTC > > running. I've the strange feeling that something is intentionally > > readjusting the ntpd time due to a misconfiguration or a rogue ntp > > server in the X.CC.pool.ntp.org > A ntp should recognize a single bad server and ignore it in favor of  > the other servers that are sane. > > It sounds like something is going off the rails once ntpd starts > calling > adjtime().  What is the output of: > sysctl kern.clockrate > > I'd suggest starting ntpd and running "ntpq -c pe" a few times a > minute > and capturing its output to monitor the status of ntpd as it starts > up > and try to capture things going wrong.   You should probably disable > iburst in ntp.conf to give more visibility in the early startup. > > For the first few minutes ntpd should just be getting reliable > timestamp > info and won't start trying to adjust the clock until it has captured > endough samples and figured out which servers are best.  Then the > behaviour of the offset is the thing to watch.  If the iniital offset > is > large enough, ntpd will step the clock once to get it close to zero, > otherwise it will just use adjtime to slowy push the offset towards > zero.  I think though that you will see the offset start gyrating > madly. > > You might want to set /var/db/ntpd.drift to zero beforehand if there > is > an insane value in there.  If the initial drift value is bogus, will > try > to use it which will push the time offset away from zero so fast that > it > will decide to keep stepping the clock back to zero before it can > capture enough samples from the external servers to determine the > true > local clock drift rate. Do not set ntpd.drift contents to zero.  Delete the file.  There's a huge difference between a file that says the clock is perfect and a missing file which triggers ntpd to do a 15-minute frequency measurement to come up with the initial drift correction. -- Ian From owner-freebsd-current@freebsd.org Fri Mar 17 20:42:37 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEB49D10C7B for ; Fri, 17 Mar 2017 20:42:37 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 BCE131F3A for ; Fri, 17 Mar 2017 20:42:37 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 32511138DE for ; Fri, 17 Mar 2017 20:42:35 +0000 (UTC) Subject: Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3 To: freebsd-current@freebsd.org References: <20170317123625.60f1a508@freyja.zeit4.iv.bundesimmobilien.de> <20170317120429.GX15630@zxy.spb.ru> <20170317175324.27f1d59d@thor.intern.walstatt.dynvpn.de> <20170317170735.GO70430@zxy.spb.ru> <20170317183111.3a80f358@thor.intern.walstatt.dynvpn.de> From: Allan Jude Message-ID: Date: Fri, 17 Mar 2017 16:42:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 20:42:38 -0000 On 2017-03-17 16:30, Patrick Kelsey wrote: > On Fri, Mar 17, 2017 at 1:31 PM, O. Hartmann wrote: > >> Am Fri, 17 Mar 2017 20:07:35 +0300 >> Slawa Olhovchenkov schrieb: >> >>> On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: >>> >>>> Am Fri, 17 Mar 2017 15:04:29 +0300 >>>> Slawa Olhovchenkov schrieb: >>>> >>>>> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: >>>>> >>>>>> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an >> Intel(R) >>>>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. >>>>>> >>>>>> FreeBSD does not report the existence or availability of AES-NI >> feature, which >>>>>> is supposed to be a feature of this type of CPU: >>>>> >>>>> What reassons to detect AES-NI by FreeBSD? >>>> >>>> What do you mean? I do not understand! FreeBSD is supposed to read the >> CPUID and >>>> therefore the capabilities as every other OS, too. But there may some >> circumstances >>>> why FBSD won't. I do not know, that is the reason why I'm asking here. >>> >>> This sample can have disabled AES-NI by vendor, in BIOS, for example. >>> As I show by links this is posible. >>> >>> CPUID in you example don't show AES-NI capabilities, for example >>> 1650v4 w/ AES-NI >>> >>> CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) >>> Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 >>> Features=0xbfebfbff> APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI, >> MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >>> Features2=0x7ffefbff> VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA, >> SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE, >> OSXSAVE,AVX,F16C,RDRAND> >>> >> >> ^^^^^^ >>> AMD Features=0x2c100800 >>> AMD Features2=0x121 >>> Structured Extended >>> Features=0x21cbfbb> BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> >>> XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID, >> VID,PostIntr >>> TSC: P-state invariant, performance statistics >>> >>> In you sample: "TSCDLT,XSAVE" >>> >>> May be AES-NI disabled by vendor and FreeBSD correct show this. Or some >> bug in FreeBSD, >>> AES-NI work and other OS show AES-NI capabilities. >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >> freebsd.org" >> >> We have some LGA1151 XEON based 19 inch rack server, also equipted with >> Haswell >> E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. >> >> You're right, the vendor could have disabled AES-NI by intention - but >> they offered this >> box especially with AES-NI capabilities. >> >> See here: >> >> http://freebsd.1045724.x6.nabble.com/r285947-broken- >> AESNI-support-No-aesni0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740- >> td6028895.html >> >> I feel a bit pissed off right now due to Fujitsu, because we started >> testing some >> encrypting features and I'd like to use AES-NI and I run into this issue >> again. >> >> I need to know that FreeBSD is not the issue with this specific CPU type. >> I'm still >> frustrated by that stupid comment "UNIX is not supoorted" I got that time >> then when I >> reported 2015 the issue to Fujitsu. >> >> >> > It's pretty straightforward to gain confidence that FreeBSD is not the > issue here. The 'Features2=' line is printed by printcpuinfo() in > sys/x86/x86/identcpu.c based on the bits set in a variable called > cpu_feature2 (the printf is currently at line 802). The value of > cpu_feature2 is set in identify_cpu() identcpu.c (for amd64, currently at > line 1401) based on the result of the cpuid instruction that is executed by > a call to do_cpuid(), which itself resides in sys/amd64/include/cpufunc.h. > In other words, a single asm instruction is executed and the set bits from > the result are printed. > > Based on some poking around in open source bits (tianocore, coreboot), it > appears that AES-NI is something the BIOS can irreversibly > disable-until-next-reset by twiddling bits in the appropriate MSR > register. There is no code that does this in FreeBSD on purpose, so there > would have to be a bug introduced in -CURRENT that somehow clobbers those > MSR bits early on - a bug that was also not merged to 11-STABLE (since > Slawa shows AESNI enabled on the same processor under 11-STABLE). > > I will also say that I have dealt with a manufacturer of Xeon hardware in > Europe who will not provide a stock BIOS that allows you to enable AES-NI, > out of concerns over violating export/import rules governing encryption > technology. With that vendor, you have to pass an end-user verification > and then they will make you a custom BIOS that gives you the option to > enable AES-NI. It took quite some time working through the outer layers of > their support organization to even determine that this was the underlying > (bureaucratic) issue. > > Here is another data point: 11.0-RELEASE-p1 running on E5-1650 v3 with > AESNI recognized as enabled. You could install that stock FreeBSD release > and if it does not show AESNI as enabled on your system, you will clearly > know it is not a FreeBSD problem without any question as to whether there > is a bug in CURRENT or having to build and install the exact rev of > 11-STABLE that Slawa is using. > > uname: > FreeBSD ttest2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep > 29 01:43:23 UTC 2016 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC > amd64 > > dmesg: > CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 > > Features=0xbfebfbff > Features2=0x7ffefbff > > > -Patrick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I can also confirm it works fine on FreeBSD 11.0-RELEASE-p1 on the E5-1650 v3, as I did all of the testing for my recent AsiaBSDCon paper of SSH performance, on a pair of identical E5-1650 v3's in the FreeBSD Test Cluster @ Sentex. -- Allan Jude From owner-freebsd-current@freebsd.org Fri Mar 17 21:23:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E969ED1077B for ; Fri, 17 Mar 2017 21:23:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660088.outbound.protection.outlook.com [40.107.66.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9462A1682; Fri, 17 Mar 2017 21:23:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Fri, 17 Mar 2017 21:23:00 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Fri, 17 Mar 2017 21:23:00 +0000 From: Rick Macklem To: Dimitry Andric , Konstantin Belousov CC: Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PP Date: Fri, 17 Mar 2017 21:23:00 +0000 Message-ID: References: <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: 8179d254-b3e6-4d37-f895-08d46d7bca20 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0189; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:/osaAg8Os3ZzfxGag1knvqOJDhcgnvN+qr0LZacZ/u+mdo2Z4SUlcct0TGcZq88rDrxhdj7m2Mci2WKVQuVUnEb2cvcqmQuHFgl/sRM+ZFahUk52pXVtyQIjaWdt95a/VWI7JG4qKqhb0U0/p7LoT8SKorVWwKrtaTl8ZzaaJ91JsF+Vt/lgjEqynoiHfaX8ch4on/YblPT2Vj5EWykDcWiphA8Res6fCcL2z+sStGzav4vMZ3ib/G0qpEa1RJ9i1S6hVfvCvSNhbzhspJmaGN1RpvOcwFqwsQXh1WIR/tD+RP5DnwNGJt54JALiJESCeKXUg21dhDNfquUp+UCB8g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(81166006)(102836003)(8676002)(8936002)(50986999)(86362001)(39060400002)(4326008)(74482002)(6246003)(33656002)(38730400002)(74316002)(305945005)(229853002)(2950100002)(93886004)(6506006)(9686003)(54356999)(6436002)(76176999)(122556002)(5660300001)(53936002)(189998001)(2900100001)(7696004)(3280700002)(77096006)(55016002)(54906002)(3660700001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 21:23:00.4395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:23:04 -0000 Dimitry Andric wrote: >On 17 Mar 2017, at 15:19, Konstantin Belousov wrote: >> >> On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote: >>> Well, I don't mind adding ncl_flush(), but it shouldn't be >>> necessary. I actually had it in the first >>> rendition of the patch, but took it out because it should happen >>> on the VOP_CLOSE() if any writing to the buffer cache happened >>> and that code hasn't changed in many years. >> Dirty pages are flushed by writes, so if we have a set of dirty pages an= d >> async vm_object_page_clean() is called on the vnode' vm_object, we get >> a bunch of delayed-write AKA dirty buffers. This is possible even after >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving >> vfs_msync(). When I was talking about ncl_flush() above, I was referring to buffer cache buffers written by a write(2) syscall, not the case of mmap'd pages. >> >> I agree that the patch would not create new dirty buffers, but it is pos= sible >> to get them by other means. To write to a buffer cache block, the file would be opened by another threa= d and that is what this sanity check was meant to catch. As for dirtying pages th= at are mmap'd, as far as I understand it, the NFS client has no way of knowing if this wil= l happen more until VOP_INACTIVE() is called on the vnode. To be honest, this check could easily be deleted. After all, NFS could care= less if a file is being executed (all it sees are reads and writes). Without the check, th= e executable might do "interesting" things;-) [stuff snipped] > FWIW, Rick's patch seems to do the trick, both for my test case and lld > itself. And even with vfs.timestamp_precision=3D3 on both server and > client. Hopefully the original reporter of the problem (Gergely ??) can test the pa= tch as well. I think the patch is pretty harmless, although it could be argued that sett= ing np->m_mtime =3D np->n_nattr.na_mtime (or close to that) shouldn't happen for the case where there isn't any dirty pages found to fl= ush. However, once a file mmap'd we don't know when it does get modified anyhow (as discussed above), so setting it here doesn't seem harmful to me. Thanks for testing the patch. Now, if others can test it...rick From owner-freebsd-current@freebsd.org Fri Mar 17 21:31:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 690F3D10CC0; Fri, 17 Mar 2017 21:31:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660063.outbound.protection.outlook.com [40.107.66.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 053641192; Fri, 17 Mar 2017 21:31:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Fri, 17 Mar 2017 21:31:43 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0961.022; Fri, 17 Mar 2017 21:31:43 +0000 From: Rick Macklem To: Larry Rosenman , "freebsd-fs@freebsd.org" CC: "freebsd-current@FreeBSD.org" Subject: Re: crash: umount_nfs: Current Thread-Topic: crash: umount_nfs: Current Thread-Index: AQHSnf9DKC+Zb1AjDkCvB/ns2F6CGqGYEmLZgAAQyoCAAWs93w== Date: Fri, 17 Mar 2017 21:31:43 +0000 Message-ID: References: <20170316024433.qiujcewz5bclbgq5@borg.lerctr.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lerctr.org; dkim=none (message not signed) header.d=none;lerctr.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-office365-filtering-correlation-id: e26a0004-4c66-43c7-5009-08d46d7d021a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0190; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:FIsWxWNnHsxXkJ5zO7jj34uNQVWqAZjp7h3M0Z5hy2dIb7seDYWemgfD6xvo7RHhfGajW3Tx9Qn7mdvzu667TLfaNnfubeelSSZEKPzpF9motQlGBIDp6ZPbe+IAosfOVJ70dxULh7uF+2kUzbPJb2Ny3jq9veK4kCN9weIy3NYTgD8zmYjA+TOkrdrWn9INS9V3Oh/Ih5ZXDPnO00eWIbe09U9TjpYub/ssA0CQZ6+gUZCyVm0bDHuPvTALjMUJHQaLCx5oV7NCfzjX3G68JSQAXv+w3oCK56Lp3VQbk5GwTfeXiUVdFtkRfTnP/3WgzX1zGyKD77w3A7HtHyLZUw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(250305191791016)(158342451672863)(22074186197030)(209352067349851)(75325880899374)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(252514010)(77096006)(122556002)(7696004)(8936002)(74316002)(6506006)(2501003)(305945005)(229853002)(3280700002)(2900100001)(53546008)(4326008)(102836003)(3660700001)(53376002)(38730400002)(6436002)(86362001)(55016002)(2906002)(5660300001)(6306002)(966004)(189998001)(575784001)(9686003)(6246003)(81166006)(76176999)(50986999)(54356999)(8676002)(74482002)(2950100002)(33656002)(2004002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 21:31:43.8294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:31:47 -0000 Oops, yea I see that now. In the krpc it is very hard to tell when the data= structures (that hold the mutexes) can be safely free'd. Code like xprt_unregister() g= et called asynchronously and lock a mutex as soon as called. (The crash fixed by r313735 was a prematurely free'd mutex that xprt_unregi= ster() used, but on the server side.) I'll look at the code as see if I can figure out how to delay freeing the s= tructure without leaving it allocated "forever". (I'll admit I've been tempted to just never= free it, since the memory leak this would cause would be small enough nothing would really= notice it. And, of course for your case of shutdown, it would be harmless to just = not free it.) rick ________________________________________ From: Larry Rosenman Sent: Thursday, March 16, 2017 7:46:51 PM To: Rick Macklem; freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: crash: umount_nfs: Current Err, I=92m at r315289=85. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 On 3/16/17, 5:51 PM, "Rick Macklem" wrote: I believe the cause of this crash was fixed by a recent commit to head r313735 (which was MFC'd to stable/11 and stable/10). rick ________________________________________ From: owner-freebsd-current@freebsd.org on behalf of Larry Rosenman Sent: Wednesday, March 15, 2017 10:44:33 PM To: freebsd-fs@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: crash: umount_nfs: Current Recent current, playing with new FreeNAS Corral, client is FreeBSD -CUR= RENT. Lovely crash: borg.lerctr.org dumped core - see /var/crash/vmcore.1 Wed Mar 15 21:38:53 CDT 2017 FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: = Tue Mar 14 20:55:36 CDT 2017 root@borg.lerctr.org:/usr/obj/usr/src/sys/= VT-LER amd64 panic: general protection fault GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copyi= ng" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/li= b/debug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 1; apic id =3D 21 instruction pointer =3D 0x20:0xffffffff80a327ae stack pointer =3D 0x28:0xfffffe535ebb2800 frame pointer =3D 0x28:0xfffffe535ebb2830 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 3172 (umount) trap number =3D 9 panic: general protection fault cpuid =3D 1 time =3D 1489631515 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe535= ebb2440 vpanic() at vpanic+0x19c/frame 0xfffffe535ebb24c0 panic() at panic+0x43/frame 0xfffffe535ebb2520 trap_fatal() at trap_fatal+0x322/frame 0xfffffe535ebb2570 trap() at trap+0x5e/frame 0xfffffe535ebb2730 calltrap() at calltrap+0x8/frame 0xfffffe535ebb2730 --- trap 0x9, rip =3D 0xffffffff80a327ae, rsp =3D 0xfffffe535ebb2800, r= bp =3D 0xfffffe535ebb2830 --- __mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfffffe535ebb2830 xprt_unregister() at xprt_unregister+0x28/frame 0xfffffe535ebb2850 clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfffffe5= 35ebb2880 nfs_unmount() at nfs_unmount+0x182/frame 0xfffffe535ebb28d0 dounmount() at dounmount+0x5c1/frame 0xfffffe535ebb2950 sys_unmount() at sys_unmount+0x30f/frame 0xfffffe535ebb2a70 amd64_syscall() at amd64_syscall+0x55a/frame 0xfffffe535ebb2bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe535ebb2bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip =3D 0x800872b9a, rsp = =3D 0x7fffffffde88, rbp =3D 0x7fffffffe3c0 --- Uptime: 2h43m8s Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..= 81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/li= b/debug//boot/kernel/zfs.ko.debug...done. done. Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from= /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /usr/= lib/debug//boot/kernel/linux.ko.debug...done. done. Reading symbols from /boot/kernel/linux_common.ko...Reading symbols fro= m /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /us= r/lib/debug//boot/kernel/if_lagg.ko.debug...done. done. Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/coretemp.ko.debug...done. done. Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /usr/= lib/debug//boot/kernel/aesni.ko.debug...done. done. Reading symbols from /boot/kernel/filemon.ko...Reading symbols from /us= r/lib/debug//boot/kernel/filemon.ko.debug...done. done. Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/fuse.ko.debug...done. done. Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /usr= /lib/debug//boot/kernel/ichsmb.ko.debug...done. done. Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/= lib/debug//boot/kernel/smbus.ko.debug...done. done. Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /usr/= lib/debug//boot/kernel/ichwd.ko.debug...done. done. Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /usr= /lib/debug//boot/kernel/cpuctl.ko.debug...done. done. Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /= usr/lib/debug//boot/kernel/cryptodev.ko.debug...done. done. Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /= usr/lib/debug//boot/kernel/dtraceall.ko.debug...done. done. Reading symbols from /boot/kernel/profile.ko...Reading symbols from /us= r/lib/debug//boot/kernel/profile.ko.debug...done. done. Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr= /lib/debug//boot/kernel/dtrace.ko.debug...done. done. Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbo= ls from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done. done. Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/systrace.ko.debug...done. done. Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/li= b/debug//boot/kernel/sdt.ko.debug...done. done. Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/fasttrap.ko.debug...done. done. Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/li= b/debug//boot/kernel/fbt.ko.debug...done. done. Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /us= r/lib/debug//boot/kernel/dtnfscl.ko.debug...done. done. Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/dtmalloc.ko.debug...done. done. Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols f= ound)...done. Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/ipmi.ko.debug...done. done. Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from = /usr/lib/debug//boot/kernel/ipmi_linux.ko.debug...done. done. Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from /usr/= lib/debug//boot/kernel/hwpmc.ko.debug...done. done. Reading symbols from /boot/kernel/mfip.ko...Reading symbols from /usr/l= ib/debug//boot/kernel/mfip.ko.debug...done. done. Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/li= b/debug//boot/kernel/ums.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbol= s found)...done. Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/netgraph.ko.debug...done. done. Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /u= sr/lib/debug//boot/kernel/ng_ether.ko.debug...done. done. Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbol= s found)...done. Reading symbols from /boot/kernel/linux64.ko...Reading symbols from /us= r/lib/debug//boot/kernel/linux64.ko.debug...done. done. Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /= usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/= lib/debug//boot/kernel/tmpfs.ko.debug...done. done. __curthread () at ./machine/pcpu.h:232 232 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff80a52c15 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:386 #3 0xffffffff80a53206 in vpanic (fmt=3D, ap=3D0xfffffe5= 35ebb2500) at /usr/src/sys/kern/kern_shutdown.c:779 #4 0xffffffff80a53253 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:710 #5 0xffffffff80ecd5c2 in trap_fatal (frame=3D0xfffffe535ebb2740, eva= =3D0) at /usr/src/sys/amd64/amd64/trap.c:801 #6 0xffffffff80eccb8e in trap (frame=3D0xfffffe535ebb2740) at /usr/src/sys/amd64/amd64/trap.c:197 #7 #8 __mtx_lock_flags (c=3D0xdeadc0dedeadc0f6, opts=3D0, file=3D0xffffffff8147e721 "/usr/src/sys/rpc/svc.c", line=3D380) at /usr/src/sys/kern/kern_mutex.c:239 #9 0xffffffff80cc14b8 in xprt_unregister (xprt=3D0xfffff8022e0fce00) at /usr/src/sys/rpc/svc.c:380 #10 0xffffffff80cbc058 in clnt_reconnect_destroy (cl=3D0xfffff80146fa39= 00) at /usr/src/sys/rpc/clnt_rc.c:500 #11 0xffffffff80969972 in nfs_unmount (mp=3D, mntflags=3D) at /usr/src/sys/fs/nfsclient/nfs_clvfso= ps.c:1704 #12 0xffffffff80b0b761 in dounmount (mp=3D0xdeadc0dedeadc0f6, flags=3D1= 34217728, td=3D0xfffff8018f2eb000) at /usr/src/sys/kern/vfs_mount.c:1388 #13 0xffffffff80b0b11f in sys_unmount (td=3D0xfffff8018f2eb000, uap=3D0xfffffe535ebb2b70) at /usr/src/sys/kern/vfs_mount.c:1215 #14 0xffffffff80ecdfea in syscallenter (td=3D0xfffff8018f2eb000, sa=3D) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #15 amd64_syscall (td=3D0xfffff8018f2eb000, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:902 #16 Can't read data for section '.eh_frame' in file '/' (kgdb) vmcore / source IS available. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" From owner-freebsd-current@freebsd.org Sat Mar 18 03:21:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 681D9D1176D for ; Sat, 18 Mar 2017 03:21:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB7FA86E; Sat, 18 Mar 2017 03:21:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2I3LpNw063641 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Mar 2017 05:21:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2I3LpNw063641 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2I3LoG1063640; Sat, 18 Mar 2017 05:21:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Mar 2017 05:21:50 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Dimitry Andric , Ian Lepore , Gergely Czuczy , FreeBSD Current Subject: Re: process killed: text file modification Message-ID: <20170318032150.GW16105@kib.kiev.ua> References: <5ac94b9a-7ced-9eff-d746-7dddaaeca516@harmless.hu> <1489340839.40576.82.camel@freebsd.org> <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 03:21:57 -0000 On Fri, Mar 17, 2017 at 09:23:00PM +0000, Rick Macklem wrote: > Dimitry Andric wrote: > >On 17 Mar 2017, at 15:19, Konstantin Belousov wrote: > >> > >> On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote: > >>> Well, I don't mind adding ncl_flush(), but it shouldn't be > >>> necessary. I actually had it in the first > >>> rendition of the patch, but took it out because it should happen > >>> on the VOP_CLOSE() if any writing to the buffer cache happened > >>> and that code hasn't changed in many years. > >> Dirty pages are flushed by writes, so if we have a set of dirty pages and > >> async vm_object_page_clean() is called on the vnode' vm_object, we get > >> a bunch of delayed-write AKA dirty buffers. This is possible even after > >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving > >> vfs_msync(). > When I was talking about ncl_flush() above, I was referring to buffer cache > buffers written by a write(2) syscall, not the case of mmap'd pages. But dirty buffers can appear on the vnode queue due to dirty pages msyncing by syncer, for instance. > > >> > >> I agree that the patch would not create new dirty buffers, but it is possible > >> to get them by other means. > To write to a buffer cache block, the file would be opened by another > thread and that is what this sanity check was meant to catch. As > for dirtying pages that are mmap'd, as far as I understand it, the > NFS client has no way of knowing if this will happen more until > VOP_INACTIVE() is called on the vnode. > Syncer does not open the vnode inside the vfs_msync() operations. > To be honest, this check could easily be deleted. After all, NFS could care less if a file > is being executed (all it sees are reads and writes). Without the check, the executable > might do "interesting" things;-) > [stuff snipped] > > FWIW, Rick's patch seems to do the trick, both for my test case and lld > > itself. And even with vfs.timestamp_precision=3 on both server and > > client. > Hopefully the original reporter of the problem (Gergely ??) can test the patch as well. > I think the patch is pretty harmless, although it could be argued that setting > np->m_mtime = np->n_nattr.na_mtime (or close to that) > shouldn't happen for the case where there isn't any dirty pages found to flush. > However, once a file mmap'd we don't know when it does get modified anyhow > (as discussed above), so setting it here doesn't seem harmful to me. We do track writeability to the file, and do not allow execution if there is an active writer, be it a file descriptor opened for write, or a writeable mapping. And in reverse, if the file is executed (VV_TEXT is set), then we disallow opening the file for write. Of course, this cannot work when we execute file on one NFS client, and another client modifies the file, but then exactly this check and kill should provide some sanity. > > Thanks for testing the patch. Now, if others can test it...rick > From owner-freebsd-current@freebsd.org Sat Mar 18 03:43:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6856D10193 for ; Sat, 18 Mar 2017 03:43:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D2D4E14A4 for ; Sat, 18 Mar 2017 03:43:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: by mailman.ysv.freebsd.org (Postfix) id D2226D10192; Sat, 18 Mar 2017 03:43:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1B9ED10191 for ; Sat, 18 Mar 2017 03:43:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7783814A3; Sat, 18 Mar 2017 03:43:13 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1cp5Gj-00047D-AR; Sat, 18 Mar 2017 04:43:05 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1cp5Gj-0005tX-8L; Sat, 18 Mar 2017 04:43:05 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Sat, 18 Mar 2017 03:43:05 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" CC: "bz" Subject: Fwd: Re: info.0 dump good Date: Fri, 17 Mar 2017 20:43:05 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 03:43:14 -0000 ----- Start Forwarded Message ----- Sent: Fri, 17 Mar 2017 12:47:30 -0700 From: John Baldwin To: jbtakk@iherebuywisely.com Subject: Re: info.0 dump good On Thursday, March 16, 2017 05:32:13 AM Jeffrey Bouquet wrote: >=20 > On Wed, 15 Mar 2017 16:10:43 -0700, John Baldwin wrote: >=20 > > On Monday, March 13, 2017 06:49:05 PM Jeffrey Bouquet wrote: > > >=20 > > > On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin wr= ote: > > >=20 > > > > On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote: > > > > > Seems to happen when Xorg has a large webpage or a page idle for = a time > > > > >=20 > > > > > Dump header from device: /dev/gpt/WDswap > > > > > Architecture: i386 > > > > > Architecture Version: 2 > > > > > Dump Length: 285376512 > > > > > Blocksize: 512 > > > > > Dumptime: Mon Mar 13 12:12:37 2017 > > > > > Hostname: [redacted]com > > > > > Magic: FreeBSD Kernel Dump > > > > > Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb 9 17:= 32:03 PST 2017 > > > > > com:/usr/obj/usr/src/sys/[custom kernel] > > > > > Panic String: page fault > > > > > Dump Parity: 1127850006 > > > > > Bounds: 0 > > > > > Dump Status: good > > > > >=20 > > > > > Viable to send the bounds, info.0 and vmcore.0 to somewhere where= someone not > > > > > a comlete novice can find a bug somewhere? Unsure what email a= ttachment allows > > > > > a 273MB file, an ftp server upstream ?? No time to use kdbg for= a few months anyway... > > > >=20 > > > > Do you have a core.txt.0 file? If so it should contain a stack tra= ce from > > > > kgdb which is the first thing that would be useful to obtain. > > > >=20 > > >=20 > > > Dump header from device: /dev/gpt/WDswap > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 229535744 > > > Blocksize: 512 > > > Dumptime: Wed Mar 1 18:10:06 2017 > > > Hostname: .com > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 12.0-CURRENT #0 r313487: Mon Feb 13 16:58:5= 3 PST 2017 > > > root@ .com:/usr/obj/usr/src/sys/[custom] > > > Panic String: vm_fault: fault on nofault entry, addr: deadc000 > > > Dump Parity: 3513472583 > > > Bounds: 8 > > > Dump Status: good > > >=20 > > > Only one of the core's has a .txt. file... this is .8 but lacks the = 4th " bounds " file... > > > I just renamed them to capitallized [ the .8 that is ] for safekeepin= g. > >=20 > > So the .txt files generally have much more useful information (such as = the stack > > trace from kgdb). If you have a .txt file and it contains a stack trac= e, can > > you follow up on the list with the stack trace? > >=20 >=20 >=20 > Don't know about the .text. file,=20 Some versions of FreeBSD will generate a /var/crash/core.txt.N file alongsi= de the /var/crash/vmcore.N and /var/crash/info.N files. If you have one, it w= ill contain things like the backtrace from kgdb which are more useful than the info.N file. =20 > Command: kgdb /boot/test/kernel VMCORE.8 >=20 > some version of the output [below] from the above [core.text.8 also ? ]= =20=20 >=20 >=20 >=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > Waiting (max 60 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `bufdaemon' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop...=20 > Syncing disks, vnodes remaining... 5 1 0 0 done > All buffers synced. > lock order reversal: > 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xbfb90150 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5b9b5d4 at __lockmgr_args+0xa64 > #3 0xb5c784ad at vop_stdlock+0x4d > #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 > #5 0xb5c9c137 at _vn_lock+0xb7 > #6 0xb5c8b00a at vputx+0x16a > #7 0xb5c8286c at dounmount+0x5dc > #8 0xb5c8c8e8 at vfs_unmountall+0x68 > #9 0xb5c68333 at bufshutdown+0x3f3 > #10 0xb5bbfca7 at kern_reboot+0x1b7 > #11 0xb5bbfa88 at sys_reboot+0x3e8 > #12 0xb6155fa5 at syscall+0x3b5 > #13 0xb6140ede at Xint0x80_syscall+0x2e > lock order reversal: > 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xbfa28034 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1404 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5b9b5d4 at __lockmgr_args+0xa64 > #3 0xb5c784ad at vop_stdlock+0x4d > #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 > #5 0xb5c9c137 at _vn_lock+0xb7 > #6 0xb5eb9617 at ffs_flushfiles+0x157 > #7 0xb5e9d9aa at softdep_flushfiles+0x17a > #8 0xb5ebc04c at ffs_unmount+0x7c > #9 0xb5c8299b at dounmount+0x70b > #10 0xb5c8c8e8 at vfs_unmountall+0x68 > #11 0xb5c68333 at bufshutdown+0x3f3 > #12 0xb5bbfca7 at kern_reboot+0x1b7 > #13 0xb5bbfa88 at sys_reboot+0x3e8 > #14 0xb6155fa5 at syscall+0x3b5 > #15 0xb6140ede at Xint0x80_syscall+0x2e > lock order reversal: > 1st 0xbf69ab4c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277 > 2nd 0xb6b6f8b0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:3104 > stack backtrace: > #0 0xb5c22421 at witness_debugger+0x81 > #1 0xb5c22342 at witness_checkorder+0xd12 > #2 0xb5bc976a at _sx_slock+0x5a > #3 0xb5b743f1 at mountcheckdirs+0x41 > #4 0xb5c828ea at dounmount+0x65a > #5 0xb5c8c93b at vfs_unmountall+0xbb > #6 0xb5c68333 at bufshutdown+0x3f3 > #7 0xb5bbfca7 at kern_reboot+0x1b7 > #8 0xb5bbfa88 at sys_reboot+0x3e8 > #9 0xb6155fa5 at syscall+0x3b5 > #10 0xb6140ede at Xint0x80_syscall+0x2e These messages are not as interesting. > Uptime: 3h49m18s > GEOM_SCHED: Modevent 2. > uhub11: detached > uhub9: detached > uhub10: detached > ums0: detached > <5>ue0: link state changed to DOWN > <5>Accounting disabled > panic: vm_fault: fault on nofault entry, addr: deadc000 > cpuid =3D 2 > KDB: stack backtrace: > db_trace_self_wrapper(b632dee0,b65ec9b0,0,b63057cc,20c,...) at db_trace_s= elf_wrapper+0x2a/frame 0xeaa10428 > kdb_backtrace(b653d063,2,b6378ae5,eaa104e4,fb,...) at kdb_backtrace+0x2d/= frame 0xeaa10490 > vpanic(b6378ae5,eaa104e4,eaa104e4,eaa105c0,b5edffb1,...) at vpanic+0x115/= frame 0xeaa104c4 > panic(b6378ae5,deadc000,1,eaa1052c,eaa1051c,...) at panic+0x1b/frame 0xea= a104d8 > vm_fault_hold(b8172000,deadc000,1,0,0,...) at vm_fault_hold+0x2051/frame = 0xeaa105c0 > vm_fault(b8172000,deadc000,1,0,c2d0bfa8,...) at vm_fault+0x88/frame 0xeaa= 105e8 > trap_pfault(deadc348,b6ae70ec,b6600504,bdda8d00,b6ae70f0,...) at trap_pfa= ult+0x116/frame 0xeaa10630 > trap(eaa10778) at trap+0x2d6/frame 0xeaa1076c > calltrap() at calltrap+0x6/frame 0xeaa1076c > --- trap 0xc, eip =3D 0xb5bbaf19, esp =3D 0xeaa107b8, ebp =3D 0xeaa10828 = --- > __rw_wlock_hard(c2d42ab4,deadc0de,be269000,b63585e2,139,...) at __rw_wloc= k_hard+0xe9/frame 0xeaa10828 > _rw_wlock_cookie(c2d42ab4,b63585e2,139,136,0,...) at _rw_wlock_cookie+0xd= 8/frame 0xeaa10858 > ip_output(c3acf400,0,0,0,0,...) at ip_output+0x4aa/frame 0xeaa10934 > check_dyn_rules(1,1,b632a786,eaa109c8,b5bce8a2,...) at check_dyn_rules+0x= 6a8/frame 0xeaa10994 > ipfw_dyn_tick(0,0,b632a786,2b1,eaa10a00,...) at ipfw_dyn_tick+0x55/frame = 0xeaa109c8 > softclock_call_cc(0,0,b632a786,360,0,...) at softclock_call_cc+0x17c/fram= e 0xeaa10a68 > softclock(b6b6fa80,9,0,560,be2d4048,...) at softclock+0x40/frame 0xeaa10a= 88 > intr_event_execute_handlers(b6aa7e10,be2d4000,b6320f1d,560,b6320b58,...) = at intr_event_execute_handlers+0x8e/frame 0xeaa10ab0 > ithread_loop(be2d7000,eaa10b28,b6320b58,406,0,...) at ithread_loop+0x90/f= rame 0xeaa10aec > fork_exit(b5b8a3c0,be2d7000,eaa10b28) at fork_exit+0x7e/frame 0xeaa10b14 > fork_trampoline() at fork_trampoline+0x8/frame 0xeaa10b14 > --- trap 0, eip =3D 0, esp =3D 0xeaa10b60, ebp =3D 0 --- > KDB: enter: panic This is the source of the panic, and it appears to be that the lock in question has been destroyed during shutdown but network packets are still being received. Please reply to the list with this kgdb output, and perhaps add 'bz@FreeBSD.org' to the list as he might know about when the associated lock is destroyed. > Reading symbols from /boot/test/geom_journal.ko...Reading symbols from /u= sr/lib/debug//boot/test/geom_journal.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_journal.ko > Reading symbols from /boot/test/geom_label.ko...Reading symbols from /usr= /lib/debug//boot/test/geom_label.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_label.ko > Reading symbols from /boot/modules/nvidia-modeset.ko...done. > Loaded symbols for /boot/modules/nvidia-modeset.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/test/ehci.ko...Reading symbols from /usr/lib/d= ebug//boot/test/ehci.ko.debug...done. > done. > Loaded symbols for /boot/test/ehci.ko > Reading symbols from /boot/test/geom_sched.ko...Reading symbols from /usr= /lib/debug//boot/test/geom_sched.ko.debug...done. > done. > Loaded symbols for /boot/test/geom_sched.ko > Reading symbols from /boot/test/gsched_rr.ko...Reading symbols from /usr/= lib/debug//boot/test/gsched_rr.ko.debug...done. > done. > Loaded symbols for /boot/test/gsched_rr.ko > Reading symbols from /boot/test/pf.ko...Reading symbols from /usr/lib/deb= ug//boot/test/pf.ko.debug...done. > done. > Loaded symbols for /boot/test/pf.ko > Reading symbols from /boot/test/snd_csa.ko...Reading symbols from /usr/li= b/debug//boot/test/snd_csa.ko.debug...done. > done. > Loaded symbols for /boot/test/snd_csa.ko > #0 doadump (textdump=3D0) at pcpu.h:225 > 225 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=3D0) at pcpu.h:225 > #1 0xb555a40e in db_dump (dummy=3D-1245695404, dummy2=3DUnhandled dwarf = expression opcode 0x9d > ) > at /usr/src/sys/ddb/db_command.c:546 > #2 0xb555a1fa in db_command (cmd_table=3D) > at /usr/src/sys/ddb/db_command.c:453 > #3 0xb5559f50 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 > #4 0xb555cdfa in db_trap (type=3D,=20 > code=3D) at /usr/src/sys/ddb/db_main.c:248 > #5 0xb5c03997 in kdb_trap (tf=3D) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xb615530f in trap (frame=3D) > at /usr/src/sys/i386/i386/trap.c:683 > #7 0xb6140e2a in calltrap () at /usr/src/sys/i386/i386/exception.s:171 > #8 0xb5c03254 in kdb_enter (why=3D0xb6328738 "panic", msg=3D) > at /usr/src/sys/kern/subr_kdb.c:444 > #9 0xb5bc03f2 in vpanic (fmt=3D, ap=3D) > at /usr/src/sys/kern/kern_shutdown.c:772 > #10 0xb5bc042b in panic ( > fmt=3D0xb6378ae5 "vm_fault: fault on nofault entry, addr: %lx") > at /usr/src/sys/kern/kern_shutdown.c:710 > #11 0xb5edffb1 in vm_fault_hold (vaddr=3D,=20 > fault_type=3D, fault_flags=3D) > at /usr/src/sys/vm/vm_fault.c:531 > ---Type to continue, or q to quit---=20 > #12 0xb5eddf28 in vm_fault (map=3D0xb8172000, vaddr=3D,=20 > fault_type=3D, fault_flags=3D) > at /usr/src/sys/vm/vm_fault.c:474 > #13 0xb61558c6 in trap_pfault (frame=3D0xeaa10778,=20 > usermode=3D, eva=3D) > at /usr/src/sys/i386/i386/trap.c:868 > #14 0xb6154d06 in trap (frame=3D) > at /usr/src/sys/i386/i386/trap.c:512 > #15 0xb6140e2a in calltrap () at /usr/src/sys/i386/i386/exception.s:171 > #16 0xb5bbaf19 in __rw_wlock_hard (c=3D,=20 > v=3D, file=3D0x0, line=3D0) > at /usr/src/sys/kern/kern_rwlock.c:891 > #17 0xb5bbada8 in _rw_wlock_cookie (c=3D,=20 > file=3D, line=3D) > at /usr/src/sys/kern/kern_rwlock.c:285 > #18 0xb5d5303a in ip_output (m=3D,=20 > opt=3D, ro=3D,=20 > imo=3D, inp=3D) > at /usr/src/sys/netinet/ip_output.c:313 > #19 0xb5e32028 in check_dyn_rules (chain=3D0xb6b75068, rt=3D,=20 > timer=3D) > at /usr/src/sys/netpfil/ipfw/ip_fw_dynamic.c:1522 > #20 0xb5e32a45 in ipfw_dyn_tick (vnetx=3D0x0) > ---Type to continue, or q to quit--- > at /usr/src/sys/netpfil/ipfw/ip_fw_dynamic.c:1224 > #21 0xb5bd81bc in softclock_call_cc (c=3D,=20 > cc=3D, direct=3D) > at /usr/src/sys/kern/kern_timeout.c:729 > #22 0xb5bd86c0 in softclock (arg=3D) > at /usr/src/sys/kern/kern_timeout.c:867 > #23 0xb5b89e6e in intr_event_execute_handlers (p=3D0xb6aa7e10,=20 > ie=3D) at /usr/src/sys/kern/kern_intr.c:1262 > #24 0xb5b8a450 in ithread_loop (arg=3D) > at /usr/src/sys/kern/kern_intr.c:1275 > #25 0xb5b8767e in fork_exit (callout=3D0xb5b8a3c0 ) > at /usr/src/sys/kern/kern_fork.c:1038 > #26 0xb6140ef0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.= s:286 > Current language: auto; currently minimal > (kgdb) quit >=20 > Command exit status: 0 > Script done on Thu Mar 16 05:28:57 2017 >=20 >=20 --=20 John Baldwin ----- End Forwarded Message ----- Forwarded to the list as requested.=20=20= From owner-freebsd-current@freebsd.org Sat Mar 18 03:52:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D7F2D10758 for ; Sat, 18 Mar 2017 03:52:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0E31C9D; Sat, 18 Mar 2017 03:52:27 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id p5PecLh46cWiHp5Pfcexzh; Fri, 17 Mar 2017 21:52:20 -0600 X-Authority-Analysis: v=2.2 cv=JLBLi4Cb c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=8nJEP1OIZ-IA:10 a=6Iz7jQTuP9IA:10 a=6I5d2MoRAAAA:8 a=85N1-lAfAAAA:8 a=YxBL1-UpAAAA:8 a=lIQFjzKYggohrT3dAzkA:9 a=uv2THEdqtlk0MrbB:21 a=2JB-jUObIajtU_Ea:21 a=wPNLvfGTeEIA:10 a=IjZwj45LgO3ly-622nXo:22 a=cyfSibbquD4hpIoiQNSb:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 107707F2; Fri, 17 Mar 2017 20:52:18 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2I3qC1W090879; Fri, 17 Mar 2017 20:52:12 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703180352.v2I3qC1W090879@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: Don Lewis , ohartmann@walstatt.org, Cy.Schubert@komquats.com, freebsd-current@freebsd.org Subject: Re: ntpd dies nightly on a server with jails In-Reply-To: Message from Ian Lepore of "Fri, 17 Mar 2017 14:33:13 -0600." <1489782793.40576.185.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 17 Mar 2017 20:52:12 -0700 X-CMAE-Envelope: MS4wfBzripGNpLAR+JYXCcjeYW3mao5Dso8Vi/1wSQOxFRX4hZAJZXdwwmeJnjlB4XAoVdYiUfSU3oE91nosmKl6HCYb7HMtRKf1US8Z5Z9B8Svvp58dLZxG JzTBLa/c4wyr05N/t/9CHXNT3wm03UBT/G7vQP02xSNVNdgEy7SuOJQHCnx0CvKtfzHlraD6rAHezRfRxxBR0iggVoZ5oC3fRww+VXozX5zweo6HnZqxVwPH Tafflfg6Wju6fTuCKvHmK8M/0t1PhwL1dqVoOjttK4A= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 03:52:28 -0000 In message <1489782793.40576.185.camel@freebsd.org>, Ian Lepore writes: > On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote: > > On 17 Mar, O. Hartmann wrote: > > > > > > > > Just some strange news: > > > > > > I left the server the whole day with ntpd disabled and I didn't > > > watch > > > a gain of the RTC by one second, even stressing the machine. > > > > > > But soon after restarting ntpd, I realised immediately a 30 minutes > > > off! This morning, the discrapancy was almost 5 hours - it looked > > > more > > > like a weird ajustment to another time base than UTC. > > > > > > Over the weekend I'll leave the server with ntpd disabled and only > > > RTC > > > running. I've the strange feeling that something is intentionally > > > readjusting the ntpd time due to a misconfiguration or a rogue ntp > > > server in the X.CC.pool.ntp.org > > A ntp should recognize a single bad server and ignore it in favor of  > > the other servers that are sane. > > > > It sounds like something is going off the rails once ntpd starts > > calling > > adjtime().  What is the output of: > > sysctl kern.clockrate > > > > I'd suggest starting ntpd and running "ntpq -c pe" a few times a > > minute > > and capturing its output to monitor the status of ntpd as it starts > > up > > and try to capture things going wrong.   You should probably disable > > iburst in ntp.conf to give more visibility in the early startup. > > > > For the first few minutes ntpd should just be getting reliable > > timestamp > > info and won't start trying to adjust the clock until it has captured > > endough samples and figured out which servers are best.  Then the > > behaviour of the offset is the thing to watch.  If the iniital offset > > is > > large enough, ntpd will step the clock once to get it close to zero, > > otherwise it will just use adjtime to slowy push the offset towards > > zero.  I think though that you will see the offset start gyrating > > madly. > > > > You might want to set /var/db/ntpd.drift to zero beforehand if there > > is > > an insane value in there.  If the initial drift value is bogus, will > > try > > to use it which will push the time offset away from zero so fast that > > it > > will decide to keep stepping the clock back to zero before it can > > capture enough samples from the external servers to determine the > > true > > local clock drift rate. > > Do not set ntpd.drift contents to zero.  Delete the file.  There's a > huge difference between a file that says the clock is perfect and a > missing file which triggers ntpd to do a 15-minute frequency > measurement to come up with the initial drift correction. Yes. And, without debugging output and/or a dump, I don't think we'll be any closer to the truth. Until then the best we can do is make educated guesses. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sat Mar 18 13:26:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16224D12C7F for ; Sat, 18 Mar 2017 13:26:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 BF5251790 for ; Sat, 18 Mar 2017 13:26:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30928 invoked from network); 18 Mar 2017 13:26:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Mar 2017 13:26:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sat, 18 Mar 2017 09:26:50 -0400 (EDT) Received: (qmail 28762 invoked from network); 18 Mar 2017 13:26:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Mar 2017 13:26:49 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 274FEEC805D; Sat, 18 Mar 2017 06:26:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> Date: Sat, 18 Mar 2017 06:26:48 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <826D525A-BDAF-4352-AD9F-A238B797BFAF@dsl-only.net> References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> <201703160607.v2G67Vwe023153@sdf.org> <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 13:26:58 -0000 [Summary: I've now tested on a rpi3 in addition to a pine64+ 2GB. Both contexts show the problem.] On 2017-Mar-16, at 2:07 AM, Mark Millard wrote: > On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote: >=20 >> Mark Millard wrote: >>=20 >>> [Something strange happened to the automatic CC: fill-in for my = original >>> reply. Also I should have mentioned that for my test program if a >>> variant is made that does not fork the swapping works fine.] >>>=20 >>> On 2017-Mar-15, at 9:37 AM, Mark Millard = wrote: >>>=20 >>>> On 2017-Mar-15, at 6:15 AM, Scott Bennett = wrote: >>>>=20 >>>>> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >>>>> wrote: >>>>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>>>>=20 >>>>>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>>>>> [test_check() between the fork and the wait/sleep prevents the >>>>>>>> failure from occurring. Even a small access to the memory at >>>>>>>> that stage prevents the failure. Details follow.] >>>>>>>=20 >>>>>>> Maybe a stupid question, since you might have written it = somewhere. >>>>>>> What medium do you swap to? >>>>>>> I've seen broken firmware on microSD cards doing silent data >>>>>>> corruption for some access patterns. >>>>>>=20 >>>>>> The root filesystem is on a USB SSD on a powered hub. >>>>>>=20 >>>>>> Only the kernel is from the microSD card. >>>>>>=20 >>>>>> I have several examples of the USB SSD model and have >>>>>> never observed such problems in any other context. >>>>>>=20 >>>>>> [remainder of irrelevant material deleted --SB] >>>>>=20 >>>>> You gave a very long-winded non-answer to Bernd's question, so = I'll >>>>> repeat it here. What medium do you swap to? >>>>=20 >>>> My wording of: >>>>=20 >>>> The root filesystem is on a USB SSD on a powered hub. >>>>=20 >>>> was definitely poor. It should have explicitly mentioned the >>>> swap partition too: >>>>=20 >>>> The root filesystem and swap partition are both on the same >>>> USB SSD on a powered hub. >>>>=20 >>>> More detail from dmesg -a for usb: >>>>=20 >>>> usbus0: 12Mbps Full Speed USB v1.0 >>>> usbus1: 480Mbps High Speed USB v2.0 >>>> usbus2: 12Mbps Full Speed USB v1.0 >>>> usbus3: 480Mbps High Speed USB v2.0 >>>> ugen0.1: at usbus0 >>>> uhub0: on = usbus0 >>>> ugen1.1: at usbus1 >>>> uhub1: = on usbus1 >>>> ugen2.1: at usbus2 >>>> uhub2: on = usbus2 >>>> ugen3.1: at usbus3 >>>> uhub3: = on usbus3 >>>> . . . >>>> uhub0: 1 port with 1 removable, self powered >>>> uhub2: 1 port with 1 removable, self powered >>>> uhub1: 1 port with 1 removable, self powered >>>> uhub3: 1 port with 1 removable, self powered >>>> ugen3.2: at usbus3 >>>> uhub4 on uhub3 >>>> uhub4: = on usbus3 >>>> uhub4: MTT enabled >>>> uhub4: 4 ports with 4 removable, self powered >>>> ugen3.3: at usbus3 >>>> umass0 on uhub4 >>>> umass0: on = usbus3 >>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>> umass0:0:0: Attached to scbus0 >>>> . . . >>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>> da0: Fixed Direct Access SPC-4 SCSI device >>>> da0: Serial Number >>>> da0: 40.000MB/s transfers >>>>=20 >>>> (Edited a bit because there is other material interlaced, even >>>> internal to some lines. Also: I removed the serial number of the >>>> specific example device.) >>=20 >> Thank you. That presents a much clearer picture. >>>>=20 >>>>> I will further note that any kind of USB device cannot = automatically >>>>> be trusted to behave properly. USB devices are notorious, for = example, >>>>>=20 >>>>> [reasons why deleted --SB] >>>>>=20 >>>>> You should identify where you page/swap to and then try = substituting >>>>> a different device for that function as a test to eliminate the = possibility >>>>> of a bad storage device/controller. If the problem still occurs, = that >>>>> means there still remains the possibility that another controller = or its >>>>> firmware is defective instead. It could be a kernel bug, it is = true, but >>>>> making sure there is no hardware or firmware error occurring is = important, >>>>> and as I say, USB devices should always be considered suspect = unless and >>>>> until proven innocent. >>>>=20 >>>> [FYI: This is a ufs context, not a zfs one.] >>=20 >> Right. It's only a Pi, after all. :-) >=20 > It is a Pine64+ 2GB, not an rpi3. >=20 >>>>=20 >>>> I'm aware of such things. There is no evidence that has resulted = in >>>> suggesting the USB devices that I can replace are a problem. = Otherwise >>>> I'd not be going down this path. I only have access to the one = arm64 >>>> device (a Pine64+ 2GB) so I've no ability to substitution-test what >>>> is on that board. >>=20 >> There isn't even one open port on that hub that you could plug a >> flash drive into temporarily to be the paging device? >=20 > Why do you think that I've never tried alternative devices? It > is just that the result was no evidence that my usually-in-use > SSD is having a special/local problem: the behavior continues > across all such contexts when the Pine64+ 2GB is involved. (Again > I have not had access to an alternate to the one arm64 board. > That limits my substitution testing possibilities.) >=20 > Why would you expect a Flash drive to be better than another SSD > for such testing? (The SSD that I usually use even happens to be > a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So > is the hub that I usually use for that matter.) FYI: I now have access to a rpi3 in addition to a pine64+ 2GB. I've tested on the rpi3 using a different USB hub and a different SSD: no hardware device in common with the recent Pine64+ 2GB tests (other than console cabling and what handles the serial console). The fork-then-swap-out-then-swap-in failure happens in the rpi3 context as well. Because the rpi3 has only 1 GiByte of RAM the stress commands that I used were more like: stress -m 1 --vm-bytes 1000M to get zero RES(ident memory) for the two processes from my test program after it forks while they are waiting/sleeping. >> You could then >> try your tests before returning to the normal configuration. If = there >> isn't an open port, then how about plugging a second hub into one of >> the first hub's ports and moving the displaced device to the second >> hub? A flash drive could then be plugged in. That kind of = configuration >> is obviously a bad idea for the long run, but just to try your tests = it >> ought to work well enough. >=20 > I have access to more SSDs that I can use than I do to Flash drives. I > see no reason to specifically use a Flash drive. >=20 >> (BTW, if a USB storage device containing a >> paging area drops off=3Dline even momentarily and the system needs to = use >> it, that is the beginning of the end, even though it may take up to a = few >> minutes for everything to lock up. >=20 > The system does not lock up, even days or weeks later, with having = done > dozens of experiments that show memory corruption failures over those > days. The only processes showing memory corruption so far are those > that were the parent or child for a fork that were later swapped out > to have zero RES(ident memory) and then even later swapped back in. >=20 > The context has no such issues. You are inventing problems that do > not exist in my context. That is why none of my list submittals > mention such problems: they did not occur. >=20 >> You probably won't be able to do an >> orderly shutdown, but will instead have to crash it with the power = switch. >> In the case of something like a Pi, this is an unpleasant fact of = life, >> to be sure.) >=20 > Such things did not occur and has nothing to do with my context so = far. >=20 >> I think I buy your arguments, given the evidence you've collected >> thus far, including what you've added below. I just like to = eliminate >> possibilities that are much simpler to deal with before facing = nastinesses >> like bugs in the VM subsystem. :-) >=20 > When I started this I found no evidence of device-specific problems. > My investigation activity goes back to long before my list submittals. >=20 > And I repeat: Other people have reported the symptoms that started > this investigation. They did so before I ever started my activities. > They were using none of the specific devices that I have access to. > Likely the types of devices were frequently even different, such as > a rpi3 instead of a Pine64+ 2GB or a different USB drive. I was able > to get the symptoms that they reported. >=20 >>>> It would be neat if some folks used my code to test other arm64 >>>> contexts and reported the results. I'd be very interested. >>>> (This is easier to do on devices that do not have massive >>>> amounts of RAM, which may limit the range of devices or >>>> device configurations that are reasonable to test.) >>>>=20 >>>> There is that other people using other devices have reported >>>> the behavior that started this investigation. I can produce the >>>> behavior that they reported, although I've not seen anyone else >>>> listing specific steps that lead to the problem or ways to tell >>>> if the symptom is going to happen before it actually does. Nor >>>> have I seen any other core dump analysis. (I have bugzilla >>>> submittals 217138 and 217239 tied to symptoms others have >>>> reported as well as this test program material.) >>>>=20 >>>> Also, considering that for my test program I can control which = pages >>>> get the zeroed-problem by read-accessing even one byte of any 4K >>>> Byte page that I want to make work normally, doing so in the child >>>> process of the fork, between the fork and the sleep/swap-out, it = does >>>> not suggest USB-device-specific behavior. The read-access is = changing >>>> the status of the page in some way as far as I can tell. >>>>=20 >>>> (Such read-accesses in the parent process make no difference to the >>>> behavior.) >>>=20 >>> I should have noted another comparison/contrast between >>> having memory corruption and not in my context: >>>=20 >>> I've tried variants of my test program that do not fork but >>> just sleep for 60s to allow me to force the swap-out. I >>> did this before adding fork and before using >>> parital_test_check, for example. I gradually added things >>> apparently involved in the reports others had made >>> until I found a combination that produced a memory >>> corruption test failure. >>>=20 >>> These tests without fork involved find no problems with >>> the memory content after the swap-in. >>>=20 >>> For my test program it appears that fork-before-swap-out >>> or the like is essential to having the problem occur. >>>=20 >> A comment about terminology seems in order here. It bothers >> me considerably to see you writing "swap out" or "swapping" where >> it seems like you mean to write "page out" or "paging". A BSD >> system whose swapping mechanism gets activated has already waded >> very deeply into the quicksand and frequently cannot be gotten out >> in a reasonable amount of time even with manual assistance. It is >> often quicker to crash it, reboot, and wait for the fsck(8) cleanups >> to complete. Orderly shutdowns, even of the kind that results from >> a quick poke to the power button, typically get mired in the same >> mess that already has the system in knots. Also, BSD systems since >> 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, >> just out. A swapped out process, once the system determines that it >> has adequate resources again to attempt to run the process, will have >> the interrupted text page paged in and the rest will be paged in by >> the normal mechanism of page faults and page-in operations. I assume >> you must already know all this, which is a large part of why it = grates >> on me that you appear to be using the wrong terms. >=20 > You apparently did not read any of the material about how the test > is done or are unfamiliar with what "stress -m 1 --vm-bytes 1800M" > does when there is only 2GB of RAM. I am deliberately inducing > swapping in other processes, including the 2 from my test program > (after the fork), not just paging. (stress is a port, not part of > the base system.) >=20 > When I say swap-out and swap-in I mean it. >=20 > =46rom the source code of my test program: >=20 > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. I watch with top -PCwaopid . >=20 > That type of stress run uses about 1.8 GiBytes after a bit, > which is enough to cause the swapping of other processes, > including the two that I am testing (post-fork). (Some RAM > is in use already before the stress run, which explains not > needing 2 GiBytes to be in use by stress.) >=20 > Look at a "top -PCwaopid" display: there are columns for > RES(ident memory) and SWAP. I cause my 2 test processes to > show zero RES and everything under SWAP, starting sometime > during the 60s sleep/wait. >=20 > Why would I cause swapping? Because buildworld causes such > swap-outs at times when there is only 2GBytes of RAM, > including processes that forked earlier, and as a result > the corrupted memory problems show up later in some processes > that were swapped out at the time. The build eventually > stops for process failures tied to the corruptions of memory > in the failing processes. (At least that is what my testing > strongly suggests.) >=20 > But that is a very complicated context to use for analysis or > testing of the problem. My test program is vastly simpler > and easier/quicker to set up and test when used with stress > as well. Such was the kind of thing I was trying to find. >=20 > I want the Pine64+ 2GB to work well enough to be able to have > buildworld (-j 4) complete correctly without having to restart > the build --even when everything has to be rebuilt. So I'm > trying to find and provide enough evidence to help someone fix > the problems that are observed to block such buildworld > activity. >=20 > Again: others have reported such arm64 problems on the lists > before I ever got into this activity. The evidence is that > the issues are not a local property of my environment. >=20 > Swapping is supposed to work. I can do buildworld (-j 4) > on armv6 (really -mcpu=3Dcortex-a7 so armv7-a) and the > swapping it causes works fine. This is true for both a > bpim3 (2 GiBytes of RAM) and a rpi2 (1 GiByte of RAM > so even more swapping). On a powerpc64 with 16 GiBytes > I've built things that caused 26 GiBytes of swap to be > in use some of the time (during 4 ld's running in > parallel), with lots of processes having zero for > RES(ident memory) and all their space listed under SWAP > in a "top -PCwaopid" display. This too has no problems > with swapping of previously forked processes (or of any > other processes). >=20 > For the likes of a Pine64+ 2GB to be "self hosted"=20 > for source-code based updates, swapping of previously > forked processes must work and currently such > swapping is unreliable. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Mar 18 13:45:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C334CD10A27 for ; Sat, 18 Mar 2017 13:45:35 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [104.225.8.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freebsd-11-64", Issuer "freebsd-11-64" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EF78173C for ; Sat, 18 Mar 2017 13:45:35 +0000 (UTC) (envelope-from andy@neu.net) Received: from neu.net (neu.net [104.225.8.138]) by mail.neu.net (8.15.2/8.15.2) with ESMTPS id v2IDjWiY060878 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 18 Mar 2017 09:45:32 -0400 (EDT) (envelope-from andy@neu.net) Date: Sat, 18 Mar 2017 09:45:31 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Subject: DHCP/network issues Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 13:45:35 -0000 Is anyone seeing network or DHCP issues with a recent update to 12-current? On new hardware Dual Core Celeron J1800 Bay Trail 2.4GHz, 2MB L2 Cache 2 Gigabit Ethernet Intel NIC ports I'm seeing the following issues: - install latest 12-current snapshot FreeBSD-12.0-CURRENT-amd64-20170316-r315413-memstick.img, try DHCP during install and it fails. Setup networking manually and try to ping default gateway results in the response ping: sendto: Host is down - install 11-stable snapshot, try DHCP IPv4 during install works perfectly. After reboot DHCP works. Then I did svnlite up to current, buildworld/install cycle and DHCP fails again on current. I tried the whole process twice just to be sure, same result. From owner-freebsd-current@freebsd.org Sat Mar 18 14:20:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2871D125E5 for ; Sat, 18 Mar 2017 14:20:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4136F18B2 for ; Sat, 18 Mar 2017 14:20:39 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.165.184]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMCSP-1cq6Ib2lcz-00809P; Sat, 18 Mar 2017 15:20:20 +0100 Date: Sat, 18 Mar 2017 15:20:13 +0100 From: "O. Hartmann" To: AN Cc: freebsd-current@freebsd.org Subject: Re: DHCP/network issues Message-ID: <20170318152013.761c4999@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/TJp/oQ8Eu=_fia964o=M1J7"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:56WJgjHZLH56P0x3YHbjo0N3ua2RIdB22SaupqQtCOosoFOuken xlTGJ4CzOgoMe4XCOVQsFTyXJymUh5a2qgIuXnv+wkb8SDprypIxDUKhV7O4UX7dYNabrZu ODULfEiQKf5aN5+95ztPm3QDtF5SLYM1udVWKn7XyIfrI1QbMprap6Edj73ZehfTYSCgyDI 6tuPBo5tU8zc25vTY7Upg== X-UI-Out-Filterresults: notjunk:1;V01:K0:NlyTtBPiSfU=:LREoilGTKypKwFAdO+zdEe rXNS/ecXFwVsNKvdloIBY2G8ddYlEIUk/nTbtf0pRTa0NF3q108H/irjfToJ6DhU+suEkeKIM CiguFVLb5o19O4IZ8mzhvq74JWei77IHCU04DUxpQveHNRptV24hsFNVoWXIlYlDJjhMfIFHR gJR8jlafpVKn5UEcScACyE+ALHsjVuyeWul8iB7gvC59NtfeEMfCADgmAstm/irRcgoACCN1U 6TCdCwtYemx9svqmvDLGe+QcV9+OV6U+mqBmzkBGfwt1M/7dWN0s9RkMCBNvCzfFyPbRuGWxa gh4K4mJX3vHWy+SvqP5rdNkRINJ2aIWKNwv3LAx4LDqoOx1PJcGdRPGSiRc5BjN/QRzKZPBuZ awX/myzfXJSZyQYzHZCnhWXNvTQt2YLrMe23UGfpa/z29lIfK5itUnskroTgZIYbaiPeMq2QE +z8AeTZrUTI8Tu9LYl3Zc3B1lyg67x9QvLhq9lmsIL4xQpU/VRNmBcSvhfB+XgPpgyZXH4thQ c5temLVQW3ls+WpZW0XBUTIDz7SHF28nbGV1Yc3FP3rlrrhGJqQw8SCCSHyXWe4EYMnQ4cX9o +5Y0H4dkGmWSzBK3oc6Lkw32qBAr5Un4i8/JPf+udv1r5cQnfshgjplO9ZDpnE4z3ktvbPq9j V9gSpt53qToW+zsCYKcHrCUgvxmL85NxNufhuVCgdTBxxMDaTqCW+5CjnWuFNIoZIhKYylTu5 OntIdgl6YATWK3sZPPDx5IDCRa1hQIamDNtzqsjs6Ug/EJo4PhX3j5A+VmU= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:20:41 -0000 --Sig_/TJp/oQ8Eu=_fia964o=M1J7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 18 Mar 2017 09:45:31 -0400 (EDT) AN schrieb: > Is anyone seeing network or DHCP issues with a recent update to=20 > 12-current? >=20 > On new hardware > Dual Core Celeron J1800 Bay Trail 2.4GHz, 2MB L2 Cache > 2 Gigabit Ethernet Intel NIC ports >=20 > I'm seeing the following issues: >=20 > - install latest 12-current snapshot=20 > FreeBSD-12.0-CURRENT-amd64-20170316-r315413-memstick.img, try DHCP during= =20 > install and it fails. Setup networking manually and try to ping default = gateway > results in the response > ping: sendto: Host is down Yes. Since IFLIB has been introduced, Intel NICs seem to be suffering from = not working properly anymore. i217-LM, i350 and sibblings are affected for which I can = speak because we suffer the same problems here. Even if the NIC works, it dies after some= time under heavy I/O. >=20 > - install 11-stable snapshot, try DHCP IPv4 during install works=20 > perfectly. After reboot DHCP works. >=20 > Then I did svnlite up to current, buildworld/install cycle and DHCP fails= =20 > again on current. I tried the whole process twice just to be sure, same= =20 > result. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/TJp/oQ8Eu=_fia964o=M1J7 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWM1CHQAKCRDS528fyFhY lLs+Af9IN+80zZSAv061c1wH17DYH8Kyiq2TA+4PpKlpfNqJZ+c5jZR8f9DWTG3G MltxEtT3vEncie8POk0+P5hBnwanAf9zOd9jgVof6nWsbnEyWfFBgk2qbBv2GuqI NQ+Ar9VESTMtXEBIpG1ffUDWNELq11p5Du+MyG7KNIDV1+sYlKEO =PH6M -----END PGP SIGNATURE----- --Sig_/TJp/oQ8Eu=_fia964o=M1J7--