From owner-freebsd-hackers@freebsd.org Sun Mar 12 20:54:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D038D09842 for ; Sun, 12 Mar 2017 20:54:11 +0000 (UTC) (envelope-from nonesuch@longcount.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 2A8431FE8 for ; Sun, 12 Mar 2017 20:54:11 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mailman.ysv.freebsd.org (Postfix) id 29D7ED0983F; Sun, 12 Mar 2017 20:54:11 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 297C9D0983E for ; Sun, 12 Mar 2017 20:54:11 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDAB91FE6 for ; Sun, 12 Mar 2017 20:54:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk0-x236.google.com with SMTP id 1so209870611qkl.3 for ; Sun, 12 Mar 2017 13:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=sHkBPGzUOo6mI4xuceB0B6eozP68Vc13aYFTNhcmL3Q=; b=DK4O0XNFUXTBWpC/C5mfUcoN7ul7uYZY4dJIoBkQlAOCMdP3bcxXG9gdmshOSmhRkQ 1bPuwsS95emHmMWMBuGAicjoWBrwdJf9ukfAS0LVWX93jpS5V2X4/Cs2i/kDM3LTcQgQ jrrw4tkEfQ+YXQwvXtsHJtktdZ/M1IQEd6KmDPj/otvQlHoYQXl1TkxWYiNlB3cdq4t5 i4wTQRi3hD+N91sDSPqvzpNFakAMZ5MfBBmj9SRLbOrR9mBXKWOxu33ldRWGCuhQU/bm 0SjSRe0dC4IHpxAHJGvoSPrwR6dUW0JKCUal45g3W/tI2EzCbke/TJnsQn9ZKnvcvLt8 cMiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=sHkBPGzUOo6mI4xuceB0B6eozP68Vc13aYFTNhcmL3Q=; b=Cg9/6f9MVJ/XSDO5zBdgPB0jBnqeeFUzWlx24TkFh4aqJvpTQT/3o2XmG8XED7lbZy THbowTpexlH6EnIqc37Oan1xGBeoZsKIkADDMoFy9iAgOz7PYdKVfbBLWj14l42Ex85k SGbV1AbxOnC/q5DB59dn20HjOwBnRMWJoy9xi21U4wXbtrP9weCSbRlmehY2GIqb3Eg7 qur+KCsCo4nd9PI9TZWTTRRfmhyfo4bmroRcmA/LTqMHUDgnhwgomMGRn4zZNv0S31pe LFPFMAz7LTwF5V6h37OxPwGKQ6dR0XiVRY6jWypS32/U4Bxee9ij4XrPpefNKTA5DFor I/+Q== X-Gm-Message-State: AFeK/H2KuSUsbKeQaXfjS4JMelvgar8xQu3/m70XK9iNjz+Bvygg6k+zcxkYMnhdKVYMgQ== X-Received: by 10.55.118.1 with SMTP id r1mr27122168qkc.236.1489352049674; Sun, 12 Mar 2017 13:54:09 -0700 (PDT) Received: from [25.244.225.254] (ool-3f8fcab5.dyn.optonline.net. [63.143.202.181]) by smtp.gmail.com with ESMTPSA id o130sm10871895qke.15.2017.03.12.13.54.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 13:54:08 -0700 (PDT) From: Mark Saad Mime-Version: 1.0 (1.0) Date: Sun, 12 Mar 2017 16:54:07 -0400 Subject: Mini sas forward/ reverse cables ? Message-Id: <4AF2C082-2494-42DE-B2C2-9C750BF39F76@longcount.org> To: hackers@freebsd.org X-Mailer: iPhone Mail (14D27) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 20:54:11 -0000 All I read this post on zfs corruption and there is an interesting comment abo= ut cable types . http://changelog.complete.org/archives/9769-silent-data-corruption-is-real I have a server that has a similar issue ; but due to its age I assumed data= corruption on the drives was a way of life . Disks get old motors burn out p= arts fail etc. Zfs protected my data but I swapped 4 disks out of 60 in the= last 18 months . The part of the story I found interesting was how the dis= ks didn't show up in the controller bios . I have that issue with a similar c= ard on this server . So has anyone ever seen this cabling issue ? Is it wor= th changing? How do I know which cable I have ?=20 --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-hackers@freebsd.org Sun Mar 12 21:02:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22FAED09147 for ; Sun, 12 Mar 2017 21:02:31 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 093831B44 for ; Sun, 12 Mar 2017 21:02:31 +0000 (UTC) (envelope-from michael@fuckner.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0885ED09145; Sun, 12 Mar 2017 21:02:31 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08305D09144 for ; Sun, 12 Mar 2017 21:02:31 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D8071B41 for ; Sun, 12 Mar 2017 21:02:30 +0000 (UTC) (envelope-from michael@fuckner.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489352548; l=802; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=gWt6OJuZuJmgHKnvmTvVa1lguvP0chSFKwq+JO+BcEc=; b=XcrKxPJ/F38J839GFSUk8tPafQIP27uwCh8U1cmkB70bgEAv7CXQbaVFFRpMezVl7P 2KPDI+gvVzLO2CPWEkNG3lub273+u34XA1YPwJ3c35mWb8ZY8Azvm8afBp9YaSBJ9M66 ksG3vjXw7y2oeN4mxVO+MEq7LtigwxaU0mcos= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1UT4IlxRED3LBIlRTDfUFX/rf8N34aEwuWdBLF X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:704:8a01:69e8:f111:2fc4:1d9] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:704:8a01:69e8:f111:2fc4:1d9]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id U0229bt2CL2RMA8 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 12 Mar 2017 22:02:27 +0100 (CET) Subject: Re: Mini sas forward/ reverse cables ? To: Mark Saad , hackers@freebsd.org References: <4AF2C082-2494-42DE-B2C2-9C750BF39F76@longcount.org> From: Michael Fuckner Message-ID: Date: Sun, 12 Mar 2017 22:02:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4AF2C082-2494-42DE-B2C2-9C750BF39F76@longcount.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:02:31 -0000 On 3/12/2017 9:54 PM, Mark Saad wrote: > All > I read this post on zfs corruption and there is an interesting comment about cable types . > > http://changelog.complete.org/archives/9769-silent-data-corruption-is-real > The part of the story I found interesting was how the disks didn't show up in the controller bios . > I have that issue with a similar card on this server . So has anyone > ever seen this cabling issue ? Is it worth changing? How do I know > which cable I have ? it's pretty straight forward- if your controller is multilane and backplane single- you need a straight cable. This is the default! If your controller is single and your backplane is multilane, your cable needs to be cross over. If it is working, there is no need to change. Regards, Michael! From owner-freebsd-hackers@freebsd.org Mon Mar 13 00:48:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD2A3D075AC for ; Mon, 13 Mar 2017 00:48:54 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA641537 for ; Mon, 13 Mar 2017 00:48:54 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9740FD075AB; Mon, 13 Mar 2017 00:48:54 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 952C0D075AA for ; Mon, 13 Mar 2017 00:48:54 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 4DC481536 for ; Mon, 13 Mar 2017 00:48:54 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk0-x22f.google.com with SMTP id y76so212525138qkb.0 for ; Sun, 12 Mar 2017 17:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nTLiKYQT0w8DL0wP2IoGs9372L8OtFE+lBbir1KYjss=; b=iMQ7FH7fhyU19UntcJnhQAlbEXAkuHsAJwtRB+bEOV1QWB4yHLKiNRyzlBZQvLpZIM B3BC/Ghy0kGqdkTdmEZ/oFMy9YpPdngHsqYYI02UwyX5ZFHcurSVEAYXw2FxQaRfRF5x 6ABJDPEr+ZjVV3SWiNGhN62ikgMFQWvE6DRZHZ2pDbBHmpYenZyf5uwKpE3zabQJWRYZ Xa0zbav3XgpKdqjwR8i4CYeMVS1A5EiOWGlj+pDzgl+Wem2TS36PEEUkhJspnjxw1d4M m6tRQWt8VaNbik0q+rlvxyTL235hqjRv0IoU32j+a6Z4j1Vo/VlSczeAM/ytqi/hyCFg lv1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nTLiKYQT0w8DL0wP2IoGs9372L8OtFE+lBbir1KYjss=; b=hcAPSsu7JqaIbJ6GSU62yunQey+EkomqN5cPcmz5tpnsIH0UylZrS027V7k0OZLLsZ uvjPhlNPnA/c/wT6AxKrPqkqrWYJrDR+p7k6a+3MGdzID0Gr21eL5dE+wkD0UbEyfEAY UIhTKHQ6wNfWVMyLrKBH4JMTXjm0i3HIUdYcHxat89Ej02JAdLTf8y2Ts994/FXEY8gp FcmhAJmmDaYeSiH6/WHhCRRakDdvEUvdjJY7EviaUg5tY3YlOFTEi3I0OvbCkirirrj8 jqviQg3L4vKOaH2ItPUsf/oEVd410VHc5kyfsNiSJNUvZB5FIdhXlxStQvdzTG+2QX5K Fgnw== X-Gm-Message-State: AMke39lAzmJAk+YPH5YhXcAkJ0uGc4MXvQhDpGZ3nmsDm9t+mul7jYkYUI+T0SKu72hOEA== X-Received: by 10.55.72.7 with SMTP id v7mr30887857qka.47.1489366132643; Sun, 12 Mar 2017 17:48:52 -0700 (PDT) Received: from [192.168.1.3] (ool-4351f21a.dyn.optonline.net. [67.81.242.26]) by smtp.gmail.com with ESMTPSA id 53sm11167518qtm.69.2017.03.12.17.48.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 17:48:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Mini sas forward/ reverse cables ? From: Mark Saad X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sun, 12 Mar 2017 20:48:50 -0400 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AF2C082-2494-42DE-B2C2-9C750BF39F76@longcount.org> To: Michael Fuckner X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 00:48:54 -0000 > On Mar 12, 2017, at 5:02 PM, Michael Fuckner wrote: >=20 >> On 3/12/2017 9:54 PM, Mark Saad wrote: >> All >> I read this post on zfs corruption and there is an interesting comment a= bout cable types . >>=20 >> http://changelog.complete.org/archives/9769-silent-data-corruption-is-rea= l >> The part of the story I found interesting was how the disks didn't show u= p in the controller bios . > > I have that issue with a similar card on this server . So has anyone > e= ver seen this cabling issue ? Is it worth changing? How do I know > > which cable I have ? >=20 >=20 > it's pretty straight forward- if your controller is multilane and backplan= e single- you need a straight cable. This is the default! >=20 > If your controller is single and your backplane is multilane, your cable n= eeds to be cross over. If it is working, there is no need to change. >=20 What sort of markings would I look for ? Are the connections different ? Als= o the post indicated it was something they overlooked on their initial build= out that gave them a working ( albeit poorly ) setup . > Regards, > Michael! >=20 >=20 >=20 --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-hackers@freebsd.org Mon Mar 13 08:21:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00CF0D07968 for ; Mon, 13 Mar 2017 08:21:24 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA4C01BB6; Mon, 13 Mar 2017 08:21:23 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id 05D22D010C9; Mon, 13 Mar 2017 04:21:21 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id v2D8LKlt045645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Mar 2017 09:21:20 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id v2D8LKmb045644; Mon, 13 Mar 2017 09:21:20 +0100 (CET) (envelope-from pho) Date: Mon, 13 Mar 2017 09:21:20 +0100 From: Peter Holm To: Mark Johnston Cc: freebsd-hackers@FreeBSD.org Subject: Re: draining high-frequency callouts Message-ID: <20170313082120.GA44651@x2.osted.lan> References: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 08:21:24 -0000 On Tue, Jan 10, 2017 at 12:57:12PM -0800, Mark Johnston wrote: > I'm occasionally seeing an assertion failure in softclock_call_cc() when > running DTrace tests on a system with hz=10000. The assertion > (c->c_flags & CALLOUT_ACTIVE) != 0 is failing while a thread is > concurrently draining the callout, which runs at a high frequency. At > the time of the panic, that thread is spinning on the per-CPU callout > lock after having been awoken from "codrain", and CALLOUT_PENDING is > set on the callout. The callout is direct, i.e., it is executed in hard > interrupt context. > > I think this is what's happening: > - callout_drain() is called while the callout is executing but after the > callout has rescheduled itself, and goes to sleep after having cleared > CALLOUT_ACTIVE. > - softclock_call_cc() wakes up the callout_drain() caller, but the > callout fires again before the caller is scheduled. > - the second softclock_call_cc() call sees that CALLOUT_ACTIVE is > cleared and panics. > > Is there anything that prevents this scenario? Is it really correct to > leave CALLOUT_ACTIVE cleared when the per-CPU callout lock must be > dropped in order to acquire a sleepqueue lock? > Is this the same problem? panic: softclock_call_cc: act 0xfffff8000de64800 0 cpuid = 10 time = 1489389893 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0f984c9660 vpanic() at vpanic+0x19c/frame 0xfffffe0f984c96e0 kassert_panic() at kassert_panic+0x126/frame 0xfffffe0f984c9750 softclock_call_cc() at softclock_call_cc+0xae/frame 0xfffffe0f984c98f0 softclock() at softclock+0x12c/frame 0xfffffe0f984c9930 intr_event_execute_handlers() at intr_event_execute_handlers+0x248/frame 0xfffffe0f984c9980 ithread_execute_handlers() at ithread_execute_handlers+0x47/frame 0xfffffe0f984c99b0 ithread_loop() at ithread_loop+0xfc/frame 0xfffffe0f984c9a30 fork_exit() at fork_exit+0x13b/frame 0xfffffe0f984c9ab0 https://people.freebsd.org/~pho/stress/log/kevent7-2.txt I first spotted this @ 12.0-CURRENT #2 r305652M: Fri Sep 9 13:09:03 CEST 2016 It's quite easy to reproduce. - Peter From owner-freebsd-hackers@freebsd.org Mon Mar 13 08:28:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A017D07AFA for ; Mon, 13 Mar 2017 08:28:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3448D1ECA; Mon, 13 Mar 2017 08:28:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4B1D91FE025; Mon, 13 Mar 2017 09:28:07 +0100 (CET) Subject: Re: draining high-frequency callouts To: Peter Holm , Mark Johnston References: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> <20170313082120.GA44651@x2.osted.lan> Cc: freebsd-hackers@FreeBSD.org From: Hans Petter Selasky Message-ID: Date: Mon, 13 Mar 2017 09:27:59 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170313082120.GA44651@x2.osted.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 08:28:58 -0000 On 03/13/17 09:21, Peter Holm wrote: > On Tue, Jan 10, 2017 at 12:57:12PM -0800, Mark Johnston wrote: >> I'm occasionally seeing an assertion failure in softclock_call_cc() when >> running DTrace tests on a system with hz=10000. The assertion >> (c->c_flags & CALLOUT_ACTIVE) != 0 is failing while a thread is >> concurrently draining the callout, which runs at a high frequency. At >> the time of the panic, that thread is spinning on the per-CPU callout >> lock after having been awoken from "codrain", and CALLOUT_PENDING is >> set on the callout. The callout is direct, i.e., it is executed in hard >> interrupt context. >> >> I think this is what's happening: >> - callout_drain() is called while the callout is executing but after the >> callout has rescheduled itself, and goes to sleep after having cleared >> CALLOUT_ACTIVE. >> - softclock_call_cc() wakes up the callout_drain() caller, but the >> callout fires again before the caller is scheduled. >> - the second softclock_call_cc() call sees that CALLOUT_ACTIVE is >> cleared and panics. >> >> Is there anything that prevents this scenario? Is it really correct to >> leave CALLOUT_ACTIVE cleared when the per-CPU callout lock must be >> dropped in order to acquire a sleepqueue lock? >> > > Is this the same problem? > > panic: softclock_call_cc: act 0xfffff8000de64800 0 > cpuid = 10 > time = 1489389893 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0f984c9660 > vpanic() at vpanic+0x19c/frame 0xfffffe0f984c96e0 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0f984c9750 > softclock_call_cc() at softclock_call_cc+0xae/frame 0xfffffe0f984c98f0 > softclock() at softclock+0x12c/frame 0xfffffe0f984c9930 > intr_event_execute_handlers() at intr_event_execute_handlers+0x248/frame 0xfffffe0f984c9980 > ithread_execute_handlers() at ithread_execute_handlers+0x47/frame 0xfffffe0f984c99b0 > ithread_loop() at ithread_loop+0xfc/frame 0xfffffe0f984c9a30 > fork_exit() at fork_exit+0x13b/frame 0xfffffe0f984c9ab0 > > https://people.freebsd.org/~pho/stress/log/kevent7-2.txt > > I first spotted this @ 12.0-CURRENT #2 r305652M: Fri Sep 9 13:09:03 CEST 2016 > It's quite easy to reproduce. > Hi, It depends on the trigger. The panic above just means the callout structure was referred after being freed. Either a drain call is missing or the callout escaped drain. Can you run this test with a kernel built from projects/hps_head aswell? --HPS From owner-freebsd-hackers@freebsd.org Mon Mar 13 13:39:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE242D08B3D for ; Mon, 13 Mar 2017 13:39:22 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD8861AAA; Mon, 13 Mar 2017 13:39:22 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id 9834CD00B47; Mon, 13 Mar 2017 09:39:20 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id v2DDdI4g058077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Mar 2017 14:39:18 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id v2DDdIn2058076; Mon, 13 Mar 2017 14:39:18 +0100 (CET) (envelope-from pho) Date: Mon, 13 Mar 2017 14:39:18 +0100 From: Peter Holm To: Hans Petter Selasky Cc: Mark Johnston , freebsd-hackers@FreeBSD.org Subject: Re: draining high-frequency callouts Message-ID: <20170313133918.GA57972@x2.osted.lan> References: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> <20170313082120.GA44651@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:39:22 -0000 On Mon, Mar 13, 2017 at 09:27:59AM +0100, Hans Petter Selasky wrote: > On 03/13/17 09:21, Peter Holm wrote: > > On Tue, Jan 10, 2017 at 12:57:12PM -0800, Mark Johnston wrote: > >> I'm occasionally seeing an assertion failure in softclock_call_cc() when > >> running DTrace tests on a system with hz=10000. The assertion > >> (c->c_flags & CALLOUT_ACTIVE) != 0 is failing while a thread is > >> concurrently draining the callout, which runs at a high frequency. At > >> the time of the panic, that thread is spinning on the per-CPU callout > >> lock after having been awoken from "codrain", and CALLOUT_PENDING is > >> set on the callout. The callout is direct, i.e., it is executed in hard > >> interrupt context. > >> > >> I think this is what's happening: > >> - callout_drain() is called while the callout is executing but after the > >> callout has rescheduled itself, and goes to sleep after having cleared > >> CALLOUT_ACTIVE. > >> - softclock_call_cc() wakes up the callout_drain() caller, but the > >> callout fires again before the caller is scheduled. > >> - the second softclock_call_cc() call sees that CALLOUT_ACTIVE is > >> cleared and panics. > >> > >> Is there anything that prevents this scenario? Is it really correct to > >> leave CALLOUT_ACTIVE cleared when the per-CPU callout lock must be > >> dropped in order to acquire a sleepqueue lock? > >> > > > > Is this the same problem? > > > > panic: softclock_call_cc: act 0xfffff8000de64800 0 > > cpuid = 10 > > time = 1489389893 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0f984c9660 > > vpanic() at vpanic+0x19c/frame 0xfffffe0f984c96e0 > > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0f984c9750 > > softclock_call_cc() at softclock_call_cc+0xae/frame 0xfffffe0f984c98f0 > > softclock() at softclock+0x12c/frame 0xfffffe0f984c9930 > > intr_event_execute_handlers() at intr_event_execute_handlers+0x248/frame 0xfffffe0f984c9980 > > ithread_execute_handlers() at ithread_execute_handlers+0x47/frame 0xfffffe0f984c99b0 > > ithread_loop() at ithread_loop+0xfc/frame 0xfffffe0f984c9a30 > > fork_exit() at fork_exit+0x13b/frame 0xfffffe0f984c9ab0 > > > > https://people.freebsd.org/~pho/stress/log/kevent7-2.txt > > > > I first spotted this @ 12.0-CURRENT #2 r305652M: Fri Sep 9 13:09:03 CEST 2016 > > It's quite easy to reproduce. > > > > Hi, > > It depends on the trigger. The panic above just means the callout > structure was referred after being freed. Either a drain call is missing > or the callout escaped drain. > > Can you run this test with a kernel built from projects/hps_head aswell? > No problem there. I ran the test for 3 hours without any problems. - Peter From owner-freebsd-hackers@freebsd.org Mon Mar 13 18:39:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13FFFD0A73D for ; Mon, 13 Mar 2017 18:39:01 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEE991A10 for ; Mon, 13 Mar 2017 18:39:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id n37so7330616qtb.3 for ; Mon, 13 Mar 2017 11:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Z2F4iHs+NKqetwYM8fPv68aL/VGDeBWs+Y6A6EFIPx4=; b=t9xkxcv92S1f3kqsivE7nQT2waiHRnKd0WfCDxAO0F8C77y9STH2qzsrFETt0posIl YNsHyz4vLJpPOLEqas+U8asvKUp4lL+PDBuErJ9lS1DuLoXw1+6C0+mLl10sPrQ2mFIg xKDvRiIfg3ZmwifrWePjLbb2uKfPZCigYhSnimAdoK+6jGUEHQJgsWdd+Qt55cnBe8od YIF8yZyDOlD8k+Sck7X9pu+APWGIJCB3Bvw9vEEUlbwWP4zOjL52fhZrfsXs7r5zrme/ pmTQk1HzIL2QiYKVliPYiKMcejO+cnEtXNojQSeNlG9/O73YuhdG8YZKU544ig7UV8sk Bd0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Z2F4iHs+NKqetwYM8fPv68aL/VGDeBWs+Y6A6EFIPx4=; b=MdlG/jGzcmsRbcdQcxC0kTGRzI5wetQDp0vfh2HNppkIx733B3FA/hcZxUBSDiBDeX 3ylzr4Gd4cgEInsguAAdadGmmDq7YY+ihWW5qPC6LmvBvDMWC2XKjSY9ZGfF6obaJGe0 y6ISgCwQ5GnE4lPt1+VFqAUB4kScztDYi0oC71KPgvup4hDAQM3VL+dy7MVpbo57l4jq 3s5Ghwi1bIAtDmLnU7uglG75+zAiipxGrio8eAmrGWCDp5q2bI37MtcS4QRH0caWxkgi nQ811eWEaIEEWovzhCqelY99yVVdW4TKpC0A1HkY6znx0JuKtJPm2+x/UPMjgT3rdWQx OP5g== X-Gm-Message-State: AMke39ksHaTIiMZJUpRfFqVV3lhUy/2n1Nx199gddNBvYYnYG4jflxiaKGKMeXGTSmDVJw== X-Received: by 10.237.55.99 with SMTP id i90mr32836822qtb.262.1489430339808; Mon, 13 Mar 2017 11:38:59 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id s69sm12716372qks.50.2017.03.13.11.38.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:38:59 -0700 (PDT) Sender: Mark Johnston Date: Mon, 13 Mar 2017 11:38:13 -0700 From: Mark Johnston To: Peter Holm Cc: freebsd-hackers@FreeBSD.org Subject: Re: draining high-frequency callouts Message-ID: <20170313183813.GB57357@wkstn-mjohnston.west.isilon.com> References: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> <20170313082120.GA44651@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170313082120.GA44651@x2.osted.lan> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:39:01 -0000 On Mon, Mar 13, 2017 at 09:21:20AM +0100, Peter Holm wrote: > On Tue, Jan 10, 2017 at 12:57:12PM -0800, Mark Johnston wrote: > > I'm occasionally seeing an assertion failure in softclock_call_cc() when > > running DTrace tests on a system with hz=10000. The assertion > > (c->c_flags & CALLOUT_ACTIVE) != 0 is failing while a thread is > > concurrently draining the callout, which runs at a high frequency. At > > the time of the panic, that thread is spinning on the per-CPU callout > > lock after having been awoken from "codrain", and CALLOUT_PENDING is > > set on the callout. The callout is direct, i.e., it is executed in hard > > interrupt context. > > > > I think this is what's happening: > > - callout_drain() is called while the callout is executing but after the > > callout has rescheduled itself, and goes to sleep after having cleared > > CALLOUT_ACTIVE. > > - softclock_call_cc() wakes up the callout_drain() caller, but the > > callout fires again before the caller is scheduled. > > - the second softclock_call_cc() call sees that CALLOUT_ACTIVE is > > cleared and panics. > > > > Is there anything that prevents this scenario? Is it really correct to > > leave CALLOUT_ACTIVE cleared when the per-CPU callout lock must be > > dropped in order to acquire a sleepqueue lock? > > > > Is this the same problem? > > panic: softclock_call_cc: act 0xfffff8000de64800 0 It's hard to say for sure. The minimal patch below fixed the problem for me - could you give it a try? I also did not see any problems while testing on Hans' branch. diff --git a/sys/kern/kern_timeout.c b/sys/kern/kern_timeout.c index 5b70cf2033f5..a9c50fd98fbe 100644 --- a/sys/kern/kern_timeout.c +++ b/sys/kern/kern_timeout.c @@ -1256,7 +1256,8 @@ again: * Succeed we to stop it or not, we must clear the * active flag - this is what API users expect. */ - c->c_flags &= ~CALLOUT_ACTIVE; + if ((flags & CS_DRAIN) == 0) + c->c_flags &= ~CALLOUT_ACTIVE; if ((flags & CS_DRAIN) != 0) { /* @@ -1315,6 +1316,7 @@ again: PICKUP_GIANT(); CC_LOCK(cc); } + c->c_flags &= ~CALLOUT_ACTIVE; } else if (use_lock && !cc_exec_cancel(cc, direct) && (drain == NULL)) { From owner-freebsd-hackers@freebsd.org Mon Mar 13 22:06:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3B4ED0AD12; Mon, 13 Mar 2017 22:06:48 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from manchester-1.man.uk.cluster.ok24.net (manchester-1.man.uk.cluster.ok24.net [IPv6:2001:41c8:51:40::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FCD610BA; Mon, 13 Mar 2017 22:06:48 +0000 (UTC) (envelope-from steven@pyro.eu.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=03a.2017; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=0eMPGR0r07agtR+D5OYSypU16xIjs1jYN8q0pWklGlw=; b=nKvWODKGiDrGyGEvxxTaoIgXD2LU6/va5aRQmo4uTVtRZPFzag5Id6cUGPpSkPg68lRHoMRoO+MbS0sZgLIqi1L3y9Z4NZ4/uns1XY+kktxWxAuvUZ0TZy3UDT11rHFlky5Q3Wji1fKnDzzUXmMlpFYztOfGOsdpD8i5tQrSw1FijYPb6lFj22+z4VIqYz/ZvvUcBwMOSnXyLQaCM6EIqZWmmmzmdfWxfVwQ0PoTk5BodWpvT4jANKHCNjMBX5c+Nn/2MGqVZlKSjgN3Oq9WWWouQUSz14cNdysMqKUEWHieCM3ZvVGDQ1tEnFAzsdf7hiXXtTC5S2djEuhjtOPTBA==; X-Spam-Status: No, score=-0.4 required=2.0 tests=BAYES_00, DKIM_ADSP_DISCARD, RP_MATCHES_RCVD Received: from guisborough-1.rcc.uk.cluster.ok24.net ([217.155.40.118] helo=smtp.ok24.net) by manchester-1.man.uk.cluster.ok24.net with esmtp (Exim 4.80) (envelope-from ) id 1cnY6x-0002Aq-Hc; Mon, 13 Mar 2017 22:06:45 +0000 Received: from kfreebsd-amd64.pyro.eu.org (kfreebsd-amd64.pyro.eu.org [IPv6:2a00:14f0:e033:2000::1]) by smtp.ok24.net (Postfix) with ESMTP id 7517F35021E; Mon, 13 Mar 2017 22:06:39 +0000 (GMT) Received: by kfreebsd-amd64.pyro.eu.org (Postfix, from userid 1000) id 6B15116B6; Mon, 13 Mar 2017 22:06:39 +0000 (GMT) Date: Mon, 13 Mar 2017 22:06:39 +0000 From: Steven Chamberlain To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within) Message-ID: <20170313220639.GB65190@pyro.eu.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:06:49 -0000 --E13BgyNx05feLLmH Content-Type: multipart/mixed; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =46rom this document (TOP SECRET//SI//NOFORN): https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%20Requirements%= 20v1.1%20TOP%20SECRET.pdf version 1.0 said: | 8. (S//NF) [...] If RC4 is used, at least the first 1024 | bytes of the cryptostream must be discarded and may not be used and that is exactly what FreeBSD's libc and in-kernel arc4random implementations do. version 1.1 received input from another agency: | (C//SI//REL FVEY) Coordinated with NSA/CES. and a new requirement was introduced: | (TS//SI) 5.9: Added additional information about proper use of RC4. | 9. (TS//SI) Further than stated above, if RC4 is used the first 3072 | bytes of the cryptostream must be discarded and may not be used. I think you should take that to mean, the NSA has, or suspects someone else to have, a practical attack on RC4 when being used as FreeBSD does currently. The document seems 4-5 years old already as it prohibits use of RC4 at all from 2014 onward. Please consider switching to ChaCha20 in the long term (kern/182610), but right now, at least increase the amount of early keystream that is discarded. Many thanks, Regards, --=20 Steven Chamberlain steven@pyro.eu.org --MW5yreqqjyrRcusr Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="arc4random.patch" Content-Transfer-Encoding: quoted-printable diff -Nru a/head/lib/libc/gen/arc4random.c b/head/lib/libc/gen/arc4random.c --- a/head/lib/libc/gen/arc4random.c 2016-10-12 14:56:14.834409000 +0100 +++ b/head/lib/libc/gen/arc4random.c 2017-03-13 21:57:16.532833171 +0000 @@ -160,7 +160,7 @@ * Discard early keystream, as per recommendations in: * "(Not So) Random Shuffles of RC4" by Ilya Mironov. */ - for (i =3D 0; i < 1024; i++) + for (i =3D 0; i < 3072; i++) (void)arc4_getbyte(); arc4_count =3D 1600000; } diff -Nru a/head/sys/libkern/arc4random.c b/head/sys/libkern/arc4random.c --- a/head/sys/libkern/arc4random.c 2016-11-25 17:20:23.862538000 +0000 +++ b/head/sys/libkern/arc4random.c 2017-03-13 21:58:45.985402563 +0000 @@ -84,11 +84,11 @@ /* * Throw away the first N words of output, as suggested in the * paper "Weaknesses in the Key Scheduling Algorithm of RC4" - * by Fluher, Mantin, and Shamir. (N =3D 256 in our case.) + * by Fluher, Mantin, and Shamir. (N =3D 768 in our case.) * * http://dl.acm.org/citation.cfm?id=3D646557.694759 */ - for (n =3D 0; n < 256*4; n++) + for (n =3D 0; n < 768*4; n++) arc4_randbyte(arc4); =20 mtx_unlock(&arc4->mtx); --MW5yreqqjyrRcusr-- --E13BgyNx05feLLmH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCAAGBQJYxxftAAoJEIzTM2ydu2CcKWcMAIXfG+Y5afRIKbmT2f6htJVO Kj4YK+CqFYc81W05yGFb1xr9RilgDXzNrMNwrbkHn9NJERI5IO0FLtdVI+x1Iund Bokjj2ZkkdkPg72y4V3fAnrKNMFMAzScCWtYccwioWFNPL2NvOpnqQDIuEqQ5qNb xcvtkWcV9Vrh5dIdNn+9Bf21g/Dh4YJ5tKkY965Oi3Sg/1Ij4zM73Jy07j8TRIrL 8siWn195tWnvFMQo151v9VY74l9WcoNd1rgC9bceMGl2/UNAIcnm0j/W5TWTw6mq t8GvTxVQFSvYB2dL7fNNOhP6hSVSb74xC6Tic1tjZM+Okd5EzbW3/FbrcdNWoof1 ZBibe5/HF7I117ITwJ1N0qq5VWdLaAaNKkC7tUOm66lOSQvStZXQDAimnIzPJuke 65dbFDpi1Arr9eFf88uPazh26K2jIdcUGt9Cgeaat6uXFxRW0xAzX81Lo1Ci0Ymk e4S0fExy4fj+tzYcOcsy4zmqy1kzFMBRXM/wm1ToBA== =/kTf -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-hackers@freebsd.org Tue Mar 14 02:04:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EEEDD0B5AB; Tue, 14 Mar 2017 02:04:19 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5E3219FF; Tue, 14 Mar 2017 02:04:18 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: by mail-it0-x233.google.com with SMTP id g138so43349195itb.0; Mon, 13 Mar 2017 19:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4WXRdx3eTTak8PMogKEc5zsSfHSxMruRMQsKsDvTaoo=; b=m2hWhZYZiPdiSYMHM8eI24+wKEIUD8JWh0iu+jDv8LNEOx5lPB9FLvBR546cYnnuZ8 9OCN5VqnEQQhKgWonrrhZlFl3I9OLdNDVxjhODQqTkY3asNUwB1Ie2vWmLUIhIieIr8+ 82NmqadgqmK++LXwoG2HcJgr49RjF/CLSEnpwAuX5aeSnaiI7jfLrGvpw7Ck0kgHcbD8 eeTKj3WWj+uvYJ9rGsI3FIV4HHEotdknDlPkKU7br1Qf5xQ9cZ5RbMavVRwZCxiNihCx bDjMUYwgATgyPkaL6kf2rzRCzUQAOD8DkXTHjW6D1Pugft1XjwJRmnbzC0fDCXO8kRMT e35A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4WXRdx3eTTak8PMogKEc5zsSfHSxMruRMQsKsDvTaoo=; b=AyLjmJirGCQCkRQBwWyscKzsctYJtx9T2AyLdKqHC9MjiLmyvuc3gziZ3HEyT9w1/N wxJdZZ1wUTzOUEt0jsDQGhlcVtAThkW156/k7uf1Lp3GQTY7QptI0sFx06V9GCuz0L/Q GTAKViH8GyfTLigl9x9digp8ZXTUgPBdKek/45jUi5LOXayL/hI1ixo6Zi4+LdlMRDpv Oz0Wg2VkpUKpR0yFXZhCzZtx5MbPG7WPeK7xkWyIP16CrfB2cH1idNiX1cAFULCNef8D Ry+fXwoDx7OFIy8z9BPdLlCkFdVdhbpVcsuJA9HrWODVrVI1hvpdPI3dxbZYKAaiczHJ 6O3w== X-Gm-Message-State: AFeK/H3gPFosPbK95mHuKbpSj4xWGgaLPjVzLu/8O/xAs9cXVDUKi9lHyWmipFUNpux6Hm10hPNa+rbruzYkrQ== X-Received: by 10.36.204.136 with SMTP id x130mr13997913itf.93.1489457057474; Mon, 13 Mar 2017 19:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.13.142 with HTTP; Mon, 13 Mar 2017 19:03:47 -0700 (PDT) In-Reply-To: <20170313220639.GB65190@pyro.eu.org> References: <20170313220639.GB65190@pyro.eu.org> From: Dewayne Geraghty Date: Tue, 14 Mar 2017 13:03:47 +1100 Message-ID: Subject: Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within) To: Steven Chamberlain Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 14 Mar 2017 02:10:42 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 02:04:19 -0000 On 14 March 2017 at 09:06, Steven Chamberlain wrote: > From this document (TOP SECRET//SI//NOFORN): > https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic% > 20Requirements%20v1.1%20TOP%20SECRET.pdf > > version 1.0 said: > > | 8. (S//NF) [...] If RC4 is used, at least the first 1024 > | bytes of the cryptostream must be discarded and may not be used > > and that is exactly what FreeBSD's libc and in-kernel arc4random > implementations do. > > version 1.1 received input from another agency: > > | (C//SI//REL FVEY) Coordinated with NSA/CES. > > and a new requirement was introduced: > > | (TS//SI) 5.9: Added additional information about proper use of RC4. > > | 9. (TS//SI) Further than stated above, if RC4 is used the first 3072 > | bytes of the cryptostream must be discarded and may not be used. > > I think you should take that to mean, the NSA has, or suspects someone > else to have, a practical attack on RC4 when being used as FreeBSD does > currently. The document seems 4-5 years old already as it prohibits use > of RC4 at all from 2014 onward. > > Please consider switching to ChaCha20 in the long term (kern/182610), > but right now, at least increase the amount of early keystream that is > discarded. > > Many thanks, > Regards, > -- > Steven Chamberlain > steven@pyro.eu.org > Thanks Steven. I wasn't aware that OpenBSD was 3.5+ years ahead of the curve in terms of securing against RC4 weaknesses, compared to FreeBSD. Perhaps they have access to a mole ;) The pointer to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610 probably needs a push along. (or a local patch, which mostly applied to /usr/src/lib/libc/gen/arc4random.c ; 2 of 13 hunks need a manual adjustment) From owner-freebsd-hackers@freebsd.org Tue Mar 14 09:12:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E3C5D0B4AD for ; Tue, 14 Mar 2017 09:12:17 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35A4111E9 for ; Tue, 14 Mar 2017 09:12:16 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.85 #1) id 1cniV3-00037y-UO for freebsd-hackers@freebsd.org; Tue, 14 Mar 2017 10:12:13 +0100 Received: from localhost ([::1]:37169 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1cniV3-0001nZ-Tc for freebsd-hackers@freebsd.org; Tue, 14 Mar 2017 10:12:13 +0100 Received: from mx14.freenet.de ([195.4.92.24]:37262) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1cniS3-0008Vo-1p for freebsd-hackers@freebsd.org; Tue, 14 Mar 2017 10:09:07 +0100 Received: from p5ddd7083.dip0.t-ipconnect.de ([93.221.112.131]:36055 helo=freebsd-t420.fritz.box) by mx14.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.85 #1) id 1cniS2-0001rA-Rh; Tue, 14 Mar 2017 10:09:06 +0100 Date: Tue, 14 Mar 2017 10:09:05 +0100 From: Manuel =?iso-8859-1?Q?St=FChn?= To: freebsd-hackers@freebsd.org Subject: mmap device-drivers Message-ID: <20170314090905.GA94880@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-Originated-At: 93.221.112.131!36055 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:12:17 -0000 Hi, is it possible for a device driver to keep track if there are still active mmap() pointers pointing to that device? Linux does have something like struct vm_operations_struct vm_ops = { .close = vm_close, }; where vm_close gets called when any mmapped pointer goes out of scope and the driver can refcount the mappers. Is there something similar in freebsd? From owner-freebsd-hackers@freebsd.org Tue Mar 14 09:15:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60AF4D0B5B9 for ; Tue, 14 Mar 2017 09:15:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA2A13AF for ; Tue, 14 Mar 2017 09:15:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F12CE1FE025; Tue, 14 Mar 2017 10:15:04 +0100 (CET) Subject: Re: mmap device-drivers To: =?UTF-8?Q?Manuel_St=c3=bchn?= , freebsd-hackers@freebsd.org References: <20170314090905.GA94880@freebsd-t420.fritz.box> From: Hans Petter Selasky Message-ID: <9f4864ee-45e4-e8d3-b875-b073921b643f@selasky.org> Date: Tue, 14 Mar 2017 10:14:59 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170314090905.GA94880@freebsd-t420.fritz.box> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:15:50 -0000 On 03/14/17 10:09, Manuel Stühn wrote: > Hi, > is it possible for a device driver to keep track if there are still > active mmap() pointers pointing to that device? > > Linux does have something like > > struct vm_operations_struct vm_ops = > { > .close = vm_close, > }; > > where vm_close gets called when any mmapped pointer goes out of scope and the > driver can refcount the mappers. > > Is there something similar in freebsd? Hi, From what I know from the past, any memory mapped to userspace via MMAP can never be freed. --HPS From owner-freebsd-hackers@freebsd.org Tue Mar 14 09:47:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5716ED0C413 for ; Tue, 14 Mar 2017 09:47:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2EEEC72 for ; Tue, 14 Mar 2017 09:47:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2E9lQ5B077090 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Mar 2017 11:47:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2E9lQ5B077090 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2E9lQr5077089; Tue, 14 Mar 2017 11:47:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Mar 2017 11:47:26 +0200 From: Konstantin Belousov To: Manuel St?hn Cc: freebsd-hackers@freebsd.org Subject: Re: mmap device-drivers Message-ID: <20170314094726.GB16105@kib.kiev.ua> References: <20170314090905.GA94880@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170314090905.GA94880@freebsd-t420.fritz.box> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:47:32 -0000 On Tue, Mar 14, 2017 at 10:09:05AM +0100, Manuel St?hn wrote: > Hi, > is it possible for a device driver to keep track if there are still > active mmap() pointers pointing to that device? > > Linux does have something like > > struct vm_operations_struct vm_ops = > { > .close = vm_close, > }; > > where vm_close gets called when any mmapped pointer goes out of scope and the > driver can refcount the mappers. > > Is there something similar in freebsd? Look at the OBJT_MGTDEVICE pager. It allows device drivers to use managed pages for mappings, which is exactly what you want from the FreeBSD VM. Managed device pagers are currently utilized by drm and xen code, read the source for examples. From owner-freebsd-hackers@freebsd.org Tue Mar 14 09:25:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1B02D0BA02 for ; Tue, 14 Mar 2017 09:25:29 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BC1441CA0 for ; Tue, 14 Mar 2017 09:25:29 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 695E8273B3; Tue, 14 Mar 2017 09:17:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v2E9HmQ2035579; Tue, 14 Mar 2017 09:17:48 GMT (envelope-from phk@phk.freebsd.dk) To: Manuel =?iso-8859-1?Q?St=FChn?= cc: freebsd-hackers@freebsd.org Subject: Re: mmap device-drivers In-reply-to: <20170314090905.GA94880@freebsd-t420.fritz.box> From: "Poul-Henning Kamp" References: <20170314090905.GA94880@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35577.1489483068.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Mar 2017 09:17:48 +0000 Message-ID: <35578.1489483068@critter.freebsd.dk> X-Mailman-Approved-At: Tue, 14 Mar 2017 11:04:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:25:30 -0000 -------- In message <20170314090905.GA94880@freebsd-t420.fritz.box>, Manuel =3D?iso= -8859-1 ?Q?St=3DFChn?=3D writes: >is it possible for a device driver to keep track if there are still >active mmap() pointers pointing to that device? I looked at this back in PCMCIA days and it was not possible, and my attempts to implement it did not succeed. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Tue Mar 14 13:42:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 638F2D0C416 for ; Tue, 14 Mar 2017 13:42:02 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.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 39C5B8C1 for ; Tue, 14 Mar 2017 13:42:02 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.3] (c-73-147-115-187.hsd1.va.comcast.net [73.147.115.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 6DB8B270019D; Tue, 14 Mar 2017 09:41:54 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 6DB8B270019D Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1489498914; bh=WE/2B6XFOfqkN6VQM32/khRbO5R+IaEmmXR+2aNA/Bw=; h=Subject:To:From:Date:From; b=cFrdP1ejWbaU8SHnR7RdEbnoC/F0U541CYNRC4cf/GBTcbwAa9AS5Q7C0dFxEmQUT 3AZ7fZ2TEcNEHT2sfNgyqw331V9axXY9vEGdy08/cV28WviEU2pkc17Wi1Fpz5HZD0 1/o8PMnW5DsvvAZ6oQF7ULpnqafqI43GMwJi2Memzp/8kAuVE/khYet9nJZQ1OMoCW qOTsx2krrdMFjbitglp0Bm9eCkrEPEYDwGnn5SOGpmGPEdA2hbzKazcTX/2SeVmLQ7 FjZOAS4eSTjibvnIoWlxn1yBcQkluVph1MZBgHRUde4Q8j+kArnbpH6ojmkIfrktCY nRNXo1ND51m3g== Subject: Re: PCI speed To: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org References: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> From: Andrew Gallatin Message-ID: <061c8bd6-63d1-2e59-2ab0-c4b48c201e96@cs.duke.edu> Date: Tue, 14 Mar 2017 09:41:53 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 13:42:02 -0000 On 03/03/2017 17:34, Dirk-Willem van Gulik wrote: > Forgive me my ignorance - but for some cards - pciconf(8) nicely lists the speed of the bus: > >> ciss0@pci0:12:0:0: class=0x010400 card=0x3243103c chip=0x323a103c rev=0x01 hdr=0x00 > ... >> cap 10[70] = PCI-Express 2 endpoint max data 128(256) RO NS >> link x4(x8) speed 5.0(5.0) >> cap 11[ac] = MSI-X supports 16 messages, enabled >> Table in map 0x10[0x1c2000], PBA in map 0x10[0x1c4000] >> PCI-e errors = Correctable Error Detected >> Fatal Error Detected >> Unsupported Request Detected > > and that matches exactly with what it is. While for other cards it does not seem to report that: > >> mpt4@pci0:7:8:1: class=0x010000 card=0x10b01000 chip=0x00301000 rev=0x08 hdr=0x00 > .... >> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >> cap 05[58] = MSI supports 1 message, 64 bit >> cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 8 split transactions >> cap 00[70] = unknown > > and in fact seems to mis report the bus - this is a PCIe Gen 2 x4 bus with a x8 Connector Width > holding a LSI 22320SE Ultra320 SCSI dual channel PCIe X4 card. > > How should one interpret this ? > > Dw. > > The mpt seems to be a PCI-X device, not a PCI Express device. So it is likely that the add-on card actually contains a PCI-e to PCI-X bridge chip. PCI Express was *very* hard to get right in the early days of Gen 1 before companies had built up large PCIe IP libraries and test suites. So a lot of companies with existing PCI and PCI-X products shipped "native" PCIe products that were actually composed of a PCIe connector with a third part PCIe to PCI-X bridge. It might be interesting to see what's upstream from the bus. I'd expect there is a PLX (or maybe IDT) device in there. Drew From owner-freebsd-hackers@freebsd.org Tue Mar 14 17:02:25 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90A1BD0CEFA for ; Tue, 14 Mar 2017 17:02:25 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E0FE17EA; Tue, 14 Mar 2017 17:02:24 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id D7FA9D00A96; Tue, 14 Mar 2017 13:02:22 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id v2EH2KC5023059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Mar 2017 18:02:21 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id v2EH2Kk9023058; Tue, 14 Mar 2017 18:02:20 +0100 (CET) (envelope-from pho) Date: Tue, 14 Mar 2017 18:02:20 +0100 From: Peter Holm To: Mark Johnston Cc: freebsd-hackers@FreeBSD.org Subject: Re: draining high-frequency callouts Message-ID: <20170314170220.GA22844@x2.osted.lan> References: <20170110205711.GA86449@wkstn-mjohnston.west.isilon.com> <20170313082120.GA44651@x2.osted.lan> <20170313183813.GB57357@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170313183813.GB57357@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:02:25 -0000 On Mon, Mar 13, 2017 at 11:38:13AM -0700, Mark Johnston wrote: > On Mon, Mar 13, 2017 at 09:21:20AM +0100, Peter Holm wrote: > > On Tue, Jan 10, 2017 at 12:57:12PM -0800, Mark Johnston wrote: > > > I'm occasionally seeing an assertion failure in softclock_call_cc() when > > > running DTrace tests on a system with hz=10000. The assertion > > > (c->c_flags & CALLOUT_ACTIVE) != 0 is failing while a thread is > > > concurrently draining the callout, which runs at a high frequency. At > > > the time of the panic, that thread is spinning on the per-CPU callout > > > lock after having been awoken from "codrain", and CALLOUT_PENDING is > > > set on the callout. The callout is direct, i.e., it is executed in hard > > > interrupt context. > > > > > > I think this is what's happening: > > > - callout_drain() is called while the callout is executing but after the > > > callout has rescheduled itself, and goes to sleep after having cleared > > > CALLOUT_ACTIVE. > > > - softclock_call_cc() wakes up the callout_drain() caller, but the > > > callout fires again before the caller is scheduled. > > > - the second softclock_call_cc() call sees that CALLOUT_ACTIVE is > > > cleared and panics. > > > > > > Is there anything that prevents this scenario? Is it really correct to > > > leave CALLOUT_ACTIVE cleared when the per-CPU callout lock must be > > > dropped in order to acquire a sleepqueue lock? > > > > > > > Is this the same problem? > > > > panic: softclock_call_cc: act 0xfffff8000de64800 0 > > It's hard to say for sure. The minimal patch below fixed the problem for > me - could you give it a try? I also did not see any problems while > testing on Hans' branch. > > diff --git a/sys/kern/kern_timeout.c b/sys/kern/kern_timeout.c > index 5b70cf2033f5..a9c50fd98fbe 100644 > --- a/sys/kern/kern_timeout.c > +++ b/sys/kern/kern_timeout.c > @@ -1256,7 +1256,8 @@ again: > * Succeed we to stop it or not, we must clear the > * active flag - this is what API users expect. > */ > - c->c_flags &= ~CALLOUT_ACTIVE; > + if ((flags & CS_DRAIN) == 0) > + c->c_flags &= ~CALLOUT_ACTIVE; > > if ((flags & CS_DRAIN) != 0) { > /* > @@ -1315,6 +1316,7 @@ again: > PICKUP_GIANT(); > CC_LOCK(cc); > } > + c->c_flags &= ~CALLOUT_ACTIVE; > } else if (use_lock && > !cc_exec_cancel(cc, direct) && (drain == NULL)) { > I ran the test that triggered the panic all night. I follow up with a buildworld + a random mix of tests for a total of 24 hours. No problems seen. -- Peter From owner-freebsd-hackers@freebsd.org Tue Mar 14 19:17:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDE7CD0C233 for ; Tue, 14 Mar 2017 19:17:55 +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 A906516D8 for ; Tue, 14 Mar 2017 19:17:55 +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 AD76A56575; Tue, 14 Mar 2017 14:17:54 -0500 (CDT) Subject: Re: Absolute timeouts and clock adjustments To: Sebastian Huber , FreeBSD References: <58AD5802.30908@embedded-brains.de> From: Eric van Gyzen Message-ID: <7f0f0316-3ff1-8264-2602-bae1d3404aab@FreeBSD.org> Date: Tue, 14 Mar 2017 14:17:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <58AD5802.30908@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:17:55 -0000 On 02/22/2017 03:21, Sebastian Huber wrote: > Hello, > > I try to figure out how the timeout mechanisms work in current FreeBSD. > My interpretation (which could be completely wrong) of POSIX is > something like this should happen: > > now 2017-02-22 > sem_timedwait(s, 2023-12-13) > external entity adjusts time to 2050-01-01 > timeout of sem_timedwait() occurs due to the time adjustment > > Inside the kernel all absolute timeouts seem to use the uptime. [...] > The abs_timeout_gethz() returns the interval length in ticks of > [abstime->cur, abstime->end]. Since the msleep() uses the uptime, does > this mean that timeouts trigger not immediately due to time adjustments > in FreeBSD? I just fixed this in 12-CURRENT. I'll merge it back to 11-STABLE in a few weeks. Eric From owner-freebsd-hackers@freebsd.org Wed Mar 15 03:50:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C519D0CA10 for ; Wed, 15 Mar 2017 03:50:51 +0000 (UTC) (envelope-from dreamashish21@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4830715FB for ; Wed, 15 Mar 2017 03:50:51 +0000 (UTC) (envelope-from dreamashish21@gmail.com) Received: by mail-io0-x231.google.com with SMTP id f84so12659682ioj.0 for ; Tue, 14 Mar 2017 20:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=trlejUE3/A88fSesGb5J3S11zf+PdidVHMBrswC9nO4=; b=F55mdc0+Xu+e94rIR5z/Rz2PTXJyxyfApgJga90k17Jg38R4C83Dc4sWE8a8CWcnXC Gkn16NKb2dLDosoj0UETF9QS90xuZ1aVbOICNTSZZyPGsPriAvhoLsRbM3x8O+jrRkAM H4qmt4mG3XpcWWUt02TTRPG1zUKdIRg0D34qA+RZYgdmR/PNA/pbUKDfOSv68P9+Husm RKyLaG+y4IZyAAb67VUhWuvZYXEOYJpM+4sjiCovSAFvQ6SwZL+XbN8aTP0li37SKP9v DTlW0QLH1qiDuDscBpf3wcXqaHFavfysf/as0Pf0UHKcQIVKZMFcnUk9Ps3ebuz/cv5g WJKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=trlejUE3/A88fSesGb5J3S11zf+PdidVHMBrswC9nO4=; b=QVHikZmqAJxRoAkfms4vjrIQjJNmrwchMHjpExrOtxpg+OLj8Ji1iFwQs1+UY31FKn OAPve8bAHEWq45SAVO8ukPS0GmTkQG6apzxiuJB4hYzIwkdA93xSJtg0wKiEazgYesEt 7nG2uR2uAXzux8hWTPclWRhH4N9iU4MlBlTohEilxRZ1K9jYrKLZuCObGPBOxPlozYqR EG0YFPm6bROQanlD/nMF7/snSZL7X0z9EWK24R6klYzHEQlrbCScydh0EQHViOSPvIWb LHqT1At0TnBV3aHPG63xUcXqPQzlsoqdh9ihS+D6RiF4nZfQNNhdyz2uNcoV1PujoGr0 uQrQ== X-Gm-Message-State: AFeK/H2i9d6klYQeoWirZgD1jA4X8KbHZZhDG7o8CI6zgtomGb0WNV+SFVSMjIjScel89S2JqpXAw6A3o+KhWw== X-Received: by 10.107.53.91 with SMTP id c88mr3803955ioa.24.1489549850506; Tue, 14 Mar 2017 20:50:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.59.214 with HTTP; Tue, 14 Mar 2017 20:50:10 -0700 (PDT) From: Ashish Gahlot Date: Wed, 15 Mar 2017 09:20:10 +0530 Message-ID: Subject: GSOC 2017 To: cattelan@digitalelves.com Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 03:50:51 -0000 Hello Sir, I am 3rd year undergraduate and interested in kload project which is listed in the Gsoc project list. I cannot find a mentor on the website so I contacted you directly. Will you be the mentor for this project? Thanks, Ashish -- Ashish Kumar Gahlot III year, UG Govt. Engg. College, Ajmer, India From owner-freebsd-hackers@freebsd.org Wed Mar 15 13:06:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29A83D0C90C; Wed, 15 Mar 2017 13:06:30 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from manchester-1.man.uk.cluster.ok24.net (manchester-1.man.uk.cluster.ok24.net [IPv6:2001:41c8:51:40::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CA821AA2; Wed, 15 Mar 2017 13:06:29 +0000 (UTC) (envelope-from steven@pyro.eu.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=03a.2017; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=2VYylVX9OPcR1EjzvHUgdPRyShDuxjE+MpecT9gb4KQ=; b=KdVCo+MpL7yx9pSwUAB9GWZNMC+Dl26WIFXIokC1kM14KbYBxMvUiYfOpKlK+dLWDkKaMBJ54i4yMXhHM8brZ6nKq234R20+btoohQIIdaPaQM0GfdH1DND5JMKxSJ6th8D/zq678FTclxGVlxNMl1E4r4PkeCjecjw5N6t/9WL4F1E7ieQZX7L6idHlt77jtCoGCgufchXu/bEpr5J9TOQnuejNrRvD4aqBAT3nYAXZP4V6/gvs72PkIeqedm4LQVQrevjQbE4qi5SyuSLVdKJQGwQ4VKSn/dzp2YvA9x3objv6xA8V689eDqPG22543Gzm/hsdsCAAY3Zns4gEhg==; X-Spam-Status: No, score=-0.1 required=2.0 tests=BAYES_00, DKIM_ADSP_DISCARD, RP_MATCHES_RCVD Received: from guisborough-1.rcc.uk.cluster.ok24.net ([217.155.40.118] helo=smtp.ok24.net) by manchester-1.man.uk.cluster.ok24.net with esmtp (Exim 4.80) (envelope-from ) id 1co8d5-00017G-RC; Wed, 15 Mar 2017 13:06:22 +0000 Received: from kfreebsd-amd64.pyro.eu.org (kfreebsd-amd64.pyro.eu.org [IPv6:2a00:14f0:e033:2000::1]) by smtp.ok24.net (Postfix) with ESMTP id ADE113517AF; Wed, 15 Mar 2017 13:06:15 +0000 (GMT) Received: by kfreebsd-amd64.pyro.eu.org (Postfix, from userid 1000) id 964AF1CC6; Wed, 15 Mar 2017 13:06:15 +0000 (GMT) Date: Wed, 15 Mar 2017 13:06:15 +0000 From: Steven Chamberlain To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: arc4random weakness Message-ID: <20170315130615.GC25448@pyro.eu.org> References: <20170313220639.GB65190@pyro.eu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <20170313220639.GB65190@pyro.eu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:06:30 -0000 --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Steven Chamberlain wrote: > Please consider switching to ChaCha20 in the long term (kern/182610), > but right now, at least increase the amount of early keystream that is > discarded. Many, many thanks delphij+so for applying the latter change so quickly! Also it is great to see INHERIT_ZERO was added to mmap(2)! (It will avoid the overhead of a getpid(2) syscall on every call to arc4random_buf(3) to determine if reseeding is needed. That wasn't guaranteed reliable anyway; if you have forked twice, then by chance/manipulation the new pid *could* be the same as the ancestor's). Thanks! Regards, --=20 Steven Chamberlain steven@pyro.eu.org --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCAAGBQJYyTxGAAoJEIzTM2ydu2Cc5V4MAIwiFty64DmrCkXJPyxYQ/LI M+yRfr94k7llkoi/asd/jCf1Argub3pAV5GY/D19DPVcGxw7QbwBfZyDrL6N7j2E PQaSu820zNVHjKqbzASFgquDeG8xGlg8DWliaZ2hnE7ebnlk4z0bjpsOgz6616uZ HOskQCheHOvpG3PmUolZguh1MngwuhGh38DcX4ewNU4JTus6VYR14CquQiuzts6y JpWB9XbouoZoKn4IwGKYaIAyk5/FfQ+HXya+seUWgXxNlvqsh3428Wh5vnSpvpTZ bKAkgOGzR7w1lU0QYm/yj6S+5CTA5K1/ap6QykhQS5Nu+KBKZECsaMHzypEqsiGG cyNmqOTS8aIGEonP4J/uMnis+2JJiUe6BLURbz7zk5e07Pln5yaxw3KOlnVVD+6D 9lbPzFkkeFuc6qiAYMe+gPeZKvHlZwtf9Ej1Di2LtvPDEYO6MXOIHvwtBCvDRMkB 24WkCt8htqxLp569bNkrB5WeU/Xk2gTwKxXXOX4uog== =KsfP -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- From owner-freebsd-hackers@freebsd.org Wed Mar 15 13:53:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F705D0D690 for ; Wed, 15 Mar 2017 13:53:52 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 C64D915A4 for ; Wed, 15 Mar 2017 13:53:51 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.lan.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id AD74B7900 for ; Wed, 15 Mar 2017 14:53:46 +0100 (CET) Subject: Re: arc4random weakness To: freebsd-hackers@freebsd.org References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> From: Jan Bramkamp Message-ID: <76e73904-82be-ed19-5757-ab58615ffb44@rlwinm.de> Date: Wed, 15 Mar 2017 14:53:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170315130615.GC25448@pyro.eu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:53:52 -0000 On 15/03/2017 14:06, Steven Chamberlain wrote: > Steven Chamberlain wrote: >> Please consider switching to ChaCha20 in the long term (kern/182610), >> but right now, at least increase the amount of early keystream that is >> discarded. > > Many, many thanks delphij+so for applying the latter change so quickly! > > Also it is great to see INHERIT_ZERO was added to mmap(2)! Can we also get MAP_ZERO to deal with truncation of mmap()ed file descriptors? From owner-freebsd-hackers@freebsd.org Wed Mar 15 18:45:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCACBD0EC70 for ; Wed, 15 Mar 2017 18:45:29 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darth.immure.com", Issuer "darth.immure.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8EA98EF for ; Wed, 15 Mar 2017 18:45:29 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTPS id v2FIjLNJ050504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Mar 2017 13:45:21 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.15.2/Submit) id v2FIjL36050503; Wed, 15 Mar 2017 13:45:21 -0500 (CDT) (envelope-from bob) Date: Wed, 15 Mar 2017 13:45:21 -0500 From: Bob Willcox To: Andrii Stesin Cc: "Rodney W. Grimes" , hackers list Subject: Re: Help with silent reboot of 10.3-stable system Message-ID: <20170315184521.GB8132@rancor.immure.com> Reply-To: Bob Willcox References: <86b89c6c-9a00-1033-4181-a7e0da2ed66f@digitaldaemon.com> <201703081727.v28HRvp6001740@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:45:29 -0000 Just to follow up on this. I updated the system to r314889 nearly a week ago and it hasn't rebooted since. No real idea if this had anything to do with it or not. The other thing that I did is order new hardware and start building a replacement system. Maybe that was it! :) Bob On Wed, Mar 08, 2017 at 08:05:55PM +0200, Andrii Stesin wrote: > I bet for faulty RAM module > > On Mar 8, 2017 19:47, "Rodney W. Grimes" > wrote: > > > > Is your system swapping to disk? Heavily? > > > > > > Might want to check the swap space on disk. > > > > > > I had spontaneous reboots some years ago because of bad swap space on > > > disk. (Got a new disk, 'dd'-ed the old disk to the new disk, reboot on > > > the new disk and everything was fine) > > > > > > Jan > > > > Good possibilty too, though usually this one causes console message > > to be spewed out and evetually a swap pager panic. Though no evidence > > is left behind beccase the disk couldnt be used to indicate an issue. > > > > Your probably not around the console when this happens Bob? > > It may be possible to hook up a serial console and capture > > the panic if it is happening. > > > > There are other failue modes that leave no on disk trace as well, > > but well spit out a panic to a serial console. > > > > > On 03/07/2017 20:56, Bob Willcox wrote: > > > > Over the past month or so my network fileserver system (NFS support > > for my > > > > entire, small, network) has begun silently rebooting itself. Here is > > the uname > > > > -a output: > > > > > > > > FreeBSD vader.immure.com 10.3-STABLE FreeBSD 10.3-STABLE #15 r313997: > > Mon Feb 20 14:40:00 CST 2017 bob@vader.immure.com:/usr/obj/usr/src/sys/GENERIC > > amd64 > > > > > > > > At first I suspected that it might be the power supply as it was a > > couple of > > > > years old so I replaced that. Unfortunately, it has begun doing it > > again (had > > > > a couple of weeks respite) so now my suspicions seem to have been > > incorrect. > > > > > > > > I was hoping that someone might be able to give me some clues on what > > I can do > > > > to reveal the problem. Are there any general debug settings for the > > kernel (or > > > > elsewhere) that would maybe give an indication of why it is being > > rebooted > > > > (assuming it's a software problem)? > > > > > > > > Thanks for any suggestions you may have! > > > > > > > > Bob > > > > > > > > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > > freebsd.org" > > > > > > > -- > > Rod Grimes > > rgrimes@freebsd.org > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Bob Willcox | If a program is useful, it will be changed. bob@immure.com | Austin, TX | From owner-freebsd-hackers@freebsd.org Wed Mar 15 20:43:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E964D0D32F for ; Wed, 15 Mar 2017 20:43:12 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 C9D149B4 for ; Wed, 15 Mar 2017 20:43:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id v2so2015618lfi.2 for ; Wed, 15 Mar 2017 13:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=VJIy1Qdz1Pt2nG6MUjLkVrPRFkcy2yK47lBs53Vadtg=; b=r7m/i3JdRk9HePEZM8LKxujuGwl6x8jjx7uassDQIfF3jlgVUoRCiuGFASIjEKLZ55 5fcdE0DecWBgQ1x0x6tbeHCVUPALhSa8wDivmYTVVEST8DcRk3ru2ujqnit26boZkH9b 3PQkH3ZL0zO+P7AXtwywywY74Q/pKqQJWsGaHWqKAeNbMX++dRMCzEnOGh/ovXJZTz1P niYnKaIVS/tNgtczgxb8yRI+Q5Whw3rCk1t83Z8pT/pRhgR80jm944jnVbIMpiaxSjzE uhf4k/g8VleycKK0xk+XtV+O9vsUoaLty+1eBWSjv8Phmwj4rmo9yY/FVznxre4MKlNF VwJA== X-Gm-Message-State: AFeK/H0Pvxw0ZZs87+ti58MTDf5CBaqWhbJgpjej1taTQRCivqzhMUJNYu/SDumIOin2Rw== X-Received: by 10.25.35.9 with SMTP id j9mr1551385lfj.62.1489608817817; Wed, 15 Mar 2017 13:13:37 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id l78sm498085lfl.59.2017.03.15.13.13.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 13:13:37 -0700 (PDT) Subject: Re: arc4random weakness To: Steven Chamberlain , freebsd-security@freebsd.org, freebsd-hackers@freebsd.org References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> From: Andrey Chernov Message-ID: <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> Date: Wed, 15 Mar 2017 23:13:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170315130615.GC25448@pyro.eu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IW8vRQi5Oug3kvNAmDSvknaK7slsa26E3" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:43:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IW8vRQi5Oug3kvNAmDSvknaK7slsa26E3 Content-Type: multipart/mixed; boundary="vgsQt28TqTXLWtKeuESqb2p3dEqopMkgU"; protected-headers="v1" From: Andrey Chernov To: Steven Chamberlain , freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> Subject: Re: arc4random weakness References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> In-Reply-To: <20170315130615.GC25448@pyro.eu.org> --vgsQt28TqTXLWtKeuESqb2p3dEqopMkgU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15.03.2017 16:06, Steven Chamberlain wrote: > Also it is great to see INHERIT_ZERO was added to mmap(2)! It is not so great. For a program which forks very often zeroing even one page will be slowdown. It will be better and faster to implement it as fork syscall wrapper setting single variable, as it already done for threaded lib. --vgsQt28TqTXLWtKeuESqb2p3dEqopMkgU-- --IW8vRQi5Oug3kvNAmDSvknaK7slsa26E3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyaBpAAoJEKUckv0MjfbK4MMH/j2D3lV/qC4y/7Z/zHkVCOkY t9MQLZ/9sMuWYzKyKAiIsv6FqdEHnWyYxA52aoCh9DptMMaOb+tzd6I0OnNY5FOY bxU+E6olYhaDu4Hj3+uxLvvOMYF0fim+LWJboqE18/zyG4/GbVOuTU3E2v7sTPZZ o6IrEKL/yqkuOkGznh662T6OiVDzS3SHjL7ewtgfNLhLhh8yA7zRQ0scQD7TjMEe tzt059vvL6rDxcvQsMWPgUjMUzfPqsElsbjUQkXVo+wQCi7ozS6jgOTkdXaZZ59+ 8+bJPKOj8WTL096A2HsnKggSYUSTlI6sfqvo2jhwt54KTBUMBgHupjj685txbEs= =MjFb -----END PGP SIGNATURE----- --IW8vRQi5Oug3kvNAmDSvknaK7slsa26E3-- From owner-freebsd-hackers@freebsd.org Thu Mar 16 12:57:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD3FBD0C0D2; Thu, 16 Mar 2017 12:57:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 76844130F; Thu, 16 Mar 2017 12:57:15 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 57B868F84; Thu, 16 Mar 2017 12:48:48 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 6F3DD40CA; Thu, 16 Mar 2017 13:48:45 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andrey Chernov Cc: Steven Chamberlain , freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: arc4random weakness References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> Date: Thu, 16 Mar 2017 13:48:45 +0100 In-Reply-To: <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> (Andrey Chernov's message of "Wed, 15 Mar 2017 23:13:26 +0300") Message-ID: <86k27pz8sy.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:57:15 -0000 Andrey Chernov writes: > Steven Chamberlain writes: > > Also it is great to see INHERIT_ZERO was added to mmap(2)! > It is not so great. For a program which forks very often zeroing even > one page will be slowdown. Wouldn't it be possible to just set up the page entry but leave it unmapped, so that it is paged in (and zeroed if necessary) on first access? Thus, a process that uses arc4random() and fork()s would not incur a penalty until (and unless) the child uses arc4random() too. > It will be better and faster to implement it as fork syscall wrapper > setting single variable, as it already done for threaded lib. fork() and vfork() and pdfork() and... From a security point of view, I prefer to have it in a single place. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@freebsd.org Thu Mar 16 13:19:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A905BD0CED0; Thu, 16 Mar 2017 13:19:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BC331781; Thu, 16 Mar 2017 13:19:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2GDJkXC060372 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 15:19:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2GDJkXC060372 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2GDJktA060371; Thu, 16 Mar 2017 15:19:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 16 Mar 2017 15:19:46 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Cc: Andrey Chernov , freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, Steven Chamberlain Subject: Re: arc4random weakness Message-ID: <20170316131946.GN16105@kib.kiev.ua> References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> <86k27pz8sy.fsf@desk.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86k27pz8sy.fsf@desk.des.no> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:19:54 -0000 On Thu, Mar 16, 2017 at 01:48:45PM +0100, Dag-Erling Sm??rgrav wrote: > Andrey Chernov writes: > > Steven Chamberlain writes: > > > Also it is great to see INHERIT_ZERO was added to mmap(2)! > > It is not so great. For a program which forks very often zeroing even > > one page will be slowdown. > > Wouldn't it be possible to just set up the page entry but leave it > unmapped, so that it is paged in (and zeroed if necessary) on first > access? Thus, a process that uses arc4random() and fork()s would not > incur a penalty until (and unless) the child uses arc4random() too. This is how the forking code works, without any additional coding, for the INHERIT_ZERO regions as well. > > > It will be better and faster to implement it as fork syscall wrapper > > setting single variable, as it already done for threaded lib. > > fork() and vfork() and pdfork() and... From a security point of view, I > prefer to have it in a single place. > > DES > -- > Dag-Erling Sm??rgrav - des@des.no > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Mar 16 17:24:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCEADD0F1B6; Thu, 16 Mar 2017 17:24:50 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 8BE041D00; Thu, 16 Mar 2017 17:24:50 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-ot0-x233.google.com with SMTP id x37so63790431ota.2; Thu, 16 Mar 2017 10:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ngkX5mYfoinHeE4jRP3pwrbhM2Kbi0cDcWPXKHpTAaQ=; b=NNyKyzO3yK2dadkEX+e1p5oTk69yfAAX++mHhx70OPCZlYJZRNnVuzizb4IEnBhPii PRuefvhXPyX6eEL5+OM4nXC/qWxH/LBTgYGssBMETod7r7DU1OzSmqGXQFmqWRrf6MVO KPBc5tBXTN5SD9VZX0dk4fNg6MJ0tlQf+BJEmeWYavn8P1k9cfdKrGptQ3mioksA7CTb kzQ5J2rxJC+ZqSwEn++EnZFLJYpLLMYvRfKyJXM92gGj5rUcQ0mkqXqvjrz1hz/FQ7Cf a3m5HMJX2ELN1+mKO3pB+gIUUCEcWGc4ojViOhQNryOt2JNd98VCO90YrzjmEzab1Lbo M50g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ngkX5mYfoinHeE4jRP3pwrbhM2Kbi0cDcWPXKHpTAaQ=; b=LIHHrwJVuzsm0tjMtxNtRYL7jy8IfBK+avaIhaF/kgwevCy6jTvBDowMh3yHRPc41L dgjt42Dqw3zimDZTI/AJctB0hP0F9pWsgjPuaftQPKncBGkLkQrnFbsCCBOB0Ft7wKW3 0YUtMSZe+CPrxElaY2kwHU6/a7vgq9GJAqxoxwPwCM/ON2mVtg0YQGH7DB5g6oWE9k2Z SzZSdiwshLqTf9bUiQUbML+tjh/fgB/b5d1M1v8rE1eMFyo0ohffaB91PJSucd7dAS2y ffATTZVxYTxu2WN8oWKYPgIOf94rn4Pno3251NgtqkgGogA2Y29eGK8zpYs4V5WM2OLU TR7Q== X-Gm-Message-State: AFeK/H27qy1Tsnkd3Q69PoDP6NpGBM6jHqTVG4dH3wXZhKGolGtPjCmTufNZ0gI9EmJuT7RfcNjtnjj659wwMw== X-Received: by 10.157.30.198 with SMTP id n64mr4787380otn.133.1489685089589; Thu, 16 Mar 2017 10:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.48.198 with HTTP; Thu, 16 Mar 2017 10:24:48 -0700 (PDT) In-Reply-To: <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> From: Xin LI Date: Thu, 16 Mar 2017 10:24:48 -0700 Message-ID: Subject: Re: arc4random weakness To: Andrey Chernov Cc: Steven Chamberlain , "freebsd-security@freebsd.org" , freebsd Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:24:50 -0000 On Wed, Mar 15, 2017 at 1:13 PM, Andrey Chernov wrote: > On 15.03.2017 16:06, Steven Chamberlain wrote: >> Also it is great to see INHERIT_ZERO was added to mmap(2)! > > It is not so great. For a program which forks very often zeroing even > one page will be slowdown. It will be better and faster to implement it > as fork syscall wrapper setting single variable, as it already done for > threaded lib. I think it's exactly what it was done (and unlike a fork wrapper, the zeroing only happens on-demand, i.e. when the page is first touched). Cheers, From owner-freebsd-hackers@freebsd.org Thu Mar 16 19:26:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3807D0FD54 for ; Thu, 16 Mar 2017 19:26:20 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (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 652F412E4 for ; Thu, 16 Mar 2017 19:26:20 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id v2so4075146lfi.2 for ; Thu, 16 Mar 2017 12:26:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GlrQJNbPdzdNm/lQHuJg8aBmGprZbm+LeyFtzV3SPkk=; b=sqGlYhuU8meedp82bA21aGcM4Trals47HBiQY0qlwydxxBroZmPmAz5epqHIAmxZQ8 B5kKeBvlPVNG8MaKVUSSwHH/bYCErdiSEsSYZSr0CO8x0hyznAX0Z9s2MS4MuLSF6UJU KPPZcV6hm+cTuytoYMmTswY0rkZNO8XAkR4V1DzTvcejy2mnkFAKlHPfhdszm2a/mKOl LhDQIDVMhzi8GgI+9sAquUB0vYIncgBPKUwyZ3+l/TPQEQ/gnht6hQYB5ON0+XCz+se9 wY9fOPc7QDpfHZZIwJAFzjXYWzppeuGrG9uyVggTHy1+RToa4dUSD3Bk2Z5M+y48Gzn5 JLfQ== X-Gm-Message-State: AFeK/H0t3aH0MykccQnwFtqCDnK+2ViBIkBw2qPz12/Xd7g2u3BimUMr2uSJx1ACBJYoUQ== X-Received: by 10.46.80.93 with SMTP id v29mr3137577ljd.94.1489692377938; Thu, 16 Mar 2017 12:26:17 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id s7sm1062664lja.50.2017.03.16.12.26.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 12:26:17 -0700 (PDT) Subject: Re: arc4random weakness To: Xin LI References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> Cc: Steven Chamberlain , des@des.no, kostikbel@gmail.com, "freebsd-security@freebsd.org" , freebsd From: Andrey Chernov Message-ID: <8677f9d8-b326-2526-47ce-f2e18421c074@freebsd.org> Date: Thu, 16 Mar 2017 22:26:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 19:26:20 -0000 On 16.03.2017 20:24, Xin LI wrote: > On Wed, Mar 15, 2017 at 1:13 PM, Andrey Chernov wrote: >> On 15.03.2017 16:06, Steven Chamberlain wrote: >>> Also it is great to see INHERIT_ZERO was added to mmap(2)! >> >> It is not so great. For a program which forks very often zeroing even >> one page will be slowdown. It will be better and faster to implement it >> as fork syscall wrapper setting single variable, as it already done for >> threaded lib. > > I think it's exactly what it was done (and unlike a fork wrapper, the > zeroing only happens on-demand, i.e. when the page is first touched). Theo kindly explained that zeroing whole page instead of single variable suits to his newest arc4random better, since clears two structs at once (including ChaCha state), making some form of backward secrecy. From owner-freebsd-hackers@freebsd.org Fri Mar 17 06:04:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B57AD1005D for ; Fri, 17 Mar 2017 06:04:02 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (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 49DCC12F6 for ; Fri, 17 Mar 2017 06:04:01 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (cl-3506.cgn-01.de.sixxs.net [IPv6:2001:4dd0:ff00:db1::2]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 413E2A80CD for ; Fri, 17 Mar 2017 07:03:57 +0100 (CET) Date: Fri, 17 Mar 2017 07:03:54 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: arc4random weakness Message-ID: <20170317060354.GB9951@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 06:04:02 -0000 On Wed, Mar 15, 2017 at 11:13:26PM +0300, Andrey Chernov wrote: > On 15.03.2017 16:06, Steven Chamberlain wrote: > > Also it is great to see INHERIT_ZERO was added to mmap(2)! > > It is not so great. For a program which forks very often zeroing even > one page will be slowdown. It will be better and faster to implement it > as fork syscall wrapper setting single variable, as it already done for > threaded lib. A program which forks very often is slow enough by nature. I don't think the overhead of zeroing another page is going to make a huge difference for that. Joerg From owner-freebsd-hackers@freebsd.org Fri Mar 17 06:30:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B11A2D1056A for ; Fri, 17 Mar 2017 06:30:54 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0FB1D33 for ; Fri, 17 Mar 2017 06:30:54 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x229.google.com with SMTP id u132so7881360wmg.0 for ; Thu, 16 Mar 2017 23:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=SayUz3kC5ZCZVz0f8q9zHfUCcxKBkc0BDCf3ktvnywA=; b=b23VEKzBuE43xySfO9lWtGgvN3Xjv5hUQjHe3Rj3NLpdPffT7Of/FWCrX0/PDf5dil b5Xu360TrBuIcbKKREWXlaQxib7CWt+vFXmjnqErtoER0J9bjBHTIT1A+gtAWpwImgUm 2qdaawmbIutf7fiGwLiKYtfQZeGz8q0fF28cnCQ04ooU1WH0LUjBBarE/1WHdFdZHH4v s7qDwUrCCbDey+Mkp6gU7QARVv5miy3grEI0nZt7q4QQoUOpuIZZHdn7/xHBD/Oin8J4 6j1lv2rghyy55SoQ+CMI0oLnn76zBYBtWkP0aBdeO9lfhHji3SRbWmQChXJjdia4K53g IuXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=SayUz3kC5ZCZVz0f8q9zHfUCcxKBkc0BDCf3ktvnywA=; b=nkRqaZDiT5VzkdNtkv+y+hJuGWVjdponkJSOispheio2qIbq2SJl5VuAec7u67bdf1 E+c4SvmSlTeayp8Ljv8IehDclkY0zOkZ55TP+9vke0VLg17R+f3/J5wXsd3hy5BiHgOE M8E4McIgpQswrXAG2OmRltCo6445uqZBqnjNDQ64UL87PiTMppLtZ0dRathSpc3weqrz jwq5s6d6Flc4csiTXSzLMjGw26m0/Tm7jA+6ynu1QXGUclJFJX60hRuYTQMvNFc5y9Z8 rQey3mS22Sz0uNhuVsNTAkkFWXwiDxeFQN16CYkR+fLkVqvnRxFDPQ8A98LTi98F2a3f m7NA== X-Gm-Message-State: AFeK/H0BE2Vav2QU5/uhDzr9vK4Ym/Auo8U94K24njAlcqxjoKlEef5PvzuC2UWnnzPZyFFB X-Received: by 10.28.8.147 with SMTP id 141mr1220818wmi.43.1489732252465; Thu, 16 Mar 2017 23:30:52 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id q12sm1501502wmd.8.2017.03.16.23.30.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 23:30:51 -0700 (PDT) Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD To: "K. Macy" References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" From: Steven Hartland Message-ID: <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> Date: Fri, 17 Mar 2017 06:30:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 06:30:54 -0000 Ok I think I've identified the cause. If an alternative signal stack is applied to a non-main thread and that thread calls execve then the signal stack is not cleared. This results in all sorts of badness. Full details, including a small C reproduction case can be found here: https://github.com/golang/go/issues/15658#issuecomment-287276856 So looks like its kernel bug. If anyone has an ideas about that before I look tomorrow that would be appreciated. Regards Steve From owner-freebsd-hackers@freebsd.org Fri Mar 17 08:23:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D75BD0F7B1 for ; Fri, 17 Mar 2017 08:23:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 330E11AAC; Fri, 17 Mar 2017 08:23:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2H8NXlV012003 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 10:23:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2H8NXlV012003 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2H8NXv2012002; Fri, 17 Mar 2017 10:23:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2017 10:23:33 +0200 From: Konstantin Belousov To: Steven Hartland Cc: "K. Macy" , "freebsd-hackers@freebsd.org" Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD Message-ID: <20170317082333.GP16105@kib.kiev.ua> References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:23:39 -0000 On Fri, Mar 17, 2017 at 06:30:49AM +0000, Steven Hartland wrote: > Ok I think I've identified the cause. > > If an alternative signal stack is applied to a non-main thread and that > thread calls execve then the signal stack is not cleared. > > This results in all sorts of badness. > > Full details, including a small C reproduction case can be found here: > https://github.com/golang/go/issues/15658#issuecomment-287276856 > > So looks like its kernel bug. If anyone has an ideas about that before I > look tomorrow that would be appreciated. Yes, there is definitely a kernel bug, which should be fixed by the patch below. Still, what I saw when I looked at the issue, is not quite resembling potential consequences of the bug. Using wrong memory for signal stack would result either in much more significant memory corruption if the alt stack range is mapped and used for something unrelated, or in killed process on signal delivery, if the range is not mapped. While I saw a systematic 'off by 0x10' in some gc structures. Anyway, patch for the issue you identified: diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 29d5dd4b132..9bf3ba66f5c 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -976,7 +976,6 @@ execsigs(struct proc *p) * and are now ignored by default). */ PROC_LOCK_ASSERT(p, MA_OWNED); - td = FIRST_THREAD_IN_PROC(p); ps = p->p_sigacts; mtx_lock(&ps->ps_mtx); while (SIGNOTEMPTY(ps->ps_sigcatch)) { @@ -1007,6 +1006,8 @@ execsigs(struct proc *p) * Reset stack state to the user stack. * Clear set of signals caught on the signal stack. */ + td = curthread; + MPASS(td->td_proc == p); td->td_sigstk.ss_flags = SS_DISABLE; td->td_sigstk.ss_size = 0; td->td_sigstk.ss_sp = 0; From owner-freebsd-hackers@freebsd.org Fri Mar 17 11:27:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E405ED0E0BC for ; Fri, 17 Mar 2017 11:27:55 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7088E1183 for ; Fri, 17 Mar 2017 11:27:55 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x22d.google.com with SMTP id g10so49934785wrg.2 for ; Fri, 17 Mar 2017 04:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=cqHQcOrGywrnM1zYyp0h/H5nrcCGyziVuMFBUr/l70I=; b=vb8S8U6WqmB534b90xq0+l4B2GLRce/W3j0uDi4n8czJkA9HtB3btjYfWCZEcZ3LF+ NDR67JVEkIV6ALT0LrenWbdCXjnIxWGNkb/qOAnAYPVlHhQrfAFjsTI13vWIzIYQ1396 n6trToWJAq48wBEkOMrsR3g6WfEb4k3k7oCRb/pITVs2rwYRdYdN29IaWZu4CNXRR7wU +RGtH3UhpM6gn0G8OYUVXgZsvuRtNqnnG/lYWWvmYhY65ey2YAoTUqyP9ZiB0pyQPKzY pxKfwFnTanxxItnnuo+WYCvydvvFOi6cBOHfB8ZLXwxE9XDB34adlvTznESOSgMq/Xyz 5Rmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=cqHQcOrGywrnM1zYyp0h/H5nrcCGyziVuMFBUr/l70I=; b=uF9Y13mDhxqEyWUYxFVrZUUcrrYbQl55ov8Bs+YUvichFOCiMIa/hD3C8gHl5a+EB8 Y9B6o4Mr704ZTytKefzJtyCl/QmKhhlbp2zsIyE4XQTNAsKrqZmYvntd6xB/kHXAMsj+ whgNoWc3bCvWTdmtAlcMMV+o2hGuS1oRdyP5LsLg0YAdHFjy+P5wFQEQOw2fbZtgT18r FnK+m+PvRWjQ0SZrHpVkLNWpmziAFeNi/qe7faaj54TxwSMrOkqx/kG7hqlGetLfJMqa JYza4X6JAidJX1Pswy0SSv2brH8+DY2XmftVlkVQWZGaLS1wUeKS23OrzEWsvHu3VZO9 WL5A== X-Gm-Message-State: AFeK/H3JvZl8zMjTTzmGg7QMg4jXwyvWcfSOut4QQ1GEjlPiE/pn05kPjrHYfCAhbjyI2nTE X-Received: by 10.223.155.147 with SMTP id d19mr9936384wrc.99.1489750073814; Fri, 17 Mar 2017 04:27:53 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id 17sm9643125wru.16.2017.03.17.04.27.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 04:27:52 -0700 (PDT) Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD To: Konstantin Belousov References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> <20170317082333.GP16105@kib.kiev.ua> Cc: "K. Macy" , "freebsd-hackers@freebsd.org" From: Steven Hartland Message-ID: <180a601b-5481-bb41-f7fc-67976aabe451@multiplay.co.uk> Date: Fri, 17 Mar 2017 11:27:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170317082333.GP16105@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 11:27:56 -0000 On 17/03/2017 08:23, Konstantin Belousov wrote: > On Fri, Mar 17, 2017 at 06:30:49AM +0000, Steven Hartland wrote: >> Ok I think I've identified the cause. >> >> If an alternative signal stack is applied to a non-main thread and that >> thread calls execve then the signal stack is not cleared. >> >> This results in all sorts of badness. >> >> Full details, including a small C reproduction case can be found here: >> https://github.com/golang/go/issues/15658#issuecomment-287276856 >> >> So looks like its kernel bug. If anyone has an ideas about that before I >> look tomorrow that would be appreciated. > Yes, there is definitely a kernel bug, which should be fixed by the patch > below. > > Still, what I saw when I looked at the issue, is not quite resembling > potential consequences of the bug. Using wrong memory for signal stack > would result either in much more significant memory corruption if the > alt stack range is mapped and used for something unrelated, or in killed > process on signal delivery, if the range is not mapped. While I saw a > systematic 'off by 0x10' in some gc structures. > > Anyway, patch for the issue you identified: > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > index 29d5dd4b132..9bf3ba66f5c 100644 > --- a/sys/kern/kern_sig.c > +++ b/sys/kern/kern_sig.c > @@ -976,7 +976,6 @@ execsigs(struct proc *p) > * and are now ignored by default). > */ > PROC_LOCK_ASSERT(p, MA_OWNED); > - td = FIRST_THREAD_IN_PROC(p); > ps = p->p_sigacts; > mtx_lock(&ps->ps_mtx); > while (SIGNOTEMPTY(ps->ps_sigcatch)) { > @@ -1007,6 +1006,8 @@ execsigs(struct proc *p) > * Reset stack state to the user stack. > * Clear set of signals caught on the signal stack. > */ > + td = curthread; > + MPASS(td->td_proc == p); > td->td_sigstk.ss_flags = SS_DISABLE; > td->td_sigstk.ss_size = 0; > td->td_sigstk.ss_sp = 0; Thanks Kostik, pretty obvious now looking at :) Testing here we've seen all sorts of corruption looking things, mainly around random signals from SIGILL to SIGSEGV but also random kernel messages including: pid 4603 (test): sigreturn copying xfpustate failed pid 5013 (test): sigreturn xfpusave_len = 0x44d9bb I'm currently running a test, but its looking good as the test case usually crashes in a matter of seconds. Would you mind if I committed it? I'm guessing given its nature this is something we'd want MFC'ed and Errata's issued for all supported versions? Regards Steve From owner-freebsd-hackers@freebsd.org Fri Mar 17 12:44:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE7B3D104EC for ; Fri, 17 Mar 2017 12:44:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CFE3151D; Fri, 17 Mar 2017 12:44:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2HCibq1069168 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 14:44:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2HCibq1069168 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2HCibLM069167; Fri, 17 Mar 2017 14:44:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2017 14:44:37 +0200 From: Konstantin Belousov To: Steven Hartland Cc: "K. Macy" , "freebsd-hackers@freebsd.org" Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD Message-ID: <20170317124437.GR16105@kib.kiev.ua> References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> <20170317082333.GP16105@kib.kiev.ua> <180a601b-5481-bb41-f7fc-67976aabe451@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <180a601b-5481-bb41-f7fc-67976aabe451@multiplay.co.uk> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 12:44:47 -0000 On Fri, Mar 17, 2017 at 11:27:52AM +0000, Steven Hartland wrote: > On 17/03/2017 08:23, Konstantin Belousov wrote: > > On Fri, Mar 17, 2017 at 06:30:49AM +0000, Steven Hartland wrote: > >> Ok I think I've identified the cause. > >> > >> If an alternative signal stack is applied to a non-main thread and that > >> thread calls execve then the signal stack is not cleared. > >> > >> This results in all sorts of badness. > >> > >> Full details, including a small C reproduction case can be found here: > >> https://github.com/golang/go/issues/15658#issuecomment-287276856 > >> > >> So looks like its kernel bug. If anyone has an ideas about that before I > >> look tomorrow that would be appreciated. > > Yes, there is definitely a kernel bug, which should be fixed by the patch > > below. > > > > Still, what I saw when I looked at the issue, is not quite resembling > > potential consequences of the bug. Using wrong memory for signal stack > > would result either in much more significant memory corruption if the > > alt stack range is mapped and used for something unrelated, or in killed > > process on signal delivery, if the range is not mapped. While I saw a > > systematic 'off by 0x10' in some gc structures. > > > > Anyway, patch for the issue you identified: > > > > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > > index 29d5dd4b132..9bf3ba66f5c 100644 > > --- a/sys/kern/kern_sig.c > > +++ b/sys/kern/kern_sig.c > > @@ -976,7 +976,6 @@ execsigs(struct proc *p) > > * and are now ignored by default). > > */ > > PROC_LOCK_ASSERT(p, MA_OWNED); > > - td = FIRST_THREAD_IN_PROC(p); > > ps = p->p_sigacts; > > mtx_lock(&ps->ps_mtx); > > while (SIGNOTEMPTY(ps->ps_sigcatch)) { > > @@ -1007,6 +1006,8 @@ execsigs(struct proc *p) > > * Reset stack state to the user stack. > > * Clear set of signals caught on the signal stack. > > */ > > + td = curthread; > > + MPASS(td->td_proc == p); > > td->td_sigstk.ss_flags = SS_DISABLE; > > td->td_sigstk.ss_size = 0; > > td->td_sigstk.ss_sp = 0; > Thanks Kostik, pretty obvious now looking at :) > > Testing here we've seen all sorts of corruption looking things, mainly > around random signals from SIGILL to SIGSEGV but also random kernel > messages including: > pid 4603 (test): sigreturn copying xfpustate failed > pid 5013 (test): sigreturn xfpusave_len = 0x44d9bb > > I'm currently running a test, but its looking good as the test case > usually crashes in a matter of seconds. > > Would you mind if I committed it? I am capable of committing the patches. > > I'm guessing given its nature this is something we'd want MFC'ed and > Errata's issued for all supported versions? MFC will be done for sure. I am not so sure about EN, this is a routine bugfix. For some reasons 10.3 errata might be indeed the only way to get this for 10.x users, but I do not see why bother re/so with 11.0. From owner-freebsd-hackers@freebsd.org Fri Mar 17 13:00:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9518D107DA for ; Fri, 17 Mar 2017 13:00:15 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AB881DE9 for ; Fri, 17 Mar 2017 13:00:15 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x22e.google.com with SMTP id g10so51496337wrg.2 for ; Fri, 17 Mar 2017 06:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=EbmH/lak4asDOoxRDo9XHY4UkVTFKojIAg4QNjj5lII=; b=wQX7gZ416YkU4ES5NOG1LOR1s7T3GO6ZQXENwVlHKwEBOj9D3p3RGhT7gOZC/kgTib o1M/Ux74KOlEjldGXy9OQ6XFAvwEnYlxZHwCMgKHaCtzCaERq+fIh+apVlAApsQ2wDBQ ej6ERrlXIJPq3sgPtNX7QjSmvOypcQlKkEGFJBvuwk9TO7G5UIynZNnK4iE5M6TJxojc 7VhpqhzAXGCKMAVZZF4ApITN1UA6dJWtth7Z6Pb1Cw0jXJDTYKNp9i4vnUsBrm9gqrZW /cT9R4xff4qB12wTDzrgmdxZMdoqZJq3RDs1MQUM/XrVVl2BwDaQ3tF2F0cKIjjx5JUy cO6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=EbmH/lak4asDOoxRDo9XHY4UkVTFKojIAg4QNjj5lII=; b=DPITciJXXfucTWD59Ll33Cl0RJiO5VxEsDFGBWcXqKr4BoUWksxwa0ssLERVdq7hSl e+TesyDy236VXciVB5TJJ5qtelINsO2BxiGd05/rmqDRFwnHCQ27KFzQIA+pEhL0mq1Z GSfLTvwL2Kq2jkxQktao0vteZzOCL5Ve92RaFya3eZNag/9r1B2yOx+aHahZbwScgrHF 9FGU9mAsDYu0n4eWUfu3mjZQzhbsuLQSLPKdVHJBCx9sKMIXP5CJVYSzXalSsHCDiBTR fKnApWur+BM8ByY0e8Xcuj/J/2saunevYww3Rf/2mgSXX+8i7mZXdhw1fqnBrA8eDxGd dQhg== X-Gm-Message-State: AFeK/H3IH//A5jlp7IhxfYmvd/ig2DeiOlm6IS6skxG32D4c5ceeKpg+3QCTeIANCA3Jw3nM X-Received: by 10.223.136.33 with SMTP id d30mr13896769wrd.117.1489755613948; Fri, 17 Mar 2017 06:00:13 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id o2sm2574826wmb.28.2017.03.17.06.00.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 06:00:13 -0700 (PDT) Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD To: Konstantin Belousov References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <18b40a69-4460-faf2-c0ce-7491eca92782@multiplay.co.uk> <20170317082333.GP16105@kib.kiev.ua> <180a601b-5481-bb41-f7fc-67976aabe451@multiplay.co.uk> <20170317124437.GR16105@kib.kiev.ua> Cc: "K. Macy" , "freebsd-hackers@freebsd.org" From: Steven Hartland Message-ID: Date: Fri, 17 Mar 2017 13:00:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170317124437.GR16105@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:00:15 -0000 On 17/03/2017 12:44, Konstantin Belousov wrote: > On Fri, Mar 17, 2017 at 11:27:52AM +0000, Steven Hartland wrote: >> On 17/03/2017 08:23, Konstantin Belousov wrote: >>> On Fri, Mar 17, 2017 at 06:30:49AM +0000, Steven Hartland wrote: >>>> Ok I think I've identified the cause. >>>> >>>> If an alternative signal stack is applied to a non-main thread and that >>>> thread calls execve then the signal stack is not cleared. >>>> >>>> This results in all sorts of badness. >>>> >>>> Full details, including a small C reproduction case can be found here: >>>> https://github.com/golang/go/issues/15658#issuecomment-287276856 >>>> >>>> So looks like its kernel bug. If anyone has an ideas about that before I >>>> look tomorrow that would be appreciated. >>> Yes, there is definitely a kernel bug, which should be fixed by the patch >>> below. >>> >>> Still, what I saw when I looked at the issue, is not quite resembling >>> potential consequences of the bug. Using wrong memory for signal stack >>> would result either in much more significant memory corruption if the >>> alt stack range is mapped and used for something unrelated, or in killed >>> process on signal delivery, if the range is not mapped. While I saw a >>> systematic 'off by 0x10' in some gc structures. >>> >>> Anyway, patch for the issue you identified: >>> >>> diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c >>> index 29d5dd4b132..9bf3ba66f5c 100644 >>> --- a/sys/kern/kern_sig.c >>> +++ b/sys/kern/kern_sig.c >>> @@ -976,7 +976,6 @@ execsigs(struct proc *p) >>> * and are now ignored by default). >>> */ >>> PROC_LOCK_ASSERT(p, MA_OWNED); >>> - td = FIRST_THREAD_IN_PROC(p); >>> ps = p->p_sigacts; >>> mtx_lock(&ps->ps_mtx); >>> while (SIGNOTEMPTY(ps->ps_sigcatch)) { >>> @@ -1007,6 +1006,8 @@ execsigs(struct proc *p) >>> * Reset stack state to the user stack. >>> * Clear set of signals caught on the signal stack. >>> */ >>> + td = curthread; >>> + MPASS(td->td_proc == p); >>> td->td_sigstk.ss_flags = SS_DISABLE; >>> td->td_sigstk.ss_size = 0; >>> td->td_sigstk.ss_sp = 0; >> Thanks Kostik, pretty obvious now looking at :) >> >> Testing here we've seen all sorts of corruption looking things, mainly >> around random signals from SIGILL to SIGSEGV but also random kernel >> messages including: >> pid 4603 (test): sigreturn copying xfpustate failed >> pid 5013 (test): sigreturn xfpusave_len = 0x44d9bb >> >> I'm currently running a test, but its looking good as the test case >> usually crashes in a matter of seconds. >> >> Would you mind if I committed it? > I am capable of committing the patches. No problem, wouldn't ever suggest otherwise, just didn't want to add to your workload ;-) > >> I'm guessing given its nature this is something we'd want MFC'ed and >> Errata's issued for all supported versions? > MFC will be done for sure. I am not so sure about EN, this is a routine > bugfix. For some reasons 10.3 errata might be indeed the only way to get > this for 10.x users, but I do not see why bother re/so with 11.0. My argument for doing an EN would for 11.0 as well as 10.3 be two fold: 1. It exposes other processes memory so could be considered as security issue? 2. Given its causing quite a bit of pain for golang users (random crashes), which is getting used more and more now, it would be good to get a fix out sooner rather than later and 11.1 is still over 4months off. Regards Steve From owner-freebsd-hackers@freebsd.org Sat Mar 18 19:05:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB566D12CC2 for ; Sat, 18 Mar 2017 19:05:42 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from mail.anongoth.pl (anongoth.pl [88.156.79.165]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anongoth.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D09901E62; Sat, 18 Mar 2017 19:05:41 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from anongoth.pl (89-73-168-84.dynamic.chello.pl [89.73.168.84]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id 6E8822CF6F; Sat, 18 Mar 2017 20:05:29 +0100 (CET) Authentication-Results: mail.anongoth.pl; dmarc=none header.from=anongoth.pl DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=anongoth.pl; s=ANONGOTH; t=1489863930; bh=pLmNBXpiCLH6o/hPgVRBMjqxzZvc3ty5l6yzdOB2g+Q=; h=Date:From:To:Subject:References:In-Reply-To; b=nZ5smg1aMbDdvpPVcfkkmZ70uE9pQ8OPC6uFoRzWvgFaXVeeQD1BejNmRhR0jqTvo MQXEUuUZE1qzCdmEL/84vHHeTAsgmWlnwaNocUp7LL4Eyrwkx8dHQPVU9ZZMy2ZgeH +5+X7sOnj1LXxQEyTtR+QlmIdr2Utt+dIdGzS2b2CIxQ/V50d+JHT3tNlvmmP3UgYV VaCtAcihKNuJnTzlubgZW0/Zd8Z6oimXOJC7jaBw28O7p8nd3tScWauRVIJ1+ml6r/ yrKMO3NxnDgmLcRJUWFu3fHvTg8wYmApDy9dOlUkOc3MNMvdbWXw9nI2e45QEt3hDu ZZstd7Ad+lk4Q== Date: Sat, 18 Mar 2017 20:05:27 +0100 From: Piotr Kubaj To: freebsd-hackers@freebsd.org, jhb@freebsd.org Subject: Re: Freeze during booting of ASUS F2A85-M motherboard with Coreboot Message-ID: <20170318190527.GA70683@ThinkPad-X200.local> References: <20170225224425.GA93825@DESKTOP1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mBcWXAAsoZ3r5qnj" Content-Disposition: inline In-Reply-To: <20170225224425.GA93825@DESKTOP1> User-Agent: Mutt/1.6.2 (2016-07-01) X-Mailman-Approved-At: Sat, 18 Mar 2017 19:32:05 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 19:05:42 -0000 --mBcWXAAsoZ3r5qnj Content-Type: multipart/mixed; boundary="9HzmNrjLmDa9xpHW" Content-Disposition: inline --9HzmNrjLmDa9xpHW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm not sure whether anyone can help me, but I got new information. When setting "Safe Mode" in bootloader, I get: panic: Couldn't find an APIC vector for IRQ 9 The whole boot log is attached. On 17-02-25 23:44:25, Piotr Kubaj wrote: > > Are you able to capture a full verbose dmesg via a serial console or th= e like > > that would really help as it may be that we are seeing a resource confl= ict > > with the way Coreboot sets up the PCI bridge windows and then disabling > > an I/O window that happens to break something. A verbose dmesg from the > > stock UEFI would also be useful, though it is less important. >=20 > Sorry for the lag, but I didn't have the null cable, the I moved to anoth= er flat and then I got married :) >=20 > I'm attaching the full verbose dmesg log from Coreboot git compiled today= and FreeBSD 11.0-RELEASE. >=20 >=20 > --=20 > __________________________=20 > / Come home America. \ > | | > \ -- George McGovern, 1972 / > --------------------------=20 > \ ^__^ > \ (oo)\_______ > (__)\ )\/\ > ||----w | > || || > Table 'FACP' at 0xbffb0b10 > Table 'SSDT' at 0xbffb0c10 > Table 'TCPA' at 0xbffb0ca0 > Table 'APIC' at 0xbffb0ce0 > APIC: Found table at 0xbffb0ce0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 16 ACPI ID 0: enabled > SMP: Added CPU 16 (AP) > MADT: Found CPU APIC ID 17 ACPI ID 1: enabled > SMP: Added CPU 17 (AP) > MADT: Found CPU APIC ID 18 ACPI ID 2: enabled > SMP: Added CPU 18 (AP) > MADT: Found CPU APIC ID 19 ACPI ID 3: enabled > SMP: Added CPU 19 (AP) > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-RELEASE-p8 #2 r314126: Thu Feb 23 15:26:37 CET 2017 > root@DESKTOP1:/usr/obj/usr/src/sys/DESKTOP1 amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLV= M 3.8.0) > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8199f000. > Calibrating TSC clock ... TSC clock: 3393898478 Hz > CPU: AMD Athlon(tm) X4 750K Quad Core Processor (3393.90-MHz K8-clas= s CPU) > Origin=3D"AuthenticAMD" Id=3D0x610f01 Family=3D0x15 Model=3D0x10 St= epping=3D1 > Features=3D0x178bfbff > Features2=3D0x3e98320b > AMD Features=3D0x2e500800 > AMD Features2=3D0x1ebbfff > Structured Extended Features=3D0x8 > SVM: Features=3D0x1cff,PauseFilterThreshold> > Revision=3D1, ASIDs=3D65536 > TSC: P-state invariant, performance statistics > L1 2MB data TLB: 64 entries, fully associative > L1 2MB instruction TLB: 24 entries, fully associative > L1 4KB data TLB: 64 entries, fully associative > L1 4KB instruction TLB: 48 entries, fully associative > L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associ= ative > L2 2MB data TLB: 1024 entries, 8-way associative > L2 2MB instruction TLB: 1024 entries, 8-way associative > L2 4KB data TLB: 1024 entries, 8-way associative > L2 4KB instruction TLB: 1024 entries, 8-way associative > L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associa= tive > real memory =3D 9110028288 (8688 MB) > Physical memory chunk(s): > 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x00000000019c4000 - 0x00000000bff9bfff, 3193798656 bytes (779736 pages) > 0x0000000100000000 - 0x0000000211288fff, 4582838272 bytes (1118857 pages) > avail memory =3D 7727480832 (7369 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 17 as a target > INTR: Adding local APIC 18 as a target > INTR: Adding local APIC 19 as a target > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 16 > cpu1 (AP): APIC ID: 17 > cpu2 (AP): APIC ID: 18 > cpu3 (AP): APIC ID: 19 > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > APIC: CPU 2 has ACPI ID 2 > APIC: CPU 3 has ACPI ID 3 > XEN: CPU 0 has VCPU ID 0 > XEN: CPU 1 has VCPU ID 1 > XEN: CPU 2 has VCPU ID 2 > XEN: CPU 3 has VCPU ID 3 > x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 > x86bios: SSEG 0x098000-0x098fff at 0xfffffe01cfdff000 > x86bios: EBDA 0x09f000-0x09ffff at 0xfffff8000009f000 > x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > ACPI: RSDP 0x00000000000F70F0 000024 (v02 CORE ) > ACPI: XSDT 0x00000000BFFAF0E0 00006C (v01 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: FACP 0x00000000BFFB0B10 0000F4 (v04 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: DSDT 0x00000000BFFAF280 00188F (v02 ASUS COREBOOT 00010001 INTL 2= 0160831) > ACPI: FACS 0x00000000BFFAF240 000040 > ACPI: SSDT 0x00000000BFFB0C10 00008A (v02 CORE COREBOOT 0000002A CORE 0= 000002A) > ACPI: TCPA 0x00000000BFFB0CA0 000032 (v02 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: APIC 0x00000000BFFB0CE0 000072 (v01 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: HPET 0x00000000BFFB0D60 000038 (v01 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: HEST 0x00000000BFFB0DA0 0001D0 (v01 CORE COREBOOT 00000000 CORE 0= 0000000) > ACPI: IVRS 0x00000000BFFB0F70 000070 (v02 AMD AMDIOMMU 00000001 AMD 0= 0000000) > ACPI: SSDT 0x00000000BFFB0FE0 00051F (v02 AMD ALIB 00000001 MSFT 0= 4000000) > ACPI: SSDT 0x00000000BFFB1500 000D40 (v01 AMD POWERNOW 00000001 AMD 0= 0000001) > MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic: Routing NMI -> LINT1 > lapic: LINT1 trigger: edge > lapic: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x10000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000300ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [= 1024] > feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_= rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 > wlan: <802.11 Link Layer> > Hardware, Intel Secure Key RNG: RDRAND is not present > Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present > null: > nfslock: pseudo-device > Falling back to random adaptor > random: initialized > VESA: INT 0x10 vector 0xc000:0x1a56 > VESA: information block > 0000 56 45 53 41 00 03 00 01 00 99 01 00 00 00 22 00 > 0010 00 99 e0 00 06 80 07 01 00 99 1a 01 00 99 31 01 > 0020 00 99 00 01 01 01 02 01 03 01 04 01 05 01 06 01 > 0030 07 01 0e 01 0f 01 11 01 12 01 14 01 15 01 17 01 > 0040 18 01 1a 01 1b 01 30 01 31 01 32 01 33 01 34 01 > 0050 35 01 36 01 3d 01 3e 01 4b 01 4c 01 4d 01 60 01 > 0060 61 01 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 > 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0100 4e 56 49 44 49 41 00 4e 56 49 44 49 41 20 43 6f > 0110 72 70 6f 72 61 74 69 6f 6e 00 47 4b 31 30 36 20 > 0120 42 6f 61 72 64 20 2d 20 32 30 31 30 30 30 31 35 > 0130 00 43 68 69 70 20 52 65 76 20 20 20 00 00 00 00 > 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > VESA: 32 mode(s) found > VESA: v3.0, 14336k memory, flags:0x1, mode table:0xfffffe020c2cb022 (9900= 0022) > VESA: NVIDIA > VESA: NVIDIA Corporation GK106 Board - 20100015 Chip Rev =20 > io: > VMBUS: load > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > hpt27xx: RocketRAID 27xx controller driver v1.2.7 > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > hptnr: R750/DC7280 controller driver v1.1.4 > acpi0: on motherboard > ACPI: All ACPI Tables successfully acquired > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 > ACPI: Executed 2 blocks of module-level executable AML code > acpi0: Power Button (fixed) > cpu0: Processor \134_PR_.P000 (ACPI ID 0) -> APIC ID 0 > cpu0: on acpi0 > cpu1: Processor \134_PR_.P001 (ACPI ID 1) -> APIC ID 1 > cpu1: on acpi0 > cpu2: Processor \134_PR_.P002 (ACPI ID 2) -> APIC ID 2 > cpu2: on acpi0 > cpu3: Processor \134_PR_.P003 (ACPI ID 3) -> APIC ID 3 > cpu3: on acpi0 > ACPI: Processor \134_PR_.P004 (ACPI ID 4) ignored > ACPI: Processor \134_PR_.P005 (ACPI ID 5) ignored > ACPI: Processor \134_PR_.P006 (ACPI ID 6) ignored > ACPI: Processor \134_PR_.P007 (ACPI ID 7) ignored > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustme= nt 0.500000000s) > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 16 vector 49 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 16 vector 50 > Event timer "i8254" frequency 1193182 Hz quality 100 > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x818-0x81b on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > hpet0: vendor 0x1022, rev 0x10, 14318180Hz, 3 timers, legacy route > hpet0: t0: irqs 0x00c00000 (0), periodic > hpet0: t1: irqs 0x00c00000 (0), periodic > hpet0: t2: irqs 0x00c00000 (0), periodic > Timecounter "HPET" frequency 14318180 Hz quality 950 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 9 > Validation 0 255 N 0 9 > After Disable 0 255 N 0 9 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 10 11 12 15 > Validation 0 255 N 0 3 4 5 7 10 11 12 15 > After Disable 0 255 N 0 3 4 5 7 10 11 12 15 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: decoding 5 range 0-0xff > pcib0: decoding 4 range 0-0xcf7 > pcib0: decoding 4 range 0x3b0-0x3df > pcib0: decoding 4 range 0xd00-0xffff > pci0: on pcib0 > pci0: domain=3D0, physical bus=3D0 > found-> vendor=3D0x1022, dev=3D0x1410, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D0, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0006, statreg=3D0x0220, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1419, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D0, func=3D2 > class=3D08-06-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0004, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > MSI supports 1 message, 64 bit > found-> vendor=3D0x1022, dev=3D0x1414, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D4, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > secbus=3D1, subbus=3D1 > found-> vendor=3D0x1022, dev=3D0x7812, revid=3D0x03 > domain=3D0, bus=3D0, slot=3D16, func=3D0 > class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 3 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > MSI-X supports 8 messages in map 0x10 > map[10]: type Memory, range 64, base 0xf3484000, size 13, enabled > found-> vendor=3D0x1022, dev=3D0x7812, revid=3D0x03 > domain=3D0, bus=3D0, slot=3D16, func=3D1 > class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D255 > powerspec 3 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > MSI-X supports 8 messages in map 0x10 > map[10]: type Memory, range 64, base 0xf3486000, size 13, enabled > found-> vendor=3D0x1022, dev=3D0x7801, revid=3D0x40 > domain=3D0, bus=3D0, slot=3D17, func=3D0 > class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > map[10]: type I/O Port, range 32, base 0x4010, size 3, enabled > pcib0: allocated type 4 (0x4010-0x4017) for rid 10 of pci0:0:17:0 > map[14]: type I/O Port, range 32, base 0x4020, size 2, enabled > pcib0: allocated type 4 (0x4020-0x4023) for rid 14 of pci0:0:17:0 > map[18]: type I/O Port, range 32, base 0x4018, size 3, enabled > pcib0: allocated type 4 (0x4018-0x401f) for rid 18 of pci0:0:17:0 > map[1c]: type I/O Port, range 32, base 0x4024, size 2, enabled > pcib0: allocated type 4 (0x4024-0x4027) for rid 1c of pci0:0:17:0 > map[20]: type I/O Port, range 32, base 0x4000, size 4, enabled > pcib0: allocated type 4 (0x4000-0x400f) for rid 20 of pci0:0:17:0 > map[24]: type Memory, range 32, base 0xf348b000, size 11, enabled > found-> vendor=3D0x1022, dev=3D0x7807, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D18, func=3D0 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0006, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > map[10]: type Memory, range 32, base 0xf3488000, size 12, enabled > found-> vendor=3D0x1022, dev=3D0x7808, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D18, func=3D2 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x02b0, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xf348c000, size 8, enabled > found-> vendor=3D0x1022, dev=3D0x7807, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D19, func=3D0 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0006, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > map[10]: type Memory, range 32, base 0xf3489000, size 12, enabled > found-> vendor=3D0x1022, dev=3D0x7808, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D19, func=3D2 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x02b0, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xf348d000, size 8, enabled > found-> vendor=3D0x1022, dev=3D0x780b, revid=3D0x14 > domain=3D0, bus=3D0, slot=3D20, func=3D0 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0403, statreg=3D0x0220, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x780d, revid=3D0x01 > domain=3D0, bus=3D0, slot=3D20, func=3D2 > class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0002, statreg=3D0x0410, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xf3480000, size 14, enabled > found-> vendor=3D0x1022, dev=3D0x780e, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D20, func=3D3 > class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x000f, statreg=3D0x0220, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x780f, revid=3D0x40 > domain=3D0, bus=3D0, slot=3D20, func=3D4 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D0 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > secbus=3D2, subbus=3D2 > found-> vendor=3D0x1022, dev=3D0x7809, revid=3D0x11 > domain=3D0, bus=3D0, slot=3D20, func=3D5 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D255 > map[10]: type Memory, range 32, base 0xf348a000, size 12, enabled > found-> vendor=3D0x1022, dev=3D0x43a0, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D21, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > secbus=3D3, subbus=3D3 > found-> vendor=3D0x1022, dev=3D0x43a1, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D21, func=3D1 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > secbus=3D4, subbus=3D4 > found-> vendor=3D0x1022, dev=3D0x1400, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1401, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D1 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1402, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D2 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1403, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D3 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1404, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D4 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1405, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D5 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > pci0: at device 0.2 (no driver attached) > pcib1: at device 4.0 on pci0 > pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: memory decode 0xf2000000-0xf30fffff > pcib1: prefetched decode 0xe8000000-0xf1ffffff > pcib1: special decode VGA > pci1: on pcib1 > pcib1: allocated bus range (1-1) for rid 0 of pci1 > pci1: domain=3D0, physical bus=3D1 > found-> vendor=3D0x10de, dev=3D0x11c6, revid=3D0xa1 > domain=3D0, bus=3D1, slot=3D0, func=3D0 > class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0003, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xf2000000, size 24, enabled > pcib1: allocated memory range (0xf2000000-0xf2ffffff) for rid 10 of pci0:= 1:0:0 > map[14]: type Prefetchable Memory, range 64, base 0xe8000000, size 27, e= nabled > pcib1: allocated prefetch range (0xe8000000-0xefffffff) for rid 14 of pci= 0:1:0:0 > map[1c]: type Prefetchable Memory, range 64, base 0xf0000000, size 25, e= nabled > pcib1: allocated prefetch range (0xf0000000-0xf1ffffff) for rid 1c of pci= 0:1:0:0 > map[24]: type I/O Port, range 32, base 0x1000, size 7, enabled > pcib1: failed to allocate initial I/O port window (0x1000-0x107f,0x80) > pci1: pci0:1:0:0 bar 0x24 failed to allocate > found-> vendor=3D0x10de, dev=3D0x0e0b, revid=3D0xa1 > domain=3D0, bus=3D1, slot=3D0, func=3D1 > class=3D04-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0002, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D255 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xf3080000, size 14, enabled > pcib1: allocated memory range (0xf3080000-0xf3083fff) for rid 10 of pci0:= 1:0:1 > vgapci0: mem 0xf2000000-0xf2ffffff,0xe8000000-0x= efffffff,0xf0000000-0xf1ffffff at device 0.0 on pci1 > vgapci0: Boot video device > hdac0: mem 0xf3080000-0xf3083fff at devi= ce 0.1 on pci1 > hdac0: PCI card vendor: 0x1458, device: 0x3557 > hdac0: HDA Driver Revision: 20120126_0002 > hdac0: Config options: on=3D0x00000000 off=3D0x00000000 > hdac0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 16 vector 51 > hdac0: using IRQ 256 for MSI > hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 4, 64bit, CORB 256, RIRB 256 > xhci0: mem 0xf3484000-0xf3485fff at d= evice 16.0 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > xhci0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 257 to local APIC 16 vector 52 > xhci0: using IRQ 257 for MSI > xhci0: MSI enabled > xhci0: Controller reset timeout. > xhci0: XHCI halt/start/probe failed err=3D18 > device_attach: xhci0 attach returned 6 > xhci0: mem 0xf3486000-0xf3487fff at d= evice 16.1 on pci0 > xhci0: 32 bytes context size, 64-bit DMA > xhci0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 257 to local APIC 16 vector 52 > xhci0: using IRQ 257 for MSI > xhci0: MSI enabled > xhci0: Controller reset timeout. > xhci0: XHCI halt/start/probe failed err=3D18 > device_attach: xhci0 attach returned 6 > ahci0: port 0x4010-0x4017,0x4020-0x40= 23,0x4018-0x401f,0x4024-0x4027,0x4000-0x400f mem 0xf348b000-0xf348b7ff at d= evice 17.0 on pci0 > pcib0: matched entry for 0.17.INTA > pcib0: slot 17 INTA hardwired to IRQ 19 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 16 vector 52 > ahci0: AHCI v1.30 with 8 6Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF MPS AL CLO 6Gbps PMD 32cmd 8ports > ahci0: Caps2: > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > ahcich2: at channel 2 on ahci0 > ahcich2: Caps: > ahcich3: at channel 3 on ahci0 > ahcich3: Caps: > ahcich4: at channel 4 on ahci0 > ahcich4: Caps: > ahcich5: at channel 5 on ahci0 > ahcich5: Caps: > ahcich6: at channel 6 on ahci0 > ahcich6: Caps: > ahcich7: at channel 7 on ahci0 > ahcich7: Caps: > ohci0: mem 0xf3488000-0xf3488fff at devic= e 18.0 on pci0 > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 18 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 16 vector 53 > usbus0 on ohci0 > ohci0: usbpf: Attached > ehci0: mem 0xf348c000-0xf348c0ff at d= evice 18.2 on pci0 > pcib0: matched entry for 0.18.INTB > pcib0: slot 18 INTB hardwired to IRQ 17 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 16 vector 54 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ehci0: usbpf: Attached > ohci1: mem 0xf3489000-0xf3489fff at devic= e 19.0 on pci0 > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 18 > usbus2 on ohci1 > ohci1: usbpf: Attached > ehci1: mem 0xf348d000-0xf348d0ff at d= evice 19.2 on pci0 > pcib0: matched entry for 0.19.INTB > pcib0: slot 19 INTB hardwired to IRQ 17 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > ehci1: usbpf: Attached > pci0: at device 20.0 (no driver attached) > hdac1: mem 0xf3480000-0xf3483fff at= device 20.2 on pci0 > hdac1: PCI card vendor: 0x1022, device: 0x1410 > hdac1: HDA Driver Revision: 20120126_0002 > hdac1: Config options: on=3D0x00000000 off=3D0x00000000 > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 16 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 16 vector 55 > hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib2: at device 20.4 on pci0 > pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib2 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode 0x2000-0x2fff > pcib2: memory decode 0xf3100000-0xf31fffff > pcib2: special decode subtractive > pci2: on pcib2 > pcib2: allocated bus range (2-2) for rid 0 of pci2 > pci2: domain=3D0, physical bus=3D2 > found-> vendor=3D0x1186, dev=3D0x1300, revid=3D0x10 > domain=3D0, bus=3D2, slot=3D5, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0003, statreg=3D0x0290, cachelnsz=3D0 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x20 (8000 ns), maxlat=3D0x40 (16000= ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type I/O Port, range 32, base 0x2000, size 8, enabled > pcib2: allocated I/O port range (0x2000-0x20ff) for rid 10 of pci0:2:5:0 > map[14]: type Memory, range 32, base 0xf3100000, size 8, enabled > pcib2: allocated memory range (0xf3100000-0xf31000ff) for rid 14 of pci0:= 2:5:0 > rl0: port 0x2000-0x20ff mem 0xf3100000-0= xf31000ff at device 5.0 on pci2 > pcib2: matched entry for 2.5.INTA > pcib2: slot 5 INTA hardwired to IRQ 20 > miibus0: on rl0 > rlphy0: PHY 0 on miibus0 > rlphy0: OUI 0x000000, model 0x0000, rev. 0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: bpf attached > rl0: Ethernet address: 00:24:01:2f:a5:8f > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 16 vector 56 > ohci2: mem 0xf348a000-0xf348afff at devic= e 20.5 on pci0 > pcib0: matched entry for 0.20.INTC > pcib0: slot 20 INTC hardwired to IRQ 18 > usbus4 on ohci2 > ohci2: usbpf: Attached > pcib3: at device 21.0 on pci0 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: memory decode 0xf3200000-0xf32fffff > pci3: on pcib3 > pcib3: allocated bus range (3-3) for rid 0 of pci3 > pci3: domain=3D0, physical bus=3D3 > found-> vendor=3D0x168c, dev=3D0x0030, revid=3D0x01 > domain=3D0, bus=3D3, slot=3D0, func=3D0 > class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0002, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 3 supports D0 D1 D3 current D0 > MSI supports 4 messages, 64 bit, vector masks > map[10]: type Memory, range 64, base 0xf3200000, size 17, enabled > pcib3: allocated memory range (0xf3200000-0xf321ffff) for rid 10 of pci0:= 3:0:0 > ath0: mem 0xf3200000-0xf321ffff at device 0.0 on pci3 > pcib3: matched entry for 3.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 16 > ar9300_set_stub_functions: setting stub functions > ar9300_set_stub_functions: setting stub functions > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: RX status length: 48 > ath0: RX buffer size: 4096 > ath0: TX descriptor length: 128 > ath0: TX status length: 36 > ath0: TX buffers per descriptor: 4 > ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 > ath0: ath_edma_setup_rxfifo: type=3D0, FIFO depth =3D 16 entries > ath0: ath_edma_setup_rxfifo: type=3D1, FIFO depth =3D 128 entries > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24M= bps 36Mbps 48Mbps 54Mbps > ath0: 3T3R > ath0: 11na MCS 20MHz > ath0: MCS 0-7: 6.5Mbps - 65Mbps > ath0: MCS 8-15: 13Mbps - 130Mbps > ath0: MCS 16-23: 19.5Mbps - 195Mbps > ath0: 11na MCS 20MHz SGI > ath0: MCS 0-7: 7Mbps - 72Mbps > ath0: MCS 8-15: 14.5Mbps - 144.5Mbps > ath0: MCS 16-23: 21.5Mbps - 216.5Mbps > ath0: 11na MCS 40MHz: > ath0: MCS 0-7: 13.5Mbps - 135Mbps > ath0: MCS 8-15: 27Mbps - 270Mbps > ath0: MCS 16-23: 40.5Mbps - 405Mbps > ath0: 11na MCS 40MHz SGI: > ath0: MCS 0-7: 15Mbps - 150Mbps > ath0: MCS 8-15: 30Mbps - 300Mbps > ath0: MCS 16-23: 45Mbps - 450Mbps > ath0: 11ng MCS 20MHz > ath0: MCS 0-7: 6.5Mbps - 65Mbps > ath0: MCS 8-15: 13Mbps - 130Mbps > ath0: MCS 16-23: 19.5Mbps - 195Mbps > ath0: 11ng MCS 20MHz SGI > ath0: MCS 0-7: 7Mbps - 72Mbps > ath0: MCS 8-15: 14.5Mbps - 144.5Mbps > ath0: MCS 16-23: 21.5Mbps - 216.5Mbps > ath0: 11ng MCS 40MHz: > ath0: MCS 0-7: 13.5Mbps - 135Mbps > ath0: MCS 8-15: 27Mbps - 270Mbps > ath0: MCS 16-23: 40.5Mbps - 405Mbps > ath0: 11ng MCS 40MHz SGI: > ath0: MCS 0-7: 15Mbps - 150Mbps > ath0: MCS 8-15: 30Mbps - 300Mbps > ath0: MCS 16-23: 45Mbps - 450Mbps > ath0: AR9380 mac 448.3 RF5110 phy 64.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > ath0: Use hw queue 1 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 2 for WME_AC_VI traffic > ath0: Use hw queue 3 for WME_AC_VO traffic > ath0: Use hw queue 8 for CAB traffic > ath0: Use hw queue 9 for beacons > ath0: using multicast key search > pcib4: at device 21.1 on pci0 > pcib0: allocated type 4 (0x3000-0x3fff) for rid 1c of pcib4 > pcib4: domain 0 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0x3000-0x3fff > pcib4: prefetched decode 0xf3300000-0xf33fffff > pci4: on pcib4 > pcib4: allocated bus range (4-4) for rid 0 of pci4 > pci4: domain=3D0, physical bus=3D4 > found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x09 > domain=3D0, bus=3D4, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0003, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 4 messages in map 0x20 > map[10]: type I/O Port, range 32, base 0x3000, size 8, enabled > pcib4: allocated I/O port range (0x3000-0x30ff) for rid 10 of pci0:4:0:0 > map[18]: type Prefetchable Memory, range 64, base 0xf3304000, size 12, e= nabled > pcib4: allocated prefetch range (0xf3304000-0xf3304fff) for rid 18 of pci= 0:4:0:0 > map[20]: type Prefetchable Memory, range 64, base 0xf3300000, size 14, e= nabled > pcib4: allocated prefetch range (0xf3300000-0xf3303fff) for rid 20 of pci= 0:4:0:0 > re0: port 0x3= 000-0x30ff mem 0xf3304000-0xf3304fff,0xf3300000-0xf3303fff at device 0.0 on= pci4 > re0: MSI count : 1 > re0: MSI-X count : 4 > re0: attempting to allocate 1 MSI-X vectors (4 supported) > msi: routing MSI-X IRQ 257 to local APIC 16 vector 57 > re0: using IRQ 257 for MSI-X > re0: Using 1 MSI-X message > re0: Chip rev. 0x48000000 > re0: MAC rev. 0x00000000 > miibus1: on re0 > rgephy0: PHY 1 on miibus1 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100bas= eTX-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: bpf attached > re0: Ethernet address: 08:60:6e:da:ca:78 > ACPI: Enabled 5 GPEs in block 00 to 1F > acpi0: wakeup code va 0xfffffe0218184000 pa 0x90000 > ex_isa_identify() > ahc_isa_identify 0: ioport 0xc00 alloc failed > ahc_isa_identify 1: ioport 0x1c00 alloc failed > ahc_isa_identify 2: ioport 0x2c00 alloc failed > ahc_isa_identify 3: ioport 0x3c00 alloc failed > ahc_isa_identify 4: ioport 0x4c00 alloc failed > ahc_isa_identify 5: ioport 0x5c00 alloc failed > ahc_isa_identify 6: ioport 0x6c00 alloc failed > ahc_isa_identify 7: ioport 0x7c00 alloc failed > ahc_isa_identify 8: ioport 0x8c00 alloc failed > ahc_isa_identify 9: ioport 0x9c00 alloc failed > ahc_isa_identify 10: ioport 0xac00 alloc failed > ahc_isa_identify 11: ioport 0xbc00 alloc failed > ahc_isa_identify 12: ioport 0xcc00 alloc failed > ahc_isa_identify 13: ioport 0xdc00 alloc failed > ahc_isa_identify 14: ioport 0xec00 alloc failed > isa_probe_children: disabling PnP devices > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xee000-0xeffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x100> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > atkbdc0: at port 0x60,0x64 on isa0 > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 16 vector 58 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > ppc0: cannot reserve I/O port range > ppc0 failed to probe at irq 7 on isa0 > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > uart0: console (9600,n,8,1) > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 16 vector 59 > uart0: fast interrupt > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > uart1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > wbwd0 failed to probe on isa0 > isa_probe_children: probing PnP devices > hwpstate0: on cpu0 > Device configuration finished. > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > procfs registered > lapic: Divisor 2, Frequency 49910251 Hz > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 > lo0: bpf attached > hpt27xx: no controller detected. > hptrr: no controller detected. > hptnr: no controller detected. > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > hdaa0: Subsystem ID: 0x14583557 > hdaa0: NumGPIO=3D0 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D0 > hdaa0: Original pins configuration: > hdaa0: nid 0x as seq device conn jack loc color m= isc > hdaa0: 4 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0 > hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: Patched pins configuration: > hdaa0: nid 0x as seq device conn jack loc color m= isc > hdaa0: 4 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: 5 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: 6 585600f0 15 0 Digital-out None Digital 0x18 Unknown 0= DISA > hdaa0: 7 185600f0 15 0 Digital-out Jack Digital 0x18 Unknown 0 > hdaa0: 3 associations found: > hdaa0: Association 0 (15) out: > hdaa0: Pin nid=3D4 seq=3D0 > hdaa0: Association 1 (15) out: > hdaa0: Pin nid=3D5 seq=3D0 > hdaa0: Association 2 (15) out: > hdaa0: Pin nid=3D7 seq=3D0 > hdaa0: Tracing association 0 (15) > hdaa0: Pin 4 traced to DAC 8 > hdaa0: Association 0 (15) trace succeeded > hdaa0: Tracing association 1 (15) > hdaa0: Pin 5 traced to DAC 9 > hdaa0: Association 1 (15) trace succeeded > hdaa0: Tracing association 2 (15) > hdaa0: Pin 7 traced to DAC 10 > hdaa0: Association 2 (15) trace succeeded > hdaa0: Looking for additional DAC for association 0 (15) > hdaa0: Looking for additional DAC for association 1 (15) > hdaa0: Looking for additional DAC for association 2 (15) > hdaa0: Tracing input monitor > hdaa0: Tracing other input monitors > hdaa0: Tracing beeper > hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref > pcm0: at nid 4 on hdaa0 > pcm0: Playback: > pcm0: Stream cap: 0x00000005 AC3 PCM > pcm0: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 K= Hz > pcm0: DAC: 8 > pcm0:=20 > pcm0: nid=3D4 [pin: Digital-out (Jack)] > pcm0: + <- nid=3D8 [audio output] [src: pcm] > pcm0:=20 > pcm0: Mixer "vol" -> "none": child=3D0x00000010 > pcm0: Mixer "pcm": parent=3D"vol" > pcm0: Soft PCM mixer ENABLED > pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected) > pcm1: at nid 5 on hdaa0 > pcm1: Playback: > pcm1: Stream cap: 0x00000005 AC3 PCM > pcm1: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 K= Hz > pcm1: DAC: 9 > pcm1:=20 > pcm1: nid=3D5 [pin: Digital-out (Jack)] > pcm1: + <- nid=3D9 [audio output] [src: pcm] > pcm1:=20 > pcm1: Mixer "vol" -> "none": child=3D0x00000010 > pcm1: Mixer "pcm": parent=3D"vol" > pcm1: Soft PCM mixer ENABLED > pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected) > pcm2: at nid 7 on hdaa0 > pcm2: Playback: > pcm2: Stream cap: 0x00000005 AC3 PCM > pcm2: PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 K= Hz > pcm2: DAC: 10 > pcm2:=20 > pcm2: nid=3D7 [pin: Digital-out (Jack)] > pcm2: + <- nid=3D10 [audio output] [src: pcm] > pcm2:=20 > pcm2: Mixer "vol" -> "none": child=3D0x00000010 > pcm2: Mixer "pcm": parent=3D"vol" > pcm2: Soft PCM mixer ENABLED > pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) > hdacc1: at cad 0 on hdac1 > hdaa1: at nid 1 on hdacc1 > hdaa1: Subsystem ID: 0x10ec0887 > hdaa1: NumGPIO=3D2 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUnsol=3D1 > hdaa1: GPIO0: disabled > hdaa1: GPIO1: disabled > hdaa1: Original pins configuration: > hdaa1: nid 0x as seq device conn jack loc color m= isc > hdaa1: 17 99430140 4 0 SPDIF-out Fixed ATAPI Onboard Unknown 1 > hdaa1: 18 411111f0 15 0 Speaker None 1/8 Rear Black 1 > hdaa1: 20 01014010 1 0 Line-out Jack 1/8 Rear Green 0 > hdaa1: 21 01011012 1 2 Line-out Jack 1/8 Rear Black 0 > hdaa1: 22 01016011 1 1 Line-out Jack 1/8 Rear Orange 0 > hdaa1: 23 01012014 1 4 Line-out Jack 1/8 Rear Grey 0 > hdaa1: 24 01a19850 5 0 Mic Jack 1/8 Rear Pink 8 > hdaa1: 25 02a19c60 6 0 Mic Jack 1/8 Front Pink 12 > hdaa1: 26 0181305f 5 15 Line-in Jack 1/8 Rear Blue 0 > hdaa1: 27 02214c20 2 0 Headphones Jack 1/8 Front Green 12 > hdaa1: 28 411111f0 15 0 Speaker None 1/8 Rear Black 1 > hdaa1: 29 4005e601 0 1 Line-out None Optical 0x00 White 6 > hdaa1: 30 01456130 3 0 SPDIF-out Jack Optical Rear Orange 1 > hdaa1: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1 > hdaa1: Patching widget caps nid=3D29 0x00400400 -> 0x00700400 > hdaa1: Patched pins configuration: > hdaa1: nid 0x as seq device conn jack loc color m= isc > hdaa1: 17 99430140 4 0 SPDIF-out Fixed ATAPI Onboard Unknown 1 > hdaa1: 18 411111f0 15 0 Speaker None 1/8 Rear Black 1= DISA > hdaa1: 20 01014010 1 0 Line-out Jack 1/8 Rear Green 0 > hdaa1: 21 01011012 1 2 Line-out Jack 1/8 Rear Black 0 > hdaa1: 22 01016011 1 1 Line-out Jack 1/8 Rear Orange 0 > hdaa1: 23 01012014 1 4 Line-out Jack 1/8 Rear Grey 0 > hdaa1: 24 01a19850 5 0 Mic Jack 1/8 Rear Pink 8 > hdaa1: 25 02a19c60 6 0 Mic Jack 1/8 Front Pink 12 > hdaa1: 26 0181305f 5 15 Line-in Jack 1/8 Rear Blue 0 > hdaa1: 27 02214c20 2 0 Headphones Jack 1/8 Front Green 12 > hdaa1: 28 411111f0 15 0 Speaker None 1/8 Rear Black 1= DISA > hdaa1: 30 01456130 3 0 SPDIF-out Jack Optical Rear Orange 1 > hdaa1: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1= DISA > hdaa1: 6 associations found: > hdaa1: Association 0 (1) out: > hdaa1: Pin nid=3D20 seq=3D0 > hdaa1: Pin nid=3D22 seq=3D1 > hdaa1: Pin nid=3D21 seq=3D2 > hdaa1: Pin nid=3D23 seq=3D4 > hdaa1: Association 1 (2) out: > hdaa1: Pin nid=3D27 seq=3D0 > hdaa1: Association 2 (3) out: > hdaa1: Pin nid=3D30 seq=3D0 > hdaa1: Association 3 (4) out: > hdaa1: Pin nid=3D17 seq=3D0 > hdaa1: Association 4 (5) in: > hdaa1: Pin nid=3D24 seq=3D0 > hdaa1: Pin nid=3D26 seq=3D15 > hdaa1: Association 5 (6) in: > hdaa1: Pin nid=3D25 seq=3D0 > hdaa1: Tracing association 0 (1) > hdaa1: Pin 20 traced to DAC 2 > hdaa1: Pin 22 traced to DAC 4 > hdaa1: Pin 21 traced to DAC 3 > hdaa1: Pin 23 traced to DAC 5 > hdaa1: Association 0 (1) trace succeeded > hdaa1: Tracing association 1 (2) > hdaa1: Pin 27 traced to DAC 37 > hdaa1: Association 1 (2) trace succeeded > hdaa1: Tracing association 2 (3) > hdaa1: Pin 30 traced to DAC 6 > hdaa1: Association 2 (3) trace succeeded > hdaa1: Tracing association 3 (4) > hdaa1: Pin 17 traced to DAC 16 > hdaa1: Association 3 (4) trace succeeded > hdaa1: Tracing association 4 (5) > hdaa1: Pin 24 traced to ADC 8 > hdaa1: Pin 26 traced to ADC 8 > hdaa1: Association 4 (5) trace succeeded > hdaa1: Tracing association 5 (6) > hdaa1: Pin 25 traced to ADC 9 > hdaa1: Association 5 (6) trace succeeded > hdaa1: Looking for additional DAC for association 0 (1) > hdaa1: Looking for additional DAC for association 1 (2) > hdaa1: Looking for additional DAC for association 2 (3) > hdaa1: Looking for additional DAC for association 3 (4) > hdaa1: Looking for additional ADC for association 4 (5) > hdaa1: Looking for additional ADC for association 5 (6) > hdaa1: Tracing input monitor > hdaa1: Tracing nid 11 to out > hdaa1: nid 11 is input monitor > hdaa1: Tracing nid 34 to out > hdaa1: Tracing nid 35 to out > hdaa1: Tracing other input monitors > hdaa1: Tracing nid 24 to out > hdaa1: Tracing nid 25 to out > hdaa1: Tracing nid 26 to out > hdaa1: Tracing beeper > hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref > pcm3: at nid 20,22,21,23 and 24,26= on hdaa1 > pcm3: Playback: > pcm3: Stream cap: 0x00000001 PCM > pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz > pcm3: DAC: 2 4 3 5 > pcm3:=20 > pcm3: nid=3D20 [pin: Line-out (Green Jack)] > pcm3: + <- nid=3D12 [audio mixer] [src: pcm, mix] > pcm3: + <- nid=3D2 [audio output] [src: pcm] > pcm3: + <- nid=3D11 [audio mixer] [src: mix] > pcm3:=20 > pcm3: nid=3D22 [pin: Line-out (Orange Jack)] > pcm3: + <- nid=3D14 [audio mixer] [src: pcm, mix] > pcm3: + <- nid=3D4 [audio output] [src: pcm] > pcm3: + <- nid=3D11 [audio mixer] [src: mix] > pcm3:=20 > pcm3: nid=3D21 [pin: Line-out (Black Jack)] > pcm3: + <- nid=3D13 [audio mixer] [src: pcm, mix] > pcm3: + <- nid=3D3 [audio output] [src: pcm] > pcm3: + <- nid=3D11 [audio mixer] [src: mix] > pcm3:=20 > pcm3: nid=3D23 [pin: Line-out (Grey Jack)] > pcm3: + <- nid=3D15 [audio mixer] [src: pcm, mix] > pcm3: + <- nid=3D5 [audio output] [src: pcm] > pcm3: + <- nid=3D11 [audio mixer] [src: mix] > pcm3:=20 > pcm3: Record: > pcm3: Stream cap: 0x00000001 PCM > pcm3: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz > pcm3: ADC: 8 > pcm3:=20 > pcm3: nid=3D8 [audio input] > pcm3: + <- nid=3D35 [audio mixer] [src: speaker, line, mic, mix] > pcm3: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic] > pcm3: + <- nid=3D26 [pin: Line-in (Blue Jack)] [src: line] > pcm3: + <- nid=3D29 [beep widget] [src: speaker] > pcm3: + <- nid=3D11 [audio mixer] [src: mix] > pcm3:=20 > pcm3: Input Mix: > pcm3:=20 > pcm3: nid=3D11 [audio mixer] > pcm3: + <- nid=3D24 [pin: Mic (Pink Jack)] [src: mic] > pcm3: + <- nid=3D26 [pin: Line-in (Blue Jack)] [src: line] > pcm3: + <- nid=3D29 [beep widget] [src: speaker] > pcm3:=20 > pcm3: Master Volume (OSS: vol): -64/0dB > pcm3: +- ctl 1 (nid 2 out): -64/0dB (65 steps) > pcm3: +- ctl 2 (nid 3 out): -64/0dB (65 steps) > pcm3: +- ctl 3 (nid 4 out): -64/0dB (65 steps) > pcm3: +- ctl 4 (nid 5 out): -64/0dB (65 steps) > pcm3: +- ctl 17 (nid 12 in 0): mute > pcm3: +- ctl 18 (nid 12 in 1): mute > pcm3: +- ctl 19 (nid 13 in 0): mute > pcm3: +- ctl 20 (nid 13 in 1): mute > pcm3: +- ctl 21 (nid 14 in 0): mute > pcm3: +- ctl 22 (nid 14 in 1): mute > pcm3: +- ctl 23 (nid 15 in 0): mute > pcm3: +- ctl 24 (nid 15 in 1): mute > pcm3: +- ctl 25 (nid 20 in ): mute > pcm3: +- ctl 26 (nid 21 in ): mute > pcm3: +- ctl 27 (nid 22 in ): mute > pcm3: +- ctl 28 (nid 23 in ): mute > pcm3:=20 > pcm3: PCM Volume (OSS: pcm): -64/0dB > pcm3: +- ctl 1 (nid 2 out): -64/0dB (65 steps) > pcm3: +- ctl 2 (nid 3 out): -64/0dB (65 steps) > pcm3: +- ctl 3 (nid 4 out): -64/0dB (65 steps) > pcm3: +- ctl 4 (nid 5 out): -64/0dB (65 steps) > pcm3: +- ctl 17 (nid 12 in 0): mute > pcm3: +- ctl 19 (nid 13 in 0): mute > pcm3: +- ctl 21 (nid 14 in 0): mute > pcm3: +- ctl 23 (nid 15 in 0): mute > pcm3:=20 > pcm3: Microphone Volume (OSS: mic): 0/30dB > pcm3: +- ctl 7 (nid 11 in 0): -34/12dB (32 steps) + mute > pcm3: +- ctl 30 (nid 24 out): 0/30dB (4 steps) > pcm3: +- ctl 49 (nid 35 in 0): mute > pcm3:=20 > pcm3: Line-in Volume (OSS: line): 0/30dB > pcm3: +- ctl 9 (nid 11 in 2): -34/12dB (32 steps) + mute > pcm3: +- ctl 34 (nid 26 out): 0/30dB (4 steps) > pcm3: +- ctl 51 (nid 35 in 2): mute > pcm3:=20 > pcm3: Speaker/Beep Volume (OSS: speaker): -34/12dB > pcm3: +- ctl 12 (nid 11 in 5): -34/12dB (32 steps) + mute > pcm3: +- ctl 54 (nid 35 in 5): mute > pcm3:=20 > pcm3: Recording Level (OSS: rec): -16/30dB > pcm3: +- ctl 5 (nid 8 in 0): -16/30dB (47 steps) + mute > pcm3: +- ctl 49 (nid 35 in 0): mute > pcm3: +- ctl 51 (nid 35 in 2): mute > pcm3: +- ctl 54 (nid 35 in 5): mute > pcm3: +- ctl 59 (nid 35 in 10): mute > pcm3:=20 > pcm3: Input Mix Level (OSS: mix): -34/12dB > pcm3: +- ctl 7 (nid 11 in 0): -34/12dB (32 steps) + mute > pcm3: +- ctl 9 (nid 11 in 2): -34/12dB (32 steps) + mute > pcm3: +- ctl 12 (nid 11 in 5): -34/12dB (32 steps) + mute > pcm3: +- ctl 18 (nid 12 in 1): mute > pcm3: +- ctl 20 (nid 13 in 1): mute > pcm3: +- ctl 22 (nid 14 in 1): mute > pcm3: +- ctl 24 (nid 15 in 1): mute > pcm3: +- ctl 59 (nid 35 in 10): mute > pcm3:=20 > pcm3: Input Monitoring Level (OSS: igain): 0/0dB > pcm3: +- ctl 18 (nid 12 in 1): mute > pcm3: +- ctl 20 (nid 13 in 1): mute > pcm3: +- ctl 22 (nid 14 in 1): mute > pcm3: +- ctl 24 (nid 15 in 1): mute > pcm3:=20 > pcm3: Mixer "vol": > pcm3: Mixer "pcm": > pcm3: Mixer "speaker": > pcm3: Mixer "line": > pcm3: Mixer "mic": > pcm3: Mixer "mix": > pcm3: Mixer "rec": > pcm3: Mixer "igain": > pcm3: Mixer "ogain": > pcm3: Playback channel set is: Front Left, Front Right, Front Center, Low= Frequency Effects, Back Left, Back Right, Side Left, Side Right,=20 > pcm3: Playback channel matrix is: 7.1 (disconnected) > pcm3: Recording channel set is: Front Left, Front Right,=20 > pcm3: Recording channel matrix is: 2.0 (disconnected) > pcm4: at nid 27 and 25 on hdaa1 > pcm4: Playback: > pcm4: Stream cap: 0x00000001 PCM > pcm4: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz > pcm4: DAC: 37 > pcm4:=20 > pcm4: nid=3D27 [pin: Headphones (Green Jack)] > pcm4: + <- nid=3D38 [audio mixer] [src: pcm, mix] > pcm4: + <- nid=3D37 [audio output] [src: pcm] > pcm4: + <- nid=3D11 [audio mixer] [src: mix] > pcm4:=20 > pcm4: Record: > pcm4: Stream cap: 0x00000001 PCM > pcm4: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz > pcm4: ADC: 9 > pcm4:=20 > pcm4: nid=3D9 [audio input] > pcm4: + <- nid=3D34 [audio mixer] [src: speaker, monitor] > pcm4: + <- nid=3D25 [pin: Mic (Pink Jack)] [src: monitor] > pcm4: + <- nid=3D29 [beep widget] [src: speaker] > pcm4:=20 > pcm4: Master Volume (OSS: vol): -64/0dB > pcm4: +- ctl 35 (nid 27 in ): mute > pcm4: +- ctl 60 (nid 37 out): -64/0dB (65 steps) > pcm4: +- ctl 61 (nid 38 in 0): mute > pcm4: +- ctl 62 (nid 38 in 1): mute > pcm4:=20 > pcm4: PCM Volume (OSS: pcm): -64/0dB > pcm4: +- ctl 60 (nid 37 out): -64/0dB (65 steps) > pcm4: +- ctl 61 (nid 38 in 0): mute > pcm4:=20 > pcm4: Microphone2 Volume (OSS: monitor): 0/30dB > pcm4: +- ctl 32 (nid 25 out): 0/30dB (4 steps) > pcm4: +- ctl 38 (nid 34 in 1): mute > pcm4:=20 > pcm4: Speaker/Beep Volume (OSS: speaker) > pcm4: +- ctl 42 (nid 34 in 5): mute > pcm4:=20 > pcm4: Recording Level (OSS: rec): -16/30dB > pcm4: +- ctl 6 (nid 9 in 0): -16/30dB (47 steps) + mute > pcm4: +- ctl 32 (nid 25 out): 0/30dB (4 steps) > pcm4: +- ctl 38 (nid 34 in 1): mute > pcm4: +- ctl 42 (nid 34 in 5): mute > pcm4:=20 > pcm4: Input Mix Level (OSS: mix) > pcm4: +- ctl 62 (nid 38 in 1): mute > pcm4:=20 > pcm4: Input Monitoring Level (OSS: igain): 0/0dB > pcm4: +- ctl 62 (nid 38 in 1): mute > pcm4:=20 > pcm4: Mixer "vol": > pcm4: Mixer "pcm": > pcm4: Mixer "rec": > pcm4: Mixer "igain": > pcm4: Mixer "ogain": > pcm4: Mixer "monitor": > pcm4: Playback channel set is: Front Left, Front Right,=20 > pcm4: Playback channel matrix is: 2.0 (disconnected) > pcm4: Recording channel set is: Front Left, Front Right,=20 > pcm4: Recording channel matrix is: 2.0 (disconnected) > pcm5: at nid 30 on hdaa1 > pcm5: Playback: > pcm5: Stream cap: 0x00000005 AC3 PCM > pcm5: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz > pcm5: DAC: 6 > pcm5:=20 > pcm5: nid=3D30 [pin: SPDIF-out (Orange Jack)] > pcm5: + <- nid=3D6 [audio output] [src: pcm] > pcm5:=20 > pcm5: Mixer "vol" -> "none": child=3D0x00000010 > pcm5: Mixer "pcm": parent=3D"vol" > pcm5: Soft PCM mixer ENABLED > pcm5: Playback channel set is: Front Left, Front Right,=20 > pcm5: Playback channel matrix is: 2.0 (unknown) > pcm6: at nid 17 on hdaa1 > pcm6: Playback: > pcm6: Stream cap: 0x00000005 AC3 PCM > pcm6: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz > pcm6: DAC: 16 > pcm6:=20 > pcm6: nid=3D17 [pin: SPDIF-out (Fixed)] > pcm6: + <- nid=3D16 [audio output] [src: pcm] > pcm6:=20 > pcm6: Mixer "vol" -> "none": child=3D0x00000010 > pcm6: Mixer "pcm": parent=3D"vol" > pcm6: Soft PCM mixer ENABLED > pcm6: Playback channel set is: Front Left, Front Right,=20 > pcm6: Playback channel matrix is: 2.0 (unknown) > usbus1: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 12Mbps Full Speed USB v1.0 > ahcich0: ugen4.1: at usbus4 > uhub4: on usbus4 > AHCI reset... > ahcich0: SATA connect time=3D100us status=3D00000133 > uhub0: 5 ports with 5 removable, self powered > ahcich0: AHCI reset: device found > ahcich0: AHCI reset: device ready after 0ms > ahcich1: AHCI reset... > uhub2: 5 ports with 5 removable, self powered > ahcich1: SATA connect time=3D1000us status=3D00000123 > uhub4: 2 ports with 2 removable, self powered > ahcich1: AHCI reset: device found > ahcich1: AHCI reset: device ready after 0ms > ahcich2: AHCI reset... > ahcich2: SATA connect timeout time=3D10000us status=3D00000000 > ahcich2: AHCI reset: device not found > ahcich3: AHCI reset... > ahcich3: SATA connect timeout time=3D10000us status=3D00000000 > ahcich3: AHCI reset: device not found > ahcich4: AHCI reset... > ahcich4: SATA connect timeout time=3D10000us status=3D00000000 > ahcich4: AHCI reset: device not found > ahcich5: AHCI reset... > ahcich5: SATA connect timeout time=3D10000us status=3D00000000 > ahcich5: AHCI reset: device not found > ahcich6: AHCI reset... > ahcich6: SATA connect time=3D1900us status=3D00000113 > ahcich6: AHCI reset: device found > ahcich6: AHCI reset: device ready after 0ms > ahcich7: AHCI reset... > ahcich7: SATA connect timeout time=3D10000us status=3D00000000 > ahcich7: AHCI reset: device not found > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > cd0 at ahcich6 bus 0 scbus6 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number S10L68ED801632 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: cd present [1337280 x 2048 byte records] > GEOM: new disk cd0 > pass0: ACS-2 ATA SATA 3.x device > pass0: Serial Number WD-WCC4M2FDTN63 > pass0: 600.000MB/s transfersuhub1: 5 ports with 5 removable, self powered > (SATA 3.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > uhub3: 5 ports with 5 removable, self powered > pass1: ATA8-ACS SATA 2.x device > pass1: Serial Number WD-WCATR0116121 > pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass1: Command Queueing enabled > pass2 at ahcich6 bus 0 scbus6 target 0 lun 0 > pass2: Removable CD-ROM SCSI device > pass2: Serial Number S10L68ED801632 > pass2: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192byt= es) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number WD-WCC4M2FDTN63 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=3D0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA8-ACS SATA 2.x device > ada1: Serial Number WD-WCATR0116121 > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > ugen0.2: at usbus0 > ukbd0: on usbus0 > kbd2 at ukbd0 > kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 > Netvsc initializing... done! > SMP: AP CPU #2 Launched! > cpu2 AP: > ID: 0x12000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > SMP: AP CPU #3 Launched! > cpu3 AP: > ID: 0x13000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x11000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 17 vector 48 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 18 vector 48 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 19 vector 48 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 17 vector 49 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 18 vector 49 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 19 vector 49 > msi: Assigning MSI IRQ 256 to local APIC 17 vector 50 > GEOM: new disk ada0 > msi: Assigning MSI-X IRQ 257 to local APIC 18 vector 50 > GEOM: new disk ada1 > SMP: passed TSC synchronization test > TSC timecounter discards lower 1 bit(s) > Timecounter "TSC-low" frequency 1696949239 Hz quality 1000 > ugen3.2: at usbus3 > umass0: on= usbus3 > umass0: SCSI over Bulk-Only; quirks =3D 0xc000 > umass0:8:0:-1: Attached to scbus8 > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > pass3 at umass-sim0 bus 0 scbus8 target 0 lun 0 > pass3: Removable Direct Access SCSI device > pass3: Serial Number 000000009744 > pass3: 40.000MB/s transfers > da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 > da0: Removable Direct Access SCSI device > da0: Serial Number 000000009744 > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > ugen0.3: at usbus0 > da0: quirks=3D0x3 > da0: Delete methods: > (probe0:umass-sim0:0:0:1): Down reving Protocol Version from 2 to 0? > pass4 at umass-sim0 bus 0 scbus8 target 0 lun 1 > pass4: Removable Direct Access SCSI device > pass4: Serial Number 000000009744 > pass4: 40.000MB/s transfers > da1 at umass-sim0 bus 0 scbus8 target 0 lun 1 > da1: Removable Direct Access SCSI device > da1: Serial Number 000000009744 > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > da1: quirks=3D0x3 > da1: Delete methods: > (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? > pass5 at umass-sim0 bus 0 scbus8 target 0 lun 2 > pass5: Removable Direct Access SCSI device > pass5: Serial Number 000000009744 > pass5: 40.000MB/s transfers > GEOM: new disk da0 > da2 at umass-sim0 bus 0 scbus8 target 0 lun 2 > GEOM: new disk da1 > da2: Removable Direct Access SCSI device > da2: Serial Number 000000009744 > da2: 40.000MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not present > da2: quirks=3D0x3 > da2: Delete methods: > (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? > pass6 at umass-sim0 bus 0 scbus8 target 0 lun 3 > pass6: Removable Direct Access SCSI device > pass6: Serial Number 000000009744 > pass6: 40.000MB/s transfers > da3 at umass-sim0 bus 0 scbus8 target 0 lun 3 > da3: Removable Direct Access SCSI device > da3: Serial Number 000000009744 > da3: 40.000MB/s transfers > da3: Attempt to query device size failed: NOT READY, Medium not present > da3: quirks=3D0x3 > da3: Delete methods: > GEOM: new disk da2 > (probe0:umass-sim0:0:0:4): Down reving Protocol Version from 2 to 0? > pass7 at umass-sim0 bus 0 scbus8 target 0 lun 4 > pass7: Removable Direct Access SCSI device > pass7: Serial Number 000000009744 > pass7: 40.000MB/s transfers > da4 at umass-sim0 bus 0 scbus8 target 0 lun 4 > da4: Removable Direct Access SCSI device > da4: Serial Number 000000009744 > da4: 40.000MB/s transfers > da4: Attempt to query device size failed: NOT READY, Medium not present > da4: quirks=3D0x3 > da4: Delete methods: > GEOM: new disk da3 > GEOM: new disk da4 > Trying to mount root from cd9660:/dev/iso9660/11_0_RELEASE_AMD64_DVD [ro]= =2E.. > start_init: trying /sbin/init > ums0: on usbus0 > ums0: 5 buttons and [XYZ] coordinates ID=3D0 --=20 _________________=20 < Vote anarchist. > -----------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --9HzmNrjLmDa9xpHW Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="coreboot.log" /boot/kernel/kernel text=0x14c6128 data=0x140810+0x564568 syms=[0x8+0x16a970+0x8+0x183b9c] Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Table 'FACP' at 0xbffb0cd0 Table 'SSDT' at 0xbffb0dd0 Table 'TCPA' at 0xbffb0e60 Table 'APIC' at 0xbffb0ea0 APIC: Found table at 0xbffb0ea0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 16 ACPI ID 0: enabled SMP: Added CPU 16 (AP) MADT: Found CPU APIC ID 17 ACPI ID 1: enabled SMP: Added CPU 17 (AP) MADT: Found CPU APIC ID 18 ACPI ID 2: enabled SMP: Added CPU 18 (AP) MADT: Found CPU APIC ID 19 ACPI ID 3: enabled SMP: Added CPU 19 (AP) Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r315413: Thu Mar 16 17:23:31 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xbffb0cd0 Table 'SSDT' at 0xbffb0dd0 Table 'TCPA' at 0xbffb0e60 Table 'APIC' at 0xbffb0ea0 Table 'HPET' at 0xbffb0f20 Table 'HEST' at 0xbffb0f60 Table 'IVRS' at 0xbffb1130 Table 'SSDT' at 0xbffb11a0 Table 'SSDT' at 0xbffb16c0 ACPI: No SRAT table found PPIM 0: PA=0xa0000, VA=0xffffffff82410000, size=0x10000, mode=0 VT(vga): resolution 640x480 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8225a000. Calibrating TSC clock ... TSC clock: 3393898334 Hz CPU: AMD Athlon(tm) X4 750K Quad Core Processor (3393.90-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x610f01 Family=0x15 Model=0x10 Stepping=1 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff Structured Extended Features=0x8 SVM: Features=0x1cff,PauseFilterThreshold> Revision=1, ASIDs=65536 TSC: P-state invariant, performance statistics L1 2MB data TLB: 64 entries, fully associative L1 2MB instruction TLB: 24 entries, fully associative L1 4KB data TLB: 64 entries, fully associative L1 4KB instruction TLB: 48 entries, fully associative L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 1024 entries, 8-way associative L2 2MB instruction TLB: 1024 entries, 8-way associative L2 4KB data TLB: 1024 entries, 8-way associative L2 4KB instruction TLB: 1024 entries, 8-way associative L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 9110028288 (8688 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x000000000229d000 - 0x00000000bff98fff, 3184508928 bytes (777468 pages) 0x0000000100000000 - 0x00000002117c0fff, 4588310528 bytes (1120193 pages) avail memory = 7703834624 (7346 MB) Event timer "LAPIC" quality 100 LAPIC: ipi_wait() us multiplier 22 (r 14875176 tsc 3393898334) ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 x86bios: SSEG 0x098000-0x098fff at 0xfffffe020c98c000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffff8000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 lapic16: MCE Thresholding ELVT unmasked Pentium Pro MTRR support enabled ULE: setup cpu 0 ACPI: RSDP 0x00000000000F2A30 000024 (v02 CORE ) ACPI: XSDT 0x00000000BFFAF0E0 00006C (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: FACP 0x00000000BFFB0CD0 0000F4 (v04 CORE COREBOOT 00000000 CORE 00000000) ACPI: DSDT 0x00000000BFFAF280 001A48 (v02 ASUS COREBOOT 00010001 INTL 20161222) ACPI: FACS 0x00000000BFFAF240 000040 ACPI: FACS 0x00000000BFFAF240 000040 ACPI: SSDT 0x00000000BFFB0DD0 00008A (v02 CORE COREBOOT 0000002A CORE 0000002A) ACPI: TCPA 0x00000000BFFB0E60 000032 (v02 CORE COREBOOT 00000000 CORE 00000000) ACPI: APIC 0x00000000BFFB0EA0 000072 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: HPET 0x00000000BFFB0F20 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: HEST 0x00000000BFFB0F60 0001D0 (v01 CORE COREBOOT 00000000 CORE 00000000) ACPI: IVRS 0x00000000BFFB1130 000070 (v02 AMD AMDIOMMU 00000001 AMD 00000000) ACPI: SSDT 0x00000000BFFB11A0 00051F (v02 AMD ALIB 00000001 MSFT 04000000) ACPI: SSDT 0x00000000BFFB16C0 000D40 (v01 AMD POWERNOW 00000001 AMD 00000001) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: ver 0x21 maxredir 0x17 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x10000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000300ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 AMD ext features: 0x00040007 AMD elvt0: 0x00010000 AMD elvt1: 0x000000f2 AMD elvt2: 0x00010000 AMD elvt3: 0x00010000 TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1696949167 Hz quality 1000 random: entropy device external interface snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> mem: netmap: loaded module null: nfslock: pseudo-device crypto: module_register_init: MOD_LOAD (vesa, 0xffffffff80f49c70, 0) error 19 io: kbd: new array size 4 kbd1 at kbdmux0 hpt27xx: RocketRAID 27xx controller driver v1.2.7 hptnr: R750/DC7280 controller driver v1.1.4 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 nexus0 vtvga0: on motherboard random: harvesting attach, 8 bytes (4 bits) from vtvga0 random: harvesting attach, 8 bytes (4 bits) from ram0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 acpi0: on motherboard ACPI: Executed 2 blocks of module-level executable AML code ACPI: 4 ACPI AML tables successfully acquired and loaded panic: Couldn't find an APIC vector for IRQ 9 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8225f680 vpanic() at vpanic+0x19c/frame 0xffffffff8225f700 panic() at panic+0x43/frame 0xffffffff8225f760 ioapic_enable_intr() at ioapic_enable_intr+0x52/frame 0xffffffff8225f780 intr_add_handler() at intr_add_handler+0xda/frame 0xffffffff8225f7d0 nexus_setup_intr() at nexus_setup_intr+0x8a/frame 0xffffffff8225f820 bus_setup_intr() at bus_setup_intr+0xa1/frame 0xffffffff8225f880 AcpiOsInstallInterruptHandler() at AcpiOsInstallInterruptHandler+0x1ba/frame 0xffffffff8225f8c0 AcpiEvInstallXruptHandlers() at AcpiEvInstallXruptHandlers+0x18/frame 0xffffffff8225f8e0 acpi_attach() at acpi_attach+0x2fd/frame 0xffffffff8225f990 device_attach() at device_attach+0x3de/frame 0xffffffff8225f9d0 bus_generic_attach() at bus_generic_attach+0x5a/frame 0xffffffff8225f9f0 nexus_acpi_attach() at nexus_acpi_attach+0x73/frame 0xffffffff8225fa20 device_attach() at device_attach+0x3de/frame 0xffffffff8225fa60 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0xffffffff8225fa90 bus_set_pass() at bus_set_pass+0x8c/frame 0xffffffff8225fac0 configure() at configure+0x9/frame 0xffffffff8225fad0 mi_startup() at mi_startup+0x9c/frame 0xffffffff8225faf0 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why --9HzmNrjLmDa9xpHW-- --mBcWXAAsoZ3r5qnj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYzYT3AAoJEHpZm4Ugg5ydjOIQAJZxp2PnXBmj9nIIevC42DhZ +RCX+1se8CW+H3+MC+p/A20eid1YqJTvbCy38ypuM1r1VOWICgWiFMQ0zpZ8Cq1f avWrdEfIi2kpUcahsMtUiiKsjIT0gASHenQ409AyLjEOMxViJHThp3UOaznVUiuq yhcIFeZV23VYjFL0T+FNMlzrdfun8LxqMQFmpcw+jGyR3H0z2SiZWBJZOJY4tqgm +pzlNQ0Zyn6ulgoLAs+ACihkbQEc4FAGxARyBgkmiisSj5WEpEhnG8xVqHWd/3q5 3XGYJiPzLwiLXWezZCukHJ/1noEMexJ3Zo6AKyG3CIcIKJAM9UVCkMyd8b7BGM6R jWWFEZpiOIFwZNhUXHk4J89HBzA0ByqtmtEKsAgOSnu4Zv5AcoUlW2DUy2Ywu8yT rSW+T+XrSW/CJpREuggtztptWN3SvF8B8FD/NyzpbHW69lKLzaH3znHjf3MHiuKv Ae/BufI3BlMXIO1Zzqzn9zB8waJHe+oPq6U7MbVGYm9ZuvKAQAGW4cTBsPB0hZ4V CmiWQxolhs8l1DRRCLOGhTWgbIS5kQ6yd8nig4Wf6SY4flFdhVCNVa3vgZf4OM2v PN3VdJkIAyPpUrDrKTkcOLuK2mpgYY2csIliI8eo9OcSWb0aMd156UBuWcz3HfDh xxfc661J1t2dmp/L4evn =ilD0 -----END PGP SIGNATURE----- --mBcWXAAsoZ3r5qnj-- From owner-freebsd-hackers@freebsd.org Sat Mar 18 20:51:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBD63D12D6E for ; Sat, 18 Mar 2017 20:51:52 +0000 (UTC) (envelope-from ankit.raj.min14@itbhu.ac.in) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B4AF13B4 for ; Sat, 18 Mar 2017 20:51:51 +0000 (UTC) (envelope-from ankit.raj.min14@itbhu.ac.in) Received: by mail-wr0-x22b.google.com with SMTP id u108so70706504wrb.3 for ; Sat, 18 Mar 2017 13:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itbhu-ac-in.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=r2CqUdXtcm9tIssxA5X/0v3QbUf1Ri0+5M8fO/QADYU=; b=YFsXbYQP+lhAh98NyDujmHkSRXG5FsbNgE93fl8DOd8XCJ74yU8yRAcIJYulkQNH+l CGq5CEXmtHpaNJuDvR+Tq5LquLHrVlyXxVpNHVVndbgEigojBcfMygGKBDsqxDvRS2zP j/CqgB9O/4ShwWrPZUk5MoSVwvFnXDZyGa/M2mN5fz4hPzWdEPqgPQOjRCx+Ch/O3vLS a3HJ/95L+Kcm4rdBeAZ66m22ZsoCwXiGMzRLiOQbUg3kfCKwuGzTBFUgcuXjyzgOnhjG x7/a1z0eowALllHrMCzAfr3c3HXK9446h5Bw5BwzkFKjj92bSch/QQTjsQuTBvGHt5bt OEWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r2CqUdXtcm9tIssxA5X/0v3QbUf1Ri0+5M8fO/QADYU=; b=tzRFkcn8ZbBD/vzR6WI7T1QPHcXDQRvsC7+yf6T0/r2u2s0Gu2P1PWHiyLZPkaUf6j 1owiJtpYauPSv2yPUjCB3yOGcV9NWB7c81wx0BDKEQdLmjDqoghKSdotzyudlKA16UWp NchSrvt3+As1zff6aDeB229nIv7uiJw6KB8PgK3iHZoCVU8vkIh9JB29MLMCLQg+S7EF 6tWLEPvoeyh1bTxIGyEjIK4ktQXkMovOdJ3FFFHmzZpb7np/mdoU4RY780p9bEBfKXyo N9aRjmpUNVKZ8/RxKmijV+2I0DJbMabO5urektYgyk84L30YAkqYq4VUw6X16LmcxNgi og2A== X-Gm-Message-State: AFeK/H3M0tk5a1PexH+j3SPrxJ3U8MB3G49w0Wb6K8uE0zjEyYqFoBYWwbgNaD7N5f1XxdN+KLipIsnIhhYIFhE+ X-Received: by 10.223.128.202 with SMTP id 68mr18969304wrl.108.1489870309097; Sat, 18 Mar 2017 13:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.150.35 with HTTP; Sat, 18 Mar 2017 13:51:48 -0700 (PDT) From: "Ankit Raj 5-Yr IDD Mining Engg." Date: Sun, 19 Mar 2017 02:21:48 +0530 Message-ID: Subject: Regarding Gsoc Project - "Replace mergesort implementation" To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sat, 18 Mar 2017 21:42:03 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 20:51:52 -0000 I am Ankit Raj a UG student at IIT(BHU),Varanasi.I am applying for the Gsoc 2017. I have done academically well scoring GPA 8.30/10. I have the strong knowledge of the Data Structures & algorithms, Graph Theory.I am proficient in C/C++ programming as i am doing this for last 2-3 year.I have sound knowledge of Machine learning algorithms and database. I am fully aware of the commitment and perseverance required for working in a Gsoc project and I believe that my aptitude and motivation will help me successfully face any challenge. I am interested in the project "*Replace mergesort implementation*".I have go through the issue/problem. Can you explain me more about the project and source ,that will help for the further steps. Also i request you to help to a make proposal regarding this project. *Thanks & Regards,* *Ankit Raj* *Department of Mining Engineering,* *IIT(BHU)Varanasi, India* Contact- 9956463839 Linkedin From owner-freebsd-hackers@freebsd.org Sat Mar 18 20:54:53 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B8A6D12F20 for ; Sat, 18 Mar 2017 20:54:53 +0000 (UTC) (envelope-from ankit.raj.min14@itbhu.ac.in) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 2141D14E3 for ; Sat, 18 Mar 2017 20:54:53 +0000 (UTC) (envelope-from ankit.raj.min14@itbhu.ac.in) Received: by mail-wm0-x22e.google.com with SMTP id n11so38723350wma.0 for ; Sat, 18 Mar 2017 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itbhu-ac-in.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gt7kqtitIOl30d2Zsdp831neNM1vyHxlyGWOk7jwc8U=; b=wOlPqYZpVTMsuAcBdYCl4C/GXsFykHLod7Nn5uevnJMucM0pyhwHaMMa1CqCOXia6R B9UEqXQ0vfZlZzBnp8nrZ90kwOT1cunrVFt7IhvtqqFTDixwHNsULN8wbCtEoQfdRlk3 jQH1M0NKF+Xjpx5mkiaRUVMjfFLSVNyYe4XPC8iQh+iWOj7hxQPYGYfFapWuZ2G1zRPe 8XANw2vNMD8WibWn7+DeXlUsgnN8wUk+yapQnvPS8fHzxNqRLfLgvnMP54JdlcsskGkW BrmttHDZknQ2Op5qHS91DrhOiZwG6nSWjfCLDsvMBlCuiL4w0y5m7dbBOUg+G/pZqFXQ NiXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gt7kqtitIOl30d2Zsdp831neNM1vyHxlyGWOk7jwc8U=; b=C++SfxidWkK9kNq2qwl8eGUuyd6UdTYq0YzjOvtor17ctGfhKZwT2AF/sRKph6CSQP 78oW/qS/eiFV9CIwB+FdaAO4FtlijwZvdIIMeJ4EEk+6hBOJusm8UTaD2vsYX5xA3T0d HZlhP12LCuPsWlVKMr8AZkKPboRRb7QcrOhxoMHoj+DL5MMn/dv2X+vWoSrDy0hQFV6P t499KeZFA1gE0VdI51eMeq5J3Hsj6CgcCFa4dqJtHkIRIszijIpsgsYAASOceie5mbxq 5PScJFCXqJuTPblfxee8DuzFzAk54gbBrP+D4RadmQtWDKImFnXLWyPzeQ1lQy7EMSMX LYOQ== X-Gm-Message-State: AFeK/H10/WEQnvANiwEGw+c+dQyOhWrENU+HitXHl0K3btjxVZ2j+DfM1N/zarZvFo9W2wXj+Exmoe4Kvp/JxOyu X-Received: by 10.28.193.197 with SMTP id r188mr3810281wmf.116.1489870490153; Sat, 18 Mar 2017 13:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.150.35 with HTTP; Sat, 18 Mar 2017 13:54:49 -0700 (PDT) In-Reply-To: References: From: "Ankit Raj 5-Yr IDD Mining Engg." Date: Sun, 19 Mar 2017 02:24:49 +0530 Message-ID: Subject: Re: Regarding Gsoc Project - "Replace mergesort implementation" To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sat, 18 Mar 2017 23:13:51 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 20:54:53 -0000 I am Ankit Raj a UG student at IIT(BHU),Varanasi.I am applying for the Gsoc 2017. I have done academically well scoring GPA 8.30/10. I have the strong knowledge of the Data Structures & algorithms, Graph Theory.I am proficient in C/C++ programming as i am doing this for last 2-3 year.I have sound knowledge of Machine learning algorithms and database. I am fully aware of the commitment and perseverance required for working in a Gsoc project and I believe that my aptitude and motivation will help me successfully face any challenge. I am interested in the project "*Replace mergesort implementation*".I have go through the issue/problem. Can you explain me more about the project and source ,that will help for the further steps. Also i request you to help to a make proposal regarding this project. *Thanks & Regards,* *Ankit Raj* *Department of Mining Engineering,* *IIT(BHU)Varanasi, India* Contact- 9956463839 Linkedin On Sun, Mar 19, 2017 at 2:21 AM, Ankit Raj 5-Yr IDD Mining Engg. < ankit.raj.min14@itbhu.ac.in> wrote: > I am Ankit Raj a UG student at IIT(BHU),Varanasi.I am applying for the > Gsoc 2017. > > I have done academically well scoring GPA 8.30/10. I have the strong > knowledge of the Data Structures & algorithms, Graph Theory.I am proficient > in C/C++ programming as i am doing this for last 2-3 year.I have sound > knowledge of Machine learning algorithms and database. > > I am fully aware of the commitment and perseverance required for working > in a Gsoc project and I believe that my aptitude and motivation will help > me successfully face any challenge. > I am interested in the project "*Replace mergesort implementation*".I > have go through the issue/problem. > Can you explain me more about the project and source ,that will help for > the further steps. > > Also i request you to help to a make proposal regarding this project. > > *Thanks & Regards,* > *Ankit Raj* > *Department of Mining Engineering,* > *IIT(BHU)Varanasi, India* > Contact- 9956463839 > Linkedin > > > >