From owner-freebsd-stable@freebsd.org Sun Feb 14 00:21:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA4ACAA05D0 for ; Sun, 14 Feb 2016 00:21:01 +0000 (UTC) (envelope-from lausts@laus.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by mx1.freebsd.org (Postfix) with ESMTP id 68B861D99 for ; Sun, 14 Feb 2016 00:21:00 +0000 (UTC) (envelope-from lausts@laus.org) Received: from [173.88.10.122] ([173.88.10.122:25668] helo=mail.laus.org) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id CC/10-16067-328CFB65; Sun, 14 Feb 2016 00:19:48 +0000 Received: from mail.laus.org (localhost [127.0.0.1]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id u1E0Jksu099431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 13 Feb 2016 19:19:46 -0500 (EST) (envelope-from lausts@laus.org) Received: (from lausts@localhost) by mail.laus.org (8.15.2/8.15.2/Submit) id u1E0JkAD099430 for freebsd-stable@freebsd.org; Sat, 13 Feb 2016 19:19:46 -0500 (EST) (envelope-from lausts) Date: Sat, 13 Feb 2016 19:19:46 -0500 From: Thomas Laus To: freebsd-stable@freebsd.org Subject: UEFI + ZFS i5 Dmesg Message-ID: <20160214001946.GA99421@mail.laus.org> Reply-To: lausts@acm.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.2-RELEASE-p12 on an amd64 User-Agent: Mutt/1.5.24 (2015-08-30) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 00:21:01 -0000 It looks like my reply to the verbose dmesg.boot did not make it to the list. I was able to boot the PC from a MSDOS 6.22 floppy using a USB floppy drive. I also can load OpenBSD 5.8 on this PC and it boots normally. My verbose dmesg.boot: Table 'FACP' at 0xbf24f4b8 Table 'APIC' at 0xbf24f5c8 APIC: Found table at 0xbf24f5c8 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 4: enabled SMP: Added CPU 6 (AP) Copyright (c) 1992-2016 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 11.0-CURRENT #0 r295345: Sat Feb 6 08:40:13 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. PPIM 0: PA=0xa0000, VA=0xffffffff82610000, size=0x10000, mode=0 VT(vga): resolution 640x480 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8242b000. Preloaded /boot/entropy "/boot/entropy" at 0xffffffff8242be48. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff8242be98. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff8242c680. Calibrating TSC clock ... TSC clock: 3192150826 Hz CPU: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (3192.15-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbb XSAVE Features=0xf VT-x: Basic Features=0xda0400 Pin-Based Controls=0x7f Primary Processor Controls=0xfff9fffe Secondary Processor Controls=0x1f7cff Exit Controls=0xda0400 Entry Controls=0xda0400 EPT Features=0x6334141 VPID Features=0xf01 TSC: P-state invariant, performance statistics Data TLB: 1 GByte pages, 4-way set associative, 4 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M pages, fully associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 128 entries 64-Byte prefetching Shared 2nd-Level TLB: 4 KByte /2 MByte pages, 6-way associative, 1536 entries. Also 1GBbyte pages, 4-way, 16 entries L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000098fff, 561152 bytes (137 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000002470000 - 0x00000000b8951fff, 3058573312 bytes (746722 pages) 0x00000000b897d000 - 0x00000000b8a21fff, 675840 bytes (165 pages) 0x00000000b90a3000 - 0x00000000bdb1bfff, 78090240 bytes (19065 pages) 0x00000000bffff000 - 0x00000000bfffffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x000000041f619fff, 13411393536 bytes (3274266 pages) avail memory = 16442499072 (15680 MB) Table 'FACP' at 0xbf24f4b8 Table 'APIC' at 0xbf24f5c8 Table 'FPDT' at 0xbf24f650 Table 'FIDT' at 0xbf24f698 Table 'MCFG' at 0xbf24f738 Table 'HPET' at 0xbf24f778 Table 'SSDT' at 0xbf24f7b0 Table 'LPIT' at 0xbf24fb20 Table 'SSDT' at 0xbf24fbb8 Table 'SSDT' at 0xbf24fe00 Table 'SSDT' at 0xbf2529b0 Table 'DBGP' at 0xbf2536a8 Table 'DBG2' at 0xbf2536e0 Table 'SSDT' at 0xbf253738 Table 'SSDT' at 0xbf253e40 Table 'UEFI' at 0xbf259130 Table 'SSDT' at 0xbf259178 Table 'ASF!' at 0xbf25a0d0 Table 'DMAR' at 0xbf25a028 DMAR: Found table at 0xbf25a028 x2APIC available but disabled by DMAR table Event timer "LAPIC" quality 600 ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 x86bios: SSEG 0x098000-0x098fff at 0xfffffe03dabd0000 x86bios: EBDA 0x09c000-0x09ffff at 0xfffff8000009c000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 lapic0: CMCI unmasked random: read 4096 bytes from preloaded cache random: unblocking device. ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0x00000000000F0580 000024 (v02 ALASKA) ACPI: XSDT 0x00000000BF22E0A0 0000BC (v01 ALASKA A M I 01072009 AMI 00010013) ACPI: FACP 0x00000000BF24F4B8 00010C (v05 ALASKA A M I 01072009 AMI 00010013) ACPI: DSDT 0x00000000BF22E1F8 0212BB (v02 ALASKA A M I 01072009 INTL 20120913) ACPI: FACS 0x00000000BFA21F80 000040 ACPI: APIC 0x00000000BF24F5C8 000084 (v03 ALASKA A M I 01072009 AMI 00010013) ACPI: FPDT 0x00000000BF24F650 000044 (v01 ALASKA A M I 01072009 AMI 00010013) ACPI: FIDT 0x00000000BF24F698 00009C (v01 ALASKA A M I 01072009 AMI 00010013) ACPI: MCFG 0x00000000BF24F738 00003C (v01 ALASKA A M I 01072009 MSFT 00000097) ACPI: HPET 0x00000000BF24F778 000038 (v01 ALASKA A M I 01072009 AMI. 0005000B) ACPI: SSDT 0x00000000BF24F7B0 00036D (v01 SataRe SataTabl 00001000 INTL 20120913) ACPI: LPIT 0x00000000BF24FB20 000094 (v01 INTEL SKL 00000000 MSFT 0000005F) ACPI: SSDT 0x00000000BF24FBB8 000248 (v02 INTEL sensrhub 00000000 INTL 20120913) ACPI: SSDT 0x00000000BF24FE00 002BAE (v02 INTEL PtidDevc 00001000 INTL 20120913) ACPI: SSDT 0x00000000BF2529B0 000CF3 (v02 INTEL Ther_Rvp 00001000 INTL 20120913) ACPI: DBGP 0x00000000BF2536A8 000034 (v01 INTEL 00000000 MSFT 0000005F) ACPI: DBG2 0x00000000BF2536E0 000054 (v00 INTEL 00000000 MSFT 0000005F) ACPI: SSDT 0x00000000BF253738 000705 (v02 INTEL xh_rvp08 00000000 INTL 20120913) ACPI: SSDT 0x00000000BF253E40 0052EA (v02 SaSsdt SaSsdt 00003000 INTL 20120913) ACPI: UEFI 0x00000000BF259130 000042 (v01 00000000 00000000) ACPI: SSDT 0x00000000BF259178 000E58 (v02 CpuRef CpuSsdt 00003000 INTL 20120913) ACPI: ASF! 0x00000000BF25A0D0 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: DMAR 0x00000000BF25A028 0000A8 (v01 INTEL SKL 00000001 INTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: ver 0x20 maxredir 0x77 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic6: Routing NMI -> LINT1 lapic6: LINT1 trigger: edge lapic6: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-119 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff x2APIC: 0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000300ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 random: entropy device external interface kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device netmap: loaded module null: crypto: module_register_init: MOD_LOAD (vesa, 0xffffffff80ee2ef0, 0) error 19 io: VMBUS: load random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" hpt27xx: RocketRAID 27xx controller driver v1.2.7 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 hptnr: R750/DC7280 controller driver v1.1.4 random: harvesting attach, 8 bytes (4 bits) from ram0 vtvga0: on motherboard random: harvesting attach, 8 bytes (4 bits) from vtvga0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 acpi0: on motherboard ACPI Error: [\134_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20150818/dswload-219) ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150818/psobject-237) ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20150818/tbxfload-211) ACPI Error: 1 table load failures, 7 successful (20150818/tbxfload-235) PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 24 blocks of module-level executable AML code acpi0: Power Button (fixed) random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource0 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource1 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource2 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource3 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource4 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource5 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource6 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF8000572B000 00037F (v02 PmRef Cpu0Cst 00003001 INTL 20120913) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF80005A7F000 0006A2 (v02 PmRef Cpu0Ist 00003000 INTL 20120913) random: harvesting attach, 8 bytes (4 bits) from cpu0 cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF80005A7E800 0005AA (v02 PmRef ApIst 00003000 INTL 20120913) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF80005723000 000119 (v02 PmRef ApCst 00003000 INTL 20120913) random: harvesting attach, 8 bytes (4 bits) from cpu1 cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu3 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 24000000Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 24000000 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 24000000 Hz quality 550 Event timer "HPET1" frequency 24000000 Hz quality 440 Event timer "HPET2" frequency 24000000 Hz quality 440 Event timer "HPET3" frequency 24000000 Hz quality 440 Event timer "HPET4" frequency 24000000 Hz quality 440 random: harvesting attach, 8 bytes (4 bits) from hpet0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 random: harvesting attach, 8 bytes (4 bits) from atrtc0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58 Event timer "i8254" frequency 1193182 Hz quality 100 random: harvesting attach, 8 bytes (4 bits) from attimer0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_timer0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link0 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link1 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link2 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link3 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link4 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link5 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link6 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link7 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0x3e pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xc3000000-0xf7ffffff pcib0: decoding 3 range 0xfd000000-0xfe7fffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x191f, revid=0x07 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1912, revid=0x06 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf6000000, size 24, enabled pcib0: allocated type 3 (0xf6000000-0xf6ffffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib0: allocated type 3 (0xe0000000-0xefffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0xf000, size 6, enabled pcib0: allocated type 4 (0xf000-0xf03f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa12f, revid=0x31 domain=0, bus=0, slot=20, func=0 class=0c-03-30, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xf7210000, size 16, enabled pcib0: allocated type 3 (0xf7210000-0xf721ffff) for rid 10 of pci0:0:20:0 pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa13a, revid=0x31 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf722d000, size 12, memory disabled pcib0: allocated type 3 (0xf722d000-0xf722dfff) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa102, revid=0x31 domain=0, bus=0, slot=23, func=0 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xf7228000, size 13, enabled pcib0: allocated type 3 (0xf7228000-0xf7229fff) for rid 10 of pci0:0:23:0 map[14]: type Memory, range 32, base 0xf722c000, size 8, enabled pcib0: allocated type 3 (0xf722c000-0xf722c0ff) for rid 14 of pci0:0:23:0 map[18]: type I/O Port, range 32, base 0xf090, size 3, enabled pcib0: allocated type 4 (0xf090-0xf097) for rid 18 of pci0:0:23:0 map[1c]: type I/O Port, range 32, base 0xf080, size 2, enabled pcib0: allocated type 4 (0xf080-0xf083) for rid 1c of pci0:0:23:0 map[20]: type I/O Port, range 32, base 0xf060, size 5, enabled pcib0: allocated type 4 (0xf060-0xf07f) for rid 20 of pci0:0:23:0 map[24]: type Memory, range 32, base 0xf722b000, size 11, enabled pcib0: allocated type 3 (0xf722b000-0xf722b7ff) for rid 24 of pci0:0:23:0 pcib0: matched entry for 0.23.INTA pcib0: slot 23 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa112, revid=0xf1 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 secbus=1, subbus=1 found-> vendor=0x8086, dev=0xa113, revid=0xf1 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=15 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 secbus=2, subbus=2 found-> vendor=0x8086, dev=0xa118, revid=0xf1 domain=0, bus=0, slot=29, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 secbus=3, subbus=3 found-> vendor=0x8086, dev=0xa11d, revid=0xf1 domain=0, bus=0, slot=29, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 17 secbus=4, subbus=5 found-> vendor=0x8086, dev=0xa144, revid=0x31 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0xa121, revid=0x31 domain=0, bus=0, slot=31, func=2 class=05-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Memory, range 32, base 0xf7224000, size 14, enabled pcib0: allocated type 3 (0xf7224000-0xf7227fff) for rid 10 of pci0:0:31:2 found-> vendor=0x8086, dev=0xa170, revid=0x31 domain=0, bus=0, slot=31, func=3 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7220000, size 14, enabled pcib0: allocated type 3 (0xf7220000-0xf7223fff) for rid 10 of pci0:0:31:3 map[20]: type Memory, range 64, base 0xf7200000, size 16, enabled pcib0: allocated type 3 (0xf7200000-0xf720ffff) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa123, revid=0x31 domain=0, bus=0, slot=31, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 64, base 0xf722a000, size 8, enabled pcib0: allocated type 3 (0xf722a000-0xf722a0ff) for rid 10 of pci0:0:31:4 map[20]: type I/O Port, range 32, base 0xf040, size 5, enabled pcib0: allocated type 4 (0xf040-0xf05f) for rid 20 of pci0:0:31:4 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 random: harvesting attach, 8 bytes (4 bits) from hostb0 vgapci0: port 0xf000-0xf03f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device random: harvesting attach, 8 bytes (4 bits) from vgapci0 xhci0: mem 0xf7210000-0xf721ffff irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 xhci0: using IRQ 264 for MSI xhci0: MSI enabled usbus0: waiting for BIOS to give up control usbus0 on xhci0 xhci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from xhci0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7228000-0xf7229fff,0xf722c000-0xf722c0ff,0xf722b000-0xf722b7ff irq 16 at device 23.0 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.31 with 4 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF AL CLO 6Gbps PMD SSC PSC 32cmd EM 4ports ahci0: Caps2: DESO SADM SDS APST ahcich0: not probed (disabled) ahcich1: not probed (disabled) ahcich2: at channel 2 on ahci0 ahcich2: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich2 ahcich3: at channel 3 on ahci0 ahcich3: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich3 ahcich4: at channel 4 on ahci0 ahcich4: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich4 ahcich5: at channel 5 on ahci0 ahcich5: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich5 ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED random: harvesting attach, 8 bytes (4 bits) from ahciem0 random: harvesting attach, 8 bytes (4 bits) from ahci0 pcib1: irq 18 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pci1: on pcib1 pcib1: allocated bus range (1-1) for rid 0 of pci1 pci1: domain=0, physical bus=1 random: harvesting attach, 8 bytes (4 bits) from pci1 random: harvesting attach, 8 bytes (4 bits) from pcib1 pcib2: irq 19 at device 28.3 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 pcib0: allocated type 3 (0xf7100000-0xf71fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xf7100000-0xf71fffff pci2: on pcib2 pcib2: allocated bus range (2-2) for rid 0 of pci2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x15 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xe000, size 8, enabled pcib2: allocated I/O port range (0xe000-0xe0ff) for rid 10 of pci0:2:0:0 map[18]: type Memory, range 64, base 0xf7104000, size 12, enabled pcib2: allocated memory range (0xf7104000-0xf7104fff) for rid 18 of pci0:2:0:0 map[20]: type Memory, range 64, base 0xf7100000, size 14, enabled pcib2: allocated memory range (0xf7100000-0xf7103fff) for rid 20 of pci0:2:0:0 pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: port 0xe000-0xe0ff mem 0xf7104000-0xf7104fff,0xf7100000-0xf7103fff irq 19 at device 0.0 on pci2 re0: MSI count : 1 re0: MSI-X count : 4 re0: attempting to allocate 1 MSI-X vectors (4 supported) msi: routing MSI-X IRQ 266 to local APIC 0 vector 61 re0: using IRQ 266 for MSI-X re0: Using 1 MSI-X message re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: OUI 0x00e04c, model 0x0000, rev. 0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow random: harvesting attach, 8 bytes (4 bits) from rgephy0 random: harvesting attach, 8 bytes (4 bits) from miibus0 re0: Using defaults for TSO: 65518/35/2048 re0: bpf attached re0: Ethernet address: 30:5a:3a:07:fa:54 re0: netmap queues/slots: TX 1/256, RX 1/256 random: harvesting attach, 8 bytes (4 bits) from re0 random: harvesting attach, 8 bytes (4 bits) from pci2 random: harvesting attach, 8 bytes (4 bits) from pcib2 pcib3: irq 16 at device 29.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pci3: on pcib3 pcib3: allocated bus range (3-3) for rid 0 of pci3 pci3: domain=0, physical bus=3 random: harvesting attach, 8 bytes (4 bits) from pci3 random: harvesting attach, 8 bytes (4 bits) from pcib3 pcib4: irq 17 at device 29.5 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib4 pcib0: allocated type 3 (0xf7000000-0xf70fffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 5 pcib4: I/O decode 0xd000-0xdfff pcib4: memory decode 0xf7000000-0xf70fffff pci4: on pcib4 pcib4: allocated bus range (4-4) for rid 0 of pci4 pci4: domain=0, physical bus=4 found-> vendor=0x1b21, dev=0x1080, revid=0x04 domain=0, bus=4, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 secbus=5, subbus=5 pcib4: allocated bus range (5-5) for rid 0 of pci0:4:0:0 pcib5: irq 17 at device 0.0 on pci4 pcib4: allocated I/O port range (0xd000-0xdfff) for rid 1c of pcib5 pcib4: allocated memory range (0xf7000000-0xf70fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xf7000000-0xf70fffff pcib5: could not get PCI interrupt routing table for \134_SB_.PCI0.RP14.D048 - AE_NOT_FOUND pci5: on pcib5 pcib5: allocated bus range (5-5) for rid 0 of pci5 pci5: domain=0, physical bus=5 found-> vendor=0x10b7, dev=0x9055, revid=0x24 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x0a (2500 ns) intpin=a, irq=5 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd000, size 7, enabled pcib5: allocated I/O port range (0xd000-0xd07f) for rid 10 of pci0:5:0:0 map[14]: type Memory, range 32, base 0xf7020000, size 7, enabled pcib5: allocated memory range (0xf7020000-0xf702007f) for rid 14 of pci0:5:0:0 pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 pcib5: slot 0 INTA is routed to irq 17 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xf7020000-0xf702007f irq 17 at device 0.0 on pci5 xl0: using memory mapped I/O xl0: No auxiliary remote wakeup connector! xl0: media options word: a xl0: found MII/AUTO miibus1: on xl0 xlphy0: <3Com internal media interface> PHY 24 on miibus1 xlphy0: OUI 0x000000, model 0x0000, rev. 0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow random: harvesting attach, 8 bytes (4 bits) from xlphy0 random: harvesting attach, 8 bytes (4 bits) from miibus1 xl0: bpf attached xl0: Ethernet address: 00:10:5a:17:bd:ba ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 62 random: harvesting attach, 8 bytes (4 bits) from xl0 random: harvesting attach, 8 bytes (4 bits) from pci5 random: harvesting attach, 8 bytes (4 bits) from pcib5 random: harvesting attach, 8 bytes (4 bits) from pci4 random: harvesting attach, 8 bytes (4 bits) from pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 random: harvesting attach, 8 bytes (4 bits) from isa0 random: harvesting attach, 8 bytes (4 bits) from isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xf7220000-0xf7223fff,0xf7200000-0xf720ffff irq 16 at device 31.3 on pci0 hdac0: PCI card vendor: 0x1043, device: 0x86c7 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 267 to local APIC 0 vector 63 hdac0: using IRQ 267 for MSI hdac0: Caps: OSS 9, ISS 7, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 random: harvesting attach, 8 bytes (4 bits) from hdac0 pci0: at device 31.4 (no driver attached) random: harvesting attach, 8 bytes (4 bits) from pci0 random: harvesting attach, 8 bytes (4 bits) from pcib0 acpi_button0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button0 acpi_button1: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button1 acpi_tz0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_tz0 acpi_tz1: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_tz1 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 64 uart0: fast interrupt uart0: PPS capture mode: DCDinvalid random: harvesting attach, 8 bytes (4 bits) from uart0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 65 atkbd0: [GIANT-LOCKED] random: harvesting attach, 8 bytes (4 bits) from atkbd0 psm0: unable to allocate IRQ random: harvesting attach, 8 bytes (4 bits) from atkbdc0 psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 90 03 3c psm: status 90 03 3c psm: status 90 03 3c psm: data 08 00 00 psm: status 00 00 14 psm: status 00 00 28 psm: status 00 02 64 psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 66 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 random: harvesting attach, 8 bytes (4 bits) from psm0 random: harvesting attach, 8 bytes (4 bits) from psmcpnp0 random: harvesting attach, 8 bytes (4 bits) from fpupnp0 ACPI: Enabled 5 GPEs in block 00 to 7F random: harvesting attach, 8 bytes (4 bits) from acpi0 random: harvesting attach, 8 bytes (4 bits) from apic0 acpi0: wakeup code va 0xfffffe046066e000 pa 0x90000 random: harvesting attach, 8 bytes (4 bits) from nexus0 ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0 failed to probe on isa0 vga0 failed to probe on isa0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0 failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices random: harvesting attach, 8 bytes (4 bits) from acpi_perf0 random: harvesting attach, 8 bytes (4 bits) from acpi_perf1 random: harvesting attach, 8 bytes (4 bits) from acpi_perf2 random: harvesting attach, 8 bytes (4 bits) from acpi_perf3 est0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from cpufreq0 random: harvesting attach, 8 bytes (4 bits) from est0 est1: on cpu1 random: harvesting attach, 8 bytes (4 bits) from cpufreq1 random: harvesting attach, 8 bytes (4 bits) from est1 est2: on cpu2 random: harvesting attach, 8 bytes (4 bits) from cpufreq2 random: harvesting attach, 8 bytes (4 bits) from est2 est3: on cpu3 random: harvesting attach, 8 bytes (4 bits) from cpufreq3 random: harvesting attach, 8 bytes (4 bits) from est3 Device configuration finished. usbus0: 5.0Gbps Super Speed USB v3.0 procfs registered ZFS filesystem version: 5 ZFS storage pool version: features support (5000) lapic: Divisor 2, Frequency 12000568 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining tcp_init: net.inet.tcp.tcbhashsize auto tuned to 131072 IPsec: Initialized Security Association Processing. lo0: bpf attached hpt27xx: no controller detected. hptrr: no controller detected. hptnr: no controller detected. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x104386c7 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 17 90460130 3 0 SPDIF-out Fixed Digital Internal Unknown 1 hdaa0: 18 40330000 0 0 CD None ATAPI 0x00 Unknown 0 hdaa0: 20 01014010 1 0 Line-out Jack 1/8 Rear Green 0 hdaa0: 21 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 22 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 01a19040 4 0 Mic Jack 1/8 Rear Pink 0 hdaa0: 25 02a19050 5 0 Mic Jack 1/8 Front Pink 0 hdaa0: 26 0181304f 4 15 Line-in Jack 1/8 Rear Blue 0 hdaa0: 27 02214020 2 0 Headphones Jack 1/8 Front Green 0 hdaa0: 28 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 29 4046c629 2 9 SPDIF-out None Digital 0x00 Res.C 6 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: Patching widget caps nid=29 0x00400400 -> 0x00700400 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 17 90460130 3 0 SPDIF-out Fixed Digital Internal Unknown 1 hdaa0: 18 40330000 0 0 CD None ATAPI 0x00 Unknown 0 DISA hdaa0: 20 01014010 1 0 Line-out Jack 1/8 Rear Green 0 hdaa0: 21 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 22 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 01a19040 4 0 Mic Jack 1/8 Rear Pink 0 hdaa0: 25 02a19050 5 0 Mic Jack 1/8 Front Pink 0 hdaa0: 26 0181304f 4 15 Line-in Jack 1/8 Rear Blue 0 hdaa0: 27 02214020 2 0 Headphones Jack 1/8 Front Green 0 hdaa0: 28 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Association 1 (2) out: hdaa0: Pin nid=27 seq=0 hdaa0: Association 2 (3) out: hdaa0: Pin nid=17 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 4 (5) in: hdaa0: Pin nid=25 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 27 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 17 traced to DAC 16 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 8 hdaa0: Pin 26 traced to ADC 8 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Pin 25 traced to ADC 9 hdaa0: Association 4 (5) trace succeeded hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional DAC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Looking for additional ADC for association 4 (5) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 34 to out hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 25 to out hdaa0: Tracing nid 26 to out hdaa0: Tracing beeper hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20 and 24,26 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Line-out (Green Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, line, mic, mix] pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -64/0dB pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 17 (nid 12 in 0): mute pcm0: +- ctl 18 (nid 12 in 1): mute pcm0: +- ctl 25 (nid 20 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -64/0dB pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 17 (nid 12 in 0): mute pcm0: pcm0: Microphone Volume (OSS: mic): 0/30dB pcm0: +- ctl 7 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 30 (nid 24 out): 0/30dB (4 steps) pcm0: +- ctl 49 (nid 35 in 0): mute pcm0: pcm0: Line-in Volume (OSS: line): 0/30dB pcm0: +- ctl 9 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 34 (nid 26 out): 0/30dB (4 steps) pcm0: +- ctl 51 (nid 35 in 2): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -34/12dB pcm0: +- ctl 12 (nid 11 in 5): -34/12dB (32 steps) + mute pcm0: +- ctl 54 (nid 35 in 5): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 5 (nid 8 in 0): -16/30dB (47 steps) + mute pcm0: +- ctl 49 (nid 35 in 0): mute pcm0: +- ctl 51 (nid 35 in 2): mute pcm0: +- ctl 54 (nid 35 in 5): mute pcm0: +- ctl 59 (nid 35 in 10): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 7 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 2): -34/12dB (32 steps) + mute pcm0: +- ctl 12 (nid 11 in 5): -34/12dB (32 steps) + mute pcm0: +- ctl 18 (nid 12 in 1): mute pcm0: +- ctl 59 (nid 35 in 10): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 18 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (disconnected) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) random: harvesting attach, 8 bytes (4 bits) from pcm0 pcm1: at nid 27 and 25 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=27 [pin: Headphones (Green Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio mixer] [src: speaker, monitor] pcm1: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -64/0dB pcm1: +- ctl 2 (nid 3 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 13 in 0): mute pcm1: +- ctl 20 (nid 13 in 1): mute pcm1: +- ctl 35 (nid 27 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -64/0dB pcm1: +- ctl 2 (nid 3 out): -64/0dB (65 steps) pcm1: +- ctl 19 (nid 13 in 0): mute pcm1: pcm1: Microphone2 Volume (OSS: monitor): 0/30dB pcm1: +- ctl 32 (nid 25 out): 0/30dB (4 steps) pcm1: +- ctl 38 (nid 34 in 1): mute pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 42 (nid 34 in 5): mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 6 (nid 9 in 0): -16/30dB (47 steps) + mute pcm1: +- ctl 32 (nid 25 out): 0/30dB (4 steps) pcm1: +- ctl 38 (nid 34 in 1): mute pcm1: +- ctl 42 (nid 34 in 5): mute pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 20 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 20 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Mixer "ogain": pcm1: Mixer "monitor": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) random: harvesting attach, 8 bytes (4 bits) from pcm1 pcm2: at nid 17 on hdaa0 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz pcm2: DAC: 16 pcm2: pcm2: nid=17 [pin: SPDIF-out (Fixed)] pcm2: + <- nid=16 [audio output] [src: pcm] pcm2: pcm2: Mixer "vol" -> "none": child=0x00000010 pcm2: Mixer "pcm": parent="vol" pcm2: Soft PCM mixer ENABLED pcm2: Playback channel set is: Front Left, Front Right, pcm2: Playback channel matrix is: 2.0 (unknown) random: harvesting attach, 8 bytes (4 bits) from pcm2 random: harvesting attach, 8 bytes (4 bits) from hdaa0 random: harvesting attach, 8 bytes (4 bits) from hdacc0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 3 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 3 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref random: harvesting attach, 8 bytes (4 bits) from hdaa1 random: harvesting attach, 8 bytes (4 bits) from hdacc1 ahcich2: AHCI reset... ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ahcich2: SATA connect time=100us status=00000133 ahcich2: AHCI reset: device found ahcich2: AHCI reset: device ready after 0ms ahcich3: AHCI reset... ahcich3: SATA connect time=1900us status=00000113 ahcich3: AHCI reset: device found ahcich3: AHCI reset: device ready after 0ms ahcich4: AHCI reset... ahcich4: SATA offline status=00000004 ahcich4: AHCI reset: device not found ahcich5: AHCI reset... ahcich5: SATA offline status=00000004 ahcich5: AHCI reset: device not found ada0 at ahcich2 bus 0 scbus0 target 0 lun 0 GEOM: new disk ada0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S1DBNSCF333310B ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors) ada0: quirks=0x1<4K> pass0 at ahcich2 bus 0 scbus0 target 0 lun 0 pass0: ACS-2 ATA SATA 3.x device pass0: Serial Number S1DBNSCF333310B pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) pass0: Command Queueing enabled pass1 at ahcich3 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI device pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) pass2 at ahciem0 bus 0 scbus4 target 0 lun 0 pass2: SEMB S-E-S 2.00 device ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 cd0 at ahcich3 bus 0 scbus1 target 0 lun 0 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: cd0: Removable CD-ROM SCSI device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device lapic6: CMCI unmasked lapic4: CMCI unmasked lapic2: CMCI unmasked SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x06000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff x2APIC: 0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff x2APIC: 0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff x2APIC: 0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 2 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 4 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 6 vector 48 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 4 vector 49 msi: Assigning MSI-X IRQ 259 to local APIC 6 vector 49 msi: Assigning MSI IRQ 264 to local APIC 4 vector 50 msi: Assigning MSI IRQ 265 to local APIC 6 vector 50 msi: Assigning MSI IRQ 267 to local APIC 2 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1596075413 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... GEOM: new disk cd0 Root mount waiting for: usbus0 uhub0: 24 ports with 24 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub0 start_init: trying /sbin/init re0: link state changed to DOWN re0: link state changed to UP xl0: link state changed to DOWN -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@freebsd.org Sun Feb 14 00:47:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 210FAAA10DA for ; Sun, 14 Feb 2016 00:47:30 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 B14258FB for ; Sun, 14 Feb 2016 00:47:29 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id a4so12770144wme.1 for ; Sat, 13 Feb 2016 16:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pETxXUYT+N1gT7Xfbp6sd/mXHpvdm5W8qqWwX8h5uFM=; b=mmR5pL+Prd/VK+Dfel5r+KZId53B4IQPjhrGeOxzJZe4/1gAwiCxQHwzTsNFe8CIGE 2laRRKtrvZA0ySbYZbDFnz+8PUQ69jUuqY9nbg1no/+XB7WLlGrz00CZhA/Gzv6ahFZD 1dsEKDmyA8npoYA7B/vBceyCNCSPqZ54pS4FpZK/+ugdUvAgwaDAJ5UHGnW6AQgSMZlA 8YWFr5QObQIpmXBJyXumIijzvO7JVRpWQOc+WSBWODKXDJbQSDGhjWnjUkaNls/1LlHB SNlBN8aVJr4z3zoFS3m8v4WEJ/OLQN2ZVW4M3I80exgB/hkyr2zjwtL06MCKfQyV+PgT R57w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pETxXUYT+N1gT7Xfbp6sd/mXHpvdm5W8qqWwX8h5uFM=; b=OEYiUYOoukss0x/GF/eCAjkRHwxCuAU1I3N4Rh2zMsLiHkgH4X3Uf5BUReRiLPhaaW z3X8tNy/th1Y0VAYubqPkLxyEVFPvuAC6OWW5UvBF4hgsu1hSs33rjD8wgl5qI+1V17/ fb3651ig6V9Oya+9/fmTMvNQkP28YC9GtoWidHuMEiF+jJbB9dvnAFJ5E0Vms1CzFkSY hKHa3yPxmMIuwH5UakLOWvaigKWC8ZVi6u5oUyx8dN81OkUTuxXGVdfBhaud5HaT+fjn xLroveIl44AXwtolt57Uvzz3kzwauCJegJIj5Yv8MFhCucY/5H3s3GFMp0KF3YITfjy5 D2ZA== X-Gm-Message-State: AG10YORUf1qDrO4T1o37LHgzhFnMR1Gh0PuooZbNeJlYus5+xgo2z8ME6+O09ylQrvCKYVh17z2Vu7Pqn4pEsQ== MIME-Version: 1.0 X-Received: by 10.194.142.135 with SMTP id rw7mr8916786wjb.42.1455410847937; Sat, 13 Feb 2016 16:47:27 -0800 (PST) Received: by 10.28.140.73 with HTTP; Sat, 13 Feb 2016 16:47:27 -0800 (PST) Date: Sun, 14 Feb 2016 01:47:27 +0100 Message-ID: Subject: FreeBSD 10.3 BETA1&2 does not boot on Mac Pro 2008 From: claudiu vasadi To: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 00:47:30 -0000 Hello all, While trying to boot 10.3 amd64 uefi disk1 BETA1 and BETA2 iso on a Mac Pro 2008, I get the following message: BETA1 - http://s76.photobucket.com/user/da1_27/media/10.3-BETA1_zpswjatgfg2.jpg.html BETA2 - http://s76.photobucket.com/user/da1_27/media/10.3-BETA2_zpsfiedhsks.jpg.html Right after displaying the message I see the Num Lock going off and on and I can hear the optical unit moving the head a couple of times; after that, complete silence. When booting verbose, I get the exact same behavior and message. Ideas? -- Best regards, Claudiu Vasadi From owner-freebsd-stable@freebsd.org Sun Feb 14 10:21:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EDA7AA8FC8 for ; Sun, 14 Feb 2016 10:21:51 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC8691423 for ; Sun, 14 Feb 2016 10:21:50 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from pd952128d.dip0.t-ipconnect.de ([217.82.18.141] helo=kosei.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aUtLy-0005y1-Cs; Sun, 14 Feb 2016 10:52:31 +0100 Date: Sun, 14 Feb 2016 10:52:24 +0100 From: Yamagi Burmeister To: lausts@acm.org Cc: freebsd-stable@freebsd.org Subject: Re: UEFI & ZFS Message-Id: <20160214105224.6b69d854724f829de0af2d19@yamagi.org> In-Reply-To: <56BE423A.12522.27C542@lausts.acm.org> References: <56BE423A.12522.27C542@lausts.acm.org> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 10:21:51 -0000 Hello, this is a known problem with Intel Skylake CPUs. Legacy boot os dead slow, UEFI boot is blazing fast. Have a look at this thread, it contains some more informations: https://lists.freebsd.org/pipermail/freebsd-current/2015-December/059037.html As far as I know now one has found / analyzed the root cause of this until now. Regard, On Fri, 12 Feb 2016 15:36:10 -0500 "Thomas Laus" wrote: > > I have a new Asus H170-Plus-D3 motherboard that will be used for a DOM0 Xen > > Server. It uses an Intel i5-6300 processor and a Samsung 840 EVO SSD. I > > would like to use ZFS on this new installation. The Xen Kernel does not > > have UEFI support at this time, so I installed FreeBSD CURRENT r295345 in > > 'legacy mode'. It takes about 7 minutes to go from the first '|' character > > to getting the 'beastie' menu. I changed the BIOS to UEFI and did another > > installation. The boot process goes in an instant. > > Several others have the same problem. See here on the freebsd forums: > > http://tinyurl.com/z9oldkc > > That is my exact problem. It takes 4 minutes to get a complete 'beastie' > menu and 7 minutes 34 seconds to login. > > Tom > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-stable@freebsd.org Sun Feb 14 11:12:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8539AA7018 for ; Sun, 14 Feb 2016 11:12:38 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 59949147E for ; Sun, 14 Feb 2016 11:12:37 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x229.google.com with SMTP id g62so74002451wme.0 for ; Sun, 14 Feb 2016 03:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Ur6OyuiWBH7YyoT+9t26tP7c4bfIpc8nrV4eQBhtG58=; b=dXWYKq3lPLlDdUpDd0gobxht9vPY0HU/iV0hQdM42UkvSNna7xjM8wzrTjwwJ++cU6 eZIEdbr5FuAKGI6smAEeAapzkI2qn/6NL3FvBh648rkfATpLgnLprXD1tnc2Mu+tOGzv 1xKcZtqjMc0iDlyBabrdeKMOqXMVy3MLiFaEOZZZSbsSv+Enz6F1qnsaPNKj+ag2cUEX CTu5rbmpZnTESeKPvF09wEsBS8Mu01BVRfEbKz8J6iOqTCCN2yWkvYshgPMXfcTKXUVS ZmDY7EnEBF/XG0nCznws7pk+J/2hncsFMWNxVbv1orJ+W7HkvEHn6H/WR1S4zmp3YEYa RMYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ur6OyuiWBH7YyoT+9t26tP7c4bfIpc8nrV4eQBhtG58=; b=G+/NH95UISq/fTcS9z5RvEAS07cZZPfXEIitDzGscvnt+n4Q0E4Ism/Xbu6E3I0FZJ ti8EtmqTroNuOSTFfS4sivKulPogIEpjO8x96k89icb8v4MWc8ccVw2aPUXBw42yNx6V 9eyZN2q68uAZJwFsgg0EgVon111PHaeAYCmchMpWUUwC3JKAq2f/ln4FvxqcKcEJolcU 2nBzVDUd32NMVQkEzcuTeTuK70+gteG9BOts8pv2kV9J0ClhzH8xAPtgY5vAes2+fji5 1LTAQo8ZdpJAZzLod33FdNPuZjdYgC3WyH+kKqgCp8m4EM6b/B410RyogNgeY+SMEhC7 8mIw== X-Gm-Message-State: AG10YOQk1IE57hPqvHdEAJtU6ZsJOjCav7QxOB0EP/0LVZUVe4ZJK7cvdwQwehVSBQgi4KHU X-Received: by 10.194.61.42 with SMTP id m10mr10671814wjr.126.1455448356481; Sun, 14 Feb 2016 03:12:36 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id d9sm20207904wjf.43.2016.02.14.03.12.35 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Feb 2016 03:12:35 -0800 (PST) Subject: Re: FreeBSD 10.3 BETA1&2 does not boot on Mac Pro 2008 To: freebsd-stable@freebsd.org References: From: Steven Hartland Message-ID: <56C06126.5080600@multiplay.co.uk> Date: Sun, 14 Feb 2016 11:12:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 11:12:38 -0000 On 14/02/2016 00:47, claudiu vasadi wrote: > Hello all, > > While trying to boot 10.3 amd64 uefi disk1 BETA1 and BETA2 iso on a Mac Pro > 2008, I get the following message: > > BETA1 - > http://s76.photobucket.com/user/da1_27/media/10.3-BETA1_zpswjatgfg2.jpg.html > > BETA2 - > http://s76.photobucket.com/user/da1_27/media/10.3-BETA2_zpsfiedhsks.jpg.html > > Right after displaying the message I see the Num Lock going off and on and > I can hear the optical unit moving the head a couple of times; after that, > complete silence. > > When booting verbose, I get the exact same behavior and message. > > Ideas? The next step after that is to display the framebuffer information and there is some additional support added in head, 10 only supports graphics output protocol but head also supports UGA draw, which from the commit message for r287538 seems to indicate this may be required for MAC's. So if you can you try the latest HEAD snapshot and see if there are any difference? If that fixes it should look to try and MFC those changes too. Regards Steve From owner-freebsd-stable@freebsd.org Sun Feb 14 11:47:20 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C79D9AA7F7D for ; Sun, 14 Feb 2016 11:47:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 837DB1099 for ; Sun, 14 Feb 2016 11:47:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aUv8r-0005DX-O7; Sun, 14 Feb 2016 13:47:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: UEFI & ZFS From: Daniel Braniss In-Reply-To: <20160214105224.6b69d854724f829de0af2d19@yamagi.org> Date: Sun, 14 Feb 2016 13:47:05 +0200 Cc: lausts@acm.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F76A980-AD77-4C77-BC0B-1B60D2351721@cs.huji.ac.il> References: <56BE423A.12522.27C542@lausts.acm.org> <20160214105224.6b69d854724f829de0af2d19@yamagi.org> To: Yamagi Burmeister X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 11:47:20 -0000 > On 14 Feb 2016, at 11:52, Yamagi Burmeister wrote: >=20 > Hello, > this is a known problem with Intel Skylake CPUs. Legacy boot os dead > slow, UEFI boot is blazing fast. Have a look at this thread, it = contains > some more informations: >=20 > = https://lists.freebsd.org/pipermail/freebsd-current/2015-December/059037.h= tml >=20 > As far as I know now one has found / analyzed the root cause of this > until now. when saying =E2=80=98slow=E2=80=99, do you see slowness when printing = output to the screen? I mention this, because in the past I saw something similar, and it was = a misconfiguration with the serial console =E2=80=A6 danny >=20 > Regard, >=20 >=20 > On Fri, 12 Feb 2016 15:36:10 -0500 > "Thomas Laus" wrote: >=20 >>> I have a new Asus H170-Plus-D3 motherboard that will be used for a = DOM0 Xen >>> Server. It uses an Intel i5-6300 processor and a Samsung 840 EVO = SSD. I >>> would like to use ZFS on this new installation. The Xen Kernel does = not >>> have UEFI support at this time, so I installed FreeBSD CURRENT = r295345 in >>> 'legacy mode'. It takes about 7 minutes to go from the first '|' = character >>> to getting the 'beastie' menu. I changed the BIOS to UEFI and did = another >>> installation. The boot process goes in an instant. >>=20 >> Several others have the same problem. See here on the freebsd forums: >>=20 >> http://tinyurl.com/z9oldkc >>=20 >> That is my exact problem. It takes 4 minutes to get a complete = 'beastie'=20 >> menu and 7 minutes 34 seconds to login. >>=20 >> Tom >>=20 >> --=20 >> Public Keys: >> PGP KeyID =3D 0x5F22FDC1 >> GnuPG KeyID =3D 0x620836CF >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Homepage: www.yamagi.org > XMPP: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sun Feb 14 12:28:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E84EAA88E1 for ; Sun, 14 Feb 2016 12:28:06 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 477821383 for ; Sun, 14 Feb 2016 12:28:05 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from pd952128d.dip0.t-ipconnect.de ([217.82.18.141] helo=kosei.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aUvmN-0007o2-RY; Sun, 14 Feb 2016 13:27:57 +0100 Date: Sun, 14 Feb 2016 13:27:49 +0100 From: Yamagi Burmeister To: danny@cs.huji.ac.il Cc: lausts@acm.org, freebsd-stable@freebsd.org Subject: Re: UEFI & ZFS Message-Id: <20160214132749.efba24a6855e37855d3cbaa9@yamagi.org> In-Reply-To: <3F76A980-AD77-4C77-BC0B-1B60D2351721@cs.huji.ac.il> References: <56BE423A.12522.27C542@lausts.acm.org> <20160214105224.6b69d854724f829de0af2d19@yamagi.org> <3F76A980-AD77-4C77-BC0B-1B60D2351721@cs.huji.ac.il> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 12:28:06 -0000 Hello, I've observed the slowness only on the local console, I haven't tested the seriel console. Put the FreeBSD legcay installation usb stick into the box, select it as boot device and watch the cursor spinning for about 10 minutens until the kernel boots. Do the same with an UEFI installation stick and it's a matter of seconds... I've seen this on an Gigabyte GA-Z170XP-SLI with a Core i7 6700k and on two Supermicro X11SBA-LN4F based machines with Skylake Xeon CPUs. There are several other reports of slow boot on Skylake CPUs on the net. In the thread mentioned below some changes in the hardware, the firmware or somewhere else were suspected. I didn't even try to debug it,instead I went with the UEFI loader. Regards, Yamagi On Sun, 14 Feb 2016 13:47:05 +0200 Daniel Braniss wrote: > > On 14 Feb 2016, at 11:52, Yamagi Burmeister wrote: > > > > https://lists.freebsd.org/pipermail/freebsd-current/2015-December/059037.html > when saying ‘slow’, do you see slowness when printing output to the screen? > I mention this, because in the past I saw something similar, and it was a > misconfiguration with the serial console … > > danny > > > > > Regard, > > > > > > On Fri, 12 Feb 2016 15:36:10 -0500 > > "Thomas Laus" wrote: > > > >>> I have a new Asus H170-Plus-D3 motherboard that will be used for a DOM0 Xen > >>> Server. It uses an Intel i5-6300 processor and a Samsung 840 EVO SSD. I > >>> would like to use ZFS on this new installation. The Xen Kernel does not > >>> have UEFI support at this time, so I installed FreeBSD CURRENT r295345 in > >>> 'legacy mode'. It takes about 7 minutes to go from the first '|' character > >>> to getting the 'beastie' menu. I changed the BIOS to UEFI and did another > >>> installation. The boot process goes in an instant. > >> > >> Several others have the same problem. See here on the freebsd forums: > >> > >> http://tinyurl.com/z9oldkc > >> > >> That is my exact problem. It takes 4 minutes to get a complete 'beastie' > >> menu and 7 minutes 34 seconds to login. > >> > >> Tom > >> > >> -- > >> Public Keys: > >> PGP KeyID = 0x5F22FDC1 > >> GnuPG KeyID = 0x620836CF > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > -- > > Homepage: www.yamagi.org > > XMPP: yamagi@yamagi.org > > GnuPG/GPG: 0xEFBCCBCB > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-stable@freebsd.org Sun Feb 14 12:59:50 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7878FAA063B; Sun, 14 Feb 2016 12:59:50 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: from mail2.openmailbox.org (mail2.openmailbox.org [62.4.1.33]) (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 3B4D6125A; Sun, 14 Feb 2016 12:59:49 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1004) id B72812AC23D8; Sun, 14 Feb 2016 13:59:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1455454780; bh=svkyVb8OHK6GP+S1g1xbl/EC9JMRQzemiJAwu9H+ovU=; h=Date:From:To:Subject:From; b=UEIko6W7oaPLdp7a4SQDtKMWjvb17/05HsTeWmJR8Spg1keMqy558StagN4nSXg++ sFxbIOJt4V6kRncsQqSeDrhpvixzSkzp+hTM6qDfh9z0U8/qVKhbjTET3eeMgYPLyE eB163YufhMQpBYKTdtocYZF6i7x3hDhInbNjkt58= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b2 X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED,BAYES_50, DKIM_ADSP_ALL,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from www.openmailbox.org (openmailbox-b1 [10.91.69.218]) by mail2.openmailbox.org (Postfix) with ESMTP id 97C902AC3C0E; Sun, 14 Feb 2016 13:59:30 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 14 Feb 2016 19:59:30 +0700 From: Tinker To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Subject: MRSAS driver/LSI MegaRaid 92XX-93XX admin question: When one of the Raid's physical drives break, how is it reported in the =?UTF-8?Q?logs=3F?= Message-ID: <6a648d421b6d611b4f6f411b66303017@openmailbox.org> X-Sender: tinkr@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 12:59:50 -0000 ( ** Extremely sorry for crossposting! Was unclear where this RAID adapter question belongs, please clarify and I'll keep to one single list! Posted to all of stable@, scsi@ and fs@ .) Hi, When you run one of the MRSAS drives such as a Avatogech LSI MegaRaid 9361 or 9266, and then eventually one of the physical RaidDrives or a CacheCade drives breaks, how is this reported to the FreeBSD host's dmesg or syslog? I don't have the hardware in place so that I would be able to check. On the other hand someone among you may have extremely deep experience, in particular because this card is so common, so this is why I ask you here. I understand that if at least one underlying copy of the data is accessible, the RAID card will optimize all access to that one, so when it comes to keeping IO working without interruption, the LSI card does a great job. At some point, an SSD or HDD will break down, either completely (it won't connect and its SMART interface says the drive is consumed) or more discretely, through taking tons of time for its operations. My best understanding is that the Raid card automatically will take those drives out of use, transparently. Now to the main point: As admin, it's great to be informed when this happens i.e. an underlying physical Raid disk or a CacheCade disk is taken out of use or otherwise malfunctions. Does the MrSas driver output this into the dmesg or syslog somehow? Reading https://svnweb.freebsd.org/base/stable/10/sys/dev/mrsas/mrsas.c?revision=284267&view=markup , the card seems to have an "event log" that the driver downloads from the card in plaintext (??), but I don't understand from the sourcecode where that information is channeled. And also of course I can't see what that event log would contain in those cases. (The "mfiutil" has a "show events" argument, though mfiutil is only for the related "mfi" driver which does not work for both 92XX and 93XX cards. Also in this case still I'd be interested to know how it reports a broken drive) http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/3rd-party/lsi/mrsas/userguide/LSI_MR_SAS_SW_UG.pdf on page 305, that is section "A.2 Event Messages" - I don't know for what LGI chip this document is, but, it does not list particular event message very clearly for when an individual underlying disk would have broken, I don't even see any event for when a hot spare would be taken in use! You who have the experience, can you clarify please? Thanks :D Tinker From owner-freebsd-stable@freebsd.org Sun Feb 14 13:38:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A14E9AA72C2 for ; Sun, 14 Feb 2016 13:38:30 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3120C19A7 for ; Sun, 14 Feb 2016 13:38:30 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id g62so24566087wme.1 for ; Sun, 14 Feb 2016 05:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wJgr2OVu3gbbPaWic/SZlUCXS+JCDgEV+BWaX9jXmUk=; b=e00klvW99ZYM6814XuWbZ7JaX6DBi2ypjHE5BX5baUOD8L9esPRRN8+Knm9LVRzGbe 9thTPk6bR54HBpn+0VZPDWE0StgAcolMgnMkjZfZpv+abAGJ/xRJJMANukL9JRE1/n3u RuSW6P2mExjnZCTejifg54afYNu7fOH63KTZk2BkRcdWw+xNYh5rHPO2QtnSwmjVS/vU KtOTH5ioBwRLut64IJhOVFWhE/EtOcA5uEXu+bCwHIZfNjq/PgG5vY9h9SdwalVeNYf+ NT2+cMhjeu90RDnHqYTnBGm/uCpdpg1vNSfuh9g2t2trd+nVbTKhDmxj7861KAYKMGJS YDCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wJgr2OVu3gbbPaWic/SZlUCXS+JCDgEV+BWaX9jXmUk=; b=ZB9IsIOLjQhov2+HCHXRWWVHGgVGOkvVC8GJG0Q6LuXCU6PwHlWPV0NNM3g41j5oPr ZBoa43OXYTY4F94R9UsBz5atvbpJv4hwdUUVIJxsXj2cED/LX0v21tyTk5y5VTPekKZV HvC1f7X7JxvzbgLqpw9ldgfjxKDfL3pqiomAkwcuDZWPiYIhOw6yQUoY16UaRDoxCedD Ga6v0lnozQ5yjfxIZb++IBmWq58OGUqI3Aoak1PeeYpHUYz0mQaO26OXpxP7iOYhMD2T Ut8YmYuV0SRT9+qBvrRLnrZ5oiukEUFU4o4HzPXMOC4hTIOooONa2LKLINqeHZN1N+16 FTMQ== X-Gm-Message-State: AG10YOQ09JcN7aR2pe7wc31kOr9MAqaAYZKS7zDgfsKcG00FzMALdIQKRPbKlTQDrHsq54jz83Y/d9Gsnf19eg== MIME-Version: 1.0 X-Received: by 10.194.103.198 with SMTP id fy6mr13180547wjb.48.1455457108522; Sun, 14 Feb 2016 05:38:28 -0800 (PST) Received: by 10.28.140.73 with HTTP; Sun, 14 Feb 2016 05:38:28 -0800 (PST) In-Reply-To: <56C06126.5080600@multiplay.co.uk> References: <56C06126.5080600@multiplay.co.uk> Date: Sun, 14 Feb 2016 14:38:28 +0100 Message-ID: Subject: Re: FreeBSD 10.3 BETA1&2 does not boot on Mac Pro 2008 From: claudiu vasadi To: Steven Hartland Cc: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 13:38:30 -0000 Hi, FreeBSD-11.0-CURRENT-amd64-20160206-r295345-disc1.iso works. Any chance for the missing bits to be MFC'ed? On Sun, Feb 14, 2016 at 12:12 PM, Steven Hartland wrote: > On 14/02/2016 00:47, claudiu vasadi wrote: > >> Hello all, >> >> While trying to boot 10.3 amd64 uefi disk1 BETA1 and BETA2 iso on a Mac >> Pro >> 2008, I get the following message: >> >> BETA1 - >> >> http://s76.photobucket.com/user/da1_27/media/10.3-BETA1_zpswjatgfg2.jpg.html >> >> BETA2 - >> >> http://s76.photobucket.com/user/da1_27/media/10.3-BETA2_zpsfiedhsks.jpg.html >> >> Right after displaying the message I see the Num Lock going off and on and >> I can hear the optical unit moving the head a couple of times; after that, >> complete silence. >> >> When booting verbose, I get the exact same behavior and message. >> >> Ideas? >> > > The next step after that is to display the framebuffer information and > there is some additional support added in head, 10 only supports graphics > output protocol but head also supports UGA draw, which from the commit > message for r287538 seems to indicate this may be required for MAC's. > > So if you can you try the latest HEAD snapshot and see if there are any > difference? > > If that fixes it should look to try and MFC those changes too. > > Regards > Steve > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Best regards, Claudiu Vasadi From owner-freebsd-stable@freebsd.org Sun Feb 14 15:13:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2143DAA7FDE; Sun, 14 Feb 2016 15:13:48 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: from mail2.openmailbox.org (mail2.openmailbox.org [62.4.1.33]) (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 D13091E38; Sun, 14 Feb 2016 15:13:47 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1004) id 78B892AC260D; Sun, 14 Feb 2016 16:13:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1455462823; bh=a6xRsHv3dB8Og6u7p4fjbM5qiUhvubkqMeI/6wnFUGk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=BGg9woQZ2saaEnpPj7pRPuzJLQ/6mxc71q99ZNWGdj82+STcxUMZ0lO/68mXp6e8N /kP+z4YL/Pm2g5+z1B8kN41weu7n5aZMcEk2A4bRN0Rn8MwKFqNVcOOU8Ws5PkyJ6q Datw1/fbJ+OFpKv1M1qTy9TQ+/j3aXiYZrgUEU/s= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b2 X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED,BAYES_50, DKIM_ADSP_ALL,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from www.openmailbox.org (openmailbox-b2 [10.91.69.220]) by mail2.openmailbox.org (Postfix) with ESMTP id C48662AC564D; Sun, 14 Feb 2016 16:13:31 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 14 Feb 2016 22:13:31 +0700 From: Tinker To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Subject: Re: MRSAS driver/LSI MegaRaid 92XX-93XX admin question: When one of the Raid's physical drives break, how is it reported in the =?UTF-8?Q?logs=3F?= In-Reply-To: <6a648d421b6d611b4f6f411b66303017@openmailbox.org> References: <6a648d421b6d611b4f6f411b66303017@openmailbox.org> Message-ID: <55de137d1ed81930cfdbee579d881d62@openmailbox.org> X-Sender: tinkr@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 15:13:48 -0000 (Will send any followup from now only to freebsd-scsi@ .) Did some additional research and found that the disk failure indeed is reported in MRSAS' "event log". So my final question then is, how do you extract it into userland (in the absence of an "mfiutil" as the MFI driver has)? Details below. Thanks. On 2016-02-14 19:59, Tinker wrote: [...] > http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/3rd-party/lsi/mrsas/userguide/LSI_MR_SAS_SW_UG.pdf > on page 305, that is section "A.2 Event Messages" - I don't know for > what LGI chip this document is, but, it does not list particular event > message very clearly for when an individual underlying disk would have > broken, I don't even see any event for when a hot spare would be taken > in use! Wait - this page: https://www.schirmacher.de/display/Linux/Replace+failed+disk+in+MegaRAID+array (and also http://serverfault.com/questions/485147/drive-is-failing-but-lsi-megaraid-controller-does-not-detect-it ) gives an example of how the host system learns about broken disks: Code: 0x00000051 .. Event Description: State change on VD 00/1 from OPTIMAL(3) to DEGRADED(2) Code: 0x00000072 .. Event Description: State change on PD 05(e0xfc/s0) from ONLINE(18) to FAILED(11) (unclean disk broken seems to be shown as:) Code: 0x00000071 .. Event Description: Unexpected sense: PD 05(e0xfc/s0) Path 4433221103000000, CDB: 2e 00 3a 38 1b c7 00 00 01 00, Sense: b/00/00 And this version of the LSI documentation http://hwraid.le-vert.net/raw-attachment/wiki/LSIMegaRAIDSAS/megacli_user_guide.pdf gives a clearer definition of the physical and virtual drive states in "1.4.16 Physical Drive States" and "1.4.17 Virtual Disk States" on pages 1-11 to 1-12. So as we see, a physical drive breaking would * "FAILED" the physical drive * "DEGRADED" the Virtual Drive (that is the logical exported drive) (from "OPTIMAL") So then, it was indeed the card's "event log" that contains this info. Last question then would only be then, *where* FreeBSD's MRSAS driver sends its event log? From owner-freebsd-stable@freebsd.org Sun Feb 14 15:26:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6256FAA8670; Sun, 14 Feb 2016 15:26:26 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A32B172D; Sun, 14 Feb 2016 15:26:26 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aUyZ8-000BJ1-RF; Sun, 14 Feb 2016 16:26:26 +0100 Date: Sun, 14 Feb 2016 16:26:26 +0100 From: Kurt Jaeger To: Tinker Cc: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Subject: Re: MRSAS driver/LSI MegaRaid 92XX-93XX admin question: When one of the Raid's physical drives break, how is it reported in the logs? Message-ID: <20160214152626.GH26283@home.opsec.eu> References: <6a648d421b6d611b4f6f411b66303017@openmailbox.org> <55de137d1ed81930cfdbee579d881d62@openmailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55de137d1ed81930cfdbee579d881d62@openmailbox.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 15:26:26 -0000 Hi! > So my final question then is, how do you extract it into userland (in > the absence of an "mfiutil" as the MFI driver has)? They renamed the util to StorCLI, it looks very similar to the old tw_cli, and can be downloaded from http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-sas-9266-8i#downloads as MR_SAS_StorCLI_1-16-06.zip, unpacking it yields storcli_all_os.zip, unpacking that yields storcli_all_os/FreeBSD/storcli64.tar, and finally unpacking that gives $ file storcli64 storcli64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 7.4, stripped which at least looks like it might work with the MRSAS controller. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Sun Feb 14 16:41:58 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0563DAA8B7D for ; Sun, 14 Feb 2016 16:41:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A170F19C5; Sun, 14 Feb 2016 16:41:57 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u1EGftJb019795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Feb 2016 17:41:55 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u1EGftlq019794; Sun, 14 Feb 2016 17:41:55 +0100 (CET) (envelope-from marius) Date: Sun, 14 Feb 2016 17:41:55 +0100 From: Marius Strobl To: freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 10.3-BETA2 Now Available Message-ID: <20160214164155.GK15359@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PkEWctFf+8E2rcii" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 14 Feb 2016 17:41:55 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 16:41:58 -0000 --PkEWctFf+8E2rcii Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The second BETA build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC O ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-BETA1 === o OpenSSH has been upgraded to 7.1p2. o A bug in bsnmpd(1) causing breakage on platforms with strict alignment requirements has been fixed. o A leak of routing table allocations occurring when shutting down VNET- enabled jails has been fixed. o The tty(4) layer now prohibits opening the callout device when the corresponding callin device (in disguise as the console device) is already opened. o Corruption of coredumps due to procstat notes changing size during coredump generation have been fixed. o A leap-seconds file for ntpd(8) now is installed by default and ntpd.conf(5) as well as the corresponding rc(8) files have been updated accordingly. Additionally, support for updating the leap- seconds file via periodic(8) has been added (defaulting to off). o The UEFI ZFS loader has been updated to support the latest ZFS Boot Environment (BE) loader menu features. o The initialization of random(9) has been adjusted so it is usable earlier. This fixes the "random device not loaded; using insecure entropy" message output during boot on some systems. o The ixgbe(4) driver has been updated to the Intel FreeBSD Networking Group version 3.1.13-k and support for X552 and X550T was added. Also, SFP module insertion post boot, the VF handling of VLANs in the Amazon Cloud, GBIC and PHY power setup (correcting link detected on X540-AT2 after a previous boot to Linux) and incorrect reporting of unsupported flow control auto negotiation have been fixed. Additionally, the flow control and link speed negotiation defaults now may be be configured via the hw.ix.flow_control and hw.ix.advertise_speed loader tunables respectively, with the previously available hw.ix.enable_aim now only setting the default for adaptive interrupt moderation and which can be overridden on a per-interface basis during runtime via the enable_aim SYSCTL. Note, however, that Amazon EC2 Enhanced Networking later turned out to actually still not operate properly with these changes. o The sfxge(4) driver has been enhanced with a SIOCGI2C IOCTL, allowing to query SFP+/QSFP+ module information via `ifconfig -v`. o The UEFI boot loader received several improvements: /boot/config and /boot.config files now are adhered to, multi device boot support works and command line argument parsing has been added. === Open Issues === o The fixes and mainly optimizations to VFS(9) merged in r292895 are known to cause system hangs when using ZFS. For i386, a fix is under testing but at this point it is questionable, whether that patch will also solve the problem for amd64. o The tryfoward optimization merged in r295285 which unconditionally replaces the previous IP fastforwarding option has turned out to break OpenVPN server functionality. For further details see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087 Currently, these two problems are regarded as showstoppers for the final 10.3-RELEASE, making 10.3-BETA3 which was scheduled on a if-needed basis an actual necessity. In 10.3-BETA3, these two problems will either be fixed - or in the worst case - the offending revisions pulled. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-56edd83c us-west-1 region: ami-9c3342fc us-west-2 region: ami-a5fe1ec5 sa-east-1 region: ami-549a1938 eu-west-1 region: ami-20cb7853 eu-central-1 region: ami-35fde659 ap-northeast-1 region: ami-46131428 ap-southeast-1 region: ami-0926e86a ap-southeast-2 region: ami-6fe5c20c === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.3-BETA2 % vagrant up --provider vmware_desktop === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.3-BETA2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.3-BETA2 amd64 GENERIC: SHA512 (FreeBSD-10.3-BETA2-amd64-bootonly.iso) = 90c4480fae117eab1ea59e828cad8696dbf9aa029904249e21c986775b1d64e983c03b8c331bb12555bbba8f5ac85fb9e00338b746e194314542c0ff9b7b4d66 SHA512 (FreeBSD-10.3-BETA2-amd64-bootonly.iso.xz) = c79225ce589955e0c15d71873b4f7a5980682971a0eb2b42f9a3f998bfd294c078d726a1539160fa9083f7190ea8122553c003a84c3b13d0e1a6657714bb6e6c SHA512 (FreeBSD-10.3-BETA2-amd64-disc1.iso) = b6d92eb1603d89433cabae91d052a2a4a7f17e874f585868daf9c8a77730f4c2ed160f4d77d6696200260c816a42bd8cdd59333272299656fe63d8e9a99dad27 SHA512 (FreeBSD-10.3-BETA2-amd64-disc1.iso.xz) = a79629ec1862fe02ce049f6e8b5511f2e6eae8eb58d482ec4b3a4d504fa9adbea07baed5fdab005f4d62ccd07df13ed827349a96eef49ae709d662d87693b29a SHA512 (FreeBSD-10.3-BETA2-amd64-dvd1.iso) = 55e04b87fcc11fe9d23c43e7026c82b49d43ccb513f7fd5b1951134815563faba7c0a9bd9a1656df6e62334253c72fa00cfb19c5bf4e38b2354f363ad569b4ec SHA512 (FreeBSD-10.3-BETA2-amd64-dvd1.iso.xz) = 2293275d1d13b13eef7767ce7a9c34aa5e5f395f3d86c2fb6f706a7ae28ef0e7bef0aa0e9cc4dbd25da38f3a3ba8b9ca230b1a69b711b62a47ec96fdb2f96f08 SHA512 (FreeBSD-10.3-BETA2-amd64-memstick.img) = 2325ac41e389dfbbf7feb78020e77d5340dae5a030e3d802b89ed68a04fc2714a50807b85b62bcd1fa5bcbb3ae7b2c526db41f20223afc2272a6d7f052e5c7a1 SHA512 (FreeBSD-10.3-BETA2-amd64-memstick.img.xz) = 6f6ca6a819fd078d233ee951fb5aa85fa5f72d10743dd63a656291a75f0d5e62b0445a442ab67c62e9c6542b0ad9b660c009655ce29729cbbc6828ae2bc65aed SHA512 (FreeBSD-10.3-BETA2-amd64-mini-memstick.img) = e3914dfa44ae426646f48b7a7bbe40249cdba2a461dd8ed3765505e94c0d926761fb24323319e43172b5a962fcf928e7f8a844768314ad3222ccc33076759cf0 SHA512 (FreeBSD-10.3-BETA2-amd64-mini-memstick.img.xz) = 4a7005b962dca8a4d765c7d98129ff06e81396e6c40fe80c3e34aec3b07b462369bf30fd830cc3126414884059471d208a9151e5ea3c8f82b97ccaf857d25281 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-bootonly.iso) = 0a72446c7478a1af58b6bbc83c0f26359e80f01ea1bfc3c333b1cc59011962da7179ade51381cb32288b4ab7400802e703b6cf98ca9ffac1c573edc30aeb3440 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-bootonly.iso.xz) = c7d970c3a4c56f8d64b825780dbe1f9e79ffa33afd8bded06f303f593efd5133b095715f051d2b2f1d58cbec7cb8c12cea998b9bc7582ce6b184bd53c04019c5 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-disc1.iso) = b3a68d9ce481c5696b19b550cbdd1aea770e69db452211ab6fe6a90e4416499ba914fc603573476b94cd81667ab6dd4cfeaf8be9b304acab32b185363c861566 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-disc1.iso.xz) = e26b47fc5d9dffb8b89573a2d37dc399eba405d0fd981feee1dafd1104055885eb7d4e4272c49daafc85a57888fddce42aced207e88ecce78068f31b20e4e3a9 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-dvd1.iso) = c96176c0573b54b7e11587f58f59f2131d68121de07eab89a3c392a2ad3bf2796aaa4c1cd3a3a40a35029440a35ed5467265164811e7212dc0b4ff2ba5ec35f6 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-dvd1.iso.xz) = 4bfa09c70dc722c6453e5f7835dec5bd87a595f4e05145b1cf663773e665cb59e4dadbc8b8867e48f7bb4e466eddddfb33da8487335bf3e61c259be715909951 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-memstick.img) = 6ef879777b8a1d24e8cd414f7623a759b28b6aabf9b78657261db57131a908df3287de464d1aa70e11e63b1b95163b975c93b5e7bd07147293d1b804440b8965 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-memstick.img.xz) = ac102c4c9c1939fb6e56fc3684c191089a38e006201b8833a6aefcc3cca930ddda8f656292836d522fd7ca58a77958a6b443900c60fedf47232357bb0a5de540 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-mini-memstick.img) = b4c96b40463060cab7f32e069eb0521f769506cd23aa61b3d6c97a64b2fc05c0766eb8798655f0c332f7af53df3ebc1d85cbde6501c17f8f3306ee4a4c525741 SHA512 (FreeBSD-10.3-BETA2-amd64-uefi-mini-memstick.img.xz) = 249e4d7c3c4afcfca039362e812a98d72f0c5496905b361cb8cccb91cae36458d700e692a6f6b1e6ab249d0d755c3cb3ec425c97976e6cfa544fcd6f162b1273 SHA256 (FreeBSD-10.3-BETA2-amd64-bootonly.iso) = a7f470a63313667c0edfef84dfb38bcbf6ccbb1d4d191a4474a1eb00f593ad6e SHA256 (FreeBSD-10.3-BETA2-amd64-bootonly.iso.xz) = 2edcf4a0d98159ff39c1c3c33bdcfcf1b41909d5fdc012d1e9ced9e12b3cd137 SHA256 (FreeBSD-10.3-BETA2-amd64-disc1.iso) = 856d091051cc413a51d4337358bdab55a12c34546b26adf2980d3b4013fbf1c4 SHA256 (FreeBSD-10.3-BETA2-amd64-disc1.iso.xz) = 416b305223e4134b9d9d64dda4827aae3566d02aa5ebcae2d5bc7a172c75d0c0 SHA256 (FreeBSD-10.3-BETA2-amd64-dvd1.iso) = 387ea372ece1e06ae3801307063c4108067fd3b916fbd575c56c35af77f6e96d SHA256 (FreeBSD-10.3-BETA2-amd64-dvd1.iso.xz) = aaf43ef49b13f59ef1d657b565e49e563d6125d0e4fa9b2ae373f9fac2be0120 SHA256 (FreeBSD-10.3-BETA2-amd64-memstick.img) = 193f82141426cf39dd99d4f0c2ca53fa1470c99a9e53f2ab038e4863a3c3c50a SHA256 (FreeBSD-10.3-BETA2-amd64-memstick.img.xz) = c8d70d7910e79b4d22b2cda36042b1efc6aa6515b4f80f5010c733651c1dc082 SHA256 (FreeBSD-10.3-BETA2-amd64-mini-memstick.img) = b2192693b96ae258790673a20a0797eccf894bfc54ad6970b1278379b06d1374 SHA256 (FreeBSD-10.3-BETA2-amd64-mini-memstick.img.xz) = d058ee1579797a2a2eb5d60bd44accf25755d052386d2f123d0a3fb65d15e38f SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-bootonly.iso) = 5ff42074fd69a1ebbbd35ddb83758e72e33f2f0bdf783e0c5e45cca676233d7f SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-bootonly.iso.xz) = f89949e757fcbcf2cb3b1a979eb878cace0dd1b5f530664f8b4bbc77b084824c SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-disc1.iso) = 747cc0f12bcc14baa51e8eed6555d92764f8a82aec1052eb46421068f48b1587 SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-disc1.iso.xz) = 7553dd395522decbefa7c5f133f964ea877c073fbe31c1d48a3a13cd9a208a18 SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-dvd1.iso) = 5b55eec291d1d66cbfaa560b2d20bca7f608a6c2dda6cf3320355da96e0e186e SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-dvd1.iso.xz) = 88dee8478a73914149170ded02eb124c9f36cc787cf3b0f2020792fd190c5d48 SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-memstick.img) = 9da83fecbd0fb6805ad216f30d4e8692419c4f6b7d19f36115a143e87f807d81 SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-memstick.img.xz) = 5baa1837227dd56d17de7a5285add5f993cf398c4197b80dcdcca59799a7d1f3 SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-mini-memstick.img) = 19e59c2b7e0d7c93e7cf1353572ed11b6331ea865780698947ce8ea7257ffcfc SHA256 (FreeBSD-10.3-BETA2-amd64-uefi-mini-memstick.img.xz) = b28f6a9efcaed6012eadd16b50da7079828706aabc72511b821c513f4e1c100d o 10.3-BETA2 i386 GENERIC: SHA512 (FreeBSD-10.3-BETA2-i386-bootonly.iso) = 2744b7448b150bd73de37ca020c52a7389077c2af958d9dc4a93a184b796d9b4a4eb5cc065848ecb06ad8d409262b4934b514c4b95af52623108e23b945ea7c0 SHA512 (FreeBSD-10.3-BETA2-i386-bootonly.iso.xz) = c31adda7d641aeabbe77e1e7871aaa059f8b9e872ff3f75f40d69dc9170a94bb110efe423ce82c8b2e2ace005ca97cf08c9b2f450318900ada9e01fe868a3f0f SHA512 (FreeBSD-10.3-BETA2-i386-disc1.iso) = 42abecdef6601e4717af01feb790380e120291e0e924cc73ea78a6a48d8cace05f1899774848ae15c8a98143cbadea6e76a5f0977c582c76e135f63cd619f9b3 SHA512 (FreeBSD-10.3-BETA2-i386-disc1.iso.xz) = 8b4092f3e4fb0247bac3f37a2f16dce438b957b1eb358a6f349d0a20d04b311e3512f9b87e511779130aa7f5bb4e502c4c35a71ee636da9d5c688822aec7c3f7 SHA512 (FreeBSD-10.3-BETA2-i386-dvd1.iso) = 3a6cbda1869962c429fdc5aef25e905c09ba942e2f79ad467ddf6a1e4d76b032ffae3a2ae1316a860677d600b8d471ba0e7c97dd0519abc61936fc132c85077c SHA512 (FreeBSD-10.3-BETA2-i386-dvd1.iso.xz) = 16e08dc1312b989a0ef75ffba81a57897f1c80abcef02db3ef07e3310696fba749a8f7d4bbeda1a2049cb7f1a3ebf4e7192eef16f98308e9b71fa4a921ccb98a SHA512 (FreeBSD-10.3-BETA2-i386-memstick.img) = e39c61f03126d06e4030ffa5ba4dc7390183ffc24c993e7b6a173fb52991b20f4cf68eb3519f4e49369f72b5d34718fd8ddd2a0244c6042f08a8fd07cef48ea1 SHA512 (FreeBSD-10.3-BETA2-i386-memstick.img.xz) = c522795603779977cd644db0622d0a014784912ce2ee6d3544b8b96cdbde096263b1636eba6b7a73fa060223eb18af8be22cb8b334e3a35630a247b33b6f8d82 SHA512 (FreeBSD-10.3-BETA2-i386-mini-memstick.img) = 9787d636e918a81190836f2b1d49549052d30d809cb57ff97d66dfce6550f81b18b60daa8076d1b241858e53c7944f0dad67d76bdc7df6aed1b1b124b8e75f65 SHA512 (FreeBSD-10.3-BETA2-i386-mini-memstick.img.xz) = 87d6f6ab0e68d32b12a9a39c11fcc244055b2fef89280f7200c41aec5f38633f7e1ecf19f11337fcb6cad579da77f49730fcc3ff6323aa6fc42ae816159bd778 SHA256 (FreeBSD-10.3-BETA2-i386-bootonly.iso) = e1a398cc2988546fab44272d273d84d2ae577efa9886a5f2a65626c2e3eeb6a6 SHA256 (FreeBSD-10.3-BETA2-i386-bootonly.iso.xz) = 47b0acf07a82102929b5d5e08e8ad3835be6502a56a90b3b95efe35dc8676c18 SHA256 (FreeBSD-10.3-BETA2-i386-disc1.iso) = bb5756d8d9aaf69c54f639a60f0ab58ecacd4754af3758f4cbc4e63ecb4cff70 SHA256 (FreeBSD-10.3-BETA2-i386-disc1.iso.xz) = 3b6d7b0a1d7bc2c51b3c215b32af21a5c531b98f450b7094d48019e30248359a SHA256 (FreeBSD-10.3-BETA2-i386-dvd1.iso) = cb877d117f597b89c83a5e54691d04b84a8f356dd226696c8aed77e27b57ebf2 SHA256 (FreeBSD-10.3-BETA2-i386-dvd1.iso.xz) = 9ae774fcbb1c42beabdd2ec2aa3937966891af282cd643711fbac955ef0eba76 SHA256 (FreeBSD-10.3-BETA2-i386-memstick.img) = 4d5447a78834d966fcec0dde1e10c25f49ec49bfbb30d81d5cab23504882ba83 SHA256 (FreeBSD-10.3-BETA2-i386-memstick.img.xz) = 996f04a8c5f76741179d42c7c3e445c571d687444e7c1dab73e105e6546e95cc SHA256 (FreeBSD-10.3-BETA2-i386-mini-memstick.img) = 56da74da88c6f68ad020b7d45e75be5db5be3078677e106f10d202b88f8809b5 SHA256 (FreeBSD-10.3-BETA2-i386-mini-memstick.img.xz) = 6105cbca2c0a5e8039858b47d73380c79d973ad1c5f45318fdb1fd1bb9881559 o 10.3-BETA2 ia64 GENERIC: SHA512 (FreeBSD-10.3-BETA2-ia64-bootonly.iso) = 084ee79e5c88474e8403b95680e06fa773f9754640a96c69fbc4377cf677fe39e43f54dd55971caf37990e74271add61af47c00079844c7a90f9a992e6e93d36 SHA512 (FreeBSD-10.3-BETA2-ia64-bootonly.iso.xz) = 427ed44c1c69fa0be298fef9127dd40c717eca82a3b0d6e5579582a547f916cf80fe3d99988246aa76b30cf6f10c9a7cd7607314381206056b231cb325480345 SHA512 (FreeBSD-10.3-BETA2-ia64-disc1.iso) = 34263f9db3c5f6e2688369677e7503c45390c57b70c1c9722f58d4c78258533bc70e0b62f85dbc79f1cdeeb4a8b30cf70ba967a1d38898440c2579f70f18db4b SHA512 (FreeBSD-10.3-BETA2-ia64-disc1.iso.xz) = 6b219911ba0fe5b4976fcece6f1714f78a1ba7789092c67b5d612690a9ce293ce54c01d6be1b4858b74239baed28a1cafa81f32b337b4940cd4123ce8922d2df SHA512 (FreeBSD-10.3-BETA2-ia64-memstick.img) = 09ab021e741c9f4c841eb22cd42f365012f19705f215747bc91f08c3942e15e37f05f5c763d076d0c4b93e3b69f2cdfe575daef6afa02d45474b917dc2042219 SHA512 (FreeBSD-10.3-BETA2-ia64-memstick.img.xz) = 446226ba2e854cf4ddeb41c7c50790eabfe16a15c8bec59f5fe61512b516efb49c68849878c5c9ca38be9e0392e59b1b8b7650e17beb2985c1b08ea92dafc533 SHA512 (FreeBSD-10.3-BETA2-ia64-mini-memstick.img) = 7caed7b770fabae886026af962fb1447e3ea3edd65ee6ecd8932d0fabe1283ffbccf2bbc70e5fca8ac2abe4be4f10b2ddf9051bf75adeac58524b0ffd3cd998e SHA512 (FreeBSD-10.3-BETA2-ia64-mini-memstick.img.xz) = 119c84d5fdcda6d27819e5da663386e2eaa61df29b2eea7900599772475ab2c585be0f5ac72094eb2784b023cfa178a96edcf892a856e4cc46ad643478819b2c SHA256 (FreeBSD-10.3-BETA2-ia64-bootonly.iso) = 342674ef18e28f68861266dcf10bfdb05ab7aa79feb2cca6353098cf263b0369 SHA256 (FreeBSD-10.3-BETA2-ia64-bootonly.iso.xz) = 67278684dbeeb029c534925789faa33b3abd50be45f8da309ebe8d7247ff91d8 SHA256 (FreeBSD-10.3-BETA2-ia64-disc1.iso) = 8b1b29508e668f0c0cb5b0f454f863dec6c7b7ceafa2da5927abef964a801b90 SHA256 (FreeBSD-10.3-BETA2-ia64-disc1.iso.xz) = e8aad2a131ca7ba0ee85d8b22894fef054ae932ff55f724073f29c84f83fd9ce SHA256 (FreeBSD-10.3-BETA2-ia64-memstick.img) = 22c328f84c09b23e8eed9e4aa0374ef415c07e56989330e9c930d6c849ce0119 SHA256 (FreeBSD-10.3-BETA2-ia64-memstick.img.xz) = b33e581d17e0b2492412f3666d8992b6d0128093c1eb77db51ed50a2f5b0e620 SHA256 (FreeBSD-10.3-BETA2-ia64-mini-memstick.img) = 8c2c1172ddb3a75ee7179644bc117afd0c6cd7440081e8bb5109ce6df6b91d06 SHA256 (FreeBSD-10.3-BETA2-ia64-mini-memstick.img.xz) = 00175f7267edcda6e1977db8c986eb9bfca920a60d8ffcea1aaec494e93cfd6c o 10.3-BETA2 powerpc GENERIC: SHA512 (FreeBSD-10.3-BETA2-powerpc-bootonly.iso) = b0617bde048f449f1ac3a2717b40fd4049557f21e7a8908f18a6964cb0e54b52d5fa31c7deac2377f12c27982dcab07f6d9dc3969618232561219b46d75f73b0 SHA512 (FreeBSD-10.3-BETA2-powerpc-bootonly.iso.xz) = 1faf9945e4fb1bb0e6bff44ab96904f7292b08b69d7db1225901948b9939be4e1acd9189eebdda3716841f4c222c51463355c2901c540c087e1ccdc4f4bea248 SHA512 (FreeBSD-10.3-BETA2-powerpc-disc1.iso) = c3c1ffecb392ce72695b388553de3e8a0a55e50c4064aa1577ae2276c693364ff28134dd00bf96e712120546bac4356a5649fa26ecc82daee44cc0c9a6afdcb3 SHA512 (FreeBSD-10.3-BETA2-powerpc-disc1.iso.xz) = 623664c5eeafb581044967f5e18fe00beddebdf8ff188785ff4747f88414bc82005ccd5ae06d05a8c95012dbd00fe479dcc84fbfcfec92453a09179e9c30ed6c SHA512 (FreeBSD-10.3-BETA2-powerpc-memstick.img) = 018856d32a9f0da29347225b82146b093b841972a7d38436dfc04c1ebffeb90b05a0de7427fcf51086304efb9c23fcb32535478ac61d5f618f11c84ee835b7f4 SHA512 (FreeBSD-10.3-BETA2-powerpc-memstick.img.xz) = 7e763a789682e82396f07f60bf0bb513c7fc0cd417861ad171ef853247573bf1f0b21aa1a3e8f8ebc9ab9fc54be046ec91a225e87969bcfb2c58e9a2ac7b1a38 SHA512 (FreeBSD-10.3-BETA2-powerpc-mini-memstick.img) = 3d543d7ace9ffd84875cd8f3fb2c13f1b32bc7072376a1ea28cb4fc083c7f60fd7b4185796cd4c8e9571f70ea4589c2e96aaf98786586fd235d15a7b6de66778 SHA512 (FreeBSD-10.3-BETA2-powerpc-mini-memstick.img.xz) = 0b36ce832a7575cb3aaae3399c8b6446535c62af4c007d0d9eb2696732abb24fd99a825cf5dc5e013176574e6a4442e445be6e81739ba61bbaab3e35c1021854 SHA256 (FreeBSD-10.3-BETA2-powerpc-bootonly.iso) = bb7476f9dcaff9258b40ce49545720f5021a2d2731a341238a769f9416e9e134 SHA256 (FreeBSD-10.3-BETA2-powerpc-bootonly.iso.xz) = 29ebb6c9c3975ee391c6d450cb51a1bc5afb304ce34f44e9f4e8f6ad84fa02f7 SHA256 (FreeBSD-10.3-BETA2-powerpc-disc1.iso) = 3bef937d4b9d4301c83135045f1febb228d0221a4ea91089312e5a46bf5898d1 SHA256 (FreeBSD-10.3-BETA2-powerpc-disc1.iso.xz) = 0e575239929b1293f597ae441dcd0a4fa3743243fe5fe55bb1c4b62cd98b6378 SHA256 (FreeBSD-10.3-BETA2-powerpc-memstick.img) = 8fd7e8c8cacf963344c27d0ebe9a0ed8d116d61539c6c14e4c755195767715a2 SHA256 (FreeBSD-10.3-BETA2-powerpc-memstick.img.xz) = e8ab5d83dbbf31c199cf021f2914e21d40058d364f7b94de4d80aa5edac8d044 SHA256 (FreeBSD-10.3-BETA2-powerpc-mini-memstick.img) = 578f081fcd3581f7bbd091b8d0beb266b938f08a508c7a1ca1a4910f892c1b6b SHA256 (FreeBSD-10.3-BETA2-powerpc-mini-memstick.img.xz) = c8f01dd3c42a10edb98841deccd9d11f1c32ae7e2126b97725f6d98c8dfa78cb o 10.3-BETA2 powerpc64 GENERIC64: SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-bootonly.iso) = e147baa8bcc7d679fd90c3806b83d8a0ed98ae865f8448785d33d43f1ab362a3e17361829b6e1a164692e09f59ae3ad55a3211272607a60931fc494bb24b6e7e SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-bootonly.iso.xz) = 437c5c93699c7dc955ec0ae9f10a8efb520af17301cf5c4b85ea9274f6f31c48260d08e72e6a19a9418ada778c25056e48116b1619203c5ae8a3cd15b2473985 SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-disc1.iso) = b82a9d0bc27c741707407d37a037f413131cbc8d2bf83fe97c58687886468de4f5f7461d3b30445b4dbf499d63d8337179b256f026c7844621e1311665e3c531 SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-disc1.iso.xz) = b1d7b570a6db7d4ce88d0e09c0f74eeb39ad8494b77d286d745e837756dcd3baba14e6121da9bbdd23eff2cc21c20f3f1e28bbe10e478e91af442f3fd6b2358a SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-memstick.img) = 83b8ea57b5ad38659f44dc25f7ce22618e6d253f4b6566c847517fec87fd0d1e3fcf088ae88a686877c22245fb61f77f94007642c6dca35aff59172423f740ca SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-memstick.img.xz) = 010befad0c50a50322c97ce255b446120288fb4a82bd63a11906d05e5000575ca6d41161d5bd4fbf4975121727d92ec6e7148873fcb4398498ef6368a5883ba1 SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-mini-memstick.img) = 322454b9c332488d0e866de9ad4b651e0311fa28c6ea6d9d251219becd50fa968df14ed116a947f3be8f3e99388aaec5b70c369b7e6f6eea41ac37de7a3b5782 SHA512 (FreeBSD-10.3-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = e91e23b0d7df97f0c7b629a14a35226a8f6b15f1e6dc51e1d2a3955005c0a3ab457c752ae906b2aa41fa176521f4bc2243ab5593b84e6a8f70d52e80dfa77f97 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-bootonly.iso) = dd72bfc98c7d6b7e2d95db231748fad3f8044c7ee24085fc2e608336ef235163 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-bootonly.iso.xz) = ee7440eb5f2e9668eeb21dde8b65909003c88c2d6a644b0ef988376845b10b70 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-disc1.iso) = 1522007852eb97230ca0726151b6b042aeed287b0ab63b3256e4be51407ea94e SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-disc1.iso.xz) = 6aaa76b8c5b290872b2afa951bb0232778eea6f29f383e379c13000c0b327cb1 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-memstick.img) = 8c6f336b09245dc4802c646465c6aaacb04984e2f6a9bcf85cb1bf8b523a4851 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-memstick.img.xz) = e1684c106674d458997be69775018af8570a8ab0593985c222ccbeaf4f7e3357 SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-mini-memstick.img) = a174f3dc03b843b0287b3298f4b1a980d17f434d52b22888027e1774732e409f SHA256 (FreeBSD-10.3-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = f4ab4fe752cc21f7bacb71768f449aa22815d505064476719226379fbfa6e158 o 10.3-BETA2 sparc64 GENERIC: SHA512 (FreeBSD-10.3-BETA2-sparc64-bootonly.iso) = 8167e8ddbc0c104ed7884ed55f515e4f6d21d5639aa33abfcc14225ff19edbdeb653fd029975177ff3c320188b163263f75fe25a1003242ce159c1dbc0e3e58b SHA512 (FreeBSD-10.3-BETA2-sparc64-bootonly.iso.xz) = 309b1b020f529469668583f948cff480c2e8f46e518c9010f9e8ca3044dd8380b81ccbfa3465de0184b9e14e687b0dfa22aa2c861ea2087774e58a24764122a6 SHA512 (FreeBSD-10.3-BETA2-sparc64-disc1.iso) = 0d153c375b81bc9cf27785fbc912fe2e451eaccb4a9659c4163d76b3e039bdba823a3d5453e35626bfd9146febfe48e0a1d2d6730437d937941118296e953c37 SHA512 (FreeBSD-10.3-BETA2-sparc64-disc1.iso.xz) = a886253b2c43dc283d7772d9e754f5116d05a8290f4f116770eeb3115158b1f83cc2b405c55da02c8ed3152e0119d335e3345dd41aa118829814bcb6b315b0c3 SHA256 (FreeBSD-10.3-BETA2-sparc64-bootonly.iso) = 69235e0fb990e80d30880c486521e2048dbed51cbe6d099de8d441bbc9ac2ef8 SHA256 (FreeBSD-10.3-BETA2-sparc64-bootonly.iso.xz) = 014613334f6bd8eb8b931020c769e2a06816929b9db8c4f0502c4a4b36079b8d SHA256 (FreeBSD-10.3-BETA2-sparc64-disc1.iso) = 7a3cdd7fa2fe4e73c26dc074d5c6ad919568491243dab76e346efb382a874285 SHA256 (FreeBSD-10.3-BETA2-sparc64-disc1.iso.xz) = 0420c132d3f3a4c03c7d51a5c8f3a9abb56ea070d73f851788902234137f3dad o 10.3-BETA2 armv6 BEAGLEBONE: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-BEAGLEBONE.img.xz) = f458777100499fe53e5b379ad3b881494a07e4e5246ca88616186b5b705af89ecf49e0afb6da7c149c9dea238b9970a458e0b71c2c0269ea09bcce62f4950b61 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-BEAGLEBONE.img.xz) = ad044306fc344123f924155c1e0dce9b6a07d8dddf6fdc7f587ffec3b31ef585 o 10.3-BETA2 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = f723f442b3d5f6385ce7939d72221d355f541314d3f48603b46889784dd99911c1d6f06d2c347f0f948ce9d478fdeaf365b1adbcb52557045da4e66d0c945d24 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 905f2ec57088e92e0f059ec1ee4797f6f29e57b799c3c6995edfb61fdee79626 o 10.3-BETA2 armv6 GUMSTIX: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-GUMSTIX.img.xz) = c46849434368c1ac7172634c56757185e477d93b3f09c0e234741a9c9e6d78c4af592d08dc698ed8607edbefac664435188be479d6b6c1600b95749abca91da8 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-GUMSTIX.img.xz) = 8524d8f43df872ad4f5463dbb1168c5e314ac74a494bd21bda5c7bee28245740 o 10.3-BETA2 armv6 RPI-B: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-RPI-B.img.xz) = dd6d747d89181d5454b235216d19d5f5e3863ccd40109e440dbb4e6a468e937819629d91448c1c1a8d65aadc8ce1062cec96f061623256d7933014d1b5951de6 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-RPI-B.img.xz) = bda3976d63d5d79d4b7d45b6621c12ce930e2688b3c0bde5c59c4fe6dbf8f87c o 10.3-BETA2 armv6 PANDABOARD: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-PANDABOARD.img.xz) = 86cf257f5122db359edd87bdf1a3c5156f3f64483e84b60109868e24d7d7ff58a55ed77f1cef4225a313b2eb120fb2bd5d8586b357cee41d08d7b5d2bc8028f9 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-PANDABOARD.img.xz) = abac330abdc52f456e02452002948bb40688c3fa966f4085282adb75ecc2d275 o 10.3-BETA2 armv6 WANDBOARD: SHA512 (FreeBSD-10.3-BETA2-arm-armv6-WANDBOARD.img.xz) = 7c090d31b1be18a88a1dcf45c6847759f5b011baca7be37058e4b551a3587c3f7cf8523ed5f3057d71f3f1b34f2cc318acb3dfbfbc686e5cb45d5a4e714e2103 SHA256 (FreeBSD-10.3-BETA2-arm-armv6-WANDBOARD.img.xz) = 7cfaf5e396f216968aaa62b1fdd609fdfc5186ddda3e9fe65655ecfffba322b8 == VM IMAGE CHECKSUMS == o 10.3-BETA2 amd64: SHA512 (FreeBSD-10.3-BETA2-amd64.qcow2.xz) = 775dee29d4b01b76afb6ae5f51523d9284e1233f7988f81e8ee3be06770983e8e7bcc5f68c850a9c15c84d8965fb52d1bd7830aa684ba080dff4c91b075b9dc9 SHA512 (FreeBSD-10.3-BETA2-amd64.raw.xz) = 973c908b63b11f087f41329b6476a23b5facbd823c2416d5c7b66111c6a36d56a54f0ddc1c5754d599d6798a806b1adbfc8e93b7c5e9c2f639b4b9457322d49b SHA512 (FreeBSD-10.3-BETA2-amd64.vhd.xz) = 0aa6cdda673badcd12c09421983aaf255c2c7224f8b9f4b442b65374c2bc2b5d554f1f202bf5f121fa5d46e56b66abb28c0e3e217cfffead37df09989aba345d SHA512 (FreeBSD-10.3-BETA2-amd64.vmdk.xz) = f33d6f57757557b4b71b50bf114fa59dcdd15136ad1e64f67cf83cfaed9f3f09814a355db2142aaef88974070a2b7e546346a9528c151780648863d59394eca5 SHA256 (FreeBSD-10.3-BETA2-amd64.qcow2.xz) = 8929a8f6ae2f0b1a44e09a5ad1804e94ffbccff4c1053dcadfa89af9d670bbc5 SHA256 (FreeBSD-10.3-BETA2-amd64.raw.xz) = d564d26f25f9543580a4708f68c37f45e901bc34c79b7e9b044526bfcc30459f SHA256 (FreeBSD-10.3-BETA2-amd64.vhd.xz) = 95d724c0998dffb5951175c738015fd6819aa400010d585b02ecbb52d2bc0458 SHA256 (FreeBSD-10.3-BETA2-amd64.vmdk.xz) = c59ae786bbfb4139a7f07be3368a2f6a2d2f9b319edfb7dfbeeaa40eaf6395f9 o 10.3-BETA2 i386: SHA512 (FreeBSD-10.3-BETA2-i386.qcow2.xz) = ed8709aa5c2f143c540c18dfad459e8b67b0482c1429d15bfa6045563d83f6953eb271900fb7c32971b81c0aa538bebc5033e64fdc2414fc0040dba7abcf33b4 SHA512 (FreeBSD-10.3-BETA2-i386.raw.xz) = 1d1f11ae74cb267d7e92d7ec896f8bf0bd795a79ddd7c269010dbb98c7b57ade5ded1d86f7b9566cb8bfcd979e4ee0026683eb61844a1af683d746e1e27f4078 SHA512 (FreeBSD-10.3-BETA2-i386.vhd.xz) = dac483973ff81e3971565a260e859fd206286b43a506d3a1d343b25771290141859c988b1b17c6189fb59e6dbaab130d903423d40f0c7e7358ee4814732ee86b SHA512 (FreeBSD-10.3-BETA2-i386.vmdk.xz) = 3472ae1c78fc73831d28556a3baa28eef77ffce1805d06da5dec98bcb8a432e7435b2e43192ea9950ce4b90264bfe944d35367c4a5a8e609f358c240e8af3c9f SHA256 (FreeBSD-10.3-BETA2-i386.qcow2.xz) = d255aca313614e1fe4752cedc1100a7126bb1d027584d2618a442d94ce19aadd SHA256 (FreeBSD-10.3-BETA2-i386.raw.xz) = 37e4e7a0d1c24f786826920bb0df175d3c378b8a5bd62a5ade2d2fdbe8cb366d SHA256 (FreeBSD-10.3-BETA2-i386.vhd.xz) = 92446fcebdd32cc57777d43dcb730a2c35a19ab76b6a19faecc8fd4eb606df28 SHA256 (FreeBSD-10.3-BETA2-i386.vmdk.xz) = c6ccb7f76778e6fcfce5222d0c0d458751a3148eb6881448bd2d53d0cf904e97 Regards Marius --PkEWctFf+8E2rcii Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWwK5TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5PdCEP/RdOhfw+0QldYcrCzb5k2pZC XH7LiEDlMMFIiKNi6Y5EjBifRgu5tThSYLhy4IacHwVHklm0c+hpMuK0Yq6ApNUv W8/p9FA6PK7huzFxjdqcOcm/WNHI9PECq7V7R1aEv4etm+36F7llv1INkWJXCt8o uugR1fk7dmvx6qCHVSNE0SdJnZ05xmv5MKXoSmsnw17dTHO1/EZepL7cDEL/+IuO NDZ3qGCHxw+7cbWArD1G/lPUPXJTigs/Qjt164rP0fRPZ9vG6KH1XH39SEyIPyFc tbfuox5+0uWWmacOHg2lRG51sjPs9NSX3bgLZOjSP4MmqUlS23ax5FHHpg9C5PX+ EE/Q1Y9/IRpXpWH28xzV4vXZmIwSWzFv81Duw+KCzLzH0WUJdb1CyQZ/Xrz7zmto yEy+r3RizxZMxdTU2/z8JJYzQICBJgwCvlr7khx5q7gk5XTKQvJoQZnWyraiPBX/ VloE3L9LOBsg+7mzmGAuFeHGPiCxaNXi5Ulp1W6A/+mss+sLdVj43VZQyDfsfuV5 n/wEOcx4lEOIv3Ug12nR55vkydDtKBsIT3avC6/6h8A/vhMl6hOP7w9NUtruQxBI K3TtbxXJTJBYOL6czMzvCOIofOH7FQgcSqngRnGauP55qkyJUoV2erEOT857WsaN HR+UKNKlzAjGVb0R4gR0 =D4Ku -----END PGP SIGNATURE----- --PkEWctFf+8E2rcii-- From owner-freebsd-stable@freebsd.org Sun Feb 14 21:42:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D5E7AA8EA8 for ; Sun, 14 Feb 2016 21:42:41 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64AAF240 for ; Sun, 14 Feb 2016 21:42:40 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aV4R4-00021i-99 for freebsd-stable@freebsd.org; Sun, 14 Feb 2016 22:42:30 +0100 Received: from 114.165.187.81.in-addr.arpa ([81.187.165.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Feb 2016 22:42:30 +0100 Received: from mnd999 by 114.165.187.81.in-addr.arpa with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Feb 2016 22:42:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Mark Dixon Subject: Re: Is UEFI required for ZFS? Date: Sun, 14 Feb 2016 21:42:24 +0000 (UTC) Lines: 20 Message-ID: References: <56BDFAA4.17139.1EEE35@lausts.acm.org> <20160212185659.GC26283@home.opsec.eu> <20160213100936.GY91220@kib.kiev.ua> <20160213170239.GD91220@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.187.165.114 (Mozilla/5.0 (X11; FreeBSD amd64; rv:44.0) Gecko/20100101 Firefox/44.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 21:42:41 -0000 Konstantin Belousov gmail.com> writes: > On Sat, Feb 13, 2016 at 03:46:16PM +0000, Mark Dixon wrote: > Might be, try the following (mostly debugging) change. > Tried it, the only thing I saw different is after the menu I got: rd eef611d6 Hope that helps, Mark From owner-freebsd-stable@freebsd.org Sun Feb 14 23:00:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E33CAA8D88 for ; Sun, 14 Feb 2016 23:00:17 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by mx1.freebsd.org (Postfix) with ESMTP id CDA9713DD for ; Sun, 14 Feb 2016 23:00:16 +0000 (UTC) (envelope-from lausts@acm.org) Received: from [173.88.10.122] ([173.88.10.122:33111] helo=mail.laus.org) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id AF/D7-17124-FF601C65; Sun, 14 Feb 2016 23:00:15 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id u1EN0EN9003255 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Feb 2016 18:00:14 -0500 (EST) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host laust2 [192.168.1.100] claimed to be [192.168.1.100] From: "Thomas Laus" Organization: ABB To: Yamagi Burmeister , freebsd-stable@freebsd.org Date: Sun, 14 Feb 2016 18:00:09 -0500 Subject: Re: UEFI & ZFS Reply-to: lausts@acm.org Message-ID: <56C106F9.7785.139D57@lausts.acm.org> Priority: normal In-reply-to: <20160214132749.efba24a6855e37855d3cbaa9@yamagi.org> References: <56BE423A.12522.27C542@lausts.acm.org>, <3F76A980-AD77-4C77-BC0B-1B60D2351721@cs.huji.ac.il>, <20160214132749.efba24a6855e37855d3cbaa9@yamagi.org> X-mailer: Pegasus Mail for Windows (4.70) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 23:00:17 -0000 > I've observed the slowness only on the local console, I haven't tested > the seriel console. Put the FreeBSD legcay installation usb stick into > the box, select it as boot device and watch the cursor spinning for > about 10 minutens until the kernel boots. Do the same with an UEFI > installation stick and it's a matter of seconds... > > I've seen this on an Gigabyte GA-Z170XP-SLI with a Core i7 6700k and on > two Supermicro X11SBA-LN4F based machines with Skylake Xeon CPUs. There > are several other reports of slow boot on Skylake CPUs on the net. In > the thread mentioned below some changes in the hardware, the firmware > or somewhere else were suspected. I didn't even try to debug it,instead > I went with the UEFI loader. > Yamagi: My experience is the same as yours, but only with the combination of Legacy BIOS and ZFS installation. UEFI loading of a ZFS filesystem is also a matter of seconds. So is a Legacy/GPT/UFS installation. I only see this on my i5 Skylake when I perform a non-UEFI instalation using the ZFS filesystem. I get a rapid boot with both OpenBSD 5.8 and using a MSDOS 6.22 USB floppy. I have seen some patches posted to this list for testing. I'll report back with my results. I can't use UEFI because this will be a XEN server and UEFI support is not in the XEN kernel yet. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@freebsd.org Mon Feb 15 09:06:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD197AA65B3 for ; Mon, 15 Feb 2016 09:06:10 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 49F5615F8 for ; Mon, 15 Feb 2016 09:06:10 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id a4so46379068wme.1 for ; Mon, 15 Feb 2016 01:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=u4O93AXk0zU/9nf4avsRZWRZ+oEv0wyz/HCoWpxUU2U=; b=DWV2Ane+kNac4i6VOhphI8SUtN0yCt3W7pFx0cQMYkfrMVnvz/gZtJDGenH/wavfqX 1A2JQemyCLdC7Kz5wwj/XQkkQSGaSYdhES8lRS1qCJiyM7teGLPjGtIxo+insP8FM44p rbxX5Dj5ttscggCNTd7roOJi4pyfKyeIajgqGGFvKAWQmjdyLD/wWB1AVzSKGOYeMOYI iRMxy4F4CF+0+ddKla9Y1glAK+Y6OcMn5W3+om+CA/WHeriqpKrHvYli2gSK09nVlA3h kBxJhN1/G0SnPgiAQa+ODYnFkf/mgrk9OAJV8rEhYqIqcnRVshXUxoAgk0LUR3bqF8K2 hR5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=u4O93AXk0zU/9nf4avsRZWRZ+oEv0wyz/HCoWpxUU2U=; b=eAm+2qxwBk/Y9hEDBCuuSi8congb6dYqHuktQJMrcBJ8q8SiF/bAK7WUyMWUB6nfPX icBYFeDEvAWksvAx8EtQoFlXHmPFzoWSO1ra6EQGSei3suV4iT0jiWTc8Xbrzg1VEq72 5lxyDozMVQO7bTYy7SOo6kS77yMQcqhuY3DSa0kDxoHyT4leX3hhyM/ObXRg5LtFDeAB 3byXaKVZmggXanNjMwrIud9+SvvYOl2mqHHDOwRBVTd7uUmUEr4o5NxYASM14UofoZrc RdH7KSDfO9eRbuj4NF60x5qiVjb8lfgOt6MJffOLFXTpW3YZu0ymVj1Zkaz40+py2+7U dN6Q== X-Gm-Message-State: AG10YOR5H9ubafu60gSUaC9jX7wXLPdzY5N16HXUlmpr+rePd/xMTVHZIbyaTCVEiAoBD9ZVzCry9NMz0RMDZQ== MIME-Version: 1.0 X-Received: by 10.194.184.50 with SMTP id er18mr16869111wjc.160.1455527168792; Mon, 15 Feb 2016 01:06:08 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 01:06:08 -0800 (PST) Date: Mon, 15 Feb 2016 12:06:08 +0300 Message-ID: Subject: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:06:10 -0000 Hi! Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? Seems like net-im/skype4 missing some dependencies and if it's satisfied net-im/skype4 hangs after start. linprocfs mounting doesn't help. I installed them all from the ports tree. Any experience? From owner-freebsd-stable@freebsd.org Mon Feb 15 09:24:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A98DDAA82FE for ; Mon, 15 Feb 2016 09:24:22 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69E3811DB for ; Mon, 15 Feb 2016 09:24:22 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by mail-wm0-x22b.google.com with SMTP id c200so103193007wme.0 for ; Mon, 15 Feb 2016 01:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to:in-reply-to; bh=5ZEB4nNahTx7UdO1h/3f32o5WPEALov0sR87DsxSXjs=; b=fkyTLJECL/TXwWc2gJZwJyu3U3oGgI2RX9TTADwWLL/pUXvyxySd/fXSKx0eEqsX5l sw9/W2a9sw+BPykJma0T41FQKS8YwjRZZxTqlEX88hIyLaj1DOXiqUtA8bURii1smp+o kG0OlPnRmJZRk6W5Utc1UFrqQfVtvekVXFEiGtSUFfr8yHQevVV5oSjb45PtkACGMyCM FbSYrokLteP/GyxCJaw/aWu8601TssKQuyXZEVm5BEbWddzUB3IuVkz6kcJzQXTBXQlA 61Go1/tRkybCH/6o8ffmGBskWN63piNYgUAWLYx9lwTJue+wfjmhSdmmGxc/lOQ/vxJY FcrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to :in-reply-to; bh=5ZEB4nNahTx7UdO1h/3f32o5WPEALov0sR87DsxSXjs=; b=gut+pvoycI9pk2DMWbiRiR1YMI1HaBSlKk/hc2WYMd7IgVedrEaexwxRnRmu3vKLph lIVWIFHShwJfwStEXECfeDzsX7gDOHm39OAn2dSkq9fBzk29Jf1p6N/d70tqJxJKfnTZ GQQQdh3iuCUxt0y+NJ3f+LRagGn0+PHnoZXzJNIsL2IopiLQyTuWrGtC5TEvV/KygPQl W04R5ucgtGO6cwWiMT8PhhfG0utVF/f/3PnwTjcqYvr88owRKy6u+YnpttZarkcHQYDh BLcu1G5VUSVpSP6T1txXOizvgwEQtyiEL/mzGSoaUlhOsqZQwq/LjxlvNgCSKn34KNeW oTUw== X-Gm-Message-State: AG10YOSTw7LhqXviiAXfOnSC0kmzmYAoamOU33lfu5BWUi5/Xgo3lUmDRO/hoMsCrHuS3KZ5 X-Received: by 10.28.107.140 with SMTP id a12mr12300691wmi.77.1455528259739; Mon, 15 Feb 2016 01:24:19 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id ks5sm24354225wjb.13.2016.02.15.01.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Feb 2016 01:24:19 -0800 (PST) Date: Mon, 15 Feb 2016 01:24:19 -0800 (PST) X-Google-Original-Date: Mon, 15 Feb 2016 09:24:18 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id u1F9OIWv046905; Mon, 15 Feb 2016 09:24:18 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id u1F9OIgB046904; Mon, 15 Feb 2016 09:24:18 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201602150924.u1F9OIgB046904@mech-as222.men.bris.ac.uk> To: freebsd-stable@freebsd.org, timp87@gmail.com Subject: Re: net-im/skype4 under FreeBSD 10.3 Reply-To: mexas@bris.ac.uk In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:24:22 -0000 >Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? >Seems like net-im/skype4 missing some dependencies and if it's >satisfied net-im/skype4 hangs after start. >linprocfs mounting doesn't help. >I installed them all from the ports tree. >Any experience? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202780 Anton From owner-freebsd-stable@freebsd.org Mon Feb 15 09:44:37 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43450AA8E27 for ; Mon, 15 Feb 2016 09:44:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D03B21CEF for ; Mon, 15 Feb 2016 09:44:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1F9iStu087999 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2016 11:44:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1F9iStu087999 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1F9iSMH087936; Mon, 15 Feb 2016 11:44:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Feb 2016 11:44:28 +0200 From: Konstantin Belousov To: Mark Dixon Cc: freebsd-stable@freebsd.org Subject: Re: Is UEFI required for ZFS? Message-ID: <20160215094428.GQ91220@kib.kiev.ua> References: <56BDFAA4.17139.1EEE35@lausts.acm.org> <20160212185659.GC26283@home.opsec.eu> <20160213100936.GY91220@kib.kiev.ua> <20160213170239.GD91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:44:37 -0000 On Sun, Feb 14, 2016 at 09:42:24PM +0000, Mark Dixon wrote: > Konstantin Belousov gmail.com> writes: > > > > On Sat, Feb 13, 2016 at 03:46:16PM +0000, Mark Dixon wrote: > > Might be, try the following (mostly debugging) change. > > > > Tried it, the only thing I saw different is after the menu I got: > > rd eef611d6 The value is reasonable. The fact that the patch did not worked means that my guess about malfunctioning bios pause was not correct. I do not have any other out of thin air ideas what else could be wrong, right now, the system must be investigated to diagnose the issue. Thank you for the testing. From owner-freebsd-stable@freebsd.org Mon Feb 15 09:47:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57428AA8FA8 for ; Mon, 15 Feb 2016 09:47:22 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E52791EE2 for ; Mon, 15 Feb 2016 09:47:21 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id c200so104142070wme.0 for ; Mon, 15 Feb 2016 01:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pja3Vx1IS7OXevHrX1SBX+2y4RiJf+COSoAJ4KqKxQY=; b=bFAEPDw+d3Fvx8eH3n+r+RxG5Pgx1F/w1plRW6oDH3vTi25yDxUrhD8i7vlQMijHkD 5mNpDHs0Vz59kJ9O0yhcxmRFNP0b8pGxSXeHEgwzfPjHDb371eD0m273pPNP1Hr8JGxO H4eleDOCWNcij0X2aGvM1lZRQdhQhphAHkA3glWu0HXHVj7Bc9UEMcODhHCVQVM2eJy0 AsbGvSSKKKRn8AFPuDnmLDic/VGiEBFkj4iZlOLF7uzsN3ZD05FCFdOEImSctsSD0h56 WYy5KE0inrtAky0BWTr4XMVThDO3FJEL+9Jj4WtMC6+sFaAXIuVzOtrBH04KR9wjxerh oreQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pja3Vx1IS7OXevHrX1SBX+2y4RiJf+COSoAJ4KqKxQY=; b=DYWwMg7ysAng+fwPdfi3qIPzl3AU3k1m4HEbNKTFu5oJ8CBiylB1sav7BDa1fNYOUC Z2g4QKaCuDF/waYvNjlJcfroPscHkSD2rt9t7Zzn7m2dyNDASNuVSe3v7rrA0L0Uk1K8 gkJsY5CAClIPQGifTEcZmc37+HIfZHwmp/gf2uz9yb9WCrynKiRSBMQ5TciQFShjGpSa GRTxCZB3DMpxylbyDXHFWIjlHwnTU0FwbCQME/A+fCPQ0BJRIqkhjMMCjYrdRSD5Co0m sY0j8nC9GjFi1iYQ8MYYXQZQL4837RvWVnIIa23cmMc0tYBF20A2CIYXtSK/rDXi9yuL 27fw== X-Gm-Message-State: AG10YOSHAy5JLZZfvvSxWHwTE4SiRj9hogv1qCBd4RerDYFRfZhFfpjzXu7g4/0RigDOtf7j0nq/3ox2qshHSg== MIME-Version: 1.0 X-Received: by 10.28.30.198 with SMTP id e189mr11059168wme.60.1455529640433; Mon, 15 Feb 2016 01:47:20 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 01:47:20 -0800 (PST) In-Reply-To: <201602150924.u1F9OIgB046904@mech-as222.men.bris.ac.uk> References: <201602150924.u1F9OIgB046904@mech-as222.men.bris.ac.uk> Date: Mon, 15 Feb 2016 12:47:20 +0300 Message-ID: Subject: Re: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: mexas@bris.ac.uk Cc: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:47:22 -0000 But isn't 'CentOS 6.7' is already in ports tree? 2016-02-15 12:24 GMT+03:00 Anton Shterenlikht : >>Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? >>Seems like net-im/skype4 missing some dependencies and if it's >>satisfied net-im/skype4 hangs after start. >>linprocfs mounting doesn't help. >>I installed them all from the ports tree. >>Any experience? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202780 > > Anton From owner-freebsd-stable@freebsd.org Mon Feb 15 09:50:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B995EAA9204 for ; Mon, 15 Feb 2016 09:50:44 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EC0B10F9 for ; Mon, 15 Feb 2016 09:50:44 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVFnn-000Cvc-1W; Mon, 15 Feb 2016 10:50:43 +0100 Date: Mon, 15 Feb 2016 10:50:43 +0100 From: Kurt Jaeger To: Pavel Timofeev Cc: mexas@bris.ac.uk, freebsd-stable@freebsd.org Subject: Re: net-im/skype4 under FreeBSD 10.3 Message-ID: <20160215095043.GJ26283@home.opsec.eu> References: <201602150924.u1F9OIgB046904@mech-as222.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:50:44 -0000 Hi! > But isn't 'CentOS 6.7' is already in ports tree? It's in HEAD ports tree, but probably not in the quarterly. Can this be the cause ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Mon Feb 15 10:09:13 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F085AAA9B41 for ; Mon, 15 Feb 2016 10:09:12 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 C0A8F1AEB for ; Mon, 15 Feb 2016 10:09:12 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qg0-x22a.google.com with SMTP id y89so107036335qge.2 for ; Mon, 15 Feb 2016 02:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U/qAtX4MYBqqDKNidTu8nlUi/k3wNv7DLi+BJGDAuqI=; b=J+haWcCFdFpAdOqe0OpHWSAHxJ2RLljlNKYp2gk+yHu9kh0tvcurBNqeLmzV0hxr+F 4p4ZP2mxRPglln7yGEJw9aaHnx2VPdYjLVUi3Y9iR7faGwjnUcmDtskQfYGB04bBfX50 zkEr7nxsWR8HvYdHe3VpCo1W+Mwmou0muGMFUBWbMT0SuuqaTkvDIgw9s6uMxVaNcaUg td+Sz1psxIU3U574osC6wOBr4sCqtIsEEtBiotX8L0alHB2vNzuIPknrf+jUIngOmlqz oMDULCcSK6S6vERL5ni/gScknnL1lUS8QucTawnU0FFoURy9mSOBbmiWMBPSf8ep/Vv4 P6Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=U/qAtX4MYBqqDKNidTu8nlUi/k3wNv7DLi+BJGDAuqI=; b=e7yEL9zgVsOwZpuB4GMWIIe71tZjf44OP81HOrk7V6IfZF02kSbNofRXYKUKwQvYY0 pL6hIaqsaNTXPI8trJ5BBDBQHPRSeAFZppUjZy7Us8NfhSkOMSQ/Atfifmh4Ee5jPBQQ Of4uOVU11GCgRImSPSteD5GtVtXqupKfNmurt5FNxPTVwWkth8SbihKhTe15uO5jG18f e8KCs9XPh4G4ZJLJ+z807uFLXTooHBcXoWwKOV+/+W1SxPpBaGKRmDF7zaj+lwY2m0IE FzfuG/ej7387T79fmMZd+TtFpS5BPCn04benVMwA2qTzjF4QEI681abPZ5KNUV3Rgm7K aKaw== X-Gm-Message-State: AG10YOSXkqUBJ/M/NGQuYUdbilZkp+fxDg56231GXDz+n400NiVanwaZxx0ML0Gfvc/MuQ== X-Received: by 10.140.20.39 with SMTP id 36mr18825789qgi.15.1455530951880; Mon, 15 Feb 2016 02:09:11 -0800 (PST) Received: from mbp.home (179-125-138-231.desktop.com.br. [179.125.138.231]) by smtp.gmail.com with ESMTPSA id e34sm10795182qga.4.2016.02.15.02.09.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Feb 2016 02:09:11 -0800 (PST) Sender: Renato Botelho Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: passwd and pw speed regression? From: Renato Botelho In-Reply-To: <56BCA298.9060000@sentex.net> Date: Mon, 15 Feb 2016 08:09:36 -0200 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <397202D9-9A58-40D9-9759-EBE54184835A@FreeBSD.org> References: <56BCA298.9060000@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 10:09:13 -0000 > On Feb 11, 2016, at 13:02, Mike Tancsa wrote: > > I noticed that on a new RELENG_10 box we are building, password updates > are taking a very long time to build. On the old RELENG_8 box, doing > something simple like adding a user > > # time pw useradd test12345 > 0.062u 0.063s 0:00.14 85.7% 54+988k 196+134io 0pf+0w > > # time pw userdel test12345 > 0.164u 0.044s 0:00.20 100.0% 28+1181k 0+18io 0pf+0w > > > On the new RELENG_10 box, > > # time pw useradd test12345 > 0.060u 0.120s 0:58.89 0.3% 58+146k 12+6485io 0pf+0w > > # time pw userdel test12345 > 0.125u 0.133s 0:58.80 0.4% 46+214k 13+9326io 0pf+0w > > > # wc /etc/passwd > 6113 14792 376128 /etc/passwd > > > Yes, almost 60 seconds to add a user to the password file? > > Does anyone know what is going on to account for the large difference > and how to work around it ? I am guessing > > https://svnweb.freebsd.org/base?view=revision&revision=285205 > > is the issue. Apart from keeping local source code changes, is there not > a better way to not have reasonable speeds ? A possible solution is being discussed at https://reviews.freebsd.org/D5186 If you can try out that patch and provide a feedback it would be great -- Renato Botelho From owner-freebsd-stable@freebsd.org Mon Feb 15 10:14:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8203AA9EC7 for ; Mon, 15 Feb 2016 10:14:21 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 709581FC0 for ; Mon, 15 Feb 2016 10:14:21 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id g62so142138030wme.0 for ; Mon, 15 Feb 2016 02:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uJzcMVInvIYfzW4ZEjXSk/kX/pfCJ/hQLFsXzSct8RQ=; b=gZmQ29XtgMHVWFFWHvOEBJMst9rbQDsLt1TBZYMogcyNGslpv6yCQ1KBvnrtG/lebF F/jVnXspWmSvTqFR7VnpErzjzpHldINt0oUwAH4pcVnoXm722LRydpKtodXOcmfvRFdG ewxpOMgteXYqXVSi0ZCFYGL/3gQMkL7Acr8xFdWjCsWmfWxEDfa4wRC3gknuaQ4o0nrH PUza61h9vt6w6ZoR/1lPFbM6RjPKNA5VpXHyBJN0BdDI32VklCuzaeb22P0PRKw2VmUa ZuGgmoE6rr28l1EAAG/JbG+XFa0BimL6IhIXgy0xuQ9TAKOV4cIYlwbRKW3wLL9Z+x2u HE/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uJzcMVInvIYfzW4ZEjXSk/kX/pfCJ/hQLFsXzSct8RQ=; b=QGCq/fyyBWbD/DB7lYS4IBkL4hXXrcF3fJMBbxAT2swZ0QmppO+pYufYAvznacsMNS rxkhrGCqf8gDVj/YzVHQxDByr//pnS9o+CufFsllcP80XjxJlcBEJloEMN7D+1dSN66Y 7JAaWoJHwfCw4+CviMQHQnv/B++EnMqP/Rz0peyTWMWnZPb60ehxwkdcnPwz+feEIam7 3yU48UnR0mRNpZqEBV3KnMv66ePJL9abpyyHbOCrvdLAEho7+3w9a04oXVwtEBxDfiD8 PGB1SYW87HwNRRUmNG3VGgZd9/3J8mcpkcNcRkDHldd2iNCikS2OhLSH20er6KOjftqi bERg== X-Gm-Message-State: AG10YORCxP79ZcGBJpa8gmy230pZZca3OiHfGMYz6+slAblIKLClsv3eoltmjAgIa+yRlS0Esh3sUX3foYsuBQ== MIME-Version: 1.0 X-Received: by 10.28.127.5 with SMTP id a5mr12368379wmd.32.1455531260035; Mon, 15 Feb 2016 02:14:20 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 02:14:19 -0800 (PST) In-Reply-To: <20160215095043.GJ26283@home.opsec.eu> References: <201602150924.u1F9OIgB046904@mech-as222.men.bris.ac.uk> <20160215095043.GJ26283@home.opsec.eu> Date: Mon, 15 Feb 2016 13:14:19 +0300 Message-ID: Subject: Re: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: Kurt Jaeger Cc: mexas@bris.ac.uk, freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 10:14:21 -0000 2016-02-15 12:50 GMT+03:00 Kurt Jaeger : > Hi! > >> But isn't 'CentOS 6.7' is already in ports tree? > > It's in HEAD ports tree, but probably not in the quarterly. Can this be the > cause ? > > -- > pi@opsec.eu +49 171 3101372 4 years to go ! I used HEAD ports tree. From owner-freebsd-stable@freebsd.org Mon Feb 15 11:00:31 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D81ECAA9610 for ; Mon, 15 Feb 2016 11:00:31 +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 9849B125F for ; Mon, 15 Feb 2016 11:00:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVGtC-000E8X-VL; Mon, 15 Feb 2016 14:00:22 +0300 Date: Mon, 15 Feb 2016 14:00:22 +0300 From: Slawa Olhovchenkov To: Pavel Timofeev Cc: freebsd-stable stable Subject: Re: net-im/skype4 under FreeBSD 10.3 Message-ID: <20160215110022.GE37895@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 11:00:31 -0000 On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: > Hi! > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new linuxulator import). Chat and voice work good. > Seems like net-im/skype4 missing some dependencies and if it's > satisfied net-im/skype4 hangs after start. > linprocfs mounting doesn't help. > I installed them all from the ports tree. > Any experience? I am don't see this issue. From owner-freebsd-stable@freebsd.org Mon Feb 15 12:28:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86092AA0646 for ; Mon, 15 Feb 2016 12:28:23 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B6D21F11 for ; Mon, 15 Feb 2016 12:28:23 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id g62so106671032wme.0 for ; Mon, 15 Feb 2016 04:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sRnIiExTrwLCunyqDsItC2XGb1NdvIq7eDlr8rcX3P4=; b=RTe7OHYsrokqhPVfQHgkUmvM/QJCB1gUqCOz2voo6jB4Ox1h9vQTS1fqRZCRwTmZDt Vb0Vid+c4Z7oUogjygPqcoxA4/nwEnhK1+FtSH6pgHCS/vekM/HV8+uC4s1NNVVViZvv 11uV0a2/z5zPK+59s7ELVCybog42DCVwq2EEyRBz+RQlZ1ICrWU7qTfK5tK0rQSEUUJH +/HeaxweTwkaDn/034BKKnvAvnQr5sWnbzUMFY7Cl484Ef2JAohGiSu9NtlZxBGRf/ze evlkAkVbZejqGfCFJolRpzRo5z5TfBP95rEsHnHdSzIizu//p9JkETOYu2oC6lHeWXz/ E2kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sRnIiExTrwLCunyqDsItC2XGb1NdvIq7eDlr8rcX3P4=; b=TdIvgky1n4T/swkWhOy9lpucmCqaBm3hRQ9/Xs+NA2X3h98aTtR1wOEErB7G0Xpq2M sYJw9gPKZVDc1h0Kfr1A/AclLlyKwauwy/5K3a0iZcEG3Ljr0Y8xUi6ewca7gjx3GDGZ NDhsq304g8u5Wwp2+7kfyqjwZuioqqUY18rKS2bOsNyF/HknDUExM9Z8MIOBXsqZJ2H6 rzg9pQbhJmvq62oro9hh9k6DevSYz3BnO18TGw91Y5VsYcYPJx6vr00EAHlMKaBw0jDm d2kw4HFI2VsTG0luC4x42R6RIp8BW9HoRca6Cdr3WNEj10YiysF3P+WcjJH4uWKOBb7X MB6w== X-Gm-Message-State: AG10YOTuCP/UI6DptF4qDXPNy9evmDC6i5e0zf8G1Agxsx8lXiKMVo8isqkU21h806HO+fFmTi5P5LNsUPY1sQ== MIME-Version: 1.0 X-Received: by 10.194.63.7 with SMTP id c7mr16097106wjs.168.1455539301595; Mon, 15 Feb 2016 04:28:21 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 04:28:21 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 04:28:21 -0800 (PST) In-Reply-To: <20160215110022.GE37895@zxy.spb.ru> References: <20160215110022.GE37895@zxy.spb.ru> Date: Mon, 15 Feb 2016 15:28:21 +0300 Message-ID: Subject: Re: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: Slawa Olhovchenkov Cc: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:28:23 -0000 15 =D1=84=D0=B5=D0=B2=D1=80. 2016 =D0=B3. 14:00 =D0=BF=D0=BE=D0=BB=D1=8C=D0= =B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Slawa Olhovchenkov" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: > > > Hi! > > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? > > I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new > linuxulator import). > Chat and voice work good. > > > Seems like net-im/skype4 missing some dependencies and if it's > > satisfied net-im/skype4 hangs after start. > > linprocfs mounting doesn't help. > > I installed them all from the ports tree. > > Any experience? > > I am don't see this issue. Ok, thank you. I'll recheck. From owner-freebsd-stable@freebsd.org Mon Feb 15 14:29:13 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C09CAA9F5C; Mon, 15 Feb 2016 14:29:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7ED1337; Mon, 15 Feb 2016 14:29:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id F24FFA024; Mon, 15 Feb 2016 17:29:09 +0300 (MSK) Reply-To: lev@FreeBSD.org To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org From: Lev Serebryakov Subject: ZFS ARC vs Inactive memory on 10-STABLE: is it Ok? X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <56C1E0B4.5080201@FreeBSD.org> Date: Mon, 15 Feb 2016 17:29:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 14:29:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have mostly-storage server with 8GB of physical RAM and 9TB (5x2TB HDD) raidz ZFS pool (so, about 6.5TB usable space). ARC is limited to 3GB by vfs.zfs.arc_max. This server runs Samba (of course), CrashPlan backup client (Linux Java!), and torrent client (transmission-daemon). And I'm noticing this regularly ("screenshot" of top(1)): Mem: 1712M Active, 3965M Inact, 2066M Wired, 137M Cache, 822M Buf, 4688K Free ARC: 421M Total, 132M MFU, 54M MRU, 1040K Anon, 7900K Header, 227M Other Swap: 4096M Total, 248M Used, 3848M Free, 6% Inuse As you can see, here are almost 4G of Inactive memory and only 412M of ARC! Is it Ok? Why Inactive memory (non-dirty buffers?) are pressed ARC out of memory? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWweC0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePRTYP/RHajhE+EuvX3fCppShb/BSg vpJZ8F1jeInIOVXe/XLw07jht04uquTXHsMvw6F0J+WIIqsCld53q1bfj4CWAnl6 4TjULTZYUWANv3wK6KxItEN5eMmDEPOW6Eqls57OSCFcZA/32hyf/Y15Nec0L6JD sd8wpqUvQs0zb//frbUpjIRcfoVSMO2ip4doGPDtBv9IcE/kDz78IcmU9By2deXU IJE8Xlg2hDY+f/NhTR2sCuwtCSvpL9/mBztffYqsKQsAm8oIn0Sz9mNdjVzUR+rN lF4GoxcWf6c3HEM/LF4+dgOdb058YwO4amyUI7GoBSFBQq3OlJzvomGeOi2vPAvC BkWxOWOcWsmEwfk1b22k00yNAjvaXQsCx6r2L/6vyrAtoQ0moXF4Rks8+MLFRUTu FFke93UUPRQPXBdrBtlnFpXX6jpmlEm7g9pazarGc4hteYOKpvHajFvNvAB7RswI NQL70+QfLBgtaA5683scCuURNptStf/RfvhwjW/o5DPNLv+NHnT+nPk64MTDuaZD 4z9Kcj088KjB++xt9c6BXuCS4zlkyUhas5cNGG+SxupZajtIuaCBTeUv0QwjnDH5 Pnu44Xe4MCvpDSt9odICdzytxO6yzwL7mLj70o2SsPs2ijN1w/fOlNqS46bekmJ/ MtvVwObCRnoDg3aMRUL0 =In6V -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Mon Feb 15 14:55:42 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87CFAAA8F7E for ; Mon, 15 Feb 2016 14:55:42 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8791A4C for ; Mon, 15 Feb 2016 14:55:42 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-yw0-x22c.google.com with SMTP id h129so116323522ywb.1 for ; Mon, 15 Feb 2016 06:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eIUD/uHokuj4elGJonRN+esIBKNmEbpRVHwKDNrlVKA=; b=vHlYd358yu8qvs3c9GI/gi3iDbDYiG4evYFI7cYYPm0Wg5HFm0rzBzfcb4WXvN8pEc q6pZT+oXoIfo3GCB+yYsC/5yNNuL5J63JQ0qRknKxfJQSp5fBinpWu04N/fM+XqLcd9n qq2clIyn2Ja1GDFBKUA6bpt/f+eK/1Y61vns3lip/JbJM4rjOu7LaVmy1hLMoe3w7BMX jd9nAZDhRAa2ZTmIViG7ItvhQj9A+lRHEm94+UzMvuFYKZXdiZub8rJTe1w7RyV2Qysh BP4yaaoOAyV/o+1W/BOV3cpU1SW2uBA4b0DDBRZQQ0WEqgc9+Fionei+ghPtYHhC3XrF QNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eIUD/uHokuj4elGJonRN+esIBKNmEbpRVHwKDNrlVKA=; b=NA0ryNWSa6J3Pk6piKf1T+5W55sbyACZe060Q2IoJ+wG3gNEFZU0flLbuFBlZdmxr1 60C2IXyaYQLcx4Z8P4kXf6z5hg2uZzG5pRtmhEPJgldOiau9hWxhfJm1O1JcalI5mhgB BlRpH4PLH0MBGMui28Yz9MxFeHLKWvmrmit+zfDwvfx9WThAg96O57EkIh5jedyNHPgT s2s+yGbrVEHJcYn/jYtlV38Pb3lCKp37i38PLlL7kK9OmR9VMrOZmWutiST1n8C5CCmH +hB91h7DGE40khWuk01J9rU8jy0aRXH8AYUwrh3OawhAcgO7cxl5Ghasb4gIA56ahOMn 7YyQ== X-Gm-Message-State: AG10YORIQV24SlITA7dsResFqaStt0VAMHnGZI2T8a935S+WSqx45y3YnK6mjyUAoqVdR8Pg7mj/nBsNdWujbA== MIME-Version: 1.0 X-Received: by 10.129.148.133 with SMTP id l127mr9266403ywg.272.1455548141331; Mon, 15 Feb 2016 06:55:41 -0800 (PST) Received: by 10.13.214.74 with HTTP; Mon, 15 Feb 2016 06:55:41 -0800 (PST) X-Originating-IP: [67.81.241.220] In-Reply-To: <56C1E0B4.5080201@FreeBSD.org> References: <56C1E0B4.5080201@FreeBSD.org> Date: Mon, 15 Feb 2016 09:55:41 -0500 Message-ID: Subject: Re: ZFS ARC vs Inactive memory on 10-STABLE: is it Ok? From: Mark Saad To: lev@freebsd.org Cc: freebsd-fs@freebsd.org, FreeBSD-Stable ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 14:55:42 -0000 On Mon, Feb 15, 2016 at 9:29 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > I have mostly-storage server with 8GB of physical RAM and 9TB (5x2TB > HDD) raidz ZFS pool (so, about 6.5TB usable space). > > ARC is limited to 3GB by vfs.zfs.arc_max. > > This server runs Samba (of course), CrashPlan backup client (Linux > Java!), and torrent client (transmission-daemon). > > Wow someone else as crazy as I was. :) > And I'm noticing this regularly ("screenshot" of top(1)): > > Mem: 1712M Active, 3965M Inact, 2066M Wired, 137M Cache, 822M Buf, > 4688K Free > ARC: 421M Total, 132M MFU, 54M MRU, 1040K Anon, 7900K Header, 227M Other > Swap: 4096M Total, 248M Used, 3848M Free, 6% Inuse > > As you can see, here are almost 4G of Inactive memory and only 412M > of ARC! > > Is it Ok? Why Inactive memory (non-dirty buffers?) are pressed ARC > out of memory? > > Lev so I ran a similar setup on 10.1-RELEASE with 40TB in a raid 1+0 like zpool . My top looked similar but its been a while and i had 24G of ram. With a 12G Arc max. I always wondered what was going on here but I suspected it was due to a interaction of java and arc eviction. The crash plan app is terrible and would "start doing something new" up and look hung. Disk io went to hell etc . Then things would settle down and start chugging away. Keep in mind crash plan would take like a month to back up 2TB of changes on this thing. I eventually convinced management to move to a automated tape library and a normal backup client ( netbackup ) for the backups. Also I abandoned this project about 18 months ago too . - -- > // Lev Serebryakov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQJ8BAEBCgBmBQJWweC0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePRTYP/RHajhE+EuvX3fCppShb/BSg > vpJZ8F1jeInIOVXe/XLw07jht04uquTXHsMvw6F0J+WIIqsCld53q1bfj4CWAnl6 > 4TjULTZYUWANv3wK6KxItEN5eMmDEPOW6Eqls57OSCFcZA/32hyf/Y15Nec0L6JD > sd8wpqUvQs0zb//frbUpjIRcfoVSMO2ip4doGPDtBv9IcE/kDz78IcmU9By2deXU > IJE8Xlg2hDY+f/NhTR2sCuwtCSvpL9/mBztffYqsKQsAm8oIn0Sz9mNdjVzUR+rN > lF4GoxcWf6c3HEM/LF4+dgOdb058YwO4amyUI7GoBSFBQq3OlJzvomGeOi2vPAvC > BkWxOWOcWsmEwfk1b22k00yNAjvaXQsCx6r2L/6vyrAtoQ0moXF4Rks8+MLFRUTu > FFke93UUPRQPXBdrBtlnFpXX6jpmlEm7g9pazarGc4hteYOKpvHajFvNvAB7RswI > NQL70+QfLBgtaA5683scCuURNptStf/RfvhwjW/o5DPNLv+NHnT+nPk64MTDuaZD > 4z9Kcj088KjB++xt9c6BXuCS4zlkyUhas5cNGG+SxupZajtIuaCBTeUv0QwjnDH5 > Pnu44Xe4MCvpDSt9odICdzytxO6yzwL7mLj70o2SsPs2ijN1w/fOlNqS46bekmJ/ > MtvVwObCRnoDg3aMRUL0 > =In6V > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@freebsd.org Mon Feb 15 15:04:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24F89AA94D0 for ; Mon, 15 Feb 2016 15:04:48 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) 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 0A6C610E4 for ; Mon, 15 Feb 2016 15:04:48 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id 05E0AAA94CF; Mon, 15 Feb 2016 15:04:48 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF857AA94CE for ; Mon, 15 Feb 2016 15:04:47 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from smtp.unipi.it (smtp1.unipi.it [131.114.21.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7545710E3 for ; Mon, 15 Feb 2016 15:04:46 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from localhost (localhost [127.0.0.1]) by smtp.unipi.it (Postfix) with ESMTP id DE943401A9; Mon, 15 Feb 2016 16:04:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at unipi.it Received: from [10.216.1.203] (prova.iet.unipi.it [131.114.58.86]) (Authenticated User) by smtp.unipi.it (Postfix) with ESMTPSA id 2948A41906; Mon, 15 Feb 2016 16:04:35 +0100 (CET) Subject: Re: 82576 + NETMAP + VLAN To: Slawa Olhovchenkov References: <20160204130029.GC88527@zxy.spb.ru> <20160208173935.GK68298@zxy.spb.ru> <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" From: Giuseppe Lettieri Message-ID: <56C1EA66.807@iet.unipi.it> Date: Mon, 15 Feb 2016 16:10:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160211133428.GM68298@zxy.spb.ru> Content-Type: multipart/mixed; boundary="------------070903090503050404020401" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:04:48 -0000 This is a multi-part message in MIME format. --------------070903090503050404020401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Slawa, I think WITNESS is seeing a false positive, since those two are always different mutexes. The actual deadlock you experience should be caused by something else. I have not been able to reproduce it locally (I have not tried that hard, to be honest). I am pretty sure that there is a lock inversion - one that may cause real deadlocks - when you use netmap pipes+kqueue and you don't pass NETMAP_NO_TX_POLL at NIOCREGIF time. The attached patch should solve this particular problem, but there may be others. May you please try it? Cheers, Giuseppe Il 11/02/2016 14:34, Slawa Olhovchenkov ha scritto: > On Thu, Feb 11, 2016 at 10:11:59AM +0100, Giuseppe Lettieri wrote: > >> Il 10/02/2016 14:53, Slawa Olhovchenkov ha scritto: >>> On Wed, Feb 10, 2016 at 02:33:20PM +0100, Giuseppe Lettieri wrote: >>> >>>> Il 10/02/2016 12:59, Slawa Olhovchenkov ha scritto: >>>>> Can you look also on second issue? >>>>> >>>>> PS: What need from me? May be open PR? >>>> >>>> May you provide some example code that triggers the issue? >>> >>> This is about 700 lines of code (not very clear), may be I can describe it? >> >> I just need some code to trigger the problem locally. Don't worry about >> the clarity and the line count, unless you cannot share the code for >> other reasons. > > I am attach source. > run as "prog if1 if2" > Got `acquiring duplicate lock of same type: "nm_kn_lock"` immediatly > after start. > Dead locking may be occur immediatly after start or may be need > traffic flooding. > -- Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 1, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.lettieri@iet.unipi.it --------------070903090503050404020401 Content-Type: text/x-patch; name="notxpoll.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="notxpoll.patch" Index: dev/netmap/netmap.c =================================================================== --- dev/netmap/netmap.c (revision 287671) +++ dev/netmap/netmap.c (working copy) @@ -2378,7 +2378,7 @@ * XXX should also check cur != hwcur on the tx rings. * Fortunately, normal tx mode has np_txpoll set. */ - if (priv->np_txpoll || want_tx) { + if ((priv->np_txpoll && !is_kevent) || want_tx) { /* * The first round checks if anyone is ready, if not * do a selrecord and another round to handle races. --------------070903090503050404020401-- From owner-freebsd-stable@freebsd.org Mon Feb 15 15:07:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD0C5AA9693; Mon, 15 Feb 2016 15:07:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA2C1321; Mon, 15 Feb 2016 15:07:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 67AF3A054; Mon, 15 Feb 2016 18:07:39 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: ZFS ARC vs Inactive memory on 10-STABLE: is it Ok? References: <56C1E0B4.5080201@FreeBSD.org> To: Mark Saad Cc: freebsd-fs@freebsd.org, FreeBSD-Stable ML From: Lev Serebryakov Organization: FreeBSD Message-ID: <56C1E9BA.3080504@FreeBSD.org> Date: Mon, 15 Feb 2016 18:07:38 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:07:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15.02.2016 17:55, Mark Saad wrote: > Wow someone else as crazy as I was. :) ... > I eventually convinced management to move to a automated tape > library and a normal backup client It is my own home NAS, and I need to backup about 2TB offsite (you could call me paranoid, yes). CrashPlan is almost only offer on the market I could afford. I will be happy to use tarsnap or rsync.net, for example, but it is too expensive for me :( - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWwem6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIqwP/iefNVwjlBfyPVuIXKtlldPP CHLgdUaUSb+Nj67WJ20aKxw5nBHoJtRi60Ao1azutzYVEJdMDLGCX7ExqBAoMreY sDZlKfTQViYlMhFhXch0AddEcticKrIl24D8a2WAaKLsnFSNY/U4XEd/jYl/TUVd kbPbN+9Tufr/xzkilwiQJ7M1jKgq2PfPF6mrezPPRkvJGuBHpQPSOMRnlylQmw4K wpBxroepNohcSIdLHOKXD6nGt9vaIF7vWycjF/IGEoWi/mmyjjR8eqBGHc6t3kZt +yktp9q56TdPgh4EgfivoQyFiQwhlcUOB6HbrXyTSXXhpTKcy0/KpeiNUwnnp6j/ Qlm1xJPJnrw1mUj5i0790h4ZuFfurfFf7cL79RL9ZQHr7os5a5A5jNQlX2+GKSgD J5eraHgYiio4a3d805wsvCETJjZGjBn0Jk5YANuodAcZyzo66RffFQomuWMlSe13 Et9NXmWT6rrNhxVC7BJv8zhK7Xy7YhIBiY3xONbpxcX7bVJt/1LIha44/Ft/BoLp rlnJITPQZPn2FUwILQz4D+caJqkEeELpGd6Q385RLEHlf++izyT3MXvJl1MAhnYS RoByj7qdy1EfSi/C0uVdxRHwk+tItySpgTVQ+5gm6T8B1dDs+noXednC6j72i+Xf L14BPz8y5/9rCR93XhdP =5Vz8 -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Mon Feb 15 15:13:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0C3AA99ED for ; Mon, 15 Feb 2016 15:13:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 C4B1B1A4E for ; Mon, 15 Feb 2016 15:13:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id BFF3DAA99EA; Mon, 15 Feb 2016 15:13:22 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A66F4AA99E9 for ; Mon, 15 Feb 2016 15:13:22 +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 672EC1A4D for ; Mon, 15 Feb 2016 15:13:22 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVKpy-000Jtv-HP; Mon, 15 Feb 2016 18:13:18 +0300 Date: Mon, 15 Feb 2016 18:13:18 +0300 From: Slawa Olhovchenkov To: Giuseppe Lettieri Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160215151318.GQ68298@zxy.spb.ru> References: <20160208173935.GK68298@zxy.spb.ru> <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C1EA66.807@iet.unipi.it> 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:13:23 -0000 On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > Hi Slawa, > > I think WITNESS is seeing a false positive, since those two are always > different mutexes. > > The actual deadlock you experience should be caused by something else. I Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. > have not been able to reproduce it locally (I have not tried that hard, > to be honest). I am pretty sure that there is a lock inversion - one > that may cause real deadlocks - when you use netmap pipes+kqueue and you > don't pass NETMAP_NO_TX_POLL at NIOCREGIF time. The attached patch > should solve this particular problem, but there may be others. May you > please try it? Try it with or w/o WITNESS? > Cheers, > Giuseppe > > Il 11/02/2016 14:34, Slawa Olhovchenkov ha scritto: > > On Thu, Feb 11, 2016 at 10:11:59AM +0100, Giuseppe Lettieri wrote: > > > >> Il 10/02/2016 14:53, Slawa Olhovchenkov ha scritto: > >>> On Wed, Feb 10, 2016 at 02:33:20PM +0100, Giuseppe Lettieri wrote: > >>> > >>>> Il 10/02/2016 12:59, Slawa Olhovchenkov ha scritto: > >>>>> Can you look also on second issue? > >>>>> > >>>>> PS: What need from me? May be open PR? > >>>> > >>>> May you provide some example code that triggers the issue? > >>> > >>> This is about 700 lines of code (not very clear), may be I can describe it? > >> > >> I just need some code to trigger the problem locally. Don't worry about > >> the clarity and the line count, unless you cannot share the code for > >> other reasons. > > > > I am attach source. > > run as "prog if1 if2" > > Got `acquiring duplicate lock of same type: "nm_kn_lock"` immediatly > > after start. > > Dead locking may be occur immediatly after start or may be need > > traffic flooding. > > > > > -- > Dr. Ing. Giuseppe Lettieri > Dipartimento di Ingegneria della Informazione > Universita' di Pisa > Largo Lucio Lazzarino 1, 56122 Pisa - Italy > Ph. : (+39) 050-2217.649 (direct) .599 (switch) > Fax : (+39) 050-2217.600 > e-mail: g.lettieri@iet.unipi.it > Index: dev/netmap/netmap.c > =================================================================== > --- dev/netmap/netmap.c (revision 287671) > +++ dev/netmap/netmap.c (working copy) > @@ -2378,7 +2378,7 @@ > * XXX should also check cur != hwcur on the tx rings. > * Fortunately, normal tx mode has np_txpoll set. > */ > - if (priv->np_txpoll || want_tx) { > + if ((priv->np_txpoll && !is_kevent) || want_tx) { > /* > * The first round checks if anyone is ready, if not > * do a selrecord and another round to handle races. From owner-freebsd-stable@freebsd.org Mon Feb 15 16:05:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C1ABAA945B for ; Mon, 15 Feb 2016 16:05:06 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) 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 68ECF1FA7 for ; Mon, 15 Feb 2016 16:05:06 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id 64665AA945A; Mon, 15 Feb 2016 16:05:06 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A1CEAA9459 for ; Mon, 15 Feb 2016 16:05:06 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from smtp.unipi.it (smtp2.unipi.it [131.114.21.21]) by mx1.freebsd.org (Postfix) with ESMTP id D40231FA4 for ; Mon, 15 Feb 2016 16:05:05 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from localhost (localhost [127.0.0.1]) by smtp.unipi.it (Postfix) with ESMTP id 0033040902; Mon, 15 Feb 2016 16:56:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at unipi.it Received: from [10.216.1.203] (prova.iet.unipi.it [131.114.58.86]) (Authenticated User) by smtp.unipi.it (Postfix) with ESMTPSA id CD4B9405AD; Mon, 15 Feb 2016 16:56:40 +0100 (CET) Subject: Re: 82576 + NETMAP + VLAN To: Slawa Olhovchenkov References: <20160208173935.GK68298@zxy.spb.ru> <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" From: Giuseppe Lettieri Message-ID: <56C1F69C.5010004@iet.unipi.it> Date: Mon, 15 Feb 2016 17:02:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160215151318.GQ68298@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:05:06 -0000 Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: > On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > >> Hi Slawa, >> >> I think WITNESS is seeing a false positive, since those two are always >> different mutexes. >> >> The actual deadlock you experience should be caused by something else. I > > Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. The deadlock I mentioned still involves nm_kn_locks, sorry if I was not clear about that. I am just saying that we never try to take the same lock that we already holding. Nonetheless, there are indeed problems in the path that WITNESS has seen. The problem is that pipes have to notify the other end while called by kevent. kevent holds the nm_kn_lock on the TX src ring and the notification takes the nm_kn_lock on the RX dst ring. > >> have not been able to reproduce it locally (I have not tried that hard, >> to be honest). I am pretty sure that there is a lock inversion - one >> that may cause real deadlocks - when you use netmap pipes+kqueue and you >> don't pass NETMAP_NO_TX_POLL at NIOCREGIF time. The attached patch >> should solve this particular problem, but there may be others. May you >> please try it? > > Try it with or w/o WITNESS? I am trying to see if the actual deadlock disappears, so disable WITNESS if it slows down the system and masks the real deadlock. Otherwise, leave it on. Cheers, Giuseppe > >> Cheers, >> Giuseppe >> >> Il 11/02/2016 14:34, Slawa Olhovchenkov ha scritto: >>> On Thu, Feb 11, 2016 at 10:11:59AM +0100, Giuseppe Lettieri wrote: >>> >>>> Il 10/02/2016 14:53, Slawa Olhovchenkov ha scritto: >>>>> On Wed, Feb 10, 2016 at 02:33:20PM +0100, Giuseppe Lettieri wrote: >>>>> >>>>>> Il 10/02/2016 12:59, Slawa Olhovchenkov ha scritto: >>>>>>> Can you look also on second issue? >>>>>>> >>>>>>> PS: What need from me? May be open PR? >>>>>> >>>>>> May you provide some example code that triggers the issue? >>>>> >>>>> This is about 700 lines of code (not very clear), may be I can describe it? >>>> >>>> I just need some code to trigger the problem locally. Don't worry about >>>> the clarity and the line count, unless you cannot share the code for >>>> other reasons. >>> >>> I am attach source. >>> run as "prog if1 if2" >>> Got `acquiring duplicate lock of same type: "nm_kn_lock"` immediatly >>> after start. >>> Dead locking may be occur immediatly after start or may be need >>> traffic flooding. >>> >> >> >> -- >> Dr. Ing. Giuseppe Lettieri >> Dipartimento di Ingegneria della Informazione >> Universita' di Pisa >> Largo Lucio Lazzarino 1, 56122 Pisa - Italy >> Ph. : (+39) 050-2217.649 (direct) .599 (switch) >> Fax : (+39) 050-2217.600 >> e-mail: g.lettieri@iet.unipi.it > >> Index: dev/netmap/netmap.c >> =================================================================== >> --- dev/netmap/netmap.c (revision 287671) >> +++ dev/netmap/netmap.c (working copy) >> @@ -2378,7 +2378,7 @@ >> * XXX should also check cur != hwcur on the tx rings. >> * Fortunately, normal tx mode has np_txpoll set. >> */ >> - if (priv->np_txpoll || want_tx) { >> + if ((priv->np_txpoll && !is_kevent) || want_tx) { >> /* >> * The first round checks if anyone is ready, if not >> * do a selrecord and another round to handle races. > -- Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 1, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.lettieri@iet.unipi.it From owner-freebsd-stable@freebsd.org Mon Feb 15 17:50:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7A3DAA864A for ; Mon, 15 Feb 2016 17:50:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 A1F6210F5 for ; Mon, 15 Feb 2016 17:50:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9F290AA8649; Mon, 15 Feb 2016 17:50:03 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84D31AA8648 for ; Mon, 15 Feb 2016 17:50:03 +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 4376610F4 for ; Mon, 15 Feb 2016 17:50:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVNHY-000NnZ-Tq; Mon, 15 Feb 2016 20:49:56 +0300 Date: Mon, 15 Feb 2016 20:49:56 +0300 From: Slawa Olhovchenkov To: Giuseppe Lettieri Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160215174956.GD68298@zxy.spb.ru> References: <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> <56C1F69C.5010004@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C1F69C.5010004@iet.unipi.it> 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:50:03 -0000 On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: > Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: > > On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > > > >> Hi Slawa, > >> > >> I think WITNESS is seeing a false positive, since those two are always > >> different mutexes. > >> > >> The actual deadlock you experience should be caused by something else. I > > > > Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. > > The deadlock I mentioned still involves nm_kn_locks, sorry if I was not > clear about that. I am just saying that we never try to take the same > lock that we already holding. > > Nonetheless, there are indeed problems in the path that WITNESS has > seen. The problem is that pipes have to notify the other end while > called by kevent. kevent holds the nm_kn_lock on the TX src ring and the > notification takes the nm_kn_lock on the RX dst ring. Thanks for clarification. > > > >> have not been able to reproduce it locally (I have not tried that hard, > >> to be honest). I am pretty sure that there is a lock inversion - one > >> that may cause real deadlocks - when you use netmap pipes+kqueue and you > >> don't pass NETMAP_NO_TX_POLL at NIOCREGIF time. The attached patch > >> should solve this particular problem, but there may be others. May you > >> please try it? > > > > Try it with or w/o WITNESS? > > I am trying to see if the actual deadlock disappears, so disable WITNESS > if it slows down the system and masks the real deadlock. Otherwise, > leave it on. OK. With and w/o WITNESS I am currently don't see deadlock. Just for record, two LOR, may be already well-known: lock order reversal: 1st 0xfffffe0172c6fa78 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3130 2nd 0xfffff8005ca81000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:280 KDB: stack backtrace: #0 0xffffffff809702b0 at kdb_backtrace+0x60 #1 0xffffffff8098825e at witness_checkorder+0xc7e #2 0xffffffff8093e137 at _sx_xlock+0x47 #3 0xffffffff80b75d6a at ufsdirhash_add+0x3a #4 0xffffffff80b78b40 at ufs_direnter+0x6a0 #5 0xffffffff80b815ab at ufs_makeinode+0x56b #6 0xffffffff80b7d5dd at ufs_create+0x2d #7 0xffffffff80e33311 at VOP_CREATE_APV+0xa1 #8 0xffffffff809e2009 at vn_open_cred+0x3b9 #9 0xffffffff809db30f at kern_openat+0x26f #10 0xffffffff80d0e8a4 at amd64_syscall+0x2d4 #11 0xffffffff80cf4f5b at Xfast_syscall+0xfb lock order reversal: 1st 0xfffff80049138d50 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2415 2nd 0xfffffe0172cb1b80 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfffff800a6832d50 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2415 KDB: stack backtrace: #0 0xffffffff809702b0 at kdb_backtrace+0x60 #1 0xffffffff8098825e at witness_checkorder+0xc7e #2 0xffffffff80918dd8 at __lockmgr_args+0x738 #3 0xffffffff80b71594 at ffs_lock+0x84 #4 0xffffffff80e3512b at VOP_LOCK1_APV+0xab #5 0xffffffff809e28f3 at _vn_lock+0x43 #6 0xffffffff809d42fb at vget+0x5b #7 0xffffffff809c8c51 at vfs_hash_get+0xe1 #8 0xffffffff80b6d0a0 at ffs_vgetf+0x40 #9 0xffffffff80b64c50 at softdep_sync_buf+0x300 #10 0xffffffff80b72296 at ffs_syncvnode+0x226 #11 0xffffffff80b4b6b3 at ffs_truncate+0x683 #12 0xffffffff80b78c99 at ufs_direnter+0x7f9 #13 0xffffffff80b808eb at ufs_mkdir+0x86b #14 0xffffffff80e34987 at VOP_MKDIR_APV+0xa7 #15 0xffffffff809dfca9 at kern_mkdirat+0x209 #16 0xffffffff80d0e8a4 at amd64_syscall+0x2d4 #17 0xffffffff80cf4f5b at Xfast_syscall+0xfb > > > >> Cheers, > >> Giuseppe > >> > >> Il 11/02/2016 14:34, Slawa Olhovchenkov ha scritto: > >>> On Thu, Feb 11, 2016 at 10:11:59AM +0100, Giuseppe Lettieri wrote: > >>> > >>>> Il 10/02/2016 14:53, Slawa Olhovchenkov ha scritto: > >>>>> On Wed, Feb 10, 2016 at 02:33:20PM +0100, Giuseppe Lettieri wrote: > >>>>> > >>>>>> Il 10/02/2016 12:59, Slawa Olhovchenkov ha scritto: > >>>>>>> Can you look also on second issue? > >>>>>>> > >>>>>>> PS: What need from me? May be open PR? > >>>>>> > >>>>>> May you provide some example code that triggers the issue? > >>>>> > >>>>> This is about 700 lines of code (not very clear), may be I can describe it? > >>>> > >>>> I just need some code to trigger the problem locally. Don't worry about > >>>> the clarity and the line count, unless you cannot share the code for > >>>> other reasons. > >>> > >>> I am attach source. > >>> run as "prog if1 if2" > >>> Got `acquiring duplicate lock of same type: "nm_kn_lock"` immediatly > >>> after start. > >>> Dead locking may be occur immediatly after start or may be need > >>> traffic flooding. > >>> > >> > >> > >> -- > >> Dr. Ing. Giuseppe Lettieri > >> Dipartimento di Ingegneria della Informazione > >> Universita' di Pisa > >> Largo Lucio Lazzarino 1, 56122 Pisa - Italy > >> Ph. : (+39) 050-2217.649 (direct) .599 (switch) > >> Fax : (+39) 050-2217.600 > >> e-mail: g.lettieri@iet.unipi.it > > > >> Index: dev/netmap/netmap.c > >> =================================================================== > >> --- dev/netmap/netmap.c (revision 287671) > >> +++ dev/netmap/netmap.c (working copy) > >> @@ -2378,7 +2378,7 @@ > >> * XXX should also check cur != hwcur on the tx rings. > >> * Fortunately, normal tx mode has np_txpoll set. > >> */ > >> - if (priv->np_txpoll || want_tx) { > >> + if ((priv->np_txpoll && !is_kevent) || want_tx) { > >> /* > >> * The first round checks if anyone is ready, if not > >> * do a selrecord and another round to handle races. > > > > > -- > Dr. Ing. Giuseppe Lettieri > Dipartimento di Ingegneria della Informazione > Universita' di Pisa > Largo Lucio Lazzarino 1, 56122 Pisa - Italy > Ph. : (+39) 050-2217.649 (direct) .599 (switch) > Fax : (+39) 050-2217.600 > e-mail: g.lettieri@iet.unipi.it From owner-freebsd-stable@freebsd.org Mon Feb 15 21:44:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9692CAA8B33 for ; Mon, 15 Feb 2016 21:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 83274BFD for ; Mon, 15 Feb 2016 21:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 81FFEAA8B32; Mon, 15 Feb 2016 21:44:53 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 819B7AA8B31 for ; Mon, 15 Feb 2016 21:44:53 +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 40FF4BFC for ; Mon, 15 Feb 2016 21:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVQwo-0003T6-QN; Tue, 16 Feb 2016 00:44:46 +0300 Date: Tue, 16 Feb 2016 00:44:46 +0300 From: Slawa Olhovchenkov To: Giuseppe Lettieri Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160215214446.GE68298@zxy.spb.ru> References: <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> <56C1F69C.5010004@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C1F69C.5010004@iet.unipi.it> 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:44:53 -0000 On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: > Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: > > On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > > > >> Hi Slawa, > >> > >> I think WITNESS is seeing a false positive, since those two are always > >> different mutexes. > >> > >> The actual deadlock you experience should be caused by something else. I > > > > Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. > > The deadlock I mentioned still involves nm_kn_locks, sorry if I was not > clear about that. I am just saying that we never try to take the same > lock that we already holding. > > Nonetheless, there are indeed problems in the path that WITNESS has > seen. The problem is that pipes have to notify the other end while > called by kevent. kevent holds the nm_kn_lock on the TX src ring and the > notification takes the nm_kn_lock on the RX dst ring. Can you comment other issuses? Is this by design or is this bug? - with kevent sync for transmiting need first register EVFILT_WRITE/EV_DISABLE and after every write EVFILT_WRITE/EV_DISPATCH - with kevent sync all opening /dev/netmap and registering need do from same thread as kevent using for sinc (unless no RX/TX). From owner-freebsd-stable@freebsd.org Tue Feb 16 07:49:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1BDBAAA52F for ; Tue, 16 Feb 2016 07:49:03 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 4B63F1030 for ; Tue, 16 Feb 2016 07:49:03 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id b205so97122291wmb.1 for ; Mon, 15 Feb 2016 23:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4AGgsbTa/mx/rH/5wgv8N03zcHKGMeLrHPiGEtjsBM0=; b=DlYLqixZX+2cv/VRQnZrUxzCypOPMFLPiR1agxbZjorWt4Oy6HE2qbkyo3BL0GVfil 9y2r/92LYT0qpWShe16llJjTmfmw+Dg0v6OkDDrpiCCWzkEwUpsZB1cRuQXtpo0dUmlg E3a537kZosb6ARwDLeltgZB8IF67pz9VyH0FkFBXqzEz5QTVwWYmTHJtJsIqBIBJnT6O IxVeS0xATayXyNtC9g5LDkbb5iHJAlD6nziOXJf6rxz+6id2TO31LXZuH/Lgprn1WQlG w9Omd/p+NYfsCDoQdECvXlGcYED0CAx/OlX491Qw5Mdjwq4f64PFgY15sxVLfk+SGHED WUPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4AGgsbTa/mx/rH/5wgv8N03zcHKGMeLrHPiGEtjsBM0=; b=eiSmOzCGQxzgGsYQxUz73Zo7/YsqdwXX6wd2nmBnbyDGvnIfBCN/G9KedhPcOFTq+p A7QopxF5W9gl8Ai7/DgpBPmilUXS5u6WYvRcc4bS8YGKa268D7EaAfKhdOYqyTDdS2Tw G/ETuKP+6bGYUzCKq+0ynCOLW9HhApHRVz0BmOo3VB6Q1xDodviOdVHRYdmfuH1E/cW8 82gboTK1zG1J/mkFkbaE/OmOJ0teims22nOD8s9zYKl+Onna2l1ERW9rqJzGx/sLkZO9 8Kx+Z9qSwM/9dxvht+QnvAuPsbNNZx+8HxsRUqaqdupuB6C6uQ5BovE0dV9PGFjCm1rC apyA== X-Gm-Message-State: AG10YORYD3DLdXmReFSRbHlyhyk7TtkgFlFAHctubicV5e579QiOefTKRV7ylS8x7bE9kcZBrIU2Udb/kPxqRQ== MIME-Version: 1.0 X-Received: by 10.28.148.68 with SMTP id w65mr18006462wmd.66.1455608941396; Mon, 15 Feb 2016 23:49:01 -0800 (PST) Received: by 10.28.89.129 with HTTP; Mon, 15 Feb 2016 23:49:01 -0800 (PST) In-Reply-To: References: <20160215110022.GE37895@zxy.spb.ru> Date: Tue, 16 Feb 2016 10:49:01 +0300 Message-ID: Subject: Re: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: Slawa Olhovchenkov Cc: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 07:49:03 -0000 2016-02-15 15:28 GMT+03:00 Pavel Timofeev : > > 15 =D1=84=D0=B5=D0=B2=D1=80. 2016 =D0=B3. 14:00 =D0=BF=D0=BE=D0=BB=D1=8C= =D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Slawa Olhovchenkov" > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > >> >> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: >> >> > Hi! >> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? >> >> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new >> linuxulator import). >> Chat and voice work good. >> >> > Seems like net-im/skype4 missing some dependencies and if it's >> > satisfied net-im/skype4 hangs after start. >> > linprocfs mounting doesn't help. >> > I installed them all from the ports tree. >> > Any experience? >> >> I am don't see this issue. > > Ok, thank you. I'll recheck. Well, I've managed to start skype4. What I did is: # mkdir -p /compat/linux/proc/ add linprocfs to /etc/fstab add linux_enable=3D"YES" to /etc/rc.conf # reboot # portmaster /usr/ports/net-im/skype4 Then I tried to start it and got: % skype /usr/local/share/skype/skype: error while loading shared libraries: libpulse-mainloop-glib.so.0: cannot open shared object file: No such file or directory Then I installed missing dependency: # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs And tried to start it again: % skype /usr/local/share/skype/skype: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory Installed another missing dependency: # portmaster /usr/ports/security/linux-c6-openssl And finally skype could start. So there are some missing dependencies. I've created a bug report. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207240 From owner-freebsd-stable@freebsd.org Tue Feb 16 08:16:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF981AA01AF for ; Tue, 16 Feb 2016 08:16:16 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 699941D29 for ; Tue, 16 Feb 2016 08:16:16 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id g62so140451129wme.0 for ; Tue, 16 Feb 2016 00:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PyXQDGsInK7ltnCYAgvQ1UxLHNcGns+9LWGnF54Yx8M=; b=oNfUWLm4VuAz0DHGkm1/xkZBucZNtoEhBmOZ8P9YuugTficBaoY9AWHuCNWfxWw0A8 e/6/arTtAhBPp17ulNmcjMybxXxE2Pbi7jEg7Rg2joxCpMkXvdwmYMabMGZ1/rwQzwGi mEC06i+NoZDqHbUyN1qgUWLUit7vLML+pyWyd65zQHUPke5gl6/TCJ6RswV0F7BLhXBs SSct4efoBLFg8lolZ521mePUQDn1hnmA7c9sd50jMMp8PF44wPdphQcKrXBWCdPI/mzO rv4gThTq5+s3xNBBwwa+3xX6dp3E0sfvpZB4KBp9QpUKU1mfYkSoP3Ksr0837aRMRz0u F64A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PyXQDGsInK7ltnCYAgvQ1UxLHNcGns+9LWGnF54Yx8M=; b=WEeD+6s4xncr39tUWCQxzexbmPRxq+Dt27X8fA4gUaBBlfe9v3k/g1PUU+NvQDdN0w qccResk5KkZmEtXk4tuJ8sbcjfBGyZ7ImayF/jXEk1bOhfYCEER/Vo/7cdngXu2FpIRH 2qk0MC/7CT8zDO2XV0Ux/TIirRuvp21XwWrQWu8eFh4clsBDZ7bI84TLOBOY7o3E0k8U t8Eb00FWhWamtGJtDkB7QBosvyBQVJtMACrGXpoEuEI9p49/HYPdgugb8SoUrQEVI0Tg L7zLdu0yUQZF433dBDKgFs/4TFu3FtdgF55i6ePUouX9U6Bu47zbvLce3lxyk5IrFyJ1 yAJA== X-Gm-Message-State: AG10YOS23/UN2c0ZHcpzMJucLoz/da6E7DOUOaUlE3Y/gpJeWDY32yDXW0gV4qT+RoF1yca5gFbPR/Ln5ovaDg== MIME-Version: 1.0 X-Received: by 10.28.224.87 with SMTP id x84mr18327005wmg.32.1455610574852; Tue, 16 Feb 2016 00:16:14 -0800 (PST) Received: by 10.28.89.129 with HTTP; Tue, 16 Feb 2016 00:16:14 -0800 (PST) In-Reply-To: References: <20160215110022.GE37895@zxy.spb.ru> Date: Tue, 16 Feb 2016 11:16:14 +0300 Message-ID: Subject: Re: net-im/skype4 under FreeBSD 10.3 From: Pavel Timofeev To: Slawa Olhovchenkov Cc: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 08:16:16 -0000 2016-02-16 10:49 GMT+03:00 Pavel Timofeev : > 2016-02-15 15:28 GMT+03:00 Pavel Timofeev : >> >> 15 =D1=84=D0=B5=D0=B2=D1=80. 2016 =D0=B3. 14:00 =D0=BF=D0=BE=D0=BB=D1=8C= =D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Slawa Olhovchenkov" >> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> >> >>> >>> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: >>> >>> > Hi! >>> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? >>> >>> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new >>> linuxulator import). >>> Chat and voice work good. >>> >>> > Seems like net-im/skype4 missing some dependencies and if it's >>> > satisfied net-im/skype4 hangs after start. >>> > linprocfs mounting doesn't help. >>> > I installed them all from the ports tree. >>> > Any experience? >>> >>> I am don't see this issue. >> >> Ok, thank you. I'll recheck. > > Well, I've managed to start skype4. > What I did is: > # mkdir -p /compat/linux/proc/ > add linprocfs to /etc/fstab > add linux_enable=3D"YES" to /etc/rc.conf > # reboot > # portmaster /usr/ports/net-im/skype4 > Then I tried to start it and got: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libpulse-mainloop-glib.so.0: cannot open shared object file: No such > file or directory > Then I installed missing dependency: > # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs > And tried to start it again: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libssl.so.10: cannot open shared object file: No such file or > directory > Installed another missing dependency: > # portmaster /usr/ports/security/linux-c6-openssl > And finally skype could start. > > So there are some missing dependencies. I've created a bug report. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207240 Oh, I noticed that sound stopped working on the front panel of my workstation after I upgraded FreeBSD from 10.2-RELEASE to 10.3-BETA. It works now only if I connect my headphones to the connectors at the back of my workstation. From owner-freebsd-stable@freebsd.org Tue Feb 16 08:45:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF3F2AA1151 for ; Tue, 16 Feb 2016 08:45:18 +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 9ED4E1F37 for ; Tue, 16 Feb 2016 08:45:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aVbFy-000Hzt-Nc; Tue, 16 Feb 2016 11:45:14 +0300 Date: Tue, 16 Feb 2016 11:45:14 +0300 From: Slawa Olhovchenkov To: Pavel Timofeev Cc: freebsd-stable stable Subject: Re: net-im/skype4 under FreeBSD 10.3 Message-ID: <20160216084514.GF68298@zxy.spb.ru> References: <20160215110022.GE37895@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 08:45:19 -0000 On Tue, Feb 16, 2016 at 10:49:01AM +0300, Pavel Timofeev wrote: > 2016-02-15 15:28 GMT+03:00 Pavel Timofeev : > > > > 15 . 2016 . 14:00 "Slawa Olhovchenkov" > > : > > > > > >> > >> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote: > >> > >> > Hi! > >> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])?? > >> > >> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new > >> linuxulator import). > >> Chat and voice work good. > >> > >> > Seems like net-im/skype4 missing some dependencies and if it's > >> > satisfied net-im/skype4 hangs after start. > >> > linprocfs mounting doesn't help. > >> > I installed them all from the ports tree. > >> > Any experience? > >> > >> I am don't see this issue. > > > > Ok, thank you. I'll recheck. > > Well, I've managed to start skype4. > What I did is: > # mkdir -p /compat/linux/proc/ > add linprocfs to /etc/fstab > add linux_enable="YES" to /etc/rc.conf > # reboot > # portmaster /usr/ports/net-im/skype4 > Then I tried to start it and got: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libpulse-mainloop-glib.so.0: cannot open shared object file: No such > file or directory > Then I installed missing dependency: I am use poudriere build and all dependens present: # pkg info -d skype4 skype4-4.3.0.37,1: linux-skype_oss_wrapper-0.1.1 linux_base-c6-6.6_6 linux-c6-pulseaudio-libs-glib2-0.9.21 linux-c6-qt47-4.7.2_1 linux-c6-qt47-webkit-4.7.2_1 webcamd-4.2.0.9 linux-c6-libv4l-0.6.3_1 linux-c6-xorg-libs-7.4_3 linux-c6-expat-2.0.1_2 linux-c6-openssl-compat-0.9.8e_2 desktop-file-utils-0.22_3 linux-c6-fontconfig-2.8.0_1 linux-c6-qt47-x11-4.7.2_1 > # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs > And tried to start it again: > % skype > /usr/local/share/skype/skype: error while loading shared libraries: > libssl.so.10: cannot open shared object file: No such file or > directory > Installed another missing dependency: > # portmaster /usr/ports/security/linux-c6-openssl > And finally skype could start. > > So there are some missing dependencies. I've created a bug report. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207240 From owner-freebsd-stable@freebsd.org Tue Feb 16 10:17:32 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72D96AAA6B0 for ; Tue, 16 Feb 2016 10:17:32 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) 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 5E4201E9B for ; Tue, 16 Feb 2016 10:17:32 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id 5DA6AAAA6AF; Tue, 16 Feb 2016 10:17:32 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D37BAAA6AE for ; Tue, 16 Feb 2016 10:17:32 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from smtp.unipi.it (smtp2.unipi.it [131.114.21.21]) by mx1.freebsd.org (Postfix) with ESMTP id 250331E99 for ; Tue, 16 Feb 2016 10:17:30 +0000 (UTC) (envelope-from g.lettieri@iet.unipi.it) Received: from localhost (localhost [127.0.0.1]) by smtp.unipi.it (Postfix) with ESMTP id CE5C940903; Tue, 16 Feb 2016 11:17:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at unipi.it Received: from [10.216.1.203] (prova.iet.unipi.it [131.114.58.86]) (Authenticated User) by smtp.unipi.it (Postfix) with ESMTPSA id BCA934146D; Tue, 16 Feb 2016 11:17:28 +0100 (CET) Subject: Re: 82576 + NETMAP + VLAN To: Slawa Olhovchenkov References: <56B9E398.1060105@iet.unipi.it> <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> <56C1F69C.5010004@iet.unipi.it> <20160215214446.GE68298@zxy.spb.ru> Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" From: Giuseppe Lettieri Message-ID: <56C2F898.2010203@iet.unipi.it> Date: Tue, 16 Feb 2016 11:23:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160215214446.GE68298@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:17:32 -0000 I am sorry, I did not participate to the implementation of kqueue support and I am not able to comment. Luigi and Adrian should know, however. Cheers, Giuseppe Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: > On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: > >> Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: >>> On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: >>> >>>> Hi Slawa, >>>> >>>> I think WITNESS is seeing a false positive, since those two are always >>>> different mutexes. >>>> >>>> The actual deadlock you experience should be caused by something else. I >>> >>> Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. >> >> The deadlock I mentioned still involves nm_kn_locks, sorry if I was not >> clear about that. I am just saying that we never try to take the same >> lock that we already holding. >> >> Nonetheless, there are indeed problems in the path that WITNESS has >> seen. The problem is that pipes have to notify the other end while >> called by kevent. kevent holds the nm_kn_lock on the TX src ring and the >> notification takes the nm_kn_lock on the RX dst ring. > > Can you comment other issuses? Is this by design or is this bug? > > - with kevent sync for transmiting need first register > EVFILT_WRITE/EV_DISABLE and after every write > EVFILT_WRITE/EV_DISPATCH > > - with kevent sync all opening /dev/netmap and registering need do > from same thread as kevent using for sinc (unless no RX/TX). > > -- Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 1, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.lettieri@iet.unipi.it From owner-freebsd-stable@freebsd.org Tue Feb 16 10:30:32 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0BE7AAAC21 for ; Tue, 16 Feb 2016 10:30:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 9D2E314A5 for ; Tue, 16 Feb 2016 10:30:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 9A974AAAC20; Tue, 16 Feb 2016 10:30:32 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A449AAAC1F for ; Tue, 16 Feb 2016 10:30: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 5B2C614A4 for ; Tue, 16 Feb 2016 10:30: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 1aVcto-000KYN-FW; Tue, 16 Feb 2016 13:30:28 +0300 Date: Tue, 16 Feb 2016 13:30:28 +0300 From: Slawa Olhovchenkov To: Giuseppe Lettieri Cc: Luigi Rizzo , Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160216103028.GG68298@zxy.spb.ru> References: <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> <56C1F69C.5010004@iet.unipi.it> <20160215214446.GE68298@zxy.spb.ru> <56C2F898.2010203@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C2F898.2010203@iet.unipi.it> 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-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:30:32 -0000 On Tue, Feb 16, 2016 at 11:23:20AM +0100, Giuseppe Lettieri wrote: > I am sorry, I did not participate to the implementation of kqueue > support and I am not able to comment. Luigi and Adrian should know, however. Thanks! > Cheers, > Giuseppe > > Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: > > On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: > > > >> Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: > >>> On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: > >>> > >>>> Hi Slawa, > >>>> > >>>> I think WITNESS is seeing a false positive, since those two are always > >>>> different mutexes. > >>>> > >>>> The actual deadlock you experience should be caused by something else. I > >>> > >>> Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. > >> > >> The deadlock I mentioned still involves nm_kn_locks, sorry if I was not > >> clear about that. I am just saying that we never try to take the same > >> lock that we already holding. > >> > >> Nonetheless, there are indeed problems in the path that WITNESS has > >> seen. The problem is that pipes have to notify the other end while > >> called by kevent. kevent holds the nm_kn_lock on the TX src ring and the > >> notification takes the nm_kn_lock on the RX dst ring. > > > > Can you comment other issuses? Is this by design or is this bug? > > > > - with kevent sync for transmiting need first register > > EVFILT_WRITE/EV_DISABLE and after every write > > EVFILT_WRITE/EV_DISPATCH > > > > - with kevent sync all opening /dev/netmap and registering need do > > from same thread as kevent using for sinc (unless no RX/TX). > > > > > > > -- > Dr. Ing. Giuseppe Lettieri > Dipartimento di Ingegneria della Informazione > Universita' di Pisa > Largo Lucio Lazzarino 1, 56122 Pisa - Italy > Ph. : (+39) 050-2217.649 (direct) .599 (switch) > Fax : (+39) 050-2217.600 > e-mail: g.lettieri@iet.unipi.it From owner-freebsd-stable@freebsd.org Tue Feb 16 20:46:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 126AFAAB0C0 for ; Tue, 16 Feb 2016 20:46:53 +0000 (UTC) (envelope-from adrian.chadd@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 E550D15DD for ; Tue, 16 Feb 2016 20:46:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E15CBAAB0B3; Tue, 16 Feb 2016 20:46:52 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C71ECAAB0B0 for ; Tue, 16 Feb 2016 20:46:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 78EA115DC for ; Tue, 16 Feb 2016 20:46:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id z135so138517927iof.0 for ; Tue, 16 Feb 2016 12:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4kCwtcVXdj5sKEiQH4gRgWsaOXva8z9ce5HNWwPlibo=; b=KMWqZxj1mLdf4rq2Ut49irBrBpn5QpF3WzHz1p58zUTQ4oAxNLp+O7bZVSD4OukWAb 2yWNLGSkv2uFbqSP0ZkLGsAvUtqAZSpTqoERjFX4csnJCK/pLOcFWpXH9kCg1fnit1SG ELE55Uw5beAohrbOnK5fiUI+pRZsZ9BhLL8AuiwA6FxukVIx6ONDp2SLuYIWysYgwDhp x6grMyX1EAt76C4clWUYtA3gJMHGmsMvQrTLRaESGaZPtImyBxel7olg5Mq7DPFZMDM5 3UmHjf3WS0N8cZje4ENpQwIsub7EwXO5VKRndsr4RQoyRhdh32mxcKBKRBeewB2EAxs1 wm+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4kCwtcVXdj5sKEiQH4gRgWsaOXva8z9ce5HNWwPlibo=; b=OFfC5NS23YsqsF9Yr4jEg+MD/sLgIGfsmIpDllSbPIaASkcKLj411kvQPp+ScMpkrd ODewcx595Nv4wyPcIO8wAd9bfIpjk4FQ81RveoYEKmsfX/AqA9OIMeuzXXwLFitC/pjN TZrxWy+yATb7wWeMRLaDbqkTuPwfbax/8OXTfqMv0C56InYDtkUubkR3GATTA+Zgi0Zs 2Aer3Kl7tLjIwIYK4/Ob5BhMo670A0mcmJ9qrIwrslCfkVXKoaWNNsesPzAIocKkIHfz u25GaA4S28hWGcX608k37N+MGbd82OBdLmyIH+fG1dVra+1tDR+asdv3yV85SvEFTcZU Tt0g== X-Gm-Message-State: AG10YOT+Eg2ISwjBBhXGMSj07LlrAcIheWXHbNfrcnHH4Y0BV0eUA6wZYa8mF9CqyvmFhGAZvf28PkqVSXxONw== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr12396336ioe.123.1455655611880; Tue, 16 Feb 2016 12:46:51 -0800 (PST) Received: by 10.36.14.19 with HTTP; Tue, 16 Feb 2016 12:46:51 -0800 (PST) In-Reply-To: <20160216103028.GG68298@zxy.spb.ru> References: <20160210115937.GA37895@zxy.spb.ru> <56BB3C20.600@iet.unipi.it> <20160210135318.GL68298@zxy.spb.ru> <56BC505F.7080309@iet.unipi.it> <20160211133428.GM68298@zxy.spb.ru> <56C1EA66.807@iet.unipi.it> <20160215151318.GQ68298@zxy.spb.ru> <56C1F69C.5010004@iet.unipi.it> <20160215214446.GE68298@zxy.spb.ru> <56C2F898.2010203@iet.unipi.it> <20160216103028.GG68298@zxy.spb.ru> Date: Tue, 16 Feb 2016 12:46:51 -0800 Message-ID: Subject: Re: 82576 + NETMAP + VLAN From: Adrian Chadd To: Slawa Olhovchenkov Cc: Giuseppe Lettieri , Luigi Rizzo , "stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 20:46:53 -0000 hi, please bug me in a couple weeks. still moving house, etc. -a On 16 February 2016 at 02:30, Slawa Olhovchenkov wrote: > On Tue, Feb 16, 2016 at 11:23:20AM +0100, Giuseppe Lettieri wrote: > >> I am sorry, I did not participate to the implementation of kqueue >> support and I am not able to comment. Luigi and Adrian should know, however. > > Thanks! > >> Cheers, >> Giuseppe >> >> Il 15/02/2016 22:44, Slawa Olhovchenkov ha scritto: >> > On Mon, Feb 15, 2016 at 05:02:36PM +0100, Giuseppe Lettieri wrote: >> > >> >> Il 15/02/2016 16:13, Slawa Olhovchenkov ha scritto: >> >>> On Mon, Feb 15, 2016 at 04:10:30PM +0100, Giuseppe Lettieri wrote: >> >>> >> >>>> Hi Slawa, >> >>>> >> >>>> I think WITNESS is seeing a false positive, since those two are always >> >>>> different mutexes. >> >>>> >> >>>> The actual deadlock you experience should be caused by something else. I >> >>> >> >>> Are you sure? When deadlock occur I am see threads waiting on nm_kn_lock. >> >> >> >> The deadlock I mentioned still involves nm_kn_locks, sorry if I was not >> >> clear about that. I am just saying that we never try to take the same >> >> lock that we already holding. >> >> >> >> Nonetheless, there are indeed problems in the path that WITNESS has >> >> seen. The problem is that pipes have to notify the other end while >> >> called by kevent. kevent holds the nm_kn_lock on the TX src ring and the >> >> notification takes the nm_kn_lock on the RX dst ring. >> > >> > Can you comment other issuses? Is this by design or is this bug? >> > >> > - with kevent sync for transmiting need first register >> > EVFILT_WRITE/EV_DISABLE and after every write >> > EVFILT_WRITE/EV_DISPATCH >> > >> > - with kevent sync all opening /dev/netmap and registering need do >> > from same thread as kevent using for sinc (unless no RX/TX). >> > >> > >> >> >> -- >> Dr. Ing. Giuseppe Lettieri >> Dipartimento di Ingegneria della Informazione >> Universita' di Pisa >> Largo Lucio Lazzarino 1, 56122 Pisa - Italy >> Ph. : (+39) 050-2217.649 (direct) .599 (switch) >> Fax : (+39) 050-2217.600 >> e-mail: g.lettieri@iet.unipi.it From owner-freebsd-stable@freebsd.org Wed Feb 17 01:30:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A810AAB35B for ; Wed, 17 Feb 2016 01:30:43 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53D78198A for ; Wed, 17 Feb 2016 01:30:43 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-ig0-x22e.google.com with SMTP id y8so4461270igp.1 for ; Tue, 16 Feb 2016 17:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=/vub2zoYwbQ8nEQR/JdGS09OaG4HUpLPTW2EYJltHnk=; b=olaXwzlcgBbrbqywcnGW8DEzxAYSyiQuOqRc/9aIy890ZVeC0+lcp3FE+eBiO5NGqi /e0VYzBLa5ndiZCuJzM1qoKSyAv5GAU4/HqE2nwZ47XOZ7rZF3/kfGM6HiBUB7Q2V/yD nbJphSmAwwbx3jA5ygjMg0omoDfGs/RJkb5ks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=/vub2zoYwbQ8nEQR/JdGS09OaG4HUpLPTW2EYJltHnk=; b=Mm/zAqrDHjU1rdVu0LIoBViwZNkuVbzsq7rJx3bmzft8MHltIomRE5IW1fZEt9uMP4 0m8uMz8TrmO5d+i+XYByKGahrUGt0Urv1GGNg26/cbh2jWShybvkylhUjAyCiF7XLRC1 hagyQ9W2XGWIl7LvjYcSHG7TW8cMJYvXXvezHYj+73wM2CzlJ5aI4JqwmSACmOYVFbo2 1VBLpIaGA2n9srsz7hJLSlVzqe7yN9i6+RSj+s3nMzH0DDqYOv2OIQn0dT7Wt30Y2y+8 Wm+NOfdwH8Tagp/BW/KXc1jHjqHpfW6h8qDg/qEgwfoqoM8+HpUIaR9kJF68AdMn3+bS UXyQ== X-Gm-Message-State: AG10YOQPjrN9+oXtlyGT1YPRCAFSkTBtX+L5sUy0UfSxkRelqDQo3UX9Ta/zeEgwXCf93CBI78eb2vxOBM7m1w== X-Received: by 10.50.73.199 with SMTP id n7mr21277531igv.74.1455672642625; Tue, 16 Feb 2016 17:30:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.244.143 with HTTP; Tue, 16 Feb 2016 17:30:23 -0800 (PST) From: Mahmoud Al-Qudsi Date: Tue, 16 Feb 2016 19:30:23 -0600 Message-ID: Subject: 7 LOR dumps related to ufs, tmpfs, igmp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 01:30:43 -0000 Hello all, I'm including below a list of LORs that I experienced running an x86 build of 10.2-RELEASE-p2. Some known LORs are also included for posterity's sake, as all are from a single session and appear in chronological order, should this information be of any additional use. I believe from a bit of hunting around that not all are documented/known-ok. Also, one is repeated below. I thought of submitting a separate email for each, but did not want to clutter the mailing list with needless "spam." Pardon the long lines. Thanks, Mahmoud 1st 0xc6aaa46c ufs (ufs) @ sys/kern/vfs_mount.c:1227 2nd 0xc6aaa5d4 devfs (devfs) @ sys/kern/vfs_subr.c:2285 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,632e7262,3832323a,c0000a35,db7df750,...) at db_trace_self_wrapper+0x2d/frame 0xdb7df708 kdb_backtrace(c120e109,c6aaa5d4,c11ffba6,c65ae7f0,c1217ba8,...) at kdb_backtrace+0x30/frame 0xdb7df76c witness_checkorder(c6aaa5d4,9,c1217ba8,8ed,c6aaa640,...) at witness_checkorder+0xd4f/frame 0xdb7df7b8 __lockmgr_args(c6aaa5d4,80100,c6aaa640,0,0,0,c1217ba8,8ed) at __lockmgr_args+0x8d4/frame 0xdb7df894 vop_stdlock(db7df908,c1486da8,c16d26e8,8,c1759564,...) at vop_stdlock+0x53/frame 0xdb7df8c4 VOP_LOCK1_APV(c14756ac,db7df908,c0b39b31,c1759554,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xdb7df8f0 _vn_lock(c6aaa5a0,80100,c1217ba8,8ed,db7df974,...) at _vn_lock+0xca/frame 0xdb7df930 vputx(c6aaa5a0,0,c11faeb6,20e,0,...) at vputx+0x37a/frame 0xdb7df974 cd9660_unmount(c6ed5000,8080000,db7df9e0,510,c1486da8,...) at cd9660_unmount+0x1dc/frame 0xdb7df9a8 dounmount(c6ed5000,8080000,c6eab310,48f,db7dfa58,...) at dounmount+0x5fa/frame 0xdb7dfa08 sys_unmount(c6eab310,db7dfb68,c6e9c304,d6,c108d221,...) at sys_unmount+0x3bb/frame 0xdb7dfad8 syscall(db7dfba8) at syscall+0x336/frame 0xdb7dfb9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7dfb9c --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x853d873, esp = 0xbfbfe6d4, ebp = 0xbfbfe7a0 --- lock order reversal: 1st 0xc7d9da0c tmpfs (tmpfs) @ sys/kern/vfs_mount.c:848 2nd 0xc7e9473c ufs (ufs) @ sys/kern/vfs_subr.c:2174 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,3731323a,34000a34,a38,0,...) at db_trace_self_wrapper+0x2d/frame 0xdb7e3578 kdb_backtrace(c120e109,c7e9473c,c11f31cd,c65ae928,c1217ba8,...) at kdb_backtrace+0x30/frame 0xdb7e35dc witness_checkorder(c7e9473c,9,c1217ba8,87e,c7e947a8,...) at witness_checkorder+0xd4f/frame 0xdb7e3628 __lockmgr_args(c7e9473c,80100,c7e947a8,0,0,...) at __lockmgr_args+0x8d4/frame 0xdb7e3708 ffs_lock(db7e3788,c65a6248,c65acb80,c65a6248,c16d10e8,...) at ffs_lock+0x97/frame 0xdb7e3744 VOP_LOCK1_APV(c14ae018,db7e3788,c65a8468,ffffffff,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xdb7e3770 _vn_lock(c7e94708,80100,c1217ba8,87e,57,...) at _vn_lock+0xca/frame 0xdb7e37b0 vget(c7e94708,80100,c6daec40,57,0,...) at vget+0x77/frame 0xdb7e37e4 vfs_hash_get(c70025d8,2,80000,c6daec40,db7e38a4,...) at vfs_hash_get+0xff/frame 0xdb7e3810 ffs_vgetf(c70025d8,2,80000,db7e38a4,0) at ffs_vgetf+0x44/frame 0xdb7e386c ffs_vget(c70025d8,2,80000,db7e38a4,c16fe418,...) at ffs_vget+0x2f/frame 0xdb7e388c ufs_root(c70025d8,80000,db7e3a90,359,c6f12390,...) at ufs_root+0x49/frame 0xdb7e38b0 vfs_donmount(c6daec40,0,0,c6ea8100,c6ea8100,...) at vfs_donmount+0x13a7/frame 0xdb7e3ab0 sys_nmount(c6daec40,db7e3b68,c6cd2000,d6,e2,...) at sys_nmount+0x78/frame 0xdb7e3ad8 syscall(db7e3ba8) at syscall+0x336/frame 0xdb7e3b9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7e3b9c --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x280dc9eb, esp = 0xbfbfdda0, ebp = 0xbfbfe2f8 --- lock order reversal: 1st 0xc69bba3c if_addr_lock (if_addr_lock) @ sys/netinet/igmp.c:1710 2nd 0xc175d718 ifnet_rw (ifnet_rw) @ sys/net/if.c:244 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,3a632e66,a343432,692f7400,2e706d67,...) at db_trace_self_wrapper+0x2d/frame 0xdab56720 kdb_backtrace(c120e109,c175d718,c121cefe,c65aa960,c121c998,...) at kdb_backtrace+0x30/frame 0xdab56784 witness_checkorder(c175d718,1,c121c998,f4,0,...) at witness_checkorder+0xd4f/frame 0xdab567d0 __rw_rlock(c175d728,c121c998,f4,c771f500,dab568dc,...) at __rw_rlock+0x92/frame 0xdab56858 ifnet_byindex(1,c12454ce,da,c65ab4c0,c26be200,...) at ifnet_byindex+0x23/frame 0xdab56870 igmp_intr(c771f500,c6d95c00,dab56930,c0e06833,c26c3900,...) at igmp_intr+0x1e/frame 0xdab568dc netisr_dispatch_src(2,0,c771f500) at netisr_dispatch_src+0xb6/frame 0xdab5691c netisr_dispatch(2,c771f500,0,89a,dab56978,...) at netisr_dispatch+0x20/frame 0xdab56930 igmp_v1v2_queue_report(c175d8dc,4,c122a604,6e4,c175a310,...) at igmp_v1v2_queue_report+0x1a9/frame 0xdab56978 igmp_fasttimo(dab56a50,c0b3a7cc,c175a300,dab56a50,c0b6421d,...) at igmp_fasttimo+0x417/frame 0xdab56a1c pffasttimo(0,0,c12073f5,285,c0b813be,...) at pffasttimo+0x30/frame 0xdab56a50 softclock_call_cc(0,0,c12073f5,32b,0,...) at softclock_call_cc+0x1ac/frame 0xdab56aec softclock(c175a300,c11fe255,566,78e5b803,c66e5f48,...) at softclock+0x40/frame 0xdab56b0c intr_event_execute_handlers(c1591590,c66e5f00,c11fe255,566,8,...) at intr_event_execute_handlers+0x8b/frame 0xdab56b34 ithread_loop(c65a3260,dab56ba8,c11fdfa8,3f2,0,...) at ithread_loop+0x90/frame 0xdab56b6c fork_exit(c0b1e6d0,c65a3260,dab56ba8) at fork_exit+0x7f/frame 0xdab56b94 fork_trampoline() at fork_trampoline+0x8/frame 0xdab56b94 --- trap 0, eip = 0, esp = 0xdab56be0, ebp = 0 --- lock order reversal: 1st 0xc724ce44 tmpfs (tmpfs) @ sys/kern/vfs_mount.c:1227 2nd 0xc9a2c19c syncer (syncer) @ sys/kern/vfs_subr.c:2285 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,72627573,323a632e,a353832,e769f700,...) at db_trace_self_wrapper+0x2d/frame 0xe769f738 kdb_backtrace(c120e109,c9a2c19c,c121829f,c65aed38,c1217ba8,...) at kdb_backtrace+0x30/frame 0xe769f79c witness_checkorder(c9a2c19c,9,c1217ba8,8ed,c9a2c208,...) at witness_checkorder+0xd4f/frame 0xe769f7e8 __lockmgr_args(c9a2c19c,80100,c9a2c208,0,0,0,c1217ba8,8ed) at __lockmgr_args+0x8d4/frame 0xe769f8c4 vop_stdlock(e769f938,246,1,e769f954,c65aecd0,...) at vop_stdlock+0x53/frame 0xe769f8f4 VOP_LOCK1_APV(c14918d4,e769f938,c0b39b31,c9a2c208,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xe769f920 _vn_lock(c9a2c168,80100,c1217ba8,8ed,c6d04930,...) at _vn_lock+0xca/frame 0xe769f960 vputx(c70068c4,0,c1217148,510,c1486da8,...) at vputx+0x37a/frame 0xe769f9a8 dounmount(c70068c4,8000000,c6d04930,48f,e769fa58,...) at dounmount+0x4bf/frame 0xe769fa08 sys_unmount(c6d04930,e769fb68,c937a304,d6,c108d221,...) at sys_unmount+0x3bb/frame 0xe769fad8 syscall(e769fba8) at syscall+0x336/frame 0xe769fb9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe769fb9c --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x280c93eb, esp = 0xbfbfe5d4, ebp = 0xbfbfe6a0 --- lock order reversal: 1st 0xc724ce44 tmpfs (tmpfs) @ sys/kern/vfs_mount.c:1227 2nd 0xc9a2c5d4 devfs (devfs) @ sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,7366765f,2e73706f,33313a63,a3537,...) at db_trace_self_wrapper+0x2d/frame 0xe769f668 kdb_backtrace(c120e109,c9a2c5d4,c11ffba6,c65ae7f0,c12425cd,...) at kdb_backtrace+0x30/frame 0xe769f6cc witness_checkorder(c9a2c5d4,9,c12425cd,55f,0,...) at witness_checkorder+0xd4f/frame 0xe769f718 __lockmgr_args(c9a2c5d4,80400,c9a2c640,0,0,0,c12425cd,55f) at __lockmgr_args+0x8d4/frame 0xe769f7f4 vop_stdlock(e769f868,c0baeb8e,c15a59ec,4,c15a59dc,...) at vop_stdlock+0x53/frame 0xe769f824 VOP_LOCK1_APV(c14756ac,e769f868,0,0,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xe769f850 _vn_lock(c9a2c5a0,80400,c12425cd,55f,1,...) at _vn_lock+0xca/frame 0xe769f890 ffs_flushfiles(c70068c4,8,c6d04930,e769f920,c0b5460d,...) at ffs_flushfiles+0x151/frame 0xe769f8e0 softdep_flushfiles(c70068c4,0,c6d04930,0,0,...) at softdep_flushfiles+0x8b/frame 0xe769f960 ffs_unmount(c70068c4,8000000,c1217148,510,c1486da8,...) at ffs_unmount+0x7b/frame 0xe769f9a8 dounmount(c70068c4,8000000,c6d04930,48f,e769fa58,...) at dounmount+0x5fa/frame 0xe769fa08 sys_unmount(c6d04930,e769fb68,c937a304,d6,c108d221,...) at sys_unmount+0x3bb/frame 0xe769fad8 syscall(e769fba8) at syscall+0x336/frame 0xe769fb9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe769fb9c --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x280c93eb, esp = 0xbfbfe5d4, ebp = 0xbfbfe6a0 --- lock order reversal: 1st 0xda98da2c bufwait (bufwait) @ sys/kern/vfs_bio.c:3124 2nd 0xc754e200 dirhash (dirhash) @ sys/ufs/ufs/ufs_dirhash.c:280 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,7366752f,7269645f,68736168,323a632e,...) at db_trace_self_wrapper+0x2d/frame 0xe9bb55d0 kdb_backtrace(c120e109,c754e200,c1243661,c65ae990,c1243289,...) at kdb_backtrace+0x30/frame 0xe9bb5634 witness_checkorder(c754e200,9,c1243289,118,0,...) at witness_checkorder+0xd4f/frame 0xe9bb5680 _sx_xlock(c754e200,0,c1243289,118,c7c9b000,...) at _sx_xlock+0x75/frame 0xe9bb56b0 ufsdirhash_add(c8173ca8,e9bb57d0,724,e9bb5730,e9bb5734,...) at ufsdirhash_add+0x4a/frame 0xe9bb56e0 ufs_direnter(c814f9d8,0,e9bb57d0,e9bb59d4,0,...) at ufs_direnter+0x604/frame 0xe9bb5760 ufs_rename(e9bb5a88,c14c2ce0,c899c9d8,e9bb5a84,c1486da8,...) at ufs_rename+0x1017/frame 0xe9bb590c VOP_RENAME_APV(c14ae018,e9bb5a88,0,1,e9bb59d4,...) at VOP_RENAME_APV+0x104/frame 0xe9bb5938 kern_renameat(c720d310,ffffff9c,bfbfcbc0,ffffff9c,bfbfd3c0,0) at kern_renameat+0x55b/frame 0xe9bb5ab8 sys_rename(c720d310,e9bb5b68,dab2dc90,e9bb5b30,c108d221,...) at sys_rename+0x39/frame 0xe9bb5ad8 syscall(e9bb5ba8) at syscall+0x336/frame 0xe9bb5b9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe9bb5b9c --- syscall (128, FreeBSD ELF32, sys_rename), eip = 0x281261fb, esp = 0xbfbfc61c, ebp = 0xbfbfc704 --- lock order reversal: 1st 0xc814fa0c ufs (ufs) @ sys/kern/vfs_subr.c:2174 2nd 0xda98da2c bufwait (bufwait) @ sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc9f71cdc ufs (ufs) @ sys/kern/vfs_subr.c:2174 KDB: stack backtrace: db_trace_self_wrapper(c120a33c,3731323a,6f000a34,632e7370,3236323a,...) at db_trace_self_wrapper+0x2d/frame 0xe9bb50e8 kdb_backtrace(c120e122,c9f71cdc,c11f31cd,c65ae928,c1217ba8,...) at kdb_backtrace+0x30/frame 0xe9bb514c witness_checkorder(c9f71cdc,9,c1217ba8,87e,c9f71d48,...) at witness_checkorder+0xd4f/frame 0xe9bb5198 __lockmgr_args(c9f71cdc,80100,c9f71d48,0,0,...) at __lockmgr_args+0x8d4/frame 0xe9bb5278 ffs_lock(e9bb52f8,c15a0bcc,c65a6248,c65acb80,c65a6248,...) at ffs_lock+0x97/frame 0xe9bb52b4 VOP_LOCK1_APV(c14ae018,e9bb52f8,104,1b9,c14c28c0,...) at VOP_LOCK1_APV+0x10a/frame 0xe9bb52e0 _vn_lock(c9f71ca8,80100,c1217ba8,87e,c1216d59,...) at _vn_lock+0xca/frame 0xe9bb5320 vget(c9f71ca8,80100,c720d310,57,0,...) at vget+0x77/frame 0xe9bb5358 vfs_hash_get(c70012ec,1fd924,80000,c720d310,e9bb5458,...) at vfs_hash_get+0xff/frame 0xe9bb5384 ffs_vgetf(c70012ec,1fd924,80000,e9bb5458,1,...) at ffs_vgetf+0x44/frame 0xe9bb53e0 softdep_sync_buf(c814f9d8,da98d9d4,1,0,0,...) at softdep_sync_buf+0xac7/frame 0xe9bb5470 ffs_syncvnode(c814f9d8,1,0,0,c1488968,...) at ffs_syncvnode+0x2dd/frame 0xe9bb54c8 ffs_truncate(c814f9d8,2a00,0,880,c771e200,...) at ffs_truncate+0x70e/frame 0xe9bb5678 ufs_direnter(c814f9d8,c9f7b000,e9bb5740,e9bb5a64,0,...) at ufs_direnter+0x79e/frame 0xe9bb56f8 ufs_makeinode(e9bb5a50,e9bb5a64,c814f9d8,c14c09b8,c814f9d8,...) at ufs_makeinode+0x534/frame 0xe9bb5874 ufs_create(e9bb5970,c13da585,c123c2ce,c70012fc,2,...) at ufs_create+0x30/frame 0xe9bb5898 VOP_CREATE_APV(c14ae018,e9bb5970,e9bb5a64,e9bb5900,c0b3a060,...) at VOP_CREATE_APV+0x12f/frame 0xe9bb58c8 vn_open_cred(e9bb5a08,e9bb5a94,180,0,c771e200,c6eedaf0) at vn_open_cred+0x2f9/frame 0xe9bb5998 vn_open(e9bb5a08,e9bb5a94,180,c6eedaf0,bfbfcbc0,...) at vn_open+0x3d/frame 0xe9bb59c0 kern_openat(c720d310,ffffff9c,bfbfcbc0,0,a02,180) at kern_openat+0x310/frame 0xe9bb5ab4 sys_open(c720d310,e9bb5b68,dab27c90,e9bb5b30,c108d221,...) at sys_open+0x39/frame 0xe9bb5ad8 syscall(e9bb5ba8) at syscall+0x336/frame 0xe9bb5b9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe9bb5b9c --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x281f4ac3, esp = 0xbfbfc25c, ebp = 0xbfbfc708 --- From owner-freebsd-stable@freebsd.org Wed Feb 17 01:34:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F6E7AAB601 for ; Wed, 17 Feb 2016 01:34:59 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 1B8611D16 for ; Wed, 17 Feb 2016 01:34:59 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-io0-x230.google.com with SMTP id z135so14102589iof.0 for ; Tue, 16 Feb 2016 17:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=uLMQy0aiemOYcfdZSdN37/S2fj3abdbVaHiaKPTcsow=; b=e0sVkUjq96BamMfBFBisHF6zLp//7g7v+r6VvEih4Q2jlwiE3wDQmZjKVd/BE/WuBE H7tY95c96Iw+tXtifQ8VrdFHLwNZgH6sxvvHFQr84kMlYs1H5fx0+x4UAEWH6lN57hY8 gLWj9BTnwvzNYL0WYdZQyw9wbzu8QaUG6UnsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=uLMQy0aiemOYcfdZSdN37/S2fj3abdbVaHiaKPTcsow=; b=R/pzv1HBnHJ8ErF0WCilH5Eda1Iq9bQWVMuGq5TmFMSGUONUpUyeqJ7/Ya15ksrrN+ tD8ewCaMNPOgc8i09pKfVjq0F2zr6P+h38b8LZhoJv3jxZr797ladC5czweXKCs9uPBH IRGoSaqTaGBqGjC07qvlygj4AXKnvkncnssC8xkZPRMSulq0eZPY+lp7GmSQknHY4pbQ cVgmh5Hgv99OIR8mRzjPh1o5ispSNiE4nfNDGcAXP+NPZmSZLmwJX2OBClaabgpokP7h jlGvmw+saVzYsPHkLdMI04RjslikMNyK0oVdY2iti4pG/9khDqhQLOIOSSNoT6WFbC5a YgNg== X-Gm-Message-State: AG10YOSyr1jTH4+LWrmuJ3Y19zbn0XvWdJSh4uNiNXJJTxWn0VPN11PRNibsvsn9ETUmuU5cZKpqFHv3Jd76nw== X-Received: by 10.107.17.147 with SMTP id 19mr685542ior.109.1455672898533; Tue, 16 Feb 2016 17:34:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.244.143 with HTTP; Tue, 16 Feb 2016 17:34:38 -0800 (PST) In-Reply-To: References: From: Mahmoud Al-Qudsi Date: Tue, 16 Feb 2016 19:34:38 -0600 Message-ID: Subject: Re: 7 LOR dumps related to ufs, tmpfs, igmp To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=001a113ff326070156052bed42bf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 01:34:59 -0000 --001a113ff326070156052bed42bf Content-Type: text/plain; charset=UTF-8 Apologies. The mail server is truncating the text. Attached as a TXT. On Tue, Feb 16, 2016 at 7:30 PM, Mahmoud Al-Qudsi wrote: > Hello all, > > I'm including below a list of LORs that I experienced running an x86 > build of 10.2-RELEASE-p2. > > Some known LORs are also included for posterity's sake, as all are from > a single session and appear in chronological order, should this > information be of any additional use. I believe from a bit of hunting around > that not all are documented/known-ok. Also, one is repeated below. > > I thought of submitting a separate email for each, but did not want to > clutter the mailing list with needless "spam." > > Pardon the long lines. > > Thanks, > > Mahmoud > > > 1st 0xc6aaa46c ufs (ufs) @ sys/kern/vfs_mount.c:1227 > 2nd 0xc6aaa5d4 devfs (devfs) @ sys/kern/vfs_subr.c:2285 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,632e7262,3832323a,c0000a35,db7df750,...) > at db_trace_self_wrapper+0x2d/frame 0xdb7df708 > kdb_backtrace(c120e109,c6aaa5d4,c11ffba6,c65ae7f0,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xdb7df76c > witness_checkorder(c6aaa5d4,9,c1217ba8,8ed,c6aaa640,...) at > witness_checkorder+0xd4f/frame 0xdb7df7b8 > __lockmgr_args(c6aaa5d4,80100,c6aaa640,0,0,0,c1217ba8,8ed) at > __lockmgr_args+0x8d4/frame 0xdb7df894 > vop_stdlock(db7df908,c1486da8,c16d26e8,8,c1759564,...) at > vop_stdlock+0x53/frame 0xdb7df8c4 > VOP_LOCK1_APV(c14756ac,db7df908,c0b39b31,c1759554,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xdb7df8f0 > _vn_lock(c6aaa5a0,80100,c1217ba8,8ed,db7df974,...) at > _vn_lock+0xca/frame 0xdb7df930 > vputx(c6aaa5a0,0,c11faeb6,20e,0,...) at vputx+0x37a/frame 0xdb7df974 > cd9660_unmount(c6ed5000,8080000,db7df9e0,510,c1486da8,...) at > cd9660_unmount+0x1dc/frame 0xdb7df9a8 > dounmount(c6ed5000,8080000,c6eab310,48f,db7dfa58,...) at > dounmount+0x5fa/frame 0xdb7dfa08 > sys_unmount(c6eab310,db7dfb68,c6e9c304,d6,c108d221,...) at > sys_unmount+0x3bb/frame 0xdb7dfad8 > syscall(db7dfba8) at syscall+0x336/frame 0xdb7dfb9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7dfb9c > --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x853d873, esp = > 0xbfbfe6d4, ebp = 0xbfbfe7a0 --- > > > lock order reversal: > 1st 0xc7d9da0c tmpfs (tmpfs) @ sys/kern/vfs_mount.c:848 > 2nd 0xc7e9473c ufs (ufs) @ sys/kern/vfs_subr.c:2174 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,3731323a,34000a34,a38,0,...) at > db_trace_self_wrapper+0x2d/frame 0xdb7e3578 > kdb_backtrace(c120e109,c7e9473c,c11f31cd,c65ae928,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xdb7e35dc > witness_checkorder(c7e9473c,9,c1217ba8,87e,c7e947a8,...) at > witness_checkorder+0xd4f/frame 0xdb7e3628 > __lockmgr_args(c7e9473c,80100,c7e947a8,0,0,...) at > __lockmgr_args+0x8d4/frame 0xdb7e3708 > ffs_lock(db7e3788,c65a6248,c65acb80,c65a6248,c16d10e8,...) at > ffs_lock+0x97/frame 0xdb7e3744 > VOP_LOCK1_APV(c14ae018,db7e3788,c65a8468,ffffffff,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xdb7e3770 > _vn_lock(c7e94708,80100,c1217ba8,87e,57,...) at _vn_lock+0xca/frame 0xdb7e37b0 > vget(c7e94708,80100,c6daec40,57,0,...) at vget+0x77/frame 0xdb7e37e4 > vfs_hash_get(c70025d8,2,80000,c6daec40,db7e38a4,...) at > vfs_hash_get+0xff/frame 0xdb7e3810 > ffs_vgetf(c70025d8,2,80000,db7e38a4,0) at ffs_vgetf+0x44/frame 0xdb7e386c > ffs_vget(c70025d8,2,80000,db7e38a4,c16fe418,...) at > ffs_vget+0x2f/frame 0xdb7e388c > ufs_root(c70025d8,80000,db7e3a90,359,c6f12390,...) at > ufs_root+0x49/frame 0xdb7e38b0 > vfs_donmount(c6daec40,0,0,c6ea8100,c6ea8100,...) at > vfs_donmount+0x13a7/frame 0xdb7e3ab0 > sys_nmount(c6daec40,db7e3b68,c6cd2000,d6,e2,...) at > sys_nmount+0x78/frame 0xdb7e3ad8 > syscall(db7e3ba8) at syscall+0x336/frame 0xdb7e3b9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdb7e3b9c > --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x280dc9eb, esp = > 0xbfbfdda0, ebp = 0xbfbfe2f8 --- > > > > lock order reversal: > 1st 0xc69bba3c if_addr_lock (if_addr_lock) @ sys/netinet/igmp.c:1710 > 2nd 0xc175d718 ifnet_rw (ifnet_rw) @ sys/net/if.c:244 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,3a632e66,a343432,692f7400,2e706d67,...) > at db_trace_self_wrapper+0x2d/frame 0xdab56720 > kdb_backtrace(c120e109,c175d718,c121cefe,c65aa960,c121c998,...) at > kdb_backtrace+0x30/frame 0xdab56784 > witness_checkorder(c175d718,1,c121c998,f4,0,...) at > witness_checkorder+0xd4f/frame 0xdab567d0 > __rw_rlock(c175d728,c121c998,f4,c771f500,dab568dc,...) at > __rw_rlock+0x92/frame 0xdab56858 > ifnet_byindex(1,c12454ce,da,c65ab4c0,c26be200,...) at > ifnet_byindex+0x23/frame 0xdab56870 > igmp_intr(c771f500,c6d95c00,dab56930,c0e06833,c26c3900,...) at > igmp_intr+0x1e/frame 0xdab568dc > netisr_dispatch_src(2,0,c771f500) at netisr_dispatch_src+0xb6/frame 0xdab5691c > netisr_dispatch(2,c771f500,0,89a,dab56978,...) at > netisr_dispatch+0x20/frame 0xdab56930 > igmp_v1v2_queue_report(c175d8dc,4,c122a604,6e4,c175a310,...) at > igmp_v1v2_queue_report+0x1a9/frame 0xdab56978 > igmp_fasttimo(dab56a50,c0b3a7cc,c175a300,dab56a50,c0b6421d,...) at > igmp_fasttimo+0x417/frame 0xdab56a1c > pffasttimo(0,0,c12073f5,285,c0b813be,...) at pffasttimo+0x30/frame 0xdab56a50 > softclock_call_cc(0,0,c12073f5,32b,0,...) at > softclock_call_cc+0x1ac/frame 0xdab56aec > softclock(c175a300,c11fe255,566,78e5b803,c66e5f48,...) at > softclock+0x40/frame 0xdab56b0c > intr_event_execute_handlers(c1591590,c66e5f00,c11fe255,566,8,...) at > intr_event_execute_handlers+0x8b/frame 0xdab56b34 > ithread_loop(c65a3260,dab56ba8,c11fdfa8,3f2,0,...) at > ithread_loop+0x90/frame 0xdab56b6c > fork_exit(c0b1e6d0,c65a3260,dab56ba8) at fork_exit+0x7f/frame 0xdab56b94 > fork_trampoline() at fork_trampoline+0x8/frame 0xdab56b94 > --- trap 0, eip = 0, esp = 0xdab56be0, ebp = 0 --- > > > > lock order reversal: > 1st 0xc724ce44 tmpfs (tmpfs) @ sys/kern/vfs_mount.c:1227 > 2nd 0xc9a2c19c syncer (syncer) @ sys/kern/vfs_subr.c:2285 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,72627573,323a632e,a353832,e769f700,...) > at db_trace_self_wrapper+0x2d/frame 0xe769f738 > kdb_backtrace(c120e109,c9a2c19c,c121829f,c65aed38,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xe769f79c > witness_checkorder(c9a2c19c,9,c1217ba8,8ed,c9a2c208,...) at > witness_checkorder+0xd4f/frame 0xe769f7e8 > __lockmgr_args(c9a2c19c,80100,c9a2c208,0,0,0,c1217ba8,8ed) at > __lockmgr_args+0x8d4/frame 0xe769f8c4 > vop_stdlock(e769f938,246,1,e769f954,c65aecd0,...) at > vop_stdlock+0x53/frame 0xe769f8f4 > VOP_LOCK1_APV(c14918d4,e769f938,c0b39b31,c9a2c208,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xe769f920 > _vn_lock(c9a2c168,80100,c1217ba8,8ed,c6d04930,...) at > _vn_lock+0xca/frame 0xe769f960 > vputx(c70068c4,0,c1217148,510,c1486da8,...) at vputx+0x37a/frame 0xe769f9a8 > dounmount(c70068c4,8000000,c6d04930,48f,e769fa58,...) at > dounmount+0x4bf/frame 0xe769fa08 > sys_unmount(c6d04930,e769fb68,c937a304,d6,c108d221,...) at > sys_unmount+0x3bb/frame 0xe769fad8 > syscall(e769fba8) at syscall+0x336/frame 0xe769fb9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe769fb9c > --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x280c93eb, esp = > 0xbfbfe5d4, ebp = 0xbfbfe6a0 --- > > > > > > lock order reversal: > 1st 0xc724ce44 tmpfs (tmpfs) @ sys/kern/vfs_mount.c:1227 > 2nd 0xc9a2c5d4 devfs (devfs) @ sys/ufs/ffs/ffs_vfsops.c:1375 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,7366765f,2e73706f,33313a63,a3537,...) > at db_trace_self_wrapper+0x2d/frame 0xe769f668 > kdb_backtrace(c120e109,c9a2c5d4,c11ffba6,c65ae7f0,c12425cd,...) at > kdb_backtrace+0x30/frame 0xe769f6cc > witness_checkorder(c9a2c5d4,9,c12425cd,55f,0,...) at > witness_checkorder+0xd4f/frame 0xe769f718 > __lockmgr_args(c9a2c5d4,80400,c9a2c640,0,0,0,c12425cd,55f) at > __lockmgr_args+0x8d4/frame 0xe769f7f4 > vop_stdlock(e769f868,c0baeb8e,c15a59ec,4,c15a59dc,...) at > vop_stdlock+0x53/frame 0xe769f824 > VOP_LOCK1_APV(c14756ac,e769f868,0,0,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xe769f850 > _vn_lock(c9a2c5a0,80400,c12425cd,55f,1,...) at _vn_lock+0xca/frame 0xe769f890 > ffs_flushfiles(c70068c4,8,c6d04930,e769f920,c0b5460d,...) at > ffs_flushfiles+0x151/frame 0xe769f8e0 > softdep_flushfiles(c70068c4,0,c6d04930,0,0,...) at > softdep_flushfiles+0x8b/frame 0xe769f960 > ffs_unmount(c70068c4,8000000,c1217148,510,c1486da8,...) at > ffs_unmount+0x7b/frame 0xe769f9a8 > dounmount(c70068c4,8000000,c6d04930,48f,e769fa58,...) at > dounmount+0x5fa/frame 0xe769fa08 > sys_unmount(c6d04930,e769fb68,c937a304,d6,c108d221,...) at > sys_unmount+0x3bb/frame 0xe769fad8 > syscall(e769fba8) at syscall+0x336/frame 0xe769fb9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe769fb9c > --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x280c93eb, esp = > 0xbfbfe5d4, ebp = 0xbfbfe6a0 --- > > > > lock order reversal: > 1st 0xda98da2c bufwait (bufwait) @ sys/kern/vfs_bio.c:3124 > 2nd 0xc754e200 dirhash (dirhash) @ sys/ufs/ufs/ufs_dirhash.c:280 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,7366752f,7269645f,68736168,323a632e,...) > at db_trace_self_wrapper+0x2d/frame 0xe9bb55d0 > kdb_backtrace(c120e109,c754e200,c1243661,c65ae990,c1243289,...) at > kdb_backtrace+0x30/frame 0xe9bb5634 > witness_checkorder(c754e200,9,c1243289,118,0,...) at > witness_checkorder+0xd4f/frame 0xe9bb5680 > _sx_xlock(c754e200,0,c1243289,118,c7c9b000,...) at > _sx_xlock+0x75/frame 0xe9bb56b0 > ufsdirhash_add(c8173ca8,e9bb57d0,724,e9bb5730,e9bb5734,...) at > ufsdirhash_add+0x4a/frame 0xe9bb56e0 > ufs_direnter(c814f9d8,0,e9bb57d0,e9bb59d4,0,...) at > ufs_direnter+0x604/frame 0xe9bb5760 > ufs_rename(e9bb5a88,c14c2ce0,c899c9d8,e9bb5a84,c1486da8,...) at > ufs_rename+0x1017/frame 0xe9bb590c > VOP_RENAME_APV(c14ae018,e9bb5a88,0,1,e9bb59d4,...) at > VOP_RENAME_APV+0x104/frame 0xe9bb5938 > kern_renameat(c720d310,ffffff9c,bfbfcbc0,ffffff9c,bfbfd3c0,0) at > kern_renameat+0x55b/frame 0xe9bb5ab8 > sys_rename(c720d310,e9bb5b68,dab2dc90,e9bb5b30,c108d221,...) at > sys_rename+0x39/frame 0xe9bb5ad8 > syscall(e9bb5ba8) at syscall+0x336/frame 0xe9bb5b9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe9bb5b9c > --- syscall (128, FreeBSD ELF32, sys_rename), eip = 0x281261fb, esp = > 0xbfbfc61c, ebp = 0xbfbfc704 --- > > > > lock order reversal: > 1st 0xc814fa0c ufs (ufs) @ sys/kern/vfs_subr.c:2174 > 2nd 0xda98da2c bufwait (bufwait) @ sys/ufs/ffs/ffs_vnops.c:262 > 3rd 0xc9f71cdc ufs (ufs) @ sys/kern/vfs_subr.c:2174 > KDB: stack backtrace: > db_trace_self_wrapper(c120a33c,3731323a,6f000a34,632e7370,3236323a,...) > at db_trace_self_wrapper+0x2d/frame 0xe9bb50e8 > kdb_backtrace(c120e122,c9f71cdc,c11f31cd,c65ae928,c1217ba8,...) at > kdb_backtrace+0x30/frame 0xe9bb514c > witness_checkorder(c9f71cdc,9,c1217ba8,87e,c9f71d48,...) at > witness_checkorder+0xd4f/frame 0xe9bb5198 > __lockmgr_args(c9f71cdc,80100,c9f71d48,0,0,...) at > __lockmgr_args+0x8d4/frame 0xe9bb5278 > ffs_lock(e9bb52f8,c15a0bcc,c65a6248,c65acb80,c65a6248,...) at > ffs_lock+0x97/frame 0xe9bb52b4 > VOP_LOCK1_APV(c14ae018,e9bb52f8,104,1b9,c14c28c0,...) at > VOP_LOCK1_APV+0x10a/frame 0xe9bb52e0 > _vn_lock(c9f71ca8,80100,c1217ba8,87e,c1216d59,...) at > _vn_lock+0xca/frame 0xe9bb5320 > vget(c9f71ca8,80100,c720d310,57,0,...) at vget+0x77/frame 0xe9bb5358 > vfs_hash_get(c70012ec,1fd924,80000,c720d310,e9bb5458,...) at > vfs_hash_get+0xff/frame 0xe9bb5384 > ffs_vgetf(c70012ec,1fd924,80000,e9bb5458,1,...) at > ffs_vgetf+0x44/frame 0xe9bb53e0 > softdep_sync_buf(c814f9d8,da98d9d4,1,0,0,...) at > softdep_sync_buf+0xac7/frame 0xe9bb5470 > ffs_syncvnode(c814f9d8,1,0,0,c1488968,...) at > ffs_syncvnode+0x2dd/frame 0xe9bb54c8 > ffs_truncate(c814f9d8,2a00,0,880,c771e200,...) at > ffs_truncate+0x70e/frame 0xe9bb5678 > ufs_direnter(c814f9d8,c9f7b000,e9bb5740,e9bb5a64,0,...) at > ufs_direnter+0x79e/frame 0xe9bb56f8 > ufs_makeinode(e9bb5a50,e9bb5a64,c814f9d8,c14c09b8,c814f9d8,...) at > ufs_makeinode+0x534/frame 0xe9bb5874 > ufs_create(e9bb5970,c13da585,c123c2ce,c70012fc,2,...) at > ufs_create+0x30/frame 0xe9bb5898 > VOP_CREATE_APV(c14ae018,e9bb5970,e9bb5a64,e9bb5900,c0b3a060,...) at > VOP_CREATE_APV+0x12f/frame 0xe9bb58c8 > vn_open_cred(e9bb5a08,e9bb5a94,180,0,c771e200,c6eedaf0) at > vn_open_cred+0x2f9/frame 0xe9bb5998 > vn_open(e9bb5a08,e9bb5a94,180,c6eedaf0,bfbfcbc0,...) at > vn_open+0x3d/frame 0xe9bb59c0 > kern_openat(c720d310,ffffff9c,bfbfcbc0,0,a02,180) at > kern_openat+0x310/frame 0xe9bb5ab4 > sys_open(c720d310,e9bb5b68,dab27c90,e9bb5b30,c108d221,...) at > sys_open+0x39/frame 0xe9bb5ad8 > syscall(e9bb5ba8) at syscall+0x336/frame 0xe9bb5b9c > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe9bb5b9c > --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x281f4ac3, esp = > 0xbfbfc25c, ebp = 0xbfbfc708 --- --001a113ff326070156052bed42bf Content-Type: text/plain; charset=US-ASCII; name="LOR.txt" Content-Disposition: attachment; filename="LOR.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ikq61dgk0 CjFzdCAweGM2YWFhNDZjIHVmcyAodWZzKSBAIHN5cy9rZXJuL3Zmc19tb3VudC5jOjEyMjcKMm5k IDB4YzZhYWE1ZDQgZGV2ZnMgKGRldmZzKSBAIHN5cy9rZXJuL3Zmc19zdWJyLmM6MjI4NQpLREI6 IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMxMjBhMzNjLDYzMmU3MjYy LDM4MzIzMjNhLGMwMDAwYTM1LGRiN2RmNzUwLC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVy KzB4MmQvZnJhbWUgMHhkYjdkZjcwOAprZGJfYmFja3RyYWNlKGMxMjBlMTA5LGM2YWFhNWQ0LGMx MWZmYmE2LGM2NWFlN2YwLGMxMjE3YmE4LC4uLikgYXQga2RiX2JhY2t0cmFjZSsweDMwL2ZyYW1l IDB4ZGI3ZGY3NmMKd2l0bmVzc19jaGVja29yZGVyKGM2YWFhNWQ0LDksYzEyMTdiYTgsOGVkLGM2 YWFhNjQwLC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ZDRmL2ZyYW1lIDB4ZGI3ZGY3YjgK X19sb2NrbWdyX2FyZ3MoYzZhYWE1ZDQsODAxMDAsYzZhYWE2NDAsMCwwLDAsYzEyMTdiYTgsOGVk KSBhdCBfX2xvY2ttZ3JfYXJncysweDhkNC9mcmFtZSAweGRiN2RmODk0CnZvcF9zdGRsb2NrKGRi N2RmOTA4LGMxNDg2ZGE4LGMxNmQyNmU4LDgsYzE3NTk1NjQsLi4uKSBhdCB2b3Bfc3RkbG9jaysw eDUzL2ZyYW1lIDB4ZGI3ZGY4YzQKVk9QX0xPQ0sxX0FQVihjMTQ3NTZhYyxkYjdkZjkwOCxjMGIz OWIzMSxjMTc1OTU1NCxjMTRjMjhjMCwuLi4pIGF0IFZPUF9MT0NLMV9BUFYrMHgxMGEvZnJhbWUg MHhkYjdkZjhmMApfdm5fbG9jayhjNmFhYTVhMCw4MDEwMCxjMTIxN2JhOCw4ZWQsZGI3ZGY5NzQs Li4uKSBhdCBfdm5fbG9jaysweGNhL2ZyYW1lIDB4ZGI3ZGY5MzAKdnB1dHgoYzZhYWE1YTAsMCxj MTFmYWViNiwyMGUsMCwuLi4pIGF0IHZwdXR4KzB4MzdhL2ZyYW1lIDB4ZGI3ZGY5NzQKY2Q5NjYw X3VubW91bnQoYzZlZDUwMDAsODA4MDAwMCxkYjdkZjllMCw1MTAsYzE0ODZkYTgsLi4uKSBhdCBj ZDk2NjBfdW5tb3VudCsweDFkYy9mcmFtZSAweGRiN2RmOWE4CmRvdW5tb3VudChjNmVkNTAwMCw4 MDgwMDAwLGM2ZWFiMzEwLDQ4ZixkYjdkZmE1OCwuLi4pIGF0IGRvdW5tb3VudCsweDVmYS9mcmFt ZSAweGRiN2RmYTA4CnN5c191bm1vdW50KGM2ZWFiMzEwLGRiN2RmYjY4LGM2ZTljMzA0LGQ2LGMx MDhkMjIxLC4uLikgYXQgc3lzX3VubW91bnQrMHgzYmIvZnJhbWUgMHhkYjdkZmFkOApzeXNjYWxs KGRiN2RmYmE4KSBhdCBzeXNjYWxsKzB4MzM2L2ZyYW1lIDB4ZGI3ZGZiOWMKWGludDB4ODBfc3lz Y2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMS9mcmFtZSAweGRiN2RmYjljCi0tLSBzeXNj YWxsICgyMiwgRnJlZUJTRCBFTEYzMiwgc3lzX3VubW91bnQpLCBlaXAgPSAweDg1M2Q4NzMsIGVz cCA9IDB4YmZiZmU2ZDQsIGVicCA9IDB4YmZiZmU3YTAgLS0tCgoKbG9jayBvcmRlciByZXZlcnNh bDoKMXN0IDB4YzdkOWRhMGMgdG1wZnMgKHRtcGZzKSBAIHN5cy9rZXJuL3Zmc19tb3VudC5jOjg0 OAoybmQgMHhjN2U5NDczYyB1ZnMgKHVmcykgQCBzeXMva2Vybi92ZnNfc3Vici5jOjIxNzQKS0RC OiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcihjMTIwYTMzYywzNzMxMzIz YSwzNDAwMGEzNCxhMzgsMCwuLi4pIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJkL2ZyYW1l IDB4ZGI3ZTM1NzgKa2RiX2JhY2t0cmFjZShjMTIwZTEwOSxjN2U5NDczYyxjMTFmMzFjZCxjNjVh ZTkyOCxjMTIxN2JhOCwuLi4pIGF0IGtkYl9iYWNrdHJhY2UrMHgzMC9mcmFtZSAweGRiN2UzNWRj CndpdG5lc3NfY2hlY2tvcmRlcihjN2U5NDczYyw5LGMxMjE3YmE4LDg3ZSxjN2U5NDdhOCwuLi4p IGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGQ0Zi9mcmFtZSAweGRiN2UzNjI4Cl9fbG9ja21ncl9h cmdzKGM3ZTk0NzNjLDgwMTAwLGM3ZTk0N2E4LDAsMCwuLi4pIGF0IF9fbG9ja21ncl9hcmdzKzB4 OGQ0L2ZyYW1lIDB4ZGI3ZTM3MDgKZmZzX2xvY2soZGI3ZTM3ODgsYzY1YTYyNDgsYzY1YWNiODAs YzY1YTYyNDgsYzE2ZDEwZTgsLi4uKSBhdCBmZnNfbG9jaysweDk3L2ZyYW1lIDB4ZGI3ZTM3NDQK Vk9QX0xPQ0sxX0FQVihjMTRhZTAxOCxkYjdlMzc4OCxjNjVhODQ2OCxmZmZmZmZmZixjMTRjMjhj MCwuLi4pIGF0IFZPUF9MT0NLMV9BUFYrMHgxMGEvZnJhbWUgMHhkYjdlMzc3MApfdm5fbG9jayhj N2U5NDcwOCw4MDEwMCxjMTIxN2JhOCw4N2UsNTcsLi4uKSBhdCBfdm5fbG9jaysweGNhL2ZyYW1l IDB4ZGI3ZTM3YjAKdmdldChjN2U5NDcwOCw4MDEwMCxjNmRhZWM0MCw1NywwLC4uLikgYXQgdmdl dCsweDc3L2ZyYW1lIDB4ZGI3ZTM3ZTQKdmZzX2hhc2hfZ2V0KGM3MDAyNWQ4LDIsODAwMDAsYzZk YWVjNDAsZGI3ZTM4YTQsLi4uKSBhdCB2ZnNfaGFzaF9nZXQrMHhmZi9mcmFtZSAweGRiN2UzODEw CmZmc192Z2V0ZihjNzAwMjVkOCwyLDgwMDAwLGRiN2UzOGE0LDApIGF0IGZmc192Z2V0ZisweDQ0 L2ZyYW1lIDB4ZGI3ZTM4NmMKZmZzX3ZnZXQoYzcwMDI1ZDgsMiw4MDAwMCxkYjdlMzhhNCxjMTZm ZTQxOCwuLi4pIGF0IGZmc192Z2V0KzB4MmYvZnJhbWUgMHhkYjdlMzg4Ywp1ZnNfcm9vdChjNzAw MjVkOCw4MDAwMCxkYjdlM2E5MCwzNTksYzZmMTIzOTAsLi4uKSBhdCB1ZnNfcm9vdCsweDQ5L2Zy YW1lIDB4ZGI3ZTM4YjAKdmZzX2Rvbm1vdW50KGM2ZGFlYzQwLDAsMCxjNmVhODEwMCxjNmVhODEw MCwuLi4pIGF0IHZmc19kb25tb3VudCsweDEzYTcvZnJhbWUgMHhkYjdlM2FiMApzeXNfbm1vdW50 KGM2ZGFlYzQwLGRiN2UzYjY4LGM2Y2QyMDAwLGQ2LGUyLC4uLikgYXQgc3lzX25tb3VudCsweDc4 L2ZyYW1lIDB4ZGI3ZTNhZDgKc3lzY2FsbChkYjdlM2JhOCkgYXQgc3lzY2FsbCsweDMzNi9mcmFt ZSAweGRiN2UzYjljClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjEv ZnJhbWUgMHhkYjdlM2I5YwotLS0gc3lzY2FsbCAoMzc4LCBGcmVlQlNEIEVMRjMyLCBzeXNfbm1v dW50KSwgZWlwID0gMHgyODBkYzllYiwgZXNwID0gMHhiZmJmZGRhMCwgZWJwID0gMHhiZmJmZTJm OCAtLS0KCgoKbG9jayBvcmRlciByZXZlcnNhbDoKMXN0IDB4YzY5YmJhM2MgaWZfYWRkcl9sb2Nr IChpZl9hZGRyX2xvY2spIEAgc3lzL25ldGluZXQvaWdtcC5jOjE3MTAKMm5kIDB4YzE3NWQ3MTgg aWZuZXRfcncgKGlmbmV0X3J3KSBAIHN5cy9uZXQvaWYuYzoyNDQKS0RCOiBzdGFjayBiYWNrdHJh Y2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcihjMTIwYTMzYywzYTYzMmU2NixhMzQzNDMyLDY5MmY3 NDAwLDJlNzA2ZDY3LC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmQvZnJhbWUgMHhk YWI1NjcyMAprZGJfYmFja3RyYWNlKGMxMjBlMTA5LGMxNzVkNzE4LGMxMjFjZWZlLGM2NWFhOTYw LGMxMjFjOTk4LC4uLikgYXQga2RiX2JhY2t0cmFjZSsweDMwL2ZyYW1lIDB4ZGFiNTY3ODQKd2l0 bmVzc19jaGVja29yZGVyKGMxNzVkNzE4LDEsYzEyMWM5OTgsZjQsMCwuLi4pIGF0IHdpdG5lc3Nf Y2hlY2tvcmRlcisweGQ0Zi9mcmFtZSAweGRhYjU2N2QwCl9fcndfcmxvY2soYzE3NWQ3MjgsYzEy MWM5OTgsZjQsYzc3MWY1MDAsZGFiNTY4ZGMsLi4uKSBhdCBfX3J3X3Jsb2NrKzB4OTIvZnJhbWUg MHhkYWI1Njg1OAppZm5ldF9ieWluZGV4KDEsYzEyNDU0Y2UsZGEsYzY1YWI0YzAsYzI2YmUyMDAs Li4uKSBhdCBpZm5ldF9ieWluZGV4KzB4MjMvZnJhbWUgMHhkYWI1Njg3MAppZ21wX2ludHIoYzc3 MWY1MDAsYzZkOTVjMDAsZGFiNTY5MzAsYzBlMDY4MzMsYzI2YzM5MDAsLi4uKSBhdCBpZ21wX2lu dHIrMHgxZS9mcmFtZSAweGRhYjU2OGRjCm5ldGlzcl9kaXNwYXRjaF9zcmMoMiwwLGM3NzFmNTAw KSBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4YjYvZnJhbWUgMHhkYWI1NjkxYwpuZXRpc3JfZGlz cGF0Y2goMixjNzcxZjUwMCwwLDg5YSxkYWI1Njk3OCwuLi4pIGF0IG5ldGlzcl9kaXNwYXRjaCsw eDIwL2ZyYW1lIDB4ZGFiNTY5MzAKaWdtcF92MXYyX3F1ZXVlX3JlcG9ydChjMTc1ZDhkYyw0LGMx MjJhNjA0LDZlNCxjMTc1YTMxMCwuLi4pIGF0IGlnbXBfdjF2Ml9xdWV1ZV9yZXBvcnQrMHgxYTkv ZnJhbWUgMHhkYWI1Njk3OAppZ21wX2Zhc3R0aW1vKGRhYjU2YTUwLGMwYjNhN2NjLGMxNzVhMzAw LGRhYjU2YTUwLGMwYjY0MjFkLC4uLikgYXQgaWdtcF9mYXN0dGltbysweDQxNy9mcmFtZSAweGRh YjU2YTFjCnBmZmFzdHRpbW8oMCwwLGMxMjA3M2Y1LDI4NSxjMGI4MTNiZSwuLi4pIGF0IHBmZmFz dHRpbW8rMHgzMC9mcmFtZSAweGRhYjU2YTUwCnNvZnRjbG9ja19jYWxsX2NjKDAsMCxjMTIwNzNm NSwzMmIsMCwuLi4pIGF0IHNvZnRjbG9ja19jYWxsX2NjKzB4MWFjL2ZyYW1lIDB4ZGFiNTZhZWMK c29mdGNsb2NrKGMxNzVhMzAwLGMxMWZlMjU1LDU2Niw3OGU1YjgwMyxjNjZlNWY0OCwuLi4pIGF0 IHNvZnRjbG9jaysweDQwL2ZyYW1lIDB4ZGFiNTZiMGMKaW50cl9ldmVudF9leGVjdXRlX2hhbmRs ZXJzKGMxNTkxNTkwLGM2NmU1ZjAwLGMxMWZlMjU1LDU2Niw4LC4uLikgYXQgaW50cl9ldmVudF9l eGVjdXRlX2hhbmRsZXJzKzB4OGIvZnJhbWUgMHhkYWI1NmIzNAppdGhyZWFkX2xvb3AoYzY1YTMy NjAsZGFiNTZiYTgsYzExZmRmYTgsM2YyLDAsLi4uKSBhdCBpdGhyZWFkX2xvb3ArMHg5MC9mcmFt ZSAweGRhYjU2YjZjCmZvcmtfZXhpdChjMGIxZTZkMCxjNjVhMzI2MCxkYWI1NmJhOCkgYXQgZm9y a19leGl0KzB4N2YvZnJhbWUgMHhkYWI1NmI5NApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4L2ZyYW1lIDB4ZGFiNTZiOTQKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0g MHhkYWI1NmJlMCwgZWJwID0gMCAtLS0KCgoKbG9jayBvcmRlciByZXZlcnNhbDoKMXN0IDB4Yzcy NGNlNDQgdG1wZnMgKHRtcGZzKSBAIHN5cy9rZXJuL3Zmc19tb3VudC5jOjEyMjcKMm5kIDB4Yzlh MmMxOWMgc3luY2VyIChzeW5jZXIpIEAgc3lzL2tlcm4vdmZzX3N1YnIuYzoyMjg1CktEQjogc3Rh Y2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoYzEyMGEzM2MsNzI2Mjc1NzMsMzIz YTYzMmUsYTM1MzgzMixlNzY5ZjcwMCwuLi4pIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJk L2ZyYW1lIDB4ZTc2OWY3MzgKa2RiX2JhY2t0cmFjZShjMTIwZTEwOSxjOWEyYzE5YyxjMTIxODI5 ZixjNjVhZWQzOCxjMTIxN2JhOCwuLi4pIGF0IGtkYl9iYWNrdHJhY2UrMHgzMC9mcmFtZSAweGU3 NjlmNzljCndpdG5lc3NfY2hlY2tvcmRlcihjOWEyYzE5Yyw5LGMxMjE3YmE4LDhlZCxjOWEyYzIw OCwuLi4pIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGQ0Zi9mcmFtZSAweGU3NjlmN2U4Cl9fbG9j a21ncl9hcmdzKGM5YTJjMTljLDgwMTAwLGM5YTJjMjA4LDAsMCwwLGMxMjE3YmE4LDhlZCkgYXQg X19sb2NrbWdyX2FyZ3MrMHg4ZDQvZnJhbWUgMHhlNzY5ZjhjNAp2b3Bfc3RkbG9jayhlNzY5Zjkz OCwyNDYsMSxlNzY5Zjk1NCxjNjVhZWNkMCwuLi4pIGF0IHZvcF9zdGRsb2NrKzB4NTMvZnJhbWUg MHhlNzY5ZjhmNApWT1BfTE9DSzFfQVBWKGMxNDkxOGQ0LGU3NjlmOTM4LGMwYjM5YjMxLGM5YTJj MjA4LGMxNGMyOGMwLC4uLikgYXQgVk9QX0xPQ0sxX0FQVisweDEwYS9mcmFtZSAweGU3NjlmOTIw Cl92bl9sb2NrKGM5YTJjMTY4LDgwMTAwLGMxMjE3YmE4LDhlZCxjNmQwNDkzMCwuLi4pIGF0IF92 bl9sb2NrKzB4Y2EvZnJhbWUgMHhlNzY5Zjk2MAp2cHV0eChjNzAwNjhjNCwwLGMxMjE3MTQ4LDUx MCxjMTQ4NmRhOCwuLi4pIGF0IHZwdXR4KzB4MzdhL2ZyYW1lIDB4ZTc2OWY5YTgKZG91bm1vdW50 KGM3MDA2OGM0LDgwMDAwMDAsYzZkMDQ5MzAsNDhmLGU3NjlmYTU4LC4uLikgYXQgZG91bm1vdW50 KzB4NGJmL2ZyYW1lIDB4ZTc2OWZhMDgKc3lzX3VubW91bnQoYzZkMDQ5MzAsZTc2OWZiNjgsYzkz N2EzMDQsZDYsYzEwOGQyMjEsLi4uKSBhdCBzeXNfdW5tb3VudCsweDNiYi9mcmFtZSAweGU3Njlm YWQ4CnN5c2NhbGwoZTc2OWZiYTgpIGF0IHN5c2NhbGwrMHgzMzYvZnJhbWUgMHhlNzY5ZmI5YwpY aW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIxL2ZyYW1lIDB4ZTc2OWZi OWMKLS0tIHN5c2NhbGwgKDIyLCBGcmVlQlNEIEVMRjMyLCBzeXNfdW5tb3VudCksIGVpcCA9IDB4 MjgwYzkzZWIsIGVzcCA9IDB4YmZiZmU1ZDQsIGVicCA9IDB4YmZiZmU2YTAgLS0tCgoKCgoKbG9j ayBvcmRlciByZXZlcnNhbDoKMXN0IDB4YzcyNGNlNDQgdG1wZnMgKHRtcGZzKSBAIHN5cy9rZXJu L3Zmc19tb3VudC5jOjEyMjcKMm5kIDB4YzlhMmM1ZDQgZGV2ZnMgKGRldmZzKSBAIHN5cy91ZnMv ZmZzL2Zmc192ZnNvcHMuYzoxMzc1CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm X3dyYXBwZXIoYzEyMGEzM2MsNzM2Njc2NWYsMmU3MzcwNmYsMzMzMTNhNjMsYTM1MzcsLi4uKSBh dCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyZC9mcmFtZSAweGU3NjlmNjY4CmtkYl9iYWNrdHJh Y2UoYzEyMGUxMDksYzlhMmM1ZDQsYzExZmZiYTYsYzY1YWU3ZjAsYzEyNDI1Y2QsLi4uKSBhdCBr ZGJfYmFja3RyYWNlKzB4MzAvZnJhbWUgMHhlNzY5ZjZjYwp3aXRuZXNzX2NoZWNrb3JkZXIoYzlh MmM1ZDQsOSxjMTI0MjVjZCw1NWYsMCwuLi4pIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGQ0Zi9m cmFtZSAweGU3NjlmNzE4Cl9fbG9ja21ncl9hcmdzKGM5YTJjNWQ0LDgwNDAwLGM5YTJjNjQwLDAs MCwwLGMxMjQyNWNkLDU1ZikgYXQgX19sb2NrbWdyX2FyZ3MrMHg4ZDQvZnJhbWUgMHhlNzY5Zjdm NAp2b3Bfc3RkbG9jayhlNzY5Zjg2OCxjMGJhZWI4ZSxjMTVhNTllYyw0LGMxNWE1OWRjLC4uLikg YXQgdm9wX3N0ZGxvY2srMHg1My9mcmFtZSAweGU3NjlmODI0ClZPUF9MT0NLMV9BUFYoYzE0NzU2 YWMsZTc2OWY4NjgsMCwwLGMxNGMyOGMwLC4uLikgYXQgVk9QX0xPQ0sxX0FQVisweDEwYS9mcmFt ZSAweGU3NjlmODUwCl92bl9sb2NrKGM5YTJjNWEwLDgwNDAwLGMxMjQyNWNkLDU1ZiwxLC4uLikg YXQgX3ZuX2xvY2srMHhjYS9mcmFtZSAweGU3NjlmODkwCmZmc19mbHVzaGZpbGVzKGM3MDA2OGM0 LDgsYzZkMDQ5MzAsZTc2OWY5MjAsYzBiNTQ2MGQsLi4uKSBhdCBmZnNfZmx1c2hmaWxlcysweDE1 MS9mcmFtZSAweGU3NjlmOGUwCnNvZnRkZXBfZmx1c2hmaWxlcyhjNzAwNjhjNCwwLGM2ZDA0OTMw LDAsMCwuLi4pIGF0IHNvZnRkZXBfZmx1c2hmaWxlcysweDhiL2ZyYW1lIDB4ZTc2OWY5NjAKZmZz X3VubW91bnQoYzcwMDY4YzQsODAwMDAwMCxjMTIxNzE0OCw1MTAsYzE0ODZkYTgsLi4uKSBhdCBm ZnNfdW5tb3VudCsweDdiL2ZyYW1lIDB4ZTc2OWY5YTgKZG91bm1vdW50KGM3MDA2OGM0LDgwMDAw MDAsYzZkMDQ5MzAsNDhmLGU3NjlmYTU4LC4uLikgYXQgZG91bm1vdW50KzB4NWZhL2ZyYW1lIDB4 ZTc2OWZhMDgKc3lzX3VubW91bnQoYzZkMDQ5MzAsZTc2OWZiNjgsYzkzN2EzMDQsZDYsYzEwOGQy MjEsLi4uKSBhdCBzeXNfdW5tb3VudCsweDNiYi9mcmFtZSAweGU3NjlmYWQ4CnN5c2NhbGwoZTc2 OWZiYTgpIGF0IHN5c2NhbGwrMHgzMzYvZnJhbWUgMHhlNzY5ZmI5YwpYaW50MHg4MF9zeXNjYWxs KCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIxL2ZyYW1lIDB4ZTc2OWZiOWMKLS0tIHN5c2NhbGwg KDIyLCBGcmVlQlNEIEVMRjMyLCBzeXNfdW5tb3VudCksIGVpcCA9IDB4MjgwYzkzZWIsIGVzcCA9 IDB4YmZiZmU1ZDQsIGVicCA9IDB4YmZiZmU2YTAgLS0tCgoKCmxvY2sgb3JkZXIgcmV2ZXJzYWw6 CjFzdCAweGRhOThkYTJjIGJ1ZndhaXQgKGJ1ZndhaXQpIEAgc3lzL2tlcm4vdmZzX2Jpby5jOjMx MjQKMm5kIDB4Yzc1NGUyMDAgZGlyaGFzaCAoZGlyaGFzaCkgQCBzeXMvdWZzL3Vmcy91ZnNfZGly aGFzaC5jOjI4MApLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMx MjBhMzNjLDczNjY3NTJmLDcyNjk2NDVmLDY4NzM2MTY4LDMyM2E2MzJlLC4uLikgYXQgZGJfdHJh Y2Vfc2VsZl93cmFwcGVyKzB4MmQvZnJhbWUgMHhlOWJiNTVkMAprZGJfYmFja3RyYWNlKGMxMjBl MTA5LGM3NTRlMjAwLGMxMjQzNjYxLGM2NWFlOTkwLGMxMjQzMjg5LC4uLikgYXQga2RiX2JhY2t0 cmFjZSsweDMwL2ZyYW1lIDB4ZTliYjU2MzQKd2l0bmVzc19jaGVja29yZGVyKGM3NTRlMjAwLDks YzEyNDMyODksMTE4LDAsLi4uKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHhkNGYvZnJhbWUgMHhl OWJiNTY4MApfc3hfeGxvY2soYzc1NGUyMDAsMCxjMTI0MzI4OSwxMTgsYzdjOWIwMDAsLi4uKSBh dCBfc3hfeGxvY2srMHg3NS9mcmFtZSAweGU5YmI1NmIwCnVmc2Rpcmhhc2hfYWRkKGM4MTczY2E4 LGU5YmI1N2QwLDcyNCxlOWJiNTczMCxlOWJiNTczNCwuLi4pIGF0IHVmc2Rpcmhhc2hfYWRkKzB4 NGEvZnJhbWUgMHhlOWJiNTZlMAp1ZnNfZGlyZW50ZXIoYzgxNGY5ZDgsMCxlOWJiNTdkMCxlOWJi NTlkNCwwLC4uLikgYXQgdWZzX2RpcmVudGVyKzB4NjA0L2ZyYW1lIDB4ZTliYjU3NjAKdWZzX3Jl bmFtZShlOWJiNWE4OCxjMTRjMmNlMCxjODk5YzlkOCxlOWJiNWE4NCxjMTQ4NmRhOCwuLi4pIGF0 IHVmc19yZW5hbWUrMHgxMDE3L2ZyYW1lIDB4ZTliYjU5MGMKVk9QX1JFTkFNRV9BUFYoYzE0YWUw MTgsZTliYjVhODgsMCwxLGU5YmI1OWQ0LC4uLikgYXQgVk9QX1JFTkFNRV9BUFYrMHgxMDQvZnJh bWUgMHhlOWJiNTkzOAprZXJuX3JlbmFtZWF0KGM3MjBkMzEwLGZmZmZmZjljLGJmYmZjYmMwLGZm ZmZmZjljLGJmYmZkM2MwLDApIGF0IGtlcm5fcmVuYW1lYXQrMHg1NWIvZnJhbWUgMHhlOWJiNWFi OApzeXNfcmVuYW1lKGM3MjBkMzEwLGU5YmI1YjY4LGRhYjJkYzkwLGU5YmI1YjMwLGMxMDhkMjIx LC4uLikgYXQgc3lzX3JlbmFtZSsweDM5L2ZyYW1lIDB4ZTliYjVhZDgKc3lzY2FsbChlOWJiNWJh OCkgYXQgc3lzY2FsbCsweDMzNi9mcmFtZSAweGU5YmI1YjljClhpbnQweDgwX3N5c2NhbGwoKSBh dCBYaW50MHg4MF9zeXNjYWxsKzB4MjEvZnJhbWUgMHhlOWJiNWI5YwotLS0gc3lzY2FsbCAoMTI4 LCBGcmVlQlNEIEVMRjMyLCBzeXNfcmVuYW1lKSwgZWlwID0gMHgyODEyNjFmYiwgZXNwID0gMHhi ZmJmYzYxYywgZWJwID0gMHhiZmJmYzcwNCAtLS0KCgoKbG9jayBvcmRlciByZXZlcnNhbDoKMXN0 IDB4YzgxNGZhMGMgdWZzICh1ZnMpIEAgc3lzL2tlcm4vdmZzX3N1YnIuYzoyMTc0CjJuZCAweGRh OThkYTJjIGJ1ZndhaXQgKGJ1ZndhaXQpIEAgc3lzL3Vmcy9mZnMvZmZzX3Zub3BzLmM6MjYyCjNy ZCAweGM5ZjcxY2RjIHVmcyAodWZzKSBAIHN5cy9rZXJuL3Zmc19zdWJyLmM6MjE3NApLREI6IHN0 YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMxMjBhMzNjLDM3MzEzMjNhLDZm MDAwYTM0LDYzMmU3MzcwLDMyMzYzMjNhLC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4 MmQvZnJhbWUgMHhlOWJiNTBlOAprZGJfYmFja3RyYWNlKGMxMjBlMTIyLGM5ZjcxY2RjLGMxMWYz MWNkLGM2NWFlOTI4LGMxMjE3YmE4LC4uLikgYXQga2RiX2JhY2t0cmFjZSsweDMwL2ZyYW1lIDB4 ZTliYjUxNGMKd2l0bmVzc19jaGVja29yZGVyKGM5ZjcxY2RjLDksYzEyMTdiYTgsODdlLGM5Zjcx ZDQ4LC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ZDRmL2ZyYW1lIDB4ZTliYjUxOTgKX19s b2NrbWdyX2FyZ3MoYzlmNzFjZGMsODAxMDAsYzlmNzFkNDgsMCwwLC4uLikgYXQgX19sb2NrbWdy X2FyZ3MrMHg4ZDQvZnJhbWUgMHhlOWJiNTI3OApmZnNfbG9jayhlOWJiNTJmOCxjMTVhMGJjYyxj NjVhNjI0OCxjNjVhY2I4MCxjNjVhNjI0OCwuLi4pIGF0IGZmc19sb2NrKzB4OTcvZnJhbWUgMHhl OWJiNTJiNApWT1BfTE9DSzFfQVBWKGMxNGFlMDE4LGU5YmI1MmY4LDEwNCwxYjksYzE0YzI4YzAs Li4uKSBhdCBWT1BfTE9DSzFfQVBWKzB4MTBhL2ZyYW1lIDB4ZTliYjUyZTAKX3ZuX2xvY2soYzlm NzFjYTgsODAxMDAsYzEyMTdiYTgsODdlLGMxMjE2ZDU5LC4uLikgYXQgX3ZuX2xvY2srMHhjYS9m cmFtZSAweGU5YmI1MzIwCnZnZXQoYzlmNzFjYTgsODAxMDAsYzcyMGQzMTAsNTcsMCwuLi4pIGF0 IHZnZXQrMHg3Ny9mcmFtZSAweGU5YmI1MzU4CnZmc19oYXNoX2dldChjNzAwMTJlYywxZmQ5MjQs ODAwMDAsYzcyMGQzMTAsZTliYjU0NTgsLi4uKSBhdCB2ZnNfaGFzaF9nZXQrMHhmZi9mcmFtZSAw eGU5YmI1Mzg0CmZmc192Z2V0ZihjNzAwMTJlYywxZmQ5MjQsODAwMDAsZTliYjU0NTgsMSwuLi4p IGF0IGZmc192Z2V0ZisweDQ0L2ZyYW1lIDB4ZTliYjUzZTAKc29mdGRlcF9zeW5jX2J1ZihjODE0 ZjlkOCxkYTk4ZDlkNCwxLDAsMCwuLi4pIGF0IHNvZnRkZXBfc3luY19idWYrMHhhYzcvZnJhbWUg MHhlOWJiNTQ3MApmZnNfc3luY3Zub2RlKGM4MTRmOWQ4LDEsMCwwLGMxNDg4OTY4LC4uLikgYXQg ZmZzX3N5bmN2bm9kZSsweDJkZC9mcmFtZSAweGU5YmI1NGM4CmZmc190cnVuY2F0ZShjODE0Zjlk OCwyYTAwLDAsODgwLGM3NzFlMjAwLC4uLikgYXQgZmZzX3RydW5jYXRlKzB4NzBlL2ZyYW1lIDB4 ZTliYjU2NzgKdWZzX2RpcmVudGVyKGM4MTRmOWQ4LGM5ZjdiMDAwLGU5YmI1NzQwLGU5YmI1YTY0 LDAsLi4uKSBhdCB1ZnNfZGlyZW50ZXIrMHg3OWUvZnJhbWUgMHhlOWJiNTZmOAp1ZnNfbWFrZWlu b2RlKGU5YmI1YTUwLGU5YmI1YTY0LGM4MTRmOWQ4LGMxNGMwOWI4LGM4MTRmOWQ4LC4uLikgYXQg dWZzX21ha2Vpbm9kZSsweDUzNC9mcmFtZSAweGU5YmI1ODc0CnVmc19jcmVhdGUoZTliYjU5NzAs YzEzZGE1ODUsYzEyM2MyY2UsYzcwMDEyZmMsMiwuLi4pIGF0IHVmc19jcmVhdGUrMHgzMC9mcmFt ZSAweGU5YmI1ODk4ClZPUF9DUkVBVEVfQVBWKGMxNGFlMDE4LGU5YmI1OTcwLGU5YmI1YTY0LGU5 YmI1OTAwLGMwYjNhMDYwLC4uLikgYXQgVk9QX0NSRUFURV9BUFYrMHgxMmYvZnJhbWUgMHhlOWJi NThjOAp2bl9vcGVuX2NyZWQoZTliYjVhMDgsZTliYjVhOTQsMTgwLDAsYzc3MWUyMDAsYzZlZWRh ZjApIGF0IHZuX29wZW5fY3JlZCsweDJmOS9mcmFtZSAweGU5YmI1OTk4CnZuX29wZW4oZTliYjVh MDgsZTliYjVhOTQsMTgwLGM2ZWVkYWYwLGJmYmZjYmMwLC4uLikgYXQgdm5fb3BlbisweDNkL2Zy YW1lIDB4ZTliYjU5YzAKa2Vybl9vcGVuYXQoYzcyMGQzMTAsZmZmZmZmOWMsYmZiZmNiYzAsMCxh MDIsMTgwKSBhdCBrZXJuX29wZW5hdCsweDMxMC9mcmFtZSAweGU5YmI1YWI0CnN5c19vcGVuKGM3 MjBkMzEwLGU5YmI1YjY4LGRhYjI3YzkwLGU5YmI1YjMwLGMxMDhkMjIxLC4uLikgYXQgc3lzX29w ZW4rMHgzOS9mcmFtZSAweGU5YmI1YWQ4CnN5c2NhbGwoZTliYjViYTgpIGF0IHN5c2NhbGwrMHgz MzYvZnJhbWUgMHhlOWJiNWI5YwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2Fs bCsweDIxL2ZyYW1lIDB4ZTliYjViOWMKLS0tIHN5c2NhbGwgKDUsIEZyZWVCU0QgRUxGMzIsIHN5 c19vcGVuKSwgZWlwID0gMHgyODFmNGFjMywgZXNwID0gMHhiZmJmYzI1YywgZWJwID0gMHhiZmJm YzcwOCAtLS0KCgoK --001a113ff326070156052bed42bf-- From owner-freebsd-stable@freebsd.org Wed Feb 17 17:36:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06540AAB84B for ; Wed, 17 Feb 2016 17:36:03 +0000 (UTC) (envelope-from efraindector@motumweb.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 DC88B1946 for ; Wed, 17 Feb 2016 17:36:02 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mailman.ysv.freebsd.org (Postfix) id D9908AAB849; Wed, 17 Feb 2016 17:36:02 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9335AAB848 for ; Wed, 17 Feb 2016 17:36:02 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 AA82A1945 for ; Wed, 17 Feb 2016 17:36:02 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mail-ob0-x22b.google.com with SMTP id xk3so25375197obc.2 for ; Wed, 17 Feb 2016 09:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=motumweb-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=v++uQP/M8++Ve7nFn5pdpK7s5hB8AGIQUKCw5MxvBqk=; b=kTH6uYMV/rtuC5fs6xSCQ6SMeGbtZrm9fIfIgeGjdnWQgjHsrgyPh4aceQ2Ao8Y08n +MKE0oxIe4ZWMmF1T/PbXlfAwfv3VKGswG2Vg9fv7j7ljoVRyoYgo3sYgoz37i1MMQOc 7lmHY+6IRlEgoTmVSJkzSDWDTShjPlniyBnHlmAoO7eb9kHpHxBc1Zv/rYPrW5RAvBNv bpPmN3k6y4qWXsrZiutqBDvfwYAV5+9iCACbjqlCYGCP8VPRb0WD8TMu1j7Y8iNL2lkz +kJ49ZfDO6xVwvAntMe8TsKol5jl0jd8cRajt8ft6mXatmaqFt8YgSYsjzJKpf8xXWgY rVZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=v++uQP/M8++Ve7nFn5pdpK7s5hB8AGIQUKCw5MxvBqk=; b=NnTZ6vFcskfZwx8DTDyftaPDMcdZfJP+B77DU5PWkgcGVGaqxmUDrjQ4S/B3y8B+Gt 6OQKIyAjt3C/xF8C6EQG2kWE0olRwOtYWbnAGvKTLpRRLVFGeFgI83CQZsaV+CoxxS8m uLHIPoR8xD7OS21I7o8Yln2VKTWyimHmmE9JFw9h+8f6cXTd616+VDoei/eQbaFWad7R sqp0XeZRa3XGG/JCwAEyJFlxwWTNtPNjEaI22nQOJErkOXOyybpMIo7TarDgAKb/t7ds kRIJiihlnevHd47T8dSiSTNzpqjnoIS4LW3esl+5NvNYFt4em9DyNcyeY06xUYXppu4u BvOA== X-Gm-Message-State: AG10YOSPQDCjZqg0xoOQjCcy4FePJC7uqvaxB9rrGfdadooCwSNrlrbmTeqQhFbq0RgPWw== X-Received: by 10.60.116.35 with SMTP id jt3mr2293338oeb.79.1455730561672; Wed, 17 Feb 2016 09:36:01 -0800 (PST) Received: from [192.168.10.2] ([187.210.81.114]) by smtp.googlemail.com with ESMTPSA id q4sm1229939oew.6.2016.02.17.09.36.00 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 09:36:01 -0800 (PST) To: "stable@freebsd.org" From: =?UTF-8?B?RWZyYcOtbiBEw6ljdG9y?= Subject: intr using Swap Message-ID: <56C4AF81.3040202@motumweb.com> Date: Wed, 17 Feb 2016 11:36:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:36:03 -0000 Hello. This past few days, on a dedicated server I'm seeing that swap space is being used while there are plenty of RAM to be used: Mem: 14G Active, 39G Inact, 7723M Wired, 504M Cache, 1864M Buf, 593M Free Swap: 8192M Total, 1567M Used, 6625M Free, 19% Inuse, 108K In After investigating, I swa that the process using swap is intr: Result of ps ax | grep W: 12 - WL 937:48.07 [intr] uname -a: FreeBSD edh.hyrule.mx 10.1-RELEASE-p24 FreeBSD 10.1-RELEASE-p24 #0: Mon Nov 2 12:17:28 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Is there any reason for intr to be using swap space? Is this normal? Thanks in advance. From owner-freebsd-stable@freebsd.org Wed Feb 17 18:51:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A0A0AAAD0F for ; Wed, 17 Feb 2016 18:51:46 +0000 (UTC) (envelope-from dweimer@dweimer.net) 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 45AC41E3A for ; Wed, 17 Feb 2016 18:51:46 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: by mailman.ysv.freebsd.org (Postfix) id 429C4AAAD0E; Wed, 17 Feb 2016 18:51:46 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42157AAAD0C; Wed, 17 Feb 2016 18:51:46 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (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 EAC0E1E39; Wed, 17 Feb 2016 18:51:45 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [192.168.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u1HIYwr8095747 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Wed, 17 Feb 2016 12:34:59 -0600 (CST) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u1HIYwps095746; Wed, 17 Feb 2016 12:34:58 -0600 (CST) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= Subject: Re: intr using Swap X-PHP-Script: www.dweimer.net/webmail/index.php for 71.86.41.122, 192.168.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 17 Feb 2016 12:34:58 -0600 From: dweimer Cc: stable@freebsd.org, owner-freebsd-stable@freebsd.org Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <56C4AF81.3040202@motumweb.com> References: <56C4AF81.3040202@motumweb.com> Message-ID: <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:51:46 -0000 On 2016-02-17 11:36 am, Efraín Déctor wrote: > Hello. > > This past few days, on a dedicated server I'm seeing that swap space > is being used while there are plenty of RAM to be used: > > Mem: 14G Active, 39G Inact, 7723M Wired, 504M Cache, 1864M Buf, 593M > Free > Swap: 8192M Total, 1567M Used, 6625M Free, 19% Inuse, 108K In > > After investigating, I swa that the process using swap is intr: > > Result of ps ax | grep W: > 12 - WL 937:48.07 [intr] > > uname -a: > FreeBSD edh.hyrule.mx 10.1-RELEASE-p24 FreeBSD 10.1-RELEASE-p24 #0: > Mon Nov 2 12:17:28 UTC 2015 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Is there any reason for intr to be using swap space? Is this normal? I believe you are incorrectly reading it, the first character of the state line being a W Marks an idle interrupt thread, W only means swapped out if its an additional character in the section. man ps [...snip...] state The state is given by a sequence of characters, for example, ``RWNA''. The first character indicates the run state of the process: [...snip...] W Marks an idle interrupt thread. [...snip...] Additional characters after these, if any, indicate additional state information: [...snip...] W The process is swapped out. [...snip...] Even when there is available memory if an item has already been swapped it wont return to physical memory until the process needs access that memory. Its not uncommon to see systems that had a brief memory constraint leave some swap long after the memory has been cleared up. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@freebsd.org Wed Feb 17 18:56:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B668AAAECD for ; Wed, 17 Feb 2016 18:56:05 +0000 (UTC) (envelope-from efraindector@motumweb.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 DEF2610A4 for ; Wed, 17 Feb 2016 18:56:04 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mailman.ysv.freebsd.org (Postfix) id DBFD1AAAECB; Wed, 17 Feb 2016 18:56:04 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAB19AAAECA for ; Wed, 17 Feb 2016 18:56:04 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F8CB10A3 for ; Wed, 17 Feb 2016 18:56:04 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mail-ob0-x231.google.com with SMTP id jq7so28858238obb.0 for ; Wed, 17 Feb 2016 10:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=motumweb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=K+N6suQwohGXdDS7EYtgVvi2imNDkbukkNqUbb/yp7c=; b=nj5hDkdaGNVGsNffx476gIJ3QQwDHjwDrpgH6lePvqyzKvy6bgt4a2i8tE602wX/vd nBCdmfiJdZz84Pw+84z8nUuy5KiSNd0XDCnW/WFlJKA9GvNHwHFW7/xTf6UnsC67Y7iL MwnowMmMgnrBTNsCuiTXETuXF27Gf3t1+je7Dfd2fZ8tJdz+d6FYg4oUeupB++OptVbX Q1lU4EwoNYA5MLtFTdu5nV2uRKsUf3hoMBen532gpfxH40OvU31pcYWn/NyUAOWGXA4+ HlOD2GaGReFuNasSdcQsko0h91gac05Ew5LFb1MUU4NTQZE1lSTy7fqj8ysiDgy8WBPy ruUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=K+N6suQwohGXdDS7EYtgVvi2imNDkbukkNqUbb/yp7c=; b=EekFgXBtpu0WB3qk9qyNIINYi/2Y7DTijv+a/vdYaZ+8d6kzVGusoDA9jWjHXJUceA NarULtCZ44k6uLWkaWsy5QkphXWYbghRFgtixji90y8P70nBUN0xKfFhjE3vgJ8GlUP3 ln6nms9rlN0XuVlgUvFjboZ3KaXfjst5W+x0IOp9A9TzeCHBYey9S99CbHKjB5qskq4N tokc3Q76PSMzNZMG2VTYuJbuDSBeumPj9ks5PaAKjzTUCDqs64CtGVQN4dblOU3SP30y TcMfMwpstnyGnrLfpgM7x3BRC3CphlXsCxqe7Cfu16RVWUrHra9VAEt5XcDaKTHVU5A+ EzRA== X-Gm-Message-State: AG10YOQmbOIi+5pOoCz5p0VUkda6w8Rxz3xo+UIuzHlPn6AX3QpYDzmHa8Chxni6nhhOXg== X-Received: by 10.60.43.170 with SMTP id x10mr2671271oel.68.1455735363871; Wed, 17 Feb 2016 10:56:03 -0800 (PST) Received: from [192.168.10.2] ([187.210.81.114]) by smtp.googlemail.com with ESMTPSA id kg7sm1420831obb.27.2016.02.17.10.56.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 10:56:03 -0800 (PST) Subject: Re: intr using Swap To: dweimer@dweimer.net References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> Cc: stable@freebsd.org, owner-freebsd-stable@freebsd.org From: =?UTF-8?B?RWZyYcOtbiBEw6ljdG9y?= Message-ID: <56C4C244.8070805@motumweb.com> Date: Wed, 17 Feb 2016 12:56:04 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:56:05 -0000 El 17/02/2016 a las 12:34 p. m., dweimer escribió: > I believe you are incorrectly reading it, the first character of the > state line being a W Marks an idle interrupt thread, W only means > swapped out if its an additional character in the section. > > man ps > [...snip...] > state The state is given by a sequence of characters, for example, > ``RWNA''. The first character indicates the run state > of the > process: > [...snip...] > W Marks an idle interrupt thread. > [...snip...] > Additional characters after these, if any, indicate > additional > state information: > [...snip...] > W The process is swapped out. > [...snip...] > > Even when there is available memory if an item has already been > swapped it wont return to physical memory until the process needs > access that memory. Its not uncommon to see systems that had a brief > memory constraint leave some swap long after the memory has been > cleared up. > Hello. Thank you for your response. Using only /ps ax/ doesn't show any process being in swap. How can I determine what processes are being swapped out? From owner-freebsd-stable@freebsd.org Wed Feb 17 19:15:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52219AABAEA for ; Wed, 17 Feb 2016 19:15:16 +0000 (UTC) (envelope-from dweimer@dweimer.net) 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 3BB46177F for ; Wed, 17 Feb 2016 19:15:16 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: by mailman.ysv.freebsd.org (Postfix) id 38C96AABAE7; Wed, 17 Feb 2016 19:15:16 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E570AABAE2; Wed, 17 Feb 2016 19:15:16 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (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 D9B03177B; Wed, 17 Feb 2016 19:15:15 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [192.168.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u1HJFEqJ096980 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Wed, 17 Feb 2016 13:15:14 -0600 (CST) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u1HJFE8b096979; Wed, 17 Feb 2016 13:15:14 -0600 (CST) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= Subject: Re: intr using Swap X-PHP-Script: www.dweimer.net/webmail/index.php for 71.86.41.122, 192.168.5.3 MIME-Version: 1.0 Date: Wed, 17 Feb 2016 13:15:13 -0600 From: dweimer Cc: stable@freebsd.org, owner-freebsd-stable@freebsd.org Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <56C4C244.8070805@motumweb.com> References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:15:16 -0000 On 2016-02-17 12:56 pm, Efraín Déctor wrote: > El 17/02/2016 a las 12:34 p. m., dweimer escribió: > >> I believe you are incorrectly reading it, the first character of the state line being a W Marks an idle interrupt thread, W only means swapped out if its an additional character in the section. >> >> man ps >> [...snip...] >> state The state is given by a sequence of characters, for example, >> ``RWNA''. The first character indicates the run state of the >> process: >> [...snip...] >> W Marks an idle interrupt thread. >> [...snip...] >> Additional characters after these, if any, indicate additional >> state information: >> [...snip...] >> W The process is swapped out. >> [...snip...] >> >> Even when there is available memory if an item has already been swapped it wont return to physical memory until the process needs access that memory. Its not uncommon to see systems that had a brief memory constraint leave some swap long after the memory has been cleared up. > > Hello. > > Thank you for your response. > > Using only _ps ax_ doesn't show any process being in swap. How can I determine what processes are being swapped out? They may not show as swapped unless the entire process is actually swapped, which would be unlikely to occur. Personally I wouldn't worry about it, the only thing I can think of is to restart processes one at a time to see which one clears up the swap usage. Granted you may see a little clear after each process. The more important task would be to determine what caused the memory to run out in the first place, and decide if its going to be a frequent enough occurrence to justify adding physical memory to the system. There is likely some way to find out what is using it, but that is beyond my knowledge. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@freebsd.org Wed Feb 17 22:44:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5453AAAA4A6 for ; Wed, 17 Feb 2016 22:44:59 +0000 (UTC) (envelope-from efraindector@motumweb.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 32CD11E6B for ; Wed, 17 Feb 2016 22:44:59 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2FC29AAA4A3; Wed, 17 Feb 2016 22:44:59 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E7F0AAA4A2 for ; Wed, 17 Feb 2016 22:44:59 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF78A1E69 for ; Wed, 17 Feb 2016 22:44:58 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: by mail-ob0-x231.google.com with SMTP id wb13so38903231obb.1 for ; Wed, 17 Feb 2016 14:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=motumweb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=PwlOY/3Wb2EdFfqSMwSi41NXutBtBCRMCt9m8RemI5g=; b=sUD0T2LWf9BzVqGYdiBHrxqwGIj5RRoEK9yQSi0d4Yt9cj66EprZ5LB5bOSDeaWdjk q23afLcbrm4qh5EgN1d05PstkAPuSZpnDwu5UayQwc7WROgc2KZYW1U01G3yysE0B1lE uJ4LjpbsSou29mx46K4DHCv49izS0P/AGhZA3tmigvS+W2cJ+MDCDzfHeDnLjhIFVTxK zxucxLCt5kMxMdmydogztpf4yHW7u5a2RkzOG0ToNBxsWPH77Ox6iVdHobLv6L1MpSVM 9ojDDTk5bIqy4e3vhLpEqX8N977yHEntZixav7j/HkvFtki6kdeG/fi56QBBFb/5j6e1 8psg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=PwlOY/3Wb2EdFfqSMwSi41NXutBtBCRMCt9m8RemI5g=; b=Mqqsl+dd0C/T8J/oOFPZWuBXQwjO96q/i+daeGu55bsi86Ky560DCRdMd4v3YAmkOY 7j5CLGDGCWdOC3kGBUt49VRn2tnvAbhsbiR3bEumLmpIUI6xuLlKjDuMdtkR3X+ndUFR OjOCblpGHSjYSwCiBbzdc6phFivUA6b8GlVN45ZsnEz4RfSTCswiymjE+iwMMCjDYthO n6uB9CLjRwibYM/kzNtif7CSy0e7kFmPJaBquEDVbTGUYagGEp0wFLqeZlOXwV4wmpwD qu2U88Sp6U/DNpLeG+wfHJm18EHXoR+jpX9blD17WwSJTz4FFzWVeppeTG7D98yEbHpB Kqtw== X-Gm-Message-State: AG10YOQJMzTBOt5ZJD9DDqMGkBQqWKcZtszpu4LR5klYM4xU03TFIuLYZmyAg5sLJkc2Qw== X-Received: by 10.182.246.73 with SMTP id xu9mr3564664obc.20.1455749098125; Wed, 17 Feb 2016 14:44:58 -0800 (PST) Received: from [192.168.10.2] ([187.210.81.114]) by smtp.googlemail.com with ESMTPSA id d39sm2059831oic.0.2016.02.17.14.44.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 14:44:57 -0800 (PST) Subject: Re: intr using Swap To: dweimer@dweimer.net References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> Cc: stable@freebsd.org, owner-freebsd-stable@freebsd.org From: =?UTF-8?B?RWZyYcOtbiBEw6ljdG9y?= Message-ID: <56C4F7E9.9090405@motumweb.com> Date: Wed, 17 Feb 2016 16:44:57 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 22:44:59 -0000 El 17/02/2016 a las 01:15 p. m., dweimer escribió: > > They may not show as swapped unless the entire process is actually > swapped, which would be unlikely to occur. Personally I wouldn't worry > about it, the only thing I can think of is to restart processes one at > a time to see which one clears up the swap usage. Granted you may see > a little clear after each process. > > The more important task would be to determine what caused the memory > to run out in the first place, and decide if its going to be a > frequent enough occurrence to justify adding physical memory to the > system. > > There is likely some way to find out what is using it, but that is > beyond my knowledge. > > -- > Thanks, > Dean E. Weimer > http://www.dweimer.net/ The server has 64 GB of RAM, 40-45 GB are always inactive thats why I'm wondering why are the processes being swapped out. Thank you very much for your answers. From owner-freebsd-stable@freebsd.org Wed Feb 17 23:01:45 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 257C6AAADA4 for ; Wed, 17 Feb 2016 23:01:45 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) 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 0A5B41E50 for ; Wed, 17 Feb 2016 23:01:45 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 09B23AAADA2; Wed, 17 Feb 2016 23:01:45 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3656AAADA1; Wed, 17 Feb 2016 23:01:44 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D49D31E4E; Wed, 17 Feb 2016 23:01:44 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 6EFB6E023; Wed, 17 Feb 2016 15:01:38 -0800 (PST) Date: Wed, 17 Feb 2016 15:01:38 -0800 From: hiren panchasara To: Efra?n D?ctor Cc: dweimer@dweimer.net, owner-freebsd-stable@freebsd.org, stable@freebsd.org Subject: Re: intr using Swap Message-ID: <20160217230138.GJ89208@strugglingcoder.info> References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n83H03bbH672hrlY" Content-Disposition: inline In-Reply-To: <56C4F7E9.9090405@motumweb.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 23:01:45 -0000 --n83H03bbH672hrlY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/17/16 at 04:44P, Efra?n D?ctor wrote: > El 17/02/2016 a las 01:15 p. m., dweimer escribi?: > > > > They may not show as swapped unless the entire process is actually=20 > > swapped, which would be unlikely to occur. Personally I wouldn't worry= =20 > > about it, the only thing I can think of is to restart processes one at= =20 > > a time to see which one clears up the swap usage. Granted you may see= =20 > > a little clear after each process. > > > > The more important task would be to determine what caused the memory=20 > > to run out in the first place, and decide if its going to be a=20 > > frequent enough occurrence to justify adding physical memory to the=20 > > system. > > > > There is likely some way to find out what is using it, but that is=20 > > beyond my knowledge. > > > > --=20 > > Thanks, > > Dean E. Weimer > > http://www.dweimer.net/ >=20 > The server has 64 GB of RAM, 40-45 GB are always inactive thats why I'm= =20 > wondering why are the processes being swapped out. Yes, I've seen this too. Inact end up accumulating a very large chunk of memory leaving Free to very low.=20 What VM/pagedaemon seems to care about is Free+Cache and not just Free. I kind of get that Free mem is wasted mem but putting everything in Inact to the point that machine has to go into swap when a sudden need arises also doesn't seem right. I guess it all boils down to adjusting defaults to the system's need. i.e. if you know you have a proc that may need a large chunk of mem you'd need to tweak free+cache target accordingly. What I find lacking is the correct/easy way to do it. If I look at available sysctls: vm.v_free_min: Minimum low-free-pages threshold vm.v_cache_min: Min pages on cache queue vm.v_free_target: Desired free pages And I cannot get them to do the right thing to have more Free around so swapping doesn't happen in sudden need. And are these all runtime sysctls? OR does it require reboot for them to work right?=20 Anyways, enough rant from someone who doesn't know much about VM. :-) Cheers, Hiren --n83H03bbH672hrlY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWxPvPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lwH0H/AsBiF0Ipu6+vNZBB6SJX2JR YLL+GwLNRJpRU/UPXG/7lbVjFBywHPMQXtCF758A+s/qCkfdNifResEYoqi91iDS 7EUXpfMZHKEmMWTgIbN3ORywt7U/lyfSxGqiSnBQHg2xbT+PocI7IdbDU7mxbU4v kOWmswfUW0VIRRsAXML4E8JMMN8xKazOhanCagGh3uC1EVDosHqkTQdKjy5LjkGs kZ+ynd49jiUWpDek46ad0mv5sGpjlZfR9yswSHqZwPP0R3oVeSOKPSyzfzZbcNnz 7heU7FK3dWYeZbr0Sw4iJKtON9i3awH4xgX5uVTJr4eFoLQsIk3T27IF+LH15bk= =n/SA -----END PGP SIGNATURE----- --n83H03bbH672hrlY-- From owner-freebsd-stable@freebsd.org Wed Feb 17 23:07:56 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA328AAB194 for ; Wed, 17 Feb 2016 23:07:56 +0000 (UTC) (envelope-from allbery.b@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 AA8EA118B for ; Wed, 17 Feb 2016 23:07:56 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A7D2FAAB192; Wed, 17 Feb 2016 23:07:56 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A749CAAB191; Wed, 17 Feb 2016 23:07:56 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61143118A; Wed, 17 Feb 2016 23:07:56 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-vk0-x229.google.com with SMTP id e185so29045360vkb.1; Wed, 17 Feb 2016 15:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8zw/ZsQDQURhIz6vnZ15Enm7fJv7L+aAj3ua1r3k8BI=; b=k58ABNU4NPKDwaKCV4QkGiZqydrgOUyapLwzYciJb1xNaO5dQuqzvqaAl8sK4emnh3 cjPNr+b168C0SGDe3rUeMCvyHGUCoLxcSwlB8K/cE691FPrOvjYalDwqU7saI5lxt9Me 8RQ2pp4iwbIx1+S6LXMFPMRRarLe8b2UdeAkmijQquNTaBsrZHVYMFV6rvP7RAdYqL2J Wfa46zDwwLZJpLOUZr83D7D1Lr4/5UMgB8ABS25WpwBdS59gzuDNSAs8X2Da2PKxfnAg hwy/dpxjcxoFi1H3ZqjjSEkYcXgz5WaCGrKAzJKS6stfkCOZL0WmcDAk8uYKWZhFSa3/ Ybwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8zw/ZsQDQURhIz6vnZ15Enm7fJv7L+aAj3ua1r3k8BI=; b=lsqxD0AF26tmWHzjw6pqJZVtyYL4MctLpxW15k2ZIbiQc9K+tQAHS15DJZbBKjUe5n zwbHV9DT51EmbDFdkzusF0G2N6ehrkHZT6vtb+B36fR+BiVmqwqO5ZqPmfr6HCD1Plq4 erXLNdLLdt07FtCiHVZkTdoneC8mz7/wd3HBOmQv0iN/GS/dqN5qElayEEFBl2PYmq6T gACoymJSJh7vFyeP0Dc1ZEggdLlDkYUZ+UoHsQFXhGKw4gdJzpiPzKA5eY+BrWajXj1G wIt/ZEGzWnw1Rmt+F3N+rVn+9gTzEeMZ4mppmXx7anQPgpfiVpOC1raw5MKhQaTBD46Y ddUQ== X-Gm-Message-State: AG10YOTDX6uY3qa+/VkB09L01HTa7KL5Qo3800aZx8Z8XiJRFNatY5g5MmuRC0PY7NnZ59mEg7jaq322zWJ2bg== MIME-Version: 1.0 X-Received: by 10.31.14.149 with SMTP id 143mr3623093vko.3.1455750475345; Wed, 17 Feb 2016 15:07:55 -0800 (PST) Received: by 10.176.3.44 with HTTP; Wed, 17 Feb 2016 15:07:55 -0800 (PST) In-Reply-To: <20160217230138.GJ89208@strugglingcoder.info> References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> Date: Wed, 17 Feb 2016 18:07:55 -0500 Message-ID: Subject: Re: intr using Swap From: Brandon Allbery To: hiren panchasara Cc: "Efra?n D?ctor" , owner-freebsd-stable@freebsd.org, "stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 23:07:56 -0000 On Wed, Feb 17, 2016 at 6:01 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > Yes, I've seen this too. Inact end up accumulating a very large chunk of > memory leaving Free to very low. > > What VM/pagedaemon seems to care about is Free+Cache and not just Free. > I kind of get that Free mem is wasted mem but putting everything in Inact > to the point that machine has to go into swap when a sudden need arises > also doesn't seem right. > If the file cache is "hot" but some working storage that was used at boot and will never be touched again is lying around (or, perhaps, that getty listening on a virtual console you never use), it makes perfect sense to push that out to swap. "Swap in use" does not mean "memory management problems". -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Thu Feb 18 00:24:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 306BAAAB530 for ; Thu, 18 Feb 2016 00:24:09 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB625E9E for ; Thu, 18 Feb 2016 00:24:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u1I0O65A095865 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Feb 2016 01:24:06 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u1I0O3Rq095864; Thu, 18 Feb 2016 01:24:03 +0100 (CET) (envelope-from marius) Date: Thu, 18 Feb 2016 01:24:03 +0100 From: Marius Strobl To: Henrik =?iso-8859-1?Q?Lidstr=F6m?= , Hajimu UMEMOTO , Peter Jeremy Cc: freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160218002403.GA95789@alchemy.franken.de> References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <56BD9FBA.3040002@lidstrom.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Thu, 18 Feb 2016 01:24:06 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:24:09 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Could those of you experiencing these hangs with ZFS please test whether instead of reverting all of r292895, a kernel built with just the merge of r291244 undone via the following patch gets rid of that problem - especially on amd64 - and report back? https://people.freebsd.org/~marius/r291244_reversal_10.diff Marius --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWxQ8fXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5P52AP/RpPDxTwdRvK5zZ0+6l49NWj Dmto9sR7QoXs+Jks/lcJQNN5okZ3ayCE71PZEH668FnOX7/LR+3W1kIb2cBENufu lDwHE2dAIS95sxctC44rQJSbFcG/I11ngVYbs5Rre9vT6iYBD84bS5Qw4AzFeB6o ui33F3r2sYI/mhmP3jZij7LVygFuqNXuxbUjOn3SrFUUI4eJcZcVNocdLHc7q0TG DjFVV7jBMRMUiV6dVEhlIemSd5jnmIVgKr/kZUrXpkNAMxC3LAUTfSzFC6Jd9LQ8 8L7T96bQ+13bB9lMYnDIovC702hlbOBF9N2L//Tgi7XnsHUghq5wjLb1achvt3yT FR5W1ucqdw1ARFn4W15IJl3VnYKQo+GDy6aXQXsih3oQmYr4938e7kg8ucvrYunw ImPlBZUbHM0M4ovMPqd2sbDPXlFrAbms/8cLZ6A/h5LuRxVZbk6/KJcLQMC8U+b2 7nryPa22S9B7ayLtdhguYMuC3TcM/IMd9QBI+dbtJxweG2nxYsxG+yTUFTPhhwrr lxqEaWbSNwjc1hU4NDgdr7ep4HPII9LmwI5mPLFM7n53zN5sDp1vvZWuhwR/Mitx QpC/f56P7pc3/4CDYwk+GKKCGlAYQdqmai+N/eWBEhlECdEM7g+0jpcJloc/ibYg DaDjw46JJW3fpByz8ga9 =hNmS -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-stable@freebsd.org Thu Feb 18 00:50:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E620AAC0FF for ; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.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 53E051C30 for ; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: by mailman.ysv.freebsd.org (Postfix) id 517A7AAC0FD; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E3EAAC0FC; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id E14531C2C; Thu, 18 Feb 2016 00:50:47 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from lowell-desk.lan (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id 90D0033C1E; Wed, 17 Feb 2016 19:50:40 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id D0E4D39843; Wed, 17 Feb 2016 19:50:39 -0500 (EST) From: Lowell Gilbert To: hiren panchasara Cc: Efra?n D?ctor , owner-freebsd-stable@freebsd.org, stable@freebsd.org Subject: Re: intr using Swap References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> Date: Wed, 17 Feb 2016 19:50:39 -0500 In-Reply-To: <20160217230138.GJ89208@strugglingcoder.info> (hiren panchasara's message of "Wed, 17 Feb 2016 15:01:38 -0800") Message-ID: <44d1rusuxs.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:50:48 -0000 hiren panchasara writes: > On 02/17/16 at 04:44P, Efra?n D?ctor wrote: >> El 17/02/2016 a las 01:15 p. m., dweimer escribi?: >> > >> > They may not show as swapped unless the entire process is actually >> > swapped, which would be unlikely to occur. Personally I wouldn't worry >> > about it, the only thing I can think of is to restart processes one at >> > a time to see which one clears up the swap usage. Granted you may see >> > a little clear after each process. >> > >> > The more important task would be to determine what caused the memory >> > to run out in the first place, and decide if its going to be a >> > frequent enough occurrence to justify adding physical memory to the >> > system. >> > >> > There is likely some way to find out what is using it, but that is >> > beyond my knowledge. >> > >> > -- >> > Thanks, >> > Dean E. Weimer >> > http://www.dweimer.net/ >> >> The server has 64 GB of RAM, 40-45 GB are always inactive thats why I'm >> wondering why are the processes being swapped out. There are almost certainly no processes being swapped out. Some of their *pages* are being stored in swap, but that is a very different thing. > Yes, I've seen this too. Inact end up accumulating a very large chunk of > memory leaving Free to very low. That's yet another, different thing. > What VM/pagedaemon seems to care about is Free+Cache and not just Free. Which makes sense, even without a deep understanding of the concepts, because those are guaranteed to be able to be re-allocated immediately. It is literally true that the pageout scan does nothing when free+cache is less than the target. > I kind of get that Free mem is wasted mem but putting everything in Inact > to the point that machine has to go into swap when a sudden need arises > also doesn't seem right. "Go into swap" is too vague to mean much. I suspect that you mean the system will have to start swapping out rapidly, but that isn't actually the case. First of all, pages in "inact" aren't necessarily dirty, so re-using them wouldn't be as expensive as having to write them to backing store. Also, when a page is copied to swap, the surrounding pages are eligible to be copied to swap also, to take advantage of the bandwidth advantages of larger transfer sizes. This does not move them to the cache queue, although it does make that easier to do later if and when their "turn" comes up. > I guess it all boils down to adjusting defaults to the system's need. > i.e. if you know you have a proc that may need a large chunk of mem > you'd need to tweak free+cache target accordingly. What I find lacking > is the correct/easy way to do it. If I look at available sysctls: > vm.v_free_min: Minimum low-free-pages threshold > vm.v_cache_min: Min pages on cache queue > vm.v_free_target: Desired free pages > And I cannot get them to do the right thing to have more Free around so > swapping doesn't happen in sudden need. And are these all runtime > sysctls? OR does it require reboot for them to work right? These take effect immediately, from what I can see. Have you measured that paging (not swapping; that's a more extreme measure where the whole process gets removed from memory) is a significant load on your system in a specific case? If not, I doubt that it's actually the case, and you're mitigating a non-existent problem. Be well. From owner-freebsd-stable@freebsd.org Thu Feb 18 01:12:37 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 967BEAAC9D4 for ; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.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 844A3A6D for ; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: by mailman.ysv.freebsd.org (Postfix) id 83EF4AAC9D3; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83712AAC9D2; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.lafn.org (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4B6A6C; Thu, 18 Feb 2016 01:12:36 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.12] (unknown [10.0.1.12]) by mail.lafn.org (Postfix) with ESMTPSA id D201D114C4FD; Wed, 17 Feb 2016 17:06:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: intr using Swap From: Doug Hardie In-Reply-To: <44d1rusuxs.fsf@lowell-desk.lan> Date: Wed, 17 Feb 2016 17:06:48 -0800 Cc: hiren panchasara , owner-freebsd-stable@freebsd.org, stable@freebsd.org, Efra?n D?ctor Content-Transfer-Encoding: quoted-printable Message-Id: <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> <44d1rusuxs.fsf@lowell-desk.lan> To: Lowell Gilbert X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 01:12:37 -0000 > On 17 February 2016, at 16:50, Lowell Gilbert = wrote: >=20 > hiren panchasara writes: >=20 >> On 02/17/16 at 04:44P, Efra?n D?ctor wrote: >>> El 17/02/2016 a las 01:15 p. m., dweimer escribi?: >>>>=20 >>>> They may not show as swapped unless the entire process is actually=20= >>>> swapped, which would be unlikely to occur. Personally I wouldn't = worry=20 >>>> about it, the only thing I can think of is to restart processes one = at=20 >>>> a time to see which one clears up the swap usage. Granted you may = see=20 >>>> a little clear after each process. >>>>=20 >>>> The more important task would be to determine what caused the = memory=20 >>>> to run out in the first place, and decide if its going to be a=20 >>>> frequent enough occurrence to justify adding physical memory to the=20= >>>> system. >>>>=20 >>>> There is likely some way to find out what is using it, but that is=20= >>>> beyond my knowledge. >>>>=20 >>>> --=20 >>>> Thanks, >>>> Dean E. Weimer >>>> http://www.dweimer.net/ >>>=20 >>> The server has 64 GB of RAM, 40-45 GB are always inactive thats why = I'm=20 >>> wondering why are the processes being swapped out. >=20 > There are almost certainly no processes being swapped out. Some of = their > *pages* are being stored in swap, but that is a very different thing. >=20 >> Yes, I've seen this too. Inact end up accumulating a very large chunk = of >> memory leaving Free to very low.=20 >=20 > That's yet another, different thing. >=20 >> What VM/pagedaemon seems to care about is Free+Cache and not just = Free. >=20 > Which makes sense, even without a deep understanding of the concepts, > because those are guaranteed to be able to be re-allocated = immediately. > It is literally true that the pageout scan does nothing when = free+cache > is less than the target. >=20 >> I kind of get that Free mem is wasted mem but putting everything in = Inact >> to the point that machine has to go into swap when a sudden need = arises >> also doesn't seem right. >=20 > "Go into swap" is too vague to mean much. I suspect that you mean the > system will have to start swapping out rapidly, but that isn't = actually > the case. First of all, pages in "inact" aren't necessarily dirty, so > re-using them wouldn't be as expensive as having to write them to > backing store. Also, when a page is copied to swap, the surrounding > pages are eligible to be copied to swap also, to take advantage of the > bandwidth advantages of larger transfer sizes. This does not move them > to the cache queue, although it does make that easier to do later if = and > when their "turn" comes up. >=20 >> I guess it all boils down to adjusting defaults to the system's need. >> i.e. if you know you have a proc that may need a large chunk of mem >> you'd need to tweak free+cache target accordingly. What I find = lacking >> is the correct/easy way to do it. If I look at available sysctls: >> vm.v_free_min: Minimum low-free-pages threshold >> vm.v_cache_min: Min pages on cache queue >> vm.v_free_target: Desired free pages >> And I cannot get them to do the right thing to have more Free around = so >> swapping doesn't happen in sudden need. And are these all runtime >> sysctls? OR does it require reboot for them to work right?=20 >=20 > These take effect immediately, from what I can see. >=20 > Have you measured that paging (not swapping; that's a more extreme > measure where the whole process gets removed from memory) is a > significant load on your system in a specific case? If not, I doubt = that > it's actually the case, and you're mitigating a non-existent problem I believe the question here is what is using up the swap space. =46rom = what I have been able to find with a similar situation is that malloc = will allocate swap space to backup memory and mmap will also allocate = swap if there is no backing file. procstat -v can be helpful in chasing = down some of those issues. However, I ended up guessing which process = it was by sequentially restarting processes and watching swapinfo. I = still have not been able to chase down what in that process is using the = space. There are no mmaps that are not file backed so it must be a = malloc. Finding the right one has been elusive. =20 From owner-freebsd-stable@freebsd.org Thu Feb 18 01:45:42 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F032AAB770 for ; Thu, 18 Feb 2016 01:45:42 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.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 2B58B1A4C for ; Thu, 18 Feb 2016 01:45:42 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: by mailman.ysv.freebsd.org (Postfix) id 28E07AAB76F; Thu, 18 Feb 2016 01:45:42 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2758FAAB76E; Thu, 18 Feb 2016 01:45:42 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 013491A4B; Thu, 18 Feb 2016 01:45:41 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from lowell-desk.lan (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id 4395333C1E; Wed, 17 Feb 2016 20:45:35 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id 68B8839843; Wed, 17 Feb 2016 20:45:34 -0500 (EST) From: Lowell Gilbert To: Doug Hardie Cc: Lowell Gilbert , owner-freebsd-stable@freebsd.org, stable@freebsd.org, Efra?n D?ctor , hiren panchasara Subject: Re: intr using Swap References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> <44d1rusuxs.fsf@lowell-desk.lan> <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> Date: Wed, 17 Feb 2016 20:45:34 -0500 In-Reply-To: <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> (Doug Hardie's message of "Wed, 17 Feb 2016 17:06:48 -0800") Message-ID: <447fi2sse9.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 01:45:42 -0000 Doug Hardie writes: >> On 17 February 2016, at 16:50, Lowell Gilbert wrote: >> >> Have you measured that paging (not swapping; that's a more extreme >> measure where the whole process gets removed from memory) is a >> significant load on your system in a specific case? If not, I doubt that >> it's actually the case, and you're mitigating a non-existent problem > > I believe the question here is what is using up the swap space. From > what I have been able to find with a similar situation is that malloc > will allocate swap space to backup memory and mmap will also allocate > swap if there is no backing file. procstat -v can be helpful in > chasing down some of those issues. However, I ended up guessing which > process it was by sequentially restarting processes and watching > swapinfo. I still have not been able to chase down what in that > process is using the space. There are no mmaps that are not file > backed so it must be a malloc. Finding the right one has been > elusive. Sure, but I'm pretty sure that the other worriers in this thread don't actually have any problem at all. I tried to poke a (Socratically limited) number of questions as a start of figuring out whether that's really the case, but thus far, I'd bet that it is. If that turns out to be a losing bet, I *will* spend time on fixing the code. Your observations are more useful, but I'm still not sure they indicate a problem that needs to be solved. There are clearly cases where significant quantities of swap can get used up storing copies of clean pages backing files on disk. Unless that slows down bringing in new pages that need to be read or written, I don't think that's a problem. From owner-freebsd-stable@freebsd.org Thu Feb 18 06:50:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FA96AAB63A for ; Thu, 18 Feb 2016 06:50:44 +0000 (UTC) (envelope-from bc979@lafn.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 73EC02C9 for ; Thu, 18 Feb 2016 06:50:44 +0000 (UTC) (envelope-from bc979@lafn.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7173AAAB638; Thu, 18 Feb 2016 06:50:44 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5707DAAB637; Thu, 18 Feb 2016 06:50:44 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.lafn.org (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC012C7; Thu, 18 Feb 2016 06:50:43 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.12] (unknown [10.0.1.12]) by mail.lafn.org (Postfix) with ESMTPSA id 236E3114C4FD; Wed, 17 Feb 2016 22:50:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: intr using Swap From: Doug Hardie In-Reply-To: <447fi2sse9.fsf@lowell-desk.lan> Date: Wed, 17 Feb 2016 22:50:43 -0800 Cc: owner-freebsd-stable@freebsd.org, stable@freebsd.org, Efra?n D?ctor , hiren panchasara Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> <44d1rusuxs.fsf@lowell-desk.lan> <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> <447fi2sse9.fsf@lowell-desk.lan> To: Lowell Gilbert X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 06:50:44 -0000 > On 17 February 2016, at 17:45, Lowell Gilbert = wrote: >=20 > Doug Hardie writes: >=20 >>> On 17 February 2016, at 16:50, Lowell Gilbert = wrote: >>>=20 >>> Have you measured that paging (not swapping; that's a more extreme >>> measure where the whole process gets removed from memory) is a >>> significant load on your system in a specific case? If not, I doubt = that >>> it's actually the case, and you're mitigating a non-existent problem >>=20 >> I believe the question here is what is using up the swap space. From >> what I have been able to find with a similar situation is that malloc >> will allocate swap space to backup memory and mmap will also allocate >> swap if there is no backing file. procstat -v can be helpful in >> chasing down some of those issues. However, I ended up guessing = which >> process it was by sequentially restarting processes and watching >> swapinfo. I still have not been able to chase down what in that >> process is using the space. There are no mmaps that are not file >> backed so it must be a malloc. Finding the right one has been >> elusive. >=20 > Sure, but I'm pretty sure that the other worriers in this thread don't > actually have any problem at all. I tried to poke a (Socratically > limited) number of questions as a start of figuring out whether that's > really the case, but thus far, I'd bet that it is. If that turns out = to > be a losing bet, I *will* spend time on fixing the code. >=20 > Your observations are more useful, but I'm still not sure they = indicate > a problem that needs to be solved. There are clearly cases where > significant quantities of swap can get used up storing copies of clean > pages backing files on disk. Unless that slows down bringing in new > pages that need to be read or written, I don't think that's a problem. Well, the problem is quite significant for me in that eventually the = system runs out of swap and starts killing processes. Its not quite = random, but I haven't spent much time trying to figure out how it = selects those to kill. The specific system unfortunately is remote = (about a 3 hour drive) and when sshd gets killed, I have no option other = than having someone go on site to reboot it. I have had to start = monitoring swap usage with nagios and having it notifiy me when swap is = at 40% used. So far that has given me enough time to find an internet = connection and restart the process that is eating the swap. The = developer of that process claims that the problem must be in one of the = library functions it uses. That does seem reasonable as I am using that = process on a large number of systems and only one has the issue. = However, until I can track down which system call or malloc is eating up = swap space, I don't really see any way to fix the problem. I recently = rebuilt that system with an updated system and resized swap to be 10x = memory. That does raise the mean time between process kills, but = doesn't eliminate the problem. About every other week the alarm is = raised now. Before it was pretty much every other day. From owner-freebsd-stable@freebsd.org Thu Feb 18 08:03:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70840AABD90 for ; Thu, 18 Feb 2016 08:03:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) 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 5A57118EE for ; Thu, 18 Feb 2016 08:03:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: by mailman.ysv.freebsd.org (Postfix) id 592D9AABD8F; Thu, 18 Feb 2016 08:03:08 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58BCDAABD8E for ; Thu, 18 Feb 2016 08:03:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C4AB18ED for ; Thu, 18 Feb 2016 08:03:07 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 04A522842B; Thu, 18 Feb 2016 09:02:58 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8FA5028423; Thu, 18 Feb 2016 09:02:56 +0100 (CET) Message-ID: <56C57AAF.9060507@quip.cz> Date: Thu, 18 Feb 2016 09:02:55 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Doug Hardie , Lowell Gilbert CC: stable@freebsd.org, Efra?n D?ctor , hiren panchasara Subject: Re: intr using Swap References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> <44d1rusuxs.fsf@lowell-desk.lan> <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> <447fi2sse9.fsf@lowell-desk.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 08:03:08 -0000 Doug Hardie wrote on 02/18/2016 07:50: > >> On 17 February 2016, at 17:45, Lowell Gilbert wrote: >> >> Doug Hardie writes: [...] >> Your observations are more useful, but I'm still not sure they indicate >> a problem that needs to be solved. There are clearly cases where >> significant quantities of swap can get used up storing copies of clean >> pages backing files on disk. Unless that slows down bringing in new >> pages that need to be read or written, I don't think that's a problem. > > > Well, the problem is quite significant for me in that eventually the system runs out of swap and starts killing processes. Its not quite random, but I haven't spent much time trying to figure out how it selects those to kill. The specific system unfortunately is remote (about a 3 hour drive) and when sshd gets killed, I have no option other than having someone go on site to reboot it. Was sshd ever killed? I think FreeBSD has some "exceptions" implemented and some processes have higher value - not to be killed so easily. I had some system without swap and there were many processes killed every few days, but never sshd. Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Feb 18 12:49:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DA35AAC269 for ; Thu, 18 Feb 2016 12:49:17 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BDBCC164C; Thu, 18 Feb 2016 12:49:16 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=marius@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3q5bSy4xzvzqmj DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1455799746; bh=IrbxYP9TelqN4z8PUKx5MYwU4PF4xAAl/0I0rVT+KhA=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=2010-STABLE=20hangups=20frequently|To:=20Marius=20 Strobl=20,=0D=0A=20=20=20=20=20=20=20=20=3D?UT F-8?Q?Henrik_Lidstr=3Dc3=3Db6m?=3D=0D=0A=20,= 0D=0A=20=20=20=20=20=20=20=20Hajimu=20UMEMOTO=20 ,=20Peter=20Jeremy=20|References:=20=0D=0A=20<20160202200738.GA78969@server.rul ingia.com>=0D=0A=20=20<56B761A4.7 010901@restart.be>=0D=0A=20<56BD9FBA.3040002@lidstrom.eu>=20<20160 218002403.GA95789@alchemy.franken.de>|Cc:=20freebsd-stable@freebsd .org|From:=20Henri=20Hennebert=20|Date:=20Thu,=201 8=20Feb=202016=2013:49:00=20+0100|In-Reply-To:=20<20160218002403.G A95789@alchemy.franken.de>; b=Kq1R/uke8xGV1Qdz2ZMFU5iSNyvk9/H/an3v9ghba4V1h0/kpuyu2AXc4NpsKLpeA qfONNr0bheraocFxTWXH9tzMyS+oeWfg98iHM30A7gpEQc3s9VjST1ZJC9ZBU0TCX2 PjoH63Erg+SfEnxHkggfkzGVon39q36zEUZvd6cJMlsZmqeAsgaMbTb2DSEXif+H4a 14TBc4gLbrVRBd2Fb5RVrv86EpMnRlVMmsHiSsQ6c1w5MeNQnqYaedbo2S+tQvYoZZ cOi4nuM5DYf323jfvtdSLaUtDArXmC6TV+qPOpbj1IJxtVCI5YfdDxo6LfB9jn6RVf WYo2P8bwOE3Uw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3q5bSy4xzvzqmj; Thu, 18 Feb 2016 13:49:06 +0100 (CET) Received: from meribel.restart.bel (meribel.restart.bel [IPv6:2001:41d0:8:bdbe:1:8:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id u1ICn0lK065020 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 18 Feb 2016 13:49:01 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: 10-STABLE hangups frequently To: Marius Strobl , =?UTF-8?Q?Henrik_Lidstr=c3=b6m?= , Hajimu UMEMOTO , Peter Jeremy References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> <20160218002403.GA95789@alchemy.franken.de> Cc: freebsd-stable@freebsd.org From: Henri Hennebert Openpgp: id=D1248BB28D7F9271D27E9D1E84EC2196D351A503 Message-ID: <56C5BDBC.4050701@restart.be> Date: Thu, 18 Feb 2016 13:49:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160218002403.GA95789@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 12:49:17 -0000 On 02/18/2016 01:24, Marius Strobl wrote: > > Could those of you experiencing these hangs with ZFS please test > whether instead of reverting all of r292895, a kernel built with > just the merge of r291244 undone via the following patch gets rid > of that problem - especially on amd64 - and report back? > https://people.freebsd.org/~marius/r291244_reversal_10.diff > > Marius > On a i386 with 2GB and pure ZFS without r291244 all is normal Henri From owner-freebsd-stable@freebsd.org Thu Feb 18 15:22:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 741B4AACAE4 for ; Thu, 18 Feb 2016 15:22:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) (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 321A1F1; Thu, 18 Feb 2016 15:22:42 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.96] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id C70959DE11F; Thu, 18 Feb 2016 16:16:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: 10-STABLE hangups frequently From: Borja Marcos In-Reply-To: <20160218002403.GA95789@alchemy.franken.de> Date: Thu, 18 Feb 2016 16:16:07 +0100 Cc: =?utf-8?Q?Henrik_Lidstr=C3=B6m?= , Hajimu UMEMOTO , Peter Jeremy , freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6FF1912A-3861-4496-A93F-680FA6479DE5@sarenet.es> References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> <20160218002403.GA95789@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:22:43 -0000 > On 18 Feb 2016, at 01:24, Marius Strobl wrote: >=20 >=20 > Could those of you experiencing these hangs with ZFS please test > whether instead of reverting all of r292895, a kernel built with > just the merge of r291244 undone via the following patch gets > rid of that problem - especially on amd64 - and report back? > https://people.freebsd.org/~marius/r291244_reversal_10.diff Fist, a warning: as my report is very fuzzy, take it with a grain of = salt. That said, since two months ago more or less, I have been having = performance problems with a =E2=80=9Cplayground=E2=80=9D machine I use = for several purposes, like searching Netflow data, graphing performance = data from several machines with Orca, etc. =E2=80=94=E2=80=94=E2=80=94 CPU: Six-Core AMD Opteron(tm) Processor 2431 (2400.15-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x100f80 Family=3D0x10 Model=3D0x8 = Stepping=3D0 = Features=3D0x178bfbff Features2=3D0x802009 AMD = Features=3D0xee500800 AMD = Features2=3D0x37ff SVM: NP,NRIP,NAsids=3D64 TSC: P-state invariant real memory =3D 8589934592 (8192 MB) avail memory =3D 8270192640 (7887 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: =E2=80=94=E2=80=94=E2=80=94 I was running lots of stuff (creating a lot of memory pressure) but the = system coped with it anyway. After one update (I use to track -STABLE) I = begun to have problems. Something I noticed was, the system begun = killing processes because of a lack of memory while the swap partition = wasn=E2=80=99t full at all. The wired memory would skyrocket as well. After reducing the clutter (ie, removing what I really didn=E2=80=99t = need) the server has been stable, but the performance (for example, when = performing large Netflow searches) has decreased remarkably. I have rebuilt -STABLE today with that patch, and something has = definitely changed. Performance is much better and memory consumption is = not growing like before, with the same NFsen, Orca and other stuff = running. I know this is not a serious report, I can=E2=80=99t do it with that = server, but I hope it rings a bell or somewhat confirms a data point. Borja. From owner-freebsd-stable@freebsd.org Thu Feb 18 17:54:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0D33AADF13 for ; Thu, 18 Feb 2016 17:54:26 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6657B19A9; Thu, 18 Feb 2016 17:54:26 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u1IHsDIt009897 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Feb 2016 02:54:18 +0900 (JST) (envelope-from ume@mahoroba.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mahoroba.org; s=20081103; t=1455818060; bh=xreYIZffyS5zc9XtwwyG3gDAPDGSLzqenHJvG8sX4Dw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NiHdi8A/kRDJh6qjpg9b631/J3a1dWIQJj7YDvb8A60p2cXL0Xl6vvEDx42cpX/kE lE2PdOz+b7Muzuh9gizkD6jHvgxjw3udMVI2PQGEX8pFKKTquBHnl2KeNXALqwzWWt RSJuuowhN4m765jQRkExhhp284rL2CtVglU+GVPE= Date: Fri, 19 Feb 2016 02:54:02 +0900 Message-ID: From: Hajimu UMEMOTO To: Marius Strobl Cc: Henrik =?ISO-2022-JP-2?B?TGlkc3RyGyQoRCtTGyhCbQ==?= , Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently In-Reply-To: <20160218002403.GA95789@alchemy.franken.de> References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> <20160218002403.GA95789@alchemy.franken.de> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-BETA2 X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6a2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 19 Feb 2016 02:54:20 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:54:26 -0000 Hi, >>>>> On Thu, 18 Feb 2016 01:24:03 +0100 >>>>> Marius Strobl said: marius> Could those of you experiencing these hangs with ZFS please test marius> whether instead of reverting all of r292895, a kernel built with marius> just the merge of r291244 undone via the following patch gets marius> rid of that problem - especially on amd64 - and report back? marius> https://people.freebsd.org/~marius/r291244_reversal_10.diff I tried your patch. It seems fix my problem. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@freebsd.org Fri Feb 19 00:44:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7811AAC28C for ; Fri, 19 Feb 2016 00:44:09 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from oceanview.tundraware.com (oceanview.tundraware.com [45.55.60.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oceanview.tundraware.com", Issuer "oceanview.tundraware.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F42B17D for ; Fri, 19 Feb 2016 00:44:09 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from [192.168.0.2] (ozzie.tundraware.com [75.145.138.73]) (authenticated bits=0) by oceanview.tundraware.com (8.15.2/8.15.2) with ESMTPSA id u1J0dA5k088035 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 18 Feb 2016 18:39:10 -0600 (CST) (envelope-from tundra@tundraware.com) To: FreeBSD Stable Maling List From: Tim Daneliuk Subject: 10.3-BETA2 rpc.statd: Failed to contact host Message-ID: <56C66428.1030200@tundraware.com> Date: Thu, 18 Feb 2016 18:39:04 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (oceanview.tundraware.com [45.55.60.57]); Thu, 18 Feb 2016 18:39:10 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: u1J0dA5k088035 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 00:44:09 -0000 Started to see this as of a week or so ago. Any idea what might be going on here? -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@freebsd.org Fri Feb 19 04:46:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82029AACD6D for ; Fri, 19 Feb 2016 04:46:06 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 449891DD9 for ; Fri, 19 Feb 2016 04:46:06 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id g127so59231600ywf.2 for ; Thu, 18 Feb 2016 20:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pB+JxyCNnHTfcRFzk+OsIGFaJ6NY35R/Lvh7qI16j1o=; b=t0CZ1ZKwWqd6y3WhjNpYf9aC7RqcX2YxvJdZbPVsj2nDCfACTSrEpqG7vgBKE24VQQ hbaqNfWxrL8Po/830X89oFtJIctolaghsFYrWomijV4SwSPF7k5xzsbLiK8Mn9YLynC7 QrSljece5Vg5UaifLs85kuLjdAtPe9/f3gr/bdn+OW4RWRI0aHIrJvqnboiZiqMzxrUI UuzGFHozg6aurtZvbkzcqS4mwIYQ7vF1BHFxBelV3x9mdyY0Q+uLcf33DjQYYlF/NfRw 2n2/o3zsmaRsM6fujvUOv74QSs0fJC3cbiqfmdIQsVUgpaNsTzEwQGh9lp938L3RQRBI 0BHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pB+JxyCNnHTfcRFzk+OsIGFaJ6NY35R/Lvh7qI16j1o=; b=chomq/SRDTbXxnQGYAyRNaxYY0WBHqYtulz1USxT6pkAY5MCZSQdJQXo7tR9mvYjoi IgteT0ky3aWHE6FnvAirs2VTJ3u+UktSzvTxQ0+CqHhTr5Gk/6wQOppB5nUE+07OSfOE DTaZEFOHsJLxxo3iFEIyUhuvbkx8sGJYTGZKI4ckTUGF1kjC0BwsA+SknjtXpL+p5ZTa Aakcev5TXHFDyBG3mWNt6PaqSXYF0uY2vxDUnSS2CtRXL7pOBN1LNLgN48N//nXwZKSX q2cPLgPy7Kemx04QrL8/V8D/QXOeHGOaQLGd3owKHDPCARyUA+s+JCKzFwBDqG6x6tXM 1uzw== X-Gm-Message-State: AG10YOQExHp+xcHx2Fi3EK9EewCx7axrrxeGf6Hm74mz1VcVUFwc73FOd2rg/420D1Ubr+h3gX3o4hQYNDAGNA== MIME-Version: 1.0 X-Received: by 10.13.214.20 with SMTP id y20mr6627166ywd.63.1455857165306; Thu, 18 Feb 2016 20:46:05 -0800 (PST) Received: by 10.37.207.206 with HTTP; Thu, 18 Feb 2016 20:46:05 -0800 (PST) Date: Thu, 18 Feb 2016 23:46:05 -0500 Message-ID: Subject: A few outstanding 10.3-BETA2 bugs From: David Cross To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 04:46:06 -0000 I would like to call attention to a number of outstanding bugs with tickets, 2 of them have patches! 1) kern/189219 (ticket has proposed patch, much better than mine) which is a crasher when using dummyney on sparc64.. I've had to maintain a separate kernel patch for >6 months, there's really no reason we can't get this in 2) kern/207070 (ticket also has proposed patch). Basically gptboot doesn't zero memory before it reads and attempts to process the boot.config file; trivial patch (one line, replaces foo[0] = '\0' with bzero(foo, sizeof(foo))) 3) kern/207069 (no patch, because I can't figure out forth).. this one is severe and really has to get fixed, anyone with a 'password="foo"' in loader.conf will find themselves unable to boot their systems. This existed since 10.2 but went largely unnoticed because if you had an already working system it worked (loader.rc in 10.1 and earlier work, 10.2 and later don't, but loader.rc was not updated), however we are now overwriting loader.rc on installworld, not even a mergemaster. For someone that understands loader and forth this is probably 20 seconds. From owner-freebsd-stable@freebsd.org Fri Feb 19 05:11:52 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B9B1AADCAA for ; Fri, 19 Feb 2016 05:11:52 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 490211410; Fri, 19 Feb 2016 05:11:50 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-70-178.lns20.adl6.internode.on.net (HELO leader.local) ([121.45.70.178]) by ipmail06.adl2.internode.on.net with ESMTP; 19 Feb 2016 15:36:07 +1030 Subject: Re: 10-STABLE hangups frequently To: Marius Strobl References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> <20160218002403.GA95789@alchemy.franken.de> Cc: freebsd-stable@freebsd.org From: Shane Ambler Message-ID: <56C6A2BD.3090808@ShaneWare.Biz> Date: Fri, 19 Feb 2016 15:36:05 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160218002403.GA95789@alchemy.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:11:52 -0000 On 18/02/2016 10:54, Marius Strobl wrote: > > Could those of you experiencing these hangs with ZFS please test > whether instead of reverting all of r292895, a kernel built with > just the merge of r291244 undone via the following patch gets > rid of that problem - especially on amd64 - and report back? > https://people.freebsd.org/~marius/r291244_reversal_10.diff > > Marius > I have built 10-STABLE - r295756 with the patch applied. corei7 - 8GB - 3 disks in raidz The first 11 hours look promising. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@freebsd.org Fri Feb 19 05:38:45 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E38E6AADC77 for ; Fri, 19 Feb 2016 05:38:45 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from server.glaver.org (server.glaver.org [204.141.35.63]) (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 BD8B5180E for ; Fri, 19 Feb 2016 05:38:45 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from glaver.org by glaver.org (PMDF V6.6 #37010) id <01PWUKIO87SW0002VH@glaver.org> for freebsd-stable@freebsd.org; Fri, 19 Feb 2016 00:22:01 -0500 (EST) Date: Fri, 19 Feb 2016 00:08:55 -0500 (EST) From: Terry Kennedy Subject: 10.3-BETA2 regression in MPT To: freebsd-stable@freebsd.org Message-id: <01PWUKZNJW2C0002VH@glaver.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:38:46 -0000 I have some systems which I plan to upgrade from 8.4 to 10.3 once 10.3 is released. In the meantime, I'm testing 10.3-BETA2 and have found what appears to be a regression in the MPT driver. The system is a Dell PowerEdge R300 with a Dell SAS6 controller: mpt0@pci0:5:0:0: class=0x010000 card=0x1f0e1028 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068E PCI-Express Fusion-MPT SAS' class = mass storage subclass = SCSI Both the system BIOS and the SAS6 firmware are at the latest revisions from Dell (which haven't changed in years). On the 8.4 system, "grep mpt /var/run/dmesg.boot" reports: mpt0: port 0xec00-0xecff mem 0xdfcec000-0xdfceffff,0xdfcf0000-0xdfcfffff irq 16 at device 0.0 on pci5 mpt0: [ITHREAD] mpt0: MPI Version=1.5.18.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:9:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:0): Physical (mpt0:0:9:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:0): Online (probe0:mpt0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:mpt0:0:0:0): CAM status: SCSI Status Error (probe0:mpt0:0:0:0): SCSI status: Check Condition (probe0:mpt0:0:0:0): SCSI sense: ILLEGAL REQUEST info?:39000000 asc:0,0 (No additional sense information) ses0 at mpt0 bus 0 scbus0 target 8 lun 0 pass2 at mpt0 bus 1 scbus1 target 0 lun 0 da0 at mpt0 bus 0 scbus0 target 0 lun 0 [I'm not sure what that ILLEGAL REQUEST is about.] On the same system, running 10.3-BETA2 r295785, I see: mpt0: port 0xec00-0xecff mem 0xdfcec000-0xdfceffff,0xdfcf0000-0xdfcfffff irq 16 at device 0.0 on pci5 mpt0: MPI Version=1.5.18.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) mpt0:vol0(mpt0:0:0): Using Spare Pool: mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:9:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:0): Physical (mpt0:0:9:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:0): Online (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe64:mpt0:1:1:0): Retrying command (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe64:mpt0:1:1:0): Retrying command (probe0:mpt0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:mpt0:0:0:0): CAM status: SCSI Status Error (probe0:mpt0:0:0:0): SCSI status: Check Condition (probe0:mpt0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (probe0:mpt0:0:0:0): Error 22, Unretryable error (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe64:mpt0:1:1:0): Retrying command (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe64:mpt0:1:1:0): Retrying command (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe64:mpt0:1:1:0): Error 5, Retries exhausted (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe1:mpt0:1:1:0): Retrying command (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe1:mpt0:1:1:0): Retrying command (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe1:mpt0:1:1:0): Retrying command (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe1:mpt0:1:1:0): Retrying command (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error (probe1:mpt0:1:1:0): Error 5, Retries exhausted da0 at mpt0 bus 0 scbus0 target 0 lun 0 ses0 at mpt0 bus 0 scbus0 target 8 lun 0 pass2 at mpt0 bus 1 scbus1 target 0 lun 0 I can try to narrow down when this regression was introduced, but I fig- ured I'd report it in case somebody has an "ah-hah" moment from seeing it. Also, there has always been an issue with passthru on these controllers - as you can see above, there are 2 physical disks attached to the controller, used as a mirror volume. But only one of the members appears as a passN de- vice, which means that the other one can't be monitored with smartmontools. If I'm remembering correctly, a volume with more than 2 drives creates a passN device for all but one of the drives. Terry Kennedy http://www.glaver.org New York, NY USA From owner-freebsd-stable@freebsd.org Fri Feb 19 08:25:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06695AABBA4 for ; Fri, 19 Feb 2016 08:25:17 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (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 C82831D8D for ; Fri, 19 Feb 2016 08:25:16 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id C3BA3A888 for ; Fri, 19 Feb 2016 09:25:13 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from iron.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 15688A831 for ; Fri, 19 Feb 2016 09:25:12 +0100 (CET) Date: Fri, 19 Feb 2016 09:21:37 +0100 From: Daniel Bilik To: freebsd-stable@freebsd.org Subject: Re: A few outstanding 10.3-BETA2 bugs Message-Id: <20160219092137.22063da8fc068a8b35dceef2@neosystem.cz> In-Reply-To: References: Organization: neosystem.cz X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 08:25:17 -0000 On Thu, 18 Feb 2016 23:46:05 -0500 David Cross wrote: > I would like to call attention to a number of outstanding bugs with > tickets, 2 of them have patches! > ... 4) kern/206231 (also with patch) -- Dan From owner-freebsd-stable@freebsd.org Fri Feb 19 14:28:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A53BAAEAE6 for ; Fri, 19 Feb 2016 14:28:44 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AD7F1B81 for ; Fri, 19 Feb 2016 14:28:44 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-yw0-x22f.google.com with SMTP id u200so68638902ywf.0 for ; Fri, 19 Feb 2016 06:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpufaddqbgaEFgI6d/GG/C+aN3QMge5k5N2sidsTO2A=; b=bS0dYflFDeXGUzS5Eff4jTG5xiMF7U4LGs5d2Q0zx4zIc0fF4tGPzCcZhq/M8U8kyw A9bKj6G9QPdpECU4O8RBp9tdWVxMW/mMDTNr/5xOaY1FfZCrTQA9jApRYXKDgjOZ/kbJ LoU+r5U87ZTwqlkusqbxvrtdYRPV1LkqAmc5qiVBlwp/BkiaR8uo5v/eoLAhJ7RJkvLq zyZasTeIRD3LRV7Idjv+a0zL05RgtUH1z/oH+vFYOCDJwusjyT/Ntr97hhIECdOuGDwc 0LotVkYRO+NL0mOE8L1K/upyOk0XaEeyrux1ixwRrSiTSS6OHkZYJbdmEAENMZbJ0njV Z4XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kpufaddqbgaEFgI6d/GG/C+aN3QMge5k5N2sidsTO2A=; b=mpG1QO9fknaNCoKmisX0Pq0qTRHshNFEU0gNFabqedPMKwtm2kqv+gznuB3IIQ9Vno JfeA52km0uuKjQVQwSiZlnt9s/cS7J/pwuUKvaS2Bc/HLIh9H+/UlxeBQ7DwwnwYaGth FwsAwPhBt4tRwSOZ6QGXwznySBm2JBCNdmUiP3dQxav/9n4UUn19FsLbhC+jJQqQ9+1d OUFU2gFW68cAJrxh3sqzL/WyY4dTP0FHT/XlMG0Ac7Uy3uN4w3Kj56VJtk81Xq9jEaAc SkMYb1i9ajzwIvZcabaJG93GVpcz5ESj4W+KrtRwSLq5I+R+Q0ZlorUcC5fOTmi40TcL eC3g== X-Gm-Message-State: AG10YOQ5R/PZNKaD3qpGFxVKpT6vXgdiUSHizgLCEvbwswNxR/830K1KSHkz/3kY4YK6Zw== X-Received: by 10.129.88.136 with SMTP id m130mr7758841ywb.81.1455892123306; Fri, 19 Feb 2016 06:28:43 -0800 (PST) Received: from [100.122.55.117] (29.sub-70-199-72.myvzw.com. [70.199.72.29]) by smtp.gmail.com with ESMTPSA id a205sm8631926ywe.50.2016.02.19.06.28.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 06:28:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: 10.3-BETA2 regression in MPT From: Mark Saad X-Mailer: iPhone Mail (13D15) In-Reply-To: <01PWUKZNJW2C0002VH@glaver.org> Date: Fri, 19 Feb 2016 09:28:41 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <01PWUKZNJW2C0002VH@glaver.org> To: Terry Kennedy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:28:44 -0000 Hi tmk, > On Feb 19, 2016, at 12:08 AM, Terry Kennedy wrote: >=20 > I have some systems which I plan to upgrade from 8.4 to 10.3 once 10.3 > is released. In the meantime, I'm testing 10.3-BETA2 and have found what > appears to be a regression in the MPT driver. >=20 > The system is a Dell PowerEdge R300 with a Dell SAS6 controller: >=20 > mpt0@pci0:5:0:0: class=3D0x010000 card=3D0x1f0e1028 chip=3D0x005810= 00 rev=3D0x08 hdr=3D0x00 > vendor =3D 'LSI Logic / Symbios Logic' > device =3D 'SAS1068E PCI-Express Fusion-MPT SAS' > class =3D mass storage > subclass =3D SCSI >=20 > Both the system BIOS and the SAS6 firmware are at the latest revisions > from Dell (which haven't changed in years). >=20 Can you get the status of the controller and disks via mptutil ? Also what d= oes camcontrol devlist -v show ?=20 > On the 8.4 system, "grep mpt /var/run/dmesg.boot" reports: >=20 > mpt0: port 0xec00-0xecff mem 0xdfcec000-0xdfce= ffff,0xdfcf0000-0xdfcfffff irq 16 at device 0.0 on pci5 > mpt0: [ITHREAD] > mpt0: MPI Version=3D1.5.18.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 1 Active Volume (2 Max) > mpt0: 2 Hidden Drive Members (14 Max) > mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) > mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 > mpt0:vol0(mpt0:0:0): 2 Members: > (mpt0:1:9:0): Primary Online > (mpt0:1:1:0): Secondary Online > mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) > (mpt0:vol0:1): Online > (mpt0:vol0:0): Physical (mpt0:0:9:0), Pass-thru (mpt0:1:1:0) > (mpt0:vol0:0): Online > (probe0:mpt0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00= =20 > (probe0:mpt0:0:0:0): CAM status: SCSI Status Error > (probe0:mpt0:0:0:0): SCSI status: Check Condition > (probe0:mpt0:0:0:0): SCSI sense: ILLEGAL REQUEST info?:39000000 asc:0,0 (N= o additional sense information) > ses0 at mpt0 bus 0 scbus0 target 8 lun 0 > pass2 at mpt0 bus 1 scbus1 target 0 lun 0 > da0 at mpt0 bus 0 scbus0 target 0 lun 0 >=20 > [I'm not sure what that ILLEGAL REQUEST is about.] >=20 > On the same system, running 10.3-BETA2 r295785, I see: >=20 > mpt0: port 0xec00-0xecff mem 0xdfcec000-0xdfce= ffff,0xdfcf0000-0xdfcfffff irq 16 at device 0.0 on pci5 > mpt0: MPI Version=3D1.5.18.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 1 Active Volume (2 Max) > mpt0: 2 Hidden Drive Members (14 Max) > mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) > mpt0:vol0(mpt0:0:0): Using Spare Pool: > mpt0:vol0(mpt0:0:0): 2 Members: > (mpt0:1:9:0): Primary Online > (mpt0:1:1:0): Secondary Online > mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) > (mpt0:vol0:1): Online > (mpt0:vol0:0): Physical (mpt0:0:9:0), Pass-thru (mpt0:1:1:0) > (mpt0:vol0:0): Online > (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe64:mpt0:1:1:0): Retrying command > (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe64:mpt0:1:1:0): Retrying command > (probe0:mpt0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00= =20 > (probe0:mpt0:0:0:0): CAM status: SCSI Status Error > (probe0:mpt0:0:0:0): SCSI status: Check Condition > (probe0:mpt0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:ffffffff,ffffffff (Re= served ASC/ASCQ pair) > (probe0:mpt0:0:0:0): Error 22, Unretryable error > (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe64:mpt0:1:1:0): Retrying command > (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe64:mpt0:1:1:0): Retrying command > (probe64:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe64:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe64:mpt0:1:1:0): Error 5, Retries exhausted > (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe1:mpt0:1:1:0): Retrying command > (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe1:mpt0:1:1:0): Retrying command > (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe1:mpt0:1:1:0): Retrying command > (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe1:mpt0:1:1:0): Retrying command > (probe1:mpt0:1:1:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe1:mpt0:1:1:0): CAM status: Unrecoverable Host Bus Adapter Error > (probe1:mpt0:1:1:0): Error 5, Retries exhausted > da0 at mpt0 bus 0 scbus0 target 0 lun 0 > ses0 at mpt0 bus 0 scbus0 target 8 lun 0 > pass2 at mpt0 bus 1 scbus1 target 0 lun 0 >=20 > I can try to narrow down when this regression was introduced, but I fig- > ured I'd report it in case somebody has an "ah-hah" moment from seeing it.= >=20 > Also, there has always been an issue with passthru on these controllers -= > as you can see above, there are 2 physical disks attached to the controlle= r, > used as a mirror volume. But only one of the members appears as a passN de= - > vice, which means that the other one can't be monitored with smartmontools= . > If I'm remembering correctly, a volume with more than 2 drives creates a > passN device for all but one of the drives. >=20 > Terry Kennedy http://www.glaver.org New York, NY USA > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-stable@freebsd.org Fri Feb 19 14:53:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 811B9AAD4A3 for ; Fri, 19 Feb 2016 14:53:54 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from server.glaver.org (server.glaver.org [204.141.35.63]) (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 595311D67 for ; Fri, 19 Feb 2016 14:53:53 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from glaver.org by glaver.org (PMDF V6.6 #37010) id <01PWV4IHZ6NK00009M@glaver.org> for freebsd-stable@freebsd.org; Fri, 19 Feb 2016 09:53:50 -0500 (EST) Date: Fri, 19 Feb 2016 09:44:03 -0500 (EST) From: Terry Kennedy Subject: Re: 10.3-BETA2 regression in MPT In-reply-to: "Your message dated Fri, 19 Feb 2016 09:28:41 -0500" To: Mark Saad Cc: Terry Kennedy , freebsd-stable@freebsd.org Message-id: <01PWV4YM2HKS00009M@glaver.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <01PWUKZNJW2C0002VH@glaver.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:53:54 -0000 > Can you get the status of the controller and disks via mptutil ? Also > what does camcontrol devlist -v show ? 8.4 (8-STABLE): # mptutil show adapter mpt0 Adapter: Board Name: SAS6IR Board Assembly: Chip Name: C1068E Chip Revision: UNUSED RAID Levels: RAID0, RAID1, RAID1E RAID0 Stripes: 64k RAID1E Stripes: 64k RAID0 Drives/Vol: 2-10 RAID1 Drives/Vol: 2 RAID1E Drives/Vol: 3-10 # mptutil show drives mpt0 Physical Drives: 0 ( 137G) ONLINE SAS bus 0 id 1 1 ( 137G) ONLINE SAS bus 0 id 9 # mptutil show volumes mpt0 Volumes: Id Size Level Stripe State Write-Cache Name 0 ( 136G) RAID-1 OPTIMAL Enabled # camcontrol devlist -v scbus0 on mpt0 bus 0: at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 8 lun 0 (ses0,pass1) <> at scbus0 target -1 lun -1 () scbus1 on mpt0 bus 1: at scbus1 target 0 lun 0 (pass2) <> at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) 10.3-BETA2: # mptutil show adapter mpt0 Adapter: Board Name: SAS6IR Board Assembly: Chip Name: C1068E Chip Revision: UNUSED RAID Levels: RAID0, RAID1, RAID1E RAID0 Stripes: 64K RAID1E Stripes: 64K RAID0 Drives/Vol: 2-10 RAID1 Drives/Vol: 2 RAID1E Drives/Vol: 3-10 # mptutil show drives mpt0 Physical Drives: 0 ( 137G) ONLINE SAS bus 0 id 1 1 ( 137G) ONLINE SAS bus 0 id 9 # mptutil show volumes mpt0 Volumes: Id Size Level Stripe State Write-Cache Name 0 ( 136G) RAID-1 OPTIMAL Enabled # camcontrol devlist -v scbus0 on mpt0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 8 lun 0 (ses0,pass1) <> at scbus0 target -1 lun ffffffff () scbus1 on mpt0 bus 1: at scbus1 target 0 lun 0 (pass2) <> at scbus1 target -1 lun ffffffff () scbus2 on ata2 bus 0: at scbus2 target 1 lun 0 (pass3,cd0) <> at scbus2 target -1 lun ffffffff () scbus3 on ata3 bus 0: <> at scbus3 target -1 lun ffffffff () scbus4 on ata4 bus 0: <> at scbus4 target -1 lun ffffffff () scbus5 on ata5 bus 0: <> at scbus5 target -1 lun ffffffff () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff (xpt0) To clarify, things seem to work fine on 10.3-BETA2 after the system has booted, but there is a _long_ pause while the kernel is probing the mpt0 controller, followed by the spew of CAM error messages from the probes. Let me know if you need any additional info. Terry Kennedy http://www.glaver.org New York, NY USA From owner-freebsd-stable@freebsd.org Fri Feb 19 15:39:56 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65431AAE73D for ; Fri, 19 Feb 2016 15:39:56 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 2E0C8189F for ; Fri, 19 Feb 2016 15:39:55 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-yw0-x235.google.com with SMTP id h129so70318273ywb.1 for ; Fri, 19 Feb 2016 07:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lyD2DUBqY0fhiDg9Cw9h1Wo1keAsyXBX/uEIpb5lsOs=; b=noKbybEjkY4JjOg4Xz8bCRNPz8dyJ2PC6WMVGVqjtuAbnNzkVbyLjTDOp3kA7/OyOP 5/B8Zftbk0ALlLeXu6mBixUz8zk71bajD2UE1j4KV+9uQc7G4vXsVt2IuO3EAprl0bIG pXJWRevsuPAwgN6bWFWeO1ogxF+aXVxIAeXwodGAqN4METmEcseHJbLIqc00Xv/tNjhe oV+Z2pfQTmKml07t8ZOdZtcToYl1PbnzZLwgZymAdzDOluKtGXPQ3cQn6WgyRDvJWOeM V+lqoDnkLaob0uJOghzF8RIwwhG60wb7u/8n6xw5f/JJGcKlbNw209Y6x+6/d6tqLWu7 cXHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lyD2DUBqY0fhiDg9Cw9h1Wo1keAsyXBX/uEIpb5lsOs=; b=NCd2caOHerm5lSWa0MfAnRlsgL4ePOq+YgSnd9AtpUqGHpKYEUg1gh9BSnFskbhYQI 1EPTSvTQttKIaGTvRkMbERBkbGl9jgWGg8ZOepD9BKFO75Nyskd99dR3JF37ft1cSyrf mXu7+bXWMmTjIZNWYY3tDOoQLFKpYtQfgcUvSu9LZxi4FZXZDtIfipJViB3E9/uivFa0 kAGVBrCWHkJYNABu6J+7qZlHT9tALqrGgLp9LBeA21CSDtZ/E/aJ0bTPlOGykkaQLZyg lTIbtj+cjFXYZ38WJMm5HpNRnIkGkzWBYrQQOP5nMywmxnq9NTZGnpSJRyB/2tQVJBmt /izw== X-Gm-Message-State: AG10YOT5A07nniVb34broSVCn/u7kBunuxM10/JMYY4wXT6InUT3LeVQ2tv8SLy1nTe6PERSbs9XlnF8kqOIDA== MIME-Version: 1.0 X-Received: by 10.129.92.196 with SMTP id q187mr8781627ywb.120.1455896395128; Fri, 19 Feb 2016 07:39:55 -0800 (PST) Received: by 10.13.214.74 with HTTP; Fri, 19 Feb 2016 07:39:55 -0800 (PST) X-Originating-IP: [207.237.155.242] In-Reply-To: <01PWV4YM2HKS00009M@glaver.org> References: <01PWUKZNJW2C0002VH@glaver.org> <01PWV4YM2HKS00009M@glaver.org> Date: Fri, 19 Feb 2016 10:39:55 -0500 Message-ID: Subject: Re: 10.3-BETA2 regression in MPT From: Mark Saad To: Terry Kennedy Cc: FreeBSD-Stable ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:39:56 -0000 TMK, On Fri, Feb 19, 2016 at 9:44 AM, Terry Kennedy wrote: > > Can you get the status of the controller and disks via mptutil ? Also > > what does camcontrol devlist -v show ? > > 8.4 (8-STABLE): > > # mptutil show adapter > mpt0 Adapter: > Board Name: SAS6IR > Board Assembly: > Chip Name: C1068E > Chip Revision: UNUSED > RAID Levels: RAID0, RAID1, RAID1E > RAID0 Stripes: 64k > RAID1E Stripes: 64k > RAID0 Drives/Vol: 2-10 > RAID1 Drives/Vol: 2 > RAID1E Drives/Vol: 3-10 > > # mptutil show drives > mpt0 Physical Drives: > 0 ( 137G) ONLINE SAS bus 0 id 1 > 1 ( 137G) ONLINE SAS bus 0 id 9 > > # mptutil show volumes > mpt0 Volumes: > Id Size Level Stripe State Write-Cache Name > 0 ( 136G) RAID-1 OPTIMAL Enabled > > # camcontrol devlist -v > scbus0 on mpt0 bus 0: > at scbus0 target 0 lun 0 (da0,pass0) > at scbus0 target 8 lun 0 (ses0,pass1) > <> at scbus0 target -1 lun -1 () > scbus1 on mpt0 bus 1: > at scbus1 target 0 lun 0 (pass2) > <> at scbus1 target -1 lun -1 () > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun -1 (xpt0) > > 10.3-BETA2: > > # mptutil show adapter > mpt0 Adapter: > Board Name: SAS6IR > Board Assembly: > Chip Name: C1068E > Chip Revision: UNUSED > RAID Levels: RAID0, RAID1, RAID1E > RAID0 Stripes: 64K > RAID1E Stripes: 64K > RAID0 Drives/Vol: 2-10 > RAID1 Drives/Vol: 2 > RAID1E Drives/Vol: 3-10 > > # mptutil show drives > mpt0 Physical Drives: > 0 ( 137G) ONLINE SAS bus 0 id 1 > 1 ( 137G) ONLINE SAS bus 0 id 9 > > # mptutil show volumes > mpt0 Volumes: > Id Size Level Stripe State Write-Cache Name > 0 ( 136G) RAID-1 OPTIMAL Enabled > > # camcontrol devlist -v > scbus0 on mpt0 bus 0: > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 8 lun 0 (ses0,pass1) > <> at scbus0 target -1 lun ffffffff () > scbus1 on mpt0 bus 1: > at scbus1 target 0 lun 0 (pass2) > <> at scbus1 target -1 lun ffffffff () > scbus2 on ata2 bus 0: > at scbus2 target 1 lun 0 (pass3,cd0) > <> at scbus2 target -1 lun ffffffff () > scbus3 on ata3 bus 0: > <> at scbus3 target -1 lun ffffffff () > scbus4 on ata4 bus 0: > <> at scbus4 target -1 lun ffffffff () > scbus5 on ata5 bus 0: > <> at scbus5 target -1 lun ffffffff () > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun ffffffff (xpt0) > > To clarify, things seem to work fine on 10.3-BETA2 after the system > has booted, but there is a _long_ pause while the kernel is probing > the mpt0 controller, followed by the spew of CAM error messages from > the probes. > > Let me know if you need any additional info. > > Terry Kennedy http://www.glaver.org New York, NY USA > Can you build 10-STABLE and merge back the mpt driver prior to r285840 . It looks like a change was merged in about 7 weeks ago that has to do with probing the devices. https://svnweb.freebsd.org/base/stable/10/sys/dev/mpt/mpt.c?view=log -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@freebsd.org Fri Feb 19 15:46:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7FAAAAEA0E for ; Fri, 19 Feb 2016 15:46:48 +0000 (UTC) (envelope-from lrizzo@d0g.ca) Received: from d0g.ca (d0g.ca [IPv6:2602:ffb6:2:0:f816:3eff:fe8b:b17a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "d0g.ca", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D9FC1CFC for ; Fri, 19 Feb 2016 15:46:48 +0000 (UTC) (envelope-from lrizzo@d0g.ca) DKIM-Signature: v=1; a=rsa-sha256; d=d0g.ca; h=user-agent :content-disposition:content-type:content-type:mime-version :message-id:subject:subject:from:from:date:date:received; s= default; t=1455896804; x=1457711205; bh=PNiLslcwcgRRqh/4hruJ5NAR ShOMiedbyULp/4jkxn8=; b=E/GbdM+ihqc3Oh8NscTlk0Wy2TXgBsgkhgmz4pwG IEEBan5ZpnvbmWe2hkHItdzeT44w/kmWrAHRImeUnG5bZ7alg6/o1F7g1AhznIRd nTEPyOowfpQ/hsP0fwFFHzcd2/07FalJtTWt/ZUtkKMDbCMZqTGpuh/7+A87xxeR 8/4= Received: from d0g.ca (doggy@localhost [127.0.0.1]) by d0g.ca (8.15.2/8.15.2) with ESMTPS id u1JFkgBS017120 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Feb 2016 10:46:43 -0500 (EST) (envelope-from lrizzo@d0g.ca) Received: (from lrizzo@localhost) by d0g.ca (8.15.2/8.15.2/Submit) id u1JFkgvr017119 for freebsd-stable@freebsd.org; Fri, 19 Feb 2016 10:46:42 -0500 (EST) (envelope-from lrizzo) Date: Fri, 19 Feb 2016 10:46:41 -0500 From: Lucius Rizzo To: freebsd-stable@freebsd.org Subject: PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel Message-ID: <20160219154641.GA17110@d0g.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:46:48 -0000 Source: http://tech.slashdot.org/story/16/02/19/001202/pvs-studio-analyzer-spots-40-bugs-in-the-freebsd-kernel Q: So are we to expect kernel related updates to -stable? From owner-freebsd-stable@freebsd.org Fri Feb 19 15:59:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5378CAAD153 for ; Fri, 19 Feb 2016 15:59:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B044419AE for ; Fri, 19 Feb 2016 15:59:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u1JFxX3N062978 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Feb 2016 10:59:33 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u1JFxWol072955; Fri, 19 Feb 2016 10:59:32 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel To: Lucius Rizzo , freebsd-stable@freebsd.org References: <20160219154641.GA17110@d0g.ca> From: Mike Tancsa Organization: Sentex Communications Message-ID: <56C73BD4.50301@sentex.net> Date: Fri, 19 Feb 2016 10:59:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160219154641.GA17110@d0g.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:59:35 -0000 On 2/19/2016 10:46 AM, Lucius Rizzo wrote: > Source: http://tech.slashdot.org/story/16/02/19/001202/pvs-studio-analyzer-spots-40-bugs-in-the-freebsd-kernel > > Q: So are we to expect kernel related updates to -stable? You can see comments in the commit logs. https://lists.freebsd.org/pipermail/svn-src-head/2016-February/082577.html I imagine they will be MFC'd like any other bug after appropriate shakeout in HEAD ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Fri Feb 19 18:43:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04F64AAD3D2 for ; Fri, 19 Feb 2016 18:43:02 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (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 B2CCD1BF7 for ; Fri, 19 Feb 2016 18:43:00 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [192.168.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u1JIgtNA010167 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO) for ; Fri, 19 Feb 2016 12:42:56 -0600 (CST) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u1JIgtCm010166; Fri, 19 Feb 2016 12:42:55 -0600 (CST) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: FreeBSD Stable Subject: 10.3-BETA2 Buildworld issue X-PHP-Script: www.dweimer.net/webmail/index.php for 71.86.41.122, 192.168.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Feb 2016 12:42:55 -0600 From: dweimer Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:43:02 -0000 In my testing of 10.3-BETA2, I have discovered that the buildworld is failing on libc/posix1e/acl_support_nfs4.c on my mail server jail. Anyone have any ideas as to what's causing the issue? /jails/devel/ROOT/usr/src/lib/libc/posix1e/acl_support_nfs4.c:51:8: error: use of undeclared identifier 'ACL_ENTRY_INHERITED' { ACL_ENTRY_INHERITED, "inherited", 'I' }, ^ 1 error generated. *** Error code 1 Stop. I have successful built an installed on the host and in my other jails, the only difference with this jail is the following options in make.conf SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 The other jails (which built fine) are using the options below, this jail has these same options set with the additional entries above. #/etc/src.conf WITHOUT_NTP="YES" WIHTOUT_FLOPPY="YES" WITHOUT_FREEBSD_UPDATE="YES" WITH_BSD_GREP="YES" WITHOUT_IPX_SUPPORT="YES" WITHOUT_BLUETOOTH="YES" WITHOUT_WIRELESS="YES" WITHOUT_WPA_SUPPLICANT_EAPOL="YES" WITHOUT_ACPI="YES" WITHOUT_APM="YES" WITHOUT_ATM="YES" WITHOUT_BLUETOOTH="YES" WITHOUT_BOOT="YES" WITHOUT_GAMES="YES" WITHOUT_IPFILTER="YES" WITHOUT_IPFW="YES" WITHOUT_IPX="YES" WITHOUT_KVM="YES" WITHOUT_PF="YES" WITHOUT_PORTSNAP="YES" WITHOUT_PPP="YES" WITHOUT_USB="YES" WITHOUT_ZFS="YES" #/etc/make.conf CFLAGS?=-O CLFAGS+=-pipe NO_WERROR= WERROR= WITH_OPENSSL_PORT="YES" OPENSSL_PORT=security/libressl OPTIONS_UNSET="X11" OPTIONS_UNSET="X" OPTIONS_UNSET="GUI" WRKDIRPREFIX=/var/ports PACKAGES=/var/ports/packages WITH_PKGNG="YES" DEFAULT_VERSIONS=pgsql=9.5 php=5.6 apache=2.4 perl5=5.22 python=2.7 bdb=5 mysql=5.6 WITH_CCACHE_BUILD=yes .if !defined(NO_CCACHE) CC= /usr/local/libexec/ccache/world/cc CXX= /usr/local/libexec/ccache/world/c++ .endif .if ${.CURDIR:M*/ports/devel/ccache} NO_CCACHE= yes .endif -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@freebsd.org Fri Feb 19 18:54:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4926AADA9F for ; Fri, 19 Feb 2016 18:54:18 +0000 (UTC) (envelope-from pcalkins@aimdigitalpros.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 B7EA21499 for ; Fri, 19 Feb 2016 18:54:18 +0000 (UTC) (envelope-from pcalkins@aimdigitalpros.com) Received: by mail-pf0-x229.google.com with SMTP id c10so57200929pfc.2 for ; Fri, 19 Feb 2016 10:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aimdigitalpros-com.20150623.gappssmtp.com; s=20150623; h=to:subject:from:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=FrRTlJYPiQI/e9Col0GqvKprdZkbefPd5h94FbaOY4I=; b=UYO5/A7DTIupUyASV7bfsKa88G8qj/g4cTbIYnq1sZi6hJ9+TyysbRkhtWXSPZDiSm V+/0lyB95Zwrz0dej2xs5a7iowa215dCkp/dVrmSplOca33NRD/fLQIuTljWFuz9Vm5x F5dN1NX8vHQb86uojg2r28px2JXdscnkHXyr8BPYVfiUjtLzv45H8bXmAvdg1IlHlR5R y2Q1imkVwCuMakynPKjRFmuffRua9G/yehFihSOFMqLN+rVUl+dkq4Jwwn1uVEcm0IV6 mQIfnlD4ZyXbN5x3u1TviOJCaGvSJenP3Dc11Hy0AlyvS3NKuiJqWgqfuVB7PnMXF8TX DFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=FrRTlJYPiQI/e9Col0GqvKprdZkbefPd5h94FbaOY4I=; b=IwfpreXauswGHjOP794Mk6rQ9ULEQhLDRJ3WY9Iizc8A7vxbYtlM+VX+ed8G0+arqb ZS/9ZnP/E8Mgg5KNUSrY6n9He9lZPQSASavV0xBkg0b2psQR9jFM5F5m8zNKU1P3rVEX zi2o0NEupdH8AWEotzrBaYsDG4evgiWR2lZSh8uuMe4Jsnz7Uo5ZDybAwZTR7KrJtmZN lNES6kyLPFQozEnyHR3tUzHOz02d7c6n/rg+KCF1cOwRoh6rxmhyczcQHufbNCDMh+YM USC4n5hNmCKNMl6W+FE6LI3YVrLez1g25fs5zUVBKIvfg8CHZXYWWBbvY2FlQ27JR8MD e2aA== X-Gm-Message-State: AG10YOQWj6sQYsSmvxXig9vt7zP0knNybv+BfsVO40XhznFsgct0mPT32r66TJy4YcX6Lw== X-Received: by 10.98.65.14 with SMTP id o14mr20114177pfa.151.1455908058358; Fri, 19 Feb 2016 10:54:18 -0800 (PST) Received: from [127.0.0.1] ([103.6.157.159]) by smtp.gmail.com with ESMTPSA id 79sm19382988pfq.65.2016.02.19.10.54.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2016 10:54:17 -0800 (PST) To: freebsd-stable@freebsd.org Subject: Avaya Users List From: Phoebe Calkins Message-ID: <56C76452.1030408@aimdigitalpros.com> Date: Fri, 19 Feb 2016 13:52:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 160219-0, 02/19/2016), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:54:19 -0000 Hi, Would you be interested in reaching out “Avaya Users List” with opt-in verified contact information from USA? We also have Avaya Aura Users, Avaya Network Hardware, Avaya CentreVu Supervisor, Avaya Intuity, Avaya Octel, Avaya PBX, Avaya IP Agent, Avaya Unified Communications, and many more..... We provide 30+ Data fields on each record which contains: Company Name ,Contact First Name, Last Name, Title, HQ Phone, Direct No, Email, Address1, Address2, City, State, Zip, Country, Industry, Revenue, Fiscal Year End, Employees, IT Budget, IT Employees, Website, Technology, Company HQ Address1, Company HQ Address2, Company HQ City, Company HQ State, Company HQ Zip, Company HQ Country and LinkedIn link Please let me know your targeted criteria, so that i can help you out to driver your sales effort in the right direction. Thanks & Regards, Phoebe Calkins --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From owner-freebsd-stable@freebsd.org Fri Feb 19 21:57:25 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CF87AAED5F for ; Fri, 19 Feb 2016 21:57:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4D61E78; Fri, 19 Feb 2016 21:57:25 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 526F91A06; Fri, 19 Feb 2016 21:57:25 +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 11BCE18855; Fri, 19 Feb 2016 21:57:25 +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 sd_9CPhrHvXN; Fri, 19 Feb 2016 21:57:22 +0000 (UTC) Subject: Re: 10.3-BETA2 Buildworld issue DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 575611884E To: dweimer@dweimer.net, FreeBSD Stable References: From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56C78FBF.1050904@FreeBSD.org> Date: Fri, 19 Feb 2016 13:57:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5X3f8uWa3IA1s7b4X2BADv29mWc1x737b" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 21:57:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5X3f8uWa3IA1s7b4X2BADv29mWc1x737b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/19/2016 10:42 AM, dweimer wrote: >=20 > In my testing of 10.3-BETA2, I have discovered that the buildworld is > failing on libc/posix1e/acl_support_nfs4.c on my mail server jail. > Anyone have any ideas as to what's causing the issue? >=20 > /jails/devel/ROOT/usr/src/lib/libc/posix1e/acl_support_nfs4.c:51:8: > error: use of undeclared identifier 'ACL_ENTRY_INHERITED' > { ACL_ENTRY_INHERITED, "inherited", 'I' }, > ^ That is defined in sys/sys/acl.h. It all seems fine to me. Check in your OBJDIR for a tmp/usr/include/sys/acl.h file and see if it has ACL_ENTRY_INHERITED defined. --=20 Regards, Bryan Drewery --5X3f8uWa3IA1s7b4X2BADv29mWc1x737b 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 iQEcBAEBAgAGBQJWx4+/AAoJEDXXcbtuRpfPg88H/2N+BDQHJ1X25rDLjSV8Um85 l+BxDCt1KQcNJaDsnGb9LAcgToFY1vUCFKxHqV7R1X6LkWJ1t+eOg/RWMquRdY5y dyp/dD26xD91KBRfSswqSCaO7G0IKUAXp+ah8CxzCQ9NODmLC/9SMuIzdROiNumL SfJofoyiRkGzTXyv5d06EMOwjozcpVJefyTGxu9pf+QqarbtObKZvn3jMSs/o0N8 hjHxgnY1d6Dq3AmyE/yVw/a4ZHUsEUAWr/ZHr9rVBQFpr0BxrrglNGSktV/iNk4n O41rnYSxdIRRQWTIyX9HT/LXx+CMMMaR9gu2arzL3+JBSahLLKxB0+Z8YgMfRqs= =j66R -----END PGP SIGNATURE----- --5X3f8uWa3IA1s7b4X2BADv29mWc1x737b-- From owner-freebsd-stable@freebsd.org Fri Feb 19 22:01:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55AC2AAD01D for ; Fri, 19 Feb 2016 22:01:02 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3B324121D; Fri, 19 Feb 2016 22:01:02 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 30E0E1C76; Fri, 19 Feb 2016 22:01:02 +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 A9C901887A; Fri, 19 Feb 2016 22:01: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 cFzQa-3XmW5t; Fri, 19 Feb 2016 22:00:58 +0000 (UTC) Subject: Re: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2775F18875 To: Jim Ohlstein , freebsd-stable stable References: <56B6014D.9090602@ohlste.in> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56C790A7.4040508@FreeBSD.org> Date: Fri, 19 Feb 2016 14:01:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B6014D.9090602@ohlste.in> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibdFgNElGfvpwvQMrGUHuCgiQluDWuML3" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:01:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ibdFgNElGfvpwvQMrGUHuCgiQluDWuML3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/6/2016 6:21 AM, Jim Ohlstein wrote: > Hello, >=20 > First noticed: >=20 > root@rubicon:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 295341 > Node Kind: directory > Schedule: normal > Last Changed Author: marius > Last Changed Rev: 295289 > Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016) >=20 >=20 > Still present: >=20 > root@rubicon:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 295351 > Node Kind: directory > Schedule: normal > Last Changed Author: wblock > Last Changed Rev: 295350 > Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016) >=20 >=20 > root@rubicon:/usr/src # make clean && make buildworld >=20 >=20 > [snip] >=20 >=20 >=20 > cc -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS -std=3Diso9899:1999 > -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -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 -Wmissing-variable-declarations -Wno-pointer-sig= n > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c > /usr/src/lib/libfetch/common.c -o common.o > /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL' > [-Werror,-Wunused-parameter] > fetch_ssl(conn_t *conn, const struct url *URL, int verbose) > ^ Try this patch please: https://people.freebsd.org/~bdrewery/patches/libfetch-unused-ssl.patch --=20 Regards, Bryan Drewery --ibdFgNElGfvpwvQMrGUHuCgiQluDWuML3 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 iQEcBAEBAgAGBQJWx5CoAAoJEDXXcbtuRpfP0FIH/AjqfwN7t2c6gIbjEM/mS4Md UFJOnG8KVdjeXTg0aSJ8qmbIs5ZGiFEOHeu9mANVi15FxNqzCpW9C6bG3CZfRZEM HbevLRdRpqIHihqSD1U9+cMEmNRDefuUPp9N68RAFsP9gZrbD4h6hRacG4HXOvML 0ZZ6iNIsPGSxYp5H3n2ysGJueMwr1hCU4fI0sruexutDJtc98W8E9FaqvChWYtVT npNkwck303w6uWQZRajFFY1VuBuGQ6FsV+SVqjcqAe/aDALeZ4RYdOHA0pqksPIi RHZ8oUB+rZOARKd5TLjf9uLlt6V/3Zo4bnmNpRxmUNEcwp+hnAansDd1csiV9+Q= =O166 -----END PGP SIGNATURE----- --ibdFgNElGfvpwvQMrGUHuCgiQluDWuML3-- From owner-freebsd-stable@freebsd.org Fri Feb 19 22:41:20 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86E92AA94F9 for ; Fri, 19 Feb 2016 22:41:20 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 0296F18AF; Fri, 19 Feb 2016 22:41:19 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: by mail-lb0-x235.google.com with SMTP id x4so55631886lbm.0; Fri, 19 Feb 2016 14:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YEJ3w/A6qZOQjb6iNToig9f6ujxUV8Xjpqh7UMi6iVM=; b=pSoZP8ZovWgQXpidioNwTs5fkkP15ZoKgtjicPnEOrhncpOBPVlH/fZVSVmInwU6+v RoGXeJjap9PqbfwwMjexB6WSFQ4HDkYMsJ+k2diN2DGXrg0fSlM8o59czOzCea36wi48 5njiXMv+mA4KapmqL6kYLjR3Hmj7JlSlJ6nM8xSof0OaMw/JgxwzQUPj/pVLPAaIPiIm IMPxRXqGY93v6/3efNKc/DdWb+NNWUuXOTiHa+v+w9ZEgGNjkf1j5TzrfC1YVoHaF+ZD AuYpkOglF0thDalcIytYCujxl1dXm13589hAIGHT6OGK9doHONAPG1hrYYB7XCPUzvsJ s2OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YEJ3w/A6qZOQjb6iNToig9f6ujxUV8Xjpqh7UMi6iVM=; b=bKLXjkpy+eX2zD+d50dN1NlAj87dSenfY1PRo0Ar4KqfdVNdjJl8N4DHBxzqzk0SAk SJ0okTzcnYWD05BcG/hv8sspC7TqdFK16DmpqogHx5PXgPq6PelSVRbgx9nf75rZKeGp crgvqWTN+6JtD3KO85q8W8EJ5YQwv/+Vkaj2dLHVbBFGPIviJoN4G/jcMKRoq+wR5Jrw ColDZiRn1mDIWUJdMl+VOPtqFgK+1MRSHBY/rN/CqtNDrWQtZoqSpntf9OPlE7NKvwxY hgDUjsw1rBJFUBeL4YNgV0iI4R+uDTNK7cZpovG2gRNoa1KZDq19clgn8a4K9aAXnmCT UIdg== X-Gm-Message-State: AG10YOT0mWlzfppV6kLVqPu1bzTuDSIkwwpQw/30lo24eaITj3INz+GDb70Xq1H6IqVTXS003eGXRGfGkyHRIw== X-Received: by 10.112.199.197 with SMTP id jm5mr5085252lbc.109.1455921678087; Fri, 19 Feb 2016 14:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.142.83 with HTTP; Fri, 19 Feb 2016 14:40:48 -0800 (PST) In-Reply-To: <56C790A7.4040508@FreeBSD.org> References: <56B6014D.9090602@ohlste.in> <56C790A7.4040508@FreeBSD.org> From: Dewayne Geraghty Date: Sat, 20 Feb 2016 09:40:48 +1100 Message-ID: Subject: Re: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE To: Bryan Drewery Cc: Jim Ohlstein , freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:41:20 -0000 On 20 February 2016 at 09:01, Bryan Drewery wrote: > On 2/6/2016 6:21 AM, Jim Ohlstein wrote: > > Hello, > > > > First noticed: > > > > root@rubicon:/usr/src # svn info > > Path: . > > Working Copy Root Path: /usr/src > > URL: https://svn.freebsd.org/base/stable/10 > > Relative URL: ^/stable/10 > > Repository Root: https://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 295341 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: marius > > Last Changed Rev: 295289 > > Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016) > > > > > > Still present: > > > > root@rubicon:/usr/src # svn info > > Path: . > > Working Copy Root Path: /usr/src > > URL: https://svn.freebsd.org/base/stable/10 > > Relative URL: ^/stable/10 > > Repository Root: https://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 295351 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: wblock > > Last Changed Rev: 295350 > > Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016) > > > > > > root@rubicon:/usr/src # make clean && make buildworld > > > > > > [snip] > > > > > > > > cc -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS -std=iso9899:1999 > > -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -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 -Wmissing-variable-declarations -Wno-pointer-sign > > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c > > /usr/src/lib/libfetch/common.c -o common.o > > /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL' > > [-Werror,-Wunused-parameter] > > fetch_ssl(conn_t *conn, const struct url *URL, int verbose) > > ^ > > > Try this patch please: > https://people.freebsd.org/~bdrewery/patches/libfetch-unused-ssl.patch > > > -- > Regards, > Bryan Drewery > > Unfortunately, I think you'll find that you'll need openssl for: libarchive, geom_eli, tar and gssd as well. Good luck (I tried a few years ago but failed because I really needed geli). From owner-freebsd-stable@freebsd.org Fri Feb 19 22:51:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3DC8AA9CD2 for ; Fri, 19 Feb 2016 22:51:06 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 671B41298 for ; Fri, 19 Feb 2016 22:51:06 +0000 (UTC) (envelope-from jim@ohlste.in) Received: by mail-qg0-x231.google.com with SMTP id y9so74315649qgd.3 for ; Fri, 19 Feb 2016 14:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ohlste-in.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=0WlcC2AHR6tJM5vNkv73aLaSFfSovgGy1Rv9HhtgH08=; b=Jc/uxwJi+MniUaEO8WRUdpGviQWxke6QY69bluhbfB8fQqaKWgH0T6kkC2+QffcOHY JLEgTTgF4U9+c0odcJ6ewiCi0w+bgPGyxzbKZqcXbLdFuq12+jUHofYUBbd2qyB0YgcM /vrLWg8TFWyOrZyHhyUczvy4oFUhKAdsg+WKzbdhrvf1uVfEfaPOzEzDovdWoy1iOdi9 Xy9yp05+KYncTqAck2LRgfEXnK/qNPpGapSPc5sVo9vNS6CmsiV0OGfnzncKLEMoudvz PbjOhElj2Ov1vsEEhM4egdK/qovrZkcH9USF3aPvtU/U6phzF0KK8u3E0BhpYLr2Envn 0vug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=0WlcC2AHR6tJM5vNkv73aLaSFfSovgGy1Rv9HhtgH08=; b=f/AGOdOFtNk16mp6WxNZnFjGTZoLBSLtsanChbQfdIYJ0noJbyLYRZGfKM/huHjkrw oxV9tJySd+YVTtkcdarSZ4zMcqLXWS0lpjFIqg5J6LYmY2em1W5fWKkCljSEvVoYS4hx s8TnZIQboVdawHF3mkcrSvbc0zyKAlUxGXyQ0K/vdqQYvypPVi1cAbZ+AhyTzX8WMnGF JnYdI++XC5PkmyK/GaC0pqN+d+VCnLV+jcsyijyD5V3+G/iUOLIAWLNlQeE+y1xElT22 p/mM+iFUC7GMtPFn4m8jfzUwkLrNTlcNWx3Yuhdo3TzPK8frod58cIB48Q3hq42vZ38+ GlvA== X-Gm-Message-State: AG10YOSVQlyMTDqHXgtTsbL32bbIVoLgCj2ZCddbx1cFAq6JgqMjYFRJkk1V7Fm+IpdMgQ== X-Received: by 10.140.102.142 with SMTP id w14mr11149684qge.58.1455922265269; Fri, 19 Feb 2016 14:51:05 -0800 (PST) Received: from [192.168.1.18] (pool-96-249-243-37.nrflva.fios.verizon.net. [96.249.243.37]) by smtp.googlemail.com with ESMTPSA id z124sm5516708qhz.46.2016.02.19.14.51.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 14:51:04 -0800 (PST) Subject: Re: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE To: Dewayne Geraghty , Bryan Drewery References: <56B6014D.9090602@ohlste.in> <56C790A7.4040508@FreeBSD.org> Cc: freebsd-stable stable From: Jim Ohlstein Message-ID: <56C79C57.3060909@ohlste.in> Date: Fri, 19 Feb 2016 17:51:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:51:06 -0000 Hello, On 2/19/16 5:40 PM, Dewayne Geraghty wrote: > On 20 February 2016 at 09:01, Bryan Drewery > wrote: > > On 2/6/2016 6:21 AM, Jim Ohlstein wrote: > > Hello, > > > > First noticed: > > > > root@rubicon:/usr/src # svn info > > Path: . > > Working Copy Root Path: /usr/src > > URL: https://svn.freebsd.org/base/stable/10 > > Relative URL: ^/stable/10 > > Repository Root: https://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 295341 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: marius > > Last Changed Rev: 295289 > > Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016) > > > > > > Still present: > > > > root@rubicon:/usr/src # svn info > > Path: . > > Working Copy Root Path: /usr/src > > URL: https://svn.freebsd.org/base/stable/10 > > Relative URL: ^/stable/10 > > Repository Root: https://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 295351 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: wblock > > Last Changed Rev: 295350 > > Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016) > > > > > > root@rubicon:/usr/src # make clean && make buildworld > > > > > > [snip] > > > > > > > > cc -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS -std=iso9899:1999 > > -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -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 -Wmissing-variable-declarations > -Wno-pointer-sign > > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c > > /usr/src/lib/libfetch/common.c -o common.o > > /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL' > > [-Werror,-Wunused-parameter] > > fetch_ssl(conn_t *conn, const struct url *URL, int verbose) > > ^ > > > Try this patch please: > https://people.freebsd.org/~bdrewery/patches/libfetch-unused-ssl.patch > > > > > -- > Regards, > Bryan Drewery > > > Unfortunately, I think you'll find that you'll need openssl for: > libarchive, geom_eli, tar and gssd as well. > Good luck (I tried a few years ago but failed because I really needed > geli). Got stuck elsewhere but looks like it's totally broken. This is a parallel build of r 295826 but looks pretty obvious where it bails: /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/bind.c:2051:20: note: use '==' to turn this assignment into an equality comparison for (i = 0; name = names[i]; i++) ^ == --- display.o --- --- lib__L --- In file included from /usr/src/lib/libldns/../../contrib/ldns/parse.c:11: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ --- gnu/lib__L --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/display.c -o display.o --- lib__L --- 1 error generated. --- gnu/lib__L --- --- signals.o --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/signals.c -o signals.o --- lib__L --- In file included from /usr/src/lib/libldns/../../contrib/ldns/rdata.c:15: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. In file included from /usr/src/lib/libldns/../../contrib/ldns/resolver.c:15: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. --- depend_subdir_libnv --- ===> lib/libnv (depend) --- depend_subdir_libopie --- ===> lib/libopie (depend) --- depend_subdir_libldns --- In file included from /usr/src/lib/libldns/../../contrib/ldns/rr.c:12: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. --- depend_subdir_libnv --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libnv/../../sys -I/usr/src/lib/libnv -std=gnu99 /usr/src/lib/libnv/../../sys/kern/subr_dnvlist.c /usr/src/lib/libnv/msgio.c /usr/src/lib/libnv/../../sys/kern/subr_nvlist.c /usr/src/lib/libnv/../../sys/kern/subr_nvpair.c --- gnu/lib__L --- --- util.o --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/util.c -o util.o --- lib__L --- --- depend_subdir_libldns --- In file included from /usr/src/lib/libldns/../../contrib/ldns/rr_functions.c:18: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. In file included from /usr/src/lib/libldns/../../contrib/ldns/sha1.c:20: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. In file included from /usr/src/lib/libldns/../../contrib/ldns/str2host.c:15: --- gnu/lib__L --- --- kill.o --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/kill.c -o kill.o --- lib__L --- In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. --- depend_subdir_libpcap --- ===> lib/libpcap (depend) --- depend_subdir_libldns --- In file included from /usr/src/lib/libldns/../../contrib/ldns/tsig.c:12: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ --- gnu/lib__L --- --- complete.o --- 3 warnings generated. --- lib__L --- 1 error generated. --- depend_subdir_libpmc --- ===> lib/libpmc (depend) --- depend_subdir_libpcap --- --- version.c --- sed 's/.*/char pcap_version[] = "&";/' /usr/src/lib/libpcap/../../contrib/libpcap/VERSION > version.c --- depend_subdir_libldns --- In file included from /usr/src/lib/libldns/../../contrib/ldns/update.c:12: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ --- depend_subdir_libpcap --- --- grammar.c --- yacc -d -p pcapyy -o grammar.c /usr/src/lib/libpcap/../../contrib/libpcap/grammar.y --- depend_subdir_libldns --- 1 error generated. --- depend_subdir_libpmc --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 /usr/src/lib/libpmc/libpmc.c /usr/src/lib/libpmc/pmclog.c --- depend_subdir_libpcap --- --- version.h --- sed 's/.*/char pcap_version_string[] = "libpcap version &";/' /usr/src/lib/libpcap/../../contrib/libpcap/VERSION > version.h --- scanner.c --- lex -Ppcapyy -oscanner.c /usr/src/lib/libpcap/../../contrib/libpcap/scanner.l --- depend_subdir_libldns --- /usr/src/lib/libldns/../../contrib/ldns/util.c:26:10: fatal error: 'openssl/rand.h' file not found #include ^ 1 error generated. In file included from /usr/src/lib/libldns/../../contrib/ldns/wire2host.c:19: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ 1 error generated. --- depend_subdir_libpcap --- --- tokdefs.h --- ln -sf grammar.h tokdefs.h --- depend_subdir_libldns --- In file included from /usr/src/lib/libldns/../../contrib/ldns/zone.c:11: In file included from /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:31:10: fatal error: 'openssl/ssl.h' file not found #include ^ --- gnu/lib__L --- --- undo.o --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/undo.c -o undo.o --- lib__L --- 1 error generated. --- gnu/lib__L --- --- macro.o --- cc -O2 -pipe -I/usr/src/gnu/lib/libreadline/readline/.. -I/usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline -DHAVE_CONFIG_H -DRL_LIBRARY_VERSION='"5.2"' -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/lib/libreadline/readline/../../../../contrib/libreadline/macro.c -o macro.o --- lib__L --- mkdep: compile failed --- depend_subdir_libpcap --- --- .depend --- --- depend_subdir_libldns --- *** [.depend] Error code 1 make[5]: stopped in /usr/src/lib/libldns 1 error make[5]: stopped in /usr/src/lib/libldns *** [depend_subdir_libldns] Error code 2 make[4]: stopped in /usr/src/lib --- depend_subdir_libpcap --- rm -f .depend CC='cc ' mkdep -f .depend -a -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H -I/usr/src/lib/libpcap/../../contrib/libpcap -std=gnu99 grammar.c /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /usr/src/lib/libpcap/pcap-netmap.c /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c /usr/src/lib/libpcap/../../contrib/libpcap/pcap-common.c /usr/src/lib/libpcap/../../contrib/libpcap/inet.c /usr/src/lib/libpcap/../../contrib/libpcap/fad-getad.c /usr/src/lib/libpcap/../../contrib/libpcap/gencode.c /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c /usr/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /usr/src/lib/libpcap/../../contrib/libpcap/etherent.c /usr/src/lib/libpcap/../../contrib/libpcap/savefile.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf_dump.c scanner.c /usr/src/lib/libpcap/../../contrib/libpcap/sf-pcap.c /usr/src/lib/libpcap/../../contrib/libpcap/sf-pcap-ng.c version.c --- gnu/lib__L --- --- bind.o --- 4 warnings generated. --- lib__L --- --- depend_subdir_libngatm --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libngatm *** [depend_subdir_libngatm] Error code 2 make[4]: stopped in /usr/src/lib --- gnu/lib__L --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/gnu/lib/libreadline/readline *** [_sub.all] Error code 2 make[5]: stopped in /usr/src/gnu/lib/libreadline 1 error make[5]: stopped in /usr/src/gnu/lib/libreadline *** [all_subdir_libreadline] Error code 2 make[4]: stopped in /usr/src/gnu/lib 1 error make[4]: stopped in /usr/src/gnu/lib *** [gnu/lib__L] Error code 2 make[3]: stopped in /usr/src --- cddl/lib__L --- --- depend_subdir_libzpool --- echo libzpool.so.2: /usr/obj/usr/src/tmp/usr/lib/libmd.a /usr/obj/usr/src/tmp/usr/lib/libpthread.a /usr/obj/usr/src/tmp/usr/lib/libz.a /usr/obj/usr/src/tmp/usr/lib/libnvpair.a /usr/obj/usr/src/tmp/usr/lib/libavl.a /usr/obj/usr/src/tmp/usr/lib/libumem.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/cddl/lib/libzpool *** [depend_subdir_libzpool] Error code 2 make[4]: stopped in /usr/src/cddl/lib 1 error make[4]: stopped in /usr/src/cddl/lib *** [cddl/lib__L] Error code 2 make[3]: stopped in /usr/src --- lib__L --- --- depend_subdir_libpcap --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libpcap *** [depend_subdir_libpcap] Error code 2 make[4]: stopped in /usr/src/lib 3 errors make[4]: stopped in /usr/src/lib *** [lib__L] Error code 2 make[3]: stopped in /usr/src 3 errors make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] 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 Contents of src.conf: # cat /etc/src.conf WITHOUT_GAMES=TRUE WITHOUT_WIRELES=TRUE WITHOUT_SENDMAIL=TRUE WITHOUT_BLUETOOTH=TRUE WITHOUT_FLOPPY=TRUE WITHOUT_IPFILTER=TRUE WITHOUT_IPFW=TRUE WITHOUT_UNBOUND=TRUE WITHOUT_OPENSSL=TRUE Perhaps this option should be taken out of the manual. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain From owner-freebsd-stable@freebsd.org Sat Feb 20 00:27:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2285AAE190 for ; Sat, 20 Feb 2016 00:27:30 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (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 A5752EE6; Sat, 20 Feb 2016 00:27:30 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.local (localhost [192.168.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPS id u1K0RVqM059308 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Fri, 19 Feb 2016 18:27:31 -0600 (CST) (envelope-from dweimer@dweimer.net) Received: (from www@localhost) by webmail.dweimer.local (8.15.2/8.15.2/Submit) id u1K0RUIT059306; Fri, 19 Feb 2016 18:27:30 -0600 (CST) (envelope-from dweimer@dweimer.net) X-Authentication-Warning: webmail.dweimer.local: www set sender to dweimer@dweimer.net using -f To: Bryan Drewery Subject: Re: 10.3-BETA2 Buildworld issue X-PHP-Script: www.dweimer.net/webmail/index.php for 192.168.5.1, 192.168.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Feb 2016 18:27:30 -0600 From: dweimer Cc: FreeBSD Stable Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <56C78FBF.1050904@FreeBSD.org> References: <56C78FBF.1050904@FreeBSD.org> Message-ID: <92130c784b8d76b1e0c5b2093bcb71fc@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:27:30 -0000 On 2016-02-19 3:57 pm, Bryan Drewery wrote: > On 2/19/2016 10:42 AM, dweimer wrote: >> >> In my testing of 10.3-BETA2, I have discovered that the buildworld is >> failing on libc/posix1e/acl_support_nfs4.c on my mail server jail. >> Anyone have any ideas as to what's causing the issue? >> >> /jails/devel/ROOT/usr/src/lib/libc/posix1e/acl_support_nfs4.c:51:8: >> error: use of undeclared identifier 'ACL_ENTRY_INHERITED' >> { ACL_ENTRY_INHERITED, "inherited", 'I' }, >> ^ > > That is defined in sys/sys/acl.h. It all seems fine to me. > > Check in your OBJDIR for a tmp/usr/include/sys/acl.h file and see if it > has ACL_ENTRY_INHERITED defined. I think I figured it out, it was due to the build of security/cyrus-sasl2 and security/cyrus-sasl2-saslauthd they were compiled on the old 10.2-RELEASE-p12 build I was updating. I copied the zfs dataset for the jail that I originally built the host 10.3 beta2 build on and installed the ports fresh under the 10.3-beta2 system and then buildworld completed successfully. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@freebsd.org Sat Feb 20 01:27:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77333AADE85 for ; Sat, 20 Feb 2016 01:27:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 16998C1B; Sat, 20 Feb 2016 01:27:20 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u1K1RCag007960 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Feb 2016 02:27:12 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u1K1RCAO007959; Sat, 20 Feb 2016 02:27:12 +0100 (CET) (envelope-from marius) Date: Sat, 20 Feb 2016 02:27:12 +0100 From: Marius Strobl To: freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 10.3-RELEASE schedule update Message-ID: <20160220012712.GB15359@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uN3tURjgVTLfI0kr" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sat, 20 Feb 2016 02:27:12 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 01:27:21 -0000 --uN3tURjgVTLfI0kr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As you may have read in the announcement of 10.3-BETA2, we are currently facing two regressions with the stable/10 code base for 10.3-RELEASE: o The tryfoward optimization introduced in r290383 and merged as r295285, which unconditionally replaces the previous IP fastforwarding option, has turned out to cause ICMP messages being sent back to incorrect addresses when NAT is applied by a machine running that revision and having divergent MTU. This problem was reported in the context of OpenVPN-based tunneling but also is not unlikely to generally cause a regression for Path MTU Discovery over a gateway doing NAT. For further details regarding the original problem see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087 o The fixes and optimizations to VFS(9) of r291244, which was merged as part of r292895, cause system hangs when using ZFS. If you are affected by this regression, please test the patch posted in: https://lists.freebsd.org/pipermail/freebsd-stable/2016-February/084180.html and report back there if the reversal of r291244 actually resolves the problem for you, especially if you are a user of amd64, as more confirmation still is needed for that architecture. At re@ it has been decided, that we will not enter the RC phase with these showstoppers in place. Thus, the original 10.3-RELEASE schedule has been put back by one week in order to allow for resolving these two problems, with the previously optional 10.3-BETA3 builds now taking place on February 26th, 2016. Consequently, the updated, remaining release cycle for 10.3-RELEASE as it currently stands is: BETA3 build starts: February 26, 2016 releng/10.3 branch: March 4, 2016 RC1 build starts: March 4, 2016 stable/10 thaw: March 6, 2016 release package copy: March 6, 2016 RC2 build starts: March 11, 2016 RC3 build starts: March 18, 2016 [*] RELEASE build starts: March 25, 2016 RELEASE announcement: March 29, 2016 RELEASE EoL: July 31, 2017 (tentative) [*] - If needed Marius On behalf of: re@ --uN3tURjgVTLfI0kr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWx8DqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5P0AsP/1WqwXtWpQ+KEQIZOpVS/EoN /OYZn4fWGb0jjcOYKF1BnLDWreC4TPdcVg2oDWLTtEIxiRbdbV0Qdy410pG8U6O9 cXzygWkdeEyUE/o0H5Wp2hsvHskv2DSLSjt0o1gTqSPEPVo23bnfQOrvrFj1UhLQ t81Pg04BXWsyoobrkOhgHV+8rdgFzSsdUL+hDUUJYtPRiO19szBxr62ZTDx4s3jb WDtJmImOaBxYCl79YPdk/O5oF3L/bNehCakdAz9+Vt6J0YK0m55a3L1HAvytrprY Ml0Qc1KeSO6Jgl8NKCQDPpn0Co7ei/bjUiwe/wHADvil1GjFxkxOZ982a9nv9Mlw WYb/aAKBRODtchA+4bFnXh9x4UhWuKhwf2lYO2GcTrn1cE1l/mkGUIu5Z2pAPGbL DMuovcYsnaKyvRfPz0nSHOguCupuGLzMQLhqEEtqqjrcNt00U3C2Bwqz2HJygsBJ oAqz7BhTcwiHpmxkOapPeibVU35vq3q3ZEGj7ig0DCMmkJOv+NuMsEm9ohwjoCVJ UaRER5FS5taPrLL+9AXDQHxhK7dp5oBiY1oK7ri09rp58Ts4z4wwjtK9RYAXQYtP IJJL9m4JcKI7rRyttc/rRsc7anclSM6MvgCLdw9f4AjOQvrKagYYygmuSDDv6OW8 /uCWpKd9Lk/PrBbgYjGI =WOiY -----END PGP SIGNATURE----- --uN3tURjgVTLfI0kr-- From owner-freebsd-stable@freebsd.org Sat Feb 20 02:57:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D34E2AADAA2 for ; Sat, 20 Feb 2016 02:57:03 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 960071894; Sat, 20 Feb 2016 02:57:03 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: by mail-yw0-x22e.google.com with SMTP id h129so81971668ywb.1; Fri, 19 Feb 2016 18:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HwHObwHEVjRm1QqHVdpXNuFTiXythLNEQI9n8iD1Z+I=; b=sPwyjre/aa5nE26AXEYBrRaSXegNNiU9cds9JRauJBcyzbQEc7itfhTSWIJqZNPEY8 gy2N7mDhg8PUQ/dSnQTXac2/MIEjNlqGtrD6BJFf2BZE1r+4Dbw0BcZ3Tm3NCrBp3jH6 m1s+pSzg3l+o5DcOh60+IvnuVasqohaWPnzzPoewGweJGGTOu7eAtjiIas/Rt1C6Aj44 yJKnvfWfgxgXxhKo2gt8qtEBIpMMeU+EipSaWHvQ2+mXasS4XElzA5WWK2kKn2kT4dfn bpDy/sfZUZJInWHvbzlOGJWvd/L8B56YVPLrmRJtaz0nFrj5zUFhUNwvyHGY2cgtpM0L 5+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=HwHObwHEVjRm1QqHVdpXNuFTiXythLNEQI9n8iD1Z+I=; b=NnHviavT89RceXMScO793sw9Wo1r5XBRYllrhyDGf1hJ0LjUPRZU8E80X0IvmxrWXa 37NQYq96FRqABozejZypqVuw5KcXlg2dgkde6AUl8aMTXoq2bGKsoRuzPXX7GDOREuTq il5W3BxSTcJmdf9UE8h/Ht2V6HLx7AYOTRtFUyMNz+MGbFD+q1juWJ1KI9qk4bwocziq PPTMjeGmiOEjN+SxuYFEWBr9TrsMnkUKqoXjeM44PdSFsazIbq6LF3zMtch2ntxBuZc5 W8FjL/BU9Z31T23mGNUVnlY7TKfrRfGireCqReCRggFN/MaYTwVpe/jtcysfoofT+wBp dhhg== X-Gm-Message-State: AG10YOTudbdXZFdpDKcSTSLkASr4YHx+AZqNugblXS2CP3aajQrP0zjXoNUBGn72Sd3UjBfiIDMW99ha6VVW/Q== MIME-Version: 1.0 X-Received: by 10.13.208.2 with SMTP id s2mr222429ywd.86.1455937022845; Fri, 19 Feb 2016 18:57:02 -0800 (PST) Received: by 10.37.207.206 with HTTP; Fri, 19 Feb 2016 18:57:02 -0800 (PST) Date: Fri, 19 Feb 2016 21:57:02 -0500 Message-ID: Subject: Outstanding bugs in 10.3-BETA2 From: David Cross To: freebsd-stable@freebsd.org, re@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 02:57:03 -0000 Could we get re's comments on: kern/207069, kern/207070, kern/189219, and kern/206231 207069 is the major one for me, it means everytime I installworld I need to remember to re-edit loader.rc or my system will not boot; this is a major regression; this IS going to bite people in an existing installed base. 189219 has been hanging out forever, is a crasher but requires root level permissions, and affects a tier 2? platform 206231 also has been hanging out for awhile and just needs someone to bring it in. 207070 is just a nuisance, but the fix is trivial (patch included), and its the right thing(tm) From owner-freebsd-stable@freebsd.org Sat Feb 20 05:55:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 448F1AAE214 for ; Sat, 20 Feb 2016 05:55:54 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id ACD4A12AD; Sat, 20 Feb 2016 05:55:53 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-70-178.lns20.adl6.internode.on.net (HELO leader.local) ([121.45.70.178]) by ipmail06.adl2.internode.on.net with ESMTP; 20 Feb 2016 16:25:45 +1030 Subject: Re: 10-STABLE hangups frequently To: Marius Strobl References: <20160202200738.GA78969@server.rulingia.com> <56B761A4.7010901@restart.be> <56BD9FBA.3040002@lidstrom.eu> <20160218002403.GA95789@alchemy.franken.de> <56C6A2BD.3090808@ShaneWare.Biz> Cc: freebsd-stable@freebsd.org From: Shane Ambler Message-ID: <56C7FFDE.4050906@ShaneWare.Biz> Date: Sat, 20 Feb 2016 16:25:42 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56C6A2BD.3090808@ShaneWare.Biz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 05:55:54 -0000 On 19/02/2016 15:36, Shane Ambler wrote: > On 18/02/2016 10:54, Marius Strobl wrote: >> >> Could those of you experiencing these hangs with ZFS please test >> whether instead of reverting all of r292895, a kernel built with >> just the merge of r291244 undone via the following patch gets >> rid of that problem - especially on amd64 - and report back? >> https://people.freebsd.org/~marius/r291244_reversal_10.diff >> >> Marius >> > > I have built 10-STABLE - r295756 with the patch applied. > > corei7 - 8GB - 3 disks in raidz > > The first 11 hours look promising. Now been running for 36 hours. This is my desktop machine and after a full day on it I am confident that this fixes the issue I have had. -- FreeBSD - the place to B...Storing Data Shane Ambler From owner-freebsd-stable@freebsd.org Sat Feb 20 19:24:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5599DAADCEB for ; Sat, 20 Feb 2016 19:24:01 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from server.glaver.org (server.glaver.org [204.141.35.63]) (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 338638D2 for ; Sat, 20 Feb 2016 19:24:00 +0000 (UTC) (envelope-from TERRY@glaver.org) Received: from glaver.org by glaver.org (PMDF V6.6 #37010) id <01PWWN3Q65R40002VH@glaver.org> for freebsd-stable@freebsd.org; Sat, 20 Feb 2016 14:23:51 -0500 (EST) Date: Sat, 20 Feb 2016 14:22:58 -0500 (EST) From: Terry Kennedy Subject: Re: 10.3-BETA2 regression in MPT In-reply-to: "Your message dated Fri, 19 Feb 2016 10:39:55 -0500" To: Mark Saad Cc: Terry Kennedy , FreeBSD-Stable ML Message-id: <01PWWSOPTVUS0002VH@glaver.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8 References: <01PWUKZNJW2C0002VH@glaver.org> <01PWV4YM2HKS00009M@glaver.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 19:24:01 -0000 > Can you build 10-STABLE and merge back the mpt driver prior to r285840 . It > looks like a change was merged in about 7 weeks ago that > has to do with probing the devices. > > https://svnweb.freebsd.org/base/stable/10/sys/dev/mpt/mpt.c?view=log Same behavior with or without that change reverted. Terry Kennedy http://www.glaver.org New York, NY USA