From owner-freebsd-hackers@freebsd.org Sun Feb 19 20:30:16 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 6B789CE5990; Sun, 19 Feb 2017 20:30:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 517D2187F; Sun, 19 Feb 2017 20:30:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1JKUFUo083830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Feb 2017 12:30:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1JKUFGh083829; Sun, 19 Feb 2017 12:30:15 -0800 (PST) (envelope-from sgk) Date: Sun, 19 Feb 2017 12:30:15 -0800 From: Steve Kargl To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: elf_load_section problem Message-ID: <20170219203015.GA83765@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Mailman-Approved-At: Sun, 19 Feb 2017 21:41:28 +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: Sun, 19 Feb 2017 20:30:16 -0000 Looks like I picked the wrong time to update a month old. Problem #1: 'kldload -v i915kms.ko' locks up the system. No panic. No messages logged. No keyboard response. Black screen of death. Problem #2: 'kldload -v drm2.ko' locks up the system. No panic. No messages logged. No keyboard response. Black screen of death. Problem #3: #1 and #2 along with an update of xorg to 1.18.4 prevents X from firing up. Problem #4: Ok. I re-install everything that X uses and their dependencies from source. % cd /usr/ports/misc/help2man % script % make Script started on Sun Feb 19 12:20:18 2017 laptop-kargl:root[201] make ===> help2man-1.47.4 depends on executable: gmake - found ===> help2man-1.47.4 depends on package: perl5>=5.24<5.25 - found ===> Configuring for help2man-1.47.4 configure: loading site script /usr/ports/Templates/config.site checking for perl... perl checking for module Locale::gettext... no checking for msgfmt... no checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for library containing dlsym... none required checking for library containing bindtextdomain... no checking for a BSD-compatible install... /usr/bin/install -c checking for makeinfo... build-aux/missing makeinfo checking for install-info... build-aux/missing install-info checking for msgmerge... build-aux/missing msgmerge checking for xgettext... build-aux/missing xgettext checking for po4a-updatepo... build-aux/missing po4a-updatepo checking for po4a-translate... build-aux/missing po4a-translate configure: creating ./config.status config.status: creating Makefile ===> Building for help2man-1.47.4 elf_load_section: truncated ELF file Abort trap *** Error code 1 Stop. make[1]: stopped in /usr/ports/misc/help2man *** Error code 1 Stop. make: stopped in /usr/ports/misc/help2man laptop-kargl:root[202] exit exit % exit Script done on Sun Feb 19 12:20:29 2017 -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sun Feb 19 23:59:26 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 189FFCE5408 for ; Sun, 19 Feb 2017 23:59:26 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB5AF121 for ; Sun, 19 Feb 2017 23:59:25 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ot0-x230.google.com with SMTP id x10so19665887otb.1 for ; Sun, 19 Feb 2017 15:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9oimjYOe9EF36DaYSgrUybxQBfuAzI/rZ8UDOZaXGno=; b=vYzcS701MzEgRe9Cnmg6kKbTZn8HHGMwKXEkK6lvJbr+ak7zrTjoNgdRtKL6lCCGuk +ZqmGzbXuJrFLv7hFD99A4UJf3NfvYRlC2TveHieuww5hkBp8+7pcTRpng9kusl6YXHw lygdv3Xb/nSqKsQ2OufOcKEoBpy99s3WmFqcmU6CKstONtfjsDxWruNt0GRDJnmbrmya 0783j247Gtk4ZWKntdtnldj+DSViOORiOmPkQJhwFjQJIdproDaGDDZaHE/quypD3ApD kIqAVQRcNtjotXEpBiXdvL4VPh87wLvtgrMWbqid/wcOswHJa/x2yG6FIYBrF8ePg/nn lyiQ== 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=9oimjYOe9EF36DaYSgrUybxQBfuAzI/rZ8UDOZaXGno=; b=RQeWInbgVyfJjDhimgD9pn7KnhrA/bJ3tUeH2j/++2/FrvttpAhIrDKdVm/VG2mP1o 05CHvqjGwRNV1DdYo0dBDZY8XT5g9msV1pptEjW1tLlBLrjNqbHEbi+Vxt/9Awrq5M8M aRvZNCsKmrLVcamaKseYJJ7mGZ2J9E7ceFtjERruMkp6cyk35WSSJy4nSX9ssYrsWTLh itZZmp77kGKDv3hIgYRJpUVA0DeetACHWo8pm0YfsXj5o0tfvrSzsd5WxYcaSthToEwD fXHUXMCyrBib6+PzQD297smNkKuQBFl1zvp75aA21jNJFe5j7AHF2HieptOdVLPxFG4W t3cA== X-Gm-Message-State: AMke39nigz545mqfjRuwZRATnDhHwiLwUIanBjYrWvuyQytjVBnUohT9I1TFmZh9gwwPW85MoLDvmDGVmLvxUg== X-Received: by 10.157.82.13 with SMTP id e13mr1665918oth.50.1487548764909; Sun, 19 Feb 2017 15:59:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.70.137 with HTTP; Sun, 19 Feb 2017 15:59:24 -0800 (PST) From: Chuck Tuffli Date: Sun, 19 Feb 2017 15:59:24 -0800 Message-ID: Subject: how to map kernel memory to user space To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 23:59:26 -0000 I'm trying to work around a problem by mapping the data from a kernel allocated buffer into a user space application. There was a post some time back with a possible way to do this [1], but while this creates a valid buffer in the user space application, the contents is all zeros instead of containing the expected data. Is this approach not possible? Does anything obviously stick out below? TIA. --chuck rc = vm_map_lookup(&kernel_map, kaddr, VM_PROT_ALL, &entry, &obj, &pindex, &prot, &is_wired); vm_map_lookup_done(kernel_map, entry); if (rc) printf("%s: vm_map_lookup() = %d\n", __func__, rc); PROC_LOCK(p); uaddr = round_page((vm_offset_t)vms->vm_daddr + lim_max(td, RLIMIT_DATA)); PROC_UNLOCK(p); objoff = kaddr - (entry->start + entry->offset); vm_object_reference(obj); rc = vm_map_find(map, obj, objoff, &uaddr, sizeof(struct nvme_controller_data), 0, VMFS_OPTIMAL_SPACE, VM_PROT_RW, VM_PROT_RW, MAP_INHERIT_SHARE); [1] http://markmail.org/message/ph5yuonevqjhhbig From owner-freebsd-hackers@freebsd.org Mon Feb 20 07:26: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 BCCDDCE39F7 for ; Mon, 20 Feb 2017 07:26:53 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 465B11F3A; Mon, 20 Feb 2017 07:26:53 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id z127so45141715lfa.2; Sun, 19 Feb 2017 23:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=F4bb6pin87i7RyrnUYN/8c1Dds2v8+8zcju4eCv6OJA=; b=DWzC4VV4agxsHtfXPFm6Lu9OjJr5Lqktr/W7hPKl8ZLcT7daPOqx55ZjPBYtE3ANyC 7MrPkqxSqvexDPD9f7q8hMRfMRIS2RrCabLpvYXO5yuPfKBuJ6C3FSCXQ1y/AxYqV8h3 TaxPIeO5rpLK/NN8BFtNllgfDKp1UZ8f9ZAhS21prrvhhGTQaSO9WkXgovpjQO3Wzq/O AsjJ90EEPhmbO62jhi5xFuRnvzpsfgvjaUQSdZwZdMEygqU+K0yMvgJmCRIuw8i8fWKm CF/EW8hdf94vgdohTVunEk2Qt0IyigzWmtsDjvhfYagjZzQRWre7BoQTvlr8xcH6JFUH c2oA== 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=F4bb6pin87i7RyrnUYN/8c1Dds2v8+8zcju4eCv6OJA=; b=FJuiXnx9VJ7yuObo6o7BhMi0ou/iwuvvpEH9SoDGffXc2PQOBDKWcEde9ahpUcLOnF sHMRONWmE7lmydaxQ4/lZ1XOIjqUn3tMuVll0fAJIJg2V+YuNJH/duUMHStBEBJscUD2 JKlIUZL+qc4TQedOTYMjKazOAyq1wDE2nQzo1MbVYxwgVKvhstjjqGxuN2AOVLr/LpQ7 41+0A2Kj1C1xhJvK3j1F2cwTswXUJ4QoeXIhUxGDpQrYYGFVyxNndvJDWOR2rUtt+EWc Wwxsali3LJ9Xe62aTuPGhMpElYQArTnum6rI6k12pXkRpAxZ6NhrF9RdIEwEKwYiMjQL /2vQ== X-Gm-Message-State: AMke39mtHjkvnkvZNtdUt0FZkUQ0p7aqKM1RiJciG/jnty/QOZrZnQNxNJHFB84wVpd4CRHc2DVm+On3k88Atw== X-Received: by 10.25.74.196 with SMTP id x187mr5511009lfa.30.1487575611234; Sun, 19 Feb 2017 23:26:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.27.84 with HTTP; Sun, 19 Feb 2017 23:26:20 -0800 (PST) From: Gleb Popov <6yearold@gmail.com> Date: Mon, 20 Feb 2017 10:26:20 +0300 Message-ID: Subject: FreeBSD CARP load balancing. To: freebsd-hackers Cc: bz@freebsd.org, glebius@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: Mon, 20 Feb 2017 07:26:53 -0000 I've found that somewhere during FreeBSD 10 development CARP was substantially rewritten ( https://svnweb.freebsd.org/base?view=revision&revision=228571 ). As a result of this, CARP lost its load balancing feature. Had it been removed intentionally, or just due to lack of resources? Is there a plan to add it back? From owner-freebsd-hackers@freebsd.org Mon Feb 20 08:04:46 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 4F271CE59A9; Mon, 20 Feb 2017 08:04:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (springbank.echomania.com [IPv6:2a01:7c8:aab2:81::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "springbank.echomania.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19FA61FFB; Mon, 20 Feb 2017 08:04:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [IPv6:2001:7b8:3a7::5dae:1b25:2f6c:febe] (unknown [IPv6:2001:7b8:3a7:0:5dae:1b25:2f6c:febe]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 96422580298; Mon, 20 Feb 2017 09:04:41 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7D3D6DB7-7781-4459-A875-8799B528DFCB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: elf_load_section problem Date: Mon, 20 Feb 2017 09:04:35 +0100 In-Reply-To: <20170219203015.GA83765@troutmask.apl.washington.edu> Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20170219203015.GA83765@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3259) 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, 20 Feb 2017 08:04:46 -0000 --Apple-Mail=_7D3D6DB7-7781-4459-A875-8799B528DFCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2017, at 21:30, Steve Kargl = wrote: >=20 > Looks like I picked the wrong time to update a month old. >=20 > Problem #1: 'kldload -v i915kms.ko' locks up the system. No > panic. No messages logged. No keyboard response. Black > screen of death. >=20 > Problem #2: 'kldload -v drm2.ko' locks up the system. No panic. > No messages logged. No keyboard response. Black screen of death. >=20 > Problem #3: #1 and #2 along with an update of xorg to 1.18.4 > prevents X from firing up. >=20 > Problem #4: Ok. I re-install everything that X uses and their > dependencies from source. I can't help you with these... > =3D=3D=3D> Building for help2man-1.47.4 > elf_load_section: truncated ELF file > Abort trap but this looks like a half-written or empty file. Did you do a full fsck, and did you already try cleaning out your work directory? -Dimitry --Apple-Mail=_7D3D6DB7-7781-4459-A875-8799B528DFCB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAliqoxkACgkQsF6jCi4glqPDuACeOtxNnAnRJNRnNk3o0K0ayheE R84An0i7ds8PnPJSwKEh9USy1j192peV =haLK -----END PGP SIGNATURE----- --Apple-Mail=_7D3D6DB7-7781-4459-A875-8799B528DFCB-- From owner-freebsd-hackers@freebsd.org Mon Feb 20 09:01:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1CB0CDBF1D for ; Mon, 20 Feb 2017 09:01:09 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A2551CE0 for ; Mon, 20 Feb 2017 09:01:09 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22d.google.com with SMTP id c85so72166115wmi.1 for ; Mon, 20 Feb 2017 01:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=d6+uKJaVCC6QRsM0kADWTeEIdWlvEvD4DMMXQQSBw3E=; b=FyTiwQejbD7jvKyu5ZgNFjBNkw8SmXU1CSN89Ff0FAee2oJS33IDd7knP98ySPz9cK 6J9W9r192sCFXyxL06FWaQhMbyZ4hyKd4o6ef1JkgJp3GZb2laBnMq6Ocf32o8XuBt86 FPmIv3ZNrkMpdlJz9TJ9nJxOrS+S1VeF6ulqrnWfEjsbeHhl2mAAZMkFM5ifOm3m9OgY LUJkuhD4roubg7hQ7FTFha3pf8Fd6Swg6vgh3osF6N9DhjEVblXQUqQ3lqd/0ylg9Zvp vVji0ZqGGi7ZfadfEzd2CNs1BQsRmXOM+8o1XdxxuSPWJkyMT+bUMGsvJOgJPsZtGYb/ adUQ== 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=d6+uKJaVCC6QRsM0kADWTeEIdWlvEvD4DMMXQQSBw3E=; b=P05o4GlVqjqrUqUToXxz2VYOTZ4Smu4cW9DnAP7gDTuTazKDvqiHUs3snwYsxLbdsz BzVd67pQujqD293vtHb7chQCTFHQ2IHzbh9QG12/fVRIV8Cx6eoYphJkjhVHz9/jFk5p kNrGIWMKBvieRZtjjCGyerTU9eEO+u4NtjORiK1F1K77GttzH9P4EVgpeA/5sXbWI1I3 asJJ5+9h2xP1fVK7QCKvRZUKyfPE3c3w1PYC4z85TQZUtPc5gJWL4xOxrNLoAH7jiiGK oraUta/1qc72Rz03KiP6pqZHIwwA54Zz1SlkgxSuqZp+df+ezh6+u5nVamYAT1cPFXqc yc4A== X-Gm-Message-State: AMke39kdyBFtg0aY5WHCgRzIF1QeMDT3zObxmrV2E/xOCtbZu9jP1Ucb0kous1spZw7VTe70 X-Received: by 10.28.132.2 with SMTP id g2mr17187340wmd.103.1487581267124; Mon, 20 Feb 2017 01:01:07 -0800 (PST) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id d75sm8442421wmd.25.2017.02.20.01.01.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 01:01:06 -0800 (PST) Subject: Re: FreeBSD CARP load balancing. To: freebsd-hackers@freebsd.org References: From: Steven Hartland Message-ID: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> Date: Mon, 20 Feb 2017 09:01:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: 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: Mon, 20 Feb 2017 09:01:09 -0000 Does LAGG do what you need? On 20/02/2017 07:26, Gleb Popov wrote: > I've found that somewhere during FreeBSD 10 development CARP was > substantially rewritten ( > https://svnweb.freebsd.org/base?view=revision&revision=228571 ). As a > result of this, CARP lost its load balancing feature. Had it been removed > intentionally, or just due to lack of resources? Is there a plan to add it > back? > _______________________________________________ > 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 Mon Feb 20 10:09:16 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 DD4BACE5036 for ; Mon, 20 Feb 2017 10:09:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DAA41FF6 for ; Mon, 20 Feb 2017 10:09:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v1KA99WK022953 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 12:09:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v1KA99WK022953 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v1KA9849022952; Mon, 20 Feb 2017 12:09:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Feb 2017 12:09:08 +0200 From: Konstantin Belousov To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org Subject: Re: how to map kernel memory to user space Message-ID: <20170220100908.GA2092@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: Mon, 20 Feb 2017 10:09:17 -0000 On Sun, Feb 19, 2017 at 03:59:24PM -0800, Chuck Tuffli wrote: > I'm trying to work around a problem by mapping the data from a kernel > allocated buffer into a user space application. There was a post some > time back with a possible way to do this [1], but while this creates a > valid buffer in the user space application, the contents is all zeros > instead of containing the expected data. Is this approach not > possible? Does anything obviously stick out below? TIA. You generally cannot map arbitrary kernel data into userspace and expect things not to break. We have shm_map(9)/shm_unmap(9) functions which allow to map posix shared object into the KVA. Userspace would map object by a file descriptor, either allocated by userspace and then passed to kernel, or allocated by kernel and returned to userspace. In any case, such setup requires coordination between kernel and userspace, and using a specific memory for this to work. Code below is not functional. > > --chuck > > rc = vm_map_lookup(&kernel_map, kaddr, VM_PROT_ALL, > &entry, &obj, &pindex, > &prot, &is_wired); > > vm_map_lookup_done(kernel_map, entry); > if (rc) printf("%s: vm_map_lookup() = %d\n", __func__, rc); > > PROC_LOCK(p); > uaddr = round_page((vm_offset_t)vms->vm_daddr + lim_max(td, RLIMIT_DATA)); > PROC_UNLOCK(p); > > objoff = kaddr - (entry->start + entry->offset); > > vm_object_reference(obj); > rc = vm_map_find(map, > obj, > objoff, > &uaddr, > sizeof(struct nvme_controller_data), > 0, > VMFS_OPTIMAL_SPACE, > VM_PROT_RW, > VM_PROT_RW, > MAP_INHERIT_SHARE); > > [1] http://markmail.org/message/ph5yuonevqjhhbig > _______________________________________________ > 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 Mon Feb 20 13:22:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4366FCE5405 for ; Mon, 20 Feb 2017 13:22:04 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from mail.tomoyat1.com (tomoyat1.com [133.130.119.65]) (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 1A25011F4; Mon, 20 Feb 2017 13:22:03 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from tomoyat1.com (60-56-201-126f1.shg1.eonet.ne.jp [60.56.201.126]) by mail.tomoyat1.com (Postfix) with ESMTPSA id E1BB68D2F; Mon, 20 Feb 2017 13:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tomoyat1.com; s=tomoyat1; t=1487596511; bh=f1BOTY34dch7diIM/o1qV3FL7WHj+6gAKdL5+EUSPXw=; h=Date:From:To:Cc:Subject:Message-ID:From:Sender:To:CC:Subject: Message-Id:Date; b=Kw4WLxdF64HGafaS6VJ2cDJrcTv9/OPUcgpniIvcbYooiO2DIG2ESjlRVGaG9J6HZ pfZ266tp/6LqSNpzvwJuzAjRF8K25WY2vXi+p0M4kMDmvcTpW7Lf/mo8RTkclpZRqe t6mP/PVEl9ZLR1tfCTzvtpPWgk3mJNZgqd/qiy+A= Date: Mon, 20 Feb 2017 22:15:09 +0900 From: Tomoya Tabuchi To: freebsd-hackers@freebsd.org Cc: allanjude@freebsd.org Subject: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170220131509.GA31623@tomoyat1.com> Mail-Followup-To: freebsd-hackers@freebsd.org, allanjude@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-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, 20 Feb 2017 13:22:04 -0000 Hello, I am interested in doing a GSoC project this year with the idea "Write a new boot environment manager" on the ideas list. (https://wiki.freebsd.org/SummerOfCodeIdeas#Write_a_new_boot_environment_manager) I would like to ask a few questions involving this. First, is there a particular reason why this project is listed in the ideas list? Aside the fact the current implementation in sh is rather complicated, I was unable to come up with a reason to justify the reimplementation. Second, is making the new implmentation of beadm(1) platform independent and promoting it across the various OpenZFS implmentation / communities as some sort of "standard" implmentation a good idea, or is it over-zealous / outside of the project scope / intrusive to other projects. As for a late self introduction, my name is Tomoya Tabuchi, and I am a undergraduate student at Doshisha University in Japan. I will start my third year in university in April. Regards, Tomoya From owner-freebsd-hackers@freebsd.org Mon Feb 20 13:49: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 78DE9CE5AE8 for ; Mon, 20 Feb 2017 13:49:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 3CAFA1CF9; Mon, 20 Feb 2017 13:49:19 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cfoL0-0006uz-HH; Mon, 20 Feb 2017 16:49:10 +0300 Date: Mon, 20 Feb 2017 16:49:10 +0300 From: Slawa Olhovchenkov To: freebsd-hackers@freebsd.org, allanjude@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170220134910.GC15630@zxy.spb.ru> References: <20170220131509.GA31623@tomoyat1.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170220131509.GA31623@tomoyat1.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 20 Feb 2017 13:49:19 -0000 On Mon, Feb 20, 2017 at 10:15:09PM +0900, Tomoya Tabuchi wrote: > Hello, > > I am interested in doing a GSoC project this year with the idea "Write a > new boot environment manager" on the ideas list. > (https://wiki.freebsd.org/SummerOfCodeIdeas#Write_a_new_boot_environment_manager) > > I would like to ask a few questions involving this. > First, is there a particular reason why this project is listed in the > ideas list? Aside the fact the current implementation in sh is rather > complicated, I was unable to come up with a reason to justify the > reimplementation. > > Second, is making the new implmentation of beadm(1) platform independent > and promoting it across the various OpenZFS implmentation / communities > as some sort of "standard" implmentation a good idea, or is it > over-zealous / outside of the project scope / intrusive to other > projects. > > As for a late self introduction, my name is Tomoya Tabuchi, and I am a > undergraduate student at Doshisha University in Japan. I will start my > third year in university in April. Don't know about link above. For me, current beadm have some leaks: 1. Don't check cosistency before applay: I am try to enable beadm on 10.1 install and switch to 11.0. fail. 2. Need to control what put under beadm. All of this don't need to rewrite all beadm, IMHO. From owner-freebsd-hackers@freebsd.org Mon Feb 20 18:09: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 D0983CE6A18; Mon, 20 Feb 2017 18:09:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A765318AE; Mon, 20 Feb 2017 18:09:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1KI9i6P089031 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 10:09:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1KI9ivc089030; Mon, 20 Feb 2017 10:09:44 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2017 10:09:44 -0800 From: Steve Kargl To: Dimitry Andric Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: elf_load_section problem Message-ID: <20170220180944.GA89000@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170219203015.GA83765@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Mailman-Approved-At: Mon, 20 Feb 2017 18:26:14 +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: Mon, 20 Feb 2017 18:09:51 -0000 On Mon, Feb 20, 2017 at 09:04:35AM +0100, Dimitry Andric wrote: > On 19 Feb 2017, at 21:30, Steve Kargl wrote: > > ===> Building for help2man-1.47.4 > > elf_load_section: truncated ELF file > > Abort trap > > but this looks like a half-written or empty file. Did you do a full > fsck, and did you already try cleaning out your work directory? > Yes, I did. It seems that the perl5.24 port was damaged during one of the black screens of death events. Removing perl5.24 and re-installing seems to have fixed the help2man problem. I can 'kldload joy.ko'. If I try to load any of drm.ko, drm2.ko, or i915kms.ko. Instant lock-up. I have no idea how to get any more information about the lock-up. This laptop, Dell Latitude D530, has worked very well with FreeBSD with sources from Jan 31th and earlier. Something in the last month has been broken. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Mon Feb 20 19:08:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28D67CE6D98 for ; Mon, 20 Feb 2017 19:08:00 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A38441BD9 for ; Mon, 20 Feb 2017 19:07:59 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id z127so53913307lfa.2 for ; Mon, 20 Feb 2017 11:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O17ytpVF5W4XiwN/LqPT+jSNpx9gTU+eLCVkL/baRXE=; b=ctrgZQ8ovc1oWZxU+4jhB3Ld2iXwpsUiTUgA5qF2KqVgehqPK99hAgmEHeVgBA1VWv ys0lA3kKqtZO5g9PIqWXdW6rEyjfQ4rNWmmL3bOoPjf9i7NZlLJVOUHxXqKdziTwimjp SZkB2qad92BosFlMsiOiRit4nt63QHRmH79Rn2xvXr8hXalR40UU7cYfKVVlQypk0TGw +HKTjoHoRcIqtRg6z+iUoQdvGPfr3kT8DoR2dfMTeuv32fClwoRriOYrYGDk8amFLeJJ RT2M9Eh1JhxUIcSKA7M9KJ7WHlqJiatH8PsA8MO7w+CQIKToMnOKBSRAsdm6cGsoknnW wLTg== 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=O17ytpVF5W4XiwN/LqPT+jSNpx9gTU+eLCVkL/baRXE=; b=gBs5J4rShGoth9IZvxHuNoLnbCFZajGC2t3ezy0oYvi1e9lv5q4CStUiTnot2ODgFr 1H6pt5/zDn49e8PBEMXe/YaMn8YsbMQPIS3uXNHfwA22F3EZdTKhnOShhLWAMin0JQ3J 7lwQkwYEQSpc/Nl1hT8SZgvn13RnPHWyPwAy9hP/w6iX5oOWLANa9sBxAXF6GEOy0OVK TV8FNaLESdtnwI3JDZnhqLlaYXpZyIu3ht8XWWnV0dbYKyA32nytlqi1A9utBpO/Q4tq v0mvGefLbd1bQsbXrNvNbURhMliw9Uf1BOfUtGd0wH3XwcX4udCtt+CndUvKIenn5jPN 6WUA== X-Gm-Message-State: AMke39lUtAwqAbiXjM1nw7JYqPQOrUTmFHYmb8NQnYnxvgxy3ax6S/wAtcPjAppUfTOuVkTvD14Ar/jE97xing== X-Received: by 10.25.216.3 with SMTP id p3mr6232673lfg.16.1487617677630; Mon, 20 Feb 2017 11:07:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.27.84 with HTTP; Mon, 20 Feb 2017 11:07:27 -0800 (PST) In-Reply-To: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> From: Gleb Popov <6yearold@gmail.com> Date: Mon, 20 Feb 2017 22:07:27 +0300 Message-ID: Subject: Re: FreeBSD CARP load balancing. To: Steven Hartland Cc: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 19:08:00 -0000 On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland wrote: > Does LAGG do what you need? Doesn't seem so. I need to balance incoming traffic between several hosts. If I understood it correctly, lagg can be used to load-balance outgoing traffic only. > > On 20/02/2017 07:26, Gleb Popov wrote: > >> I've found that somewhere during FreeBSD 10 development CARP was >> substantially rewritten ( >> https://svnweb.freebsd.org/base?view=revision&revision=228571 ). As a >> result of this, CARP lost its load balancing feature. Had it been removed >> intentionally, or just due to lack of resources? Is there a plan to add it >> back? >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Feb 20 19:16:33 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 51392CE624C for ; Mon, 20 Feb 2017 19:16:33 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE4D61445 for ; Mon, 20 Feb 2017 19:16:32 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x236.google.com with SMTP id 35so29553127wrw.0 for ; Mon, 20 Feb 2017 11:16:32 -0800 (PST) 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=un9FVdQL65onyoeVZX100yyD7jSMBsV/0TxJIh4fldI=; b=dt4s13ozqiaXKXI5y39aelWzeYDX7JqfRWRJC2Rltk37DjC98M8FguqtN7rJ9Cldd+ UovvVOI2rZgFCiT06MRRor5gYNp6unGCbvzzLUXyhy82uAvOULVeCcanXRzPFR85pvFX 4cIwf4+fIrh1MJHixzu65oFf4HnZ8TVlfP/4gHmxwhAUk0pu4fMwqSCsEjqKzLun3nNY GDArLB+LjxJDYMzIlBsGjeF96u624e40G7PV15Ln0hJ3X0unbLTOcIElLWxc+9qtB9sy q0TTe7C987w57jT9+nJNU/jpSMYZBhtrOJzhPgM9K1gRNxDkaAf1lM+iE2GR4Fy24QoM 72PA== 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=un9FVdQL65onyoeVZX100yyD7jSMBsV/0TxJIh4fldI=; b=HBoRO++wQ3KVARlbcSKw8tcU6Bvohk88UMQq+XiXbvYlj/pgl+c9yZVMy2ZAFZUbDn UzaNttXICwcAdf3AMoqNe73ShDV2ZNl3oZmjzSKR9jvU8Gl/7phIzFqRg2fPJQHSMuwL BMGoCi7j/d1iq+XYA/q9w+TL5pYGqPUCrlzMNI+oe0t3a8gHkDQ2yzydcBrWzY0dx8sh zBlxyL7Hh4I7Ts6fG/n2N6nlw7jhZt2WWABBulySKZZzgzZqFSN5sQFq4Yj61nZSqX8c IXBA8It6QRVDh+byj+lVrwyg92UFiDTwSaDMGrfdFmmQ5zgF56mXro5RHHAnQCfDJWBq K6ow== X-Gm-Message-State: AMke39kZjHrggg6fif6SzN8e5nxea8xkDv0W0sCbLUBK1OM7HXnoSGdPR6+zSCsSjabVEnhd X-Received: by 10.223.139.90 with SMTP id v26mr15789881wra.143.1487618191154; Mon, 20 Feb 2017 11:16:31 -0800 (PST) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id m83sm14615097wmc.33.2017.02.20.11.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 11:16:30 -0800 (PST) Subject: Re: FreeBSD CARP load balancing. To: Gleb Popov <6yearold@gmail.com> References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> Cc: freebsd-hackers From: Steven Hartland Message-ID: Date: Mon, 20 Feb 2017 19:16:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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: Mon, 20 Feb 2017 19:16:33 -0000 On 20/02/2017 19:07, Gleb Popov wrote: > > On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland > > wrote: > > Does LAGG do what you need? > > > Doesn't seem so. I need to balance incoming traffic between several > hosts. If I understood it correctly, lagg can be used to load-balance > outgoing traffic only. LAGG does incoming and outgoing but only on a single host, so it does sound like it won't help you. That said what your doing does sound quite out of the ordinary, is there a reason you're trying to copy the traffic to multiple hosts? Might be a good idea to explain exactly what your trying to achieve. Regards Steve From owner-freebsd-hackers@freebsd.org Mon Feb 20 19:56: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 52EBBCE6EC7 for ; Mon, 20 Feb 2017 19:56:29 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC4068ED for ; Mon, 20 Feb 2017 19:56:28 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id 89so65777276wrr.3 for ; Mon, 20 Feb 2017 11:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0C6Hcqcc9G25WyGJ1b0M5DP6xuCNn8tvYIn/hkh68Nc=; b=p7LV/5AvcrSgLc5jemmaQIkCt6QYLpcjgiTPC12V13uygyBfnFswXCk6ECyO/Lqd5C Je2QMixuNIkP3VR7K9RD2bhP9kiNZM/Eh3VkI7oH8SNaKPTXkZ+2hi2brapP3YEtBsKf ADD0l0GWT3G70oeBktonN4FtknzJq/bhy8pw+nYTcwiTYSCI+e4oSy10LcZzshYEFE+/ IWavRSXLmMgXfDebrqZEBp9eqLD74Jz2l681mlnfsknS6bjacwb3q+08laAkO2gQSEDT oW5kSkEXlWpSq8XKa/hSUwmVR9z8feILE95NbrxzIvpXB6BNSZ77FfDpnkpoDVYJYyk0 pZjw== 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=0C6Hcqcc9G25WyGJ1b0M5DP6xuCNn8tvYIn/hkh68Nc=; b=gBJbczBH1LLK6Haw10bn00xpxJWWsNjW/Z98KSIYHi23J3TwBwP5V5a/6PQ2sWdVE/ qtYxllPY2BsufMxp782ad/FsYEOJoN1q43fJqqLwM9Amei0IX6OcQbZcNXgBCG+tM2wz EM4z0f5Rdh1MGRerz/PFsB7oCTUDX/HIFzmgJ11CEEXHKZFLh3OMDsSQb+FEBPtax2ii jMe5C3Tr+YFzxa2IDdLxYNo8M0YBiV0scGJqeMXc3KHsPY2iDtDppcF9EWj5C+cF+PoU d+9y5U97FYUzh8Jys0ng9aBZtiQ5dkjjh0zwcCjvw8DzXQBO3b/yaby2pVFS8d+JaOP9 EIOw== X-Gm-Message-State: AMke39nkJv1HawcjkrEYZknnLg+30cN839UCzDXXTzS5BKccgVfk72XSej0wRq/5KVxDJtg2sAXPIIBIqMgfxQ== X-Received: by 10.223.164.210 with SMTP id h18mr5220756wrb.17.1487620586636; Mon, 20 Feb 2017 11:56:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.65 with HTTP; Mon, 20 Feb 2017 11:56:26 -0800 (PST) In-Reply-To: References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> From: Adam Vande More Date: Mon, 20 Feb 2017 13:56:26 -0600 Message-ID: Subject: Re: FreeBSD CARP load balancing. To: Gleb Popov <6yearold@gmail.com> Cc: Steven Hartland , freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 19:56:29 -0000 On Mon, Feb 20, 2017 at 1:07 PM, Gleb Popov <6yearold@gmail.com> wrote: > On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland > > wrote: > > > Does LAGG do what you need? > > > Doesn't seem so. I need to balance incoming traffic between several hosts. > If I understood it correctly, lagg can be used to load-balance outgoing > traffic only. > What kind of traffic? Like HTTP? www/pound or net/haproxy may be what you are looking for. It's difficult to tell with such a sparse description. -- Adam From owner-freebsd-hackers@freebsd.org Mon Feb 20 20:17:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F375ACE6577 for ; Mon, 20 Feb 2017 20:17:23 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A367414E2 for ; Mon, 20 Feb 2017 20:17:22 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v1KK3txp074097 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 20 Feb 2017 21:03:56 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: sa and mpt in FreeBSD 11.0-RELEASE-p2 Message-Id: Date: Mon, 20 Feb 2017 21:04:11 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Mon, 20 Feb 2017 21:03:56 +0100 (CET) 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, 20 Feb 2017 20:17:24 -0000 A machine, recently upgraded from 8.4 to FreeBSD 11.0-RELEASE-p2 seems = to have lost pretty much any and all performance on mpt(4) with its = attached tape drives Read performance is around 50Mbyte/second - and write a paltry = 100-200kbyte/second (and occasionally hitting 800kbyte/second) (from/to = memory disk&/dev/null; no risk of shoe shining, compression off). SCSI bus looks happy; with no kernel messages. Output of the DLT script = below. Normal LTO drives in a tape robot, G9 server; pretty much all SAS = *except* for a U320 to tape drive with the performance issue. Active = terminator. Does this ring a bell with anyone? Was anything changed in either the sa = or mpt driver since 8.x ?=20 One odd thing is that a 'dd(1)' -without- a block size (compression is = off, data is a prepared urandom file on md disk) writes much faster -- = while on 8.x one -had- to use a sane blockwise to get the 'normal' speed = of around 120Mbyte/second. Could it be that one needs to fiddle with = MAXPHYS (which AFAIK is a readonly sysctl). Dw. DLT / http://www.freebsddiary.org/tape-testing.php READING Corrected errors with substantial delay: 0 Corrected errors with possible delay : 0 Total errors : 0 Total errors corrected : 0 Total times correction algorithm used : 0 Total bytes processed : 8590352388 Total corrected errors / GB : 0 Total uncorrected errors : 0 Read compression ratio : 101% On tape Mbytes read : 2 On tape kbytes read residual : 329320 WRITING Corrected errors with substantial delay: 154 Corrected errors with possible delay : 0 Total errors : 0 Total errors corrected : 0 Total times correction algorithm used : 168 Total bytes processed : 4909148037124 Total corrected errors / GB : 0 Total uncorrected errors : 0 Write compression ratio : 99% Host requested Mbytes written : 1442 Host requested kbytes written residual : 115996 On tape Mbytes written : 1443 On tape kbytes written residual : 0 camcontrol devlist at scbus3 target 5 lun 0 (sa0,pass0) at scbus3 target 5 lun 1 (ch0,pass1) at scbus4 target 0 lun 0 (pass2,da0) at scbus6 target 0 lun 0 (pass3,da1) at scbus6 target 1 lun 0 (pass4,da2) at scbus7 target 5 lun 0 (sa1,pass5) at scbus7 target 5 lun 1 (ch1,pass6) mt rblim /dev/nsa0: min blocksize 1 byte max blocksize 16777215 bytes granularity 1 byte mt status, ostatus and errstatus Mode Density Blocksize bpi Compression Current: 0x46:LTO-4 variable 323215 disabled ---------available modes--------- 0: 0x46:LTO-4 variable 323215 0x1 1: 0x46:LTO-4 variable 323215 0x1 2: 0x46:LTO-4 variable 323215 0x1 3: 0x46:LTO-4 variable 323215 0x1 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 Drive: sa0: Serial Number: HU1027B53Y --------------------------------- Mode Density Blocksize bpi Compression Current: 0x46:LTO-4 variable 323215 disabled --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual: 0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP Last I/O Residual: 0 Last I/O Command: 0A 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 Last I/O Sense: 70 00 0B 00 00 00 00 10 00 00 00 00 47 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Last Control Residual: 0 Last Control Command: 34 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Last Control Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 From owner-freebsd-hackers@freebsd.org Mon Feb 20 20:41: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 E21D5CE6CB8 for ; Mon, 20 Feb 2017 20:41:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 A37883EB for ; Mon, 20 Feb 2017 20:41:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cfumF-000HmE-U3; Mon, 20 Feb 2017 23:41:43 +0300 Date: Mon, 20 Feb 2017 23:41:43 +0300 From: Slawa Olhovchenkov To: Steven Hartland Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers Subject: Re: FreeBSD CARP load balancing. Message-ID: <20170220204143.GD15630@zxy.spb.ru> References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 20 Feb 2017 20:41:48 -0000 On Mon, Feb 20, 2017 at 07:16:30PM +0000, Steven Hartland wrote: > On 20/02/2017 19:07, Gleb Popov wrote: > > > > On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland > > > wrote: > > > > Does LAGG do what you need? > > > > > > Doesn't seem so. I need to balance incoming traffic between several > > hosts. If I understood it correctly, lagg can be used to load-balance > > outgoing traffic only. > > LAGG does incoming and outgoing but only on a single host, so it does > sound like it won't help you. > > That said what your doing does sound quite out of the ordinary, is there > a reason you're trying to copy the traffic to multiple hosts? Just for record: multichassis lacp exist (not for FreeBSD). http://www.cisco.com/c/en/us/td/docs/ios/cether/configuration/guide/ce_mlacp.html From owner-freebsd-hackers@freebsd.org Mon Feb 20 20:56:26 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 7526DCE6FF7 for ; Mon, 20 Feb 2017 20:56:26 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4945EBB8 for ; Mon, 20 Feb 2017 20:56:25 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id v1KKuMFe014865 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 15:56:22 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id v1KKuMtX014864; Mon, 20 Feb 2017 15:56:22 -0500 (EST) (envelope-from ken) Date: Mon, 20 Feb 2017 15:56:22 -0500 From: "Kenneth D. Merry" To: Dirk-Willem van Gulik Cc: freebsd-hackers@freebsd.org Subject: Re: sa and mpt in FreeBSD 11.0-RELEASE-p2 Message-ID: <20170220205621.GA14597@mithlond.kdm.org> References: 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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 20 Feb 2017 15:56:22 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org 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, 20 Feb 2017 20:56:26 -0000 On Mon, Feb 20, 2017 at 21:04:11 +0100, Dirk-Willem van Gulik wrote: > A machine, recently upgraded from 8.4 to FreeBSD 11.0-RELEASE-p2 seems to have lost pretty much any and all performance on mpt(4) with its attached tape drives > > Read performance is around 50Mbyte/second - and write a paltry 100-200kbyte/second (and occasionally hitting 800kbyte/second) (from/to memory disk&/dev/null; no risk of shoe shining, compression off). > > SCSI bus looks happy; with no kernel messages. Output of the DLT script below. > > Normal LTO drives in a tape robot, G9 server; pretty much all SAS *except* for a U320 to tape drive with the performance issue. Active terminator. > > Does this ring a bell with anyone? Was anything changed in either the sa or mpt driver since 8.x ? > > One odd thing is that a 'dd(1)' -without- a block size (compression is off, data is a prepared urandom file on md disk) writes much faster -- while on 8.x one -had- to use a sane blockwise to get the 'normal' speed of around 120Mbyte/second. Could it be that one needs to fiddle with MAXPHYS (which AFAIK is a readonly sysctl). > What blocksize are you using? What blocksize were you using before? What application do you normally use to talk to the tape drive? One thing that did change is that I disabled I/O splitting by default in the sa(4) driver. That means that previously, you could write a 10MB block to the sa(4) character device, and it would get split up by physio(9) into a bunch of MAXPHYS-size chunks. The problem with that behavior is that you can get an error back, and not have a good indication of which block caused the problem, and how many blocks made it out to tape if a write fails. You can also have applications that think they're writing large blocks, but in reality aren't actually doing that. The application doesn't have control of what size block is going to tape. Now, you can't write more than the lowest common denominator supported by MAXPHYS, the controller and the tape drive. This lets the application see on a block by block basis what succeeded and what failed. It also gives the application control of the blocksize, up to the limit supported by the configuration. You can see what is possible with your current configuration by doing a 'mt status -v'. For example: # mt status -v Drive: sa0: Serial Number: 101300520A --------------------------------- Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual: 0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP --------------------------------- Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes This particular machine has an LTO-5 attached via a Qlogic FC controller, and MAXPHYS is set to 1024*1056 (just over 1MB) in the kernel config file. If you want to re-enable I/O splitting (which I should have disabled by now), you can set the following loader tunable in /boot/loader.conf: kern.cam.sa.allow_io_split=1 Then reboot and re-run your test and see if the performance is any different. If so, you probably want to look at the blocksize you're using, and bump up MAXPHYS in your kernel configuration to a larger value. > Dw. > > DLT / http://www.freebsddiary.org/tape-testing.php > READING > Corrected errors with substantial delay: 0 > Corrected errors with possible delay : 0 > Total errors : 0 > Total errors corrected : 0 > Total times correction algorithm used : 0 > Total bytes processed : 8590352388 > Total corrected errors / GB : 0 > Total uncorrected errors : 0 > Read compression ratio : 101% > On tape Mbytes read : 2 > On tape kbytes read residual : 329320 > WRITING > Corrected errors with substantial delay: 154 > Corrected errors with possible delay : 0 > Total errors : 0 > Total errors corrected : 0 > Total times correction algorithm used : 168 > Total bytes processed : 4909148037124 > Total corrected errors / GB : 0 > Total uncorrected errors : 0 > Write compression ratio : 99% > Host requested Mbytes written : 1442 > Host requested kbytes written residual : 115996 > On tape Mbytes written : 1443 > On tape kbytes written residual : 0 > > camcontrol devlist > > at scbus3 target 5 lun 0 (sa0,pass0) > at scbus3 target 5 lun 1 (ch0,pass1) > at scbus4 target 0 lun 0 (pass2,da0) > at scbus6 target 0 lun 0 (pass3,da1) > at scbus6 target 1 lun 0 (pass4,da2) > at scbus7 target 5 lun 0 (sa1,pass5) > at scbus7 target 5 lun 1 (ch1,pass6) > > mt rblim > /dev/nsa0: > min blocksize 1 byte > max blocksize 16777215 bytes > granularity 1 byte > > mt status, ostatus and errstatus > > Mode Density Blocksize bpi Compression > Current: 0x46:LTO-4 variable 323215 disabled > ---------available modes--------- > 0: 0x46:LTO-4 variable 323215 0x1 > 1: 0x46:LTO-4 variable 323215 0x1 > 2: 0x46:LTO-4 variable 323215 0x1 > 3: 0x46:LTO-4 variable 323215 0x1 > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 Residual Count 0 > > > Drive: sa0: Serial Number: HU1027B53Y > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x46:LTO-4 variable 323215 disabled > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > Flags: BOP What does 'mt status -v' show? That will show you the maximum blocksize that you can effectively send to the device. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-hackers@freebsd.org Mon Feb 20 23:52: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 6079DCE5090; Mon, 20 Feb 2017 23:52:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9557CA; Mon, 20 Feb 2017 23:52:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1KNqOsR091219 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 15:52:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1KNqONp091218; Mon, 20 Feb 2017 15:52:24 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2017 15:52:24 -0800 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: drm2, i915kms cause instant lock-up Message-ID: <20170220235224.GA91194@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) 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, 20 Feb 2017 23:52:25 -0000 With a kernel and world from r313943 sources (circa Feb 19, 2017), kldload of either drm2.ko or i915kms.ko will lock up the system. There is no keyboard response, screen output, or panic. Just a locked up system. A kernel from r313027 and its modules boots fine. 'kldload drm2.ko' yields the following in /var/log/messages: agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory info: [drm] Initialized drm 1.1.0 20060810 'kldload drm2.ko' yields the following in /var/log/messages: drmn0: on vgapci0 intel_iicbb0 on drmn0 iicbus0: on iicbb0 addr 0xf2 iic0: on iicbus0 iicbus1: on intel_gmbus0 iic1: on iicbus1 intel_iicbb1 on drmn0 iicbus2: on iicbb1 addr 0xf2 iic2: on iicbus2 iicbus3: on intel_gmbus1 iic3: on iicbus3 intel_iicbb2 on drmn0 iicbus4: on iicbb2 addr 0xf2 iic4: on iicbus4 iicbus5: on intel_gmbus2 iic5: on iicbus5 intel_iicbb3 on drmn0 iicbus6: on iicbb3 addr 0xf2 iic6: on iicbus6 iicbus7: on intel_gmbus3 iic7: on iicbus7 intel_iicbb4 on drmn0 iicbus8: on iicbb4 addr 0xf2 iic8: on iicbus8 iicbus9: on intel_gmbus4 iic9: on iicbus9 intel_iicbb5 on drmn0 iicbus10: on iicbb5 addr 0xf2 iic10: on iicbus10 iicbus11: on intel_gmbus5 iic11: on iicbus11 info: [drm] MSI enabled 1 message(s) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. composite sync not supported intel_sdvo_ddc_proxy397632 on drmn0 intel_sdvo_ddc_proxy397632: detached intel_sdvo_ddc_proxy397664 on drmn0 intel_sdvo_ddc_proxy397664: detached drmn0: taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] initialized overlay support info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector SVIDEO-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.SVIDEO-1 info: [drm] - kern.vt.fb.default_mode composite sync not supported fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 A diff of dmesg.boot for the good kernel and bad kernel shows --- /root/dmesg.good 2017-02-20 13:30:06.707702000 -0800 +++ /root/dmesg.bad 2017-02-20 13:42:10.271942000 -0800 @@ -2,11 +2,11 @@ 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 #3 r313027: Mon Feb 20 11:59:15 PST 2017 +FreeBSD 12.0-CURRENT #1 r313943: Sun Feb 19 09:18:03 PST 2017 root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) VT(vga): text 80x25 -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd @@ -15,7 +15,7 @@ VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) -avail memory = 3663994880 (3494 MB) +avail memory = 3665018880 (3495 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs @@ -24,7 +24,7 @@ ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 -module_register_init: MOD_LOAD (vesa, 0xc0bf7440, 0) error 19 +module_register_init: MOD_LOAD (vesa, 0xc0ae6db0, 0) error 19 nexus0 vtvga0: on motherboard acpi0: on motherboard @@ -42,7 +42,7 @@ attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 +Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: on acpi0 pcib0: failed to parse resources: AE_AML_NO_RESOURCE_END_TAG The module_register_init difference seems suspicious. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Mon Feb 20 23:58: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 873C1CE5500; Mon, 20 Feb 2017 23:58:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7B1B72; Mon, 20 Feb 2017 23:58:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id c85so17015516wmi.1; Mon, 20 Feb 2017 15:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=k7xyikLNfEuxO+fXiDOOpKDtnzaQCMlepe4i9OyfcFI=; b=GQMZlvFhRx+wcnQblxLsqszNIJwhwC11tgRqrC4BFVLoZYOeUrSSpUjILdeOWPI585 gAVvGAYtHI9nGLzutDzpI017ksdo4Hx7EHV+Vg21IanO+Fhyap/snzcB+M67ooMvG2Wk sQ/0akiQCh/w7odyLuVqI+sTx8GteezmDVM4rM4dMbgIthiSxg+4cpA1cd/f0QoBHerH jxYwtneMxKzdTaAorUomQvEt4/1pUcFClWVKoHDlAF5yecO3tSsw0Y9hsUOMfd47vi+V O7p1VMzRbEjVsXaVZsFRD1AF8C4t6uy+byPCL92fGPD502bI8+lsqVZFLelNk7w4pKUB WXSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=k7xyikLNfEuxO+fXiDOOpKDtnzaQCMlepe4i9OyfcFI=; b=CXf9BKSawiqHlnUwIhNankjNV+Bo26dMpUEfbIx6i27gQlo77LBoj05gp+6UVy+g1M NbxNpiRWMza6l3EvSsTYkrxJK57lClqoUwpRIrS9c3Ra0H8esn74EeWEDhwInCfdoyBY pj9EAKjKqi3ymh7gTUTnd+IYSCg1A7bg4lTgScenBoPqy+yxa7VZaBC2h47oPYcXaalu 9QPn3smmjWA+OGGEl6aMaduWyG2lGvoV0LjPbEZkXek8GgC301l57Kq2U8shANR/1YWa r3yzAzONnAxfQVbDLYKE41dnzVfmzel45xpPkD0qPIjxALboGomeqXmDIoAMNiPsSNpd WeyA== X-Gm-Message-State: AMke39nEBpJ7usgo89gPMBtXyBpGVhxqkwSdlp6DvciI9lITqb26MPBGZHHhveSvzPAUGQ== X-Received: by 10.28.113.9 with SMTP id m9mr22654684wmc.60.1487635089598; Mon, 20 Feb 2017 15:58:09 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id o2sm26640390wra.42.2017.02.20.15.58.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 20 Feb 2017 15:58:09 -0800 (PST) Date: Tue, 21 Feb 2017 00:58:07 +0100 From: Mateusz Guzik To: Steve Kargl Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170220235807.GC26759@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Steve Kargl , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <20170220235224.GA91194@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170220235224.GA91194@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 20 Feb 2017 23:58:11 -0000 On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > With a kernel and world from r313943 sources (circa > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > will lock up the system. There is no keyboard response, > screen output, or panic. Just a locked up system. > > A kernel from r313027 and its modules boots fine. > 'kldload drm2.ko' yields the following in /var/log/messages: > There were quite a few invasive changes in this timeframe. Can you please: 1. switch to 313254 and ensure it works 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and check if it breaks If it does not break, revert the patch and bisect the kernel please. Otherwise I'll devise smaller diffs to narrow this down. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Tue Feb 21 00:02: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 C11DCCE5A4E; Tue, 21 Feb 2017 00:02:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A62661252; Tue, 21 Feb 2017 00:02:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1L02fuO091399 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 16:02:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1L02fHl091398; Mon, 20 Feb 2017 16:02:41 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2017 16:02:41 -0800 From: Steve Kargl To: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170221000241.GA91372@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170220235807.GC26759@dft-labs.eu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 21 Feb 2017 00:02:42 -0000 On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > With a kernel and world from r313943 sources (circa > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > > will lock up the system. There is no keyboard response, > > screen output, or panic. Just a locked up system. > > > > A kernel from r313027 and its modules boots fine. > > 'kldload drm2.ko' yields the following in /var/log/messages: > > > > There were quite a few invasive changes in this timeframe. Can you > please: > > 1. switch to 313254 and ensure it works > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and > check if it breaks > I'll give it a shot. It takes 30 to 60 minutes to build kernel and modules on my system. I'll post results when available. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Tue Feb 21 00:43: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 05349CE6B7C; Tue, 21 Feb 2017 00:43:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DEB09F1A; Tue, 21 Feb 2017 00:43:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1L0heQo091596 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 16:43:40 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1L0hepS091595; Mon, 20 Feb 2017 16:43:40 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2017 16:43:40 -0800 From: Steve Kargl To: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170221004340.GA91587@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170220235807.GC26759@dft-labs.eu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 21 Feb 2017 00:43:42 -0000 On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > With a kernel and world from r313943 sources (circa > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > > will lock up the system. There is no keyboard response, > > screen output, or panic. Just a locked up system. > > > > A kernel from r313027 and its modules boots fine. > > 'kldload drm2.ko' yields the following in /var/log/messages: > > > > There were quite a few invasive changes in this timeframe. Can you > please: > > 1. switch to 313254 and ensure it works > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and > check if it breaks > > If it does not break, revert the patch and bisect the kernel please. > Otherwise I'll devise smaller diffs to narrow this down. > With 1. and 2. the system boots and I can kldload both drm2 and i915kms. I revert the patch and start bisecting the kernel. Thanks for the quick response. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Tue Feb 21 00:50:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE188CE6F40; Tue, 21 Feb 2017 00:50:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8140B164B; Tue, 21 Feb 2017 00:50:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr0-x243.google.com with SMTP id 89so6996163wrr.1; Mon, 20 Feb 2017 16:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=l0PBSH/mHnJNHslH6dy9XWgM3kv3xwxxrOobqWkAOpk=; b=gFzUPzFjLf7bQ7EpZhHh9Den8QmmxmV/yH7NNbg9oEmOkQYXoFKcmNGWqn2s39Yy66 gQhLu77lXEspbKMTbuj3edzKFNduvNjs7XVjBXe2LE26YXv8iPJeW9OPMqp+Y0eoQ4u/ diUtjmWtsHnjdV1o0nbh6mawBubctVdNbQeSnyy0KU0pJyKqczs9wrrO3GwrMj3yg0Zv drh7bXSAQwms0i4h3Uz7AUdUY1PWfQWjaU9U+kFTR5STP0QFVRwqteWBPPgaEyxy4FKE q5Fu7bTgoIZpL8KmWnD26pN1zV6q5K7OaBqJym7tDFRzzjxD58c7/W8R1r5DLk8Ku8i3 gi9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=l0PBSH/mHnJNHslH6dy9XWgM3kv3xwxxrOobqWkAOpk=; b=HzgVqJ5X0KZ7/HMnfT+lkWsiQBueeIL11dpFBiA8XdGE3qikNHDCT+TQlSt11suedu 5h8cfsCou2nbagnHq71c8PPKW0InIqww5jhggqoH7YQ1EUHQuzSkNslR7rACGR56hQJJ SRMflDsnDZ39QGesHLvZdc9BXmEMw782V3+58jEm4DRY0avSXPEZmGHgBAm6euW5I4oC 3SQwsuzJKzuPV3CGLeEIvy0ykuVBoNO1zzZGL+vvuoK3pBAnnxaKbDYrPDRWmQ4O0z6v KCe/yOw/CFI0w9plLqOC1tNMP3qEenxT0PRD2erz9Z75AQQ+XphKDP4b3OyTQ1i4HG3Y vZJg== X-Gm-Message-State: AMke39lsphKPdQdDZ+4StvFZJRZ33eXSgdbtkPJuBecopxDKGH5F2o7T9ftZeCwyocbZNQ== X-Received: by 10.223.165.70 with SMTP id j6mr4377384wrb.173.1487638232848; Mon, 20 Feb 2017 16:50:32 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id y97sm15466677wmh.24.2017.02.20.16.50.32 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 20 Feb 2017 16:50:32 -0800 (PST) Date: Tue, 21 Feb 2017 01:50:30 +0100 From: Mateusz Guzik To: Steve Kargl Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170221005030.GD26759@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Steve Kargl , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170221004340.GA91587@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 21 Feb 2017 00:50:35 -0000 On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote: > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > > With a kernel and world from r313943 sources (circa > > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > > > will lock up the system. There is no keyboard response, > > > screen output, or panic. Just a locked up system. > > > > > > A kernel from r313027 and its modules boots fine. > > > 'kldload drm2.ko' yields the following in /var/log/messages: > > > > > > > There were quite a few invasive changes in this timeframe. Can you > > please: > > > > 1. switch to 313254 and ensure it works > > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and > > check if it breaks > > > > If it does not break, revert the patch and bisect the kernel please. > > Otherwise I'll devise smaller diffs to narrow this down. > > > > With 1. and 2. the system boots and I can kldload both drm2 > and i915kms. I revert the patch and start bisecting the kernel. > Thanks for the quick response. > Thanks for testing. Note you may encounter some turbulences along the road as there were fixups and fixups to fixups to the combined above patch. Good luck. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Tue Feb 21 05:27:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68B37CE637E; Tue, 21 Feb 2017 05:27:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D334AEE; Tue, 21 Feb 2017 05:27:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1L5Qwn1093429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 21:26:58 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1L5QwSU093428; Mon, 20 Feb 2017 21:26:58 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2017 21:26:58 -0800 From: Steve Kargl To: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170221052658.GA93413@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> <20170221005030.GD26759@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221005030.GD26759@dft-labs.eu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 21 Feb 2017 05:27:00 -0000 On Tue, Feb 21, 2017 at 01:50:30AM +0100, Mateusz Guzik wrote: > On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote: > > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote: > > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > > > > With a kernel and world from r313943 sources (circa > > > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > > > > will lock up the system. There is no keyboard response, > > > > screen output, or panic. Just a locked up system. > > > > > > > > A kernel from r313027 and its modules boots fine. > > > > 'kldload drm2.ko' yields the following in /var/log/messages: > > > > > > > > > > There were quite a few invasive changes in this timeframe. Can you > > > please: > > > > > > 1. switch to 313254 and ensure it works > > > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and > > > check if it breaks > > > > > > If it does not break, revert the patch and bisect the kernel please. > > > Otherwise I'll devise smaller diffs to narrow this down. > > > > > > > With 1. and 2. the system boots and I can kldload both drm2 > > and i915kms. I revert the patch and start bisecting the kernel. > > Thanks for the quick response. > > > > Thanks for testing. Note you may encounter some turbulences along the > road as there were fixups and fixups to fixups to the combined above > patch. > Well, the good news seems to be that r313254 and older are 'ok'. So, something between r313943 and r313254 is triggering a the problem. I'm still bisecting, but it might take a day or two. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Tue Feb 21 05:56: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 83640CE6DE5 for ; Tue, 21 Feb 2017 05:56:15 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 286B81A35 for ; Tue, 21 Feb 2017 05:56:15 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id b80so22307371lfe.3 for ; Mon, 20 Feb 2017 21:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/DM6QRvXkordAPASE3HfuNAWD3x/K+Ku9C9N/n6zn0=; b=C4sS2vt+x8BVVZYA9phJYsqGXzk0MpoSwwmOByd15X9Q3MRmrAzT6Uyu+lu/kb85Bv Onumr89lzwnET8A8ghO7wwNHAYG7duqMtEuDXZL2/28ELPNcrztYShCme6H500Z/KI7r ZXP9AIx91RZkXsVq6n776r4WWLpx6/MxQPqYowY+tna7dU/TL6XoqjhOqIWEwKa/1F+0 1TZWLj0K0sYCyCtEx215sTM6OtwY2fMtHfxPEw7uXlVm9XYCVa1ZUClt0bWyvGPUZJU0 sdqERLaorMCLgN6m3p3Eq9w9mobhW7yEiaXqye3hl+dUkyElhbI1M7T7XciYz2VJ948A nfRg== 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=F/DM6QRvXkordAPASE3HfuNAWD3x/K+Ku9C9N/n6zn0=; b=OPJNgOWI5KmJFeG3B3vyH7iufIM8Y5gUli/7TnfU+LKs7vy8vDd5GpzCwlu/AJ2Dgx 2PWkQFGgAFaI/Cv0mWkWbvqJX2PVSBcVzxRl/axKCrTQh6vjlbx6fAIT/1zHxBt3ZQqv yDg/BpYHijDtfx+Cvsqp2lzhW9sPmKGbw4Mlo6W28lfBw4gNXG9ESWDIkq2EqlFVtvFX uNO1fPcTVPIxN7M/p08n8EhC4SmYLFhz1fn24ghTZd3l/p7U8iXO4tt+46I9zmetc0uP STw6gozLwt0b7LnCeZRnXDI8cDyJlFX+XLu+pmsT44ub1upldOWshc9uKaI8ohWKyWig xzWA== X-Gm-Message-State: AMke39nqQhLIEAN1hFXwsRUZLxl5McTcg5Qfxks8sJxTrFXwpKRKIs+yaHqvIwuAEwn3iVbQRN/r+YMzHW5MFw== X-Received: by 10.46.88.79 with SMTP id x15mr6307790ljd.39.1487656573077; Mon, 20 Feb 2017 21:56:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.27.84 with HTTP; Mon, 20 Feb 2017 21:55:42 -0800 (PST) In-Reply-To: References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> From: Gleb Popov <6yearold@gmail.com> Date: Tue, 21 Feb 2017 08:55:42 +0300 Message-ID: Subject: Re: FreeBSD CARP load balancing. To: Steven Hartland Cc: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 05:56:15 -0000 On Mon, Feb 20, 2017 at 10:16 PM, Steven Hartland wrote: > On 20/02/2017 19:07, Gleb Popov wrote: > > > On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland > wrote: > >> Does LAGG do what you need? > > > Doesn't seem so. I need to balance incoming traffic between several hosts. > If I understood it correctly, lagg can be used to load-balance outgoing > traffic only. > > > LAGG does incoming and outgoing but only on a single host, so it does > sound like it won't help you. > > That said what your doing does sound quite out of the ordinary, > So, that *net.inet.carp.arpbalance *sysctl was out of ordinary feature? That probably explains it. is there a reason you're trying to copy the traffic to multiple hosts? > Not copy, but distribute. I just don't want to wait current CARP master die to make another computer become active, but to switch between them in some fashion (round-robin or whatever). > > Might be a good idea to explain exactly what your trying to achieve. > > Regards > Steve > From owner-freebsd-hackers@freebsd.org Tue Feb 21 06:00:43 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 2A25CCE6EDA for ; Tue, 21 Feb 2017 06:00:43 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3DE21BFB for ; Tue, 21 Feb 2017 06:00:42 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 03F1BD7E8 for ; Tue, 21 Feb 2017 06:00:35 +0000 (UTC) Subject: Re: FreeBSD CARP load balancing. To: freebsd-hackers@freebsd.org References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> From: Allan Jude Message-ID: <5b9f3663-c244-29c1-1771-d745fd0b0a98@freebsd.org> Date: Tue, 21 Feb 2017 01:00:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AopGWd3p7Xxdtc9QuV1U0rBvcnJvQj6lI" 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, 21 Feb 2017 06:00:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AopGWd3p7Xxdtc9QuV1U0rBvcnJvQj6lI Content-Type: multipart/mixed; boundary="GoNmI1XkwDgimkR68wQnh06AS1uHPEIkX"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <5b9f3663-c244-29c1-1771-d745fd0b0a98@freebsd.org> Subject: Re: FreeBSD CARP load balancing. References: <5e139f90-89c0-e4c4-46c3-457f1fd02c74@multiplay.co.uk> In-Reply-To: --GoNmI1XkwDgimkR68wQnh06AS1uHPEIkX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-02-21 00:55, Gleb Popov wrote: > On Mon, Feb 20, 2017 at 10:16 PM, Steven Hartland > wrote: >=20 >> On 20/02/2017 19:07, Gleb Popov wrote: >> >> >> On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland >> wrote: >> >>> Does LAGG do what you need? >> >> >> Doesn't seem so. I need to balance incoming traffic between several ho= sts. >> If I understood it correctly, lagg can be used to load-balance outgoin= g >> traffic only. >> >> >> LAGG does incoming and outgoing but only on a single host, so it does >> sound like it won't help you. >> >> That said what your doing does sound quite out of the ordinary, >> >=20 > So, that *net.inet.carp.arpbalance *sysctl was out of ordinary feature= ? > That probably explains it. >=20 > is there a reason you're trying to copy the traffic to multiple hosts? >> >=20 > Not copy, but distribute. I just don't want to wait current CARP master= die > to make another computer become active, but to switch between them in s= ome > fashion (round-robin or whatever). >=20 >=20 >> >> Might be a good idea to explain exactly what your trying to achieve. >> >> Regards >> Steve >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I am not sure arpbalancing every worked very well. Without a hashing algorithm or something, how would you actually make a TCP session work? --=20 Allan Jude --GoNmI1XkwDgimkR68wQnh06AS1uHPEIkX-- --AopGWd3p7Xxdtc9QuV1U0rBvcnJvQj6lI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJYq9d5AAoJEBmVNT4SmAt+WvMP/R6mGhCQiDMBUriPXJRm32TS HJJbPGY/Yhxdre7BLS/ld5XFt7exfTCwhm2UGFuhpcKdzaR8hCYsHf5/YTzwdrBW d2isQGOz3c72yR62S+N3BfxqIZNxDYI/sjOUf5olL49IbMnrphAdBcymYeXcsUCk uxuQbTmHu3Cf2JF5BGDxdD+l15zmU2m9OLPQe1A6vTRCl6qFyuNz0G0j1zvKshsZ PjXVry9dKPrC6FLDY6xMBqUzgf5NeQNzLEwMtKeVV9xfej54gwFZqtEcXLl4kPZd b2UnXhfjMKgSZM8AfB0GkBSgs2P8YKmjXYheS3YAgyHgzUzIn57I0E5x+UtHc65V 5RbW3+WxGCQxl4J6KIfvZkL2vtbhjKGtMiuCnha6se2ziw71ShsmrNq4CZ1Hss5i Kw3NGjipDw5lAt1nnAsnUbePqQFAvG88hP6vfDdas72kRetn43gSWPe+AQJZX7Vk 3YodeZi1yEv/QBTQ5ofRImHThMcdjmzUSqcEe8aSxqaoBAwiX4ZwmTC24EckSDOG 9YM8MctDQhhqHHspi7SvQENVWIp+7C+uZhJAXsS6whY3CqSmQzR9XtNkN9l3nOm8 Q1BQoZlOAgchjImKlogBHsMJWySmVLaKu55hKP6RhBwMetHndIffMTAjdJAwob7n src+wryyImLrPkw2UB2W =bJn5 -----END PGP SIGNATURE----- --AopGWd3p7Xxdtc9QuV1U0rBvcnJvQj6lI-- From owner-freebsd-hackers@freebsd.org Tue Feb 21 13:20:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4C48CE646E for ; Tue, 21 Feb 2017 13:20:09 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from mail.tomoyat1.com (tomoyat1.com [133.130.119.65]) (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 9B4231177 for ; Tue, 21 Feb 2017 13:20:09 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from tomoyat1.com (60-56-201-126f1.shg1.eonet.ne.jp [60.56.201.126]) by mail.tomoyat1.com (Postfix) with ESMTPSA id BE580176E for ; Tue, 21 Feb 2017 13:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tomoyat1.com; s=tomoyat1; t=1487683201; bh=T4q913wNbVOxYy0ZjCSo71HkcOQPqPZmzLX47e/sNNI=; h=Date:From:To:Subject:Message-ID:From:Sender:To:CC:Subject: Message-Id:Date; b=kaBtiWyu9gwxXP6/VBEBrKXwC5d/pSdd93UGAipfVAdAYAspYwJCFy8vqZDB/9msZ Y5AVvZsc520rQw6Fna1VZYp6SanW4ZAGkDOVfQrnxmNVge64SksSaQ3NwO9Gvetc/L N5TBjMhK+7nOjuQf2ce9JNR1o2Gq9KhV/3O+H1qw= Date: Tue, 21 Feb 2017 22:20:00 +0900 From: Tomoya Tabuchi To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170221132000.GA11545@tomoyat1.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170220131509.GA31623@tomoyat1.com> <20170220134910.GC15630@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170220134910.GC15630@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 21 Feb 2017 13:20:09 -0000 On Mon, Feb 20, 2017 at 04:49:10PM +0300, Slawa Olhovchenkov wrote: > On Mon, Feb 20, 2017 at 10:15:09PM +0900, Tomoya Tabuchi wrote: > > > Hello, > > > > I am interested in doing a GSoC project this year with the idea "Write a > > new boot environment manager" on the ideas list. > > (https://wiki.freebsd.org/SummerOfCodeIdeas#Write_a_new_boot_environment_manager) > > > > I would like to ask a few questions involving this. > > First, is there a particular reason why this project is listed in the > > ideas list? Aside the fact the current implementation in sh is rather > > complicated, I was unable to come up with a reason to justify the > > reimplementation. > > > > Second, is making the new implmentation of beadm(1) platform independent > > and promoting it across the various OpenZFS implmentation / communities > > as some sort of "standard" implmentation a good idea, or is it > > over-zealous / outside of the project scope / intrusive to other > > projects. > > > > As for a late self introduction, my name is Tomoya Tabuchi, and I am a > > undergraduate student at Doshisha University in Japan. I will start my > > third year in university in April. > > Don't know about link above. For me, current beadm have some leaks: > > 1. Don't check cosistency before applay: > I am try to enable beadm on 10.1 install and switch to 11.0. > fail. That is interesting. I'll try and see if I can reproduce that, and observe what's going on. > > 2. Need to control what put under beadm. Does this mean to hold back on feature bloat, or to distinguish between ZFS clones created by beadm and ones that were not? If you mean the latter, I'll take a look at the current behaviour when manually created ZFS clones are involved. > > All of this don't need to rewrite all beadm, IMHO. Thank you for your views. Tomoya From owner-freebsd-hackers@freebsd.org Tue Feb 21 14:11: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 41B12CE75D4 for ; Tue, 21 Feb 2017 14:11:51 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from mail.tomoyat1.com (tomoyat1.com [133.130.119.65]) (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 1665B132B for ; Tue, 21 Feb 2017 14:11:50 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from tomoyat1.com (60-56-201-126f1.shg1.eonet.ne.jp [60.56.201.126]) by mail.tomoyat1.com (Postfix) with ESMTPSA id B42D317DA for ; Tue, 21 Feb 2017 14:11:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tomoyat1.com; s=tomoyat1; t=1487686308; bh=gatqZjhiX/2s6jPM81Be9LWuTrV+FHb7JUFb51d+hGo=; h=Date:From:To:Subject:Message-ID:From:Sender:To:CC:Subject: Message-Id:Date; b=TANU5snOEB9uDvIPmsn64CY90VSd1YrJ9SVr14BOhblRN3Qd8SCrXvfYlzz3Wln6J ittQB999iAU9FYajGCHB9lp7rlljRIpHsbeS0SlqLZ+O16hmbcvuf5aUK6EaXQYuLh 5PEa4ZOeMOeBudjxjEOqTBQRqjvOGiYdYgVUitlw= Date: Tue, 21 Feb 2017 23:11:47 +0900 From: Tomoya Tabuchi To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170221141147.GB11545@tomoyat1.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170220131509.GA31623@tomoyat1.com> <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 21 Feb 2017 14:11:51 -0000 On Mon, Feb 20, 2017 at 12:52:03PM -0800, Jordan Hubbard wrote: > > > On Feb 20, 2017, at 5:15 AM, Tomoya Tabuchi > wrote: > > > > I would like to ask a few questions involving this. > > First, is there a particular reason why this project is listed in the > > ideas list? Aside the fact the current implementation in sh is rather > > complicated, I was unable to come up with a reason to justify the > > reimplementation. > > The current implementation of beadm is very slow and fragile - it writes to all previous boot environments when configuration changes are made which require the regeneration of config data, something which becomes slower as an O(n) property of the number of boot environments, and it does a poor job of handling any number of failure cases which can occur during this process. It provides also no “seat belts†for the pathological cases where the ZFS boot pool fills up or even approaches the 90% “storage cliff†where ZFS begins to exhibit pathological performance characteristics. I did not know about such problems. As for the part regarding the regeneration of config data. I'll look into the current implementation and see if I could come up with a better way to do things. As for the zpool approaching the "storage cliff", or filling up, it seems straightforward that a doing a usage check before each BE creation, and aborting if limits are exceeded, should suffice. I figure it will be worth searching the existing implementation for any other edge cases in need of "seat belts". > > It also provides no API other than the beadm(1) command itself, which makes it harder to control from 3rd party tools like FreeNAS (which uses beadm extensively). In order to provide an API to beadm, splitting the final product into 1. an underlying library that does the heavy lifting 2. an user-facing beadm(1) command that will make use of the library could be a solution. IIRC this is sort of like what is done in libzfs and the zfs commands. > > It’s on our (iXsystems) own long-term list of things to rewrite from scratch, but we haven’t managed to find the time or resources. If someone else wanted to do so, we’d be enthusiastic co-conspirators! Thank you! I'll do some more research, write a project proposal, and post it on this list when the time comes. I would appreciate it very much if I could then have feedback from you. > > - Jordan > > Thank you, Tomoya From owner-freebsd-hackers@freebsd.org Tue Feb 21 14:16: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 9298BCE784E for ; Tue, 21 Feb 2017 14:16:29 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 397E4174A for ; Tue, 21 Feb 2017 14:16:29 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v1LEGHuf017450 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 15:16:17 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v1LEGHaW017447; Tue, 21 Feb 2017 15:16:17 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 21 Feb 2017 15:16:17 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Tomoya Tabuchi cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) In-Reply-To: <20170221141147.GB11545@tomoyat1.com> Message-ID: References: <20170220131509.GA31623@tomoyat1.com> <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> <20170221141147.GB11545@tomoyat1.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:16:29 -0000 On Tue, 21 Feb 2017 23:11+0900, Tomoya Tabuchi wrote: > On Mon, Feb 20, 2017 at 12:52:03PM -0800, Jordan Hubbard wrote: > > > > > On Feb 20, 2017, at 5:15 AM, Tomoya Tabuchi > wrote: > > > > > > I would like to ask a few questions involving this. > > > First, is there a particular reason why this project is listed in the > > > ideas list? Aside the fact the current implementation in sh is rather > > > complicated, I was unable to come up with a reason to justify the > > > reimplementation. > > > > The current implementation of beadm is very slow and fragile - it writes to all previous boot environments when configuration changes are made which require the regeneration of config data, something which becomes slower as an O(n) property of the number of boot environments, and it does a poor job of handling any number of failure cases which can occur during this process. It provides also no “seat belts†for the pathological cases where the ZFS boot pool fills up or even approaches the 90% “storage cliff†where ZFS begins to exhibit pathological performance characteristics. > I did not know about such problems. As for the part regarding the > regeneration of config data. I'll look into the current > implementation and see if I could come up with a better way to do > things. Could beadm use ZFS user properties to distinguish between BE created by beadm, and those created manually or by other tools? > As for the zpool approaching the "storage cliff", or filling up, it seems straightforward that a doing a usage check before each BE creation, and aborting if limits are exceeded, should suffice. I figure it will be worth searching the existing implementation for any other edge cases in need of "seat belts". > > > > It also provides no API other than the beadm(1) command itself, which makes it harder to control from 3rd party tools like FreeNAS (which uses beadm extensively). > In order to provide an API to beadm, splitting the final product into > 1. an underlying library that does the heavy lifting > 2. an user-facing beadm(1) command that will make use of the library > could be a solution. IIRC this is sort of like what is done in libzfs and the > zfs commands. > > > > > It’s on our (iXsystems) own long-term list of things to rewrite from scratch, but we haven’t managed to find the time or resources. If someone else wanted to do so, we’d be enthusiastic co-conspirators! > Thank you! I'll do some more research, write a project proposal, and post it on this list when the time comes. I would appreciate it very much if I could then have feedback from you. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@freebsd.org Tue Feb 21 15:46:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3193FCE8B4E for ; Tue, 21 Feb 2017 15:46:41 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D533EFD0; Tue, 21 Feb 2017 15:46:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v1LFkdmi008296; Tue, 21 Feb 2017 07:46:39 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v1LFkdxA008295; Tue, 21 Feb 2017 07:46:39 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD CARP load balancing. In-Reply-To: <5b9f3663-c244-29c1-1771-d745fd0b0a98@freebsd.org> To: Allan Jude Date: Tue, 21 Feb 2017 07:46:39 -0800 (PST) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 21 Feb 2017 16:59:40 +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, 21 Feb 2017 15:46:41 -0000 > On 2017-02-21 00:55, Gleb Popov wrote: > > On Mon, Feb 20, 2017 at 10:16 PM, Steven Hartland > > wrote: > > > >> On 20/02/2017 19:07, Gleb Popov wrote: > >> > >> > >> On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland >>> wrote: > >> > >>> Does LAGG do what you need? > >> > >> > >> Doesn't seem so. I need to balance incoming traffic between several hosts. > >> If I understood it correctly, lagg can be used to load-balance outgoing > >> traffic only. > >> > >> > >> LAGG does incoming and outgoing but only on a single host, so it does > >> sound like it won't help you. > >> > >> That said what your doing does sound quite out of the ordinary, > >> > > > > So, that *net.inet.carp.arpbalance *sysctl was out of ordinary feature? > > That probably explains it. > > > > is there a reason you're trying to copy the traffic to multiple hosts? > >> > > > > Not copy, but distribute. I just don't want to wait current CARP master die > > to make another computer become active, but to switch between them in some > > fashion (round-robin or whatever). > > > > > >> > >> Might be a good idea to explain exactly what your trying to achieve. > >> > >> Regards > >> Steve > >> > > _______________________________________________ > > 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" > > > > I am not sure arpbalancing every worked very well. Without a hashing > algorithm or something, how would you actually make a TCP session work? 8.xish man page: ARP level load balancing The carp has limited abilities for load balancing the incoming connec- tions between hosts in Ethernet network. For load balancing operation, one needs several CARP interfaces that are configured to the same IP address, but to a different VHIDs. Once an ARP request is received, the CARP protocol will use a hashing function against the source IP address ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in the ARP request to determine which VHID should this request belong to. If the corresponding CARP interface is in master state, the ARP request will be replied, otherwise it will be ignored. See the EXAMPLES section for a practical example of load balancing. There is your hash. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Feb 21 17:15:56 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 C49B9CE8B05 for ; Tue, 21 Feb 2017 17:15:56 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C879E2D for ; Tue, 21 Feb 2017 17:15:56 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v1LHF7Ca006030 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 18:15:07 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3265\)) Subject: Re: sa and mpt in FreeBSD 11.0-RELEASE-p2 From: Dirk-Willem van Gulik In-Reply-To: <20170220205621.GA14597@mithlond.kdm.org> Date: Tue, 21 Feb 2017 18:15:06 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9A1C3971-0614-4E7C-9A99-C40346D794CB@webweaving.org> References: <20170220205621.GA14597@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.3265) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Tue, 21 Feb 2017 18:15:07 +0100 (CET) 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, 21 Feb 2017 17:15:56 -0000 > On 20 Feb 2017, at 21:56, Kenneth D. Merry wrote: >=20 > On Mon, Feb 20, 2017 at 21:04:11 +0100, Dirk-Willem van Gulik wrote: >> A machine, recently upgraded from 8.4 to FreeBSD 11.0-RELEASE-p2 = seems to have lost pretty much any and all performance on mpt(4) with = its attached tape drives >>=20 >> Read performance is around 50Mbyte/second - and write a paltry = 100-200kbyte/second (and occasionally hitting 800kbyte/second) (from/to = memory disk&/dev/null; no risk of shoe shining, compression off). >>=20 >> SCSI bus looks happy; with no kernel messages. Output of the DLT = script below. >>=20 >> Normal LTO drives in a tape robot, G9 server; pretty much all SAS = *except* for a U320 to tape drive with the performance issue. Active = terminator. >>=20 >> Does this ring a bell with anyone? Was anything changed in either the = sa or mpt driver since 8.x ?=20 >>=20 >> One odd thing is that a 'dd(1)' -without- a block size (compression = is off, data is a prepared urandom file on md disk) writes much faster = -- while on 8.x one -had- to use a sane blockwise to get the 'normal' = speed of around 120Mbyte/second. Could it be that one needs to fiddle = with MAXPHYS (which AFAIK is a readonly sysctl). >>=20 >=20 > What blocksize are you using? What blocksize were you using before? = What > application do you normally use to talk to the tape drive? Amanda (or plain DD); we increased Amanda=E2=80=99s default of 32 to 64k = (which stopped any and all shoe shining at that time. It was tested in = 2013 (so likely in FreeBSD 8) up to 16 Mbyte in factors of 2 according = to our notes - but with no further improvements in performance - and = left at 64k). The actual drive (mt status -v) reports (prior to increasing MAXPHYS) on = 11.0-p2 with default kernel config: > Drive: sa0: Serial Number: HU1027B53Y > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x46:LTO-4 variable 323215 enabled (0x1) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > Flags: BOP > --------------------------------- > Tape I/O parameters: > Maximum I/O size allowed by driver and controller (maxio): 131072 = bytes > Maximum I/O size reported by controller (cpi_maxio): 131072 bytes > Maximum block size supported by tape drive and media (max_blk): = 16777215 bytes > Minimum block size supported by tape drive and media (min_blk): 1 = bytes > Block granularity supported by tape drive and media (blk_gran): 0 = bytes > Maximum possible I/O size (max_effective_iosize): 131072 bytes =E2=80=A6. > If you want to re-enable I/O splitting (which I should have disabled = by > now), you can set the following loader tunable in /boot/loader.conf: >=20 > kern.cam.sa.allow_io_split=3D1 Ok - this changes behaviour - non-blocksized limited writes are now up; = 2Mbyte/second; any block-sized write is 200kb/second (regardless of bs). > If so, you probably want to look at the blocksize you're using, and = bump up > MAXPHYS in your kernel configuration to a larger value. Post MAXPHYS & DFLTPHYS increase to 4MB (4x1024x1024) (as 16MB caused = the kernel to hang during boot just post usb/knd - likely as it is there = that it starts on SAS disk & tape discovery) I get as =E2=80=98mt status -v=E2=80=99 the output: > Tape I/O parameters: > Maximum I/O size allowed by driver and controller (maxio): 1372160 = bytes > Maximum I/O size reported by controller (cpi_maxio): 1372160 bytes > Maximum block size supported by tape drive and media (max_blk): = 16777215 bytes > Minimum block size supported by tape drive and media (min_blk): 1 = bytes > Block granularity supported by tape drive and media (blk_gran): 0 = bytes > Maximum possible I/O size (max_effective_iosize): 1372160 bytes And see the same speeds; non blocksize limited (with dd) are = 2.7Mbyte/second (so slightly higher); the blocksized writes are better = (but still) low; 200kbyte/second for 16k, 600k for 32k, 800k for 64k, = 500k for 128k, 1M at 256k, 1M at 1024k. The writes at 2048k and 4096k = fail with a =E2=80=98hardware failure asc:44,0 =E2=80=94 tape is now = frozen=E2=80=9D error). This is with `kern.cam.sa.allow_io_split=3D1=E2=80=99 in = /boot/loader.conf=E2=80=99. Doing so without that (after a reboot) give = substantially similar results: (1.8Mbyte/second (0), 450k (16k), 560k = (32k), 0.9M (64), 560k (128k), 730k (256k) and 600k (1M) =E2=80=94 it = fairly errors out with a si_iosize_max=3D1372160 for sizes above that. Dw #!/bin/sh set -x # create a ram disk of about 1 Gbyte with a noncompressible file on it. # mdconfig -a -s 1200M newfs md0 mount /dev/md0 /mnt dd if=3D/dev/urandom bs=3D1m count=3D1024 of=3D/mnt/test-1024m for i in "" bs=3D16k bs=3D32k bs=3D64k bs=3D128k bs=3D256k bs=3D1024k = bs=3D2048k bs=3D4196k do mt rewind echo Run started with ${i:-no blocksize set} dd if=3D/mnt/test-1024m $i of=3D/dev/nsa0 done From owner-freebsd-hackers@freebsd.org Tue Feb 21 18:55:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16CDFCE7640; Tue, 21 Feb 2017 18:55:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F0E9DAAC; Tue, 21 Feb 2017 18:55:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1LItBgq098130 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 10:55:11 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1LItBw5098129; Tue, 21 Feb 2017 10:55:11 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 10:55:11 -0800 From: Steve Kargl To: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170221185511.GA98080@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> <20170221005030.GD26759@dft-labs.eu> <20170221052658.GA93413@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221052658.GA93413@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 21 Feb 2017 18:55:13 -0000 On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > Well, the good news seems to be that r313254 and older are 'ok'. > So, something between r313943 and r313254 is triggering a the > problem. I'm still bisecting, but it might take a day or two. > I've been able to narrow the range down to r313854 to r313943. If I had to guess, the issue may be related to Author: kib Date: Fri Feb 17 21:08:32 2017 New Revision: 313898 URL: https://svnweb.freebsd.org/changeset/base/313898 Log: Merge i386 and amd64 mtrr drivers. I won't be able to investigate until later tonight (~ 10 hours from now). -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Tue Feb 21 20:46: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 0C245CE89CD for ; Tue, 21 Feb 2017 20:46:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9167E5E for ; Tue, 21 Feb 2017 20:46:01 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id v1LKjqXE034619 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 15:45:52 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id v1LKjqXX034618; Tue, 21 Feb 2017 15:45:52 -0500 (EST) (envelope-from ken) Date: Tue, 21 Feb 2017 15:45:52 -0500 From: "Kenneth D. Merry" To: Dirk-Willem van Gulik Cc: freebsd-hackers@freebsd.org Subject: Re: sa and mpt in FreeBSD 11.0-RELEASE-p2 Message-ID: <20170221204551.GA32056@mithlond.kdm.org> References: <20170220205621.GA14597@mithlond.kdm.org> <9A1C3971-0614-4E7C-9A99-C40346D794CB@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A1C3971-0614-4E7C-9A99-C40346D794CB@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 21 Feb 2017 15:45:52 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org 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, 21 Feb 2017 20:46:02 -0000 On Tue, Feb 21, 2017 at 18:15:06 +0100, Dirk-Willem van Gulik wrote: > > > On 20 Feb 2017, at 21:56, Kenneth D. Merry wrote: > > > > On Mon, Feb 20, 2017 at 21:04:11 +0100, Dirk-Willem van Gulik wrote: > >> A machine, recently upgraded from 8.4 to FreeBSD 11.0-RELEASE-p2 seems to have lost pretty much any and all performance on mpt(4) with its attached tape drives > >> > >> Read performance is around 50Mbyte/second - and write a paltry 100-200kbyte/second (and occasionally hitting 800kbyte/second) (from/to memory disk&/dev/null; no risk of shoe shining, compression off). > >> > >> SCSI bus looks happy; with no kernel messages. Output of the DLT script below. > >> > >> Normal LTO drives in a tape robot, G9 server; pretty much all SAS *except* for a U320 to tape drive with the performance issue. Active terminator. > >> > >> Does this ring a bell with anyone? Was anything changed in either the sa or mpt driver since 8.x ? > >> > >> One odd thing is that a 'dd(1)' -without- a block size (compression is off, data is a prepared urandom file on md disk) writes much faster -- while on 8.x one -had- to use a sane blockwise to get the 'normal' speed of around 120Mbyte/second. Could it be that one needs to fiddle with MAXPHYS (which AFAIK is a readonly sysctl). > >> > > > > What blocksize are you using? What blocksize were you using before? What > > application do you normally use to talk to the tape drive? > > Amanda (or plain DD); we increased Amanda???s default of 32 to 64k (which stopped any and all shoe shining at that time. It was tested in 2013 (so likely in FreeBSD 8) up to 16 Mbyte in factors of 2 according to our notes - but with no further improvements in performance - and left at 64k). > This tells me that Amanda is keeping the tape driver well supplied with I/O. Since 64K was probably the blocksize going down to the hardware previously, it makes sense that increasing it in Amanda didn't make a difference. > The actual drive (mt status -v) reports (prior to increasing MAXPHYS) on 11.0-p2 with default kernel config: > > > Drive: sa0: Serial Number: HU1027B53Y > > --------------------------------- > > Mode Density Blocksize bpi Compression > > Current: 0x46:LTO-4 variable 323215 enabled (0x1) > > --------------------------------- > > Current Driver State: at rest. > > --------------------------------- > > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > > Flags: BOP > > --------------------------------- > > Tape I/O parameters: > > Maximum I/O size allowed by driver and controller (maxio): 131072 bytes > > Maximum I/O size reported by controller (cpi_maxio): 131072 bytes > > Maximum block size supported by tape drive and media (max_blk): 16777215 bytes > > Minimum block size supported by tape drive and media (min_blk): 1 bytes > > Block granularity supported by tape drive and media (blk_gran): 0 bytes > > Maximum possible I/O size (max_effective_iosize): 131072 bytes > > ???. > > If you want to re-enable I/O splitting (which I should have disabled by > > now), you can set the following loader tunable in /boot/loader.conf: > > > > kern.cam.sa.allow_io_split=1 > > Ok - this changes behaviour - non-blocksized limited writes are now up; 2Mbyte/second; any block-sized write is 200kb/second (regardless of bs). > > > If so, you probably want to look at the blocksize you're using, and bump up > > MAXPHYS in your kernel configuration to a larger value. > > Post MAXPHYS & DFLTPHYS increase to 4MB (4x1024x1024) (as 16MB caused the kernel to hang during boot just post usb/knd - likely as it is there that it starts on SAS disk & tape discovery) I get > as ???mt status -v??? the output: > > > Tape I/O parameters: > > Maximum I/O size allowed by driver and controller (maxio): 1372160 bytes > > Maximum I/O size reported by controller (cpi_maxio): 1372160 bytes > > Maximum block size supported by tape drive and media (max_blk): 16777215 bytes > > Minimum block size supported by tape drive and media (min_blk): 1 bytes > > Block granularity supported by tape drive and media (blk_gran): 0 bytes > > Maximum possible I/O size (max_effective_iosize): 1372160 bytes > > > And see the same speeds; non blocksize limited (with dd) are 2.7Mbyte/second (so slightly higher); the blocksized writes are better (but still) low; 200kbyte/second for 16k, 600k for 32k, 800k for 64k, 500k for 128k, 1M at 256k, 1M at 1024k. The writes at 2048k and 4096k fail with a ???hardware failure asc:44,0 ??? tape is now frozen??? error). > > This is with `kern.cam.sa.allow_io_split=1??? in /boot/loader.conf???. Doing so without that (after a reboot) give substantially similar results: (1.8Mbyte/second (0), 450k (16k), 560k (32k), 0.9M (64), 560k (128k), 730k (256k) and 600k (1M) ??? it fairly errors out with a si_iosize_max=1372160 for sizes above that. > What do you mean by 0 for a blocksize? Do you mean that you didn't specify a blocksize? If not, it appears that dd defaults to 512 bytes, although it could be different in your case. If the kernel is well supplied with data, there should be very little difference between the I/O splitting case and the non-I/O splitting case. The fact that you're getting substantially higher performance with I/O splitting enabled points to probable delays in getting the data into the kernel. Instead of doing a single threaded read/write dd test, I would suggest doing something like this: dd if=inputfile bs=10m | dd of=/dev/nsa0 bs=1m That will insure that the dd process writing to the tape has plenty of data to write. Even though the test script below uses a ramdisk for the source file, it looks like there is probably a delay between writes, which might account for the lower performance. Also, the fact that you're getting a hardware failure with larger writes may mean that the tape drive might not support what it claims to. The hardware failure is probably coming from the tape drive. > Dw > > #!/bin/sh > set -x > > # create a ram disk of about 1 Gbyte with a noncompressible file on it. > # > mdconfig -a -s 1200M > newfs md0 > mount /dev/md0 /mnt > dd if=/dev/urandom bs=1m count=1024 of=/mnt/test-1024m > > for i in "" bs=16k bs=32k bs=64k bs=128k bs=256k bs=1024k bs=2048k bs=4196k > do > mt rewind > echo Run started with ${i:-no blocksize set} > dd if=/mnt/test-1024m $i of=/dev/nsa0 > done Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-hackers@freebsd.org Wed Feb 22 00:32:40 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 6982FCE5939 for ; Wed, 22 Feb 2017 00:32:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B58315DB for ; Wed, 22 Feb 2017 00:32:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id l19so72585358ywc.2 for ; Tue, 21 Feb 2017 16:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=WlN8DaBgFplWDgmkVHLR6s/vwxPEwntXKI8Yg0z5pJg=; b=msK5b3N6S685z/8ZXAQ4gI+xulHoYRtDS4ur3zYXosm+60TH7DauJHsznsnoWUf97L ZfgckL/KE8LQY2i4c5KFpPt/sDoxzmU7oLemVeXuJxeS8+Him6cKU21Lxlo7R65IWp86 uZqszDL8xXiiDsuOHwBJRgMOtl0Tf3k3lxLAmMBpgf38U5iWSp1RkJDUzjlp4baJ1LC3 AoxvFBDuuJj8+bx0n4EezCSowUZlQuB9Q1RotMiY6c5a2r5VMpvobyQ2ZI9tqNLN80TD VfHgJpnGuU8HyN4BI50X6tYQANVrGLI5vIjGTMQiWEQC39549uyrxyf5y3dpXyNR5UK0 W1Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=WlN8DaBgFplWDgmkVHLR6s/vwxPEwntXKI8Yg0z5pJg=; b=AfINGBy0S2+rsE40nIkPe3DfsZ6xvYjy6OqYGsT2B4Of7472VslbL6b0Ugir5ZRmyJ U95vVzYvWNlEUyaYjMVryQ2Hl0MnHo8KNl+aGuIGjp/Kdte4sCU8bCr/HSbMZQsbHFNT feUZgklYgzza8RrXTV6NoAiH8M0wvTEp0Jl/3fgK9Pd183b55aYMNRLf4ibgKxfU2C3d lISnPCrcH7WyvvnfevRu5gYoGqw3A+l7ULq8s9DxvzaCkeSL4pYqC77cyOH3Tkc4h/hy 3sfkqKdvMUY4b+yDv/3ATSZc+9puXvrNYhdfa5ksrIG2d7usu6odvS7U70fPB60l6Bjl nY/Q== X-Gm-Message-State: AMke39kqT5yyrRFRk+XSKj4w43x3SSt/2jju2+ZAbUM8N5+xmHoy/+RKD8Z83j7BEvHCPsGrI+H+XHr8/OBIUA== X-Received: by 10.129.141.6 with SMTP id d6mr22233790ywg.36.1487723559066; Tue, 21 Feb 2017 16:32:39 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Tue, 21 Feb 2017 16:32:38 -0800 (PST) From: Alan Somers Date: Tue, 21 Feb 2017 17:32:38 -0700 X-Google-Sender-Auth: -WWzViUCwHFfQU64OcoBtLV3Fdg Message-ID: Subject: TravisCI vs BuildBot vs Bamboo vs Jenkins To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 00:32:40 -0000 All of the cool kids are hosting their projects on Github and using TravisCI for continuous testing. The integration is fairly slick. But TravisCI only supports OSX and Linux. Every time a user opens a feature request for FreeBSD support (https://github.com/travis-ci/travis-ci/issues/1818, https://github.com/travis-ci/travis-ci/issues/5473, https://github.com/travis-ci/travis-ci/issues/6671), it gets closed by a Travis employee who thinks that FreeBSD is a Linux distro. One overachiever managed to trick Travis into running FreeBSD by using QEMU to fire up a VM as an unprivileged user process and run his tests inside of that. https://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html And a few projects are even doing this very thing, though it seems like a bit abusive to me. https://travis-ci.org/rust-lang/libc/jobs/203950308 So my question is, what's the best alternative? BuildBot can run on pretty much anything, and supposedly it can hook into all of the popular code hosting platforms. https://docs.buildbot.net/latest/manual/cfg-wwwhooks.html Bamboo is also very portable, and has a slick GUI to connect to Bitbucket. Unfortunately, it's closed-source, but free licenses are available for open-source developers. Unfortunately, it's written in Java. https://developer.atlassian.com/blog/2016/02/totw-connecting-bamboo-and-bitbucket-cloud/ Jenkins is free and portable and has some level of Github and Bitbucket integration. Unfortunately it's also written in Java. https://jenkins.io/solutions/github/ Does anybody have experience with any of these solutions? Are there alternatives I've overlooked? -Alan From owner-freebsd-hackers@freebsd.org Wed Feb 22 03:40:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA29ECE7B71 for ; Wed, 22 Feb 2017 03:40:37 +0000 (UTC) (envelope-from orion@blackboxconsortium.com) Received: from vps.getseenmedia.com (vps.getseenmedia.com [184.154.14.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8703D1E91 for ; Wed, 22 Feb 2017 03:40:37 +0000 (UTC) (envelope-from orion@blackboxconsortium.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blackboxconsortium.com; s=default; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JSpTmAvwL8aFp/jZcl1BDQtSDgPjwtqqxTVy7JviCXM=; b=ZBDFeYbSNYAS/jD+S6+lXjiG9l fyLL/VEb1bmJ3o29jugQgKq9L6Fk0sARNk++uLDBt72MXUdvuJE7B7hOhZIl6e9AdB9C8MHdQ8b6f dKh0kX1417fKwLq6xqPWyCtnQN3nsjUxWPdsL5klQNO7az623DBei1m65Ry7Yv9+9QVX/Fkk7S/n+ tWjyKXQuandTNEL8g35nXpvts+Lwbeq8NNUNWT0CQA6Oi98qciUrpSpebkTmAXW3EhHQHZmaa/gJL fHGDezN9y2dlxrhs5IKcXdj7OPWYddllcZQeF+iePK70479e9epg/cOdRYpKa0KVzpIY8NoeM00L0 SFBGWLBA==; Received: from 47-51-33-228.static.mtpk.ca.charter.com ([47.51.33.228]:42692 helo=homemail.leadverticals.com) by vps.getseenmedia.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cgMYh-00028i-CD for freebsd-hackers@freebsd.org; Tue, 21 Feb 2017 18:21:35 -0800 Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: freebsd-hackers@freebsd.org References: From: Orion Tiller Message-ID: <4b9a58e1-8b67-0728-b0d2-370684350805@blackboxconsortium.com> Date: Tue, 21 Feb 2017 18:27:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.getseenmedia.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blackboxconsortium.com X-Get-Message-Sender-Via: vps.getseenmedia.com: authenticated_id: orion@blackboxconsortium.com X-Authenticated-Sender: vps.getseenmedia.com: orion@blackboxconsortium.com X-Source: X-Source-Args: X-Source-Dir: 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, 22 Feb 2017 03:40:37 -0000 > All of the cool kids are hosting their projects on Github and using > TravisCI for continuous testing. The integration is fairly slick. > But TravisCI only supports OSX and Linux. Every time a user opens a > feature request for FreeBSD support > (https://github.com/travis-ci/travis-ci/issues/1818, > https://github.com/travis-ci/travis-ci/issues/5473, > https://github.com/travis-ci/travis-ci/issues/6671), it gets closed by > a Travis employee who thinks that FreeBSD is a Linux distro. > > One overachiever managed to trick Travis into running FreeBSD by using > QEMU to fire up a VM as an unprivileged user process and run his tests > inside of that. > https://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html > > And a few projects are even doing this very thing, though it seems > like a bit abusive to me. > https://travis-ci.org/rust-lang/libc/jobs/203950308 > > > So my question is, what's the best alternative? > > BuildBot can run on pretty much anything, and supposedly it can hook > into all of the popular code hosting platforms. > https://docs.buildbot.net/latest/manual/cfg-wwwhooks.html > > Bamboo is also very portable, and has a slick GUI to connect to > Bitbucket. Unfortunately, it's closed-source, but free licenses are > available for open-source developers. Unfortunately, it's written in > Java. > https://developer.atlassian.com/blog/2016/02/totw-connecting-bamboo-and-bitbucket-cloud/ > > Jenkins is free and portable and has some level of Github and > Bitbucket integration. Unfortunately it's also written in Java. > https://jenkins.io/solutions/github/ > > > Does anybody have experience with any of these solutions? Are there > alternatives I've overlooked? Gitlab has CI as well. https://about.gitlab.com/gitlab-ci/ > > -Alan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Feb 22 05:29: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 8ADE0CE963E; Wed, 22 Feb 2017 05:29:15 +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 EEA3D1F27; Wed, 22 Feb 2017 05:29:14 +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 v1M5T8f6096325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2017 07:29:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v1M5T8f6096325 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v1M5T84R096324; Wed, 22 Feb 2017 07:29:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Feb 2017 07:29:08 +0200 From: Konstantin Belousov To: Steve Kargl Cc: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222052908.GL2092@kib.kiev.ua> References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> <20170221005030.GD26759@dft-labs.eu> <20170221052658.GA93413@troutmask.apl.washington.edu> <20170221185511.GA98080@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221185511.GA98080@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 22 Feb 2017 05:29:15 -0000 On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > So, something between r313943 and r313254 is triggering a the > > problem. I'm still bisecting, but it might take a day or two. > > > > I've been able to narrow the range down to r313854 to r313943. > If I had to guess, the issue may be related to > > Author: kib > Date: Fri Feb 17 21:08:32 2017 > New Revision: 313898 > URL: https://svnweb.freebsd.org/changeset/base/313898 > > Log: > Merge i386 and amd64 mtrr drivers. > > I won't be able to investigate until later tonight (~ 10 hours from now). >From what I see in other messages, you are using i386 kernel on Core2 class machine, am I right ? Did r313897 worked fine ? r313898 has a bug for i386 architecture, which was fixed in r313934. Could you compile kernel from r313898 sources with r313934 applied on top of it ? I mean, take r313898 and apply the changes from r313934 either manually or with patch, but not take any further changes from svn after r313898. If such kernel does not boot, I will provide further instructions. From owner-freebsd-hackers@freebsd.org Wed Feb 22 05:32:43 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 D8BE5CE9987; Wed, 22 Feb 2017 05:32:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C48CA873; Wed, 22 Feb 2017 05:32:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1M5WgMc004254 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 21:32:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1M5Wglt004253; Tue, 21 Feb 2017 21:32:42 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 21:32:42 -0800 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Cc: kib@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222053242.GA4204@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170220235224.GA91194@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 22 Feb 2017 05:32:43 -0000 Well, I found the guilty commit. r313934 breaks loading either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. details below. I'll also note that starting at r313902 or so, after loading i915kms.ko console output on vt is slooooooow. A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, and 1.08 sys, but the drawing on screen takes more than 30 seconds. One can painfully watch each line of output be rastered across the screen. Kib you can read the details below. If you need more info, ping me. I did notice that i686_mem.c used constants of the form 0xffffULL prior to the merge into x86_mem.c. You now use 0xfffUL. I have no idea whether this is related to cause. -- steve On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > With a kernel and world from r313943 sources (circa > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > will lock up the system. There is no keyboard response, > screen output, or panic. Just a locked up system. > > A kernel from r313027 and its modules boots fine. > 'kldload drm2.ko' yields the following in /var/log/messages: > > agp0: on vgapci0 > agp0: aperture size is 256M, detected 7676k stolen memory > info: [drm] Initialized drm 1.1.0 20060810 > > 'kldload drm2.ko' yields the following in /var/log/messages: > drmn0: on vgapci0 > intel_iicbb0 on drmn0 > iicbus0: on iicbb0 addr 0xf2 > iic0: on iicbus0 > iicbus1: on intel_gmbus0 > iic1: on iicbus1 > intel_iicbb1 on drmn0 > iicbus2: on iicbb1 addr 0xf2 > iic2: on iicbus2 > iicbus3: on intel_gmbus1 > iic3: on iicbus3 > intel_iicbb2 on drmn0 > iicbus4: on iicbb2 addr 0xf2 > iic4: on iicbus4 > iicbus5: on intel_gmbus2 > iic5: on iicbus5 > intel_iicbb3 on drmn0 > iicbus6: on iicbb3 addr 0xf2 > iic6: on iicbus6 > iicbus7: on intel_gmbus3 > iic7: on iicbus7 > intel_iicbb4 on drmn0 > iicbus8: on iicbb4 addr 0xf2 > iic8: on iicbus8 > iicbus9: on intel_gmbus4 > iic9: on iicbus9 > intel_iicbb5 on drmn0 > iicbus10: on iicbb5 addr 0xf2 > iic10: on iicbus10 > iicbus11: on intel_gmbus5 > iic11: on iicbus11 > info: [drm] MSI enabled 1 message(s) > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > composite sync not supported > intel_sdvo_ddc_proxy397632 on drmn0 > intel_sdvo_ddc_proxy397632: detached > intel_sdvo_ddc_proxy397664 on drmn0 > intel_sdvo_ddc_proxy397664: detached > drmn0: taking over the fictitious range 0xe0000000-0xf0000000 > info: [drm] initialized overlay support > info: [drm] Connector LVDS-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.LVDS-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector VGA-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.VGA-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector SVIDEO-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.SVIDEO-1 > info: [drm] - kern.vt.fb.default_mode > composite sync not supported > fbd0 on drmn0 > VT: Replacing driver "vga" with new "fb". > info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > > A diff of dmesg.boot for the good kernel and bad kernel shows > > --- /root/dmesg.good 2017-02-20 13:30:06.707702000 -0800 > +++ /root/dmesg.bad 2017-02-20 13:42:10.271942000 -0800 > @@ -2,11 +2,11 @@ > 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 #3 r313027: Mon Feb 20 11:59:15 PST 2017 > +FreeBSD 12.0-CURRENT #1 r313943: Sun Feb 19 09:18:03 PST 2017 > root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 > FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) > VT(vga): text 80x25 > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) > Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > Features=0xbfebfbff > Features2=0xe3bd > @@ -15,7 +15,7 @@ > VT-x: (disabled in BIOS) HLT,PAUSE > TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > -avail memory = 3663994880 (3494 MB) > +avail memory = 3665018880 (3495 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > @@ -24,7 +24,7 @@ > ioapic0 irqs 0-23 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > -module_register_init: MOD_LOAD (vesa, 0xc0bf7440, 0) error 19 > +module_register_init: MOD_LOAD (vesa, 0xc0ae6db0, 0) error 19 > nexus0 > vtvga0: on motherboard > acpi0: on motherboard > @@ -42,7 +42,7 @@ > attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > +Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: on acpi0 > pcib0: failed to parse resources: AE_AML_NO_RESOURCE_END_TAG > > The module_register_init difference seems suspicious. > > -- > Steve > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Feb 22 05:37: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 23C58CE9B38; Wed, 22 Feb 2017 05:37:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 08105B1B; Wed, 22 Feb 2017 05:37:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1M5bf0H004335 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 21:37:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1M5bfoQ004334; Tue, 21 Feb 2017 21:37:41 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 21:37:41 -0800 From: Steve Kargl To: Konstantin Belousov Cc: Mateusz Guzik , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222053741.GB4204@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> <20170221005030.GD26759@dft-labs.eu> <20170221052658.GA93413@troutmask.apl.washington.edu> <20170221185511.GA98080@troutmask.apl.washington.edu> <20170222052908.GL2092@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222052908.GL2092@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 22 Feb 2017 05:37:42 -0000 On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > > So, something between r313943 and r313254 is triggering a the > > > problem. I'm still bisecting, but it might take a day or two. > > > > > > > I've been able to narrow the range down to r313854 to r313943. > > If I had to guess, the issue may be related to > > > > Author: kib > > Date: Fri Feb 17 21:08:32 2017 > > New Revision: 313898 > > URL: https://svnweb.freebsd.org/changeset/base/313898 > > > > Log: > > Merge i386 and amd64 mtrr drivers. > > > > I won't be able to investigate until later tonight (~ 10 hours from now). > > >From what I see in other messages, you are using i386 kernel on Core2 > class machine, am I right ? Did r313897 worked fine ? > > r313898 has a bug for i386 architecture, which was fixed in r313934. > Could you compile kernel from r313898 sources with r313934 applied on > top of it ? I mean, take r313898 and apply the changes from r313934 > either manually or with patch, but not take any further changes from > svn after r313898. > I just completed the bisection. r313934 is the problem. 'svn update -r 313933' boots and I can load drm2.ko. 'svn update -r 313934' boots and hangs on loading the module. As I noted in another reply I just sent, around -r313902 I can load the i915kms.ko but console output to vt is sloooow. Perhaps, a locking issue that 313934 exacerbated. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Feb 22 05:48:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07236CE9E28; Wed, 22 Feb 2017 05:48:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7A4910D1; Wed, 22 Feb 2017 05:48:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1M5mBVI004428 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 21:48:11 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1M5mBJE004427; Tue, 21 Feb 2017 21:48:11 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 21:48:11 -0800 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222054811.GA4404@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170220235807.GC26759@dft-labs.eu> <20170221004340.GA91587@troutmask.apl.washington.edu> <20170221005030.GD26759@dft-labs.eu> <20170221052658.GA93413@troutmask.apl.washington.edu> <20170221185511.GA98080@troutmask.apl.washington.edu> <20170222052908.GL2092@kib.kiev.ua> <20170222053741.GB4204@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222053741.GB4204@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 22 Feb 2017 05:48:13 -0000 On Tue, Feb 21, 2017 at 09:37:41PM -0800, Steve Kargl wrote: > On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > > > So, something between r313943 and r313254 is triggering a the > > > > problem. I'm still bisecting, but it might take a day or two. > > > > > > > > > > I've been able to narrow the range down to r313854 to r313943. > > > If I had to guess, the issue may be related to > > > > > > Author: kib > > > Date: Fri Feb 17 21:08:32 2017 > > > New Revision: 313898 > > > URL: https://svnweb.freebsd.org/changeset/base/313898 > > > > > > Log: > > > Merge i386 and amd64 mtrr drivers. > > > > > > I won't be able to investigate until later tonight (~ 10 hours from now). > > > > >From what I see in other messages, you are using i386 kernel on Core2 > > class machine, am I right ? Did r313897 worked fine ? Re-reading your email, I noticed you asked about r313897. I'll rebuild the kernel at this revision and r313898 and get back to to you. Yes, it is i386 on a core2 system. : FreeBSD 12.0-CURRENT #20 r313931: Tue Feb 21 21:02:18 PST 2017 root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) VT(vga): text 80x25 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE > > > > r313898 has a bug for i386 architecture, which was fixed in r313934. > > Could you compile kernel from r313898 sources with r313934 applied on > > top of it ? I mean, take r313898 and apply the changes from r313934 > > either manually or with patch, but not take any further changes from > > svn after r313898. > > > > I just completed the bisection. r313934 is the problem. > 'svn update -r 313933' boots and I can load drm2.ko. > 'svn update -r 313934' boots and hangs on loading the > module. > > As I noted in another reply I just sent, around -r313902 > I can load the i915kms.ko but console output to vt is sloooow. > Perhaps, a locking issue that 313934 exacerbated. > > -- > Steve > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > _______________________________________________ > 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" -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Feb 22 06:08:08 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 AA7EECE84F7; Wed, 22 Feb 2017 06:08:08 +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 29BDE1CE7; Wed, 22 Feb 2017 06:08:07 +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 v1M682DY005294 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2017 08:08:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v1M682DY005294 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v1M682qD005293; Wed, 22 Feb 2017 08:08:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Feb 2017 08:08:02 +0200 From: Konstantin Belousov To: Steve Kargl Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222060802.GM2092@kib.kiev.ua> References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170222053242.GA4204@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222053242.GA4204@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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: Wed, 22 Feb 2017 06:08:08 -0000 On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote: > Well, I found the guilty commit. r313934 breaks loading > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. > details below. > > I'll also note that starting at r313902 or so, after > loading i915kms.ko console output on vt is slooooooow. > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, > and 1.08 sys, but the drawing on screen takes more than > 30 seconds. One can painfully watch each line of output > be rastered across the screen. > > Kib you can read the details below. If you need more info, > ping me. I did notice that i686_mem.c used constants of the > form 0xffffULL prior to the merge into x86_mem.c. You now > use 0xfffUL. I have no idea whether this is related to > cause. Well, yes, I found two instances more of such bugs, one seems to be innocent, and another might be the issue. Please try this on top of r313934 or the latest HEAD. diff --git a/sys/x86/x86/x86_mem.c b/sys/x86/x86/x86_mem.c index 8e93883863a..d639224f840 100644 --- a/sys/x86/x86/x86_mem.c +++ b/sys/x86/x86/x86_mem.c @@ -260,7 +260,7 @@ x86_mrfetch(struct mem_range_softc *sc) /* Compute the range from the mask. Ick. */ mrd->mr_len = (~(msrv & mtrr_physmask) & - (mtrr_physmask | 0xfffL)) + 1; + (mtrr_physmask | 0xfffLL)) + 1; if (!mrvalid(mrd->mr_base, mrd->mr_len)) mrd->mr_flags |= MDF_BOGUS; @@ -638,7 +638,7 @@ x86_mrinit(struct mem_range_softc *sc) * Determine the size of the PhysMask and PhysBase fields in * the variable range MTRRs. */ - mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffUL; + mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffULL; /* If fixed MTRRs supported and enabled. */ if ((mtrrcap & MTRR_CAP_FIXED) && (mtrrdef & MTRR_DEF_FIXED_ENABLE)) { From owner-freebsd-hackers@freebsd.org Wed Feb 22 06:29:44 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 EA978CE8BE0; Wed, 22 Feb 2017 06:29:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B70D5B7B; Wed, 22 Feb 2017 06:29:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1M6Thos004619 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 22:29:43 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1M6Th6F004618; Tue, 21 Feb 2017 22:29:43 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 22:29:43 -0800 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222062943.GA4611@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170222053242.GA4204@troutmask.apl.washington.edu> <20170222060802.GM2092@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222060802.GM2092@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 22 Feb 2017 06:29:45 -0000 On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote: > > Well, I found the guilty commit. r313934 breaks loading > > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. > > details below. > > > > I'll also note that starting at r313902 or so, after > > loading i915kms.ko console output on vt is slooooooow. > > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, > > and 1.08 sys, but the drawing on screen takes more than > > 30 seconds. One can painfully watch each line of output > > be rastered across the screen. > > > > Kib you can read the details below. If you need more info, > > ping me. I did notice that i686_mem.c used constants of the > > form 0xffffULL prior to the merge into x86_mem.c. You now > > use 0xfffUL. I have no idea whether this is related to > > cause. > > Well, yes, I found two instances more of such bugs, one seems to be innocent, > and another might be the issue. Please try this on top of r313934 or > the latest HEAD. > > diff --git a/sys/x86/x86/x86_mem.c b/sys/x86/x86/x86_mem.c > index 8e93883863a..d639224f840 100644 > --- a/sys/x86/x86/x86_mem.c > +++ b/sys/x86/x86/x86_mem.c > @@ -260,7 +260,7 @@ x86_mrfetch(struct mem_range_softc *sc) > > /* Compute the range from the mask. Ick. */ > mrd->mr_len = (~(msrv & mtrr_physmask) & > - (mtrr_physmask | 0xfffL)) + 1; > + (mtrr_physmask | 0xfffLL)) + 1; > if (!mrvalid(mrd->mr_base, mrd->mr_len)) > mrd->mr_flags |= MDF_BOGUS; > > @@ -638,7 +638,7 @@ x86_mrinit(struct mem_range_softc *sc) > * Determine the size of the PhysMask and PhysBase fields in > * the variable range MTRRs. > */ > - mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffUL; > + mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffULL; > > /* If fixed MTRRs supported and enabled. */ > if ((mtrrcap & MTRR_CAP_FIXED) && (mtrrdef & MTRR_DEF_FIXED_ENABLE)) { At -r313934 + patch seems to fix the hang on loading i915kms.ko and also the sloooow output to vt. Thanks for the quick response. I'll update to top of tree to check that there isn't any other problems. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Feb 22 06:54: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 C9DEBCE9573 for ; Wed, 22 Feb 2017 06:54:22 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EC111B30; Wed, 22 Feb 2017 06:54:21 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cgQoT-000520-3Y; Tue, 21 Feb 2017 22:54:22 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v1M6s8ld019343; Tue, 21 Feb 2017 22:54:08 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 21 Feb 2017 22:54:08 -0800 From: Oleksandr Tymoshenko To: Alan Somers Cc: "freebsd-hackers@freebsd.org" Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins Message-ID: <20170222065408.GA19302@bluezbox.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Alan Somers (asomers@freebsd.org) wrote: > All of the cool kids are hosting their projects on Github and using > TravisCI for continuous testing. The integration is fairly slick. > But TravisCI only supports OSX and Linux. Every time a user opens a > feature request for FreeBSD support > (https://github.com/travis-ci/travis-ci/issues/1818, > https://github.com/travis-ci/travis-ci/issues/5473, > https://github.com/travis-ci/travis-ci/issues/6671), it gets closed by > a Travis employee who thinks that FreeBSD is a Linux distro. > > One overachiever managed to trick Travis into running FreeBSD by using > QEMU to fire up a VM as an unprivileged user process and run his tests > inside of that. > https://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html > > And a few projects are even doing this very thing, though it seems > like a bit abusive to me. > https://travis-ci.org/rust-lang/libc/jobs/203950308 > > > So my question is, what's the best alternative? > > BuildBot can run on pretty much anything, and supposedly it can hook > into all of the popular code hosting platforms. > https://docs.buildbot.net/latest/manual/cfg-wwwhooks.html > > Bamboo is also very portable, and has a slick GUI to connect to > Bitbucket. Unfortunately, it's closed-source, but free licenses are > available for open-source developers. Unfortunately, it's written in > Java. > https://developer.atlassian.com/blog/2016/02/totw-connecting-bamboo-and-bitbucket-cloud/ > > Jenkins is free and portable and has some level of Github and > Bitbucket integration. Unfortunately it's also written in Java. > https://jenkins.io/solutions/github/ > > > Does anybody have experience with any of these solutions? Are there > alternatives I've overlooked? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: atlassian.com] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-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, 22 Feb 2017 06:54:22 -0000 Alan Somers (asomers@freebsd.org) wrote: > All of the cool kids are hosting their projects on Github and using > TravisCI for continuous testing. The integration is fairly slick. > But TravisCI only supports OSX and Linux. Every time a user opens a > feature request for FreeBSD support > (https://github.com/travis-ci/travis-ci/issues/1818, > https://github.com/travis-ci/travis-ci/issues/5473, > https://github.com/travis-ci/travis-ci/issues/6671), it gets closed by > a Travis employee who thinks that FreeBSD is a Linux distro. > > One overachiever managed to trick Travis into running FreeBSD by using > QEMU to fire up a VM as an unprivileged user process and run his tests > inside of that. > https://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html > > And a few projects are even doing this very thing, though it seems > like a bit abusive to me. > https://travis-ci.org/rust-lang/libc/jobs/203950308 > > > So my question is, what's the best alternative? > > BuildBot can run on pretty much anything, and supposedly it can hook > into all of the popular code hosting platforms. > https://docs.buildbot.net/latest/manual/cfg-wwwhooks.html > > Bamboo is also very portable, and has a slick GUI to connect to > Bitbucket. Unfortunately, it's closed-source, but free licenses are > available for open-source developers. Unfortunately, it's written in > Java. > https://developer.atlassian.com/blog/2016/02/totw-connecting-bamboo-and-bitbucket-cloud/ > > Jenkins is free and portable and has some level of Github and > Bitbucket integration. Unfortunately it's also written in Java. > https://jenkins.io/solutions/github/ > > > Does anybody have experience with any of these solutions? Are there > alternatives I've overlooked? FreeBSD's CI is built using Jenkins: https://ci.freebsd.org also https://wiki.freebsd.org/Jenkins so it must be working fine with FreeBSD. I've been using Jenkins for number of years (not in *BSD world though) and I kind of like it despite somewhat trashy UI. My main complaint is that you can't have CI pipeline description/settings in file in version control (like in GitLab for instance) and have to set it up manually via web UI or API. Other than that it's fairly good system. -- gonzo From owner-freebsd-hackers@freebsd.org Wed Feb 22 07:03: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 C5BCFCE9756; Wed, 22 Feb 2017 07:03:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0AD81FA1; Wed, 22 Feb 2017 07:03:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v1M730IB004927 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 23:03:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v1M730dr004926; Tue, 21 Feb 2017 23:03:00 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 23:03:00 -0800 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222070300.GA4919@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170222053242.GA4204@troutmask.apl.washington.edu> <20170222060802.GM2092@kib.kiev.ua> <20170222062943.GA4611@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222062943.GA4611@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 22 Feb 2017 07:03:01 -0000 On Tue, Feb 21, 2017 at 10:29:43PM -0800, Steve Kargl wrote: > On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote: > > > Well, I found the guilty commit. r313934 breaks loading > > > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. > > > details below. > > > > > > I'll also note that starting at r313902 or so, after > > > loading i915kms.ko console output on vt is slooooooow. > > > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, > > > and 1.08 sys, but the drawing on screen takes more than > > > 30 seconds. One can painfully watch each line of output > > > be rastered across the screen. > > > > > > Kib you can read the details below. If you need more info, > > > ping me. I did notice that i686_mem.c used constants of the > > > form 0xffffULL prior to the merge into x86_mem.c. You now > > > use 0xfffUL. I have no idea whether this is related to > > > cause. > > > > Well, yes, I found two instances more of such bugs, one seems to be innocent, > > and another might be the issue. Please try this on top of r313934 or > > the latest HEAD. > > (patch delete) > > At -r313934 + patch seems to fix the hang on loading i915kms.ko and > also the sloooow output to vt. Thanks for the quick response. I'll > update to top of tree to check that there isn't any other problems. > A kernel and modules from top of tree works as expected. Thanks for the fix. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Wed Feb 22 09:21:21 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 57A49CE81DB for ; Wed, 22 Feb 2017 09:21:21 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 146BF1042 for ; Wed, 22 Feb 2017 09:21:20 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1cgT6m-00036y-4v for freebsd-hackers@freebsd.org; Wed, 22 Feb 2017 10:21:12 +0100 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cgT6l-0007Mf-NN for freebsd-hackers@freebsd.org; Wed, 22 Feb 2017 10:21:12 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A154E2A0008 for ; Wed, 22 Feb 2017 10:21:19 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fh-iycHrIbOF for ; Wed, 22 Feb 2017 10:21:16 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id DFA482A1804 for ; Wed, 22 Feb 2017 10:21:16 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7TnDevExwkds for ; Wed, 22 Feb 2017 10:21:16 +0100 (CET) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id CA85F2A0008 for ; Wed, 22 Feb 2017 10:21:16 +0100 (CET) To: FreeBSD From: Sebastian Huber Subject: Absolute timeouts and clock adjustments Message-ID: <58AD5802.30908@embedded-brains.de> Date: Wed, 22 Feb 2017 10:21:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23107/Wed Feb 22 05:52:45 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 09:21:21 -0000 Hello, I try to figure out how the timeout mechanisms work in current FreeBSD.=20 My interpretation (which could be completely wrong) of POSIX is=20 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=20 sem_timedwait() seems to end up eventually in: /* * Put thread into sleep state, before sleeping, check if * thread was removed from umtx queue. */ static inline int umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct abs_timeout=20 *abstime) { struct umtxq_chain *uc; int error, timo; uc =3D umtxq_getchain(&uq->uq_key); UMTXQ_LOCKED_ASSERT(uc); for (;;) { if (!(uq->uq_flags & UQF_UMTXQ)) return (0); if (abstime !=3D NULL) { timo =3D abs_timeout_gethz(abstime); if (timo < 0) return (ETIMEDOUT); } else timo =3D 0; error =3D msleep(uq, &uc->uc_lock, PCATCH | PDROP, wmesg, timo); if (error !=3D EWOULDBLOCK) { umtxq_lock(&uq->uq_key); break; } if (abstime !=3D NULL) abs_timeout_update(abstime); umtxq_lock(&uq->uq_key); } return (error); } The abs_timeout_gethz() returns the interval length in ticks of=20 [abstime->cur, abstime->end]. Since the msleep() uses the uptime, does=20 this mean that timeouts trigger not immediately due to time adjustments=20 in FreeBSD? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Wed Feb 22 09:55:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01434CE8E6C for ; Wed, 22 Feb 2017 09:55:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0CE0C5B; Wed, 22 Feb 2017 09:55:03 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 052B63A361; Wed, 22 Feb 2017 10:54:59 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU22pjgI5qDr; Wed, 22 Feb 2017 10:54:56 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id E74AE3A360; Wed, 22 Feb 2017 10:54:56 +0100 (CET) Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Alan Somers , "freebsd-hackers@freebsd.org" References: From: Willem Jan Withagen Message-ID: Date: Wed, 22 Feb 2017 10:54:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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, 22 Feb 2017 09:55:04 -0000 On 22-2-2017 01:32, Alan Somers wrote: > All of the cool kids are hosting their projects on Github and using > TravisCI for continuous testing. The integration is fairly slick. > But TravisCI only supports OSX and Linux. Every time a user opens a > feature request for FreeBSD support > (https://github.com/travis-ci/travis-ci/issues/1818, > https://github.com/travis-ci/travis-ci/issues/5473, > https://github.com/travis-ci/travis-ci/issues/6671), it gets closed by > a Travis employee who thinks that FreeBSD is a Linux distro. > > One overachiever managed to trick Travis into running FreeBSD by using > QEMU to fire up a VM as an unprivileged user process and run his tests > inside of that. > https://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html > > And a few projects are even doing this very thing, though it seems > like a bit abusive to me. > https://travis-ci.org/rust-lang/libc/jobs/203950308 > > > So my question is, what's the best alternative? > > BuildBot can run on pretty much anything, and supposedly it can hook > into all of the popular code hosting platforms. > https://docs.buildbot.net/latest/manual/cfg-wwwhooks.html > > Bamboo is also very portable, and has a slick GUI to connect to > Bitbucket. Unfortunately, it's closed-source, but free licenses are > available for open-source developers. Unfortunately, it's written in > Java. > https://developer.atlassian.com/blog/2016/02/totw-connecting-bamboo-and-bitbucket-cloud/ > > Jenkins is free and portable and has some level of Github and > Bitbucket integration. Unfortunately it's also written in Java. > https://jenkins.io/solutions/github/ > > > Does anybody have experience with any of these solutions? Are there > alternatives I've overlooked? Hi Alan, Using Jenkins for my Ceph building.... http://cephdev.digiware.nl:8180/jenkins/ More or less to give the other Ceph-developers access to errors/warnings that Clang on FreeBSD generates with their code. And it will alert me when there are commits on ceph/master that will break the master build. Setup/install was rather painless. Integration with GitHub from my end was rather simple, and I just poll GitHub to see if code has been added. That was a simple tick in a box. Could even integrate it the other way around, and have GitHub ping me if new versions needed to be build. But That I considered too much. The Java stuff runs big, but I did not have to touch it. I would not like to start doing things in Java, but up till now I did not have to. --WjW From owner-freebsd-hackers@freebsd.org Wed Feb 22 10:30:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77C58CE8E66 for ; Wed, 22 Feb 2017 10:30:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 3B407683 for ; Wed, 22 Feb 2017 10:30:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cgUBa-0007KG-MS for freebsd-hackers@freebsd.org; Wed, 22 Feb 2017 13:30:14 +0300 Date: Wed, 22 Feb 2017 13:30:14 +0300 From: Slawa Olhovchenkov To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170222103014.GE15630@zxy.spb.ru> References: <20170220131509.GA31623@tomoyat1.com> <20170220134910.GC15630@zxy.spb.ru> <20170221132000.GA11545@tomoyat1.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221132000.GA11545@tomoyat1.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 22 Feb 2017 10:30:23 -0000 On Tue, Feb 21, 2017 at 10:20:00PM +0900, Tomoya Tabuchi wrote: > On Mon, Feb 20, 2017 at 04:49:10PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Feb 20, 2017 at 10:15:09PM +0900, Tomoya Tabuchi wrote: > > > > > Hello, > > > > > > I am interested in doing a GSoC project this year with the idea "Write a > > > new boot environment manager" on the ideas list. > > > (https://wiki.freebsd.org/SummerOfCodeIdeas#Write_a_new_boot_environment_manager) > > > > > > I would like to ask a few questions involving this. > > > First, is there a particular reason why this project is listed in the > > > ideas list? Aside the fact the current implementation in sh is rather > > > complicated, I was unable to come up with a reason to justify the > > > reimplementation. > > > > > > Second, is making the new implmentation of beadm(1) platform independent > > > and promoting it across the various OpenZFS implmentation / communities > > > as some sort of "standard" implmentation a good idea, or is it > > > over-zealous / outside of the project scope / intrusive to other > > > projects. > > > > > > As for a late self introduction, my name is Tomoya Tabuchi, and I am a > > > undergraduate student at Doshisha University in Japan. I will start my > > > third year in university in April. > > > > Don't know about link above. For me, current beadm have some leaks: > > > > 1. Don't check cosistency before applay: > > I am try to enable beadm on 10.1 install and switch to 11.0. > > fail. > That is interesting. I'll try and see if I can reproduce that, and > observe what's going on. This is may be involved by outdated /etc/rc.d/zfs from 10.1 or by different ZFS layout in 10.1. (how to update by beadm: beadm create NEW beadm mount NEW /mnt cd /mnt find -x . -flags +schg | xargs chflags noschg unpack new binaries cd / beadm umount NEW beadm activate NEW AFTER REBOOT: etcupdate -t etcupdate.tar i.e. new version boot w/ old /etc/rc.d In may case I am see multiple mounted datesets w/ same mount points and lack of /dev For 10.2 and later -- OK. > > 2. Need to control what put under beadm. > Does this mean to hold back on feature bloat, or to distinguish between > ZFS clones created by beadm and ones that were not? If you mean the > latter, I'll take a look at the current behaviour when manually created ZFS > clones are involved. Yes, but this is not intuitive. I am about more friendly from beadm, i.e. for example: beadm showcontrol -- show path beadmed beadm takecontrol -- do some path beadmed beadm releasecontrol -- reverse yes, in many cases need addtional confiramtions for split datasets and move some files between. and warning about inconsistency old. From owner-freebsd-hackers@freebsd.org Wed Feb 22 11:10: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 D80EACE98F8 for ; Wed, 22 Feb 2017 11:10:22 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 78D5519A0; Wed, 22 Feb 2017 11:10:22 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id l12so4197780lfe.0; Wed, 22 Feb 2017 03:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OLxQ/xZunDRDSE9tlWGFcw9dCttKzs5AP+rNkjcAdFc=; b=ZpvEMfm5SeT+XjO5HOwjDubmO/eeuSN9OwVRU16TIEMfIm9nCu4KJXrrBWoGH4V332 sWo2OoH077c+g+DAxEwgp93e620ewJe7KyPFWzQsJieJRs0rgGjU4E0uqZmCI2vOx09H 6y+sBh+/oNe2056/dtlt67H4hbU596Xhkcg8zKbB743kAXYEk9IRzFhScCn8t6N2iaFE PuxwrdHYpBcBE8xCFZEEZkLr9zsD3uaBQ04Gsn1nciGcNYtiL7bojQL+N0MH56kTBYcH 9wh+h5INozUr2E42eY/VITr/A/xmfEQ8Qnejdqv89PxpYPKh23f3YL3AYh36N0B60OgF PtbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OLxQ/xZunDRDSE9tlWGFcw9dCttKzs5AP+rNkjcAdFc=; b=l23VZ3nrefUvt2KohJFfwBzghqnBAiZwclehxMk0SJJizz/GmOVgbLMkLU5epa1Vdd Sao09rfoPSd2/K8Rygif0NxjAnbz5eNFVCc/nCm0Y7saYg9Ne5jnwD1BuG7ST+Kx5GQX gRcRMlK+jLwallOaWY0ZuX0gVZQXDi/JUA7nTBILIyb0pUq2WbEzQiJlEj4qZVsdVntS DXgYOELkjIFY6zpiV9ww6+T8Wc4XxJcq3RFeBtZLxsN/wDnJjYPLFpUd0nABZykeXCHv CQrvbFZTEdsSI3ckLzCgj87U8ywX8un3FuruFcJogjCxgDumowDN07sJiWVR0DKoP02l N1xA== X-Gm-Message-State: AMke39ne/FUFmSGl2lHwFrkxR6sutwEu6N3Q92fW2GAwKFCN1STwkZw2c3dz8kaxaXMkG9p7gp0wz2y4ahWCzA== X-Received: by 10.25.43.8 with SMTP id r8mr1934931lfr.41.1487761820549; Wed, 22 Feb 2017 03:10:20 -0800 (PST) MIME-Version: 1.0 Sender: lwhsu.freebsd@gmail.com Received: by 10.25.159.71 with HTTP; Wed, 22 Feb 2017 03:10:19 -0800 (PST) In-Reply-To: <20170222065408.GA19302@bluezbox.com> References: <20170222065408.GA19302@bluezbox.com> From: Li-Wen Hsu Date: Wed, 22 Feb 2017 19:10:19 +0800 X-Google-Sender-Auth: mJMv1pa0wFUgFoNKQQcJejQFEXA Message-ID: Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Oleksandr Tymoshenko Cc: Alan Somers , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 11:10:22 -0000 On Wed, Feb 22, 2017 at 2:54 PM, Oleksandr Tymoshenko wrote: > FreeBSD's CI is built using Jenkins: https://ci.freebsd.org also > https://wiki.freebsd.org/Jenkins so it must be working fine with > FreeBSD. > > I've been using Jenkins for number of years (not in *BSD world though) > and I kind of like it despite somewhat trashy UI. My main complaint is > that you can't have CI pipeline description/settings in file in version > control (like in GitLab for instance) and have to set it up manually > via web UI or API. Other than that it's fairly good system. > =E2=80=8B=E2=80=8B > =E2=80=8Bci.freebsd.org uses Jenkins Job Builder from OpenStack: https://docs.openstack.org/infra/jenkins-job-builder/ by which you can define your jobs in YAML and save them in VCS. Jenkins 2 also offers "pipeline as code" feature by which you can control your jobs more: https://jenkins.io/doc/book/pipeline/ Best, Li-Wen=E2=80=8B --=20 Li-Wen Hsu https://lwhsu.org From owner-freebsd-hackers@freebsd.org Wed Feb 22 15:01:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C52F0CE9236 for ; Wed, 22 Feb 2017 15:01:36 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B24D1DB6 for ; Wed, 22 Feb 2017 15:01:36 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 475B2132B7 for ; Wed, 22 Feb 2017 15:01:35 +0000 (UTC) Subject: Re: FreeBSD CARP load balancing. To: freebsd-hackers@freebsd.org References: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> From: Allan Jude Message-ID: Date: Wed, 22 Feb 2017 10:01:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FO0JHDODp2lPP6Qi2RlPHHWPfdn4fdgxJ" 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, 22 Feb 2017 15:01:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FO0JHDODp2lPP6Qi2RlPHHWPfdn4fdgxJ Content-Type: multipart/mixed; boundary="oEDueuCRXoRA8s56VbTtXN1ikCrQ8oaRp"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: FreeBSD CARP load balancing. References: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201702211546.v1LFkdxA008295@pdx.rh.CN85.dnsmgr.net> --oEDueuCRXoRA8s56VbTtXN1ikCrQ8oaRp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2017-02-21 10:46, Rodney W. Grimes wrote: >> On 2017-02-21 00:55, Gleb Popov wrote: >>> On Mon, Feb 20, 2017 at 10:16 PM, Steven Hartland >>> wrote: >>> >>>> On 20/02/2017 19:07, Gleb Popov wrote: >>>> >>>> >>>> On Mon, Feb 20, 2017 at 12:01 PM, Steven Hartland >>>> wrote: >>>> >>>>> Does LAGG do what you need? >>>> >>>> >>>> Doesn't seem so. I need to balance incoming traffic between several = hosts. >>>> If I understood it correctly, lagg can be used to load-balance outgo= ing >>>> traffic only. >>>> >>>> >>>> LAGG does incoming and outgoing but only on a single host, so it doe= s >>>> sound like it won't help you. >>>> >>>> That said what your doing does sound quite out of the ordinary, >>>> >>> >>> So, that *net.inet.carp.arpbalance *sysctl was out of ordinary featu= re? >>> That probably explains it. >>> >>> is there a reason you're trying to copy the traffic to multiple hosts= ? >>>> >>> >>> Not copy, but distribute. I just don't want to wait current CARP mast= er die >>> to make another computer become active, but to switch between them in= some >>> fashion (round-robin or whatever). >>> >>> >>>> >>>> Might be a good idea to explain exactly what your trying to achieve.= >>>> >>>> Regards >>>> Steve >>>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd= =2Eorg" >>> >> >> I am not sure arpbalancing every worked very well. Without a hashing >> algorithm or something, how would you actually make a TCP session work= ? >=20 > 8.xish man page: > ARP level load balancing > The carp has limited abilities for load balancing the incoming con= nec- > tions between hosts in Ethernet network. For load balancing opera= tion, > one needs several CARP interfaces that are configured to the same = IP > address, but to a different VHIDs. Once an ARP request is receive= d, the > CARP protocol will use a hashing function against the source IP ad= dress > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^ > in the ARP request to determine which VHID should this request bel= ong to. > If the corresponding CARP interface is in master state, the ARP re= quest > will be replied, otherwise it will be ignored. See the EXAMPLES s= ection > for a practical example of load balancing. >=20 >=20 > There is your hash. >=20 Ohh, cool. I suppose it would be nice to have that feature back. --=20 Allan Jude --oEDueuCRXoRA8s56VbTtXN1ikCrQ8oaRp-- --FO0JHDODp2lPP6Qi2RlPHHWPfdn4fdgxJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iQIcBAEBAgAGBQJYrafKAAoJEBmVNT4SmAt+sFQP/RhyrInu+U9vvSf5hmyB8vTC K0xq8Ordiv8KnoA25RAmWITF3aj5Eu51qSYeZFxXYSQhtifkQ44BnXiAxYp102AI exaoQZksrwdoz2oMZSOeIUfGoVBv5cQsc/Udzr57uK9GdbY+6gc0O17XiM3P5//l QHtav9lsVEUE24V+Qvywwr9pl9tiBAV9siKyB4sw07RhTWmesAq4FNEn9hOLFqwp fkMNOAf+RI5Mt7DZevTTzyP9IYv/faqiuBjctiiUaNdDmpbEvGsI+cdhTm5R6bfs demIx6SI2N35A4tVeCvdzyo66clIv25KrV5zi5uLuOsEgJpoXoKbBhu9ff5uCUFP CCwLMYnx2o7gyNV0/ABNhy6TeGTkFoVUHXxRtX/9d9rncoF7Lk79RVKAaRDikNJo QDto5dE4FvrzSFroAuz1RCLkN8muFqp3YOkM9AHH+5GyvglWzxESX9CSsx4sZfii uh62f55v9LpvZw7UfeG3jlOFnn8FwYwkFVo4yJ3Qj4HtrPEgJ/wbKvcC7/Eq6Erx oi0I/SawPdHCROu266HAcUeWeKvj2X48du60cuO+mjMry6qsWQHjdB67AUVe5tlU aGSiI2MVIUUirnmLBJ0aNCKINXCi4RHVneRTAYBitAnN6LLEzl3yuaEkcG3oP8if CVCbxhnHBzm9Aedt05ji =/0PE -----END PGP SIGNATURE----- --FO0JHDODp2lPP6Qi2RlPHHWPfdn4fdgxJ-- From owner-freebsd-hackers@freebsd.org Wed Feb 22 15:19: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 50A02CE9804 for ; Wed, 22 Feb 2017 15:19:22 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7D5D3B for ; Wed, 22 Feb 2017 15:19:21 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 60B6356483; Wed, 22 Feb 2017 09:19:15 -0600 (CST) Subject: Re: Absolute timeouts and clock adjustments To: Sebastian Huber , FreeBSD References: <58AD5802.30908@embedded-brains.de> From: Eric van Gyzen Message-ID: <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> Date: Wed, 22 Feb 2017 09:19:12 -0600 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: Wed, 22 Feb 2017 15:19:22 -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 This is correct. > Inside the kernel all absolute timeouts seem to use the uptime. The > sem_timedwait() seems to end up eventually in: > > /* > * Put thread into sleep state, before sleeping, check if > * thread was removed from umtx queue. > */ > static inline int > umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct abs_timeout *abstime) > { > struct umtxq_chain *uc; > int error, timo; > > uc = umtxq_getchain(&uq->uq_key); > UMTXQ_LOCKED_ASSERT(uc); > for (;;) { > if (!(uq->uq_flags & UQF_UMTXQ)) > return (0); > if (abstime != NULL) { > timo = abs_timeout_gethz(abstime); > if (timo < 0) > return (ETIMEDOUT); > } else > timo = 0; > error = msleep(uq, &uc->uc_lock, PCATCH | PDROP, wmesg, timo); > if (error != EWOULDBLOCK) { > umtxq_lock(&uq->uq_key); > break; > } > if (abstime != NULL) > abs_timeout_update(abstime); > umtxq_lock(&uq->uq_key); > } > return (error); > } > > 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? This is also correct. The sleep will not be affected by the clock adjustment. This is contrary to POSIX. Note that CentOS 6 (Linux 3.10) behaves the same way. Fedora 24 (Linux 4.8) behaves according to POSIX. I don't know when this changed. I also don't know if it's configurable. By a curious coincidence, I'm working on adding a new sem_clockwait_np() function to FreeBSD. It allows the caller to specify the reference clock and choose between absolute and relative mode. In relative mode, the remaining time can be returned. https://reviews.freebsd.org/D9656 My changes will not make sem_timedwait() comply with POSIX, but they will let the caller use CLOCK_MONOTONIC and avoid the issue. Eric From owner-freebsd-hackers@freebsd.org Wed Feb 22 15:46:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B58BCE90AE for ; Wed, 22 Feb 2017 15:46:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 082E176D for ; Wed, 22 Feb 2017 15:46:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 09f31b96-f916-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 09f31b96-f916-11e6-95b5-6dfd7dbb0ee5; Wed, 22 Feb 2017 15:46:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1MFk5IB007865; Wed, 22 Feb 2017 08:46:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1487778365.73144.144.camel@freebsd.org> Subject: Re: Absolute timeouts and clock adjustments From: Ian Lepore To: Eric van Gyzen , Sebastian Huber , FreeBSD Date: Wed, 22 Feb 2017 08:46:05 -0700 In-Reply-To: <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 15:46:18 -0000 On Wed, 2017-02-22 at 09:19 -0600, Eric van Gyzen wrote: > 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 > This is correct. > > > > > Inside the kernel all absolute timeouts seem to use the uptime. The > > sem_timedwait() seems to end up eventually in: > > > > /* > >  * Put thread into sleep state, before sleeping, check if > >  * thread was removed from umtx queue. > >  */ > > static inline int > > umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct > > abs_timeout *abstime) > > { > >     struct umtxq_chain *uc; > >     int error, timo; > > > >     uc = umtxq_getchain(&uq->uq_key); > >     UMTXQ_LOCKED_ASSERT(uc); > >     for (;;) { > >         if (!(uq->uq_flags & UQF_UMTXQ)) > >             return (0); > >         if (abstime != NULL) { > >             timo = abs_timeout_gethz(abstime); > >             if (timo < 0) > >                 return (ETIMEDOUT); > >         } else > >             timo = 0; > >         error = msleep(uq, &uc->uc_lock, PCATCH | PDROP, wmesg, > > timo); > >         if (error != EWOULDBLOCK) { > >             umtxq_lock(&uq->uq_key); > >             break; > >         } > >         if (abstime != NULL) > >             abs_timeout_update(abstime); > >         umtxq_lock(&uq->uq_key); > >     } > >     return (error); > > } > > > > 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? > This is also correct.  The sleep will not be affected by the clock > adjustment.  > This is contrary to POSIX. > > Note that CentOS 6 (Linux 3.10) behaves the same way.  Fedora 24 > (Linux 4.8)  > behaves according to POSIX.  I don't know when this changed.  I also > don't know  > if it's configurable. > > By a curious coincidence, I'm working on adding a new > sem_clockwait_np()  > function to FreeBSD.  It allows the caller to specify the reference > clock and  > choose between absolute and relative mode.  In relative mode, the > remaining time  > can be returned. > > https://reviews.freebsd.org/D9656 > > My changes will not make sem_timedwait() comply with POSIX, but they > will let  > the caller use CLOCK_MONOTONIC and avoid the issue. > > Eric Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly asks for the current behavior.  If the behavior you need is to wake up when CLOCK_REALTIME exceeds some value, you're still screwed. It would be easy enough to fix the current behavior by adding something like "if (timo > hz) timo = hz;" to the existing loop so that CLOCK_REALTIME gets re-checked once a second. -- Ian From owner-freebsd-hackers@freebsd.org Wed Feb 22 18:03: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 E2A68CE9F3E for ; Wed, 22 Feb 2017 18:03:54 +0000 (UTC) (envelope-from jmr@computing.com) Received: from shiny.computing.com (67-198-16-23.static.grandenetworks.net [67.198.16.23]) by mx1.freebsd.org (Postfix) with ESMTP id BE2B51935 for ; Wed, 22 Feb 2017 18:03:54 +0000 (UTC) (envelope-from jmr@computing.com) Received: from shiny.computing.com (localhost [127.0.0.1]) by shiny.computing.com (Postfix) with ESMTP id 1314E33C2C for ; Wed, 22 Feb 2017 11:57:34 -0600 (CST) X-Virus-Scanned: amavisd-new at computing.com Received: from shiny.computing.com ([127.0.0.1]) by shiny.computing.com (shiny.computing.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOk4dJ5XE6l1 for ; Wed, 22 Feb 2017 11:57:32 -0600 (CST) Received: from shiny.computing.com (localhost [127.0.0.1]) by shiny.computing.com (Postfix) with ESMTP id 76D4B33C2B for ; Wed, 22 Feb 2017 11:57:32 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=computing.com; s=computing; t=1487786252; bh=N2Co+MUDKpETtMAC8ey+DuBIcIx2NiDTpbgIjg+ZWF0=; h=Subject:From:In-Reply-To:Date:References:To; b=L+T+8EnANU1IMVDdeJjXqDRlVA42f6ekLTQAcE46oelGhRyJDMJQXwjPbaIL62wmx Q+SMtqKkSJNroma/6557t9GQuxuyXlLofeNeShtaXRq742Q1vEHuc/q+OtbMYQDcRQ 4CXds740Cu9fTy9XrVb/TCIBoVAEErECllSufaSE= Received: from jmr@computing.com by shiny.computing.com (Archiveopteryx 3.1.3) with esmtpsa id 1487786250-59553-59552/7/142; Wed, 22 Feb 2017 11:57:30 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins From: Jim Rowan In-Reply-To: Date: Wed, 22 Feb 2017 11:57:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> References: To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 22 Feb 2017 18:03:55 -0000 I like buildbot. It is more programmable, and probably much easier to = extend in the case that the build-in paradigms don=92t quite do what you = would like. I think this makes it more suitable for large or complicate= d/unusual systems. Implemented in python, and the configuration is = also written in python (and thus nicely lives in git/svn/whatever =97 I = can=92t even imagine choosing a CI system in which the config can=92t be = properly managed!!). Runs everywhere python runs, including windows = (either with cygwin or native).=20 From owner-freebsd-hackers@freebsd.org Wed Feb 22 18:12: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 7A41BCE92EE for ; Wed, 22 Feb 2017 18:12:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 39D991FCE for ; Wed, 22 Feb 2017 18:12:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22d.google.com with SMTP id p77so5424115ywg.1 for ; Wed, 22 Feb 2017 10:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=u1XzC78w0/jATpDexnavapGfmZkR3GOLfxbhCB+dO+Y=; b=jHeMrD/vbwNDb36UNejYLUPT/CA5yPlb+mFywMcjZItssyLsyM85JHECFz8GFi9Bt/ WzDucVvWQn5By5HHjwQPrpiwc40WRjjF11bdqYEWVHU8jGqqRFAt+vT17iwiU2B+voeF OGF5kcp8VkqYwfOBqqqXU7KNoQp3oAG07K4e/WvV880dwUYMGekkor60+UhnsIBw2/if eSOw4+7lyao+jqeUvjMMcEerQPaAxZNT1mN8WNdLVodCrHNBGT7Qs0T+nKKhxhDs9qnM fHsmAL/59cHfSbS41N8CiTSUpU7Bl7sLyWRwObPJxUsGaRA0Dldr9CyXWibsHdEFAbz4 e2qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=u1XzC78w0/jATpDexnavapGfmZkR3GOLfxbhCB+dO+Y=; b=oPx7TQV1H1cC4NK2IDk9CFpCkR3/0Wp59gOKvHeBOhTzJObuIvII6UMWoz1S0onZtg D0Yf5OclxznDwTFB0WAAlEPQoFmu5NRQepzkZx2/Ls6pnc22xM/YqNr9yaLXIAoeW9aO ooCoGuv6cwp9AXWCyV/JhY1jK+D+MjY2mxecw/nNjVetAET42hr7SZ7363gDi01aVfua ZD1gwLjIRRXvrg+k31xyiX1z6w5gl0etwYGzfO/lcN1IEGz/N0fpsp0SEU4yfPMqydl1 63KhNeOOV2t4WujfIVV5lVf1X55++YfO/znZ+6ffSM/6xRQwfZL6reHj7EKVigYfIPxB 8jAg== X-Gm-Message-State: AMke39l6cwgfeqi73CC0BPNsbzspGvaeYMkDnGjFOgpcd/hFK7E6yUOBAROEpT4+eCCLzK/LA0g4FnLZdpQcww== X-Received: by 10.129.76.85 with SMTP id z82mr4304945ywa.302.1487787134497; Wed, 22 Feb 2017 10:12:14 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Wed, 22 Feb 2017 10:12:14 -0800 (PST) In-Reply-To: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> From: Alan Somers Date: Wed, 22 Feb 2017 11:12:14 -0700 X-Google-Sender-Auth: qFpXADWrZSkTeEVOiKsgHnYXurc Message-ID: Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Jim Rowan Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:12:15 -0000 I think I need to emphasize more that the key feature for me is Github integration. I want to use one of these tools with a project that is hosted in Github. It's not my project, so I can't move it even if I wanted to. WJW's example gets half of the integration I would like; he shows how Jenkins can pull information out of Github. But it doesn't show how to push information back into Github. Does anybody have any examples of using Jenkins, Bamboo, Buildbot etc to push build pass/fail notifications back into Github? -Alan From owner-freebsd-hackers@freebsd.org Thu Feb 23 20:56: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 12283CEAA5F for ; Thu, 23 Feb 2017 20:56:01 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF71D10C8; Thu, 23 Feb 2017 20:56:00 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9BCA73A9B9; Thu, 23 Feb 2017 21:55:57 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoayWOc26ITN; Thu, 23 Feb 2017 21:55:56 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id B0E863A9B6; Thu, 23 Feb 2017 21:55:56 +0100 (CET) Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Alan Somers , Jim Rowan References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> Cc: "freebsd-hackers@freebsd.org" From: Willem Jan Withagen Message-ID: Date: Thu, 23 Feb 2017 21:55:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Thu, 23 Feb 2017 20:56:01 -0000 On 22-2-2017 19:12, Alan Somers wrote: > I think I need to emphasize more that the key feature for me is Github > integration. I want to use one of these tools with a project that is > hosted in Github. It's not my project, so I can't move it even if I > wanted to. WJW's example gets half of the integration I would like; > he shows how Jenkins can pull information out of Github. But it > doesn't show how to push information back into Github. Does anybody > have any examples of using Jenkins, Bamboo, Buildbot etc to push build > pass/fail notifications back into Github? I'm doing very little after the build has completed, but looking at the config, it is possible to add new actions after building had finished. This is in the pull-down, sorry some of it is dutch, but perhaps you get the drift. The [] wording is my crude translation. Archiveer de artefacten [archive] Bouw ander project. [build other] Leg de vingerafdrukken van bestanden vast om hun gebruik te volgen. [fingerprint] Publiceer rapport van de JUnit-testresultaten [publicise] Verzamel testresultaten van onderliggende projecten [collect children] Git Publisher E-mail Notificatie Editable Email Notification Set GitHub commit status (universal) Set build status on GitHub commit [deprecated] Delete workspace when build is done And then there are "lots" of plugins, and I guess that they will also add more reporting. --WjW From owner-freebsd-hackers@freebsd.org Thu Feb 23 22:57: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 24130CEB69D for ; Thu, 23 Feb 2017 22:57:58 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) 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 D4C04C38; Thu, 23 Feb 2017 22:57:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id x71so5454818qkb.3; Thu, 23 Feb 2017 14:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MIf/Z6MXK9f8HSXQVyXDZKWkP015lTRMfMie9D/RYH8=; b=d/PvnBTDrKIS5KMdsxvkRjPmbEtkQuawETMyS1xMwg7Tv+8qvR73f4lfrC6K5jutvF f58L4F+kzp4WAC0zT0ITV1pf2RV13pqced4kli5itYYQcdzpZQGORTNpG3U3eBf7idT/ MLN5/iSGplTt1KmUxRKIm4SXKfnw54LaM2XerfVjmva5SQM7YVe4Ga0QKfcdkhIDu0a6 bYPVs14eQVlDAnScSpkSX8RV9WK5zdjsM45iOCGpqN4cAwf4IolrQ7B5dTW2gVfYYDyq OSSBHdosbGPegBvNvk+c9/+p+ltUcqtxrTUWscu3VR7GCfhcDtJe+hRAnIy5EgkKxaS0 AIwA== 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=MIf/Z6MXK9f8HSXQVyXDZKWkP015lTRMfMie9D/RYH8=; b=qbRcokKvfF/IhbQ6lYYqsvL4/xF5CFrb4FDn1RxL2ga1kX7VIplq+fOqcFnENUoWPk ICy9Jxt3kOWqfzwfBZl233EbOk9M2iUp6CTXjgqoQEOaJOiiVpX1Ge1899p6RL87o0gL lZAG2rppP5vzcHs3OG2LfjxZktMpk75gp6jKsXzfkjVioc6l/mN+X7ja2VfxveVyJks1 CvV4+NbJOtyQxZaA3umnN9NaQJd0Bxs6r7zHi4KUMyr8I2mSjg/RGWZiHjRbXTqiHQAA FMYHkiOzAGLdYtyYy9CjBHLSWH0e1qHf0ADL2+FbwGLauGBKeGhoLFAybNKl+AVKNA7m b09A== X-Gm-Message-State: AMke39nvRq646XIg3FbDP956ehf96ZW8aYlkFKgsyQ357HCSGbt+rXCz9ctmgH+u0o1Pa4pihAre4C9Tbna0Gg== X-Received: by 10.55.123.5 with SMTP id w5mr44310698qkc.76.1487890676759; Thu, 23 Feb 2017 14:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.84.230 with HTTP; Thu, 23 Feb 2017 14:57:56 -0800 (PST) In-Reply-To: References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> From: Ngie Cooper Date: Thu, 23 Feb 2017 14:57:56 -0800 Message-ID: Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Alan Somers Cc: Jim Rowan , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:57:58 -0000 On Wed, Feb 22, 2017 at 10:12 AM, Alan Somers wrote: > I think I need to emphasize more that the key feature for me is Github > integration. I want to use one of these tools with a project that is > hosted in Github. It's not my project, so I can't move it even if I > wanted to. WJW's example gets half of the integration I would like; > he shows how Jenkins can pull information out of Github. But it > doesn't show how to push information back into Github. Does anybody > have any examples of using Jenkins, Bamboo, Buildbot etc to push build > pass/fail notifications back into Github? Having seen other integrations done, I think Buildbot/TravisCI are the most functional builder types out of the box with GitHub, but as you noted before, getting them to work with FreeBSD requires jumping through hoops. Here are some notes I found quickly with GitHub/Jenkins integration: https://jenkins.io/solutions/github/ . Personally, I don't care for the flat text file format with Jenkins for the following reasons: 1. It doesn't scale longterm, in particular it requires data retention policies/pruning to ensure that you don't slow down your Jenkins master too much with data. 2. IIRC writing the results/config isn't atomic. 3. Backups are harder to deal with. 4. Job files/templates a more painful to deal with, depending on how you design the Jenkins jobs. IMHO, it was a mistake I think for the Jenkins folks to not implement more intelligent database backends and storage methods for the logs. Also, Jenkins loves RAM (#thanksJava). Otherwise, I think Jenkins is fine for most tasks. My 2 cents, -Ngie From owner-freebsd-hackers@freebsd.org Fri Feb 24 00:25: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 A0797CEBDEC for ; Fri, 24 Feb 2017 00:25:17 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71531188F for ; Fri, 24 Feb 2017 00:25:17 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: by mail-pg0-x235.google.com with SMTP id 1so3130593pgi.1 for ; Thu, 23 Feb 2017 16:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=q0mtk5niBjxV25SRw2k0IBNpQhGZ2TX3/fx2CaQX60A=; b=GltuYCEhyjuFIFD0oLK88MgExDSmLU4DVe+LRvh3FDcmou5Nc23LMVWqBvvZvEdMaj d34ztYz715ulH4ZB20Y8ir8FbUCAL1Fd90K+l8wk6O0uNtjwQmWFyLsp7qtsAxtP748l rHMBpOtE3i3FjBtWMuUkG6j6Vq6rjRtCfJPw7rwsMOtvebXAzRSGaTaSRZ7b7073oyAM IFVCdwhMZPZz389dSBvFHbh8IuaoweNpdsWX1QIICs2uf8uVRajSWct3+QvTvkR3o2bX NmjkMcQGobHB72eSH0pAek944BDvrwn4E/tw3KIqWh0iTRpEPBmpALVeXrD4XIv2O+Dx a3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=q0mtk5niBjxV25SRw2k0IBNpQhGZ2TX3/fx2CaQX60A=; b=I05PzWdGvtym5Ikp4RqXO0hQHJ55He+QDufqWqv4r9MwusYr+GEeHaUMmC96eKnBpy E0GpieNnUpJWdFHN+gbwTlt1+k6f+u4cL8MEWV6DOWm48UNEv1oa8b5Q5uQ00gG1/ykT WyjTtwoy0UnanTDjZwgxVUvnaVkeBc+cptXJR2jLdcKHRrtOOmBIlW3BWjAS6I75Y+Ak BWufg4CqjBKjjkbNjLRr+EablPQqVFkE8P+U9TGR5VqTTjbtTuk3Pk1uu8oeP3IiUOCf nCORePuCmmIiF62OV8QNZ6L5RH+eHeGsH32qU2H2ENDoqTvZIkPSsO+585+zFoDFuSdC ssNg== X-Gm-Message-State: AMke39mpVjKqQc4hCgh95CATNJcU10uMjOz3z7l0pS687W4thVWBgUL8gR/TqZIvRrbEkw== X-Received: by 10.99.44.138 with SMTP id s132mr52261385pgs.88.1487895916850; Thu, 23 Feb 2017 16:25:16 -0800 (PST) Received: from f45c89a3ac23.sea.amazon.com (54-240-196-186.amazon.com. [54.240.196.186]) by smtp.gmail.com with ESMTPSA id 78sm9596508pfm.122.2017.02.23.16.25.16 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Feb 2017 16:25:16 -0800 (PST) From: Xiao Li Subject: FreeBSD TPM 2.0 Support? Message-Id: <690CB4BB-A27D-42D1-A6CA-A4650F6E8293@gmail.com> Date: Thu, 23 Feb 2017 16:25:15 -0800 To: Hackers freeBSD Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 00:25:17 -0000 Hi, I=E2=80=99ve been recently working on integrate my project base on = FreeBSD with a TPM 2.0 chip. The tpm-tools / tcsd I=E2=80=99ve been = using with a former Infineon TPM 1.2 chip does not compatible with the = new chip, even though I changed a bit of the tpm.ko so I could see tpm = device. I wonder if FreeBSD already have equivalent of tpm-tools for TPM = 2.0 chips.=20 I=E2=80=99ve been trying to use https://github.com/01org/TPM2.0-TSS = =20 and https://github.com/01org/tpm2.0-tools Each got some problems while building and I=E2=80=99m not quire sure if = they were supported with FreeBSD at all.=20 Any insights would be really helpful.=20 Thanks, X.L From owner-freebsd-hackers@freebsd.org Fri Feb 24 05:05: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 3B608CEB2D3 for ; Fri, 24 Feb 2017 05:05:39 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 288E21C83 for ; Fri, 24 Feb 2017 05:05:39 +0000 (UTC) (envelope-from takawata@init-main.com) Received: by mailman.ysv.freebsd.org (Postfix) id 24F06CEB2D2; Fri, 24 Feb 2017 05:05:39 +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 22F06CEB2D1 for ; Fri, 24 Feb 2017 05:05:39 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B180D1C82 for ; Fri, 24 Feb 2017 05:05:38 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id v1O4g0LG002798; Fri, 24 Feb 2017 13:42:00 +0900 (JST) (envelope-from takawata@sana.init-main.com) Received: (from takawata@localhost) by sana.init-main.com (8.14.3/8.14.3/Submit) id v1O4g0dp002797; Fri, 24 Feb 2017 13:42:00 +0900 (JST) (envelope-from takawata) Date: Fri, 24 Feb 2017 13:42:00 +0900 From: Takanori Watanabe To: Xiao Li Cc: hackers@freebsd.org Subject: Re: FreeBSD TPM 2.0 Support? Message-ID: <20170224044200.GA2784@sana.init-main.com> References: <690CB4BB-A27D-42D1-A6CA-A4650F6E8293@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <690CB4BB-A27D-42D1-A6CA-A4650F6E8293@gmail.com> User-Agent: Mutt/1.4.2.1i 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, 24 Feb 2017 05:05:39 -0000 On Thu, Feb 23, 2017 at 04:25:15PM -0800, Xiao Li wrote: > Hi, > > I$B!G(Bve been recently working on integrate my project base on FreeBSD with a TPM 2.0 chip. The tpm-tools / tcsd I$B!G(Bve been using with a former Infineon TPM 1.2 chip does not compatible with the new chip, even though I changed a bit of the tpm.ko so I could see tpm device. I wonder if FreeBSD already have equivalent of tpm-tools for TPM 2.0 chips. As far as I know, No. And not compatible with TPM 1.2 spec it seems. > Each got some problems while building and I$B!G(Bm not quire sure if they were supported with FreeBSD at all. > > Any insights would be really helpful. > > From owner-freebsd-hackers@freebsd.org Fri Feb 24 09:57:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E2E1CEB86A for ; Fri, 24 Feb 2017 09:57:37 +0000 (UTC) (envelope-from iblis@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13FFD31E; Fri, 24 Feb 2017 09:57:37 +0000 (UTC) (envelope-from iblis@hs.ntnu.edu.tw) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 800) id 7784A1C6450; Fri, 24 Feb 2017 17:49:12 +0800 (CST) Received: from abeing (IP-215-9.cs.nctu.edu.tw [140.113.215.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: iblis@hs.ntnu.edu.tw) by mail.hs.ntnu.edu.tw (Postfix) with ESMTPSA id 5B7B21C644A; Fri, 24 Feb 2017 17:49:12 +0800 (CST) Date: Fri, 24 Feb 2017 17:49:10 +0800 From: Iblis Lin To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins Message-ID: <20170224094909.GA79036@abeing> References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Bogosity: Ham, tests=bogofilter, spamicity=0.012724, version=1.2.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 09:57:37 -0000 Hi, If you are skilled at python, I will recommand BuildBot. There is a builtin Github reporter for handling push/pr state. I am currently working on a FreeBSD CI for Julia(https://github.com/JuliaLang/julia/issues/20585) You can checkout my repos: - https://github.com/iblis17/julia-fbsd-buildbot - https://github.com/iblis17/buildbot-freebsd and take a loop this testing: https://github.com/iblis17/julia/pull/3 -- Iblis Lin 林峻頤 From owner-freebsd-hackers@freebsd.org Fri Feb 24 11:22:08 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 811D8CEA120 for ; Fri, 24 Feb 2017 11:22:08 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 409DDF8B; Fri, 24 Feb 2017 11:22:08 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A8EBE3ACCF; Fri, 24 Feb 2017 12:22:03 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0k-BrxlJ4dT; Fri, 24 Feb 2017 12:22:02 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id DDFBE3ACCE; Fri, 24 Feb 2017 12:22:02 +0100 (CET) Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Ngie Cooper , Alan Somers References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> Cc: Jim Rowan , "freebsd-hackers@freebsd.org" From: Willem Jan Withagen Message-ID: <2b82244a-eb4d-b313-4d01-5c0212c5168d@digiware.nl> Date: Fri, 24 Feb 2017 12:22:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 11:22:08 -0000 On 23-2-2017 23:57, Ngie Cooper wrote: > Also, Jenkins loves RAM (#thanksJava). That is really a major understatement: 715 jenkins 66 52 0 10401M 2987M uwait 0 25:16 1.07% java That is: 10G footprint, and almost 3G resident. It is on a 32Gb build VM, but still .... So make sure your builders are big enough, especially if you are adding ZFS and CCACHE into the equation. --WjW From owner-freebsd-hackers@freebsd.org Fri Feb 24 11:26: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 C7270CEA303 for ; Fri, 24 Feb 2017 11:26:24 +0000 (UTC) (envelope-from iblis@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94ED312B9; Fri, 24 Feb 2017 11:26:24 +0000 (UTC) (envelope-from iblis@hs.ntnu.edu.tw) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 800) id 9599B1C644F; Fri, 24 Feb 2017 19:26:15 +0800 (CST) Received: from abeing (IP-215-9.cs.nctu.edu.tw [140.113.215.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: iblis@hs.ntnu.edu.tw) by mail.hs.ntnu.edu.tw (Postfix) with ESMTPSA id 3120D1C644A; Fri, 24 Feb 2017 19:26:15 +0800 (CST) Date: Fri, 24 Feb 2017 19:26:14 +0800 From: Iblis Lin To: Alan Somers Cc: Jim Rowan , "freebsd-hackers@freebsd.org" Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins Message-ID: <20170224112613.GA31394@abeing> References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Bogosity: Ham, tests=bogofilter, spamicity=0.480066, version=1.2.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 11:26:24 -0000 On Wed, Feb 22, 2017 at 11:12:14AM -0700, Alan Somers wrote: > I think I need to emphasize more that the key feature for me is Github > integration. I want to use one of these tools with a project that is > hosted in Github. It's not my project, so I can't move it even if I > wanted to. WJW's example gets half of the integration I would like; > he shows how Jenkins can pull information out of Github. But it > doesn't show how to push information back into Github. Does anybody > have any examples of using Jenkins, Bamboo, Buildbot etc to push build > pass/fail notifications back into Github? > > -Alan > _______________________________________________ > 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" Just found this: https://github.com/buildbot/buildbot_travis -- Iblis Lin 林峻頤 From owner-freebsd-hackers@freebsd.org Fri Feb 24 17:35: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 9172BCEB50A for ; Fri, 24 Feb 2017 17:35:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE2A1DD9 for ; Fri, 24 Feb 2017 17:35:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22e.google.com with SMTP id q127so12951697ywg.0 for ; Fri, 24 Feb 2017 09:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Cs/FPbq5gMH+R5w7C6ifOeb3Ycb51o31zKZAXPikec8=; b=frZzHTHek1zcd/rit49n7dT3Kxtgl2NixIgN1BMq6Uw4+NqphBfSewx3yCkkV9x6XJ 9alnBY2aHe9HbgSeX5fUHgOBBFDRZIaQzC45nxc4LAn1EJviAIwI9S0DTipgDbP7LzKN yJOgfGLiKxlIu+0OzCVLkMycUJPocpj18VE6zxbsidfGw6wDc7cCKtkRmtGBfyPwTw8c ldsz/NF/nSffPQlgaDZub3eUsQ5SylTtCX2fVmNNv/rV2SvDODPAro3hQgCa+UNRZfwh VwAz6/ebkX3QpPxG+ON1SWUcKYXHzsvSEr8vgfXYqGxw1V3thbd0RjTTX+GSXB/URgxl /CnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Cs/FPbq5gMH+R5w7C6ifOeb3Ycb51o31zKZAXPikec8=; b=iLDb6SGCC9gLD+H5a+qQbdRXt8V+taABkeTAhY/2del/RC2VC4O6qeZ/GFDdzPH+sQ NEaWTgPBQkU7w2iHJIib4lNcLlKLkGREm1oi8I6zUAajfY93PaRcNmJILIujMZtXQkas 6STAgdAf/GK0gNlVLgGab7yDfWbwWNIqDAOK2OyzWzxW4W8kxDBiPTODZ+252ilA6GWi 7jYdPryiykQPoC6jOXAZoNfiYJirhODMryjs5GIYPquCJP21209bkL0agFH44Zf6j7Im mTWkLuDcstpQmE23X+d9BHEKRH+Xmre/eGXK4H6sLhcWXmO+S3+YKKbzLhovhIK5AnCm wQhw== X-Gm-Message-State: AMke39kJIwWcAN2KCXJWKg+iPIsPzCN7z+88vLLXJbViCs7kBOOJ81zoLno2Y8zSQmNBL2l5NT8YP2JRVilLYg== X-Received: by 10.129.68.31 with SMTP id r31mr2309102ywa.307.1487957718421; Fri, 24 Feb 2017 09:35:18 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Fri, 24 Feb 2017 09:35:17 -0800 (PST) In-Reply-To: <20170224112613.GA31394@abeing> References: <91A98293-35F0-4C27-993D-01F40B28B92E@computing.com> <20170224112613.GA31394@abeing> From: Alan Somers Date: Fri, 24 Feb 2017 10:35:17 -0700 X-Google-Sender-Auth: e4lQtEXE9MkSfWKDx0UstBjB410 Message-ID: Subject: Re: TravisCI vs BuildBot vs Bamboo vs Jenkins To: Iblis Lin Cc: Jim Rowan , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:35:19 -0000 Iblis, that's exactly what I'm looking for. I think I'll try copying your setup when I'm ready, which will probably be in about a month. I like that Buildbot is thriftier with RAM than Jenkins, and I know Python decently well. Iblis's Github integration looks good too. Thanks for all the advice, everyone. -Alan On Fri, Feb 24, 2017 at 4:26 AM, Iblis Lin wrote: > On Wed, Feb 22, 2017 at 11:12:14AM -0700, Alan Somers wrote: >> I think I need to emphasize more that the key feature for me is Github >> integration. I want to use one of these tools with a project that is >> hosted in Github. It's not my project, so I can't move it even if I >> wanted to. WJW's example gets half of the integration I would like; >> he shows how Jenkins can pull information out of Github. But it >> doesn't show how to push information back into Github. Does anybody >> have any examples of using Jenkins, Bamboo, Buildbot etc to push build >> pass/fail notifications back into Github? >> >> -Alan >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" > > Just found this: https://github.com/buildbot/buildbot_travis > > -- > Iblis Lin > =E6=9E=97=E5=B3=BB=E9=A0=A4 From owner-freebsd-hackers@freebsd.org Fri Feb 24 21:26: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 4280DCEBDB2 for ; Fri, 24 Feb 2017 21:26:31 +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 2D327954; Fri, 24 Feb 2017 21:26:31 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 7DD2D56483; Fri, 24 Feb 2017 15:26:30 -0600 (CST) Subject: Re: Absolute timeouts and clock adjustments To: Ian Lepore , Sebastian Huber , FreeBSD References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> <1487778365.73144.144.camel@freebsd.org> From: Eric van Gyzen Message-ID: Date: Fri, 24 Feb 2017 15:26:28 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1487778365.73144.144.camel@freebsd.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: Fri, 24 Feb 2017 21:26:31 -0000 > Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly asks > for the current behavior. If the behavior you need is to wake up when > CLOCK_REALTIME exceeds some value, you're still screwed. > > It would be easy enough to fix the current behavior by adding something > like "if (timo > hz) timo = hz;" to the existing loop so that > CLOCK_REALTIME gets re-checked once a second. That would work, but I don't really like introducing spurious wakeups just to handle a very rare event. How about this approach? https://reviews.freebsd.org/D9791 It's also not ideal, and it's obviously much larger than your suggestion, but it's very cheap in the common paths. Eric From owner-freebsd-hackers@freebsd.org Sat Feb 25 20:02:44 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 4A10ECED514 for ; Sat, 25 Feb 2017 20:02:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7EA1BD3 for ; Sat, 25 Feb 2017 20:02:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 57d932c1-fb95-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 57d932c1-fb95-11e6-95b5-6dfd7dbb0ee5; Sat, 25 Feb 2017 20:02:33 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1PK2Nmt001833; Sat, 25 Feb 2017 13:02:23 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488052943.25520.72.camel@freebsd.org> Subject: Re: Absolute timeouts and clock adjustments From: Ian Lepore To: Eric van Gyzen , Sebastian Huber , FreeBSD Date: Sat, 25 Feb 2017 13:02:23 -0700 In-Reply-To: References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> <1487778365.73144.144.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 20:02:44 -0000 On Fri, 2017-02-24 at 15:26 -0600, Eric van Gyzen wrote: > > > > Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly > > asks > > for the current behavior.  If the behavior you need is to wake up > > when > > CLOCK_REALTIME exceeds some value, you're still screwed. > > > > It would be easy enough to fix the current behavior by adding > > something > > like "if (timo > hz) timo = hz;" to the existing loop so that > > CLOCK_REALTIME gets re-checked once a second. > That would work, but I don't really like introducing spurious wakeups > just to  > handle a very rare event. > > How about this approach? > > https://reviews.freebsd.org/D9791 > > It's also not ideal, and it's obviously much larger than your > suggestion, but  > it's very cheap in the common paths. I would rather add low-frequency wakeups to handle a rare event than all that extra code complexity.  Anyone who requires real sleep accuracy won't be relying on a single call to nail the return time anyway.  The point of a 1hz wakeup is that it's cheap and easy to implement and good enough to keep code with casual timing requirements from locking up forever after a big clock step (which tends to happen on embedded systems without battery backed clocks). For code that really cares about accuracy (like basically everything we do at $work), the userland code will do its own looping, with a series of long sleeps (typically at 1hz) followed by a series of decreasing- length microsleeps to get the time right.  That's immune to ntpd/ptpd steering the clock hard, leap seconds, and other things that perturb accurate sleeps. But all in all, I don't have strong feelings about it either way. -- Ian From owner-freebsd-hackers@freebsd.org Sat Feb 25 22:44: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 29256CED5BC for ; Sat, 25 Feb 2017 22:44:39 +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 3FC55F9; Sat, 25 Feb 2017 22:44:37 +0000 (UTC) (envelope-from pkubaj@anongoth.pl) Received: from anongoth.pl (89-73-168-94.dynamic.chello.pl [89.73.168.94]) (using TLSv1.2 with cipher ECDHE-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 0ABCAF361; Sat, 25 Feb 2017 23:44:25 +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=1488062666; bh=wY2CIhrL5rrS11HfyRbOplXb2S6HwG8APKeusYEWyHM=; h=Date:From:To:Subject; b=ZxmtKqRhbHwrZj3sNvfZ09FwJyvxdxR3CZJsead+MV9gXs2k2jJT4eQrX1sg886C6 xI+yf2aU1vdWx2zFQNmGtlh61ctd2MFBAruLjR0ZVqKBgcVQXYV4FAXRyTHMXphuso Lx26PXa4bERjJ7vTZgbtieo8k5rsBmyCsKwqRk1/IG0W6tA2skiwioEZPSbGvgOqWv AtPCdAZlWEKLnnj11sGrmx2/ny0PLmpzTXXbO0V1reO1K4ilCyv6+X3le8fIZTtDzs CUF6LY38TD/FULePGkkgNZfBpFFnYjRv0wBfxSBCH510EvTxyGiOjuvSrHeolzUYbm 76Qm+JIW+HH7w== Date: Sat, 25 Feb 2017 23:44:25 +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: <20170225224425.GA93825@DESKTOP1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-Mailman-Approved-At: Sat, 25 Feb 2017 23:00:55 +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, 25 Feb 2017 22:44:39 -0000 --3lcZGd9BuhuYXNfi Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Are you able to capture a full verbose dmesg via a serial console or the = like > that would really help as it may be that we are seeing a resource conflict > 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. Sorry for the lag, but I didn't have the null cable, the I moved to another= flat and then I got married :) I'm attaching the full verbose dmesg log from Coreboot git compiled today a= nd FreeBSD 11.0-RELEASE. --=20 __________________________=20 / Come home America. \ | | \ -- George McGovern, 1972 / --------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="dmesg.log" Content-Transfer-Encoding: quoted-printable 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 LLVM = 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-class = CPU) Origin=3D"AuthenticAMD" Id=3D0x610f01 Family=3D0x15 Model=3D0x10 Step= ping=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 associat= ive 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 associati= ve 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 000= 00000) ACPI: FACP 0x00000000BFFB0B10 0000F4 (v04 CORE COREBOOT 00000000 CORE 000= 00000) ACPI: DSDT 0x00000000BFFAF280 00188F (v02 ASUS COREBOOT 00010001 INTL 201= 60831) ACPI: FACS 0x00000000BFFAF240 000040 ACPI: SSDT 0x00000000BFFB0C10 00008A (v02 CORE COREBOOT 0000002A CORE 000= 0002A) ACPI: TCPA 0x00000000BFFB0CA0 000032 (v02 CORE COREBOOT 00000000 CORE 000= 00000) ACPI: APIC 0x00000000BFFB0CE0 000072 (v01 CORE COREBOOT 00000000 CORE 000= 00000) ACPI: HPET 0x00000000BFFB0D60 000038 (v01 CORE COREBOOT 00000000 CORE 000= 00000) ACPI: HEST 0x00000000BFFB0DA0 0001D0 (v01 CORE COREBOOT 00000000 CORE 000= 00000) ACPI: IVRS 0x00000000BFFB0F70 000070 (v02 AMD AMDIOMMU 00000001 AMD 000= 00000) ACPI: SSDT 0x00000000BFFB0FE0 00051F (v02 AMD ALIB 00000001 MSFT 040= 00000) ACPI: SSDT 0x00000000BFFB1500 000D40 (v01 AMD POWERNOW 00000001 AMD 000= 00001) 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 [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_ra= te_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 (990000= 22) 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, adjustment= 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, ena= bled pcib1: allocated prefetch range (0xe8000000-0xefffffff) for rid 14 of pci0:= 1:0:0 map[1c]: type Prefetchable Memory, range 64, base 0xf0000000, size 25, ena= bled pcib1: allocated prefetch range (0xf0000000-0xf1ffffff) for rid 1c of pci0:= 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-0xef= ffffff,0xf0000000-0xf1ffffff at device 0.0 on pci1 vgapci0: Boot video device hdac0: mem 0xf3080000-0xf3083fff at device= 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 dev= ice 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 dev= ice 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-0x4023= ,0x4018-0x401f,0x4024-0x4027,0x4000-0x400f mem 0xf348b000-0xf348b7ff at dev= ice 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 device = 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 dev= ice 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 device = 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 dev= ice 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 d= evice 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 n= s) 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-0xf= 31000ff 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 device = 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 24Mbp= s 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, ena= bled pcib4: allocated prefetch range (0xf3304000-0xf3304fff) for rid 18 of pci0:= 4:0:0 map[20]: type Prefetchable Memory, range 64, base 0xf3300000, size 14, ena= bled pcib4: allocated prefetch range (0xf3300000-0xf3303fff) for rid 20 of pci0:= 4:0:0 re0: port 0x300= 0-0x30ff mem 0xf3304000-0xf3304fff,0xf3300000-0xf3303fff at device 0.0 on p= ci4 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, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-F= DX-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 misc 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 misc 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 D= ISA 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 KHz 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 KHz 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 KHz 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 misc 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 misc hdaa1: 17 99430140 4 0 SPDIF-out Fixed ATAPI Onboard Unknown 1 hdaa1: 18 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA 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 D= ISA hdaa1: 30 01456130 3 0 SPDIF-out Jack Optical Rear Orange 1 hdaa1: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1 D= ISA 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 o= n 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 F= requency 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 8192bytes) 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 u= sbus3 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]... start_init: trying /sbin/init ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=3D0 --ikeVEW9yuYc//A+q-- --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAliyCMkACgkQelmbhSCD nJ1mHA//eHv+r3zvaFoURY1CVNpt0v5J0D/2sBd1FHSSybgklOlfZY0suTNhgccI 3SIvrI1MJbSzuBoU2ssAPyEflFXIQll0+dCUivSFNetPGnRIA9PGQeE3xPXJDWwv G+KgxZEk7n830FegTASLCCqsOAdZZxqnJcTOPHdsDnV4cKCJRrlSbafjTmwUsO6C Tz4+MV+JDpoIIZdgT9L/2ZW5HUTYzDxxFsei75OIxp2OV2kokllH6klB0T9MMMd0 Ur5w+OyDe73qcpTwPapaD5JoEwSkog7AFSPeVKR+YZZW0TApVMRvqZFzrvQ6a7aB aovGxuXzrLIyWLnLoYojqz/orxvWDfSOJaDW6YBnqxfubDbngUNEnso4W423pWtf R5isEC+nyD63ssPgKyxOiALiTssv0Lk15eT2adsA8ZQQReg0EXYb8Mq1iN965XqZ A9dWz1DN4gJnu+OCWXeWyHVg6NTe01Ue5CN/Iz7etVIs1f7m//aj13BfOTwExlIN ikq+56hTYXcR7xPgoKBqdG1K0sjBNL3A8JO5ywJQgTpMDwtvmmttXEhYK+maTvEG 0twTqsUbhWDomH9ajsLAQOe1kqNYAfOXArruWLVkkBURXJA0twUDUqZJ2orGkIYI O20UE/ERRTxOBTkhuC9ssiK8MK5VTuSyrG74b7RwSh9pEaeTLiM= =hLdF -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi--