From owner-freebsd-hackers@freebsd.org Mon Apr 16 04:21:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3020F84523 for ; Mon, 16 Apr 2018 04:21:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6735C6B704 for ; Mon, 16 Apr 2018 04:21:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id v140-v6so3206441ybe.3 for ; Sun, 15 Apr 2018 21:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=TYOeaz3HShhZoi1Y1Ozj21rt8GvK8lpoWxIfcqhCNww=; b=fCnyy49dkWyG2HGJr2GlXRXDvcc+1Q1KLgXD6ZyZ2QafY1O+db/mIJngj1MJqbrYAb R5xw7wepdHiemnyqpk+vb8ZyzCpvAmRiAt3f79CXAdamolPLCWdelN57YJ7bb1Tjun5d a9wM3JbXUcq16yWtH3gS9xoylzzAyKn/RmKXI= 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=TYOeaz3HShhZoi1Y1Ozj21rt8GvK8lpoWxIfcqhCNww=; b=ljyPciw9FlCd9dorAHtE5Am+tpH21H4lA9DRVqhpoR77Y1MfBTKxJOKBnk/WyXvvND coOQf6Wv1t0lzkkKfta0HsK8ADDsExyUxfkwRTFrFdEdYuOiYaYt+vh9VjndmyVY3k3T ftkJnyHV8Y29wWPFZcscUZEhLgRh/OBBqT+J+93DYFrEwqh5iX90wHCKFq0ZjLxWwv/S CcwGXwnmOZFtl8MwtA65W7C5p0tvhAXz4IYWkCtaF+ix/LQYpKbyfbAcWjYSXs775+PQ THlTmrp1sB7s2QZ1uxWN1/5uASWPi/aYVP/meDg3llUME/bMrDVzuGn/kJrgAjEQiqQq L+2w== X-Gm-Message-State: ALQs6tC8MZxwIsFI4bnELw/nNhGIQ53yousihGLtbXWn41+m5ffrbRyP G/AzAUJOoTTWuWFBNsBQCv2vNPtfWCh5X2JepmAuecRA X-Google-Smtp-Source: AIpwx49nYHgsyNGOz/3/vpJNiKttilmtyJzk9gRScXBcdAh4bXR8mWmSC/fgTpTsUcLskQ24FQDPITSXSrRm5DSs4Tc= X-Received: by 2002:a25:ac23:: with SMTP id w35-v6mr10437574ybi.87.1523852461130; Sun, 15 Apr 2018 21:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Sun, 15 Apr 2018 21:20:30 -0700 (PDT) From: Eitan Adler Date: Sun, 15 Apr 2018 21:20:30 -0700 Message-ID: Subject: panic: ip_mroute: empty ef->progtab[i].name To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 04:21:03 -0000 How to reproduce: kldload ip_mroute Unread portion of the kernel message buffer: [341188] [341188] [341188] Fatal trap 12: page fault while in kernel mode [341188] cpuid = 17; apic id = 11 [341188] fault virtual address = 0x0 [341188] fault code = supervisor read data, page not present [341188] instruction pointer = 0x20:0xffffffff80c50cd0 [341188] stack pointer = 0x28:0xfffffe00a741c440 [341188] frame pointer = 0x28:0xfffffe00a741c440 [341188] code segment = base 0x0, limit 0xfffff, type 0x1b [341188] = DPL 0, pres 1, long 1, def32 0, gran 1 [341188] processor eflags = interrupt enabled, resume, IOPL = 0 [341188] current process = 31597 (kldload) __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) bt #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=0x1) at /usr/src/sys/kern/kern_shutdown.c:361 #2 0xffffffff80434f4c in db_fncall_generic (addr=, rv=, nargs=, args=) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff80434a99 in db_command (last_cmdp=, cmd_table=, dopager=) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff80434814 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff80437a3f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80babf53 in kdb_trap (type=0xc, code=0x0, tf=) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff81025170 in trap_fatal (frame=0xfffffe00a741c380, eva=0x0) at /usr/src/sys/amd64/amd64/trap.c:815 #9 0xffffffff81025282 in trap_pfault (frame=0xfffffe00a741c380, usermode=) at /usr/src/sys/amd64/amd64/trap.c:664 #10 0xffffffff81024a72 in trap (frame=0xfffffe00a741c380) at /usr/src/sys/amd64/amd64/trap.c:413 #11 #12 strncmp (s1=0x0, s2=0xffffffff812562ea "set_", n=0x4) at /usr/src/sys/libkern/strncmp.c:44 #13 0xffffffff8114f214 in link_elf_lookup_set (lf=0xfffff8003930c800, name=0xffffffff83bacc82 "sdt_providers_set", startp=0xfffffe00a741c4a0, stopp=0xfffffe00a741c4a8, countp=0x0) at /usr/src/sys/kern/link_elf_obj.c:1265 #14 0xffffffff83bac5e9 in sdt_kld_unload_try (arg=, lf=0xfffff8003930cc00, error=0xfffffe00a741c504) at /usr/src/sys/cddl/dev/sdt/sdt.c:314 #15 0xffffffff80b3712b in linker_file_unload (file=0xfffff8003930c800, flags=0x1) at /usr/src/sys/kern/kern_linker.c:656 #16 0xffffffff8114d76f in link_elf_load_file (cls=, filename=, result=) at /usr/src/sys/kern/link_elf_obj.c:1002 #17 0xffffffff80b36a2c in LINKER_LOAD_FILE (cls=0xffffffff81b7dc80 , result=0x0, filename=) at ./linker_if.h:180 #18 linker_load_file (filename=, result=) at /usr/src/sys/kern/kern_linker.c:447 #19 linker_load_module (kldname=, modname=0x0, parent=0x0, verinfo=, lfpp=0xfffffe00a741c918) at /usr/src/sys/kern/kern_linker.c:2092 #20 0xffffffff80b38361 in kern_kldload (td=, file=, fileid=0xfffffe00a741c964) at /usr/src/sys/kern/kern_linker.c:1071 #21 0xffffffff80b3848b in sys_kldload (td=0xfffff800461cc560, uap=) at /usr/src/sys/kern/kern_linker.c:1097 #22 0xffffffff8102606b in syscallenter (td=0xfffff800461cc560) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134 #23 amd64_syscall (td=0xfffff800461cc560, traced=0x0) at /usr/src/sys/amd64/amd64/trap.c:936 #24 #25 0x00000008002cfd8a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffd468 (kgdb) frame 12 Stack level 12, frame at 0xfffffe00a741c450: rip = 0xffffffff80c50cd0 in strncmp (/usr/src/sys/libkern/strncmp.c:44); saved rip = 0xffffffff8114f214 called by frame at 0xfffffe00a741c4a0, caller of frame at 0xfffffe00a741c440 source language c. Arglist at 0xfffffe00a741c440, args: s1=0x0, s2=0xffffffff812562ea "set_", n=0x4 Locals at 0xfffffe00a741c440, Previous frame's sp is 0xfffffe00a741c450 Saved registers: rbp at 0xfffffe00a741c440, rip at 0xfffffe00a741c448 s1 = 0x0 s2 = 0xffffffff812562ea "set_" n = 0x4 No locals. (kgdb) list 1260 void **start, **stop; 1261 int i, count; 1262 1263 /* Relative to section number */ 1264 for (i = 0; i < ef->nprogtab; i++) { 1265 if ((strncmp(ef->progtab[i].name, "set_", 4) == 0) && 1266 strcmp(ef->progtab[i].name + 4, name) == 0) { 1267 start = (void **)ef->progtab[i].addr; 1268 stop = (void **)((char *)ef->progtab[i].addr + 1269 ef->progtab[i].size); (kgdb) p ef->progtab[i] $8 = { addr = 0x0, size = 0x0, flags = 0x0, sec = 0x0, name = 0x0 } -- Eitan Adler From owner-freebsd-hackers@freebsd.org Mon Apr 16 04:39:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 851F0F858A8 for ; Mon, 16 Apr 2018 04:39:48 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2754770E2E for ; Mon, 16 Apr 2018 04:39:48 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x233.google.com with SMTP id k199-v6so6591805ybk.12 for ; Sun, 15 Apr 2018 21:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7ixYfFyehTPVX01cLOb5bNYJZUEOqwG5EgrNdxqXUyk=; b=LwLFeO0HaCtYtr8vuMNm8EWVJ37SDpFETdQUphULd+TYLonF3ZPJfhJ9uTCE/INxt2 C7n/CGbtU7m9Y9z0+XhznkCi46Crjd+yYMruB428qn3xSyd2g0EmsZqh6S32tY31eJxf VPhgSnXdHUrZLY5i1eJwbLnVsaZSDN0hy+66A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7ixYfFyehTPVX01cLOb5bNYJZUEOqwG5EgrNdxqXUyk=; b=E1FWD54MrRMsobsltiAj3mwdffAYGT/zp1IcYqr5hdVRvAM2IGW5FqgyV5a0FPtzVE KrHUsu84TkJvW6FL20yD8Yr4iji2rV6LONjCTvt6fWJ4GjDtnS6vAu1aZuvSvakN3Omq vXVX557RMyV1g/IvIaEv7HZdQi2BO1jYj+8BZjVPymvAgs6CqnO2LxAX7/djz6YtIj/P 1cc5RGlkNRpbgPW1Y7neULXC8vJ6U3WP1hHdPrmWRiKh8mJZXKYrOmme/TwSdilY9im3 F4xdlOZGW2iiz0qS6NXo2IzwizqXiGh9gmvjZvLeye/B1xGGslmR7LxeTGzizCNGsYq3 3o2A== X-Gm-Message-State: ALQs6tAKniSLar8QBcbOh9Hqj4T5GFwjwe2LK4oGJXy02O+H6cEuiE02 6ogp64nOiuinwesd1fZvmGAJfZ2qZaiAfq3Xa1247g== X-Google-Smtp-Source: AIpwx48ig3lhKaQcDc6hwRbkpCyFAlYrz4k5Es7ZHInDwGXrTr8Z4FLb1zZFRbyhuYPJcsba3YlwzFcLah49m5ZI6ao= X-Received: by 2002:a25:d705:: with SMTP id o5-v6mr10361853ybg.338.1523853587235; Sun, 15 Apr 2018 21:39:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Sun, 15 Apr 2018 21:39:16 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 15 Apr 2018 21:39:16 -0700 Message-ID: Subject: Re: panic: ip_mroute: empty ef->progtab[i].name To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 04:39:48 -0000 On 15 April 2018 at 21:20, Eitan Adler wrote: > How to reproduce: > > kldload ip_mroute I managed to reproduce this as well with "kldload ipsec" as well, so it does not appear to be specific to ip_mroute (nor did I expect it to be). -- Eitan Adler From owner-freebsd-hackers@freebsd.org Mon Apr 16 10:58:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05097F9F2A0 for ; Mon, 16 Apr 2018 10:58:25 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9316882C2C for ; Mon, 16 Apr 2018 10:58:24 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 46765F9F29E; Mon, 16 Apr 2018 10:58:24 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32935F9F29D; Mon, 16 Apr 2018 10:58:24 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 B974082C0C; Mon, 16 Apr 2018 10:58:23 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f81Lq-000NYe-KY ; Mon, 16 Apr 2018 13:27:10 +0300 Date: Mon, 16 Apr 2018 13:27:10 +0300 From: Vitalij Satanivskij To: hackers@freebsd.org, freebsd-current@freebsd.org Subject: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180416102710.GA90028@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 10:58:25 -0000 Hello. We have a kernel panic when loading current or 11.1 snapshot As while booting from usb steck or from hdd/ssd with installed system Kernel - GENERIC DUMP can be found here http://hell.ukr.net/panic/panic.jpg or even video record from screen http://hell.ukr.net/panic/recorder.webm Hardware is - 2x AMD EPYC 7251 Processor on Supermicro H11DSI mother board. Only way to boot system is - disable HPET in bios and set hw.pci.enable_msix=0 hw.pci.enable_msi=0 We already try different's loader.conf setting like machdep.disable_msix_migration=1 hint.hpet.0.clock=0 hint.hpet.0.per_cpu=0 #hw.pci.enable_msix=0 #hw.pci.enable_msi=0 #dev.igb.1.iflib.disable_msix=1 #dev.igb.0.iflib.disable_msix=1 #machdep.disable_msix_migration = 1 #hw.pci.msix_rewrite_table=1 #hw.pci.honor_msi_blacklist=0 In differents combination with no success. Any suggestion we can try to test? ANy additional information from ower side? Thank you. From owner-freebsd-hackers@freebsd.org Mon Apr 16 13:07:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03A45F818A7 for ; Mon, 16 Apr 2018 13:07:00 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75F0E7938D for ; Mon, 16 Apr 2018 13:06:59 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-wr0-x244.google.com with SMTP id u46so25824137wrc.11 for ; Mon, 16 Apr 2018 06:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rJJ1fv4+G2lUyGS4A6+oQ9GEfUeLmTXVjhFSOAL7XW0=; b=GbwW/lF6CR5D+4gZlaAIrgUgaJ4OIlu7GAJ3RiSTGMFjSpL4Pd50RdG2fQQZ6edxph 3eQeyX2tiPi9fprjBbbXxsL+sceTtYOOFTiMVOMoI59JtF9CrqvjJjFs4NoN6UVI8KY/ c9mf3fN5V5/KEEJJ4NFGn38v7r89MAw8NuyMBDCtzGy74WaKYCD48mNSFAWPs0qGi+h3 mtToHDK9sxPaosLFfQQUVJsXOHzGLhdptJ2SSMFit9NRPHy2isnDDv3KoAgZzpFDJVwT K0NbTw8KhwlHvr7+i4zY34RbRJDnWwHNkHWb3W+S8zmisuPnZ+3FYWchUiuTOtSof+F5 DygA== 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=rJJ1fv4+G2lUyGS4A6+oQ9GEfUeLmTXVjhFSOAL7XW0=; b=E369bt+ZLPEjUylP0JgYaaalQKgxo69bqLX5jrK2VW4JHJ/yoELs8rfyxCIx77Nbqx L7F0u+Y25+drzI6MD0QHcLr7XMjLNpgV2GS2wlZEMsurpP+nwbIPkay4z/NWuroJbrVR q78huU2ikIPWP8gUBaammCJ8H232e55KtyPGf77F3l6scGZVn+dOJIgmp9+//5tuZqZ8 tcbNUVZbrejOzkKe6RkGCijLgbXiRcCoAIecZQyEQdv4ocytncS7gluIBqnliPD0BaB8 MChLPGhKhndb7jCCD1BKIL+maZNPpB5xLRqDz8hflZ25VGjaeFlQJFWZSHdZZGbS18IH 4XKg== X-Gm-Message-State: ALQs6tCvOSd2jTG6xpOPjm7muQieDSi4J+u7jc4ls33Og+ZWwXO/5nHu G/iExNs+QQbnRQHJ5bsZD4yUwAtZpRXdE8tQhxIzdFL4 X-Google-Smtp-Source: AIpwx4/YOy9oMu3zuMMMzXE/Z4Ng6t8xAUGyjsQja3f8UNPwTAQ1cfN7LGEZlrITDowmL/qdo5cUOiEjchPtpuqPSuE= X-Received: by 10.80.153.203 with SMTP id n11mr9097260edb.240.1523884018068; Mon, 16 Apr 2018 06:06:58 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 10.80.208.17 with HTTP; Mon, 16 Apr 2018 06:06:57 -0700 (PDT) X-Originating-IP: [121.73.38.77] In-Reply-To: <20180414180415.GC1774@kib.kiev.ua> References: <20180414180415.GC1774@kib.kiev.ua> From: Thomas Munro Date: Tue, 17 Apr 2018 01:06:57 +1200 X-Google-Sender-Auth: a7gpsiInEwianCHh7OpyzoUoDyg Message-ID: Subject: Re: PROC_SET_PDEATHSIG to get a signal when your parent exits To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 13:07:00 -0000 Hi Konstantin, Thanks for the review! On 15 April 2018 at 06:04, Konstantin Belousov wrote: > On Sat, Apr 14, 2018 at 04:44:51PM +1200, Thomas Munro wrote: >> [...] Should this somehow share >> something with the Linux compat support for prctl(PR_SET_PDEATHSIG, >> ...)? Would people want this? > > Do we support prctl(2) in linuxolator ? Even if yes, I doubt that > there is PR_SET_PDEATHSIG feature. In sys/compat/linux/linux_misc.c there is a linux_prctl() function and it stores the value in em->pdeath_signal, but I don't see any code in the tree that actually does anything with it. >> That tests a few interesting cases I thought of, but note that I >> haven't yet tested 32 bit support or the setuid/getuid logic. > > Compile the test program using "cc -m32 -o test-deathsig-32 ...." > to easily get binary for compat32 testing. It turned out that I needed to modify freebsd32_procctl too. > We have test framework, and several procctl(2) tests already. > Please look at the tests/sys/kern/reaper.c. You might consider > converting your test to the framework and also adding it to the > base system. Done. > Other comments inline. You may create the account at > https://reviews.freebsd.org and putting patch there. Ok. Here is my -v2 patch: https://reviews.freebsd.org/differential/diff/41511/ >> +.It Dv PROC_SET_PDEATHSIG >> +Request the delivery of a signal when the parent of the calling >> +process exits. >> +Use id type P_PID and id 0. > > Use > .Fa id > type > .Dv P_PID > and > .Fa id > 0. Fixed. > In fact, '0' is ok as an alias for the current pid, but not allowing current > pid as the argument is strange. Ok, now it also accepts the caller's PID. > I can see why you only allow the process to set the parent signal only > on itself, but also can see that it does not cost anything to allow > arbitrary pid. I wondered about that, but it seemed a bit strange to allow you to request that *some other* PID should get a signal when *its* parent exits. I think a different interface for "signal me when process X" (not just my parent) might be useful, but that's a different feature. > But I do not see how would pfind(0) return curproc. Don't you need to add > some code for this in kern_procctl() ? No, I just use td->td_proc. If we only support with the current process we don't need to call pfind() at all. >> +The value is cleared for the children >> +of fork() and when executing set-user-ID or set-group-ID binaries. > .Xr fork 2 >> +.Fa arg >> +must point to a value of type int indicating the signal >> +that should be delivered to the caller. Use zero to cancel the > > Start new sentence from the new line. Done. >> +delivery of signals. >> +.It Dv PROC_GET_PDEATHSIG >> +Query the current signal number that will be delivered when the parent >> +of the calling process exits. >> +Use id type P_PID and id 0. > > Same markup. Done. >> + /* Don't inherit PROC_SET_PDEATHSIG value if setuid/setgid. */ >> + if (credential_changing) >> + imgp->proc->p_pdeathsig = 0; >> + > > What is the Linux behaviour on exec ? It seems of negative value to > receive a signal which disposition is reset to default. In other words, > for the non-suid image, you typicall get the process terminated and > perhaps core dumped when parent is exiting. This is the documented Linux behaviour. I'm guessing it's disabled for setuid/setgid because you wouldn't normally be allowed to signal that process so you shouldn't be allowed to request a signal on parent exit (once exec changes the credentials). That seems to make sense. I think in the case of a non-setuid image the point is probably to be able to make it die if the parent dies... It can't really be relying on the exec'd binary installing a signal handler, because the signal might arrive before the binary manages to do that. >> if (credential_changing && >> #ifdef CAPABILITY_MODE >> ((oldcred->cr_flags & CRED_FLAG_CAPMODE) == 0) && >> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c >> index f672a2c7358..55f08a004eb 100644 >> --- a/sys/kern/kern_exit.c >> +++ b/sys/kern/kern_exit.c >> @@ -480,6 +480,12 @@ exit1(struct thread *td, int rval, int signo) >> PROC_LOCK(q->p_reaper); >> pksignal(q->p_reaper, SIGCHLD, ksi1); >> PROC_UNLOCK(q->p_reaper); >> + } else if (q->p_pdeathsig > 0) { >> + /* >> + * The child asked to received a signal >> + * when we exit. >> + */ >> + kern_psignal(q, q->p_pdeathsig); > > Don't you need to lock q around kern_psignal() ? Test your > patch with WITNESS and INVARIANTS kernel options enabled. PROC_LOCK(q) appears above the whole if/else block. Those options were enabled for my testing (I used GENERIC out of the source tree, and they're enabled in there). >> + case PROC_GET_PDEATHSIG: >> + if (idtype != P_PID || id != 0) >> + return (EINVAL); >> + PROC_LOCK(td->td_proc); >> + signum = td->td_proc->p_pdeathsig; >> + PROC_UNLOCK(td->td_proc); >> + *(int *)data = signum; > > Why do you need to mediate assignment through the signum ? Ok, assigned directly to *(int *)data. > Note that the locking around the lone integer assignment is excessive, > but it does not hurt. Ok, I'll leave the locking. >> +#define PROC_SET_PDEATHSIG 11 /* set parent death signal */ >> +#define PROC_GET_PDEATHSIG 12 /* get parent death signal */ > > Note that other commands names follow the pattern > PROC__, > in your case it would be PROC_PDEATHSIG_SET/GET. Changed. > Please use tab after #define. Fixed. From owner-freebsd-hackers@freebsd.org Mon Apr 16 17:27:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4078DF961C1 for ; Mon, 16 Apr 2018 17:27:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C74BB80518 for ; Mon, 16 Apr 2018 17:27:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7E2C3F961BC; Mon, 16 Apr 2018 17:27:45 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AE1CF961BB; Mon, 16 Apr 2018 17:27:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (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 0779A80513; Mon, 16 Apr 2018 17:27:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f45.google.com with SMTP id 19-v6so12584191itw.3; Mon, 16 Apr 2018 10:27:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=DQobMNZ1/DTswlhV1dEpXO8nk3Cdsx15VOKeuC2zI2M=; b=TAOwCqBGvSVBkj8WocuyOy4Yg61hwS0aGv/NW5BaaHMWZmtxbLmSXPvZ8XOEU5UeCZ NIIgNOYzmO/ol5owpuiFyQvtg5+0wvBZ22k4yc1ObcTy5cSSV5ZxONJnCbir45Nrrnl/ 39399MT3gLANLbj7mBeD2ToYLzDuq1qlROJMPyN7gOqGhS+mKu8p/ihO1p848KAjqOGY 9Yp1Jn8D4voxiJYM6HGh8W9C5z6xnvA3pnPiNls+jMOleY7b6N2mmzzzrcmCzcGH+EWM KaJiX9iPdIFjm9t4jzuUt9nzqmJiesp0G0oxlDXJ4HI2ms1E/+4hCMnxddC3FxzBfxDL 1Z/Q== X-Gm-Message-State: ALQs6tD1cmqhFDJASa6auWDQm0PCgZeogWH6s0tSXTA84M5aF/I3I+rw oYLwf+AFs6l6TvY+5hXhJ5/lphxM X-Google-Smtp-Source: AIpwx49HvFnrmWT1Qf4lB99YqdlIpf/8e29XglcbpNK0u2F8g/O4eD66jZTYSaCfTyfMcjYZs+I6Jw== X-Received: by 2002:a24:5f45:: with SMTP id r66-v6mr16269890itb.126.1523899657945; Mon, 16 Apr 2018 10:27:37 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id j197sm1926459ioj.45.2018.04.16.10.27.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 10:27:37 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id a7so3109842ioc.12; Mon, 16 Apr 2018 10:27:37 -0700 (PDT) X-Received: by 10.107.69.23 with SMTP id s23mr19655812ioa.173.1523899657130; Mon, 16 Apr 2018 10:27:37 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.34.77 with HTTP; Mon, 16 Apr 2018 10:27:36 -0700 (PDT) In-Reply-To: <20180416102710.GA90028@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> From: Conrad Meyer Date: Mon, 16 Apr 2018 10:27:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) To: Vitalij Satanivskij Cc: "freebsd-hackers@freebsd.org" , freebsd-current , Stephen Hurd , Sean Bruno , Matthew Macy Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 17:27:46 -0000 Hi Vitalij, On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij wrote: > DUMP can be found here http://hell.ukr.net/panic/panic.jpg > or even video record from screen http://hell.ukr.net/panic/recorder.webm Looks like the panic message is printed directly after: "igb0: using 2 rx queues 2 tx queues" (iflib_msix_init(), called by iflib_device_register()). And stack is indeed coming from iflib in probe (0:17 in linked video): panic() nexus_add_irq() msix_alloc() pci_alloc_msix_method() iflib_device_register() iflib_device_attach() device_attach() ... Stephen, Matt, or Sean might be able to help diagnose further. Best, Conrad From owner-freebsd-hackers@freebsd.org Mon Apr 16 18:23:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4133F9A3E3 for ; Mon, 16 Apr 2018 18:23:51 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48C87697B7 for ; Mon, 16 Apr 2018 18:23:51 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-io0-x230.google.com with SMTP id y128so19192018iod.4 for ; Mon, 16 Apr 2018 11:23: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=tQwA+1BqhMJGWv2+iasYnmWU6cm329qd0CJJtQXE8Gk=; b=oqaWxLbn+xn9b/iugeOWeGtSf2kbTUyQCUOPreFb37E12YOGnHLDmml0eh5X+G6kKD wPm3izoUZCJr7EYkUGvnnUUa4afpSpgQTZNJp28QvW24yN1dN215N66Rvq1OtVrm+nDV ORh3zr3oaSNyE4Q9oD4apLgyOi3uqTb4wFrEQ8RkHafiYfvn2knO7gjRII5kpcsiP87P PLKFuFgzceIgwwnTIYUnVxTYpL/38xgQWfnO/8IICqSWVLahgl74TPJKmaNgVXk27hee yb7F3AOrZeFyfM5+85SofpcbYhrhiCjapATH6EfA+U6WC8G7ufMkUJrYzmX9anQxg24S z7TQ== 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=tQwA+1BqhMJGWv2+iasYnmWU6cm329qd0CJJtQXE8Gk=; b=ou26/9P7x/omXaxrCdb/nwdY7Zi0vQQkeeoH7+tYO99w3roH+l4Q8go7yvZFR07WDa 6HBTOq2kRHks3V557qV3rZVO0XsdmefRwLR92ugu7Xv78/D6OcG0PS59QmHI0etM+rNJ ea8v4BZIgWxA/F45fSTx3Wfyq1nqOLQn+XVQkAAuAwybcXPSVlVBePwxaEQmxc18iIVS gRP24c6XNkHaWXXGFA75gF06QP6wS3uM9XS6ZqznKaDxOzmgNZAzFigkHSo8ZCH7V4RT SmUHBp0JBZB4I2Vmu4Cz7+IP0O9PNYRSMRVbNN5noKCHWQhwXuiupEugxMICQkQn4pIq cGVA== X-Gm-Message-State: ALQs6tCEj643tvAVbwqDgtet0BnkFKCNnnwLwq4HCEcKR4HyhSbDxOyE uGhVEcvzQsQ0l6yRm8hbDxkRWK60qFVjRFhsTSOXX69V X-Google-Smtp-Source: AIpwx48EX6TDxE3uXH+GfFwnqTx88ujsPmA98L3m0sKyuVPHH5MrxoTFlvHTjg5Cl1n0wD2ZdJYVklmvLWl1JKLNlpI= X-Received: by 10.107.82.3 with SMTP id g3mr1934121iob.11.1523903030348; Mon, 16 Apr 2018 11:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.128.233 with HTTP; Mon, 16 Apr 2018 11:23:29 -0700 (PDT) From: Farhan Khan Date: Mon, 16 Apr 2018 14:23:29 -0400 Message-ID: Subject: Merge vale-ctl into ifconfig(8) To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:23:52 -0000 Hi all, I am interested in vale(4) and see the vale-ctl in /usr/src/tools/tools/netmap/vale-ctl.c. Given that it affects interface cards and creates a virtual switch, is it appropriate to merge vale-ctl's behavior into ifconfig? From a cursory code review, vale-ctl opens /dev/netapi whereas ifconfig uses a socket(2). Thoughts? -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE From owner-freebsd-hackers@freebsd.org Mon Apr 16 18:31:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8994EF9AC54 for ; Mon, 16 Apr 2018 18:31:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3D5869C4E for ; Mon, 16 Apr 2018 18:31:53 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w3GIVjtl049085 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Apr 2018 20:31:46 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: khanzf@gmail.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w3GIVfpQ090987 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2018 01:31:41 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Merge vale-ctl into ifconfig(8) To: Farhan Khan , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: <5AD4EC0D.5090607@grosbein.net> Date: Tue, 17 Apr 2018 01:31:41 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=4.7 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 2.5 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:31:54 -0000 17.04.2018 1:23, Farhan Khan wrote: > Hi all, > > I am interested in vale(4) and see the vale-ctl > in /usr/src/tools/tools/netmap/vale-ctl.c. Given that it affects interface > cards and creates a virtual switch, is it appropriate to merge vale-ctl's > behavior into ifconfig? From a cursory code review, vale-ctl opens > /dev/netapi whereas ifconfig uses a socket(2). > > Thoughts? Please don't overweight our already bloated ifconfig. Have you considered etherswitch(4) and etherswitchcfg(8)? From owner-freebsd-hackers@freebsd.org Mon Apr 16 19:12:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20F04F9DE96 for ; Mon, 16 Apr 2018 19:12:18 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A7B306FB73 for ; Mon, 16 Apr 2018 19:12:17 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 617B0F9DE94; Mon, 16 Apr 2018 19:12:17 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C4DCF9DE93; Mon, 16 Apr 2018 19:12:17 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 C8B3F6FB6C; Mon, 16 Apr 2018 19:12:16 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f89Xx-000DyA-9E ; Mon, 16 Apr 2018 22:12:13 +0300 Date: Mon, 16 Apr 2018 22:12:13 +0300 From: Vitalij Satanivskij To: Stephen Hurd Cc: cem@freebsd.org, Vitalij Satanivskij , "freebsd-hackers@freebsd.org" , freebsd-current , Stephen Hurd , Sean Bruno , Matthew Macy Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180416191213.GA53406@hell.ukr.net> Reply-To: satan@ukr.net References: <20180416102710.GA90028@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:12:18 -0000 igb0@pci0:1:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR RO NS link x4(x4) speed 5.0(5.0) ASPM L1(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 ac1f6bffff620e0c ecap 000e[150] = ARI 1 ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled 0 VFs configured out of 8 supported First VF RID Offset 0x0180, VF RID Stride 0x0004 VF Device ID 0x1520 Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304 ecap 0017[1a0] = TPH Requester 1 ecap 0018[1c0] = LTR 1 ecap 000d[1d0] = ACS 1 It's info from system booted with HPET disabled and hw.pci.enable_msix: 0 hw.pci.enable_msi: 0 If one of this parameters not set as described system not boot ^( Stephen Hurd wrote: SH> Hrm, it should be trying to allocate three msi-x vectors there, and it SH> appears that it's reported that 10 are available. What's the output of SH> ``pciconf -lcv pci1:0:0''? SH> SH> On Mon, Apr 16, 2018 at 1:27 PM, Conrad Meyer wrote: SH> SH> > Hi Vitalij, SH> > SH> > On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij SH> > wrote: SH> > > DUMP can be found here http://hell.ukr.net/panic/panic.jpg SH> > > or even video record from screen http://hell.ukr.net/panic/recorder.webm SH> > SH> > Looks like the panic message is printed directly after: "igb0: using 2 SH> > rx queues 2 tx queues" (iflib_msix_init(), called by SH> > iflib_device_register()). SH> > SH> > And stack is indeed coming from iflib in probe (0:17 in linked video): SH> > SH> > panic() SH> > nexus_add_irq() SH> > msix_alloc() SH> > pci_alloc_msix_method() SH> > iflib_device_register() SH> > iflib_device_attach() SH> > device_attach() SH> > ... SH> > SH> > Stephen, Matt, or Sean might be able to help diagnose further. SH> > SH> > Best, SH> > Conrad SH> > SH> SH> SH> SH> -- SH> [image: Limelight Networks] SH> Stephen Hurd* Principal Engineer* SH> EXPERIENCE FIRST. SH> +1 616 848 0643 <+1+616+848+0643> SH> www.limelight.com SH> [image: Facebook] [image: SH> LinkedIn] [image: SH> Twitter] From owner-freebsd-hackers@freebsd.org Mon Apr 16 19:51:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED9E3FA0CB8 for ; Mon, 16 Apr 2018 19:51:32 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 837E373EBB for ; Mon, 16 Apr 2018 19:51:32 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 400CCFA0CAF; Mon, 16 Apr 2018 19:51:32 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18616FA0CAE; Mon, 16 Apr 2018 19:51:32 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 9C09E73EB4; Mon, 16 Apr 2018 19:51:31 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f8A9w-000E2O-Pd ; Mon, 16 Apr 2018 22:51:28 +0300 Date: Mon, 16 Apr 2018 22:51:28 +0300 From: Vitalij Satanivskij To: Stephen Hurd Cc: cem@freebsd.org, Vitalij Satanivskij , "freebsd-hackers@freebsd.org" , freebsd-current , Stephen Hurd , Sean Bruno , Matthew Macy Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180416195128.GA53754@hell.ukr.net> Reply-To: satan@ukr.net References: <20180416102710.GA90028@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:51:33 -0000 Dear Stephen I'm disable msix on igb both 1 and 0 and enable HPET in bios get hpet_attach panic. http://hell.ukr.net/panic/recorder_hpet.webm so i disable hpet again and get msi_alloc and so on http://hell.ukr.net/panic/recorder_msi.webm So for test I'm set hw.pci.enable_msi=0 and get panic in cpp_hw_attach wich autoloaded later wile system run rc scripts panic here - http://hell.ukr.net/panic/recorder_ccp.webm For me it's look like some kind of resource menegment problem? Stephen Hurd wrote: SH> If you disable msix just for igb0, does it crash somewhere else? SH> SH> On Mon, Apr 16, 2018 at 3:13 PM, Stephen Hurd wrote: SH> SH> > Oh, you may need to disable msix to boot... SH> > SH> > dev.igb.0.iflib.disable_msix=1 SH> > SH> > On Mon, Apr 16, 2018 at 3:02 PM, Stephen Hurd wrote: SH> > SH> >> Hrm, it should be trying to allocate three msi-x vectors there, and it SH> >> appears that it's reported that 10 are available. What's the output of SH> >> ``pciconf -lcv pci1:0:0''? SH> >> SH> >> On Mon, Apr 16, 2018 at 1:27 PM, Conrad Meyer wrote: SH> >> SH> >>> Hi Vitalij, SH> >>> SH> >>> On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij SH> >>> wrote: SH> >>> > DUMP can be found here http://hell.ukr.net/panic/panic.jpg SH> >>> > or even video record from screen http://hell.ukr.net/panic/reco SH> >>> rder.webm SH> >>> SH> >>> Looks like the panic message is printed directly after: "igb0: using 2 SH> >>> rx queues 2 tx queues" (iflib_msix_init(), called by SH> >>> iflib_device_register()). SH> >>> SH> >>> And stack is indeed coming from iflib in probe (0:17 in linked video): SH> >>> SH> >>> panic() SH> >>> nexus_add_irq() SH> >>> msix_alloc() SH> >>> pci_alloc_msix_method() SH> >>> iflib_device_register() SH> >>> iflib_device_attach() SH> >>> device_attach() SH> >>> ... SH> >>> SH> >>> Stephen, Matt, or Sean might be able to help diagnose further. SH> >>> SH> >>> Best, SH> >>> Conrad SH> >>> SH> >> SH> >> SH> >> SH> >> -- SH> >> [image: Limelight Networks] SH> >> Stephen Hurd* Principal Engineer* SH> >> EXPERIENCE FIRST. SH> >> +1 616 848 0643 <+1+616+848+0643> SH> >> www.limelight.com SH> >> [image: Facebook] [image: SH> >> LinkedIn] [image: SH> >> Twitter] SH> >> SH> > SH> > SH> > SH> > -- SH> > [image: Limelight Networks] SH> > Stephen Hurd* Principal Engineer* SH> > EXPERIENCE FIRST. SH> > +1 616 848 0643 <+1+616+848+0643> SH> > www.limelight.com SH> > [image: Facebook] [image: SH> > LinkedIn] [image: SH> > Twitter] SH> > SH> SH> SH> SH> -- SH> [image: Limelight Networks] SH> Stephen Hurd* Principal Engineer* SH> EXPERIENCE FIRST. SH> +1 616 848 0643 <+1+616+848+0643> SH> www.limelight.com SH> [image: Facebook] [image: SH> LinkedIn] [image: SH> Twitter] From owner-freebsd-hackers@freebsd.org Mon Apr 16 20:07:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1FAEFA1EA5 for ; Mon, 16 Apr 2018 20:07:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2100175DD7 for ; Mon, 16 Apr 2018 20:07:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3GK7DoV056495 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Apr 2018 23:07:16 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3GK7DoV056495 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3GK7DNA056494; Mon, 16 Apr 2018 23:07:13 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 16 Apr 2018 23:07:13 +0300 From: Konstantin Belousov To: Thomas Munro Cc: freebsd-hackers@freebsd.org Subject: Re: PROC_SET_PDEATHSIG to get a signal when your parent exits Message-ID: <20180416200713.GL1774@kib.kiev.ua> References: <20180414180415.GC1774@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 20:07:26 -0000 On Tue, Apr 17, 2018 at 01:06:57AM +1200, Thomas Munro wrote: > Hi Konstantin, > > Thanks for the review! > > On 15 April 2018 at 06:04, Konstantin Belousov wrote: > > On Sat, Apr 14, 2018 at 04:44:51PM +1200, Thomas Munro wrote: > >> [...] Should this somehow share > >> something with the Linux compat support for prctl(PR_SET_PDEATHSIG, > >> ...)? Would people want this? > > > > Do we support prctl(2) in linuxolator ? Even if yes, I doubt that > > there is PR_SET_PDEATHSIG feature. > > In sys/compat/linux/linux_misc.c there is a linux_prctl() function and > it stores the value in em->pdeath_signal, but I don't see any code in > the tree that actually does anything with it. > > >> That tests a few interesting cases I thought of, but note that I > >> haven't yet tested 32 bit support or the setuid/getuid logic. > > > > Compile the test program using "cc -m32 -o test-deathsig-32 ...." > > to easily get binary for compat32 testing. > > It turned out that I needed to modify freebsd32_procctl too. > > > We have test framework, and several procctl(2) tests already. > > Please look at the tests/sys/kern/reaper.c. You might consider > > converting your test to the framework and also adding it to the > > base system. > > Done. > > > Other comments inline. You may create the account at > > https://reviews.freebsd.org and putting patch there. > > Ok. Here is my -v2 patch: > > https://reviews.freebsd.org/differential/diff/41511/ You did not created a review. You only uploaded the diff, but there are more steps after the 'create' button. In particular, you put the description of the patch there, and assign reviewers. Put kib@freebsd.org for the start. Also, your diff lacks context information, so the review is even less useful than the patch in the mail. Please use 'svn diff -x -U999999' command when generating the diff for upload. > > >> +.It Dv PROC_SET_PDEATHSIG > >> +Request the delivery of a signal when the parent of the calling > >> +process exits. > >> +Use id type P_PID and id 0. > > > > Use > > .Fa id > > type > > .Dv P_PID > > and > > .Fa id > > 0. > > Fixed. > > > In fact, '0' is ok as an alias for the current pid, but not allowing current > > pid as the argument is strange. > > Ok, now it also accepts the caller's PID. > > > I can see why you only allow the process to set the parent signal only > > on itself, but also can see that it does not cost anything to allow > > arbitrary pid. > > I wondered about that, but it seemed a bit strange to allow you to > request that *some other* PID should get a signal when *its* parent > exits. I think a different interface for "signal me when process X" > (not just my parent) might be useful, but that's a different feature. Ok. > > > But I do not see how would pfind(0) return curproc. Don't you need to add > > some code for this in kern_procctl() ? > > No, I just use td->td_proc. If we only support with the current > process we don't need to call pfind() at all. Ok. > > >> +The value is cleared for the children > >> +of fork() and when executing set-user-ID or set-group-ID binaries. > > .Xr fork 2 > >> +.Fa arg > >> +must point to a value of type int indicating the signal > >> +that should be delivered to the caller. Use zero to cancel the > > > > Start new sentence from the new line. > > Done. > > >> +delivery of signals. > >> +.It Dv PROC_GET_PDEATHSIG > >> +Query the current signal number that will be delivered when the parent > >> +of the calling process exits. > >> +Use id type P_PID and id 0. > > > > Same markup. > > Done. > > >> + /* Don't inherit PROC_SET_PDEATHSIG value if setuid/setgid. */ > >> + if (credential_changing) > >> + imgp->proc->p_pdeathsig = 0; > >> + > > > > What is the Linux behaviour on exec ? It seems of negative value to > > receive a signal which disposition is reset to default. In other words, > > for the non-suid image, you typicall get the process terminated and > > perhaps core dumped when parent is exiting. > > This is the documented Linux behaviour. I'm guessing it's disabled > for setuid/setgid because you wouldn't normally be allowed to signal > that process so you shouldn't be allowed to request a signal on parent > exit (once exec changes the credentials). That seems to make sense. > > I think in the case of a non-setuid image the point is probably to be > able to make it die if the parent dies... It can't really be relying > on the exec'd binary installing a signal handler, because the signal > might arrive before the binary manages to do that. It is still strange, but if this is the Linux behaviour, I would close eyes and accept it to not make consumers handle the difference. > > >> if (credential_changing && > >> #ifdef CAPABILITY_MODE > >> ((oldcred->cr_flags & CRED_FLAG_CAPMODE) == 0) && > >> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > >> index f672a2c7358..55f08a004eb 100644 > >> --- a/sys/kern/kern_exit.c > >> +++ b/sys/kern/kern_exit.c > >> @@ -480,6 +480,12 @@ exit1(struct thread *td, int rval, int signo) > >> PROC_LOCK(q->p_reaper); > >> pksignal(q->p_reaper, SIGCHLD, ksi1); > >> PROC_UNLOCK(q->p_reaper); > >> + } else if (q->p_pdeathsig > 0) { > >> + /* > >> + * The child asked to received a signal > >> + * when we exit. > >> + */ > >> + kern_psignal(q, q->p_pdeathsig); > > > > Don't you need to lock q around kern_psignal() ? Test your > > patch with WITNESS and INVARIANTS kernel options enabled. > > PROC_LOCK(q) appears above the whole if/else block. This is what I do not see in the patch with limited context, unless I start reading by applying. > > Those options were enabled for my testing (I used GENERIC out of the > source tree, and they're enabled in there). > > >> + case PROC_GET_PDEATHSIG: > >> + if (idtype != P_PID || id != 0) > >> + return (EINVAL); > >> + PROC_LOCK(td->td_proc); > >> + signum = td->td_proc->p_pdeathsig; > >> + PROC_UNLOCK(td->td_proc); > >> + *(int *)data = signum; > > > > Why do you need to mediate assignment through the signum ? > > Ok, assigned directly to *(int *)data. > > > Note that the locking around the lone integer assignment is excessive, > > but it does not hurt. > > Ok, I'll leave the locking. > > >> +#define PROC_SET_PDEATHSIG 11 /* set parent death signal */ > >> +#define PROC_GET_PDEATHSIG 12 /* get parent death signal */ > > > > Note that other commands names follow the pattern > > PROC__, > > in your case it would be PROC_PDEATHSIG_SET/GET. > > Changed. > > > Please use tab after #define. > > Fixed. From owner-freebsd-hackers@freebsd.org Mon Apr 16 20:26:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1113AFA3158 for ; Mon, 16 Apr 2018 20:26:48 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8F57779D5C for ; Mon, 16 Apr 2018 20:26:47 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 4CE5CFA3145; Mon, 16 Apr 2018 20:26:47 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AEA6FA3144; Mon, 16 Apr 2018 20:26:47 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 B201779D33; Mon, 16 Apr 2018 20:26:46 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f8Ai3-000E76-8W ; Mon, 16 Apr 2018 23:26:43 +0300 Date: Mon, 16 Apr 2018 23:26:43 +0300 From: Vitalij Satanivskij To: Stephen Hurd Cc: Vitalij Satanivskij , cem@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-current , Stephen Hurd , Sean Bruno , Matthew Macy Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180416202643.GA54226@hell.ukr.net> Reply-To: satan@ukr.net References: <20180416102710.GA90028@hell.ukr.net> <20180416195128.GA53754@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 20:26:48 -0000 Oh bios. It's already lastest bios for now with agesa 1.0.0.5 in it. It's dated 2/14/2018 So most likely new version will not appear soon Stephen Hurd wrote: SH> Yeah, this looks like some sort of general MSI issue, not igb specific. SH> I'm not familiar with that part of the kernel, but maybe check if there's a SH> BIOS update available? SH> SH> On Mon, Apr 16, 2018 at 3:51 PM, Vitalij Satanivskij wrote: SH> SH> > Dear Stephen SH> > SH> > I'm disable msix on igb both 1 and 0 SH> > and enable HPET in bios SH> > SH> > get hpet_attach panic. http://hell.ukr.net/panic/recorder_hpet.webm SH> > so i disable hpet again and get msi_alloc and so on SH> > http://hell.ukr.net/panic/recorder_msi.webm SH> > SH> > So for test I'm set hw.pci.enable_msi=0 and get panic in cpp_hw_attach SH> > wich autoloaded later wile system run rc scripts SH> > SH> > panic here - http://hell.ukr.net/panic/recorder_ccp.webm SH> > SH> > For me it's look like some kind of resource menegment problem? SH> > SH> > SH> > Stephen Hurd wrote: SH> > SH> If you disable msix just for igb0, does it crash somewhere else? SH> > SH> SH> > SH> On Mon, Apr 16, 2018 at 3:13 PM, Stephen Hurd wrote: SH> > SH> SH> > SH> > Oh, you may need to disable msix to boot... SH> > SH> > SH> > SH> > dev.igb.0.iflib.disable_msix=1 SH> > SH> > SH> > SH> > On Mon, Apr 16, 2018 at 3:02 PM, Stephen Hurd SH> > wrote: SH> > SH> > SH> > SH> >> Hrm, it should be trying to allocate three msi-x vectors there, and SH> > it SH> > SH> >> appears that it's reported that 10 are available. What's the SH> > output of SH> > SH> >> ``pciconf -lcv pci1:0:0''? SH> > SH> >> SH> > SH> >> On Mon, Apr 16, 2018 at 1:27 PM, Conrad Meyer SH> > wrote: SH> > SH> >> SH> > SH> >>> Hi Vitalij, SH> > SH> >>> SH> > SH> >>> On Mon, Apr 16, 2018 at 3:27 AM, Vitalij Satanivskij < SH> > satan@ukr.net> SH> > SH> >>> wrote: SH> > SH> >>> > DUMP can be found here http://hell.ukr.net/panic/panic.jpg SH> > SH> >>> > or even video record from screen http://hell.ukr.net/panic/reco SH> > SH> >>> rder.webm SH> > SH> >>> SH> > SH> >>> Looks like the panic message is printed directly after: "igb0: SH> > using 2 SH> > SH> >>> rx queues 2 tx queues" (iflib_msix_init(), called by SH> > SH> >>> iflib_device_register()). SH> > SH> >>> SH> > SH> >>> And stack is indeed coming from iflib in probe (0:17 in linked SH> > video): SH> > SH> >>> SH> > SH> >>> panic() SH> > SH> >>> nexus_add_irq() SH> > SH> >>> msix_alloc() SH> > SH> >>> pci_alloc_msix_method() SH> > SH> >>> iflib_device_register() SH> > SH> >>> iflib_device_attach() SH> > SH> >>> device_attach() SH> > SH> >>> ... SH> > SH> >>> SH> > SH> >>> Stephen, Matt, or Sean might be able to help diagnose further. SH> > SH> >>> SH> > SH> >>> Best, SH> > SH> >>> Conrad SH> > SH> >>> SH> > SH> >> SH> > SH> >> SH> > SH> >> SH> > SH> >> -- SH> > SH> >> [image: Limelight Networks] SH> > SH> >> Stephen Hurd* Principal Engineer* SH> > SH> >> EXPERIENCE FIRST. SH> > SH> >> +1 616 848 0643 <+1+616+848+0643> SH> > SH> >> www.limelight.com SH> > SH> >> [image: Facebook] > >[image: SH> > SH> >> LinkedIn] [ SH> > image: SH> > SH> >> Twitter] SH> > SH> >> SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > -- SH> > SH> > [image: Limelight Networks] SH> > SH> > Stephen Hurd* Principal Engineer* SH> > SH> > EXPERIENCE FIRST. SH> > SH> > +1 616 848 0643 <+1+616+848+0643> SH> > SH> > www.limelight.com SH> > SH> > [image: Facebook] > >[image: SH> > SH> > LinkedIn] [ SH> > image: SH> > SH> > Twitter] SH> > SH> > SH> > SH> SH> > SH> SH> > SH> SH> > SH> -- SH> > SH> [image: Limelight Networks] SH> > SH> Stephen Hurd* Principal Engineer* SH> > SH> EXPERIENCE FIRST. SH> > SH> +1 616 848 0643 <+1+616+848+0643> SH> > SH> www.limelight.com SH> > SH> [image: Facebook] [image: SH> > SH> LinkedIn] [image: SH> > SH> Twitter] SH> > SH> SH> SH> SH> -- SH> [image: Limelight Networks] SH> Stephen Hurd* Principal Engineer* SH> EXPERIENCE FIRST. SH> +1 616 848 0643 <+1+616+848+0643> SH> www.limelight.com SH> [image: Facebook] [image: SH> LinkedIn] [image: SH> Twitter] From owner-freebsd-hackers@freebsd.org Mon Apr 16 20:30:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10CDBFA3528 for ; Mon, 16 Apr 2018 20:30:19 +0000 (UTC) (envelope-from munro@penski.net) 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 7B0DA7B1D7 for ; Mon, 16 Apr 2018 20:30:18 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-wr0-x236.google.com with SMTP id l49so29536376wrl.4 for ; Mon, 16 Apr 2018 13:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZiIvnvjDKkXvKGk27uuHkvA6PK3STdqtUeaOUfPJ9Ds=; b=jOY5yy7HGfxHy2qvLl/a5W7FkObieoWCY7R8hdpov8hcrtAXs3EaA2ZyRUWC1GI159 k9IeKYs1QbmrsIO+UhrScDlm8aMNQ/BZ/N0RxnxmM7fAseUtkeNSTT/Wbt+PSZtD1inw QD//Z5IlKBSG2pUzyprEhgXVk6cBxeuUD9ZUY9Ne8s4e7yZXVvGpidlIEEcVHgVmajRJ SABeTUxSBpuBLd57lhxvv1A7t5Nuc07EnWZbN1cF3V+ec7XwqYZLtSr0vXwBrhRWvBmx mXyld8MJBWUnnJxhwijUQ/nRWxkHfuuAPoYiMQdE6itFA2hiPmf64QojKTZEtEb+TDXu Xs4g== 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=ZiIvnvjDKkXvKGk27uuHkvA6PK3STdqtUeaOUfPJ9Ds=; b=rwCK0PPKwVaqYO+uJSuMhdbn0tKx/OJZb2+nuytQE6Oe97aAKFyp2K//LQpSgThHXo mZrdlwTi9U1+iH5fSeRDMV7hQElZdov8cP3fnE1SXaVhug9PaAicj7hb4Kkbhw62DjXh BpdSPfWCA2qbg61T3fbyLqQQv99uaTERKYVHJ0j82PNZcEFUfAIfLx/vn3WgXrejV+jZ cvGDKFasBS/NlBaX1ZcUL5InMnHRY3jWhY5+ZQl1oPQhCYoE3fML0oZBz8Nvgib0g6+K BRgpfG+K8CkmmOuM5YJ+hQL4bPCAD2xSa/VttflE3DN9WrEo4pdsXyS7AkjOSCJ+c4xs 6jUQ== X-Gm-Message-State: ALQs6tAilGtau7zP1B3q8eXa9rIrH2f4TR52CUuOXPtfEVg3/zi4Oq3q oIkXokr/qVZphGd0Y8p5D+hvH7nzVRCmSJuNqG05Og== X-Google-Smtp-Source: AIpwx48HR0VGfcYf4cePv2tu7Ie91tbsx57t1kSdgSKd/y0NFRDhFwIa2u6ECoeq3KvmpBDDzRT7Cr5QayREiFc0f/Y= X-Received: by 10.80.178.102 with SMTP id o93mr32848725edd.228.1523910616602; Mon, 16 Apr 2018 13:30:16 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 10.80.208.17 with HTTP; Mon, 16 Apr 2018 13:30:16 -0700 (PDT) X-Originating-IP: [121.73.38.77] In-Reply-To: <20180416200713.GL1774@kib.kiev.ua> References: <20180414180415.GC1774@kib.kiev.ua> <20180416200713.GL1774@kib.kiev.ua> From: Thomas Munro Date: Tue, 17 Apr 2018 08:30:16 +1200 X-Google-Sender-Auth: Z0U8bpY6E4M_LOBaGl_a9i0Q2Ko Message-ID: Subject: Re: PROC_SET_PDEATHSIG to get a signal when your parent exits To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 20:30:19 -0000 On 17 April 2018 at 08:07, Konstantin Belousov wrote: > On Tue, Apr 17, 2018 at 01:06:57AM +1200, Thomas Munro wrote: >> Ok. Here is my -v2 patch: >> >> https://reviews.freebsd.org/differential/diff/41511/ > > You did not created a review. You only uploaded the diff, but there > are more steps after the 'create' button. In particular, you put > the description of the patch there, and assign reviewers. Put > kib@freebsd.org for the start. > > Also, your diff lacks context information, so the review is even less > useful than the patch in the mail. Please use 'svn diff -x -U999999' > command when generating the diff for upload. Ah, I see. Done: https://reviews.freebsd.org/D15106 From owner-freebsd-hackers@freebsd.org Mon Apr 16 21:23:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 770ACFA6AA9 for ; Mon, 16 Apr 2018 21:23:07 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 1913F866C6 for ; Mon, 16 Apr 2018 21:23:07 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-it0-x236.google.com with SMTP id m134-v6so13304769itb.3 for ; Mon, 16 Apr 2018 14:23:06 -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=l0v3YHIZp+rNakg6pKsDMcLEaCxnhoTYlHbLwlr1CSE=; b=uhLAUodKQAbaVaSM5IJXg5IB/NLlA/G2Pht0GqRI8lNTXrj9TqcEJ2Y6+WCiJLdo2K C1f5DrsvIEhkO1Hf8Cgy1k7m2FKMqn3WKECEE68iYcjVfeBXpp0mb221TI8NvPN6IkfY czo3iUtuvr9tgJjJTEwd05ihrZ/EDacMT4r+kvDCIdHfCnz6tuNz7Pj5xK8FnfzV4FbX R/zdo+rqquOYPor+NMN7aqZqpoKz2wUYd+NlzJSlC3lAaY2ZBWTiJKwwL4/c5H7CH/SU +bHz7uv6awa0De7sBt7XtUfpPdP7dn5IysoLb6Mbixogq9BanQw0ciXjavkJ0sIrxq1j 6HcQ== 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=l0v3YHIZp+rNakg6pKsDMcLEaCxnhoTYlHbLwlr1CSE=; b=detkZj405kwZ2vef98cwMLgFqrRCWvyjrlCK3BbpbAK19H7+1sI6MvOyZrohG7LYYF QFn7SIHIHIM3pHfKK3TpjeWoPJ1gCirNGp8OXPlqLdCdbSqAnC2VPK+oCBv++54iW0yv gYzF7XlvUqzFq+ETD6NtQcFC97Y4Tb+2GGoYRT1tynGvXGY2EE2Rm1UeaWGMqgHkhsjb b3SnO4ci5pvey7JGuHe2CoOnkm8Tb8K7tjErWYozV+c53dokw0toW8EsK0JmZSpOgjLk yTIYx63BGkXeg0WU5jGGaFg++pdwf9BTvY/wNNFTRKeCo+sl4bc4WsIDLGKLjEOcnv6f wR4w== X-Gm-Message-State: ALQs6tB1tpxSueSjy/ygngZ8zR21TllcEqY1XMDWKNYKt3e909ywqzxY HbtDg2Un8P9yg7E0cF2i1MdTm3kgPp70nuqO2HA= X-Google-Smtp-Source: AIpwx48cfIWT9T8vNn1CbVAXe6QGwG2ymrmk2vzWCNC+HGgjCMiINui+7xcQO7MmpS8TQ7MON1TkjCPF5fYzDV8hOEc= X-Received: by 2002:a24:19c9:: with SMTP id b192-v6mr16861067itb.1.1523913786343; Mon, 16 Apr 2018 14:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Mon, 16 Apr 2018 14:23:05 -0700 (PDT) From: Dieter BSD Date: Mon, 16 Apr 2018 14:23:05 -0700 Message-ID: Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:23:07 -0000 Built a kernel with Realtek's Ethernet driver. The 8111E & 8111F work, although initial testing using nc(1) is being a bit strange. 1st testing window: re0 I tried the same copy a 28 GB file using nc(1) and udp. The 1st & 3rd try gave the correct number of bytes, but the 2nd try was short. The other 2 ports (re1 re2) worked less well. 2nd testing window: re0 (8111F on Syba 2 port PCIe card [1]) 6 times 28 GB file using nc and udp 3 "plain" and 3 with -T reliability 1 "plain" copy worked correctly, the other 5 were short re1 (2nd 8111F port on PCIe card) all 5 attempts were short, 3 of 5 were very short: 28132560000 goal 27982918784 big_file_copied_via_udp_re1_0 27981835392 big_file_copied_via_udp_re1_1 587776 big_file_copied_via_udp_re1_2 608256 big_file_copied_via_udp_re1_3 606208 big_file_copied_via_udp_re1_Trel_0 re2 (8111E on UD5 mainboard) all 6 attempts were short 32452608 big_file_copied_via_udp_re2rt_0 3932160 big_file_copied_via_udp_re2rt_1 399364096 big_file_copied_via_udp_re2_Trel_0 5963776 big_file_copied_via_udp_re2_Trel_1 4159488 big_file_copied_via_udp_re2_Trel_2 4827136 big_file_copied_via_udp_re2_2 28132560000 goal One burst and then it fails: input re2 output packets errs idrops bytes packets errs bytes colls 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3840 0 0 4078080 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 For real world use, so far the Realtek driver is working at least as well as the stock FreeBSD 10.3 driver, probably better. But it does lose data with real world applications, (2 separate incidents so far) so it needs improvement. Some of the test results with nc(1) are kinda screwy. Maybe nc is the wrong tool, maybe I'm using it wrong, I don't know. Has anyone tried similar testing? Suggestions of knobs to turn, or other things to try? I need to receive data via UDP without dropping packets. Closed source sucks, but I'm stuck with it, and thus with UDP. [1] http://www.sybausa.com/index.php?route=product/product&manufacturer_id=11&product_id=130&page=25 $21.22 From owner-freebsd-hackers@freebsd.org Tue Apr 17 07:30:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7C19F88978 for ; Tue, 17 Apr 2018 07:30:47 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout01.t-online.de (mailout01.t-online.de [194.25.134.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 639B075700 for ; Tue, 17 Apr 2018 07:30:47 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd40.aul.t-online.de (fwd40.aul.t-online.de [172.20.26.139]) by mailout01.t-online.de (Postfix) with SMTP id EBC4442CE9DB; Tue, 17 Apr 2018 09:30:39 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (SODx4oZDohH4jw-2CEVmKU+YdK2xh0-7ZQQs-UH1EYmVTWRru6WDYgI57cAf8gfQWh@[84.154.107.172]) by fwd40.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f8L4X-0FqEhE0; Tue, 17 Apr 2018 09:30:37 +0200 Subject: Re: Realtek re(4) driver References: From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Cc: freebsd-hackers@freebsd.org To: Dieter BSD Message-ID: <364c2505-ffac-c213-6c95-048b02212ffb@freebsd.org> Date: Tue, 17 Apr 2018 09:30:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: SODx4oZDohH4jw-2CEVmKU+YdK2xh0-7ZQQs-UH1EYmVTWRru6WDYgI57cAf8gfQWh X-TOI-MSGID: 5451da2d-3c8b-4bbf-a5fa-b077f3e00c90 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 07:30:48 -0000 Am 16.04.18 um 23:23 schrieb Dieter BSD: > test results with nc(1) are kinda screwy. Maybe nc is the > wrong tool, maybe I'm using it wrong, I don't know. > > Has anyone tried similar testing? > Suggestions of knobs to turn, or other things to try? > > I need to receive data via UDP without dropping packets. Closed source sucks, > but I'm stuck with it, and thus with UDP. Well, but you know that the U in UDP means unreliable? On a non-congested link, UDP packets should arrive at the receiver, but the application has to deal with packet loss, since it cannot be sure that it is used on a reliable link. Packet loss will cause reduced throughput (as with TCP), unless it can be dealt with by FEC or other means (which also reduce throughput). Regards, STefan From owner-freebsd-hackers@freebsd.org Tue Apr 17 16:31:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A072F883FF for ; Tue, 17 Apr 2018 16:31:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 055D477338 for ; Tue, 17 Apr 2018 16:31:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B0DE4F883FD; Tue, 17 Apr 2018 16:31:46 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E501F883FC; Tue, 17 Apr 2018 16:31:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5008E77318; Tue, 17 Apr 2018 16:31:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 2743C10AFCD; Tue, 17 Apr 2018 12:31:45 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, satan@ukr.net Cc: Stephen Hurd , cem@freebsd.org, "freebsd-hackers@freebsd.org" , Stephen Hurd , Sean Bruno , Matthew Macy Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Date: Tue, 17 Apr 2018 09:25:46 -0700 Message-ID: <3723755.0KMZDfyMWu@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180416191213.GA53406@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <20180416191213.GA53406@hell.ukr.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 17 Apr 2018 12:31:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 16:31:47 -0000 On Monday, April 16, 2018 10:12:13 PM Vitalij Satanivskij wrote: > > igb0@pci0:1:0:0: class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I350 Gigabit Network Connection' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 10 messages > Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] > cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR RO NS > link x4(x4) speed 5.0(5.0) ASPM L1(L0s/L1) > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected > ecap 0003[140] = Serial 1 ac1f6bffff620e0c > ecap 000e[150] = ARI 1 > ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled > 0 VFs configured out of 8 supported > First VF RID Offset 0x0180, VF RID Stride 0x0004 > VF Device ID 0x1520 > Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304 > ecap 0017[1a0] = TPH Requester 1 > ecap 0018[1c0] = LTR 1 > ecap 000d[1d0] = ACS 1 > > It's info from system booted with HPET disabled and > hw.pci.enable_msix: 0 > hw.pci.enable_msi: 0 > > If one of this parameters not set as described system not boot ^( Please try the patch from here https://reviews.freebsd.org/P165 -- John Baldwin From owner-freebsd-hackers@freebsd.org Tue Apr 17 19:16:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EF11F934D6 for ; Tue, 17 Apr 2018 19:16:10 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 106937F94C for ; Tue, 17 Apr 2018 19:16:07 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 06327F934B7; Tue, 17 Apr 2018 19:16:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E89F4F934B6; Tue, 17 Apr 2018 19:16:06 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 D0CC27F883; Tue, 17 Apr 2018 19:16:03 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f8W53-000PE3-UV ; Tue, 17 Apr 2018 22:15:53 +0300 Date: Tue, 17 Apr 2018 22:15:53 +0300 From: Vitalij Satanivskij To: John Baldwin Cc: freebsd-current@freebsd.org, satan@ukr.net, cem@freebsd.org, Stephen Hurd , Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180417191553.GA95803@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <20180416191213.GA53406@hell.ukr.net> <3723755.0KMZDfyMWu@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3723755.0KMZDfyMWu@ralph.baldwin.cx> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 19:16:10 -0000 Dear John I'm try patch with no success http://hell.ukr.net/panic/recorder_patch165.webm Also I'm enable verbose boot and record boot process (hpet was disabled so crash in another driver atach) http://hell.ukr.net/panic/recorder_patch_verbose.webm root@test:/usr/src # svnlite diff Index: sys/x86/x86/msi.c =================================================================== --- sys/x86/x86/msi.c (revision 332650) +++ sys/x86/x86/msi.c (working copy) @@ -404,7 +404,7 @@ /* Do we need to create some new sources? */ if (cnt < count) { /* If we would exceed the max, give up. */ - if (i + (count - cnt) > FIRST_MSI_INT + NUM_MSI_INTS) { + if (i + (count - cnt) >= FIRST_MSI_INT + NUM_MSI_INTS) { mtx_unlock(&msi_lock); free(mirqs, M_MSI); return (ENXIO); @@ -645,7 +645,7 @@ /* Do we need to create a new source? */ if (msi == NULL) { /* If we would exceed the max, give up. */ - if (i + 1 > FIRST_MSI_INT + NUM_MSI_INTS) { + if (i + 1 >= FIRST_MSI_INT + NUM_MSI_INTS) { mtx_unlock(&msi_lock); return (ENXIO); } root@test:/usr/src If you need any aditional information please tell me about. JB> > If one of this parameters not set as described system not boot ^( JB> JB> Please try the patch from here https://reviews.freebsd.org/P165 JB> JB> -- JB> John Baldwin JB> _______________________________________________ JB> freebsd-hackers@freebsd.org mailing list JB> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers JB> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Apr 17 21:21:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32666F9C2D7 for ; Tue, 17 Apr 2018 21:21:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4FDD7F6B4 for ; Tue, 17 Apr 2018 21:21:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 85937F9C2D5; Tue, 17 Apr 2018 21:21:10 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7312DF9C2D4; Tue, 17 Apr 2018 21:21:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2690F7F6AE; Tue, 17 Apr 2018 21:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 4BD8D10AFAD; Tue, 17 Apr 2018 17:21:02 -0400 (EDT) From: John Baldwin To: Vitalij Satanivskij Cc: freebsd-current@freebsd.org, cem@freebsd.org, Stephen Hurd , Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Date: Tue, 17 Apr 2018 13:42:19 -0700 Message-ID: <3628282.XVdngBdGlp@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180417191553.GA95803@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <3723755.0KMZDfyMWu@ralph.baldwin.cx> <20180417191553.GA95803@hell.ukr.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 17 Apr 2018 17:21:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 21:21:11 -0000 On Tuesday, April 17, 2018 10:15:53 PM Vitalij Satanivskij wrote: > Dear John > > I'm try patch with no success > > http://hell.ukr.net/panic/recorder_patch165.webm > > Also I'm enable verbose boot and record boot process (hpet was disabled so crash in another driver atach) > http://hell.ukr.net/panic/recorder_patch_verbose.webm > > root@test:/usr/src # svnlite diff > Index: sys/x86/x86/msi.c > =================================================================== > --- sys/x86/x86/msi.c (revision 332650) > +++ sys/x86/x86/msi.c (working copy) > @@ -404,7 +404,7 @@ > /* Do we need to create some new sources? */ > if (cnt < count) { > /* If we would exceed the max, give up. */ > - if (i + (count - cnt) > FIRST_MSI_INT + NUM_MSI_INTS) { > + if (i + (count - cnt) >= FIRST_MSI_INT + NUM_MSI_INTS) { > mtx_unlock(&msi_lock); > free(mirqs, M_MSI); > return (ENXIO); > @@ -645,7 +645,7 @@ > /* Do we need to create a new source? */ > if (msi == NULL) { > /* If we would exceed the max, give up. */ > - if (i + 1 > FIRST_MSI_INT + NUM_MSI_INTS) { > + if (i + 1 >= FIRST_MSI_INT + NUM_MSI_INTS) { > mtx_unlock(&msi_lock); > return (ENXIO); > } > root@test:/usr/src > > If you need any aditional information please tell me about. Can you perhaps turn off the stack trace on boot to not lose the panic messages (remove KDB_TRACE from kernel config) and maybe modify the panic message to include the IRQ number passed to nexus_add_irq? -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Apr 18 05:15:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0046F91522 for ; Wed, 18 Apr 2018 05:15:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49F0A816F4 for ; Wed, 18 Apr 2018 05:15:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w3I5FCqq029238 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 Apr 2018 22:15:15 -0700 (PDT) (envelope-from julian@freebsd.org) To: FreeBSD Hackers From: Julian Elischer Subject: us report on russian hacking Message-ID: Date: Wed, 18 Apr 2018 13:15:07 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:15:17 -0000 This is a LOT more specific than I'd expected... https://www.us-cert.gov/ncas/alerts/TA18-106A From owner-freebsd-hackers@freebsd.org Wed Apr 18 07:36:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDDD9F9A29F for ; Wed, 18 Apr 2018 07:36:17 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward1o.cmail.yandex.net (forward1o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::2a1]) (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 65B247EC90; Wed, 18 Apr 2018 07:36:16 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback5g.mail.yandex.net (mxback5g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:166]) by forward1o.cmail.yandex.net (Yandex) with ESMTP id 21CBF2145A; Wed, 18 Apr 2018 10:36:14 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback5g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 9NTFQ1x47U-aDfqmrjr; Wed, 18 Apr 2018 10:36:13 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1524036973; bh=5+Hi8Wczf/FxfkfHF/FS5OMhgjwKuY4nOo6p9HpiiMY=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=GCYWtcrUatLtYOvTR6R8otK0QZKW8FsmT0MyhitU/D44WmU1GcnUzxCxNtkUzIIHP 7Qovs9Rc2GfsncZKIe52jmwEZJRMJlBcffBihNqjwYsTz5jZKBFvjD09li7STDDiIN k/lviCjB8mzKy344n97muMAs2+j83E42jXeSuWXA= Authentication-Results: mxback5g.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web25o.yandex.ru with HTTP; Wed, 18 Apr 2018 10:36:13 +0300 From: Alexander V. Chernikov To: Julian Elischer , FreeBSD Hackers In-Reply-To: References: Subject: Re: us report on russian hacking MIME-Version: 1.0 Message-Id: <3951901524036973@web25o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 18 Apr 2018 10:36:13 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 07:36:18 -0000 18.04.2018, 08:19, "Julian Elischer" : > This is a LOT more specific than I'd expected... Is it? This is basically a combination of the popular cisco bug description with the "Network router security 101" guidelines. If you do s/Russia/US/g (or any other country) it can be treated with the same level of confidence - because the statements there are either too broad or totally unprovable. > > https://www.us-cert.gov/ncas/alerts/TA18-106A > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Apr 18 07:58:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6787F9BED1 for ; Wed, 18 Apr 2018 07:58:10 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from smh-06.1blu.de (smh-06.1blu.de [178.254.0.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49CE782219; Wed, 18 Apr 2018 07:58:09 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [172.16.29.5] (helo=sh4-5.1blu.de) by smh-06.1blu.de with esmtp (Exim 4.86_2) (envelope-from ) id 1f8hyh-0003q1-E6; Wed, 18 Apr 2018 09:58:07 +0200 Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.86_2) (envelope-from ) id 1f8hyh-00063Q-BE; Wed, 18 Apr 2018 09:58:07 +0200 Date: Wed, 18 Apr 2018 09:58:07 +0200 From: Matthias Apitz To: "Alexander V. Chernikov" Cc: Julian Elischer , FreeBSD Hackers Subject: Re: us report on russian hacking Message-ID: <20180418075807.GA18424@sh4-5.1blu.de> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , "Alexander V. Chernikov" , Julian Elischer , FreeBSD Hackers References: <3951901524036973@web25o.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3951901524036973@web25o.yandex.ru> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 07:58:10 -0000 El día Wednesday, April 18, 2018 a las 10:36:13AM +0300, Alexander V. Chernikov escribió: > 18.04.2018, 08:19, "Julian Elischer" : > > This is a LOT more specific than I'd expected... > Is it? > This is basically a combination of the popular cisco bug description with the "Network router security 101" guidelines. > If you do s/Russia/US/g (or any other country) it can be treated with the same level of confidence - because the statements there are either too broad or totally unprovable. > +1 This is only, after Skripal and the "chemical attack" in Syria, the next round of Russian bashing to prepare our folks for a real war against Russia. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From owner-freebsd-hackers@freebsd.org Wed Apr 18 09:27:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3216FFA2BE1 for ; Wed, 18 Apr 2018 09:27:38 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 9FA3A77FAF; Wed, 18 Apr 2018 09:27:37 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id q6-v6so2859993wrd.6; Wed, 18 Apr 2018 02:27:37 -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=9mAwNM1QBERncpiupNbc6+s/dL4ITiyfFNqDFvueF1g=; b=L2iLJRhXRoHTHBEHQY0pl7+c8HhJ8NqZ8X04n8oi49zQXuHAVOqHfqXo3sD6bqX50c QdsBg3PZ3IqQbQfvyIbCz8AeXiqbJYTVltYopo7Kg70kKIWZFCU5rGjy2qRYweN+Un6X 6/C/XNO7syslwYaLnmvHYIlEGaX5plusvZbpHY1B045eCC22NEtRvx/mHyGWucv1/pD+ 1jS0Q65IDEZYDgyur6JZ9+gD2jfMEjNu2yCsnwz7cc0kq9+qhxAuqr91cRZ2ZB86vY3Z giDZGOA28JQNffKyrvbXUcv107Mb/ONQ9tjstrDHaDo1i8WWAbDwPcfxWwzqblkETl17 JZbA== 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=9mAwNM1QBERncpiupNbc6+s/dL4ITiyfFNqDFvueF1g=; b=QcvX3hChjTDQPWaflD953fzdGAfOL/jOjf2XFj2aUJnGMbw945kZ/ezqOeXOOVtXAl vJfvd9XfqGdHYI9ltZLoipBwH08ZPiDooNb2u+OtEf2trM3beRZBamRMgeuP2B5YaDJm rIfsUdeCeX14fU/KJdQ4SDXIGn19nLy/V5NNebsrmjrB2LZzS+fV8JqfFDZn3PurYo4A e2otfY7w+J+NcWS9YMutPYqi2rXTs2mVwAci55Hd51jku3CmLV4fNcn0AWyJ86uxVdbM 1/LfompvgGSONtKWEXH33RH3my50ispk2zXeU4ezbWvqSdW2vWyI3LzgagqGH8PmIIcC vVew== X-Gm-Message-State: ALQs6tDcjdDbEoGwdshOCGIuKbaDxYPLLL2QbnSxxGSCOu+TMov1gyEM GkWWp9VOJWLEHikG6eUqvQ8S/IkHygGo8CztNyqKeA== X-Google-Smtp-Source: AIpwx4/cZit8+2xAWgO80py+mxnBV5U6h9GqqUTbzUcQ0RIN1ngYEf86X7pkCbw7Y8R/3BLNFixVi3g6GRDaCOv/9QE= X-Received: by 2002:adf:9789:: with SMTP id s9-v6mr1089838wrb.28.1524043656295; Wed, 18 Apr 2018 02:27:36 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.28.194.11 with HTTP; Wed, 18 Apr 2018 02:26:55 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Wed, 18 Apr 2018 10:26:55 +0100 X-Google-Sender-Auth: GMDC9ybkg6kZeYa52I9fvfpU7CU Message-ID: Subject: Re: us report on russian hacking To: Julian Elischer Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 09:27:38 -0000 On 18 April 2018 at 06:15, Julian Elischer wrote: > This is a LOT more specific than I'd expected... > > > https://www.us-cert.gov/ncas/alerts/TA18-106A And this is what actually happened back in the real world: https://www.csoonline.com/article/3267867/security/hackers-abused-cisco-flaw-to-warn-iran-and-russia-dont-mess-with-our-elections.html -- Igor M. From owner-freebsd-hackers@freebsd.org Wed Apr 18 09:32:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42B7FFA32B9 for ; Wed, 18 Apr 2018 09:32:33 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3BB4797D0; Wed, 18 Apr 2018 09:32:32 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pl0-x231.google.com with SMTP id 59-v6so766937plc.13; Wed, 18 Apr 2018 02:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbCQJNiDCRdqc9Mq/8k/0faUDC9wMDjVJ+Zw1Ak6qAQ=; b=tHRLOwm0Xo6997eVe4yzZy5O3oSyUP/X9sP2bjMml3fb26BJuk9ukaGiFyh+s+vO7F fMGmx1TR+1y7sehxTfsrMC3ss7abr6Pik4iZIicUeXzUrSlyKhqI1IM+5Ds9SyIons6n Xqiyw0MKL3+DzM28YUI3AYqKCLsvNkpVS3gf5RsW915tc1LRFePFBhGkGeDpqZKr0FF7 f7h8HEpbJtc7BQBsMIf8MmhK5PWr2B4OjBMZKSsJGOsMmxksK6G21jTdNJ64Cz3P9Sf0 aeQZF0L7Rx16fF/tyVRhkrNxJzdXgs2AKAV4luGcZru1ZhQNwbAJzVublwAp5+zO19r5 4EfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bbCQJNiDCRdqc9Mq/8k/0faUDC9wMDjVJ+Zw1Ak6qAQ=; b=E1IAw0tPWrwiLkfsT3advbDrmOT1aa1TqO2kM4Djm25nfM4QQpaAfXDX2XinMdNzdV UEh6UeBpgmGxoulGJxZrHxY5QR0c6jtMXzvXAiQkKbhKuxEzPsF6WtQRZrJNG8zBQvH6 Ny5VITE/W+0gDeVD8KhYFfMJWnxOQ6WFv4oZqfgUIkJZtGKGwatHAJBU0SYZLPXbaRH6 WkeuR4yODZE9aFxPLdnQ/X2xXPyZHcGO5DZ3F3cS1LAtV0uceBGHzCDAVSMHCwx4wOiO jeHkjafHY1ZTsgtU/OWiOHw4vC+5CQe/O6DKyQRHES1NHyBnfXKo6kAFEwlEC47kX5Tr unvg== X-Gm-Message-State: ALQs6tBBILYW0g+Tsr6NP8e5Dyik1QbLERKcKHmmJlohQl52VoKxeWpY AVSX+iIahAoeV1kUyTRPbLWgMLkodKMRrEwMW7Q= X-Google-Smtp-Source: AIpwx48nD0OWcaVdUw19y8KKkCBDKdeqyY6akBI0EiqTFCbxyZL11s+yEQdz61CoseuCYdY3exVG3p4kooVZi7Mz5YI= X-Received: by 2002:a17:902:8342:: with SMTP id z2-v6mr1354003pln.311.1524043951452; Wed, 18 Apr 2018 02:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.226.199 with HTTP; Wed, 18 Apr 2018 02:32:00 -0700 (PDT) In-Reply-To: References: From: Gleb Popov <6yearold@gmail.com> Date: Wed, 18 Apr 2018 12:32:00 +0300 Message-ID: Subject: Re: us report on russian hacking To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 09:32:33 -0000 On Wed, Apr 18, 2018 at 8:15 AM, Julian Elischer wrote: > This is a LOT more specific than I'd expected... > > > https://www.us-cert.gov/ncas/alerts/TA18-106A > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > On light of recent CoC developments I wonder if this post satisfies it. I feel strongly offended by completely ongrounded accusations to my country. I wouldn't cate about it generally, but @hackers is clearly not a right place for such posts. From owner-freebsd-hackers@freebsd.org Wed Apr 18 10:56:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF63DFA8082 for ; Wed, 18 Apr 2018 10:56:54 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 59CE16DD21 for ; Wed, 18 Apr 2018 10:56:54 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 1B5A4FA8080; Wed, 18 Apr 2018 10:56:54 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09FB6FA807F; Wed, 18 Apr 2018 10:56:54 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 986B36DD01; Wed, 18 Apr 2018 10:56:53 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f8kld-0002jm-NO ; Wed, 18 Apr 2018 13:56:49 +0300 Date: Wed, 18 Apr 2018 13:56:49 +0300 From: Vitalij Satanivskij To: John Baldwin Cc: Vitalij Satanivskij , freebsd-current@freebsd.org, cem@freebsd.org, Stephen Hurd , Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180418105649.GA9989@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <3723755.0KMZDfyMWu@ralph.baldwin.cx> <20180417191553.GA95803@hell.ukr.net> <3628282.XVdngBdGlp@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3628282.XVdngBdGlp@ralph.baldwin.cx> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 10:56:54 -0000 JB> > If you need any aditional information please tell me about. JB> JB> Can you perhaps turn off the stack trace on boot to not lose the panic messages JB> (remove KDB_TRACE from kernel config) and maybe modify the panic message to JB> include the IRQ number passed to nexus_add_irq? Hm looks like it's always irq with number 256 eg hpet - 256 igb - 256 Chenged made for it was Index: sys/x86/x86/nexus.c =================================================================== --- sys/x86/x86/nexus.c (revision 332663) +++ sys/x86/x86/nexus.c (working copy) @@ -698,7 +698,7 @@ { if (rman_manage_region(&irq_rman, irq, irq) != 0) - panic("%s: failed", __func__); + panic("%s: failed irq is: %lu", __func__, irq); } From owner-freebsd-hackers@freebsd.org Wed Apr 18 08:07:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF818F9CBA5 for ; Wed, 18 Apr 2018 08:07:36 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4063A850C5; Wed, 18 Apr 2018 08:07:35 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.15.2/8.15.2) with ESMTP id w3I87RqS090749; Wed, 18 Apr 2018 11:07:27 +0300 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 18 Apr 2018 11:07:27 +0300 (MSK) From: Maxim Konovalov To: Julian Elischer cc: FreeBSD Hackers Subject: Re: us report on russian hacking In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 18 Apr 2018 11:25:10 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 08:07:37 -0000 Does this belong to -hackers@ really? On Wed, 18 Apr 2018, 13:15+0800, Julian Elischer wrote: > This is a LOT more specific than I'd expected... > > > https://www.us-cert.gov/ncas/alerts/TA18-106A > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Maxim Konovalov From owner-freebsd-hackers@freebsd.org Wed Apr 18 11:47:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C756F82B2B for ; Wed, 18 Apr 2018 11:47:46 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AA6E7855D; Wed, 18 Apr 2018 11:47:46 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id z73-v6so4009939wrb.0; Wed, 18 Apr 2018 04:47:45 -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=+5ZgKJKXLNiV7eRncsd9ZNTotAb64A5cvZrLaLBq/Kk=; b=S4+C9MTm3x+PBojb0kwDhkeIXZ2yIGFzF9zaV3NMPB4UPdtIUpF3UTWnja+ZHi2X3Z OUFfJ6NjFEggrGmwOlpgNLO8+/lksz1HdiMzuUgrY+u7iK2tCwc/78q37yRMjpjlw/VA tvwBwDIS8oAuFsuuqR+i2h0OVTtmijv0+dSWWzW7REdpj3I+YdXyIfOPWsNT2PkW1nBt 2DXLndB4GqBzfrXJGwTU6waNLSVAWrRytv7gwwWRHdK3NRofkDAkBpFkzo5yw2U3pz+c Kw7BOD0fJHE8dBsf8tFuQS089ttParT1lKuv6GC/HhyDoYAq7PQ9c7hoaNe37lqYAtF2 eOKQ== 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=+5ZgKJKXLNiV7eRncsd9ZNTotAb64A5cvZrLaLBq/Kk=; b=aHncJkeFq7ioo2GOwSQsiO58XxTCR6OmtQKem7Gq25jisNJCwk5LqnXtTSM98jzutm QIMrrr1qzARpRaheLzgvQ/+brXHdtG9dZWkEIGP8aLQnSRdBAIvifLTb/LIZl47gQpaR LonxUBctXZSut8A7rySqo0KQNeN4y0b4PzO7fZEbglM+ry4LUuNOtavDstx5DToid0oe zkJXQ4xSymDfKn5dYxX8Q3vVQblLv5Crfkls4i3WWUT0rz17gEQ/luLZiYT54DKjvEEi hv5pDGTtrYWx4357mPofkUKjEhCGQLRjwOh01x6obMDKxUBdQixX9Sxn9d0i1hAJQhKK Gxwg== X-Gm-Message-State: ALQs6tBzACt4HlzvgIthZZ/YIouoCvhxfu+gr8KTaHNCjodKxmvTKCRI TuzZ9Z1U2NufYbC4SAT1oJQU36u+wUSq+q9yyI4= X-Google-Smtp-Source: AIpwx48QohvnrWCRkHzH0akdYd1StXhJnYem8kjpOGh8AfuKqlBW4shOjzc+ci9N1j7edJl6lrhTfSOYJ1Nmj8JEn5k= X-Received: by 2002:adf:a19d:: with SMTP id u29-v6mr1454306wru.114.1524052064820; Wed, 18 Apr 2018 04:47:44 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.28.194.11 with HTTP; Wed, 18 Apr 2018 04:47:04 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Wed, 18 Apr 2018 12:47:04 +0100 X-Google-Sender-Auth: _D3PGQ0Rr6oxmQvcghK1zbn-4sk Message-ID: Subject: Re: us report on russian hacking To: Maxim Konovalov Cc: Julian Elischer , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 11:47:46 -0000 On 18 April 2018 at 09:07, Maxim Konovalov wrote: > Does this belong to -hackers@ really? In "popular" culture `hacker' === `cracker,' and not a hacker in its original/traditional sense as in a `skilled coder'. -- Igor M. From owner-freebsd-hackers@freebsd.org Wed Apr 18 11:58:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD890F83741 for ; Wed, 18 Apr 2018 11:58:34 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AB3F7A705 for ; Wed, 18 Apr 2018 11:58:33 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.15.2/8.15.2) with ESMTP id w3IBwVpF019588; Wed, 18 Apr 2018 14:58:31 +0300 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 18 Apr 2018 14:58:31 +0300 (MSK) From: Maxim Konovalov To: Igor Mozolevsky cc: FreeBSD Hackers Subject: Re: us report on russian hacking In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 18 Apr 2018 12:03:53 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 11:58:34 -0000 On Wed, 18 Apr 2018, 12:47+0100, Igor Mozolevsky wrote: > On 18 April 2018 at 09:07, Maxim Konovalov > wrote: > > > Does this belong to -hackers@ really? > > In "popular" culture `hacker' === `cracker,' and not a hacker in its > original/traditional sense as in a `skilled coder'. > Igor, I know that very well, thanks. Let me re-phrase the initial question: can we keep freebsd lists out of government propaganda both US, Russia or whatever state -sponsored. I was under impression there was number of other tools like popural social networks and sites invented for that. Thanks, Maxim -- Maxim Konovalov From owner-freebsd-hackers@freebsd.org Wed Apr 18 12:36:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B36F0F86D44 for ; Wed, 18 Apr 2018 12:36:22 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA9481BBF for ; Wed, 18 Apr 2018 12:36:22 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id d19-v6so4409328wre.1 for ; Wed, 18 Apr 2018 05:36:22 -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=+q1hHLwaEODqbkZ1++TPQ3CKpsF3KRzbplcwzwG+PSw=; b=Qt8rKP2TjPU9gm07G+/K02kv/k/Lq1R/aYIAK/9KbMxhEr8AJ7WvWU/yv4+ZuRpTpP qxZcuPP/EjumGkXoj8BPxAOlWQAobLQH/GMipqE1hPsCvwVCzgyHJaU7Lr+ccMVIpJU4 lAap/EZSmgPIt+/HnW0Irnb7NJwarKnTed3LYZfgFFbgVoG8loGiaB6g3PZeVOO6BDaS 4PcJKiCvcWuNaOCH3D1WYPdKEPpsoUYCbG3P4v5ONvU2kZCutWMs+JU426e0AmdMSvC+ 1QavG3GDDvxZXQbyb+1xANJkWHndU5+r803xvZUHIzZe+tFYrwqBOT4NDKMFZAQYr+W5 C5/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=+q1hHLwaEODqbkZ1++TPQ3CKpsF3KRzbplcwzwG+PSw=; b=DE2U3MNr+ixR1NMU2qM+8g1YBJD1dgKzYRhdztw4FHnMwl/Ewj9b/HkWjh1QR4gNPv egrxezPQO68HzuL6woNDJ4yvPETbAMu2LC6WoLlA9uQcPZ7zSLOJ9RxJ+UZkHyrF1g3q iIlSyz6DeUCg0Aa7ZIxKszG9DqLJYXAGmm9E40givniwAqdRT77at0N8ZWWqT0Ry5TVA bVpLPt9PamiCbujF5tJL+rpWfRJB/sz9M++8XLDdx9JUKupkOX5LwVDR+p1XekuoGeBE wHGNDH4OB/iHdpaDfzBKQ1z3OT9d3l4EGi67YCtp9dkvmXsF6/O8cQPcRMNWx6N+Vbhv 2jrA== X-Gm-Message-State: ALQs6tBwwB1P51Ouufb6JPN5M9x21ayynMItaogFecxwOVfLa/rGQ0Ms IGvwk5rd0M3f8fUMATaLJXmUxHoiZNRaXAHomug= X-Google-Smtp-Source: AIpwx4+mUvfexzCjVzDjCwphn5XaQBAbFMP9NC+g5zqXZWBRZctmmcevIkn/jhzJDo3P56sZdNutn3pQuoDwsgmaqXs= X-Received: by 10.28.101.6 with SMTP id z6mr1553202wmb.86.1524054981251; Wed, 18 Apr 2018 05:36:21 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.28.194.11 with HTTP; Wed, 18 Apr 2018 05:35:40 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Wed, 18 Apr 2018 13:35:40 +0100 X-Google-Sender-Auth: iMHWriW7n452e8qwQtWi47RUpM4 Message-ID: Subject: Re: us report on russian hacking To: Maxim Konovalov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 12:36:22 -0000 On 18 April 2018 at 12:58, Maxim Konovalov wrote: > On Wed, 18 Apr 2018, 12:47+0100, Igor Mozolevsky wrote: > > > On 18 April 2018 at 09:07, Maxim Konovalov > > wrote: > > > > > Does this belong to -hackers@ really? > > > > In "popular" culture `hacker' === `cracker,' and not a hacker in its > > original/traditional sense as in a `skilled coder'. > > > Igor, I know that very well, thanks. > > Let me re-phrase the initial question: can we keep freebsd lists out > of government propaganda both US, Russia or whatever state -sponsored. > > I was under impression there was number of other tools like popural > social networks and sites invented for that. Perhaps the welcome message for the list (FreeBSD send these, right?) should make that disparity between the meanings abundantly clear? -- Igor M. From owner-freebsd-hackers@freebsd.org Wed Apr 18 14:11:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C5E3F8E0F7 for ; Wed, 18 Apr 2018 14:11:33 +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 A551076D2A for ; Wed, 18 Apr 2018 14:11:32 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (noddy.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id w3IDrQAl000971 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 18 Apr 2018 23:53:31 +1000 (AEST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) X-Authentication-Warning: b3.hs: Host noddy.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: us report on russian hacking To: freebsd-hackers@freebsd.org References: From: Dewayne Geraghty Message-ID: Date: Wed, 18 Apr 2018 23:53:26 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-AU X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:11:33 -0000 It is useful for us to be ahead of the issues that we will be asked to comment on, and advise our clients & friends.  If Julian's email is read carefully, it is not a political statement. US Cert did need to communicate the issue, but did not need to attribute any nation as instigator (or threat).  Though US-Cert's apparatus seems to be unreliable as this was (& should have been) a critical issue, particularly for SMI users in Feb, 2017 (#1) Did it need to be in freebsd-hackers?  Perhaps, though I suspect freebsd-security might be better? Thanks Igor for the csoonline reference, as background/context its helpful.  Though I did laugh at 'don’t call it a vulnerability, but a “protocol misuse issue.”'  (Hello George?  Hello, is that you, George Orwell?) Kind (g)regards.  :) #1: Refer to https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170214-smi (indirectly from Igor's earlier email) -- Influence national support against IP address spoofing (pretending to be someone else), refer: http://www.bcp38.info/index.php/Main_Page From owner-freebsd-hackers@freebsd.org Wed Apr 18 14:54:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43548F91F96 for ; Wed, 18 Apr 2018 14:54:23 +0000 (UTC) (envelope-from mozolevsky@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 95F5B82DF4 for ; Wed, 18 Apr 2018 14:54:22 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x236.google.com with SMTP id u4-v6so5642843wrg.10 for ; Wed, 18 Apr 2018 07:54:22 -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=p3RZLm8uTqaEYTBOTG9/+j2I6cwnXnhNlccWqT0r9Ns=; b=VGionrSZupX+GwpJi+YA1A5Dpk8yNuIFhHPoNn5nB/r30KYJ5iYiNp7xfCKJe2rL1p 5l6fHYuGe6yOuNiSOYXg3a1nnUk3PKgQDFGR8fbkfvAaUQQLBfykzcdnfLljscWeDZf0 JjTfY6aM5OgV9hdXEBCRB0XGRGA2PQFOiFPg8HCOGBUVNRnE60HTYdKXqpFqOqZnC8rd 018aPyHvJQr/KDsqBBfIeLpdY0X5Z0WTln4VMbGeHDclESzkepesFwmprlZ/GI5JbF6q Y1HfQdx1Nt8HGVKm8uahXX0TTeRqhiiNBFT+3vevZGYzaFNrxD1uRzDPsOf4Ex/5YtWl PPBg== 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=p3RZLm8uTqaEYTBOTG9/+j2I6cwnXnhNlccWqT0r9Ns=; b=SGJGYnpyufI9rN9TLl1UBM9/w2qkatPCQDkfF9N4d6U5Da0isdfxHSxCGocosD4pvv LoajUyy5tIx/dyAaGFLxwYA4HGm5TzVyAY92jAbCbzvn5i/f5lxfmGyap1sH7ZqNh+t8 +O0oQDoBB8xnVU0dEf1JpKG7viB292jBeE6WfK6V3U0yEmduGnyJ9GSUFShIilY3PHdA Uj3dCbuDiZEg6LUtU2d883gXollnZgIL9pWE5TjBVjNYT5CGXb27xbUGp2y3cYYGBXhI a5uVZOfkm+jofv3IxM/vH2vgEpEsIDbFAHkZ3oBVW/+ZtEZDd6IvEuhUkwkxuu+rWdlY Cocw== X-Gm-Message-State: ALQs6tCxu0XnCdQ+vlSRoHsvijSmfFs8gnJeRkBuyXzYqXwh0wrmuYnE gFZ4TqSHt7ln4puD2WcQ3eBa5irVstJdVLf/QEtdig== X-Google-Smtp-Source: AIpwx4814TksdCd/zHRuIRCXpMc0Q6oXbi2TgZPBMwHML8JY3Xxauc2SsFvqm80lKB1Cxu2+9QDVu0+Vc78tS70URPg= X-Received: by 10.28.215.136 with SMTP id o130mr2162177wmg.41.1524063260681; Wed, 18 Apr 2018 07:54:20 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.28.194.11 with HTTP; Wed, 18 Apr 2018 07:53:40 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Wed, 18 Apr 2018 15:53:40 +0100 X-Google-Sender-Auth: y49L1YfKIiW-YVFO40izsqltDog Message-ID: Subject: Re: us report on russian hacking To: Dewayne Geraghty Cc: Hackers freeBSD Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:54:23 -0000 On 18 April 2018 at 14:53, Dewayne Geraghty wrote: It is useful for us to be ahead of the issues that we will be asked to > comment on, and advise our clients & friends. > Indeed, but -hackers@ is hardly a place for security-related stuff; -security@ is more appropriate, although general security issues are _not_ FreeBSD-specific issues. Besides, those interested in receiving US CERT updates are free to sign up [1] to hear from the horse's mouth (and there's even more things to subscribe to at the same link), I've been subscribed for ages and the traffic volume is fairly low. 1. https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new -- Igor M. From owner-freebsd-hackers@freebsd.org Wed Apr 18 15:00:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5419F92B9E for ; Wed, 18 Apr 2018 15:00:25 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C69183C64 for ; Wed, 18 Apr 2018 15:00:24 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w3IEvPUm020428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Apr 2018 16:57:25 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w3IEvJeZ020425; Wed, 18 Apr 2018 16:57:19 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Wed, 18 Apr 2018 16:57:19 +0200 (CEST) From: Wojciech Puchar To: Maxim Konovalov cc: Igor Mozolevsky , FreeBSD Hackers Subject: Re: us report on russian hacking In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:00:25 -0000 >> >> In "popular" culture `hacker' === `cracker,' and not a hacker in its >> original/traditional sense as in a `skilled coder'. >> > Igor, I know that very well, thanks. > > Let me re-phrase the initial question: can we keep freebsd lists out > of government propaganda both US, Russia or whatever state -sponsored. > > I was under impression there was number of other tools like popural > social networks and sites invented for that. > true. and especially - everywhere i here that everything is russian guilt..... There must be public enemy no 1 ;) From owner-freebsd-hackers@freebsd.org Wed Apr 18 17:19:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBF80F9BD16 for ; Wed, 18 Apr 2018 17:19:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7970785D24 for ; Wed, 18 Apr 2018 17:19:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 1D69410AFD3; Wed, 18 Apr 2018 13:19:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Chuck Tuffli Subject: Re: examining Linux core file? Date: Wed, 18 Apr 2018 09:24:11 -0700 Message-ID: <2717167.3JnP6E4tFK@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Apr 2018 13:19:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:19:45 -0000 On Sunday, January 14, 2018 07:57:01 AM Chuck Tuffli wrote: > If a Linux application running under the Linux emulation (a.k.a. > Linuxulator) core dumps, is it possible to examine the resulting core > file? lldb didn't seem to like it: > > # file mremap05.core > mremap05.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), > FreeBSD-style, from 'ases/bin/mremap05' > # lldb -c mremap05.core testcases/bin/mremap05 > (lldb) target create "testcases/bin/mremap05" --core "mremap05.core" > error: Unable to find process plug-in for core file > '/compat/linux/opt/ltp/mremap05.core' > (lldb) bt > error: invalid process > > FreeBSD's gdb seems to recognize this is as Linux, but doesn't know > where to go from there: > # /usr/libexec/gdb -q ./testcases/bin/mremap05 mremap05.core > > warning: A handler for the OS ABI "GNU/Linux" is not built into this > configuration > of GDB. Attempting to continue with the default i386:x86-64 settings. > > Dwarf Error: wrong version in compilation unit header (is 4, should be > 2) [in module /compat/linux/opt/ltp/testcases/bin/mremap05] > > warning: core file may not match specified executable file. > Core was generated by `./testcases/bin/mremap05'. > Program terminated with signal 11, Segmentation fault. > #0 0x0040eb01 in ?? () > (gdb) bt > #0 0x0040eb01 in ?? () > Cannot access memory at address 0xdbea00 > > The gdb from CentOS, on the other hand, seems to think this is a FreeBSD core: > # gdb -q ./testcases/bin/mremap05 mremap05.core > Reading symbols from /opt/ltp/testcases/bin/mremap05...done. > > warning: A handler for the OS ABI "FreeBSD ELF" is not built into this > configuration > of GDB. Attempting to continue with the default i386:x86-64 settings. > > "/opt/ltp/mremap05.core": no core file handler recognizes format > > Are there any other approaches to consider? TIA. Try gdb from ports. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Apr 18 17:19:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6A5AF9BD28 for ; Wed, 18 Apr 2018 17:19:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8127F85D27 for ; Wed, 18 Apr 2018 17:19:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6BCC810AFD4; Wed, 18 Apr 2018 13:19:44 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Kevin Day Subject: Re: sysctl(8) can't read IFMIB nodes Date: Wed, 18 Apr 2018 09:21:57 -0700 Message-ID: <5477049.PC1KtAaiLR@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <18D7A1E9-8564-47D7-90D7-CA2E94F7F9F7@dragondata.com> References: <18D7A1E9-8564-47D7-90D7-CA2E94F7F9F7@dragondata.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Apr 2018 13:19:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:19:46 -0000 On Friday, January 12, 2018 09:09:26 AM Kevin Day wrote: > > IFMIB doesn't work with the command-line tool sysctl(8). src/tools/tools/ifinfo uses IFMIB correctly though, so I looked at why: > > ifinfo is calling sysctlbyname() directly: > > 86387 ifinfo CALL __sysctl(0x7fffffffe510,0x6,0x7fffffffe530,0x7fffffffe100,0,0) > 86387 ifinfo SCTL "net.link.generic.ifdata.1.1" > 86387 ifinfo RET __sysctl 0 > > But using sysctl directly doesn't: > > # ktrace sysctl net.link.generic.ifdata.1.1 > sysctl: unknown oid 'net.link.generic.ifdata.1.1': No such file or directory > > The problem is that sysctl(8) is calling sysctl.name2oid on it first, so that it can get type information on it: > > 21090 sysctl CALL __sysctl(0x7fffffffda00,0x2,0x7fffffffd970,0x7fffffffd9f8,0x7fffffffe210,0x1b) > 21090 sysctl SCTL "sysctl.name2oid" > 21090 sysctl RET __sysctl -1 errno 2 No such file or directory > 21090 sysctl CALL write(0x2,0x7fffffffd2d0,0x8) > 21090 sysctl GIO fd 2 wrote 8 bytes > "sysctl: " > 21090 sysctl RET write 8 > 21090 sysctl CALL write(0x2,0x7fffffffd3c0,0x29) > 21090 sysctl GIO fd 2 wrote 41 bytes > "unknown oid 'net.link.generic.ifdata.1.1'" > > This fails because in the kernel, ifmib isn't setting up oids for every possible entry under ifdata, it configures the parent node then captures every request under it. > > I'm specifically looking to be able to get link state/speed on all interfaces from what's essentially a shell script using tools that only exist in a base install. > > If I were trying to fix this with a patch that would likely get accepted, what's the best way of fixing this? > > 1) Making IFMIB create sysctls for every interface? This would require it get involved every time an interface is added or deleted, which might not be popular because this is a very infrequently used feature. > > 2) Allowing sysctl(8) to forge ahead anyway with reading/writing to sysctls without oids (maybe only if the -o flag is present?) I would fix sysctl by extending it to handle a MIB which is written as either all integers or with a prefix that is a name. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Apr 18 18:20:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E59ECF9FC7E for ; Wed, 18 Apr 2018 18:20:02 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5F37353D; Wed, 18 Apr 2018 18:20:01 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id m202-v6so4026276lfe.8; Wed, 18 Apr 2018 11:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9dRLvOzDts6++rZXjkplsy9TxF28YqX6fFH5zmBJb9U=; b=swgbPjlZGm7SY5e9ZCT9YwcG/4g1brWep9ya+TqhCqLmZFP5a83FbRjeCFz8cwGmTF NFTezJ4S+r11K/9duhTuSOQUPaUW9k0K9FlO003qzGUHM7XtDkRKtSvMzC1cV2hMLFyx DfYN8J2Him3rKy/Uml0seoeImP60IGXqMxHATpBx/LiERM6yU3bdYyyk+mBvbeMGBUIS hCL5V4JINGvOh0zhg+I0e3MM4TSbAKHLEjHFrN0SKrc8xUh7Y06roFOYXvX3SOOAjQYa yZSTVH+6mHu67xybxjx96hBHxHpOok+6RcjZXtqgtAKPhSDwO1bBYtkpfIM+QILUFb6k fTEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9dRLvOzDts6++rZXjkplsy9TxF28YqX6fFH5zmBJb9U=; b=MklpZAGPLwPajDeYoS9S1PY4HNogKOJ0bA7aAS6dBx/7V5p3ovDWQbbLMuC616Uo+g +5YB0IoEwvxmBe6w0tFTXVgef+ljP4WaM24GTQ3kkPp5IXO/8ySbKMElsrIz+rYA/iqL +pUyytF5RoGj/n+0I3ynVBu1gjfCZNH4NTQQRtZX7139rHYxrDJOALYoL5LPP2+XIWzB BDlJKF9XDGbSs+TD1xYLgmSYse3WoWbhSyBGzCDd3Eg/IDXEYskiJ4n5HgJz5FThn3bs DyQ+KMq/3bDK9KElHCRUJymBNxCRjG9WlS/S6KAjTtA1hySIL+Ywc34U8TYHx5Qao/Qo /cuA== X-Gm-Message-State: ALQs6tBU6cqtbpmiVzM3G4TNjoCyZuJ9EFpr9mrH4dF01M7S5Htlr9lh RHi7hWvegNb9XxTVtrtfxcGwcQ== X-Google-Smtp-Source: AIpwx48FjS/jCuziEEyfNKly3WKe80wN2xS6OQpAW/mO+MhbnYMcwQeAToUHb4YSOZPjpcIoQgNCMg== X-Received: by 10.46.128.16 with SMTP id j16mr2253085ljg.26.1524075599243; Wed, 18 Apr 2018 11:19:59 -0700 (PDT) Received: from localhost ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id u12sm279589lji.87.2018.04.18.11.19.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Apr 2018 11:19:58 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Wed, 18 Apr 2018 21:20:04 +0300 To: Julian Elischer Cc: FreeBSD Hackers Subject: Re: us report on russian hacking Message-ID: <20180418212004.50874cd4@gmail.com> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 18:20:03 -0000 On Wed, 18 Apr 2018 13:15:07 +0800 Julian Elischer wrote: > This is a LOT more specific than I'd expected... > > > https://www.us-cert.gov/ncas/alerts/TA18-106A > What about new NSA exploits and operations? )))) From owner-freebsd-hackers@freebsd.org Wed Apr 18 18:42:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51CECFA193A for ; Wed, 18 Apr 2018 18:42:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E5F84798B8 for ; Wed, 18 Apr 2018 18:42:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A771EFA1938; Wed, 18 Apr 2018 18:42:51 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93608FA1936; Wed, 18 Apr 2018 18:42:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36FE97989A; Wed, 18 Apr 2018 18:42:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 342B310AFAD; Wed, 18 Apr 2018 14:42:50 -0400 (EDT) From: John Baldwin To: Vitalij Satanivskij Cc: freebsd-current@freebsd.org, cem@freebsd.org, Stephen Hurd , Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Date: Wed, 18 Apr 2018 11:42:41 -0700 Message-ID: <1616582.sIejGazfcv@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180418105649.GA9989@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <3628282.XVdngBdGlp@ralph.baldwin.cx> <20180418105649.GA9989@hell.ukr.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 18 Apr 2018 14:42:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 18:42:52 -0000 On Wednesday, April 18, 2018 01:56:49 PM Vitalij Satanivskij wrote: > JB> > If you need any aditional information please tell me about. > JB> > JB> Can you perhaps turn off the stack trace on boot to not lose the panic messages > JB> (remove KDB_TRACE from kernel config) and maybe modify the panic message to > JB> include the IRQ number passed to nexus_add_irq? > > > Hm looks like it's always irq with number 256 > eg hpet - 256 > igb - 256 > > Chenged made for it was > > Index: sys/x86/x86/nexus.c > =================================================================== > --- sys/x86/x86/nexus.c (revision 332663) > +++ sys/x86/x86/nexus.c (working copy) > @@ -698,7 +698,7 @@ > { > > if (rman_manage_region(&irq_rman, irq, irq) != 0) > - panic("%s: failed", __func__); > + panic("%s: failed irq is: %lu", __func__, irq); > } Ohhhh, this is a different issue. Sorry. As a hack, try changing 'FIRST_MSI_INT' to 512 in sys/amd64/include/intr_machdep.h. The issue is that some systems now include more than 256 interrupt pins on I/O APICs, so IRQ 256 is already reserved for use by one of those interrupt pins. The real fix is that I need to make FIRST_MSI_INT dynamic instead of a constant and just define it as the first free IRQ after the I/O APICs have probed. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Apr 18 19:13:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EFD8FA3919 for ; Wed, 18 Apr 2018 19:13:16 +0000 (UTC) (envelope-from satan@ukr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B942E814FF for ; Wed, 18 Apr 2018 19:13:15 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 78E88FA3916; Wed, 18 Apr 2018 19:13:15 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65CCBFA3915; Wed, 18 Apr 2018 19:13:15 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 F208D814E1; Wed, 18 Apr 2018 19:13:14 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1f8sVz-000Arj-Pe ; Wed, 18 Apr 2018 22:13:11 +0300 Date: Wed, 18 Apr 2018 22:13:11 +0300 From: Vitalij Satanivskij To: John Baldwin Cc: Vitalij Satanivskij , freebsd-current@freebsd.org, cem@freebsd.org, Stephen Hurd , Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) Message-ID: <20180418191311.GA74540@hell.ukr.net> References: <20180416102710.GA90028@hell.ukr.net> <3628282.XVdngBdGlp@ralph.baldwin.cx> <20180418105649.GA9989@hell.ukr.net> <1616582.sIejGazfcv@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1616582.sIejGazfcv@ralph.baldwin.cx> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 19:13:16 -0000 JB> Ohhhh, this is a different issue. Sorry. As a hack, try changing JB> 'FIRST_MSI_INT' to 512 in sys/amd64/include/intr_machdep.h. The issue JB> is that some systems now include more than 256 interrupt pins on I/O JB> APICs, so IRQ 256 is already reserved for use by one of those JB> interrupt pins. The real fix is that I need to make FIRST_MSI_INT JB> dynamic instead of a constant and just define it as the first free IRQ JB> after the I/O APICs have probed. JB> Yep. That it. But just one note irq585: ccp14:721 @cpu0(domain0): 0 irq586: ccp14:723 @cpu0(domain0): 0 irq587: ccp15:725 @cpu0(domain0): 0 If I understand correctly number of irq's even more then 512, so better to change to real number in system ? Or this is another case ? Any way thank you for help. Now I can use system with msix and msi enabled. From owner-freebsd-hackers@freebsd.org Wed Apr 18 21:57:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63547F8505B for ; Wed, 18 Apr 2018 21:57:29 +0000 (UTC) (envelope-from serdarresi@hotmail.com) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-oln040092067051.outbound.protection.outlook.com [40.92.67.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF0096AC2C for ; Wed, 18 Apr 2018 21:57:28 +0000 (UTC) (envelope-from serdarresi@hotmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HQSrtNL+CDH6JsoLAaR8X/rOqr9kempIYe4h/BxCk2M=; b=Og0fqcMauxoail2pzIeYW6Q4LiX0jneBbLLCeu884V++CsjRJ+M+77crD4DMBkD7yJnstr42wQ2eCZt7c+mut7Vo0L9ysrr+QrJB0D/MblHG9gUebfOrBf9d6KbtCXMKjamu8PlYncKmwhmVPztkJ4DdCLWU+GYg+HjSCEJnW9GeAAuavjeRGFdKnalLU1fnLqsiSG2OdxCODSnFwdXHoj0vPV8aBMDskJodenuCCrcp+6cBwu1xTjmKpMy3/7LAYhiIEvyDko0pC4MWZJ7mM1nyvqmRI5CEay/zUxji4FPSfCQVeDY5YLiqyFe58P1TYRAEmGKQq+hM7BucTo2FkA== Received: from VE1EUR02FT058.eop-EUR02.prod.protection.outlook.com (10.152.12.51) by VE1EUR02HT153.eop-EUR02.prod.protection.outlook.com (10.152.13.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.675.14; Wed, 18 Apr 2018 21:57:27 +0000 Received: from AM5P194MB0034.EURP194.PROD.OUTLOOK.COM (10.152.12.53) by VE1EUR02FT058.mail.protection.outlook.com (10.152.13.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.675.14 via Frontend Transport; Wed, 18 Apr 2018 21:57:27 +0000 Received: from AM5P194MB0034.EURP194.PROD.OUTLOOK.COM ([fe80::254d:6340:3cd8:87bf]) by AM5P194MB0034.EURP194.PROD.OUTLOOK.COM ([fe80::254d:6340:3cd8:87bf%7]) with mapi id 15.20.0696.011; Wed, 18 Apr 2018 21:57:27 +0000 From: =?utf-8?B?c2VyZGFyIHRva2fDtno=?= To: "freebsd-hackers@freebsd.org" Subject: Thread-Index: AQHT12A9U3BSkwW3KEKlc4lj9ruNkA== Date: Wed, 18 Apr 2018 21:57:26 +0000 Message-ID: Accept-Language: tr-TR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:84DB323797920823C44358B2D9A4DA73D17F4C19A0062CCFDA2F60200F57E9BC; UpperCasedChecksum:D9BD19F8EE0926F10B333E78E3CF750CCB6945BF2B35B364DC02E1908FA0CC5B; SizeAsReceived:6822; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [FRiyUUPcVtuO7p2wRYManl7W3jjW55Tl] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VE1EUR02HT153; 7:+IrAoNCmmaC/R6BjyPikmT5/aMlLiG5g5WIjJz+J5jH+cECO7vFYQXocLPHWoAt9eu0koLY0zacQIu9f5fSZy+FMqL+sLrENlbyjY/IybJmA0OJC6Sqqu0WkP1yMNquwm4sXSrj5tEbj6s1iuy2wlF2DnuZxKJZZqo1TaeSLgqwdV7+o2cJLSGtQwcXae5Akws1jRTg8IoNtbqlMNxKPeFS4ArZZjyy6MAJjgkC+5MnMU67gaz36ECeTrcKvcFn3 x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:VE1EUR02HT153; x-ms-traffictypediagnostic: VE1EUR02HT153: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:VE1EUR02HT153; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR02HT153; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:VE1EUR02HT153; H:AM5P194MB0034.EURP194.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: OhwGBeZY8kfNHJiih1iVWRbSNqMNn7urS4jf2e9F7yKTy+RlWH/EguuGPC+EVB0BHG8WlV3lAJMekX7wmsv0cuYeVkybfHhCvpCsBMrxc13ZpRL5Jb5DXY85CDSTAuuBwThGH036rPwH8KtIfUmCZC7XbN6gb2sWYzw6TH3ve/m0+5yxOwJaKh3maF57XHsd MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1781deac-f4d4-40ec-e5e2-08d5a5775ef2 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-Network-Message-Id: 1781deac-f4d4-40ec-e5e2-08d5a5775ef2 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 21:57:26.9833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT153 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 21:57:29 -0000 VW5TdWJzY3JpcHRpb24NCg== From owner-freebsd-hackers@freebsd.org Thu Apr 19 15:20:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28EAFF833F4 for ; Thu, 19 Apr 2018 15:20:27 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC7D6AB4D for ; Thu, 19 Apr 2018 15:20:26 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id q13-v6so15119620wre.3 for ; Thu, 19 Apr 2018 08:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HHfYqBEOWxs/jPmIl6B73dTuX37wYhMs+ock8knixgQ=; b=jsw4yabhGvsiTBeGSyCzQHmMtteRepZGVRPr4aRxM3CfETkp6vQ/fxrPy81XVCTkys 32r2d4GbhKq8xxMRloWhtT9xeSfjJNU9xXv7D8coIJQk1oD62jCrPG1xLoxp6T0G0uA/ poxyvsQsuSg1j1PMZeyxThG+zwpIPYVzBUtPoYHNOm9ZzPKNgAeTsElwPyb1aV4mp4Pm wkNIl4x0s8iOP/9pcSebxHBmJcZnNmIyk7NRw1qYn8KUROws7J56wJc1o1Ilp1Sekbpj hgCu+NiKFcrC91F4I0iOgsyMTg788q3MDLESerLX0kC+IlGv30UqMREUXlFsmIsphlmy 8mIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HHfYqBEOWxs/jPmIl6B73dTuX37wYhMs+ock8knixgQ=; b=ic3i1UFyoPSOEiHLEpdXBeug9RCkSl9RaKbdqmOpKcoAjkBmbT4O9cQbQ4mLnqjh8F 7UzgYFxw4nE71mNwZIztg+lCdvNyJHf9iQVqrT5gzehPqUDZ1fQbJXB7cYDfgSJ4Bu2D rgOGSAX/b4tkdYQGyRSo1JxnEE4uOzF3jqlDmwjHy+BhCcfwjNe9tb2sgZ3j4ytLhYni LYGIZE+6o9HneR0MtfVzivMA/nKLLqUfH2Vp2L+6llAIAD0ZpTRaIvCzOBBYy4l0ovCa 29YqWU5Ab/vFZYVPOi45t+D48dyAoAbSkLtxnHKzmTjaafWZPUQGoXw6BTSfXvzof6gb qInw== X-Gm-Message-State: ALQs6tBhjKODj23iAPba7qp814s6MT/kCDOQs/Wt6/YjEPzTB7Rjahar sShStZ7mHWUaVYYJuF5SDh23SQ== X-Google-Smtp-Source: AIpwx48IX92Wq/CfkddHA93n/KEO8J3omIVLNPBZyK0/rnX/2VaZfJuMndrLhCURhNT+KRJeuMiNVQ== X-Received: by 2002:adf:b90a:: with SMTP id k10-v6mr5414942wrf.283.1524151225170; Thu, 19 Apr 2018 08:20:25 -0700 (PDT) Received: from alfixfbsd (host81-254-dynamic.22-79-r.retail.telecomitalia.it. [79.22.254.81]) by smtp.gmail.com with ESMTPSA id n79sm6194467wmi.20.2018.04.19.08.20.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 08:20:24 -0700 (PDT) Date: Thu, 19 Apr 2018 17:20:23 +0200 From: alfix86 To: Theron Tarigo Cc: freebsd-hackers@freebsd.org Subject: Re: mount system call for nullfs Message-Id: <20180419172023.e19621515d3060295dccb2f5@gmail.com> In-Reply-To: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> References: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 15:20:27 -0000 > > I would use "mount" system call > > > > int mount(const char *type, const char *dir, int flags, void *data); > > > > to mount a nullfs, the problem is about *data; > > > > Where can I find docs? Example? Code? I solved, The *data [0] was in FreeBSD4: struct null_args { char *target; /* Target of loopback */ }; but was deleted [1], so I'll use nmount [0] http://fxr.watson.org/fxr/source/miscfs/nullfs/null.h?v=FREEBSD4 [1] https://svnweb.freebsd.org/base/head/sys/fs/nullfs/null.h?r1=65467&r2=97186 -- alfix86 From owner-freebsd-hackers@freebsd.org Thu Apr 19 18:06:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1077AF91E54 for ; Thu, 19 Apr 2018 18:06:29 +0000 (UTC) (envelope-from 01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@amazonses.com) Received: from a8-56.smtp-out.amazonses.com (a8-56.smtp-out.amazonses.com [54.240.8.56]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A948D72FB3 for ; Thu, 19 Apr 2018 18:06:28 +0000 (UTC) (envelope-from 01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524161182; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=rga1IUhNqPf+uMoGlR91ioND8YJrO/vDAiYIWyQgghI=; b=SEJHrYH7Oo0kfjgEmmdoFTLqtYB2bISGWfJka9CUag38/oZL1jInFxDH1H61wyxp CkJBnm+OdG6vyYftlOMjn5eWEnGAvrpEvjN/u7nykdWmGnnhhpIlpNK9zL1HpM/C9Cv eK/ktK7Ao4oKx04fD5YBmEwJUS4dlDciJr75Zwkc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524161182; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=rga1IUhNqPf+uMoGlR91ioND8YJrO/vDAiYIWyQgghI=; b=K8YKdSWDz00EWfMY3Cx0Jns1r4m3tzm1lsb/TC9sDPyQmZ2OoEon31cUz49DG+9i lWu6TjVIVp63Xp6ZD7k52gOEPFKOKwO0LabPjRxpGScoYbRpXFm5zUZsnv5b/ve0tF6 v4dFKEERtCHtjHa2ongxuPuq+AndMOo2+Oq5e5I0= To: freebsd-hackers@freebsd.org From: Colin Percival Subject: RFC: Hiding per-CPU kernel output behind bootverbose Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> Date: Thu, 19 Apr 2018 18:06:21 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2018.04.19-54.240.8.56 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-Mailman-Approved-At: Thu, 19 Apr 2018 20:05:42 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 18:06:29 -0000 On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) the boot time console output contains a large number of lines of the forms SMP: AP CPU #N Launched! cpuN: on acpi0 estN: on cpuN Having 128 almost-identical lines of output doesn't seem very useful, and it actually has a nontrivial impact on the time spent booting. Does anyone mind if I hide these by default, having them only show up if boot verbosity is requested? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Thu Apr 19 20:44:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E384AFA0C03 for ; Thu, 19 Apr 2018 20:44:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4705C7907A for ; Thu, 19 Apr 2018 20:44:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3JKi5SF030720 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Apr 2018 23:44:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3JKi5SF030720 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3JKi5fF030719; Thu, 19 Apr 2018 23:44:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Apr 2018 23:44:05 +0300 From: Konstantin Belousov To: Colin Percival Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <20180419204405.GE6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 20:44:17 -0000 On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: > On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) > the boot time console output contains a large number of lines of the forms > > SMP: AP CPU #N Launched! > cpuN: on acpi0 > estN: on cpuN > > Having 128 almost-identical lines of output doesn't seem very useful, and > it actually has a nontrivial impact on the time spent booting. > > Does anyone mind if I hide these by default, having them only show up if > boot verbosity is requested? The 'CPU XX Launched' messages are very useful for initial diagnostic of the SMP startup failures. You need to enable bootverbose to see the hang details, but for initial hint they are required. Unfortunately, AP startup hangs occur too often to pretend that this can be delegated to very specific circumstances. Rest of the lines you pasted are normal device attach messages, so it is not clear how would you hide them without ugly hacks. From owner-freebsd-hackers@freebsd.org Thu Apr 19 20:48:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 672B9FA10E2 for ; Thu, 19 Apr 2018 20:48:26 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 D7C107ACE1 for ; Thu, 19 Apr 2018 20:48:25 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22a.google.com with SMTP id u21-v6so483593lfu.9 for ; Thu, 19 Apr 2018 13:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3rRvX20IRuq2BNaKAgLqMmWyg7JKmLgBtSRgN7a+3N8=; b=FdeypmTJ7U4grYn6Fj3lIu2IcywoszloGFRhBDbfzbqkt6d4HJlnP6IKAbkFO61O6N K9y1d3kdPGM23gpR2T3HN5xpv9LdnEGzlBKecQ7br7WLM6veT9bxD6fYGOatOfmclmEK TP9nFlGkhSxTiZkwW2F6RrOV0pzui3pvhmDw/wKtvIHhKpG3866tREmeoLqb0J3Ldvny XWPNS7Wj5PGEoe9NC4ewIZwoudcNELcxuwMgNloGTWhbvGIO/YiRC2Q3su+3Z902Oolp VqfU+xd22haTeGPeohFc66RP3GdWm1bYeZ7KWmcgnEkW0POBTUP1B/eIDn1jXvLLAPgx I7dw== 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:cc; bh=3rRvX20IRuq2BNaKAgLqMmWyg7JKmLgBtSRgN7a+3N8=; b=O5rK3PrtrCn+6szz3dDH3GIAXNzLaSvAsyXcc0pwJT9s37ET0naBq0yHtwTIFTObzM r2D42cHrerYrk8hQ4R6rW4ZsnrsDkQfEkBC1e1RAQ8lK4O/RlV/EIil6vTRPlD0k012J yYDJLiLFGGRo5ma4WBVJfNEB3SNPXY1/ApW84cr5UhL3bpbK0yVAnzq1X69HPjCDqgVu SLgUPR76hhwaWH3p+1hj/twNquv8ECC8JvlMBRyqzaDqX9AN8gGkMa0ILXpsCXaPRKqa 4USnLxZU3TSijH1ieZ2MDZx2khdrH+grskuNoF3QXtd8hfoY52WJMBzY+wo7q/C/7GWB Jd8Q== X-Gm-Message-State: ALQs6tC7v1film2HluRfy+aUHR5iFdiF7rUlHRI/il5tALxl0npNKeaN 07W7xJ4mgU9FDBZoj3qzdr7AMiQkg4b3TvJaeTCtd1Y5 X-Google-Smtp-Source: AB8JxZquQywrMifmKQjLCI/NaP+GjfGwM0LrSNWph4HXP3UFzL3Gqrj6xb/rCak5XDV3tm1k34+It+E9cgyZ/Ynvw7k= X-Received: by 2002:a19:c3d0:: with SMTP id t199-v6mr7098lff.127.1524170903668; Thu, 19 Apr 2018 13:48:23 -0700 (PDT) MIME-Version: 1.0 References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> In-Reply-To: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> From: Steven Hartland Date: Thu, 19 Apr 2018 20:48:13 +0000 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Colin Percival 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.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 20:48:26 -0000 Sounds good to me, I think we could actually benefit from even quieter modes if I=E2=80=99m honest. On Thu, 19 Apr 2018 at 21:09, Colin Percival wrote: > On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) > the boot time console output contains a large number of lines of the form= s > > SMP: AP CPU #N Launched! > cpuN: on acpi0 > estN: on cpuN > > Having 128 almost-identical lines of output doesn't seem very useful, and > it actually has a nontrivial impact on the time spent booting. > > Does anyone mind if I hide these by default, having them only show up if > boot verbosity is requested? > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoi= d > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Thu Apr 19 20:59:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37BDAFA1FF7 for ; Thu, 19 Apr 2018 20:59:42 +0000 (UTC) (envelope-from 01000162dfb48d86-02daee46-919a-4193-84d2-5352d6b05107-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF24C7E38C for ; Thu, 19 Apr 2018 20:59:41 +0000 (UTC) (envelope-from 01000162dfb48d86-02daee46-919a-4193-84d2-5352d6b05107-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524171574; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=sgYZbLcbH3RnOJ2m++LL95Kme2tsNLsEp8uETz2uhsQ=; b=ejVXxH5jnHbLpJHlLis0mAybs37tjTFNy766MRVpyfF8sKu2G84UUL/E/sXuCUZ2 Cc2aYkPDNFsCR8nRF3pfxFmdQ9jBfxqzg7cHiHH11Vo8d55S+3QYu/VuMgfDYORpj8n gzt6AmcVnz3dqjbUILX4WmYat8xoK9x8uPBL2T3A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524171574; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=sgYZbLcbH3RnOJ2m++LL95Kme2tsNLsEp8uETz2uhsQ=; b=e1WcsCScHnkKqICfmaoP+i4YYdgfXOA+HuN5DGKY0rFzGQDZwJBHcBFEssRZz1BG +ZyRQgtNLg52DFABwdgw5IJd4aMeR7kQr/DYW8ziSZxMS5GX60FnYQD+zeNL0B3kQG0 ofdp1cw0AvLOkxdAq6kauP5/S3+yY/acAFptjR9I= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162dfb48d86-02daee46-919a-4193-84d2-5352d6b05107-000000@email.amazonses.com> Date: Thu, 19 Apr 2018 20:59:34 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180419204405.GE6887@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2018.04.19-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 20:59:42 -0000 On 04/19/18 13:44, Konstantin Belousov wrote: > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) >> the boot time console output contains a large number of lines of the forms >> >> SMP: AP CPU #N Launched! >> cpuN: on acpi0 >> estN: on cpuN >> >> Having 128 almost-identical lines of output doesn't seem very useful, and >> it actually has a nontrivial impact on the time spent booting. >> >> Does anyone mind if I hide these by default, having them only show up if >> boot verbosity is requested? > > The 'CPU XX Launched' messages are very useful for initial diagnostic > of the SMP startup failures. You need to enable bootverbose to see the > hang details, but for initial hint they are required. Unfortunately, AP > startup hangs occur too often to pretend that this can be delegated to > very specific circumstances. Do SMP startup failures need to be debugged often enough to justify having this verbosity every time a FreeBSD system boots? > Rest of the lines you pasted are normal device attach messages, so it is > not clear how would you hide them without ugly hacks. I would be willing to employ ugly hacks in order to silence unhelpful output and speed up the boot process. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Thu Apr 19 21:37:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A75E7FA4A22 for ; Thu, 19 Apr 2018 21:37:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (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 3B97C8854B for ; Thu, 19 Apr 2018 21:37:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id h143-v6so178449ita.4 for ; Thu, 19 Apr 2018 14:37:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ncCqr+ULadv3U4ezh7iuwercsfN5x+KUOJOxx9cQSBk=; b=ohttD8BnAmyk6cIln2xvRJJMWa8ksxl6F3ob+Qjnj0sn0nWOwrjUfu/qfGjFmyY3bB +nU8IKQso6qGobyNIzLj03GZovv/vE6vA6ZyOz8rOAMq2AcpqvkZX8i8g9VFUBGm6S0Y TPiA5wXZYs/B/tHWwP1YG0pMuzsUMg3Z+vAhAeIAZAKKpG6BZ4gN01Ut3wDt5CAJsIwQ QkEjJ7VdXySVtXB4WJN86jTgG/JqRbrKpRzl6Vqa2nd5N0bZTTE6FkVbInZn7do+TQSu azY66bzzuEzIa6rEziaQYOhhZAwSlwVZhsu7Lc2i/0AQCF+XPRfwj83nXRWdtdxxzarY SWDQ== X-Gm-Message-State: ALQs6tCGluePbGikVjXh4e+ppDAKlMbwTZD/fnoWtrYtW8Ya7BekMWQB N6pXD8eaNGDzW6aHYSrJ3ouK5GNE X-Google-Smtp-Source: AIpwx4+yJ+dBOvqiyZM7Lhn9odMBwtcI3wJQr/Xzoth2zS3332bGHE6UqJyCnbdtzwDglc0CuXbxEg== X-Received: by 2002:a24:b548:: with SMTP id j8-v6mr481070iti.146.1524173878246; Thu, 19 Apr 2018 14:37:58 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id i12-v6sm35917itb.7.2018.04.19.14.37.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 14:37:58 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id 85-v6so157675iti.4 for ; Thu, 19 Apr 2018 14:37:57 -0700 (PDT) X-Received: by 2002:a24:b103:: with SMTP id o3-v6mr507764itf.46.1524173877183; Thu, 19 Apr 2018 14:37:57 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:224d:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 14:37:56 -0700 (PDT) In-Reply-To: <20180419204405.GE6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> From: Conrad Meyer Date: Thu, 19 Apr 2018 14:37:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Konstantin Belousov , Colin Percival Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 21:38:00 -0000 On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) >> the boot time console output contains a large number of lines of the forms >> >> SMP: AP CPU #N Launched! >> cpuN: on acpi0 >> estN: on cpuN >> >> Having 128 almost-identical lines of output doesn't seem very useful, and >> it actually has a nontrivial impact on the time spent booting. >> >> Does anyone mind if I hide these by default, having them only show up if >> boot verbosity is requested? +1. For the device attaches, perhaps it makes sense to add a device 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then the generic attach code can choose whether to print spammy attaches based on bootverbose. dmesg for device attaches seems mostly redundant with devinfo(8) for persistent devices like ACPI CPU and est(4). > The 'CPU XX Launched' messages are very useful for initial diagnostic > of the SMP startup failures. You need to enable bootverbose to see the > hang details, but for initial hint they are required. Unfortunately, AP > startup hangs occur too often to pretend that this can be delegated to > very specific circumstances. Really? I don't know that I've ever seen an AP startup hang. How often do they occur? Best, Conrad From owner-freebsd-hackers@freebsd.org Thu Apr 19 21:46:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 096FBFA5634 for ; Thu, 19 Apr 2018 21:46:07 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E8C189C6C; Thu, 19 Apr 2018 21:46:06 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3JLjoAK045012 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Apr 2018 00:45:54 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3JLjoAK045012 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3JLjoxK045008; Fri, 20 Apr 2018 00:45:50 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 20 Apr 2018 00:45:50 +0300 From: Konstantin Belousov To: Conrad Meyer Cc: Colin Percival , "freebsd-hackers@freebsd.org" Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <20180419214550.GF6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 21:46:07 -0000 On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov > wrote: > > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: > >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) > >> the boot time console output contains a large number of lines of the forms > >> > >> SMP: AP CPU #N Launched! > >> cpuN: on acpi0 > >> estN: on cpuN > >> > >> Having 128 almost-identical lines of output doesn't seem very useful, and > >> it actually has a nontrivial impact on the time spent booting. > >> > >> Does anyone mind if I hide these by default, having them only show up if > >> boot verbosity is requested? > > +1. For the device attaches, perhaps it makes sense to add a device > 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then > the generic attach code can choose whether to print spammy attaches > based on bootverbose. dmesg for device attaches seems mostly > redundant with devinfo(8) for persistent devices like ACPI CPU and > est(4). > > > The 'CPU XX Launched' messages are very useful for initial diagnostic > > of the SMP startup failures. You need to enable bootverbose to see the > > hang details, but for initial hint they are required. Unfortunately, AP > > startup hangs occur too often to pretend that this can be delegated to > > very specific circumstances. > > Really? I don't know that I've ever seen an AP startup hang. How > often do they occur? It was epidemic with Sandy Bridge, mostly correlated to specific BIOS supplier and its interaction with the x2APIC enablement, see madt.c:170 and below. There were several recent reports of the issue with Broadwell Xeon machines, no additional data or resolution. There are sporadic reports of the problem, where I do not see a clear commonality. From owner-freebsd-hackers@freebsd.org Thu Apr 19 23:05:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B067DFAA489 for ; Thu, 19 Apr 2018 23:05:02 +0000 (UTC) (envelope-from sblachmann@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 3D6D872704; Thu, 19 Apr 2018 23:05:02 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-oi0-x230.google.com with SMTP id n65-v6so6416417oig.6; Thu, 19 Apr 2018 16:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+7sZq/3fviy3H2qG4I87BEOVGzcnamYX2fXFX3TGX6k=; b=EgYRvvEVMCKQ4UijTyR4UY55SWZ8PLbMe1lwG7LcJBhuZaUIJz+mzY+AVQysZZJtwN oTp5zVSk7HLHT707e6QxpOxq7DU0sO7zmnhqdk54QfJODJcwKVdrx7BTrQNtaWw6RQAq KOQzSM5K4tX94Ho1yWUAqisPwwIxHOuCL4EOm+VDdm0uAw4O/UF4mFksNZfhoxRZVuSs h80IoysfcF5fG07gRhpBWKHD1PJ89oo+RSy80ICQU6EYJ3Xtrq+d8ghoyE7VmUnKbvSm kk7F9mvGswWEbwd+eqGvpvRVNzb59XmQ839gD4VV3MBbxilwbbPSiOWmbMr+ASlvVBGu kPfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+7sZq/3fviy3H2qG4I87BEOVGzcnamYX2fXFX3TGX6k=; b=ucrkJWzvVwaMSxi/HEfIaXuhaYAg2BivrGd1LjLGDUYnTo09VCYi33UsN+YnbPHpQE FVGa8Scr2Y2JgX80IkeUXx3JDpG9NDEI9tvCW3TRo+aHvjzGiT0Zhyzw2+Fe1mhEZSFa JFo5DfwbiMzS9TkZrpAf3bjmtYod23REYxy4TWS6EI5p4tawqFP7vQXqjzhlmgA2OlEv aV3yam9Z1T4dFZu9ZRRw2Yf9aLvD90HoDeGmSBmhnbjEqQZzXSCAjm96BJeGWr7EFE34 K1e+SLs+TrQtjLGvvYg0/PPwhup/4yYZSGfeBq8xg1lAmqkWW1S+/Ls4+K8RBKKNMBl8 Ub6g== X-Gm-Message-State: ALQs6tCx8tRmMmZuK+HSA9IczBf9p+BW88cthSz4fDdNOlqPRyKFfdbp WdHq2Xe15qOy9EaYrLkhJOuFoRyYNjxK9Kn6Ksw= X-Google-Smtp-Source: AIpwx48FiZeGrI5KokHRK7qJJKRbe2b9IzFT58irawhF9yRVDtvl+ZDPrxbbuQFXnKkxgb5aq/HObWA2vCShoWOSgGs= X-Received: by 2002:aca:5751:: with SMTP id l78-v6mr4641685oib.171.1524179101407; Thu, 19 Apr 2018 16:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Thu, 19 Apr 2018 16:05:00 -0700 (PDT) In-Reply-To: <20180419214550.GF6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> From: Stefan Blachmann Date: Fri, 20 Apr 2018 01:05:00 +0200 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Konstantin Belousov Cc: Conrad Meyer , "freebsd-hackers@freebsd.org" , Colin Percival Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:05:02 -0000 I would also like a solution to this issue, which is looking highly unprofessional and uselessly wasting space in the dmesg ring buffer. In the first version of my sysutils/cpupdate tool I also had spammy output like being complained about. This was hard-to-read. Thus I changed code so that identical cores output was collected up in blocks of single output, i.e.: "core #n to #m: ". If all cpus are identical, cpu stats will be output only once this way, else in subsequent blocks comprising all identical cores on different cpus. To avoid the spamming at bootup and microcode updating, the kernel would need such a function to read/evaluate *all* cores in a row, like I did in cpupdate. This would be only a few lines of code. On 4/19/18, Konstantin Belousov wrote: > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov >> wrote: >> > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: >> >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 >> >> vCPUs) >> >> the boot time console output contains a large number of lines of the >> >> forms >> >> >> >> SMP: AP CPU #N Launched! >> >> cpuN: on acpi0 >> >> estN: on cpuN >> >> >> >> Having 128 almost-identical lines of output doesn't seem very useful, >> >> and >> >> it actually has a nontrivial impact on the time spent booting. >> >> >> >> Does anyone mind if I hide these by default, having them only show up >> >> if >> >> boot verbosity is requested? >> >> +1. For the device attaches, perhaps it makes sense to add a device >> 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then >> the generic attach code can choose whether to print spammy attaches >> based on bootverbose. dmesg for device attaches seems mostly >> redundant with devinfo(8) for persistent devices like ACPI CPU and >> est(4). >> >> > The 'CPU XX Launched' messages are very useful for initial diagnostic >> > of the SMP startup failures. You need to enable bootverbose to see the >> > hang details, but for initial hint they are required. Unfortunately, AP >> > startup hangs occur too often to pretend that this can be delegated to >> > very specific circumstances. >> >> Really? I don't know that I've ever seen an AP startup hang. How >> often do they occur? > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > supplier and its interaction with the x2APIC enablement, see madt.c:170 > and below. > > There were several recent reports of the issue with Broadwell Xeon > machines, no additional data or resolution. > > There are sporadic reports of the problem, where I do not see > a clear commonality. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Apr 19 23:17:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39A24FAB245 for ; Thu, 19 Apr 2018 23:17:46 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BC9D76A19; Thu, 19 Apr 2018 23:17:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w3JNHftp067876; Thu, 19 Apr 2018 16:17:41 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w3JNHfB9067875; Thu, 19 Apr 2018 16:17:41 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804192317.w3JNHfB9067875@pdx.rh.CN85.dnsmgr.net> Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose In-Reply-To: To: cem@freebsd.org Date: Thu, 19 Apr 2018 16:17:41 -0700 (PDT) CC: Konstantin Belousov , Colin Percival , "freebsd-hackers@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:17:46 -0000 > On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov > wrote: > > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: > >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) > >> the boot time console output contains a large number of lines of the forms > >> > >> SMP: AP CPU #N Launched! > >> cpuN: on acpi0 > >> estN: on cpuN > >> > >> Having 128 almost-identical lines of output doesn't seem very useful, and > >> it actually has a nontrivial impact on the time spent booting. > >> > >> Does anyone mind if I hide these by default, having them only show up if > >> boot verbosity is requested? > > +1. For the device attaches, perhaps it makes sense to add a device > 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then > the generic attach code can choose whether to print spammy attaches > based on bootverbose. dmesg for device attaches seems mostly > redundant with devinfo(8) for persistent devices like ACPI CPU and > est(4). > > > The 'CPU XX Launched' messages are very useful for initial diagnostic > > of the SMP startup failures. You need to enable bootverbose to see the > > hang details, but for initial hint they are required. Unfortunately, AP > > startup hangs occur too often to pretend that this can be delegated to > > very specific circumstances. > > Really? I don't know that I've ever seen an AP startup hang. How > often do they occur? > What about if XX > 4 silence the messages unless bootverbose is set? That gets us kinda both worlds, you still see AP startup occuring, but once you seen 4 of them go off there isnt much point in seeing the next N of them. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Apr 19 23:34:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEA98F84371 for ; Thu, 19 Apr 2018 23:34:23 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 463F0796F4 for ; Thu, 19 Apr 2018 23:34:23 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id h4-v6so7718003qtn.13 for ; Thu, 19 Apr 2018 16:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4IOu6MPeXvxsm2XCG2gMuIKW3v18LBGtvfqH6OkzbnE=; b=N1M18poftP2NuyNOHAFJUfr4HZQkfDKX5qqJwh4uzX8T5O7javS4eFUeEC0cXp6M8I 3Kf4nSOyyXsP+IF0hT6w3yzplY44L9LxxOXwi+9mIWYU5zj6fm49HQx1z0KH4ZUW2bnx 7y3fkBnjEBeTt/6k1rVlXfgvXb2Rb13V8iIopLPeTAyDbgJcGeWggSfjFDiPVb/cFORD bKIFwNXLe/rpWV0GQzLEeGDoZta8ZW1wTP1qj3trEDY0gb4jhqAbPVU1RdUTvbRD/ccY cweuScu8S7uYzV9aK95X/AS5cSxsROEJZNwb2SXabZJCIfs0wB33vgoUDciHhnd3FB8m ab8Q== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4IOu6MPeXvxsm2XCG2gMuIKW3v18LBGtvfqH6OkzbnE=; b=GxbZILpx+CNcJI9kw1IEqwG7xf0udtsSiRTb1HbxffKVyb7RHbgna2gNuxoH43e8/K YlT3mPBW2Pd2U7YCusRCkSKGouNMk972Lht7qnKTYrobWtvviF9ZXOeaZNOHj1i3Mrvk l4ZVePwXtcCthVi1AgkGnDaicVSYDlRn7ZyvAcV1uqvKaB5mPF+j3LxwxrioTi3FWaBI MiAbvOpKbIy8+gmQrGds0QpUNoqFnEYlQm/BWEHK9l8MaBkdstJloHWWrJfN7l/36K/t MKXWeZ0vcJPY7vG13qP8MciThqlVRuRmzlwJy0scnZsqGNM+B0lqe/XpOHwRFtG8WXei qsdw== X-Gm-Message-State: ALQs6tDdQdgg7gZpt6t6HrJXPSvb+1hCR86Ipxvue7JiRm7h500yMJ1F ZeBy1mzSRneNRK4udRPvE10YFCPv X-Google-Smtp-Source: AB8JxZqdSuPQ4mXutOyWMGznJiJgb7nNgiq102AWB+fOTbHPPpGJPx6EjvK1BoH67X5xHRiWSxmJbw== X-Received: by 2002:ac8:7217:: with SMTP id a23-v6mr7779378qtp.204.1524180862410; Thu, 19 Apr 2018 16:34:22 -0700 (PDT) Received: from [155.41.75.211] (dhcp-wifi-8021x-155-41-75-211.bu.edu. [155.41.75.211]) by smtp.gmail.com with ESMTPSA id w67sm4012256qkg.54.2018.04.19.16.34.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 16:34:21 -0700 (PDT) Sender: Theron Tarigo Subject: Re: mount system call for nullfs To: alfix86 Cc: freebsd-hackers@freebsd.org References: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> <20180419172023.e19621515d3060295dccb2f5@gmail.com> From: Theron Tarigo Message-ID: <49a77715-e713-b1e3-326d-1ed3f08e4c97@gmail.com> Date: Thu, 19 Apr 2018 19:34:21 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180419172023.e19621515d3060295dccb2f5@gmail.com> 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:34:23 -0000 On 04/19/18 11:20, alfix86 wrote: ... > but was deleted [1], so I'll use nmount > > [0] http://fxr.watson.org/fxr/source/miscfs/nullfs/null.h?v=FREEBSD4 > [1] https://svnweb.freebsd.org/base/head/sys/fs/nullfs/null.h?r1=65467&r2=97186 There is in fact a suggestion that mount() system call be removed entirely: https://wiki.freebsd.org/IdeasPage#Userspace_mount.28.29_implementation From owner-freebsd-hackers@freebsd.org Fri Apr 20 06:11:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80A52FA8DA2 for ; Fri, 20 Apr 2018 06:11:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3AE71560 for ; Fri, 20 Apr 2018 06:11:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w3K6BfPB041341 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 19 Apr 2018 23:11:44 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: freebsd-hackers@freebsd.org References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> From: Julian Elischer Message-ID: <4be440e4-e70f-3652-e755-ed2d924ff3d2@freebsd.org> Date: Fri, 20 Apr 2018 14:11:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 06:11:46 -0000 On 20/4/18 4:48 am, Steven Hartland wrote: > Sounds good to me, I think we could actually benefit from even quieter > modes if I’m honest. > > On Thu, 19 Apr 2018 at 21:09, Colin Percival wrote: > >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) >> the boot time console output contains a large number of lines of the forms >> >> SMP: AP CPU #N Launched! >> cpuN: on acpi0 >> estN: on cpuN >> >> Having 128 almost-identical lines of output doesn't seem very useful, and >> it actually has a nontrivial impact on the time spent booting. >> >> Does anyone mind if I hide these by default, having them only show up if >> boot verbosity is requested? make them single line and just type a CR at the end so they cycle through on the same line. or "previous line repeated N times  with only 3 characters different" >> -- >> Colin Percival >> Security Officer Emeritus, FreeBSD | The power to serve >> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Fri Apr 20 12:08:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 508B8F98B48 for ; Fri, 20 Apr 2018 12:08:57 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 CF7217E727 for ; Fri, 20 Apr 2018 12:08:56 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-ot0-x22a.google.com with SMTP id i5-v6so9358869oth.1 for ; Fri, 20 Apr 2018 05:08:56 -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=VAatN4sRwCF4x2E4R8Mviqu6PljbDvNJMWboqBwPJBE=; b=sGqiZTasisrxfMo/DqbsS5O9YhQrM+Y1P4Fp2lhdCXBzB/mxzogawJ2zYlZRepAcHJ 1R5spjaDS+U+v1rumyY3a6w8pd8X0wscLsyB3cchw0EgUUlzHbvdbXjhGFgJ2T7iXkqz AbzfR1cx8+ylnwRYXBYWTguRmoyqgtRldCW85Aw2yyk8IxitdNh6AC9N7aNV3gMyZdpN 4D1JW6FRg1txrmFbFIlvCG3xIA4tEnGXXibJPE5eq+NeKdCu8mmxKQ2fCp9k8w3P32WC CYP6x9mdHgKihxV/uelAeAdmjrUJfFUPba0upPcA4PAeVV6U0IJVw5qWZtwt71VfaAwf tehA== 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=VAatN4sRwCF4x2E4R8Mviqu6PljbDvNJMWboqBwPJBE=; b=oGfCjlGQf6scyzn3xxtrmmKGlc+SWckhXH1QtHQbFun89eGrA/DMzKONCfVFP0QWmc Sz72RTaMy1bCcOCN0jHRt1+GtseKIOo9i1Znhd4AZddBwQhdw8mAaJKkY8weP9Z59AM+ oHxOxZdHEGA0aXbXP0BYsZHSQj1K4UKUIoo3CfxUAb/2n5NEZ1eoNpcBj6yCmi7S+rJy fRx3DZKg+MoLJ7IymNM3YLHf4cS/wTkClKp58qKUFS9QdRZDQj8O2TCgez+sgwpUDvHM qfv09uCMSbDmDGqgGx2QlideEb64+izn+a+8N1C51+gbFSP4PMhpZhaJh4O42bCkgCRg uh9A== X-Gm-Message-State: ALQs6tDIl3KtWYbEqBwdlFm7+AYzzntblnyRdew/RqQQxWSGpXn3Wgxk V04/YARBas6SVaEOayhx2yO/yvestphPVLMBXUJUdA== X-Google-Smtp-Source: AIpwx48E163fzRHkRE7XrYK86GYpH1QOVNuuAuVHIGyVkGm3htj+jojQZPogq8kUkc9HoLjoIXCkyCh8gRYqVrxYwZ4= X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr5656895otb.271.1524226136020; Fri, 20 Apr 2018 05:08:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.50.38 with HTTP; Fri, 20 Apr 2018 05:08:55 -0700 (PDT) From: Ali Abdallah Date: Fri, 20 Apr 2018 14:08:55 +0200 Message-ID: Subject: sched_setscheduler returns EPERM instead of EINVAL when sched_priority is out of range To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Fri, 20 Apr 2018 12:21:19 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 12:08:57 -0000 Hello, I got quite confused when I was getting EPERM from the sched_setscheduler system call on FreeBSD 11.1, thinking at the beginning that I had a permission problem (program uses setuid, and it is launched by normal user). After, I realized that my sched_param.sched_priority value was simply out of range. According to the documentation, [EINVAL] should be returned if the value of the policy argument is invalid, or one or more parameters contained in param is outside the valid range! In ksched.c line 180, the ksched_setscheduler functions returns EPERM when (param->sched_priority >= P1B_PRIO_MIN && param->sched_priority <= P1B_PRIO_MAX), on other Unices, I get EINVAL as expected. Is there is a reason for why FreeBSS handles this differently? Cheers, Ali From owner-freebsd-hackers@freebsd.org Fri Apr 20 18:09:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79BCEF8B26E for ; Fri, 20 Apr 2018 18:09:24 +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 F2F8C74C10 for ; Fri, 20 Apr 2018 18:09:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w3KHwCA1033549 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 20 Apr 2018 10:58:13 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Runaway processes freeze the system Message-ID: Date: Fri, 20 Apr 2018 10:58:11 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 18:09:24 -0000 I am getting this problem again and again: when some process allocates too much memory the system to freezes. My memory size is 24GB, and swap is only 4GB. I know that increasing the swap size should reduce the chance of this happening, but it obviously can't eliminate the problem. What is the expected behavior of the system in such situation? To me it looks like it is wait-and-see, and this causes this problem. A better strategy would be to maybe wait for some time, but if when the problem persists to kill the largest, the most active, or the offending process. 11.1 amd64 Yuri From owner-freebsd-hackers@freebsd.org Fri Apr 20 19:17:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 817C8F948FF for ; Fri, 20 Apr 2018 19:17:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 11B4183D90 for ; Fri, 20 Apr 2018 19:17:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id l22-v6so244680otj.0 for ; Fri, 20 Apr 2018 12:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TgCroV6fI22PpZ+wJKLBJrO98ckiJ4ECraDBlaKtCRs=; b=k1452kwPF9y4w3QFObcxBQHESxcOhBuXumpRW357dR+U835N+ForZ9XgeqYWgq2iCx 79MaKM6027+kJznQF7YQfHegKUl/IJyDPggwHRfQc5OVqsqL+DPWecYIGIDpzLsabE0u ulBILj6qvx5rChn8YeqMMv02j+A3NgWPKKO/J7CSaB1uFH1W57Z1pBpplvHVtwCP7JXu GNteYvDo6TxNloyLU0UiFvuWeG22vroa3t49cp2S9doRfZJDku3apqMex+GfUIi+nV4x YMG2u4/z8qIXvmvDkhqbzvFqNU0PmLm4NFL4Z0sdPx57boUiH7SyaUBR96alAA5nTkSt Xbow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TgCroV6fI22PpZ+wJKLBJrO98ckiJ4ECraDBlaKtCRs=; b=fNVIx+iN3nrbMfPzPpoUlpWyogZZ9X8OQU44hIIMFoXUNzQrmGkCKqADRttvkXYDkp 7gGDkwXsE6k9EJem3RmKDWQ4EURqPkwtLkJX5utMeONKT47zQgI6YfMd/2YTqKn9jgCy PIC97ZwsfJs38Znus6PkacEWwD3ZKk59rEnqCx42PFxAC8wACUQ4OOSdi6KdPiELsEbF yeva59Jf/cDDEyYTMhQ7FmrmsehAc4bW9tDpObls/ko0OmkCqvKJpK1QCKtYp5TuVmQW W/RisHt9HgpdsaCIm6+Gbr5jq49kUPTbbJWfI+YIKAw1uzR4F9HcCs+iKBbtaW9laxdn ZSuQ== X-Gm-Message-State: ALQs6tAuT7PmlkVxhapThSq3HRuWYoOhHYxkD7SnkbbKGIOKeA1tx4BW sg2Nxtp8Ig390ur0IGI3i5PeaPU9iS3zXCsK2mI= X-Google-Smtp-Source: AB8JxZodV8vPg2Khb7XlCgHaSe8sHmVmgsPMseNpYnKedcl6OAz7x3n55ZL1mi/cCtVMvPqSk7lWJk5PqYJEWNuYGqY= X-Received: by 2002:a9d:4a90:: with SMTP id i16-v6mr3429028otf.294.1524251862526; Fri, 20 Apr 2018 12:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Fri, 20 Apr 2018 12:17:41 -0700 (PDT) In-Reply-To: References: From: Stefan Blachmann Date: Fri, 20 Apr 2018 21:17:41 +0200 Message-ID: Subject: Re: Runaway processes freeze the system To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 19:17:43 -0000 Ideally rctl(8) should be the solution. Actions can be defined to refuse to allocate more memory or kill processes that demand too much memory. By turning off swap and restricting memory usage one can improve performance by preventing the swapper making the system sluggish. However, rctl is only of limited use for desktop users, as Xorg fails to start if vmemoryuse gets restricted (no matter how big the value). So rctl(8) appears of practical use only for example for protecting servers and embedded systems from crashing and damaging filesystems because of user programs eating up too much memory. I advise you to experiment with it, as the rctl(8) documentation/man page seems partly incorrect/misleading, for example regarding per-user resource limiting. On 4/20/18, Yuri wrote: > I am getting this problem again and again: when some process allocates > too much memory the system to freezes. > > My memory size is 24GB, and swap is only 4GB. I know that increasing the > swap size should reduce the chance of this happening, but it obviously > can't eliminate the problem. > > > What is the expected behavior of the system in such situation? To me it > looks like it is wait-and-see, and this causes this problem. > > A better strategy would be to maybe wait for some time, but if when the > problem persists to kill the largest, the most active, or the offending > process. > > > 11.1 amd64 > > > Yuri > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat Apr 21 00:08:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91CFEFADBF4 for ; Sat, 21 Apr 2018 00:08:54 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 18A44852C2 for ; Sat, 21 Apr 2018 00:08:54 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id j68-v6so7317214lfg.13 for ; Fri, 20 Apr 2018 17:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AJ8wW6ixv1oNbZzoA4mYVvGQhATdTi7h0KN7bFW1xuA=; b=Zrcd1+L2NGu5S9rqrKrd/5uOtiqTgTcD+1xM8M2whnON1Ov1s2hV3KezhDD8NhZ54W 6xTye3otiEJnyCQnvZl3852otrE+MQj2lFZyELxTjHmAGkDh/1IfzAB29VnLVitTiq+e y5BmWFojrZ5/li1gTuGQsjffWAhn6ctnnCQWnD4230AaZIiH3FWlMPNLl1WElgeEL3e/ IAwfN5JN696EPXjq7u60rV96c7hXULybw/1JJWF6UT6KzoW/HxkY9DpOTZOtfUP9HJBl QffdDvxKuKU55AG6R83hvAKDGMFo7ERtZJYr2pWYGFKX+n9DABuUyVpQUyvV2JbmR/Uf BZBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AJ8wW6ixv1oNbZzoA4mYVvGQhATdTi7h0KN7bFW1xuA=; b=JZ9towkOOnfBkH/Y1NZhvIQ1GjdPnq0tVGMRiIyuaZzgp6HLBQd27lidJsongagUQ0 2L9i613pceEmtkXfHXFA41to0R3uFXHYQ7gC7X3L55E+MMPt0xqh07e+f4/g1T4mFBr/ O/NM5vHyrdV99IHqotHDdq3zETCGuAcnJ372ylMtqeEMaPFVksurHcHMK3VN4lMiwfuX g++pMlMQ+kgXXDTd1KfXKZOPnTzn8OJhQyVB3MBLI1QU7BxQGzo/K4z7H6rvhEP6ABCR nIguu0BbllfqukjjTzD1XtV0E1f81n5ucZtx7wGc2j26hqwSv9B4chZeLHsr3flxN9q0 1Pxw== X-Gm-Message-State: ALQs6tDkXk1pRAvOZTzHWWHZKe10a4GeYpcdbNsMDy85gSlWM9e3phAT H5CvyB+xKizHgesRDPZXkvM= X-Google-Smtp-Source: AIpwx48eJRd5ObPEAl0OjNKl7Z734o4e1TZhfkSAdfJGk7X3TW3s7GZ1oP9KgLIKAg3o5rrtLSpsMw== X-Received: by 10.46.71.132 with SMTP id u126mr6014528lja.64.1524269332713; Fri, 20 Apr 2018 17:08:52 -0700 (PDT) Received: from localhost ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id 199sm1241828ljj.81.2018.04.20.17.08.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Apr 2018 17:08:51 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 21 Apr 2018 03:08:50 +0300 To: Stefan Blachmann Cc: Yuri , Freebsd hackers list Subject: Re: Runaway processes freeze the system Message-ID: <20180421030850.6fd1e182@gmail.com> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 00:08:54 -0000 On Fri, 20 Apr 2018 21:17:41 +0200 Stefan Blachmann wrote: > Ideally rctl(8) should be the solution. > Actions can be defined to refuse to allocate more memory or kill > processes that demand too much memory. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195882 I do not try it with 11.1, but rctl will not help for this case. From owner-freebsd-hackers@freebsd.org Sat Apr 21 00:11:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A1C9FADE59 for ; Sat, 21 Apr 2018 00:11:14 +0000 (UTC) (envelope-from 01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@amazonses.com) Received: from a8-56.smtp-out.amazonses.com (a8-56.smtp-out.amazonses.com [54.240.8.56]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB7F885F1A for ; Sat, 21 Apr 2018 00:11:13 +0000 (UTC) (envelope-from 01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524269467; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=1akbAon8rasTDWuShxU8zGH48iklbSYpCHWYA8+UU94=; b=OK4TmhPCxc1VPLJ+EURjVZy1EqCy0AmVfCj5GJ8BhXBTarO+84Vz1+8YTSxEFrZt OqdJ6ExdbJYw110jtsXVNREaVxLM4m7fFFbVtVpP6qrneIGcpN9CZpBdF2Hhq5SREv9 eIFo7bipDFghtoxw//w9x0HYnXm8EXoHWplYF478= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524269467; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=1akbAon8rasTDWuShxU8zGH48iklbSYpCHWYA8+UU94=; b=O+9TUry9boKkrtfe5Zbni5wZELPVrwTbahrTPfz9uxP1PbOScQHWD5Lx1TyxYXBx xUkzCs009zNolDkAS+58extcTCxwyWQtx+1KJxxWny0RTHL+MU4B9XlCVSy4hq8Sz+w +nvmsqQKYxBSjgEXW7x1UF88x33QwLcc4AN+exZk= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Konstantin Belousov , Conrad Meyer Cc: "freebsd-hackers@freebsd.org" References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> Date: Sat, 21 Apr 2018 00:11:07 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180419214550.GF6887@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2018.04.21-54.240.8.56 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 00:11:14 -0000 On 04/19/18 14:45, Konstantin Belousov wrote: > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: >>> The 'CPU XX Launched' messages are very useful for initial diagnostic >>> of the SMP startup failures. You need to enable bootverbose to see the >>> hang details, but for initial hint they are required. Unfortunately, AP >>> startup hangs occur too often to pretend that this can be delegated to >>> very specific circumstances. >> >> Really? I don't know that I've ever seen an AP startup hang. How >> often do they occur? > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > supplier and its interaction with the x2APIC enablement, see madt.c:170 > and below. > > There were several recent reports of the issue with Broadwell Xeon > machines, no additional data or resolution. > > There are sporadic reports of the problem, where I do not see > a clear commonality. Would it be sufficient for debugging purposes if I change the !bootverbose case from printing many lines of SMP: AP CPU #N Launched! to instead have a single SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 36 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 67 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 22 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 16 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 108 106 122 117 114 26 110 59 76 124 119 ? (With each AP printing its number as it reaches the appropriate point?) This yields almost the same gain as silencing the launch messages completely, while still allowing you to see each CPU announcing itself. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Sat Apr 21 06:57:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9F8FA7936 for ; Sat, 21 Apr 2018 06:57:15 +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 C7EE78044E for ; Sat, 21 Apr 2018 06:57:14 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w3L6vCrR015279 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 20 Apr 2018 23:57:13 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me Subject: Re: Runaway processes freeze the system To: Freebsd hackers list References: From: Yuri Message-ID: Date: Fri, 20 Apr 2018 23:57:11 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 06:57:15 -0000 On 04/20/18 12:17, Stefan Blachmann wrote: > Ideally rctl(8) should be the solution. > Actions can be defined to refuse to allocate more memory or kill > processes that demand too much memory. > > By turning off swap and restricting memory usage one can improve > performance by preventing the swapper making the system sluggish. > > However, rctl is only of limited use for desktop users, as Xorg fails > to start if vmemoryuse gets restricted (no matter how big the value). > So rctl(8) appears of practical use only for example for protecting > servers and embedded systems from crashing and damaging filesystems > because of user programs eating up too much memory. > > I advise you to experiment with it, as the rctl(8) documentation/man > page seems partly incorrect/misleading, for example regarding per-user > resource limiting. I am trying to understand what happens when both memory and swap are completely exhausted, and some process still tries to allocate more. This process calls mmap, but it can't succeed. There are only a few things that the kernel can do: 1. wait in a hope that some other process will return some memory soon 2. fail mmap 3. kill some process to free memory. It seems like the current behavior is to wait indefinitely. First one large offending process freezes. Then other, smaller processes that attempt to allocate some more memory also freeze, one by one, and the whole system becomes unusable. I am trying to understand why this behavior occurs, instead of options 2 or 3? Are there any relevant sysctl variables? Is this a conscious choice of behavior? Is there some malfunction involved, and this isn't the intended behavior? Yuri From owner-freebsd-hackers@freebsd.org Sat Apr 21 08:58:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 438F8FB0A3A for ; Sat, 21 Apr 2018 08:58:33 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CAF7C806 for ; Sat, 21 Apr 2018 08:58:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w3L8wSKL037009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Apr 2018 10:58:28 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w3L8wM9O037006; Sat, 21 Apr 2018 10:58:23 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 21 Apr 2018 10:58:22 +0200 (CEST) From: Wojciech Puchar To: Yuri cc: Freebsd hackers list Subject: Re: Runaway processes freeze the system In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 08:58:33 -0000 > size should reduce the chance of this happening, but it obviously can't > eliminate the problem. > > > What is the expected behavior of the system in such situation? To me it looks > like it is wait-and-see, and this causes this problem. > > A better strategy would be to maybe wait for some time, but if when the > problem persists to kill the largest, the most active, or the offending > process. > > > 11.1 amd64 it's better to have more swap than memory. second it's good to use ulimit to prevent overallocating memory you may just edit login.conf and do cap_mkdb /etc/login.conf and relogin From owner-freebsd-hackers@freebsd.org Sat Apr 21 09:21:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ADD8FB222B for ; Sat, 21 Apr 2018 09:21:03 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9402801BF; Sat, 21 Apr 2018 09:21:02 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3L9KokR021969 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Apr 2018 12:20:53 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3L9KokR021969 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3L9KnS4021959; Sat, 21 Apr 2018 12:20:49 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sat, 21 Apr 2018 12:20:49 +0300 From: Konstantin Belousov To: Colin Percival Cc: Conrad Meyer , "freebsd-hackers@freebsd.org" Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <20180421092049.GM6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 09:21:03 -0000 On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > On 04/19/18 14:45, Konstantin Belousov wrote: > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > >>> The 'CPU XX Launched' messages are very useful for initial diagnostic > >>> of the SMP startup failures. You need to enable bootverbose to see the > >>> hang details, but for initial hint they are required. Unfortunately, AP > >>> startup hangs occur too often to pretend that this can be delegated to > >>> very specific circumstances. > >> > >> Really? I don't know that I've ever seen an AP startup hang. How > >> often do they occur? > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > supplier and its interaction with the x2APIC enablement, see madt.c:170 > > and below. > > > > There were several recent reports of the issue with Broadwell Xeon > > machines, no additional data or resolution. > > > > There are sporadic reports of the problem, where I do not see > > a clear commonality. > > Would it be sufficient for debugging purposes if I change the !bootverbose > case from printing many lines of > > SMP: AP CPU #N Launched! > > to instead have a single > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 36 > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 67 > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 22 > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 16 > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 108 > 106 122 117 114 26 110 59 76 124 119 > > ? (With each AP printing its number as it reaches the appropriate point?) > > This yields almost the same gain as silencing the launch messages completely, > while still allowing you to see each CPU announcing itself. I am fine with the behaviour, but I am not sure how would you implement this. printf(9) buffers the output, you need to flush it somehow. From owner-freebsd-hackers@freebsd.org Sat Apr 21 10:35:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89D60F86E3A for ; Sat, 21 Apr 2018 10:35:48 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 0055270A67; Sat, 21 Apr 2018 10:35:48 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id q3-v6so18920196wrj.6; Sat, 21 Apr 2018 03:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=otAi6SMt9JmtcC8eASn2Lc57MDI3G9FJ6QpmI0lpC1k=; b=rq/l1sFktNjL2s/rmOC8bMOqPAb4RF5QDYgJsq24bO5pftoBrXxD/drKVPdcgMoMwi fn/jsV2fEBeBAFl00otgDLZ5H3g2SQW2GNpl3zijx2K9v247zCvxvxmq+QDmE7NGwNcs m+LrncesjI5vT5z4SiCM6KiqHpIe6uJMjqiAbv2UDdIQKZfusYp2GocwMLfZ2uu8OOz1 80GZUxlwAoo4gnjev47AqS6Eja09JJaDfw3i7UeOMsxALlePFdUqya8+qqxE94aHXQBe cNdDn9LWOGYOCrXP4gpnZEqxEprNkV+sV6wjW5DdAqrqvpSGeRph2Tm0eYdTcPPCimKY AXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=otAi6SMt9JmtcC8eASn2Lc57MDI3G9FJ6QpmI0lpC1k=; b=rgMZ4HFS5JKHwpEJgLZKR480VMdXwfetUHKuOY0TivU9wSt3XtoVeX3K4Qiy90B1yI uHEJHZk8XKpdmqVEn6+q/YuxrhuDNRpb3DLxoFvr9xqzfeQSKek9cLV9CeepCUfRjh5I 2mv4KyBAGDTjgeSBP9N/QFseeWZydVSejqTX7o1ktK7yfVy5bwjy/2wzy4OTMYlbPNvR crD9jiyqp6nX8XMQZ1RFB/SFGiYGB5wED5HA0g+PfZQ6VioWpWegv5qijTj2dg1NnZzt ylW0dml9DCr7ky2HpbrFQTJsdch5NpaqreC+rB0fx+s39EpMj4WqzifnBPlszBA0FdGX s5Tw== X-Gm-Message-State: ALQs6tBRhFqsDxqIEPDUv9mX+7WBdvmI7BNm3dhsNlBKU5pluF5sMPXg 54qyqUzEroF5Lw5fnrVgBVm5eA== X-Google-Smtp-Source: AIpwx4+SUs2e0eyaXbvFGsM1PWeuEUw98Aqm7z6T0ynptwfysu5ytdsNG8YxlorRi7oN7ioNinXEUQ== X-Received: by 2002:adf:9cc5:: with SMTP id h5-v6mr10182405wre.11.1524306946411; Sat, 21 Apr 2018 03:35:46 -0700 (PDT) Received: from ernst.home (pD9E23019.dip0.t-ipconnect.de. [217.226.48.25]) by smtp.gmail.com with ESMTPSA id 58-v6sm15558027wrv.41.2018.04.21.03.35.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 21 Apr 2018 03:35:45 -0700 (PDT) Date: Sat, 21 Apr 2018 12:35:44 +0200 From: Gary Jennejohn To: Konstantin Belousov Cc: Colin Percival , "freebsd-hackers@freebsd.org" , Conrad Meyer Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <20180421123544.56d7e690@ernst.home> In-Reply-To: <20180421092049.GM6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 10:35:48 -0000 On Sat, 21 Apr 2018 12:20:49 +0300 Konstantin Belousov wrote: > On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > > On 04/19/18 14:45, Konstantin Belousov wrote: > > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > > >>> The 'CPU XX Launched' messages are very useful for initial diagnostic > > >>> of the SMP startup failures. You need to enable bootverbose to see the > > >>> hang details, but for initial hint they are required. Unfortunately, AP > > >>> startup hangs occur too often to pretend that this can be delegated to > > >>> very specific circumstances. > > >> > > >> Really? I don't know that I've ever seen an AP startup hang. How > > >> often do they occur? > > > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > > supplier and its interaction with the x2APIC enablement, see madt.c:170 > > > and below. > > > > > > There were several recent reports of the issue with Broadwell Xeon > > > machines, no additional data or resolution. > > > > > > There are sporadic reports of the problem, where I do not see > > > a clear commonality. > > > > Would it be sufficient for debugging purposes if I change the !bootverbose > > case from printing many lines of > > > > SMP: AP CPU #N Launched! > > > > to instead have a single > > > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 36 > > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 67 > > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 22 > > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 16 > > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 108 > > 106 122 117 114 26 110 59 76 124 119 > > > > ? (With each AP printing its number as it reaches the appropriate point?) > > > > This yields almost the same gain as silencing the launch messages completely, > > while still allowing you to see each CPU announcing itself. > I am fine with the behaviour, but I am not sure how would you implement > this. printf(9) buffers the output, you need to flush it somehow. > And printf(9) calls vprintf(9) which in turn calls _vprintf which will allocate a buffer on the stack (bad idea) if the option PRINTF_BUFR_SIZE is set in the kernel config file. So it seems that output may even be double buffered. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Sat Apr 21 13:03:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8681CFA4043 for ; Sat, 21 Apr 2018 13:03:03 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 1A747727A5; Sat, 21 Apr 2018 13:03:03 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ot0-x242.google.com with SMTP id q10-v6so7780109oth.9; Sat, 21 Apr 2018 06:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HD51phsHu4tOe0xTwak0SgtMLdMdOjn8B1WCeq3mahE=; b=RRPz2Tevgmj0M7yH8v4K6I1/tn80umM9KVFz1d9G6aj1uLk9cCxnFBOdSG5uYzotfH 1AZpY4D0dB3Cfu1n0p7X1Lz+gQghOAbf+aYf/MehdmukEHNcWt2z6NxS3JL1G+z8sAvf owdVKvFSHa34RIP+2phHoRfmTd7ChzTn6av3WI5qG2Npb9tXhhJQFNyC2lRnQgXuSymi gDKlUQiO2HPASrFmIKqaaRaqPvTJR7eL2uRZowlqIIn5bGpbh5PVYgMUSF5SNVKGGSd6 7EHb3fF8sSNy8DY7y5vRgI0Mxp/a8CAYM92r64U0GREQviDm0FG/WO4aBHbMAiVmHQzJ 4jvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HD51phsHu4tOe0xTwak0SgtMLdMdOjn8B1WCeq3mahE=; b=fWvQ+CJlY9mlV2JEzZAYuXNBxP9gt0iigH7Z4HHohq2d9HRNlJdUoWzoz16Mz8utfk itglIWUAIsr0ygxB7+ruv92LsSWqqfAiilL7QKBtNMxIZ8ABdhdYYGUpHWJExYmJx//V 8aVckTLxtPER3dy+eTKzyGHKZOU6ybA2PQBlcl8mufD7g6TASl3g7WvDDzOFaZxuZeir Oi409wK25E3tN21omAfhHBhWkHhatj3IfePPfuic5RbwYDpGO5AxBaEZMgDQeEUxoUUb n7pjOkUoitOk4qyUYhrwVUhmf2J37M8E5yze+qBa67/eFxIzGGDHBoXDIW2XtSkICvra ZOBQ== X-Gm-Message-State: ALQs6tCe8mkB2JmuscwDUqj8Tql9lfpuXM8pf/dBwaM/GUTxCXGM1rmF 4K1ZAkwSVyuvmTm+4TSR+Yf2b5hxzLq4SJwWpUI= X-Google-Smtp-Source: AB8JxZovFyGbYzdurgb72q5RYmRWGqA40cMlGwnWCrtz7qapuksT+DKdfsgEG0MnAvTP4Mq/Pi6YNx7rdbBaZ6nKcTs= X-Received: by 2002:a9d:fad:: with SMTP id d42-v6mr4339181otd.358.1524315782315; Sat, 21 Apr 2018 06:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Sat, 21 Apr 2018 06:03:01 -0700 (PDT) In-Reply-To: <20180421123544.56d7e690@ernst.home> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Stefan Blachmann Date: Sat, 21 Apr 2018 15:03:01 +0200 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: gljennjohn@gmail.com Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Colin Percival , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 13:03:03 -0000 There are not many places that call the cpu initializing routine. Thus it should be easy to add a pointer to the output function to be used. What about solving the problem using simple code like I did this in sysutils/cpupdate? (https://github.com/kernschmelze/cpupdate) [BEGIN PSEUDOCODE SNIPPET] print_cpu_stats( stringbuffer *info, int from, int to) { print( "Core %d to %d: %s", from, to, info); } initialize_all_cpus() { int startcore = 0; int ncore = 1; stringbuffer *ncoreinfo, *startcoreinfo = initializeCPU(0, functionPointerPrintToStringBuffer); for ( ; ncore < numCores ; ++ncore) { ncoreinfo = initialize_one_CPU(ncore, functionPointerPrintToStringBuffer); if ( ) { // core #ncore is different than core #startcore..#(ncore-1). // Print core info for that block print_cpu_stats( startcoreinfo, startcore, ncore - 1); startcore = ncore; startcoreinfo = ncoreinfo; } } // make sure also the last block of identical cores are shown if (startcore < ncore) print_cpu_stats( startcoreinfo, startcore, ncore - 1); } [END PSEUDOCODE SNIPPET] Only such a small change would be necessary in the bootup code and in cpuctl.c to avoid massive spamming when updating microcode. But I have given up attempting to contribute to FreeBSD, because of the gross lack of interest on core developers' side in things important to people running FreeBSD on bare metal. For example, it is just amazing to see how all reports about massive flaws in kernel microcode detection/updating and all offered patches are being blatantly ignored for many years. See for example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487 Sad, very sad! On 4/21/18, Gary Jennejohn wrote: > On Sat, 21 Apr 2018 12:20:49 +0300 > Konstantin Belousov wrote: > >> On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: >> > On 04/19/18 14:45, Konstantin Belousov wrote: >> > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: >> > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: >> > >>> The 'CPU XX Launched' messages are very useful for initial >> > >>> diagnostic >> > >>> of the SMP startup failures. You need to enable bootverbose to see >> > >>> the >> > >>> hang details, but for initial hint they are required. Unfortunately, >> > >>> AP >> > >>> startup hangs occur too often to pretend that this can be delegated >> > >>> to >> > >>> very specific circumstances. >> > >> >> > >> Really? I don't know that I've ever seen an AP startup hang. How >> > >> often do they occur? >> > > >> > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS >> > > supplier and its interaction with the x2APIC enablement, see >> > > madt.c:170 >> > > and below. >> > > >> > > There were several recent reports of the issue with Broadwell Xeon >> > > machines, no additional data or resolution. >> > > >> > > There are sporadic reports of the problem, where I do not see >> > > a clear commonality. >> > >> > Would it be sufficient for debugging purposes if I change the >> > !bootverbose >> > case from printing many lines of >> > >> > SMP: AP CPU #N Launched! >> > >> > to instead have a single >> > >> > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 >> > 113 36 >> > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 >> > 18 67 >> > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 >> > 37 22 >> > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 >> > 115 16 >> > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 >> > 25 108 >> > 106 122 117 114 26 110 59 76 124 119 >> > >> > ? (With each AP printing its number as it reaches the appropriate >> > point?) >> > >> > This yields almost the same gain as silencing the launch messages >> > completely, >> > while still allowing you to see each CPU announcing itself. >> I am fine with the behaviour, but I am not sure how would you implement >> this. printf(9) buffers the output, you need to flush it somehow. >> > > And printf(9) calls vprintf(9) which in turn calls _vprintf which > will allocate a buffer on the stack (bad idea) if the option > PRINTF_BUFR_SIZE is set in the kernel config file. So it seems > that output may even be double buffered. > > -- > Gary Jennejohn > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat Apr 21 14:55:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28AFEFAAF1D for ; Sat, 21 Apr 2018 14:55:12 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 750F287712; Sat, 21 Apr 2018 14:55:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 9tunfEa54brv99tuoflYOJ; Sat, 21 Apr 2018 08:55:04 -0600 X-Authority-Analysis: v=2.3 cv=JOMVTfCb c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=xfDLHkLGAAAA:8 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=f0I3owjPZEPjKYQvSk4A:9 a=CjuIK1q_8ugA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 109031781; Sat, 21 Apr 2018 07:55:01 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w3LEt08M076409; Sat, 21 Apr 2018 07:55:00 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w3LEt0sa076406; Sat, 21 Apr 2018 07:55:00 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804211455.w3LEt0sa076406@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Stefan Blachmann cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Colin Percival , Conrad Meyer Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose In-Reply-To: Message from Stefan Blachmann of "Fri, 20 Apr 2018 01:05:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Apr 2018 07:55:00 -0700 X-CMAE-Envelope: MS4wfAMHrjhw3UIr9YT0N0urYK13lLc7X1AnVpMl+l4eFtEzF2P039om9k3mel6bAr9nRlkFDHZ3eLqmNeoQe+CWjm5osakRg+bBgHRinfOuqOdgXYCbAera MscSYUWUPM3LAbHeY4w5QjLkJhHofu+27lbrLr9vG0HBLCDldCiDvUKLSg2aH/TWVxY3v4QESgaKKTPllfqhyJwe3FkA0wSLimbfBJ77map01R0XOXTMUnxw r5ZzC451iM/n5F0h6Cvk1APiGGbiQYAOAcASrqVNmafMW4NUjVhb8zj8bnwpW71ysWtDDxG4aG9CiVWBbVzkHw== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 14:55:12 -0000 In message , Stefan Blachmann writes: > I would also like a solution to this issue, which is looking highly > unprofessional and uselessly wasting space in the dmesg ring buffer. Really? Have you looked at Red Hat (or Oracle) Linux or Solaris dmesg output? Why neuter the dmesg ring buffer? > > In the first version of my sysutils/cpupdate tool I also had spammy > output like being complained about. > This was hard-to-read. Thus I changed code so that identical cores > output was collected up in blocks of single output, i.e.: "core #n to > #m: ". > If all cpus are identical, cpu stats will be output only once this > way, else in subsequent blocks comprising all identical cores on > different cpus. > > To avoid the spamming at bootup and microcode updating, the kernel > would need such a function to read/evaluate *all* cores in a row, like > I did in cpupdate. > This would be only a few lines of code. Maybe the solution is a Red Hat style of slider bar or a Windows style graphic to hide messages. Personally, a Red Hat style of slider might work. Hit the enter to see the gory details. Hit enter again to see the slider bar again. It doesn't have to be a slider -- we don't want to look like a RH derivative. It can be any kind of progress indicator. Additionally, green and red checkboxes like HP/UX and Red Hat (they ripped that off from HP) is okay but when something fails you're in the dark. (At $JOB we use HP SA, with its green checkmarks and red x's on various dashboard style outputs. All you can tell is something is out of compliance but not where the actual problem is. This is totally unacceptable.) ~cy > > > On 4/19/18, Konstantin Belousov wrote: > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov > >> wrote: > >> > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: > >> >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 > >> >> vCPUs) > >> >> the boot time console output contains a large number of lines of the > >> >> forms > >> >> > >> >> SMP: AP CPU #N Launched! > >> >> cpuN: on acpi0 > >> >> estN: on cpuN > >> >> > >> >> Having 128 almost-identical lines of output doesn't seem very useful, > >> >> and > >> >> it actually has a nontrivial impact on the time spent booting. > >> >> > >> >> Does anyone mind if I hide these by default, having them only show up > >> >> if > >> >> boot verbosity is requested? > >> > >> +1. For the device attaches, perhaps it makes sense to add a device > >> 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then > >> the generic attach code can choose whether to print spammy attaches > >> based on bootverbose. dmesg for device attaches seems mostly > >> redundant with devinfo(8) for persistent devices like ACPI CPU and > >> est(4). > >> > >> > The 'CPU XX Launched' messages are very useful for initial diagnostic > >> > of the SMP startup failures. You need to enable bootverbose to see the > >> > hang details, but for initial hint they are required. Unfortunately, AP > >> > startup hangs occur too often to pretend that this can be delegated to > >> > very specific circumstances. > >> > >> Really? I don't know that I've ever seen an AP startup hang. How > >> often do they occur? > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > supplier and its interaction with the x2APIC enablement, see madt.c:170 > > and below. > > > > There were several recent reports of the issue with Broadwell Xeon > > machines, no additional data or resolution. > > > > There are sporadic reports of the problem, where I do not see > > a clear commonality. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Sat Apr 21 17:00:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B55FFB2C06 for ; Sat, 21 Apr 2018 17:00:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F04F07BA25; Sat, 21 Apr 2018 17:00:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w3LH0QVi049273 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2018 10:00:29 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Stefan Blachmann , gljennjohn@gmail.com Cc: "freebsd-hackers@freebsd.org" , Colin Percival , Konstantin Belousov , Conrad Meyer References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Julian Elischer Message-ID: Date: Sun, 22 Apr 2018 01:00:21 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 17:00:39 -0000 On 21/4/18 9:03 pm, Stefan Blachmann wrote: > For example, it is just amazing to see how all reports about massive > flaws in kernel microcode detection/updating and all offered patches > are being blatantly ignored for many years. See for example: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487 yes I saw that but Only a handful of people know what's going on there so 99% of the developers just stood back and said "I hope someone who understands this picks it up". I didn't follow the one response I saw. So I couldn't decide on who had the better argument. From owner-freebsd-hackers@freebsd.org Sat Apr 21 17:02:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCE9CFB31D2 for ; Sat, 21 Apr 2018 17:02:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 665B47C8FE for ; Sat, 21 Apr 2018 17:02:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id d6-v6so13887412iog.1 for ; Sat, 21 Apr 2018 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gMHxVTSuji4TP3x0P5qLJZCkwUyt3QAZHJrEhepmnIE=; b=uwNOISH5lcak5EYYurrWAG8UCC7Gim0XrzSOIBEiqmn8v82Z0VXv0q+kRmEkhqbK5X gJu+D9uZEeDnDKZpCZrxC6t5R/awUrVAbEm5/qFKvSUaarbC8AfC2A9ejrXpllByXbpN MM0/1vykIolbDKfd6Onj4jed53sVkGKMfgc2E4VkdD2nSD2lrJ3Nu/brnHEN6C5sFnB+ xEJzLfOMrZFLnTpILfn0zYNTDOa5oPN5kPv6ccwqTjufVEaFqtcLAV3PMHBSZvYIiFoz 9XqBOuKOc74IHDLqMp1T17Wd8XlY/xiEsU71Zhh7W91eArBkdwUTgByD+T7AWUZtQWPM Gp5Q== 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=gMHxVTSuji4TP3x0P5qLJZCkwUyt3QAZHJrEhepmnIE=; b=uM1JZsrb5tVwip1NGEWvQ7chkYO61DReRiMkX7BMcsDo6/j/uNYbKQO1OhA/t0Qn5/ 0RTW5CJ4CCSUeUCro/AoNeAe5IgXaR/J5+3jsO1Yb0jDxICoR8EN7XMQHIRU+8To6qnE fcpXcIUotkK2Dj51h9AlU0bejEAluKt+OiUCvfBwqVxrTgWMEj5s5/UBz1Rv6SC6+O6Z R1DctGVzV5UCByzijpV9Gu/UaI8BJcHKukwMkIpXPBcTKNcvBCfEookdcXTm0FvHCIyl GG6thkvD8q4Kz4tac3MnLr1kgPGncNNaNj+ZOo/fKg2eY+VE0lecXQ+J1KCBy3yudbPD c+3w== X-Gm-Message-State: ALQs6tCPKXamn1+AXGbBsxa6I4wGwtR0ROOqm7wMqkymLsQ1rr+H92UR k9ZEFgLvCkQ1ZxW1xdstCXJcDcqch7ElyNySgIorXw== X-Google-Smtp-Source: AB8JxZr7wl87uSjgJo3qnmo+M4XYirtsQ9M5DpoZkmmIMbPV1wClrgsj+DXS9PjpdGNM/jc3uDfch9IS5GSlk4UEOuI= X-Received: by 2002:a6b:d404:: with SMTP id l4-v6mr12558012iog.37.1524330161575; Sat, 21 Apr 2018 10:02:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 10:02:40 -0700 (PDT) X-Originating-IP: [107.77.200.57] In-Reply-To: <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> From: Warner Losh Date: Sat, 21 Apr 2018 11:02:40 -0600 X-Google-Sender-Auth: 2i4Ma6_N0oj1SloNQVl3lPf2L-M Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Colin Percival Cc: Konstantin Belousov , Conrad Meyer , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 17:02:43 -0000 On Fri, Apr 20, 2018 at 6:11 PM, Colin Percival wrote: > On 04/19/18 14:45, Konstantin Belousov wrote: > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > >>> The 'CPU XX Launched' messages are very useful for initial diagnostic > >>> of the SMP startup failures. You need to enable bootverbose to see the > >>> hang details, but for initial hint they are required. Unfortunately, AP > >>> startup hangs occur too often to pretend that this can be delegated to > >>> very specific circumstances. > >> > >> Really? I don't know that I've ever seen an AP startup hang. How > >> often do they occur? > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > supplier and its interaction with the x2APIC enablement, see madt.c:170 > > and below. > > > > There were several recent reports of the issue with Broadwell Xeon > > machines, no additional data or resolution. > > > > There are sporadic reports of the problem, where I do not see > > a clear commonality. > > Would it be sufficient for debugging purposes if I change the !bootverbose > case from printing many lines of > > SMP: AP CPU #N Launched! > > to instead have a single > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 > 36 > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 > 67 > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 > 22 > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 > 16 > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 > 108 > 106 122 117 114 26 110 59 76 124 119 > > ? (With each AP printing its number as it reaches the appropriate point?) > > This yields almost the same gain as silencing the launch messages > completely, > while still allowing you to see each CPU announcing itself. The trouble is that you've got N CPUs that are doing output at the same time. You'll need to synchronize somehow. And how do you know that the last one is done? Especailly if one of the CPUs doesn't start.. It looks great in theory, but I'm not sure how you'd make it work in practice. The other stuff (cpu and per-cpu stuff) is actually easy to pare down entirely inside of newbus. I'll share a patch to do that. Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 17:04:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 389E2FB3476 for ; Sat, 21 Apr 2018 17:04:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B67A37D3FD for ; Sat, 21 Apr 2018 17:04:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x241.google.com with SMTP id d6-v6so13889833iog.1 for ; Sat, 21 Apr 2018 10:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2fhSJvcYCLvjSnZWiV3wPPBRBSbwwDBUCM0AnLk0D5E=; b=D/Xg1KXWCFmyR4KeE6DaWAg5JobYUOJzTtXP9fy/kpi0xbXr8IAxP+tjdNfjbOcHvw 6P/ey1GecGs4RenFy3ib6/5Ff6olzgjUPe267YSpfn4895R82UvoBIZQ+jsvO+YUEDbC fhPFZzQeRE9+4X+CAhDu6LJS4JuHESrvoICJYBEgUJOXmLk0wn4QafxAsA6P6djnMzzA YU9tsGqXMQOvICKUe0M3Q92OzAVLtpWRFwZ2COpbP0V2r+4EajOZtH52+4xVKc9yGnTp 7MlsTdNJvW02eQMrhqBbcnpXilEO+gul2Dvu/m0g3r/8PtQqZ2cOHu3+tqBoobqx3GLI Ft7g== 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=2fhSJvcYCLvjSnZWiV3wPPBRBSbwwDBUCM0AnLk0D5E=; b=RcGQ88OMpEZppp1KLcXuA+ZGRJ4GgyVSHB5g1xDybLPy+bgfuSb6SeoF5Pnex2YtwG C/dPq7GmDpGAVfs9PJmojdKqH2dX3rvhkMCmvsyDwgYPrHE+tLMqikuAGbzAQ4fo66Be 3xL1+dDfpWq/+lbCTPisXHJipaA0r4XvgQ2mIdeTeuIvjN1UypbWVGDLS7rO+mCfCGcG hZbg92fCl041cXBCi3TYnmYhWaWA5Jn3Cob50BZkUAmIorJx+MsGRy03nEEmLmMCCMb9 Vrfx4oph/JYYFKjio0jYKcRPAldnhaQgyqRZxg7wTkYbPcTFd/S0a22ywgn6m8zJwQ3A ZMjw== X-Gm-Message-State: ALQs6tB/ZYYSsfBNt0GgBNUO1jKNVUHgm50i+gVbEzAI0n279P+L88El Twz6oOxIiQi+t8r5D0UxJy/cyk3Xu8TXsGs+bkhFCg== X-Google-Smtp-Source: AIpwx48fWQm417J5zxzTAeiNhWMkctNC3sQeUfTHXIl4sNUJhS/PQ6UpF+xcmtZSxWpRRfes6j7kZsk4zbomXFFpd4w= X-Received: by 2002:a6b:be01:: with SMTP id o1-v6mr14664056iof.299.1524330252094; Sat, 21 Apr 2018 10:04:12 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 10:04:11 -0700 (PDT) X-Originating-IP: [107.77.200.57] In-Reply-To: References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Warner Losh Date: Sat, 21 Apr 2018 11:04:11 -0600 X-Google-Sender-Auth: 64YjlNXtaOG43UJKoSvj2a2Oakg Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Julian Elischer Cc: Stefan Blachmann , gljennjohn@gmail.com, "freebsd-hackers@freebsd.org" , Colin Percival , Konstantin Belousov , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 17:04:13 -0000 On Sat, Apr 21, 2018 at 11:00 AM, Julian Elischer wrote: > On 21/4/18 9:03 pm, Stefan Blachmann wrote: > >> For example, it is just amazing to see how all reports about massive >> flaws in kernel microcode detection/updating and all offered patches >> are being blatantly ignored for many years. See for example: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487 >> > yes I saw that but Only a handful of people know what's going on there so > 99% of the > developers just stood back and said "I hope someone who understands this > picks it up". > I didn't follow the one response I saw. So I couldn't decide on who had > the better argument. Except that I said "sure, I'll integrate it, but you need to do these things" and Stefan said "oh, lemme get you the code" and I never heard back anything except complaints that it hasn't been integrated yet. Not playing well with others makes them less willing to help you. Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 17:30:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B9FDFB4FAF for ; Sat, 21 Apr 2018 17:30:25 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A48B84412; Sat, 21 Apr 2018 17:30:25 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id e23-v6so10738391oiy.1; Sat, 21 Apr 2018 10:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LkyI7cystr8ySfMNmaxYUwbeSQhMNwOstSRJ51yk9PM=; b=RNC5QO6aSkmkJLqISoj4lQ4gnnm5C+SEtZiQ3Tykb6XuaRcO272NrAwhj/zCHUO1xb cnZKi+/sj5Rk6/t5qOkrOFNgnvfbubsOVJXPIy8w0oEScZ1o8t0VzyXWqj7MwJLJ47PS kDO/RsfO5AourYTilV+yS1cYPb2RzxFVlhwPVFd9+IY2zcJ0z4g4OyszoWey4C8Nl18l tGy+UdDm2sU1pO1A3yKX+jZaoPr6VqMnp7AD5R+3v0jpa4Z9Uz8WggSQmOPU7CSRoCgW Bkuo5Z1CMMewYUd72eJXLyWTsQOjxvNRJ6a1+vzAa7i+npAxQESsclCjbOd0zWmVDzVz +pmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LkyI7cystr8ySfMNmaxYUwbeSQhMNwOstSRJ51yk9PM=; b=r4jVakBV9p6dydzPzvHG30xyoTMryk1Ac7081kuHQEk/l4VaDP3qVIkWQT9u/sPB5K +Gnk4blO7UZO3Orhy4kog3hMdAqhBmvmvssp346nEmFo6uZF/cqN+8y+OJ19Z5nzuVkX VqZmIA4sVLWEAefnJZAhgdhiKaEWLaJvRgArFyr9JUsC/GgYFVA4ZQkWLjA93J0rjpzu Z1q804MqutAKDkgNwtTWhb+NSsfChjJxYmr3nZXxZ/HLNoSjRB4YDqFYKKt+o0zRnLQn DiEYHGsmNz6SUaMdscQEGCslz8dSKYReGsoJ5j/dbjOwlenXflMB50vZGIMagBCC/beZ 8l4A== X-Gm-Message-State: ALQs6tBIbReUNr/WEcJhwmvuIZHq2Cr64jvJEJDHWNWC/AK/FI0YtE00 avg4q50zw3j9sbG42Pd3BGU24Sriec/wsQD0t5Y= X-Google-Smtp-Source: AIpwx49l57M4KoCJ/3/qQ6HBwkfAQtuN9h/6FVh8XE3zTZ6xUpa5074PogpffQ6UlY4FLfk2tSJ7qkn5PmfyZWWibOg= X-Received: by 2002:aca:d786:: with SMTP id o128-v6mr8353115oig.10.1524331824611; Sat, 21 Apr 2018 10:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Sat, 21 Apr 2018 10:30:24 -0700 (PDT) In-Reply-To: References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Stefan Blachmann Date: Sat, 21 Apr 2018 19:30:24 +0200 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh Cc: Julian Elischer , gljennjohn@gmail.com, "freebsd-hackers@freebsd.org" , Colin Percival , Konstantin Belousov , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 17:30:25 -0000 On 4/21/18, Warner Losh wrote: > Except that I said "sure, I'll integrate it, but you need to do these > things" and Stefan said "oh, lemme get you the code" and I never heard back > anything except complaints that it hasn't been integrated yet. Not playing > well with others makes them less willing to help you. Well, I refactored the code to be up to style guidelines, and when it was ready on Mar 20th, I emailed you and the other guys involved with microcode stuff. Didn't get an answer from you, so I thought there would be no more interest. But, maybe it was just the mail slipping through, or get forgotten due to much work? From owner-freebsd-hackers@freebsd.org Sat Apr 21 18:35:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8E3CFB9089 for ; Sat, 21 Apr 2018 18:35:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (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 77CF473111 for ; Sat, 21 Apr 2018 18:35:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f169.google.com with SMTP id t23-v6so1082143ioc.10 for ; Sat, 21 Apr 2018 11:35:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=jl+Tlj47tp+MnyfZynkL0y7w6yJb3PgRKcWfSix8gzQ=; b=oMY3LK/CHKE1WQkpxCuZQFMQHBQgWHGe3FQWpUnphPzbNrwfIyE9gkUgYMPNmch8aI OEDD1MZIgjNlT6NH/BW65/cZshBR2gWOHTCk7kayvN9V5SelSrIMcHQ0dY4Ihbv5fhhl Zo1yAITfjUKIn8VAC6vU50WRkHUrlYS1+EirsJa7YDdn8A7usIEqtUsUMgikslkQ7v8i LCSKt+nDeHKOufkwsYH47es5ES2bh7hUyWY9unnrURoP7Kwh0uOst4P33rYyWqXKMxoL DbRvu0lgxtG/6+/tIZYk6xnm9xIKysdTII6id2NQURRFafrTrwMFs+HymNDs5aPlVy6K Zn4g== X-Gm-Message-State: ALQs6tCa9NQ89554oQN5OrJl6Yrpg/vnOUzUCi4dbXwG5jCEz+3pLAT6 Vje0/EFICp8PV+qjWW8Vqr0zZMzV X-Google-Smtp-Source: AIpwx49nHDl16XTB5iDR9xHnEj3UqSyhLHONmhbI1/09mEMzP0ThKsi7x6fPogZBJQj5gpt+y36Y3g== X-Received: by 2002:a6b:b7c6:: with SMTP id h189-v6mr14541865iof.94.1524333830503; Sat, 21 Apr 2018 11:03:50 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id x189-v6sm1164780ite.5.2018.04.21.11.03.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 11:03:50 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id f3-v6so13943874iob.13 for ; Sat, 21 Apr 2018 11:03:50 -0700 (PDT) X-Received: by 2002:a6b:da04:: with SMTP id x4-v6mr6427996iob.19.1524333829913; Sat, 21 Apr 2018 11:03:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:224d:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 11:03:49 -0700 (PDT) In-Reply-To: References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> From: Conrad Meyer Date: Sat, 21 Apr 2018 11:03:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh Cc: Colin Percival , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 18:35:09 -0000 On Sat, Apr 21, 2018 at 10:02 AM, Warner Losh wrote: > On Fri, Apr 20, 2018 at 6:11 PM, Colin Percival > wrote: >> Would it be sufficient for debugging purposes if I change the !bootverbose >> case from printing many lines of >> >> SMP: AP CPU #N Launched! >> >> to instead have a single >> >> SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 >> 36 >> 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 >> 67 >> 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 >> 22 >> 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 >> 16 >> 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 >> 108 >> 106 122 117 114 26 110 59 76 124 119 >> >> ? (With each AP printing its number as it reaches the appropriate point?) >> >> This yields almost the same gain as silencing the launch messages >> completely, >> while still allowing you to see each CPU announcing itself. > > > The trouble is that you've got N CPUs that are doing output at the same > time. You'll need to synchronize somehow. And how do you know that the last > one is done? Especailly if one of the CPUs doesn't start.. > > It looks great in theory, but I'm not sure how you'd make it work in > practice. Yeah. You could pare down the number of characters per-AP substantially. Something like: SMP: Launching APs: 2 3 4 ... It sounds like EC2 is redrawing on every character emitted, scrolling or not. So the additional line breaks shouldn't hurt. Best, Conrad From owner-freebsd-hackers@freebsd.org Sat Apr 21 19:28:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB163F8BD90 for ; Sat, 21 Apr 2018 19:28:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BDEA8086C for ; Sat, 21 Apr 2018 19:28:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id e78-v6so1529366iod.0 for ; Sat, 21 Apr 2018 12:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c/BhbioWIPxigOg1UmgknbY4OdyKZnieZCiQFmXi6bQ=; b=nWCStLatgqS/Yn1jCJgAX9EcJ1rc/F1IWm9SHzS/5EKXLnIfEu5LNOs9pqtgx0zdWK fUBxTScfCya1iQ4BW/n3fVIUhhGNZA/3Y8TGQkadSGDktupMalVo6oCqXmW2oKSrX3/K JD3Xnn87p3mlQyB9GXEcU/8g+uNrY4SJvU/tjL8N8QZcuS72uSFF2odd0//JJBnNRdZK T1CzyVpC+LD5fkf2a1VcA5pwK4+jjE02szCjG0ohGjRpVtpysXEzpAB0FnAJ1MvmqKWJ WovzQHA6f4ml/YAsUkaoshxbG7/FxiP0I4xTBJo1fbKpW8Bc24ha98CJ2Ge99T7Wdk3e o6QQ== 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=c/BhbioWIPxigOg1UmgknbY4OdyKZnieZCiQFmXi6bQ=; b=mWQSiFeQVDDbynhW0t0xOA6wP7y5dKmMqPN1i+OlfKjr4npX45HtozoRE3nEe0s/6V ghddoJYWYOJb48uYPlDs8ec88eWjao/87WK2mWe832LY8S2yNjw9bQFypTCBe5eRr5mA uobKxoli9/fSfeCIYZ57hd5heCVpWM4iPGegWCprk1HfNJVZgPuBcAdeOWQ8wMz6Ukoa 4jsyejPuetXLijBfi0kHnAHj3HsXNo8IIpBX+b73cXVDrys9CaBzUy4Vzq/ocBipKVd2 KrUOICqTYGO2RyFq/q0LZoeD/eIpsIMXMi995tXi4b5GqOtnShd3j67zWfS9ClNAfSRb EA9A== X-Gm-Message-State: ALQs6tAIbXOHOMdj3AptiU0dljhOouCdYue/NqUJJ3q4TI+bG83YJgdb D7vUNi0ScdxkRZit8Rn7V9qXDQt5FaX0JLZhZ2V6VQ== X-Google-Smtp-Source: AB8JxZo4gh2dq3Yjug1gQPV6OBew2Jf89vwzqOMtvlL7ZfFTzYgw5cAyoXzqK2a/uI336HVdEnKDj4/WYXosYmTu00c= X-Received: by 2002:a6b:a292:: with SMTP id l140-v6mr15176316ioe.39.1524338924834; Sat, 21 Apr 2018 12:28:44 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 12:28:44 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <4be440e4-e70f-3652-e755-ed2d924ff3d2@freebsd.org> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <4be440e4-e70f-3652-e755-ed2d924ff3d2@freebsd.org> From: Warner Losh Date: Sat, 21 Apr 2018 13:28:44 -0600 X-Google-Sender-Auth: xvEbVQku_hVv78uSOclThznbU9c Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Julian Elischer 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.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 19:28:46 -0000 On Fri, Apr 20, 2018 at 12:11 AM, Julian Elischer wrote: > On 20/4/18 4:48 am, Steven Hartland wrote: > >> Sounds good to me, I think we could actually benefit from even quieter >> modes if I=E2=80=99m honest. >> >> On Thu, 19 Apr 2018 at 21:09, Colin Percival >> wrote: >> >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs= ) >>> the boot time console output contains a large number of lines of the >>> forms >>> >>> SMP: AP CPU #N Launched! >>> cpuN: on acpi0 >>> estN: on cpuN >>> >>> Having 128 almost-identical lines of output doesn't seem very useful, a= nd >>> it actually has a nontrivial impact on the time spent booting. >>> >>> Does anyone mind if I hide these by default, having them only show up i= f >>> boot verbosity is requested? >>> >> https://reviews.freebsd.org/D15153 implements that for everything except the CPU launched. Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 19:52:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07D09F92BE6 for ; Sat, 21 Apr 2018 19:52:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 85C4C84876 for ; Sat, 21 Apr 2018 19:52:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id 19-v6so6230493itw.3 for ; Sat, 21 Apr 2018 12:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FexdtQcWWIPZFwZJMOTvo3xA63cOYz6NtTHTEYezejg=; b=CC81YIBYN+v45mdslUL/W5xr8JTPuFA9FyAj2fohJuo9m5p5x/MKYFhcdLVsCbro7T k/GdQ/FEcHH9iKh+681vklRpX/MBKuRRpUlISKJhKY1rcxloeLG50icu53ZlGZ+WXdFr giAfk4ZtSR4OxIDp46omeZpeCuKnBENZPm5fZkYVBWFusx8L2w1YpRtDHpMRLn1dBjtN bbFeblSeXm+6sayIKHz15qSWHrat2whDByMqMbTJKANawNNNgqqk4iMYaUySC5R+hbI7 zU11sOcLkXPfo96CcNTb7oGQhF3w3MTm5emzF0k235sOyvYd6leQfk9W024XI8ApkaOn i6xg== 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=FexdtQcWWIPZFwZJMOTvo3xA63cOYz6NtTHTEYezejg=; b=YzLM9hRRFMgXGYs1siNEJzqBrT2LFKPU7uqY4FgbWoQvPGbdac4biZLUHMjsbhdv9H YGDsDM6buGT+HbACD1Mk6bXuAaM1IqHpCq0YNbfSOJCGzFoRO/6t15LRv6U/DNs8V3xl uaaMi+BFMJ+oYhQSCCjjLoKpfAFQpHZPWzFHgyI20IAsk9sCtk8HEFuW1cYPZkIuMz0P ISroT2u4wbLx0NjF7Y0egjL3ZIo1eH54m+Nh7/1yZ5FEkMt+CWf17VXX8+m6rghywzvC IYdJ0EPbb28xrFJW7Rg7WyUCfSmT056naOt08Dp36SAss16/EFNR5JqYJs9e+pe1w+fq xLRQ== X-Gm-Message-State: ALQs6tAy+1dstKR2jyGGAkTrQ0nr38AdUGUtrCpmMo3/0mVzszAmbI8J FI36X1O+3pNmMhuJ0zPtp10V5HXL7sZy8eIDdY9tSw== X-Google-Smtp-Source: AB8JxZqy6+nxBigOhVWGRjOEexH29dQNTuZ8CrOZclKckr8YGeH4z5Y8F8JttuJOeruJ84WKoLu9oUREY7s41ucJ2Rc= X-Received: by 2002:a24:ad64:: with SMTP id a36-v6mr7743845itj.1.1524340367554; Sat, 21 Apr 2018 12:52:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 12:52:46 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180421123544.56d7e690@ernst.home> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Warner Losh Date: Sat, 21 Apr 2018 13:52:46 -0600 X-Google-Sender-Auth: RuBu3rV8Qou6L2hcrgLMYeupyU0 Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: gljennjohn@gmail.com Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Colin Percival , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 19:52:49 -0000 On Sat, Apr 21, 2018 at 4:35 AM, Gary Jennejohn wrote: > On Sat, 21 Apr 2018 12:20:49 +0300 > Konstantin Belousov wrote: > > > On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > > > On 04/19/18 14:45, Konstantin Belousov wrote: > > > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > > > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > > > >>> The 'CPU XX Launched' messages are very useful for initial > diagnostic > > > >>> of the SMP startup failures. You need to enable bootverbose to see > the > > > >>> hang details, but for initial hint they are required. > Unfortunately, AP > > > >>> startup hangs occur too often to pretend that this can be > delegated to > > > >>> very specific circumstances. > > > >> > > > >> Really? I don't know that I've ever seen an AP startup hang. How > > > >> often do they occur? > > > > > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > > > supplier and its interaction with the x2APIC enablement, see > madt.c:170 > > > > and below. > > > > > > > > There were several recent reports of the issue with Broadwell Xeon > > > > machines, no additional data or resolution. > > > > > > > > There are sporadic reports of the problem, where I do not see > > > > a clear commonality. > > > > > > Would it be sufficient for debugging purposes if I change the > !bootverbose > > > case from printing many lines of > > > > > > SMP: AP CPU #N Launched! > > > > > > to instead have a single > > > > > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 > 113 36 > > > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 > 63 18 67 > > > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 > 37 22 > > > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 > 115 16 > > > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 > 25 108 > > > 106 122 117 114 26 110 59 76 124 119 > > > > > > ? (With each AP printing its number as it reaches the appropriate > point?) > > > > > > This yields almost the same gain as silencing the launch messages > completely, > > > while still allowing you to see each CPU announcing itself. > > I am fine with the behaviour, but I am not sure how would you implement > > this. printf(9) buffers the output, you need to flush it somehow. > > > > And printf(9) calls vprintf(9) which in turn calls _vprintf which > will allocate a buffer on the stack (bad idea) if the option > PRINTF_BUFR_SIZE is set in the kernel config file. So it seems > that output may even be double buffered. > I don't think either of these is true (the double buffered part,. nor the buffered part). Well, they are both kinda true, but they don't matter. It's all to make dmesg and friends work. There's other issues, but at this stage of the boot we're single threaded and the CPUs that are launching take out a spin lock. We always call putchar for each character that kvprintf(). So any buffering that's done is in addition to putchar going to the console. diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c index 3fcf7aa25152..06973b1ea6d5 100644 --- a/sys/x86/x86/mp_x86.c +++ b/sys/x86/x86/mp_x86.c @@ -1020,7 +1020,7 @@ init_secondary_tail(void) smp_cpus++; CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); - printf("SMP: AP CPU #%d Launched!\n", cpuid); + printf("%d%s", cpuid, smp_cpus == mp_ncpus ? "\n" : " "); /* Determine if we are a logical CPU. */ if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) is enough to give them all to me on a single line. We'd need another printf that says 'Starting APs: ' since otherwise we see: andom: unblocking device. ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard 1 8 10 20 2 19 11 12 22 4 14 23 16 13 3 18 5 17 21 9 15 6 7 Timecounter "TSC-low" frequency 1350029824 Hz quality 1000 which doesn't make a lot of sense. Comments? Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:19:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8630F96D2B for ; Sat, 21 Apr 2018 20:19:46 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B8CF68949; Sat, 21 Apr 2018 20:19:46 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3LKJTQL068050 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Apr 2018 23:19:32 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3LKJTQL068050 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3LKJTYW068049; Sat, 21 Apr 2018 23:19:29 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sat, 21 Apr 2018 23:19:29 +0300 From: Konstantin Belousov To: Warner Losh Cc: gljennjohn@gmail.com, "freebsd-hackers@freebsd.org" , Colin Percival , Conrad Meyer Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose Message-ID: <20180421201929.GP6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:19:47 -0000 On Sat, Apr 21, 2018 at 01:52:46PM -0600, Warner Losh wrote: > On Sat, Apr 21, 2018 at 4:35 AM, Gary Jennejohn > wrote: > > > On Sat, 21 Apr 2018 12:20:49 +0300 > > Konstantin Belousov wrote: > > > > > On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > > > > On 04/19/18 14:45, Konstantin Belousov wrote: > > > > > On Thu, Apr 19, 2018 at 02:37:56PM -0700, Conrad Meyer wrote: > > > > >> On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > > > > >>> The 'CPU XX Launched' messages are very useful for initial > > diagnostic > > > > >>> of the SMP startup failures. You need to enable bootverbose to see > > the > > > > >>> hang details, but for initial hint they are required. > > Unfortunately, AP > > > > >>> startup hangs occur too often to pretend that this can be > > delegated to > > > > >>> very specific circumstances. > > > > >> > > > > >> Really? I don't know that I've ever seen an AP startup hang. How > > > > >> often do they occur? > > > > > > > > > > It was epidemic with Sandy Bridge, mostly correlated to specific BIOS > > > > > supplier and its interaction with the x2APIC enablement, see > > madt.c:170 > > > > > and below. > > > > > > > > > > There were several recent reports of the issue with Broadwell Xeon > > > > > machines, no additional data or resolution. > > > > > > > > > > There are sporadic reports of the problem, where I do not see > > > > > a clear commonality. > > > > > > > > Would it be sufficient for debugging purposes if I change the > > !bootverbose > > > > case from printing many lines of > > > > > > > > SMP: AP CPU #N Launched! > > > > > > > > to instead have a single > > > > > > > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 > > 113 36 > > > > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 > > 63 18 67 > > > > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 > > 37 22 > > > > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 > > 115 16 > > > > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 > > 25 108 > > > > 106 122 117 114 26 110 59 76 124 119 > > > > > > > > ? (With each AP printing its number as it reaches the appropriate > > point?) > > > > > > > > This yields almost the same gain as silencing the launch messages > > completely, > > > > while still allowing you to see each CPU announcing itself. > > > I am fine with the behaviour, but I am not sure how would you implement > > > this. printf(9) buffers the output, you need to flush it somehow. > > > > > > > And printf(9) calls vprintf(9) which in turn calls _vprintf which > > will allocate a buffer on the stack (bad idea) if the option > > PRINTF_BUFR_SIZE is set in the kernel config file. So it seems > > that output may even be double buffered. > > > > I don't think either of these is true (the double buffered part,. nor the > buffered part). Well, they are both kinda true, but they don't matter. It's > all to make dmesg and friends work. There's other issues, but at this stage > of the boot we're single threaded and the CPUs that are launching take out > a spin lock. > > We always call putchar for each character that kvprintf(). So any buffering > that's done is in addition to putchar going to the console. > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 3fcf7aa25152..06973b1ea6d5 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > @@ -1020,7 +1020,7 @@ init_secondary_tail(void) > smp_cpus++; > > CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); > - printf("SMP: AP CPU #%d Launched!\n", cpuid); > + printf("%d%s", cpuid, smp_cpus == mp_ncpus ? "\n" : " "); With this, my concern is to have the cpu ids printed immediately, instead of being buffered until \n is printed as well. Please ensure that this is the case. > > /* Determine if we are a logical CPU. */ > if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) > > is enough to give them all to me on a single line. We'd need another printf > that says 'Starting APs: ' since otherwise we see: > > andom: unblocking device. > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > 1 8 10 20 2 19 11 12 22 4 14 23 16 13 3 18 5 17 21 9 15 6 7 > Timecounter "TSC-low" frequency 1350029824 Hz quality 1000 > > which doesn't make a lot of sense. > > Comments? > > Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:25:32 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E829EFA0621 for ; Sat, 21 Apr 2018 20:25:31 +0000 (UTC) (envelope-from 01000162e9e21428-4144fd41-2e1e-4af8-a1b0-ffc0d18fc432-000000@amazonses.com) Received: from a8-52.smtp-out.amazonses.com (a8-52.smtp-out.amazonses.com [54.240.8.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B2EB6B507 for ; Sat, 21 Apr 2018 20:25:31 +0000 (UTC) (envelope-from 01000162e9e21428-4144fd41-2e1e-4af8-a1b0-ffc0d18fc432-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524342330; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=rydp+oFUCAph7CpxEug6z1uVhTQ7E9KLL159dfnrGOQ=; b=RP5H1FMUYnBYTquL6QZ7NVrREw1CZRLnDOJxtSG76Zm/UV7uQF0+22+L5CBml2Am to8hotZk/LtIFR8g2T1eqKqAZbYEDhGV4iGr+9Gh1bD6IDrziKKM6b8gkFq9KpkW7+j vukfqYeiyeGpEfSNfkSTfIbfYin+ADzr3DCvQy0c= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524342330; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=rydp+oFUCAph7CpxEug6z1uVhTQ7E9KLL159dfnrGOQ=; b=iQONBTjzghocTji1JWTedh5ErVOFmjcIWGH547hSffDYO4MrcSqfHASONHQpt+Sj rvgksypJsUb4uafypdsV0bSrmQRGyVP5oU7M/bbcHulK8sny/VirgXMDV0GZ344j2FQ vflPaTdPffVvrMvrikj/ZsdKWz7lvyqGDz2owoh0= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: cem@freebsd.org, Warner Losh Cc: "freebsd-hackers@freebsd.org" References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162e9e21428-4144fd41-2e1e-4af8-a1b0-ffc0d18fc432-000000@email.amazonses.com> Date: Sat, 21 Apr 2018 20:25:30 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2018.04.21-54.240.8.52 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:25:32 -0000 On 04/21/18 11:03, Conrad Meyer wrote: > It sounds like EC2 is redrawing on every character emitted, scrolling > or not. So the additional line breaks shouldn't hurt. EC2 redraws characters when they're written to the VGA text mode buffer. Line breaks absolutely matter -- when we have a line break we rewrite the entire screen. Writing characters without scrolling is much faster. (FWIW, this applies to vt_fb as well; it's just that EC2 is the most extreme case since it combines a large number of CPUs with a slow emulated VGA. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:30:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BB93FA0C06 for ; Sat, 21 Apr 2018 20:30:12 +0000 (UTC) (envelope-from 01000162e9e65aa9-50a58dbb-eaae-45fb-b6bb-20212b25d016-000000@amazonses.com) Received: from a8-60.smtp-out.amazonses.com (a8-60.smtp-out.amazonses.com [54.240.8.60]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C09176B7EE for ; Sat, 21 Apr 2018 20:30:11 +0000 (UTC) (envelope-from 01000162e9e65aa9-50a58dbb-eaae-45fb-b6bb-20212b25d016-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524342610; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=2L1qpCeO8+b6nM6X6LLObMUf/3ZLMOzqgBbVXfs+/Ts=; b=HBbZG9jZht38roP8WwDd2mXZzN7i9tGHVJSIzT12WyoqKatLzWlbjMuDDyLvPDUp yw6Vu+VGCcVaTMC74YwR+Uj5NoJf74tKrqk2vEsrlGkvzKumUPIsVzzoZorNcR1GWdq 8CTWNcZBSQLiN9GHQX2j0YTlV+RZOY5a4A4UCND8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524342610; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=2L1qpCeO8+b6nM6X6LLObMUf/3ZLMOzqgBbVXfs+/Ts=; b=H6mnLG5VMOzQBgzi5crCreIMeRcCotjvDCcWraZ9bzJpBpEPtVk/DYBb6EoJoM81 8SD/PVOAeav0AjpD65QNaA0pucCgiG42YMKImvbdVkeZzNkwgirKp5xt/hUTiqVaIMA hMijung9UJNkZ0FjrWoKlJwhPWbXFZ51E2brui2g= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh Cc: Konstantin Belousov , Conrad Meyer , "freebsd-hackers@freebsd.org" References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162e9e65aa9-50a58dbb-eaae-45fb-b6bb-20212b25d016-000000@email.amazonses.com> Date: Sat, 21 Apr 2018 20:30:10 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2018.04.21-54.240.8.60 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:30:12 -0000 On 04/21/18 10:02, Warner Losh wrote: > On Fri, Apr 20, 2018 at 6:11 PM, Colin Percival > wrote: > Would it be sufficient for debugging purposes if I change the !bootverbose > case from printing many lines of > > SMP: AP CPU #N Launched! > > to instead have a single > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 36 > 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 67 > 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 22 > 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 16 > 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 108 > 106 122 117 114 26 110 59 76 124 119 > > ?  (With each AP printing its number as it reaches the appropriate point?) > > This yields almost the same gain as silencing the launch messages completely, > while still allowing you to see each CPU announcing itself. > > The trouble is that you've got N CPUs that are doing output at the same time. > You'll need to synchronize somehow. And how do you know that the last one is > done? Especailly if one of the CPUs doesn't start.. Fortunately, this output is all generated with the ap_boot_mtx lock held. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:30:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70CD7FA0C11 for ; Sat, 21 Apr 2018 20:30:13 +0000 (UTC) (envelope-from 01000162e9e66234-e005d59e-2896-436a-aab1-a3d7b3a74610-000000@amazonses.com) Received: from a8-237.smtp-out.amazonses.com (a8-237.smtp-out.amazonses.com [54.240.8.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BB286B7F2 for ; Sat, 21 Apr 2018 20:30:13 +0000 (UTC) (envelope-from 01000162e9e66234-e005d59e-2896-436a-aab1-a3d7b3a74610-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524342612; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=Z68i2lxBzOF1Xj/M08L69CzPkMgbj9mV/oJP7LdYCOQ=; b=U7C46HD3zx2pbRqv8l8a2YBkwr6FcM5kXBNxkD1+I/xPJwu39i3fJImkqz23MJgz iLhR8mpG0Mdk1PM/6fA0HiXplPZloCvxoK+th0tnkp05jRH1VjMjTXl6aWQqWkQcpAs 0bvhKIilNfjVNVoQ3os15M2ZKJMHlsvsy5G6jOBg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524342612; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=Z68i2lxBzOF1Xj/M08L69CzPkMgbj9mV/oJP7LdYCOQ=; b=Bji2RNTklJQ2/MJkwqpUtTCedIeZ7xntqGz7BJyIylC8JLlnk09RWD/mL2+MopGO PF7/GnNSxuXueK5VBksvyuaC2FzGguCnTYjU+zkj9+AfXDwJBikAfj8LAxZUveXgFYC NJoHSFmHhRSxOh52ZyGXFqSpKwLMxyK/8Ij3YcSI= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh , gljennjohn@gmail.com Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Conrad Meyer References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162e9e66234-e005d59e-2896-436a-aab1-a3d7b3a74610-000000@email.amazonses.com> Date: Sat, 21 Apr 2018 20:30:12 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2018.04.21-54.240.8.237 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:30:13 -0000 On 04/21/18 12:52, Warner Losh wrote: > On Sat, 21 Apr 2018 12:20:49 +0300 > Konstantin Belousov > wrote: > > On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > > > Would it be sufficient for debugging purposes if I change the !bootverbose > > > case from printing many lines of > > > > > > SMP: AP CPU #N Launched! > > > > > > to instead have a single > > > > > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 [...] > > > > > > ?  (With each AP printing its number as it reaches the appropriate point?) > > I am fine with the behaviour, but I am not sure how would you implement > > this.  printf(9) buffers the output, you need to flush it somehow. > > I don't think either of these is true (the double buffered part,. nor the > buffered part). Well, they are both kinda true, but they don't matter. It's > all to make dmesg and friends work. There's other issues, but at this stage of > the boot we're single threaded and the CPUs that are launching take out a spin > lock. I just checked (by adding a 500 ms delay after each CPU prints its ID) and I can definitely see the individual numbers being printed on the console. > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 3fcf7aa25152..06973b1ea6d5 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > @@ -1020,7 +1020,7 @@ init_secondary_tail(void) >         smp_cpus++; > >         CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); > -       printf("SMP: AP CPU #%d Launched!\n", cpuid); > +       printf("%d%s", cpuid, smp_cpus == mp_ncpus ? "\n" : " "); > >         /* Determine if we are a logical CPU. */ >         if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) > > is enough to give them all to me on a single line. We'd need another printf > that says 'Starting APs: ' since otherwise we see: > > andom: unblocking device. > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > 1 8 10 20 2 19 11 12 22 4 14 23 16 13 3 18 5 17 21 9 15 6 7 > Timecounter "TSC-low" frequency 1350029824 Hz quality 1000 > > which doesn't make a lot of sense. > > Comments? Here's the patch I have, which prints a header before the CPU IDs: Index: sys/x86/x86/mp_x86.c =================================================================== --- sys/x86/x86/mp_x86.c (revision 332638) +++ sys/x86/x86/mp_x86.c (working copy) @@ -1020,7 +1020,9 @@ smp_cpus++; CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); - printf("SMP: AP CPU #%d Launched!\n", cpuid); + printf(" %d", cpuid); + if (smp_cpus == mp_ncpus) + printf("\n"); /* Determine if we are a logical CPU. */ if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) @@ -1508,6 +1510,7 @@ if (mp_ncpus == 1) return; + printf("SMP: Launching AP CPUs:"); atomic_store_rel_int(&aps_ready, 1); while (smp_started == 0) ia32_pause(); -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:35:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42D50FA1848 for ; Sat, 21 Apr 2018 20:35:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B0636D707 for ; Sat, 21 Apr 2018 20:35:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id u62-v6so6274039ita.5 for ; Sat, 21 Apr 2018 13:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WzgX1/zyKtI7/BYecSEe1U/mZhftQR5XsP4geDN9jbY=; b=NSvSYtxLbeBAI3IThWRLt+8w8L9aaswkNHuDyMYWvUNyFL+WwMSxjOVD3ut9L7mim5 UUQseS8AigvKkuWOaE5zI1nyG8r3qdxDHglBQ7+MiN7TtWQfLLSDbk43OMeU9m5WSFGI dEhKJWzev+3iARnVbF/I34SGEh3Ma3XjhbXNJlcFohRwIpp6JTYsJ/k0tf704QKTusCa 84JqTTY8q36lC9mD60Z8zFp8pjFOI88jZ5lnekU5wmveeVszU1aAJNm7UQqqdaHO5lgF Y6in1LzPd9FqFz/v6jJV7/KLLr5U6gf8B5I7prVFY+b3x3kLjZiG8m5X9EYtgKFQRhZN /Tkw== 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=WzgX1/zyKtI7/BYecSEe1U/mZhftQR5XsP4geDN9jbY=; b=LQmWH31FNuIGS/ElxwJHrScGHAzcTQH+J/bzKosxpJ/3LJbxwuO4tr3RRoHm7h+uGo kazEa/zcmqzVSi7bhR/CGXMoIIoH5C9d7m+uiTfESwVJvroq64oTqjA6arpIJlm0TIO5 WYtSHgs8BiMlOMpNEgCXxOeByHuGsQwSFbss3vIoL7805akgekTDN2HYeTtv79LPMkYU sIWebEMOQ2FPjzEyCW8lQzKyeD0xoYjkQvD5q9P37b3qn31hMtFMuOkDl5m98ZEU6siU 79E4P3F7lEO1g3d4dY99PuQTer5Uv2xq/jHlbM8u6Iea8d1+R+uMYTPetvXvjnt+KCX3 bjJA== X-Gm-Message-State: ALQs6tD4JRVuJbWIWAvg6A8BJWSk23kRIHa6FDfmhhauUS1V2urzfHdx X8G9HUpXwxeOo9AfFxpW+VpV1Of5lXntGAlGwdYT9iDn X-Google-Smtp-Source: AIpwx48e4gntTbyQO/84Hg6YbGiHwEJnouvK4zzR3Gt0FICCrzf5KHmL3Um4pjjVVkfQc7rB33csrVeSFRmNwUKWQDQ= X-Received: by 2002:a24:42c6:: with SMTP id i189-v6mr7952849itb.73.1524342942588; Sat, 21 Apr 2018 13:35:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 13:35:42 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <01000162e9e66255-b8ae47df-b48c-4512-a042-48df5604914b-000000@email.amazonses.com> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> <01000162e9e66255-b8ae47df-b48c-4512-a042-48df5604914b-000000@email.amazonses.com> From: Warner Losh Date: Sat, 21 Apr 2018 14:35:42 -0600 X-Google-Sender-Auth: Jxef69qiqL8lBeCvWaAqdSTUmMA Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Colin Percival Cc: gljennjohn@gmail.com, Konstantin Belousov , "freebsd-hackers@freebsd.org" , Conrad Meyer Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:35:45 -0000 On Sat, Apr 21, 2018 at 2:30 PM, Colin Percival wrote: > On 04/21/18 12:52, Warner Losh wrote: > > On Sat, 21 Apr 2018 12:20:49 +0300 > > Konstantin Belousov > > wrote: > > > On Sat, Apr 21, 2018 at 12:11:07AM +0000, Colin Percival wrote: > > > > Would it be sufficient for debugging purposes if I change the > !bootverbose > > > > case from printing many lines of > > > > > > > > SMP: AP CPU #N Launched! > > > > > > > > to instead have a single > > > > > > > > SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 > [...] > > > > > > > > ? (With each AP printing its number as it reaches the > appropriate point?) > > > I am fine with the behaviour, but I am not sure how would you > implement > > > this. printf(9) buffers the output, you need to flush it somehow. > > > > I don't think either of these is true (the double buffered part,. nor the > > buffered part). Well, they are both kinda true, but they don't matter. > It's > > all to make dmesg and friends work. There's other issues, but at this > stage of > > the boot we're single threaded and the CPUs that are launching take out > a spin > > lock. > > I just checked (by adding a 500 ms delay after each CPU prints its ID) and > I > can definitely see the individual numbers being printed on the console. > > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > > index 3fcf7aa25152..06973b1ea6d5 100644 > > --- a/sys/x86/x86/mp_x86.c > > +++ b/sys/x86/x86/mp_x86.c > > @@ -1020,7 +1020,7 @@ init_secondary_tail(void) > > smp_cpus++; > > > > CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); > > - printf("SMP: AP CPU #%d Launched!\n", cpuid); > > + printf("%d%s", cpuid, smp_cpus == mp_ncpus ? "\n" : " "); > > > > /* Determine if we are a logical CPU. */ > > if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) > > > > is enough to give them all to me on a single line. We'd need another > printf > > that says 'Starting APs: ' since otherwise we see: > > > > andom: unblocking device. > > ioapic0 irqs 0-23 on motherboard > > ioapic1 irqs 24-47 on motherboard > > 1 8 10 20 2 19 11 12 22 4 14 23 16 13 3 18 5 17 21 9 15 6 7 > > Timecounter "TSC-low" frequency 1350029824 Hz quality 1000 > > > > which doesn't make a lot of sense. > > > > Comments? > > Here's the patch I have, which prints a header before the CPU IDs: > > Index: sys/x86/x86/mp_x86.c > =================================================================== > --- sys/x86/x86/mp_x86.c (revision 332638) > +++ sys/x86/x86/mp_x86.c (working copy) > @@ -1020,7 +1020,9 @@ > smp_cpus++; > > CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); > - printf("SMP: AP CPU #%d Launched!\n", cpuid); > + printf(" %d", cpuid); > + if (smp_cpus == mp_ncpus) > + printf("\n"); > > /* Determine if we are a logical CPU. */ > if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) > @@ -1508,6 +1510,7 @@ > > if (mp_ncpus == 1) > return; > + printf("SMP: Launching AP CPUs:"); > atomic_store_rel_int(&aps_ready, 1); > while (smp_started == 0) > ia32_pause(); > > Here's the one that I have: diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c index 3fcf7aa25152..4637243c4274 100644 --- a/sys/x86/x86/mp_x86.c +++ b/sys/x86/x86/mp_x86.c @@ -1020,7 +1020,8 @@ init_secondary_tail(void) smp_cpus++; CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); - printf("SMP: AP CPU #%d Launched!\n", cpuid); + printf("%s%d%s", smp_cpus == 1 ? "Launching APs: " : "", + cpuid, smp_cpus == mp_ncpus ? "\n" : " "); /* Determine if we are a logical CPU. */ if (cpu_info[PCPU_GET(apic_id)].cpu_hyperthread) which will print the results one at a time. Except when PRINTF_BUFR_SIZE is defined (which is in the GENERIC config). Do you have it in the kernel you're booting in the cloud? Warner From owner-freebsd-hackers@freebsd.org Sat Apr 21 20:50:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDE2FFA2BCC for ; Sat, 21 Apr 2018 20:50:25 +0000 (UTC) (envelope-from 01000162e9f8cc9a-4ffd1c10-d640-47b0-bfae-6769dff4f78b-000000@amazonses.com) Received: from a8-13.smtp-out.amazonses.com (a8-13.smtp-out.amazonses.com [54.240.8.13]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E5337198E for ; Sat, 21 Apr 2018 20:50:25 +0000 (UTC) (envelope-from 01000162e9f8cc9a-4ffd1c10-d640-47b0-bfae-6769dff4f78b-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1524343819; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=/RAWw1NA4v0ocZPOOpP50kh4MMUsy6lLwHjoYJOgL7w=; b=AnMZVT/xsVCd64foEQpuznINsjSn5GyRahHUsV97j62derecig18qqqIIwupN7Pk nF2hR0xjipBdqUO/d9a49Ja/1YUwmBgp9pnZ2/POmY0r5WtfYbR/lmCW2x60kGoqDpE m7NZaQ1lOLcA1xv8uBDKfovQd+GVY7fs/fBBYNuA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1524343819; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=/RAWw1NA4v0ocZPOOpP50kh4MMUsy6lLwHjoYJOgL7w=; b=JBwEUz/IpWkVl0qvMIFM49SXedZ5+p8TmF4PNTN++0bJAI1xKv45gAUAsgTyrZDM kwnOCTn6o5mtBP2llIr7PH7mlRGf32AWtmYLIT3nJbFDGQUwgNScJb1O2fiFvXHJenG /k6ME5PRHTqKnRVPxDD2mUBaKvJOxE+WBX5YwMzw= Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh Cc: gljennjohn@gmail.com, Konstantin Belousov , "freebsd-hackers@freebsd.org" , Conrad Meyer References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a466e-98f0305b-1723-467a-bc49-342c3fa9fc5b-000000@email.amazonses.com> <20180421092049.GM6887@kib.kiev.ua> <20180421123544.56d7e690@ernst.home> <01000162e9e66255-b8ae47df-b48c-4512-a042-48df5604914b-000000@email.amazonses.com> From: Colin Percival Openpgp: preference=signencrypt Autocrypt: addr=cperciva@tarsnap.com; prefer-encrypt=mutual; keydata= xsDhBElrAAcRBACDfDys4ZtK+ErCJ1HAzYeteKpm3OEsvT/49AjUTLihkF79HhIKrCQU+1KC zv7BwHCMLb6hq30As9L7iFKG7n5QFLFC4Te/VcITUnWHMG/c3ViLOfJGvi+9/nOEHaM1dVJY D6tEp5yM1nHmVQpo9932j4KGuGFR0LhOK5IHXOSfGwCgxSFDPdgxe2OEjWxjGgY+oV3EafcD +JROXCTjlcQiG/OguQH4Vks3mhHfFnEppLxTkDuYgHZQiUtpcT9ssH5khgqoTyMar05OUdAj ZIhNbWDh4LgTj+7ZmvLhXT5Zxw8LX9d7T36aTB8XDQSenDqEtinMWOb0TCBBLbsB8EFG1WTT ESbZci9jJS5yhtktuZoY/eM8uXMD/3k4FWFO80VRRkELSp+XSy/VlSQjyi/rhl2nQq/oOA9F oJbDaB0yq9VNhxP+uFBzBWSqeIX0t1ZWLtNfVFr4TRP5hihI5ICrg/0OpqgisKsU2NFe9xyO hyJLYmfD8ebpDJ/9k30C7Iju9pVrwLm1QgS4S2fqJRcR+U4WbjvP7CgSzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wmEEExECACEFAklrALYCGwMHCwkIBwMCAQQV AggDBBYCAwECHgECF4AACgkQOM7KaQxqam6/igCgn+z2k3V5ggNppmWrZstt1U2lugsAoL7L wS9V9yLtil3oWmHtwpUqYruEzsFNBElrAAcQCAD3ZLMIsP4CIDoJORg+YY0lqLVBgcnF7pFb 4Uy2+KvdWofN+DKH61rZLjgXXkNE9M4EQC1B4lGttBP8IY2gs41y3AUogGdyFbidq99rCBz7 LTsgARHwFxZoaHmXyiZLEU1QZuMqwPZV1mCviRhN5E3rRqYNXVcrnXAAuhBpvNyj/ntHvcDN 2/m+ochiuBYueU4kX3lHya7sOj+mTsndcWmQ9soOUyr8O0r/BG088bMn4qqtUw4dl5/pglXk jbl7uOOPinKf0WVd2r6M0wLPJCD4NPHrCWRLLLAjwfjrtoSRvXxDbXhCdgGBa72+K8eYLzVs hgq7tJOoBWzjVK6XRxR7AAMGB/9Mo3iJ2DxqDecd02KCB5BsFDICbJGhPltU7FwrtbC7djSb XUrwsEVLHi4st4cbdGNCWCrp0BRezXZKohKnNAPFOTK++ZfgeKxrV2sJod+Q9RILF86tQ4XF 7A7Yme5hy92t/WgiU4vc/fWbgP8gV/19f8nunaT2E9NSa70mZFjZNu4iuwThoUUO5CV3Wo0Y UISsnRK8XD1+LR3A2qVyLiFRwh/miC1hgLFCTGCQ3GLxZeZzIpYSlGdQJ0L5lixW5ZQD9r1I 8i/8zhE6qRFAM0upUMI3Gt1Oq2w03DiXrZU0Fu/R8Rm8rlnkQKA+95mRTUq1xL5P5NZIi4gJ Z569OPMFwkkEGBECAAkFAklrAAcCGwwACgkQOM7KaQxqam41igCfbaldnFTu5uAdrnrghESv EI3CAo8AoLkNMks1pThl2BJNRm4CtTK9xZeH Message-ID: <01000162e9f8cc9a-4ffd1c10-d640-47b0-bfae-6769dff4f78b-000000@email.amazonses.com> Date: Sat, 21 Apr 2018 20:50:19 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2018.04.21-54.240.8.13 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:50:26 -0000 On 04/21/18 13:35, Warner Losh wrote: > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 3fcf7aa25152..4637243c4274 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > @@ -1020,7 +1020,8 @@ init_secondary_tail(void) >         smp_cpus++; > >         CTR1(KTR_SMP, "SMP: AP CPU #%d Launched", cpuid); > -       printf("SMP: AP CPU #%d Launched!\n", cpuid); > +       printf("%s%d%s", smp_cpus == 1 ? "Launching APs: " : "", > +           cpuid, smp_cpus == mp_ncpus ? "\n" : " "); Have you tested this? If you're going to print the header here, I think you need to check for smp_cpus == 2, since it starts at 1 and is already incremented once. (Because CPU #0 isn't an AP and thus doesn't hit this code path.) > which will print the results one at a time. Except when PRINTF_BUFR_SIZE is > defined (which is in the GENERIC config). Do you have it in the kernel you're > booting in the cloud? I'm running GENERIC + options TSLOG, and (with a 500 ms delay added) I could definitely see the individual numbers showing up one by one on the VGA output. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid