From owner-freebsd-current@freebsd.org Sun Feb 18 00:04:45 2018 Return-Path: Delivered-To: freebsd-current@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 E790EF1EB3A for ; Sun, 18 Feb 2018 00:04:44 +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 6D46F7497B for ; Sun, 18 Feb 2018 00:04:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2DB25F1EB35; Sun, 18 Feb 2018 00:04:44 +0000 (UTC) Delivered-To: current@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 1B93AF1EB34 for ; Sun, 18 Feb 2018 00:04:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) (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 AC17574978 for ; Sun, 18 Feb 2018 00:04:43 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f51.google.com with SMTP id w63so5637575ita.3 for ; Sat, 17 Feb 2018 16:04:43 -0800 (PST) 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=hlZxQI1uJHylIgri04QdlD5cUUrpAhKi3Ad5JqQ06rw=; b=X65gv2lSQty6i/Qgfjz4hwCiwxz8lo1z7avJjUgw3YgdVCai3KE53s7b1InRG09s1M PHziKQ1PbLS/EFkouuaFkdJfWcjsvhJ8IxLACPSV0SR05UtirH4q4lMuvEvKpT5B9HYc qyxOSJtLvHoTf/mgc1eBAr0AARWndLEiTOBUhEsSYlGAFgorQl+xiBmhzEFAATLvJ4i/ 8jplyspTpvgvi335rH8CgXqg8ZPuYyaqKRMIQIPV0Dfm+RKnHfR9ZnCA61VYjf5Oca0o DeJItKsfDbmnV7baCTJbXRjOICkqNhFdPdz5QtZXWVKum0oMgUfPda5ZpYuKcm3ArxhS dBPA== X-Gm-Message-State: APf1xPC0UKeAxWnHwUi9gGDG+UIIOgdOP4iLeMr3AJmwzafoHD/lHC9G mv7V7dhj069zJ9zpcuv8MHYiMF/q X-Google-Smtp-Source: AH8x226tjhH1vLM75FaK8Z/PfHHviu+4nnJnktfizMOhJKTGlRTdTOydf3x8AY4UFXYKgeEkjklteQ== X-Received: by 10.36.222.2 with SMTP id d2mr13716179itg.1.1518912276717; Sat, 17 Feb 2018 16:04:36 -0800 (PST) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id x186sm17781682itb.6.2018.02.17.16.04.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2018 16:04:36 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id n7so7870057iob.0 for ; Sat, 17 Feb 2018 16:04:36 -0800 (PST) X-Received: by 10.107.161.77 with SMTP id k74mr13800890ioe.220.1518912276434; Sat, 17 Feb 2018 16:04:36 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Sat, 17 Feb 2018 16:04:36 -0800 (PST) In-Reply-To: References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> From: Conrad Meyer Date: Sat, 17 Feb 2018 16:04:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Since last week (today) current on my Ryzen box is unstable To: Andrew Reilly Cc: current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 00:04:45 -0000 On Sat, Feb 17, 2018 at 12:52 PM, Andrew Reilly wrote: > I've applied the patch, and the boot process is quiet now, but it's still loading cc_vegas.ko, seemingly in response to seeing this device: (from pciconf -l -v) > > none4@pci0:17:0:2: class=0x108000 card=0x14561022 chip=0x14561022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices, Inc. [AMD]' > device = 'Family 17h (Models 00h-0fh) Platform Security Processor' > class = encrypt/decrypt > > (from devmatch -v) > Searching pci bus at slot=0 function=2 dbsf=pci0:17:0:2 handle=\_SB_.PCI0.GP17.APSP for pnpinfo vendor=0x1022 device=0x1456 subvendor=0x1022 subdevice=0x1456 class=0x108000 > cc_vegas.ko That's kind of interesting. That device should match ccp.ko, not cc_vegas.ko. As far as I can tell, cc_vegas has no PNP data at all. Maybe this is a bug in kldxref or devmatch. Best, Conrad From owner-freebsd-current@freebsd.org Sun Feb 18 01:39:49 2018 Return-Path: Delivered-To: freebsd-current@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 9517BF00D86 for ; Sun, 18 Feb 2018 01:39:49 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 A511D7A005 for ; Sun, 18 Feb 2018 01:39:47 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: wcX2PgoVM1kLW9iN8MZnPI37PJMwQNlrfsskkAOfvv_cn0QEPnfpppSXZBbnydI yG5yaAd7VqcGWRLKywJBYw5nWybjl8QeAt0pgXH133Cuy1CvsxhzXt6O0Z7cOMCTY_yt24bz0w3h lEd6y2Q4GJIgKWDDQ7E6g94zQYgvpFTu953Sd3CcPFrRzH1USyQC9g_22MzStCK1FMAe7NBr1w1b sLJbdeeVCkWFgOKWbhhdIbgmZ_7DVxcbTLQzm1trlXiV9uf.QYhFWhubbbZ0RXrikeCK4wSrk1Nf vb.kmwUvCT2CfXme_7VqENXnmTrOLQ3paQZ4gfT3UiH1w_UHY5F4pK_YF0ylCiwSTIF0BqKVkkLH nLrxYqFBXaCBkdfik4WaOLFWACPrYr80H4FHjAbp1vg6pfy3AuEENGCccXJi7TpCMdmxytvciujT eL_MtyZrOnWHZLdhGVtsG8qI4ALmznK15K7onNNh0D086xlZLSyaX2OeSNmNmaw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 01:39:41 +0000 Received: from smtp101.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([68.180.227.10]) by smtp410.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 059fc7489feb036f39796c716a262c7d; Sun, 18 Feb 2018 01:39:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Message-Id: Date: Sat, 17 Feb 2018 17:39:39 -0800 To: FreeBSD Current , FreeBSD Hackers X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 01:39:49 -0000 This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen Threadripper 1950X). No other Hyper-V use. This happened during: # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>> Checking for old files (Hand typed from a picture of a window's content at slighly different times, expect typos:) KDB: enter: panic [thread pid 42170 tid 100752 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db> call doadump Dumping 4825 out of 110559 MB: ... (omitted) ... Dump complete =3D 0 (The "pid 42170" identification as the process reporting the issue does not seem to appear in the core.txt.0 file.) # ls -lTdt /var/crash/* -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 = /var/crash/core.txt.0 lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 = /var/crash/vmcore.last -> vmcore.0 lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 = /var/crash/info.last -> info.0 -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 = /var/crash/vmcore.0 -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 = /var/crash/info.0 -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 = /var/crash/bounds -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 = /var/crash/minfree =46rom /var/crash/core.txt.0 : Unread portion of the kernel message buffer: spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long panic: spin lock held too long cpuid =3D 5 time =3D 1518911834 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f10094d0 vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 panic() at panic+0x43/frame 0xfffffe00f1009590 _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f10095a0 thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1009610 statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1009730 timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1009880 fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffcfc0 KDB: enter: panic __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D-2122191464) at = /usr/src/sys/kern/kern_shutdown.c:347 #2 0xffffffff8040b42c in db_fncall_generic (addr=3D,=20 rv=3D, nargs=3D, args=3D) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=3D, dummy2=3D,=20 dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff8040af79 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3D) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff8040acf4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff8040df9f in db_trap (type=3D, = code=3D) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80b370e3 in kdb_trap (type=3D3, code=3D-61456, = tf=3D) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff80fa2c5c in trap (frame=3D0xfffffe00f1009400) at /usr/src/sys/amd64/amd64/trap.c:547 #9 #10 kdb_enter (why=3D0xffffffff811f280b "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80aef17a in vpanic (fmt=3D, = ap=3D0xfffffe00f1009570) at /usr/src/sys/kern/kern_shutdown.c:801 #12 0xffffffff80aeefc3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:739 #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=3D,=20 ldap=3D) at /usr/src/sys/kern/kern_mutex.c:1224 #14 0xffffffff80acfb9b in thread_lock_flags_ (td=3D0xfffff818719d1000,=20= opts=3D, file=3D, line=3D) at /usr/src/sys/kern/kern_mutex.c:913 #15 0xffffffff80a89d6c in statclock_cnt (cnt=3D1, usermode=3D) at /usr/src/sys/kern/kern_clock.c:768 #16 0xffffffff810d0003 in handleevents (now=3D43230207690178, fake=3D0) at /usr/src/sys/kern/kern_clocksource.c:196 #17 0xffffffff810d0709 in timercb (et=3D0xffffffff81c528e8 ,=20= arg=3D) at /usr/src/sys/kern/kern_clocksource.c:353 #18 0xffffffff8110dad7 in lapic_handle_timer (frame=3D0xfffffe00f1009740) at /usr/src/sys/x86/x86/local_apic.c:1305 #19 0xffffffff80f849d0 in timerint_u () at /usr/src/sys/amd64/amd64/apic_vector.S:132 #20 0xfffffe00f1009828 in ?? () #21 0x000000000000b6b1 in ?? () #22 0x0000000000002000 in ?? () #23 0x00000000ffffdfff in ?? () #24 0x00c11c08e43e7fd5 in ?? () #25 0x00000000000003e8 in ?? () #26 0x00000000fffff1eb in ?? () #27 0xfffffe00f1009828 in ?? () #28 0xfffffe00f1009810 in ?? () #29 0x00000000800e6d01 in ?? () #30 0x0000000000000064 in ?? () #31 0xfffff8011d936560 in ?? () #32 0xfffffe00f1009828 in ?? () #33 0xffffffff81771014 in mtx_delay () #34 0x0000000000000000 in ?? () (kgdb)=20 . . . UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND . . . 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 [sshd] 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 = [script] 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 [xargs] 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 [xargs] . . . Context details: # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 = amd64 1200058 1200058 # svnlite status /usr/src | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/sys/vm/uma_core.c M /usr/src/usr.bin/top/machine.c The GENERIC* files include GENERIC and then set explicit debug status choices of mine. Most of the rest is tied to historical powerpc and powerpc64 investigations. I also have top report the maximum swap-in-use figure that it sees during its run. # svnlite diff /usr/src/sys/vm/uma_core.c Index: /usr/src/sys/vm/uma_core.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/uma_core.c (revision 329465) +++ /usr/src/sys/vm/uma_core.c (working copy) @@ -3428,7 +3428,7 @@ void uma_reclaim_wakeup(void) { - +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, = uma_kmem_total, uma_reclaim_needed); if (atomic_fetchadd_int(&uma_reclaim_needed, 1) =3D=3D 0) wakeup(uma_reclaim); } Side note: It took the automatic fsck and 2 manual fsck runs to get back to a clean status (before I could get to multi-user). =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 01:52:46 2018 Return-Path: Delivered-To: freebsd-current@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 815C2F022FF for ; Sun, 18 Feb 2018 01:52:46 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 1F4F27AE59; Sun, 18 Feb 2018 01:52:46 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x22c.google.com with SMTP id u99so2917594uau.8; Sat, 17 Feb 2018 17:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HcKQnbRrNxT4XKwLBdeTEH8t8rKfVAuVuZ88v4OTnQc=; b=iBsXntCWurUrNsJ1n1JW9jsZS4XCbspAHQpBKaXIJ752HNZx0Sp51hmVCfPvmf2pqW Wk1xP9MAufXq7haubpFz0EPymatsB252dTlJtmyDeopF6uUFqJBSElp1QSfXzd3K7xzt bkB14X2VfFYs+Hhwbmk0RGT8YSH0MWP6ufRya0tUHP1svWD03Bgdh8BwQAbWVip/5ZQr OuOruNWYPCfTt1ocGAD5dwc8K7PR03dxOqaK/l8yihhITwR5LUxIy8j+s1dBEIR7ORwb KB5IrkZxKO3y6c+PobqVDwFnCH9WoMPyRybQeq5vIZvlEWch1uds0xDmxDFOA7N4Kzez cMcg== 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=HcKQnbRrNxT4XKwLBdeTEH8t8rKfVAuVuZ88v4OTnQc=; b=V/XQGKGaVQpHWHHt1U4v7wkDW6gr6W5VB+stPzWYYQLznYNivNQN06QlJd2QTC5+xF 9xDlodn6UT03J4vmiLiAagf9bST8IjNO4jIbwlqYvHEaek/IBYnZPULHc9SZxP7tE0H4 WsZUbL0CcfADXbNO4Hg2d6Wf38mv9GghIuX9CISllxnE02aYzzmPMfs0nCa/7NABLsZX 6lzHssJEr6VKk6wnAwv6RS/H7/TSlnVtFur0VXIec0zfc87L//WT1bN+UZDe/gs3YzQn B6kET3ZpWYWbWVupewCG+J5AEUF2eh6AfZuU3LDQkay0I+dPz1YRpNbgSSWbUPa5/LXi SGsw== X-Gm-Message-State: APf1xPBGX29C0tiLprFCH2VWkp1pjWSAEgmfLk0W/LLTgF3KZdCTc2SQ qDrDmGbkdHPXAa0rovwroqb26sdP80pAnm3+EvZjNTTm X-Google-Smtp-Source: AH8x225z3pqJMo6A3BRL5+Xv4nVtzDYRjA6rRd98O7HJ5tg+iPLsFb4ORqU4lgSWfSgaR9WBFLqYxJllxfzEZFAGUlY= X-Received: by 10.159.36.225 with SMTP id 88mr5242170uar.77.1518918765375; Sat, 17 Feb 2018 17:52:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.4.8 with HTTP; Sat, 17 Feb 2018 17:52:44 -0800 (PST) From: Ben Woods Date: Sun, 18 Feb 2018 09:52:44 +0800 Message-ID: Subject: Buildworld failing during llvm To: FreeBSD Current , dim@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 01:52:46 -0000 Hi everyone, My attempts to build FreeBSD 12-current have been failing as of yesterday with the error below. This problem persists with current at the time of writing this email (r329497). Given llvm was updated to 6.0 around that time, I suspect it is related: https://svnweb.freebsd.org/base?view=revision&revision=329410 --- clang.full --- c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections -fdata-sections -g -O0 -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o clang.full cc1_main.o cc1as_main.o driver.o /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr -lpthread -legacy /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a: could not read symbols: Malformed archive c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [clang.full] Error code 1 Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Sun Feb 18 02:10:29 2018 Return-Path: Delivered-To: freebsd-current@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 2D2E2F03C18 for ; Sun, 18 Feb 2018 02:10:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 B2F897B992 for ; Sun, 18 Feb 2018 02:10:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 5pGTKJcVM1lFaTn92WsBY06zJcmkpSmw6pD7_Zxocn0zd137RjRa.YxdN7904yY AZ26x._0I9clW7llLfDUuBZzN9YdZafI6XL16ZIt8_ltXJSIhEd4fxhxmiNsxM63XLjRNWTGggq8 qALD29.GISsr2cRin5a0B4_FaLfraucCYpbYT3lMblQonqFNLp.HSfncJ9dz.azc6xOTFOvzpijY ROSA52QvNPYTTlMj09aZ62RCL6W8C1L80nZKMHCB2aDIjxPr_.NZMBbb4giW9_v_LQ_b0Gci4W5z iCIQZdSAIOVvLTwP2ZElvuLQx7MfvyI_QQIf.RlQQtCAHWR7BE3KhLcfEB6mib_d.AOeP32PDgcY H6k766YzwdW9vRtfB2sYcVfsT..PWbD0L3lt1nZtylN8ETx9p8rApCddn08kkvv.rRMFQszfSgA6 QWxXUhCDWY502MJbsUUlZDEsn000EXsHE5kd4oWkkDewSpDaBaiShkGzB13d8LA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Feb 2018 02:10:22 +0000 Received: from smtp101.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([68.142.231.32]) by smtp413.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 2402d0d8508818cd1bbc18952f7a8436; Sun, 18 Feb 2018 02:10:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Date: Sat, 17 Feb 2018 18:10:16 -0800 References: To: FreeBSD Current , FreeBSD Hackers In-Reply-To: Message-Id: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 02:10:29 -0000 [Some more information added, from /usr/libexec/kgdb use.] On 2018-Feb-17, at 5:39 PM, Mark Millard = wrote: > This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. > 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > Threadripper 1950X). No other Hyper-V use. >=20 > This happened during: >=20 > # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>>> Checking for old files >=20 >=20 > (Hand typed from a picture of a window's content > at slighly different times, expect typos:) >=20 > KDB: enter: panic > [thread pid 42170 tid 100752 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> call doadump > Dumping 4825 out of 110559 MB: ... (omitted) ... > Dump complete > =3D 0 >=20 >=20 > (The "pid 42170" identification as the process reporting the > issue does not seem to appear in the core.txt.0 file.) >=20 >=20 > # ls -lTdt /var/crash/* > -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 = /var/crash/core.txt.0 > lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 = /var/crash/vmcore.last -> vmcore.0 > lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 = /var/crash/info.last -> info.0 > -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 = /var/crash/vmcore.0 > -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 = /var/crash/info.0 > -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 = /var/crash/bounds > -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 = /var/crash/minfree >=20 > =46rom /var/crash/core.txt.0 : >=20 > Unread portion of the kernel message buffer: > spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long > panic: spin lock held too long > cpuid =3D 5 > time =3D 1518911834 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f10094d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 > panic() at panic+0x43/frame 0xfffffe00f1009590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f10095a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame = 0xfffffe00f1009610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 > handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 > timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame = 0xfffffe00f1009730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame = 0xfffffe00f1009880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame = 0x7fffffffcfc0 > KDB: enter: panic >=20 > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=3D-2122191464) at = /usr/src/sys/kern/kern_shutdown.c:347 > #2 0xffffffff8040b42c in db_fncall_generic (addr=3D,=20= > rv=3D, nargs=3D, args=3D) > at /usr/src/sys/ddb/db_command.c:609 > #3 db_fncall (dummy1=3D, dummy2=3D,=20 > dummy3=3D, dummy4=3D) > at /usr/src/sys/ddb/db_command.c:657 > #4 0xffffffff8040af79 in db_command (last_cmdp=3D,=20 > cmd_table=3D, dopager=3D) > at /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff8040acf4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff8040df9f in db_trap (type=3D, = code=3D) > at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80b370e3 in kdb_trap (type=3D3, code=3D-61456, = tf=3D) > at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff80fa2c5c in trap (frame=3D0xfffffe00f1009400) > at /usr/src/sys/amd64/amd64/trap.c:547 > #9 > #10 kdb_enter (why=3D0xffffffff811f280b "panic", msg=3D) > at /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80aef17a in vpanic (fmt=3D, = ap=3D0xfffffe00f1009570) > at /usr/src/sys/kern/kern_shutdown.c:801 > #12 0xffffffff80aeefc3 in panic (fmt=3D0x0) > at /usr/src/sys/kern/kern_shutdown.c:739 > #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=3D,=20 > ldap=3D) at /usr/src/sys/kern/kern_mutex.c:1224 > #14 0xffffffff80acfb9b in thread_lock_flags_ (td=3D0xfffff818719d1000,=20= > opts=3D, file=3D, line=3D) > at /usr/src/sys/kern/kern_mutex.c:913 > #15 0xffffffff80a89d6c in statclock_cnt (cnt=3D1, usermode=3D) > at /usr/src/sys/kern/kern_clock.c:768 > #16 0xffffffff810d0003 in handleevents (now=3D43230207690178, fake=3D0) > at /usr/src/sys/kern/kern_clocksource.c:196 > #17 0xffffffff810d0709 in timercb (et=3D0xffffffff81c528e8 ,=20= > arg=3D) at /usr/src/sys/kern/kern_clocksource.c:353 > #18 0xffffffff8110dad7 in lapic_handle_timer = (frame=3D0xfffffe00f1009740) > at /usr/src/sys/x86/x86/local_apic.c:1305 > #19 0xffffffff80f849d0 in timerint_u () > at /usr/src/sys/amd64/amd64/apic_vector.S:132 > #20 0xfffffe00f1009828 in ?? () > #21 0x000000000000b6b1 in ?? () > #22 0x0000000000002000 in ?? () > #23 0x00000000ffffdfff in ?? () > #24 0x00c11c08e43e7fd5 in ?? () > #25 0x00000000000003e8 in ?? () > #26 0x00000000fffff1eb in ?? () > #27 0xfffffe00f1009828 in ?? () > #28 0xfffffe00f1009810 in ?? () > #29 0x00000000800e6d01 in ?? () > #30 0x0000000000000064 in ?? () > #31 0xfffff8011d936560 in ?? () > #32 0xfffffe00f1009828 in ?? () > #33 0xffffffff81771014 in mtx_delay () > #34 0x0000000000000000 in ?? () > (kgdb)=20 >=20 > . . . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > . . . > 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] > 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] > 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 = [sshd] > 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] > 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] > 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 = [script] > 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] > 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] > 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] > 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] > 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 = [xargs] > 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] > 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 = [xargs] > . . . >=20 >=20 >=20 >=20 > Context details: >=20 > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 = amd64 1200058 1200058 >=20 > # svnlite status /usr/src | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/stand/defs.mk > M /usr/src/stand/powerpc/boot1.chrp/Makefile > M /usr/src/stand/powerpc/kboot/Makefile > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/kern/subr_pcpu.c > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/interrupt.c > M /usr/src/sys/powerpc/powerpc/mp_machdep.c > M /usr/src/sys/powerpc/powerpc/trap.c > M /usr/src/sys/vm/uma_core.c > M /usr/src/usr.bin/top/machine.c >=20 > The GENERIC* files include GENERIC and then set explicit > debug status choices of mine. Most of the rest is tied to > historical powerpc and powerpc64 investigations. I also > have top report the maximum swap-in-use figure that it > sees during its run. >=20 > # svnlite diff /usr/src/sys/vm/uma_core.c > Index: /usr/src/sys/vm/uma_core.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/vm/uma_core.c (revision 329465) > +++ /usr/src/sys/vm/uma_core.c (working copy) > @@ -3428,7 +3428,7 @@ > void > uma_reclaim_wakeup(void) > { > - > +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, = uma_kmem_total, uma_reclaim_needed); > if (atomic_fetchadd_int(&uma_reclaim_needed, 1) =3D=3D 0) > wakeup(uma_reclaim); > } >=20 >=20 >=20 > Side note: It took the automatic fsck and 2 manual fsck > runs to get back to a clean status (before I could get to > multi-user). /usr/local/bin/kgdb did not seem to work. But /usr/libexec/kgdb seems to. (This is likely the first time that I've used a normal vmcore.* file on any architecture. On powerpc I had to hack things into a non-default way of working. On powerpc64 dumps used to fail.) # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] . . . So here is what thread 100691 gets as a report in "info threads" --100752 shows "doadump", but of course was doing a fork at the time of the problem: (kgdb) info threads 558 Thread 100691 (PID=3D46769: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 . . . * 556 Thread 100752 (PID=3D42170: xargs) doadump (textdump=3D0x8181ed98) = at pcpu.h:230 . . . The bt for 558 (a.k.a. 100691) does not seem to have much information: (kgdb) thread 558 [Switching to thread 558 (Thread 100691)]#0 fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 840 movq %r12,%rdi /* function */ Current language: auto; currently asm (kgdb) bt #0 fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:840 #1 0xffffffff80f8398d in fast_syscall_common () at = /usr/src/sys/amd64/amd64/exception.S:480 #2 0x0000000800c43000 in ?? () #3 0x0000000000203353 in ?? () #4 0x0000000000000001 in .rodata () #5 0x0000000800c43008 in ?? () #6 0x00c11c08e43e7fd5 in ?? () #7 0x0000000000000000 in ?? () (kgdb)=20 But the kernel message buffer material reported: (repeated from the earlier Email) spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long I'll note that I have no known way to cause a repeat. I'd been doing the = same sort of build activity for a time when this happened. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 02:54:00 2018 Return-Path: Delivered-To: freebsd-current@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 DDDAAF077A4 for ; Sun, 18 Feb 2018 02:53:59 +0000 (UTC) (envelope-from glebius@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 7ABA87DA04 for ; Sun, 18 Feb 2018 02:53:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3ED09F0779F; Sun, 18 Feb 2018 02:53:59 +0000 (UTC) Delivered-To: current@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 02B15F0779C for ; Sun, 18 Feb 2018 02:53:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B48A7D9FE; Sun, 18 Feb 2018 02:53:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id w1I2Zkmd001485 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 18:35:46 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id w1I2ZjCo001484; Sat, 17 Feb 2018 18:35:45 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 17 Feb 2018 18:35:45 -0800 From: Gleb Smirnoff To: Andriy Gapon Cc: Andrew Reilly , kib@freebsd.org, current@freebsd.org Subject: Re: Since last week (today) current on my Ryzen box is unstable Message-ID: <20180218023545.GE93303@FreeBSD.org> References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 02:54:00 -0000 Andriy, On Sun, Feb 18, 2018 at 12:54:21AM +0200, Andriy Gapon wrote: A> > Today's rebuild has given me uptimes of below an hour, usually. The box will stay up in single user mode long enough to rebuild world/kernel, but multi-user it is panicking at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1592 A> > A> > The backtrace shows that it gets to this panic from a sendfile() syscall. The line above is in the middle of a big edit that's part of svn revision 329363. The tripping assertion seems to suggest that m->valid != 0, for whatever that's worth. A> A> I am doing a bit of an offline investigation with Andrew and it seems that the A> actual panic message is this: A> A> panic: vm_page_assert_xbusied: page 0xfffff807ebbd8f98 not exclusive busy @ A> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1592 A> A> The stack is this: A> vpanic() at vpanic/frame 0xfffffe00b3c36390 A> dmu_read_pages() at dmu_read_pages+0x535/frame 0xfffffe00b3c36460 A> zfs_freebsd_getpages() at zfs_freebsd_getpages+0x24c/frame 0xfffffe00b3c36510 A> VOP_GETPAGES_APV() at VOP_GETPAGES_APV+0xd9/frame 0xfffffe00b3c36540 A> vop_stdgetpages_async() at vop_stdgetpages_async+0x49/frame 0xfffffe00b3c36590 A> VOP_GETPAGES_ASYNC_APV() at VOP_GETPAGES_ASYNC_APV+0xd9/frame 0xfffffe00b3c365c0 A> vnode_pager_getpages_async() at vnode_pager_getpages_async+0x81/frame A> 0xfffffe00b3c36650 A> vn_sendfile() at vn_sendfile+0xe70/frame 0xfffffe00b3c368e0 A> sendfile() at sendfile+0x149/frame 0xfffffe00b3c36980 A> amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe00b3c36ab0 A> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffdb00 A> A> I looked at sendfile_swapin() code and it seems that it uses the pager API in an A> undocumented way. Specifically, it inserts bogus_page into the array of A> requested pages. For starters, bogus_page is not busied and VOP_GETPAGES is A> documented to have all requested pages exclusively busied. Second, I always had A> an impression that bogus_page is an implementation detail of the unified buffer A> / page cache and that other code need not be aware of it. A> A> So, my opinion is that the sendfile code uses a "clever hack" that happens to A> work with the buffer cache based filesystems, but that that hack is a bug. A> So, I'd prefer that the problem is fixed in that code. A> But I am open to being convinced that all VOP_GETPAGES implementations, A> including that in ZFS, must be made aware of bogus_page. Or, at least, that A> they should not verify that the requested pages are busied. This is optimization that improves throughput when file memory cache is fragmented. Why don't you like adding the code to zfs_freebsd_getpages()? -- Gleb Smirnoff From owner-freebsd-current@freebsd.org Sun Feb 18 03:24:44 2018 Return-Path: Delivered-To: freebsd-current@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 84E11F0A24D for ; Sun, 18 Feb 2018 03:24:44 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 0B8517F285 for ; Sun, 18 Feb 2018 03:24:44 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id C4518F0A24C; Sun, 18 Feb 2018 03:24:43 +0000 (UTC) Delivered-To: current@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 9FA2EF0A24B for ; Sun, 18 Feb 2018 03:24:43 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3730F7F283 for ; Sun, 18 Feb 2018 03:24:42 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yw0-x22f.google.com with SMTP id f12so2813415ywb.8 for ; Sat, 17 Feb 2018 19:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5rGIeHejNQnLgTTG3Ovq/i5yB5VdL4h7ywqFc8xY4w4=; b=TzwzClmRgDeLPUsJ954+8xN88C2HOjWITMOfis32KVde4xGx26m8JBnu0ZYLtTDUdt LP6ZGiJcJCSMquYw1PRb1Out3nvwifGAu8US0HMYW3LscuChP/g3dxJcXl6Ib4MxbGov BkOFWQOWkEx+Ofs+WFPSfPDcGl7XBC7n8Yanc4XSd3vnkLY/+4scwgFCjzozwEj/Z1ai f0vtnbfYdMKeiDiybVyA5y7sTD2BSrhztDbQVBDL27FOuP7Y4kDNd2YTV+VZK1kdUh7R h5qJ3cfGfsN8MYW/XhWS8StjnsjZRVxO1L/sn/Kqqe5ZjsKa/AApAtgkwWj6DzMeGWt1 eYLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5rGIeHejNQnLgTTG3Ovq/i5yB5VdL4h7ywqFc8xY4w4=; b=GOhxBYO/7GlaO3xNLYSnJ64nzFc73ZxopNSXyx5VQ5M/BBFZ45TYi6eJecz+OUxGW6 J+SiT7TryOR3LX7vVaVDUZO8fQ+v6NPNs/XloXKfMBMtefRzhMxmJyWNbXrPfLiKPJxa wLHo+owY2n4mzzelqq4sEZS8u/nFB5EtQYSMVxG1TY3ZDxrEoMiaExTuhLaYXLNgt8tK JDiX9q/KZ5ca5tLETj+q9qG7lMFtLPWk6SVRJCNa8PcrUoqCHt58+ffCe5PuPTYABB4O kpfjA9u9Xh+GlcfJydDV5U7FED/BPfCOitGnqkWWh4EyWW7R1UThFMMb7ofTgjO42qd1 Jeyw== X-Gm-Message-State: APf1xPBgxvLfJXp71wJPRPTwOxCDyXOjFrnrLXRZztC6ILdkyfDp+XDQ 77AbNye6JfsxKVxRRnSIXXXShpvt400PQtVuos3jMx6FBAQQkbegcZVgeNCJuOR1sGZZmK5DBP1 32F2mNw== X-Google-Smtp-Source: AH8x224DFxFqzzbtfYVBz+/68zQu6fszA0FNFOsOfhuVVTVafBv3rj1/Ptxz87oUx4RlhUOnFKGqkA== X-Received: by 10.129.117.87 with SMTP id q84mr7941726ywc.326.1518924282182; Sat, 17 Feb 2018 19:24:42 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id n9sm3606287ywb.61.2018.02.17.19.24.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2018 19:24:41 -0800 (PST) To: current , imp@freebsd.org From: Ian FREISLICH Subject: r329501 devd doesn't find USB devices Message-ID: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> Date: Sat, 17 Feb 2018 22:24:40 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 03:24:44 -0000 Hi Since devmatch some of my USB devices no longer get their drivers loaded.=C2=A0 It's not clear from UPDATING whether I needed to do anything beyond building and installing kernel and world as well as updating /etc.=C2=A0 There was reference to removing /etc/devd/usb.conf in another thread but its presence or lack thereof makes no difference. if_ure: ugen0.6: at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DON (72mA) =C2=A0 bLength =3D 0x0012 =C2=A0 bDescriptorType =3D 0x0001 =C2=A0 bcdUSB =3D 0x0300 =C2=A0 bDeviceClass =3D 0x0000=C2=A0 =C2=A0 bDeviceSubClass =3D 0x0000 =C2=A0 bDeviceProtocol =3D 0x0000 =C2=A0 bMaxPacketSize0 =3D 0x0009 =C2=A0 idVendor =3D 0x0bda =C2=A0 idProduct =3D 0x8153 =C2=A0 bcdDevice =3D 0x3000 =C2=A0 iManufacturer =3D 0x0001=C2=A0 =C2=A0 iProduct =3D 0x0002=C2=A0 =C2=A0 iSerialNumber =3D 0x0006=C2=A0 <000001> =C2=A0 bNumConfigurations =3D 0x0002 ums, ukbd: ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) =C2=A0 bLength =3D 0x0012 =C2=A0 bDescriptorType =3D 0x0001 =C2=A0 bcdUSB =3D 0x0110 =C2=A0 bDeviceClass =3D 0x0000=C2=A0 =C2=A0 bDeviceSubClass =3D 0x0000 =C2=A0 bDeviceProtocol =3D 0x0000 =C2=A0 bMaxPacketSize0 =3D 0x0040 =C2=A0 idVendor =3D 0x24ae =C2=A0 idProduct =3D 0x2000 =C2=A0 bcdDevice =3D 0x1001 =C2=A0 iManufacturer =3D 0x0001=C2=A0 =C2=A0 iProduct =3D 0x0002=C2=A0 =C2=A0 iSerialNumber =3D 0x0000=C2=A0 =C2=A0 bNumConfigurations =3D 0x0001 Ian --=20 Ian Freislich --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 03:48:22 2018 Return-Path: Delivered-To: freebsd-current@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 6E1BEF0BF95 for ; Sun, 18 Feb 2018 03:48:22 +0000 (UTC) (envelope-from wlosh@bsdimp.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 E1D8E801A1 for ; Sun, 18 Feb 2018 03:48:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9C6F3F0BF8E; Sun, 18 Feb 2018 03:48:21 +0000 (UTC) Delivered-To: current@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 78A15F0BF8D for ; Sun, 18 Feb 2018 03:48:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 129DE8019E for ; Sun, 18 Feb 2018 03:48:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id t126so8073127iof.4 for ; Sat, 17 Feb 2018 19:48:21 -0800 (PST) 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=q0sZ4dDgO7+K1llAqQKf8KqQo8JJAgM47992JnJav/0=; b=Eo9WU1zLOYTxucfuyt6q9PpTV7QRa0WOogpUL9i/mxXaMnc+Z3VNfQbSqj6e2GH82U yxhWUVCx2zoMxh2RKjoR4TfBZODIef1egbtJgAW+60nvoqP/Lt6R7+JU/v5ug+ofiPGF 2jEo/NUvdZdybz0kT7Tx8sErwkV88Q9qftv07hwhCamoMTS6xrg/rouKALyjPqB8qqc4 m/yf+f5zmUfDsR1LeqvT3msAbIWACElRnV5bHFwDsWZK26JghnJP0Y8SykPsGTqk7YJV t7pAp9YfzzNSSvxlGA8r9crRL/Jen5t/HdFlNEeo4D4gfDD4dgfyfQLNBZV9jQzdMis7 WHmg== 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=q0sZ4dDgO7+K1llAqQKf8KqQo8JJAgM47992JnJav/0=; b=o5key+9dz8K3+FgiXHDy0XQszjekeDmu7UYNd3Hzv1K/F/HjESgNKO5Exq/mEcZlBa /j2xRb3HM6LQGOelROp8mGciURZF1vcurx9q8I322kRWmZpLok1D19BKQKNbf3ZJzcK4 b5ZlFKQyAHmW+0gSnzZ4IE/Loo9VMuO2f1k2ZIJRn4v5QCI5CshcerTITisgqQ4El2iO Vn+LAVMpds9N0/SLvdEGBaO0MTOypmlqR5iIIbhVl0wCVXSrujZqO21S3NcTeRy2sgEi ekYuFO9wQK1DR6qYxUBpX8wlz2hsWkU6UTpeq6dvO2pUIrbNLeIpyrYzkAQNd99ugcgo CWPg== X-Gm-Message-State: APf1xPCaL9J/yjJGQqQAza5s59VzS7ZusR2yqxUPagI+1FDXkANnakOZ Q6asX7NInbmC/w+wZx/xnc5q1rm2/9gX/geZFcY14Q== X-Google-Smtp-Source: AH8x225P6WuDhwLHpHrrMChJyUhG0okGh1kO4OSTCE/mNKUrEaS2Ol8SLQ1LazfrgUmr1S19Lmp/SZ3sIaCC+CfLnUc= X-Received: by 10.107.142.13 with SMTP id q13mr14664398iod.299.1518925700011; Sat, 17 Feb 2018 19:48:20 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sat, 17 Feb 2018 19:48:19 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:8d85:51e:3310:75e4] Received: by 10.79.201.67 with HTTP; Sat, 17 Feb 2018 19:48:19 -0800 (PST) In-Reply-To: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Warner Losh Date: Sat, 17 Feb 2018 20:48:19 -0700 X-Google-Sender-Auth: YxEl3PqVAbYx04D_QqRTHr17WDk Message-ID: Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH Cc: FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 03:48:22 -0000 On Feb 17, 2018 8:24 PM, "Ian FREISLICH" wrote: Hi Since devmatch some of my USB devices no longer get their drivers loaded. It's not clear from UPDATING whether I needed to do anything beyond building and installing kernel and world as well as updating /etc. There was reference to removing /etc/devd/usb.conf in another thread but its presence or lack thereof makes no difference. I assume you've fully updated including /etc. if_ure: ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <000001> bNumConfigurations = 0x0002 ums, ukbd: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x24ae idProduct = 0x2000 bcdDevice = 0x1001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 If you can uncomment the devd lines in syslog.conf, touch /var/log/devd.log and reboot. Once you are up again, please send me /var/log/devd.conf. Warner From owner-freebsd-current@freebsd.org Sun Feb 18 04:14:35 2018 Return-Path: Delivered-To: freebsd-current@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 5B529F0E0E4 for ; Sun, 18 Feb 2018 04:14:35 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 C7B0681238 for ; Sun, 18 Feb 2018 04:14:34 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8C816F0E0D0; Sun, 18 Feb 2018 04:14:34 +0000 (UTC) Delivered-To: current@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 5C082F0E0CF for ; Sun, 18 Feb 2018 04:14:34 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE4D281235 for ; Sun, 18 Feb 2018 04:14:33 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-oi0-x22a.google.com with SMTP id 24so5061843oij.3 for ; Sat, 17 Feb 2018 20:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=QeR9fremRpXRbnvOzW1poRh0IqhSm0uz8JBX0WumLos=; b=L5ALBRT8FLl/QS18JsRHo5dKzXly0BIGSMuetEBIJSlpO5aGtVVu8pvKSxVO84kwk3 QTuwC/mWBFyiCWtJxzGA0SshKKB62cMhwsNfHRoEvIlHYPAdGtd5DOkQruWr9vKFHqbX /akAkFOM13YTUKU55j6n/Z5abhTmC5nO7deOMNVlrb8aJopLWND7g2wd1x6YQXqW0pLr RDFULSQkLxpavcVGPrYp5dKKtDpS5rve9PAfNlU7rwxNnOG6+ZKfxWy+sYUpJdMxET+e GcAORwwOwj0+U6VTWD1AvWtPNGf2dUCRKD/hoFCYU7YuVXWUvQ3tzefuFKa22m1RKIMT yXjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QeR9fremRpXRbnvOzW1poRh0IqhSm0uz8JBX0WumLos=; b=owAi22+0K74EUDz8IdVkWdjuWzwBWi7y9cYW6bxGng4CFFiXh0wb0bV1YAhXbPEtaZ kZTBtDauCkPcMaYdnGm0T3RoYQOZBsO+kV0AcEW/UbUTNg0zI+3jTnRF3pfccYPB6EpQ 9fSxg3/Wx7pxH935cHCtV6jaJjzhI2NZIHnwyv05TnVwoMTZmwRy+P+3u41Xi4kh4wCc ESo9gYsmNMUts7MTDgAFa5Icd4aLh/DZP2bi8QmkOr8ImET+YxRwlyTNRzG/oAqpg1tw 0OkycFow0H4dx6mv9ANQbzu3/hK4RARQEzFnz4f4lrXnN+qqDvVzQbdWq//MBGN2odRf v5Uw== X-Gm-Message-State: APf1xPD04GlpDNcwnbnpTurAVU0SWDwYtdorz74o9EIhGJubMzLmj24P ycoGgZMYWEhMbiRH+MYzt/FCBbpWTllHPCXK0CyLW6Gb6BGCBwYgR4GXgIEUofNrwBrMEltdwO6 +Z5UpJQ== X-Google-Smtp-Source: AH8x2274bp4rSkuJYv6pkvK00CF5YpuYiMj5rczX0wOArnnv3qA5I1PzsEPk+9cbsP/9J78b5ACOvg== X-Received: by 10.202.207.151 with SMTP id f145mr7928128oig.263.1518927272699; Sat, 17 Feb 2018 20:14:32 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id 38sm11298528otq.0.2018.02.17.20.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2018 20:14:32 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices To: Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Ian FREISLICH Message-ID: Date: Sat, 17 Feb 2018 23:14:31 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 04:14:35 -0000 On 02/17/18 22:48, Warner Losh wrote: > On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > > > wrote: > > Hi > > Since devmatch some of my USB devices no longer get their drivers > loaded.=C2=A0 It's not clear from UPDATING whether I needed to do any= thing > beyond building and installing kernel and world as well as updating > /etc.=C2=A0 There was reference to removing /etc/devd/usb.conf in ano= ther > thread but its presence or lack thereof makes no difference. > > > I assume you've fully updated including /etc. In as much as 'mergemaster -Ui' fully updates /etc > If you can uncomment the devd lines in syslog.conf, touch > /var/log/devd.log and reboot. Once you are up again, please send me > /var/log/devd.conf. Assuming you mean these lines: !devd *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /var/log/devd.log devd produced zero logs on reboot and restart. Ian --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 07:26:49 2018 Return-Path: Delivered-To: freebsd-current@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 CBF5AF19E43 for ; Sun, 18 Feb 2018 07:26:49 +0000 (UTC) (envelope-from hps@selasky.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 6B22B87DFE for ; Sun, 18 Feb 2018 07:26:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2AD90F19E31; Sun, 18 Feb 2018 07:26:49 +0000 (UTC) Delivered-To: current@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 1846CF19E30 for ; Sun, 18 Feb 2018 07:26:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB66087DF8; Sun, 18 Feb 2018 07:26:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B36692604C3; Sun, 18 Feb 2018 08:26:45 +0100 (CET) Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH , Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Hans Petter Selasky Message-ID: Date: Sun, 18 Feb 2018 08:23:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 07:26:50 -0000 On 02/18/18 05:14, Ian FREISLICH wrote: > On 02/17/18 22:48, Warner Losh wrote: >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> > >> wrote: >> >> Hi >> >> Since devmatch some of my USB devices no longer get their drivers >> loaded.  It's not clear from UPDATING whether I needed to do anything >> beyond building and installing kernel and world as well as updating >> /etc.  There was reference to removing /etc/devd/usb.conf in another >> thread but its presence or lack thereof makes no difference. >> >> >> I assume you've fully updated including /etc. > > In as much as 'mergemaster -Ui' fully updates /etc > >> If you can uncomment the devd lines in syslog.conf, touch >> /var/log/devd.log and reboot. Once you are up again, please send me >> /var/log/devd.conf. > > Assuming you mean these lines: > > !devd > *.>=notice                                      /var/log/devd.log > > devd produced zero logs on reboot and restart. Can you run: usbconfig show_ifdrv Maybe the wrong driver captured your device? Try running: usbconfig -d X.Y reset --HPS From owner-freebsd-current@freebsd.org Sun Feb 18 07:28:42 2018 Return-Path: Delivered-To: freebsd-current@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 C73D8F1A16B for ; Sun, 18 Feb 2018 07:28:42 +0000 (UTC) (envelope-from agapon@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 5EE4187FA9 for ; Sun, 18 Feb 2018 07:28:42 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1FEC7F1A166; Sun, 18 Feb 2018 07:28:42 +0000 (UTC) Delivered-To: current@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 ED001F1A165 for ; Sun, 18 Feb 2018 07:28:41 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 5D88787FA3; Sun, 18 Feb 2018 07:28:41 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id q194so9119013lfe.13; Sat, 17 Feb 2018 23:28:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gyjFeFG1MDYt2sco42JS8X/p1yBsPt/60AMQdHHTdg8=; b=kGZdfs+RgBcuGSDjex/1iDa7tZscW8ZzqtTx2HC6paTf5qX5Nl5JRZNJ6lioaPaExN 7Ni6f0w72kRjafJ/65xlZ2YNuyqQ0wY/wdnIV3ZeYBrEZOzTSHUF4yFZzr9hYs5lET0r fUvetYLp3uYSG1G3o2vSKvH2O1eDXr1t0VFJtEu9pvbRUJ5DuRJyz5qaxLK7zmaFA7lI 2a7+rt8M95kVxLjN3mVmnFGDv+M/ZwHh5W6sy681RcupZiEag3jlCbbDnjCTMwc6lest 4Rx819oZCZ0FTbkauPIbxeF9sD+E1m8HlyUbRNBKPECz1r7WNN7Ib+YZFoNCGJEN6g4/ K0zw== X-Gm-Message-State: APf1xPCi9xKZ6WE2JnVxA8ZFngzh+fSIRRExMkHgqI9uT5NUY919wXRd 3KalE1HGZWzXfoR0k1EZec0InxRV X-Google-Smtp-Source: AH8x2260N70HRvKQm6Sq2W4gzStvOlPPzVDMiRjAKLDETniqZNdBWo4puGJB6RxKhePiKopCNruAMw== X-Received: by 10.25.87.193 with SMTP id l184mr7119448lfb.2.1518938913145; Sat, 17 Feb 2018 23:28:33 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q133sm3573758lfe.60.2018.02.17.23.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2018 23:28:32 -0800 (PST) Subject: Re: Since last week (today) current on my Ryzen box is unstable To: Gleb Smirnoff Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> From: Andriy Gapon Message-ID: <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> Date: Sun, 18 Feb 2018 09:28:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218023545.GE93303@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 07:28:43 -0000 On 18/02/2018 04:35, Gleb Smirnoff wrote: > Andriy, > > On Sun, Feb 18, 2018 at 12:54:21AM +0200, Andriy Gapon wrote: > A> > Today's rebuild has given me uptimes of below an hour, usually. The box will stay up in single user mode long enough to rebuild world/kernel, but multi-user it is panicking at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1592 > A> > > A> > The backtrace shows that it gets to this panic from a sendfile() syscall. The line above is in the middle of a big edit that's part of svn revision 329363. The tripping assertion seems to suggest that m->valid != 0, for whatever that's worth. > A> > A> I am doing a bit of an offline investigation with Andrew and it seems that the > A> actual panic message is this: > A> > A> panic: vm_page_assert_xbusied: page 0xfffff807ebbd8f98 not exclusive busy @ > A> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1592 > A> > A> The stack is this: > A> vpanic() at vpanic/frame 0xfffffe00b3c36390 > A> dmu_read_pages() at dmu_read_pages+0x535/frame 0xfffffe00b3c36460 > A> zfs_freebsd_getpages() at zfs_freebsd_getpages+0x24c/frame 0xfffffe00b3c36510 > A> VOP_GETPAGES_APV() at VOP_GETPAGES_APV+0xd9/frame 0xfffffe00b3c36540 > A> vop_stdgetpages_async() at vop_stdgetpages_async+0x49/frame 0xfffffe00b3c36590 > A> VOP_GETPAGES_ASYNC_APV() at VOP_GETPAGES_ASYNC_APV+0xd9/frame 0xfffffe00b3c365c0 > A> vnode_pager_getpages_async() at vnode_pager_getpages_async+0x81/frame > A> 0xfffffe00b3c36650 > A> vn_sendfile() at vn_sendfile+0xe70/frame 0xfffffe00b3c368e0 > A> sendfile() at sendfile+0x149/frame 0xfffffe00b3c36980 > A> amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe00b3c36ab0 > A> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffdb00 > A> > A> I looked at sendfile_swapin() code and it seems that it uses the pager API in an > A> undocumented way. Specifically, it inserts bogus_page into the array of > A> requested pages. For starters, bogus_page is not busied and VOP_GETPAGES is > A> documented to have all requested pages exclusively busied. Second, I always had > A> an impression that bogus_page is an implementation detail of the unified buffer > A> / page cache and that other code need not be aware of it. > A> > A> So, my opinion is that the sendfile code uses a "clever hack" that happens to > A> work with the buffer cache based filesystems, but that that hack is a bug. > A> So, I'd prefer that the problem is fixed in that code. > A> But I am open to being convinced that all VOP_GETPAGES implementations, > A> including that in ZFS, must be made aware of bogus_page. Or, at least, that > A> they should not verify that the requested pages are busied. > > This is optimization that improves throughput when file memory cache is > fragmented. Why don't you like adding the code to zfs_freebsd_getpages()? I cited two reasons above and expected to hear some counter-points rather than them being ignored :-) If we settle upon allowing bogus_page to be used in ma[], then that will obviously need to be documented. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Feb 18 10:41:39 2018 Return-Path: Delivered-To: freebsd-current@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 6E599F24D7E for ; Sun, 18 Feb 2018 10:41:39 +0000 (UTC) (envelope-from lists@opsec.eu) 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 130E570334 for ; Sun, 18 Feb 2018 10:41:39 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id CBA43F24D7D; Sun, 18 Feb 2018 10:41:38 +0000 (UTC) Delivered-To: current@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 B7E1BF24D7C for ; Sun, 18 Feb 2018 10:41:38 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D63270330 for ; Sun, 18 Feb 2018 10:41:38 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enMPZ-000GFD-IA for current@freebsd.org; Sun, 18 Feb 2018 11:41:37 +0100 Date: Sun, 18 Feb 2018 11:41:37 +0100 From: Kurt Jaeger To: current@freebsd.org Subject: How to find CPU microcode version ? Message-ID: <20180218104137.GA32429@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 10:41:39 -0000 Hi! How do I find the microcode version a Intel CPU is currently using ? Background: When Spectre/Meltdown hit, Intel released new microcode around 20180108. I've used the devcpu-data port at that time to update the microcode at that time, and the box in question developed strange instability issues approx. since 14th of Februar. It had two updates since 8th of January, to r328013 on the 16th of Jan. and to r328899 on the 6th of February. Around the 14th, processes started to be killed for out of swapspace, even if the box had almost no load at all. pid 1056 (mutt), uid 104, was killed: out of swap space pid 536 (devd), uid 0, was killed: out of swap space pid 15093 (exim), uid 26, was killed: out of swap space pid 91868 (mutt), uid 104, was killed: out of swap space pid 1086 (sshd), uid 104, was killed: out of swap space Reboot of the box and waiting a few hours and the problem re-occured. The box has 32 GB RAM and 34 GB swap, which never was utilized beyond a few hundred MBs. Moving the two disks involved to a very similar hardware and the 'dying' stopped. The 'strange box' runs a debian version now for 24 hours, no problems. -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sun Feb 18 12:25:40 2018 Return-Path: Delivered-To: freebsd-current@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 D197CF03A29; Sun, 18 Feb 2018 12:25:39 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53A0773E3E; Sun, 18 Feb 2018 12:25:39 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1ICPI0w026091 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 13:25:18 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1ICPHNx026088; Sun, 18 Feb 2018 13:25:18 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 13:25:17 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 12:25:40 -0000 On Sat, 17 Feb 2018 17:39-0800, Mark Millard wrote: > This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > Threadripper 1950X). No other Hyper-V use. > > This happened during: > > # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh check-old DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > Script started, output file is /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20 > >>> Checking for old files > > > (Hand typed from a picture of a window's content > at slighly different times, expect typos:) > > KDB: enter: panic > [thread pid 42170 tid 100752 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> call doadump > Dumping 4825 out of 110559 MB: ... (omitted) ... > Dump complete > = 0 > > > (The "pid 42170" identification as the process reporting the > issue does not seem to appear in the core.txt.0 file.) > > > # ls -lTdt /var/crash/* > -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 /var/crash/core.txt.0 > lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 /var/crash/vmcore.last -> vmcore.0 > lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 /var/crash/info.last -> info.0 > -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 /var/crash/vmcore.0 > -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 /var/crash/info.0 > -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 /var/crash/bounds > -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 /var/crash/minfree > > >From /var/crash/core.txt.0 : > > Unread portion of the kernel message buffer: > spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 (tid 100691) too long > panic: spin lock held too long > cpuid = 5 > time = 1518911834 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f10094d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 > panic() at panic+0x43/frame 0xfffffe00f1009590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 0xfffffe00f10095a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1009610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 > handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 > timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1009730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1009880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffcfc0 > KDB: enter: panic > > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=-2122191464) at /usr/src/sys/kern/kern_shutdown.c:347 > #2 0xffffffff8040b42c 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 0xffffffff8040af79 in db_command (last_cmdp=, > cmd_table=, dopager=) > at /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff8040acf4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff8040df9f in db_trap (type=, code=) > at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80b370e3 in kdb_trap (type=3, code=-61456, tf=) > at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff80fa2c5c in trap (frame=0xfffffe00f1009400) > at /usr/src/sys/amd64/amd64/trap.c:547 > #9 > #10 kdb_enter (why=0xffffffff811f280b "panic", msg=) > at /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80aef17a in vpanic (fmt=, ap=0xfffffe00f1009570) > at /usr/src/sys/kern/kern_shutdown.c:801 > #12 0xffffffff80aeefc3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:739 > #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=, > ldap=) at /usr/src/sys/kern/kern_mutex.c:1224 > #14 0xffffffff80acfb9b in thread_lock_flags_ (td=0xfffff818719d1000, > opts=, file=, line=) > at /usr/src/sys/kern/kern_mutex.c:913 > #15 0xffffffff80a89d6c in statclock_cnt (cnt=1, usermode=) > at /usr/src/sys/kern/kern_clock.c:768 > #16 0xffffffff810d0003 in handleevents (now=43230207690178, fake=0) > at /usr/src/sys/kern/kern_clocksource.c:196 > #17 0xffffffff810d0709 in timercb (et=0xffffffff81c528e8 , > arg=) at /usr/src/sys/kern/kern_clocksource.c:353 > #18 0xffffffff8110dad7 in lapic_handle_timer (frame=0xfffffe00f1009740) > at /usr/src/sys/x86/x86/local_apic.c:1305 > #19 0xffffffff80f849d0 in timerint_u () > at /usr/src/sys/amd64/amd64/apic_vector.S:132 > #20 0xfffffe00f1009828 in ?? () > #21 0x000000000000b6b1 in ?? () > #22 0x0000000000002000 in ?? () > #23 0x00000000ffffdfff in ?? () > #24 0x00c11c08e43e7fd5 in ?? () > #25 0x00000000000003e8 in ?? () > #26 0x00000000fffff1eb in ?? () > #27 0xfffffe00f1009828 in ?? () > #28 0xfffffe00f1009810 in ?? () > #29 0x00000000800e6d01 in ?? () > #30 0x0000000000000064 in ?? () > #31 0xfffff8011d936560 in ?? () > #32 0xfffffe00f1009828 in ?? () > #33 0xffffffff81771014 in mtx_delay () > #34 0x0000000000000000 in ?? () > (kgdb) > > . . . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > . . . > 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] > 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] > 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 [sshd] > 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] > 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] > 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 [script] > 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] > 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] > 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] > 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] > 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 [xargs] > 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] > 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 [xargs] > . . . > > > > > Context details: > > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 amd64 1200058 1200058 > > # svnlite status /usr/src | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/stand/defs.mk > M /usr/src/stand/powerpc/boot1.chrp/Makefile > M /usr/src/stand/powerpc/kboot/Makefile > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/kern/subr_pcpu.c > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/interrupt.c > M /usr/src/sys/powerpc/powerpc/mp_machdep.c > M /usr/src/sys/powerpc/powerpc/trap.c > M /usr/src/sys/vm/uma_core.c > M /usr/src/usr.bin/top/machine.c > > The GENERIC* files include GENERIC and then set explicit > debug status choices of mine. Most of the rest is tied to > historical powerpc and powerpc64 investigations. I also > have top report the maximum swap-in-use figure that it > sees during its run. > > # svnlite diff /usr/src/sys/vm/uma_core.c > Index: /usr/src/sys/vm/uma_core.c > =================================================================== > --- /usr/src/sys/vm/uma_core.c (revision 329465) > +++ /usr/src/sys/vm/uma_core.c (working copy) > @@ -3428,7 +3428,7 @@ > void > uma_reclaim_wakeup(void) > { > - > +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, uma_kmem_total, uma_reclaim_needed); > if (atomic_fetchadd_int(&uma_reclaim_needed, 1) == 0) > wakeup(uma_reclaim); > } > > > > Side note: It took the automatic fsck and 2 manual fsck > runs to get back to a clean status (before I could get to > multi-user). The same thing happened to me on a VirtualBox VM running base/head r329515. This VM previously ran r329101 and I can easily revert to this version where the problem doesn't exist. See https://ximalas.info/~trond/base-head-r329515/ for core.txt.0 and info.0. Crash dump of roughly 1 GiB is available on request. I achieved an uptime of roughly 26 minutes before the panic set in. I was in the process of upgrading print/texinfo using portmaster when the crash occurred. xargs was the running process. Unread portion of the kernel message buffer: spin lock 0xffffffff80e76e80 (sched lock 0) held by 0xfffff800c58d4000 (tid 100746) too long panic: spin lock held too long cpuid = 0 time = 1518955069 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff804d281b = db_trace_self_wrapper+0x2b/frame 0xfffffe004b204610 vpanic() at 0xffffffff807106cd = vpanic+0x18d/frame 0xfffffe004b204670 panic() at 0xffffffff80710533 = panic+0x43/frame 0xfffffe004b2046d0 _mtx_lock_indefinite_check() at 0xffffffff806f0fa1 = _mtx_lock_indefinite_check+0x71/frame 0xfffffe004b2046e0 thread_lock_flags_() at 0xffffffff806f110b = thread_lock_flags_+0xdb/frame 0xfffffe004b204750 statclock_cnt() at 0xffffffff806ab0dc = statclock_cnt+0xdc/frame 0xfffffe004b204790 handleevents() at 0xffffffff80a72d73 = handleevents+0x113/frame 0xfffffe004b2047e0 timercb() at 0xffffffff80a73479 = timercb+0xa9/frame 0xfffffe004b204830 lapic_handle_timer() at 0xffffffff80ad6237 = lapic_handle_timer+0xa7/frame 0xfffffe004b204870 timerint_u() at 0xffffffff80a1f080 = timerint_u+0x96/frame 0xfffffe004b204950 thread_lock_flags_() at 0xffffffff806f10f1 = thread_lock_flags_+0xc1/frame 0xfffffe004b2049c0 fork1() at 0xffffffff806d124f = fork1+0x1b9f/frame 0xfffffe004b204a70 sys_vfork() at 0xffffffff806d17ec = sys_vfork+0x4c/frame 0xfffffe004b204ac0 amd64_syscall() at 0xffffffff80a3d6c8 = amd64_syscall+0xa48/frame 0xfffffe004b204bf0 fast_syscall_common() at 0xffffffff80a1e03d = fast_syscall_common+0x101/frame 0x7fffffffe000 Uptime: 26m5s Dumping 1003 out of 6123 MB:..2%..12%..21%..31%..42%..52%..61%..71%..82%..91% __curthread () at ./machine/pcpu.h:230 230 ./machine/pcpu.h: No such file or directory. (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:347 #2 0xffffffff80710200 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #3 0xffffffff8071072d in vpanic (fmt=, ap=0xfffffe004b2046b0) at /usr/src/sys/kern/kern_shutdown.c:812 #4 0xffffffff80710533 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:739 #5 0xffffffff806f0fa1 in _mtx_lock_indefinite_check (m=, ldap=) at /usr/src/sys/kern/kern_mutex.c:1224 #6 0xffffffff806f110b in thread_lock_flags_ (td=0xfffff8006205d000, opts=, file=, line=) at /usr/src/sys/kern/kern_mutex.c:913 #7 0xffffffff806ab0dc in statclock_cnt (cnt=1, usermode=) at /usr/src/sys/kern/kern_clock.c:768 #8 0xffffffff80a72d73 in handleevents (now=6721246917305, fake=0) at /usr/src/sys/kern/kern_clocksource.c:196 #9 0xffffffff80a73479 in timercb (et=0xffffffff80f80ad8 , arg=) at /usr/src/sys/kern/kern_clocksource.c:353 #10 0xffffffff80ad6237 in lapic_handle_timer (frame=0xfffffe004b204880) at /usr/src/sys/x86/x86/local_apic.c:1305 #11 0xffffffff80a1f080 in timerint_u () at /usr/src/sys/amd64/amd64/apic_vector.S:132 #12 0xfffffe004b204968 in ?? () #13 0x0000000000001b8d in ?? () #14 0x0000000000000800 in ?? () #15 0x00000000fffff7ff in ?? () #16 0x0000000080000034 in ?? () #17 0x00000000000001f4 in ?? () #18 0x00000000fffff8eb in ?? () #19 0xfffffe004b204968 in ?? () #20 0xfffffe004b204950 in ?? () #21 0x000000008000ba2f in ?? () #22 0x0000000000000032 in ?? () #23 0xfffff800c58d4000 in ?? () #24 0xfffffe004b204968 in ?? () #25 0xffffffff80c41014 in mtx_delay () #26 0x0000000000000000 in ?? () Looking at the commit logs, I suspect r329419, r329420, r329422, and/or r320449 being possible candidates. I'll try revert my source tree to r329418, and take it from there. -- Trond. From owner-freebsd-current@freebsd.org Sun Feb 18 12:30:04 2018 Return-Path: Delivered-To: freebsd-current@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 8E42AF03D8D for ; Sun, 18 Feb 2018 12:30:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) 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 218C373FCD for ; Sun, 18 Feb 2018 12:30:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: by mailman.ysv.freebsd.org (Postfix) id D7068F03D8B; Sun, 18 Feb 2018 12:30:03 +0000 (UTC) Delivered-To: current@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 B4B34F03D8A for ; Sun, 18 Feb 2018 12:30:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 35BCA73FCC for ; Sun, 18 Feb 2018 12:30:02 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Sun, 18 Feb 2018 13:29:56 +0100 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 93E299F6-3195-4057-A163-FDE55E7CABC9.1 envelope-from (authenticated bits=0); Sun, 18 Feb 2018 13:29:44 +0100 From: Rainer Duffner Message-Id: <90A19A4E-C6FB-4FD7-81A5-DAE6280AE78F@ultra-secure.de> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: How to find CPU microcode version ? Date: Sun, 18 Feb 2018 13:29:39 +0100 In-Reply-To: <20180218104137.GA32429@home.opsec.eu> Cc: current@freebsd.org To: Kurt Jaeger References: <20180218104137.GA32429@home.opsec.eu> X-Mailer: Apple Mail (2.3445.5.20) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=12 total_conn=1 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 4954, bad: 1, connections: 5434, history: 4953, asn_score: 671, asn_connections: 706, asn_good: 671, asn_bad: 0, pass:asn, asn_all_good, relaying Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 12:30:04 -0000 > Am 18.02.2018 um 11:41 schrieb Kurt Jaeger : >=20 > Hi! >=20 > How do I find the microcode version a Intel CPU is currently using ?=20= >=20 AFAIK: All Linux-vendors have retracted their microcode-updates, for the time = being. If your BIOS-vendor didn=E2=80=99t provide you an updated BIOS, just = forget about =E2=80=9Efixing" the various Spectre-variants. From owner-freebsd-current@freebsd.org Sun Feb 18 13:26:45 2018 Return-Path: Delivered-To: freebsd-current@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 0D179F07808 for ; Sun, 18 Feb 2018 13:26:45 +0000 (UTC) (envelope-from glebius@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 9C1D47679A for ; Sun, 18 Feb 2018 13:26:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5D426F07807; Sun, 18 Feb 2018 13:26:44 +0000 (UTC) Delivered-To: current@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 4AA9DF07806 for ; Sun, 18 Feb 2018 13:26:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B610B76795; Sun, 18 Feb 2018 13:26:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id w1IDQNNm004845 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 05:26:24 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id w1IDQN5L004844; Sun, 18 Feb 2018 05:26:23 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 18 Feb 2018 05:26:23 -0800 From: Gleb Smirnoff To: Andriy Gapon Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org Subject: Re: Since last week (today) current on my Ryzen box is unstable Message-ID: <20180218132623.GF93303@FreeBSD.org> References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 13:26:45 -0000 On Sun, Feb 18, 2018 at 09:28:30AM +0200, Andriy Gapon wrote: A> > A> vnode_pager_getpages_async() at vnode_pager_getpages_async+0x81/frame A> > A> 0xfffffe00b3c36650 A> > A> vn_sendfile() at vn_sendfile+0xe70/frame 0xfffffe00b3c368e0 A> > A> sendfile() at sendfile+0x149/frame 0xfffffe00b3c36980 A> > A> amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe00b3c36ab0 A> > A> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffdb00 A> > A> A> > A> I looked at sendfile_swapin() code and it seems that it uses the pager API in an A> > A> undocumented way. Specifically, it inserts bogus_page into the array of A> > A> requested pages. For starters, bogus_page is not busied and VOP_GETPAGES is A> > A> documented to have all requested pages exclusively busied. Second, I always had A> > A> an impression that bogus_page is an implementation detail of the unified buffer A> > A> / page cache and that other code need not be aware of it. A> > A> A> > A> So, my opinion is that the sendfile code uses a "clever hack" that happens to A> > A> work with the buffer cache based filesystems, but that that hack is a bug. A> > A> So, I'd prefer that the problem is fixed in that code. A> > A> But I am open to being convinced that all VOP_GETPAGES implementations, A> > A> including that in ZFS, must be made aware of bogus_page. Or, at least, that A> > A> they should not verify that the requested pages are busied. A> > A> > This is optimization that improves throughput when file memory cache is A> > fragmented. Why don't you like adding the code to zfs_freebsd_getpages()? A> A> I cited two reasons above and expected to hear some counter-points rather than A> them being ignored :-) A> If we settle upon allowing bogus_page to be used in ma[], then that will A> obviously need to be documented. My only point is that it is a performance improvement. IMHO that's enough :) If you can't suggest a more elegant way of doing that improvement, then all I can suggest is to document it and add its support to ZFS. -- Gleb Smirnoff From owner-freebsd-current@freebsd.org Sun Feb 18 13:32:23 2018 Return-Path: Delivered-To: freebsd-current@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 3AA59F07F9E for ; Sun, 18 Feb 2018 13:32:23 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 E199876CCE for ; Sun, 18 Feb 2018 13:32:22 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9AED1F07F8A; Sun, 18 Feb 2018 13:32:22 +0000 (UTC) Delivered-To: current@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 5D90CF07F80 for ; Sun, 18 Feb 2018 13:32:22 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1216B76CBE for ; Sun, 18 Feb 2018 13:32:22 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-ua0-x235.google.com with SMTP id u99so3356617uau.8 for ; Sun, 18 Feb 2018 05:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=1EAK5kJfqzZypSRbw46zoCQU8IPuWd1cVsUgul7HGuk=; b=BB5+oSr5GM7boRQ8lN80A/kz8P/wygy4dEaDTdeGlyofGxjNVZMsIpq3MGMJ4ApbKb 1HWjGiJJ9WYhbX5s5R4JuRhXQel4t/1HL57SIGugzOeFMZ4z7iL8uNfaltL5lwXob4+k LuIo0VPWowUn3cWG+q/x5HSzU3mUKgatnMqpJHaXna9WMZ+Cr4Jzo8z53GUmJFPu26SX 74jTdETObtmMAtH8ki+bVr7FCta5mZuvt9AuI70Kwxgtd6EiM9ktR+tKpQOtCQgqLlt8 yHFgGWu9b/l8z/oifh/JIqlsFNPHZsoUSTwKgqYdAy/Jyx8jIC6zbI8fT2Sk/IpT79oP Refw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=1EAK5kJfqzZypSRbw46zoCQU8IPuWd1cVsUgul7HGuk=; b=ConBIszkzw5tn/Gk1rtQFfzHyAwUZDc7Dz9rtMruPIPfmbbcA8qRr61LbA7MjdkDnE KH+nBl8Ee9C8ZhdlmjIa2t6m6/CDOS0vonmUVkB6TWhxqYdpJbpBx1lZFS3wyzGbW1Sv AiNZAy/oR4uuoCYyd5CjcqIKRE9Cl63kt2zNjvQSZ7Jx8s2BOuU/zLcVG6+aMI/oOeQt fsTtkgb3/SU5I6wLWsX+QR/GXnLKlxYkfr5bmnWp3Eu+8OWQq975tbddu8jbXtBSoWCC ZkgNZJavjdC/noJ8dksU+t93Kd4PXBzLiQt7N5ZNS4BE4ynuq29UzBZ0+WGqTqelXNnj 6s3A== X-Gm-Message-State: APf1xPAOwUSO62KB5ST0sibdriYlBoF67SOX4C0dp9iloQlY/9DOQctZ 1sVh2AE6jEZraLWu0znJFtXMO4/XInCoMvefZq9ZI8UhlWMTX0ADuY8iCm34kp+x344kvsNCX3f gKA9L9A== X-Google-Smtp-Source: AH8x227M/m/7rUtx4o783fd96ckxbMo3Xp7seHvYmtjDH1i/sqg71HIxuANbGQVjbV5v5kxfFFS1NA== X-Received: by 10.159.61.88 with SMTP id m24mr9125231uai.139.1518960741073; Sun, 18 Feb 2018 05:32:21 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id k123sm3315282vkb.34.2018.02.18.05.32.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 05:32:20 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices To: Hans Petter Selasky , Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Ian FREISLICH Message-ID: <514d3c3f-996d-6299-396a-ae161e6f730b@capeaugusta.com> Date: Sun, 18 Feb 2018 08:32:19 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------DA3165BA7EAD78A8833A9647" Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 13:32:23 -0000 This is a multi-part message in MIME format. --------------DA3165BA7EAD78A8833A9647 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 02/18/18 02:23, Hans Petter Selasky wrote: > On 02/18/18 05:14, Ian FREISLICH wrote: >> On 02/17/18 22:48, Warner Losh wrote: >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> > >>> wrote: >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0 Hi >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0 Since devmatch some of my USB devices no longe= r get their drivers >>> =C2=A0=C2=A0=C2=A0=C2=A0 loaded.=C2=A0 It's not clear from UPDATING whe= ther I needed to do >>> anything >>> =C2=A0=C2=A0=C2=A0=C2=A0 beyond building and installing kernel and worl= d as well as >>> updating >>> =C2=A0=C2=A0=C2=A0=C2=A0 /etc.=C2=A0 There was reference to removing /e= tc/devd/usb.conf in >>> another >>> =C2=A0=C2=A0=C2=A0=C2=A0 thread but its presence or lack thereof makes = no difference. >>> >>> >>> I assume you've fully updated including /etc. >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >>> If you can uncomment the devd lines in syslog.conf, touch >>> /var/log/devd.log and reboot. Once you are up again, please send me >>> /var/log/devd.conf. >> >> Assuming you mean these lines: >> >> !devd >> *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 /var/log/devd.log >> >> devd produced zero logs on reboot and restart. > > Can you run: > > usbconfig show_ifdrv > > Maybe the wrong driver captured your device? ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DSAVE (0mA) ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) ugen0.3: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) ugen0.3.0: ubt0: ugen0.4: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) ugen0.5: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) ugen0.6: at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DON (72mA) After loading ums and ukbd: ugen0.5: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) ugen0.5.0: ukbd0: ugen0.5.1: ums0: > Try running: > > usbconfig -d X.Y reset This produces no kernel messages, no difference to drivers. --=20 --------------DA3165BA7EAD78A8833A9647 Content-Type: text/plain; charset=UTF-8; name="device_desc.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="device_desc.txt" dWdlbjAuMTogPDB4ODA4NiBYSENJIHJvb3QgSFVCPiBhdCB1c2J1czAsIGNmZz0wIG1kPUhP U1Qgc3BkPVNVUEVSICg1LjBHYnBzKSBwd3I9U0FWRSAoMG1BKQoKICBiTGVuZ3RoID0gMHgw MDEyIAogIGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwMSAKICBiY2RVU0IgPSAweDAzMDAgCiAg YkRldmljZUNsYXNzID0gMHgwMDA5ICA8SFVCPgogIGJEZXZpY2VTdWJDbGFzcyA9IDB4MDAw MCAKICBiRGV2aWNlUHJvdG9jb2wgPSAweDAwMDMgCiAgYk1heFBhY2tldFNpemUwID0gMHgw MDA5IAogIGlkVmVuZG9yID0gMHgwMDAwIAogIGlkUHJvZHVjdCA9IDB4MDAwMCAKICBiY2RE ZXZpY2UgPSAweDAxMDAgCiAgaU1hbnVmYWN0dXJlciA9IDB4MDAwMSAgPDB4ODA4Nj4KICBp UHJvZHVjdCA9IDB4MDAwMiAgPFhIQ0kgcm9vdCBIVUI+CiAgaVNlcmlhbE51bWJlciA9IDB4 MDAwMCAgPG5vIHN0cmluZz4KICBiTnVtQ29uZmlndXJhdGlvbnMgPSAweDAwMDEgCgp1Z2Vu MC4yOiA8QXp1cmVXYXZlIFVTQjIuMCBWR0EgVVZDIFdlYkNhbT4gYXQgdXNidXMwLCBjZmc9 MCBtZD1IT1NUIHNwZD1ISUdIICg0ODBNYnBzKSBwd3I9T04gKDUwMG1BKQoKICBiTGVuZ3Ro ID0gMHgwMDEyIAogIGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwMSAKICBiY2RVU0IgPSAweDAy MDAgCiAgYkRldmljZUNsYXNzID0gMHgwMGVmICA8TWlzY2VsbGFuZW91cyBkZXZpY2U+CiAg YkRldmljZVN1YkNsYXNzID0gMHgwMDAyIAogIGJEZXZpY2VQcm90b2NvbCA9IDB4MDAwMSAK ICBiTWF4UGFja2V0U2l6ZTAgPSAweDAwNDAgCiAgaWRWZW5kb3IgPSAweDEzZDMgCiAgaWRQ cm9kdWN0ID0gMHg1NzU1IAogIGJjZERldmljZSA9IDB4MTYxMiAKICBpTWFudWZhY3R1cmVy ID0gMHgwMDAzICA8QXp1cmVXYXZlPgogIGlQcm9kdWN0ID0gMHgwMDAxICA8VVNCMi4wIFZH QSBVVkMgV2ViQ2FtPgogIGlTZXJpYWxOdW1iZXIgPSAweDAwMDIgIDwwMDAxPgogIGJOdW1D b25maWd1cmF0aW9ucyA9IDB4MDAwMSAKCnVnZW4wLjM6IDx2ZW5kb3IgMHg4MDg3IHByb2R1 Y3QgMHgwYTJiPiBhdCB1c2J1czAsIGNmZz0wIG1kPUhPU1Qgc3BkPUZVTEwgKDEyTWJwcykg cHdyPU9OICgxMDBtQSkKCiAgYkxlbmd0aCA9IDB4MDAxMiAKICBiRGVzY3JpcHRvclR5cGUg PSAweDAwMDEgCiAgYmNkVVNCID0gMHgwMjAwIAogIGJEZXZpY2VDbGFzcyA9IDB4MDBlMCAg PFdpcmVsZXNzIGNvbnRyb2xsZXI+CiAgYkRldmljZVN1YkNsYXNzID0gMHgwMDAxIAogIGJE ZXZpY2VQcm90b2NvbCA9IDB4MDAwMSAKICBiTWF4UGFja2V0U2l6ZTAgPSAweDAwNDAgCiAg aWRWZW5kb3IgPSAweDgwODcgCiAgaWRQcm9kdWN0ID0gMHgwYTJiIAogIGJjZERldmljZSA9 IDB4MDAxMCAKICBpTWFudWZhY3R1cmVyID0gMHgwMDAwICA8bm8gc3RyaW5nPgogIGlQcm9k dWN0ID0gMHgwMDAwICA8bm8gc3RyaW5nPgogIGlTZXJpYWxOdW1iZXIgPSAweDAwMDAgIDxu byBzdHJpbmc+CiAgYk51bUNvbmZpZ3VyYXRpb25zID0gMHgwMDAxIAoKdWdlbjAuNDogPEVM QU4gRUxBTkZpbmdlcnByaW50PiBhdCB1c2J1czAsIGNmZz0wIG1kPUhPU1Qgc3BkPUZVTEwg KDEyTWJwcykgcHdyPU9OICgxMDBtQSkKCiAgYkxlbmd0aCA9IDB4MDAxMiAKICBiRGVzY3Jp cHRvclR5cGUgPSAweDAwMDEgCiAgYmNkVVNCID0gMHgwMjAwIAogIGJEZXZpY2VDbGFzcyA9 IDB4MDAwMCAgPFByb2JlZCBieSBpbnRlcmZhY2UgY2xhc3M+CiAgYkRldmljZVN1YkNsYXNz ID0gMHgwMDAwIAogIGJEZXZpY2VQcm90b2NvbCA9IDB4MDAwMCAKICBiTWF4UGFja2V0U2l6 ZTAgPSAweDAwMDggCiAgaWRWZW5kb3IgPSAweDA0ZjMgCiAgaWRQcm9kdWN0ID0gMHgwOTAz IAogIGJjZERldmljZSA9IDB4MDEzNSAKICBpTWFudWZhY3R1cmVyID0gMHgwMDAxICA8RUxB Tj4KICBpUHJvZHVjdCA9IDB4MDAwMiAgPEVMQU46RmluZ2VycHJpbnQ+CiAgaVNlcmlhbE51 bWJlciA9IDB4MDAwMCAgPG5vIHN0cmluZz4KICBiTnVtQ29uZmlndXJhdGlvbnMgPSAweDAw MDEgCgp1Z2VuMC41OiA8UkFQT08gUkFQT08gMi40RyBXaXJlbGVzcyBEZXZpY2U+IGF0IHVz YnVzMCwgY2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAoMTJNYnBzKSBwd3I9T04gKDEwMG1BKQoK ICBiTGVuZ3RoID0gMHgwMDEyIAogIGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwMSAKICBiY2RV U0IgPSAweDAxMTAgCiAgYkRldmljZUNsYXNzID0gMHgwMDAwICA8UHJvYmVkIGJ5IGludGVy ZmFjZSBjbGFzcz4KICBiRGV2aWNlU3ViQ2xhc3MgPSAweDAwMDAgCiAgYkRldmljZVByb3Rv Y29sID0gMHgwMDAwIAogIGJNYXhQYWNrZXRTaXplMCA9IDB4MDA0MCAKICBpZFZlbmRvciA9 IDB4MjRhZSAKICBpZFByb2R1Y3QgPSAweDIwMDAgCiAgYmNkRGV2aWNlID0gMHgxMDAxIAog IGlNYW51ZmFjdHVyZXIgPSAweDAwMDEgIDxSQVBPTz4KICBpUHJvZHVjdCA9IDB4MDAwMiAg PFJBUE9PIDIuNEcgV2lyZWxlc3MgRGV2aWNlPgogIGlTZXJpYWxOdW1iZXIgPSAweDAwMDAg IDxubyBzdHJpbmc+CiAgYk51bUNvbmZpZ3VyYXRpb25zID0gMHgwMDAxIAoKdWdlbjAuNjog PENNSSBVU0IgMTAxMDAxMDAwIExBTj4gYXQgdXNidXMwLCBjZmc9MCBtZD1IT1NUIHNwZD1T VVBFUiAoNS4wR2JwcykgcHdyPU9OICg3Mm1BKQoKICBiTGVuZ3RoID0gMHgwMDEyIAogIGJE ZXNjcmlwdG9yVHlwZSA9IDB4MDAwMSAKICBiY2RVU0IgPSAweDAzMDAgCiAgYkRldmljZUNs YXNzID0gMHgwMDAwICA8UHJvYmVkIGJ5IGludGVyZmFjZSBjbGFzcz4KICBiRGV2aWNlU3Vi Q2xhc3MgPSAweDAwMDAgCiAgYkRldmljZVByb3RvY29sID0gMHgwMDAwIAogIGJNYXhQYWNr ZXRTaXplMCA9IDB4MDAwOSAKICBpZFZlbmRvciA9IDB4MGJkYSAKICBpZFByb2R1Y3QgPSAw eDgxNTMgCiAgYmNkRGV2aWNlID0gMHgzMDAwIAogIGlNYW51ZmFjdHVyZXIgPSAweDAwMDEg IDxDTUk+CiAgaVByb2R1Y3QgPSAweDAwMDIgIDxVU0IgMTAvMTAwLzEwMDAgTEFOPgogIGlT ZXJpYWxOdW1iZXIgPSAweDAwMDYgIDwwMDAwMDE+CiAgYk51bUNvbmZpZ3VyYXRpb25zID0g MHgwMDAyIAoK --------------DA3165BA7EAD78A8833A9647-- From owner-freebsd-current@freebsd.org Sun Feb 18 14:06:28 2018 Return-Path: Delivered-To: freebsd-current@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 5DCB9F0AC37 for ; Sun, 18 Feb 2018 14:06:28 +0000 (UTC) (envelope-from lists@opsec.eu) 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 F3FCB79218 for ; Sun, 18 Feb 2018 14:06:27 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id B1D29F0AC33; Sun, 18 Feb 2018 14:06:27 +0000 (UTC) Delivered-To: current@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 9E002F0AC30 for ; Sun, 18 Feb 2018 14:06:27 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36E4F79217 for ; Sun, 18 Feb 2018 14:06:27 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enPbp-000Gc0-6N; Sun, 18 Feb 2018 15:06:29 +0100 Date: Sun, 18 Feb 2018 15:06:29 +0100 From: Kurt Jaeger To: current@FreeBSD.org Cc: current@freebsd.org Subject: Re: How to find CPU microcode version ? Message-ID: <20180218140629.GB32429@home.opsec.eu> References: <20180218104137.GA32429@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180218104137.GA32429@home.opsec.eu> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 14:06:28 -0000 Hi! > How do I find the microcode version a Intel CPU is currently using ? I was pointed to https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-tool-for-freebsd.64588/ which points to: https://github.com/kernschmelze/cpupdate Works! -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sun Feb 18 15:45:15 2018 Return-Path: Delivered-To: freebsd-current@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 54297F127E3 for ; Sun, 18 Feb 2018 15:45:15 +0000 (UTC) (envelope-from lists@opsec.eu) 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 EA9DF7CCDC for ; Sun, 18 Feb 2018 15:45:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id AA0D4F127E0; Sun, 18 Feb 2018 15:45:14 +0000 (UTC) Delivered-To: current@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 97F62F127DF for ; Sun, 18 Feb 2018 15:45:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 341AC7CCD9 for ; Sun, 18 Feb 2018 15:45:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enR9Q-000Glk-LP for current@FreeBSD.org; Sun, 18 Feb 2018 16:45:16 +0100 Date: Sun, 18 Feb 2018 16:45:16 +0100 From: Kurt Jaeger To: current@FreeBSD.org Subject: Re: How to find CPU microcode version ? Message-ID: <20180218154516.GE32429@home.opsec.eu> References: <20180218104137.GA32429@home.opsec.eu> <20180218140629.GB32429@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180218140629.GB32429@home.opsec.eu> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 15:45:15 -0000 Hi! > > How do I find the microcode version a Intel CPU is currently using ? > > I was pointed to > > https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-tool-for-freebsd.64588/ > > which points to: > > https://github.com/kernschmelze/cpupdate > > Works! So: On the box which showed problems, I had: -> CPUID: 306a9 Family: 06 Model: 3A Stepping: 09 uCodeRev: 00000012 Update done with pkg install devcpu-data service microcode_update start Now I have: -> CPUID: 306a9 Family: 06 Model: 3A Stepping: 09 uCodeRev: 0000001C On the spare box that shows no sign of trouble: -> CPUID: 306a9 Family: 06 Model: 3A Stepping: 09 uCodeRev: 00000019 Hmm. -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sun Feb 18 17:17:19 2018 Return-Path: Delivered-To: freebsd-current@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 E7808F1999C for ; Sun, 18 Feb 2018 17:17:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86249808BA for ; Sun, 18 Feb 2018 17:17:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1850E1E585; Sun, 18 Feb 2018 18:17:11 +0100 (CET) From: Dimitry Andric Message-Id: <7EECF1BF-CC59-48A4-BE54-B8425AE0545F@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_106C2E11-3C8A-4B8C-A057-C94C46140F1D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Buildworld failing during llvm Date: Sun, 18 Feb 2018 18:17:10 +0100 In-Reply-To: Cc: FreeBSD Current To: Ben Woods References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 17:17:19 -0000 --Apple-Mail=_106C2E11-3C8A-4B8C-A057-C94C46140F1D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Feb 2018, at 02:52, Ben Woods wrote: > > My attempts to build FreeBSD 12-current have been failing as of yesterday > with the error below. This problem persists with current at the time of > writing this email (r329497). > > Given llvm was updated to 6.0 around that time, I suspect it is related: > https://svnweb.freebsd.org/base?view=revision&revision=329410 > > > --- clang.full --- > c++ -O2 -pipe > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm > -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections > -fdata-sections -g -O0 -Qunused-arguments > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 > -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions > -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o clang.full cc1_main.o cc1as_main.o driver.o > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw > -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr > -lpthread -legacy > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a: > could not read symbols: Malformed archive Hi Ben, This is most likely because you are setting CFLAGS to "-g -O0", which causes libllvm.a and libclang.a to become too big (>2GiB) for ar to handle. Then the linker finds the archive malformed. John Baldwin added some special handling for libraries under lib/clang, so they emit smaller debug information, so just leave out -g from your CFLAGS, buildworld will automatically take care of applying the right -g flags in all the various places. -Dimitry --Apple-Mail=_106C2E11-3C8A-4B8C-A057-C94C46140F1D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWom1FgAKCRCwXqMKLiCW o5gLAKCH4U8h/cdH8qWoWeYJgKswIe/GdgCeKwBMlFY/vQMTQI40QIn/GNiW630= =dQmj -----END PGP SIGNATURE----- --Apple-Mail=_106C2E11-3C8A-4B8C-A057-C94C46140F1D-- From owner-freebsd-current@freebsd.org Sun Feb 18 17:35:28 2018 Return-Path: Delivered-To: freebsd-current@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 6D1CBF1AF42 for ; Sun, 18 Feb 2018 17:35:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 EB2A8815CE for ; Sun, 18 Feb 2018 17:35:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ioAI0.cVM1lRnXssqgmnZ2UmeUn4av3USwvkx1Omcl72ZhB8TmenK.miKxsNPpJ zQqJfqI1GePPocDdnqbZGW0TfUlBLjKggMHwM8OcFicz8r0826lpCQFzC4TfOqX1ZDS0zu8.I.lV j.2s11dH96339AmHQj0IC02bCyV.mgxGxXh4Vou4S6lpZimnD54sRB4Ci1430nEhaV92Gpjg8Gv1 5YyTDJru3xmN96NLh3rtu.O4X170YWgYE8KR1nY8fvo5VuSSxBpjq94gmamDmQIArEnzwnnsqIoK UIybJ.fsxs7j5PlSzCc_ABdF.I9QnWjDZXjXihVnZVPcN9_G53fWq9IfxnalvvrhUIJ5Li_ihPDa gwwu4UbLRUl7Yy2kA6KvUNlK.nLbN6wTg7CXiPQMjUw188NqBTObHFxKcOk_YhCDFjy6.cAkmtlR uVKUTplASFU_3urcmD5mzBySDxPbLlC1ZMIotpZhHgJE4ovLi.sVth0XOE9R5Re0qhRDw Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 17:35:21 +0000 Received: from smtp104.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.214]) by smtp402.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 96e403d0707c1cd692e984bac48f01ad; Sun, 18 Feb 2018 17:35:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Date: Sun, 18 Feb 2018 09:35:16 -0800 References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> To: FreeBSD Current , FreeBSD Hackers In-Reply-To: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> Message-Id: <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 17:35:28 -0000 On 2018-Feb-17, at 6:10 PM, Mark Millard = wrote: > [Some more information added, from /usr/libexec/kgdb use.] >=20 > On 2018-Feb-17, at 5:39 PM, Mark Millard = wrote: >=20 >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro = machine. >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen >> Threadripper 1950X). No other Hyper-V use. Trond's report seems to be for a "4 core" Intel i7 context (as seen by FreeBSD in virtual box). So Ryzen seems to be non-essential for reproduction. Both of our reports are from some form of using FreeBSD in a virtual machine (Hyper-V and VirtualBox). I do not know if that is a required type of context or not. >> This happened during: >>=20 >> # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils >> Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>>>> Checking for old files >>=20 I got another example but during a buildworld: >>> Deleting stale files in build tree... cd /usr/src; MACHINE_ARCH=3Dpowerpc64 MACHINE=3Dpowerpc CPUTYPE=3D = BUILD_TOOLS_META=3D.NOMETA CC=3D"cc -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX=3D"c++ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP=3D"cpp -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" = AS=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/as" = AR=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" = LD=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=3D"" = NM=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/nm = OBJCOPY=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/ranlib = STRINGS=3D/usr/local/bin/powerpc64-unknown-freebsd12.0-strings = SIZE=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/o= bj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.power= pc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_a= ltbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/= bin:/usr/sbin:/usr/bin = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp make -f Makefile.inc1 BWPHASE=3Dworldtmp = DESTDIR=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp -DBATCH_DELETE_OLD_FILES delete-old = delete-old-libs >/dev/null load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k make: Working in: = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc= .powerpc64 packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe (I noticed the long pause and got the ^T in before the panic.) Yet again it is xargs related fork activity that gets the problem (from = core.txt.1 ): 561 Thread 100836 (PID=3D69982: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 . . . * 559 Thread 100811 (PID=3D62304: xargs) doadump (textdump=3D-2122191464)= at pcpu.h:230 spin lock 0xffffffff81b3cf00 (sched lock 24) held by 0xfffff806aa6d5000 = (tid 100836) too long panic: spin lock held too long cpuid =3D 24 time =3D 1518974055 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f11304d0 vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 panic() at panic+0x43/frame 0xfffffe00f1130590 _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f11305a0 thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1130610 statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1130730 timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1130880 fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffc5a0 =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 18:08:08 2018 Return-Path: Delivered-To: freebsd-current@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 6D6FFF1D9D1; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 0744382ED8; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id v90so6963034qte.12; Sun, 18 Feb 2018 10:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=MC4uFCPU9o5Ih7ORz48ie/x1LY2t3QACrkuaTLpZKPB1RTBIgR+SMVBJbOk40TyLn5 iIt1BClBfB+F4uI8SKz3VCb9UyVe64PTq6LIQ+CpcMrecAoiS5bAGigXxrAPTWQzt1i2 AsR4DrMEmuZnp6jZi9ujIhfLkNKcqTpVmYlQCylaiuP4es/R7UD4997sULko7s8qmsXU UzBE2e6uXm3VjNHGBK0k5XOGH4E472cOnGHQVGA5HMsbmMbcdjxKmEiwyCTcJU8EP835 Czs5+FBurGdwJqKqsr/kECDtnxuiR2IM7u1L6UhEmDFZt+2CPmQ2h1BTSO0ecLZ0P5YB NdfA== 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=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=SAP+Ji0RI0C0zIo2ISIszlk2kWmkG7Yq4u0kHPt4CCw9YNQqV0cpwSK0usHPmMQhJB 6y0FdDQQ1kJifnpAlfp++WbunFOvfYN6KeUYgMJyyk5nKKIw+RoZS3epUZKsxHynN4vk IrshpR+dkyNX/K6kr89A3HvXhY6jjhwYxjrShX7nJSnoI2x2geEGFpz9kjun6dCyNEr6 ZHZJwa9YviCy57FBv6ZPw5T+M/7zhcmVPgDTMKwYkz3hPSmcfJwJ6iWXKVc0zRx5sRFn P9EteRwzGJpVNT9mme5spCsQy1KYpBo/S+lBBdt7YlescS/hrAQKGQ9xiMqElS6IysAC iUQQ== X-Gm-Message-State: APf1xPAExGn3ZU+ZB04GJyr0UizDsFu93n2qmga6+ekcANSz8FTk6oQr kRbdK7Q27uzX4KKKrvJJkm7+kXF34EfAnDoPYWI= X-Google-Smtp-Source: AH8x225nxW9c4CsaZ7LS+bMN1XEaYpHsQxqpAGlxP9cnM2fz7V6+/MWdXJJwrNp00Fh6YugJPS0w4sNsWD3CYd3yfxk= X-Received: by 10.200.38.188 with SMTP id 57mr6877681qto.220.1518977287640; Sun, 18 Feb 2018 10:08:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 10:08:07 -0800 (PST) In-Reply-To: <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 19:08:07 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mark Millard Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 18:08:08 -0000 Can you please bisect this? There is another report stating that r329418 works fine. On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: > > On 2018-Feb-17, at 6:10 PM, Mark Millard > wrote: > > > [Some more information added, from /usr/libexec/kgdb use.] > > > > On 2018-Feb-17, at 5:39 PM, Mark Millard > wrote: > > > >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > >> Threadripper 1950X). No other Hyper-V use. > > Trond's report seems to be for a "4 core" Intel i7 context (as seen > by FreeBSD in virtual box). So Ryzen seems to be non-essential for > reproduction. > > Both of our reports are from some form of using FreeBSD in a virtual > machine (Hyper-V and VirtualBox). I do not know if that is a required > type of context or not. > > >> This happened during: > >> > >> # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_ > nodebug_clang_altbinutils-amd64-host.sh check-old > DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > >> Script started, output file is /root/sys_typescripts/ > typescript_make_powerpc64vtsc_nodebug_clang_altbinutils- > amd64-host-2018-02-17:15:56:20 > >>>>> Checking for old files > >> > > I got another example but during a buildworld: > > >>> Deleting stale files in build tree... > cd /usr/src; MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= > BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0 > --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++ -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP="cpp -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" > AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as" > AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" > LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK="" > NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm > OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" > RANLIB=/usr/local/powerpc64-unknown- > freebsd12.0/bin/ranlib STRINGS=/usr/local/bin/ > powerpc64-unknown-freebsd12.0-strings SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size" > INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/powerpc64vtsc_ > clang_altbinutils/powerpc.powerpc64/usr/src/powerpc. > powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > make -f Makefile.inc1 BWPHASE=worldtmp DESTDIR=/usr/obj/ > powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -DBATCH_DELETE_OLD_FILES delete-old d > elete-old-libs >/dev/null > > load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k > make: Working in: /usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64 > packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe > > > (I noticed the long pause and got the ^T in before the panic.) > > Yet again it is xargs related fork activity that gets the problem (from > core.txt.1 ): > > 561 Thread 100836 (PID=69982: xargs) fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:840 > . . . > * 559 Thread 100811 (PID=62304: xargs) doadump (textdump=-2122191464) at > pcpu.h:230 > > spin lock 0xffffffff81b3cf00 (sched lock 24) held by 0xfffff806aa6d5000 > (tid 100836) too long > panic: spin lock held too long > cpuid = 24 > time = 1518974055 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00f11304d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 > panic() at panic+0x43/frame 0xfffffe00f1130590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame > 0xfffffe00f11305a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1130610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 > handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 > timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1130730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1130880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffc5a0 > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Sun Feb 18 18:28:46 2018 Return-Path: Delivered-To: freebsd-current@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 82EE7F1F744 for ; Sun, 18 Feb 2018 18:28:46 +0000 (UTC) (envelope-from ml@netfence.it) Received: from smtp209.alice.it (smtp209.alice.it [82.57.200.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF1283C68 for ; Sun, 18 Feb 2018 18:28:45 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu (87.18.51.42) by smtp209.alice.it (8.6.060.28) id 5A88C32E002D94AB for freebsd-current@freebsd.org; Sun, 18 Feb 2018 19:28:39 +0100 Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) by soth.ventu (8.15.2/8.15.2) with ESMTP id w1IISc7o036997 for ; Sun, 18 Feb 2018 19:28:38 +0100 (CET) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.ventu: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu Subject: Re: How to find CPU microcode version ? To: freebsd-current@freebsd.org References: <20180218104137.GA32429@home.opsec.eu> From: Andrea Venturoli Message-ID: <90550601-e86b-a72d-83b6-405a371bb457@netfence.it> Date: Sun, 18 Feb 2018 19:28:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218104137.GA32429@home.opsec.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 18:28:46 -0000 On 02/18/18 11:41, Kurt Jaeger wrote: > Reboot of the box and waiting a few hours and the problem re-occured. Doesn't the work of microcode_update vanish after a reboot? Unless of course you set up rc.conf to repeat it at every start... bye av. From owner-freebsd-current@freebsd.org Sun Feb 18 18:48:22 2018 Return-Path: Delivered-To: freebsd-current@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 5D2B9F20D0D for ; Sun, 18 Feb 2018 18:48:22 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECA9284ACC for ; Sun, 18 Feb 2018 18:48:21 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enU0f-000IS0-37; Sun, 18 Feb 2018 19:48:25 +0100 Date: Sun, 18 Feb 2018 19:48:25 +0100 From: Kurt Jaeger To: Andrea Venturoli Cc: freebsd-current@freebsd.org Subject: Re: How to find CPU microcode version ? Message-ID: <20180218184825.GG32429@home.opsec.eu> References: <20180218104137.GA32429@home.opsec.eu> <90550601-e86b-a72d-83b6-405a371bb457@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90550601-e86b-a72d-83b6-405a371bb457@netfence.it> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 18:48:22 -0000 Hi! > On 02/18/18 11:41, Kurt Jaeger wrote: > > > Reboot of the box and waiting a few hours and the problem re-occured. > > Doesn't the work of microcode_update vanish after a reboot? Thanks. I was not sure and tested this. Indeed, yes, the microcode update is reverted by rebooting. Then I have some other issue, because my problems were ongoing after reboots. > Unless of course you set up rc.conf to repeat it at every start... -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Sun Feb 18 19:30:44 2018 Return-Path: Delivered-To: freebsd-current@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 C5281F23C60; Sun, 18 Feb 2018 19:30:44 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4079086BA6; Sun, 18 Feb 2018 19:30:43 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IJUYlY028458 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 20:30:34 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IJUY5K028455; Sun, 18 Feb 2018 20:30:34 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 20:30:34 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 19:30:44 -0000 On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that r329418 > works fine. My problems started yesterday with r329464. I decided to go back to r329101 (ZFS BE), update the source tree, move forward to the latest revision, and so on. I even emptied /usr/obj and /var/cache/ccache and set WITHOUT_SYSTEM_COMPILER=yes in /etc/src.conf to get rid of any bias. I have tried with success r329418, r329419, r329420, and r329422. I'm now at r329448 and have not seen any spin lock problems so far. Sooner or later I'll reach r329464 and by then it should be clear which revision is the likely culprit. -- Trond. From owner-freebsd-current@freebsd.org Sun Feb 18 19:52:05 2018 Return-Path: Delivered-To: freebsd-current@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 EA46BF25237 for ; Sun, 18 Feb 2018 19:52:04 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 90E3B87B89 for ; Sun, 18 Feb 2018 19:52:04 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 5uz4meQVM1kbbDfbbDEEecZVxP3jU75lHCnMSy2oMdaCEOWIwMjI6k86bWoYsyi QRhNU87cnIe1MnK293QAur7PsNlbuouVpXjz74x07mZAZkItVZW5geiHqpia87ldFt3RTnUOiksL 6mx8kdj_jki.Ubl8h0pJvtAd_z72ZKLFpXHTw6e5LDu4SpHDKpyki71UWA77iH5BUzxXEPTRiBxr uK_cQpLe9NWdfAcW1PZ.J5oYFK08bJkuW8km4fEvsvHB.9NzONsYnDCytZtB9Essh3lOc_gjTG0v 4NYgYOjU99fkC0CTJ0PPs9R6tXK37et3yh6mLYhy_4Uujkj06_mdJaXawt.cQy1tLdtex7ExeaBg VT.sWQdXVpebk.P5eyTnBMQnH6mxhCff9axVu.WsivUbj.v4rr8GlwOySoAHu3I7oI6YJ918IpRr .hcg8LtYrb2kec3NasmcGygxX78AYNUZqpjcPFyQd6KH00VRiyncS_V4PQQdc_MDvd8JZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Feb 2018 19:51:58 +0000 Received: from smtp101.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([68.142.231.32]) by smtp409.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID ba15a840364f155c1584bae7ccf8d823; Sun, 18 Feb 2018 19:51:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 11:51:52 -0800 Cc: FreeBSD Current , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> To: =?utf-8?Q?Trond_Endrest=C3=B8l?= X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 19:52:05 -0000 On 2018-Feb-18, at 11:30 AM, Trond Endrest=C3=B8l wrote: > On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: >=20 >> Can you please bisect this? There is another report stating that = r329418 >> works fine. >=20 > My problems started yesterday with r329464. I decided to go back to=20 > r329101 (ZFS BE), update the source tree, move forward to the latest=20= > revision, and so on. I even emptied /usr/obj and /var/cache/ccache and=20= > set WITHOUT_SYSTEM_COMPILER=3Dyes in /etc/src.conf to get rid of any=20= > bias. >=20 > I have tried with success r329418, r329419, r329420, and r329422. >=20 > I'm now at r329448 and have not seen any spin lock problems so far. Note: -r329448 was reverted in -r329461 : racy. > Sooner or later I'll reach r329464 and by then it should be clear=20 > which revision is the likely culprit. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 20:00:01 2018 Return-Path: Delivered-To: freebsd-current@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 5E33AF25A92 for ; Sun, 18 Feb 2018 20:00:01 +0000 (UTC) (envelope-from wlosh@bsdimp.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 E62726805C for ; Sun, 18 Feb 2018 20:00:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id A469DF25A89; Sun, 18 Feb 2018 20:00:00 +0000 (UTC) Delivered-To: current@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 6A046F25A81 for ; Sun, 18 Feb 2018 20:00:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB6FF68057 for ; Sun, 18 Feb 2018 19:59:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id l12so3510445ioc.10 for ; Sun, 18 Feb 2018 11:59:59 -0800 (PST) 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=PGEBOXC68Vnrvflz3x6CZ0dQc/frRyyIuHE2Y7DTngg=; b=LyjpkVii3WpNS9iq4koDx5bcpV8Pm/88eTmbw2TBVNAkUoFj+7jv/gKD5tt0OCek0Z 6yAuHaD6fdeQ9QQmjZM/wd0/e+6M7ODML3BypBXK7PdCX6c1cgaqUBhYsanM9oNf4WsQ TjYRGGg9086m+M3si9h8dl7Hv7n2NTP39YuNnvfkRclXer0PcBH3F9W5JIgCJwHHR2aF Ed3GK04PGn9y8DB093kaYSMM7DRisYf5xpSWp77r6QaZhZP6Kv1OL7FHZVmAzVqwOsCS uNpdniNHJbP/yf1zxVy1WruVoShqF53dG7jty60ml7JtVXmUVeecbkdzBXsyPfOaI09X STbQ== 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=PGEBOXC68Vnrvflz3x6CZ0dQc/frRyyIuHE2Y7DTngg=; b=N62fezktrJ1HnPFaQgwM9YEB9sWlLHNGWJsG7zk6olhyWztA82y4Pn1vO2ETtH92Uo V7FYV7AQ4E8IAWO7/0F7CXfUhhicYOQgTY5NkmnZjvAo8UAswarwVo8F+5ZN87yFKNah mcI2WCRRzeXmJLoUDCwoZjrzJ/cFmR5sc55UJag5K+ZyP6ebaj/mzCXMdH6p4WcE2oO/ c9sEWYCcbSUIRKpDEcWqVW5jA9t8CBoDaL+4I5Mb0RLhlPGydCyf6G8zocainlTyp7Ht leH1LFe4YpgJW3IbZ1WjtumZItMH6sX5AxAk2YA9ztoh2/+lR1m7tijKT+RKaGQYZVYI Ddrw== X-Gm-Message-State: APf1xPCo7NszCC5Ynie4PDlW8q5gD1lSpUH0eNwprh5TR5eVjZgIjxIl 77m3+tMhQj7YzMCg19bN3p/pWI+Nm9U8/wqw/iy1BA== X-Google-Smtp-Source: AH8x227eVUBrVruayVKDVuLzCOr0JMN+ODTIRO7lS2oqykiKQX683sb4GgiCr215GSSoB1NQQ8N8bpxW7/fDO7jMQfE= X-Received: by 10.107.2.6 with SMTP id 6mr16786227ioc.117.1518983999084; Sun, 18 Feb 2018 11:59:59 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 18 Feb 2018 11:59:58 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <514d3c3f-996d-6299-396a-ae161e6f730b@capeaugusta.com> References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <514d3c3f-996d-6299-396a-ae161e6f730b@capeaugusta.com> From: Warner Losh Date: Sun, 18 Feb 2018 12:59:58 -0700 X-Google-Sender-Auth: JxLLzaUaUWi3L5aZdb4FqfDWIZI Message-ID: Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH Cc: Hans Petter Selasky , FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:00:01 -0000 On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH < ian.freislich@capeaugusta.com> wrote: > On 02/18/18 02:23, Hans Petter Selasky wrote: > > On 02/18/18 05:14, Ian FREISLICH wrote: > >> On 02/17/18 22:48, Warner Losh wrote: > >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > >>> > > >>> wrote: > >>> > >>> Hi > >>> > >>> Since devmatch some of my USB devices no longer get their drivers > >>> loaded. It's not clear from UPDATING whether I needed to do > >>> anything > >>> beyond building and installing kernel and world as well as > >>> updating > >>> /etc. There was reference to removing /etc/devd/usb.conf in > >>> another > >>> thread but its presence or lack thereof makes no difference. > >>> > >>> > >>> I assume you've fully updated including /etc. > >> > >> In as much as 'mergemaster -Ui' fully updates /etc > >> > >>> If you can uncomment the devd lines in syslog.conf, touch > >>> /var/log/devd.log and reboot. Once you are up again, please send me > >>> /var/log/devd.conf. > >> > >> Assuming you mean these lines: > >> > >> !devd > >> *.>=notice /var/log/devd.log > >> > >> devd produced zero logs on reboot and restart. > > > > Can you run: > > > > usbconfig show_ifdrv > > > > Maybe the wrong driver captured your device? > > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=SAVE (0mA) > ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> > ugen0.2: at usbus0, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON (500mA) > ugen0.3: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.3.0: ubt0: 2.00/0.10, addr 2> > ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON (100mA) > ugen0.5: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=ON (72mA) > > After loading ums and ukbd: > > ugen0.5: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON (100mA) > ugen0.5.0: ukbd0: 1.10/10.01, addr 5> > ugen0.5.1: ums0: 1.10/10.01, addr 5> > So what happens if you build these drivers into the kernel vs loading them? Warner From owner-freebsd-current@freebsd.org Sun Feb 18 20:08:26 2018 Return-Path: Delivered-To: freebsd-current@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 043E9F26424 for ; Sun, 18 Feb 2018 20:08:26 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic308-11.consmr.mail.ne1.yahoo.com (sonic308-11.consmr.mail.ne1.yahoo.com [66.163.187.34]) (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 7A02068737 for ; Sun, 18 Feb 2018 20:08:25 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: VCF2V70VM1m5bNANyuWvqveT_.28d5TVYU_3NdrPK4jcdrx8PpPN05eYtzcqEyb IAud.U9o_p75UbRHY0QhyrqMfyz3KtvXfp94OpqyEi3IbEpn7k1ONgKBjZDK0cj8_vYGCWTeOZHf 12EVMu7FYZ9Bkp9FYKL5ghN1NzXaXhNBJWwW9DSO2XJWweE_BQpU6clUSg60_E.AZ60WFxHdbtL1 IjpdyIbHInjMqcHGp69RlEkIP9JWFLkm14vj9Vwg5CYyO1s6G2EASKeNBwrX9q3L3kP12q18fg1G GMFFAnvCjTdTjZ9TWxyqcbdPIL91ZsCDghI8dLz7dI9ZpXsC25P3hJbaSpkfbLTvLm8GKcYQ_PPG yCvoMpQtxOhFdVMGi4x37EPVBeSIlnW6NCTYRWyzSmXjYc9BQ2mwzaWuKaYNgOx5E.YXy2h1fRv0 A9XpWFvz4Nh33gBiNxcYexeQseEdOjomfzu1Xmc7bpePJbNjHg0zNSiEynY5gcd4jg.ww Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Feb 2018 20:08:24 +0000 Received: from smtp231.mail.ne1.yahoo.com (EHLO [192.168.1.25]) ([10.218.253.210]) by smtp412.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 9cb940f2491913eaffd95b58e217359f; Sun, 18 Feb 2018 19:48:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 11:48:05 -0800 Cc: FreeBSD Current , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <7914AB08-AC79-4D83-BBD7-CE8B78070624@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:08:26 -0000 On 2018-Feb-18, at 10:08 AM, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that = r329418 works fine. I saw that Trond indicated an intent to test -r329418 but I've not seen any reports about -r329418 or how much activity was used to make any judgment about its status. But I can assume -r329418 is good if you want. Bisecting is likely going to be problematical for self-updates: builds and installs and such can crash, making the installs risky. I do not have an alternate builder for amd64 set up. Even without that, it is not clear how many hours of build-related = activity it takes to have a high probability that the problem is gone. (I've seen widely variable amounts of activity between failures in -r329465 .) It = is obvious to try an earlier version after failure but not obvious when to try a later version. My FreeBSD time is also rather limited (compared to historically over = the last few years), so the activity could be spread over parts of various weekends, depending on how it goes. >> On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: >>=20 >> On 2018-Feb-17, at 6:10 PM, Mark Millard wrote: >>=20 >> > [Some more information added, from /usr/libexec/kgdb use.] >> > >> > On 2018-Feb-17, at 5:39 PM, Mark Millard wrote: >> > >> >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro = machine. >> >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. >> >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen >> >> Threadripper 1950X). No other Hyper-V use. >>=20 >> Trond's report seems to be for a "4 core" Intel i7 context (as seen >> by FreeBSD in virtual box). So Ryzen seems to be non-essential for >> reproduction. >>=20 >> Both of our reports are from some form of using FreeBSD in a virtual >> machine (Hyper-V and VirtualBox). I do not know if that is a required >> type of context or not. >>=20 >> >> This happened during: >> >> >> >> # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils >> >> Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >> >>>>> Checking for old files >> >> >>=20 >> I got another example but during a buildworld: >>=20 >> >>> Deleting stale files in build tree... >> cd /usr/src; MACHINE_ARCH=3Dpowerpc64 MACHINE=3Dpowerpc CPUTYPE=3D = BUILD_TOOLS_META=3D.NOMETA CC=3D"cc -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX=3D"c++ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP=3D"cpp -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" = AS=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/as" = AR=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" = LD=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=3D"" = NM=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/nm = OBJCOPY=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-unknown- >> freebsd12.0/bin/ranlib = STRINGS=3D/usr/local/bin/powerpc64-unknown-freebsd12.0-strings = SIZE=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/o= bj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.power= pc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_a= ltbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/= bin:/usr/sbin:/usr/bin = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp make -f Makefile.inc1 BWPHASE=3Dworldtmp = DESTDIR=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp -DBATCH_DELETE_OLD_FILES delete-old d >> elete-old-libs >/dev/null >>=20 >> load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k >> make: Working in: = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc= .powerpc64 >> packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe >>=20 >>=20 >> (I noticed the long pause and got the ^T in before the panic.) >>=20 >> Yet again it is xargs related fork activity that gets the problem = (from core.txt.1 ): >>=20 >> 561 Thread 100836 (PID=3D69982: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 >> . . . >> * 559 Thread 100811 (PID=3D62304: xargs) doadump = (textdump=3D-2122191464) at pcpu.h:230 >>=20 >> spin lock 0xffffffff81b3cf00 (sched lock 24) held by = 0xfffff806aa6d5000 (tid 100836) too long >> panic: spin lock held too long >> cpuid =3D 24 >> time =3D 1518974055 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f11304d0 >> vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 >> panic() at panic+0x43/frame 0xfffffe00f1130590 >> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f11305a0 >> thread_lock_flags_() at thread_lock_flags_+0xdb/frame = 0xfffffe00f1130610 >> statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 >> handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 >> timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 >> lapic_handle_timer() at lapic_handle_timer+0xa7/frame = 0xfffffe00f1130730 >> timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 >> thread_lock_flags_() at thread_lock_flags_+0xc1/frame = 0xfffffe00f1130880 >> fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 >> sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 >> amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 >> fast_syscall_common() at fast_syscall_common+0x101/frame = 0x7fffffffc5a0 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 20:09:09 2018 Return-Path: Delivered-To: freebsd-current@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 019D5F2650E for ; Sun, 18 Feb 2018 20:09:09 +0000 (UTC) (envelope-from wlosh@bsdimp.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 8850F688E8 for ; Sun, 18 Feb 2018 20:09:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4297DF26505; Sun, 18 Feb 2018 20:09:08 +0000 (UTC) Delivered-To: current@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 1E1F7F26504 for ; Sun, 18 Feb 2018 20:09:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 A4430688E5 for ; Sun, 18 Feb 2018 20:09:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id t126so9250973iof.4 for ; Sun, 18 Feb 2018 12:09:07 -0800 (PST) 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=4r3jrGIWSWtrXnrh4tgNmsBHJaRAPx7/JQbNLvsBV20=; b=bVMC3lHFP/U9BH5hV1PuvvVTELVEAFnk5EkRwDIiWqmM6MPqguiDYLGnQMY9SSh92d fKfRrU3XbXn72QxHY5EKC6iPJc6KNh59jXCXEe9arnGVBLqulRQQdgGgIzRIlhwXZdUw X9ENN/mlRDman0cA4GGR9L6aa2sUsMCxYzqSW+7D75Xp6K9d1UtlsQ15C6aBb9I6eRIC ImVGVS93vDjtSFGu5o0nE0eMMANKbjT2I5RVEYxisD6/1eSzMo4vRrNcr/RpFMXV61u5 JfrePPA0pVr1+OFyHUY5pGZNAfbLRZ5Mary0fT5cBTLAFz3jjM9/jbaLwnjp1PRztvGX 4fDg== 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=4r3jrGIWSWtrXnrh4tgNmsBHJaRAPx7/JQbNLvsBV20=; b=Rtkvmnonh4TY7FgFhEYJLEF+1dD45hO+M/VQpcSru/yv+IZLCp8iLzd0JpjQzlRzGe UaNddVjykPTHq9HlkemTB3fqkUbVb/8pW3phY/6Nq6gDdLXrNzMbqB+BIhgWvfVEc3sz jDBCNVHnez8xK9lEBhYc9pk6SucF4lcnt/3oWCfeCY2BEomxehyxKbEheQl3xMAh0lOg hm/RoZ19v4xdIAe5NMbGLcQzz09wndMZbf88j2ikFMP1Ueq8hUFoASs5uJmv3uOjqeGT lYLXrXOOsftkDIyOfdNC9EGNauPaGsfWMOM2Yj6VX4e4BNSUpbQYWQ+sKGM2Tk7jYovq 5kPw== X-Gm-Message-State: APf1xPCe1PNfDacjhDsiZZ6G3X3u38NedlSR5k9Vd0e6eNYpGMu/N2G0 KNaYRoee6O3vP14GR6LrqlymwHhb0016aRHbKf4inw== X-Google-Smtp-Source: AH8x224FMbGoQxlcHehJwvzHQoh+jGEauKBmEuco3pDFTgN3MyzhwcOrlcDeNTvJrVjFfmIsNLf76Llboj+l+uu+Nww= X-Received: by 10.107.142.13 with SMTP id q13mr17076793iod.299.1518984546900; Sun, 18 Feb 2018 12:09:06 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 18 Feb 2018 12:09:06 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Warner Losh Date: Sun, 18 Feb 2018 13:09:06 -0700 X-Google-Sender-Auth: qh5z4WppnpR5odNhVZF_tgdFJsA Message-ID: Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH Cc: FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:09:09 -0000 On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH < ian.freislich@capeaugusta.com> wrote: > On 02/17/18 22:48, Warner Losh wrote: > > On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > wrote: > > Hi > > Since devmatch some of my USB devices no longer get their drivers > loaded. It's not clear from UPDATING whether I needed to do anything > beyond building and installing kernel and world as well as updating > /etc. There was reference to removing /etc/devd/usb.conf in another > thread but its presence or lack thereof makes no difference. > > > I assume you've fully updated including /etc. > > > In as much as 'mergemaster -Ui' fully updates /etc > > If you can uncomment the devd lines in syslog.conf, touch > /var/log/devd.log and reboot. Once you are up again, please send me > /var/log/devd.conf. > > > Assuming you mean these lines: > > !devd > *.>=notice /var/log/devd.log > > devd produced zero logs on reboot and restart. > There should be a lot of output... one line per device that's attached... Did you create /var/log/devd.log before reboot? Is your /dev/log persistent across boots? Warner > Ian > > > From owner-freebsd-current@freebsd.org Sun Feb 18 20:15:30 2018 Return-Path: Delivered-To: freebsd-current@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 6A7A8F26E22 for ; Sun, 18 Feb 2018 20:15:30 +0000 (UTC) (envelope-from agapon@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 010A66907B for ; Sun, 18 Feb 2018 20:15:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B141AF26E1F; Sun, 18 Feb 2018 20:15:29 +0000 (UTC) Delivered-To: current@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 9EBF6F26E1E for ; Sun, 18 Feb 2018 20:15:29 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (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 13D2569076; Sun, 18 Feb 2018 20:15:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f54.google.com with SMTP id x196so10395873lfd.12; Sun, 18 Feb 2018 12:15:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kqOzPpO/uUcMWgeWZc8aZMTDfT+bO29eVemhVrldIt8=; b=Z2b5paTMfHeukcR5iLZkFfN4tDiyXQpAC16LEgcXIFoEIAErkVKjVGiNwJGO6CiF4G zoXZ/sRLUO/Jspu+isnYHlCZ9wTZqGvzDcD7cWPIGPiPc66hpfwftn2+w3VZrTLy2uT+ sV+uiuZt3jE8vUxQwbRryyjkCqWzgm5Srzbtcb9JY13AqNnNW6eBgLs6qIXS7LX7JZd2 X4RCYD8TJiRqr5xzKzd3mIds9MNtEMd9PU1WPHHhaj9rYQN9hV9xjbzZ5LTFEBkv/mTg DIujOHm3ra7I58mEcd3hgpE0YNQU8VHM6HK84rtXWab7B97pmi9yfbhmzkq0oer8J1jK JYYA== X-Gm-Message-State: APf1xPByKlvBdw/do/d4yjBwOLysGwzgvzsAS7Z5Mob+SR6aRA3w72ex Gr/gV7cLaeCIU4csjjxQm6MY8AIm X-Google-Smtp-Source: AH8x225V3O9Hkd83eXOjqb2Bt4bXIiiTzZ7Lzg+kbVQFzwVTDWcGk8O/0hNusFco1oBKCx9Fk8H/Mg== X-Received: by 10.25.149.143 with SMTP id x137mr8611598lfd.119.1518984927115; Sun, 18 Feb 2018 12:15:27 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id e27sm3630243lff.89.2018.02.18.12.15.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 12:15:25 -0800 (PST) Subject: Re: Since last week (today) current on my Ryzen box is unstable To: Gleb Smirnoff Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> <20180218132623.GF93303@FreeBSD.org> From: Andriy Gapon Message-ID: <359681a7-3885-820e-1ac8-19254c83d1ad@FreeBSD.org> Date: Sun, 18 Feb 2018 22:15:24 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218132623.GF93303@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:15:30 -0000 On 18/02/2018 15:26, Gleb Smirnoff wrote: > My only point is that it is a performance improvement. IMHO that's enough :) I don't think that passing an invalid argument to a documented KPI is "enough" for any optimization. > If you can't suggest a more elegant way of doing that improvement, then all > I can suggest is to document it and add its support to ZFS. In return I can only suggest that (1) you run your suggestion by arch@ -- unless that's already been done and you can point me to the discussion, (2) document it and (3) double-check that all implementations confirm to it. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Feb 18 20:29:52 2018 Return-Path: Delivered-To: freebsd-current@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 D9646F00EBD for ; Sun, 18 Feb 2018 20:29:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63B22698AF for ; Sun, 18 Feb 2018 20:29:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id nVaeeNlsDppe1nVageuQ3t; Sun, 18 Feb 2018 13:29:44 -0700 X-Authority-Analysis: v=2.3 cv=Bo6zP7f5 c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=Op4juWPpsa0A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=adqX0pXGAAAA:8 a=VLHWHO-1t6Exyxq0FqQA:9 a=O3CA5ulgLJEZO-pc:21 a=0J1huZKPBesmqoGi:21 a=CjuIK1q_8ugA:10 a=VIklHh9CzJLcClmVAbYA:9 a=LCDJtpOLxl-DTVdK:21 a=Ln2ZeSrFJR8Sh8Y2:21 a=AkvTBx0Z0YGVrdNs:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=0l7XRIR7vdP6TgInZwrD:22 Received: from [192.168.1.101] (S0106002401cb186f.gv.shawcable.net [96.50.22.10]) by spqr.komquats.com (Postfix) with ESMTPSA id 9DEF11DF5; Sun, 18 Feb 2018 12:29:40 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: How to find CPU microcode version ? Date: Sun, 18 Feb 2018 12:29:47 -0800 To: Kurt Jaeger , Andrea Venturoli CC: "freebsd-current@freebsd.org" Message-Id: <20180218202940.9DEF11DF5@spqr.komquats.com> X-CMAE-Envelope: MS4wfA8yPpxqlmmlRjgHiDFnaB998IUw5DnW9uwyIQiFvwlUgoEKDw5BTkNGutT5MRxZUdf+huOiA9NEyNoVaelE5yamOIR7PhuJ4LvoNjcCr/2w2M5C/vhX Mi5CypiIwlDfq+7u3sDXeR5KICjMFf8pl5mPYDrs1NgvDWRZl/9s0F+2hH9IBC6OVaqNL7sOCv560gEfRDYgRVj0Ca3wPs00Q7HwkqEyw83NVImSuEaX39on Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:29:52 -0000 Yes. Intel and AMD docs describe this. CPU reset clears any microcode updat= e. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Kurt Jaeger Sent: 18/02/2018 10:50 To: Andrea Venturoli Cc: freebsd-current@freebsd.org Subject: Re: How to find CPU microcode version ? Hi! > On 02/18/18 11:41, Kurt Jaeger wrote: >=20 > > Reboot of the box and waiting a few hours and the problem re-occured. >=20 > Doesn't the work of microcode_update vanish after a reboot? Thanks. I was not sure and tested this. Indeed, yes, the microcode update i= s reverted by rebooting. Then I have some other issue, because my problems were ongoing after reboots. > Unless of course you set up rc.conf to repeat it at every start... --=20 pi@opsec.eu +49 171 3101372 2 years to g= o ! _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Feb 18 20:34:17 2018 Return-Path: Delivered-To: freebsd-current@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 66B73F016E8 for ; Sun, 18 Feb 2018 20:34:17 +0000 (UTC) (envelope-from glebius@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 07A9D69EAD for ; Sun, 18 Feb 2018 20:34:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id BB37EF016E7; Sun, 18 Feb 2018 20:34:16 +0000 (UTC) Delivered-To: current@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 A5A74F016E6 for ; Sun, 18 Feb 2018 20:34:16 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EEE869EA8; Sun, 18 Feb 2018 20:34:15 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id w1IKXwgm006759 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 12:33:58 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id w1IKXwld006758; Sun, 18 Feb 2018 12:33:58 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 18 Feb 2018 12:33:58 -0800 From: Gleb Smirnoff To: Andriy Gapon Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org Subject: Re: Since last week (today) current on my Ryzen box is unstable Message-ID: <20180218203358.GG93303@FreeBSD.org> References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> <20180218132623.GF93303@FreeBSD.org> <359681a7-3885-820e-1ac8-19254c83d1ad@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <359681a7-3885-820e-1ac8-19254c83d1ad@FreeBSD.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:34:17 -0000 On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: A> On 18/02/2018 15:26, Gleb Smirnoff wrote: A> > My only point is that it is a performance improvement. IMHO that's enough :) A> A> I don't think that passing an invalid argument to a documented KPI is "enough" A> for any optimization. I don't see a sense in making this KPI so sacred. This is something used internally in kernel, and not used outside. The KPI has changed several times in the past. A> > If you can't suggest a more elegant way of doing that improvement, then all A> > I can suggest is to document it and add its support to ZFS. A> A> In return I can only suggest that (1) you run your suggestion by arch@ -- unless A> that's already been done and you can point me to the discussion, (2) document A> it and (3) double-check that all implementations confirm to it. I can provide a patch for ZFS. -- Gleb Smirnoff From owner-freebsd-current@freebsd.org Sun Feb 18 20:39:03 2018 Return-Path: Delivered-To: freebsd-current@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 C82CCF01E56; Sun, 18 Feb 2018 20:39:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F60D6A25E; Sun, 18 Feb 2018 20:39:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IKctK8028855 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 21:38:55 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IKctkA028852; Sun, 18 Feb 2018 21:38:55 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 21:38:55 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:39:04 -0000 On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > Note: -r329448 was reverted in -r329461 : racy. True. I got a crash when compiling r329451 while running r329449. I've now booted the r329422 ZFS BE and I'm attempting to build r329529. -- Trond. From owner-freebsd-current@freebsd.org Sun Feb 18 21:33:28 2018 Return-Path: Delivered-To: freebsd-current@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 9C374F0634B; Sun, 18 Feb 2018 21:33:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 316046CDCD; Sun, 18 Feb 2018 21:33:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id d26so10064539qtk.10; Sun, 18 Feb 2018 13:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fl+Rag2s3g1SHTkqSikrKV27NR9wBXoYAC9YZ7einYs=; b=LaBo/jK9gL8dxtuy7Dl85P4Zms7zxynHW+lx5OWx3dp212Fua/P8rlly9D/9G0X/6g 4a3MvRsEzos7Zdu7vv0puhUvQcyqvWuPuzEG/C/k2+zk1r/ffXixw4SiZoXEQJShBiBr qYyZec07T6cLCWx4tReDfKpfB0HpnFZwRPSXR8kKyCCQL4EOTcs1DRC57bGMTbJbxrk2 WLu+b5nQK4d+cnzqBlgWx4dOdyGbE7+z7RNQt9oncQKz6cjlUcvp//piKQj6zc2NwAkr Gwh0KSKPtJdYrICs0NMcK5P3rpRmcOuMVp55G6Idr9mxaZYyTWpTVEXT1ynTNviabCBc DB4Q== 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=Fl+Rag2s3g1SHTkqSikrKV27NR9wBXoYAC9YZ7einYs=; b=Qy5wTjAqWXXIa+pmJDQQDWQ2DvKTI4BPTRZIY9LH7PfRajLGZnaTpal4FabhCcA5/+ 0jEGBc4uQAE2kVjOlh+Ra6jhK1dc15/Xt0h1IjbO+3UEbmCYe4ZhobLALNbRw+oonXne Cr+79hGXsL7x/OXQeGajsD8wKkKweSMAEtUPaSfGG7NOR13vHczcSLVcl8jMt3UBvICx XEIjLGTGuRsLOehufS92AXCoWWvocUDTN/PNFCDNebnjv5uFhEiiWl9Rb31hRLlbELJf i3yCHmFLyI4ZVMmIhOwcp/SJIOePBKNWjC0SY4pffSZng+QcvPsMdbh0FTpYsCBjdUkV /roA== X-Gm-Message-State: APf1xPBlvQYOS5Gj6VGh5+2JRcu4FD6ylUmZPKg7mg4ygWhnm169kc2t JSp0kS6WK+neuiZrtCXsDjqpPIFWNjtCUlzGsBaxTg== X-Google-Smtp-Source: AH8x225LYUGRZp5MBhVgx4r6dUPNGX6EPaRdW2PqOFjED/Yk4nnxO74oNgKjY5nMKoAsZgVn2a2G2cxphMKaWz1Ftlw= X-Received: by 10.200.38.188 with SMTP id 57mr7516794qto.220.1518989607871; Sun, 18 Feb 2018 13:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 13:33:27 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 22:33:27 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:33:28 -0000 On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > Note: -r329448 was reverted in -r329461 : racy. > > True. I got a crash when compiling r329451 while running r329449. > I've now booted the r329422 ZFS BE and I'm attempting to build > r329529. > Looking around strongly suggests r329448 is the culprit. If you can verify 329447 works fine we are mostly done here. Note the revision got reverted and different variant got in in r329531. That said, if r329447 works then the issue should be already fixed and in particular fresh head should work fine. --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Sun Feb 18 21:50:19 2018 Return-Path: Delivered-To: freebsd-current@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 A87C3F079CD for ; Sun, 18 Feb 2018 21:50:19 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 E4E6B6D7CD for ; Sun, 18 Feb 2018 21:50:18 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: g5wpv9YVM1nU3Vz3DKsJEL6Q2sWuv8hXQpTKHWGLF35CrM5wSlsndSxpmi1XN1g 7tzTr9FWILKNJEDqtYhEr6DubmNk69bx21YEHbxEd8T1sz346uUAmlVGZljHOYVOKgIiatr2paZU dYc4duWszmVpzxjGL__2JcqT0ojVWFo8hnyaoyCNJcz4j6VYLdi8RUAkJD7JtJ2sWaq_Ox8M8aVZ QJvzkv_nk9cBZ_Brzr3Y8yqVrqAxM_3nS72bq09jMsfZAVAIIxxMwUHqn75zflALFzsmNS6pEQFl tiPE.p_Lzg2GWSGfUU41MzuANC2ChayS0N7PBZPWqNGhA6XmuPFGRsOVy0JCM1r_638vmXTfEkK_ mRnkf6KdW.wTM54NXOgCqY3t_ukpIEcjjB9FKHaPDrP79dgi4AwVO6gqnsAtprNcKvmsa6nKKao2 ZJMN5QVrQTI.GsaYhGU1ActL3xRnfzGsFhX0FwtSjmauoDr6E62Fg7dv6zDmpZBpszL4u Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 21:50:17 +0000 Received: from smtp104.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.214]) by smtp405.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 3be2782e0ba0a0d55693c0e3a45b5691; Sun, 18 Feb 2018 21:50:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 13:50:15 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:50:20 -0000 On 2018-Feb-18, at 1:46 PM, Mark Millard = wrote: > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: >=20 >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < >> Trond.Endrestol@fagskolen.gjovik.no> wrote: >>=20 >>> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >>>=20 >>>> Note: -r329448 was reverted in -r329461 : racy. >>>=20 >>> True. I got a crash when compiling r329451 while running r329449. >>> I've now booted the r329422 ZFS BE and I'm attempting to build >>> r329529. >>>=20 >>=20 >> Looking around strongly suggests r329448 is the culprit. If you can = verify >> 329447 works fine we are mostly done here. >>=20 >> Note the revision got reverted and different variant got in in = r329531. >>=20 >> That said, if r329447 works then the issue should be already fixed = and in >> particular fresh head should work fine. >=20 > My initial problem was with -r329465, which is after -r329461 reverted > -r329488 . Trond reported in one note that he had problems with > -r329464 , also after -r329488 was reverted. Trond has also reported > -r329449 failed. Dumb typos above: I meant -r329448 instead of -r329488 both times. > I did manage to revert to -r329447 earlier and so far the results > suggests that it works. >=20 > =46rom this I get that -r329449 is the the one that is common to > all the so--far failing combinations. -r329448 is not common to > all of them. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 21:56:14 2018 Return-Path: Delivered-To: freebsd-current@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 CBCF9F08592 for ; Sun, 18 Feb 2018 21:56:14 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 6760F6E049 for ; Sun, 18 Feb 2018 21:56:14 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ZJnuUqAVM1kwCETSo7fp8SGPq0DVfwTww6TMElF1laG7VZFwTuX2orhVolTUroY SumsBGVM1aoxLF39uzD7VZg6pjNVwGFdPhBqbIt6LZ3finw0qj3UrLAkM8Y91jOj3IT85G1znwKo 2naSM5p9Q4qgLzCUIkiLZbM3QnhJwHF8AupFCtA8DUmJr3giDPt0WTKKYU3FdSaPIlioukUjgmrl KRqgqq2a9q.3OuyN6GzFNY9iNVnPKhJiLWFZ2V0aejz6t82p5ByehFPcC_OtgEj4cqYSLtauQWeS 3m9N1N5kyVoKA6SPniqnsgHh5DPc282fcfXF55MmgwQAqHdCWftq.FBSmVG1w4BIM1FVU3fqD81M _hdxLZA7LOVT3HJqWDnzAG3z8xyLNmA9n4v3OES.vTPT4r33ZzIwuyfuDhFEvzielgbIUhtmaLvQ G7EHz54vWciwsP05WAAcUpRZQzDJXIQsfcbGqKcBQ5rghbVXi53z_Z0sjtdZRUjcZOWoQ Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Feb 2018 21:56:13 +0000 Received: from smtpgate102.mail.ne1.yahoo.com (EHLO [192.168.1.25]) ([216.155.193.199]) by smtp406.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 987bc49e0cd8d1c09a4ca76cc5525b18; Sun, 18 Feb 2018 21:46:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 13:46:02 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:56:15 -0000 On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: >=20 >> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >>=20 >>> Note: -r329448 was reverted in -r329461 : racy. >>=20 >> True. I got a crash when compiling r329451 while running r329449. >> I've now booted the r329422 ZFS BE and I'm attempting to build >> r329529. >>=20 >=20 > Looking around strongly suggests r329448 is the culprit. If you can = verify > 329447 works fine we are mostly done here. >=20 > Note the revision got reverted and different variant got in in = r329531. >=20 > That said, if r329447 works then the issue should be already fixed and = in > particular fresh head should work fine. My initial problem was with -r329465, which is after -r329461 reverted -r329488 . Trond reported in one note that he had problems with -r329464 , also after -r329488 was reverted. Trond has also reported -r329449 failed. I did manage to revert to -r329447 earlier and so far the results suggests that it works. =46rom this I get that -r329449 is the the one that is common to all the so--far failing combinations. -r329448 is not common to all of them. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Sun Feb 18 22:24:59 2018 Return-Path: Delivered-To: freebsd-current@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 AF711F0AA54; Sun, 18 Feb 2018 22:24:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28DCB6F5A2; Sun, 18 Feb 2018 22:24:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IMOps9029504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 23:24:51 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IMOpFQ029501; Sun, 18 Feb 2018 23:24:51 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 23:24:51 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:24:59 -0000 On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > True. I got a crash when compiling r329451 while running r329449. > > I've now booted the r329422 ZFS BE and I'm attempting to build > > r329529. > > > > Looking around strongly suggests r329448 is the culprit. If you can verify > 329447 works fine we are mostly done here. I noticed no errors in r329447. When r329529 is built and installed, I'll try to incrementally build and install r329531. > Note the revision got reverted and different variant got in in r329531. > > That said, if r329447 works then the issue should be already fixed and in > particular fresh head should work fine. -- Trond. From owner-freebsd-current@freebsd.org Sun Feb 18 22:25:15 2018 Return-Path: Delivered-To: freebsd-current@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 16F1EF0AAA1; Sun, 18 Feb 2018 22:25:15 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::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 9FE086F5D1; Sun, 18 Feb 2018 22:25:14 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x244.google.com with SMTP id q18so10181839qtl.3; Sun, 18 Feb 2018 14:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Mz4rua7Pa3nzFZ50ABKH/hndRiO+i+rdmf7JPPiPnM=; b=M11eNmfCVxZAktlIlU8FBtpt/4EO+oV4Ra8LKDfqciV1MBvk5sQvRzvyimvhBvzJzT lm5gtu9GVSK12W0/VmDzxrkwPv64uDKLbIicBnyXg0k7+ssMCYyvdJPFxeRJy1BJaib5 9CX8eAZxy+ggQ7YHQG6fLKe5UWbFtMAMt3ylmjWRm1HUXfRjID/sJpMr/afHj1nNDhiP 5yLB+RsCCzxpSMPzFZJasxF5tD5ZJE9eJRTCuH+w2/GRba4M8+ifJDHOWAJt6xK5CvXX zNZTvLXVV3ys0lde0MW+JtCKuck/3rDKWyh90rsFW0AelgsVIZqgOMQTlg785ATL7wmJ 29oQ== 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=5Mz4rua7Pa3nzFZ50ABKH/hndRiO+i+rdmf7JPPiPnM=; b=kZY/GSQHt72lRrlzdp7jZJ2WX2oPujv8/llCX8cAmbQJ3LQ6kfThnCikEo+U0fXcjV 8ByXhsSsobCnTAjvYSC7hd2r6TDRu+ey/C3NiYOgXcz2XelrGYR4krV4n8fVVXQZhjXP NTUn2htQ7xxtMzINFNspvAZ/JcZyLCdtwdCDWtaeiMRJ5R+42dZOFJKzP0G8kbnX2LUU NslEMSef8EXJg9aVOyeP3nCul4XDstKcnr8zZfWHnR5WEqFdjS2Obf/1hvvXBlbfO/gY 0GvAjGWlTjhqZWlqg/cnzqoWXQ+hIks+/970jOATc+diOf/nw0FsND50oyC6nmZxebYb 4deg== X-Gm-Message-State: APf1xPDdtgkQCcHwO+Iug6D/RBe5KZvTyWEIQ9goOFMdbbVIyhE9E8WE 0yW6hyZD4V6qQhKKqZPmPgYoMlEObbczTJFxXp1R0Q== X-Google-Smtp-Source: AH8x225eE+wjAhvjheRNf7o1LatxKVBlohyL7Y7OgqbzI4/6x7zoLT7/utKn3KzHbYvGH0feMdfYxMBbK/H5gQgIhA4= X-Received: by 10.200.48.13 with SMTP id f13mr21554173qte.140.1518992714326; Sun, 18 Feb 2018 14:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 14:25:13 -0800 (PST) In-Reply-To: <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 23:25:13 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mark Millard Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:25:15 -0000 On Sun, Feb 18, 2018 at 10:50 PM, Mark Millard wrote: > > > On 2018-Feb-18, at 1:46 PM, Mark Millard wrote= : > > > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > > > >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > >> Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> > >>> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > >>> > >>>> Note: -r329448 was reverted in -r329461 : racy. > >>> > >>> True. I got a crash when compiling r329451 while running r329449. > >>> I've now booted the r329422 ZFS BE and I'm attempting to build > >>> r329529. > >>> > >> > >> Looking around strongly suggests r329448 is the culprit. If you can > verify > >> 329447 works fine we are mostly done here. > >> > >> Note the revision got reverted and different variant got in in r329531= . > >> > >> That said, if r329447 works then the issue should be already fixed and > in > >> particular fresh head should work fine. > > > > My initial problem was with -r329465, which is after -r329461 reverted > > -r329488 . Trond reported in one note that he had problems with > > -r329464 , also after -r329488 was reverted. Trond has also reported > > -r329449 failed. > > Dumb typos above: I meant -r329448 instead of -r329488 both times. > > Ok, I think I see the bug: exit1 does: PROC_SLOCK(p); p->p_state =3D PRS_ZOMBIE; /* work continues */ pre-patch proc_to_reap does an equivalent of: if (p->p_state =3D=3D PRS_ZOMBIE) { PROC_SLOCK(p); PROC_SUNLOCK(p); .... reap; } It is possible the exiting thread will be caught just after setting the state to PRS_ZOMBIE. With the slock/sunlock cycle we guarantee the reaping thread will wait for it to finish. Without the cycle we can end up reaping the still exiting thread. I'll fix it soon(tm). --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Sun Feb 18 22:50:28 2018 Return-Path: Delivered-To: freebsd-current@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 89561F0CD4D for ; Sun, 18 Feb 2018 22:50:28 +0000 (UTC) (envelope-from agapon@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 1A3FC70928 for ; Sun, 18 Feb 2018 22:50:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C8885F0CD3F; Sun, 18 Feb 2018 22:50:27 +0000 (UTC) Delivered-To: current@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 B65A0F0CD3E for ; Sun, 18 Feb 2018 22:50:27 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.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 3B50270922; Sun, 18 Feb 2018 22:50:27 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f45.google.com with SMTP id 37so10688880lfs.7; Sun, 18 Feb 2018 14:50:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wVcQ9DfQ/hPzjVabkr0UsmwGDQzY6abJ/OK5xa5YWZo=; b=AyijzEuBl8z7DOm/fH37SkTjBmQmaIe5kFLhKlb2N8TNo4CFWH+iA8KPQboT7K1evi JidkzaXJtRm5T6qz01np2ebsSwNoYRxOG3nmJqrbJEY7P3Up/UFhU4PJxpTel+kg3KSN eJh9a7kA3t11VtNpEsXMmNNSZNVE+IgYkPGPhuiolB5yUbhSLWIj8IGebxbELFoWHLaz MZG1JHjjgB8UFo+QHG3U2cPv/TUozhirDKoAUHEUCshYrMzItIy+xW6mL4dr2+/o7dKx OHvycGUVrNrIbyhooBY/jgUyXO/321CJEaFUjZANb520Id65DZOnNL+VcgC37jjFKArd 91Ew== X-Gm-Message-State: APf1xPD+3/d/TDg2F5THe3fclgjqQ/+LhpS+kX4asC49yeamw+KWXvev /dG8SXhCCBOY6dWoh3tNN5Slm8zx X-Google-Smtp-Source: AH8x226WAsZiFrit2qayVRBe7pkcEOi/UPBADyE9eof9QhGpIZDnX0aM66OSX16fcPG11cUSjlByow== X-Received: by 10.25.42.81 with SMTP id f78mr9005971lfl.100.1518994219952; Sun, 18 Feb 2018 14:50:19 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id m74sm29672lfe.85.2018.02.18.14.50.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 14:50:18 -0800 (PST) Subject: Re: Since last week (today) current on my Ryzen box is unstable To: Gleb Smirnoff Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> <20180218132623.GF93303@FreeBSD.org> <359681a7-3885-820e-1ac8-19254c83d1ad@FreeBSD.org> <20180218203358.GG93303@FreeBSD.org> From: Andriy Gapon Message-ID: <23215dca-663f-1f0d-10ce-aaf7cf3c5d68@FreeBSD.org> Date: Mon, 19 Feb 2018 00:50:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218203358.GG93303@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:50:28 -0000 On 18/02/2018 22:33, Gleb Smirnoff wrote: > On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: > A> On 18/02/2018 15:26, Gleb Smirnoff wrote: > A> > My only point is that it is a performance improvement. IMHO that's enough :) > A> > A> I don't think that passing an invalid argument to a documented KPI is "enough" > A> for any optimization. > > I don't see a sense in making this KPI so sacred. This is something used internally > in kernel, and not used outside. The KPI has changed several times in the past. I don't have anything against changing KPI. At the same time think that it should be well-defined at all times. > A> > If you can't suggest a more elegant way of doing that improvement, then all > A> > I can suggest is to document it and add its support to ZFS. > A> > A> In return I can only suggest that (1) you run your suggestion by arch@ -- unless > A> that's already been done and you can point me to the discussion, (2) document > A> it and (3) double-check that all implementations confirm to it. > > I can provide a patch for ZFS. Thank you. But I think that the documentation update will be much more valuable. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Feb 18 22:55:51 2018 Return-Path: Delivered-To: freebsd-current@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 77CBDF0D935; Sun, 18 Feb 2018 22:55:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 DDD5371077; Sun, 18 Feb 2018 22:55:50 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id f4so10222451qtj.6; Sun, 18 Feb 2018 14:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vQg7NjbuN5ZYJR+b9ooxyZLtjDwmcTh+M4TzhqSi7so=; b=mA/YW+gQ2rGHeMCRx9kM5SN3URah/s3MbXkxU0jxyAUdw/wpW3qCg5NWY0w4Bh987X pE1AbqDF3JSgAnn/yb7vhUnOb0BA75OwKz0u2muS0dabW1eCYAcmhQqLcDrU2DB+Npey bXL2+9Dsx9ei7wNeCuqsNvwZ4RtOYZD3IGDqDWSq0LqiU4rtvOMnu8VxBs0Fw4K+S+ZD Ki3jK8eFJb7HUYHz/oL8vE5bsgTdz6/l2TlCMiNr8eat9Xz7XrvhPdNpkCKbIxzr5FoK kdf5Gsafjyf4+HO6ln3LWQW1ZzkN3kN7fvba2jKz/XCpfMZLLG1wZIX+CFGVghr+YaFn k1Vw== 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=vQg7NjbuN5ZYJR+b9ooxyZLtjDwmcTh+M4TzhqSi7so=; b=KqkzHzWPxuZu0GPcx5NWpvhmNVadrp0YIwJaPsZaHYh7aF2VsrtHrttgQYZzxPGg6t cGWvpydApNVevKdr48VHGHQF1IbxI5ytq+HOp12ILQky6Fbaoq0YArYgkbf/8muhhJRW rMBeekITq6xSNxzUdKlyb0ztQDdM4sUQCNNAVcviZYQ1aH7IMM1tPFsBienBmSfU4saI vAxptAjWdZHJV02QSAF6VH5bmO6EIqziCNxk5O2BzADy76ls9R+g33/O3A8qhJaAENBx Lm3Uu6y9pF50ioeclwwA9oE8jHmI7BLnl8nvcZSTu8AznT0ie2+SJ48Dq03h1EUNpSmV Z7Fw== X-Gm-Message-State: APf1xPCQF4WFoOogpfvsunLxN6vfYPeGWTWk8ZjEuKFGY8rnVeLD/5Vk 15bv7RISQA+5UXfHyrntlD1HOV93Eq0XUzcSfossBg== X-Google-Smtp-Source: AH8x225Mk8pw7jWFVhBK93GSVRdM7jZmLihz7CIqNsobdJ348wahS24ChMthWzBgAzKtA2piyWCUVcneqhDZJhVoEwg= X-Received: by 10.237.62.233 with SMTP id o38mr20690864qtf.3.1518994550502; Sun, 18 Feb 2018 14:55:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 14:55:50 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 23:55:50 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:55:51 -0000 On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > > > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > > > True. I got a crash when compiling r329451 while running r329449. > > > I've now booted the r329422 ZFS BE and I'm attempting to build > > > r329529. > > > > > > > Looking around strongly suggests r329448 is the culprit. If you can > verify > > 329447 works fine we are mostly done here. > > I noticed no errors in r329447. When r329529 is built and installed, > I'll try to incrementally build and install r329531. > Can you grab a panicking kernel and apply this: https://people.freebsd.org/~mjg/wait_unlocked.diff there may be debug printfs signifying the problem condition was hit, however the patch should fix the panic --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Sun Feb 18 23:13:00 2018 Return-Path: Delivered-To: freebsd-current@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 9EA98F0EF83 for ; Sun, 18 Feb 2018 23:13:00 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 1B3267201D for ; Sun, 18 Feb 2018 23:13:00 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id D3B2FF0EF81; Sun, 18 Feb 2018 23:12:59 +0000 (UTC) Delivered-To: current@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 8CCBCF0EF7F for ; Sun, 18 Feb 2018 23:12:59 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 2483A72018 for ; Sun, 18 Feb 2018 23:12:59 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yw0-x232.google.com with SMTP id b16so3239971ywh.12 for ; Sun, 18 Feb 2018 15:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LM9bUR0Qo+S2uQHuIM2cFk3s/1RDE7fagcCRcaA+veo=; b=WbllCA6R6KI9dtYfQTu6AmSUeiAGQkBjdiJgpO5bXvwtuWnMlKFsxMGvWP1vmR0tq7 AFWv2FNUv6VhfxZGcr026sxBXoqFW61JTBA/Nfk/eHI9K5JHBYZVP907VVCuO1h4wJo/ rszHTrzhfqUHOXj9+e5S5S06yIztOzY2LRCcnFR9UhCxUrLBdBW5PLUq8ZbyjFjOrHBC c20RoGMwaohqhBRXhiW9iAi3UIgAevCZ6dj3izrYrShoyAmGxYg87FRum3cqTHha3bGs 9ugUqAgxNyvm/F0APSurqXmGF+iUVW0PErKg3rmZwBvHJIA/Qt2t5g/iYaNBSRX2NrIK 23kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LM9bUR0Qo+S2uQHuIM2cFk3s/1RDE7fagcCRcaA+veo=; b=T4PDTnuHGqAmLUmKVB+E844PBbTYKlXe5jP4/nW2tVT2w/4Vas4LhzowRnIyoojcvt 7LqnlOTBxVPuskh1jPgfOtcu/Gfi4V5yYLZ8oM0Ols26dW91iU+dQXS3slMXyp4E62HL Vgscwzvs3xG5xgYboPqmRmAEWn7z70TILHOeSDcyPfQ73Y+UeA0qtf3VJc1zWvMutvBk LYijoXR1GEA0uVuReBkHP0cYAhAcpjaKpCnCH5NoUeisX3MhHagr/Pm5zCSgi7RRLTe8 1fV6zdvkPCNy8RZ2ttcoV7rfYITdz+Rd8T07mLd9HQAuggO8PcybbGNvM1aetf1xFYoF XgkQ== X-Gm-Message-State: APf1xPDL+wzYzJAY8t2iIsjqlrz2hxTg08kO7smfg/C966GdMsCY5zo6 Ad05oVYmJhAk6QZFINAf3FJu8H+pm4Aj3U35l/7Dy2hi4grK5M/TRxs+Xz87mMh5KJyxFlLQCub zm+dPm4D/2Hk= X-Google-Smtp-Source: AH8x225vJfG4JLXCnhlCDshNRiJYDZARAyx5RIJfN2TCfp4QT2SK+3uFGlFaRdwQhXYhEim+GOeuOg== X-Received: by 10.129.181.7 with SMTP id t7mr9540768ywh.228.1518995578051; Sun, 18 Feb 2018 15:12:58 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id q9sm9089526ywl.59.2018.02.18.15.12.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 15:12:57 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices To: Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> From: Ian FREISLICH Message-ID: <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> Date: Sun, 18 Feb 2018 18:12:57 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:13:01 -0000 On 02/18/18 15:09, Warner Losh wrote: > On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH > > > wrote: > > On 02/17/18 22:48, Warner Losh wrote: >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> > > wrote: >> >> Hi >> >> Since devmatch some of my USB devices no longer get their driver= s >> loaded.=C2=A0 It's not clear from UPDATING whether I needed to d= o >> anything >> beyond building and installing kernel and world as well as >> updating >> /etc.=C2=A0 There was reference to removing /etc/devd/usb.conf i= n >> another >> thread but its presence or lack thereof makes no difference. >> >> >> I assume you've fully updated including /etc. > > In as much as 'mergemaster -Ui' fully updates /etc > >> If you can uncomment the devd lines in syslog.conf, touch >> /var/log/devd.log and reboot. Once you are up again, please send >> me /var/log/devd.conf. > > Assuming you mean these lines: > > !devd > *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 /var/log/devd.log > > devd produced zero logs on reboot and restart. > > > There should be a lot of output... one line per device that's > attached...=C2=A0 Did you create /var/log/devd.log before reboot? Is your > /dev/log persistent across boots? Lots of output after I changed the priority from 'notice' to 'debug' in syslogd.conf.=C2=A0 Might want to fix that in src/etc/syslogd.conf. 1. Startup: Feb 18 17:43:44 zen devd: Pushing table Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf Feb 18 17:43:44 zen devd: Parsing files in /etc/devd Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf Feb 18 17:43:44 zen devd: Calling daemon 2. Inserting the USB-C NIC: Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.0' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dugen0.6' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.1' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.2' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.3' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB subsystem=3DDEVIC= E type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 vendor=3D0x0bda product=3D0x815= 3 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"000001" release=3D0x3000 mode= =3Dhost port=3D13 parent=3Dugen0.1' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 vendor=3D= 0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"000001" release=3D0x3000 mode=3Dhost interface=3D0 endpoints=3D3 intclass=3D0xff intsubclass=3D0xff intprotocol=3D0x00' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing notify event Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start ugen0.6' Feb 18 18:05:53 zen devd: Popping table Feb 18 18:05:53 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 port= =3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"000001" release=3D0x3000 mode=3Dhost intclass=3D0xff intsubclass=3D0xff intprotocol= =3D0x00 on uhub0' Feb 18 18:05:53 zen devd: Pushing table Feb 18 18:05:53 zen devd: Processing nomatch event Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vend= or=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"000001" release=3D0x3000 mode=3Dhost intclass=3D0xff intsubclass= =3D0xff intprotocol=3D0x00 on uhub0'' Feb 18 18:05:53 zen devd: Popping table 3. Insert USB-3 drive: Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.0' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dugen0.6' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.1' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.2' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.3' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.6.4' Feb 18 18:09:38 zen devd: Pushing table Feb 18 18:09:38 zen devd: Processing notify event Feb 18 18:09:38 zen devd: Popping table Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB subsystem=3DDEVIC= E type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 vendor=3D0x0bc2 product=3D0xab2= 4 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost port=3D13 parent=3Dugen0.1' Feb 18 18:09:40 zen devd: Pushing table Feb 18 18:09:40 zen devd: Processing notify event Feb 18 18:09:40 zen devd: Popping table Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 vendor=3D= 0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost interface=3D0 endpoints=3D2 intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50' Feb 18 18:09:40 zen devd: Pushing table Feb 18 18:09:40 zen devd: Processing notify event Feb 18 18:09:40 zen devd: Popping table Feb 18 18:09:40 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 port= =3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost intclass=3D0x08 intsubclass=3D0x06 intprotocol= =3D0x50 on uhub0' Feb 18 18:09:40 zen devd: Pushing table Feb 18 18:09:40 zen devd: Processing nomatch event Feb 18 18:09:40 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vend= or=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50 on uhub0'' Feb 18 18:09:40 zen devd: Popping table 4. Inserting the keyboard/mouse: Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.0' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dugen0.5' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.1' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.2' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB subsystem=3DDEVIC= E type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D0x24ae product=3D0x200= 0 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost= port=3D2 parent=3Dugen0.1' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D= 0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0= x1001 mode=3Dhost interface=3D0 endpoints=3D1 intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D= 0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0= x1001 mode=3Dhost interface=3D1 endpoints=3D1 intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing notify event Feb 18 18:11:04 zen devd: Popping table Feb 18 18:11:04 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 port= =3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"" release=3D0x= 1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01 on uhub0' Feb 18 18:11:04 zen devd: Pushing table Feb 18 18:11:04 zen devd: Processing nomatch event Feb 18 18:11:04 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendo= r=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum= =3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol= =3D0x01 on uhub0'' Feb 18 18:11:04 zen devd: Popping table --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 23:17:24 2018 Return-Path: Delivered-To: freebsd-current@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 167BFF0F4B9 for ; Sun, 18 Feb 2018 23:17:24 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 9AE16723DF for ; Sun, 18 Feb 2018 23:17:23 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4A7E5F0F4B8; Sun, 18 Feb 2018 23:17:23 +0000 (UTC) Delivered-To: current@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 25ACBF0F4B6 for ; Sun, 18 Feb 2018 23:17:23 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 A4B40723D2 for ; Sun, 18 Feb 2018 23:17:22 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yb0-x233.google.com with SMTP id p77-v6so799578yba.5 for ; Sun, 18 Feb 2018 15:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=2qOIIi7sQvaFb3ATf8r7I8R2UkXWF25MgD/Jufv/4W8=; b=icMpoXRkMG0ZFmvL9mLZe0OULkkcdysUqJ9UnAMOsv4VsDiDoRE1gHQ+0I84CdGwuZ IjA57y35vJmdx5qgIXw3MXWd5QmZCpHKWuharOz45tMz2Wleh0mZ/xflN2keaZIMmnAM UqvLeYuBYk3bh4IMQLjeYBj/o4hJg7HPyysFFRgBiMZn0YSC3Asw0WHZAFcQ6CeLCamL YH/+lMLmd4WdIrXpOMCrLvi4LLCS6gJJyYxV15rVJF9LRwXmO+NJ9QqZeYUiezqxGXev PiluCN0NrmfMzPGE7Qp+rJb+NgqnAzy4/JjMQ7ZRxSX9iq/FBOAtCX8KkTXK5TCxn80D lQ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2qOIIi7sQvaFb3ATf8r7I8R2UkXWF25MgD/Jufv/4W8=; b=NUR7/xUZFAKLuf8SVbMIrn3j6WZWg9AL0iZIaaIxe8D2yWPDcrCxStA/St0TYSWZCB FtI5oPmkgb0/6Nw8yjJTWRhlGAZnFVvNR0jfkRR5Uwj+A/JrbCrP8BiRBP5jF41DkMdj y1PS41ciaULwKMbePxgPKCU5/yh+PRUTyuQsa6dxWHtF8s37lZ6vQIlAK2YW6Zi46POa QN1d1wPPp7xca7Y5hI1OKrFnKf8EGQj2SW/IjIQTR32OS4Il7LkmdSnDPAcsfBbNZ+rF xAUkI+7iLrBdo3OsYnHaExzPbMSVmpAoE5zE98Lz4f6Jh7HMFqtu9aroGfNle/DC4DSC 1P2w== X-Gm-Message-State: APf1xPDZjboZfjqTsVw0/QDKXc4seOoyXlAbkyifhc2VXEQgrMH1Z/dr GClTiwX5QYzHi07CzXP5q7gBK6qL4F3RNQcXa1/NiPuDfBFQp/cDyL2tCoQnLqmECg9iKmF6pXg 3Y79m9A== X-Google-Smtp-Source: AH8x224O7ooHp+C98wmMRcxneXYijoPl5vyv6MGr6lMQkhDvIQ6ybmYv/Xq72yheHXVbMpuxjuguLA== X-Received: by 10.37.115.11 with SMTP id o11mr9604023ybc.306.1518995841966; Sun, 18 Feb 2018 15:17:21 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id b123sm8792013ywf.84.2018.02.18.15.17.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 15:17:21 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices From: Ian FREISLICH To: Warner Losh Cc: Hans Petter Selasky , FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <514d3c3f-996d-6299-396a-ae161e6f730b@capeaugusta.com> <56798d16-ddc7-6abd-40df-8a8f552140c6@capeaugusta.com> Message-ID: <80b6155f-fd24-950d-8b52-6c935fcbee25@capeaugusta.com> Date: Sun, 18 Feb 2018 18:17:21 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <56798d16-ddc7-6abd-40df-8a8f552140c6@capeaugusta.com> Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:17:24 -0000 On 02/18/18 18:01, Ian FREISLICH wrote: > On 02/18/18 14:59, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH >> > > wrote: >> >> On 02/18/18 02:23, Hans Petter Selasky wrote: >> > On 02/18/18 05:14, Ian FREISLICH wrote: >> >> On 02/17/18 22:48, Warner Losh wrote: >> >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> >>> > >> > >> >> >>> wrote: >> >>> >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 Hi >> >>> >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 Since devmatch some of my USB devices n= o longer get >> their drivers >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 loaded.=C2=A0 It's not clear from UPDAT= ING whether I needed to do >> >>> anything >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 beyond building and installing kernel a= nd world as well as >> >>> updating >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 /etc.=C2=A0 There was reference to remo= ving /etc/devd/usb.conf in >> >>> another >> >>> =C2=A0=C2=A0=C2=A0=C2=A0 thread but its presence or lack thereof= makes no difference. >> >>> >> >>> >> >>> I assume you've fully updated including /etc. >> >> >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >> >> >>> If you can uncomment the devd lines in syslog.conf, touch >> >>> /var/log/devd.log and reboot. Once you are up again, please >> send me >> >>> /var/log/devd.conf. >> >> >> >> Assuming you mean these lines: >> >> >> >> !devd >> >> *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 /var/log/devd.log >> >> >> >> devd produced zero logs on reboot and restart. >> > >> > Can you run: >> > >> > usbconfig show_ifdrv >> > >> > Maybe the wrong driver captured your device? >> >> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST spd=3DS= UPER >> (5.0Gbps) pwr=3DSAVE (0mA) >> ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev >> 3.00/1.00, addr 1> >> ugen0.2: at usbus0, cfg=3D0 md=3DH= OST >> spd=3DHIGH (480Mbps) pwr=3DON (500mA) >> ugen0.3: at usbus0, cfg=3D0 md=3DHOST >> spd=3DFULL (12Mbps) pwr=3DON (100mA) >> ugen0.3.0: ubt0: > 2.00/0.10, addr 2> >> ugen0.4: at usbus0, cfg=3D0 md=3DHOST spd=3DF= ULL >> (12Mbps) pwr=3DON (100mA) >> ugen0.5: at usbus0, cfg=3D0 md=3D= HOST >> spd=3DFULL (12Mbps) pwr=3DON (100mA) >> ugen0.6: at usbus0, cfg=3D0 md=3DHOST spd=3D= SUPER >> (5.0Gbps) pwr=3DON (72mA) >> >> After loading ums and ukbd: >> >> ugen0.5: at usbus0, cfg=3D0 md=3D= HOST >> spd=3DFULL (12Mbps) pwr=3DON (100mA) >> ugen0.5.0: ukbd0: > 1.10/10.01, addr 5> >> ugen0.5.1: ums0: > 1.10/10.01, addr 5> >> >> >> So what happens if you build these drivers into the kernel vs loading >> them? It just works, which is the fix I'm using for now. Ian --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 23:17:56 2018 Return-Path: Delivered-To: freebsd-current@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 88612F0F57D for ; Sun, 18 Feb 2018 23:17:56 +0000 (UTC) (envelope-from wlosh@bsdimp.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 042277244E for ; Sun, 18 Feb 2018 23:17:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id BC5E1F0F57B; Sun, 18 Feb 2018 23:17:55 +0000 (UTC) Delivered-To: current@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 78972F0F57A for ; Sun, 18 Feb 2018 23:17:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 0B8A27244A for ; Sun, 18 Feb 2018 23:17:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id p204so7274719itc.4 for ; Sun, 18 Feb 2018 15:17:55 -0800 (PST) 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=MHC0zu3y3HECoORRQ2v/XXu0HGilXOyUPpVp21cPDJc=; b=daLV6UXH6CJItN0WlW9Bsuz0mt9HNh5MQWenu5e/AzNBuKGz4y/OtRnjq8dj3mkKp8 /mGyG5LeQqdELnKzVidW6BeKF7PnONb+KmSp1sTh9ANIjwg/8pXZHjE69fw8oFYjaQ17 55z0ixX0QDNjF9QyeKEdunzbK6puLSkUG1ktlpKTDZOSO6Ugz1eR4+h95/GqAe93CIcw 6jFtSRnsl0/EblGy6KPV35fCh7sUylBcE6NXuAqYVQ2hrGBH1i8KhHTAr31f4ju9rwAS qAat9XPCiRXeMrf9wfS/SpTV+SIFlgc4RtRqAlTImRemgtmTisnwprOntPymjg/4IzNN Bf7A== 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=MHC0zu3y3HECoORRQ2v/XXu0HGilXOyUPpVp21cPDJc=; b=W8zenqBlimTH78GKWsbpHAGrbS2UWN2o/NlrgDu/Ebr9ZMoDG1cJKk+Ant5u2K5eay SGHllwqDHpKc+d5e/d0UTtaoUGXvrUnBqXzs4SZ9Du2uI97adpG7WgjZzZsqeErSYkhT MfKxrUp2czS6dlwPe35xJCB8i3P76u+0xtuyDoGq1L3aumOAsB4WGj3bsi/mZE9lMicp Pp1mVNeqS8ep6dS2DbzKvnsXSL8T32oFQJSFvkOfKWm8acRbqRHbnURltRJjU+hNFDZF q23oy+/cEOFiYnd4F8xQfnUTE3gUgVKKCQ687wC0VLwj+Me6lF1Ofyayo8H6X0qnH00A IC5Q== X-Gm-Message-State: APf1xPCPn0Blk3E+7XK2yJD4ht2Y3SpydZFqCeW+eQyPNo4YU86mo82J p/nR4w3oQpQ9AFTs2K8TRl5Pr2Ktt2DSN3yamSmSEyFv X-Google-Smtp-Source: AH8x225lInES2zjY/s+KDOoK9jlgHRTiAcnqBhrfiFcLmqhRgvGshquuz/g9bmCnK4ydbkLZzE+gMmmddBOR6XundLw= X-Received: by 10.36.111.4 with SMTP id x4mr9316165itb.51.1518995874079; Sun, 18 Feb 2018 15:17:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 18 Feb 2018 15:17:53 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> From: Warner Losh Date: Sun, 18 Feb 2018 16:17:53 -0700 X-Google-Sender-Auth: 1xKFT6zoxJx5r7qD2g8fY5oX1yo Message-ID: Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH Cc: FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:17:56 -0000 On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH < ian.freislich@capeaugusta.com> wrote: > On 02/18/18 15:09, Warner Losh wrote: > > On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH < > ian.freislich@capeaugusta.com> wrote: > >> On 02/17/18 22:48, Warner Losh wrote: >> >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> wrote: >> >> Hi >> >> Since devmatch some of my USB devices no longer get their drivers >> loaded. It's not clear from UPDATING whether I needed to do anything >> beyond building and installing kernel and world as well as updating >> /etc. There was reference to removing /etc/devd/usb.conf in another >> thread but its presence or lack thereof makes no difference. >> >> >> I assume you've fully updated including /etc. >> >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >> If you can uncomment the devd lines in syslog.conf, touch >> /var/log/devd.log and reboot. Once you are up again, please send me >> /var/log/devd.conf. >> >> >> Assuming you mean these lines: >> >> !devd >> *.>=notice /var/log/devd.log >> >> devd produced zero logs on reboot and restart. >> > > There should be a lot of output... one line per device that's attached... > Did you create /var/log/devd.log before reboot? Is your /dev/log persistent > across boots? > > > Lots of output after I changed the priority from 'notice' to 'debug' in > syslogd.conf. Might want to fix that in src/etc/syslogd.conf. > > 1. Startup: > > Feb 18 17:43:44 zen devd: Pushing table > Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf > Feb 18 17:43:44 zen devd: Parsing files in /etc/devd > Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf > Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf > Feb 18 17:43:44 zen devd: Calling daemon > > > 2. Inserting the USB-C NIC: > > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.0' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=ugen0.6' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.1' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.2' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.3' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE > type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153 > devclass=0x00 devsubclass=0x00 sernum="000001" release=0x3000 mode=host > port=13 parent=ugen0.1' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda > product=0x8153 devclass=0x00 devsubclass=0x00 sernum="000001" > release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff > intsubclass=0xff intprotocol=0x00' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start > ugen0.6' > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13 > devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153 > devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="000001" release=0x3000 > mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on uhub0' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing nomatch event > Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 > hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda > product=0x8153 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="000001" > release=0x3000 mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on > uhub0'' > Feb 18 18:05:53 zen devd: Popping table > > > 3. Insert USB-3 drive: > > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.0' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=ugen0.6' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.1' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.2' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.3' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.6.4' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '!system=USB subsystem=DEVICE > type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bc2 product=0xab24 > devclass=0x00 devsubclass=0x00 sernum="NA7W30KM" release=0x0100 mode=host > port=13 parent=ugen0.1' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing notify event > Feb 18 18:09:40 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bc2 > product=0xab24 devclass=0x00 devsubclass=0x00 sernum="NA7W30KM" > release=0x0100 mode=host interface=0 endpoints=2 intclass=0x08 > intsubclass=0x06 intprotocol=0x50' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing notify event > Feb 18 18:09:40 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '? at bus=0 hubaddr=1 port=13 > devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bc2 product=0xab24 > devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="NA7W30KM" > release=0x0100 mode=host intclass=0x08 intsubclass=0x06 intprotocol=0x50 on > uhub0' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing nomatch event > Feb 18 18:09:40 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 > hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bc2 > product=0xab24 devclass=0x00 devsubclass=0x00 devproto=0x00 > sernum="NA7W30KM" release=0x0100 mode=host intclass=0x08 intsubclass=0x06 > intprotocol=0x50 on uhub0'' > Feb 18 18:09:40 zen devd: Popping table > > > 4. Inserting the keyboard/mouse: > > Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.0' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=ugen0.5' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.1' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.2' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=USB subsystem=DEVICE > type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae product=0x2000 > devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 mode=host port=2 > parent=ugen0.1' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 > mode=host interface=0 endpoints=1 intclass=0x03 intsubclass=0x01 > intprotocol=0x01' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 > mode=host interface=1 endpoints=1 intclass=0x03 intsubclass=0x01 > intprotocol=0x02' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '? at bus=0 hubaddr=1 port=2 > devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae product=0x2000 > devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x1001 > mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on uhub0' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing nomatch event > Feb 18 18:11:04 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 > hubaddr=1 port=2 devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" > release=0x1001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on > uhub0'' > Feb 18 18:11:04 zen devd: Popping table > > That's better... I think you might be hitting the same bug I've been hitting on my system... It looks like we're calling devmatch, but it isn't seeing the modules to load. There's still a mismatch between things in the USB code (likely my fault, I thought I'd fixed them all: either I missed one or broke something). Try running with r329538 (it's just a new devmatch, so all you need to do is install just it). Warner From owner-freebsd-current@freebsd.org Sun Feb 18 23:19:14 2018 Return-Path: Delivered-To: freebsd-current@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 3F7EDF0F728 for ; Sun, 18 Feb 2018 23:19:14 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 C4B54725C9 for ; Sun, 18 Feb 2018 23:19:13 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id 88DD7F0F71C; Sun, 18 Feb 2018 23:19:13 +0000 (UTC) Delivered-To: current@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 5E775F0F71B for ; Sun, 18 Feb 2018 23:19:13 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF6CD725C5 for ; Sun, 18 Feb 2018 23:19:12 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yb0-x232.google.com with SMTP id e3-v6so69257ybk.1 for ; Sun, 18 Feb 2018 15:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Lz1q5NBFAaT57pAE9Z19zkIHm5jipvsj0KRnob/C31o=; b=dpSSie5wixLdRWtNa6cMVkpVtuWrneO8bNAP2+bX+oKHrCUo81gaK9cAdbx/Li9N+N wGktThfFFI+v9HIU3CExSjwU0qsZcHOn+CkzIwc7H8IusldQA17GRTFYka6h6ZZqq86D rfSUR9upR+DGoMS4tRnag+VsCs9b/WTj2g3KGHDrA1dsQxUqAfoiT0I9gyYMWFU2B0Xr KjCIkzFlgK6C2ikMh3qCW0RXRqXzl2Pe+UWvvyUy9fE5ObUZlJMC1B4189itGnD9eL+f 3MR66q9PdXAbdubJbWNRrQ2P+em7ExPBNDoNR0Ou4u5vVrmDb8UqoXgjPL7qoctZxS7A o0vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Lz1q5NBFAaT57pAE9Z19zkIHm5jipvsj0KRnob/C31o=; b=JnlxW20/zLcXZMTh9885bsNoL0Gse0uV8JaNxbPbKQNF2NYZMlFR6X6L7Nrozob937 qL0WmqW9rnEvCIplF1qDtAC1LT0r/LESxwjEvHmqXO2CEWmrWdwp28pyKL4p6u0yaxAF +x0YZS50B2zwe28MVfs7+71CwBRAk//KSBcxlbq/mt8s2H1uHbdsUNGxQx00/jpieZ1J 7+Rl2sxE/me151dBG/XkpL35LV38XWUW5j/E/BQzQh5QYCQeHzX0XODOIumV6cY1lyQd 3aFf0ujoSGmKnO+RErYKCcqxWflb8Npiup5cHrI85ed/Y7K6745HOmx9npTTPmgZVyqn AW7g== X-Gm-Message-State: APf1xPAGJlxJhegdrWzROxeOVcUkIroHJRYgQJDlhlv4dcAT1KsVe3J1 4UK3khMh8aIx4SBc9Ul6LxJ9XTRCCUgnpf4t9tyPipdSRjdIfjUuGGzzIFtToyY//nFpGbRG8vO u5Uqc2w== X-Google-Smtp-Source: AH8x227hElYoBRaM0yJ9t9Ky/PVDRXkBgldAnh2JlEMq2IhC2w2mcdg8c87+KgXdw5H5acUqvSNPlg== X-Received: by 10.37.65.212 with SMTP id o203mr9062497yba.141.1518995952335; Sun, 18 Feb 2018 15:19:12 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id n9sm4223243ywb.61.2018.02.18.15.19.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 15:19:11 -0800 (PST) From: Ian FREISLICH Subject: Re: r329501 devd doesn't find USB devices To: Warner Losh Cc: Hans Petter Selasky , FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <514d3c3f-996d-6299-396a-ae161e6f730b@capeaugusta.com> Message-ID: <8580b120-6a35-5ffb-a98f-0f78dc0b6a9b@capeaugusta.com> Date: Sun, 18 Feb 2018 18:19:11 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:19:14 -0000 On 02/18/18 14:59, Warner Losh wrote: > On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH > > > wrote: > > On 02/18/18 02:23, Hans Petter Selasky wrote: > > On 02/18/18 05:14, Ian FREISLICH wrote: > >> On 02/17/18 22:48, Warner Losh wrote: > >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > >>> > >> > >>> wrote: > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 Hi > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 Since devmatch some of my USB devices no= longer get their > drivers > >>> =C2=A0=C2=A0=C2=A0=C2=A0 loaded.=C2=A0 It's not clear from UPDATI= NG whether I needed to do > >>> anything > >>> =C2=A0=C2=A0=C2=A0=C2=A0 beyond building and installing kernel an= d world as well as > >>> updating > >>> =C2=A0=C2=A0=C2=A0=C2=A0 /etc.=C2=A0 There was reference to remov= ing /etc/devd/usb.conf in > >>> another > >>> =C2=A0=C2=A0=C2=A0=C2=A0 thread but its presence or lack thereof = makes no difference. > >>> > >>> > >>> I assume you've fully updated including /etc. > >> > >> In as much as 'mergemaster -Ui' fully updates /etc > >> > >>> If you can uncomment the devd lines in syslog.conf, touch > >>> /var/log/devd.log and reboot. Once you are up again, please > send me > >>> /var/log/devd.conf. > >> > >> Assuming you mean these lines: > >> > >> !devd > >> *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 /var/log/devd.log > >> > >> devd produced zero logs on reboot and restart. > > > > Can you run: > > > > usbconfig show_ifdrv > > > > Maybe the wrong driver captured your device? > > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST spd=3DSU= PER > (5.0Gbps) pwr=3DSAVE (0mA) > ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, > addr 1> > ugen0.2: at usbus0, cfg=3D0 md=3DHO= ST > spd=3DHIGH (480Mbps) pwr=3DON (500mA) > ugen0.3: at usbus0, cfg=3D0 md=3DHOST > spd=3DFULL (12Mbps) pwr=3DON (100mA) > ugen0.3.0: ubt0: 2.00/0.10, addr 2> > ugen0.4: at usbus0, cfg=3D0 md=3DHOST spd=3DFU= LL > (12Mbps) pwr=3DON (100mA) > ugen0.5: at usbus0, cfg=3D0 md=3DH= OST > spd=3DFULL (12Mbps) pwr=3DON (100mA) > ugen0.6: at usbus0, cfg=3D0 md=3DHOST spd=3DS= UPER > (5.0Gbps) pwr=3DON (72mA) > > After loading ums and ukbd: > > ugen0.5: at usbus0, cfg=3D0 md=3DH= OST > spd=3DFULL (12Mbps) pwr=3DON (100mA) > ugen0.5.0: ukbd0: 1.10/10.01, addr 5> > ugen0.5.1: ums0: 1.10/10.01, addr 5> > > > So what happens if you build these drivers into the kernel vs loading > them? > > Warner=C2=A0 --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 23:45:15 2018 Return-Path: Delivered-To: freebsd-current@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 D2AAAF11572 for ; Sun, 18 Feb 2018 23:45:14 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 26EBC737D9 for ; Sun, 18 Feb 2018 23:45:14 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id DC95FF1156E; Sun, 18 Feb 2018 23:45:13 +0000 (UTC) Delivered-To: current@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 7B5A8F1156C for ; Sun, 18 Feb 2018 23:45:13 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F68A737D3 for ; Sun, 18 Feb 2018 23:45:12 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yb0-x234.google.com with SMTP id g2-v6so2321995ybd.8 for ; Sun, 18 Feb 2018 15:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=kMEeg9fltftOQl6E/mw84LeTuQZpUwnTIbQGr6CkPJc=; b=sC8R+I7VERpnPW5/6burOspFdlks361y9GBBgtf0UcLjTLwhcJGNst1H1sY0S9YtWx 4UztxMhnt0u15cw4WNfu81GKdPE58JKPCKB6eSxDuIkvU1nAalg/FiluD0vUxFAs6C53 oKooaqU8ZfY+oLco/5s66pi69bwBmrqOSut0q8p7JSkHz2d+smYTffpxI0Hkbi0Nchw1 JGvAgo9zqxk+T4fKV5mjfeJrELonMVuUaXZA63G2Bffc4ZiRuhztCcDiVsV091wMlAYx 52oi+quIGTY/IayKhEu5Ea2kiqKmgUHCzBtNRxgItV+9eonlEMU8WYDixRLYdt+RC7lB p6Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=kMEeg9fltftOQl6E/mw84LeTuQZpUwnTIbQGr6CkPJc=; b=Y2YSsKxEo3cADIUlsfyI+nFVJtG63p1UEgT4ZYWxkag5qZbQjq6qw1N9OAi9+BtQgq kyUUtvD4QbNYnqTGBUE4wEZmXFE3MaA56LvUMTLL06dgyBHgde5ux/zBDRKiauMlNQR/ WC9l1zIfzDkN+RgEAEz0bUP2gqhrEL8xTmbelderfDTaKn5ciPok2ElAJlH/e/dUfHBQ vsVPfXVdV4XIuQBg4xS6x22Bnbjxw6NSE+7xsNyzBKPfu1IFyQHuux9pu6JKYwSuSBjC h+w0qGEwuffG348e1dd4zfJM1eZtEhidPr/K+EAXIqKNwmmI/R6N2jVrRc23ksCBpFgj JN1A== X-Gm-Message-State: APf1xPCjTiYAfSvYnr0jBv24rhnTvZT/+7M3YZ44NLyJfvaa7cWiymSV 6ptINxpLWSNkUvFq4Td3JmTHUIlRiF5CG4RtXkHEKpWa1fq72qiVEULAIr1IK3woJ9uCGHEN8iu /k30if3ENueI= X-Google-Smtp-Source: AH8x227rN6r9g1ZxL4iqE+DFpVKzam/RIuD12QnpzsDlvz6gw9pNDAZTqDz8jNomwDfqomP0611pxw== X-Received: by 10.37.45.88 with SMTP id s24mr5897696ybe.164.1518997512042; Sun, 18 Feb 2018 15:45:12 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id l21sm142576ywa.32.2018.02.18.15.45.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 15:45:11 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices To: Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> From: Ian FREISLICH Message-ID: <1fbaea27-a1ef-31f1-309f-1db99f951122@capeaugusta.com> Date: Sun, 18 Feb 2018 18:45:10 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:45:15 -0000 --=20 Ian Freislich (M) +1 404 574 0228 On 02/18/18 18:17, Warner Losh wrote: > > > On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH > > > wrote: > > On 02/18/18 15:09, Warner Losh wrote: >> On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH >> > > wrote: >> >> On 02/17/18 22:48, Warner Losh wrote: >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> >> > wrote: >>> >>> Hi >>> >>> Since devmatch some of my USB devices no longer get >>> their drivers >>> loaded.=C2=A0 It's not clear from UPDATING whether I needed >>> to do anything >>> beyond building and installing kernel and world as well >>> as updating >>> /etc.=C2=A0 There was reference to removing >>> /etc/devd/usb.conf in another >>> thread but its presence or lack thereof makes no difference= . >>> >>> >>> I assume you've fully updated including /etc. >> >> In as much as 'mergemaster -Ui' fully updates /etc >> >>> If you can uncomment the devd lines in syslog.conf, touch >>> /var/log/devd.log and reboot. Once you are up again, please >>> send me /var/log/devd.conf. >> >> Assuming you mean these lines: >> >> !devd >> *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 /var/log/devd.log >> >> devd produced zero logs on reboot and restart. >> >> >> There should be a lot of output... one line per device that's >> attached...=C2=A0 Did you create /var/log/devd.log before reboot? Is >> your /dev/log persistent across boots? > > Lots of output after I changed the priority from 'notice' to > 'debug' in syslogd.conf.=C2=A0 Might want to fix that in > src/etc/syslogd.conf. > > 1. Startup: > > Feb 18 17:43:44 zen devd: Pushing table > Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf > Feb 18 17:43:44 zen devd: Parsing files in /etc/devd > Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf > Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf > Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf > Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf > Feb 18 17:43:44 zen devd: Calling daemon > > > 2. Inserting the USB-C NIC: > > Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.0' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.6' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.1' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.2' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.3' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB > subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 > vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"000001" release=3D0x3000 mode=3Dhost port=3D13 parent=3Duge= n0.1' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 > vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"000001" release=3D0x3000 mode=3Dhost interface=3D0 endpoint= s=3D3 > intclass=3D0xff intsubclass=3D0xff intprotocol=3D0x00' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing notify event > Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd > start ugen0.6' > Feb 18 18:05:53 zen devd: Popping table > Feb 18 18:05:53 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 > port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vendor=3D0x0bda > product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 > sernum=3D"000001" release=3D0x3000 mode=3Dhost intclass=3D0xff > intsubclass=3D0xff intprotocol=3D0x00 on uhub0' > Feb 18 18:05:53 zen devd: Pushing table > Feb 18 18:05:53 zen devd: Processing nomatch event > Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? > at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Duge= n0.6 > vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0x00 > devproto=3D0x00 sernum=3D"000001" release=3D0x3000 mode=3Dhost > intclass=3D0xff intsubclass=3D0xff intprotocol=3D0x00 on uhub0'' > Feb 18 18:05:53 zen devd: Popping table > > > 3. Insert USB-3 drive: > > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.0' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.6' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.1' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.2' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.3' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.4' > Feb 18 18:09:38 zen devd: Pushing table > Feb 18 18:09:38 zen devd: Processing notify event > Feb 18 18:09:38 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB > subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 > vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost port=3D13 parent=3Du= gen0.1' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing notify event > Feb 18 18:09:40 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 > vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost interface=3D0 endpoi= nts=3D2 > intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing notify event > Feb 18 18:09:40 zen devd: Popping table > Feb 18 18:09:40 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 > port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 vendor=3D0x0bc2 > product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 > sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost intclass=3D0x08 > intsubclass=3D0x06 intprotocol=3D0x50 on uhub0' > Feb 18 18:09:40 zen devd: Pushing table > Feb 18 18:09:40 zen devd: Processing nomatch event > Feb 18 18:09:40 zen devd: Executing '/etc/rc.d/devmatch start '? > at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Duge= n0.6 > vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0x00 > devproto=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost > intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50 on uhub0'' > Feb 18 18:09:40 zen devd: Popping table > > > 4. Inserting the keyboard/mouse: > > Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.0' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.5' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.1' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.2' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB > subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost port=3D2 parent=3Dugen0.1' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D0 endpoints=3D1 > intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D1 endpoints=3D1 > intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing notify event > Feb 18 18:11:04 zen devd: Popping table > Feb 18 18:11:04 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 > port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendor=3D0x24ae > product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass= =3D0x01 > intprotocol=3D0x01 on uhub0' > Feb 18 18:11:04 zen devd: Pushing table > Feb 18 18:11:04 zen devd: Processing nomatch event > Feb 18 18:11:04 zen devd: Executing '/etc/rc.d/devmatch start '? > at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen= 0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > devproto=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0= x03 > intsubclass=3D0x01 intprotocol=3D0x01 on uhub0'' > Feb 18 18:11:04 zen devd: Popping table > > > That's better... I think you might be hitting the same bug I've been > hitting on my system... > > It looks like we're calling devmatch, but it isn't seeing the modules > to load. There's still a mismatch between things in the USB code > (likely my fault, I thought I'd fixed them all: either I missed one or > broke something). Try running with=C2=A0r329538 (it's just a new devmatch= , > so all you need to do is install just it). No difference: Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.0' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dugen0.5' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.1' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS subsystem=3DCDE= V type=3DCREATE cdev=3Dusb/0.5.2' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB subsystem=3DDEVIC= E type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D0x24ae product=3D0x200= 0 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost= port=3D2 parent=3Dugen0.1' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D= 0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0= x1001 mode=3Dhost interface=3D0 endpoints=3D1 intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 vendor=3D= 0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 sernum=3D"" release=3D0= x1001 mode=3Dhost interface=3D1 endpoints=3D1 intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing notify event Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 port= =3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"" release=3D0x= 1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01 on uhub0' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing nomatch event Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendo= r=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum= =3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol= =3D0x01 on uhub0'' Feb 18 18:34:33 zen devd: Popping table Feb 18 18:34:33 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 port= =3D2 devaddr=3D5 interface=3D1 ugen=3Dugen0.5 vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum=3D"" release=3D0x= 1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02 on uhub0' Feb 18 18:34:33 zen devd: Pushing table Feb 18 18:34:33 zen devd: Processing nomatch event Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D1 ugen=3Dugen0.5 vendo= r=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 sernum= =3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol= =3D0x02 on uhub0'' Feb 18 18:34:34 zen devd: Popping table FWIW, this laptop's USB works but is quirky in FreeBSD.=C2=A0 It has 2 thunderbolt ports both of which work under Windows.=C2=A0 Only one works under BSD for HDMI out but doesn't work as USB so nothing detects in it except the the power+hdmi+usb dongle that came with it.=C2=A0 The USB-3 por= t works in the dongle though when connected to this port.=C2=A0 USB+HDMI dong= le doesn't work on the first thunderbolt port but USB devices plugged in this port work.=C2=A0 I can charge on both thunderbolt ports. The third type-C port works as expected. Ian --=20 From owner-freebsd-current@freebsd.org Sun Feb 18 23:49:04 2018 Return-Path: Delivered-To: freebsd-current@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 B550DF11925 for ; Sun, 18 Feb 2018 23:49:03 +0000 (UTC) (envelope-from wlosh@bsdimp.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 04F7D73996 for ; Sun, 18 Feb 2018 23:49:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B596CF11923; Sun, 18 Feb 2018 23:49:02 +0000 (UTC) Delivered-To: current@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 42956F11922 for ; Sun, 18 Feb 2018 23:49:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 C5B7673994 for ; Sun, 18 Feb 2018 23:49:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id q4so2577864itc.0 for ; Sun, 18 Feb 2018 15:49:01 -0800 (PST) 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=jVHm3d8T7uBf4oaccKbZOP8//UEVIcUZuZ1XdTlCHKI=; b=mm6tpT4SWiLH6kAA/ov1WrsXANYxVXMu8GDkDXHhEjBLz1+wzTJFfW58it1DNuAULg ZgmyWxO3p7Thtd7tjEk+3vjL1AGWCTRrBrRgmM2OVhS59ONRybE3veOiEV+VggDTX/Wp jZ8P8LWLE43ZPqgNe83JqplCIkYBJWo8oj+ICSUoDFU+qn30JpMHTH/o9AWEf8SlIv9t qa8yk8ljnv0r0Zbhi6UmDKabTIgm2Fdn+XPtWMfa6LoI8Y1/hKR70tpxQzwatNflGB7Y IIw306C8sOEhyp81S+Nh1ge/DOB2eu1xbxlzGC/+iFIxSWBcwl78+ZLy+rfoqSh8PFBq MSFg== 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=jVHm3d8T7uBf4oaccKbZOP8//UEVIcUZuZ1XdTlCHKI=; b=CIZ3cGuWA+9vnweeYcBPFA7GIUr8x8ajMvlLykOOeuNpjqzkS2qY4Yk+ln8jN78eCs YKrWQGRM2Hs8uURVXb7QOhfhJEMZzxeiWMGjanDe1KiHECZJ+LePh73gV9jfnsbtFRrz fKqievQ6H/1b6lXdEzUnvvtAD5+Y1VuYNYvLtIL+ZL8H7i7z+wQ4N2njwIXx31nQxZFD z75O+aGjAu+fx0ZmhJwR75Aq6m1QyZgg3VAm5z6kVzvc1L1NbD7gKYw+pDXr/J6KyLBR YdEPAZamSkowrcdpa9fJIcgU/a/NLRj0Ad7I7amQHYQk4U9n8KsDQfrbYAKxMO5gVsZO VYOw== X-Gm-Message-State: APf1xPDDbt8wHpw7+xn8JQJb6sT+rtMexCO4ce1l+7obqJS4hraaILTL R8zrESQJ3PpxPAHVei8/i0a1dfffsh2stg7FtIrS0g== X-Google-Smtp-Source: AH8x224pnBur8tS9FJI8LNjmmDH4CecJnbvMt3uwJ+LSW5CLvfdw8rqacFhtKugJyFlL+0GednMiWTbKC1UUxlT1yr0= X-Received: by 10.36.111.4 with SMTP id x4mr9387346itb.51.1518997740761; Sun, 18 Feb 2018 15:49:00 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sun, 18 Feb 2018 15:49:00 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <1fbaea27-a1ef-31f1-309f-1db99f951122@capeaugusta.com> References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> <1fbaea27-a1ef-31f1-309f-1db99f951122@capeaugusta.com> From: Warner Losh Date: Sun, 18 Feb 2018 16:49:00 -0700 X-Google-Sender-Auth: 8mzfM3ijqhksRH8RsYqxMbYf8XI Message-ID: Subject: Re: r329501 devd doesn't find USB devices To: Ian FREISLICH Cc: FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:49:04 -0000 On Sun, Feb 18, 2018 at 4:45 PM, Ian FREISLICH < ian.freislich@capeaugusta.com> wrote: > > -- > Ian Freislich > (M) +1 404 574 0228 <(404)%20574-0228> > > On 02/18/18 18:17, Warner Losh wrote: > > > > On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH < > ian.freislich@capeaugusta.com> wrote: > >> On 02/18/18 15:09, Warner Losh wrote: >> >> On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH < >> ian.freislich@capeaugusta.com> wrote: >> >>> On 02/17/18 22:48, Warner Losh wrote: >>> >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> wrote: >>> >>> Hi >>> >>> Since devmatch some of my USB devices no longer get their drivers >>> loaded. It's not clear from UPDATING whether I needed to do anything >>> beyond building and installing kernel and world as well as updating >>> /etc. There was reference to removing /etc/devd/usb.conf in another >>> thread but its presence or lack thereof makes no difference. >>> >>> >>> I assume you've fully updated including /etc. >>> >>> >>> In as much as 'mergemaster -Ui' fully updates /etc >>> >>> If you can uncomment the devd lines in syslog.conf, touch >>> /var/log/devd.log and reboot. Once you are up again, please send me >>> /var/log/devd.conf. >>> >>> >>> Assuming you mean these lines: >>> >>> !devd >>> *.>=notice /var/log/devd.log >>> >>> devd produced zero logs on reboot and restart. >>> >> >> There should be a lot of output... one line per device that's >> attached... Did you create /var/log/devd.log before reboot? Is your >> /dev/log persistent across boots? >> >> >> Lots of output after I changed the priority from 'notice' to 'debug' in >> syslogd.conf. Might want to fix that in src/etc/syslogd.conf. >> >> 1. Startup: >> >> Feb 18 17:43:44 zen devd: Pushing table >> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf >> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf >> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd >> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf >> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf >> Feb 18 17:43:44 zen devd: Calling daemon >> >> >> 2. Inserting the USB-C NIC: >> >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.0' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=ugen0.6' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.1' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.2' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.3' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE >> type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153 >> devclass=0x00 devsubclass=0x00 sernum="000001" release=0x3000 mode=host >> port=13 parent=ugen0.1' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=USB >> subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda >> product=0x8153 devclass=0x00 devsubclass=0x00 sernum="000001" >> release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff >> intsubclass=0xff intprotocol=0x00' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start >> ugen0.6' >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13 >> devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153 >> devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="000001" release=0x3000 >> mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on uhub0' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing nomatch event >> Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 >> hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda >> product=0x8153 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="000001" >> release=0x3000 mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on >> uhub0'' >> Feb 18 18:05:53 zen devd: Popping table >> >> >> 3. Insert USB-3 drive: >> >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.0' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=ugen0.6' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.1' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.2' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.3' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.6.4' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '!system=USB subsystem=DEVICE >> type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bc2 product=0xab24 >> devclass=0x00 devsubclass=0x00 sernum="NA7W30KM" release=0x0100 mode=host >> port=13 parent=ugen0.1' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing notify event >> Feb 18 18:09:40 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '!system=USB >> subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bc2 >> product=0xab24 devclass=0x00 devsubclass=0x00 sernum="NA7W30KM" >> release=0x0100 mode=host interface=0 endpoints=2 intclass=0x08 >> intsubclass=0x06 intprotocol=0x50' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing notify event >> Feb 18 18:09:40 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '? at bus=0 hubaddr=1 port=13 >> devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bc2 product=0xab24 >> devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="NA7W30KM" >> release=0x0100 mode=host intclass=0x08 intsubclass=0x06 intprotocol=0x50 on >> uhub0' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing nomatch event >> Feb 18 18:09:40 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 >> hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bc2 >> product=0xab24 devclass=0x00 devsubclass=0x00 devproto=0x00 >> sernum="NA7W30KM" release=0x0100 mode=host intclass=0x08 intsubclass=0x06 >> intprotocol=0x50 on uhub0'' >> Feb 18 18:09:40 zen devd: Popping table >> >> >> 4. Inserting the keyboard/mouse: >> >> Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.5.0' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=ugen0.5' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.5.1' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=DEVFS subsystem=CDEV >> type=CREATE cdev=usb/0.5.2' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=USB subsystem=DEVICE >> type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae product=0x2000 >> devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 mode=host port=2 >> parent=ugen0.1' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=USB >> subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae >> product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 >> mode=host interface=0 endpoints=1 intclass=0x03 intsubclass=0x01 >> intprotocol=0x01' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=USB >> subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae >> product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 >> mode=host interface=1 endpoints=1 intclass=0x03 intsubclass=0x01 >> intprotocol=0x02' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '? at bus=0 hubaddr=1 port=2 >> devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae product=0x2000 >> devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x1001 >> mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on uhub0' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing nomatch event >> Feb 18 18:11:04 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 >> hubaddr=1 port=2 devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae >> product=0x2000 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" >> release=0x1001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on >> uhub0'' >> Feb 18 18:11:04 zen devd: Popping table >> >> > That's better... I think you might be hitting the same bug I've been > hitting on my system... > > It looks like we're calling devmatch, but it isn't seeing the modules to > load. There's still a mismatch between things in the USB code (likely my > fault, I thought I'd fixed them all: either I missed one or broke > something). Try running with r329538 (it's just a new devmatch, so all you > need to do is install just it). > > > No difference: > > Feb 18 18:34:33 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=ugen0.5' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.1' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=DEVFS subsystem=CDEV > type=CREATE cdev=usb/0.5.2' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=USB subsystem=DEVICE > type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae product=0x2000 > devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 mode=host port=2 > parent=ugen0.1' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 > mode=host interface=0 endpoints=1 intclass=0x03 intsubclass=0x01 > intprotocol=0x01' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=USB > subsystem=INTERFACE type=ATTACH ugen=ugen0.5 cdev=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 sernum="" release=0x1001 > mode=host interface=1 endpoints=1 intclass=0x03 intsubclass=0x01 > intprotocol=0x02' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '? at bus=0 hubaddr=1 port=2 > devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae product=0x2000 > devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x1001 > mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on uhub0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing nomatch event > Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 > hubaddr=1 port=2 devaddr=5 interface=0 ugen=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" > release=0x1001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 on > uhub0'' > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '? at bus=0 hubaddr=1 port=2 > devaddr=5 interface=1 ugen=ugen0.5 vendor=0x24ae product=0x2000 > devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x1001 > mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 on uhub0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing nomatch event > Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0 > hubaddr=1 port=2 devaddr=5 interface=1 ugen=ugen0.5 vendor=0x24ae > product=0x2000 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" > release=0x1001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 on > uhub0'' > Feb 18 18:34:34 zen devd: Popping table > > FWIW, this laptop's USB works but is quirky in FreeBSD. It has 2 > thunderbolt ports both of which work under Windows. Only one works under > BSD for HDMI out but doesn't work as USB so nothing detects in it except > the the power+hdmi+usb dongle that came with it. The USB-3 port works in > the dongle though when connected to this port. USB+HDMI dongle doesn't > work on the first thunderbolt port but USB devices plugged in this port > work. I can charge on both thunderbolt ports. The third type-C port works > as expected. > OK. I'll delve deeper tonight. Can you do a kldstat to see if the right .ko's got loaded? If so that's one problem, if not it's a different problem. Thanks for your patience as I iron out this new feature. Warner From owner-freebsd-current@freebsd.org Sun Feb 18 23:58:09 2018 Return-Path: Delivered-To: freebsd-current@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 5717CF124F6 for ; Sun, 18 Feb 2018 23:58:09 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 9F37873F39 for ; Sun, 18 Feb 2018 23:58:08 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5FB44F124F5; Sun, 18 Feb 2018 23:58:08 +0000 (UTC) Delivered-To: current@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 E6CB3F124F4 for ; Sun, 18 Feb 2018 23:58:07 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.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 7558E73F36 for ; Sun, 18 Feb 2018 23:58:07 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-oi0-x230.google.com with SMTP id a207so4437631oii.10 for ; Sun, 18 Feb 2018 15:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yp5SOBq4p6sSxIo/OipH3G+SHbZptktG7UNkeA4JtTw=; b=FRHqVaLZDuDWfWD4hOZbKd9A6izoKz5THTCBLOmBm804rP8csqwuAAob+q/WwONnM5 Y2k0e3Iw1vZXw38h/7eKjh/K1hp+OBqd5rShTTD6wWjveGMIZmADveqyncIyLoxfGrVG QQDMSYihRpIiZgBKAyer7IM4zG3bb6GdDfV9k+8p5qGhl/DhVvZORS6Z+dYn64BmFahc AHCuuBBPK8KiLn91zddiT4/BhA1JdYcFjXL7P7d9adQljbR7PnvutZyPsAWk6eMf+t3k 0tLF/enbABtKObKcl2+qNXijvTrxkIcsZv2vaTUtpD8MX9u6YTbC5LwLCe5SZ71IHew4 4B8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yp5SOBq4p6sSxIo/OipH3G+SHbZptktG7UNkeA4JtTw=; b=MQNExwtU5zX4GO76DWzaRvcBaBQK1ISqQrjyj/K5pB7stM7pP9/j0Ep1gnoYFHH+cd UYQoOnSmrB142b9nH5p9Su73ZMvxaaq1o/XUzPeK5fkeGrr7LbEgn021P8/oUIsEH3Mr aqnnlAjcA3XVWDT2U7CrHLRfvJaydqYjt7ijNh7Aprk7jDUetoI+Vcr+FToxp2EoQfRN GLoN2XXXkSBQADSdgpkDfvNfXL42HSNZre4V7CI/i0jIEVv90hKXs+lSA2Mt7bBviA2p 7hv4NiJg7fphM9dFI2qeL34lSnAf4kiZDyRmXpLuQ4WMmo2zkEO/BxOOD0GB5ov+t71V hgvQ== X-Gm-Message-State: APf1xPDL7RPorssAkYpWugyOW/eC2mph8Nh453p0MWVzwjfZ5FeAXXLT wl3FUJXp79M8l2+ZnA3l5wP0dBVe8q561RI+u5fBhMR+TMASZlvfcQNWjpBRF9S67UpdYTFghiO CuF1Glw== X-Google-Smtp-Source: AH8x225KmMGtI9+Ys2N7VfBEq8wChwz5b/bjXKLtg2PA3qgdP1HRSCkOIl+YkirmslgiE8SMF9oPKw== X-Received: by 10.202.186.136 with SMTP id k130mr8667361oif.179.1518998286390; Sun, 18 Feb 2018 15:58:06 -0800 (PST) Received: from zen.clue.co.za (c-69-254-3-228.hsd1.ga.comcast.net. [69.254.3.228]) by smtp.gmail.com with ESMTPSA id f97sm1550607otb.56.2018.02.18.15.58.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 15:58:05 -0800 (PST) Subject: Re: r329501 devd doesn't find USB devices To: Warner Losh Cc: FreeBSD Current , Warner Losh References: <2c5d435c-54b1-fbd8-f695-de3dcc6259f1@capeaugusta.com> <0a0f8471-87e4-0048-aebc-a84014a9faee@capeaugusta.com> <1fbaea27-a1ef-31f1-309f-1db99f951122@capeaugusta.com> From: Ian FREISLICH Message-ID: <8212a950-3d10-0ac6-f60a-f5dc8b6f10ae@capeaugusta.com> Date: Sun, 18 Feb 2018 18:58:04 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:58:10 -0000 On 02/18/18 18:49, Warner Losh wrote: > On Sun, Feb 18, 2018 at 4:45 PM, Ian FREISLICH > > > wrote: > > On 02/18/18 18:17, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH >> > > wrote: >> >> On 02/18/18 15:09, Warner Losh wrote: >>> On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH >>> >> > wrote: >>> >>> On 02/17/18 22:48, Warner Losh wrote: >>>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>>> >>> > wrote: >>>> >>>> Hi >>>> >>>> Since devmatch some of my USB devices no longer get >>>> their drivers >>>> loaded.=C2=A0 It's not clear from UPDATING whether I >>>> needed to do anything >>>> beyond building and installing kernel and world as >>>> well as updating >>>> /etc.=C2=A0 There was reference to removing >>>> /etc/devd/usb.conf in another >>>> thread but its presence or lack thereof makes no >>>> difference. >>>> >>>> >>>> I assume you've fully updated including /etc. >>> >>> In as much as 'mergemaster -Ui' fully updates /etc >>> >>>> If you can uncomment the devd lines in syslog.conf, >>>> touch /var/log/devd.log and reboot. Once you are up >>>> again, please send me /var/log/devd.conf. >>> >>> Assuming you mean these lines: >>> >>> !devd >>> *.>=3Dnotice=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> /var/log/devd.log >>> >>> devd produced zero logs on reboot and restart. >>> >>> >>> There should be a lot of output... one line per device >>> that's attached...=C2=A0 Did you create /var/log/devd.log befor= e >>> reboot? Is your /dev/log persistent across boots? >> >> Lots of output after I changed the priority from 'notice' to >> 'debug' in syslogd.conf.=C2=A0 Might want to fix that in >> src/etc/syslogd.conf. >> >> 1. Startup: >> >> Feb 18 17:43:44 zen devd: Pushing table >> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf >> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf >> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf >> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd >> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf >> Feb 18 17:43:44 zen devd: Parsing >> /usr/local/etc/devd/webcamd.co nf >> Feb 18 17:43:44 zen devd: Calling daemon >> >> >> 2. Inserting the USB-C NIC: >> >> Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.0' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.6' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.1' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.2' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.3' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB >> subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 >> vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"000001" release=3D0x3000 mode=3Dhost port=3D13 parent= =3Dugen0.1' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '!system=3DUSB >> subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.= 6 >> vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"000001" release=3D0x3000 mode=3Dhost interface=3D0 >> endpoints=3D3 intclass=3D0xff intsubclass=3D0xff intprotocol=3D0= x00' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing notify event >> Feb 18 18:05:53 zen devd: Executing >> '/usr/local/etc/rc.d/webcamd start ugen0.6' >> Feb 18 18:05:53 zen devd: Popping table >> Feb 18 18:05:53 zen devd: Processing event '? at bus=3D0 >> hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 >> vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 devsubclass=3D0= x00 >> devproto=3D0x00 sernum=3D"000001" release=3D0x3000 mode=3Dhost >> intclass=3D0xff intsubclass=3D0xff intprotocol=3D0x00 on uhub0' >> Feb 18 18:05:53 zen devd: Pushing table >> Feb 18 18:05:53 zen devd: Processing nomatch event >> Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start >> '? at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 >> ugen=3Dugen0.6 vendor=3D0x0bda product=3D0x8153 devclass=3D0x00 >> devsubclass=3D0x00 devproto=3D0x00 sernum=3D"000001" release=3D0= x3000 >> mode=3Dhost intclass=3D0xff intsubclass=3D0xff intprotocol=3D0x0= 0 on >> uhub0'' >> Feb 18 18:05:53 zen devd: Popping table >> >> >> 3. Insert USB-3 drive: >> >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.0' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.6' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.1' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.2' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.3' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:38 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.6.4' >> Feb 18 18:09:38 zen devd: Pushing table >> Feb 18 18:09:38 zen devd: Processing notify event >> Feb 18 18:09:38 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB >> subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.6 >> vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost port=3D13 >> parent=3Dugen0.1' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing notify event >> Feb 18 18:09:40 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '!system=3DUSB >> subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.6 cdev=3Dugen0.= 6 >> vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost interface=3D0 >> endpoints=3D2 intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0= x50' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing notify event >> Feb 18 18:09:40 zen devd: Popping table >> Feb 18 18:09:40 zen devd: Processing event '? at bus=3D0 >> hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 ugen=3Dugen0.6 >> vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 devsubclass=3D0= x00 >> devproto=3D0x00 sernum=3D"NA7W30KM" release=3D0x0100 mode=3Dhost >> intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50 on uhub0' >> Feb 18 18:09:40 zen devd: Pushing table >> Feb 18 18:09:40 zen devd: Processing nomatch event >> Feb 18 18:09:40 zen devd: Executing '/etc/rc.d/devmatch start >> '? at bus=3D0 hubaddr=3D1 port=3D13 devaddr=3D6 interface=3D0 >> ugen=3Dugen0.6 vendor=3D0x0bc2 product=3D0xab24 devclass=3D0x00 >> devsubclass=3D0x00 devproto=3D0x00 sernum=3D"NA7W30KM" >> release=3D0x0100 mode=3Dhost intclass=3D0x08 intsubclass=3D0x06 >> intprotocol=3D0x50 on uhub0'' >> Feb 18 18:09:40 zen devd: Popping table >> >> >> 4. Inserting the keyboard/mouse: >> >> Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.0' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.5' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.1' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DDEVFS >> subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.2' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB >> subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 >> vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"" release=3D0x1001 mode=3Dhost port=3D2 parent=3Dugen0= .1' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB >> subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.= 5 >> vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D0 endpoints= =3D1 >> intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '!system=3DUSB >> subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.= 5 >> vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0= x00 >> sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D1 endpoints= =3D1 >> intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing notify event >> Feb 18 18:11:04 zen devd: Popping table >> Feb 18 18:11:04 zen devd: Processing event '? at bus=3D0 >> hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 >> vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0= x00 >> devproto=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost >> intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01 on uhub0' >> Feb 18 18:11:04 zen devd: Pushing table >> Feb 18 18:11:04 zen devd: Processing nomatch event >> Feb 18 18:11:04 zen devd: Executing '/etc/rc.d/devmatch start >> '? at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 >> ugen=3Dugen0.5 vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 >> devsubclass=3D0x00 devproto=3D0x00 sernum=3D"" release=3D0x1001 >> mode=3Dhost intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x0= 1 on >> uhub0'' >> Feb 18 18:11:04 zen devd: Popping table >> >> >> That's better... I think you might be hitting the same bug I've >> been hitting on my system... >> >> It looks like we're calling devmatch, but it isn't seeing the >> modules to load. There's still a mismatch between things in the >> USB code (likely my fault, I thought I'd fixed them all: either I >> missed one or broke something). Try running with=C2=A0r329538 (it's >> just a new devmatch, so all you need to do is install just it). > > No difference: > > Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.5' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.1' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DDEVFS > subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.5.2' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB > subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost port=3D2 parent=3Dugen0.1' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D0 endpoints=3D1 > intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x01' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '!system=3DUSB > subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.5 cdev=3Dugen0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost interface=3D1 endpoints=3D1 > intclass=3D0x03 intsubclass=3D0x01 intprotocol=3D0x02' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing notify event > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 > port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen0.5 vendor=3D0x24ae > product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass= =3D0x01 > intprotocol=3D0x01 on uhub0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing nomatch event > Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? > at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D0 ugen=3Dugen= 0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > devproto=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0= x03 > intsubclass=3D0x01 intprotocol=3D0x01 on uhub0'' > Feb 18 18:34:33 zen devd: Popping table > Feb 18 18:34:33 zen devd: Processing event '? at bus=3D0 hubaddr=3D1 > port=3D2 devaddr=3D5 interface=3D1 ugen=3Dugen0.5 vendor=3D0x24ae > product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 devproto=3D0x00 > sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0x03 intsubclass= =3D0x01 > intprotocol=3D0x02 on uhub0' > Feb 18 18:34:33 zen devd: Pushing table > Feb 18 18:34:33 zen devd: Processing nomatch event > Feb 18 18:34:33 zen devd: Executing '/etc/rc.d/devmatch start '? > at bus=3D0 hubaddr=3D1 port=3D2 devaddr=3D5 interface=3D1 ugen=3Dugen= 0.5 > vendor=3D0x24ae product=3D0x2000 devclass=3D0x00 devsubclass=3D0x00 > devproto=3D0x00 sernum=3D"" release=3D0x1001 mode=3Dhost intclass=3D0= x03 > intsubclass=3D0x01 intprotocol=3D0x02 on uhub0'' > Feb 18 18:34:34 zen devd: Popping table > > FWIW, this laptop's USB works but is quirky in FreeBSD.=C2=A0 It has = 2 > thunderbolt ports both of which work under Windows.=C2=A0 Only one > works under BSD for HDMI out but doesn't work as USB so nothing > detects in it except the the power+hdmi+usb dongle that came with > it.=C2=A0 The USB-3 port works in the dongle though when connected to > this port.=C2=A0 USB+HDMI dongle doesn't work on the first thunderbol= t > port but USB devices plugged in this port work.=C2=A0 I can charge on > both thunderbolt ports. The third type-C port works as expected. > > > OK. I'll delve deeper tonight. > > Can you do a kldstat to see if the right .ko's got loaded? If so > that's one problem, if not it's a different problem. Thanks for your > patience as I iron out this new feature. No additional modules are loaded.=C2=A0 No worries about the issue - I have= a work around until it's fixed. Ian --=20 From owner-freebsd-current@freebsd.org Mon Feb 19 00:55:59 2018 Return-Path: Delivered-To: freebsd-current@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 77901F16D7D; Mon, 19 Feb 2018 00:55:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 0336E761C9; Mon, 19 Feb 2018 00:55:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id k13so10404958qtg.5; Sun, 18 Feb 2018 16:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSyrJ2J6ToRuxNmwZkFaGDtzFDuX6suKmKvlBwFgcWA=; b=jx/FUIfjdV0a//3e5nXo8yKu4IbPubMX4QJDcMpQpY47CORYlkaKOGI1o+hc8VcUC2 NuxQqm6Il3I2mBvsoB9iXrHvnT4agV8hP3ORrmQHLJzviV0uS0v7x6GEK/uNeziq9xRC 7Q3XWsv5UfrtuWYmNBjBb1nRFjRXQYuNv3P5AG1BmDfwl7SGGRH/Dg6OxMRf5jHM0d8a Ddkc1UY+g1NC/wIE0ItZu1c+tvQnmDQg62YJe4dNepBmSjQTgkdg719LWhRui7rLjMaG c9/DCdF7eOfBbhFP0bBKtmjG3Nmhpfz4NPHu/GC7IRtPzXw5bSfdailPbpWsU90pU5ZR qpug== 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=JSyrJ2J6ToRuxNmwZkFaGDtzFDuX6suKmKvlBwFgcWA=; b=CUcKSlE5hjsIQjus8KNVL1Oidsjg2sCfhI6zZUCcuZgQOzbWMhD4zWIk9inCVtlotu /wHeN3IrDhmXRErgIntqaQduELbFKoVA0duJSUeyMcIatmDAPB41eHjxB2SgTJzUM76R KLm9Z2Lf3tBfmMz6DBf337q4oNw8ak1EuHquMHEJmYoTQvpW1smaIT19sQcjViHez1dE nMPbMy/vFRlAlGPQeZ+Vj+fkNXEa4rzNJ9f0DFE1JTh0hoBOdkgXDoaRHWc3j5l8n2Re kdYJrSvshmB1tLia8ZFdhMpiGtf61ONMQZsVP9S/wRIMTIpY8MNLwU2SXoR15AVTXQSA T4YQ== X-Gm-Message-State: APf1xPA0wqVpp/YXaBmO7pREUIUWzn58gshzuVs7XmFUq783eFeR6Rwy 0lQLAfvfvcT49esFzgzhtGmHQx7FxsmBH3fGyAo= X-Google-Smtp-Source: AH8x226AGQFnLK5feEphsYKNYDne7bCAVPMLfEmCFYUAZBycZTkXhjCfkAu1YjVusGIKs/lyr3H/bZOXYZlKP8QxbRU= X-Received: by 10.200.38.188 with SMTP id 57mr8039817qto.220.1519001758685; Sun, 18 Feb 2018 16:55:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 16:55:58 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Mon, 19 Feb 2018 01:55:58 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 00:55:59 -0000 I committed the fix in https://svnweb.freebsd.org/base?view=3Drevision&revision=3D329542 i.e. should be stable from this point on. On Sun, Feb 18, 2018 at 11:55 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: >> >> > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < >> > Trond.Endrestol@fagskolen.gjovik.no> wrote: >> > >> > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >> > > >> > > > Note: -r329448 was reverted in -r329461 : racy. >> > > >> > > True. I got a crash when compiling r329451 while running r329449. >> > > I've now booted the r329422 ZFS BE and I'm attempting to build >> > > r329529. >> > > >> > >> > Looking around strongly suggests r329448 is the culprit. If you can >> verify >> > 329447 works fine we are mostly done here. >> >> I noticed no errors in r329447. When r329529 is built and installed, >> I'll try to incrementally build and install r329531. >> > > Can you grab a panicking kernel and apply this: > https://people.freebsd.org/~mjg/wait_unlocked.diff > > there may be debug printfs signifying the problem condition was hit, > however the patch should fix the panic > > -- > Mateusz Guzik > --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Mon Feb 19 01:51:22 2018 Return-Path: Delivered-To: freebsd-current@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 89DE8F1ACAB for ; Mon, 19 Feb 2018 01:51:22 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 0F3CD78674 for ; Mon, 19 Feb 2018 01:51:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: EN1hd9AVM1lgCor36_5VFOnk4LlLHYBr8BEikhjHqaNWssvaEUqvfI0810W.wFx f3olePC.kLa4zai7.VEjz7_dHprJR2bBhUB0iNmY.chas9RtVzyNcG3vfixxw1A10vJCqZrFkjPI zqihHZzNswsBpYWt7JRTBDR0WEF0UNrZcf4M01LQ9bpStuQhA67g0OAU_QD_N78HrsddKj5vwU4C lpz_8N33Tdf962uKKTYmyx47gqegpZnYnYWYjJL7aKBozcZIwtK2ePp6U9Ij_7abLF7JRzzsn4nT WaApY03jJGK0IivwSKzUslYoRC0YTd9J9aGgEfIn._qx3_zeWmf_pMEpRHd59qksJVY_aRPZs5hM S53E9n1NanLvPQgaVEKeYRLmDen37WAvigCu3VzY4_iHkZszVCYvQ_vPmQ10AB2Cx6OQ5h65CJbm j5KVdj9pu_77NbCGtHNjl1jsLMH8KhObTk9RCHLg3W0jpoTDmPNjRl9kd9c2fa2bNPE8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Feb 2018 01:51:20 +0000 Received: from smtpgate101.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.214.169.33]) by smtp408.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID a416070d3c41bc4f9f12eb9c7f0f076e; Mon, 19 Feb 2018 01:51:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 17:51:15 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <47049961-C3F5-454A-89A9-E768B2EBF0DF@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 01:51:22 -0000 On 2018-Feb-18, at 4:55 PM, Mateusz Guzik wrote: > I committed the fix in > https://svnweb.freebsd.org/base?view=revision&revision=329542 > > i.e. should be stable from this point on. Thanks! === Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-current@freebsd.org Mon Feb 19 02:43:19 2018 Return-Path: Delivered-To: freebsd-current@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 C70A2F1F0BF for ; Mon, 19 Feb 2018 02:43:19 +0000 (UTC) (envelope-from julian@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 678EA7A968 for ; Mon, 19 Feb 2018 02:43:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2C1AEF1F0BA; Mon, 19 Feb 2018 02:43:19 +0000 (UTC) Delivered-To: current@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 180B1F1F0B9 for ; Mon, 19 Feb 2018 02:43:19 +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 ABD137A963; Mon, 19 Feb 2018 02:43:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1J2ghXt028170 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Feb 2018 18:42:46 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Since last week (today) current on my Ryzen box is unstable To: Gleb Smirnoff , Andriy Gapon Cc: Andrew Reilly , kib@FreeBSD.org, current@FreeBSD.org References: <0CEA9D55-D488-42EC-BBDE-D0B7CE58BAEA@bigpond.net.au> <20180218023545.GE93303@FreeBSD.org> <431f3e00-c66a-8e2e-6c61-a315a6353d1d@FreeBSD.org> <20180218132623.GF93303@FreeBSD.org> <359681a7-3885-820e-1ac8-19254c83d1ad@FreeBSD.org> <20180218203358.GG93303@FreeBSD.org> From: Julian Elischer Message-ID: <5c03d74d-1c81-ec63-a4ae-4243141bf3c9@freebsd.org> Date: Mon, 19 Feb 2018 10:42:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218203358.GG93303@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 02:43:19 -0000 On 19/2/18 4:33 am, Gleb Smirnoff wrote: > On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: > A> On 18/02/2018 15:26, Gleb Smirnoff wrote: > A> > My only point is that it is a performance improvement. IMHO that's enough :) > A> > A> I don't think that passing an invalid argument to a documented KPI is "enough" > A> for any optimization. > > I don't see a sense in making this KPI so sacred. This is something used internally > in kernel, and not used outside. The KPI has changed several times in the past. > > A> > If you can't suggest a more elegant way of doing that improvement, then all > A> > I can suggest is to document it and add its support to ZFS. > A> > A> In return I can only suggest that (1) you run your suggestion by arch@ -- unless > A> that's already been done and you can point me to the discussion, (2) document > A> it and (3) double-check that all implementations confirm to it. > > I can provide a patch for ZFS. > If any module outside of the code that implements it needs to know about it, then it is in the KPI and should be documented in the KPI documentation (e.g. man 9) Since the Filesystems need to know about this, it must be an externally visible feature and therefore needs to be documented. From owner-freebsd-current@freebsd.org Mon Feb 19 06:23:02 2018 Return-Path: Delivered-To: freebsd-current@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 95E12F05B3E for ; Mon, 19 Feb 2018 06:23:02 +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 2A6B682A97 for ; Mon, 19 Feb 2018 06:23:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1J6MuZU028856 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Feb 2018 22:22:59 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: 12.0-CURRENT missing timezones To: Warner Losh , David Boyd Cc: FreeBSD Current References: <1518195361.5829.2.camel@twc.com> <1518197310.5829.4.camel@twc.com> From: Julian Elischer Message-ID: Date: Mon, 19 Feb 2018 14:22:51 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.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-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 06:23:02 -0000 On 10/2/18 2:48 am, Warner Losh wrote: > OK. That makes sense again. > > > I've pushed two changes (r329064 and r329075) which should correct this. thanks.. I was just about to go investigate this as I noticed my build last week had no timezone info. > > Warner > > On Fri, Feb 9, 2018 at 10:28 AM, David Boyd wrote: > >> On Fri, 2018-02-09 at 10:16 -0700, Warner Losh wrote: >> >> >> >> On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh wrote: >> >> >> >> On Fri, Feb 9, 2018 at 9:56 AM, David Boyd wrote: >> >> In the most recent images for 12.0-CURRENT >> >> FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz >> >> FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso >> >> FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img >> >> the /usr/share/zoneinfo directory is sparsely populated with >> directories. The only file present is "zone.tab". >> >> >> I think that may be my fault for changing find -s to find | sort, but I >> think I neglected to add sort to ITOOLS to fix it. Building a test now. >> >> >> I am surprised the 0131 is empty, though.... My change was after that. >> >> Warner >> >> >> Oops. My mistake (cut and paste error). All dates should be 20180208. >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Feb 19 11:17:33 2018 Return-Path: Delivered-To: freebsd-current@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 7CF37F1BE58 for ; Mon, 19 Feb 2018 11:17:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 0FB4D6F1EE; Mon, 19 Feb 2018 11:17:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id u99so4620807uau.8; Mon, 19 Feb 2018 03:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8cPM9BdDqSUrN1SdUbwTU0MwkyJtOqMwzfvMABE0QRQ=; b=M/pAaCGppBv57J4PFpX0xledYYQT1jhNr4vQGQ7vUl7gF9YSdUhuPpJZJxndncMjsb hrk/XvPvXM5XVWnR3ujxRPxJMy7ZdSkqA3mCXuVCSrmLP4Ns7cbjVCEd3TEa2G+y+VjK P2ngOoOcSuBvRgaaTsMVH9lgtfhwUtvVHIOaXMKYKq1xPptXh+NJe62JEYmikTA33e3T FBTvNExCcJNJSS6NVLbhiN2EeXC3yT4iVzVgBlw/3OgS9DDTS48R6L8EG5O8k+PzVlMt XFcWNlfTBeTQQdh31qaqd5kPlXBCBDL/d4YsqXQAG47YD7aA+yQ1xHJo6ZL0SMWD9AoN nM/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:in-reply-to:references:from:date :message-id:subject:to; bh=8cPM9BdDqSUrN1SdUbwTU0MwkyJtOqMwzfvMABE0QRQ=; b=l5H7mlXGt9iPPNCwWZSF4Z8bIHm5qjSNRyi29ofbyDWa35yAtGdz/Y7susGcwWYI9g IRWCoVfeNtIN2k2Utv9NO5kXCwQR0q3ilqGh187KQ8Dm7qPdHn+7rp8LtFv4bOo/o9S3 po8GXkiMXaqAspMFB+Ec2DYJCMJ4459r3Q3XJJejOHtPfDqoFVebFHw0urGC9MMTPs5w UuSSQBNP7VnwRf3SsAbdO04KIY6UiOJn2eJ0aZTTbv693essR4QuwsdhzTiirHgPNxig yo5PLOaLhRWN6bFpWJoTcauDx8qv2/pK21pxnz+5OzkRUjqkyrzmdC+3pBoJy1s8xt4n 3baw== X-Gm-Message-State: APf1xPDRcbSB3lbOW12Ow1vyg5UYB04/RjYA9KuEMY9ZmH1aXTlNyIOb iIKL0v7hMA46aqBV2uPFSA+f0MnWOU2kccMqokd87FyC X-Google-Smtp-Source: AH8x226TnAYacvoNcO3e12w49ODNSc9wjk/sh8QG5L8Kn0xC817fIfiOHIVcpUGtAHqUGeFWD7HmPfnGJFH8aaRWZoE= X-Received: by 10.176.83.88 with SMTP id y24mr841496uay.121.1519039052337; Mon, 19 Feb 2018 03:17:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.4.8 with HTTP; Mon, 19 Feb 2018 03:17:31 -0800 (PST) In-Reply-To: References: From: Ben Woods Date: Mon, 19 Feb 2018 19:17:31 +0800 Message-ID: Subject: Re: Buildworld failing during llvm To: FreeBSD Current , dim@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 11:17:33 -0000 On 18 February 2018 at 09:52, Ben Woods wrote: > Hi everyone, > > My attempts to build FreeBSD 12-current have been failing as of yesterday > with the error below. This problem persists with current at the time of > writing this email (r329497). > > Given llvm was updated to 6.0 around that time, I suspect it is related: > https://svnweb.freebsd.org/base?view=revision&revision=329410 > > > --- clang.full --- > c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm > -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" > -ffunction-sections -fdata-sections -g -O0 -Qunused-arguments > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 > -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions > -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o clang.full cc1_main.o cc1as_main.o driver.o > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw > -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr > -lpthread -legacy > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a: > could not read symbols: Malformed archive > c++: error: linker command failed with exit code 1 (use -v to see > invocation) > *** [clang.full] Error code 1 > > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > I found this issue was caused by having the following line in my /etc/make.conf (which I had there for some ports debugging): DEBUG_FLAGS=-g -O0 I wouldn't have thought this should cause the clang build to fail... Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-current@freebsd.org Mon Feb 19 14:30:05 2018 Return-Path: Delivered-To: freebsd-current@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 ECA1AF03CD0 for ; Mon, 19 Feb 2018 14:30:04 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.20]) (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 8AE2F77C35 for ; Mon, 19 Feb 2018 14:30:04 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2630.sfr.fr (SMTP Server) with ESMTP id 51EBE1C02B099 for ; Mon, 19 Feb 2018 15:21:49 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2630.sfr.fr (SMTP Server) with ESMTPSA for ; Mon, 19 Feb 2018 15:21:49 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Subject: ACPI panic on boot with new Lua loader and other minor issues To: freebsd-current@freebsd.org References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> Message-ID: <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> Date: Mon, 19 Feb 2018 15:21:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> X-sfr-mailing: LEGIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:30:05 -0000 I have done a full build of r329555 to test the new Lua boot loader. Both the new and the old kernels panic after being loaded with: panic: running without device atpic requires a local APIC For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous message: https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html OK show hint.acpi.0.disabled 1 Setting ACPI to On resolves the issue. Also, I can not stop boot2 to try to use the copy of the Forth loader: the keyboard only becomes responsive at the loader stage. There is an error during this stage: Loading /boot/defaults/loader.conf Failed to open config: ’/boot/loader.conf.local’ Moreover, the "boot [kernel]" loader command does not work: OK ls /boot/kernel.old/kernel /boot/kernel.old/kernel OK boot kernel.old Command failed OK boot /boot/kernel.old/kernel Command failed OK boot kernel Command failed On the other hand, just "boot" works. Finally, the double lines drawing a frame around the loader menu do not work with the new loader and are replaced by ? characters in a box. Hope it helps, Juan From owner-freebsd-current@freebsd.org Mon Feb 19 14:34:24 2018 Return-Path: Delivered-To: freebsd-current@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 83554F04269 for ; Mon, 19 Feb 2018 14:34:24 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.20]) (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 252FC7809D for ; Mon, 19 Feb 2018 14:34:24 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2630.sfr.fr (SMTP Server) with ESMTP id 249E11C04F82C for ; Mon, 19 Feb 2018 15:34:23 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2630.sfr.fr (SMTP Server) with ESMTPSA for ; Mon, 19 Feb 2018 15:34:22 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Subject: ACPI panic on boot with new Lua loader and other minor issues To: freebsd-current@freebsd.org References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> Message-ID: <54e6b19c-6b2c-c986-3538-8285ac988ff5@club.fr> Date: Mon, 19 Feb 2018 15:34:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> X-sfr-mailing: LEGIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:34:24 -0000 > Moreover, the "boot [kernel]" loader command does not work: > > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel > Command failed > OK boot kernel > Command failed I forgot that I tried starting with "unload", which seems to work, but does not correct the issue: OK unload OK boot kernel.old Command failed From owner-freebsd-current@freebsd.org Mon Feb 19 14:39:51 2018 Return-Path: Delivered-To: freebsd-current@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 CD68EF048A5 for ; Mon, 19 Feb 2018 14:39:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26ECB78330 for ; Mon, 19 Feb 2018 14:39:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w1JEdf4A019645; Mon, 19 Feb 2018 14:39:41 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w1JEdfst019644; Mon, 19 Feb 2018 06:39:41 -0800 (PST) (envelope-from david) Date: Mon, 19 Feb 2018 06:39:41 -0800 From: David Wolfskill To: Juan =?iso-8859-1?Q?Ram=F3n?= Molina Menor Cc: freebsd-current@freebsd.org Subject: Re: ACPI panic on boot with new Lua loader and other minor issues Message-ID: <20180219143941.GA1212@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Juan =?iso-8859-1?Q?Ram=F3n?= Molina Menor , freebsd-current@freebsd.org References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jIdBwf7/i7YThJrI" Content-Disposition: inline In-Reply-To: <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:39:51 -0000 --jIdBwf7/i7YThJrI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ram=C3=B3n Molina Menor wrot= e: > I have done a full build of r329555 to test the new Lua boot loader. >=20 > Both the new and the old kernels panic after being loaded with: >=20 > panic: running without device atpic requires a local APIC >=20 > For reasons unknown, ACPI is off, as shown by David Wolfskill in a=20 > previous message: > https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.= html That has been fixed (for me, at least). My last two build/smoke-tests were at r329517 and r329561; I believe that r329366 was the fix for ACPI detection/setting. > OK show hint.acpi.0.disabled > 1 >=20 > Setting ACPI to On resolves the issue. >=20 > Also, I can not stop boot2 to try to use the copy of the Forth loader:=20 > the keyboard only becomes responsive at the loader stage. > There is an error during this stage: >=20 > Loading /boot/defaults/loader.conf > Failed to open config: =E2=80=99/boot/loader.conf.local=E2=80=99 IIUC, that's merely an informational message, not an error. (None of my systems have a /boot/loader.conf.local, either.) > Moreover, the "boot [kernel]" loader command does not work: >=20 > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel > Command failed > OK boot kernel > Command failed >=20 > On the other hand, just "boot" works. And the Lua loader permits kernel selection, as well (as the Forth laoder has). > Finally, the double lines drawing a frame around the loader menu do not= =20 > work with the new loader and are replaced by ? characters in a box. That has also been fixed for me (as of r329517). > Hope it helps, > Juan > .... Peace, david --=20 David H. Wolfskill david@catwhisker.org The circus around that memo helps confirm that Mr. Trump is unfit for offic= e. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --jIdBwf7/i7YThJrI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlqK4a1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7hd5Lwf/YutOzTKgqjLHVvSYN0xhNJyP+ZjuekiiCisZ4kfgMCLfY9fx7b7W3LJN jGEj3yhCvEFnzkIy4dW4KT1mMWt4Us9s77t7dwkhImLMUoMNOmQ8jew/Wx8hju8J 8RpXgrIGNdo0Luty6T8hmp/1Xqhw6g0K7HRdq8fyWwGRHN3LvjJbybq4a/tJEcFb qSgOznJfoXdTNqeXWqUuXHSRm/JlDuLV+JcuTSvsw+mVJ3oKC6SHwFM1FFobNSXX sMTPNXqjQPEqWUdz5y8vLazttkSrglRNXgCOBZRR0UUAXEDASpxGef2YaO/cpgje du83GguA3zUpaJxHM1hOyuIfw5HNkg== =3J6K -----END PGP SIGNATURE----- --jIdBwf7/i7YThJrI-- From owner-freebsd-current@freebsd.org Mon Feb 19 16:57:55 2018 Return-Path: Delivered-To: freebsd-current@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 A8C3EF0FDD6 for ; Mon, 19 Feb 2018 16:57:55 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) 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 4DECF7EF97 for ; Mon, 19 Feb 2018 16:57:55 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: by mailman.ysv.freebsd.org (Postfix) id 0A309F0FDD5; Mon, 19 Feb 2018 16:57:55 +0000 (UTC) Delivered-To: current@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 EC082F0FDD4 for ; Mon, 19 Feb 2018 16:57:54 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 3081B7EF93 for ; Mon, 19 Feb 2018 16:57:53 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from 124-169-249-32.dyn.iinet.net.au (HELO leader.local) ([124.169.249.32]) by ipmail06.adl6.internode.on.net with ESMTP; 20 Feb 2018 03:22:43 +1030 Subject: Re: How to find CPU microcode version ? To: Kurt Jaeger , current@freebsd.org References: <20180218104137.GA32429@home.opsec.eu> From: Shane Ambler Message-ID: <057ac894-7362-b235-3859-65108b2afb76@ShaneWare.Biz> Date: Tue, 20 Feb 2018 03:22:41 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180218104137.GA32429@home.opsec.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 16:57:55 -0000 On 18/02/2018 21:11, Kurt Jaeger wrote: > Hi! > Around the 14th, processes started to be killed for out of swapspace, > even if the box had almost no load at all. > > pid 1056 (mutt), uid 104, was killed: out of swap space > pid 536 (devd), uid 0, was killed: out of swap space > pid 15093 (exim), uid 26, was killed: out of swap space > pid 91868 (mutt), uid 104, was killed: out of swap space > pid 1086 (sshd), uid 104, was killed: out of swap space > > Reboot of the box and waiting a few hours and the problem re-occured. > > The box has 32 GB RAM and 34 GB swap, which never was utilized > beyond a few hundred MBs. One situation that can cause out of swap errors is large amounts of wired ram. Wired ram is memory that can't be swapped out. When you get around 80 or 90% of physical ram wired you start seeing those errors. You can see the amount of wired displayed in top or sysctl vm.stats.vm.v_wire_count then times that by hw.pagesize There is a vm.max_wired but it doesn't appear to be an enforced limit. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Mon Feb 19 19:27:52 2018 Return-Path: Delivered-To: freebsd-current@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 6386FF1CC9D for ; Mon, 19 Feb 2018 19:27:52 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 05D9386D09 for ; Mon, 19 Feb 2018 19:27:51 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1enr6G-0002ev-DZ for freebsd-current@freebsd.org; Mon, 19 Feb 2018 20:27:44 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org Date: Mon, 19 Feb 2018 20:27:43 +0100 Subject: pkg does not recognize correct kernel version MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 2ecd0b53b7de9511489f92806276a3d7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:27:52 -0000 I just did this. root@sjakie ~]# pkg upgrade Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 Processing entries: 0% pkg: Newer FreeBSD version for package gnome-menus: - package: 1200058 - running kernel: 1200056 pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64 Processing entries: 100% Unable to update repository FreeBSD Error updating repositories! [root@sjakie ~]# uname -UK 1200058 1200058 [root@sjakie ~]# uname -a FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 12:37:36 CET 2018 ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 So uname gives a different version than pkg detects. What is happening? pkg update -f gives the same result. -o OSVERSION=1200058 helps, but does not feel like the right solution. Regards, Ronald. From owner-freebsd-current@freebsd.org Mon Feb 19 19:55:07 2018 Return-Path: Delivered-To: freebsd-current@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 3ECEBF1F076 for ; Mon, 19 Feb 2018 19:55:07 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 9526768153 for ; Mon, 19 Feb 2018 19:55:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 35980 invoked by uid 89); 19 Feb 2018 19:54:59 -0000 Received: from unknown (HELO ?100.72.81.158?) (mg@grem.de@109.41.192.222) by mail.grem.de with ESMTPA; 19 Feb 2018 19:54:59 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: pkg does not recognize correct kernel version From: Michael Gmelin X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 19 Feb 2018 20:54:57 +0100 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ronald Klop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:55:07 -0000 > On 19. Feb 2018, at 20:27, Ronald Klop wrote: >=20 > I just did this. >=20 > root@sjakie ~]# pkg upgrade > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 > Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 > Processing entries: 0% > pkg: Newer FreeBSD version for package gnome-menus: > - package: 1200058 > - running kernel: 1200056 > pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12= :amd64 > Processing entries: 100% > Unable to update repository FreeBSD > Error updating repositories! >=20 > [root@sjakie ~]# uname -UK > 1200058 1200058 >=20 > [root@sjakie ~]# uname -a > FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 1= 2:37:36 CET 2018 ronald@sjakie:/data/ronald/obj-freebsd-current/data/ron= ald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 >=20 >=20 > So uname gives a different version than pkg detects. >=20 > What is happening? pkg update -f gives the same result. -o OSVERSION=3D120= 0058 helps, but does not feel like the right solution. What is the output of =E2=80=98freebsd-version=E2=80=99? Best, Michael From owner-freebsd-current@freebsd.org Mon Feb 19 20:10:59 2018 Return-Path: Delivered-To: freebsd-current@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 1C796F205A6 for ; Mon, 19 Feb 2018 20:10:59 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) (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 B1C9A68E7A for ; Mon, 19 Feb 2018 20:10:58 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a01.um.gwdg.de ([134.76.11.221] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1enrlx-0007p2-Mx; Mon, 19 Feb 2018 21:10:49 +0100 Received: from UM-EXCHT-S1.um.gwdg.de (134.76.9.213) by um-excht-a01.um.gwdg.de (134.76.9.210) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 19 Feb 2018 21:10:49 +0100 Received: from krabat.raven.hur (91.8.148.12) by email.gwdg.de (134.76.9.213) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 19 Feb 2018 21:10:48 +0100 Subject: Re: pkg does not recognize correct kernel version To: Ronald Klop , References: From: Rainer Hurling Message-ID: Date: Mon, 19 Feb 2018 21:10:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:10:59 -0000 Hi Ronald, Am 19.02.2018 um 20:27 schrieb Ronald Klop: > I just did this. > > root@sjakie ~]# pkg upgrade > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100%    944 B   0.9kB/s    00:01 > Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01 > Processing entries:   0% > pkg: Newer FreeBSD version for package gnome-menus: > - package: 1200058 > - running kernel: 1200056 > pkg: repository FreeBSD contains packages for wrong OS version: > FreeBSD:12:amd64 > Processing entries: 100% > Unable to update repository FreeBSD > Error updating repositories! > > [root@sjakie ~]# uname -UK > 1200058 1200058 > > [root@sjakie ~]# uname -a > FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 > 12:37:36 CET 2018     > ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG  > amd64 > > > So uname gives a different version than pkg detects. > > What is happening? pkg update -f gives the same result. -o > OSVERSION=1200058 helps, but does not feel like the right solution. > > Regards, > Ronald. Please try #sysctl kern.osreldate kern.osreldate: 1200058 HTH, Rainer Hurling From owner-freebsd-current@freebsd.org Mon Feb 19 20:21:35 2018 Return-Path: Delivered-To: freebsd-current@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 25526F2134F for ; Mon, 19 Feb 2018 20:21:35 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (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 9033C697CA; Mon, 19 Feb 2018 20:21:34 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f43.google.com with SMTP id v9so1132659lfa.11; Mon, 19 Feb 2018 12:21:34 -0800 (PST) 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:content-transfer-encoding; bh=CvRtpjeT5C3M0GqdGVvfPuA0n/lLsGZv7HGps93ru3g=; b=hIWh8Y1T12eKJyglHE2+m8TPLfPCH+C0Sl+jbNsSXwpB6pHOfBeLJcMC1F+HwXQERo BepbbZ7PDXZlYsCeJGEDMKoNsO/g69CSik+91C++HHkl0XlwXcMsauGaRT64gIfDXMYn MZyVIzlAb8s1WqNj5JI1AiiI3tRv729+3nOqgQ0R068wUowezYj9pzeZALxf6vxs9vWE xqoQehzO8L5a+jHNBxVK1U1TrIbFIAcY3Cn4eJTJ8ZSZOuBDgk2E/XLMNPMCOPXb+J8q ZOWprFfTEGEhQggAXUq8VFI/sV0YSs/rz9Ari1Rnjt2Xna3lboSAPsE5JULIbNW2kpwN lM3Q== X-Gm-Message-State: APf1xPAPm57pnxGAjRtt5M7ZeBL1l/Bh1LoGIlRq20ZKBSTZPlgPlRXT gecMRfu7WnRVtzYf+WnNYCWaKf34 X-Google-Smtp-Source: AH8x227DeT7RhtuRSpdRj1OR9GD2UdzG1xX5Vew2xgdmAAWbOaBdsysbjU0vF4AoWVswDJAL3t6QOw== X-Received: by 10.46.21.75 with SMTP id 11mr7538424ljv.58.1519071687004; Mon, 19 Feb 2018 12:21:27 -0800 (PST) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com. [209.85.215.47]) by smtp.gmail.com with ESMTPSA id g17sm4461744ljf.22.2018.02.19.12.21.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 12:21:26 -0800 (PST) Received: by mail-lf0-f47.google.com with SMTP id t204so1136143lff.9; Mon, 19 Feb 2018 12:21:26 -0800 (PST) X-Received: by 10.46.4.74 with SMTP id 71mr633652lje.51.1519071686497; Mon, 19 Feb 2018 12:21:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 12:21:05 -0800 (PST) In-Reply-To: <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Mon, 19 Feb 2018 14:21:05 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Cc: freebsd-current@freebsd.org, dteske@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:21:35 -0000 Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor wrote: > I have done a full build of r329555 to test the new Lua boot loader. > > Both the new and the old kernels panic after being loaded with: > > panic: running without device atpic requires a local APIC > > For reasons unknown, ACPI is off, as shown by David Wolfskill in a previo= us > message: > https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.= html > > OK show hint.acpi.0.disabled > 1 > > Setting ACPI to On resolves the issue. As David noted, this should actually Just Work (TM) now. Can you break into a loader prompt with just the forth loader and tell me what "show hint.acpi.0.rsdp" looks like? > Also, I can not stop boot2 to try to use the copy of the Forth loader: th= e > keyboard only becomes responsive at the loader stage. Hmm... > There is an error during this stage: > > Loading /boot/defaults/loader.conf > Failed to open config: =E2=80=99/boot/loader.conf.local=E2=80=99 David's diagnosis of this is right- this is more of an informational message that you don't need to worry about. > Moreover, the "boot [kernel]" loader command does not work: > > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel > Command failed > OK boot kernel > Command failed > > On the other hand, just "boot" works. It seems that the Forth loader might be doing something sneaky and replacing the standard common "boot" with a Forth boot that handles this a lot better. CC'ing dteske@ so they can confirm. > Finally, the double lines drawing a frame around the loader menu do not w= ork > with the new loader and are replaced by ? characters in a box. Interesting, I'll look into that... anything interesting/unique about your setup? r329387 should have addressed one potential cause of this, but I see you're past that. From owner-freebsd-current@freebsd.org Mon Feb 19 20:24:14 2018 Return-Path: Delivered-To: freebsd-current@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 CFA96F21629 for ; Mon, 19 Feb 2018 20:24:14 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 6D66769A28 for ; Mon, 19 Feb 2018 20:24:14 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1enryu-0007SW-6b; Mon, 19 Feb 2018 21:24:12 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org, "Rainer Hurling" Subject: Re: pkg does not recognize correct kernel version References: Date: Mon, 19 Feb 2018 21:24:11 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 4c3c8b3d32e7d0cfaf2d58264fc1daa3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:24:15 -0000 On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling wrote: > Hi Ronald, > > Am 19.02.2018 um 20:27 schrieb Ronald Klop: >> I just did this. >> >> root@sjakie ~]# pkg upgrade >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 >> Processing entries: 0% >> pkg: Newer FreeBSD version for package gnome-menus: >> - package: 1200058 >> - running kernel: 1200056 >> pkg: repository FreeBSD contains packages for wrong OS version: >> FreeBSD:12:amd64 >> Processing entries: 100% >> Unable to update repository FreeBSD >> Error updating repositories! >> >> [root@sjakie ~]# uname -UK >> 1200058 1200058 >> >> [root@sjakie ~]# uname -a >> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 >> 12:37:36 CET 2018 >> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG >> amd64 >> >> >> So uname gives a different version than pkg detects. >> >> What is happening? pkg update -f gives the same result. -o >> OSVERSION=1200058 helps, but does not feel like the right solution. >> >> Regards, >> Ronald. > > Please try > > #sysctl kern.osreldate > kern.osreldate: 1200058 > > HTH, > Rainer Hurling [root@sjakie ~]# sysctl kern.osreldate kern.osreldate: 1200058 Regards, Ronald. From owner-freebsd-current@freebsd.org Mon Feb 19 20:25:25 2018 Return-Path: Delivered-To: freebsd-current@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 8998BF21745 for ; Mon, 19 Feb 2018 20:25:25 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 2767969A98 for ; Mon, 19 Feb 2018 20:25:24 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ens03-0007hQ-KL; Mon, 19 Feb 2018 21:25:23 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Michael Gmelin" Cc: freebsd-current@freebsd.org Subject: Re: pkg does not recognize correct kernel version References: Date: Mon, 19 Feb 2018 21:25:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 353bb18b0f14186cd389c275975c39f5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:25:25 -0000 On Mon, 19 Feb 2018 20:54:57 +0100, Michael Gmelin wro= te: > >> On 19. Feb 2018, at 20:27, Ronald Klop wrote: >> >> I just did this. >> >> root@sjakie ~]# pkg upgrade >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 >> Processing entries: 0% >> pkg: Newer FreeBSD version for package gnome-menus: >> - package: 1200058 >> - running kernel: 1200056 >> pkg: repository FreeBSD contains packages for wrong OS version: = >> FreeBSD:12:amd64 >> Processing entries: 100% >> Unable to update repository FreeBSD >> Error updating repositories! >> >> [root@sjakie ~]# uname -UK >> 1200058 1200058 >> >> [root@sjakie ~]# uname -a >> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb= = >> 18 12:37:36 CET 2018 = >> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-cu= rrent/amd64.amd64/sys/GENERIC-NODEBUG = >> amd64 >> >> >> So uname gives a different version than pkg detects. >> >> What is happening? pkg update -f gives the same result. -o = >> OSVERSION=3D1200058 helps, but does not feel like the right solution.= > > What is the output of =E2=80=98freebsd-version=E2=80=99? > > Best, > Michael > > [root@sjakie ~]# freebsd-version 12.0-CURRENT Regards, Ronald. From owner-freebsd-current@freebsd.org Mon Feb 19 20:39:41 2018 Return-Path: Delivered-To: freebsd-current@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 70B3DF22A55 for ; Mon, 19 Feb 2018 20:39:41 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) (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 0A6166A65E for ; Mon, 19 Feb 2018 20:39:40 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [134.76.11.226] (helo=email.stud.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1ensDr-0003Vz-3c; Mon, 19 Feb 2018 21:39:39 +0100 Received: from UM-EXCHT-A01.um.gwdg.de (134.76.9.210) by um-excht-s2.um.gwdg.de (134.76.9.214) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 19 Feb 2018 21:39:38 +0100 Received: from krabat.raven.hur (91.8.148.12) by email.gwdg.de (134.76.9.210) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 19 Feb 2018 21:39:38 +0100 Subject: Re: pkg does not recognize correct kernel version To: Ronald Klop , References: From: Rainer Hurling Message-ID: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> Date: Mon, 19 Feb 2018 21:39:37 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:39:41 -0000 Am 19.02.2018 um 21:24 schrieb Ronald Klop: > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling wrote: > >> Hi Ronald, >> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: >>> I just did this. >>> >>> root@sjakie ~]# pkg upgrade >>> Updating FreeBSD repository catalogue... >>> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01 >>> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01 >>> Processing entries:   0% >>> pkg: Newer FreeBSD version for package gnome-menus: >>> - package: 1200058 >>> - running kernel: 1200056 >>> pkg: repository FreeBSD contains packages for wrong OS version: >>> FreeBSD:12:amd64 >>> Processing entries: 100% >>> Unable to update repository FreeBSD >>> Error updating repositories! >>> >>> [root@sjakie ~]# uname -UK >>> 1200058 1200058 >>> >>> [root@sjakie ~]# uname -a >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 >>> 12:37:36 CET 2018   >>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64 >>> >>> >>> >>> So uname gives a different version than pkg detects. >>> >>> What is happening? pkg update -f gives the same result. -o >>> OSVERSION=1200058 helps, but does not feel like the right solution. >>> >>> Regards, >>> Ronald. >> >> Please try >> >> #sysctl kern.osreldate >> kern.osreldate: 1200058 >> >> HTH, >> Rainer Hurling > > > [root@sjakie ~]# sysctl kern.osreldate > kern.osreldate: 1200058 > > Regards, > Ronald. On my kernel patchlevel 1200058 (r329446) I get: #pkg update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05 Processing entries: 100% FreeBSD repository update completed. 28645 packages processed. All repositories are up to date. Perhaps more a local problem :( From owner-freebsd-current@freebsd.org Mon Feb 19 21:06:03 2018 Return-Path: Delivered-To: freebsd-current@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 42AEEF24503 for ; Mon, 19 Feb 2018 21:06:03 +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 C1DD96B634 for ; Mon, 19 Feb 2018 21:06:02 +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 w1JL5p69072812 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Feb 2018 23:05:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1JL5p69072812 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1JL5pHX072808; Mon, 19 Feb 2018 23:05:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 19 Feb 2018 23:05:51 +0200 From: Konstantin Belousov To: Rainer Hurling Cc: Ronald Klop , freebsd-current@freebsd.org Subject: Re: pkg does not recognize correct kernel version Message-ID: <20180219210551.GE94212@kib.kiev.ua> References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:06:03 -0000 On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote: > Am 19.02.2018 um 21:24 schrieb Ronald Klop: > > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling wrote: > > > >> Hi Ronald, > >> > >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: > >>> I just did this. > >>> > >>> root@sjakie ~]# pkg upgrade > >>> Updating FreeBSD repository catalogue... > >>> Fetching meta.txz: 100%ššš 944 Bšš 0.9kB/sššš 00:01 > >>> Fetching packagesite.txz: 100%ššš 6 MiBšš 6.0MB/sššš 00:01 > >>> Processing entries:šš 0% > >>> pkg: Newer FreeBSD version for package gnome-menus: > >>> - package: 1200058 > >>> - running kernel: 1200056 > >>> pkg: repository FreeBSD contains packages for wrong OS version: > >>> FreeBSD:12:amd64 > >>> Processing entries: 100% > >>> Unable to update repository FreeBSD > >>> Error updating repositories! > >>> > >>> [root@sjakie ~]# uname -UK > >>> 1200058 1200058 > >>> > >>> [root@sjakie ~]# uname -a > >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 > >>> 12:37:36 CET 2018šš > >>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64 > >>> > >>> > >>> > >>> So uname gives a different version than pkg detects. > >>> > >>> What is happening? pkg update -f gives the same result. -o > >>> OSVERSION=1200058 helps, but does not feel like the right solution. > >>> > >>> Regards, > >>> Ronald. > >> > >> Please try > >> > >> #sysctl kern.osreldate > >> kern.osreldate: 1200058 > >> > >> HTH, > >> Rainer Hurling > > > > > > [root@sjakie ~]# sysctl kern.osreldate > > kern.osreldate: 1200058 > > > > Regards, > > Ronald. > > On my kernel patchlevel 1200058 (r329446) I get: > > #pkg update -f > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 > Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05 > Processing entries: 100% > FreeBSD repository update completed. 28645 packages processed. > All repositories are up to date. > > > Perhaps more a local problem :( Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD version note: orion% file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 (1101506), FreeBSD-style, stripped Update world past the __FreeBSD_version which is reported for the repository. From owner-freebsd-current@freebsd.org Mon Feb 19 21:37:20 2018 Return-Path: Delivered-To: freebsd-current@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 A2F35F0040D for ; Mon, 19 Feb 2018 21:37:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 3B9686C7AD for ; Mon, 19 Feb 2018 21:37:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x242.google.com with SMTP id l12so6999724ioc.10 for ; Mon, 19 Feb 2018 13:37:20 -0800 (PST) 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=KWYUvrPJ8oW9ofIrb86XaCZAS5y+16Kb+sV/NaFj7QQ=; b=ClYAe/Mjp7gmrJajFsfrCUVJfXZExPqlTRkm8rF/g3aQ0BJ7nrQ7EOX0taN8i3NZ3X NcnLk+B3cejgOD+7DTsjlgN6EtD3zhc+/YocrLqOrPXEZ9LoakNfzPTYikLNvlC4+oUW JeqWFlVSGNHYDFKrBtYdC/tRamfb2XnJN9vDrleNvLOBCgr8EDMF2YdDcgwBtGHghPbW q/9RUUs3xzPhrBBhpqOXZEZ1xHp+0udRdmpnUvS05HTfNcYkG3xtYgjPgAnDu/+B3JX5 I4YschjhoS5Btzicj4LgkuggkuwGxSXq+QhFvSDqlAAKwfXHTcnc0arKETt4D6in9uNb 9rew== 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=KWYUvrPJ8oW9ofIrb86XaCZAS5y+16Kb+sV/NaFj7QQ=; b=m0bshbfAW+RtT2UPH3WUDHc5o3W042a+ee8y1NCN8DdZG1KU9zqCKweTuFGXVUvtmD EqrPvyE/+rBm+T4DiRCTQhWFjuSDcTSOFjNfszeJ8Hsl5glAwLLBWx2JLOeL3qJKYK6I zsEXq4tTB8nXYEcckwyzACJZLSoeFbp+CiirRrAtOalLu+BUVDmLKylUtrDNIcSRSQvs 6G2pHSuo5Xsi5kv5OuKzOKVqiCQGw54hN5vlNG0dSdOD3upP0OwI8GVkwqlvU28CiJDZ Zyo18UEZFTSzxZG4ADhFatbtNj6uorLc936JPb4tQH4YJcbP3wB6GaiqD0m0WNgohIpQ AlwA== X-Gm-Message-State: APf1xPDw5RYk2cqzXWD/8uedjdE62N64Wg0Bwl3gbsGQDUgVFEXG/+Ao CdQLflZTT6ZxloPFhC3rMnpE7bexHpVO/Lb/7/99lw== X-Google-Smtp-Source: AH8x227fAdJSXo+ODSS6M4CYRtLcVaId7ajbtgYTWZKwczhGq29dLSZfNL48BJPZGXqTzdC4Cw7TetfALAIzzd27Fo4= X-Received: by 10.107.2.6 with SMTP id 6mr21163639ioc.117.1519076239359; Mon, 19 Feb 2018 13:37:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Mon, 19 Feb 2018 13:37:18 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:9198:c568:89aa:9c67] Received: by 10.79.201.67 with HTTP; Mon, 19 Feb 2018 13:37:18 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Warner Losh Date: Mon, 19 Feb 2018 14:37:18 -0700 X-Google-Sender-Auth: pRELEbh5d_SOSIpvJkceAuGdLtc Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans Cc: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current , dteske@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-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:37:20 -0000 On Feb 19, 2018 1:23 PM, "Kyle Evans" wrote: Hello! On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor wrote: > I have done a full build of r329555 to test the new Lua boot loader. > > Both the new and the old kernels panic after being loaded with: > > panic: running without device atpic requires a local APIC > > For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous > message: > https://lists.freebsd.org/pipermail/freebsd-current/ 2018-February/068497.html > > OK show hint.acpi.0.disabled > 1 > > Setting ACPI to On resolves the issue. As David noted, this should actually Just Work (TM) now. Can you break into a loader prompt with just the forth loader and tell me what "show hint.acpi.0.rsdp" looks like? > Also, I can not stop boot2 to try to use the copy of the Forth loader: th= e > keyboard only becomes responsive at the loader stage. Hmm... > There is an error during this stage: > > Loading /boot/defaults/loader.conf > Failed to open config: =E2=80=99/boot/loader.conf.local=E2=80=99 David's diagnosis of this is right- this is more of an informational message that you don't need to worry about. > Moreover, the "boot [kernel]" loader command does not work: > > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel > Command failed > OK boot kernel > Command failed > > On the other hand, just "boot" works. It seems that the Forth loader might be doing something sneaky and replacing the standard common "boot" with a Forth boot that handles this a lot better. CC'ing dteske@ so they can confirm. Indeed, it does. Loader.4th defines boot. Search for ': boot' to see it. Warner > Finally, the double lines drawing a frame around the loader menu do not work > with the new loader and are replaced by ? characters in a box. Interesting, I'll look into that... anything interesting/unique about your setup? r329387 should have addressed one potential cause of this, but I see you're past that. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Feb 19 21:43:41 2018 Return-Path: Delivered-To: freebsd-current@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 E989BF00D96 for ; Mon, 19 Feb 2018 21:43:40 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.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 7F96F6CF5F for ; Mon, 19 Feb 2018 21:43:40 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2615.sfr.fr (SMTP Server) with ESMTP id 463001C003588 for ; Mon, 19 Feb 2018 22:34:19 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2615.sfr.fr (SMTP Server) with ESMTPSA; Mon, 19 Feb 2018 22:34:18 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: David Wolfskill , FreeBSD-Current References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <20180219143941.GA1212@albert.catwhisker.org> From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Message-ID: Date: Mon, 19 Feb 2018 22:34:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180219143941.GA1212@albert.catwhisker.org> X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:43:41 -0000 Le 19/02/2018 à 15:39, David Wolfskill a écrit : > On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic: running without device atpic requires a local APIC >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in a >> previous message: >> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html > > That has been fixed (for me, at least). My last two build/smoke-tests > were at r329517 and r329561; I believe that r329366 was the fix for ACPI > detection/setting. > >> OK show hint.acpi.0.disabled >> 1 >> >> Setting ACPI to On resolves the issue. >> >> Also, I can not stop boot2 to try to use the copy of the Forth loader: >> the keyboard only becomes responsive at the loader stage. > >> There is an error during this stage: >> >> Loading /boot/defaults/loader.conf >> Failed to open config: ’/boot/loader.conf.local’ > > IIUC, that's merely an informational message, not an error. (None of my > systems have a /boot/loader.conf.local, either.) > >> Moreover, the "boot [kernel]" loader command does not work: >> >> OK ls /boot/kernel.old/kernel >> /boot/kernel.old/kernel >> OK boot kernel.old >> Command failed >> OK boot /boot/kernel.old/kernel >> Command failed >> OK boot kernel >> Command failed >> >> On the other hand, just "boot" works. > > And the Lua loader permits kernel selection, as well (as the Forth > laoder has). > >> Finally, the double lines drawing a frame around the loader menu do not >> work with the new loader and are replaced by ? characters in a box. > > That has also been fixed for me (as of r329517). > >> Hope it helps, >> Juan >> .... > > Peace, > david Thanks David. It’s strange I’m having issues resolved for you in commits older than the one I used here… From owner-freebsd-current@freebsd.org Mon Feb 19 21:57:30 2018 Return-Path: Delivered-To: freebsd-current@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 390E8F0207E for ; Mon, 19 Feb 2018 21:57:30 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.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 D08A46D9D8; Mon, 19 Feb 2018 21:57:29 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from 27.sub-174-236-10.myvzw.com ([174.236.10.27]:13167 helo=[192.168.1.7]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ensEY-000AS5-Ji; Mon, 19 Feb 2018 20:40:22 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: ACPI panic on boot with new Lua loader and other minor issues From: Devin Teske X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 19 Feb 2018 15:57:23 -0600 Cc: =?utf-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , freebsd-current@freebsd.org, dteske@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> To: Kyle Evans Sender: devin@shxd.cx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:57:30 -0000 > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >=20 > It seems that the Forth loader might be doing something sneaky and > replacing the standard common "boot" with a Forth boot that handles > this a lot better. CC'ing dteske@ so they can confirm. I can indeed confirm this as fact. Not able to help much because I am driving cross-country (San Francisco to O= rlando) right now with the spouse and dog. We get back March 3rd, but I will be checking-in from time to time for spora= dic responses during downtime. =E2=80=94=20 Cheers, Devin= From owner-freebsd-current@freebsd.org Mon Feb 19 21:57:49 2018 Return-Path: Delivered-To: freebsd-current@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 6358DF0210B for ; Mon, 19 Feb 2018 21:57:49 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (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 C19526D9F8; Mon, 19 Feb 2018 21:57:48 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f47.google.com with SMTP id q69so1428317lfi.10; Mon, 19 Feb 2018 13:57:48 -0800 (PST) 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:content-transfer-encoding; bh=a87DtU9sc2kwUaoESJKz/GdaSjSBZMglN6kxzHvG/rc=; b=HpROS3PZWlNGP70t0sql7rZi3vh6meJqAyDlrfB3lOR3oex+Oec6t2sWu2zTxnrDEr IAPA86DRg7QjEP+Rmlswn0nkeWNig59uAm7TaMO4A686rXX51muo4V7o0VS3ZGW+UkHS ujnGsXSOQI6szZEIsYngLEiZvxmO2rRW9mNQwqsrO9Qb/MH4+H1CP/6OedgDnNM2YVqQ q+zEacSB2oYO1Kh7vu9N0P76DcIek9otuXGAL3MMWIyAH+Bf3KkB7/5UYoD0f2knfQG1 zqPrFle4HgVoEQ8ASYf7baeuBkxzooEtFivicgQHCP9ChvKsYnrJarLv8yB72rwp5qOE BPEg== X-Gm-Message-State: APf1xPBmMaEqL4X9hHawRmOLAvrub3+VKwmONczdB3tm7UKvkiAci8I1 x4sac0OutwWAwEnI86PqjOOGO/k8 X-Google-Smtp-Source: AH8x225y0edt9AvNGNHpXt9W2XcQY+v/2mKp86DUX7tS5YggiDr0559GA0oHU7cPZU9cEzqWPVxzUQ== X-Received: by 10.46.89.213 with SMTP id g82mr10871921ljf.105.1519077466629; Mon, 19 Feb 2018 13:57:46 -0800 (PST) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com. [209.85.215.50]) by smtp.gmail.com with ESMTPSA id l193sm5187275lfg.50.2018.02.19.13.57.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 13:57:45 -0800 (PST) Received: by mail-lf0-f50.google.com with SMTP id h78so1445741lfg.6; Mon, 19 Feb 2018 13:57:45 -0800 (PST) X-Received: by 10.46.29.69 with SMTP id d66mr5156262ljd.22.1519077465104; Mon, 19 Feb 2018 13:57:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 13:57:24 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Mon, 19 Feb 2018 15:57:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Warner Losh Cc: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current , dteske@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:57:49 -0000 On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh wrote: > > > On Feb 19, 2018 1:23 PM, "Kyle Evans" wrote: > > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor > wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic: running without device atpic requires a local APIC >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in a >> previous >> message: >> >> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497= .html >> >> OK show hint.acpi.0.disabled >> 1 >> >> Setting ACPI to On resolves the issue. > > As David noted, this should actually Just Work (TM) now. Can you break > into a loader prompt with just the forth loader and tell me what "show > hint.acpi.0.rsdp" looks like? > >> Also, I can not stop boot2 to try to use the copy of the Forth loader: t= he >> keyboard only becomes responsive at the loader stage. > > Hmm... > >> There is an error during this stage: >> >> Loading /boot/defaults/loader.conf >> Failed to open config: =E2=80=99/boot/loader.conf.local=E2=80=99 > > David's diagnosis of this is right- this is more of an informational > message that you don't need to worry about. > >> Moreover, the "boot [kernel]" loader command does not work: >> >> OK ls /boot/kernel.old/kernel >> /boot/kernel.old/kernel >> OK boot kernel.old >> Command failed >> OK boot /boot/kernel.old/kernel >> Command failed >> OK boot kernel >> Command failed >> >> On the other hand, just "boot" works. > > It seems that the Forth loader might be doing something sneaky and > replacing the standard common "boot" with a Forth boot that handles > this a lot better. CC'ing dteske@ so they can confirm. > > > Indeed, it does. > > Loader.4th defines boot. Search for ': boot' to see it. > I've created D14442 [1] to improve this situation a little bit. We should also either: 1.) Provide a way for lua to register a function to handle a loader command= , or 2.) Provide a way for lua/forth to tell the common boot what modules to loa= d. These both entail a good amount of work and quite a few places to fail, but one of them needs to happen. =3D( [1] https://reviews.freebsd.org/D14442 From owner-freebsd-current@freebsd.org Mon Feb 19 22:13:41 2018 Return-Path: Delivered-To: freebsd-current@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 2936BF0371D for ; Mon, 19 Feb 2018 22:13:41 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.10]) (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 B38186ED3D for ; Mon, 19 Feb 2018 22:13:40 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2624.sfr.fr (SMTP Server) with ESMTP id 78DC61C012832 for ; Mon, 19 Feb 2018 23:08:12 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2624.sfr.fr (SMTP Server) with ESMTPSA; Mon, 19 Feb 2018 23:08:11 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans , FreeBSD-Current References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Message-ID: Date: Mon, 19 Feb 2018 23:08:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:13:41 -0000 Le 19/02/2018 à 21:21, Kyle Evans a écrit : > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic: running without device atpic requires a local APIC >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous >> message: >> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html >> >> OK show hint.acpi.0.disabled >> 1 >> >> Setting ACPI to On resolves the issue. > Hi Kyle. > As David noted, this should actually Just Work (TM) now. Can you break > into a loader prompt with just the forth loader and tell me what "show > hint.acpi.0.rsdp" looks like? OK show hint.acpi.0.rsdp Command error I tested both with hint.acpi.0.disabled= 1 and 0. > >> Also, I can not stop boot2 to try to use the copy of the Forth loader: the >> keyboard only becomes responsive at the loader stage. > > Hmm... In fact, I don’t think this has ever worked here… I’ve found a very old (July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage. >> There is an error during this stage: >> >> Loading /boot/defaults/loader.conf >> Failed to open config: ’/boot/loader.conf.local’ > > David's diagnosis of this is right- this is more of an informational > message that you don't need to worry about. Thanks. >> Moreover, the "boot [kernel]" loader command does not work: >> >> OK ls /boot/kernel.old/kernel >> /boot/kernel.old/kernel >> OK boot kernel.old >> Command failed >> OK boot /boot/kernel.old/kernel >> Command failed >> OK boot kernel >> Command failed >> >> On the other hand, just "boot" works. > > It seems that the Forth loader might be doing something sneaky and > replacing the standard common "boot" with a Forth boot that handles > this a lot better. CC'ing dteske@ so they can confirm. > >> Finally, the double lines drawing a frame around the loader menu do not work >> with the new loader and are replaced by ? characters in a box. > > Interesting, I'll look into that... anything interesting/unique about > your setup? r329387 should have addressed one potential cause of this, > but I see you're past that. I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 4GB RAM). The only thing I can think of is that the ACPI of this model is not well supported, but the errors I have are related to thermal zones…: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678 To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache and WITH_META_MODE, but this build process has been working nicely for months. The kernel is based on GENERIC-NODEBUG and has been also working reliably: juan@Server ~ % cat /root/kernels/MEMSTICK include GENERIC-NODEBUG ident MEMSTICK nodevice fdc nodevice ch nodevice sa nodevice ses nodevice amr nodevice arcmsr nodevice ciss nodevice dpt nodevice hptmv nodevice hptnr nodevice hptrr nodevice hpt27xx nodevice iir nodevice ips nodevice mly nodevice twa nodevice tws nodevice aac nodevice aacp nodevice aacraid nodevice ida nodevice mfi nodevice mlx nodevice mrsas nodevice pmspcv nodevice twe nodevice nvme nodevice nvd nodevice virtio nodevice virtio_pci nodevice vtnet nodevice virtio_blk nodevice virtio_scsi nodevice virtio_balloon nooptions HYPERV nodevice hyperv nooptions XENHVM nodevice xenpci nodevice vmx There is maybe something fishy in my src.conf, where I disable a lot of things to slim down the memstick, but still, it has been stable till now: juan@Server ~ % cat /etc/src.conf # For memory sticks WITH_CCACHE_BUILD= WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_ATM= WITHOUT_AUTHPF= WITHOUT_AUTOFS= WITHOUT_BHYVE= WITHOUT_BLACKLIST= # iwm does not support Bluetooth WITHOUT_BLUETOOTH= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= # WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG WITHOUT_BSNMP= WITHOUT_CALENDAR= # Don't set this when building HEAD from RELENG # WITHOUT_CROSS_COMPILER= WITHOUT_CTM= WITHOUT_DEBUG_FILES= #WITHOUT_DIALOG= WITHOUT_DICT= WITHOUT_EE= WITHOUT_EXAMPLES= WITHOUT_FDT= WITHOUT_FINGER= WITHOUT_FLOPPY= # For testing the Lua loader (WITH_LOADER_LUA) WITHOUT_FORTH= WITHOUT_FREEBSD_UPDATE= WITHOUT_GAMES= WITHOUT_GCOV= WITHOUT_GPIO= # You disable Kerberos later, but try to keep GSSAPI for curl > pkg # But this does not work, base Kerberos is required #WITH_GSSAPI= WITHOUT_GSSAPI= WITHOUT_HAST= WITHOUT_HESIOD= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_IPFW= WITHOUT_ISCSI= WITHOUT_JAIL= WITHOUT_KERBEROS= WITHOUT_KERNEL_SYMBOLS= WITHOUT_KVM= WITHOUT_LDNS= # This disables moused #WITHOUT_LEGACY_CONSOLE= WITHOUT_LLDB= # This requires WITHOUT_FORTH WITH_LOADER_LUA= # This breaks setting locale and thus tmux #WITHOUT_LOCALES= WITHOUT_LPR= WITHOUT_MAIL= WITHOUT_NETCAT= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PORTSNAP= WITHOUT_PPP= WITHOUT_PROFILE= WITHOUT_QUOTAS= WITHOUT_RADIUS_SUPPORT= WITHOUT_RBOOTD= WITHOUT_RCS= WITHOUT_SHAREDOCS= WITH_SVN= WITHOUT_SYSCONS= WITHOUT_TALK= WITHOUT_TCP_WRAPPERS= WITHOUT_TELNET= WITHOUT_TESTS= WITHOUT_TFPT= WITHOUT_TIMED= WITHOUT_UNBOUND= WITHOUT_UTMPX= WITHOUT_ZFS= WITHOUT_ZONEINFO= Thanks for your attention. Juan From owner-freebsd-current@freebsd.org Mon Feb 19 22:26:38 2018 Return-Path: Delivered-To: freebsd-current@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 74134F045EE for ; Mon, 19 Feb 2018 22:26:38 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC4EA6F85A for ; Mon, 19 Feb 2018 22:26:37 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w1JMI95Q036220 for ; Mon, 19 Feb 2018 14:18:15 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Date: Mon, 19 Feb 2018 14:18:15 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:26:38 -0000 I'm seeing a number of messages like the following: kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d and was wondering if it's anything to be concerned with, or whether fsck(8) is fixing them=2E This began to happen when the power went out on a new install: FreeBSD dns0 12=2E0-CURRENT FreeBSD 12=2E0-CURRENT #0: Wed Dec 13 06:07:59 PST = 2017 root@dns0:/usr/obj/usr/src/amd64=2Eamd64/sys/DNS0 amd64 which hadn't yet been hooked up to the UPS=2E I performed an fsck in single user mode upon power-up=2E Which ended with the mount points being masked CLEAN=2E I was asked if I wanted to use the JOURNAL= =2E I answered Y=2E FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: newfs -U -j Thank you for all your time, and consideration=2E --Chris From owner-freebsd-current@freebsd.org Mon Feb 19 22:32:57 2018 Return-Path: Delivered-To: freebsd-current@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 34C2DF04FAE for ; Mon, 19 Feb 2018 22:32:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 BB4C16FFA2 for ; Mon, 19 Feb 2018 22:32:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id p188so12848711ioe.12 for ; Mon, 19 Feb 2018 14:32:56 -0800 (PST) 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=49ryWu0Twm6h/WzppGkp3rnoSDzTwUDA99eqvLs9nxo=; b=WgkpQqQ5aTNanMJijPgaN4coyM206PvL+/daUDXyZ9ISOlDKGuuF201W3IlIfePcO4 UAPEi5RyYKZ4ctmUBpIHKY+CBOs7M67nn7XaunLAqDOT8dOtZry04Zzw/e151mWJmovH /IdvtydpPPlpvOcV3/3cJpbTkir2JZwkHyquYY/wFz5bg0l2YBr3qG5aj6ySohj6qqgd sKd5DMNVILPHOvh/S3aOSU7xrpdx0Of5WfmfvtS6s4UMIG3oD3xHYCvmR2SWFyNr6BbK brLKMNDmk9H+2iejaA4sC42jKo7PeEAMprYNRbI0GxDKf3PGoR1CmBW4podLwuaRu2Bp 7cAg== 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=49ryWu0Twm6h/WzppGkp3rnoSDzTwUDA99eqvLs9nxo=; b=COJuyJ1n+wAqxaGWjFo2gGFjlbEr9PwleJvxbyVin1U4bGmIxdEkQOM4b0kMCHAtqy 3NiGQgOa20u/wq5mdanT3bpDYLn//MvBZOwcBqnxQW61bWb2ihqRm0EDGSawHVHoT5Qc tOQ+zypNMwhDW8n2G9cO4w7iIZQHKvM50pR9mE2u8LsccDi0oKptG711rCZmOUjyTBC4 doweu92CYYarW3GVUa/FPgtbTCfNJa9eW/h0CWrfRMDZnqGuOF1Tr3sEWb0mLUPX5Qjo EhhzFA+dk70/+UGYJXp19CUufpbnA7PhwmmytuU3JAm0Jq0kM1ixyoTRFI0ceoPucUSL Z/Aw== X-Gm-Message-State: APf1xPDMCAg+fWNHJNK4XxAEbwKo46NJUFZnGqR1NW/J076rRHKt/Gni 5z0CDIEkD31OFDEleMVRlfkc3f95cngKwXfRX7emFQ== X-Google-Smtp-Source: AH8x224qqjMHY3181GaTtVO4u3sTIql6+0ndUa9xF0lwzlOvxJgMHO46Aifl0iEpUzWeS5aYlDQOxbrGsoTEEBfrbrk= X-Received: by 10.107.2.6 with SMTP id 6mr21337147ioc.117.1519079575934; Mon, 19 Feb 2018 14:32:55 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Mon, 19 Feb 2018 14:32:55 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> From: Warner Losh Date: Mon, 19 Feb 2018 15:32:55 -0700 X-Google-Sender-Auth: hFLaYUdY-seyFLGRAF1e-8PDBBA Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Devin Teske Cc: Kyle Evans , =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:32:57 -0000 On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: > > > > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: > > > > It seems that the Forth loader might be doing something sneaky and > > replacing the standard common "boot" with a Forth boot that handles > > this a lot better. CC'ing dteske@ so they can confirm. > > I can indeed confirm this as fact. > > Not able to help much because I am driving cross-country (San Francisco to > Orlando) right now with the spouse and dog. > > We get back March 3rd, but I will be checking-in from time to time for > sporadic responses during downtime. > The command in loader.4th is defined as: : boot 0= if ( interpreted ) get_arguments then \ Unload only if a path was passed dup if >r over r> swap c@ [char] - <> if 0 1 unload drop else s" kernelname" getenv? if ( a kernel has been loaded ) try-menu-unset bootmsg 1 boot exit then load_kernel_and_modules ?dup if exit then try-menu-unset bootmsg 0 1 boot exit then else s" kernelname" getenv? if ( a kernel has been loaded ) try-menu-unset bootmsg 1 boot exit then load_kernel_and_modules ?dup if exit then try-menu-unset bootmsg 0 1 boot exit then load_kernel_and_modules ?dup 0= if bootmsg 0 1 boot then ; The thing to know here is when you see 'boot' as part of above script, it's calling the 'boot' cli command, not itself recursively. I can help do more interpretation of the details if you need Kyle. Not sure how much to spell out, but the brief pseudo code is: If there were any arguments that didn't start with '-', unload. otherwise if kernelname is in in the environment, run the 'menu-unset' forth word if it exists, print the boot message and boot. Otherwise load the kernel and modules, run the 'menu-unset' forth word (if it exists), print the boot message and boot with kernelname Otherwise load the kernel and modules, run the 'menu-unset' forth word (if it exists), print the boot message and boot with kernelname if all that fails, load the kernel and modules and if that works boot them. Warner From owner-freebsd-current@freebsd.org Mon Feb 19 22:44:30 2018 Return-Path: Delivered-To: freebsd-current@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 B0074F05F17 for ; Mon, 19 Feb 2018 22:44:30 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.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 33E5670B26; Mon, 19 Feb 2018 22:44:30 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id y19so1587390lfd.4; Mon, 19 Feb 2018 14:44:30 -0800 (PST) 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=+Xx/Zr4EliR/j1MlnQ92nNfpm14jG1DteXXFDy9bhbw=; b=NDMA5wG0yJWzrb+ILSyyaUtzmZxPvuWOvTaXOeOdzv8wCKh4oCdSIc4kDr0Kpse7NZ Q+vBRWnbS03dj8aRjSDCMkXbs6Vrs8rJBtrJDGeWnJiSjw6I+HRQxFRkNixP8RFKuHDV poes1TQfaEn9dV57GOU/2TzWkm0ptHdbaoOP2K7XYN4IYXrnFPzAAvj7Y8WaBp2D8lp8 PcdEYpNZN5CdRnfqjSlRu9raCZ2uuhmq008r/EhD1eil8N0Lmi7WsnQf3gangAB5n82f ewoy2Ulj5gpJWlGunJQ/7ZnmVVP4RZ729NwFaf78DNiTk8OPXE2Srajqlg+baCu+LbGy t9KQ== X-Gm-Message-State: APf1xPBl5XpsMrycE/VxOh709/C1/FB/IMVASRqNl9yA7nVP+XWrIKs0 3E97bD10JKVvjJJxm5Ov1g/lkIKz X-Google-Smtp-Source: AH8x226LjHwe6mNjgPHg8nNzbOs3bUzB5pR2ZmqFjW3AXOayIC/HfVRbxVpk7ZR1a7wmpP/cq1nyTA== X-Received: by 10.46.125.3 with SMTP id y3mr5190773ljc.23.1519079901283; Mon, 19 Feb 2018 14:38:21 -0800 (PST) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com. [209.85.215.49]) by smtp.gmail.com with ESMTPSA id 65sm4611232lfa.77.2018.02.19.14.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 14:38:21 -0800 (PST) Received: by mail-lf0-f49.google.com with SMTP id j193so1588294lfe.0; Mon, 19 Feb 2018 14:38:21 -0800 (PST) X-Received: by 10.46.88.84 with SMTP id x20mr11121712ljd.44.1519079900882; Mon, 19 Feb 2018 14:38:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 14:38:00 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> From: Kyle Evans Date: Mon, 19 Feb 2018 16:38:00 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Warner Losh Cc: Devin Teske , =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:44:30 -0000 On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh wrote: > > > On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >> >> >> >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing something sneaky and >> > replacing the standard common "boot" with a Forth boot that handles >> > this a lot better. CC'ing dteske@ so they can confirm. >> >> I can indeed confirm this as fact. >> >> Not able to help much because I am driving cross-country (San Francisco to >> Orlando) right now with the spouse and dog. >> >> We get back March 3rd, but I will be checking-in from time to time for >> sporadic responses during downtime. > > > The command in loader.4th is defined as: > > : boot > 0= if ( interpreted ) get_arguments then > > \ Unload only if a path was passed > dup if > >r over r> swap > c@ [char] - <> if > 0 1 unload drop > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > load_kernel_and_modules > ?dup 0= if bootmsg 0 1 boot then > ; > > The thing to know here is when you see 'boot' as part of above script, it's > calling the 'boot' cli command, not itself recursively. > > I can help do more interpretation of the details if you need Kyle. Not sure > how much to spell out, but the brief pseudo code is: > > If there were any arguments that didn't start with '-', unload. > otherwise if kernelname is in in the environment, run the 'menu-unset' > forth word if it exists, print the boot message and boot. > Otherwise load the kernel and modules, run the 'menu-unset' forth word (if > it exists), print the boot message and boot with kernelname > Otherwise load the kernel and modules, run the 'menu-unset' forth word (if > it exists), print the boot message and boot with kernelname > if all that fails, load the kernel and modules and if that works boot them. > Yeah, we have something like this on the lua side. Unfortunately, it's going to wreck people's muscle memory- dropping to the loader prompt and typing "boot [x]" will never work as expected because lua won't recognize that as a function call due to spaces as delimiters. We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])" (for some [x] that could be multiple space-delimited arguments) before falling back to the originally typed "cmd [x]" if we want Lua to have any chance to intercept it and adds its own salt and pepper like Forth does. From owner-freebsd-current@freebsd.org Mon Feb 19 22:50:23 2018 Return-Path: Delivered-To: freebsd-current@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 3850AF06498 for ; Mon, 19 Feb 2018 22:50:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 CD25070DF2 for ; Mon, 19 Feb 2018 22:50:22 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1enuGK-0007lI-9I; Mon, 19 Feb 2018 23:50:20 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Rainer Hurling" , "Konstantin Belousov" Cc: freebsd-current@freebsd.org Subject: Re: pkg does not recognize correct kernel version References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> Date: Mon, 19 Feb 2018 23:38:42 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20180219210551.GE94212@kib.kiev.ua> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: dd305f484f1ad876e240bae2a9803cbd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:50:23 -0000 On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov wrote: > On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote: >> Am 19.02.2018 um 21:24 schrieb Ronald Klop: >> > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling >> wrote: >> > >> >> Hi Ronald, >> >> >> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: >> >>> I just did this. >> >>> >> >>> root@sjakie ~]# pkg upgrade >> >>> Updating FreeBSD repository catalogue... >> >>> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> >>> Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 >> >>> Processing entries: 0% >> >>> pkg: Newer FreeBSD version for package gnome-menus: >> >>> - package: 1200058 >> >>> - running kernel: 1200056 >> >>> pkg: repository FreeBSD contains packages for wrong OS version: >> >>> FreeBSD:12:amd64 >> >>> Processing entries: 100% >> >>> Unable to update repository FreeBSD >> >>> Error updating repositories! >> >>> >> >>> [root@sjakie ~]# uname -UK >> >>> 1200058 1200058 >> >>> >> >>> [root@sjakie ~]# uname -a >> >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun >> Feb 18 >> >>> 12:37:36 CET 2018 >>> >> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64 >> >>> >> >>> >> >>> >> >>> So uname gives a different version than pkg detects. >> >>> >> >>> What is happening? pkg update -f gives the same result. -o >> >>> OSVERSION=1200058 helps, but does not feel like the right solution. >> >>> >> >>> Regards, >> >>> Ronald. >> >> >> >> Please try >> >> >> >> #sysctl kern.osreldate >> >> kern.osreldate: 1200058 >> >> >> >> HTH, >> >> Rainer Hurling >> > >> > >> > [root@sjakie ~]# sysctl kern.osreldate >> > kern.osreldate: 1200058 >> > >> > Regards, >> > Ronald. >> >> On my kernel patchlevel 1200058 (r329446) I get: >> >> #pkg update -f >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05 >> Processing entries: 100% >> FreeBSD repository update completed. 28645 packages processed. >> All repositories are up to date. >> >> >> Perhaps more a local problem :( > > Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD Which man page? I can't find it in pkg help update or pkg help upgrade or man pkg. > version note: > orion% file /bin/ls > /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 > (1101506), FreeBSD-style, stripped > > Update world past the __FreeBSD_version which is reported for the > repository. Does this mean I always have to do a *clean* buildworld after every version bump? This takes ages. Regards, Ronald. From owner-freebsd-current@freebsd.org Mon Feb 19 23:44:36 2018 Return-Path: Delivered-To: freebsd-current@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 3E554F09F8F for ; Mon, 19 Feb 2018 23:44:36 +0000 (UTC) (envelope-from peter.lei@ieee.org) 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 C9F6C72E40 for ; Mon, 19 Feb 2018 23:44:35 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: by mail-it0-x236.google.com with SMTP id n7so1722901ita.5 for ; Mon, 19 Feb 2018 15:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Jia0CeirDteHflsYBNQ+bsmeubAPSScXIFg1RUGqz1w=; b=yzGqJJxFNDf3RUZSdvHg+1GLWXX8j9/YPEd/rCulZnxN7OSuDy7eJwr6TEEFieCXKF 4zFxgsUigPfFJgG0p/T6DMOW7Qo3iLVbd7lYZWWIeelEIlPPSYWYlk1ut8dSAEiPaazw bgRQuqgpeLzOgn6x0C1F7gu1OsyXqmDQennvRDspv1xfQtivjVk2KPN37Oa/6Br4K9Kk gr60VVBJRPFM+gjJ9w1/xd48NHQfRdIM7k7P7yr47+AYb6+sjR8s2ZbEVxVaHbEtsqVH kRIOGtL48MPbW9WinPs+su5oQDkwUBpp6JD0zhjgl42otU5n8GQAvE7PQwJhShF/6nR0 R5qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Jia0CeirDteHflsYBNQ+bsmeubAPSScXIFg1RUGqz1w=; b=peYjRtEFj9ETO6Wji38WRrLpZMAjHm+kMaiFcSk9rgIApljywzJdPRayVJZg0ysKtc QB8HuycW803Vw8owh8k4RvwAlsHn3L4UncQenLF1VZcIKq2t57NvrBQ8Z9BrAPoDHt0C WLKuuaLItg+PyvZcj2/Nii1hIiknkXvvPq4nif9x8XCP0sUd5KtTCywvlUrRtqsPyyAJ kKObURFy4mSRIz2/VLr9SaWltbe05QhJ+0X8+q3/cNl1BRQCnAy/h7SbUL1pdnVYP/ok V/wUx+LZ3c11UMNWGdtQy6vFFqt+YXWXclvWRx1+uSKGYNd4PlcIv0ytowQ2O17+/k6A gqoA== X-Gm-Message-State: APf1xPDknxU34sfgK0wjORe840I52cU89Bj3u3qygp+JBkknCdtDdhL5 1AuFh5UU0KaCGGxZmcT0CLIJvg== X-Google-Smtp-Source: AH8x226x/dqb7bAo/VUB5ix8WBh+6V3Pzyxa/PskY3anqFr26/ByRN9cww1E+jJGuUNveqQ0puI/Mg== X-Received: by 10.36.151.197 with SMTP id k188mr18045067ite.45.1519083875020; Mon, 19 Feb 2018 15:44:35 -0800 (PST) Received: from mbpro15.local ([2607:fb10:7061:7fd::7d2]) by smtp.gmail.com with ESMTPSA id g127sm3438991iof.2.2018.02.19.15.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 15:44:34 -0800 (PST) Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans , =?UTF-8?Q?Juan_Ram=c3=b3n_Molina_Menor?= Cc: freebsd-current@freebsd.org, dteske@freebsd.org References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Peter Lei Message-ID: Date: Mon, 19 Feb 2018 17:44:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080306050409050201050303" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 23:44:36 -0000 This is a cryptographically signed message in MIME format. --------------ms080306050409050201050303 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/19/18 2:21 PM, Kyle Evans wrote: > Hello! >=20 > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic: running without device atpic requires a local APIC >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in a pre= vious >> message: >> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/0684= 97.html >> >> OK show hint.acpi.0.disabled >> 1 >> >> Setting ACPI to On resolves the issue. >=20 > As David noted, this should actually Just Work (TM) now. Can you break > into a loader prompt with just the forth loader and tell me what "show > hint.acpi.0.rsdp" looks like? This doesn't appear to "just work out-of-the-box" yet when EFI booting amd64, as I still get the 'no local APIC' panic (I just tried @r329609). Under EFI and lua loader, the following is set when breaking to prompt: hint.acpi.0.disabled=3D1 Under forth loader, this is not present/set. In neither case is hint.acpi.0.rsdp present/set as that appears to get set during the exec of the loaded kernel... I've worked around the issue by adding hint.acpi.0.disabled=3D"0" to loader.conf (or patching the amd64 efi loader code to explicitly clear that hint). --------------ms080306050409050201050303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cx4wggUwMIIEGKADAgECAhEA5uRbT5dO2Nji0P2d3zpsSDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMTA5MDAw MDAwWhcNMTgxMTA5MjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJwZXRlci5sZWlAaWVlZS5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxBMAPv3y1gA/CpG9WGm3dIJR9 2ch1Vk4InSVWXHV11mt1j2gNajK8Sa+IyPSf4/xeP/MQfkworYIM2n0Ob5F6/t2oNS4w/G2y 0CaCSxQAtbk46wKKErx20t4s4ODDs3YXzf38juNMB93YCVhFrs8jyKP1/Y7RwkjaKrRF8KBK PxHUcqxhZir3TjOJtu2P2STWtPD2fRpRkvN+gEh2ejd+n1HHBst/9Rtz0vb8yHFWl1n1YISi KQOXT73a0MFrdFGYlJwvoZJZWmV7XGthlLGt7h41f01Ug91eKY19XB3K6CmZLdiwy/6Ir8nG QMC0OH7LcudUfbu6wk7MY+ceTO4PAgMBAAGjggHoMIIB5DAfBgNVHSMEGDAWgBSCr2yM+MX+ lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQU9tUteyjHW7DsqMhulCpoaT1DlQMwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBL hklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAdBgNVHREEFjAUgRJwZXRlci5sZWlAaWVlZS5vcmcwDQYJKoZIhvcNAQELBQADggEBAHBU iY1f7LKqo0sQAs/YRvlvL2ydz+9oCDf6BNnyTjDXOiET4D2t5kMh0fceGKhlpfAOA47Nob1s MNS+6sjOqEm8e10SjVv69dq6ZmjFVqTZ1MZjt1Mmi7XpsNYiLE66dF9Ff0ne8bHhcqHVHtFT 6MU7Fq1N8r5mnqCB7zPxuDYV9DprrnOYm2g68CRVGsKhH5kYSsYogMQpxgZ5PP0gdnpfKV+X ROtXTpZg4Ln6WCaeGh5oVdCw095af07hIG8F9VM559N8jv4Z9/R5MsrM6AfwJvXmVUQ9XGKk qZw0MUbf8FQCS928I3h111Ur5zap+rXiu+lJ4cI6T6/h3p3TdCswggXmMIIDzqADAgECAhBq m+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00 SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0 RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq 8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmO upyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOC ATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM +MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEE ZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRU cnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqG SIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxC DBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt /eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77 ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT 3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWB f/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5I SYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwxCTP9 bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S /GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDgwggQ0AgEBMIGt MIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQH EwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RP IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAObkW0+X TtjY4tD9nd86bEgwDQYJYIZIAWUDBAIBBQCgggJbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIxOTIzNDQzMlowLwYJKoZIhvcNAQkEMSIEIO5bXims zWZbHy7HZw4Ib/WuRRxWDp+5CbIhycMM1UC3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDm5FtPl07Y2OLQ /Z3fOmxIMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDm5FtPl07Y2OLQ/Z3fOmxIMA0GCSqGSIb3DQEBAQUA BIIBAA+9Og7KZbmu8dBKwHDJzIJiBlVpoW2b0EV7Jz+WiCVwTUD6BEA3IEWziLe0NYlHOKuo ix8SyyLDGGl2v5J2HfoLjsk2diQx6Bq+IX/9q5z7Dki0L0GJ6oty9kYAIs447b9L56Dr8z0n iOnJiFgSNi1+Czxu3EStnIUlcKcV5UVgtvq3wOr8uihKPjbgl9AHTgDHgklcOI/FZjYHPyEQ Bl5XAJzRhwACzOsQObwcfKq5S99NmQPHvA3hnvF/4WnK2ClYLzDiGru/bBALfi7j+bwgm5Kq BEHvtbB8jKXGgmTpZirDvBThXDb0U2sh1a7fOiE+fuH9BhOkLg1LPG1d51QAAAAAAAA= --------------ms080306050409050201050303-- From owner-freebsd-current@freebsd.org Mon Feb 19 23:48:30 2018 Return-Path: Delivered-To: freebsd-current@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 E3CA4F0A3AC for ; Mon, 19 Feb 2018 23:48:29 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.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 594A273013; Mon, 19 Feb 2018 23:48:29 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id l191so1760188lfe.1; Mon, 19 Feb 2018 15:48:29 -0800 (PST) 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=ydbq6gDXwpiihebt+Jcjmfn52FNvGXag1xVMPg6epRM=; b=ULI9PdZzH4Yp1X5iZqAj7pCrdyZ4ArpRsv09ynNYoN4DJbZ3qO86a/u1WWDSZPt/z6 XcyV1eVVsdD4a00lE4QOXjXyHD9v7AjmVDLUIOsAIDwIQy1SGWyKjdIIqgkgH2kp2oES o6aBOelJNG0KnoAWWK+jFgPnhXXeF1Vqcj4im31qA2zRleTsFyZeq5cmKyeaDMhGCmLH HtLK4tHP04joKneX0huLsj+etD9aO1zQ7RkWog4nCHb/6eBfqsGLg7zEMcMMJXFJwDgN L4bA6mRxsUsaYm/Fnv8jBQFv8f4RBrwc7MdDILcaUlnZx/aTQt+tx03lEaC90vfOSiNT ccTg== X-Gm-Message-State: APf1xPAJ1Y9JHpGpAzQ6OyVcaWCgUBGIQlOm2jHlTt1LanKn3Fo8WyO8 rTHjJ3s5cNbfoU89A4pSmhWoghgG X-Google-Smtp-Source: AH8x226R9sr+qLIPksRGy053CP/3Fxz57fkbeDX3ikSuYnABTQioh3JGRSE2vaftmUVneF1ZMD8LoQ== X-Received: by 10.46.82.16 with SMTP id g16mr10375306ljb.67.1519084107391; Mon, 19 Feb 2018 15:48:27 -0800 (PST) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com. [209.85.215.41]) by smtp.gmail.com with ESMTPSA id f7sm4648839lfb.42.2018.02.19.15.48.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 15:48:26 -0800 (PST) Received: by mail-lf0-f41.google.com with SMTP id 70so1745335lfw.2; Mon, 19 Feb 2018 15:48:26 -0800 (PST) X-Received: by 10.25.233.23 with SMTP id g23mr9327582lfh.99.1519084106499; Mon, 19 Feb 2018 15:48:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 15:48:25 -0800 (PST) Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 15:48:25 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Mon, 19 Feb 2018 17:48:25 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Peter Lei Cc: freebsd-current@freebsd.org, dteske@freebsd.org, listjm@club.fr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 23:48:30 -0000 On Feb 19, 2018 5:44 PM, "Peter Lei" wrote: On 2/19/18 2:21 PM, Kyle Evans wrote: > Hello! > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor wrote: >> I have done a full build of r329555 to test the new Lua boot loader. >> >> Both the new and the old kernels panic after being loaded with: >> >> panic: running without device atpic requires a local APIC >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous >> message: >> https://lists.freebsd.org/pipermail/freebsd-current/ 2018-February/068497.html >> >> OK show hint.acpi.0.disabled >> 1 >> >> Setting ACPI to On resolves the issue. > > As David noted, this should actually Just Work (TM) now. Can you break > into a loader prompt with just the forth loader and tell me what "show > hint.acpi.0.rsdp" looks like? This doesn't appear to "just work out-of-the-box" yet when EFI booting amd64, as I still get the 'no local APIC' panic (I just tried @r329609). Under EFI and lua loader, the following is set when breaking to prompt: hint.acpi.0.disabled=3D1 Under forth loader, this is not present/set. In neither case is hint.acpi.0.rsdp present/set as that appears to get set during the exec of the loaded kernel... I've worked around the issue by adding hint.acpi.0.disabled=3D"0" to loader.conf (or patching the amd64 efi loader code to explicitly clear that hint). [Apologies for broken quoting, currently mobile] What happens if you patch this line out? https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=3Dmarkup#l233 I'll have to go back and figure out what I was thinking here again. It made sense when I wrote it, maybe explicitly disabling ACPI if it's not immediately detected was the wrong move. =3D) From owner-freebsd-current@freebsd.org Tue Feb 20 00:11:24 2018 Return-Path: Delivered-To: freebsd-current@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 A3E6EF0C7A2 for ; Tue, 20 Feb 2018 00:11:24 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3632074531 for ; Tue, 20 Feb 2018 00:11:23 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: by mail-io0-x22a.google.com with SMTP id 30so7842934iog.2 for ; Mon, 19 Feb 2018 16:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=37LEpG19tli1khugodF5sXkNXdWntQbv2Ie3bc7TVuc=; b=b+7kSq1K9wNDRQbgn3f6+JC5WFFeAN2v6HSHZKfBK3Hv+3t6mIsEpRtuJ5jwJGRdw5 8IDMTKOoxfWzg6Ra2ShY5siUrQeN/7FWw/nWVk+QbH/A5m345mUKwB6vpFro5G/++E19 jLV6No4RfK2RlWyFUVf9+QPI/KReswWlyy2b7ep4FyyBYdIDOtIipbgsFRm8TmWCMHaK 9wMEhOFIk7e4MAJu0oqYlaBRdPb8GTOf3cNDVphD/ESS+VH53Xbsf2XJNsch1XtzgBiS 3clAxmvegnV9sLjDCJeqSi8qzwdiQHaafq6PhjgbTsB/5jzNqxvitksLssPUAsTkv2d4 2KVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=37LEpG19tli1khugodF5sXkNXdWntQbv2Ie3bc7TVuc=; b=ZHqOqlAktWPpsUn77bWfl8Y3vZUBgvZQtqDycCVx2NrSANCGHKzjvOCtjh8Xg1O6nK XOPVE1TmnroXfSLIIREsURcLv5Bh4F2Rj1jWZIbC9wURmoNSyy1BmM7ABhuM5qCRzgEX Oc3GO77rBaPwvo2FHF44QwDD/q0NDU51E45fyJkcKFY9rd9OV8vZDvoaEu9mPA/pkqpn piYZWw4N5eVbRs8mUDTA9hcjy3ktRNCskeyaPBe538P4oBQuw0PMpXAhhGzmk7kGHv2m YsPU4E09CPnWYPMbDlFnz+bN4PFttFDz6ucmZStcHeg7t72s8Y0T7lAj4k7/SULA2PmZ cFAA== X-Gm-Message-State: APf1xPBU6k5txM1eHYYXwaMwSq1xRh8UL24G7GFQngLyqDtLACcz0cHy FX9h80Q6IZSZgSNC+eCm0lwDU8xcWeEN6A== X-Google-Smtp-Source: AH8x2261H9siMDaxRyaJ4I79FXCMUIQqX/9BRrxwcpP5LQ2TGfi+OU1TOVYqtgryFM24vOvOpnkolQ== X-Received: by 10.107.159.148 with SMTP id i142mr22367515ioe.36.1519085483296; Mon, 19 Feb 2018 16:11:23 -0800 (PST) Received: from mbpro15.local ([2607:fb10:7061:7fd::7d2]) by smtp.gmail.com with ESMTPSA id m32sm588920iti.3.2018.02.19.16.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 16:11:22 -0800 (PST) Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans Cc: freebsd-current@freebsd.org, dteske@freebsd.org, listjm@club.fr References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Peter Lei Message-ID: <5bea1c92-0ae9-7acb-d806-b7d7623658e1@ieee.org> Date: Mon, 19 Feb 2018 18:11:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030509060902050606050201" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 00:11:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030509060902050606050201 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/19/18 5:48 PM, Kyle Evans wrote: >=20 >=20 > On Feb 19, 2018 5:44 PM, "Peter Lei" > wrote: >=20 >=20 >=20 > On 2/19/18 2:21 PM, Kyle Evans wrote: > > Hello! > > > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor > > wrote: > >> I have done a full build of r329555 to test the new Lua boot loa= der. > >> > >> Both the new and the old kernels panic after being loaded with: > >> > >> panic: running without device atpic requires a local APIC > >> > >> For reasons unknown, ACPI is off, as shown by David Wolfskill in= > a previous > >> message: > >> > https://lists.freebsd.org/pipermail/freebsd-current/2018-February/0= 68497.html > > >> > >> OK show hint.acpi.0.disabled > >> 1 > >> > >> Setting ACPI to On resolves the issue. > > > > As David noted, this should actually Just Work (TM) now. Can you = break > > into a loader prompt with just the forth loader and tell me what = "show > > hint.acpi.0.rsdp" looks like? >=20 >=20 > This doesn't appear to "just work out-of-the-box" yet when EFI boot= ing > amd64, as I still get the 'no local APIC' panic (I just tried @r329= 609). >=20 > Under EFI and lua loader, the following is set when breaking to pro= mpt: > =C2=A0 =C2=A0 hint.acpi.0.disabled=3D1 > Under forth loader, this is not present/set. >=20 > In neither case is hint.acpi.0.rsdp present/set as that appears to = get > set during the exec of the loaded kernel... >=20 > I've worked around the issue by adding hint.acpi.0.disabled=3D"0" t= o > loader.conf (or patching the amd64 efi loader code to explicitly cl= ear > that hint). >=20 >=20 > [Apologies for broken quoting, currently mobile] >=20 > What happens if you patch this line out? > https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=3Dmarkup#l= 233 Ah, right - yep, commenting out that line works. > I'll have to go back and figure out what I was thinking here again. It > made sense when I wrote it, maybe explicitly disabling ACPI if it's not= > immediately detected was the wrong move. =3D) --------------ms030509060902050606050201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cx4wggUwMIIEGKADAgECAhEA5uRbT5dO2Nji0P2d3zpsSDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMTA5MDAw MDAwWhcNMTgxMTA5MjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJwZXRlci5sZWlAaWVlZS5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxBMAPv3y1gA/CpG9WGm3dIJR9 2ch1Vk4InSVWXHV11mt1j2gNajK8Sa+IyPSf4/xeP/MQfkworYIM2n0Ob5F6/t2oNS4w/G2y 0CaCSxQAtbk46wKKErx20t4s4ODDs3YXzf38juNMB93YCVhFrs8jyKP1/Y7RwkjaKrRF8KBK PxHUcqxhZir3TjOJtu2P2STWtPD2fRpRkvN+gEh2ejd+n1HHBst/9Rtz0vb8yHFWl1n1YISi KQOXT73a0MFrdFGYlJwvoZJZWmV7XGthlLGt7h41f01Ug91eKY19XB3K6CmZLdiwy/6Ir8nG QMC0OH7LcudUfbu6wk7MY+ceTO4PAgMBAAGjggHoMIIB5DAfBgNVHSMEGDAWgBSCr2yM+MX+ lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQU9tUteyjHW7DsqMhulCpoaT1DlQMwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBL hklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAdBgNVHREEFjAUgRJwZXRlci5sZWlAaWVlZS5vcmcwDQYJKoZIhvcNAQELBQADggEBAHBU iY1f7LKqo0sQAs/YRvlvL2ydz+9oCDf6BNnyTjDXOiET4D2t5kMh0fceGKhlpfAOA47Nob1s MNS+6sjOqEm8e10SjVv69dq6ZmjFVqTZ1MZjt1Mmi7XpsNYiLE66dF9Ff0ne8bHhcqHVHtFT 6MU7Fq1N8r5mnqCB7zPxuDYV9DprrnOYm2g68CRVGsKhH5kYSsYogMQpxgZ5PP0gdnpfKV+X ROtXTpZg4Ln6WCaeGh5oVdCw095af07hIG8F9VM559N8jv4Z9/R5MsrM6AfwJvXmVUQ9XGKk qZw0MUbf8FQCS928I3h111Ur5zap+rXiu+lJ4cI6T6/h3p3TdCswggXmMIIDzqADAgECAhBq m+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00 SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0 RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq 8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmO upyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOC ATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM +MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEE ZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRU cnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqG SIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxC DBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt /eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77 ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT 3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWB f/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5I SYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwxCTP9 bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S /GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDgwggQ0AgEBMIGt MIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQH EwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RP IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAObkW0+X TtjY4tD9nd86bEgwDQYJYIZIAWUDBAIBBQCgggJbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIyMDAwMTEyMVowLwYJKoZIhvcNAQkEMSIEICpkMtPv XXhLW5QDvkphJW+JQX+NL4OGTYVNXyJYkPhpMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDm5FtPl07Y2OLQ /Z3fOmxIMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDm5FtPl07Y2OLQ/Z3fOmxIMA0GCSqGSIb3DQEBAQUA BIIBAG29u94sovc1bru2YGyGrmoBF7ynrt+ggZ3QgDAU53dlybVTigy7BmnlY5vjDsiJomeI LB/pkaHED84rYaH/GTJVwxYf5U9SXk409ysK2pcdpfKRn/bsj7B/iIjArsExDsKmnQM+3/EG HhQGRhLucekfBttC0u3DB4PXMDBDaMaAfMBqbCzlHVW5h7cjwY3eoQg9RWj2KdRaFGUWerbN 1fJOLqjyZQ0p5V9vnY2PVZoap/Od/ST6uTgESbRAfr/3/ZQ1iNFew+1VR4IeIyajLX381iMj son/dSZbU32Zu0SkAzLQxjGCIBV98Fh8a/bQVrsE5XYBUl6qrzRzQ1S8SxQAAAAAAAA= --------------ms030509060902050606050201-- From owner-freebsd-current@freebsd.org Tue Feb 20 02:07:35 2018 Return-Path: Delivered-To: freebsd-current@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 4A4A8F17EC2 for ; Tue, 20 Feb 2018 02:07:35 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.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 BC13E79739; Tue, 20 Feb 2018 02:07:34 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id x196so1991849lfd.12; Mon, 19 Feb 2018 18:07:34 -0800 (PST) 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:content-transfer-encoding; bh=cBZD0BWwlWe/lzm4EzdeHOYII18y0Rw12+CRy2ljb70=; b=EaE9GMHsT12x08PYmTSYr7+gtuHLBoydMhxxo9RsVgOeQnq3anA4NFvq7589rqbtnv obZeIi9+v85GXbj1zALisZ3G2WmgPFtcX9J3xEA/z7hA4u8/twvkheSImlD2YW5FniPf Vn7bjXTKv5oPcuBc3SP2TCpxf/660dKEiEJKpIJYmP5a+yiB6oBHnOhep/gNGeJGIkOh LjTedSI8lLcSRHH3F85tNmz7rCab0tFUB31XgdsBwn0kcUW0X2Ozf5NP7E/mZTfSvcay +KxDGtbHfa+0y8WV7CHeJrMFgcmdJ3lpJf1WaHKdwXRorVIVdIRwC4bjiWvLcJPN+l/C ME5Q== X-Gm-Message-State: APf1xPDlziU4hoEiwweiLjeVP7sdn4D9SqXayAPV6onuprvfvDsMsKSp OIX1uE8B8+BFUyFox496nePESQQj X-Google-Smtp-Source: AH8x224Ujq0OZlkCarLUve3Lexh4ddQvBuhjJBK5RyvAHhd7vyHO8EeLsPHUWvK0pYD9/cuoT83xbA== X-Received: by 10.25.158.67 with SMTP id h64mr11554380lfe.56.1519092452968; Mon, 19 Feb 2018 18:07:32 -0800 (PST) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com. [209.85.215.42]) by smtp.gmail.com with ESMTPSA id c123sm5234718lfc.94.2018.02.19.18.07.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 18:07:32 -0800 (PST) Received: by mail-lf0-f42.google.com with SMTP id r80so2008346lfe.13; Mon, 19 Feb 2018 18:07:32 -0800 (PST) X-Received: by 10.25.196.66 with SMTP id u63mr10456702lff.108.1519092451879; Mon, 19 Feb 2018 18:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Mon, 19 Feb 2018 18:07:11 -0800 (PST) In-Reply-To: <5bea1c92-0ae9-7acb-d806-b7d7623658e1@ieee.org> References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <5bea1c92-0ae9-7acb-d806-b7d7623658e1@ieee.org> From: Kyle Evans Date: Mon, 19 Feb 2018 20:07:11 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Peter Lei Cc: FreeBSD Current , Devin Teske , =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 02:07:35 -0000 gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei wrot= e: > > > On 2/19/18 5:48 PM, Kyle Evans wrote: >> >> >> On Feb 19, 2018 5:44 PM, "Peter Lei" > > wrote: >> >> >> >> On 2/19/18 2:21 PM, Kyle Evans wrote: >> > Hello! >> > >> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor >> > wrote: >> >> I have done a full build of r329555 to test the new Lua boot load= er. >> >> >> >> Both the new and the old kernels panic after being loaded with: >> >> >> >> panic: running without device atpic requires a local APIC >> >> >> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in >> a previous >> >> message: >> >> >> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/06= 8497.html >> >> >> >> >> OK show hint.acpi.0.disabled >> >> 1 >> >> >> >> Setting ACPI to On resolves the issue. >> > >> > As David noted, this should actually Just Work (TM) now. Can you b= reak >> > into a loader prompt with just the forth loader and tell me what "= show >> > hint.acpi.0.rsdp" looks like? >> >> >> This doesn't appear to "just work out-of-the-box" yet when EFI booti= ng >> amd64, as I still get the 'no local APIC' panic (I just tried @r3296= 09). >> >> Under EFI and lua loader, the following is set when breaking to prom= pt: >> hint.acpi.0.disabled=3D1 >> Under forth loader, this is not present/set. >> >> In neither case is hint.acpi.0.rsdp present/set as that appears to g= et >> set during the exec of the loaded kernel... >> >> I've worked around the issue by adding hint.acpi.0.disabled=3D"0" to >> loader.conf (or patching the amd64 efi loader code to explicitly cle= ar >> that hint). >> >> >> [Apologies for broken quoting, currently mobile] >> >> What happens if you patch this line out? >> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=3Dmarkup#l2= 33 > > > Ah, right - yep, commenting out that line works. > This should be fixed as of r329614. hint.acpi.0.rsdp gets set upon exec of the loaded kernel in the EFI world, then in i386 world it's before lualoader comes into play. We should probably do as forth does and disable ACPI stuff on !i386 (IIRC the option disappears completely), but IIRC we haven't yet exposed TARGET/TARGET_ARCH to lua. From owner-freebsd-current@freebsd.org Tue Feb 20 02:23:54 2018 Return-Path: Delivered-To: freebsd-current@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 B94C7F19F89 for ; Tue, 20 Feb 2018 02:23:54 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.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 5698F7A637; Tue, 20 Feb 2018 02:23:54 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [172.58.145.77] (port=49224 helo=[IPv6:2607:fb90:58f7:47fc:d1cc:63a6:1309:bd22]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1enwNk-000Cfn-Ma; Tue, 20 Feb 2018 01:06:09 +0000 Mime-Version: 1.0 (1.0) Subject: Re: ACPI panic on boot with new Lua loader and other minor issues From: Devin Teske X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 19 Feb 2018 20:23:47 -0600 Cc: Kyle Evans , =?utf-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current , dteske@FreeBSD.org Message-Id: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> To: Warner Losh Sender: devin@shxd.cx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 02:23:55 -0000 > On Feb 19, 2018, at 4:32 PM, Warner Losh wrote: >=20 >=20 >=20 >> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >>=20 >>=20 >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing something sneaky and >> > replacing the standard common "boot" with a Forth boot that handles >> > this a lot better. CC'ing dteske@ so they can confirm. >>=20 >> I can indeed confirm this as fact. >>=20 >> Not able to help much because I am driving cross-country (San Francisco t= o Orlando) right now with the spouse and dog. >>=20 >> We get back March 3rd, but I will be checking-in from time to time for sp= oradic responses during downtime. >=20 > The command in loader.4th is defined as: >=20 > : boot > 0=3D if ( interpreted ) get_arguments then >=20 > \ Unload only if a path was passed > dup if > >r over r> swap > c@ [char] - <> if > 0 1 unload drop > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > load_kernel_and_modules > ?dup 0=3D if bootmsg 0 1 boot then > ;=20 >=20 > The thing to know here is when you see 'boot' as part of above script, it'= s calling the 'boot' cli command, not itself recursively. >=20 What is actually going on is that when the =E2=80=9Cboot=E2=80=9D function i= s compiled, the reference to =E2=80=9Cboot=E2=80=9D inside it is to the alre= ady-existing word defined previously. Forth allows you to have multiply-defi= ned names. The =E2=80=9Cboot=E2=80=9D command inside the =E2=80=9Cboot=E2=80= =9D function is replaced with the address of previous boot during function c= ompilation because the function is m not defined and given an address in the= dictionary until it is completed (last line compiled). =E2=80=94=20 Devin= From owner-freebsd-current@freebsd.org Tue Feb 20 03:05:12 2018 Return-Path: Delivered-To: freebsd-current@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 C4322F1DFC0 for ; Tue, 20 Feb 2018 03:05:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 53FFD7C696 for ; Tue, 20 Feb 2018 03:05:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id l12so7629299ioc.10 for ; Mon, 19 Feb 2018 19:05:11 -0800 (PST) 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=P4868rLOMeGfuUo7e2SGDb9dLz7J/ksTdqlS1zYom/Q=; b=Y97DbwKDE6u6sY6lQZo8nyos6kQdbWwIQw2pzmxXgQTxYFw/jM3d5l3hJ8TB4KXC9T ZMBAhFVj4+xaU0hBwR/rZ7q3Mq9Q4xZycU8gscnGyDv6a7Qud95qwYjtHk2YqB3k+Wyz QbOa/O6stcQHs6ZXzFS3lcBgRPOdrHIeV0IPU0WjuF7Xu6p01yD2qzjU6lH5xBF5vUTY tDgiucrO2iKbkRylpgsKJXVC4TxlhFsuOjv6Ip8sZFXpe/kwp1FIo4UFCqn6d6XkM2aq sXW7LJN+lOWTdsonHX/WPUaD8SbSLpdTJ1r8W2kVI8S8rsa6cqFjOBZ1NA7ilgjHqmr6 fusA== 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=P4868rLOMeGfuUo7e2SGDb9dLz7J/ksTdqlS1zYom/Q=; b=l07qzcfuOVaOotwbnnDwqEBd6CTTYWUD7RhD+ap4vbWsg9gAxjfTcD5o3Q9n6RhCzO i+XdGDpUSPViAT90F53FZigF7Cf3kWtVrC/VKA0lLXdEcUW9+MpB+tVPEA1ArnoQsGqB KKy7hzSjS7oJtMkP7rAIwqo+HNUUHY1oMSnBgSTOHEMa+RLaOkaU3Mol1WPXrcUIKJkB XAHBpfKNJh51qIciE6wKl/M6T5TTZPMas3iKJxJ4/L/T6g+7h9W1mCoh2anIpM19bKTF fCzajpdnO9vhgM2xlN2Ln6jh/RxYD0YI839Z1X3W3kxXUOQWsPNIeMLdy3jucKbtZNnj 101Q== X-Gm-Message-State: APf1xPAF1+dGkcVvjoQxcwiLR9GVKs/wkhCKdJbXiy1VrGuYiw7OXF0/ oLu6sWqPYJHhpaDG+S1mz4XA1Eua//bOH5tRHi4L5Q== X-Google-Smtp-Source: AH8x226MxjSYOeu7tdB3TF7f9BSFOa01Y6j6TiecvXx8phaDFjiA7sy9Sz0o918lAmnVccFaAX2Kg7cmlXHVOnGdJSs= X-Received: by 10.107.188.65 with SMTP id m62mr21485608iof.39.1519095910507; Mon, 19 Feb 2018 19:05:10 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Mon, 19 Feb 2018 19:05:09 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:9198:c568:89aa:9c67] Received: by 10.79.201.67 with HTTP; Mon, 19 Feb 2018 19:05:09 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> <6EB9705C-92AC-4952-B1F6-642DCD4701F1@freebsd.org> From: Warner Losh Date: Mon, 19 Feb 2018 20:05:09 -0700 X-Google-Sender-Auth: TDo-xWlxLQ81mF24Zdth5kLtl3M Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans Cc: Devin Teske , =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 03:05:12 -0000 On Feb 19, 2018 3:38 PM, "Kyle Evans" wrote: On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh wrote: > > > On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske wrote: >> >> >> >> > On Feb 19, 2018, at 2:21 PM, Kyle Evans wrote: >> > >> > It seems that the Forth loader might be doing something sneaky and >> > replacing the standard common "boot" with a Forth boot that handles >> > this a lot better. CC'ing dteske@ so they can confirm. >> >> I can indeed confirm this as fact. >> >> Not able to help much because I am driving cross-country (San Francisco to >> Orlando) right now with the spouse and dog. >> >> We get back March 3rd, but I will be checking-in from time to time for >> sporadic responses during downtime. > > > The command in loader.4th is defined as: > > : boot > 0= if ( interpreted ) get_arguments then > > \ Unload only if a path was passed > dup if > >r over r> swap > c@ [char] - <> if > 0 1 unload drop > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > else > s" kernelname" getenv? if ( a kernel has been loaded ) > try-menu-unset > bootmsg 1 boot exit > then > load_kernel_and_modules > ?dup if exit then > try-menu-unset > bootmsg 0 1 boot exit > then > load_kernel_and_modules > ?dup 0= if bootmsg 0 1 boot then > ; > > The thing to know here is when you see 'boot' as part of above script, it's > calling the 'boot' cli command, not itself recursively. > > I can help do more interpretation of the details if you need Kyle. Not sure > how much to spell out, but the brief pseudo code is: > > If there were any arguments that didn't start with '-', unload. > otherwise if kernelname is in in the environment, run the 'menu-unset' > forth word if it exists, print the boot message and boot. > Otherwise load the kernel and modules, run the 'menu-unset' forth word (if > it exists), print the boot message and boot with kernelname > Otherwise load the kernel and modules, run the 'menu-unset' forth word (if > it exists), print the boot message and boot with kernelname > if all that fails, load the kernel and modules and if that works boot them. > Yeah, we have something like this on the lua side. Unfortunately, it's going to wreck people's muscle memory- dropping to the loader prompt and typing "boot [x]" will never work as expected because lua won't recognize that as a function call due to spaces as delimiters. We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])" (for some [x] that could be multiple space-delimited arguments) before falling back to the originally typed "cmd [x]" if we want Lua to have any chance to intercept it and adds its own salt and pepper like Forth does. Forth has a framework for making all commands forth words. It leverages that to run the intercept. We already have the intercept in place with a stupidly simple policy. We totally can do something generic that would solve this and maybe other problems. Let's chat online tomorrow about a couple of possibilities we can choose from. Warner From owner-freebsd-current@freebsd.org Tue Feb 20 05:07:16 2018 Return-Path: Delivered-To: freebsd-current@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 5A370F01FF4 for ; Tue, 20 Feb 2018 05:07:16 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 A89E68235F for ; Tue, 20 Feb 2018 05:07:15 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id v9so2385426lfa.11 for ; Mon, 19 Feb 2018 21:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uiIzA/dYkYBFRxxXFMFgfbwos0AIR+J+4XJZdGbcrCQ=; b=VMO5OZ+qdzXVfWCHlc2hLpKqJ04b+xPApezcuWusMa5HAoTrrq1h1syxEB4FynvWWc aFVRPDNs5jzsEMPznEB0q4YMacqrLKCc5yMGWaF2TdcTxluCkr+B/7PM4r4LRKGNrlJx V+hRdFPjPZYm0RwvGMQGNBxtxEk6wkcNTB5zJCbq8+QBB0WcsVY59b+H5JC8qcHqT/p6 G5+PafoYwJhaNiuRz9jMagwXZ7pjgk0H1WdKVM0UlK299Sf+gGWhr6/PXuJz9Sk/07Iw 4a40TEismp/qVozbPNX8yndmcXamI0A5DSCFX+bTJDShegrnn9g95Ukbq2GK9oxATtN2 QWEg== 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=uiIzA/dYkYBFRxxXFMFgfbwos0AIR+J+4XJZdGbcrCQ=; b=Vtoc+w7Ta17bECEdYExEqXAROk4WsnICHY+S+bj0t65VOuc6jZtmWhZ+zmFctPTf3X sJEjvknfGgGIYsT2PVDrCsX4lq9EOiaqVd0yvCq3ERUJn8ySDcUpHPxKg3sc/jz4saBe cL0RHKsQdcXBEKV7EBwoAgvY+Z5QzUt2iszL2Yly1b2NktXE2SKchjm0Wm5OZ2/bMEiD S1Nni19ZAVPsO1Xxz4NHhilf/hwmoNtWgDtcjmbwzG3wIaXjP6oAmhlNqamVWr05Y/Wn 8bWeMIBYEM+iZX0ORfJmu/HvOWEz1eDY5+Y3A8+Rv5UirAFXHZWCcGsfl4XzKZ64dnFb lVig== X-Gm-Message-State: APf1xPD2uwQvMPLirJId4iF+ENWn28hfk7TEhiCTjdBo5Za9H2f8+EXH zp8BVCa2u7qUiPzif2gv01VzjGWxBtbMN0CiGG0= X-Google-Smtp-Source: AH8x2270oYAjbyp7KwdXiK7ev0yTvL3VjGJ4ZXhC221wxRVFR7nlHbyeu2CvyoJYVXWEXSILzyjAz+1gixt2eC1Vf18= X-Received: by 10.25.199.151 with SMTP id x145mr10544155lff.33.1519103233649; Mon, 19 Feb 2018 21:07:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.3.10 with HTTP; Mon, 19 Feb 2018 21:07:12 -0800 (PST) Received: by 10.46.3.10 with HTTP; Mon, 19 Feb 2018 21:07:12 -0800 (PST) In-Reply-To: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> From: Andreas Nilsson Date: Tue, 20 Feb 2018 06:07:12 +0100 Message-ID: Subject: Re: pkg does not recognize correct kernel version To: Ronald Klop Cc: Rainer Hurling , Konstantin Belousov , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 05:07:16 -0000 I think this was worked around in pkg 1.10.5. As a temporary workaround do pkg -o OSVERSION=1200058 update -f pkg upgrade Best regards Andreas On Feb 19, 2018 23:54, "Ronald Klop" wrote: On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov wrote: On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote: > >> Am 19.02.2018 um 21:24 schrieb Ronald Klop: >> > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling >> wrote: >> > >> >> Hi Ronald, >> >> >> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: >> >>> I just did this. >> >>> >> >>> root@sjakie ~]# pkg upgrade >> >>> Updating FreeBSD repository catalogue... >> >>> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> >>> Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 >> >>> Processing entries: 0% >> >>> pkg: Newer FreeBSD version for package gnome-menus: >> >>> - package: 1200058 >> >>> - running kernel: 1200056 >> >>> pkg: repository FreeBSD contains packages for wrong OS version: >> >>> FreeBSD:12:amd64 >> >>> Processing entries: 100% >> >>> Unable to update repository FreeBSD >> >>> Error updating repositories! >> >>> >> >>> [root@sjakie ~]# uname -UK >> >>> 1200058 1200058 >> >>> >> >>> [root@sjakie ~]# uname -a >> >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb >> 18 >> >>> 12:37:36 CET 2018 >>> ronald@sjakie:/data/ronald/obj >> -freebsd-current/data/ronald/freebsd-current/amd64.amd64/ >> sys/GENERIC-NODEBUGamd64 >> >>> >> >>> >> >>> >> >>> So uname gives a different version than pkg detects. >> >>> >> >>> What is happening? pkg update -f gives the same result. -o >> >>> OSVERSION=1200058 helps, but does not feel like the right solution. >> >>> >> >>> Regards, >> >>> Ronald. >> >> >> >> Please try >> >> >> >> #sysctl kern.osreldate >> >> kern.osreldate: 1200058 >> >> >> >> HTH, >> >> Rainer Hurling >> > >> > >> > [root@sjakie ~]# sysctl kern.osreldate >> > kern.osreldate: 1200058 >> > >> > Regards, >> > Ronald. >> >> On my kernel patchlevel 1200058 (r329446) I get: >> >> #pkg update -f >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05 >> Processing entries: 100% >> FreeBSD repository update completed. 28645 packages processed. >> All repositories are up to date. >> >> >> Perhaps more a local problem :( >> > > Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > Which man page? I can't find it in pkg help update or pkg help upgrade or man pkg. version note: > orion% file /bin/ls > /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 > (1101506), FreeBSD-style, stripped > > Update world past the __FreeBSD_version which is reported for the > repository. > Does this mean I always have to do a *clean* buildworld after every version bump? This takes ages. Regards, Ronald. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Feb 20 10:29:50 2018 Return-Path: Delivered-To: freebsd-current@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 C7781F1A088 for ; Tue, 20 Feb 2018 10:29:50 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78A5A6F143 for ; Tue, 20 Feb 2018 10:29:49 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9D62D21AC8 for ; Tue, 20 Feb 2018 05:29:48 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Tue, 20 Feb 2018 05:29:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=e5UB/ldg2Z1n1Vefe8/5Hf2qHx/9R+t8Zj+cnFiHaoM=; b=dxtF22n0 XNqgYnvp+DmUcFy8IN0qOPckAf2mpjAeQCwMH6TxFkodJcVyW8+l+Ipc4r8aH/Y5 JITndsZe56g5F0A0DGbiM6nDZPmLC4eDQU7oSThW6WGOqdYcakAcIdnULa59j/iS WKXKANj5LWo9zZZnRrVrc7pUhPp+o6dQAiDdHMc1Ru5WoNWqexpQuwhw4/TPEQkM wgx+/EHvrrbf+AgVc3+SITzMQ5OhoT25PHCJN1enetyCkrnt7hFmQmmCHe5v9lrF FjIhs8gQhlP5RzC27E57YgZmd5qfAPlWAVRnj+6jjsFdo0/srB0yPx7vNlCluaBM esnkY4XHcsRTFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=e5UB/ldg2Z1n1Vefe8/5Hf2qHx/9R +t8Zj+cnFiHaoM=; b=je6bZ8ADWoWYG+SrYWuWzVJl2ii/vaW7Gw3QLT2bSPtJH Ow+ZdNM7bPHTRwDYhE1tb+R2rYAIVIDwLLHwl5nPAZzRyJiqKfmm+V4BbBi3QZ4e H9Q5CdBE7jNujDz/9Nn3g/xFvTECnCZBuies/NTkHRPw0RoMyIHOqCpgpXVa/iCw DBv5St12a6WBrelnDzZWSPnOI0c4d0YW1vqxn1xxRsdwpeDFemFbBFwS+Ddxvf3z g63/CjwhpLVU4FFaJdKfvh4QJlz5IC8I0Ef5Ytnz7XipobsT5wP7TZEJm0WaY5s7 QbtxFcCzhvawEIV3tqqIu5u1r8cWYJWKzwSn53FDQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7C042410D; Tue, 20 Feb 2018 05:29:48 -0500 (EST) Message-Id: <1519122588.1708441.1276812536.04FE76B5@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1b99b2df Subject: [panic][bhyve] mtx_lock_spin: recursed on non-recursive mutex vcpu lock @ /usr/src/sys/amd64/vmm/vmm.c:2246 Date: Tue, 20 Feb 2018 11:29:48 +0100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:29:51 -0000 # info - 100% reproducible on starting a bhyve-based vm - recent current r329611, also panics at r329531 - GENERIC + WITH_CTF=1 and DEBUG=-g - built WITH_META_MODE=yes & CCACHE_BUILD=yes # panic dmesg [36984] panic: mtx_lock_spin: recursed on non-recursive mutex vcpu lock @ /usr/src/sys/amd64/vmm/vmm.c:2246 [36984] [36984] cpuid = 3 [36984] time = 1519121280 [36984] KDB: stack backtrace: [36984] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe020c272360 [36984] vpanic() at vpanic+0x18d/frame 0xfffffe020c2723c0 [36984] vpanic() at vpanic/frame 0xfffffe020c272440 [36984] __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x148/frame 0xfffffe020c272480 [36984] vcpu_get_state() at vcpu_get_state+0x44/frame 0xfffffe020c2724c0 [36984] vmx_pending_intr() at vmx_pending_intr+0xc6/frame 0xfffffe020c272500 [36984] vm_run() at vm_run+0x759/frame 0xfffffe020c272600 [36984] vmmdev_ioctl() at vmmdev_ioctl+0x86b/frame 0xfffffe020c2726a0 [36984] devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfffffe020c2726f0 [36984] VOP_IOCTL_APV() at VOP_IOCTL_APV+0xd9/frame 0xfffffe020c272720 [36984] vn_ioctl() at vn_ioctl+0x124/frame 0xfffffe020c272830 [36984] devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfffffe020c272850 [36984] kern_ioctl() at kern_ioctl+0x2b9/frame 0xfffffe020c2728b0 [36984] sys_ioctl() at sys_ioctl+0x15c/frame 0xfffffe020c272980 [36984] amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe020c272ab0 [36984] fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffdddecee0 [36984] KDB: enter: panic # debugger db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks db:1:locks> show alllocks db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 3 dynamic pcpu = 0xfffffe0084b95800 curthread = 0xfffff8017ad76560: pid 12951 tid 103324 "vcpu 0" curpcb = 0xfffffe020c272b80 fpcurthread = none idlethread = 0xfffff8010764f560: tid 100006 "idle: cpu3" curpmap = 0xfffff80dbaba5130 tssp = 0xffffffff81d8bfd8 commontssp = 0xffffffff81d8bfd8 rsp0 = 0xfffffe020c272b80 gs32p = 0xffffffff81d92c10 ldt = 0xffffffff81d92c50 tss = 0xffffffff81d92c40 curvnet = 0 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 12951 tid 103324 td 0xfffff8017ad76560 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe020c272360 vpanic() at vpanic+0x1aa/frame 0xfffffe020c2723c0 vpanic() at vpanic/frame 0xfffffe020c272440 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x148/frame 0xfffffe020c272480 vcpu_get_state() at vcpu_get_state+0x44/frame 0xfffffe020c2724c0 vmx_pending_intr() at vmx_pending_intr+0xc6/frame 0xfffffe020c272500 vm_run() at vm_run+0x759/frame 0xfffffe020c272600 vmmdev_ioctl() at vmmdev_ioctl+0x86b/frame 0xfffffe020c2726a0 devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfffffe020c2726f0 VOP_IOCTL_APV() at VOP_IOCTL_APV+0xd9/frame 0xfffffe020c272720 vn_ioctl() at vn_ioctl+0x124/frame 0xfffffe020c272830 devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfffffe020c272850 kern_ioctl() at kern_ioctl+0x2b9/frame 0xfffffe020c2728b0 sys_ioctl() at sys_ioctl+0x15c/frame 0xfffffe020c272980 amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe020c272ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffdddecee0 db:0:kdb.enter.panic> ps pid ppid pgrp uid state wmesg wchan cmd 18384 99134 12632 1002 S+ select 0xfffff80152b4e9c0 ssh 12951 53776 53776 0 R+ (threaded) bhyve 101692 S kqread 0xfffff81c41243400 mevent 102880 S uwait 0xfffff80d4915e500 blk-3:0:0-0 102881 S uwait 0xfffff8025b2c5800 blk-3:0:0-1 102982 S uwait 0xfffff802d198b680 blk-3:0:0-2 102985 S uwait 0xfffff8015fdb6a00 blk-3:0:0-3 102988 S uwait 0xfffff80721bbab00 blk-3:0:0-4 102990 S uwait 0xfffff806a1161b00 blk-3:0:0-5 102994 S uwait 0xfffff8010a0db480 blk-3:0:0-6 103009 S uwait 0xfffff80aae76f700 blk-3:0:0-7 103016 S uwait 0xfffff8073b79d980 blk-4:0-0 103018 S uwait 0xfffff8010a0d8900 blk-4:0-1 103020 S uwait 0xfffff80618184780 blk-4:0-2 103022 S uwait 0xfffff802d198ba00 blk-4:0-3 103024 S uwait 0xfffff807ac4e2800 blk-4:0-4 103320 S uwait 0xfffff807ac4e2180 blk-4:0-5 103321 S uwait 0xfffff8015fdb5b80 blk-4:0-6 103322 S uwait 0xfffff807473e9900 blk-4:0-7 103323 S uwait 0xfffff80721c41b80 vtnet-5:0 tx 103324 Run CPU 3 vcpu 0 100505 Run CPU 11 vcpu 1 53776 38209 53776 0 Ss+ wait 0xfffff80d4942da70 sh 38209 1 38209 0 Ss select 0xfffff80cca99d940 tmux ... # head of dmesg FreeBSD 12.0-CURRENT #6 r329611+f65afb3cfe82(master): Mon Feb 19 23:19:01 UTC 2018 root@wintermute:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 6.0.0 (branches/release_60 325330) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1280x1024 module_register: cannot register mmc/mmcsd from kernel; already loaded from mmcsd.ko Module mmc/mmcsd failed to register: 17 CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz (3200.07-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 137434759168 (131068 MB) avail memory = 133684940800 (127491 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) x 2 hardware threads ... BTW I've been running CURRENT for a while now but just starting out reporting any panics that hopefully aren't due to my errors/omissions. Tips for making these reports more useful are welcomed. A+ Dave From owner-freebsd-current@freebsd.org Tue Feb 20 10:31:04 2018 Return-Path: Delivered-To: freebsd-current@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 F2889F1A1C2 for ; Tue, 20 Feb 2018 10:31:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D6216F37C for ; Tue, 20 Feb 2018 10:31:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1KAUqSd018209 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 20 Feb 2018 11:30:53 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1KAUq14018206 for ; Tue, 20 Feb 2018 11:30:52 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 20 Feb 2018 11:30:52 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: pkg does not recognize correct kernel version In-Reply-To: Message-ID: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:31:04 -0000 On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > Does this mean I always have to do a *clean* buildworld after every version > bump? This takes ages. Yes, I've come to the conclusion that whenever __FreeBSD_version in sys/sys/param.h is incremented, then it's time to blow away /usr/obj, recreate everything to ensure the correct value of osversion in the .note.tag section of each executable, and reinstall base prior to updating localbase. See PR 225104 for more details, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104. -- Trond. From owner-freebsd-current@freebsd.org Tue Feb 20 11:40:03 2018 Return-Path: Delivered-To: freebsd-current@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 7F44DF20944 for ; Tue, 20 Feb 2018 11:40:03 +0000 (UTC) (envelope-from gljennjohn@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 E7F667203D for ; Tue, 20 Feb 2018 11:40:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id w77so13431296wrc.6 for ; Tue, 20 Feb 2018 03:40:02 -0800 (PST) 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=i9Jf3FI2beC7m+a0ahXmcUHvEvEjoudbh7NXRZ+AXWY=; b=DWg5YCUNkf05YOgPwcKyKHw5OGr+xHHSvovnaHp//RpxsM5PNVNTV8UUrgapk4WNZM CSoyielygzFIxmOE3kk/a3uxd4roNcVuf/u380IIJYJgEzRhac9iXcOCj+4VxRQDw4bp qkpKT+yL0kUKWsFj3Ss/6nc+C7wToMWF5abzwod0cRZBT5K/ojueFr6LvAEY7+kmYAPW 5KrX/UTRQTche9So9u4jcMVQXNdIgy4whcvy1mqg7MLNA3RUQqhGSW6kcXXrBqLKpQm5 DWerTPQ9Wdc/hS2OSG7ohNmf0T0I0v3JC4fj6poAc61o5PssMEovKVSElpgEpbqT2RtA CujA== 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=i9Jf3FI2beC7m+a0ahXmcUHvEvEjoudbh7NXRZ+AXWY=; b=CjSJXhwUT4VYLg72xBpmDgFMskCR3fjjxDnAYzk4eAcRKcfv1SwqWxPDFKWzCe8LVt Y0j3Hd2FiC3hzV8ejq0KrMYrkycYV4X+W9Lb/JY9IhHz0puINcPnsDYA/ST8OoaWZH76 uIgmBZk6g+K4NxpCaFugE5DI4EmEoeQ51i3ryTRcBoOSXWESl1Jzn90q+w5sY0OFjll1 QoABPMntmMMCcm/lK26g0E20fO1MUq8s+UJSL/SJyyGkcjZLgvRV7jA2DnCxdwKASSbN pq6jyA/f0vUO5IQ/0E1L6N/kqe74/ZvZRtkWIa80n/3qCN5PV9kuujVeRumqMX3kV9Bk LUcg== X-Gm-Message-State: APf1xPBmu/miLcHnigQKnYvcRLN/9Og4ZuQuGukcRbn2N7IDjDBmH00f /l93JkiAJnGPOYRGQCnSH0KWBw== X-Google-Smtp-Source: AH8x226MYlyI9p8NkkMNnmyib7fXpL5ZuY4fpY+zQ2MxL+8Kf6cGIewNF2W6rnAaEmWOmgulvsSi8w== X-Received: by 10.223.128.104 with SMTP id 95mr17003314wrk.139.1519126801598; Tue, 20 Feb 2018 03:40:01 -0800 (PST) Received: from ernst.home (p5B0232AA.dip0.t-ipconnect.de. [91.2.50.170]) by smtp.gmail.com with ESMTPSA id p60sm16942423wrc.88.2018.02.20.03.39.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Feb 2018 03:40:00 -0800 (PST) Date: Tue, 20 Feb 2018 12:39:53 +0100 From: Gary Jennejohn To: "Chris H" Cc: "FreeBSD Current" Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Message-ID: <20180220123953.5e987691@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 11:40:03 -0000 On Mon, 19 Feb 2018 14:18:15 -0800 "Chris H" wrote: > I'm seeing a number of messages like the following: > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > and was wondering if it's anything to be concerned with, or whether > fsck(8) is fixing them. > This began to happen when the power went out on a new install: > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST 2017 > root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > which hadn't yet been hooked up to the UPS. > I performed an fsck in single user mode upon power-up. Which ended with the > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL. > I answered Y. > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: > newfs -U -j > > Thank you for all your time, and consideration. > fsck fixes these errors only when the user does NOT use the journal. You should re-do the fsck. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue Feb 20 11:40:28 2018 Return-Path: Delivered-To: freebsd-current@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 D3862F209C3 for ; Tue, 20 Feb 2018 11:40:27 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 4BC7F7207E for ; Tue, 20 Feb 2018 11:40:27 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id u15so13459926wrg.3 for ; Tue, 20 Feb 2018 03:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zNa3f8ea7Dcd3n+vSVYb1+iAVNeb9+MGpskpyBxWteQ=; b=pCM48jbmH5hwxkH/+J5jQk0ahMsiwd52HKZDUBK79A0/jRFbR0pOL+YuXtnxJNit6n b08JWOvoj+F1YEDrx3eNPOxLAWMr7o+9fphxpgVunLr7apdYUi0sEaTxaMINVh9TtjeF Sk+RgrkduC7CH1MbxJbh3D2ajiEtqhLbcvvgRE6F+FwnYanYW5lRpEzeyTmZSbn/o05r KvrHnEQAe1dEQFvWFSBSTAT6aVW5VFZRrV4EFrk+BxLcyXLwtfun8FM0EUucMJG5uVIU QfoPLMRuoOs0Ox4/peKCKQf7PwVmRqtke5hG6rQFVzV/XD2qnldm9fPmBKOvMT1lcGi9 bqRg== 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=zNa3f8ea7Dcd3n+vSVYb1+iAVNeb9+MGpskpyBxWteQ=; b=WPWqeh1KV63LlEbjKAoUuelH5T4JDtsiwc/PfcQW7qOn63hwufWyDmm1ZLAxhgKHzm eGLQDrKfayblSJSB4WA8lWFsLq1qBcFpn4w8yJCQ18K7TW9XDZQUKyH3/NW2mLQzPAvx WLoQ132WhNkV6HclVPATR9coDdFp//5IqOUtHpP42erfhExjor5gx57d0v9uS+xLARej gq2xj2ZPPpR9NO30Dgn++4uDY6pcS7uNGpLfumeW+ZkA3JA1v1xlnan2V7Phyo5OxuNr Cv/z+o/yCQerPhI8LwGXamEFtO5e4qyHuy74WLsolfPh6LPgZliquA+2+xs4NRYgFm42 cYow== X-Gm-Message-State: APf1xPACfYnb2NMUPwK3Ft3WYw6SaHzMtkh3F7en8QZtsgkRnlmxwbLy LNm9ZEN3URqymI43TAsCC/o0JP1cXg3wxOk4ubUkAQ== X-Google-Smtp-Source: AH8x227UyfbGHqPWqwY2yiLK3HPrXrzQCuAm6oGoZxM1BgsjRRh5jRfzewPoY3QK34/KnEuLwjNSb0RpRodp1eupNww= X-Received: by 10.28.66.199 with SMTP id k68mr14495855wmi.104.1519126825675; Tue, 20 Feb 2018 03:40:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.68 with HTTP; Tue, 20 Feb 2018 03:39:45 -0800 (PST) From: Johannes Lundberg Date: Tue, 20 Feb 2018 11:39:45 +0000 Message-ID: Subject: Recent world+kernel has broken Linux 3D apps? To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 11:40:28 -0000 Before rebuilding world my system was running Linux games fine with a couple of months old world/kernel and drm-next-kmod. Since updating world+kernel last week all Linux 3D apps fail (native binaries like glxgears and supertuxkart works fine). linux-c6/c7, intel/modesetting, does no difference This is on Dell Intel Broadwell laptop. Doom 3 fail like this: ----- R_ReloadARBPrograms ----- glprogs/test.vfpsignal caught: Segmentation fault si_code 1 Trying to exit gracefully.. And glxgears (in /compat/linux/usr/bin/) johannes@jd2:~ % /compat/linux/usr/bin/glxgears Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be broken. libdrm aub dumping is deprecated. Use intel_aubdump from intel-gpu-tools instead. Install intel-gpu-tools, then run (for example) $ intel_aubdump --output=trace.aub glxgears -geometry 500x500 See the intel_aubdump man page for more details. bo_create: buf 1 (swizzle test) 32768b bo_unreference final: 1 (swizzle test) libGL: Can't open configuration file /home/johannes/.drirc: No such file or directory. intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject bo_create: buf 1 (transform feedback offsets) 16b bo_create: buf 2 (xfb primitive counts) 4096b intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject intelNewTextureObject Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable libGL: Can't open configuration file /home/johannes/.drirc: No such file or directory. bo_create: buf 3 (batchbuffer) 32768b drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 bo_map: 3 (batchbuffer), map_count=1 bo_map: 3 (batchbuffer) -> 0x1000 bo_create: buf 4 (pipe_control workaround) 4096b bo_create: buf 5 (program cache) 4096b drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 bo_map_gtt: mmap 5 (program cache), map_count=1 intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid argument . drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 bo_create: buf 6 (shader time) 393216b bo_create: buf 7 (bufferobj) 65536b enter intel_update_renderbuffers, drawable 0x614b80 enter intel_update_dri2_buffers, drawable 0x614b80 attaching buffer 3, at 1, cpp 4, pitch 1536 bo_create_from_handle: 3 (dri2 back buffer) intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210 intel_miptree_set_level_info level 0, depth 1, offset 0,0 intel_miptree_set_total_width_height: 300x300x4 intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: MESA_FORMAT_Z24_UNORM_X8_UINT (300x300) intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440 intel_miptree_set_level_info level 0, depth 1, offset 0,0 intel_miptree_set_total_width_height: 300x300x4 bo_create: buf 9 (miptree) 409600b bo_create: buf 10 (hiz) 98304b mt 0x778440 level 0: HiZ enabled intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: MESA_FORMAT_S_UINT8 (300x300) intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_S_UINT8 level 0..0 slices 1 <-- 0x778890 intel_miptree_set_level_info level 0, depth 1, offset 0,0 intel_miptree_set_total_width_height: 300x304x1 bo_create: buf 11 (miptree) 102400b Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. bo_create: buf 12 (bufferobj) 32768b drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 bo_map_gtt: mmap 12 (bufferobj), map_count=1 intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid argument . drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 Segmentation fault (core dumped) From owner-freebsd-current@freebsd.org Tue Feb 20 12:57:46 2018 Return-Path: Delivered-To: freebsd-current@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 7AC37F2716D for ; Tue, 20 Feb 2018 12:57:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A76175B97 for ; Tue, 20 Feb 2018 12:57:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B9A0E2603CD; Tue, 20 Feb 2018 13:57:44 +0100 (CET) Subject: Re: Recent world+kernel has broken Linux 3D apps? To: Johannes Lundberg , freebsd-current References: From: Hans Petter Selasky Message-ID: <25f3a769-b1dd-9531-c87f-20a5f7b73ff3@selasky.org> Date: Tue, 20 Feb 2018 13:57:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 12:57:46 -0000 On 02/20/18 12:39, Johannes Lundberg wrote: > Before rebuilding world my system was running Linux games fine with a > couple of months old world/kernel and drm-next-kmod. > > Since updating world+kernel last week all Linux 3D apps fail (native > binaries like glxgears and supertuxkart works fine). > > linux-c6/c7, intel/modesetting, does no difference > This is on Dell Intel Broadwell laptop. > > Doom 3 fail like this: > > ----- R_ReloadARBPrograms ----- > glprogs/test.vfpsignal caught: Segmentation fault > si_code 1 > Trying to exit gracefully.. > > > And glxgears (in /compat/linux/usr/bin/) > > johannes@jd2:~ % /compat/linux/usr/bin/glxgears > Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be > broken. > Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be > broken. > Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be > broken. > Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be > broken. > Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be > broken. > libdrm aub dumping is deprecated. > > Use intel_aubdump from intel-gpu-tools instead. Install intel-gpu-tools, > then run (for example) > > $ intel_aubdump --output=trace.aub glxgears -geometry 500x500 > > See the intel_aubdump man page for more details. > bo_create: buf 1 (swizzle test) 32768b > bo_unreference final: 1 (swizzle test) > libGL: Can't open configuration file /home/johannes/.drirc: No such file or > directory. > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > bo_create: buf 1 (transform feedback offsets) 16b > bo_create: buf 2 (xfb primitive counts) 4096b > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > intelNewTextureObject > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn > compression/decompression unavailable > libGL: Can't open configuration file /home/johannes/.drirc: No such file or > directory. > bo_create: buf 3 (batchbuffer) 32768b > drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 > bo_map: 3 (batchbuffer), map_count=1 > bo_map: 3 (batchbuffer) -> 0x1000 > bo_create: buf 4 (pipe_control workaround) 4096b > bo_create: buf 5 (program cache) 4096b > drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 > bo_map_gtt: mmap 5 (program cache), map_count=1 > intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid > argument . > drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 > bo_create: buf 6 (shader time) 393216b > bo_create: buf 7 (bufferobj) 65536b > enter intel_update_renderbuffers, drawable 0x614b80 > enter intel_update_dri2_buffers, drawable 0x614b80 > attaching buffer 3, at 1, cpp 4, pitch 1536 > bo_create_from_handle: 3 (dri2 back buffer) > intel_miptree_create_layout target GL_TEXTURE_2D format > MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210 > intel_miptree_set_level_info level 0, depth 1, offset 0,0 > intel_miptree_set_total_width_height: 300x300x4 > intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: > MESA_FORMAT_Z24_UNORM_X8_UINT (300x300) > intel_miptree_create_layout target GL_TEXTURE_2D format > MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440 > intel_miptree_set_level_info level 0, depth 1, offset 0,0 > intel_miptree_set_total_width_height: 300x300x4 > bo_create: buf 9 (miptree) 409600b > bo_create: buf 10 (hiz) 98304b > mt 0x778440 level 0: HiZ enabled > intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: > MESA_FORMAT_S_UINT8 (300x300) > intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_S_UINT8 > level 0..0 slices 1 <-- 0x778890 > intel_miptree_set_level_info level 0, depth 1, offset 0,0 > intel_miptree_set_total_width_height: 300x304x1 > bo_create: buf 11 (miptree) 102400b > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > bo_create: buf 12 (bufferobj) 32768b > drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 > bo_map_gtt: mmap 12 (bufferobj), map_count=1 > intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid > argument . > drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 > > > Segmentation fault (core dumped) Can you compare the debug prints with working version? --HPS From owner-freebsd-current@freebsd.org Tue Feb 20 13:04:41 2018 Return-Path: Delivered-To: freebsd-current@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 5EC6DF27999 for ; Tue, 20 Feb 2018 13:04:41 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 E3DB076224 for ; Tue, 20 Feb 2018 13:04:40 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id f14so9722387wre.8 for ; Tue, 20 Feb 2018 05:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GU6TOHbcPghmXwzs/sz92rPMCJjtH4VJSl1I9lv3K/8=; b=OlKMVWVla6khsLB/Oxgg1OVYlrQ5vHDlj2hSV9CdJqPZWflgwyNiWo0P0oG/wtCH+R oxlEbd4p34z+bLCuS4TF4i0oPakPG88y9lkM+xn/iGs5316shT7b8ypNO4VdM7USkvRp ypH5OTTh/2nq260yKj0WqDvcmWv0AoOD6N6Had3za3Sh90vD9/DUvo3QpUlMReXSMoSB KbfvhabwqS8eFsvYnK8AB8cPbhoVpp5O2gvriT24PvFBIV3kP7ZWsEljOe8OdXxyWgXr w7QyIWwAm0fy4XLMbu91s0MZQkbBxjufHF5xXjL0ARaesn4uD1KABmWPYFEL3Lh3cebT Dq6A== 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=GU6TOHbcPghmXwzs/sz92rPMCJjtH4VJSl1I9lv3K/8=; b=l4cKFiJZv+M/8aSf3h6Hdx0IwIhSZbzILpY4x6rRL8JNAqgpOOSDh+CNerSryz//e3 4KKSzQEf+PWEm5RSsmNh7TU7AcKF3w8iKbjDLrSj/Fr6y/IEDguYzvMI4sNHNju5NrlS KFGdQ7I0CYg0RS5QjXc/F6+z6+YbHqWDUxb9vs8lkfR2sO8JHlfbc1TRD4mYdCGvHOms Ugaq+duA2/5p3+dhcggZ2SHYFEw6wSLtSE9ke44Tkb0oghsSFQHoLOs7gD2D5nRhwydT orT+O1bptcRlr6UP/5psqNUpcre55tXEoc+aO3OhpQvoRx8D3FifNimu17GGIWbNcRMA wZNA== X-Gm-Message-State: APf1xPBSFuE51+773DAy+wyn+2flApcRYTIH0xkdJsRHUAN7bAuKK/n0 8ZmrWYXzJWs4jE/9xirALomYdYFY9DvZHlf9dxV0fQ== X-Google-Smtp-Source: AH8x2250gNd27dT4Z8i+dDQXl0JM0CWF1X/utGh4PVeumQhx0hndcUnVQ2Quera4QL7j+umbvhiBwHIx8pqfpWw/KJk= X-Received: by 10.223.158.10 with SMTP id u10mr8180790wre.165.1519131878991; Tue, 20 Feb 2018 05:04:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.68 with HTTP; Tue, 20 Feb 2018 05:03:58 -0800 (PST) In-Reply-To: <25f3a769-b1dd-9531-c87f-20a5f7b73ff3@selasky.org> References: <25f3a769-b1dd-9531-c87f-20a5f7b73ff3@selasky.org> From: Johannes Lundberg Date: Tue, 20 Feb 2018 13:03:58 +0000 Message-ID: Subject: Re: Recent world+kernel has broken Linux 3D apps? To: Hans Petter Selasky Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 13:04:41 -0000 On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky wrote: > On 02/20/18 12:39, Johannes Lundberg wrote: > >> Before rebuilding world my system was running Linux games fine with a >> couple of months old world/kernel and drm-next-kmod. >> >> Since updating world+kernel last week all Linux 3D apps fail (native >> binaries like glxgears and supertuxkart works fine). >> >> linux-c6/c7, intel/modesetting, does no difference >> This is on Dell Intel Broadwell laptop. >> >> Doom 3 fail like this: >> >> ----- R_ReloadARBPrograms ----- >> glprogs/test.vfpsignal caught: Segmentation fault >> si_code 1 >> Trying to exit gracefully.. >> >> >> And glxgears (in /compat/linux/usr/bin/) >> >> johannes@jd2:~ % /compat/linux/usr/bin/glxgears >> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >> broken. >> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >> broken. >> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >> broken. >> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >> broken. >> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >> broken. >> libdrm aub dumping is deprecated. >> >> Use intel_aubdump from intel-gpu-tools instead. Install intel-gpu-tools, >> then run (for example) >> >> $ intel_aubdump --output=trace.aub glxgears -geometry 500x500 >> >> See the intel_aubdump man page for more details. >> bo_create: buf 1 (swizzle test) 32768b >> bo_unreference final: 1 (swizzle test) >> libGL: Can't open configuration file /home/johannes/.drirc: No such file >> or >> directory. >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> bo_create: buf 1 (transform feedback offsets) 16b >> bo_create: buf 2 (xfb primitive counts) 4096b >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> intelNewTextureObject >> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn >> compression/decompression unavailable >> libGL: Can't open configuration file /home/johannes/.drirc: No such file >> or >> directory. >> bo_create: buf 3 (batchbuffer) 32768b >> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >> bo_map: 3 (batchbuffer), map_count=1 >> bo_map: 3 (batchbuffer) -> 0x1000 >> bo_create: buf 4 (pipe_control workaround) 4096b >> bo_create: buf 5 (program cache) 4096b >> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >> bo_map_gtt: mmap 5 (program cache), map_count=1 >> intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid >> argument . >> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >> bo_create: buf 6 (shader time) 393216b >> bo_create: buf 7 (bufferobj) 65536b >> enter intel_update_renderbuffers, drawable 0x614b80 >> enter intel_update_dri2_buffers, drawable 0x614b80 >> attaching buffer 3, at 1, cpp 4, pitch 1536 >> bo_create_from_handle: 3 (dri2 back buffer) >> intel_miptree_create_layout target GL_TEXTURE_2D format >> MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210 >> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >> intel_miptree_set_total_width_height: 300x300x4 >> intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: >> MESA_FORMAT_Z24_UNORM_X8_UINT (300x300) >> intel_miptree_create_layout target GL_TEXTURE_2D format >> MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440 >> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >> intel_miptree_set_total_width_height: 300x300x4 >> bo_create: buf 9 (miptree) 409600b >> bo_create: buf 10 (hiz) 98304b >> mt 0x778440 level 0: HiZ enabled >> intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: >> MESA_FORMAT_S_UINT8 (300x300) >> intel_miptree_create_layout target GL_TEXTURE_2D format >> MESA_FORMAT_S_UINT8 >> level 0..0 slices 1 <-- 0x778890 >> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >> intel_miptree_set_total_width_height: 300x304x1 >> bo_create: buf 11 (miptree) 102400b >> Running synchronized to the vertical refresh. The framerate should be >> approximately the same as the monitor refresh rate. >> bo_create: buf 12 (bufferobj) 32768b >> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >> bo_map_gtt: mmap 12 (bufferobj), map_count=1 >> intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid >> argument . >> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >> >> >> Segmentation fault (core dumped) >> > > Can you compare the debug prints with working version? > > I don't have a working system anymore.. Need some time to set one up... If anyone has, try this $ setenv INTEL_DEBUG all $ setenv MESA_DEBUG 1 $ setenv LIBGL_DEBUG 1 $ /compat/linux/usr/bin/glxgears > --HPS > > From owner-freebsd-current@freebsd.org Tue Feb 20 13:39:34 2018 Return-Path: Delivered-To: freebsd-current@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 EB396F02A46 for ; Tue, 20 Feb 2018 13:39:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 8369477AD9 for ; Tue, 20 Feb 2018 13:39:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 43C212603CD; Tue, 20 Feb 2018 14:39:31 +0100 (CET) Subject: Re: Recent world+kernel has broken Linux 3D apps? To: Johannes Lundberg Cc: freebsd-current References: <25f3a769-b1dd-9531-c87f-20a5f7b73ff3@selasky.org> From: Hans Petter Selasky Message-ID: Date: Tue, 20 Feb 2018 14:39:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 13:39:34 -0000 On 02/20/18 14:03, Johannes Lundberg wrote: > On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky > wrote: > >> On 02/20/18 12:39, Johannes Lundberg wrote: >> >>> Before rebuilding world my system was running Linux games fine with a >>> couple of months old world/kernel and drm-next-kmod. >>> >>> Since updating world+kernel last week all Linux 3D apps fail (native >>> binaries like glxgears and supertuxkart works fine). >>> >>> linux-c6/c7, intel/modesetting, does no difference >>> This is on Dell Intel Broadwell laptop. >>> >>> Doom 3 fail like this: >>> >>> ----- R_ReloadARBPrograms ----- >>> glprogs/test.vfpsignal caught: Segmentation fault >>> si_code 1 >>> Trying to exit gracefully.. >>> >>> >>> And glxgears (in /compat/linux/usr/bin/) >>> >>> johannes@jd2:~ % /compat/linux/usr/bin/glxgears >>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>> broken. >>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>> broken. >>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>> broken. >>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>> broken. >>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>> broken. >>> libdrm aub dumping is deprecated. >>> >>> Use intel_aubdump from intel-gpu-tools instead. Install intel-gpu-tools, >>> then run (for example) >>> >>> $ intel_aubdump --output=trace.aub glxgears -geometry 500x500 >>> >>> See the intel_aubdump man page for more details. >>> bo_create: buf 1 (swizzle test) 32768b >>> bo_unreference final: 1 (swizzle test) >>> libGL: Can't open configuration file /home/johannes/.drirc: No such file >>> or >>> directory. >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> bo_create: buf 1 (transform feedback offsets) 16b >>> bo_create: buf 2 (xfb primitive counts) 4096b >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> intelNewTextureObject >>> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn >>> compression/decompression unavailable >>> libGL: Can't open configuration file /home/johannes/.drirc: No such file >>> or >>> directory. >>> bo_create: buf 3 (batchbuffer) 32768b >>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>> bo_map: 3 (batchbuffer), map_count=1 >>> bo_map: 3 (batchbuffer) -> 0x1000 >>> bo_create: buf 4 (pipe_control workaround) 4096b >>> bo_create: buf 5 (program cache) 4096b >>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >>> bo_map_gtt: mmap 5 (program cache), map_count=1 >>> intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid >>> argument . >>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>> bo_create: buf 6 (shader time) 393216b >>> bo_create: buf 7 (bufferobj) 65536b >>> enter intel_update_renderbuffers, drawable 0x614b80 >>> enter intel_update_dri2_buffers, drawable 0x614b80 >>> attaching buffer 3, at 1, cpp 4, pitch 1536 >>> bo_create_from_handle: 3 (dri2 back buffer) >>> intel_miptree_create_layout target GL_TEXTURE_2D format >>> MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210 >>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>> intel_miptree_set_total_width_height: 300x300x4 >>> intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: >>> MESA_FORMAT_Z24_UNORM_X8_UINT (300x300) >>> intel_miptree_create_layout target GL_TEXTURE_2D format >>> MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440 >>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>> intel_miptree_set_total_width_height: 300x300x4 >>> bo_create: buf 9 (miptree) 409600b >>> bo_create: buf 10 (hiz) 98304b >>> mt 0x778440 level 0: HiZ enabled >>> intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: >>> MESA_FORMAT_S_UINT8 (300x300) >>> intel_miptree_create_layout target GL_TEXTURE_2D format >>> MESA_FORMAT_S_UINT8 >>> level 0..0 slices 1 <-- 0x778890 >>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>> intel_miptree_set_total_width_height: 300x304x1 >>> bo_create: buf 11 (miptree) 102400b >>> Running synchronized to the vertical refresh. The framerate should be >>> approximately the same as the monitor refresh rate. >>> bo_create: buf 12 (bufferobj) 32768b >>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >>> bo_map_gtt: mmap 12 (bufferobj), map_count=1 >>> intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid >>> argument . >>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>> >>> >>> Segmentation fault (core dumped) >>> >> >> Can you compare the debug prints with working version? >> >> > I don't have a working system anymore.. Need some time to set one up... > If anyone has, try this > > $ setenv INTEL_DEBUG all > $ setenv MESA_DEBUG 1 > $ setenv LIBGL_DEBUG 1 > $ /compat/linux/usr/bin/glxgears > This patch fixes it for me: > Index: sys/compat/linux/linux_mmap.c > =================================================================== > --- sys/compat/linux/linux_mmap.c (revision 329557) > +++ sys/compat/linux/linux_mmap.c (working copy) > @@ -129,7 +129,7 @@ > error = fget(td, fd, cap_rights_init(&rights, CAP_MMAP), &fp); > if (error != 0) > return (error); > - if (fp->f_type != DTYPE_VNODE) { > + if (fp->f_type != DTYPE_VNODE && fp->f_type != DTYPE_DEV) { > fdrop(fp, td); > return (EINVAL); > } --HPS From owner-freebsd-current@freebsd.org Tue Feb 20 13:48:37 2018 Return-Path: Delivered-To: freebsd-current@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 95A58F03554 for ; Tue, 20 Feb 2018 13:48:37 +0000 (UTC) (envelope-from johalun0@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 0D7C7780BA for ; Tue, 20 Feb 2018 13:48:37 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id 34so14529610wre.13 for ; Tue, 20 Feb 2018 05:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y+nRxge4hA7qtE616awo3ds4BmkeBARPgeTipjQ95TQ=; b=MEfajbEuO5wlrqlyfgIdVdFLnhwX6IVygygojcg/CrvnzZ7pWg2SB5TNwAmFnR+H6d diWrCeSVRW03hF2B18P+ZjgGrVa+9SoejTIlxmBld+C0nkXmgPFEsMXG48zjLvP8KE4+ sppIAOa3ZlsaH92k6fYiohsLoB8stuZtoHVBF1QFzSL80XK2KoZiONu2xiySameA3Py0 7qkQKnlvEOqZ35nB9yp9I4XbLN7No1YpPU3hGzlUxOfSn/Olw49J1+qdCKAGkS8qKHxc l0LlJklxNiPtVIwmdObIMW1t1hx5QcxFkmQzY4HhxOyPqXFASNheERHpLbSzUnMc3EeS Hi2g== 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=Y+nRxge4hA7qtE616awo3ds4BmkeBARPgeTipjQ95TQ=; b=hodkNkf6M1AYJRxfIxYHG2OwxnIP0KOmTDVP6n+C9oMYBVcyvZOQTJcd/mGhYg3HtV cvTUjXEuz7rOQ2zY0Y1g77xYBmpzLmmCNAAnB9lJyCr8ShgB0jAw6MHW/PrlP+75begR QprvO9bR2SiVknY2ICedc8BS97/jjcBCNVVcDP5hkG+WAkBEK0ngwdz2TukGmwe/bm0z F4OIiy0KVNUMo0AWJaPOCEP8m/QnfwzTYjJPbUiVcTXdl3GRj1DQVFSt/iVDtnkZ4I5O 3ylB9osT1uBKvdeLUd68u7r4Kzxg/NJ9mP5PeKbEFv5agdWdF7Pj168GuHK0q26+5+iw 93AQ== X-Gm-Message-State: APf1xPD5UHw76eqU6FNR/2xfgHJe2hSepBWNviozLKYLs3i2b13ESmJD MazvzLhrb8fvjPJxS6e2XVbAtRArfZEjBeojBG4= X-Google-Smtp-Source: AH8x226oDLrdaAiyitsl6tGhbFv9ebGpk53xEVdEbecsj4ki5+idXDNZNAlDHOcQjhbfnRAirCmQStTFBS6C1zYAdiY= X-Received: by 10.223.129.49 with SMTP id 46mr13045491wrm.133.1519134515973; Tue, 20 Feb 2018 05:48:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.68 with HTTP; Tue, 20 Feb 2018 05:47:55 -0800 (PST) In-Reply-To: References: <25f3a769-b1dd-9531-c87f-20a5f7b73ff3@selasky.org> From: Johannes Lundberg Date: Tue, 20 Feb 2018 13:47:55 +0000 Message-ID: Subject: Re: Recent world+kernel has broken Linux 3D apps? To: Hans Petter Selasky Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 13:48:37 -0000 On Tue, Feb 20, 2018 at 1:39 PM, Hans Petter Selasky wrote: > On 02/20/18 14:03, Johannes Lundberg wrote: > >> On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky >> wrote: >> >> On 02/20/18 12:39, Johannes Lundberg wrote: >>> >>> Before rebuilding world my system was running Linux games fine with a >>>> couple of months old world/kernel and drm-next-kmod. >>>> >>>> Since updating world+kernel last week all Linux 3D apps fail (native >>>> binaries like glxgears and supertuxkart works fine). >>>> >>>> linux-c6/c7, intel/modesetting, does no difference >>>> This is on Dell Intel Broadwell laptop. >>>> >>>> Doom 3 fail like this: >>>> >>>> ----- R_ReloadARBPrograms ----- >>>> glprogs/test.vfpsignal caught: Segmentation fault >>>> si_code 1 >>>> Trying to exit gracefully.. >>>> >>>> >>>> And glxgears (in /compat/linux/usr/bin/) >>>> >>>> johannes@jd2:~ % /compat/linux/usr/bin/glxgears >>>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>>> broken. >>>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>>> broken. >>>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>>> broken. >>>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>>> broken. >>>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be >>>> broken. >>>> libdrm aub dumping is deprecated. >>>> >>>> Use intel_aubdump from intel-gpu-tools instead. Install >>>> intel-gpu-tools, >>>> then run (for example) >>>> >>>> $ intel_aubdump --output=trace.aub glxgears -geometry 500x500 >>>> >>>> See the intel_aubdump man page for more details. >>>> bo_create: buf 1 (swizzle test) 32768b >>>> bo_unreference final: 1 (swizzle test) >>>> libGL: Can't open configuration file /home/johannes/.drirc: No such file >>>> or >>>> directory. >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> bo_create: buf 1 (transform feedback offsets) 16b >>>> bo_create: buf 2 (xfb primitive counts) 4096b >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> intelNewTextureObject >>>> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn >>>> compression/decompression unavailable >>>> libGL: Can't open configuration file /home/johannes/.drirc: No such file >>>> or >>>> directory. >>>> bo_create: buf 3 (batchbuffer) 32768b >>>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>>> bo_map: 3 (batchbuffer), map_count=1 >>>> bo_map: 3 (batchbuffer) -> 0x1000 >>>> bo_create: buf 4 (pipe_control workaround) 4096b >>>> bo_create: buf 5 (program cache) 4096b >>>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >>>> bo_map_gtt: mmap 5 (program cache), map_count=1 >>>> intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid >>>> argument . >>>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>>> bo_create: buf 6 (shader time) 393216b >>>> bo_create: buf 7 (bufferobj) 65536b >>>> enter intel_update_renderbuffers, drawable 0x614b80 >>>> enter intel_update_dri2_buffers, drawable 0x614b80 >>>> attaching buffer 3, at 1, cpp 4, pitch 1536 >>>> bo_create_from_handle: 3 (dri2 back buffer) >>>> intel_miptree_create_layout target GL_TEXTURE_2D format >>>> MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210 >>>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>>> intel_miptree_set_total_width_height: 300x300x4 >>>> intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: >>>> MESA_FORMAT_Z24_UNORM_X8_UINT (300x300) >>>> intel_miptree_create_layout target GL_TEXTURE_2D format >>>> MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440 >>>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>>> intel_miptree_set_total_width_height: 300x300x4 >>>> bo_create: buf 9 (miptree) 409600b >>>> bo_create: buf 10 (hiz) 98304b >>>> mt 0x778440 level 0: HiZ enabled >>>> intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: >>>> MESA_FORMAT_S_UINT8 (300x300) >>>> intel_miptree_create_layout target GL_TEXTURE_2D format >>>> MESA_FORMAT_S_UINT8 >>>> level 0..0 slices 1 <-- 0x778890 >>>> intel_miptree_set_level_info level 0, depth 1, offset 0,0 >>>> intel_miptree_set_total_width_height: 300x304x1 >>>> bo_create: buf 11 (miptree) 102400b >>>> Running synchronized to the vertical refresh. The framerate should be >>>> approximately the same as the monitor refresh rate. >>>> bo_create: buf 12 (bufferobj) 32768b >>>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1 >>>> bo_map_gtt: mmap 12 (bufferobj), map_count=1 >>>> intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid >>>> argument . >>>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1 >>>> >>>> >>>> Segmentation fault (core dumped) >>>> >>>> >>> Can you compare the debug prints with working version? >>> >>> >>> I don't have a working system anymore.. Need some time to set one up... >> If anyone has, try this >> >> $ setenv INTEL_DEBUG all >> $ setenv MESA_DEBUG 1 >> $ setenv LIBGL_DEBUG 1 >> $ /compat/linux/usr/bin/glxgears >> >> > This patch fixes it for me: > > Index: sys/compat/linux/linux_mmap.c >> =================================================================== >> --- sys/compat/linux/linux_mmap.c (revision 329557) >> +++ sys/compat/linux/linux_mmap.c (working copy) >> @@ -129,7 +129,7 @@ >> error = fget(td, fd, cap_rights_init(&rights, CAP_MMAP), >> &fp); >> if (error != 0) >> return (error); >> - if (fp->f_type != DTYPE_VNODE) { >> + if (fp->f_type != DTYPE_VNODE && fp->f_type != DTYPE_DEV) >> { >> fdrop(fp, td); >> return (EINVAL); >> } >> > And just like magic it works again <3 > > --HPS > From owner-freebsd-current@freebsd.org Tue Feb 20 16:34:48 2018 Return-Path: Delivered-To: freebsd-current@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 E27BFF126DA for ; Tue, 20 Feb 2018 16:34:47 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.10]) (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 7EE5C7F657 for ; Tue, 20 Feb 2018 16:34:46 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2625.sfr.fr (SMTP Server) with ESMTP id 5FC241C7AEC19 for ; Tue, 20 Feb 2018 17:34:45 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2625.sfr.fr (SMTP Server) with ESMTPSA; Tue, 20 Feb 2018 17:34:44 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans , FreeBSD-Current References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> Message-ID: <4e3d28ae-447a-0249-ba42-ac0bd3416b92@club.fr> Date: Tue, 20 Feb 2018 17:34:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 16:34:48 -0000 > Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello! >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: >>> I have done a full build of r329555 to test the new Lua boot loader. >>> >>> Both the new and the old kernels panic after being loaded with: >>> >>> panic: running without device atpic requires a local APIC >>> >>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous >>> message: >>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html >>> >>> OK show hint.acpi.0.disabled >>> 1 >>> >>> Setting ACPI to On resolves the issue. >> > Hi Kyle. > >> As David noted, this should actually Just Work (TM) now. Can you break >> into a loader prompt with just the forth loader and tell me what "show >> hint.acpi.0.rsdp" looks like? > OK show hint.acpi.0.rsdp > Command error > > I tested both with hint.acpi.0.disabled= 1 and 0. > > >> >>> Also, I can not stop boot2 to try to use the copy of the Forth loader: the >>> keyboard only becomes responsive at the loader stage. >> >> Hmm... > In fact, I don’t think this has ever worked here… I’ve found a very old (July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage. > > >>> There is an error during this stage: >>> >>> Loading /boot/defaults/loader.conf >>> Failed to open config: ’/boot/loader.conf.local’ >> >> David's diagnosis of this is right- this is more of an informational >> message that you don't need to worry about. > Thanks. > > >>> Moreover, the "boot [kernel]" loader command does not work: >>> >>> OK ls /boot/kernel.old/kernel >>> /boot/kernel.old/kernel >>> OK boot kernel.old >>> Command failed >>> OK boot /boot/kernel.old/kernel >>> Command failed >>> OK boot kernel >>> Command failed >>> >>> On the other hand, just "boot" works. >> >> It seems that the Forth loader might be doing something sneaky and >> replacing the standard common "boot" with a Forth boot that handles >> this a lot better. CC'ing dteske@ so they can confirm. >> >>> Finally, the double lines drawing a frame around the loader menu do not work >>> with the new loader and are replaced by ? characters in a box. >> >> Interesting, I'll look into that... anything interesting/unique about >> your setup? r329387 should have addressed one potential cause of this, >> but I see you're past that. > I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 4GB RAM). The only thing I can think of is that the ACPI of this model is not well supported, but the errors I have are related to thermal zones…: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678 > > To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache and WITH_META_MODE, but this build process has been working nicely for months. > > The kernel is based on GENERIC-NODEBUG and has been also working reliably: > > juan@Server ~ % cat /root/kernels/MEMSTICK > include GENERIC-NODEBUG > > ident MEMSTICK > > nodevice fdc > > nodevice ch > nodevice sa > nodevice ses > > nodevice amr > nodevice arcmsr > nodevice ciss > nodevice dpt > nodevice hptmv > nodevice hptnr > nodevice hptrr > nodevice hpt27xx > nodevice iir > nodevice ips > nodevice mly > nodevice twa > nodevice tws > > nodevice aac > nodevice aacp > nodevice aacraid > nodevice ida > nodevice mfi > nodevice mlx > nodevice mrsas > nodevice pmspcv > nodevice twe > > nodevice nvme > nodevice nvd > > nodevice virtio > nodevice virtio_pci > nodevice vtnet > nodevice virtio_blk > nodevice virtio_scsi > nodevice virtio_balloon > > nooptions HYPERV > nodevice hyperv > > nooptions XENHVM > nodevice xenpci > > nodevice vmx > > > There is maybe something fishy in my src.conf, where I disable a lot of things to slim down the memstick, but still, it has been stable till now: > > juan@Server ~ % cat /etc/src.conf > # For memory sticks > > WITH_CCACHE_BUILD= > > WITHOUT_ACCT= > WITHOUT_AMD= > WITHOUT_ATM= > WITHOUT_AUTHPF= > WITHOUT_AUTOFS= > WITHOUT_BHYVE= > WITHOUT_BLACKLIST= > # iwm does not support Bluetooth > WITHOUT_BLUETOOTH= > WITHOUT_BOOTPARAMD= > WITHOUT_BOOTPD= > # WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG > WITHOUT_BSNMP= > WITHOUT_CALENDAR= > # Don't set this when building HEAD from RELENG > # WITHOUT_CROSS_COMPILER= > WITHOUT_CTM= > WITHOUT_DEBUG_FILES= > #WITHOUT_DIALOG= > WITHOUT_DICT= > WITHOUT_EE= > WITHOUT_EXAMPLES= > WITHOUT_FDT= > WITHOUT_FINGER= > WITHOUT_FLOPPY= > # For testing the Lua loader (WITH_LOADER_LUA) > WITHOUT_FORTH= > WITHOUT_FREEBSD_UPDATE= > WITHOUT_GAMES= > WITHOUT_GCOV= > WITHOUT_GPIO= > # You disable Kerberos later, but try to keep GSSAPI for curl > pkg > # But this does not work, base Kerberos is required > #WITH_GSSAPI= > WITHOUT_GSSAPI= > WITHOUT_HAST= > WITHOUT_HESIOD= > WITHOUT_HTML= > WITHOUT_HYPERV= > WITHOUT_IPFILTER= > WITHOUT_IPFW= > WITHOUT_ISCSI= > WITHOUT_JAIL= > WITHOUT_KERBEROS= > WITHOUT_KERNEL_SYMBOLS= > WITHOUT_KVM= > WITHOUT_LDNS= > # This disables moused > #WITHOUT_LEGACY_CONSOLE= > WITHOUT_LLDB= > # This requires WITHOUT_FORTH > WITH_LOADER_LUA= > # This breaks setting locale and thus tmux > #WITHOUT_LOCALES= > WITHOUT_LPR= > WITHOUT_MAIL= > WITHOUT_NETCAT= > WITHOUT_PC_SYSINSTALL= > WITHOUT_PF= > WITHOUT_PORTSNAP= > WITHOUT_PPP= > WITHOUT_PROFILE= > WITHOUT_QUOTAS= > WITHOUT_RADIUS_SUPPORT= > WITHOUT_RBOOTD= > WITHOUT_RCS= > WITHOUT_SHAREDOCS= > WITH_SVN= > WITHOUT_SYSCONS= > WITHOUT_TALK= > WITHOUT_TCP_WRAPPERS= > WITHOUT_TELNET= > WITHOUT_TESTS= > WITHOUT_TFPT= > WITHOUT_TIMED= > WITHOUT_UNBOUND= > WITHOUT_UTMPX= > WITHOUT_ZFS= > WITHOUT_ZONEINFO= > > > Thanks for your attention. > Juan Hi! Updated today to r239641 and indeed the ACPI issue is gone. Drawing chars in the loader are still missing. I guess it is related to a difference I forgot to explain in my previous message: the Forth loader used a higher resolution (lots of space around the logo and menu), while the Lua one is using a lower one and occupies the whole screen. Hope it helps, Juan From owner-freebsd-current@freebsd.org Tue Feb 20 16:50:59 2018 Return-Path: Delivered-To: freebsd-current@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 AAFE4F13EF9 for ; Tue, 20 Feb 2018 16:50:59 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.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 42E60801D7 for ; Tue, 20 Feb 2018 16:50:58 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2611.sfr.fr (SMTP Server) with ESMTP id 802EC1C0018EF for ; Tue, 20 Feb 2018 17:50:57 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2611.sfr.fr (SMTP Server) with ESMTPSA; Tue, 20 Feb 2018 17:50:56 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr To: freebsd-current@freebsd.org, mjguzik@gmail.com References: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Message-ID: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> Date: Tue, 20 Feb 2018 17:50:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-sfr-mailing: LEGIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 16:50:59 -0000 > I committed the fix in > https://svnweb.freebsd.org/base?view=revision&revision=329542 > > i.e. should be stable from this point on. Hi! It is maybe unrelated, but recent commits have broken my system with a similar error. I did not have panics with a system built around December, but since updating first to r329555 then today to r329641 I’m getting a reproducible panic when logging out from a Lumina desktop session: Unread portion of the kernel message buffer: spin lock 0xfffff8000d440020 (process slock) held by 0xfffff8000daed560 (tid 100111) too long panic: spin lock held too long cpuid = 1 time = 1519143505 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00005c15e0 vpanic() at vpanic+0x18d/frame 0xfffffe00005c1640 panic() at panic+0x43/frame 0xfffffe00005c16a0 _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 0xfffffe00005c16b0 mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame 0xfffffe00005c16e0 proc_reap() at proc_reap+0x24/frame 0xfffffe00005c1720 procdesc_close() at procdesc_close+0x125/frame 0xfffffe00005c1760 closef() at closef+0x251/frame 0xfffffe00005c17f0 fdescfree_fds() at fdescfree_fds+0x90/frame 0xfffffe00005c1840 fdescfree() at fdescfree+0x4df/frame 0xfffffe00005c1900 exit1() at exit1+0x508/frame 0xfffffe00005c1970 sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00005c1980 amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00005c1ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffea90 Uptime: 17m45s Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..54%..64%..74%..84%..93% Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/linux_common.ko...done. Loaded symbols for /boot/kernel/linux_common.ko Reading symbols from /boot/kernel/acpi_ibm.ko...done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/iwm7260fw.ko...done. Loaded symbols for /boot/kernel/iwm7260fw.ko Reading symbols from /boot/kernel/coretemp.ko...done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/if_iwm.ko...done. Loaded symbols for /boot/kernel/if_iwm.ko Reading symbols from /boot/kernel/acpi_video.ko...done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/nullfs.ko...done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/i915kms.ko...done. Loaded symbols for /boot/kernel/i915kms.ko Reading symbols from /boot/kernel/drm2.ko...done. Loaded symbols for /boot/kernel/drm2.ko Reading symbols from /boot/kernel/iicbus.ko...done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/iic.ko...done. Loaded symbols for /boot/kernel/iic.ko Reading symbols from /boot/kernel/iicbb.ko...done. Loaded symbols for /boot/kernel/iicbb.ko #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 1324            CPU_SET_ATOMIC(cpu, &stopped_cpus); (kgdb) bt #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 #1  0xffffffff80e29fb4 in ipi_nmi_handler () at /usr/src/sys/x86/x86/mp_x86.c:1280 #2  0xffffffff80d09a79 in trap (frame=0xffffffff8158bef0)     at /usr/src/sys/amd64/amd64/trap.c:188 #3  0xffffffff80cec054 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:633 #4  0xffffffff80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at cpufunc.h:611 Previous frame inner to this frame (corrupt stack?) Current language:  auto; currently minimal kgdb is over my head, but I can provide more details under some guidance. Hope it helps, Juan From owner-freebsd-current@freebsd.org Tue Feb 20 17:06:48 2018 Return-Path: Delivered-To: freebsd-current@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 9C9CFF15675 for ; Tue, 20 Feb 2018 17:06:48 +0000 (UTC) (envelope-from mjguzik@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 3423080D3F for ; Tue, 20 Feb 2018 17:06:48 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id l19so2559036qtj.9 for ; Tue, 20 Feb 2018 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HPCpKE7qxZjG+ogeU3q0EPhU56wjiHRbUNfaVYC+Pbo=; b=oawUaeesL9kZIY8l3koaEwjGBL8E7PIYKYSp8UETJck57KgCx/Z6efJbJAdZo4XhVv l7pptJ/x9OoA4VAmfAzPineOaUW73tj0Ridu2yCBjc+0740VGbwKsfpXorbH6v/jjGTd g1Vf2WrBb5MvhxcAkzBdXeHgPHAQ/RYG27U3Sl/yhWPosONz4eTsgAsSQK9YRTyN+uHk QOv9Cf6CNfvECZ3pXuwfBI+oN7c3JrVd57N84oRUSFrygICAraZfI0RLwwWNC3kyeMlN 25y3EWxUsx53HJ0TUL9o524WzT1Z5twAnEovkVrJwZRpaZ9NB/KFvaHO/qV15/P2T6nx sAyQ== 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=HPCpKE7qxZjG+ogeU3q0EPhU56wjiHRbUNfaVYC+Pbo=; b=NGw/rg/HztjDmUq/q9uVCqkF6dGYRR3RzvS520lo5dZNtRk5f7qV+ZkRnzryJdWlHV gIPJEvwAkuPYX3oM6XH/h/W0dC86nU2rTN24CEd3qnJ/wV40q57F66azjJYu6hDCJCuC KYHnAb9jW+jFogUibtf1g5/CbLRRej4mKfSQUz0gDTDCbEc8zGxUZrDnfWfm01XgyLS0 TYN33WTV1ahzX6R4gLnB1qu9sny0O1gaIr5WWlDSpSztwaFVZC0GBN6RYOFI9pVMPHLI Kvr499K4bb8uJ37DjtaHPjigA7z3odN7thSrTkmDZItjniPgi9rbgQGzJQM2J4/vqOP1 iY8Q== X-Gm-Message-State: APf1xPDxRjfo1d1a4L3lA+A2RHIoZlCbsrdTClm70PWXUo6yDqFBZYvc Bjt5unEwzEVpkLign3PKrrt4D0OQ7mCGQhxuGXw= X-Google-Smtp-Source: AH8x226n9acXSOk86q5TAhtUnsq1RQNTR8kWTh3V5tC9W/HhdHlxqv8tq4O/sKaxiajdr3NBdiE0vIjZAhoveVyD0NE= X-Received: by 10.200.38.188 with SMTP id 57mr459952qto.220.1519146407860; Tue, 20 Feb 2018 09:06:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.42 with HTTP; Tue, 20 Feb 2018 09:06:47 -0800 (PST) In-Reply-To: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> References: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> From: Mateusz Guzik Date: Tue, 20 Feb 2018 18:06:47 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:06:48 -0000 I missed a consumer, try this: diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c index 5e8928cb1534..174fffc5c666 100644 --- a/sys/kern/sys_procdesc.c +++ b/sys/kern/sys_procdesc.c @@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td) * process's reference to the process descriptor when it * calls back into procdesc_reap(). */ - PROC_SLOCK(p); proc_reap(curthread, p, NULL, 0); } else { /* On Tue, Feb 20, 2018 at 5:50 PM, Juan Ram=C3=B3n Molina Menor wrote: > I committed the fix in >> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D329542 >> >> i.e. should be stable from this point on. >> > > Hi! > > It is maybe unrelated, but recent commits have broken my system with a > similar error. I did not have panics with a system built around December, > but since updating first to r329555 then today to r329641 I=E2=80=99m get= ting a > reproducible panic when logging out from a Lumina desktop session: > > Unread portion of the kernel message buffer: > spin lock 0xfffff8000d440020 (process slock) held by 0xfffff8000daed560 > (tid 100111) too long > panic: spin lock held too long > cpuid =3D 1 > time =3D 1519143505 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00005c15e0 > vpanic() at vpanic+0x18d/frame 0xfffffe00005c1640 > panic() at panic+0x43/frame 0xfffffe00005c16a0 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame > 0xfffffe00005c16b0 > mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame > 0xfffffe00005c16e0 > proc_reap() at proc_reap+0x24/frame 0xfffffe00005c1720 > procdesc_close() at procdesc_close+0x125/frame 0xfffffe00005c1760 > closef() at closef+0x251/frame 0xfffffe00005c17f0 > fdescfree_fds() at fdescfree_fds+0x90/frame 0xfffffe00005c1840 > fdescfree() at fdescfree+0x4df/frame 0xfffffe00005c1900 > exit1() at exit1+0x508/frame 0xfffffe00005c1970 > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00005c1980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00005c1ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffea90 > Uptime: 17m45s > Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..5 > 4%..64%..74%..84%..93% > > Reading symbols from /boot/kernel/linux.ko...done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/linux_common.ko...done. > Loaded symbols for /boot/kernel/linux_common.ko > Reading symbols from /boot/kernel/acpi_ibm.ko...done. > Loaded symbols for /boot/kernel/acpi_ibm.ko > Reading symbols from /boot/kernel/iwm7260fw.ko...done. > Loaded symbols for /boot/kernel/iwm7260fw.ko > Reading symbols from /boot/kernel/coretemp.ko...done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/if_iwm.ko...done. > Loaded symbols for /boot/kernel/if_iwm.ko > Reading symbols from /boot/kernel/acpi_video.ko...done. > Loaded symbols for /boot/kernel/acpi_video.ko > Reading symbols from /boot/kernel/nullfs.ko...done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/fdescfs.ko...done. > Loaded symbols for /boot/kernel/fdescfs.ko > Reading symbols from /boot/kernel/i915kms.ko...done. > Loaded symbols for /boot/kernel/i915kms.ko > Reading symbols from /boot/kernel/drm2.ko...done. > Loaded symbols for /boot/kernel/drm2.ko > Reading symbols from /boot/kernel/iicbus.ko...done. > Loaded symbols for /boot/kernel/iicbus.ko > Reading symbols from /boot/kernel/iic.ko...done. > Loaded symbols for /boot/kernel/iic.ko > Reading symbols from /boot/kernel/iicbb.ko...done. > Loaded symbols for /boot/kernel/iicbb.ko > #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 > 1324 CPU_SET_ATOMIC(cpu, &stopped_cpus); > (kgdb) bt > #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 > #1 0xffffffff80e29fb4 in ipi_nmi_handler () at > /usr/src/sys/x86/x86/mp_x86.c:1280 > #2 0xffffffff80d09a79 in trap (frame=3D0xffffffff8158bef0) > at /usr/src/sys/amd64/amd64/trap.c:188 > #3 0xffffffff80cec054 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exc= ep > tion.S:633 > #4 0xffffffff80e1aaef in acpi_cpu_idle_mwait (mwait_hint=3D0) at > cpufunc.h:611 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > kgdb is over my head, but I can provide more details under some guidance. > > Hope it helps, > Juan > > --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Feb 20 17:07:44 2018 Return-Path: Delivered-To: freebsd-current@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 2AE5CF157CA for ; Tue, 20 Feb 2018 17:07:44 +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 A35EC80E21 for ; Tue, 20 Feb 2018 17:07:43 +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 w1KH7VA2043324 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Feb 2018 19:07:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1KH7VA2043324 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1KH7VCQ043323; Tue, 20 Feb 2018 19:07:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Feb 2018 19:07:31 +0200 From: Konstantin Belousov To: Juan Ram?n Molina Menor Cc: freebsd-current@freebsd.org, mjguzik@gmail.com Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Message-ID: <20180220170731.GN94212@kib.kiev.ua> References: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:07:44 -0000 On Tue, Feb 20, 2018 at 05:50:57PM +0100, Juan Ram?n Molina Menor wrote: > > I committed the fix in > > https://svnweb.freebsd.org/base?view=revision&revision=329542 > > > > i.e. should be stable from this point on. > > Hi! > > It is maybe unrelated, but recent commits have broken my system with a > similar error. I did not have panics with a system built around > December, but since updating first to r329555 then today to r329641 I?m > getting a reproducible panic when logging out from a Lumina desktop session: > > Unread portion of the kernel message buffer: > spin lock 0xfffff8000d440020 (process slock) held by 0xfffff8000daed560 > (tid 100111) too long > panic: spin lock held too long > cpuid = 1 > time = 1519143505 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00005c15e0 > vpanic() at vpanic+0x18d/frame 0xfffffe00005c1640 > panic() at panic+0x43/frame 0xfffffe00005c16a0 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame > 0xfffffe00005c16b0 > mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame > 0xfffffe00005c16e0 > proc_reap() at proc_reap+0x24/frame 0xfffffe00005c1720 > procdesc_close() at procdesc_close+0x125/frame 0xfffffe00005c1760 > closef() at closef+0x251/frame 0xfffffe00005c17f0 > fdescfree_fds() at fdescfree_fds+0x90/frame 0xfffffe00005c1840 > fdescfree() at fdescfree+0x4df/frame 0xfffffe00005c1900 > exit1() at exit1+0x508/frame 0xfffffe00005c1970 > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00005c1980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00005c1ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffea90 > Uptime: 17m45s > Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..54%..64%..74%..84%..93% > > Reading symbols from /boot/kernel/linux.ko...done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/linux_common.ko...done. > Loaded symbols for /boot/kernel/linux_common.ko > Reading symbols from /boot/kernel/acpi_ibm.ko...done. > Loaded symbols for /boot/kernel/acpi_ibm.ko > Reading symbols from /boot/kernel/iwm7260fw.ko...done. > Loaded symbols for /boot/kernel/iwm7260fw.ko > Reading symbols from /boot/kernel/coretemp.ko...done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/if_iwm.ko...done. > Loaded symbols for /boot/kernel/if_iwm.ko > Reading symbols from /boot/kernel/acpi_video.ko...done. > Loaded symbols for /boot/kernel/acpi_video.ko > Reading symbols from /boot/kernel/nullfs.ko...done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/fdescfs.ko...done. > Loaded symbols for /boot/kernel/fdescfs.ko > Reading symbols from /boot/kernel/i915kms.ko...done. > Loaded symbols for /boot/kernel/i915kms.ko > Reading symbols from /boot/kernel/drm2.ko...done. > Loaded symbols for /boot/kernel/drm2.ko > Reading symbols from /boot/kernel/iicbus.ko...done. > Loaded symbols for /boot/kernel/iicbus.ko > Reading symbols from /boot/kernel/iic.ko...done. > Loaded symbols for /boot/kernel/iic.ko > Reading symbols from /boot/kernel/iicbb.ko...done. > Loaded symbols for /boot/kernel/iicbb.ko > #0š cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 > 1324ššššššššššš CPU_SET_ATOMIC(cpu, &stopped_cpus); > (kgdb) bt > #0š cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 > #1š 0xffffffff80e29fb4 in ipi_nmi_handler () at > /usr/src/sys/x86/x86/mp_x86.c:1280 > #2š 0xffffffff80d09a79 in trap (frame=0xffffffff8158bef0) > ššš at /usr/src/sys/amd64/amd64/trap.c:188 > #3š 0xffffffff80cec054 in nmi_calltrap () at > /usr/src/sys/amd64/amd64/exception.S:633 > #4š 0xffffffff80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at > cpufunc.h:611 > Previous frame inner to this frame (corrupt stack?) > Current language:š auto; currently minimal > > kgdb is over my head, but I can provide more details under some guidance. Use this. diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c index 5e8928cb153..174fffc5c66 100644 --- a/sys/kern/sys_procdesc.c +++ b/sys/kern/sys_procdesc.c @@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td) * process's reference to the process descriptor when it * calls back into procdesc_reap(). */ - PROC_SLOCK(p); proc_reap(curthread, p, NULL, 0); } else { /* From owner-freebsd-current@freebsd.org Tue Feb 20 18:25:34 2018 Return-Path: Delivered-To: freebsd-current@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 1D22BF1CDE5 for ; Tue, 20 Feb 2018 18:25:34 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (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 ACBB385097 for ; Tue, 20 Feb 2018 18:25:33 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f172.google.com with SMTP id u84so15931704iod.9 for ; Tue, 20 Feb 2018 10:25:33 -0800 (PST) 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=xr1FuSlbWph4kI/1A1Q/O4xZ9G5mFQ+I9htS/WTsBzQ=; b=UvumNwv2Cj03QFahasCNs/0fpqdsUksrYsdR5cjY+gyE+HMmddmxr9RNMetCFC25Lb vrhGvSEdeOVmHq/s20vC3lpuB92ZVNSpNuD1i0s1fpIWx7TdaTLRqof6b+8lVYN+jRbK WVhGUvDLiJXOXcRZrWiVql8nMsY5nHSQP6Ws3fmsjgDuU/ksDVWV4KKwO6ZGBbwDhgId RrGwXGb7Sd8IjAsgebrDTC5ikXB1mEEgTF6SZhHrO1VMtq7Mx+ZPASnhmHbo1HDIuKAQ KMJnfbUpup9ALYlJFUf4QBQJZrGuFAuuqNd38pDLfxMUxoQO7FoB53OQdFLH3bkKg6EK zz9w== X-Gm-Message-State: APf1xPA/jGnIcMT479BHa9kjfqfvVgkLv+v8QZsnoXgTRWL8TZecWSlP SxEjyFOtlwoGyLBLrnYr2P3Jlw5E X-Google-Smtp-Source: AH8x227SxRTxQfKOlJ3+D7hVst/0fDOZtDHOGDjOARwHMeRZOCK9M4dyXIxeYttMmDg81450aiISWg== X-Received: by 10.107.197.66 with SMTP id v63mr749875iof.298.1519150743227; Tue, 20 Feb 2018 10:19:03 -0800 (PST) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id e63sm14223997ioj.85.2018.02.20.10.19.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 10:19:03 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id t22so15914751ioa.7 for ; Tue, 20 Feb 2018 10:19:03 -0800 (PST) X-Received: by 10.107.179.70 with SMTP id c67mr702416iof.220.1519150742911; Tue, 20 Feb 2018 10:19:02 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Tue, 20 Feb 2018 10:19:02 -0800 (PST) In-Reply-To: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> From: Conrad Meyer Date: Tue, 20 Feb 2018 10:19:02 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: pkg does not recognize correct kernel version To: Ronald Klop Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:25:34 -0000 On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote: > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov > wrote: > >> Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > > > Which man page? I can't find it in pkg help update or pkg help upgrade or > man pkg. I had to dig for quite a while to find a reference (pkg.conf(5)): ABI: string The ABI of the package you want to install. Default: derived from the ABI of the /bin/sh binary. >> version note: >> orion% file /bin/ls >> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), >> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 >> (1101506), FreeBSD-style, stripped >> >> Update world past the __FreeBSD_version which is reported for the >> repository. > > > Does this mean I always have to do a *clean* buildworld after every version > bump? This takes ages. You could also do a -DNO_CLEAN buildworld. Or you can continue to override with "-o OSVERSION=foo", although that may eventually result in broken packages. In general the OSVERSION is bumped conservatively (more often than will actually result in breakage), so you can get away with the easy workaround for a while between buildworlds. Best, Conrad From owner-freebsd-current@freebsd.org Tue Feb 20 20:20:20 2018 Return-Path: Delivered-To: freebsd-current@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 C3179F27971 for ; Tue, 20 Feb 2018 20:20:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AF526B4DC for ; Tue, 20 Feb 2018 20:20:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id s188so8438617qkb.2 for ; Tue, 20 Feb 2018 12:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X9iFe/k8VUdT1UHqIUjxtwHuEdshXjEeY4EyAEZv/0k=; b=IhRiWiqRtZY+7i9L9aYV6JwBcpuX3imsD4hpueKb48m7DhJ8cV5Iyovs29l1N7HLW0 WnBjbI0tO0klIbPYoHklvLwQOjLAgOUUkDjVyggBEqaeIRkcUgm9YDCcmYBGdpR6khv/ SQYl4HSPa1FI6FeSXacxDtXW828G8qSEjpRdAgjlM3rPeWh17qYSoUE6q7Cul5ooEtyL R4bvIR1QJhFkY+jFntf/2PhLYpEx875kk47oVtsnZ5mprF37LEEk599CR3WlbYa/FYsc 8TDxiSoeLizgaEMjTsUgQGmGvB0XNjmUwFXJCwASywImZpZ8IiUUz8za8xH1Km6P0Ctu IN+w== 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=X9iFe/k8VUdT1UHqIUjxtwHuEdshXjEeY4EyAEZv/0k=; b=G0eWmA6JSgvSnj81+ua9xVrF4jQUbexVIebiGIWDZ8v0Oi0UzvYF86r3VuQerBGmX5 dp8uZ7bip9LPgsAtcyLHnwghOOIuR8rG2c4rv6QQoJ6MHgg7RNWn+1h3NnMNoNCB3W6P mzcADpD2bJj5/crzytgd7Xwee758hyCx1+RuwxHf9T8yG3SyT6qVhgRmlDmpGZMbD6VK acP4ShUtV3p8qYHIURQeu0Q7epePwGmxkbBVjQF3gqS1sW1anEdrvwVwHDYjAM34MKAX sPXVq9b+Ty/H/4ZcQ5B+ajvqibwtm+hebP1tcw/BNfxJ1SfR3bMcmxiXykB1ojiuhW5p 4F4Q== X-Gm-Message-State: APf1xPBfngv1hr9U6esdRVPGCYuNn+nC/ogGCX6jpNwWc3RW/MXcQla6 U5kjQWr7fsfEFbtaatUxDmRkfdek6rHGOok+uqM= X-Google-Smtp-Source: AH8x224wf3YCE9gvqW48pu6ZM/brHalDybnDO86DD2yO3bfhAJExE+jxCB9HGdLYjE8HnOzhsfcdkkgtsb86v/RXxow= X-Received: by 10.55.74.2 with SMTP id x2mr1350995qka.314.1519158019071; Tue, 20 Feb 2018 12:20:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.42 with HTTP; Tue, 20 Feb 2018 12:20:18 -0800 (PST) In-Reply-To: References: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> From: Mateusz Guzik Date: Tue, 20 Feb 2018 21:20:18 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 20:20:20 -0000 Committed in https://svnweb.freebsd.org/base?view=3Drevision&revision=3D329= 660 thanks for reporting On Tue, Feb 20, 2018 at 6:06 PM, Mateusz Guzik wrote: > I missed a consumer, try this: > > diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c > index 5e8928cb1534..174fffc5c666 100644 > --- a/sys/kern/sys_procdesc.c > +++ b/sys/kern/sys_procdesc.c > @@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td) > * process's reference to the process descriptor > when it > * calls back into procdesc_reap(). > */ > - PROC_SLOCK(p); > proc_reap(curthread, p, NULL, 0); > } else { > /* > > > On Tue, Feb 20, 2018 at 5:50 PM, Juan Ram=C3=B3n Molina Menor > wrote: > >> I committed the fix in >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D329542 >>> >>> i.e. should be stable from this point on. >>> >> >> Hi! >> >> It is maybe unrelated, but recent commits have broken my system with a >> similar error. I did not have panics with a system built around December= , >> but since updating first to r329555 then today to r329641 I=E2=80=99m ge= tting a >> reproducible panic when logging out from a Lumina desktop session: >> >> Unread portion of the kernel message buffer: >> spin lock 0xfffff8000d440020 (process slock) held by 0xfffff8000daed560 >> (tid 100111) too long >> panic: spin lock held too long >> cpuid =3D 1 >> time =3D 1519143505 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe00005c15e0 >> vpanic() at vpanic+0x18d/frame 0xfffffe00005c1640 >> panic() at panic+0x43/frame 0xfffffe00005c16a0 >> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame >> 0xfffffe00005c16b0 >> mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame >> 0xfffffe00005c16e0 >> proc_reap() at proc_reap+0x24/frame 0xfffffe00005c1720 >> procdesc_close() at procdesc_close+0x125/frame 0xfffffe00005c1760 >> closef() at closef+0x251/frame 0xfffffe00005c17f0 >> fdescfree_fds() at fdescfree_fds+0x90/frame 0xfffffe00005c1840 >> fdescfree() at fdescfree+0x4df/frame 0xfffffe00005c1900 >> exit1() at exit1+0x508/frame 0xfffffe00005c1970 >> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00005c1980 >> amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00005c1ab0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffea90 >> Uptime: 17m45s >> Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..5 >> 4%..64%..74%..84%..93% >> >> Reading symbols from /boot/kernel/linux.ko...done. >> Loaded symbols for /boot/kernel/linux.ko >> Reading symbols from /boot/kernel/linux_common.ko...done. >> Loaded symbols for /boot/kernel/linux_common.ko >> Reading symbols from /boot/kernel/acpi_ibm.ko...done. >> Loaded symbols for /boot/kernel/acpi_ibm.ko >> Reading symbols from /boot/kernel/iwm7260fw.ko...done. >> Loaded symbols for /boot/kernel/iwm7260fw.ko >> Reading symbols from /boot/kernel/coretemp.ko...done. >> Loaded symbols for /boot/kernel/coretemp.ko >> Reading symbols from /boot/kernel/if_iwm.ko...done. >> Loaded symbols for /boot/kernel/if_iwm.ko >> Reading symbols from /boot/kernel/acpi_video.ko...done. >> Loaded symbols for /boot/kernel/acpi_video.ko >> Reading symbols from /boot/kernel/nullfs.ko...done. >> Loaded symbols for /boot/kernel/nullfs.ko >> Reading symbols from /boot/kernel/fdescfs.ko...done. >> Loaded symbols for /boot/kernel/fdescfs.ko >> Reading symbols from /boot/kernel/i915kms.ko...done. >> Loaded symbols for /boot/kernel/i915kms.ko >> Reading symbols from /boot/kernel/drm2.ko...done. >> Loaded symbols for /boot/kernel/drm2.ko >> Reading symbols from /boot/kernel/iicbus.ko...done. >> Loaded symbols for /boot/kernel/iicbus.ko >> Reading symbols from /boot/kernel/iic.ko...done. >> Loaded symbols for /boot/kernel/iic.ko >> Reading symbols from /boot/kernel/iicbb.ko...done. >> Loaded symbols for /boot/kernel/iicbb.ko >> #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 >> 1324 CPU_SET_ATOMIC(cpu, &stopped_cpus); >> (kgdb) bt >> #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324 >> #1 0xffffffff80e29fb4 in ipi_nmi_handler () at >> /usr/src/sys/x86/x86/mp_x86.c:1280 >> #2 0xffffffff80d09a79 in trap (frame=3D0xffffffff8158bef0) >> at /usr/src/sys/amd64/amd64/trap.c:188 >> #3 0xffffffff80cec054 in nmi_calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:633 >> #4 0xffffffff80e1aaef in acpi_cpu_idle_mwait (mwait_hint=3D0) at >> cpufunc.h:611 >> Previous frame inner to this frame (corrupt stack?) >> Current language: auto; currently minimal >> >> kgdb is over my head, but I can provide more details under some guidance= . >> >> Hope it helps, >> Juan >> >> > > > -- > Mateusz Guzik > --=20 Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Feb 20 21:46:07 2018 Return-Path: Delivered-To: freebsd-current@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 AFB51F06709 for ; Tue, 20 Feb 2018 21:46:07 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 D32C571F26 for ; Tue, 20 Feb 2018 21:46:06 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id v9so6307213lfa.11 for ; Tue, 20 Feb 2018 13:46:06 -0800 (PST) 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:content-transfer-encoding; bh=uqZf+Uoq2fMajBXd+BWoQ4luUH8Ts+kqJ+KVyfYHtnk=; b=IMhrIODyR4eF3K1PeJtqyE5mKHcWuwcfDS2NFl7PZaEEfIiIQJZDMvdF1Qa4qX5Irk zuO9IXwPb35wFbNebEHZ4cbFyHT5qrUBQgR8cCc1ANC3SXhD8gj6O6eZlB3ltaTSysnh RYUnsD9ijH9ZhY8pb5uGUQiFpLQAEPhFg0DvxY3iOweQjFICh5yMEelHh7W//sQx+tM/ lygXxlTjM9xKiFPloFF7MN3jluVlvCdj6htqlzpT2gOPZ8ThAK9qzJtHUBoc9LDPVTUn JnLhXHMW7o2Ahzakq0LIRb4q7DcUcVgc6Rf/9lsndiTv+Un/HF7Senpx3amHhox775Iq 5STQ== X-Gm-Message-State: APf1xPBCmNZTe7C+A5L47Vyustxu5hkUorlbboFYNtOPPhmTkFNc9ZiW NELdwUFzDqQ3wtL1pffaPvj3nmOX X-Google-Smtp-Source: AH8x227nt/vEtkGxNbzdgJKK5CWPlF/I9XugLJKJmaFob75VG5DgJ3yQdvzBFtK7xBSadzKeOxI0jg== X-Received: by 10.25.76.9 with SMTP id z9mr702887lfa.141.1519163164828; Tue, 20 Feb 2018 13:46:04 -0800 (PST) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com. [209.85.215.43]) by smtp.gmail.com with ESMTPSA id l1sm1523549ljc.91.2018.02.20.13.46.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 13:46:04 -0800 (PST) Received: by mail-lf0-f43.google.com with SMTP id j193so6360095lfe.0 for ; Tue, 20 Feb 2018 13:46:04 -0800 (PST) X-Received: by 10.46.114.10 with SMTP id n10mr752146ljc.74.1519163163743; Tue, 20 Feb 2018 13:46:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Tue, 20 Feb 2018 13:45:43 -0800 (PST) In-Reply-To: <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Tue, 20 Feb 2018 15:45:43 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 21:46:07 -0000 On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor wrote: > [... snip ...] > > Moreover, the "boot [kernel]" loader command does not work: > > OK ls /boot/kernel.old/kernel > /boot/kernel.old/kernel > OK boot kernel.old > Command failed > OK boot /boot/kernel.old/kernel > Command failed > OK boot kernel > Command failed > > On the other hand, just "boot" works. > This part should work as expected as of r329674, so please give that a shot. I'm still trying to see if I can reproduce your box drawing problem. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Wed Feb 21 02:27:18 2018 Return-Path: Delivered-To: freebsd-current@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 72208F21476 for ; Wed, 21 Feb 2018 02:27:18 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 000B17ED16 for ; Wed, 21 Feb 2018 02:27:17 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w1L2RB8u057161; Tue, 20 Feb 2018 18:27:18 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: <20180220123953.5e987691@ernst.home> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Date: Tue, 20 Feb 2018 18:27:17 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:27:18 -0000 On Tue, 20 Feb 2018 12:39:53 +0100 said > On Mon, 19 Feb 2018 14:18:15 -0800 > "Chris H" wrote: >=20 > > I'm seeing a number of messages like the following: > > kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d > >=20 > > and was wondering if it's anything to be concerned with, or whether > > fsck(8) is fixing them=2E > > This began to happen when the power went out on a new install: > > FreeBSD dns0 12=2E0-CURRENT FreeBSD 12=2E0-CURRENT #0: Wed Dec 13 06:07:59 = PST > > 2017 > > root@dns0:/usr/obj/usr/src/amd64=2Eamd64/sys/DNS0 amd64 > > which hadn't yet been hooked up to the UPS=2E > > I performed an fsck in single user mode upon power-up=2E Which ended with= the > > mount points being masked CLEAN=2E I was asked if I wanted to use the JOU= RNAL=2E > > I answered Y=2E > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thu= sly: > > newfs -U -j > >=20 > > Thank you for all your time, and consideration=2E > >=20 >=20 > fsck fixes these errors only when the user does NOT use the journal=2E > You should re-do the fsck=2E This doesn't seem quite right=2E That is; fsck(8) /should/ fix it when soft j= ournaling is enabled=2E Otherwise the -j option, to newfs(8) and journaling have no val= ue=2E OTOH you are indeed correct in that "falling through" will correct any erro= rs=2E I used that option after submitting this question=2E But there /does/ appear to= be a regression=2E As this has never been the case in earlier versions of FreeBSD=2E= fe; imposing the same conditions on an 11, or 9=2E3 system does NOT exhibit this = problem=2E I literally pulled the plug on 2 systems (1 @11, and 1 @9=2E3) and fsck(8) us= ing the journal happily fixed the errors, without any latter fallout as describ= ed in this message=2E Thank you very much Gary, for taking the time to reply! --Chris >=20 > --=20 > Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Feb 21 03:56:57 2018 Return-Path: Delivered-To: freebsd-current@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 D3D2EF27D3B for ; Wed, 21 Feb 2018 03:56:56 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FCAB831F9; Wed, 21 Feb 2018 03:56:56 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id z197so389395qkb.6; Tue, 20 Feb 2018 19:56:56 -0800 (PST) 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=IyvBkC1rOFCJQfQnoWezlBF30S/DwXSX+c040DyCK2k=; b=MMUfpdc/516LaEEH+pUXQocBgkmNeE1hov2+526D8qKK6DUyPZi2KRfBBQukqh825p b7P2WqlnDese+wvB1yC6AihC6PjOCNBTRehiANSPbhhSv3AGKxBFLEij4Z1VzDMvtBb7 gk/5Jh54GJMSIudcUlTeTRSLa+P3oplpyNVWSjkj/uFVnvTBoAeQ3Dwk5Q7u6A/BfrEV uNQZg27gCXJlxutQanuQmkUjkUzK1RaD6LhZUZRehXjOihDDvOoWuEXfSy/w5aXwtVdD S1r3ZaQxrdtn5F7H8jywtOmpFqSYLbF/0McYmZyELemqggiIHrPu3gq1PcbzJm91rURc t25w== 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=IyvBkC1rOFCJQfQnoWezlBF30S/DwXSX+c040DyCK2k=; b=CCPE9OG24BVPPy2fcld56bc4rwpR9ExsZgSfMlmhrnDRLowQ1n47vw4dyaLQ5No9xS HgGgeNhRj82gqRAevbnCWfwj0/QKH/Cp6OAp1Qi1C6dtA8RwE/NX1Q/73OTRtwVDmWDH PJ2tr0WiKYjhHmgclKRL/wjAn+53BmhM3Brq+krWGPaR+phhJKOF/l8N+YqS5mZe8ieT t0z/f0p31XtlpqVGqx7rMwM3nYvTfLF2Dz4Q6/lZdEPv+6XvJIYhYpDj45x2lGVIxW+Y ycG3rl8ESSLjQ1hBj7H541ggj7sJWeXHpoWwknz/NH/vrVF+7FMuXP5s7iJynyERhVA6 jPEw== X-Gm-Message-State: APf1xPDPJtEGUFObcPki5fUVB106MJ0omnhm2IbG6yoAIaIK500DpxVk Xp/c6q6RO+u0pNlWUbPhZy9bj31vyxvXwhT/yF2uUg== X-Google-Smtp-Source: AG47ELtyFc14ZnNwZwbXd7utPP83NswK8DPKDkJEEKT09JFIDCCeIwoNTRE7vY9xbB7SX+XwFGxCT0/pBsuxZi7HDFE= X-Received: by 10.55.169.1 with SMTP id s1mr3021989qke.96.1519185415574; Tue, 20 Feb 2018 19:56:55 -0800 (PST) MIME-Version: 1.0 Sender: tommi.pernila@gmail.com Received: by 10.200.6.196 with HTTP; Tue, 20 Feb 2018 19:56:54 -0800 (PST) Received: by 10.200.6.196 with HTTP; Tue, 20 Feb 2018 19:56:54 -0800 (PST) In-Reply-To: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> From: Tommi Pernila Date: Wed, 21 Feb 2018 05:56:54 +0200 X-Google-Sender-Auth: sP_f_ku5fn6xcO4UeHciS7YcWF0 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:56:57 -0000 Hi Eric, could you provide a brief update how the work is going? Br, Tommi On Nov 16, 2017 04:29, "Eric McCorkle" wrote: Right, so basically, the remaining GELI patches are against loader, and most of them can go in independently of the work on removing boot1. There's a unanimous consensus on getting rid of boot1 which includes its original author, so that's going to happen. For GELI, we have the following (not necessarily in order): a) Adding the KMS interfaces, pseudo-device, and kernel keybuf interactions b) Modifications to the efipart driver c) boot crypto d) GELI partition types (not strictly necessary) Then there's the GELI driver itself. (a) and (c) are good to land, (b) needs some more work after Toomas Soome pointed out a legitimate problem, and (d) actually needs a good bit more code (but again, it's more cosmetic). Additionally, the GELI driver will need further mods to efipart to be written (nothing too big). But we could go ahead with (a) and (c), as they've already been proven to work. I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with the 7th RISC-V workshop at the end of the month. Once this stuff is all in, loader should handle any GELI volumes it finds, and it should Just Work once boot1 is gone. From owner-freebsd-current@freebsd.org Wed Feb 21 04:01:44 2018 Return-Path: Delivered-To: freebsd-current@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 ED987F28259 for ; Wed, 21 Feb 2018 04:01:43 +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 781A8836F2 for ; Wed, 21 Feb 2018 04:01:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1L41dxj039103 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 20 Feb 2018 20:01:42 -0800 (PST) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: A small procedural request Message-ID: <1ec9ccb4-0f0e-e525-4ce8-71d9d34172ae@freebsd.org> Date: Wed, 21 Feb 2018 12:01:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 04:01:44 -0000 Hi,  I have a very small request to those committing into head. If you commit a fix, then if it is possible to easily do so, can you give the revision number in which the regression was introduced? like "this was  broken in r329xxx" this allows people who are looking for specific problems to say "Ok that bug was introduced after the snapshot I'm working on and can't be my issue". (we are not always working on the very tip). thanks Julian From owner-freebsd-current@freebsd.org Wed Feb 21 06:16:42 2018 Return-Path: Delivered-To: freebsd-current@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 7B94EF087FE for ; Wed, 21 Feb 2018 06:16:42 +0000 (UTC) (envelope-from lists@opsec.eu) 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 1DC81687B2 for ; Wed, 21 Feb 2018 06:16:42 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id D1049F087FC; Wed, 21 Feb 2018 06:16:41 +0000 (UTC) Delivered-To: current@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 BFD7AF087F9 for ; Wed, 21 Feb 2018 06:16:41 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2ED687B0 for ; Wed, 21 Feb 2018 06:16:41 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eoNhm-00066D-SO; Wed, 21 Feb 2018 07:16:38 +0100 Date: Wed, 21 Feb 2018 07:16:38 +0100 From: Kurt Jaeger To: Shane Ambler Cc: current@freebsd.org Subject: Re: How to find CPU microcode version ? Message-ID: <20180221061638.GM32429@home.opsec.eu> References: <20180218104137.GA32429@home.opsec.eu> <057ac894-7362-b235-3859-65108b2afb76@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <057ac894-7362-b235-3859-65108b2afb76@ShaneWare.Biz> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 06:16:42 -0000 Hi! > One situation that can cause out of swap errors is large amounts of > wired ram. Indeed: Very large amounts of wired RAM. What happened ? This did not happen before the last upgrade ? I'm at r328899. CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle Mem: 2472K Active, 8K Inact, 31G Wired, 515M Free ARC: 25G Total, 19G MFU, 3792M MRU, 840K Anon, 492M Header, 2040M Other 22G Compressed, 36G Uncompressed, 1.67:1 Ratio Swap: 34G Total, 76M Used, 34G Free, 8K In, 92K Out -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Wed Feb 21 06:20:53 2018 Return-Path: Delivered-To: freebsd-current@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 5666DF08B8A for ; Wed, 21 Feb 2018 06:20:53 +0000 (UTC) (envelope-from lists@opsec.eu) 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 EFA3968A0F for ; Wed, 21 Feb 2018 06:20:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id AB98DF08B89; Wed, 21 Feb 2018 06:20:52 +0000 (UTC) Delivered-To: current@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 9981FF08B87 for ; Wed, 21 Feb 2018 06:20:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3424D68A0B for ; Wed, 21 Feb 2018 06:20:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eoNlr-00068m-P4 for current@freebsd.org; Wed, 21 Feb 2018 07:20:51 +0100 Date: Wed, 21 Feb 2018 07:20:51 +0100 From: Kurt Jaeger To: current@freebsd.org Subject: Re: How to find CPU microcode version ? Message-ID: <20180221062051.GA23558@home.opsec.eu> References: <20180218104137.GA32429@home.opsec.eu> <057ac894-7362-b235-3859-65108b2afb76@ShaneWare.Biz> <20180221061638.GM32429@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180221061638.GM32429@home.opsec.eu> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 06:20:53 -0000 Hi! > > One situation that can cause out of swap errors is large amounts of > > wired ram. > > Indeed: Very large amounts of wired RAM. What happened ? This > did not happen before the last upgrade ? I'm at r328899. vfs.zfs.arc_max was at 32345493504 changed that to vfs.zfs.arc_max=16172746752 Looks better now. -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Wed Feb 21 10:27:39 2018 Return-Path: Delivered-To: freebsd-current@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 E771BF1B177 for ; Wed, 21 Feb 2018 10:27:38 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.20]) (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 817057159C for ; Wed, 21 Feb 2018 10:27:38 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2629.sfr.fr (SMTP Server) with ESMTP id 6FE6A1C017432 for ; Wed, 21 Feb 2018 11:27:31 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2629.sfr.fr (SMTP Server) with ESMTPSA; Wed, 21 Feb 2018 11:27:29 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mateusz Guzik Cc: FreeBSD Current References: <038d9336-9ee7-c079-5ad5-f023c6a306eb@club.fr> From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Message-ID: Date: Wed, 21 Feb 2018 11:27:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 10:27:39 -0000 Le 20/02/2018 à 21:20, Mateusz Guzik a écrit : > Committed in https://svnweb.freebsd.org/base?view=revision&revision=329660 > > thanks for reporting Thanks Mateusz, Konstantin, issue solved. From owner-freebsd-current@freebsd.org Wed Feb 21 10:43:29 2018 Return-Path: Delivered-To: freebsd-current@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 103BAF1C69C for ; Wed, 21 Feb 2018 10:43:29 +0000 (UTC) (envelope-from listjm@club.fr) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.20]) (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 9B9B672102 for ; Wed, 21 Feb 2018 10:43:28 +0000 (UTC) (envelope-from listjm@club.fr) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) by msfrf2629.sfr.fr (SMTP Server) with ESMTP id 849541C030C16 for ; Wed, 21 Feb 2018 11:43:27 +0100 (CET) Received: from [192.168.1.51] (125.164.7.84.rev.sfr.net [84.7.164.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juanmolina@sfr.fr) by msfrf2629.sfr.fr (SMTP Server) with ESMTPSA; Wed, 21 Feb 2018 11:43:27 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=juanmolina@sfr.fr Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans Cc: FreeBSD Current References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor Message-ID: Date: Wed, 21 Feb 2018 11:43:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-sfr-mailing: LEGIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 10:43:29 -0000 Le 20/02/2018 à 22:45, Kyle Evans a écrit : > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor wrote: >> [... snip ...] >> >> Moreover, the "boot [kernel]" loader command does not work: >> >> OK ls /boot/kernel.old/kernel >> /boot/kernel.old/kernel >> OK boot kernel.old >> Command failed >> OK boot /boot/kernel.old/kernel >> Command failed >> OK boot kernel >> Command failed >> >> On the other hand, just "boot" works. >> > > This part should work as expected as of r329674, so please give that a > shot. I'm still trying to see if I can reproduce your box drawing > problem. > > Thanks, > > Kyle Evans > Thanks Kyle. boot command works now. There is though a somewhat strangely formulated messages when trying to load an non-existent kernel: OK boot fake Failed to load kernel ’fake’ Failed to load any kernel can’t load ’kernel’ The two last lines are odd: Did the loader try to load a fallback kernel and failed? That would explain the ’kernel’ name in quotes, but I have such a kernel… Also, just nitpicking, but "can’t" should be capitalized. Then, I have just remembered why I was seeing a higher resolution menu before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new loader is not implementing the inclusion of this file, because I can change the gop mode in the loader with 'gop set [0-3]'. This has thus nothing to do with the drawing lines, I guess. Best regards. From owner-freebsd-current@freebsd.org Wed Feb 21 11:14:16 2018 Return-Path: Delivered-To: freebsd-current@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 8A74CF1FFE9 for ; Wed, 21 Feb 2018 11:14:16 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 E3C2173598 for ; Wed, 21 Feb 2018 11:14:15 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-70-98.dz.commufa.jp [124.18.70.98]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w1LBE6OW073169 for ; Wed, 21 Feb 2018 20:14:06 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 21 Feb 2018 20:14:05 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: A small procedural request Message-Id: <20180221201405.4c0b1262e2f239616120869a@dec.sakura.ne.jp> In-Reply-To: <1ec9ccb4-0f0e-e525-4ce8-71d9d34172ae@freebsd.org> References: <1ec9ccb4-0f0e-e525-4ce8-71d9d34172ae@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 11:14:16 -0000 Hi. +1. But have one suggestion for format. Something like Broken by: rXXXXXXX Broken by: Unknown (Bugfix but the revision introduced it is unknown) and optionally Broken by: No (To emphasize it's NOT a bugfix.) would be better for scripts already handling "MFC after: " or "X-MFC-With: " etc. to support this. If put on the top with "MFC rXXXXXX: Comments", it can be FIX rXXXXXX: Comments or for multiple revisions, FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals FIX rXXXXXX-rYYYYYY: Comments for massive continuous range would be better. Regards. On Wed, 21 Feb 2018 12:01:33 +0800 Julian Elischer wrote: > Hi,$B".(B I have a very small request to those committing into head. > > If you commit a fix, then if it is possible to easily do so, can you > give the revision number in which the regression was introduced? > > like "this was$B".(B broken in r329xxx" > > this allows people who are looking for specific problems to say "Ok > that bug was introduced after the snapshot I'm working on and can't be > my issue". > > (we are not always working on the very tip). > > > thanks > > Julian > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Wed Feb 21 12:36:28 2018 Return-Path: Delivered-To: freebsd-current@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 34796F26CF4 for ; Wed, 21 Feb 2018 12:36:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ADE547711D for ; Wed, 21 Feb 2018 12:36:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 72455F26CE9; Wed, 21 Feb 2018 12:36:27 +0000 (UTC) Delivered-To: current@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 3547CF26CE8 for ; Wed, 21 Feb 2018 12:36:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83BC777118; Wed, 21 Feb 2018 12:36:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w1LCaHom074363; Wed, 21 Feb 2018 12:36:17 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w1LCaHqW074362; Wed, 21 Feb 2018 04:36:17 -0800 (PST) (envelope-from david) Date: Wed, 21 Feb 2018 04:36:17 -0800 From: David Wolfskill To: kevans@freebsd.org Cc: imp@freebsd.org, current@freebsd.org Subject: Kernel selection in Lua loader Message-ID: <20180221123617.GD1212@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, kevans@freebsd.org, imp@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ROA1rv1+fHr2QGor" Content-Disposition: inline User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 12:36:28 -0000 --ROA1rv1+fHr2QGor Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The Lua loader appears to be using a mechanism other than the "kernels=3D..." specification in /boot/loader.conf to slect potential kernels to load. I'm not claiming this is "bad" -- just "different." I noticed because I sometimes build a kernel that ... panics, or some such thing, so I hve had occasion to make use of kernel.old. But in the process of engaging a developer and trying patches, the default behavior is that kernel.old gets overwritten next time I build a kernel. So I had taken to copying /boot/*.old to /boot/*.save manually as the occasion warrants; I modified /boot/loader.conf to include: kernels=3D"kernel kernel.old kernel.save" and the Forth loader presented (precisely) those kernels as the available options for selecting a kernel to load and boot. Usually, if I manually copy/move kernels around, I also save the kernel that misbehaved (in case further poking around in its internals may be warranted); a typical name for such a beast is "kernel.panic" (as I usually have at most a single such misbehaving kernel around). Thus, I noticed when I did my smoke-test boot after freshily building: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #108 r3297= 03M/329706:1200058: Wed Feb 21 04:04:36 PST 2018 root@g1-215.catwhisker= =2Eorg:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY amd64 with the Lua loader, I was being offered a choice among 4 kernels (rather than the expected 3). Cycling through them (twice; I wanted to be sure the behavior was reproducible), I noted that the presented options were: * default/kernel * kernel.old * kernel.save * kernel.panic (in that sequence). I did not attempt to select any of the non-default options, however. :-) Nor did I remove the 'kernels=3D"kernel kernel.old kernel.save"' specificaton from /boot/loader.conf to see what would happen. Peace, david --=20 David H. Wolfskill david@catwhisker.org Yes, the indictments don't "prove" guilt; that's what trials are for. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ROA1rv1+fHr2QGor Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlqNZ8FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7hfbkAf/a50GwLoUifQDBDmPTOApgf6VNLMzpyi+//xrhiyH34mM6lLGMYEN2fz2 TXM3GJEsqlZncw2VpmsDcca7PVBpsIYPXJGs5TmK4/6WkwmBO+TSTbnMjcgLIKqW nzETRMW/p9ifXWEaMwdytCdfxjBQcHzYxAKsdK4/YcqA1JOiIJ+e8CB3OhZYGXPs 0QoAwfo6q3DFIPUNuFdxyduC1W5ZSsqhjbyi6DlayhgN+dLYqVlRNEo3dc8B9lHB dfkYCMCJl8GcG7hBJ+PCPtOdD3NRGXwrgZbzuQ45Gkcn5aaP+2HE9P7/vNTewI8q cKSRYORty6/oAsP3ggAV8ug9NWb+ug== =a0h9 -----END PGP SIGNATURE----- --ROA1rv1+fHr2QGor-- From owner-freebsd-current@freebsd.org Wed Feb 21 13:58:56 2018 Return-Path: Delivered-To: freebsd-current@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 DE07EF03DA5 for ; Wed, 21 Feb 2018 13:58:55 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 517C87BB9C; Wed, 21 Feb 2018 13:58:55 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id g72so2481393lfg.5; Wed, 21 Feb 2018 05:58:55 -0800 (PST) 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:content-transfer-encoding; bh=MLb5SKa32krWl5fQNm8rtlvRyzh4G5OWWCf6v0A7A90=; b=AVM8rEbhglKFUf1EcYdPgy+5til365Q23bkEJkQZ2CLv5F4O35ietYM2PAPwnsEQob Vj0iGgV9D986wOjtv25WtDo+i4NDvjAa9gCG738wwFOtNvZ1wNVCXqPuRFgXh7myOmuv Ssv38LZzg4Qr0rdb9/I8Cp5PLUFzCyHKPtX3cfdYANF8mBXsCZ/QEjJ39V9KgWREXPEd hkvnSlujg6eBq1EtarC3mdN0ptCkK6xOpzQYqabqVT4KIisOdabKN/jZtfz7IxpKsetw gW/MagEvMymwd2uW8xGyoxgumtPah+GHUPdD8/gf1lVFDcx9WwBKt50UILCcPZGj8uDY XpBQ== X-Gm-Message-State: APf1xPAZE6rPMMOPNSL32VKSHZ6BGKbTsnnXvoX5OlDsBheIkL91VYSi Rt4kAWSc9bHxr3vAnbnLFIxcMqnb X-Google-Smtp-Source: AH8x2249kQqlb4+5g3FKr/yLPTssxSI9EX8K1awptlucI42YPY+ky2wUiL6VhHwfIaadPUxvl3DdUg== X-Received: by 10.46.29.147 with SMTP id w19mr2370050lje.70.1519221527208; Wed, 21 Feb 2018 05:58:47 -0800 (PST) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com. [209.85.215.47]) by smtp.gmail.com with ESMTPSA id k8sm165148ljk.63.2018.02.21.05.58.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 05:58:47 -0800 (PST) Received: by mail-lf0-f47.google.com with SMTP id t79so2492587lfe.3; Wed, 21 Feb 2018 05:58:47 -0800 (PST) X-Received: by 10.46.64.203 with SMTP id r72mr2654570lje.38.1519221526708; Wed, 21 Feb 2018 05:58:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Wed, 21 Feb 2018 05:58:24 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Wed, 21 Feb 2018 07:58:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= Cc: rgrimes@freebsd.org, FreeBSD Current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 13:58:56 -0000 On Wed, Feb 21, 2018 at 4:43 AM, Juan Ram=C3=B3n Molina Menor wrote: > Le 20/02/2018 =C3=A0 22:45, Kyle Evans a =C3=A9crit : >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor >> wrote: >>> >>> [... snip ...] >>> >>> Moreover, the "boot [kernel]" loader command does not work: >>> >>> OK ls /boot/kernel.old/kernel >>> /boot/kernel.old/kernel >>> OK boot kernel.old >>> Command failed >>> OK boot /boot/kernel.old/kernel >>> Command failed >>> OK boot kernel >>> Command failed >>> >>> On the other hand, just "boot" works. >>> >> >> This part should work as expected as of r329674, so please give that a >> shot. I'm still trying to see if I can reproduce your box drawing >> problem. >> >> Thanks, >> >> Kyle Evans >> > > Thanks Kyle. > > boot command works now. There is though a somewhat strangely formulated > messages when trying to load an non-existent kernel: > > OK boot fake > Failed to load kernel =E2=80=99fake=E2=80=99 > Failed to load any kernel > can=E2=80=99t load =E2=80=99kernel=E2=80=99 > > The two last lines are odd: Did the loader try to load a fallback kernel = and > failed? That would explain the =E2=80=99kernel=E2=80=99 name in quotes, b= ut I have such a > kernel=E2=80=A6 Also, just nitpicking, but "can=E2=80=99t" should be capi= talized. (CC'ing Rod, since he also commented on this) I'm only directly responsible for the first two messages. =3D) I've removed the second one, though, since it was a carry-over from when it would try to load the selected kernel and then some default kernel that might be in your module_path. We can look at changing "can't load 'kernel'" to capitalize and remove the contraction, but that's common loader stuff and should've also been displayed for the same Forth scenario. > Then, I have just remembered why I was seeing a higher resolution menu > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new > loader is not implementing the inclusion of this file, because I can chan= ge > the gop mode in the loader with 'gop set [0-3]'. > Oy. This is actually a Forth file, so we can't really maintain all of the functionality that would have been allowed there. Technically, things like this should probably either appear in your loader.conf(5) in the form of 'exec=3D"gop set 3"' to be applied when loader.conf(5) is read, or we should provide some other means of running pure loader command scripts at different points in the loader sequence. (CC Warner, because he probably has thoughts about this latter idea) From owner-freebsd-current@freebsd.org Wed Feb 21 14:12:29 2018 Return-Path: Delivered-To: freebsd-current@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 9E365F04FE4 for ; Wed, 21 Feb 2018 14:12:29 +0000 (UTC) (envelope-from byond.lenox@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 35C1F7CCAC for ; Wed, 21 Feb 2018 14:12:29 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id EAA05F04FBF; Wed, 21 Feb 2018 14:12:28 +0000 (UTC) Delivered-To: current@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 C8746F04FBD for ; Wed, 21 Feb 2018 14:12:28 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (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 540427CCA8; Wed, 21 Feb 2018 14:12:28 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f43.google.com with SMTP id v9so2538706lfa.11; Wed, 21 Feb 2018 06:12:28 -0800 (PST) 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=Db4IogvptC1Cg/6pKiLuoaSCGt+NUKZ9L3/JVoClazM=; b=fqEM1b/GGw61Z6T10EUvkrOh2cxfVQJVoa1KmVP3HtdeDN8xiKDIlfwBMv+C2vYS1/ 8fAiy+1iLSZDVJ0aN/bkQzEqZ6hyxi/2VUdVZH6UZOPnfTGLQdgoK4+6rPDVjk/s35AU ba66wTfHJDNToRLxqGZ5M9b4JbbXkVaREjmeSwb2SvmLGv3P2RM6WSYIEFSJ1dP+t4bg J/KYe2rioiracS/y8RKvcFz1qf2hZAzoA3p0p1yEMoJU6mGyg2htqYXg0shGww+MY/qD ku9R8vHA4lqXJXm2pi/JE3OEvC/10cfSbGb3LaMVVx5JVxkJmj7gZ0EqijeOxnrLoDS8 pBKg== X-Gm-Message-State: APf1xPCw5EAQ9FLBMDtH2kUF3VbrXCcFDszBtfXpVRaSC24JT17V1UXZ OGsnvSd/0jg6pYal8iTaJxXH8Zk+ X-Google-Smtp-Source: AH8x224jjvGNqFs3NSN1hxzQi3hxS+4XrWQGvpVMVjcdBa5hVig/7G3r1xE88sN9y3SW3mFHxzT0eA== X-Received: by 10.46.77.90 with SMTP id a87mr2620465ljb.41.1519222340623; Wed, 21 Feb 2018 06:12:20 -0800 (PST) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com. [209.85.215.49]) by smtp.gmail.com with ESMTPSA id e27sm2228609lfb.20.2018.02.21.06.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 06:12:20 -0800 (PST) Received: by mail-lf0-f49.google.com with SMTP id g72so2546919lfg.5; Wed, 21 Feb 2018 06:12:20 -0800 (PST) X-Received: by 10.25.201.76 with SMTP id z73mr2574121lff.74.1519222340178; Wed, 21 Feb 2018 06:12:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Wed, 21 Feb 2018 06:11:59 -0800 (PST) In-Reply-To: <20180221123617.GD1212@albert.catwhisker.org> References: <20180221123617.GD1212@albert.catwhisker.org> From: Kyle Evans Date: Wed, 21 Feb 2018 08:11:59 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Kernel selection in Lua loader To: current@freebsd.org, imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:12:29 -0000 On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote: > The Lua loader appears to be using a mechanism other than the > "kernels=..." specification in /boot/loader.conf to slect potential > kernels to load. I'm not claiming this is "bad" -- just "different." > > I noticed because I sometimes build a kernel that ... panics, or some > such thing, so I hve had occasion to make use of kernel.old. But in the > process of engaging a developer and trying patches, the default behavior > is that kernel.old gets overwritten next time I build a kernel. > > So I had taken to copying /boot/*.old to /boot/*.save manually as the > occasion warrants; I modified /boot/loader.conf to include: > > kernels="kernel kernel.old kernel.save" > > and the Forth loader presented (precisely) those kernels as the > available options for selecting a kernel to load and boot. > Right, so, we (and by we I mean cem@) actually implemented a form of auto-detection for kernels. Any directory in in /boot with a file named 'kernel' inside will be automatically listed, and that supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5). (*) I use "supplemented" because I changed that in r329709, just a little bit ago, to not do the autodetection if a 'kernels' is explicitly set in loader.conf(5) My reasoning here is that there's probably a reason one has set it explicitly, whether it be to hide bogus kernels or just to slim down the list of kernels they need to cycle through. > [ ... snip ... ] From owner-freebsd-current@freebsd.org Wed Feb 21 14:22:23 2018 Return-Path: Delivered-To: freebsd-current@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 4C39EF05F73 for ; Wed, 21 Feb 2018 14:22:23 +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 DFC297D8D4 for ; Wed, 21 Feb 2018 14:22:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1LEMEZi041678 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Feb 2018 06:22:17 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: A small procedural request To: Tomoaki AOKI , freebsd-current@freebsd.org References: <1ec9ccb4-0f0e-e525-4ce8-71d9d34172ae@freebsd.org> <20180221201405.4c0b1262e2f239616120869a@dec.sakura.ne.jp> From: Julian Elischer Message-ID: <7c133301-deb6-e747-3932-1c4cf67bced9@freebsd.org> Date: Wed, 21 Feb 2018 22:22:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180221201405.4c0b1262e2f239616120869a@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:22:23 -0000 On 21/2/18 7:14 pm, Tomoaki AOKI wrote: > Hi. > > +1. But have one suggestion for format. > Something like > > Broken by: rXXXXXXX > Broken by: Unknown (Bugfix but the revision introduced it is unknown) > > and optionally > > Broken by: No (To emphasize it's NOT a bugfix.) I think that is probably too much, but the        Broken by:  would be good. > > would be better for scripts already handling "MFC after: " or > "X-MFC-With: " etc. to support this. > > If put on the top with "MFC rXXXXXX: Comments", it can be > > FIX rXXXXXX: Comments possibly.. that Would allow some sort of collection of the data to  suggest good places to retrospectively base your head following (but not too closely) branches. but may be more work that people are willing to do.. For myself, just a hint of where the bug was introduced would help a lot. further more if you have a branch/product based at some point in time, this would help you to know when a patch needs to be cherry picked back to your code. > > or for multiple revisions, > > FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals > FIX rXXXXXX-rYYYYYY: Comments for massive continuous range > > would be better. > > Regards. > > > On Wed, 21 Feb 2018 12:01:33 +0800 > Julian Elischer wrote: > >> Hi,〓 I have a very small request to those committing into head. >> >> If you commit a fix, then if it is possible to easily do so, can you >> give the revision number in which the regression was introduced? >> >> like "this was〓 broken in r329xxx" >> >> this allows people who are looking for specific problems to say "Ok >> that bug was introduced after the snapshot I'm working on and can't be >> my issue". >> >> (we are not always working on the very tip). >> >> >> thanks >> >> Julian >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> > From owner-freebsd-current@freebsd.org Wed Feb 21 13:09:40 2018 Return-Path: Delivered-To: freebsd-current@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 9D5A3F000DD for ; Wed, 21 Feb 2018 13:09:40 +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 1ADDB78A3B; Wed, 21 Feb 2018 13:09:39 +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 w1LD9NDJ086047; Wed, 21 Feb 2018 05:09:23 -0800 (PST) (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 w1LD9Lr7086046; Wed, 21 Feb 2018 05:09:21 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201802211309.w1LD9Lr7086046@pdx.rh.CN85.dnsmgr.net> Subject: Re: ACPI panic on boot with new Lua loader and other minor issues In-Reply-To: To: =?ISO-8859-1?Q?Juan_Ram=F3n_Molina_Menor?= Date: Wed, 21 Feb 2018 05:09:21 -0800 (PST) CC: Kyle Evans , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 21 Feb 2018 14:50:44 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 13:09:40 -0000 > Le 20/02/2018 ? 22:45, Kyle Evans a ?crit?: > > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram?n Molina Menor wrote: > >> [... snip ...] > >> > >> Moreover, the "boot [kernel]" loader command does not work: > >> > >> OK ls /boot/kernel.old/kernel > >> /boot/kernel.old/kernel > >> OK boot kernel.old > >> Command failed > >> OK boot /boot/kernel.old/kernel > >> Command failed > >> OK boot kernel > >> Command failed > >> > >> On the other hand, just "boot" works. > >> > > > > This part should work as expected as of r329674, so please give that a > > shot. I'm still trying to see if I can reproduce your box drawing > > problem. > > > > Thanks, > > > > Kyle Evans > > > > Thanks Kyle. > > boot command works now. There is though a somewhat strangely formulated > messages when trying to load an non-existent kernel: > > OK boot fake > Failed to load kernel ?fake? > Failed to load any kernel > can?t load ?kernel? > > The two last lines are odd: Did the loader try to load a fallback kernel > and failed? That would explain the ?kernel? name in quotes, but I have > such a kernel? Also, just nitpicking, but "can?t" should be capitalized. To be supper nt picky can't should also be spelled can not. > Then, I have just remembered why I was seeing a higher resolution menu > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new > loader is not implementing the inclusion of this file, because I can > change the gop mode in the loader with 'gop set [0-3]'. > > This has thus nothing to do with the drawing lines, I guess. > > Best regards. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Feb 21 14:55:06 2018 Return-Path: Delivered-To: freebsd-current@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 AF001F090F3 for ; Wed, 21 Feb 2018 14:55:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 3E2227F87F for ; Wed, 21 Feb 2018 14:55:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id t22so2407529iob.3 for ; Wed, 21 Feb 2018 06:55:06 -0800 (PST) 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=hgJUYyKx0DUr06Rt0mqjxkv8Mz8iPvpm+JBzet8nWmo=; b=0AiDP+gdVCRkhYTNsdvO5R0fYQEq4VJ3Cfigq3ZWnIfBXhZyoOqC3uea0/uB6HKcDY 1hj+OdgIBPgmQmI/gj1ZImq4feG85Ai6rxTr+8x6PBvKa7Zgp29i3JVB14RzcCl9nZ9x L+XoyeSfoyBac0IoM8GSfPGU88xeo1j+7AjXorkSwlMyKIpEJX+CtNZbbINN6j94CxuH DBSg263C3d9zF3ugo4Eog8E3c7GbKgY09YEjQ1mH5dwjTbWEuWWvme0Mh2iJNtOq/lbw RWyKz9vg615yKUlrDJUOiGvD+AyTrUEZrBLtMRJWbbDYoKynQ7EXsqoCsdqQFcrBQXvE ny8A== 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=hgJUYyKx0DUr06Rt0mqjxkv8Mz8iPvpm+JBzet8nWmo=; b=tw0M293znbHpkKs6tDeGpdgbz5PZJrlYCHvNQpx+dEB6jtZPMyA9Ov8noVfUJw0fNg h4Bef+Jw6gaxqQaOr6PGcfBYBjAo5p4WwhVkv/ajw1Gf1b61EfzjU72dbx1Gd7PnKUxI txuzotzYVUxIHpz0KytQgR8X4cTHXZqvU0rGg/Slsf4oxOQlEpBv+gXpsni201u0EDoq T56Iapu9G1J61afTZbogcB3BkFNNKu1IkmdFm47yYwhOTUv1BXMRV4bIAMlNk4By0tdW dOJduXhgWQj1bQhl7Q1FP9UrnoqbvPOV2h9JlrazyFUkbvErjkeCgN1KQTy0w1HHVk6i yAXg== X-Gm-Message-State: APf1xPC85Obnz86oAfVmxc8DG7y8en/djTjfS2S59ge7+esp/2/GwoJk MZ/vXu7NaXN2QXl0NYiXpI/QsyfyN/J05cEhX3yRCA== X-Google-Smtp-Source: AG47ELvw714Vmt2q4oaECQMkQ5BHIJFYGRFCZBXfEQnn6wRzJ00s9IcaGlVqWmwZQ+JVeS6LagYK7kKezirbryvInsY= X-Received: by 10.107.2.6 with SMTP id 6mr4334870ioc.117.1519224905299; Wed, 21 Feb 2018 06:55:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 21 Feb 2018 06:55:04 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Warner Losh Date: Wed, 21 Feb 2018 07:55:04 -0700 X-Google-Sender-Auth: SsPfQOS9xl4ui3HrSuqAI2Il9O4 Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans Cc: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , "Rodney W. Grimes" , FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:55:07 -0000 On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote: > On Wed, Feb 21, 2018 at 4:43 AM, Juan Ram=C3=B3n Molina Menor > wrote: > > Le 20/02/2018 =C3=A0 22:45, Kyle Evans a =C3=A9crit : > >> > >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor < > listjm@club.fr> > >> wrote: > >>> > >>> [... snip ...] > >>> > >>> Moreover, the "boot [kernel]" loader command does not work: > >>> > >>> OK ls /boot/kernel.old/kernel > >>> /boot/kernel.old/kernel > >>> OK boot kernel.old > >>> Command failed > >>> OK boot /boot/kernel.old/kernel > >>> Command failed > >>> OK boot kernel > >>> Command failed > >>> > >>> On the other hand, just "boot" works. > >>> > >> > >> This part should work as expected as of r329674, so please give that a > >> shot. I'm still trying to see if I can reproduce your box drawing > >> problem. > >> > >> Thanks, > >> > >> Kyle Evans > >> > > > > Thanks Kyle. > > > > boot command works now. There is though a somewhat strangely formulated > > messages when trying to load an non-existent kernel: > > > > OK boot fake > > Failed to load kernel =E2=80=99fake=E2=80=99 > > Failed to load any kernel > > can=E2=80=99t load =E2=80=99kernel=E2=80=99 > > > > The two last lines are odd: Did the loader try to load a fallback kerne= l > and > > failed? That would explain the =E2=80=99kernel=E2=80=99 name in quotes,= but I have such a > > kernel=E2=80=A6 Also, just nitpicking, but "can=E2=80=99t" should be ca= pitalized. > > (CC'ing Rod, since he also commented on this) > > I'm only directly responsible for the first two messages. =3D) I've > removed the second one, though, since it was a carry-over from when it > would try to load the selected kernel and then some default kernel > that might be in your module_path. > > We can look at changing "can't load 'kernel'" to capitalize and remove > the contraction, but that's common loader stuff and should've also > been displayed for the same Forth scenario. > > > Then, I have just remembered why I was seeing a higher resolution menu > > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the ne= w > > loader is not implementing the inclusion of this file, because I can > change > > the gop mode in the loader with 'gop set [0-3]'. > > > > Oy. This is actually a Forth file, so we can't really maintain all of > the functionality that would have been allowed there. Technically, > things like this should probably either appear in your loader.conf(5) > in the form of 'exec=3D"gop set 3"' to be applied when loader.conf(5) is > read, or we should provide some other means of running pure loader > command scripts at different points in the loader sequence. (CC > Warner, because he probably has thoughts about this latter idea) > While loader.rc is FORTH, it's contrived FORTH designed to look like command line interaction. While some crazy people like me have actual forth in these, most do not, really (apart from the include /boot/XXX.4th lines, that is, which could be filtered). We have two choices here: Try to provide some level of compatibility shims, or provide a new way to say these things in Lua. In the original SoC code, loader.lua lived in /boot and looked to be something that people could modify. We likely need to do something similar. loader.lua right now has nothing but were in the forth world called 'include' and then very similar commands to the forth loader.rc. Perhaps the right answer is to move cli_execute out of /boot/lua/loader.lua, move that file up, and add the try-include functionality to try to include a loader.local.lua. Then we could tell people to move to the Lua syntax way of doing things. We'd have to hunt down all the hacks like this, but that wouldn't be terrible. Bonus points if we could convert the common ones either to lua code automatically, or to loader.conf variables. This specific example should have always been a loader.conf variable (and not an exec). While the gop command is useful, the loader should have, as part of it's forth sequence, had something that would set the GOP mode if the uefi_gop_mode loader.conf variable was set (I get why that wasn't done that way in the forth loader, insert rant of Fear of FORTH here). So we should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few other things that are simple settings to make it easier for users to set this stuff up and start to move away from the FoF kludges that we've accumulated. A new loader.conf variable would also allow coexistence of the two loaders, which will be further helped with some patches I have to the build system coming soon. Warner From owner-freebsd-current@freebsd.org Wed Feb 21 15:13:10 2018 Return-Path: Delivered-To: freebsd-current@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 939D4F0AC4C for ; Wed, 21 Feb 2018 15:13:10 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2354280989 for ; Wed, 21 Feb 2018 15:13:09 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from clamav.bulinfo.net (unknown [193.194.156.41]) by mx.bulinfo.net (Postfix) with ESMTP id 094005C4DA for ; Wed, 21 Feb 2018 17:04:35 +0200 (EET) Authentication-Results: mx.bulinfo.net; dkim=pass (1024-bit key) header.d=bulinfo.net header.i=@bulinfo.net header.b=OdKGz7+t X-Virus-Scanned: amavisd-new at bulinfo.net Received: from mx.bulinfo.net ([193.194.156.1]) by clamav.bulinfo.net (clamav.bulinfo.net [10.0.0.32]) (amavisd-new, port 10024) with ESMTP id tQ5UT__ZOmfc for ; Wed, 21 Feb 2018 17:04:24 +0200 (EET) Received: from [192.168.1.42] (strainer.bulinfo.net [193.194.156.5]) by mx.bulinfo.net (Postfix) with ESMTP id 26EFF5C42D for ; Wed, 21 Feb 2018 17:04:24 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bulinfo.net; s=sign; t=1519225464; bh=IxZCjmzs36D0wPH4yLf1HGfMrrU83UJ83Ep67vYh4vU=; h=From:Subject:To:Date; b=OdKGz7+tIsjV67lFH0iiSeEazGXLie8J4xrsHXUX6711uvLv1d0Mrqw/jCdGUCqRr uKUAaFfNLi0PcPwBojhmURMyDPVdfowoBUhLaJdq1fiHKKavDblcdxbmapyiq5x4qs R0Wkn6UF9DM/gK+i3BPVGINnPV1/py6ZrdlW+ECQ= From: Krassimir Slavchev Subject: GELI changes? To: Current FreeBSD Message-ID: <927f7364-e600-ab6b-c1ca-5966d87cabf2@bulinfo.net> Date: Wed, 21 Feb 2018 17:04:24 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:13:10 -0000 Hi All, On FreeBSD 8 & 9 I was able to use GELI on preloaded image providing keys either via loader.conf or via custom usb driver. On FreeBSD 11 & CURRENT I can not make usb drivers to load before GELI (e.g. MODULE_DEPEND(g_eli, my_usb_device, 1, 1, 1) in g_eli.c). Also, loading keys from loader.conf is not working (Cannot decrypt Master Key) which may be related to current EFI changes. On CURRENT loading keys from loader.conf produces kernel panic because cryptosoft is not initialized (opencrypto/crypto.c:497, CRYPTO_DRIVER_LOCK() spin mutex (null)). So, could we load USB layer before GELI? Is there a way to re-taste a GEOM provider a bit later but before root mount? Best regards, -- Krassimir Slavchev Bulinfo Ltd. krassi@bulinfo.net (+359 2) 9699 166 http://www.bulinfo.net (+359 2) 9699 160 From owner-freebsd-current@freebsd.org Wed Feb 21 15:37:13 2018 Return-Path: Delivered-To: freebsd-current@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 454C1F0DF03 for ; Wed, 21 Feb 2018 15:37:13 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.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 BDF4881DCA; Wed, 21 Feb 2018 15:37:12 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-ua0-f169.google.com with SMTP id z3so1270254uae.12; Wed, 21 Feb 2018 07:37:12 -0800 (PST) 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:content-transfer-encoding; bh=APwLQJs1AI5z0aKrXkG8vzxK7t/+8jgUZuw8Yfuljnw=; b=gx8Sv7pfM/bSDAKSO7HdXVJm1eZe1X9lH0tGHT7ZALDwhesUrDSYe+ZIXEkA/3puHV ZFmdWc5xHA6MtsSeNjTgcHCZ+iX750kQ+vCDT48q/fLsDln2nzMSkkzcy52mEelvJBye UqNuqjxRP/MqsZbGaPzYioLLCNy+nn5Vf4mfTh4vlkIjptrwHbeAilqxGvTtve/qXlWh WY4KDyXJPj9UzTD9OT31DsX4uEN6OAVB9yfnVldoVjDP/xZ9KVhTbdLmveDsmJujwgM1 Jk4KFj5ipf25Uvn9K6H1qH69KK3lHmRuBgFMXyrQOSPGScqPGrdFVUFR7xs3SdJBQvLh QaTA== X-Gm-Message-State: APf1xPDfJq8WlpmWKb3Ff0+nzKQigxYdQs0Kk8AI4Xr/xQjsqlPW8Yy1 pCIcR6dG98SADwueMJeRQ8S6zHsD X-Google-Smtp-Source: AH8x225M92CwNIOA2hCCvCAXzMPNTzBoxhmEeVKpdq5J4bLCwtRbbGvo6g8WHjHqI/4lpcbsxERMRQ== X-Received: by 10.176.72.197 with SMTP id y5mr2822445uac.122.1519227047619; Wed, 21 Feb 2018 07:30:47 -0800 (PST) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com. [209.85.217.179]) by smtp.gmail.com with ESMTPSA id v2sm9223641uaf.7.2018.02.21.07.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 07:30:47 -0800 (PST) Received: by mail-ua0-f179.google.com with SMTP id c20so406209uak.6; Wed, 21 Feb 2018 07:30:47 -0800 (PST) X-Received: by 10.159.62.13 with SMTP id o13mr2634222uai.83.1519227046780; Wed, 21 Feb 2018 07:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.197.146 with HTTP; Wed, 21 Feb 2018 07:30:26 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Wed, 21 Feb 2018 09:30:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Warner Losh Cc: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , "Rodney W. Grimes" , FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:37:13 -0000 On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh wrote: > > > On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote: >> >> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ram=C3=B3n Molina Menor >> wrote: >> > Le 20/02/2018 =C3=A0 22:45, Kyle Evans a =C3=A9crit : >> >> >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor >> >> >> >> wrote: >> >>> >> >>> [... snip ...] >> >>> >> >>> Moreover, the "boot [kernel]" loader command does not work: >> >>> >> >>> OK ls /boot/kernel.old/kernel >> >>> /boot/kernel.old/kernel >> >>> OK boot kernel.old >> >>> Command failed >> >>> OK boot /boot/kernel.old/kernel >> >>> Command failed >> >>> OK boot kernel >> >>> Command failed >> >>> >> >>> On the other hand, just "boot" works. >> >>> >> >> >> >> This part should work as expected as of r329674, so please give that = a >> >> shot. I'm still trying to see if I can reproduce your box drawing >> >> problem. >> >> >> >> Thanks, >> >> >> >> Kyle Evans >> >> >> > >> > Thanks Kyle. >> > >> > boot command works now. There is though a somewhat strangely formulate= d >> > messages when trying to load an non-existent kernel: >> > >> > OK boot fake >> > Failed to load kernel =E2=80=99fake=E2=80=99 >> > Failed to load any kernel >> > can=E2=80=99t load =E2=80=99kernel=E2=80=99 >> > >> > The two last lines are odd: Did the loader try to load a fallback kern= el >> > and >> > failed? That would explain the =E2=80=99kernel=E2=80=99 name in quotes= , but I have such >> > a >> > kernel=E2=80=A6 Also, just nitpicking, but "can=E2=80=99t" should be c= apitalized. >> >> (CC'ing Rod, since he also commented on this) >> >> I'm only directly responsible for the first two messages. =3D) I've >> removed the second one, though, since it was a carry-over from when it >> would try to load the selected kernel and then some default kernel >> that might be in your module_path. >> >> We can look at changing "can't load 'kernel'" to capitalize and remove >> the contraction, but that's common loader stuff and should've also >> been displayed for the same Forth scenario. >> >> > Then, I have just remembered why I was seeing a higher resolution menu >> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the n= ew >> > loader is not implementing the inclusion of this file, because I can >> > change >> > the gop mode in the loader with 'gop set [0-3]'. >> > >> >> Oy. This is actually a Forth file, so we can't really maintain all of >> the functionality that would have been allowed there. Technically, >> things like this should probably either appear in your loader.conf(5) >> in the form of 'exec=3D"gop set 3"' to be applied when loader.conf(5) is >> read, or we should provide some other means of running pure loader >> command scripts at different points in the loader sequence. (CC >> Warner, because he probably has thoughts about this latter idea) > > > While loader.rc is FORTH, it's contrived FORTH designed to look like comm= and > line interaction. While some crazy people like me have actual forth in > these, most do not, really (apart from the include /boot/XXX.4th lines, t= hat > is, which could be filtered). > > We have two choices here: Try to provide some level of compatibility shim= s, > or provide a new way to say these things in Lua. > > In the original SoC code, loader.lua lived in /boot and looked to be > something that people could modify. We likely need to do something simila= r. > loader.lua right now has nothing but were in the forth world called > 'include' and then very similar commands to the forth loader.rc. Perhaps = the > right answer is to move cli_execute out of /boot/lua/loader.lua, move tha= t > file up, and add the try-include functionality to try to include a > loader.local.lua. Then we could tell people to move to the Lua syntax way= of > doing things. We'd have to hunt down all the hacks like this, but that > wouldn't be terrible. Bonus points if we could convert the common ones > either to lua code automatically, or to loader.conf variables. We have something like this that I added yesterday in r329692, but named a little bit differently ("local.lua", "local module"). Mostly added because I've been using it to locally add test menu options and writing some of the documentation for how to hook into our new lua system to do things, and it was getting tiresome having to manually revert those bits in loader.lua when I wanted to make changes to the in-tree loader.lua. We'd basically rename this to loader.local.lua to match more closely to current convention, move "cli_execute" out to either core.lua or maybe it and the boot commands are worthy of their own "cli" module, then be happy. > This specific example should have always been a loader.conf variable (and > not an exec). While the gop command is useful, the loader should have, as > part of it's forth sequence, had something that would set the GOP mode if > the uefi_gop_mode loader.conf variable was set (I get why that wasn't don= e > that way in the forth loader, insert rant of Fear of FORTH here). So we > should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few > other things that are simple settings to make it easier for users to set > this stuff up and start to move away from the FoF kludges that we've > accumulated. A new loader.conf variable would also allow coexistence of t= he > two loaders, which will be further helped with some patches I have to the > build system coming soon. Right, this seemed like something worthy of its own loader.conf(5) variable. I didn't patch that idea, though, because I didn't necessarily want to write the Forth handling of it. =3D) From owner-freebsd-current@freebsd.org Wed Feb 21 17:10:51 2018 Return-Path: Delivered-To: freebsd-current@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 D5A1EF164C2 for ; Wed, 21 Feb 2018 17:10:50 +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 64E8086F0F for ; Wed, 21 Feb 2018 17:10:50 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 240FDF164BE; Wed, 21 Feb 2018 17:10:50 +0000 (UTC) Delivered-To: current@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 F0D6FF164BB for ; Wed, 21 Feb 2018 17:10:49 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (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 8DD0786F0A; Wed, 21 Feb 2018 17:10:49 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f180.google.com with SMTP id 30so2889020iog.2; Wed, 21 Feb 2018 09:10:49 -0800 (PST) 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=DZLc7nV/kOdDdqxS/W6ph72vcvD+DEZZtiUGxRtL0rI=; b=aySkX6qoe+ArlI616kPvwFTcHO3B/G8JZw/In7BIfgOhyniKS0Mjn54nmqyTm6/BKW fTOqbN2lnTZrGXMbgUKGCjxXIr2VpRikcEYCvwjod2u0zaUJSm1MTKdc6RswXHCw8PpF eBP54mezrvlj98N1UxGmEmeuLrBQI6cfDwaCyRIKEUl7JnXNEOCRHoYacXxeIS4ftTi6 wg05D0CIU/IG+YmXj+U2XH1xfav+WhwZxkmE5wjtHf0bjoMEb5mS2E5L2MCItiNm2NYG GHHWWfH9PL4p59YMUaWje4inORgOEoaw4AqEBbLKp/2Y8sydF20VkpQHSsRgPcYBWMi5 soYw== X-Gm-Message-State: APf1xPAn+2fwaaVVKDNs1q6mRMEsRyN4D24OfSvsUgphWAjHLV7H4Hy+ pJvIy4LVMKTXBk4hsJA6BDzyoUhl X-Google-Smtp-Source: AG47ELv1VHIE9EFGwCNdkdR0HmaEXjZmJ+ue0plZF/SAbD4cWLh+XPwfKza8m+Uwy6k8HvGHOdxECA== X-Received: by 10.107.135.207 with SMTP id r76mr4999418ioi.248.1519233043014; Wed, 21 Feb 2018 09:10:43 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id z131sm24221290itb.4.2018.02.21.09.10.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 09:10:42 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id e4so2867593iob.8; Wed, 21 Feb 2018 09:10:42 -0800 (PST) X-Received: by 10.107.41.16 with SMTP id p16mr5021470iop.173.1519233042679; Wed, 21 Feb 2018 09:10:42 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Wed, 21 Feb 2018 09:10:42 -0800 (PST) In-Reply-To: References: <20180221123617.GD1212@albert.catwhisker.org> From: Conrad Meyer Date: Wed, 21 Feb 2018 09:10:42 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Kernel selection in Lua loader To: David Wolfskill Cc: current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 17:10:51 -0000 On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans wrote: > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote: >> >> ... >> kernels="kernel kernel.old kernel.save" >> >> and the Forth loader presented (precisely) those kernels as the >> available options for selecting a kernel to load and boot. >> > > Right, so, we (and by we I mean cem@) actually implemented a form of > auto-detection for kernels. Any directory in in /boot with a file > named 'kernel' inside will be automatically listed, and that > supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5). > > (*) I use "supplemented" because I changed that in r329709, just a > little bit ago, to not do the autodetection if a 'kernels' is > explicitly set in loader.conf(5) My reasoning here is that there's > probably a reason one has set it explicitly, whether it be to hide > bogus kernels or just to slim down the list of kernels they need to > cycle through. Yep. And to add a little more detail, because I like this behavior, I've convinced Kyle to add a knob to re-enable the autodetection behavior even in the presence of kernels="", by adding a kernels_autodetect="yes" knob to loader.conf (r329733). Note that any kernels in kernels="" are offered first in the list, in the same order as configured; any additional autodetected kernels follow at the end (as you observed earlier): >> with the Lua loader, I was being offered a choice among 4 kernels >> (rather than the expected 3). Cycling through them (twice; I wanted >> to be sure the behavior was reproducible), I noted that the presented >> options were: >> >> * default/kernel >> * kernel.old >> * kernel.save >> * kernel.panic >> >> (in that sequence). Best, Conrad From owner-freebsd-current@freebsd.org Wed Feb 21 18:18:32 2018 Return-Path: Delivered-To: freebsd-current@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 9078AF1BAE3 for ; Wed, 21 Feb 2018 18:18:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.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 147A069E98 for ; Wed, 21 Feb 2018 18:18:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id CD2A0F1BADF; Wed, 21 Feb 2018 18:18:31 +0000 (UTC) Delivered-To: current@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 B7086F1BADE for ; Wed, 21 Feb 2018 18:18:31 +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 1E27B69E94; Wed, 21 Feb 2018 18:18:30 +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 w1LII7Q1087167; Wed, 21 Feb 2018 10:18:07 -0800 (PST) (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 w1LII7fh087166; Wed, 21 Feb 2018 10:18:07 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> Subject: Re: Kernel selection in Lua loader In-Reply-To: To: cem@freebsd.org Date: Wed, 21 Feb 2018 10:18:07 -0800 (PST) CC: David Wolfskill , current , Warner Losh 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-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:18:32 -0000 > On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans wrote: > > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote: > >> > >> ... > >> kernels="kernel kernel.old kernel.save" > >> > >> and the Forth loader presented (precisely) those kernels as the > >> available options for selecting a kernel to load and boot. > >> > > > > Right, so, we (and by we I mean cem@) actually implemented a form of > > auto-detection for kernels. Any directory in in /boot with a file > > named 'kernel' inside will be automatically listed, and that > > supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5). > > > > (*) I use "supplemented" because I changed that in r329709, just a > > little bit ago, to not do the autodetection if a 'kernels' is > > explicitly set in loader.conf(5) My reasoning here is that there's > > probably a reason one has set it explicitly, whether it be to hide > > bogus kernels or just to slim down the list of kernels they need to > > cycle through. > > Yep. And to add a little more detail, because I like this behavior, > I've convinced Kyle to add a knob to re-enable the autodetection > behavior even in the presence of kernels="", by adding a > kernels_autodetect="yes" knob to loader.conf (r329733). Or how about parse a wildcard * in kernels= to mean do the same as kernels_autodetect=yes the should make it possible to control the order of them on the list bo doing something like kernels=/boot/kernel;/boot/kernel.old;*;/altboot/kernel;/altboot/kernel.GENERIC > Note that any kernels in kernels="" are offered first in the list, in > the same order as configured; any additional autodetected kernels > follow at the end (as you observed earlier): The mechansism now only allows autodetec at end, use of a wildcard to show when to insert autodetect allows a fairly arbitrary order. > >> with the Lua loader, I was being offered a choice among 4 kernels > >> (rather than the expected 3). Cycling through them (twice; I wanted > >> to be sure the behavior was reproducible), I noted that the presented > >> options were: > >> > >> * default/kernel > >> * kernel.old > >> * kernel.save > >> * kernel.panic > >> > >> (in that sequence). > > Best, > Conrad -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Feb 21 18:26:24 2018 Return-Path: Delivered-To: freebsd-current@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 39A20F1C668 for ; Wed, 21 Feb 2018 18:26:24 +0000 (UTC) (envelope-from byond.lenox@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 C61086A63B for ; Wed, 21 Feb 2018 18:26:23 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 87723F1C667; Wed, 21 Feb 2018 18:26:23 +0000 (UTC) Delivered-To: current@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 60266F1C666 for ; Wed, 21 Feb 2018 18:26:23 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 C1E256A63A for ; Wed, 21 Feb 2018 18:26:22 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id t204so3718157lff.9 for ; Wed, 21 Feb 2018 10:26:22 -0800 (PST) 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=dyzNrM25wFERvjnDJL/7gU01sFvEq4qXAim0oUp7C7I=; b=d84gU/atFUmUGlDgoVcLm7Muh7LfJGixOy7D3BDMai/Zwb2hpQGLQf9m//5fmQM2YJ CID5pzFned/wcgt6NdbH3vk8chIZ8sRadf2K1oWrJI9XMxxAsBxYCHronu0T5u0fjzT/ 4gf/QYzBc+HmuDXfJDu2LarvkeYQVKykhNWNznHRkZIjiiGMmsJFZBVy+Mcv5C3H5CCC FKtmawcNNJ84/+fwP7G0KUdda4GAvZ9uCHaHmSTyFxbM+syydFFAzKGi8fiongiO5MCu UlthJ6RbeYxNyygo+bVgjHI7dTS4NbWwk3qamSmdelfHmutXcq727E4qGxwWMQOT5U7D 6M1Q== X-Gm-Message-State: APf1xPBbBxg5LKFcCcoK/DZFdwhI6p8fZgdnSQx5eHx0bgrxW28esMA3 2ue0lfpWv1cIba4vhIoxjBlA7vNu X-Google-Smtp-Source: AH8x2246mI/TdubWQGOEBHVP4kfzsUItVoppvMA+f28sco17oDPl8O8NvK+kPalCJdP4LGANlwdfLA== X-Received: by 10.46.68.78 with SMTP id r75mr3000656lja.13.1519237580721; Wed, 21 Feb 2018 10:26:20 -0800 (PST) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. [209.85.215.48]) by smtp.gmail.com with ESMTPSA id 207sm2305285lfb.61.2018.02.21.10.26.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 10:26:20 -0800 (PST) Received: by mail-lf0-f48.google.com with SMTP id x196so3701145lfd.12 for ; Wed, 21 Feb 2018 10:26:19 -0800 (PST) X-Received: by 10.25.158.149 with SMTP id h143mr2163940lfe.129.1519237579433; Wed, 21 Feb 2018 10:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Wed, 21 Feb 2018 10:25:58 -0800 (PST) In-Reply-To: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Wed, 21 Feb 2018 12:25:58 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Kernel selection in Lua loader To: "Rodney W. Grimes" Cc: current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:26:24 -0000 On Wed, Feb 21, 2018 at 12:18 PM, Rodney W. Grimes wrote: >> On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans wrote: >> > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill wrote: >> >> >> >> ... >> >> kernels="kernel kernel.old kernel.save" >> >> >> >> and the Forth loader presented (precisely) those kernels as the >> >> available options for selecting a kernel to load and boot. >> >> >> > >> > Right, so, we (and by we I mean cem@) actually implemented a form of >> > auto-detection for kernels. Any directory in in /boot with a file >> > named 'kernel' inside will be automatically listed, and that >> > supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5). >> > >> > (*) I use "supplemented" because I changed that in r329709, just a >> > little bit ago, to not do the autodetection if a 'kernels' is >> > explicitly set in loader.conf(5) My reasoning here is that there's >> > probably a reason one has set it explicitly, whether it be to hide >> > bogus kernels or just to slim down the list of kernels they need to >> > cycle through. >> >> Yep. And to add a little more detail, because I like this behavior, >> I've convinced Kyle to add a knob to re-enable the autodetection >> behavior even in the presence of kernels="", by adding a >> kernels_autodetect="yes" knob to loader.conf (r329733). > > Or how about parse a wildcard * in kernels= to mean do the same as > kernels_autodetect=yes > the should make it possible to control the order of them on > the list bo doing something like > kernels=/boot/kernel;/boot/kernel.old;*;/altboot/kernel;/altboot/kernel.GENERIC > > > >> Note that any kernels in kernels="" are offered first in the list, in >> the same order as configured; any additional autodetected kernels >> follow at the end (as you observed earlier): > > The mechansism now only allows autodetec at end, use of a wildcard to > show when to insert autodetect allows a fairly arbitrary order. > I think we might have a problem right now with trying to do this while Forth is still the default; how would it interpret such an entry? I'd almost want to go a step further and say that * should indicate where we search. Right now, it's a hard-coded /boot. I'd express that in kernels as /boot/*, which tells the loader to search directories matching /boot/* for a 'kernel' file and use that. This could then be expanded to do things like /altboot/* and search /altboot for other kernels. That'd need a little more work because we don't currently search non-/boot directories[*] when we're actually trying to load kernels. [*] Unless they appear in the module_path, then we search for "$kernel" as a file. From owner-freebsd-current@freebsd.org Wed Feb 21 19:01:06 2018 Return-Path: Delivered-To: freebsd-current@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 3630FF2071A for ; Wed, 21 Feb 2018 19:01:06 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 C68A16C704 for ; Wed, 21 Feb 2018 19:01:05 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1eoZdS-00024p-4c; Wed, 21 Feb 2018 20:00:58 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "FreeBSD current" , =?utf-8?Q?Trond_Endrest=C3=B8l?= Subject: Re: pkg does not recognize correct kernel version References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> Date: Wed, 21 Feb 2018 20:01:00 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 919fae14bc17c74543a025539baad412 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:01:06 -0000 On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrest=C3=B8l = wrote: > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > >> Does this mean I always have to do a *clean* buildworld after every = >> version >> bump? This takes ages. > > Yes, I've come to the conclusion that whenever __FreeBSD_version in > sys/sys/param.h is incremented, then it's time to blow away /usr/obj, > recreate everything to ensure the correct value of osversion in the > .note.tag section of each executable, and reinstall base prior to > updating localbase. See PR 225104 for more details, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225104. > pkg: Newer FreeBSD version for package gnome-menus: - package: 1200058 - running kernel: 1200056 So it says "running kernel", but it actually checked "version of = FreeBSD_version while building /bin/sh" or something like that. This sounds over-engineered and (more important) confusing. Ronald. From owner-freebsd-current@freebsd.org Wed Feb 21 19:06:10 2018 Return-Path: Delivered-To: freebsd-current@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 83E49F20DE6 for ; Wed, 21 Feb 2018 19:06:10 +0000 (UTC) (envelope-from o.hartmann@walstatt.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 158DF6CBBE for ; Wed, 21 Feb 2018 19:06:10 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id CB767F20DE2; Wed, 21 Feb 2018 19:06:09 +0000 (UTC) Delivered-To: current@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 B8D7DF20DE1 for ; Wed, 21 Feb 2018 19:06:09 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 150A56CBBA for ; Wed, 21 Feb 2018 19:06:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.233.30]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwJRe-1ehHZX0BO2-0181NB for ; Wed, 21 Feb 2018 20:06:01 +0100 Date: Wed, 21 Feb 2018 20:05:24 +0100 From: "O. Hartmann" To: current Subject: top: sysctl(vfs.bufspace...) expected 8, got 4 Message-ID: <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/4NFnOpWu=Dp3VjOxxziblCm"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:jFCAO54zzmtD31N7auOm6hTLt0g0pD9IvC0GZS3Bv8i59fZEq31 WKmo9vcaYFXp/+KpCz0EErx/h0eKOM7hOc7eviDgxTFWaNur9+UwMN8YZisIELulerL9tMg pxDFRQdEChI7Z7ILqOLCLGORacYCAM94OOeH2Yr/xOtJj7oZ/7X2QsAT2C/NXZM+7jnxHgt 04H7zfo/zZJBBsph7ruPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ToqoGbHgLWQ=:LlwioLGHpUvg8zO/Bg/mKB Sx0H+P31u5YDwlhSJsHR10UATNnsCNziD4YMEGR7+CT5XSXpyWkmhUf3mFSZGGXV0mTDPByjc X4nd8FEaYd7yebCTGiydxB/FscyDnsxbi0Q+GIL/fqEQuukR4Udmy6RJA2IsYGe48J5ErwO0A msmNlai6gELz/lqjcl/vJIizgzMdRobczMqhLa10EIyX5W6UhIRFVKs4tLP/anr9SC1GcTuT7 Z/xkWfbeFo7hT7yfWOHTP+fIKoOlOAmVsk2UrFZJnEyuswBGdMswGcrv6J+nIoJ25WtdgF3w3 PYIIl/Yu/XgJPMdDFvBZQmVF6IKLib9Trrkb/9kOtE1PBqbtfB/HHovMnKEYKihA0MWa0hqV4 k9S1Fx+hllK5wPi21QV2lT8pzMdQO3zcWu4E0tESv81NzE609ApFtheUJ7CBgtEH1gyfBB0oj T12lN4YGB9HLd1wAxTch+yjR1uTCpp5SIWiI13DDuiksARUapwf6JKRNFPs4jY6vCZBu6b7Vn AVvgw6g4nfgzyirpQr0OuAh74D/FEcb+gbU0aKbnWAebJ/D4Gvk5E3qULoz3qbDossaicZ6em XPdaC98A9dcqB1FRKCPIHOPpcG8P0RvW+8QKC3a0f3j/0iqNN3gES6r3udm050ov8Iw/IUMhm 6cRLXspFVVNCtjjidjj8IAqqYJwkqIYfWGmSdtdPC0K3LB/PSPyySk5mYx+kkrHlEIwxWLrBM Yf3EY0DjVLNj81qr07TercuK5Jp+tglgJPMMsG5CnvqdYhJrfSSjBCOzmctFooDITotY4p90O TW8NYYiHvA9L+ktFTQNYRXY0q+W1g== X-Mailman-Approved-At: Wed, 21 Feb 2018 19:17:18 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:06:10 -0000 --Sig_/4NFnOpWu=Dp3VjOxxziblCm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 23:= 06:15 CET 2018 amd64) I'm honored by this nice bug when calling top: top: sysctl(vfs.bufspace...) expected 8, got 4 Regards, oh --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/4NFnOpWu=Dp3VjOxxziblCm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWo3DDwAKCRDS528fyFhY lMZXAgCYRq3DgmhL5MuPDSMM9MaK7DJUYG04tyUScsvEoQ6PeihWqjruaFivWT1q a8uiWPOi4QymYfJTSqnVCzw96syjAf448xfJJji4w+FiyhvIql3pxtw+I0fADPWu vc3lHMr1KqHpxr3HKdzZ0OgpseFFE3ETZrIkkyTCk6jzos5PTtAI =VE0C -----END PGP SIGNATURE----- --Sig_/4NFnOpWu=Dp3VjOxxziblCm-- From owner-freebsd-current@freebsd.org Wed Feb 21 19:43:52 2018 Return-Path: Delivered-To: freebsd-current@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 5236CF23F68 for ; Wed, 21 Feb 2018 19:43:52 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1AE86E97F for ; Wed, 21 Feb 2018 19:43:51 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1LJhfKW068319 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 21 Feb 2018 20:43:41 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1LJhfqX068316 for ; Wed, 21 Feb 2018 20:43:41 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 21 Feb 2018 20:43:41 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Re: pkg does not recognize correct kernel version In-Reply-To: Message-ID: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:43:52 -0000 On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote: > On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl > wrote: > > > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > > > > > Does this mean I always have to do a *clean* buildworld after every > > > version > > > bump? This takes ages. > > > > Yes, I've come to the conclusion that whenever __FreeBSD_version in > > sys/sys/param.h is incremented, then it's time to blow away /usr/obj, > > recreate everything to ensure the correct value of osversion in the > > .note.tag section of each executable, and reinstall base prior to > > updating localbase. See PR 225104 for more details, > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104. > > > > pkg: Newer FreeBSD version for package gnome-menus: > - package: 1200058 > - running kernel: 1200056 > > So it says "running kernel", but it actually checked "version of > FreeBSD_version while building /bin/sh" or something like that. > This sounds over-engineered and (more important) confusing. I tried the simply approach of running "make clean; make build" in /usr/src/bin/sh, hoping it would generate binaries with the correct osversion in the .note.tag section. Boy, I couldn't be more wrong. Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever osversion is increased. I'm probably missing a simpler step. -- Trond. From owner-freebsd-current@freebsd.org Wed Feb 21 19:49:40 2018 Return-Path: Delivered-To: freebsd-current@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 792D1F245C0 for ; Wed, 21 Feb 2018 19:49:40 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 BBC0F6EC72 for ; Wed, 21 Feb 2018 19:49:39 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id g72so4053697lfg.5 for ; Wed, 21 Feb 2018 11:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mBgr/pfxTHypDvj1jgA8MLbxGa5sNLWtEEJYuQszE1M=; b=r+T3GYciULouFp6Bhn/8PA5KH1Eoj9+ckMgGMOJEOK/Q4iRZZY2OKUOIvXiMxx5hXa 2kpNIVQaYtwOUlxXECDieVqJNfxht3h6V0ir55AEayGlcDN80PNA8Gon5IrDNKS1iaUX qW5JKHZcRShlFsNODLs4zq8cPYE+kkBlR2cOwRr/2ZvQspEO5fdjiMuxnY6U+DFrDKYc 1ap0hq6x/jZSKPREzmMhYwiEsVlB7O5iBKCc2KseZ5nCyYGrS3ZHEeLuG96uHQbl8kki Nq3GzZf2q8zjuFzwfIWJHQ/5/zEAByvxfXTe6xQQOev0ebMEQJ647Xn54StoQKHrHyJg FCcA== 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=mBgr/pfxTHypDvj1jgA8MLbxGa5sNLWtEEJYuQszE1M=; b=My6k47h21y1Z8qYrQoFvuiljDQBRsnHOfqm941nCf168z4HtpIpR6mMGJW3fu9Z1BB isBWI4/ItfYim+gflgAY9PxO6O8/UaRheGAnOg3onoeRP554DcwQWwaSRJRnzMjULQRq ZJGvKvBxLWetMQvfnCJKZxzxYrkUH8EjxBfTPdrG0KZr4/hzMp3ocoZYbvhJzrmI0a4f KTnMoZ3fEvYK80V5mROwW/PPlfl2ypuVD7muzuYya+d8MJe2Z1i3zJ359yyyIV+o3KnN UUx73X1PJWuDDQZLAXqnQTIL46yqJui0H/kgXv1XTNX6xRIJHwjz2pkFtIjbBnBiJUGg xVWQ== X-Gm-Message-State: APf1xPCmEFaOBuZpfZ0Al3vAtu0jsdG1ennPRtrlQo/UX/8q7WUsYQsT lUnA9+JlJ7lBvrOsuhTIKOBPeeH2d3pWYcPl1Kw= X-Google-Smtp-Source: AH8x224UrnFb4A1YfSP812X6jgMgtOoXq7aI8nF6FF97LtKTH3DWJglvEAfYYQMh/a1/NhGY6UK24xOc63gKfm3XH48= X-Received: by 10.25.34.81 with SMTP id i78mr3193474lfi.50.1519242578024; Wed, 21 Feb 2018 11:49:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.3.10 with HTTP; Wed, 21 Feb 2018 11:49:37 -0800 (PST) Received: by 10.46.3.10 with HTTP; Wed, 21 Feb 2018 11:49:37 -0800 (PST) In-Reply-To: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> From: Andreas Nilsson Date: Wed, 21 Feb 2018 20:49:37 +0100 Message-ID: Subject: Re: pkg does not recognize correct kernel version To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: Current FreeBSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:49:40 -0000 As of pkg-1.10.5 it will ask if you wish to proceed which makes this much easier to deal with. Best regards Andreas On Feb 21, 2018 20:45, "Trond Endrest=C3=B8l" < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote: > > > On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrest=C3=B8l > > wrote: > > > > > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > > > > > > > Does this mean I always have to do a *clean* buildworld after every > > > > version > > > > bump? This takes ages. > > > > > > Yes, I've come to the conclusion that whenever __FreeBSD_version in > > > sys/sys/param.h is incremented, then it's time to blow away /usr/obj, > > > recreate everything to ensure the correct value of osversion in the > > > .note.tag section of each executable, and reinstall base prior to > > > updating localbase. See PR 225104 for more details, > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225104. > > > > > > > pkg: Newer FreeBSD version for package gnome-menus: > > - package: 1200058 > > - running kernel: 1200056 > > > > So it says "running kernel", but it actually checked "version of > > FreeBSD_version while building /bin/sh" or something like that. > > This sounds over-engineered and (more important) confusing. > > I tried the simply approach of running "make clean; make build" in > /usr/src/bin/sh, hoping it would generate binaries with the correct > osversion in the .note.tag section. Boy, I couldn't be more wrong. > Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever > osversion is increased. I'm probably missing a simpler step. > > -- > Trond. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Wed Feb 21 19:54:59 2018 Return-Path: Delivered-To: freebsd-current@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 F2E8FF24E1D for ; Wed, 21 Feb 2018 19:54:58 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 6B0446F253 for ; Wed, 21 Feb 2018 19:54:57 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 70981 invoked by uid 89); 21 Feb 2018 19:54:51 -0000 Received: from unknown (HELO ?192.168.102.151?) (mg@grem.de@195.30.121.97) by mail.grem.de with ESMTPA; 21 Feb 2018 19:54:51 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: pkg does not recognize correct kernel version From: Michael Gmelin X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Wed, 21 Feb 2018 20:54:49 +0100 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <6D85D1DD-A9EB-42A0-B0AD-CDC8230B88D5@grem.de> References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> To: Andreas Nilsson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:54:59 -0000 Still breaks automation, doesn=E2=80=99t it? > On 21. Feb 2018, at 20:49, Andreas Nilsson wrote: >=20 > As of pkg-1.10.5 it will ask if you wish to proceed which makes this much > easier to deal with. >=20 > Best regards > Andreas >=20 > On Feb 21, 2018 20:45, "Trond Endrest=C3=B8l" < > Trond.Endrestol@fagskolen.gjovik.no> wrote: >=20 >>> On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote: >>>=20 >>> On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrest=C3=B8l >>> wrote: >>>=20 >>>>> On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: >>>>>=20 >>>>> Does this mean I always have to do a *clean* buildworld after every >>>>> version >>>>> bump? This takes ages. >>>>=20 >>>> Yes, I've come to the conclusion that whenever __FreeBSD_version in >>>> sys/sys/param.h is incremented, then it's time to blow away /usr/obj, >>>> recreate everything to ensure the correct value of osversion in the >>>> .note.tag section of each executable, and reinstall base prior to >>>> updating localbase. See PR 225104 for more details, >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225104. >>>>=20 >>>=20 >>> pkg: Newer FreeBSD version for package gnome-menus: >>> - package: 1200058 >>> - running kernel: 1200056 >>>=20 >>> So it says "running kernel", but it actually checked "version of >>> FreeBSD_version while building /bin/sh" or something like that. >>> This sounds over-engineered and (more important) confusing. >>=20 >> I tried the simply approach of running "make clean; make build" in >> /usr/src/bin/sh, hoping it would generate binaries with the correct >> osversion in the .note.tag section. Boy, I couldn't be more wrong. >> Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever >> osversion is increased. I'm probably missing a simpler step. >>=20 >> -- >> Trond. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >>=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= From owner-freebsd-current@freebsd.org Wed Feb 21 19:55:47 2018 Return-Path: Delivered-To: freebsd-current@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 B08A9F24EC9 for ; Wed, 21 Feb 2018 19:55:47 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25E446F2E3 for ; Wed, 21 Feb 2018 19:55:47 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1LJtdPN068417 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 21 Feb 2018 20:55:39 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1LJtdle068414 for ; Wed, 21 Feb 2018 20:55:39 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 21 Feb 2018 20:55:39 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Current FreeBSD Subject: Re: pkg does not recognize correct kernel version In-Reply-To: Message-ID: References: <80b54e13-7e6c-a52e-4d42-16903e16e67b@gwdg.de> <20180219210551.GE94212@kib.kiev.ua> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:55:47 -0000 On Wed, 21 Feb 2018 20:49+0100, Andreas Nilsson wrote: > As of pkg-1.10.5 it will ask if you wish to proceed which makes this much > easier to deal with. That's an huge improvement. sys/sys/param.h and base are in agreement on the systems I manage, so I won't see the improvement in action for some time. -- Trond. From owner-freebsd-current@freebsd.org Wed Feb 21 19:59:35 2018 Return-Path: Delivered-To: freebsd-current@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 6500CF253C5 for ; Wed, 21 Feb 2018 19:59:35 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.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 029FB6F7B0 for ; Wed, 21 Feb 2018 19:59:35 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: by mailman.ysv.freebsd.org (Postfix) id AC0C3F253BB; Wed, 21 Feb 2018 19:59:34 +0000 (UTC) Delivered-To: current@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 9978BF253BA for ; Wed, 21 Feb 2018 19:59:34 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: from smtp.kcbark.net (static-212-247-41-80.cust.tele2.se [212.247.41.80]) (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 352446F7A7 for ; Wed, 21 Feb 2018 19:59:33 +0000 (UTC) (envelope-from kalle.carlbark+freebsd@kcbark.net) Received: from [192.168.10.137] (h-136-218.A336.priv.bahnhof.se [176.10.136.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.kcbark.net (Postfix) with ESMTPSA id 65B567538A for ; Wed, 21 Feb 2018 20:59:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kcbark.net; s=mail; t=1519243172; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=PuzWZs4BDl408rD2hS7EBN1895zj2S112DsrBUryIvU=; b=q4UhnngNTJwhEnlgd505xDn2Qus7urReNwOa949R0k+1ZUstG6/FfFvDqaXXmi+vWJZJXM gkwpXTtyRenpVMAlROuQ2hOGAg4UWo1uKjtIBtBbUmdjMgMD8UEr8VaK7Q2UPdxd/35tSu NVM601nEFDlwrtPkTn+LYmvs1601SWk= From: Kalle Carlbark Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Wed, 21 Feb 2018 20:59:32 +0100 Subject: Lua loader - geli passphrase issue Message-Id: <7AC75432-7954-4D47-9EDB-7142F265C4B1@kcbark.net> To: current@freebsd.org X-Mailer: iPhone Mail (15D100) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:59:35 -0000 Hi, Geli passphrase longer than 15 characters puts you directly to the beastie b= oot menu without you hitting the enter key. GELI passphrase: 1234567890123456 Is that the correct behavior or have I missed something? Peace, //Kalle From owner-freebsd-current@freebsd.org Wed Feb 21 20:18:31 2018 Return-Path: Delivered-To: freebsd-current@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 93B45F26B36 for ; Wed, 21 Feb 2018 20:18:31 +0000 (UTC) (envelope-from byond.lenox@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 28F3F70A40 for ; Wed, 21 Feb 2018 20:18:31 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DB6C7F26B35; Wed, 21 Feb 2018 20:18:30 +0000 (UTC) Delivered-To: current@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 C8890F26B34 for ; Wed, 21 Feb 2018 20:18:30 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (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 3BAAD70A3F for ; Wed, 21 Feb 2018 20:18:29 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f43.google.com with SMTP id o145so950988lff.0 for ; Wed, 21 Feb 2018 12:18:29 -0800 (PST) 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=6CBUL0QSwHCQjRi4VeQJUfYLtLbUAJF0j8EoYHKrXCA=; b=i0DIw7IHaDjbzBm6lKbw6pynZZrfaoGddZjn9KM6p40oXiCTO3xuny5d4QeNP6ubNZ JQY/hHwYMx02UFBRtDdk+HSrb4p6BGewhkSOic4D1C0i5lfGYogXxpfVt5S6kAxoQ5fd RaR34+CzN2PeIA7EvdqIqfQBiPM6dbRtW658l1Ooe3+Cvwlb4hPCbc254aCYZJ5gXQYa MQ5LCy/r+lYqEgp7SCNbU9DqN9ZDK1jNcfdx9Io82vPucPSbCeKO8emu0YY3e00u1qgr WJu9zSNkXntXICZWx61bF5FuThyjoiSJluz6vrPqrOhum/nMRs6cZ1GSNixx6jRrDeSl gbhw== X-Gm-Message-State: APf1xPBj8K018P0gTxoEf/fdv4UKZ1p8ioPFigGHGsbuO7vq/6cRA+HP wQHSQiD2m2VLuY4ouWpOCnWufk41 X-Google-Smtp-Source: AH8x226hZr72Yr9P8hKpMTzfPye/4IrCzSCe4OsTPjppjBPHo3pPkoAosgNbPKFQ48NTEXZVkqcamg== X-Received: by 10.46.1.149 with SMTP id f21mr3103736lji.56.1519244308093; Wed, 21 Feb 2018 12:18:28 -0800 (PST) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com. [209.85.215.41]) by smtp.gmail.com with ESMTPSA id p16sm3615595lje.12.2018.02.21.12.18.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 12:18:27 -0800 (PST) Received: by mail-lf0-f41.google.com with SMTP id v9so4157404lfa.11 for ; Wed, 21 Feb 2018 12:18:27 -0800 (PST) X-Received: by 10.25.154.205 with SMTP id c196mr3263561lfe.52.1519244307558; Wed, 21 Feb 2018 12:18:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.106.8 with HTTP; Wed, 21 Feb 2018 12:18:06 -0800 (PST) In-Reply-To: <7AC75432-7954-4D47-9EDB-7142F265C4B1@kcbark.net> References: <7AC75432-7954-4D47-9EDB-7142F265C4B1@kcbark.net> From: Kyle Evans Date: Wed, 21 Feb 2018 14:18:06 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Lua loader - geli passphrase issue To: Kalle Carlbark Cc: current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 20:18:31 -0000 On Wed, Feb 21, 2018 at 1:59 PM, Kalle Carlbark wrote: > Hi, > > Geli passphrase longer than 15 characters puts you directly to the beastie boot menu without you hitting the enter key. > > GELI passphrase: 1234567890123456 > > Is that the correct behavior or have I missed something? > You have missed how silly this behavior was. =) Fixed in r329748, sorry about that! Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Wed Feb 21 23:15:50 2018 Return-Path: Delivered-To: freebsd-current@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 53A88F09EEC for ; Wed, 21 Feb 2018 23:15:50 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id EA4227852D; Wed, 21 Feb 2018 23:15:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-107-107-61-1.mycingular.net [107.107.61.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B55062B68; Wed, 21 Feb 2018 23:15:48 +0000 (UTC) Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Tommi Pernila Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> From: Eric McCorkle Message-ID: <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> Date: Wed, 21 Feb 2018 18:15:47 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 23:15:50 -0000 The GELI work could be merged at this point, though it won't be usable without an additional patch to enable loader-only operation. The patches are currently up for review: This is the order in which they'd need to be merged: https://reviews.freebsd.org/D12732 This one changes the efipart device. Toomas Soome identified some problems, which I have addressed. He has not re-reviewed it, however. https://reviews.freebsd.org/D12692 This adds some crypto code needed for GELI. It simply adds new code, and doesn't conflict with anything. https://reviews.freebsd.org/D12698 This adds the EFI KMS interface code, and has the EFI loader pass keys into the keybuf interface. I can't post the main GELI driver until those get merged, as it depends on them. It can be found on the geli branch on my github freebsd repository, however. Additionally, you need this patch, which allows loader.efi to function when installed directly to the ESP: https://reviews.freebsd.org/D13497 On 02/20/2018 22:56, Tommi Pernila wrote: > Hi Eric, > > could you provide a brief update how the work is going? > > > Br, > > Tommi > > > On Nov 16, 2017 04:29, "Eric McCorkle" > wrote: > > Right, so basically, the remaining GELI patches are against loader, and > most of them can go in independently of the work on removing boot1. > There's a unanimous consensus on getting rid of boot1 which includes its > original author, so that's going to happen. > > > For GELI, we have the following (not necessarily in order): > > a) Adding the KMS interfaces, pseudo-device, and kernel keybuf > interactions > b) Modifications to the efipart driver > c) boot crypto > d) GELI partition types (not strictly necessary) > > Then there's the GELI driver itself.  (a) and (c) are good to land, (b) > needs some more work after Toomas Soome pointed out a legitimate > problem, and (d) actually needs a good bit more code (but again, it's > more cosmetic).  Additionally, the GELI driver will need further mods to > efipart to be written (nothing too big).  But we could go ahead with (a) > and (c), as they've already been proven to work. > > I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with > the 7th RISC-V workshop at the end of the month. > > Once this stuff is all in, loader should handle any GELI volumes it > finds, and it should Just Work once boot1 is gone. > > From owner-freebsd-current@freebsd.org Thu Feb 22 00:03:24 2018 Return-Path: Delivered-To: freebsd-current@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 DD737F0E8AF for ; Thu, 22 Feb 2018 00:03:23 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 500D47A75D; Thu, 22 Feb 2018 00:03:23 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-107-107-61-1.mycingular.net [107.107.61.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id C11952B75; Thu, 22 Feb 2018 00:03:16 +0000 (UTC) Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? From: Eric McCorkle To: Tommi Pernila Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> Message-ID: Date: Wed, 21 Feb 2018 19:03:15 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 00:03:24 -0000 FYI, I just IFC'ed everything, and the current patches are still fine. Also, the full GELI + standalone loader has been deployed on one of my laptops for some time now. On 02/21/2018 18:15, Eric McCorkle wrote: > The GELI work could be merged at this point, though it won't be usable > without an additional patch to enable loader-only operation. The > patches are currently up for review: > > This is the order in which they'd need to be merged: > > > https://reviews.freebsd.org/D12732 > > This one changes the efipart device. Toomas Soome identified some > problems, which I have addressed. He has not re-reviewed it, however. > > > https://reviews.freebsd.org/D12692 > > This adds some crypto code needed for GELI. It simply adds new code, > and doesn't conflict with anything. > > > https://reviews.freebsd.org/D12698 > > This adds the EFI KMS interface code, and has the EFI loader pass keys > into the keybuf interface. > > > I can't post the main GELI driver until those get merged, as it depends > on them. It can be found on the geli branch on my github freebsd > repository, however. > > > Additionally, you need this patch, which allows loader.efi to function > when installed directly to the ESP: > > https://reviews.freebsd.org/D13497 > > On 02/20/2018 22:56, Tommi Pernila wrote: >> Hi Eric, >> >> could you provide a brief update how the work is going? >> >> >> Br, >> >> Tommi >> >> >> On Nov 16, 2017 04:29, "Eric McCorkle" > > wrote: >> >> Right, so basically, the remaining GELI patches are against loader, and >> most of them can go in independently of the work on removing boot1. >> There's a unanimous consensus on getting rid of boot1 which includes its >> original author, so that's going to happen. >> >> >> For GELI, we have the following (not necessarily in order): >> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf >> interactions >> b) Modifications to the efipart driver >> c) boot crypto >> d) GELI partition types (not strictly necessary) >> >> Then there's the GELI driver itself.  (a) and (c) are good to land, (b) >> needs some more work after Toomas Soome pointed out a legitimate >> problem, and (d) actually needs a good bit more code (but again, it's >> more cosmetic).  Additionally, the GELI driver will need further mods to >> efipart to be written (nothing too big).  But we could go ahead with (a) >> and (c), as they've already been proven to work. >> >> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with >> the 7th RISC-V workshop at the end of the month. >> >> Once this stuff is all in, loader should handle any GELI volumes it >> finds, and it should Just Work once boot1 is gone. >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Feb 22 02:52:17 2018 Return-Path: Delivered-To: freebsd-current@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 D5C40F1DD33 for ; Thu, 22 Feb 2018 02:52:17 +0000 (UTC) (envelope-from lebarondemerde@privacychain.ch) Received: from forward100j.mail.yandex.net (forward100j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::100]) (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 5550A84179 for ; Thu, 22 Feb 2018 02:52:16 +0000 (UTC) (envelope-from lebarondemerde@privacychain.ch) Received: from mxback5j.mail.yandex.net (mxback5j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10e]) by forward100j.mail.yandex.net (Yandex) with ESMTP id 157915D836FB for ; Thu, 22 Feb 2018 05:52:11 +0300 (MSK) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:7]) by mxback5j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 3xyjCrBFaU-qBTSiGpU; Thu, 22 Feb 2018 05:52:11 +0300 Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Yo9SmSToLQ-q23WDNxi; Thu, 22 Feb 2018 05:52:02 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Date: Wed, 21 Feb 2018 23:51:58 -0300 From: Le Baron =?utf-8?B?ZOKAmU1lcmRl?= To: freebsd-current@freebsd.org Subject: P2P core/daemon in Base? Message-ID: <20180222025158.dqookgcvscyihyeb@privacychain.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: NeoMutt/20171215 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 02:52:18 -0000 Dear Fellows, Nothing new and probably will not be implemented, specially by me who can't write code, but I am sharing this idea anyway. The point would be to have a P2P core/daemon in Base with some API to be used by clients, including pkg, freebsd-update, and portsnap becoming P2P based/capable, and would also allowing any user that desire to become a FreeBSD mirror[1]. What would reduce the load on the FreeBSD infrastructure. Other than those, idealistic, that built-in P2P core to be also capable of handling "modern" needs, like a net/syncthing equivalent client, and the usual torrent clients (CLI, GTK, Qt etc.). Some time ago, while digging in the Syncthing resources I found some people willing to use that to keep files synced between thousands of servers, and so I imagine this kind of feature would (very?) be appealing at enterprise level. This piece of software could of course be integrated with IPFW, Capsicum or wherever be necessary, possible or desired. 1 - The FreeBSD mirror capability would be a separated feature allowing for those who desire to partially mirror the FreeBSD packages, etc. For instance in a way that user to mirror from just the latest packages to everything. -- Best Regards. LBdM. From owner-freebsd-current@freebsd.org Thu Feb 22 06:18:45 2018 Return-Path: Delivered-To: freebsd-current@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 0605DF061ED for ; Thu, 22 Feb 2018 06:18:45 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) (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 800A36EACC; Thu, 22 Feb 2018 06:18:44 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: by mail-qt0-f177.google.com with SMTP id c19so5044612qtm.7; Wed, 21 Feb 2018 22:18:44 -0800 (PST) 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=2GK3sqi4DajJglAPwj8DGxb16guKB/KTSfOtza+GQSs=; b=dp3/B6bDrlAmyVXIbH4yv4PuHeZOeUckCG2DFtd7MuWGprX/ZrySNJvy4r7uDsY2rj 2V295vZr4VIJXxYHHZYZcuwLVVyCQ0v1mJtADgUdF+Ei+4MQBUQHT7wiGifNZo/54w/u 9kfUftvd9lnGiz4GsFiyxddPBfS5SX3wmaF1AaN0YZGfuN8w9iEyOFGEYsOD7A+QTShV IwAuKG2n9eYBgztAP8Z9+ph0ZyIV2kq38KaDKrdHcVTDt3o0oJWq+uXjY4iyHRXlv2Ch 0jXv0vhrfDZ6I5klIn+VXQuA9d4dq7rP87g0kQOKtuboMquKsArdM/33nqCMByKvvAk7 JJRw== X-Gm-Message-State: APf1xPA/Iq75/kB+eAJDzFpPo6aaMTPQn149ZPj3fL+cN5vcJu2+EQOe em3KYGNJe8a4XbHj4iywjdbkfq58fwdC7TNBBSY= X-Google-Smtp-Source: AH8x2255XO3fvjPBJgBGr885X56wcQZQ37+D5XeSAlbdDMrzahK1RzgQ1MmrTZi0TjoWP8HBqJ7JJeF+C8iNWaxwTlo= X-Received: by 10.237.62.26 with SMTP id l26mr9080264qtf.143.1519280317615; Wed, 21 Feb 2018 22:18:37 -0800 (PST) MIME-Version: 1.0 References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> In-Reply-To: From: Tommi Pernila Date: Thu, 22 Feb 2018 06:18:26 +0000 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 06:18:45 -0000 Awesome, thanks for the update and the work that you have done! Now we just need some more reviewers eyes on the code :) Br, Tommi On Thu, 22 Feb 2018 at 2.03, Eric McCorkle wrote: > FYI, I just IFC'ed everything, and the current patches are still fine. > > Also, the full GELI + standalone loader has been deployed on one of my > laptops for some time now. > > On 02/21/2018 18:15, Eric McCorkle wrote: > > The GELI work could be merged at this point, though it won't be usable > > without an additional patch to enable loader-only operation. The > > patches are currently up for review: > > > > This is the order in which they'd need to be merged: > > > > > > https://reviews.freebsd.org/D12732 > > > > This one changes the efipart device. Toomas Soome identified some > > problems, which I have addressed. He has not re-reviewed it, however. > > > > > > https://reviews.freebsd.org/D12692 > > > > This adds some crypto code needed for GELI. It simply adds new code, > > and doesn't conflict with anything. > > > > > > https://reviews.freebsd.org/D12698 > > > > This adds the EFI KMS interface code, and has the EFI loader pass keys > > into the keybuf interface. > > > > > > I can't post the main GELI driver until those get merged, as it depends > > on them. It can be found on the geli branch on my github freebsd > > repository, however. > > > > > > Additionally, you need this patch, which allows loader.efi to function > > when installed directly to the ESP: > > > > https://reviews.freebsd.org/D13497 > > > > On 02/20/2018 22:56, Tommi Pernila wrote: > >> Hi Eric, > >> > >> could you provide a brief update how the work is going? > >> > >> > >> Br, > >> > >> Tommi > >> > >> > >> On Nov 16, 2017 04:29, "Eric McCorkle" >> > wrote: > >> > >> Right, so basically, the remaining GELI patches are against loader, > and > >> most of them can go in independently of the work on removing boot1. > >> There's a unanimous consensus on getting rid of boot1 which > includes its > >> original author, so that's going to happen. > >> > >> > >> For GELI, we have the following (not necessarily in order): > >> > >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf > >> interactions > >> b) Modifications to the efipart driver > >> c) boot crypto > >> d) GELI partition types (not strictly necessary) > >> > >> Then there's the GELI driver itself. (a) and (c) are good to land, > (b) > >> needs some more work after Toomas Soome pointed out a legitimate > >> problem, and (d) actually needs a good bit more code (but again, > it's > >> more cosmetic). Additionally, the GELI driver will need further > mods to > >> efipart to be written (nothing too big). But we could go ahead > with (a) > >> and (c), as they've already been proven to work. > >> > >> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied > with > >> the 7th RISC-V workshop at the end of the month. > >> > >> Once this stuff is all in, loader should handle any GELI volumes it > >> finds, and it should Just Work once boot1 is gone. > >> > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@freebsd.org Thu Feb 22 07:37:38 2018 Return-Path: Delivered-To: freebsd-current@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 0AFCEF0DB56 for ; Thu, 22 Feb 2018 07:37:38 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 721E67281F; Thu, 22 Feb 2018 07:37:36 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MdKDb-1f614i2L8F-00IS7p; Thu, 22 Feb 2018 08:37:15 +0100 Date: Thu, 22 Feb 2018 08:37:07 +0100 From: "O. Hartmann" To: Gary Jennejohn Cc: "Chris H" , "FreeBSD Current" , Warner Losh , Ed Maste , Michael Tuexen , Mark Johnston Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Message-ID: <20180222083707.73ae3036@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180220123953.5e987691@ernst.home> References: <20180220123953.5e987691@ernst.home> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mBhoc3LXizpjMdyPgwwIo79PCO47vV2eZG5DJhx1eQEgRJb+WAa YdBNpZg7CTbnBrHj46kuRTQmVqzjdpAK+U5BU7bFHM8U8uB7z2SVmvTFPVrWb/sNfOzbAzV k6e9lsFroi58n6KyR4Q+WrqfcoHcqaG0qdNGQ25naOuS3112QonADoMAD6RJRr9jJrUT3Pw zIjY2jaXtxLnJiEyVmgpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xjO9ULfIYqY=:pvamZBuK/nBCxPbVvMd9PO BDwPbVOcRwwZ7ergKabOgkTVpPtN81dqp1UpjgUxK/jflSu9POML+QKD1hpqFB6EubG/e65fB Cy0hUlugVmfN57P9HW7zDbWycsaK0Ez42tIzyswD4pQg5HzVttGnG07sGiTZaZsIqQiZJWCZ+ jNdNWqXVGfhOz1JOLPQ7eZ11uWDJgeAp7P57vZUcta3lZMAo9XEZJtMWfjTMDY6Xin0MML99v GtggKQhOIMycEbh195Wpq+xDl0OTQIkH5+E+nlTXf+M2X3xtuF29OSo1FPnKlr95eL9pkGUnT 063p8QtGl9EAHr9rGBNHp+8L4udViyER8Gr3fyP9Ke2y7oXX8KQYF8aZsQIPJonLR6IiC0Wf2 rRMCIm8vJ/1ux+yyCN4zir/qpirMadUFc3diSXCERADp3bCRPanzzozGEMsnOiVrZBB/a26hm uQez3A3asosI4bjUUDLjXBoP4BQPBzs0GKOsqLWmdAw7HYToeuHRWvFKCpV0RBKKq5WiTryqw +BhBdbJjso7NnoEE9vpfrz9kCr7/Rl1KcHrHx8KzTO1+4jZPX0KO5JuLERvquSJh09hjYKFxs GozQivclEINBt5/vcXE4GTCRlvIMUaJj+BN9Fz9z78EIA+TprAT5i0fy99Q2LqfMltW1Dxc+3 xUTv0WsFy8IO4kLBICiSMzBzuWv+aBrz66D7AXgswX3wd+1INP4U8bikRnw5QlHawtIv11cj/ +DfvitukD9q0tSqFDtPYS6tc9dlQ4C+PsdyqSEA1FGp40T2YeGfP2pPjmiWIoJB1phODXXv/o 4ZqKYOpo/dW4wXJkxDDaFWnbGaFBxHh7MButDU2GfaV4hzplCo= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 07:37:38 -0000 On Tue, 20 Feb 2018 12:39:53 +0100 Gary Jennejohn wrote: > On Mon, 19 Feb 2018 14:18:15 -0800 > "Chris H" wrote: > > > I'm seeing a number of messages like the following: > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > > > and was wondering if it's anything to be concerned with, or whether > > fsck(8) is fixing them. > > This began to happen when the power went out on a new install: > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST > > 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > > which hadn't yet been hooked up to the UPS. > > I performed an fsck in single user mode upon power-up. Which ended with the > > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL. > > I answered Y. > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: > > newfs -U -j > > > > Thank you for all your time, and consideration. > > > > fsck fixes these errors only when the user does NOT use the journal. > You should re-do the fsck. > When first these mysterious errors occured on several boxes running CURRENT, that was in December 2017 if I'm right, I also whitnessed mysterious and frequent crashes on several SSD driven machines, where this error described above occured. While the error vanished somehow in the meanwhile while CURRENT proceeds, the crashes continued - on two boxes, I dumped restore the OS on the system's SSD by reformatting the SSD from sratch (UFS2, soft update+ journaling). On those boxes the mysterious crashes vanished since then! On box left so far, my workstation. And this box continous to crash now and started crashing today again while compiling world/kernel. The fun-part is: even after a clean shutdown, where I can not detect any filesystem inconsistencies and rebooting and, again: no reported inconsistencies on the console/messages/logs, the box crashes spontanously. Now (today) I could trigger the reboot by starting "make -j4 buildworld buildkernel" and after showing the initial compiler statements/build framework statements, the box went to Nirwana. A well known phenomenon right now. I checked now the consistency of the filesystem, here is the result of the /usr/obj tree, which is a dedicated GPT partition (label: /dev/gpt/usr.obj): [...] root@box1:~ # fsck -fy /dev/gpt/usr.obj ** /dev/gpt/usr.obj ** Last Mounted on /usr/obj ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames UNALLOCATED I=515 OWNER=root MODE=0 SIZE=0 MTIME=Feb 22 07:25 2018 NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes DIRECTORY CORRUPTED I=169691 OWNER=root MODE=40775 SIZE=1536 MTIME=Feb 22 05:16 2018 DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd UNEXPECTED SOFT UPDATE INCONSISTENCY SALVAGE? yes ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4% fragmentation) ***** FILE SYSTEM MARKED DIRTY ***** ***** FILE SYSTEM WAS MODIFIED ***** ***** PLEASE RERUN FSCK ***** [...] When doing a installworld, I pre-emptively perform in single user mode before mounting the partitions a "fsck -yf" two times. In most cases, the filesystem are reported clean, but sometimes especially those under high I/O (/usr/src and mostly /usr/obj on this build machine) there are reports of corruption. As I reported, the very same behaviour occured on three boxes simultanously and I got rid of it by completely reformatting the SSDs (never had issues so far with HDD based boxes!). I hope I can refurbish this weekend the remaining box and I could report, if desired, whether this box returns to a healthy state as the others or if my observation was a simple coincidence of issues ... Thanks for the patience, Oliver From owner-freebsd-current@freebsd.org Thu Feb 22 08:26:23 2018 Return-Path: Delivered-To: freebsd-current@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 9F4E3F12E97 for ; Thu, 22 Feb 2018 08:26:23 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 1D6E375123; Thu, 22 Feb 2018 08:26:23 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id m207so1549208wma.2; Thu, 22 Feb 2018 00:26:23 -0800 (PST) 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=CvZYg5uwbcWi/Hs4Z9Fdyj/05MMadhHCodFtcfVN1go=; b=rGpU2yKI5BXzu0UiwsODN42bIKpyOZWRtpoGYkYXA+7LRfb4vVPGaVK210eVAwETx3 3GFmig9SlupNzX3zku5Yd3es0rrWUx+1H3KO3kSHrwLsyTnRR91AQENu0NBBSagBJuR8 MG9ekjvW8nPE3ERr987K5ZGDmpkJXBJoy5sfXOerCxMKMGp29veWmeL/9ehBIc5I3zLr DpM9eaN0LupBMsn+irerb8kI2gxahoZU6pe3WuR4vz8l12IuswOYBfbRijewLxa61prU 561LDc6nRtx9KPwMukiuWpSMZJzRwgNhVb/pNFGrjLEQ9h1PeMc/Mxpa8LjHkTM3LfDc OqwA== 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=CvZYg5uwbcWi/Hs4Z9Fdyj/05MMadhHCodFtcfVN1go=; b=SsKZWB7VnwfBRBr8SNISEq/PuzPd35LI8VfwwdhCGGpcxcejDUPTHyYsUp9okZ458U 7Cf7GoJFf53asslq68nfcK/deBb26Y6+QdE45FPGaf26Bjlso/D2p4xZA4g9d75ZHuw0 uFO+q85BB2XV8vxCY2ax8l4Mxd27lsPlsOSQSYNmomdsS84e7NR4Wuli/CePxlBqPhCW eBfy3Giblr+9ktduaKrVNXl8IJgi6bD7gRMpQECCfDs1mDI0IHfRXAEJ2Fzm9MOa/EZD 1aAraW3OUV/7lRFFRvlFgcbRNGlTE+8R6IyFXhCoBwnl2vTKd8+oze846dSDpLJO69nS 0mjw== X-Gm-Message-State: APf1xPB7PbOidg8f/rAnmPyrxddCqv9js6/Ci08zHzG31AjFUyKxD0h9 BQ71dHGOCnXe+UswlAUR5BGdNCYy X-Google-Smtp-Source: AH8x226Qs2cBVnSXcJWv6eB61pj6/5JkIjgWDRFruirawv8m29y8SPK0f9txiCswWnRpzTmmTF+mXA== X-Received: by 10.28.216.82 with SMTP id p79mr2636669wmg.8.1519287982068; Thu, 22 Feb 2018 00:26:22 -0800 (PST) Received: from ernst.home (p5B02324A.dip0.t-ipconnect.de. [91.2.50.74]) by smtp.gmail.com with ESMTPSA id t141sm41258633wmd.34.2018.02.22.00.26.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Feb 2018 00:26:21 -0800 (PST) Date: Thu, 22 Feb 2018 09:26:20 +0100 From: Gary Jennejohn To: "O. Hartmann" Cc: "Chris H" , "FreeBSD Current" , Warner Losh , Ed Maste , Michael Tuexen , Mark Johnston Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Message-ID: <20180222092620.7c327329@ernst.home> In-Reply-To: <20180222083707.73ae3036@freyja.zeit4.iv.bundesimmobilien.de> References: <20180220123953.5e987691@ernst.home> <20180222083707.73ae3036@freyja.zeit4.iv.bundesimmobilien.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 08:26:23 -0000 On Thu, 22 Feb 2018 08:37:07 +0100 "O. Hartmann" wrote: > On Tue, 20 Feb 2018 12:39:53 +0100 > Gary Jennejohn wrote: > > > On Mon, 19 Feb 2018 14:18:15 -0800 > > "Chris H" wrote: > > > > > I'm seeing a number of messages like the following: > > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > > > > > and was wondering if it's anything to be concerned with, or whether > > > fsck(8) is fixing them. > > > This began to happen when the power went out on a new install: > > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST > > > 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > > > which hadn't yet been hooked up to the UPS. > > > I performed an fsck in single user mode upon power-up. Which ended with the > > > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL. > > > I answered Y. > > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: > > > newfs -U -j > > > > > > Thank you for all your time, and consideration. > > > > > > > fsck fixes these errors only when the user does NOT use the journal. > > You should re-do the fsck. > > > > When first these mysterious errors occured on several boxes running CURRENT, > that was in December 2017 if I'm right, I also whitnessed mysterious and > frequent crashes on several SSD driven machines, where this error described > above occured. > > While the error vanished somehow in the meanwhile while CURRENT proceeds, the > crashes continued - on two boxes, I dumped restore the OS on the system's SSD > by reformatting the SSD from sratch (UFS2, soft update+ journaling). On those > boxes the mysterious crashes vanished since then! > > On box left so far, my workstation. And this box continous to crash now and > started crashing today again while compiling world/kernel. > > The fun-part is: even after a clean shutdown, where I can not detect any > filesystem inconsistencies and rebooting and, again: no reported > inconsistencies on the console/messages/logs, the box crashes spontanously. Now > (today) I could trigger the reboot by starting "make -j4 buildworld > buildkernel" and after showing the initial compiler statements/build framework > statements, the box went to Nirwana. A well known phenomenon right now. > > I checked now the consistency of the filesystem, here is the result of > the /usr/obj tree, which is a dedicated GPT partition > (label: /dev/gpt/usr.obj): > > > [...] > root@box1:~ # fsck -fy /dev/gpt/usr.obj > ** /dev/gpt/usr.obj > ** Last Mounted on /usr/obj > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > UNALLOCATED I=515 OWNER=root MODE=0 > SIZE=0 MTIME=Feb 22 07:25 2018 > NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > REMOVE? yes > > DIRECTORY CORRUPTED I=169691 OWNER=root MODE=40775 > SIZE=1536 MTIME=Feb 22 05:16 2018 > DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > SALVAGE? yes > > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > > SUMMARY INFORMATION BAD > SALVAGE? yes > > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > > 126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4% > fragmentation) > > ***** FILE SYSTEM MARKED DIRTY ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > ***** PLEASE RERUN FSCK ***** > > [...] > > When doing a installworld, I pre-emptively perform in single user mode before > mounting the partitions a "fsck -yf" two times. In most cases, the filesystem > are reported clean, but sometimes especially those under high I/O (/usr/src and > mostly /usr/obj on this build machine) there are reports of corruption. > > As I reported, the very same behaviour occured on three boxes simultanously and > I got rid of it by completely reformatting the SSDs (never had issues so far > with HDD based boxes!). > > I hope I can refurbish this weekend the remaining box and I could report, if > desired, whether this box returns to a healthy state as the others or if my > observation was a simple coincidence of issues ... > > Thanks for the patience, > I also see such problems only with SSDs. Probably because the SSDs are buffering writes internally which never make it into the flash chips, although the SSDs report that the writes were completed. HDDs apparently don't do that, or have a smaller cache. I then also run fsck in single-user mode, but I explicitly do NOT use the journal, i.e., I do NOT run fsck -y. But I guess that using fsck -fy is equivalent to not using the journal. In my case the SSDs are error free after doing the fsck without using the jounal until the next crash happens. My box with a Ryzen 5 1600 tends to hang for no apparent reason, so I see these errors fairly frequently because I have to reset the box :( -- Gary Jennejohn From owner-freebsd-current@freebsd.org Thu Feb 22 09:48:20 2018 Return-Path: Delivered-To: freebsd-current@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 EFB18F19E38 for ; Thu, 22 Feb 2018 09:48:19 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) Received: from sonic308-45.consmr.mail.ir2.yahoo.com (sonic308-45.consmr.mail.ir2.yahoo.com [77.238.178.181]) (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 7615B782DC for ; Thu, 22 Feb 2018 09:48:19 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) X-YMail-OSG: .66UUyEVM1nZ7iGjHVR_r9G78V6.1RGIpk1BDcetNj8CZ6m2r_dfS_rDhY4BgWK g9hFi3L1rlsA4wn1pw_2reFEg9hLS4PR5ca8RcDapBiBinTXATPmAD0mvsfJFS57iZCbgCH6SUPF piOcFxxW5r6RuJESQlsGcyklfaLiqk4GGvvncC2LMP.pk_2GbuIQQDFXZWgWdpQhKWtVXRpNB4ap LOy05JbaF4XvQp8acwk9iAK9fV4WXkZRX8DFx6VfqI5MDocA_EEdE2CdLGJObb0rV5P7llxY6MaO 3YwiRy0f8L6eXsVgd9XDrYNT5_qfgNidOj5N_uDQvPoaye1n35D2J72zR5Opg_wLJ3pNYfkyBeFn y7.P8VL16nIyGye7uadbfN0MY54P0wHXqUyGwB9_JUojHjotUe_QU_xyT9TK.hKrQwkeyPI1Zvk7 pMzUkzCJ04IO.POEQpiy3NFpcKNwqzEU53OrdS9GSQDpleU884ZWlACDPcYM1Fwye.K76oPVV9cV RXk27JzY8bKm8UsPZYRnHs1pLAm91G_P63zmdswsZcMCVFTirFgb0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Thu, 22 Feb 2018 09:48:12 +0000 Received: from smtp164.mail.ir2.yahoo.com (EHLO [0.0.0.0]) ([46.228.39.127]) by smtp411.mail.ir2.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 59e6c8fd7411a235c302346633fcd0c4 for ; Thu, 22 Feb 2018 09:44:11 +0000 (UTC) To: freebsd-current From: Per Gunnarsson Subject: Revision: 329797 kernel build problem Message-ID: <15ec4507-1beb-46db-7cf3-8f179e9baad0@yahoo.com> Date: Thu, 22 Feb 2018 10:43:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 09:48:20 -0000 When trying to build the kernel, I get: --- all_subdir_linux --- /usr/src/sys/amd64/linux32/linux32_dummy.c:1:5: error: unknown type name 'sys' --- linux_fork.o --- ctfconvert -L VERSION -g linux_fork.o --- nsprepkg.o --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing?? -g -nostdinc?? -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h?? -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD?? -MF.depend.nsprepkg.o -MTnsprepkg.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float?? -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member?? -mno-aes -mno-avx?? -std=iso9899:1999 -Werror?? /usr/src/sys/contrib/dev/acpica/components/namespace/nsprepkg.c --- modules-all --- --- linux32_dummy.o --- ?????? sys/sys/sysent.2 ?????? ^ /usr/src/sys/amd64/linux32/linux32_dummy.c:1:8: error: expected identifier or '(' ?????? sys/sys/sysent.2 ???????????? ^ --- all_subdir_linux64 --- --- assym.s --- sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s --- all_subdir_libalias --- --- alias_smedia.o --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin?? -O2 -pipe?? -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc???? -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC???? -MD?? -MF.depend.alias_smedia.o -MTalias_smedia.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float?? -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member?? -mno-aes -mno-avx?? -std=iso9899:1999 -c /usr/src/sys/netinet/libalias/alias_smedia.c -o alias_smedia.o --- all_subdir_linux64 --- --- linux_genassym.o --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC -MD -MF.depend.linux_genassym.o -MTlinux_genassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 /usr/src/sys/amd64/linux/linux_genassym.c --- all_subdir_linux --- 2 errors generated. --- all_subdir_linux64 --- --- linux_fork.o --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin?? -O2 -pipe?? -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc???? -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC???? -MD?? -MF.depend.linux_fork.o -MTlinux_fork.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float?? -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member?? -mno-aes -mno-avx?? -std=iso9899:1999 -c /usr/src/sys/compat/linux/linux_fork.c -o linux_fork.o --- all_subdir_linux --- *** [linux32_dummy.o] Error code 1 Regards, Per Gunnarsson From owner-freebsd-current@freebsd.org Thu Feb 22 10:57:53 2018 Return-Path: Delivered-To: freebsd-current@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 ECBCBF21A77 for ; Thu, 22 Feb 2018 10:57:52 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 976C37B261 for ; Thu, 22 Feb 2018 10:57:52 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 93644213D0 for ; Thu, 22 Feb 2018 05:57:46 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Thu, 22 Feb 2018 05:57:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=xIFeUkGIsInpwDnicA6NQnKNLYZ5w8lAaySv2e3ExzI=; b=c8aexNwA A9TxA5iZAkekaU7WMohWgQ2LV6iR6K3sJr2j+BNzisYSwrCPskPwtt5mImTdqvz6 yvVChO7yxghdZ8ULNOlD4BacZZSFwjxH8tKWx+WkJLdq9uaH+CaEduwnkCLunI78 bOHitTg+gadew9mxfUuAF4PWfRijt2/DYEuCv5csX6CVi04sYl3q+jtgCmzvHSIM S9GkWBfl5EPVjI6AGg8FA2VM8uaaNKPL7eWLByazF0uvWX2lTR8p4rXN6iEJdpf6 opQe0zon/5GwDdVG5YX5K9i9hF8juFPLnxnbhEVxl5l7i93xKdnmtzcwLJHvIdvE X4k5LLki7UU80g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xIFeUkGIsInpwDnicA6NQnKNLYZ5w 8lAaySv2e3ExzI=; b=MY53Lo30Gv/adPv7Svpg+xVvCp8LSntKqufGEoG+u5Fx3 Vgk/iu2yRKR+ckyv3xsyBDWyWZ/HQK/GfojAZamK8dBdnm+IXaPaoFZ6pz92/0CG C0jkJcWXSkSQdA987ueuuWFxC4daQfPRr2n1dnNyhW1GEC7O4ShjgrGuVEJi4GAE REfiSLcOoRiHHt4I6JslAK9xfQt3Em6uuOpYoUie0cV0pNsSUuXlPIml2Si1m4Ry yJUPy/vRrE8RD1iQ2M6m0Ut2CL0/bcmAdjHlddevVnz/1L6huiWNggI8myc2Pzfd qrhjsU59iaXEUDAXz3eUMb6LOIed/JW+Ls6aVrCeg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6C447BA43B; Thu, 22 Feb 2018 05:57:46 -0500 (EST) Message-Id: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> From: John To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 Date: Thu, 22 Feb 2018 10:57:46 +0000 Subject: make installworld broke / how to recover X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:57:53 -0000 Hello, When trying to upgrade from 11-stable to 12-current, make installworld broke. The OS is mainly on a ssd, there is zfs installed (usr/src is on zfs). Is there a guide somewhere that shows how to recover from this situation? both 11.1 and 12-current kernels are bootable. I can just blat the system and install from scratch but that would mean i've not learned how to fix it. I have subsequently tried make buildworld again but it bais out with this error: ##### objcopy --only-keep-debug xinstall.full install.debug objcopy --strip-debug --add-gnu-debuglink=install.debug xinstall.full xinstall sh /storage/usr/src/tools/install.sh -s -o root -g wheel -m 555 xinstall /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/bin/install sh /storage/usr/src/tools/install.sh -o root -g wheel -m 444 install.debug /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/lib/debug/usr/bin/install.debug install: install.debug: Inappropriate file type or format *** Error code 71 Stop. make[3]: stopped in /storage/usr/src/usr.bin/xinstall *** Error code 1 Stop. make[2]: stopped in /storage/usr/src *** Error code 1 Stop. make[1]: stopped in /storage/usr/src *** Error code 1 Stop. make: stopped in /storage/usr/src ##### thanks, -- John tech-lists@zyxst.net From owner-freebsd-current@freebsd.org Thu Feb 22 11:11:00 2018 Return-Path: Delivered-To: freebsd-current@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 94650F22CA2 for ; Thu, 22 Feb 2018 11:11:00 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 10FA87BC3A for ; Thu, 22 Feb 2018 11:11:00 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id w77so10116506wrc.6 for ; Thu, 22 Feb 2018 03:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=owkj+GFxEJU9KWwFcM+e+uj9RXrayUqY3PLUIBUPIQw=; b=leKExeN2Zmy5H2Lgh7RI+tIllqIuJhqgFytTjNOH+ySceJduQ0Wsh3fta3wXNIoDIw jBluLAgU82QpNM79SYa6yV36WxzSkvsdYpuLne1oubjDjMeJTsZXwTQEYpsk1/uKSMpE GR+CSDnxd2yfoiiolXuKMsJ0BaUbNA2W8IprGM6BnCzCbaVqIzpHPm1GrEUakh9cETZ8 wFI+NZkNm46u6l7lvWUjrp3NS8K46GTBgudfQBY3ctda4o6H+YVDbgHjtGBw4MdlHFWe H033aruQhXkmsmLLsKZ32GsPm9GCueaqY6pbM1z9ObwAVyPyVyR1gZXQRnoaZriXW074 BxlA== 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=owkj+GFxEJU9KWwFcM+e+uj9RXrayUqY3PLUIBUPIQw=; b=eu2tiBavuagKmu0nCKuHW5R9+93lKS/UCTgvPSEr4HuLYIqMaS1cGhDYpA691SZ/S+ 9GP1XWa1D46lMEpwT2GaAEI8iDlg6og0khrBbQqBNLwtKrrGKMC61Ez53wxZnu3lMnlx A5AGuttjUNIWYK4XSFJquhfwla1lKpeBq1vNmDIyw2uCMFp1a/Pis7ORtSzwtGJV5gm0 HzA3s7fYWEL6Yi377gN6MQQyFhDDmTzsqpKuzs0Yt8w7exdbCJSbY3bH7G6EcIR2NkIj D9bvo2JpEI1ac1joTObzzbClsrifLWc2D7AA+P8XdvNU/SPs0T/9Q2yEHWj8TudQovin g/hw== X-Gm-Message-State: APf1xPBVgZT/utW7+mxPvILcyUQEFbdOj/gcg3lhzz1vlqgAxU9ahKGz 4+JVHQGghZ2kVGlq4nXvNg1qwnry94y0mUrN6Uc= X-Google-Smtp-Source: AH8x226weg4wSIRM7rQ0NK8TnUOvNTajVgBAIP3QMropJYKIwhFO4LQbzmZqcHsGoEyIwtiZw+xTcyQYO738C/wiYIU= X-Received: by 10.223.196.129 with SMTP id m1mr5682780wrf.213.1519297858271; Thu, 22 Feb 2018 03:10:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.170.3 with HTTP; Thu, 22 Feb 2018 03:10:17 -0800 (PST) In-Reply-To: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> References: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> From: "Jack L." Date: Thu, 22 Feb 2018 03:10:17 -0800 Message-ID: Subject: Re: make installworld broke / how to recover To: John Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 11:11:00 -0000 maybe try a clean buildworld, update /usr/src to the latest version, rm -rf /usr/obj, then make buildworld && make installworld && make kernel and see if that fixes the issue? On Thu, Feb 22, 2018 at 2:57 AM, John wrote: > Hello, > > When trying to upgrade from 11-stable to 12-current, make installworld > broke. The OS is mainly on a ssd, there is zfs installed (usr/src is on > zfs). Is there a guide somewhere that shows how to recover from this > situation? both 11.1 and 12-current kernels are bootable. I can just blat > the system and install from scratch but that would mean i've not learned > how to fix it. I have subsequently tried make buildworld again but it bais > out with this error: > > ##### > > objcopy --only-keep-debug xinstall.full install.debug > objcopy --strip-debug --add-gnu-debuglink=install.debug xinstall.full > xinstall > sh /storage/usr/src/tools/install.sh -s -o root -g wheel -m 555 > xinstall /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/bin/install > sh /storage/usr/src/tools/install.sh -o root -g wheel -m 444 > install.debug /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/lib/ > debug/usr/bin/install.debug > install: install.debug: Inappropriate file type or format > *** Error code 71 > > Stop. > make[3]: stopped in /storage/usr/src/usr.bin/xinstall > *** Error code 1 > > Stop. > make[2]: stopped in /storage/usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /storage/usr/src > *** Error code 1 > > Stop. > make: stopped in /storage/usr/src > > ##### > > thanks, > > -- > John > tech-lists@zyxst.net > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Feb 22 11:40:33 2018 Return-Path: Delivered-To: freebsd-current@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 71C7FF252EB for ; Thu, 22 Feb 2018 11:40:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDA97D14F for ; Thu, 22 Feb 2018 11:40:31 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6C0CF20C7C for ; Thu, 22 Feb 2018 06:40:30 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Thu, 22 Feb 2018 06:40:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Kvy35rlhZ747OrpRXG9Z6AwJxXfPc UwVUN+1IEpM0e0=; b=MWO5di0D/D6Nc4oSiShl83Y/N4nI7LVUk1sJArX6hvx1Z 8gqkfYSCObjpxQke0a/1X1F/OInsRnNUlPhx64c5/qxxomI7SAIiXx3KZSUNBB2y kZehNsc7mmu2HIfSnx5H79VH6Y2qORgWgEGEBxH1U8hO3DESPg1OkzMnzixghuiH +LWOnwUTOSIJlaM+gTwi7zPMCZUP1qgGZcVPBjkb2aeqFGEVbuWEcnImDslUR9m0 4pp3+ipNCUg8eJcZMj0bAI43p4hHRCjpKEaQMA6/LkctMNtl2Q8gxFpbM6PY5l6r ZUqqFI/mgG5KqnUi/WyUFMJJF7L+mDiFGtRqfm8Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Kvy35r lhZ747OrpRXG9Z6AwJxXfPcUwVUN+1IEpM0e0=; b=B5v9Tv52u8IAv0+6KwLZjO ZotwKg9XvwkNp4IXk7nKKG1lG1vOZB04xMhbE3K1ggzpPdKV6Ntko9fBerxI6bfy DuPQy00blfettFt7gnSPnvBK+Sm2zHgCCpkTFxPZ91ZgMd8bvsvxS1n4SDRNEQPD WMmMvW+lyQLG9N2GgWcoFMsPlo3CNwSO07MEcEPlCazefc8t1DlxT3jgFZTzvDcF H3eMa5wYatOoewS4Fl8u/cE/bunD56Qo3pNOXZE2ARA8Qn7DZdL9Qr2zzXyF7vFy 0/4RooyJyVkGXtNOWnZprP33TTZgy9PKSzpfHPiF3Ce11mANP6WEnqTyP8tWzp4Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 44AA7BA43B; Thu, 22 Feb 2018 06:40:30 -0500 (EST) Message-Id: <1519299630.664276.1279544696.7DB0D25D@webmail.messagingengine.com> From: John To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 In-Reply-To: References: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> Date: Thu, 22 Feb 2018 11:40:30 +0000 Subject: Re: make installworld broke / how to recover X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 11:40:33 -0000 Hi, thanks for responding On Thu, 22 Feb 2018, at 11:10, Jack L. wrote: > maybe try a clean buildworld, update /usr/src to the latest version, rm -rf > /usr/obj, then make buildworld && make installworld && make kernel and see > if that fixes the issue? I booted to the old kernel as it's apparently in sync with the (broken) world: root@desktop:/usr/src# make -j32 cleandir && make -j32 clean && make -j32 clean <-- just to make sure! [...] root@desktop:/usr/src# less /etc/make.conf /etc/make.conf: No such file or directory root@desktop:/usr/src# less /etc/src.conf /etc/src.conf: No such file or directory root@desktop:/usr/src# svnlite update Updating '.': At revision 329819. root@desktop:/usr/src# rm -rf /obj/* [ my /usr/obj is symlinked to /obj as /obj is on a SSD] root@desktop:/usr/src# uname -KU 1101510 1101510 root@desktop:/usr/src# make -j1 buildworld [...] ===> usr.bin/xinstall (obj,all,install) /usr/obj/storage/usr/src/tmp/storage/usr/src/usr.bin/xinstall created for /storage/usr/src/usr.bin/xinstall echo xinstall.full: /usr/lib/libc.a /usr/lib/libmd.a /usr/obj/storage/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend cc -O2 -pipe -I/storage/usr/src/contrib/mtree -I/storage/usr/src/lib/libnetbsd -g -MD -MF.depend.xinstall.o -MTxinstall.o -std=gnu99 -Qunused-arguments -I/usr/obj/storage/usr/src/tmp/legacy/usr/include -c /storage/usr/src/usr.bin/xinstall/xinstall.c -o xinstall.o cc -O2 -pipe -I/storage/usr/src/contrib/mtree -I/storage/usr/src/lib/libnetbsd -g -MD -MF.depend.getid.o -MTgetid.o -std=gnu99 -Qunused-arguments -I/usr/obj/storage/usr/src/tmp/legacy/usr/include -c /storage/usr/src/contrib/mtree/getid.c -o getid.o cc -O2 -pipe -I/storage/usr/src/contrib/mtree -I/storage/usr/src/lib/libnetbsd -g -std=gnu99 -Qunused-arguments -I/usr/obj/storage/usr/src/tmp/legacy/usr/include -static -L/usr/obj/storage/usr/src/tmp/legacy/usr/lib -o xinstall.full xinstall.o getid.o -lmd -legacy objcopy --only-keep-debug xinstall.full install.debug objcopy --strip-debug --add-gnu-debuglink=install.debug xinstall.full xinstall sh /storage/usr/src/tools/install.sh -s -o root -g wheel -m 555 xinstall /usr/obj/storage/usr/src/tmp/legacy/usr/bin/install sh /storage/usr/src/tools/install.sh -o root -g wheel -m 444 install.debug /usr/obj/storage/usr/src/tmp/legacy/usr/lib/debug/usr/bin/install.debug install: install.debug: Inappropriate file type or format *** [_proginstall] Error code 71 make[3]: stopped in /storage/usr/src/usr.bin/xinstall 1 error make[3]: stopped in /storage/usr/src/usr.bin/xinstall *** [_bootstrap-tools-usr.bin/xinstall] Error code 2 make[2]: stopped in /storage/usr/src 1 error make[2]: stopped in /storage/usr/src *** [_bootstrap-tools] Error code 2 make[1]: stopped in /storage/usr/src 1 error make[1]: stopped in /storage/usr/src *** [buildworld] Error code 2 make: stopped in /storage/usr/src 1 error make: stopped in /storage/usr/src -- John tech-lists@zyxst.net From owner-freebsd-current@freebsd.org Thu Feb 22 12:39:32 2018 Return-Path: Delivered-To: freebsd-current@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 81E0BF2A3B3 for ; Thu, 22 Feb 2018 12:39:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 CDC3C804F7 for ; Thu, 22 Feb 2018 12:39:31 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-70-98.dz.commufa.jp [124.18.70.98]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w1MCdLpE094449 for ; Thu, 22 Feb 2018 21:39:21 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 22 Feb 2018 21:39:20 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: A small procedural request Message-Id: <20180222213920.c8cf9bf57e76b5e36632c51a@dec.sakura.ne.jp> In-Reply-To: <7c133301-deb6-e747-3932-1c4cf67bced9@freebsd.org> References: <1ec9ccb4-0f0e-e525-4ce8-71d9d34172ae@freebsd.org> <20180221201405.4c0b1262e2f239616120869a@dec.sakura.ne.jp> <7c133301-deb6-e747-3932-1c4cf67bced9@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 12:39:32 -0000 On Wed, 21 Feb 2018 22:22:08 +0800 Julian Elischer wrote: > On 21/2/18 7:14 pm, Tomoaki AOKI wrote: > > Hi. > > > > +1. But have one suggestion for format. > > Something like > > > > Broken by: rXXXXXXX > > Broken by: Unknown (Bugfix but the revision introduced it is unknown) > > > > and optionally > > > > Broken by: No (To emphasize it's NOT a bugfix.) > > I think that is probably too much, but the$B".".".".".".".(B Broken by:$B".(B would be > good. Maybe not all committers would add this info. But examples should be useful for who wants to write. ;-) > > would be better for scripts already handling "MFC after: " or > > "X-MFC-With: " etc. to support this. > > > > If put on the top with "MFC rXXXXXX: Comments", it can be > > > > FIX rXXXXXX: Comments > > possibly.. > that Would allow some sort of collection of the data to$B".(B suggest good > places to > retrospectively base your head following (but not too closely) branches. > but may be more work that people are willing to do.. I guess so, too. It's useful, but not a creative work. I think less is better than nothing. > For myself, just a hint of where the bug was introduced would help a lot. > further more if you have a branch/product based at some point in time, > this would help > you to know when a patch needs to be cherry picked back to your code. Yes. I 100% agree. BTW, "X-MFC-With: " is sometimes used for the same purpose, but not always. (Used for bugfixes for new feature, and related new features.) > > > > or for multiple revisions, > > > > FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals > > FIX rXXXXXX-rYYYYYY: Comments for massive continuous range > > > > would be better. > > > > Regards. > > > > > > On Wed, 21 Feb 2018 12:01:33 +0800 > > Julian Elischer wrote: > > > >> Hi,$B".(B I have a very small request to those committing into head. > >> > >> If you commit a fix, then if it is possible to easily do so, can you > >> give the revision number in which the regression was introduced? > >> > >> like "this was$B".(B broken in r329xxx" > >> > >> this allows people who are looking for specific problems to say "Ok > >> that bug was introduced after the snapshot I'm working on and can't be > >> my issue". > >> > >> (we are not always working on the very tip). > >> > >> > >> thanks > >> > >> Julian > >> > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> > >> > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Thu Feb 22 13:25:58 2018 Return-Path: Delivered-To: freebsd-current@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 D15C8F02B05 for ; Thu, 22 Feb 2018 13:25:57 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 7A03F82122 for ; Thu, 22 Feb 2018 13:25:57 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8A45920DD3 for ; Thu, 22 Feb 2018 08:25:56 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Thu, 22 Feb 2018 08:25:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Cl7afB/DBGkZ6nfW+idtsrS3i7i7Y 3+k9A81d2aiy5Q=; b=bomtK1T+GGSupx5WeWDdMCM679hAkSintRU0QgbzvmYwB 4VBdm73GYszxwpIVPBnKWV5gpgyNZ5OfdTMgdpVx4vkFwyNahTAwGJv2R3C35ebs U4lz7n+7tT+AxOaiYfpuGxoRGiz5q6RQMwOvOcxXa6tyFWXPbnIZ9PzOPQ9KUx2e xn5M7boB2mVbVdzqgA3H63OmVEI7gtjD7Fge+1o6Mru0QpfcPULP0/NQH56DWN9B 8oFM3MAkfklTfgLHYbbO27S1EyVc/rY8cQizqLzakcV0g3ia0/e3daUmuTqzwyMA DbPFvbtw3kDXar/dL1iS4OLhZpvNWMdAgGcLy7Ang== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Cl7afB /DBGkZ6nfW+idtsrS3i7i7Y3+k9A81d2aiy5Q=; b=FbBSgH2dYq9aPVixtVt5Zc FcWFNIOhKlpL2MqRlIysxwlsw511cqFRgI8OoMNXNDKDxfHYOlb07W3q33XwGPvf btT3IKNx5nXj99e96YqyCgF8h2+w1MvoUG4fetJDenetvs4G0LFZ8lD4s12cmrXX NjcwQQGxq06Mf27ufAbqyRLgpWR/Y1cTJ4OG1cSTF9hdkD6ZGkLF0S5+Cxq+he2Z rW+pvqB9S3rbZ7B/44qXNAGkIOlA+ixS6beEZeinV84fxVGm9WqULT4OJjvpjQcG HX7wocBVw6aLZ3VLK6f1royp/h6mwTC/pEZXYm1A5lfkNYk2sswYdBm7ocYyXkpA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6B5674133; Thu, 22 Feb 2018 08:25:56 -0500 (EST) Message-Id: <1519305956.3128800.1279637856.74E007EC@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 Subject: Re: P2P core/daemon in Base? In-Reply-To: <20180222025158.dqookgcvscyihyeb@privacychain.ch> References: <20180222025158.dqookgcvscyihyeb@privacychain.ch> Date: Thu, 22 Feb 2018 14:25:56 +0100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:25:58 -0000 On Thu, 22 Feb 2018, at 03:51, Le Baron d=E2=80=99Merde wrote: > Dear Fellows, >=20 > Nothing new and probably will not be implemented, specially by me who=20 > can't write code, but I am sharing this idea anyway. >=20 > The point would be to have a P2P core/daemon in Base with some API to be= =20 > used by clients, including pkg, freebsd-update, and portsnap becoming=20 > P2P based/capable, and would also allowing any user that desire to=20 > become a FreeBSD mirror[1]. What would reduce the load on the FreeBSD=20 > infrastructure. At present if nobody's downloading 11.1R.txz then there's no load to the mi= rrors. Most P2P implementations require some form of seed node that keeps t= rack of active peers & blocks, so it's not quite a free lunch. I've an incomplete erlang-based version of https://tools.ietf.org/html/rfc7= 574 called PPSP (Peer-to-Peer Streaming Protocol), and I always felt a C or rust-based implementation of it would be a great addition to FreeBSD whethe= r ports or base. PPSP is a multi-peer streaming mix of: - merkle tree across arbitrary blocks of data - lightweight 'torrent-ish' UDP protocol for requesting and sharing blocks - optional live-streaming (i.e. stream starts before full data is available) - optional cryptographic signatures For example, I'd love to be able to "zfs send" via a multipeer protocol and= have it Do The Right Thing in transferring this to multiple "zfs recv" pee= rs, or have our custom pkg repo pull stuff off the adjacent servers rather = than stumble across the Pacific Ocean for the data. [Yes I'm aware pkg can be cached already]. If somebody is interested in working on this please get in touch, I would p= ut some funds in and can offer some context on the spec as I was involved in it. Also, if it's something the FreeBSD Foundation might consider jointly suppo= rting, I would help with the paperwork & submission. A+ Dave =E2=80=94 Dave Cottlehuber +43 67 67 22 44 78 Managing Director Skunkwerks, GmbH http://skunkwerks.at/ ATU70126204 Firmenbuch 410811i From owner-freebsd-current@freebsd.org Thu Feb 22 13:41:35 2018 Return-Path: Delivered-To: freebsd-current@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 1ECC7F040F3 for ; Thu, 22 Feb 2018 13:41:35 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 C14D582C4F for ; Thu, 22 Feb 2018 13:41:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0982B20E58 for ; Thu, 22 Feb 2018 08:41:34 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 22 Feb 2018 08:41:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XPFOyCtciS63Ca4ZG9H+gGuLs+s5WHXUi4qNAdOVO5c=; b=q8B7XQQC riGDfwcp63c3DKzyYryq8bJKl0iBDJgWif8Zm1HwIta2iP7MoIx9tR+f0I0lC5l0 vJ5xe5IGRC0AhWa/9pHI5R7u8cwinwwLIOgdw18XADV7wsAgpgzM064SlAdO2Bnv EfyL1zGpTM5anCfjt4ElQhq6//IgF/AJD8vZhrSxNqDomRJu17qa+K+rKQVGuSBV edoJPmLwLtSY7EuJTKaNuWxO9Y3wviKFs5eIJp4o69e0gH5f4BGL3nFw3Z7vFTuW iWwq+WBC1dgXbKPxQxjIFii9bIwobCzIRiBwGxStLGq5hwvVtkpFbgbC1/cL+aqN DS7aFNucb0dKlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=XPFOyCtciS63Ca4ZG9H+gGuLs+s5W HXUi4qNAdOVO5c=; b=AHNoCqqdVF7eOJ1Q2PHFEZV0VG6O1xmL9p+d+ODEyeZYF 5mZfVVahuWABfCYSu7yIN6UmkGM1w0hMFJoJMkFkosBsP8dDbGBa1gGDvDfaWznN q1I0RjSMOc5PYQAbaB/vC1Bqy06LHXtKUIrcg6cdrdJZsKswCVMKmfTPhm7dhct+ XR6wizcfHtUg5q9/VGfzhidaDJ9lJNW91iAZtLPbZgFBquLxcSv8xs5+/FhW+NuU pl/uk1cE5GeeaNY7HUi4/OebDJ2oKKz0woQq7phLirLHPsi5eSCud4jv3LKpOeSL scPce6v0kcintAeUYfnFj2wIbJoLGk1CTgr1NdMmA== X-ME-Sender: Received: from v007.zyxst.net (v007.zyxst.net [89.145.100.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 86CC67E070 for ; Thu, 22 Feb 2018 08:41:33 -0500 (EST) Date: Thu, 22 Feb 2018 13:41:32 +0000 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: make installworld broke / how to recover Message-ID: <20180222134131.GA45189@v007.zyxst.net> Mail-Followup-To: freebsd-current@freebsd.org References: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:41:35 -0000 On Thu, Feb 22, 2018 at 03:10:17AM -0800, Jack L. wrote: >maybe try a clean buildworld, update /usr/src to the latest version, rm -rf >/usr/obj, then make buildworld && make installworld && make kernel and see >if that fixes the issue? Is there a documented way of say booting to memstick, starting fixit, mounting the zfs from the broken system then building/installing a new world? Is there enough "environment" and utilities to do this on the fixit disk? [never had this happen before, anticipate steep learning curve] -- J. From owner-freebsd-current@freebsd.org Thu Feb 22 13:50:26 2018 Return-Path: Delivered-To: freebsd-current@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 0213BF04F68 for ; Thu, 22 Feb 2018 13:50:26 +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 7550683573; Thu, 22 Feb 2018 13:50:24 +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 w1MDoA23091429; Thu, 22 Feb 2018 05:50:10 -0800 (PST) (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 w1MDo96h091428; Thu, 22 Feb 2018 05:50:09 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201802221350.w1MDo96h091428@pdx.rh.CN85.dnsmgr.net> Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d In-Reply-To: <20180222092620.7c327329@ernst.home> To: gljennjohn@gmail.com Date: Thu, 22 Feb 2018 05:50:09 -0800 (PST) CC: "O. Hartmann" , Chris H , FreeBSD Current , Warner Losh , Ed Maste , Michael Tuexen , Mark Johnston 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-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:50:26 -0000 > On Thu, 22 Feb 2018 08:37:07 +0100 > "O. Hartmann" wrote: > > > On Tue, 20 Feb 2018 12:39:53 +0100 > > Gary Jennejohn wrote: > > > > > On Mon, 19 Feb 2018 14:18:15 -0800 > > > "Chris H" wrote: > > > > > > > I'm seeing a number of messages like the following: > > > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > > > > > > > and was wondering if it's anything to be concerned with, or whether > > > > fsck(8) is fixing them. > > > > This began to happen when the power went out on a new install: > > > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST > > > > 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > > > > which hadn't yet been hooked up to the UPS. > > > > I performed an fsck in single user mode upon power-up. Which ended with the > > > > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL. > > > > I answered Y. > > > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: > > > > newfs -U -j > > > > > > > > Thank you for all your time, and consideration. > > > > > > > > > > fsck fixes these errors only when the user does NOT use the journal. > > > You should re-do the fsck. > > > > > > > When first these mysterious errors occured on several boxes running CURRENT, > > that was in December 2017 if I'm right, I also whitnessed mysterious and > > frequent crashes on several SSD driven machines, where this error described > > above occured. > > > > While the error vanished somehow in the meanwhile while CURRENT proceeds, the > > crashes continued - on two boxes, I dumped restore the OS on the system's SSD > > by reformatting the SSD from sratch (UFS2, soft update+ journaling). On those > > boxes the mysterious crashes vanished since then! > > > > On box left so far, my workstation. And this box continous to crash now and > > started crashing today again while compiling world/kernel. > > > > The fun-part is: even after a clean shutdown, where I can not detect any > > filesystem inconsistencies and rebooting and, again: no reported > > inconsistencies on the console/messages/logs, the box crashes spontanously. Now > > (today) I could trigger the reboot by starting "make -j4 buildworld > > buildkernel" and after showing the initial compiler statements/build framework > > statements, the box went to Nirwana. A well known phenomenon right now. > > > > I checked now the consistency of the filesystem, here is the result of > > the /usr/obj tree, which is a dedicated GPT partition > > (label: /dev/gpt/usr.obj): > > > > > > [...] > > root@box1:~ # fsck -fy /dev/gpt/usr.obj > > ** /dev/gpt/usr.obj > > ** Last Mounted on /usr/obj > > ** Phase 1 - Check Blocks and Sizes > > ** Phase 2 - Check Pathnames > > UNALLOCATED I=515 OWNER=root MODE=0 > > SIZE=0 MTIME=Feb 22 07:25 2018 > > NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new > > > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > > REMOVE? yes > > > > DIRECTORY CORRUPTED I=169691 OWNER=root MODE=40775 > > SIZE=1536 MTIME=Feb 22 05:16 2018 > > DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd > > > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > > SALVAGE? yes > > > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > FREE BLK COUNT(S) WRONG IN SUPERBLK > > SALVAGE? yes > > > > SUMMARY INFORMATION BAD > > SALVAGE? yes > > > > BLK(S) MISSING IN BIT MAPS > > SALVAGE? yes > > > > 126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4% > > fragmentation) > > > > ***** FILE SYSTEM MARKED DIRTY ***** > > > > ***** FILE SYSTEM WAS MODIFIED ***** > > > > ***** PLEASE RERUN FSCK ***** > > > > [...] > > > > When doing a installworld, I pre-emptively perform in single user mode before > > mounting the partitions a "fsck -yf" two times. In most cases, the filesystem > > are reported clean, but sometimes especially those under high I/O (/usr/src and > > mostly /usr/obj on this build machine) there are reports of corruption. > > > > As I reported, the very same behaviour occured on three boxes simultanously and > > I got rid of it by completely reformatting the SSDs (never had issues so far > > with HDD based boxes!). > > > > I hope I can refurbish this weekend the remaining box and I could report, if > > desired, whether this box returns to a healthy state as the others or if my > > observation was a simple coincidence of issues ... > > > > Thanks for the patience, > > > > I also see such problems only with SSDs. Probably because the SSDs > are buffering writes internally which never make it into the flash > chips, although the SSDs report that the writes were completed. > > HDDs apparently don't do that, or have a smaller cache. > > I then also run fsck in single-user mode, but I explicitly do NOT > use the journal, i.e., I do NOT run fsck -y. But I guess that using > fsck -fy is equivalent to not using the journal. fsck -y is not the same as running fsck and answer the special question that has been added to fix something. (I believe this is to turn back on the cgcksum thing). Kirk would have to correct me if I am wrong there. > In my case the SSDs are error free after doing the fsck without > using the jounal until the next crash happens. My box with a > Ryzen 5 1600 tends to hang for no apparent reason, so I see these > errors fairly frequently because I have to reset the box :( Instead of running fsck -fy or fsck -y I would recommend running 'fsck' at single user and see what it finds, and what options it might give you to "fix" or "enable". -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Thu Feb 22 14:24:09 2018 Return-Path: Delivered-To: freebsd-current@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 47A64F07DE8 for ; Thu, 22 Feb 2018 14:24:09 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B45BF84F43; Thu, 22 Feb 2018 14:24:08 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkSOt-1eD47536ZH-00cO3u; Thu, 22 Feb 2018 15:18:28 +0100 Date: Thu, 22 Feb 2018 15:18:25 +0100 From: "O. Hartmann" To: Gary Jennejohn Cc: "O. Hartmann" , "Chris H" , "FreeBSD Current" , Warner Losh , Ed Maste , Michael Tuexen , Mark Johnston Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Message-ID: <20180222151825.2b193c4a@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180222092620.7c327329@ernst.home> References: <20180220123953.5e987691@ernst.home> <20180222083707.73ae3036@freyja.zeit4.iv.bundesimmobilien.de> <20180222092620.7c327329@ernst.home> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4GUxYy2SGsZL65bF1RMT/PlTEpyErlajOuDX+L9vJqTQoTXREv1 n79zlOjWRd9WunYfFGe3YzZm9QfK0b/TzqlVeCVcnVX7Vv3FbIL8E1sIMkoomj0ta1JLnMx 3O/tjCeY4NdGuTc9LprBcfMrhpT/ZSsQkJ7stSKoc5Z3CpDFmElYIUeeDjqeDl/C+zXtpSN Ow75nFtuwDVgwjs8AQrWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0VZ+XV3vngA=:ZViJeOfVox/pkzdvyBWgqp qtxFvZwJwwasGRFp5ZCAkClwwIp7UWyGh1sa+9Jzw/Z+wOki+8XRM1FKn6ZstxFwR8UULU9S2 f8uZTYbqCJDo9cVqt9D4tD6dq9ywkqwK4PiHWsWfHzeA4czjtiOsY9Trc9vwricCEIHRXuJO6 EQSKb5V86L2cal4dXxCRgHY48rywmW30TV/2eZGSaeyFkXAWWKEOaX/yJ2y5vuoWaJVt+TiyJ /bZ5R2c/zf8HuVMmy4oljgwJoI/1ulTV0SyWXKtjEj2zFdXkf4yWOwc1Y3PwXuFxf3yODwRVp KYsz1TIyG/xtVAiO5UMWzD6LKs9mDxPAlC3f6zjgsDX0IL5jqNDSUy/mdAyejVSwF3azaOmRr SgtCrnhMF+VjFGFnt4lbI9PxWiDmqY5wm1dkYx5lg0aOhTHOoA9Raa4CMZcfF7sHCT1q0MM4A lFGSOeYZ860j950YX6kvZx4T/H2YSxAVPWyfqAwuIbpkGSvVMjTyPYwj5Q6pGwANa9MWwQgIh XP11rdrhk++4Q/YaCflM76ngkdfTQeQS4LkEmze8+KFIfrasWThuj4NvljzcYGii2myP4UD/F mU6P5QpRN9pElhgNO3dUZJNy8ehQ2WRsIwOm9ATPAM7eQI0hRp52y/ALfikuU8fYqSvUeV140 x/NQrGFsYe9S0g8J87P8lyY7fCM+TUBSnveChRdvMbeTBbGPco2fi0JsllBL2qejPQaOWoGZK aBkfTMkW1PWO3+WWgngkdF7YC+Ve/nudR1VIdHDScFuIZBL9nnHtsKIFR2S6jv61U/PPMIArH Nop+++Z+dqmf/WQEABpucX87ZXNP/jF5lUsimc703MfFErjS18= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:24:09 -0000 On Thu, 22 Feb 2018 09:26:20 +0100 Gary Jennejohn wrote: > On Thu, 22 Feb 2018 08:37:07 +0100 > "O. Hartmann" wrote: > > > On Tue, 20 Feb 2018 12:39:53 +0100 > > Gary Jennejohn wrote: > > > > > On Mon, 19 Feb 2018 14:18:15 -0800 > > > "Chris H" wrote: > > > > > > > I'm seeing a number of messages like the following: > > > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > > > > > > > and was wondering if it's anything to be concerned with, or whether > > > > fsck(8) is fixing them. > > > > This began to happen when the power went out on a new install: > > > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 > > > > PST 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > > > > which hadn't yet been hooked up to the UPS. > > > > I performed an fsck in single user mode upon power-up. Which ended with > > > > the mount points being masked CLEAN. I was asked if I wanted to use the > > > > JOURNAL. I answered Y. > > > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd > > > > thusly: newfs -U -j > > > > > > > > Thank you for all your time, and consideration. > > > > > > > > > > fsck fixes these errors only when the user does NOT use the journal. > > > You should re-do the fsck. > > > > > > > When first these mysterious errors occured on several boxes running CURRENT, > > that was in December 2017 if I'm right, I also whitnessed mysterious and > > frequent crashes on several SSD driven machines, where this error described > > above occured. > > > > While the error vanished somehow in the meanwhile while CURRENT proceeds, > > the crashes continued - on two boxes, I dumped restore the OS on the > > system's SSD by reformatting the SSD from sratch (UFS2, soft update+ > > journaling). On those boxes the mysterious crashes vanished since then! > > > > On box left so far, my workstation. And this box continous to crash now and > > started crashing today again while compiling world/kernel. > > > > The fun-part is: even after a clean shutdown, where I can not detect any > > filesystem inconsistencies and rebooting and, again: no reported > > inconsistencies on the console/messages/logs, the box crashes spontanously. > > Now (today) I could trigger the reboot by starting "make -j4 buildworld > > buildkernel" and after showing the initial compiler statements/build > > framework statements, the box went to Nirwana. A well known phenomenon > > right now. > > > > I checked now the consistency of the filesystem, here is the result of > > the /usr/obj tree, which is a dedicated GPT partition > > (label: /dev/gpt/usr.obj): > > > > > > [...] > > root@box1:~ # fsck -fy /dev/gpt/usr.obj > > ** /dev/gpt/usr.obj > > ** Last Mounted on /usr/obj > > ** Phase 1 - Check Blocks and Sizes > > ** Phase 2 - Check Pathnames > > UNALLOCATED I=515 OWNER=root MODE=0 > > SIZE=0 MTIME=Feb 22 07:25 2018 > > NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new > > > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > > REMOVE? yes > > > > DIRECTORY CORRUPTED I=169691 OWNER=root MODE=40775 > > SIZE=1536 MTIME=Feb 22 05:16 2018 > > DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd > > > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > > > SALVAGE? yes > > > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > FREE BLK COUNT(S) WRONG IN SUPERBLK > > SALVAGE? yes > > > > SUMMARY INFORMATION BAD > > SALVAGE? yes > > > > BLK(S) MISSING IN BIT MAPS > > SALVAGE? yes > > > > 126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4% > > fragmentation) > > > > ***** FILE SYSTEM MARKED DIRTY ***** > > > > ***** FILE SYSTEM WAS MODIFIED ***** > > > > ***** PLEASE RERUN FSCK ***** > > > > [...] > > > > When doing a installworld, I pre-emptively perform in single user mode > > before mounting the partitions a "fsck -yf" two times. In most cases, the > > filesystem are reported clean, but sometimes especially those under high > > I/O (/usr/src and mostly /usr/obj on this build machine) there are reports > > of corruption. > > > > As I reported, the very same behaviour occured on three boxes simultanously > > and I got rid of it by completely reformatting the SSDs (never had issues > > so far with HDD based boxes!). > > > > I hope I can refurbish this weekend the remaining box and I could report, if > > desired, whether this box returns to a healthy state as the others or if my > > observation was a simple coincidence of issues ... > > > > Thanks for the patience, > > > > I also see such problems only with SSDs. Probably because the SSDs > are buffering writes internally which never make it into the flash > chips, although the SSDs report that the writes were completed. > > HDDs apparently don't do that, or have a smaller cache. > > I then also run fsck in single-user mode, but I explicitly do NOT > use the journal, i.e., I do NOT run fsck -y. But I guess that using > fsck -fy is equivalent to not using the journal. > > In my case the SSDs are error free after doing the fsck without > using the jounal until the next crash happens. My box with a > Ryzen 5 1600 tends to hang for no apparent reason, so I see these > errors fairly frequently because I have to reset the box :( > In my case here, I do not have to wait for a crash with an inconsistent filesystem to have some weird behaviour with the journaling. Somehow, in my naive terms, there is some strange problem hidden on partitions. Since December last year I had very weird and bad corruptions of the filesystem when performing "make installworld": boot process stopped at BTX or claimed having no loader, although the installation process made it up to installing everything in /boot/; but other folders like /sbin oder /libexec contained nullified files. These corruptions even happend then, when I "fsck'ed" the SSD prior to "make installworld" in single-user mode. Result of that was a installation from a USB flash and then again, rebuild world, kernel, and so on. Those horrible failures went away on all SSD based systems when reformatting /usr/src, /usr/obj and /tmp (all dedicated partitions in my case) where the inconsitencies occured most. Those systems, where I also reformatted /, all of these problems went away! The remaining box were I havn't so far reformatted / is the box in question here. Now, after /usr/obj and /usr/src newly formatted, the horror corruptions while performing installworld disapperead, but the crashes are going on. Especially after heavy I/O with lots of storage operations trigger spontanous crashes. For me, it looks like there is something really fishy with the UFS2. Since I perfomr on three boxes almost daily buildworlds with CURRENT, I guess something happened to the filesystem when CURRENT got hickups and the "inconsistency" moved on until a complete newfs of the whole SSD. I'm sorry not being able having more qualified data ... Regards, Oliver From owner-freebsd-current@freebsd.org Thu Feb 22 15:39:22 2018 Return-Path: Delivered-To: freebsd-current@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 137B4F0FC88 for ; Thu, 22 Feb 2018 15:39:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 7786D697E3 for ; Thu, 22 Feb 2018 15:39:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id x196so7988270lfd.12 for ; Thu, 22 Feb 2018 07:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=tPKNzaTbycO5TPq6Ibsc0af4IdUTG/uZ6Sndsry+NS0=; b=VvfDxltT7l+acnYnecBU2vimJI4PTLtwbmn7zikvGlFoavHlcLsKW1DOxvYKB8jH5Q JM37RaozGAmyy0iNbHtw8aCLKsffGpvAITHxaMdl0uzBglypfs5Ws31I+KJ34m67cOqG v1rxmfmSECUOEukM0apuKWOjYjbE732i4BGl3iVmvslh6mglOQAsxJbAf4mKIyI9OFDM WKA6OTQ/CeP2XBz0pzsQ/BkDoNTw+9DOEItj/ELK1OV4/nxMccMO/c6B1lbRsP3TVvhj 20it6mT5kAhtJuFWLLlMpOUHincTBeL6qxo1D7rPcIE1ZXErEQ+JUQR5DtjnJwyQka5v aCTg== 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:from:date:message-id:subject :to; bh=tPKNzaTbycO5TPq6Ibsc0af4IdUTG/uZ6Sndsry+NS0=; b=oMGz+RQdsWQ0+0Wdgn1CeBwDKErpJ/naEC6qhS1tOYHvStMsxW8THbWiA7JYNho6rZ 16JuwUpPGjF4h5bJHdda9VP9ZLpseMtoZSRG02l0XE3OJfQTuSL2moe+y+UoeGJnmVj8 LTyA2lM2S/bvYNYbVJBystRWhVpALuG1xmOlemxINzBejWXZH7R3vPouwuP2bhs46ymD xBW6SeYexFhkZ+6DrKSil0WJLNqw5TjtVmTkJFk3LdafFqH+5ejZXfk+nMsoct9YzaaC fU+R456KW/30b6AcgVhc2+icASYLCSoXCd/2uPFzZ3Cq2nIw5+6CjYttlZEpoZCyqzKd VPXw== X-Gm-Message-State: APf1xPBj8Ru2SiUJtM7NcmvwJvvMig/8mXXvRfgLQv3nT5QBUkHwlqTa vuB2xkqsFrm6IAcpGt/7fHBM1YhJEB4yD/7JwzyQZA== X-Google-Smtp-Source: AH8x226z1aiIt9LghwP21pzSQx60CjCj3I5nhEdbWPciRupkmOhu4k+ne5K3pRgoiVpfHjSm4zQW9n99djm6bXdcEjM= X-Received: by 10.46.9.150 with SMTP id 144mr3474537ljj.117.1519313959187; Thu, 22 Feb 2018 07:39:19 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.66 with HTTP; Thu, 22 Feb 2018 07:39:18 -0800 (PST) From: Alan Somers Date: Thu, 22 Feb 2018 08:39:18 -0700 X-Google-Sender-Auth: zK9HPm7v_5lZ6J978ew2a0JatrA Message-ID: Subject: pkg broken on FreeBSD-12: "Newer FreeBSD version for package py27-sphinxcontrib-websupport" To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:39:22 -0000 I have two FreeBSD 12-CURRENT amd64 systems that both refuse to install any new packages. "pkg update -f" doesn't help. When I try, I get a confusing error like this. $ sudo pkg update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 Fetching packagesite.txz: 100% 6 MiB 3.0MB/s 00:02 Processing entries: 0% pkg: Newer FreeBSD version for package py27-sphinxcontrib-websupport: - package: 1200058 - running kernel: 1200056 pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64 Processing entries: 100% Unable to update repository FreeBSD Error updating repositories It's confusing because: a) My running kernel actually is 1200058, as shown by "uname -K" b) I don't have py27-sphinxcontrib-websupport installed, so what is it complaining about? Does anybody know what's going on? -Alan From owner-freebsd-current@freebsd.org Thu Feb 22 15:51:06 2018 Return-Path: Delivered-To: freebsd-current@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 400B5F10C39 for ; Thu, 22 Feb 2018 15:51:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A90C96A121; Thu, 22 Feb 2018 15:51:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id g72so8052736lfg.5; Thu, 22 Feb 2018 07:51:05 -0800 (PST) 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=ngrM2JVtDgOQgfG5gnbMgGuFRCcyQAMrgR+iwC62LcI=; b=HpBokhedUkV9uWu0RoP9ohHSVwtudFqdaCgK7fsmZ7Q0oAPq4ZEZk20EXl3FfCZQ6f WCLH2xdC/Z9cYXi2mxY3yY/TUw7lh0cgPko1vmk9/lZx7CaogFNlPgN+QD8tBni8N8cb yZsCMXWRwh0a9DZ2ja9fDlQPuywgdNOLUaTFQTz9zT0OoflEKbi1aB7sPYgfdVU05ZfB PBUGBuhUxK5dIL1D9BizGyFXm333d0iWTI695Iz93+etob4tAi+5/Pe50UegQauDzkuZ 6HjEg1CvJWCgpJyniLuTAG47a2HpoEjJ5sgeYvRWRDFWHofSkRYk3JTciMtUv8d27TO6 QszA== 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=ngrM2JVtDgOQgfG5gnbMgGuFRCcyQAMrgR+iwC62LcI=; b=omOi0j/K4gJERkvj+qHRXJv6WQ/OrSJkHcqu2tLL+qf7ZkydIEasMWPnPHzUVeeHU5 EvYkqU0YSPEoCy74NK7hDUT/G11yuvcZwNJ6Avz6Rg1Tmjkpu1yv76oh0DqZCKaWY4fH qXbyEvEWJF9nxYF5fQA1BiSwoMmvoMweCRyXc7gAYcs7DjsDB+i9gXwC9ZG+dFW8BEgH 1ZR35ysTZA2a035jFhCtfgiUE0Iu/6DXgUmJmk5uqxdGBKi2rXy4GRM2HPVKo5zBDPty QU7pfHEcx8jYPqlYlfnMuO9PeHXgE/NICtcIRe0COoCRufneg1oNZfxgB3LJhKycG0wD 4lYw== X-Gm-Message-State: APf1xPCbij7NoipSJJhj59MYDxLS2Vz13RBB+Vqvprjxy/RCxs/3rXnS 5L0r80gGSyZXVftu5F50QEdbYM1y3m88ahs+6hPiDg== X-Google-Smtp-Source: AH8x2253qPecRyue8xZrmFn0xz081BG25KYdqs9ICJIakquIh8vQ/F918E27haovvZw3EPJA6wAufpJOMniSDqhqpZ4= X-Received: by 10.25.193.7 with SMTP id r7mr5762692lff.37.1519314663968; Thu, 22 Feb 2018 07:51:03 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.66 with HTTP; Thu, 22 Feb 2018 07:51:03 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Thu, 22 Feb 2018 08:51:03 -0700 X-Google-Sender-Auth: yEUQJn8g1nlEYglsWw8rZZXTuVk Message-ID: Subject: Re: pkg broken on FreeBSD-12: "Newer FreeBSD version for package py27-sphinxcontrib-websupport" To: Alan Somers Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:51:06 -0000 On Thu, Feb 22, 2018 at 8:39 AM, Alan Somers wrote: > I have two FreeBSD 12-CURRENT amd64 systems that both refuse to install > any new packages. "pkg update -f" doesn't help. When I try, I get a > confusing error like this. > > $ sudo pkg update -f > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 > Fetching packagesite.txz: 100% 6 MiB 3.0MB/s 00:02 > Processing entries: 0% > pkg: Newer FreeBSD version for package py27-sphinxcontrib-websupport: > - package: 1200058 > - running kernel: 1200056 > pkg: repository FreeBSD contains packages for wrong OS version: > FreeBSD:12:amd64 > Processing entries: 100% > Unable to update repository FreeBSD > Error updating repositories > > It's confusing because: > a) My running kernel actually is 1200058, as shown by "uname -K" > b) I don't have py27-sphinxcontrib-websupport installed, so what is it > complaining about? > > Does anybody know what's going on? > > -Alan > Nevermind. I found the workaround here. I still don't know why the error message mentions "sphinxcontrib-websupport", though. https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068615.html From owner-freebsd-current@freebsd.org Thu Feb 22 17:42:27 2018 Return-Path: Delivered-To: freebsd-current@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 A08A1F1A483 for ; Thu, 22 Feb 2018 17:42:27 +0000 (UTC) (envelope-from ohartmann@walstatt.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 32AA96F276 for ; Thu, 22 Feb 2018 17:42:27 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id E5654F1A482; Thu, 22 Feb 2018 17:42:26 +0000 (UTC) Delivered-To: current@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 D154AF1A481 for ; Thu, 22 Feb 2018 17:42:26 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CD296F272 for ; Thu, 22 Feb 2018 17:42:25 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.179.104.27]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MCtNr-1ewvVj134d-009l9n for ; Thu, 22 Feb 2018 18:42:24 +0100 Date: Thu, 22 Feb 2018 18:41:51 +0100 From: "O. Hartmann" To: current Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 Message-ID: <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_//c0+Tzflur4zE7G8dCJCk9e"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:MT5a0khBgE0G/B8q3BsrP1AoTJm7+CNoSmQ4NPDQGdFrYACLd9J F1KR3seC9X1nA626yALcwfdkOuK6DKKmLcT9SwO4vKD+e+n8k9AQwXz/jiOhuzlJODEaDLp hnNvO8dQGvhD13kQNxhFRctxNzQSndfbuJ0VizBbF+TJ5jAbleK3Fbk6eghrJlRDeN1ikpy AJ7wAD7EfL/EgDvKAj38g== X-UI-Out-Filterresults: notjunk:1;V01:K0:w1R2XCPPx50=:CZTZYnkJeWP331Pc/bjiQj 9T3MiPwmO6eUuVcmZaNIYmnYYKGzzM1nUQzuQlthKJISMX2HXlVNTdzLtWCwGATSugvPNoB3j e2SytGs8o+82ZVdqs2ZjXH3a89foiA9brKQROEXrlpU2koR3BZbdzKmvf/GtR89YCPP8eUIJt VuIuCRNuoZQJlOh3g552SjRi8sHwH7XfHjLDSLRDunXw2ldR6Jhm6POAuYGnHku0ZsI798cY4 Txwo3/BRee9IrArMnrnjkcT51SClAoQb0g8jhPQnjT6jRSsakuMbrjdKJA8a8+izeh3r6K5ky nYr3RO86K1nlwSTrXAE2ZvNH9tUbVDm3rKlxDSmO/p91UCpyDfJXY+j1aMx6IDHBbP3rAwshP MCqAupYkhThi/ThzvB1iZji1opjEARPz//NDiJ7k7BjzUP7kqhu0tBBqP6NNfiePAsNj4PDrG 9c85RCTLHf8X6RLGmh2pCt0CnLq188jLlZSUZWtGcRPx+KuQ7ui+TgQNQ+6RTeK4to7CFbfUU lpCBrQbOWRpD4NR4ShDIxRclMma/ts6oDLu/WTVJdNrzQoBfjd7t7PGc2vGSH2txJxb3wXxUS aFWxQlK4Tk+TEb37NZD7Bxnij/mSDoXcIyya23oU+zI0b3fHmaJhnq6xPgYBF5n455GW7GLPW 214etIkFiQndKE0B1QU8Wcq+RLyBI9JBCx1GhfCQLzeKLPvSjFMqbx1t/IAmaJgJ6JLNczmHZ IgHfhyGwVVXH5PId6RuOPh6EO2CFstKxRgNB9AjfdX/UdChQyRXBBaYFvH9TScl5utS0ctmqm H220q5iauNCjxPj2929c8mdeZioxKy9mGawHb7cROZ6qChisFA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:42:27 -0000 --Sig_//c0+Tzflur4zE7G8dCJCk9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 21 Feb 2018 20:05:24 +0100 "O. Hartmann" schrieb: > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 2= 3:06:15 CET > 2018 amd64) I'm honored by this nice bug when calling top: >=20 > top: sysctl(vfs.bufspace...) expected 8, got 4 >=20 >=20 > Regards, >=20 > oh I still can not use "top", it quits with the error mentioned above. Whats i= s wrong with my setup? --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_//c0+Tzflur4zE7G8dCJCk9e Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWo8A+gAKCRDS528fyFhY lGiyAf0ZiCYgPlSBOIdnf5ZveSgUfZClOkB+qw20mNCV0pkcOGHrXORgUZX14nKw 4B0cAmHNmsI9n6aKoh9wjann6+s0Af42iNn0qzMU8bzSrprP8DXbVcpnHpAoQ6wU wYwUQuAhhDFd58i8FgMKL77djzSGosFfQaQ/tNIRY06xzrox9Vlb =UnD2 -----END PGP SIGNATURE----- --Sig_//c0+Tzflur4zE7G8dCJCk9e-- From owner-freebsd-current@freebsd.org Thu Feb 22 17:52:27 2018 Return-Path: Delivered-To: freebsd-current@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 88D25F1B367 for ; Thu, 22 Feb 2018 17:52:27 +0000 (UTC) (envelope-from mjguzik@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 185D46FB2E for ; Thu, 22 Feb 2018 17:52:27 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id CB721F1B35D; Thu, 22 Feb 2018 17:52:26 +0000 (UTC) Delivered-To: current@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 A7905F1B357 for ; Thu, 22 Feb 2018 17:52:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A7DE6FB26 for ; Thu, 22 Feb 2018 17:52:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id s188so7523770qkb.2 for ; Thu, 22 Feb 2018 09:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VU+5s7gUqs5naxtpnNpn3xWwaXQjIPJv0SGfQd8osIc=; b=s7wyDzkeWDAbc6AVT7u9C2g1l5GL/lAQ4s9tdmKIK6cBckMpXJJvJu8u0RR+rzzha/ nVV3y9b28+QFk9GEUm/dIx+iEFOZW1/Qr4cPcql2SDbBNSscVP4AYmnx3FT8wPmINi1w JRNDvDHZ43YrBQK0RbgKBL26h5YkPz3XmEwLrN5xfOvZKnZEt+Khikx6HttxKxhRGEZ7 K41op3hWql5NU3/TpyGLUwYt7X5+61uRwo9Butd8jnhDdzW2M3r+rarhaULbxRy7q1ii jCGWVxzvTvDAd7zFWqYFQApzPpi6RuvaEHPeuq62h6M30QazMcjPv99TpfwGAV6EHeNg l/Aw== 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=VU+5s7gUqs5naxtpnNpn3xWwaXQjIPJv0SGfQd8osIc=; b=YitNIIMoeRjdLA+0mGgKNv++LhjFCh/Vac+iVLAHl3TmH9g0r8Jwrw8jnw5W1i5Vdr DRvIQbMEMQiru3NQ7Z2uA03Liak/uQgePKovTeMvtw/L+djj8sKYhr79lEJgef0FoRN7 1GP59HRrSn6JmR8/YVtZe/GziUaIb9Eq7Su/2X1ISwfR6IlE8rphKaFmvY635+8av59h MSgHzTRZYfZM3oJIbZBMfWrWiDbNNSJZCjQD50s22j/YGKudLn6L7Qfk/a2QkaWCHiEI ZRGkbyaIONxBgvm9q9P3wzzrHSXdM2JUKMVijqxtoqekK74m8Cre3o93eVnqb/9Uk3Nc cJYA== X-Gm-Message-State: APf1xPD/H2zWo1wiaknzYhSA4zmw6mnEUpnLSSGujtRYUdoSn1XxhNRF qg1OWQmj7gqvWgctdp+eJR9kDsnzeQKaOkm5Znqcog== X-Google-Smtp-Source: AG47ELvUg5mP0dNboakXVIEWS42V5UWnYncWKm5pX7lS8Ik5CHl/94vefLAo51DDpFAu7Uo+BRShhbTRcCYPADuDn+c= X-Received: by 10.55.22.144 with SMTP id 16mr11527405qkw.11.1519321945949; Thu, 22 Feb 2018 09:52:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.42 with HTTP; Thu, 22 Feb 2018 09:52:25 -0800 (PST) In-Reply-To: <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> From: Mateusz Guzik Date: Thu, 22 Feb 2018 18:52:25 +0100 Message-ID: Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 To: "O. Hartmann" Cc: current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:52:27 -0000 On Thu, Feb 22, 2018 at 6:41 PM, O. Hartmann wrote: > Am Wed, 21 Feb 2018 20:05:24 +0100 > "O. Hartmann" schrieb: > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 > 23:06:15 CET > > 2018 amd64) I'm honored by this nice bug when calling top: > > > > top: sysctl(vfs.bufspace...) expected 8, got 4 > > > > > > Regards, > > > > oh > > I still can not use "top", it quits with the error mentioned above. Whats > is wrong with > my setup? > > Looks like a fallout from r329612. Try this, untested: diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index a2a1736a24f4..7cb6aa15ddc5 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -423,7 +423,7 @@ sysctl_bufspace(SYSCTL_HANDLER_ARGS) lvalue = 0; for (i = 0; i < clean_domains; i++) lvalue += bdclean[i].bd_bufspace; - return (sysctl_handle_int(oidp, &lvalue, 0, req)); + return (sysctl_handle_long(oidp, &lvalue, 0, req)); } #endif From owner-freebsd-current@freebsd.org Thu Feb 22 17:53:52 2018 Return-Path: Delivered-To: freebsd-current@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 9E15BF1B534 for ; Thu, 22 Feb 2018 17:53:52 +0000 (UTC) (envelope-from ian@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 364186FCAB for ; Thu, 22 Feb 2018 17:53:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EB3BDF1B530; Thu, 22 Feb 2018 17:53:51 +0000 (UTC) Delivered-To: current@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 D779DF1B52E for ; Thu, 22 Feb 2018 17:53:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F2126FCA8 for ; Thu, 22 Feb 2018 17:53:51 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 55ab1f02-17f9-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 55ab1f02-17f9-11e8-91c6-33ffc249f3e8; Thu, 22 Feb 2018 17:53:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1MHrkDj064301; Thu, 22 Feb 2018 10:53:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1519322026.91697.135.camel@freebsd.org> Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 From: Ian Lepore To: "O. Hartmann" , current Date: Thu, 22 Feb 2018 10:53:46 -0700 In-Reply-To: <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:53:52 -0000 On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote: > Am Wed, 21 Feb 2018 20:05:24 +0100 > "O. Hartmann" schrieb: > > > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue > > Feb 20 23:06:15 CET > > 2018 amd64) I'm honored by this nice bug when calling top: > > > > top: sysctl(vfs.bufspace...) expected 8, got 4 > > > > > > Regards, > > > > oh > I still can not use "top", it quits with the error mentioned above. > Whats is wrong with > my setup? > It seems like the two big candidates must be mismatch between kernel and userland, or maybe 32/64-bit mismatch between the kernel and top. What's the output of   uname -pmUK   file `which top`   ldd `which top` -- Ian From owner-freebsd-current@freebsd.org Thu Feb 22 18:57:08 2018 Return-Path: Delivered-To: freebsd-current@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 945AAF214A2 for ; Thu, 22 Feb 2018 18:57:08 +0000 (UTC) (envelope-from ohartmann@walstatt.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 2770872748 for ; Thu, 22 Feb 2018 18:57:08 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id D24AAF2149E; Thu, 22 Feb 2018 18:57:07 +0000 (UTC) Delivered-To: current@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 ADA89F2149D for ; Thu, 22 Feb 2018 18:57:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F9B872742; Thu, 22 Feb 2018 18:57:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.48.251.95]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfF6I-1f8F2v2I0Y-00OkSZ; Thu, 22 Feb 2018 19:56:59 +0100 Date: Thu, 22 Feb 2018 19:56:26 +0100 From: "O. Hartmann" To: Ian Lepore Cc: "O. Hartmann" , current , Mateusz Guzik Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 Message-ID: <20180222195653.757840c3@thor.intern.walstatt.dynvpn.de> In-Reply-To: <1519322026.91697.135.camel@freebsd.org> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> <1519322026.91697.135.camel@freebsd.org> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/hVsXnv1fbz7hrH5ak8TnaBS"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:M60fEAVIYWqESl9ceVkZAVWk5GStP4w9NmK5VL9/RQc99bWfsLp 6Xu+1K4T1JFeQPslXWodhbLQ2TywGFLSUAxw1yYjld5bRowoJqBl+IAcFDEmmkydq4lCjes sXPxgVxsBltYurcA9ZAiE8mNT8bhcLEsXy65tEQdrtfOfLdX4xbUJdtGt2pAW8dc6r2ZYMx Nvp4J7Nc4Pf1qQJmk5AtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:s6IKFCOWwsQ=:BGyqdqmEDVzolXeuYJYtbq 0Tbxp0GeJCi1Qi3OgoVcmDBeTU8VW7wn8L34UV9I2O56oMC1htd6WAS75TbFQ9csvXSXbP7b5 MisVwegX13nlcvZkwTZqkY+63OhBIAX4lczGqpY+SpYU2pZQBYjQLBGlGZbI2I9PFsJu8NAfy O1SerP4dr8DiysOU15FUrcDK4k1ZpARlPm6mHdi5ZbG/OGUW997gjFQqNlGXEU+JrlnVAr8hS wTXeE5O8xkVNkpLZaYPja/2p4Qe0U3DGGsPlvByU7Ud8Untx4EASuJkGhemdqoj2K+aAv/val dY3JxRyv8io+oYzsc2qBR30Kgw8jZQz5wkpa9GSo3inguRjs5yzQU1fL/6TtGlTtFa65P62Y4 OOBQEkfHkajZt220WMEQQd+pVSErmzuFmcVJqBDNmyc0GoCT8r7BnqYv64wa67Z023T346Q6x tpfIUg4tRYm/z0Sd2e0vp8p/Zy4/deQIABE0Bg1gA6Hqa3H37MWsc5x6+DA6vzH6RfolYqjIi ypZAzZdXEAG/yUCx5arQIFM9ITAHP25LQ3/1xxb6g4dC+2WMl9VxI4aSCAYwuottNGcUpM1eQ HFrWlXQ9R2c6DYvyPd8Jc+VLziRERiMSLMni2IpWoQhO74M2T8xfAbYYdVaLNNGMY+NqKiG0p slLqglPUcS4buEQjVd2CXZIBd5es5y7cvdA4kY0Ofhux9DFSbIV9SJXBgQcEe9ANfh+nc/JcB OeDmsgLUXyEoIcufFOsguCkGQ84n9aEeWpPt+dpAZJc5+OShWWwallCoVbXeWWWWXeKfcSbva 1SyHjbH57SrXPnH9++QOBHOAAbwCMbIy9/tdAulAfX/Yw71omEswgZkXsrP9irvSj2I54DAqu 3pYTpgg+zE+g6HfrZr3+zR9DouCqdz+hfxVHEm5ss= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 18:57:08 -0000 --Sig_/hVsXnv1fbz7hrH5ak8TnaBS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am Thu, 22 Feb 2018 10:53:46 -0700 Ian Lepore schrieb: > On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote: > > Am Wed, 21 Feb 2018 20:05:24 +0100 > > "O. Hartmann" schrieb: > > =20 > > >=20 > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue > > > Feb 20 23:06:15 CET > > > 2018 amd64) I'm honored by this nice bug when calling top: > > >=20 > > > top: sysctl(vfs.bufspace...) expected 8, got 4 > > >=20 > > >=20 > > > Regards, > > >=20 > > > oh =20 > > I still can not use "top", it quits with the error mentioned above. > > Whats is wrong with > > my setup? > > =20 >=20 > It seems like the two big candidates must be mismatch between kernel > and userland, or maybe 32/64-bit mismatch between the kernel and top. >=20 > What's the output of >=20 > =A0 uname -pmUK amd64 amd64 1200058 1200058 > =A0 file `which top` /usr/bin/top: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynam= ically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200058), FreeBSD-style= , stripped > =A0 ldd `which top` /usr/bin/top: libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x800258000) libm.so.5 =3D> /lib/libm.so.5 (0x8002bd000) libkvm.so.7 =3D> /lib/libkvm.so.7 (0x8002ed000) libjail.so.1 =3D> /lib/libjail.so.1 (0x800300000) libc.so.7 =3D> /lib/libc.so.7 (0x800309000) libelf.so.2 =3D> /lib/libelf.so.2 (0x800712000) >=20 > -- Ian >=20 ... so ... @ Mateusz Guzik: I missed your patch - didn't apply clean, was rejected and= I accidentally build a "usual" kernel. Will try again.=20 At revision 329831, the target line in question is at line 414, not 423 as = of your patch (old source?). --=20 O. Hartmann Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs. 4 BDS= G). --Sig_/hVsXnv1fbz7hrH5ak8TnaBS Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWo8SdQAKCRDS528fyFhY lGKYAgCTX5X+6qNQykHhZ2+zAWJiLVSiXjxIcoIkQXBxLJADx90jHbtupVii0YOs Uy3uDWKM9D3MiOE3GEuWE+Ux5FF+AgCFCVkoczgkV7MLnx0hvNvv3n3vTeX0GE7f Kwp8nIrs5WzV0rtVSQGN2+SYqXFao3XWufyFByKy6UhN7v6wOpYv =Awau -----END PGP SIGNATURE----- --Sig_/hVsXnv1fbz7hrH5ak8TnaBS-- From owner-freebsd-current@freebsd.org Thu Feb 22 19:34:52 2018 Return-Path: Delivered-To: freebsd-current@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 15DCCF24401 for ; Thu, 22 Feb 2018 19:34:51 +0000 (UTC) (envelope-from ohartmann@walstatt.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 81A587434A for ; Thu, 22 Feb 2018 19:34:51 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3F679F243EE; Thu, 22 Feb 2018 19:34:51 +0000 (UTC) Delivered-To: current@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 1A307F243EC for ; Thu, 22 Feb 2018 19:34:51 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 850E974345; Thu, 22 Feb 2018 19:34:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.48.251.95]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MU0U9-1fFAbZ1nVZ-00QlU8; Thu, 22 Feb 2018 20:34:48 +0100 Date: Thu, 22 Feb 2018 20:34:14 +0100 From: "O. Hartmann" To: "O. Hartmann" Cc: Ian Lepore , current , Mateusz Guzik Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 Message-ID: <20180222203441.482d03bf@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180222195653.757840c3@thor.intern.walstatt.dynvpn.de> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> <1519322026.91697.135.camel@freebsd.org> <20180222195653.757840c3@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/zKsg69IyaurjumUQG1f1Itk"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Jff2tCX1sdcmyEMve8Xbef7WWOCaB2aNMfA2WUqWkc2MRQ+1x0+ 4CgulUAh/Cb/l9nHYVKvi+sAMfNm+hKqPAwMre89hWdUQ8TDuvJ0pVokTEF5s3DP12BDF5t jAzFfZV5VLhZ+xJTX2ziJj6N7xMcJ0yMRnVQTG51gLdhVjuEBvp77QvEUlJ65YyhaqLqvAq UwZBb4YmtAwpW3QpV8TAg== X-UI-Out-Filterresults: notjunk:1;V01:K0:6hoEIyqKI3g=:oGuLx5mvwGzDKCs3jjJa53 WbjOa3u9+acj5yqZ0OEjv+RG8d7HJv3vZPsARR8MBypeDMAXe0gzMoURccSj/HftaIR8nZUQ+ IOH9cIork0RgpRELG1FrNrF04QbSJU6yRWRi1xCmRdY4x4dUqXWNz0dEqga4kr28I5LNFJ3x0 tCLbzHYiwoR2Y0WI/zAqwhYdVBKyjPfKCbT3RbaWzOKwfhBdYbIb83qdGfTFLgRFteYCgOery EIznovyN6EJT15qY14QJlkTMZIoiVxj96af8nemX18k/B5T7nqCkTZJmRgdms6ANZDBSs6PnC GxznRC2v81ROf9MZfX6+GUtgBL3x5y1OX3MrDVgPI897/osICryy9MB0yBjp1qezxxPmrOsfz PsbAYr4JghTOkrvGDdeqwm61nnZyJXpSEUhOFxtjnVt6pXoURrxHes3d8XKAhqFTdYvHdJZXk 7aDmk9rXTo4XJxIkR0z3dpkg+MOr5emQN/t3dx/S6IHh4lMTmgANMmhXgsiAAg8ohxZFyVwdX 30oJG2UQN6X1uZ3brM5zloOhlri6MAmSl/j3oiOlFteobjdn8wc8sJAx583bzbQsIrz8RXIRf beS1fQ3zwoxxL2n6rH53CGtUBSSOQK0DDN5FmMVcnu/JiSKnlgRk42Na9u5GCVSCrfxV1Nigr YDFdSeME4AjEUfIT53VXVD0R+0C7ofoQ1CAMlk/cuJiUge6k3xLXCcIVbH+SRhHikHuMC3tuM s8CGZ1UDC/TF3n+uVAlFDn5JhYQpKMXfNECvo7xSKZ5ZhVenFDAd8baKZGtzbcbZtr8g9uy/f yDp6TZUKnrQwfIsbVaY4rsMzXSxei9mUtLlvCYqG9E5Hi63Yj677Jqhbfs99P8YRE3N251Dtj /ZXg4aP536T5EgMQOO+McfFGMngENCA9GFdDfzmHE= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 19:34:52 -0000 --Sig_/zKsg69IyaurjumUQG1f1Itk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am Thu, 22 Feb 2018 19:56:26 +0100 "O. Hartmann" schrieb: > Am Thu, 22 Feb 2018 10:53:46 -0700 > Ian Lepore schrieb: >=20 > > On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote: =20 > > > Am Wed, 21 Feb 2018 20:05:24 +0100 > > > "O. Hartmann" schrieb: > > > =20 > > > >=20 > > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue > > > > Feb 20 23:06:15 CET > > > > 2018 amd64) I'm honored by this nice bug when calling top: > > > >=20 > > > > top: sysctl(vfs.bufspace...) expected 8, got 4 > > > >=20 > > > >=20 > > > > Regards, > > > >=20 > > > > oh =20 > > > I still can not use "top", it quits with the error mentioned above. > > > Whats is wrong with > > > my setup? > > > =20 > >=20 > > It seems like the two big candidates must be mismatch between kernel > > and userland, or maybe 32/64-bit mismatch between the kernel and top. > >=20 > > What's the output of > >=20 > > =A0 uname -pmUK =20 > amd64 amd64 1200058 1200058 >=20 > > =A0 file `which top` =20 > /usr/bin/top: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dyn= amically > linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200058), Fre= eBSD-style, > stripped > > =A0 ldd `which top` =20 > /usr/bin/top: > libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x800258000) > libm.so.5 =3D> /lib/libm.so.5 (0x8002bd000) > libkvm.so.7 =3D> /lib/libkvm.so.7 (0x8002ed000) > libjail.so.1 =3D> /lib/libjail.so.1 (0x800300000) > libc.so.7 =3D> /lib/libc.so.7 (0x800309000) > libelf.so.2 =3D> /lib/libelf.so.2 (0x800712000) > >=20 > > -- Ian > > =20 >=20 > ... so ... >=20 > @ Mateusz Guzik: I missed your patch - didn't apply clean, was rejected a= nd I > accidentally build a "usual" kernel. Will try again.=20 >=20 > At revision 329831, the target line in question is at line 414, not 423 a= s of your patch > (old source?). >=20 Stupid me ...=20 The patch, Mateusz provided, worked! My sight is some kinf of "bend", so I = missed the correct line. Mateusz provided me with this patch, which solved the issue: Index: sys/kern/vfs_bio.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_bio.c (revision 329832) +++ sys/kern/vfs_bio.c (working copy) @@ -423,7 +423,7 @@ lvalue =3D 0; for (i =3D 0; i < clean_domains; i++) lvalue +=3D bdclean[i].bd_bufspace; - return (sysctl_handle_int(oidp, &lvalue, 0, req)); + return (sysctl_handle_long(oidp, &lvalue, 0, req)); } #endif --=20 O. Hartmann Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs. 4 BDS= G). --Sig_/zKsg69IyaurjumUQG1f1Itk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWo8bUQAKCRDS528fyFhY lH15AgCQjQuy5DgmydnOffzz35Mm5J/iC5lMSx9WCmya1MRhOiuIy9KWgaIP/R6a s63C+u3MQjD16E6+5jbNYYZDpzOrAgCBsRCEJ2fI9eVusfCCV1Ip4ei8o38pFPrI YG8vpye9VuU5+9ooJ1Pg1fIOvVdGo70gUwdQONxNMYcPkR3AOdBH =ePQx -----END PGP SIGNATURE----- --Sig_/zKsg69IyaurjumUQG1f1Itk-- From owner-freebsd-current@freebsd.org Thu Feb 22 20:41:03 2018 Return-Path: Delivered-To: freebsd-current@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 A192DF291E0 for ; Thu, 22 Feb 2018 20:41:03 +0000 (UTC) (envelope-from mjguzik@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 2F6507851E for ; Thu, 22 Feb 2018 20:41:03 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DAF0CF291D8; Thu, 22 Feb 2018 20:41:02 +0000 (UTC) Delivered-To: current@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 B3C52F291D7 for ; Thu, 22 Feb 2018 20:41:02 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4416078518; Thu, 22 Feb 2018 20:41:02 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id f4so8013162qtj.6; Thu, 22 Feb 2018 12:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b3nWROyVQbx5v7FZ2/Z+/Ags1rcOepujMdkGtjaUkJY=; b=fJOwmaUjltsV3bkVnJEMpBTu0NBvX8pAnEmLzGaB3+C8r9T4KH1MzybGBqjcQBf2ni 8tRw3BLp+7oDIZHhIQMTNC/N9CJJmfw6gVxl++JcW1VistKTJr3EBx8vG3bxZmO1hjYk eXhHaEKG8F4Qap/F0zpLP/s9lXuFksOufCycvuPHhHP7ySQl8Nb38gogQU/Ppkj7FhcX 4kUYGjLVCv6bOQJQG0ndmW3tq9Wgr8D2r+s1qi/CYwxN0bbDQ5v6bjFAD2gfS6FzPRuY 3uoN7FaPjXEDgPNIe02W1j41ZdjZiU6kb+pDWg01NGNoi4sE6TK5ChvW1OYAkkA5as0P Udww== 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=b3nWROyVQbx5v7FZ2/Z+/Ags1rcOepujMdkGtjaUkJY=; b=Pi9CLwEC7w/8/qeggYFFdDwBqJN9+Fgu8Y61AetWGSrM357f4w66hfSglQ8IU2DW5D DnycNkkEj9m4cOVUzhlMsjAjirZ2sUHOS3jZa/BSPJQSlLTc9ZHIZbbcWIyGdFLhkqfL FAWO0MuXP7QTgarYLeJky4ta5gr5uuakV6a3v0NYS6l8+BpsN3r2V+6KD7iTo5KxGfoA kHmmmCsSAe21AIDLaOPoY+Ae52N9RIw4mvIIEg16mjMvJsS+ok2RzkVzSKsP773UAfl8 Bi7Gl/IDmHjFxPqsBaxhlAH86Sgy4xnsICbPNyQfGCvAYU238PKL/xmWgjE5q6OmNvCU B/1A== X-Gm-Message-State: APf1xPDuOoE2KNDDoXVXo/0SYyvbzecbfnARmjsmbdc/UmyJ6540Ehxs aXKOEpI7E4Rt0xgCGhjgx2yeAzUb6ZhOddMazkNrzg== X-Google-Smtp-Source: AH8x227hyFO7y/7u8T6rtVPY65mZWyN8Gbihtlh1XV0/dVP3A6p0y73mbBEy7cYxagrbp49INK4m9W4dsfZPPfEnnuY= X-Received: by 10.200.64.91 with SMTP id j27mr13355199qtl.29.1519332061966; Thu, 22 Feb 2018 12:41:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.42 with HTTP; Thu, 22 Feb 2018 12:41:01 -0800 (PST) In-Reply-To: <20180222203441.482d03bf@thor.intern.walstatt.dynvpn.de> References: <201802211818.w1LII7fh087166@pdx.rh.CN85.dnsmgr.net> <20180221200551.718ab72f@thor.intern.walstatt.dynvpn.de> <20180222184218.2da3db1a@thor.intern.walstatt.dynvpn.de> <1519322026.91697.135.camel@freebsd.org> <20180222195653.757840c3@thor.intern.walstatt.dynvpn.de> <20180222203441.482d03bf@thor.intern.walstatt.dynvpn.de> From: Mateusz Guzik Date: Thu, 22 Feb 2018 21:41:01 +0100 Message-ID: Subject: Re: top: sysctl(vfs.bufspace...) expected 8, got 4 To: "O. Hartmann" Cc: Ian Lepore , current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 20:41:03 -0000 On Thu, Feb 22, 2018 at 8:34 PM, O. Hartmann wrote: > Mateusz provided me with this patch, which solved the issue: > > Index: sys/kern/vfs_bio.c > =================================================================== > --- sys/kern/vfs_bio.c (revision 329832) > +++ sys/kern/vfs_bio.c (working copy) > @@ -423,7 +423,7 @@ > lvalue = 0; > for (i = 0; i < clean_domains; i++) > lvalue += bdclean[i].bd_bufspace; > - return (sysctl_handle_int(oidp, &lvalue, 0, req)); > + return (sysctl_handle_long(oidp, &lvalue, 0, req)); > } > #endif Thanks for testing, committed in r329837. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Fri Feb 23 06:25:42 2018 Return-Path: Delivered-To: freebsd-current@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 3D456F2BBB7; Fri, 23 Feb 2018 06:25:42 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (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 C17D26F03D; Fri, 23 Feb 2018 06:25:41 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=H2+AtR4VK++cHgUWFYfdspGMHm7uZv8umWeyNa9eYp0=; b=e18F7tJUjZzb6WrWWlK6XBNmLZ dWx/7QZ7oAo8Uqqb6SvlN90umTf3pemhomvbLcDrA1WtzbQwfbP+5KSqndFvUPJRzuGbrwhTibgRy aJ5l5z+g7m5Xb/ncVDCeSgNAmR9wVoG57sTuGq1vHu22PvKd7bD3a0c8x5FFzBBUvWzYsFGAd8pbV 5Z54/enBtlXFMQyXSSK1F+Vt7fjanAhX4h6mrgxlYMZdRUYY1A8Ixf3gC2N9i697TMfuTpwqYfPt0 Nwrx8xT02Cb2EDDirBWWg3NQLzI6fYiBa3413QUkV+OaUTMh85TyUyV798iGGcyxfrG5Zz8RbJKWx r0sj+U0A==; Received: from [136.62.171.86] (port=49322 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ep6nU-002XDe-GL; Fri, 23 Feb 2018 01:25:32 -0500 From: Jon Brawn Content-Type: multipart/signed; boundary="Apple-Mail=_F740E14E-91B5-4C5A-B650-BEEC7F00D477"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: INTRNG Message-Id: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> Date: Fri, 23 Feb 2018 00:25:30 -0600 To: freebsd-arm@freebsd.org, FreeBSD current X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 06:25:42 -0000 --Apple-Mail=_F740E14E-91B5-4C5A-B650-BEEC7F00D477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Wotcha Gang! In my travels through the arm64 GENERIC config file I came across the = option =E2=80=98INTRNG=E2=80=99, and wondered what it was: INTeRrupt Next Generation? INTeger Random Number Generator? IN TRaiNinG? INTerrupt Random Number Generator? INdependent TRaiNinG? So, please put me out of my misery, what does INTRNG stand for, and what = are its implications when selected vs not selected? Cheers! Jon.=20= --Apple-Mail=_F740E14E-91B5-4C5A-B650-BEEC7F00D477 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAy MjMwNjI1MzBaMCMGCSqGSIb3DQEJBDEWBBQM//0owUKDzjGQFQqkx3VNitdeIDCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBABAapjTG hXrBNLlH973rZG84yEHcJcoJ97lkwihLaWirHjE2c+vkpNowp6yzxAhptH3C5I8YNxdFpjkzSudI F2s/q5Ne8nfN4OksilXvsQnWxdpuB3A9H3IFmQuEOZC6lDmxZXpOKn1KqUNSroTDrBjP9WUFJW33 2zfLZqcdfA30jbdjvV9U/DuaGWpvwX74WYUHXEijaAvAazf2Qvjj4wBkD/qy7UTu/YcYHoiYQqWV xq29WvYYrk5qON+qcyxjL7oPDrGzl+n+usdS7Et5XiuUtRp2viT4slnT5nxdjkA8P3phMZr3THc6 Jf+TRWXAdGe7PPPFj8n2/+2lmucc27IAAAAAAAA= --Apple-Mail=_F740E14E-91B5-4C5A-B650-BEEC7F00D477-- From owner-freebsd-current@freebsd.org Fri Feb 23 09:07:55 2018 Return-Path: Delivered-To: freebsd-current@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 5E7ACF0AE28; Fri, 23 Feb 2018 09:07:55 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 E2CB9748A1; Fri, 23 Feb 2018 09:07:54 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3znlXG63k1zZrQ; Fri, 23 Feb 2018 09:59:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=mail; t=1519376355; x=1521190756; bh=tp7U4X+TbZjVU7 bct9cU9CenUWkhdp8jpnUo5s02XlE=; b=sU/2cq9jYaRZHesOpYyrlhgrR6yjqq ZcLLXyhRgdHpkicJCSZIU8auSfb0PQj+5Jdx5b5uB4x1M0tEIL/ME3Sl1dT9D+9i uG5nWg4iGQDpQgYApyvXT+OPcyPXtRv0IZkPDHWVOf1yp+r1QfbY/uWpDUVlx/ps h+bnLz2CuslAU= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id 0fO2cC9MW-s0; Fri, 23 Feb 2018 09:59:15 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 23 Feb 2018 09:59:15 +0100 (CET) Subject: Re: INTRNG To: Jon Brawn , freebsd-arm@freebsd.org, FreeBSD current References: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> From: Guido Falsi Message-ID: <177301ca-b1aa-da15-4554-32a4bed9b226@madpilot.net> Date: Fri, 23 Feb 2018 09:59:14 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 09:07:55 -0000 On 02/23/18 07:25, Jon Brawn wrote: > Wotcha Gang! > > In my travels through the arm64 GENERIC config file I came across the option ‘INTRNG’, and wondered what it was: > > INTeRrupt Next Generation? > INTeger Random Number Generator? > IN TRaiNinG? > INTerrupt Random Number Generator? > INdependent TRaiNinG? > > So, please put me out of my misery, what does INTRNG stand for, and what are its implications when selected vs not selected? > A quick grep in src/sys gave me this: MALLOC_DEFINE(M_INTRNG, "intr", "intr interrupt handling"); Also: arm/arm/machdep.c:#if __ARM_ARCH >= 6 && !defined(INTRNG) arm/arm/machdep.c:#error armv6 requires INTRNG So it's about interrupts and mandatory for arm processors, I suspect it's and arm (and mips too, since I found grep hits there too) specific interrupts handling method. this looks like the original RFC for this code: https://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007915.html -- Guido Falsi From owner-freebsd-current@freebsd.org Fri Feb 23 09:25:54 2018 Return-Path: Delivered-To: freebsd-current@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 9F826F0D79D for ; Fri, 23 Feb 2018 09:25:54 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 CF555753EA for ; Fri, 23 Feb 2018 09:25:52 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [202.216.24.27]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id w1N97KDn032090; Fri, 23 Feb 2018 18:07:21 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201802230907.w1N97KDn032090@kx.openedu.org> Date: Fri, 23 Feb 2018 18:07:20 +0900 From: KIRIYAMA Kazuhiko To: FreeBSD current Cc: kiri@kx.openedu.org Subject: Intel SST Audio Device(WDM) User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 09:25:54 -0000 Hi, all I'm searching Intel SST Audio Device(WDM) for FreeBSD which seems not yet implemented. In Linux/Debien, the non-free firmware firmware-intel-sound[1] may be supported. How does it work in FreeBSD ? Best regards [1] https://unix.stackexchange.com/questions/307623/system-mute-of-fresh-install-debian-cant-find-the-audio-devices --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Fri Feb 23 06:57:38 2018 Return-Path: Delivered-To: freebsd-current@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 3A660F010C4 for ; Fri, 23 Feb 2018 06:57:38 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 B49ED6FF52 for ; Fri, 23 Feb 2018 06:57:37 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id w1N6vcMC007878; Thu, 22 Feb 2018 22:57:38 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201802230657.w1N6vcMC007878@chez.mckusick.com> From: Kirk McKusick To: bsd-lists@BSDforge.com Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d cc: "FreeBSD Current" X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to "Chris H" message dated "Mon, 19 Feb 2018 14:18:15 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7876.1519369058.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Feb 2018 22:57:38 -0800 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Mailman-Approved-At: Fri, 23 Feb 2018 11:21:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 06:57:38 -0000 > From: "Chris H" > Reply-To: bsd-lists@BSDforge.com > To: "FreeBSD Current" > Subject: kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d > Date: Mon, 19 Feb 2018 14:18:15 -0800 > = > I'm seeing a number of messages like the following: > kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d > = > and was wondering if it's anything to be concerned with, or whether > fsck(8) is fixing them. > This began to happen when the power went out on a new install: > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 P= ST 2017 > root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > which hadn't yet been hooked up to the UPS. > I performed an fsck in single user mode upon power-up. Which ended with = the > mount points being masked CLEAN. I was asked if I wanted to use the JOUR= NAL. > I answered Y. > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thus= ly: > newfs -U -j > = > Thank you for all your time, and consideration. > = > --Chris This problem should have been fixed with this commit: r328914 | mckusick | 2018-02-05 16:19:46 -0800 (Mon, 05 Feb 2018) You need to update your kernel to get the fix. Kirk McKusick From owner-freebsd-current@freebsd.org Fri Feb 23 17:18:43 2018 Return-Path: Delivered-To: freebsd-current@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 3F9C4F092FE for ; Fri, 23 Feb 2018 17:18:43 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B11CC6B8FA for ; Fri, 23 Feb 2018 17:18:42 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w1NHIlLG051226; Fri, 23 Feb 2018 09:18:53 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: <201802230657.w1N6vcMC007878@chez.mckusick.com> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Kirk McKusick" Subject: Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d Date: Fri, 23 Feb 2018 09:18:53 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:18:43 -0000 On Thu, 22 Feb 2018 22:57:38 -0800 "Kirk McKusick" = said > > From: "Chris H" > > Reply-To: bsd-lists@BSDforge=2Ecom > > To: "FreeBSD Current" > > Subject: kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d > > Date: Mon, 19 Feb 2018 14:18:15 -0800 > >=20 > > I'm seeing a number of messages like the following: > > kernel: failed: cg 5, cgp: 0xd11ecd0d !=3D bp: 0x63d3ff1d > >=20 > > and was wondering if it's anything to be concerned with, or whether > > fsck(8) is fixing them=2E > > This began to happen when the power went out on a new install: > > FreeBSD dns0 12=2E0-CURRENT FreeBSD 12=2E0-CURRENT #0: Wed Dec 13 06:07:59 = PST > > 2017 > > root@dns0:/usr/obj/usr/src/amd64=2Eamd64/sys/DNS0 amd64 > > which hadn't yet been hooked up to the UPS=2E > > I performed an fsck in single user mode upon power-up=2E Which ended with= the > > mount points being masked CLEAN=2E I was asked if I wanted to use the JOU= RNAL=2E > > I answered Y=2E > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thu= sly: > > newfs -U -j > >=20 > > Thank you for all your time, and consideration=2E > >=20 > > --Chris >=20 > This problem should have been fixed with this commit: >=20 > r328914 | mckusick | 2018-02-05 16:19:46 -0800 (Mon, 05 Feb 2018) Good news=2E Thank you very much, Kirk! --Chris >=20 > You need to update your kernel to get the fix=2E >=20 > =09Kirk McKusick > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Sat Feb 24 04:47:06 2018 Return-Path: Delivered-To: freebsd-current@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 33463F1399C; Sat, 24 Feb 2018 04:47:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 C813B6D53F; Sat, 24 Feb 2018 04:47:05 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1epRjg-0000Mw-QH; Fri, 23 Feb 2018 20:47:02 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w1O4kxXZ001420; Fri, 23 Feb 2018 20:46:59 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 23 Feb 2018 20:46:58 -0800 From: Oleksandr Tymoshenko To: Jon Brawn Cc: freebsd-arm@freebsd.org, FreeBSD current Subject: Re: INTRNG Message-ID: <20180224044658.GA1384@bluezbox.com> References: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Jon Brawn (jon@brawn.org) wrote: > Wotcha Gang! > > In my travels through the arm64 GENERIC config file I came across the option ‘INTRNG’, and wondered what it was: > > INTeRrupt Next Generation? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 04:47:06 -0000 Jon Brawn (jon@brawn.org) wrote: > Wotcha Gang! > > In my travels through the arm64 GENERIC config file I came across the option ‘INTRNG’, and wondered what it was: > > INTeRrupt Next Generation? > INTeger Random Number Generator? > IN TRaiNinG? > INTerrupt Random Number Generator? > INdependent TRaiNinG? > > So, please put me out of my misery, what does INTRNG stand for, and what are its implications when selected vs not selected? "INTeRrupt Next Generation". It's a framework to manage complex interrupt routing cases. I think it's required for all recent ARM platforms, you can't disable it for ARM64. It can be disabled for older ARM/MIPS platforms that use old-style interrupt cascading. -- gonzo From owner-freebsd-current@freebsd.org Sat Feb 24 14:38:49 2018 Return-Path: Delivered-To: freebsd-current@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 6F601F23C13 for ; Sat, 24 Feb 2018 14:38:49 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 1C15C864F2 for ; Sat, 24 Feb 2018 14:38:48 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6E9732123D for ; Sat, 24 Feb 2018 09:38:48 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Sat, 24 Feb 2018 09:38:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OfQwyDVZBIB84MhRDSosLHOekalZS ni5KoWszAVRVDg=; b=FeRqOfIpDlTFAgJQMlM8/FS2o0VyNHU02/GSUusCUXx7g HwG0TGhOhgy1a3frtR+vSxulqE1Ip/JhPvYhGfs0bkDsTvFHH+wMN5BXIexwJhkW IC8GCi/Ipj5GxOYZ+9dfbAZzYuGF3ZiaTnEwSRtDxu9A3LfGx9PFKJgeiJ4xYyqA 58Hm3bfZbPm5q/W07zQ4pd04DLiOke2u9/kmsFmar00SJlSqGtc06Jx9Zt5d4oda gbKDbwLCUucerhcBSttO9EYv0xDeTTC4ryyumyw0kWiV+Yt1biSbLiiqR7iHGr1q tlQd7sfHat+HZTMJ7tUCe2TJ+VE+RhC6fyUYzp3Iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OfQwyD VZBIB84MhRDSosLHOekalZSni5KoWszAVRVDg=; b=ajsLgf9b4YIgxE1Lt5Righ 7squBISt5Gd34mJ4st9Nh+v+yWRTnL5wrDjwjxHLrAoCvFox1qdapleTR1CcnCxM b/eze3SZOpyVLjjT7qkO5xDr6YoC0n5kc0a6+s8qjSMiU6iJg2z+aUmuD7L4ri0T 1Sbgsse7vGWALErAnTIvUzIIFM2h+RWcfiRYECdORhTx6ECKRCs+TmxEu6ni7JPg SlwB2CMJ27NTAv/GE9yRaXwtUmL1ZyQI97f6QWiG4lgBkkf5TLEK7nXJ+HUewGdH anl0m6zqQVsU1tCG4BsPEJ7ZOLmhXzdN0Ik4dAM1EshPpp3L7TzDNu8lU/TJ3kyw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 413214230; Sat, 24 Feb 2018 09:38:48 -0500 (EST) Message-Id: <1519483128.3534220.1281952752.51A3BEEF@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 In-Reply-To: <20180222134131.GA45189@v007.zyxst.net> References: <1519297066.646719.1279504848.0851DCB5@webmail.messagingengine.com> <20180222134131.GA45189@v007.zyxst.net> Subject: Re: make installworld broke / how to recover Date: Sat, 24 Feb 2018 15:38:48 +0100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 14:38:49 -0000 On Thu, 22 Feb 2018, at 14:41, tech-lists wrote: > On Thu, Feb 22, 2018 at 03:10:17AM -0800, Jack L. wrote: > >maybe try a clean buildworld, update /usr/src to the latest version, rm -rf > >/usr/obj, then make buildworld && make installworld && make kernel and see > >if that fixes the issue? > > Is there a documented way of say booting to memstick, starting fixit, > mounting the zfs from the broken system then building/installing a > new world? Is there enough "environment" and utilities to do this on the > fixit disk? I can't help from the source/installworld side, but I have a couple of things to share that may help, apologies if this is already familiar to you. The email's long enough to be a blog entry... 1. fixing a dead/borked system I love using mfsbsd[1] by Martin Matuska for this. It's a bootable FreeBSD image with DHCP support so you can ssh into it from a separate system. You can then import the zpool and basically do all the cleanup from there. zpool import -R /mnt -N -f zroot then mount the datasets you need manually. 2. hacking a semblance of sanity back into the borked current Try this, after doing a zfs snapshot of your filesystem. - download the latest CURRENT snapshot and untar kernel + base in place over top of the above mounted rootfs. Copy back anything "important" from your snapshot like /etc/ and /boot/loader.conf and the system will probably boot now. 3. use boot environments I use these all the time, so awesome. basically when you install 11.x the zfs dataset layout already supports this by default. You can tweak an existing system to fit this if needed, it's not too hard. Details elided, help available if you need it later on. install sysutils/beadm-devel and have a go. Briefly, your / is kept in zroot/ROOT/ (called a Boot Environment) and variable data lives outside that namespace, but overlaid using zfs mountpoints. You can make multiple copies of these as you go along, before upgrades, during patches, or major config changes. Real Data like /usr/home, /var/log or (in my case) /var/db/* are in separate datasets and will always be present and up to date, irrespective of which boot environment you are currently running under. For example, I have a 11.1R boot environment, and about 3-4 12.0-CURRENT ones over the last few weeks, in case something unexpected breaks for me. At boot time, the loader (thanks Allan Jude IIRC for implementing this) allows you to choose between those copies so you can simply switch back to the working one and decide what you want to do with the borked one. see [2] for some really cool tricks from Michael Dexter about mounting that into bhyve and then "live testing" before upgrading. 4. beinstall.sh script from Will Andrews If you're building from source, then you can combine #3 with [3] and have your next incarnation automatically installed not into your existing working / dataset but into its own dataset, cloned off your current /, and upgraded, all within the boot environment. This is so awesome it's changed my world (pun intended), I install a new CURRENT every 3-4 days now because rolling back is absolutely painless. I borrowed xmj@ [4] tips on using ccache and metamode, which makes incremental builds pretty quick. I can later on mount the /usr/src and /usr/obj over NFS to other lesser powered systems like my laptop, and beinstall.sh there too. LIKE A BOSS. Here's my current hacky scripts to build world & current, and stash everything into a boot environment. It works for me, but I'm hardly a build-from-source guru so maybe that could be improved [5] [1]: http://mfsbsd.vx.sk/ [2]: http://www.callfortesting.org/bhyve-boot-environments/ [3]: https://svnweb.freebsd.org/base/head/tools/build/beinstall.sh?view=markup [4]: https://xmj.github.io/articles/sysadmin/builds_ccache_memcached.html [5]: https://gist.github.com/dch/99a0e3c42e971a08dd922aab20670d7d From owner-freebsd-current@freebsd.org Sat Feb 24 18:41:16 2018 Return-Path: Delivered-To: freebsd-current@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 2B062F023C4 for ; Sat, 24 Feb 2018 18:41:16 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 B35E270D3A for ; Sat, 24 Feb 2018 18:41:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id m13so9692947qtg.13 for ; Sat, 24 Feb 2018 10:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bh+dXEnj+sCZpAT2ZlXOUIH6AHwYmreKnF3//o8T114=; b=i5rB/hCjcpPf3SVAbaiOeQvmgMDw3Q6lfx2XFIhFy9O8vKSRCAMTJxgWmNwmBpzdbc jwGb0+H0/jya2/xB4T521wBYAgqUwk9R1Uysh/pX+80ZIBT9FjpoNURTEZ3Z8wqx5oKi 21yi6l2tXbz3SdpG92YFWSlKwcbgyx4tZSY4eN/yjVgJXqAPZZ3tDTUmg3Rd6IqRSCP7 6rPscpWuQo9Vxb2VuLrwO2UTSU6syK5fPfgpLd/nnXpaC0byMUqEx49Lpme057Yh4z8J lBWGaf2kBEE1KdQyulJHuYm5sj3nHJZYgJTlehcpdo8Bmjdim01ZqUJzzuH0s32yv5pC u9dw== 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=Bh+dXEnj+sCZpAT2ZlXOUIH6AHwYmreKnF3//o8T114=; b=YTMp2GEZaxman/pFiPXsNS+zrEKSItKTzwl3sE85Zfc21IiEqYnpwh0UZPYiI4LBay BirVy62YgDXrAGrDbrcPS9Uexl0rlRWGVX2/ZzfB/sApr30BbSqkf3gC7Udy+BsDw1DQ SQ8wNBwnmQsJFYNkWg23vDMIgsqMTj6XXsBpfp7j2lZEE95hSvslcJuFFm4HnRu2Xb30 dJXTIzWUwvJQVOI8WkF/EbDmw536WQ3rMWSn00nZwvOWIw1WpPw/EuuRv60/DMuoInGa jOT9E2NQCQlx9RArZjpeoyY5bCsYjUDsmQS4dVzwlQmu6OSzB9rPZ3fnem2uu5HE/+WM +Lmg== X-Gm-Message-State: APf1xPB9Gt6K45eNo1JN+joIKfnyRfPICwxhqpztxy6zXqbe0YPJbQra 6qNPjq8sJujx93LbMYnlCgrDU5H8j/khYG2CwrGE4w== X-Google-Smtp-Source: AG47ELsiuhsSbFaTLxZeJcLwXvILAdYxEnBef8hhno1u4IqYtV4kOHNxWink5XocN02dzV7Jyr/v6B030GZ9M/f664k= X-Received: by 10.237.58.7 with SMTP id n7mr9259081qte.194.1519497675220; Sat, 24 Feb 2018 10:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.52.4 with HTTP; Sat, 24 Feb 2018 10:41:14 -0800 (PST) In-Reply-To: <20180212085852.GA94212@kib.kiev.ua> References: <20180212085852.GA94212@kib.kiev.ua> From: Ryan Stone Date: Sat, 24 Feb 2018 13:41:14 -0500 Message-ID: Subject: Re: Panic in prison_alloc() on boot To: Konstantin Belousov Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 18:41:16 -0000 Sorry for the late reply. Panicking this system is a bit painful, but I found some time to do it today. Strangely, it's actually cred that is NULL, not cred->cr_prison: (kgdb) p cred $7 = (struct ucred *) 0x0 (kgdb) disassemble Dump of assembler code for function prison_allow: 0xffffffff80ac33e0 <+0>: push %rbp 0xffffffff80ac33e1 <+1>: mov %rsp,%rbp => 0xffffffff80ac33e4 <+4>: mov 0x30(%rdi),%rax 0xffffffff80ac33e8 <+8>: and 0xf8(%rax),%esi 0xffffffff80ac33ee <+14>: mov %esi,%eax 0xffffffff80ac33f0 <+16>: pop %rbp 0xffffffff80ac33f1 <+17>: retq End of assembler dump. (kgdb) info reg $rdi rdi 0x0 0 However, if I go up a frame, things look fine? (kgdb) up #13 0xffffffff82c22531 in nullfs_mount (mp=0xfffff801a483d000) at /usr/src/sys/fs/nullfs/null_vfsops.c:88 88 if (!prison_allow(td->td_ucred, PR_ALLOW_MOUNT_NULLFS)) (kgdb) p td->td_ucred $8 = (struct ucred *) 0xfffff801854c1700 This appears to be a miscompilation, but I've blown away /usr/obj/usr/src multiple times and rebuilt and got this same error every time. But looking at the disassembly, something is definitely wrong: 0xffffffff82c22517 <+23>: mov %gs:0x0,%r14 0xffffffff82c22520 <+32>: mov 0x150(%r14),%rdi 0xffffffff82c22527 <+39>: mov $0x100,%esi 0xffffffff82c2252c <+44>: callq 0xffffffff80ac33e0 => 0xffffffff82c22531 <+49>: test %eax,%eax (kgdb) p &((struct thread*)0)->td_ucred $10 = (struct ucred **) 0x158 It uses offset 0x150 to get the cred, but the debug info claims that td_ucred is at offset 0x158. If I print out the pointer at that offset, it looks reasonable: (kgdb) p *td->td_ucred $11 = {cr_ref = 107, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 1, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0xfffff80106617000, cr_ruidinfo = 0xfffff80106617000, cr_prison = 0xffffffff8187cb70 , cr_loginclass = 0xfffff8019fa43b00, cr_flags = 0, cr_pspare2 = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 4294967295, ai_mask = {am_success = 0, am_failure = 0}, ai_termid = {at_port = 0, at_type = 4, at_addr = {0, 0, 0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xfffff801854c179c, cr_agroups = 16, cr_smallgroups = {0 }} I'm really at a loss at to what to try next. Build with MAKEOBJDIRPREFIX set to something else to get rid of any lingering possibility of an issue in my objdir, I guess?