From owner-freebsd-current@freebsd.org Sun Feb 14 14:10:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97D6FAA7EDF for ; Sun, 14 Feb 2016 14:10:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DAE52179C for ; Sun, 14 Feb 2016 14:10:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA11875 for ; Sun, 14 Feb 2016 16:10:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aUxNr-000K7x-6l for freebsd-current@FreeBSD.org; Sun, 14 Feb 2016 16:10:43 +0200 Subject: Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead) To: FreeBSD Current References: <56BBAB6E.5050601@FreeBSD.org> From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <56C08AAA.5050206@FreeBSD.org> Date: Sun, 14 Feb 2016 16:09:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56BBAB6E.5050601@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 14 Feb 2016 14:10:52 -0000 On 10/02/2016 23:28, Andriy Gapon wrote: > > Over a span of approximately 3 weeks I have got two slightly different panics of > the same kind. The affected system is a several months old amd64 head. I added a small assertion and it got tripped: --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -608,8 +608,11 @@ readrest: cluster_offset; } ahead = ulmin(ahead, atop(fs.entry->end - vaddr) - 1); - if (era != nera) + if (era != nera) { + KASSERT(fs.lookup_still_valid, + ("modifying read_ahead without map lock")); fs.entry->read_ahead = nera; + } /* * Call the pager to retrieve the data, if any, after So, it seems that the code allows modification of read_ahead field of an entry without holding a map lock. I'd guess that that should be mostly harmless as read_ahead value is not critical, but it is still not nice. Some details from the panic caused by the assertion can be found here: http://dpaste.com/39BYV7S.txt > ======================== 1 =========================================== > Unread portion of the kernel message buffer: > panic: Memory modified after free 0xfffff8008c15ac80(128) val=adc0de @ > 0xfffff8008c15acdc > > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8041e90b = db_trace_self_wrapper+0x2b/frame > 0xfffffe04f5349530 > kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame 0xfffffe04f53495e0 > vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f5349620 > panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f5349680 > trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame 0xfffffe04f5349690 > uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame > 0xfffffe04f5349720 > uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame 0xfffffe04f5349730 > vm_map_entry_create() at 0xffffffff807e5a2e = vm_map_entry_create+0x2e/frame > 0xfffffe04f5349740 > _vm_map_clip_start() at 0xffffffff807e69e3 = _vm_map_clip_start+0x123/frame > 0xfffffe04f5349770 > vm_map_wire() at 0xffffffff807e797d = vm_map_wire+0x11d/frame 0xfffffe04f53497f0 > vslock() at 0xffffffff807e1a2b = vslock+0x6b/frame 0xfffffe04f5349810 > sysctl_wire_old_buffer() at 0xffffffff8064148a = > sysctl_wire_old_buffer+0x4a/frame 0xfffffe04f5349830 > sysctl_kern_proc() at 0xffffffff8062259b = sysctl_kern_proc+0x8b/frame > 0xfffffe04f5349880 > sysctl_root_handler_locked() at 0xffffffff80641a8e = > sysctl_root_handler_locked+0x8e/frame 0xfffffe04f53498c0 > sysctl_root() at 0xffffffff806412fe = sysctl_root+0x13e/frame 0xfffffe04f5349940 > userland_sysctl() at 0xffffffff8064183d = userland_sysctl+0x16d/frame > 0xfffffe04f53499e0 > sys___sysctl() at 0xffffffff80641694 = sys___sysctl+0x74/frame 0xfffffe04f5349a90 > syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame 0xfffffe04f5349b00 > amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame 0xfffffe04f5349bf0 > Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame 0xfffffe04f5349bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8042225ea, rsp = > 0x7fffffffcef8, rbp = 0x7fffffffcf30 --- > Uptime: 14d22h38m17s > ====================================================================== > > ======================== 2 =========================================== > Unread portion of the kernel message buffer: > panic: Memory modified after free 0xfffff80176692680(128) val=adc0de @ > 0xfffff801766926dc > > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8041e90b = db_trace_self_wrapper+0x2b/frame > 0xfffffe04f507c5a0 > kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame 0xfffffe04f507c650 > vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f507c690 > panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f507c6f0 > trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame 0xfffffe04f507c700 > uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame > 0xfffffe04f507c790 > uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame 0xfffffe04f507c7a0 > vm_map_entry_create() at 0xffffffff807e5a2e = vm_map_entry_create+0x2e/frame > 0xfffffe04f507c7b0 > vm_map_insert() at 0xffffffff807e558a = vm_map_insert+0x2fa/frame 0xfffffe04f507c850 > vm_map_stack_locked() at 0xffffffff807e63cb = vm_map_stack_locked+0x13b/frame > 0xfffffe04f507c8b0 > vm_map_find() at 0xffffffff807e65d3 = vm_map_find+0x183/frame 0xfffffe04f507c950 > vm_mmap_object() at 0xffffffff807eac99 = vm_mmap_object+0x329/frame > 0xfffffe04f507c9d0 > sys_mmap() at 0xffffffff807ea8ec = sys_mmap+0x41c/frame 0xfffffe04f507ca90 > syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame 0xfffffe04f507cb00 > amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame 0xfffffe04f507cbf0 > Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame 0xfffffe04f507cbf0 > --- syscall (477, FreeBSD ELF64, sys_mmap), rip = 0x80418776a, rsp = > 0x7fffffffb808, rbp = 0x7fffffffb840 --- > Uptime: 4d4h36m36s > ====================================================================== > > I have crash dumps from both panics. > It seems that it was read_ahead field that was reset to zero in both cases. > Perhaps the issue has been fixed already? > I would appreciate any suggestions. Thanks! > -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Feb 14 22:27:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20208AA9F88 for ; Sun, 14 Feb 2016 22:27:50 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 E19891E9B; Sun, 14 Feb 2016 22:27:49 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id z135so72076955iof.0; Sun, 14 Feb 2016 14:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=apdbFvovvUcAbjP7c6pcHZwieYwpz0RwamCDJ829ZLM=; b=L9e8kEt5FiKH0afFLI/PIuXJcNhxyhytP8ocUr7DwIZe9t7/72ay6TwHW0ALm7rjMm pK1VXS56cr3VTWM3VuG2Ng5+PS/8YgkJnimeKraY2SsaQ4c2Zlad9VAp7nHALv6sWshc DquTDPZbyRjBYQ0qfCwCU/5TCn9qlvR1CmgR1lmECloYyZ16YIbL2j/m+0nSxnL4sp6s UzzgziW+fZPOVFcoL0d1ObqMT9A7ASWwXrnf/eovHFpEim3Vgcfbw3DE/P3hZs8cGQ/w vpnoUpAppqeo2C4RfyZ0Q7C+huIqTrC631ywtgXpCY/II5HaZM9M1gIS3ofw2OjNwo8l C5tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=apdbFvovvUcAbjP7c6pcHZwieYwpz0RwamCDJ829ZLM=; b=CsYg+gashB/Eh6ELspf6tRMzC2dHRcHlUbnkT7x9xf2eo79qLtG/sXmFsQo1ky9N6u xEMaJKN4+obKgNm9Q0ZtqBNIcgEyYOA4prbyofmcviy9YFwu9MpPHVdXLIgwrsR0oh64 8ENtR9R823dn1OGHW0hJO8/IAceihrlv1ohaqTUuxl91b6jpfpA9E+LWxLDz4E4iAeyM 2YuRaMjBkwzWfBPog867WqoDkfrtNA/aNkTie4GdZU1w9ov6Nqd+C0O6kA4n6vyQwTuR tRYmCuyUcoGyI3f9kIg3H5JqF1Bf9OV8LERBvs8nRIceSvgdV8CPzQZJBk3ZOlWuG/M7 hMJQ== X-Gm-Message-State: AG10YOSXGdrcordZ9KV1cOlVYShR5/6AC2VdjB//0hdZAwZeUkZUT43qcqQXSxvnK04YaWRZsGsZG1og8/g12Q== MIME-Version: 1.0 X-Received: by 10.107.170.79 with SMTP id t76mr17307424ioe.71.1455488869325; Sun, 14 Feb 2016 14:27:49 -0800 (PST) Received: by 10.79.84.71 with HTTP; Sun, 14 Feb 2016 14:27:49 -0800 (PST) Reply-To: alc@freebsd.org In-Reply-To: <56C08AAA.5050206@FreeBSD.org> References: <56BBAB6E.5050601@FreeBSD.org> <56C08AAA.5050206@FreeBSD.org> Date: Sun, 14 Feb 2016 16:27:49 -0600 Message-ID: Subject: Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead) From: Alan Cox To: Andriy Gapon Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 14 Feb 2016 22:27:50 -0000 On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon wrote: > On 10/02/2016 23:28, Andriy Gapon wrote: > > > > Over a span of approximately 3 weeks I have got two slightly different > panics of > > the same kind. The affected system is a several months old amd64 head. > > I added a small assertion and it got tripped: > --- a/sys/vm/vm_fault.c > +++ b/sys/vm/vm_fault.c > @@ -608,8 +608,11 @@ readrest: > cluster_offset; > } > ahead = ulmin(ahead, atop(fs.entry->end - vaddr) - > 1); > - if (era != nera) > + if (era != nera) { > + KASSERT(fs.lookup_still_valid, > + ("modifying read_ahead without map > lock")); > fs.entry->read_ahead = nera; > + } > > /* > * Call the pager to retrieve the data, if any, > after > > So, it seems that the code allows modification of read_ahead field of an > entry > without holding a map lock. I'd guess that that should be mostly harmless > as > read_ahead value is not critical, but it is still not nice. > > Not intentionally. The nearby code to the read_ahead assignment expects the map to be locked, so I wouldn't categorize this as mostly harmless. In general, you shouldn't get to the read_ahead assignment without the map being locked, and almost all of the code paths that unlock the map jump to RetryFault shortly thereafter, so it's hard to imagine how the map lock wouldn't be reacquired. I speculate that the root cause of your panic is a case where vm_pager_get_pages() fails, and in such a case we might loop around, descending to the next backing object without reacquiring the map lock. In other words, your above assertion failure is happening on the next iteration after an initial vm_pager_get_pages() failure, and we're about to do another vm_pager_get_pages() call on a different object. In summary, I have no trouble believing that the code that handles a failure by vm_pager_get_pages() in vm_fault() is not quite right, and I think that's what's biting you. > Some details from the panic caused by the assertion can be found here: > http://dpaste.com/39BYV7S.txt > > > > ======================== 1 =========================================== > > Unread portion of the kernel message buffer: > > panic: Memory modified after free 0xfffff8008c15ac80(128) val=adc0de @ > > 0xfffff8008c15acdc > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff8041e90b = > db_trace_self_wrapper+0x2b/frame > > 0xfffffe04f5349530 > > kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame > 0xfffffe04f53495e0 > > vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f5349620 > > panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f5349680 > > trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame > 0xfffffe04f5349690 > > uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame > > 0xfffffe04f5349720 > > uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame > 0xfffffe04f5349730 > > vm_map_entry_create() at 0xffffffff807e5a2e = > vm_map_entry_create+0x2e/frame > > 0xfffffe04f5349740 > > _vm_map_clip_start() at 0xffffffff807e69e3 = > _vm_map_clip_start+0x123/frame > > 0xfffffe04f5349770 > > vm_map_wire() at 0xffffffff807e797d = vm_map_wire+0x11d/frame > 0xfffffe04f53497f0 > > vslock() at 0xffffffff807e1a2b = vslock+0x6b/frame 0xfffffe04f5349810 > > sysctl_wire_old_buffer() at 0xffffffff8064148a = > > sysctl_wire_old_buffer+0x4a/frame 0xfffffe04f5349830 > > sysctl_kern_proc() at 0xffffffff8062259b = sysctl_kern_proc+0x8b/frame > > 0xfffffe04f5349880 > > sysctl_root_handler_locked() at 0xffffffff80641a8e = > > sysctl_root_handler_locked+0x8e/frame 0xfffffe04f53498c0 > > sysctl_root() at 0xffffffff806412fe = sysctl_root+0x13e/frame > 0xfffffe04f5349940 > > userland_sysctl() at 0xffffffff8064183d = userland_sysctl+0x16d/frame > > 0xfffffe04f53499e0 > > sys___sysctl() at 0xffffffff80641694 = sys___sysctl+0x74/frame > 0xfffffe04f5349a90 > > syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame > 0xfffffe04f5349b00 > > amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame > 0xfffffe04f5349bf0 > > Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame > 0xfffffe04f5349bf0 > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8042225ea, rsp = > > 0x7fffffffcef8, rbp = 0x7fffffffcf30 --- > > Uptime: 14d22h38m17s > > ====================================================================== > > > > ======================== 2 =========================================== > > Unread portion of the kernel message buffer: > > panic: Memory modified after free 0xfffff80176692680(128) val=adc0de @ > > 0xfffff801766926dc > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff8041e90b = > db_trace_self_wrapper+0x2b/frame > > 0xfffffe04f507c5a0 > > kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame > 0xfffffe04f507c650 > > vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f507c690 > > panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f507c6f0 > > trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame > 0xfffffe04f507c700 > > uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame > > 0xfffffe04f507c790 > > uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame > 0xfffffe04f507c7a0 > > vm_map_entry_create() at 0xffffffff807e5a2e = > vm_map_entry_create+0x2e/frame > > 0xfffffe04f507c7b0 > > vm_map_insert() at 0xffffffff807e558a = vm_map_insert+0x2fa/frame > 0xfffffe04f507c850 > > vm_map_stack_locked() at 0xffffffff807e63cb = > vm_map_stack_locked+0x13b/frame > > 0xfffffe04f507c8b0 > > vm_map_find() at 0xffffffff807e65d3 = vm_map_find+0x183/frame > 0xfffffe04f507c950 > > vm_mmap_object() at 0xffffffff807eac99 = vm_mmap_object+0x329/frame > > 0xfffffe04f507c9d0 > > sys_mmap() at 0xffffffff807ea8ec = sys_mmap+0x41c/frame > 0xfffffe04f507ca90 > > syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame > 0xfffffe04f507cb00 > > amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame > 0xfffffe04f507cbf0 > > Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame > 0xfffffe04f507cbf0 > > --- syscall (477, FreeBSD ELF64, sys_mmap), rip = 0x80418776a, rsp = > > 0x7fffffffb808, rbp = 0x7fffffffb840 --- > > Uptime: 4d4h36m36s > > ====================================================================== > > > > I have crash dumps from both panics. > > It seems that it was read_ahead field that was reset to zero in both > cases. > > Perhaps the issue has been fixed already? > > I would appreciate any suggestions. Thanks! > > > > > -- > Andriy Gapon > _______________________________________________ > 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 15 02:36:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA43CAA8924 for ; Mon, 15 Feb 2016 02:36:40 +0000 (UTC) (envelope-from gwq_uk@yahoo.com) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (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 5FC4B1A14 for ; Mon, 15 Feb 2016 02:36:40 +0000 (UTC) (envelope-from gwq_uk@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455503592; bh=LrAGM0su/LtKv0+IxRgeg1vWrEu5/4VIsstRnpy6K0Y=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=IUDARL2On1SvHOVaZP7qpr1YkcqAkTShcXPgS0PeZNYEk/ygjNaW3zUvAZ2LC+xnAkp6ivD8F6LPbkZMlV5o+FMw1k/0lG4wL2Iv7XwKGMg5FhPHUfGPXjh6VZwRq79nTeTzFlGYMgeL/FpLJKbRhAGfdbZioLYpW4ASWtX3eHTjhGNwstvJBuUMfB+vFIUOhSluq5T+Qp1ElIF6TjchqQ1AGsVF1GXJHeaawDrAwVc1Q1XZGk9hTzO8I9GqmFQ85eBNRF9jaKj5UVyI8TyR7SsJLRf/QkC4vT+KgMqL/t1Vt4zF7FU0KTWppO2Fb9v3YHI8i/zy5RmP650LdlSFKg== Received: from [98.139.215.141] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2016 02:33:12 -0000 Received: from [98.139.212.214] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2016 02:33:12 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 15 Feb 2016 02:33:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 505698.31194.bm@omp1023.mail.bf1.yahoo.com X-YMail-OSG: OrpcEHwVM1nNgpMgGqnZ9BGPetZqUvgh49Gy9kxD8njU9snd.DzoVQj87vloSA8 bLKMXxdBoo.db7HCe3TvFL5dEuVkNLmIaVKwaXFThhJbqGIHKUajOwbqD3qRHjU9C3uJPCZe0ms8 07SxB8hpRnV83hvm.Em2S5YUKQb89w_ArZqJ4qUYGbwCNqqpo18ztYkvfLmZsn1FSnOsoDFZ_y2K VXdDl.w_uwRkAunvH32to7O8ob8i3SoKQx1D4kja1V59DoZRJ2IelzS6IQaoZDvhUnWiKT2HuyZ4 RVdDm3TcQhfbseBnJdqz3VMJmuVXAlSP4X4LfT2CODhsGXrOZwQLsMen60v02Vp6wdYY63CDCnci GHCdOeK9t0BUV38dDUl9GLC68rXn1mCPyXdfD938FtmPhL0U2.MJmlkabPvmX4UheoLNrXPSc97S URtiJ_5uubiEGqx19c8Iv9NKXmU7pWHbIVndPjBC5G.TMKbXZeIgPito0doZV3F7182aFH.nkweY 5SoZO Received: by 76.13.26.159; Mon, 15 Feb 2016 02:33:12 +0000 Date: Mon, 15 Feb 2016 02:33:11 +0000 (UTC) From: Greg Quinlan Reply-To: Greg Quinlan To: Hans Petter Selasky , "freebsd-current@freebsd.org" Message-ID: <693932216.4173309.1455503591733.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <56BEE187.80702@selasky.org> References: <56BEE187.80702@selasky.org> Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL PANIC FreeBSD-11 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 15 Feb 2016 02:36:40 -0000 Thanks.=20 I am not going to use OSS anymore...=C2=A0=20 I am going to stick to stick with a custom kernel device sounddevice snd_hda=C2=A0From: Hans Petter Selasky To: Greg Quinlan ; "freebsd-current@freebsd.org" =20 Sent: Saturday, 13 February 2016, 18:55 Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL PANIC= FreeBSD-11 =20 On 02/12/16 01:04, Greg Quinlan wrote: > Spoke too soon... > > I applied the patch (kern_module.diff - which was successful) > > # cd /usr/src# patch The text leading up to this was: > -------------------------- > |Index: sys/kern/kern_module.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/kern_module.c=C2=A0 =C2=A0 (revision 295464) > |+++ sys/kern/kern_module.c=C2=A0 =C2=A0 (working copy) > -------------------------- > Patching file sys/kern/kern_module.c using Plan A... > Hunk #1 succeeded at 214. > done > # make buildkernel: > # make installkernel: > # shutdown -r now > Logged in and ran# soundon > No panic!! > > Thought the problem was fixed ... unfortunately, I assumed that the conte= nts of /usr/local/lib/oss/etc/installed_drivers still contained >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oss_hdaudio #Intel High Definition Audi= o (CPT) > but somehow the file was empty > I ran >=C2=A0 =C2=A0 =C2=A0 # ossdetect=C2=A0 =C2=A0 # soundon > > Another KERNEL PANIC...=C2=A0 this time it scrolled off the screen. I tri= ed setting this (below) in /etc/rc.conf but there is nothing in /var/crash > > [entries in /etc/rc.conf] >=C2=A0 =C2=A0 =C2=A0 dumpdev=3D"AUTO" >=C2=A0 =C2=A0 =C2=A0 dumpdir=3D"/var/crash" > I need help to recover the backtrace, please? > > Thanks > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Greg Quinlan > To: Hans Petter Selasky ; "freebsd-current@freebsd.org" = >=C2=A0 Sent: Thursday, 11 February 2016, 22:19 >=C2=A0 Subject: Re: Open Sound System - OSS "soundon" command causes KERNE= L PANIC FreeBSD-11 > > Well done!! > Fixed. Thanks! > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Hans Petter Selasky >=C2=A0 To: Greg Quinlan ; "freebsd-current@freebsd.org" = >=C2=A0 Sent: Thursday, 11 February 2016, 17:54 >=C2=A0 Subject: Re: Open Sound System - OSS "soundon" command causes KERNE= L PANIC FreeBSD-11 > > On 02/11/16 03:02, Greg Quinlan wrote: >> Hi HPS, >> Note: Does not happen on FreeBSD 10.1-Stable! >> > > Yes, that's because WITNESS is off in 10.x by default. > > Does the attached patch solve your problem? > > --HPS Hi, It might be that audio/oss is not compatible with 11-current if it=20 crashes like that. --HPS _______________________________________________ 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 15 09:08:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32191AA6A2C for ; Mon, 15 Feb 2016 09:08:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 51E4A1AC4; Mon, 15 Feb 2016 09:08:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA04012; Mon, 15 Feb 2016 11:08:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aVF8y-000LMO-FA; Mon, 15 Feb 2016 11:08:32 +0200 Subject: Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead) To: alc@FreeBSD.org References: <56BBAB6E.5050601@FreeBSD.org> <56C08AAA.5050206@FreeBSD.org> Cc: FreeBSD Current From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <56C1953F.60604@FreeBSD.org> Date: Mon, 15 Feb 2016 11:07:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 15 Feb 2016 09:08:36 -0000 On 15/02/2016 00:27, Alan Cox wrote: > > On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon > wrote: > > On 10/02/2016 23:28, Andriy Gapon wrote: > > > > Over a span of approximately 3 weeks I have got two slightly different panics of > > the same kind. The affected system is a several months old amd64 head. > > I added a small assertion and it got tripped: [snip] > > So, it seems that the code allows modification of read_ahead field of an entry > without holding a map lock. I'd guess that that should be mostly harmless as > read_ahead value is not critical, but it is still not nice. > > Not intentionally. The nearby code to the read_ahead assignment expects the map > to be locked, so I wouldn't categorize this as mostly harmless. > > In general, you shouldn't get to the read_ahead assignment without the map being > locked, and almost all of the code paths that unlock the map jump to RetryFault > shortly thereafter, so it's hard to imagine how the map lock wouldn't be > reacquired. I speculate that the root cause of your panic is a case where > vm_pager_get_pages() fails, and in such a case we might loop around, descending > to the next backing object without reacquiring the map lock. In other words, > your above assertion failure is happening on the next iteration after an initial > vm_pager_get_pages() failure, and we're about to do another vm_pager_get_pages() > call on a different object. > > In summary, I have no trouble believing that the code that handles a failure by > vm_pager_get_pages() in vm_fault() is not quite right, and I think that's what's > biting you. Alan, thank you very much for the very insightful analysis. Indeed, I see that in this case the object chain is default -> swap -> swap. I am not sure how such chain was created. It seems that going default -> swap is not a problem as the map lock is not dropped in this case. But going swap -> swap the way you described (pager error, e.g. the page is just not found) has exactly the problem that you suggested. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Feb 15 16:12:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F163DAA982D for ; Mon, 15 Feb 2016 16:12:20 +0000 (UTC) (envelope-from vangyzen@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 E530C13A4 for ; Mon, 15 Feb 2016 16:12:20 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E0A7CAA982C; Mon, 15 Feb 2016 16:12:20 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E03FAAA982B for ; Mon, 15 Feb 2016 16:12:20 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id CEA4613A2; Mon, 15 Feb 2016 16:12:20 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4D29556497; Mon, 15 Feb 2016 10:12:20 -0600 (CST) From: Eric van Gyzen Subject: /etc/periodic/weekly/320.whatis: /usr/libexec/makewhatis.local: not found To: bapt@FreeBSD.org, current@FreeBSD.org Message-ID: <56C1F8E0.2020708@FreeBSD.org> Date: Mon, 15 Feb 2016 10:12:16 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 15 Feb 2016 16:12:21 -0000 I just set up a workstation running head. The weekly 320.whatis script always reports: /usr/libexec/makewhatis.local: not found Indeed, it doesn't exist. Does the 320.whatis script need to be updated for r283777? Cheers, Eric From owner-freebsd-current@freebsd.org Tue Feb 16 10:55:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 492F4AA9875 for ; Tue, 16 Feb 2016 10:55:44 +0000 (UTC) (envelope-from outbackdingo@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 2C8AF1734 for ; Tue, 16 Feb 2016 10:55:44 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 29EABAA9874; Tue, 16 Feb 2016 10:55:44 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FAFFAA9873 for ; Tue, 16 Feb 2016 10:55:44 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 8E8261733 for ; Tue, 16 Feb 2016 10:55:43 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id m1so106420221lfg.0 for ; Tue, 16 Feb 2016 02:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=TYqLGk7Z5p3QZ34eNEiC6N3ULbJd6O9qW+ym87vJU0w=; b=AUz0PPIMHv6XVtZAArsZ57ECe2ltPRyC+2mI8aAJeSZNdOQDxV5sN3MJ9fGp7uwFxh mmD/2TRRGzALb7H96Q737qeAr1suj48OcifyTkOrqLSAlkjm2yKET7Eg210GtKQopWrc 7h+f+uiLiyHWcQYLYj9V9whUiWhjE9lowYvRB4yYyplm4FOVZ4DCKJZSm51lon9qQ7nn QrClpUILe74NdsUuiXpKiD3Sn9xipQFfPSQH1z7g8sQNpKp4Zo6mg+0wo2VOFw4V1iZK SLqrlbYTT6PUhcXgx9adpT4ARhpI+XWH9KZHVf6kZsSHt9AXOblivrQsc8OcDf67cCtg mHog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=TYqLGk7Z5p3QZ34eNEiC6N3ULbJd6O9qW+ym87vJU0w=; b=EQ4Occ0YEHz1ssqfN8madXoNur7mzHHcXOPKioe8+ogAR2HNUSMSgSQtZUk6erGWUq Kjr29IflTBzEq9+wIYPd47e8Y7biG0uFlI5XyeH0A9AWFMLwomPpFIjQ07VcklnUNh18 r2t5oUAYW0ahj79gFiLbqYpvHvnihK2yfDmrIFhWbJFvrBOue10oC1CJz+zwQxlzTjka PgaCKGooTlWIHPOzJwP+czUsUrRofzc/a2wyNVByibPw2dUMylM6QtEa7xaFWlNz2tkV KpE/ZNbVG4Y7TgqQWZUrJPXKJE4jGX2NNrzgCCiq1T9OasHN76UqW2rfy+BRlklNYoTd SsKw== X-Gm-Message-State: AG10YOQFlWI3tepZzgpgAl7y7sQFgfmeeUsT78wov8CVopvkja3/5SxpBtdd9IiPUWx+WZmO/o2sV9EEY9UsCQ== X-Received: by 10.25.25.84 with SMTP id 81mr8972561lfz.71.1455620141708; Tue, 16 Feb 2016 02:55:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.28.194 with HTTP; Tue, 16 Feb 2016 02:55:02 -0800 (PST) From: Outback Dingo Date: Tue, 16 Feb 2016 11:55:02 +0100 Message-ID: Subject: CURRENT BROKEN fatal error: 'config_local.h' file not found To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 16 Feb 2016 10:55:44 -0000 seems current is broken due to a missing file /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found CC='cc' mkdep -f .depend -a -I/usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/libelftc -I/usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/libpe -I/usr/src/usr.bin /elfcopy/../../contrib/elftoolchain/common -DWITH_PE=1 -std=gnu99 /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/archive.c /usr/src/usr.bin/elfcopy/../../co ntrib/elftoolchain/elfcopy/ascii.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/binary.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/main.c / usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/pe.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/sections.c /usr/src/usr.bin/elfcopy/../../contri b/elftoolchain/elfcopy/segments.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/symbols.c --- depend_subdir_usr.sbin --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab/mtab_bsd.c:51: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error From owner-freebsd-current@freebsd.org Tue Feb 16 12:00:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73C83AA9E06; Tue, 16 Feb 2016 12:00:50 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 574C0138F; Tue, 16 Feb 2016 12:00:50 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 05CF61CE8; Tue, 16 Feb 2016 12:00:49 +0000 (UTC) Date: Tue, 16 Feb 2016 12:00:47 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: andrew@FreeBSD.org, olivier@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1787093706.5.1455624049169.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1948561587.1.1455609836828.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1948561587.1.1455609836828.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2350 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 12:00:50 -0000 FreeBSD_HEAD_i386 - Build #2350 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2350/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2350/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2350/cons= ole Change summaries: 295654 by andrew: Only read the power state register when we will be using its value. While here remove magic shifts, and cleanup pwr_name. Sponsored by:=09ABT Systems Ltd 295653 by olivier: Add myself as ports committer (including calendar) Approved by:=09jadawin Differential Revision:=09https://reviews.freebsd.org/D5295 The end of the build log: [...truncated 83513 lines...] --- depend_subdir_random --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.bin/random/r= andom.c /usr/src/usr.bin/random/randomize_fd.c echo random.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_sa --- =3D=3D=3D> usr.sbin/sa (depend) --- depend_subdir_usr.bin --- --- depend_subdir_primes --- echo primes.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/= usr/lib/libm.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_amd --- =3D=3D=3D> usr.sbin/amd (depend) --- depend_subdir_sa --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.sbin/sa/main= .c /usr/src/usr.sbin/sa/db.c /usr/src/usr.sbin/sa/pdb.c /usr/src/usr.sbin/s= a/usrdb.c /usr/src/usr.sbin/sa/../../usr.bin/lastcomm/readrec.c --- depend_subdir_amd --- --- depend_subdir_include --- =3D=3D=3D> usr.sbin/amd/include (depend) --- depend_subdir_libamu --- =3D=3D=3D> usr.sbin/amd/libamu (depend) --- nfs_prot_x.c --- RPCGEN_CPP=3Dcpp\ rpcgen -c -C -DWANT_NFS3 /usr/obj/usr/src/tmp/usr/includ= e/rpcsvc/nfs_prot.x -o nfs_prot_x.c --- xdr_func_%undef.c --- unifdef -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS -DHAVE_XDR_DIRLIST -DHAVE= _XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES -DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH= -DHAVE_XDR_ENTRY -DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR= -DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME -DHAVE_XDR_FTYP= E -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS -DHAVE_XDR_LINKARGS -DHAVE_XDR_MOU= NTBODY -DHAVE_XDR_MOUNTLIST -DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NF= SCOOKIE -DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME -DHAVE_XDR= _POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS -DHAVE_XDR_READDIRRES -= DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES -DHAVE_XDR_READRES -DHAVE_XDR_RE= NAMEARGS -DHAVE_XDR_SATTR -DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAV= E_XDR_STATFSRES -DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS < /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/xdr_func.c > xdr_func_%undef.c --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/amd/libamu/../../../co= ntrib/amd/libamu -I/usr/obj/usr/src/tmp/usr/include/rpcsvc -I. -I/usr/src/u= sr.sbin/amd/libamu -I/usr/src/usr.sbin/amd/libamu/../include -I/usr/obj/usr= /src/usr.sbin/amd/libamu/../include -I/usr/src/usr.sbin/amd/libamu/../../..= /contrib/amd/include -I/usr/src/usr.sbin/amd/libamu/../../../contrib/amd -D= HAVE_CONFIG_H -DHOST_CPU=3D\"i386\" -DHOST_ARCH=3D\"i386\" -std=3Dgnu99 = /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/hasmntopt.c /usr/s= rc/usr.sbin/amd/libamu/../../../contrib/amd/libamu/misc_rpc.c /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/mount_fs.c /usr/src/usr.sbin/am= d/libamu/../../../contrib/amd/libamu/mtab.c /usr/src/usr.sbin/amd/libamu/..= /../../contrib/amd/libamu/nfs_prot_xdr.c /usr/src/usr.sbin/amd/libamu/../..= /../contrib/amd/libamu/strutil.c /usr/src/usr.sbin/amd/libamu/../../../cont= rib/amd/libamu/wire.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/transp/t= ransp_sockets.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab= /mtab_bsd.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/u= mount_bsd44.c nfs_prot_x.c xdr_func_%undef.c --- depend_subdir_sa --- echo sa.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend --- =3D=3D=3D> usr.sbin/sa/tests (depend) --- depend_subdir_usr.bin --- --- depend_subdir_vgrind --- =3D=3D=3D> usr.bin/vgrind (depend) --- depend_subdir_usr.sbin --- --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/hasmntopt.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.bin/vgrind/r= egexp.c /usr/src/usr.bin/vgrind/vfontedpr.c echo vfontedpr.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend_subdir_iconv --- =3D=3D=3D> usr.bin/iconv (depend) --- depend_subdir_usr.sbin --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/misc_rpc.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.bin/iconv/ic= onv.c echo iconv.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_audit --- =3D=3D=3D> usr.sbin/audit (depend) --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mount_fs.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_audit --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/audit/../../contrib/op= enbsm -std=3Dgnu99 /usr/src/usr.sbin/audit/../../contrib/openbsm/bin/aud= it/audit.c --- depend_subdir_amd --- 1 error generated. --- depend_subdir_audit --- echo audit.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libbsm.a >> .depend --- depend_subdir_auditd --- =3D=3D=3D> usr.sbin/auditd (depend) --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mtab.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditd --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/auditd/../../contrib/o= penbsm -std=3Dgnu99 /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/a= uditd/auditd.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/au= dit_warn.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/auditd= _fbsd.c --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/nfs_prot_xdr.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. --- depend_subdir_auditd --- echo auditd.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/= usr/lib/libauditd.a /usr/obj/usr/src/tmp/usr/lib/libbsm.a >> .depend --- depend_subdir_auditdistd --- =3D=3D=3D> usr.sbin/auditdistd (depend) --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/strutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditdistd --- --- parse.c --- yacc -d -v -o parse.c /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bi= n/auditdistd/parse.y --- depend_subdir_amd --- 1 error generated. --- depend_subdir_auditdistd --- --- token.c --- lex -otoken.c /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/audit= distd/token.l --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/wire.c:57: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditdistd --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/auditdistd/../../contr= ib/openbsm -I/usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/auditdi= std -std=3Dgnu99 /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/= auditdistd/auditdistd.c parse.c /usr/src/usr.sbin/auditdistd/../../contrib/= openbsm/bin/auditdistd/pjdlog.c /usr/src/usr.sbin/auditdistd/../../contrib/= openbsm/bin/auditdistd/proto.c /usr/src/usr.sbin/auditdistd/../../contrib/o= penbsm/bin/auditdistd/proto_common.c /usr/src/usr.sbin/auditdistd/../../con= trib/openbsm/bin/auditdistd/proto_socketpair.c /usr/src/usr.sbin/auditdistd= /../../contrib/openbsm/bin/auditdistd/proto_tcp.c /usr/src/usr.sbin/auditdi= std/../../contrib/openbsm/bin/auditdistd/proto_tls.c /usr/src/usr.sbin/audi= tdistd/../../contrib/openbsm/bin/auditdistd/receiver.c /usr/src/usr.sbin/au= ditdistd/../../contrib/openbsm/bin/auditdistd/sandbox.c /usr/src/usr.sbin/a= uditdistd/../../contrib/openbsm/bin/auditdistd/sender.c /usr/src/usr.sbin/a= uditdistd/../../contrib/openbsm/bin/auditdistd/subr.c token.c /usr/src/usr.= sbin/auditdistd/../../contrib/openbsm/bin/auditdistd/trail.c --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/transp/transp_sockets.c:47: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/mtab/mtab_bsd.c:51: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error make[5]: stopped in /usr/src/usr.sbin/amd/libamu *** [depend_subdir_libamu] Error code 2 make[4]: stopped in /usr/src/usr.sbin/amd 1 error make[4]: stopped in /usr/src/usr.sbin/amd *** [depend_subdir_amd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_auditdistd --- echo auditdistd.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/= tmp/usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpthread.a /usr/obj/usr/s= rc/tmp/usr/lib/libutil.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a /usr/obj/= usr/src/tmp/usr/lib/libssl.a >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.sbin/auditdistd *** [depend_subdir_auditdistd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_usr.bin --- --- depend_subdir_clang --- --- depend_subdir_tblgen --- echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/usr.= bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/= obj/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvms= upport.a /usr/obj/usr/src/tmp/usr/lib/libncursesw.a /usr/obj/usr/src/tmp/us= r/lib/libpthread.a >> .depend echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.bin/clang/tblgen *** [depend_subdir_tblgen] Error code 2 make[4]: stopped in /usr/src/usr.bin/clang 1 error make[4]: stopped in /usr/src/usr.bin/clang *** [depend_subdir_clang] Error code 2 make[3]: stopped in /usr/src/usr.bin 1 error make[3]: stopped in /usr/src/usr.bin *** [depend_subdir_usr.bin] Error code 2 make[2]: stopped in /usr/src --- depend_subdir_usr.sbin --- --- depend_subdir_tcpdump --- echo tcpdump.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp= /usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpcap.a /usr/obj/usr/src/tmp= /usr/lib/libcapsicum.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** [depend] Error code 2 make[4]: stopped in /usr/src/usr.sbin/tcpdump 1 error make[4]: stopped in /usr/src/usr.sbin/tcpdump *** [depend_subdir_tcpdump] Error code 2 make[3]: stopped in /usr/src/usr.sbin 3 errors make[3]: stopped in /usr/src/usr.sbin *** [depend_subdir_usr.sbin] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_depend] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson4353526006202368089.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Feb 16 08:03:59 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF357AAACAA; Tue, 16 Feb 2016 08:03:59 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BCAB1182B; Tue, 16 Feb 2016 08:03:59 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D6C7E1C82; Tue, 16 Feb 2016 08:03:58 +0000 (UTC) Date: Tue, 16 Feb 2016 08:03:47 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: dteske@FreeBSD.org, emaste@FreeBSD.org, skra@FreeBSD.org, pfg@FreeBSD.org, mmel@FreeBSD.org, feld@FreeBSD.org, cem@FreeBSD.org, hselasky@FreeBSD.org, des@FreeBSD.org, bdrewery@FreeBSD.org, ian@FreeBSD.org, cperciva@FreeBSD.org, jimharris@FreeBSD.org, zbb@FreeBSD.org, jhibbits@FreeBSD.org, bjk@FreeBSD.org, andrew@FreeBSD.org, jhb@FreeBSD.org, mav@FreeBSD.org, royger@FreeBSD.org, wma@FreeBSD.org, tuexen@FreeBSD.org, sephe@FreeBSD.org, vangyzen@FreeBSD.org, adrian@FreeBSD.org, markj@FreeBSD.org, glebius@FreeBSD.org, kib@FreeBSD.org, kevlo@FreeBSD.org, br@FreeBSD.org, cy@FreeBSD.org, np@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1948561587.1.1455609836828.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2349 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk X-Mailman-Approved-At: Tue, 16 Feb 2016 12:03:22 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 08:04:00 -0000 FreeBSD_HEAD_i386 - Build #2349 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2349/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2349/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2349/console Change summaries: 295651 by vangyzen: ichsmb: add PCI device ID for Intel Sunrise Point-H SMBus controller MFC after: 3 days Sponsored by: Dell Inc. 295650 by bdrewery: DIRDEPS_BUILD: Update dependencies. Sponsored by: EMC / Isilon Storage Division 295649 by bdrewery: Filemon: Fix panic when fork1() is called from kproc_create(). MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 295648 by bdrewery: Remove the need for overriding depend. Sponsored by: EMC / Isilon Storage Division 295647 by bdrewery: Add missing dependency on sys/conf/newvers.sh. Sponsored by: EMC / Isilon Storage Division 295646 by bdrewery: Add an .ORDER for all/install. Sponsored by: EMC / Isilon Storage Division 295645 by bdrewery: Use built-in :tA here rather than realpath(1). Sponsored by: EMC / Isilon Storage Division 295644 by bdrewery: Don't descend into test directories for distribution->installconfig. Sponsored by: EMC / Isilon Storage Division 295643 by bdrewery: Test directories can build in parallel fine. Sponsored by: EMC / Isilon Storage Division 295642 by jhibbits: Fix a panic bug that cropped up in the PTE rewrite. PTE was getting overwritten by just the flags. Pointy-hat to: jhibbits 295641 by bdrewery: Consolidate common beforebuild logic. Sponsored by: EMC / Isilon Storage Division 295638 by pfg: fputs: Return the number of bytes written. Fix r295631: wrong value. Pointy hat: pfg (me) Pointed out by: bde 295637 by jhb: Correct the ABI name for Linux/i386 binaries under FreeBSD/i386. This allows truss to work for these binaries again after r288424. MFC after: 3 days 295636 by jhb: Sign extend the error value for failing Linux/i386 system calls. This restores the mapping of Linux errors to native FreeBSD errno values after the refactoring in r288424. 295635 by andrew: Add support for the Allwinner DMA controller. This will be used by the at least the audio codec driver currently in review. Submitted by: Jared McNeill Differential Revision: https://reviews.freebsd.org/D5050 295634 by andrew: Add support for the AXP209 Power System Management IC. This allows boards with this and an Allwinner SoC to power off. Submitted by: Emmanuel Vadot Differential Revision: https://reviews.freebsd.org/D4954 295633 by andrew: Set sc->clkfreq removed in r295470 Reported by: Jared McNeill Pointy-hat to: andrew 295632 by pfg: getln: We cannot expand the buffer beyond INT_MAX. In such cases return ENOMEM. This is a limitation of our implementation, alternatively you may consider getline(3). Differential Revision: https://reviews.freebsd.org/D442 (Partial) Obtained from: Apple Inc. (Libc 997.90.3) Relnotes: yes 295631 by pfg: fputs: Return the number of bytes written. POSIX.1-2008 requires that successful completion simply return a non-negative integer. We have regularly returned a constant value. Another, equally valid, implementation convention implies returning the number of bytes written. Adopt this last convention to be in line with what Apple's libc does. POSIX also explicitly notes: Note that this implementation convention cannot be adhered to for strings longer than {INT_MAX} bytes as the value would not be representable in the return type of the function. For backwards-compatibility, implementations can return the number of bytes for strings of up to {INT_MAX} bytes, and return {INT_MAX} for all longer strings. Developers shouldn't depend specifically on either convention but the change may help port software from Apple. Differential Revision: https://reviews.freebsd.org/D442 (Partial) Obtained from: Apple Inc. (Libc 997.90.3 with changes) Relnotes: yes 295630 by andrew: Fix the spelling of OF_getencprop. It will fix the data correctly for the endian of the CPU so there is no need to call fdt32_to_cpu. Sponsored by: ABT Systems Ltd 295629 by andrew: Remove an unused FDT header, fdt_common.h should only be needed in a few places, mostly in sys/dev/fdt and legacy code. Sponsored by: ABT Systems Ltd 295628 by andrew: Remove an unused static inline function. Sponsored by: ABT Systems Ltd 295627 by skra: Initial OMAP4 WUGEN pass-through driver. SPI interrupts are passed through WUGEN to GIC. Hardware initialization is left in state after reset as well as before. This is needed after an update of Linux dts files. 295626 by andrew: Add support for the Allwinner i2c device. This is similar to the existing Marvell twsi part, however uses different register locations, as such split the existing driver into Marvell and Allwinner attachments. While here clean a few style issues. Submitted by: Emmanuel Vadot Differential Revision: https://reviews.freebsd.org/D4846 295625 by adrian: Allow MIPS INTRNG code to be built without FDT support. This patch allows the newly imported INTRNG code to be built without necessarily having FDT support in the kernel. This may be useful for some MIPS platforms that wish to move to INTRNG, but not to FDT at the same time. Basically all the code is already within ifdef's where FDT is concerned, it's just the headers that aren't. Submitted by: Stanislav Galabov Differential Revision: https://reviews.freebsd.org/D5249 295622 by andrew: Move the twsi driver source to be under iicbus. It is in a separate directory as it is expected multiple attachments will be added for the SoC families that use this hardware. Sponsored by: ABT Systems Ltd 295621 by andrew: Create the twsi device option in preparation to move the driver to a common location. The device is also found in Allwinner SoCs. Sponsored by: ABT Systems Ltd 295618 by cem: NTB: workaround for high traffic hardware hang This patch comes from Dave Jiang's Linux tree, davejiang/ntb. It hasn't been accepted into Linus' tree, so I do not have an authoritative SHA1 to point at. Original commit log: ===================================================================== A hardware errata causes the NTB to hang when heavy bi-directional traffic in addition to the usage of BAR0/1 (where the registers reside, including the doorbell registers to trigger interrupts). This workaround is only available on Haswell and Broadwell platform. The workaround is to enable split BAR in the BIOS to allow the 64bit BAR4 to be split into two 32bit BAR4 and BAR5. The BAR4 shall be pointed to LAPIC region of the remote host. We will bypass the db mechanism and directly trigger the MSIX interrupts. The offsets and vectors are exchanged during transport scratch pad negotiation. The scratch pads are now overloaded in order to allow the exchange of the information. This gets around using the doorbell and prevents the lockup with additional pcode changes in BIOS. Signed-off-by: Dave Jiang ===================================================================== Notable changes in the FreeBSD version of this patch: * The MSIX BAR is configurable, like hw.ntb.b2b_mw_idx (msix_mw_idx). The Linux version of the patch only uses BAR4. * MSIX negotiation aborts if the link goes down. Obtained from: Linux (Dual BSD/GPL driver) Sponsored by: EMC / Isilon Storage Division 295616 by pfg: ext2fs: Remove panics for rename() race conditions. Sync with r84642 from UFS: The panics are inappropriate because the IN_RENAME flag only fixes a few of the huge number of race conditions that can result in the source path becoming invalid even prior to the VOP_RENAME() call. Found accidentally while checking an issue from PVS Static Analysis. MFC after: 3 days 295612 by andrew: Remove an unused include. 295611 by hselasky: Restore maximum number of host keys to 64. Discussed with: adrian @ and avos @ 295610 by kevlo: Fix a bug that caused nothing to be skipped when skipping exactly the number of bytes present in a regular file was requested. Obtained from: OpenBSD 295609 by cperciva: Don't dereference a pointer immediately after determining that it is equal to NULL. [1] While I'm here, s/xb/xbd/ (the name changed a long time ago but this instance wasn't corrected). Reported by: PVS-Studio [1] 295608 by hselasky: Fix variable assignment inside if-clause in the smsc driver. Found by D5245 / PVS. MFC after: 1 week 295607 by hselasky: Reduce the number of supported WLAN keys in the rum driver, else we risk bit shifting overflows. Found by D5245 / PVS. MFC after: 1 week 295606 by sephe: hyperv/hn: Fix typo in comment Noticed by: avos Reviewed by: adrian, avos, Hongjiang Zhang Approved by: adrian MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5199 295605 by cem: ioat(4): On error detected in ithread, defer HW reset to taskqueue The I/OAT HW reset process may sleep, so it is invalid to perform a channel reset from the software interrupt thread. Sponsored by: EMC / Isilon Storage Division 295604 by cem: ioat(4): Also check for errors if the channel is suspended Sponsored by: EMC / Isilon Storage Division 295603 by cem: ioat(4): Decode/define more capabilities, operations These are defined in the Intel Haswell EDS volume 2 (registers) (507849 v2.1). Sponsored by: EMC / Isilon Storage Division 295602 by kib: Hide ucontext_t and mcontext_t when neither POSIX nor XSI features are enabled in the compilation environment, i.e. for ANSI C use of #include . Requested and reviewed by: bde Sponsored by: The FreeBSD Foundation MFC after: 13 days 295588 by cem: ioat(4): Recheck status register on zero-descriptor wakeups Errors that halt the channel don't necessarily result in a completion update, apparently. Sponsored by: EMC / Isilon Storage Division 295587 by dteske: Fix missing description for command usage While "jng" or "jib" without arguments told you what each sub-command does, sub-command usage didn't tell you (e.g., "jng bridge" or "jib addm" gave only usage and not description). 295586 by pfg: cd9660: More "check for NULL" cleaunps. Cleanup some checks for NULL. Most of these were always unnecessary and starting with r294954 brelse() doesn't need any NULL checks at all. For now keep the checks somewhat consistent with NetBSD in case we want to merge the cleanups to older versions. 295584 by markj: Add a missing newline to a log message. MFC after: 1 week 295583 by markj: Rename the flags field of struct nd_defrouter to "raflags". This field contains the flags inherited from the corresponding router advertisement message and is not for storing private state. MFC after: 1 week 295582 by emaste: elfcopy: enable PE and EFI support Sponsored by: The FreeBSD Foundation 295581 by emaste: Add libpe for elfcopy(1) PE/COFF support Sponsored by: The FreeBSD Foundation 295580 by markj: Simplify defrtrlist_update() slightly in preparation for future changes. No functional change intended. MFC after: 1 week 295579 by markj: Remove a bogus comment from nd6_na_input(). The splnet() call that it refers to has been removed, and a lock for the default router list is in fact needed. MFC after: 1 week 295578 by markj: Remove superfluous return statements from the neighbour discovery code. MFC after: 1 week 295577 by emaste: Update ELF Tool Chain to upstream rev 3400 Some notable improvements include: readelf: - Add AArch64 relocation definitions. - Report value of unknown relocation types. elfcopy: - Consider symbols with STB_GNU_UNIQUE binding as global symbols. - Fixed support for VMA adjustment for loadable sections found in relocatable objects. - Handle nameless global symbols. - Improve wildcard matching for !-prefixed symbols. - Add PE/COFF support. elfdump: - Improve section type reporting. - Add MIPS-specific section types. This update also includes a significant number of bug fixes. PR: 207091 [exp-run] Sponsored by: The FreeBSD Foundation 295576 by markj: Fix style around allocations from M_IP6NDP. - Don't cast the return value of malloc(9). - Use M_ZERO instead of explicitly calling bzero(9). MFC after: 1 week 295575 by markj: Remove some unreferenced NDP debug variable definitions. MFC after: 1 week 295574 by markj: Clear the cookie pointer on error in tmpfs_readdir(). It is otherwise left dangling, and callers that request cookies always free the cookie buffer, even when VOP_READDIR(9) returns an error. This results in a double free if tmpfs_readdir() returns an error to the NFS server or the Linux getdents(2) emulation code. Reported by: pho MFC after: 1 week Security: double free of malloc(9)-backed memory Sponsored by: EMC / Isilon Storage Division 295573 by np: Remove duplicate definition (CPL_TRACE_PKT_T5). 295568 by feld: Document the new jail_reverse_stop parameter While here clean up the documentation for jail_list PR: 196152 Approved by: jamie, wblock MFC after: 1 week, with r295471 Differential Revision: https://reviews.freebsd.org/D5243 295567 by andrew: Stop adding an extra null terminator to strings, OF_getprop already returns a null terminated string. 295566 by bjk: Update .Dd for r295565 295565 by ian: Clarify the difference between 7- and 8-bit i2c addresses, used in FDT versus hints-based configuration, respectively. Reported by: Jukka Ukkonen 295564 by br: Use __uint64_t type for floating point registers as compiler don't know about __uint128_t yet. Discussed with: theraven, kib 295563 by andrew: Only update curthread and curpcb after we have finished using the old values. If switching from a thread that used floating-point registers to a thread that is still running, but holding the blocked_lock lock we would switch the curthread to the new (running) thread, then call critical_enter. This will non-atomically increment td_critnest, and later call critical_exit to non-atomically decrement this value. This can happen at the same time as the new thread is still running on the old core, also calling these functions. In this case there will be a race between these non-atomic operations. This can be an issue as we could loose one of these operations leading to the value to not return to zero. If, later on, we then hit a data abort we check if the td_critnest is zero. If this check fails we will panic the kernel. This has been observed when running pcmstat on a Cavium ThunderX. The pcm thread will use the blocked_lock lock and there is a high chance userspace will use the floating-point registers. When, later on, pmcstat triggers a data abort we will hit this panic. The fix is to update these values after storing the floating-point state. This means we use the correct curthread while storing the state so it will not be an issue that the changes to td_critnest are non-atomic. Sponsored by: ABT Systems Ltd 295562 by mav: Don't check CmdSN for initial login request. This fixes connection errors for some initiators not starting CmdSN from zero. While there, fix wrong status details reported for couple errors. MFC after: 3 days 295561 by kib: POSIX states that #include shall make both mcontext_t and ucontext_t available. Our code even has XXX comment about this. Add a bit of compliance by moving struct __ucontext definition into sys/_ucontext.h and including it into signal.h and sys/ucontext.h. Several machine/ucontext.h headers were changed to use namespace-safe types (like uint64_t->__uint64_t) to not depend on sys/types.h. struct __stack_t from sys/signal.h is made always visible in private namespace to satisfy sys/_ucontext.h requirements. Apparently mips _types.h pollutes global namespace with f_register_t type definition. This commit does not try to fix the issue. PR: 207079 Reported and tested by: Ting-Wei Lan Sponsored by: The FreeBSD Foundation MFC after: 2 weeks 295560 by kib: If full width writes to the performance monitoring counters are supported, use full-width aliases MSRs for writes. This fixes the "[pmc,X] negative increment" assertion on the context switch when clipped counter value is sign-extended. Add definitions for the MSR IA32_PERF_CAPABILITIES needed to detect the feature. PR: 207068 Submitted by: joss.upton@yahoo.com MFC after: 2 weeks 295559 by kib: Adjust the size of PMC_DEFAULT_DEBUG_FLAGS to match the size of the structure. PR: 207068 Submitted by: joss.upton@yahoo.com MFC after: 2 weeks 295558 by kib: Remove tautological cast. PR: 207068 Submitted by: joss.upton@yahoo.com MFC after: 2 weeks 295557 by mmel: UART: Fix spurious interrupts generated by ns8250 and lpc drivers: - don't enable transmitter empty interrupt before filling TX FIFO. - add missing uart_barrier() call in interrupt service routine 295556 by dteske: Comments and fix small bug Reduce differences between jib/jng and fix a bug that would prevent additional interfaces from being created if the first of many already existed (counter wasn't incremented before calling only continue). 295555 by dteske: Interpret vnet_interface/vnet.interface as array 295554 by dteske: Add syntax to disable MAC allocation Adding `!' before an interface name will disable MAC allocation, falling back to driver mechanics. Alternatively adding `=' before an interface name causes the MAC address to be cloned (for ng_bridge(4) back-end only). While here, disable the auto-detection of wlan* since this knocks the host off; requiring the host that defines the jail to explicitly enable this feature by preceding the interface with `='. 295553 by dteske: Refactor conversion to hex 295549 by tuexen: Loopback addresses are 127.0.0.0/8, not 127.0.0.1/32. MFC after: 1 week 295548 by dteske: Add support for bridging iwn(4) based wlan(4) Documented in iwn(4), "Only one virtual interface may be configured at any time." However, netgraph with a cloned MAC address is able to communicate over an ng_eiface attached to an ng_bridge linked to the wlan(4) interface. While here, introduce syntax to specify the MAC address is to be cloned if the named interface begins with equals [=]. 295547 by glebius: o Gather all mbuf(9) allocation functions into kern_mbuf.c, and all mbuf(9) manipulation functions into uipc_mbuf.c. This looks like the initial intent, but had diffused in the last decade. o Gather all declarations in mbuf.h in one place and sort them. o Uninline m_clget() and m_cljget(). There are no functional changes in this patch. The patch comes from a larger version, where all mbuf(9) allocation was uninlined, which allowed to make mbuf(9) UMA zones private to kern_mbuf.c. The performance impact of the total uninlining is still unclear, so we are holding on now with larger version. Together with: melifaro, olivier 295546 by dteske: Centralize MAC derivation formula 295542 by dteske: Add example VIMAGE config required by vnet jails 295541 by tuexen: Use 4 spaces instead of a tab. 295540 by andrew: Enable ARM_INTRNG on all kernel configs where we use the Generic Interrupt Controller. Sponsored by: ABT Systems Ltd 295536 by des: Fix double-free error: r289419 moved all error handling in http_connect() to the end of the function, but did not remove a fetch_close() call which was made redundant by the one in the shared error-handling code. PR: 206774 Submitted by: Christian Heckendorf MFC after: 3 days 295535 by des: Use the new insecure-lan-zones option instead of listing each AS112 zone separately. MFC after: 3 days 295533 by des: Remove unbound-contrl-setup since we use a local control socket which does not require keys. MFC after: 3 days Relnotes: yes 295532 by jimharris: nvme: avoid duplicate SET_NUM_QUEUES commands nvme(4) issues a SET_NUM_QUEUES command during device initialization to ensure enough I/O queues exists for each of the MSI-X vectors we have allocated. The SET_NUM_QUEUES command is then issued again during nvme_ctrlr_start(), to ensure that is properly set after any controller reset. At least one NVMe drive exists which fails this second SET_NUM_QUEUES command during device initialization. So change nvme_ctrlr_start() to only issue its SET_NUM_QUEUES command when it is coming out of a reset - avoiding the duplicate SET_NUM_QUEUES during device initialization. Reported by: gallatin MFC after: 3 days Sponsored by: Intel 295529 by dteske: Merge SVN r295220 (bz) from projects/vnet/ Fix a panic that occurs when a vnet interface is unavailable at the time the vnet jail referencing said interface is stopped. Sponsored by: FIS Global, Inc. 295527 by andrew: Include the correct header to get a phandle_t needed by ofw_bus_if.h. While here only include opt_platform.h once. Sponsored by: ABT Systems Ltd 295523 by pfg: Ext4: Use boolean type instead of '0' and '1' There are precedents of uses of bool in the kernel and it is incorrect style to use integers as replacement for a boolean type. 295522 by emaste: Explain that boot1.efi prefers ZFS over UFS Reported by: smh 295521 by br: o Move non-generic kernel configuration out from GENERIC. o Add kernel configuration for QEMU. Both SPIKE and QEMU kernel configs are temporary (until we will be able to obtain DTB from loader). Sponsored by: DARPA, AFRL Sponsored by: HEIF5 295520 by jhibbits: Migrate the PTE format for book-e to standardize on the 'indirect PTE' format Summary: The revised Book-E spec, adding the specification for the MMUv2 and e6500, includes a hardware PTE layout for indirect page tables. In order to support this in the future, migrate the PTE format to match the MMUv2 hardware PTE format. Test Plan: Boot tested on a P5020 board. Booted to multiuser mode. Differential Revision: https://reviews.freebsd.org/D5224 295519 by zbb: Support interrupts binding in GICv3 and ITS - Add MOVI command and routine for the LPI migration - Allow to search for the ITS device descriptor using not only devID but also LPI number. - Bind SPIs in the Distributor - Don't bind its_dev to collection. Keep track of the collection IDs for each LPI. Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5231 295518 by zbb: Implement finer locking in ITS - Change locks' names to be more suitable - Don't use blocking mutex. Lock only basic operations such as lists or bitmaps modifications. Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5230 295517 by zbb: Initially bind all interrupts to the boot CPU when using GICv3 This should be done by routing all interrupts to CPU0, different assignment will be induced by either interrupts shuffling or bus_bind_intr(). Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5229 295516 by zbb: Call pmc_hook() correctly in the ARM64 interrupt handler pmc_hook() was called only in case of the stray interrupt but should rather be called on each interrupt. Move in to the arm_cpu_intr() handler, out of the critical section too. Reviewed by: br Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5161 295515 by zbb: Introduce bus_bind_intr method for ARM64 It can be used to bind specific interrupt to a particular CPU. Requires PIC support for interrupts binding. Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5122 295514 by zbb: Fix bugs in interrupts allocation on ARM64 Separate interrupt descriptors lookup from allocation. It was possible to perform config on non-existing interrupt simply by allocating spurious descriptor. Must lock the interrupt descriptors table lookup to avoid mismatches. This ought to prevent trouble while setting up new interrupt and dispatching existing one. Use spin mutex rather than sleep mutex. This is mainly due to lock in arm_dispatch_intr. This should be eventually changed to a lock-less solution without walking through a linked list on each interrupt. Reviewed by: andrew, wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5121 295513 by royger: xen-netfront: remove useless NULL check in netif_free xn_ifp is allocated in create_netdev with if_alloc(IFT_ETHER). According to the current arrangement it can't be NULL. Coverity ID: 1349805 Submitted by: Wei Liu Reviewed by: royger Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D5252 295512 by zbb: Minor clean-ups for ARM64 GICv3 and GIC drivers GICv3: - move ICC_SGI1R_EL1 definitions to armreg.h and use proper system register's names GIC: - remove unused functions Reviewed by: andrew Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5119 295511 by royger: xen-netfront: rearrange error paths in setup_txqs Coverity spotted double free errors in error path. Fix that by removing the extraneous calls. Coverity ID: 1349798 Submitted by: Wei Liu Reviewed by: royger Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D5251 295510 by royger: xen-netfront: remove pointless assignment in xn_ioctl The variable error is assigned to 0 before entering the switch. Assigning error to 0 before break pointless rewrites the real error value that should be returned. Coverity ID: 1304974 Submitted by: Wei Liu Reviewed by: royger Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D5250 295509 by andrew: Stop defining fdt_pic_table when building for ARM_INTRNG. 295508 by br: Stop device enumeration when we see first empty slot. This fixes operation in QEMU and saves some booting time as well. Pointed out by: Sagar Karandikar Sponsored by: DARPA, AFRL Sponsored by: HEIF5 295507 by andrew: Remove unused Zedboard config files. files.zedboard was empty other than comments, and std.zedboard just pointed to files.zedboard and std.xilinx. 295506 by hselasky: Use a pair of ifs when comparing the 32-bit flowid integers so that the sign bit doesn't cause an overflow. The overflow manifests itself as a sorting index wrap around in the middle of the sorted array, which is not a problem for the LRO code, but might be a problem for the logic inside qsort(). Reviewed by: gnn @ Sponsored by: Mellanox Technologies Differential Revision: https://reviews.freebsd.org/D5239 295505 by wma: ARM64 disassembler: support for LDR instructions Implemented disassembly for a whole bunch of various ldr instructions. Obtained from: Semihalf Sponsored by: Cavium Approved by: cognet (mentor) Reviewed by: zbb Differential revision: https://reviews.freebsd.org/D5217 295504 by adrian: Make bus_space_generic properly map/unmap memory (using pmap_mapdev and pmap_unmapdev respectively) so that resources are properly managed. This is work originally done by kan@. Stanislav picked it up as part of his Mediatek SoC work. Tested: * Carambola2, AR933x SoC Submitted by: Stanislav Galabov Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5184 295503 by adrian: Migrate the other MIPS24K SoC cores to use the CPU_MIPS24K option. 295502 by adrian: Missing commit - remove MIPS fdt bus space. Differential Revision: https://reviews.freebsd.org/D5184 295501 by adrian: Remove bus space fdt for MIPS. This was originall done by kan@. Submitted by: Stanislav Galabov Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5184 295500 by adrian: Convert MIPS nexus and mips_pic to BUS_PASS Submitted by: Stanislav Galabov Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5196 295499 by adrian: Teach the MIPS ticker to attach itself properly when using INTRNG. Submitted by: Stanislav Galabov Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5183 295498 by adrian: Begin the MIPS_INTRNG support. This is a prelude to intr-ng support for MIPS boards that need it - notably the CI20 port from kan@ that's upcoming, but also work that Stanislav is doing for the Mediatek platforms. This is the initial platform dependent bits in include/intr.h, some #defines for the nexus code for the intrng initialisation/runtime bits, some changed naming (which I'll fix later to be the same, much like what I did for ARM intr-ng) in exception.S, and the first cut at a PIC. Stanislav and I refactored out the common code for intrng support, so the mips intrng definitions are quite small (sys/mips/include/intr.h.) This is all work done by kan@, which stanislav has been cherry picking into common code for his mediatek chipset work. Tested: * Carambola2 - no regressions (not intr-ng though!) Submitted by: Stanislav Galabov Reviewed by: kan (original author) Differential Revision: https://reviews.freebsd.org/D5182 295497 by emaste: Update uefi.8 for ZFS and multi device boot support As of r294068 boot1.efi can load loader.efi from ZFS. As of r295320 boot1.efi prefers to load loader.efi from the same device it was loaded from. MFC after: 3 days Sponsored by: The FreeBSD Foundation 295496 by emaste: Document boot1.efi's handling of /boot.config, added in r294768 MFC after: 3 days Sponsored by: The FreeBSD Foundation 295495 by cy: Update leapsecond file in non-chroot environments. PR: 207095 Submitted by: madpilot MFC after: 3 days The end of the build log: [...truncated 83381 lines...] ===> usr.bin/bmake/tests/shell/path_select (depend) --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_suffixes --- --- depend_subdir_basic --- ===> usr.bin/bmake/tests/suffixes/basic (depend) --- depend_subdir_usr.sbin --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/wire.c:57: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_shell --- --- depend_subdir_replace --- ===> usr.bin/bmake/tests/shell/replace (depend) --- depend_subdir_suffixes --- --- depend_subdir_src_wild1 --- ===> usr.bin/bmake/tests/suffixes/src_wild1 (depend) --- depend_subdir_shell --- --- depend_subdir_select --- ===> usr.bin/bmake/tests/shell/select (depend) --- depend_subdir_suffixes --- --- depend_subdir_src_wild2 --- --- depend_subdir_dc --- --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_bmake --- ===> usr.bin/bmake/tests/suffixes/src_wild2 (depend) --- depend_subdir_dc --- ===> usr.bin/dc (depend) --- depend_subdir_usr.sbin --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_bmake --- --- depend_subdir_syntax --- ===> usr.bin/bmake/tests/syntax (depend) --- depend_subdir_dc --- --- .depend --- rm -f .depend --- depend_subdir_bmake --- --- depend_subdir_directive-t0 --- ===> usr.bin/bmake/tests/syntax/directive-t0 (depend) --- depend_subdir_dc --- CC='cc' mkdep -f .depend -a -std=gnu99 /usr/src/usr.bin/dc/dc.c /usr/src/usr.bin/dc/bcode.c /usr/src/usr.bin/dc/inout.c /usr/src/usr.bin/dc/mem.c /usr/src/usr.bin/dc/stack.c --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_bmake --- --- depend_subdir_enl --- ===> usr.bin/bmake/tests/syntax/enl (depend) --- depend_subdir_usr.sbin --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/transp/transp_sockets.c:47: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_funny-targets --- ===> usr.bin/bmake/tests/syntax/funny-targets (depend) --- depend_subdir_semi --- ===> usr.bin/bmake/tests/syntax/semi (depend) --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_sysmk --- ===> usr.bin/bmake/tests/sysmk (depend) --- depend_subdir_usr.sbin --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab/mtab_bsd.c:51: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_t0 --- ===> usr.bin/bmake/tests/sysmk/t0 (depend) --- depend_subdir_mk --- ===> usr.bin/bmake/tests/sysmk/t0/mk (depend) --- depend_subdir_2 --- ===> usr.bin/bmake/tests/sysmk/t0/2 (depend) --- depend_subdir_1 --- ===> usr.bin/bmake/tests/sysmk/t0/2/1 (depend) --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_t1 --- ===> usr.bin/bmake/tests/sysmk/t1 (depend) --- depend_subdir_usr.sbin --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_mk --- ===> usr.bin/bmake/tests/sysmk/t1/mk (depend) --- depend_subdir_2 --- ===> usr.bin/bmake/tests/sysmk/t1/2 (depend) --- depend_subdir_1 --- ===> usr.bin/bmake/tests/sysmk/t1/2/1 (depend) --- depend_subdir_usr.sbin --- 1 error generated. --- depend_subdir_usr.bin --- --- depend_subdir_t2 --- ===> usr.bin/bmake/tests/sysmk/t2 (depend) --- depend_subdir_mk --- ===> usr.bin/bmake/tests/sysmk/t2/mk (depend) --- depend_subdir_dc --- echo dc.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend --- depend_subdir_bmake --- --- depend_subdir_2 --- ===> usr.bin/bmake/tests/sysmk/t2/2 (depend) --- depend_subdir_variables --- ===> usr.bin/bmake/tests/variables (depend) --- depend_subdir_sysmk --- --- depend_subdir_1 --- ===> usr.bin/bmake/tests/sysmk/t2/2/1 (depend) --- depend_subdir_usr.sbin --- In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_variables --- --- depend_subdir_modifier_M --- ===> usr.bin/bmake/tests/variables/modifier_M (depend) --- depend_subdir_newkey --- ===> usr.bin/newkey (depend) --- depend_subdir_bmake --- --- depend_subdir_modifier_t --- ===> usr.bin/bmake/tests/variables/modifier_t (depend) --- depend_subdir_usr.sbin --- 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error make[5]: stopped in /usr/src/usr.sbin/amd/libamu --- depend_subdir_usr.bin --- --- depend_subdir_newkey --- --- .depend --- --- depend_subdir_usr.sbin --- *** [depend_subdir_libamu] Error code 2 make[4]: stopped in /usr/src/usr.sbin/amd 1 error make[4]: stopped in /usr/src/usr.sbin/amd *** [depend_subdir_amd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_usr.bin --- rm -f .depend CC='cc' mkdep -f .depend -a -DYP -std=gnu99 /usr/src/usr.bin/newkey/newkey.c /usr/src/usr.bin/newkey/generic.c /usr/src/usr.bin/newkey/update.c --- depend_subdir_bmake --- A failure has been detected in another branch of the parallel make make[7]: stopped in /usr/src/usr.bin/bmake/tests/variables/modifier_t *** [depend_subdir_modifier_t] Error code 2 make[6]: stopped in /usr/src/usr.bin/bmake/tests/variables 1 error make[6]: stopped in /usr/src/usr.bin/bmake/tests/variables *** [depend_subdir_variables] Error code 2 make[5]: stopped in /usr/src/usr.bin/bmake/tests 1 error make[5]: stopped in /usr/src/usr.bin/bmake/tests *** [depend] Error code 2 make[4]: stopped in /usr/src/usr.bin/bmake 1 error make[4]: stopped in /usr/src/usr.bin/bmake *** [depend_subdir_bmake] Error code 2 make[3]: stopped in /usr/src/usr.bin --- depend_subdir_newkey --- echo newkey.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/librpcsvc.a /usr/obj/usr/src/tmp/usr/lib/libmp.a >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.bin/newkey *** [depend_subdir_newkey] Error code 2 make[3]: stopped in /usr/src/usr.bin 2 errors make[3]: stopped in /usr/src/usr.bin *** [depend_subdir_usr.bin] Error code 2 make[2]: stopped in /usr/src --- depend_subdir_usr.sbin --- --- depend_subdir_tcpdump --- echo tcpdump.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpcap.a /usr/obj/usr/src/tmp/usr/lib/libcapsicum.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** [depend] Error code 2 make[4]: stopped in /usr/src/usr.sbin/tcpdump 1 error make[4]: stopped in /usr/src/usr.sbin/tcpdump *** [depend_subdir_tcpdump] Error code 2 make[3]: stopped in /usr/src/usr.sbin 2 errors make[3]: stopped in /usr/src/usr.sbin *** [depend_subdir_usr.sbin] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_depend] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson7985524070429360485.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Feb 16 14:00:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00596AAAA82; Tue, 16 Feb 2016 14:00:42 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E66681A7C; Tue, 16 Feb 2016 14:00:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EF4671D2A; Tue, 16 Feb 2016 14:00:41 +0000 (UTC) Date: Tue, 16 Feb 2016 14:00:40 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: skra@FreeBSD.org, andrew@FreeBSD.org, zbb@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <203857527.9.1455631241944.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1787093706.5.1455624049169.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1787093706.5.1455624049169.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2351 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:00:42 -0000 FreeBSD_HEAD_i386 - Build #2351 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2351/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2351/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2351/cons= ole Change summaries: 295659 by skra: Do not use DMA channels used by GPU. (1) The channel mask is get from "brcm,dma-channel-mask" property of dma node, and if not provided, from "broadcom,channels" property. (2) Consequently, sdhci driver does not allocate any specific channel. (3) Use CS_RESET bit for initial channel reset. Differential Revision: https://reviews.freebsd.org/D4303 295658 by andrew: Add a sysctl to read the internal temperature of the AXP209 Power Management IC. Submitted by:=09Jared McNeill Differential Revision:=09https://reviews.freebsd.org/D5298 295657 by andrew: Add an analog audio driver for the audio codec found on the Allwinner A10/A20 SoC. Based loosely on the submitters NetBSD driver, tested on Cubieboard 2. Playback and capture are supported. Submitted by:=09Jared McNeill Differential Revision:=09https://reviews.freebsd.org/D5202 295656 by zbb: Support PEM that is not a PCI endpoint on ThunderX Some chip revisions don't have their external PCIe buses behind the internal bridge. Add support for FDT-configurable PEMs but keep ability for PCIe enumeration. Reviewed by: andrew, wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5285 295655 by skra: Temporary overwrite bad definition of elm interrupt property in Linux dts files. It may be removed once it will be fixed upstream. This is done just to supresses a warning during dtb evaluation as there is no elm driver in tree at present. The end of the build log: [...truncated 83571 lines...] CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.sbin/sa/main= .c /usr/src/usr.sbin/sa/db.c /usr/src/usr.sbin/sa/pdb.c /usr/src/usr.sbin/s= a/usrdb.c /usr/src/usr.sbin/sa/../../usr.bin/lastcomm/readrec.c --- depend_subdir_usr.bin --- --- depend_subdir_kdump --- --- kdump_subr.c --- sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include >kdump_su= br.c --- depend_subdir_usr.sbin --- echo sa.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend --- =3D=3D=3D> usr.sbin/sa/tests (depend) --- depend_subdir_usr.bin --- --- depend_subdir_truss --- =3D=3D=3D> usr.bin/truss (depend) --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/truss -I. -I/usr/src/us= r.bin/truss/../../sys -std=3Dgnu99 /usr/src/usr.bin/truss/cloudabi.c /us= r/src/usr.bin/truss/main.c /usr/src/usr.bin/truss/setup.c /usr/src/usr.bin/= truss/syscalls.c /usr/src/usr.bin/truss/i386-freebsd.c /usr/src/usr.bin/tru= ss/i386-linux.c --- depend_subdir_kdump --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/kdump/../ktrace -I/usr/= src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -I. -DHAVE_LIBCAPSICUM -st= d=3Dgnu99 kdump_subr.c /usr/src/usr.bin/kdump/kdump.c /usr/src/usr.bin/k= dump/../ktrace/subr.c --- depend_subdir_truss --- echo truss.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libsysdecode.a >> .depend --- depend_subdir_compile_et --- =3D=3D=3D> usr.bin/compile_et (depend) --- parse.c --- yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.= y --- lex.c --- lex -olex.c /usr/src/usr.bin/compile_et/../../contrib/com_err/lex.l --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I. -I/usr/src/usr.bin/compile_et/../../co= ntrib/com_err -std=3Dgnu99 /usr/src/usr.bin/compile_et/../../contrib/com= _err/compile_et.c parse.c lex.c --- depend_subdir_kdump --- echo kdump.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libsysdecode.a /usr/obj/usr/src/tmp/usr/lib/libcapsicum.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_amd --- =3D=3D=3D> usr.sbin/amd (depend) --- depend_subdir_include --- =3D=3D=3D> usr.sbin/amd/include (depend) --- depend_subdir_libamu --- =3D=3D=3D> usr.sbin/amd/libamu (depend) --- depend_subdir_usr.bin --- --- depend_subdir_compile_et --- echo compile_et.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/= tmp/usr/lib/libroken.a /usr/obj/usr/src/kerberos5/lib/libvers/libvers.a >> = .depend --- depend_subdir_drill --- =3D=3D=3D> usr.bin/drill (depend) --- depend_subdir_usr.sbin --- --- nfs_prot_x.c --- RPCGEN_CPP=3Dcpp\ rpcgen -c -C -DWANT_NFS3 /usr/obj/usr/src/tmp/usr/includ= e/rpcsvc/nfs_prot.x -o nfs_prot_x.c --- depend_subdir_usr.bin --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/drill/../../contrib/ldn= s -std=3Dgnu99 /usr/src/usr.bin/drill/../../contrib/ldns/drill/drill.c /= usr/src/usr.bin/drill/../../contrib/ldns/drill/drill_util.c /usr/src/usr.bi= n/drill/../../contrib/ldns/drill/error.c /usr/src/usr.bin/drill/../../contr= ib/ldns/drill/root.c /usr/src/usr.bin/drill/../../contrib/ldns/drill/work.c= /usr/src/usr.bin/drill/../../contrib/ldns/drill/chasetrace.c /usr/src/usr.= bin/drill/../../contrib/ldns/drill/dnssec.c /usr/src/usr.bin/drill/../../co= ntrib/ldns/drill/securetrace.c --- depend_subdir_usr.sbin --- --- xdr_func_%undef.c --- unifdef -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS -DHAVE_XDR_DIRLIST -DHAVE= _XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES -DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH= -DHAVE_XDR_ENTRY -DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR= -DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME -DHAVE_XDR_FTYP= E -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS -DHAVE_XDR_LINKARGS -DHAVE_XDR_MOU= NTBODY -DHAVE_XDR_MOUNTLIST -DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NF= SCOOKIE -DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME -DHAVE_XDR= _POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS -DHAVE_XDR_READDIRRES -= DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES -DHAVE_XDR_READRES -DHAVE_XDR_RE= NAMEARGS -DHAVE_XDR_SATTR -DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAV= E_XDR_STATFSRES -DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS < /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/xdr_func.c > xdr_func_%undef.c --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/amd/libamu/../../../co= ntrib/amd/libamu -I/usr/obj/usr/src/tmp/usr/include/rpcsvc -I. -I/usr/src/u= sr.sbin/amd/libamu -I/usr/src/usr.sbin/amd/libamu/../include -I/usr/obj/usr= /src/usr.sbin/amd/libamu/../include -I/usr/src/usr.sbin/amd/libamu/../../..= /contrib/amd/include -I/usr/src/usr.sbin/amd/libamu/../../../contrib/amd -D= HAVE_CONFIG_H -DHOST_CPU=3D\"i386\" -DHOST_ARCH=3D\"i386\" -std=3Dgnu99 = /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/hasmntopt.c /usr/s= rc/usr.sbin/amd/libamu/../../../contrib/amd/libamu/misc_rpc.c /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/mount_fs.c /usr/src/usr.sbin/am= d/libamu/../../../contrib/amd/libamu/mtab.c /usr/src/usr.sbin/amd/libamu/..= /../../contrib/amd/libamu/nfs_prot_xdr.c /usr/src/usr.sbin/amd/libamu/../..= /../contrib/amd/libamu/strutil.c /usr/src/usr.sbin/amd/libamu/../../../cont= rib/amd/libamu/wire.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/transp/t= ransp_sockets.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab= /mtab_bsd.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/u= mount_bsd44.c nfs_prot_x.c xdr_func_%undef.c In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/hasmntopt.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/misc_rpc.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mount_fs.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mtab.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/nfs_prot_xdr.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/strutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/wire.c:57: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. --- depend_subdir_usr.bin --- echo drill.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libprivateldns.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_audit --- =3D=3D=3D> usr.sbin/audit (depend) --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/transp/transp_sockets.c:47: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_audit --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/audit/../../contrib/op= enbsm -std=3Dgnu99 /usr/src/usr.sbin/audit/../../contrib/openbsm/bin/aud= it/audit.c --- depend_subdir_amd --- 1 error generated. --- depend_subdir_audit --- echo audit.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libbsm.a >> .depend --- depend_subdir_amd --- In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/mtab/mtab_bsd.c:51: --- depend_subdir_usr.bin --- --- depend_subdir_host --- --- depend_subdir_usr.sbin --- /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- =3D=3D=3D> usr.bin/host (depend) --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/host/../../contrib/ldns= -std=3Dgnu99 /usr/src/usr.bin/host/../../contrib/ldns-host/ldns-host.c --- depend_subdir_usr.sbin --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. --- depend_subdir_usr.bin --- echo host.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/us= r/lib/libprivateldns.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_auditd --- =3D=3D=3D> usr.sbin/auditd (depend) --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/auditd/../../contrib/o= penbsm -std=3Dgnu99 /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/a= uditd/auditd.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/au= dit_warn.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/auditd= _fbsd.c --- depend_subdir_amd --- In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error make[5]: stopped in /usr/src/usr.sbin/amd/libamu *** [depend_subdir_libamu] Error code 2 make[4]: stopped in /usr/src/usr.sbin/amd 1 error make[4]: stopped in /usr/src/usr.sbin/amd *** [depend_subdir_amd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_auditd --- echo auditd.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/= usr/lib/libauditd.a /usr/obj/usr/src/tmp/usr/lib/libbsm.a >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.sbin/auditd *** [depend_subdir_auditd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_usr.bin --- --- depend_subdir_clang --- --- depend_subdir_tblgen --- echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/usr.= bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/= obj/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvms= upport.a /usr/obj/usr/src/tmp/usr/lib/libncursesw.a /usr/obj/usr/src/tmp/us= r/lib/libpthread.a >> .depend echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.bin/clang/tblgen *** [depend_subdir_tblgen] Error code 2 make[4]: stopped in /usr/src/usr.bin/clang 1 error make[4]: stopped in /usr/src/usr.bin/clang *** [depend_subdir_clang] Error code 2 make[3]: stopped in /usr/src/usr.bin 1 error make[3]: stopped in /usr/src/usr.bin *** [depend_subdir_usr.bin] Error code 2 make[2]: stopped in /usr/src --- depend_subdir_usr.sbin --- --- depend_subdir_tcpdump --- echo tcpdump.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp= /usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpcap.a /usr/obj/usr/src/tmp= /usr/lib/libcapsicum.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** [depend] Error code 2 make[4]: stopped in /usr/src/usr.sbin/tcpdump 1 error make[4]: stopped in /usr/src/usr.sbin/tcpdump *** [depend_subdir_tcpdump] Error code 2 make[3]: stopped in /usr/src/usr.sbin 3 errors make[3]: stopped in /usr/src/usr.sbin *** [depend_subdir_usr.sbin] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_depend] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson4703767091610572758.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Feb 16 15:02:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5291DAAAACF for ; Tue, 16 Feb 2016 15:02:52 +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 3F58365A for ; Tue, 16 Feb 2016 15:02:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3C702AAAACD; Tue, 16 Feb 2016 15:02:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C012AAAACC for ; Tue, 16 Feb 2016 15:02:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AB3C659 for ; Tue, 16 Feb 2016 15:02:51 +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 u1GF2oPf027924 for ; Tue, 16 Feb 2016 15:02:50 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u1GF2nRQ027923 for current@freebsd.org; Tue, 16 Feb 2016 07:02:49 -0800 (PST) (envelope-from david) Date: Tue, 16 Feb 2016 07:02:49 -0800 From: David Wolfskill To: current@freebsd.org Subject: Possible race condition noted r295622 -> r295654 Message-ID: <20160216150249.GT1178@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ScUgq5oMe+fJq4F1" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 16 Feb 2016 15:02:52 -0000 --ScUgq5oMe+fJq4F1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Given some of the reports of problems building head recently, my initial attempts this morning (upgrading head/amd64) in place from r295622 to r295654) were "clean" builds. My "build machine" reported no trouble (using -j16). On my laptop, also using -j16, the process terminated prematurely, with whines about inability to find libopythagoras. In a half-hearted attempt, I then immediately attempted an "unclean" build ("make -j 16 --DNO_CLEAN buildworld"); unsurprisingly, that failed. On a bit of a whim, I then tried "make -j14 buildworld" -- that succeeeded. I've placed a typescript of all of those efforts in -- ref "bw.txt" (or "bw.txt.gz"), in case that's of interest or use. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ScUgq5oMe+fJq4F1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWwzoZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X00QH/2qF9e7te0lvw6Yrtd2G867/ CV0lG+hDmmSypYmNAIKrHrfks/qur3d5nAzxtZCxu++HJgXBk9hpLgileU9NsgVJ qC55HJkwPDZrM9gC9OkobJCait37PDXqPk0/td1NgJXPPZu+hP2cmQRhS2NpZ/R1 QikohrVau2mZqZyOcTijInAkdX+7B3qwD+6i2focrCvzu4RDGq5NywDOq3QjnMG/ 9q0jxrYcxX3Ly3IAFWPEo741uR3+HW4a2O2Hv0JJGZGy2Jo1gQzAHm/MRPXcPolH SxLEalY7wkArFu0KivVWnvaNxej4bN/yvlIPKvfaoW++qC+NE2KRYuGVeKgYcgc= =ay55 -----END PGP SIGNATURE----- --ScUgq5oMe+fJq4F1-- From owner-freebsd-current@freebsd.org Tue Feb 16 16:01:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E932FAA9417; Tue, 16 Feb 2016 16:01:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D37921FB0; Tue, 16 Feb 2016 16:01:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 154B01D60; Tue, 16 Feb 2016 16:01:08 +0000 (UTC) Date: Tue, 16 Feb 2016 16:01:06 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, skra@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1485102190.13.1455638468052.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <203857527.9.1455631241944.JavaMail.jenkins@jenkins-9.freebsd.org> References: <203857527.9.1455631241944.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2352 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 16:01:08 -0000 FreeBSD_HEAD_i386 - Build #2352 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2352/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2352/cha= nges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2352/cons= ole Change summaries: 295661 by emaste: Allow elfcopy to convert between two non-ELF formats If the output object is not an ELF file, choose an arbitrary ELF format for the intermediate file. srec, ihex and binary formats are independent of class, endianness and machine type so these choices do not affect the output. ELF Tool Chain ticket #517 Reviewed by:=09kai Obtained from:=09ELF Tool Chain r3411 295660 by skra: Use EARLY_DRIVER_MODULE() for ti_scm driver to be attached before am335x_prcm driver which uses it. Used BUS_PASS_BUS is a quick pick for now and may be revised when other drivers start using multipass feature. This is needed after an update of Linux dts files done in r295436. The end of the build log: [...truncated 82035 lines...] tblgen -gen-opt-parser-defs -I /usr/src/usr.bin/clang/clang/../../../contr= ib/llvm/include -I /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools= /clang/include/clang/Driver -d Options.inc.d -o Options.inc.h /usr/src/us= r.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver/Op= tions.td --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/clang/clang/../../../co= ntrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/too= ls/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools= /clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llv= m/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_M= ACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_A= NALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"i386-unknown-freebsd11.0\" -DLLVM_= HOST_TRIPLE=3D\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -std= =3Dc++11 -stdlib=3Dlibc++ /usr/src/usr.bin/clang/clang/../../../contr= ib/llvm/tools/clang/tools/driver/cc1_main.cpp /usr/src/usr.bin/clang/clang/= ../../../contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp /usr/src/usr.= bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/driver.cpp= =20 --- depend_subdir_cpio --- echo bsdcpio_test.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/sr= c/tmp/usr/lib/libarchive.a >> .depend.bsdcpio_test --- depend_subdir_usr.sbin --- --- depend_subdir_sa --- =3D=3D=3D> usr.sbin/sa (depend) --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -std=3Dgnu99 /usr/src/usr.sbin/sa/main= .c /usr/src/usr.sbin/sa/db.c /usr/src/usr.sbin/sa/pdb.c /usr/src/usr.sbin/s= a/usrdb.c /usr/src/usr.sbin/sa/../../usr.bin/lastcomm/readrec.c echo sa.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend --- depend --- =3D=3D=3D> usr.sbin/sa/tests (depend) --- depend_subdir_usr.bin --- --- depend_subdir_clang --- --- depend_subdir_clang-tblgen --- echo clang-tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/sr= c/usr.bin/clang/clang-tblgen/../../../lib/clang/libllvmtablegen/libllvmtabl= egen.a /usr/obj/usr/src/usr.bin/clang/clang-tblgen/../../../lib/clang/libll= vmsupport/libllvmsupport.a /usr/obj/usr/src/tmp/usr/lib/libncursesw.a /usr/= obj/usr/src/tmp/usr/lib/libpthread.a >> .depend echo clang-tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend --- depend_subdir_tblgen --- =3D=3D=3D> usr.bin/clang/tblgen (depend) --- depend_subdir_usr.sbin --- --- depend_subdir_amd --- =3D=3D=3D> usr.sbin/amd (depend) --- depend_subdir_usr.bin --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.bin/clang/tblgen/../../../c= ontrib/llvm/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/t= ools/clang/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/ut= ils/TableGen -I. -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../.= ./lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZE= R -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"i386-unknown-freebsd11.0\" -DLLVM_HOST_T= RIPLE=3D\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -std=3Dc++11= -stdlib=3Dlibc++ /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm= /utils/TableGen/AsmMatcherEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../.= ./contrib/llvm/utils/TableGen/AsmWriterEmitter.cpp /usr/src/usr.bin/clang/t= blgen/../../../contrib/llvm/utils/TableGen/AsmWriterInst.cpp /usr/src/usr.b= in/clang/tblgen/../../../contrib/llvm/utils/TableGen/CTagsEmitter.cpp /usr/= src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CallingConvEm= itter.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGe= n/CodeEmitterGen.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/ut= ils/TableGen/CodeGenDAGPatterns.cpp /usr/src/usr.bin/clang/tblgen/../../../= contrib/llvm/utils/TableGen/CodeGenInstruction.cpp /usr/src/usr.bin/clang/t= blgen/../../../contrib/llvm/utils/TableGen/CodeGenMapTable.cpp /usr/src/usr= .bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGenRegisters.cpp= /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/CodeGen= Schedule.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/Tabl= eGen/CodeGenTarget.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/= utils/TableGen/DAGISelEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../../co= ntrib/llvm/utils/TableGen/DAGISelMatcher.cpp /usr/src/usr.bin/clang/tblgen/= ../../../contrib/llvm/utils/TableGen/DAGISelMatcherEmitter.cpp /usr/src/usr= .bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISelMatcherGen.cp= p /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/DAGISe= lMatcherOpt.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/T= ableGen/DFAPacketizerEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../../con= trib/llvm/utils/TableGen/DisassemblerEmitter.cpp /usr/src/usr.bin/clang/tbl= gen/../../../contrib/llvm/utils/TableGen/FastISelEmitter.cpp /usr/src/usr.b= in/clang/tblgen/../../../contrib/llvm/utils/TableGen/FixedLenDecoderEmitter= .cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/Ins= trInfoEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils= /TableGen/IntrinsicEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../../contr= ib/llvm/utils/TableGen/OptParserEmitter.cpp /usr/src/usr.bin/clang/tblgen/.= ./../../contrib/llvm/utils/TableGen/PseudoLoweringEmitter.cpp /usr/src/usr.= bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/RegisterInfoEmitter.c= pp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/Subta= rgetEmitter.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/T= ableGen/TableGen.cpp /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/ut= ils/TableGen/X86DisassemblerTables.cpp /usr/src/usr.bin/clang/tblgen/../../= ../contrib/llvm/utils/TableGen/X86ModRMFilters.cpp /usr/src/usr.bin/clang/t= blgen/../../../contrib/llvm/utils/TableGen/X86RecognizableInstr.cpp=20 --- depend_subdir_usr.sbin --- --- depend_subdir_include --- =3D=3D=3D> usr.sbin/amd/include (depend) --- depend_subdir_libamu --- =3D=3D=3D> usr.sbin/amd/libamu (depend) --- nfs_prot_x.c --- RPCGEN_CPP=3Dcpp\ rpcgen -c -C -DWANT_NFS3 /usr/obj/usr/src/tmp/usr/includ= e/rpcsvc/nfs_prot.x -o nfs_prot_x.c --- xdr_func_%undef.c --- unifdef -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS -DHAVE_XDR_DIRLIST -DHAVE= _XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES -DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH= -DHAVE_XDR_ENTRY -DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR= -DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME -DHAVE_XDR_FTYP= E -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS -DHAVE_XDR_LINKARGS -DHAVE_XDR_MOU= NTBODY -DHAVE_XDR_MOUNTLIST -DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NF= SCOOKIE -DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME -DHAVE_XDR= _POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS -DHAVE_XDR_READDIRRES -= DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES -DHAVE_XDR_READRES -DHAVE_XDR_RE= NAMEARGS -DHAVE_XDR_SATTR -DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAV= E_XDR_STATFSRES -DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS < /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/xdr_func.c > xdr_func_%undef.c --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/amd/libamu/../../../co= ntrib/amd/libamu -I/usr/obj/usr/src/tmp/usr/include/rpcsvc -I. -I/usr/src/u= sr.sbin/amd/libamu -I/usr/src/usr.sbin/amd/libamu/../include -I/usr/obj/usr= /src/usr.sbin/amd/libamu/../include -I/usr/src/usr.sbin/amd/libamu/../../..= /contrib/amd/include -I/usr/src/usr.sbin/amd/libamu/../../../contrib/amd -D= HAVE_CONFIG_H -DHOST_CPU=3D\"i386\" -DHOST_ARCH=3D\"i386\" -std=3Dgnu99 = /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/hasmntopt.c /usr/s= rc/usr.sbin/amd/libamu/../../../contrib/amd/libamu/misc_rpc.c /usr/src/usr.= sbin/amd/libamu/../../../contrib/amd/libamu/mount_fs.c /usr/src/usr.sbin/am= d/libamu/../../../contrib/amd/libamu/mtab.c /usr/src/usr.sbin/amd/libamu/..= /../../contrib/amd/libamu/nfs_prot_xdr.c /usr/src/usr.sbin/amd/libamu/../..= /../contrib/amd/libamu/strutil.c /usr/src/usr.sbin/amd/libamu/../../../cont= rib/amd/libamu/wire.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/transp/t= ransp_sockets.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab= /mtab_bsd.c /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/u= mount_bsd44.c nfs_prot_x.c xdr_func_%undef.c In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/hasmntopt.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/misc_rpc.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mount_fs.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- depend_subdir_clang --- echo clang.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/usr.b= in/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool= .a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend= /libclangfrontend.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang= /libclangdriver/libclangdriver.a /usr/obj/usr/src/usr.bin/clang/clang/../..= /../lib/clang/libclangserialization/libclangserialization.a /usr/obj/usr/sr= c/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a = /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libcl= angparse.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclang= sema/libclangsema.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang= /libclangrewritefrontend/libclangrewritefrontend.a /usr/obj/usr/src/usr.bin= /clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/obj/= usr/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzerfronte= nd/libclangstaticanalyzerfrontend.a /usr/obj/usr/src/usr.bin/clang/clang/..= /../../lib/clang/libclangstaticanalyzercheckers/libclangstaticanalyzercheck= ers.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangstati= canalyzercore/libclangstaticanalyzercore.a /usr/obj/usr/src/usr.bin/clang/c= lang/../../../lib/clang/libclangarcmigrate/libclangarcmigrate.a /usr/obj/us= r/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganaly= sis.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/= libclangedit.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libc= langast/libclangast.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/cla= ng/libclanglex/libclanglex.a /usr/obj/usr/src/usr.bin/clang/clang/../../../= lib/clang/libclangbasic/libclangbasic.a /usr/obj/usr/src/usr.bin/clang/clan= g/../../../lib/clang/libllvmoption/libllvmoption.a /usr/obj/usr/src/usr.bin= /clang/clang/../../../lib/clang/libllvmobjcarcopts/libllvmobjcarcopts.a /us= r/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmlinker/libllvml= inker.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmirre= ader/libllvmirreader.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/cl= ang/libllvmipo/libllvmipo.a /usr/obj/usr/src/usr.bin/clang/clang/../../../l= ib/clang/libllvmvectorize/libllvmvectorize.a /usr/obj/usr/src/usr.bin/clang= /clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/usr/= src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparse= r.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmaarch64c= odegen/libllvmaarch64codegen.a /usr/obj/usr/src/usr.bin/clang/clang/../../.= ./lib/clang/libllvmaarch64asmparser/libllvmaarch64asmparser.a /usr/obj/usr/= src/usr.bin/clang/clang/../../../lib/clang/libllvmaarch64desc/libllvmaarch6= 4desc.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmaarc= h64info/libllvmaarch64info.a /usr/obj/usr/src/usr.bin/clang/clang/../../../= lib/clang/libllvmaarch64instprinter/libllvmaarch64instprinter.a /usr/obj/us= r/src/usr.bin/clang/clang/../../../lib/clang/libllvmaarch64utils/libllvmaar= ch64utils.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvm= armdisassembler/libllvmarmdisassembler.a /usr/obj/usr/src/usr.bin/clang/cla= ng/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/usr/sr= c/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmp= arser.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmd= esc/libllvmarmdesc.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clan= g/libllvmarminfo/libllvmarminfo.a /usr/obj/usr/src/usr.bin/clang/clang/../.= ./../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/usr/s= rc/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscod= egen.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsa= smparser/libllvmmipsasmparser.a /usr/obj/usr/src/usr.bin/clang/clang/../../= ../lib/clang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/usr/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/usr/= src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/libllvmmi= psinstprinter.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/lib= llvmpowerpcdisassembler/libllvmpowerpcdisassembler.a /usr/obj/usr/src/usr.b= in/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodeg= en.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpc= asmparser/libllvmpowerpcasmparser.a /usr/obj/usr/src/usr.bin/clang/clang/..= /../../lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/usr/src/u= sr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo= .a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcin= stprinter/libllvmpowerpcinstprinter.a /usr/obj/usr/src/usr.bin/clang/clang/= ../../../lib/clang/libllvmsparccodegen/libllvmsparccodegen.a /usr/obj/usr/s= rc/usr.bin/clang/clang/../../../lib/clang/libllvmsparcasmparser/libllvmspar= casmparser.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllv= msparcdesc/libllvmsparcdesc.a /usr/obj/usr/src/usr.bin/clang/clang/../../..= /lib/clang/libllvmsparcinfo/libllvmsparcinfo.a /usr/obj/usr/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmsparcinstprinter/libllvmsparcinstprinter= .a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmpar= ser/libllvmx86asmparser.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib= /clang/libllvmx86codegen/libllvmx86codegen.a /usr/obj/usr/src/usr.bin/clang= /clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/ob= j/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvma= smprinter.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvm= codegen/libllvmcodegen.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/= clang/libllvmtarget/libllvmtarget.a /usr/obj/usr/src/usr.bin/clang/clang/..= /../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/usr/src/usr= .bin/clang/clang/../../../lib/clang/libllvmprofiledata/libllvmprofiledata.a= /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine= /libllvminstcombine.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/cla= ng/libllvminstrumentation/libllvminstrumentation.a /usr/obj/usr/src/usr.bin= /clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils= .a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libll= vmipa.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanal= ysis/libllvmanalysis.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/cl= ang/libllvmx86desc/libllvmx86desc.a /usr/obj/usr/src/usr.bin/clang/clang/..= /../../lib/clang/libllvmobject/libllvmobject.a /usr/obj/usr/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/usr/= src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreade= r.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcdisass= embler/libllvmmcdisassembler.a /usr/obj/usr/src/usr.bin/clang/clang/../../.= ./lib/clang/libllvmx86info/libllvmx86info.a /usr/obj/usr/src/usr.bin/clang/= clang/../../../lib/clang/libllvmx86instprinter/libllvmx86instprinter.a /usr= /obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /= usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86utils/libl= lvmx86utils.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libll= vmcore/libllvmcore.a /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clan= g/libllvmsupport/libllvmsupport.a /usr/obj/usr/src/tmp/usr/lib/libz.a /usr/= obj/usr/src/tmp/usr/lib/libncursesw.a /usr/obj/usr/src/tmp/usr/lib/libpthre= ad.a >> .depend echo clang.full: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend --- depend_subdir_usr.sbin --- --- depend_subdir_audit --- =3D=3D=3D> usr.sbin/audit (depend) --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/audit/../../contrib/op= enbsm -std=3Dgnu99 /usr/src/usr.sbin/audit/../../contrib/openbsm/bin/aud= it/audit.c --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/mtab.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_audit --- echo audit.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/u= sr/lib/libbsm.a >> .depend --- depend_subdir_auditd --- =3D=3D=3D> usr.sbin/auditd (depend) --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/nfs_prot_xdr.c:45: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditd --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/auditd/../../contrib/o= penbsm -std=3Dgnu99 /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/a= uditd/auditd.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/au= dit_warn.c /usr/src/usr.sbin/auditd/../../contrib/openbsm/bin/auditd/auditd= _fbsd.c --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/strutil.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditd --- echo auditd.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/= usr/lib/libauditd.a /usr/obj/usr/src/tmp/usr/lib/libbsm.a >> .depend --- depend_subdir_usr.bin --- --- depend_subdir_ee --- =3D=3D=3D> usr.bin/ee (depend) --- depend_subdir_usr.sbin --- --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/wire.c:57: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_usr.bin --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -DHAS_NCURSES -DHAS_UNISTD -DHAS_STDARG -D= HAS_STDLIB -DHAS_SYS_WAIT -std=3Dgnu99 /usr/src/usr.bin/ee/../../contrib= /ee/ee.c --- depend_subdir_usr.sbin --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/lib= amu/xutil.c:49: --- depend_subdir_usr.bin --- echo ee.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/= lib/libncursesw.a >> .depend --- depend_subdir_usr.sbin --- /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditdistd --- =3D=3D=3D> usr.sbin/auditdistd (depend) --- parse.c --- yacc -d -v -o parse.c /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bi= n/auditdistd/parse.y --- token.c --- lex -otoken.c /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/audit= distd/token.l --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/transp/transp_sockets.c:47: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ --- depend_subdir_auditdistd --- --- .depend --- rm -f .depend CC=3D'cc' mkdep -f .depend -a -I/usr/src/usr.sbin/auditdistd/../../contr= ib/openbsm -I/usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/auditdi= std -std=3Dgnu99 /usr/src/usr.sbin/auditdistd/../../contrib/openbsm/bin/= auditdistd/auditdistd.c parse.c /usr/src/usr.sbin/auditdistd/../../contrib/= openbsm/bin/auditdistd/pjdlog.c /usr/src/usr.sbin/auditdistd/../../contrib/= openbsm/bin/auditdistd/proto.c /usr/src/usr.sbin/auditdistd/../../contrib/o= penbsm/bin/auditdistd/proto_common.c /usr/src/usr.sbin/auditdistd/../../con= trib/openbsm/bin/auditdistd/proto_socketpair.c /usr/src/usr.sbin/auditdistd= /../../contrib/openbsm/bin/auditdistd/proto_tcp.c /usr/src/usr.sbin/auditdi= std/../../contrib/openbsm/bin/auditdistd/proto_tls.c /usr/src/usr.sbin/audi= tdistd/../../contrib/openbsm/bin/auditdistd/receiver.c /usr/src/usr.sbin/au= ditdistd/../../contrib/openbsm/bin/auditdistd/sandbox.c /usr/src/usr.sbin/a= uditdistd/../../contrib/openbsm/bin/auditdistd/sender.c /usr/src/usr.sbin/a= uditdistd/../../contrib/openbsm/bin/auditdistd/subr.c token.c /usr/src/usr.= sbin/auditdistd/../../contrib/openbsm/bin/auditdistd/trail.c --- depend_subdir_amd --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/mtab/mtab_bsd.c:51: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/con= f/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'confi= g_local.h' file not found #include "config_local.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error make[5]: stopped in /usr/src/usr.sbin/amd/libamu *** [depend_subdir_libamu] Error code 2 make[4]: stopped in /usr/src/usr.sbin/amd 1 error make[4]: stopped in /usr/src/usr.sbin/amd *** [depend_subdir_amd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_auditdistd --- echo auditdistd.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/= tmp/usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpthread.a /usr/obj/usr/s= rc/tmp/usr/lib/libutil.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a /usr/obj/= usr/src/tmp/usr/lib/libssl.a >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.sbin/auditdistd *** [depend_subdir_auditdistd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_usr.bin --- --- depend_subdir_clang --- --- depend_subdir_tblgen --- echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/usr.= bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/= obj/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvms= upport.a /usr/obj/usr/src/tmp/usr/lib/libncursesw.a /usr/obj/usr/src/tmp/us= r/lib/libpthread.a >> .depend echo tblgen.full: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.bin/clang/tblgen *** [depend_subdir_tblgen] Error code 2 make[4]: stopped in /usr/src/usr.bin/clang 1 error make[4]: stopped in /usr/src/usr.bin/clang *** [depend_subdir_clang] Error code 2 make[3]: stopped in /usr/src/usr.bin 1 error make[3]: stopped in /usr/src/usr.bin *** [depend_subdir_usr.bin] Error code 2 make[2]: stopped in /usr/src --- depend_subdir_usr.sbin --- --- depend_subdir_tcpdump --- echo tcpdump.full: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp= /usr/lib/libl.a /usr/obj/usr/src/tmp/usr/lib/libpcap.a /usr/obj/usr/src/tmp= /usr/lib/libcapsicum.a /usr/obj/usr/src/tmp/usr/lib/libcrypto.a >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** [depend] Error code 2 make[4]: stopped in /usr/src/usr.sbin/tcpdump 1 error make[4]: stopped in /usr/src/usr.sbin/tcpdump *** [depend_subdir_tcpdump] Error code 2 make[3]: stopped in /usr/src/usr.sbin 3 errors make[3]: stopped in /usr/src/usr.sbin *** [depend_subdir_usr.sbin] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_depend] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson6969127340795327068.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Tue Feb 16 18:21:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EDEAAAA1C6; Tue, 16 Feb 2016 18:21:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 236CE173C; Tue, 16 Feb 2016 18:21:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6C80F1D95; Tue, 16 Feb 2016 18:21:52 +0000 (UTC) Date: Tue, 16 Feb 2016 18:21:50 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, andrew@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1203556842.19.1455646912395.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1485102190.13.1455638468052.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1485102190.13.1455638468052.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2353 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 18:21:52 -0000 FreeBSD_HEAD_i386 - Build #2353 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2353/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2353/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2353/console Change summaries: 295663 by bdrewery: Revert r295648 for now. This builds fine with FAST_DEPEND but the mkdep method requires that include/ generates the headers during 'make depend' so the subsequent directories can find them when running mkdep. Sponsored by: EMC / Isilon Storage Division 295662 by andrew: Allow callers of OF_decode_addr to get the size of the found mapping. This will allow for code that uses the old fdt_get_range and fdt_regsize functions to find a range, map it, access, then unmap to replace this, up to and including the map, with a call to OF_decode_addr. As this function should only be used in the early boot code the unmap is mostly do document we no longer need the mapping as it's a no-op, at least on arm. Reviewed by: jhibbits Sponsored by: ABT Systems Ltd Differential Revision: https://reviews.freebsd.org/D5258 From owner-freebsd-current@freebsd.org Tue Feb 16 19:04:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B6DAAAA6F9 for ; Tue, 16 Feb 2016 19:04:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 19F4418DE for ; Tue, 16 Feb 2016 19:04:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id y8so104516078igp.0 for ; Tue, 16 Feb 2016 11:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=cuxbDOZZKIfMppdU2WDvRlIglFhJ+iKGEg0klKLhgZM=; b=qFZmvxLQmniwBcsH9x8Vl/h9zlS9sYTv1KVPy/WJzNZx5OTbs2g/vsQ+Cxe1uQQ44n u82j+KGeo8EbdKOhVKafzVpgkin5vPv87JCSYaukElEo29vjxZYu3BfrudxzMex/arVW 0wstSz2HXIBF5ROUw9w8ee045MEs/0u+8mR2ERyHzcpRU3H9i4PU+OX0MYT/XCbQAEkF LF5ysaKnzLl7M78i4Kx9WC3LR/6XEb8Uvd2N09xQehDy5xQKv5B3zZxGp+163BffSyQU k7p8t3Db6OGJUBeJK4i3JE3xgCuxXxdNq4s1qMLvVikn5hQSKdMgxfZas0frCJUulEQ9 v7pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=cuxbDOZZKIfMppdU2WDvRlIglFhJ+iKGEg0klKLhgZM=; b=CC190G18WK5yJ2h3XRjrHsP2kjWHaqUwiyqDvsCZC82tUwQfZ1bTeXlFNvYUnM/R/t lb2meGk6LGR5qBe2nsMc8lzmlcvc8dntcVaz/SZJUj4TGEw2guZTy4twCbiXtCngw2Tq Bka4Q7y0SHdQmNsDAo7eQO4R/PyaO7scielKjC/Zeoz8QLOmCMLL5AHVGYM141S18jb8 tJy3fXEsex7M3VuhhE9nf07v3wiuGXX1QuvbqhGeL2OxVNRQMo6OBjXraCwuE543YG8K MYxsVUPxpifaecGuYoFUtYyh58AzZQeOEt9AEEx9sECf3hIEd0+waLgo8kx1e4uRLa4m RYMg== X-Gm-Message-State: AG10YOR3kxIDnDmJXXoUm7eXGYa2sxKDr8bXxdru7o9eEgWbvdd7fhmOw66M8WZDPsKi321D+GbDJzWTTor1Kg== X-Received: by 10.50.12.33 with SMTP id v1mr18988436igb.33.1455649477519; Tue, 16 Feb 2016 11:04:37 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.66 with HTTP; Tue, 16 Feb 2016 11:04:17 -0800 (PST) From: Ed Maste Date: Tue, 16 Feb 2016 14:04:17 -0500 X-Google-Sender-Auth: SDHxnaNdtjCCi7Wt31K04c2Iqok Message-ID: Subject: Call for testing: Using ELF Tool Chain elfcopy as objcopy To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 16 Feb 2016 19:04:38 -0000 Summary: If you're willing to help test the ELF Tool Chain tools and you build -CURRENT from source, please set WITH_ELFCOPY_AS_OBJCOPY=yes in /etc/src.conf, and report any build- or run-time issues you experience with the base system, ports, or third-party software. In SVN revision 295577 I updated ELF Tool Chain to upstream revision 3400, which corresponds roughly with the upcoming 0.7.1 release of that project. ELF Tool Chain's elfcopy is a functional replacement for binutils objcopy for both the base system and ports tree after this update and a few followup commits. (An exp-run is in progress in PR 207091 to validate the followup fixes. One port failure is due to an issue in that port and is tracked in PR 207170.) There is a src.conf knob WITH_ELFCOPY_AS_OBJCOPY to install ELF Tool Chain's elfcopy as /usr/bin/objcopy. I plan to make this the default for 11.0, but first would like to ask for broader testing with the setting enabled. I'm particularly interested in hearing from anyone using the base system objcopy in unusual cases (e.g., converting ELF files to ROM images). Note that some lesser-used objcopy options (like --reverse-bytes or --interleave-width) are not implemented in elfcopy, so I'm also interested in hearing from anyone who makes use of options that are not supported by elfcopy. From owner-freebsd-current@freebsd.org Wed Feb 17 00:31:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DA12AABB71 for ; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 89E6AFE8 for ; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 872DCAABB70; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86C97AABB6F for ; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 788A1FE7; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 71D381898; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 248301BC8F; Wed, 17 Feb 2016 00:31:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Q-5JOzhVXn05; Wed, 17 Feb 2016 00:31:07 +0000 (UTC) Subject: Re: Possible race condition noted r295622 -> r295654 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 208E61BC88 To: David Wolfskill , current@freebsd.org References: <20160216150249.GT1178@albert.catwhisker.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <56C3BF4A.4040104@FreeBSD.org> Date: Tue, 16 Feb 2016 16:31:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160216150249.GT1178@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 00:31:10 -0000 On 2/16/16 7:02 AM, David Wolfskill wrote: > Given some of the reports of problems building head recently, my initial > attempts this morning (upgrading head/amd64) in place from r295622 to > r295654) were "clean" builds. > > My "build machine" reported no trouble (using -j16). > > On my laptop, also using -j16, the process terminated prematurely, with > whines about inability to find libopythagoras. > > In a half-hearted attempt, I then immediately attempted an "unclean" > build ("make -j 16 --DNO_CLEAN buildworld"); unsurprisingly, that > failed. > > On a bit of a whim, I then tried "make -j14 buildworld" -- that > succeeeded. > > I've placed a typescript of all of those efforts in > -- ref "bw.txt" (or > "bw.txt.gz"), in case that's of interest or use. > r295683 should fix it. There are likely more regressions after my recent change. Please CC me on any more you run into. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Wed Feb 17 00:31:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8564FAABBBC for ; Wed, 17 Feb 2016 00:31:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 75F271130 for ; Wed, 17 Feb 2016 00:31:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 6F9D0193C for ; Wed, 17 Feb 2016 00:31:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 3D3311BCA4 for ; Wed, 17 Feb 2016 00:31:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id tLpZkZStT8dq for ; Wed, 17 Feb 2016 00:31:27 +0000 (UTC) Subject: Re: CURRENT BROKEN fatal error: 'config_local.h' file not found DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com EA6C31BC9A To: freebsd-current@freebsd.org References: From: Bryan Drewery Organization: FreeBSD Message-ID: <56C3BF5E.7020000@FreeBSD.org> Date: Tue, 16 Feb 2016 16:31:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 00:31:29 -0000 On 2/16/16 2:55 AM, Outback Dingo wrote: > seems current is broken due to a missing file > /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: > 'config_local.h' file not found > It's fixed now. -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Wed Feb 17 13:29:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22687AAA1C8 for ; Wed, 17 Feb 2016 13:29:48 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 DBF5F1CB8 for ; Wed, 17 Feb 2016 13:29:47 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aW25Z-001uZA-L4>; Wed, 17 Feb 2016 14:24:17 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aW25Z-0024qk-8I>; Wed, 17 Feb 2016 14:24:17 +0100 Date: Wed, 17 Feb 2016 14:24:10 +0100 From: "O. Hartmann" To: freebsd-current Subject: CVE-2015-7547: critical bug in libc Message-ID: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 13:29:48 -0000 It is around now in the media also for non-OS developers: CVE-2015-7547 describes a bug in libc which is supposed to affects all Linux versions. big price question: is FreeBSD > 9.3 also affected? Some reporters tell us that Linux/UNIX is affected, so sometimes this terminus is used to prevent the "Linux-nailed" view, but sometimes it also referes to everything else those people can not imagine but consider them Linux-like. So I'm a bit puzzled, since there is no report about *BSD is affected, too. Thanks in advance for shedding light onto CVE-2015-7547. Regards, oh From owner-freebsd-current@freebsd.org Wed Feb 17 13:40:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F4177AAA71A for ; Wed, 17 Feb 2016 13:40:07 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 AD7C9130E for ; Wed, 17 Feb 2016 13:40:07 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qg0-x230.google.com with SMTP id y9so11683883qgd.3 for ; Wed, 17 Feb 2016 05:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wPmJKsCjOZhP2yaM8ArNUUmitjhIo8+nLjjp61X+hXY=; b=ugjTz4Ae4yGwGqDAp8wTmOXiDUXyiss47M/990DPvf3BpHjvJLU3vCA1yFQ1q8jOqi wHP3GzHAB5PkcJq5QNmejwzc3ZWKnps2yUNxojAZlih6F1He3dzysRvXPOiGqBM1UQcV fbd6g0RUKqEhIf1j2ng1SsvsdbAQ368pnatv7S4gjS64OS0wUg9Ny0Khh+tzS0qBgqZd xGwXNRU4ZNTTh0Xpj+K0hEMKxd4V3yDS8VtiF4kRoWYqukU/0sp+1gIKIP5gPc50W0RA VrmIOXIVIEyf/DStKE19iLGTIo1z/yTsRe7urNe3vLY3/VTMNyTJ3RnBkWENyyae6Ovy VBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=wPmJKsCjOZhP2yaM8ArNUUmitjhIo8+nLjjp61X+hXY=; b=mqaWx8dWb4HOgX8shDKqv9DqnEKlZ0FRgd9Hbq8FT4rV0KD6tYgHovIwBi4x2QopNQ a54wIxuHBJJRYEqk8EUBTtqGVzDp6akzjdr35rA27pXdORaxNwkfMrAkQ6jZ8h8pBvbE XO53xa5+GsUZwUeVxDYy72hoaIWCAgXSztM6aFcUe/Hzf+rdGmH8cPbv2Epkbu8bguUj HX2EWgrn6egwSZnD5vVFMfGdUcKiClIoBFyit3+dp15X+tj9IGw4kLijXSZqyeuQq2Te e+Ye2X04ZjS5s+b8ZPtXsrhJtLn/cq967pvUB4wmuKmigPLjMv+5w0vETQcc6J+aDLnS SgpA== X-Gm-Message-State: AG10YOQSFfG/lDluhY50h1g95CuQqGwbas8LtvQTTwueslnlsugVRq41vpd6HV9fi68SIDmA X-Received: by 10.140.91.109 with SMTP id y100mr1890441qgd.42.1455716406795; Wed, 17 Feb 2016 05:40:06 -0800 (PST) Received: from mutt-hardenedbsd (c-73-135-80-144.hsd1.md.comcast.net. [73.135.80.144]) by smtp.gmail.com with ESMTPSA id a196sm495166qha.49.2016.02.17.05.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2016 05:40:05 -0800 (PST) Date: Wed, 17 Feb 2016 08:40:03 -0500 From: Shawn Webb To: "O. Hartmann" Cc: freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160217134003.GB57405@mutt-hardenedbsd> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 13:40:08 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 17, 2016 at 02:24:10PM +0100, O. Hartmann wrote: > It is around now in the media also for non-OS developers: CVE-2015-7547 > describes a bug in libc which is supposed to affects all Linux versions. >=20 > big price question: is FreeBSD > 9.3 also affected? >=20 > Some reporters tell us that Linux/UNIX is affected, so sometimes this ter= minus > is used to prevent the "Linux-nailed" view, but sometimes it also referes= to > everything else those people can not imagine but consider them Linux-like= =2E So > I'm a bit puzzled, since there is no report about *BSD is affected, too. >=20 > Thanks in advance for shedding light onto CVE-2015-7547. The project that's vulnerable is called "glibc", not "libc". The BSDs don't use glibc, so the phrase "nothing to see here" applies. glibc isn't even available in FreeBSD's ports tree. TL;DR: FreeBSD is not affected by CVE-2015-7547. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWxHgxAAoJEGqEZY9SRW7uBLYP/1NNgED/9wm8czihM0RtUfK0 Wx9zYKf/QWwp8zPFKKnb67mh+ZN6n0kzTYdMEfyCAZs0wt4Rdi3vj6aCD66zTlfA 9lkS6s75Y6WxZCv5eW/+5bloPWhIdNV7tYOat+GdPIkJrA/WkUZFz6EQQL7s9mMR KG2BI+YHCrV/WQGSYn8Uuo/CaHqDcxxt+3ns/4YUu9RT6NwXCqYV0hUWF75Kj2Zt CKGdbpTZmFpTCEEumYmxRWQjxtbiq40erUagA0oV1aGvRfBDrR9vKJ8BBAETTi0O wO+k7QO0YKQ5zuKDuA7CiaUM9k/KqyaFQP1CQvY0oZKSiBDNC/1oNFX9+dc1j27P l2E9uCpRzXTGB8bJXQHmVV24GAcF3Osbdi4/as57tFA3laQFx7z0/tLUpJYst6Qi MYK/Qdhe1n8jOWjInOmKffNsh++ECrjMEPnzzDDLjVYn30y1aKf5FnXwBpkwCzzW V3wazWerdglJYOuhpZaolvlIJYzpf9+AMLEfmNfw3L5fXZ36H9WubOCJFtpwb7kH LHIhslg/d1qUGthPV+h0aJMV4u/W4aL88rXbjDdeWL+sIBX1REZP+NePW9LPZpHH gnK6JE1oaYVMWvn/id7NpFm+6s/8JbXXfrg/VaPMM8LpXXyDAGC2RSv3xX7Wp7sh ZwSuy5cU/VyiL8QuckMM =Ta5F -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@freebsd.org Wed Feb 17 13:43:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16C7AAAAA1E for ; Wed, 17 Feb 2016 13:43:20 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 921B417EB for ; Wed, 17 Feb 2016 13:43:19 +0000 (UTC) (envelope-from tommi.pernila@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id j78so11001784lfb.1 for ; Wed, 17 Feb 2016 05:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MEVlFZ2EQBy9LEwFKwSpldie6di7WVBVDUpj3qQ+QfY=; b=O9exA1b8W+8CK1bEN+6mE8jy2sWHMB11WXQUL5SrBMh0vRbX4e0asEoyR0K4zrCuaJ oihnOTHyKKJEESNXTIEAiBbhQfdzQfC8KR/r1AeWWtkN04e/6RHl6txrr7TZ5EGtyL5v rSYQMdVyg2fhZ+vx5999CAQ5Xf21sCgGUooFFjrZAxwLAD01rmdnqx6QqGcjJON8bIqI eenCRopoCGepNWTqUi5ecwTZv1gMXfzd4n6CyMgyX5gfurm1HFm7HtcpavNvVOD2qlkj Po9xyo4MLKT/+CMnt+f+JomYXz1Q4ul6gmVDOk4tl2DogVAHs6M2I57+qAYODryS2G4o c4cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MEVlFZ2EQBy9LEwFKwSpldie6di7WVBVDUpj3qQ+QfY=; b=Fe4aSG2ChO4uj14qh/uPs5ni+FaaK48LvO4PcrpKrAst1BgYM+ofThhIXYN7OCuT1S YDTnN10lOsdmVvelVtH3r4MBj3LQ2F7cN1M1hyIxR4b8Ji00puAqAqab3MgeunI5e4Ke ovBD2GMneJ78zOGT9aIHg6zZILXH/JRddMPv9PzzbR92FTae/XS0qY1pPXD/4d2/C1P2 a/3uqSLjzQM9T6becjl1gAlE+BNe9WCqrcvIepLGmGG9Cz6t+qC2vbEIuQDCQZZu2Mfi vgjcvle7U6N7wfKwkk5eHr/nwne5wvdonPTeTzemSkROnIjTZMbH+pZOG2YkaKyx5Cly EwBQ== X-Gm-Message-State: AG10YOTbzzfky9NuSXMM3fEnNhGF8GVRrt7k5Zcoqn001/hTsm3tv6hNoy2BpsSVZr/0Q1Uv71n5LVFfRjssAw== MIME-Version: 1.0 X-Received: by 10.25.148.76 with SMTP id w73mr684385lfd.31.1455716597440; Wed, 17 Feb 2016 05:43:17 -0800 (PST) Sender: tommi.pernila@gmail.com Received: by 10.112.91.131 with HTTP; Wed, 17 Feb 2016 05:43:17 -0800 (PST) In-Reply-To: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> Date: Wed, 17 Feb 2016 15:43:17 +0200 X-Google-Sender-Auth: yCGm3q2jnwi0bXAA1mD9pOLxy60 Message-ID: Subject: Re: CVE-2015-7547: critical bug in libc From: Tommi Pernila To: "O. Hartmann" Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 13:43:20 -0000 Hi, as Shawn types faster then me... the libc issue has been found from glibc which is not used in the BSD family. This is the affected libc https://en.wikipedia.org/wiki/GNU_C_Library What FreeBSD uses: https://en.wikipedia.org/wiki/BSD_libc -Tommi On Wed, Feb 17, 2016 at 3:24 PM, O. Hartmann wrote: > It is around now in the media also for non-OS developers: CVE-2015-7547 > describes a bug in libc which is supposed to affects all Linux versions. > > big price question: is FreeBSD > 9.3 also affected? > > Some reporters tell us that Linux/UNIX is affected, so sometimes this > terminus > is used to prevent the "Linux-nailed" view, but sometimes it also referes > to > everything else those people can not imagine but consider them Linux-like. > So > I'm a bit puzzled, since there is no report about *BSD is affected, too. > > Thanks in advance for shedding light onto CVE-2015-7547. > > Regards, > > oh > _______________________________________________ > 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 17 13:50:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA96AAAADF3 for ; Wed, 17 Feb 2016 13:50:30 +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 804F51E04 for ; Wed, 17 Feb 2016 13:50:30 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aW2Uu-000Igu-S5; Wed, 17 Feb 2016 14:50:28 +0100 Date: Wed, 17 Feb 2016 14:50:28 +0100 From: Kurt Jaeger To: Shawn Webb Cc: "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160217135028.GR26283@home.opsec.eu> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160217134003.GB57405@mutt-hardenedbsd> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 13:50:30 -0000 Hi! > The project that's vulnerable is called "glibc", not "libc". The BSDs > don't use glibc, so the phrase "nothing to see here" applies. glibc > isn't even available in FreeBSD's ports tree. > > TL;DR: FreeBSD is not affected by CVE-2015-7547. A short note on the www.freebsd.org website would probably be helpful, as this case will produce a lot of noise. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Feb 17 14:15:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F03AAAB8AD for ; Wed, 17 Feb 2016 14:15:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) 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 EC87E1F0D for ; Wed, 17 Feb 2016 14:15:22 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22b.google.com with SMTP id s68so6117828qkh.3 for ; Wed, 17 Feb 2016 06:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DqDl4Klbw+QpQoehnaHwtFvMVsP6yUYg9kxSHYP/VsE=; b=E6pEkdnmx1a/lnSn8/N5VnfRJQFFfBGYOSgBJpRAouogEUoMGqJQQInuV6nEmE022m uB26qQHvzSQgkvwAH3pot2gaBI4r68AOk5qIYK3b2h53+ZWv1LdLGoabsgaNSluzGTMP AQhGRV1n/zT/4P93dvPKr+c9Ioi8KFT/+MLCGQSvcbd5mRn2c9jG/ZpXcD0+/rtNumAO r+6P2sR1hSY9GJiPrcFSDhxUl225GcuMNBOElJ9gLsVv7hS6UByoS5zuPEDt5v3CsR3I 9d1TZqrnGC+otbKjKIBRPVu7tzMwIsNEC+sT30gmnSsTsZRxZRw2kAPMxkVZk6bT1dwk gtdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=DqDl4Klbw+QpQoehnaHwtFvMVsP6yUYg9kxSHYP/VsE=; b=bv/4g1BMknWE/wSpkF/eOgu992+gCvH7ruDOQUFto4dOBud8OdshYHPBxHl92UZDw8 EK7EA31MHo/QYFpghR/s+zzJtiDlh62Ly3PFyA4BxIMR31vlIAuftcl0cLl4A9llumsy 0aVvdneXkNS0JuKDWi0WIByGhIHbLDWNWQYX8CDmmpUky/P+3ApaQNrjMzbCaYTt2442 Er+7Nv6+CQlay4Y9XsyLbdWiG4KKOFht/OBjOqpeCYTXyuV+UifgMPMjDtFTcSEhafcg S6Df6SjA5VezQhkhVsTWx6mpqyky4pc2kK5ggcXlPPTIiMBAK0vIQe2ALyYd9ZUV+o5A kTPw== X-Gm-Message-State: AG10YOS9KHJxSF7PguxV0qdR1WF53U8u33qyJS36BfhNZRqFuf2wNAY67grpLfR3vZ6SWIsp X-Received: by 10.55.74.209 with SMTP id x200mr2139491qka.106.1455718521946; Wed, 17 Feb 2016 06:15:21 -0800 (PST) Received: from mutt-hardenedbsd (c-73-135-80-144.hsd1.md.comcast.net. [73.135.80.144]) by smtp.gmail.com with ESMTPSA id 90sm15431453qgo.14.2016.02.17.06.15.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2016 06:15:19 -0800 (PST) Date: Wed, 17 Feb 2016 09:15:18 -0500 From: Shawn Webb To: Daniel Kalchev Cc: "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160217141518.GC57405@mutt-hardenedbsd> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 14:15:23 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 17, 2016 at 04:07:25PM +0200, Daniel Kalchev wrote: >=20 > > On 17.02.2016 ??., at 15:40, Shawn Webb wr= ote: > >=20 > > TL;DR: FreeBSD is not affected by CVE-2015-7547. >=20 >=20 > Unless you use Linux applications under emulation. True. I didn't think of that since I don't use the linuxulator and am not a big fan of it. Good catch. --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWxIBzAAoJEGqEZY9SRW7uOHIP/1IMXL+zZyjqhmNxpkvxjYDl n7ZFS3zidHTIAGilaEsGCHfjoGCElXyiGYSS4sYyh2AlZ4O1BapxoWTHSi+HOulG 6WPcXS8ycVeA384MaSKrw2ZaJEnJQXaIwoBFgRXAamERYg4pG8SRs18/D3I3jMFt HELmsAUN9FnY+KYr3HmroDARhBODwK9GkPm6B89yqtdPeKBfABSeeunVcHaMeA3f aUWQvolOhwCovRBkBYCvTTAAJr0owBQr4z6HxRHT5YDzuiIsIG9i+aXgyPoLPlEw EBlQ036J7uWROe4Tw2JFgQp7wSVf9QghwqeYGla58WcaXHEIIj5ts3Q8Fs3zLRah Dy/NrYTFPCmKtGBE0X46q6ZWEbvoPs/3vsxSl98qKc6Uk6OaKIMVkMUuMbwwbhbL Akt4PmLVIIjFsLn/9bzoKWIs0cHwC8/VDcPx7CYS+DGChwihAYlBgCOvvvnq0fqw 6vXu/+wRlTFl3slke87MS9N4swtrdrxqnHpv4VtQyUbA2T6X32Yyj4+r5L6leyrA AuyLg0CFLjx8nQ/dl6BwBwT9Rln6uxVczcgjUdJcfgF1L5J4/mfDBNjYIAcJKRS7 dk0XJQyQt2On8nflU9Fj6R3qmEGHA8BLQPPFHG/AqX8mrWTizD8E0/xzJOPxtX6G LQnj3f9Fc7ZHMkMBlnfC =8+wZ -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-current@freebsd.org Wed Feb 17 14:19:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4488EAABB18 for ; Wed, 17 Feb 2016 14:19:09 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 139991173 for ; Wed, 17 Feb 2016 14:19:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u1HEJ7r2056421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 07:19:07 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u1HEJ7K5056418; Wed, 17 Feb 2016 07:19:07 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 17 Feb 2016 07:19:07 -0700 (MST) From: Warren Block To: Kurt Jaeger cc: Shawn Webb , "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc In-Reply-To: <20160217135028.GR26283@home.opsec.eu> Message-ID: References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 17 Feb 2016 07:19:07 -0700 (MST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 14:19:09 -0000 On Wed, 17 Feb 2016, Kurt Jaeger wrote: > Hi! > >> The project that's vulnerable is called "glibc", not "libc". The BSDs >> don't use glibc, so the phrase "nothing to see here" applies. glibc >> isn't even available in FreeBSD's ports tree. >> >> TL;DR: FreeBSD is not affected by CVE-2015-7547. What about software that uses emulators/linux_base? > A short note on the www.freebsd.org website would probably be helpful, > as this case will produce a lot of noise. Maybe a short article like we did for leap seconds? https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html I can help with that. From owner-freebsd-current@freebsd.org Wed Feb 17 14:25:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD678AABEA3 for ; Wed, 17 Feb 2016 14:25:17 +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 6FD961939 for ; Wed, 17 Feb 2016 14:25:17 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aW32c-000InI-Jz; Wed, 17 Feb 2016 15:25:18 +0100 Date: Wed, 17 Feb 2016 15:25:18 +0100 From: Kurt Jaeger To: Warren Block Cc: freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160217142518.GT26283@home.opsec.eu> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 14:25:17 -0000 Hi! > >> TL;DR: FreeBSD is not affected by CVE-2015-7547. > > What about software that uses emulators/linux_base? > > > A short note on the www.freebsd.org website would probably be helpful, > > as this case will produce a lot of noise. > > Maybe a short article like we did for leap seconds? > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html > > I can help with that. Just write the piece, there's no-one else doin' it 8-} -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Feb 17 14:27:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DBBAABFC6 for ; Wed, 17 Feb 2016 14:27:28 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49F661B8D for ; Wed, 17 Feb 2016 14:27:28 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.9/8.14.9) with ESMTP id u1HE7otS022846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2016 16:07:51 +0200 (EET) (envelope-from daniel@digsys.bg) Subject: Re: CVE-2015-7547: critical bug in libc Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A32C4E14-5811-4F9E-A18C-00EB3F5B74D2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Daniel Kalchev In-Reply-To: <20160217134003.GB57405@mutt-hardenedbsd> Date: Wed, 17 Feb 2016 16:07:25 +0200 Cc: "O. Hartmann" , freebsd-current Message-Id: References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> To: Shawn Webb X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 14:27:29 -0000 --Apple-Mail=_A32C4E14-5811-4F9E-A18C-00EB3F5B74D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17.02.2016 =D0=B3., at 15:40, Shawn Webb = wrote: >=20 > TL;DR: FreeBSD is not affected by CVE-2015-7547. Unless you use Linux applications under emulation. Daniel --Apple-Mail=_A32C4E14-5811-4F9E-A18C-00EB3F5B74D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWxH65AAoJEDN1EDx7HoqimjEP/AsIDMgl2zAmPkXNKpJGJpp+ XVOMVHoW7ZNkQClu24YFiyAWdKaKFyOmHbGWugjsiI8JzpVas7Uic5efuSi48RKC yjwdAE9FIwOAvV253ghdBSky8K7PTb68VS0Z8CEdg9Y7SAtf3mYlmo/Y6tCE1vJm G4nVAQzh8HDk5yHQ47sI+SHVcDW+1m+E53UtgR378WvBFZv61q1EnA0sN+kEafCv UyOlO0VGx+7Ce+11Bvp4GbiqkakOXmr6HrcOaJY9W4vtVv9wPr4ZhI5y0VR6Kn1H ExvoZ77rkr6Om7j2D095rQor1uMgW3dfDlZPJXZBiLulIys4Xef2bg5CGMvtR9iH iWyB6CBMdkjNZ7bU4ElDOn8JzvGkl3k3oZzgrB/eidBu/CSX6fV0KFmWoN7WUI6y obMAc09AnhBDG6sm1B/AQeR6KAIGN3uG1C3SN/EiRTKn+1+YlYumCt8YO3kmFhg9 0rZsG02/ZZEL3k73F20aTH+rHqFmbIQzrtHIcYmDIJ72yeE5JNAPQJQdH1Dzd5Mv vDm+eX6BdLF/f1fWCSLgo45+L08nMxcaO85b80bXC6xS4a4cSOJrBr6yYgHm/bG2 hBRGCCosfWu4I8ITNlR+4kbGsvgTVVH1zSzyHynL+RHAymekUd20U2KC3I8AmRMg OOb+ofoPoOL9d9yz3sId =gWgB -----END PGP SIGNATURE----- --Apple-Mail=_A32C4E14-5811-4F9E-A18C-00EB3F5B74D2-- From owner-freebsd-current@freebsd.org Wed Feb 17 15:36:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BABAAABF59 for ; Wed, 17 Feb 2016 15:36:02 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 238CF1D01 for ; Wed, 17 Feb 2016 15:36:01 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id u1HF4ofG093173 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Feb 2016 15:04:51 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id u1GMEThi026221 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 01:14:29 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.1/Submit) id u1GMESAt026220; Wed, 17 Feb 2016 01:14:28 +0300 (MSK) (envelope-from dchagin) Date: Wed, 17 Feb 2016 01:14:28 +0300 From: Chagin Dmitry To: Warren Block Cc: Kurt Jaeger , Shawn Webb , "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160216221428.GA26203@chd.heemeyer.club> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 15:36:02 -0000 On Wed, Feb 17, 2016 at 07:19:07AM -0700, Warren Block wrote: > On Wed, 17 Feb 2016, Kurt Jaeger wrote: > > > Hi! > > > >> The project that's vulnerable is called "glibc", not "libc". The BSDs > >> don't use glibc, so the phrase "nothing to see here" applies. glibc > >> isn't even available in FreeBSD's ports tree. > >> > >> TL;DR: FreeBSD is not affected by CVE-2015-7547. > > What about software that uses emulators/linux_base? > see PR/207272 > > A short note on the www.freebsd.org website would probably be helpful, > > as this case will produce a lot of noise. > > Maybe a short article like we did for leap seconds? > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html > > I can help with 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 Wed Feb 17 15:50:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34A00AAA69C for ; Wed, 17 Feb 2016 15:50:06 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD1315FB for ; Wed, 17 Feb 2016 15:50:06 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4752F56AE0; Wed, 17 Feb 2016 09:50:05 -0600 (CST) Subject: Re: CVE-2015-7547: critical bug in libc To: Warren Block , Kurt Jaeger References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> Cc: Shawn Webb , "O. Hartmann" , freebsd-current From: Eric van Gyzen Message-ID: <56C496AC.8000200@FreeBSD.org> Date: Wed, 17 Feb 2016 09:50:04 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 15:50:06 -0000 On 02/17/2016 08:19, Warren Block wrote: > On Wed, 17 Feb 2016, Kurt Jaeger wrote: > >> A short note on the www.freebsd.org website would probably be helpful, >> as this case will produce a lot of noise. > > Maybe a short article like we did for leap seconds? > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html > Articles are permanent, which makes sense for the recurring issue of leap seconds. This vulnerability is transient, so I would suggest a news item. Eric From owner-freebsd-current@freebsd.org Wed Feb 17 16:51:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2864AAA6BB for ; Wed, 17 Feb 2016 16:51:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2237100C; Wed, 17 Feb 2016 16:51:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u1HGpc1h096011 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 09:51:38 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u1HGpcwb096002; Wed, 17 Feb 2016 09:51:38 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 17 Feb 2016 09:51:38 -0700 (MST) From: Warren Block To: Eric van Gyzen cc: Kurt Jaeger , Shawn Webb , "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc In-Reply-To: <56C496AC.8000200@FreeBSD.org> Message-ID: References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> <56C496AC.8000200@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 17 Feb 2016 09:51:38 -0700 (MST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 16:51:41 -0000 On Wed, 17 Feb 2016, Eric van Gyzen wrote: > On 02/17/2016 08:19, Warren Block wrote: >> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >> >>> A short note on the www.freebsd.org website would probably be helpful, >>> as this case will produce a lot of noise. >> >> Maybe a short article like we did for leap seconds? >> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >> > > Articles are permanent, which makes sense for the recurring issue of > leap seconds. This vulnerability is transient, so I would suggest a > news item. Yes, but news items are usually just links. For the amount of information we have so far, an article seems like the easiest way to do this. Or maybe an addition to the security part of the web site? For now, I'll collect the information as just text. From owner-freebsd-current@freebsd.org Wed Feb 17 17:02:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B09DCAAAB38 for ; Wed, 17 Feb 2016 17:02:36 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 7E6F515AF; Wed, 17 Feb 2016 17:02:36 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pa0-x231.google.com with SMTP id fy10so14255800pac.1; Wed, 17 Feb 2016 09:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4Ir3Ts/AeJDS29HHig3c21pchxtUSP6Jek46Y3ygxKE=; b=cSg2Ws9SEKnWhjRr/KVEFwBDtuP+9gNE+Aro2lAHK64I9w87vtXDbDkAHNIe+tCq/7 2psKe7PctLa9zSmWM7mjuQCQWbIl1/NexgKe28jZV9ZCVGMgx2bEavUB7IrCnxt1EJIH 8NB37RlBJMICZPjbK6n8nGZZ6a9LDEqO4wPz4TThUqM4cJwh5pyax3avCLDNJxX3x8jL ho5EBqQRm9S4nYTw7U3oz4FA3cX0QSf5PowbsotWRVKtlg5YHKuZc113BRk10e9N+h1X ZKQAtUCiC+FudaBf+mXoEkWHsb4gTFt1MTJ3jlLbjF9hmPkCziiGO9cp0izxQNjrn7M1 91Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4Ir3Ts/AeJDS29HHig3c21pchxtUSP6Jek46Y3ygxKE=; b=F1otDn4J+64Rl/KPK/pXgBGN+ewgH+VJyTWpSHhKcg2bKJJyTBrLZ/yknZAWii2oyU vkG7fOpK2w+IzCwdez8dZ0SkpkpbyMygh5333uiEIMRJOIuhgjGfbAIFsohDKeCt8WEO oIbvjkO/ClhP0CHyrK1wZJNLJH8x2jTnI5VvQFglo6Elub7TAwkHbUTctT0YJjgRVFO+ Kul2dw1T056SgHMzOWnnk2foXyuIrQOqNvAcC8v30KHMUST0oXpidE5Zlv/ds1GoV0Fd wurFOqXLbV566BX5RgUFba9eM5v799M9zU5EePVlYNO42A/ttIW73FuOjkB+FQxOMVDO PqEQ== X-Gm-Message-State: AG10YOTW6Dzjhdh3VB0pUPAP85wHHuxLm3SaUztpAkYxwCFQRAb3SCskgfYdBSgDZ4WowA== X-Received: by 10.66.141.71 with SMTP id rm7mr3603940pab.106.1455728555930; Wed, 17 Feb 2016 09:02:35 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01:59b2:e9e6:6067:a08f? (2001-44b8-31ae-7b01-59b2-e9e6-6067-a08f.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:59b2:e9e6:6067:a08f]) by smtp.gmail.com with ESMTPSA id tp6sm3934841pab.25.2016.02.17.09.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 09:02:35 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: CVE-2015-7547: critical bug in libc References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> <56C496AC.8000200@FreeBSD.org> To: Warren Block , Eric van Gyzen Cc: Kurt Jaeger , Shawn Webb , "O. Hartmann" , freebsd-current From: Kubilay Kocak Message-ID: <0a7bd64c-59c5-8298-3773-660d832d7cde@FreeBSD.org> Date: Thu, 18 Feb 2016 04:02:26 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 17:02:36 -0000 On 18/02/2016 3:51 AM, Warren Block wrote: > On Wed, 17 Feb 2016, Eric van Gyzen wrote: > >> On 02/17/2016 08:19, Warren Block wrote: >>> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >>> >>>> A short note on the www.freebsd.org website would probably be helpful, >>>> as this case will produce a lot of noise. >>> >>> Maybe a short article like we did for leap seconds? >>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >>> >>> >> >> Articles are permanent, which makes sense for the recurring issue of >> leap seconds. This vulnerability is transient, so I would suggest a >> news item. > > Yes, but news items are usually just links. For the amount of > information we have so far, an article seems like the easiest way to do > this. Or maybe an addition to the security part of the web site? > > For now, I'll collect the information as just text. Don't we also want our sec teams to investigate/confirm it anyway, independent of how it's communicated? If so, doesn't a security advisory (with secteam and/or ports-secteam as appropriate) make the most sense here, given the scope of vulnerability for base/linux emulation/ports is yet to be completely established and is still to be investigated properly? Finally, would users expect a news item, an article or a heads up from our security teams for something like this, even in the case where it's only a "confirmed we're not affected" ? ./koobs From owner-freebsd-current@freebsd.org Wed Feb 17 17:23:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51C5DAAB401 for ; Wed, 17 Feb 2016 17:23:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 138DC1355; Wed, 17 Feb 2016 17:23:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u1HHNcaK004318 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 10:23:39 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u1HHNcni004311; Wed, 17 Feb 2016 10:23:38 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 17 Feb 2016 10:23:38 -0700 (MST) From: Warren Block To: Kubilay Kocak cc: Eric van Gyzen , Kurt Jaeger , Shawn Webb , "O. Hartmann" , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc In-Reply-To: <0a7bd64c-59c5-8298-3773-660d832d7cde@FreeBSD.org> Message-ID: References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> <56C496AC.8000200@FreeBSD.org> <0a7bd64c-59c5-8298-3773-660d832d7cde@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 17 Feb 2016 10:23:39 -0700 (MST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 17:23:40 -0000 On Thu, 18 Feb 2016, Kubilay Kocak wrote: > On 18/02/2016 3:51 AM, Warren Block wrote: >> On Wed, 17 Feb 2016, Eric van Gyzen wrote: >> >>> On 02/17/2016 08:19, Warren Block wrote: >>>> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >>>> >>>>> A short note on the www.freebsd.org website would probably be helpful, >>>>> as this case will produce a lot of noise. >>>> >>>> Maybe a short article like we did for leap seconds? >>>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >>>> >>>> >>> >>> Articles are permanent, which makes sense for the recurring issue of >>> leap seconds. This vulnerability is transient, so I would suggest a >>> news item. >> >> Yes, but news items are usually just links. For the amount of >> information we have so far, an article seems like the easiest way to do >> this. Or maybe an addition to the security part of the web site? >> >> For now, I'll collect the information as just text. > > Don't we also want our sec teams to investigate/confirm it anyway, > independent of how it's communicated? Absolutely. > If so, doesn't a security advisory (with secteam and/or ports-secteam as > appropriate) make the most sense here, given the scope of vulnerability > for base/linux emulation/ports is yet to be completely established and > is still to be investigated properly? Have there been security advisories for unconfirmed or not-actually-a-problem events before? My impression was that they have only been announced when a problem exists and action needs to be taken. However, a real problem *does* exist for Linux VMs and applications on FreeBSD, so it could be addressed that way. A "we are investigating" advisory right now could do some good, if the protocols allow it. > Finally, would users expect a news item, an article or a heads up from > our security teams for something like this, even in the case where it's > only a "confirmed we're not affected" ? A news item linking to a "it's not us!" advisory would be no problem. People have to go looking for that. Those who are subscribed to the security mailing list will receive those notices directly, and because those are expected to be problems that need to be addressed immediately, it might cause some initial palpitations as if it were an actual problem with FreeBSD. From owner-freebsd-current@freebsd.org Wed Feb 17 18:21:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B09D3AABD8E for ; Wed, 17 Feb 2016 18:21:19 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 7B2CD162D; Wed, 17 Feb 2016 18:21:19 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pf0-x22c.google.com with SMTP id e127so15563184pfe.3; Wed, 17 Feb 2016 10:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=G+CWThxbvL0WdEP2ZiG1XzWP/IFQWQ7shAbzEMujdPc=; b=DddpKyjwci8T57797R4hESUrhi9M/nVVR9ZYOVAIQx97N4BpwbFw6SwO0+2hYl3fxM jyElQhWhab5Z9vzYq5pxT6WrOYvy+0wCw16sCLpaujxTeIRr5RFGndS5obGwTxGcDhNV 2QFWAiNQmVoUREk2hebxAGJuZy7Rs9DRTR0Aje0FMutEPyYoV5J4ldzK7vGZl7+SxCio LtX7Zg50SXRPnGUFM7/Xr93wjfCKDXqA6J0BLWBOGjXcFsmg2rKBQDtBQmG8rN7QcPYr uA7ybNjpCh+aujhxeEjYp79XiLLkBi2hcOjMXbYV8Q8/sg29pSZkpinT33s3KZHsf/dR Z9CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=G+CWThxbvL0WdEP2ZiG1XzWP/IFQWQ7shAbzEMujdPc=; b=HBWZLtGLyqRUt4eBICNc2I+vg5jPTlesF6sdIbK1Gml6uzesT8rUegDAZFxRdgUVf9 kugcYEY5POv/zFo+8BwrghlmG/Yhw3jtJptMVHgLPkAAsAE94Od9Vly0y9X0zxqPodIr psA7XPxxTgZ8LkhqR4C7HK+XD1KJGgPB9qF7E6sEX3+J3GXlWm7vZZ0xIqx3XyCTKuiZ /by4bHQmZXsoAhPhpADI4V7Om8MiT3CkHbcihmp5FSyT9SiuOzwJXsY3qGEuQ1maCai9 UB/HJguPQUVU9q1ZX81AzYIhCb2/z1wB6iqUqLTToHTDTz4aclbE770rogEKa5nymcbo RGyw== X-Gm-Message-State: AG10YOTZGmrwuE2g++iVLZdryEpAHZjn1Izy3+sS7JLpHNFSF4fDgdQvYARTbReiNPhj2Q== X-Received: by 10.98.68.73 with SMTP id r70mr4186647pfa.136.1455733279084; Wed, 17 Feb 2016 10:21:19 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01:59b2:e9e6:6067:a08f? (2001-44b8-31ae-7b01-59b2-e9e6-6067-a08f.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:59b2:e9e6:6067:a08f]) by smtp.gmail.com with ESMTPSA id yl1sm4195037pac.35.2016.02.17.10.21.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 10:21:18 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: CVE-2015-7547: critical bug in libc References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> <56C496AC.8000200@FreeBSD.org> <0a7bd64c-59c5-8298-3773-660d832d7cde@FreeBSD.org> To: Warren Block Cc: Eric van Gyzen , Kurt Jaeger , Shawn Webb , "O. Hartmann" , freebsd-current From: Kubilay Kocak Message-ID: <2a6f9be2-fe6c-f844-6fec-dcdbb5f7da0d@FreeBSD.org> Date: Thu, 18 Feb 2016 05:21:09 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 18:21:19 -0000 On 18/02/2016 4:23 AM, Warren Block wrote: > On Thu, 18 Feb 2016, Kubilay Kocak wrote: > >> On 18/02/2016 3:51 AM, Warren Block wrote: >>> On Wed, 17 Feb 2016, Eric van Gyzen wrote: >>> >>>> On 02/17/2016 08:19, Warren Block wrote: >>>>> On Wed, 17 Feb 2016, Kurt Jaeger wrote: >>>>> >>>>>> A short note on the www.freebsd.org website would probably be >>>>>> helpful, >>>>>> as this case will produce a lot of noise. >>>>> >>>>> Maybe a short article like we did for leap seconds? >>>>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html >>>>> >>>>> >>>>> >>>> >>>> Articles are permanent, which makes sense for the recurring issue of >>>> leap seconds. This vulnerability is transient, so I would suggest a >>>> news item. >>> >>> Yes, but news items are usually just links. For the amount of >>> information we have so far, an article seems like the easiest way to do >>> this. Or maybe an addition to the security part of the web site? >>> >>> For now, I'll collect the information as just text. >> >> Don't we also want our sec teams to investigate/confirm it anyway, >> independent of how it's communicated? > > Absolutely. > >> If so, doesn't a security advisory (with secteam and/or ports-secteam as >> appropriate) make the most sense here, given the scope of vulnerability >> for base/linux emulation/ports is yet to be completely established and >> is still to be investigated properly? > > Have there been security advisories for unconfirmed or > not-actually-a-problem events before? My impression was that they have > only been announced when a problem exists and action needs to be taken. This "No SA, no problem" pattern is reasonable for default case, and the vast majority of issues. This glibc issue, like heartbleed and others may be sufficiently high-profile to warrant special treatment, even if not in "SA" form. > However, a real problem *does* exist for Linux VMs and applications on > FreeBSD, so it could be addressed that way. A "we are investigating" > advisory right now could do some good, if the protocols allow it. > >> Finally, would users expect a news item, an article or a heads up from >> our security teams for something like this, even in the case where it's >> only a "confirmed we're not affected" ? > > A news item linking to a "it's not us!" advisory would be no problem. > People have to go looking for that. > > Those who are subscribed to the security mailing list will receive those > notices directly, and because those are expected to be problems that > need to be addressed immediately, it might cause some initial > palpitations as if it were an actual problem with FreeBSD. Yup, and let me make clear an out-there-in-the-world distinction between 'an advisory by freebsd security people ' and a FreeBSD "SA" the implementation format. ./koobs From owner-freebsd-current@freebsd.org Wed Feb 17 19:48:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DED39AAC9B5 for ; Wed, 17 Feb 2016 19:48:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 ABBF81EDF for ; Wed, 17 Feb 2016 19:48:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x232.google.com with SMTP id c3so24524268vkb.3 for ; Wed, 17 Feb 2016 11:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CpT/j5AJvTbZZjJb1cR9NDb5Jpo2o+A5j7w0sJ+hbOs=; b=IntPIEWeInPqJwV6HWIssNDsbienTrJR3XLIXE1RSnBiZDZM3qcT5IxisaCjmm/HK2 tVi9P8IFvMXOmDjtPR9WZ7525aG1XtXADsa+5VY/H9mLdb6KbctzzFjqFPQjDZU9h/Vm qyf+1EUUZrMstwlHRHfWkYOBKWWEog/zxJST6vWoDPrIY2Lt6jARzCMgWZrII+9UUD5r V9qUWXtmHeY1cLZ27BLn21wewxI0cPkyFK3BUQhb3B5heRFZlZ3JOSW885Nn9qX0UbxF bmDfFDztIHs70LcU4TB3wegakmK1K6c/xgInLTyQ2vgnLHDgJSyH4fhtLcCctHVt3qd3 aukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CpT/j5AJvTbZZjJb1cR9NDb5Jpo2o+A5j7w0sJ+hbOs=; b=hz4QHpVbAzflsfARcwcZ/DIFnySQq36OyyVSjWywg/aayNd58eTo71kekyjYoQjr61 jxmgif3wDaoFk95jATzbCAZ7pEKSWqj7QS+LF0PysrxSYSDeEC0NeH69OkVBJv8ao0Rh gvMvbAN0beRFva1Jn8UbiKK1+JfjT5wsbPjzLy7NSjmFKQIn7Le0GjhjELV4ncXhy8t3 XiAZEO73B1NjbFmB4QPw2zKOFcYFA1TFg1tvUjgf1ZSequnQzwpZDMiLt/rdBROKPE3G uLT73DBQa9RL7W56x35r8DwOjETBGduSdqM8+U7TGX/SwZCveqMbMcMspQLZwUWW6Dr7 mpMw== X-Gm-Message-State: AG10YOQVu+WHsxLASxrZ2N7f0IiwCmHH221ZXJpAY+OT2FFr6eFqp+NqGoUogKtfiAFX/gTe+iGiyIvYAapK+Q== MIME-Version: 1.0 X-Received: by 10.31.128.82 with SMTP id b79mr2850009vkd.47.1455738506804; Wed, 17 Feb 2016 11:48:26 -0800 (PST) Received: by 10.103.37.196 with HTTP; Wed, 17 Feb 2016 11:48:26 -0800 (PST) In-Reply-To: <693932216.4173309.1455503591733.JavaMail.yahoo@mail.yahoo.com> References: <56BEE187.80702@selasky.org> <693932216.4173309.1455503591733.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 17 Feb 2016 14:48:26 -0500 Message-ID: Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL PANIC FreeBSD-11 From: Joe Nosay To: Greg Quinlan Cc: Hans Petter Selasky , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 17 Feb 2016 19:48:28 -0000 The Creative Labs Xfi cards use OSS as the driver. Other cards based on the same chipset would also be dependent upon OSS. On Sun, Feb 14, 2016 at 9:33 PM, Greg Quinlan wrote: > Thanks. > > I am not going to use OSS anymore... > > I am going to stick to stick with a custom kernel > > device sounddevice snd_hda From: Hans Petter Selasky > To: Greg Quinlan ; "freebsd-current@freebsd.org" < > freebsd-current@freebsd.org> > Sent: Saturday, 13 February 2016, 18:55 > Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL > PANIC FreeBSD-11 > > On 02/12/16 01:04, Greg Quinlan wrote: > > Spoke too soon... > > > > I applied the patch (kern_module.diff - which was successful) > > > > # cd /usr/src# patch to me... > > The text leading up to this was: > > -------------------------- > > |Index: sys/kern/kern_module.c > > |=================================================================== > > |--- sys/kern/kern_module.c (revision 295464) > > |+++ sys/kern/kern_module.c (working copy) > > -------------------------- > > Patching file sys/kern/kern_module.c using Plan A... > > Hunk #1 succeeded at 214. > > done > > # make buildkernel: > > # make installkernel: > > # shutdown -r now > > Logged in and ran# soundon > > No panic!! > > > > Thought the problem was fixed ... unfortunately, I assumed that the > contents of /usr/local/lib/oss/etc/installed_drivers still contained > > oss_hdaudio #Intel High Definition Audio (CPT) > > but somehow the file was empty > > I ran > > # ossdetect # soundon > > > > Another KERNEL PANIC... this time it scrolled off the screen. I tried > setting this (below) in /etc/rc.conf but there is nothing in /var/crash > > > > [entries in /etc/rc.conf] > > dumpdev="AUTO" > > dumpdir="/var/crash" > > I need help to recover the backtrace, please? > > > > Thanks > > > > From: Greg Quinlan > > To: Hans Petter Selasky ; "freebsd-current@freebsd.org" > > > Sent: Thursday, 11 February 2016, 22:19 > > Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL > PANIC FreeBSD-11 > > > > Well done!! > > Fixed. Thanks! > > > > > > > > From: Hans Petter Selasky > > To: Greg Quinlan ; "freebsd-current@freebsd.org" < > freebsd-current@freebsd.org> > > Sent: Thursday, 11 February 2016, 17:54 > > Subject: Re: Open Sound System - OSS "soundon" command causes KERNEL > PANIC FreeBSD-11 > > > > On 02/11/16 03:02, Greg Quinlan wrote: > >> Hi HPS, > >> Note: Does not happen on FreeBSD 10.1-Stable! > >> > > > > Yes, that's because WITNESS is off in 10.x by default. > > > > Does the attached patch solve your problem? > > > > --HPS > > Hi, > > It might be that audio/oss is not compatible with 11-current if it > crashes like that. > > --HPS > > _______________________________________________ > 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" From owner-freebsd-current@freebsd.org Thu Feb 18 00:08:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF821AACC21 for ; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D86AF21A for ; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5E51AACC20; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5773AACC1F for ; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C3AEB219; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id BCE9217A6; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 53DB31CFA3; Thu, 18 Feb 2016 00:08:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 5qYhoasym0dq; Thu, 18 Feb 2016 00:08:45 +0000 (UTC) Subject: Re: /etc/periodic/weekly/320.whatis: /usr/libexec/makewhatis.local: not found DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 083171CF9E To: Eric van Gyzen , bapt@FreeBSD.org, current@FreeBSD.org References: <56C1F8E0.2020708@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56C50B96.3030302@FreeBSD.org> Date: Wed, 17 Feb 2016 16:08:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C1F8E0.2020708@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wm92GWgskl1Arfk6HRgIHNQ9lg59abiK7" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 00:08:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wm92GWgskl1Arfk6HRgIHNQ9lg59abiK7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/15/2016 8:12 AM, Eric van Gyzen wrote: > I just set up a workstation running head. The weekly 320.whatis script= always > reports: >=20 > /usr/libexec/makewhatis.local: not found >=20 > Indeed, it doesn't exist. Does the 320.whatis script need to be update= d for > r283777? >=20 makewhatis.local is an optimization wrapper. Rather than blow it away I will move it out of usr.bin/makewhatis (to avoid accidentally removing it later and a more proper place) and fix the installation of it. --=20 Regards, Bryan Drewery --wm92GWgskl1Arfk6HRgIHNQ9lg59abiK7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWxQuXAAoJEDXXcbtuRpfPGnAH/0oo70dvr9JDF/NJFBMMKY6Y 8QXykMUB1Pq3weH/MFKVpoj/wFBpI+2BJU+phUynyCLfKr4ao4CV4lIOntoZG3Tj ouLlcuKaWOLjRzDH7lKXLRlCTBZidGYqVwCjEYqUqgjCOTauCHD/hAh3WV3qCnOo K5DTJwKspEy7NaZifSFfD+jUkg+2RZn09UQTgb3xULVw2wkOHq3c0TME3WXJbHzg H3XRxn16n8TQSE1KMjFKxe+Z8W9KDEGZSRr0ztRWpc045L3MgGC4bUIF1zbtaZBV ATJWXHxbl3lqko0FQ0VQoJ1LmbC0fAjDY1Mok2zENjMwKjUT5mrYaFxv5zhc+fE= =Y7pu -----END PGP SIGNATURE----- --wm92GWgskl1Arfk6HRgIHNQ9lg59abiK7-- From owner-freebsd-current@freebsd.org Thu Feb 18 12:44:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CA14AAC085 for ; Thu, 18 Feb 2016 12:44:08 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 041061513 for ; Thu, 18 Feb 2016 12:44:08 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 0382AAAC084; Thu, 18 Feb 2016 12:44:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 031B7AAC081 for ; Thu, 18 Feb 2016 12:44:08 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A60ED1512 for ; Thu, 18 Feb 2016 12:44:06 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWNWL-0001zN-HJ for current@freebsd.org; Thu, 18 Feb 2016 18:17:22 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1ICIMeM099255 for ; Thu, 18 Feb 2016 18:18:22 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1ICIHZB099165 for current@freebsd.org; Thu, 18 Feb 2016 18:18:17 +0600 (NOVT) (envelope-from danfe) Date: Thu, 18 Feb 2016 18:18:17 +0600 From: Alexey Dokuchaev To: current@freebsd.org Subject: Unable to kldload vesa.ko (but works from loader.conf) Message-ID: <20160218121817.GA96654@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91506 [Feb 18 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3969491, 3969541, 3969055 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/17 15:51:37 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Thu, 18 Feb 2016 13:14:59 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 12:44:08 -0000 Hi there, I've decided to give -CURRENT a try on my i386 laptop with a 915GM video (supported by i915kms.ko) @ r295286; minimal kernel with most of the stuff loaded from /boot/loader.conf. While debugging suspend/resume issues, I've found out that loading vesa.ko now apparently only works from /boot/loader.conf: doing it manually from the command line after logging in gives me this error in dmesg(8): module_register_init: MOD_LOAD (vesa, 0x, 0) error 19 Some scattered reports on the net did not shed the light on whether this is expected behavior these days (which is a bit unexpected for a stable/8 user) or a regression due to lack of testing of standalone vesa.ko since VESA is a default option in GENERIC. Shall I file a PR? ./danfe From owner-freebsd-current@freebsd.org Thu Feb 18 13:16:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9E43AACDB5 for ; Thu, 18 Feb 2016 13:16:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 B1268B0F for ; Thu, 18 Feb 2016 13:16:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWORa-001G7t-H0>; Thu, 18 Feb 2016 14:16:30 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWORa-003z1U-64>; Thu, 18 Feb 2016 14:16:30 +0100 Date: Thu, 18 Feb 2016 14:16:24 +0100 From: "O. Hartmann" To: freebsd-current Subject: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 13:16:33 -0000 Hello out there, I run into a problem and digging for a solution didn't work out. Problem: I need a string that reflects the hashed password for the usage with passwd -H 0 I think the procedure is using sha512 -s Password and using this output for further processing, but how? I looked for a possibility to emmit the hash created by passwd to be used, but I couldn't find anything useful. It is crucial that we use utilities available in the base system of FreeBSD, so no fancy Python or Perl scripts. I might have overlooked something in my desperate quest, so I'm sorry if the task is trivial and already standard. Kind regards and than you very much in advance, oh From owner-freebsd-current@freebsd.org Thu Feb 18 14:05:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1D61AAC2A3 for ; Thu, 18 Feb 2016 14:05:51 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from eva.tinkyfi.com (eva.tinkyfi.com [107.191.63.190]) by mx1.freebsd.org (Postfix) with ESMTP id 80947F2 for ; Thu, 18 Feb 2016 14:05:50 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from [172.21.88.129] (cpc82705-staf9-2-0-cust342.3-1.cable.virginm.net [81.108.23.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by s.tinkyfi.com (Postfix) with ESMTPSA id 3q5GSD2z08z5HjN for ; Thu, 18 Feb 2016 00:02:20 +0000 (UTC) Subject: Re: CVE-2015-7547: critical bug in libc To: freebsd-current@freebsd.org References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> From: Joe Holden Message-ID: <56C50A0C.5090207@m.jwh.me.uk> Date: Thu, 18 Feb 2016 00:02:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 14:05:51 -0000 On 17/02/2016 14:07, Daniel Kalchev wrote: > >> On 17.02.2016 г., at 15:40, Shawn Webb wrote: >> >> TL;DR: FreeBSD is not affected by CVE-2015-7547. > > > Unless you use Linux applications under emulation. > > Daniel > Which is supported by ports so at most it should be a ports advisory and not a FreeBSD (base) SA and therefore not on the website. Just my 2p ;) From owner-freebsd-current@freebsd.org Thu Feb 18 14:20:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B5ABAACA46; Thu, 18 Feb 2016 14:20:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE04C9C; Thu, 18 Feb 2016 14:20:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7A7392CB; Thu, 18 Feb 2016 14:20:06 +0000 (UTC) Date: Thu, 18 Feb 2016 14:20:03 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: zbb@FreeBSD.org, wma@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <775636303.25.1455805205557.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2369 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:20:07 -0000 FreeBSD_HEAD_i386 - Build #2369 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2369/console Change summaries: 295756 by zbb: Extract common code from PowerPC's ofw_pci Import portions of the PowerPC OF PCI implementation into new file "ofw_pci.c", common for other platforms. The files ofw_pci.c and ofw_pci.h from sys/powerpc/ofw no longer exist. All required declarations are moved to sys/dev/ofw/ofw_pci.h. This creates a new ofw_pci_write_ivar() function and modifies ofw_pci_nranges(), ofw_pci_read_ivar(), ofw_pci_route_interrupt() methods. Most functions contain existing ppc implementations in the majority unchanged. Now there is no need to have multiple identical copies of methods for various architectures. Submitted by: Marcin Mazurek Obtained from: Semihalf Sponsored by: Annapurna Labs Reviewed by: jhibbits, mmel Differential Revision: https://reviews.freebsd.org/D4879 295755 by zbb: Introduce bus_get_bus_tag() method Provide bus_get_bus_tag() for sparc64, powerpc, arm, arm64 and mips nexus and its children in order to return a platform specific default tag. This is required to ensure generic correctness of the bus_space tag. It is especially needed for arches where child bus tag does not match the parent bus tag. This solves the problem with ppc architecture where the PCI bus tag differs from parent bus tag which is big-endian. This commit is a part of the following patch: https://reviews.freebsd.org/D4879 Submitted by: Marcin Mazurek Obtained from: Semihalf Sponsored by: Annapurna Labs Reviewed by: jhibbits, mmel Differential Revision: https://reviews.freebsd.org/D4879 295754 by zbb: Fix bug in ofwbus_release_resource() for non-ofwbus descendants Resource list for devices that are not ofwbus descendants, but got to ofwbus method via bus_generic_release_resource() call chain, cannot be found using BUS_GET_RESOURCE_LIST() used by ofwbus. In that case, changing device's resource list should be avoided (will not contain resource list prepared by ofw or simplebus). Pointy-hat to: zbb Reviewed by: wma Obtained from: Semihalf Sponsored by: Cavium Differential Revision: https://reviews.freebsd.org/D5304 295753 by wma: Fix ThunderX external PEM bus offset Obtained from: Semihalf Sponsored by: Cavium Approved by: cognet (mentor) Reviewed by: zbb Differential revision: https://reviews.freebsd.org/D5293 The end of the build log: [...truncated 209624 lines...] --- uart_dbg.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/uart/uart_dbg.c ctfconvert -L VERSION -g uart_dbg.o --- uart_subr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/uart/uart_subr.c ctfconvert -L VERSION -g uart_subr.o --- tmc18c30.o --- ctfconvert -L VERSION -g tmc18c30.o --- ehci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/ehci.c --- ohci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/ohci.c --- syscons.o --- ctfconvert -L VERSION -g syscons.o --- uhci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/uhci.c --- ohci.o --- ctfconvert -L VERSION -g ohci.o --- xhci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/xhci.c --- rt2860.o --- ctfconvert -L VERSION -g rt2860.o --- usb_busdma.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_busdma.c --- ehci.o --- ctfconvert -L VERSION -g ehci.o --- usb_core.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_core.c ctfconvert -L VERSION -g usb_core.o --- usb_debug.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_debug.c --- usb_busdma.o --- ctfconvert -L VERSION -g usb_busdma.o --- usb_dynamic.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_dynamic.c --- usb_debug.o --- ctfconvert -L VERSION -g usb_debug.o --- usb_error.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_error.c ctfconvert -L VERSION -g usb_error.o --- usb_generic.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_generic.c --- usb_dynamic.o --- ctfconvert -L VERSION -g usb_dynamic.o --- usb_hid.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hid.c --- uhci.o --- ctfconvert -L VERSION -g uhci.o --- usb_hub.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hub.c --- usb_hid.o --- ctfconvert -L VERSION -g usb_hid.o --- usb_lookup.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_lookup.c ctfconvert -L VERSION -g usb_lookup.o --- usb_mbuf.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_mbuf.c --- xhci.o --- ctfconvert -L VERSION -g xhci.o --- usb_msctest.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_msctest.c --- usb_generic.o --- ctfconvert -L VERSION -g usb_generic.o --- usb_parse.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_parse.c --- usb_mbuf.o --- ctfconvert -L VERSION -g usb_mbuf.o --- usb_pf.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_pf.c --- usb_parse.o --- ctfconvert -L VERSION -g usb_parse.o --- usb_process.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_process.c --- usb_hub.o --- ctfconvert -L VERSION -g usb_hub.o --- usb_request.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_request.c --- usb_msctest.o --- ctfconvert -L VERSION -g usb_msctest.o --- usb_transfer.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_transfer.c --- usb_pf.o --- ctfconvert -L VERSION -g usb_pf.o --- usb_util.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_util.c --- usb_process.o --- ctfconvert -L VERSION -g usb_process.o --- ukbd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/input/ukbd.c --- usb_util.o --- ctfconvert -L VERSION -g usb_util.o --- if_vtnet.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/network/if_vtnet.c --- usb_request.o --- ctfconvert -L VERSION -g usb_request.o --- virtio_blk.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/block/virtio_blk.c --- ukbd.o --- ctfconvert -L VERSION -g ukbd.o --- virtio_balloon.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/balloon/virtio_balloon.c --- usb_transfer.o --- ctfconvert -L VERSION -g usb_transfer.o --- virtio_scsi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/scsi/virtio_scsi.c --- virtio_blk.o --- ctfconvert -L VERSION -g virtio_blk.o --- if_vx.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/vx/if_vx.c --- virtio_balloon.o --- ctfconvert -L VERSION -g virtio_balloon.o --- watchdog.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/watchdog/watchdog.c ctfconvert -L VERSION -g watchdog.o --- if_wi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/wi/if_wi.c --- if_vx.o --- ctfconvert -L VERSION -g if_vx.o --- if_xe.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xe/if_xe.c --- if_vtnet.o --- ctfconvert -L VERSION -g if_vtnet.o --- virtio_scsi.o --- ctfconvert -L VERSION -g virtio_scsi.o --- xen_console.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/console/xen_console.c --- grant_table.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/grant_table/grant_table.c ctfconvert -L VERSION -g grant_table.o --- pvcpu.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/pvcpu/pvcpu.c --- xen_console.o --- ctfconvert -L VERSION -g xen_console.o --- privcmd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/privcmd/privcmd.c --- pvcpu.o --- ctfconvert -L VERSION -g pvcpu.o --- debug.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/debug/debug.c --- if_wi.o --- ctfconvert -L VERSION -g if_wi.o --- debug.o --- ctfconvert -L VERSION -g debug.o --- privcmd.o --- ctfconvert -L VERSION -g privcmd.o --- geom_dev.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/geom/geom_dev.c --- kern_clock.o --- --- kern_cpuset.o --- --- kern_clock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_clock.c --- kern_cpuset.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_cpuset.c --- if_xe.o --- ctfconvert -L VERSION -g if_xe.o --- kern_ffclock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_ffclock.c --- kern_cpuset.o --- /usr/src/sys/kern/kern_cpuset.c:643:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] for (i = 0; i < (_NCPUWORDS - 1); i++) { ~ ^ ~~~~~~~~~~~~~~~~ --- geom_dev.o --- ctfconvert -L VERSION -g geom_dev.o --- kern_intr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_intr.c --- kern_clock.o --- ctfconvert -L VERSION -g kern_clock.o WARNING: kern_clock.c: enum pmc_event has too many values: 2588 > 1023 --- kern_mutex.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_mutex.c --- kern_ffclock.o --- ctfconvert -L VERSION -g kern_ffclock.o --- kern_numa.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_numa.c --- kern_cpuset.o --- 1 warning generated. ctfconvert -L VERSION -g kern_cpuset.o --- kern_racct.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_racct.c --- kern_numa.o --- ctfconvert -L VERSION -g kern_numa.o --- kern_rctl.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_rctl.c --- kern_intr.o --- ctfconvert -L VERSION -g kern_intr.o --- kern_timeout.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_timeout.c --- kern_mutex.o --- ctfconvert -L VERSION -g kern_mutex.o WARNING: kern_mutex.c: enum pmc_event has too many values: 2588 > 1023 --- sched_ule.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/sched_ule.c --- kern_racct.o --- ctfconvert -L VERSION -g kern_racct.o --- subr_bus.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus.c --- kern_timeout.o --- ctfconvert -L VERSION -g kern_timeout.o --- subr_bus_dma.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus_dma.c --- subr_bus.o --- /usr/src/sys/kern/subr_bus.c:4110:9: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'bus_space_tag_t' (aka 'int') [-Werror,-Wint-conversion] return (NULL); ^~~~~~ /usr/src/sys/kern/subr_bus.c:4607:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'bus_space_tag_t' (aka 'int') [-Werror,-Wint-conversion] return (NULL); ^~~~~~ 2 errors generated. *** [subr_bus.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC --- kern_rctl.o --- ctfconvert -L VERSION -g kern_rctl.o --- subr_bus_dma.o --- ctfconvert -L VERSION -g subr_bus_dma.o --- sched_ule.o --- ctfconvert -L VERSION -g sched_ule.o 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson1579507223060952602.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Thu Feb 18 14:46:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4661AAD916 for ; Thu, 18 Feb 2016 14:46:38 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (gw.macktronics.com [209.181.253.70]) (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 94BF41FDA for ; Thu, 18 Feb 2016 14:46:38 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from olive.macktronics.com (olive.macktronics.com [209.181.253.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 2997A299; Thu, 18 Feb 2016 08:39:32 -0600 (CST) Date: Thu, 18 Feb 2016 08:39:32 -0600 (CST) From: Dan Mack To: Joe Holden cc: freebsd-current@freebsd.org Subject: Re: CVE-2015-7547: critical bug in libc In-Reply-To: <56C50A0C.5090207@m.jwh.me.uk> Message-ID: References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <56C50A0C.5090207@m.jwh.me.uk> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 14:46:38 -0000 On Thu, 18 Feb 2016, Joe Holden wrote: > On 17/02/2016 14:07, Daniel Kalchev wrote: >> >>> On 17.02.2016 ?., at 15:40, Shawn Webb wrote: >>> >>> TL;DR: FreeBSD is not affected by CVE-2015-7547. >> >> >> Unless you use Linux applications under emulation. >> >> Daniel >> > Which is supported by ports so at most it should be a ports advisory and > not a FreeBSD (base) SA and therefore not on the website. > > Just my 2p ;) Documenting and putting out security advisiories for other operating systems seems like a bad precedent in general. The same could be said for runniing java applications, windows under bhyve, etc. - *sigh* - if the cross over use is common via a port, then have the port maybe remind users to consult their distribution specific security vulnerabilites prior to running it maybe - which is what they should be doing anyway. That's my two insignificant cents :-) Dan From owner-freebsd-current@freebsd.org Thu Feb 18 14:52:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6C33AADBF8 for ; Thu, 18 Feb 2016 14:52:49 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 649A67F4 for ; Thu, 18 Feb 2016 14:52:49 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x232.google.com with SMTP id g62so31676070wme.1 for ; Thu, 18 Feb 2016 06:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=euRWRzwTZR9flPFPkjOuj0lzmKifoaluGtjefYKAYiw=; b=0XRPUKsjnjmypYW8fczBf4E+cH1k4MKyccw8dg+ssjMzSaPpH0U3zNVv3MKZF5BawH Eeqcqet9qudVZ1z6WtQdqdcmRbQDaYzkv0+YOtQpRTPxeqILAuoCR/Vmik4RNJb9k/MI duzn6JAlM60NvgyPs31Li1HCTQodAQ0dkIuppRp99YF5d4Z5/x7sfGK9tU7HQICi8CcA XKdAHeVMmTz7Y5XKUTMEKImcbb2GnszxkGpryJixEpvH4dvDyt+NnBsbX1fnoLHknxRt YhbT5RNBFM0dmLPkEEh69+qVV5+8jwN9yoxlhS0qUVrVCeuTNBwuAqAdI6Vtus72hd6Y 7C/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=euRWRzwTZR9flPFPkjOuj0lzmKifoaluGtjefYKAYiw=; b=XJdZ3EvJY0uSHfncYSpXa2h5DPteVvFKWZw13iIeq9Yd+KZeoYsgyZJNfn26TOodZu OVdVodJh+Xif3tYujfMfTTQKh/GuormfoLiXhcLAgvuXko4VDuzPAaUglF2FWBvAp+VK GDpWdvj5rqkgkf5xUFPSTg3ZP1HRPpidoR5V2qTWSssLf+GD59aJerfQY2DPTZQ1KnMA wdqVZHUuyX/UmoBBlfqfiQpPsYXbOqWhIIgNVizYusZJQlHP36+MsGkmlx+C1ONlTk2F G8fMJ+ugyTAtLjMVVunTmop0iqgJPY3/IEDNljTsPa7Z2V34GI2J6K0FAfyAWkf7Rty3 l/Dg== X-Gm-Message-State: AG10YOR0akgdHv8zu8O5Pw/iMdr0hrkG/0PsGxI1B5lDQlGmnWNHTmtQqrP5gIJvtieQkg== X-Received: by 10.194.143.82 with SMTP id sc18mr7891263wjb.14.1455807166942; Thu, 18 Feb 2016 06:52:46 -0800 (PST) Received: from gumby.homeunix.com ([94.8.71.47]) by smtp.gmail.com with ESMTPSA id x65sm3370300wmg.4.2016.02.18.06.52.45 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 06:52:45 -0800 (PST) Date: Thu, 18 Feb 2016 14:52:44 +0000 From: RW To: freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218145244.0b1e4c94@gumby.homeunix.com> In-Reply-To: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) 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.20 Precedence: 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, 18 Feb 2016 14:52:49 -0000 On Thu, 18 Feb 2016 14:16:24 +0100 O. Hartmann wrote: > Hello out there, > > I run into a problem and digging for a solution didn't work out. > > Problem: I need a string that reflects the hashed password for the > usage with > > passwd -H 0 Did you mean -h? > I think the procedure is using > > sha512 -s Password > > and using this output for further processing, but how? It's not as simple as that, password hashes are usually salted and iterated. Salting means that the password is combined with a randomly generated string stored in plaintext, which means that the password doesn't hash to a fixed string. I'm not sure exactly what you are trying to do, but crypt(3) may be of help. From owner-freebsd-current@freebsd.org Thu Feb 18 14:55:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6F5FAADCDD for ; Thu, 18 Feb 2016 14:55:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BB48395C for ; Thu, 18 Feb 2016 14:55:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BB182AADCDB; Thu, 18 Feb 2016 14:55:34 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA8F5AADCDA; Thu, 18 Feb 2016 14:55:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9901C95B; Thu, 18 Feb 2016 14:55:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E913B918; Thu, 18 Feb 2016 09:55:33 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: Jan Henrik Sylvester , Hans Petter Selasky , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" , Kevin Oberman Subject: Re: Thinkpad T410: resume broken Date: Thu, 18 Feb 2016 06:55:03 -0800 Message-ID: <1519677.qimO7W0WJL@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160218143738.GA38066@regency.nsu.ru> References: <53762216.8020205@gmx.net> <201405231000.30861.jhb@freebsd.org> <20160218143738.GA38066@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Feb 2016 09:55:33 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 14:55:35 -0000 On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote: > On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote: > > On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: > > > Looking through dmesg, it seems that other USB devices (build-in) are > > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > > > resume, just not the mouse. > > > > > > Are these lines likely related? > > > > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > > > AE_BAD_PARAMETER > > > > These are probably not related. These man that your BIOS explicitly told > > the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] > > are probably PCI-PCI bridges that represent the downstream ports of your > > PCI-e root complex) in the D2 state when suspending, but the devices don't > > actually support D2 (most PCI devices only support D0 (full on) and D3 > > (full off)). > > I've started to observe similar lines in the logs after updating to fresh > -CURRENT, upon resume (on a different laptop though, not T410): > > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER > acpi0: cleared fixed power button status > > If these messages are legit, I'm wondering why I didn't see them on 8.4, > and if it might affect suspend/resume sequence (broken right now)? Thanks, 8.4 has a bug fixed only in HEAD where we tried to power down the wrong devices during suspend (or used the _Sx hint from the wrong device to decide which Dx state to use when powering down, I can't recall which). For this reason, 11 is going to use different Dx states on different devices. The reason for the message remains the same (though it should now be correct on 11). Your BIOS said "please put this device in D2 during suspend" and your device's capabilites said "I don't support D2". You can confirm this by looking up the _S3 method of your _SB_.PCIO device to find out what state is requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see what D states are listed as supported. There's not much we can do if your BIOS lies to us. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 18 14:55:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E47D8AADCF6 for ; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C88FF960 for ; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C8694AADCF4; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE67AAADCED; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88F9B95F; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93073B94E; Thu, 18 Feb 2016 09:55:34 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: Kevin Oberman , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Date: Thu, 18 Feb 2016 06:50:34 -0800 Message-ID: <2846385.IUIOUlEDYf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160218141338.GA15706@regency.nsu.ru> References: <53762216.8020205@gmx.net> <537753F3.6000202@FreeBSD.org> <20160218141338.GA15706@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Feb 2016 09:55:34 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 14:55:36 -0000 On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote: > > VESA needs to be removed for i915kms, but I've no idea if it needs to be > > removed for Nvidia. The video reset code was reworked in 10 so that > > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, > > but in theory it works more often. > > This (VESA needs to be removed for i915kms) is news to me: I don't see it > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS > era) GENERIC kernel config. So what's the real deal here? :-) This is an old mail you are responding to. You no longer need to remove VESA for kms. > If "having VESA is supposed to be like using 'hw.acpi.reset_video=1' on > 9", it should not hurt (I recall having to hw.acpi.reset_video=1 in early > stable/[67] days, but no longer for quite a long time with stable/8). > > Admittedly, the whole situation with i915kms, vesa.ko, et al. looks quite > confusing, while suspend/resume works *worse* than with stable/8 and pre- > KMS. Table of known laptops on wiki page [1] is hardly helpful unless it > has your laptop of interest; IMHO it would benefit a lot more from listing > common symptoms and mitigation/fixes for them (including VESA, sysctl vars, > kernel options, etc). The value of "worse" depends on your laptop. I have an older i386 HP netbook for which resume works fine using sc(4) and the older DRM drivers because the video BIOS turns the LCD back on during resume without requiring the OS to do so. However, the recent GPU chipsets from Intel do not do that and the only bit of code in the tree that knows how to turn the LCD panel back on is the KMS driver. However, note that KMS is not related to NVidia GPUs. If your laptop is using one of those then the nvidia driver is what has to turn the LCD panel back on. > > ACPI_PM setting to the kernel module along with removing VESA would seem > > like your best bet, but I see in follow-ups that that wasn't completely > > reliable. However, you can try using ACPI_PM with syscons, no need to > > use vt. > > What are indications for use of ACPI_PM option? As for removing VESA, > I've found that my laptop resumes more willingly with i915kms.ko *and* > vesa.ko than without vesa.ko (could only? be loaded from loader.conf): > with both modules loaded it takes only three presses of power button to > get back from suspend, while without vesa.ko it's a lottery, and often > power-cycling is required to get things back to working -- any ideas on > why would that be? vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA emulation in the hardware when it starts which prevents VESA from working (VESA requires the legacy VGA interface). I never have to hit the power button more than once to resume on a laptop where resume works though. (True on my X220 and on a T440 both with Intel or Radeon graphics (all using KMS). > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > and stable/7 FWIW. If it worked here, then this means you could try using sc(4) + the old drm (not drm2). This means your laptop is old enough to still turn the LCD panel back on in its BIOS during resume like my HP netbook. However, I don't know for how much longer Xorg will support the older drm (if it even does now). FWIW, the HP netbook resumes fine with KMS as well for me. One caveat though is that if you are using vt(4) and haven't yet loaded KMS it won't resume (due to vt(4) not having the equivalent of VESA). With sc(4) the netbook was always able to resume. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 18 15:13:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D3AAAC615 for ; Thu, 18 Feb 2016 15:13:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 718251AF8; Thu, 18 Feb 2016 15:13:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1IFDLrl020395 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 18 Feb 2016 17:13:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1IFDLrl020395 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1IFDL6a020394; Thu, 18 Feb 2016 17:13:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Feb 2016 17:13:21 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: alc@FreeBSD.org, FreeBSD Current Subject: Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead) Message-ID: <20160218151321.GR91220@kib.kiev.ua> References: <56BBAB6E.5050601@FreeBSD.org> <56C08AAA.5050206@FreeBSD.org> <56C1953F.60604@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C1953F.60604@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 15:13:32 -0000 On Mon, Feb 15, 2016 at 11:07:11AM +0200, Andriy Gapon wrote: > On 15/02/2016 00:27, Alan Cox wrote: > > > > On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon > > wrote: > > > > On 10/02/2016 23:28, Andriy Gapon wrote: > > > > > > Over a span of approximately 3 weeks I have got two slightly different panics of > > > the same kind. The affected system is a several months old amd64 head. > > > > I added a small assertion and it got tripped: > [snip] > > > > So, it seems that the code allows modification of read_ahead field of an entry > > without holding a map lock. I'd guess that that should be mostly harmless as > > read_ahead value is not critical, but it is still not nice. > > > > Not intentionally. The nearby code to the read_ahead assignment expects the map > > to be locked, so I wouldn't categorize this as mostly harmless. > > > > In general, you shouldn't get to the read_ahead assignment without the map being > > locked, and almost all of the code paths that unlock the map jump to RetryFault > > shortly thereafter, so it's hard to imagine how the map lock wouldn't be > > reacquired. I speculate that the root cause of your panic is a case where > > vm_pager_get_pages() fails, and in such a case we might loop around, descending > > to the next backing object without reacquiring the map lock. In other words, > > your above assertion failure is happening on the next iteration after an initial > > vm_pager_get_pages() failure, and we're about to do another vm_pager_get_pages() > > call on a different object. > > > > In summary, I have no trouble believing that the code that handles a failure by > > vm_pager_get_pages() in vm_fault() is not quite right, and I think that's what's > > biting you. > > Alan, > > thank you very much for the very insightful analysis. > Indeed, I see that in this case the object chain is default -> swap -> swap. I > am not sure how such chain was created. It seems that going default -> swap is > not a problem as the map lock is not dropped in this case. But going swap -> > swap the way you described (pager error, e.g. the page is just not found) has > exactly the problem that you suggested. > So this is arguably a fallout from r188331. The following is somewhat non-insistent attempt to fix the problem. diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index a7e3d37..cddf1eb 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -291,7 +291,8 @@ vm_fault_hold(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, struct faultstate fs; struct vnode *vp; vm_page_t m; - int ahead, behind, cluster_offset, error, locked; + int ahead, behind, cluster_offset, error, locked, rv; + u_char behavior; hardfault = 0; growstack = TRUE; @@ -550,9 +551,18 @@ readrest: * zero-filled pages. */ if (fs.object->type != OBJT_DEFAULT) { - int rv; - u_char behavior = vm_map_entry_behavior(fs.entry); - + if (!fs.lookup_still_valid) { + locked = vm_map_trylock_read(fs.map); + if (locked) + fs.lookup_still_valid = TRUE; + if (!locked || fs.map->timestamp != + map_generation) { + release_page(&fs); + unlock_and_deallocate(&fs); + goto RetryFault; + } + } + behavior = vm_map_entry_behavior(fs.entry); era = fs.entry->read_ahead; if (behavior == MAP_ENTRY_BEHAV_RANDOM || P_KILLED(curproc)) { @@ -603,6 +613,7 @@ readrest: } ahead = ulmin(ahead, atop(fs.entry->end - vaddr) - 1); if (era != nera) + /* XXX only read-lock on map */ fs.entry->read_ahead = nera; /* From owner-freebsd-current@freebsd.org Thu Feb 18 14:36:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3087AAD4BD for ; Thu, 18 Feb 2016 14:36:54 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A6FBF194E for ; Thu, 18 Feb 2016 14:36:54 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id A6E6EAAD4BB; Thu, 18 Feb 2016 14:36:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CA72AAD4BA; Thu, 18 Feb 2016 14:36:54 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38B76194D; Thu, 18 Feb 2016 14:36:53 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWPhC-0000d4-CL; Thu, 18 Feb 2016 20:36:43 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1IEbid3041643; Thu, 18 Feb 2016 20:37:44 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1IEbcLS041553; Thu, 18 Feb 2016 20:37:38 +0600 (NOVT) (envelope-from danfe) Date: Thu, 18 Feb 2016 20:37:38 +0600 From: Alexey Dokuchaev To: John Baldwin Cc: Jan Henrik Sylvester , Hans Petter Selasky , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" , Kevin Oberman Subject: Re: Thinkpad T410: resume broken Message-ID: <20160218143738.GA38066@regency.nsu.ru> References: <53762216.8020205@gmx.net> <537CFCE4.2000300@selasky.org> <537D01F5.2050101@janh.de> <201405231000.30861.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405231000.30861.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91511 [Feb 18 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3969835, 3969873, 3969585 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 11:55:00 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Thu, 18 Feb 2016 15:23:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 14:36:55 -0000 On Fri, May 23, 2014 at 10:00:30AM -0400, John Baldwin wrote: > On Wednesday, May 21, 2014 3:43:49 pm Jan Henrik Sylvester wrote: > > Looking through dmesg, it seems that other USB devices (build-in) are > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after > > resume, just not the mouse. > > > > Are these lines likely related? > > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > > AE_BAD_PARAMETER > > These are probably not related. These man that your BIOS explicitly told > the OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] > are probably PCI-PCI bridges that represent the downstream ports of your > PCI-e root complex) in the D2 state when suspending, but the devices don't > actually support D2 (most PCI devices only support D0 (full on) and D3 > (full off)). I've started to observe similar lines in the logs after updating to fresh -CURRENT, upon resume (on a different laptop though, not T410): pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER acpi0: cleared fixed power button status If these messages are legit, I'm wondering why I didn't see them on 8.4, and if it might affect suspend/resume sequence (broken right now)? Thanks, ./danfe From owner-freebsd-current@freebsd.org Thu Feb 18 15:29:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48408AACE7E for ; Thu, 18 Feb 2016 15:29:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 0C52394A for ; Thu, 18 Feb 2016 15:29:17 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWQVy-0029bw-1a>; Thu, 18 Feb 2016 16:29:10 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWQVx-0000TE-N1>; Thu, 18 Feb 2016 16:29:09 +0100 Date: Thu, 18 Feb 2016 16:29:08 +0100 From: "O. Hartmann" To: RW Cc: freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20160218145244.0b1e4c94@gumby.homeunix.com> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 15:29:18 -0000 On Thu, 18 Feb 2016 14:52:44 +0000 RW wrote: > On Thu, 18 Feb 2016 14:16:24 +0100 > O. Hartmann wrote: > > > Hello out there, > > > > I run into a problem and digging for a solution didn't work out. > > > > Problem: I need a string that reflects the hashed password for the > > usage with > > > > passwd -H 0 > > Did you mean -h? no, I literally mean -H 0, I explain later ... > > > I think the procedure is using > > > > sha512 -s Password > > > > and using this output for further processing, but how? > > It's not as simple as that, password hashes are usually salted and > iterated. Salting means that the password is combined with a randomly > generated string stored in plaintext, which means that the password > doesn't hash to a fixed string. > > I'm not sure exactly what you are trying to do, but crypt(3) may be of > help. I'm now down to a small C routine utilizing crypt(3). But this is not what I intend to have, since I want to use tools from the FBSD base system. I build images of a small appliance in a secure isolated environment via NanoBSD. I do not want to have passwords in the clear around here, but I also do not want to type in everytime an image is created, so the idea is to have passwords prepared as hashes in a local file/in variables. Therefore, I'm inclined to use the option "-H 0" of the pw(1) command to provide an already and clean hash (SHA512), which is then stored in /etc/master.passwd. It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and they "generate" somehow the hashed password and store that in master.password - but I didn't find any way to pipe out the writing of the password to the standard output from that piece of software. Why? Security concerns I forgot to consider? I found lots of articles and howtos to use pipes producing the required password hashes via passwd, chpasswd or pw, but they all have one problem: I have to provide somehow the cleartext password in an automated environment. Maybe there is something missing ... oh From owner-freebsd-current@freebsd.org Thu Feb 18 15:54:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A9D3AAA030 for ; Thu, 18 Feb 2016 15:54:21 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2011DEC for ; Thu, 18 Feb 2016 15:54:20 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8DDF6D7B3 for ; Thu, 18 Feb 2016 15:54:19 +0000 (UTC) Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? To: freebsd-current@freebsd.org References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> From: Allan Jude X-Enigmail-Draft-Status: N1110 Message-ID: <56C5E933.8070502@freebsd.org> Date: Thu, 18 Feb 2016 10:54:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PhWBUiGg5reWGC1ofLVCKos7KUFnhJNo4" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 15:54:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PhWBUiGg5reWGC1ofLVCKos7KUFnhJNo4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-02-18 10:29, O. Hartmann wrote: > On Thu, 18 Feb 2016 14:52:44 +0000 > RW wrote: >=20 >> On Thu, 18 Feb 2016 14:16:24 +0100 >> O. Hartmann wrote: >> >>> Hello out there, >>> >>> I run into a problem and digging for a solution didn't work out. >>> >>> Problem: I need a string that reflects the hashed password for the >>> usage with=20 >>> >>> passwd -H 0 =20 >> >> Did you mean -h? >=20 > no, I literally mean -H 0, I explain later ... >=20 >> >>> I think the procedure is using=20 >>> >>> sha512 -s Password >>> >>> and using this output for further processing, but how? =20 >> >> It's not as simple as that, password hashes are usually salted and >> iterated. Salting means that the password is combined with a randomly >> generated string stored in plaintext, which means that the password >> doesn't hash to a fixed string. >> >> I'm not sure exactly what you are trying to do, but crypt(3) may be of= >> help. >=20 > I'm now down to a small C routine utilizing crypt(3). But this is not w= hat I > intend to have, since I want to use tools from the FBSD base system. >=20 > I build images of a small appliance in a secure isolated environment vi= a > NanoBSD. I do not want to have passwords in the clear around here, but = I also > do not want to type in everytime an image is created, so the idea is to= have > passwords prepared as hashes in a local file/in variables. Therefore, I= 'm > inclined to use the option "-H 0" of the pw(1) command to provide an al= ready > and clean hash (SHA512), which is then stored in /etc/master.passwd. >=20 > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw= ) and > they "generate" somehow the hashed password and store that in master.pa= ssword > - but I didn't find any way to pipe out the writing of the password to = the > standard output from that piece of software. Why? Security concerns I f= orgot to > consider? >=20 > I found lots of articles and howtos to use pipes producing the required= > password hashes via passwd, chpasswd or pw, but they all have one probl= em: I > have to provide somehow the cleartext password in an automated environm= ent. >=20 > Maybe there is something missing ... >=20 > oh > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 pw is using crypt() to turn the raw password into the password hash you see in master.passwd. The sha512 tool cannot do this, as that is 'sha512' (designed to be as fast as possible), and what crypt() uses is 'sha512crypt' (designed to be purposefully slow, does 5,000 sha512s by default, but is tunable by setting rounds=3D10000$ as a prefix to the salt when calling crypt) crypt("mypassword", "$6$rounds=3D10000$usesomesillystri"); Results in: $6$rounds=3D10000$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOA= b0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0 NetBSD has a command for generating hashes on the command line, pwhash(1)= I have wanted to bring something like that over for a while, but looking at the source for pwhash I decided I'd want to start from scratch. --=20 Allan Jude --PhWBUiGg5reWGC1ofLVCKos7KUFnhJNo4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWxek3AAoJEBmVNT4SmAt+BXkP/3nkTdLO+o17OmTvkwl0Toko hFBN4DWQ9r/NZaVxEwVVbY693Td2KE2pb+aVq3/isWem7KK56ZxJXZ0ITwcr/90z DIViO0zDXalhVnGMIJVDRCNc774Sl8Ku9JLIcIhiCWmfb0b1QxuXVjMqfuVFv9xi vRRl9Hl5zhk7qY5TZIxKsOZ/fvA3vajGHq4dyc5acX83arjSDc3b6ACYFEA04zVB SSvh8npleegpQqzH0I52odv648U5WPv8WWoe0MC2/kL4rAS9p9LiB/oAli0bNX4D 5eU3A3ZGIib+a5B2ObyPpyvoyPSaYrLfaBeM4IILsCdo6Mzl227bA1BBZk8CK0lc XQ/5xJmzfmaqk2YHT9Pi3V315M0IefPUnXtbzedfe9H1yIXPzNJSYkKySSRcr245 Sc+/1Fr1tWSSAtswfwrjba99k5lTfMH4isn+mp38m1BZ/FiLxtckSHq0zPuhQ6zd 2R2g9nt9Ae7y3sVUkHJIuFN4H8XaX6JKszmg1YzYfQVP2ZXL/qOsS2vk3CnL8TlC oQTCWj+ZdURRH0TcQf3unIVe8cxsrh2rJ2Hf6NGQawvY+FhjOCxM4jeu2Pb6YcAR iXUcxNQtDhKMxhdlhFSxqBLxdiC6l6hM2W6+h4mZcKqU3l+TyPvYuSGQB6fUCS6Y VyXZ2YpKB5YbSeNkwekP =oO1t -----END PGP SIGNATURE----- --PhWBUiGg5reWGC1ofLVCKos7KUFnhJNo4-- From owner-freebsd-current@freebsd.org Thu Feb 18 16:20:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 774FAAAAD9A for ; Thu, 18 Feb 2016 16:20:26 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 56B17ABF; Thu, 18 Feb 2016 16:20:26 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: by be-well.ilk.org (Postfix, from userid 1147) id 5F9FC33C25; Thu, 18 Feb 2016 11:20:20 -0500 (EST) From: Lowell Gilbert To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <56C5E933.8070502@freebsd.org> Date: Thu, 18 Feb 2016 11:20:20 -0500 In-Reply-To: <56C5E933.8070502@freebsd.org> (Allan Jude's message of "Thu, 18 Feb 2016 10:54:27 -0500") Message-ID: <44d1rugfcr.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 16:20:26 -0000 Allan Jude writes: > On 2016-02-18 10:29, O. Hartmann wrote: >> I'm now down to a small C routine utilizing crypt(3). But this is not what I >> intend to have, since I want to use tools from the FBSD base system. >> >> I build images of a small appliance in a secure isolated environment via >> NanoBSD. I do not want to have passwords in the clear around here, but I also >> do not want to type in everytime an image is created, so the idea is to have >> passwords prepared as hashes in a local file/in variables. Therefore, I'm >> inclined to use the option "-H 0" of the pw(1) command to provide an already >> and clean hash (SHA512), which is then stored in /etc/master.passwd. >> >> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and >> they "generate" somehow the hashed password and store that in master.password >> - but I didn't find any way to pipe out the writing of the password to the >> standard output from that piece of software. Why? Security concerns I forgot to >> consider? >> >> I found lots of articles and howtos to use pipes producing the required >> password hashes via passwd, chpasswd or pw, but they all have one problem: I >> have to provide somehow the cleartext password in an automated environment. >> >> Maybe there is something missing ... >> >> oh >> _______________________________________________ > > pw is using crypt() to turn the raw password into the password hash you > see in master.passwd. > > The sha512 tool cannot do this, as that is 'sha512' (designed to be as > fast as possible), and what crypt() uses is 'sha512crypt' (designed to > be purposefully slow, does 5,000 sha512s by default, but is tunable by > setting rounds=10000$ as a prefix to the salt when calling crypt) > > crypt("mypassword", "$6$rounds=10000$usesomesillystri"); > > Results in: > > $6$rounds=10000$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0 > > NetBSD has a command for generating hashes on the command line, pwhash(1) > > I have wanted to bring something like that over for a while, but looking > at the source for pwhash I decided I'd want to start from scratch. "openssl passwd", maybe? From owner-freebsd-current@freebsd.org Thu Feb 18 16:20:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB59FAAAD9F; Thu, 18 Feb 2016 16:20:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ADDF4AC7; Thu, 18 Feb 2016 16:20:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2AEF6306; Thu, 18 Feb 2016 16:20:27 +0000 (UTC) Date: Thu, 18 Feb 2016 16:20:25 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, imp@FreeBSD.org, br@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1659777383.33.1455812427140.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <775636303.25.1455805205557.JavaMail.jenkins@jenkins-9.freebsd.org> References: <775636303.25.1455805205557.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2370 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:20:26 -0000 FreeBSD_HEAD_i386 - Build #2370 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2370/console Change summaries: 295759 by imp: Remove a stray else. It isn't needed (due to the return at the end of the if statement it pairs with). While not an error today, a careless edit in the future could cause problems (though given the nature of this specific code, the problems quite likely would be some variation of "most direct access SCSI storage devices won't attach," which is unlikely to go unnoticed). PVS-Studio: V705 295758 by br: Use medany (Medium/Anywhere) GCC code model for RISC-V. This will allow us to use bigger relocations and all the 64-bit VA space. 295757 by emaste: Remove dd xfer stats emitted during buildworld They result in gratuitous differences when comparing build log output. The end of the build log: [...truncated 210759 lines...] --- tmc18c30.o --- ctfconvert -L VERSION -g tmc18c30.o --- ohci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/ohci.c --- syscons.o --- ctfconvert -L VERSION -g syscons.o --- uhci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/uhci.c --- ohci.o --- ctfconvert -L VERSION -g ohci.o --- xhci.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/xhci.c --- rt2860.o --- ctfconvert -L VERSION -g rt2860.o --- usb_busdma.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_busdma.c --- ehci.o --- ctfconvert -L VERSION -g ehci.o --- usb_core.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_core.c ctfconvert -L VERSION -g usb_core.o --- usb_debug.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_debug.c --- usb_busdma.o --- ctfconvert -L VERSION -g usb_busdma.o --- usb_dynamic.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_dynamic.c --- usb_debug.o --- ctfconvert -L VERSION -g usb_debug.o --- usb_error.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_error.c --- usb_dynamic.o --- ctfconvert -L VERSION -g usb_dynamic.o --- usb_generic.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_generic.c --- usb_error.o --- ctfconvert -L VERSION -g usb_error.o --- usb_hid.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hid.c --- uhci.o --- ctfconvert -L VERSION -g uhci.o --- usb_hub.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hub.c --- usb_hid.o --- ctfconvert -L VERSION -g usb_hid.o --- usb_lookup.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_lookup.c ctfconvert -L VERSION -g usb_lookup.o --- usb_mbuf.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_mbuf.c --- xhci.o --- ctfconvert -L VERSION -g xhci.o --- usb_msctest.o --- --- usb_generic.o --- ctfconvert -L VERSION -g usb_generic.o --- usb_msctest.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_msctest.c --- usb_parse.o --- --- usb_mbuf.o --- ctfconvert -L VERSION -g usb_mbuf.o --- usb_parse.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_parse.c --- usb_pf.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_pf.c --- usb_hub.o --- ctfconvert -L VERSION -g usb_hub.o --- usb_parse.o --- ctfconvert -L VERSION -g usb_parse.o --- usb_process.o --- --- usb_request.o --- --- usb_process.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_process.c --- usb_request.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_request.c --- usb_msctest.o --- ctfconvert -L VERSION -g usb_msctest.o --- usb_pf.o --- ctfconvert -L VERSION -g usb_pf.o --- usb_transfer.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_transfer.c --- usb_util.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_util.c --- usb_process.o --- ctfconvert -L VERSION -g usb_process.o --- ukbd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/input/ukbd.c --- usb_util.o --- ctfconvert -L VERSION -g usb_util.o --- if_vtnet.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/network/if_vtnet.c --- usb_request.o --- ctfconvert -L VERSION -g usb_request.o --- virtio_blk.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/block/virtio_blk.c --- ukbd.o --- ctfconvert -L VERSION -g ukbd.o --- virtio_balloon.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/balloon/virtio_balloon.c --- usb_transfer.o --- ctfconvert -L VERSION -g usb_transfer.o --- virtio_scsi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/scsi/virtio_scsi.c --- virtio_blk.o --- ctfconvert -L VERSION -g virtio_blk.o --- if_vx.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/vx/if_vx.c --- virtio_balloon.o --- ctfconvert -L VERSION -g virtio_balloon.o --- watchdog.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/watchdog/watchdog.c ctfconvert -L VERSION -g watchdog.o --- if_wi.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/wi/if_wi.c --- if_vx.o --- ctfconvert -L VERSION -g if_vx.o --- if_xe.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xe/if_xe.c --- if_vtnet.o --- ctfconvert -L VERSION -g if_vtnet.o --- xen_console.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/console/xen_console.c --- virtio_scsi.o --- ctfconvert -L VERSION -g virtio_scsi.o --- grant_table.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/grant_table/grant_table.c --- xen_console.o --- ctfconvert -L VERSION -g xen_console.o --- pvcpu.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/pvcpu/pvcpu.c --- grant_table.o --- ctfconvert -L VERSION -g grant_table.o --- privcmd.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/privcmd/privcmd.c --- pvcpu.o --- ctfconvert -L VERSION -g pvcpu.o --- debug.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/xen/debug/debug.c --- if_wi.o --- ctfconvert -L VERSION -g if_wi.o --- geom_dev.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/geom/geom_dev.c --- debug.o --- ctfconvert -L VERSION -g debug.o --- kern_clock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_clock.c --- privcmd.o --- ctfconvert -L VERSION -g privcmd.o --- kern_cpuset.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_cpuset.c --- if_xe.o --- ctfconvert -L VERSION -g if_xe.o --- kern_ffclock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_ffclock.c --- geom_dev.o --- ctfconvert -L VERSION -g geom_dev.o --- kern_cpuset.o --- /usr/src/sys/kern/kern_cpuset.c:643:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] for (i = 0; i < (_NCPUWORDS - 1); i++) { ~ ^ ~~~~~~~~~~~~~~~~ --- kern_intr.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_intr.c --- kern_clock.o --- ctfconvert -L VERSION -g kern_clock.o WARNING: kern_clock.c: enum pmc_event has too many values: 2588 > 1023 --- kern_mutex.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_mutex.c --- kern_ffclock.o --- ctfconvert -L VERSION -g kern_ffclock.o --- kern_numa.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_numa.c --- kern_cpuset.o --- 1 warning generated. ctfconvert -L VERSION -g kern_cpuset.o --- kern_racct.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_racct.c --- kern_numa.o --- ctfconvert -L VERSION -g kern_numa.o --- kern_rctl.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_rctl.c --- kern_intr.o --- ctfconvert -L VERSION -g kern_intr.o --- kern_timeout.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_timeout.c --- kern_mutex.o --- ctfconvert -L VERSION -g kern_mutex.o WARNING: kern_mutex.c: enum pmc_event has too many values: 2588 > 1023 --- sched_ule.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/sched_ule.c --- kern_racct.o --- ctfconvert -L VERSION -g kern_racct.o --- subr_bus.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus.c --- kern_timeout.o --- ctfconvert -L VERSION -g kern_timeout.o --- subr_bus_dma.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus_dma.c --- kern_rctl.o --- ctfconvert -L VERSION -g kern_rctl.o --- subr_clock.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -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 -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_clock.c --- subr_bus.o --- /usr/src/sys/kern/subr_bus.c:4110:9: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'bus_space_tag_t' (aka 'int') [-Werror,-Wint-conversion] return (NULL); ^~~~~~ /usr/src/sys/kern/subr_bus.c:4607:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'bus_space_tag_t' (aka 'int') [-Werror,-Wint-conversion] return (NULL); ^~~~~~ 2 errors generated. *** [subr_bus.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC --- subr_clock.o --- ctfconvert -L VERSION -g subr_clock.o --- subr_bus_dma.o --- ctfconvert -L VERSION -g subr_bus_dma.o --- sched_ule.o --- ctfconvert -L VERSION -g sched_ule.o 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson8659697514031596143.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Thu Feb 18 16:29:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE2D7AAB2B6 for ; Thu, 18 Feb 2016 16:29:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3F99107B for ; Thu, 18 Feb 2016 16:29:34 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fa3d9c8a-d65c-11e5-8de6-958346fd02ba X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 18 Feb 2016 16:30:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u1IGTQgV032251; Thu, 18 Feb 2016 09:29:26 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1455812966.1294.5.camel@freebsd.org> Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? From: Ian Lepore To: "O. Hartmann" , RW Cc: freebsd-current@freebsd.org Date: Thu, 18 Feb 2016 09:29:26 -0700 In-Reply-To: <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 16:29:34 -0000 On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote: > On Thu, 18 Feb 2016 14:52:44 +0000 > RW wrote: > > > On Thu, 18 Feb 2016 14:16:24 +0100 > > O. Hartmann wrote: > > > > > Hello out there, > > > > > > I run into a problem and digging for a solution didn't work out. > > > > > > Problem: I need a string that reflects the hashed password for the > > > usage with > > > > > > passwd -H 0 > > > > Did you mean -h? > > no, I literally mean -H 0, I explain later ... > > > > > > I think the procedure is using > > > > > > sha512 -s Password > > > > > > and using this output for further processing, but how? > > > > It's not as simple as that, password hashes are usually salted and > > iterated. Salting means that the password is combined with a randomly > > generated string stored in plaintext, which means that the password > > doesn't hash to a fixed string. > > > > I'm not sure exactly what you are trying to do, but crypt(3) may be of > > help. > > I'm now down to a small C routine utilizing crypt(3). But this is not what I > intend to have, since I want to use tools from the FBSD base system. > > I build images of a small appliance in a secure isolated environment via > NanoBSD. I do not want to have passwords in the clear around here, but I also > do not want to type in everytime an image is created, so the idea is to have > passwords prepared as hashes in a local file/in variables. Therefore, I'm > inclined to use the option "-H 0" of the pw(1) command to provide an already > and clean hash (SHA512), which is then stored in /etc/master.passwd. > > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and > they "generate" somehow the hashed password and store that in master.password > - but I didn't find any way to pipe out the writing of the password to the > standard output from that piece of software. Why? Security concerns I forgot to > consider? > > I found lots of articles and howtos to use pipes producing the required > password hashes via passwd, chpasswd or pw, but they all have one problem: I > have to provide somehow the cleartext password in an automated environment. > > Maybe there is something missing ... > > oh We use something like this at work (which I don't fully understand, but it works on freebsd 6.x through 10.x at least)... echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \ pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $* I guess for your use you'd capture and save the output of openssl so you could later feed it back to pw when making images. -- Ian From owner-freebsd-current@freebsd.org Thu Feb 18 15:46:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A3E5AAD957 for ; Thu, 18 Feb 2016 15:46:24 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7F19617DE for ; Thu, 18 Feb 2016 15:46:24 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 7E992AAD955; Thu, 18 Feb 2016 15:46:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6440DAAD954; Thu, 18 Feb 2016 15:46:24 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 110F017DD; Thu, 18 Feb 2016 15:46:23 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWQmV-00044O-IW; Thu, 18 Feb 2016 21:46:16 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1IFlHHV062697; Thu, 18 Feb 2016 21:47:17 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1IFlCMM062651; Thu, 18 Feb 2016 21:47:12 +0600 (NOVT) (envelope-from danfe) Date: Thu, 18 Feb 2016 21:47:12 +0600 From: Alexey Dokuchaev To: John Baldwin Cc: Kevin Oberman , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Message-ID: <20160218154712.GA56997@regency.nsu.ru> References: <53762216.8020205@gmx.net> <537753F3.6000202@FreeBSD.org> <20160218141338.GA15706@regency.nsu.ru> <2846385.IUIOUlEDYf@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2846385.IUIOUlEDYf@ralph.baldwin.cx> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91511 [Feb 18 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3969987, 3970033, 3969585 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 11:55:00 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Thu, 18 Feb 2016 16:33:46 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 15:46:24 -0000 On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote: > > > VESA needs to be removed for i915kms, but I've no idea if it needs to be > > > removed for Nvidia. The video reset code was reworked in 10 so that > > > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, > > > but in theory it works more often. > > > > This (VESA needs to be removed for i915kms) is news to me: I don't see it > > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS > > era) GENERIC kernel config. So what's the real deal here? :-) > > This is an old mail you are responding to. You no longer need to remove > VESA for kms. Ah OK, that would explain it, thanks. > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > emulation in the hardware when it starts which prevents VESA from working > (VESA requires the legacy VGA interface). Hmm, could this explain why vesa.ko can be loaded from loader.conf, but not via kldload(8)? OTOH, kldload'ing it later does not seem to work (ir)regardless of whether i915kms.ko is loaded or not... > I never have to hit the power button more than once to resume on a laptop > where resume works though. > > (True on my X220 and on a T440 both with Intel or Radeon graphics (all > using KMS). I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence I'll ask: do aforementioned laptops suspend/resume without issues in X11 or on the naked console as well? (In a shop, I could only quickly test our X11-less memstick image.) > > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > > and stable/7 FWIW. > > If it worked here, then this means you could try using sc(4) + the old drm > (not drm2). This means your laptop is old enough to still turn the LCD panel > back on in its BIOS during resume like my HP netbook. However, I don't know > for how much longer Xorg will support the older drm (if it even does now). Well, technically, my laptop *does* resume with vt(4) + i915kms, just it takes a lot of power button hits and quite some time (up to several minutes), unless it dies somewhere during the process. I'll retest it against GENERIC and report in a separate email. On a related note, how does one configure sc(4) with old drm (vs. drm2) shall I need to try that? > FWIW, the HP netbook resumes fine with KMS as well for me. One caveat > though is that if you are using vt(4) and haven't yet loaded KMS it won't > resume (due to vt(4) not having the equivalent of VESA). With sc(4) the > netbook was always able to resume. Right. So far, I've been booting, kldloading i915kms.ko, zzz(8), resume. No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like to iron out the issues with the pure console first. ./danfe From owner-freebsd-current@freebsd.org Thu Feb 18 16:41:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8E66AAB91E for ; Thu, 18 Feb 2016 16:41:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83D581D72; Thu, 18 Feb 2016 16:41:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 861BB28438; Thu, 18 Feb 2016 17:41:32 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 82E8C28429; Thu, 18 Feb 2016 17:41:31 +0100 (CET) Message-ID: <56C5F43B.4070202@quip.cz> Date: Thu, 18 Feb 2016 17:41:31 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Lowell Gilbert , Allan Jude CC: freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <56C5E933.8070502@freebsd.org> <44d1rugfcr.fsf@be-well.ilk.org> In-Reply-To: <44d1rugfcr.fsf@be-well.ilk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 16:41:37 -0000 Lowell Gilbert wrote on 02/18/2016 17:20: > Allan Jude writes: > >> On 2016-02-18 10:29, O. Hartmann wrote: > >>> I'm now down to a small C routine utilizing crypt(3). But this is not what I >>> intend to have, since I want to use tools from the FBSD base system. [...] >> I have wanted to bring something like that over for a while, but looking >> at the source for pwhash I decided I'd want to start from scratch. > > "openssl passwd", maybe? It is really old implementation and cannot produce any modern hash than MD5. Miroslav Lachman From owner-freebsd-current@freebsd.org Thu Feb 18 17:11:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D582DAAC8F8 for ; Thu, 18 Feb 2016 17:11:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 9966BFF5; Thu, 18 Feb 2016 17:11:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWS6x-002oNo-KD>; Thu, 18 Feb 2016 18:11:27 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWS6x-0009oP-AJ>; Thu, 18 Feb 2016 18:11:27 +0100 Date: Thu, 18 Feb 2016 18:11:22 +0100 From: "O. Hartmann" To: Ian Lepore Cc: RW , freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218181122.29b8fae2.ohartman@zedat.fu-berlin.de> In-Reply-To: <1455812966.1294.5.camel@freebsd.org> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <1455812966.1294.5.camel@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_//NYOyk_Y3BLQUfXZEhj3wtT"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:11:29 -0000 --Sig_//NYOyk_Y3BLQUfXZEhj3wtT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Feb 2016 09:29:26 -0700 Ian Lepore schrieb: > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote: > > On Thu, 18 Feb 2016 14:52:44 +0000 > > RW wrote: > > =20 > > > On Thu, 18 Feb 2016 14:16:24 +0100 > > > O. Hartmann wrote: > > > =20 > > > > Hello out there, > > > >=20 > > > > I run into a problem and digging for a solution didn't work out. > > > >=20 > > > > Problem: I need a string that reflects the hashed password for the > > > > usage with=20 > > > >=20 > > > > passwd -H 0 =20 > > >=20 > > > Did you mean -h? =20 > >=20 > > no, I literally mean -H 0, I explain later ... > > =20 > > > =20 > > > > I think the procedure is using=20 > > > >=20 > > > > sha512 -s Password > > > >=20 > > > > and using this output for further processing, but how? =20 > > >=20 > > > It's not as simple as that, password hashes are usually salted and > > > iterated. Salting means that the password is combined with a randomly > > > generated string stored in plaintext, which means that the password > > > doesn't hash to a fixed string. > > >=20 > > > I'm not sure exactly what you are trying to do, but crypt(3) may be of > > > help. =20 > >=20 > > I'm now down to a small C routine utilizing crypt(3). But this is not w= hat I > > intend to have, since I want to use tools from the FBSD base system. > >=20 > > I build images of a small appliance in a secure isolated environment via > > NanoBSD. I do not want to have passwords in the clear around here, but = I also > > do not want to type in everytime an image is created, so the idea is to= have > > passwords prepared as hashes in a local file/in variables. Therefore, I= 'm > > inclined to use the option "-H 0" of the pw(1) command to provide an al= ready > > and clean hash (SHA512), which is then stored in /etc/master.passwd. > >=20 > > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw= ) and > > they "generate" somehow the hashed password and store that in master.pa= ssword > > - but I didn't find any way to pipe out the writing of the password to = the > > standard output from that piece of software. Why? Security concerns I f= orgot to > > consider? > >=20 > > I found lots of articles and howtos to use pipes producing the required > > password hashes via passwd, chpasswd or pw, but they all have one probl= em: I > > have to provide somehow the cleartext password in an automated environm= ent. > >=20 > > Maybe there is something missing ... > >=20 > > oh =20 >=20 > We use something like this at work (which I don't fully understand, but > it works on freebsd 6.x through 10.x at least)... >=20 > echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \ > pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $* >=20 > I guess for your use you'd capture and save the output of openssl so > you could later feed it back to pw when making images. >=20 > -- Ian The "openssl passwd -1" refers to MD5 hashes, as I understand the manpage, = but I require at least sha256. With this solution suggested, I'd have the password still = stored in cleartext somewhere - if not read -in via read or similar. If you snip off the openssl portion and substitute "-H0" with "-h0", then t= his is the way I did before - as defined/configured in login.conf (usually in ${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and the pa= ssword seems "salted", prepended by the $6$ characters. I'd like to have something like echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty and store the result in a variable somewhere for use with echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc usermod= -n\ ${username} -H 0 Thanks, oh --Sig_//NYOyk_Y3BLQUfXZEhj3wtT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxfs6AAoJEOgBcD7A/5N87XcH/inka3EdCzZZ+bE1eHyBhuAi 8hi77DJlJcamjA8ylQ+nxJMQHFM8pANwQ/jz745MsiPld5vbtHlXI55P8xN+h8gp ttCqShpZ4AZ6u7wJr2ztKyzn4+o0tGdod01v6Lf8OnC1mHLcJ6dd+MDLpFdvJBK4 T9ZrFMsCAlQkyQ/9uS6nfJVLBb78QJ6PTh9Jj6BB7t/KjOaRBiSTPbhW3mEZueH9 U+EdihBoKi42auiwlaBz8yCkEOc8oS69KZyrZ223ABriXvwHCzxT3lA8t1uqgMZ3 +LavAEA9WXX6mCZsBreVtGPnAF9bheaV3/bRf3oXzbwBDVdaxY3J2kTyu4A6ZXk= =kriY -----END PGP SIGNATURE----- --Sig_//NYOyk_Y3BLQUfXZEhj3wtT-- From owner-freebsd-current@freebsd.org Thu Feb 18 17:16:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4483AACB93 for ; Thu, 18 Feb 2016 17:16:39 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 88A9B15BC for ; Thu, 18 Feb 2016 17:16:39 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6993CDAFC for ; Thu, 18 Feb 2016 17:16:33 +0000 (UTC) Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? To: freebsd-current@freebsd.org References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <1455812966.1294.5.camel@freebsd.org> From: Allan Jude Message-ID: <56C5FC6B.7070408@freebsd.org> Date: Thu, 18 Feb 2016 12:16:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1455812966.1294.5.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:16:39 -0000 On 2016-02-18 11:29, Ian Lepore wrote: > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote: >> On Thu, 18 Feb 2016 14:52:44 +0000 >> RW wrote: >> >>> On Thu, 18 Feb 2016 14:16:24 +0100 >>> O. Hartmann wrote: >>> >>>> Hello out there, >>>> >>>> I run into a problem and digging for a solution didn't work out. >>>> >>>> Problem: I need a string that reflects the hashed password for the >>>> usage with >>>> >>>> passwd -H 0 >>> >>> Did you mean -h? >> >> no, I literally mean -H 0, I explain later ... >> >>> >>>> I think the procedure is using >>>> >>>> sha512 -s Password >>>> >>>> and using this output for further processing, but how? >>> >>> It's not as simple as that, password hashes are usually salted and >>> iterated. Salting means that the password is combined with a randomly >>> generated string stored in plaintext, which means that the password >>> doesn't hash to a fixed string. >>> >>> I'm not sure exactly what you are trying to do, but crypt(3) may be of >>> help. >> >> I'm now down to a small C routine utilizing crypt(3). But this is not what I >> intend to have, since I want to use tools from the FBSD base system. >> >> I build images of a small appliance in a secure isolated environment via >> NanoBSD. I do not want to have passwords in the clear around here, but I also >> do not want to type in everytime an image is created, so the idea is to have >> passwords prepared as hashes in a local file/in variables. Therefore, I'm >> inclined to use the option "-H 0" of the pw(1) command to provide an already >> and clean hash (SHA512), which is then stored in /etc/master.passwd. >> >> It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and >> they "generate" somehow the hashed password and store that in master.password >> - but I didn't find any way to pipe out the writing of the password to the >> standard output from that piece of software. Why? Security concerns I forgot to >> consider? >> >> I found lots of articles and howtos to use pipes producing the required >> password hashes via passwd, chpasswd or pw, but they all have one problem: I >> have to provide somehow the cleartext password in an automated environment. >> >> Maybe there is something missing ... >> >> oh > > We use something like this at work (which I don't fully understand, but > it works on freebsd 6.x through 10.x at least)... > > echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \ > pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $* > > I guess for your use you'd capture and save the output of openssl so > you could later feed it back to pw when making images. > > -- Ian > > _______________________________________________ > 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" > `openssl passwd` only seems to support md5crypt -- Allan Jude From owner-freebsd-current@freebsd.org Thu Feb 18 17:19:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B19B8AACD19 for ; Thu, 18 Feb 2016 17:19:39 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 73D9F1935; Thu, 18 Feb 2016 17:19:39 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWSEr-002qnH-QR>; Thu, 18 Feb 2016 18:19:37 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWSEr-000AZT-H4>; Thu, 18 Feb 2016 18:19:37 +0100 Date: Thu, 18 Feb 2016 18:19:36 +0100 From: "O. Hartmann" To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218181936.7922f0fb.ohartman@zedat.fu-berlin.de> In-Reply-To: <56C5E933.8070502@freebsd.org> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <56C5E933.8070502@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/OG_F7+4Tfa3iRE13fpa6cuK"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:19:39 -0000 --Sig_/OG_F7+4Tfa3iRE13fpa6cuK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Feb 2016 10:54:27 -0500 Allan Jude schrieb: > On 2016-02-18 10:29, O. Hartmann wrote: > > On Thu, 18 Feb 2016 14:52:44 +0000 > > RW wrote: > > =20 > >> On Thu, 18 Feb 2016 14:16:24 +0100 > >> O. Hartmann wrote: > >> =20 > >>> Hello out there, > >>> > >>> I run into a problem and digging for a solution didn't work out. > >>> > >>> Problem: I need a string that reflects the hashed password for the > >>> usage with=20 > >>> > >>> passwd -H 0 =20 > >> > >> Did you mean -h? =20 > >=20 > > no, I literally mean -H 0, I explain later ... > > =20 > >> =20 > >>> I think the procedure is using=20 > >>> > >>> sha512 -s Password > >>> > >>> and using this output for further processing, but how? =20 > >> > >> It's not as simple as that, password hashes are usually salted and > >> iterated. Salting means that the password is combined with a randomly > >> generated string stored in plaintext, which means that the password > >> doesn't hash to a fixed string. > >> > >> I'm not sure exactly what you are trying to do, but crypt(3) may be of > >> help. =20 > >=20 > > I'm now down to a small C routine utilizing crypt(3). But this is not w= hat I > > intend to have, since I want to use tools from the FBSD base system. > >=20 > > I build images of a small appliance in a secure isolated environment via > > NanoBSD. I do not want to have passwords in the clear around here, but = I also > > do not want to type in everytime an image is created, so the idea is to= have > > passwords prepared as hashes in a local file/in variables. Therefore, I= 'm > > inclined to use the option "-H 0" of the pw(1) command to provide an al= ready > > and clean hash (SHA512), which is then stored in /etc/master.passwd. > >=20 > > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw= ) and > > they "generate" somehow the hashed password and store that in master.pa= ssword > > - but I didn't find any way to pipe out the writing of the password to = the > > standard output from that piece of software. Why? Security concerns I f= orgot to > > consider? > >=20 > > I found lots of articles and howtos to use pipes producing the required > > password hashes via passwd, chpasswd or pw, but they all have one probl= em: I > > have to provide somehow the cleartext password in an automated environm= ent. > >=20 > > Maybe there is something missing ... > >=20 > > oh > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > =20 >=20 > pw is using crypt() to turn the raw password into the password hash you > see in master.passwd. >=20 > The sha512 tool cannot do this, as that is 'sha512' (designed to be as > fast as possible), and what crypt() uses is 'sha512crypt' (designed to > be purposefully slow, does 5,000 sha512s by default, but is tunable by > setting rounds=3D10000$ as a prefix to the salt when calling crypt) >=20 > crypt("mypassword", "$6$rounds=3D10000$usesomesillystri"); >=20 > Results in: >=20 > $6$rounds=3D10000$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnGOA= b0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0 >=20 > NetBSD has a command for generating hashes on the command line, pwhash(1) >=20 > I have wanted to bring something like that over for a while, but looking > at the source for pwhash I decided I'd want to start from scratch. >=20 Hallo Allen, thanks for the insight in crypt. I have no information found about crypt()'= s capability of using rounds=3Dxxxx - there is a slide-show floating around referring to= FBSD 10.x and claims, that FreeBSD doesn't have this functionality yet. The manpage for c= rypt(3) doesn't state anything. It is very hard for me to extract those information= s from the docs provided! It would be great, if someone could read about it in the man= pages - did I miss something? And yes, please, start from scratch - I'd like to see something like pwhash= () in FreeBSD ;-) Thank you very much and kind regards, oh --Sig_/OG_F7+4Tfa3iRE13fpa6cuK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxf0oAAoJEOgBcD7A/5N8goYIAI395lfpSn1UaQQ5ttp77P+S +2hO9nVhKU5k7q8nwv8gc2PbRNkVLOFNsLIGAyaQpyNhgfdWpN6TyLRMzZRNfCT5 6JEbActMCf/AG6Vs+cCkXtJRRsD/+ZA1YlIZNyHPVQkqKrdjlyzcl724YPFs/hH9 Xc/zX1POn0Kdap1OVszl+fxLzDZwNzkEHmCbmweVarDGT05MVmFpIqx7WTh8ywRT LgSXSBtwyI3iBIYVRPntN15iBrmOmM616v1trU+8FjbbwnfdJyASmctXk26AkEU3 /iE5H5lNu6yph78cBkhNLtfXvAHqjfoc/+fEzrcV/sNRR3OclXQQtHdnNLtZJ9g= =3Kkz -----END PGP SIGNATURE----- --Sig_/OG_F7+4Tfa3iRE13fpa6cuK-- From owner-freebsd-current@freebsd.org Thu Feb 18 17:20:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E9EAACDC5 for ; Thu, 18 Feb 2016 17:20:55 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 064B61A9B; Thu, 18 Feb 2016 17:20:54 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWSG5-002r9h-C3>; Thu, 18 Feb 2016 18:20:53 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWSG5-000AfP-1C>; Thu, 18 Feb 2016 18:20:53 +0100 Date: Thu, 18 Feb 2016 18:20:52 +0100 From: "O. Hartmann" To: Lowell Gilbert Cc: Allan Jude , freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218182052.34f0fe46.ohartman@zedat.fu-berlin.de> In-Reply-To: <44d1rugfcr.fsf@be-well.ilk.org> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <56C5E933.8070502@freebsd.org> <44d1rugfcr.fsf@be-well.ilk.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/sfATciowLfvSPcstOmh3ILC"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:20:55 -0000 --Sig_/sfATciowLfvSPcstOmh3ILC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Feb 2016 11:20:20 -0500 Lowell Gilbert schrieb: > Allan Jude writes: >=20 > > On 2016-02-18 10:29, O. Hartmann wrote: =20 >=20 > >> I'm now down to a small C routine utilizing crypt(3). But this is not = what I > >> intend to have, since I want to use tools from the FBSD base system. > >>=20 > >> I build images of a small appliance in a secure isolated environment v= ia > >> NanoBSD. I do not want to have passwords in the clear around here, but= I also > >> do not want to type in everytime an image is created, so the idea is t= o have > >> passwords prepared as hashes in a local file/in variables. Therefore, = I'm > >> inclined to use the option "-H 0" of the pw(1) command to provide an a= lready > >> and clean hash (SHA512), which is then stored in /etc/master.passwd. > >>=20 > >> It is really funny: passwd or pw take passwords via stdin (-h 0 with p= w) and > >> they "generate" somehow the hashed password and store that in master.p= assword > >> - but I didn't find any way to pipe out the writing of the password to= the > >> standard output from that piece of software. Why? Security concerns I = forgot to > >> consider? > >>=20 > >> I found lots of articles and howtos to use pipes producing the required > >> password hashes via passwd, chpasswd or pw, but they all have one prob= lem: I > >> have to provide somehow the cleartext password in an automated environ= ment. > >>=20 > >> Maybe there is something missing ... > >>=20 > >> oh > >> _______________________________________________ =20 > > > > pw is using crypt() to turn the raw password into the password hash you > > see in master.passwd. > > > > The sha512 tool cannot do this, as that is 'sha512' (designed to be as > > fast as possible), and what crypt() uses is 'sha512crypt' (designed to > > be purposefully slow, does 5,000 sha512s by default, but is tunable by > > setting rounds=3D10000$ as a prefix to the salt when calling crypt) > > > > crypt("mypassword", "$6$rounds=3D10000$usesomesillystri"); > > > > Results in: > > > > $6$rounds=3D10000$usesomesillystri$CtNyZlpTyzaFTivUi7CCBYAoRBZXxSz1qnnG= OAb0tXB4irc9/ro10S1a3X2JWTNa1tsMZwIprG/H1o3TKOrDt0 > > > > NetBSD has a command for generating hashes on the command line, pwhash(= 1) > > > > I have wanted to bring something like that over for a while, but looking > > at the source for pwhash I decided I'd want to start from scratch. =20 >=20 > "openssl passwd", maybe? As stated in an earlier response, openssl passwd has only md5 (option -1) = and ordinary crypt (-crypt) as digest, I need something more stronger, at least sha256. --Sig_/sfATciowLfvSPcstOmh3ILC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxf10AAoJEOgBcD7A/5N8NK0IALKebHn1jxqF8fyZt1LFtD75 kZosU7C2b8Av385+rVA5XL2ddB3/OBOoCALBpixsQhWO0ekR5Beu534eLylBcIpB 0EHPvT//spwQwkmptF6LNfDUVA51q/DCBKMTViZYQDOKJkzsU5eSpjT0DTRRpqP5 HAGLkpqgfwbbBE7DKGZom6eIHix6ed6Ng5ntsJrq10P4AnrBIDL08hBBynxPnJKM 3nsSrNE+4FER+gaYwarVBYHtT8Endbvk9gP6s9XxarfUBHVctOEsi6u8BRyjovUI Sn0rmxl4bVP3aHqpEhgAWIuIBU1aJ+DrSHJMAEJ1c5xSLEpkm813y4qI42pFlns= =NeUm -----END PGP SIGNATURE----- --Sig_/sfATciowLfvSPcstOmh3ILC-- From owner-freebsd-current@freebsd.org Thu Feb 18 16:55:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 869A1AAC0E6 for ; Thu, 18 Feb 2016 16:55:43 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6B80978D for ; Thu, 18 Feb 2016 16:55:43 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 67CD5AAC0E4; Thu, 18 Feb 2016 16:55:43 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D537AAC0E3; Thu, 18 Feb 2016 16:55:43 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB0E789; Thu, 18 Feb 2016 16:55:42 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWRrY-0003U6-9s; Thu, 18 Feb 2016 22:55:33 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1IGuYwV072968; Thu, 18 Feb 2016 22:56:34 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1IGuTOF072930; Thu, 18 Feb 2016 22:56:29 +0600 (NOVT) (envelope-from danfe) Date: Thu, 18 Feb 2016 22:56:29 +0600 From: Alexey Dokuchaev To: John Baldwin Cc: Jan Henrik Sylvester , Hans Petter Selasky , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" , Kevin Oberman Subject: Re: Thinkpad T410: resume broken Message-ID: <20160218165629.GA64990@regency.nsu.ru> References: <53762216.8020205@gmx.net> <201405231000.30861.jhb@freebsd.org> <20160218143738.GA38066@regency.nsu.ru> <1519677.qimO7W0WJL@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1519677.qimO7W0WJL@ralph.baldwin.cx> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91515 [Feb 18 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3970137, 3970161, 3969585 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 13:06:53 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Thu, 18 Feb 2016 17:23:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 16:55:43 -0000 On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote: > > I've started to observe similar lines in the logs after updating to > > fresh -CURRENT, upon resume (on a different laptop though, not T410): > > > > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER > > acpi0: cleared fixed power button status > > > > If these messages are legit, I'm wondering why I didn't see them on 8.4, > > and if it might affect suspend/resume sequence (broken right now)? > > [...] Your BIOS said "please put this device in D2 during suspend" and your > device's capabilities said "I don't support D2". You can confirm this by > looking up the _S3 method of your _SB_.PCIO device to find out what state is > requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see > what D states are listed as supported. This?: Scope (\_SB) { Name (ECOK, 0x00) Device (PCI0) { Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State { Return (0x02) } ... # pciconf -lc pci0:0:0 hostb0@pci0:0:0:0: class=0x060000 card=0x83191033 chip=0x25908086 rev=0x04 hdr=0x00 cap 09[e0] = vendor (length 9) Intel cap 2 version 1 # pciconf -rb pci0:0:0 0xe0:0xff 09 00 09 21 02 a2 8b 90 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 10 00 00 00 > There's not much we can do if your BIOS lies to us. As long as we can patch ACPI tables, lying BIOS should not be a problem, no? ./danfe From owner-freebsd-current@freebsd.org Thu Feb 18 17:27:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F22AAAD1AF for ; Thu, 18 Feb 2016 17:27:13 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 01E0722D for ; Thu, 18 Feb 2016 17:27:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWSMB-002swe-0f>; Thu, 18 Feb 2016 18:27:11 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWSMA-000BCi-MJ>; Thu, 18 Feb 2016 18:27:10 +0100 Date: Thu, 18 Feb 2016 18:27:09 +0100 From: "O. Hartmann" To: Shawn Webb Cc: freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160218182709.2380b719.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160217134003.GB57405@mutt-hardenedbsd> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rjY1OGvjYDJSxrPce3Rs8SU"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:27:13 -0000 --Sig_/rjY1OGvjYDJSxrPce3Rs8SU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 17 Feb 2016 08:40:03 -0500 Shawn Webb schrieb: > On Wed, Feb 17, 2016 at 02:24:10PM +0100, O. Hartmann wrote: > > It is around now in the media also for non-OS developers: CVE-2015-7547 > > describes a bug in libc which is supposed to affects all Linux versions. > >=20 > > big price question: is FreeBSD > 9.3 also affected? > >=20 > > Some reporters tell us that Linux/UNIX is affected, so sometimes this t= erminus > > is used to prevent the "Linux-nailed" view, but sometimes it also refer= es to > > everything else those people can not imagine but consider them Linux-li= ke. So > > I'm a bit puzzled, since there is no report about *BSD is affected, too. > >=20 > > Thanks in advance for shedding light onto CVE-2015-7547. =20 >=20 > The project that's vulnerable is called "glibc", not "libc". The BSDs > don't use glibc, so the phrase "nothing to see here" applies. glibc > isn't even available in FreeBSD's ports tree. >=20 > TL;DR: FreeBSD is not affected by CVE-2015-7547. >=20 > Thanks, >=20 The article, I refere to, did only mention "libc" and they used the terminus "Linux/UNIX", and this is usually associted by that Linux-folks with the re= st of the UNIX-alike world after their precious Linux. I followed then the explanation of the CVE and that stated very clearly, th= at it is GNU libc. So, I feel better now, but a pity of all that stuff in routers, switc= hes, security appliances utilizing Linux and the penetrated glic. :-) --Sig_/rjY1OGvjYDJSxrPce3Rs8SU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxf7uAAoJEOgBcD7A/5N8RlAIAMDdY9NDFf6G8ElBKl7g/Kz6 Qu/UR45et0lkZoefVhS/T2mX0kM2bT3Jfw3oxE+JEHO2xwv8Xc1GPbu1qKaU+gSN u5EdS8U8WOZzgSkE49t7NJiV3byMZskMIe79CPN79YwVc+NlNt406YSVFzrtjzFW Ci+NCZfUpnh8MkfGrhyicgCwt5Q3vncE6xMykOeRxtUnnGGz26RrHZjmf25FAyl0 DuqD40o46IltXwQsILKY38dxkb8oP4sorvciE8tZc/2f3VywTraJtmnnsFQxwerP dikwge+3yqa+mtWFksZ737ktjoI0zVAw3woaydp3NzK735mxgZlID6Zm8+M/WRg= =+XEZ -----END PGP SIGNATURE----- --Sig_/rjY1OGvjYDJSxrPce3Rs8SU-- From owner-freebsd-current@freebsd.org Thu Feb 18 17:30:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E866AAD325 for ; Thu, 18 Feb 2016 17:30:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 D588C3DE for ; Thu, 18 Feb 2016 17:30:28 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWSPK-002u41-Ip>; Thu, 18 Feb 2016 18:30:26 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWSPK-000BRg-6n>; Thu, 18 Feb 2016 18:30:26 +0100 Date: Thu, 18 Feb 2016 18:30:25 +0100 From: "O. Hartmann" To: Kurt Jaeger Cc: Shawn Webb , freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160218183025.02dd3f14.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160217135028.GR26283@home.opsec.eu> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ZzzL8p7zUTqDqmYcz/u7mqw"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:30:29 -0000 --Sig_/ZzzL8p7zUTqDqmYcz/u7mqw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 17 Feb 2016 14:50:28 +0100 Kurt Jaeger schrieb: > Hi! >=20 > > The project that's vulnerable is called "glibc", not "libc". The BSDs > > don't use glibc, so the phrase "nothing to see here" applies. glibc > > isn't even available in FreeBSD's ports tree. > >=20 > > TL;DR: FreeBSD is not affected by CVE-2015-7547. =20 >=20 > A short note on the www.freebsd.org website would probably be helpful, > as this case will produce a lot of noise. >=20 I'd like to second this! This could be some kind of use for the further pro= pagation of FreeBSD! Many people asked me since yesterday, whether the operating system= I used to base my appliances and work on does have the bug or not.=20 --Sig_/ZzzL8p7zUTqDqmYcz/u7mqw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxf+xAAoJEOgBcD7A/5N8qsMH+wXMGwXt+LC7eGtC1k+ekKXn 6p7qJ1V7SbffmzLA0akWxp3uImZOw1ssPIGWqOyat2djpEhDo7jUsJyiSVpehojB pB95xnZrDjR9jqTz5AEw7pG5vaC9FgZAN910DuJ4qNA5XfHRBRTbK3pgn4svVnDd 55pVsi4mjiZOcdu4JZz0kxveBUDrEpt6rx4M8p2En5KdphDPAfMxJ+UP74q+ltCn +O8ZSB47wwaRDI+8NgcepCbJOBUMslHnhLpX6fqiMnAVVj1FyKxvJex/D4I+ENdg 7s915tM2Bw1naSbVK6hMpwnrCGjGDrcJScGardwCeIrAeIuvDH1eiyqNZyIfQzE= =E0qc -----END PGP SIGNATURE----- --Sig_/ZzzL8p7zUTqDqmYcz/u7mqw-- From owner-freebsd-current@freebsd.org Thu Feb 18 17:37:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7D67AAD6FF for ; Thu, 18 Feb 2016 17:37:54 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 AF6B5BB8; Thu, 18 Feb 2016 17:37:54 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWSWW-0001Wc-Im; Thu, 18 Feb 2016 17:37:52 +0000 Date: Thu, 18 Feb 2016 17:37:52 +0000 From: Gary Palmer To: "O. Hartmann" Cc: Ian Lepore , RW , freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218173752.GC28757@in-addr.com> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <1455812966.1294.5.camel@freebsd.org> <20160218181122.29b8fae2.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160218181122.29b8fae2.ohartman@zedat.fu-berlin.de> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:37:55 -0000 On Thu, Feb 18, 2016 at 06:11:22PM +0100, O. Hartmann wrote: > Am Thu, 18 Feb 2016 09:29:26 -0700 > Ian Lepore schrieb: > > > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote: > > > On Thu, 18 Feb 2016 14:52:44 +0000 > > > RW wrote: > > > > > > > On Thu, 18 Feb 2016 14:16:24 +0100 > > > > O. Hartmann wrote: > > > > > > > > > Hello out there, > > > > > > > > > > I run into a problem and digging for a solution didn't work out. > > > > > > > > > > Problem: I need a string that reflects the hashed password for the > > > > > usage with > > > > > > > > > > passwd -H 0 > > > > > > > > Did you mean -h? > > > > > > no, I literally mean -H 0, I explain later ... > > > > > > > > > > > > I think the procedure is using > > > > > > > > > > sha512 -s Password > > > > > > > > > > and using this output for further processing, but how? > > > > > > > > It's not as simple as that, password hashes are usually salted and > > > > iterated. Salting means that the password is combined with a randomly > > > > generated string stored in plaintext, which means that the password > > > > doesn't hash to a fixed string. > > > > > > > > I'm not sure exactly what you are trying to do, but crypt(3) may be of > > > > help. > > > > > > I'm now down to a small C routine utilizing crypt(3). But this is not what I > > > intend to have, since I want to use tools from the FBSD base system. > > > > > > I build images of a small appliance in a secure isolated environment via > > > NanoBSD. I do not want to have passwords in the clear around here, but I also > > > do not want to type in everytime an image is created, so the idea is to have > > > passwords prepared as hashes in a local file/in variables. Therefore, I'm > > > inclined to use the option "-H 0" of the pw(1) command to provide an already > > > and clean hash (SHA512), which is then stored in /etc/master.passwd. > > > > > > It is really funny: passwd or pw take passwords via stdin (-h 0 with pw) and > > > they "generate" somehow the hashed password and store that in master.password > > > - but I didn't find any way to pipe out the writing of the password to the > > > standard output from that piece of software. Why? Security concerns I forgot to > > > consider? > > > > > > I found lots of articles and howtos to use pipes producing the required > > > password hashes via passwd, chpasswd or pw, but they all have one problem: I > > > have to provide somehow the cleartext password in an automated environment. > > > > > > Maybe there is something missing ... > > > > > > oh > > > > We use something like this at work (which I don't fully understand, but > > it works on freebsd 6.x through 10.x at least)... > > > > echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \ > > pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $* > > > > I guess for your use you'd capture and save the output of openssl so > > you could later feed it back to pw when making images. > > > > -- Ian > > The "openssl passwd -1" refers to MD5 hashes, as I understand the manpage, but I require > at least sha256. With this solution suggested, I'd have the password still stored > in cleartext somewhere - if not read -in via read or similar. > > If you snip off the openssl portion and substitute "-H0" with "-h0", then this is the way > I did before - as defined/configured in login.conf (usually in > ${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and the password seems > "salted", prepended by the $6$ characters. > > I'd like to have something like > > echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty > > and store the result in a variable somewhere for use with > > echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc usermod -n\ > ${username} -H 0 I presume you want to generate the password manually (to eliminate the storage of the cleartext password) and then store the hash in a script somewhere to be reused? How often do you need to generate new hashes? I'm wondering why you can't have a dummy user that you just change the password for when you need a new hash and then grab the crypted password out of /etc/master.passwd Thanks, Gary From owner-freebsd-current@freebsd.org Thu Feb 18 17:53:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69417AADDD1 for ; Thu, 18 Feb 2016 17:53:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 568EB15AD for ; Thu, 18 Feb 2016 17:53:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5555AAADDD0; Thu, 18 Feb 2016 17:53:37 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54CE1AADDCF; Thu, 18 Feb 2016 17:53:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3486C15AC; Thu, 18 Feb 2016 17:53:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE4D6B94E; Thu, 18 Feb 2016 12:53:35 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: Jan Henrik Sylvester , Hans Petter Selasky , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" , Kevin Oberman Subject: Re: Thinkpad T410: resume broken Date: Thu, 18 Feb 2016 09:51:08 -0800 Message-ID: <3029262.DlAcg8ENfU@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160218165629.GA64990@regency.nsu.ru> References: <53762216.8020205@gmx.net> <1519677.qimO7W0WJL@ralph.baldwin.cx> <20160218165629.GA64990@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Feb 2016 12:53:35 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:53:37 -0000 On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote: > On Thu, Feb 18, 2016 at 06:55:03AM -0800, John Baldwin wrote: > > On Thursday, February 18, 2016 08:37:38 PM Alexey Dokuchaev wrote: > > > I've started to observe similar lines in the logs after updating to > > > fresh -CURRENT, upon resume (on a different laptop though, not T410): > > > > > > pcib0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER > > > acpi0: cleared fixed power button status > > > > > > If these messages are legit, I'm wondering why I didn't see them on 8.4, > > > and if it might affect suspend/resume sequence (broken right now)? > > > > [...] Your BIOS said "please put this device in D2 during suspend" and your > > device's capabilities said "I don't support D2". You can confirm this by > > looking up the _S3 method of your _SB_.PCIO device to find out what state is > > requested during suspend and then looking at 'pciconf -lc pci0:0:0' to see > > what D states are listed as supported. > > This?: > > Scope (\_SB) > { > Name (ECOK, 0x00) > Device (PCI0) > { > Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State > { > Return (0x02) > } > ... Yes, this says "please use D2 when going to S3". > # pciconf -lc pci0:0:0 > hostb0@pci0:0:0:0: class=0x060000 card=0x83191033 chip=0x25908086 rev=0x04 hdr=0x00 > cap 09[e0] = vendor (length 9) Intel cap 2 version 1 Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for _SB_.PCI0? That contains the "slot" and "function" as two words, e.g. 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1, don't recall the order off the top of my head). -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 18 17:53:38 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E65FAADDDB for ; Thu, 18 Feb 2016 17:53:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4521E15B3 for ; Thu, 18 Feb 2016 17:53:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 43CDDAADDD7; Thu, 18 Feb 2016 17:53:38 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B006AADDD6; Thu, 18 Feb 2016 17:53:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05BB915B1; Thu, 18 Feb 2016 17:53:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1C7DBB990; Thu, 18 Feb 2016 12:53:37 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: Kevin Oberman , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Date: Thu, 18 Feb 2016 09:48:40 -0800 Message-ID: <9693306.i8x5an8c0H@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160218154712.GA56997@regency.nsu.ru> References: <53762216.8020205@gmx.net> <2846385.IUIOUlEDYf@ralph.baldwin.cx> <20160218154712.GA56997@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Feb 2016 12:53:37 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 17:53:38 -0000 On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote: > On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > > emulation in the hardware when it starts which prevents VESA from working > > (VESA requires the legacy VGA interface). > > Hmm, could this explain why vesa.ko can be loaded from loader.conf, but > not via kldload(8)? OTOH, kldload'ing it later does not seem to work > (ir)regardless of whether i915kms.ko is loaded or not... You might load it from loader.conf but it might then fail with an error about failing to register in dmesg. In that case it is effectively ignored. > > I never have to hit the power button more than once to resume on a laptop > > where resume works though. > > > > (True on my X220 and on a T440 both with Intel or Radeon graphics (all > > using KMS). > > I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence > I'll ask: do aforementioned laptops suspend/resume without issues in X11 > or on the naked console as well? (In a shop, I could only quickly test > our X11-less memstick image.) Once KMS is loaded they resume fine. They require the KMS driver to turn the LCD panel back on. Without KMS they also "resume" but the screen is off so you can't see anything. However, you can type blind and run commands. If the network is up you can ssh into the laptop, etc. after resume. > > > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > > > and stable/7 FWIW. > > > > If it worked here, then this means you could try using sc(4) + the old drm > > (not drm2). This means your laptop is old enough to still turn the LCD panel > > back on in its BIOS during resume like my HP netbook. However, I don't know > > for how much longer Xorg will support the older drm (if it even does now). > > Well, technically, my laptop *does* resume with vt(4) + i915kms, just it > takes a lot of power button hits and quite some time (up to several minutes), > unless it dies somewhere during the process. I'll retest it against > GENERIC and report in a separate email. On a related note, how does one > configure sc(4) with old drm (vs. drm2) shall I need to try that? On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4). For suspend/resume without X that should be sufficient. You would only need the old drm drivers for X. > > FWIW, the HP netbook resumes fine with KMS as well for me. One caveat > > though is that if you are using vt(4) and haven't yet loaded KMS it won't > > resume (due to vt(4) not having the equivalent of VESA). With sc(4) the > > netbook was always able to resume. > > Right. So far, I've been booting, kldloading i915kms.ko, zzz(8), resume. > No X.Org was involved -- given how fragile suspend/resume is ATM, I'd like > to iron out the issues with the pure console first. Note that for the HP netbook, resume in console with vt(4) does not work without KMS (due to vt(4) not supporting VESA). -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 18 18:02:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0884EAAC29B for ; Thu, 18 Feb 2016 18:02:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DE7F61E5F for ; Thu, 18 Feb 2016 18:02:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DD36AAAC299; Thu, 18 Feb 2016 18:02:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCB35AAC298; Thu, 18 Feb 2016 18:02:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A603F1E5D; Thu, 18 Feb 2016 18:02:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id g203so82386063iof.2; Thu, 18 Feb 2016 10:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3LJMvbnyhs+fkpi7SSIrA/5+PWZjYs/diBmt2TmT11c=; b=bXk/pZQx7JDkyW97EkBM+p2dQtEIBhj14UfJYe2wX0KPcmhgD/lTia+KpOQy0A/sxF jV8E34ZVMw63Soq0CXlhP/m1mhkSgt31H6n6ReZ4JorKbVo7137hmBh+euGE25HtAtTh 4Xj1m0gNLf/p1+OoTR3lJKJrhu/jNnTJkph28zgfGuzMEWVxPCUwGj/4WmdZgRQI0Xc1 Nrn6LBUicu+nxYYw4pGjDn2Dw8SVfa3RFDmg/oLGnNvbsPO3vF2Gu64wpo/UpM31ief2 JW0H5o5m6o9+hsUfesZ1qJIWgHb+OlUZQ9FzhvXQqSxwzUkOXmTSReWp+kT3/I8aZ73y z0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3LJMvbnyhs+fkpi7SSIrA/5+PWZjYs/diBmt2TmT11c=; b=TXjk4Uv85PPkvmZf1koV8o05AphVl3sePlewCYhAMPGPbUOpuY6kFeLUgJwf0tV4P3 YhsoMLlwy4wuoYPN90eHnAkohCvjExDbLWLNJKZa6RPlp6mku3mUNVXRBEUDzTEa22Ep jJfF4q1G8sSCm2hmzZGBTbQpHy4ok548o8kA3Ccytz9flBwsWIIqfHvCljGiP2dOrvOf fXSI4FoOxrggdqvvOFoYRtcCCeNcAJiyr+xzd8wtjvc9BnIVegBk27+9/fqZz31VoGcT OEccbftp1ttR2nNoBTvTeb4Gbos0DoumC4jEfqyECTJtD2zWg+rkgMLnJWOZZv5Rmbno 8Z0g== X-Gm-Message-State: AG10YORXRTyz1bkJhuDwnm1K7wUkBMRsJPMi9yVEtrkv/sBCSZjRcmZJRWuP6aU4zjRF29iONcnrqPEA+sk3FQ== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr9749137ioe.123.1455818538099; Thu, 18 Feb 2016 10:02:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.14.19 with HTTP; Thu, 18 Feb 2016 10:02:17 -0800 (PST) In-Reply-To: <9693306.i8x5an8c0H@ralph.baldwin.cx> References: <53762216.8020205@gmx.net> <2846385.IUIOUlEDYf@ralph.baldwin.cx> <20160218154712.GA56997@regency.nsu.ru> <9693306.i8x5an8c0H@ralph.baldwin.cx> Date: Thu, 18 Feb 2016 10:02:17 -0800 X-Google-Sender-Auth: wP_LDl7CZino1XFb_u8zlZGdCC8 Message-ID: Subject: Re: Thinkpad T410: resume broken From: Adrian Chadd To: John Baldwin Cc: Alexey Dokuchaev , Kevin Oberman , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 18:02:19 -0000 [snip] Someone should sit me down with pizza and "help" me just modularise the vesa/fb code so we can use it in vt. It isn't /that/ hard, I've just been preoccupied. -a From owner-freebsd-current@freebsd.org Thu Feb 18 18:21:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F9BBAACD85; Thu, 18 Feb 2016 18:21:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4424AF51; Thu, 18 Feb 2016 18:21:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7C90C344; Thu, 18 Feb 2016 18:21:49 +0000 (UTC) Date: Thu, 18 Feb 2016 18:21:46 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: se@FreeBSD.org, br@FreeBSD.org, zbb@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1339654442.37.1455819709393.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1659777383.33.1455812427140.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1659777383.33.1455812427140.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2371 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:21:49 -0000 FreeBSD_HEAD_i386 - Build #2371 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2371/console Change summaries: 295762 by zbb: Fix build for i386 and arm64 after r295755 - Take bus_space_tag_t type into consideration when returning default, zero value. - Include missing rman.h required by ofw_pci.h 295761 by br: Increase kernel and user VA space. This allows us to boot with more than 128MB of physical memory. Sponsored by: DARPA, AFRL Sponsored by: HEIF5 295760 by se: Make WARNS=6 safe. Tested with Clang 3.7.1, GCC 4.2.1 and GCC 4.8.5 on amd64. From owner-freebsd-current@freebsd.org Thu Feb 18 19:28:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D32FAAC8C4 for ; Thu, 18 Feb 2016 19:28:42 +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 261C819D5 for ; Thu, 18 Feb 2016 19:28:42 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWUFn-000MFJ-Jt; Thu, 18 Feb 2016 20:28:43 +0100 Date: Thu, 18 Feb 2016 20:28:43 +0100 From: Kurt Jaeger To: "O. Hartmann" Cc: freebsd-current Subject: Re: CVE-2015-7547: critical bug in libc Message-ID: <20160218192843.GU26283@home.opsec.eu> References: <20160217142410.18748906@freyja.zeit4.iv.bundesimmobilien.de> <20160217134003.GB57405@mutt-hardenedbsd> <20160217135028.GR26283@home.opsec.eu> <20160218183025.02dd3f14.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160218183025.02dd3f14.ohartman@zedat.fu-berlin.de> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 19:28:42 -0000 Hi! > > A short note on the www.freebsd.org website would probably be helpful, > > as this case will produce a lot of noise. > I'd like to second this! This could be some kind of use for the > further propagation of FreeBSD! > Many people asked me since yesterday, whether the operating system I used to > base my appliances and work on does have the bug or not. There's a link in the News section now to a writeup by des. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Thu Feb 18 20:41:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69EE0AACD5E for ; Thu, 18 Feb 2016 20:41:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 29A80D7B; Thu, 18 Feb 2016 20:41:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aWVNw-003g3l-Ky>; Thu, 18 Feb 2016 21:41:12 +0100 Received: from f052131134.adsl.alicedsl.de ([78.52.131.134] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aWVNw-000QUA-97>; Thu, 18 Feb 2016 21:41:12 +0100 Date: Thu, 18 Feb 2016 21:41:06 +0100 From: "O. Hartmann" To: Gary Palmer Cc: Ian Lepore , RW , freebsd-current@freebsd.org Subject: Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0? Message-ID: <20160218214106.05de26f4.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160218173752.GC28757@in-addr.com> References: <20160218141624.5f560f2d@freyja.zeit4.iv.bundesimmobilien.de> <20160218145244.0b1e4c94@gumby.homeunix.com> <20160218162908.4cf16f6b@freyja.zeit4.iv.bundesimmobilien.de> <1455812966.1294.5.camel@freebsd.org> <20160218181122.29b8fae2.ohartman@zedat.fu-berlin.de> <20160218173752.GC28757@in-addr.com> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/LaI=9lcrup+kZIR31Z9oe1j"; protocol="application/pgp-signature" X-Originating-IP: 78.52.131.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 20:41:15 -0000 --Sig_/LaI=9lcrup+kZIR31Z9oe1j Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Feb 2016 17:37:52 +0000 Gary Palmer schrieb: > On Thu, Feb 18, 2016 at 06:11:22PM +0100, O. Hartmann wrote: > > Am Thu, 18 Feb 2016 09:29:26 -0700 > > Ian Lepore schrieb: > > =20 > > > On Thu, 2016-02-18 at 16:29 +0100, O. Hartmann wrote: =20 > > > > On Thu, 18 Feb 2016 14:52:44 +0000 > > > > RW wrote: > > > > =20 > > > > > On Thu, 18 Feb 2016 14:16:24 +0100 > > > > > O. Hartmann wrote: > > > > > =20 > > > > > > Hello out there, > > > > > >=20 > > > > > > I run into a problem and digging for a solution didn't work out. > > > > > >=20 > > > > > > Problem: I need a string that reflects the hashed password for = the > > > > > > usage with=20 > > > > > >=20 > > > > > > passwd -H 0 =20 > > > > >=20 > > > > > Did you mean -h? =20 > > > >=20 > > > > no, I literally mean -H 0, I explain later ... > > > > =20 > > > > > =20 > > > > > > I think the procedure is using=20 > > > > > >=20 > > > > > > sha512 -s Password > > > > > >=20 > > > > > > and using this output for further processing, but how? =20 > > > > >=20 > > > > > It's not as simple as that, password hashes are usually salted a= nd > > > > > iterated. Salting means that the password is combined with a rand= omly > > > > > generated string stored in plaintext, which means that the passwo= rd > > > > > doesn't hash to a fixed string. > > > > >=20 > > > > > I'm not sure exactly what you are trying to do, but crypt(3) may = be of > > > > > help. =20 > > > >=20 > > > > I'm now down to a small C routine utilizing crypt(3). But this is n= ot what I > > > > intend to have, since I want to use tools from the FBSD base system. > > > >=20 > > > > I build images of a small appliance in a secure isolated environmen= t via > > > > NanoBSD. I do not want to have passwords in the clear around here, = but I also > > > > do not want to type in everytime an image is created, so the idea i= s to have > > > > passwords prepared as hashes in a local file/in variables. Therefor= e, I'm > > > > inclined to use the option "-H 0" of the pw(1) command to provide a= n already > > > > and clean hash (SHA512), which is then stored in /etc/master.passwd. > > > >=20 > > > > It is really funny: passwd or pw take passwords via stdin (-h 0 wit= h pw) and > > > > they "generate" somehow the hashed password and store that in maste= r.password > > > > - but I didn't find any way to pipe out the writing of the password= to the > > > > standard output from that piece of software. Why? Security concerns= I forgot to > > > > consider? > > > >=20 > > > > I found lots of articles and howtos to use pipes producing the requ= ired > > > > password hashes via passwd, chpasswd or pw, but they all have one p= roblem: I > > > > have to provide somehow the cleartext password in an automated envi= ronment. > > > >=20 > > > > Maybe there is something missing ... > > > >=20 > > > > oh =20 > > >=20 > > > We use something like this at work (which I don't fully understand, b= ut > > > it works on freebsd 6.x through 10.x at least)... > > >=20 > > > echo ${password} | openssl passwd -1 -stdin -salt VerySalty | \ > > > pw -V ${IMAGE_CHROOT_DIR}/etc useradd -n ${username} -H0 $* > > >=20 > > > I guess for your use you'd capture and save the output of openssl so > > > you could later feed it back to pw when making images. > > >=20 > > > -- Ian =20 > >=20 > > The "openssl passwd -1" refers to MD5 hashes, as I understand the manpa= ge, but I > > require at least sha256. With this solution suggested, I'd have the pas= sword still > > stored in cleartext somewhere - if not read -in via read or similar. > >=20 > > If you snip off the openssl portion and substitute "-H0" with "-h0", th= en this is the > > way I did before - as defined/configured in login.conf (usually in > > ${IMAGE_CHROOT_DIR}/etc) SHA512 will be used as digest algorithm and th= e password > > seems "salted", prepended by the $6$ characters. > >=20 > > I'd like to have something like > >=20 > > echo ${password} | openssl passwd -sha512 -stdin -salt VerySalty > >=20 > > and store the result in a variable somewhere for use with > >=20 > > echo ${password_salted_sha512_hash} | pw -V ${IMAGE_CHROOT_DIR}/etc use= rmod -n\ > > ${username} -H 0 =20 >=20 > I presume you want to generate the password manually (to eliminate the > storage of the cleartext password) and then store the hash in a script > somewhere to be reused? How often do you need to generate new hashes? Quite often - weekly and the images are numerous. The problem is that I mad= e in the initial phase mistakes - lack of concentration et cetera and several passwo= rds were then worng and the images wrecked (CD/DVD). =20 >=20 > I'm wondering why you can't have a dummy user that you just change the > password for when you need a new hash and then grab the crypted password > out of /etc/master.passwd Well, this idea has also come to my mind - but the efford would be more (sc= ripts to extract ...) and, on the other hand, it's quite non-academic! I'd like a cl= ean solution. passwd() somehow results in such a hash - but passwd writes its hash into a= file, no chance so far to pipe the hash out. As Allen Jude already wrote - OpenBSD d= oes have the desired tool and it seems to me that there is need - in security areas, wer= e OpenBSD has its domain. >=20 > Thanks, >=20 > Gary --Sig_/LaI=9lcrup+kZIR31Z9oe1j Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWxixjAAoJEOgBcD7A/5N8+8QIALkHuyaodcakRVuDdHeHKMFr AsFMYtebd3KrmjWPBUJWyTHNhPq5otafIISR3bY4/GY7e8rEvd/kLjjS3XRWl7bW 22g5Bi9LKwvQV98hlnWU5giy6IsgXfXwORlMEWdXVe+xSTrkmU59GcOtMkv+k0gQ buKE6eQsD0KYRxqmAxJSdnuK5/fI3sUaZt/0AgHJyj1YdKdb5oAoPuWrV9m1ecBq dfICVxyeHVjl8to9mpu2ggcYJ3kP6X4WlHXuu2n2uTIyb5HHQ5sV1Ek/Hwtc+yVb 16QKFG6jiSvhAXko1+aA4euL0wQuYQelA67ALW7eAq6V11we91zXC7d18/nlh7M= =DrO8 -----END PGP SIGNATURE----- --Sig_/LaI=9lcrup+kZIR31Z9oe1j-- From owner-freebsd-current@freebsd.org Thu Feb 18 22:10:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A35AFAAD4F8 for ; Thu, 18 Feb 2016 22:10:42 +0000 (UTC) (envelope-from Michal@dry.pl) Received: from milos.dry.pl (dry.pl [151.80.178.168]) (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 73AC61D3A for ; Thu, 18 Feb 2016 22:10:42 +0000 (UTC) (envelope-from Michal@dry.pl) Received: from mailpile.local (milos [151.80.178.168]) (Authenticated sender: dry) by milos.dry.pl (Postfix) with ESMTPSA id 464468675; Thu, 18 Feb 2016 23:10:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dry.pl; s=dkim; t=1455833440; bh=DQ6sRzjzR4hxhT1qoWgsN6IXrV2kEYIcTOIgN9HrC8U=; h=From:To:Subject:Date; b=Zli/3DWeKUF5kcAGRJXHiUzWyR6EIWCs78sEDcTMml0iKx6lHKDfhZ9NhO8mNQfP9 5YRSh9fNhPehoGDpejWJZmJwEh4gdc21XQjLkEQEAtCVdHrUyC9ED4ej0zxkNUoOSQ q+qHPJnPnOGtV3bWM32jJuUShi1Oah0elu6bRFTo= From: Michal Suszko To: freebsd-current@freebsd.org Subject: buildkernel ULE related breakage Message-ID: <20030707152010.GB39108@dry.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organization: Warsaw School of Economics Status: RO Date: Thu, 18 Feb 2016 22:10:40 -0000 X-Mailman-Approved-At: Thu, 18 Feb 2016 22:13:11 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 18 Feb 2016 22:10:42 -0000 Hi, Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT ( wrapped long lines ) cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function `sched_setup': /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i' *** Error code 1 Stop in /usr/obj/usr/src/sys/TEST. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Michal From owner-freebsd-current@freebsd.org Fri Feb 19 01:50:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34530AAC1F7 for ; Fri, 19 Feb 2016 01:50:07 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 CFDD2BCA for ; Fri, 19 Feb 2016 01:50:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-lb0-x229.google.com with SMTP id x4so39497746lbm.0 for ; Thu, 18 Feb 2016 17:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DJ8K9mACK+cy4lkg/ZpwvaRdRCIO8ESK7+K5xIGIaXA=; b=xd3c+SUcZ1pAiY0bzkENua72eyDOzMYB4OpiWx5jFzWhQ7ekevFJvRyRJ1uGwOOCDn zDFlwnZwUayfEvPeeGcKUgxJLfsyN0qcceATx0ja3fTGRwCIZuEki6JI99sFKBXW3toa AtxarB60NKRZ+T1QUiswyD+D7PfPlidyD1bDuhSk8vOUQM1+DY6woZrkn5dwmtPB5FoE LUEQYCktd+JyZkd/3d6/3+VIeeGUI/aLvvWSywkrBvcfPOgJskhFCfHixfm6ormJ+a8f tDbFsUkFnD6fDFV6szxbb+o4XBna2SelynmJKvzPKCYPAKGP+eB+ZgS2m+pPNkppnDkT 1DsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DJ8K9mACK+cy4lkg/ZpwvaRdRCIO8ESK7+K5xIGIaXA=; b=khyeJIC/KMsjGEzVu0oS4BR7YFu3lowdFvBX/sjdM8mKfaMg4YAampqfdJP5RHVXGP 067fo62wP0ITQ+jH07UN6BAoCypI0WFOMa4IDuPEM+eN83Xiugv4Di1Aokq4MbA4qilN HV4Q6oVFHr8jFIOhFu+d5wqDmuLjaYxTTAsMc6tqNvQkJT8wKjP+WPrkrQXNtEqmKNGF OMZiRyyx98ECEsAhoC9nXxl1UoHR6K+q7dcYATBk1vAuspmLj/SMs4uh0QdbFbkvhpzq WUjfS4fQeP8WbJkkBWuiXYj46+LVN0GR0oMNjHjzPqNWRvp17QLifyX38rJB0M3w/atT 0pXQ== X-Gm-Message-State: AG10YOS0IpeFPyamkwCElCoJ+c/7/Mw8bzMsqjWOWarjLqH/9oGEMwrq8/ZQVA3Ha7kmy8fOsx4f/U7KTsyThg== MIME-Version: 1.0 X-Received: by 10.112.223.37 with SMTP id qr5mr4400876lbc.19.1455846604822; Thu, 18 Feb 2016 17:50:04 -0800 (PST) Received: by 10.112.160.133 with HTTP; Thu, 18 Feb 2016 17:50:04 -0800 (PST) In-Reply-To: <20030707152010.GB39108@dry.pl> References: <20030707152010.GB39108@dry.pl> Date: Thu, 18 Feb 2016 17:50:04 -0800 Message-ID: Subject: Re: buildkernel ULE related breakage From: Ngie Cooper To: Michal Suszko Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 01:50:07 -0000 On Thu, Feb 18, 2016 at 2:10 PM, Michal Suszko wrote: > > Hi, > Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT > ( wrapped long lines ) > > cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath > -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h > -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 > -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c > cc1: warnings being treated as errors > /usr/src/sys/kern/sched_ule.c: In function `sched_setup': > /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/TEST. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. I'm not sure what you're running, but it doesn't look like untainted CURRENT. 1. Please post `TEST` somewhere in pastebin. 2. Please note what revision you're on, whether you're forked from another version, etc. Thanks, -Ngie 526 /* 527 * Load is maintained for all threads RUNNING and ON_RUNQ. Add the load 528 * for this thread to the referenced thread queue. 529 */ 530 static void 531 tdq_load_add(struct tdq *tdq, struct thread *td) 532 { 533 534 TDQ_LOCK_ASSERT(tdq, MA_OWNED); 535 THREAD_LOCK_ASSERT(td, MA_OWNED); 536 537 tdq->tdq_load++; 538 if ((td->td_flags & TDF_NOLOAD) == 0) 539 tdq->tdq_sysload++; 540 KTR_COUNTER0(KTR_SCHED, "load", tdq->tdq_loadname, tdq->tdq_load); 541 SDT_PROBE2(sched, , , load__change, (int)TDQ_ID(tdq), tdq->tdq_load); 542 } From owner-freebsd-current@freebsd.org Fri Feb 19 08:40:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 943E3AAC5C3 for ; Fri, 19 Feb 2016 08:40:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ADB5F138A; Fri, 19 Feb 2016 08:40:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA24802; Fri, 19 Feb 2016 10:40:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aWgbf-0001c4-F9; Fri, 19 Feb 2016 10:40:07 +0200 Subject: Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead) To: Konstantin Belousov References: <56BBAB6E.5050601@FreeBSD.org> <56C08AAA.5050206@FreeBSD.org> <56C1953F.60604@FreeBSD.org> <20160218151321.GR91220@kib.kiev.ua> Cc: alc@FreeBSD.org, FreeBSD Current From: Andriy Gapon Message-ID: <56C6D496.1060509@FreeBSD.org> Date: Fri, 19 Feb 2016 10:38:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160218151321.GR91220@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 08:40:10 -0000 On 18/02/2016 17:13, Konstantin Belousov wrote: > So this is arguably a fallout from r188331. > The following is somewhat non-insistent attempt to fix the problem. Kostik, thank you very much, I am testing the patch. > diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c > index a7e3d37..cddf1eb 100644 > --- a/sys/vm/vm_fault.c > +++ b/sys/vm/vm_fault.c > @@ -291,7 +291,8 @@ vm_fault_hold(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, > struct faultstate fs; > struct vnode *vp; > vm_page_t m; > - int ahead, behind, cluster_offset, error, locked; > + int ahead, behind, cluster_offset, error, locked, rv; > + u_char behavior; > > hardfault = 0; > growstack = TRUE; > @@ -550,9 +551,18 @@ readrest: > * zero-filled pages. > */ > if (fs.object->type != OBJT_DEFAULT) { > - int rv; > - u_char behavior = vm_map_entry_behavior(fs.entry); > - > + if (!fs.lookup_still_valid) { > + locked = vm_map_trylock_read(fs.map); > + if (locked) > + fs.lookup_still_valid = TRUE; > + if (!locked || fs.map->timestamp != > + map_generation) { > + release_page(&fs); > + unlock_and_deallocate(&fs); > + goto RetryFault; > + } > + } > + behavior = vm_map_entry_behavior(fs.entry); > era = fs.entry->read_ahead; > if (behavior == MAP_ENTRY_BEHAV_RANDOM || > P_KILLED(curproc)) { > @@ -603,6 +613,7 @@ readrest: > } > ahead = ulmin(ahead, atop(fs.entry->end - vaddr) - 1); > if (era != nera) > + /* XXX only read-lock on map */ > fs.entry->read_ahead = nera; > > /* > -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Feb 19 11:54:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08D06AAC702 for ; Fri, 19 Feb 2016 11:54:37 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E2EAD140F for ; Fri, 19 Feb 2016 11:54:36 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id DF072AAC700; Fri, 19 Feb 2016 11:54:36 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5600AAC6FF; Fri, 19 Feb 2016 11:54:36 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3733613F0; Fri, 19 Feb 2016 11:54:35 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWjdi-0003fn-SJ; Fri, 19 Feb 2016 17:54:27 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1JBtVc5018050; Fri, 19 Feb 2016 17:55:31 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1JBtQm4018049; Fri, 19 Feb 2016 17:55:26 +0600 (NOVT) (envelope-from danfe) Date: Fri, 19 Feb 2016 17:55:26 +0600 From: Alexey Dokuchaev To: John Baldwin Cc: Kevin Oberman , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Message-ID: <20160219115525.GA12543@regency.nsu.ru> References: <53762216.8020205@gmx.net> <2846385.IUIOUlEDYf@ralph.baldwin.cx> <20160218154712.GA56997@regency.nsu.ru> <9693306.i8x5an8c0H@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9693306.i8x5an8c0H@ralph.baldwin.cx> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91565 [Feb 19 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3971456, 3971494, 3971287 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 13:06:53 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Fri, 19 Feb 2016 12:30:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 11:54:37 -0000 On Thu, Feb 18, 2016 at 09:48:40AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 09:47:12 PM Alexey Dokuchaev wrote: > > On Thu, Feb 18, 2016 at 06:50:34AM -0800, John Baldwin wrote: > > > On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > > > vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA > > > emulation in the hardware when it starts which prevents VESA from > > > working (VESA requires the legacy VGA interface). > > > > Hmm, could this explain why vesa.ko can be loaded from loader.conf, but > > not via kldload(8)? OTOH, kldload'ing it later does not seem to work > > (ir)regardless of whether i915kms.ko is loaded or not... > > You might load it from loader.conf but it might then fail with an error > about failing to register in dmesg. In that case it is effectively > ignored. By "can be loaded from loader.conf" I mean that it's reported in kldstat(8) output. I'm still unsure if I understand all implications of having or not having VESA kernel option or vesa.ko loaded in vt(4)+KMS world. E.g., do I understand correctly that vesa.ko is not needed (or might even cause certain problems) with vt(4)+KMS, and "options VESA" is left in GENERIC as part of syscons(4) support, and will likely go south together with syscons(4) some day? > > I'm about to try fresh -CURRENT on some HP AMD APU-based laptops, hence > > I'll ask: do [Intel or Radeon graphics] laptops suspend/resume without > > issues in X11 or on the naked console as well? (In a shop, I could only > > quickly test our X11-less memstick image.) > > Once KMS is loaded they resume fine. They require the KMS driver to turn > the LCD panel back on. Without KMS they also "resume" but the screen is off > so you can't see anything. However, you can type blind and run commands. > If the network is up you can ssh into the laptop, etc. after resume. > [...] > On HEAD you need to set kern.vty=sc to use sc(4) instead of vt(4). For > suspend/resume without X that should be sufficient. You would only need > the old drm drivers for X. > [...] > Note that for the HP netbook, resume in console with vt(4) does not work > without KMS (due to vt(4) not supporting VESA). OK I see, makes sense. So my best bet would be to try suspend/resume with vt(4)+KMS, then if it fails try with kern.vty=sc (in the context of GENERIC kernel and pure console). ./danfe From owner-freebsd-current@freebsd.org Fri Feb 19 12:00:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE51EAAD124 for ; Fri, 19 Feb 2016 12:00:57 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C38161A07 for ; Fri, 19 Feb 2016 12:00:57 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id C1ED0AAD11D; Fri, 19 Feb 2016 12:00:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1768AAD11C; Fri, 19 Feb 2016 12:00:57 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0BA1A05; Fri, 19 Feb 2016 12:00:57 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWjju-0007Lx-6s; Fri, 19 Feb 2016 18:00:52 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1JC1sG5021917; Fri, 19 Feb 2016 18:01:54 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1JC1n64021909; Fri, 19 Feb 2016 18:01:49 +0600 (NOVT) (envelope-from danfe) Date: Fri, 19 Feb 2016 18:01:49 +0600 From: Alexey Dokuchaev To: Adrian Chadd Cc: John Baldwin , Kevin Oberman , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Message-ID: <20160219120149.GA18684@regency.nsu.ru> References: <53762216.8020205@gmx.net> <2846385.IUIOUlEDYf@ralph.baldwin.cx> <20160218154712.GA56997@regency.nsu.ru> <9693306.i8x5an8c0H@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91565 [Feb 19 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3971469, 3971510, 3971287 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; regency.nsu.ru:7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; bugs.freebsd.org:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 13:06:53 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Fri, 19 Feb 2016 12:32:15 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 12:00:58 -0000 On Thu, Feb 18, 2016 at 10:02:17AM -0800, Adrian Chadd wrote: > [snip] > > Someone should sit me down with pizza and "help" me just modularise > the vesa/fb code so we can use it in vt. > > It isn't /that/ hard, I've just been preoccupied. And before it happens, someone(tm) could write a few paragraphs of current state of affairs and codependencies between sc(4), vt(4), and VESA. :-) Hopefully this would lower the degree of "black magic" surrounding this code and help with some [1] related PRs. ./danfe [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174504 From owner-freebsd-current@freebsd.org Fri Feb 19 12:37:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36324AAE4D4 for ; Fri, 19 Feb 2016 12:37:40 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3D81333 for ; Fri, 19 Feb 2016 12:37:40 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 1BEDFAAE4D1; Fri, 19 Feb 2016 12:37:40 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B690AAE4D0; Fri, 19 Feb 2016 12:37:40 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB0901332; Fri, 19 Feb 2016 12:37:39 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1aWkJL-0001Bg-JD; Fri, 19 Feb 2016 18:37:28 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id u1JCcWdE030139; Fri, 19 Feb 2016 18:38:32 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id u1JCcRtB030110; Fri, 19 Feb 2016 18:38:27 +0600 (NOVT) (envelope-from danfe) Date: Fri, 19 Feb 2016 18:38:27 +0600 From: Alexey Dokuchaev To: John Baldwin Cc: current@freebsd.org, mobile@freebsd.org Subject: Re: Thinkpad T410: resume broken Message-ID: <20160219123827.GA27878@regency.nsu.ru> References: <53762216.8020205@gmx.net> <1519677.qimO7W0WJL@ralph.baldwin.cx> <20160218165629.GA64990@regency.nsu.ru> <3029262.DlAcg8ENfU@ralph.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3029262.DlAcg8ENfU@ralph.baldwin.cx> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 91566 [Feb 19 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3971555, 3971593, 3971287 X-KLMS-AntiSpam-Info: LuaCore: 414 414 652141367f63b6038f5642fa97308d3a9d2edb46, 127.0.0.200:7.1.3; people.freebsd.org:7.1.1; regency.nsu.ru:7.1.1; 193.124.210.26:7.1.3,7.1.2,7.3.4; nsu.ru:7.1.1; 127.0.0.199:7.1.2; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/02/18 13:06:53 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Mailman-Approved-At: Fri, 19 Feb 2016 13:19:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 12:37:40 -0000 On Thu, Feb 18, 2016 at 09:51:08AM -0800, John Baldwin wrote: > On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote: > > # pciconf -lc pci0:0:0 > > hostb0@pci0:0:0:0: class=0x060000 card=0x83191033 chip=0x25908086 rev=0x04 hdr=0x00 > > cap 09[e0] = vendor (length 9) Intel cap 2 version 1 > > Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for > _SB_.PCI0? That contains the "slot" and "function" as two words, e.g. > 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1, > don't recall the order off the top of my head). Seems it's all zeros: Device (PCI0) { ... Name (_ADR, 0x00) // _ADR: Address I've uploaded the dump on freefall [1], perhaps I've missed something so you can have a better/sharper look. ./danfe [1] http://people.freebsd.org/~danfe/nec_versa_s950.asl From owner-freebsd-current@freebsd.org Fri Feb 19 14:56:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88AA6AAD5CE for ; Fri, 19 Feb 2016 14:56:04 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from vps.amdmi3.ru (vps.amdmi3.ru [109.234.38.216]) by mx1.freebsd.org (Postfix) with ESMTP id 54E431EB0; Fri, 19 Feb 2016 14:56:03 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from hive.panopticon (unknown [78.153.152.119]) by vps.amdmi3.ru (Postfix) with ESMTPS id 970A5B0615; Fri, 19 Feb 2016 17:55:56 +0300 (MSK) Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 6D07D851; Fri, 19 Feb 2016 17:53:52 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id CDF48D2; Fri, 19 Feb 2016 17:55:11 +0300 (MSK) Date: Fri, 19 Feb 2016 17:55:11 +0300 From: Dmitry Marakasov To: Ed Maste Cc: FreeBSD Current Subject: Re: Call for testing: Using ELF Tool Chain elfcopy as objcopy Message-ID: <20160219145511.GG63762@hades.panopticon> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 14:56:04 -0000 * Ed Maste (emaste@freebsd.org) wrote: JFYI, I've just updated my desktop to 295763 with WITH_ELFCOPY_AS_OBJCOPY=yes, and rebuilt all ~800 installed ports, no problems so far. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://amdmi3.ru From owner-freebsd-current@freebsd.org Fri Feb 19 16:52:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F0C6AAE73B for ; Fri, 19 Feb 2016 16:52:47 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 CF8971EA1 for ; Fri, 19 Feb 2016 16:52:46 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from [176.158.145.63] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWoIO-0000sT-Ra for freebsd-current@freebsd.org; Fri, 19 Feb 2016 17:52:44 +0100 Subject: Re: Thinkpad T410: resume broken To: freebsd-current@freebsd.org References: <53762216.8020205@gmx.net> <537753F3.6000202@FreeBSD.org> <20160218141338.GA15706@regency.nsu.ru> <2846385.IUIOUlEDYf@ralph.baldwin.cx> <20160218154712.GA56997@regency.nsu.ru> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= X-Enigmail-Draft-Status: N1110 Message-ID: <56C74858.5060602@dumbbell.fr> Date: Fri, 19 Feb 2016 17:52:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160218154712.GA56997@regency.nsu.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EVVlIULlQx2D3lnXwEIijdIxg2kWsvIXg" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 16:52:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EVVlIULlQx2D3lnXwEIijdIxg2kWsvIXg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 18/02/2016 16:47, Alexey Dokuchaev wrote: > On a related note, how does one configure sc(4) with old drm (vs. > drm2) shall I need to try that? Hi! xf86-video-intel and xf86-video-ati do not handle modesetting for a long time now (almost three years), so they can't be used with the old "drm" (only "drm2"). We don't have xf86-video-nouveau for the same reason. You can't use older versions of those xf86-video-* (ie. those doing user modesetting) because they are not supported anymore by the X.Org server. That was the whole WITH_NEW_XORG drama. --=20 Jean-S=E9bastien P=E9dron --EVVlIULlQx2D3lnXwEIijdIxg2kWsvIXg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWx0hYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMR3IP/jf+oFrjUSd/wdCYp1EpjVbp w/VNc/s9KVrYhrAx374/OZlrCOB2KzHnMJrFeg3uUFeHIa/9Cg4QnzgD1web2tvr 0z2muNSyCilhuT3PROjnY0cPJ2h2fYsL7NoMApr75RRUJwlCG5iZQNPlBNgA1CmK rH7EtYFYao8T8poFJSXu65oZr/lMQ0Gq0fzMZkcAhwHmy5l4h/PStLtvKBEMHBRA OlE9hOhVzVKFcNfWYv36Vlb0qYnV/JskQctVcNK6NaY3WE8YS5zYBZbFvBBWW0ym N2wSFMgfBG/ut5mq/MLzvIaeXjsjO8G34UlVJ4g50ecZeO+iM2LX4NlRAnIgyeZg tGZRnOprnm/pf8NNlpXPu7H4JbWSI52DwlaX1ZOvumJ03SJnbdcp8UegDLMErJkc hSF4n1K8JRR7P3f2gZCPUwpTXnWsaVe910H9Bd7IeN5Jz75h9AqT5hylWz3pUAFV pe4xamSyw1mhtQfFB99hfTM6zRzXM/itjD6FWQ/f0tVWxF8kr5pHzVdXfVpzQe81 OCFuRLU2GJ0TZZNV9WY4FwxBK12VFnmRa3DSroDmF23lV9zHaJOfDEWOZQ42BbIp voU4J4oY4oFuul8BPQ6/pX99mdtfTUmmbPswao/f0FnwBTClz1jeDVEGmKSxOIAh ObvlVJ47FDF3Xm8be2HX =MajV -----END PGP SIGNATURE----- --EVVlIULlQx2D3lnXwEIijdIxg2kWsvIXg-- From owner-freebsd-current@freebsd.org Fri Feb 19 19:17:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60C8EAAE3D9 for ; Fri, 19 Feb 2016 19:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFAA13B6 for ; Fri, 19 Feb 2016 19:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4AB6FAAE3D4; Fri, 19 Feb 2016 19:17:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A2B6AAE3CF; Fri, 19 Feb 2016 19:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C24513B4; Fri, 19 Feb 2016 19:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 74EF8B946; Fri, 19 Feb 2016 14:17:25 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: current@freebsd.org, mobile@freebsd.org Subject: Re: Thinkpad T410: resume broken Date: Fri, 19 Feb 2016 10:48:56 -0800 Message-ID: <1677027.G58VU7gWm8@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160219123827.GA27878@regency.nsu.ru> References: <53762216.8020205@gmx.net> <3029262.DlAcg8ENfU@ralph.baldwin.cx> <20160219123827.GA27878@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Feb 2016 14:17:25 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 19 Feb 2016 19:17:27 -0000 On Friday, February 19, 2016 06:38:27 PM Alexey Dokuchaev wrote: > On Thu, Feb 18, 2016 at 09:51:08AM -0800, John Baldwin wrote: > > On Thursday, February 18, 2016 10:56:29 PM Alexey Dokuchaev wrote: > > > # pciconf -lc pci0:0:0 > > > hostb0@pci0:0:0:0: class=0x060000 card=0x83191033 chip=0x25908086 rev=0x04 hdr=0x00 > > > cap 09[e0] = vendor (length 9) Intel cap 2 version 1 > > > > Humm, perhaps PCI0 is not at 0:0. Can you find the _ADR method for > > _SB_.PCI0? That contains the "slot" and "function" as two words, e.g. > > 0x10002 would correspond to the 'pci0:1:2' device (or possibly pci0:2:1, > > don't recall the order off the top of my head). > > Seems it's all zeros: > > Device (PCI0) > { > ... > Name (_ADR, 0x00) // _ADR: Address > > I've uploaded the dump on freefall [1], perhaps I've missed something so > you can have a better/sharper look. Ok, so your BIOS is just odd / broken. It's asked us to power that device down to D2, but it doesn't support any power management at all, so we whine. In practice it should be harmless and something you can ignore. -- John Baldwin From owner-freebsd-current@freebsd.org Sat Feb 20 03:32:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2335AAE9EE for ; Sat, 20 Feb 2016 03:32:28 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 852A3D63 for ; Sat, 20 Feb 2016 03:32:28 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=FZiufpIwPXlI0RkEEnY4h7R3TDAeBCToXJGRq2rWPBw=; b=b59ubKidbXPu4e84hpL6Gmclrt H6FhDsj1pETj6awRdzNw2LjOtKUEMGKFsPgVgzSbHFZQ3KYhUr21omiJwD9+88cbh6BgwLjjQkQGe 7IqArgqpJ4zm7REVddNotiOwRXco0X7/Xbz0fgqEOCH3Nn49rree/ljZjXIP9hPXLqoc=; Received: from [2605:6000:ec17:200:2247:47ff:fe73:75f] (port=26552 helo=lrosenman-dell.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWyHT-0004NC-Gy for freebsd-current@freebsd.org; Fri, 19 Feb 2016 21:32:27 -0600 Date: Fri, 19 Feb 2016 21:32:15 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Realtek MMC/MMCSD reader? Message-ID: <20160220033215.GB988@lrosenman-dell.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 03:32:28 -0000 Any chance of supporting: none7@pci0:6:0:0: class=0xff0000 card=0x522a10ec chip=0x522a10ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' Thanks! From owner-freebsd-current@freebsd.org Sat Feb 20 03:48:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DD21AAEF98 for ; Sat, 20 Feb 2016 03:48:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2FE6148A for ; Sat, 20 Feb 2016 03:48:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk0-x229.google.com with SMTP id s5so38592307qkd.0 for ; Fri, 19 Feb 2016 19:48:03 -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:date:message-id:subject :from:to:content-type; bh=iYlmwpyEYgTpajxZqw5InBKDlJp6n1jZWDzWP/8zb2c=; b=1AWH8wr4Z9KqQnkPYhvgB5oyYZbIZ1aTsZ72M0dimWAjl7zubOo2SqAOXdOas0uwmP 5mQBHv8dbKlO33PD6eZym2zbXvJ4blG97WsUVslfZq81cjwGSr1QCasCgqWBsi0uxM/r Vesd1IcyOz0+zE4VqAEL047ATjublDlrjTwQzlvVO/JuBC+ZCCHrtXDjpDqKC/5o49oU byCiU1f0KjE25j4bFTdWc3J40dsQQjmemxd1Z5ZGC+yNr3VztKWNXxDIhLtSCXAwa7b1 DnMufiyae/Y0bAg6Yjk3ZwIqKigzWBjLDl4NjRrPFmoiVW+JZztBFw1CQBkl96U9bOIg fy2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=iYlmwpyEYgTpajxZqw5InBKDlJp6n1jZWDzWP/8zb2c=; b=moYRXbBhrWkpYUogcbNzcWn/FyDkyQZHFeMsbpIRSpdHrXQ5RB0OJ+fsJqmNaNOEKZ 5YNPBCj6nNjQ1sJnEeqrn+KPFz8ETTV+yRgIJxKLw/XqCV9TvkOZPDDnGYztBWUbCuS2 2hvJuDXd6WzKJhlgzkVIat1fZC/YfBRcy1vBkC0gCExDVhHcFhxq/THtzwuEl3DHOh25 Crv6/HyjsnsZx1xwcL8g5mVStylhRonfMayVI3DBMDv3wTkMm/Wy+pHgfxC3IQjfoSGT 1XNhHXh+o0oFzs7Oz0KwHp44QLFVht0xojmLy6Nui8X2I61TOZl6gnGe0l+cg7HUMeoL 41sw== X-Gm-Message-State: AG10YORYS6GSH/N0J5fy8+PwMYyVcVF7TDokngF0RAZCje7v+Z+/QeAvRyg5TYarucrxHv2lNO9H3sf9sUQoRA== MIME-Version: 1.0 X-Received: by 10.55.81.87 with SMTP id f84mr20638416qkb.10.1455940082836; Fri, 19 Feb 2016 19:48:02 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Fri, 19 Feb 2016 19:48:02 -0800 (PST) X-Originating-IP: [2607:fb90:123:4b5c:0:50:4738:7301] Received: by 10.140.30.166 with HTTP; Fri, 19 Feb 2016 19:48:02 -0800 (PST) In-Reply-To: <20160220033215.GB988@lrosenman-dell.lerctr.org> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> Date: Fri, 19 Feb 2016 20:48:02 -0700 X-Google-Sender-Auth: 1bmXFT23iAsHj75-f5aeJ-8zH5U Message-ID: Subject: Re: Realtek MMC/MMCSD reader? From: Warner Losh To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 03:48:04 -0000 You'll have to write a driver for it. Warner On Feb 19, 2016 8:32 PM, "Larry Rosenman" wrote: > Any chance of supporting: > > none7@pci0:6:0:0: class=0xff0000 card=0x522a10ec chip=0x522a10ec > rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > > > Thanks! > _______________________________________________ > 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 Sat Feb 20 03:58:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1796AAAF314 for ; Sat, 20 Feb 2016 03:58:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECAF119C3 for ; Sat, 20 Feb 2016 03:58:34 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date; bh=1hPohIs3ZKOMAf1p1urAeAtm+nEcPlrIJHjERlEwcVw=; b=tItU tQc+L2nGCzhF4jiWXgTD3gwa8qQ+QsTYKctRa2mntht9cVQlQxayGWPtuVVi6hs4AH1+C7M3ZhC/a 0wOuHSulw8pzwmSgaZJ6t8PQFLdIMdLMWFt4t9q+69B0sWNAfqyHJq+tqo5wB7aMHZhtQRDT9NI31 Pm32/vwOWuuDE=; Received: from [2605:6000:ec17:200:2247:47ff:fe73:75f] (port=30220 helo=lrosenman-dell.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWygj-00054A-St for freebsd-current@freebsd.org; Fri, 19 Feb 2016 21:58:34 -0600 Date: Fri, 19 Feb 2016 21:58:22 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: Realtek MMC/MMCSD reader? Message-ID: <20160220035821.GA57181@lrosenman-dell.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20160220033215.GB988@lrosenman-dell.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 03:58:35 -0000 Great. Since I've never done that.... Any ideas of anyone that might be able to help? Or where to even start? On Fri, Feb 19, 2016 at 08:48:02PM -0700, Warner Losh wrote: > You'll have to write a driver for it. > > Warner > On Feb 19, 2016 8:32 PM, "Larry Rosenman" wrote: > > > Any chance of supporting: > > > > none7@pci0:6:0:0: class=0xff0000 card=0x522a10ec chip=0x522a10ec > > rev=0x01 hdr=0x00 > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > > > > Thanks! > > _______________________________________________ > > 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" From owner-freebsd-current@freebsd.org Sat Feb 20 04:05:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 607ABAAF5A7 for ; Sat, 20 Feb 2016 04:05:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 DB5EA1E0D for ; Sat, 20 Feb 2016 04:05:57 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id g62so95820505wme.0 for ; Fri, 19 Feb 2016 20:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=75oDpMNJNbzHeWdDq8da1s85qw6BzEY/cTDgq9fcszM=; b=Phd/+DajNAsvYE+eqmxgc1fPuzTAKyC4Yx7onHMewqZyH0vwmQADZzw6sLdNmHkd0l 8MnWSKwYWvKHzUCmiJSm1sF0xNdVX3XkM37lHg+g/ucVW9P2c1d1mLMAI/rkP6g2sqxK hJ2h0BDRcx6Ssi2pQrz/ASxqUoLMXFxrS6/2uRro7EBF+e6fmjRa2wDZH+4Ox6zEg0Kr 5ZoJokrG3qRFCKcdvIE9HAjHDQ6tZm/XttvF9a8ULdVqszMv0TaqYIhUHr5mGFaZz88i 3sVdy5pgNzNJqkLEXOqta0IUOL1XAnSfmpTtdcT6g4qpLSKc+lKLcbF5AfPZdRmeJEJ6 ujqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=75oDpMNJNbzHeWdDq8da1s85qw6BzEY/cTDgq9fcszM=; b=ZCBegTn/Q/PXt5vyziK5rWIrVwgI3J1OS7MswOsj1Rc0rK8pNWOTtXEqfaS5Svl68L EFxfrTs0oCNtJoIA+b522Z1w4MdbG3VX/GAZqb2SqQv3c7wijfVmwrzNgcakTXMc/mcP XN5vVLqsWRYwqm5/8N99bn9khvZbqFLzwEbUAmHKhL98NMnBEvOoeGECF53BqnJ+7CWI NorNAzRzfPnIGFjjvkVCnZI4sj5/Ra2Ya68Xt9zjiIUa8hbMhgrq8aYPgvWqJSpWyvxX ixcNfoaBm1X3KQjOpO1sPn58VEuMzE4UhrUWHUwnk55UgYyTdlf+b07Z25H3ykHrBp6A cEBw== X-Gm-Message-State: AG10YOQh+10L672htDFFl18L6NOlNB7CaHKM6RnyBCAvjUrgI9q4Lz1Fe3r98O2nztvTkte89j6GomyaaY4abQ== MIME-Version: 1.0 X-Received: by 10.28.51.9 with SMTP id z9mr497118wmz.59.1455941156331; Fri, 19 Feb 2016 20:05:56 -0800 (PST) Received: by 10.27.139.195 with HTTP; Fri, 19 Feb 2016 20:05:56 -0800 (PST) In-Reply-To: <20160220035821.GA57181@lrosenman-dell.lerctr.org> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> Date: Fri, 19 Feb 2016 20:05:56 -0800 Message-ID: Subject: Re: Realtek MMC/MMCSD reader? From: Mehmet Erol Sanliturk To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 04:05:58 -0000 On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman wrote: > Great. Since I've never done that.... > > Any ideas of anyone that might be able to help? > > Or where to even start? > > > Perhaps https://www.nostarch.com/bsddrivers.htm FreeBSD Device Drivers ? Mehmet Erol Sanliturk > On Fri, Feb 19, 2016 at 08:48:02PM -0700, Warner Losh wrote: > > You'll have to write a driver for it. > > > > Warner > > On Feb 19, 2016 8:32 PM, "Larry Rosenman" wrote: > > > > > Any chance of supporting: > > > > > > none7@pci0:6:0:0: class=0xff0000 card=0x522a10ec chip=0x522a10ec > > > rev=0x01 hdr=0x00 > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > > > > > > > Thanks! > > > _______________________________________________ > > > 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" > _______________________________________________ > 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 Sat Feb 20 04:08:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F2B3AAF656; Sat, 20 Feb 2016 04:08:43 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DD801F45; Sat, 20 Feb 2016 04:08:43 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=bf5slLBQSxiAR4lDGs7qR9W3VpBHoOACigdrVfasniE=; b=NvAMaAs2f+BT0K1dGb0WWswqlY igfhcHyK1HxV2D6FQBBUn2jBobdZvcfKkJRMtJbgjQrNqd1LY5RgP9FA5GyMPVY7VN2wS7Ckjok+T 7a0XIyl/9xNiA7MgWomkO95rxqIoiH5CTyKpAmwBkjcbVZfA8xun/KHR5Exx7uO328kc=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:20701 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWyqX-0005Kc-9H; Fri, 19 Feb 2016 22:08:41 -0600 Received: from 2605:6000:ec17:200:20a8:2140:b873:6ca9 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 19 Feb 2016 22:08:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Feb 2016 22:08:41 -0600 From: Larry Rosenman To: Mehmet Erol Sanliturk Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Realtek MMC/MMCSD reader? In-Reply-To: References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 04:08:43 -0000 On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: > On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman wrote: > >> Great. Since I've never done that.... >> >> Any ideas of anyone that might be able to help? >> >> Or where to even start? >> >> >> > > > Perhaps > > https://www.nostarch.com/bsddrivers.htm > FreeBSD Device Drivers > > > ? > > > Mehmet Erol Sanliturk > > perhaps. But I'd need an NDA with RealTek to get the chip specs, and I'm not sure I can do that working for Nokia during the day as I do. I'd love for one of the current folks that do realtek stuff to look. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 04:29:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1188AAFC49 for ; Sat, 20 Feb 2016 04:29:56 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp.rcn.com (smtp-fo.rcn.cmh.synacor.com [69.168.97.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 8BE9AC4D for ; Sat, 20 Feb 2016 04:29:55 +0000 (UTC) (envelope-from gcorcoran@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=ZulNU4PG c=1 sm=1 tr=0 a=jCH78jcaBILaJ1B6H+di6A==:117 a=jCH78jcaBILaJ1B6H+di6A==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=6VqBrpBaAAAA:8 a=rWQgXGXZAAAA:8 a=uJJb9Q7RqX-hdRtFIzAA:9 a=pILNOxqGKmIA:10 a=WTkvQHiFTPwA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: Z2NvcmNvcmFuQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=gcorcoran@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=gcorcoran@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=gcorcoran; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 64.121.14.202 is neither permitted nor denied by domain of rcn.com) Received: from [64.121.14.202] ([64.121.14.202:64280] helo=[10.56.78.185]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPA id 82/C9-31527-2CBE7C65; Fri, 19 Feb 2016 23:29:54 -0500 Subject: Re: Realtek MMC/MMCSD reader? To: freebsd-current@freebsd.org References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> From: Gary Corcoran Message-ID: <56C7EAC9.1050908@rcn.com> Date: Fri, 19 Feb 2016 23:25:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 04:29:56 -0000 On 2/19/2016 11:08 PM, Larry Rosenman wrote: > On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: >> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman wrote: >> >>> Great. Since I've never done that.... >>> >>> Any ideas of anyone that might be able to help? >>> >>> Or where to even start? >>> >>> >>> >> >> >> Perhaps >> >> https://www.nostarch.com/bsddrivers.htm >> FreeBSD Device Drivers >> >> >> ? >> >> >> Mehmet Erol Sanliturk >> >> > perhaps. But I'd need an NDA with RealTek to get the chip specs, and I'm not sure I can do that working for Nokia during the day > as I do. > > I'd love for one of the current folks that do realtek stuff to look. Sometimes people look to see if Linux has a driver, and if so, you might be able to get enough programming info from their driver to be able to write a FreeBSD driver, without getting the full chip specs. Gary From owner-freebsd-current@freebsd.org Sat Feb 20 05:02:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCA5CAADF36; Sat, 20 Feb 2016 05:02:27 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB3819F; Sat, 20 Feb 2016 05:02:27 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=7fQfrEVC1tg8RcpF3QS3aILw0qqYMwym/3RqHz8GT2g=; b=IMX/AF4Ip2tcYGzI1gt+0T+PIP FhwNDVRRnEKr8ETh8uaffn5A2ItRbDiGHM7yp4wk52S8oJrExMOVxM87vbbS5eIoUVg5YaQNniXCc 5p3719ppnF6vPQj4woHfF2PzhFPtH0gAV8H4zkz7DugjbZicX2qATp7d+zsuFNU/DHag=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:14328 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWzgY-0006gE-KD; Fri, 19 Feb 2016 23:02:26 -0600 Received: from 2605:6000:ec17:200:20a8:2140:b873:6ca9 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 19 Feb 2016 23:02:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Feb 2016 23:02:26 -0600 From: Larry Rosenman To: Gary Corcoran Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Realtek MMC/MMCSD reader? In-Reply-To: <56C7EAC9.1050908@rcn.com> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> <56C7EAC9.1050908@rcn.com> Message-ID: <2c70336f78b550e1b8964ab21fd9b138@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 05:02:28 -0000 On 2016-02-19 22:25, Gary Corcoran wrote: > On 2/19/2016 11:08 PM, Larry Rosenman wrote: >> On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: >>> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman >>> wrote: >>> >>>> Great. Since I've never done that.... >>>> >>>> Any ideas of anyone that might be able to help? >>>> >>>> Or where to even start? >>>> >>>> >>>> >>> >>> >>> Perhaps >>> >>> https://www.nostarch.com/bsddrivers.htm >>> FreeBSD Device Drivers >>> >>> >>> ? >>> >>> >>> Mehmet Erol Sanliturk >>> >>> >> perhaps. But I'd need an NDA with RealTek to get the chip specs, and >> I'm not sure I can do that working for Nokia during the day >> as I do. >> >> I'd love for one of the current folks that do realtek stuff to look. > Sometimes people look to see if Linux has a driver, and if so, you > might be able to get enough > programming info from their driver to be able to write a FreeBSD > driver, without getting the > full chip specs. > > Gary > http://askubuntu.com/questions/731093/sd-card-reader-realtek-522a-not-working-in-dell-i7559-in-ubuntu-15-10 I'm still VERY much a newbie (like ZERO experience) writing drivers. Does anyone want to help? I'm more than willing to guinea pig stuff. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 05:19:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 013D4AAE4BA for ; Sat, 20 Feb 2016 05:19:55 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D62A37B3 for ; Sat, 20 Feb 2016 05:19:54 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=gnonUayHy1IjQP49vmts3WbioyR7koLY0ku/hG/uRGc=; b=ckqy+eT89+y4elnhkR9UvNg2qV ZuQT9MC63e/cd0LtjleMX50hd7KIf3u1ruMUksX2UwOT4Q0/URmUzXydzjI2EeMy+0Tg8YDtOek7x VCObGT6sCsa91o+FDx2mEh6ei8bjVo0LX+n7IQegl9j8KbXz+L8hVCkMLpTeTm7Du0rE=; Received: from [2605:6000:ec17:200:2247:47ff:fe73:75f] (port=46354 helo=lrosenman-dell.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aWzxR-00076Z-K1 for freebsd-current@freebsd.org; Fri, 19 Feb 2016 23:19:54 -0600 Date: Fri, 19 Feb 2016 23:19:51 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: new computer, strange usb messages at boot Message-ID: <20160220051951.GA47875@lrosenman-dell.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 05:19:55 -0000 Does any of this look weird? What can I provide to help? Dell Inspiron 15 7559 Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 02:07:17 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 2048x1200 CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16396095488 (15636 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 random: unblocking device. ioapic0 irqs 0-119 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80ee1ef0, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 24000000 Hz quality 950 Event timer "HPET" frequency 24000000 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 1.1 on pci0 pci2: on pcib2 vgapci0: port 0xe000-0xe07f mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff,0xd0000000-0xd1ffffff irq 17 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci1: port 0xf000-0xf03f mem 0xdd000000-0xddffffff,0xb0000000-0xbfffffff irq 16 at device 2.0 on pci0 vgapci1: Boot video device xhci0: mem 0xdf410000-0xdf41ffff irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0: waiting for BIOS to give up control usbus0 on xhci0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xdf430000-0xdf431fff,0xdf434000-0xdf4340ff,0xdf433000-0xdf4337ff irq 16 at device 23.0 on pci0 ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahciem0: on ahci0 pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 re0: port 0xd000-0xd0ff mem 0xdf304000-0xdf304fff,0xdf300000-0xdf303fff irq 16 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x50800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 20:47:47:73:07:5f re0: netmap queues/slots: TX 1/256, RX 1/256 pcib5: irq 17 at device 28.5 on pci0 pci5: on pcib5 pci5: at device 0.0 (no driver attached) pcib6: irq 18 at device 28.6 on pci0 pci6: on pcib6 pci6: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xdf428000-0xdf42bfff,0xdf400000-0xdf40ffff irq 16 at device 31.3 on pci0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 acpi_acad0: on acpi0 battery0: on acpi0 orm0: at iomem 0xd0000-0xd0fff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 18 on hdaa0 pcm1: at nid 33 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 3 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number 154595406259 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number S314JB0GA02416 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Sleeping on "acmtx" with the following non-sleepable locks held: exclusive sleep mutex intr sources (intr sources) r = 0 (0xffffffff81c7f630) locked @ /usr/src/sys/x86/x86/intr_machdep.c:549 stack backtrace: #0 0xffffffff80a7f790 at witness_debugger+0x70 #1 0xffffffff80a80aa7 at witness_warn+0x3d7 #2 0xffffffff80a2e26d at _sleep+0x6d #3 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 #4 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a #5 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb #6 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb #7 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 #8 0xffffffff8039ac0d at acpi_GetInteger+0x3d #9 0xffffffff80f94c01 at dmar_find_hpet+0x81 #10 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d #11 0xffffffff80fb2f91 at msi_map+0x171 #12 0xffffffff80e73035 at hpet_remap_intr+0xb5 #13 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 #14 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 #15 0xffffffff809c3a38 at mi_startup+0x108 #16 0xffffffff802fb02c at btext+0x2c lock order reversal: (Giant after non-sleepable) 1st 0xffffffff81c7f630 intr sources (intr sources) @ /usr/src/sys/x86/x86/intr_machdep.c:549 2nd 0xffffffff81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244 stack backtrace: #0 0xffffffff80a7f790 at witness_debugger+0x70 #1 0xffffffff80a7f691 at witness_checkorder+0xTrying to mount root from zfs:zroot/ROOT/default []... e71 #2 0xffffffff80a06f94 at __mtx_lock_flags+0xa4 #3 0xffffffff80a2e5ba at _sleep+0x3ba #4 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 #5 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a #6 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb #7 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb #8 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 #9 0xffffffff8039ac0d at acpi_GetInteger+0x3d #10 0xffffffff80f94c01 at dmar_find_hpet+0x81 #11 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d #12 0xffffffff80fb2f91 at msi_map+0x171 #13 0xffffffff80e73035 at hpet_remap_intr+0xb5 #14 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 #15 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 #16 0xffffffff809c3a38 at mi_startup+0x108 #17 0xffffffff802fb02c at btext+0x2c Timecounter "TSC-low" frequency 1296064094 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus0 uhub0: 24 ports with 24 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 ugen0.3: at usbus0 hid_get_item: Number of items truncated to 255 re0: link state changed to DOWN re0: link state changed to UP uhid0: on usbus0 hid_get_item: Number of items truncated to 255 uhid1: on usbus0 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 From owner-freebsd-current@freebsd.org Sat Feb 20 05:26:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28840AAE7F1 for ; Sat, 20 Feb 2016 05:26:10 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 DAECBAD0 for ; Sat, 20 Feb 2016 05:26:09 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x233.google.com with SMTP id k196so92848312vka.0 for ; Fri, 19 Feb 2016 21:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8cSUcWLTFGJ6DAPNdnkmS5Urpgqea2eu6tmw2YjK5mk=; b=W8CbcT1An8jmHZRopyIZP3AumEo3rDPkQ0/H0PWX3iL4DQbanIgLYoh8ljoi+m2HEU NmxAX2Sx1QTwFZoSUpxpKpWzrsp8dXQcCcbOO0nXJGhsopczFGe3YYv/fK1yIKc0oL1w +EGx9WoEAj3Gr4uI9o4FLd8J8F8KVwGN1p1J+ufBHTKOp48QS8U9F7pDNtzldkcGWOUr djPE6fys1vYOGopZ5JJI+TH5ZEzlwEbX4OVSuiKfFHipn5ghwJc3FkZu/0LUq7Aj1cCZ 96pY/KACHRk1UHaaomrwNZSJ/Zc7vC0SREXRJPsozHk2BR9R5fVn3mBE2s4n+jvcF05W xx8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8cSUcWLTFGJ6DAPNdnkmS5Urpgqea2eu6tmw2YjK5mk=; b=ar8pcf2iucqw9okIcNtqO/L9Kp/h/fc+K7SMS3H2EU3bCQWW3PKMVJiN2x5ulsKvQC JeqALU9McXbyQtFknMri3Go+6oVT3UQ0DxfRXYP/UlL/xNrC06Mhcr0jclHmg/HKhVc5 uPDQ+6OjmB5fI6yYrIoGkoUMd3OeDEgtbjOWp1gsYr245zxAoEjXglXfWS6B0WhqnQke IPT/1QFX/WT0By+ADLxw6LtRHhpaKXsULX8o118SpXr//jkI+KXZX5vSaC/4hzkmyB0Z DU3zvoT3mLyhDYAiPnS3WTRTpB+v88nDRrkPqeq7ZjZxghXJPlSZkXFemy2bLmuZttxA Zmxw== X-Gm-Message-State: AG10YOQ5agpKQh49W3pRb2Bpfa+KvK0HXB9idmQiIDCRMa3JBF6fWTdKLiH945KTm2tACk9b6pBDjp/sYmtKIuOIo9qsyOHmJlQv7L9J6J15F7M72Iw2USJfZA8UpvnQUNWNlw55+PQ0imOt+Tr10DH07+I= MIME-Version: 1.0 X-Received: by 10.31.14.195 with SMTP id 186mr13952439vko.2.1455945968715; Fri, 19 Feb 2016 21:26:08 -0800 (PST) Received: by 10.176.3.161 with HTTP; Fri, 19 Feb 2016 21:26:08 -0800 (PST) In-Reply-To: <2c70336f78b550e1b8964ab21fd9b138@thebighonker.lerctr.org> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> <56C7EAC9.1050908@rcn.com> <2c70336f78b550e1b8964ab21fd9b138@thebighonker.lerctr.org> Date: Fri, 19 Feb 2016 21:26:08 -0800 Message-ID: Subject: Re: Realtek MMC/MMCSD reader? From: "Lundberg, Johannes" To: Larry Rosenman Cc: Gary Corcoran , "freebsd-current@freebsd.org" , "owner-freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 05:26:10 -0000 I'm also newbie and I'm working on adding a sdhci_acpi driver for Intel's Atom SoC. I wonder if your device would work with the existing sdhci_pci driver. Maybe it just a matter of adding the device id and possibly setting some quirks or you might have to write a new driver for the host controller? For me it's a bit tricky because I have to communicate with the card using GPIO before it can be detected. There is a driver in FreeBSD for reading and writing to a mmc so maybe it is just a matter of connecting that to the controller. Searching the Linux source for the device id to see if there is a driver is a good idea. For FreeBSD source check sys/dev/mmc/ sys/dev/sdhci/ There is also a ongoing project to rewrite mmc to use cam. Maybe good idea to check that as well. https://wiki.freebsd.org/SDIO On Friday, February 19, 2016, Larry Rosenman wrote: > On 2016-02-19 22:25, Gary Corcoran wrote: > >> On 2/19/2016 11:08 PM, Larry Rosenman wrote: >> >>> On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: >>> >>>> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman wrote= : >>>> >>>> Great. Since I've never done that.... >>>>> >>>>> Any ideas of anyone that might be able to help? >>>>> >>>>> Or where to even start? >>>>> >>>>> >>>>> >>>>> >>>> >>>> Perhaps >>>> >>>> https://www.nostarch.com/bsddrivers.htm >>>> FreeBSD Device Drivers >>>> >>>> >>>> ? >>>> >>>> >>>> Mehmet Erol Sanliturk >>>> >>>> >>>> perhaps. But I'd need an NDA with RealTek to get the chip specs, and >>> I'm not sure I can do that working for Nokia during the day >>> as I do. >>> >>> I'd love for one of the current folks that do realtek stuff to look. >>> >> Sometimes people look to see if Linux has a driver, and if so, you >> might be able to get enough >> programming info from their driver to be able to write a FreeBSD >> driver, without getting the >> full chip specs. >> >> Gary >> >> > http://askubuntu.com/questions/731093/sd-card-reader-realtek-522a-not-wor= king-in-dell-i7559-in-ubuntu-15-10 > > I'm still VERY much a newbie (like ZERO experience) writing drivers. > > Does anyone want to help? > > I'm more than willing to guinea pig stuff. > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 > _______________________________________________ > 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 -- Name: Johannes Lundberg Position: Mirama project leader Phone: +1-408-636-2161 Skype: brilliantjohannes Online: LinkedIn Facebook Reddit Twitter GitHub GitLab Company: Mirama Brilliantservice US Brilliantservice JP --=20 =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- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@freebsd.org Sat Feb 20 09:23:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52A83AAED17 for ; Sat, 20 Feb 2016 09:23:07 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 1DF9C258 for ; Sat, 20 Feb 2016 09:23:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B65FF1FE023 for ; Sat, 20 Feb 2016 10:23:03 +0100 (CET) Subject: Re: new computer, strange usb messages at boot To: freebsd-current@freebsd.org References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> From: Hans Petter Selasky Message-ID: <56C8310B.4010908@selasky.org> Date: Sat, 20 Feb 2016 10:25:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160220051951.GA47875@lrosenman-dell.lerctr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 09:23:07 -0000 On 02/20/16 06:19, Larry Rosenman wrote: > ugen0.2: at usbus0 > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Hi, Looks like there is an error enumerating one of the USB devices. It is harmless. What does "pciconf -lv" say about your USB controllers? --HPS From owner-freebsd-current@freebsd.org Sat Feb 20 09:44:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5366AADA04; Sat, 20 Feb 2016 09:44:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B3DAE84; Sat, 20 Feb 2016 09:44:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id a4so101185333wme.1; Sat, 20 Feb 2016 01:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=w2poA3ug+exocanap6KGdzVIc1IlsNzkPXCzEPSxDo0=; b=KutTkCUrHuqukIEpGWHT7WU+VgpCSAneBjFYB7ZZn1H4fNbuLNFhY/aZvYaUlWutnc w7teZO2gLMUshmNFuF7dSgcQnW+5vZrSW7hZ4/eyDNJ64tVtLD/icGxgMNJZiDqEXw3g RWno9c31VDKClANL6ideiaNtz+gbYqHZfoJA4i6sq957XyS0PdkykaZf3BA6ieoPh56h 4ZdP35vkKodMKKZHSzqDSCyxXpP+PShSDhnIiQiFvB1J6iDj2PzQAIjyIBSBRtI17fwV mhugj2OV7jJnFjM5zPMiD9jChOn5skoYvIGMx6R8ZbSbRYQ3U4fbsYSvpWGXZvXNwotL EUQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=w2poA3ug+exocanap6KGdzVIc1IlsNzkPXCzEPSxDo0=; b=koo39+RJSUFRRLGoPa7uJwbj7MPSjVrut35+nLgxAuIyICaNy1cRDmCa7QhGX7be/x uEfzNAF8DrZ+lWkAAzq2TiTt7fQZ+iuobDHHN+Itl0MlxRaLCBjVffGhgZWuPrGKHOJh RqZTPDovDFPDK3cIuL6Jih9t07/1A5PI+YHctAD+P7Rj5nDQfBmZTZY0WZF5jTqUnXSR eea4AYKmGtJrk/xiRfMHk0g65ClYT+kNahXDtCAi0gIiJXUx0DrZcSIBCvU1sg4NYISJ qDCC+nyF/LIXaKPt24Twxm+33W4y5fjeGgkKq/A7BZNHXLMK0+9sE1l0KDVEw6EuFll+ BtCg== X-Gm-Message-State: AG10YOSHgsNxz981izLY2poXStdIAhoPsVSwyEwhjePfFoFLBwcxvXPWkRkhuiuj6cKUwQ== X-Received: by 10.194.94.138 with SMTP id dc10mr20628050wjb.37.1455961456657; Sat, 20 Feb 2016 01:44:16 -0800 (PST) Received: from ernst.home (p578E1EFC.dip0.t-ipconnect.de. [87.142.30.252]) by smtp.gmail.com with ESMTPSA id 8sm11321565wmk.13.2016.02.20.01.44.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Feb 2016 01:44:15 -0800 (PST) Date: Sat, 20 Feb 2016 10:44:13 +0100 From: Gary Jennejohn To: Larry Rosenman Cc: Gary Corcoran , freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Realtek MMC/MMCSD reader? Message-ID: <20160220104413.6b6bdd17@ernst.home> In-Reply-To: <2c70336f78b550e1b8964ab21fd9b138@thebighonker.lerctr.org> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> <56C7EAC9.1050908@rcn.com> <2c70336f78b550e1b8964ab21fd9b138@thebighonker.lerctr.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.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.20 Precedence: 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, 20 Feb 2016 09:44:18 -0000 On Fri, 19 Feb 2016 23:02:26 -0600 Larry Rosenman wrote: > On 2016-02-19 22:25, Gary Corcoran wrote: > > On 2/19/2016 11:08 PM, Larry Rosenman wrote: > >> On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: > >>> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman > >>> wrote: > >>> > >>>> Great. Since I've never done that.... > >>>> > >>>> Any ideas of anyone that might be able to help? > >>>> > >>>> Or where to even start? > >>>> > >>>> > >>>> > >>> > >>> > >>> Perhaps > >>> > >>> https://www.nostarch.com/bsddrivers.htm > >>> FreeBSD Device Drivers > >>> > >>> > >>> ? > >>> > >>> > >>> Mehmet Erol Sanliturk > >>> > >>> > >> perhaps. But I'd need an NDA with RealTek to get the chip specs, and > >> I'm not sure I can do that working for Nokia during the day > >> as I do. > >> > >> I'd love for one of the current folks that do realtek stuff to look. > > Sometimes people look to see if Linux has a driver, and if so, you > > might be able to get enough > > programming info from their driver to be able to write a FreeBSD > > driver, without getting the > > full chip specs. > > > > Gary > > > http://askubuntu.com/questions/731093/sd-card-reader-realtek-522a-not-working-in-dell-i7559-in-ubuntu-15-10 > > I'm still VERY much a newbie (like ZERO experience) writing drivers. > > Does anyone want to help? > > I'm more than willing to guinea pig stuff. > Looking at the patch some non-trivial changes were made to the driver. It's hard to tell whether most of them were meant to make the driver more flexible, or whether they were really added to support this device. That said, a number of device-specific commands and at least one new function were added just for this. Whether these changes can easily be implemented in the FBSD code I can't answer without investing more time. There's also the point that any programmer willing to help may need the hardware. Blindly making changes to a driver in the hope they might work isn't exactly good practice. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sat Feb 20 11:13:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3C1DAAE123 for ; Sat, 20 Feb 2016 11:13:48 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2B2112C for ; Sat, 20 Feb 2016 11:13:48 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 2A27A1A6A for ; Sat, 20 Feb 2016 11:13:47 +0000 (UTC) (envelope-from rm@FreeBSD.org) To: FreeBSD Current From: Ruslan Makhmatkhanov Subject: Possible bug in bc(1) Message-ID: <56C848FD.6040502@FreeBSD.org> Date: Sat, 20 Feb 2016 14:07:41 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 11:13:48 -0000 Hello, I'm getting strange result with something looking like valid data: [rm@smsh-zfs ~]> bc 2*1\ 2*1 24 I'd expect the output being like that: 2*1\ 2 2*1 2 What I see in bc(1) man-page regarding to backslash is: "The sequence ‘\’ is ignored within numbers." So looks like it doesn't actually ignored or I missing something? Thanks for clarification. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Sat Feb 20 11:38:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 400BCAAEB40; Sat, 20 Feb 2016 11:38:40 +0000 (UTC) (envelope-from zhao6014@gmail.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 F36811CB0; Sat, 20 Feb 2016 11:38:39 +0000 (UTC) (envelope-from zhao6014@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id u200so86812828ywf.0; Sat, 20 Feb 2016 03:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sepMC0rgYDfl3G3dPyfED69WynM2TsGOXlBu6Yt/+kU=; b=T5hFF0S/CnvB6Qc6j6SY9QG0Hrj4pLR7hCWSCemTKKuRmmggpbpaBpA+l1btxW1dAE 12XGfkt0EZ/JMRGabzx09TFbxgfxRsk62h+ZjPMnCijsM8T7QITy8Y/wvN3aKZ4K2Rgp cSxcMAQvuRjHHQS0srZH1wWjaU9q9S+hmePZdWU1LGUYXj+Y7l5c6471E/RZvKLDmHV6 ORBp+GrEpkMO/hKabBr/LRUg7paTCFHAlkMHS0xzIPENJ88LVfi3RMdWiCb9wHOUX12o KOxMSRI8oyKTX5uVinh+8rhg+3qd302ID9AELKvcyEYTJoHGVrmSGsmpsu5M61ARS8mn gfaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sepMC0rgYDfl3G3dPyfED69WynM2TsGOXlBu6Yt/+kU=; b=KmyXqtBus8BintdBYHkXxq7BCF390CougqzSOsm0R5mj/DgNC+feDCDArj6YWVQQi5 Dohj9NnS475q7fmrX9kDCM+3FiQ0hp5uCgL4heWMZWGKyehYvN7vVgZONpWvzrW0rhKv 4te/kTuYJbgsL5w1AmrNOFw+96pFTH4tKPQtPfgo/MsToUhiprFG7HImDHhEtShw4Dud 6sZ/5rWaGsHGvt7B5vuZUAjyIU6qumMcfL3nCoBjB5PdiOR6wUltF8aPe66uTayAi6+S l0vi5HNPf5QhS137Pa7ED0x1dee6kWm0knTUVif+RoQtnBMp4UbcgWANl+ahe668O1u4 dlBg== X-Gm-Message-State: AG10YOTlgCBIjCuNppGOdwNQ4sGMe0FYABxzQEU7OBFKzk+mwrCZ5TLQwxXUUPr0176xWB6UE0zFC5IH0udVkQ== MIME-Version: 1.0 X-Received: by 10.129.91.132 with SMTP id p126mr9404288ywb.188.1455968319204; Sat, 20 Feb 2016 03:38:39 -0800 (PST) Received: by 10.37.79.6 with HTTP; Sat, 20 Feb 2016 03:38:39 -0800 (PST) Received: by 10.37.79.6 with HTTP; Sat, 20 Feb 2016 03:38:39 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 19:38:39 +0800 Message-ID: Subject: Re: [Bug 207366] openssh do not generate dsa host key by default From: Jov To: freebsd-current Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 11:38:40 -0000 fyi 2016=E5=B9=B42=E6=9C=8820=E6=97=A5 7:13 PM=EF=BC=8C =E5=86=99=E9=81=93=EF=BC=9A > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207366 > > Bug ID: 207366 > Summary: openssh do not generate dsa host key by default > Product: Base System > Version: 11.0-CURRENT > Hardware: arm > OS: Any > Status: New > Severity: Affects Some People > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: amutu@amutu.com > > /var/log/message error: > sshd[779]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key > > root@rpi-b:~/.ssh # uname -a > FreeBSD rpi-b 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 > 10:21:45 > UTC 2016 root@releng2.nyi.freebsd.org: > /usr/obj/arm.armv6/usr/src/sys/RPI-B > arm > root@rpi-b:~/.ssh # ssh -V > OpenSSH_7.1p2, OpenSSL 1.0.2f-freebsd 28 Jan 2016 > > r294912 do not have this problem,ant the openssh version is 1.0.2e: > root@fbpi2:~ # uname -a > FreeBSD pi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294912: Thu Jan 28 > 02:05:30 > UTC 2016 root@releng2.nyi.freebsd.org: > /usr/obj/arm.armv6/usr/src/sys/RPI2 > arm > root@pi2:~ # ssh -V > OpenSSH_7.1p2, OpenSSL 1.0.2e-freebsd 3 Dec 2015 > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sat Feb 20 11:45:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53C73AAEEC7 for ; Sat, 20 Feb 2016 11:45:08 +0000 (UTC) (envelope-from wolfgang@heldvonkosmos.de) Received: from v22015082968727213.yourvserver.net (v22015082968727213.yourvserver.net [37.120.168.72]) (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 1D9F5188 for ; Sat, 20 Feb 2016 11:45:07 +0000 (UTC) (envelope-from wolfgang@heldvonkosmos.de) Received: from v22015082968727213.yourvserver.net (unknown [127.0.0.1]) by v22015082968727213.yourvserver.net (Postfix) with ESMTP id AF5FF3C869 for ; Sat, 20 Feb 2016 12:45:04 +0100 (CET) X-Virus-Scanned: amavisd-new at v22015082968727213.yourvserver.net Received: from v22015082968727213.yourvserver.net ([127.0.0.1]) by v22015082968727213.yourvserver.net (v22015082968727213.yourvserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaLEBkIJcq5q for ; Sat, 20 Feb 2016 12:45:03 +0100 (CET) Received: from [192.168.42.103] (aftr-109-91-36-47.unity-media.net [109.91.36.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: wolfgang@heldvonkosmos.de) by v22015082968727213.yourvserver.net (Postfix) with ESMTPSA id 358613C863 for ; Sat, 20 Feb 2016 12:45:03 +0100 (CET) Subject: Re: Possible bug in bc(1) To: freebsd-current@freebsd.org References: <56C848FD.6040502@FreeBSD.org> From: Wolfgang Petzold Message-ID: <56C851C5.9040405@heldvonkosmos.de> Date: Sat, 20 Feb 2016 12:45:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C848FD.6040502@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 11:45:08 -0000 Hi, actually, if you "ignore \ within numbers", your input reads 2*12*1, doesn't it? W. Am 20.02.2016 um 12:07 schrieb Ruslan Makhmatkhanov: > Hello, > > I'm getting strange result with something looking like valid data: > > [rm@smsh-zfs ~]> bc > 2*1\ > 2*1 > 24 > > I'd expect the output being like that: > 2*1\ > 2 > 2*1 > 2 > > What I see in bc(1) man-page regarding to backslash is: > "The sequence ‘\’ is ignored within numbers." > > So looks like it doesn't actually ignored or I missing something? > > Thanks for clarification. > From owner-freebsd-current@freebsd.org Sat Feb 20 12:04:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AE0FAAFD76 for ; Sat, 20 Feb 2016 12:04:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 253E21111 for ; Sat, 20 Feb 2016 12:04:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1KC41rU042020 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 20 Feb 2016 14:04:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1KC41rU042020 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1KC4129042019 for freebsd-current@freebsd.org; Sat, 20 Feb 2016 14:04:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Feb 2016 14:04:01 +0200 From: Konstantin Belousov To: freebsd-current@freebsd.org Subject: Re: new computer, strange usb messages at boot Message-ID: <20160220120401.GA91220@kib.kiev.ua> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160220051951.GA47875@lrosenman-dell.lerctr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 12:04:07 -0000 On Fri, Feb 19, 2016 at 11:19:51PM -0600, Larry Rosenman wrote: > Does any of this look weird? What can I provide to help? > Sleeping on "acmtx" with the following non-sleepable locks held: > exclusive sleep mutex intr sources (intr sources) r = 0 (0xffffffff81c7f630) locked @ /usr/src/sys/x86/x86/intr_machdep.c:549 > stack backtrace: > #0 0xffffffff80a7f790 at witness_debugger+0x70 > #1 0xffffffff80a80aa7 at witness_warn+0x3d7 > #2 0xffffffff80a2e26d at _sleep+0x6d > #3 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 > #4 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a > #5 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb > #6 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb > #7 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 > #8 0xffffffff8039ac0d at acpi_GetInteger+0x3d > #9 0xffffffff80f94c01 at dmar_find_hpet+0x81 > #10 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d > #11 0xffffffff80fb2f91 at msi_map+0x171 > #12 0xffffffff80e73035 at hpet_remap_intr+0xb5 > #13 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 > #14 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 > #15 0xffffffff809c3a38 at mi_startup+0x108 > #16 0xffffffff802fb02c at btext+0x2c > lock order reversal: (Giant after non-sleepable) > 1st 0xffffffff81c7f630 intr sources (intr sources) @ /usr/src/sys/x86/x86/intr_machdep.c:549 > 2nd 0xffffffff81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244 > stack backtrace: > #0 0xffffffff80a7f790 at witness_debugger+0x70 > #1 0xffffffff80a7f691 at witness_checkorder+0xTrying to mount root from zfs:zroot/ROOT/default []... > e71 > #2 0xffffffff80a06f94 at __mtx_lock_flags+0xa4 > #3 0xffffffff80a2e5ba at _sleep+0x3ba > #4 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 > #5 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a > #6 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb > #7 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb > #8 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 > #9 0xffffffff8039ac0d at acpi_GetInteger+0x3d > #10 0xffffffff80f94c01 at dmar_find_hpet+0x81 > #11 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d > #12 0xffffffff80fb2f91 at msi_map+0x171 > #13 0xffffffff80e73035 at hpet_remap_intr+0xb5 > #14 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 > #15 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 > #16 0xffffffff809c3a38 at mi_startup+0x108 > #17 0xffffffff802fb02c at btext+0x2c For these two LORs, please try the following patch. Apparently acpi_GetInteger() might get acpi lock. Patch also modernizes /dev/hpet creation. Just patch and boot, the LOR messages should go away as the only change in behaviour. diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c index 1b5a161..76fbd5a 100644 --- a/sys/dev/acpica/acpi_hpet.c +++ b/sys/dev/acpica/acpi_hpet.c @@ -85,6 +85,7 @@ struct hpet_softc { struct resource *intr_res; void *intr_handle; ACPI_HANDLE handle; + uint32_t acpi_uid; uint64_t freq; uint32_t caps; struct timecounter tc; @@ -295,6 +296,15 @@ hpet_intr(void *arg) return (FILTER_STRAY); } +uint32_t +hpet_get_uid(device_t dev) +{ + struct hpet_softc *sc; + + sc = device_get_softc(dev); + return (sc->acpi_uid); +} + static ACPI_STATUS hpet_find(ACPI_HANDLE handle, UINT32 level, void *context, void **status) @@ -422,8 +432,9 @@ hpet_attach(device_t dev) { struct hpet_softc *sc; struct hpet_timer *t; + struct make_dev_args mda; int i, j, num_msi, num_timers, num_percpu_et, num_percpu_t, cur_cpu; - int pcpu_master; + int pcpu_master, error; static int maxhpetet = 0; uint32_t val, val2, cvectors, dvectors; uint16_t vendor, rev; @@ -745,11 +756,16 @@ hpet_attach(device_t dev) maxhpetet++; } } - - sc->pdev = make_dev(&hpet_cdevsw, 0, UID_ROOT, GID_WHEEL, - 0600, "hpet%d", device_get_unit(dev)); - if (sc->pdev) { - sc->pdev->si_drv1 = sc; + acpi_GetInteger(sc->handle, "_UID", &sc->acpi_uid); + + make_dev_args_init(&mda); + mda.mda_devsw = &hpet_cdevsw; + mda.mda_uid = UID_ROOT; + mda.mda_gid = GID_WHEEL; + mda.mda_mode = 0600; + mda.mda_si_drv1 = sc; + error = make_dev_s(&mda, &sc->pdev, "hpet%d", device_get_unit(dev)); + if (error == 0) { sc->mmap_allow = 1; TUNABLE_INT_FETCH("hw.acpi.hpet.mmap_allow", &sc->mmap_allow); @@ -766,9 +782,10 @@ hpet_attach(device_t dev) OID_AUTO, "mmap_allow_write", CTLFLAG_RW, &sc->mmap_allow_write, 0, "Allow userland write to the HPET register space"); - } else - device_printf(dev, "could not create /dev/hpet%d\n", - device_get_unit(dev)); + } else { + device_printf(dev, "could not create /dev/hpet%d, error %d\n", + device_get_unit(dev), error); + } return (0); } diff --git a/sys/dev/acpica/acpivar.h b/sys/dev/acpica/acpivar.h index 4f601c9..4df83d5 100644 --- a/sys/dev/acpica/acpivar.h +++ b/sys/dev/acpica/acpivar.h @@ -441,6 +441,8 @@ int acpi_wakeup_machdep(struct acpi_softc *sc, int state, int acpi_table_quirks(int *quirks); int acpi_machdep_quirks(int *quirks); +uint32_t hpet_get_uid(device_t dev); + /* Battery Abstraction. */ struct acpi_battinfo; diff --git a/sys/x86/iommu/intel_drv.c b/sys/x86/iommu/intel_drv.c index 47588af..d2197ff 100644 --- a/sys/x86/iommu/intel_drv.c +++ b/sys/x86/iommu/intel_drv.c @@ -826,13 +826,9 @@ dmar_find_nonpci(u_int id, u_int entry_type, uint16_t *rid) struct dmar_unit * dmar_find_hpet(device_t dev, uint16_t *rid) { - ACPI_HANDLE handle; - uint32_t hpet_id; - handle = acpi_get_handle(dev); - if (ACPI_FAILURE(acpi_GetInteger(handle, "_UID", &hpet_id))) - return (NULL); - return (dmar_find_nonpci(hpet_id, ACPI_DMAR_SCOPE_TYPE_HPET, rid)); + return (dmar_find_nonpci(hpet_get_uid(dev), ACPI_DMAR_SCOPE_TYPE_HPET, + rid)); } struct dmar_unit * From owner-freebsd-current@freebsd.org Sat Feb 20 12:08:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50EFBAAFEF6 for ; Sat, 20 Feb 2016 12:08:41 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F73B127E for ; Sat, 20 Feb 2016 12:08:41 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date; bh=pj2yWOcpa79zw3rdyLsP15fwQffSyuprGHyZDbptL/c=; b=Zgu2 XnXwiX3CZbiDZIDZm33gNIDTM2UxD30TExbtTTVgUikK4ScTucYhPr8vUVJG29c9Q3sKce/BzNfWs UPTK9nQvrBix83p4RhiY63odAxw0rm49upFQ4zssqu9GNCBY6/M+1y0lwogP7GKbp8w7PLarPoLCt xG7ViZhPg7DQ8=; Received: from [2605:6000:ec17:200:2247:47ff:fe73:75f] (port=53735 helo=lrosenman-dell.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aX6L2-000HHC-4W for freebsd-current@freebsd.org; Sat, 20 Feb 2016 06:08:40 -0600 Date: Sat, 20 Feb 2016 06:08:38 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: new computer, strange usb messages at boot Message-ID: <20160220120838.GA76920@lrosenman-dell.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <56C8310B.4010908@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C8310B.4010908@selasky.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 12:08:41 -0000 On Sat, Feb 20, 2016 at 10:25:31AM +0100, Hans Petter Selasky wrote: > On 02/20/16 06:19, Larry Rosenman wrote: > > ugen0.2: at usbus0 > > Root mount waiting for: usbus0 > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > > Root mount waiting for: usbus0 > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > > Root mount waiting for: usbus0 > > Root mount waiting for: usbus0 > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > > Root mount waiting for: usbus0 > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > > Root mount waiting for: usbus0 > > Root mount waiting for: usbus0 > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR > > Hi, > > Looks like there is an error enumerating one of the USB devices. It is > harmless. > > What does "pciconf -lv" say about your USB controllers? > > --HPS Here is the full pciconf -lv: hostb0@pci0:0:0:0: class=0x060000 card=0x07061028 chip=0x19108086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sky Lake Host Bridge/DRAM Registers' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x20158086 chip=0x19018086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sky Lake PCIe Controller (x16)' class = bridge subclass = PCI-PCI pcib2@pci0:0:1:1: class=0x060400 card=0x07061028 chip=0x19058086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sky Lake PCIe Controller (x8)' class = bridge subclass = PCI-PCI vgapci1@pci0:0:2:0: class=0x030000 card=0x07061028 chip=0x191b8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA none0@pci0:0:4:0: class=0x118000 card=0x07061028 chip=0x19038086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' class = dasp xhci0@pci0:0:20:0: class=0x0c0330 card=0x07061028 chip=0xa12f8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H USB 3.0 xHCI Controller' class = serial bus subclass = USB none1@pci0:0:20:2: class=0x118000 card=0x07061028 chip=0xa1318086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H Thermal subsystem' class = dasp none2@pci0:0:21:0: class=0x118000 card=0x07061028 chip=0xa1608086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H LPSS I2C Controller' class = dasp none3@pci0:0:22:0: class=0x078000 card=0x07061028 chip=0xa13a8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H CSME HECI' class = simple comms ahci0@pci0:0:23:0: class=0x010601 card=0x07061028 chip=0xa1038086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H SATA Controller [AHCI mode]' class = mass storage subclass = SATA pcib3@pci0:0:28:0: class=0x060400 card=0x07061028 chip=0xa1108086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:4: class=0x060400 card=0x07061028 chip=0xa1148086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:5: class=0x060400 card=0x07061028 chip=0xa1158086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:6: class=0x060400 card=0x07061028 chip=0xa1168086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x07061028 chip=0xa14e8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H LPC Controller' class = bridge subclass = PCI-ISA none4@pci0:0:31:2: class=0x058000 card=0x07061028 chip=0xa1218086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H PMC' class = memory hdac0@pci0:0:31:3: class=0x040300 card=0x07061028 chip=0xa1708086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H HD Audio' class = multimedia subclass = HDA none5@pci0:0:31:4: class=0x0c0500 card=0x07061028 chip=0xa1238086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H SMBus' class = serial bus subclass = SMBus vgapci0@pci0:2:0:0: class=0x030200 card=0x07061028 chip=0x139b10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GM107M [GeForce GTX 960M]' class = display subclass = 3D re0@pci0:4:0:0: class=0x020000 card=0x07061028 chip=0x816810ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet none6@pci0:5:0:0: class=0x028000 card=0x44108086 chip=0x31658086 rev=0x79 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 3165' class = network none7@pci0:6:0:0: class=0xff0000 card=0x522a10ec chip=0x522a10ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 12:24:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 299E4AAD74F for ; Sat, 20 Feb 2016 12:24:25 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD731C99 for ; Sat, 20 Feb 2016 12:24:25 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date; bh=FQhRPI0IOfEn/GParoQosYa/hCuV7Q4YZxk6teepq0s=; b=hD1t /pGCYTVHQ0lZjZ2bM0z81q+6DlFnjKwt8v7OR68kBAHh74Xhcaj+N+ufUqLDP4GBnotgcWpuxnjGT OF8H1T3acIQHhxzCObAb5GsBWHu/B5IPWv31lV03tffyVb7lNN84ookryFu1M26VyDIw54NuEOeNi G3PMcKPgcouLM=; Received: from [2605:6000:ec17:200:2247:47ff:fe73:75f] (port=60078 helo=lrosenman-dell.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aX6aG-000Hg2-5M for freebsd-current@freebsd.org; Sat, 20 Feb 2016 06:24:24 -0600 Date: Sat, 20 Feb 2016 06:24:16 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: new computer, strange usb messages at boot Message-ID: <20160220122416.GA1026@lrosenman-dell.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160220120401.GA91220@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 12:24:25 -0000 On Sat, Feb 20, 2016 at 02:04:01PM +0200, Konstantin Belousov wrote: > On Fri, Feb 19, 2016 at 11:19:51PM -0600, Larry Rosenman wrote: > > Does any of this look weird? What can I provide to help? > > > Sleeping on "acmtx" with the following non-sleepable locks held: > > exclusive sleep mutex intr sources (intr sources) r = 0 (0xffffffff81c7f630) locked @ /usr/src/sys/x86/x86/intr_machdep.c:549 > > stack backtrace: > > #0 0xffffffff80a7f790 at witness_debugger+0x70 > > #1 0xffffffff80a80aa7 at witness_warn+0x3d7 > > #2 0xffffffff80a2e26d at _sleep+0x6d > > #3 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 > > #4 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a > > #5 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb > > #6 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb > > #7 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 > > #8 0xffffffff8039ac0d at acpi_GetInteger+0x3d > > #9 0xffffffff80f94c01 at dmar_find_hpet+0x81 > > #10 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d > > #11 0xffffffff80fb2f91 at msi_map+0x171 > > #12 0xffffffff80e73035 at hpet_remap_intr+0xb5 > > #13 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 > > #14 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 > > #15 0xffffffff809c3a38 at mi_startup+0x108 > > #16 0xffffffff802fb02c at btext+0x2c > > lock order reversal: (Giant after non-sleepable) > > 1st 0xffffffff81c7f630 intr sources (intr sources) @ /usr/src/sys/x86/x86/intr_machdep.c:549 > > 2nd 0xffffffff81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244 > > stack backtrace: > > #0 0xffffffff80a7f790 at witness_debugger+0x70 > > #1 0xffffffff80a7f691 at witness_checkorder+0xTrying to mount root from zfs:zroot/ROOT/default []... > > e71 > > #2 0xffffffff80a06f94 at __mtx_lock_flags+0xa4 > > #3 0xffffffff80a2e5ba at _sleep+0x3ba > > #4 0xffffffff80399ff8 at AcpiOsAcquireMutex+0xc8 > > #5 0xffffffff8036891a at AcpiUtAcquireMutex+0x3a > > #6 0xffffffff80355f2b at AcpiExEnterInterpreter+0xb > > #7 0xffffffff8035a2fb at AcpiNsEvaluate+0x1cb > > #8 0xffffffff8035d7b4 at AcpiEvaluateObject+0x174 > > #9 0xffffffff8039ac0d at acpi_GetInteger+0x3d > > #10 0xffffffff80f94c01 at dmar_find_hpet+0x81 > > #11 0xffffffff80f9d54d at iommu_map_msi_intr+0x2d > > #12 0xffffffff80fb2f91 at msi_map+0x171 > > #13 0xffffffff80e73035 at hpet_remap_intr+0xb5 > > #14 0xffffffff80fb2627 at msi_assign_cpu+0x1c7 > > #15 0xffffffff80fa9733 at intr_shuffle_irqs+0x73 > > #16 0xffffffff809c3a38 at mi_startup+0x108 > > #17 0xffffffff802fb02c at btext+0x2c > > For these two LORs, please try the following patch. Apparently > acpi_GetInteger() might get acpi lock. Patch also modernizes /dev/hpet > creation. > > Just patch and boot, the LOR messages should go away as the only change > in behaviour. Applied, and it does seem to fix the LOR: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r295833M: Sat Feb 20 06:13:34 CST 2016 root@lrosenman-dell:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 2048x1200 CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16396095488 (15636 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 random: unblocking device. ioapic0 irqs 0-119 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80ee1ea0, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 24000000 Hz quality 950 Event timer "HPET" frequency 24000000 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 1.1 on pci0 pci2: on pcib2 vgapci0: port 0xe000-0xe07f mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff,0xd0000000-0xd1ffffff irq 17 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci1: port 0xf000-0xf03f mem 0xdd000000-0xddffffff,0xb0000000-0xbfffffff irq 16 at device 2.0 on pci0 vgapci1: Boot video device xhci0: mem 0xdf410000-0xdf41ffff irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0: waiting for BIOS to give up control usbus0 on xhci0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xdf430000-0xdf431fff,0xdf434000-0xdf4340ff,0xdf433000-0xdf4337ff irq 16 at device 23.0 on pci0 ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahciem0: on ahci0 pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 re0: port 0xd000-0xd0ff mem 0xdf304000-0xdf304fff,0xdf300000-0xdf303fff irq 16 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x50800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 20:47:47:73:07:5f re0: netmap queues/slots: TX 1/256, RX 1/256 pcib5: irq 17 at device 28.5 on pci0 pci5: on pcib5 pci5: at device 0.0 (no driver attached) pcib6: irq 18 at device 28.6 on pci0 pci6: on pcib6 pci6: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xdf428000-0xdf42bfff,0xdf400000-0xdf40ffff irq 16 at device 31.3 on pci0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 acpi_acad0: on acpi0 battery0: on acpi0 orm0: at iomem 0xd0000-0xd0fff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 18 on hdaa0 pcm1: at nid 33 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 3 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number 154595406259 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number S314JB0GA02416 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! Timecounter "TSC-low" frequency 1296064060 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 24 ports with 24 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 ugen0.3: at usbus0 hid_get_item: Number of items truncated to 255 re0: link state changed to DOWN re0: link state changed to UP uhid0: on usbus0 hid_get_item: Number of items truncated to 255 uhid1: on usbus0 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 12:48:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BACF3AAE232 for ; Sat, 20 Feb 2016 12:48:02 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC56AF5 for ; Sat, 20 Feb 2016 12:48:02 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=UszteKBugJBvrDdMCX8Ji/Snzsjd7hoazRSO9Wp9xII=; b=Mys9AZxcAnTFUnhjtfjWrYK5+oCmuwmO8l1OeDSL1QLMm4+dpuC+H+cLFNJWRwcosNFkHAHC71 IoC04mHMgRtHx6dqHvnX8VGQgCFPK9+UK1hvMOmsfPHvi/8UxcJT3fjFKGfJxara4vesJZ1d2YCUg rTE6aIDDJO0rWamClrBs=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:54899 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aX6x7-000ILL-Pj for freebsd-current@freebsd.org; Sat, 20 Feb 2016 06:48:01 -0600 Received: from 2605:6000:ec17:200:20a8:2140:b873:6ca9 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 20 Feb 2016 06:48:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 20 Feb 2016 06:48:01 -0600 From: Larry Rosenman To: Freebsd current Subject: LOR: ZFS/syncer: on mount of msdosfs Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 12:48:02 -0000 Is this a known LOR: lock order reversal: 1st 0xfffff801d20ea5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff801d2fe6418 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2618 stack backtrace: #0 0xffffffff80a7f810 at witness_debugger+0x70 #1 0xffffffff80a7f711 at witness_checkorder+0xe71 #2 0xffffffff809fe5cb at __lockmgr_args+0xd3b #3 0xffffffff80ac525c at vop_stdlock+0x3c #4 0xffffffff80fbd640 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae5f2a at _vn_lock+0x9a #6 0xffffffff80ad6c38 at vputx+0x208 #7 0xffffffff80aceaf0 at dounmount+0x410 #8 0xffffffff80ace64d at sys_unmount+0x35d #9 0xffffffff80e6e15b at amd64_syscall+0x2db #10 0xffffffff80e4dd4b at Xfast_syscall+0xfb lock order reversal: 1st 0xfffff801d20ea5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff801d2fe65f0 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994 stack backtrace: #0 0xffffffff80a7f810 at witness_debugger+0x70 #1 0xffffffff80a7f711 at witness_checkorder+0xe71 #2 0xffffffff809fe5cb at __lockmgr_args+0xd3b #3 0xffffffff80ac525c at vop_stdlock+0x3c #4 0xffffffff80fbd640 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae5f2a at _vn_lock+0x9a #6 0xffffffff809075a3 at msdosfs_sync+0x193 #7 0xffffffff80acebc9 at dounmount+0x4e9 #8 0xffffffff80ace64d at sys_unmount+0x35d #9 0xffffffff80e6e15b at amd64_syscall+0x2db #10 0xffffffff80e4dd4b at Xfast_syscall+0xfb $ uname -a FreeBSD lrosenman-dell 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r295833M: Sat Feb 20 06:13:34 CST 2016 root@lrosenman-dell:/usr/obj/usr/src/sys/GENERIC amd64 $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 12:49:34 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC801AAE316 for ; Sat, 20 Feb 2016 12:49:34 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F3B2C38 for ; Sat, 20 Feb 2016 12:49:34 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=qciBEqWVSCnwedv6uaWncfi+NIwWS76gNoVXP3AXgjw=; b=WLypbx/L98DwEZfhGz6pAnf4KYlTy5Dhv8uwvxc8fjbDAoNvu9tNGFdzAqg6Xj99n5fYCZhu6i Pv8LxGKoTxFoxSAtvKE2VzUag2jXl80Bt1yRVhwgvIvfOuPgcPwnXU8par/ixwk0tCCYb9JbMu6Bk //WtJ17ZtEnKpcSf6qK8=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:51658 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aX6yb-000IO7-Qu for freebsd-current@freebsd.org; Sat, 20 Feb 2016 06:49:34 -0600 Received: from 2605:6000:ec17:200:20a8:2140:b873:6ca9 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 20 Feb 2016 06:49:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 20 Feb 2016 06:49:33 -0600 From: Larry Rosenman To: Freebsd current Subject: HWPMC on SkyLake Message-ID: <9cd19cb076765fe841e273de1df4772d@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 12:49:34 -0000 Is there anything I can do to help: hwpc_core: unknown PMC architecture: 4 hwpmc: SOFT/16/64/0x67 CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sat Feb 20 14:48:45 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A447CAAF30F for ; Sat, 20 Feb 2016 14:48:45 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AB747F5 for ; Sat, 20 Feb 2016 14:48:43 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id u1KEm0QB003765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Feb 2016 22:48:01 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id u1KEm0g8003764; Sat, 20 Feb 2016 22:48:00 +0800 (CST) (envelope-from kevlo) Date: Sat, 20 Feb 2016 22:47:59 +0800 From: Kevin Lo To: Gary Corcoran Cc: freebsd-current@freebsd.org Subject: Re: Realtek MMC/MMCSD reader? Message-ID: <20160220144759.GA3753@ns.kevlo.org> References: <20160220033215.GB988@lrosenman-dell.lerctr.org> <20160220035821.GA57181@lrosenman-dell.lerctr.org> <56C7EAC9.1050908@rcn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C7EAC9.1050908@rcn.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 14:48:45 -0000 On Fri, Feb 19, 2016 at 11:25:45PM -0500, Gary Corcoran wrote: > > On 2/19/2016 11:08 PM, Larry Rosenman wrote: > > On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote: > >> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman wrote: > >> > >>> Great. Since I've never done that.... > >>> > >>> Any ideas of anyone that might be able to help? > >>> > >>> Or where to even start? > >>> > >>> > >>> > >> > >> > >> Perhaps > >> > >> https://www.nostarch.com/bsddrivers.htm > >> FreeBSD Device Drivers > >> > >> > >> ? > >> > >> > >> Mehmet Erol Sanliturk > >> > >> > > perhaps. But I'd need an NDA with RealTek to get the chip specs, and I'm not sure I can do that working for Nokia during the day > > as I do. > > > > I'd love for one of the current folks that do realtek stuff to look. > Sometimes people look to see if Linux has a driver, and if so, you might be able to get enough > programming info from their driver to be able to write a FreeBSD driver, without getting the > full chip specs. Or do a port of the OpenBSD's rtsx(4). > Gary Kevin From owner-freebsd-current@freebsd.org Sat Feb 20 19:57:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EAFFAAEDBC; Sat, 20 Feb 2016 19:57:37 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39410160B; Sat, 20 Feb 2016 19:57:37 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id k196so102077395vka.0; Sat, 20 Feb 2016 11:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2Z9JxVpdJh+332GZx+OuFz0ZFwFyWmg2E5rlnVa6YNA=; b=mXg0/8hDQ6D3i/MUMRKqUcZEXpk2rhcXM+X+7CdiFubmKT0uvLMJa/Tb6MtIVwglk/ fMI57trkYKUxeSzavNOy5Axsb1igXhHzjMmG7+HMyvOO19sGWufjVY4NT9L0GB2a7wnw d45XE9+omoYYsfEtRK4Tb1dlRL8G6ORVKV3s0xu+JPsplGtSxnO0Ux561TqMgS8UEe3p 9+cXVJMzv0twnahhBzqNvcUa8VRAdW/WfdEIJsOOR+czvLWYAP3faXhvXY80WkKeI4lt ywphkeXJedDOVssvSFrnHwr3v+/OJXyp2MgPyTnCh4qtC+5Da88TuFJBe0GA5Yel+Xu8 8X8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2Z9JxVpdJh+332GZx+OuFz0ZFwFyWmg2E5rlnVa6YNA=; b=S87WVEHkrOkAZBWdvkSqh+TJrZ9W3oNBeL5pt+kjhlAlG93KynrJektMIu4FSSyWN5 p66VUYtY+mFtTfZZq5URH/LyO71Uup+zuCz8Bugqzk98GzLCY2dY/qLdx3RMwNerQK5O NgeqQ2rXGwCc7atoNK5OMiBRoGzTFwbEEnO1aCE/uEb/+9lKCs1rysKrH15ptg2DOr6k MU6sIBwDOHE/Pb6L5LoR3TyoArTw9UohqqgbdiKJJ0c2tyJH2ngUMwMUxgOBw/AaJra5 M35tNLoiGn6UzQgc75q5S7EmNK86vEZVtGDNqXx+458ulskrk51YD1QZWlx+0egbHINI kaVQ== X-Gm-Message-State: AG10YOQeJadlO4DctM1CshgWsz4E4pBKaRyLx9iO54xtqMJ0NGOzZbu26djYPqguyh2Aw5HnH0XcpwxTn8LVQg== MIME-Version: 1.0 X-Received: by 10.31.34.67 with SMTP id i64mr7873202vki.140.1455998256155; Sat, 20 Feb 2016 11:57:36 -0800 (PST) Received: by 10.31.194.194 with HTTP; Sat, 20 Feb 2016 11:57:36 -0800 (PST) Date: Sat, 20 Feb 2016 14:57:36 -0500 Message-ID: Subject: sr-iov issues, reset_hw() failed with error -100 From: Ultima To: freebsd-current@freebsd.org, freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 20 Feb 2016 19:57:37 -0000 Decided to do some testing with iovctl to see how sr-iov is coming along. Currently when adding the vf's there are a couple errors, and the network no longer function after iovctl is started. My guess is the reset_hw() call that is failing. Any ideas why this call would fail? I tested this on both ports, ix1 is detached and unused for this test, however inserting a cable results in an unusable port. iovctl -Dd ix1 removes the vf's, however functionality is still not restored without a system restart. FreeBSD S1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295736: Wed Feb 17 21:17:28 EST 2016 root@S1:/usr/obj/usr/src/sys/MYKERNEL amd64 /boot/loader.conf hw.ix.num_queues="4" /etc/iovctl.conf PF { device : ix1; num_vfs : 31; } DEFAULT { passthrough : true; } VF-0 { passthrough : false; } VF-1 { passthrough : false; } # iovctl -C -f /etc/iovctl.conf dmesg ixv0: at device 0.129 on pci12 ixv0: Using MSIX interrupts with 2 vectors ixv0: ixgbe_reset_hw() failed with error -100 device_attach: ixv0 attach returned 5 ixv0: at device 0.131 on pci12 ixv0: Using MSIX interrupts with 2 vectors ixv0: ixgbe_reset_hw() failed with error -100 device_attach: ixv0 attach returned 5 pci12: at device 0.133 (no driver attached) pci12: at device 0.135 (no driver attached) pci12: at device 0.137 (no driver attached) pci12: at device 0.139 (no driver attached) pci12: at device 0.141 (no driver attached) pci12: at device 0.143 (no driver attached) pci12: at device 0.145 (no driver attached) pci12: at device 0.147 (no driver attached) pci12: at device 0.149 (no driver attached) pci12: at device 0.151 (no driver attached) pci12: at device 0.153 (no driver attached) pci12: at device 0.155 (no driver attached) pci12: at device 0.157 (no driver attached) pci12: at device 0.159 (no driver attached) pci12: at device 0.161 (no driver attached) pci12: at device 0.163 (no driver attached) pci12: at device 0.165 (no driver attached) pci12: at device 0.167 (no driver attached) pci12: at device 0.169 (no driver attached) pci12: at device 0.171 (no driver attached) pci12: at device 0.173 (no driver attached) pci12: at device 0.175 (no driver attached) pci12: at device 0.177 (no driver attached) pci12: at device 0.179 (no driver attached) pci12: at device 0.181 (no driver attached) pci12: at device 0.183 (no driver attached) pci12: at device 0.185 (no driver attached) pci12: at device 0.187 (no driver attached) pci12: at device 0.189 (no driver attached) pciconf -lv ix1@pci0:129:0:1: class=0x020000 card=0x00001458 chip=0x15288086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Controller 10-Gigabit X540-AT2' class = network subclass = ethernet none155@pci0:129:0:129: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet none156@pci0:129:0:131: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt0@pci0:129:0:133: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt1@pci0:129:0:135: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt2@pci0:129:0:137: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt3@pci0:129:0:139: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt4@pci0:129:0:141: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt5@pci0:129:0:143: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt6@pci0:129:0:145: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt7@pci0:129:0:147: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt8@pci0:129:0:149: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt9@pci0:129:0:151: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt10@pci0:129:0:153: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt11@pci0:129:0:155: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt12@pci0:129:0:157: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt13@pci0:129:0:159: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt14@pci0:129:0:161: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt15@pci0:129:0:163: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt16@pci0:129:0:165: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt17@pci0:129:0:167: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt18@pci0:129:0:169: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt19@pci0:129:0:171: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt20@pci0:129:0:173: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt21@pci0:129:0:175: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt22@pci0:129:0:177: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt23@pci0:129:0:179: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt24@pci0:129:0:181: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt25@pci0:129:0:183: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt26@pci0:129:0:185: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt27@pci0:129:0:187: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet ppt28@pci0:129:0:189: class=0x020000 card=0x00001458 chip=0x15158086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'X540 Ethernet Controller Virtual Function' class = network subclass = ethernet Ultima