From owner-freebsd-hackers@freebsd.org Sun Jul 16 07:49:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E9C4BF88B4 for ; Sun, 16 Jul 2017 07:49:04 +0000 (UTC) (envelope-from nbari@codigo.io) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8897709F0 for ; Sun, 16 Jul 2017 07:49:03 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wm0-x234.google.com with SMTP id w126so51576963wme.0 for ; Sun, 16 Jul 2017 00:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=wF86MaMEeBuL40OAj/ZUBn4bM9D1TiVwFYCshK9/7Fk=; b=bbYp7uUITD/NzDkHZNgvA60CrnKg6sNHK7JLHN/8rQtwqymmKsidEphsQP6GYo67AC QFUGr3/uw9wrpV/yK8PG3CudjUYJA0BZaqTW0W5P7ZTXf7ExKdchULQyQfenwznTERF3 8SNuQpxmS63fkZvzVozBFRpdZFqOuDG+kodArtipEOYh12xGxeP8Z79w9TTBSK/Dv1ZU eKp5/b6E8zSuvjSG/vGQpeiDO54Wyyr+gPy8FlsEDwaAlkYc+GFPm0Ji78ajjrukzJxc Z7KIxnXZerMGaqEhInMOsd2scv9eo+D/8qeqKgjrIpiU9J9WYn/Og/eydCnHuDFJsKRk zuHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=wF86MaMEeBuL40OAj/ZUBn4bM9D1TiVwFYCshK9/7Fk=; b=JXlHL6KImglcM7SPMcFEev6WPKpYH+j46PlHBbqkfzKYm2GiwNB2FCIu0GSy0xg+2P /pjqOeGdc6XzBCxypr6v+DVQJat8EwYT8mQ7KA7YDp4M/UCMsUTbbfe+QMmGq2CvmrOZ 8+lLpn/xa3KdALLEkN9z+9nD+znOTIl+G6smIx9FLsajP5Veyk4IriBVvtZzJWvCJTd2 D0TzdqyhzFPjMCPvSXNVAUnPl84jZf1m/Mf2YVheRfOHK+v1Jblu898AXHu62UDn0fLe vAbC/+EZRriFGp8Y42e9bLKjwppOuflo5PSCsBtNVidB4aqTywUJa3JrzsQ7Wv/yecwq poZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=wF86MaMEeBuL40OAj/ZUBn4bM9D1TiVwFYCshK9/7Fk=; b=RcxgdBFhcXCbFBVg/30PMnAVHJZityZPkvhA4s4/9JX5SAQMdSrOBCEpMXQ7OEwIKq IqBtXkW+tVPMLcLUCb+x/KyCfEmxbWnOlGr/l8KVujyv9DeknraZn8Y8sl/QV2eKvSRU pJefl7ya/edZ05rafUm0yQ1V0UgsUSg59Ltp2zCY+poXUYaqJxgeDXXZqa5Ae+wMQ37Z iEpzEgCMEic5/b6ayrIw6kluuVaUiZJ4nUO5/E0CAXBrnFgDYDuxMuY2lPNr/ZYNVu1F +FJSYXJAeOYEYPo+Ks2Z8WrvsEwjxQqnLCYXPEeRR2Yxy8L8gw63FSrNpqQ+gnjX3mBX NkQA== X-Gm-Message-State: AIVw1109OQU2lqH0Y8576hiOjOt0MspmtM0T0hgj9+M3tv9+FiuAJh4p 4p7CJmKNWCvR+tjeUnU+reFWS9S2S9xvalsD6Q== X-Received: by 10.28.230.8 with SMTP id d8mr781356wmh.47.1500191341017; Sun, 16 Jul 2017 00:49:01 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.146.162 with HTTP; Sun, 16 Jul 2017 00:49:00 -0700 (PDT) X-Originating-IP: [91.64.160.139] In-Reply-To: References: From: Nicolas Embriz Date: Sun, 16 Jul 2017 09:49:00 +0200 X-Google-Sender-Auth: bgnJtSC0kuQyOuBSAaKbFmEDx2g Message-ID: Subject: Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores To: Warner Losh Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 07:49:04 -0000 Hi, I am trying this in Amazon AWS, the problem is that I can=E2=80=99t do a dm= esg or get more logs because when choosing a t2.medium or any instance with more than 2 cores, the image gets stuck on the boot process and therefore I can=E2=80=99t login. I have a working image with FreeBSD 11.0-stable: https://github.com/fabrik-red/images/releases/download/11.0/disk.tar.gz Using this kernel: https://github.com/fabrik-red/images/blob/11.0/fabrik.kernel and made using this script: https://github.com/fabrik-red/images/blob/11.0/fabrik.sh I know is probably not useful this info but so far the only difference is that I updated the sources and now while doing the same thing with FreeBSD 11.1-prelrelease I am getting this strange behaviour. When using only one single cpu core the image works but when using more thant 2 cores the image just don=E2=80=99t boot. Any ideas of what else I may add so that I could get more info at least on the boot screen that is the only thing I get from AWS while booting? Thanks in advance. Regards. From owner-freebsd-hackers@freebsd.org Sun Jul 16 08:59:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDBE4BFA42D for ; Sun, 16 Jul 2017 08:59:41 +0000 (UTC) (envelope-from nbari@codigo.io) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 72B5F72A2D for ; Sun, 16 Jul 2017 08:59:41 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wm0-x22a.google.com with SMTP id 62so52306626wmw.1 for ; Sun, 16 Jul 2017 01:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ilgNcMzLD6ce3a7cHo3HoJ9Jdkjr2ccwcMQ/AUmwSwM=; b=XwNwSJM7KlxfXf2uzS2nNDItUcExDlvSgO0L8JpWT/8SWowce6Nez9qyQVUpLUGUeY PT7qEIY6UhUw/2n0H7NqHGXps3oQ6y8faP8LAKzUZzv0yPnQVsx9HV48oB8DfgPqK2rL cDsTCtg3qbJEZVcdVIXtYjPN9rwS6P8RiahIS03RuSSxjAeY/tJgll3/9DLr3HTm1qGD /BJBO1Xd0t/RT3XsSyM7Pm15PYDvw1bLx3gATo1HNRZWEuhcOyEvt5MMPvPzJyKEfKIw mXFLCYi5Q99Netw9h8IdWIYkS/Wtq0ix7q4P5jvSrIApmG8MsCvIdGVahwR5zTze+MZ8 z2aQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ilgNcMzLD6ce3a7cHo3HoJ9Jdkjr2ccwcMQ/AUmwSwM=; b=MRJ2Ag2whrdUduJ+eKra+MGIm0v12SYfR/mvskFfhXVLK9c9HcVVo7mygWXgQSBGwX FI2FyluRXvTIS7NIxvCnWyZlDPYEPTqVXE1VESQazMk8ezomeVD2ghR90Cqow0ETr8pu DdusJGUrA49InUCw7qkvphAMLnP0vG1Qi1UgEPijlaWbQDqGVakNj+gUXZwktkMaXVLQ hBsx7B32zWrnOc0J9gItGi/9jX92JPKSQmFXhwrHN5/AekyDblumik4VDig/Wcn/s7/Y K1EiJNv/Da3uZqX9LQIFkWx6w16pQqmR6tP6fgsdDSa1pL4wgXTHELPt2wZXZtJTMjqk JeEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ilgNcMzLD6ce3a7cHo3HoJ9Jdkjr2ccwcMQ/AUmwSwM=; b=YtqlO3WK0tBu0gbycw56Dl8iB/aIJSgNmMGMonvIca/PvecmF5u38rBpelagGYHBan 5PMZmowh41nfbpeOCxfo4FP+wC4rsTAoMPSLRS6nPXyQG+bJnKzsLy5dYuryguW0R9eH Qwa1D5YLKmt/9tedYmlEE9NBM7+D43evsLMfqAyKZETed8t50aSIGuK186Q+m0E/GU7W 5qqGyVpvqcZZOVqVd0QeU3N2nE/m8RXhuNzIc9v++CqPuKDWhAf5ile5sIF/FYP/sqgo Gd1DUAsKZy3VqKGPPPRMLbGq8MW/ria/GcRl14MSe0KbOD2tbSMBkEReS4T72p7cPwlz YZgw== X-Gm-Message-State: AIVw111BTpR6tEjTm4sqJzZKXDpYhc2UNI+UhLK5K/SH4DJe+fU26/lT J8OqjUGLRAEqWNDJVCURrjXMwyU6NGrghFxsYg== X-Received: by 10.28.113.21 with SMTP id m21mr886559wmc.80.1500195578926; Sun, 16 Jul 2017 01:59:38 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.146.162 with HTTP; Sun, 16 Jul 2017 01:59:38 -0700 (PDT) X-Originating-IP: [91.64.160.139] In-Reply-To: References: From: Nicolas Embriz Date: Sun, 16 Jul 2017 10:59:38 +0200 X-Google-Sender-Auth: gtbANgTjR3_LeWWhS9q5hx5wcEw Message-ID: Subject: Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores To: Warner Losh Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:59:41 -0000 Hi, this is the only output I have from AWS (system log), important to mention that this only happens when using more than 2 cores (t2.medium) for example, when using 1 core it works. Output: / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ /boot/kernel/kernel text=3D0x6876= f0 | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / data=3D0x76348+0x37d168= - \ | syms=3D[0x8+0xa1e38/ - +0x8+0x9d58c\ | / ] - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ /boot/kernel/zfs.ko | / - \ | / - \ | / size 0x2e8938 at 0xfba000 loading required module 'opensolaris' - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / /boot/kernel/opensolaris.ko size 0xaab0 at 0x12a3000 Booting [/boot/kernel/kernel]... - \ | / - \ | / - \ | / - \ Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.1-PRERELEASE #0 r321034: Sat Jul 15 20:44:15 UTC 2017 devops@fabrik-de1.127.network:/fabrik/aws/host/obj/usr/src/sys/FABRIKAW= S amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT: init without driver. XEN: Hypervisor version 4.2 detected. CPU: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (2400.05-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306f2 Family=3D0x6 Model=3D0x3f Steppi= ng=3D2 Features=3D0x1783fbff Features2=3D0xfffa3203 AMD Features=3D0x28100800 AMD Features2=3D0x21 Structured Extended Features=3D0x728 XSAVE Features=3D0x1 Hypervisor: Origin =3D "XenVMMXenVMM" real memory =3D 4294967296 (4096 MB) avail memory =3D 4128489472 (3937 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard random: entropy device external interface random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 aesni0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) cpu0: on acpi0 cpu1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 62500000 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc100-0xc10f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 vgapci0: Boot video device xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) xenpv0: on motherboard granttable0: on xenpv0 xen_et0: on xenpv0 Event timer "XENTIMER" frequency 1000000000 Hz quality 950 Timecounter "XENTIMER" frequency 1000000000 Hz quality 950 xenstore0: on xenpv0 evtchn0: on xenpv0 privcmd0: on xenpv0 debug0: on xenpv0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec nvme cam probe device init xenballoon0: on xenstore0 xctrl0: on xenstore0 xs_dev0: on xenstore0 xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 0a:9a:53:0d:ff:6b xenbusb_back0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 18432MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 SMP: AP CPU #1 Launched! Trying to mount root from zfs:zroot/ROOT/default []... GEOM: ada0: the secondary GPT header is not in the last LBA. On Sun, Jul 16, 2017 at 9:49 AM, Nicolas Embriz wrote: > Hi, > > I am trying this in Amazon AWS, the problem is that I can=E2=80=99t do a = dmesg > or get more logs because when choosing a t2.medium or any instance > with more than 2 cores, the image gets stuck on the boot process and > therefore I can=E2=80=99t login. > > I have a working image with FreeBSD 11.0-stable: > https://github.com/fabrik-red/images/releases/download/11.0/disk.tar.gz > > Using this kernel: > https://github.com/fabrik-red/images/blob/11.0/fabrik.kernel and made > using this script: > https://github.com/fabrik-red/images/blob/11.0/fabrik.sh > > I know is probably not useful this info but so far the only difference > is that I updated the sources and now while doing the same thing with > FreeBSD 11.1-prelrelease I am getting this strange behaviour. > > When using only one single cpu core the image works but when using > more thant 2 cores the image just don=E2=80=99t boot. > > Any ideas of what else I may add so that I could get more info at > least on the boot screen that is the only thing I get from AWS while > booting? > > Thanks in advance. > > Regards. > From owner-freebsd-hackers@freebsd.org Sun Jul 16 10:16:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D23ADBFBD47 for ; Sun, 16 Jul 2017 10:16:17 +0000 (UTC) (envelope-from nbari@codigo.io) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 661AE74C14 for ; Sun, 16 Jul 2017 10:16:17 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wm0-x234.google.com with SMTP id w126so53112095wme.0 for ; Sun, 16 Jul 2017 03:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lwdGg6nyCMOYm2AaTvUTpC59NVKJZI4jGwDvIdSSIQM=; b=fyLHmpY7XR6gvddRezV8Y/d7zXQu2AwLy1Js9AewL0+XWBeHxHz402HO+DM57U8GHH Bdr4b818hWbiRmNi0qzZkXcw2riha+by8VmGIQUKUGXnT45O3Ay60R7OMsCgtI1TO3+q PlUsQtT/JcME8dD02eBbsg+XwEIKl8Ply1gPgVfu17tjq+zrqsGqTGHkIKh0Y/YhMvTE QIkb5zVPx6adfwd981SsBC6tdQkULyhR8v+sc5kyII9lc43o/y0fbBpmOnmroYVlS0tN tcKBsKEdG4OgxPR8tYdP+NAlvUMyHj29aNVv7eIGCFQh2TlhM8kxITgN4GtxwLdTyUdL Y/4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lwdGg6nyCMOYm2AaTvUTpC59NVKJZI4jGwDvIdSSIQM=; b=EvsGYg+6LcTp2Ip88KQdunWVn7UbNTggXVANdnlp4ctY4bZLkys8ipu7LnezmYcJ6g 88HbZY0Tf0Hy5vbvGzeP99AZjIatpuVZ/ASUoGW5zf7f4X5vKhPR54PtRTJqXU6AVHXs Oayh2rRQhTk0pWp6TENrFfGBuW0a+On5Ip+WPZ/us9nm+ImPnl4Ifz02AmW+39i4C7e8 ruYHqiFtHe51Giu/4Fl9K0EQ40JhkzDGI3yFkn+GbGv924T5u7r1EJ0cFdw2kykck/NX 6JTOTKvfLF17ZLkXLNwbsnVb3v5UltcJ+fl/0Tjaw0+8idk6SViUtvgU51W2o3qtWWOT oAWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lwdGg6nyCMOYm2AaTvUTpC59NVKJZI4jGwDvIdSSIQM=; b=iNWShaSYYI9m0bfb6G+yAwVO4Y89NFfJqjIPDrsSz6Wa7lCL6Q21+zzvBVYdaXewjg FNROaRmvDnYgxq73XHoSVy5/5fmeDM3bBWmUOUPFRG6bSK2nshuJwqI/QA4HmEt9wNwR Oshquyq5ib9nCTtg2DAcEXAASfBLHAq/4jaqP1wfFkLfsGKeuhIwuTEsAyhvAZetAUeX sZFwHac0HWZhltaRBd7PppmsK4tbdk4oq3dihbeqNfdY1euLYi6Amu5v8DQ8Grtc+etb yRKFe5d4kceP3i+OfQvEWhp9UuqaFI8APen8IsSPT6QwhHuYVka2sG7MebJjb8xZLAVa 5iYw== X-Gm-Message-State: AIVw1103YvGv+lXMZQP3HMQk+A3c4RXBQWunBOuI3WMsvrUlwPlOhzor qoOlwKGXreCoRvVwuNO+JPAsdiM6c/xgNBWpXA== X-Received: by 10.28.170.8 with SMTP id t8mr980897wme.111.1500200175423; Sun, 16 Jul 2017 03:16:15 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.146.162 with HTTP; Sun, 16 Jul 2017 03:16:14 -0700 (PDT) X-Originating-IP: [46.189.27.100] In-Reply-To: References: From: Nicolas Embriz Date: Sun, 16 Jul 2017 12:16:14 +0200 X-Google-Sender-Auth: pL-eNcr9KQH-IchrxCaz_A861hQ Message-ID: Subject: Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores To: Warner Losh Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:16:17 -0000 I change the zone on AWS (eu-central-1a) and got the same behaviour, instantes with 1 core work but with 2 cores they panic, I was available to get more details, in this time I was using UFS instead of ZFS on root: Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTA= CH,CACHED Feeding entropy: . spin lock 0xffffffff80db45c0 (smp rendezvous) held by 0xfffff80004378560 (tid 100074) too long timeout stopping cpus panic: spin lock held too long cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff804f69a7 at kdb_backtrace+0x67 #1 0xffffffff804b9666 at vpanic+0x186 #2 0xffffffff804b94d3 at panic+0x43 #3 0xffffffff8049da60 at __mtx_trylock_spin_flags+0 #4 0xffffffff807bd2d6 at smp_targeted_tlb_shootdown+0xd6 #5 0xffffffff807bd62c at smp_masked_invlpg+0x4c #6 0xffffffff807558b2 at pmap_invalidate_page+0x142 #7 0xffffffff8075f2a9 at pmap_ts_referenced+0x709 #8 0xffffffff8073ac9c at vm_pageout+0xcbc #9 0xffffffff80482345 at fork_exit+0x75 #10 0xffffffff8074b4be at fork_trampoline+0xe Uptime: 1m0s Rebooting... cpu_reset: Stopping other CPUs timeout stopping cpus cpu_reset: Restarting BSP cpu_reset: Failed to restart BSP Full output: - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / /boot/kernel/kernel text=3D0x6876f0 - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ data=3D0x76348+0x37d168 | / - \ syms=3D[0x8+0xa1e38| / - \ | +0x8+0x9d58c/ - \ | / ] - \ | / - \ | / - \ | Booting [/boot/kernel/kernel]... / - \ | / Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.1-PRERELEASE #0 r321036: Sat Jul 15 21:52:50 UTC 2017 devops@fabrik-de1.127.network:/fabrik/aws-nozfs/host/obj/usr/src/sys/FA= BRIKAWS amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT: init without driver. XEN: Hypervisor version 4.2 detected. CPU: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (2394.50-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306f2 Family=3D0x6 Model=3D0x3f Steppi= ng=3D2 Features=3D0x1783fbff Features2=3D0xfffa3203 AMD Features=3D0x28100800 AMD Features2=3D0x21 Structured Extended Features=3D0x728 XSAVE Features=3D0x1 Hypervisor: Origin =3D "XenVMMXenVMM" real memory =3D 4294967296 (4096 MB) avail memory =3D 4131692544 (3940 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard random: entropy device external interface random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 aesni0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) cpu0: on acpi0 cpu1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 62500000 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc100-0xc10f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 vgapci0: Boot video device xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) xenpv0: on motherboard granttable0: on xenpv0 xen_et0: on xenpv0 Event timer "XENTIMER" frequency 1000000000 Hz quality 950 Timecounter "XENTIMER" frequency 1000000000 Hz quality 950 xenstore0: on xenpv0 evtchn0: on xenpv0 privcmd0: on xenpv0 debug0: on xenpv0 Timecounters tick every 1.000 msec nvme cam probe device init xenballoon0: on xenstore0 xctrl0: on xenstore0 xs_dev0: on xenstore0 xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 02:0e:56:1c:1c:d3 xenbusb_back0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 8192MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/gpt/rootfs [rw]... GEOM: ada0: the secondary GPT header is not in the last LBA. Growing root partition to fill device ada0 recovered ada0p3 resized super-block backups (for fsck_ffs -b #) at: 2097600, 2621952, 3146304, 3670656, 4195008, 4719360, 5243712, 5768064, 6292416, 6816768, 7341120, 7865472, 8389824, 8914176, 9438528, 9962880, 10487232, 11011584, 11535936, 12060288, 12584640, 13108992, 13633344, 1415= 7696 Setting hostuuid: ec259844-260d-90a9-bfa5-5157bc239b6b. Setting hostid: 0x52ee9fe5. Starting file system checks: /dev/gpt/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/gpt/rootfs: clean, 1648359 free (39 frags, 206040 blocks, 0.0% fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib random: unblocking device. 32-bit compatibility ldconfig path: Setting hostname: fabrik. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTA= CH,CACHED Feeding entropy: . spin lock 0xffffffff80db45c0 (smp rendezvous) held by 0xfffff80004378560 (tid 100074) too long timeout stopping cpus panic: spin lock held too long cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff804f69a7 at kdb_backtrace+0x67 #1 0xffffffff804b9666 at vpanic+0x186 #2 0xffffffff804b94d3 at panic+0x43 #3 0xffffffff8049da60 at __mtx_trylock_spin_flags+0 #4 0xffffffff807bd2d6 at smp_targeted_tlb_shootdown+0xd6 #5 0xffffffff807bd62c at smp_masked_invlpg+0x4c #6 0xffffffff807558b2 at pmap_invalidate_page+0x142 #7 0xffffffff8075f2a9 at pmap_ts_referenced+0x709 #8 0xffffffff8073ac9c at vm_pageout+0xcbc #9 0xffffffff80482345 at fork_exit+0x75 #10 0xffffffff8074b4be at fork_trampoline+0xe Uptime: 1m0s Rebooting... cpu_reset: Stopping other CPUs timeout stopping cpus cpu_reset: Restarting BSP cpu_reset: Failed to restart BSP On Sun, Jul 16, 2017 at 10:59 AM, Nicolas Embriz wrote: > > Hi, this is the only output I have from AWS (system log), important to mention that this only happens when using more than 2 cores (t2.medium) for example, when using 1 core it works. > > Output: > > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ /boot/kernel/kernel text=3D0x6876f0 | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / data=3D0x76348+0x37d168 - \ | syms=3D[0x8+0xa1e38/ - +0x8+0x9d58c\ | / ] > - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ /boot/kernel/zfs.ko | / - \ | / - \ | / size 0x2e8938 at 0xfba000 > loading required module 'opensolaris' > - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / /boot/kernel/opensolaris.ko size 0xaab0 at 0x12a3000 > > > Booting [/boot/kernel/kernel]... > - \ | / - \ | / - \ | / - \ Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.1-PRERELEASE #0 r321034: Sat Jul 15 20:44:15 UTC 2017 > devops@fabrik-de1.127.network:/fabrik/aws/host/obj/usr/src/sys/FABRIK= AWS amd64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) > VT: init without driver. > XEN: Hypervisor version 4.2 detected. > CPU: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (2400.05-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x306f2 Family=3D0x6 Model=3D0x3f Step= ping=3D2 > Features=3D0x1783fbff > Features2=3D0xfffa3203 > AMD Features=3D0x28100800 > AMD Features2=3D0x21 > Structured Extended Features=3D0x728 > XSAVE Features=3D0x1 > Hypervisor: Origin =3D "XenVMMXenVMM" > real memory =3D 4294967296 (4096 MB) > avail memory =3D 4128489472 (3937 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > ioapic0: Changing APIC ID to 1 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-47 on motherboard > random: entropy device external interface > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > nexus0 > aesni0: on motherboard > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 62500000 Hz quality 950 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc100-0xc10f at device 1.1 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 1.3 (no driver attached) > vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 > vgapci0: Boot video device > xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: console (9600,n,8,1) > xenpv0: on motherboard > granttable0: on xenpv0 > xen_et0: on xenpv0 > Event timer "XENTIMER" frequency 1000000000 Hz quality 950 > Timecounter "XENTIMER" frequency 1000000000 Hz quality 950 > xenstore0: on xenpv0 > evtchn0: on xenpv0 > privcmd0: on xenpv0 > debug0: on xenpv0 > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.conf. > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > nvme cam probe device init > xenballoon0: on xenstore0 > xctrl0: on xenstore0 > xs_dev0: on xenstore0 > xenbusb_front0: on xenstore0 > xn0: at device/vif/0 on xenbusb_front0 > xn0: Ethernet address: 0a:9a:53:0d:ff:6b > xenbusb_back0: on xenstore0 > xn0: backend features: feature-sg feature-gso-tcp4 > xbd0: 18432MB at device/vbd/768 on xenbusb_front0 > xbd0: attaching as ada0 > SMP: AP CPU #1 Launched! > Trying to mount root from zfs:zroot/ROOT/default []... > GEOM: ada0: the secondary GPT header is not in the last LBA. > > > > > On Sun, Jul 16, 2017 at 9:49 AM, Nicolas Embriz wrote: >> >> Hi, >> >> I am trying this in Amazon AWS, the problem is that I can=E2=80=99t do a= dmesg >> or get more logs because when choosing a t2.medium or any instance >> with more than 2 cores, the image gets stuck on the boot process and >> therefore I can=E2=80=99t login. >> >> I have a working image with FreeBSD 11.0-stable: >> https://github.com/fabrik-red/images/releases/download/11.0/disk.tar.gz >> >> Using this kernel: >> https://github.com/fabrik-red/images/blob/11.0/fabrik.kernel and made >> using this script: >> https://github.com/fabrik-red/images/blob/11.0/fabrik.sh >> >> I know is probably not useful this info but so far the only difference >> is that I updated the sources and now while doing the same thing with >> FreeBSD 11.1-prelrelease I am getting this strange behaviour. >> >> When using only one single cpu core the image works but when using >> more thant 2 cores the image just don=E2=80=99t boot. >> >> Any ideas of what else I may add so that I could get more info at >> least on the boot screen that is the only thing I get from AWS while >> booting? >> >> Thanks in advance. >> >> Regards. > > From owner-freebsd-hackers@freebsd.org Sun Jul 16 20:44:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9F94C79791; Sun, 16 Jul 2017 20:44:13 +0000 (UTC) (envelope-from paggas1@yandex.com) Received: from forward19p.cmail.yandex.net (forward19p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 782626602A; Sun, 16 Jul 2017 20:44:13 +0000 (UTC) (envelope-from paggas1@yandex.com) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::28]) by forward19p.cmail.yandex.net (Yandex) with ESMTP id 93E34214F2; Sun, 16 Jul 2017 23:44:09 +0300 (MSK) Received: from smtp4o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp4o.mail.yandex.net (Yandex) with ESMTP id E14EF6C01102; Sun, 16 Jul 2017 23:44:07 +0300 (MSK) Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id nXe8AUYaT0-i7f0BN88; Sun, 16 Jul 2017 23:44:07 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1500237847; bh=Km3dMH/w/DYrxjQz/ot4T6Ql3JyTlIC8Ch/yLBr5iW8=; h=To:From:Subject:Message-ID:Date; b=HcE/OenXbp2DhALc++rUbhO3D4g/ewxT9SvO2TW8rXYz9HgjzCUhyxYLU75DrwUTA qx/qDDxFpUBd9e8n+0rvwgcq6oUtHh0xB3evAhQTVMn4NE8lG5wbzdX2oQ+HWGUJBL MuGPzTSvjtwhoCPtedWJLW93KeJextSU8Gt3b0BU= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.com X-Yandex-Suid-Status: 1 1022867361,1 0,1 0 To: FreeBSD Current , "freebsd-hackers@freebsd.org" From: Panagiotes Mousikides Subject: Attn: CI/Jenkins people; Run bhyve instance for testing pf Message-ID: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> Date: Sun, 16 Jul 2017 20:44:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 20:44:13 -0000 Hello everybody! I am working on adding tests to the FreeBSD test suite for testing pf, the network packet filter. These tests need at least two machines running and connected to each other, with one machine generating network traffic and the other running pf and filtering the traffic. I am looking for a way to fire off a bhyve instance to serve as the second machine, the first being the actual machine I am running the tests on. This should be done completely automatically, with scripts to configure all network interfaces and to preferably also set up an SSH server on the bhyve instance. This bhyve instance could start off as running the latest stable version of FreeBSD, or it could be configured to run a snapshot of the development tree. The aim is to have the desired version of FreeBSD that we want to test running on it. Ideally this would be done in such a way that we can reuse the machine for further tests, instead of rebuilding everything from scratch for each test. What I am looking for is the best way to do this, preferably so that it can be easily integrated into the CI work being done at Jenkins. What do you think? Any input is welcome! All the best, Panagiotes From owner-freebsd-hackers@freebsd.org Sun Jul 16 21:11:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F368C7A81B; Sun, 16 Jul 2017 21:11:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 5A7B967752; Sun, 16 Jul 2017 21:11:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x229.google.com with SMTP id l21so41043093ywb.1; Sun, 16 Jul 2017 14:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rW467UFheZzv3rA94JqxvNtt+Y5jCshdQYimeHa9uGs=; b=VADE4jpJy+Lnc5wKePp1PJgeKLVFDV6tdTxitO1AowhvOG6QuUayKQTOIBQpxNGANG Z9XSBJbkEw81CVuB49GaBZ7thtMHTAlAbWt3jqE0zzt/7OwuKewhUDKfylvRlPLWrm0e O9AejIHf6Oae9kSi0bGmtv6PjoRpFtcNTMEcwtWtml4KBZr/sQZ3pq1aJMGSdYhsUnsY UV35Rm3LPvbz290Ma9SdXbwhlaZHfSSZu+LZFyMIV9rrt9PLFMaVwbRK7XNNdg+/iKMa JklJeW4BesSQmA6AuNBPEAGBsbJi6RJr2yDHLM12nIfVjipR8VpO5Vdgmw3FiS7fpu7t 1FIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rW467UFheZzv3rA94JqxvNtt+Y5jCshdQYimeHa9uGs=; b=n6opFYrBQMVeV0262WhRlpn/4nfuUlGYBjg3FQdvhlxu5i5lhONbB25cuW/AqjEXU7 0+ba8k8FL+U/nV1yLW+MISYo4y2hki5z2r55tIyw1dKuPSGrq9gkQh5SUy0X91BPCFwJ 7tSmtQXjKEVlE/3nmWiM6mQ1Xugt0ipDQMXpB7S/vEWOVouzW6ZxvYJbnt4LfnlKZHGK z/iSsxXT5NrHQ7mV3+Socop4gQ7sSf3ZP4RaZLHpTmtr9IA2x+tl5QVtG4L5V9HBlB5C vbNjxkHztTPrC7Oo+qqjtuF4wcm95srXlrdGpKqpPVNxqx4xNdpTrrukgbRKITiBmfbN XYFw== X-Gm-Message-State: AIVw111zU2GKzf1vNlXVfyfdHj6jmku7MXfNN57F1Ei3KzUX5nwg9xFU 2F8p5aFnRcOBGpJfjWLUBNSuEtw1gw== X-Received: by 10.13.255.69 with SMTP id p66mr13794874ywf.233.1500239495482; Sun, 16 Jul 2017 14:11:35 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.13.243.135 with HTTP; Sun, 16 Jul 2017 14:11:34 -0700 (PDT) In-Reply-To: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> References: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> From: Alan Somers Date: Sun, 16 Jul 2017 15:11:34 -0600 X-Google-Sender-Auth: BGR4n-R1eTNU4byTJVhOwFksjXM Message-ID: Subject: Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf To: Panagiotes Mousikides Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 21:11:36 -0000 On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides wrote: > Hello everybody! > > I am working on adding tests to the FreeBSD test suite for testing pf, the > network packet filter. > > These tests need at least two machines running and connected to each other, > with one machine generating network traffic and the other running pf and > filtering the traffic. I am looking for a way to fire off a bhyve instance > to serve as the second machine, the first being the actual machine I am > running the tests on. This should be done completely automatically, with > scripts to configure all network interfaces and to preferably also set up an > SSH server on the bhyve instance. > > This bhyve instance could start off as running the latest stable version of > FreeBSD, or it could be configured to run a snapshot of the development > tree. The aim is to have the desired version of FreeBSD that we want to > test running on it. Ideally this would be done in such a way that we can > reuse the machine for further tests, instead of rebuilding everything from > scratch for each test. > > What I am looking for is the best way to do this, preferably so that it can > be easily integrated into the CI work being done at Jenkins. What do you > think? Any input is welcome! > > All the best, > Panagiotes It's possible to setup CI systems that involve multiple machines networked together. I've done it. But it's complicated, fragile, and slow. I advise you to consider very carefully whether you truly need multiple VMs. What about creating an epair(4)? You could run pf on epair0b and generate traffic from epair0a. That would be faster than spinning up VMs, and would be very easy to integrate into any other CI system. Would that work? -Alan From owner-freebsd-hackers@freebsd.org Mon Jul 17 09:11:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9080D14EDB for ; Mon, 17 Jul 2017 09:11:34 +0000 (UTC) (envelope-from netch@netch.kiev.ua) Received: from vpa.nn.kiev.ua (078.vps.ho.ua [91.228.147.78]) (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 A501E7D634 for ; Mon, 17 Jul 2017 09:11:33 +0000 (UTC) (envelope-from netch@netch.kiev.ua) Received: by vpa.nn.kiev.ua (Postfix, from userid 1000) id 607779443ACA; Mon, 17 Jul 2017 12:11:25 +0300 (EEST) Date: Mon, 17 Jul 2017 12:11:25 +0300 From: Valentin Nechayev To: Nicolas Embriz Cc: "freebsd-hackers@freebsd.org" Subject: Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores Message-ID: <20170717091125.GA8450@netch.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:11:35 -0000 hi, Sun, Jul 16, 2017 at 12:16:14, nbari wrote about "Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores": > Setting up harvesting: > [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > Feeding entropy: . > spin lock 0xffffffff80db45c0 (smp rendezvous) held by 0xfffff80004378560 Are you using a custom kernel? I had experienced panics just with random device on transition 10.2 -> 10.3 by source, and they were solved by temporary disabling of rdrand_rng, despite following reenabling of this device settled normal working. (Regrettably, I haven't got the panic details.) -netch- From owner-freebsd-hackers@freebsd.org Mon Jul 17 15:51:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 233BBD96896 for ; Mon, 17 Jul 2017 15:51:11 +0000 (UTC) (envelope-from nbari@codigo.io) 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 9C67F65375 for ; Mon, 17 Jul 2017 15:51:10 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wm0-x229.google.com with SMTP id w126so80179463wme.0 for ; Mon, 17 Jul 2017 08:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hLZrSBiIsjeB8fAB9+CiSg5S2158mNMgGd+n41CbCgE=; b=e1GOqqb9K1qMliO5ej5mfCywGwHl0dPN+Ak2HDQIMUNNtolDS2zzgPl8bpqQAj3Bce denjRZ8n8BCuDIm2t7mrCh3k1ZkIfpMnr3lOZdlut9lCPsfomFMyz2Ircz/QOdXkEsSN lAsCLN3DJyjEJUya5bNAB2M1HZusgxYf9D4tBNh03PrrrF2BO1Su7BSoT65PBFZ9d7qc yTVuGI49yJMsKNQZ260FVkzxuMPDV/qFQN7M3r8jeqbfP8XRuEiaAzO7AnNdIUoJ9JrY RpExv39HVouzwReiwSp5icQ5MSiLn7J3h/2kCjONrIF/1AW+4JIdpmUL8g0xal2TzJfJ ZD1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hLZrSBiIsjeB8fAB9+CiSg5S2158mNMgGd+n41CbCgE=; b=OT+/KLg9gAD6wJNd22HmaQ4BrvVN3OcpyBC3RhxXr9KR598xpcyl+OnAt9fQrblXA5 HEPA95gerNKlnfRQkplo2/n2AOQ+5bLfymnlfBJq1gQWlJdU2L2T1VWL7tcH6zUHj3Dg LQI2ZQgv0PY5tAZOnALphfQQynlYo2jA0uzfffFf52zSB4sYzbobB3s+sRsYg3KOsKIn GFY7LAnpZSAmAc9hub8/uIbfEY6IEZUZtHf+hfH5t6jb2DPcp0MpE6JnYGLRhWFdtw1c Jf3MGb0j9r3ODuqEetDLCkLjaO7gtzm+p8VbRN/eudntxccQzcWnkEQWhN0J7jY0Lzgd dy/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hLZrSBiIsjeB8fAB9+CiSg5S2158mNMgGd+n41CbCgE=; b=ZUTS7si9MwdUItsp4abVW1IosP2ns8e54Ffhsz21l6mK8sVB4/S1DvU22nqZ8kQtXk W3d7fXuwRIkRPborHNwkUqnDWJ1ziPZo7TKDcL/ANFcAO7vsa6mL714zeGn/BvhkHxTq pJ7GweaVYhQwOLnSjZ4j8qPKxQ1ZPV15/EfWmzIiy/VTcqNveplZ7ZD0LBbD7TssVwH6 gAOC5PhE0g0gmdpH0pe1EGUoeJ6CGaqan6Tn484CowAz1J5QHPJz2GKtzhRLqw1AMwVl OjlKYH2JW05COa2cwlsxnVY6xfQZA8il1sQPJoh+zR5spRwL6G/W28IEu+AqLK9qD5Ef VmJQ== X-Gm-Message-State: AIVw112I2LY62Bk0C8+AXGzWG6jluYszgTLCsKZfATpjsDGS8bHLj9zr V1k5BuIr9MeAwOCgQVgjWsg1fDE2cJ4MmQo0tA== X-Received: by 10.28.168.21 with SMTP id r21mr4631876wme.80.1500306668764; Mon, 17 Jul 2017 08:51:08 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.146.162 with HTTP; Mon, 17 Jul 2017 08:51:07 -0700 (PDT) X-Originating-IP: [46.189.27.100] In-Reply-To: <20170717091125.GA8450@netch.kiev.ua> References: <20170717091125.GA8450@netch.kiev.ua> From: Nicolas Embriz Date: Mon, 17 Jul 2017 17:51:07 +0200 X-Google-Sender-Auth: VEEIoLsvYqp7KFoNQfOM97-pjdA Message-ID: Subject: Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores To: Valentin Nechayev Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:51:11 -0000 Hi, I notice that in 11.1 there is this new option EARLY_AP_STARTUP, I add it to the kernel and testing also with a GENERIC and seems to be working (no panics when using more than 2 cores) But wondering what exactly =E2=80=9CEARLY_AP_STARTUP=E2=80=9D does and why = is that when using one single core kernel and not using this option the kernel doesn't panic but if using more than 2 cores it panics at boot time. Regards. On Mon, Jul 17, 2017 at 11:11 AM, Valentin Nechayev wrote: > > hi, > > Sun, Jul 16, 2017 at 12:16:14, nbari wrote about "Re: GEOM: ada0: the secondary GPT header is not in the last LBA or random: unblocking device. when using more than 2 cores": > > > Setting up harvesting: > > [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTA= CH,CACHED > > Feeding entropy: . > > spin lock 0xffffffff80db45c0 (smp rendezvous) held by 0xfffff8000437856= 0 > > Are you using a custom kernel? > I had experienced panics just with random device on transition > 10.2 -> 10.3 by source, and they were solved by temporary disabling of > rdrand_rng, despite following reenabling of this device settled normal > working. (Regrettably, I haven't got the panic details.) > > > -netch- From owner-freebsd-hackers@freebsd.org Mon Jul 17 20:42:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85975DA0292 for ; Mon, 17 Jul 2017 20:42:37 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 0F9EC70935 for ; Mon, 17 Jul 2017 20:42:37 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id p204so1057291wmg.1 for ; Mon, 17 Jul 2017 13:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=yUO7/haaukeHGcqXvz8M7fZY+fo5+VhICLekTabtBxQ=; b=NWcVCzLd2Br4PpdiSyjbgugifRLeitqW+IrCBb1ZppCAWTZDHsK0N+AVTwEvOS6Uaf hgV/c5qwzPnUE+71L8NVVhAY4xSz+PXUaRSIvOO3xtgYoZIuberBawosIJ4s3Iy1QJug SAPqCBaTd3TV94BZRDBTY8CoVqp5gtKqqEXuGX9pikLNy0xmhFTLGA/k29nu2167uixs 5PMUmQKQNY4q5qmHCGh1pGiw2qxZQ2HCoLBrRASRrl32i6g6EakgGvWjHpcxd/RUEUoH VVc8ctzWJNMpRJfYlTlyVnwbBGJ2qvumzEDF7JllnvAJmCXxVkhsBuPRiYPhL/4o2D2c 6L7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=yUO7/haaukeHGcqXvz8M7fZY+fo5+VhICLekTabtBxQ=; b=Oar4vjls9RtV9F6WARKBY8fNfP+ZQfeSbWdchWxQE8iqaFUy4fMX2VWQ59/VPJjx4e mMbsYpHULp39LGUKMBHmLLI+dAontsLIwRSqrdi97u3N7sEHA2cE13keN6l8taWWuQs8 pYorK9BbCaGZFQUf5+NGvxRDXHwJ06Os4RMPcvrN/9x8xApF1i2eL1JRDVjlyudRFFhL gpfXiq/tpMgGeGRYs4t1OMnWPpjwIIEIc9xsagyajGMKUP4Aa+QtK46D90JfCzVIPfzR 5Rz7Ss8PLoiQt4FpFzRx8EkU3Ip34eliskhMJlqETKbXInBp3pCpt+qV+zKmURtjkeiw WCMg== X-Gm-Message-State: AIVw111FPpB+POAqAHOSUqHQwA97QlHKasBRDW7gT97N1vJsK9I4xJqu M7RpdCk5GPpSMW47Crk= X-Received: by 10.28.156.20 with SMTP id f20mr5356407wme.17.1500324154959; Mon, 17 Jul 2017 13:42:34 -0700 (PDT) Received: from mb.tns.cz ([92.43.24.116]) by smtp.gmail.com with ESMTPSA id 143sm15767202wmg.9.2017.07.17.13.42.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 13:42:34 -0700 (PDT) Sender: Martin Beran To: freebsd-hackers@freebsd.org From: Martin Beran Subject: mac_sofi: a proof of concept MAC module Message-ID: Date: Mon, 17 Jul 2017 22:42:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:42:37 -0000 Hello, I created an initial proof-of-concept implementation of a new Mandatory Access Control kernel module. It is called SOFI (Subjects and Objects with Floating Integrity). Source code is at https://github.com/martin-beran/mac_sofi. It is written and tested on FreeBSD 10.3, but it should be usable on newer releases too. The SOFI security model combines access control by ACLs and capabilities with automatic modification of process and data integrity according to data flow. Each subject (usually a process that executes an operation, for example, a system call) and object (a target of the operation, for example, a file being accessed) has its integrity value, which is a set of atomic integrity attributes. A subject or an object can be either a reader or a writer for a particular operation, depending on the direction of information flow between them. First, the subject's integrity is compared to the object's ACL in order to decide whether the operation should be allowed or denied. If allowed, the reader's integrity (subject in read, object in write) is modified to the lower bound (intersection) of reader's and writers's integrities. Then the operation is performed. The main idea is that accessing low-integrity data (a file downloaded from an untrusted source) makes a process untrusted and prevents its further access to high-integrity data (reading a file with personal information or changing an executable file). To be practical, integrity reduction of readers can be controlled by a testing function, which can prevent removing some integrity attributes from a reader. For example, a downloaded installation image file is assigned a low integrity. But if a checker program, which has high integrity, reads the file and verifies its digital signature, the program's integrity is not degraded, so it can pass the image to an installer as high-integrity data. There is also an integrity granting function, which can add some integrity attributes from a writer to a reader. It is essentially similar to the set-uid bit on executables. More technical description of the SOFI algorithm is contained in the mac_sofi.h header file. The implementation is an initial proof-of-concept. It demonstrates basic principles of the SOFI model, but only file open, access check, read, and write operations, as well as MAC label manipulation entry points of the MAC framework are implemented. The internal data structures are inefficient due to my unfortunate initial decision to combine a fixed-size integrity and some variable-size data into a single MAC label structure. It is my first attempt to create a nontrivial kernel module, so I expect bugs related to locking and memory management. There are also many open correctness-related questions, especially regarding memory-mapped data, multithreading, and blocking read operations. I would appreciate any comments on both the SOFI model and on my implementation. -- Martin Beran From owner-freebsd-hackers@freebsd.org Mon Jul 17 23:01:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59C9DDA36E6; Mon, 17 Jul 2017 23:01:23 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 065B67613F; Mon, 17 Jul 2017 23:01:23 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3xBJgh48V6z9g; Tue, 18 Jul 2017 01:01:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1500332476; x=1502924477; bh=ImLI30NzJkvUphL7G6XtDM8KFHbplOwj8aH K7UWXL0w=; b=KQEteV2qwTB2ethPcJggxvZE9LJ4dSOTTXC7MKq1gYP9H/Zxw/S uIbAY5ptlWlJbqsNIm7cDmZT7IDoLkLFX8SZu7pRFS0gTeg8v++umjZMmcW52Wwq zG4CvSDsg1oZOWAFcLxG6dSucMam7DNc3LcGamhufiyRoxrSmBinSsRY= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id OUB8vt3EGW9M; Tue, 18 Jul 2017 01:01:16 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3xBJgc31qNz9f; Tue, 18 Jul 2017 01:01:16 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3xBJgc2nJTz1Rj; Tue, 18 Jul 2017 01:01:16 +0200 (CEST) Received: from sleepy.ijs.si (2001:1470:ff80:e001::76) by nabiralnik.ijs.si with HTTP (HTTP/2.0 POST); Tue, 18 Jul 2017 01:01:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2017 01:01:16 +0200 From: Mark Martinec To: freebsd-stable@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: The 11.1-RC3 can only boot and attach disks in "Safe mode", otherwise gets stuck attaching Organization: Jozef Stefan Institute Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 23:01:23 -0000 Upgrading 11.0-RELEASE-p11 to 11.1-RC3 using the usual freebsd-update upgrade method I ended up with a system which gets stuck while trying to attach the second set of disks. This happened already after the first phase of the upgrade procedure (installing and re-booting with a new kernel). The first set of disks (ada0 .. ada2) are attached successfully, also a cd0, but then when the first of the set of four (a regular spinning disk) on an LSI controller is to be attached, the boot procedure just gets stuck there: kernel: ada1: 300.000MB/s transfers (SATA 2.x, PIO4, PIO 8192bytes) kernel: ada1: Command Queueing enabled kernel: ada1: 305245MB (625142448 512 byte sectors) kernel: ada2 at ahcich6 bus 0 scbus8 target 0 lun 0 kernel: ada2: ATA8-ACS SATA 3.x device kernel: ada2: Serial Number OCZ-O1L6RF591R09Z5C8 kernel: ada2: 300.000MB/s transfers (SATA 2.x, PIO4, PIO 8192bytes) kernel: ada2: Command Queueing enabled kernel: ada2: 114473MB (234441648 512 byte sectors) kernel: ada2: quirks=0x1<4K> kernel: da0 at mps0 bus 0 scbus0 target 2 lun 0 (stuck here, keyboard not responding, fans rising their pitch, presumably CPU is spinning) (instead of the normal continuation like: kernel: da0: Fixed Direct Access SPC-4 SCSI device kernel: da0: Serial Number .... kernel: da0: 600.000MB/s transfers kernel: da0: Command Queueing enabled kernel: da0: 1907729MB (3907029168 512 byte sectors) ) The controller for da0 .. da3 is an LSI: kernel: mps0: port 0x4000-0x40ff mem 0xd1740000-0xd1743fff,0xd1300000-0xd133ffff irq 16 at device 0.0 on pci1 kernel: mps0: Firmware: 14.00.01.00, Driver: 21.02.00.00-fbsd kernel: mps0: IOCCapabilities: 185c [...] kernel: mps0: SAS Address for SATA device = a4a4843003d0cf79 kernel: mps0: SAS Address from SATA device = a4a4843003d0cf79 kernel: mps0: SAS Address for SATA device = d3d48904eddff0d5 kernel: mps0: SAS Address from SATA device = d3d48904eddff0d5 [...] kernel: mps0: SAS Address for SATA device = 2a021c07585c665b kernel: mps0: SAS Address from SATA device = 2a021c07585c665b kernel: mps0: SAS Address for SATA device = 2a021c0758637b7c kernel: mps0: SAS Address from SATA device = 2a021c0758637b7c This host in this configuration worked perfectly well with 11.0 and many older versions of the OS. After some frustration I found out that the system can boot fine if a boot loader option "Safe mode" is set. This way I successfully finished the upgrade procedure (installing world). Playing with loader options that the "Safe mode" turns on ( /boot/menu-commands.4th ) it seems that kern.smp.disabled=1 is the crucial option, although my attempts at ruling out remaining options of the "Safe mode" turned out inconclusive - perhaps there is some random/race involved. Anyway, in "Safe mode" the machine always boots normally and attaches all disks. This experience is much like described in: https://forums.freebsd.org/threads/56524/ where the poster ended up disabling SMP to be able to have a working host. It is also somewhat similar to: https://lists.freebsd.org/pipermail/freebsd-hackers/2017-July/051258.html where a FreeBSD 11.1 prerelease only boots on a single-CPU AWS host, but fails to boot on a 2-core CPU, with various symptoms, including: ( https://lists.freebsd.org/pipermail/freebsd-hackers/2017-July/051260.html ) Feeding entropy: . spin lock 0xffffffff80db45c0 (smp rendezvous) held by 0xfffff80004378560 (tid 100074) too long timeout stopping cpus panic: spin lock held too long Please advise, thanks Mark From owner-freebsd-hackers@freebsd.org Tue Jul 18 00:56:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2FB9C08861; Tue, 18 Jul 2017 00:56:00 +0000 (UTC) (envelope-from paggas1@yandex.com) Received: from forward17o.cmail.yandex.net (forward17o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::1e7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 881307D183; Tue, 18 Jul 2017 00:56:00 +0000 (UTC) (envelope-from paggas1@yandex.com) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [77.88.61.132]) by forward17o.cmail.yandex.net (Yandex) with ESMTP id 3BB0E21BC8; Tue, 18 Jul 2017 03:55:56 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id 7799B63C0E8B; Tue, 18 Jul 2017 03:55:53 +0300 (MSK) Received: by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id CCiud5xOnX-tAjqORHa; Tue, 18 Jul 2017 03:55:11 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1500339311; bh=+U8RjezC9NV5NG62UL4m8294fd6n2VU4Gy99a2Cj65Y=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=IaqcN7lf2Y8KRRZ7kox/EWg4abNcDiHMoLaQnJePI06c2EUKKsy0e+deoK+imwrLX vkhHmU+yCmz0J/nFgmhjArRGozrGbmQs3osZNw1kh+uhI3/msO/3nrgPlk3y+UfwWh hCyXmHId43Cfiv+YlhXp6P8NBxYdeZ9Z9TD+OzV4= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.com X-Yandex-Suid-Status: 1 0,1 0,1 1022867361,1 0 Subject: Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf To: Alan Somers , Panagiotes Mousikides Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current References: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> From: Panagiotes Mousikides Message-ID: Date: Tue, 18 Jul 2017 00:55:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 00:56:00 -0000 Den 2017-07-16 kl. 21:11, skrev Alan Somers: > On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides > wrote: >> Hello everybody! >> >> I am working on adding tests to the FreeBSD test suite for testing pf, the >> network packet filter. >> >> These tests need at least two machines running and connected to each other, >> with one machine generating network traffic and the other running pf and >> filtering the traffic. I am looking for a way to fire off a bhyve instance >> to serve as the second machine, the first being the actual machine I am >> running the tests on. This should be done completely automatically, with >> scripts to configure all network interfaces and to preferably also set up an >> SSH server on the bhyve instance. >> >> This bhyve instance could start off as running the latest stable version of >> FreeBSD, or it could be configured to run a snapshot of the development >> tree. The aim is to have the desired version of FreeBSD that we want to >> test running on it. Ideally this would be done in such a way that we can >> reuse the machine for further tests, instead of rebuilding everything from >> scratch for each test. >> >> What I am looking for is the best way to do this, preferably so that it can >> be easily integrated into the CI work being done at Jenkins. What do you >> think? Any input is welcome! >> >> All the best, >> Panagiotes > It's possible to setup CI systems that involve multiple machines > networked together. I've done it. But it's complicated, fragile, and > slow. I advise you to consider very carefully whether you truly need > multiple VMs. What about creating an epair(4)? You could run pf on > epair0b and generate traffic from epair0a. That would be faster than > spinning up VMs, and would be very easy to integrate into any other CI > system. Would that work? > > -Alan > Hi Alan! Thank you for the tip about epair(4), it sounds really like an interesting approach to my problem. I will look into it! Best regards, Panagiotes From owner-freebsd-hackers@freebsd.org Tue Jul 18 17:27:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74E31D9AA02 for ; Tue, 18 Jul 2017 17:27:51 +0000 (UTC) (envelope-from vasis.g@gmail.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 3A26976195 for ; Tue, 18 Jul 2017 17:27:51 +0000 (UTC) (envelope-from vasis.g@gmail.com) Received: by mail-oi0-x230.google.com with SMTP id x187so22917009oig.3 for ; Tue, 18 Jul 2017 10:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NDahkLEWSv+CfTITyr0FgkNwdcToNsI7ohuY0xXODXU=; b=uE05dvUO9QnBBT6QUjBZCqwGtWilWGWPxpOzLs3XgREUIzsrmRj4gsIcvG7B8uynef wPQEi+mIge04mmHTJ74arTjb+u6PN6TPrmrNfNJ9BYKYZIhfKCRnAm3ocFabqEQv2L5e F2YSYsCZvbRmZOC2jy2XyTlZJL40aZyXrSieq6O1bNU+Zx/77ENx/8LcSoI0eU9Mi7FH Q4cZ7b+iL9U08vvhMbjr6zwD3HwFcSAXayzt789MaiMK8ZALuzdJbZUBgTVvg+RenN0i HicrP1RjzKn3j1I0Lak4pctzx7Gw3dKJL7FZd5eGKBVuodIPplbR2VZaOsY5o2fi26yQ F2Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NDahkLEWSv+CfTITyr0FgkNwdcToNsI7ohuY0xXODXU=; b=FSzPVlDgJ5ijStl7KeAAoLsuYjbLVP0HK7+eDZooF2lnb6/SS7inkLnDM0IXHARmT0 4+N0B8dKO/xcoNPLt5ihBV2sfTZVQCJzq8hOnVeUPmErqLIp8wQMSSbGkBs08bIqA/Ft 1kdhXyrO2W7Tq96QpCI/NeLJ4ze1Vy7uS5hMOGofK5oj7unG7J7ROch5WrH6e3UxzlZh GrP2HQte2UU2g1cj+BQRs5kHb+0E74WcFrsjq7lVnJN+avKPCedsz3XUv+GacbH1Bbdy 862XOSjLrK4yJSky7MN0d273HRMnUXyK1zTuL44WB9YUMWj3MfqNWUBMvMPo3RfH+Bzm tZzw== X-Gm-Message-State: AIVw110AO8wGUiT+3aIzLoIkq9MlQlA2fNOk/U0uFwI9qgVGkoe85+pa u6eBNoqiGWgZT94xCLXiyfgRGhjFAmZw X-Received: by 10.202.242.213 with SMTP id q204mr1642466oih.88.1500398870167; Tue, 18 Jul 2017 10:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.104 with HTTP; Tue, 18 Jul 2017 10:27:29 -0700 (PDT) From: Vasisvaran G Date: Tue, 18 Jul 2017 12:27:29 -0500 Message-ID: Subject: lint(1) improvements from OpenBSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:27:51 -0000 Hackers, I am planning to work on https://wiki.freebsd.org/IdeasPage#lint.281.29_improvements_from_OpenBSD. Please do let me know if anyone has already started working on it on or before 7/21 so that duplicate effort can be avoided. Regards, Vasu From owner-freebsd-hackers@freebsd.org Tue Jul 18 18:47:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2B88D9D1A1 for ; Tue, 18 Jul 2017 18:47:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 8C5057F12A for ; Tue, 18 Jul 2017 18:47:19 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 674427e6-6be9-11e7-bfd0-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 674427e6-6be9-11e7-bfd0-afd4446ba3af; Tue, 18 Jul 2017 18:46:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v6IIkFO6001673; Tue, 18 Jul 2017 12:46:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1500403575.22314.182.camel@freebsd.org> Subject: Re: lint(1) improvements from OpenBSD From: Ian Lepore To: Vasisvaran G , freebsd-hackers@freebsd.org Date: Tue, 18 Jul 2017 12:46:15 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:47:19 -0000 On Tue, 2017-07-18 at 12:27 -0500, Vasisvaran G wrote: > Hackers, > > I am planning to work on > https://wiki.freebsd.org/IdeasPage#lint.281.29_improvements_from_Open > BSD. > Please > do let me know if anyone has already started working on it on or > before > 7/21 so that duplicate effort can be avoided. > I have heard it expressed on the mailing lists in the past year or two that we should just abandon lint completely.  I dont' think anything was decided, but it's certainly a sentiment I agree with.  Given all the static analysis tools available today I'm not sure lint serves any purpose that isn't already covered by better tools. -- Ian From owner-freebsd-hackers@freebsd.org Tue Jul 18 20:24:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED25AD9F6A4 for ; Tue, 18 Jul 2017 20:24:27 +0000 (UTC) (envelope-from vasis.g@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 A84B982941; Tue, 18 Jul 2017 20:24:27 +0000 (UTC) (envelope-from vasis.g@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id p188so27204182oia.0; Tue, 18 Jul 2017 13:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/WAGlu977d2vCmXeNycnTWA8Wp+MGxaezb+aUhqUCbI=; b=BTW4VgLZItZkvWXBC0BT2yK1OS4lN1yfB/hG3NFHlg7ko5dt6sG1EUIvVfyqYBSFwZ bzvNcU13KofFclNjLjqzOPpKa6TMXLUlbfAGFJCGrSKhb1r9WbFdJJ7QFlygssb9EUck xf5F1oxJQtxlyWrmM1gSRvBrlsw24LSPcq35S51w5/RmKD4yUov+YBJsUDHKc3PqBObk 8+Wv2NyPg6gFVFhDJEPT1HvHhvl2SLv/SrWf6d9xPFu19/Qza9oesYFGtUUmeZYnktNm oiP9qN7wfevXjKiiF0xboyYa/UULGFEYM4IogoSOuiQYUgCknIcCp0gRSk0NgDZfIfSy lObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/WAGlu977d2vCmXeNycnTWA8Wp+MGxaezb+aUhqUCbI=; b=Qntdtyu5NsODNimvW3jzYRvsBPsEidTo8NL/UHIKOdpAM4axU2YZh6cblfCBwsNrG0 a8yqQC4S6RUZF9awG6rC+jig7n/gY/0FhVT4qHqtkrEGyBNjXyuDDV67Ab5PZHYpUnZ8 ozpoBPO5qpaxQeq8HloywWrMXfssquagg3o1ayBnB9Gp/G2CgSrLnkI7vTfuiasB3LcL i03E2gSchOy4vwo3gRI5ZW+LAgfHjA8w7wkLYOanqHaioId1/uXf02xztpGd9n2IlMSt B+xuAgCrcYgmbL1f2EcHug8XrcsbROXJ0VXJyY3JloUo88NvBzjTXQZn9t2DNtYl4faM 2dHg== X-Gm-Message-State: AIVw113ddbe6musMFdSNAPlmYm88qxLBMVGauPQ30XqIh9a6u6CfBnnQ hDnoFai0RxtIYKajgi7vK8wOa83LPg== X-Received: by 10.202.80.66 with SMTP id e63mr2438903oib.152.1500409466788; Tue, 18 Jul 2017 13:24:26 -0700 (PDT) MIME-Version: 1.0 References: <1500403575.22314.182.camel@freebsd.org> In-Reply-To: <1500403575.22314.182.camel@freebsd.org> From: Vasisvaran G Date: Tue, 18 Jul 2017 20:24:16 +0000 Message-ID: Subject: Re: lint(1) improvements from OpenBSD To: Ian Lepore , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 20:24:28 -0000 Yes, I agree. On Tue, Jul 18, 2017 at 1:46 PM Ian Lepore wrote: > On Tue, 2017-07-18 at 12:27 -0500, Vasisvaran G wrote: > > Hackers, > > > > I am planning to work on > > https://wiki.freebsd.org/IdeasPage#lint.281.29_improvements_from_Open > > BSD. > > Please > > do let me know if anyone has already started working on it on or > > before > > 7/21 so that duplicate effort can be avoided. > > > > I have heard it expressed on the mailing lists in the past year or two > that we should just abandon lint completely. I dont' think anything > was decided, but it's certainly a sentiment I agree with. Given all > the static analysis tools available today I'm not sure lint serves any > purpose that isn't already covered by better tools. > > -- Ian > -- Regards, Vasisvaran From owner-freebsd-hackers@freebsd.org Wed Jul 19 01:26:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35028DA4B0B for ; Wed, 19 Jul 2017 01:26:54 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE6C65CBA for ; Wed, 19 Jul 2017 01:26:52 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id v6J1Pl0V022108 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 19 Jul 2017 11:25:48 +1000 (AEST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) X-Authentication-Warning: b3.hs: Host ewsw01.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: mac_sofi: a proof of concept MAC module To: Martin Beran , freebsd-hackers@freebsd.org References: From: Dewayne Geraghty Message-ID: <5f10fbd6-f8aa-0e47-0861-9bfebff0ca74@heuristicsystems.com.au> Date: Wed, 19 Jul 2017 11:26:18 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 01:26:54 -0000 Martin, Would it be possible to expand on how SOFI is better/different to MAC lomac? As it seems that the testing program is the differentiator? Aside: Also you may not be aware that system namespace extended attributes do not function within a jail, though this is the same as the rest of MAC. I'm told that SELinux uses "security" and others use "trusted" namespaces, perhaps for some future FreeBSD...? Regards, Dewayne. From owner-freebsd-hackers@freebsd.org Wed Jul 19 18:35:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 733F1CFF67D for ; Wed, 19 Jul 2017 18:35:51 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1A26664A7 for ; Wed, 19 Jul 2017 18:35:50 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: by mail-wr0-x236.google.com with SMTP id v105so31806971wrb.0 for ; Wed, 19 Jul 2017 11:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rawSiL09ZaNhbkbE3zZGk0a7ukjGCe9kI+H1gW43M5U=; b=N58FEQCDeBDExXHDjFQ/TDmDBhqqVO06nORLKDy0bUDRKpftA42vltByzzcbKAJuIo Xjf8cdkGB1fNEkh8muncALbCyP9LjxNVXZ+2oa+6DWcizJz74388VcJraOMtuIfjLubE 3+XH0WLCeaZarssYFLKZ6ye2tc4UCbibnMhZKDh8fdBLCYbtlR1Zeqy4nHjFM4Et3xYg r04TVRKi5l8VJMEaff4lIYWC8rL+fswc/asZV+6Ez4A3cDqe+1Shvgks0ldoqMiKk/IV ZR9nyTGqrQe3uzr8B5bOK3EDuXEDwXDjO/ObELKNiSQPxT8FwfZHpfNx1/0inK3BEl4D 9NyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rawSiL09ZaNhbkbE3zZGk0a7ukjGCe9kI+H1gW43M5U=; b=BNa51m9q9adCJZfRpFmHz1O6oolrr5KJW5HVzyucQEbAmjiKUNDM8QZZ7WeL35uPQw kqznWpvZd3jAkYihgOqa6Ecqv79bF9CPakr4R9axf458djPdN+bCNxetthrZjT5280jS sKEZVer8f4Qw2UoVRKl3r+Oc5YtZmgA4179pyG/b8tJWNOZkGVsQiB8fuwHMR+aNVgbR 39BrlGLOvq1wvucRclOIlj1BoYz6VZbkEnBCUL84x8RWD5h/fR2Tj0cM4PEOIh96OQnF 95b/a/kkHsY6dLn+/hO/GzKZUbjPfAbM17EUvGJVw7gYWZlkpmw+3I20mv0NJNKlyktq 2FeQ== X-Gm-Message-State: AIVw112DHLedoAw7lf+zj2ekcrDhOSr+7IVRUT86nvBNezf8kmiGNGTw N7PGhQTZMtLF1T3yDvk= X-Received: by 10.223.176.73 with SMTP id g9mr4830349wra.108.1500489348668; Wed, 19 Jul 2017 11:35:48 -0700 (PDT) Received: from mb.tns.cz ([92.43.24.116]) by smtp.gmail.com with ESMTPSA id k76sm623035wmg.38.2017.07.19.11.35.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 11:35:47 -0700 (PDT) Sender: Martin Beran Subject: Re: mac_sofi: a proof of concept MAC module To: freebsd-hackers@freebsd.org References: <5f10fbd6-f8aa-0e47-0861-9bfebff0ca74@heuristicsystems.com.au> From: Martin Beran Message-ID: Date: Wed, 19 Jul 2017 20:35:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5f10fbd6-f8aa-0e47-0861-9bfebff0ca74@heuristicsystems.com.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:35:51 -0000 On 07/19/17 03:26, Dewayne Geraghty wrote: > Would it be possible to expand on how SOFI is better/different to MAC > lomac? As it seems that the testing program is the differentiator? 1. LOMAC integrity is essentially a single number. SOFI integrity is a set of integrity attributes. This provides integrity values that are only partially ordered. For example, there is usually no ordering between "trusted by user A" and "trusted by user B", and a file can be also trusted by both users simultaneously. Then, if user A changes the file, it remains "trusted by A", but ceases to be "trusted by B", until user B verifies its new content. 2. LOMAC demotes only subjects (processes) upon reading from objects (files). SOFI demotes the reader side of each operation, that is, the subject of a read operation, the object of a write operation, and both the subject and the object of a read/write operation. 3. SOFI integrity values, which form a lattice instead of a simple linear ordering, provide "more interesting" combining of integrities of subjects and objects. Integrity demotion is based on intersection of integrities. Granting of integrity attributes is based on union. In my opinion, it supports real world needs of integrity enforcement better than LOMAC. 4. LOMAC uses a single integrity value both for following information flow and for making access decisions. SOFI uses and updates subject's and object's integrity values for tracking information flow, but makes its access decisions by comparing subject's integrity with object's ACLs, which are not changed by normal operations. 5. SOFI provides two "escape paths" from strict integrity checking: An integrity checking function allows a reader to keep a subset of integrity attributes, which would be otherwise removed by a low integrity writer. For example, an antivirus engine can read a downloaded, potentially infected, hence low-integrity file without reducing its own integrity needed for further functioning. Integrity granting and accepting functions allow transfer of integrity attributes from readers to writers. It is similar to a set-uid bit or to LOMAC relabeling of a process upon execution of a file. Unlike set-uid or LOMAC, integrity granting in SOFI is not limited to processes. For example, if an antivirus engine checks a file successfully, it can grant it a higher integrity. > Aside: Also you may not be aware that system namespace extended > attributes do not function within a jail, though this is the same as the > rest of MAC. I'm told that SELinux uses "security" and others use > "trusted" namespaces, perhaps for some future FreeBSD...? As my implementation is only a demonstration of ideas of the SOFI model, I did not take jails into account. -- Martin Beran From owner-freebsd-hackers@freebsd.org Thu Jul 20 07:25:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5718CDAABCA for ; Thu, 20 Jul 2017 07:25:36 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 143A983E41 for ; Thu, 20 Jul 2017 07:25:35 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dY5Qr-0007AQ-7o for freebsd-hackers@freebsd.org; Thu, 20 Jul 2017 08:59:33 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dY5Qp-0008Tp-4l for freebsd-hackers@freebsd.org; Thu, 20 Jul 2017 08:59:31 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CC07F2A004F for ; Thu, 20 Jul 2017 08:59:31 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id s3TZ4NIRLdUj for ; Thu, 20 Jul 2017 08:59:28 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CEB282A160A for ; Thu, 20 Jul 2017 08:59:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XvxEASNxxbL8 for ; Thu, 20 Jul 2017 08:59:28 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id AEC5A2A004F for ; Thu, 20 Jul 2017 08:59:28 +0200 (CEST) To: FreeBSD From: Sebastian Huber Subject: Relationship between ncallout and callwheelsize Message-ID: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> Date: Thu, 20 Jul 2017 08:59:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23579/Thu Jul 20 02:14:56 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:25:36 -0000 Hello, I noticed on a LPC4088 running at 96MHz from external SDRAM that the=20 callout_process() function needs a lot of time even if no callouts are=20 active. The reason is that on a 32-bit architecture with only 13 general=20 purpose registers this function needs a lot of load/store operations. So=20 I tried to reduce the complexity by using compile time constants. I=20 don't understand why the callwheelsize and the timeout(9)=20 pre-allocations are related: ncallout =3D imin(16 + maxproc + maxfiles, 18508); TUNABLE_INT_FETCH("kern.ncallout", &ncallout); /* * Calculate callout wheel size, should be next power of two higher * than 'ncallout'. */ callwheelsize =3D 1 << fls(ncallout); callwheelmask =3D callwheelsize - 1; The size of the wheel should be related to typical timeout values to=20 balance memory size and hash collisions. Why is there a connection to=20 the timeout(9) pre-allocations? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Thu Jul 20 08:18:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA42EDABB71 for ; Thu, 20 Jul 2017 08:18:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 724491825 for ; Thu, 20 Jul 2017 08:18:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 53BA4260666; Thu, 20 Jul 2017 10:18:57 +0200 (CEST) Subject: Re: Relationship between ncallout and callwheelsize To: Sebastian Huber , FreeBSD References: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> From: Hans Petter Selasky Message-ID: <597c9854-8074-81b2-4094-8aaeae29bdb7@selasky.org> Date: Thu, 20 Jul 2017 10:16:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:18:59 -0000 On 07/20/17 08:59, Sebastian Huber wrote: > Hello, > > I noticed on a LPC4088 running at 96MHz from external SDRAM that the > callout_process() function needs a lot of time even if no callouts are > active. The reason is that on a 32-bit architecture with only 13 general > purpose registers this function needs a lot of load/store operations. So > I tried to reduce the complexity by using compile time constants. I > don't understand why the callwheelsize and the timeout(9) > pre-allocations are related: > > ncallout = imin(16 + maxproc + maxfiles, 18508); > TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > > /* > * Calculate callout wheel size, should be next power of two higher > * than 'ncallout'. > */ > callwheelsize = 1 << fls(ncallout); > callwheelmask = callwheelsize - 1; > > The size of the wheel should be related to typical timeout values to > balance memory size and hash collisions. Why is there a connection to > the timeout(9) pre-allocations? > Hi, The calloutwheel is simply an optimisation. If you don't need many callouts, maybe a per-CPU list will be enough for your purpose. --HPS From owner-freebsd-hackers@freebsd.org Thu Jul 20 08:19:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAAEFDABB8B for ; Thu, 20 Jul 2017 08:19:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 8FD3E1888 for ; Thu, 20 Jul 2017 08:19:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 932E3260628; Thu, 20 Jul 2017 10:15:46 +0200 (CEST) Subject: Re: Relationship between ncallout and callwheelsize To: Sebastian Huber , FreeBSD References: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> From: Hans Petter Selasky Message-ID: <757f601d-96ad-0334-a663-963e8da6cb0e@selasky.org> Date: Thu, 20 Jul 2017 10:13:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:19:10 -0000 On 07/20/17 08:59, Sebastian Huber wrote: > Hello, > > I noticed on a LPC4088 running at 96MHz from external SDRAM that the > callout_process() function needs a lot of time even if no callouts are > active. The reason is that on a 32-bit architecture with only 13 general > purpose registers this function needs a lot of load/store operations. So > I tried to reduce the complexity by using compile time constants. I > don't understand why the callwheelsize and the timeout(9) > pre-allocations are related: > > ncallout = imin(16 + maxproc + maxfiles, 18508); > TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > > /* > * Calculate callout wheel size, should be next power of two higher > * than 'ncallout'. > */ > callwheelsize = 1 << fls(ncallout); > callwheelmask = callwheelsize - 1; > > The size of the wheel should be related to typical timeout values to > balance memory size and hash collisions. Why is there a connection to > the timeout(9) pre-allocations? > Hi, The calloutwheel is simply an optimisation. If you don't need many callouts, maybe a per-CPU list will be enough for your purpose. --HPS From owner-freebsd-hackers@freebsd.org Thu Jul 20 08:20:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A016DABCD0 for ; Thu, 20 Jul 2017 08:20:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 EA1741AA0 for ; Thu, 20 Jul 2017 08:20:19 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 77345260651; Thu, 20 Jul 2017 10:17:40 +0200 (CEST) Subject: Re: Relationship between ncallout and callwheelsize To: Sebastian Huber , FreeBSD References: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> From: Hans Petter Selasky Message-ID: <6453f4fa-016f-3d7a-ce03-aa49c7f465e5@selasky.org> Date: Thu, 20 Jul 2017 10:15:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <8ba43394-41e4-f06c-a8c6-12b773d185c4@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:20:20 -0000 On 07/20/17 08:59, Sebastian Huber wrote: > Hello, > > I noticed on a LPC4088 running at 96MHz from external SDRAM that the > callout_process() function needs a lot of time even if no callouts are > active. The reason is that on a 32-bit architecture with only 13 general > purpose registers this function needs a lot of load/store operations. So > I tried to reduce the complexity by using compile time constants. I > don't understand why the callwheelsize and the timeout(9) > pre-allocations are related: > > ncallout = imin(16 + maxproc + maxfiles, 18508); > TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > > /* > * Calculate callout wheel size, should be next power of two higher > * than 'ncallout'. > */ > callwheelsize = 1 << fls(ncallout); > callwheelmask = callwheelsize - 1; > > The size of the wheel should be related to typical timeout values to > balance memory size and hash collisions. Why is there a connection to > the timeout(9) pre-allocations? > Hi, The calloutwheel is simply an optimisation. If you don't need many callouts, maybe a per-CPU list will be enough for your purpose. --HPS From owner-freebsd-hackers@freebsd.org Thu Jul 20 16:24:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDEC3C7B6F1 for ; Thu, 20 Jul 2017 16:24:24 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 7899E6F675 for ; Thu, 20 Jul 2017 16:24:24 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-ua0-x235.google.com with SMTP id w45so27037275uac.5 for ; Thu, 20 Jul 2017 09:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yukd31bhFnjxWm1whv0HwYuZqbO5+gFxGacF8dCLxlk=; b=X6/tbRylNMON8nQjym6npoTvmi7VDhk/dGT7stb/vL8S1WmFCOvZE4dzpSsGAJbxgH G/26X8/9trBATkfmqgHCIGo+yrx27/t5awm2PCt02uU/Uft6RdufEbVFHatZ2p0p2UW/ XI2ym3ia3RiG8x88URKlfHfdD5Eo2Fd25KIwl91jbHspRZLl909/T2zcCsrdNknuMHfE cnpb+wdu4MYx6tyt+pMLnuQL64tmfDrv/lGsWTfW4QmlwqL2hvV5mmNJD456u6U9XdSE IFDFeN5Z/exGEuBYMjhBPgz/zKrHX+G/RW9bTy481ZyENuMkBVk6JQ+LpDRXgQ8lJuP8 pH7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yukd31bhFnjxWm1whv0HwYuZqbO5+gFxGacF8dCLxlk=; b=Qp47xkbuW1EcAnXYbNSArJeXRw/Btnjn6qjUVSo8VkYITpav3CEn2cxAcmNqRTVSiP cpTJssb91bTAeWKKbcQI6y6XlWWBjBQKveg3vMSaa0nXSagaLOCRNQhDO7IjYoXLxQpp /MxnpTM2IFJcXzx0jn9ViZff44Wn2kcGL/t8OyHnUrszkf44eFIsLJuQMvtB4NjnVDFK A5pbATC/UGW5xd8diXuzHirdRH5tb86YYXW1WFTswTrsZlgmJhsahrribHiOvHIo37pV bxXxXWEJ+wQVkNmCDhnp6lg+9PNNFauyjZV26LCWx581hRQgAZAvroIVVuvKjTtm5wRL doEA== X-Gm-Message-State: AIVw110UQb3coOsE+zJeNRSVXIHSYwS23CRQzBOZ6V7AZmwvxDtF/ajb z0ONN9TGZ25vkjhwWEeEyDB6emreunnb X-Received: by 10.31.140.193 with SMTP id o184mr2239240vkd.92.1500567863054; Thu, 20 Jul 2017 09:24:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.55.198 with HTTP; Thu, 20 Jul 2017 09:24:22 -0700 (PDT) From: Aijaz Baig Date: Thu, 20 Jul 2017 21:54:22 +0530 Message-ID: Subject: replace base KGDB with latest version To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:24:24 -0000 As of now I have installed the latest version of gdb via the package manager (7.9.1). The binary gets installed as /usr/local/bin/gdb which is apparently a symlink to /usr/local/bin/gdb791. The version which comes with the system is at /usr/bin/gdb which is an older version (v6.1.1). I have modified my path to have /usr/local/bin precede /usr/bin such that typing GDB on the prompt opens the latest version. However KGDB still refers to the older version of GDB. Is there a way to make KGDB refer to the newer version? Or do I have to remove it altogether and build it myself from the ports? I just want KGDB to refer to the newer version of GDB that I have on my system -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Thu Jul 20 16:24:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A60ABC7B6E0; Thu, 20 Jul 2017 16:24:22 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2376D6F673; Thu, 20 Jul 2017 16:24:21 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0LaaVn-1e2e6u1vO3-00mNeM; Thu, 20 Jul 2017 18:24:19 +0200 From: Nikos Vassiliadis Subject: Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf To: Panagiotes Mousikides , Alan Somers Cc: "freebsd-hackers@freebsd.org" , FreeBSD Current References: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> Message-ID: <81ab7ffc-c89d-0a79-5736-32d555366f3f@gmx.com> Date: Thu, 20 Jul 2017 18:24:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:weIlLa9zhERN7QqbSqIm+whgr3H1+E+8itVwEO7emL26as9+tJU 5pBRG1UiZKUEb4X2e4xI/9eZ3WK7JVHRECvHEHTnQHSLlO7xOWzFvMcqxVJ8yIPNFnAiu+d 4UUX2FL9cwTdkI0JCLyEB2fbi+kKPTW7eiVVNPQxgIxTYE7hok4e2NBgZhEnIA7Byuwpq7b O8KhyjwAFkk1pkh+Gj0ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:eHhp1S95aoI=:XraAI9PiOnhu53Y+Yhr7Tn 815GMy03fByEfrPkYoZUkBrk/RNPnw4KmBatLBtbdfQeqjcgR4etJC1kjtKSMYDdM3IEfY3BS JkQ0LmHILv9aawYb2CAWbr/OX0TUHmbIN18ifIOQF6PWmpVb6R/oumDrnESptXVrIquw6FLcc MHpLcYPEudgP38g2oKMLLQ+3b1l1FRiOmANaKPcSwPia4rIKSTSgIOIMWK5mUmlO4PTTfAkxK ZxbahFKn5SopKWmrh4mdIBjbcFKLeoUgw6eFs0sz/0SMUV721l5XVuax7C73In2yAGu9Kb3gG 0s+vyD+CCdNEtoipGTMPM/+dwpTSCUg12aDnVy4P55/ZaC5XKwvqhFhUuyhJtJHg2qbw9Lbm6 5glmnl+oHca8KpZH6dvQwRhdR1Gk3/ShAZuAWv7eIvhty1W0/H9jyOMooRZh7R6GoIt1cuROt OiEhfEv7gYbfkvey+WMYRaGG9r9aORSeFB9IJ/PzGAya/PhGE7mlkHwLpj0A1eVaHeDFXw6/q i+dkD4KK5ub6T3VHvKbJnXBt8vN53KOvqctDtPaSxMST8UQu/Mr4VqlUuChBr7Sl3qsYPVH5Z 4vTzfG5NoY0fEUtSi97EJNfdGBIg6aFLMuNp6uEh2qPJdzyiAIBbbMHkwtInbRyC7IVtW0ymu QYfKCKH8gFjPT9a4wlNDGinZok+XvW4pb9ypXwUV0ohIPLN+zTgchwNFSmqQxHOJtPpFI8I3P YVyp8vbE+4GtAUvUtDcvHvLpewAkW2yuVS5vDK7UqLo/VuDB4sZwG7kWci36XUu55D52b6vkH VyKVuWW0YLw9680uUjYU29rz6x8lAmTOURRazBE/HyUnb+HsFI= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:24:22 -0000 On 07/18/2017 02:55 AM, Panagiotes Mousikides wrote: > Den 2017-07-16 kl. 21:11, skrev Alan Somers: >> On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides >> wrote: >>> Hello everybody! >>> >>> I am working on adding tests to the FreeBSD test suite for testing >>> pf, the >>> network packet filter. >>> >>> These tests need at least two machines running and connected to each >>> other, >>> with one machine generating network traffic and the other running pf and >>> filtering the traffic. I am looking for a way to fire off a bhyve >>> instance >>> to serve as the second machine, the first being the actual machine I am >>> running the tests on. This should be done completely automatically, with >>> scripts to configure all network interfaces and to preferably also >>> set up an >>> SSH server on the bhyve instance. >>> >>> This bhyve instance could start off as running the latest stable >>> version of >>> FreeBSD, or it could be configured to run a snapshot of the development >>> tree. The aim is to have the desired version of FreeBSD that we want to >>> test running on it. Ideally this would be done in such a way that we >>> can >>> reuse the machine for further tests, instead of rebuilding everything >>> from >>> scratch for each test. >>> >>> What I am looking for is the best way to do this, preferably so that >>> it can >>> be easily integrated into the CI work being done at Jenkins. What do >>> you >>> think? Any input is welcome! >>> >>> All the best, >>> Panagiotes >> It's possible to setup CI systems that involve multiple machines >> networked together. I've done it. But it's complicated, fragile, and >> slow. I advise you to consider very carefully whether you truly need >> multiple VMs. What about creating an epair(4)? You could run pf on >> epair0b and generate traffic from epair0a. That would be faster than >> spinning up VMs, and would be very easy to integrate into any other CI >> system. Would that work? >> >> -Alan >> > Hi Alan! > > Thank you for the tip about epair(4), it sounds really like an > interesting approach to my problem. I will look into it! > > Best regards, > Panagiotes Hi, It would be great if you use vnet jails for that. I am not sure regarding the per-vnet pf functionality but I have seen many bug fixes hitting the tree since last year. You can ask on freebsd-virtualization@freebsd.org or freebsd-pf@freebsd.org to learn more about it. Pf within a jail should behave more or less like the "normal" one. Plus you will be testing per-vnet functionality, which the project needs anyhow, in one go. Best regards, Nikos From owner-freebsd-hackers@freebsd.org Fri Jul 21 09:24:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7F2FDA0128; Fri, 21 Jul 2017 09:24:39 +0000 (UTC) (envelope-from srs0=mtmv=6y=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FF23697FC; Fri, 21 Jul 2017 09:24:39 +0000 (UTC) (envelope-from srs0=mtmv=6y=sigsegv.be=kristof@codepro.be) Received: from [192.168.228.1] (ptr-8ripyyi2gsyvj1795t0.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:f15b:3b81:7e:80a4]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 1F7C6B1DB; Fri, 21 Jul 2017 11:24:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1500629077; bh=F69XGbgioIr1CZV5QEwxiaCFwA0kIhFXRk1QFeWdhSA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=kGHlnIxhr6o0oDsna27f8VM1bq2WUpEcm+rr7ituCKge5qgOurhTzXlElddY4OYK3 E8M+R5ZHd+ytdqgITHSjV0Ca17AERfBBJ93Wie2rD6KkDdCF1hAjQKwvXuXGP4pR0k XsLHeh+ckwNOdz+LeopiaDQo7Xz5jtsHsBJWZCkQ= From: "Kristof Provost" To: "Nikos Vassiliadis" Cc: "Panagiotes Mousikides" , "Alan Somers" , "freebsd-hackers@freebsd.org" , "FreeBSD Current" Subject: Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf Date: Fri, 21 Jul 2017 11:25:00 +0200 Message-ID: <1DA23B47-AC65-450F-A643-55162D300638@sigsegv.be> In-Reply-To: <81ab7ffc-c89d-0a79-5736-32d555366f3f@gmx.com> References: <871d6043-0c56-2c9b-1e3e-5db33898c24a@yandex.com> <81ab7ffc-c89d-0a79-5736-32d555366f3f@gmx.com> MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6088) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:24:39 -0000 On 20 Jul 2017, at 18:24, Nikos Vassiliadis wrote: > It would be great if you use vnet jails for that. I am not > sure regarding the per-vnet pf functionality but I have seen > many bug fixes hitting the tree since last year. You can ask > on freebsd-virtualization@freebsd.org or freebsd-pf@freebsd.org > to learn more about it. > It’s starting to become usable, yes. > Pf within a jail should behave more or less like the "normal" one. > Plus you will be testing per-vnet functionality, which the project > needs anyhow, in one go. > It *should* behave the same, but the fact is that a setup like that tests vnet pf, not just pf. Ideally we should have both setups, but the priority should be on the setup most people use today, which is not vnet enabled. Regards, Kristof From owner-freebsd-hackers@freebsd.org Fri Jul 21 09:41:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2645DA0A8E for ; Fri, 21 Jul 2017 09:41:27 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id BBAA46A085 for ; Fri, 21 Jul 2017 09:41:27 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v6L9fLpu031309 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 21 Jul 2017 02:41:21 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me From: Yuri Subject: Do midi devices work on FreeBSD? To: Freebsd hackers list Message-ID: <9d39ebdc-8b61-b3f9-b6c1-1b99e1f932e6@rawbw.com> Date: Fri, 21 Jul 2017 02:41:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:41:28 -0000 The midi device isn't created for the soundcard that has a "midi" driver: EMU10Kx. For some weird reason even the probe in kernel, emu_midi_probe, isn't called. Yuri From owner-freebsd-hackers@freebsd.org Fri Jul 21 15:32:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5B28DAA8B4 for ; Fri, 21 Jul 2017 15:32:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 B085773ECD for ; Fri, 21 Jul 2017 15:32:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AC2A72600EB; Fri, 21 Jul 2017 17:32:15 +0200 (CEST) Subject: Re: Do midi devices work on FreeBSD? To: Yuri , Freebsd hackers list References: <9d39ebdc-8b61-b3f9-b6c1-1b99e1f932e6@rawbw.com> From: Hans Petter Selasky Message-ID: <7a073732-defe-d301-68ca-1b165f0aa794@selasky.org> Date: Fri, 21 Jul 2017 17:30:06 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <9d39ebdc-8b61-b3f9-b6c1-1b99e1f932e6@rawbw.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:32:19 -0000 On 07/21/17 11:41, Yuri wrote: > The midi device isn't created for the soundcard that has a "midi" > driver: EMU10Kx. > > For some weird reason even the probe in kernel, emu_midi_probe, isn't > called. > All USB MIDI devices work out of the box. If you need low latency look for high speed one. --HPS