From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 11:24:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07ACF106567B for ; Sun, 22 Jan 2012 11:24:40 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B17CF8FC21 for ; Sun, 22 Jan 2012 11:24:39 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 65AECE0E for ; Sun, 22 Jan 2012 12:24:36 +0100 (CET) Date: Sun, 22 Jan 2012 12:23:22 +0100 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20120122112322.GF1723@garage.freebsd.pl> References: <201201212112.q0LLCrQn009840@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+ts6NCQ4mrNQIV8p" Content-Disposition: inline In-Reply-To: <201201212112.q0LLCrQn009840@svn.freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Snapshot listing speedup. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 11:24:40 -0000 --+ts6NCQ4mrNQIV8p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If you have many snapshots and you were complaining that listing them takes a lot of time, you may find the commit below useful. It only works if your listing is limited to snapshot names and you want to sort also by snapshot name (by default snapshots are sorted by creation time). On Sat, Jan 21, 2012 at 09:12:53PM +0000, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Sat Jan 21 21:12:53 2012 > New Revision: 230438 > URL: http://svn.freebsd.org/changeset/base/230438 >=20 > Log: > Dramatically optimize listing snapshots when user requests only snapshot > names and wants to sort them by name, ie. when executes: > =20 > # zfs list -t snapshot -o name -s name > =20 > Because only name is needed we don't have to read all snapshot properti= es. > =20 > Below you can find how long does it take to list 34509 snapshots from a= single > disk pool before and after this change with cold and warm cache: > =20 > before: > =20 > # time zfs list -t snapshot -o name -s name > /dev/null > cold cache: 525s > warm cache: 218s > =20 > after: > =20 > # time zfs list -t snapshot -o name -s name > /dev/null > cold cache: 1.7s > warm cache: 1.1s --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --+ts6NCQ4mrNQIV8p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8b8aoACgkQForvXbEpPzStzACgpBTvvkyoSEDSX8w8LFWI9ve9 JlkAnA8wZ5IpfAFIEJyROXhRS7+pe3nK =HEIJ -----END PGP SIGNATURE----- --+ts6NCQ4mrNQIV8p-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 15:16:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744621065670 for ; Sun, 22 Jan 2012 15:16:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50D308FC16 for ; Sun, 22 Jan 2012 15:16:51 +0000 (UTC) Received: by dadi14 with SMTP id i14so1681707dad.13 for ; Sun, 22 Jan 2012 07:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Rs0lDE9DhA/dlvpBsqlE8YmVf0/pO2Y8rc5ecKuv2Ak=; b=ncNQLUd/Ywfn5VLZRw/cZik4B1/rN2Z6G5IsOn35x5yASDSkGGTE2A4Z5hopFVsAbm wjPR+ix1WERrIJ8Jiz7PCRWKAbsrCd+mPY8Oq26MN5zEqaYafKCGXgT5QhF/8m4SFhph vG3ejfgcBpqy8GHqW+JEA5g3wOJ5pdqnmCTCI= MIME-Version: 1.0 Received: by 10.68.116.237 with SMTP id jz13mr13804939pbb.100.1327243912485; Sun, 22 Jan 2012 06:51:52 -0800 (PST) Received: by 10.68.136.106 with HTTP; Sun, 22 Jan 2012 06:51:52 -0800 (PST) Date: Sun, 22 Jan 2012 09:51:52 -0500 Message-ID: From: Super Bisquit To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 15:16:52 -0000 # sysctl legal.intel_iwi.license_ack=1 sysctl: unknown oid 'legal.intel_iwi.license_ack' On 9.0, the XML type input does not include the intel license. I switched to 8.2 thinking that it was the release; however, that is not the case. What is the fix to this? I'm using 5.5GB of space for my install; building kernel and world is out of the question. From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 15:32:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1CA7106566C for ; Sun, 22 Jan 2012 15:32:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BFB458FC14 for ; Sun, 22 Jan 2012 15:32:01 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 378EB60DF; Sun, 22 Jan 2012 10:32:00 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=TUsGHEdrNVX26SVzk4JbM6pkcXdhH2/Z2l0bjWLhl59P3lHAGZU/JB2uh9jhADgf5 WpBy9WESOXVf8iIkdo8Y2Aub4LFVB5u9vkvCYtINIXN+YL6KnwPeYPDsyje6vtN Message-ID: <4F1C2BED.2080805@protected-networks.net> Date: Sun, 22 Jan 2012 10:31:57 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Super Bisquit References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 15:32:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/12 09:51, Super Bisquit wrote: > # sysctl legal.intel_iwi.license_ack=1 > sysctl: unknown oid 'legal.intel_iwi.license_ack' > > On 9.0, the XML type input does not include the intel license. > > I switched to 8.2 thinking that it was the release; however, that is not > the case. > > What is the fix to this? This should go in /boot/loader.conf imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cK+wACgkQQv9rrgRC1JLH6QCZAQrkrErVrInoyqfKoKkYPkDE HvwAmwWfBkrhSPwzxR358N8wPkGx+rtN =8uCP -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 16:35:41 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F13C10656DF; Sun, 22 Jan 2012 16:35:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 106F78FC19; Sun, 22 Jan 2012 16:35:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0MGZd8V029315; Sun, 22 Jan 2012 20:35:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0MGZdRI029314; Sun, 22 Jan 2012 20:35:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 22 Jan 2012 20:35:39 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120122163539.GF16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1ABFF3.9090305@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:35:41 -0000 On Sat, Jan 21, 2012 at 03:38:59PM +0200, Andriy Gapon wrote: A> on 20/01/2012 17:41 Gleb Smirnoff said the following: A> > A> > On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: A> > T> New panic has been introduced somewhere between A> > T> r229851 and r229932, that happens on shutdown if A> > T> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. A> > A> > I've run through binary search and panic was introduced A> > by r229854. A> > A> A> Which means that it was introduced by one of the earlier commits (probably A> mine). Thank you for this investigative work! A> Although, to be frank and honest, I still don't see how the problem could be A> a non-issue before. I can confirm that I can reboot succesfully with a new kernel and kern.stop_scheduler_on_panic=0. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 17:46:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12870106564A for ; Sun, 22 Jan 2012 17:46:23 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE1CE8FC08 for ; Sun, 22 Jan 2012 17:46:22 +0000 (UTC) Received: by pbcc13 with SMTP id c13so1758398pbc.13 for ; Sun, 22 Jan 2012 09:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mXGtIaIZNafMsD0fvACCXiCeRBCmZrJzfPqN307EnG8=; b=VIeJJS7xF/cO9f4fflMytkSxzxpbUcHBMTkbzTnkv+rmJIFcAmFAbMftgmo9MGXbNj M8Tsrs0XiPnXpSB+ZNpzHnclMtR1gSQcw3HXncV4P7qGGSZtGf6L9mv3S7KGLh0QsiOU aoZpwOKiWyBiD7bBJVeXp2StVQV3Eu1WQgMWA= MIME-Version: 1.0 Received: by 10.68.211.198 with SMTP id ne6mr15009136pbc.83.1327254381880; Sun, 22 Jan 2012 09:46:21 -0800 (PST) Received: by 10.68.136.106 with HTTP; Sun, 22 Jan 2012 09:46:21 -0800 (PST) In-Reply-To: <4F1C2BED.2080805@protected-networks.net> References: <4F1C2BED.2080805@protected-networks.net> Date: Sun, 22 Jan 2012 12:46:21 -0500 Message-ID: From: Super Bisquit To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 17:46:23 -0000 No dice, people. It isn't doing diddly. # ifconfig -a iwi0: flags=8802 metric 0 mtu 2290 ether 00:0e:35:53:a9:fe media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 02:e0:b8:00:ba:fb ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 0.e0.b8.5.0.0.ba.fb.a.2.ff.fe.0.0.0.0 fxp0: flags=8843 metric 0 mtu 1500 options=2009 ether 00:e0:b8:6d:68:0b inet 98.211.110.13 netmask 0xffffff00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 # ifconfig wlan create wlandev iwi0 ifconfig: SIOCIFCREATE2: Input/output error # kldload if_iwi kldload: can't load if_iwi: File exists # kldload iwi_bss kldload: can't load iwi_bss: File exists # kldload iwi_ibss # kldload iwi_monitor # ifconfig wlan create wlandev iwi0 ifconfig: SIOCIFCREATE2: Input/output error # sysctl legal.intel_iwi.license_ack=1 sysctl: unknown oid 'legal.intel_iwi.license_ack' Yet the sysctl variable is on the man page http://www.freebsd.org/cgi/man.cgi?query=iwi&apropos=0&sektion=0&manpath=FreeBSD+8-current&format=html The firmware module was created and installed. /boot/loader.conf has legal.intel_iwi.license_ack=1 if_iwi_load="YES" hw.physmem="1300M" atapicam_load="YES" wlans_iwi0="wlan" ifconfig_wlan0="DHCP" On Sun, Jan 22, 2012 at 10:31 AM, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/22/12 09:51, Super Bisquit wrote: > > # sysctl legal.intel_iwi.license_ack=1 > > sysctl: unknown oid 'legal.intel_iwi.license_ack' > > > > On 9.0, the XML type input does not include the intel license. > > > > I switched to 8.2 thinking that it was the release; however, that is not > > the case. > > > > What is the fix to this? > > This should go in /boot/loader.conf > > imb > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8cK+wACgkQQv9rrgRC1JLH6QCZAQrkrErVrInoyqfKoKkYPkDE > HvwAmwWfBkrhSPwzxR358N8wPkGx+rtN > =8uCP > -----END PGP SIGNATURE----- > From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 21:44:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A25106566C; Sun, 22 Jan 2012 21:44:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 52A5E8FC12; Sun, 22 Jan 2012 21:44:53 +0000 (UTC) Received: by vbbey12 with SMTP id ey12so2247730vbb.13 for ; Sun, 22 Jan 2012 13:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBUrWi4mVn/+nKyS72i0Be9qGuOn77fO/G5Cozlo5yE=; b=rqVoXTbAloKzvtkViGTAcYXNKRX1TISY8UfnHX+cm6HVOff5SrRbkPtyLJYVBnMtvr 96FPwoioiS2MNlnMp9rFBPNJhLqa2FwFzZyFFCD8etN9u08nWfS7oHiXE56Y6Nwr46e1 KUbwdQpcxcd7X/y9GwIqv4AG9qC2MJ9sf+qFY= MIME-Version: 1.0 Received: by 10.52.33.239 with SMTP id u15mr2712409vdi.49.1327268693501; Sun, 22 Jan 2012 13:44:53 -0800 (PST) Received: by 10.220.117.11 with HTTP; Sun, 22 Jan 2012 13:44:53 -0800 (PST) Received: by 10.220.117.11 with HTTP; Sun, 22 Jan 2012 13:44:53 -0800 (PST) In-Reply-To: <20120122112322.GF1723@garage.freebsd.pl> References: <201201212112.q0LLCrQn009840@svn.freebsd.org> <20120122112322.GF1723@garage.freebsd.pl> Date: Sun, 22 Jan 2012 13:44:53 -0800 Message-ID: From: Freddie Cash To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Snapshot listing speedup. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 21:44:54 -0000 On Jan 22, 2012 3:26 AM, "Pawel Jakub Dawidek" wrote: > > If you have many snapshots and you were complaining that listing them > takes a lot of time, you may find the commit below useful. > > It only works if your listing is limited to snapshot names and you want > to sort also by snapshot name (by default snapshots are sorted by > creation time). Would this have any effect on the speed of an 'ls' in the .zfs/snapshot/ directory? I'm guessing not, since that would have more to do with generic directory listings and general slowness in 'ls'. But one can dream. :) Afterall, the 'ls' *is* just querying the name and not all of the other ZFS properties. :D We do most of our snapshot accesses and listing via the .zfs/snapshot/ directory, which can take several seconds before the list starts to appear when there's a couple of hundred snapshots there. From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 22:05:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70FAA1065670 for ; Sun, 22 Jan 2012 22:05:12 +0000 (UTC) (envelope-from rcm@fuzzwad.org) Received: from mail.volente.us (unknown [IPv6:2001:470:7:d47::2]) by mx1.freebsd.org (Postfix) with ESMTP id 195BA8FC08 for ; Sun, 22 Jan 2012 22:05:11 +0000 (UTC) Received: from shiny-w0.fuzzwad.net (localhost [127.0.0.1]) by mail.volente.us (8.14.4/8.14.4) with ESMTP id q0MM5AEY093221 for ; Sun, 22 Jan 2012 16:05:11 -0600 (CST) (envelope-from rcm@fuzzwad.org) Message-ID: <4F1C8816.5030104@fuzzwad.org> Date: Sun, 22 Jan 2012 16:05:10 -0600 From: Ron McDowell User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: i18n and shell scripts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:05:12 -0000 I'm working on the new bsdconfig, and looking for some good examples of how to incorporate internationalization into the scripts. I'm not finding much love in this area. :-( Any pointers appreciated. -- Ron McDowell San Antonio TX From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 22:19:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAE4106566C for ; Sun, 22 Jan 2012 22:19:14 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7269E8FC13 for ; Sun, 22 Jan 2012 22:19:14 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 2AD4D60DF; Sun, 22 Jan 2012 17:19:13 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=E9auwsDJwUcVkpS3xZewR0kLcWXRbhWhLrOOF2huqujTFM9osBJyQepxdD615BL/8 vE3baco8n+FA3czNjE2HN3rVPWT55CHCOPZ5GbxuWQ8obg7duLxmhNHXIMzpGzB Message-ID: <4F1C8B5F.8040204@protected-networks.net> Date: Sun, 22 Jan 2012 17:19:11 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Super Bisquit References: <4F1C2BED.2080805@protected-networks.net> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:19:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/12 12:46, Super Bisquit wrote: > No dice, people. It isn't doing diddly. You did, of course, reboot after adding the license ack to /boot/loader.conf .. imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8ci14ACgkQQv9rrgRC1JIFZwCfXw7kNPy8ITMEDO+FcPdMmC28 zccAoJxLd1dO7kfEQOXqMzKSUtH88uib =SeH1 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 22:30:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1502D106566C for ; Sun, 22 Jan 2012 22:30:46 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C90998FC16 for ; Sun, 22 Jan 2012 22:30:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0MMUioa098772; Sun, 22 Jan 2012 22:30:44 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 8wxxnga825thdhwieziihq94m2; Sun, 22 Jan 2012 22:30:44 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: <4F1C8816.5030104@fuzzwad.org> Date: Sun, 22 Jan 2012 14:30:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1C8816.5030104@fuzzwad.org> To: Ron McDowell X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current Subject: Re: i18n and shell scripts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:30:46 -0000 On Jan 22, 2012, at 2:05 PM, Ron McDowell wrote: > I'm working on the new bsdconfig, and looking for some good examples = of how to incorporate internationalization into the scripts. I'm not = finding much love in this area. :-( >=20 > Any pointers appreciated. GNU gettext may not be an option here, but the documentation at http://www.gnu.org/software/gettext/manual/gettext.html#sh outlines how this can be done. The general model used by gettext and lots of other translation systems = is: * There's a distinctive function name or source code pattern wrapping = the English text strings. * So you can run a simple program that identifies and extracts these = strings. (Simple sed or awk scripts often suffice.) * Translation files map English text =3D=3D> translated text. (There = are many more-or-less standard formats used for translation files; the = .po format used by gettext is widely supported by translation tools. In = particular, there are a number of commercial translation management = interfaces that allow free use by open-source projects and can directly = upload/download po files.) * Translation files can be compiled into some dictionary structure = that can be used efficiently at run time. * The "distinctive source code pattern" above is typically a function = name. At run-time, that function looks up the English text string from = the source file and emits the result. Nothing here is difficult to just build from scratch. The complex part = is the process for actually keeping track of what has and hasn't been = translated across a large number of languages. Fortunately, there are = some pretty good translation management systems on the web where you can = upload .po files, invite people to contribute translations and then = download constructed .po files for each language. At work, we've = started using getLocalization.com, which looks pretty promising, but = there are many others. Warning: Translating quantities (e.g., "$x bytes") is complicated (why = does 'zero' take a plural in English?). You can sometimes just avoid it = ("size in bytes: $x") and sometimes get by with stilted language (e.g., = "1 bytes" or "$x byte(s)"). If you require high-quality handling of = phrases that include variable numbers, then you'll need something more = complex than just a lookup table. Cheers, Tim From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 22:39:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 869021065673; Sun, 22 Jan 2012 22:39:53 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD048FC0A; Sun, 22 Jan 2012 22:39:52 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0MMdpwJ089083; Mon, 23 Jan 2012 02:39:51 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0MMdpGD089082; Mon, 23 Jan 2012 02:39:51 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 23 Jan 2012 02:39:51 +0400 From: Yuri Pankov To: Pawel Jakub Dawidek Message-ID: <20120122223951.GA10149@sirius.xvoid.org> References: <201201212112.q0LLCrQn009840@svn.freebsd.org> <20120122112322.GF1723@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120122112322.GF1723@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Snapshot listing speedup. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:39:53 -0000 On Sun, Jan 22, 2012 at 12:23:22PM +0100, Pawel Jakub Dawidek wrote: > If you have many snapshots and you were complaining that listing them > takes a lot of time, you may find the commit below useful. > > It only works if your listing is limited to snapshot names and you want > to sort also by snapshot name (by default snapshots are sorted by > creation time). [...] Thanks Pawel, this looks extremely useful. A bit of off-topic - are you planning to submit these changes to illumos? Yuri From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 22:50:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66DF5106564A for ; Sun, 22 Jan 2012 22:50:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id ED8E18FC0C for ; Sun, 22 Jan 2012 22:50:38 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 4855035962E; Sun, 22 Jan 2012 23:50:38 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2B94228468; Sun, 22 Jan 2012 23:50:38 +0100 (CET) Date: Sun, 22 Jan 2012 23:50:38 +0100 From: Jilles Tjoelker To: Ron McDowell Message-ID: <20120122225037.GC33235@stack.nl> References: <4F1C8816.5030104@fuzzwad.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F1C8816.5030104@fuzzwad.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: i18n and shell scripts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:50:39 -0000 On Sun, Jan 22, 2012 at 04:05:10PM -0600, Ron McDowell wrote: > I'm working on the new bsdconfig, and looking for some good examples of > how to incorporate internationalization into the scripts. I'm not > finding much love in this area. :-( > Any pointers appreciated. Yes, this is not very easy, and particularly not if you only want to use base system functionality. An important thing is printf(1) as it will let you put placeholders for variables in translatable strings rather than build strings from hard to understand pieces. (Our printf(1) does not support changing the order of variables like the printf(3) function does.) With GNU gettext (which is in ports, not in base), you can translate messages in a shell script much like in a C program, although you will be invoking the gettext(1) tool rather frequently, which may be slow. It has many features to help the programmer and the translator. This also means that it can be fairly complicated to use. Alternatively, you could do it yourself. One way would be to define a variable for each translatable string with the default language's value, then source a file for the appropriate language (mylang=${LC_ALL-${LC_MESSAGES-${LANG}}}). Supporting multiple character sets is going to be ugly because we do not have any form of iconv (character set conversion) in base. This is particularly bad because syscons does not support UTF-8 while many users want to use UTF-8 in X instead of language-specific character sets. The base catgets(3) facility does not provide a utility for use from shell scripts, and is also harder to use than gettext. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Jan 22 16:02:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38D27106564A for ; Sun, 22 Jan 2012 16:02:56 +0000 (UTC) (envelope-from andreast@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id ACAAD8FC08 for ; Sun, 22 Jan 2012 16:02:54 +0000 (UTC) Received: from t43.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id q0MFHvoi065241; Sun, 22 Jan 2012 16:18:00 +0100 (CET) (envelope-from andreast@fgznet.ch) Message-ID: <4F1C29F4.9070205@fgznet.ch> Date: Sun, 22 Jan 2012 16:23:32 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Super Bisquit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-Mailman-Approved-At: Mon, 23 Jan 2012 01:19:31 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:02:56 -0000 On 01/22/12 15:51, Super Bisquit wrote: > # sysctl legal.intel_iwi.license_ack=1 > sysctl: unknown oid 'legal.intel_iwi.license_ack' You should put it in your loader.conf. [t43:~] andreast% cat /boot/loader.conf legal.intel_iwi.license_ack=1 Given that your were looking on how to make iwi work... Gruss, Andreas From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 01:36:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06A75106564A for ; Mon, 23 Jan 2012 01:36:44 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id A1BC78FC08 for ; Mon, 23 Jan 2012 01:36:43 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0N1ag6p092862 for ; Mon, 23 Jan 2012 05:36:42 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0N1agxI092861 for freebsd-current@freebsd.org; Mon, 23 Jan 2012 05:36:42 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 23 Jan 2012 05:36:42 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20120123013642.GB10149@sirius.xvoid.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 01:36:44 -0000 Seems to be reproducible here running r230467 as the NFS client and r230135 as NFS server. NFSv4 not enabled. # mount [...] sirius:/data/distfiles on /usr/ports/distfiles (nfs) # /usr/bin/env /usr/bin/fetch -AFpr -S 4682084 -o /usr/ports/distfiles/sqlite-src-3071000.zip http://www.sqlite.org/sqlite-src-3071000.zip /usr/ports/distfiles/sqlite-src-3071000.zip 100% of 4572 kB 379 kBps 00m00s # rm /usr/ports/distfiles/sqlite-src-3071000.zip immediately followed by: panic: No NCF_TS cpuid = 2 KDB: enter: panic [ thread pid 1603 tid 100494 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 1603 tid 100494 td 0xfffffe0089585460 kdb_enter() at kdb_enter+0x3e panic() at panic+0x245 cache_lookup_times() at cache_lookup_times+0x6b5 nfs_lookup() at nfs_lookup+0x190 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x8b lookup() at lookup+0x7e9 namei() at namei+0x74c kern_statat_vnhook() at kern_statat_vnhook+0x90 sys_lstat() at sys_lstat+0x30 amd64_syscall() at amd64_syscall+0x221 Xfast_syscall() at Xfast_syscall+0xfb --- syscall (190, FreeBSD ELF64, sys_lstat), rip = 0x80093ff3c, rsp = 0x7fffffffd8d8, rbp = 0x7fffffffd979 --- Yuri From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 02:16:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C44106566B for ; Mon, 23 Jan 2012 02:16:48 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 978418FC0C for ; Mon, 23 Jan 2012 02:16:48 +0000 (UTC) Received: by pbcc13 with SMTP id c13so1956979pbc.13 for ; Sun, 22 Jan 2012 18:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y26F/WKq+GYeyW9fTRFA4LNblgsUaZUdWih0BiOQ8Sw=; b=Xt8YpCsf29C5AO5nuzsw0J1Ko7D+SUSf19zVOtGpVJMOVV5W+lEtR78Pj3iiVyTGmI 6fW9Iz3hL/q4GBjpF/wUpqMRDbvVAHWlBdb8u4N5nFxCQvaEIMajIx6truWh54103GZk JhzTk3k2UYe1I5vk+eY0nQn2T1FkO9Cw/xIbo= MIME-Version: 1.0 Received: by 10.68.189.65 with SMTP id gg1mr18090130pbc.66.1327285008192; Sun, 22 Jan 2012 18:16:48 -0800 (PST) Received: by 10.68.136.106 with HTTP; Sun, 22 Jan 2012 18:16:48 -0800 (PST) In-Reply-To: <4F1C8B5F.8040204@protected-networks.net> References: <4F1C2BED.2080805@protected-networks.net> <4F1C8B5F.8040204@protected-networks.net> Date: Sun, 22 Jan 2012 21:16:48 -0500 Message-ID: From: Super Bisquit To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 02:16:48 -0000 Yes, it is corrected now. I was missing the firmware ko. Thanks. On 1/22/12, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/22/12 12:46, Super Bisquit wrote: >> No dice, people. It isn't doing diddly. > > You did, of course, reboot after adding the license ack to > /boot/loader.conf .. > > imb > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8ci14ACgkQQv9rrgRC1JIFZwCfXw7kNPy8ITMEDO+FcPdMmC28 > zccAoJxLd1dO7kfEQOXqMzKSUtH88uib > =SeH1 > -----END PGP SIGNATURE----- > From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 03:05:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3230D106566B; Mon, 23 Jan 2012 03:05:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE3F8FC12; Mon, 23 Jan 2012 03:05:18 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0N35D3J042705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 05:05:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0N35DPV083194; Mon, 23 Jan 2012 05:05:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0N35D6K083193; Mon, 23 Jan 2012 05:05:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jan 2012 05:05:13 +0200 From: Kostik Belousov To: Yuri Pankov Message-ID: <20120123030513.GK31224@deviant.kiev.zoral.com.ua> References: <20120123013642.GB10149@sirius.xvoid.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l0X5dEQA+6dqjqIE" Content-Disposition: inline In-Reply-To: <20120123013642.GB10149@sirius.xvoid.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:05:19 -0000 --l0X5dEQA+6dqjqIE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2012 at 05:36:42AM +0400, Yuri Pankov wrote: > Seems to be reproducible here running r230467 as the NFS client and > r230135 as NFS server. NFSv4 not enabled. >=20 > # mount > [...] > sirius:/data/distfiles on /usr/ports/distfiles (nfs) >=20 > # /usr/bin/env /usr/bin/fetch -AFpr -S 4682084 -o /usr/ports/distfiles/sq= lite-src-3071000.zip http://www.sqlite.org/sqlite-src-3071000.zip > /usr/ports/distfiles/sqlite-src-3071000.zip 100% of 4572 kB 379 kBps 0= 0m00s > # rm /usr/ports/distfiles/sqlite-src-3071000.zip >=20 > immediately followed by: >=20 > panic: No NCF_TS > cpuid =3D 2 > KDB: enter: panic > [ thread pid 1603 tid 100494 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> bt > Tracing pid 1603 tid 100494 td 0xfffffe0089585460 > kdb_enter() at kdb_enter+0x3e > panic() at panic+0x245 > cache_lookup_times() at cache_lookup_times+0x6b5 > nfs_lookup() at nfs_lookup+0x190 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x8b > lookup() at lookup+0x7e9 > namei() at namei+0x74c > kern_statat_vnhook() at kern_statat_vnhook+0x90 > sys_lstat() at sys_lstat+0x30 > amd64_syscall() at amd64_syscall+0x221 > Xfast_syscall() at Xfast_syscall+0xfb > --- syscall (190, FreeBSD ELF64, sys_lstat), rip =3D 0x80093ff3c, rsp =3D= 0x7fffffffd8d8, rbp =3D 0x7fffffffd979 --- >=20 Yes, my bad. I wrote the r230441 with the assumption that filesystems are consistent in their use of cache_enter_time(). And my net-booting test box did not catched this, which is at least interesting. Please try the change below. Actually, it should be enough to only apply the changes for fs/nfsclient (or nfsclient/ if you use old nfs). If this does not help, then please try the whole patch. Even if not needed for correctness, I think vfs_cache.c change could be made useful by adding KASSERT to it. commit 9771eb4739170d014fcebfbad07bfed4076c6d85 Author: Konstantin Belousov Date: Mon Jan 23 04:36:08 2012 +0200 Make NCF_TS mismatch not fatal. Consistently use cache_enter_time in nfs clients. diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index 2747191..2841647 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@ -1432,7 +1432,7 @@ nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, s= truct componentname *cnp, } if (!error) { if ((cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); + cache_enter_time(dvp, newvp, cnp, &vattr.va_ctime); *vpp =3D newvp; } else if (NFS_ISV4(dvp)) { error =3D nfscl_maperr(cnp->cn_thread, error, vap->va_uid, @@ -1591,7 +1591,7 @@ again: } if (!error) { if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); *ap->a_vpp =3D newvp; } else if (NFS_ISV4(dvp)) { error =3D nfscl_maperr(cnp->cn_thread, error, vap->va_uid, @@ -1923,6 +1923,7 @@ nfs_link(struct vop_link_args *ap) struct componentname *cnp =3D ap->a_cnp; struct nfsnode *np, *tdnp; struct nfsvattr nfsva, dnfsva; + struct timespec ts; int error =3D 0, attrflag, dattrflag; =20 if (vp->v_mount !=3D tdvp->v_mount) { @@ -1966,8 +1967,10 @@ nfs_link(struct vop_link_args *ap) * must care about lookup caching hit rate, so... */ if (VFSTONFS(vp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(tdvp, vp, cnp); + (cnp->cn_flags & MAKEENTRY)) { + vfs_timestamp(&ts); + cache_enter_time(tdvp, vp, cnp, &ts); + } if (error && NFS_ISV4(vp)) error =3D nfscl_maperr(cnp->cn_thread, error, (uid_t)0, (gid_t)0); @@ -1987,6 +1990,7 @@ nfs_symlink(struct vop_symlink_args *ap) struct nfsfh *nfhp; struct nfsnode *np =3D NULL, *dnp; struct vnode *newvp =3D NULL; + struct timespec ts; int error =3D 0, attrflag, dattrflag, ret; =20 vap->va_type =3D VLNK; @@ -2030,8 +2034,10 @@ nfs_symlink(struct vop_symlink_args *ap) * must care about lookup caching hit rate, so... */ if (VFSTONFS(dvp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); + (cnp->cn_flags & MAKEENTRY)) { + vfs_timestamp(&ts); + cache_enter_time(dvp, newvp, cnp, &ts); + } *ap->a_vpp =3D newvp; } =20 @@ -2063,6 +2069,7 @@ nfs_mkdir(struct vop_mkdir_args *ap) struct vattr vattr; struct nfsfh *nfhp; struct nfsvattr nfsva, dnfsva; + struct timespec ts; int error =3D 0, attrflag, dattrflag, ret; =20 if ((error =3D VOP_GETATTR(dvp, &vattr, cnp->cn_cred)) !=3D 0) @@ -2116,8 +2123,10 @@ nfs_mkdir(struct vop_mkdir_args *ap) * must care about lookup caching hit rate, so... */ if (VFSTONFS(dvp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); + (cnp->cn_flags & MAKEENTRY)) { + vfs_timestamp(&ts); + cache_enter_time(dvp, newvp, cnp, &ts); + } *ap->a_vpp =3D newvp; } return (error); diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index c11f25f..647dcac 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -233,6 +233,24 @@ nc_get_name(struct namecache *ncp) return (ncp_ts->nc_name); } =20 +static void +cache_out_ts(struct namecache *ncp, struct timespec *tsp, int *ticksp) +{ + + if ((ncp->nc_flag & NCF_TS) =3D=3D 0) { + if (tsp !=3D NULL) + bzero(tsp, sizeof(*tsp)); + if (ticksp !=3D NULL) + *ticksp =3D 0; + return; + } + + if (tsp !=3D NULL) + *tsp =3D ((struct namecache_ts *)ncp)->nc_time; + if (ticksp !=3D NULL) + *ticksp =3D ((struct namecache_ts *)ncp)->nc_ticks; +} + static int doingcache =3D 1; /* 1 =3D> enable the cache */ SYSCTL_INT(_debug, OID_AUTO, vfscache, CTLFLAG_RW, &doingcache, 0, "VFS namecache enabled"); @@ -506,17 +524,7 @@ retry_wlocked: dvp, cnp->cn_nameptr, *vpp); SDT_PROBE(vfs, namecache, lookup, hit, dvp, "..", *vpp, 0, 0); - if (tsp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, - ("No NCF_TS")); - *tsp =3D ((struct namecache_ts *)ncp)->nc_time; - } - if (ticksp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, - ("No NCF_TS")); - *ticksp =3D ((struct namecache_ts *)ncp)-> - nc_ticks; - } + cache_out_ts(ncp, tsp, ticksp); goto success; } } @@ -563,14 +571,7 @@ retry_wlocked: dvp, cnp->cn_nameptr, *vpp, ncp); SDT_PROBE(vfs, namecache, lookup, hit, dvp, nc_get_name(ncp), *vpp, 0, 0); - if (tsp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, ("No NCF_TS")); - *tsp =3D ((struct namecache_ts *)ncp)->nc_time; - } - if (ticksp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, ("No NCF_TS")); - *ticksp =3D ((struct namecache_ts *)ncp)->nc_ticks; - } + cache_out_ts(ncp, tsp, ticksp); goto success; } =20 @@ -602,14 +603,7 @@ negative_success: cnp->cn_flags |=3D ISWHITEOUT; SDT_PROBE(vfs, namecache, lookup, hit_negative, dvp, nc_get_name(ncp), 0, 0, 0); - if (tsp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, ("No NCF_TS")); - *tsp =3D ((struct namecache_ts *)ncp)->nc_time; - } - if (ticksp !=3D NULL) { - KASSERT((ncp->nc_flag & NCF_TS) !=3D 0, ("No NCF_TS")); - *ticksp =3D ((struct namecache_ts *)ncp)->nc_ticks; - } + cache_out_ts(ncp, tsp, ticksp); CACHE_WUNLOCK(); return (ENOENT); =20 @@ -797,8 +791,8 @@ cache_enter_time(dvp, vp, cnp, tsp) n2->nc_nlen =3D=3D cnp->cn_namelen && !bcmp(nc_get_name(n2), cnp->cn_nameptr, n2->nc_nlen)) { if (tsp !=3D NULL) { - KASSERT((n2->nc_flag & NCF_TS) !=3D 0, - ("no NCF_TS")); + if ((n2->nc_flag & NCF_TS) =3D=3D 0) + continue; n3 =3D (struct namecache_ts *)n2; n3->nc_time =3D ((struct namecache_ts *)ncp)->nc_time; diff --git a/sys/nfsclient/nfs_vnops.c b/sys/nfsclient/nfs_vnops.c index a39b29b..2fc4d2c 100644 --- a/sys/nfsclient/nfs_vnops.c +++ b/sys/nfsclient/nfs_vnops.c @@ -1531,7 +1531,7 @@ nfsmout: vput(newvp); } else { if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); *vpp =3D newvp; } mtx_lock(&(VTONFS(dvp))->n_mtx); @@ -1671,7 +1671,7 @@ nfsmout: } if (!error) { if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); *ap->a_vpp =3D newvp; } mtx_lock(&(VTONFS(dvp))->n_mtx); --l0X5dEQA+6dqjqIE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8czmkACgkQC3+MBN1Mb4i9wACeK3lFYdgb08gaax/b/teC9agE 1+AAnisAAjAaYBhCV1QsY8hrhzBPXfgx =ruNM -----END PGP SIGNATURE----- --l0X5dEQA+6dqjqIE-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 03:38:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92F9106564A for ; Mon, 23 Jan 2012 03:38:15 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8AD8FC12 for ; Mon, 23 Jan 2012 03:38:15 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0N3cDbb095310; Mon, 23 Jan 2012 07:38:13 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0N3cCjD095309; Mon, 23 Jan 2012 07:38:12 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 23 Jan 2012 07:38:12 +0400 From: Yuri Pankov To: Kostik Belousov Message-ID: <20120123033812.GC10149@sirius.xvoid.org> References: <20120123013642.GB10149@sirius.xvoid.org> <20120123030513.GK31224@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120123030513.GK31224@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:38:15 -0000 On Mon, Jan 23, 2012 at 05:05:13AM +0200, Kostik Belousov wrote: > On Mon, Jan 23, 2012 at 05:36:42AM +0400, Yuri Pankov wrote: > > Seems to be reproducible here running r230467 as the NFS client and > > r230135 as NFS server. NFSv4 not enabled. > > > > # mount > > [...] > > sirius:/data/distfiles on /usr/ports/distfiles (nfs) > > > > # /usr/bin/env /usr/bin/fetch -AFpr -S 4682084 -o /usr/ports/distfiles/sqlite-src-3071000.zip http://www.sqlite.org/sqlite-src-3071000.zip > > /usr/ports/distfiles/sqlite-src-3071000.zip 100% of 4572 kB 379 kBps 00m00s > > # rm /usr/ports/distfiles/sqlite-src-3071000.zip > > > > immediately followed by: > > > > panic: No NCF_TS > > cpuid = 2 > > KDB: enter: panic > > [ thread pid 1603 tid 100494 ] > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > db> bt > > Tracing pid 1603 tid 100494 td 0xfffffe0089585460 > > kdb_enter() at kdb_enter+0x3e > > panic() at panic+0x245 > > cache_lookup_times() at cache_lookup_times+0x6b5 > > nfs_lookup() at nfs_lookup+0x190 > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x8b > > lookup() at lookup+0x7e9 > > namei() at namei+0x74c > > kern_statat_vnhook() at kern_statat_vnhook+0x90 > > sys_lstat() at sys_lstat+0x30 > > amd64_syscall() at amd64_syscall+0x221 > > Xfast_syscall() at Xfast_syscall+0xfb > > --- syscall (190, FreeBSD ELF64, sys_lstat), rip = 0x80093ff3c, rsp = 0x7fffffffd8d8, rbp = 0x7fffffffd979 --- > > > > Yes, my bad. I wrote the r230441 with the assumption that filesystems > are consistent in their use of cache_enter_time(). And my net-booting > test box did not catched this, which is at least interesting. > > Please try the change below. Actually, it should be enough to only apply > the changes for fs/nfsclient (or nfsclient/ if you use old nfs). If this > does not help, then please try the whole patch. > > Even if not needed for correctness, I think vfs_cache.c change could > be made useful by adding KASSERT to it. Thanks, applying only the fs/nfsclient part of the patch helped. No problems after applying the full patch as well. Yuri From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 03:00:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB151065678 for ; Mon, 23 Jan 2012 03:00:29 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from ln.servalan.com (unknown [IPv6:2600:3c00::f03c:91ff:fe96:62f5]) by mx1.freebsd.org (Postfix) with ESMTP id 3578B8FC12 for ; Mon, 23 Jan 2012 03:00:13 +0000 (UTC) Received: from uucp by ln.servalan.com with local-rmail (Exim 4.71) (envelope-from ) id 1RpA8d-0003x9-Ry for freebsd-current@freebsd.org; Sun, 22 Jan 2012 21:00:07 -0600 Received: from rmtodd by servalan.servalan.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RpA1O-0005fM-Ec; Sun, 22 Jan 2012 20:52:38 -0600 Date: Sun, 22 Jan 2012 20:52:38 -0600 From: Richard Todd To: freebsd-current@freebsd.org, ken@freebsd.org Message-ID: <20120123025238.GA17816@ichotolot.servalan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 23 Jan 2012 05:48:58 +0000 Cc: Subject: Firewire disk/tape access stopped working after recent CAM commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:00:29 -0000 Hi. I tried upgrading my amd64 10-CURRENT box to the most recent -CURRENT code and found that the new kernel couldn't find my two disks and tape drive that are on a Firewire bus. All the USB and AHCI-attached hardware still showed up okay, it's just the Firewire stuff that failed to show up properly on boot. Spent today doing binary search to find the responsible commit and it looks to be this one: r230000 | ken | 2012-01-11 18:41:48 -0600 (Wed, 11 Jan 2012) | 72 lines Fix a race condition in CAM peripheral free handling, locking in the CAM XPT bus traversal code, and a number of other periph level issues. Not sure what in this commit triggers the problem, or why it just hits Firewire and not the rest of the system. I've built kernels both right before and right after the r230000 commit, with CAM debugging turned on real high on the firewire bus in question, bus 0 (hardwired to that number in device.hints, if that matters) options CAMDEBUG options CAM_DEBUG_BUS=0 options CAM_DEBUG_TARGET=-1 options CAM_DEBUG_LUN=-1 options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_TRACE|CAM_DEBUG_CDB and got dmesgs of both the "bad" (r230000) and "good" (pre-r230000) kernels, which I've put online at http://ln.servalan.com/rmtodd/bug1/dmesg.bad and http://ln.servalan.com/rmtodd/bug1/dmesg.good, respectively. They're a bit lengthy, what with all that debug info. Grepping out the info for one of the targets (disk 0, sbp0:0:0:0) and just looking at the lines for that one, we see that the "good" kernel does a lot more with that target, starting with the "(noperiph:sbp0:0:0:0): xpt_compile_path" bit, that the "bad" kernel doesn't do, as seen in the diff below. Not sure what's going on here, but if anyone has suggestions on more things I can test/debug code I can add to track this down further, let me know. --- /tmp/dbad 2012-01-22 19:08:03.000000000 -0600 +++ /tmp/dgood 2012-01-22 19:08:10.000000000 -0600 @@ -128,3 +128,1097 @@ (xpt0:sbp0:0:0:0): xpt_action_default (xpt0:sbp0:0:0:0): xpt_free_path (xpt0:sbp0:0:0:0): xpt_release_path +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_compile_path +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(noperiph:sbp0:0:0:0): xpt_release_path +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee c1 2f 0 0 1 0 +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(pass0:sbp0:0:0:0): xpt_compile_path +(pass0:sbp0:0:0:0): xpt_setup_ccb +(pass0:sbp0:0:0:0): xpt_action +(pass0:sbp0:0:0:0): xpt_action_default +(pass0:sbp0:0:0:0): xpt_done +(pass0:sbp0:0:0:0): xpt_setup_ccb +(pass0:sbp0:0:0:0): xpt_action +(pass0:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 +(noperiph:sbp0:0:0:0): xpt_compile_path +(noperiph:sbp0:0:0:0): xpt_setup_ccb +(noperiph:sbp0:0:0:0): xpt_action +(noperiph:sbp0:0:0:0): xpt_action_default +(noperiph:sbp0:0:0:0): xpt_release_path +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_done +(pass0:sbp0:0:0:0): xpt_setup_ccb +(pass0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee c1 2f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee c1 2f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 80 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 10 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 0 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 80 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 10 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 0 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 2 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 10 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 80 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee ad 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee ad 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 bf 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 3f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 bf 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 3f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 7f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 41 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 bf 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 f ff ff fe 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 f ff ff fe 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 cf 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 5f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 cf 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 5f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 2 4f 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 8f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 51 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 5f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 cf 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 4f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee ad 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee ad 40 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 81 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 11 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 1 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 2 1 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 81 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 11 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 1 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 2 1 0 0 10 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 41 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 1 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 3 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 11 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 81 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 10 0 0 1 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 f ff ff fd 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ(10). CDB: 28 0 22 ee ad 3f 0 0 1 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): daopen: disk=da0 (unit 0) +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): entering cdgetccb +(da0:sbp0:0:0:0): xpt_schedule +(da0:sbp0:0:0:0): xpt_setup_ccb +(da0:sbp0:0:0:0): xpt_action +(da0:sbp0:0:0:0): xpt_action_default +(da0:sbp0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 +(da0:sbp0:0:0:0): xpt_done +(da0:sbp0:0:0:0): camisr I'm not sure From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 08:12:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE275106566C for ; Mon, 23 Jan 2012 08:12:49 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6846B8FC0A for ; Mon, 23 Jan 2012 08:12:49 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id q0N8ClI2000753 for ; Mon, 23 Jan 2012 17:12:47 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id q0N8Cl513425 for ; Mon, 23 Jan 2012 17:12:47 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi16) id q0N8Clmk020317 for freebsd-current@freebsd.org; Mon, 23 Jan 2012 17:12:47 +0900 Received: from localhost by lomi16.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id q0N8ClxL020273 for ; Mon, 23 Jan 2012 17:12:47 +0900 Date: Mon, 23 Jan 2012 17:12:46 +0900 (JST) Message-Id: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Is UPS_PORT_POWER wrong? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 08:12:49 -0000 Hi HPS, I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap. And, in xhci.c you set UPS_PORT_POWER as folows. When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET() macro will return incorrect value. if (v & XHCI_PS_PP) { /* * The USB 3.0 RH is using the * USB 2.0's power bit */ i |= UPS_PORT_POWER; } Regards, Kohji Okuno From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 08:22:01 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FAD5106566B; Mon, 23 Jan 2012 08:22:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AAD268FC08; Mon, 23 Jan 2012 08:22:00 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA00672; Mon, 23 Jan 2012 10:21:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RpFA6-000PTR-Rg; Mon, 23 Jan 2012 10:21:58 +0200 Message-ID: <4F1D18A5.8010006@FreeBSD.org> Date: Mon, 23 Jan 2012 10:21:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> In-Reply-To: <20120122163539.GF16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 08:22:01 -0000 on 22/01/2012 18:35 Gleb Smirnoff said the following: > On Sat, Jan 21, 2012 at 03:38:59PM +0200, Andriy Gapon wrote: > A> on 20/01/2012 17:41 Gleb Smirnoff said the following: > A> > > A> > On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: > A> > T> New panic has been introduced somewhere between > A> > T> r229851 and r229932, that happens on shutdown if > A> > T> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. > A> > > A> > I've run through binary search and panic was introduced > A> > by r229854. > A> > > A> > A> Which means that it was introduced by one of the earlier commits (probably > A> mine). Thank you for this investigative work! > A> Although, to be frank and honest, I still don't see how the problem could be > A> a non-issue before. > > I can confirm that I can reboot succesfully with a new kernel > and kern.stop_scheduler_on_panic=0. This is very puzzling. You observation means that stop_scheduler_on_panic has an effect on the code outside the panic path. I reviewed the SCHEDULER_STOPPED() changes and I still can not see how that could be possible (modulo compiler bugs). Unfortunately, I also can not reproduce the problem here - without WITNESS_SKIPSPIN I am running into a panic[*] during boot. BTW, do you get any other LOR reports _before_ you do a reboot? Can you try to change printfs in witness to db_printfs? Perhaps this will allow to get the details of the LOR in uart_cnputc. Maybe that will reveal some important additional details. Finally, can you try the patch from my other post? [*] The panic: ... Root mount waiting for: usbus0 panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:500 cpuid = 0 curthread: 0xfffffe000230b900 stack: 0xffffff802cda3000 - 0xffffff802cda7000 stack pointer: 0xffffff802cda5c50 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802bf41a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff8053382a = kdb_backtrace+0x3a panic() at 0xffffffff804f8690 = panic+0x260 _mtx_lock_spin_flags() at 0xffffffff804e5eff = _mtx_lock_spin_flags+0xef cnputs() at 0xffffffff804b0ea6 = cnputs+0x36 putchar() at 0xffffffff8053887f = putchar+0x24f kvprintf() at 0xffffffff80536b1b = kvprintf+0x9b vprintf() at 0xffffffff80538225 = vprintf+0x85 printf() at 0xffffffff805382f7 = printf+0x67 witness_checkorder() at 0xffffffff8054c361 = witness_checkorder+0x821 _mtx_lock_spin_flags() at 0xffffffff804e5f1d = _mtx_lock_spin_flags+0x10d uart_cnputc() at 0xffffffff803c8e6c = uart_cnputc+0x3c cnputc() at 0xffffffff804b0acd = cnputc+0x6d cnputs() at 0xffffffff804b0ebb = cnputs+0x4b putchar() at 0xffffffff8053887f = putchar+0x24f kvprintf() at 0xffffffff80536b1b = kvprintf+0x9b vprintf() at 0xffffffff80538225 = vprintf+0x85 printf() at 0xffffffff805382f7 = printf+0x67 witness_checkorder() at 0xffffffff8054c361 = witness_checkorder+0x821 _mtx_lock_spin_flags() at 0xffffffff804e5f1d = _mtx_lock_spin_flags+0x10d cpu_new_callout() at 0xffffffff806fadbb = cpu_new_callout+0x9b callout_cc_add() at 0xffffffff8050e379 = callout_cc_add+0x129 callout_reset_on() at 0xffffffff8050efcc = callout_reset_on+0x24c sleepq_set_timeout() at 0xffffffff8053ff56 = sleepq_set_timeout+0x106 _sleep() at 0xffffffff805036f2 = _sleep+0x342 pause() at 0xffffffff80503920 = pause+0x90 usb_pause_mtx() at 0xffffffff803ee841 = usb_pause_mtx+0x71 usbd_req_set_address() at 0xffffffff803e9f1c = usbd_req_set_address+0xac usb_alloc_device() at 0xffffffff803def89 = usb_alloc_device+0x3d9 uhub_explore() at 0xffffffff803e5b63 = uhub_explore+0x3a3 usb_bus_explore() at 0xffffffff803d4187 = usb_bus_explore+0xd7 usb_process() at 0xffffffff803e8bc1 = usb_process+0xa1 fork_exit() at 0xffffffff804c801a = fork_exit+0x1aa fork_trampoline() at 0xffffffff806bf3ee = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff802cda6d00, rbp = 0 --- KDB: enter: panic [ thread pid 15 tid 100031 ] Stopped at 0xffffffff8053348d = kdb_enter+0x3d: movq $0,0x11212d0(%rip) db> show locks exclusive sx USB config SX lock (USB config SX lock) r = 0 (0xfffffe0005040070) locked @ /usr/src/sys/dev/usb/usb_device.c:2643 exclusive spin mutex callout (callout) r = 0 (0xffffffff8160b3f8) locked @ /usr/src/sys/kern/kern_timeout.c:409 exclusive spin mutex sleepq chain (sleepq chain) r = 0 (0xffffffff81655668) locked @ /usr/src/sys/kern/subr_sleepqueue.c:237 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 08:33:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE159106564A for ; Mon, 23 Jan 2012 08:33:01 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3C60C8FC19 for ; Mon, 23 Jan 2012 08:33:01 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 628246A6245; Mon, 23 Jan 2012 09:33:00 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id jC2u_YqPnnBG; Mon, 23 Jan 2012 09:33:00 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 215D06A6228; Mon, 23 Jan 2012 09:33:00 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id q0N8Wxq1094159; Mon, 23 Jan 2012 09:32:59 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id q0N8Wxva092832; Mon, 23 Jan 2012 09:32:59 +0100 (CET) (envelope-from lars) Date: Mon, 23 Jan 2012 09:32:59 +0100 From: Lars Engels To: Michael Butler Message-ID: <20120123083259.GG3788@e-new.0x20.net> References: <4F1C2BED.2080805@protected-networks.net> <4F1C8B5F.8040204@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p7qwJlK53pWzbayA" Content-Disposition: inline In-Reply-To: <4F1C8B5F.8040204@protected-networks.net> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Super Bisquit , freebsd-current@freebsd.org Subject: Re: Problems with enabling iwi due to sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 08:33:01 -0000 --p7qwJlK53pWzbayA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 05:19:11PM -0500, Michael Butler wrote: > On 01/22/12 12:46, Super Bisquit wrote: > > No dice, people. It isn't doing diddly. >=20 > You did, of course, reboot after adding the license ack to > /boot/loader.conf .. No need to reboot: # kenv legal.intel_iwi.license_ack=3D"1" Sets the variable on the fly. --p7qwJlK53pWzbayA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8dGzsACgkQKc512sD3afinwgCdHxgnwpX243A+lWVs5wItNxni 6AoAnAmfMN2BIQO07nd7/oYN+OePZsNu =Ot2G -----END PGP SIGNATURE----- --p7qwJlK53pWzbayA-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 09:22:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476221065679 for ; Mon, 23 Jan 2012 09:22:04 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from mail.beastielabs.net (beasties.demon.nl [82.161.3.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2128FC12 for ; Mon, 23 Jan 2012 09:22:03 +0000 (UTC) Received: from merom.hotsoft.nl (merom.hotsoft.nl [192.168.0.12]) by mail.beastielabs.net (8.14.5/8.14.5) with ESMTP id q0N90CEw088848; Mon, 23 Jan 2012 10:00:12 +0100 (CET) (envelope-from hans@beastielabs.net) Message-ID: <4F1D219C.9000909@beastielabs.net> Date: Mon, 23 Jan 2012 10:00:12 +0100 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111224 Thunderbird/9.0 MIME-Version: 1.0 To: Rick Macklem References: <1642456771.665100.1327113309598.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1642456771.665100.1327113309598.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , "O. Hartmann" Subject: Re: amd: is there an alternative with NFSv4 capabilities? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 09:22:04 -0000 On 01/21/12 03:35, Rick Macklem wrote: > O. Hartmann wrote: >> Hello. >> I still use the amd automounter, but I miss NFSv4 capabilities. Since >> Linux seems to use a more deep in the kernel located facility, I'd >> like >> to ask whether FreeBSd has an alternative to the amd automounter with >> NFSv4 capabilities. Sorry if I bother someone, I'm not aware of an >> alternative and it maybe the case that I'm stuck with the amd ... >> >> Cheers, >> Oliver > > I'm not aware of anything, but maybe someone else knows of an alternative? > > On my "maybe it would be nice" list (not my "to do" list, because I'll never > get around to it) was to look at the Solaris' AutoFS. I believe Apple > switched to it and has found it worked well in Mac OSX. I suspect that there > are OpenSolaris sources for it out there under the CDDL, but I haven't even > checked that. > > So, if anyone is looking for an interesting project, this might be a nice one. > (I could probably provide some help with it, if someone took it on.) > AutoFS for FreeBSD was the topic of a GSoC 2006 project and results seem to be presented at BSDCan 2007, see: http://www.bsdcan.org/2007/schedule/events/32.en.html (The presentation has a .ppt extension, but is actually a pdf). Despite plans, to my knowledge nothing ever happened with the results. As far as I remember, the code is viewable in Perforce, but not (easily) down loadable by mere mortals, and probably quite stale by now. I concur that having a real AutoFS, integrated with NFSv4 and fully inter operable with Linux and Solaris (and Mac OS-X ?) would be really nice to have, especially for scientific and engineering environments. Kind regards, Hans Ottevanger From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 13:04:55 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1141D106566B; Mon, 23 Jan 2012 13:04:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 85CDB8FC0A; Mon, 23 Jan 2012 13:04:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0ND4rUc037501; Mon, 23 Jan 2012 17:04:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0ND4rSi037500; Mon, 23 Jan 2012 17:04:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 17:04:53 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123130453.GH16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <4F1ACD97.5080506@FreeBSD.org> <4F1AF55F.4090803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1AF55F.4090803@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:04:55 -0000 On Sat, Jan 21, 2012 at 07:26:55PM +0200, Andriy Gapon wrote: A> > BTW, we have a quite strange situation with spin locks in console output path. A> > cnputs_mtx is marked as MTX_NOWITNESS, supposedly because cnputs (printf) can be A> > called in any locking context (even during normal operation). But there are a A> > number of console-specific locks (scrlock, uart_hwmtx, "syscons video lock") A> > which are acquired under cnputs_mtx, but which are *not* marked as A> > MTX_NOWITNESS. More, they are specified in the witness order_lists as if we A> > certainly know a correct order for them. A> > I think that the msgbuf mutex also deserves mentioning in this context. A> > A> > I think that all of these spin locks should be marked as MTX_NOWITNESS (as long A> > as they stay normal spinlocks), because printf(9) should be usable wherever I A> > stick it in the code. A> > A> > P.S. The above only matters for WITNESS and !WITNESS_SKIPSPIN and I am not sure A> > if this combination really matters. A> > A> A> Here's my take at it: A> diff --git a/sys/kern/kern_cons.c b/sys/kern/kern_cons.c A> index 5346bc3..97f0f16 100644 ... This patch works. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 13:07:45 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0F01065675; Mon, 23 Jan 2012 13:07:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE328FC12; Mon, 23 Jan 2012 13:07:44 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0ND7h63037552; Mon, 23 Jan 2012 17:07:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0ND7hZd037551; Mon, 23 Jan 2012 17:07:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 17:07:43 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123130743.GI16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1D18A5.8010006@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:07:45 -0000 On Mon, Jan 23, 2012 at 10:21:57AM +0200, Andriy Gapon wrote: A> > I can confirm that I can reboot succesfully with a new kernel A> > and kern.stop_scheduler_on_panic=0. A> A> This is very puzzling. You observation means that stop_scheduler_on_panic has A> an effect on the code outside the panic path. I reviewed the A> SCHEDULER_STOPPED() changes and I still can not see how that could be possible A> (modulo compiler bugs). A> A> Unfortunately, I also can not reproduce the problem here - without A> WITNESS_SKIPSPIN I am running into a panic[*] during boot. I suppose your patch (the one in other post) should help against this panic on boot. A> BTW, do you get any other LOR reports _before_ you do a reboot? I have some, but I don't think they are related. A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some A> important additional details. Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only in special places? A> Finally, can you try the patch from my other post? Yes, it works. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 13:59:40 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E738A1065672; Mon, 23 Jan 2012 13:59:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 11C098FC1E; Mon, 23 Jan 2012 13:59:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04965; Mon, 23 Jan 2012 15:59:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D67CA.8010809@FreeBSD.org> Date: Mon, 23 Jan 2012 15:59:38 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <4F1ACD97.5080506@FreeBSD.org> <4F1AF55F.4090803@FreeBSD.org> <20120123130453.GH16676@glebius.int.ru> In-Reply-To: <20120123130453.GH16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:59:41 -0000 on 23/01/2012 15:04 Gleb Smirnoff said the following: > On Sat, Jan 21, 2012 at 07:26:55PM +0200, Andriy Gapon wrote: > A> > BTW, we have a quite strange situation with spin locks in console output path. > A> > cnputs_mtx is marked as MTX_NOWITNESS, supposedly because cnputs (printf) can be > A> > called in any locking context (even during normal operation). But there are a > A> > number of console-specific locks (scrlock, uart_hwmtx, "syscons video lock") > A> > which are acquired under cnputs_mtx, but which are *not* marked as > A> > MTX_NOWITNESS. More, they are specified in the witness order_lists as if we > A> > certainly know a correct order for them. > A> > I think that the msgbuf mutex also deserves mentioning in this context. > A> > > A> > I think that all of these spin locks should be marked as MTX_NOWITNESS (as long > A> > as they stay normal spinlocks), because printf(9) should be usable wherever I > A> > stick it in the code. > A> > > A> > P.S. The above only matters for WITNESS and !WITNESS_SKIPSPIN and I am not sure > A> > if this combination really matters. > A> > > A> > A> Here's my take at it: > A> diff --git a/sys/kern/kern_cons.c b/sys/kern/kern_cons.c > A> index 5346bc3..97f0f16 100644 > > ... > > This patch works. > Thank you for testing! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 14:01:23 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 567E61065676; Mon, 23 Jan 2012 14:01:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7143D8FC1C; Mon, 23 Jan 2012 14:01:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05013; Mon, 23 Jan 2012 16:01:20 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D6830.60602@FreeBSD.org> Date: Mon, 23 Jan 2012 16:01:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> In-Reply-To: <20120123130743.GI16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:01:23 -0000 on 23/01/2012 15:07 Gleb Smirnoff said the following: > On Mon, Jan 23, 2012 at 10:21:57AM +0200, Andriy Gapon wrote: > A> > I can confirm that I can reboot succesfully with a new kernel > A> > and kern.stop_scheduler_on_panic=0. > A> > A> This is very puzzling. You observation means that stop_scheduler_on_panic has > A> an effect on the code outside the panic path. I reviewed the > A> SCHEDULER_STOPPED() changes and I still can not see how that could be possible > A> (modulo compiler bugs). > A> > A> Unfortunately, I also can not reproduce the problem here - without > A> WITNESS_SKIPSPIN I am running into a panic[*] during boot. > > I suppose your patch (the one in other post) should help against > this panic on boot. Yes, it does. It also masks/fixes the panic at reboot. > A> BTW, do you get any other LOR reports _before_ you do a reboot? > > I have some, but I don't think they are related. OK. > A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow > A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some > A> important additional details. > > Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only > in special places? I think that "replace all" should work for this test. > A> Finally, can you try the patch from my other post? > > Yes, it works. > Thank you again. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 14:54:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADC51065673; Mon, 23 Jan 2012 14:54:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F0E1C8FC19; Mon, 23 Jan 2012 14:54:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8CE8046B0D; Mon, 23 Jan 2012 09:54:51 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (50-76-52-236-ip-static.hfc.comcastbusiness.net [50.76.52.236]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8AA84B955; Mon, 23 Jan 2012 09:54:50 -0500 (EST) Message-ID: <4F1D74B9.8010800@FreeBSD.org> Date: Mon, 23 Jan 2012 06:54:49 -0800 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20120123013642.GB10149@sirius.xvoid.org> <20120123030513.GK31224@deviant.kiev.zoral.com.ua> In-Reply-To: <20120123030513.GK31224@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 23 Jan 2012 09:54:51 -0500 (EST) Cc: Yuri Pankov , Rick Macklem , freebsd-current@freebsd.org Subject: Re: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:54:52 -0000 On 1/22/12 7:05 PM, Kostik Belousov wrote: > On Mon, Jan 23, 2012 at 05:36:42AM +0400, Yuri Pankov wrote: >> Seems to be reproducible here running r230467 as the NFS client and >> r230135 as NFS server. NFSv4 not enabled. >> >> # mount >> [...] >> sirius:/data/distfiles on /usr/ports/distfiles (nfs) >> >> # /usr/bin/env /usr/bin/fetch -AFpr -S 4682084 -o /usr/ports/distfiles/sqlite-src-3071000.zip http://www.sqlite.org/sqlite-src-3071000.zip >> /usr/ports/distfiles/sqlite-src-3071000.zip 100% of 4572 kB 379 kBps 00m00s >> # rm /usr/ports/distfiles/sqlite-src-3071000.zip >> >> immediately followed by: >> >> panic: No NCF_TS >> cpuid = 2 >> KDB: enter: panic >> [ thread pid 1603 tid 100494 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> db> bt >> Tracing pid 1603 tid 100494 td 0xfffffe0089585460 >> kdb_enter() at kdb_enter+0x3e >> panic() at panic+0x245 >> cache_lookup_times() at cache_lookup_times+0x6b5 >> nfs_lookup() at nfs_lookup+0x190 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x8b >> lookup() at lookup+0x7e9 >> namei() at namei+0x74c >> kern_statat_vnhook() at kern_statat_vnhook+0x90 >> sys_lstat() at sys_lstat+0x30 >> amd64_syscall() at amd64_syscall+0x221 >> Xfast_syscall() at Xfast_syscall+0xfb >> --- syscall (190, FreeBSD ELF64, sys_lstat), rip = 0x80093ff3c, rsp = 0x7fffffffd8d8, rbp = 0x7fffffffd979 --- >> > > Yes, my bad. I wrote the r230441 with the assumption that filesystems > are consistent in their use of cache_enter_time(). And my net-booting > test box did not catched this, which is at least interesting. > > Please try the change below. Actually, it should be enough to only apply > the changes for fs/nfsclient (or nfsclient/ if you use old nfs). If this > does not help, then please try the whole patch. I think we should have the existing assertion. If cache_lookup_times() is called with a timestamp requested, then returning a name cache entry without a timestamp is just going to result in that name cache entry not being used. Panic'ing in that case is correct. With regard to the NFS changes below, all of these are bugs that didn't really work right before. Specifically, adding a positive entry without setting n_ctime previously would have just resulted in the name cache entry being purged on the next lookup anyway. Keep in mind that the timestamp for a give name cache entry in NFS needs to match an actual timestamp returned by the NFS server as post-op attributes in some RPC. Using the timestamp from vfs_timestamp() is completely bogus. Instead, the timestamp for a negative entry needs to be the mtime of the parent directory. If we don't have that timestamp handy, then we should just not add a namecache entry at all. Also, the vap->va_ctime used below for mknod() and create() is not a timestamp from the server, so it is also suspect. I can look at this in more detail on Wednesday, but my best guess is that nearly all (if not all) of these cache_enter() calls will simply need to be removed. Note that other filesystems like UFS don't bother creating name cache entries for things like create or mknod. It's debatable if the NFS client should even be creating any name cache entries outside of lookup and when handling a READDIR+ reply. > Even if not needed for correctness, I think vfs_cache.c change could > be made useful by adding KASSERT to it. > > commit 9771eb4739170d014fcebfbad07bfed4076c6d85 > Author: Konstantin Belousov > Date: Mon Jan 23 04:36:08 2012 +0200 > > Make NCF_TS mismatch not fatal. > Consistently use cache_enter_time in nfs clients. > > diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c > index 2747191..2841647 100644 > --- a/sys/fs/nfsclient/nfs_clvnops.c > +++ b/sys/fs/nfsclient/nfs_clvnops.c > @@ -1432,7 +1432,7 @@ nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, struct componentname *cnp, > } > if (!error) { > if ((cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > + cache_enter_time(dvp, newvp, cnp, &vattr.va_ctime); > *vpp = newvp; > } else if (NFS_ISV4(dvp)) { > error = nfscl_maperr(cnp->cn_thread, error, vap->va_uid, > @@ -1591,7 +1591,7 @@ again: > } > if (!error) { > if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); > *ap->a_vpp = newvp; > } else if (NFS_ISV4(dvp)) { > error = nfscl_maperr(cnp->cn_thread, error, vap->va_uid, > @@ -1923,6 +1923,7 @@ nfs_link(struct vop_link_args *ap) > struct componentname *cnp = ap->a_cnp; > struct nfsnode *np, *tdnp; > struct nfsvattr nfsva, dnfsva; > + struct timespec ts; > int error = 0, attrflag, dattrflag; > > if (vp->v_mount != tdvp->v_mount) { > @@ -1966,8 +1967,10 @@ nfs_link(struct vop_link_args *ap) > * must care about lookup caching hit rate, so... > */ > if (VFSTONFS(vp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(tdvp, vp, cnp); > + (cnp->cn_flags & MAKEENTRY)) { > + vfs_timestamp(&ts); > + cache_enter_time(tdvp, vp, cnp, &ts); > + } > if (error && NFS_ISV4(vp)) > error = nfscl_maperr(cnp->cn_thread, error, (uid_t)0, > (gid_t)0); > @@ -1987,6 +1990,7 @@ nfs_symlink(struct vop_symlink_args *ap) > struct nfsfh *nfhp; > struct nfsnode *np = NULL, *dnp; > struct vnode *newvp = NULL; > + struct timespec ts; > int error = 0, attrflag, dattrflag, ret; > > vap->va_type = VLNK; > @@ -2030,8 +2034,10 @@ nfs_symlink(struct vop_symlink_args *ap) > * must care about lookup caching hit rate, so... > */ > if (VFSTONFS(dvp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > + (cnp->cn_flags & MAKEENTRY)) { > + vfs_timestamp(&ts); > + cache_enter_time(dvp, newvp, cnp, &ts); > + } > *ap->a_vpp = newvp; > } > > @@ -2063,6 +2069,7 @@ nfs_mkdir(struct vop_mkdir_args *ap) > struct vattr vattr; > struct nfsfh *nfhp; > struct nfsvattr nfsva, dnfsva; > + struct timespec ts; > int error = 0, attrflag, dattrflag, ret; > > if ((error = VOP_GETATTR(dvp, &vattr, cnp->cn_cred)) != 0) > @@ -2116,8 +2123,10 @@ nfs_mkdir(struct vop_mkdir_args *ap) > * must care about lookup caching hit rate, so... > */ > if (VFSTONFS(dvp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > + (cnp->cn_flags & MAKEENTRY)) { > + vfs_timestamp(&ts); > + cache_enter_time(dvp, newvp, cnp, &ts); > + } > *ap->a_vpp = newvp; > } > return (error); > diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c > index c11f25f..647dcac 100644 > --- a/sys/kern/vfs_cache.c > +++ b/sys/kern/vfs_cache.c > @@ -233,6 +233,24 @@ nc_get_name(struct namecache *ncp) > return (ncp_ts->nc_name); > } > > +static void > +cache_out_ts(struct namecache *ncp, struct timespec *tsp, int *ticksp) > +{ > + > + if ((ncp->nc_flag & NCF_TS) == 0) { > + if (tsp != NULL) > + bzero(tsp, sizeof(*tsp)); > + if (ticksp != NULL) > + *ticksp = 0; > + return; > + } > + > + if (tsp != NULL) > + *tsp = ((struct namecache_ts *)ncp)->nc_time; > + if (ticksp != NULL) > + *ticksp = ((struct namecache_ts *)ncp)->nc_ticks; > +} > + > static int doingcache = 1; /* 1 => enable the cache */ > SYSCTL_INT(_debug, OID_AUTO, vfscache, CTLFLAG_RW, &doingcache, 0, > "VFS namecache enabled"); > @@ -506,17 +524,7 @@ retry_wlocked: > dvp, cnp->cn_nameptr, *vpp); > SDT_PROBE(vfs, namecache, lookup, hit, dvp, "..", > *vpp, 0, 0); > - if (tsp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, > - ("No NCF_TS")); > - *tsp = ((struct namecache_ts *)ncp)->nc_time; > - } > - if (ticksp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, > - ("No NCF_TS")); > - *ticksp = ((struct namecache_ts *)ncp)-> > - nc_ticks; > - } > + cache_out_ts(ncp, tsp, ticksp); > goto success; > } > } > @@ -563,14 +571,7 @@ retry_wlocked: > dvp, cnp->cn_nameptr, *vpp, ncp); > SDT_PROBE(vfs, namecache, lookup, hit, dvp, nc_get_name(ncp), > *vpp, 0, 0); > - if (tsp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, ("No NCF_TS")); > - *tsp = ((struct namecache_ts *)ncp)->nc_time; > - } > - if (ticksp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, ("No NCF_TS")); > - *ticksp = ((struct namecache_ts *)ncp)->nc_ticks; > - } > + cache_out_ts(ncp, tsp, ticksp); > goto success; > } > > @@ -602,14 +603,7 @@ negative_success: > cnp->cn_flags |= ISWHITEOUT; > SDT_PROBE(vfs, namecache, lookup, hit_negative, dvp, nc_get_name(ncp), > 0, 0, 0); > - if (tsp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, ("No NCF_TS")); > - *tsp = ((struct namecache_ts *)ncp)->nc_time; > - } > - if (ticksp != NULL) { > - KASSERT((ncp->nc_flag & NCF_TS) != 0, ("No NCF_TS")); > - *ticksp = ((struct namecache_ts *)ncp)->nc_ticks; > - } > + cache_out_ts(ncp, tsp, ticksp); > CACHE_WUNLOCK(); > return (ENOENT); > > @@ -797,8 +791,8 @@ cache_enter_time(dvp, vp, cnp, tsp) > n2->nc_nlen == cnp->cn_namelen && > !bcmp(nc_get_name(n2), cnp->cn_nameptr, n2->nc_nlen)) { > if (tsp != NULL) { > - KASSERT((n2->nc_flag & NCF_TS) != 0, > - ("no NCF_TS")); > + if ((n2->nc_flag & NCF_TS) == 0) > + continue; > n3 = (struct namecache_ts *)n2; > n3->nc_time = > ((struct namecache_ts *)ncp)->nc_time; > diff --git a/sys/nfsclient/nfs_vnops.c b/sys/nfsclient/nfs_vnops.c > index a39b29b..2fc4d2c 100644 > --- a/sys/nfsclient/nfs_vnops.c > +++ b/sys/nfsclient/nfs_vnops.c > @@ -1531,7 +1531,7 @@ nfsmout: > vput(newvp); > } else { > if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); > *vpp = newvp; > } > mtx_lock(&(VTONFS(dvp))->n_mtx); > @@ -1671,7 +1671,7 @@ nfsmout: > } > if (!error) { > if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); > *ap->a_vpp = newvp; > } > mtx_lock(&(VTONFS(dvp))->n_mtx); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 16:24:12 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CB1F106564A; Mon, 23 Jan 2012 16:24:12 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id D67138FC08; Mon, 23 Jan 2012 16:24:11 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0NGOAqi038902; Mon, 23 Jan 2012 20:24:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0NGOAbI038901; Mon, 23 Jan 2012 20:24:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 20:24:10 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123162410.GN16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1D6830.60602@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:24:12 -0000 On Mon, Jan 23, 2012 at 04:01:20PM +0200, Andriy Gapon wrote: A> > A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow A> > A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some A> > A> important additional details. A> > A> > Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only A> > in special places? A> A> I think that "replace all" should work for this test. Yes, s/ printf/ db_printf/ in subr_witness.c fixes my problem. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 16:26:07 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDEDF1065675; Mon, 23 Jan 2012 16:26:07 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA8B8FC17; Mon, 23 Jan 2012 16:26:07 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0NGQ62N038929; Mon, 23 Jan 2012 20:26:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0NGQ6Qi038928; Mon, 23 Jan 2012 20:26:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 20:26:06 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123162606.GO16676@FreeBSD.org> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20120123162410.GN16676@glebius.int.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:26:08 -0000 On Mon, Jan 23, 2012 at 08:24:10PM +0400, Gleb Smirnoff wrote: T> On Mon, Jan 23, 2012 at 04:01:20PM +0200, Andriy Gapon wrote: T> A> > A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow T> A> > A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some T> A> > A> important additional details. T> A> > T> A> > Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only T> A> > in special places? T> A> T> A> I think that "replace all" should work for this test. T> T> Yes, s/ printf/ db_printf/ in subr_witness.c fixes my problem. Sorry. I was testing wrong kernel. The substitute doesn't help. Panic trace is almost the same: db> bt Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c7 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f cnputs() at cnputs+0x7a vprintf() at vprintf+0xcb printf() at printf+0x67 db_putc() at db_putc+0x81 kvprintf() at kvprintf+0x83 db_printf() at db_printf+0x86 witness_checkorder() at witness_checkorder+0x773 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 uart_cnputc() at uart_cnputc+0x3e cnputc() at cnputc+0x4c cnputs() at cnputs+0x26 putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 cpu_reset() at cpu_reset+0x81 kern_reboot() at kern_reboot+0x3a5 sys_reboot() at sys_reboot+0x42 amd64_syscall() at amd64_syscall+0x39e Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 --- db> -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 16:43:26 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C2E1065744; Mon, 23 Jan 2012 16:43:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8773D8FC0C; Mon, 23 Jan 2012 16:43:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07045; Mon, 23 Jan 2012 18:43:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D8E2B.30800@FreeBSD.org> Date: Mon, 23 Jan 2012 18:43:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> In-Reply-To: <20120123162606.GO16676@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:43:26 -0000 on 23/01/2012 18:26 Gleb Smirnoff said the following: > Sorry. I was testing wrong kernel. The substitute doesn't help. Panic > trace is almost the same: > > db> bt > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 > kdb_enter() at kdb_enter+0x3b > panic() at panic+0x1c7 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f > cnputs() at cnputs+0x7a > vprintf() at vprintf+0xcb > printf() at printf+0x67 > db_putc() at db_putc+0x81 Ah, db_putc does something different from what I expected. Can you hack it to never use printf? > kvprintf() at kvprintf+0x83 > db_printf() at db_printf+0x86 > witness_checkorder() at witness_checkorder+0x773 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 > uart_cnputc() at uart_cnputc+0x3e > cnputc() at cnputc+0x4c > cnputs() at cnputs+0x26 > putchar() at putchar+0x11f > kvprintf() at kvprintf+0x83 > vprintf() at vprintf+0x85 > printf() at printf+0x67 > cpu_reset() at cpu_reset+0x81 > kern_reboot() at kern_reboot+0x3a5 > sys_reboot() at sys_reboot+0x42 > amd64_syscall() at amd64_syscall+0x39e > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 --- > db> > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 16:47:01 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B771065673; Mon, 23 Jan 2012 16:47:01 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 25C628FC18; Mon, 23 Jan 2012 16:47:00 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0NGkxZj039123; Mon, 23 Jan 2012 20:46:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0NGkxiw039122; Mon, 23 Jan 2012 20:46:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 20:46:59 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123164659.GQ16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1D8E2B.30800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:47:01 -0000 On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A> > db> bt A> > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 A> > kdb_enter() at kdb_enter+0x3b A> > panic() at panic+0x1c7 A> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f A> > cnputs() at cnputs+0x7a A> > vprintf() at vprintf+0xcb A> > printf() at printf+0x67 A> > db_putc() at db_putc+0x81 A> A> Ah, db_putc does something different from what I expected. A> Can you hack it to never use printf? Just cut printfs from db_putc()? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 16:56:11 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A18106566B; Mon, 23 Jan 2012 16:56:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5148FC0A; Mon, 23 Jan 2012 16:56:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07195; Mon, 23 Jan 2012 18:56:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D9128.3030501@FreeBSD.org> Date: Mon, 23 Jan 2012 18:56:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> In-Reply-To: <20120123164659.GQ16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:56:11 -0000 on 23/01/2012 18:46 Gleb Smirnoff said the following: > On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: > A> > db> bt > A> > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 > A> > kdb_enter() at kdb_enter+0x3b > A> > panic() at panic+0x1c7 > A> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f > A> > cnputs() at cnputs+0x7a > A> > vprintf() at vprintf+0xcb > A> > printf() at printf+0x67 > A> > db_putc() at db_putc+0x81 > A> > A> Ah, db_putc does something different from what I expected. > A> Can you hack it to never use printf? > > Just cut printfs from db_putc()? Make the following condition be always false: if (!kdb_active || ddb_use_printf) { E.g.: if (0) { :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 17:31:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0023F106566B for ; Mon, 23 Jan 2012 17:31:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 89F8A8FC0A for ; Mon, 23 Jan 2012 17:31:27 +0000 (UTC) X-T2-Spam-Status: No, hits=0.5 required=5.0 tests=ALL_TRUSTED, BAYES_60 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 230006553; Mon, 23 Jan 2012 18:31:23 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 23 Jan 2012 18:29:19 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> In-Reply-To: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201231829.19576.hselasky@c2i.net> Cc: Kohji Okuno Subject: Re: Is UPS_PORT_POWER wrong? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:31:28 -0000 On Monday 23 January 2012 09:12:46 Kohji Okuno wrote: > Hi HPS, > > I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap. > And, in xhci.c you set UPS_PORT_POWER as folows. > > When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET() macro will > return incorrect value. > > if (v & XHCI_PS_PP) { > /* > * The USB 3.0 RH is using the > * USB 2.0's power bit > */ > i |= UPS_PORT_POWER; > } > Hi, The USB 3.0 root HUB is special because it defines FULL/HIGH and LOW speed, so I had to merge that into the port status register of the XHCI root HUB like this: 0: CONNECT_STATUS 1: PORT_ENABLED 2: SUSPEND 3: OVERCURRENT_INDICATOR 4: LINK STATE (USB 3.0) 5: - 6: - 7: - 8: PORT_POWER (USB 2.0) # Bit 9+10 have 4 combinations which are defined: FS, LW, HS, SS 9: LOW_SPEED (USB 2.0) 10: HIGH_SPEED (USB 2.0) 11: not implemented 12: PORT_INDICATOR 13: 14: 15: MODE_DEVICE (FreeBSD specific) If you have a better idea, it is possible to change this. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 18:05:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7BF1065675; Mon, 23 Jan 2012 18:05:49 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id DDEC88FC0C; Mon, 23 Jan 2012 18:05:48 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0NI5lqc014930; Mon, 23 Jan 2012 22:05:47 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0NI5lTX014929; Mon, 23 Jan 2012 22:05:47 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 23 Jan 2012 22:05:47 +0400 From: Yuri Pankov To: Alexander Motin Message-ID: <20120123180547.GB13410@sirius.xvoid.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <20120112130404.GD1429@procyon.xvoid.org> <4F16ED05.4060604@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F16ED05.4060604@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:05:49 -0000 On Wed, Jan 18, 2012 at 06:02:13PM +0200, Alexander Motin wrote: > On 01/12/12 15:04, Yuri Pankov wrote: > > On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote: > >> On 01/12/12 14:18, Yuri Pankov wrote: > >>> On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote: > >>>> I would like request for testing of my work on further HDA sound driver > >>>> improvement. > >>> [...] > >>>> Patch can be found here: > >>>> http://people.freebsd.org/~mav/hda.rewrite.patch > >>>> > >>>> Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE > >>>> and 8-STABLE branches also. > >>> > >>> Patch applied cleanly to r230008 using `svn patch`. > >>> > >>> hdacc0: at cad 0 on hdac0 > >>> hdaa0: at nid 1 on hdacc0 > >>> pcm0: at nid 5 on hdaa0 > >>> hdacc1: at cad 1 on hdac0 > >>> hdaa1: at nid 1 on hdacc1 > >>> pcm1: at nid 5 on hdaa1 > >>> hdacc2: at cad 2 on hdac0 > >>> hdaa2: at nid 1 on hdacc2 > >>> pcm2: at nid 5 on hdaa2 > >>> hdacc3: at cad 3 on hdac0 > >>> hdaa3: at nid 1 on hdacc3 > >>> pcm3: at nid 5 on hdaa3 > >>> hdacc4: at cad 0 on hdac1 > >>> hdaa4: at nid 1 on hdacc4 > >>> pcm4: at nid 13 and 11 on hdaa4 > >>> pcm5: at nid 15 and 24 on hdaa4 > >>> pcm6: at nid 30 on hdaa4 > >>> > >>> pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however > >> > >> Thank you. > >> > >>> I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI), > >>> mplayer just pauses at the beggining, trying to cat anything to > >>> /dev/dsp{0-3}.0 gives: > >>> > >>> pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead > >>> > >>> It was the same with the old driver and I'm not sure if it's (most > >>> likely) my misconfiguration or a driver problem. > >> > >> It sounds more like a driver problem. HDMI audio is still not very well > >> discovered area, and, according to ALSA reading, NVidia HDMI is also not > >> very standard. Probably I'll finally have to buy something to > >> experiment. What card do you have? > > > > It's a laptop with "nVidia Corporation GT216 [GeForce GT 230M]" (as > > identified by x11/nvidia-driver). > > I've reproduced it on NVidia GT210. It seems there is some problem with > MSI generation. Switching to legacy PCI interrupts fixes problem for me. > Linux HDA driver disables MSI for all NVidia controllers. > > Try to add hint.hdac.0.msi=0 into the /boot/loader.conf. Sorry for delay. Indeed, setting hint.hdac.0.msi=0 helped. Thanks, Yuri From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 18:16:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E7F106564A for ; Mon, 23 Jan 2012 18:16:06 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 96F998FC0A for ; Mon, 23 Jan 2012 18:16:06 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q0NIG598052287; Mon, 23 Jan 2012 11:16:05 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q0NIG56P052286; Mon, 23 Jan 2012 11:16:05 -0700 (MST) (envelope-from ken) Date: Mon, 23 Jan 2012 11:16:05 -0700 From: "Kenneth D. Merry" To: Richard Todd Message-ID: <20120123181605.GA52248@nargothrond.kdm.org> References: <20120123025238.GA17816@ichotolot.servalan.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20120123025238.GA17816@ichotolot.servalan.com> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: Firewire disk/tape access stopped working after recent CAM commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:16:07 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 22, 2012 at 20:52:38 -0600, Richard Todd wrote: > Hi. I tried upgrading my amd64 10-CURRENT box to the most recent -CURRENT code > and found that the new kernel couldn't find my two disks and tape drive that > are on a Firewire bus. All the USB and AHCI-attached hardware still showed > up okay, it's just the Firewire stuff that failed to show up properly on boot. > Spent today doing binary search to find the responsible commit and it looks > to be this one: > > r230000 | ken | 2012-01-11 18:41:48 -0600 (Wed, 11 Jan 2012) | 72 lines > > Fix a race condition in CAM peripheral free handling, locking > in the CAM XPT bus traversal code, and a number of other periph level > issues. > > Not sure what in this commit triggers the problem, or why it just hits > Firewire and not the rest of the system. I've built kernels both right > before and right after the r230000 commit, with CAM debugging turned on real > high on the firewire bus in question, bus 0 (hardwired to that number in > device.hints, if that matters) > > options CAMDEBUG > options CAM_DEBUG_BUS=0 > options CAM_DEBUG_TARGET=-1 > options CAM_DEBUG_LUN=-1 > options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_TRACE|CAM_DEBUG_CDB > > and got dmesgs of both the "bad" (r230000) and "good" (pre-r230000) kernels, > which I've put online at http://ln.servalan.com/rmtodd/bug1/dmesg.bad and > http://ln.servalan.com/rmtodd/bug1/dmesg.good, respectively. They're a bit > lengthy, what with all that debug info. Grepping out the info for one of > the targets (disk 0, sbp0:0:0:0) and just looking at the lines for that one, > we see that the "good" kernel does a lot more with that target, starting > with the "(noperiph:sbp0:0:0:0): xpt_compile_path" bit, that the "bad" > kernel doesn't do, as seen in the diff below. > > Not sure what's going on here, but if anyone has suggestions on more things > I can test/debug code I can add to track this down further, let me know. Thanks for testing this out, and for sending all of the debugging output! If you can, please try the attached patch and see if it has any impact on the problem. There is a bug in that commit in that we shouldn't be invalidating all LUNs on a target when we get a status of CAM_DEV_NOT_THERE. It may be that we need to do a more thorough audit of how various SIM drivers are using the CAM_DEV_NOT_THERE status. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cam_periph.c.20120123.1.txt" ==== //depot/users/kenm/FreeBSD-test2/sys/cam/cam_periph.c#7 - /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/cam/cam_periph.c ==== *** /tmp/tmp.87992.13 Mon Jan 23 11:11:36 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/cam/cam_periph.c Mon Jan 23 10:53:13 2012 *************** *** 1864,1876 **** case CAM_DEV_NOT_THERE: { struct cam_path *newpath; error = ENXIO; /* Should we do more if we can't create the path?? */ if (xpt_create_path(&newpath, periph, xpt_path_path_id(ccb->ccb_h.path), xpt_path_target_id(ccb->ccb_h.path), ! CAM_LUN_WILDCARD) != CAM_REQ_CMP) break; /* --- 1864,1889 ---- case CAM_DEV_NOT_THERE: { struct cam_path *newpath; + lun_id_t lun_id; error = ENXIO; + + /* + * For a selection timeout, we consider all of the LUNs on + * the target to be gone. If the status is CAM_DEV_NOT_THERE, + * then we only get rid of the device(s) specified by the + * path in the original CCB. + */ + if (status == CAM_DEV_NOT_THERE) + lun_id = xpt_path_lun_id(ccb->ccb_h.path); + else + lun_id = CAM_LUN_WILDCARD; + /* Should we do more if we can't create the path?? */ if (xpt_create_path(&newpath, periph, xpt_path_path_id(ccb->ccb_h.path), xpt_path_target_id(ccb->ccb_h.path), ! lun_id) != CAM_REQ_CMP) break; /* --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 20:37:25 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4067106566B for ; Mon, 23 Jan 2012 20:37:25 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mx1.freebsd.org (Postfix) with ESMTP id A333B8FC14 for ; Mon, 23 Jan 2012 20:37:25 +0000 (UTC) Received: from [109.84.211.28] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RpQT2-0007i3-8H; Mon, 23 Jan 2012 21:26:16 +0100 Date: Mon, 23 Jan 2012 20:56:06 +0100 From: Fabian Keil To: Pawel Jakub Dawidek Message-ID: <20120123205606.7a9bc26d@fabiankeil.de> In-Reply-To: <20120122112322.GF1723@garage.freebsd.pl> References: <201201212112.q0LLCrQn009840@svn.freebsd.org> <20120122112322.GF1723@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/j+IFZGNSGAdZi9mK==iijZ2"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@FreeBSD.org Subject: Re: Snapshot listing speedup. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:37:26 -0000 --Sig_/j+IFZGNSGAdZi9mK==iijZ2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > If you have many snapshots and you were complaining that listing them > takes a lot of time, you may find the commit below useful. Indeed. =20 > It only works if your listing is limited to snapshot names and you want > to sort also by snapshot name (by default snapshots are sorted by > creation time). After adjusting my backup script, I can confirm that gathering the available snapshots is more than 200 times faster now. Previously figuring out what to send frequently took more time than actually sending the data. Thanks a lot. Fabian --Sig_/j+IFZGNSGAdZi9mK==iijZ2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8du1oACgkQBYqIVf93VJ09CwCfd1YxSFh1mppWC8kv7cFCr3Ss j94AoLTLv06Nrn9pFGsfhywuXv+jkziu =zQ// -----END PGP SIGNATURE----- --Sig_/j+IFZGNSGAdZi9mK==iijZ2-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 00:53:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFF81106566B for ; Tue, 24 Jan 2012 00:53:46 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6C09A8FC08 for ; Tue, 24 Jan 2012 00:53:45 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id q0O0rWfN024567; Tue, 24 Jan 2012 09:53:32 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id q0O0rX327650; Tue, 24 Jan 2012 09:53:33 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi11) id q0O0rWj6027924; Tue, 24 Jan 2012 09:53:32 +0900 Received: from localhost by lomi11.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id q0O0rWmI027839; Tue, 24 Jan 2012 09:53:32 +0900 Date: Tue, 24 Jan 2012 09:53:29 +0900 (JST) Message-Id: <20120124.095329.1799630236416551619.okuno.kohji@jp.panasonic.com> To: hselasky@c2i.net From: Kohji Okuno In-Reply-To: <201201231829.19576.hselasky@c2i.net> References: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> <201201231829.19576.hselasky@c2i.net> Organization: Panasonic Corporation X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com Subject: Re: Is UPS_PORT_POWER wrong? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:53:47 -0000 Hi HPS, > On Monday 23 January 2012 09:12:46 Kohji Okuno wrote: >> Hi HPS, >> >> I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap. >> And, in xhci.c you set UPS_PORT_POWER as folows. >> >> When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET() macro will >> return incorrect value. >> >> if (v & XHCI_PS_PP) { >> /* >> * The USB 3.0 RH is using the >> * USB 2.0's power bit >> */ >> i |= UPS_PORT_POWER; >> } >> > > Hi, > > The USB 3.0 root HUB is special because it defines FULL/HIGH and LOW speed, so > I had to merge that into the port status register of the XHCI root HUB like > this: > > 0: CONNECT_STATUS > 1: PORT_ENABLED > 2: SUSPEND > 3: OVERCURRENT_INDICATOR > 4: LINK STATE (USB 3.0) > 5: - > 6: - > 7: - > 8: PORT_POWER (USB 2.0) > # Bit 9+10 have 4 combinations which are defined: FS, LW, HS, SS > 9: LOW_SPEED (USB 2.0) > 10: HIGH_SPEED (USB 2.0) > 11: not implemented > 12: PORT_INDICATOR > 13: > 14: > 15: MODE_DEVICE (FreeBSD specific) > > If you have a better idea, it is possible to change this. I have a idea. -#define UPS_PORT_LINK_STATE_GET(x) (((x) >> 5) & 0xF) -#define UPS_PORT_LINK_STATE_SET(x) (((x) & 0xF) << 5) +#define UPS_PORT_LINK_STATE_GET(x) ((((x) >> 5) & 0x7)|(((x) >> 11) & 0x8)) +#define UPS_PORT_LINK_STATE_SET(x) ((((x) & 0x7) << 5)|(((x) & 0x8) << 11)) +#define UPS_PORT_LS_SS 0x4000 /* currently FreeBSD specific */ But, this is not cool. Regards, Kohji Okuno From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 06:15:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4115106564A for ; Tue, 24 Jan 2012 06:15:07 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from ln.servalan.com (unknown [IPv6:2600:3c00::f03c:91ff:fe96:62f5]) by mx1.freebsd.org (Postfix) with ESMTP id 86B018FC17 for ; Tue, 24 Jan 2012 06:15:07 +0000 (UTC) Received: from uucp by ln.servalan.com with local-rmail (Exim 4.71) (envelope-from ) id 1RpZet-0005fo-9G for freebsd-current@freebsd.org; Tue, 24 Jan 2012 00:15:07 -0600 Received: from rmtodd by servalan.servalan.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RpZU4-00024y-6S; Tue, 24 Jan 2012 00:03:56 -0600 Date: Tue, 24 Jan 2012 00:03:56 -0600 From: Richard Todd To: "Kenneth D. Merry" Message-ID: <20120124060356.GA4989@ichotolot.servalan.com> References: <20120123025238.GA17816@ichotolot.servalan.com> <20120123181605.GA52248@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120123181605.GA52248@nargothrond.kdm.org> User-Agent: Mutt/1.4.2.3i Cc: Richard Todd , freebsd-current@freebsd.org Subject: Re: Firewire disk/tape access stopped working after recent CAM commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:15:07 -0000 On Mon, Jan 23, 2012 at 11:16:05AM -0700, Kenneth D. Merry wrote: > If you can, please try the attached patch and see if it has any impact on > the problem. There is a bug in that commit in that we shouldn't be > invalidating all LUNs on a target when we get a status of > CAM_DEV_NOT_THERE. Just applied the patch, built new kernel, and rebooted, and all the FW drivees are showing up now. Thanks! > It may be that we need to do a more thorough audit of how various SIM > drivers are using the CAM_DEV_NOT_THERE status. So I take it the layers for the different hardware (SCSI, FW, USB, ATA/AHCI) are handling this status differently, so that's why this bug only showed up on the Firewire buses but not on ATA/AHCI, USB, or (on my other machine) SCSI buses? Richard From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 11:54:26 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23842106564A; Tue, 24 Jan 2012 11:54:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id ABC578FC13; Tue, 24 Jan 2012 11:54:25 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0OBsOXA047250; Tue, 24 Jan 2012 15:54:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0OBsOYB047249; Tue, 24 Jan 2012 15:54:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 24 Jan 2012 15:54:24 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120124115424.GX16676@glebius.int.ru> References: <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1D9128.3030501@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 11:54:26 -0000 On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: A> on 23/01/2012 18:46 Gleb Smirnoff said the following: A> > On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A> > A> > db> bt A> > A> > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 A> > A> > kdb_enter() at kdb_enter+0x3b A> > A> > panic() at panic+0x1c7 A> > A> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f A> > A> > cnputs() at cnputs+0x7a A> > A> > vprintf() at vprintf+0xcb A> > A> > printf() at printf+0x67 A> > A> > db_putc() at db_putc+0x81 A> > A> A> > A> Ah, db_putc does something different from what I expected. A> > A> Can you hack it to never use printf? A> > A> > Just cut printfs from db_putc()? A> A> Make the following condition be always false: A> A> if (!kdb_active || ddb_use_printf) { A> A> E.g.: A> A> if (0) { With this change + s/printf/db_printf/ in subr_witness.c I've got the following during reboot: Rebooting... lllock order reversal: 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 2nd 0xffffffff80b13280 syscons video lock (syscons video lock) @ /usr/src/head/sys/dev/syscons/syscons.c:1921 panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 cpuid = 0 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x3b: movq $0,0x5159f2(%rip) db> bt Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c7 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f cnputs() at cnputs+0x7a putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 kdb_backtrace() at kdb_backtrace+0x2d _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x854 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 scrn_update() at scrn_update+0x41c sc_cnputc() at sc_cnputc+0x46 cnputc() at cnputc+0x4c db_putc() at db_putc+0x4d kvprintf() at kvprintf+0x83 db_printf() at db_printf+0x86 witness_checkorder() at witness_checkorder+0x773 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 sc_puts() at sc_puts+0x97 sc_cnputc() at sc_cnputc+0x3e cnputc() at cnputc+0x4c db_putc() at db_putc+0x4d kvprintf() at kvprintf+0x83 db_printf() at db_printf+0x86 witness_checkorder() at witness_checkorder+0x773 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 uart_cnputc() at uart_cnputc+0x3e cnputc() at cnputc+0x4c cnputs() at cnputs+0x26 putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 cpu_reset() at cpu_reset+0x81 kern_reboot() at kern_reboot+0x3a5 sys_reboot() at sys_reboot+0x42 amd64_syscall() at amd64_syscall+0x39e Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 --- db> -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 12:09:07 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F93A1065674; Tue, 24 Jan 2012 12:09:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2B54B8FC1D; Tue, 24 Jan 2012 12:09:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA20560; Tue, 24 Jan 2012 14:09:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1E9F5F.8080209@FreeBSD.org> Date: Tue, 24 Jan 2012 14:09:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> In-Reply-To: <20120124115424.GX16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:09:07 -0000 on 24/01/2012 13:54 Gleb Smirnoff said the following: > On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: > A> on 23/01/2012 18:46 Gleb Smirnoff said the following: > A> > On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: > A> > A> > db> bt > A> > A> > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 > A> > A> > kdb_enter() at kdb_enter+0x3b > A> > A> > panic() at panic+0x1c7 > A> > A> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f > A> > A> > cnputs() at cnputs+0x7a > A> > A> > vprintf() at vprintf+0xcb > A> > A> > printf() at printf+0x67 > A> > A> > db_putc() at db_putc+0x81 > A> > A> > A> > A> Ah, db_putc does something different from what I expected. > A> > A> Can you hack it to never use printf? > A> > > A> > Just cut printfs from db_putc()? > A> > A> Make the following condition be always false: > A> > A> if (!kdb_active || ddb_use_printf) { > A> > A> E.g.: > A> > A> if (0) { > > With this change + s/printf/db_printf/ in subr_witness.c I've > got the following during reboot: > > Rebooting... > lllock order reversal: > 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 > 2nd 0xffffffff80b13280 syscons video lock (syscons video lock) @ /usr/src/head/sys/dev/syscons/syscons.c:1921 > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 Can you disable video console? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 12:32:48 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286F6106566C; Tue, 24 Jan 2012 12:32:48 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id AA0B08FC0A; Tue, 24 Jan 2012 12:32:47 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0OCWjuS047577; Tue, 24 Jan 2012 16:32:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0OCWjo6047576; Tue, 24 Jan 2012 16:32:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 24 Jan 2012 16:32:45 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120124123245.GZ16676@glebius.int.ru> References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1E9F5F.8080209@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:32:48 -0000 On Tue, Jan 24, 2012 at 02:09:03PM +0200, Andriy Gapon wrote: A> on 24/01/2012 13:54 Gleb Smirnoff said the following: A> > On Mon, Jan 23, 2012 at 06:56:08PM +0200, Andriy Gapon wrote: A> > A> on 23/01/2012 18:46 Gleb Smirnoff said the following: A> > A> > On Mon, Jan 23, 2012 at 06:43:23PM +0200, Andriy Gapon wrote: A> > A> > A> > db> bt A> > A> > A> > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 A> > A> > A> > kdb_enter() at kdb_enter+0x3b A> > A> > A> > panic() at panic+0x1c7 A> > A> > A> > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f A> > A> > A> > cnputs() at cnputs+0x7a A> > A> > A> > vprintf() at vprintf+0xcb A> > A> > A> > printf() at printf+0x67 A> > A> > A> > db_putc() at db_putc+0x81 A> > A> > A> A> > A> > A> Ah, db_putc does something different from what I expected. A> > A> > A> Can you hack it to never use printf? A> > A> > A> > A> > Just cut printfs from db_putc()? A> > A> A> > A> Make the following condition be always false: A> > A> A> > A> if (!kdb_active || ddb_use_printf) { A> > A> A> > A> E.g.: A> > A> A> > A> if (0) { A> > A> > With this change + s/printf/db_printf/ in subr_witness.c I've A> > got the following during reboot: A> > A> > Rebooting... A> > lllock order reversal: A> > 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 A> > 2nd 0xffffffff80b13280 syscons video lock (syscons video lock) @ /usr/src/head/sys/dev/syscons/syscons.c:1921 A> > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 A> A> Can you disable video console? Yes, now: Rebooting... lock order reversal: 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ /usr/src/head/sys/dev/uart/uart_cpu.h:92 panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 cpuid = 0 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x3b: movq $0,0x5159f2(%rip) db> bt Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c7 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f cnputs() at cnputs+0x7a putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 kdb_backtrace() at kdb_backtrace+0x2d _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x854 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 uart_cnputc() at uart_cnputc+0x3e cnputc() at cnputc+0x4c cnputs() at cnputs+0x26 putchar() at putchar+0x11f kvprintf() at kvprintf+0x83 vprintf() at vprintf+0x85 printf() at printf+0x67 cpu_reset() at cpu_reset+0x81 kern_reboot() at kern_reboot+0x3a5 sys_reboot() at sys_reboot+0x42 amd64_syscall() at amd64_syscall+0x39e Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 --- -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 12:57:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B89A106564A; Tue, 24 Jan 2012 12:57:33 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 13A538FC14; Tue, 24 Jan 2012 12:57:32 +0000 (UTC) Received: by qadz30 with SMTP id z30so145571qad.13 for ; Tue, 24 Jan 2012 04:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XJhrAzQpbhpe+BwH7QcATOuKdchpqOqTFf68wzvxiqs=; b=ahHrCqSgP3HRYe1tb0vG/lYh9h9S/7wuMmXwhUZLbjdDRsOv3ZwBxkYQFqdJBYvqY3 w/odU6BN2zIRbh6VCFo7vd6SrGQ6NAu+Q77FUpDmVxX6X/Fyo8muDfdfHf1UXVPoAQWD gKr4aSyosel/vaMrW7BGPHBoivBdyNCEYJEDI= MIME-Version: 1.0 Received: by 10.224.197.5 with SMTP id ei5mr14659263qab.73.1327409852205; Tue, 24 Jan 2012 04:57:32 -0800 (PST) Received: by 10.229.124.11 with HTTP; Tue, 24 Jan 2012 04:57:02 -0800 (PST) In-Reply-To: <4F1ACBA8.6000203@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> Date: Tue, 24 Jan 2012 13:57:02 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:57:33 -0000 2012/1/21 Alexander Motin > > From that description I can conclude that you are passing through > compressed DTS-HD and TrueHD streams to the receiver. What are the bitrates > of streams you are playing? It looks like your receiver doesn't receives > all data. If I understand right, to transfer with compressed bitrates above > 6.144Mbps special High Bit Rate mode should be activated in CODEC, when > data stream occupies all 8 HDMI channels instead of 2. I haven't > implemented this feature yet as my receiver doesn't support such HD formats. > i dont think bitrate is over 6.144Mbps. for TrueHD files, mediainfo reports: Format profile : TrueHD / Core Mode extension : CM (complete main) Codec ID : 131 Bit rate mode : Variable / Constant Bit rate : Unknown / 640 Kbps Maximum bit rate : 2 868 Kbps / 640 Kbps Channel(s) : 6 channels and for DTS-HDMA, mediainfo can't calculate it, but from description, all tested file have bitrate below 3689 kbps > I'll try to make a patch for it a bit later and send you to try. i'll be happy to try it. Until that time, is it possible to make your xbmc to decode those HD > streams into different number of uncompressed LPCM channels to play it that > way? yes, it's just an option. It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM configurations > with your receiver. Or at least normal definition 7.1 playback would be > interesting to test (you can just set vchanformat to s16le:7.1 or s32le:7.1 > and play anything). > > i sucessfully tried 6.1 and 7.1 LPCM in 16 bits. just a small channel order issue (center and a surround back inversion) which can be solved easily. i'll add 32bits support in XBMC later for my test but from what you say, it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s. > What do you mean that you can't set more then 2 channels? I've never tried > to set ac3 format with more then 2 channels, but s16le:7.1 and s32le:7.1 > should work fine. At least s16le:5.1 and s32le:5.1 are working perfectly > for me. For HDA 24bit samples stored in memory as 32bit, so setting s24le > format only cause extra 24->32bit conversion. > > > i never show things like PCMDIR_...: Stream setup.... in my messages, so >> may be i use oss wrongly. >> > > They are printed only when hw.snd.verbose set to 4. > > ok thanks for the tips. From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 12:57:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C2E1065672; Tue, 24 Jan 2012 12:57:54 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19BBE8FC1D; Tue, 24 Jan 2012 12:57:53 +0000 (UTC) Received: by qcse1 with SMTP id e1so2872825qcs.13 for ; Tue, 24 Jan 2012 04:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HPOupBZfFXVHXVbjB98ET9QD5uYurQj1Z7VwCP2ROA=; b=YwGa5wH4zA25OnejzRYWlDyTwi0kKuLEZ32f4K0tcPaHMNnJ6KK2qC9cNlq4kBZBLU XNSPIbZENExs7fRJMs5+4AlzR2aLiNH0pJgyCaiRdB5TjTMU8mlGltND2p50D4pfwsat xl3tKe/pnqUGAeNT07vM28WuxENNnVBqDbffY= MIME-Version: 1.0 Received: by 10.224.214.201 with SMTP id hb9mr14453771qab.86.1327409843380; Tue, 24 Jan 2012 04:57:23 -0800 (PST) Received: by 10.229.124.11 with HTTP; Tue, 24 Jan 2012 04:57:02 -0800 (PST) In-Reply-To: <4F1ACBA8.6000203@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> Date: Tue, 24 Jan 2012 13:57:02 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:57:54 -0000 2012/1/21 Alexander Motin > > From that description I can conclude that you are passing through > compressed DTS-HD and TrueHD streams to the receiver. What are the bitrates > of streams you are playing? It looks like your receiver doesn't receives > all data. If I understand right, to transfer with compressed bitrates above > 6.144Mbps special High Bit Rate mode should be activated in CODEC, when > data stream occupies all 8 HDMI channels instead of 2. I haven't > implemented this feature yet as my receiver doesn't support such HD formats. > i dont think bitrate is over 6.144Mbps. for TrueHD files, mediainfo reports: Format profile : TrueHD / Core Mode extension : CM (complete main) Codec ID : 131 Bit rate mode : Variable / Constant Bit rate : Unknown / 640 Kbps Maximum bit rate : 2 868 Kbps / 640 Kbps Channel(s) : 6 channels and for DTS-HDMA, mediainfo can't calculate it, but from description, all tested file have bitrate below 3689 kbps > I'll try to make a patch for it a bit later and send you to try. i'll be happy to try it. Until that time, is it possible to make your xbmc to decode those HD > streams into different number of uncompressed LPCM channels to play it that > way? yes, it's just an option. It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM configurations > with your receiver. Or at least normal definition 7.1 playback would be > interesting to test (you can just set vchanformat to s16le:7.1 or s32le:7.1 > and play anything). > > i sucessfully tried 6.1 and 7.1 LPCM in 16 bits. just a small channel order issue (center and a surround back inversion) which can be solved easily. i'll add 32bits support in XBMC later for my test but from what you say, it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s. > What do you mean that you can't set more then 2 channels? I've never tried > to set ac3 format with more then 2 channels, but s16le:7.1 and s32le:7.1 > should work fine. At least s16le:5.1 and s32le:5.1 are working perfectly > for me. For HDA 24bit samples stored in memory as 32bit, so setting s24le > format only cause extra 24->32bit conversion. > > > i never show things like PCMDIR_...: Stream setup.... in my messages, so >> may be i use oss wrongly. >> > > They are printed only when hw.snd.verbose set to 4. > > ok thanks for the tips. From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 13:33:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2A05106566B; Tue, 24 Jan 2012 13:33:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49D898FC0C; Tue, 24 Jan 2012 13:32:59 +0000 (UTC) Received: by eaai10 with SMTP id i10so1741497eaa.13 for ; Tue, 24 Jan 2012 05:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=x5OwAXmjcm0/4YIbB8u/6ikZYaoLLU5fvJGu0SW9RIY=; b=ZGsmrAqpjoY7p/eCxvl6MwgytyQhaPPQZND4z/d7URH01URjrsFsudfhXYCb4DRF1f /NH9gtluIEFVvPH1hievGynupCNr2l8Sl0UGSHtUR/IYiVCzyNMrIZiyHp2d5TIaMIKX gXLfOiE7/U5kVUPt4HHgXlU1qjXX8D4LsDPlo= Received: by 10.213.4.16 with SMTP id 16mr2370547ebp.93.1327411978980; Tue, 24 Jan 2012 05:32:58 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id e12sm67683312eea.5.2012.01.24.05.32.55 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 05:32:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1EB305.9000105@FreeBSD.org> Date: Tue, 24 Jan 2012 15:32:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:33:01 -0000 On 01/24/12 14:57, Mickaël Maillot wrote: > 2012/1/21 Alexander Motin > > From that description I can conclude that you are passing through > compressed DTS-HD and TrueHD streams to the receiver. What are the > bitrates of streams you are playing? It looks like your receiver > doesn't receives all data. If I understand right, to transfer with > compressed bitrates above 6.144Mbps special High Bit Rate mode > should be activated in CODEC, when data stream occupies all 8 HDMI > channels instead of 2. I haven't implemented this feature yet as my > receiver doesn't support such HD formats. > > > i dont think bitrate is over 6.144Mbps. > for TrueHD files, mediainfo reports: > > Format profile : TrueHD / Core > Mode extension : CM (complete main) > Codec ID : 131 > Bit rate mode : Variable / Constant > Bit rate : Unknown / 640 Kbps > Maximum bit rate : 2 868 Kbps / 640 Kbps > Channel(s) : 6 channels > > and for DTS-HDMA, mediainfo can't calculate it, but from description, > all tested file have bitrate below 3689 kbps Then make sure that your player properly sets "sampling rate" for the playback. Data transferred as "16bit stereo", but depending on bit rate may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps and 6Mbps respectively). For higher bit rates stream transferred as 8-channel (High Bit Rate mode) with same set of frequencies (but now up to 12, 24 and 49Mbps). > I'll try to make a patch for it a bit later and send you to try. > > i'll be happy to try it. > > Until that time, is it possible to make your xbmc to decode those HD > streams into different number of uncompressed LPCM channels to play > it that way? > > > yes, it's just an option. > > It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM > configurations with your receiver. Or at least normal definition 7.1 > playback would be interesting to test (you can just set vchanformat > to s16le:7.1 or s32le:7.1 and play anything). > > i sucessfully tried 6.1 and 7.1 LPCM in 16 bits. > just a small channel order issue (center and a surround back inversion) > which can be solved easily. In what number of channels which channels are swapped specifically? I've compared mapping I am setting in driver with data I have and found no problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left, Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've never could check what mplayer thinks about it because I have no such such media. Can you give me some example? > i'll add 32bits support in XBMC later for my test but from what you say, > it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s. 6Mbps limitation is only for data, as they use only two channels by default. Audio stream has no such limit. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 14:25:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1024106564A for ; Tue, 24 Jan 2012 14:25:09 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 37D408FC08 for ; Tue, 24 Jan 2012 14:25:09 +0000 (UTC) Received: from [46.255.176.2] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RphJ5-0003uW-3b; Tue, 24 Jan 2012 15:25:07 +0100 Message-ID: <4F1EBF42.4050307@FreeBSD.org> Date: Tue, 24 Jan 2012 15:25:06 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------070505030600020006010808" Cc: Pierre-Gilles Mialon , Romain Vrignaud Subject: [patch] pam_exec: use program exit code instead of PAM_SYSTEM_ERR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:25:09 -0000 This is a multi-part message in MIME format. --------------070505030600020006010808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, If the specified program exits with non-zero, current implementation of pam_exec(8) logs this code and return PAM_SYSTEM_ERR. Therefore, applications have no idea what went wrong with authentication. Attached is a patch that changes the behaviour to always return the program exit code as-is. This lets the program returns meaningful informations to applications. I also added a small paragraph explaining this to the man page. I'm planning to commit this to -CURRENT (maybe in a week or two) and merge it to 9 and 8 if there're no objections. Thanks for any comments! - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8ev0IACgkQa+xGJsFYOlNjyACfSg6NgDLy+7VF6rEVV6yTINTd rlgAoNpgWLvYBEL2DCejuPDz0yQRf5QY =JEte -----END PGP SIGNATURE----- --------------070505030600020006010808 Content-Type: text/plain; name="pam_exec-return-exit-code-c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pam_exec-return-exit-code-c.patch" diff --git a/lib/libpam/modules/pam_exec/pam_exec.8 b/lib/libpam/modules/pam_exec/pam_exec.8 index 311d64c..c5d2404 100644 --- a/lib/libpam/modules/pam_exec/pam_exec.8 +++ b/lib/libpam/modules/pam_exec/pam_exec.8 @@ -32,7 +32,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 1, 2005 +.Dd January 24, 2012 .Dt PAM_EXEC 8 .Os .Sh NAME @@ -59,6 +59,12 @@ variables: .Ev PAM_TTY , and .Ev PAM_USER . +.Pp +The program exit code should be one of the codes defined in +.Pa /usr/include/security/pam_constants.h +under section "XSSO 5.2". Authentication is successful if the return code is +.Er PAM_SUCCESS +(0), failed otherwise. .Sh SEE ALSO .Xr pam_get_item 3 , .Xr pam.conf 5 , diff --git a/lib/libpam/modules/pam_exec/pam_exec.c b/lib/libpam/modules/pam_exec/pam_exec.c index b7a870f..d497479 100644 --- a/lib/libpam/modules/pam_exec/pam_exec.c +++ b/lib/libpam/modules/pam_exec/pam_exec.c @@ -141,12 +141,7 @@ _pam_exec(pam_handle_t *pamh __unused, int flags __unused, openpam_log(PAM_LOG_ERROR, "unknown status 0x%x", status); return (PAM_SYSTEM_ERR); } - if (WEXITSTATUS(status) != 0) { - openpam_log(PAM_LOG_ERROR, "%s returned code %d", - argv[0], WEXITSTATUS(status)); - return (PAM_SYSTEM_ERR); - } - return (PAM_SUCCESS); + return (WEXITSTATUS(status)); } PAM_EXTERN int --------------070505030600020006010808-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 16:33:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24EA7106566C; Tue, 24 Jan 2012 16:33:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 770278FC08; Tue, 24 Jan 2012 16:33:08 +0000 (UTC) Received: by eekb47 with SMTP id b47so1793020eek.13 for ; Tue, 24 Jan 2012 08:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kI9oJaupldR0+Ml0HLWAqcgIwj6U+sDaWhhdasLFEeQ=; b=UI7MGptmisrB7LRiTNio4fTv8E55hAhTleb3d52ZwJOfPryaay8m4CHSeO0AsO6Mmw U7kbpwDnK8iDF8EHm/DLctqx1F9BxYZmJR38ssdrzaWL//v4FXbtM0+cgB18TvY78+ai XpqIzXpQm2qBfAkfys9EAVY/7sd7PW479+JX4= Received: by 10.14.123.10 with SMTP id u10mr4813035eeh.71.1327422786275; Tue, 24 Jan 2012 08:33:06 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c16sm69557813eei.1.2012.01.24.08.33.02 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 08:33:02 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1EDD3D.6070800@FreeBSD.org> Date: Tue, 24 Jan 2012 18:33:01 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> In-Reply-To: <4F1EB305.9000105@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:33:09 -0000 On 01/24/12 15:32, Alexander Motin wrote: > On 01/24/12 14:57, Mickaël Maillot wrote: >> 2012/1/21 Alexander Motin > >> From that description I can conclude that you are passing through >> compressed DTS-HD and TrueHD streams to the receiver. What are the >> bitrates of streams you are playing? It looks like your receiver >> doesn't receives all data. If I understand right, to transfer with >> compressed bitrates above 6.144Mbps special High Bit Rate mode >> should be activated in CODEC, when data stream occupies all 8 HDMI >> channels instead of 2. I haven't implemented this feature yet as my >> receiver doesn't support such HD formats. >> >> >> i dont think bitrate is over 6.144Mbps. >> for TrueHD files, mediainfo reports: >> >> Format profile : TrueHD / Core >> Mode extension : CM (complete main) >> Codec ID : 131 >> Bit rate mode : Variable / Constant >> Bit rate : Unknown / 640 Kbps >> Maximum bit rate : 2 868 Kbps / 640 Kbps >> Channel(s) : 6 channels >> >> and for DTS-HDMA, mediainfo can't calculate it, but from description, >> all tested file have bitrate below 3689 kbps > > Then make sure that your player properly sets "sampling rate" for the > playback. Data transferred as "16bit stereo", but depending on bit rate > may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps > and 6Mbps respectively). For higher bit rates stream transferred as > 8-channel (High Bit Rate mode) with same set of frequencies (but now up > to 12, 24 and 49Mbps). > >> I'll try to make a patch for it a bit later and send you to try. >> >> i'll be happy to try it. Here is it: http://people.freebsd.org/~mav/hda.HBR.patch It should activate HBR mode if you try to play stream with AC3 format and 8 channels (>6Mbps). >> Until that time, is it possible to make your xbmc to decode those HD >> streams into different number of uncompressed LPCM channels to play >> it that way? >> >> >> yes, it's just an option. >> >> It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM >> configurations with your receiver. Or at least normal definition 7.1 >> playback would be interesting to test (you can just set vchanformat >> to s16le:7.1 or s32le:7.1 and play anything). >> >> i sucessfully tried 6.1 and 7.1 LPCM in 16 bits. >> just a small channel order issue (center and a surround back inversion) >> which can be solved easily. > > In what number of channels which channels are swapped specifically? I've > compared mapping I am setting in driver with data I have and found no > problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left, > Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've > never could check what mplayer thinks about it because I have no such > such media. Can you give me some example? > >> i'll add 32bits support in XBMC later for my test but from what you say, >> it'll not work because 8 channels / 48khz / 16 bits = 6.144 Mbit/s. > > 6Mbps limitation is only for data, as they use only two channels by > default. Audio stream has no such limit. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 17:40:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE0CD1065677 for ; Tue, 24 Jan 2012 17:40:40 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE7B8FC0C for ; Tue, 24 Jan 2012 17:40:40 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q0OHedxZ087982; Tue, 24 Jan 2012 10:40:39 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q0OHed2O087981; Tue, 24 Jan 2012 10:40:39 -0700 (MST) (envelope-from ken) Date: Tue, 24 Jan 2012 10:40:39 -0700 From: "Kenneth D. Merry" To: Richard Todd Message-ID: <20120124174039.GA87021@nargothrond.kdm.org> References: <20120123025238.GA17816@ichotolot.servalan.com> <20120123181605.GA52248@nargothrond.kdm.org> <20120124060356.GA4989@ichotolot.servalan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120124060356.GA4989@ichotolot.servalan.com> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: Firewire disk/tape access stopped working after recent CAM commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:40:40 -0000 On Tue, Jan 24, 2012 at 00:03:56 -0600, Richard Todd wrote: > On Mon, Jan 23, 2012 at 11:16:05AM -0700, Kenneth D. Merry wrote: > > If you can, please try the attached patch and see if it has any impact on > > the problem. There is a bug in that commit in that we shouldn't be > > invalidating all LUNs on a target when we get a status of > > CAM_DEV_NOT_THERE. > > Just applied the patch, built new kernel, and rebooted, and all the FW > drivees are showing up now. Thanks! Great! > > It may be that we need to do a more thorough audit of how various SIM > > drivers are using the CAM_DEV_NOT_THERE status. > > So I take it the layers for the different hardware (SCSI, FW, USB, > ATA/AHCI) are handling this status differently, so that's why this bug only > showed up on the Firewire buses but not on ATA/AHCI, USB, or (on my other > machine) SCSI buses? Yes. Some drivers report a selection timeout, some report that the device isn't there, and they may be using those status values in different situations. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 18:11:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8111065677 for ; Tue, 24 Jan 2012 18:11:45 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 723D38FC0A for ; Tue, 24 Jan 2012 18:11:42 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Tue, 24 Jan 2012 18:29:55 +0100 id 00033CEA.4F1EEA93.0000FE54 Date: Tue, 24 Jan 2012 18:31:52 +0100 From: Milan Obuch To: freebsd-current@freebsd.org Message-ID: <20120124183152.40c5c5af@atom.dino.sk> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 18:11:45 -0000 Hi, as I succesfully installed FreeBSD on Mac Mini (older powerpc model with G4 CPU) I tried to use mount_nullfs to share some files for more systems. I use this method for years on i386 and amd64 platforms for years now to share sources and other files. Basically I want to have small system specific slice/partition and large shared data area. System sources are in shared area as well as some working area (think /usr/src and /usr/obj directories). This does not work with powerpc for me. With sources csup'ped this morning, full system rebuild with GENERIC kernel, it is enough for me to issue mount_nullfs /data/src10 /usr/src csup /usr/share/examples/cvsup/standard-supfile and system panic occurs, with following on system console: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/vfs_subr.c:2670 cpuid = 0 KDB: enter: panic [ thread pid 1442 tid 100095 ] Stopped at 0x40f734: addi r0, r0, 0x0 db> At this point, I am able to interact with system, the question for me is what I want to get from it :) I tried bt with following result: Tracing pid 1442 tid 100095 td 0x2d6b000 0xe22c26d0: at panic+0x274 0xe22c2730: at _mtx_lock_flags+0xc4 0xe22c2760: at vgonel+0x330 0xe22c27b0: at vrecycle+0x54 0xe22c27d0: at null_inactive+0x30 0xe22c27f0: at VOP_INACTIVE_APV+0xdc 0xe22c2810: at vinactive+0x98 0xe22c2850: at vputx+0x344 0xe22c28a0: at vput+0x18 0xe22c28c0: at kern_statat_vnhook+0x108 0xe22c29d0: at kern_statat+0x18 0xe22c29f0: at kern_lstat+0x2c 0xe22c2a10: at sys_lstat+0x30 0xe22c2a90: at trap+0x388 0xe22c2b60: at powerpc_interrupt+0x108 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=0xd032 r1=0xffaf9a70 cr=0x28004044 xer=0x20000000 ctr=0x41a0ac40 db> Does this shed any light for someone with more knowledge here? My gut feeling is there is some endianness issue at play, the same nullfs usage works for me flawlessly on both i386 and amd64 systems, so it could not be 32 vs 64 bit issue at least. At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function void vgonel(struct vnode *vp) VI_LOCK(vp); vp->v_vnlock = &vp->v_lock; vp->v_op = &dead_vnodeops; vp->v_tag = "none"; vp->v_type = VBAD; } so the question seems to be reduced to 'why is vp null?' or is my small attempt on analyse flawed... Regards, Milan From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 22:13:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D12106566B; Tue, 24 Jan 2012 22:13:14 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D47C78FC14; Tue, 24 Jan 2012 22:13:13 +0000 (UTC) Received: by qaea17 with SMTP id a17so2974968qae.13 for ; Tue, 24 Jan 2012 14:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=89u+nAO6cNL/QKEtOzket1RIojAkPeFXUt4QweEvQ1U=; b=AUiQMrn9srRY2RgMd5qxlpS3gJWqttSwuqc9qo4Ncaac67F/66kQrOz230pi+2FDML /E/Eko4h8bp6+RF+N/SEueozXr3QgmRfJSveS/MfqIcUWj52iFxXPxHiJNbojBnnKTc0 /za6PZ4b1tjcOluMvggfwEEugz/WwDyHUWn0w= MIME-Version: 1.0 Received: by 10.224.197.5 with SMTP id ei5mr17800652qab.73.1327443193066; Tue, 24 Jan 2012 14:13:13 -0800 (PST) Received: by 10.229.124.11 with HTTP; Tue, 24 Jan 2012 14:13:12 -0800 (PST) In-Reply-To: <4F1EDD3D.6070800@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> Date: Tue, 24 Jan 2012 23:13:12 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:13:14 -0000 2012/1/24 Alexander Motin > On 01/24/12 15:32, Alexander Motin wrote: > >> On 01/24/12 14:57, Micka=EBl Maillot wrote: >> >>> 2012/1/21 Alexander Motin > >>> From that description I can conclude that you are passing through >>> compressed DTS-HD and TrueHD streams to the receiver. What are the >>> bitrates of streams you are playing? It looks like your receiver >>> doesn't receives all data. If I understand right, to transfer with >>> compressed bitrates above 6.144Mbps special High Bit Rate mode >>> should be activated in CODEC, when data stream occupies all 8 HDMI >>> channels instead of 2. I haven't implemented this feature yet as my >>> receiver doesn't support such HD formats. >>> >>> >>> i dont think bitrate is over 6.144Mbps. >>> for TrueHD files, mediainfo reports: >>> >>> Format profile : TrueHD / Core >>> Mode extension : CM (complete main) >>> Codec ID : 131 >>> Bit rate mode : Variable / Constant >>> Bit rate : Unknown / 640 Kbps >>> Maximum bit rate : 2 868 Kbps / 640 Kbps >>> Channel(s) : 6 channels >>> >>> and for DTS-HDMA, mediainfo can't calculate it, but from description, >>> all tested file have bitrate below 3689 kbps >>> >> >> Then make sure that your player properly sets "sampling rate" for the >> playback. Data transferred as "16bit stereo", but depending on bit rate >> may have 48000, 96000 or 192000Hz sampling rate (up to 1.5Mbps, 3Mbps >> and 6Mbps respectively). For higher bit rates stream transferred as >> 8-channel (High Bit Rate mode) with same set of frequencies (but now up >> to 12, 24 and 49Mbps). >> >> I'll try to make a patch for it a bit later and send you to try. >>> >>> i'll be happy to try it. >>> >> > Here is it: http://people.freebsd.org/~**mav/hda.HBR.patch > It should activate HBR mode if you try to play stream with AC3 format and > 8 channels (>6Mbps). > > no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3, SNDCTL_DSP_CHANNELS always return 2 channels even if i set SNDCTL_DSP_SPEED to 192000. and i think it's why "if ((ch->fmt & AFMT_AC3) && (cchn =3D=3D 8))" can't b= e true. i checked my /v/l/messages and saw PCMDIR_PLAY ....chan_count=3D0x01. i can set 8 channels without problems with AFMT_S32_LE format and sound works: kernel: hdac1: 36864Kbps of 92160Kbps bandwidth used kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=3D02801000 (7.1) speed=3D192000 kernel: pcm4: PCMDIR_PLAY: Stream setup nid=3D4: fmt=3D0x1837, dfmt=3D0x000= 1, chan=3D0x0010, chan_count=3D0x07, stripe=3D1 > > Until that time, is it possible to make your xbmc to decode those HD >>> streams into different number of uncompressed LPCM channels to play >>> it that way? >>> >>> >>> yes, it's just an option. >>> >>> It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM >>> configurations with your receiver. Or at least normal definition 7.1 >>> playback would be interesting to test (you can just set vchanformat >>> to s16le:7.1 or s32le:7.1 and play anything). >>> >>> i sucessfully tried 6.1 and 7.1 LPCM in 16 bits. >>> just a small channel order issue (center and a surround back inversion) >>> which can be solved easily. >>> >> >> In what number of channels which channels are swapped specifically? I've >> compared mapping I am setting in driver with data I have and found no >> problem. What channel order for 7.1 uses xbmc? sound(4) uses: Left, >> Right, Rear Left, Rear Right, Center, LFE, Side Left, Side Right. I've >> never could check what mplayer thinks about it because I have no such >> such media. Can you give me some example? >> >> ok mapping is good, i think the swap is in XBMC, i'll check later with xbmc's audio dev. > i'll add 32bits support in XBMC later for my test but from what you say, >>> it'll not work because 8 channels / 48khz / 16 bits =3D 6.144 Mbit/s. >>> >> >> 6Mbps limitation is only for data, as they use only two channels by >> default. Audio stream has no such limit. >> > > yep, it works ! From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 21:53:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57067106564A; Tue, 24 Jan 2012 21:53:24 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by mx1.freebsd.org (Postfix) with ESMTP id C6AF28FC14; Tue, 24 Jan 2012 21:53:23 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTx8oU1Zs5U078dvrFIgDmQUT5XMxaoTf@postini.com; Tue, 24 Jan 2012 13:53:23 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 24 Jan 2012 13:36:54 -0800 From: Marcel Moolenaar To: freebsd-current Current Date: Tue, 24 Jan 2012 13:36:55 -0800 Thread-Topic: [ptrace] please review follow fork/exec changes Thread-Index: Acza4Eq96UY0ancSQBq4BmEk1VYZSg== Message-ID: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_749E238AA85F42649DEBBCE1BBD21C9Djunipernet_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 24 Jan 2012 22:28:03 +0000 Cc: Konstantin Belousov , Dmitry Mikulin Subject: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:53:24 -0000 --_002_749E238AA85F42649DEBBCE1BBD21C9Djunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Please review the attached changes (done by Dmitry -- CC'd) to add support = for PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK. I'll commit this when there are no comments/objections. Thanks, --=20 Marcel Moolenaar marcelm@juniper.net --_002_749E238AA85F42649DEBBCE1BBD21C9Djunipernet_ Content-Type: text/x-patch; name="kernel.diff" Content-Description: kernel.diff Content-Disposition: attachment; filename="kernel.diff"; size=12136; creation-date="Tue, 24 Jan 2012 21:36:54 GMT"; modification-date="Tue, 24 Jan 2012 21:36:54 GMT" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9rZXJuL2tlcm5fZXhpdC5jDQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0NCi0tLSBzeXMva2Vybi9r ZXJuX2V4aXQuYwkocmV2aXNpb24gMjI1MTg5KQ0NCisrKyBzeXMva2Vybi9rZXJuX2V4aXQuYwko d29ya2luZyBjb3B5KQ0NCkBAIC02ODAsNyArNjgwLDcgQEAgd2FpdDQoc3RydWN0IHRocmVhZCAq dGQsIHN0cnVjdCB3YWl0X2FyZ3MgKnVhcCkNDQogICovDQ0KIHZvaWQNDQogcHJvY19yZWFwKHN0 cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgcHJvYyAqcCwgaW50ICpzdGF0dXMsIGludCBvcHRpb25z LA0NCi0gICAgc3RydWN0IHJ1c2FnZSAqcnVzYWdlKQ0NCisgICAgc3RydWN0IHJ1c2FnZSAqcnVz YWdlLCBpbnQgY2hpbGQpDQ0KIHsNDQogCXN0cnVjdCBwcm9jICpxLCAqdDsNDQogDQ0KQEAgLTcy MCw3ICs3MjAsNiBAQCBwcm9jX3JlYXAoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBwcm9jICpw LCBpbnQgKg0NCiAJaWYgKHAtPnBfb3BwaWQgJiYgKHQgPSBwZmluZChwLT5wX29wcGlkKSkgIT0g TlVMTCkgew0NCiAJCVBST0NfTE9DSyhwKTsNDQogCQlwcm9jX3JlcGFyZW50KHAsIHQpOw0NCi0J CXAtPnBfcHB0ci0+cF9kYmdfY2hpbGQtLTsNDQogCQlwLT5wX29wcGlkID0gMDsNDQogCQlQUk9D X1VOTE9DSyhwKTsNDQogCQlwa3NpZ25hbCh0LCBTSUdDSExELCBwLT5wX2tzaSk7DQ0KQEAgLTcz OCw3ICs3MzcsMTAgQEAgcHJvY19yZWFwKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgcHJvYyAq cCwgaW50ICoNDQogCXN4X3hsb2NrKCZhbGxwcm9jX2xvY2spOw0NCiAJTElTVF9SRU1PVkUocCwg cF9saXN0KTsJLyogb2ZmIHpvbWJwcm9jICovDQ0KIAlzeF94dW5sb2NrKCZhbGxwcm9jX2xvY2sp Ow0NCi0JTElTVF9SRU1PVkUocCwgcF9zaWJsaW5nKTsNDQorCWlmIChjaGlsZCkNDQorCQlMSVNU X1JFTU9WRShwLCBwX3NpYmxpbmcpOw0NCisJZWxzZQ0NCisJCUxJU1RfUkVNT1ZFKHAsIHBfb3Jw aGFuKTsNDQogCWxlYXZlcGdycChwKTsNDQogI2lmZGVmIFBST0NERVNDDQ0KIAlpZiAocC0+cF9w cm9jZGVzYyAhPSBOVUxMKQ0NCkBAIC04NTksNyArODYxLDcgQEAgbG9vcDoNDQogCQluZm91bmQr KzsNDQogCQlQUk9DX1NMT0NLKHApOw0NCiAJCWlmIChwLT5wX3N0YXRlID09IFBSU19aT01CSUUp IHsNDQotCQkJcHJvY19yZWFwKHRkLCBwLCBzdGF0dXMsIG9wdGlvbnMsIHJ1c2FnZSk7DQ0KKwkJ CXByb2NfcmVhcCh0ZCwgcCwgc3RhdHVzLCBvcHRpb25zLCBydXNhZ2UsIDEpOw0NCiAJCQlyZXR1 cm4gKDApOw0NCiAJCX0NDQogCQlpZiAoKHAtPnBfZmxhZyAmIFBfU1RPUFBFRF9TSUcpICYmDQ0K QEAgLTg5MywxNiArODk1LDQ3IEBAIGxvb3A6DQ0KIA0NCiAJCQlpZiAoc3RhdHVzKQ0NCiAJCQkJ KnN0YXR1cyA9IFNJR0NPTlQ7DQ0KKwkJfQ0NCisJCVBST0NfVU5MT0NLKHApOw0NCisJfQ0NCisJ TElTVF9GT1JFQUNIKHAsICZxLT5wX29ycGhhbnMsIHBfb3JwaGFuKSB7DQ0KKwkJUFJPQ19MT0NL KHApOw0NCisJCWlmIChwaWQgIT0gV0FJVF9BTlkgJiYNDQorCQkgICAgcC0+cF9waWQgIT0gcGlk ICYmIHAtPnBfcGdpZCAhPSAtcGlkKSB7DQ0KKwkJCVBST0NfVU5MT0NLKHApOw0NCisJCQljb250 aW51ZTsNDQorCQl9DQ0KKwkJaWYgKHBfY2Fud2FpdCh0ZCwgcCkpIHsNDQorCQkJUFJPQ19VTkxP Q0socCk7DQ0KKwkJCWNvbnRpbnVlOw0NCisJCX0NDQorDQ0KKwkJLyoNDQorCQkgKiBUaGlzIHNw ZWNpYWwgY2FzZSBoYW5kbGVzIGEga3RocmVhZCBzcGF3bmVkIGJ5IGxpbnV4X2Nsb25lDQ0KKwkJ ICogKHNlZSBsaW51eF9taXNjLmMpLiAgVGhlIGxpbnV4X3dhaXQ0IGFuZCBsaW51eF93YWl0cGlk DQ0KKwkJICogZnVuY3Rpb25zIG5lZWQgdG8gYmUgYWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu IHdhaXRpbmcNDQorCQkgKiBvbiBhIHByb2Nlc3MgYW5kIHdhaXRpbmcgb24gYSB0aHJlYWQuICBJ dCBpcyBhIHRocmVhZCBpZg0NCisJCSAqIHBfc2lncGFyZW50IGlzIG5vdCBTSUdDSExELCBhbmQg dGhlIFdMSU5VWENMT05FIG9wdGlvbg0NCisJCSAqIHNpZ25pZmllcyB3ZSB3YW50IHRvIHdhaXQg Zm9yIHRocmVhZHMgYW5kIG5vdCBwcm9jZXNzZXMuDQ0KKwkJICovDQ0KKwkJaWYgKChwLT5wX3Np Z3BhcmVudCAhPSBTSUdDSExEKSBeDQ0KKwkJICAgICgob3B0aW9ucyAmIFdMSU5VWENMT05FKSAh PSAwKSkgew0NCisJCQlQUk9DX1VOTE9DSyhwKTsNDQorCQkJY29udGludWU7DQ0KKwkJfQ0NCisN DQorCQluZm91bmQrKzsNDQorCQlQUk9DX1NMT0NLKHApOw0NCisJCWlmIChwLT5wX3N0YXRlID09 IFBSU19aT01CSUUpIHsNDQorCQkgIHByb2NfcmVhcCh0ZCwgcCwgc3RhdHVzLCBvcHRpb25zLCBy dXNhZ2UsIDApOw0NCiAJCQlyZXR1cm4gKDApOw0NCiAJCX0NDQorCQlQUk9DX1NVTkxPQ0socCk7 DQ0KIAkJUFJPQ19VTkxPQ0socCk7DQ0KIAl9DQ0KIAlpZiAobmZvdW5kID09IDApIHsNDQogCQlz eF94dW5sb2NrKCZwcm9jdHJlZV9sb2NrKTsNDQotCQlpZiAodGQtPnRkX3Byb2MtPnBfZGJnX2No aWxkKQ0NCi0JCQlyZXR1cm4gKDApOw0NCi0JCWVsc2UNDQotCQkJcmV0dXJuIChFQ0hJTEQpOw0N CisJCXJldHVybiAoRUNISUxEKTsNDQogCX0NDQogCWlmIChvcHRpb25zICYgV05PSEFORykgew0N CiAJCXN4X3h1bmxvY2soJnByb2N0cmVlX2xvY2spOw0NCkBAIC05MzIsNiArOTY1LDcgQEAgcHJv Y19yZXBhcmVudChzdHJ1Y3QgcHJvYyAqY2hpbGQsIHN0cnVjdCBwcm9jICpwYXINDQogI2lmZGVm IFJBQ0NUDQ0KIAlpbnQgbG9ja2VkOw0NCiAjZW5kaWYNDQorCXN0cnVjdCBwcm9jICpwOw0NCiAN DQogCXN4X2Fzc2VydCgmcHJvY3RyZWVfbG9jaywgU1hfWExPQ0tFRCk7DQ0KIAlQUk9DX0xPQ0tf QVNTRVJUKGNoaWxkLCBNQV9PV05FRCk7DQ0KQEAgLTk1Miw1ICs5ODYsMTcgQEAgcHJvY19yZXBh cmVudChzdHJ1Y3QgcHJvYyAqY2hpbGQsIHN0cnVjdCBwcm9jICpwYXINDQogCVBST0NfVU5MT0NL KGNoaWxkLT5wX3BwdHIpOw0NCiAJTElTVF9SRU1PVkUoY2hpbGQsIHBfc2libGluZyk7DQ0KIAlM SVNUX0lOU0VSVF9IRUFEKCZwYXJlbnQtPnBfY2hpbGRyZW4sIGNoaWxkLCBwX3NpYmxpbmcpOw0N CisNDQorCUxJU1RfRk9SRUFDSChwLCAmcGFyZW50LT5wX29ycGhhbnMsIHBfb3JwaGFuKSB7DQ0K KwkJaWYgKHAgPT0gY2hpbGQpIHsNDQorCQkJTElTVF9SRU1PVkUoY2hpbGQsIHBfb3JwaGFuKTsN DQorCQkJYnJlYWs7DQ0KKwkJfQ0NCisJfQ0NCisJaWYgKGNoaWxkLT5wX2ZsYWcgJiBQX1RSQUNF RCkgew0NCisJCUxJU1RfSU5TRVJUX0hFQUQoJmNoaWxkLT5wX3BwdHItPnBfb3JwaGFucywgY2hp bGQsIHBfb3JwaGFuKTsNDQorCQlQUk9DX1VOTE9DSyhjaGlsZCk7DQ0KKwkJUFJPQ19MT0NLKGNo aWxkKTsNDQorCX0NDQogCWNoaWxkLT5wX3BwdHIgPSBwYXJlbnQ7DQ0KIH0NDQpJbmRleDogc3lz L2tlcm4va2Vybl9leGVjLmMNDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQ0KLS0tIHN5cy9rZXJuL2tlcm5fZXhlYy5j CShyZXZpc2lvbiAyMjUxODkpDQ0KKysrIHN5cy9rZXJuL2tlcm5fZXhlYy5jCSh3b3JraW5nIGNv cHkpDQ0KQEAgLTU1LDYgKzU1LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOw0NCiAjaW5jbHVk ZSA8c3lzL3ByaXYuaD4NDQogI2luY2x1ZGUgPHN5cy9wcm9jLmg+DQ0KICNpbmNsdWRlIDxzeXMv cGlvY3RsLmg+DQ0KKyNpbmNsdWRlIDxzeXMvcHRyYWNlLmg+DQ0KICNpbmNsdWRlIDxzeXMvbmFt ZWkuaD4NDQogI2luY2x1ZGUgPHN5cy9yZXNvdXJjZXZhci5oPg0NCiAjaW5jbHVkZSA8c3lzL3Nk dC5oPg0NCkBAIC04OTUsMTYgKzg5NiwyMiBAQCBleGVjX2ZhaWxfZGVhbGxvYzoNDQogCWZyZWUo aW1ncC0+ZnJlZXBhdGgsIE1fVEVNUCk7DQ0KIA0NCiAJaWYgKGVycm9yID09IDApIHsNDQorCQlp ZiAoKHAtPnBfZmxhZyAmIChQX1RSQUNFRCB8IFBfRk9MTE9XRVhFQykpID09IA0NCisJCSAgICAo UF9UUkFDRUQgfAlQX0ZPTExPV0VYRUMpKSB7DQ0KKwkJCVBST0NfTE9DSyhwKTsNDQorCQkJdGQt PnRkX2RiZ2ZsYWdzIHw9IFREQl9FWEVDOw0NCisJCQlQUk9DX1VOTE9DSyhwKTsNDQorCQl9DQ0K KyAJCS8qDQ0KKyAJCSAqIFN0b3AgdGhlIHByb2Nlc3MgaGVyZSBpZiBpdHMgc3RvcCBldmVudCBt YXNrIGhhcw0NCisgCQkgKiB0aGUgU19FWEVDIGJpdCBzZXQuDQ0KKyAJCSAqLw0NCisgCQlTVE9Q RVZFTlQocCwgU19FWEVDLCAwKTsNDQorCQlQVFJBQ0VTVE9QX1NDKHAsIHRkLCBTX1BUX0VYRUMp Ow0NCiAJCVBST0NfTE9DSyhwKTsNDQotCQl0ZC0+dGRfZGJnZmxhZ3MgfD0gVERCX0VYRUM7DQ0K KwkJdGQtPnRkX2RiZ2ZsYWdzICY9IH5UREJfRVhFQzsNDQogCQlQUk9DX1VOTE9DSyhwKTsNDQot DQ0KLQkJLyoNDQotCQkgKiBTdG9wIHRoZSBwcm9jZXNzIGhlcmUgaWYgaXRzIHN0b3AgZXZlbnQg bWFzayBoYXMNDQotCQkgKiB0aGUgU19FWEVDIGJpdCBzZXQuDQ0KLQkJICovDQ0KLQkJU1RPUEVW RU5UKHAsIFNfRVhFQywgMCk7DQ0KLQkJZ290byBkb25lMjsNDQorIAkJZ290byBkb25lMjsNDQog CX0NDQogDQ0KIGV4ZWNfZmFpbDoNDQpJbmRleDogc3lzL2tlcm4va2Vybl9mb3JrLmMNDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQ0KLS0tIHN5cy9rZXJuL2tlcm5fZm9yay5jCShyZXZpc2lvbiAyMjUxODkpDQ0KKysr IHN5cy9rZXJuL2tlcm5fZm9yay5jCSh3b3JraW5nIGNvcHkpDQ0KQEAgLTU5LDYgKzU5LDcgQEAg X19GQlNESUQoIiRGcmVlQlNEJCIpOw0NCiAjaW5jbHVkZSA8c3lzL3Byb2MuaD4NDQogI2luY2x1 ZGUgPHN5cy9wcm9jZGVzYy5oPg0NCiAjaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPg0NCisjaW5jbHVk ZSA8c3lzL3B0cmFjZS5oPg0NCiAjaW5jbHVkZSA8c3lzL3JhY2N0Lmg+DQ0KICNpbmNsdWRlIDxz eXMvcmVzb3VyY2V2YXIuaD4NDQogI2luY2x1ZGUgPHN5cy9zY2hlZC5oPg0NCkBAIC01OTAsNiAr NTkxLDcgQEAgZG9fZm9yayhzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IGZsYWdzLCBzdHJ1Y3QgcHJv Yw0NCiAJTElTVF9JTlNFUlRfQUZURVIocDEsIHAyLCBwX3BnbGlzdCk7DQ0KIAlQR1JQX1VOTE9D SyhwMS0+cF9wZ3JwKTsNDQogCUxJU1RfSU5JVCgmcDItPnBfY2hpbGRyZW4pOw0NCisJTElTVF9J TklUKCZwMi0+cF9vcnBoYW5zKTsNDQogDQ0KIAljYWxsb3V0X2luaXQoJnAyLT5wX2l0Y2FsbG91 dCwgQ0FMTE9VVF9NUFNBRkUpOw0NCiANDQpAQCAtNzAyLDcgKzcwNCw4IEBAIGRvX2Zvcmsoc3Ry dWN0IHRocmVhZCAqdGQsIGludCBmbGFncywgc3RydWN0IHByb2MNDQogCQkgKiBmb3IgcnVuYXdh eSBjaGlsZC4NDQogCQkgKi8NDQogCQl0ZC0+dGRfZGJnZmxhZ3MgfD0gVERCX0ZPUks7DQ0KLQkJ dGQtPnRkX2RiZ19mb3JrZWQgPSBwMi0+cF9waWQ7DQ0KKwkJdGQyLT50ZF9kYmdmbGFncyB8PSBU REJfRk9SSzsNDQorCQl0ZC0+dGRfZGJnX2ZvcmtlZCA9IHRkMi0+dGRfZGJnX2ZvcmtlZCA9IHAy LT5wX3BpZDsNDQogCQl0ZDItPnRkX2RiZ2ZsYWdzIHw9IFREQl9TVE9QQVRGT1JLOw0NCiAJCV9Q SE9MRChwMik7DQ0KIAkJcDJfaGVsZCA9IDE7DQ0KQEAgLTczMSw2ICs3MzQsMTMgQEAgZG9fZm9y ayhzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IGZsYWdzLCBzdHJ1Y3QgcHJvYw0NCiAJa25vdGVfZm9y aygmcDEtPnBfa2xpc3QsIHAyLT5wX3BpZCk7DQ0KIAlTRFRfUFJPQkUocHJvYywga2VybmVsLCAs IGNyZWF0ZSwgcDIsIHAxLCBmbGFncywgMCwgMCk7DQ0KIA0NCisJaWYgKHRkLT50ZF9kYmdmbGFn cyAmIFREQl9GT1JLKSB7DQ0KKwkJUFRSQUNFU1RPUF9TQyhwMSwgdGQsIFNfUFRfRk9SSyk7DQ0K KwkJUFJPQ19MT0NLKHAxKTsNDQorCQl0ZC0+dGRfZGJnZmxhZ3MgJj0gflREQl9GT1JLOw0NCisJ CVBST0NfVU5MT0NLKHAxKTsNDQorCX0NDQorDQ0KIAkvKg0NCiAJICogV2FpdCB1bnRpbCBkZWJ1 Z2dlciBpcyBhdHRhY2hlZCB0byBjaGlsZC4NDQogCSAqLw0NCkBAIC03OTcsNiArODA3LDEwIEBA IGZvcmsxKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgZmxhZ3MsIGludCBwYWdlcywgc3RyDQ0KIA0N CiAJcDEgPSB0ZC0+dGRfcHJvYzsNDQogDQ0KKwkvKiBEb24ndCBkbyB2Zm9yayB3aGlsZSBiZWlu ZyB0cmFjZWQuICovDQ0KKwlpZiAocDEtPnBfZmxhZyAmIFBfVFJBQ0VEKQ0NCisJCWZsYWdzICY9 IH4oUkZQUFdBSVQgfCBSRk1FTSk7DQ0KKw0NCiAJLyoNDQogCSAqIEhlcmUgd2UgZG9uJ3QgY3Jl YXRlIGEgbmV3IHByb2Nlc3MsIGJ1dCB3ZSBkaXZvcmNlDQ0KIAkgKiBjZXJ0YWluIHBhcnRzIG9m IGEgcHJvY2VzcyBmcm9tIGl0c2VsZi4NDQpAQCAtMTA2Niw2ICsxMDgwLDcgQEAgZm9ya19yZXR1 cm4oc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCB0cmFwZnJhbWUgKmYNDQogCQkJcHJvY19yZXBh cmVudChwLCBkYmcpOw0NCiAJCQlzeF94dW5sb2NrKCZwcm9jdHJlZV9sb2NrKTsNDQogCQkJcHRy YWNlc3RvcCh0ZCwgU0lHU1RPUCk7DQ0KKwkJCXRkLT50ZF9kYmdmbGFncyAmPSB+VERCX0ZPUks7 DQ0KIAkJfSBlbHNlIHsNDQogCQkJLyoNDQogCQkJICogLi4uIG90aGVyd2lzZSBjbGVhciB0aGUg cmVxdWVzdC4NDQpJbmRleDogc3lzL2tlcm4vc3lzX3Byb2Nlc3MuYw0NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NDQot LS0gc3lzL2tlcm4vc3lzX3Byb2Nlc3MuYwkocmV2aXNpb24gMjI1MTg5KQ0NCisrKyBzeXMva2Vy bi9zeXNfcHJvY2Vzcy5jCSh3b3JraW5nIGNvcHkpDQ0KQEAgLTY2MCw2ICs2NjAsNyBAQCBrZXJu X3B0cmFjZShzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHJlcSwgcGlkX3QgcGlkLA0NCiAJY2FzZSBQ VF9UT19TQ1g6DQ0KIAljYXNlIFBUX1NZU0NBTEw6DQ0KIAljYXNlIFBUX0ZPTExPV19GT1JLOg0N CisJY2FzZSBQVF9GT0xMT1dfRVhFQzoNDQogCWNhc2UgUFRfREVUQUNIOg0NCiAJCXN4X3hsb2Nr KCZwcm9jdHJlZV9sb2NrKTsNDQogCQlwcm9jdHJlZV9sb2NrZWQgPSAxOw0NCkBAIC04NDEsOCAr ODQyLDYgQEAga2Vybl9wdHJhY2Uoc3RydWN0IHRocmVhZCAqdGQsIGludCByZXEsIHBpZF90IHBp ZCwNDQogCQlwLT5wX2ZsYWcgfD0gUF9UUkFDRUQ7DQ0KIAkJcC0+cF9vcHBpZCA9IHAtPnBfcHB0 ci0+cF9waWQ7DQ0KIAkJaWYgKHAtPnBfcHB0ciAhPSB0ZC0+dGRfcHJvYykgew0NCi0JCQkvKiBS ZW1lbWJlciB0aGF0IGEgY2hpbGQgaXMgYmVpbmcgZGVidWdnZWQodHJhY2VkKS4gKi8NDQotCQkJ cC0+cF9wcHRyLT5wX2RiZ19jaGlsZCsrOw0NCiAJCQlwcm9jX3JlcGFyZW50KHAsIHRkLT50ZF9w cm9jKTsNDQogCQl9DQ0KIAkJZGF0YSA9IFNJR1NUT1A7DQ0KQEAgLTg2OCwxMiArODY3LDI4IEBA IGtlcm5fcHRyYWNlKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgcmVxLCBwaWRfdCBwaWQsDQ0KIAkJ YnJlYWs7DQ0KIA0NCiAJY2FzZSBQVF9GT0xMT1dfRk9SSzoNDQotCQlpZiAoZGF0YSkNDQorCQlp ZiAoZGF0YSkgew0NCiAJCQlwLT5wX2ZsYWcgfD0gUF9GT0xMT1dGT1JLOw0NCi0JCWVsc2UNDQor CQkJcC0+cF9zdG9wcyB8PSBTX1BUX0ZPUks7DQ0KKwkJfQ0NCisJCWVsc2Ugew0NCiAJCQlwLT5w X2ZsYWcgJj0gflBfRk9MTE9XRk9SSzsNDQorCQkJcC0+cF9zdG9wcyAmPSB+U19QVF9GT1JLOw0N CisJCX0NDQogCQlicmVhazsNDQogDQ0KKwljYXNlIFBUX0ZPTExPV19FWEVDOg0NCisJCWlmIChk YXRhKSB7DQ0KKwkJCXAtPnBfZmxhZyB8PSBQX0ZPTExPV0VYRUM7DQ0KKwkJCXAtPnBfc3RvcHMg fD0gU19QVF9FWEVDOw0NCisJCX0NDQorCQllbHNlIHsNDQorCQkJcC0+cF9mbGFnICY9IH5QX0ZP TExPV0VYRUM7DQ0KKwkJCXAtPnBfc3RvcHMgJj0gflNfUFRfRVhFQzsNDQorCQl9DQ0KKwkJYnJl YWs7DQ0KKw0NCisNDQogCWNhc2UgUFRfU1RFUDoNDQogCWNhc2UgUFRfQ09OVElOVUU6DQ0KIAlj YXNlIFBUX1RPX1NDRToNDQpAQCAtOTMxLDEyICs5NDYsMTIgQEAga2Vybl9wdHJhY2Uoc3RydWN0 IHRocmVhZCAqdGQsIGludCByZXEsIHBpZF90IHBpZCwNDQogCQkJCQlQUk9DX1VOTE9DSyhwcCk7 DQ0KIAkJCQlQUk9DX0xPQ0socCk7DQ0KIAkJCQlwcm9jX3JlcGFyZW50KHAsIHBwKTsNDQotCQkJ CXAtPnBfcHB0ci0+cF9kYmdfY2hpbGQtLTsNDQogCQkJCWlmIChwcCA9PSBpbml0cHJvYykNDQog CQkJCQlwLT5wX3NpZ3BhcmVudCA9IFNJR0NITEQ7DQ0KIAkJCX0NDQogCQkJcC0+cF9vcHBpZCA9 IDA7DQ0KLQkJCXAtPnBfZmxhZyAmPSB+KFBfVFJBQ0VEIHwgUF9XQUlURUQgfCBQX0ZPTExPV0ZP UkspOw0NCisJCQlwLT5wX2ZsYWcgJj0gfihQX1RSQUNFRCB8IFBfV0FJVEVEIHwgUF9GT0xMT1dG T1JLIHwgDQ0KKwkJCQkgICAgICAgUF9GT0xMT1dFWEVDKTsNDQogDQ0KIAkJCS8qIHNob3VsZCB3 ZSBzZW5kIFNJR0NITEQ/ICovDQ0KIAkJCS8qIGNoaWxkcHJvY19jb250aW51ZWQocCk7ICovDQ0K SW5kZXg6IHN5cy9rZXJuL3N5c19wcm9jZGVzYy5jDQ0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0NCi0tLSBzeXMva2Vy bi9zeXNfcHJvY2Rlc2MuYwkocmV2aXNpb24gMjI1MTg5KQ0NCisrKyBzeXMva2Vybi9zeXNfcHJv Y2Rlc2MuYwkod29ya2luZyBjb3B5KQ0NCkBAIC0zNjcsNyArMzY3LDcgQEAgcHJvY2Rlc2NfY2xv c2Uoc3RydWN0IGZpbGUgKmZwLCBzdHJ1Y3QgdGhyZWFkICp0ZCkNDQogCQkgKiBwcm9jZGVzY19y ZWFwKCkuDQ0KIAkJICovDQ0KIAkJUFJPQ19TTE9DSyhwKTsNDQotCQlwcm9jX3JlYXAoY3VydGhy ZWFkLCBwLCBOVUxMLCAwLCBOVUxMKTsNDQorCQlwcm9jX3JlYXAoY3VydGhyZWFkLCBwLCBOVUxM LCAwLCBOVUxMLCAwKTsNDQogCX0gZWxzZSB7DQ0KIAkJLyoNDQogCQkgKiBJZiB0aGUgcHJvY2Vz cyBpcyBub3QgeWV0IGRlYWQsIHdlIG5lZWQgdG8ga2lsbCBpdCwgYnV0IHdlDQ0KSW5kZXg6IHN5 cy9zeXMvcHJvYy5oDQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0NCi0tLSBzeXMvc3lzL3Byb2MuaAkocmV2aXNpb24g MjI1MTg5KQ0NCisrKyBzeXMvc3lzL3Byb2MuaAkod29ya2luZyBjb3B5KQ0NCkBAIC01MDQsOCAr NTA0LDYgQEAgc3RydWN0IHByb2Mgew0NCiAvKiBUaGUgZm9sbG93aW5nIGZpZWxkcyBhcmUgYWxs IHplcm9lZCB1cG9uIGNyZWF0aW9uIGluIGZvcmsuICovDQ0KICNkZWZpbmUJcF9zdGFydHplcm8J cF9vcHBpZA0NCiAJcGlkX3QJCXBfb3BwaWQ7CS8qIChjICsgZSkgU2F2ZSBwcGlkIGluIHB0cmFj ZS4gWFhYICovDQ0KLQlpbnQJCXBfZGJnX2NoaWxkOwkvKiAoYyArIGUpICMgb2YgZGVidWdnZWQg Y2hpbGRyZW4gaW4NDQotCQkJCQkJCXB0cmFjZS4gKi8NDQogCXN0cnVjdCB2bXNwYWNlCSpwX3Zt c3BhY2U7CS8qIChiKSBBZGRyZXNzIHNwYWNlLiAqLw0NCiAJdV9pbnQJCXBfc3d0aWNrOwkvKiAo YykgVGljayB3aGVuIHN3YXBwZWQgaW4gb3Igb3V0LiAqLw0NCiAJc3RydWN0IGl0aW1lcnZhbCBw X3JlYWx0aW1lcjsJLyogKGMpIEFsYXJtIHRpbWVyLiAqLw0NCkBAIC01NzMsNiArNTcxLDggQEAg c3RydWN0IHByb2Mgew0NCiAJCQkJCSAgIGFmdGVyIGZvcmsuICovDQ0KIAl1aW50NjRfdAlwX3By ZXZfcnVudGltZTsJLyogKGMpIFJlc291cmNlIHVzYWdlIGFjY291bnRpbmcuICovDQ0KIAlzdHJ1 Y3QgcmFjY3QJKnBfcmFjY3Q7CS8qIChiKSBSZXNvdXJjZSBhY2NvdW50aW5nLiAqLw0NCisJTElT VF9FTlRSWShwcm9jKSBwX29ycGhhbjsJLyogKGUpIExpc3Qgb2Ygb3JwaGFuIHByb2Nlc3Nlcy4g Ki8NDQorCUxJU1RfSEVBRCgsIHByb2MpIHBfb3JwaGFuczsJLyogKGUpIFBvaW50ZXIgdG8gbGlz dCBvZiBvcnBoYW5zLiAqLw0NCiB9Ow0NCiANDQogI2RlZmluZQlwX3Nlc3Npb24JcF9wZ3JwLT5w Z19zZXNzaW9uDQ0KQEAgLTYxNiw2ICs2MTYsNyBAQCBzdHJ1Y3QgcHJvYyB7DQ0KICNkZWZpbmUJ UF9JTk1FTQkJMHgxMDAwMDAwMCAvKiBMb2FkZWQgaW50byBtZW1vcnkuICovDQ0KICNkZWZpbmUJ UF9TV0FQUElOR09VVAkweDIwMDAwMDAwIC8qIFByb2Nlc3MgaXMgYmVpbmcgc3dhcHBlZCBvdXQu ICovDQ0KICNkZWZpbmUJUF9TV0FQUElOR0lOCTB4NDAwMDAwMDAgLyogUHJvY2VzcyBpcyBiZWlu ZyBzd2FwcGVkIGluLiAqLw0NCisjZGVmaW5lCVBfRk9MTE9XRVhFQwkweDgwMDAwMDAwIC8qIE5v dGlmeSBkZWJ1Z2dlciBvZiBleGVjIGV2ZW50cy4gKi8NDQogDQ0KICNkZWZpbmUJUF9TVE9QUEVE CShQX1NUT1BQRURfU0lHfFBfU1RPUFBFRF9TSU5HTEV8UF9TVE9QUEVEX1RSQUNFKQ0NCiAjZGVm aW5lCVBfU0hPVUxEU1RPUChwKQkoKHApLT5wX2ZsYWcgJiBQX1NUT1BQRUQpDQ0KQEAgLTg0Nyw3 ICs4NDgsNyBAQCB2b2lkCXByb2Npbml0KHZvaWQpOw0NCiB2b2lkCXByb2NfbGlua3VwMChzdHJ1 Y3QgcHJvYyAqcCwgc3RydWN0IHRocmVhZCAqdGQpOw0NCiB2b2lkCXByb2NfbGlua3VwKHN0cnVj dCBwcm9jICpwLCBzdHJ1Y3QgdGhyZWFkICp0ZCk7DQ0KIHZvaWQJcHJvY19yZWFwKHN0cnVjdCB0 aHJlYWQgKnRkLCBzdHJ1Y3QgcHJvYyAqcCwgaW50ICpzdGF0dXMsIGludCBvcHRpb25zLA0NCi0J ICAgIHN0cnVjdCBydXNhZ2UgKnJ1c2FnZSk7DQ0KKwkgICAgc3RydWN0IHJ1c2FnZSAqcnVzYWdl LCBpbnQgY2hpbGQpOw0NCiB2b2lkCXByb2NfcmVwYXJlbnQoc3RydWN0IHByb2MgKmNoaWxkLCBz dHJ1Y3QgcHJvYyAqbmV3cGFyZW50KTsNDQogc3RydWN0CXBzdGF0cyAqcHN0YXRzX2FsbG9jKHZv aWQpOw0NCiB2b2lkCXBzdGF0c19mb3JrKHN0cnVjdCBwc3RhdHMgKnNyYywgc3RydWN0IHBzdGF0 cyAqZHN0KTsNDQpJbmRleDogc3lzL3N5cy9wdHJhY2UuaA0NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NDQotLS0gc3lz L3N5cy9wdHJhY2UuaAkocmV2aXNpb24gMjI1MTg5KQ0NCisrKyBzeXMvc3lzL3B0cmFjZS5oCSh3 b3JraW5nIGNvcHkpDQ0KQEAgLTY0LDYgKzY0LDcgQEANDQogI2RlZmluZQlQVF9TWVNDQUxMCTIy DQ0KIA0NCiAjZGVmaW5lCVBUX0ZPTExPV19GT1JLCTIzDQ0KKyNkZWZpbmUJUFRfRk9MTE9XX0VY RUMgIDI0DQ0KIA0NCiAjZGVmaW5lIFBUX0dFVFJFR1MgICAgICAzMwkvKiBnZXQgZ2VuZXJhbC1w dXJwb3NlIHJlZ2lzdGVycyAqLw0NCiAjZGVmaW5lIFBUX1NFVFJFR1MgICAgICAzNAkvKiBzZXQg Z2VuZXJhbC1wdXJwb3NlIHJlZ2lzdGVycyAqLw0NCkBAIC0xMDYsNyArMTA3LDcgQEAgc3RydWN0 IHB0cmFjZV9sd3BpbmZvIHsNDQogI2RlZmluZQlQTF9GTEFHX1NDWAkweDA4CS8qIHN5c2NhbGwg bGVhdmUgcG9pbnQgKi8NDQogI2RlZmluZQlQTF9GTEFHX0VYRUMJMHgxMAkvKiBleGVjKDIpIHN1 Y2NlZWRlZCAqLw0NCiAjZGVmaW5lCVBMX0ZMQUdfU0kJMHgyMAkvKiBzaWdpbmZvIGlzIHZhbGlk ICovDQ0KLSNkZWZpbmUJUExfRkxBR19GT1JLRUQJMHg0MAkvKiBuZXcgY2hpbGQgKi8NDQorI2Rl ZmluZQlQTF9GTEFHX0ZPUktFRAkweDQwCS8qIG5ldyBjaGlsZCBmcm9tIGZvcmsoKSAqLw0NCiAJ c2lnc2V0X3QJcGxfc2lnbWFzazsJLyogTFdQIHNpZ25hbCBtYXNrICovDQ0KIAlzaWdzZXRfdAlw bF9zaWdsaXN0OwkvKiBMV1AgcGVuZGluZyBzaWduYWwgKi8NDQogCXN0cnVjdCBfX3NpZ2luZm8g cGxfc2lnaW5mbzsJLyogc2lnaW5mbyBmb3Igc2lnbmFsICovDQ0KQEAgLTE0Miw2ICsxNDMsOCBA QCBzdHJ1Y3QgcHRyYWNlX3ZtX2VudHJ5IHsNDQogICovDQ0KICNkZWZpbmUJU19QVF9TQ0UJMHgw MDAwMTAwMDANDQogI2RlZmluZQlTX1BUX1NDWAkweDAwMDAyMDAwMA0NCisjZGVmaW5lCVNfUFRf Rk9SSwkweDAwMDA0MDAwMA0NCisjZGVmaW5lCVNfUFRfRVhFQwkweDAwMDA4MDAwMA0NCiANDQog aW50CXB0cmFjZV9zZXRfcGMoc3RydWN0IHRocmVhZCAqX3RkLCB1bnNpZ25lZCBsb25nIF9hZGRy KTsNDQogaW50CXB0cmFjZV9zaW5nbGVfc3RlcChzdHJ1Y3QgdGhyZWFkICpfdGQpOw0NCg== --_002_749E238AA85F42649DEBBCE1BBD21C9Djunipernet_-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 22:33:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C64106566C; Tue, 24 Jan 2012 22:33:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5E98FC08; Tue, 24 Jan 2012 22:33:51 +0000 (UTC) Received: by eaai10 with SMTP id i10so1932639eaa.13 for ; Tue, 24 Jan 2012 14:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=no2lUFbPzOMNwwd0DDNuhNb4nFa0FhpCT06LkyLTQlQ=; b=EqE5hiygcxTkEsxVmLqiugiOQM3Kc/iSji6MklddaKpyoa0XjLqvI+BHp0YNR2rAed LdtszkE/aE4JL97f6NeTg4UrvpXAoATCkekt7yv/bktImkFc3U/RGS4dxyq6Hh66OIL9 9lNFnSOqAWLOOlxAJxJbOexgNp135HWC5pARs= Received: by 10.213.15.20 with SMTP id i20mr2169485eba.6.1327444430954; Tue, 24 Jan 2012 14:33:50 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id y12sm73254964eeb.11.2012.01.24.14.33.47 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 14:33:48 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1F31CA.5000507@FreeBSD.org> Date: Wed, 25 Jan 2012 00:33:46 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:33:52 -0000 On 01/25/12 00:13, Mickaël Maillot wrote: > 2012/1/24 Alexander Motin > > Here is it: http://people.freebsd.org/~__mav/hda.HBR.patch > > It should activate HBR mode if you try to play stream with AC3 > format and 8 channels (>6Mbps). > > no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3, > SNDCTL_DSP_CHANNELS always return 2 channels even if i > set SNDCTL_DSP_SPEED to 192000. > and i think it's why "if ((ch->fmt & AFMT_AC3) && (cchn == 8))" can't be > true. > i checked my /v/l/messages and saw PCMDIR_PLAY ....chan_count=0x01. Number of channels should be set to 8 by application when it expects bit rate above 6Mbps. Sample rate, as I've described, just give more fine control. Increasing sample rate does not automatically increase channels. They are orthogonal: Rate 48 96 192 48 96 192 Channels 2 2 2 8 8 8 ---------------------------------------------------------- Mbps 1.5 3 6 12 24 49 What I've forgot is to allow 8ch format. :) Add the patch below. Hope sound(4) has no other limitations for it. --- hdaa.c (revision 230511) +++ hdaa.c (working copy) @@ -4979,6 +4979,8 @@ } if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(fmtcap)) { ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0); + if (channels >= 8) + ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0); } ch->fmtlist[i] = 0; i = 0; But in your case I think it should be enough to just increase sample rate to 96 or 192KHz. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 22:46:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C57106564A; Tue, 24 Jan 2012 22:46:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9175C8FC13; Tue, 24 Jan 2012 22:46:55 +0000 (UTC) Received: by eekb47 with SMTP id b47so1917562eek.13 for ; Tue, 24 Jan 2012 14:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ePDA7XU/bZX1iHWW/72HSWNPh6tw68GqCL+k1gpkmh8=; b=SCiCA/qGKOahIkCu4tJ7zxvXvr5tlgS3vxvPRdukTDGY8tPuD7/KI4PxybYJVCKFJv jnSRxF1Zc00bpKg6Lz/6xU2lY35nJ0VT35LSEVaTEOSH89dcyP88R4aUVBy24tV2nnFC wS1nmsa0BBM4SO9fIDUSIpqyZmzjHziKONVpw= Received: by 10.14.14.165 with SMTP id d37mr5266164eed.91.1327445214476; Tue, 24 Jan 2012 14:46:54 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id r2sm73415610eef.7.2012.01.24.14.46.52 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 14:46:53 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1F34DB.9040405@FreeBSD.org> Date: Wed, 25 Jan 2012 00:46:51 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> In-Reply-To: <4F1F31CA.5000507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:46:56 -0000 On 01/25/12 00:33, Alexander Motin wrote: > On 01/25/12 00:13, Mickaël Maillot wrote: >> 2012/1/24 Alexander Motin > >> Here is it: http://people.freebsd.org/~__mav/hda.HBR.patch >> >> It should activate HBR mode if you try to play stream with AC3 >> format and 8 channels (>6Mbps). >> >> no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3, >> SNDCTL_DSP_CHANNELS always return 2 channels even if i >> set SNDCTL_DSP_SPEED to 192000. >> and i think it's why "if ((ch->fmt & AFMT_AC3) && (cchn == 8))" can't be >> true. >> i checked my /v/l/messages and saw PCMDIR_PLAY ....chan_count=0x01. > > Number of channels should be set to 8 by application when it expects bit > rate above 6Mbps. Sample rate, as I've described, just give more fine > control. Increasing sample rate does not automatically increase > channels. They are orthogonal: > Rate 48 96 192 48 96 192 > Channels 2 2 2 8 8 8 > ---------------------------------------------------------- > Mbps 1.5 3 6 12 24 49 > > What I've forgot is to allow 8ch format. :) Add the patch below. Hope > sound(4) has no other limitations for it. Hmm. Looks like there is some limitation. You may grep kernel for AFMT_PASSTHROUGH and find two "XXX force ..." comments and code, including forcing 2 channels for AC3. Luckily for not part for frequency is commented out. Further we may try to comment or modify part about number of channels. > --- hdaa.c (revision 230511) > +++ hdaa.c (working copy) > @@ -4979,6 +4979,8 @@ > } > if (HDA_PARAM_SUPP_STREAM_FORMATS_AC3(fmtcap)) { > ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0); > + if (channels >= 8) > + ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0); > } > ch->fmtlist[i] = 0; > i = 0; > > But in your case I think it should be enough to just increase sample > rate to 96 or 192KHz. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 23:32:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2E7E106564A; Tue, 24 Jan 2012 23:32:47 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBEA8FC0A; Tue, 24 Jan 2012 23:32:46 +0000 (UTC) Received: by qaea17 with SMTP id a17so3016589qae.13 for ; Tue, 24 Jan 2012 15:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lnSQzcDliAr9bE6bRCN45Z3gXsBGzCKwL2XPaUSSC6Q=; b=UNw31NE5aOFk2/1cyOJLSfehiBl1kdomHjUbi3PZkqAWTQxsYJ93U9xWDufA6tmq0I BB7E5xf/NHkvnrugvqQoMSSLlPjNXsITzregk+DTOHzRHJvSd40AZYHHn66HMwtW8wRe x/52CJknjNk/5WwTiFHSAxdlFCHovtFTZuQd8= MIME-Version: 1.0 Received: by 10.224.188.209 with SMTP id db17mr12223540qab.60.1327447966390; Tue, 24 Jan 2012 15:32:46 -0800 (PST) Received: by 10.229.124.11 with HTTP; Tue, 24 Jan 2012 15:32:46 -0800 (PST) In-Reply-To: <4F1F34DB.9040405@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> Date: Wed, 25 Jan 2012 00:32:46 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:32:47 -0000 2012/1/24 Alexander Motin > On 01/25/12 00:33, Alexander Motin wrote: > >> On 01/25/12 00:13, Micka=EBl Maillot wrote: >> >>> 2012/1/24 Alexander Motin > >>> Here is it: http://people.freebsd.org/~__**mav/hda.HBR.patch >>> >>> > >>> It should activate HBR mode if you try to play stream with AC3 >>> format and 8 channels (>6Mbps). >>> >>> no change with the patch because when i SNDCTL_DSP_SETFMT to AFMT_AC3, >>> SNDCTL_DSP_CHANNELS always return 2 channels even if i >>> set SNDCTL_DSP_SPEED to 192000. >>> and i think it's why "if ((ch->fmt & AFMT_AC3) && (cchn =3D=3D 8))" can= 't be >>> true. >>> i checked my /v/l/messages and saw PCMDIR_PLAY ....chan_count=3D0x01. >>> >> >> Number of channels should be set to 8 by application when it expects bit >> rate above 6Mbps. Sample rate, as I've described, just give more fine >> control. Increasing sample rate does not automatically increase >> channels. They are orthogonal: >> Rate 48 96 192 48 96 192 >> Channels 2 2 2 8 8 8 >> ------------------------------**---------------------------- >> Mbps 1.5 3 6 12 24 49 >> >> ok so set 8 channels is just to allow more bandwidth. i just looked at alsa hdmi code (because i never find oss code that can play hd audio), they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so i was thinking to do the same. > What I've forgot is to allow 8ch format. :) Add the patch below. Hope >> sound(4) has no other limitations for it. >> > > Hmm. Looks like there is some limitation. You may grep kernel for > AFMT_PASSTHROUGH and find two "XXX force ..." comments and code, includin= g > forcing 2 channels for AC3. Luckily for not part for frequency is comment= ed > out. Further we may try to comment or modify part about number of channel= s. > > spotted and commented > > --- hdaa.c (revision 230511) >> +++ hdaa.c (working copy) >> @@ -4979,6 +4979,8 @@ >> } >> if (HDA_PARAM_SUPP_STREAM_**FORMATS_AC3(fmtcap)) { >> ch->fmtlist[i++] =3D SND_FORMAT(AFMT_AC3, 2, 0); >> + if (channels >=3D 8) >> + ch->fmtlist[i++] =3D SND_FORMAT(AFMT_AC3, 8, 0); >> } >> ch->fmtlist[i] =3D 0; >> i =3D 0; >> >> But in your case I think it should be enough to just increase sample >> rate to 96 or 192KHz. >> > > so if my problem persist after settings 8 channels, i'll blame xbmc oss part. From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 23:39:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 885231065700; Tue, 24 Jan 2012 23:39:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D3EB68FC0C; Tue, 24 Jan 2012 23:39:40 +0000 (UTC) Received: by eekb47 with SMTP id b47so1928545eek.13 for ; Tue, 24 Jan 2012 15:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=edaWTatxkPd8ym0AdHazZfhKcAhW7i5w7bG14Ow4jZk=; b=VbWRvk1dTbs4/I2eO+eazhMZM6qirTqDIhv535uS8DxoFkjYUWLMTSY/j/jqcvdUjO 51xgKTN0NJPFypsg94W2Eu9odIrpn6gbjfkUksFMVKu7gg9P0EnYTPj5Blw0RJ+f7HoH uCZ/tQ3oFu/q5xlJ+8CXirhHVABH50L/4N6Ak= Received: by 10.14.95.9 with SMTP id o9mr5297780eef.125.1327448379624; Tue, 24 Jan 2012 15:39:39 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id e12sm73932370eea.5.2012.01.24.15.39.36 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 15:39:38 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1F412D.5040009@FreeBSD.org> Date: Wed, 25 Jan 2012 01:39:25 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlja2HDq2wgTWFpbGxvdA==?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:39:41 -0000 On 25.01.2012 01:32, Mickaël Maillot wrote: > 2012/1/24 Alexander Motin > > Number of channels should be set to 8 by application when it > expects bit > rate above 6Mbps. Sample rate, as I've described, just give more > fine > control. Increasing sample rate does not automatically increase > channels. They are orthogonal: > Rate 48 96 192 48 96 192 > Channels 2 2 2 8 8 8 > ------------------------------__---------------------------- > Mbps 1.5 3 6 12 24 49 > > > ok so set 8 channels is just to allow more bandwidth. > i just looked at alsa hdmi code (because i never find oss code that can > play hd audio), > they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so > i was thinking to do the same. HBR mode (8 channels) is not always supported by hardware and not defined by HDMI 1.1 spec (not sure about 1.2). So I think if possible, it would be nice to differentiate them. > What I've forgot is to allow 8ch format. :) Add the patch below. > Hope > sound(4) has no other limitations for it. > > Hmm. Looks like there is some limitation. You may grep kernel for > AFMT_PASSTHROUGH and find two "XXX force ..." comments and code, > including forcing 2 channels for AC3. Luckily for not part for > frequency is commented out. Further we may try to comment or modify > part about number of channels. > > spotted and commented > > --- hdaa.c (revision 230511) > +++ hdaa.c (working copy) > @@ -4979,6 +4979,8 @@ > } > if (HDA_PARAM_SUPP_STREAM___FORMATS_AC3(fmtcap)) { > ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 2, 0); > + if (channels >= 8) > + ch->fmtlist[i++] = SND_FORMAT(AFMT_AC3, 8, 0); > } > ch->fmtlist[i] = 0; > i = 0; > > But in your case I think it should be enough to just increase sample > rate to 96 or 192KHz. > > so if my problem persist after settings 8 channels, i'll blame xbmc oss > part. Can't wait to know result. :) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 00:32:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732A1106566B for ; Wed, 25 Jan 2012 00:32:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 30ABA8FC13 for ; Wed, 25 Jan 2012 00:32:02 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPRLH0+DaFvO/2dsb2JhbABChQmqM4IcgQsCDRkCoWCOC5E2gS+CT4UMAQYGCQUBAQIBCQIYCgIDgkgGAgUBBQoBAwkKAQYCAl0zggaBFgSIP4xekmw X-IronPort-AV: E=Sophos;i="4.71,565,1320642000"; d="scan'208";a="156644400" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 24 Jan 2012 19:32:02 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 206FAB3F08 for ; Tue, 24 Jan 2012 19:32:02 -0500 (EST) Date: Tue, 24 Jan 2012 19:32:02 -0500 (EST) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <666472979.73336.1327451522107.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: Heads Up: NFS clients can now fail "mount -u -o udp..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:32:03 -0000 Hi, r230516, which was just committed to head/current, will result in a "mount -u -o udp /path" failing if the mount is using an rsize/wsize/readdirsize of greater than 16384 (which will be the case of a default sized TCP mount). As such, specifying "udp" or "mntudp" options in the /etc/fstab entry for "/" on a diskless NFS client could result in the "mount -u" failing. I'd suggest that "udp" and "mntudp" be avoided for this case, if you are using the default of TCP for the root mnt done when the diskless client is booted. The discussion on freebsd-fs@ seemed to indicate returning an error was preferable to silently ignoring the "udp/mntudp" option for this case. Hopefully this won't cause many people grief, rick ps: Since doing the above could cause errors with both the NFS clients for the root, I suspect few do the above. From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 04:47:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993E7106566C; Wed, 25 Jan 2012 04:47:52 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E98468FC08; Wed, 25 Jan 2012 04:47:51 +0000 (UTC) Received: by eekb47 with SMTP id b47so1991414eek.13 for ; Tue, 24 Jan 2012 20:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PbeBLgsPMdBC4UTeMSYpwz2z4LA+/2gnwXNrFxcRo0g=; b=g3ztLb4A15VS15J+gIg/CHWm1giHZXS12Wx4dIRlJhKl3ZFDWxPH5ffe984GettISs icN0vOiJS5gyMRfTuIMiPt+Lhdu5pQ0HFf9xYKL3xTIK0uZUSf+SLOzSsr+ddZkTptaI hssobByU3j28hq0IYzNdEogNQBb5mt2SM4bWU= MIME-Version: 1.0 Received: by 10.14.2.66 with SMTP id 42mr5464906eee.44.1327465344243; Tue, 24 Jan 2012 20:22:24 -0800 (PST) Received: by 10.14.12.70 with HTTP; Tue, 24 Jan 2012 20:22:24 -0800 (PST) In-Reply-To: <4F1F412D.5040009@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> Date: Tue, 24 Jan 2012 22:22:24 -0600 Message-ID: From: Zhihao Yuan To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Jan 2012 05:14:02 +0000 Cc: =?UTF-8?Q?Micka=C3=ABl_Maillot?= , freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 04:47:52 -0000 On Tue, Jan 24, 2012 at 5:39 PM, Alexander Motin wrote: > On 25.01.2012 01:32, Micka=C3=ABl Maillot wrote: >> >> 2012/1/24 Alexander Motin > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Number of channels should be set to 8 by appl= ication when it >> =C2=A0 =C2=A0 =C2=A0 =C2=A0expects bit >> =C2=A0 =C2=A0 =C2=A0 =C2=A0rate above 6Mbps. Sample rate, as I've descri= bed, just give more >> =C2=A0 =C2=A0 =C2=A0 =C2=A0fine >> =C2=A0 =C2=A0 =C2=A0 =C2=A0control. Increasing sample rate does not auto= matically increase >> =C2=A0 =C2=A0 =C2=A0 =C2=A0channels. They are orthogonal: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Rate 48 96 192 48 96 192 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channels 2 2 2 8 8 8 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------__-------------= --------------- >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Mbps 1.5 3 6 12 24 49 >> >> >> ok so set 8 channels is just to allow more bandwidth. >> i just looked at alsa hdmi code (because i never find oss code that can >> play hd audio), >> they set 192k and 8 channels for every DTS HD / TRUEHD / E-AC3 file, so >> i was thinking to do the same. > > > HBR mode (8 channels) is not always supported by hardware and not defined= by > HDMI 1.1 spec (not sure about 1.2). So I think if possible, it would be n= ice > to differentiate them. > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0What I've forgot is to allow 8ch format. :) A= dd the patch below. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Hope >> =C2=A0 =C2=A0 =C2=A0 =C2=A0sound(4) has no other limitations for it. >> >> =C2=A0 =C2=A0Hmm. Looks like there is some limitation. You may grep kern= el for >> =C2=A0 =C2=A0AFMT_PASSTHROUGH and find two "XXX force ..." comments and = code, >> =C2=A0 =C2=A0including forcing 2 channels for AC3. Luckily for not part = for >> =C2=A0 =C2=A0frequency is commented out. Further we may try to comment o= r modify >> =C2=A0 =C2=A0part about number of channels. >> >> spotted and commented >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0--- hdaa.c (revision 230511) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+++ hdaa.c (working copy) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0@@ -4979,6 +4979,8 @@ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (HDA_PARAM_SUPP_STREAM___FORMATS_AC3(fmtca= p)) { >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ch->fmtlist[i++] =3D SND_FORMAT(AFMT_AC3, 2, = 0); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+ if (channels >=3D 8) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+ ch->fmtlist[i++] =3D SND_FORMAT(AFMT_AC3, 8= , 0); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ch->fmtlist[i] =3D 0; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0i =3D 0; >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0But in your case I think it should be enough = to just increase >> sample >> =C2=A0 =C2=A0 =C2=A0 =C2=A0rate to 96 or 192KHz. >> >> so if my problem persist after settings 8 channels, i'll blame xbmc oss >> part. > > > Can't wait to know result. :) > > -- > Alexander Motin > > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to > "freebsd-multimedia-unsubscribe@freebsd.org" Oops, device_delete_children is not available on 8_RELENG. --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 07:42:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C67106564A; Wed, 25 Jan 2012 07:42:20 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 636C28FC15; Wed, 25 Jan 2012 07:42:20 +0000 (UTC) Received: by qaea17 with SMTP id a17so3208495qae.13 for ; Tue, 24 Jan 2012 23:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WH9vkFAPIHXzMh0EBc6+FEoRsLIcEEkOMeqdPrTNmAk=; b=tBdLcLE6H7Gxa0LnVIzIC+eg9fxMANXphKMn0GImrKBH1AlHMM5iCdJfd7txaHPi4X qGiSCLJ7tKVbTXCLnwzUQdEQYLfPLTL7/OolDaUsDUhlTARXpcW2ceiRW+hG5V3bG5yW W5G72nsTJURnLr4Pe9kPRFmV9CP6pyDVzvETs= MIME-Version: 1.0 Received: by 10.224.187.14 with SMTP id cu14mr17395281qab.99.1327477339733; Tue, 24 Jan 2012 23:42:19 -0800 (PST) Received: by 10.229.124.11 with HTTP; Tue, 24 Jan 2012 23:42:19 -0800 (PST) In-Reply-To: <4F1F412D.5040009@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> Date: Wed, 25 Jan 2012 08:42:19 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 07:42:20 -0000 2012/1/25 Alexander Motin > > What I've forgot is to allow 8ch format. :) Add the patch below. >> Hope >> sound(4) has no other limitations for it. >> >> Hmm. Looks like there is some limitation. You may grep kernel for >> AFMT_PASSTHROUGH and find two "XXX force ..." comments and code, >> including forcing 2 channels for AC3. Luckily for not part for >> frequency is commented out. Further we may try to comment or modify >> part about number of channels. >> >> spotted and commented >> >> so if my problem persist after settings 8 channels, i'll blame xbmc oss >> part. >> > > Can't wait to know result. :) > > -- > Alexander Motin > ok so unfortunately it's does not work :( first: with vchan disable, i cant set format to AFMT_AC3, ioctl always return -1 in /v/l/messages: Jan 25 08:09:18 htpc kernel: pcm4: chn_setformat(): Format change 0x00100400 failed, falling back to 0x00100008 so may be my change in sys/dev/sound/pcm/channel.c is not good ? i just commented: /* XXX force stereo */ if (format & AFMT_PASSTHROUGH) format = SND_FORMAT(format, AFMT_PASSTHROUGH_CHANNEL, AFMT_PASSTHROUGH_EXTCHANNEL); next with vchan: i can set ac3 to 2 channels and 8 channels. when i try to play DTS HDMA or TRUEHD, i set ac3, 8 channels, 192k and no sound ! before i had: dtshdma: some part of sound (like all data cant be send) and truehd: some crapy bipbip now everything seems to be ok for the player, procstat -f write counter grows up, but no sound from my receiver: no channel input, nothing showed, like nothing is send to him. no error in xbmc.log or in messages: Jan 25 08:15:35 htpc kernel: pcm4: chn_start(): VCHAN PARENT starting! (PCMDIR_PLAY/running) (ready=8192 force=1 i=1 j=0 intrtimeout=2 latency=2ms) Jan 25 08:15:35 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02800400 (7.1) speed=192000 Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:play:dsp4.p0: calling go=0x00000001 , prev=0xffffffff Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:virtual:dsp4.vp0: calling go=0x00000001 , prev=0xffffffff From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 07:48:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DB36106566C for ; Wed, 25 Jan 2012 07:48:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 956CE8FC13 for ; Wed, 25 Jan 2012 07:48:31 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0P7mOVB006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 09:48:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0P7mO8l009272; Wed, 25 Jan 2012 09:48:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0P7mO16009271; Wed, 25 Jan 2012 09:48:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 09:48:24 +0200 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20120125074824.GD2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline In-Reply-To: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Dmitry Mikulin Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 07:48:32 -0000 --OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 01:36:55PM -0800, Marcel Moolenaar wrote: > All, >=20 > Please review the attached changes (done by Dmitry -- CC'd) to add suppor= t for > PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK. >=20 > I'll commit this when there are no comments/objections. > Thanks, I would certainly appreciate some more words describing the changes. What is the goal of introducing the PT_FOLLOW_EXEC ? To not force the debugger to filter all syscall exits to see exec events ? Why did you moved the stopevent/ptracestop for exec events from syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC is not removed from syscallret() ? I do not think that TDB_EXEC can be seen there after the patch. The same question about TDB_FORK. If possible, I would greatly prefer to have fork changes separated. I doubt that disallowing RFMEM while tracing is the right change. It may be to fix some (undescribed) bug, but RFMEM is documented behaviour used not only for vfork(2), and the change just breaks rfork(2) for debugged processes. Even vfork() should not be broken, since I believe there are programs that rely on the vfork() model, in particular, C shell. It will be broken if vfork() is substituted by fork(). The fact that it breaks only under debugger will make it esp. confusing. Why do we need to have TDB_FORK set for td2 ? Does the orphan list change intended to not lost the child after fork ? But the child shall be traced, so debugger would get the SIGTRAP on the attach on fork returning to usermode. I remember that I explicitely tested this when adding followfork changes. --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8fs8gACgkQC3+MBN1Mb4iV5wCgzqH0Lf3OWLNVKFnebVoXiLqn 1dMAnjkLw03Q6x/DarX4KxiaXBTyiefI =0ixd -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 12:15:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DBCA106564A; Wed, 25 Jan 2012 12:15:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A40C28FC0A; Wed, 25 Jan 2012 12:15:33 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0PCFT2e040967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 14:15:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0PCFSKo010576; Wed, 25 Jan 2012 14:15:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0PCFSjF010575; Wed, 25 Jan 2012 14:15:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 14:15:28 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20120125121528.GJ2726@deviant.kiev.zoral.com.ua> References: <20120123013642.GB10149@sirius.xvoid.org> <20120123030513.GK31224@deviant.kiev.zoral.com.ua> <4F1D74B9.8010800@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJFRpmOek+ZRSQoz" Content-Disposition: inline In-Reply-To: <4F1D74B9.8010800@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Yuri Pankov , Rick Macklem , freebsd-current@freebsd.org Subject: Re: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:15:34 -0000 --IJFRpmOek+ZRSQoz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2012 at 06:54:49AM -0800, John Baldwin wrote: > On 1/22/12 7:05 PM, Kostik Belousov wrote: > > On Mon, Jan 23, 2012 at 05:36:42AM +0400, Yuri Pankov wrote: > >> Seems to be reproducible here running r230467 as the NFS client and > >> r230135 as NFS server. NFSv4 not enabled. > >> > >> # mount > >> [...] > >> sirius:/data/distfiles on /usr/ports/distfiles (nfs) > >> > >> # /usr/bin/env /usr/bin/fetch -AFpr -S 4682084 -o /usr/ports/distfiles= /sqlite-src-3071000.zip http://www.sqlite.org/sqlite-src-3071000.zip > >> /usr/ports/distfiles/sqlite-src-3071000.zip 100% of 4572 kB 379 kBp= s 00m00s > >> # rm /usr/ports/distfiles/sqlite-src-3071000.zip > >> > >> immediately followed by: > >> > >> panic: No NCF_TS > >> cpuid =3D 2 > >> KDB: enter: panic > >> [ thread pid 1603 tid 100494 ] > >> Stopped at kdb_enter+0x3e: movq $0,kdb_why > >> db> bt > >> Tracing pid 1603 tid 100494 td 0xfffffe0089585460 > >> kdb_enter() at kdb_enter+0x3e > >> panic() at panic+0x245 > >> cache_lookup_times() at cache_lookup_times+0x6b5 > >> nfs_lookup() at nfs_lookup+0x190 > >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x8b > >> lookup() at lookup+0x7e9 > >> namei() at namei+0x74c > >> kern_statat_vnhook() at kern_statat_vnhook+0x90 > >> sys_lstat() at sys_lstat+0x30 > >> amd64_syscall() at amd64_syscall+0x221 > >> Xfast_syscall() at Xfast_syscall+0xfb > >> --- syscall (190, FreeBSD ELF64, sys_lstat), rip =3D 0x80093ff3c, rsp = =3D 0x7fffffffd8d8, rbp =3D 0x7fffffffd979 --- > >> > >=20 > > Yes, my bad. I wrote the r230441 with the assumption that filesystems > > are consistent in their use of cache_enter_time(). And my net-booting > > test box did not catched this, which is at least interesting. > >=20 > > Please try the change below. Actually, it should be enough to only apply > > the changes for fs/nfsclient (or nfsclient/ if you use old nfs). If this > > does not help, then please try the whole patch. >=20 > I think we should have the existing assertion. If cache_lookup_times() > is called with a timestamp requested, then returning a name cache entry > without a timestamp is just going to result in that name cache entry not > being used. Panic'ing in that case is correct. >=20 > With regard to the NFS changes below, all of these are bugs that didn't > really work right before. Specifically, adding a positive entry without > setting n_ctime previously would have just resulted in the name cache > entry being purged on the next lookup anyway. Keep in mind that the > timestamp for a give name cache entry in NFS needs to match an actual > timestamp returned by the NFS server as post-op attributes in some RPC. > Using the timestamp from vfs_timestamp() is completely bogus. Instead, > the timestamp for a negative entry needs to be the mtime of the parent > directory. If we don't have that timestamp handy, then we should just > not add a namecache entry at all. Also, the vap->va_ctime used below > for mknod() and create() is not a timestamp from the server, so it is > also suspect. I can look at this in more detail on Wednesday, but my > best guess is that nearly all (if not all) of these cache_enter() calls > will simply need to be removed. >=20 > Note that other filesystems like UFS don't bother creating name cache > entries for things like create or mknod. It's debatable if the NFS > client should even be creating any name cache entries outside of lookup > and when handling a READDIR+ reply. Ok, next try. I did removed the cache_enter calls for old nfs client, but it seems that the calls can be kept for the new client. diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index 2747191..709cd8d 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@ -1431,8 +1431,6 @@ nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, s= truct componentname *cnp, } } if (!error) { - if ((cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); *vpp =3D newvp; } else if (NFS_ISV4(dvp)) { error =3D nfscl_maperr(cnp->cn_thread, error, vap->va_uid, @@ -1591,7 +1589,7 @@ again: } if (!error) { if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); *ap->a_vpp =3D newvp; } else if (NFS_ISV4(dvp)) { error =3D nfscl_maperr(cnp->cn_thread, error, vap->va_uid, @@ -1966,8 +1964,9 @@ nfs_link(struct vop_link_args *ap) * must care about lookup caching hit rate, so... */ if (VFSTONFS(vp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(tdvp, vp, cnp); + (cnp->cn_flags & MAKEENTRY) && dattrflag) { + cache_enter_time(tdvp, vp, cnp, &dnfsva.na_mtime); + } if (error && NFS_ISV4(vp)) error =3D nfscl_maperr(cnp->cn_thread, error, (uid_t)0, (gid_t)0); @@ -2023,15 +2022,6 @@ nfs_symlink(struct vop_symlink_args *ap) error =3D nfscl_maperr(cnp->cn_thread, error, vap->va_uid, vap->va_gid); } else { - /* - * If negative lookup caching is enabled, I might as well - * add an entry for this node. Not necessary for correctness, - * but if negative caching is enabled, then the system - * must care about lookup caching hit rate, so... - */ - if (VFSTONFS(dvp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); *ap->a_vpp =3D newvp; } =20 @@ -2041,6 +2031,16 @@ nfs_symlink(struct vop_symlink_args *ap) if (dattrflag !=3D 0) { mtx_unlock(&dnp->n_mtx); (void) nfscl_loadattrcache(&dvp, &dnfsva, NULL, NULL, 0, 1); + /* + * If negative lookup caching is enabled, I might as well + * add an entry for this node. Not necessary for correctness, + * but if negative caching is enabled, then the system + * must care about lookup caching hit rate, so... + */ + if (VFSTONFS(dvp->v_mount)->nm_negnametimeo !=3D 0 && + (cnp->cn_flags & MAKEENTRY)) { + cache_enter_time(dvp, newvp, cnp, &dnfsva.na_mtime); + } } else { dnp->n_attrstamp =3D 0; mtx_unlock(&dnp->n_mtx); @@ -2116,8 +2116,9 @@ nfs_mkdir(struct vop_mkdir_args *ap) * must care about lookup caching hit rate, so... */ if (VFSTONFS(dvp->v_mount)->nm_negnametimeo !=3D 0 && - (cnp->cn_flags & MAKEENTRY)) - cache_enter(dvp, newvp, cnp); + (cnp->cn_flags & MAKEENTRY) && dattrflag) { + cache_enter_time(dvp, newvp, cnp, &dnfsva.na_mtime); + } *ap->a_vpp =3D newvp; } return (error); diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index 647dcac..4562ebc 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -237,13 +237,9 @@ static void cache_out_ts(struct namecache *ncp, struct timespec *tsp, int *ticksp) { =20 - if ((ncp->nc_flag & NCF_TS) =3D=3D 0) { - if (tsp !=3D NULL) - bzero(tsp, sizeof(*tsp)); - if (ticksp !=3D NULL) - *ticksp =3D 0; - return; - } + KASSERT((ncp->nc_flag & NCF_TS) !=3D 0 || + (tsp =3D=3D NULL && ticksp =3D=3D NULL), + ("No NCF_TS")); =20 if (tsp !=3D NULL) *tsp =3D ((struct namecache_ts *)ncp)->nc_time; @@ -791,8 +787,8 @@ cache_enter_time(dvp, vp, cnp, tsp) n2->nc_nlen =3D=3D cnp->cn_namelen && !bcmp(nc_get_name(n2), cnp->cn_nameptr, n2->nc_nlen)) { if (tsp !=3D NULL) { - if ((n2->nc_flag & NCF_TS) =3D=3D 0) - continue; + KASSERT((n2->nc_flag & NCF_TS) !=3D 0, + ("no NCF_TS")); n3 =3D (struct namecache_ts *)n2; n3->nc_time =3D ((struct namecache_ts *)ncp)->nc_time; diff --git a/sys/nfsclient/nfs_vnops.c b/sys/nfsclient/nfs_vnops.c index a39b29b..c2dfd97 100644 --- a/sys/nfsclient/nfs_vnops.c +++ b/sys/nfsclient/nfs_vnops.c @@ -1530,8 +1530,6 @@ nfsmout: if (newvp) vput(newvp); } else { - if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); *vpp =3D newvp; } mtx_lock(&(VTONFS(dvp))->n_mtx); @@ -1670,8 +1668,6 @@ nfsmout: vput(newvp); } if (!error) { - if (cnp->cn_flags & MAKEENTRY) - cache_enter(dvp, newvp, cnp); *ap->a_vpp =3D newvp; } mtx_lock(&(VTONFS(dvp))->n_mtx); --IJFRpmOek+ZRSQoz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8f8mAACgkQC3+MBN1Mb4hvYwCbBl7jcEWExQXIk6xGdShcpkj8 qCcAni8D6kR9fUM56IF7XoWnpMewfgtg =dSbk -----END PGP SIGNATURE----- --IJFRpmOek+ZRSQoz-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 12:16:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 709181065675; Wed, 25 Jan 2012 12:16:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA3308FC15; Wed, 25 Jan 2012 12:16:50 +0000 (UTC) Received: by eaai10 with SMTP id i10so2160427eaa.13 for ; Wed, 25 Jan 2012 04:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pHS05hAeqeIyrhZ6zv4vD3snzXmacjocG9t0TctsUwY=; b=BrcUW12UxByCd4S9IHO/xQFswTVyQ38Cv/NGpD2tB/N4u34Q0vrolYJgzVjugzRjuk Qd8rIb/2P/TxfB40oAO7vRxpTcvzwvll6WHp8mQhspl53uQ4iZPhMTUQD2k9R9PNQAak OkVZp/f5VV+fU9rcqvdil1AXVVUaZYwmQMD28= Received: by 10.213.106.7 with SMTP id v7mr3054036ebo.50.1327493809756; Wed, 25 Jan 2012 04:16:49 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id r2sm964932eef.7.2012.01.25.04.16.47 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 04:16:48 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1FF2AD.9020003@FreeBSD.org> Date: Wed, 25 Jan 2012 14:16:45 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:16:51 -0000 On 01/25/12 09:42, Mickaël Maillot wrote: > 2012/1/25 Alexander Motin > > > > What I've forgot is to allow 8ch format. :) Add the > patch below. > Hope > sound(4) has no other limitations for it. > > Hmm. Looks like there is some limitation. You may grep > kernel for > AFMT_PASSTHROUGH and find two "XXX force ..." comments and code, > including forcing 2 channels for AC3. Luckily for not part for > frequency is commented out. Further we may try to comment or > modify > part about number of channels. > > spotted and commented > > so if my problem persist after settings 8 channels, i'll blame > xbmc oss > part. > > > ok so unfortunately it's does not work :( > first: with vchan disable, i cant set format to AFMT_AC3, ioctl always > return -1 > in /v/l/messages: > Jan 25 08:09:18 htpc kernel: pcm4: chn_setformat(): Format change > 0x00100400 failed, falling back to 0x00100008 > so may be my change in sys/dev/sound/pcm/channel.c is not good ? i just > commented: > /* XXX force stereo */ > if (format & AFMT_PASSTHROUGH) > format = SND_FORMAT(format, AFMT_PASSTHROUGH_CHANNEL, > AFMT_PASSTHROUGH_EXTCHANNEL); Commenting it appeared not good, as at least mplayer doesn't sets channels for AC3. That makes sound(4) use default 1 channel for AC3, that is definitely not supported. I believe this should be better: http://svn.freebsd.org/changeset/base/230537 Also, as soon as sound(4) interprets 8 channel as 7.1 by default, I've changed previous patch a bit to allow both "8.0" and "7.1" AC3 formats: http://svn.freebsd.org/changeset/base/230513 For me this at least doesn't break normal AC3 operation and when I hacked mplayer to set 8 channels, I can see predictable codec configuration and time in mplayer predictably running 4 times faster. Unluckily mplayer seems doesn't support TrueHD passthrough to ckeck closer -- it always does decoding. > next with vchan: i can set ac3 to 2 channels and 8 channels. > when i try to play DTS HDMA or TRUEHD, i set ac3, 8 channels, 192k > and no sound ! before i had: dtshdma: some part of sound (like all data > cant be send) and truehd: some crapy bipbip > now everything seems to be ok for the player, procstat -f write counter > grows up, but no sound from my receiver: no channel input, nothing > showed, like nothing is send to him. > no error in xbmc.log or in messages: > Jan 25 08:15:35 htpc kernel: pcm4: chn_start(): VCHAN PARENT starting! > (PCMDIR_PLAY/running) (ready=8192 force=1 i=1 j=0 intrtimeout=2 latency=2ms) > Jan 25 08:15:35 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used > Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup > fmt=02800400 (7.1) speed=192000 > Jan 25 08:15:35 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: > fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 > Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:play:dsp4.p0: > calling go=0x00000001 , prev=0xffffffff > Jan 25 08:15:35 htpc kernel: pcm4: chn_trigger() pcm4:virtual:dsp4.vp0: > calling go=0x00000001 , prev=0xffffffff I've tried with both vchans on and off and found no difference. In both cases cases I had vchanformat set to "s16le:2.0", as vchan should just pass any ac3 through without conversion and set format is not important. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 12:22:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D76106566C for ; Wed, 25 Jan 2012 12:22:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id F1E3E8FC12 for ; Wed, 25 Jan 2012 12:22:43 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0PCLRNS042491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 14:21:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0PCLNAE010629; Wed, 25 Jan 2012 14:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0PCLNlZ010628; Wed, 25 Jan 2012 14:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 14:21:23 +0200 From: Kostik Belousov To: Milan Obuch Message-ID: <20120125122123.GK2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XjbSsFHOHxvQpKib" Content-Disposition: inline In-Reply-To: <20120124183152.40c5c5af@atom.dino.sk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:22:44 -0000 --XjbSsFHOHxvQpKib Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: > Hi, >=20 > as I succesfully installed FreeBSD on Mac Mini (older powerpc model > with G4 CPU) I tried to use mount_nullfs to share some files for more > systems. I use this method for years on i386 and amd64 platforms for > years now to share sources and other files. >=20 > Basically I want to have small system specific slice/partition and > large shared data area. System sources are in shared area as well as > some working area (think /usr/src and /usr/obj directories). >=20 > This does not work with powerpc for me. With sources csup'ped this > morning, full system rebuild with GENERIC kernel, it is enough for me > to issue >=20 > mount_nullfs /data/src10 /usr/src > csup /usr/share/examples/cvsup/standard-supfile >=20 > and system panic occurs, with following on system console: >=20 > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/vfs_subr.c:2670 > cpuid =3D 0 > KDB: enter: panic > [ thread pid 1442 tid 100095 ] > Stopped at 0x40f734: addi r0, r0, 0x0 > db> >=20 > At this point, I am able to interact with system, the question for me > is what I want to get from it :) I tried bt with following result: >=20 > Tracing pid 1442 tid 100095 td 0x2d6b000 > 0xe22c26d0: at panic+0x274 > 0xe22c2730: at _mtx_lock_flags+0xc4 > 0xe22c2760: at vgonel+0x330 > 0xe22c27b0: at vrecycle+0x54 > 0xe22c27d0: at null_inactive+0x30 > 0xe22c27f0: at VOP_INACTIVE_APV+0xdc > 0xe22c2810: at vinactive+0x98 > 0xe22c2850: at vputx+0x344 > 0xe22c28a0: at vput+0x18 > 0xe22c28c0: at kern_statat_vnhook+0x108 > 0xe22c29d0: at kern_statat+0x18 > 0xe22c29f0: at kern_lstat+0x2c > 0xe22c2a10: at sys_lstat+0x30 > 0xe22c2a90: at trap+0x388 > 0xe22c2b60: at powerpc_interrupt+0x108 > 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=3D0xd032 > r1=3D0xffaf9a70 cr=3D0x28004044 xer=3D0x20000000 ctr=3D0x41a0= ac40 > db> >=20 > Does this shed any light for someone with more knowledge here? My gut > feeling is there is some endianness issue at play, the same nullfs > usage works for me flawlessly on both i386 and amd64 systems, so it > could not be 32 vs 64 bit issue at least. >=20 > At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function void > vgonel(struct vnode *vp) >=20 > VI_LOCK(vp); > vp->v_vnlock =3D &vp->v_lock; > vp->v_op =3D &dead_vnodeops; > vp->v_tag =3D "none"; > vp->v_type =3D VBAD; > } >=20 > so the question seems to be reduced to 'why is vp null?' or is my small > attempt on analyse flawed... I do not think that the vp is null. It more look like the *vp memory was zeroed. This has very low chances of being related to endianess, and more like a kernel memory corruption. Take a dump and print the content of *vp. --XjbSsFHOHxvQpKib Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8f88MACgkQC3+MBN1Mb4jF9ACglY79BRneKuX5dxLV26n2/++I NRQAoJbr1nQriIq85GZq1uscg0pdKKqe =oWbS -----END PGP SIGNATURE----- --XjbSsFHOHxvQpKib-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 16:29:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF8D1065677 for ; Wed, 25 Jan 2012 16:29:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9C43E8FC13 for ; Wed, 25 Jan 2012 16:29:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 3623F46B3F; Wed, 25 Jan 2012 11:29:26 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8FE4EB926; Wed, 25 Jan 2012 11:29:25 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 25 Jan 2012 11:29:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201191739.48327.tijl@coosemans.org> <201201201412.13269.jhb@freebsd.org> In-Reply-To: <201201201412.13269.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201251129.22368.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Jan 2012 11:29:25 -0500 (EST) Cc: Tijl Coosemans Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:29:27 -0000 On Friday, January 20, 2012 2:12:13 pm John Baldwin wrote: > On Thursday, January 19, 2012 11:39:42 am Tijl Coosemans wrote: > > Hi, > > > > I recently noticed that multimedia/vlc generates a lot of disk IO when > > playing media files. For instance, when playing a 320kbps mp3 gstat > > reports about 1250kBps (=10000kbps). That's quite a lot of overhead. > > > > It turns out that vlc sets POSIX_FADV_NOREUSE on the entire file and > > reads in chunks of 1028 bytes. FreeBSD implements NOREUSE as if > > O_DIRECT was specified during open(2), i.e. it disables all caching. > > That means every 1028 byte read turns into a 32KiB read (new default > > block size in 9.0) which explains the above numbers. > > > > I've copied the relevant vlc code below (modules/access/file.c:Open()). > > It's interesting to see that on OSX it sets F_NOCACHE which disables > > caching too, but combined with F_RDAHEAD there's still read-ahead > > caching. > > > > I don't think POSIX intended for NOREUSE to mean O_DIRECT. It should > > still cache data (and even do read-ahead if F_RDAHEAD is specified), > > and once data is fetched from the cache, it can be marked WONTNEED. > > POSIX doesn't specify O_DIRECT, so it's not clear what it asks for. > > > Is it possible to implement it this way, or if not to just ignore > > the NOREUSE hint for now? > > I think it would be good to improve NOREUSE, though I had sort of > assumed that applications using NOREUSE would do their own buffering > and read full blocks. We could perhaps reimplement NOREUSE by doing > the equivalent of POSIX_FADV_DONTNEED after each read to free buffers > and pages after the data is copied out to userland. I also have an > XXX about whether or not NOREUSE should still allow read-ahead as it > isn't very clear what the right thing to do there is. HP-UX (IIRC) > has an fadvise() that lets you specify multiple policies, so you > could specify both NOREUSE and SEQUENTIAL for a single region to > get read-ahead but still release memory once the data is read once. So I've came up with this untested patch. It uses VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, and leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn't do any good really for writes (it only flushes clean buffers), so I've left write(2) operations as using IO_DIRECT still. Does this sound reasonable? I've not yet tested this at all: Index: vfs_vnops.c =================================================================== --- vfs_vnops.c (revision 230331) +++ vfs_vnops.c (working copy) @@ -519,6 +519,7 @@ vn_read(fp, uio, active_cred, flags, td) int error, ioflag; struct mtx *mtxp; int advice, vfslocked; + off_t offset; KASSERT(uio->uio_td == td, ("uio_td %p is not td %p", uio->uio_td, td)); @@ -558,19 +559,14 @@ vn_read(fp, uio, active_cred, flags, td) switch (advice) { case POSIX_FADV_NORMAL: case POSIX_FADV_SEQUENTIAL: + case POSIX_FADV_NOREUSE: ioflag |= sequential_heuristic(uio, fp); break; case POSIX_FADV_RANDOM: /* Disable read-ahead for random I/O. */ break; - case POSIX_FADV_NOREUSE: - /* - * Request the underlying FS to discard the buffers - * and pages after the I/O is complete. - */ - ioflag |= IO_DIRECT; - break; } + offset = uio->uio_offset; #ifdef MAC error = mac_vnode_check_read(active_cred, fp->f_cred, vp); @@ -587,6 +583,10 @@ vn_read(fp, uio, active_cred, flags, td) } fp->f_nextoff = uio->uio_offset; VOP_UNLOCK(vp, 0); + if (error == 0 && advice == POSIX_FADV_NOREUSE && + offset != uio->uio_offset) + error = VOP_ADVISE(vp, offset, uio->uio_offset - 1, + POSIX_FADV_DONTNEED); VFS_UNLOCK_GIANT(vfslocked); return (error); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 16:30:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEFBF1065687 for ; Wed, 25 Jan 2012 16:30:24 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from sirius.xvoid.org (sirius.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:fe62:9a22]) by mx1.freebsd.org (Postfix) with ESMTP id 995268FC19 for ; Wed, 25 Jan 2012 16:30:24 +0000 (UTC) Received: from sirius.xvoid.org (yuri@sirius.xvoid.org [IPv6:::1]) by sirius.xvoid.org (8.14.5/8.14.5) with ESMTP id q0PGUNtC005930 for ; Wed, 25 Jan 2012 20:30:23 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by sirius.xvoid.org (8.14.5/8.14.5/Submit) id q0PGUMmE005929 for freebsd-current@freebsd.org; Wed, 25 Jan 2012 20:30:22 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: sirius.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Wed, 25 Jan 2012 20:30:22 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20120125163022.GA1070@sirius.xvoid.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: LOR so_snd_sx @ uipc_sockbuf.c and filedesc structure @ uipc_usrreq.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:30:25 -0000 Hi, Getting this LOR every time I login via ssh after reboot, and it doesn't seem to be reported previously. Running 10.0-CURRENT r230537. lock order reversal: 1st 0xfffffe0160615490 so_snd_sx (so_snd_sx) @ /usr/src/sys/kern/uipc_sockbuf.c:148 2nd 0xfffffe0029ef1048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/uipc_usrreq.c:1872 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b kdb_backtrace() at kdb_backtrace+0x39 witness_checkorder() at witness_checkorder+0x715 _sx_slock() at _sx_slock+0x57 uipc_send() at uipc_send+0x1fe sosend_generic() at sosend_generic+0x31a kern_sendit() at kern_sendit+0x1bb sendit() at sendit+0xf0 sys_sendmsg() at sys_sendmsg+0x61 amd64_syscall() at amd64_syscall+0x221 Xfast_syscall() at Xfast_syscall+0xfb --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x8024dabfc, rsp = 0x7fffffffcb08, rbp = 0x7fffffffcbb0 --- Yuri From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 18:35:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA7611065670; Wed, 25 Jan 2012 18:35:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF9DD8FC13; Wed, 25 Jan 2012 18:35:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 50C5846B06; Wed, 25 Jan 2012 13:35:44 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D2095B926; Wed, 25 Jan 2012 13:35:43 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Wed, 25 Jan 2012 13:35:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120123013642.GB10149@sirius.xvoid.org> <4F1D74B9.8010800@FreeBSD.org> <20120125121528.GJ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120125121528.GJ2726@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201251335.43387.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Jan 2012 13:35:43 -0500 (EST) Cc: Yuri Pankov , Rick Macklem , freebsd-current@freebsd.org Subject: Re: panic: No NCF_TS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 18:35:45 -0000 On Wednesday, January 25, 2012 7:15:28 am Kostik Belousov wrote: > diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c > index 2747191..709cd8d 100644 > --- a/sys/fs/nfsclient/nfs_clvnops.c > +++ b/sys/fs/nfsclient/nfs_clvnops.c > @@ -1431,8 +1431,6 @@ nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, struct componentname *cnp, > } > } > if (!error) { > - if ((cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > *vpp = newvp; > } else if (NFS_ISV4(dvp)) { > error = nfscl_maperr(cnp->cn_thread, error, vap->va_uid, This is good. > @@ -1591,7 +1589,7 @@ again: > } > if (!error) { > if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > + cache_enter_time(dvp, newvp, cnp, &vap->va_ctime); > *ap->a_vpp = newvp; > } else if (NFS_ISV4(dvp)) { > error = nfscl_maperr(cnp->cn_thread, error, vap->va_uid, This should use the post-op attrs instead. Maybe this: if (cnp->cn_flags & MAKEENTRY && attrflag) cache_enter_time(dvp, newvp, cnp, &nfsva.na_ctime); > @@ -1966,8 +1964,9 @@ nfs_link(struct vop_link_args *ap) > * must care about lookup caching hit rate, so... > */ > if (VFSTONFS(vp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(tdvp, vp, cnp); > + (cnp->cn_flags & MAKEENTRY) && dattrflag) { > + cache_enter_time(tdvp, vp, cnp, &dnfsva.na_mtime); > + } > if (error && NFS_ISV4(vp)) > error = nfscl_maperr(cnp->cn_thread, error, (uid_t)0, > (gid_t)0); Looks good. > @@ -2023,15 +2022,6 @@ nfs_symlink(struct vop_symlink_args *ap) > error = nfscl_maperr(cnp->cn_thread, error, > vap->va_uid, vap->va_gid); > } else { > - /* > - * If negative lookup caching is enabled, I might as well > - * add an entry for this node. Not necessary for correctness, > - * but if negative caching is enabled, then the system > - * must care about lookup caching hit rate, so... > - */ > - if (VFSTONFS(dvp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > *ap->a_vpp = newvp; > } > @@ -2041,6 +2031,16 @@ nfs_symlink(struct vop_symlink_args *ap) > if (dattrflag != 0) { > mtx_unlock(&dnp->n_mtx); > (void) nfscl_loadattrcache(&dvp, &dnfsva, NULL, NULL, 0, 1); > + /* > + * If negative lookup caching is enabled, I might as well > + * add an entry for this node. Not necessary for correctness, > + * but if negative caching is enabled, then the system > + * must care about lookup caching hit rate, so... > + */ > + if (VFSTONFS(dvp->v_mount)->nm_negnametimeo != 0 && > + (cnp->cn_flags & MAKEENTRY)) { > + cache_enter_time(dvp, newvp, cnp, &dnfsva.na_mtime); > + } > } else { > dnp->n_attrstamp = 0; > mtx_unlock(&dnp->n_mtx); Good. > @@ -2116,8 +2116,9 @@ nfs_mkdir(struct vop_mkdir_args *ap) > * must care about lookup caching hit rate, so... > */ > if (VFSTONFS(dvp->v_mount)->nm_negnametimeo != 0 && > - (cnp->cn_flags & MAKEENTRY)) > - cache_enter(dvp, newvp, cnp); > + (cnp->cn_flags & MAKEENTRY) && dattrflag) { > + cache_enter_time(dvp, newvp, cnp, &dnfsva.na_mtime); > + } > *ap->a_vpp = newvp; > } > return (error); Correct (I'm still not sure it is really best to be adding these extra entries, but that's a separate issue). > diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c > index 647dcac..4562ebc 100644 > --- a/sys/kern/vfs_cache.c > +++ b/sys/kern/vfs_cache.c > @@ -237,13 +237,9 @@ static void > cache_out_ts(struct namecache *ncp, struct timespec *tsp, int *ticksp) > { > > - if ((ncp->nc_flag & NCF_TS) == 0) { > - if (tsp != NULL) > - bzero(tsp, sizeof(*tsp)); > - if (ticksp != NULL) > - *ticksp = 0; > - return; > - } > + KASSERT((ncp->nc_flag & NCF_TS) != 0 || > + (tsp == NULL && ticksp == NULL), > + ("No NCF_TS")); > > if (tsp != NULL) > *tsp = ((struct namecache_ts *)ncp)->nc_time; > @@ -791,8 +787,8 @@ cache_enter_time(dvp, vp, cnp, tsp) > n2->nc_nlen == cnp->cn_namelen && > !bcmp(nc_get_name(n2), cnp->cn_nameptr, n2->nc_nlen)) { > if (tsp != NULL) { > - if ((n2->nc_flag & NCF_TS) == 0) > - continue; > + KASSERT((n2->nc_flag & NCF_TS) != 0, > + ("no NCF_TS")); > n3 = (struct namecache_ts *)n2; > n3->nc_time = > ((struct namecache_ts *)ncp)->nc_time; Good. > diff --git a/sys/nfsclient/nfs_vnops.c b/sys/nfsclient/nfs_vnops.c > index a39b29b..c2dfd97 100644 > --- a/sys/nfsclient/nfs_vnops.c > +++ b/sys/nfsclient/nfs_vnops.c > @@ -1530,8 +1530,6 @@ nfsmout: > if (newvp) > vput(newvp); > } else { > - if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > *vpp = newvp; > } > mtx_lock(&(VTONFS(dvp))->n_mtx); > @@ -1670,8 +1668,6 @@ nfsmout: > vput(newvp); > } > if (!error) { > - if (cnp->cn_flags & MAKEENTRY) > - cache_enter(dvp, newvp, cnp); > *ap->a_vpp = newvp; > } > mtx_lock(&(VTONFS(dvp))->n_mtx); This is fine. If we really cared about these, we could add a variant of nfsm_wcc_data() that returned the post-op attributes, but it's not really worth doing I think. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 18:41:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAF20106566C for ; Wed, 25 Jan 2012 18:41:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 776748FC08 for ; Wed, 25 Jan 2012 18:41:42 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so8709906obc.13 for ; Wed, 25 Jan 2012 10:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KRo3QYildeElD6DNku8DHKeYaNFQv0fkjTdoKdag6PQ=; b=Of0VNwFWB1K7wIJhve5g+BHigAWcOn0SfBn4RJp9fb4PconxnZCqSPzqlf/GbXJR03 K69UGJuw9WOsha3gtugg0cjdQPOhb7B5t8F1yByz3MAi+EVmOdfy1Itm2CJQM3w94/ov GsS1O1oohBQ0NgVCXwvjhEOZGWLWlwjN2voOM= MIME-Version: 1.0 Received: by 10.182.76.135 with SMTP id k7mr16577899obw.62.1327516902057; Wed, 25 Jan 2012 10:41:42 -0800 (PST) Received: by 10.182.74.167 with HTTP; Wed, 25 Jan 2012 10:41:41 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Jan 2012 21:41:41 +0300 Message-ID: From: Sergey Kandaurov To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Improving the FreeBSD-9 boot menu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 18:41:42 -0000 On 21 September 2011 05:46, Warren Block wrote: > The patch in PR 160818 makes some clarifications and improvements to the = new > boot menu. =A0Obviously this is not for 9.0-RELEASE, just wanting to get = it > out there so people can look at it. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D160818 > I just committed it to head and will merge it to stable/9 in 1 week. Thanks! --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 19:50:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01642106566B for ; Wed, 25 Jan 2012 19:50:51 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id A8EF68FC08 for ; Wed, 25 Jan 2012 19:50:50 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Wed, 25 Jan 2012 20:48:29 +0100 id 00033C37.4F205C8D.000135DD Date: Wed, 25 Jan 2012 20:50:41 +0100 From: Milan Obuch To: Kostik Belousov Message-ID: <20120125205041.26aeef85@atom.dino.sk> In-Reply-To: <20120125122123.GK2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 19:50:51 -0000 On Wed, 25 Jan 2012 14:21:23 +0200 Kostik Belousov wrote: > On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: > > Hi, > > [ snip ] > > This does not work with powerpc for me. With sources csup'ped this > > morning, full system rebuild with GENERIC kernel, it is enough for > > me to issue > > > > mount_nullfs /data/src10 /usr/src > > csup /usr/share/examples/cvsup/standard-supfile > > > > and system panic occurs, with following on system console: > > > > panic: mtx_lock() of spin mutex (null) > > @ /usr/src/sys/kern/vfs_subr.c:2670 cpuid = 0 > > KDB: enter: panic > > [ thread pid 1442 tid 100095 ] > > Stopped at 0x40f734: addi r0, r0, 0x0 > > db> > > > > At this point, I am able to interact with system, the question for > > me is what I want to get from it :) I tried bt with following > > result: > > > > Tracing pid 1442 tid 100095 td 0x2d6b000 > > 0xe22c26d0: at panic+0x274 > > 0xe22c2730: at _mtx_lock_flags+0xc4 > > 0xe22c2760: at vgonel+0x330 > > 0xe22c27b0: at vrecycle+0x54 > > 0xe22c27d0: at null_inactive+0x30 > > 0xe22c27f0: at VOP_INACTIVE_APV+0xdc > > 0xe22c2810: at vinactive+0x98 > > 0xe22c2850: at vputx+0x344 > > 0xe22c28a0: at vput+0x18 > > 0xe22c28c0: at kern_statat_vnhook+0x108 > > 0xe22c29d0: at kern_statat+0x18 > > 0xe22c29f0: at kern_lstat+0x2c > > 0xe22c2a10: at sys_lstat+0x30 > > 0xe22c2a90: at trap+0x388 > > 0xe22c2b60: at powerpc_interrupt+0x108 > > 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=0xd032 > > r1=0xffaf9a70 cr=0x28004044 xer=0x20000000 > > ctr=0x41a0ac40 > > db> > > > > Does this shed any light for someone with more knowledge here? My > > gut feeling is there is some endianness issue at play, the same > > nullfs usage works for me flawlessly on both i386 and amd64 > > systems, so it could not be 32 vs 64 bit issue at least. > > > > At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function > > void vgonel(struct vnode *vp) > > > > VI_LOCK(vp); > > vp->v_vnlock = &vp->v_lock; > > vp->v_op = &dead_vnodeops; > > vp->v_tag = "none"; > > vp->v_type = VBAD; > > } > > > > so the question seems to be reduced to 'why is vp null?' or is my > > small attempt on analyse flawed... > I do not think that the vp is null. It more look like the *vp memory > was zeroed. This has very low chances of being related to endianess, > and more like a kernel memory corruption. > > Take a dump and print the content of *vp. How could I look into memory? I found page http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html and I can see registers (show reg), use x with absolute addresses, but something like 'x vp' tells just 'Symbol not known' - should I somehow load symbol table into memory? But backtrace shows function names... or should I somehow modify GENERIC kernel to include more debugging info? Kernel debugging is a bit new for me, even if I can write simple modification into kernel, but only in some special (and narrow) area of code... Regards, Milan From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 20:08:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7FD2106566C for ; Wed, 25 Jan 2012 20:08:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1EB8FC14 for ; Wed, 25 Jan 2012 20:08:22 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0PK8HQN081815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 22:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0PK8H0b012873; Wed, 25 Jan 2012 22:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0PK8H5k012872; Wed, 25 Jan 2012 22:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 22:08:17 +0200 From: Kostik Belousov To: Milan Obuch Message-ID: <20120125200817.GO2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Thv7PGoFpDPJ7Oar" Content-Disposition: inline In-Reply-To: <20120125205041.26aeef85@atom.dino.sk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:08:23 -0000 --Thv7PGoFpDPJ7Oar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 08:50:41PM +0100, Milan Obuch wrote: > On Wed, 25 Jan 2012 14:21:23 +0200 > Kostik Belousov wrote: >=20 > > On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: > > > Hi, > > >=20 >=20 > [ snip ] >=20 > > > This does not work with powerpc for me. With sources csup'ped this > > > morning, full system rebuild with GENERIC kernel, it is enough for > > > me to issue > > >=20 > > > mount_nullfs /data/src10 /usr/src > > > csup /usr/share/examples/cvsup/standard-supfile > > >=20 > > > and system panic occurs, with following on system console: > > >=20 > > > panic: mtx_lock() of spin mutex (null) > > > @ /usr/src/sys/kern/vfs_subr.c:2670 cpuid =3D 0 > > > KDB: enter: panic > > > [ thread pid 1442 tid 100095 ] > > > Stopped at 0x40f734: addi r0, r0, 0x0 > > > db> > > >=20 > > > At this point, I am able to interact with system, the question for > > > me is what I want to get from it :) I tried bt with following > > > result: > > >=20 > > > Tracing pid 1442 tid 100095 td 0x2d6b000 > > > 0xe22c26d0: at panic+0x274 > > > 0xe22c2730: at _mtx_lock_flags+0xc4 > > > 0xe22c2760: at vgonel+0x330 > > > 0xe22c27b0: at vrecycle+0x54 > > > 0xe22c27d0: at null_inactive+0x30 > > > 0xe22c27f0: at VOP_INACTIVE_APV+0xdc > > > 0xe22c2810: at vinactive+0x98 > > > 0xe22c2850: at vputx+0x344 > > > 0xe22c28a0: at vput+0x18 > > > 0xe22c28c0: at kern_statat_vnhook+0x108 > > > 0xe22c29d0: at kern_statat+0x18 > > > 0xe22c29f0: at kern_lstat+0x2c > > > 0xe22c2a10: at sys_lstat+0x30 > > > 0xe22c2a90: at trap+0x388 > > > 0xe22c2b60: at powerpc_interrupt+0x108 > > > 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=3D0xd032 > > > r1=3D0xffaf9a70 cr=3D0x28004044 xer=3D0x20000000 > > > ctr=3D0x41a0ac40 > > > db> > > >=20 > > > Does this shed any light for someone with more knowledge here? My > > > gut feeling is there is some endianness issue at play, the same > > > nullfs usage works for me flawlessly on both i386 and amd64 > > > systems, so it could not be 32 vs 64 bit issue at least. > > >=20 > > > At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function > > > void vgonel(struct vnode *vp) > > >=20 > > > VI_LOCK(vp); > > > vp->v_vnlock =3D &vp->v_lock; > > > vp->v_op =3D &dead_vnodeops; > > > vp->v_tag =3D "none"; > > > vp->v_type =3D VBAD; > > > } > > >=20 > > > so the question seems to be reduced to 'why is vp null?' or is my > > > small attempt on analyse flawed... >=20 > > I do not think that the vp is null. It more look like the *vp memory > > was zeroed. This has very low chances of being related to endianess, > > and more like a kernel memory corruption. > >=20 > > Take a dump and print the content of *vp. >=20 > How could I look into memory? I found page > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-onlin= e-ddb.html > and I can see registers (show reg), use x with absolute addresses, but > something like 'x vp' tells just 'Symbol not known' - should I somehow > load symbol table into memory? But backtrace shows function names... or > should I somehow modify GENERIC kernel to include more debugging info? > Kernel debugging is a bit new for me, even if I can write simple > modification into kernel, but only in some special (and narrow) area of > code... You shall/could take a dump and then use kgdb to look at *vp. If doing from ddb, you need to look at the disassembly of the function to undestand where to find the vp (probably in some register). --Thv7PGoFpDPJ7Oar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8gYTEACgkQC3+MBN1Mb4jx7QCbB3Bznpl2RlD4mrckCUg30GF1 aI0AoO3f+4nskcspPvcX+nm2zU4Nf5Cg =2XNh -----END PGP SIGNATURE----- --Thv7PGoFpDPJ7Oar-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 20:29:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB6D106566C for ; Wed, 25 Jan 2012 20:29:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9844C8FC08 for ; Wed, 25 Jan 2012 20:29:47 +0000 (UTC) Received: by lahj13 with SMTP id j13so312649lah.13 for ; Wed, 25 Jan 2012 12:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-gm-message-state:content-type:content-transfer-encoding; bh=HpRNIp3RIFkR3nJ2i3XoYOZUFoYI0u3TMjcKuCadfpM=; b=MkDekKWGUQAF5HMjxODq2UOQ4Lo6cIsi7nMKFbQX3w3Yp6uLzA2sBYHqsARwJDJYXO e4o4/zh8OdM7pIpgfiSzgk02HyNxYQYaNYkqD4SUK2n6sS8s9y0GSJy80ns03DMLzUcJ S80XH0GxKgjjHk4MkyjGQ1oLyHEtEX+zEu/UU= Received: by 10.152.111.229 with SMTP id il5mr7623836lab.19.1327523386112; Wed, 25 Jan 2012 12:29:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.196 with HTTP; Wed, 25 Jan 2012 12:29:15 -0800 (PST) In-Reply-To: <20120125205041.26aeef85@atom.dino.sk> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> From: Eitan Adler Date: Wed, 25 Jan 2012 15:29:15 -0500 Message-ID: To: Milan Obuch X-Gm-Message-State: ALoCoQlYRX2Cu+iz/5v4Gz0Kb61o5eShGz996mHMSN2Z406z6cubuM/uPrEkneWjsDOUsPqC/yyj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:29:49 -0000 On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuch wrot= e: > On Wed, 25 Jan 2012 14:21:23 +0200 > Kostik Belousov wrote: > >> On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: >> > Hi, >> > > > [ snip ] > >> > This does not work with powerpc for me. With sources csup'ped this >> > morning, full system rebuild with GENERIC kernel, it is enough for >> > me to issue >> > >> > mount_nullfs /data/src10 /usr/src >> > csup /usr/share/examples/cvsup/standard-supfile >> > >> > and system panic occurs, with following on system console: >> > >> > panic: mtx_lock() of spin mutex (null) >> > @ /usr/src/sys/kern/vfs_subr.c:2670 cpuid =3D 0 >> > KDB: enter: panic >> > [ thread pid 1442 tid 100095 ] >> > Stopped at 0x40f734: addi r0, r0, 0x0 >> > db> >> > >> > At this point, I am able to interact with system, the question for >> > me is what I want to get from it :) I tried bt with following >> > result: >> > >> > Tracing pid 1442 tid 100095 td 0x2d6b000 >> > 0xe22c26d0: at panic+0x274 >> > 0xe22c2730: at _mtx_lock_flags+0xc4 >> > 0xe22c2760: at vgonel+0x330 >> > 0xe22c27b0: at vrecycle+0x54 >> > 0xe22c27d0: at null_inactive+0x30 >> > 0xe22c27f0: at VOP_INACTIVE_APV+0xdc >> > 0xe22c2810: at vinactive+0x98 >> > 0xe22c2850: at vputx+0x344 >> > 0xe22c28a0: at vput+0x18 >> > 0xe22c28c0: at kern_statat_vnhook+0x108 >> > 0xe22c29d0: at kern_statat+0x18 >> > 0xe22c29f0: at kern_lstat+0x2c >> > 0xe22c2a10: at sys_lstat+0x30 >> > 0xe22c2a90: at trap+0x388 >> > 0xe22c2b60: at powerpc_interrupt+0x108 >> > 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=3D0xd032 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r1=3D0xffaf9a70 cr=3D0x28004= 044 xer=3D0x20000000 >> > ctr=3D0x41a0ac40 >> > db> >> > >> > Does this shed any light for someone with more knowledge here? My >> > gut feeling is there is some endianness issue at play, the same >> > nullfs usage works for me flawlessly on both i386 and amd64 >> > systems, so it could not be 32 vs 64 bit issue at least. >> > >> > At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function >> > void vgonel(struct vnode *vp) >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 VI_LOCK(vp); >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_vnlock =3D &vp->v_lock; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_op =3D &dead_vnodeops; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_tag =3D "none"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_type =3D VBAD; >> > } >> > >> > so the question seems to be reduced to 'why is vp null?' or is my >> > small attempt on analyse flawed... > >> I do not think that the vp is null. It more look like the *vp memory >> was zeroed. This has very low chances of being related to endianess, >> and more like a kernel memory corruption. >> >> Take a dump and print the content of *vp. > > How could I look into memory? I found page > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-onlin= e-ddb.html > and I can see registers (show reg), use x with absolute addresses, but > something like 'x vp' tells just 'Symbol not known' - should I somehow > load symbol table into memory? But backtrace shows function names... or > should I somehow modify GENERIC kernel to include more debugging info? > Kernel debugging is a bit new for me, even if I can write simple > modification into kernel, but only in some special (and narrow) area of > code... >From ddb write 'call doadump'. Provided you have a proper dump device set up in rc.conf it should work. You could then use kgdb from a running computer to analyze the dump in more detail. --=20 Eitan Adler From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:05:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE0A106564A for ; Wed, 25 Jan 2012 21:05:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48C728FC08 for ; Wed, 25 Jan 2012 21:05:05 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0PL4x1P085600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0PL4xms014243; Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0PL4xau014242; Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 23:04:59 +0200 From: Kostik Belousov To: Andreas Tobler Message-ID: <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> <4F206D6A.3030302@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s3R87C3fwYeCSZ0b" Content-Disposition: inline In-Reply-To: <4F206D6A.3030302@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Eitan Adler , freebsd-current@freebsd.org, Milan Obuch Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:05:06 -0000 --s3R87C3fwYeCSZ0b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 10:00:26PM +0100, Andreas Tobler wrote: > On 25.01.12 21:29, Eitan Adler wrote: > >On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuch = =20 > >wrote: > >>On Wed, 25 Jan 2012 14:21:23 +0200 > >>Kostik Belousov wrote: > >> > >>>On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: > >>>>Hi, > >>>> > >> > >>[ snip ] > >> > >>>>This does not work with powerpc for me. With sources csup'ped this > >>>>morning, full system rebuild with GENERIC kernel, it is enough for > >>>>me to issue > >>>> > >>>>mount_nullfs /data/src10 /usr/src > >>>>csup /usr/share/examples/cvsup/standard-supfile > >>>> > >>>>and system panic occurs, with following on system console: > >>>> > >>>>panic: mtx_lock() of spin mutex (null) > >>>>@ /usr/src/sys/kern/vfs_subr.c:2670 cpuid =3D 0 > >>>>KDB: enter: panic > >>>>[ thread pid 1442 tid 100095 ] > >>>>Stopped at 0x40f734: addi r0, r0, 0x0 > >>>>db> > >>>> > >>>>At this point, I am able to interact with system, the question for > >>>>me is what I want to get from it :) I tried bt with following > >>>>result: > >>>> > >>>>Tracing pid 1442 tid 100095 td 0x2d6b000 > >>>>0xe22c26d0: at panic+0x274 > >>>>0xe22c2730: at _mtx_lock_flags+0xc4 > >>>>0xe22c2760: at vgonel+0x330 > >>>>0xe22c27b0: at vrecycle+0x54 > >>>>0xe22c27d0: at null_inactive+0x30 > >>>>0xe22c27f0: at VOP_INACTIVE_APV+0xdc > >>>>0xe22c2810: at vinactive+0x98 > >>>>0xe22c2850: at vputx+0x344 > >>>>0xe22c28a0: at vput+0x18 > >>>>0xe22c28c0: at kern_statat_vnhook+0x108 > >>>>0xe22c29d0: at kern_statat+0x18 > >>>>0xe22c29f0: at kern_lstat+0x2c > >>>>0xe22c2a10: at sys_lstat+0x30 > >>>>0xe22c2a90: at trap+0x388 > >>>>0xe22c2b60: at powerpc_interrupt+0x108 > >>>>0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=3D0xd032 > >>>> r1=3D0xffaf9a70 cr=3D0x28004044 xer=3D0x20000000 > >>>>ctr=3D0x41a0ac40 > >>>>db> > >>>> > >>>>Does this shed any light for someone with more knowledge here? My > >>>>gut feeling is there is some endianness issue at play, the same > >>>>nullfs usage works for me flawlessly on both i386 and amd64 > >>>>systems, so it could not be 32 vs 64 bit issue at least. > >>>> > >>>>At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function > >>>>void vgonel(struct vnode *vp) > >>>> > >>>> VI_LOCK(vp); > >>>> vp->v_vnlock =3D&vp->v_lock; > >>>> vp->v_op =3D&dead_vnodeops; > >>>> vp->v_tag =3D "none"; > >>>> vp->v_type =3D VBAD; > >>>>} > >>>> > >>>>so the question seems to be reduced to 'why is vp null?' or is my > >>>>small attempt on analyse flawed... > >> > >>>I do not think that the vp is null. It more look like the *vp memory > >>>was zeroed. This has very low chances of being related to endianess, > >>>and more like a kernel memory corruption. > >>> > >>>Take a dump and print the content of *vp. > >> > >>How could I look into memory? I found page > >>http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-onl= ine-ddb.html > >>and I can see registers (show reg), use x with absolute addresses, but > >>something like 'x vp' tells just 'Symbol not known' - should I somehow > >>load symbol table into memory? But backtrace shows function names... or > >>should I somehow modify GENERIC kernel to include more debugging info? > >>Kernel debugging is a bit new for me, even if I can write simple > >>modification into kernel, but only in some special (and narrow) area of > >>code... > > > >>From ddb write 'call doadump'. Provided you have a proper dump device > >set up in rc.conf it should work. You could then use kgdb from a > >running computer to analyze the dump in more detail. >=20 > This only works if your target is booke, AIM (Apple based machines) do=20 > not have the 'call doadump' implemented yet. It is somewhere on my long= =20 > todo list. FWIW, it is not 'call doadump', it is just 'dump' for some time. I think calling doadump does not work. --s3R87C3fwYeCSZ0b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8gbnoACgkQC3+MBN1Mb4icKQCfTcTE4D22DMGCkadCIzIlQTD6 d5EAoKHC/EO/ub3Fbr55HqeOlmkpP74L =q86O -----END PGP SIGNATURE----- --s3R87C3fwYeCSZ0b-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:33:11 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C0C106566B for ; Wed, 25 Jan 2012 21:33:11 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9728FC15 for ; Wed, 25 Jan 2012 21:33:10 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id q0PKsZ8Q075079; Wed, 25 Jan 2012 21:54:37 +0100 (CET) (envelope-from andreast@FreeBSD.org) Message-ID: <4F206D6A.3030302@FreeBSD.org> Date: Wed, 25 Jan 2012 22:00:26 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Eitan Adler References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Kostik Belousov , freebsd-current@FreeBSD.org, Milan Obuch Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:33:12 -0000 On 25.01.12 21:29, Eitan Adler wrote: > On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuch wrote: >> On Wed, 25 Jan 2012 14:21:23 +0200 >> Kostik Belousov wrote: >> >>> On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: >>>> Hi, >>>> >> >> [ snip ] >> >>>> This does not work with powerpc for me. With sources csup'ped this >>>> morning, full system rebuild with GENERIC kernel, it is enough for >>>> me to issue >>>> >>>> mount_nullfs /data/src10 /usr/src >>>> csup /usr/share/examples/cvsup/standard-supfile >>>> >>>> and system panic occurs, with following on system console: >>>> >>>> panic: mtx_lock() of spin mutex (null) >>>> @ /usr/src/sys/kern/vfs_subr.c:2670 cpuid = 0 >>>> KDB: enter: panic >>>> [ thread pid 1442 tid 100095 ] >>>> Stopped at 0x40f734: addi r0, r0, 0x0 >>>> db> >>>> >>>> At this point, I am able to interact with system, the question for >>>> me is what I want to get from it :) I tried bt with following >>>> result: >>>> >>>> Tracing pid 1442 tid 100095 td 0x2d6b000 >>>> 0xe22c26d0: at panic+0x274 >>>> 0xe22c2730: at _mtx_lock_flags+0xc4 >>>> 0xe22c2760: at vgonel+0x330 >>>> 0xe22c27b0: at vrecycle+0x54 >>>> 0xe22c27d0: at null_inactive+0x30 >>>> 0xe22c27f0: at VOP_INACTIVE_APV+0xdc >>>> 0xe22c2810: at vinactive+0x98 >>>> 0xe22c2850: at vputx+0x344 >>>> 0xe22c28a0: at vput+0x18 >>>> 0xe22c28c0: at kern_statat_vnhook+0x108 >>>> 0xe22c29d0: at kern_statat+0x18 >>>> 0xe22c29f0: at kern_lstat+0x2c >>>> 0xe22c2a10: at sys_lstat+0x30 >>>> 0xe22c2a90: at trap+0x388 >>>> 0xe22c2b60: at powerpc_interrupt+0x108 >>>> 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=0xd032 >>>> r1=0xffaf9a70 cr=0x28004044 xer=0x20000000 >>>> ctr=0x41a0ac40 >>>> db> >>>> >>>> Does this shed any light for someone with more knowledge here? My >>>> gut feeling is there is some endianness issue at play, the same >>>> nullfs usage works for me flawlessly on both i386 and amd64 >>>> systems, so it could not be 32 vs 64 bit issue at least. >>>> >>>> At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function >>>> void vgonel(struct vnode *vp) >>>> >>>> VI_LOCK(vp); >>>> vp->v_vnlock =&vp->v_lock; >>>> vp->v_op =&dead_vnodeops; >>>> vp->v_tag = "none"; >>>> vp->v_type = VBAD; >>>> } >>>> >>>> so the question seems to be reduced to 'why is vp null?' or is my >>>> small attempt on analyse flawed... >> >>> I do not think that the vp is null. It more look like the *vp memory >>> was zeroed. This has very low chances of being related to endianess, >>> and more like a kernel memory corruption. >>> >>> Take a dump and print the content of *vp. >> >> How could I look into memory? I found page >> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html >> and I can see registers (show reg), use x with absolute addresses, but >> something like 'x vp' tells just 'Symbol not known' - should I somehow >> load symbol table into memory? But backtrace shows function names... or >> should I somehow modify GENERIC kernel to include more debugging info? >> Kernel debugging is a bit new for me, even if I can write simple >> modification into kernel, but only in some special (and narrow) area of >> code... > >> From ddb write 'call doadump'. Provided you have a proper dump device > set up in rc.conf it should work. You could then use kgdb from a > running computer to analyze the dump in more detail. This only works if your target is booke, AIM (Apple based machines) do not have the 'call doadump' implemented yet. It is somewhere on my long todo list. Gruss, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:34:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58492106566C; Wed, 25 Jan 2012 21:34:08 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 94F4C8FC1C; Wed, 25 Jan 2012 21:34:07 +0000 (UTC) Received: by lahj13 with SMTP id j13so356801lah.13 for ; Wed, 25 Jan 2012 13:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-gm-message-state:content-type; bh=VWSDU88Id6q5P5ZyG9pGx0bFOqQ8RZXdM68aSp+R+r8=; b=GuuaLHLGN2itPaMkmM5lGX+nXdYrOoH1w0qANrP60u+2o0ZCE7x84TkbxAu2Rk/8Kh tE49yWPqAEY70RM+0s+QHT2hnN46SDyQxnLmi13efJxden4RFgPIPSnq1XXF5eBkhzbZ hsQoRWr6c8dQHYKZIXfpINWnb7U9tyo2bsV2Q= Received: by 10.112.82.226 with SMTP id l2mr4812883lby.102.1327527246132; Wed, 25 Jan 2012 13:34:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.196 with HTTP; Wed, 25 Jan 2012 13:33:35 -0800 (PST) In-Reply-To: <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> <4F206D6A.3030302@FreeBSD.org> <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> From: Eitan Adler Date: Wed, 25 Jan 2012 16:33:35 -0500 Message-ID: To: Kostik Belousov X-Gm-Message-State: ALoCoQn45bCBz8rmmWOimFKx96aqbtxH7gRY9KTIXzTTBqU4X4fL88iUMCt5JxVoR9wejYMf7mgG Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Andreas Tobler , Milan Obuch Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:34:08 -0000 On Wed, Jan 25, 2012 at 4:04 PM, Kostik Belousov wrote: > FWIW, it is not 'call doadump', it is just 'dump' for some time. > I think calling doadump does not work. Worked for me about a month ago but I could obviously be mistaken. :) Thanks for correcting me. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 20:50:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7BC01065670 for ; Wed, 25 Jan 2012 20:50:29 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5298FC23 for ; Wed, 25 Jan 2012 20:50:29 +0000 (UTC) Received: by qadz30 with SMTP id z30so1282907qad.13 for ; Wed, 25 Jan 2012 12:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Wl+mPu7TfsrKbRGgEoVjbQ9bN8maf3dhXJdIKJQeohA=; b=QNRNxQNwm9EKPMK3psZw3EmqHdFF1t5wtuw5YRaUSVVZ6Dg0D2bAfjFq+pjSobDfYn 2pSYLV5hFZy69xl8FsJCh0xE2VR426CaRcvkmDdxkGD8Po0q36FxL+uObeXpfuI656X/ DI3sudtRFJdr8vim3I2p37k+VTUeirPadk2mA= MIME-Version: 1.0 Received: by 10.224.180.67 with SMTP id bt3mr1805139qab.6.1327523170093; Wed, 25 Jan 2012 12:26:10 -0800 (PST) Received: by 10.229.223.135 with HTTP; Wed, 25 Jan 2012 12:26:09 -0800 (PST) Date: Wed, 25 Jan 2012 15:26:09 -0500 Message-ID: From: Kim Culhan To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=20cf303b3a2dfc0a6904b76012b9 X-Mailman-Approved-At: Wed, 25 Jan 2012 21:47:27 +0000 Cc: Subject: msk0: watchdog timeout interface hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:50:29 -0000 --20cf303b3a2dfc0a6904b76012b9 Content-Type: text/plain; charset=ISO-8859-1 Running 10-curent from 01-20-12 the msk0 interface hung, on the console: msk0: watchdog timeout msk0: prefetch unit stuck? msk0: initialization failed: no memory for Rx buffers Verbose boot dmesg output attached. Any help is greatly appreciated. -kim --20cf303b3a2dfc0a6904b76012b9 Content-Type: application/octet-stream; name="acer5570_2997_msk0_dmesg.out" Content-Disposition: attachment; filename="acer5570_2997_msk0_dmesg.out" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gxusylzl0 TVAgQ29uZmlndXJhdGlvbiBUYWJsZSB2ZXJzaW9uIDEuNCBmb3VuZCBhdCAweGMwMDllNTcxClRh YmxlICdGQUNQJyBhdCAweDdmNjlhYzJhClRhYmxlICdBUElDJyBhdCAweDdmNjlhZDFlCkFQSUM6 IEZvdW5kIHRhYmxlIGF0IDB4N2Y2OWFkMWUKQVBJQzogVXNpbmcgdGhlIE1BRFQgZW51bWVyYXRv ci4KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDA6IGVuYWJsZWQKU01QOiBBZGRl ZCBDUFUgMCAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDEgQUNQSSBJRCAxOiBlbmFibGVk ClNNUDogQWRkZWQgQ1BVIDEgKEFQKQpDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUgRnJlZUJT RCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5 ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5 IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3Rl cmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDEwLjAtQ1VS UkVOVCAjMDogV2VkIEphbiAyNSAxNDowMToxMyBVVEMgMjAxMgogICAgcm9vdEBidWlsZC1pMzg2 LWZic2QtMi5hbGxic2Qub3JnOi91c3Ivb2JqL2kzODYuaTM4Ni91c3Ivc3JjL3N5cy9HRU5FUklD IGkzODYKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVy Zm9ybWFuY2UuClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAw eGMxNDdlMDAwLgpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMTczMzQzOTY5 NSBIegpDUFU6IEdlbnVpbmUgSW50ZWwoUikgQ1BVICAgICAgICAgICBUMjA4MCAgQCAxLjczR0h6 ICgxNzMzLjQ0LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJ ZCA9IDB4NmVjICBGYW1pbHkgPSA2ICBNb2RlbCA9IGUgIFN0ZXBwaW5nID0gMTIKICBGZWF0dXJl cz0weGJmZTlmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIs U1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHhjMTg5PFNTRTMsTU9OLEVTVCxUTTIseFRQUixQ RENNPgogIEFNRCBGZWF0dXJlcz0weDEwMDAwMDxOWD4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50 LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCgpJbnN0cnVjdGlvbiBUTEI6IDQgS0IgUGFnZXMsIDQt d2F5IHNldCBhc3NvY2lhdGl2ZSwgMTI4IGVudHJpZXMKRGF0YSBUTEI6IDQgS0IgUGFnZXMsIDQt d2F5IHNldCBhc3NvY2lhdGl2ZSwgMTI4IGVudHJpZXMKSW5zdHJ1Y3Rpb24gVExCOiA0IE1CIHBh Z2VzLCBmdWxseSBhc3NvY2lhdGl2ZSwgMiBlbnRyaWVzCjJuZC1sZXZlbCBjYWNoZTogMSBNQiwg NC13YXkgc2V0IGFzc29jaWF0aXZlLCA2NC1ieXRlIGxpbmUgc2l6ZQoxc3QtbGV2ZWwgaW5zdHJ1 Y3Rpb24gY2FjaGU6IDMyIEtCLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUsIDY0IGJ5dGUgbGluZSBz aXplCkRhdGEgVExCOiA0IE1CIFBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRpdmUsIDggZW50cmll cwoxc3QtbGV2ZWwgZGF0YSBjYWNoZTogMzIgS0IsIDgtd2F5IHNldCBhc3NvY2lhdGl2ZSwgNjQg Ynl0ZSBsaW5lIHNpemUKTDIgY2FjaGU6IDEwMjQga2J5dGVzLCA0LXdheSBhc3NvY2lhdGl2ZSwg NjQgYnl0ZXMvbGluZQpyZWFsIG1lbW9yeSAgPSAyMTQ3NDgzNjQ4ICgyMDQ4IE1CKQpQaHlzaWNh bCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5Y2Zm ZiwgNjM4OTc2IGJ5dGVzICgxNTYgcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAw MDAwMDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDE4MjYwMDAg LSAweDAwMDAwMDAwN2QyNGNmZmYsIDIwNzQyNDMwNzIgYnl0ZXMgKDUwNjQwNyBwYWdlcykKYXZh aWwgbWVtb3J5ID0gMjA3MjMyNjE0NCAoMTk3NiBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFs aXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxJTlRFTCAgQ0FMSVNUR0E+CklOVFI6IEFkZGluZyBs b2NhbCBBUElDIDEgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl bSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCAyIGNvcmUocykK IGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCmJpb3MzMjog Rm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGY2NjAwCmJpb3Mz MjogRW50cnkgPSAweGZkNDYwIChjMDBmZDQ2MCkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlvczog UENJIEJJT1MgZW50cnkgYXQgMHhmZDQ2MCsweDI2MgpwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBk YXRhIGF0IDB4YzAwZjY2YTAKcG5wYmlvczogRW50cnkgPSBmMDAwMDphY2NkICBSZXYgPSAxLjAK T3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgpBUElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwCkFQ SUM6IENQVSAxIGhhcyBBQ1BJIElEIDEKVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVwIGNwdSAx CkFDUEk6IFJTRFAgMHhmNjY1MCAwMDAyNCAodjAyIFBUTFREICkKQUNQSTogWFNEVCAweDdmNjkx MWYzIDAwMDY0ICh2MDEgQUNSU1lTIEFDUlBSRENUIDA2MDQwMDAwICBMVFAgMDAwMDAwMDApCkFD UEk6IEZBQ1AgMHg3ZjY5YWMyYSAwMDBGNCAodjAzIElOVEVMICBDQUxJU1RHQSAwNjA0MDAwMCBB TEFOIDAwMDAwMDAxKQpBQ1BJOiBEU0RUIDB4N2Y2OTFmNzggMDhDM0UgKHYwMiBJTlRFTCAgQ0FM SVNUR0EgMDYwNDAwMDAgTVNGVCAwMzAwMDAwMCkKQUNQSTogRkFDUyAweDdmNjliZmMwIDAwMDQw CkFDUEk6IEFQSUMgMHg3ZjY5YWQxZSAwMDA2OCAodjAxIElOVEVMICBDQUxJU1RHQSAwNjA0MDAw MCBMT0hSIDAwMDAwMDVBKQpBQ1BJOiBIUEVUIDB4N2Y2OWFkODYgMDAwMzggKHYwMSBJTlRFTCAg Q0FMSVNUR0EgMDYwNDAwMDAgTE9IUiAwMDAwMDA1QSkKQUNQSTogTUNGRyAweDdmNjlhZGJlIDAw MDNDICh2MDEgSU5URUwgIENBTElTVEdBIDA2MDQwMDAwIExPSFIgMDAwMDAwNUEpCkFDUEk6IEFQ SUMgMHg3ZjY5YWRmYSAwMDA2OCAodjAxIFBUTFREICA/IEFQSUMgICAwNjA0MDAwMCAgTFRQIDAw MDAwMDAwKQpBQ1BJOiBCT09UIDB4N2Y2OWFlNjIgMDAwMjggKHYwMSBQVExURCAgJFNCRlRCTCQg MDYwNDAwMDAgIExUUCAwMDAwMDAwMSkKQUNQSTogU0xJQyAweDdmNjlhZThhIDAwMTc2ICh2MDEg QUNSU1lTIEFDUlBSRENUIDA2MDQwMDAwIGFjZXIgMDAwMDAwMDApCkFDUEk6IFNTRFQgMHg3ZjY5 MTI1NyAwMDRFNiAodjAxICBQbVJlZiAgICBDcHVQbSAwMDAwMzAwMCBJTlRMIDIwMDUwNjI0KQpN QURUOiBGb3VuZCBJTyBBUElDIElEIDEsIEludGVycnVwdCAwIGF0IDB4ZmVjMDAwMDAKaW9hcGlj MDogQ2hhbmdpbmcgQVBJQyBJRCB0byAxCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEn cyAtPiBpbnRwaW4gMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBpcnEgMgpp b2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1BRFQ6IEludGVycnVwdCBvdmVycmlk ZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCmxhcGlj MDogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGlj MDogTElOVDEgcG9sYXJpdHk6IGhpZ2gKbGFwaWMxOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBp YzE6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWMxOiBMSU5UMSBwb2xhcml0eTogaGlnaAppb2Fw aWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmNwdTAgQlNQOgogICAg IElEOiAweDAwMDAwMDAwICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6IDB4 ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAw MDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAw MDAgZXJyOiAweDAwMDAwMGYwIHBtYzogMHgwMDAxMDQwMApzbmRfdW5pdF9pbml0KCkgdT0weDAw ZmY4MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgwMDAwMDNmZiBbMTAyNF0KZmVlZGVy X3JlZ2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3ZjaGFucz0xNiBsYXRlbmN5PTUgZmVl ZGVyX3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYwMDAgZmVlZGVyX3JhdGVfcm91bmQ9 MjUKd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBh dCBrYmRtdXgwCm1lbTogPG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQK bmZzbG9jazogcHNldWRvLWRldmljZQpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpp bzogPEkvTz4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+CmhwdHJy OiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIKY3RsOiBD QU0gVGFyZ2V0IExheWVyIGxvYWRlZAphY3BpMDogPEFDUlNZUyBBQ1JQUkRDVD4gb24gbW90aGVy Ym9hcmQKUENJZTogTWVtb3J5IE1hcHBlZCBjb25maWd1cmF0aW9uIGJhc2UgQCAweGUwMDAwMDAw CnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDkgKElT QSBJUlEgOSkgdG8gbGFwaWMgMCB2ZWN0b3IgNDgKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQp CmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGM1YTc4MDAwIHBhIDB4MTAwMAp1bmtub3duOiBJL08g cmFuZ2Ugbm90IHN1cHBvcnRlZApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBp b21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgaXJxIDAsOCBvbiBhY3BpMApocGV0MDogdmVuZG9y IDB4ODA4NiwgcmV2IDB4MSwgMTQzMTgxODBIeiA2NGJpdCwgMyB0aW1lcnMsIGxlZ2FjeSByb3V0 ZQpocGV0MDogIHQwOiBpcnFzIDB4MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6 ICB0MTogaXJxcyAweDAwZjAwMDAwICgwKQpocGV0MDogIHQyOiBpcnFzIDB4MDBmMDA4MDAgKDAp ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5NTAKaW9h cGljMDogcm91dGluZyBpbnRwaW4gMjAgKFBDSSBJUlEgMjApIHRvIGxhcGljIDAgdmVjdG9yIDQ5 CkV2ZW50IHRpbWVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTAKRXZl bnQgdGltZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQg dGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKQUNQSSB0aW1l cjogMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIC0+IDEwClRpbWVjb3Vu dGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFjcGlfdGlt ZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24g YWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBTU0RUIDB4N2Y2OTFjNzggMDAy MzggKHYwMSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1MDYyNCkKQUNQSTogRHlu YW1pYyBPRU0gVGFibGUgTG9hZDoKQUNQSTogU1NEVCAwIDAwMjM4ICh2MDEgIFBtUmVmICBDcHUw SXN0IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpCkFDUEk6IFNTRFQgMHg3ZjY5MTczZCAwMDRCNiAo djAxICBQbVJlZiAgQ3B1MENzdCAwMDAwMzAwMSBJTlRMIDIwMDUwNjI0KQpBQ1BJOiBEeW5hbWlj IE9FTSBUYWJsZSBMb2FkOgpBQ1BJOiBTU0RUIDAgMDA0QjYgKHYwMSAgUG1SZWYgIENwdTBDc3Qg MDAwMDMwMDEgSU5UTCAyMDA1MDYyNCkKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBT U0RUIDB4N2Y2OTFlYjAgMDAwQzggKHYwMSAgUG1SZWYgIENwdTFJc3QgMDAwMDMwMDAgSU5UTCAy MDA1MDYyNCkKQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKQUNQSTogU1NEVCAwIDAwMEM4 ICh2MDEgIFBtUmVmICBDcHUxSXN0IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpCkFDUEk6IFNTRFQg MHg3ZjY5MWJmMyAwMDA4NSAodjAxICBQbVJlZiAgQ3B1MUNzdCAwMDAwMzAwMCBJTlRMIDIwMDUw NjI0KQpBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2FkOgpBQ1BJOiBTU0RUIDAgMDAwODUgKHYw MSAgUG1SZWYgIENwdTFDc3QgMDAwMDMwMDAgSU5UTCAyMDA1MDYyNCkKYWNwaV9lYzA6IDxFbWJl ZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxNz4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKcGNpX2xp bmswOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgICAxMSAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDEwIDEyIDE0IDE1CiAgVmFsaWRhdGlv biAgICAgICAgICAwICAyNTUgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMiAxNCAxNQogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTAgMTIgMTQg MTUKcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFs IFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDExIDEyIDE0IDE1CiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMSAxMiAx NCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcg MTEgMTIgMTQgMTUKcGNpX2xpbmsyOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDEwIDEy IDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAxIDMgNCA1IDYg NyAxMCAxMiAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAz IDQgNSA2IDcgMTAgMTIgMTQgMTUKcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDEgMyA0IDUg NiA3IDExIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAx IDMgNCA1IDYgNyAxMSAxMiAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMSAzIDQgNSA2IDcgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAg IDEgMyA0IDUgNiA3IDEwIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBO ICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMiAxNCAxNQogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTAgMTIgMTQgMTUKcGNpX2xpbms1OiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAg IE4gICAgIDAgIDEgMyA0IDUgNiA3IDExIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAgMTEgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMSAxMiAxNCAxNQogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTEgMTIgMTQgMTUKcGNpX2xpbms2 OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgICAxMCAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDEwIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgMTAgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMCAxMiAxNCAxNQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTAgMTIgMTQgMTUK cGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFBy b2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDEgMyA0IDUgNiA3IDExIDEyIDE0IDE1CiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAxIDMgNCA1IDYgNyAxMSAxMiAxNCAx NQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMSAzIDQgNSA2IDcgMTEg MTIgMTQgMTUKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBv biBhY3BpMApwY2liMDogZGVjb2RpbmcgNCByYW5nZSAwLTB4Y2Y3CnBjaWIwOiBkZWNvZGluZyA0 IHJhbmdlIDB4ZDAwLTB4ZmZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGEwMDAwLTB4YmZm ZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhkMDAwMC0weGQzZmZmCnBjaWIwOiBkZWNvZGlu ZyAzIHJhbmdlIDB4ZDQwMDAtMHhkN2ZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGQ4MDAw LTB4ZGJmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhlMDAwMC0weGUzZmZmCnBjaWIwOiBk ZWNvZGluZyAzIHJhbmdlIDB4ODAwMDAwMDAtMHhmZWJmZmZmZgpwY2kwOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyN2EwLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwg ZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MDA2LCBzdGF0cmVnPTB4MjA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI3YTIsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1T SSBzdXBwb3J0cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGQwMzAwMDAwLCBzaXplIDE5LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGQwMzAwMDAwLTB4ZDAzN2ZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjI6MAoJbWFwWzE0XTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODAwLCBzaXplICAzLCBlbmFibGVkCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDE4MDAtMHgxODA3KSBmb3IgcmlkIDE0IG9mIHBjaTA6 MDoyOjAKCW1hcFsxOF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2Ug MHhjMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhj MDAwMDAwMC0weGNmZmZmZmZmKSBmb3IgcmlkIDE4IG9mIHBjaTA6MDoyOjAKCW1hcFsxY106IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQwNDAwMDAwLCBzaXplIDE4LCBlbmFibGVkCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQwNDAwMDAwLTB4ZDA0M2ZmZmYpIGZvciByaWQgMWMg b2YgcGNpMDowOjI6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEEKcGNpYjA6IHNs b3QgMiBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgyN2E2LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFz cz0wMy04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVn PTB4MDA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2Ug MHhkMDM4MDAwMCwgc2l6ZSAxOSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk MDM4MDAwMC0weGQwM2ZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MDoyOjEKZm91bmQtPgl2ZW5k b3I9MHg4MDg2LCBkZXY9MHgyN2Q4LCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9 MjcsIGZ1bmM9MAoJY2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn PTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1T SSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4ZDA0NDAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4ZDA0NDAwMDAtMHhkMDQ0M2ZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Mjc6MApw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNy5JTlRBCnBjaWIwOiBzbG90IDI3IElOVEEgaGFy ZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZDAsIHJldmlk PTB4MDIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwg aGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEw MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRBCnBjaWIwOiBzbG90IDI4IElOVEEgaGFyZHdp cmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZDIsIHJldmlkPTB4 MDIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0xCgljbGFzcz0wNi0wNC0wMCwgaGRy dHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRCCnBjaWIwOiBzbG90IDI4IElOVEIgaGFyZHdpcmVk IHRvIElSUSAxNwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZDQsIHJldmlkPTB4MDIK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0yCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRDCnBjaWIwOiBzbG90IDI4IElOVEMgaGFyZHdpcmVkIHRv IElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3YzgsIHJldmlkPTB4MDIKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHgxODIwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSA0ICgweDE4MjAtMHgxODNmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyOTowCnBjaWIwOiBt YXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQg dG8gSVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdjOSwgcmV2aWQ9MHgwMgoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDE4NDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDQgKDB4MTg0MC0weDE4NWYpIGZvciByaWQgMjAgb2YgcGNpMDowOjI5OjEKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQgpwY2liMDogc2xvdCAyOSBJTlRCIGhhcmR3aXJl ZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2NhLCByZXZpZD0weDAy Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4MTg2MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2Nh dGVkIHR5cGUgNCAoMHgxODYwLTB4MTg3ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MgpwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDCnBjaWIwOiBzbG90IDI5IElOVEMgaGFyZHdp cmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3Y2IsIHJldmlkPTB4 MDIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0zCgljbGFzcz0wYy0wMy0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWQsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODgwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSA0ICgweDE4ODAtMHgxODlmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyOTozCnBj aWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEQKcGNpYjA6IHNsb3QgMjkgSU5URCBoYXJk d2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdjYywgcmV2aWQ9 MHgwMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweGQwNjQ0MDAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGQwNjQ0MDAwLTB4ZDA2NDQzZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjI5OjcKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJl ZCB0byBJUlEgMjMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNDQ4LCByZXZpZD0weGUy Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2I5LCBy ZXZpZD0weDAyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyMTAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy N2M0LCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MgoJY2xhc3M9 MDEtMDEtODAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0w eDAyYjgsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MjU1Cglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDQgKDB4MWYwLTB4MWY3KSBmb3IgcmlkIDEwIG9mIHBjaTA6MDozMToyCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweDNmNi0weDNmNikgZm9yIHJpZCAxNCBvZiBwY2kwOjA6MzE6MgpwY2liMDog YWxsb2NhdGVkIHR5cGUgNCAoMHgxNzAtMHgxNzcpIGZvciByaWQgMTggb2YgcGNpMDowOjMxOjIK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4Mzc2LTB4Mzc2KSBmb3IgcmlkIDFjIG9mIHBjaTA6 MDozMToyCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4YjAsIHNp emUgIDQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4MThiMC0weDE4YmYpIGZv ciByaWQgMjAgb2YgcGNpMDowOjMxOjIKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2Rh LCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xhc3M9MGMt MDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAy ODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAKCW1hcFsyMF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MThjMCwgc2l6ZSAgNSwgZW5hYmxlZApw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxOGMwLTB4MThkZikgZm9yIHJpZCAyMCBvZiBwY2kw OjA6MzE6MwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCCnBjaWIwOiBzbG90IDMx IElOVEIgaGFyZHdpcmVkIHRvIElSUSAxOQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gcG9ydCAweDE4MDAtMHgxODA3IG1lbSAweGQwMzAwMDAwLTB4ZDAzN2ZmZmYsMHhjMDAwMDAw MC0weGNmZmZmZmZmLDB4ZDA0MDAwMDAtMHhkMDQzZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBv biBwY2kwCmFncDA6IDxJbnRlbCA4Mjk0NUdNICg5NDVHTSBHTUNIKSBTVkdBIGNvbnRyb2xsZXI+ IG9uIHZnYXBjaTAKYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAyNTZNLCBkZXRlY3RlZCA3OTMyayBz dG9sZW4gbWVtb3J5CnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBtZW0gMHhkMDM4 MDAwMC0weGQwM2ZmZmZmIGF0IGRldmljZSAyLjEgb24gcGNpMApoZGFjMDogPEludGVsIDgyODAx RyBIREEgQ29udHJvbGxlcj4gbWVtIDB4ZDA0NDAwMDAtMHhkMDQ0M2ZmZiBpcnEgMjIgYXQgZGV2 aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAxMjAxMTFfMDAw MQpoZGFjMDogQ29uZmlnIG9wdGlvbnM6IG9uPTB4MDAwMDAwMDAgb2ZmPTB4MDAwMDAwMDAKaGRh YzA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVjdG9ycyAoMSBzdXBwb3J0ZWQpCm1z aTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDUwCmhkYWMwOiB1 c2luZyBJUlEgMjU2IGZvciBNU0kKaGRhYzA6IENhcHM6IE9TUyA0LCBJU1MgNCwgQlNTIDAsIE5T RE8gMSwgNjRiaXQsIENPUkIgMjU2LCBSSVJCIDI1NgpwY2liMTogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIxOiBmYWlsZWQgdG8gYWxsb2Nh dGUgaW5pdGlhbCBJL08gcG9ydCB3aW5kb3c6IDAtMHhmZmYKcGNpYjE6IGZhaWxlZCB0byBhbGxv Y2F0ZSBpbml0aWFsIG1lbW9yeSB3aW5kb3c6IDAtMHhmZmZmZgpwY2liMTogZmFpbGVkIHRvIGFs bG9jYXRlIGluaXRpYWwgcHJlZmV0Y2ggd2luZG93OiAwLTB4ZmZmZmYKcGNpYjE6ICAgZG9tYWlu ICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIxOiAgIHN1Ym9y ZGluYXRlIGJ1cyAgIDIKcGNpYjE6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMjogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjEKcGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yCmZvdW5kLT4J dmVuZG9yPTB4MTFhYiwgZGV2PTB4NDM1MiwgcmV2aWQ9MHgxNAoJZG9tYWluPTAsIGJ1cz0yLCBz bG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDAwMCwgc3RhdHJlZz0weDQwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglp bnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJl bnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVt b3J5LCByYW5nZSA2NCwgYmFzZSAwLCBzaXplIDE0LCBtZW1vcnkgZGlzYWJsZWQKCW1hcFsxOF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDAsIHNpemUgIDgsIHBvcnQgZGlzYWJsZWQK cGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIxOiBzbG90IDAgSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE2Cm1za2MwOiA8TWFydmVsbCBZdWtvbiA4OEU4MDM4IEZhc3QgRXRoZXJu ZXQ+IGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ODAwMDAwMDAtMHg4MDBmZmZmZikgZm9yIHJpZCAyMCBvZiBwY2liMQpwY2liMTogYWxsb2Nh dGVkIGluaXRpYWwgbWVtb3J5IHdpbmRvdyBvZiAweDgwMDAwMDAwLTB4ODAwZmZmZmYKcGNpYjE6 IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ODAwMDAwMDAtMHg4MDAwM2ZmZikgZm9yIHJpZCAx MCBvZiBtc2tjMAptc2tjMDogTGF6eSBhbGxvY2F0aW9uIG9mIDB4NDAwMCBieXRlcyByaWQgMHgx MCB0eXBlIDMgYXQgMHg4MDAwMDAwMAptc2tjMDogTVNJIGNvdW50IDogMgptc2tjMDogYXR0ZW1w dGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgyIHN1cHBvcnRlZCkKbXNpOiByb3V0aW5n IE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTEKbXNrYzA6IHVzaW5nIElSUSAy NTcgZm9yIE1TSQptc2tjMDogUkFNIGJ1ZmZlciBzaXplIDogNEtCCm1za2MwOiBQb3J0IDAgOiBS eCBRdWV1ZSAyS0IoMHgwMDAwMDAwMDoweDAwMDAwN2ZmKQptc2tjMDogUG9ydCAwIDogVHggUXVl dWUgMktCKDB4MDAwMDA4MDA6MHgwMDAwMGZmZikKbXNrMDogPE1hcnZlbGwgVGVjaG5vbG9neSBH cm91cCBMdGQuIFl1a29uIEZFIElkIDB4YjcgUmV2IDB4MDE+IG9uIG1za2MwCm1zazA6IGRpc2Fi bGluZyBqdW1ibyBmcmFtZSBzdXBwb3J0Cm1zazA6IGJwZiBhdHRhY2hlZAptc2swOiBFdGhlcm5l dCBhZGRyZXNzOiAwMDoxYjoyNDo1OTo1Yjo3YQptaWlidXMwOiA8TUlJIGJ1cz4gb24gbXNrMApl MTAwMHBoeTA6IDxNYXJ2ZWxsIDg4RTMwODIgMTAvMTAwIEZhc3QgRXRoZXJuZXQgUEhZPiBQSFkg MCBvbiBtaWlidXMwCmUxMDAwcGh5MDogT1VJIDB4MDAwYWMyLCBtb2RlbCAweDAwMDgsIHJldi4g MwplMTAwMHBoeTA6ICBub25lLCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBi YXNlVFgtRkRYLCBhdXRvLCBhdXRvLWZsb3cKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBp cnEgMTcgYXQgZGV2aWNlIDI4LjEgb24gcGNpMApwY2liMjogZmFpbGVkIHRvIGFsbG9jYXRlIGlu aXRpYWwgSS9PIHBvcnQgd2luZG93OiAwLTB4ZmZmCnBjaWIyOiBmYWlsZWQgdG8gYWxsb2NhdGUg aW5pdGlhbCBtZW1vcnkgd2luZG93OiAwLTB4ZmZmZmYKcGNpYjI6IGZhaWxlZCB0byBhbGxvY2F0 ZSBpbml0aWFsIHByZWZldGNoIHdpbmRvdzogMC0weGZmZmZmCnBjaWIyOiAgIGRvbWFpbiAgICAg ICAgICAgIDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMjogICBzdWJvcmRpbmF0 ZSBidXMgICAzCnBjaWIyOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaTM6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIyCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Mwpmb3VuZC0+CXZlbmRv cj0weDE2OGMsIGRldj0weDAwMWMsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9Mywgc2xvdD0w LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgMSBtZXNzYWdlCglNU0ktWCBzdXBwb3J0cyAxIG1lc3NhZ2UgaW4gbWFwIDB4MTAK CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAwLCBzaXplIDE2LCBtZW1vcnkg ZGlzYWJsZWQKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDMuMC5JTlRBCnBjaWIyOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmF0aDA6IDxBdGhlcm9zIDU0MjQvMjQyND4gaXJxIDE3 IGF0IGRldmljZSAwLjAgb24gcGNpMwpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHg4MDEwMDAw MC0weDgwMWZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWIyCnBjaWIyOiBhbGxvY2F0ZWQgaW5pdGlh bCBtZW1vcnkgd2luZG93IG9mIDB4ODAxMDAwMDAtMHg4MDFmZmZmZgpwY2liMjogYWxsb2NhdGVk IG1lbW9yeSByYW5nZSAoMHg4MDEwMDAwMC0weDgwMTBmZmZmKSBmb3IgcmlkIDEwIG9mIGF0aDAK YXRoMDogTGF6eSBhbGxvY2F0aW9uIG9mIDB4MTAwMDAgYnl0ZXMgcmlkIDB4MTAgdHlwZSAzIGF0 IDB4ODAxMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIGxh cGljIDAgdmVjdG9yIDUyCmF0aDA6IDExYiByYXRlczogMU1icHMgMk1icHMgNS41TWJwcyAxMU1i cHMKYXRoMDogMTFnIHJhdGVzOiAxTWJwcyAyTWJwcyA1LjVNYnBzIDExTWJwcyA2TWJwcyA5TWJw cyAxMk1icHMgMThNYnBzIDI0TWJwcyAzNk1icHMgNDhNYnBzIDU0TWJwcwphdGgwOiBBUjI0MjUg bWFjIDE0LjIgUkY1NDI0IHBoeSA3LjAKYXRoMDogMkdIeiByYWRpbzogMHgwMDAwOyA1R0h6IHJh ZGlvOiAweDAwYTIKYXRoMDogVXNlIGh3IHF1ZXVlIDEgZm9yIFdNRV9BQ19CRSB0cmFmZmljCmF0 aDA6IFVzZSBodyBxdWV1ZSAwIGZvciBXTUVfQUNfQksgdHJhZmZpYwphdGgwOiBVc2UgaHcgcXVl dWUgMiBmb3IgV01FX0FDX1ZJIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDMgZm9yIFdNRV9B Q19WTyB0cmFmZmljCmF0aDA6IFVzZSBodyBxdWV1ZSA4IGZvciBDQUIgdHJhZmZpYwphdGgwOiBV c2UgaHcgcXVldWUgOSBmb3IgYmVhY29ucwphdGgwOiB1c2luZyBtdWx0aWNhc3Qga2V5IHNlYXJj aApwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxOCBhdCBkZXZpY2UgMjguMiBvbiBw Y2kwCnBjaWIzOiBmYWlsZWQgdG8gYWxsb2NhdGUgaW5pdGlhbCBJL08gcG9ydCB3aW5kb3c6IDAt MHhmZmYKcGNpYjM6IGZhaWxlZCB0byBhbGxvY2F0ZSBpbml0aWFsIG1lbW9yeSB3aW5kb3c6IDAt MHhmZmZmZgpwY2liMzogZmFpbGVkIHRvIGFsbG9jYXRlIGluaXRpYWwgcHJlZmV0Y2ggd2luZG93 OiAwLTB4ZmZmZmYKcGNpYjM6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMzogICBzZWNvbmRh cnkgYnVzICAgICA0CnBjaWIzOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjM6ICAgbm8gcHJl ZmV0Y2hlZCBkZWNvZGUKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpNDogZG9tYWlu PTAsIHBoeXNpY2FsIGJ1cz00CnVoY2kwOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJv bGxlciBVU0ItQT4gcG9ydCAweDE4MjAtMHgxODNmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBw Y2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIzIChQQ0kgSVJRIDIzKSB0byBsYXBpYyAwIHZl Y3RvciA1Mwp1c2J1czA6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1B PiBvbiB1aGNpMAp1c2J1czA6IGJwZiBhdHRhY2hlZAp1aGNpMDogdXNicGY6IEF0dGFjaGVkCnVo Y2kxOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweDE4 NDAtMHgxODVmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDE5IChQQ0kgSVJRIDE5KSB0byBsYXBpYyAwIHZlY3RvciA1NAp1c2J1czE6IDxJbnRl bCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2J1czE6IGJw ZiBhdHRhY2hlZAp1aGNpMTogdXNicGY6IEF0dGFjaGVkCnVoY2kyOiA8SW50ZWwgODI4MDFHIChJ Q0g3KSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweDE4NjAtMHgxODdmIGlycSAxOCBhdCBk ZXZpY2UgMjkuMiBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4 KSB0byBsYXBpYyAwIHZlY3RvciA1NQp1c2J1czI6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBj b250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1c2J1czI6IGJwZiBhdHRhY2hlZAp1aGNpMjogdXNi cGY6IEF0dGFjaGVkCnVoY2kzOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBV U0ItRD4gcG9ydCAweDE4ODAtMHgxODlmIGlycSAxNiBhdCBkZXZpY2UgMjkuMyBvbiBwY2kwCmlv YXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAwIHZlY3RvciA1 Ngp1c2J1czM6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBvbiB1 aGNpMwp1c2J1czM6IGJwZiBhdHRhY2hlZAp1aGNpMzogdXNicGY6IEF0dGFjaGVkCmVoY2kwOiA8 SW50ZWwgODI4MDFHQi9SIChJQ0g3KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQwNjQ0MDAw LTB4ZDA2NDQzZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAKdXNidXM0OiBFSENJIHZl cnNpb24gMS4wCnVzYnVzNDogPEludGVsIDgyODAxR0IvUiAoSUNINykgVVNCIDIuMCBjb250cm9s bGVyPiBvbiBlaGNpMAp1c2J1czQ6IGJwZiBhdHRhY2hlZAplaGNpMDogdXNicGY6IEF0dGFjaGVk CnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMDIwMDAwMC0weGQwMmZmZmZmKSBmb3IgcmlkIDIwIG9m IHBjaWI0CnBjaWI0OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1 cyAgICAgMTAKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTEKcGNpYjQ6ICAgbWVtb3J5IGRl Y29kZSAgICAgMHhkMDIwMDAwMC0weGQwMmZmZmZmCnBjaWI0OiAgIG5vIHByZWZldGNoZWQgZGVj b2RlCnBjaWI0OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTEwOiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liNApwY2kxMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xMApmb3VuZC0+ CXZlbmRvcj0weDEwNGMsIGRldj0weDgwMzksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MTAs IHNsb3Q9OSwgZnVuYz0wCgljbGFzcz0wNi0wNy0wMCwgaGRydHlwZT0weDAyLCBtZmRldj0xCglj bWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0 aW1lcj0weDMxICgxNDcwIG5zKSwgbWluZ250PTB4NDQgKDE3MDAwIG5zKSwgbWF4bGF0PTB4MDMg KDc1MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBE MiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 ZDAyMDQwMDAsIHNpemUgMTIsIG1lbW9yeSBkaXNhYmxlZApwY2liNDogYWxsb2NhdGVkIG1lbW9y eSByYW5nZSAoMHhkMDIwNDAwMC0weGQwMjA0ZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MTA6OTow CnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciAxMC45LklOVEEKcGNpYjQ6IHNsb3QgOSBJTlRBIGhh cmR3aXJlZCB0byBJUlEgMjAKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDNiLCByZXZp ZD0weDAwCglkb21haW49MCwgYnVzPTEwLCBzbG90PTksIGZ1bmM9MgoJY2xhc3M9MDEtODAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMTAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgzOSAoMTcxMCBucyksIG1pbmdudD0weDA3 ICgxNzUwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQwMjA1MDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWI0 OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGQwMjA1MDAwLTB4ZDAyMDVmZmYpIGZvciByaWQg MTAgb2YgcGNpMDoxMDo5OjIKcGNpYjQ6IG1hdGNoZWQgZW50cnkgZm9yIDEwLjkuSU5UQQpwY2li NDogc2xvdCA5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMApjYmIwOiA8UENJLUNhcmRCdXMgQnJp ZGdlPiBtZW0gMHhkMDIwNDAwMC0weGQwMjA0ZmZmIGlycSAyMCBhdCBkZXZpY2UgOS4wIG9uIHBj aTEwCmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJpdCBQQ0Nh cmQgYnVzPiBvbiBjYmIwCmNiYjA6IFBDSSBDb25maWd1cmF0aW9uIHNwYWNlOgogIDB4MDA6IDB4 ODAzOTEwNGMgMHgwMjEwMDAwNyAweDA2MDcwMDAwIDB4MDA4MjMxMTAgCiAgMHgxMDogMHhkMDIw NDAwMCAweDAyMDAwMGEwIDB4MjAwYjBiMGEgMHhmZmZmZjAwMCAKICAweDIwOiAweDAwMDAwMDAw IDB4ZmZmZmYwMDAgMHgwMDAwMDAwMCAweGZmZmZmZmZjIAogIDB4MzA6IDB4MDAwMDAwMDAgMHhm ZmZmZmZmYyAweDAwMDAwMDAwIDB4MDc0NDAxMTQgCiAgMHg0MDogMHgwMTEwMTAyNSAweDAwMDAw MDAxIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgMHgwMDAwMDAwMCAKICAweDgwOiAweDE4NDRkMDYwIDB4MDJkODAwMTkgMHgwMDE5MDAxNiAw eDAxMzIxYjIyIAogIDB4OTA6IDB4NjA2NjAyYzAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgCiAgMHhhMDogMHhmZTEyMDAwMSAweDAwYzAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAKICAweGIwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAog IDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhk MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGUwOiAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZjA6IDB4ZjQ4 YjM5MGYgMHg5NzAxOWFkMiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCnBjaTEwOiA8bWFzcyBzdG9y YWdlPiBhdCBkZXZpY2UgOS4yIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBi cmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0 YXBjaTA6IDxJbnRlbCBJQ0g3TSBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcs MHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgxOGIwLTB4MThiZiBhdCBkZXZpY2UgMzEuMiBvbiBw Y2kwCmF0YTA6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGF0YXBjaTAKaW9hcGljMDog cm91dGluZyBpbnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIGxhcGljIDAgdmVjdG9yIDU3CmF0YTE6 IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTAKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTUgKElTQSBJUlEgMTUpIHRvIGxhcGljIDAgdmVjdG9yIDU4CnBjaTA6IDxzZXJpYWwg YnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV9hY2Fk MDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBC YXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBv biBhY3BpMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmFjcGlfYnV0dG9u MTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFj cGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3NyBvbiBhY3BpMAph dHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAocmVzb2x1dGlvbiAxMDAw MDAwdXMsIGFkanVzdG1lbnQgMC41MDAwMDAwMDBzKQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA4 IChJU0EgSVJRIDgpIHRvIGxhcGljIDAgdmVjdG9yIDU5CkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1 ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4 NDMsMHg1MC0weDUzIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMx ODIgSHogcXVhbGl0eSAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIgKElTQSBJUlEgMCkgdG8g bGFwaWMgMCB2ZWN0b3IgNjAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDEwMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0 IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAw NDcKYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRr YmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDog cm91dGluZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byBsYXBpYyAwIHZlY3RvciA2MQphdGtiZDA6 IFtHSUFOVC1MT0NLRURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEKcHNtY3BucDA6IDxQ Uy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMApwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0 ZTowMDQ3CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gbGFwaWMgMCB2ZWN0b3IgNjIKcHNtMDogW0dJ QU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMC0w MCwgMiBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tl dCBzaXplOjMKcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCmV4X2lzYV9pZGVudGlmeSgp CmFoY19pc2FfcHJvYmUgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2Jl IDE6IGlvcG9ydCAweDFjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgMjogaW9wb3J0IDB4 MmMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSAzOiBpb3BvcnQgMHgzYzAwIGFsbG9jIGZh aWxlZAphaGNfaXNhX3Byb2JlIDQ6IGlvcG9ydCAweDRjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2Ff cHJvYmUgNTogaW9wb3J0IDB4NWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSA2OiBpb3Bv cnQgMHg2YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDc6IGlvcG9ydCAweDdjMDAgYWxs b2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgODogaW9wb3J0IDB4OGMwMCBhbGxvYyBmYWlsZWQKYWhj X2lzYV9wcm9iZSA5OiBpb3BvcnQgMHg5YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEw OiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDExOiBpb3BvcnQgMHhi YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEyOiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZh aWxlZAphaGNfaXNhX3Byb2JlIDEzOiBpb3BvcnQgMHhkYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNh X3Byb2JlIDE0OiBpb3BvcnQgMHhlYzAwIGFsbG9jIGZhaWxlZApwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMK cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMK cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMK UE5QIElkZW50aWZ5IGNvbXBsZXRlCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEwMDAwLTB4 YTA3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEwODAw LTB4YTBmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEx MDAwLTB4YTE3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGExODAwLTB4YTFmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGEyMDAwLTB4YTI3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGEyODAwLTB4YTJmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGEzMDAwLTB4YTM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGEzODAwLTB4YTNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGE0MDAwLTB4YTQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGE0ODAwLTB4YTRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGE1MDAwLTB4YTU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE1ODAwLTB4YTVmZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE2MDAwLTB4YTY3ZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE2ODAwLTB4YTZmZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE3MDAwLTB4YTc3ZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE3ODAwLTB4YTdmZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE4MDAwLTB4YTg3ZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE4ODAwLTB4YThmZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE5MDAwLTB4YTk3 ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE5ODAwLTB4 YTlmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFhMDAw LTB4YWE3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFh ODAwLTB4YWFmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGFiMDAwLTB4YWI3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGFiODAwLTB4YWJmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGFjMDAwLTB4YWM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGFjODAwLTB4YWNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGFkMDAwLTB4YWQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGFkODAwLTB4YWRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGFlMDAwLTB4YWU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGFlODAwLTB4YWVmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFmMDAwLTB4YWY3ZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFmODAwLTB4YWZmZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIwMDAwLTB4YjA3ZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIwODAwLTB4YjBmZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIxMDAwLTB4YjE3ZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIxODAwLTB4YjFmZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIyMDAwLTB4YjI3ZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIyODAwLTB4YjJm ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIzMDAwLTB4 YjM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIzODAw LTB4YjNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI0 MDAwLTB4YjQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGI0ODAwLTB4YjRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGI1MDAwLTB4YjU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGI1ODAwLTB4YjVmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGI2MDAwLTB4YjY3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGI2ODAwLTB4YjZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGI3MDAwLTB4Yjc3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGI3ODAwLTB4YjdmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGI4MDAwLTB4Yjg3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI4ODAwLTB4YjhmZmYpIGZvciByaWQgMCBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI5MDAwLTB4Yjk3ZmYpIGZvciByaWQgMCBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI5ODAwLTB4YjlmZmYpIGZvciByaWQgMCBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJhMDAwLTB4YmE3ZmYpIGZvciByaWQg MCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJhODAwLTB4YmFmZmYpIGZvciBy aWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJiMDAwLTB4YmI3ZmYpIGZv ciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJiODAwLTB4YmJmZmYp IGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJjMDAwLTB4YmM3 ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJjODAwLTB4 YmNmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJkMDAw LTB4YmQ3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJk ODAwLTB4YmRmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGJlMDAwLTB4YmU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGJlODAwLTB4YmVmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGJmMDAwLTB4YmY3ZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGJmODAwLTB4YmZmZmYpIGZvciByaWQgMCBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGQwMDAwLTB4ZDA3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGQwODAwLTB4ZDBmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGQxMDAwLTB4ZDE3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGQxODAwLTB4ZDFmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQyMDAwLTB4ZDI3ZmYpIGZvciByaWQgMSBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQyODAwLTB4ZDJmZmYpIGZvciByaWQgMSBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQzMDAwLTB4ZDM3ZmYpIGZvciByaWQgMSBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQzODAwLTB4ZDNmZmYpIGZvciByaWQg MSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0MDAwLTB4ZDQ3ZmYpIGZvciBy aWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0ODAwLTB4ZDRmZmYpIGZv ciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ1MDAwLTB4ZDU3ZmYp IGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ1ODAwLTB4ZDVm ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ2MDAwLTB4 ZDY3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ2ODAw LTB4ZDZmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ3 MDAwLTB4ZDc3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGQ3ODAwLTB4ZDdmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGQ4MDAwLTB4ZDg3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGQ4ODAwLTB4ZDhmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGQ5MDAwLTB4ZDk3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGQ5ODAwLTB4ZDlmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGRhMDAwLTB4ZGE3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGRhODAwLTB4ZGFmZmYpIGZvciByaWQgMSBvZiBvcm0wCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGRiMDAwLTB4ZGI3ZmYpIGZvciByaWQgMSBvZiBvcm0wCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRiODAwLTB4ZGJmZmYpIGZvciByaWQgMSBvZiBvcm0w CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUwMDAwLTB4ZTA3ZmYpIGZvciByaWQgMiBvZiBv cm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUwODAwLTB4ZTBmZmYpIGZvciByaWQgMiBv ZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUxMDAwLTB4ZTE3ZmYpIGZvciByaWQg MiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUxODAwLTB4ZTFmZmYpIGZvciBy aWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUyMDAwLTB4ZTI3ZmYpIGZv ciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUyODAwLTB4ZTJmZmYp IGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUzMDAwLTB4ZTM3 ZmYpIGZvciByaWQgMiBvZiBvcm0wCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUzODAwLTB4 ZTNmZmYpIGZvciByaWQgMiBvZiBvcm0wCmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBu UCBkZXZpY2VzCnBtdGltZXIwIG9uIGlzYTAKYXRhOiBhdGEwIGFscmVhZHkgZXhpc3RzOyBza2lw cGluZyBpdAphdGE6IGF0YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0a2JkYzogYXRr YmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRydGM6IGF0cnRjMCBhbHJlYWR5IGV4 aXN0czsgc2tpcHBpbmcgaXQKYXR0aW1lcjogYXR0aW1lcjAgYWxyZWFkeSBleGlzdHM7IHNraXBw aW5nIGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmlzYV9wcm9iZV9jaGls ZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQg aW9tZW0gMHhjZjAwMC0weGNmZmZmLDB4ZGY4MDAtMHhkZmZmZiBwbnBpZCBPUk0wMDAwIG9uIGlz YTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0Eg PDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWlu YWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1pbmFsKQp2Z2EwOiA8R2VuZXJpYyBJU0Eg VkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNjMC0weDNkZikgZm9yIHJpZCAwIG9mIHZnYTAKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTAwMDAtMHhiZmZmZikgZm9yIHJpZCAwIG9mIHZnYTAK cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2YwLTB4M2Y1KSBmb3IgcmlkIDAgb2YgZmRjMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjctMHgzZjcpIGZvciByaWQgMSBvZiBmZGMwCmZk YzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIg b24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4KcHBjMDogPFBhcmFsbGVsIHBv cnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBpc2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSA0ICgweDNmOC0weDNmZikgZm9yIHJpZCAwIG9mIHVhcnQwCnVhcnQwOiA8bnM4MjUwPiBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBvbiBpc2EwCnBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSA0ICgweDJmOC0weDJmZikgZm9yIHJpZCAwIG9mIHVhcnQxCnVhcnQxOiA8bnM4 MjUwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwCmlz YV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwplc3QwOiA8RW5oYW5jZWQgU3Bl ZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCnA0dGNjMDogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRy b2w+IG9uIGNwdTEKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3Rl cmVkClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdmxhbjogaW5pdGlhbGl6ZWQs IHVzaW5nIGhhc2ggdGFibGVzIHdpdGggY2hhaW5pbmcKbG8wOiBicGYgYXR0YWNoZWQKaHB0cnI6 IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhkYWNjMDogPFJlYWx0ZWsgQUxDODgzIEhEQSBDT0RF Qz4gYXQgY2FkIDAgb24gaGRhYzAKaGRhY2MwOiBSb290IE5vZGUgYXQgbmlkPTA6IDEgc3Vibm9k ZXMgMS0xCmhkYWEwOiA8UmVhbHRlayBBTEM4ODMgSERBIENPREVDIEF1ZGlvIEZ1bmN0aW9uIEdy b3VwPiBhdCBuaWQgMSBvbiBoZGFjYzAKaGRhYTA6IEF1ZGlvIEZ1bmN0aW9uIEdyb3VwIGF0IG5p ZD0xOiAzNyBzdWJub2RlcyAyLTM4CmhkYWEwOiBOdW1HUElPPTIgTnVtR1BPPTAgTnVtR1BJPTAg R1BJV2FrZT0wIEdQSVVuc29sPTEKaGRhYTA6ICBHUElPMDogZGlzYWJsZWQKaGRhYTA6ICBHUElP MTogZGlzYWJsZWQKaGRhYTA6IE9yaWdpbmFsIHBpbnMgY29uZmlndXJhdGlvbjoKaGRhYTA6IG5p ZCAgIDB4ICAgIGFzIHNlcSBkZXZpY2UgICAgICAgY29ubiAgamFjayAgICBsb2MgICAgICAgIGNv bG9yICAgbWlzYwpoZGFhMDogMjAgMDEyMTEwMWYgMSAgMTUgSGVhZHBob25lcyAgICBKYWNrICAx LzggICAgIFJlYXIgICAgICAgQmxhY2sgICAwCmhkYWEwOiAyMSA5OTEzMDExMCAxICAwICBTcGVh a2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2FyZCAgICBVbmtub3duIDEKaGRhYTA6IDIyIDQx MTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNr ICAgMQpoZGFhMDogMjMgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAg IFJlYXIgICAgICAgQmxhY2sgICAxCmhkYWEwOiAyNCAwMWExOTgzMCAzICAwICBNaWMgICAgICAg ICAgIEphY2sgIDEvOCAgICAgUmVhciAgICAgICBQaW5rICAgIDgKaGRhYTA6IDI1IDk5YTMwMTMx IDMgIDEgIE1pYyAgICAgICAgICAgRml4ZWQgQVRBUEkgICBPbmJvYXJkICAgIFVua25vd24gMQpo ZGFhMDogMjYgMDE4MTMwM2YgMyAgMTUgTGluZS1pbiAgICAgICBKYWNrICAxLzggICAgIFJlYXIg ICAgICAgQmx1ZSAgICAwCmhkYWEwOiAyNyA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5v bmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDI4IDQxMTExMWYwIDE1IDAg IFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDog MjkgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAg QmxhY2sgICAxCmhkYWEwOiAzMCAwMTQ1MTEyMCAyICAwICBTUERJRi1vdXQgICAgIEphY2sgIE9w dGljYWwgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDMxIDQxMTExMWYwIDE1IDAgIFNwZWFr ZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogUGF0Y2hp bmcgd2lkZ2V0IGNhcHMgbmlkPTI5IDB4MDA0MDAwMDAgLT4gMHgwMDcwMDAwMApoZGFhMDogUGF0 Y2hlZCBwaW5zIGNvbmZpZ3VyYXRpb246CmhkYWEwOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNl ICAgICAgIGNvbm4gIGphY2sgICAgbG9jICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTA6IDIwIDAx MjExMDFmIDEgIDE1IEhlYWRwaG9uZXMgICAgSmFjayAgMS84ICAgICBSZWFyICAgICAgIEJsYWNr ICAgMApoZGFhMDogMjEgOTkxMzAxMTAgMSAgMCAgU3BlYWtlciAgICAgICBGaXhlZCBBVEFQSSAg IE9uYm9hcmQgICAgVW5rbm93biAxCmhkYWEwOiAyMiA0MTExMTFmMCAxNSAwICBTcGVha2VyICAg ICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMjMgNDEx MTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sg ICAxIERJU0EKaGRhYTA6IDI0IDAxYTE5ODMwIDMgIDAgIE1pYyAgICAgICAgICAgSmFjayAgMS84 ICAgICBSZWFyICAgICAgIFBpbmsgICAgOApoZGFhMDogMjUgOTlhMzAxMzEgMyAgMSAgTWljICAg ICAgICAgICBGaXhlZCBBVEFQSSAgIE9uYm9hcmQgICAgVW5rbm93biAxCmhkYWEwOiAyNiAwMTgx MzAzZiAzICAxNSBMaW5lLWluICAgICAgIEphY2sgIDEvOCAgICAgUmVhciAgICAgICBCbHVlICAg IDAKaGRhYTA6IDI3IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBS ZWFyICAgICAgIEJsYWNrICAgMSBESVNBCmhkYWEwOiAyOCA0MTExMTFmMCAxNSAwICBTcGVha2Vy ICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMzAg MDE0NTExMjAgMiAgMCAgU1BESUYtb3V0ICAgICBKYWNrICBPcHRpY2FsIFJlYXIgICAgICAgQmxh Y2sgICAxCmhkYWEwOiAzMSA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAg ICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMyBhc3NvY2lhdGlvbnMgZm91bmQ6 CmhkYWEwOiBBc3NvY2lhdGlvbiAwICgxKSBvdXQ6CmhkYWEwOiAgUGluIG5pZD0yMSBzZXE9MApo ZGFhMDogIFBpbiBuaWQ9MjAgc2VxPTE1CmhkYWEwOiBBc3NvY2lhdGlvbiAxICgyKSBvdXQ6Cmhk YWEwOiAgUGluIG5pZD0zMCBzZXE9MApoZGFhMDogQXNzb2NpYXRpb24gMiAoMykgaW46CmhkYWEw OiAgUGluIG5pZD0yNCBzZXE9MApoZGFhMDogIFBpbiBuaWQ9MjUgc2VxPTEKaGRhYTA6ICBQaW4g bmlkPTI2IHNlcT0xNQpoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMDogIFBp biAyMSB0cmFjZWQgdG8gREFDIDIKaGRhYTA6ICBQaW4gMjAgdHJhY2VkIHRvIERBQyAyIGFuZCBo cHJlZGlyIDAKaGRhYTA6IEFzc29jaWF0aW9uIDAgKDEpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDog VHJhY2luZyBhc3NvY2lhdGlvbiAxICgyKQpoZGFhMDogIFBpbiAzMCB0cmFjZWQgdG8gREFDIDYK aGRhYTA6IEFzc29jaWF0aW9uIDEgKDIpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBh c3NvY2lhdGlvbiAyICgzKQpoZGFhMDogIFBpbiAyNCB0cmFjZWQgdG8gQURDIDgKaGRhYTA6ICBQ aW4gMjUgdHJhY2VkIHRvIEFEQyA4CmhkYWEwOiAgUGluIDI2IHRyYWNlZCB0byBBREMgOApoZGFh MDogQXNzb2NpYXRpb24gMiAoMykgdHJhY2Ugc3VjY2VlZGVkCmhkYWEwOiBMb29raW5nIGZvciBh ZGRpdGlvbmFsIERBQyBmb3IgYXNzb2NpYXRpb24gMCAoMSkKaGRhYTA6IExvb2tpbmcgZm9yIGFk ZGl0aW9uYWwgREFDIGZvciBhc3NvY2lhdGlvbiAxICgyKQpoZGFhMDogTG9va2luZyBmb3IgYWRk aXRpb25hbCBBREMgZm9yIGFzc29jaWF0aW9uIDIgKDMpCmhkYWEwOiAgQURDIDkgY29uc2lkZXJl ZCBlcXVhbCB0byBBREMgOApoZGFhMDogVHJhY2luZyBpbnB1dCBtb25pdG9yCmhkYWEwOiAgVHJh Y2luZyBuaWQgMTEgdG8gb3V0CmhkYWEwOiAgbmlkIDExIGlzIGlucHV0IG1vbml0b3IKaGRhYTA6 ICBUcmFjaW5nIG5pZCAzNCB0byBvdXQKaGRhYTA6ICBUcmFjaW5nIG5pZCAzNSB0byBvdXQKaGRh YTA6IFRyYWNpbmcgb3RoZXIgaW5wdXQgbW9uaXRvcnMKaGRhYTA6ICBUcmFjaW5nIG5pZCAyNCB0 byBvdXQKaGRhYTA6ICBUcmFjaW5nIG5pZCAyNSB0byBvdXQKaGRhYTA6ICBUcmFjaW5nIG5pZCAy NiB0byBvdXQKaGRhYTA6IFRyYWNpbmcgYmVlcGVyCmhkYWEwOiBIZWFkcGhvbmVzIHJlZGlyZWN0 aW9uIGZvciBhcz0wIG5pZD0yMCB1c2luZyB1bnNvbGljaXRlZCByZXNwb25zZXMuCmhkYWEwOiBQ aW4gc2Vuc2U6IG5pZD0yMCBzZW5jZT0weDAwMDAwMDAwIChkaXNjb25uZWN0ZWQpCmhkYWEwOiBG RyBjb25maWcvcXVpcmtzOiBmb3JjZXN0ZXJlbyBpdnJlZjUwIGl2cmVmODAgaXZyZWYxMDAgaXZy ZWYKaGRhYTA6IApoZGFhMDogKy0tLS0tLS0tLS0tLS0tLS0tLS0rCmhkYWEwOiB8IERVTVBJTkcg SERBIE5PREVTIHwKaGRhYTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tKwpoZGFhMDogCmhkYWEwOiBE ZWZhdWx0IFBhcmFtZXRlcgpoZGFhMDogLS0tLS0tLS0tLS0tLS0tLS0KaGRhYTA6ICAgICAgU3Ry ZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFhMDogICAgICAgICAgICAgICAgICBQQ00KaGRhYTA6ICAg ICAgICAgUENNIGNhcDogMHgwMDBlMDU2MApoZGFhMDogICAgICAgICAgICAgICAgICAxNiAyMCAy NCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6CmhkYWEwOiAgICAgICAgICBJTiBhbXA6IDB4MDAwMDAw MDAKaGRhYTA6ICAgICAgICAgT1VUIGFtcDogMHgwMDAwMDAwMApoZGFhMDogCmhkYWEwOiAgICAg ICAgICAgICBuaWQ6IDIKaGRhYTA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gb3V0cHV0CmhkYWEw OiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAwMTEKaGRhYTA6ICAgICAgICAgICAgICAgICAgU1RF UkVPCmhkYWEwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDgwMDEpCmhkYWEwOiAgICAgICAg ICAgICBPU1M6IHBjbSAocGNtKQpoZGFhMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhk YWEwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFhMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUw NTYwCmhkYWEwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBL SHoKaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAzIFtESVNBQkxFRF0KaGRhYTA6ICAg ICAgICAgICAgTmFtZTogYXVkaW8gb3V0cHV0CmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAw MDAwMTEKaGRhYTA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWEwOiAgICAgIFN0cmVhbSBj YXA6IDB4MDAwMDAwMDEKaGRhYTA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWEwOiAgICAgICAg IFBDTSBjYXA6IDB4MDAwZTA1NjAKaGRhYTA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0 cywgNDQgNDggOTYgMTkyIEtIegpoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDQgW0RJ U0FCTEVEXQpoZGFhMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYTA6ICAgICAg V2lkZ2V0IGNhcDogMHgwMDAwMDAxMQpoZGFhMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRh YTA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFhMDogICAgICAgICAgICAgICAgICBQ Q00KaGRhYTA6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDU2MApoZGFhMDogICAgICAgICAgICAg ICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6CmhkYWEwOiAKaGRhYTA6ICAgICAg ICAgICAgIG5pZDogNSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91 dHB1dApoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDAwMDExCmhkYWEwOiAgICAgICAgICAg ICAgICAgIFNURVJFTwpoZGFhMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWEwOiAg ICAgICAgICAgICAgICAgIFBDTQpoZGFhMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYwCmhk YWEwOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKaGRh YTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiA2CmhkYWEwOiAgICAgICAgICAgIE5hbWU6IGF1 ZGlvIG91dHB1dApoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDAwMjExCmhkYWEwOiAgICAg ICAgICAgICAgICAgIERJR0lUQUwgU1RFUkVPCmhkYWEwOiAgICAgQXNzb2NpYXRpb246IDEgKDB4 MDAwMDAwMDEpCmhkYWEwOiAgICAgICAgICAgICBPU1M6IHBjbSAocGNtKQpoZGFhMDogICAgICBT dHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWEwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFhMDog ICAgICAgICBQQ00gY2FwOiAweDAwMWUwNTYwCmhkYWEwOiAgICAgICAgICAgICAgICAgIDE2IDIw IDI0IDMyIGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKaGRhYTA6IApoZGFhMDogICAgICAgICAgICAg bmlkOiA3IFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApo ZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAwMDAwCmhkYWEwOiAKaGRhYTA6ICAgICAgICAg ICAgIG5pZDogOApoZGFhMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBpbnB1dApoZGFhMDogICAg ICBXaWRnZXQgY2FwOiAweDAwMTAwMTFiCmhkYWEwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpo ZGFhMDogICAgIEFzc29jaWF0aW9uOiAyICgweDAwMDA4MDAzKQpoZGFhMDogICAgICBTdHJlYW0g Y2FwOiAweDAwMDAwMDAxCmhkYWEwOiAgICAgICAgICAgICAgICAgIFBDTQpoZGFhMDogICAgICAg ICBQQ00gY2FwOiAweDAwMDYwMTYwCmhkYWEwOiAgICAgICAgICAgICAgICAgIDE2IDIwIGJpdHMs IDQ0IDQ4IDk2IEtIegpoZGFhMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDUxZjA4CmhkYWEwOiAg ICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9OApoZGFhMDogICAg IGNvbm5lY3Rpb25zOiAxCmhkYWEwOiAgICAgICAgICAgfApoZGFhMDogICAgICAgICAgICsgPC0g bmlkPTM1IFthdWRpbyBtaXhlcl0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiA5Cmhk YWEwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIGlucHV0CmhkYWEwOiAgICAgIFdpZGdldCBjYXA6 IDB4MDAxMDAxMWIKaGRhYTA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWEwOiAgICAgQXNz b2NpYXRpb246IDIgKDB4MDAwMDgwMDMpCmhkYWEwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAw MDEKaGRhYTA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWEwOiAgICAgICAgIFBDTSBjYXA6IDB4 MDAwNjAxNjAKaGRhYTA6ICAgICAgICAgICAgICAgICAgMTYgMjAgYml0cywgNDQgNDggOTYgS0h6 CmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwNTFmMDgKaGRhYTA6ICAgICAgICAgICAgICAg ICAgbXV0ZT0xIHN0ZXA9MzEgc2l6ZT01IG9mZnNldD04CmhkYWEwOiAgICAgY29ubmVjdGlvbnM6 IDEKaGRhYTA6ICAgICAgICAgICB8CmhkYWEwOiAgICAgICAgICAgKyA8LSBuaWQ9MzQgW2F1ZGlv IG1peGVyXQpoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDEwIFtESVNBQkxFRF0KaGRh YTA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gaW5wdXQKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDog MHgwMDEwMDM5MQpoZGFhMDogICAgICAgICAgICAgICAgICBESUdJVEFMIFVOU09MIFNURVJFTwpo ZGFhMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWEwOiAgICAgICAgICAgICAgICAg IFBDTQpoZGFhMDogICAgICAgICBQQ00gY2FwOiAweDAwMWUwNTYwCmhkYWEwOiAgICAgICAgICAg ICAgICAgIDE2IDIwIDI0IDMyIGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKaGRhYTA6ICAgICBjb25u ZWN0aW9uczogMQpoZGFhMDogICAgICAgICAgIHwKaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTMxIFtwaW46IFNwZWFrZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEwOiAKaGRh YTA6ICAgICAgICAgICAgIG5pZDogMTEKaGRhYTA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4 ZXIKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwYgpoZGFhMDogICAgICAgICAgICAg ICAgICBTVEVSRU8KaGRhYTA6ICAgICBBc3NvY2lhdGlvbjogMiAoMHgwMDAwODAwMykKaGRhYTA6 ICAgICAgICAgICAgIE9TUzogbWl4IChtaXgpCmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAw NTFmMTcKaGRhYTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MzEgc2l6ZT01IG9mZnNl dD0yMwpoZGFhMDogICAgIGNvbm5lY3Rpb25zOiAxMApoZGFhMDogICAgICAgICAgIHwKaGRhYTA6 ICAgICAgICAgICArIDwtIG5pZD0yNCBbcGluOiBNaWMgKFBpbmsgSmFjayldCmhkYWEwOiAgICAg ICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWljIChGaXhlZCldCmhkYWEwOiAgICAgICAgICAgKyA8 LSBuaWQ9MjYgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0KaGRhYTA6ICAgICAgICAgICArIFtE SVNBQkxFRF0gPC0gbmlkPTI3IFtwaW46IFNwZWFrZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEw OiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yOCBbcGluOiBTcGVha2VyIChOb25lKV0g W0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0KaGRh YTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIwIFtwaW46IEhlYWRwaG9uZXMgKEJs YWNrIEphY2spXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjEgW3Bpbjog U3BlYWtlciAoRml4ZWQpXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjIg W3BpbjogU3BlYWtlciAoTm9uZSldIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTIzIFtwaW46IFNwZWFrZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEwOiAK aGRhYTA6ICAgICAgICAgICAgIG5pZDogMTIKaGRhYTA6ICAgICAgICAgICAgTmFtZTogYXVkaW8g bWl4ZXIKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFhMDogICAgICAgICAg ICAgICAgICBTVEVSRU8KaGRhYTA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwODAwMSkKaGRh YTA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKaGRhYTA6ICAgICAgT3V0cHV0IGFtcDogMHgw MDA1MWYxZgpoZGFhMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zMSBzaXplPTUgb2Zm c2V0PTMxCmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYTA6ICAgICAgICAg ICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYTA6ICAgICBjb25uZWN0 aW9uczogMgpoZGFhMDogICAgICAgICAgIHwKaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0yIFth dWRpbyBvdXRwdXRdCmhkYWEwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpo ZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDEzIFtESVNBQkxFRF0KaGRhYTA6ICAgICAg ICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEw ZgpoZGFhMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYTA6ICAgICBBc3NvY2lhdGlvbjog LTIgKDB4MDAwMDAwMDApCmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4MDAwNTFmMWYKaGRhYTA6 ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MzEgc2l6ZT01IG9mZnNldD0zMQpoZGFhMDog ICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWEwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYTA6 ICAgICAgICAgICB8CmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zIFthdWRp byBvdXRwdXRdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlk PTExIFthdWRpbyBtaXhlcl0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAxNCBbRElT QUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWEwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDAyMDAxMGYKaGRhYTA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWEw OiAgICAgQXNzb2NpYXRpb246IC0yICgweDAwMDAwMDAwKQpoZGFhMDogICAgICBPdXRwdXQgYW1w OiAweDAwMDUxZjFmCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMxIHNpemU9 NSBvZmZzZXQ9MzEKaGRhYTA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFhMDogICAg ICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFhMDogICAgIGNv bm5lY3Rpb25zOiAyCmhkYWEwOiAgICAgICAgICAgfApoZGFhMDogICAgICAgICAgICsgW0RJU0FC TEVEXSA8LSBuaWQ9NCBbYXVkaW8gb3V0cHV0XSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdCmhkYWEwOiAKaGRhYTA6ICAgICAg ICAgICAgIG5pZDogMTUgW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICBOYW1lOiBhdWRpbyBt aXhlcgpoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwMjAwMTBmCmhkYWEwOiAgICAgICAgICAg ICAgICAgIFNURVJFTwpoZGFhMDogICAgIEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwMDAwMCkKaGRh YTA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MWYxZgpoZGFhMDogICAgICAgICAgICAgICAgICBt dXRlPTAgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4 ODAwMDAwMDAKaGRhYTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zm c2V0PTAKaGRhYTA6ICAgICBjb25uZWN0aW9uczogMgpoZGFhMDogICAgICAgICAgIHwKaGRhYTA6 ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTUgW2F1ZGlvIG91dHB1dF0gW0RJU0FCTEVE XQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpo ZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDE2IFtESVNBQkxFRF0KaGRhYTA6ICAgICAg ICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAw MDAwCmhkYWEwOiAKaGRhYTA6ICAgICAgICAgICAgIG5pZDogMTcgW0RJU0FCTEVEXQpoZGFhMDog ICAgICAgICAgICBOYW1lOiB2ZW5kb3Igd2lkZ2V0CmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4 MDBmMDAwMDAKaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAxOCBbRElTQUJMRURdCmhk YWEwOiAgICAgICAgICAgIE5hbWU6IHZlbmRvciB3aWRnZXQKaGRhYTA6ICAgICAgV2lkZ2V0IGNh cDogMHgwMGYwMDAwMApoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDE5IFtESVNBQkxF RF0KaGRhYTA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFhMDogICAgICBXaWRn ZXQgY2FwOiAweDAwZjAwMDAwCmhkYWEwOiAKaGRhYTA6ICAgICAgICAgICAgIG5pZDogMjAKaGRh YTA6ICAgICAgICAgICAgTmFtZTogcGluOiBIZWFkcGhvbmVzIChCbGFjayBKYWNrKQpoZGFhMDog ICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThmCmhkYWEwOiAgICAgICAgICAgICAgICAgIFVOU09M IFNURVJFTwpoZGFhMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDA4MDAwKQpoZGFhMDogICAg ICAgICBQaW4gY2FwOiAweDAwMDAwMDNlCmhkYWEwOiAgICAgICAgICAgICAgICAgIFRSUUQgUERD IEhQIE9VVCBJTgpoZGFhMDogICAgICBQaW4gY29uZmlnOiAweDAxMjExMDFmCmhkYWEwOiAgICAg UGluIGNvbnRyb2w6IDB4MDAwMDAwYzAgSFAgT1VUCmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4 ODAwMDAwMDAKaGRhYTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zm c2V0PTAKaGRhYTA6ICAgICAgIElucHV0IGFtcDogMHgwMDI3MDMwMApoZGFhMDogICAgICAgICAg ICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0PTAKaGRhYTA6ICAgICBjb25uZWN0 aW9uczogNQpoZGFhMDogICAgICAgICAgIHwKaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0xMiBb YXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0g bmlkPTEzIFthdWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FC TEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpo ZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDIxCmhkYWEwOiAgICAgICAgICAgIE5hbWU6 IHBpbjogU3BlYWtlciAoRml4ZWQpCmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGYK aGRhYTA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWEwOiAgICAgQXNzb2NpYXRp b246IDAgKDB4MDAwMDAwMDEpCmhkYWEwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwM2UKaGRh YTA6ICAgICAgICAgICAgICAgICAgVFJRRCBQREMgSFAgT1VUIElOCmhkYWEwOiAgICAgIFBpbiBj b25maWc6IDB4OTkxMzAxMTAKaGRhYTA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQK aGRhYTA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFhMDogICAgICAgICAgICAgICAg ICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFhMDogICAgICAgSW5wdXQgYW1wOiAw eDAwMjcwMzAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBv ZmZzZXQ9MApoZGFhMDogICAgIGNvbm5lY3Rpb25zOiA1CmhkYWEwOiAgICAgICAgICAgfApoZGFh MDogICAgICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gKHNlbGVjdGVkKQpoZGFhMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXSBbRElTQUJMRURd CmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdIFtE SVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTE1IFthdWRpbyBt aXhlcl0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9Mzgg W2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAKaGRhYTA6ICAgICAgICAgICAgIG5pZDog MjIgW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICBOYW1lOiBwaW46IFNwZWFrZXIgKE5vbmUp CmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGYKaGRhYTA6ICAgICAgICAgICAgICAg ICAgVU5TT0wgU1RFUkVPCmhkYWEwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwM2UKaGRhYTA6 ICAgICAgICAgICAgICAgICAgVFJRRCBQREMgSFAgT1VUIElOCmhkYWEwOiAgICAgIFBpbiBjb25m aWc6IDB4NDExMTExZjAKaGRhYTA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAwMApoZGFhMDog ICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4MDAyNzAz MDAKaGRhYTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0w CmhkYWEwOiAgICAgY29ubmVjdGlvbnM6IDUKaGRhYTA6ICAgICAgICAgICB8CmhkYWEwOiAgICAg ICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRh YTA6ICAgICAgICAgICArIDwtIG5pZD0xMyBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6 ICAgICAgICAgICArIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAg ICAgICAgICArIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAg ICAgICArIDwtIG5pZD0zOCBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6IApoZGFhMDog ICAgICAgICAgICAgbmlkOiAyMyBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IHBp bjogU3BlYWtlciAoTm9uZSkKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpoZGFh MDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYTA6ICAgICAgICAgUGluIGNhcDog MHgwMDAwMDAzZQpoZGFhMDogICAgICAgICAgICAgICAgICBUUlFEIFBEQyBIUCBPVVQgSU4KaGRh YTA6ICAgICAgUGluIGNvbmZpZzogMHg0MTExMTFmMApoZGFhMDogICAgIFBpbiBjb250cm9sOiAw eDAwMDAwMDAwCmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYTA6ICAgICAg ICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYTA6ICAgICAgIElu cHV0IGFtcDogMHgwMDI3MDMwMApoZGFhMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z IHNpemU9Mzkgb2Zmc2V0PTAKaGRhYTA6ICAgICBjb25uZWN0aW9uczogNQpoZGFhMDogICAgICAg ICAgIHwKaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhl cl0gKHNlbGVjdGVkKQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0g W0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0gW0RJ U0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0gW0RJU0FC TEVEXQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0gW0RJU0FCTEVE XQpoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDI0CmhkYWEwOiAgICAgICAgICAgIE5h bWU6IHBpbjogTWljIChQaW5rIEphY2spCmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAx OGYKaGRhYTA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWEwOiAgICAgQXNzb2Np YXRpb246IDIgKDB4MDAwMDAwMDEpCmhkYWEwOiAgICAgICAgICAgICBPU1M6IG1pYyAobWljKQpo ZGFhMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAxNzNlCmhkYWEwOiAgICAgICAgICAgICAgICAg IFRSUUQgUERDIEhQIE9VVCBJTiBWUkVGWyA1MCA4MCBHUk9VTkQgSElaIF0KaGRhYTA6ICAgICAg UGluIGNvbmZpZzogMHgwMWExOTgzMApoZGFhMDogICAgIFBpbiBjb250cm9sOiAweDAwMDAwMDI0 IElOIFZSRUZzCmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYTA6ICAgICAg ICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYTA6ICAgICAgIElu cHV0IGFtcDogMHgwMDI3MDMwMApoZGFhMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z IHNpemU9Mzkgb2Zmc2V0PTAKaGRhYTA6ICAgICBjb25uZWN0aW9uczogNQpoZGFhMDogICAgICAg ICAgIHwKaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhl cl0gKHNlbGVjdGVkKQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1 ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD0xNCBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAKaGRh YTA6ICAgICAgICAgICAgIG5pZDogMjUKaGRhYTA6ICAgICAgICAgICAgTmFtZTogcGluOiBNaWMg KEZpeGVkKQpoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThmCmhkYWEwOiAgICAgICAg ICAgICAgICAgIFVOU09MIFNURVJFTwpoZGFhMDogICAgIEFzc29jaWF0aW9uOiAyICgweDAwMDAw MDAyKQpoZGFhMDogICAgICAgICAgICAgT1NTOiBtb25pdG9yIChtb25pdG9yKQpoZGFhMDogICAg ICAgICBQaW4gY2FwOiAweDAwMDAxNzNlCmhkYWEwOiAgICAgICAgICAgICAgICAgIFRSUUQgUERD IEhQIE9VVCBJTiBWUkVGWyA1MCA4MCBHUk9VTkQgSElaIF0KaGRhYTA6ICAgICAgUGluIGNvbmZp ZzogMHg5OWEzMDEzMQpoZGFhMDogICAgIFBpbiBjb250cm9sOiAweDAwMDAwMDI0IElOIFZSRUZz CmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYTA6ICAgICAgICAgICAgICAg ICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYTA6ICAgICAgIElucHV0IGFtcDog MHgwMDI3MDMwMApoZGFhMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkg b2Zmc2V0PTAKaGRhYTA6ICAgICBjb25uZWN0aW9uczogNQpoZGFhMDogICAgICAgICAgIHwKaGRh YTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gKHNlbGVj dGVkKQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVy XSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNCBbYXVk aW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlk PTE1IFthdWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAKaGRhYTA6ICAgICAg ICAgICAgIG5pZDogMjYKaGRhYTA6ICAgICAgICAgICAgTmFtZTogcGluOiBMaW5lLWluIChCbHVl IEphY2spCmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGYKaGRhYTA6ICAgICAgICAg ICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWEwOiAgICAgQXNzb2NpYXRpb246IDIgKDB4MDAwMDgw MDApCmhkYWEwOiAgICAgICAgICAgICBPU1M6IGxpbmUgKGxpbmUpCmhkYWEwOiAgICAgICAgIFBp biBjYXA6IDB4MDAwMDE3M2UKaGRhYTA6ICAgICAgICAgICAgICAgICAgVFJRRCBQREMgSFAgT1VU IElOIFZSRUZbIDUwIDgwIEdST1VORCBISVogXQpoZGFhMDogICAgICBQaW4gY29uZmlnOiAweDAx ODEzMDNmCmhkYWEwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjQgSU4gVlJFRnMKaGRhYTA6 ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFhMDogICAgICAgICAgICAgICAgICBtdXRl PTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFhMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcw MzAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZzZXQ9 MApoZGFhMDogICAgIGNvbm5lY3Rpb25zOiA1CmhkYWEwOiAgICAgICAgICAgfApoZGFhMDogICAg ICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXSAoc2VsZWN0ZWQpCmhk YWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMyBbYXVkaW8gbWl4ZXJdIFtESVNB QkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTE0IFthdWRpbyBtaXhl cl0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTUgW2F1 ZGlvIG1peGVyXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD0zOCBbYXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAg bmlkOiAyNyBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU3BlYWtlciAo Tm9uZSkKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpoZGFhMDogICAgICAgICAg ICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYTA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMTczZQpo ZGFhMDogICAgICAgICAgICAgICAgICBUUlFEIFBEQyBIUCBPVVQgSU4gVlJFRlsgNTAgODAgR1JP VU5EIEhJWiBdCmhkYWEwOiAgICAgIFBpbiBjb25maWc6IDB4NDExMTExZjAKaGRhYTA6ICAgICBQ aW4gY29udHJvbDogMHgwMDAwMDAwMApoZGFhMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAwMDAw CmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhk YWEwOiAgICAgICBJbnB1dCBhbXA6IDB4MDAyNzAzMDAKaGRhYTA6ICAgICAgICAgICAgICAgICAg bXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCmhkYWEwOiAgICAgY29ubmVjdGlvbnM6IDUK aGRhYTA6ICAgICAgICAgICB8CmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0x MiBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0xMyBb YXVkaW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0xNCBbYXVk aW8gbWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0xNSBbYXVkaW8g bWl4ZXJdIFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0zOCBbYXVkaW8gbWl4 ZXJdIFtESVNBQkxFRF0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAyOCBbRElTQUJM RURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU3BlYWtlciAoTm9uZSkKaGRhYTA6ICAg ICAgV2lkZ2V0IGNhcDogMHgwMDQwMDAwMQpoZGFhMDogICAgICAgICAgICAgICAgICBTVEVSRU8K aGRhYTA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAyMApoZGFhMDogICAgICAgICAgICAgICAg ICBJTgpoZGFhMDogICAgICBQaW4gY29uZmlnOiAweDQxMTExMWYwCmhkYWEwOiAgICAgUGluIGNv bnRyb2w6IDB4MDAwMDAwMDAKaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAyOQpoZGFh MDogICAgICAgICAgICBOYW1lOiBiZWVwIHdpZGdldApoZGFhMDogICAgICBXaWRnZXQgY2FwOiAw eDAwNzAwMDAwCmhkYWEwOiAgICAgQXNzb2NpYXRpb246IC0yICgweDAwMDAwMDAwKQpoZGFhMDog ICAgICAgICAgICAgT1NTOiBzcGVha2VyIChzcGVha2VyKQpoZGFhMDogICAgICAgICBQaW4gY2Fw OiAweDAwMDAwMDIwCmhkYWEwOiAgICAgICAgICAgICAgICAgIElOCmhkYWEwOiAgICAgIFBpbiBj b25maWc6IDB4NDExMTExZjAKaGRhYTA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyMCBJTgpo ZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDMwCmhkYWEwOiAgICAgICAgICAgIE5hbWU6 IHBpbjogU1BESUYtb3V0IChCbGFjayBKYWNrKQpoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAw NDAwMzAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIERJR0lUQUwKaGRhYTA6ICAgICBBc3NvY2lh dGlvbjogMSAoMHgwMDAwMDAwMSkKaGRhYTA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAxMApo ZGFhMDogICAgICAgICAgICAgICAgICBPVVQKaGRhYTA6ICAgICAgUGluIGNvbmZpZzogMHgwMTQ1 MTEyMApoZGFhMDogICAgIFBpbiBjb250cm9sOiAweDAwMDAwMDQwIE9VVApoZGFhMDogICAgIGNv bm5lY3Rpb25zOiAxCmhkYWEwOiAgICAgICAgICAgfApoZGFhMDogICAgICAgICAgICsgPC0gbmlk PTYgW2F1ZGlvIG91dHB1dF0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAzMSBbRElT QUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IHBpbjogU3BlYWtlciAoTm9uZSkKaGRhYTA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDIwMApoZGFhMDogICAgICAgICAgICAgICAgICBESUdJ VEFMCmhkYWEwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwMjAKaGRhYTA6ICAgICAgICAgICAg ICAgICAgSU4KaGRhYTA6ICAgICAgUGluIGNvbmZpZzogMHg0MTExMTFmMApoZGFhMDogICAgIFBp biBjb250cm9sOiAweDAwMDAwMDAwCmhkYWEwOiAKaGRhYTA6ICAgICAgICAgICAgIG5pZDogMzIg W0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICBOYW1lOiB2ZW5kb3Igd2lkZ2V0CmhkYWEwOiAg ICAgIFdpZGdldCBjYXA6IDB4MDBmMDAwNDAKaGRhYTA6ICAgICAgICAgICAgICAgICAgUFJPQwpo ZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDMzIFtESVNBQkxFRF0KaGRhYTA6ICAgICAg ICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFhMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAw MDAwCmhkYWEwOiAKaGRhYTA6ICAgICAgICAgICAgIG5pZDogMzQKaGRhYTA6ICAgICAgICAgICAg TmFtZTogYXVkaW8gbWl4ZXIKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFh MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYTA6ICAgICBBc3NvY2lhdGlvbjogMiAoMHgw MDAwODAwMykKaGRhYTA6ICAgICAgICAgICAgIE9TUzogc3BlYWtlciwgbGluZSwgbWljLCBtaXgs IG1vbml0b3IKaGRhYTA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFhMDogICAgICAg ICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFhMDogICAgIGNvbm5l Y3Rpb25zOiAxMQpoZGFhMDogICAgICAgICAgIHwKaGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0y NCBbcGluOiBNaWMgKFBpbmsgSmFjayldCmhkYWEwOiAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3Bp bjogTWljIChGaXhlZCldCmhkYWEwOiAgICAgICAgICAgKyA8LSBuaWQ9MjYgW3BpbjogTGluZS1p biAoQmx1ZSBKYWNrKV0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI3IFtw aW46IFNwZWFrZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJM RURdIDwtIG5pZD0yOCBbcGluOiBTcGVha2VyIChOb25lKV0gW0RJU0FCTEVEXQpoZGFhMDogICAg ICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0KaGRhYTA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTIwIFtwaW46IEhlYWRwaG9uZXMgKEJsYWNrIEphY2spXQpoZGFhMDogICAg ICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjEgW3BpbjogU3BlYWtlciAoRml4ZWQpXQpoZGFh MDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjIgW3BpbjogU3BlYWtlciAoTm9uZSld IFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIzIFtwaW46 IFNwZWFrZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEg W2F1ZGlvIG1peGVyXQpoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBuaWQ6IDM1CmhkYWEwOiAg ICAgICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAy MDAxMGYKaGRhYTA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWEwOiAgICAgQXNzb2NpYXRp b246IDIgKDB4MDAwMDgwMDMpCmhkYWEwOiAgICAgICAgICAgICBPU1M6IHNwZWFrZXIsIGxpbmUs IG1pYywgbWl4LCBtb25pdG9yCmhkYWEwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRh YTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYTA6 ICAgICBjb25uZWN0aW9uczogMTEKaGRhYTA6ICAgICAgICAgICB8CmhkYWEwOiAgICAgICAgICAg KyA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2spXQpoZGFhMDogICAgICAgICAgICsgPC0g bmlkPTI1IFtwaW46IE1pYyAoRml4ZWQpXQpoZGFhMDogICAgICAgICAgICsgPC0gbmlkPTI2IFtw aW46IExpbmUtaW4gKEJsdWUgSmFjayldCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0yNyBbcGluOiBTcGVha2VyIChOb25lKV0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAg ICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjggW3BpbjogU3BlYWtlciAoTm9uZSldIFtESVNBQkxFRF0K aGRhYTA6ICAgICAgICAgICArIDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRdCmhkYWEwOiAgICAgICAg ICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGluOiBIZWFkcGhvbmVzIChCbGFjayBKYWNrKV0K aGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIxIFtwaW46IFNwZWFrZXIgKEZp eGVkKV0KaGRhYTA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIyIFtwaW46IFNwZWFr ZXIgKE5vbmUpXSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5p ZD0yMyBbcGluOiBTcGVha2VyIChOb25lKV0gW0RJU0FCTEVEXQpoZGFhMDogICAgICAgICAgICsg PC0gbmlkPTExIFthdWRpbyBtaXhlcl0KaGRhYTA6IApoZGFhMDogICAgICAgICAgICAgbmlkOiAz NiBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgIE5hbWU6IHZlbmRvciB3aWRnZXQKaGRhYTA6 ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAwMApoZGFhMDogCmhkYWEwOiAgICAgICAgICAgICBu aWQ6IDM3IFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gb3V0cHV0Cmhk YWEwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAwMDAwMTEKaGRhYTA6ICAgICAgICAgICAgICAgICAg U1RFUkVPCmhkYWEwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYTA6ICAgICAgICAg ICAgICAgICAgUENNCmhkYWEwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKaGRhYTA6ICAg ICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpoZGFhMDogCmhk YWEwOiAgICAgICAgICAgICBuaWQ6IDM4IFtESVNBQkxFRF0KaGRhYTA6ICAgICAgICAgICAgTmFt ZTogYXVkaW8gbWl4ZXIKaGRhYTA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFhMDog ICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYTA6ICAgICBBc3NvY2lhdGlvbjogLTIgKDB4MDAw MDAwMDApCmhkYWEwOiAgICAgIE91dHB1dCBhbXA6IDB4MDAwNTFmMWYKaGRhYTA6ICAgICAgICAg ICAgICAgICAgbXV0ZT0wIHN0ZXA9MzEgc2l6ZT01IG9mZnNldD0zMQpoZGFhMDogICAgICAgSW5w dXQgYW1wOiAweDgwMDAwMDAwCmhkYWEwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAg c2l6ZT0wIG9mZnNldD0wCmhkYWEwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYTA6ICAgICAgICAg ICB8CmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zNyBbYXVkaW8gb3V0cHV0 XSBbRElTQUJMRURdCmhkYWEwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMSBbYXVk aW8gbWl4ZXJdCmhkYWEwOiAKcGNtMDogPFJlYWx0ZWsgQUxDODgzIEhEQSBDT0RFQyBQQ00gKEFu YWxvZyk+IGF0IG5pZCAyMSwyMCBhbmQgMjQsMjUsMjYgb24gaGRhYTAKcGNtMDogKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20wOiB8IERVTVBJTkcgUENNIFBsYXli YWNrL1JlY29yZCBDaGFubmVscyB8CnBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKcGNtMDogCnBjbTA6IFBsYXliYWNrOgpwY20wOiAKcGNtMDogICAgICBTdHJl YW0gY2FwOiAweDAwMDAwMDAxCnBjbTA6ICAgICAgICAgICAgICAgICAgUENNCnBjbTA6ICAgICAg ICAgUENNIGNhcDogMHgwMDBlMDU2MApwY20wOiAgICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJp dHMsIDQ0IDQ4IDk2IDE5MiBLSHoKcGNtMDogICAgICAgICAgICAgREFDOiAyCnBjbTA6IApwY20w OiBSZWNvcmQ6CnBjbTA6IApwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKcGNtMDog ICAgICAgICAgICAgICAgICBQQ00KcGNtMDogICAgICAgICBQQ00gY2FwOiAweDAwMDYwMTYwCnBj bTA6ICAgICAgICAgICAgICAgICAgMTYgMjAgYml0cywgNDQgNDggOTYgS0h6CnBjbTA6ICAgICAg ICAgICAgIERBQzogOApwY20wOiAgICAgICAgICAgICBEQUM6IDkKcGNtMDogCnBjbTA6ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20wOiB8IERVTVBJTkcgUGxheWJhY2svUmVj b3JkIFBhdGhzIHwKcGNtMDogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTA6 IApwY20wOiBQbGF5YmFjazoKcGNtMDogCnBjbTA6ICAgICBuaWQ9MjEgW3BpbjogU3BlYWtlciAo Rml4ZWQpXQpwY20wOiAgICAgICB8CnBjbTA6ICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhl cl0gW3NyYzogcGNtLCBtaXhdCnBjbTA6ICAgICAgICAgICAgICB8CnBjbTA6ICAgICAgICAgICAg ICArIDwtIG5pZD0yIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMDogICAgICAgICAgICAg ICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5p ZD0yMCBbcGluOiBIZWFkcGhvbmVzIChCbGFjayBKYWNrKV0KcGNtMDogICAgICAgfApwY20wOiAg ICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwgbWl4XQpwY20wOiAgICAg ICAgICAgICAgfApwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XSBb c3JjOiBwY21dCnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdIFtz cmM6IG1peF0KcGNtMDogCnBjbTA6IFJlY29yZDoKcGNtMDogCnBjbTA6ICAgICBuaWQ9OCBbYXVk aW8gaW5wdXRdCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9MzUgW2F1ZGlvIG1p eGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBtaWMsIG1peCwgbW9uaXRvcl0KcGNtMDogICAgICAg ICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBK YWNrKV0gW3NyYzogbWljXQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWlj IChGaXhlZCldIFtzcmM6IG1vbml0b3JdCnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0yNiBb cGluOiBMaW5lLWluIChCbHVlIEphY2spXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICAgICAgICAg KyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0XSBbc3JjOiBzcGVha2VyXQpwY20wOiAgICAgICAgICAg ICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCnBjbTA6IApwY20wOiAgICAg bmlkPTkgW2F1ZGlvIGlucHV0XQpwY20wOiAgICAgICB8CnBjbTA6ICAgICAgICsgPC0gbmlkPTM0 IFthdWRpbyBtaXhlcl0gW3NyYzogc3BlYWtlciwgbGluZSwgbWljLCBtaXgsIG1vbml0b3JdCnBj bTA6ICAgICAgICAgICAgICB8CnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0yNCBbcGluOiBN aWMgKFBpbmsgSmFjayldIFtzcmM6IG1pY10KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTI1 IFtwaW46IE1pYyAoRml4ZWQpXSBbc3JjOiBtb25pdG9yXQpwY20wOiAgICAgICAgICAgICAgKyA8 LSBuaWQ9MjYgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNrKV0gW3NyYzogbGluZV0KcGNtMDogICAg ICAgICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0gW3NyYzogc3BlYWtlcl0KcGNtMDog ICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAK cGNtMDogSW5wdXQgTWl4OgpwY20wOiAKcGNtMDogICAgIG5pZD0xMSBbYXVkaW8gbWl4ZXJdCnBj bTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5rIEphY2sp XSBbc3JjOiBtaWNdCnBjbTA6ICAgICAgICsgPC0gbmlkPTI1IFtwaW46IE1pYyAoRml4ZWQpXSBb c3JjOiBtb25pdG9yXQpwY20wOiAgICAgICArIDwtIG5pZD0yNiBbcGluOiBMaW5lLWluIChCbHVl IEphY2spXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICArIDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRd IFtzcmM6IHNwZWFrZXJdCnBjbTA6IApwY20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK cGNtMDogfCBEVU1QSU5HIFZvbHVtZSBDb250cm9scyB8CnBjbTA6ICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKwpwY20wOiAKcGNtMDogTWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wpCnBjbTA6ICAg IHwKcGNtMDogICAgKy0gY3RsIDEzIChuaWQgIDEyIG91dCk6ICAgIC00Ni8wZEIgKDMyIHN0ZXBz KQpwY20wOiAgICArLSBjdGwgMTQgKG5pZCAgMTIgaW4gICAwKTogbXV0ZQpwY20wOiAgICArLSBj dGwgMTUgKG5pZCAgMTIgaW4gICAxKTogbXV0ZQpwY20wOiAgICArLSBjdGwgMjUgKG5pZCAgMjAg aW4gKTogICAgbXV0ZQpwY20wOiAgICArLSBjdGwgMjcgKG5pZCAgMjEgaW4gKTogICAgbXV0ZQpw Y20wOiAKcGNtMDogUENNIFZvbHVtZSAoT1NTOiBwY20pCnBjbTA6ICAgIHwKcGNtMDogICAgKy0g Y3RsIDE0IChuaWQgIDEyIGluICAgMCk6IG11dGUKcGNtMDogCnBjbTA6IE1pY3JvcGhvbmUgVm9s dW1lIChPU1M6IG1pYykKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgMzQgKG5pZCAgMjQgb3V0 KTogICAgMC8zMGRCICg0IHN0ZXBzKQpwY20wOiAgICArLSBjdGwgNDEgKG5pZCAgMzQgaW4gICAw KTogbXV0ZQpwY20wOiAgICArLSBjdGwgNTIgKG5pZCAgMzUgaW4gICAwKTogbXV0ZQpwY20wOiAK cGNtMDogTWljcm9waG9uZTIgVm9sdW1lIChPU1M6IG1vbml0b3IpCnBjbTA6ICAgIHwKcGNtMDog ICAgKy0gY3RsIDM2IChuaWQgIDI1IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKcGNtMDogICAg Ky0gY3RsIDQyIChuaWQgIDM0IGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDUzIChuaWQg IDM1IGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6IExpbmUtaW4gVm9sdW1lIChPU1M6IGxpbmUp CnBjbTA6ICAgIHwKcGNtMDogICAgKy0gY3RsIDM4IChuaWQgIDI2IG91dCk6ICAgIDAvMzBkQiAo NCBzdGVwcykKcGNtMDogICAgKy0gY3RsIDQzIChuaWQgIDM0IGluICAgMik6IG11dGUKcGNtMDog ICAgKy0gY3RsIDU0IChuaWQgIDM1IGluICAgMik6IG11dGUKcGNtMDogCnBjbTA6IFNwZWFrZXIv QmVlcCBWb2x1bWUgKE9TUzogc3BlYWtlcikKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgIDgg KG5pZCAgMTEgaW4gICA1KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0g Y3RsIDQ2IChuaWQgIDM0IGluICAgNSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDU3IChuaWQgIDM1 IGluICAgNSk6IG11dGUKcGNtMDogCnBjbTA6IFJlY29yZGluZyBMZXZlbCAoT1NTOiByZWMpCnBj bTA6ICAgIHwKcGNtMDogICAgKy0gY3RsICAxIChuaWQgICA4IGluICAgMCk6IC0xMi8zNGRCICgz MiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAgMiAobmlkICAgOSBpbiAgIDApOiAtMTIv MzRkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgNDEgKG5pZCAgMzQgaW4gICAw KTogbXV0ZQpwY20wOiAgICArLSBjdGwgNDIgKG5pZCAgMzQgaW4gICAxKTogbXV0ZQpwY20wOiAg ICArLSBjdGwgNDMgKG5pZCAgMzQgaW4gICAyKTogbXV0ZQpwY20wOiAgICArLSBjdGwgNDYgKG5p ZCAgMzQgaW4gICA1KTogbXV0ZQpwY20wOiAgICArLSBjdGwgNTEgKG5pZCAgMzQgaW4gIDEwKTog bXV0ZQpwY20wOiAgICArLSBjdGwgNTIgKG5pZCAgMzUgaW4gICAwKTogbXV0ZQpwY20wOiAgICAr LSBjdGwgNTMgKG5pZCAgMzUgaW4gICAxKTogbXV0ZQpwY20wOiAgICArLSBjdGwgNTQgKG5pZCAg MzUgaW4gICAyKTogbXV0ZQpwY20wOiAgICArLSBjdGwgNTcgKG5pZCAgMzUgaW4gICA1KTogbXV0 ZQpwY20wOiAgICArLSBjdGwgNjIgKG5pZCAgMzUgaW4gIDEwKTogbXV0ZQpwY20wOiAKcGNtMDog SW5wdXQgTWl4IExldmVsIChPU1M6IG1peCkKcGNtMDogICAgfApwY20wOiAgICArLSBjdGwgIDMg KG5pZCAgMTEgaW4gICAwKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0g Y3RsICA0IChuaWQgIDExIGluICAgMSk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6 ICAgICstIGN0bCAgNSAobmlkICAxMSBpbiAgIDIpOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0 ZQpwY20wOiAgICArLSBjdGwgIDggKG5pZCAgMTEgaW4gICA1KTogLTM0LzEyZEIgKDMyIHN0ZXBz KSArIG11dGUKcGNtMDogICAgKy0gY3RsIDE1IChuaWQgIDEyIGluICAgMSk6IG11dGUKcGNtMDog ICAgKy0gY3RsIDUxIChuaWQgIDM0IGluICAxMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDYyIChu aWQgIDM1IGluICAxMCk6IG11dGUKcGNtMDogCnBjbTA6IElucHV0IE1vbml0b3JpbmcgTGV2ZWwg KE9TUzogaWdhaW4pCnBjbTA6ICAgIHwKcGNtMDogICAgKy0gY3RsIDE1IChuaWQgIDEyIGluICAg MSk6IG11dGUKcGNtMDogCnBjbTA6IEVuYWJsaW5nIFNvZnQgUENNIHZvbHVtZQpwY20wOiBNaXhl ciAidm9sIjoKcGNtMDogTWl4ZXIgInBjbSI6CnBjbTA6IE1peGVyICJzcGVha2VyIjoKcGNtMDog TWl4ZXIgImxpbmUiOgpwY20wOiBNaXhlciAibWljIjoKcGNtMDogTWl4ZXIgIm1peCI6CnBjbTA6 IE1peGVyICJyZWMiOgpwY20wOiBNaXhlciAiaWdhaW4iOgpwY20wOiBNaXhlciAibW9uaXRvciI6 CnBjbTA6IFNvZnQgUENNIG1peGVyIEVOQUJMRUQKcGNtMDogY2xvbmUgbWFuYWdlcjogZGVhZGxp bmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAxZQpwY20wOiBzbmRidWZfc2V0bWFwIDQ0NjMwMDAsIDQw MDA7IDB4ZWMwNjMwMDAgLT4gNDQ2MzAwMApwY20wOiBzbmRidWZfc2V0bWFwIDQ0NzMwMDAsIDQw MDA7IDB4ZWMwNzMwMDAgLT4gNDQ3MzAwMApwY20wOiBzbmRidWZfc2V0bWFwIDQ0ODMwMDAsIDQw MDA7IDB4ZWMwODMwMDAgLT4gNDQ4MzAwMApwY20xOiA8UmVhbHRlayBBTEM4ODMgSERBIENPREVD IFBDTSAoUmVhciBEaWdpdGFsKT4gYXQgbmlkIDMwIG9uIGhkYWEwCnBjbTE6ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMTogfCBEVU1QSU5HIFBDTSBQbGF5YmFj ay9SZWNvcmQgQ2hhbm5lbHMgfApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCnBjbTE6IApwY20xOiBQbGF5YmFjazoKcGNtMTogCnBjbTE6ICAgICAgU3RyZWFt IGNhcDogMHgwMDAwMDAwNQpwY20xOiAgICAgICAgICAgICAgICAgIEFDMyBQQ00KcGNtMTogICAg ICAgICBQQ00gY2FwOiAweDAwMWUwNTYwCnBjbTE6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQg MzIgYml0cywgNDQgNDggOTYgMTkyIEtIegpwY20xOiAgICAgICAgICAgICBEQUM6IDYKcGNtMTog CnBjbTE6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20xOiB8IERVTVBJTkcg UGxheWJhY2svUmVjb3JkIFBhdGhzIHwKcGNtMTogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCnBjbTE6IApwY20xOiBQbGF5YmFjazoKcGNtMTogCnBjbTE6ICAgICBuaWQ9MzAgW3Bp bjogU1BESUYtb3V0IChCbGFjayBKYWNrKV0KcGNtMTogICAgICAgfApwY20xOiAgICAgICArIDwt IG5pZD02IFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMTogCnBjbTE6ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwpwY20xOiB8IERVTVBJTkcgVm9sdW1lIENvbnRyb2xzIHwKcGNtMTog Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTE6IApwY20xOiBGb3JjaW5nIFNvZnQgUENN IHZvbHVtZQpwY20xOiBGb3JjaW5nIG1hc3RlciB2b2x1bWUgd2l0aCBQQ00KcGNtMTogTWl4ZXIg InZvbCIgLT4gIm5vbmUiOiBjaGlsZD0weDAwMDAwMDEwCnBjbTE6IE1peGVyICJwY20iOiBwYXJl bnQ9InZvbCIKcGNtMTogU29mdCBQQ00gbWl4ZXIgRU5BQkxFRApwY20xOiBjbG9uZSBtYW5hZ2Vy OiBkZWFkbGluZT03NTBtcyBmbGFncz0weDgwMDAwMDFlCnBjbTE6IHNuZGJ1Zl9zZXRtYXAgNDQ5 MzAwMCwgNDAwMDsgMHhlYzA5MzAwMCAtPiA0NDkzMDAwCmhkYWNjMTogPEx1Y2VudC9BZ2VyZSBT eXN0ZW1zICgweDEwNDApIEhEQSBDT0RFQz4gYXQgY2FkIDEgb24gaGRhYzAKaGRhY2MxOiBSb290 IE5vZGUgYXQgbmlkPTA6IDEgc3Vibm9kZXMgMS0xCnVua25vd246IDxMdWNlbnQvQWdlcmUgU3lz dGVtcyAoMHgxMDQwKSBIREEgQ09ERUMgTW9kZW0gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9u IGhkYWNjMSAobm8gZHJpdmVyIGF0dGFjaGVkKQp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzNDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNi dXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPElu dGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czEKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6 IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVz YnVzNAp1aHViNDogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2J1czQKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmF0YTA6IFNBVEEgcmVzZXQ6IHBvcnRz IHN0YXR1cz0weDAxCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAK YXRhMDogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiBzdGF0MT0w eDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBz dGF0MT0wMCBkZXZpY2VzPTB4MQooYXByb2JlMDphdGEwOjA6MDowKTogU0lHTkFUVVJFOiAwMDAw CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDEKYXRhMTogc3RhdDA9 MHgxMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExOiBzdGF0MT0weDAxIGVycj0weDA0 IGxzYj0weDAwIG1zYj0weDAwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0xMCBzdGF0MT0wMSBkZXZp Y2VzPTB4MTAwMDAKKGFwcm9iZTE6YXRhMTowOjA6MCk6IFNJR05BVFVSRTogZWIxNAphY3BpX2Fj YWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gc3RhcnQKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlh bGl6YXRpb24gc3RhcnQKYWNwaV9hY2FkMDogT24gTGluZQphY3BpX2FjYWQwOiBhY2xpbmUgaW5p dGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwp1aHViNDogOCBwb3J0cyB3aXRoIDggcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKKHByb2JlMDpjdGwyY2FtMDowOjE6MCk6IEVycm9yIDYsIFVu cmV0cnlhYmxlIGVycm9yCkdFT006IG5ldyBkaXNrIGNkMAphZGEwIGF0IGF0YTAgYnVzIDAgc2Ni dXMwIHRhcmdldCAwIGx1biAwCmFkYTA6IChjZDA6YXRhMTowOjA6MCk6IFNDU0kgc3RhdHVzIGVy cm9yCihjZDA6YXRhMTowOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAg MCAwIDAgCihjZDA6YXRhMTowOjA6MCk6IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihj ZDA6YXRhMTowOjA6MCk6IFNDU0kgc3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGNkMDphdGExOjA6 MDowKTogU0NTSSBzZW5zZTogTk9UIFJFQURZIGFzYzozYSwxIChNZWRpdW0gbm90IHByZXNlbnQg LSB0cmF5IGNsb3NlZCkKKGNkMDphdGExOjA6MDowKTogRXJyb3IgNiwgVW5yZXRyeWFibGUgZXJy b3IKY2QwIGF0IGF0YTEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCmNkMDogPE9wdGlhcmMg RFZEIFJXIEFELTc1MzBBIEVYMzE+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2Qw OiBTZXJpYWwgTnVtYmVyIDMwNjQ1NDAwIDE0NDY3NDJRMTExCmNkMDogMzMuMzAwTUIvcyB0cmFu c2ZlcnMgKFVETUEyLCBBVEFQSSAxMmJ5dGVzLCBQSU8gNjU1MzRieXRlcykKY2QwOiBBdHRlbXB0 IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNl bnQgLSB0cmF5IGNsb3NlZAo8U1Q5MTYwODIxQVMgMy5BTEQ+IEFUQS03IFNBVEEgMS54IGRldmlj ZQphZGEwOiBTZXJpYWwgTnVtYmVyIDVNQTMyQ1BOCmFkYTA6IDE1MC4wMDBNQi9zIHRyYW5zZmVy cyAoU0FUQSwgVURNQTUsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IDE1MjYyN01CICgzMTI1ODE4MDgg NTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMDogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQwCihjZDA6YXRhMTowOjA6MCk6IFNDU0kgc3RhdHVzIGVycm9yCihjZDA6YXRh MTowOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgCihjZDA6 YXRhMTowOjA6MCk6IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihjZDA6YXRhMTowOjA6 MCk6IFNDU0kgc3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGNkMDphdGExOjA6MDowKTogU0NTSSBz ZW5zZTogTk9UIFJFQURZIGFzYzozYSwxIChNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3Nl ZCkKKGNkMDphdGExOjA6MDowKTogRXJyb3IgNiwgVW5yZXRyeWFibGUgZXJyb3IKcGFzczAgYXQg YXRhMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxTVDkxNjA4MjFBUyAzLkFM RD4gQVRBLTcgU0FUQSAxLnggZGV2aWNlCnBhc3MwOiBTZXJpYWwgTnVtYmVyIDVNQTMyQ1BOCnBh c3MwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEsIFVETUE1LCBQSU8gODE5MmJ5dGVzKQpw YXNzMSBhdCBhdGExIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMApwYXNzMTogPE9wdGlhcmMg RFZEIFJXIEFELTc1MzBBIEVYMzE+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKcGFz czE6IFNlcmlhbCBOdW1iZXIgMzA2NDU0MDAgMTQ0Njc0MlExMTEKcGFzczE6IDMzLjMwME1CL3Mg dHJhbnNmZXJzIChVRE1BMiwgQVRBUEkgMTJieXRlcywgUElPIDY1NTM0Ynl0ZXMpCihjZDA6YXRh MTowOjA6MCk6IFNDU0kgc3RhdHVzIGVycm9yCihjZDA6YXRhMTowOjA6MCk6IFJFQUQgQ0FQQUNJ VFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgCihjZDA6YXRhMTowOjA6MCk6IENBTSBzdGF0 dXM6IFNDU0kgU3RhdHVzIEVycm9yCihjZDA6YXRhMTowOjA6MCk6IFNDU0kgc3RhdHVzOiBDaGVj ayBDb25kaXRpb24KKGNkMDphdGExOjA6MDowKTogU0NTSSBzZW5zZTogTk9UIFJFQURZIGFzYzoz YSwxIChNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZCkKKGNkMDphdGExOjA6MDowKTog RXJyb3IgNiwgVW5yZXRyeWFibGUgZXJyb3IKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCmNwdTEg QVA6CiAgICAgSUQ6IDB4MDEwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAwMDAwMDAw IERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQ UjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTog MHgwMDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwClRTQyB0aW1lY291bnRl ciBkaXNhYmxlZDogQzMgZW5hYmxlZC4KVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDE3MzM0 Mzk2OTUgSHogcXVhbGl0eSAtMTAwMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBl eHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KKGNkMDphdGExOjA6MDowKTogU0NTSSBzdGF0dXMg ZXJyb3IKKGNkMDphdGExOjA6MDowKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAwIDAgMCAwIDAg MCAwIDAgMCAKKGNkMDphdGExOjA6MDowKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IK KGNkMDphdGExOjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlvbgooY2QwOmF0YTE6 MDowOjApOiBTQ1NJIHNlbnNlOiBOT1QgUkVBRFkgYXNjOjNhLDEgKE1lZGl1bSBub3QgcHJlc2Vu dCAtIHRyYXkgY2xvc2VkKQooY2QwOmF0YTE6MDowOjApOiBFcnJvciA2LCBVbnJldHJ5YWJsZSBl cnJvcgpHRU9NOiBuZXcgZGlzayBhZGEwClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9k ZXYvYWRhMHAyIFtyd10uLi4Kc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKYmF0dGVyeTA6 IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMiB0aW1lcwptc2swOiBsaW5rIHN0 YXRlIGNoYW5nZWQgdG8gVVAK --20cf303b3a2dfc0a6904b76012b9-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:52:59 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC9A9106566C; Wed, 25 Jan 2012 21:52:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBBBB8FC0A; Wed, 25 Jan 2012 21:52:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14839; Wed, 25 Jan 2012 23:52:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RqAlx-0006vT-0A; Wed, 25 Jan 2012 23:52:53 +0200 Message-ID: <4F2079B3.80305@FreeBSD.org> Date: Wed, 25 Jan 2012 23:52:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> In-Reply-To: <20120124123245.GZ16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:52:59 -0000 on 24/01/2012 14:32 Gleb Smirnoff said the following: > Yes, now: > > Rebooting... > lock order reversal: > 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 > 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ /usr/src/head/sys/dev/uart/uart_cpu.h:92 > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no new details... It's still intriguing to me why the LOR *doesn't* happen [*] with stop_scheduler_on_panic=0. But I don't see a productive way to pursue this investigation further. [*] - or maybe better to say why it isn't detected/reported. > cpuid = 0 > KDB: enter: panic > [ thread pid 1 tid 100001 ] > Stopped at kdb_enter+0x3b: movq $0,0x5159f2(%rip) > db> bt > Tracing pid 1 tid 100001 td 0xfffffe0001d5e000 > kdb_enter() at kdb_enter+0x3b > panic() at panic+0x1c7 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f > cnputs() at cnputs+0x7a > putchar() at putchar+0x11f > kvprintf() at kvprintf+0x83 > vprintf() at vprintf+0x85 > printf() at printf+0x67 Maybe kdb_backtrace ought to use db_printf. > kdb_backtrace() at kdb_backtrace+0x2d > _witness_debugger() at _witness_debugger+0x2c > witness_checkorder() at witness_checkorder+0x854 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99 > uart_cnputc() at uart_cnputc+0x3e > cnputc() at cnputc+0x4c > cnputs() at cnputs+0x26 > putchar() at putchar+0x11f > kvprintf() at kvprintf+0x83 > vprintf() at vprintf+0x85 > printf() at printf+0x67 > cpu_reset() at cpu_reset+0x81 > kern_reboot() at kern_reboot+0x3a5 > sys_reboot() at sys_reboot+0x42 > amd64_syscall() at amd64_syscall+0x39e > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 --- -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 22:44:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D337A106564A for ; Wed, 25 Jan 2012 22:44:49 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 608808FC12 for ; Wed, 25 Jan 2012 22:44:48 +0000 (UTC) Received: by bkbc12 with SMTP id c12so6532532bkb.13 for ; Wed, 25 Jan 2012 14:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8eJwYWswOcoOxgubQfXSDOH3pJtEeeZAH1yo8ohs2IQ=; b=yBEHKwVhjgrxHibUbFDu2j5mX3PZfAbkCW/xYk78FqBK0bGdK9oOE9PmStijQwGbLQ 42lUyS0mvAqvT86EcSBNgNw3PhpIAIDs2wTGd6WaKDnwLpS4Xxf9dkCVvLw9ZsXqYy0k IF5d3rIWw3sYflZPRkjpcDE4WAo1ielgB89xM= MIME-Version: 1.0 Received: by 10.205.129.20 with SMTP id hg20mr8028691bkc.77.1327531488135; Wed, 25 Jan 2012 14:44:48 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.204.179.15 with HTTP; Wed, 25 Jan 2012 14:44:48 -0800 (PST) In-Reply-To: <666472979.73336.1327451522107.JavaMail.root@erie.cs.uoguelph.ca> References: <666472979.73336.1327451522107.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 25 Jan 2012 14:44:48 -0800 X-Google-Sender-Auth: AEAa6BbVe4Q4hAuUFCN0-wXlUeI Message-ID: From: Craig Rodrigues To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: NFS clients can now fail "mount -u -o udp..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:44:49 -0000 On Tue, Jan 24, 2012 at 4:32 PM, Rick Macklem wrote: > > As such, specifying "udp" or "mntudp" options in the /etc/fstab > entry for "/" on a diskless NFS client could result in the "mount -u" > failing. I'd suggest that "udp" and "mntudp" be avoided for this > case, if you are using the default of TCP for the root mnt done > when the diskless client is booted. If a user boots with an NFS root mount, and does not specify UDP or TCP, what is the default transport protocol used? If I user does: "mount -t nfs ...." or "mount_nfs ...." from the command-line, and does not specify UDP or TCP, what is the default transport protocol used? I would like to see the default become TCP in both cases. It would solve a lot of "FreeBSD out of the box" problems when interacting with more modern NFS servers. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 22:55:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49FEA106568C for ; Wed, 25 Jan 2012 22:55:05 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F22798FC1E for ; Wed, 25 Jan 2012 22:55:04 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 5480F60E5; Wed, 25 Jan 2012 17:55:03 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=G9r7o02NLkWl89RqIXzhWavZIOcXaEQBjgzB3FGkmWt0oDQ6PVyuiniz3syoRNGxt 9vnDac46YsXwgO1+PPQVZNLZWQe/somIUu/HGPYJTv7+bNcbuAleRqgGSWWtp1z Message-ID: <4F208843.5000100@protected-networks.net> Date: Wed, 25 Jan 2012 17:54:59 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Craig Rodrigues References: <666472979.73336.1327451522107.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: Heads Up: NFS clients can now fail "mount -u -o udp..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:55:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/25/12 17:44, Craig Rodrigues wrote: > If a user boots with an NFS root mount, and does not specify > UDP or TCP, what is the default transport protocol used? > > If I user does: "mount -t nfs ...." or "mount_nfs ...." > from the command-line, and does not specify UDP or TCP, what is the > default transport protocol used? > > I would like to see the default become TCP in both cases. > It would solve a lot of "FreeBSD out of the box" problems when interacting > with more modern NFS servers. The default is TCP, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8giEMACgkQQv9rrgRC1JLfTwCgp+5xi6/5tCoQpGER+TpR+LPK 2psAoMm7YVqCBdC/F/rGReWLMIXuNUBr =GVHN -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 23:02:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F35C7106564A; Wed, 25 Jan 2012 23:02:29 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8EC8FC14; Wed, 25 Jan 2012 23:02:28 +0000 (UTC) Received: by eekb47 with SMTP id b47so2381385eek.13 for ; Wed, 25 Jan 2012 15:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=WjB/NruIzI/zEyzcqupp/XGE45Hc75IuW4sQ4LJL4ZU=; b=etcV5PMWgq3JX4wMtW0DxEmm4ng1/mBkeEKJ6duLsILKZtMfX8XmsKbwlNyP+n2viE /of70ckeYHSC3/V+zC11eY9LGVrQsCtGKOyPl1T/7yFWSMB2al9cTarU7wZ5DT9xXg4U SjeS5hPmcdcF0woQLAqc8WdkdgwdYNMGX6W58= Received: by 10.14.17.30 with SMTP id i30mr6700993eei.0.1327530933751; Wed, 25 Jan 2012 14:35:33 -0800 (PST) Received: from [192.168.0.104] ([95.232.4.130]) by mx.google.com with ESMTPS id b49sm7225780eec.9.2012.01.25.14.35.31 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 14:35:32 -0800 (PST) Sender: K Macy Message-ID: <4F208413.8020901@freebsd.org> Date: Wed, 25 Jan 2012 23:37:07 +0100 From: Kip Macy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Kostik Belousov References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> <4F206D6A.3030302@FreeBSD.org> <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Milan Obuch , freebsd-current@freebsd.org, Andreas Tobler , avg@freebsd.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:02:30 -0000 > FWIW, it is not 'call doadump', it is just 'dump' for some time. > I think calling doadump does not work. When I tested my dump changes against head a week ago ddb> call doadump() provided the same functionality as it always has. Cheers From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 23:28:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928FC106564A for ; Wed, 25 Jan 2012 23:28:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 03DDC8FC0C for ; Wed, 25 Jan 2012 23:28:30 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0PMtj4X073477 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 14:55:45 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2088B7.7030308@freebsd.org> Date: Wed, 25 Jan 2012 14:56:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: John Baldwin References: <201201191739.48327.tijl@coosemans.org> <201201201412.13269.jhb@freebsd.org> <201201251129.22368.jhb@freebsd.org> In-Reply-To: <201201251129.22368.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Tijl Coosemans Subject: Re: posix_fadvise noreuse disables file caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:28:31 -0000 On 1/25/12 8:29 AM, John Baldwin wrote: > > So I've came up with this untested patch. It uses > VOP_ADVISE(FADV_DONTNEED) after read(2) calls to a NOREUSE region, and > leaves read-ahead caching enabled for NOREUSE. FADV_DONTNEED doesn't > do any good really for writes (it only flushes clean buffers), so I've > left write(2) operations as using IO_DIRECT still. Does this sound > reasonable? That sounds like a good solution. If people want something from write they can do it separately. For what it's worth, I would expect NOREUSE on write to still do write clustering but to free the buffer once it is written. From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 23:33:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD63C106564A for ; Wed, 25 Jan 2012 23:33:35 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8530A8FC12 for ; Wed, 25 Jan 2012 23:33:35 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id ED06CAAC93 for ; Thu, 26 Jan 2012 00:18:26 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id SLfY6OXC9j6X for ; Thu, 26 Jan 2012 00:18:24 +0100 (CET) Received: from danger-mbp.local (adsl-dyn189.91-127-166.t-com.sk [91.127.166.189]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 6601CAAC81 for ; Thu, 26 Jan 2012 00:18:24 +0100 (CET) Message-ID: <4F208DC1.5070005@FreeBSD.org> Date: Thu, 26 Jan 2012 00:18:25 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.25pre) Gecko/20111117 Lanikai/3.1.17pre MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20120105045311.GA40378@nargothrond.kdm.org> In-Reply-To: <20120105045311.GA40378@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CAM Target Layer available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:33:35 -0000 On 5.1.2012 5:53, Kenneth D. Merry wrote: > > The CAM Target Layer (CTL) is now available for testing. I am planning to > commit it to to head next week, barring any major objections. Hello, aren't you interested in covering this work through the freebsd status report? If so please follow the instructions at http://freebsd.org/news/status/ and let me know ASAP as I am going to release the status report real soon now. Thanks! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 00:02:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8F106564A for ; Thu, 26 Jan 2012 00:02:29 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by mx1.freebsd.org (Postfix) with ESMTP id A84218FC13 for ; Thu, 26 Jan 2012 00:02:28 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTyCYE/znZ7GXo3FdtpvMv0PZJGvth2Yw@postini.com; Wed, 25 Jan 2012 16:02:28 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 25 Jan 2012 15:48:23 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q0PNm9100485; Wed, 25 Jan 2012 15:48:20 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F2094B4.70707@juniper.net> Date: Wed, 25 Jan 2012 15:48:04 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120125074824.GD2726@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Jan 2012 00:12:36 +0000 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 00:02:29 -0000 Thanks for taking a look at it. I'll try to explain the changes the best I can: the work was done nearly 6 months ago... > I would certainly appreciate some more words describing the changes. > > What is the goal of introducing the PT_FOLLOW_EXEC ? To not force > the debugger to filter all syscall exits to see exec events ? PT_FOLLOW_EXEC was added to trace the exec() family of calls. When it's enabled, the kernel will generate a trap to give debugger a chance to clean up old process info and initialize its state with the new binary. > > Why did you moved the stopevent/ptracestop for exec events from > syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC > is not removed from syscallret() ? I do not think that TDB_EXEC can be > seen there after the patch. The same question about TDB_FORK. The reason I moved the event notifications from syscallret() is because the debugger is interested successful completion of either fork or exec, not just the fact that they have been called. If, say, a call to fork() failed, as far as debugger is concerned, fork() might as well had never been called. Having a ptracestop in syscallret triggered a trap on every return from fork without telling the debugger whether a new process had been created or not. Same goes for exec(). Looking at the code now I think I should have removed TDB_EXEC/TDB_FORK processing from syscallret(). I'll do that and verify that it works as expected. > > If possible, I would greatly prefer to have fork changes separated. You mean separate fork changes into a separate patch from exec changes? > > I doubt that disallowing RFMEM while tracing is the right change. It may > be to fix some (undescribed) bug, but RFMEM is documented behaviour used > not only for vfork(2), and the change just breaks rfork(2) for debugged > processes. > > Even vfork() should not be broken, since I believe there are programs > that rely on the vfork() model, in particular, C shell. It will be > broken if vfork() is substituted by fork(). The fact that it breaks only > under debugger will make it esp. confusing. I need to dig up the details since I can't recall the exact reason for forcing fork() in cases of user calls to vfork() under gdb. I believe it had to do with when child process memory was available for writing in case of vfork() and it wasn't early enough to complete the switch over from parent to child in gdb. After consulting with our internal kernel experts we decided that doing fork() instead of vfork() under gdb is a low impact change. > > Why do we need to have TDB_FORK set for td2 ? The debugger needs to intercept fork() in both parent and child so it can detach from the old process and attach to the new one. Maybe it'll make more sense in the context of gdb changes. Should I send them too? Don't think Marcel included that patch... > > Does the orphan list change intended to not lost the child after fork ? > But the child shall be traced, so debugger would get the SIGTRAP on > the attach on fork returning to usermode. I remember that I explicitely > tested this when adding followfork changes. Yes, the debugger gets SIGTRAPs. The problem arises when the real parent of the forked process has the code to collect termination status. Since attaching to a process changes the parent/child relationships, we need to keep track of the children lost due to re-parenting so we can properly attribute their exit status to the "real" parent. From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 04:47:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D111106564A; Thu, 26 Jan 2012 04:47:41 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id C187D8FC12; Thu, 26 Jan 2012 04:47:40 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q0Q4lbB9022991; Wed, 25 Jan 2012 20:47:37 -0800 (PST) (envelope-from freebsd@penx.com) From: Dennis Glatting To: "Kenneth D. Merry" In-Reply-To: <20120120204459.GA51162@nargothrond.kdm.org> References: <20120120204459.GA51162@nargothrond.kdm.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Jan 2012 20:47:37 -0800 Message-ID: <1327553257.19745.6.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q0Q4lbB9022991 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:47:41 -0000 On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote: > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > HBAs as well as WarpDrive controllers, is available here: > > http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > I plan to check it in to head next week, and then MFC it into stable/9 a > week after that most likely. > > Please test it out and let me know if you run into any problems. > > In addition to supporting WarpDrive, the driver also supports Integrated > RAID. > > Thanks to LSI for doing the work on this driver! > Does this include the SAS2008 series chips? I have two systems, one a Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am interested in using a driver under 9.0 amd64. > I have added a number of other infrastructure changes that are necessary > for the driver, and here is a brief summary: > > - A new Advanced Information buffer is now added to the EDT for drives > that support READ CAPACITY (16). The da(4) driver updates this buffer > when it grabs new read capacity data from a drive. > - The mps(4) driver will look for Advanced Information state change async > events, and updates its table of drives with protection information > turned on accordingly. > - The size of struct scsi_read_capacity_data_long has been bumped up to > the amount specified in the latest SBC-3 draft. The hope is to avoid > some future structure size bumps with that change. The API for > scsi_read_capacity_16() has been changed to add a length argument. > Hopefully this will future-proof it somewhat. > - __FreeBSD_version bumped for the addition of the Advanced Information > buffer with the read capacity information. The mps(4) driver has a > kludgy way of getting the information on versions of FreeBSD without > this change. > > I believe that the CAM API changes are mild enough and beneficial enough > for a merge into stable/9, but they are intertwined with the unmap changes > in the da(4) driver, so those changes will have to go back to stable/9 as > well in order to MFC the full set of changes. > > Otherwise it'll just be the driver that gets merged into stable/9, and > it'll use the kludgy method of getting the read capacity data for each > drive. > > A couple of notes about issues with this driver: > > - Unlike the current mps(4) driver, it probes sequentially. If you have a > lot of drives in your system, it will take a while to probe them all. > - You may see warning messages like this: > > _mapping_add_new_device: failed to add the device with handle 0x0019 to persiste > nt table because there is no free space available > _mapping_add_new_device: failed to add the device with handle 0x001a to persiste > nt table because there is no free space available > > - The driver is not endian safe. (It assumes a little endian machine.) > This is not new, the driver in the tree has the same issue. > > The LSI folks know about these issues. The driver has passed their testing > process. > > Many thanks to LSI for going through the effort to support FreeBSD. > > Ken From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 04:54:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B0251065679; Thu, 26 Jan 2012 04:54:10 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id E98D08FC18; Thu, 26 Jan 2012 04:54:09 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q0Q4s9NY090929; Wed, 25 Jan 2012 21:54:09 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q0Q4s9i7090928; Wed, 25 Jan 2012 21:54:09 -0700 (MST) (envelope-from ken) Date: Wed, 25 Jan 2012 21:54:09 -0700 From: "Kenneth D. Merry" To: Dennis Glatting Message-ID: <20120126045409.GA90912@nargothrond.kdm.org> References: <20120120204459.GA51162@nargothrond.kdm.org> <1327553257.19745.6.camel@btw.pki2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1327553257.19745.6.camel@btw.pki2.com> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:54:10 -0000 On Wed, Jan 25, 2012 at 20:47:37 -0800, Dennis Glatting wrote: > On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote: > > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > > HBAs as well as WarpDrive controllers, is available here: > > > > http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt > > > > I plan to check it in to head next week, and then MFC it into stable/9 a > > week after that most likely. > > > > Please test it out and let me know if you run into any problems. > > > > In addition to supporting WarpDrive, the driver also supports Integrated > > RAID. > > > > Thanks to LSI for doing the work on this driver! > > > > Does this include the SAS2008 series chips? I have two systems, one a > Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am > interested in using a driver under 9.0 amd64. Yes. The driver in 9.0 supports the 2008 as well. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 09:12:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2CAC106564A for ; Thu, 26 Jan 2012 09:12:57 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1AE8FC15 for ; Thu, 26 Jan 2012 09:12:56 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Thu, 26 Jan 2012 10:10:33 +0100 id 00033CD1.4F211889.00014EE9 Date: Thu, 26 Jan 2012 10:12:53 +0100 From: Milan Obuch To: Andreas Tobler Message-ID: <20120126101253.423a83c8@atom.dino.sk> In-Reply-To: <4F206D6A.3030302@FreeBSD.org> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> <4F206D6A.3030302@FreeBSD.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Eitan Adler , freebsd-current@FreeBSD.org Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 09:12:57 -0000 On Wed, 25 Jan 2012 22:00:26 +0100 Andreas Tobler wrote: > On 25.01.12 21:29, Eitan Adler wrote: > > On Wed, Jan 25, 2012 at 2:50 PM, Milan > > Obuch wrote: > >> On Wed, 25 Jan 2012 14:21:23 +0200 > >> Kostik Belousov wrote: > >> [ snip ] > >>>> Tracing pid 1442 tid 100095 td 0x2d6b000 > >>>> 0xe22c26d0: at panic+0x274 > >>>> 0xe22c2730: at _mtx_lock_flags+0xc4 > >>>> 0xe22c2760: at vgonel+0x330 > >>>> 0xe22c27b0: at vrecycle+0x54 > >>>> 0xe22c27d0: at null_inactive+0x30 > >>>> 0xe22c27f0: at VOP_INACTIVE_APV+0xdc > >>>> 0xe22c2810: at vinactive+0x98 > >>>> 0xe22c2850: at vputx+0x344 > >>>> 0xe22c28a0: at vput+0x18 > >>>> 0xe22c28c0: at kern_statat_vnhook+0x108 > >>>> 0xe22c29d0: at kern_statat+0x18 > >>>> 0xe22c29f0: at kern_lstat+0x2c > >>>> 0xe22c2a10: at sys_lstat+0x30 > >>>> 0xe22c2a90: at trap+0x388 > >>>> 0xe22c2b60: at powerpc_interrupt+0x108 > >>>> 0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=0xd032 > >>>> r1=0xffaf9a70 cr=0x28004044 xer=0x20000000 > >>>> ctr=0x41a0ac40 > >>>> db> > >>>> > >>>> Does this shed any light for someone with more knowledge here? My > >>>> gut feeling is there is some endianness issue at play, the same > >>>> nullfs usage works for me flawlessly on both i386 and amd64 > >>>> systems, so it could not be 32 vs 64 bit issue at least. > >>>> > >>>> At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of > >>>> function void vgonel(struct vnode *vp) > >>>> > >>>> VI_LOCK(vp); > >>>> vp->v_vnlock =&vp->v_lock; > >>>> vp->v_op =&dead_vnodeops; > >>>> vp->v_tag = "none"; > >>>> vp->v_type = VBAD; > >>>> } > >>>> > >>>> so the question seems to be reduced to 'why is vp null?' or is my > >>>> small attempt on analyse flawed... > >> > >>> I do not think that the vp is null. It more look like the *vp > >>> memory was zeroed. This has very low chances of being related to > >>> endianess, and more like a kernel memory corruption. > >>> > >>> Take a dump and print the content of *vp. > >> > >> How could I look into memory? I found page > >> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html > >> and I can see registers (show reg), use x with absolute addresses, > >> but something like 'x vp' tells just 'Symbol not known' - should I > >> somehow load symbol table into memory? But backtrace shows > >> function names... or should I somehow modify GENERIC kernel to > >> include more debugging info? Kernel debugging is a bit new for me, > >> even if I can write simple modification into kernel, but only in > >> some special (and narrow) area of code... > > > >> From ddb write 'call doadump'. Provided you have a proper dump > >> device > > set up in rc.conf it should work. You could then use kgdb from a > > running computer to analyze the dump in more detail. > > This only works if your target is booke, AIM (Apple based machines) > do not have the 'call doadump' implemented yet. It is somewhere on my > long todo list. > So I looked for an ideas, found http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html and tried it but no good result - as both dump and call doadump dumped 0 MB memory... only method available now seems to be live debug until dump is implemented for AIM... if you have anything to test, just write me. In the meantime, I will try to get something, just no real idea yet how. Anyway, the more I test the more it looks like some memory corruption issue, which is a bit more to investigate - real issue could be well in some other area as it manifests itself... So if anybody has any advice what to look for, I can try it. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 10:38:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE45106566B; Thu, 26 Jan 2012 10:38:39 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B52378FC15; Thu, 26 Jan 2012 10:38:38 +0000 (UTC) Received: by lahj13 with SMTP id j13so312825lah.13 for ; Thu, 26 Jan 2012 02:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=HqWd5iZW1WiwuOZ9sIeYsFX6AWx7GDad3gPgdsc8k/M=; b=VWG/fclr0MNQYkGEsMIxA+bUt8OV7ZWjO8VTUBomMIpUYLRq4Jlz1A+099BCMQ8qMQ dz0/WBUgW1+Hiqf8CD3aYh0S0PrVreIbo2E8xx8TMdE8WzOACvbY7133C6nz4IL3cGzg oVtwNVwaTxx6SFN6gmQnM+PYBJjavuiZs0z/o= Received: by 10.112.29.6 with SMTP id f6mr364099lbh.69.1327572462897; Thu, 26 Jan 2012 02:07:42 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id k4sm2720023lbw.10.2012.01.26.02.07.40 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 02:07:41 -0800 (PST) Date: Thu, 26 Jan 2012 12:07:46 +0200 From: Gleb Kurtsou To: Jean-S?bastien P?dron Message-ID: <20120126100745.GA62071@reks> References: <4F1EBF42.4050307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F1EBF42.4050307@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Romain Vrignaud , Pierre-Gilles Mialon , freebsd-current@freebsd.org Subject: Re: [patch] pam_exec: use program exit code instead of PAM_SYSTEM_ERR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 10:38:39 -0000 On (24/01/2012 15:25), Jean-S?bastien P?dron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > If the specified program exits with non-zero, current implementation > of pam_exec(8) logs this code and return PAM_SYSTEM_ERR. Therefore, > applications have no idea what went wrong with authentication. > > Attached is a patch that changes the behaviour to always return the > program exit code as-is. This lets the program returns meaningful > informations to applications. > > I also added a small paragraph explaining this to the man page. > > I'm planning to commit this to -CURRENT (maybe in a week or two) and > merge it to 9 and 8 if there're no objections. Please consider making it optional. It will break for generic applications because pam_sm_chauthtok error codes are documented and standardized. I'm not aware of any application that uses PAM error constants as exit code. Thanks, Gleb. > > Thanks for any comments! > > - -- > Jean-Sébastien Pédron > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8ev0IACgkQa+xGJsFYOlNjyACfSg6NgDLy+7VF6rEVV6yTINTd > rlgAoNpgWLvYBEL2DCejuPDz0yQRf5QY > =JEte > -----END PGP SIGNATURE----- > diff --git a/lib/libpam/modules/pam_exec/pam_exec.8 b/lib/libpam/modules/pam_exec/pam_exec.8 > index 311d64c..c5d2404 100644 > --- a/lib/libpam/modules/pam_exec/pam_exec.8 > +++ b/lib/libpam/modules/pam_exec/pam_exec.8 > @@ -32,7 +32,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd February 1, 2005 > +.Dd January 24, 2012 > .Dt PAM_EXEC 8 > .Os > .Sh NAME > @@ -59,6 +59,12 @@ variables: > .Ev PAM_TTY , > and > .Ev PAM_USER . > +.Pp > +The program exit code should be one of the codes defined in > +.Pa /usr/include/security/pam_constants.h > +under section "XSSO 5.2". Authentication is successful if the return code is > +.Er PAM_SUCCESS > +(0), failed otherwise. > .Sh SEE ALSO > .Xr pam_get_item 3 , > .Xr pam.conf 5 , > diff --git a/lib/libpam/modules/pam_exec/pam_exec.c b/lib/libpam/modules/pam_exec/pam_exec.c > index b7a870f..d497479 100644 > --- a/lib/libpam/modules/pam_exec/pam_exec.c > +++ b/lib/libpam/modules/pam_exec/pam_exec.c > @@ -141,12 +141,7 @@ _pam_exec(pam_handle_t *pamh __unused, int flags __unused, > openpam_log(PAM_LOG_ERROR, "unknown status 0x%x", status); > return (PAM_SYSTEM_ERR); > } > - if (WEXITSTATUS(status) != 0) { > - openpam_log(PAM_LOG_ERROR, "%s returned code %d", > - argv[0], WEXITSTATUS(status)); > - return (PAM_SYSTEM_ERR); > - } > - return (PAM_SUCCESS); > + return (WEXITSTATUS(status)); > } > > PAM_EXTERN int > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 10:46:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B52106566B for ; Thu, 26 Jan 2012 10:46:25 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01C828FC17 for ; Thu, 26 Jan 2012 10:46:24 +0000 (UTC) Received: by qcse14 with SMTP id e14so308895qcs.13 for ; Thu, 26 Jan 2012 02:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uI55+DNZL5fFFokhIopSgv0r0ob18Ek/RIp+QSliAAo=; b=SGaIjRynwITAs7aK1JRvZBu1KbpkCQaZYf+UPIOyKAEdyOPCrxmYd1JKQseZ0m1cGE bcLBy/BFx+1m0tENfq5wd0WQf5wMADozLNeFADiIehyHx3sm9Xb6tfVhnm7AX28wO3z2 GHso5VzHstjO3JV0WxGOY/RyjuGMGuZsnGzLU= MIME-Version: 1.0 Received: by 10.224.212.134 with SMTP id gs6mr1659132qab.32.1327574784070; Thu, 26 Jan 2012 02:46:24 -0800 (PST) Received: by 10.229.223.135 with HTTP; Thu, 26 Jan 2012 02:46:23 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Jan 2012 05:46:23 -0500 Message-ID: From: Kim Culhan To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 26 Jan 2012 12:04:31 +0000 Cc: Subject: Re: msk0: watchdog timeout interface hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 10:46:25 -0000 On Wed, Jan 25, 2012 at 3:26 PM, Kim Culhan wrote: > Running 10-curent from 01-20-12 > the msk0 interface hung, on the console: > > msk0: watchdog timeout > msk0: prefetch unit stuck? > msk0: initialization failed: no memory for Rx buffers > > Verbose boot dmesg output attached. This additional datapoint found, at boot after the last line in the verbose dmesg this line was logged to messages: Jan 25 15:21:19 foo kernel: interrupt storm detected on "irq257:"; throttling interrupt source Hope this helps. thanks -kiim From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 12:23:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606B7106564A for ; Thu, 26 Jan 2012 12:23:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E841F8FC12 for ; Thu, 26 Jan 2012 12:23:34 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0QCNRGo065184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 14:23:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0QCNRLT035256; Thu, 26 Jan 2012 14:23:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0QCNQUv035255; Thu, 26 Jan 2012 14:23:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Jan 2012 14:23:26 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120126122326.GT2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r3KnbM2MoJFBL7Dl" Content-Disposition: inline In-Reply-To: <4F2094B4.70707@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:23:35 -0000 --r3KnbM2MoJFBL7Dl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote: > Thanks for taking a look at it. I'll try to explain the changes the best = I=20 > can: the work was done nearly 6 months ago... >=20 > >I would certainly appreciate some more words describing the changes. > > > >What is the goal of introducing the PT_FOLLOW_EXEC ? To not force > >the debugger to filter all syscall exits to see exec events ? >=20 > PT_FOLLOW_EXEC was added to trace the exec() family of calls. When it's= =20 > enabled, the kernel will generate a trap to give debugger a chance to cle= an=20 > up old process info and initialize its state with the new binary. >=20 It was more a question, why PT_FLAG_EXEC is not enough. >=20 >=20 > > > >Why did you moved the stopevent/ptracestop for exec events from > >syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC > >is not removed from syscallret() ? I do not think that TDB_EXEC can be > >seen there after the patch. The same question about TDB_FORK. >=20 > The reason I moved the event notifications from syscallret() is because t= he=20 > debugger is interested successful completion of either fork or exec, not= =20 > just the fact that they have been called. If, say, a call to fork() faile= d,=20 > as far as debugger is concerned, fork() might as well had never been=20 > called. Having a ptracestop in syscallret triggered a trap on every retur= n=20 > from fork without telling the debugger whether a new process had been=20 > created or not. Same goes for exec(). PT_FLAG_EXEC is only set if an exec-kind of syscall succeeded. The same is true for PT_FLAG_FORKED, the flag is set only if a new child was successfully created. >=20 > Looking at the code now I think I should have removed TDB_EXEC/TDB_FORK= =20 > processing from syscallret(). I'll do that and verify that it works as=20 > expected. >=20 > > > >If possible, I would greatly prefer to have fork changes separated. >=20 > You mean separate fork changes into a separate patch from exec changes? Yes. Even more, it seems that fork changes should be separated into bug fixes and new functionality. >=20 > > > >I doubt that disallowing RFMEM while tracing is the right change. It may > >be to fix some (undescribed) bug, but RFMEM is documented behaviour used > >not only for vfork(2), and the change just breaks rfork(2) for debugged > >processes. > > > >Even vfork() should not be broken, since I believe there are programs > >that rely on the vfork() model, in particular, C shell. It will be > >broken if vfork() is substituted by fork(). The fact that it breaks only > >under debugger will make it esp. confusing. >=20 > I need to dig up the details since I can't recall the exact reason for=20 > forcing fork() in cases of user calls to vfork() under gdb. I believe it= =20 > had to do with when child process memory was available for writing in cas= e=20 > of vfork() and it wasn't early enough to complete the switch over from=20 > parent to child in gdb. After consulting with our internal kernel experts= =20 > we decided that doing fork() instead of vfork() under gdb is a low impact= =20 > change. >=20 > > > >Why do we need to have TDB_FORK set for td2 ? >=20 > The debugger needs to intercept fork() in both parent and child so it can= =20 > detach from the old process and attach to the new one. Maybe it'll make= =20 > more sense in the context of gdb changes. Should I send them too? Don't= =20 > think Marcel included that patch... No, I think the kernel changes are enough for now. >=20 > > > >Does the orphan list change intended to not lost the child after fork ? > >But the child shall be traced, so debugger would get the SIGTRAP on > >the attach on fork returning to usermode. I remember that I explicitely > >tested this when adding followfork changes. >=20 > Yes, the debugger gets SIGTRAPs. The problem arises when the real parent = of=20 > the forked process has the code to collect termination status. Since=20 > attaching to a process changes the parent/child relationships, we need to= =20 > keep track of the children lost due to re-parenting so we can properly=20 > attribute their exit status to the "real" parent. >=20 I do not quite understand it. From the description it sounds as the problem that is not related to follow fork changes at all, and shall be presented regardless of the follow fork. If yes, I think this shall be separated into a standalone patch. --r3KnbM2MoJFBL7Dl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8hRb4ACgkQC3+MBN1Mb4jGNQCfULh439QfL2w1Ee6a+YbpEFcf srMAn2cMTjcJJERhtUJMg2waeBllWk3B =BUX5 -----END PGP SIGNATURE----- --r3KnbM2MoJFBL7Dl-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 15:25:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE10E106564A for ; Thu, 26 Jan 2012 15:25:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD0F8FC15 for ; Thu, 26 Jan 2012 15:25:25 +0000 (UTC) Received: by ggnq2 with SMTP id q2so353152ggn.13 for ; Thu, 26 Jan 2012 07:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=lOpVPoD2caxgnKclrEyr/mUzeKGUQkhTF9/sNhml9gs=; b=WMZ2HjMNqJdIEpCe6gRUS7w+rtoy6P/qLThgCCwo94sxR9crwIdhAYPhqiMr5K8YgZ wWrrPomLCxEqRKXg9URUVo1kdO/tFtyoj4dNLYGdwPKNz2Vf8ltmQW6x9HvDaZa2/F++ TcwI3tfVL8ITZTL3nnSyuZmx/a516q2wv26zw= MIME-Version: 1.0 Received: by 10.182.0.106 with SMTP id 10mr2599229obd.72.1327591524801; Thu, 26 Jan 2012 07:25:24 -0800 (PST) Received: by 10.182.74.167 with HTTP; Thu, 26 Jan 2012 07:25:24 -0800 (PST) Date: Thu, 26 Jan 2012 18:25:24 +0300 Message-ID: From: Sergey Kandaurov To: FreeBSD Current Content-Type: multipart/mixed; boundary=f46d043c077e3e1d7004b76ffde2 Subject: [patch] fstat: print the owner process for UNIX domain sockets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:25:25 -0000 --f46d043c077e3e1d7004b76ffde2 Content-Type: text/plain; charset=ISO-8859-1 Hi. This patch adds support for fstat(1) to identify which process opened the specified socket file, to bring in line with regular files. E.g.: # fstat /var/run/devd.pipe USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root devd 1259 4* local stream fffffe0002a1a870 /var/run/devd.pipe # fstat /var/run/logpriv USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root syslogd 1495 5* local dgram fffffe0002a1a3c0 /var/run/logpriv Comments are welcome. Index: usr.bin/fstat/fstat.c =================================================================== --- usr.bin/fstat/fstat.c (revision 230505) +++ usr.bin/fstat/fstat.c (working copy) @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include @@ -224,28 +225,53 @@ static void print_file_info(struct procstat *procstat, struct filestat *fst, const char *uname, const char *cmd, int pid) { + struct sockstat sock; struct vnstat vn; DEVS *d; const char *filename; int error, fsmatch = 0; char errbuf[_POSIX2_LINE_MAX]; + error = 0; filename = NULL; if (checkfile != 0) { - if (fst->fs_type != PS_FST_TYPE_VNODE && - fst->fs_type != PS_FST_TYPE_FIFO) + switch (fst->fs_type) { + case PS_FST_TYPE_VNODE: + case PS_FST_TYPE_FIFO: + error = procstat_get_vnode_info(procstat, fst, &vn, errbuf); + break; + case PS_FST_TYPE_SOCKET: + error = procstat_get_socket_info(procstat, fst, &sock, errbuf); + break; + default: return; - error = procstat_get_vnode_info(procstat, fst, &vn, errbuf); + } if (error != 0) return; for (d = devs; d != NULL; d = d->next) - if (d->fsid == vn.vn_fsid) { - fsmatch = 1; - if ((unsigned)d->ino == vn.vn_fileid) { - filename = d->name; - break; + switch (fst->fs_type) { + case PS_FST_TYPE_VNODE: + case PS_FST_TYPE_FIFO: + if (d->fsid == vn.vn_fsid) { + fsmatch = 1; + if ((unsigned)d->ino == vn.vn_fileid) { + filename = d->name; + break; + } } + break; + case PS_FST_TYPE_SOCKET: + if (sock.dom_family == AF_UNIX) { + fsmatch = 1; + if (strcmp(((struct sockaddr_un *) + (&sock.sa_local))->sun_path, + d->name) == 0) { + filename = d->name; + break; + } + } + break; } if (fsmatch == 0 || (filename == NULL && fsflg == 0)) return; -- wbr, pluknet --f46d043c077e3e1d7004b76ffde2 Content-Type: application/octet-stream; name="fstat_un.diff" Content-Disposition: attachment; filename="fstat_un.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gxvxo1v60 SW5kZXg6IHVzci5iaW4vZnN0YXQvZnN0YXQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL2ZzdGF0 L2ZzdGF0LmMJKHJldmlzaW9uIDIzMDUwNSkKKysrIHVzci5iaW4vZnN0YXQvZnN0YXQuYwkod29y a2luZyBjb3B5KQpAQCAtMzgsNiArMzgsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5j bHVkZSA8c3lzL3NvY2tldHZhci5oPgogI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KICNpbmNsdWRl IDxzeXMvcXVldWUuaD4KKyNpbmNsdWRlIDxzeXMvdW4uaD4KIAogI2luY2x1ZGUgPG5ldGluZXQv aW4uaD4KIApAQCAtMjI0LDI4ICsyMjUsNTMgQEAgc3RhdGljIHZvaWQKIHByaW50X2ZpbGVfaW5m byhzdHJ1Y3QgcHJvY3N0YXQgKnByb2NzdGF0LCBzdHJ1Y3QgZmlsZXN0YXQgKmZzdCwKICAgICBj b25zdCBjaGFyICp1bmFtZSwgY29uc3QgY2hhciAqY21kLCBpbnQgcGlkKQogeworCXN0cnVjdCBz b2Nrc3RhdCBzb2NrOwogCXN0cnVjdCB2bnN0YXQgdm47CiAJREVWUyAqZDsKIAljb25zdCBjaGFy ICpmaWxlbmFtZTsKIAlpbnQgZXJyb3IsIGZzbWF0Y2ggPSAwOwogCWNoYXIgZXJyYnVmW19QT1NJ WDJfTElORV9NQVhdOwogCisJZXJyb3IgPSAwOwogCWZpbGVuYW1lID0gTlVMTDsKIAlpZiAoY2hl Y2tmaWxlICE9IDApIHsKLQkJaWYgKGZzdC0+ZnNfdHlwZSAhPSBQU19GU1RfVFlQRV9WTk9ERSAm JgotCQkgICAgZnN0LT5mc190eXBlICE9IFBTX0ZTVF9UWVBFX0ZJRk8pCisJCXN3aXRjaCAoZnN0 LT5mc190eXBlKSB7CisJCWNhc2UgUFNfRlNUX1RZUEVfVk5PREU6CisJCWNhc2UgUFNfRlNUX1RZ UEVfRklGTzoKKwkJCWVycm9yID0gcHJvY3N0YXRfZ2V0X3Zub2RlX2luZm8ocHJvY3N0YXQsIGZz dCwgJnZuLCBlcnJidWYpOworCQkJYnJlYWs7CisJCWNhc2UgUFNfRlNUX1RZUEVfU09DS0VUOgor CQkJZXJyb3IgPSBwcm9jc3RhdF9nZXRfc29ja2V0X2luZm8ocHJvY3N0YXQsIGZzdCwgJnNvY2ss IGVycmJ1Zik7CisJCQlicmVhazsKKwkJZGVmYXVsdDoKIAkJCXJldHVybjsKLQkJZXJyb3IgPSBw cm9jc3RhdF9nZXRfdm5vZGVfaW5mbyhwcm9jc3RhdCwgZnN0LCAmdm4sIGVycmJ1Zik7CisJCX0K IAkJaWYgKGVycm9yICE9IDApCiAJCQlyZXR1cm47CiAKIAkJZm9yIChkID0gZGV2czsgZCAhPSBO VUxMOyBkID0gZC0+bmV4dCkKLQkJCWlmIChkLT5mc2lkID09IHZuLnZuX2ZzaWQpIHsKLQkJCQlm c21hdGNoID0gMTsKLQkJCQlpZiAoKHVuc2lnbmVkKWQtPmlubyA9PSB2bi52bl9maWxlaWQpIHsK LQkJCQkJZmlsZW5hbWUgPSBkLT5uYW1lOwotCQkJCQlicmVhazsKKwkJCXN3aXRjaCAoZnN0LT5m c190eXBlKSB7CisJCQljYXNlIFBTX0ZTVF9UWVBFX1ZOT0RFOgorCQkJY2FzZSBQU19GU1RfVFlQ RV9GSUZPOgkJCQorCQkJCWlmIChkLT5mc2lkID09IHZuLnZuX2ZzaWQpIHsKKwkJCQkJZnNtYXRj aCA9IDE7CisJCQkJCWlmICgodW5zaWduZWQpZC0+aW5vID09IHZuLnZuX2ZpbGVpZCkgeworCQkJ CQkJZmlsZW5hbWUgPSBkLT5uYW1lOworCQkJCQkJYnJlYWs7CisJCQkJCX0KIAkJCQl9CisJCQkJ YnJlYWs7CisJCQljYXNlIFBTX0ZTVF9UWVBFX1NPQ0tFVDoKKwkJCQlpZiAoc29jay5kb21fZmFt aWx5ID09IEFGX1VOSVgpIHsKKwkJCQkJZnNtYXRjaCA9IDE7CisJCQkJCWlmIChzdHJjbXAoKChz dHJ1Y3Qgc29ja2FkZHJfdW4gKikKKwkJCQkJICAgICgmc29jay5zYV9sb2NhbCkpLT5zdW5fcGF0 aCwKKwkJCQkJICAgIGQtPm5hbWUpID09IDApIHsKKwkJCQkJCWZpbGVuYW1lID0gZC0+bmFtZTsK KwkJCQkJCWJyZWFrOworCQkJCQl9CisJCQkJfQorCQkJCWJyZWFrOwogCQkJfQogCQlpZiAoZnNt YXRjaCA9PSAwIHx8IChmaWxlbmFtZSA9PSBOVUxMICYmIGZzZmxnID09IDApKQogCQkJcmV0dXJu Owo= --f46d043c077e3e1d7004b76ffde2-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 16:29:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6346D106564A; Thu, 26 Jan 2012 16:29:28 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B88FC8FC13; Thu, 26 Jan 2012 16:29:27 +0000 (UTC) Received: by eaaa14 with SMTP id a14so291935eaa.13 for ; Thu, 26 Jan 2012 08:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DFrtf6BIjZk/FuvRfPQb+XTMcBKtcpg+JlJ1aYgjcPc=; b=UhGuj6TCxGPQZ+w55YT8zToVTPLEZOctpD9y+r6H2ZTbebgmviquiQJ80C/2KS6ewr JLw8DPc0awtJUa6pNvtXSWHgNfXpeT17rHj8wCUfbDwI2ZJbdmTxKb/zSL9EmlEiw+G5 g1pZDhqGZt858005vYdJwrthshgfzGgpWivxw= Received: by 10.213.108.65 with SMTP id e1mr555692ebp.138.1327595366589; Thu, 26 Jan 2012 08:29:26 -0800 (PST) Received: from [192.168.1.129] (schavemaker.nl. [213.84.84.186]) by mx.google.com with ESMTPS id n56sm17126386eeh.6.2012.01.26.08.29.25 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 08:29:25 -0800 (PST) Message-ID: <4F217F60.9010909@gmail.com> Date: Thu, 26 Jan 2012 17:29:20 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <20120120204459.GA51162@nargothrond.kdm.org> <4F1EC371.4040608@gmail.com> <20120124163538.GA81247@nargothrond.kdm.org> In-Reply-To: <20120124163538.GA81247@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:29:28 -0000 Kenneth D. Merry schreef: > On Tue, Jan 24, 2012 at 15:42:57 +0100, Johan Hendriks wrote: >> Kenneth D. Merry schreef: >>> The LSI-supported version of the mps(4) driver that supports their 6Gb SAS >>> HBAs as well as WarpDrive controllers, is available here: >>> >>> http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt >>> >>> I plan to check it in to head next week, and then MFC it into stable/9 a >>> week after that most likely. >>> >>> Please test it out and let me know if you run into any problems. >>> >>> In addition to supporting WarpDrive, the driver also supports Integrated >>> RAID. >>> >>> Thanks to LSI for doing the work on this driver! >>> >>> I have added a number of other infrastructure changes that are necessary >>> for the driver, and here is a brief summary: >>> >>> - A new Advanced Information buffer is now added to the EDT for drives >>> that support READ CAPACITY (16). The da(4) driver updates this buffer >>> when it grabs new read capacity data from a drive. >>> - The mps(4) driver will look for Advanced Information state change async >>> events, and updates its table of drives with protection information >>> turned on accordingly. >>> - The size of struct scsi_read_capacity_data_long has been bumped up to >>> the amount specified in the latest SBC-3 draft. The hope is to avoid >>> some future structure size bumps with that change. The API for >>> scsi_read_capacity_16() has been changed to add a length argument. >>> Hopefully this will future-proof it somewhat. >>> - __FreeBSD_version bumped for the addition of the Advanced Information >>> buffer with the read capacity information. The mps(4) driver has a >>> kludgy way of getting the information on versions of FreeBSD without >>> this change. >>> >>> I believe that the CAM API changes are mild enough and beneficial enough >>> for a merge into stable/9, but they are intertwined with the unmap changes >>> in the da(4) driver, so those changes will have to go back to stable/9 as >>> well in order to MFC the full set of changes. >>> >>> Otherwise it'll just be the driver that gets merged into stable/9, and >>> it'll use the kludgy method of getting the read capacity data for each >>> drive. >>> >>> A couple of notes about issues with this driver: >>> >>> - Unlike the current mps(4) driver, it probes sequentially. If you have >>> a >>> lot of drives in your system, it will take a while to probe them all. >>> - You may see warning messages like this: >>> >>> _mapping_add_new_device: failed to add the device with handle 0x0019 to >>> persiste >>> nt table because there is no free space available >>> _mapping_add_new_device: failed to add the device with handle 0x001a to >>> persiste >>> nt table because there is no free space available >>> >>> - The driver is not endian safe. (It assumes a little endian machine.) >>> This is not new, the driver in the tree has the same issue. >>> >>> The LSI folks know about these issues. The driver has passed their testing >>> process. >>> >>> Many thanks to LSI for going through the effort to support FreeBSD. >>> >>> Ken >> Sorry to bother you with this, but how do i test this on a 9.0 release >> machine. >> I am no developer what so ever, but we use some LSI 9211-8i cards, in >> supermicro storage machines. >> One machine give me scsi timeouts, and i like to try the new driver. >> >> I did the following: save the >> http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt as lsi.patch >> in /root >> >> then >> # cd /usr >> # patch< lsi.patch >> I do get some .rej from patch >> >> But when i rebuild the kernel it errors out, so i think i am doing >> something wrong. > The overall patch won't apply cleanly to 9.0, because it depends on some > other CAM changes that are not in 9.0. > > The driver itself may apply and work, however. > > The easiest thing to do may be to edit the patch and only keep the patches > against files in sys/dev/lsi, sys/conf, and sys/modules. > > Before you apply the revised patch, make sure you either back out the > previous patch attempt, or otherwise get a clean source tree. > > Ken Ok thanks. I did some homework on patching, and to my own surprice, the altered patch i have now even compiles on 9.0-RELEASE. :D only the param.h failed in the end, and i can not figure out why. So i hope the change in that file is not that important. I am running it now on a Supermicro 3U storage server with a few sata disk in it, with a single LSI 9211-8i card connected the the backplane. It seems to do the job. The driver coming with 9.0 had some trouble when i remirror some drives, i try that tomorrow. i have put the patch here http://xs4all.nl/~doub/mps.patch maybe you can use it, maybe not. my dmesg for what is worth filer01# dmesg Copyright (c) 1992-2012 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 9.0-RELEASE #1: Thu Jan 26 15:37:38 CET 2012 root@filer01.neuteboom.local:/usr/obj/usr/src/sys/KRNL amd64 CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x15bae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16493346816 (15729 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 6.0 on pci0 pci1: on pcib1 mps0: port 0xe000-0xe0ff mem 0xfb600000-0xfb603fff irq 19 at device 0.0 on pci1 mps0: Firmware: 11.00.00.00, Driver: 11.255.03.00-fbsd mps0: IOCCapabilities: 1285c em0: port 0xf020-0xf03f mem 0xfb800000-0xfb81ffff,0xfb824000-0xfb824fff irq 20 at device 25.0 on pci0 em0: No MSI/MSIX using a Legacy IRQ em0: Ethernet address: 00:25:90:57:20:bd ehci0: mem 0xfb823000-0xfb8233ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 em1: port 0xd000-0xd01f mem 0xfb700000-0xfb71ffff,0xfb720000-0xfb723fff irq 16 at device 0.0 on pci3 em1: MSIX: insufficient vectors, using MSI em1: No MSI/MSIX using a Legacy IRQ em1: Ethernet address: 00:25:90:57:20:bc ehci1: mem 0xfb822000-0xfb8223ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 vgapci0: mem 0xf9000000-0xf9ffffff,0xfb000000-0xfb003fff,0xfa800000-0xfaffffff irq 23 at device 3.0 on pci4 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfb821000-0xfb8217ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 da0 at mps0 bus 0 scbus0 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da1 at mps0 bus 0 scbus0 target 9 lun 0 da1: Fixed Direct Access SCSI-6 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da2 at mps0 bus 0 scbus0 target 10 lun 0 da2: Fixed Direct Access SCSI-6 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da3 at mps0 bus 0 scbus0 target 11 lun 0 da3: Fixed Direct Access SCSI-6 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da4 at mps0 bus 0 scbus0 target 12 lun 0 da4: Fixed Direct Access SCSI-6 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da5 at mps0 bus 0 scbus0 target 13 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 150.000MB/s transfers da5: Command Queueing enabled da5: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) ses0 at mps0 bus 0 scbus0 target 16 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 600.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 SES Device cd0 at ahcich2 bus 0 scbus3 target 0 lun 0 SMP: AP CPU #1 Launched! cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 12082197 Hz quality 1000 da7 at mps0 bus 0 scbus0 target 15 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 150.000MB/s transfers da7: Command Queueing enabled da7: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da6 at mps0 bus 0 scbus0 target 14 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 150.000MB/s transfers da6: Command Queueing enabled da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) Root mount waiting for: GMIRROR usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: GMIRROR usbus1 usbus0 ugen0.2: at usbus0 ugen1.2: at usbus1 uhub2: on usbus0 uhub3: on usbus1 uhub3: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered ugen0.3: at usbus0 ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=0 ukbd0: on usbus0 kbd2 at ukbd0 Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device gm0-p2 start due to timeout. GEOM_MIRROR: Device mirror/gm0-p2 launched (1/2). Trying to mount root from ufs:/dev/mirror/gm0-p2 [rw]... Again, i am a complete novice with this sort of things, so forgive me any mistakes i made. regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 18:50:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F21E106566B for ; Thu, 26 Jan 2012 18:50:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 271178FC12 for ; Thu, 26 Jan 2012 18:50:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E1F267300A; Thu, 26 Jan 2012 20:08:17 +0100 (CET) Date: Thu, 26 Jan 2012 20:08:17 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20120126190817.GA73310@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: timeouts too long bug again... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 18:50:56 -0000 In sep.2009 i noticed that usleep() select() and friends (including the in-kernel callouts) would consistently take one tick longer than they should, and committed a fix to sys/kern/kern_timeout.c to HEAD and RELENG_8 http://svnweb.freebsd.org/base?view=revision&revision=197137 http://svnweb.freebsd.org/base?view=revision&revision=200510 Now it seems that the bug is there again, in some form: on 9.0 (and someone reported this also no HEAD) the minimum sleep interval is now 2 ticks. Callouts seem to be correct (at least, dummynet delays are exact, and the sysctl net.inet.ip.dummynet.tick_adjustment: 2770 now does not grow at 500 HZ as it did in the past. Any idea on what might have reintroduced the problem ? (please spare us the story that usleep gives no guarantees etc etc - we all know that, but FreeBSD is consistently 1 tick above the minimum guaranteed interval) cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 20:34:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE8B106564A for ; Thu, 26 Jan 2012 20:34:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id EAA2B8FC13 for ; Thu, 26 Jan 2012 20:34:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp023.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LYF00JSS77NP770@asmtp023.mac.com> for current@freebsd.org; Thu, 26 Jan 2012 19:23:47 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361,1.0.211,0.0.0000 definitions=2012-01-26_07:2012-01-26, 2012-01-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201260213 From: Chuck Swiger In-reply-to: <20120126190817.GA73310@onelab2.iet.unipi.it> Date: Thu, 26 Jan 2012 11:23:46 -0800 Message-id: <9C921CC7-0BCB-4509-9601-379A1BF60738@mac.com> References: <20120126190817.GA73310@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org Subject: Re: timeouts too long bug again... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 20:34:43 -0000 On Jan 26, 2012, at 11:08 AM, Luigi Rizzo wrote: > In sep.2009 i noticed that usleep() select() and friends (including > the in-kernel callouts) would consistently take one tick longer > than they should, and committed a fix to sys/kern/kern_timeout.c > to HEAD and RELENG_8 Sounds like the tvtohz() issue described here: http://www.dragonflybsd.org/presentations/nanosleep/ ...and the prior discussion you had with Peter Wemm: http://www.mavetju.org/mail/view_message.php?list=freebsd-stable&id=3022641 Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 20:43:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7747B1065674 for ; Thu, 26 Jan 2012 20:43:30 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by mx1.freebsd.org (Postfix) with ESMTP id F30E78FC0C for ; Thu, 26 Jan 2012 20:43:29 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTyG68IwdjtfQsK+cgUoBGogEjxH8hodF@postini.com; Thu, 26 Jan 2012 12:43:30 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jan 2012 12:41:25 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q0QKfO177551; Thu, 26 Jan 2012 12:41:25 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F21BA6F.9020401@juniper.net> Date: Thu, 26 Jan 2012 12:41:19 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120126122326.GT2726@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Jan 2012 20:57:24 +0000 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 20:43:30 -0000 On 01/26/2012 04:23 AM, Kostik Belousov wrote: > On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote: >> Thanks for taking a look at it. I'll try to explain the changes the best I >> can: the work was done nearly 6 months ago... >> >>> I would certainly appreciate some more words describing the changes. >>> >>> What is the goal of introducing the PT_FOLLOW_EXEC ? To not force >>> the debugger to filter all syscall exits to see exec events ? >> PT_FOLLOW_EXEC was added to trace the exec() family of calls. When it's >> enabled, the kernel will generate a trap to give debugger a chance to clean >> up old process info and initialize its state with the new binary. >> > It was more a question, why PT_FLAG_EXEC is not enough. I don't see it in the code (sp?) If you mean PL_FLAG_FORKED, than it's used to return lwpinfo, and PT_FOLLOW_EXEC is a ptrace request. > >> >>> Why did you moved the stopevent/ptracestop for exec events from >>> syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC >>> is not removed from syscallret() ? I do not think that TDB_EXEC can be >>> seen there after the patch. The same question about TDB_FORK. >> The reason I moved the event notifications from syscallret() is because the >> debugger is interested successful completion of either fork or exec, not >> just the fact that they have been called. If, say, a call to fork() failed, >> as far as debugger is concerned, fork() might as well had never been >> called. Having a ptracestop in syscallret triggered a trap on every return >> from fork without telling the debugger whether a new process had been >> created or not. Same goes for exec(). > PT_FLAG_EXEC is only set if an exec-kind of syscall succeeded. The same > is true for PT_FLAG_FORKED, the flag is set only if a new child was > successfully created. I found the test cases you sent me for your fork/exec tracing changes and now I see why I needed to make some of the changes. Before my patches tracing of fork/exec is done via PT_TO_SCE/PT_TO_SCX ptrace calls. Their semantics did not fit well into what gdb needs to do. They operate as a variant of PT_CONTINUE. What gdb needs is a process-wide setting that instructs the kernel to generate SIGTRAPs in fork/exec when the process is being controlled via the regular ptrace(PT_CONTINUE)/wait() sequence. > >> Looking at the code now I think I should have removed TDB_EXEC/TDB_FORK >> processing from syscallret(). I'll do that and verify that it works as >> expected. >> >>> If possible, I would greatly prefer to have fork changes separated. >> You mean separate fork changes into a separate patch from exec changes? > Yes. Even more, it seems that fork changes should be separated into > bug fixes and new functionality. OK, that's doable. > >>> I doubt that disallowing RFMEM while tracing is the right change. It may >>> be to fix some (undescribed) bug, but RFMEM is documented behaviour used >>> not only for vfork(2), and the change just breaks rfork(2) for debugged >>> processes. >>> >>> Even vfork() should not be broken, since I believe there are programs >>> that rely on the vfork() model, in particular, C shell. It will be >>> broken if vfork() is substituted by fork(). The fact that it breaks only >>> under debugger will make it esp. confusing. >> I need to dig up the details since I can't recall the exact reason for >> forcing fork() in cases of user calls to vfork() under gdb. I believe it >> had to do with when child process memory was available for writing in case >> of vfork() and it wasn't early enough to complete the switch over from >> parent to child in gdb. After consulting with our internal kernel experts >> we decided that doing fork() instead of vfork() under gdb is a low impact >> change. >> >>> Why do we need to have TDB_FORK set for td2 ? >> The debugger needs to intercept fork() in both parent and child so it can >> detach from the old process and attach to the new one. Maybe it'll make >> more sense in the context of gdb changes. Should I send them too? Don't >> think Marcel included that patch... > No, I think the kernel changes are enough for now. > >>> Does the orphan list change intended to not lost the child after fork ? >>> But the child shall be traced, so debugger would get the SIGTRAP on >>> the attach on fork returning to usermode. I remember that I explicitely >>> tested this when adding followfork changes. >> Yes, the debugger gets SIGTRAPs. The problem arises when the real parent of >> the forked process has the code to collect termination status. Since >> attaching to a process changes the parent/child relationships, we need to >> keep track of the children lost due to re-parenting so we can properly >> attribute their exit status to the "real" parent. >> > I do not quite understand it. From the description it sounds as the problem > that is not related to follow fork changes at all, and shall be presented > regardless of the follow fork. If yes, I think this shall be separated > into a standalone patch. You're right, it's not related. It just happened to prevent me from finishing the work. I'll break up the changes into multiple patches and re-send. From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 21:32:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF6C106566C for ; Thu, 26 Jan 2012 21:32:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF9D8FC12 for ; Thu, 26 Jan 2012 21:32:03 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 26 Jan 2012 13:03:26 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q0QL3Qv8083497 for ; Thu, 26 Jan 2012 13:03:26 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q0QL3QWr083496 for freebsd-current@freebsd.org; Thu, 26 Jan 2012 13:03:26 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201201262103.q0QL3QWr083496@ambrisko.com> To: freebsd-current@freebsd.org Date: Thu, 26 Jan 2012 13:03:26 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Subject: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 21:32:03 -0000 Ran into problems with running kqueue/aio with WITNESS etc. Sometimes things are locked sometimes not. knlist_remove is called telling it whether it is locked or not ie: extern void knlist_remove(struct knlist *knl, struct knote *kn, int islocked); so I changed: extern int knlist_empty(struct knlist *knl); to: extern int knlist_empty(struct knlist *knl, int islocked); and then updated things to reflect that following what that state of the lock for knlist_remove. If it is not locked, it gets a lock and frees it after. This now fixes a panic when a process using kqueue/aio is killed on shutdown with WITNESS. It changes an API/ABI so it probably can't merged back. If there are no objections then I'll commit it. Here is the patch: Index: fs/fifofs/fifo_vnops.c =================================================================== RCS file: /cvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.157 diff -u -p -r1.157 fifo_vnops.c --- fs/fifofs/fifo_vnops.c 16 Aug 2011 20:07:47 -0000 1.157 +++ fs/fifofs/fifo_vnops.c 26 Jan 2012 20:50:31 -0000 @@ -324,7 +324,7 @@ filt_fifordetach(struct knote *kn) SOCKBUF_LOCK(&so->so_rcv); knlist_remove(&so->so_rcv.sb_sel.si_note, kn, 1); - if (knlist_empty(&so->so_rcv.sb_sel.si_note)) + if (knlist_empty(&so->so_rcv.sb_sel.si_note, 1)) so->so_rcv.sb_flags &= ~SB_KNOTE; SOCKBUF_UNLOCK(&so->so_rcv); } @@ -352,7 +352,7 @@ filt_fifowdetach(struct knote *kn) SOCKBUF_LOCK(&so->so_snd); knlist_remove(&so->so_snd.sb_sel.si_note, kn, 1); - if (knlist_empty(&so->so_snd.sb_sel.si_note)) + if (knlist_empty(&so->so_snd.sb_sel.si_note, 1)) so->so_snd.sb_flags &= ~SB_KNOTE; SOCKBUF_UNLOCK(&so->so_snd); } Index: kern/kern_event.c =================================================================== RCS file: /cvs/src/sys/kern/kern_event.c,v retrieving revision 1.146 diff -u -p -r1.146 kern_event.c --- kern/kern_event.c 16 Sep 2011 13:58:51 -0000 1.146 +++ kern/kern_event.c 26 Jan 2012 20:50:31 -0000 @@ -1650,7 +1650,7 @@ kqueue_close(struct file *fp, struct thr KASSERT(kq->kq_refcnt == 1, ("other refs are out there!")); fdp = kq->kq_fdp; - KASSERT(knlist_empty(&kq->kq_sel.si_note), + KASSERT(knlist_empty(&kq->kq_sel.si_note, 1), ("kqueue's knlist not empty")); for (i = 0; i < kq->kq_knlistsize; i++) { @@ -1735,7 +1735,7 @@ kqueue_wakeup(struct kqueue *kq) if (!SEL_WAITING(&kq->kq_sel)) kq->kq_state &= ~KQ_SEL; } - if (!knlist_empty(&kq->kq_sel.si_note)) + if (!knlist_empty(&kq->kq_sel.si_note, 1)) kqueue_schedtask(kq); if ((kq->kq_state & KQ_ASYNC) == KQ_ASYNC) { pgsigio(&kq->kq_sigio, SIGIO, 0); @@ -1867,10 +1867,18 @@ knlist_remove_inevent(struct knlist *knl } int -knlist_empty(struct knlist *knl) +knlist_empty(struct knlist *knl, int knlislocked) { - KNL_ASSERT_LOCKED(knl); - return SLIST_EMPTY(&knl->kl_list); + int error; + + KNL_ASSERT_LOCK(knl, knlislocked); + if (!knlislocked) + knl->kl_lock(knl->kl_lockarg); + error = SLIST_EMPTY(&knl->kl_list); + if (!knlislocked) + knl->kl_unlock(knl->kl_lockarg); + + return error; } static struct mtx knlist_lock; @@ -1931,7 +1939,9 @@ knlist_init(struct knlist *knl, void *lo else knl->kl_assert_unlocked = kl_assert_unlocked; + knl->kl_lock(knl->kl_lockarg); SLIST_INIT(&knl->kl_list); + knl->kl_unlock(knl->kl_lockarg); } void Index: kern/uipc_socket.c =================================================================== RCS file: /cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.358 diff -u -p -r1.358 uipc_socket.c --- kern/uipc_socket.c 25 Aug 2011 15:51:54 -0000 1.358 +++ kern/uipc_socket.c 26 Jan 2012 20:50:31 -0000 @@ -3188,7 +3188,7 @@ filt_sordetach(struct knote *kn) SOCKBUF_LOCK(&so->so_rcv); knlist_remove(&so->so_rcv.sb_sel.si_note, kn, 1); - if (knlist_empty(&so->so_rcv.sb_sel.si_note)) + if (knlist_empty(&so->so_rcv.sb_sel.si_note, 1)) so->so_rcv.sb_flags &= ~SB_KNOTE; SOCKBUF_UNLOCK(&so->so_rcv); } @@ -3222,7 +3222,7 @@ filt_sowdetach(struct knote *kn) SOCKBUF_LOCK(&so->so_snd); knlist_remove(&so->so_snd.sb_sel.si_note, kn, 1); - if (knlist_empty(&so->so_snd.sb_sel.si_note)) + if (knlist_empty(&so->so_snd.sb_sel.si_note, 1)) so->so_snd.sb_flags &= ~SB_KNOTE; SOCKBUF_UNLOCK(&so->so_snd); } Index: kern/vfs_aio.c =================================================================== RCS file: /cvs/src/sys/kern/vfs_aio.c,v retrieving revision 1.249 diff -u -p -r1.249 vfs_aio.c --- kern/vfs_aio.c 16 Sep 2011 13:58:51 -0000 1.249 +++ kern/vfs_aio.c 26 Jan 2012 20:50:31 -0000 @@ -2531,7 +2533,7 @@ filt_aiodetach(struct knote *kn) { struct aiocblist *aiocbe = kn->kn_ptr.p_aio; - if (!knlist_empty(&aiocbe->klist)) + if (!knlist_empty(&aiocbe->klist, 0)) knlist_remove(&aiocbe->klist, kn, 0); } @@ -2576,7 +2578,7 @@ filt_liodetach(struct knote *kn) { struct aioliojob * lj = kn->kn_ptr.p_lio; - if (!knlist_empty(&lj->klist)) + if (!knlist_empty(&lj->klist, 0)) knlist_remove(&lj->klist, kn, 0); } Index: sys/event.h =================================================================== RCS file: /cvs/src/sys/sys/event.h,v retrieving revision 1.49 diff -u -p -r1.49 event.h --- sys/event.h 31 Dec 2009 20:29:58 -0000 1.49 +++ sys/event.h 26 Jan 2012 20:50:37 -0000 @@ -244,7 +244,7 @@ extern void knote_fork(struct knlist *li extern void knlist_add(struct knlist *knl, struct knote *kn, int islocked); extern void knlist_remove(struct knlist *knl, struct knote *kn, int islocked); extern void knlist_remove_inevent(struct knlist *knl, struct knote *kn); -extern int knlist_empty(struct knlist *knl); +extern int knlist_empty(struct knlist *knl, int islocked); extern void knlist_init(struct knlist *knl, void *lock, void (*kl_lock)(void *), void (*kl_unlock)(void *), void (*kl_assert_locked)(void *), void (*kl_assert_unlocked)(void *)); Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 09:38:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5060A1065672 for ; Fri, 27 Jan 2012 09:38:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B63528FC13 for ; Fri, 27 Jan 2012 09:38:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0R9anSL095315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 11:36:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0R8uvFt041229; Fri, 27 Jan 2012 10:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0R8uurH041228; Fri, 27 Jan 2012 10:56:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Jan 2012 10:56:56 +0200 From: Kostik Belousov To: Doug Ambrisko Message-ID: <20120127085656.GY2726@deviant.kiev.zoral.com.ua> References: <201201262103.q0QL3QWr083496@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ed2sj0fx90rgoibw" Content-Disposition: inline In-Reply-To: <201201262103.q0QL3QWr083496@ambrisko.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 09:38:52 -0000 --ed2sj0fx90rgoibw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2012 at 01:03:26PM -0800, Doug Ambrisko wrote: > Ran into problems with running kqueue/aio with WITNESS etc. Sometimes > things are locked sometimes not. knlist_remove is called telling it > whether it is locked or not ie: > extern void knlist_remove(struct knlist *knl, struct knote *kn, int = islocked); > so I changed: > extern int knlist_empty(struct knlist *knl); > to: > extern int knlist_empty(struct knlist *knl, int islocked); >=20 > and then updated things to reflect that following what that state of the > lock for knlist_remove. If it is not locked, it gets a lock and=20 > frees it after. >=20 > This now fixes a panic when a process using kqueue/aio is killed on > shutdown with WITNESS. >=20 > It changes an API/ABI so it probably can't merged back. If there are > no objections then I'll commit it. >=20 Change to knlist_init() does not make sense at all, the knlist shall not be exposed to other consumers during initialization, so no need to exclude the parallel access. Regarding the knlist_empty(), I propose to keep it as is. Locking the knlist inside knlist_empty() does not make sense, because lock is immediately dropped afterward, and relocked for remove. This way, the entry could be removed from the list meantime (can it, really ?). I think that you should take a lock around the whole if() {} statement, and call knlist_remove with locked =3D=3D 1. --ed2sj0fx90rgoibw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8iZtgACgkQC3+MBN1Mb4i2CgCfWHZPTo8+ZH45enS5lsoeFrMw 1GAAn1J1OhCzi0Q7vNZwgEA9YCTz29TE =tzJl -----END PGP SIGNATURE----- --ed2sj0fx90rgoibw-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 10:06:48 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09ABF106566B; Fri, 27 Jan 2012 10:06:48 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E98E68FC19; Fri, 27 Jan 2012 10:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0RA6le0037726; Fri, 27 Jan 2012 10:06:47 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0RA6ljK037725; Fri, 27 Jan 2012 10:06:47 GMT (envelope-from danger) Date: Fri, 27 Jan 2012 10:06:47 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20120127100647.GA37668@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Quarterly Status Report October-December, 2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:06:48 -0000 FreeBSD Quarterly Status Report October-December, 2011 Introduction This report covers FreeBSD-related projects between October and December 2011. It is the last of the four reports planned for 2011. This quarter was mainly devoted to polishing the bits for the next major version of FreeBSD, 9.0, which was already successfully released in the beginning of January 2012. Thanks to all the reporters for the excellent work! This report contains 32 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between January and March 2012 is April 15th, 2012. __________________________________________________________________ Projects * Auditdistd Project * BSD-Licensed C++ Stack * pfSense User-land Programs * Replacing the Regular Expression Code * System Configuration Utilities FreeBSD Team Reports * FreeBSD Ports Management Team Status Report * Release Engineering Team Status Report * The FreeBSD Foundation Status Report Kernel * CAM Target Layer (CTL) * FreeBSD No-IPv4 ("IPv6-Only") Support * GEOM MULTIPATH Rewrite * HDA Sound Driver (snd_hda) Improvements * LSI Supported mps(4) SAS driver * SCSI Direct Access Driver (da) Improvements * Status Report for NFS * The New CARP Documentation * A Tool to Check for Mistakes in Documentation -- igor * The FreeBSD German Documentation Project * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/390 * FreeBSD/arm on Marvell Armada XP * FreeBSD/powerpc on AppliedMicro APM86290 * FreeBSD/powerpc on Freescale QorIQ DPAA * Improving Support for New Features in the Intel SandyBridge CPUs Ports * FreeBSD Haskell Ports * FreeBSD Ruby Ports * FreeBSD/GNOME * FreeBSD/KDE * Multimedia -- Watching/Recording Digital TV * Perl Ports Testing * Public FreeBSD Ports Development Infrastructure -- redports.org * Up to Date X.Org Server __________________________________________________________________ A Tool to Check for Mistakes in Documentation -- igor URL: http://www.wonkity.com/~wblock/igor/ Contact: Warren Block igor is a program that proofreads man pages, DocBook SGML source, and other text files for many common mistakes. Files are tested for spelling mistakes, repeated words, and white-space problems. Man pages are also checked for minimal structure, and DocBook SGML source files are checked for formatting and tag problems. If you write or edit FreeBSD documentation, let igor help you check it for correctness. Open tasks: 1. Find a testing or parsing framework that can do a faster or better job, or that can understand the state of DocBook tags. 2. Add more tests. 3. Improve speed. __________________________________________________________________ Auditdistd Project Contact: Pawel Jakub Dawidek Current weakness of FreeBSD's Security Event Audit facility is that audit records are stored locally and can be modified or removed by an attacker after a system compromise. The auditdistd will allow to reliably and securely distribute audit trail files over TCP/IP network to remote system. In case of system compromise it will enable administrators to analyze audit records in trusted environment. This project is sponsored by the FreeBSD Foundation and should be completed by the end of February 2012. __________________________________________________________________ BSD-Licensed C++ Stack Contact: David Chisnall Two new libraries, libc++ (providing a C++11 STL implementation) and libcxxrt (providing an implementation of the C++ ABI specification) have been added. This is enabled by adding WITH_LIBCPLUSPLUS=yes to src.conf. It is not enabled by default because libc++ does not build with the version of gcc in the base system and requires you to build with clang. Once it is built, you can select between using GNU libstdc++ and libc++ by adding -stdlib=libc++ or -stdlib=libstdc++ to your compile and link flags (when building with clang). If you are running head (or have a spare [virtual] machine you can try it on) then please try building your C++ code with libc++ and let me know of any failures, ideally with reduced test cases. Open tasks: 1. Test ports with libc++. Hopefully most will Just Work., but others may need patches or have a hard dependency on libstdc++. 2. Make libstdc++ dynamically link to libsupc++. This will allow us to use libmap.conf to switch between libsupc++ and libcxxrt. 3. Enable building libc++ by default (hopefully in the 9.1 time-frame, when clang becomes the default system compiler) and switch to using libcxxrt instead of libsupc++ by default. 4. Lots more testing. Followed by even more testing. 5. Removing libstdc++ from the base system and making it available through ports for backwards compatibility. __________________________________________________________________ CAM Target Layer (CTL) URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2012-January/031007. html Contact: Ken Merry The CAM Target Layer (CTL) is now in FreeBSD/head. CTL is a disk and processor device emulation subsystem originally written for Copan Systems under Linux starting in 2003. It has been shipping in Copan (now SGI) products since 2005. It was ported to FreeBSD in 2008, and thanks to an agreement between SGI (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is available under a BSD-style license. The intent behind the agreement was that Spectra would work to get CTL into the FreeBSD tree. It will likely be merged into the stable/9 tree in mid-February. Some CTL features: * Disk and processor device emulation * Tagged queueing * SCSI task attribute support (ordered, head of queue, simple tags) * SCSI implicit command ordering support. (e.g. if a read follows a mode select, the read will be blocked until the mode select completes.) * Full task management support (abort, LUN reset, target reset, etc.) * Support for multiple ports * Support for multiple simultaneous initiators * Support for multiple simultaneous backing stores * Persistent reservation support * Mode sense/select support * Error injection support * High Availability support (1) * All I/O handled in-kernel, no userland context switch overhead. (1) HA Support is just an API stub, and needs much more to be fully functional. For the basics on configuring and running CTL, see src/sys/cam/ctl/README.ctl.txt in the FreeBSD/head source tree. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.FreeBSD.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ URL: http://haskell.org/mailman/listinfo/freebsd-haskell/ Contact: Gábor János PÁLI Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2011.4.0.0, as well as updated GHC to 7.0.4 in FreeBSD Haskell ports repository. We also added a number of new Haskell ports, and their count is now more than 300. Some of the new ports include Yesod, Happstack (popular web development frameworks in Haskell), ThreadScope (a graphical profiler tool for parallel Haskell programs). Due to ports repository freeze for 9.0-RELEASE, these updates are not in official ports tree yet. They will be committed to the ports repository after it is unfrozen again, in the meantime they can be accessed through FreeBSD Haskell ports repository. Open tasks: 1. Commit pending Haskell ports to FreeBSD ports repository. 2. Test GHC to work with clang/LLVM. 3. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC bootstrap tarball. __________________________________________________________________ FreeBSD No-IPv4 ("IPv6-Only") Support URL: http://www.FreeBSD.org/ipv6/ipv6only.html Contact: Bjoern A. Zeeb The No-IPv4 (fka. "IPv6-Only") project initially prototyped in p4 and merged into mainstream FreeBSD with support from the FreeBSD Foundation and iXsystems earlier in 2011 for World IPv6 Day continued as a free time project. Thanks to the help of an anonymous source, dedicated i386 and amd64 build machines and a distribution node were setup to allow continuous building of snapshots and we hope to extend the support for the snapshots in the future providing more services. During the 9.0 release cycle a BETA and an RC snapshot were built and released. FreeBSD 9.0-RELEASE will be the first official release supporting a kernel to compile out IPv4 support. We will provide (and given 9.0 is out at time of writing do provide) a no-IPv4 snapshot accompanying the official release and hope for your feedback. I would like to thank Hiroki Sato/allbsd.org for providing a mirror in Japan for the Asian community in addition to mine in Europe. Open tasks: 1. Commit/Submit upstream a few user space fixes. 2. More user space cleanup and testing. 3. Get rid of gethostby*() calls. __________________________________________________________________ FreeBSD Ports Management Team Status Report URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 Contact: Thomas Abthorpe Contact: Port Management Team The ports tree finally surpassed 23,000 ports. The PR count still remains at about 1100. In Q4 we added 4 new committers, took in 4 commit bit for safe keeping, and had one committer return to ports work. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * KDE4 and cmake updates * Multiple runs to test and fix breakages induced by the bump in digits for FreeBSD 10 * Verify the removal of X11BASE from ports * Test ports after import of flex and m4 into src base * Optimizations to bsd.ports.mk * Test xcb update and split into multiple ports * Estimate number of ports utilizing old interface ioctls * Ongoing validation of infrastructure with pkgng * testing ports with clang as default compiler pkgng now has real safe binary upgrade, as well as real integrity checking, work has been started to have the ports tree be able to bootstrap pkgng. More info on the CFT email.. The pointyhat-west build machine continues toward production use, code updates have made it more versatile such as swapping out information in make.conf for build slaves, assist in testing of pkgng -exp runs and to properly build linux_base ports. It has been decided that the ports tree will be migrated from CVS to Subversion, beat@ will be in charge of the project. More information on the wiki. A moderated mailing list has been created for ports related announcements, http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports-announce, it is intended, but not limited, to be a means of communicating portmgr@ announcements, Calls for Testing, plus other relevant information to be used by our committers and ports maintainer community. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help fixing ports broken on CURRENT. (List needs updating, too) 3. Looking for help with Tier-2 architectures. 4. ports broken by src changes. 5. ports failing on pointyhat. 6. ports failing on pointyhat-west. 7. ports that are marked as BROKEN. 8. When did that port break. 9. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ FreeBSD Ruby Ports URL: http://wiki.FreeBSD.org/Ruby URL: http://people.FreeBSD.org/~pgollucci/FreeBSD/prs/prefixes.html#ruby- URL: http://people.FreeBSD.org/~pgollucci/FreeBSD/prs/prefixes.html#rubygem- Contact: Philip Gollucci Contact: Steve Wills Work is underway to convert the remaining ruby- ports to rubygem-* ports in order to keep up with the gem community. A second attempt will be made to change the default ruby from 1.8 to 1.9. There will be some unavoidable casualties of this transition. The sysutils/rubygem-chef-server port was contributed by RideCharge Inc / Taxi Magic who is now using it exclusively. Open tasks: 1. Need some fresh -exp runs to check the new status especially with ruby 1.9.3-p0. __________________________________________________________________ FreeBSD/390 Contact: Pau Amma Contact: Bjoern A. Zeeb I wandered in and started working on FreeBSD/390 about 1 month ago based on source Bjoern provided. My short term goals are to sync it with the current HEAD and write a minimal IPLabel loader, so we do not have to depend on Hercules-only commands to test the kernel boot process. Then it will be time to make the crossbuild work again and get the kernel booting. __________________________________________________________________ FreeBSD/arm on Marvell Armada XP URL: http://svnweb.FreeBSD.org/base/projects/armv6/ Contact: Grzegorz Bernacki Contact: Rafal Jaworowski Marvell Armada XP is a complete system-on-chip solution based on Sheeva embedded CPU. These devices integrate up to four ARMv6/v7 compliant Sheeva CPU cores with shared L2 cache. This work is extending the FreeBSD/arm infrastructure towards support for recent ARM architecture variations along with a basic set of device drivers for integrated peripherals. The following code has been implemented since the last status report: * SMP support * + Implemented TLB broadcast and RFO + Tested 2 and 4 cores setup in WT cache mode * SATA driver integrated and tested * CESA driver integrated and tested Next steps: * L2 cache support * Full support for WB/WBA cache __________________________________________________________________ FreeBSD/GNOME URL: http://www.FreeBSD.org/gnome URL: http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ Contact: GNOME FreeBSD mailing list It has been a while since we did a status report. This year we started work on GNOME 3.0. Due to time constrains and lack of man power, this version did not make it into the ports. Currently we have 3.2 in our development repo. See the development FAQ on our website for details. The MC-UPDATING file contains upgrade instructions. Currently the GNOME team is understaffed, help is welcome! Open tasks: 1. Update the FreeBSD gnome website with GNOME 3.x information, and still supply the 2.32.x info. __________________________________________________________________ FreeBSD/KDE URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: FreeBSD KDE The KDE/FreeBSD team have continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Many fixes upstream to make KDE and Qt build with Clang * Making automoc not freeze with parallel builds The team has also made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.7.3, 4.7.4 (in the area51 experimental repository) * Qt: 4.8.0 (in the area51 experimental repository) * CMake: 2.8.6, 2.8.7 The team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. Open tasks: 1. Testing KDE SC 4.8.0. 2. Testing KDE PIM 4.7.4. 3. Testing phonon-gstreamer and phonon-vlc as the phonon-xine backend was deprecated (but will remain in the ports for now). 4. Testing the Calligra beta releases (in the area51 repository). __________________________________________________________________ FreeBSD/powerpc on AppliedMicro APM86290 Contact: Grzegorz Bernacki Contact: Rafal Jaworowski The APM86290 system-on-chip device is a member of AppliedMicro's PACKETpro family of embedded processors. The chip includes two Power Architecture PPC465 processor cores, which are compliant with Book-E specification of the architecture, and a number of integrated peripherals. This work is extending current Book-E support in FreeBSD towards PPC4xx processors variation along with device drivers for integrated peripherals. The following drivers have been created since the last report: * Ethernet controller driver * Classifier driver * Finished Queue Manager/Traffic Manager * Improved performance and stability Next steps: * L2 cache support * Merge APM86290 support to -CURRENT __________________________________________________________________ FreeBSD/powerpc on Freescale QorIQ DPAA URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2040 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P3041 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5020 Contact: Michal Dubiel Contact: Rafal Jaworowski Contact: Piotr Ziecik The QorIQ Data Path Acceleration Architecture (DPAA) from Freescale is a comprehensive architecture, which integrates all aspects of packet processing in the SoC, addressing issues and requirements resulting from the nature of QorIQ multicore SoCs. It includes: * Cores * Network and packet I/O * Hardware offload accelerators * The infrastructure required to facilitate the flow of packets between the above The DPAA also addresses various performance related requirements, especially those created by the high speed network I/O found on multicore SoCs such as P2041, P3041, P5020, etc. This work is bringing up FreeBSD on these system-on-chip devices along with device drivers for integrated peripherals. Current FreeBSD QorIQ DPAA support includes: * QorIQ P2041 and P3041 devices * E500mc core complex * Adaptation of toolchain for the new core * Booting via U-Boot bootloader * CoreNet interconnect fabric * L1, L2, L3 cache * Serial console (UART) * Interrupt controller * DPAA infrastructure (BMAN, FMAN, QMAN) * Ethernet (basic network functionality using Independent Mode of DPAA infrastructure) * EHCI controller * PCI Express controller (host mode) * SMP support (up to quad-core) * I2C Next steps: * QorIQ P5020 (32-bit mode) support * Ethernet (full network functionality using Regular Mode of DPAA infrastructure) * Enhanced SDHC __________________________________________________________________ GEOM MULTIPATH Rewrite URL: http://people.FreeBSD.org/~mav/gmultipath5.patch Contact: Alexander Motin The GEOM MULTIPATH class underwent a major rewrite to fix many problems and improve functionality, including: * Improved locking and destruction process to fix crashes. * "Automatic" configuration method improved to make it safe by reading metadata back from all specified paths after writing to one. * "Manual" configuration method added to work without using on-disk metadata. New "add" and "remove" commands allow to manage paths manually. * Failed paths are no longer dropped from GEOM, but only marked as failed and excluded from I/O operations. Failed paths can be automatically restored when all other paths are lost or marked as failed, for example, because of device-caused (not transport) errors. "Fail" and "restore" commands added to manually control failure status. * Added Active/Active mode support. Unlike the default Active/Passive mode, the load is evenly distributed between all working paths. If supported by the device, it allows to significantly improve performance, utilizing bandwidth of all paths. It is controlled by the -A option during creation. * Provider size check added to reduce chance of conflict with other GEOM classes. * GEOM is now destroyed on last provider disconnection. * `status` and `list` commands output was improved. These changes are now committed into the FreeBSD HEAD branch. Merge to 9-STABLE and 8-STABLE is planned after 9.0 release. Project sponsored by iXsystems, Inc. Open tasks: 1. Implement some additional request ordering mechanism for the Active/Active mode. Some consumers in theory may not wait for previous requests completion before submitting new overlapping or dependent requests. Those requests may be reordered on device if run via different paths simultaneously. __________________________________________________________________ HDA Sound Driver (snd_hda) Improvements URL: http://people.FreeBSD.org/~mav/hda.rewrite2.patch Contact: Alexander Motin snd_hda(4) driver took major rewrite: * Big old hdac driver was split into three independent pieces: HDA controller driver (hdac), HDA CODEC driver (hdacc) and HDA audio function driver (hdaa). All drivers are completely independent and talk to each other only via NewBus interfaces. Using more NewBus bells and whistles allows to properly see HDA structure with standard system instruments, such as `devinfo -v`. Biggest driver file size now is 150K, instead of 240K before, and the code is much cleaner. * Support for multichannel recording was added. While I have never seen it configured by default, UAA specification tells that it is possible. Now, as specification defines, driver checks input associations for pins with sequence numbers 14 and 15, and if found (usually) -- works as before, mixing signals together. If it does not, it configures input association as multichannel. I have found some CODECs doing strange things when configured for multichannel recording, but I have also found successfully working examples. * Signal tracer was improved to look for cases where several DACs/ADCs in CODEC can work with the same audio signal. If such a case is found, the driver registers additional playback/record stream (channel) for the pcm device. Having more than one stream allows to avoid vchans use and so avoid extra conversion to vchan's pre-configured sample rate and format. Not many CODECs allow this, especially on playback, but some do. * New controller streams reservation mechanism was implemented. That allows to have more pcm devices than streams supported by the controller (usually 4 in each direction). Now it limits only number of simultaneously transferred audio streams, that is rarely reachable and properly reported if happens. * Codec pins and GPIO signals configuration was exported via set of writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger driver reconfiguration in run-time. The only requirement is that all pcm devices should be closed at the moment, as they will be destroyed and recreated. This should significantly simplify process of fixing CODEC configuration. It should be possible now even to write GUI to do it with few mouse clicks. * Driver now decodes pins location and connector type names. In some cases it gives a hint to the user where the connectors of the pcm device are located on the system case. The number of channels supported by pcm device, reported now (if it is not 2), should also make finding them easier. The code is in testing now and should be soon committed to the HEAD branch. Project sponsored by iXsystems, Inc. Open tasks: 1. Closer inspection of HDMI/DisplayPort audio is planned. 2. A number of hardware, mostly laptops, need workarounds to work properly. Some statistics should be collected to implement some of them avoiding excessive code bloat. __________________________________________________________________ Improving Support for New Features in the Intel SandyBridge CPUs Contact: Konstantin Belousov Support for new features in the Intel SandyBridge CPUs is progressing. The patch to query and allow extended FPU states was committed, which enabled the YMM registers and AVX instruction set on the capable processors. Todo items include get wider testing of the change before planned merge to stable/9 in a month, and start using XSAVEOPT instruction to optimize context switch times. Patch to enable and use per-process TLB was developed. Latest version is available at http://people.freebsd.org/~kib/misc/pcid.2.patch. The facility, referred in the documentation as PCID, allows to avoid TLB flush on context switches by applying PID tag to each non-global TLB entry. On SandyBridge, measurements did not prove any difference between context switch latencies on patched and stock kernels. Forthcoming IvyBridge CPUs promised to provide optimizations in the form of INVPCID instructions that allow to optimize TLB shootdown handlers. The patch above uses the instruction on the capable CPU. Todo items are to get access to IvyBridge and do the benchmarks. Future work might provide SEP support, use hardware random generator from IvyBridge for random(4), considering using faster instructions to access %fs and %gs bases, and use improved AES-NI instruction set for aesni(4). __________________________________________________________________ LSI Supported mps(4) SAS driver URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2012-January/031358. html Contact: Ken Merry Contact: Kashyap Desai The LSI-supported version of the mps(4) driver, that supports their 6Gb SAS controllers and WarpDrive solid state drives, is available in FreeBSD/head. In addition to WarpDrive support, the driver also has several other new features: * Integrated RAID (IR) support * Improved error recovery code * Support for SCSI protection information (EEDP) * Support for TLR (Transport Level Retries), needed for tape drives * ioctl interface compatible with LSI utilities Thanks to LSI for doing the work on this driver, and the testing. I plan to merge it into stable/9 and stable/8 in early February. __________________________________________________________________ Multimedia -- Watching/Recording Digital TV URL: http://wiki.FreeBSD.org/WebcamCompat URL: http://wiki.FreeBSD.org/HTPC URL: http://wiki.FreeBSD.org/VDR Contact: Hans Petter Selasky Contact: Jason Harmening Contact: Juergen Lock Progress has been made when watching/recording live digital TV using FreeBSD: * multimedia/webcamd is continuously adding support for more and more USB tuners using the Linux V4L/DVB drivers (also including remotes via webcamd and comms/lirc.) * multimedia/cx88 recently added Linux DVB API support for CX88-based PCI(-e) DVB-T tuners so "common" apps can now also be used with that hardware. * multimedia/xbmc-pvr was committed recently and the multimedia/vdr ports are working too for watching/recording live digital TV, and also other apps like kaffeine, or mplayer, or vlc. Open tasks: 1. Continue updating the VDR ports to the latest versions and fix remaining bugs. 2. Update multimedia/libxine to 1.2.0 that recently was released (which VDR uses.) 3. Test more hardware? __________________________________________________________________ Perl Ports Testing Contact: Steve Wills Contact: Sunpoet Po-Chuan Hsieh Many Perl modules in ports come with test cases included with their source. This project's goal is to ensure that all these tests pass. Patches have been added to the ports tinderbox to allow test related dependencies to be installed and many ports have TEST_DEPENDS now. A patch is available to enable testing for those who wish to help out. All p5- ports have been built and tests attempted. Approximately 61% of the Perl ports pass currently. Many ports have been updated to include missing dependencies or make other changes which allow tests to pass. Long term goals include a more generic framework for testing ports and automated tests executed when ports are updated. Open tasks: 1. Many Perl ports which do not pass tests remain. 2. Need to figure out how to move testing out of tinderbox. 3. A patch to build Perl with -pthread (but not enable useithreads in Perl) is pending. It will fix many currently broken tests __________________________________________________________________ pfSense URL: http://www.pfsense.org/ Contact: Scott Ullrich Contact: Chris Buechler Contact: Ermal Luçi pfSense is a free and open source customized distribution of FreeBSD tailored for use as a firewall and router. 2.0.1 was just released which corrected a number of issues http://blog.pfsense.org/?p=633. Open tasks: 1. 6 month release cycle. 2. Moving builds to FreeBSD 9. 3. Full IPV6 support. 4. PBI Package binaries. 5. Unbound integration. 6. Multi-instance Captive Portal. 7. Replacing Prototype with jQuery. __________________________________________________________________ Public FreeBSD Ports Development Infrastructure -- redports.org URL: http://redports.org/ URL: irc://irc.freenode.net#redports URL: https://groups.google.com/group/redports URL: http://redports.org/wiki/UserGuide Contact: Bernhard Froehlich Redports is a free service for FreeBSD port maintainers and port committers to automatically buildtest ports on various FreeBSD versions and architectures. The motivation to do that was because there are many people that do not have access to Ports Tinderboxes and the existing Tinderboxes are usually dedicated to a single team. The platform was designed with scalability in mind but building capacity is currently very limited until more hardware is available. I am already in contact with the usual suspects to improve that. Open tasks: 1. Get more Hardware for building. 2. Port options support. 3. ports-mgmt/portlint support. __________________________________________________________________ Release Engineering Team Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team was pleased to announce the release of FreeBSD-9.0 on January 12th, 2012. To acknowledge his incredible contributions to the world of computing and in particular the FreeBSD Project's corner of that world FreeBSD-9.0 was dedicated to Dennis Ritchie. May he rest in peace. The Release Engineering Team also wishes to thank the FreeBSD Developers and Community for all the work they put into the release. With the FreeBSD-9.0 release cycle completed our focus shifts to preparing for the FreeBSD-8.3 release. A schedule has not been set but we expect to be shooting for release some time in March 2012. __________________________________________________________________ Replacing the Regular Expression Code URL: http://svnweb.FreeBSD.org/base/user/gabor/tre-integration/ URL: http://laurikari.net/tre/ URL: http://www.tdk.aut.bme.hu/Files/TDK2011/POSIX-regularis-kifejezesek1.pd f Contact: Gábor Kövesdán The current regular expression code in libc has to be replaced because it is old, unmaintained and does not support wide characters. As it has been elaborated, TRE is the most suitable replacement outside that has an acceptable license. However, the development of BSD grep also brought some relevant observations. In short, there are some possibilities to optimize pattern matching but it is not possible with the POSIX API, because: * It uses NUL-terminated strings that requires processing each character and makes longer jumps impossible. * It matches for one pattern at a time. If more patterns are searched, there are more efficient ways for pattern matching but we have to know all of them and process them together. This project intends to implement these shortcut and provide efficient pattern matching for all programs that use regex matching. It will also help avoiding the custom tricks that are hardcoded into some programs, like GNU grep, to work around the limiting POSIX API. Besides, GNU grep has some extensions over the POSIX regular expression, which are necessary if we want to get rid of GNU code in the end. Open tasks: 1. Implement multi-pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Adapt BSD grep to use the multi-pattern interface. 4. Test standard-compliance and correct behavior. __________________________________________________________________ SCSI Direct Access Driver (da) Improvements Contact: Alexander Motin BIO_DELETE support (aka TRIM) was added to the CAM SCSI Direct Access device driver (da). Depending on device capabilities different methods are used to implement it. Currently used method can be read/set via kern.cam.da.X.delete_method sysctls. Possible values are: * NONE - no provisioning support reported by the device; * DISABLE - provisioning support was disabled because of errors; * ZERO - use WRITE SAME (10) command to write zeroes; * WS10 - use WRITE SAME (10) command with UNMAP bit set; * WS16 - use WRITE SAME (16) command with UNMAP bit set; * UNMAP - use UNMAP command (equivalent of the ATA DSM TRIM command). The last two methods (UNMAP and WS16) are defined by SBC specification and the UNMAP method is the most advanced one. The rest of the methods I have found supported in Linux, and as they were trivial to implement, then why not? I hope they will be useful in some cases. As side product of fetching logical block provisioning support flag, da driver also got support for reporting device physical sector size (aka Advanced Format) via stripesize/stripeoffset GEOM fields. Some quirks were added for known 4K sector disks not reporting it properly. The code was committed to the HEAD branch and is going to be merged to 8/9-STABLE after some time. Project sponsored by iXsystems, Inc. Open tasks: 1. To implement more effective selection of the best delete method some more parameters need to be obtained from the device. Unluckily none of devices I have report them. __________________________________________________________________ Status Report for NFS Contact: Rick Macklem The new NFS client and server are no longer considered experimental and are the default for FreeBSD 9.0. Included is fairly complete support for NFSv4.0, as well as NFSv3 and NFSv2. NFSv4.0 delegations are not enabled by default for the server, since there is no handling of them for local system calls done on the server, as yet. So far, the transition seems to have gone alright, with only a couple of obscure issues identified that did not get fixed for FreeBSD 9.0. Patches for these can be found at http://people.FreeBSD.org/~rmacklem Work is ongoing with respect to NFSv4.1 client support. The current code includes functioning support for the required components, in particular, sessions for both fore and back channels. Development for the big optional component pNFS is in progress and will hopefully be functional for the Files layout in a few months. The modified sources can be found at http://svn.FreeBSD.org/viewvc/base/projects/nfsv4.1-client. There is also a patch for what I call packrats, where threads perform aggressive on-disk caching of delegated file in the NFSv4.0 client. It currently seems to function OK, but does not yet have client reboot recovery implemented, so it can only be used experimentally at this time. This patch can be found at http://people.FreeBSD.org/~rmacklem/packrat-patches. __________________________________________________________________ System Configuration Utilities URL: http://druidbsd.sourceforge.net/ Contact: Devin Teske On December 31st, 2011 sysutils/sysrc was added to the ports-tree. On January 6th, 2012 sysutils/host-setup was added to the ports-tree. Still pending is the addition of sysutils/tzdialog. Together or separately, these utilities try to make configuring the system easier and more efficient. sysrc(8) allows you to safely modify rc.conf(5) without fear or trepidation; making remote-management and scripted changes a simple transaction. Also useful in managing puppet installations. host-setup(8) allows you to configure your time zone, hostname, network interfaces, default router/gateway, DNS nameservers in resolv.conf(5) all via dialog(1) (or Xdialog(1)) interface. Designed to replace sysinstall(8), host-setup is written entirely in sh(1) and is completely stand-alone. tzdialog(8) is an ISO-3166 compatible sh(1) rewrite of tzsetup(8). It is designed to be a drop-in replacement for tzsetup. The major difference between the two is tzdialog(8) adds supports for graphical user interface via Xdialog(1) (by passing the `-X' argument), whereas tzsetup(8) only supports console-based interaction. Open tasks: 1. Write a man-page for tzdialog(8). 2. Submit current tzdialog(8) version (1.1) and yet-to-be completed man-page to ports-tree as sysutils/tzdialog. __________________________________________________________________ The FreeBSD Foundation Status Report URL: www.FreeBSDFoundation.org Contact: Deb Goodkin The most exciting news to report is that we raised $426,000 through our fundraising efforts. We were overwhelmed by the generosity of the FreeBSD community. We would like to thank everyone who made a contribution to FreeBSD by either making a financial donation to the foundation or volunteering on the Project. We published our semi-annual newsletter in December. If you have not already done so, please take a moment to read this publication to find out how we supported the FreeBSD Project and community during the second half of 2011. There are also two great testimonials in the newsletter from TaxiMagic and the Apache Software Foundation. The Foundation sponsored EuroBSDCon 2011 which was held in The Netherlands, October 6-9. And, we sponsored six developers to attend the conference. We sponsored the Bay Area Vendor Summit in November. We were represented at LISA '11, Dec 7-8 in Boston MA. We are a proud sponsor of AsiaBSDCon 2012, which will be held in Tokyo, Japan, March 22-25. The Foundation funded project Feed-Forward Clock Synchronization Algorithms Project by the University of Melbourne completed. We approved two new projects for 2012, they are analyzing the performance of FreeBSD's IPv6 stack by Bjoern Zeeb, and implementing auditdistd daemon by Pawel Jakub Dawidek We purchased more servers and other hardware for the FreeBSD co-location centers at Sentex, NYI, and ISC. The work above, as well as many other tasks which we do for the FreeBSD Project, could not be done without donations. Please help us by making a donation or asking your company to make a donation. We would be happy to send marketing literature to you or your company. Find out how to make a donation at our donate page. Find out more up-to-date Foundation news by reading our blog and Facebook page. __________________________________________________________________ The FreeBSD German Documentation Project URL: https://doc.bsdgroup.de/ URL: http://www.FreeBSD.org/doc/de_DE.ISO8859-1/books/handbook/bsdinstall.ht ml Contact: Benedict Reuschling Contact: Johann Kois The German Documentation Project is happy to report that two big chapters have been translated in the past quarter. The first update is in the firewall chapter and covering the complete IPFW section. It was contributed by Christopher J. Ruwe. There were style and language fixes to be done, but the biggest amount of work, the actual translation, was done by him. We thank Christopher very much. The other chapter that was translated is the new bsdinstall chapter. Benedict Reuschling did the work on this chapter. He tried to keep the same titles for sections that are mostly describing the same things as in the sysinstall chapter (at least where this was possible). German speaking users are encouraged to read both chapters and report typos or grammar errors back to us so we can fix them. The German website is being updated on a regular basis. Open tasks: 1. Catch up with the latest changes made to the documentation. 2. Translate more www pages into German. 3. Find bugs in the German documentation and fix them. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki During this period, many part of the outdated contents in the www/ja subtree were updated to the latest versions in the English counterpart. The "bsdinstall" section in Handbook was newly translated and the "cutting-edge" section is now work-in-progress. Open tasks: 1. Further translation work for outdated documents in both doc/ja_JP.eucJP and www/ja. __________________________________________________________________ The New CARP URL: http://svnweb.FreeBSD.org/base?view=revision&revision=228571 Contact: Gleb Smirnoff Contact: Bjoern Zeeb Contact: George Neville-Neil Significantly updated CARP protocol has been committed to head/. I expect the new code to be easier to maintain and less buggy, since it uses less hacks in the networking stack. The new CARP does not bring a lot of new features, however here is a couple: * One can put a single redundant address on an interface. * Master/backup state can be switched via ifconfig. * Feature that demotes carp(4) during pfsync(4) update has been restored (it was lost in 7.0). * The overall ifconfig(8) output is now more readable, since addresses are exactly on the interfaces they are running. Yes, this is feature, too :) The code has been developed by glebius@ with lots of help from bz@. Open tasks: 1. Work on arpbalance/ipbalance features. Since I do not utilize them at all, first I need to find somebody eager to see these features and willing to test patches. Sponsoring work is also appreciated. glebius@ to handle. 2. Estimate whether we need to catch up with OpenBSD on putting demotion counter into datagrams. glebius@ to handle. 3. Update tcpdump(8) to enable nice printing of CARP packets. gnn@ to handle. 4. Work with IANA to get an official protocol number. gnn@ to handle. __________________________________________________________________ Up to Date X.Org Server URL: http://wiki.FreeBSD.org/Xorg Contact: X11 FreeBSD mailing list The X11 team has started work on the next major update for the X.Org ports. You might have noticed libraries and proto ports being updated that belong to the X.Org stack. Currently in our development repository we have the latest versions of many ports including mesa and xf86-video-intel. We support versions 1.7.7 and 1.10.4 of the X.Org tree for users with the appropriate hardware and patches. We need more testers for both the standard version from xorg-devel and the WITH_NEW_XORG version. We also need testers for updated input/video drivers, especially for the less mainstream ones. In order to test check out our svn repository from http://trillian.chruetertee.ch/ports/browser/branches/xorg-dev and the merge script from http://people.FreeBSD.org/~miwi/xorg/xorgmerge. See the wiki for more details. Open tasks: 1. Investigate xorg-server 1.12 which brings xinput 2.2. 2. Merge development repository into the main repository, after more testing. __________________________________________________________________ (c) 1995-2012 The FreeBSD Project. All rights reserved. From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 16:34:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B8A106564A for ; Fri, 27 Jan 2012 16:34:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 63FBC8FC13 for ; Fri, 27 Jan 2012 16:34:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 01BA246B37; Fri, 27 Jan 2012 11:34:42 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86F1EB96F; Fri, 27 Jan 2012 11:34:41 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 27 Jan 2012 10:13:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201262103.q0QL3QWr083496@ambrisko.com> <20120127085656.GY2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120127085656.GY2726@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201271013.55474.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jan 2012 11:34:41 -0500 (EST) Cc: Kostik Belousov Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:34:42 -0000 On Friday, January 27, 2012 3:56:56 am Kostik Belousov wrote: > On Thu, Jan 26, 2012 at 01:03:26PM -0800, Doug Ambrisko wrote: > > Ran into problems with running kqueue/aio with WITNESS etc. Sometimes > > things are locked sometimes not. knlist_remove is called telling it > > whether it is locked or not ie: > > extern void knlist_remove(struct knlist *knl, struct knote *kn, int islocked); > > so I changed: > > extern int knlist_empty(struct knlist *knl); > > to: > > extern int knlist_empty(struct knlist *knl, int islocked); > > > > and then updated things to reflect that following what that state of the > > lock for knlist_remove. If it is not locked, it gets a lock and > > frees it after. > > > > This now fixes a panic when a process using kqueue/aio is killed on > > shutdown with WITNESS. > > > > It changes an API/ABI so it probably can't merged back. If there are > > no objections then I'll commit it. > > > Change to knlist_init() does not make sense at all, the knlist shall > not be exposed to other consumers during initialization, so no need > to exclude the parallel access. > > Regarding the knlist_empty(), I propose to keep it as is. Locking > the knlist inside knlist_empty() does not make sense, because lock > is immediately dropped afterward, and relocked for remove. This way, > the entry could be removed from the list meantime (can it, really ?). > > I think that you should take a lock around the whole if() {} statement, > and call knlist_remove with locked == 1. Agreed, I think the missing locking should just be added to the aio code. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:15:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CCC0106564A for ; Fri, 27 Jan 2012 17:15:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 18CD18FC14 for ; Fri, 27 Jan 2012 17:15:50 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 27 Jan 2012 09:15:53 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q0RHFq4O086860; Fri, 27 Jan 2012 09:15:52 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q0RHFqZc086859; Fri, 27 Jan 2012 09:15:52 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201201271715.q0RHFqZc086859@ambrisko.com> In-Reply-To: <201201271013.55474.jhb@freebsd.org> To: John Baldwin Date: Fri, 27 Jan 2012 09:15:52 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:15:51 -0000 John Baldwin writes: | On Friday, January 27, 2012 3:56:56 am Kostik Belousov wrote: | > On Thu, Jan 26, 2012 at 01:03:26PM -0800, Doug Ambrisko wrote: | > > Ran into problems with running kqueue/aio with WITNESS etc. Sometimes | > > things are locked sometimes not. knlist_remove is called telling it | > > whether it is locked or not ie: | > > extern void knlist_remove(struct knlist *knl, struct knote *kn, | int islocked); | > > so I changed: | > > extern int knlist_empty(struct knlist *knl); | > > to: | > > extern int knlist_empty(struct knlist *knl, int islocked); | > > | > > and then updated things to reflect that following what that state of the | > > lock for knlist_remove. If it is not locked, it gets a lock and | > > frees it after. | > > | > > This now fixes a panic when a process using kqueue/aio is killed on | > > shutdown with WITNESS. | > > | > > It changes an API/ABI so it probably can't merged back. If there are | > > no objections then I'll commit it. | > > | > Change to knlist_init() does not make sense at all, the knlist shall | > not be exposed to other consumers during initialization, so no need | > to exclude the parallel access. | > | > Regarding the knlist_empty(), I propose to keep it as is. Locking | > the knlist inside knlist_empty() does not make sense, because lock | > is immediately dropped afterward, and relocked for remove. This way, | > the entry could be removed from the list meantime (can it, really ?). | > | > I think that you should take a lock around the whole if() {} statement, | > and call knlist_remove with locked == 1. | | Agreed, I think the missing locking should just be added to the aio code. Okay so then just: Index: vfs_aio.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v retrieving revision 1.243.2.3.4.1 diff -u -p -r1.243.2.3.4.1 vfs_aio.c --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 @@ -2509,9 +2509,12 @@ static void filt_aiodetach(struct knote *kn) { struct aiocblist *aiocbe = kn->kn_ptr.p_aio; + struct knlist *knl = &aiocbe->klist; - if (!knlist_empty(&aiocbe->klist)) - knlist_remove(&aiocbe->klist, kn, 0); + knl->kl_lock(knl->kl_lockarg); + if (!knlist_empty(knl)) + knlist_remove(knl, kn, 1); + knl->kl_unlock(knl->kl_lockarg); } /* kqueue filter function */ I was trying to be consistant with knlist_remove but this is a much smaller change that can be merge to older branches. Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:34:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A38A1065723 for ; Fri, 27 Jan 2012 17:34:25 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 982928FC0A for ; Fri, 27 Jan 2012 17:34:23 +0000 (UTC) Received: from [46.255.176.2] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rqpgp-00059W-VV; Fri, 27 Jan 2012 18:34:21 +0100 Message-ID: <4F22E01B.3010204@FreeBSD.org> Date: Fri, 27 Jan 2012 18:34:19 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Kurtsou , freebsd-current@freebsd.org References: <4F1EBF42.4050307@FreeBSD.org> <20120126100745.GA62071@reks> In-Reply-To: <20120126100745.GA62071@reks> X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------020208080603040400090703" Cc: Pierre-Gilles Mialon , Romain Vrignaud Subject: Re: [patch] pam_exec: use program exit code instead of PAM_SYSTEM_ERR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:34:25 -0000 This is a multi-part message in MIME format. --------------020208080603040400090703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.01.2012 11:07, Gleb Kurtsou wrote: > On (24/01/2012 15:25), Jean-Sébastien Pédron wrote: >> Attached is a patch that changes the behaviour to always return >> the program exit code as-is. > > Please consider making it optional. It will break for generic > applications because pam_sm_chauthtok error codes are documented > and standardized. You're right, thanks. I attached a new patch with the following changes: o Instead of making it optionnal, I preferred to check the exit code for each pam_sm_* functions supported. Here are the rules: - If the code is allowed, it's returned as is. - If the exit code is 1 (not an allowed PAM code here), PAM_PERM_DENIED is returned. I added this because 1 is a common exit code for errors. - For any other codes, a message is logged about this invalid value and PAM_SERVICE_ERR is returned. o I changed return code from PAM_SYSTEM_ERR to PAM_SERVICE_ERR for the WIFSIGNALED(status) and !WIFEXITED(status) cases. PAM_SYSTEM_ERR is still returned if a syscall fails. o A new environment variable is set before calling the program: PAM_SM_FUNC. It contains the name of the pam_sm_* function. The program can use it to determine which exit codes are allowed. o The pam_sm_* function name is also added to messages logged from _pam_exec(). o waitpid() is now called in a loop. If it returned because of EINTR, do it again. Before, it would return PAM_SYSTEM_ERR without waiting for the child to exit. I expanded the man page with these informations. Again, thanks for your comments! If you have more, they're welcome :) - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8i4BsACgkQa+xGJsFYOlN/EQCg0D3uHsJC2y9jO/Sk9LHTg/xf POcAnjUUjLwWd035bHqg4o4Ry/htfEkJ =l4+1 -----END PGP SIGNATURE----- --------------020208080603040400090703 Content-Type: text/plain; name="pam_exec-return-exit-code-e.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pam_exec-return-exit-code-e.patch" ZGlmZiAtLWdpdCBhL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZXhlYy9wYW1fZXhlYy44IGIv bGliL2xpYnBhbS9tb2R1bGVzL3BhbV9leGVjL3BhbV9leGVjLjgKaW5kZXggMzExZDY0Yy4u OTI5N2IxZTAgMTAwNjQ0Ci0tLSBhL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZXhlYy9wYW1f ZXhlYy44CisrKyBiL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZXhlYy9wYW1fZXhlYy44CkBA IC0zMiw3ICszMiw3IEBACiAuXCIKIC5cIiAkRnJlZUJTRCQKIC5cIgotLkRkIEZlYnJ1YXJ5 IDEsIDIwMDUKKy5EZCBKYW51YXJ5IDI3LCAyMDEyCiAuRHQgUEFNX0VYRUMgOAogLk9zCiAu U2ggTkFNRQpAQCAtNTYsMTMgKzU2LDUxIEBAIHZhcmlhYmxlczoKIC5FdiBQQU1fUkhPU1Qg LAogLkV2IFBBTV9SVVNFUiAsCiAuRXYgUEFNX1NFUlZJQ0UgLAotLkV2IFBBTV9UVFkgLAor LkV2IFBBTV9TTV9GVU5DICwKKy5FdiBQQU1fVFRZCiBhbmQKIC5FdiBQQU1fVVNFUiAuCisu UHAKK1RoZQorLkV2IFBBTV9TTV9GVU5DCit2YXJpYWJsZSBjb250YWlucyB0aGUgbmFtZSBv ZiB0aGUgUEFNIHNlcnZpY2UgbW9kdWxlIGZ1bmN0aW9uIGJlaW5nCitjYWxsZWQuIEl0IG1h eSBiZToKKy5CbCAtYnVsbGV0IC1vZmZzZXQgaW5kZW50IC1jb21wYWN0CisuSXQKK3BhbV9z bV9hY2N0X21nbXQKKy5JdAorcGFtX3NtX2F1dGhlbnRpY2F0ZQorLkl0CitwYW1fc21fY2hh dXRodG9rCisuSXQKK3BhbV9zbV9jbG9zZV9zZXNzaW9uCisuSXQKK3BhbV9zbV9vcGVuX3Nl c3Npb24KKy5JdAorcGFtX3NtX3NldGNyZWQKKy5FbAorLlBwCitUaGUgcHJvZ3JhbSBleGl0 IGNvZGUgc2hvdWxkIGJlCisuRXIgUEFNX1NVQ0NFU1MKK29yIG9uZSBvZiB0aGUgZXJyb3Ig Y29kZXMgYWxsb3dlZCBieSB0aGUgY2FsbGluZworLkV2IFBBTV9TTV9GVU5DCitmdW5jdGlv bi4KK1RoZSB2YWxpZCBjb2RlcyBhcmUgZG9jdW1lbnRlZCBpbiBlYWNoIGZ1bmN0aW9uIG1h biBwYWdlIGFuZCB0aGVpcgorbnVtZXJpY2FsIHZhbHVlIGlzIGRlZmluZWQgaW4KKy5QYSAv dXNyL2luY2x1ZGUvc2VjdXJpdHkvcGFtX2NvbnN0YW50cy5oCit1bmRlciBzZWN0aW9uICJY U1NPIDUuMiIuIEF1dGhlbnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwgaWYgdGhlIHJldHVybiBj b2RlIGlzCisuRXIgUEFNX1NVQ0NFU1MKKygwKSwgZmFpbGVkIG90aGVyd2lzZS4KIC5TaCBT RUUgQUxTTwogLlhyIHBhbV9nZXRfaXRlbSAzICwKIC5YciBwYW0uY29uZiA1ICwKLS5YciBw YW0gOAorLlhyIHBhbSA4ICwKKy5YciBwYW1fc21fYWNjdF9tZ210IDggLAorLlhyIHBhbV9z bV9hdXRoZW50aWNhdGUgOCAsCisuWHIgcGFtX3NtX2NoYXV0aHRvayA4LAorLlhyIHBhbV9z bV9jbG9zZV9zZXNzaW9uIDggLAorLlhyIHBhbV9zbV9vcGVuX3Nlc3Npb24gOCAsCisuWHIg cGFtX3NtX3NldGNyZWQgOCAuCiAuU2ggQVVUSE9SUwogVGhlCiAuTm0KZGlmZiAtLWdpdCBh L2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZXhlYy9wYW1fZXhlYy5jIGIvbGliL2xpYnBhbS9t b2R1bGVzL3BhbV9leGVjL3BhbV9leGVjLmMKaW5kZXggYjdhODcwZi4uNzg2MzE5ZSAxMDA2 NDQKLS0tIGEvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9leGVjL3BhbV9leGVjLmMKKysrIGIv bGliL2xpYnBhbS9tb2R1bGVzL3BhbV9leGVjL3BhbV9leGVjLmMKQEAgLTYyLDEwICs2Miwx MCBAQCBzdGF0aWMgc3RydWN0IHsKIAogc3RhdGljIGludAogX3BhbV9leGVjKHBhbV9oYW5k bGVfdCAqcGFtaCBfX3VudXNlZCwgaW50IGZsYWdzIF9fdW51c2VkLAotICAgIGludCBhcmdj LCBjb25zdCBjaGFyICphcmd2W10pCisgICAgY29uc3QgY2hhciAqZnVuYywgaW50IGFyZ2Ms IGNvbnN0IGNoYXIgKmFyZ3ZbXSkKIHsKIAlpbnQgZW52bGVuLCBpLCBuaXRlbXMsIHBhbV9l cnIsIHN0YXR1czsKLQljaGFyICplbnYsICoqZW52bGlzdCwgKip0bXA7CisJY2hhciAqZW52 LCAqKmVudmxpc3QsICoqdG1wLCAqZW52c3RyOwogCXZvbGF0aWxlIGludCBjaGlsZGVycjsK IAlwaWRfdCBwaWQ7CiAKQEAgLTc5LDEzICs3OSwxNCBAQCBfcGFtX2V4ZWMocGFtX2hhbmRs ZV90ICpwYW1oIF9fdW51c2VkLCBpbnQgZmxhZ3MgX191bnVzZWQsCiAKIAkvKgogCSAqIFNl dCB1cCB0aGUgY2hpbGQncyBlbnZpcm9ubWVudCBsaXN0LiAgSXQgY29uc2lzdHMgb2YgdGhl IFBBTQotCSAqIGVudmlyb25tZW50LCBwbHVzIGEgZmV3IGhhbmQtcGlja2VkIFBBTSBpdGVt cy4KKwkgKiBlbnZpcm9ubWVudCwgcGx1cyBhIGZldyBoYW5kLXBpY2tlZCBQQU0gaXRlbXMg YW5kIHRoZSBwYW1fc21fCisJICogZnVuY3Rpb24gbmFtZSBjYWxsaW5nIGl0LgogCSAqLwog CWVudmxpc3QgPSBwYW1fZ2V0ZW52bGlzdChwYW1oKTsKIAlmb3IgKGVudmxlbiA9IDA7IGVu dmxpc3RbZW52bGVuXSAhPSBOVUxMOyArK2VudmxlbikKIAkJLyogbm90aGluZyAqLyA7CiAJ bml0ZW1zID0gc2l6ZW9mKGVudl9pdGVtcykgLyBzaXplb2YoKmVudl9pdGVtcyk7Ci0JdG1w ID0gcmVhbGxvYyhlbnZsaXN0LCAoZW52bGVuICsgbml0ZW1zICsgMSkgKiBzaXplb2YoKmVu dmxpc3QpKTsKKwl0bXAgPSByZWFsbG9jKGVudmxpc3QsIChlbnZsZW4gKyBuaXRlbXMgKyAx ICsgMSkgKiBzaXplb2YoKmVudmxpc3QpKTsKIAlpZiAodG1wID09IE5VTEwpIHsKIAkJb3Bl bnBhbV9mcmVlX2Vudmxpc3QoZW52bGlzdCk7CiAJCXJldHVybiAoUEFNX0JVRl9FUlIpOwpA QCAtOTMsNyArOTQsNiBAQCBfcGFtX2V4ZWMocGFtX2hhbmRsZV90ICpwYW1oIF9fdW51c2Vk LCBpbnQgZmxhZ3MgX191bnVzZWQsCiAJZW52bGlzdCA9IHRtcDsKIAlmb3IgKGkgPSAwOyBp IDwgbml0ZW1zOyArK2kpIHsKIAkJY29uc3Qgdm9pZCAqaXRlbTsKLQkJY2hhciAqZW52c3Ry OwogCiAJCXBhbV9lcnIgPSBwYW1fZ2V0X2l0ZW0ocGFtaCwgZW52X2l0ZW1zW2ldLml0ZW0s ICZpdGVtKTsKIAkJaWYgKHBhbV9lcnIgIT0gUEFNX1NVQ0NFU1MgfHwgaXRlbSA9PSBOVUxM KQpAQCAtMTA3LDYgKzEwNywxNSBAQCBfcGFtX2V4ZWMocGFtX2hhbmRsZV90ICpwYW1oIF9f dW51c2VkLCBpbnQgZmxhZ3MgX191bnVzZWQsCiAJCWVudmxpc3RbZW52bGVuXSA9IE5VTEw7 CiAJfQogCisJLyogQWRkIHRoZSBwYW1fc21fIGZ1bmN0aW9uIG5hbWUgdG8gdGhlIGVudmly b25tZW50LiAqLworCWFzcHJpbnRmKCZlbnZzdHIsICIlcz0lcyIsICJQQU1fU01fRlVOQyIs IGZ1bmMpOworCWlmIChlbnZzdHIgPT0gTlVMTCkgeworCQlvcGVucGFtX2ZyZWVfZW52bGlz dChlbnZsaXN0KTsKKwkJcmV0dXJuIChQQU1fQlVGX0VSUik7CisJfQorCWVudmxpc3RbZW52 bGVuKytdID0gZW52c3RyOworCWVudmxpc3RbZW52bGVuXSA9IE5VTEw7CisKIAkvKgogCSAq IEZvcmsgYW5kIHJ1biB0aGUgY29tbWFuZC4gIEJ5IHVzaW5nIHZmb3JrKCkgaW5zdGVhZCBv ZiBmb3JrKCksCiAJICogd2UgY2FuIGRpc3Rpbmd1aXNoIGJldHdlZW4gYW4gZXhlY3ZlKCkg ZmFpbHVyZSBhbmQgYSBub24temVybwpAQCAtMTIwLDgxICsxMjksMjU5IEBAIF9wYW1fZXhl YyhwYW1faGFuZGxlX3QgKnBhbWggX191bnVzZWQsIGludCBmbGFncyBfX3VudXNlZCwKIAl9 CiAJb3BlbnBhbV9mcmVlX2Vudmxpc3QoZW52bGlzdCk7CiAJaWYgKHBpZCA9PSAtMSkgewot CQlvcGVucGFtX2xvZyhQQU1fTE9HX0VSUk9SLCAidmZvcmsoKTogJW0iKTsKKwkJb3BlbnBh bV9sb2coUEFNX0xPR19FUlJPUiwgIiVzOiB2Zm9yaygpOiAlbSIsIGZ1bmMpOwogCQlyZXR1 cm4gKFBBTV9TWVNURU1fRVJSKTsKIAl9Ci0JaWYgKHdhaXRwaWQocGlkLCAmc3RhdHVzLCAw KSA9PSAtMSkgewotCQlvcGVucGFtX2xvZyhQQU1fTE9HX0VSUk9SLCAid2FpdHBpZCgpOiAl bSIpOwotCQlyZXR1cm4gKFBBTV9TWVNURU1fRVJSKTsKKwl3aGlsZSAoMSkgeworCQlpZiAo d2FpdHBpZChwaWQsICZzdGF0dXMsIDApID09IC0xKSB7CisJCQlpZiAoZXJybm8gPT0gRUlO VFIpCisJCQkJY29udGludWU7CisJCQlvcGVucGFtX2xvZyhQQU1fTE9HX0VSUk9SLCAiJXM6 IHdhaXRwaWQoKTogJW0iLCBmdW5jKTsKKwkJCXJldHVybiAoUEFNX1NZU1RFTV9FUlIpOwor CQl9CisKKwkJYnJlYWs7CiAJfQogCWlmIChjaGlsZGVyciAhPSAwKSB7Ci0JCW9wZW5wYW1f bG9nKFBBTV9MT0dfRVJST1IsICJleGVjdmUoKTogJW0iKTsKKwkJb3BlbnBhbV9sb2coUEFN X0xPR19FUlJPUiwgIiVzOiBleGVjdmUoKTogJW0iLCBmdW5jKTsKIAkJcmV0dXJuIChQQU1f U1lTVEVNX0VSUik7CiAJfQogCWlmIChXSUZTSUdOQUxFRChzdGF0dXMpKSB7Ci0JCW9wZW5w YW1fbG9nKFBBTV9MT0dfRVJST1IsICIlcyBjYXVnaHQgc2lnbmFsICVkJXMiLAotCQkgICAg YXJndlswXSwgV1RFUk1TSUcoc3RhdHVzKSwKKwkJb3BlbnBhbV9sb2coUEFNX0xPR19FUlJP UiwgIiVzOiAlcyBjYXVnaHQgc2lnbmFsICVkJXMiLAorCQkgICAgZnVuYywgYXJndlswXSwg V1RFUk1TSUcoc3RhdHVzKSwKIAkJICAgIFdDT1JFRFVNUChzdGF0dXMpID8gIiAoY29yZSBk dW1wZWQpIiA6ICIiKTsKLQkJcmV0dXJuIChQQU1fU1lTVEVNX0VSUik7CisJCXJldHVybiAo UEFNX1NFUlZJQ0VfRVJSKTsKIAl9CiAJaWYgKCFXSUZFWElURUQoc3RhdHVzKSkgewotCQlv cGVucGFtX2xvZyhQQU1fTE9HX0VSUk9SLCAidW5rbm93biBzdGF0dXMgMHgleCIsIHN0YXR1 cyk7Ci0JCXJldHVybiAoUEFNX1NZU1RFTV9FUlIpOwotCX0KLQlpZiAoV0VYSVRTVEFUVVMo c3RhdHVzKSAhPSAwKSB7Ci0JCW9wZW5wYW1fbG9nKFBBTV9MT0dfRVJST1IsICIlcyByZXR1 cm5lZCBjb2RlICVkIiwKLQkJICAgIGFyZ3ZbMF0sIFdFWElUU1RBVFVTKHN0YXR1cykpOwot CQlyZXR1cm4gKFBBTV9TWVNURU1fRVJSKTsKKwkJb3BlbnBhbV9sb2coUEFNX0xPR19FUlJP UiwgIiVzOiB1bmtub3duIHN0YXR1cyAweCV4IiwKKwkJICAgIGZ1bmMsIHN0YXR1cyk7CisJ CXJldHVybiAoUEFNX1NFUlZJQ0VfRVJSKTsKIAl9Ci0JcmV0dXJuIChQQU1fU1VDQ0VTUyk7 CisJcmV0dXJuIChXRVhJVFNUQVRVUyhzdGF0dXMpKTsKIH0KIAogUEFNX0VYVEVSTiBpbnQK IHBhbV9zbV9hdXRoZW50aWNhdGUocGFtX2hhbmRsZV90ICpwYW1oLCBpbnQgZmxhZ3MsCiAg ICAgaW50IGFyZ2MsIGNvbnN0IGNoYXIgKmFyZ3ZbXSkKIHsKKwlpbnQgcmV0OwogCi0JcmV0 dXJuIChfcGFtX2V4ZWMocGFtaCwgZmxhZ3MsIGFyZ2MsIGFyZ3YpKTsKKwlyZXQgPSBfcGFt X2V4ZWMocGFtaCwgZmxhZ3MsIF9fZnVuY19fLCBhcmdjLCBhcmd2KTsKKworCS8qCisJICog V2UgbXVzdCBjaGVjayB0aGF0IHRoZSBwcm9ncmFtIHJldHVybmVkIGEgdmFsaWQgY29kZSBm b3IgdGhpcworCSAqIGZ1bmN0aW9uLgorCSAqLworCXN3aXRjaCAocmV0KSB7CisJY2FzZSBQ QU1fU1VDQ0VTUzoKKwljYXNlIFBBTV9BQk9SVDoKKwljYXNlIFBBTV9BVVRISU5GT19VTkFW QUlMOgorCWNhc2UgUEFNX0FVVEhfRVJSOgorCWNhc2UgUEFNX0JVRl9FUlI6CisJY2FzZSBQ QU1fQ09OVl9FUlI6CisJY2FzZSBQQU1fQ1JFRF9JTlNVRkZJQ0lFTlQ6CisJY2FzZSBQQU1f SUdOT1JFOgorCWNhc2UgUEFNX01BWFRSSUVTOgorCWNhc2UgUEFNX1BFUk1fREVOSUVEOgor CWNhc2UgUEFNX1NFUlZJQ0VfRVJSOgorCWNhc2UgUEFNX1NZU1RFTV9FUlI6CisJY2FzZSBQ QU1fVVNFUl9VTktOT1dOOgorCQlicmVhazsKKwljYXNlIDE6CisJCXJldCA9IFBBTV9QRVJN X0RFTklFRDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJb3BlbnBhbV9sb2coUEFNX0xPR19F UlJPUiwgIiVzIHJldHVybmVkIGludmFsaWQgY29kZSAlZCIsCisJCSAgICBhcmd2WzBdLCBy ZXQpOworCQlyZXQgPSBQQU1fU0VSVklDRV9FUlI7CisJfQorCisJcmV0dXJuIChyZXQpOwog fQogCiBQQU1fRVhURVJOIGludAogcGFtX3NtX3NldGNyZWQocGFtX2hhbmRsZV90ICpwYW1o LCBpbnQgZmxhZ3MsCiAgICAgaW50IGFyZ2MsIGNvbnN0IGNoYXIgKmFyZ3ZbXSkKIHsKKwlp bnQgcmV0OworCisJcmV0ID0gX3BhbV9leGVjKHBhbWgsIGZsYWdzLCBfX2Z1bmNfXywgYXJn YywgYXJndik7CisKKwkvKgorCSAqIFdlIG11c3QgY2hlY2sgdGhhdCB0aGUgcHJvZ3JhbSBy ZXR1cm5lZCBhIHZhbGlkIGNvZGUgZm9yIHRoaXMKKwkgKiBmdW5jdGlvbi4KKwkgKi8KKwlz d2l0Y2ggKHJldCkgeworCWNhc2UgUEFNX1NVQ0NFU1M6CisJY2FzZSBQQU1fQUJPUlQ6CisJ Y2FzZSBQQU1fQlVGX0VSUjoKKwljYXNlIFBBTV9DT05WX0VSUjoKKwljYXNlIFBBTV9DUkVE X0VSUjoKKwljYXNlIFBBTV9DUkVEX0VYUElSRUQ6CisJY2FzZSBQQU1fQ1JFRF9VTkFWQUlM OgorCWNhc2UgUEFNX0lHTk9SRToKKwljYXNlIFBBTV9QRVJNX0RFTklFRDoKKwljYXNlIFBB TV9TRVJWSUNFX0VSUjoKKwljYXNlIFBBTV9TWVNURU1fRVJSOgorCWNhc2UgUEFNX1VTRVJf VU5LTk9XTjoKKwkJYnJlYWs7CisJY2FzZSAxOgorCQlyZXQgPSBQQU1fUEVSTV9ERU5JRUQ7 CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCW9wZW5wYW1fbG9nKFBBTV9MT0dfRVJST1IsICIl cyByZXR1cm5lZCBpbnZhbGlkIGNvZGUgJWQiLAorCQkgICAgYXJndlswXSwgcmV0KTsKKwkJ cmV0ID0gUEFNX1NFUlZJQ0VfRVJSOworCX0KIAotCXJldHVybiAoX3BhbV9leGVjKHBhbWgs IGZsYWdzLCBhcmdjLCBhcmd2KSk7CisJcmV0dXJuIChyZXQpOwogfQogCiBQQU1fRVhURVJO IGludAogcGFtX3NtX2FjY3RfbWdtdChwYW1faGFuZGxlX3QgKnBhbWgsIGludCBmbGFncywK ICAgICBpbnQgYXJnYywgY29uc3QgY2hhciAqYXJndltdKQogeworCWludCByZXQ7CisKKwly ZXQgPSBfcGFtX2V4ZWMocGFtaCwgZmxhZ3MsIF9fZnVuY19fLCBhcmdjLCBhcmd2KTsKIAot CXJldHVybiAoX3BhbV9leGVjKHBhbWgsIGZsYWdzLCBhcmdjLCBhcmd2KSk7CisJLyoKKwkg KiBXZSBtdXN0IGNoZWNrIHRoYXQgdGhlIHByb2dyYW0gcmV0dXJuZWQgYSB2YWxpZCBjb2Rl IGZvciB0aGlzCisJICogZnVuY3Rpb24uCisJICovCisJc3dpdGNoIChyZXQpIHsKKwljYXNl IFBBTV9TVUNDRVNTOgorCWNhc2UgUEFNX0FCT1JUOgorCWNhc2UgUEFNX0FDQ1RfRVhQSVJF RDoKKwljYXNlIFBBTV9BVVRIX0VSUjoKKwljYXNlIFBBTV9CVUZfRVJSOgorCWNhc2UgUEFN X0NPTlZfRVJSOgorCWNhc2UgUEFNX0lHTk9SRToKKwljYXNlIFBBTV9ORVdfQVVUSFRPS19S RVFEOgorCWNhc2UgUEFNX1BFUk1fREVOSUVEOgorCWNhc2UgUEFNX1NFUlZJQ0VfRVJSOgor CWNhc2UgUEFNX1NZU1RFTV9FUlI6CisJY2FzZSBQQU1fVVNFUl9VTktOT1dOOgorCQlicmVh azsKKwljYXNlIDE6CisJCXJldCA9IFBBTV9QRVJNX0RFTklFRDsKKwkJYnJlYWs7CisJZGVm YXVsdDoKKwkJb3BlbnBhbV9sb2coUEFNX0xPR19FUlJPUiwgIiVzIHJldHVybmVkIGludmFs aWQgY29kZSAlZCIsCisJCSAgICBhcmd2WzBdLCByZXQpOworCQlyZXQgPSBQQU1fU0VSVklD RV9FUlI7CisJfQorCisJcmV0dXJuIChyZXQpOwogfQogCiBQQU1fRVhURVJOIGludAogcGFt X3NtX29wZW5fc2Vzc2lvbihwYW1faGFuZGxlX3QgKnBhbWgsIGludCBmbGFncywKICAgICBp bnQgYXJnYywgY29uc3QgY2hhciAqYXJndltdKQogeworCWludCByZXQ7CisKKwlyZXQgPSBf cGFtX2V4ZWMocGFtaCwgZmxhZ3MsIF9fZnVuY19fLCBhcmdjLCBhcmd2KTsKKworCS8qCisJ ICogV2UgbXVzdCBjaGVjayB0aGF0IHRoZSBwcm9ncmFtIHJldHVybmVkIGEgdmFsaWQgY29k ZSBmb3IgdGhpcworCSAqIGZ1bmN0aW9uLgorCSAqLworCXN3aXRjaCAocmV0KSB7CisJY2Fz ZSBQQU1fU1VDQ0VTUzoKKwljYXNlIFBBTV9BQk9SVDoKKwljYXNlIFBBTV9CVUZfRVJSOgor CWNhc2UgUEFNX0NPTlZfRVJSOgorCWNhc2UgUEFNX0lHTk9SRToKKwljYXNlIFBBTV9QRVJN X0RFTklFRDoKKwljYXNlIFBBTV9TRVJWSUNFX0VSUjoKKwljYXNlIFBBTV9TRVNTSU9OX0VS UjoKKwljYXNlIFBBTV9TWVNURU1fRVJSOgorCQlicmVhazsKKwljYXNlIDE6CisJCXJldCA9 IFBBTV9QRVJNX0RFTklFRDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJb3BlbnBhbV9sb2co UEFNX0xPR19FUlJPUiwgIiVzIHJldHVybmVkIGludmFsaWQgY29kZSAlZCIsCisJCSAgICBh cmd2WzBdLCByZXQpOworCQlyZXQgPSBQQU1fU0VSVklDRV9FUlI7CisJfQogCi0JcmV0dXJu IChfcGFtX2V4ZWMocGFtaCwgZmxhZ3MsIGFyZ2MsIGFyZ3YpKTsKKwlyZXR1cm4gKHJldCk7 CiB9CiAKIFBBTV9FWFRFUk4gaW50CiBwYW1fc21fY2xvc2Vfc2Vzc2lvbihwYW1faGFuZGxl X3QgKnBhbWgsIGludCBmbGFncywKICAgICBpbnQgYXJnYywgY29uc3QgY2hhciAqYXJndltd KQogeworCWludCByZXQ7CisKKwlyZXQgPSBfcGFtX2V4ZWMocGFtaCwgZmxhZ3MsIF9fZnVu Y19fLCBhcmdjLCBhcmd2KTsKKworCS8qCisJICogV2UgbXVzdCBjaGVjayB0aGF0IHRoZSBw cm9ncmFtIHJldHVybmVkIGEgdmFsaWQgY29kZSBmb3IgdGhpcworCSAqIGZ1bmN0aW9uLgor CSAqLworCXN3aXRjaCAocmV0KSB7CisJY2FzZSBQQU1fU1VDQ0VTUzoKKwljYXNlIFBBTV9B Qk9SVDoKKwljYXNlIFBBTV9CVUZfRVJSOgorCWNhc2UgUEFNX0NPTlZfRVJSOgorCWNhc2Ug UEFNX0lHTk9SRToKKwljYXNlIFBBTV9QRVJNX0RFTklFRDoKKwljYXNlIFBBTV9TRVJWSUNF X0VSUjoKKwljYXNlIFBBTV9TRVNTSU9OX0VSUjoKKwljYXNlIFBBTV9TWVNURU1fRVJSOgor CQlicmVhazsKKwljYXNlIDE6CisJCXJldCA9IFBBTV9QRVJNX0RFTklFRDsKKwkJYnJlYWs7 CisJZGVmYXVsdDoKKwkJb3BlbnBhbV9sb2coUEFNX0xPR19FUlJPUiwgIiVzIHJldHVybmVk IGludmFsaWQgY29kZSAlZCIsCisJCSAgICBhcmd2WzBdLCByZXQpOworCQlyZXQgPSBQQU1f U0VSVklDRV9FUlI7CisJfQogCi0JcmV0dXJuIChfcGFtX2V4ZWMocGFtaCwgZmxhZ3MsIGFy Z2MsIGFyZ3YpKTsKKwlyZXR1cm4gKHJldCk7CiB9CiAKIFBBTV9FWFRFUk4gaW50CiBwYW1f c21fY2hhdXRodG9rKHBhbV9oYW5kbGVfdCAqcGFtaCwgaW50IGZsYWdzLAogICAgIGludCBh cmdjLCBjb25zdCBjaGFyICphcmd2W10pCiB7CisJaW50IHJldDsKKworCXJldCA9IF9wYW1f ZXhlYyhwYW1oLCBmbGFncywgX19mdW5jX18sIGFyZ2MsIGFyZ3YpOworCisJLyoKKwkgKiBX ZSBtdXN0IGNoZWNrIHRoYXQgdGhlIHByb2dyYW0gcmV0dXJuZWQgYSB2YWxpZCBjb2RlIGZv ciB0aGlzCisJICogZnVuY3Rpb24uCisJICovCisJc3dpdGNoIChyZXQpIHsKKwljYXNlIFBB TV9TVUNDRVNTOgorCWNhc2UgUEFNX0FCT1JUOgorCWNhc2UgUEFNX0FVVEhUT0tfRElTQUJM RV9BR0lORzoKKwljYXNlIFBBTV9BVVRIVE9LX0VSUjoKKwljYXNlIFBBTV9BVVRIVE9LX0xP Q0tfQlVTWToKKwljYXNlIFBBTV9BVVRIVE9LX1JFQ09WRVJZX0VSUjoKKwljYXNlIFBBTV9C VUZfRVJSOgorCWNhc2UgUEFNX0NPTlZfRVJSOgorCWNhc2UgUEFNX0lHTk9SRToKKwljYXNl IFBBTV9QRVJNX0RFTklFRDoKKwljYXNlIFBBTV9TRVJWSUNFX0VSUjoKKwljYXNlIFBBTV9T WVNURU1fRVJSOgorCWNhc2UgUEFNX1RSWV9BR0FJTjoKKwkJYnJlYWs7CisJY2FzZSAxOgor CQlyZXQgPSBQQU1fUEVSTV9ERU5JRUQ7CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCW9wZW5w YW1fbG9nKFBBTV9MT0dfRVJST1IsICIlcyByZXR1cm5lZCBpbnZhbGlkIGNvZGUgJWQiLAor CQkgICAgYXJndlswXSwgcmV0KTsKKwkJcmV0ID0gUEFNX1NFUlZJQ0VfRVJSOworCX0KIAot CXJldHVybiAoX3BhbV9leGVjKHBhbWgsIGZsYWdzLCBhcmdjLCBhcmd2KSk7CisJcmV0dXJu IChyZXQpOwogfQogCiBQQU1fTU9EVUxFX0VOVFJZKCJwYW1fZXhlYyIpOwo= --------------020208080603040400090703-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:42:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72DB1065670; Fri, 27 Jan 2012 17:42:57 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7F78FC1D; Fri, 27 Jan 2012 17:42:57 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 27 Jan 2012 09:43:00 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q0RHgxEt091010; Fri, 27 Jan 2012 09:42:59 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q0RHgwGS091009; Fri, 27 Jan 2012 09:42:58 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201201271742.q0RHgwGS091009@ambrisko.com> In-Reply-To: <5EDB646F-513F-411A-ABBC-6DA555D2EAC6@averesystems.com> To: Andrew Boyer Date: Fri, 27 Jan 2012 09:42:58 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:42:57 -0000 Andrew Boyer writes: | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: | | > John Baldwin writes: | > | Agreed, I think the missing locking should just be added to the aio code. | > | > Okay so then just: | > | > Index: vfs_aio.c | > =================================================================== | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v | > retrieving revision 1.243.2.3.4.1 | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c | > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 | > @@ -2509,9 +2509,12 @@ static void | > filt_aiodetach(struct knote *kn) | > { | > struct aiocblist *aiocbe = kn->kn_ptr.p_aio; | > + struct knlist *knl = &aiocbe->klist; | > | > - if (!knlist_empty(&aiocbe->klist)) | > - knlist_remove(&aiocbe->klist, kn, 0); | > + knl->kl_lock(knl->kl_lockarg); | > + if (!knlist_empty(knl)) | > + knlist_remove(knl, kn, 1); | > + knl->kl_unlock(knl->kl_lockarg); | > } | > | > /* kqueue filter function */ | > | > I was trying to be consistant with knlist_remove but this is a much | > smaller change that can be merge to older branches. | | Does filt_liodetach() need the same treatment? Yes, I had that in the original. I updated that and optimized the knl to just get the structure needed. Index: vfs_aio.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v retrieving revision 1.243.2.3.4.1 diff -u -p -r1.243.2.3.4.1 vfs_aio.c --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 +++ vfs_aio.c 27 Jan 2012 17:35:47 -0000 @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn) static void filt_aiodetach(struct knote *kn) { - struct aiocblist *aiocbe = kn->kn_ptr.p_aio; + struct knlist *knl = &kn->kn_ptr.p_aio->klist; - if (!knlist_empty(&aiocbe->klist)) - knlist_remove(&aiocbe->klist, kn, 0); + knl->kl_lock(knl->kl_lockarg); + if (!knlist_empty(knl)) + knlist_remove(knl, kn, 1); + knl->kl_unlock(knl->kl_lockarg); } /* kqueue filter function */ @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn) static void filt_liodetach(struct knote *kn) { - struct aioliojob * lj = kn->kn_ptr.p_lio; + struct knlist *knl = &kn->kn_ptr.p_lio->klist; - if (!knlist_empty(&lj->klist)) - knlist_remove(&lj->klist, kn, 0); + knl->kl_lock(knl->kl_lockarg); + if (!knlist_empty(knl)) + knlist_remove(knl, kn, 1); + knl->kl_unlock(knl->kl_lockarg); } /* kqueue filter function */ Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:43:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE6F1065679; Fri, 27 Jan 2012 17:43:51 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9E48FC21; Fri, 27 Jan 2012 17:43:50 +0000 (UTC) Received: by eaaa14 with SMTP id a14so746653eaa.13 for ; Fri, 27 Jan 2012 09:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=to:mime-version:references:in-reply-to:user-agent:x-identity-key :content-type:fcc:message-id:content-transfer-encoding:cc:x-mailer :from:subject:x-mozilla-draft-info:date; bh=5IdH8oGV929G2ul/6NwM13OyK8HgazbnyBXs1vkSZKo=; b=oXQ6e/JIehR6vy6NRNQYw8BGy2TyTGp1Tn8qi57orOaC3+3i5HXAvDdAz8lAyxlVLD KtGzpO98sZxj3wFiYg6jD4mOZTpPzFCkTaaw7GTIheqHKnPApNQGGi0jcSd24d3VNhql zt2TWUW+j9vX/3WhzKd7rYRGJF8rXFvM3tbMk= Received: by 10.213.34.17 with SMTP id j17mr1271624ebd.84.1327686229128; Fri, 27 Jan 2012 09:43:49 -0800 (PST) Received: from [192.168.1.12] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id t11sm5000979eea.10.2012.01.27.09.43.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 09:43:47 -0800 (PST) To: "Kenneth D. Merry" Mime-Version: 1.0 References: <20120120204459.GA51162@nargothrond.kdm.org> <4F1EC371.4040608@gmail.com> <20120124163538.GA81247@nargothrond.kdm.org> In-Reply-To: <20120124163538.GA81247@nargothrond.kdm.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 X-Identity-Key: id3 Fcc: imap://joh.hendriks%40gmail.com@imap.googlemail.com/[Gmail]/Verzonden berichten Message-Id: <95ED928D-6FB5-43EB-A7F7-40FA34B7C1CA@gmail.com> X-Mailer: iPad Mail (9A405) From: Johan Hendriks X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 Date: Fri, 27 Jan 2012 18:43:47 +0100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Subject: Re: LSI supported mps(4) driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:43:51 -0000 Kenneth D. Merry schreef: >=20 > On Tue, Jan 24, 2012 at 15:42:57 +0100, Johan Hendriks wrote: >> Kenneth D. Merry schreef: >>> The LSI-supported version of the mps(4) driver that supports their 6Gb S= AS >>> HBAs as well as WarpDrive controllers, is available here: >>>=20 >>> http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt >>>=20 >>> I plan to check it in to head next week, and then MFC it into stable/9 a= >>> week after that most likely. >>>=20 >>> Please test it out and let me know if you run into any problems. >>>=20 >>> In addition to supporting WarpDrive, the driver also supports Integrated= >>> RAID. >>>=20 >>> Thanks to LSI for doing the work on this driver! >>>=20 >>> I have added a number of other infrastructure changes that are necessary= >>> for the driver, and here is a brief summary: >>>=20 >>> - A new Advanced Information buffer is now added to the EDT for drives >>> that support READ CAPACITY (16). The da(4) driver updates this buffe= r >>> when it grabs new read capacity data from a drive. >>> - The mps(4) driver will look for Advanced Information state change asy= nc >>> events, and updates its table of drives with protection information >>> turned on accordingly. >>> - The size of struct scsi_read_capacity_data_long has been bumped up to= >>> the amount specified in the latest SBC-3 draft. The hope is to avoid= >>> some future structure size bumps with that change. The API for >>> scsi_read_capacity_16() has been changed to add a length argument. >>> Hopefully this will future-proof it somewhat. >>> - __FreeBSD_version bumped for the addition of the Advanced Information= >>> buffer with the read capacity information. The mps(4) driver has a >>> kludgy way of getting the information on versions of FreeBSD without >>> this change. >>>=20 >>> I believe that the CAM API changes are mild enough and beneficial enough= >>> for a merge into stable/9, but they are intertwined with the unmap chang= es >>> in the da(4) driver, so those changes will have to go back to stable/9 a= s >>> well in order to MFC the full set of changes. >>>=20 >>> Otherwise it'll just be the driver that gets merged into stable/9, and >>> it'll use the kludgy method of getting the read capacity data for each >>> drive. >>>=20 >>> A couple of notes about issues with this driver: >>>=20 >>> - Unlike the current mps(4) driver, it probes sequentially. If you hav= e=20 >>> a >>> lot of drives in your system, it will take a while to probe them all.= >>> - You may see warning messages like this: >>>=20 >>> _mapping_add_new_device: failed to add the device with handle 0x0019 to=20= >>> persiste >>> nt table because there is no free space available >>> _mapping_add_new_device: failed to add the device with handle 0x001a to=20= >>> persiste >>> nt table because there is no free space available >>>=20 >>> - The driver is not endian safe. (It assumes a little endian machine.)= >>> This is not new, the driver in the tree has the same issue. >>>=20 >>> The LSI folks know about these issues. The driver has passed their test= ing >>> process. >>>=20 >>> Many thanks to LSI for going through the effort to support FreeBSD. >>>=20 >>> Ken >> Sorry to bother you with this, but how do i test this on a 9.0 release=20= >> machine. >> I am no developer what so ever, but we use some LSI 9211-8i cards, in=20 >> supermicro storage machines. >> One machine give me scsi timeouts, and i like to try the new driver. >>=20 >> I did the following: save the=20 >> http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt as lsi.patch=20= >> in /root >>=20 >> then >> # cd /usr >> # patch < lsi.patch >> I do get some .rej from patch >>=20 >> But when i rebuild the kernel it errors out, so i think i am doing=20 >> something wrong. > The overall patch won't apply cleanly to 9.0, because it depends on some > other CAM changes that are not in 9.0. >=20 > The driver itself may apply and work, however. >=20 > The easiest thing to do may be to edit the patch and only keep the patches= > against files in sys/dev/lsi, sys/conf, and sys/modules. >=20 > Before you apply the revised patch, make sure you either back out the > previous patch attempt, or otherwise get a clean source tree. >=20 > Ken Ok thanks. I did some homework on patching, and to my own surprice, the altered patch i= have now even compiles on 9.0-RELEASE. :D only the param.h failed in the end, and i can not figure out why. So i hope the change in that file is not that important. I am running it now on a Supermicro 3U storage server with a few sata disk i= n it, with a single LSI 9211-8i card connected the the backplane. It seems to do the job. The driver coming with 9.0 had some trouble when i remirror some drives, i t= ry that tomorrow. i have put the patch here http://xs4all.nl/~doub/mps.patch=20 my dmesg for what is worth filer01# dmesg Copyright (c) 1992-2012 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 9.0-RELEASE #1: Thu Jan 26 15:37:38 CET 2012 root@filer01.neuteboom.local:/usr/obj/usr/src/sys/KRNL amd64 CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a Ste= pping =3D 7 Features=3D0xbfebfbff Features2=3D0x15bae3ff AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16493346816 (15729 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 6.0 on pci0 pci1: on pcib1 mps0: port 0xe000-0xe0ff mem 0xfb600000-0xfb603fff irq 19 at d= evice 0.0 on pci1 mps0: Firmware: 11.00.00.00, Driver: 11.255.03.00-fbsd mps0: IOCCapabilities: 1285c em0: port 0xf020-0xf03f mem 0xf= b800000-0xfb81ffff,0xfb824000-0xfb824fff irq 20 at device 25.0 on pci0 em0: No MSI/MSIX using a Legacy IRQ em0: Ethernet address: 00:25:90:57:20:bd ehci0: mem 0xfb823000-0xfb8233ff irq 16 a= t device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 em1: port 0xd000-0xd01f mem 0xf= b700000-0xfb71ffff,0xfb720000-0xfb723fff irq 16 at device 0.0 on pci3 em1: MSIX: insufficient vectors, using MSI em1: No MSI/MSIX using a Legacy IRQ em1: Ethernet address: 00:25:90:57:20:bc ehci1: mem 0xfb822000-0xfb8223ff irq 23 a= t device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 vgapci0: mem 0xf9000000-0xf9ffffff,0xfb000000-0xfb0= 03fff,0xfa800000-0xfaffffff irq 23 at device 3.0 on pci4 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060-0= xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfb821000-0xfb8217ff ir= q 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 da0 at mps0 bus 0 scbus0 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da1 at mps0 bus 0 scbus0 target 9 lun 0 da1: Fixed Direct Access SCSI-6 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da2 at mps0 bus 0 scbus0 target 10 lun 0 da2: Fixed Direct Access SCSI-6 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da3 at mps0 bus 0 scbus0 target 11 lun 0 da3: Fixed Direct Access SCSI-6 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da4 at mps0 bus 0 scbus0 target 12 lun 0 da4: Fixed Direct Access SCSI-6 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da5 at mps0 bus 0 scbus0 target 13 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 150.000MB/s transfers da5: Command Queueing enabled da5: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) ses0 at mps0 bus 0 scbus0 target 16 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 600.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 SES Device cd0 at ahcich2 bus 0 scbus3 target 0 lun 0 SMP: AP CPU #1 Launched! cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tr= ay closed SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 12082197 Hz quality 1000 da7 at mps0 bus 0 scbus0 target 15 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 150.000MB/s transfers da7: Command Queueing enabled da7: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da6 at mps0 bus 0 scbus0 target 14 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 150.000MB/s transfers da6: Command Queueing enabled da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) Root mount waiting for: GMIRROR usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: GMIRROR usbus1 usbus0 ugen0.2: at usbus0 ugen1.2: at usbus1 uhub2: on u= sbus0 uhub3: on u= sbus1 uhub3: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered ugen0.3: at usbus0 ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=3D0 ukbd0: on usbus0 kbd2 at ukbd0 Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device gm0-p2 start due to timeout. GEOM_MIRROR: Device mirror/gm0-p2 launched (1/2). Trying to mount root from ufs:/dev/mirror/gm0-p2 [rw]... Again, i am a complete=20 From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:44:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD32106564A for ; Fri, 27 Jan 2012 17:44:54 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 86D308FC0C for ; Fri, 27 Jan 2012 17:44:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 26ACF446004; Fri, 27 Jan 2012 12:27:24 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0WDV2wUShsX; Fri, 27 Jan 2012 12:27:21 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id DB22C446002; Fri, 27 Jan 2012 12:27:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <201201271715.q0RHFqZc086859@ambrisko.com> Date: Fri, 27 Jan 2012 12:25:24 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5EDB646F-513F-411A-ABBC-6DA555D2EAC6@averesystems.com> References: <201201271715.q0RHFqZc086859@ambrisko.com> To: Doug Ambrisko X-Mailer: Apple Mail (2.1084) Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:44:54 -0000 On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: > John Baldwin writes: > | Agreed, I think the missing locking should just be added to the aio code. > > Okay so then just: > > Index: vfs_aio.c > =================================================================== > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > retrieving revision 1.243.2.3.4.1 > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 > @@ -2509,9 +2509,12 @@ static void > filt_aiodetach(struct knote *kn) > { > struct aiocblist *aiocbe = kn->kn_ptr.p_aio; > + struct knlist *knl = &aiocbe->klist; > > - if (!knlist_empty(&aiocbe->klist)) > - knlist_remove(&aiocbe->klist, kn, 0); > + knl->kl_lock(knl->kl_lockarg); > + if (!knlist_empty(knl)) > + knlist_remove(knl, kn, 1); > + knl->kl_unlock(knl->kl_lockarg); > } > > /* kqueue filter function */ > > I was trying to be consistant with knlist_remove but this is a much > smaller change that can be merge to older branches. > > Thanks, > > Doug A. Does filt_liodetach() need the same treatment? -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:37:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A09F1065674 for ; Fri, 27 Jan 2012 17:37:57 +0000 (UTC) (envelope-from pgollucci@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFE468FC13 for ; Fri, 27 Jan 2012 17:37:55 +0000 (UTC) Received: by qcse14 with SMTP id e14so1457300qcs.13 for ; Fri, 27 Jan 2012 09:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:x-enigmail-version:content-type; bh=fM0Gi6e8/8uETpnQoH90wskYt9I4z9NWF6JjdY9jhqg=; b=FLgnHSDS1ekY1yEI54Rx7aQB2hYbu/hO1uQcd/NM85fMNXOoG+CHwTSI0dRO0gnVJz pxtGBpvZ/OO/YxMpLL30L//Mo4QG/ayrV5g5spM1N8bWCLCBdRK6yLyEcTavm/9/Kudr L/B++u+8bRbwyYWOD9xCeyYnF7TJwaWuBeaEc= Received: by 10.229.77.66 with SMTP id f2mr2142326qck.4.1327684097681; Fri, 27 Jan 2012 09:08:17 -0800 (PST) Received: from philip.hq.rws (wsip-174-79-184-239.dc.dc.cox.net. [174.79.184.239]) by mx.google.com with ESMTPS id m20sm16114597qaj.14.2012.01.27.09.08.15 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 09:08:16 -0800 (PST) Message-ID: <4F22D9FD.10502@p6m7g8.com> Date: Fri, 27 Jan 2012 17:08:13 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111029 Thunderbird/7.0.1 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00404A200D5298C770AC6528" X-Mailman-Approved-At: Fri, 27 Jan 2012 17:48:33 +0000 Cc: Daniel Shafaf , Scott Sanders Subject: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:37:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00404A200D5298C770AC6528 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, $ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)=3D'| xargs jid=3D17 name=3D17 $ jls JID IP Address Hostname Path 3 192.168.2.38 sid.dca1.rws /sid 17 192.168.2.41 jubilee.dca1.rws /jubilee # jubilee/chef jail_jubilee_hostname=3D"jubilee.dca1.rws" jail_jubilee_ip=3D"192.168.2.41" jail_jubilee_ip_multi0=3D"192.168.2.42" jail_jubilee_interface=3D"bge1" jail_jubilee_rootdir=3D"/jubilee" jail_jubilee_devfs_enable=3D"YES" =46rom jexec(8): DESCRIPTION The jexec utility executes command inside the jail identified by its jid or name. This works, but kind of defeats the point -- $ sudo jexec `jls |grep sid |awk '{print $1}'` /bin/bash --=20 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --------------enig00404A200D5298C770AC6528 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.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPItn/dbiP+9ubjBwRAn3xAJ9EsaWaIo98D07cwFTqaJrfpFXFmwCeKaZL j8m+ZXMchnz31KttOVr/8zc= =pTqu -----END PGP SIGNATURE----- --------------enig00404A200D5298C770AC6528-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 17:54:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9931C106566B; Fri, 27 Jan 2012 17:54:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7778FC18; Fri, 27 Jan 2012 17:54:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0RHqIhM019739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 19:52:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0RHqIrE054373; Fri, 27 Jan 2012 19:52:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0RHqIRZ054372; Fri, 27 Jan 2012 19:52:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Jan 2012 19:52:18 +0200 From: Kostik Belousov To: Doug Ambrisko Message-ID: <20120127175218.GC2726@deviant.kiev.zoral.com.ua> References: <5EDB646F-513F-411A-ABBC-6DA555D2EAC6@averesystems.com> <201201271742.q0RHgwGS091009@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VcZjVMblxkg0/8Ur" Content-Disposition: inline In-Reply-To: <201201271742.q0RHgwGS091009@ambrisko.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Andrew Boyer Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:54:52 -0000 --VcZjVMblxkg0/8Ur Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2012 at 09:42:58AM -0800, Doug Ambrisko wrote: > Andrew Boyer writes: > | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: > |=20 > | > John Baldwin writes: > | > | Agreed, I think the missing locking should just be added to the aio= code. > | >=20 > | > Okay so then just: > | >=20 > | > Index: vfs_aio.c > | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > | > retrieving revision 1.243.2.3.4.1 > | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > | > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 > | > @@ -2509,9 +2509,12 @@ static void > | > filt_aiodetach(struct knote *kn) > | > { > | > struct aiocblist *aiocbe =3D kn->kn_ptr.p_aio; > | > + struct knlist *knl =3D &aiocbe->klist; > | >=20 > | > - if (!knlist_empty(&aiocbe->klist)) > | > - knlist_remove(&aiocbe->klist, kn, 0); > | > + knl->kl_lock(knl->kl_lockarg); > | > + if (!knlist_empty(knl)) > | > + knlist_remove(knl, kn, 1); > | > + knl->kl_unlock(knl->kl_lockarg); > | > } > | >=20 > | > /* kqueue filter function */ > | >=20 > | > I was trying to be consistant with knlist_remove but this is a much > | > smaller change that can be merge to older branches. > | =20 > | Does filt_liodetach() need the same treatment? >=20 > Yes, I had that in the original. I updated that and optimized > the knl to just get the structure needed. >=20 > Index: vfs_aio.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > retrieving revision 1.243.2.3.4.1 > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > +++ vfs_aio.c 27 Jan 2012 17:35:47 -0000 > @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn) > static void > filt_aiodetach(struct knote *kn) > { > - struct aiocblist *aiocbe =3D kn->kn_ptr.p_aio; > + struct knlist *knl =3D &kn->kn_ptr.p_aio->klist; > =20 > - if (!knlist_empty(&aiocbe->klist)) > - knlist_remove(&aiocbe->klist, kn, 0); > + knl->kl_lock(knl->kl_lockarg); > + if (!knlist_empty(knl)) > + knlist_remove(knl, kn, 1); > + knl->kl_unlock(knl->kl_lockarg); > } > =20 > /* kqueue filter function */ > @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn) > static void > filt_liodetach(struct knote *kn) > { > - struct aioliojob * lj =3D kn->kn_ptr.p_lio; > + struct knlist *knl =3D &kn->kn_ptr.p_lio->klist; It is easy to be style-compiant there and move initialization of knl after the blank line. Do you need two different functions now ? I think you can leave just one. Otherwise looks fine. > =20 > - if (!knlist_empty(&lj->klist)) > - knlist_remove(&lj->klist, kn, 0); > + knl->kl_lock(knl->kl_lockarg); > + if (!knlist_empty(knl)) > + knlist_remove(knl, kn, 1); > + knl->kl_unlock(knl->kl_lockarg); > } > =20 > /* kqueue filter function */ >=20 > Thanks, >=20 > Doug A. --VcZjVMblxkg0/8Ur Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8i5FEACgkQC3+MBN1Mb4hdCgCgo+14TtYF4K7VCahvfsZhavRQ 040AoNU2pTmCGC5g69EtH1IdoS4fwDv1 =yD6O -----END PGP SIGNATURE----- --VcZjVMblxkg0/8Ur-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 18:15:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87853106566B for ; Fri, 27 Jan 2012 18:15:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 411E98FC0C for ; Fri, 27 Jan 2012 18:15:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id CBBF146B2D; Fri, 27 Jan 2012 13:15:45 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 456DDB96F; Fri, 27 Jan 2012 13:15:45 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Fri, 27 Jan 2012 13:02:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <5EDB646F-513F-411A-ABBC-6DA555D2EAC6@averesystems.com> <201201271742.q0RHgwGS091009@ambrisko.com> <20120127175218.GC2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120127175218.GC2726@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201271302.59011.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jan 2012 13:15:45 -0500 (EST) Cc: freebsd-current@freebsd.org, Andrew Boyer Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:15:46 -0000 On Friday, January 27, 2012 12:52:18 pm Kostik Belousov wrote: > On Fri, Jan 27, 2012 at 09:42:58AM -0800, Doug Ambrisko wrote: > > Andrew Boyer writes: > > | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: > > | > > | > John Baldwin writes: > > | > | Agreed, I think the missing locking should just be added to the aio code. > > | > > > | > Okay so then just: > > | > > > | > Index: vfs_aio.c > > | > =================================================================== > > | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > > | > retrieving revision 1.243.2.3.4.1 > > | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > > | > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > > | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 > > | > @@ -2509,9 +2509,12 @@ static void > > | > filt_aiodetach(struct knote *kn) > > | > { > > | > struct aiocblist *aiocbe = kn->kn_ptr.p_aio; > > | > + struct knlist *knl = &aiocbe->klist; > > | > > > | > - if (!knlist_empty(&aiocbe->klist)) > > | > - knlist_remove(&aiocbe->klist, kn, 0); > > | > + knl->kl_lock(knl->kl_lockarg); > > | > + if (!knlist_empty(knl)) > > | > + knlist_remove(knl, kn, 1); > > | > + knl->kl_unlock(knl->kl_lockarg); > > | > } > > | > > > | > /* kqueue filter function */ > > | > > > | > I was trying to be consistant with knlist_remove but this is a much > > | > smaller change that can be merge to older branches. > > | > > | Does filt_liodetach() need the same treatment? > > > > Yes, I had that in the original. I updated that and optimized > > the knl to just get the structure needed. > > > > Index: vfs_aio.c > > =================================================================== > > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > > retrieving revision 1.243.2.3.4.1 > > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > > +++ vfs_aio.c 27 Jan 2012 17:35:47 -0000 > > @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn) > > static void > > filt_aiodetach(struct knote *kn) > > { > > - struct aiocblist *aiocbe = kn->kn_ptr.p_aio; > > + struct knlist *knl = &kn->kn_ptr.p_aio->klist; > > > > - if (!knlist_empty(&aiocbe->klist)) > > - knlist_remove(&aiocbe->klist, kn, 0); > > + knl->kl_lock(knl->kl_lockarg); > > + if (!knlist_empty(knl)) > > + knlist_remove(knl, kn, 1); > > + knl->kl_unlock(knl->kl_lockarg); > > } > > > > /* kqueue filter function */ > > @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn) > > static void > > filt_liodetach(struct knote *kn) > > { > > - struct aioliojob * lj = kn->kn_ptr.p_lio; > > + struct knlist *knl = &kn->kn_ptr.p_lio->klist; > It is easy to be style-compiant there and move initialization of knl > after the blank line. > > Do you need two different functions now ? I think you can leave just one. Hmm, I think p_lio != p_aio, so two functions are required. I think the patch looks fine. The style fix to not assign 'knl' in its declaration would be nice to fix as you suggested, but that's minor. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 18:14:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C81106566C for ; Fri, 27 Jan 2012 18:14:24 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id 79BD18FC17 for ; Fri, 27 Jan 2012 18:14:23 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTyLpfW/I/xB/Jp5++msSFEykxWpLRH4l@postini.com; Fri, 27 Jan 2012 10:14:23 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 27 Jan 2012 10:12:35 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q0RICJ141509; Fri, 27 Jan 2012 10:12:33 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F22E8FD.6010201@juniper.net> Date: Fri, 27 Jan 2012 10:12:13 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120126122326.GT2726@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------050804080208020403030502" X-Mailman-Approved-At: Fri, 27 Jan 2012 18:19:37 +0000 Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:14:24 -0000 --------------050804080208020403030502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Attached are 4 separate patches for each somewhat independent portion of the kernel work related to the follow-fork implementation. On 01/26/2012 04:23 AM, Kostik Belousov wrote: > On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote: >> Thanks for taking a look at it. I'll try to explain the changes the best I >> can: the work was done nearly 6 months ago... >> >>> I would certainly appreciate some more words describing the changes. >>> >>> What is the goal of introducing the PT_FOLLOW_EXEC ? To not force >>> the debugger to filter all syscall exits to see exec events ? >> PT_FOLLOW_EXEC was added to trace the exec() family of calls. When it's >> enabled, the kernel will generate a trap to give debugger a chance to clean >> up old process info and initialize its state with the new binary. >> > It was more a question, why PT_FLAG_EXEC is not enough. > >> >>> Why did you moved the stopevent/ptracestop for exec events from >>> syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC >>> is not removed from syscallret() ? I do not think that TDB_EXEC can be >>> seen there after the patch. The same question about TDB_FORK. >> The reason I moved the event notifications from syscallret() is because the >> debugger is interested successful completion of either fork or exec, not >> just the fact that they have been called. If, say, a call to fork() failed, >> as far as debugger is concerned, fork() might as well had never been >> called. Having a ptracestop in syscallret triggered a trap on every return >> from fork without telling the debugger whether a new process had been >> created or not. Same goes for exec(). > PT_FLAG_EXEC is only set if an exec-kind of syscall succeeded. The same > is true for PT_FLAG_FORKED, the flag is set only if a new child was > successfully created. > >> Looking at the code now I think I should have removed TDB_EXEC/TDB_FORK >> processing from syscallret(). I'll do that and verify that it works as >> expected. >> >>> If possible, I would greatly prefer to have fork changes separated. >> You mean separate fork changes into a separate patch from exec changes? > Yes. Even more, it seems that fork changes should be separated into > bug fixes and new functionality. > >>> I doubt that disallowing RFMEM while tracing is the right change. It may >>> be to fix some (undescribed) bug, but RFMEM is documented behaviour used >>> not only for vfork(2), and the change just breaks rfork(2) for debugged >>> processes. >>> >>> Even vfork() should not be broken, since I believe there are programs >>> that rely on the vfork() model, in particular, C shell. It will be >>> broken if vfork() is substituted by fork(). The fact that it breaks only >>> under debugger will make it esp. confusing. >> I need to dig up the details since I can't recall the exact reason for >> forcing fork() in cases of user calls to vfork() under gdb. I believe it >> had to do with when child process memory was available for writing in case >> of vfork() and it wasn't early enough to complete the switch over from >> parent to child in gdb. After consulting with our internal kernel experts >> we decided that doing fork() instead of vfork() under gdb is a low impact >> change. >> >>> Why do we need to have TDB_FORK set for td2 ? >> The debugger needs to intercept fork() in both parent and child so it can >> detach from the old process and attach to the new one. Maybe it'll make >> more sense in the context of gdb changes. Should I send them too? Don't >> think Marcel included that patch... > No, I think the kernel changes are enough for now. > >>> Does the orphan list change intended to not lost the child after fork ? >>> But the child shall be traced, so debugger would get the SIGTRAP on >>> the attach on fork returning to usermode. I remember that I explicitely >>> tested this when adding followfork changes. >> Yes, the debugger gets SIGTRAPs. The problem arises when the real parent of >> the forked process has the code to collect termination status. Since >> attaching to a process changes the parent/child relationships, we need to >> keep track of the children lost due to re-parenting so we can properly >> attribute their exit status to the "real" parent. >> > I do not quite understand it. From the description it sounds as the problem > that is not related to follow fork changes at all, and shall be presented > regardless of the follow fork. If yes, I think this shall be separated > into a standalone patch. --------------050804080208020403030502 Content-Type: text/x-patch; name="follow-exec.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="follow-exec.patch" Index: sys/kern/kern_exec.c =================================================================== --- sys/kern/kern_exec.c (revision 230617) +++ sys/kern/kern_exec.c (working copy) @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -888,16 +889,22 @@ free(imgp->freepath, M_TEMP); if (error == 0) { + if ((p->p_flag & (P_TRACED | P_FOLLOWEXEC)) == + (P_TRACED | P_FOLLOWEXEC)) { + PROC_LOCK(p); + td->td_dbgflags |= TDB_EXEC; + PROC_UNLOCK(p); + } + /* + * Stop the process here if its stop event mask has + * the S_EXEC bit set. + */ + STOPEVENT(p, S_EXEC, 0); + PTRACESTOP_SC(p, td, S_PT_EXEC); PROC_LOCK(p); - td->td_dbgflags |= TDB_EXEC; + td->td_dbgflags &= ~TDB_EXEC; PROC_UNLOCK(p); - - /* - * Stop the process here if its stop event mask has - * the S_EXEC bit set. - */ - STOPEVENT(p, S_EXEC, 0); - goto done2; + goto done2; } exec_fail: Index: sys/kern/sys_process.c =================================================================== --- sys/kern/sys_process.c (revision 230617) +++ sys/kern/sys_process.c (working copy) @@ -660,6 +660,7 @@ case PT_TO_SCX: case PT_SYSCALL: case PT_FOLLOW_FORK: + case PT_FOLLOW_EXEC: case PT_DETACH: sx_xlock(&proctree_lock); proctree_locked = 1; @@ -874,6 +875,17 @@ p->p_flag &= ~P_FOLLOWFORK; break; + case PT_FOLLOW_EXEC: + if (data) { + p->p_flag |= P_FOLLOWEXEC; + p->p_stops |= S_PT_EXEC; + } + else { + p->p_flag &= ~P_FOLLOWEXEC; + p->p_stops &= ~S_PT_EXEC; + } + break; + case PT_STEP: case PT_CONTINUE: case PT_TO_SCE: @@ -936,7 +948,8 @@ p->p_sigparent = SIGCHLD; } p->p_oppid = 0; - p->p_flag &= ~(P_TRACED | P_WAITED | P_FOLLOWFORK); + p->p_flag &= ~(P_TRACED | P_WAITED | P_FOLLOWFORK | + P_FOLLOWEXEC); /* should we send SIGCHLD? */ /* childproc_continued(p); */ Index: sys/sys/proc.h =================================================================== --- sys/sys/proc.h (revision 230617) +++ sys/sys/proc.h (working copy) @@ -617,6 +617,7 @@ #define P_INMEM 0x10000000 /* Loaded into memory. */ #define P_SWAPPINGOUT 0x20000000 /* Process is being swapped out. */ #define P_SWAPPINGIN 0x40000000 /* Process is being swapped in. */ +#define P_FOLLOWEXEC 0x80000000 /* Notify debugger of exec events. */ #define P_STOPPED (P_STOPPED_SIG|P_STOPPED_SINGLE|P_STOPPED_TRACE) #define P_SHOULDSTOP(p) ((p)->p_flag & P_STOPPED) Index: sys/sys/ptrace.h =================================================================== --- sys/sys/ptrace.h (revision 230617) +++ sys/sys/ptrace.h (working copy) @@ -64,6 +64,7 @@ #define PT_SYSCALL 22 #define PT_FOLLOW_FORK 23 +#define PT_FOLLOW_EXEC 24 #define PT_GETREGS 33 /* get general-purpose registers */ #define PT_SETREGS 34 /* set general-purpose registers */ @@ -142,6 +143,7 @@ */ #define S_PT_SCE 0x000010000 #define S_PT_SCX 0x000020000 +#define S_PT_EXEC 0x000080000 int ptrace_set_pc(struct thread *_td, unsigned long _addr); int ptrace_single_step(struct thread *_td); --------------050804080208020403030502 Content-Type: text/x-patch; name="follow-fork.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="follow-fork.patch" Index: sys/kern/kern_fork.c =================================================================== --- sys/kern/kern_fork.c (revision 230617) +++ sys/kern/kern_fork.c (working copy) @@ -59,6 +59,7 @@ #include #include #include +#include #include #include #include @@ -702,7 +703,8 @@ * for runaway child. */ td->td_dbgflags |= TDB_FORK; - td->td_dbg_forked = p2->p_pid; + td2->td_dbgflags |= TDB_FORK; + td->td_dbg_forked = td2->td_dbg_forked = p2->p_pid; td2->td_dbgflags |= TDB_STOPATFORK; _PHOLD(p2); p2_held = 1; @@ -731,6 +733,13 @@ knote_fork(&p1->p_klist, p2->p_pid); SDT_PROBE(proc, kernel, , create, p2, p1, flags, 0, 0); + if (td->td_dbgflags & TDB_FORK) { + PTRACESTOP_SC(p1, td, S_PT_FORK); + PROC_LOCK(p1); + td->td_dbgflags &= ~TDB_FORK; + PROC_UNLOCK(p1); + } + /* * Wait until debugger is attached to child. */ @@ -1036,6 +1045,7 @@ proc_reparent(p, dbg); sx_xunlock(&proctree_lock); ptracestop(td, SIGSTOP); + td->td_dbgflags &= ~TDB_FORK; } else { /* * ... otherwise clear the request. Index: sys/kern/sys_process.c =================================================================== --- sys/kern/sys_process.c (revision 230617) +++ sys/kern/sys_process.c (working copy) @@ -868,10 +868,14 @@ break; case PT_FOLLOW_FORK: - if (data) + if (data) { p->p_flag |= P_FOLLOWFORK; - else + p->p_stops |= S_PT_FORK; + } + else { p->p_flag &= ~P_FOLLOWFORK; + p->p_stops &= ~S_PT_FORK; + } break; case PT_STEP: Index: sys/sys/ptrace.h =================================================================== --- sys/sys/ptrace.h (revision 230617) +++ sys/sys/ptrace.h (working copy) @@ -142,6 +142,7 @@ */ #define S_PT_SCE 0x000010000 #define S_PT_SCX 0x000020000 +#define S_PT_FORK 0x000040000 int ptrace_set_pc(struct thread *_td, unsigned long _addr); int ptrace_single_step(struct thread *_td); --------------050804080208020403030502 Content-Type: text/x-patch; name="orphan.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="orphan.patch" Index: sys/kern/kern_exit.c =================================================================== --- sys/kern/kern_exit.c (revision 230617) +++ sys/kern/kern_exit.c (working copy) @@ -680,7 +680,7 @@ */ void proc_reap(struct thread *td, struct proc *p, int *status, int options, - struct rusage *rusage) + struct rusage *rusage, int child) { struct proc *q, *t; @@ -720,7 +720,6 @@ if (p->p_oppid && (t = pfind(p->p_oppid)) != NULL) { PROC_LOCK(p); proc_reparent(p, t); - p->p_pptr->p_dbg_child--; p->p_oppid = 0; PROC_UNLOCK(p); pksignal(t, SIGCHLD, p->p_ksi); @@ -738,7 +737,10 @@ sx_xlock(&allproc_lock); LIST_REMOVE(p, p_list); /* off zombproc */ sx_xunlock(&allproc_lock); - LIST_REMOVE(p, p_sibling); + if (child) + LIST_REMOVE(p, p_sibling); + else + LIST_REMOVE(p, p_orphan); leavepgrp(p); #ifdef PROCDESC if (p->p_procdesc != NULL) @@ -859,7 +861,7 @@ nfound++; PROC_SLOCK(p); if (p->p_state == PRS_ZOMBIE) { - proc_reap(td, p, status, options, rusage); + proc_reap(td, p, status, options, rusage, 1); return (0); } if ((p->p_flag & P_STOPPED_SIG) && @@ -893,16 +895,47 @@ if (status) *status = SIGCONT; + } + PROC_UNLOCK(p); + } + LIST_FOREACH(p, &q->p_orphans, p_orphan) { + PROC_LOCK(p); + if (pid != WAIT_ANY && + p->p_pid != pid && p->p_pgid != -pid) { + PROC_UNLOCK(p); + continue; + } + if (p_canwait(td, p)) { + PROC_UNLOCK(p); + continue; + } + + /* + * This special case handles a kthread spawned by linux_clone + * (see linux_misc.c). The linux_wait4 and linux_waitpid + * functions need to be able to distinguish between waiting + * on a process and waiting on a thread. It is a thread if + * p_sigparent is not SIGCHLD, and the WLINUXCLONE option + * signifies we want to wait for threads and not processes. + */ + if ((p->p_sigparent != SIGCHLD) ^ + ((options & WLINUXCLONE) != 0)) { + PROC_UNLOCK(p); + continue; + } + + nfound++; + PROC_SLOCK(p); + if (p->p_state == PRS_ZOMBIE) { + proc_reap(td, p, status, options, rusage, 0); return (0); } + PROC_SUNLOCK(p); PROC_UNLOCK(p); } if (nfound == 0) { sx_xunlock(&proctree_lock); - if (td->td_proc->p_dbg_child) - return (0); - else - return (ECHILD); + return (ECHILD); } if (options & WNOHANG) { sx_xunlock(&proctree_lock); @@ -929,6 +962,7 @@ void proc_reparent(struct proc *child, struct proc *parent) { + struct proc *p; sx_assert(&proctree_lock, SX_XLOCKED); PROC_LOCK_ASSERT(child, MA_OWNED); @@ -940,5 +974,17 @@ PROC_UNLOCK(child->p_pptr); LIST_REMOVE(child, p_sibling); LIST_INSERT_HEAD(&parent->p_children, child, p_sibling); + + LIST_FOREACH(p, &parent->p_orphans, p_orphan) { + if (p == child) { + LIST_REMOVE(child, p_orphan); + break; + } + } + if (child->p_flag & P_TRACED) { + LIST_INSERT_HEAD(&child->p_pptr->p_orphans, child, p_orphan); + PROC_UNLOCK(child); + PROC_LOCK(child); + } child->p_pptr = parent; } Index: sys/kern/kern_fork.c =================================================================== --- sys/kern/kern_fork.c (revision 230617) +++ sys/kern/kern_fork.c (working copy) @@ -590,6 +590,7 @@ LIST_INSERT_AFTER(p1, p2, p_pglist); PGRP_UNLOCK(p1->p_pgrp); LIST_INIT(&p2->p_children); + LIST_INIT(&p2->p_orphans); callout_init(&p2->p_itcallout, CALLOUT_MPSAFE); Index: sys/kern/sys_process.c =================================================================== --- sys/kern/sys_process.c (revision 230617) +++ sys/kern/sys_process.c (working copy) @@ -841,8 +841,6 @@ p->p_flag |= P_TRACED; p->p_oppid = p->p_pptr->p_pid; if (p->p_pptr != td->td_proc) { - /* Remember that a child is being debugged(traced). */ - p->p_pptr->p_dbg_child++; proc_reparent(p, td->td_proc); } data = SIGSTOP; @@ -931,7 +929,6 @@ PROC_UNLOCK(pp); PROC_LOCK(p); proc_reparent(p, pp); - p->p_pptr->p_dbg_child--; if (pp == initproc) p->p_sigparent = SIGCHLD; } Index: sys/kern/sys_procdesc.c =================================================================== --- sys/kern/sys_procdesc.c (revision 230617) +++ sys/kern/sys_procdesc.c (working copy) @@ -367,7 +367,7 @@ * procdesc_reap(). */ PROC_SLOCK(p); - proc_reap(curthread, p, NULL, 0, NULL); + proc_reap(curthread, p, NULL, 0, NULL, 0); } else { /* * If the process is not yet dead, we need to kill it, but we Index: sys/sys/proc.h =================================================================== --- sys/sys/proc.h (revision 230617) +++ sys/sys/proc.h (working copy) @@ -505,8 +505,6 @@ /* The following fields are all zeroed upon creation in fork. */ #define p_startzero p_oppid pid_t p_oppid; /* (c + e) Save ppid in ptrace. XXX */ - int p_dbg_child; /* (c + e) # of debugged children in - ptrace. */ struct vmspace *p_vmspace; /* (b) Address space. */ u_int p_swtick; /* (c) Tick when swapped in or out. */ struct itimerval p_realtimer; /* (c) Alarm timer. */ @@ -574,6 +572,8 @@ after fork. */ uint64_t p_prev_runtime; /* (c) Resource usage accounting. */ struct racct *p_racct; /* (b) Resource accounting. */ + LIST_ENTRY(proc) p_orphan; /* (e) List of orphan processes. */ + LIST_HEAD(, proc) p_orphans; /* (e) Pointer to list of orphans. */ }; #define p_session p_pgrp->pg_session @@ -865,7 +865,7 @@ void proc_linkup0(struct proc *p, struct thread *td); void proc_linkup(struct proc *p, struct thread *td); void proc_reap(struct thread *td, struct proc *p, int *status, int options, - struct rusage *rusage); + struct rusage *rusage, int child); void proc_reparent(struct proc *child, struct proc *newparent); struct pstats *pstats_alloc(void); void pstats_fork(struct pstats *src, struct pstats *dst); --------------050804080208020403030502 Content-Type: text/x-patch; name="vfork-fork.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vfork-fork.patch" Index: sys/kern/kern_fork.c =================================================================== --- sys/kern/kern_fork.c (revision 230617) +++ sys/kern/kern_fork.c (working copy) @@ -797,6 +797,10 @@ p1 = td->td_proc; + /* Don't do vfork while being traced. */ + if (p1->p_flag & P_TRACED) + flags &= ~(RFPPWAIT | RFMEM); + /* * Here we don't create a new process, but we divorce * certain parts of a process from itself. --------------050804080208020403030502-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 18:36:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44BB21065678; Fri, 27 Jan 2012 18:36:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D196C8FC20; Fri, 27 Jan 2012 18:36:03 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8850546B32; Fri, 27 Jan 2012 13:36:03 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E803B96F; Fri, 27 Jan 2012 13:36:03 -0500 (EST) From: John Baldwin To: Doug Barton Date: Fri, 27 Jan 2012 13:21:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> In-Reply-To: <4F0401D3.9040903@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201271321.39632.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jan 2012 13:36:03 -0500 (EST) Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:36:04 -0000 On Wednesday, January 04, 2012 2:37:55 am Doug Barton wrote: > On 01/03/2012 14:14, John Baldwin wrote: > > On Wednesday, August 03, 2011 3:55:17 am Doug Barton wrote: > >> On 08/02/2011 15:06, John Baldwin wrote: > >>> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: > >>>> on 19/07/2011 18:16 John Baldwin said the following: > >>>>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? > >>>>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. > >>>> > >>>> I believe that I've got a similar problem with amdsbwd(4). > >>>> It needs some resources (I/O ports) that belong to ACPI. > >>>> The problem is that the driver attaches to isa bus which is under > >>>> isab->pci->pcib and those particular resources are not assigned to the Host-PCI > >>>> bridge. > >>>> > >>>> I think that you already made a suggestion that perhaps isa bus should directly > >>>> attach to acpi bus when acpi is available. Not sure if there are any > >>>> alternative approaches. > >>> > >>> Can you try this: > >> > >> Not so much. :) the first and last patches I can apply to HEAD by hand, > >> but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not > >> even sure where to start. > >> > >> Any chance you could diff against HEAD? > > > > I believe this should be fixed (well, worked-around) by my most recent commit > > to sys/dev/acpica/acpi_pcib_acpi.c in HEAD. > > Funny you should ask. :) I saw that, and took a look. I'm getting the > following error, from a verbose dmesg: > > isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer > ichwd0: on isa0 > isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer > pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 > > That's different than the error message I got before, but watchdogd > still fails. I didn't have a chance to check the BIOS settings until > today, and there is no entry for anything even closely resembling this. > The only things I actually have disabled are the parallel port, and the > "Dell Trusted Platform Module," neither of which I can imagine would be > relevant. > > I'm happy to provide more info. Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 18:48:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9539E1065673 for ; Fri, 27 Jan 2012 18:48:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4738FC16 for ; Fri, 27 Jan 2012 18:48:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C6C1146B2D; Fri, 27 Jan 2012 13:48:36 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 543A0B979; Fri, 27 Jan 2012 13:48:36 -0500 (EST) From: John Baldwin To: aconnolly08@yahoo.co.jp Date: Fri, 27 Jan 2012 13:48:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <639642.41300.qm@web100410.mail.kks.yahoo.co.jp> In-Reply-To: <639642.41300.qm@web100410.mail.kks.yahoo.co.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201271348.35731.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jan 2012 13:48:36 -0500 (EST) Cc: "freebsd-current@freebsd.org" Subject: Re: atkbc not loaded with ACPI enabled in 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:48:37 -0000 On Saturday, January 21, 2012 12:11:54 am aconnolly08@yahoo.co.jp wrote: > > --- On Wed, 2012/1/18, John Baldwin wrote: > > On Friday, January 13, 2012 10:27:13 pm aconnolly08@yahoo.co.jp wrote: > > Please try this patch: > > > > Index: sys/dev/atkbdc/atkbdc_isa.c > > =================================================================== > > --- atkbdc_isa.c (revision 230009) > > +++ atkbdc_isa.c (working copy) > > @@ -87,6 +87,7 @@ static driver_t atkbdc_isa_driver = { > > > > static struct isa_pnp_id atkbdc_ids[] = { > > { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ > > + { 0x0320d041, "Keyboard controller (i8042)" }, /* PNP0320 */ > > { 0 } > > }; > > > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > > John, > > Thanks for your help, but that patch doesn't appear to address the problem. > I edited the atkbdc_isa.c file as you instructed, rebuilt and installed my > kernel, but my integrated keyboard remains unresponsive with ACPI enabled. > > Here's the new output of dmesg -a http://pastebin.com/h6ahmD2ddevinfo -ur > http://pastebin.com/sdNcNEJUdevinfo -vr http://pastebin.com/P2yqQBLY > > Perhaps I was supposed to remove PNP0303 support? > > No, the goal was to get atkbdc to try to attach to PNP0320 devices since those > have your keyboard I/O ports. Can you add some printfs to atkbdc_isa_probe() > to see how many times it is getting past the ID check, and how far along it > gets in each cases (i.e. which failure case causes the probe routine to return > an error)? > > -- > John Baldwin > > > John, > > I added some printfs to the isa_probe() function to see how far it was getting. The function is called many times as you can see in the dmesg, but mostly it exits at the PnP ID check with ENXIO. > > At one point it gets further, but still exits with ENXIO when port0 is found to be NULL. > > Any suggestions for further investigation? > > edited function http://pastebin.com/uUsVLiz2 > dmesg -a http://pastebin.com/kDtC9gvM Hmm, so this looks like it is only getting past the ID check once and is not probing the 0320 device at all. Please try this patch with some different debugging printfs and let me know what you get as output during boot: Index: atkbdc_isa.c =================================================================== --- atkbdc_isa.c (revision 230585) +++ atkbdc_isa.c (working copy) @@ -87,6 +87,7 @@ static driver_t atkbdc_isa_driver = { static struct isa_pnp_id atkbdc_ids[] = { { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ + { 0x0320d041, "Keyboard controller (i8042)" }, /* PNP0320 */ { 0 } }; @@ -111,6 +112,9 @@ atkbdc_isa_probe(device_t dev) return ENXIO; device_set_desc(dev, "Keyboard controller (i8042)"); + if (isa_get_logicalid(dev) != 0) + device_printf(dev, "has PNP ID %s\n", + pnp_eisaformat(isa_get_logicalid(dev))); /* * Adjust I/O port resources. @@ -125,17 +129,25 @@ atkbdc_isa_probe(device_t dev) */ device_quiet(dev); rid = 0; - if (bus_get_resource(dev, SYS_RES_IOPORT, rid, &start, &count) != 0) + if (bus_get_resource(dev, SYS_RES_IOPORT, rid, &start, &count) != 0) { + device_printf(dev, "no I/O port resources\n"); return ENXIO; + } + device_printf(dev, "initial I/O port 0 is %x-%x\n", start, + start + count - 1); if (start == IO_KBD + KBD_STATUS_PORT) { start = IO_KBD; count++; } - if (count > 1) /* adjust the count and/or start port */ + if (count > 1) /* adjust the count and/or start port */ { + device_printf(dev, "setting rid 0 to %x-%x\n", start, start); bus_set_resource(dev, SYS_RES_IOPORT, rid, start, 1); + } port0 = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &rid, RF_ACTIVE); - if (port0 == NULL) + if (port0 == NULL) { + device_printf(dev, "Failed to allocate I/O port rid 0\n"); return ENXIO; + } rid = 1; if (bus_get_resource(dev, SYS_RES_IOPORT, rid, NULL, NULL) != 0) bus_set_resource(dev, SYS_RES_IOPORT, 1, -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 19:14:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC5541065670; Fri, 27 Jan 2012 19:14:53 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id B1D5C8FC12; Fri, 27 Jan 2012 19:14:53 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 27 Jan 2012 11:14:56 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q0RJEt1k005546; Fri, 27 Jan 2012 11:14:55 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q0RJEt1C005544; Fri, 27 Jan 2012 11:14:55 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201201271914.q0RJEt1C005544@ambrisko.com> In-Reply-To: <201201271302.59011.jhb@freebsd.org> To: John Baldwin Date: Fri, 27 Jan 2012 11:14:55 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Kostik Belousov , freebsd-current@freebsd.org, Andrew Boyer Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:14:53 -0000 John Baldwin writes: | On Friday, January 27, 2012 12:52:18 pm Kostik Belousov wrote: | > On Fri, Jan 27, 2012 at 09:42:58AM -0800, Doug Ambrisko wrote: | > > Andrew Boyer writes: | > > | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: | > > | | > > | > John Baldwin writes: | > > | > | Agreed, I think the missing locking should just be added to the aio | code. | > > | > | > > | > Okay so then just: | > > | > | > > | > Index: vfs_aio.c | > > | > =================================================================== | > > | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v | > > | > retrieving revision 1.243.2.3.4.1 | > > | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c | > > | > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 | > > | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 | > > | > @@ -2509,9 +2509,12 @@ static void | > > | > filt_aiodetach(struct knote *kn) | > > | > { | > > | > struct aiocblist *aiocbe = kn->kn_ptr.p_aio; | > > | > + struct knlist *knl = &aiocbe->klist; | > > | > | > > | > - if (!knlist_empty(&aiocbe->klist)) | > > | > - knlist_remove(&aiocbe->klist, kn, 0); | > > | > + knl->kl_lock(knl->kl_lockarg); | > > | > + if (!knlist_empty(knl)) | > > | > + knlist_remove(knl, kn, 1); | > > | > + knl->kl_unlock(knl->kl_lockarg); | > > | > } | > > | > | > > | > /* kqueue filter function */ | > > | > | > > | > I was trying to be consistant with knlist_remove but this is a much | > > | > smaller change that can be merge to older branches. | > > | | > > | Does filt_liodetach() need the same treatment? | > > | > > Yes, I had that in the original. I updated that and optimized | > > the knl to just get the structure needed. | > > | > > Index: vfs_aio.c | > > =================================================================== | > > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v | > > retrieving revision 1.243.2.3.4.1 | > > diff -u -p -r1.243.2.3.4.1 vfs_aio.c | > > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 | > > +++ vfs_aio.c 27 Jan 2012 17:35:47 -0000 | > > @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn) | > > static void | > > filt_aiodetach(struct knote *kn) | > > { | > > - struct aiocblist *aiocbe = kn->kn_ptr.p_aio; | > > + struct knlist *knl = &kn->kn_ptr.p_aio->klist; | > > | > > - if (!knlist_empty(&aiocbe->klist)) | > > - knlist_remove(&aiocbe->klist, kn, 0); | > > + knl->kl_lock(knl->kl_lockarg); | > > + if (!knlist_empty(knl)) | > > + knlist_remove(knl, kn, 1); | > > + knl->kl_unlock(knl->kl_lockarg); | > > } | > > | > > /* kqueue filter function */ | > > @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn) | > > static void | > > filt_liodetach(struct knote *kn) | > > { | > > - struct aioliojob * lj = kn->kn_ptr.p_lio; | > > + struct knlist *knl = &kn->kn_ptr.p_lio->klist; | > It is easy to be style-compiant there and move initialization of knl | > after the blank line. | > | > Do you need two different functions now ? I think you can leave just one. | | Hmm, I think p_lio != p_aio, so two functions are required. Correct, even thought they are together in a union, the structures are different so klist would have a different offset for each function. | I think the patch looks fine. The style fix to not assign 'knl' in its | declaration would be nice to fix as you suggested, but that's minor. Here is the updated version that seems to work fine. Index: vfs_aio.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v retrieving revision 1.243.2.3.4.1 diff -u -p -r1.243.2.3.4.1 vfs_aio.c --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 +++ vfs_aio.c 27 Jan 2012 18:22:10 -0000 @@ -2508,10 +2508,13 @@ filt_aioattach(struct knote *kn) static void filt_aiodetach(struct knote *kn) { - struct aiocblist *aiocbe = kn->kn_ptr.p_aio; + struct knlist *knl; - if (!knlist_empty(&aiocbe->klist)) - knlist_remove(&aiocbe->klist, kn, 0); + knl = &kn->kn_ptr.p_aio->klist; + knl->kl_lock(knl->kl_lockarg); + if (!knlist_empty(knl)) + knlist_remove(knl, kn, 1); + knl->kl_unlock(knl->kl_lockarg); } /* kqueue filter function */ @@ -2553,10 +2556,13 @@ filt_lioattach(struct knote *kn) static void filt_liodetach(struct knote *kn) { - struct aioliojob * lj = kn->kn_ptr.p_lio; + struct knlist *knl; - if (!knlist_empty(&lj->klist)) - knlist_remove(&lj->klist, kn, 0); + knl = &kn->kn_ptr.p_lio->klist; + knl->kl_lock(knl->kl_lockarg); + if (!knlist_empty(knl)) + knlist_remove(knl, kn, 1); + knl->kl_unlock(knl->kl_lockarg); } /* kqueue filter function */ Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 19:56:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F12D106566C for ; Fri, 27 Jan 2012 19:56:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 381AA8FC14 for ; Fri, 27 Jan 2012 19:56:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C267A46B2D; Fri, 27 Jan 2012 14:56:54 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 32517B971; Fri, 27 Jan 2012 14:56:54 -0500 (EST) From: John Baldwin To: Doug Ambrisko Date: Fri, 27 Jan 2012 14:50:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201201271914.q0RJEt1C005544@ambrisko.com> In-Reply-To: <201201271914.q0RJEt1C005544@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201271450.33504.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jan 2012 14:56:54 -0500 (EST) Cc: Kostik Belousov , freebsd-current@freebsd.org, Andrew Boyer Subject: Re: knlist_empty locking fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:56:55 -0000 On Friday, January 27, 2012 2:14:55 pm Doug Ambrisko wrote: > John Baldwin writes: > | On Friday, January 27, 2012 12:52:18 pm Kostik Belousov wrote: > | > On Fri, Jan 27, 2012 at 09:42:58AM -0800, Doug Ambrisko wrote: > | > > Andrew Boyer writes: > | > > | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote: > | > > | > | > > | > John Baldwin writes: > | > > | > | Agreed, I think the missing locking should just be added to the aio > | code. > | > > | > > | > > | > Okay so then just: > | > > | > > | > > | > Index: vfs_aio.c > | > > | > =================================================================== > | > > | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > | > > | > retrieving revision 1.243.2.3.4.1 > | > > | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > | > > | > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > | > > | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -0000 > | > > | > @@ -2509,9 +2509,12 @@ static void > | > > | > filt_aiodetach(struct knote *kn) > | > > | > { > | > > | > struct aiocblist *aiocbe = kn->kn_ptr.p_aio; > | > > | > + struct knlist *knl = &aiocbe->klist; > | > > | > > | > > | > - if (!knlist_empty(&aiocbe->klist)) > | > > | > - knlist_remove(&aiocbe->klist, kn, 0); > | > > | > + knl->kl_lock(knl->kl_lockarg); > | > > | > + if (!knlist_empty(knl)) > | > > | > + knlist_remove(knl, kn, 1); > | > > | > + knl->kl_unlock(knl->kl_lockarg); > | > > | > } > | > > | > > | > > | > /* kqueue filter function */ > | > > | > > | > > | > I was trying to be consistant with knlist_remove but this is a much > | > > | > smaller change that can be merge to older branches. > | > > | > | > > | Does filt_liodetach() need the same treatment? > | > > > | > > Yes, I had that in the original. I updated that and optimized > | > > the knl to just get the structure needed. > | > > > | > > Index: vfs_aio.c > | > > =================================================================== > | > > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v > | > > retrieving revision 1.243.2.3.4.1 > | > > diff -u -p -r1.243.2.3.4.1 vfs_aio.c > | > > --- vfs_aio.c 21 Dec 2010 17:09:25 -0000 1.243.2.3.4.1 > | > > +++ vfs_aio.c 27 Jan 2012 17:35:47 -0000 > | > > @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn) > | > > static void > | > > filt_aiodetach(struct knote *kn) > | > > { > | > > - struct aiocblist *aiocbe = kn->kn_ptr.p_aio; > | > > + struct knlist *knl = &kn->kn_ptr.p_aio->klist; > | > > > | > > - if (!knlist_empty(&aiocbe->klist)) > | > > - knlist_remove(&aiocbe->klist, kn, 0); > | > > + knl->kl_lock(knl->kl_lockarg); > | > > + if (!knlist_empty(knl)) > | > > + knlist_remove(knl, kn, 1); > | > > + knl->kl_unlock(knl->kl_lockarg); > | > > } > | > > > | > > /* kqueue filter function */ > | > > @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn) > | > > static void > | > > filt_liodetach(struct knote *kn) > | > > { > | > > - struct aioliojob * lj = kn->kn_ptr.p_lio; > | > > + struct knlist *knl = &kn->kn_ptr.p_lio->klist; > | > It is easy to be style-compiant there and move initialization of knl > | > after the blank line. > | > > | > Do you need two different functions now ? I think you can leave just one. > | > | Hmm, I think p_lio != p_aio, so two functions are required. > > Correct, even thought they are together in a union, the structures are > different so klist would have a different offset for each function. > > | I think the patch looks fine. The style fix to not assign 'knl' in its > | declaration would be nice to fix as you suggested, but that's minor. > > Here is the updated version that seems to work fine. Looks good to me. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 20:36:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7970106564A for ; Fri, 27 Jan 2012 20:36:21 +0000 (UTC) (envelope-from mokomull@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9288FC0C for ; Fri, 27 Jan 2012 20:36:21 +0000 (UTC) Received: by werm13 with SMTP id m13so69751wer.13 for ; Fri, 27 Jan 2012 12:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7A1U/AMo+lLku2WWtf30OIMfH4iPDoETACT9FZXW9P0=; b=kBw9E3WQcRS6mOP/kXeYRsG/exASbSK5o4xUO5gUf6HhhGd9i4GO1lsndTuCpHZp/o 7rKhgaXo2RXS/G7Qwue/z4w1sVCTLISpFWyWHGpAqYP55ctvmmQsFsxsPNPMsEcwOVaE 2jTEoySV5SYVpD9/GgQDi46q9s8Zd/1fnspuE= MIME-Version: 1.0 Received: by 10.216.131.210 with SMTP id m60mr3438678wei.47.1327694808746; Fri, 27 Jan 2012 12:06:48 -0800 (PST) Received: by 10.223.106.141 with HTTP; Fri, 27 Jan 2012 12:06:48 -0800 (PST) In-Reply-To: <4F22D9FD.10502@p6m7g8.com> References: <4F22D9FD.10502@p6m7g8.com> Date: Fri, 27 Jan 2012 12:06:48 -0800 Message-ID: From: Matt Mullins To: "Philip M. Gollucci" Content-Type: text/plain; charset=ISO-8859-1 Cc: Daniel Shafaf , current@freebsd.org, Scott Sanders Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:36:21 -0000 On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci wrote: > All, > > $ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs > jid=17 name=17 > > # jubilee/chef > jail_jubilee_hostname="jubilee.dca1.rws" > jail_jubilee_ip="192.168.2.41" > jail_jubilee_ip_multi0="192.168.2.42" > jail_jubilee_interface="bge1" > jail_jubilee_rootdir="/jubilee" > jail_jubilee_devfs_enable="YES" The default flags that /etc/rc.d/jail passes to jail(8) are "-l -U root". Failing to give jail(8) a name results in name==jid, as you found above. You can make the rc script name the jail by setting: jail_jubilee_flags="-n jubilee -l -U root" Notice the rc script uses the second form of syntax listed in jail(8), at least on 9.0-RELEASE. -- Matt Mullins From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:20:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001A2106566C; Fri, 27 Jan 2012 21:20:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C12548FC0C; Fri, 27 Jan 2012 21:20:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLKMbM041502; Fri, 27 Jan 2012 16:20:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLKM3p041499; Fri, 27 Jan 2012 21:20:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:20:22 GMT Message-Id: <201201272120.q0RLKM3p041499@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:20:24 -0000 TB --- 2012-01-27 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-01-27 21:00:00 - cleaning the object tree TB --- 2012-01-27 21:00:19 - cvsupping the source tree TB --- 2012-01-27 21:00:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-01-27 21:00:53 - building world TB --- 2012-01-27 21:00:53 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:00:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:00:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:00:53 - SRCCONF=/dev/null TB --- 2012-01-27 21:00:53 - TARGET=arm TB --- 2012-01-27 21:00:53 - TARGET_ARCH=arm TB --- 2012-01-27 21:00:53 - TZ=UTC TB --- 2012-01-27 21:00:53 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:00:53 - cd /src TB --- 2012-01-27 21:00:53 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:00:54 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:20:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:20:22 - ERROR: failed to build world TB --- 2012-01-27 21:20:22 - 887.90 user 221.34 system 1221.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:27:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91E511065673; Fri, 27 Jan 2012 21:27:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABDB8FC12; Fri, 27 Jan 2012 21:27:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLRGsI009543; Fri, 27 Jan 2012 16:27:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLRGnt009538; Fri, 27 Jan 2012 21:27:16 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:27:16 GMT Message-Id: <201201272127.q0RLRGnt009538@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:27:17 -0000 TB --- 2012-01-27 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-27 21:00:00 - cleaning the object tree TB --- 2012-01-27 21:00:22 - cvsupping the source tree TB --- 2012-01-27 21:00:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-27 21:00:53 - building world TB --- 2012-01-27 21:00:53 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:00:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:00:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:00:53 - SRCCONF=/dev/null TB --- 2012-01-27 21:00:53 - TARGET=pc98 TB --- 2012-01-27 21:00:53 - TARGET_ARCH=i386 TB --- 2012-01-27 21:00:53 - TZ=UTC TB --- 2012-01-27 21:00:53 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:00:53 - cd /src TB --- 2012-01-27 21:00:53 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:00:54 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:27:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:27:16 - ERROR: failed to build world TB --- 2012-01-27 21:27:16 - 1223.76 user 248.48 system 1635.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:28:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1201065676; Fri, 27 Jan 2012 21:28:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BD3A48FC1F; Fri, 27 Jan 2012 21:28:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLSCl8012727; Fri, 27 Jan 2012 16:28:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLSCVX012718; Fri, 27 Jan 2012 21:28:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:28:12 GMT Message-Id: <201201272128.q0RLSCVX012718@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:28:13 -0000 TB --- 2012-01-27 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-01-27 21:00:00 - cleaning the object tree TB --- 2012-01-27 21:00:51 - cvsupping the source tree TB --- 2012-01-27 21:00:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-01-27 21:01:18 - building world TB --- 2012-01-27 21:01:18 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:01:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:01:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:01:18 - SRCCONF=/dev/null TB --- 2012-01-27 21:01:18 - TARGET=amd64 TB --- 2012-01-27 21:01:18 - TARGET_ARCH=amd64 TB --- 2012-01-27 21:01:18 - TZ=UTC TB --- 2012-01-27 21:01:18 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:01:18 - cd /src TB --- 2012-01-27 21:01:18 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:01:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:28:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:28:12 - ERROR: failed to build world TB --- 2012-01-27 21:28:12 - 1272.34 user 254.77 system 1691.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:32:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55003106564A; Fri, 27 Jan 2012 21:32:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 21E258FC08; Fri, 27 Jan 2012 21:32:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLWwpF064024; Fri, 27 Jan 2012 16:32:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLWwrM064005; Fri, 27 Jan 2012 21:32:58 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:32:58 GMT Message-Id: <201201272132.q0RLWwrM064005@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:32:59 -0000 TB --- 2012-01-27 21:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-27 21:00:00 - cleaning the object tree TB --- 2012-01-27 21:00:51 - cvsupping the source tree TB --- 2012-01-27 21:00:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-27 21:06:18 - building world TB --- 2012-01-27 21:06:18 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:06:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:06:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:06:18 - SRCCONF=/dev/null TB --- 2012-01-27 21:06:18 - TARGET=i386 TB --- 2012-01-27 21:06:18 - TARGET_ARCH=i386 TB --- 2012-01-27 21:06:18 - TZ=UTC TB --- 2012-01-27 21:06:18 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:06:18 - cd /src TB --- 2012-01-27 21:06:18 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:06:18 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:32:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:32:58 - ERROR: failed to build world TB --- 2012-01-27 21:32:58 - 1246.59 user 247.64 system 1977.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:46:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9938106566B; Fri, 27 Jan 2012 21:46:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6D78FC18; Fri, 27 Jan 2012 21:46:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLktQ1091019; Fri, 27 Jan 2012 16:46:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLktm2091012; Fri, 27 Jan 2012 21:46:55 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:46:55 GMT Message-Id: <201201272146.q0RLktm2091012@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:46:56 -0000 TB --- 2012-01-27 21:20:23 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:20:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-01-27 21:20:23 - cleaning the object tree TB --- 2012-01-27 21:20:31 - cvsupping the source tree TB --- 2012-01-27 21:20:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-01-27 21:20:51 - building world TB --- 2012-01-27 21:20:51 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:20:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:20:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:20:51 - SRCCONF=/dev/null TB --- 2012-01-27 21:20:51 - TARGET=ia64 TB --- 2012-01-27 21:20:51 - TARGET_ARCH=ia64 TB --- 2012-01-27 21:20:51 - TZ=UTC TB --- 2012-01-27 21:20:51 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:20:51 - cd /src TB --- 2012-01-27 21:20:51 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:20:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:46:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:46:55 - ERROR: failed to build world TB --- 2012-01-27 21:46:55 - 1236.87 user 248.94 system 1592.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:50:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E2A4106567C; Fri, 27 Jan 2012 21:50:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3987D8FC19; Fri, 27 Jan 2012 21:50:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLo7hS032031; Fri, 27 Jan 2012 16:50:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLo7fZ032022; Fri, 27 Jan 2012 21:50:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:50:07 GMT Message-Id: <201201272150.q0RLo7fZ032022@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:50:08 -0000 TB --- 2012-01-27 21:27:16 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:27:16 - starting HEAD tinderbox run for mips/mips TB --- 2012-01-27 21:27:16 - cleaning the object tree TB --- 2012-01-27 21:27:20 - cvsupping the source tree TB --- 2012-01-27 21:27:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-01-27 21:28:33 - building world TB --- 2012-01-27 21:28:33 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:28:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:28:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:28:33 - SRCCONF=/dev/null TB --- 2012-01-27 21:28:33 - TARGET=mips TB --- 2012-01-27 21:28:33 - TARGET_ARCH=mips TB --- 2012-01-27 21:28:33 - TZ=UTC TB --- 2012-01-27 21:28:33 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:28:33 - cd /src TB --- 2012-01-27 21:28:33 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:28:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:50:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:50:07 - ERROR: failed to build world TB --- 2012-01-27 21:50:07 - 966.90 user 221.14 system 1370.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:54:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 685D01065673; Fri, 27 Jan 2012 21:54:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE678FC19; Fri, 27 Jan 2012 21:54:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLsh3W061680; Fri, 27 Jan 2012 16:54:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLshDp061679; Fri, 27 Jan 2012 21:54:43 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:54:43 GMT Message-Id: <201201272154.q0RLshDp061679@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:54:44 -0000 TB --- 2012-01-27 21:28:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:28:12 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-01-27 21:28:12 - cleaning the object tree TB --- 2012-01-27 21:28:16 - cvsupping the source tree TB --- 2012-01-27 21:28:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-01-27 21:28:33 - building world TB --- 2012-01-27 21:28:33 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:28:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:28:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:28:33 - SRCCONF=/dev/null TB --- 2012-01-27 21:28:33 - TARGET=powerpc TB --- 2012-01-27 21:28:33 - TARGET_ARCH=powerpc TB --- 2012-01-27 21:28:33 - TZ=UTC TB --- 2012-01-27 21:28:33 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:28:33 - cd /src TB --- 2012-01-27 21:28:33 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:28:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:54:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:54:43 - ERROR: failed to build world TB --- 2012-01-27 21:54:43 - 1236.94 user 240.02 system 1591.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 21:59:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C892F1065670; Fri, 27 Jan 2012 21:59:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 94EFB8FC16; Fri, 27 Jan 2012 21:59:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RLx49E093090; Fri, 27 Jan 2012 16:59:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RLx434093085; Fri, 27 Jan 2012 21:59:04 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 21:59:04 GMT Message-Id: <201201272159.q0RLx434093085@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:59:05 -0000 TB --- 2012-01-27 21:32:58 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:32:58 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-27 21:32:58 - cleaning the object tree TB --- 2012-01-27 21:33:17 - cvsupping the source tree TB --- 2012-01-27 21:33:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-27 21:33:33 - building world TB --- 2012-01-27 21:33:33 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:33:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:33:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:33:33 - SRCCONF=/dev/null TB --- 2012-01-27 21:33:33 - TARGET=powerpc TB --- 2012-01-27 21:33:33 - TARGET_ARCH=powerpc64 TB --- 2012-01-27 21:33:33 - TZ=UTC TB --- 2012-01-27 21:33:33 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:33:33 - cd /src TB --- 2012-01-27 21:33:33 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:33:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 21:59:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 21:59:04 - ERROR: failed to build world TB --- 2012-01-27 21:59:04 - 1243.02 user 243.68 system 1566.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:07:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89EB4106564A; Fri, 27 Jan 2012 22:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 58B378FC08; Fri, 27 Jan 2012 22:07:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RM7512015940; Fri, 27 Jan 2012 17:07:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RM75Vl015939; Fri, 27 Jan 2012 22:07:05 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:07:05 GMT Message-Id: <201201272207.q0RM75Vl015939@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:07:06 -0000 TB --- 2012-01-27 21:46:55 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 21:46:55 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-01-27 21:46:55 - cleaning the object tree TB --- 2012-01-27 21:47:01 - cvsupping the source tree TB --- 2012-01-27 21:47:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-01-27 21:47:55 - building world TB --- 2012-01-27 21:47:55 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 21:47:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 21:47:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 21:47:55 - SRCCONF=/dev/null TB --- 2012-01-27 21:47:55 - TARGET=sparc64 TB --- 2012-01-27 21:47:55 - TARGET_ARCH=sparc64 TB --- 2012-01-27 21:47:55 - TZ=UTC TB --- 2012-01-27 21:47:55 - __MAKE_CONF=/dev/null TB --- 2012-01-27 21:47:55 - cd /src TB --- 2012-01-27 21:47:55 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 21:47:56 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/sparc64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:07:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:07:05 - ERROR: failed to build world TB --- 2012-01-27 22:07:05 - 969.16 user 184.64 system 1209.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:29:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEDF106566B; Fri, 27 Jan 2012 22:29:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 075F58FC0A; Fri, 27 Jan 2012 22:29:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMTcMw002834; Fri, 27 Jan 2012 17:29:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMTcbM002828; Fri, 27 Jan 2012 22:29:38 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:29:38 GMT Message-Id: <201201272229.q0RMTcbM002828@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:29:39 -0000 TB --- 2012-01-27 22:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-01-27 22:10:01 - cleaning the object tree TB --- 2012-01-27 22:10:04 - cvsupping the source tree TB --- 2012-01-27 22:10:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-01-27 22:10:29 - building world TB --- 2012-01-27 22:10:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:10:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:10:29 - SRCCONF=/dev/null TB --- 2012-01-27 22:10:29 - TARGET=arm TB --- 2012-01-27 22:10:29 - TARGET_ARCH=arm TB --- 2012-01-27 22:10:29 - TZ=UTC TB --- 2012-01-27 22:10:29 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:10:29 - cd /src TB --- 2012-01-27 22:10:29 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:10:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign -! Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:29:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:29:38 - ERROR: failed to build world TB --- 2012-01-27 22:29:38 - 885.19 user 219.27 system 1177.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:36:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 403491065787; Fri, 27 Jan 2012 22:36:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 086488FC1D; Fri, 27 Jan 2012 22:36:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMaQjM070891; Fri, 27 Jan 2012 17:36:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMaQs5070886; Fri, 27 Jan 2012 22:36:26 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:36:26 GMT Message-Id: <201201272236.q0RMaQs5070886@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:36:27 -0000 TB --- 2012-01-27 22:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:10:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-27 22:10:01 - cleaning the object tree TB --- 2012-01-27 22:10:04 - cvsupping the source tree TB --- 2012-01-27 22:10:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-27 22:10:29 - building world TB --- 2012-01-27 22:10:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:10:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:10:29 - SRCCONF=/dev/null TB --- 2012-01-27 22:10:29 - TARGET=i386 TB --- 2012-01-27 22:10:29 - TARGET_ARCH=i386 TB --- 2012-01-27 22:10:29 - TZ=UTC TB --- 2012-01-27 22:10:29 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:10:29 - cd /src TB --- 2012-01-27 22:10:29 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:10:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:36:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:36:26 - ERROR: failed to build world TB --- 2012-01-27 22:36:26 - 1223.08 user 242.30 system 1585.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:37:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337131065678; Fri, 27 Jan 2012 22:37:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 02BD98FC17; Fri, 27 Jan 2012 22:37:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMbN0u074802; Fri, 27 Jan 2012 17:37:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMbNVH074798; Fri, 27 Jan 2012 22:37:23 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:37:23 GMT Message-Id: <201201272237.q0RMbNVH074798@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:37:24 -0000 TB --- 2012-01-27 22:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:10:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-01-27 22:10:01 - cleaning the object tree TB --- 2012-01-27 22:10:04 - cvsupping the source tree TB --- 2012-01-27 22:10:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-01-27 22:10:29 - building world TB --- 2012-01-27 22:10:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:10:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:10:29 - SRCCONF=/dev/null TB --- 2012-01-27 22:10:29 - TARGET=amd64 TB --- 2012-01-27 22:10:29 - TARGET_ARCH=amd64 TB --- 2012-01-27 22:10:29 - TZ=UTC TB --- 2012-01-27 22:10:29 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:10:29 - cd /src TB --- 2012-01-27 22:10:29 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:10:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/amd64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protecto! r -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:37:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:37:23 - ERROR: failed to build world TB --- 2012-01-27 22:37:23 - 1272.13 user 246.11 system 1642.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:42:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FD541065673; Fri, 27 Jan 2012 22:42:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 293CA8FC17; Fri, 27 Jan 2012 22:42:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMgaiL030631; Fri, 27 Jan 2012 17:42:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMgaYT030608; Fri, 27 Jan 2012 22:42:36 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:42:36 GMT Message-Id: <201201272242.q0RMgaYT030608@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:42:37 -0000 TB --- 2012-01-27 22:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:10:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-27 22:10:01 - cleaning the object tree TB --- 2012-01-27 22:10:04 - cvsupping the source tree TB --- 2012-01-27 22:10:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-27 22:15:43 - building world TB --- 2012-01-27 22:15:43 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:15:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:15:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:15:43 - SRCCONF=/dev/null TB --- 2012-01-27 22:15:43 - TARGET=pc98 TB --- 2012-01-27 22:15:43 - TARGET_ARCH=i386 TB --- 2012-01-27 22:15:43 - TZ=UTC TB --- 2012-01-27 22:15:43 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:15:43 - cd /src TB --- 2012-01-27 22:15:43 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:15:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/i386/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protector! -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:42:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:42:36 - ERROR: failed to build world TB --- 2012-01-27 22:42:36 - 1253.00 user 248.24 system 1955.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:56:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51FF2106564A; Fri, 27 Jan 2012 22:56:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCB48FC08; Fri, 27 Jan 2012 22:56:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMu91S056314; Fri, 27 Jan 2012 17:56:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMu9nC056304; Fri, 27 Jan 2012 22:56:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:56:09 GMT Message-Id: <201201272256.q0RMu9nC056304@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:56:10 -0000 TB --- 2012-01-27 22:29:38 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:29:38 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-01-27 22:29:38 - cleaning the object tree TB --- 2012-01-27 22:29:40 - cvsupping the source tree TB --- 2012-01-27 22:29:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-01-27 22:29:51 - building world TB --- 2012-01-27 22:29:51 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:29:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:29:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:29:51 - SRCCONF=/dev/null TB --- 2012-01-27 22:29:51 - TARGET=ia64 TB --- 2012-01-27 22:29:51 - TARGET_ARCH=ia64 TB --- 2012-01-27 22:29:51 - TZ=UTC TB --- 2012-01-27 22:29:51 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:29:51 - cd /src TB --- 2012-01-27 22:29:51 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:29:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/ia64/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-sign! -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:56:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:56:09 - ERROR: failed to build world TB --- 2012-01-27 22:56:09 - 1233.66 user 247.46 system 1590.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 22:57:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D1D1065670; Fri, 27 Jan 2012 22:57:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EA12C8FC12; Fri, 27 Jan 2012 22:57:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RMvqTa080378; Fri, 27 Jan 2012 17:57:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RMvqps079006; Fri, 27 Jan 2012 22:57:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 22:57:52 GMT Message-Id: <201201272257.q0RMvqps079006@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:57:53 -0000 TB --- 2012-01-27 22:36:26 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:36:26 - starting HEAD tinderbox run for mips/mips TB --- 2012-01-27 22:36:26 - cleaning the object tree TB --- 2012-01-27 22:36:28 - cvsupping the source tree TB --- 2012-01-27 22:36:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-01-27 22:36:39 - building world TB --- 2012-01-27 22:36:39 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:36:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:36:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:36:39 - SRCCONF=/dev/null TB --- 2012-01-27 22:36:39 - TARGET=mips TB --- 2012-01-27 22:36:39 - TARGET_ARCH=mips TB --- 2012-01-27 22:36:39 - TZ=UTC TB --- 2012-01-27 22:36:39 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:36:39 - cd /src TB --- 2012-01-27 22:36:39 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:36:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O -pipe -G0 -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/mips/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -Wno-pointer-s! ign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 22:57:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 22:57:47 - ERROR: failed to build world TB --- 2012-01-27 22:57:47 - 955.12 user 217.59 system 1280.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 23:03:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40DC11065675; Fri, 27 Jan 2012 23:03:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D6D418FC19; Fri, 27 Jan 2012 23:03:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RN3Gra023220; Fri, 27 Jan 2012 18:03:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RN3Gc6023219; Fri, 27 Jan 2012 23:03:16 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 23:03:16 GMT Message-Id: <201201272303.q0RN3Gc6023219@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:03:17 -0000 TB --- 2012-01-27 22:37:23 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:37:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-01-27 22:37:23 - cleaning the object tree TB --- 2012-01-27 22:37:25 - cvsupping the source tree TB --- 2012-01-27 22:37:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-01-27 22:37:36 - building world TB --- 2012-01-27 22:37:36 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:37:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:37:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:37:36 - SRCCONF=/dev/null TB --- 2012-01-27 22:37:36 - TARGET=powerpc TB --- 2012-01-27 22:37:36 - TARGET_ARCH=powerpc TB --- 2012-01-27 22:37:36 - TZ=UTC TB --- 2012-01-27 22:37:36 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:37:36 - cd /src TB --- 2012-01-27 22:37:36 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:37:37 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 23:03:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 23:03:16 - ERROR: failed to build world TB --- 2012-01-27 23:03:16 - 1220.57 user 230.05 system 1552.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 23:07:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3C24106566B; Fri, 27 Jan 2012 23:07:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4748E8FC0A; Fri, 27 Jan 2012 23:07:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0RN7ur1058856; Fri, 27 Jan 2012 18:07:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0RN7uKq058854; Fri, 27 Jan 2012 23:07:56 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Jan 2012 23:07:56 GMT Message-Id: <201201272307.q0RN7uKq058854@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:07:57 -0000 TB --- 2012-01-27 22:42:36 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:42:36 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-27 22:42:36 - cleaning the object tree TB --- 2012-01-27 22:42:38 - cvsupping the source tree TB --- 2012-01-27 22:42:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-27 22:42:50 - building world TB --- 2012-01-27 22:42:50 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:42:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:42:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:42:50 - SRCCONF=/dev/null TB --- 2012-01-27 22:42:50 - TARGET=powerpc TB --- 2012-01-27 22:42:50 - TARGET_ARCH=powerpc64 TB --- 2012-01-27 22:42:50 - TZ=UTC TB --- 2012-01-27 22:42:50 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:42:50 - cd /src TB --- 2012-01-27 22:42:50 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:42:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c -o zfs_sa.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c -o zfs_znode.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c -o zil.o cc -O2 -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../compat/opensolaris/include -I/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../lib/libumem -I/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -DNEED_SOLARIS_BOOLEAN -std=iso9899:1999 -fstack-protec! tor -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -o zio.o /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In function 'zio_data_buf_alloc': /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: 'KM_NODEBUG' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:245: error: for each function it appears in.) *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-27 23:07:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-27 23:07:56 - ERROR: failed to build world TB --- 2012-01-27 23:07:56 - 1216.78 user 230.18 system 1520.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 00:03:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F72106564A; Sat, 28 Jan 2012 00:03:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 229E18FC12; Sat, 28 Jan 2012 00:03:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q0S03VPM083799; Fri, 27 Jan 2012 19:03:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q0S03VEj083798; Sat, 28 Jan 2012 00:03:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Jan 2012 00:03:31 GMT Message-Id: <201201280003.q0S03VEj083798@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:03:32 -0000 TB --- 2012-01-27 22:56:09 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-27 22:56:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-01-27 22:56:09 - cleaning the object tree TB --- 2012-01-27 22:56:11 - cvsupping the source tree TB --- 2012-01-27 22:56:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-01-27 22:56:26 - building world TB --- 2012-01-27 22:56:26 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 22:56:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 22:56:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 22:56:26 - SRCCONF=/dev/null TB --- 2012-01-27 22:56:26 - TARGET=sparc64 TB --- 2012-01-27 22:56:26 - TARGET_ARCH=sparc64 TB --- 2012-01-27 22:56:26 - TZ=UTC TB --- 2012-01-27 22:56:26 - __MAKE_CONF=/dev/null TB --- 2012-01-27 22:56:26 - cd /src TB --- 2012-01-27 22:56:26 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 27 22:56:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 27 23:50:07 UTC 2012 TB --- 2012-01-27 23:50:07 - generating LINT kernel config TB --- 2012-01-27 23:50:07 - cd /src/sys/sparc64/conf TB --- 2012-01-27 23:50:07 - /usr/bin/make -B LINT TB --- 2012-01-27 23:50:08 - cd /src/sys/sparc64/conf TB --- 2012-01-27 23:50:08 - /usr/sbin/config -m LINT TB --- 2012-01-27 23:50:08 - building LINT kernel TB --- 2012-01-27 23:50:08 - CROSS_BUILD_TESTING=YES TB --- 2012-01-27 23:50:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-27 23:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-27 23:50:08 - SRCCONF=/dev/null TB --- 2012-01-27 23:50:08 - TARGET=sparc64 TB --- 2012-01-27 23:50:08 - TARGET_ARCH=sparc64 TB --- 2012-01-27 23:50:08 - TZ=UTC TB --- 2012-01-27 23:50:08 - __MAKE_CONF=/dev/null TB --- 2012-01-27 23:50:08 - cd /src TB --- 2012-01-27 23:50:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 27 23:50:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/iommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/jbusppm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/sparc64/sparc64/machdep.c cc1: warnings being treated as errors /src/sys/sparc64/sparc64/machdep.c: In function 'cpu_halt': /src/sys/sparc64/sparc64/machdep.c:930: warning: 'noreturn' function does return *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-28 00:03:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-28 00:03:31 - ERROR: failed to build LINT kernel TB --- 2012-01-28 00:03:31 - 3574.41 user 505.73 system 4041.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 02:58:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F174106566C; Sat, 28 Jan 2012 02:58:36 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07D3B8FC12; Sat, 28 Jan 2012 02:58:35 +0000 (UTC) Received: by qcse14 with SMTP id e14so1771276qcs.13 for ; Fri, 27 Jan 2012 18:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lr4DeR1i6i0okWBjUaqG4IMBC3Lgk7hJuy91C3WgOk0=; b=Jv85IaN2z0bPCtfS94dCLi1OkbdrP54d2BW4662IcB6IYo81RRtEskPalQH0g3ypVq EytY63EARPxFUpJNL6v7lW379syknwjKKwl91/06xcXkgpkOW5nXE8aumnkJmDzWYRHu /4bmRNX1qfC2TFWSDoS4dFHQcNBaIAEHlnYgo= MIME-Version: 1.0 Received: by 10.224.218.4 with SMTP id ho4mr11746087qab.77.1327719515224; Fri, 27 Jan 2012 18:58:35 -0800 (PST) Received: by 10.229.222.206 with HTTP; Fri, 27 Jan 2012 18:58:35 -0800 (PST) In-Reply-To: <4F1FF2AD.9020003@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <20120112121853.GC1429@procyon.xvoid.org> <4F0ED8D0.8080403@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> <4F1FF2AD.9020003@FreeBSD.org> Date: Sat, 28 Jan 2012 03:58:35 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 02:58:36 -0000 2012/1/25 Alexander Motin > > Commenting it appeared not good, as at least mplayer doesn't sets channels > for AC3. That makes sound(4) use default 1 channel for AC3, that is > definitely not supported. I believe this should be better: > http://svn.freebsd.org/**changeset/base/230537 > > Also, as soon as sound(4) interprets 8 channel as 7.1 by default, I've > changed previous patch a bit to allow both "8.0" and "7.1" AC3 formats: > http://svn.freebsd.org/**changeset/base/230513 > > thank, i can set 8 channels without vchan now. > For me this at least doesn't break normal AC3 operation and when I hacked > mplayer to set 8 channels, I can see predictable codec configuration and > time in mplayer predictably running 4 times faster. Unluckily mplayer seems > doesn't support TrueHD passthrough to ckeck closer -- it always does > decoding. > > ok i think i found the problem: in http://svn.freebsd.org/changeset/base/230511 cchn is equal to 7 for me if i set SNDCTL_DSP_CHANNELS to 8. and it's why HBR bit is not set. it's confirmed in my /v/l/messages where chan_count=0x7: Jan 28 03:23:53 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02800400 (7.1) speed=192000 Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 09:13:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A618F106566C; Sat, 28 Jan 2012 09:13:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5C94B14F191; Sat, 28 Jan 2012 09:13:15 +0000 (UTC) Message-ID: <4F23BC2B.8070801@FreeBSD.org> Date: Sat, 28 Jan 2012 01:13:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> <201201271321.39632.jhb@freebsd.org> In-Reply-To: <201201271321.39632.jhb@freebsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:13:15 -0000 On 01/27/2012 10:21, John Baldwin wrote: > On Wednesday, January 04, 2012 2:37:55 am Doug Barton wrote: >> On 01/03/2012 14:14, John Baldwin wrote: >>> On Wednesday, August 03, 2011 3:55:17 am Doug Barton wrote: >>>> On 08/02/2011 15:06, John Baldwin wrote: >>>>> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >>>>>> on 19/07/2011 18:16 John Baldwin said the following: >>>>>>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? >>>>>>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. >>>>>> >>>>>> I believe that I've got a similar problem with amdsbwd(4). >>>>>> It needs some resources (I/O ports) that belong to ACPI. >>>>>> The problem is that the driver attaches to isa bus which is under >>>>>> isab->pci->pcib and those particular resources are not assigned to the Host-PCI >>>>>> bridge. >>>>>> >>>>>> I think that you already made a suggestion that perhaps isa bus should directly >>>>>> attach to acpi bus when acpi is available. Not sure if there are any >>>>>> alternative approaches. >>>>> >>>>> Can you try this: >>>> >>>> Not so much. :) the first and last patches I can apply to HEAD by hand, >>>> but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not >>>> even sure where to start. >>>> >>>> Any chance you could diff against HEAD? >>> >>> I believe this should be fixed (well, worked-around) by my most recent commit >>> to sys/dev/acpica/acpi_pcib_acpi.c in HEAD. >> >> Funny you should ask. :) I saw that, and took a look. I'm getting the >> following error, from a verbose dmesg: >> >> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >> ichwd0: on isa0 >> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >> pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 >> pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 >> ichwd0: ICH WDT present but disabled in BIOS or hardware >> device_attach: ichwd0 attach returned 6 >> >> That's different than the error message I got before, but watchdogd >> still fails. I didn't have a chance to check the BIOS settings until >> today, and there is no entry for anything even closely resembling this. >> The only things I actually have disabled are the parallel port, and the >> "Dell Trusted Platform Module," neither of which I can imagine would be >> relevant. >> >> I'm happy to provide more info. > > Does it operate fully with NEW_PCIB disabled entirely, or do you get this > same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 09:21:51 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF54106564A; Sat, 28 Jan 2012 09:21:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2815A8FC15; Sat, 28 Jan 2012 09:21:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA22947; Sat, 28 Jan 2012 11:21:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rr4Tj-000GpV-IN; Sat, 28 Jan 2012 11:21:47 +0200 Message-ID: <4F23BE29.7040102@FreeBSD.org> Date: Sat, 28 Jan 2012 11:21:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> <201201271321.39632.jhb@freebsd.org> <4F23BC2B.8070801@FreeBSD.org> In-Reply-To: <4F23BC2B.8070801@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:21:51 -0000 on 28/01/2012 11:13 Doug Barton said the following: > On 01/27/2012 10:21, John Baldwin wrote: >> Does it operate fully with NEW_PCIB disabled entirely, or do you get this >> same message in that case? > > I put nooptions NEW_PCIB in my kernel config, and got basically the same: > > isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer > ichwd0: on isa0 > isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 The next logical question is has ichwd ever worked on this system? With any version of FreeBSD. And, perhaps, if there is any watchdog-related knob in the BIOS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 09:26:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47298106566B; Sat, 28 Jan 2012 09:26:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 907968FC08; Sat, 28 Jan 2012 09:26:18 +0000 (UTC) Received: by eekb47 with SMTP id b47so947443eek.13 for ; Sat, 28 Jan 2012 01:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gpygIsMT1f1/cqooz74kHWcteU7Q20JdT0LMy3RLWF8=; b=lnYZVhdIkgxLRfRn1AIsF+zLeOUqVaAjT1yBhXGyZmRZULvRytT8Z0xWyuW64SPF+U NxPKmzUsZgVDT/+fbgZEjzO5jFBA2Wxns6vZ8kUg7KHAlyJoJQ5sPfGNM42abplmcfXG EB4e4GQKAyigwf1JIGVuPQDYJlDB3B3NVd8VQ= Received: by 10.213.25.139 with SMTP id z11mr1646563ebb.80.1327742776757; Sat, 28 Jan 2012 01:26:16 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n17sm41017499eei.3.2012.01.28.01.26.14 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 01:26:14 -0800 (PST) Sender: Alexander Motin Message-ID: <4F23BF2B.9050100@FreeBSD.org> Date: Sat, 28 Jan 2012 11:26:03 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlja2HDq2wgTWFpbGxvdA==?= References: <4F0DE3FD.2020203@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> <4F1FF2AD.9020003@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:26:19 -0000 On 28.01.2012 04:58, Mickaël Maillot wrote: > 2012/1/25 Alexander Motin > > > > Commenting it appeared not good, as at least mplayer doesn't sets > channels for AC3. That makes sound(4) use default 1 channel for AC3, > that is definitely not supported. I believe this should be better: > http://svn.freebsd.org/__changeset/base/230537 > > > Also, as soon as sound(4) interprets 8 channel as 7.1 by default, > I've changed previous patch a bit to allow both "8.0" and "7.1" AC3 > formats: > http://svn.freebsd.org/__changeset/base/230513 > > > > thank, i can set 8 channels without vchan now. > > For me this at least doesn't break normal AC3 operation and when I > hacked mplayer to set 8 channels, I can see predictable codec > configuration and time in mplayer predictably running 4 times > faster. Unluckily mplayer seems doesn't support TrueHD passthrough > to ckeck closer -- it always does decoding. > > > ok i think i found the problem: in > http://svn.freebsd.org/changeset/base/230511 > cchn is equal to 7 for me if i set SNDCTL_DSP_CHANNELS to 8. > and it's why HBR bit is not set. > > it's confirmed in my /v/l/messages where chan_count=0x7: > Jan 28 03:23:53 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used > Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup > fmt=02800400 (7.1) speed=192000 > Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: > fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 You are right. Fixed: http://svn.freebsd.org/changeset/base/230641 Thank you! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 09:37:35 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 557CB106566C; Sat, 28 Jan 2012 09:37:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7B7C81A7485; Sat, 28 Jan 2012 09:37:34 +0000 (UTC) Message-ID: <4F23C1DE.2010700@FreeBSD.org> Date: Sat, 28 Jan 2012 01:37:34 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> <201201271321.39632.jhb@freebsd.org> <4F23BC2B.8070801@FreeBSD.org> <4F23BE29.7040102@FreeBSD.org> In-Reply-To: <4F23BE29.7040102@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:37:35 -0000 On 01/28/2012 01:21, Andriy Gapon wrote: > on 28/01/2012 11:13 Doug Barton said the following: >> On 01/27/2012 10:21, John Baldwin wrote: >>> Does it operate fully with NEW_PCIB disabled entirely, or do you get this >>> same message in that case? >> >> I put nooptions NEW_PCIB in my kernel config, and got basically the same: >> >> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >> ichwd0: on isa0 >> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >> ichwd0: ICH WDT present but disabled in BIOS or hardware >> device_attach: ichwd0 attach returned 6 > > The next logical question is has ichwd ever worked on this system? With any > version of FreeBSD. I have a vague recollection that it did, but I just tried 8.1-RELEASE on the same system and got the same message about it being disabled. OTOH, on my laptop I know that it used to work, and then it didn't. > And, perhaps, if there is any watchdog-related knob in the BIOS. That was answered in the part of the message that you snipped. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 09:41:22 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6FF1065670; Sat, 28 Jan 2012 09:41:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 148758FC0A; Sat, 28 Jan 2012 09:41:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA23105; Sat, 28 Jan 2012 11:41:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rr4md-000Gq1-57; Sat, 28 Jan 2012 11:41:19 +0200 Message-ID: <4F23C2BE.7080600@FreeBSD.org> Date: Sat, 28 Jan 2012 11:41:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4E23EE49.5040801@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> <4F0401D3.9040903@FreeBSD.org> <201201271321.39632.jhb@freebsd.org> <4F23BC2B.8070801@FreeBSD.org> <4F23BE29.7040102@FreeBSD.org> <4F23C1DE.2010700@FreeBSD.org> In-Reply-To: <4F23C1DE.2010700@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:41:22 -0000 on 28/01/2012 11:37 Doug Barton said the following: > On 01/28/2012 01:21, Andriy Gapon wrote: >> on 28/01/2012 11:13 Doug Barton said the following: >>> On 01/27/2012 10:21, John Baldwin wrote: >>>> Does it operate fully with NEW_PCIB disabled entirely, or do you get this >>>> same message in that case? >>> >>> I put nooptions NEW_PCIB in my kernel config, and got basically the same: >>> >>> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >>> ichwd0: on isa0 >>> isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer >>> ichwd0: ICH WDT present but disabled in BIOS or hardware >>> device_attach: ichwd0 attach returned 6 >> >> The next logical question is has ichwd ever worked on this system? With any >> version of FreeBSD. > > I have a vague recollection that it did, but I just tried 8.1-RELEASE on > the same system and got the same message about it being disabled. Then I'd guess that it has never actually worked (with FreeBSD). > OTOH, > on my laptop I know that it used to work, and then it didn't. But that's a different system and, as such, a different problem? Have you fixed it or debugged it in a similar fashion to this !laptop system? >> And, perhaps, if there is any watchdog-related knob in the BIOS. > > That was answered in the part of the message that you snipped. Oops. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 10:02:58 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE4FD1065670; Sat, 28 Jan 2012 10:02:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A8AB78FC0C; Sat, 28 Jan 2012 10:02:57 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23293; Sat, 28 Jan 2012 12:02:56 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rr57Y-000Gqa-1D; Sat, 28 Jan 2012 12:02:56 +0200 Message-ID: <4F23C7CE.3050504@FreeBSD.org> Date: Sat, 28 Jan 2012 12:02:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: current@FreeBSD.org References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <4F1ACD97.5080506@FreeBSD.org> <4F1AF55F.4090803@FreeBSD.org> <20120123130453.GH16676@glebius.int.ru> <4F1D67CA.8010809@FreeBSD.org> In-Reply-To: <4F1D67CA.8010809@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: locks under printf(9) and WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 10:02:58 -0000 BTW, I see another LOR with spinlocks, maybe harmless. o sysbeep() is called from syscons code and it calls timeout() which introduces the following order: scrlock -> callout. o The callout code programming of event timers introduces the following order (via callout_new_inserted == cpu_new_callout): callout -> et_hw_mtx o Eventtimers' doconfigtimer calls loadtimer with et_hw_mtx held, loadtimer calls et_start method of a configured event timer and, e.g. in the case of lapic_et_start and bootverbose it calls printf(9), which gives: et_hw_mtx -> scrlock This is just for the information. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 11:39:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9B96106564A; Sat, 28 Jan 2012 11:39:09 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1D38FC0A; Sat, 28 Jan 2012 11:39:08 +0000 (UTC) Received: by qcse14 with SMTP id e14so1964513qcs.13 for ; Sat, 28 Jan 2012 03:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rcazzc4iaY4/700YxglS5sNP0+pSFBL8jzmWHxbeZUQ=; b=NxS/TEUhIDrPO7hoQoUzcqKrGFjp6wAAxbxT7IAAMzU+aYV1NdwOhvihy/2BRuyoTH U83/TOzmriiYVHRsTayJWCNdbymgIxYiT/MKBsSa54/g6KN/2OgadIDx9ybhLeyWt8+O Hpq2b9ik8BiHNPC3awEeC45MLGFuX9w/CxT74= MIME-Version: 1.0 Received: by 10.229.135.135 with SMTP id n7mr3962888qct.31.1327750748031; Sat, 28 Jan 2012 03:39:08 -0800 (PST) Received: by 10.229.222.206 with HTTP; Sat, 28 Jan 2012 03:39:07 -0800 (PST) In-Reply-To: <4F23BF2B.9050100@FreeBSD.org> References: <4F0DE3FD.2020203@FreeBSD.org> <4F171D7A.4080003@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> <4F1FF2AD.9020003@FreeBSD.org> <4F23BF2B.9050100@FreeBSD.org> Date: Sat, 28 Jan 2012 12:39:07 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 11:39:09 -0000 2012/1/28 Alexander Motin > > You are right. Fixed: http://svn.freebsd.org/**changeset/base/230641 > > Thank you! > > -- > Alexander Motin > And i can play DTS-HDMA en Dolby TrueHD ! thanks for all your work :) From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 11:45:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E928E106564A; Sat, 28 Jan 2012 11:45:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1C18FC17; Sat, 28 Jan 2012 11:45:20 +0000 (UTC) Received: by eaaa14 with SMTP id a14so976164eaa.13 for ; Sat, 28 Jan 2012 03:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U0+eKPSSjHuvUq0QhyRvIQrwpByGNGTEV9kvBKI+BkA=; b=dRJqCixT4BeGdONssRuYyU4TLh4Y5vhjIiuyYOM9oP936wZpAz2LxfwpWFsY7q01Gc T1Rt6iucj52ERkxYJNdVp0vTUAmMwIT23XPkNeydYVQH6ZPhReSwEDPjyvkSF9GMza1v aP75gvvoBG3s3QmRBe3YM0QD2OS3aNVgD04yM= Received: by 10.213.25.73 with SMTP id y9mr1188968ebb.34.1327751120275; Sat, 28 Jan 2012 03:45:20 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t11sm15576953eea.10.2012.01.28.03.45.18 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 03:45:19 -0800 (PST) Sender: Alexander Motin Message-ID: <4F23DFC3.7040809@FreeBSD.org> Date: Sat, 28 Jan 2012 13:45:07 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlja2HDq2wgTWFpbGxvdA==?= References: <4F0DE3FD.2020203@FreeBSD.org> <4F177979.5010106@FreeBSD.org> <4F1ACBA8.6000203@FreeBSD.org> <4F1EB305.9000105@FreeBSD.org> <4F1EDD3D.6070800@FreeBSD.org> <4F1F31CA.5000507@FreeBSD.org> <4F1F34DB.9040405@FreeBSD.org> <4F1F412D.5040009@FreeBSD.org> <4F1FF2AD.9020003@FreeBSD.org> <4F23BF2B.9050100@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-multimedia@freebsd.org, FreeBSD current Subject: Re: [RFT] Major snd_hda rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 11:45:22 -0000 On 28.01.2012 13:39, Mickaël Maillot wrote: > 2012/1/28 Alexander Motin > > You are right. Fixed: http://svn.freebsd.org/__changeset/base/230641 > > > And i can play DTS-HDMA en Dolby TrueHD ! thanks for all your work :) Hooray! We did it! :) Thank you very much for testing it! -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 11:54:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E934106566C for ; Sat, 28 Jan 2012 11:54:02 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id A6B828FC0A for ; Sat, 28 Jan 2012 11:54:01 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id q0SBreml018303; Sat, 28 Jan 2012 20:53:40 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id q0SBrda21533; Sat, 28 Jan 2012 20:53:39 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi15) id q0SBrdTI016542; Sat, 28 Jan 2012 20:53:39 +0900 Received: from localhost by lomi15.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id q0SBrduU016530; Sat, 28 Jan 2012 20:53:39 +0900 Date: Sat, 28 Jan 2012 20:53:39 +0900 (JST) Message-Id: <20120128.205339.1305564732068259146.okuno.kohji@jp.panasonic.com> To: hselasky@c2i.net From: Kohji Okuno In-Reply-To: <20120124.095329.1799630236416551619.okuno.kohji@jp.panasonic.com> References: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> <201201231829.19576.hselasky@c2i.net> <20120124.095329.1799630236416551619.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com Subject: Re: Is UPS_PORT_POWER wrong? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 11:54:02 -0000 Hi HPS, Do you have better idea? From: Kohji Okuno Date: Tue, 24 Jan 2012 09:53:29 +0900 (JST) > Hi HPS, > >> On Monday 23 January 2012 09:12:46 Kohji Okuno wrote: >>> Hi HPS, >>> >>> I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap. >>> And, in xhci.c you set UPS_PORT_POWER as folows. >>> >>> When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET() macro will >>> return incorrect value. >>> >>> if (v & XHCI_PS_PP) { >>> /* >>> * The USB 3.0 RH is using the >>> * USB 2.0's power bit >>> */ >>> i |= UPS_PORT_POWER; >>> } >>> >> >> Hi, >> >> The USB 3.0 root HUB is special because it defines FULL/HIGH and LOW speed, so >> I had to merge that into the port status register of the XHCI root HUB like >> this: >> >> 0: CONNECT_STATUS >> 1: PORT_ENABLED >> 2: SUSPEND >> 3: OVERCURRENT_INDICATOR >> 4: LINK STATE (USB 3.0) >> 5: - >> 6: - >> 7: - >> 8: PORT_POWER (USB 2.0) >> # Bit 9+10 have 4 combinations which are defined: FS, LW, HS, SS >> 9: LOW_SPEED (USB 2.0) >> 10: HIGH_SPEED (USB 2.0) >> 11: not implemented >> 12: PORT_INDICATOR >> 13: >> 14: >> 15: MODE_DEVICE (FreeBSD specific) >> >> If you have a better idea, it is possible to change this. > > I have a idea. > > -#define UPS_PORT_LINK_STATE_GET(x) (((x) >> 5) & 0xF) > -#define UPS_PORT_LINK_STATE_SET(x) (((x) & 0xF) << 5) > +#define UPS_PORT_LINK_STATE_GET(x) ((((x) >> 5) & 0x7)|(((x) >> 11) & 0x8)) > +#define UPS_PORT_LINK_STATE_SET(x) ((((x) & 0x7) << 5)|(((x) & 0x8) << 11)) > +#define UPS_PORT_LS_SS 0x4000 /* currently FreeBSD specific */ > > But, this is not cool. > > Regards, > Kohji Okuno From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 11:58:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A000106564A for ; Sat, 28 Jan 2012 11:58:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id BD6368FC0A for ; Sat, 28 Jan 2012 11:58:17 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 235284084; Sat, 28 Jan 2012 12:58:15 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 28 Jan 2012 12:56:13 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20120123.171246.321689433999174416.okuno.kohji@jp.panasonic.com> <20120124.095329.1799630236416551619.okuno.kohji@jp.panasonic.com> <20120128.205339.1305564732068259146.okuno.kohji@jp.panasonic.com> In-Reply-To: <20120128.205339.1305564732068259146.okuno.kohji@jp.panasonic.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201281256.13847.hselasky@c2i.net> Cc: Kohji Okuno Subject: Re: Is UPS_PORT_POWER wrong? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 11:58:18 -0000 On Saturday 28 January 2012 12:53:39 Kohji Okuno wrote: > Hi HPS, > > Do you have better idea? > It might be we should implement a separate control request to get the information we need? Though that needs to be standardized. What do you think about that? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 08:49:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BAD4106566C for ; Sat, 28 Jan 2012 08:49:44 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 523BD8FC14 for ; Sat, 28 Jan 2012 08:49:44 +0000 (UTC) Received: (qmail 80245 invoked by uid 99); 28 Jan 2012 08:19:45 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2012 08:19:45 +0000 Received: from localhost (HELO lp-shahaf.local) (127.0.0.1) (smtp-auth username danielsh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2012 08:19:44 +0000 Date: Sat, 28 Jan 2012 10:19:19 +0200 From: Daniel Shafaf To: Matt Mullins Message-ID: <20120128081919.GA6699@lp-shahaf.local> References: <4F22D9FD.10502@p6m7g8.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Sat, 28 Jan 2012 12:32:38 +0000 Cc: Scott Sanders , current@freebsd.org, "Philip M. Gollucci" Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 08:49:44 -0000 Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800: > On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci wrote: > > All, > > > > $ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs > > jid=17 name=17 > > > > # jubilee/chef > > jail_jubilee_hostname="jubilee.dca1.rws" > > jail_jubilee_ip="192.168.2.41" > > jail_jubilee_ip_multi0="192.168.2.42" > > jail_jubilee_interface="bge1" > > jail_jubilee_rootdir="/jubilee" > > jail_jubilee_devfs_enable="YES" > > The default flags that /etc/rc.d/jail passes to jail(8) are "-l -U > root". Failing to give jail(8) a name results in name==jid, as you > found above. > > You can make the rc script name the jail by setting: > jail_jubilee_flags="-n jubilee -l -U root" > Good point. Would it make sense to have rc.d/jail behave this way by default? % diff -u /etc/rc.d/jail jail --- /etc/rc.d/jail 2012-01-21 18:22:26.000000000 +0200 +++ jail 2012-01-28 10:13:03.000000000 +0200 @@ -112,7 +112,7 @@ eval _fstab=\"\${jail_${_j}_fstab:-${jail_fstab}}\" [ -z "${_fstab}" ] && _fstab="/etc/fstab.${_j}" eval _flags=\"\${jail_${_j}_flags:-${jail_flags}}\" - [ -z "${_flags}" ] && _flags="-l -U root" + [ -z "${_flags}" ] && _flags="-n ${_j} -l -U root" eval _consolelog=\"\${jail_${_j}_consolelog:-${jail_consolelog}}\" [ -z "${_consolelog}" ] && _consolelog="/var/log/jail_${_j}_console.log" eval _fib=\"\${jail_${_j}_fib:-${jail_fib}}\" > Notice the rc script uses the second form of syntax listed in jail(8), > at least on 9.0-RELEASE. From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 15:36:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D851065672; Sat, 28 Jan 2012 15:36:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 51AB08FC14; Sat, 28 Jan 2012 15:36:15 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3267829wib.13 for ; Sat, 28 Jan 2012 07:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=lpYX7EqXwouQbNoNcz61R1/hyDV3vonpIrIwSHPPIaQ=; b=CtR3y7c5L8LhfVEDQg0zvAl4SS/4YX6N4969aqIjDoz968Tjy65GGeImQNObJjsj+V 3IXXZyWmStAJhACNfCfEt7kyrDkDglMpPR2aqoOm7gWDSGegCSmlyOld+O0L3weyJ4z8 PNCjT49JVvQj3gIzLVWIIFcVV5wD3G/aemOok= MIME-Version: 1.0 Received: by 10.180.82.41 with SMTP id f9mr17635110wiy.7.1327763450081; Sat, 28 Jan 2012 07:10:50 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Sat, 28 Jan 2012 07:10:49 -0800 (PST) In-Reply-To: <201201191123.06109.jhb@freebsd.org> References: <20120118220136.GA1862@glenbarber.us> <201201191050.45477.jhb@freebsd.org> <20120119160257.GD1953@glenbarber.us> <201201191123.06109.jhb@freebsd.org> Date: Sat, 28 Jan 2012 16:10:49 +0100 X-Google-Sender-Auth: hN-902rb3FHjuWwO55G_duNleto Message-ID: From: Attilio Rao To: John Baldwin , freebsd-current@freebsd.org, gjb@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [panic] intr_event_execute_handlers() - Corrupted DWARF expression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 15:36:16 -0000 2012/1/19 John Baldwin : > On Thursday, January 19, 2012 11:02:57 am Glen Barber wrote: >> On Thu, Jan 19, 2012 at 10:50:45AM -0500, John Baldwin wrote: >> > On Wednesday, January 18, 2012 5:01:37 pm Glen Barber wrote: >> > > Hi, >> > > >> > > I'm running -CURRENT from about 5 days ago: >> > > >> > > nucleus# uname -a >> > > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r230037M: Fri J= an >> > > 13 17:48:14 EST 2012 =C2=A0 =C2=A0 gjb@nucleus:/usr/obj/usr/src/sys/= NUCLEUS =C2=A0amd64 >> > > >> > > (The 'M' is kib's DRM patches for Intel GPU.) >> > > >> > > So far, I haven't had much problem with this laptop, but just had th= e >> > > machine panic. >> > > >> > > I have kgdb output attached, and I'll be happy to provide whatever >> > > additional information that may be needed. >> > > >> > > I have core.txt.N available here: >> > > >> > > =C2=A0 http://people.freebsd.org/~gjb/core.txt >> > >> > In kgdb, can you go to frame 6 and 'p td->td_lock'. =C2=A0If that is n= on-null, can >> > you do 'p *td->td_lock'? >> > >> >> Sure, script(1) output is attached. > > Hmm, I don't think td->td_lock is ever supposed to be NULL. No, never, it is initialized in sched_fork_thread() and can point to containers lock or blocked_lock. I think the memory page of the pointer could have been zeroed or it is an hw bug. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 16:03:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53A6D106566B for ; Sat, 28 Jan 2012 16:03:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCA88FC08 for ; Sat, 28 Jan 2012 16:03:12 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so2954386wgb.31 for ; Sat, 28 Jan 2012 08:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B0Uq5I1mYaaDZ9rx5TMCGEzSJ3duNVCjxo12goClvtA=; b=tamz16P/toS/LtBK2qJiF4e7oTnjnqggp+Xv7k3YvtNEZGsQ3mLjrfn/0ng8XBrugs PlxO6tcBKAWbhpDhkIzaHHVeNm6bkGps/fTVKPnP8R7S1+VieP16am5XukUnbCt8b0zc WzWjEm3RBPFukqevJx9bFdfkJKJOloKXne46k= MIME-Version: 1.0 Received: by 10.180.109.77 with SMTP id hq13mr18401922wib.7.1327766591358; Sat, 28 Jan 2012 08:03:11 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Sat, 28 Jan 2012 08:03:11 -0800 (PST) In-Reply-To: References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Sat, 28 Jan 2012 17:03:11 +0100 X-Google-Sender-Auth: A3bGQKxC_f9Bc9MRYADpTfYRpZE Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 16:03:13 -0000 2011/11/8 Attilio Rao : > 2011/11/8 Attilio Rao : >> Author: attilio >> Date: Tue Nov =C2=A08 10:18:07 2011 >> New Revision: 227333 >> URL: http://svn.freebsd.org/changeset/base/227333 >> >> Log: >> =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default= on >> =C2=A0all the architectures. >> =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the >> =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. >> >> =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems >> =C2=A0from the tree. > > This is just a gentle reminder in order to point you further to the > "official" page: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > and encourage once again people in adopting a dying FS if it really > matters to them. > So far, unfortunately, I didn't see a lot of activity in this area but > I hope that this would change soon. This is a further reminder. So far I've not seen any improvement over the locking of any of our 'legacy' filesystems. I remind you that this may be meaning disconnecting them from the tree on 1st Semptember 2012, accordingly with this road-map: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in order to see how well the users do with this option down. At the present times this means that from 1st March you won't be able to mount smbfs or ntfs volumes, for example. Please step up and fix your favourite filesystem. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 21:07:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6C61065780 for ; Sat, 28 Jan 2012 21:07:05 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 96F918FC08 for ; Sat, 28 Jan 2012 21:07:04 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1C89F25D3892; Sat, 28 Jan 2012 21:07:02 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 04736BDA2A6; Sat, 28 Jan 2012 21:07:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 35JJQuWtrHqH; Sat, 28 Jan 2012 21:07:00 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C14E7BDA2A9; Sat, 28 Jan 2012 21:06:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120128081919.GA6699@lp-shahaf.local> Date: Sat, 28 Jan 2012 21:06:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F22D9FD.10502@p6m7g8.com> <20120128081919.GA6699@lp-shahaf.local> To: Daniel Shafaf X-Mailer: Apple Mail (2.1084) Cc: Scott Sanders , Matt Mullins , "Philip M. Gollucci" , current@freebsd.org Subject: Re: jid and jname are numberic by default why? Can we change it ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 21:07:05 -0000 On 28. Jan 2012, at 08:19 , Daniel Shafaf wrote: > Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800: >> On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci = wrote: >>> All, >>>=20 >>> $ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)=3D'| xargs >>> jid=3D17 name=3D17 >>>=20 >>> # jubilee/chef >>> jail_jubilee_hostname=3D"jubilee.dca1.rws" >>> jail_jubilee_ip=3D"192.168.2.41" >>> jail_jubilee_ip_multi0=3D"192.168.2.42" >>> jail_jubilee_interface=3D"bge1" >>> jail_jubilee_rootdir=3D"/jubilee" >>> jail_jubilee_devfs_enable=3D"YES" >>=20 >> The default flags that /etc/rc.d/jail passes to jail(8) are "-l -U >> root". Failing to give jail(8) a name results in name=3D=3Djid, as = you >> found above. >>=20 >> You can make the rc script name the jail by setting: >> jail_jubilee_flags=3D"-n jubilee -l -U root" >>=20 >=20 > Good point. Would it make sense to have rc.d/jail behave this way by > default? >=20 > % diff -u /etc/rc.d/jail jail=20 > --- /etc/rc.d/jail 2012-01-21 18:22:26.000000000 +0200 > +++ jail 2012-01-28 10:13:03.000000000 +0200 > @@ -112,7 +112,7 @@ > eval _fstab=3D\"\${jail_${_j}_fstab:-${jail_fstab}}\" > [ -z "${_fstab}" ] && _fstab=3D"/etc/fstab.${_j}" > eval _flags=3D\"\${jail_${_j}_flags:-${jail_flags}}\" > - [ -z "${_flags}" ] && _flags=3D"-l -U root" > + [ -z "${_flags}" ] && _flags=3D"-n ${_j} -l -U root" > eval = _consolelog=3D\"\${jail_${_j}_consolelog:-${jail_consolelog}}\" > [ -z "${_consolelog}" ] && = _consolelog=3D"/var/log/jail_${_j}_console.log" > eval _fib=3D\"\${jail_${_j}_fib:-${jail_fib}}\" >=20 No. rc.d/jail shall not be extended anymore; please see the framework = Jamie posted on freebsd-jail last year and test/review/report back there. See = http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568= You get a config file etc and get rid of all the shell "magic" and = "nightmare". /bz >> Notice the rc script uses the second form of syntax listed in = jail(8), >> at least on 9.0-RELEASE. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!