From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 05:52:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFAD9AA9; Mon, 10 Dec 2012 05:52:25 +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 A62648FC0C; Mon, 10 Dec 2012 05:52:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBA5qJLK046213; Mon, 10 Dec 2012 05:52:19 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 2kp9ziqbjm8k87fn2xp2ukyk7s; Mon, 10 Dec 2012 05:52:19 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: please add auditdistd user/group to -stable and the 9.1-release? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Sun, 9 Dec 2012 21:52:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <0D1FE0E1-7DAA-451D-8290-B338027249A0@kientzle.com> References: To: Garrett Cooper X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , freebsd-current , Robert Watson , Ken Smith X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 05:52:26 -0000 On Dec 3, 2012, at 12:46 AM, Garrett Cooper wrote: > On Sun, Dec 2, 2012 at 11:06 PM, Garrett Cooper wrote: >> On Sun, Dec 2, 2012 at 9:20 PM, Garrett Cooper wrote: >>> On Sun, Dec 2, 2012 at 9:08 PM, Adrian Chadd wrote: >>>> Hi, >>>> >>>> Would you guys please add the auditdistd user/group info to >>>> 9.1-release, so people doing crossbuilds of -HEAD on a fresh >>>> 9.1-RELEASE won't get an install error? >>> >>> Or mtree could just use -w instead in Makefile.inc1 and distribute. >>> Let me do some investigation to determine whether or not this is a >>> valid solution to this problem. >> >> I've done some digging in the source tree and this seems like a >> potentially workable solution for the issue reported -- in part >> because auditdistd is only present in BSD.var.dist, /etc/rc.d/var runs >> BSD.var.dist at boot, etc: A more robust -- and possibly simpler -- solution might be to include the uid/gid in the mtree file as well and provide a way for mtree to fall back to using that if the uname/gname can't be looked up. This will probably require adding some switches to choose the appropriate behavior from among the following: * If both are specified, prefer the name. This is what tar always does: tries to use the name and falls back to using the number if the name isn't available. * If both are specified, prefer the number. This would be helpful if you were running mtree in a cross-build situation where the host system has radically different user/group numbering (Robert mentioned someday cross-building from non-FreeBSD hosts). * Require both to match. This would complain if the name/number in the mtree file didn't both exactly match the current host. This would be the useful behavior when using mtree files to verify files on disk. This is likely the most appropriate default behavior. Tim From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 06:08:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6B7FD09 for ; Mon, 10 Dec 2012 06:08:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 9E6D78FC08 for ; Mon, 10 Dec 2012 06:08:32 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBA68WIP046289 for freebsd-current@freebsd.org; Mon, 10 Dec 2012 06:08:32 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id d96u7d3fceamjrxtdjreg6h5vs; for freebsd-current@freebsd.org; Mon, 10 Dec 2012 06:08:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: r244036 kernel hangs under load. Date: Sun, 9 Dec 2012 22:08:31 -0800 Message-Id: To: freebsd-current Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 06:08:32 -0000 I haven't found any useful clues yet, but thought I'd ask if anyone else was seeing hangs in a recent kernel. I just upgraded to r244036 using a straight GENERIC i386 kernel. (Straight buildworld/buildkernel, no local changes, /etc/src.conf doesn't exist, /etc/make.conf just has PERL_VERSION defined.) When I try to cross build an ARM world on the resulting system, the entire system hangs hard after about 30 minutes: No network, no keyboard response, no nothing. Don't know if it's relevant, but the system is using NFS pretty heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) I'll try to get some more details ... Tim From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 08:14:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D782A4DB; Mon, 10 Dec 2012 08:14:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 35B8C8FC13; Mon, 10 Dec 2012 08:14:36 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so900028wib.13 for ; Mon, 10 Dec 2012 00:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5TejgMaufzwx+IWmqOxSbDtw2e3W7TR7e3Yfazjfvs8=; b=uwwTPT6AW/74+RD0N3yUPKqBEmfkfPxosTcH9fow1TbBi1Ry4tb3gXKepPeuiCZ/WY cdx2LWQTpCo1b9BETR1NHzCCdwLSSt4hQt5dA7SIOr/Qi11D/LD/AuSSM8V6DYVJ6MCj 2pHTeAWfevM5wnlNurd1djxLa21DYDMCsllsJPAqn8RQzeBbZz2mCvbLNdfYR7P8kJrJ bUhH2pdBdPe1Ts7ifslz0G5zYzwMuqf7MAlhtLn3liINomDizWETM5w1tofHA5auPivs d4TK7KbM7v6GLHM2pMH/3Q03BqgN1Cab+kRo2GrUybnn6UrK8lBH/O1qTm7wTY3iMVby q1NQ== MIME-Version: 1.0 Received: by 10.180.102.101 with SMTP id fn5mr9141015wib.19.1355127275881; Mon, 10 Dec 2012 00:14:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Mon, 10 Dec 2012 00:14:35 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 00:14:35 -0800 X-Google-Sender-Auth: EQ5HRl73Z6vL0ebpBnYifFO_vu4 Message-ID: Subject: Re: r244036 kernel hangs under load. From: Adrian Chadd To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 08:14:37 -0000 .. what was the previous kernel version? adrian On 9 December 2012 22:08, Tim Kientzle wrote: > I haven't found any useful clues yet, but thought I'd ask if anyone else > was seeing hangs in a recent kernel. > > I just upgraded to r244036 using a straight GENERIC i386 kernel. > (Straight buildworld/buildkernel, no local changes, /etc/src.conf doesn't > exist, /etc/make.conf just has PERL_VERSION defined.) > > When I try to cross build an ARM world on the resulting system, > the entire system hangs hard after about 30 minutes: No network, > no keyboard response, no nothing. > > Don't know if it's relevant, but the system is using NFS pretty > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > I'll try to get some more details ... > > Tim > > _______________________________________________ > 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 Mon Dec 10 09:45:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED51AFC; Mon, 10 Dec 2012 09:45:01 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B453E8FC13; Mon, 10 Dec 2012 09:45:00 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so953248wib.13 for ; Mon, 10 Dec 2012 01:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Ym9SEzKy5OClEg+7hqqwlaFkaTIWAk31xjTaCY1JClI=; b=IdJadRPF/l/zIIr8xvToBBHgdBLgpgOhIJfMPbdTPT2zHqy6LocEG0a6gWFJOBMdGc IMp9s77EMBPy4Ro08ZZZp7FPG/i0nlYTnD26HA7ILRhlrMUVQhkefvbyiqnWJAwBZhc4 mxDzFNCrgE+T78mTjamICbxA5Q3vr92vIa7xiO+vmgs35iT70OJJKJHEC9nOMBPdCwaS /d8gEL5DbosaXfAT6Ioj1h0XkesIa2rrY5nMuUnTC5ZlwJl/FvhF1VHcUsCeVFUWJ+5s FaNLbud6Jv84ZNb0/RJTRgrfSqXrUpGOnDjQDoXSeSLpzNdY70uwvcz1udNUUkhwTeAI fdLw== Received: by 10.216.213.36 with SMTP id z36mr4768789weo.202.1355132698953; Mon, 10 Dec 2012 01:44:58 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id cf6sm10742120wib.3.2012.12.10.01.44.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 01:44:57 -0800 (PST) Date: Mon, 10 Dec 2012 10:44:51 +0100 From: Mateusz Guzik To: Tim Kientzle Subject: Re: please add auditdistd user/group to -stable and the 9.1-release? Message-ID: <20121210094451.GA25061@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tim Kientzle , Garrett Cooper , Adrian Chadd , freebsd-current , Robert Watson , Ken Smith References: <0D1FE0E1-7DAA-451D-8290-B338027249A0@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0D1FE0E1-7DAA-451D-8290-B338027249A0@kientzle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , Adrian Chadd , freebsd-current , Robert Watson , Ken Smith X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 09:45:01 -0000 On Sun, Dec 09, 2012 at 09:52:18PM -0800, Tim Kientzle wrote: > > On Dec 3, 2012, at 12:46 AM, Garrett Cooper wrote: > > > On Sun, Dec 2, 2012 at 11:06 PM, Garrett Cooper wrote: > >> On Sun, Dec 2, 2012 at 9:20 PM, Garrett Cooper wrote: > >>> On Sun, Dec 2, 2012 at 9:08 PM, Adrian Chadd wrote: > >>>> Hi, > >>>> > >>>> Would you guys please add the auditdistd user/group info to > >>>> 9.1-release, so people doing crossbuilds of -HEAD on a fresh > >>>> 9.1-RELEASE won't get an install error? > >>> > >>> Or mtree could just use -w instead in Makefile.inc1 and distribute. > >>> Let me do some investigation to determine whether or not this is a > >>> valid solution to this problem. > >> > >> I've done some digging in the source tree and this seems like a > >> potentially workable solution for the issue reported -- in part > >> because auditdistd is only present in BSD.var.dist, /etc/rc.d/var runs > >> BSD.var.dist at boot, etc: > > A more robust -- and possibly simpler -- solution might be to > include the uid/gid in the mtree file as well and provide a > way for mtree to fall back to using that if the uname/gname can't > be looked up. > I disagree. We can have more tools requiring uid/gid pairs (install?). Having this information in more than one place may lead to mismatches. I think libc should export functions that would operate on arbitrary passwd files. Then we can teach tools to use them as needed. > This will probably require adding some switches to choose the > appropriate behavior from among the following: > > * If both are specified, prefer the name. This is what tar always does: > tries to use the name and falls back to using the number if the name > isn't available. > > * If both are specified, prefer the number. This would be helpful if > you were running mtree in a cross-build situation where the host > system has radically different user/group numbering (Robert > mentioned someday cross-building from non-FreeBSD hosts). > > * Require both to match. This would complain if the name/number in > the mtree file didn't both exactly match the current host. This > would be the useful behavior when using mtree files to verify > files on disk. This is likely the most appropriate default > behavior. > I agree, except s/number/name from in-tree passwd file/ . :) -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 11:24:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0260FDD6 for ; Mon, 10 Dec 2012 11:24:26 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 67C708FC16 for ; Mon, 10 Dec 2012 11:24:24 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so1066837wib.1 for ; Mon, 10 Dec 2012 03:24:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2b7MyPy1b7/Y+RLQ1tLw/MJckjQ5pDyLPvI7tfaZo8Y=; b=pj+yQhhkOwMM46WOsz1bMiK7W9iILtQZGXh4DLGqeJAo3pHr4H9p/imCgHFZ73jIgS IBpWPnn/7kO+Kh1oWjCfqlNUwneW9q6tg3OnD6WWnRhUmNZC9kUrl+49s8rMoMKt8Fef AHbBcsBt59/8J6TZQHWXkhfUkDQtU9zEcaJJ8FcbDRlFfGJdEHNw6M+PMr8bQww6UNrY Q/73YWzpAuWXyMnb3s2JMilcRNqcbx/WHnoEP9mc56bwnOZEXOKVzxnbr8FLemUaaURX 5pFjxYAGm6ufTKBUrwNItdp7xTaqRRvDvKZIO5bLxjF75O79n+Wc5X3ByRovXK70ghY7 +Gtg== Received: by 10.216.209.130 with SMTP id s2mr5436789weo.86.1355138663668; Mon, 10 Dec 2012 03:24:23 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id h19sm9624152wiv.7.2012.12.10.03.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 03:24:22 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: kernel module parallel build? From: Fleuriot Damien In-Reply-To: Date: Mon, 10 Dec 2012 12:24:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C48F39A-83D9-4EA0-A7C5-99484FF00D3F@my.gd> References: <5083D84E.50903@freebsd.org> <201212041052.51476.jhb@freebsd.org> <201212051142.18361.jhb@freebsd.org> <0EC857C9-4C1B-467D-8499-B493401B64BC@bsdimp.com> <20E25F79-2C53-45FD-BB7F-060AC9B26245@my.gd> To: Garrett Cooper X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm7z3Ctt0ejSkcOU0B2qdg67ktS8zznw/Ib9Xc8rFF1mGkjJo0ZvuvVvChAoVBzoZJUvV++ X-Mailman-Approved-At: Mon, 10 Dec 2012 12:30:16 +0000 Cc: "freebsd-hackers@freebsd.org" , AndreOppermann , FreeBSD Current , Ryan Stone , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 11:24:26 -0000 On Dec 6, 2012, at 1:28 AM, Garrett Cooper wrote: > On Wed, Dec 5, 2012 at 3:51 PM, Damien Fleuriot wrote: >=20 > ... >=20 >> All trolling aside, I believe an awesome fix to be setting module = override in /etc/make.conf to only build the 4-5 specific modules one = needs. >>=20 >> To be honest I think this configuration tweak should be advertised a = bit more as it definitely speeds up kernel builds. >>=20 >> I would be happy to check if this is advertised in the handbook in = the "rebuilding kernel" section and enhance its visibility if required. >>=20 >> I can provide en_US and fr_FR. >=20 > +1. Please write it up if you can; it's much quicker/better than the > kitchen sink approach if you know what you're doing and don't have to > build for a large set of platforms. > Thanks! > -Garrett I've had a look at the handbook and the MODULES_OVERRIDE bit is already = well written and definitely visible: = http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-bui= lding.html I believe no rewrite is necessary. However, I fail to see any mention of nextboot. It might be a good idea to let people know they can boot their new = kernel just once to see if it works, and revert to their old kernel if = boot should fail. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 13:41:02 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3705BBCC for ; Mon, 10 Dec 2012 13:41:02 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8068FC12 for ; Mon, 10 Dec 2012 13:41: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 qBADew4b085660; Mon, 10 Dec 2012 17:40:58 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBADevhM085659; Mon, 10 Dec 2012 17:40:57 +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, 10 Dec 2012 17:40:57 +0400 From: Gleb Smirnoff To: Artyom Mirgorodskiy Subject: Re: rev 244030 route command is not working Message-ID: <20121210134057.GN48639@FreeBSD.org> References: <2452291.zQQ4fSp1fM@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <2452291.zQQ4fSp1fM@home.alkar.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 13:41:02 -0000 On Sat, Dec 08, 2012 at 01:00:57PM +0200, Artyom Mirgorodskiy wrote: A> I just upgraded to revision 244030. Unexpected route command is not working: A> A> #route add default 192.168.1.1 A> route: fiboptlist_csv failed. What does 'sysctl net.my_fibnum' say? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 13:50:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E28D125; Mon, 10 Dec 2012 13:50:01 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7B38FC15; Mon, 10 Dec 2012 13:50:00 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 90BC2E604A; Mon, 10 Dec 2012 08:49:59 -0500 (EST) From: Artyom Mirgorodskiy To: Gleb Smirnoff Subject: Re: rev 244030 route command is not working Date: Mon, 10 Dec 2012 15:49:36 +0200 Message-ID: <10115016.7W2v4CMve6@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: <20121210134057.GN48639@FreeBSD.org> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121210134057.GN48639@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 13:50:01 -0000 sysctl net.my_fibnum net.my_fibnum: 0 On Monday 10 December 2012 17:40:57 Gleb Smirnoff wrote: > On Sat, Dec 08, 2012 at 01:00:57PM +0200, Artyom Mirgorodskiy wrote: > A> I just upgraded to revision 244030. Unexpected route command is not working: > A> > A> #route add default 192.168.1.1 > A> route: fiboptlist_csv failed. > > What does 'sysctl net.my_fibnum' say? > > > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 14:21:46 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88588DFC for ; Mon, 10 Dec 2012 14:21:46 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 15B588FC17 for ; Mon, 10 Dec 2012 14:21:45 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBAELira030988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Dec 2012 15:21:44 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Mon, 10 Dec 2012 15:21:44 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Chuck Burns Subject: Re: 9.1-RC3 LiveCD missing features Message-ID: <20121210142143.GB69724@acme.spoerlein.net> Mail-Followup-To: Chuck Burns , freebsd-current@freebsd.org References: <50C26999.6090802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C26999.6090802@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 14:21:46 -0000 On Fri, 2012-12-07 at 16:11:37 -0600, Chuck Burns wrote: > On 12/7/2012 3:50 PM, CeDeROM wrote: > > Hello :-) > > > > I have tried to chceck for badblocks on my / but I did not find badblocks > > program on LiveCD and there is no option to install it. This is very useful > > utility, please add it as part of LiveCD :-) > > > > Also there is a problem with DHCP based workstations using LiveCD - > > although interface gets configured it is impossible to update > > /etc/resolv.conf (by dhclient and by hand) and so this workstation pretty > > useless for IPv4 (is it more usable on IPv6?). Please update :-) > > > > Thank you :-) > > Tomek > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > _______________________________________________ > > 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" > > > > dd if=/dev/zer of=/dev/ada0 > > ^^^ There's your "badblocks" program. Any hard drive made in the last > decade have been self-remapping.. Attempting to write to a bad block > will cause the hard drive to remap an unused sector into it's place, > until the drive runs out of said "unused" backup sectors, and at that > time, will begin simply begin just "losing" storage space... IE the > number of total sectors on the drive will begin to shrink. Nah, use recoverdisk(1) to either zero the target disk or do a read/write cycle on every sector. It should be way faster, especially with dieing disks (but why would you want to make them work again, you should buy a new disk ASAP instead). hth Uli From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 14:28:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D2A1350; Mon, 10 Dec 2012 14:28:22 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 081648FC14; Mon, 10 Dec 2012 14:28:22 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id A2B3FE604A; Mon, 10 Dec 2012 09:28:21 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: rev 244030 route command is not working Date: Mon, 10 Dec 2012 16:27:58 +0200 Message-ID: <2837017.6IXeElfWaT@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: <20121210134057.GN48639@FreeBSD.org> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121210134057.GN48639@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gleb Smirnoff , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 14:28:22 -0000 Before calling fiboptlist_csv() the errno = EINVAL. I hope this help to solve problem. On Monday 10 December 2012 17:40:57 Gleb Smirnoff wrote: > On Sat, Dec 08, 2012 at 01:00:57PM +0200, Artyom Mirgorodskiy wrote: > A> I just upgraded to revision 244030. Unexpected route command is not working: > A> > A> #route add default 192.168.1.1 > A> route: fiboptlist_csv failed. > > What does 'sysctl net.my_fibnum' say? > > > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 17:35:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1528231E for ; Mon, 10 Dec 2012 17:35:53 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3098FC15 for ; Mon, 10 Dec 2012 17:35:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ti7Gj-000682-5M for freebsd-current@freebsd.org; Mon, 10 Dec 2012 18:35:53 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 18:35:53 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 18:35:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Date: Mon, 10 Dec 2012 09:35:29 -0800 Lines: 112 Message-ID: References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <50C22789.3030303@FreeBSD.org> X-Enigmail-Version: 1.4.6 Cc: kde-freebsd@freebsd.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 17:35:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/07/2012 09:29, Dimitry Andric wrote: > On 2012-12-07 17:43, Mark Atkinson wrote: >> On 12/7/2012 6:08 AM, Dimitry Andric wrote: > ... >>> With this patch (placed in /usr/ports/devel/dbus-qt4/files), >>> qdbus starts up and exits normally for me. I did not do any >>> other rigorous testing, though. :) >> >> Thanks for the awesome analysis. I will endeavor to figure out >> the bug in automoc4 that keeps it segfaulting randomly during >> compilation. >> >> Weirdly it segfaults reliably under portmaster, but may work just >> fine under just make. > > Try running it under valgrind. If it does undefined things, it may > work or not work randomly, and valgrind usually catches this. OK, so this one's a bit of a headscratcher, but maybe someone has some ideas. automoc4 always dies in libthr. #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP 101795/automoc4.bin)] (gdb) bt #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 #1 0x2864a046 in pthread_getspecific () from /lib/libthr.so.3 #2 0x28649e9a in pthread_getspecific () from /lib/libthr.so.3 #3 0x2864dbfb in pthread_kill () from /lib/libthr.so.3 #4 0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #5 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #6 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 #7 0x28075e00 in ?? () #8 0x286b4d30 in pipe () from /lib/libc.so.7 #9 0x280712ac in ?? () from /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? () from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in ?? () #15 0x00000001 in ?? () #16 0x00000000 in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0 0x2876c3a7 in select () from /lib/libc.so.7 (gdb) bt #0 0x2876c3a7 in select () from /lib/libc.so.7 #1 0x286481ab in select () from /lib/libthr.so.3 #2 0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #3 0x282c23b2 in select_msecs (nfds=17, fdread=0xbfbfa090, fdwrite=0xbfbfa010, timeout=-1) at io/qprocess_unix.cpp:998 #4 0x282c33f3 in QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at io/qprocess_unix.cpp:1219 #5 0x28240b50 in QProcess::waitForFinished (this=0xbfbfa1e8, msecs=-1) at io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor (this=0xbfbfab00, msg=@0xbfbfa2e0) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00, sourceFile=@0x29011658, mocFileName=@0x2901165c) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #8 0x0804f13b in AutoMoc::run (this=0xbfbfab00) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #9 0x0804aaef in main (argc=6, argv=0xbfbfab98) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 I noticed that qt_safe_select() used a register bound variable for the return value, but removing that didn't alleviate the error. The pthread_getspecific() manpage mentions that if the key is deleted then the behavior is undefined -- so maybe this? It's definitely seems like a race condition of some kind. Valgrind will kill any run of automoc4 and doesn't like some instruction after the qt_safe_select() call: vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 ==33074== valgrind: Unrecognised instruction at address 0x380434e9. ==33074== at 0x380434E9: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd) ==33074== by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) (qcore_unix.cpp:83) ==33074== by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) (qprocess_unix.cpp:998) ==33074== by 0x28021D: QProcessPrivate::waitForStarted(int) (qprocess_unix.cpp:1031) ==33074== by 0x1FFA02: QProcess::waitForStarted(int) (qprocess.cpp:1687) ==33074== by 0x1FEAEA: QProcess::waitForFinished(int) (qprocess.cpp:1752) ==33074== by 0x805487A: AutoMoc::echoColor(QString const&) (kde4automoc.cpp:74) ==33074== by 0x805264F: AutoMoc::generateMoc(QString const&, QString const&) (kde4automoc.cpp:569) ==33074== by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) ==33074== by 0x804AAEE: main (kde4automoc.cpp:114) Full valgrind output is at http://pastebin.com/KQTKYGX5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDGHWEACgkQrDN5kXnx8yZEUwCfXhKBqCJKJcfomG6mHo6ataaw x60An36saeyL2b09CR2Z/zL84KzjPjsQ =EzG3 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 18:25:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A7DC391 for ; Mon, 10 Dec 2012 18:25:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9779D8FC0C for ; Mon, 10 Dec 2012 18:25:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBAIPQVI074316; Mon, 10 Dec 2012 20:25:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBAIPQVI074316 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBAIPQBW074314; Mon, 10 Dec 2012 20:25:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Dec 2012 20:25:26 +0200 From: Konstantin Belousov To: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Message-ID: <20121210182525.GR3013@kib.kiev.ua> References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QyTKe3xr7+CGa/hc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, kde-freebsd@spider.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 18:25:32 -0000 --QyTKe3xr7+CGa/hc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 12/07/2012 09:29, Dimitry Andric wrote: > > On 2012-12-07 17:43, Mark Atkinson wrote: > >> On 12/7/2012 6:08 AM, Dimitry Andric wrote: > > ... > >>> With this patch (placed in /usr/ports/devel/dbus-qt4/files), > >>> qdbus starts up and exits normally for me. I did not do any > >>> other rigorous testing, though. :) > >>=20 > >> Thanks for the awesome analysis. I will endeavor to figure out > >> the bug in automoc4 that keeps it segfaulting randomly during > >> compilation. > >>=20 > >> Weirdly it segfaults reliably under portmaster, but may work just > >> fine under just make. > >=20 > > Try running it under valgrind. If it does undefined things, it may > > work or not work randomly, and valgrind usually catches this. >=20 > OK, so this one's a bit of a headscratcher, but maybe someone has some > ideas. automoc4 always dies in libthr. Build rtld, libc and libthr with the debug symbols to get useful backtrace. >=20 > #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 > [New Thread 29003800 (LWP 100960/automoc4.bin)] > [New Thread 29003080 (LWP 101795/automoc4.bin)] > (gdb) bt > #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 > #1 0x2864a046 in pthread_getspecific () from /lib/libthr.so.3 > #2 0x28649e9a in pthread_getspecific () from /lib/libthr.so.3 > #3 0x2864dbfb in pthread_kill () from /lib/libthr.so.3 > #4 0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #5 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 > #6 0x2865d500 in _thread_state_running () from /lib/libthr.so.3 > #7 0x28075e00 in ?? () > #8 0x286b4d30 in pipe () from /lib/libc.so.7 > #9 0x280712ac in ?? () from /libexec/ld-elf.so.1 > #10 0xbf9fce2c in ?? () > #11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1 > #12 0x28071f68 in ?? () from /libexec/ld-elf.so.1 > #13 0xbf9fcde0 in ?? () > #14 0xbf9fce18 in ?? () > #15 0x00000001 in ?? () > #16 0x00000000 in ?? () > (gdb) thread 2 > [Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0 > 0x2876c3a7 in select () from /lib/libc.so.7 > (gdb) bt > #0 0x2876c3a7 in select () from /lib/libc.so.7 > #1 0x286481ab in select () from /lib/libthr.so.3 > #2 0x28365c49 in qt_safe_select (nfds=3D17, fdread=3D0xbfbfa090, > fdwrite=3D0xbfbfa010, fdexcept=3D0x0, orig_timeout=3D0x0) at > kernel/qcore_unix.cpp:83 > #3 0x282c23b2 in select_msecs (nfds=3D17, fdread=3D0xbfbfa090, > fdwrite=3D0xbfbfa010, timeout=3D-1) at io/qprocess_unix.cpp:998 > #4 0x282c33f3 in QProcessPrivate::waitForFinished (this=3D0x29089300, > msecs=3D-1) at io/qprocess_unix.cpp:1219 > #5 0x28240b50 in QProcess::waitForFinished (this=3D0xbfbfa1e8, > msecs=3D-1) at io/qprocess.cpp:1759 > #6 0x0805487b in AutoMoc::echoColor (this=3D0xbfbfab00, > msg=3D@0xbfbfa2e0) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 > #7 0x08052650 in AutoMoc::generateMoc (this=3D0xbfbfab00, > sourceFile=3D@0x29011658, mocFileName=3D@0x2901165c) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 > #8 0x0804f13b in AutoMoc::run (this=3D0xbfbfab00) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #9 0x0804aaef in main (argc=3D6, argv=3D0xbfbfab98) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 >=20 > I noticed that qt_safe_select() used a register bound variable for the > return value, but removing that didn't alleviate the error. >=20 > The pthread_getspecific() manpage mentions that if the key is deleted > then the behavior is undefined -- so maybe this? It's definitely > seems like a race condition of some kind. >=20 > Valgrind will kill any run of automoc4 and doesn't like some > instruction after the qt_safe_select() call: >=20 > vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 This is ud2, an instruction which generates a fault on purpose. So rebuild the system libraries with the debug symbols and show the backtrace. > =3D=3D33074=3D=3D valgrind: Unrecognised instruction at address 0x380434e= 9. > =3D=3D33074=3D=3D at 0x380434E9: ??? (in > /usr/local/lib/valgrind/memcheck-x86-freebsd) > =3D=3D33074=3D=3D by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, > fd_set*, timeval const*) (qcore_unix.cpp:83) > =3D=3D33074=3D=3D by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) > (qprocess_unix.cpp:998) > =3D=3D33074=3D=3D by 0x28021D: QProcessPrivate::waitForStarted(int) > (qprocess_unix.cpp:1031) > =3D=3D33074=3D=3D by 0x1FFA02: QProcess::waitForStarted(int) > (qprocess.cpp:1687) > =3D=3D33074=3D=3D by 0x1FEAEA: QProcess::waitForFinished(int) > (qprocess.cpp:1752) > =3D=3D33074=3D=3D by 0x805487A: AutoMoc::echoColor(QString const&) > (kde4automoc.cpp:74) > =3D=3D33074=3D=3D by 0x805264F: AutoMoc::generateMoc(QString const&, > QString const&) (kde4automoc.cpp:569) > =3D=3D33074=3D=3D by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) > =3D=3D33074=3D=3D by 0x804AAEE: main (kde4automoc.cpp:114) >=20 > Full valgrind output is at http://pastebin.com/KQTKYGX5 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlDGHWEACgkQrDN5kXnx8yZEUwCfXhKBqCJKJcfomG6mHo6ataaw > x60An36saeyL2b09CR2Z/zL84KzjPjsQ > =3DEzG3 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > 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" --QyTKe3xr7+CGa/hc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQxikVAAoJEJDCuSvBvK1BZOoP+gNRJh613Ei0VSDQX+nTsUsq ffhhxd+tza/f4E6BS/DndbKPi+rTovu+wNShQ0dwlBNX/Ukp+R6pICnO6/UTnd4w 8rD8DH3ZFHW955Kgoz3icor9Y4/0xb5q1P9aLkbnbpOx4KijRbspfkS7c+ygrEyh FIpKX0rZQwGbtFmVq9Qo4R58dB6JXieaRXEhp971TYy0yYYM91kYf7WSr8iaQKdg w07Ep4YKp4C67w3XdQaeaFDxQLySdD2OhMHEG5KiBsybGzztbneQwJ3MsjzYY7K+ 6OAFY7detx6wi4NFG4BHIvvvd5p2+Y1ydNfM4YNZz5YSv7JD8efqFTEBCprUFsks J/Jd7ZOG5tmxgr2qZJxNm4aYj51ljTJrUPT4KpI4+1MEIqEBMu4faxVMuJm7pQ5k M0mYDw7Kap7ss/3uHpQx/dAWw56nwDgV5y4dKBr/oo8SXmvIlkgqz5IbCBi2GdGL 7sKgoimfR4rEeu0p84Ifr4lY4jy/6SxuoG5UUVoJc58jwJhie4Q3RqIWujrG6g1Y 674I7VKlzqSzIxYYTNS72eMEGc2PldeieN6/Futl83VCtKhMEyIaXu13e2bmp/72 BYiGkUCv14T5MZjMMcSDYL5Aaxyk69VAaSEbIQsiB/B1GiHcOfr++T33GXLhRVTS 7znLnSahNhK5bJH96R1I =5Dp2 -----END PGP SIGNATURE----- --QyTKe3xr7+CGa/hc-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 18:38:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9496770C; Mon, 10 Dec 2012 18:38:29 +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 168D78FC0C; Mon, 10 Dec 2012 18:38:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACgrxlCDaFvO/2dsb2JhbABFhje4XHOCHgEBAQMBAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASHagYMpSWSP4Eiix0bDYMIgRMDiF+KeYIugRyPLIMRgUgHFx4 X-IronPort-AV: E=Sophos;i="4.84,252,1355115600"; d="scan'208";a="3866404" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Dec 2012 13:38:21 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D5A82B3F7D; Mon, 10 Dec 2012 13:38:21 -0500 (EST) Date: Mon, 10 Dec 2012 13:38:21 -0500 (EST) From: Rick Macklem To: Adrian Chadd Message-ID: <735026206.1290394.1355164701856.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 18:38:29 -0000 Adrian Chadd wrote: > .. what was the previous kernel version? > Hopefully Tim has it narrowed down more, but I don't see the hangs on a Sept. 7 kernel from head and I do see them on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) It seems to predate my commit (r244008), which was my first concern. I use old single core i386 hardware and can fairly reliably reproduce it by doing a kernel build and a "svn checkout" concurrently. No NFS activity. These are running on a local disk (UFS/FFS). (The kernel I reproduce it on is built via GENERIC for i386. If you want me to start a "binary search" for which rNNNNNN, I can do that, but it will take a while.:-) I can get out into DDB, but I'll admit I don't know enough about it to know where to look;-) Here's some lines from "db> ps", in case they give someone useful information. (I can leave this box sitting in DB for the rest of to-day, in case someone can suggest what I should look for on it.) Just snippets... Ss pause adjkerntz DL sdflush [sofdepflush] RL [syncer] DL vlruwt [vnlru] DL psleep [bufdaemon] RL [pagezero] DL psleep [vmdaemon] DL psleep [pagedaemon] DL ccb_scan [xpt_thrd] DL waiting_ [sctp_iterator] DL ctl_work [ctl_thrd] DL cooling [acpi_cooling0] DL tzpoll [acpi_thermal] DL (threaded) [usb] ... DL - [yarrow] DL (threaded) [geom] D - [g_down] D - [g_up] D - [g_event] RL (threaded) [intr] I [irq15: ata1] ... Run CPU0 [swi6: Giant taskq] --> does this one indicate the CPU is actually running this? (after a db> cont, wait a while db> ps it is still the same) I [swi4: clock] I [swi1: netisr 0] I [swi3: vm] RL [idle: cpu0] SLs wait [init] DL audit_wo [audit] DLs (threaded) [kernel] D - [deadlkres] ... D sched [swapper] I have no idea if this "ps" output helps, unless it indicates that it is looping on the Giant taskq? As I said, I can leave it in "db" for to-day, if anyone wants me to do anything in the debugger and I can probably reproduce it, if someone wants stuff tried later. rick > > > adrian > > > On 9 December 2012 22:08, Tim Kientzle wrote: > > I haven't found any useful clues yet, but thought I'd ask if anyone > > else > > was seeing hangs in a recent kernel. > > > > I just upgraded to r244036 using a straight GENERIC i386 kernel. > > (Straight buildworld/buildkernel, no local changes, /etc/src.conf > > doesn't > > exist, /etc/make.conf just has PERL_VERSION defined.) > > > > When I try to cross build an ARM world on the resulting system, > > the entire system hangs hard after about 30 minutes: No network, > > no keyboard response, no nothing. > > > > Don't know if it's relevant, but the system is using NFS pretty > > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > > > I'll try to get some more details ... > > > > Tim > > > > _______________________________________________ > > 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" > _______________________________________________ > 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 Mon Dec 10 18:45:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5ED3A29; Mon, 10 Dec 2012 18:45:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 432818FC12; Mon, 10 Dec 2012 18:45:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBAIjjVC076350; Mon, 10 Dec 2012 20:45:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBAIjjVC076350 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBAIjjuR076349; Mon, 10 Dec 2012 20:45:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Dec 2012 20:45:45 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121210184545.GS3013@kib.kiev.ua> References: <735026206.1290394.1355164701856.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="04FybxbhfaAKXQYm" Content-Disposition: inline In-Reply-To: <735026206.1290394.1355164701856.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 18:45:54 -0000 --04FybxbhfaAKXQYm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > Adrian Chadd wrote: > > .. what was the previous kernel version? > >=20 > Hopefully Tim has it narrowed down more, but I don't see > the hangs on a Sept. 7 kernel from head and I do see them > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) >=20 > It seems to predate my commit (r244008), which was my first > concern. >=20 > I use old single core i386 hardware and can fairly reliably > reproduce it by doing a kernel build and a "svn checkout" > concurrently. No NFS activity. These are running on a local > disk (UFS/FFS). (The kernel I reproduce it on is built via > GENERIC for i386. If you want me to start a "binary search" > for which rNNNNNN, I can do that, but it will take a while.:-) >=20 > I can get out into DDB, but I'll admit I don't know enough > about it to know where to look;-) > Here's some lines from "db> ps", in case they give someone > useful information. (I can leave this box sitting in DB for > the rest of to-day, in case someone can suggest what I should > look for on it.) >=20 > Just snippets... > Ss pause adjkerntz > DL sdflush [sofdepflush] > RL [syncer] > DL vlruwt [vnlru] > DL psleep [bufdaemon] > RL [pagezero] > DL psleep [vmdaemon] > DL psleep [pagedaemon] > DL ccb_scan [xpt_thrd] > DL waiting_ [sctp_iterator] > DL ctl_work [ctl_thrd] > DL cooling [acpi_cooling0] > DL tzpoll [acpi_thermal] > DL (threaded) [usb] > ... > DL - [yarrow] > DL (threaded) [geom] > D - [g_down] > D - [g_up] > D - [g_event] > RL (threaded) [intr] > I [irq15: ata1] > ... > Run CPU0 [swi6: Giant taskq] > --> does this one indicate the CPU is actually running this? > (after a db> cont, wait a while db> ps > it is still the same) > I [swi4: clock] > I [swi1: netisr 0] > I [swi3: vm] > RL [idle: cpu0] > SLs wait [init] > DL audit_wo [audit] > DLs (threaded) [kernel] > D - [deadlkres] > ... > D sched [swapper] >=20 > I have no idea if this "ps" output helps, unless it indicates > that it is looping on the Giant taskq? Might be. You could do 'bt ' for the process to see where it loops. Another good set of hints is at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html >=20 > As I said, I can leave it in "db" for to-day, if anyone wants > me to do anything in the debugger and I can probably reproduce > it, if someone wants stuff tried later. >=20 > rick >=20 >=20 > >=20 > >=20 > > adrian > >=20 > >=20 > > On 9 December 2012 22:08, Tim Kientzle wrote: > > > I haven't found any useful clues yet, but thought I'd ask if anyone > > > else > > > was seeing hangs in a recent kernel. > > > > > > I just upgraded to r244036 using a straight GENERIC i386 kernel. > > > (Straight buildworld/buildkernel, no local changes, /etc/src.conf > > > doesn't > > > exist, /etc/make.conf just has PERL_VERSION defined.) > > > > > > When I try to cross build an ARM world on the resulting system, > > > the entire system hangs hard after about 30 minutes: No network, > > > no keyboard response, no nothing. > > > > > > Don't know if it's relevant, but the system is using NFS pretty > > > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > > > > > I'll try to get some more details ... > > > > > > Tim > > > > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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" > _______________________________________________ > 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" --04FybxbhfaAKXQYm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQxi3ZAAoJEJDCuSvBvK1BTpgP/2t5z4TU//kLmdOplsnr3Nnn Hf29ENQuwj6tMX8KcsFNnHMehbWkGpSzHaSgFW5Ud4AsiYid4rS+l6YZGt5YWxmw U0gX4wa2vmDG72FhhTj9IVQm2O9rBRYM4rdEEc+Gr/CSRIe0Rp2Ia9xC6bHkw017 lZgsepbMMFiLDQkf+1TbwSI8bm/NN2uvByBTzgkg9kTdE8XiNiK8+neeTdhk+QWn PMxeQ7XbNHmFMRbPAZyehoFnx0+/WTTmbT74Ryb2gzDIxUwLXjaZoo3TaMHP1G9a w+7YXrtUU/0mWdGBSUBIFMa3dNnNnD7gY/edkrFqLarDqwZwJ70iwUfvwVU9i8r4 BmNlQhl+E27IlQf2hbdm9JvSpR8pFHFr/vNHPBj5LOtzEfNVAWnNTPHDgD9JxFQ/ eQxceX1ADWcJa6QR6id1q7weTH3g2kjFOQhifMzKdT/nILYFyybMS2aHfKVvTFvP xb6bpUsKE4dvasGRKX4SsPGEwezAoXGobc65YPtklHnfh5k8we89PC8dbr0fqe/Q HR20bmb/PABEy3XRzYYRfq+XJy4vPaleJYnuGTpYpo0pwURNQh+w62dDgXjM6HaS zSFJP5JzUR8dDDhDnzMAcPjblXqV8h8Hb4HGlQ7o7LpF3vFOPXOEFLE3lC2RBWG0 u69ZHe44vz9NtZYbIbBT =W9J8 -----END PGP SIGNATURE----- --04FybxbhfaAKXQYm-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 19:38:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40B4438B; Mon, 10 Dec 2012 19:38:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 114E48FC12; Mon, 10 Dec 2012 19:38:05 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3463EB95D; Mon, 10 Dec 2012 14:38:04 -0500 (EST) From: John Baldwin To: husyh@hush.com Subject: Re: ath0: unable to attach hardware Date: Mon, 10 Dec 2012 14:37:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212041106.50645.jhb@freebsd.org> <20121207095937.ECB38E6726@smtp.hushmail.com> In-Reply-To: <20121207095937.ECB38E6726@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201212101437.54825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Dec 2012 14:38:04 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 19:38:05 -0000 On Friday, December 07, 2012 4:59:37 am husyh@hush.com wrote: > Hello, > > thank you for your answer. > > Unfortunately, I'm unexperienced with FreeBSD, and am absolutely unfamiliar with hardware specifics. During this mail conversion, I have heard abour BAR for the first time, and therefore, I know neither what exactly I should do (e.g. how I can find the start of bar, which register offsets would be interesting, etc.), nor what the results would tell me. > > I'm sorry if I'm tedious, but I would be very grateful if you could provide some more guidance. > > Thank you very much! Adrian should be able to do that for you. He knows which registers he wants to see. > On Dienstag, 4. Dezember 2012 at 7:43 PM, "John Baldwin" wrote: > > > >On Friday, November 23, 2012 5:56:02 pm Adrian Chadd wrote: > >> Thanks for this! > >> > >> I'm sorry it hasn't gotten any more attention. I've cc'ed john > >because > >> he understands the PCI-PCI resource allocation stuff and I > >currently > >> don't; I'm hoping he can stare at this and see what's going on. > >> > >> But yes, if it were an ath(4) problem, the NIC would be returning > >> 0xdeadbeef, 0xdeadc0de, etc. It wouldn't return 0xffffffff - that > >> happens when there's nothing mapped at that address. > >> > >> The PCI config space that you've provided shows BAR(0) is > >programmed > >correctly.. > > > >Your dmesg shows that another device behind the same PCI-PCI > >bridge is working > >fine (fxp0), so the bridge is configured correctly. Also, the PCI > >command > >register for ath0 has memory decoding enabled, so everything > >should be fine > >from PCI's perspective. Note that if you want to examine specific > >registers > >you can use dd with /dev/mem (albeit carefully), e.g. > > > > dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) > >count=1 | hd > > > >to read a single 32-bit register. I think that the card is in > >fact returning > >the value you see from its registers. I would do some reads of > >other > >registers using dd to see if all of the device registers are > >returning -1 or > >if only certain registers are. > > > >-- > >John Baldwin > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 20:29:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28398ECB for ; Mon, 10 Dec 2012 20:29:45 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id B04F88FC13 for ; Mon, 10 Dec 2012 20:29:44 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ti9z5-0001fc-Dt for freebsd-current@freebsd.org; Mon, 10 Dec 2012 21:29:51 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 21:29:51 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 21:29:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Date: Mon, 10 Dec 2012 12:29:20 -0800 Lines: 190 Message-ID: References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> <20121210182525.GR3013@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <20121210182525.GR3013@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Cc: kde-freebsd@freebsd.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 20:29:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2012 10:25, Konstantin Belousov wrote: > On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: On > 12/07/2012 09:29, Dimitry Andric wrote: >>>> On 2012-12-07 17:43, Mark Atkinson wrote: >>>>> On 12/7/2012 6:08 AM, Dimitry Andric wrote: >>>> ... >>>>>> With this patch (placed in >>>>>> /usr/ports/devel/dbus-qt4/files), qdbus starts up and >>>>>> exits normally for me. I did not do any other rigorous >>>>>> testing, though. :) >>>>> >>>>> Thanks for the awesome analysis. I will endeavor to figure >>>>> out the bug in automoc4 that keeps it segfaulting randomly >>>>> during compilation. >>>>> >>>>> Weirdly it segfaults reliably under portmaster, but may >>>>> work just fine under just make. >>>> >>>> Try running it under valgrind. If it does undefined things, >>>> it may work or not work randomly, and valgrind usually >>>> catches this. > > OK, so this one's a bit of a headscratcher, but maybe someone has > some ideas. automoc4 always dies in libthr. >> Build rtld, libc and libthr with the debug symbols to get useful >> backtrace. > > > #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread > 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP > 101795/automoc4.bin)] (gdb) bt #0 0x2864b1da in swapcontext () > from /lib/libthr.so.3 #1 0x2864a046 in pthread_getspecific () from > /lib/libthr.so.3 #2 0x28649e9a in pthread_getspecific () from > /lib/libthr.so.3 #3 0x2864dbfb in pthread_kill () from > /lib/libthr.so.3 #4 0x28064e71 in _rtld_get_stack_prot () from > /libexec/ld-elf.so.1 #5 0x2865d500 in _thread_state_running () > from /lib/libthr.so.3 #6 0x2865d500 in _thread_state_running () > from /lib/libthr.so.3 #7 0x28075e00 in ?? () #8 0x286b4d30 in > pipe () from /lib/libc.so.7 #9 0x280712ac in ?? () from > /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in > r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? () > from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in > ?? () #15 0x00000001 in ?? () #16 0x00000000 in ?? () (gdb) thread > 2 [Switching to thread 2 (Thread 29003080 (LWP > 101795/automoc4.bin))]#0 0x2876c3a7 in select () from > /lib/libc.so.7 (gdb) bt #0 0x2876c3a7 in select () from > /lib/libc.so.7 #1 0x286481ab in select () from /lib/libthr.so.3 #2 > 0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090, > fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at > kernel/qcore_unix.cpp:83 #3 0x282c23b2 in select_msecs (nfds=17, > fdread=0xbfbfa090, fdwrite=0xbfbfa010, timeout=-1) at > io/qprocess_unix.cpp:998 #4 0x282c33f3 in > QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at > io/qprocess_unix.cpp:1219 #5 0x28240b50 in > QProcess::waitForFinished (this=0xbfbfa1e8, msecs=-1) at > io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor > (this=0xbfbfab00, msg=@0xbfbfa2e0) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 > #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00, > sourceFile=@0x29011658, mocFileName=@0x2901165c) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 > #8 0x0804f13b in AutoMoc::run (this=0xbfbfab00) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #9 0x0804aaef in main (argc=6, argv=0xbfbfab98) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 > > I noticed that qt_safe_select() used a register bound variable for > the return value, but removing that didn't alleviate the error. > > The pthread_getspecific() manpage mentions that if the key is > deleted then the behavior is undefined -- so maybe this? It's > definitely seems like a race condition of some kind. > > Valgrind will kill any run of automoc4 and doesn't like some > instruction after the qt_safe_select() call: > > vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 >> This is ud2, an instruction which generates a fault on purpose. > >> So rebuild the system libraries with the debug symbols and show >> the backtrace. Hmm. Since I took out -O2 and added -g in rebuilding libthr/libc/rtld, I figured I needed to reproduce a new segfault, but the rtld side of things seems broken: #0 0xbf9fd01a in ?? () [New Thread 29003800 (LWP 100652/automoc4.bin)] [New Thread 29003080 (LWP 101395/automoc4.bin)] (gdb) bt #0 0xbf9fd01a in ?? () #1 0xbf9fcd20 in ?? () #2 0x00000000 in ?? () (gdb) info thread 2 Thread 29003080 (LWP 101395/automoc4.bin) select () at select.S:3 * 1 Thread 29003800 (LWP 100652/automoc4.bin) 0xbf9fd01a in ?? () Current language: auto; currently asm (gdb) thread 2 [Switching to thread 2 (Thread 29003080 (LWP 101395/automoc4.bin))]#0 select () at select.S:3 3 RSYSCALL(select) (gdb) bt #0 select () at select.S:3 #1 0x28659028 in __select (numfds=17, readfds=0xbfbfc1f0, writefds=0xbfbfc170, exceptfds=0x0, timeout=0x0) at /usr/src/lib/libthr/thread/thr_syscalls.c:539 #2 0x28372c49 in qt_safe_select (nfds=17, fdread=0xbfbfc1f0, fdwrite=0xbfbfc170, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:83 #3 0x282cf3b2 in select_msecs (nfds=17, fdread=0xbfbfc1f0, fdwrite=0xbfbfc170, timeout=-1) at io/qprocess_unix.cpp:998 #4 0x282d03f3 in QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at io/qprocess_unix.cpp:1219 #5 0x2824db50 in QProcess::waitForFinished (this=0xbfbfc348, msecs=-1) at io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor (this=0xbfbfcc60, msg=@0xbfbfc440) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 #7 0x08052650 in AutoMoc::generateMoc (this=0xbfbfcc60, sourceFile=@0x29011638, mocFileName=@0x2901163c) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #8 0x0804f13b in AutoMoc::run (this=0xbfbfcc60) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #9 0x0804aaef in main (argc=6, argv=0xbfbfccfc) at /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 (gdb) thread 1 [Switching to thread 1 (Thread 29003800 (LWP 100652/automoc4.bin))]#0 0xbf9fd01a in ?? () (gdb) bt #0 0xbf9fd01a in ?? () #1 0xbf9fcd20 in ?? () #2 0x00000000 in ?? () (gdb) frame 0 #0 0xbf9fd01a in ?? () (gdb) info reg eax 0x0 0 ecx 0x286d7ddb 678264283 edx 0x0 0 ebx 0xbf9fd058 -1080045480 esp 0xbf9fcd1c 0xbf9fcd1c ebp 0x14 0x14 esi 0x2865c563 677758307 edi 0x2869f2ec 678032108 eip 0xbf9fd01a 0xbf9fd01a eflags 0x210246 2163270 cs 0x33 51 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x3b 59 gs 0x1b 27 > ==33074== valgrind: Unrecognised instruction at address > 0x380434e9. ==33074== at 0x380434E9: ??? (in > /usr/local/lib/valgrind/memcheck-x86-freebsd) ==33074== by > 0x323C48: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval > const*) (qcore_unix.cpp:83) ==33074== by 0x2803B1: > select_msecs(int, fd_set*, fd_set*, int) (qprocess_unix.cpp:998) > ==33074== by 0x28021D: QProcessPrivate::waitForStarted(int) > (qprocess_unix.cpp:1031) ==33074== by 0x1FFA02: > QProcess::waitForStarted(int) (qprocess.cpp:1687) ==33074== by > 0x1FEAEA: QProcess::waitForFinished(int) (qprocess.cpp:1752) > ==33074== by 0x805487A: AutoMoc::echoColor(QString const&) > (kde4automoc.cpp:74) ==33074== by 0x805264F: > AutoMoc::generateMoc(QString const&, QString const&) > (kde4automoc.cpp:569) ==33074== by 0x804F13A: AutoMoc::run() > (kde4automoc.cpp:470) ==33074== by 0x804AAEE: main > (kde4automoc.cpp:114) > > Full valgrind output is at http://pastebin.com/KQTKYGX5 > >> >> _______________________________________________ >> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDGRiAACgkQrDN5kXnx8yYJFQCgkMYOxkIfFibTaPNOkikw+0Ki t3YAoJTCIYecBmk7LT1ehsdQzwhm1Uif =4Ars -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 20:33:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55E1F120 for ; Mon, 10 Dec 2012 20:33:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9018FC1B for ; Mon, 10 Dec 2012 20:33:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBAKXVRU086645; Mon, 10 Dec 2012 22:33:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBAKXVRU086645 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBAKXV2v086644; Mon, 10 Dec 2012 22:33:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Dec 2012 22:33:31 +0200 From: Konstantin Belousov To: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Message-ID: <20121210203331.GV3013@kib.kiev.ua> References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> <20121210182525.GR3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V7svHyRZ5yxp1ETC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, kde-freebsd@spider.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 20:33:38 -0000 --V7svHyRZ5yxp1ETC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 12:29:20PM -0800, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 12/10/2012 10:25, Konstantin Belousov wrote: > > On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: On > > 12/07/2012 09:29, Dimitry Andric wrote: > >>>> On 2012-12-07 17:43, Mark Atkinson wrote: > >>>>> On 12/7/2012 6:08 AM, Dimitry Andric wrote: > >>>> ... > >>>>>> With this patch (placed in > >>>>>> /usr/ports/devel/dbus-qt4/files), qdbus starts up and > >>>>>> exits normally for me. I did not do any other rigorous > >>>>>> testing, though. :) > >>>>>=20 > >>>>> Thanks for the awesome analysis. I will endeavor to figure > >>>>> out the bug in automoc4 that keeps it segfaulting randomly > >>>>> during compilation. > >>>>>=20 > >>>>> Weirdly it segfaults reliably under portmaster, but may > >>>>> work just fine under just make. > >>>>=20 > >>>> Try running it under valgrind. If it does undefined things, > >>>> it may work or not work randomly, and valgrind usually > >>>> catches this. > >=20 > > OK, so this one's a bit of a headscratcher, but maybe someone has > > some ideas. automoc4 always dies in libthr. > >> Build rtld, libc and libthr with the debug symbols to get useful=20 > >> backtrace. > >=20 > >=20 > > #0 0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread > > 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP > > 101795/automoc4.bin)] (gdb) bt #0 0x2864b1da in swapcontext () > > from /lib/libthr.so.3 #1 0x2864a046 in pthread_getspecific () from > > /lib/libthr.so.3 #2 0x28649e9a in pthread_getspecific () from > > /lib/libthr.so.3 #3 0x2864dbfb in pthread_kill () from > > /lib/libthr.so.3 #4 0x28064e71 in _rtld_get_stack_prot () from > > /libexec/ld-elf.so.1 #5 0x2865d500 in _thread_state_running () > > from /lib/libthr.so.3 #6 0x2865d500 in _thread_state_running () > > from /lib/libthr.so.3 #7 0x28075e00 in ?? () #8 0x286b4d30 in > > pipe () from /lib/libc.so.7 #9 0x280712ac in ?? () from > > /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in > > r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? () > > from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in > > ?? () #15 0x00000001 in ?? () #16 0x00000000 in ?? () (gdb) thread > > 2 [Switching to thread 2 (Thread 29003080 (LWP > > 101795/automoc4.bin))]#0 0x2876c3a7 in select () from > > /lib/libc.so.7 (gdb) bt #0 0x2876c3a7 in select () from > > /lib/libc.so.7 #1 0x286481ab in select () from /lib/libthr.so.3 #2 > > 0x28365c49 in qt_safe_select (nfds=3D17, fdread=3D0xbfbfa090,=20 > > fdwrite=3D0xbfbfa010, fdexcept=3D0x0, orig_timeout=3D0x0) at=20 > > kernel/qcore_unix.cpp:83 #3 0x282c23b2 in select_msecs (nfds=3D17, > > fdread=3D0xbfbfa090, fdwrite=3D0xbfbfa010, timeout=3D-1) at > > io/qprocess_unix.cpp:998 #4 0x282c33f3 in > > QProcessPrivate::waitForFinished (this=3D0x29089300, msecs=3D-1) at > > io/qprocess_unix.cpp:1219 #5 0x28240b50 in > > QProcess::waitForFinished (this=3D0xbfbfa1e8, msecs=3D-1) at > > io/qprocess.cpp:1759 #6 0x0805487b in AutoMoc::echoColor > > (this=3D0xbfbfab00, msg=3D@0xbfbfa2e0) at=20 > > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74=20 > > #7 0x08052650 in AutoMoc::generateMoc (this=3D0xbfbfab00,=20 > > sourceFile=3D@0x29011658, mocFileName=3D@0x2901165c) at=20 > > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569=20 > > #8 0x0804f13b in AutoMoc::run (this=3D0xbfbfab00) at=20 > > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470=20 > > #9 0x0804aaef in main (argc=3D6, argv=3D0xbfbfab98) at=20 > > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 > >=20 > > I noticed that qt_safe_select() used a register bound variable for > > the return value, but removing that didn't alleviate the error. > >=20 > > The pthread_getspecific() manpage mentions that if the key is > > deleted then the behavior is undefined -- so maybe this? It's > > definitely seems like a race condition of some kind. > >=20 > > Valgrind will kill any run of automoc4 and doesn't like some=20 > > instruction after the qt_safe_select() call: > >=20 > > vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 > >> This is ud2, an instruction which generates a fault on purpose. > >=20 > >> So rebuild the system libraries with the debug symbols and show=20 > >> the backtrace. >=20 > Hmm. Since I took out -O2 and added -g in rebuilding > libthr/libc/rtld, I figured I needed to reproduce a new segfault, but > the rtld side of things seems broken: Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=3D-g clean all install This is really FAQ. >=20 > #0 0xbf9fd01a in ?? () > [New Thread 29003800 (LWP 100652/automoc4.bin)] > [New Thread 29003080 (LWP 101395/automoc4.bin)] > (gdb) bt > #0 0xbf9fd01a in ?? () > #1 0xbf9fcd20 in ?? () > #2 0x00000000 in ?? () > (gdb) info thread > 2 Thread 29003080 (LWP 101395/automoc4.bin) select () at select.S:3 > * 1 Thread 29003800 (LWP 100652/automoc4.bin) 0xbf9fd01a in ?? () > Current language: auto; currently asm > (gdb) thread 2 > [Switching to thread 2 (Thread 29003080 (LWP 101395/automoc4.bin))]#0 > select () at select.S:3 > 3 RSYSCALL(select) > (gdb) bt > #0 select () at select.S:3 > #1 0x28659028 in __select (numfds=3D17, readfds=3D0xbfbfc1f0, > writefds=3D0xbfbfc170, exceptfds=3D0x0, timeout=3D0x0) at > /usr/src/lib/libthr/thread/thr_syscalls.c:539 > #2 0x28372c49 in qt_safe_select (nfds=3D17, fdread=3D0xbfbfc1f0, > fdwrite=3D0xbfbfc170, fdexcept=3D0x0, orig_timeout=3D0x0) at > kernel/qcore_unix.cpp:83 > #3 0x282cf3b2 in select_msecs (nfds=3D17, fdread=3D0xbfbfc1f0, > fdwrite=3D0xbfbfc170, timeout=3D-1) at io/qprocess_unix.cpp:998 > #4 0x282d03f3 in QProcessPrivate::waitForFinished (this=3D0x29089300, > msecs=3D-1) at io/qprocess_unix.cpp:1219 > #5 0x2824db50 in QProcess::waitForFinished (this=3D0xbfbfc348, > msecs=3D-1) at io/qprocess.cpp:1759 > #6 0x0805487b in AutoMoc::echoColor (this=3D0xbfbfcc60, > msg=3D@0xbfbfc440) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 > #7 0x08052650 in AutoMoc::generateMoc (this=3D0xbfbfcc60, > sourceFile=3D@0x29011638, mocFileName=3D@0x2901163c) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 > #8 0x0804f13b in AutoMoc::run (this=3D0xbfbfcc60) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #9 0x0804aaef in main (argc=3D6, argv=3D0xbfbfccfc) at > /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 > (gdb) thread 1 > [Switching to thread 1 (Thread 29003800 (LWP 100652/automoc4.bin))]#0 > 0xbf9fd01a in ?? () > (gdb) bt > #0 0xbf9fd01a in ?? () > #1 0xbf9fcd20 in ?? () > #2 0x00000000 in ?? () > (gdb) frame 0 > #0 0xbf9fd01a in ?? () > (gdb) info reg > eax 0x0 0 > ecx 0x286d7ddb 678264283 > edx 0x0 0 > ebx 0xbf9fd058 -1080045480 > esp 0xbf9fcd1c 0xbf9fcd1c > ebp 0x14 0x14 > esi 0x2865c563 677758307 > edi 0x2869f2ec 678032108 > eip 0xbf9fd01a 0xbf9fd01a > eflags 0x210246 2163270 > cs 0x33 51 > ss 0x3b 59 > ds 0x3b 59 > es 0x3b 59 > fs 0x3b 59 > gs 0x1b 27 >=20 >=20 > > =3D=3D33074=3D=3D valgrind: Unrecognised instruction at address > > 0x380434e9. =3D=3D33074=3D=3D at 0x380434E9: ??? (in=20 > > /usr/local/lib/valgrind/memcheck-x86-freebsd) =3D=3D33074=3D=3D by > > 0x323C48: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval > > const*) (qcore_unix.cpp:83) =3D=3D33074=3D=3D by 0x2803B1: > > select_msecs(int, fd_set*, fd_set*, int) (qprocess_unix.cpp:998)=20 > > =3D=3D33074=3D=3D by 0x28021D: QProcessPrivate::waitForStarted(int)= =20 > > (qprocess_unix.cpp:1031) =3D=3D33074=3D=3D by 0x1FFA02: > > QProcess::waitForStarted(int) (qprocess.cpp:1687) =3D=3D33074=3D=3D = by > > 0x1FEAEA: QProcess::waitForFinished(int) (qprocess.cpp:1752)=20 > > =3D=3D33074=3D=3D by 0x805487A: AutoMoc::echoColor(QString const&)= =20 > > (kde4automoc.cpp:74) =3D=3D33074=3D=3D by 0x805264F: > > AutoMoc::generateMoc(QString const&, QString const&) > > (kde4automoc.cpp:569) =3D=3D33074=3D=3D by 0x804F13A: AutoMoc::run() > > (kde4automoc.cpp:470) =3D=3D33074=3D=3D by 0x804AAEE: main > > (kde4automoc.cpp:114) > >=20 > > Full valgrind output is at http://pastebin.com/KQTKYGX5 > >=20 > >>=20 > >> _______________________________________________=20 > >> freebsd-current@freebsd.org mailing list=20 > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current To > >> unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlDGRiAACgkQrDN5kXnx8yYJFQCgkMYOxkIfFibTaPNOkikw+0Ki > t3YAoJTCIYecBmk7LT1ehsdQzwhm1Uif > =3D4Ars > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > 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" --V7svHyRZ5yxp1ETC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQxkcaAAoJEJDCuSvBvK1BBIEQAKJ7/AcTVwKvufr3co5PTW7y NvfsTyvJoOLEcHvme2gi4WX+cC/wZPpnRvCZ/of3hZG6VxImi2ABdlzbmcmnhaLA 7ws/mu8onQyXLtZF8r1r2I/SLAWyxtPXjyXZTwDcIyFFCAaKYXRJ4D/N+7lXHwqC 5RfSkTyIeRRqJZ+7L2M2DBqPkk8MXtsXKhkXHj2GzY8aM1KbQSRQ50axLXNIkr/R DVptmdR0hWiTJRbpyZKosi3ikCMjLjf5aU2s/ry36VEI5fT0so25JV7smE7rKm33 1AJHQSy+uz56zEpzIURGEvEUsYvVkb/TleGV7QXzdrw5pxPnkx3W/IwssErqzWjC KP4zG/5A7cAaroshX3ICf5Ya3Dad6EQe+jxoHGiGEV2UBzyEwzbnj4E3oL65TfCA ycXB3WRv7W3D9xfjZrMiIXGXwvTDL6Qbo2Atspjw12ScMCxlRjucbGoYQvjGmiPM wix5zBbY1NPFvr+BLC2c9dTI0+0Oe/XcDC3QT5lWTD9zsMZ7htloZmJlouwwWgFS yw7aRVKNyhxGQpiry6MLKnW/DZih9tUD84tBMq3ymEFsE7DIineHVPyQnUS6pf2R 3CxRla+iMOUlauhT4sc3TINTYAJaAVlYsJzX7UE1a+5aKTqZQx0EEiHLfWnYcdJU LzWCwMMhE5ZciQRbVQ49 =ZNYA -----END PGP SIGNATURE----- --V7svHyRZ5yxp1ETC-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 20:45:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5503960A for ; Mon, 10 Dec 2012 20:45:37 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id F3A8E8FC14 for ; Mon, 10 Dec 2012 20:45:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TiAET-0007LE-Eh for freebsd-current@freebsd.org; Mon, 10 Dec 2012 21:45:45 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 21:45:45 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 21:45:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Date: Mon, 10 Dec 2012 12:45:23 -0800 Lines: 38 Message-ID: References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> <20121210182525.GR3013@kib.kiev.ua> <20121210203331.GV3013@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <20121210203331.GV3013@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Cc: kde-freebsd@freebsd.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 20:45:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2012 12:33, Konstantin Belousov wrote: > Hmm. Since I took out -O2 and added -g in rebuilding > libthr/libc/rtld, I figured I needed to reproduce a new segfault, > but the rtld side of things seems broken: >> Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=-g clean all >> install This is really FAQ. It _is_ strange, because I did almost exactly that (dumped a temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf) The one I had problems with was libc since It needs a make depend in there. $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges contains: Length: 28 Version: 2 Offset into .debug_info: 0 Pointer Size: 4 Segment Size: 0 Address Length 0x00000e80 0x49 $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlDGSeMACgkQrDN5kXnx8yYb6QCfQFO6o/At+srdpuRfI8jGCnqu ZJMAlir1UvA4mgE0k2ewP43ayPiepCM= =YVai -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:13:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F61AC79 for ; Mon, 10 Dec 2012 21:13:44 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id B28898FC08 for ; Mon, 10 Dec 2012 21:13:43 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TiAfg-0006eE-SH for freebsd-current@freebsd.org; Mon, 10 Dec 2012 22:13:52 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 22:13:52 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Dec 2012 22:13:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Date: Mon, 10 Dec 2012 13:13:23 -0800 Lines: 72 Message-ID: References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> <20121210182525.GR3013@kib.kiev.ua> <20121210203331.GV3013@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: X-Enigmail-Version: 1.4.6 Cc: kde-freebsd@freebsd.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 21:13:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2012 12:45, Mark Atkinson wrote: > On 12/10/2012 12:33, Konstantin Belousov wrote: > >> Hmm. Since I took out -O2 and added -g in rebuilding >> libthr/libc/rtld, I figured I needed to reproduce a new >> segfault, but the rtld side of things seems broken: >>> Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=-g clean >>> all install This is really FAQ. > > > It _is_ strange, because I did almost exactly that (dumped a > temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf) > > The one I had problems with was libc since It needs a make depend > in there. > > $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges > contains: > > Length: 28 Version: 2 Offset > into .debug_info: 0 Pointer Size: 4 Segment Size: > 0 > > Address Length 0x00000e80 0x49 $ So ignoring this weirdness, running under valgrind always segfaults and the core seems useful. #0 0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20, info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198 #1 0x0061b71c in thr_sighandler (sig=20, info=0xbf9fd7b0, _ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:182 #2 0x380434dc in ?? () #3 0x00000014 in ?? () #4 0xbf9fd7b0 in ?? () #5 0x00000000 in ?? () (gdb) frame 0 #0 0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20, info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198 198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask); (gdb) list 193 int cancel_enable; 194 int in_sigsuspend; 195 int err; 196 197 /* add previous level mask */ 198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask); 199 200 /* add this signal's mask */ 201 if (!(actp->sa_flags & SA_NODEFER)) 202 SIGADDSET(actp->sa_mask, sig); (gdb) p actp $1 = (struct sigaction *) 0xbf9fd490 (gdb) p *actp $2 = {__sigaction_u = {__sa_handler = 0x288310 , __sa_sigaction = 0x288310 }, sa_flags = 8, sa_mask = {__bits = {0, 0, 0, 0}}} (gdb) p *ucp Cannot access memory at address 0x0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z X7UAn1ea4LbW8PHXL07BwraiVXakh1bU =GktK -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:23:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 948AD1F8 for ; Mon, 10 Dec 2012 21:23:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 02D9E8FC19 for ; Mon, 10 Dec 2012 21:23:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBALNZA8091574; Mon, 10 Dec 2012 23:23:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBALNZA8091574 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBALNZQH091573; Mon, 10 Dec 2012 23:23:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Dec 2012 23:23:35 +0200 From: Konstantin Belousov To: Mark Atkinson Subject: Re: problems with threads/destructors in -current with llvm/clang Message-ID: <20121210212335.GW3013@kib.kiev.ua> References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> <20121210182525.GR3013@kib.kiev.ua> <20121210203331.GV3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xb2rXNyfy/tCyg2t" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, kde-freebsd@spider.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 21:23:44 -0000 --xb2rXNyfy/tCyg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 01:13:23PM -0800, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 12/10/2012 12:45, Mark Atkinson wrote: > > On 12/10/2012 12:33, Konstantin Belousov wrote: > >=20 > >> Hmm. Since I took out -O2 and added -g in rebuilding=20 > >> libthr/libc/rtld, I figured I needed to reproduce a new > >> segfault, but the rtld side of things seems broken: > >>> Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=3D-g clean > >>> all install This is really FAQ. > >=20 > >=20 > > It _is_ strange, because I did almost exactly that (dumped a > > temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf) > >=20 > > The one I had problems with was libc since It needs a make depend > > in there. > >=20 > > $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges > > contains: > >=20 > > Length: 28 Version: 2 Offset > > into .debug_info: 0 Pointer Size: 4 Segment Size: > > 0 > >=20 > > Address Length 0x00000e80 0x49 $ >=20 > So ignoring this weirdness, running under valgrind always segfaults > and the core seems useful. >=20 > #0 0x0061bd59 in handle_signal (actp=3D0xbf9fd490, sig=3D20, > info=3D0xbf9fd7b0, ucp=3D0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198 > #1 0x0061b71c in thr_sighandler (sig=3D20, info=3D0xbf9fd7b0, _ucp=3D0x0) > at /usr/src/lib/libthr/thread/thr_sig.c:182 > #2 0x380434dc in ?? () > #3 0x00000014 in ?? () > #4 0xbf9fd7b0 in ?? () > #5 0x00000000 in ?? () > (gdb) frame 0 > #0 0x0061bd59 in handle_signal (actp=3D0xbf9fd490, sig=3D20, > info=3D0xbf9fd7b0, ucp=3D0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198 > 198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask); > (gdb) list > 193 int cancel_enable; > 194 int in_sigsuspend; > 195 int err; > 196 > 197 /* add previous level mask */ > 198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask); > 199 > 200 /* add this signal's mask */ > 201 if (!(actp->sa_flags & SA_NODEFER)) > 202 SIGADDSET(actp->sa_mask, sig); >=20 > (gdb) p actp > $1 =3D (struct sigaction *) 0xbf9fd490 > (gdb) p *actp > $2 =3D {__sigaction_u =3D {__sa_handler =3D 0x288310 > , __sa_sigaction =3D 0x288310 > }, sa_flags =3D 8, sa_mask =3D {__bits =3D {0, > 0, 0, 0}}} > (gdb) p *ucp > Cannot access memory at address 0x0 This looks like a valgrind problem, because kernel correctly passes fourth argument to the signal handler frame. Or rather, the signal trampoline and kernel properly pass ucontext to signal handler. If this appear to be broken, the signal trampoline would cause the fault on the signal return, even for the single-threaded processes. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z > X7UAn1ea4LbW8PHXL07BwraiVXakh1bU > =3DGktK > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > 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" --xb2rXNyfy/tCyg2t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQxlLVAAoJEJDCuSvBvK1BKMoP/iqpI155z0EWe+b+eqMKBRD0 WpuwImlZsBYHGwe7zdOVTNpWLRKXBDj8Mh3ZiG9aHk5coXVQcRnqh52l2fVYJ8P9 0F3GxyEnoI/dfWDBhfo84IJ0osx8tnpQbIszBoQROqymzzu+RoP7E3XWJZBzAdqj iPvF/G8nrDgyD7dCRjMEljo76d3obMnTUdQK1cdGUInh8s5qA6l2hHzCBaODIZdu 8aLidMkDvvKEgaqVXfaDbTcP3Jt6YG1hg4FmWPw7D+HCLM5fyZN+yLyyXjcCqDkC stiIYLikRVVohzPubSmH1NQUWL/YI4cO+hLssqvRTejSW/RRnmWJXo3nd1MYuT6h zA6WECrHqpJJy3IlH58VMIoszc3ujbQfwL38xCgyuHPv+XaTyuVSl6tlWevZeHKl My7TwOLHwnnR26Uv+hvN6JTe5oERfN6yKxi2RNGjZ9wXY9zod3uXkq3yyBBc8xLB MXXcL823ItL90w54bPkdR8YvQ8lChNndAKrY9gevh+H219eVLKPUs7u4F4ekIGYQ d85QM7eUzDh/uU3dNXCQU3UnILN3BK4XCUjUEBGQosMJ5yoow3/UNK94DQkB7vOq EOs6AIq4EAKmI/8k0ToSsf+wW3Y9jCyJqShxGFf4664VqUsU74piEgQRJInIwHdc GiYjhSPnf089m81cw76W =34Tq -----END PGP SIGNATURE----- --xb2rXNyfy/tCyg2t-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:25:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFE6433A; Mon, 10 Dec 2012 21:25:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDEE8FC08; Mon, 10 Dec 2012 21:25:36 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3913693oag.13 for ; Mon, 10 Dec 2012 13:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=puQJ8paCKH0/UopSYfLLJtY4A5w7MFlVHgRBEl8sMoo=; b=Jd6g8r4Ep3wYxoJTIpaiW8oZdPPWSIFY/jfeA8+b6ZzlzfduwvaeqvchjSs0nztlqf p4ydNcITrFXB88HIcounV5Fawe1/sPN+G7RprRmwN8q9LcP1kAsgR6VBXN8zB2zMGYs4 43xd+xKA2L5JepoxdFwB3ob5mDfjCS9NIl3eRvS7zXv1j9edNs96G/HtyYlmFXemXA+4 c/Q8eVXWIPi5u2QX3uNJAwCvGc9hKQVwaRvG/rjvjztSOj0NZSDNDwHmLIJGSfjpuafL qo4zFRpNXg4HQhXKl/QjETkm2iQpENbpy28iuQs9eUOLhz3EFUS0hKMROPy2o9eN5ydZ O1lw== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr8319694oeg.17.1355174730246; Mon, 10 Dec 2012 13:25:30 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 13:25:30 -0800 (PST) In-Reply-To: References: <50B6598B.20200@FreeBSD.org> Date: Mon, 10 Dec 2012 13:25:30 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 21:25:37 -0000 On Thu, Dec 6, 2012 at 4:55 PM, Garrett Cooper wrote: ... > (Removing bogus list) > > If I try and let it import the pool at boot it claims the pool is in a > FAULTED state when I point mountroot to /dev/cd0 (one of gjb's > snapshot CDs -- thanks!), run service hostid onestart, etc. If I > export and try to reimport the pool it claims it's not available (!). > However, if I boot, run service hostid onestart, _then_ import the > pool, then the pool is imported properly. > > While I was mucking around with the pool trying to get the system to > boot I set the cachefile attribute to /boot/zfs/zpool.cache before > upgrading. In order to diagnose whether or not that was at fault, I > set that back to none and I'm still running into the same issue. > > I'm going to try backing out your commit and rebuild my kernel in > order to determine whether or not that's at fault. > > One other thing: both my machines have more than one ZFS-only zpool, > and it might be probing the pools in the wrong order; one of the pools > has bootfs set, the other doesn't, and the behavior is sort of > resembling it not being set properly. I reverted the following commits with no change. Thanks, -Garrett commit 969475c599c9cd5095012f47c25faef914b63a45 Author: Garrett Cooper Date: Wed Dec 5 23:48:06 2012 -0800 Don't define the TESTSDIR if it's empty The problem is that items like lib/crypt/tests with empty TESTSDIRS will blow up the build if make installworld is run with the modifications made to bsd.subdir.mk . Signed-off-by: Garrett Cooper commit 7a1c6d1a406d78810db56e5a8915d9ec945f546c Author: avg Date: Sat Nov 24 13:23:15 2012 +0000 zfs roopool: add support for multi-vdev configurations Tested by: madpilot MFC after: 10 days commit 7ad1a2bc4c09f0635d5f7216a8e96703cd70f371 Author: avg Date: Sat Nov 24 13:16:49 2012 +0000 spa_import_rootpool: initialize ub_version before calling spa_config_parse ... because the latter makes some decision based on the version. This is especially important for raidz vdevs. This is similar to what spa_load does. This is not an issue for upstream because they do not seem to support using raidz as a root pool. Reported by: Andrei Lavreniyuk Tested by: Andrei Lavreniyuk MFC after: 6 days commit 574c22111b5590734e10a02b2b7d27a290b38148 Author: avg Date: Sat Nov 24 13:14:53 2012 +0000 spa_import_rootpool: do not call spa_history_log_version The call is a NOP, because pool version in spa_ubsync.ub_version is not initialized and thus appears to be zero. If the version is properly set then the call leads to a NULL pointer dereference because the spa object is still under-constructed. The same change was independently made in the upstream as a part of a larger change (4445fffbbb1ea25fd0e9ea68b9380dd7a6709025). MFC after: 6 days From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 22:06:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3D336C for ; Mon, 10 Dec 2012 22:06:20 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1918FC08 for ; Mon, 10 Dec 2012 22:06:20 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so3931310vba.13 for ; Mon, 10 Dec 2012 14:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7SxpJZnNx4AukYuUPmh9M0Yvqmhg9LUhBNL9/gL094=; b=lqhhGhUF2MB/5cLFnmAbAMun9v7EwoxdOX55y9Loa68ZaFneNcchQ+T/u8mdKIpv6m gD0IlLRw+JWLWq5BxZHIF9y8KuWZOvkSsa1WfdLb3m/WZ4CX7/lkmYNFiAdqsfiJWZlq hRoGFAZo/8mho/HILuWMEyOZfGxp9qpfSFzzt1dR1QQYIfEcKws/ZdPIpZujAjreeRcy oZxKklgcvUNpK8smq/o1egotohSdxyoiN3lrOYN0zzxVJerCLC9BjKBPNzHXp/U7ZzgF YcjkEZ7K5JDxoD4zqf/JzM6ITwen+wITSr/drtI0Xt45GTbciGVBxXxH6jZXsVSU3bDm 9quQ== MIME-Version: 1.0 Received: by 10.58.240.107 with SMTP id vz11mr10148478vec.45.1355177179725; Mon, 10 Dec 2012 14:06:19 -0800 (PST) Received: by 10.58.207.114 with HTTP; Mon, 10 Dec 2012 14:06:19 -0800 (PST) In-Reply-To: References: <50C1E81A.1040107@FreeBSD.org> <50C1F862.2010501@FreeBSD.org> <50C22789.3030303@FreeBSD.org> Date: Mon, 10 Dec 2012 17:06:19 -0500 Message-ID: Subject: Re: problems with threads/destructors in -current with llvm/clang From: Ryan Stone To: Mark Atkinson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , kde-freebsd@freebsd.kde.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 22:06:20 -0000 On Mon, Dec 10, 2012 at 12:35 PM, Mark Atkinson wrote: > vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 > ==33074== valgrind: Unrecognised instruction at address 0x380434e9. > ==33074== at 0x380434E9: ??? (in > /usr/local/lib/valgrind/memcheck-x86-freebsd) > ==33074== by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, > fd_set*, timeval const*) (qcore_unix.cpp:83) > ==33074== by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) > (qprocess_unix.cpp:998) > ==33074== by 0x28021D: QProcessPrivate::waitForStarted(int) > (qprocess_unix.cpp:1031) > ==33074== by 0x1FFA02: QProcess::waitForStarted(int) > (qprocess.cpp:1687) > ==33074== by 0x1FEAEA: QProcess::waitForFinished(int) > (qprocess.cpp:1752) > ==33074== by 0x805487A: AutoMoc::echoColor(QString const&) > (kde4automoc.cpp:74) > ==33074== by 0x805264F: AutoMoc::generateMoc(QString const&, > QString const&) (kde4automoc.cpp:569) > ==33074== by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) > ==33074== by 0x804AAEE: main (kde4automoc.cpp:114) > > Full valgrind output is at http://pastebin.com/KQTKYGX5 > This sounds like a valgrind bug I reported related to sigreturn: https://bitbucket.org/stass/valgrind-freebsd/issue/4/crash-in-x86_freebsd_subst_for_sigreturn Unfortunately I don't understand the mechanics of signal handling well enough to take this to completion. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 22:20:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD01B938; Mon, 10 Dec 2012 22:20:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAC18FC12; Mon, 10 Dec 2012 22:20:54 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so1591714wib.1 for ; Mon, 10 Dec 2012 14:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rXdwoRiRgxYiZlS8w9pmtJTgSQMjCvLFmc1OGflTJ2I=; b=m6XJsfJ70dhF5YkjEneBeT+NoN9JgD1vnm9WlYlD3IgDPm5SnFoxcdJOCP9NQptdVQ MSwwuaK1ZJjPevAtJZaX2qAh/JjEoOwhHVhKohz9Hgrc53GzDrDKPKzLFiX2CHuBNvMg eeU05y3IVm6qwnpSqjEr5r6dMfhP8BLzpZVZFqzNFUR8wALQapT+mXSeKu4zrTCK1UqE nSdeIB/+RDyQfrZ7EDjcVNF3g8Jyj91MCg+tCTpx3VOgUPD1AX5ThSLerhUEqWhZz86E ap5YPGAr1wmJA0C4l3BoD9LLYFv8sswbmZlZJ27y1ogak3OrB201ivDX7wF/PlE2+hJI p3/w== MIME-Version: 1.0 Received: by 10.216.139.140 with SMTP id c12mr6256555wej.46.1355178053978; Mon, 10 Dec 2012 14:20:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Mon, 10 Dec 2012 14:20:53 -0800 (PST) In-Reply-To: <201212101437.54825.jhb@freebsd.org> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212041106.50645.jhb@freebsd.org> <20121207095937.ECB38E6726@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> Date: Mon, 10 Dec 2012 14:20:53 -0800 X-Google-Sender-Auth: GcoW5_VjH8Ed-5_lwpmgDoPA80E Message-ID: Subject: Re: ath0: unable to attach hardware From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: husyh@hush.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 22:20:56 -0000 Hi, The fact the initial probe/attach fails by returning 0xffffffff means the chip isn't "right" on the bus. It's either just not mapped in correctly, or it's "powered off." If it were just asleep, it'd return 0xdeadc0de or 0xdeadbeef or something similar like that. Try AR_SCR (0x4004) and AR_PCICFG (0x4010) . Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 22:22:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7047AEB; Mon, 10 Dec 2012 22:22:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0E68FC0C; Mon, 10 Dec 2012 22:22:35 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3979299oag.13 for ; Mon, 10 Dec 2012 14:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=x0xcM9zuZk9bcCSa7Fam6zHpDk0wORQlZwWrvFYczqM=; b=iHsuuMpf5rowce53n8vgUZ/XHoABrGYzYh5pXUxDyMxElWcY/aD1AZIPP6daDwEea7 AEX8AZYPy+aaB0qaFgYr4HZd8HE11qCZT5ZeALacaRi4fcQIe+pGY2tMN37EwwgsIHn1 BM76TQBd/S2+yZBvcpnjsQjAdFCkJYXUO+2gP0n3bZqB9Kn5dDLFNG7cx+fYkA9asetp Agjp9sqxF4PTscKWXBi1fsYI5fOrauFNEMfqxknFpdcVw31i3HZmal126QCbLR2IY9vM iMbsOI2krkQOPr+wNY2JJzP1hkvcutvYnb1u+Fr/yyTfeJLD+GDheGsayultOZsDwYkc D7Mw== MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr7664871oec.51.1355178153559; Mon, 10 Dec 2012 14:22:33 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 14:22:33 -0800 (PST) Date: Mon, 10 Dec 2012 14:22:33 -0800 Message-ID: Subject: "Memory modified after free" - by whom? From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 22:22:36 -0000 I noticed this while checking the logs on one of my test boxes after restarting the network. Any idea where I should start looking into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe interfaces with the ixgbe interfaces lagged previously, but now not)? It looks suspiciously like the same size as a jumbo frame, but I'm not 100% sure if that's the real problem. Thanks, -Garrett Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination address delete failed Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was deleted, dhclient exiting Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes Dec 10 14:03:32 wf158 dhclient[4521]: exiting. Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 Dec 10 14:05:34 wf158 kernel: Memory modified after free 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 Dec 10 14:05:35 wf158 kernel: Memory modified after free 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 # uname -a FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 23:10:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5251DAC1; Mon, 10 Dec 2012 23:10:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D7D7E8FC18; Mon, 10 Dec 2012 23:10:58 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so3993039vcb.13 for ; Mon, 10 Dec 2012 15:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jVSaj4ddHb8ClAuhxbdz12tOufj15Iy1jdIcaEojd4o=; b=cGtzDIbbvBgm9IL57W/nyW3FIyIdgbX9h5cgblcAp8dW7sfQ3uuw6j5ivMczE0n3DI wNwx6JAwQo8rSFo5535gSJ0D7crqTy0/5B2zJnLu2xG9MSq3Y2Bd2IjXQ8lh3wjxLyq8 hadOKVUExa2f+kiUlWSG9Z7tOIIVYGtE6jlIXvIab33B713neBKfnWg7DuJNTavGn6BE 4KFB6GSFCftSFGzPL2VDMB8npFEReuYUIV2C4PSe80XSRj75YmhrIb1fBdrUpQCFPb0A V8yUqXo72XNZFi12odWoeS3uCQgSt9OyI1YRorlrpeNUEto4C7OB8D2cEBIORtXzPHuy LQwg== MIME-Version: 1.0 Received: by 10.52.98.36 with SMTP id ef4mr8696461vdb.104.1355181057877; Mon, 10 Dec 2012 15:10:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Mon, 10 Dec 2012 15:10:57 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:10:57 -0800 X-Google-Sender-Auth: 3G7VBInCSBJYmiogDZC4pCVBkyE Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 23:10:59 -0000 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf after it's finalised/freed. I have a similar bug showing up on ath(4) RX. :( adrian On 10 December 2012 14:22, Garrett Cooper wrote: > I noticed this while checking the logs on one of my test boxes > after restarting the network. Any idea where I should start looking > into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe > interfaces with the ixgbe interfaces lagged previously, but now not)? > It looks suspiciously like the same size as a jumbo frame, but I'm not > 100% sure if that's the real problem. > Thanks, > -Garrett > > Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP > Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 > Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 > Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 > Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 > Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination > address delete failed > Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was > deleted, dhclient exiting > Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes > Dec 10 14:03:32 wf158 dhclient[4521]: exiting. > Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN > Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN > Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP > Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP > Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 > Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 > Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 > Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 > Dec 10 14:05:34 wf158 kernel: Memory modified after free > 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 > Dec 10 14:05:35 wf158 kernel: Memory modified after free > 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 > > # uname -a > FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 > r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 > root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 23:18:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD229523; Mon, 10 Dec 2012 23:18:46 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9028FC12; Mon, 10 Dec 2012 23:18:46 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2289828pbc.13 for ; Mon, 10 Dec 2012 15:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U1bh6ZSvMw9khWC+8oQT5O6hNcR+B9frvdyIdwe0I6Q=; b=qkBLsSI2KaCuHhxua9JfeJv/fRq9upt6KNGewi2M5Wk35BxdOhjsFzHuOP0hCGp1Lh BuhDPqizYWnjN3Asmy8GK3rLa2SxjV/UMhSWSdriEmroIfgNRaT6UziJr/STCwSreTqC m4QQBb3CScKR14CSHLmYlVzhbpGzThGKs22jvVjJaqUpFKVhPCDcvntylM6nT6Cp4mpH B5JwYv5LuwRZinziDTgvJffTndClxTp/p4PsB7fAoeNiCTtT1g5/fVsK2B2vuUTiN8dt xXcFM8niQwhGiKizujdSWK1xB826aO+31rEqqb9/YgdKXvTCD9t2BJnoD1tQfWhImR75 9gVg== MIME-Version: 1.0 Received: by 10.66.80.68 with SMTP id p4mr39868443pax.35.1355181525767; Mon, 10 Dec 2012 15:18:45 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.55.166 with HTTP; Mon, 10 Dec 2012 15:18:45 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:18:45 -0800 X-Google-Sender-Auth: j0Wm823QFKo7Tm0elWmqQK7-aR0 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: mdf@FreeBSD.org To: Adrian Chadd , Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 23:18:46 -0000 On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: > 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf > after it's finalised/freed. > > I have a similar bug showing up on ath(4) RX. :( Compile with DEBUG_MEMGUARD in the kernel configuration, and then set vm.memguard.desc to the name of the UMA zone used for the 9216 byte allocations, mbuf_jumbo_9k. This should cause a panic when the memory is touched after free. Cheers, matthew > On 10 December 2012 14:22, Garrett Cooper wrote: >> I noticed this while checking the logs on one of my test boxes >> after restarting the network. Any idea where I should start looking >> into this (has IPv6 enabled but wasn't using it, em/cxgbe/ixgbe >> interfaces with the ixgbe interfaces lagged previously, but now not)? >> It looks suspiciously like the same size as a jumbo frame, but I'm not >> 100% sure if that's the real problem. >> Thanks, >> -Garrett >> >> Dec 10 14:03:12 wf158 kernel: em0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:13 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:13 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:15 wf158 kernel: em0: link state changed to UP >> Dec 10 14:03:15 wf158 dhclient: New IP Address (em0): 10.7.169.89 >> Dec 10 14:03:15 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 >> Dec 10 14:03:15 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 >> Dec 10 14:03:15 wf158 dhclient: New Routers (em0): 10.7.160.1 >> Dec 10 14:03:16 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:16 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:31 wf158 kernel: in6_purgeaddr: err=65, destination >> address delete failed >> Dec 10 14:03:31 wf158 dhclient[4539]: My address (10.7.169.89) was >> deleted, dhclient exiting >> Dec 10 14:03:32 wf158 dhclient[4521]: short write: wanted 20 got 0 bytes >> Dec 10 14:03:32 wf158 dhclient[4521]: exiting. >> Dec 10 14:03:33 wf158 kernel: em0: link state changed to DOWN >> Dec 10 14:03:33 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix0: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix0: link state changed to UP >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to DOWN >> Dec 10 14:03:34 wf158 kernel: ix1: link state changed to UP >> Dec 10 14:03:36 wf158 kernel: em0: link state changed to UP >> Dec 10 14:03:36 wf158 dhclient: New IP Address (em0): 10.7.169.89 >> Dec 10 14:03:36 wf158 dhclient: New Subnet Mask (em0): 255.255.240.0 >> Dec 10 14:03:36 wf158 dhclient: New Broadcast Address (em0): 10.7.175.255 >> Dec 10 14:03:36 wf158 dhclient: New Routers (em0): 10.7.160.1 >> Dec 10 14:05:34 wf158 kernel: Memory modified after free >> 0xffffff81c016d000(9216) val=ffffffff @ 0xffffff81c016d000 >> Dec 10 14:05:35 wf158 kernel: Memory modified after free >> 0xffffff81b5cdc000(9216) val=ffffffff @ 0xffffff81b5cdc000 >> >> # uname -a >> FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >> r+2760369-dirty: Mon Dec 10 08:04:46 PST 2012 >> root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > 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 Mon Dec 10 23:21:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 145838EA; Mon, 10 Dec 2012 23:21:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9043D8FC13; Mon, 10 Dec 2012 23:21:45 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4011130vba.13 for ; Mon, 10 Dec 2012 15:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KgcJGKZWpZSMhGc6NXwpKpFHRWM6NdN5JQUMoRt2H0M=; b=UDohXtR8AUHB4lMTLKFskKu2qk8TtmFEFQMJEfqDEBjyigysaNsekFVmtkgF7Q1vW/ HzYveLYOVHhHM7DAQ+51SvRgPnqxAFjymYPfWhmrqRypacKguWU/lrlcnYbiRgX/5zwl auk+y6WeziFpRBNltiPKwe0xPIuznFuBDs9sasLYXRPYsaHnHSYGuIFQkKdsk3SeUX0l JF3hx89o/dCLlqS3rHTiFy9I4K2q6ZpgKoY0Tjcey+SAaCmqKkG7RANPBG2U8JtlOSTU WNQDQoMq1qQXRG8KDAsCeZ4vLsOCmNZ6LkB3M/CwEVA1ubjiTJtkZr5gBQnEseX7a30N sE9Q== MIME-Version: 1.0 Received: by 10.58.239.162 with SMTP id vt2mr10326635vec.1.1355181704741; Mon, 10 Dec 2012 15:21:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Mon, 10 Dec 2012 15:21:44 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 15:21:44 -0800 X-Google-Sender-Auth: 9lN_vMmu972aJdTl6GNcFAu1w6c Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Adrian Chadd To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 10 Dec 2012 23:21:46 -0000 On 10 December 2012 15:18, wrote: > On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >> after it's finalised/freed. >> >> I have a similar bug showing up on ath(4) RX. :( > > Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > vm.memguard.desc to the name of the UMA zone used for the 9216 byte > allocations, mbuf_jumbo_9k. This should cause a panic when the memory > is touched after free. Right, but I think its a _hardware_ access after the buffer has been freed.. Adrian From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 00:12:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2C78440; Tue, 11 Dec 2012 00:12:01 +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 381628FC17; Tue, 11 Dec 2012 00:12:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAFF5xlCDaFvO/2dsb2JhbAA9CIY3uE1zgh4BAQEEAQEBIAQnIAsbDgoCAg0ZAikBCSYGCAcEAQgUBIdwDKVakl6BIosdCwwEDYMIgRMDiF+KeYIugRyPLIMRgUgHFx4 X-IronPort-AV: E=Sophos;i="4.84,254,1355115600"; d="scan'208";a="3915091" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Dec 2012 19:11:59 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A12CFB4041; Mon, 10 Dec 2012 19:11:59 -0500 (EST) Date: Mon, 10 Dec 2012 19:11:59 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <703324201.1302912.1355184719580.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121210184545.GS3013@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 00:12:01 -0000 Konstantin Belousov wrote: > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > Adrian Chadd wrote: > > > .. what was the previous kernel version? > > > > > Hopefully Tim has it narrowed down more, but I don't see > > the hangs on a Sept. 7 kernel from head and I do see them > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > It seems to predate my commit (r244008), which was my first > > concern. > > > > I use old single core i386 hardware and can fairly reliably > > reproduce it by doing a kernel build and a "svn checkout" > > concurrently. No NFS activity. These are running on a local > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > GENERIC for i386. If you want me to start a "binary search" > > for which rNNNNNN, I can do that, but it will take a while.:-) > > > > I can get out into DDB, but I'll admit I don't know enough > > about it to know where to look;-) > > Here's some lines from "db> ps", in case they give someone > > useful information. (I can leave this box sitting in DB for > > the rest of to-day, in case someone can suggest what I should > > look for on it.) > > > > Just snippets... > > Ss pause adjkerntz > > DL sdflush [sofdepflush] > > RL [syncer] > > DL vlruwt [vnlru] > > DL psleep [bufdaemon] > > RL [pagezero] > > DL psleep [vmdaemon] > > DL psleep [pagedaemon] > > DL ccb_scan [xpt_thrd] > > DL waiting_ [sctp_iterator] > > DL ctl_work [ctl_thrd] > > DL cooling [acpi_cooling0] > > DL tzpoll [acpi_thermal] > > DL (threaded) [usb] > > ... > > DL - [yarrow] > > DL (threaded) [geom] > > D - [g_down] > > D - [g_up] > > D - [g_event] > > RL (threaded) [intr] > > I [irq15: ata1] > > ... > > Run CPU0 [swi6: Giant taskq] > > --> does this one indicate the CPU is actually running this? > > (after a db> cont, wait a while db> ps > > it is still the same) > > I [swi4: clock] > > I [swi1: netisr 0] > > I [swi3: vm] > > RL [idle: cpu0] > > SLs wait [init] > > DL audit_wo [audit] > > DLs (threaded) [kernel] > > D - [deadlkres] > > ... > > D sched [swapper] > > > > I have no idea if this "ps" output helps, unless it indicates > > that it is looping on the Giant taskq? > Might be. You could do 'bt ' for the process to see where it > loops. > Another good set of hints is at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Kostik, you must be clairvoyant;-) When I did "show alllocks", I found that the syncer process held - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 The trace for this process goes like: spinlock_exit mtx_unlock_spin_flags kern_yield _mnt_vnode_next_active vnode_next_active vfs_msync() So, it seems like your r244095 commit might have fixed this? (I'm not good at this stuff, but from your description, it looks like it did the kern_yield() with the mutex held and "maybe" got into trouble trying to acquire Giant?) Anyhow, I'm going to test a kernel with r244095 in it and see if I can still reproduce the hang. (There wasn't much else in the "show alllocks", except a process that held the exclusive vnode interlock mutex plus a ufs vnode lock, but it's just doing a witness_unlock.) I'll email if/when I know more, rick ps: Fingers/toes crossed that you've already fixed it. > > > > > As I said, I can leave it in "db" for to-day, if anyone wants > > me to do anything in the debugger and I can probably reproduce > > it, if someone wants stuff tried later. > > > > rick > > > > > > > > > > > > > adrian > > > > > > > > > On 9 December 2012 22:08, Tim Kientzle > > > wrote: > > > > I haven't found any useful clues yet, but thought I'd ask if > > > > anyone > > > > else > > > > was seeing hangs in a recent kernel. > > > > > > > > I just upgraded to r244036 using a straight GENERIC i386 kernel. > > > > (Straight buildworld/buildkernel, no local changes, > > > > /etc/src.conf > > > > doesn't > > > > exist, /etc/make.conf just has PERL_VERSION defined.) > > > > > > > > When I try to cross build an ARM world on the resulting system, > > > > the entire system hangs hard after about 30 minutes: No network, > > > > no keyboard response, no nothing. > > > > > > > > Don't know if it's relevant, but the system is using NFS pretty > > > > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > > > > > > > I'll try to get some more details ... > > > > > > > > Tim > > > > > > > > _______________________________________________ > > > > 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" > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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 Tue Dec 11 01:37:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8F8C9F3; Tue, 11 Dec 2012 01:37:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44F1A8FC0C; Tue, 11 Dec 2012 01:37:17 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4142047oag.13 for ; Mon, 10 Dec 2012 17:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cWNkoDULkc/Uje2L8kLnPciq24V/jCjHh6F67TwbbCs=; b=DPStZoY6aAiAnOFNpGRbfmDnp1AuCtrxcqNbjv6toRWtg1uAPOh3g9UQ4dW8gwFb/t OemnD4Q2Qjro67dhRGhO0AoEOv/qfqq/R6akZ0q9OEHSWyzJIFjYO2aeMv7eX54T9eaS yRilSvZ7P9gaozFo9V7ECEfItIpd/BOHxTNohmeDkZ4gqKkk8hLK2iv/5J+3TcKJZutM aIhNo6A/dAUXuz/sinSA09F2iosXcBLULpOYytRdAF7hsiNWUh9mqXhEttEzLiU3PlAp N9moztY8vzT7Bziw0blXS6dbj3fATei0yGXMGJ25ggEbBCuwegt8F59xUZ3gyXsFcdd0 IzoA== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr8421128obb.38.1355189837412; Mon, 10 Dec 2012 17:37:17 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 17:37:17 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 17:37:17 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: mdf@freebsd.org, FreeBSD Current , freebsd-net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 01:37:18 -0000 On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote: > On 10 December 2012 15:18, wrote: >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >>> after it's finalised/freed. >>> >>> I have a similar bug showing up on ath(4) RX. :( >> >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory >> is touched after free. > > Right, but I think its a _hardware_ access after the buffer has been freed.. At least that will give me an idea of who to punt the bug over to next (assuming it lists the driver) -- one of the network folks, jfv, or np :). It seems to be a recent change that's causing this (it's spewing out these warnings every couple seconds), but that might also be related to me getting lagg working on CURRENT as my last known base was 9-STABLE and a lot of networking changes haven't been MFCed :). I could probably look through the code too after compiling it, but it would take too long. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 02:34:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CC3B46A; Tue, 11 Dec 2012 02:34:09 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E26D8FC12; Tue, 11 Dec 2012 02:34:08 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so2546103pad.13 for ; Mon, 10 Dec 2012 18:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=5c1hnPCGJJ7zTmRNDZ70C1RWwdEhcT02D5zQljfG6JM=; b=NkgDfwFsLM5sfdTBr7Lk64kVRKFoe9DWB0TdGegGqmTzdTnCGum88IIEPKl+QjLK3l RnAP+ViYLhUhkO45FcJC6nlHGKJ4eiUOYYTMwVocPlk2A2657QYgm8hOSBOu7pb9dgfM bP31I3BRNyNbHW0pt9ipuSJJYpoZoun9yHqLwOpLXNCBU0a53z2p+HNEAz4hbWZJa0Kq p6TiHwZshwx3VcE7NRp6yg7WP6ckLspX/fLMpPOtx8PFHp0saTdhEO5zKZsOj1RVr4wr nuHIrnlV2uP9B5N4HoCEeo6dxvijc0035s55gr2yz4SeI7uTl9kCuMv1o462PIHvCjEU NrdA== Received: by 10.68.239.104 with SMTP id vr8mr44547947pbc.59.1355193242646; Mon, 10 Dec 2012 18:34:02 -0800 (PST) Received: from itx (c-24-6-45-85.hsd1.ca.comcast.net. [24.6.45.85]) by mx.google.com with ESMTPS id na7sm438594pbc.48.2012.12.10.18.33.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 18:34:00 -0800 (PST) Date: Mon, 10 Dec 2012 18:33:54 -0800 From: Navdeep Parhar To: Garrett Cooper Subject: Re: "Memory modified after free" - by whom? Message-ID: <20121211023354.GA1916@itx> Mail-Followup-To: Garrett Cooper , Adrian Chadd , mdf@freebsd.org, FreeBSD Current , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mdf@freebsd.org, Adrian Chadd , FreeBSD Current , freebsd-net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 02:34:09 -0000 On Mon, Dec 10, 2012 at 05:37:17PM -0800, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote: > > On 10 December 2012 15:18, wrote: > >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: > >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf > >>> after it's finalised/freed. > >>> > >>> I have a similar bug showing up on ath(4) RX. :( > >> > >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte > >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory > >> is touched after free. > > > > Right, but I think its a _hardware_ access after the buffer has been freed.. > > At least that will give me an idea of who to punt the bug over to > next (assuming it lists the driver) -- one of the network folks, jfv, > or np :). It seems to be a recent change that's causing this (it's > spewing out these warnings every couple seconds), but that might also > be related to me getting lagg working on CURRENT as my last known base > was 9-STABLE and a lot of networking changes haven't been MFCed :). If you suspect it's a DMA from the NIC after the 9K cluster has been freed, see if the "corrupt" portion looks anything like an Ethernet frame. If it does then the DMAC in the frame will tell you who to follow up with -- jfv@ or me :-) (btw, your log had "val=ffffffff" so I think it's something else..) Regards, Navdeep > I could probably look through the code too after compiling it, but > it would take too long. > Thanks! > -Garrett > _______________________________________________ > 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 Tue Dec 11 03:32:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26C663BE; Tue, 11 Dec 2012 03:32:15 +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 C80678FC0C; Tue, 11 Dec 2012 03:32:11 +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 qBB3W4LU005389; Mon, 10 Dec 2012 22:32: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 qBB3W4ux005374; Tue, 11 Dec 2012 03:32:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 03:32:04 GMT Message-Id: <201212110332.qBB3W4ux005374@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 , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 03:32:15 -0000 TB --- 2012-12-11 02:07:55 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 02:07:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 02:07:55 - starting HEAD tinderbox run for mips64/mips TB --- 2012-12-11 02:07:55 - cleaning the object tree TB --- 2012-12-11 02:07:55 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 02:07:55 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-12-11 02:07:55 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 02:09:25 - /usr/local/bin/svn update /src TB --- 2012-12-11 02:09:32 - At svn revision 244107 TB --- 2012-12-11 02:09:33 - building world TB --- 2012-12-11 02:09:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 02:09:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 02:09:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 02:09:33 - SRCCONF=/dev/null TB --- 2012-12-11 02:09:33 - TARGET=mips TB --- 2012-12-11 02:09:33 - TARGET_ARCH=mips64 TB --- 2012-12-11 02:09:33 - TZ=UTC TB --- 2012-12-11 02:09:33 - __MAKE_CONF=/dev/null TB --- 2012-12-11 02:09:33 - cd /src TB --- 2012-12-11 02:09:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 02:09:39 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 Tue Dec 11 03:14:34 UTC 2012 TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m ADM5120 TB --- 2012-12-11 03:14:34 - skipping ADM5120 kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-11 03:14:34 - skipping ALCHEMY kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AP91 TB --- 2012-12-11 03:14:34 - skipping AP91 kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AP93 TB --- 2012-12-11 03:14:34 - skipping AP93 kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AP94 TB --- 2012-12-11 03:14:34 - skipping AP94 kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AP96 TB --- 2012-12-11 03:14:34 - skipping AP96 kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AR71XX_BASE TB --- 2012-12-11 03:14:34 - skipping AR71XX_BASE kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AR724X_BASE TB --- 2012-12-11 03:14:34 - skipping AR724X_BASE kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m AR91XX_BASE TB --- 2012-12-11 03:14:34 - skipping AR91XX_BASE kernel TB --- 2012-12-11 03:14:34 - cd /src/sys/mips/conf TB --- 2012-12-11 03:14:34 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2012-12-11 03:14:34 - building BERI_DE4_MDROOT kernel TB --- 2012-12-11 03:14:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:14:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:14:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:14:34 - SRCCONF=/dev/null TB --- 2012-12-11 03:14:34 - TARGET=mips TB --- 2012-12-11 03:14:34 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:14:34 - TZ=UTC TB --- 2012-12-11 03:14:34 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:14:34 - cd /src TB --- 2012-12-11 03:14:34 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Tue Dec 11 03:14:34 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 >>> Kernel build for BERI_DE4_MDROOT completed on Tue Dec 11 03:17:50 UTC 2012 TB --- 2012-12-11 03:17:50 - cd /src/sys/mips/conf TB --- 2012-12-11 03:17:50 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2012-12-11 03:17:50 - building BERI_DE4_SDROOT kernel TB --- 2012-12-11 03:17:50 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:17:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:17:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:17:50 - SRCCONF=/dev/null TB --- 2012-12-11 03:17:50 - TARGET=mips TB --- 2012-12-11 03:17:50 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:17:50 - TZ=UTC TB --- 2012-12-11 03:17:50 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:17:50 - cd /src TB --- 2012-12-11 03:17:50 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Tue Dec 11 03:17:50 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 >>> Kernel build for BERI_DE4_SDROOT completed on Tue Dec 11 03:20:17 UTC 2012 TB --- 2012-12-11 03:20:17 - cd /src/sys/mips/conf TB --- 2012-12-11 03:20:17 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2012-12-11 03:20:17 - building BERI_SIM_MDROOT kernel TB --- 2012-12-11 03:20:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:20:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:20:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:20:17 - SRCCONF=/dev/null TB --- 2012-12-11 03:20:17 - TARGET=mips TB --- 2012-12-11 03:20:17 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:20:17 - TZ=UTC TB --- 2012-12-11 03:20:17 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:20:17 - cd /src TB --- 2012-12-11 03:20:17 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Tue Dec 11 03:20:17 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 >>> Kernel build for BERI_SIM_MDROOT completed on Tue Dec 11 03:22:32 UTC 2012 TB --- 2012-12-11 03:22:32 - cd /src/sys/mips/conf TB --- 2012-12-11 03:22:32 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2012-12-11 03:22:32 - building BERI_TEMPLATE kernel TB --- 2012-12-11 03:22:32 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:22:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:22:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:22:32 - SRCCONF=/dev/null TB --- 2012-12-11 03:22:32 - TARGET=mips TB --- 2012-12-11 03:22:32 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:22:32 - TZ=UTC TB --- 2012-12-11 03:22:32 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:22:32 - cd /src TB --- 2012-12-11 03:22:32 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Tue Dec 11 03:22:32 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 >>> Kernel build for BERI_TEMPLATE completed on Tue Dec 11 03:24:48 UTC 2012 TB --- 2012-12-11 03:24:48 - cd /src/sys/mips/conf TB --- 2012-12-11 03:24:48 - /usr/sbin/config -m DIR-825 TB --- 2012-12-11 03:24:48 - skipping DIR-825 kernel TB --- 2012-12-11 03:24:48 - cd /src/sys/mips/conf TB --- 2012-12-11 03:24:48 - /usr/sbin/config -m GXEMUL TB --- 2012-12-11 03:24:49 - building GXEMUL kernel TB --- 2012-12-11 03:24:49 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:24:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:24:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:24:49 - SRCCONF=/dev/null TB --- 2012-12-11 03:24:49 - TARGET=mips TB --- 2012-12-11 03:24:49 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:24:49 - TZ=UTC TB --- 2012-12-11 03:24:49 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:24:49 - cd /src TB --- 2012-12-11 03:24:49 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Tue Dec 11 03:24:49 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 >>> Kernel build for GXEMUL completed on Tue Dec 11 03:27:04 UTC 2012 TB --- 2012-12-11 03:27:04 - cd /src/sys/mips/conf TB --- 2012-12-11 03:27:04 - /usr/sbin/config -m IDT TB --- 2012-12-11 03:27:04 - skipping IDT kernel TB --- 2012-12-11 03:27:04 - cd /src/sys/mips/conf TB --- 2012-12-11 03:27:04 - /usr/sbin/config -m MALTA TB --- 2012-12-11 03:27:04 - skipping MALTA kernel TB --- 2012-12-11 03:27:04 - cd /src/sys/mips/conf TB --- 2012-12-11 03:27:04 - /usr/sbin/config -m MALTA64 TB --- 2012-12-11 03:27:04 - skipping MALTA64 kernel TB --- 2012-12-11 03:27:04 - cd /src/sys/mips/conf TB --- 2012-12-11 03:27:04 - /usr/sbin/config -m OCTEON1 TB --- 2012-12-11 03:27:04 - building OCTEON1 kernel TB --- 2012-12-11 03:27:04 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:27:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:27:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:27:04 - SRCCONF=/dev/null TB --- 2012-12-11 03:27:04 - TARGET=mips TB --- 2012-12-11 03:27:04 - TARGET_ARCH=mips64 TB --- 2012-12-11 03:27:04 - TZ=UTC TB --- 2012-12-11 03:27:04 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:27:04 - cd /src TB --- 2012-12-11 03:27:04 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Tue Dec 11 03:27:04 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 -O -pipe -std=c99 -g -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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/subr_trap.c cc -c -O -pipe -std=c99 -g -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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/subr_turnstile.c cc -c -O -pipe -std=c99 -g -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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/subr_uio.c cc -c -O -pipe -std=c99 -g -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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/subr_unit.c cc -c -O -pipe -std=c99 -g -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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_assert': /src/sys/kern/subr_witness.c:2253: warning: 'instance' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/mips.mips64/src/sys/OCTEON1. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 03:32:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 03:32:04 - ERROR: failed to build OCTEON1 kernel TB --- 2012-12-11 03:32:04 - 3414.84 user 718.04 system 5049.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 04:52:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7669F6A1; Tue, 11 Dec 2012 04:52:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D88758FC14; Tue, 11 Dec 2012 04:52:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBB4qQcu035978; Tue, 11 Dec 2012 06:52:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBB4qQcu035978 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBB4qPQ1035977; Tue, 11 Dec 2012 06:52:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Dec 2012 06:52:25 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121211045225.GY3013@kib.kiev.ua> References: <20121210184545.GS3013@kib.kiev.ua> <703324201.1302912.1355184719580.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7zXkBnrtCPTreBSJ" Content-Disposition: inline In-Reply-To: <703324201.1302912.1355184719580.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 04:52:36 -0000 --7zXkBnrtCPTreBSJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > > Adrian Chadd wrote: > > > > .. what was the previous kernel version? > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > the hangs on a Sept. 7 kernel from head and I do see them > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > > > It seems to predate my commit (r244008), which was my first > > > concern. > > > > > > I use old single core i386 hardware and can fairly reliably > > > reproduce it by doing a kernel build and a "svn checkout" > > > concurrently. No NFS activity. These are running on a local > > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > > GENERIC for i386. If you want me to start a "binary search" > > > for which rNNNNNN, I can do that, but it will take a while.:-) > > > > > > I can get out into DDB, but I'll admit I don't know enough > > > about it to know where to look;-) > > > Here's some lines from "db> ps", in case they give someone > > > useful information. (I can leave this box sitting in DB for > > > the rest of to-day, in case someone can suggest what I should > > > look for on it.) > > > > > > Just snippets... > > > Ss pause adjkerntz > > > DL sdflush [sofdepflush] > > > RL [syncer] > > > DL vlruwt [vnlru] > > > DL psleep [bufdaemon] > > > RL [pagezero] > > > DL psleep [vmdaemon] > > > DL psleep [pagedaemon] > > > DL ccb_scan [xpt_thrd] > > > DL waiting_ [sctp_iterator] > > > DL ctl_work [ctl_thrd] > > > DL cooling [acpi_cooling0] > > > DL tzpoll [acpi_thermal] > > > DL (threaded) [usb] > > > ... > > > DL - [yarrow] > > > DL (threaded) [geom] > > > D - [g_down] > > > D - [g_up] > > > D - [g_event] > > > RL (threaded) [intr] > > > I [irq15: ata1] > > > ... > > > Run CPU0 [swi6: Giant taskq] > > > --> does this one indicate the CPU is actually running this? > > > (after a db> cont, wait a while db> ps > > > it is still the same) > > > I [swi4: clock] > > > I [swi1: netisr 0] > > > I [swi3: vm] > > > RL [idle: cpu0] > > > SLs wait [init] > > > DL audit_wo [audit] > > > DLs (threaded) [kernel] > > > D - [deadlkres] > > > ... > > > D sched [swapper] > > > > > > I have no idea if this "ps" output helps, unless it indicates > > > that it is looping on the Giant taskq? > > Might be. You could do 'bt ' for the process to see where it > > loops. > > Another good set of hints is at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html >=20 > Kostik, you must be clairvoyant;-) >=20 > When I did "show alllocks", I found that the syncer process held > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > The trace for this process goes like: > spinlock_exit > mtx_unlock_spin_flags > kern_yield > _mnt_vnode_next_active > vnode_next_active > vfs_msync() >=20 > So, it seems like your r244095 commit might have fixed this? > (I'm not good at this stuff, but from your description, it looks > like it did the kern_yield() with the mutex held and "maybe" > got into trouble trying to acquire Giant?) >=20 > Anyhow, I'm going to test a kernel with r244095 in it and see > if I can still reproduce the hang. > (There wasn't much else in the "show alllocks", except a > process that held the exclusive vnode interlock mutex plus > a ufs vnode lock, but it's just doing a witness_unlock.) There must be a thread blocked for the mount interlock for the loop in the mnt_vnode_next_active to cause livelock. >=20 > I'll email if/when I know more, rick > ps: Fingers/toes crossed that you've already fixed it. >=20 > >=20 > > > > > > As I said, I can leave it in "db" for to-day, if anyone wants > > > me to do anything in the debugger and I can probably reproduce > > > it, if someone wants stuff tried later. > > > > > > rick > > > > > > > > > > > > > > > > > > adrian > > > > > > > > > > > > On 9 December 2012 22:08, Tim Kientzle > > > > wrote: > > > > > I haven't found any useful clues yet, but thought I'd ask if > > > > > anyone > > > > > else > > > > > was seeing hangs in a recent kernel. > > > > > > > > > > I just upgraded to r244036 using a straight GENERIC i386 kernel. > > > > > (Straight buildworld/buildkernel, no local changes, > > > > > /etc/src.conf > > > > > doesn't > > > > > exist, /etc/make.conf just has PERL_VERSION defined.) > > > > > > > > > > When I try to cross build an ARM world on the resulting system, > > > > > the entire system hangs hard after about 30 minutes: No network, > > > > > no keyboard response, no nothing. > > > > > > > > > > Don't know if it's relevant, but the system is using NFS pretty > > > > > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > > > > > > > > > I'll try to get some more details ... > > > > > > > > > > Tim > > > > > > > > > > _______________________________________________ > > > > > 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" > > > > _______________________________________________ > > > > 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" > > > _______________________________________________ > > > 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" --7zXkBnrtCPTreBSJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQxrwJAAoJEJDCuSvBvK1Bpg0P/2sogQ9eqwfBcdKDLLxGv4ZO ea2nnp4ovJOGDhSowFS69sYqeT7sXvI3Oixqd/6X8bCkUSySKs4q4np0k+ds+49S f89mro0Y4dnOoGm1tq/cRdu3YnM00OaDzSoeMcbHGHs72eC6eBIRm56PZc+8BO1p moqUDfsY6zlhCcF3wmqVDLwhnHBnMitTaNz2w/DDrYpksf9YIwlxntzENMUPTM0l dc3JZ6qFgkc/YpnO5tkTr2zAo1lGSsZiiHH46WCt0bj8U6XeGX8hhKp0RS6EynKO 1tRCvwZ49YIyzBXfldj5EW5JA+hegnt9CWwwW/2ViTXaOVG4T5tD84k33tuCTdoQ AGT6BTOkYpSiUUrVIFwPUelCax+X8F+rKsW4WbC8lhjUD5K02+jfigfW7pNh+/37 aenQlGi0bD+lkrtZyfizHd3uJI7TjHZgAgvuJCutCFwEDRjipTU8O8ta7PUABdFc o4OeFBpK649ZDQ/Rt2sKcwMIc9vC8h5kneuYPmLKxPw95g/LKUmOEPY0SyS0K6WJ QYGq6uWr/NZZGJgAen5SugZeRE+tFdk+xGLoXz0pJZu4lYDS2bER1KjoTqn1sHBN rqUg2ser2Y1vl9Uf/IUBXPDCWFMqfvmnlClR+pEX+8jVgjYnLBGh/7etYeoMjhxy Y9JEnjI/YMjweXbXqhNo =kKhv -----END PGP SIGNATURE----- --7zXkBnrtCPTreBSJ-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 05:09:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F86964; Tue, 11 Dec 2012 05:09:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 0766B8FC0C; Tue, 11 Dec 2012 05:09:33 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBB59W29054383; Tue, 11 Dec 2012 05:09:32 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hkwe4if3ernr5urxpqexiijfkw; Tue, 11 Dec 2012 05:09:32 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: r244036 kernel hangs under load. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <735026206.1290394.1355164701856.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 10 Dec 2012 21:09:31 -0800 Content-Transfer-Encoding: 7bit Message-Id: <4140ADBA-0F30-4DE6-99F9-F4E90EB2DA39@freebsd.org> References: <735026206.1290394.1355164701856.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 05:09:34 -0000 On Dec 10, 2012, at 10:38 AM, Rick Macklem wrote: > Adrian Chadd wrote: >> .. what was the previous kernel version? >> > Hopefully Tim has it narrowed down more, but I don't see > the hangs on a Sept. 7 kernel from head and I do see them > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) I haven't had a chance to narrow it down any yet, but I think my previous kernel was from around Aug 25. Tim From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 05:24:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF9B5F6B; Tue, 11 Dec 2012 05:24:14 +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 AA0CD8FC0C; Tue, 11 Dec 2012 05:24:14 +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 qBB5ODq0017512; Tue, 11 Dec 2012 00:24:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB5ODLh017507; Tue, 11 Dec 2012 05:24:13 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 05:24:13 GMT Message-Id: <201212110524.qBB5ODLh017507@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 , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:24:15 -0000 TB --- 2012-12-11 04:09:25 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 04:09:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 04:09:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-12-11 04:09:25 - cleaning the object tree TB --- 2012-12-11 04:09:25 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 04:09:25 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-12-11 04:09:25 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 04:11:32 - /usr/local/bin/svn update /src TB --- 2012-12-11 04:11:39 - At svn revision 244108 TB --- 2012-12-11 04:11:40 - building world TB --- 2012-12-11 04:11:40 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 04:11:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 04:11:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 04:11:40 - SRCCONF=/dev/null TB --- 2012-12-11 04:11:40 - TARGET=sparc64 TB --- 2012-12-11 04:11:40 - TARGET_ARCH=sparc64 TB --- 2012-12-11 04:11:40 - TZ=UTC TB --- 2012-12-11 04:11:40 - __MAKE_CONF=/dev/null TB --- 2012-12-11 04:11:40 - cd /src TB --- 2012-12-11 04:11:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 04:11:46 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 Tue Dec 11 05:13:53 UTC 2012 TB --- 2012-12-11 05:13:53 - generating LINT kernel config TB --- 2012-12-11 05:13:53 - cd /src/sys/sparc64/conf TB --- 2012-12-11 05:13:53 - /usr/bin/make -B LINT TB --- 2012-12-11 05:13:53 - cd /src/sys/sparc64/conf TB --- 2012-12-11 05:13:53 - /usr/sbin/config -m LINT TB --- 2012-12-11 05:13:53 - building LINT kernel TB --- 2012-12-11 05:13:53 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 05:13:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 05:13:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 05:13:53 - SRCCONF=/dev/null TB --- 2012-12-11 05:13:53 - TARGET=sparc64 TB --- 2012-12-11 05:13:53 - TARGET_ARCH=sparc64 TB --- 2012-12-11 05:13:53 - TZ=UTC TB --- 2012-12-11 05:13:53 - __MAKE_CONF=/dev/null TB --- 2012-12-11 05:13:53 - cd /src TB --- 2012-12-11 05:13:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 05:13:53 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/kern/subr_trap.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/kern/subr_turnstile.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/kern/subr_uio.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/kern/subr_unit.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/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_assert': /src/sys/kern/subr_witness.c:2253: warning: 'instance' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 05:24:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 05:24:13 - ERROR: failed to build LINT kernel TB --- 2012-12-11 05:24:13 - 3586.73 user 597.80 system 4488.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 05:59:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42307A8E; Tue, 11 Dec 2012 05:59:42 +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 0600A8FC17; Tue, 11 Dec 2012 05:59:41 +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 qBB5xffV023184; Tue, 11 Dec 2012 00:59:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB5xf9Q023183; Tue, 11 Dec 2012 05:59:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 05:59:41 GMT Message-Id: <201212110559.qBB5xf9Q023183@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 , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:59:42 -0000 TB --- 2012-12-11 03:24:20 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 03:24:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 03:24:20 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-12-11 03:24:20 - cleaning the object tree TB --- 2012-12-11 03:24:20 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 03:24:20 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2012-12-11 03:24:20 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 03:26:28 - /usr/local/bin/svn update /src TB --- 2012-12-11 03:26:35 - At svn revision 244108 TB --- 2012-12-11 03:26:36 - building world TB --- 2012-12-11 03:26:36 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:26:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:26:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:26:36 - SRCCONF=/dev/null TB --- 2012-12-11 03:26:36 - TARGET=powerpc TB --- 2012-12-11 03:26:36 - TARGET_ARCH=powerpc TB --- 2012-12-11 03:26:36 - TZ=UTC TB --- 2012-12-11 03:26:36 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:26:36 - cd /src TB --- 2012-12-11 03:26:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 03:26:42 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 Tue Dec 11 05:52:06 UTC 2012 TB --- 2012-12-11 05:52:06 - generating LINT kernel config TB --- 2012-12-11 05:52:06 - cd /src/sys/powerpc/conf TB --- 2012-12-11 05:52:06 - /usr/bin/make -B LINT TB --- 2012-12-11 05:52:06 - cd /src/sys/powerpc/conf TB --- 2012-12-11 05:52:06 - /usr/sbin/config -m LINT TB --- 2012-12-11 05:52:06 - building LINT kernel TB --- 2012-12-11 05:52:06 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 05:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 05:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 05:52:06 - SRCCONF=/dev/null TB --- 2012-12-11 05:52:06 - TARGET=powerpc TB --- 2012-12-11 05:52:06 - TARGET_ARCH=powerpc TB --- 2012-12-11 05:52:06 - TZ=UTC TB --- 2012-12-11 05:52:06 - __MAKE_CONF=/dev/null TB --- 2012-12-11 05:52:06 - cd /src TB --- 2012-12-11 05:52:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 05:52:06 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 -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_turnstile.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_uio.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_unit.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_unlock': /src/sys/kern/subr_witness.c:1517: warning: 'instance' may be used uninitialized in this function /src/sys/kern/subr_witness.c:1521: warning: 'i' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 05:59:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 05:59:41 - ERROR: failed to build LINT kernel TB --- 2012-12-11 05:59:41 - 7567.98 user 943.02 system 9321.21 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 06:36:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09ED56C7; Tue, 11 Dec 2012 06:36:02 +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 C1EFD8FC1B; Tue, 11 Dec 2012 06:36:01 +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 qBB6a0V2001596; Tue, 11 Dec 2012 01:36:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB6a0U7001595; Tue, 11 Dec 2012 06:36:00 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 06:36:00 GMT Message-Id: <201212110636.qBB6a0U7001595@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 , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 06:36:02 -0000 TB --- 2012-12-11 03:32:04 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 03:32:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 03:32:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-12-11 03:32:04 - cleaning the object tree TB --- 2012-12-11 03:32:04 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 03:32:04 - cd /tinderbox/HEAD/powerpc64/powerpc TB --- 2012-12-11 03:32:04 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 03:34:07 - /usr/local/bin/svn update /src TB --- 2012-12-11 03:34:14 - At svn revision 244108 TB --- 2012-12-11 03:34:15 - building world TB --- 2012-12-11 03:34:15 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:34:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:34:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:34:15 - SRCCONF=/dev/null TB --- 2012-12-11 03:34:15 - TARGET=powerpc TB --- 2012-12-11 03:34:15 - TARGET_ARCH=powerpc64 TB --- 2012-12-11 03:34:15 - TZ=UTC TB --- 2012-12-11 03:34:15 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:34:15 - cd /src TB --- 2012-12-11 03:34:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 03:34:20 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Dec 11 06:28:07 UTC 2012 TB --- 2012-12-11 06:28:07 - generating LINT kernel config TB --- 2012-12-11 06:28:07 - cd /src/sys/powerpc/conf TB --- 2012-12-11 06:28:07 - /usr/bin/make -B LINT TB --- 2012-12-11 06:28:07 - cd /src/sys/powerpc/conf TB --- 2012-12-11 06:28:07 - /usr/sbin/config -m LINT TB --- 2012-12-11 06:28:07 - building LINT kernel TB --- 2012-12-11 06:28:07 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 06:28:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 06:28:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 06:28:07 - SRCCONF=/dev/null TB --- 2012-12-11 06:28:07 - TARGET=powerpc TB --- 2012-12-11 06:28:07 - TARGET_ARCH=powerpc64 TB --- 2012-12-11 06:28:07 - TZ=UTC TB --- 2012-12-11 06:28:07 - __MAKE_CONF=/dev/null TB --- 2012-12-11 06:28:07 - cd /src TB --- 2012-12-11 06:28:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 06:28:07 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 -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_turnstile.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_uio.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_unit.c cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_unlock': /src/sys/kern/subr_witness.c:1517: warning: 'instance' may be used uninitialized in this function /src/sys/kern/subr_witness.c:1521: warning: 'i' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 06:36:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 06:36:00 - ERROR: failed to build LINT kernel TB --- 2012-12-11 06:36:00 - 9189.95 user 1202.70 system 11035.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 06:41:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DDFFA0A; Tue, 11 Dec 2012 06:41:12 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7D99B8FC13; Tue, 11 Dec 2012 06:41:11 +0000 (UTC) Received: from Alfreds-MacBook-Pro-6.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 55A911A3C1B; Mon, 10 Dec 2012 22:41:11 -0800 (PST) Message-ID: <50C6D586.2070604@mu.org> Date: Mon, 10 Dec 2012 22:41:10 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on powerpc64/powerpc References: <201212110636.qBB6a0U7001595@freebsd-current.sentex.ca> In-Reply-To: <201212110636.qBB6a0U7001595@freebsd-current.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: powerpc64@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 06:41:12 -0000 Got bit by compiler not warning on some things. Working on a fix. -Alfred On 12/10/12 10:36 PM, FreeBSD Tinderbox wrote: > TB --- 2012-12-11 03:32:04 - tinderbox 2.9 running on freebsd-current.sentex.ca > TB --- 2012-12-11 03:32:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2012-12-11 03:32:04 - starting HEAD tinderbox run for powerpc64/powerpc > TB --- 2012-12-11 03:32:04 - cleaning the object tree > TB --- 2012-12-11 03:32:04 - checking out /src from svn://svn.freebsd.org/base/head > TB --- 2012-12-11 03:32:04 - cd /tinderbox/HEAD/powerpc64/powerpc > TB --- 2012-12-11 03:32:04 - /usr/local/bin/svn cleanup /src > TB --- 2012-12-11 03:34:07 - /usr/local/bin/svn update /src > TB --- 2012-12-11 03:34:14 - At svn revision 244108 > TB --- 2012-12-11 03:34:15 - building world > TB --- 2012-12-11 03:34:15 - CROSS_BUILD_TESTING=YES > TB --- 2012-12-11 03:34:15 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-12-11 03:34:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-12-11 03:34:15 - SRCCONF=/dev/null > TB --- 2012-12-11 03:34:15 - TARGET=powerpc > TB --- 2012-12-11 03:34:15 - TARGET_ARCH=powerpc64 > TB --- 2012-12-11 03:34:15 - TZ=UTC > TB --- 2012-12-11 03:34:15 - __MAKE_CONF=/dev/null > TB --- 2012-12-11 03:34:15 - cd /src > TB --- 2012-12-11 03:34:15 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Tue Dec 11 03:34:20 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 >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Tue Dec 11 06:28:07 UTC 2012 > TB --- 2012-12-11 06:28:07 - generating LINT kernel config > TB --- 2012-12-11 06:28:07 - cd /src/sys/powerpc/conf > TB --- 2012-12-11 06:28:07 - /usr/bin/make -B LINT > TB --- 2012-12-11 06:28:07 - cd /src/sys/powerpc/conf > TB --- 2012-12-11 06:28:07 - /usr/sbin/config -m LINT > TB --- 2012-12-11 06:28:07 - building LINT kernel > TB --- 2012-12-11 06:28:07 - CROSS_BUILD_TESTING=YES > TB --- 2012-12-11 06:28:07 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-12-11 06:28:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-12-11 06:28:07 - SRCCONF=/dev/null > TB --- 2012-12-11 06:28:07 - TARGET=powerpc > TB --- 2012-12-11 06:28:07 - TARGET_ARCH=powerpc64 > TB --- 2012-12-11 06:28:07 - TZ=UTC > TB --- 2012-12-11 06:28:07 - __MAKE_CONF=/dev/null > TB --- 2012-12-11 06:28:07 - cd /src > TB --- 2012-12-11 06:28:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>>> Kernel build for LINT started on Tue Dec 11 06:28:07 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 -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_turnstile.c > cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_uio.c > cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_unit.c > cc -c -O -pipe -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 -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_witness.c > cc1: warnings being treated as errors > /src/sys/kern/subr_witness.c: In function 'witness_unlock': > /src/sys/kern/subr_witness.c:1517: warning: 'instance' may be used uninitialized in this function > /src/sys/kern/subr_witness.c:1521: warning: 'i' may be used uninitialized in this function > *** [subr_witness.o] Error code 1 > > Stop in /obj/powerpc.powerpc64/src/sys/LINT. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-12-11 06:36:00 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-12-11 06:36:00 - ERROR: failed to build LINT kernel > TB --- 2012-12-11 06:36:00 - 9189.95 user 1202.70 system 11035.80 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full > _______________________________________________ > 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 Tue Dec 11 07:13:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA39E692 for ; Tue, 11 Dec 2012 07:13:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3338FC0C for ; Tue, 11 Dec 2012 07:13:43 +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 qBB7DZ7l090299; Tue, 11 Dec 2012 11:13:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBB7DYUr090298; Tue, 11 Dec 2012 11:13:34 +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, 11 Dec 2012 11:13:34 +0400 From: Gleb Smirnoff To: Artyom Mirgorodskiy Subject: Re: rev 244030 route command is not working Message-ID: <20121211071334.GS48639@glebius.int.ru> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121210134057.GN48639@FreeBSD.org> <2837017.6IXeElfWaT@home.alkar.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mSxgbZZZvrAyzONB" Content-Disposition: inline In-Reply-To: <2837017.6IXeElfWaT@home.alkar.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 07:13:44 -0000 --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Artyom, can you please run route with attached patch and show output? -- Totus tuus, Glebius. --mSxgbZZZvrAyzONB Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="route.c.diff" Index: route.c =================================================================== --- route.c (revision 244082) +++ route.c (working copy) @@ -325,6 +325,7 @@ goto fiboptlist_csv_ret; } snprintf(str, ALLSTRLEN - 1, "%d", defaultfib); + printf("%s: arg %s, ret %d, str \"%s\"\n", __func__, arg, error, str); } else str = strdup(arg); @@ -350,6 +351,7 @@ TAILQ_INSERT_TAIL(flh, fl, fl_next); } } + printf("%s: arg %s, ret %d, str \"%s\"\n", __func__, arg, error, str); fiboptlist_csv_ret: free(str); return (error); --mSxgbZZZvrAyzONB-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 07:53:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FDCA2D7; Tue, 11 Dec 2012 07:53:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9794D8FC14; Tue, 11 Dec 2012 07:53:43 +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 qBB7rheP090531; Tue, 11 Dec 2012 11:53: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 qBB7rhx9090530; Tue, 11 Dec 2012 11:53: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: Tue, 11 Dec 2012 11:53:43 +0400 From: Gleb Smirnoff To: mdf@FreeBSD.org Subject: Re: "Memory modified after free" - by whom? Message-ID: <20121211075343.GT48639@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , freebsd-net@FreeBSD.org, Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 07:53:45 -0000 On Mon, Dec 10, 2012 at 03:18:45PM -0800, mdf@freebsd.org wrote: m> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: m> > 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf m> > after it's finalised/freed. m> > m> > I have a similar bug showing up on ath(4) RX. :( m> m> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set m> vm.memguard.desc to the name of the UMA zone used for the 9216 byte m> allocations, mbuf_jumbo_9k. This should cause a panic when the memory m> is touched after free. DEBUG_MEMGUARD doesn't work with cluster zone, I'm afraid it won't work with mbuf_jumbo_9k, too, but I didn't try this. The problem is documented in BUGS in memguard(9). -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 07:54:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91F58478; Tue, 11 Dec 2012 07:54:36 +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 558CF8FC13; Tue, 11 Dec 2012 07:54: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 qBB7sZ9W016312; Tue, 11 Dec 2012 02:54:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB7sZSL016311; Tue, 11 Dec 2012 07:54:35 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 07:54:35 GMT Message-Id: <201212110754.qBB7sZSL016311@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 07:54:36 -0000 TB --- 2012-12-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 06:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-11 06:40:00 - cleaning the object tree TB --- 2012-12-11 06:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 06:40:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-11 06:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 06:44:22 - /usr/local/bin/svn update /src TB --- 2012-12-11 06:44:33 - At svn revision 244111 TB --- 2012-12-11 06:44:34 - building world TB --- 2012-12-11 06:44:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 06:44:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 06:44:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 06:44:34 - SRCCONF=/dev/null TB --- 2012-12-11 06:44:34 - TARGET=arm TB --- 2012-12-11 06:44:34 - TARGET_ARCH=arm TB --- 2012-12-11 06:44:34 - TZ=UTC TB --- 2012-12-11 06:44:34 - __MAKE_CONF=/dev/null TB --- 2012-12-11 06:44:34 - cd /src TB --- 2012-12-11 06:44:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 06:44:42 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 Tue Dec 11 07:44:11 UTC 2012 TB --- 2012-12-11 07:44:11 - generating LINT kernel config TB --- 2012-12-11 07:44:11 - cd /src/sys/arm/conf TB --- 2012-12-11 07:44:11 - /usr/bin/make -B LINT TB --- 2012-12-11 07:44:11 - cd /src/sys/arm/conf TB --- 2012-12-11 07:44:11 - /usr/sbin/config -m LINT TB --- 2012-12-11 07:44:11 - building LINT kernel TB --- 2012-12-11 07:44:11 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 07:44:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 07:44:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 07:44:11 - SRCCONF=/dev/null TB --- 2012-12-11 07:44:11 - TARGET=arm TB --- 2012-12-11 07:44:11 - TARGET_ARCH=arm TB --- 2012-12-11 07:44:11 - TZ=UTC TB --- 2012-12-11 07:44:11 - __MAKE_CONF=/dev/null TB --- 2012-12-11 07:44:11 - cd /src TB --- 2012-12-11 07:44:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 07:44:12 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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_turnstile.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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_uio.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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_unit.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 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_unlock': /src/sys/kern/subr_witness.c:1517: warning: 'instance' may be used uninitialized in this function /src/sys/kern/subr_witness.c:1521: warning: 'i' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 07:54:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 07:54:35 - ERROR: failed to build LINT kernel TB --- 2012-12-11 07:54:35 - 3085.66 user 624.03 system 4474.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 10:16:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF636F27; Tue, 11 Dec 2012 10:16:18 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 864558FC12; Tue, 11 Dec 2012 10:16:18 +0000 (UTC) Received: from notebook.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 00C3EE604A; Tue, 11 Dec 2012 05:16:16 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: rev 244030 route command is not working Date: Tue, 11 Dec 2012 12:16:13 +0200 Message-ID: <1740464.YojJrNfMlV@notebook.alkar.net> User-Agent: KMail/4.9.3 (FreeBSD/10.0-CURRENT; KDE/4.9.3; amd64; ; ) In-Reply-To: <20121211071334.GS48639@glebius.int.ru> References: <2452291.zQQ4fSp1fM@home.alkar.net> <2837017.6IXeElfWaT@home.alkar.net> <20121211071334.GS48639@glebius.int.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: Gleb Smirnoff , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 10:16:18 -0000 # route add default 192.168.1.1 fiboptlist_csv: arg default, ret 846422615, str "0" route: fiboptlist_csv failed. On Tuesday 11 December 2012 11:13:34 Gleb Smirnoff wrote: > Artyom, > > can you please run route with attached patch and show output? > > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 10:21:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D327A1A8; Tue, 11 Dec 2012 10:21:23 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id AA7818FC0C; Tue, 11 Dec 2012 10:21:23 +0000 (UTC) Received: from notebook.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 0A4A4E604A; Tue, 11 Dec 2012 05:21:23 -0500 (EST) From: Artyom Mirgorodskiy To: Gleb Smirnoff Subject: Re: rev 244030 route command is not working Date: Tue, 11 Dec 2012 12:21:20 +0200 Message-ID: <13928549.1YcT8qshV5@notebook.alkar.net> User-Agent: KMail/4.9.3 (FreeBSD/10.0-CURRENT; KDE/4.9.3; amd64; ; ) In-Reply-To: <1740464.YojJrNfMlV@notebook.alkar.net> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121211071334.GS48639@glebius.int.ru> <1740464.YojJrNfMlV@notebook.alkar.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 10:21:23 -0000 Gleb, when I reset errno at the begin of fiboptlist_csv() everything work as expected. On Tuesday 11 December 2012 12:16:13 Artyom Mirgorodskiy wrote: > # route add default 192.168.1.1 > fiboptlist_csv: arg default, ret 846422615, str "0" > route: fiboptlist_csv failed. > > > On Tuesday 11 December 2012 11:13:34 Gleb Smirnoff wrote: > > Artyom, > > > > can you please run route with attached patch and show output? > > > > > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 12:07:06 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 898AA19C; Tue, 11 Dec 2012 12:07:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 01FF48FC0C; Tue, 11 Dec 2012 12:07:05 +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 qBBC730N091931; Tue, 11 Dec 2012 16:07:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBBC73tC091930; Tue, 11 Dec 2012 16:07:03 +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, 11 Dec 2012 16:07:03 +0400 From: Gleb Smirnoff To: Artyom Mirgorodskiy Subject: Re: rev 244030 route command is not working Message-ID: <20121211120703.GI48639@glebius.int.ru> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121211071334.GS48639@glebius.int.ru> <1740464.YojJrNfMlV@notebook.alkar.net> <13928549.1YcT8qshV5@notebook.alkar.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VdOwlNaOFKGAtAAV" Content-Disposition: inline In-Reply-To: <13928549.1YcT8qshV5@notebook.alkar.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 12:07:06 -0000 --VdOwlNaOFKGAtAAV Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Tue, Dec 11, 2012 at 12:21:20PM +0200, Artyom Mirgorodskiy wrote: A> Gleb, when I reset errno at the begin of fiboptlist_csv() everything work as expected. Artyom, can you please test attached patch? -- Totus tuus, Glebius. --VdOwlNaOFKGAtAAV Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="route.c.diff" Index: route.c =================================================================== --- route.c (revision 244082) +++ route.c (working copy) @@ -271,8 +271,7 @@ case 0: case 1: fib[i] = strtol(token, &endptr, 0); - if (*endptr != '\0' || (fib[i] == 0 && - (errno == EINVAL || errno == ERANGE))) + if (*endptr != '\0') error = 1; break; default: @@ -336,8 +335,7 @@ goto fiboptlist_csv_ret; } else { fib = strtol(token, &endptr, 0); - if (*endptr != '\0' || (fib == 0 && - (errno == EINVAL || errno == ERANGE))) { + if (*endptr != '\0') { error = 1; goto fiboptlist_csv_ret; } --VdOwlNaOFKGAtAAV-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 12:20:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91AF3610; Tue, 11 Dec 2012 12:20:13 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 4FABE8FC0C; Tue, 11 Dec 2012 12:20:11 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 05C2EE604A; Tue, 11 Dec 2012 07:20:05 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: rev 244030 route command is not working Date: Tue, 11 Dec 2012 14:19:41 +0200 Message-ID: <1492816.70p1QBTjMS@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: <20121211120703.GI48639@glebius.int.ru> References: <2452291.zQQ4fSp1fM@home.alkar.net> <13928549.1YcT8qshV5@notebook.alkar.net> <20121211120703.GI48639@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gleb Smirnoff , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 12:20:13 -0000 Works fine On Tuesday 11 December 2012 16:07:03 Gleb Smirnoff wrote: > On Tue, Dec 11, 2012 at 12:21:20PM +0200, Artyom Mirgorodskiy wrote: > A> Gleb, when I reset errno at the begin of fiboptlist_csv() everything work as expected. > > Artyom, > > can you please test attached patch? > > > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 21:35:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01CFC2A9; Tue, 11 Dec 2012 21:35:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF528FC0C; Tue, 11 Dec 2012 21:35:47 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so4224524lbb.13 for ; Tue, 11 Dec 2012 13:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ESXuCeGmmSGPfMTPhMJwJWWoTf0ky3eMPo04WS32fTA=; b=fAUtMhiIjIrZkW8LySHoQY76iQrW53j0aEI4vnhcTNmcY2RuHorG0lob90Oykd+OD/ M2ZpBq12daoCKBX76OwwIUHopfRVLI/MFwvqkaikke3235McHf7iUdKveu9amS86QDjB wiO1enwWxbi3+XiW6fO462R10pyoxZn628kHsCU7XCShUs/agP2SPtoH8cFfm+oil5ly oaI180EF/PhOkl4ZkuD8dTa/+ZXh+H6hwh/FRyDBYmOgniGUsY0ToHSpMoHFbK9qgftj aP1HVcBEVDZwdKw/mNZpZ+wvgVG7Q7PfFkCgKB/SpZl6T35cPCC0ZvTlfXfEbHLySlQ0 /qCg== MIME-Version: 1.0 Received: by 10.112.16.69 with SMTP id e5mr7742168lbd.43.1355261746894; Tue, 11 Dec 2012 13:35:46 -0800 (PST) Received: by 10.112.99.70 with HTTP; Tue, 11 Dec 2012 13:35:46 -0800 (PST) In-Reply-To: References: <50B6598B.20200@FreeBSD.org> Date: Tue, 11 Dec 2012 13:35:46 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 21:35:49 -0000 On Mon, Dec 10, 2012 at 1:25 PM, Garrett Cooper wrote: ... Going back in time a until the start of November didn't help. This zpool get version for both of the pools is quite interesting -- in particular, why is the value unset ("-")? I've provided the zdb -C info as well (just in case) (interesting why things are ordered the way they are in the zdb output -- not sure if it matters or not). I unset cachefile on the zpool (set it to `none` before according to the documentation's list of accepted values). I rebooted the box and still ran into mounting issues... Going to try to keep on working on this for a couple more iterations before I give up and move one of the drives to UFS or reformat with ZFS using gjb's livecd. Thanks, -Garrett # zpool get version root NAME PROPERTY VALUE SOURCE root version - default # zpool get version scratch NAME PROPERTY VALUE SOURCE scratch version 28 local # zpool upgrade scratch This system supports ZFS pool feature flags. Successfully upgraded 'scratch' from version 28 to feature flags. Enabled the following features on 'scratch': async_destroy empty_bpobj # zpool get version scratch NAME PROPERTY VALUE SOURCE scratch version - default # zdb -e -C root MOS Configuration: version: 5000 name: 'root' state: 0 txg: 100769 pool_guid: 16626214580045724926 hostid: 820800805 hostname: '' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 16626214580045724926 children[0]: type: 'disk' id: 0 guid: 9546056018082780826 path: '/dev/da0p3' phys_path: '/dev/da0p3' whole_disk: 1 metaslab_array: 31 metaslab_shift: 30 ashift: 9 asize: 172685787136 is_log: 0 create_txg: 4 features_for_read: # zdb -C scratch MOS Configuration: name: 'scratch' state: 0 txg: 95459 pool_guid: 4958045391345281734 hostid: 820800805 hostname: 'gran-tourismo.west.isilon.com' vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 4958045391345281734 children[0]: type: 'disk' id: 0 guid: 5020728737590777479 path: '/dev/da1p1' phys_path: '/dev/da1p1' whole_disk: 1 metaslab_array: 33 metaslab_shift: 29 ashift: 9 asize: 80021553152 is_log: 0 DTL: 70 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 17800508717108910354 path: '/dev/da2p1' phys_path: '/dev/da2p1' whole_disk: 1 metaslab_array: 30 metaslab_shift: 29 ashift: 9 asize: 80021553152 is_log: 0 DTL: 71 create_txg: 4 features_for_read: version: 5000 From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 21:55:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B74ADC5F; Tue, 11 Dec 2012 21:55:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDEB8FC17; Tue, 11 Dec 2012 21:55:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF6rx1CDaFvO/2dsb2JhbAA9CIY3uC9zgh4BAQEDAQEBASAEJyALGw4KAgINGQIpAQkmBggHBAEIFASHagYMqF+CQJBBgSKLKAsMBA2DCIETA4hginmCLoEcjyyDEYFIBxce X-IronPort-AV: E=Sophos;i="4.84,262,1355115600"; d="scan'208";a="4387206" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 11 Dec 2012 16:55:52 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 22248B3EE4; Tue, 11 Dec 2012 16:55:52 -0500 (EST) Date: Tue, 11 Dec 2012 16:55:52 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1814631088.1331228.1355262952071.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121211045225.GY3013@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 21:55:59 -0000 Konstantin Belousov wrote: > On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > > > Adrian Chadd wrote: > > > > > .. what was the previous kernel version? > > > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > > the hangs on a Sept. 7 kernel from head and I do see them > > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > > > > > It seems to predate my commit (r244008), which was my first > > > > concern. > > > > > > > > I use old single core i386 hardware and can fairly reliably > > > > reproduce it by doing a kernel build and a "svn checkout" > > > > concurrently. No NFS activity. These are running on a local > > > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > > > GENERIC for i386. If you want me to start a "binary search" > > > > for which rNNNNNN, I can do that, but it will take a while.:-) > > > > > > > > I can get out into DDB, but I'll admit I don't know enough > > > > about it to know where to look;-) > > > > Here's some lines from "db> ps", in case they give someone > > > > useful information. (I can leave this box sitting in DB for > > > > the rest of to-day, in case someone can suggest what I should > > > > look for on it.) > > > > > > > > Just snippets... > > > > Ss pause adjkerntz > > > > DL sdflush [sofdepflush] > > > > RL [syncer] > > > > DL vlruwt [vnlru] > > > > DL psleep [bufdaemon] > > > > RL [pagezero] > > > > DL psleep [vmdaemon] > > > > DL psleep [pagedaemon] > > > > DL ccb_scan [xpt_thrd] > > > > DL waiting_ [sctp_iterator] > > > > DL ctl_work [ctl_thrd] > > > > DL cooling [acpi_cooling0] > > > > DL tzpoll [acpi_thermal] > > > > DL (threaded) [usb] > > > > ... > > > > DL - [yarrow] > > > > DL (threaded) [geom] > > > > D - [g_down] > > > > D - [g_up] > > > > D - [g_event] > > > > RL (threaded) [intr] > > > > I [irq15: ata1] > > > > ... > > > > Run CPU0 [swi6: Giant taskq] > > > > --> does this one indicate the CPU is actually running this? > > > > (after a db> cont, wait a while db> ps > > > > it is still the same) > > > > I [swi4: clock] > > > > I [swi1: netisr 0] > > > > I [swi3: vm] > > > > RL [idle: cpu0] > > > > SLs wait [init] > > > > DL audit_wo [audit] > > > > DLs (threaded) [kernel] > > > > D - [deadlkres] > > > > ... > > > > D sched [swapper] > > > > > > > > I have no idea if this "ps" output helps, unless it indicates > > > > that it is looping on the Giant taskq? > > > Might be. You could do 'bt ' for the process to see where it > > > loops. > > > Another good set of hints is at > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > Kostik, you must be clairvoyant;-) > > > > When I did "show alllocks", I found that the syncer process held > > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 > > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > > The trace for this process goes like: > > spinlock_exit > > mtx_unlock_spin_flags > > kern_yield > > _mnt_vnode_next_active > > vnode_next_active > > vfs_msync() > > > > So, it seems like your r244095 commit might have fixed this? > > (I'm not good at this stuff, but from your description, it looks > > like it did the kern_yield() with the mutex held and "maybe" > > got into trouble trying to acquire Giant?) > > > > Anyhow, I'm going to test a kernel with r244095 in it and see > > if I can still reproduce the hang. > > (There wasn't much else in the "show alllocks", except a > > process that held the exclusive vnode interlock mutex plus > > a ufs vnode lock, but it's just doing a witness_unlock.) > There must be a thread blocked for the mount interlock for the loop > in the mnt_vnode_next_active to cause livelock. > Yes. I am getting hangs with the -current kernel and they seem easier for me to reproduce. For the one I just did, the "syncer" seems to be blocked at VI_TRYLOCK() in _mnt_vnode_next_active(). The vnode interlock mutex is eclusively locked by a "sh" process (11627). Now, here is where it gets weird... When I do a "db> trace 11627" I get the following: witness_unlock+0x1f3 (subr_witness.c:1563) mtx_unlock_flags+0x9f (kern_mutex.c:250) vdropl+0x63 (vfs_subr.c:2405) vputx+0x130 (vfs_subr.c:2116) vput+0x10 (vfs_subr.c:2319) vm_mmap+0x52e (vm_mmap.c:1341) sys_mmap So, it seems this process is stuck while trying to unlock the mutex, if that makes any sense... When I look at subr_witness.c around 1563, I can't see why anything would block there? (here's the code snippet) if ((instance->li_flags & LI_EXCLUSIVE) == 0 && witness_watch > 0 && (flags & LOP_EXCLUSIVE) != 0) { printf("exclusive unlock of (%s) %s @ %s:%d\n", class->lc_name, lock->lo_name, fixup_filename(file), line); printf("while share locked from %s:%d\n", fixup_filename(instance->li_file), instance->li_line); panic("share->uexcl"); } /* If we are recursed, unrecurse. */ *1563* if ((instance->li_flags & LI_RECURSEMASK) > 0) { CTR4(KTR_WITNESS, "%s: pid %d unrecursed on %s r=%d", __func__, td->td_proc->p_pid, instance->li_lock->lo_name, instance->li_flags); instance->li_flags--; return; } /* The lock is now being dropped, check for NORELEASE flag */ if ((instance->li_flags & LI_NORELEASE) != 0 && witness_watch > 0) { printf("forbidden unlock of (%s) %s @ %s:%d\n", class->lc_name, lock->lo_name, fixup_filename(file), line); So, what is really going on is still a mystery to me. (I do see interrupt stuff on the "bt"'s from the debugger, if that means anything?) rick > > > > I'll email if/when I know more, rick > > ps: Fingers/toes crossed that you've already fixed it. > > > > > > > > > > > > > As I said, I can leave it in "db" for to-day, if anyone wants > > > > me to do anything in the debugger and I can probably reproduce > > > > it, if someone wants stuff tried later. > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > adrian > > > > > > > > > > > > > > > On 9 December 2012 22:08, Tim Kientzle > > > > > wrote: > > > > > > I haven't found any useful clues yet, but thought I'd ask if > > > > > > anyone > > > > > > else > > > > > > was seeing hangs in a recent kernel. > > > > > > > > > > > > I just upgraded to r244036 using a straight GENERIC i386 > > > > > > kernel. > > > > > > (Straight buildworld/buildkernel, no local changes, > > > > > > /etc/src.conf > > > > > > doesn't > > > > > > exist, /etc/make.conf just has PERL_VERSION defined.) > > > > > > > > > > > > When I try to cross build an ARM world on the resulting > > > > > > system, > > > > > > the entire system hangs hard after about 30 minutes: No > > > > > > network, > > > > > > no keyboard response, no nothing. > > > > > > > > > > > > Don't know if it's relevant, but the system is using NFS > > > > > > pretty > > > > > > heavily (Parallels VM mounting NFS from Mac OS 10.7 host.) > > > > > > > > > > > > I'll try to get some more details ... > > > > > > > > > > > > Tim > > > > > > > > > > > > _______________________________________________ > > > > > > 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" > > > > > _______________________________________________ > > > > > 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" > > > > _______________________________________________ > > > > 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 Tue Dec 11 21:57:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1B4EE64; Tue, 11 Dec 2012 21:57:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2C968FC1C; Tue, 11 Dec 2012 21:57:45 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so4241321lbb.13 for ; Tue, 11 Dec 2012 13:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=l9fgXn+eJHZ7R8wo7HD2Pes39WQxuHwxBw0R4CFQSzg=; b=KZ6/H4ZkF1B79sonKHTUomykT4LyExvPkSyTvdDK8FPK2rrDH84wcG9Hj6gjiSxool mFfekgljPAoQpsyI7r3gVufJ2uOxokiBSKyRwCJS6+BFH0LRqDeqAqLGDsz5G3epBaNt 5HBT6NRcUbPZPGP9/aUIscmpO6lrmipafAraFhh7eZpNtcuIO3f6OALDjiupXiCxsB+x 9OldOTULn6TFUgG/dCFeL+uM2cHSy+uMk8+/MBmN2K9zcKpDF/kiX82jAoygkj+1sADP 6IWCJZOBEUDqvNA7qnaBnM8TPNJ1Pd5o3JgeFQbskzonTeqn1rMvbwxuW9PR26uUfGt/ T+HA== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr7819681lbz.75.1355263064433; Tue, 11 Dec 2012 13:57:44 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.84.193 with HTTP; Tue, 11 Dec 2012 13:57:44 -0800 (PST) In-Reply-To: <1814631088.1331228.1355262952071.JavaMail.root@erie.cs.uoguelph.ca> References: <20121211045225.GY3013@kib.kiev.ua> <1814631088.1331228.1355262952071.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 11 Dec 2012 21:57:44 +0000 X-Google-Sender-Auth: xZ1KTekmbZLp_tbFHYqNmc73Ymw Message-ID: Subject: Re: r244036 kernel hangs under load. From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@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: Tue, 11 Dec 2012 21:57:46 -0000 On Tue, Dec 11, 2012 at 9:55 PM, Rick Macklem wrote: > Konstantin Belousov wrote: >> On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: >> > Konstantin Belousov wrote: >> > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: >> > > > Adrian Chadd wrote: >> > > > > .. what was the previous kernel version? >> > > > > >> > > > Hopefully Tim has it narrowed down more, but I don't see >> > > > the hangs on a Sept. 7 kernel from head and I do see them >> > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) >> > > > >> > > > It seems to predate my commit (r244008), which was my first >> > > > concern. >> > > > >> > > > I use old single core i386 hardware and can fairly reliably >> > > > reproduce it by doing a kernel build and a "svn checkout" >> > > > concurrently. No NFS activity. These are running on a local >> > > > disk (UFS/FFS). (The kernel I reproduce it on is built via >> > > > GENERIC for i386. If you want me to start a "binary search" >> > > > for which rNNNNNN, I can do that, but it will take a while.:-) >> > > > >> > > > I can get out into DDB, but I'll admit I don't know enough >> > > > about it to know where to look;-) >> > > > Here's some lines from "db> ps", in case they give someone >> > > > useful information. (I can leave this box sitting in DB for >> > > > the rest of to-day, in case someone can suggest what I should >> > > > look for on it.) >> > > > >> > > > Just snippets... >> > > > Ss pause adjkerntz >> > > > DL sdflush [sofdepflush] >> > > > RL [syncer] >> > > > DL vlruwt [vnlru] >> > > > DL psleep [bufdaemon] >> > > > RL [pagezero] >> > > > DL psleep [vmdaemon] >> > > > DL psleep [pagedaemon] >> > > > DL ccb_scan [xpt_thrd] >> > > > DL waiting_ [sctp_iterator] >> > > > DL ctl_work [ctl_thrd] >> > > > DL cooling [acpi_cooling0] >> > > > DL tzpoll [acpi_thermal] >> > > > DL (threaded) [usb] >> > > > ... >> > > > DL - [yarrow] >> > > > DL (threaded) [geom] >> > > > D - [g_down] >> > > > D - [g_up] >> > > > D - [g_event] >> > > > RL (threaded) [intr] >> > > > I [irq15: ata1] >> > > > ... >> > > > Run CPU0 [swi6: Giant taskq] >> > > > --> does this one indicate the CPU is actually running this? >> > > > (after a db> cont, wait a while db> ps >> > > > it is still the same) >> > > > I [swi4: clock] >> > > > I [swi1: netisr 0] >> > > > I [swi3: vm] >> > > > RL [idle: cpu0] >> > > > SLs wait [init] >> > > > DL audit_wo [audit] >> > > > DLs (threaded) [kernel] >> > > > D - [deadlkres] >> > > > ... >> > > > D sched [swapper] >> > > > >> > > > I have no idea if this "ps" output helps, unless it indicates >> > > > that it is looping on the Giant taskq? >> > > Might be. You could do 'bt ' for the process to see where it >> > > loops. >> > > Another good set of hints is at >> > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html >> > >> > Kostik, you must be clairvoyant;-) >> > >> > When I did "show alllocks", I found that the syncer process held >> > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 >> > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 >> > The trace for this process goes like: >> > spinlock_exit >> > mtx_unlock_spin_flags >> > kern_yield >> > _mnt_vnode_next_active >> > vnode_next_active >> > vfs_msync() >> > >> > So, it seems like your r244095 commit might have fixed this? >> > (I'm not good at this stuff, but from your description, it looks >> > like it did the kern_yield() with the mutex held and "maybe" >> > got into trouble trying to acquire Giant?) >> > >> > Anyhow, I'm going to test a kernel with r244095 in it and see >> > if I can still reproduce the hang. >> > (There wasn't much else in the "show alllocks", except a >> > process that held the exclusive vnode interlock mutex plus >> > a ufs vnode lock, but it's just doing a witness_unlock.) >> There must be a thread blocked for the mount interlock for the loop >> in the mnt_vnode_next_active to cause livelock. >> > Yes. I am getting hangs with the -current kernel and they seem > easier for me to reproduce. Can you report the svn rev number is kernel is built from? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:10:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FB5F2EC; Tue, 11 Dec 2012 22:10:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5E78FC08; Tue, 11 Dec 2012 22:10:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBBMAHBZ037416; Wed, 12 Dec 2012 00:10:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBBMAHBZ037416 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBBMAH65037415; Wed, 12 Dec 2012 00:10:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Dec 2012 00:10:17 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121211221017.GC3013@kib.kiev.ua> References: <20121211045225.GY3013@kib.kiev.ua> <1814631088.1331228.1355262952071.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rlMgvmd72ait5qJG" Content-Disposition: inline In-Reply-To: <1814631088.1331228.1355262952071.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 22:10:27 -0000 --rlMgvmd72ait5qJG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > > > Konstantin Belousov wrote: > > > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > > > > Adrian Chadd wrote: > > > > > > .. what was the previous kernel version? > > > > > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > > > the hangs on a Sept. 7 kernel from head and I do see them > > > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > > > > > > > It seems to predate my commit (r244008), which was my first > > > > > concern. > > > > > > > > > > I use old single core i386 hardware and can fairly reliably > > > > > reproduce it by doing a kernel build and a "svn checkout" > > > > > concurrently. No NFS activity. These are running on a local > > > > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > > > > GENERIC for i386. If you want me to start a "binary search" > > > > > for which rNNNNNN, I can do that, but it will take a while.:-) > > > > > > > > > > I can get out into DDB, but I'll admit I don't know enough > > > > > about it to know where to look;-) > > > > > Here's some lines from "db> ps", in case they give someone > > > > > useful information. (I can leave this box sitting in DB for > > > > > the rest of to-day, in case someone can suggest what I should > > > > > look for on it.) > > > > > > > > > > Just snippets... > > > > > Ss pause adjkerntz > > > > > DL sdflush [sofdepflush] > > > > > RL [syncer] > > > > > DL vlruwt [vnlru] > > > > > DL psleep [bufdaemon] > > > > > RL [pagezero] > > > > > DL psleep [vmdaemon] > > > > > DL psleep [pagedaemon] > > > > > DL ccb_scan [xpt_thrd] > > > > > DL waiting_ [sctp_iterator] > > > > > DL ctl_work [ctl_thrd] > > > > > DL cooling [acpi_cooling0] > > > > > DL tzpoll [acpi_thermal] > > > > > DL (threaded) [usb] > > > > > ... > > > > > DL - [yarrow] > > > > > DL (threaded) [geom] > > > > > D - [g_down] > > > > > D - [g_up] > > > > > D - [g_event] > > > > > RL (threaded) [intr] > > > > > I [irq15: ata1] > > > > > ... > > > > > Run CPU0 [swi6: Giant taskq] > > > > > --> does this one indicate the CPU is actually running this? > > > > > (after a db> cont, wait a while db> ps > > > > > it is still the same) > > > > > I [swi4: clock] > > > > > I [swi1: netisr 0] > > > > > I [swi3: vm] > > > > > RL [idle: cpu0] > > > > > SLs wait [init] > > > > > DL audit_wo [audit] > > > > > DLs (threaded) [kernel] > > > > > D - [deadlkres] > > > > > ... > > > > > D sched [swapper] > > > > > > > > > > I have no idea if this "ps" output helps, unless it indicates > > > > > that it is looping on the Giant taskq? > > > > Might be. You could do 'bt ' for the process to see where it > > > > loops. > > > > Another good set of hints is at > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handboo= k/kerneldebug-deadlocks.html > > > > > > Kostik, you must be clairvoyant;-) > > > > > > When I did "show alllocks", I found that the syncer process held > > > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 > > > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > > > The trace for this process goes like: > > > spinlock_exit > > > mtx_unlock_spin_flags > > > kern_yield > > > _mnt_vnode_next_active > > > vnode_next_active > > > vfs_msync() > > > > > > So, it seems like your r244095 commit might have fixed this? > > > (I'm not good at this stuff, but from your description, it looks > > > like it did the kern_yield() with the mutex held and "maybe" > > > got into trouble trying to acquire Giant?) > > > > > > Anyhow, I'm going to test a kernel with r244095 in it and see > > > if I can still reproduce the hang. > > > (There wasn't much else in the "show alllocks", except a > > > process that held the exclusive vnode interlock mutex plus > > > a ufs vnode lock, but it's just doing a witness_unlock.) > > There must be a thread blocked for the mount interlock for the loop > > in the mnt_vnode_next_active to cause livelock. > >=20 > Yes. I am getting hangs with the -current kernel and they seem > easier for me to reproduce. >=20 > For the one I just did, the "syncer" seems to be blocked at > VI_TRYLOCK() in _mnt_vnode_next_active(). trylock cannot block. > The vnode interlock mutex is eclusively locked by a "sh" > process (11627). Now, here is where it gets weird... > When I do a "db> trace 11627" I get the following: > witness_unlock+0x1f3 (subr_witness.c:1563) > mtx_unlock_flags+0x9f (kern_mutex.c:250) > vdropl+0x63 (vfs_subr.c:2405) > vputx+0x130 (vfs_subr.c:2116) > vput+0x10 (vfs_subr.c:2319) > vm_mmap+0x52e (vm_mmap.c:1341) > sys_mmap >=20 > So, it seems this process is stuck while trying to unlock > the mutex, if that makes any sense... It probably not stuck, but just you catched it at this moment. The issue sounds more like a livelock. Can you obtain _all_ the information listed in the deadlock debugging page I sent earlier, and provide it to me ? Also, do you use the post-r244095 kernel ? Is your machine SMP ? --rlMgvmd72ait5qJG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQx69JAAoJEJDCuSvBvK1BDIIP/izQ62iN/xcPlL5i2pZ8gf+J HCNtmgX1rKuKKf7asTyxdugvjjjKFE+asQcrsLII3e1jyCoWhQ5yPuqzwrA1waQn 6sCeLwSEd4HgFE8AGkE//1+RoaNbzlnZoX1O+C8gtZJhcermjbM9qPLGzX1bonui wfldWJKx62clUk4W1ZsRlpNeMFb87ZgiEBjq6v/gZh6x4GF29M5UqzN+Zt7guhXo ijfDWhpF1i63kqKvNEB2Ps0LsShzgKWnt5k88XzC0i0BowluerKmtf4n7Pe7DbNA N57hPOVhapTJKau+sPH6KXOe5tWV0YlJJVzcc7i9St60D/TIN15jxUgR9vZsh/2u L6n7YWkjBy9efBKY7vbIN+iapyzOaocB2fXeQXaJWEYm0/eZ+AO5oELwi0C1cI60 A7TagpfS0Pwn7xmHekbJTJoLF2H4Yhkp1Hchm2Or0JB+PRNXl+V3DObQz0pu48Zz /Pnpl2PfNKUezo3uTpUAY51hcPHxdeLoFn7Y+RMjMNai8LzpMniYr5C6+RH54CVM KjxdxkyxZKJWnuxmYJkDB5ANz8DM7ll87CweUpvZQJy/VOm9zpKRAWmmjLaleTc3 rZjpdthhXmE0j2r8aUDUVWdnFPjVqE6akgqD2cJN+7CGgZJ8ZIWOxiFkR3XrHO8t rMoWJDZhHr5Buq2Ynbe4 =Orc8 -----END PGP SIGNATURE----- --rlMgvmd72ait5qJG-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:21:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 032B4674; Tue, 11 Dec 2012 22:21:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C82D28FC0C; Tue, 11 Dec 2012 22:21:10 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 30BD1B987; Tue, 11 Dec 2012 17:21:10 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: ath0: unable to attach hardware Date: Tue, 11 Dec 2012 15:49:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212111549.49942.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Dec 2012 17:21:10 -0500 (EST) Cc: husyh@hush.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 22:21:11 -0000 On Monday, December 10, 2012 5:20:53 pm Adrian Chadd wrote: > Hi, > > The fact the initial probe/attach fails by returning 0xffffffff means > the chip isn't "right" on the bus. > > It's either just not mapped in correctly, or it's "powered off." > > If it were just asleep, it'd return 0xdeadc0de or 0xdeadbeef or > something similar like that. > > Try AR_SCR (0x4004) and AR_PCICFG (0x4010) . > > Thanks, Look, it's up to you to look at more registers if you want to debug this further. PCI says everything is ok, so the ball is in your court. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:30:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C22C931; Tue, 11 Dec 2012 22:30:32 +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 E545A8FC12; Tue, 11 Dec 2012 22:30:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPayx1CDaFvO/2dsb2JhbAA9CIY3uC9zgh4BAQQBIwRSGw4KAgINGQJZBhyIAgYMqGCCQJBBgSKLKBeDGYETA4hgjSeQSIMRggQ X-IronPort-AV: E=Sophos;i="4.84,262,1355115600"; d="scan'208";a="4068203" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Dec 2012 17:30:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F2A53B3F13; Tue, 11 Dec 2012 17:30:24 -0500 (EST) Date: Tue, 11 Dec 2012 17:30:24 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <757455047.1332148.1355265024983.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121211221017.GC3013@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 22:30:32 -0000 Konstantin Belousov wrote: > On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > > > > > Adrian Chadd wrote: > > > > > > > .. what was the previous kernel version? > > > > > > > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > > > > the hangs on a Sept. 7 kernel from head and I do see them > > > > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > > > > > > > > > It seems to predate my commit (r244008), which was my first > > > > > > concern. > > > > > > > > > > > > I use old single core i386 hardware and can fairly reliably > > > > > > reproduce it by doing a kernel build and a "svn checkout" > > > > > > concurrently. No NFS activity. These are running on a local > > > > > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > > > > > GENERIC for i386. If you want me to start a "binary search" > > > > > > for which rNNNNNN, I can do that, but it will take a > > > > > > while.:-) > > > > > > > > > > > > I can get out into DDB, but I'll admit I don't know enough > > > > > > about it to know where to look;-) > > > > > > Here's some lines from "db> ps", in case they give someone > > > > > > useful information. (I can leave this box sitting in DB for > > > > > > the rest of to-day, in case someone can suggest what I > > > > > > should > > > > > > look for on it.) > > > > > > > > > > > > Just snippets... > > > > > > Ss pause adjkerntz > > > > > > DL sdflush [sofdepflush] > > > > > > RL [syncer] > > > > > > DL vlruwt [vnlru] > > > > > > DL psleep [bufdaemon] > > > > > > RL [pagezero] > > > > > > DL psleep [vmdaemon] > > > > > > DL psleep [pagedaemon] > > > > > > DL ccb_scan [xpt_thrd] > > > > > > DL waiting_ [sctp_iterator] > > > > > > DL ctl_work [ctl_thrd] > > > > > > DL cooling [acpi_cooling0] > > > > > > DL tzpoll [acpi_thermal] > > > > > > DL (threaded) [usb] > > > > > > ... > > > > > > DL - [yarrow] > > > > > > DL (threaded) [geom] > > > > > > D - [g_down] > > > > > > D - [g_up] > > > > > > D - [g_event] > > > > > > RL (threaded) [intr] > > > > > > I [irq15: ata1] > > > > > > ... > > > > > > Run CPU0 [swi6: Giant taskq] > > > > > > --> does this one indicate the CPU is actually running this? > > > > > > (after a db> cont, wait a while db> ps > > > > > > it is still the same) > > > > > > I [swi4: clock] > > > > > > I [swi1: netisr 0] > > > > > > I [swi3: vm] > > > > > > RL [idle: cpu0] > > > > > > SLs wait [init] > > > > > > DL audit_wo [audit] > > > > > > DLs (threaded) [kernel] > > > > > > D - [deadlkres] > > > > > > ... > > > > > > D sched [swapper] > > > > > > > > > > > > I have no idea if this "ps" output helps, unless it > > > > > > indicates > > > > > > that it is looping on the Giant taskq? > > > > > Might be. You could do 'bt ' for the process to see where > > > > > it > > > > > loops. > > > > > Another good set of hints is at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > > > > > Kostik, you must be clairvoyant;-) > > > > > > > > When I did "show alllocks", I found that the syncer process held > > > > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 > > > > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > > > > The trace for this process goes like: > > > > spinlock_exit > > > > mtx_unlock_spin_flags > > > > kern_yield > > > > _mnt_vnode_next_active > > > > vnode_next_active > > > > vfs_msync() > > > > > > > > So, it seems like your r244095 commit might have fixed this? > > > > (I'm not good at this stuff, but from your description, it looks > > > > like it did the kern_yield() with the mutex held and "maybe" > > > > got into trouble trying to acquire Giant?) > > > > > > > > Anyhow, I'm going to test a kernel with r244095 in it and see > > > > if I can still reproduce the hang. > > > > (There wasn't much else in the "show alllocks", except a > > > > process that held the exclusive vnode interlock mutex plus > > > > a ufs vnode lock, but it's just doing a witness_unlock.) > > > There must be a thread blocked for the mount interlock for the > > > loop > > > in the mnt_vnode_next_active to cause livelock. > > > > > Yes. I am getting hangs with the -current kernel and they seem > > easier for me to reproduce. > > > > For the one I just did, the "syncer" seems to be blocked at > > VI_TRYLOCK() in _mnt_vnode_next_active(). > trylock cannot block. > > > The vnode interlock mutex is eclusively locked by a "sh" > > process (11627). Now, here is where it gets weird... > > When I do a "db> trace 11627" I get the following: > > witness_unlock+0x1f3 (subr_witness.c:1563) > > mtx_unlock_flags+0x9f (kern_mutex.c:250) > > vdropl+0x63 (vfs_subr.c:2405) > > vputx+0x130 (vfs_subr.c:2116) > > vput+0x10 (vfs_subr.c:2319) > > vm_mmap+0x52e (vm_mmap.c:1341) > > sys_mmap > > > > So, it seems this process is stuck while trying to unlock > > the mutex, if that makes any sense... > It probably not stuck, but just you catched it at this moment. > > The issue sounds more like a livelock. Can you obtain _all_ the > information > listed in the deadlock debugging page I sent earlier, and provide it > to > me ? Well, this is a laptop and when it hangs (doesn't do anything, except sometimes echo characters on the console screen) I to get to DB. How can I capture the stuff? (I don't even have a digital camera. Sorry, but I'm not into that sort of thing.) When I do a "db> cont" and then another , what I get looks the same, so I don't think I'm just getting what is happening "at that moment". I'll start a binary search on kernel revision #s and try to narrow it down to a commit. It will take a while, but... Also, do you use the post-r244095 kernel ? Before and after. The most recent tests were post-r244095. (If anything the more recent kernels hang more easily.) > > Is your machine SMP ? Old, slow single core i386. rick From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:38:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEF72E6A; Tue, 11 Dec 2012 22:38:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4D61C8FC19; Tue, 11 Dec 2012 22:38:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBBMcd9R040025; Wed, 12 Dec 2012 00:38:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBBMcd9R040025 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBBMcd2S040024; Wed, 12 Dec 2012 00:38:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Dec 2012 00:38:39 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121211223839.GE3013@kib.kiev.ua> References: <20121211221017.GC3013@kib.kiev.ua> <757455047.1332148.1355265024983.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5HJtbU+CBezNQ5Mu" Content-Disposition: inline In-Reply-To: <757455047.1332148.1355265024983.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 22:38:44 -0000 --5HJtbU+CBezNQ5Mu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 05:30:24PM -0500, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote: > > > Konstantin Belousov wrote: > > > > On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > > > > > Konstantin Belousov wrote: > > > > > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote: > > > > > > > Adrian Chadd wrote: > > > > > > > > .. what was the previous kernel version? > > > > > > > > > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > > > > > the hangs on a Sept. 7 kernel from head and I do see them > > > > > > > on a Dec. 3 kernel from head. (Don't know the eact rNNNNNN.) > > > > > > > > > > > > > > It seems to predate my commit (r244008), which was my first > > > > > > > concern. > > > > > > > > > > > > > > I use old single core i386 hardware and can fairly reliably > > > > > > > reproduce it by doing a kernel build and a "svn checkout" > > > > > > > concurrently. No NFS activity. These are running on a local > > > > > > > disk (UFS/FFS). (The kernel I reproduce it on is built via > > > > > > > GENERIC for i386. If you want me to start a "binary search" > > > > > > > for which rNNNNNN, I can do that, but it will take a > > > > > > > while.:-) > > > > > > > > > > > > > > I can get out into DDB, but I'll admit I don't know enough > > > > > > > about it to know where to look;-) > > > > > > > Here's some lines from "db> ps", in case they give someone > > > > > > > useful information. (I can leave this box sitting in DB for > > > > > > > the rest of to-day, in case someone can suggest what I > > > > > > > should > > > > > > > look for on it.) > > > > > > > > > > > > > > Just snippets... > > > > > > > Ss pause adjkerntz > > > > > > > DL sdflush [sofdepflush] > > > > > > > RL [syncer] > > > > > > > DL vlruwt [vnlru] > > > > > > > DL psleep [bufdaemon] > > > > > > > RL [pagezero] > > > > > > > DL psleep [vmdaemon] > > > > > > > DL psleep [pagedaemon] > > > > > > > DL ccb_scan [xpt_thrd] > > > > > > > DL waiting_ [sctp_iterator] > > > > > > > DL ctl_work [ctl_thrd] > > > > > > > DL cooling [acpi_cooling0] > > > > > > > DL tzpoll [acpi_thermal] > > > > > > > DL (threaded) [usb] > > > > > > > ... > > > > > > > DL - [yarrow] > > > > > > > DL (threaded) [geom] > > > > > > > D - [g_down] > > > > > > > D - [g_up] > > > > > > > D - [g_event] > > > > > > > RL (threaded) [intr] > > > > > > > I [irq15: ata1] > > > > > > > ... > > > > > > > Run CPU0 [swi6: Giant taskq] > > > > > > > --> does this one indicate the CPU is actually running this? > > > > > > > (after a db> cont, wait a while db> ps > > > > > > > it is still the same) > > > > > > > I [swi4: clock] > > > > > > > I [swi1: netisr 0] > > > > > > > I [swi3: vm] > > > > > > > RL [idle: cpu0] > > > > > > > SLs wait [init] > > > > > > > DL audit_wo [audit] > > > > > > > DLs (threaded) [kernel] > > > > > > > D - [deadlkres] > > > > > > > ... > > > > > > > D sched [swapper] > > > > > > > > > > > > > > I have no idea if this "ps" output helps, unless it > > > > > > > indicates > > > > > > > that it is looping on the Giant taskq? > > > > > > Might be. You could do 'bt ' for the process to see where > > > > > > it > > > > > > loops. > > > > > > Another good set of hints is at > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-han= dbook/kerneldebug-deadlocks.html > > > > > > > > > > Kostik, you must be clairvoyant;-) > > > > > > > > > > When I did "show alllocks", I found that the syncer process held > > > > > - exclusive sleep mutex mount mtx locked @ kern/vfs_subr.c:4720 > > > > > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > > > > > The trace for this process goes like: > > > > > spinlock_exit > > > > > mtx_unlock_spin_flags > > > > > kern_yield > > > > > _mnt_vnode_next_active > > > > > vnode_next_active > > > > > vfs_msync() > > > > > > > > > > So, it seems like your r244095 commit might have fixed this? > > > > > (I'm not good at this stuff, but from your description, it looks > > > > > like it did the kern_yield() with the mutex held and "maybe" > > > > > got into trouble trying to acquire Giant?) > > > > > > > > > > Anyhow, I'm going to test a kernel with r244095 in it and see > > > > > if I can still reproduce the hang. > > > > > (There wasn't much else in the "show alllocks", except a > > > > > process that held the exclusive vnode interlock mutex plus > > > > > a ufs vnode lock, but it's just doing a witness_unlock.) > > > > There must be a thread blocked for the mount interlock for the > > > > loop > > > > in the mnt_vnode_next_active to cause livelock. > > > > > > > Yes. I am getting hangs with the -current kernel and they seem > > > easier for me to reproduce. > > > > > > For the one I just did, the "syncer" seems to be blocked at > > > VI_TRYLOCK() in _mnt_vnode_next_active(). > > trylock cannot block. > >=20 > > > The vnode interlock mutex is eclusively locked by a "sh" > > > process (11627). Now, here is where it gets weird... > > > When I do a "db> trace 11627" I get the following: > > > witness_unlock+0x1f3 (subr_witness.c:1563) > > > mtx_unlock_flags+0x9f (kern_mutex.c:250) > > > vdropl+0x63 (vfs_subr.c:2405) > > > vputx+0x130 (vfs_subr.c:2116) > > > vput+0x10 (vfs_subr.c:2319) > > > vm_mmap+0x52e (vm_mmap.c:1341) > > > sys_mmap > > > > > > So, it seems this process is stuck while trying to unlock > > > the mutex, if that makes any sense... > > It probably not stuck, but just you catched it at this moment. > >=20 > > The issue sounds more like a livelock. Can you obtain _all_ the > > information > > listed in the deadlock debugging page I sent earlier, and provide it > > to > > me ? > Well, this is a laptop and when it hangs (doesn't do anything, except > sometimes echo characters on the console screen) I > to get to DB. How can I capture the stuff? (I don't even have a digital > camera. Sorry, but I'm not into that sort of thing.) >=20 > When I do a "db> cont" and then another , what I > get looks the same, so I don't think I'm just getting what is > happening "at that moment". It could be that it happens in rapid succession. >=20 > I'll start a binary search on kernel revision #s and try to > narrow it down to a commit. It will take a while, but... It is not useful, I just know that it is a consequence of the r243599+r243835, but I expected that r244095 would help. Still, if you have single-core machine, than it is possible that it is a livelock, or rather, a crawl. >=20 > Also, do you use the post-r244095 kernel ? >=20 > Before and after. The most recent tests were post-r244095. > (If anything the more recent kernels hang more easily.) >=20 >=20 > >=20 > > Is your machine SMP ? >=20 > Old, slow single core i386. Try this. Please note that this is mostly a debugging facility. diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 67e078d..0905eec 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4727,7 +4727,7 @@ restart: continue; } if (!VI_TRYLOCK(vp)) { - if (should_yield()) { + if (1 || should_yield()) { mtx_unlock(&vnode_free_list_mtx); kern_yield(PRI_UNCHANGED); mtx_lock(&vnode_free_list_mtx); @@ -4778,7 +4778,7 @@ restart: continue; } if (!VI_TRYLOCK(vp)) { - if (should_yield()) { + if (1 || should_yield()) { mtx_unlock(&vnode_free_list_mtx); kern_yield(PRI_UNCHANGED); mtx_lock(&vnode_free_list_mtx); --5HJtbU+CBezNQ5Mu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQx7XuAAoJEJDCuSvBvK1BblUP/1ii7bcK36IPwpAuHdULFSXQ s9FaMyc9+3k/98RukRS+dbmMIegMnl/VdZcfoe/+H+BFEMO1LcYt61+/R43tn/K2 OPH4ik6jURbWYzp7P33ciYQ6+svHn0VYglKVkLh9TPG8sMAL7y2nnrAEC7JUyPC/ q1Yaf439wjyLwePPL2efyzjNwcO2FwfCW4jLfTKNcELIp/zLe3vxv3TwVv0NPV6G gW1Wk0JtnKUO/lLYiQCkCa1ilynp/J4pcY+zHilNEOrqV3Q5vCxAy+Pr/lmGQzFo gi8F36NxcLtVLxxVu9CxDndAzKTO25yxRELGOoVcHdSx1bh7mLqKKCgFd/GEHwco vcKdpCA05zLWRs8NuzkjLlMrEzzckLwjpFmGH49fGK4A2FskD54BvR00KR/u7/fZ YUMPZxk7H9FTkw8CPEoAYZcffwMS22bNwkJdFESQlp2NmJVF4QP66JDSNuCGxdLF VR43537S2FnKO6vmgyCpKYuh6DpspgV7bkSqPNS9q2Qb+b7L2kf12ZnqceCASzhI tSImbcNTtiEMSzexsGUaCAmMzvYQxhc3u5O4yLmfgmvHVoRCzCVb8pKctY81lMyM Ue3npE04UvFYAVRd3vg85qFlRW7dkaw/xFIpIZUTL5z9hsr3iot5Xd46hRXyQgIV mqGT+puYeS746Ahyg9o4 =pvep -----END PGP SIGNATURE----- --5HJtbU+CBezNQ5Mu-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 23:36:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25392AB1; Tue, 11 Dec 2012 23:36:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 834558FC1B; Tue, 11 Dec 2012 23:36:17 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so27175wib.13 for ; Tue, 11 Dec 2012 15:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r1fNM3olyhwSXPPsfrVCB+DaVmarWo1GXWB4ttonG+s=; b=oi+raA1Anl8iR8qn8hnC1+TtfupP0lbYOCKVa++ZLo2jlkbwCwtegK9Hjnv49iURgz m/BRr+mH/6rYgndhaZ71tW1QI3hFJy7XGSHkcaPiuSvm2S0L8oMVu7UrH1ywf9sOMNOC agAJnAcSEGyKQR7DOE12Kat62SSAuAaeKQ6VYfNNbfZJ0JagiYqHkIURnfjESaWVR7fh hgJeETzN1FFTwvGt7tlSzwSQ6S3pEpJ2NgSv/IMrkXyWF3j2PlaOPpFarf4DO48Ipy1k miNt82eWJSUcWA0CVafv9rCeOJ/cqHpA12mI5G+2d0EqQFQ9Qr1BBOR6WdayHci9WAJi AZXQ== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr3412839wjc.1.1355268976176; Tue, 11 Dec 2012 15:36:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 11 Dec 2012 15:36:16 -0800 (PST) In-Reply-To: <201212111549.49942.jhb@freebsd.org> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <201212111549.49942.jhb@freebsd.org> Date: Tue, 11 Dec 2012 15:36:16 -0800 X-Google-Sender-Auth: puAHLI3Ar1rr3iFn6cvy95eqAuY Message-ID: Subject: Re: ath0: unable to attach hardware From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: husyh@hush.com, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 11 Dec 2012 23:36:18 -0000 On 11 December 2012 12:49, John Baldwin wrote: > Look, it's up to you to look at more registers if you want to debug this > further. PCI says everything is ok, so the ball is in your court. Right, that's why I've asked for those two above registers. There are other things that could be wrong - eg, the device may actually not have reset correctly. This isn't the first time that someone's come to me with a "linux works, freebsd doesn't" for an AR5212 era NIC. ath5k and FreeBSD do the same thing at probe/attach time. I believe they do the same thing during device power-on time too. There's some corner cases where the chip doesn't reset right because the BIOS PCI bus reset code does things in a brain dead manner (eg doing two PCI bus resets back to back with not enough time in between for the MAC to settle.) There may be PCI code differences in how Linux and FreeBSD does things like "reset the PCI bus." Adrian From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 01:58:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FB1018B; Wed, 12 Dec 2012 01:58:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF1C8FC12; Wed, 12 Dec 2012 01:58:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAKDjx1CDaFvO/2dsb2JhbAA9CIY3uEVzgh4BAQQBIwRSBRYOCgICDRkCWQYciAIGDKh+gkCQOYEiiygLDIMZgRMDiGCNJ5BIgxGBTzU X-IronPort-AV: E=Sophos;i="4.84,263,1355115600"; d="scan'208";a="4414737" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 11 Dec 2012 20:58:47 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 01B27B4081; Tue, 11 Dec 2012 20:58:47 -0500 (EST) Date: Tue, 11 Dec 2012 20:58:47 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <2088105020.1335870.1355277527941.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121211223839.GE3013@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 01:58:50 -0000 Konstantin Belousov wrote: > On Tue, Dec 11, 2012 at 05:30:24PM -0500, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote: > > > > > > Konstantin Belousov wrote: > > > > > > > On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem > > > > > > > wrote: > > > > > > > > Adrian Chadd wrote: > > > > > > > > > .. what was the previous kernel version? > > > > > > > > > > > > > > > > > Hopefully Tim has it narrowed down more, but I don't see > > > > > > > > the hangs on a Sept. 7 kernel from head and I do see > > > > > > > > them > > > > > > > > on a Dec. 3 kernel from head. (Don't know the eact > > > > > > > > rNNNNNN.) > > > > > > > > > > > > > > > > It seems to predate my commit (r244008), which was my > > > > > > > > first > > > > > > > > concern. > > > > > > > > > > > > > > > > I use old single core i386 hardware and can fairly > > > > > > > > reliably > > > > > > > > reproduce it by doing a kernel build and a "svn > > > > > > > > checkout" > > > > > > > > concurrently. No NFS activity. These are running on a > > > > > > > > local > > > > > > > > disk (UFS/FFS). (The kernel I reproduce it on is built > > > > > > > > via > > > > > > > > GENERIC for i386. If you want me to start a "binary > > > > > > > > search" > > > > > > > > for which rNNNNNN, I can do that, but it will take a > > > > > > > > while.:-) > > > > > > > > > > > > > > > > I can get out into DDB, but I'll admit I don't know > > > > > > > > enough > > > > > > > > about it to know where to look;-) > > > > > > > > Here's some lines from "db> ps", in case they give > > > > > > > > someone > > > > > > > > useful information. (I can leave this box sitting in DB > > > > > > > > for > > > > > > > > the rest of to-day, in case someone can suggest what I > > > > > > > > should > > > > > > > > look for on it.) > > > > > > > > > > > > > > > > Just snippets... > > > > > > > > Ss pause adjkerntz > > > > > > > > DL sdflush [sofdepflush] > > > > > > > > RL [syncer] > > > > > > > > DL vlruwt [vnlru] > > > > > > > > DL psleep [bufdaemon] > > > > > > > > RL [pagezero] > > > > > > > > DL psleep [vmdaemon] > > > > > > > > DL psleep [pagedaemon] > > > > > > > > DL ccb_scan [xpt_thrd] > > > > > > > > DL waiting_ [sctp_iterator] > > > > > > > > DL ctl_work [ctl_thrd] > > > > > > > > DL cooling [acpi_cooling0] > > > > > > > > DL tzpoll [acpi_thermal] > > > > > > > > DL (threaded) [usb] > > > > > > > > ... > > > > > > > > DL - [yarrow] > > > > > > > > DL (threaded) [geom] > > > > > > > > D - [g_down] > > > > > > > > D - [g_up] > > > > > > > > D - [g_event] > > > > > > > > RL (threaded) [intr] > > > > > > > > I [irq15: ata1] > > > > > > > > ... > > > > > > > > Run CPU0 [swi6: Giant taskq] > > > > > > > > --> does this one indicate the CPU is actually running > > > > > > > > this? > > > > > > > > (after a db> cont, wait a while db> > > > > > > > > ps > > > > > > > > it is still the same) > > > > > > > > I [swi4: clock] > > > > > > > > I [swi1: netisr 0] > > > > > > > > I [swi3: vm] > > > > > > > > RL [idle: cpu0] > > > > > > > > SLs wait [init] > > > > > > > > DL audit_wo [audit] > > > > > > > > DLs (threaded) [kernel] > > > > > > > > D - [deadlkres] > > > > > > > > ... > > > > > > > > D sched [swapper] > > > > > > > > > > > > > > > > I have no idea if this "ps" output helps, unless it > > > > > > > > indicates > > > > > > > > that it is looping on the Giant taskq? > > > > > > > Might be. You could do 'bt ' for the process to see > > > > > > > where > > > > > > > it > > > > > > > loops. > > > > > > > Another good set of hints is at > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > > > > > > > > > Kostik, you must be clairvoyant;-) > > > > > > > > > > > > When I did "show alllocks", I found that the syncer process > > > > > > held > > > > > > - exclusive sleep mutex mount mtx locked @ > > > > > > kern/vfs_subr.c:4720 > > > > > > - exclusive lockmgr syncer locked @ kern/vfs_subr.c:1780 > > > > > > The trace for this process goes like: > > > > > > spinlock_exit > > > > > > mtx_unlock_spin_flags > > > > > > kern_yield > > > > > > _mnt_vnode_next_active > > > > > > vnode_next_active > > > > > > vfs_msync() > > > > > > > > > > > > So, it seems like your r244095 commit might have fixed this? > > > > > > (I'm not good at this stuff, but from your description, it > > > > > > looks > > > > > > like it did the kern_yield() with the mutex held and > > > > > > "maybe" > > > > > > got into trouble trying to acquire Giant?) > > > > > > > > > > > > Anyhow, I'm going to test a kernel with r244095 in it and > > > > > > see > > > > > > if I can still reproduce the hang. > > > > > > (There wasn't much else in the "show alllocks", except a > > > > > > process that held the exclusive vnode interlock mutex plus > > > > > > a ufs vnode lock, but it's just doing a witness_unlock.) > > > > > There must be a thread blocked for the mount interlock for the > > > > > loop > > > > > in the mnt_vnode_next_active to cause livelock. > > > > > > > > > Yes. I am getting hangs with the -current kernel and they seem > > > > easier for me to reproduce. > > > > > > > > For the one I just did, the "syncer" seems to be blocked at > > > > VI_TRYLOCK() in _mnt_vnode_next_active(). > > > trylock cannot block. > > > > > > > The vnode interlock mutex is eclusively locked by a "sh" > > > > process (11627). Now, here is where it gets weird... > > > > When I do a "db> trace 11627" I get the following: > > > > witness_unlock+0x1f3 (subr_witness.c:1563) > > > > mtx_unlock_flags+0x9f (kern_mutex.c:250) > > > > vdropl+0x63 (vfs_subr.c:2405) > > > > vputx+0x130 (vfs_subr.c:2116) > > > > vput+0x10 (vfs_subr.c:2319) > > > > vm_mmap+0x52e (vm_mmap.c:1341) > > > > sys_mmap > > > > > > > > So, it seems this process is stuck while trying to unlock > > > > the mutex, if that makes any sense... > > > It probably not stuck, but just you catched it at this moment. > > > > > > The issue sounds more like a livelock. Can you obtain _all_ the > > > information > > > listed in the deadlock debugging page I sent earlier, and provide > > > it > > > to > > > me ? > > Well, this is a laptop and when it hangs (doesn't do anything, > > except > > sometimes echo characters on the console screen) I > > to get to DB. How can I capture the stuff? (I don't even have a > > digital > > camera. Sorry, but I'm not into that sort of thing.) > > > > When I do a "db> cont" and then another , what I > > get looks the same, so I don't think I'm just getting what is > > happening "at that moment". > It could be that it happens in rapid succession. > > > > > I'll start a binary search on kernel revision #s and try to > > narrow it down to a commit. It will take a while, but... > It is not useful, I just know that it is a consequence of the > r243599+r243835, but I expected that r244095 would help. Still, > if you have single-core machine, than it is possible that it is > a livelock, or rather, a crawl. > Ok, I'll test r243598 and then r243599 and r243835, just to see if it really is this. I'll email when I have done this. > > > > Also, do you use the post-r244095 kernel ? > > > > Before and after. The most recent tests were post-r244095. > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > Is your machine SMP ? > > > > Old, slow single core i386. > > Try this. Please note that this is mostly a debugging facility. > It seemed to help, but didn't stop the hangs completely. r244125 without the patch would hang somewhere in a kernel build. r244125 plus this patch ran almost 2 kernel builds before it got hung. > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index 67e078d..0905eec 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -4727,7 +4727,7 @@ restart: > continue; > } > if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > + if (1 || should_yield()) { > mtx_unlock(&vnode_free_list_mtx); > kern_yield(PRI_UNCHANGED); > mtx_lock(&vnode_free_list_mtx); > @@ -4778,7 +4778,7 @@ restart: > continue; > } > if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > + if (1 || should_yield()) { > mtx_unlock(&vnode_free_list_mtx); > kern_yield(PRI_UNCHANGED); > mtx_lock(&vnode_free_list_mtx); From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 04:35:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5CADEE0; Wed, 12 Dec 2012 04:35:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 450F98FC08; Wed, 12 Dec 2012 04:35:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBC4ZKjs075102; Wed, 12 Dec 2012 06:35:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBC4ZKjs075102 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBC4ZKEp075101; Wed, 12 Dec 2012 06:35:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Dec 2012 06:35:20 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121212043520.GF3013@kib.kiev.ua> References: <20121211223839.GE3013@kib.kiev.ua> <2088105020.1335870.1355277527941.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AmQwmWFbeMnnUgEL" Content-Disposition: inline In-Reply-To: <2088105020.1335870.1355277527941.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 04:35:27 -0000 --AmQwmWFbeMnnUgEL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: > Ok, I'll test r243598 and then r243599 and r243835, just to > see if it really is this. >=20 > I'll email when I have done this. If you test only r243598, I am sure that you would experience corruption. The r243599 should cause the deadlocks. >=20 > > > > > > Also, do you use the post-r244095 kernel ? > > > > > > Before and after. The most recent tests were post-r244095. > > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > > > > > Is your machine SMP ? > > > > > > Old, slow single core i386. > >=20 > > Try this. Please note that this is mostly a debugging facility. > >=20 > It seemed to help, but didn't stop the hangs completely. > r244125 without the patch would hang somewhere in a kernel > build. r244125 plus this patch ran almost 2 kernel builds > before it got hung. Can you try to look into the system state on the hang (on the kernel with the if (1 || patch applied) ? Using the ddb and recipe from the web page. Basically watch for a thread looping in the mnt_active iterator and threads owning vnode interlocks. --AmQwmWFbeMnnUgEL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQyAmHAAoJEJDCuSvBvK1BF6cP/jpwXtXJpWQ4eIu4tJlK2XMf aMCq8Srj4YdWqEy640Njo1MvV6jKMJLjgwN+qd1P/01ibUyamVgRq1r90eROWw8d mzuMqsGUgx1qrt7mpLv//BHA15qrG7j2rfpzSIBdNXHlTvhjj2zKuCyWl/crz+Rb ypcoCgQuWnAM+SPs9RhsjQd0U5hlsb4lhqvoJGpyR4lxKTYVbBbjgXwPM5dj6SuX aQV58CC9cYNKzvxFwqKALdWckIa5rf0pXKSH8kmVKFAIlfmJhOznSKocxomutVNV 3bZ+290882hmxxozwfIt141g8AbMU99drlfB3LGdvFrZ6JKAdhwyE8TpWNTRqTOx A0xZ4g+AIYjtXPIyO8az8liDlSE85jsI4GD9Ulbc8k9OHAWbxqP+BAlHl0AWBJQt /Vbjp8vuzuSl3BPvKHNHoG7iGaMnvu5TEok+l1FENLr7MKivWn7EaWohwbimETTm h8S8/ReiqEYp6064EHoEfddZ7cJiZCJ0O7cG43B/mqSnD72Hgll7SE3TDJNPiUUV MThWvGbDjrbssACSte2NHPULxJUGsXwvdrkFEHlzXpxHib9mOHlHPVmSg7OiCC1K URZD1f6hoLskqmuR7binP3dmt7+kJGXhRZ6/iddxuRjpppqCShY4VP11GwIufly5 WwCRjE4ZqIX7vvTuBxRe =h7vp -----END PGP SIGNATURE----- --AmQwmWFbeMnnUgEL-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 10:07:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49A63EE0 for ; Wed, 12 Dec 2012 10:07:51 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id D9F598FC0C for ; Wed, 12 Dec 2012 10:07:48 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1TijDh-0003uD-UQ for freebsd-current@freebsd.org; Wed, 12 Dec 2012 10:07:42 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TijDh-0007Xi-Jj for freebsd-current@freebsd.org; Wed, 12 Dec 2012 10:07:17 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id qBCA7HfC028407 for ; Wed, 12 Dec 2012 10:07:17 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id qBCA7Hu9028406 for freebsd-current@freebsd.org; Wed, 12 Dec 2012 10:07:17 GMT (envelope-from mexas) Date: Wed, 12 Dec 2012 10:07:17 GMT From: Anton Shterenlikht Message-Id: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org Subject: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat X-Spam-Score: -3.5 X-Spam-Level: --- X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:07:51 -0000 I updated to r244114 on ia64 following the standard procedure. I then get: # make check-old-libs >>> Checking for old libraries /lib/libz.so.5 # while sysutils/libchk shows: Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat and indeed these two executables depend on this library: # ldd /usr/sbin/dtrace /usr/sbin/dtrace: libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) libz.so.5 => /lib/libz.so.5 (0x2000000020210000) libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) libc.so.7 => /lib/libc.so.7 (0x2000000020294000) # ldd /usr/sbin/lockstat /usr/sbin/lockstat: libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) libz.so.5 => /lib/libz.so.5 (0x2000000020210000) librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) # I see that these two executables are old: # ls -al /usr/sbin/dtrace /usr/sbin/lockstat -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat # Does this mean that both dtrace and lockstat are obsolete and can be removed? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 13:04:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5186127B; Wed, 12 Dec 2012 13:04:33 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 501C68FC14; Wed, 12 Dec 2012 13:04:31 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so595663lah.13 for ; Wed, 12 Dec 2012 05:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dBeY2vQEtDb+ubQlKhMH8x583lRKGAadgenKXi3hxyM=; b=Rl9P4pCEcHsw2RlDWCnSk62U+26LVENHxdnneIX9G2gt/DK8hARovuKOkGvaI7T+Ni PvArIFAJLXGkzxeKfpD8i6tqvDBfAlF4ivTrmdJRgDozAW6gs5/cRW877+bbPtxiTSPI wX5unOXpNTI5V0wq02O+/tswkuvXT+P/qQFLzebW57OOnAAwaAkP+vJE7Vmudf8n6wfM QXdp6aEMqEM9ljOwVfrRlFvs9MkuU6y1em/exvNn9BkBEuun42toeUw+4r3JuFEHX3Tg ozwIM0OPj1SKghjXulIhyZ1Fs4V3klaTOdBgDcnxtzdDFXbUoZ2lvf9h6n7xjSnt6sEC rNxg== Received: by 10.152.108.48 with SMTP id hh16mr964882lab.25.1355317471103; Wed, 12 Dec 2012 05:04:31 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id ti4sm10660662lab.1.2012.12.12.05.04.27 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 05:04:29 -0800 (PST) Message-ID: <50C880D7.1040907@gmail.com> Date: Wed, 12 Dec 2012 15:04:23 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> In-Reply-To: <20121203224132.GJ3013@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, dim@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 13:04:33 -0000 04.12.2012 00:41, Konstantin Belousov: > Please try the patch below. It might give an immediate relief, but still > there are many offenders in the backtrace. I'm having almost the same issue and the patch doesn't work for me. Trying to mount root from zfs:limb0 []... Fatal double fault: eip = 0x835a6bce esp = 0x875c2fd4 ebp = 0x875c3018 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(8380283b,20646920,3030203d,3831000a,a3a000a,...) at db_trace_self_wrapper+0x36/frame 0x83a10f10 kdb_backtrace(8383658f,0,83837c3d,83a10fc0,0,...) at kdb_backtrace+0x30/frame 0x83a10f70 panic(83837c3d,0,0,0,875c3018,...) at panic+0x1bc/frame 0x83a10fb4 dblfault_handler() at cpu_fetch_syscall_args/frame 0x83a10fb4 --- trap 0x17, eip = 8x835a6bce, esp = 0x875c2fd4, ebp = 0x875c3018 --- witness_checkorder(843df808,9,8382a15c,7dd,0,...) at witness_checkorder+0x2e/frame 0x875c3018 _mtx_lock_flags(843df808,0,8382a15c,7dd,202,...) at _mtx_lock_flags+0x7a/frame 0x875c3040 uma_zalloc_arg(843de960,0,102,2,2,...) at uma_zalloc_arg+0x5df/franc 0x875c3090 malloc(38,83d03100,102,875c3138,83c01d1a,...) at malloc+0xe9/frame 0x875c30c0 zfs_kmem_alloc(38,102,8,83cab2fe,157,...) at zfs_kmem_alloc+0x20/frame 0x875c30d4 vdev_mirror_io_start(87e3eb20,10,B7e3eb20,1,87d3f618,...) at vdev_mirror_io_start+0x14a/frame 0x875c3138 zio_vdev_io_start(87e3eb20,8795dbcO,87e3eb20,875c3340,200,...) at zio_vdev_io_start+0x1a6/frame Ox875c3180 zio_execute(87e3eb20.87c8f000,880a0640,8807d400,200,...) at zio_execute+0x103/frame 0x875c31b0 spa_load_verify_cb(87c8f000,0,880a0640,87f7b708,875c3340,...) at spa_load_verify_cb+0x89/frame 0x875c31f0 traverse_visitbp(87f7b708,880a0640,875c3340,875c3db8,0,...) at traverse_visitbp+0x1e6/frame 0x875c3320 traverse_dnode(87f7b708,15,0,3,O,...) at traverse_dnode+0x92/frame 0x875c337O traverse_visitbp(87f7b6cc,880a4000,875c3520,87f7b744,83b92d10,...) at traverse_visitbp+0xc40/frame 0x875c34a0 traverse_visitbp(87f7b744,88096000,875c3650,87f7b834,83b92d10,...) at traverse_visitbp+0xd33/frame 0xB75c35d0 traverse_visitbp(87f7b834,88074000,875c3780,87f7b8ac,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3700 traverse_visitbp(87f7b8ac,8806c000,875c38b0,87f7b924,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3830 traverse_visitbp(87f7b924,88064000,875c39e0,87f7b99c,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3960 traverse_visitbp(87f7b99c,87fce000,875c3b10,87f7ba14,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3a90 traverse_visitbp(87f7ba14,88061040,875c3be0,875c3db8,0,...) at traverse_visitbp+0xd33/frame 0x875c3bc0 traverse_dnode(87f7ba14,15,0,0,0,...) at traverse_dnode+0x92/frame 0x875c3c10 traverse_visitbp(0,87f8ee80,875c3d68,2,834,...) at traverse_visitbp+0x822/frame 0x875c3d40 traverse_impl(15,0,87f8ee80,261400,0,...) at traverse_impl+0x268/frane 0x875c3df0 traverse_pool(87c8f000,261400,0,d,83bec290,...) at traverse_pool+0x273/frame 0x875c3e90 spa_load(0,1,875c4034,83ca82f2,8,...) at spa_load+0x1d8f/frame 0x875c3fa8 spa_load(0,0,83a48934,1,14,...) at spa_load+0x114c/frame 0x875c40c0 spa_load_best(0,ffffffff,ffffffff,1,0,...) at spa_load_best+0x71/frame 0x875c3e90 spa_open_common(83ca3ca6,0,0,875c42f0,83bb9dec,...) at spa_open_common+0x11a/frame 0x875c4174 spa_open(875c41e0,875c41dc,83ca3ca6,0,0,...) at spa_open+0x27/frame 0x875c4188 dsl_dir_open_spa(0,87d47350,83ca4039,875c4358,875c4354,...) at dsl_dir_open_spa+0x6c/frame 0x875c42f0 dsl_dataset_hold(87d47350,87a36000,875c43a0,87a36000,87a36000,...) at dsl_data_hold+0x3a/frame 0x875c436c dsl_dataset_own(87d47350,0,87a3600,875c43a0,83d01e30,...) at dsl_dataset_own+0x21/frame 0x875c4388 dmu_objset_own(87d4350,2,1,87a36000,875c43f0,...) at dmu_objset_own+0x2a/frame 0x875c43b0 zfsvfs_create(87d47350,875c4504,83cb0b68,68e,87d47350,...) at zfsvfs_create+0x4c/frame 0x875c4400 zfs_mount(87d40ce4,83cb5Bd0,87d46300,87957500,8384fd28,...) at zfs_mount+0x4a9/frame 0x875c4630 vfs_donmount(8795dbc0,4000,0,875c48b8,87d46380,...) at vfs_donmount+0xc94/frame 0x875c48a0 kernel_mount(87d473d0,4000,0,0,839de044,...) at kernel_mount+0x6b/frame 0x875c48e0 parse_mount(87d47400,8385a800,0,1,0,...) at parse_mount+0x622/frame 0x875c49f8 vfs_mountroot(83a491c4,4,837f68a2,2ba,0,...) at vfs_mountroot+0x6f1/frame 0x875c4c60 start_init(0,875c4d08,837f8f83,3d8,0,...) at start_init+0x6a/frame 0x875c4ccc fork_exit(835107b0,0,875c4d08) at fork_init+0x7c/frame 0x875c4cf4 fork_trampoline() at fork_trampoline+0x8/frame 0x875c4cf4 --- trap 0, eip = 0, esp = 0x875c4d40, ebp = O --- KDB: enter: panic [ thread pid 1 tid 100002 J Stopped at kdb_enter+0x3d: movl $O,kdb_why db> Source pictures are at https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault?authuser=0&feat=directlink just in case I missed something. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 13:29:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 057C1AD9; Wed, 12 Dec 2012 13:29:16 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 436BE8FC0C; Wed, 12 Dec 2012 13:29:14 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so652231lbb.13 for ; Wed, 12 Dec 2012 05:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=98Zyip4t+ArUdHmgSYyI6r6/z3c90glSub6bKLyggik=; b=ZEvqcovaneeZpexX+43efQqSnjM0lCiuxRi4wZLEF4aLcQFL1tZ7pSv3CSQB97j/mS jIQAgLhXm5+EndVqRxy6QcNPTDYwWlsNkpq7IePWwW7oHql79EsKOS7Z3hbtWhfYBFjl ZXk0jfLX475dR1E9o/WIBVBZpFnprOPzx35BWzmdWbF3FdWcxFto6cYvIZgzvG/piaKP MkqI7l50p5Kpe3jq6AnQWYti+R7oYgEyNLPQEMzAxUvgZTTv987lMM+9qNrxbH51Nqbi TWhuwQA66X3QwA3Mr7rjhZf+Vn9rS3rtxVL8bVXYmX5543Xjd2TmYZkpSRrmXMdLYaB+ XNNQ== MIME-Version: 1.0 Received: by 10.152.148.129 with SMTP id ts1mr1055076lab.19.1355318953832; Wed, 12 Dec 2012 05:29:13 -0800 (PST) Received: by 10.112.133.129 with HTTP; Wed, 12 Dec 2012 05:29:13 -0800 (PST) Date: Wed, 12 Dec 2012 13:29:13 +0000 Message-ID: Subject: Request for merge into 9.x From: Paul Webster To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: bschmidt@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 13:29:16 -0000 Hello I was recently reading about your work on the Ralink 2860, I run an EEEPC 1000 at the moment and have always wanted to run freebsd on it; however due to the wireless not being supported and a hatred for hanging usb dongles handing everywhere; I had to run linux. I am no driver developer, but I would love to give your driver a trial run on 9.1-RELEASE or -STABLE if easier, I am quite sure once everyone with an eeepc realizes we finally have a working wifi card; they will be most impressed :) as an aside, if you could leave me some simplish instructions on howto actually generate the kernel module in 9.0/9.1 -RELEASE I would happily report how well it works -- paul From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 13:52:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FE87481 for ; Wed, 12 Dec 2012 13:52:56 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id A76288FC08 for ; Wed, 12 Dec 2012 13:52:55 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Wed, 12 Dec 2012 14:52:47 +0100 Message-ID: <50C88C2B.4070007@ose.nl> Date: Wed, 12 Dec 2012 14:52:43 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, paul.g.webster@googlemail.com Subject: Re: Request for merge into 9.x References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 13:52:56 -0000 On 12/12/2012 02:29 PM, Paul Webster wrote: > Hello I was recently reading about your work on the Ralink 2860, I run > an EEEPC 1000 at the moment and have always wanted to run freebsd on > it; however due to the wireless not being supported and a hatred for > hanging usb dongles handing everywhere; I had to run linux. > > I am no driver developer, but I would love to give your driver a trial > run on 9.1-RELEASE or -STABLE if easier, I am quite sure once everyone > with an eeepc realizes we finally have a working wifi card; they will > be most impressed :) > > as an aside, if you could leave me some simplish instructions on howto > actually generate the kernel module in 9.0/9.1 -RELEASE I would > happily report how well it works > > -- paul There is work going on for this. You can keep an eye on http://wiki.freebsd.org/AsusEee Maybe this link can help you http://forums.freebsd.org/showthread.php?t=7010 It is on the wiki page also, just onder the tasks table. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 16:07:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81CD3F5; Wed, 12 Dec 2012 16:07:25 +0000 (UTC) (envelope-from rizzo.unipi@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 AAAEE8FC19; Wed, 12 Dec 2012 16:07:24 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so601057eek.13 for ; Wed, 12 Dec 2012 08:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MKkka79sc4v2qlQ1XM4y4J37XCnnAvG4aGw9OJmjqXg=; b=Vi1V1r1tkd2uB0MIUR7cutHw8gQdc7f4NQAZ3wsUt8qBb3aSTkd94g6nSuPe8koaTJ 5h+EAcxRVCQCd/xm96tOXa7Kvz8msgB0SZuf813qR6T5Gzjrt+zZAkCzjpnG9j5xbfnj n8PEctsJTb1uY/WEikE77NHvic6/LcKaG/SkbfcbJ3x3vOap+du3sjXCDjVdvbHqcfgX EIwkdC4zxyEKdOeWAZIPDBmfuT78jlKl24djDNIe1hX+tAzAf8ZRDdfUY8PNqu1wdFlx tEBZBaG8bOKIwWOz8jSyLfXyiTPAMLJMp0YSptPW8in8CO8XfSASgG1adnkfB0eAPwmV re+w== MIME-Version: 1.0 Received: by 10.14.218.69 with SMTP id j45mr3939049eep.35.1355328443512; Wed, 12 Dec 2012 08:07:23 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.0.2 with HTTP; Wed, 12 Dec 2012 08:07:23 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 08:07:23 -0800 X-Google-Sender-Auth: jfdIrtH66iHpJjpUJdYNNpJIbko Message-ID: Subject: Fwd: new pc-bios/bios.bin breaks freebsd booting From: Luigi Rizzo To: current@freebsd.org, emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: nox@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 16:07:25 -0000 it seems that qemu-1.3.0 is broken for freebsd... cheers luigi ---------- Forwarded message ---------- From: Luigi Rizzo Date: Wed, Dec 12, 2012 at 8:04 AM Subject: new pc-bios/bios.bin breaks freebsd booting To: qemu-devel@nongnu.org, kraxel@redhat.com I am not sure if it has been reported already but this commit http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 (replacing pc-bios/bios.bin with a newer version) breaks booting of FreeBSD on recent qemu (starting roughly with qemu- 1.3.0-rc2). Using a FreeBSD host, and a FreeBSD guest, the qemu thread runs at 100% and the console is stuck after the 'pci0' probe: ... hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 100000000 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Reverting the bios fixes things. I wonder if it isn't the case of reverting this change ? cheers luigi -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 16:14:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7656E5E9; Wed, 12 Dec 2012 16:14:36 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1141A8FC16; Wed, 12 Dec 2012 16:14:35 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so993309vba.13 for ; Wed, 12 Dec 2012 08:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iWRNdWiX0Fkpyc+j8elyWwtgi3lPfi5KXEZeurgVTL8=; b=GZZJaGuVGbL92HNHwupXvi6xg3/WORE0UF2wy4EgWvOp9slUT+nVX3E+sVAo7n+wKV ody2ST75ESDNSNiIlOspj+kFvINxNNoMSg+GnQdFE+KwboFizvaAmCHwLbLz2Fq8aS2W AUbeVIHjqv3J8khj3yQXnVf9Ln7xpvalEAgq1Xviodc/SycW/3atySfsm2uLBE3jNZcM /O6w/Gk2sDk1sZmbzj2ZNser+iM2VTSzSqwFiLdjsC4Miwam0JK4O3tusgDwoCLaBom8 rZHUBY9IIfgcL1czVXWwRMQSoMrcXGwJDD5RTqSyfzcbHCsVMYHnESSyaFLKN1Xuic2l mF6A== MIME-Version: 1.0 Received: by 10.220.115.133 with SMTP id i5mr799596vcq.42.1355328875239; Wed, 12 Dec 2012 08:14:35 -0800 (PST) Received: by 10.58.209.163 with HTTP; Wed, 12 Dec 2012 08:14:35 -0800 (PST) Date: Wed, 12 Dec 2012 18:14:35 +0200 Message-ID: Subject: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Kimmo Paasiala To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 16:14:36 -0000 Hello, My 9-STABLE buildworld broke in a very inexplicable way, I was getting an error on /usr/src/include/osreldate.h that I couldn't figure out until I started looking at the sys/conf/newvers.sh and what it does. It turned out that the thing that broke my buildworld was having .git directory at the root directory of the system because I recently started using GIT to track the configuration files. I added some debug echos to the newvers.sh and I found out it's setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set the gitdir to /.git and that seems to break the logic in newvers.sh. Isn't SYSDIR supposed to be set to the sys -subdirectory of the source tree (/usr/src/sys default)? I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in newvers.sh: SYSDIR=$(dirname $0)/.. $0 is actually /bin/sh and not the path to newver.sh because the newvers.sh is sourced by the Makefile in /usr/src/include instead of executing it: osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \ ${.CURDIR}/Makefile @${ECHO} creating osreldate.h from newvers.sh @MAKE=${MAKE}; \ PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ . ${.CURDIR}/../sys/conf/newvers.sh; \ Now the question is how to fix this? -Kimmo From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 16:52:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6D17398 for ; Wed, 12 Dec 2012 16:52:54 +0000 (UTC) (envelope-from swhetzel@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 2B6D58FC0A for ; Wed, 12 Dec 2012 16:52:53 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so641234eek.13 for ; Wed, 12 Dec 2012 08:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y+368HcfzwzZbWeOwcggVLyPD/CkbIil3BmTtKVMKHY=; b=EZwuN18gbuo5VPv/dMkm/ztKhNg3QqUpzT6vMTjaPPJ1yZD7SSmihIMJABusLJo0P2 0Qnvve84OOqHzB3I9KyeypRfekm50x2cBN0q97HycD1UX2sA+ki2UeOESWIUkQ15Z9VP TOS0VR6iw+zg4GVw47hNxhy2bwSZkDUpDw9p7Y+/pY173Alxf9phxzgjBRSI6sF44Ik2 dlC7dqJD141Y/MOGLRg45DEEoKrzgs8ccVYOrYEu7CJwQXUlX9SBJ0u6lpYO9ylKqsTe KBPKcrrjJydXi82X5pVMxwMkR4Q4ohGFw/LjFdOD9y/xVOaLyJzO4oSFlI8jQfq7ZvVq wq/g== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr4277671eef.25.1355331173133; Wed, 12 Dec 2012 08:52:53 -0800 (PST) Received: by 10.14.198.71 with HTTP; Wed, 12 Dec 2012 08:52:53 -0800 (PST) In-Reply-To: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> References: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> Date: Wed, 12 Dec 2012 10:52:53 -0600 Message-ID: Subject: Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat From: Scot Hetzel To: mexas@bristol.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 16:52:54 -0000 On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht wrote: > I updated to r244114 on ia64 following the > standard procedure. I then get: > > # make check-old-libs >>>> Checking for old libraries > /lib/libz.so.5 > # > > while sysutils/libchk shows: > > Binaries that are linked with: /lib/libz.so.5 > /usr/sbin/dtrace > /usr/sbin/lockstat > > and indeed these two executables depend > on this library: > > # ldd /usr/sbin/dtrace > /usr/sbin/dtrace: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) > libc.so.7 => /lib/libc.so.7 (0x2000000020294000) > # ldd /usr/sbin/lockstat > /usr/sbin/lockstat: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) > libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) > libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) > # > > I see that these two executables are old: > > # ls -al /usr/sbin/dtrace /usr/sbin/lockstat > -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace > -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat > # > > Does this mean that both dtrace and lockstat > are obsolete and can be removed? > These 2 programs are part of the CDDL liscensed code. Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it is defined, then you can remove them. Otherwise you'll need to determine why they are not being built/installed. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 16:54:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8EEE59E; Wed, 12 Dec 2012 16:54:02 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 456D38FC13; Wed, 12 Dec 2012 16:54:01 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBCGrtQZ033194; Wed, 12 Dec 2012 09:53:55 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBCGrpZN056726; Wed, 12 Dec 2012 09:53:51 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Ian Lepore To: Kimmo Paasiala In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Dec 2012 09:53:51 -0700 Message-ID: <1355331231.87661.461.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 16:54:02 -0000 On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote: > Hello, > > My 9-STABLE buildworld broke in a very inexplicable way, I was > getting an error on /usr/src/include/osreldate.h that I couldn't > figure out until I started looking at the sys/conf/newvers.sh and what > it does. It turned out that the thing that broke my buildworld was > having .git directory at the root directory of the system because I > recently started using GIT to track the configuration files. > > I added some debug echos to the newvers.sh and I found out it's > setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set > the gitdir to /.git and that seems to break the logic in newvers.sh. > > Isn't SYSDIR supposed to be set to the sys -subdirectory of the source > tree (/usr/src/sys default)? > > I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in > newvers.sh: > > SYSDIR=$(dirname $0)/.. > > $0 is actually /bin/sh and not the path to newver.sh because the > newvers.sh is sourced by the Makefile in /usr/src/include instead of > executing it: > > osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \ > ${.CURDIR}/Makefile > @${ECHO} creating osreldate.h from newvers.sh > @MAKE=${MAKE}; \ > PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ > . ${.CURDIR}/../sys/conf/newvers.sh; \ > > Now the question is how to fix this? > > -Kimmo Perhaps it could be handled similar to PARAMFILE, something like this in the makefile: PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ SYSDIR=${.CURDIR}/../sys; \ . ${.CURDIR}/../sys/conf/newvers.sh; \ I'm not sure if newvers.sh needs to work in ways that don't involve being invoked from that makefile rule, so to be safe it could have default handling, something like: : ${SYSDIR:=$(dirname $0)/..} -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:01:03 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F905AD6; Wed, 12 Dec 2012 17:01:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id AEB5C8FC17; Wed, 12 Dec 2012 17:01:02 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so2038416wgb.1 for ; Wed, 12 Dec 2012 09:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D4oQNplXGZfIz8lzwuisT1LpB45eGAIvZkxwAQk63a8=; b=FsIMPcoIccQ+Z3tfg4BcaR4NLXwhIovRkGimSsruLDrd26NE0ZHM6tIzKeWPtu8se7 eDm21EmejR06vV7AgAEo49xK8aiVTxkPV45wI1XCmRHcScEwEPoAEWwhtn5Rt1DH9Tx6 WtZO+XaV8q8RiFYMrhIBZz2dQdlKsCeCScw4qsxiMbX03HyomJAx2+SsqpsbWZw9uOsC 4Yxs+b072rG0Gn+nXCyHSiCBCrcMobGwZPCTbhOVZEWsziO9i2AyWoPg4hrMjyZokaKf L+4Z8kqaLiRzrmPeVwFCUTX2wHVDmp6HorzKbmt/rvdgFm9Cd6K1Nf8QN5mFzU91gRIm 3mGg== MIME-Version: 1.0 Received: by 10.194.120.132 with SMTP id lc4mr3179366wjb.59.1355331661297; Wed, 12 Dec 2012 09:01:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 12 Dec 2012 09:01:01 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 09:01:01 -0800 X-Google-Sender-Auth: LtESMmdSYGn_FpfK-G03etQjbOw Message-ID: Subject: Re: new pc-bios/bios.bin breaks freebsd booting From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: emulation@freebsd.org, nox@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 17:01:03 -0000 Yes, the qemu bios people decided that they could change the ACPI setup, in order to make Linux boot slightly (1 line) quieter. http://git.qemu.org/?p=seabios.git;a=commit;h=4540409d19a4baeec5006d925cfca19f8038a96e Adrian On 12 December 2012 08:07, Luigi Rizzo wrote: > it seems that qemu-1.3.0 is broken for freebsd... > > cheers > luigi > > ---------- Forwarded message ---------- > From: Luigi Rizzo > Date: Wed, Dec 12, 2012 at 8:04 AM > Subject: new pc-bios/bios.bin breaks freebsd booting > To: qemu-devel@nongnu.org, kraxel@redhat.com > > > I am not sure if it has been reported already but this commit > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 > > (replacing pc-bios/bios.bin with a newer version) > breaks booting of FreeBSD on recent qemu (starting roughly with qemu- > 1.3.0-rc2). > > Using a FreeBSD host, and a FreeBSD guest, > the qemu thread runs at 100% and the console is stuck > after the 'pci0' probe: > > > ... > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 100000000 Hz quality 950 > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > Reverting the bios fixes things. > I wonder if it isn't the case of reverting this change ? > > cheers > luigi > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > _______________________________________________ > 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 Wed Dec 12 17:02:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E9B3C2C for ; Wed, 12 Dec 2012 17:02:14 +0000 (UTC) (envelope-from swhetzel@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 044958FC08 for ; Wed, 12 Dec 2012 17:02:13 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so649102eek.13 for ; Wed, 12 Dec 2012 09:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bTH7Kkm9nUSJmp9Jsw+noaEnm8GhhBS97iupNyFcmKU=; b=mjgsnriSjdKwi64oQEw1nUZsqwmocMsWadisAxKxyKmDECMKwPzFqtvDwvOvLpj8Wa 014QyGbQicoY0clfs8UoryH8opK+e8mdoBLI6FVkVmCbxYhE++qRBoVWRitbZQ761x79 DZzuD6E7jM6H3yBIe/TcWaga7Z/csJeqxdGwUDV7uOjRvdKFPP0tpZeyma14cPzAPEil 0MrTnbDwtKSkFPkwgHywAc+gfiOyFdmVG5R2pY6R9BQr/H16u18h3CH+0zWEaQjAl/v8 raj1ZPAL4Zcn/P41ZPRgfgF7O9Vuasg0xlsFDYAGHT4tyqLaOJ1ui1jw4ZkgPwEBa8/6 pegg== MIME-Version: 1.0 Received: by 10.14.203.8 with SMTP id e8mr4356967eeo.2.1355331733068; Wed, 12 Dec 2012 09:02:13 -0800 (PST) Received: by 10.14.198.71 with HTTP; Wed, 12 Dec 2012 09:02:12 -0800 (PST) In-Reply-To: References: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> Date: Wed, 12 Dec 2012 11:02:12 -0600 Message-ID: Subject: Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat From: Scot Hetzel To: mexas@bristol.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 17:02:14 -0000 On Wed, Dec 12, 2012 at 10:52 AM, Scot Hetzel wrote: > On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht wrote: >> I updated to r244114 on ia64 following the >> standard procedure. I then get: >> >> # make check-old-libs >>>>> Checking for old libraries >> /lib/libz.so.5 >> # >> >> while sysutils/libchk shows: >> >> Binaries that are linked with: /lib/libz.so.5 >> /usr/sbin/dtrace >> /usr/sbin/lockstat >> >> and indeed these two executables depend >> on this library: >> >> # ldd /usr/sbin/dtrace >> /usr/sbin/dtrace: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) >> libz.so.5 => /lib/libz.so.5 (0x2000000020210000) >> libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) >> libc.so.7 => /lib/libc.so.7 (0x2000000020294000) >> # ldd /usr/sbin/lockstat >> /usr/sbin/lockstat: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) >> libz.so.5 => /lib/libz.so.5 (0x2000000020210000) >> librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) >> libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) >> libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) >> # >> >> I see that these two executables are old: >> >> # ls -al /usr/sbin/dtrace /usr/sbin/lockstat >> -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace >> -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat >> # >> >> Does this mean that both dtrace and lockstat >> are obsolete and can be removed? >> > These 2 programs are part of the CDDL liscensed code. > > Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it > is defined, then you can remove them. Otherwise you'll need to > determine why they are not being built/installed. > I had another look at cddl/usr.sbin/Makefile, and it only builds lockstat and dtrace for i386, amd64, and powerpc. It doesn't build them for ia64. So it is safe to remove them. -- DISCLAIMER: No electrons were mamedi while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:08:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF339352; Wed, 12 Dec 2012 17:08:56 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6178FC08; Wed, 12 Dec 2012 17:08:56 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id E74A639D5B; Thu, 13 Dec 2012 02:08:54 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id E3BEC39D46; Thu, 13 Dec 2012 02:08:54 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: Subject: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 13 Dec 2012 02:08:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 17:08:57 -0000 Hi, I've created FreeBSD clang world for RPI based on svn 244112 + eabi.diff(NOT USE) + few NetBSD code. I didn't test with "-mfloat-abi=softfp" but it might work. The first version is released at my Japanese blog: http://shell.peach.ne.jp/aoyama/archives/2357 Thank you for many comments to previous versions. Thank you for adding RPI support to FreeBSD. Thank you for porting latest clang to head! It's very useful for RPI developing now. You can get the pre-build image from my archives: http://www.peach.ne.jp/archives/rpi/ (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) Download and decompress it, then write it to SD. This image requires SD 4GB or more. I'm using as headless server. So, you need a serial console for seeing the boot log. If you need to change the value on it, please mount the second partition (e.g. /dev/da0s2a). If you want the video out, please remove the line of "set console=comconsole" in /boot/loader.rc. Note: first time, it takes about 2 minutes for generating the SSH keys. This version includes axe(ASIX AX88x7x/760) driver because smsc is not stable. Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify or edit /etc/make.conf. The initial setup code is taken from NetBSD. Using config is here: http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 Source and pacth is here: http://www.peach.ne.jp/archives/rpi/patch/ Pre-configured for: MEM 496MB/GPU 16MB/SWAP 512MB I/O: multi-console (primary serial) IP address: 192.168.1.240 Default router: 192.168.1.1 DNS: 192.168.1.1 sshd: enabled User: pi Password: raspberry Password(root): raspberry kernel section limit: TS=256MB, DS=1024MB, SS=256MB example of /etc/make.conf: ---------------------------------------------------------------------- WITHOUT_X11=yes WITH_CLANG=yes WITH_CLANG_IS_CC=yes # Now cc = clang is default #CC=clang #CXX=clang++ #CPP=clang-cpp # For clang NO_WERROR= WERROR= CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft # For gcc #CC=gcc #CXX=g++ #CPP=cpp ---------------------------------------------------------------------- How to use GPT USB stick in RPI: (if you use something, delete/destory it before doing) # gpart delete -i NN da0 # gpart destroy -F da0 (create new partition and format) # gpart create -s gpt da0 # gpart add -t freebsd-ufs da0 # gpart show # newfs -U -j /dev/da0p1 (mount it) # mount /dev/da0p1 /mnt ---------------------------------------------------------------------- Known problems: o SD card is not configured correctly. (power on/off need if it's failed) o hang the system. (unknown reason) o smsc is not stable. o alignment/padding is not same as gcc. (temporary avoid strict alignment now) o call both IDCACHE_WBINV_ALL and DCACHE_WB_RANGE at switch. (can't work without both) o still depend on GNU as (gas syntax). TODO: o modify/replace bcm2835 drivers. o using "clang -integrated-as". o fix alignment with clang. o self build. o use EABI if possible. o create build script :-) Enjoy clang world in Raspberry Pi! Thank you. -- Daisuke Aoyama From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:59:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4BD0799 for ; Wed, 12 Dec 2012 17:59:37 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 93AE68FC08 for ; Wed, 12 Dec 2012 17:59:37 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Tiqaj-0007QG-UF; Wed, 12 Dec 2012 17:59:36 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Tiqaj-0004Bd-OQ; Wed, 12 Dec 2012 17:59:33 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id qBCHxXSd030786; Wed, 12 Dec 2012 17:59:33 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id qBCHxXZl030785; Wed, 12 Dec 2012 17:59:33 GMT (envelope-from mexas) Date: Wed, 12 Dec 2012 17:59:33 GMT From: Anton Shterenlikht Message-Id: <201212121759.qBCHxXZl030785@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk, swhetzel@gmail.com Subject: Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat In-Reply-To: X-Spam-Score: -3.5 X-Spam-Level: --- Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:59:38 -0000 From swhetzel@gmail.com Wed Dec 12 17:55:00 2012 On Wed, Dec 12, 2012 at 10:52 AM, Scot Hetzel wrote: > On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht wrote: >> I updated to r244114 on ia64 following the >> standard procedure. I then get: >> >> # make check-old-libs >>>>> Checking for old libraries >> /lib/libz.so.5 >> # >> >> while sysutils/libchk shows: >> >> Binaries that are linked with: /lib/libz.so.5 >> /usr/sbin/dtrace >> /usr/sbin/lockstat >> >> and indeed these two executables depend >> on this library: >> >> # ldd /usr/sbin/dtrace >> /usr/sbin/dtrace: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) >> libz.so.5 => /lib/libz.so.5 (0x2000000020210000) >> libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) >> libc.so.7 => /lib/libc.so.7 (0x2000000020294000) >> # ldd /usr/sbin/lockstat >> /usr/sbin/lockstat: >> libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) >> libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) >> libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) >> libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) >> libz.so.5 => /lib/libz.so.5 (0x2000000020210000) >> librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) >> libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) >> libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) >> # >> >> I see that these two executables are old: >> >> # ls -al /usr/sbin/dtrace /usr/sbin/lockstat >> -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace >> -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat >> # >> >> Does this mean that both dtrace and lockstat >> are obsolete and can be removed? >> > These 2 programs are part of the CDDL liscensed code. > > Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it > is defined, then you can remove them. Otherwise you'll need to > determine why they are not being built/installed. > I had another look at cddl/usr.sbin/Makefile, and it only builds lockstat and dtrace for i386, amd64, and powerpc. It doesn't build them for ia64. So it is safe to remove them. ok, this makes sense, thanks Anton From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 18:14:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2DA8B58 for ; Wed, 12 Dec 2012 18:14:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 597C48FC13 for ; Wed, 12 Dec 2012 18:14:13 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1TiqZm-00069b-Fi; Wed, 12 Dec 2012 17:58:34 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TiqZl-0005di-UM; Wed, 12 Dec 2012 17:58:34 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id qBCHwXIj030780; Wed, 12 Dec 2012 17:58:33 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id qBCHwXQn030779; Wed, 12 Dec 2012 17:58:33 GMT (envelope-from mexas) Date: Wed, 12 Dec 2012 17:58:33 GMT From: Anton Shterenlikht Message-Id: <201212121758.qBCHwXQn030779@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk, swhetzel@gmail.com Subject: Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat In-Reply-To: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:14:13 -0000 From swhetzel@gmail.com Wed Dec 12 17:54:59 2012 On Wed, Dec 12, 2012 at 4:07 AM, Anton Shterenlikht wrote: > I updated to r244114 on ia64 following the > standard procedure. I then get: > > # make check-old-libs >>>> Checking for old libraries > /lib/libz.so.5 > # > > while sysutils/libchk shows: > > Binaries that are linked with: /lib/libz.so.5 > /usr/sbin/dtrace > /usr/sbin/lockstat > > and indeed these two executables depend > on this library: > > # ldd /usr/sbin/dtrace > /usr/sbin/dtrace: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) > libc.so.7 => /lib/libc.so.7 (0x2000000020294000) > # ldd /usr/sbin/lockstat > /usr/sbin/lockstat: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) > libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) > libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) > # > > I see that these two executables are old: > > # ls -al /usr/sbin/dtrace /usr/sbin/lockstat > -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace > -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat > # > > Does this mean that both dtrace and lockstat > are obsolete and can be removed? > These 2 programs are part of the CDDL liscensed code. Do you have WITHOUT_CDDL defined in your src.conf or make.conf? If it is defined, then you can remove them. Otherwise you'll need to determine why they are not being built/installed. UZI> cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 WITH_PKGNG=yes PERL_VERSION=5.16.2 UZI> UZI> ls /etc/src* ls: No match. UZI> I did the usual make buildworld, make buildkernel, make install kernel, reboot, make installworld. I didn't do anything unusual. Are you saying you've got these two files up to date? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 18:38:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D6D0FD7 for ; Wed, 12 Dec 2012 18:38:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id CE4A98FC0C for ; Wed, 12 Dec 2012 18:38:00 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id a19so5370720qad.13 for ; Wed, 12 Dec 2012 10:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jjfwIVcpgqYeL0mWuqRetH9fbdaXL+v01I2ntz0eHTs=; b=bC1kBZSX5qccDqSsdaN3GWjzeEWnHHtuC02gG0NYbI1yN2vEo8JyrW/jlIleYlt5rA 07t4Pti0yl69nzf6VKXmEZzp3oxZaZWtCw+0DrFboL5bpJJiVA0ZNEebczwaCCztDefF jXbvrYnzUrT+kOgy6F3grHZDMDB2PrGONLIPG2cIMDqp8z3nwcOU9JJmKNdRsf54hArx Y/JIgCvXlIOC+ilu52I1VjouzPeXw7Y+Fo5dT+eKttbUpD6h395Kqej8LCejN+Qrxobu dMUO23rVVHO+5lavi8lbcNBzEXavzom38jIEgHTfArgLknsUtK6Akc5CMkgTR1wNPGox 3vlA== MIME-Version: 1.0 Received: by 10.224.60.12 with SMTP id n12mr3681002qah.23.1355337038930; Wed, 12 Dec 2012 10:30:38 -0800 (PST) Received: by 10.229.78.96 with HTTP; Wed, 12 Dec 2012 10:30:38 -0800 (PST) In-Reply-To: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> References: <201212121007.qBCA7Hu9028406@mech-cluster241.men.bris.ac.uk> Date: Wed, 12 Dec 2012 21:30:38 +0300 Message-ID: Subject: Re: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat From: Sergey Kandaurov To: mexas@bristol.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 18:38:01 -0000 On 12 December 2012 14:07, Anton Shterenlikht wrote: > I updated to r244114 on ia64 following the > standard procedure. I then get: > > # make check-old-libs >>>> Checking for old libraries > /lib/libz.so.5 > # > > while sysutils/libchk shows: > > Binaries that are linked with: /lib/libz.so.5 > /usr/sbin/dtrace > /usr/sbin/lockstat > > and indeed these two executables depend > on this library: > > # ldd /usr/sbin/dtrace > /usr/sbin/dtrace: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > libthr.so.3 => /lib/libthr.so.3 (0x2000000020246000) > libc.so.7 => /lib/libc.so.7 (0x2000000020294000) > # ldd /usr/sbin/lockstat > /usr/sbin/lockstat: > libdtrace.so.2 => /lib/libdtrace.so.2 (0x2000000020094000) > libproc.so.2 => /usr/lib/libproc.so.2 (0x2000000020194000) > libctf.so.2 => /lib/libctf.so.2 (0x20000000201a8000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000201d0000) > libz.so.5 => /lib/libz.so.5 (0x2000000020210000) > librt.so.1 => /usr/lib/librt.so.1 (0x2000000020246000) > libthr.so.3 => /lib/libthr.so.3 (0x200000002025e000) > libc.so.7 => /lib/libc.so.7 (0x20000000202ac000) > # > > I see that these two executables are old: > > # ls -al /usr/sbin/dtrace /usr/sbin/lockstat > -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace > -r-xr-xr-x 1 root wheel 72832 Jul 18 2010 /usr/sbin/lockstat > # > > Does this mean that both dtrace and lockstat > are obsolete and can be removed? > Both binaries stopped building for ia64 since r210693 (Jul 31 2010). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 18:52:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D4C1AA5; Wed, 12 Dec 2012 18:52:54 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B453C8FC0A; Wed, 12 Dec 2012 18:52:53 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so1217458vcb.13 for ; Wed, 12 Dec 2012 10:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cx4BzxB5npuRhh4zciM8Bj17kzmkfm86NirkakabwJA=; b=gYZBNer2xsNaRdvCMaZobZYL6/oe2Oa6gEN3hfxd3yc7lx+LpPvxbTooiseKn0Poge VAUWg158GcBWtz3/3YDQY/G1K0qMci8czDPcjO0CGSr/4lvdPYtGD/KoMgWmrw9LZCeE Yme3LsNancRKPl6GnNJTGyBDHv7UpHs2EN4Ffo4G5s1toLue7eLA1rsXD59Zht28Nk/p aeAj6mxD3DwXUeL0o1vdM0MdTt19ZuvI7fA3U/VC5wk3qu08EdWDiTAVUGcczNCycuhD NNfy6q4LuWRiLIPSRD5FZGlXM8g2Qyh8SmL46Aog83nV8AHCVpg4cjDtKDvC6tsrByF2 eZ3A== MIME-Version: 1.0 Received: by 10.52.33.228 with SMTP id u4mr940246vdi.4.1355338373048; Wed, 12 Dec 2012 10:52:53 -0800 (PST) Received: by 10.58.209.163 with HTTP; Wed, 12 Dec 2012 10:52:52 -0800 (PST) In-Reply-To: <1355331231.87661.461.camel@revolution.hippie.lan> References: <1355331231.87661.461.camel@revolution.hippie.lan> Date: Wed, 12 Dec 2012 20:52:52 +0200 Message-ID: Subject: Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Kimmo Paasiala To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 18:52:54 -0000 On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore wrote: > On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote: >> Hello, >> >> My 9-STABLE buildworld broke in a very inexplicable way, I was >> getting an error on /usr/src/include/osreldate.h that I couldn't >> figure out until I started looking at the sys/conf/newvers.sh and what >> it does. It turned out that the thing that broke my buildworld was >> having .git directory at the root directory of the system because I >> recently started using GIT to track the configuration files. >> >> I added some debug echos to the newvers.sh and I found out it's >> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set >> the gitdir to /.git and that seems to break the logic in newvers.sh. >> >> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source >> tree (/usr/src/sys default)? >> >> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in >> newvers.sh: >> >> SYSDIR=$(dirname $0)/.. >> >> $0 is actually /bin/sh and not the path to newver.sh because the >> newvers.sh is sourced by the Makefile in /usr/src/include instead of >> executing it: >> >> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \ >> ${.CURDIR}/Makefile >> @${ECHO} creating osreldate.h from newvers.sh >> @MAKE=${MAKE}; \ >> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ >> . ${.CURDIR}/../sys/conf/newvers.sh; \ >> >> Now the question is how to fix this? >> >> -Kimmo > > Perhaps it could be handled similar to PARAMFILE, something like this in > the makefile: > > PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ > SYSDIR=${.CURDIR}/../sys; \ > . ${.CURDIR}/../sys/conf/newvers.sh; \ > > I'm not sure if newvers.sh needs to work in ways that don't involve > being invoked from that makefile rule, so to be safe it could have > default handling, something like: > > : ${SYSDIR:=$(dirname $0)/..} > > -- Ian > > Thanks, that works. Should I file a PR about this? -Kimmo From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 19:15:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A15C1CE; Wed, 12 Dec 2012 19:15:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 069838FC14; Wed, 12 Dec 2012 19:15:24 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1006982lah.13 for ; Wed, 12 Dec 2012 11:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=98u0P/ZMBVi18UWyNqNqsqRc1tcXHakW1CvAmVCtVeM=; b=u/FXRjLgT021qElVRnM8FdiMysHVY70w6aqMdZV3sf6IV1TxoYNC2UzUEzd5BobIGI YsJzppbYakzuHFMKRfshg30VSV2GbEdfedsTHKWtf/pbrlmVMZgcNWUPZ/S9hJcXNGhX c67TmQofOm3DPlX2Tm+Anm4a79hCTuZB7TKqqU/k0SlK9+42jO6HU8YcmX8Vt7zhaXde trMCKr79CQWLqmoXWo+G3n99fxRybaLjC6XQGQOUfShlkEnb9pBDTMjoINhb+KM3mHuB rzK/Lle7sMm3wdXeOLluci6LKdCrLxqZCeuHKujIbCzDvkBk/+Gyjq03HBgFOhPFmM0h 9+6Q== MIME-Version: 1.0 Received: by 10.112.88.7 with SMTP id bc7mr925250lbb.108.1355339723725; Wed, 12 Dec 2012 11:15:23 -0800 (PST) Received: by 10.112.99.70 with HTTP; Wed, 12 Dec 2012 11:15:23 -0800 (PST) In-Reply-To: References: <1355331231.87661.461.camel@revolution.hippie.lan> Date: Wed, 12 Dec 2012 11:15:23 -0800 Message-ID: Subject: Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Garrett Cooper To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , freebsd-stable@freebsd.org, Alfred Perlstein , freebsd-current@freebsd.org, Josh Paetzel , Xin LI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 19:15:26 -0000 On Wed, Dec 12, 2012 at 10:52 AM, Kimmo Paasiala wrote: ... > Thanks, that works. Should I file a PR about this? There are other issues with this that should be resolved (in particular, modifying include/Makefile that FreeNAS has been packing around for a year or so now). Filed a PR here a year ago, but no one has committed it yet even though it should be trivial enough to review and commit: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/160646 . Alfred/Josh/Xin: could you please commit this change first? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 19:35:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68E9DD4C for ; Wed, 12 Dec 2012 19:35:31 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 440B18FC12 for ; Wed, 12 Dec 2012 19:35:31 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Tis5a-0004d8-RA for freebsd-current@freebsd.org; Wed, 12 Dec 2012 11:35:30 -0800 Date: Wed, 12 Dec 2012 11:35:30 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1355340930835-5768897.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Request for merge into 9.x MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 19:35:31 -0000 Have you tested 9-STABLE? I see there some 2860 bits- http://svnweb.freebsd.org/base/stable/9/sys/dev/ral/ There are some updates in head, they should go to -STABLE after a usual while (TM). FYI, current wifi development and discussion takes place in freebsd-wireless too. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Request-for-merge-into-9-x-tp5768802p5768897.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 19:35:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47038E52; Wed, 12 Dec 2012 19:35:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id F17A48FC1B; Wed, 12 Dec 2012 19:35:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5821:52ef:5e7d:addd] (unknown [IPv6:2001:7b8:3a7:0:5821:52ef:5e7d:addd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6DBF45C37; Wed, 12 Dec 2012 20:35:42 +0100 (CET) Message-ID: <50C8DC8E.1080204@FreeBSD.org> Date: Wed, 12 Dec 2012 20:35:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> In-Reply-To: <50C880D7.1040907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 19:35:44 -0000 On 2012-12-12 14:04, Volodymyr Kostyrko wrote: > 04.12.2012 00:41, Konstantin Belousov: >> Please try the patch below. It might give an immediate relief, but still >> there are many offenders in the backtrace. > > I'm having almost the same issue and the patch doesn't work for me. ... Looking at the stack frame addresses, it seems some of them are mangled. Did you type this by hand? The differences between subsequent frames are a bit strange because of it (and because of awk's integer processing): _mtx_lock_flags 40 uma_zalloc_arg 80 malloc 48 zfs_kmem_alloc 20 vdev_mirror_io_start 100 zio_vdev_io_start -2270966072 zio_execute 2270966192 spa_load_verify_cb 64 traverse_visitbp 304 traverse_dnode -2129031145 traverse_visitbp 2129031529 traverse_visitbp 805306672 traverse_visitbp -805306064 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_dnode 80 traverse_visitbp 304 traverse_impl 176 traverse_pool 160 spa_load 280 spa_load 280 spa_load_best -560 spa_open_common 740 spa_open 20 dsl_dir_open_spa 360 dsl_dataset_hold 124 dsl_dataset_own 28 dmu_objset_own 40 zfsvfs_create 80 zfs_mount 560 vfs_donmount 624 kernel_mount 64 parse_mount 280 vfs_mountroot 616 start_init 108 fork_exit 40 fork_trampoline 0 The kernel stack is just 8,192 bytes; since you can see these routines are all consuming massive amounts of stack, and the calls are very deeply nested, it is almost inevitable that it would crash. Especially the recursive spa_load and traverse_visitbp calls are scary, because that can grow out of hand very quickly. It is probably tricky to remove the recursion... From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 21:26:26 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90DD52EF; Wed, 12 Dec 2012 21:26:26 +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 26A2D8FC0A; Wed, 12 Dec 2012 21:26:26 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 84680358C2A; Wed, 12 Dec 2012 22:26:25 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 6E6DB2848C; Wed, 12 Dec 2012 22:26:25 +0100 (CET) Date: Wed, 12 Dec 2012 22:26:25 +0100 From: Jilles Tjoelker To: Gleb Smirnoff Subject: Re: rev 244030 route command is not working Message-ID: <20121212212625.GA48633@stack.nl> References: <2452291.zQQ4fSp1fM@home.alkar.net> <20121211071334.GS48639@glebius.int.ru> <1740464.YojJrNfMlV@notebook.alkar.net> <13928549.1YcT8qshV5@notebook.alkar.net> <20121211120703.GI48639@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121211120703.GI48639@glebius.int.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Artyom Mirgorodskiy , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 21:26:26 -0000 On Tue, Dec 11, 2012 at 04:07:03PM +0400, Gleb Smirnoff wrote: > On Tue, Dec 11, 2012 at 12:21:20PM +0200, Artyom Mirgorodskiy wrote: > A> Gleb, when I reset errno at the begin of fiboptlist_csv() > A> everything work as expected. > Artyom, > can you please test attached patch? > Index: route.c > =================================================================== > --- route.c (revision 244082) > +++ route.c (working copy) > @@ -271,8 +271,7 @@ > case 0: > case 1: > fib[i] = strtol(token, &endptr, 0); > - if (*endptr != '\0' || (fib[i] == 0 && > - (errno == EINVAL || errno == ERANGE))) > + if (*endptr != '\0') > error = 1; > break; > default: > @@ -336,8 +335,7 @@ > goto fiboptlist_csv_ret; > } else { > fib = strtol(token, &endptr, 0); > - if (*endptr != '\0' || (fib == 0 && > - (errno == EINVAL || errno == ERANGE))) { > + if (*endptr != '\0') { > error = 1; > goto fiboptlist_csv_ret; > } This patch will avoid erroneously failing but will let through certain invalid strings. The empty string will silently be treated as 0 and values outside the range [LONG_MIN, LONG_MAX] will be clamped silently (the latter was already broken in most cases because [ERANGE] happens only with a return value of LONG_MIN or LONG_MAX). Other invalid strings that were and are let through (with unexpected results) are ones containing a number that fits in a long but not in an int. To fix the range detection, errno should be set to 0 before the call and checked afterwards; in a library function (this is an application), errno should be saved and restored around that to avoid setting errno to 0 as a side effect of the function. The empty string needs a specific check. I don't insist on this being fixed but it shows that strtol() is too hard to use correctly. The non-standard strtonum() looks easier but has other problems (such as returning an English string in an API that should be language-neutral). -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 21:31:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF864615 for ; Wed, 12 Dec 2012 21:31:40 +0000 (UTC) (envelope-from bschmidt@freebsd.org) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 613458FC0A for ; Wed, 12 Dec 2012 21:31:40 +0000 (UTC) Received: from amy.lab.techwires.net (dslb-088-067-193-184.pools.arcor-ip.net [88.67.193.184]) by mx.techwires.net (Postfix) with ESMTPSA id A59132BBA25; Wed, 12 Dec 2012 22:31:31 +0100 (CET) From: Bernhard Schmidt To: Paul Webster Subject: Re: Request for merge into 9.x Date: Wed, 12 Dec 2012 22:32:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201212122232.13305.bschmidt@freebsd.org> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 21:31:41 -0000 On Wednesday 12 December 2012 14:29:13 Paul Webster wrote: > Hello I was recently reading about your work on the Ralink 2860, I run > an EEEPC 1000 at the moment and have always wanted to run freebsd on > it; however due to the wireless not being supported and a hatred for > hanging usb dongles handing everywhere; I had to run linux. > > I am no driver developer, but I would love to give your driver a trial > run on 9.1-RELEASE or -STABLE if easier, I am quite sure once everyone > with an eeepc realizes we finally have a working wifi card; they will > be most impressed :) > > as an aside, if you could leave me some simplish instructions on howto > actually generate the kernel module in 9.0/9.1 -RELEASE I would > happily report how well it works Which card do you have exactly (pciconf -lv)? Everything if done to ral(4) is in stable/9 and 9.1-release. So, if the card is affected by any of the changes it should be supported in 9.1-release. If not, it might just be a missing PCI ID. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 23:51:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63B5CA93; Wed, 12 Dec 2012 23:51:24 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12DE58FC15; Wed, 12 Dec 2012 23:51:23 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1401028obc.13 for ; Wed, 12 Dec 2012 15:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CBRVRLLgvUZOjEjDgpyO+TGyigAqy54d2HXjeHa2Kfo=; b=PwaPi5PPVZUzJp0Ovm22x+eW3aCVU7YoN2Jn8hzz7K6GwW7qDAZ+dhz7H7qsiYa3sJ PJrLQnqHfMPzDzobgug+ixBNOYJZAkfeb1maYYUXtEuhDOBcmihLsfP45sQlGm0lg/f7 jxwz3fFEBYZAwte0wO5M4yCsn2JUg26GYP8xiPH+ixjYUG+gT9sq0r9zsGZPicysf53z QZNGiF/J7PgaxTgwG+IVMtesXyilMZAduneJbG3AWzhIL2sWzC66ZFuntswx3uaqgmQ8 K1DGb8QfBX9M3tOLJUDzI0Kkj/U1mTwEEqEfbUXEWNiM9NnHLhLaqJol0/JMR5mWAgHN LvQw== MIME-Version: 1.0 Received: by 10.60.171.133 with SMTP id au5mr1550324oec.90.1355356283464; Wed, 12 Dec 2012 15:51:23 -0800 (PST) Received: by 10.60.76.200 with HTTP; Wed, 12 Dec 2012 15:51:23 -0800 (PST) Date: Thu, 13 Dec 2012 03:51:23 +0400 Message-ID: Subject: AR9285 not see n-channels From: Andrey Fesenko To: freebsd-wireless@freebsd.org, freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 12 Dec 2012 23:51:24 -0000 I have # uname -a FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r243259: Mon Nov 19 09:28:08 MSK 2012 root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 # grep ATH /usr/src/sys/amd64/conf/W_BOOK options ATH_ENABLE_11N options ATH_DEBUG options ATH_DIAGAPI pciconf ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network # ifconfig -v wlan0 list channel Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b .... wi-fi router have and enable n-mode (linksys e4200) How to turn on or activate n-mode? From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:07:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0621CFC4; Thu, 13 Dec 2012 00:07:06 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 82DB88FC18; Thu, 13 Dec 2012 00:07:05 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TiwKD-0008y7-8Y; Wed, 12 Dec 2012 16:06:56 -0800 Message-ID: <50C91C1B.4070301@bluezbox.com> Date: Wed, 12 Dec 2012 16:06:51 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Daisuke Aoyama Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/12/2012 9:08 AM, Daisuke Aoyama wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. > > The first version is released at my Japanese blog: > http://shell.peach.ne.jp/aoyama/archives/2357 > > Thank you for many comments to previous versions. > Thank you for adding RPI support to FreeBSD. > Thank you for porting latest clang to head! > It's very useful for RPI developing now. > > You can get the pre-build image from my archives: > > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) > > Download and decompress it, then write it to SD. This image requires > SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing > the boot log. > If you need to change the value on it, please mount the second > partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set > console=comconsole" in /boot/loader.rc. > > Note: first time, it takes about 2 minutes for generating the SSH keys. > This version includes axe(ASIX AX88x7x/760) driver because smsc is not > stable. > Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify > or edit /etc/make.conf. > The initial setup code is taken from NetBSD. > > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 > > Source and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ > > > Pre-configured for: > > MEM 496MB/GPU 16MB/SWAP 512MB > I/O: multi-console (primary serial) > IP address: 192.168.1.240 > Default router: 192.168.1.1 > DNS: 192.168.1.1 > sshd: enabled > > User: pi > Password: raspberry > Password(root): raspberry > > kernel section limit: > TS=256MB, DS=1024MB, SS=256MB > > example of /etc/make.conf: > > WITHOUT_X11=yes > > WITH_CLANG=yes > WITH_CLANG_IS_CC=yes > > # Now cc = clang is default > #CC=clang > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 00:07:06 -0000 On 12/12/2012 9:08 AM, Daisuke Aoyama wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. > > The first version is released at my Japanese blog: > http://shell.peach.ne.jp/aoyama/archives/2357 > > Thank you for many comments to previous versions. > Thank you for adding RPI support to FreeBSD. > Thank you for porting latest clang to head! > It's very useful for RPI developing now. > > You can get the pre-build image from my archives: > > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) > > Download and decompress it, then write it to SD. This image requires > SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing > the boot log. > If you need to change the value on it, please mount the second > partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set > console=comconsole" in /boot/loader.rc. > > Note: first time, it takes about 2 minutes for generating the SSH keys. > This version includes axe(ASIX AX88x7x/760) driver because smsc is not > stable. > Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify > or edit /etc/make.conf. > The initial setup code is taken from NetBSD. > > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 > > Source and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ > > > Pre-configured for: > > MEM 496MB/GPU 16MB/SWAP 512MB > I/O: multi-console (primary serial) > IP address: 192.168.1.240 > Default router: 192.168.1.1 > DNS: 192.168.1.1 > sshd: enabled > > User: pi > Password: raspberry > Password(root): raspberry > > kernel section limit: > TS=256MB, DS=1024MB, SS=256MB > > example of /etc/make.conf: > ---------------------------------------------------------------------- > WITHOUT_X11=yes > > WITH_CLANG=yes > WITH_CLANG_IS_CC=yes > > # Now cc = clang is default > #CC=clang > #CXX=clang++ > #CPP=clang-cpp > > # For clang > NO_WERROR= > WERROR= > > CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > > # For gcc > #CC=gcc > #CXX=g++ > #CPP=cpp > ---------------------------------------------------------------------- > How to use GPT USB stick in RPI: > > (if you use something, delete/destory it before doing) > # gpart delete -i NN da0 > # gpart destroy -F da0 > > (create new partition and format) > # gpart create -s gpt da0 > # gpart add -t freebsd-ufs da0 > # gpart show > # newfs -U -j /dev/da0p1 > > (mount it) > # mount /dev/da0p1 /mnt > ---------------------------------------------------------------------- > Known problems: > o SD card is not configured correctly. (power on/off need if it's failed) > o hang the system. (unknown reason) > o smsc is not stable. > o alignment/padding is not same as gcc. (temporary avoid strict > alignment now) > o call both IDCACHE_WBINV_ALL and DCACHE_WB_RANGE at switch. (can't > work without both) > o still depend on GNU as (gas syntax). > > TODO: > o modify/replace bcm2835 drivers. > o using "clang -integrated-as". > o fix alignment with clang. > o self build. > o use EABI if possible. > o create build script :-) > > Enjoy clang world in Raspberry Pi! Amazing! Thank you for working on it From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:32:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03314768; Thu, 13 Dec 2012 00:32:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 56ABB8FC12; Thu, 13 Dec 2012 00:32:50 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so2209899wgb.1 for ; Wed, 12 Dec 2012 16:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FEeg6nFCNgYWmAdnsEhpAMfP5RoqeHb9qAeedBhEaAE=; b=QDrQaaIC3vKlhhRE9Zj2cucZIe3XGmkbg6C4ZitToejgWHwSjSISnDubVD9S/NaaRR lIKoVoYlWyZZXtWOCciAJ+qQNKpr7vQ/CikK7idfyjI57fLeT5ZfyHV2x3PbY1HiJVqf 3Ml0cwTx8+pJu0CafYknElGqWCVFRjybimxT77RjTC9GFlKH/JOU8UtJjyt7SCPFFdVw Icj3RDlw6cGs3hhPNaVdrgMUdrq+rIB5DdcVdJsAwZWwz0zaGzEozymngGHxdi/Tk0EA BWYSiCfRxp+uefMrA+UjJWXU/xQnVIgJTCqy9P21j8RCaxDflO1P+qSWpXF2fIdZ0Y/o /JlA== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr4895620wjc.1.1355358769110; Wed, 12 Dec 2012 16:32:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 12 Dec 2012 16:32:48 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 16:32:48 -0800 X-Google-Sender-Auth: K5vYe_EuuwbonrMYpY0fJUMRi-U Message-ID: Subject: Re: AR9285 not see n-channels From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 00:32:51 -0000 What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? adrian On 12 December 2012 15:51, Andrey Fesenko wrote: > I have > # uname -a > FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 > r243259: Mon Nov 19 09:28:08 MSK 2012 > root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 > # grep ATH /usr/src/sys/amd64/conf/W_BOOK > options ATH_ENABLE_11N > options ATH_DEBUG > options ATH_DIAGAPI > > pciconf > ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR9285 Wireless Network Adapter (PCI-Express)' > class = network > > > # ifconfig -v wlan0 list channel > Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 > Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b > Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g > Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 > Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b > .... > > wi-fi router have and enable n-mode (linksys e4200) > How to turn on or activate n-mode? > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:39:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D6B79F3; Thu, 13 Dec 2012 00:39:09 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id A165B8FC08; Thu, 13 Dec 2012 00:39:08 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1558601oag.13 for ; Wed, 12 Dec 2012 16:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b/iJSJTFPeFNeeWIbTkkDtf0BIaDD975TBChl9BvH7k=; b=EW41T4N3b4jk+YyIhuHTxKWE/2yzJz47TXUZdFv0dtoYvJpsbeGD9LPctPp9jkBZhq W0lzFPVnBiLdpbDImxWbT4x5YSenAFLMSdid5MnOR/+/JjPP0bSras/K8TzKeZtDiGEP OYTVLA+synXy1ADlMFFLHq2hX/yYJLwpWJMfNxXSczruOLVxYqLdZyEB49evWyLq+qjo 7adPpJvziLKZuv0gltgNblK9S6cP6fEZKnehV5GcjNbzw+TbbWGdTYWTTKRK9s7IqUq6 56ar7BIFx0/qO+0lo4Ata1mF/XKhnrE2c3q2VGbSb8x67aDGNk0ZkGl2k8e73GN8lncw nSRg== MIME-Version: 1.0 Received: by 10.182.240.45 with SMTP id vx13mr30340obc.21.1355359147388; Wed, 12 Dec 2012 16:39:07 -0800 (PST) Received: by 10.60.76.200 with HTTP; Wed, 12 Dec 2012 16:39:07 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 04:39:07 +0400 Message-ID: Subject: Re: AR9285 not see n-channels From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-wireless@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 00:39:09 -0000 On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: > What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? > > > > adrian > > > On 12 December 2012 15:51, Andrey Fesenko wrote: >> I have >> # uname -a >> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >> r243259: Mon Nov 19 09:28:08 MSK 2012 >> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >> options ATH_ENABLE_11N >> options ATH_DEBUG >> options ATH_DIAGAPI >> >> pciconf >> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >> rev=0x01 hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >> class = network >> >> >> # ifconfig -v wlan0 list channel >> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >> .... >> >> wi-fi router have and enable n-mode (linksys e4200) >> How to turn on or activate n-mode? # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS RSN HTCAP WME WPS # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 4c:0f:6e:4b:4e:f5 inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme burst roaming MANUAL From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:44:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D6C2E50; Thu, 13 Dec 2012 00:44:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9348FC16; Thu, 13 Dec 2012 00:44:57 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so1009871pad.13 for ; Wed, 12 Dec 2012 16:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:reply-to:subject:in-reply-to:x-mailer :mime-version:content-type; bh=d2iLroS7Dr5aan6HBBul/TQWqUI61kOBuyT5kSrGhqY=; b=vPqYWTkrZ6ZPbstcgVsQUgP8/cDxrhS9LXC/0tAiiZc5ExoR3UR6yBCR+oeWFpf0qV DIFZFFoDQwTZW5VqWGyRbyc4mzn3GMnLZ4OyYH5jTyKOOlOI/Ybdux91e8STQmCubIgT ywJFeQxkkgwAN6aQ1n8yMD2QKOt4Y2QZM/etNxeCMbRcIAMEIg7FIYK8PvQMRgmoRe1E 0LE9G5g5rt9ATBqXN6XESJlz6RFJa7xP2ybj9eLTDbJqfOMk+Q0Raw3DVBLZL18oxkbC T/LrnG2tIN+wW4YuLq2yy1mXpJGp/zQ2+RGs7fFxMmWx/LyqYPmnoz6Ri1VJn0NKX1fz n7hg== Received: by 10.68.134.232 with SMTP id pn8mr109532pbb.47.1355359497458; Wed, 12 Dec 2012 16:44:57 -0800 (PST) Received: from www.palm.com (i-global235-qca.qualcomm.com. [199.106.103.235]) by mx.google.com with ESMTPS id ot3sm16493174pbb.38.2012.12.12.16.44.52 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 16:44:56 -0800 (PST) Message-ID: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Wed, 12 Dec 2012 16:44:44 -0800 From: "Adrian Chadd" To: "Andrey Fesenko" , "Adrian Chadd" Subject: Re: AR9285 not see n-channels In-Reply-To: X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:44:58 -0000 Yup. It's doing 11n rates. Compile and run athstats, it'll tell you how many aggregate frames are bein= g sent and received. Adrian Sent from my Palm Pre on AT&T On Dec 12, 2012 4:39 PM, Andrey Fesenko <f0andrey@gmail.com> wrote:=20 On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd <adrian@freebsd.org> wr= ote: > What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? > > > > adrian > > > On 12 December 2012 15:51, Andrey Fesenko <f0andrey@gmail.com>= wrote: >> I have >> # uname -a >> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT= #1 >> r243259: Mon Nov 19 09:28:08 MSK 2012 >> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >> options ATH_ENABLE_11N >> options ATH_DEBUG >> options ATH_DIAGAPI >> >> pciconf >> ath0@pci0:5:0:0: class=3D0x028000 card=3D0xe016105b chip=3D= 0x002b168c >> rev=3D0x01 hdr=3D0x00 >> vendor =3D 'Atheros Communications Inc.' >> device =3D 'AR9285 Wireless Network Adapter (PCI-Express)' >> class =3D network >> >> >> # ifconfig -v wlan0 list channel >> Channel 1 : 2412 MHz 11b Channel 7 : 2442 = MHz 11g ht/20 >> Channel 1 : 2412 MHz 11g Channel 8 : 2447 = MHz 11b >> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 = MHz 11g >> Channel 2 : 2417 MHz 11b Channel 8 : 2447 = MHz 11g ht/20 >> Channel 2 : 2417 MHz 11g Channel 9 : 2452 = MHz 11b >> .... >> >> wi-fi router have and enable n-mode (linksys e4200) >> How to turn on or activate n-mode? # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS RSN HTCAP WME WPS # ifconfig wlan0 wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0= mtu 1500 ether 4c:0f:6e:4b:4e:f5 inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:= 50 regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss= 7 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme burst roaming MANUAL From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:54:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8CA229E; Thu, 13 Dec 2012 00:54:29 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 468388FC13; Thu, 13 Dec 2012 00:54:29 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1447747obc.13 for ; Wed, 12 Dec 2012 16:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ljzIMXAb8wgXi6QKKmXp9TYO5T8/JjciQlMmuI5jsJs=; b=EfpG/xNVEZd1FovZkZ1ruQVm9IVxV3vYQXiJcYJvrZeQD4h/11ev5aQn+TypJ6J+Uz 8qKhRrd60uxu/FUQmrKAfDfLVMfqVSbnPohro0sYoI+UiDA63nXiZ1crO2O6caHA+lm7 jFMochcGjWGpZe/C6b5UsWMR0GXAyxyXqXYp2pJfUnhmidynwqsdIrGi5vnl+Ag/zXKI kfAyZt53YRjiMVZVuESTw1e5oP/w6BiJOGRlUEMX9EF80900+mjNZYma0DCBD8NeeAsr BPeRAVucQsxTzTTQJ0qiv6xQpJ3hRFoVCGK7gpJsOU+ENnBnfcI0N0A09rttwkz9f5wh rv+A== MIME-Version: 1.0 Received: by 10.182.185.12 with SMTP id ey12mr73834obc.7.1355360068405; Wed, 12 Dec 2012 16:54:28 -0800 (PST) Received: by 10.60.76.200 with HTTP; Wed, 12 Dec 2012 16:54:28 -0800 (PST) In-Reply-To: <50c92508.6384440a.1379.3a4a@mx.google.com> References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Thu, 13 Dec 2012 04:54:28 +0400 Message-ID: Subject: Re: AR9285 not see n-channels From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 00:54:29 -0000 On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: > Yup. It's doing 11n rates. > > Compile and run athstats, it'll tell you how many aggregate frames are being > sent and received. > > > > Adrian > > Sent from my Palm Pre on AT&T > > ________________________________ > On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: > > On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >> >> >> >> adrian >> >> >> On 12 December 2012 15:51, Andrey Fesenko wrote: >>> I have >>> # uname -a >>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>> options ATH_ENABLE_11N >>> options ATH_DEBUG >>> options ATH_DIAGAPI >>> >>> pciconf >>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>> rev=0x01 hdr=0x00 >>> vendor = 'Atheros Communications Inc.' >>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>> class = network >>> >>> >>> # ifconfig -v wlan0 list channel >>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>> .... >>> >>> wi-fi router have and enable n-mode (linksys e4200) >>> How to turn on or activate n-mode? > > # ifconfig wlan0 list sta > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS > RSN HTCAP WME WPS > # ifconfig wlan0 > wlan0: flags=8843 metric 0 mtu 1500 > ether 4c:0f:6e:4b:4e:f5 > inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > status: associated > ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 > regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON > deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 > scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme > burst roaming MANUAL # ./athstats 526213 data frames received 10205 data frames transmit 79 short on-chip tx retries 103 long on-chip tx retries 16 tx failed 'cuz too many retries 220 mib overflow interrupts MCS7 current transmit rate 1 watchdog timeouts 42 beacon miss interrupts 23154 rx failed 'cuz of bad CRC 56 rx failed 'cuz of PHY err 56 illegal service 1638 periodic calibrations -0/+0 TDMA slot adjust (usecs, smoothed) 56 rssi of last ack 50 avg recv rssi -96 rx noise floor 13 phantom beacon misses 6569 tx frames through raw api 1460 A-MPDU sub-frames received 183 Half-GI frames received 183 40MHz frames received 2397 CRC errors for non-last A-MPDU subframes 3151 Frames transmitted with HT Protection 25 A-MPDU sub-frame TX attempt success 2 first step level 1 OFDM weak signal detect 268 listen time 190 ANI increased spur immunity 174 ANI decrease spur immunity 2 ANI enabled OFDM weak signal detect 3517 ANI disabled OFDM weak signal detect 3515 ANI disabled CCK weak signal threshold 4 ANI increased first step level 2 ANI decreased first step level 154772 cumulative OFDM phy error count 528256 cumulative CCK phy error count 851 ANI forced listen time to zero 26 missing ACK's 78 RTS without CTS 3135 successful RTS 65747 bad FCS 473007 beacons received 53 average rssi (beacons only) 35 average rssi (all rx'd frames) 48 average rssi (ACKs only) Antenna profile: [0] tx 10173 rx 4 [1] tx 0 rx 526209 # ./athaggrstats 17 single frames scheduled 9 aggregate frames scheduled 1217 single frames scheduled due to low HWQ depth Aggregate size profile: 0: 0 1: 0 2: 6 3: 2 4: 0 5: 0 6: 0 7: 1 8: 0 9: 0 10: 0 11: 0 From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:56:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 986325E2; Thu, 13 Dec 2012 00:56:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 003CA8FC18; Thu, 13 Dec 2012 00:56:00 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1121957wib.13 for ; Wed, 12 Dec 2012 16:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JHAHyfHmY5uzswoEFSm0JoyWNBP1j30wQ0R70cvdJjs=; b=SrCm+6gXS98JQIaqHYpVjDJEwJfnIkMwTOvrq8XbaWtc0jmfs5RLFRlZTa+fukDSJi BWS6BoaUQS0EtI8RYSs/Tb3MMsbBbq1xo1CdwU6JswIPnuJvhbESNb2UXLW9+a4p2KlD CqpdSQtBgQ+r3F4UcTPz2AMPWoQmttAK2CBt204u9GcecvMwOCsmxhgRpeYeAjrLVxAZ nJ8d/W4Z/6r6sOPzicB7nGzsvFl8yCZ7VK3N8HDRpatBtBs5rHrzLgAk8tLn0jwG+A3A 2BsBIPbR7GztECrDdiQjW0tAsmK42hGklJW4BeLVppg+7eoqDOWY3HA/BW7NlU50rPKR f9nw== MIME-Version: 1.0 Received: by 10.194.120.132 with SMTP id lc4mr4946169wjb.59.1355360159052; Wed, 12 Dec 2012 16:55:59 -0800 (PST) Received: by 10.217.57.9 with HTTP; Wed, 12 Dec 2012 16:55:58 -0800 (PST) In-Reply-To: References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Wed, 12 Dec 2012 16:55:58 -0800 Message-ID: Subject: Re: AR9285 not see n-channels From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 00:56:01 -0000 .. yup, you're doing 11n! Welcome! Adrian On 12 December 2012 16:54, Andrey Fesenko wrote: > On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >> Yup. It's doing 11n rates. >> >> Compile and run athstats, it'll tell you how many aggregate frames are being >> sent and received. >> >> >> >> Adrian >> >> Sent from my Palm Pre on AT&T >> >> ________________________________ >> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >> >> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>> >>> >>> >>> adrian >>> >>> >>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>> I have >>>> # uname -a >>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>> options ATH_ENABLE_11N >>>> options ATH_DEBUG >>>> options ATH_DIAGAPI >>>> >>>> pciconf >>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>> rev=0x01 hdr=0x00 >>>> vendor = 'Atheros Communications Inc.' >>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>> class = network >>>> >>>> >>>> # ifconfig -v wlan0 list channel >>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>> .... >>>> >>>> wi-fi router have and enable n-mode (linksys e4200) >>>> How to turn on or activate n-mode? >> >> # ifconfig wlan0 list sta >> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >> RSN HTCAP WME WPS >> # ifconfig wlan0 >> wlan0: flags=8843 metric 0 mtu 1500 >> ether 4c:0f:6e:4b:4e:f5 >> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >> nd6 options=29 >> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >> status: associated >> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >> burst roaming MANUAL > > # ./athstats > 526213 data frames received > 10205 data frames transmit > 79 short on-chip tx retries > 103 long on-chip tx retries > 16 tx failed 'cuz too many retries > 220 mib overflow interrupts > MCS7 current transmit rate > 1 watchdog timeouts > 42 beacon miss interrupts > 23154 rx failed 'cuz of bad CRC > 56 rx failed 'cuz of PHY err > 56 illegal service > 1638 periodic calibrations > -0/+0 TDMA slot adjust (usecs, smoothed) > 56 rssi of last ack > 50 avg recv rssi > -96 rx noise floor > 13 phantom beacon misses > 6569 tx frames through raw api > 1460 A-MPDU sub-frames received > 183 Half-GI frames received > 183 40MHz frames received > 2397 CRC errors for non-last A-MPDU subframes > 3151 Frames transmitted with HT Protection > 25 A-MPDU sub-frame TX attempt success > 2 first step level > 1 OFDM weak signal detect > 268 listen time > 190 ANI increased spur immunity > 174 ANI decrease spur immunity > 2 ANI enabled OFDM weak signal detect > 3517 ANI disabled OFDM weak signal detect > 3515 ANI disabled CCK weak signal threshold > 4 ANI increased first step level > 2 ANI decreased first step level > 154772 cumulative OFDM phy error count > 528256 cumulative CCK phy error count > 851 ANI forced listen time to zero > 26 missing ACK's > 78 RTS without CTS > 3135 successful RTS > 65747 bad FCS > 473007 beacons received > 53 average rssi (beacons only) > 35 average rssi (all rx'd frames) > 48 average rssi (ACKs only) > Antenna profile: > [0] tx 10173 rx 4 > [1] tx 0 rx 526209 > > > # ./athaggrstats > 17 single frames scheduled > 9 aggregate frames scheduled > 1217 single frames scheduled due to low HWQ depth > > Aggregate size profile: > > 0: 0 1: 0 2: 6 3: 2 > 4: 0 5: 0 6: 0 7: 1 > 8: 0 9: 0 10: 0 11: 0 From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:32:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C17BFDB; Thu, 13 Dec 2012 01:32:19 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACDB58FC0A; Thu, 13 Dec 2012 01:32:18 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1473319obc.13 for ; Wed, 12 Dec 2012 17:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q0OR9mZlrkNcqGiudszxrf2b/fyfqdv+kXvBTuZk1hM=; b=RZbQaeJGYjI4VxDqyL5WYjkKL3o4LVrxDtiGoTQ9lr8BwsTx8jri8+q/NsLkfASd+Q 30D3ONW/AUZHDBDNG7JyauR9zwxF5UwXKZQ18ruxMaugW9XN3MEuvwyWw7wZQY450nOc e+PsOFlmpBxKcS5C7+UsttnsQAQEGNR7fEfG7GUBzLz6pRXqwarwRsbZCG51FdnBKv1a 6w0pafsHLpnq+C62FjMApdj9F0PIG+c8y0wKONfxERrDnvif/F9NqVyLmO8Mi8jz1H7k snJFfj287Su1vhPtoGu5qGC6+OvN1Uyf0U5wxxaTamjElIKtR8hZcgDX5f3GNRgT/h4F aZ9w== MIME-Version: 1.0 Received: by 10.182.212.70 with SMTP id ni6mr102698obc.44.1355362337982; Wed, 12 Dec 2012 17:32:17 -0800 (PST) Received: by 10.60.76.200 with HTTP; Wed, 12 Dec 2012 17:32:17 -0800 (PST) In-Reply-To: References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Thu, 13 Dec 2012 05:32:17 +0400 Message-ID: Subject: Re: AR9285 not see n-channels From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 01:32:19 -0000 On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: > .. yup, you're doing 11n! Welcome! > > > > Adrian > > On 12 December 2012 16:54, Andrey Fesenko wrote: >> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >>> Yup. It's doing 11n rates. >>> >>> Compile and run athstats, it'll tell you how many aggregate frames are being >>> sent and received. >>> >>> >>> >>> Adrian >>> >>> Sent from my Palm Pre on AT&T >>> >>> ________________________________ >>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>> >>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>> >>>> >>>> >>>> adrian >>>> >>>> >>>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>>> I have >>>>> # uname -a >>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>> options ATH_ENABLE_11N >>>>> options ATH_DEBUG >>>>> options ATH_DIAGAPI >>>>> >>>>> pciconf >>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>> rev=0x01 hdr=0x00 >>>>> vendor = 'Atheros Communications Inc.' >>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>> class = network >>>>> >>>>> >>>>> # ifconfig -v wlan0 list channel >>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>> .... >>>>> >>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>> How to turn on or activate n-mode? >>> >>> # ifconfig wlan0 list sta >>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>> RSN HTCAP WME WPS >>> # ifconfig wlan0 >>> wlan0: flags=8843 metric 0 mtu 1500 >>> ether 4c:0f:6e:4b:4e:f5 >>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>> nd6 options=29 >>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>> status: associated >>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>> burst roaming MANUAL >> >> # ./athstats >> 526213 data frames received >> 10205 data frames transmit >> 79 short on-chip tx retries >> 103 long on-chip tx retries >> 16 tx failed 'cuz too many retries >> 220 mib overflow interrupts >> MCS7 current transmit rate >> 1 watchdog timeouts >> 42 beacon miss interrupts >> 23154 rx failed 'cuz of bad CRC >> 56 rx failed 'cuz of PHY err >> 56 illegal service >> 1638 periodic calibrations >> -0/+0 TDMA slot adjust (usecs, smoothed) >> 56 rssi of last ack >> 50 avg recv rssi >> -96 rx noise floor >> 13 phantom beacon misses >> 6569 tx frames through raw api >> 1460 A-MPDU sub-frames received >> 183 Half-GI frames received >> 183 40MHz frames received >> 2397 CRC errors for non-last A-MPDU subframes >> 3151 Frames transmitted with HT Protection >> 25 A-MPDU sub-frame TX attempt success >> 2 first step level >> 1 OFDM weak signal detect >> 268 listen time >> 190 ANI increased spur immunity >> 174 ANI decrease spur immunity >> 2 ANI enabled OFDM weak signal detect >> 3517 ANI disabled OFDM weak signal detect >> 3515 ANI disabled CCK weak signal threshold >> 4 ANI increased first step level >> 2 ANI decreased first step level >> 154772 cumulative OFDM phy error count >> 528256 cumulative CCK phy error count >> 851 ANI forced listen time to zero >> 26 missing ACK's >> 78 RTS without CTS >> 3135 successful RTS >> 65747 bad FCS >> 473007 beacons received >> 53 average rssi (beacons only) >> 35 average rssi (all rx'd frames) >> 48 average rssi (ACKs only) >> Antenna profile: >> [0] tx 10173 rx 4 >> [1] tx 0 rx 526209 >> >> >> # ./athaggrstats >> 17 single frames scheduled >> 9 aggregate frames scheduled >> 1217 single frames scheduled due to low HWQ depth >> >> Aggregate size profile: >> >> 0: 0 1: 0 2: 6 3: 2 >> 4: 0 5: 0 6: 0 7: 1 >> 8: 0 9: 0 10: 0 11: 0 why # ifconfig -v wlan0 list channel show only b and g channels? and only 13? or this restriction AR9285 though # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K ------------------------------------------------------------ Client connecting to 192.168.1.26, TCP port 5001 TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) ------------------------------------------------------------ [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:33:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C7F1180; Thu, 13 Dec 2012 01:33:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5428FC08; Thu, 13 Dec 2012 01:33:18 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1135089wib.13 for ; Wed, 12 Dec 2012 17:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6g4ptybI7VX8NmoGiv3qrCanxvtAj9H42wclSQVjT/s=; b=Fla5PNxM/2Ef8AVLp89aXE5gDSlwtR/lvihBQefIbMmKi1arfyVTK3JJ6K2cK0Scl2 TncwRYszBA9/8RyK/IdyDoT3IG0zG2JVbpbRjJPhRkvX577CGeRmfDG6uh6cgJLynL5p r+d/Ii0wx+jP0PPbm3clEddlgh1wjT5N5npRj2CiB0pzsU7ZAcbOgaVfeedq5qJqkfIH 4d3ozVphKQ1RlBw9PNnFVpPGcALrgynkzF/dmn/Qamw/KXYAS+UF3Ni/38NuMDRmGTbC z40QJQh9rzLiMWo9F+NKnACkKgkALcEYfKisKx1SIX/cqCBgo4cWfQmWkI55KdT3Ldtt TVzg== MIME-Version: 1.0 Received: by 10.194.120.132 with SMTP id lc4mr5055291wjb.59.1355362398101; Wed, 12 Dec 2012 17:33:18 -0800 (PST) Received: by 10.217.57.9 with HTTP; Wed, 12 Dec 2012 17:33:17 -0800 (PST) In-Reply-To: References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Wed, 12 Dec 2012 17:33:17 -0800 Message-ID: Subject: Re: AR9285 not see n-channels From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 01:33:20 -0000 Hi, The AR9285 is a 2GHz only NIC. The channel list shows 11b, 11bg, HT20 and HT40 channels. It all looks right, why don't you think it is? Adrian On 12 December 2012 17:32, Andrey Fesenko wrote: > On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: >> .. yup, you're doing 11n! Welcome! >> >> >> >> Adrian >> >> On 12 December 2012 16:54, Andrey Fesenko wrote: >>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >>>> Yup. It's doing 11n rates. >>>> >>>> Compile and run athstats, it'll tell you how many aggregate frames are being >>>> sent and received. >>>> >>>> >>>> >>>> Adrian >>>> >>>> Sent from my Palm Pre on AT&T >>>> >>>> ________________________________ >>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>>> >>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>>> >>>>> >>>>> >>>>> adrian >>>>> >>>>> >>>>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>>>> I have >>>>>> # uname -a >>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>>> options ATH_ENABLE_11N >>>>>> options ATH_DEBUG >>>>>> options ATH_DIAGAPI >>>>>> >>>>>> pciconf >>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>>> rev=0x01 hdr=0x00 >>>>>> vendor = 'Atheros Communications Inc.' >>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>>> class = network >>>>>> >>>>>> >>>>>> # ifconfig -v wlan0 list channel >>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>>> .... >>>>>> >>>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>>> How to turn on or activate n-mode? >>>> >>>> # ifconfig wlan0 list sta >>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>>> RSN HTCAP WME WPS >>>> # ifconfig wlan0 >>>> wlan0: flags=8843 metric 0 mtu 1500 >>>> ether 4c:0f:6e:4b:4e:f5 >>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>>> nd6 options=29 >>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>>> status: associated >>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>>> burst roaming MANUAL >>> >>> # ./athstats >>> 526213 data frames received >>> 10205 data frames transmit >>> 79 short on-chip tx retries >>> 103 long on-chip tx retries >>> 16 tx failed 'cuz too many retries >>> 220 mib overflow interrupts >>> MCS7 current transmit rate >>> 1 watchdog timeouts >>> 42 beacon miss interrupts >>> 23154 rx failed 'cuz of bad CRC >>> 56 rx failed 'cuz of PHY err >>> 56 illegal service >>> 1638 periodic calibrations >>> -0/+0 TDMA slot adjust (usecs, smoothed) >>> 56 rssi of last ack >>> 50 avg recv rssi >>> -96 rx noise floor >>> 13 phantom beacon misses >>> 6569 tx frames through raw api >>> 1460 A-MPDU sub-frames received >>> 183 Half-GI frames received >>> 183 40MHz frames received >>> 2397 CRC errors for non-last A-MPDU subframes >>> 3151 Frames transmitted with HT Protection >>> 25 A-MPDU sub-frame TX attempt success >>> 2 first step level >>> 1 OFDM weak signal detect >>> 268 listen time >>> 190 ANI increased spur immunity >>> 174 ANI decrease spur immunity >>> 2 ANI enabled OFDM weak signal detect >>> 3517 ANI disabled OFDM weak signal detect >>> 3515 ANI disabled CCK weak signal threshold >>> 4 ANI increased first step level >>> 2 ANI decreased first step level >>> 154772 cumulative OFDM phy error count >>> 528256 cumulative CCK phy error count >>> 851 ANI forced listen time to zero >>> 26 missing ACK's >>> 78 RTS without CTS >>> 3135 successful RTS >>> 65747 bad FCS >>> 473007 beacons received >>> 53 average rssi (beacons only) >>> 35 average rssi (all rx'd frames) >>> 48 average rssi (ACKs only) >>> Antenna profile: >>> [0] tx 10173 rx 4 >>> [1] tx 0 rx 526209 >>> >>> >>> # ./athaggrstats >>> 17 single frames scheduled >>> 9 aggregate frames scheduled >>> 1217 single frames scheduled due to low HWQ depth >>> >>> Aggregate size profile: >>> >>> 0: 0 1: 0 2: 6 3: 2 >>> 4: 0 5: 0 6: 0 7: 1 >>> 8: 0 9: 0 10: 0 11: 0 > > why # ifconfig -v wlan0 list channel > show only b and g channels? and only 13? or this restriction AR9285 > > though > # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K > ------------------------------------------------------------ > Client connecting to 192.168.1.26, TCP port 5001 > TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) > ------------------------------------------------------------ > [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:39:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ED1E37E; Thu, 13 Dec 2012 01:39:43 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 280748FC08; Thu, 13 Dec 2012 01:39:43 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1601075oag.13 for ; Wed, 12 Dec 2012 17:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ROTN67dODE4eJ22X5bcbc77p49TtQFJznykDWdFAkSI=; b=0yuQWDPkRIhIzWq2p6e8VJuIm39U0d8alWP2gwyuJvfNDsPysMbionWPlKobtEBGNn /9z10U2rgPr5lKfD7zlk7EltXy5Sp96GJ7dnN/gj2lEHKDPprO6aWDbp6nCseXYcwGct G7qwyxp4jy2wxuT4wY65s7z2ZdQk81A5d7+yWxJrCA6+C8KShgB4tcj4BXjKUhQgT/Zw KEm0RRuH02j3lGHfGdvVvqdNoNWIAA6ho39/UQ35IItwm4ipGs+bcQS146yg8jBifopt raqDGhqlJljGPO+HxOXsSMunuNVGsOiMh+4nhDWyAji65kFP0P28I0jPislJjL6rC4hc 9m1g== MIME-Version: 1.0 Received: by 10.60.20.101 with SMTP id m5mr82747oee.102.1355362782400; Wed, 12 Dec 2012 17:39:42 -0800 (PST) Received: by 10.60.76.200 with HTTP; Wed, 12 Dec 2012 17:39:42 -0800 (PST) In-Reply-To: References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Thu, 13 Dec 2012 05:39:42 +0400 Message-ID: Subject: Re: AR9285 not see n-channels From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 01:39:43 -0000 On Thu, Dec 13, 2012 at 5:33 AM, Adrian Chadd wrote: > Hi, > > The AR9285 is a 2GHz only NIC. > > The channel list shows 11b, 11bg, HT20 and HT40 channels. > > It all looks right, why don't you think it is? > > > Adrian > > > On 12 December 2012 17:32, Andrey Fesenko wrote: >> On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: >>> .. yup, you're doing 11n! Welcome! >>> >>> >>> >>> Adrian >>> >>> On 12 December 2012 16:54, Andrey Fesenko wrote: >>>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >>>>> Yup. It's doing 11n rates. >>>>> >>>>> Compile and run athstats, it'll tell you how many aggregate frames are being >>>>> sent and received. >>>>> >>>>> >>>>> >>>>> Adrian >>>>> >>>>> Sent from my Palm Pre on AT&T >>>>> >>>>> ________________________________ >>>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>>>> >>>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>>>> >>>>>> >>>>>> >>>>>> adrian >>>>>> >>>>>> >>>>>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>>>>> I have >>>>>>> # uname -a >>>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>>>> options ATH_ENABLE_11N >>>>>>> options ATH_DEBUG >>>>>>> options ATH_DIAGAPI >>>>>>> >>>>>>> pciconf >>>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>>>> rev=0x01 hdr=0x00 >>>>>>> vendor = 'Atheros Communications Inc.' >>>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>>>> class = network >>>>>>> >>>>>>> >>>>>>> # ifconfig -v wlan0 list channel >>>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>>>> .... >>>>>>> >>>>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>>>> How to turn on or activate n-mode? >>>>> >>>>> # ifconfig wlan0 list sta >>>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>>>> RSN HTCAP WME WPS >>>>> # ifconfig wlan0 >>>>> wlan0: flags=8843 metric 0 mtu 1500 >>>>> ether 4c:0f:6e:4b:4e:f5 >>>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>>>> nd6 options=29 >>>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>>>> status: associated >>>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >>>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >>>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>>>> burst roaming MANUAL >>>> >>>> # ./athstats >>>> 526213 data frames received >>>> 10205 data frames transmit >>>> 79 short on-chip tx retries >>>> 103 long on-chip tx retries >>>> 16 tx failed 'cuz too many retries >>>> 220 mib overflow interrupts >>>> MCS7 current transmit rate >>>> 1 watchdog timeouts >>>> 42 beacon miss interrupts >>>> 23154 rx failed 'cuz of bad CRC >>>> 56 rx failed 'cuz of PHY err >>>> 56 illegal service >>>> 1638 periodic calibrations >>>> -0/+0 TDMA slot adjust (usecs, smoothed) >>>> 56 rssi of last ack >>>> 50 avg recv rssi >>>> -96 rx noise floor >>>> 13 phantom beacon misses >>>> 6569 tx frames through raw api >>>> 1460 A-MPDU sub-frames received >>>> 183 Half-GI frames received >>>> 183 40MHz frames received >>>> 2397 CRC errors for non-last A-MPDU subframes >>>> 3151 Frames transmitted with HT Protection >>>> 25 A-MPDU sub-frame TX attempt success >>>> 2 first step level >>>> 1 OFDM weak signal detect >>>> 268 listen time >>>> 190 ANI increased spur immunity >>>> 174 ANI decrease spur immunity >>>> 2 ANI enabled OFDM weak signal detect >>>> 3517 ANI disabled OFDM weak signal detect >>>> 3515 ANI disabled CCK weak signal threshold >>>> 4 ANI increased first step level >>>> 2 ANI decreased first step level >>>> 154772 cumulative OFDM phy error count >>>> 528256 cumulative CCK phy error count >>>> 851 ANI forced listen time to zero >>>> 26 missing ACK's >>>> 78 RTS without CTS >>>> 3135 successful RTS >>>> 65747 bad FCS >>>> 473007 beacons received >>>> 53 average rssi (beacons only) >>>> 35 average rssi (all rx'd frames) >>>> 48 average rssi (ACKs only) >>>> Antenna profile: >>>> [0] tx 10173 rx 4 >>>> [1] tx 0 rx 526209 >>>> >>>> >>>> # ./athaggrstats >>>> 17 single frames scheduled >>>> 9 aggregate frames scheduled >>>> 1217 single frames scheduled due to low HWQ depth >>>> >>>> Aggregate size profile: >>>> >>>> 0: 0 1: 0 2: 6 3: 2 >>>> 4: 0 5: 0 6: 0 7: 1 >>>> 8: 0 9: 0 10: 0 11: 0 >> >> why # ifconfig -v wlan0 list channel >> show only b and g channels? and only 13? or this restriction AR9285 >> >> though >> # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K >> ------------------------------------------------------------ >> Client connecting to 192.168.1.26, TCP port 5001 >> TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) >> ------------------------------------------------------------ >> [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec Thanks I was confused that there is no mention n-mode in the output channel list From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:41:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EF6B604; Thu, 13 Dec 2012 01:41:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 616158FC0A; Thu, 13 Dec 2012 01:41:18 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so548738wgh.31 for ; Wed, 12 Dec 2012 17:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NT25UBoiPAMUxBsHphXiwGvOeOmF4B1ph91/5bHk6qQ=; b=kfMJNTNBZrDekvP6ErcAMVK1RpNaQaf446r0GWPLya2xZbWuPWL+WtUb660mE0DVrp Ijr0BHbdpvsYpHy3HRMLVomp1SOyLcmfllrmtQr0zFsHY88enqnhKH4matBmdwXfuA+F TpxoNBGn2QGSco/7GLzWtl9zUI1KtJCOLhsWFEDTGqkxW07XXgDYl0QuO0WbBf+SL8pp ZkNOVRjHvcHCVUgR8jYTbwazsLJxymjeI7a1VeL7CeqyXuhsLmFyuSJkKx9lswn6buuX UB2be4/JQJZWf2Cfa77Tdl3WkDuI+bzJyATF+scIib1fAKhBrSknKJgGbx/ofYOn1suy oZtg== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr5107732wjb.16.1355362877377; Wed, 12 Dec 2012 17:41:17 -0800 (PST) Received: by 10.217.57.9 with HTTP; Wed, 12 Dec 2012 17:41:17 -0800 (PST) In-Reply-To: References: <50c92508.6384440a.1379.3a4a@mx.google.com> Date: Wed, 12 Dec 2012 17:41:17 -0800 Message-ID: Subject: Re: AR9285 not see n-channels From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 01:41:19 -0000 Right, that's what "HT" is for. Adrian On 12 December 2012 17:39, Andrey Fesenko wrote: > On Thu, Dec 13, 2012 at 5:33 AM, Adrian Chadd wrote: >> Hi, >> >> The AR9285 is a 2GHz only NIC. >> >> The channel list shows 11b, 11bg, HT20 and HT40 channels. >> >> It all looks right, why don't you think it is? >> >> >> Adrian >> >> >> On 12 December 2012 17:32, Andrey Fesenko wrote: >>> On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: >>>> .. yup, you're doing 11n! Welcome! >>>> >>>> >>>> >>>> Adrian >>>> >>>> On 12 December 2012 16:54, Andrey Fesenko wrote: >>>>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >>>>>> Yup. It's doing 11n rates. >>>>>> >>>>>> Compile and run athstats, it'll tell you how many aggregate frames are being >>>>>> sent and received. >>>>>> >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> Sent from my Palm Pre on AT&T >>>>>> >>>>>> ________________________________ >>>>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>>>>> >>>>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>>>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>>>>> >>>>>>> >>>>>>> >>>>>>> adrian >>>>>>> >>>>>>> >>>>>>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>>>>>> I have >>>>>>>> # uname -a >>>>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>>>>> options ATH_ENABLE_11N >>>>>>>> options ATH_DEBUG >>>>>>>> options ATH_DIAGAPI >>>>>>>> >>>>>>>> pciconf >>>>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>>>>> rev=0x01 hdr=0x00 >>>>>>>> vendor = 'Atheros Communications Inc.' >>>>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>>>>> class = network >>>>>>>> >>>>>>>> >>>>>>>> # ifconfig -v wlan0 list channel >>>>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>>>>> .... >>>>>>>> >>>>>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>>>>> How to turn on or activate n-mode? >>>>>> >>>>>> # ifconfig wlan0 list sta >>>>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>>>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>>>>> RSN HTCAP WME WPS >>>>>> # ifconfig wlan0 >>>>>> wlan0: flags=8843 metric 0 mtu 1500 >>>>>> ether 4c:0f:6e:4b:4e:f5 >>>>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>>>>> nd6 options=29 >>>>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>>>>> status: associated >>>>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >>>>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >>>>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>>>>> burst roaming MANUAL >>>>> >>>>> # ./athstats >>>>> 526213 data frames received >>>>> 10205 data frames transmit >>>>> 79 short on-chip tx retries >>>>> 103 long on-chip tx retries >>>>> 16 tx failed 'cuz too many retries >>>>> 220 mib overflow interrupts >>>>> MCS7 current transmit rate >>>>> 1 watchdog timeouts >>>>> 42 beacon miss interrupts >>>>> 23154 rx failed 'cuz of bad CRC >>>>> 56 rx failed 'cuz of PHY err >>>>> 56 illegal service >>>>> 1638 periodic calibrations >>>>> -0/+0 TDMA slot adjust (usecs, smoothed) >>>>> 56 rssi of last ack >>>>> 50 avg recv rssi >>>>> -96 rx noise floor >>>>> 13 phantom beacon misses >>>>> 6569 tx frames through raw api >>>>> 1460 A-MPDU sub-frames received >>>>> 183 Half-GI frames received >>>>> 183 40MHz frames received >>>>> 2397 CRC errors for non-last A-MPDU subframes >>>>> 3151 Frames transmitted with HT Protection >>>>> 25 A-MPDU sub-frame TX attempt success >>>>> 2 first step level >>>>> 1 OFDM weak signal detect >>>>> 268 listen time >>>>> 190 ANI increased spur immunity >>>>> 174 ANI decrease spur immunity >>>>> 2 ANI enabled OFDM weak signal detect >>>>> 3517 ANI disabled OFDM weak signal detect >>>>> 3515 ANI disabled CCK weak signal threshold >>>>> 4 ANI increased first step level >>>>> 2 ANI decreased first step level >>>>> 154772 cumulative OFDM phy error count >>>>> 528256 cumulative CCK phy error count >>>>> 851 ANI forced listen time to zero >>>>> 26 missing ACK's >>>>> 78 RTS without CTS >>>>> 3135 successful RTS >>>>> 65747 bad FCS >>>>> 473007 beacons received >>>>> 53 average rssi (beacons only) >>>>> 35 average rssi (all rx'd frames) >>>>> 48 average rssi (ACKs only) >>>>> Antenna profile: >>>>> [0] tx 10173 rx 4 >>>>> [1] tx 0 rx 526209 >>>>> >>>>> >>>>> # ./athaggrstats >>>>> 17 single frames scheduled >>>>> 9 aggregate frames scheduled >>>>> 1217 single frames scheduled due to low HWQ depth >>>>> >>>>> Aggregate size profile: >>>>> >>>>> 0: 0 1: 0 2: 6 3: 2 >>>>> 4: 0 5: 0 6: 0 7: 1 >>>>> 8: 0 9: 0 10: 0 11: 0 >>> >>> why # ifconfig -v wlan0 list channel >>> show only b and g channels? and only 13? or this restriction AR9285 >>> >>> though >>> # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K >>> ------------------------------------------------------------ >>> Client connecting to 192.168.1.26, TCP port 5001 >>> TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) >>> ------------------------------------------------------------ >>> [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 >>> [ ID] Interval Transfer Bandwidth >>> [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec > > Thanks > > I was confused that there is no mention n-mode in the output channel list From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 03:01:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5736F5EC; Thu, 13 Dec 2012 03:01:47 +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 CAE668FC22; Thu, 13 Dec 2012 03:01:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEALJDyVCDaFvO/2dsb2JhbAA9CIY4tGSDaHOCHgEBBSNWGw4KAgINGQJZBogkqyKTAYEiiykLDIMZgRMDiGCNKZBIgxGBTzU X-IronPort-AV: E=Sophos;i="4.84,270,1355115600"; d="scan'208";a="4267142" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Dec 2012 22:01:39 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8C2F5B406D; Wed, 12 Dec 2012 22:01:39 -0500 (EST) Date: Wed, 12 Dec 2012 22:01:39 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1645494460.1368157.1355367699558.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121212043520.GF3013@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 03:01:47 -0000 Konstantin Belousov wrote: > On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: > > Ok, I'll test r243598 and then r243599 and r243835, just to > > see if it really is this. > > > > I'll email when I have done this. > If you test only r243598, I am sure that you would experience > corruption. > The r243599 should cause the deadlocks. > I think you meant r243599 will result in corruptions and r243835 deadlocks. I have run r243598 for a while without a hang. (r243599 doesn't build) I haven't tried r243835 yet. > > > > > > > > > > Also, do you use the post-r244095 kernel ? > > > > > > > > Before and after. The most recent tests were post-r244095. > > > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > > > > > > > > > Is your machine SMP ? > > > > > > > > Old, slow single core i386. > > > > > > Try this. Please note that this is mostly a debugging facility. > > > > > It seemed to help, but didn't stop the hangs completely. > > r244125 without the patch would hang somewhere in a kernel > > build. r244125 plus this patch ran almost 2 kernel builds > > before it got hung. > > Can you try to look into the system state on the hang (on the kernel > with the if (1 || patch applied) ? Using the ddb and recipe from the > web page. Basically watch for a thread looping in the mnt_active > iterator and threads owning vnode interlocks. Ok, there is only one process in the mnt_active iterator and its trace is as follows (syncer): dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe33afc lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame 0xdfe33b10 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 --- interrupt, eip = 0xc0eca8db, esp = 0xdfe33b60, ebp = 0xdfe33b64 --- spinlock_exit(c128be90,4,c10b5017,130,1710,...) at spinlock_exit+0x2b/frame 0xdfe33b64 __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at __mtx_unlock_spin_flags+0x112/frame 0xdfe33b90 kern_yield(ffffffff,0,c10c75c9,127b,c8b05238,...) at kern_yield+0x125/frame 0xdfe33bbc __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at __mnt_vnode_next_active+0xda/frame 0xdfe33be0 vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame 0xdfe33c18 sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at sync_fsync+0x141/frame 0xdfe33c64 VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at VOP_FSYNC_APV+0xb4/frame 0xdfe33c64 sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at sched_sync+0x399/frame 0xdfe33cc8 fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 --- trap 0, eip = 0, esp = 0xdfe33d40, ebp = 0 --- This process holds: exclusive lockmgr syncer (syncer) r = 0 (0xc85cf4c8) locked @ kern/vfs_subr.c:1780 The only other process that is doing anything in the VFS subsystem holds the vnode interlock. It's trace is: dle+0x12d/frame 0xdfe6a850 intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe6a870 lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame 0xdfe6a884 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 --- interrupt, eip = 0xc0b2206a, esp = 0xdfe6a8d4, ebp = 0xdfe6a908 --- witness_unlock(c8972a74,8,c10c75c9,965,0,...) at witness_unlock+0x3a/frame 0xdfe6a908 __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at __mtx_unlock_flags+0x9f/frame 0xdfe6a938 vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at vdropl+0x63/frame 0xdfe6a95c vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at vputx+0x300/frame 0xdfe6a994 vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame 0xdfe6a99c lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame 0xdfe6aa04 namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at vn_open_cred+0x2c0/frame 0xdfe6ab40 vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at vn_open+0x3b/frame 0xdfe6ab60 kern_openat(c85c55e0,ffffff9c,2882dcc0,0,8001,...) at kern_openat+0x1e2/frame 0xdfe6ac0c kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame 0xdfe6ac2c sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at sys_open+0x30/frame 0xdfe6ac48 syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x84a1667, esp = 0xbfbfcffc, ebp = 0xbfbfd018 --- The locks this process holds are: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0x8972a74) locked @ kern/vfs_subr.c:2513 shared lockmgr ufs (ufs) r = 0 (0xc8bd181c) locked @ kern/vfs_subr.c:2161 The only other lock held by any thread/process is: Process 12 (intr) thread 0xc5dfc5e0 (100012) exclusive sleep mutex Giant (Giant) r = 1 (0xc127b690) locked @ dev/syscons/syscons.c:724 The only 2 locked vnodes are the ufs one and the syncer one, as shown above. The rest of the processes/threads don't hold any locks and don't seem to be in vfs code. db> show pcpu (this machine is single core) cpuid = 0 dynamic pcpu = 0x5e5b00 curthread = 0xc5dfc5e0: pid 12 "swi6: Giant taskq" curpcb = 0xc592fd60 fpcurthread = none idlethread = 0xc5dfb8d0: tid 100003 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: db> When I do a "db> cont", wait a while and then go back into the debugger with , everything looks the same. I'll leave this machine like this, in case you want me to do anything else in the debugger. The kernel is r244125 + your little patch and it took about 5 kernel build cycles to get it hung. (Without your little patch, it usually hangs in the first kernel build cycle.) Do you happen to know how I can tell where it was executing when I ? (show registers just has the eip in kdb_enter) Can I work up a the stack referenced by esp and find a saved eip? rick ps: I'll admit I don't understand it. I haven't seen interrupt stuff in "bt"s before and the processes don't seem to be in a place where they block. From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 04:31:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3F90689; Thu, 13 Dec 2012 04:31:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6F108FC08; Thu, 13 Dec 2012 04:31:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBD4VXbR074293; Thu, 13 Dec 2012 06:31:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBD4VXbR074293 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBD4VWLj074292; Thu, 13 Dec 2012 06:31:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Dec 2012 06:31:32 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121213043132.GB71906@kib.kiev.ua> References: <20121212043520.GF3013@kib.kiev.ua> <1645494460.1368157.1355367699558.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <1645494460.1368157.1355367699558.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 04:31:43 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: > > > Ok, I'll test r243598 and then r243599 and r243835, just to > > > see if it really is this. > > > > > > I'll email when I have done this. > > If you test only r243598, I am sure that you would experience > > corruption. > > The r243599 should cause the deadlocks. > >=20 > I think you meant r243599 will result in corruptions and > r243835 deadlocks. >=20 > I have run r243598 for a while without a hang. (r243599 doesn't > build) I haven't tried r243835 yet. >=20 > > > > > > > > > > > > > Also, do you use the post-r244095 kernel ? > > > > > > > > > > Before and after. The most recent tests were post-r244095. > > > > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > > > > > > > > > > > > > Is your machine SMP ? > > > > > > > > > > Old, slow single core i386. > > > > > > > > Try this. Please note that this is mostly a debugging facility. > > > > > > > It seemed to help, but didn't stop the hangs completely. > > > r244125 without the patch would hang somewhere in a kernel > > > build. r244125 plus this patch ran almost 2 kernel builds > > > before it got hung. > >=20 > > Can you try to look into the system state on the hang (on the kernel > > with the if (1 || patch applied) ? Using the ddb and recipe from the > > web page. Basically watch for a thread looping in the mnt_active > > iterator and threads owning vnode interlocks. >=20 > Ok, there is only one process in the mnt_active iterator and its > trace is as follows (syncer): > dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') > intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at intr_= execute_handlers+0x49/frame 0xdfe33afc > lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame 0xdfe33b10 > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 > --- interrupt, eip =3D 0xc0eca8db, esp =3D 0xdfe33b60, ebp =3D 0xdfe33b64= --- > spinlock_exit(c128be90,4,c10b5017,130,1710,...) at spinlock_exit+0x2b/fra= me 0xdfe33b64 > __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at __mtx_unlock_sp= in_flags+0x112/frame 0xdfe33b90 > kern_yield(ffffffff,0,c10c75c9,127b,c8b05238,...) at kern_yield+0x125/fra= me 0xdfe33bbc > __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at __mnt_= vnode_next_active+0xda/frame 0xdfe33be0 > vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame 0xdfe33= c18 > sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at sync_fsync+0x141/= frame 0xdfe33c64 > VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at VOP_FSYNC_APV+0= xb4/frame 0xdfe33c64 > sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at sched_sync+0x399/fram= e 0xdfe33cc8 > fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 > --- trap 0, eip =3D 0, esp =3D 0xdfe33d40, ebp =3D 0 --- >=20 > This process holds: > exclusive lockmgr syncer (syncer) r =3D 0 (0xc85cf4c8) locked @ kern/vfs_= subr.c:1780 >=20 > The only other process that is doing anything in the VFS subsystem > holds the vnode interlock. It's trace is: > dle+0x12d/frame 0xdfe6a850 > intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at intr_= execute_handlers+0x49/frame 0xdfe6a870 > lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame 0xdfe6a884 > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 > --- interrupt, eip =3D 0xc0b2206a, esp =3D 0xdfe6a8d4, ebp =3D 0xdfe6a908= --- > witness_unlock(c8972a74,8,c10c75c9,965,0,...) at witness_unlock+0x3a/fram= e 0xdfe6a908 > __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at __mtx_unlock_= flags+0x9f/frame 0xdfe6a938 > vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at vdropl+0x63/frame = 0xdfe6a95c > vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at vputx+0x300/fr= ame 0xdfe6a994 > vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame 0xdf= e6a99c > lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame 0xdfe6a= a04 > namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 > vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at vn_open_cred+0x2c0/= frame 0xdfe6ab40 > vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at vn_open+0x3b/fram= e 0xdfe6ab60 > kern_openat(c85c55e0,ffffff9c,2882dcc0,0,8001,...) at kern_openat+0x1e2/f= rame 0xdfe6ac0c > kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame 0xdfe= 6ac2c > sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at sys_open+0x30= /frame 0xdfe6ac48 > syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc > --- syscall (5, FreeBSD ELF32, sys_open), eip =3D 0x84a1667, esp =3D 0xbf= bfcffc, ebp =3D 0xbfbfd018 --- >=20 > The locks this process holds are: > exclusive sleep mutex vnode interlock (vnode interlock) r =3D 0 (0x8972a7= 4) locked @ kern/vfs_subr.c:2513 > shared lockmgr ufs (ufs) r =3D 0 (0xc8bd181c) locked @ kern/vfs_subr.c:21= 61 >=20 > The only other lock held by any thread/process is: > Process 12 (intr) thread 0xc5dfc5e0 (100012) > exclusive sleep mutex Giant (Giant) r =3D 1 (0xc127b690) locked @ dev/sys= cons/syscons.c:724 >=20 > The only 2 locked vnodes are the ufs one and the syncer one, as > shown above. >=20 > The rest of the processes/threads don't hold any locks and don't seem > to be in vfs code. >=20 > db> show pcpu (this machine is single core) > cpuid =3D 0 > dynamic pcpu =3D 0x5e5b00 > curthread =3D 0xc5dfc5e0: pid 12 "swi6: Giant taskq" > curpcb =3D 0xc592fd60 > fpcurthread =3D none > idlethread =3D 0xc5dfb8d0: tid 100003 "idle: cpu0" > APIC ID =3D 0 > currentldt =3D 0x50 > spin locks held: > db> >=20 > When I do a "db> cont", wait a while and then go > back into the debugger with , everything > looks the same. >=20 > I'll leave this machine like this, in case you want me > to do anything else in the debugger. The kernel is > r244125 + your little patch and it took about 5 kernel > build cycles to get it hung. (Without your little > patch, it usually hangs in the first kernel build cycle.) >=20 > Do you happen to know how I can tell where it was executing > when I ? (show registers just has the eip in > kdb_enter) > Can I work up a the stack referenced by esp and find a saved > eip? The thread that was executing is shown as curthread from 'show pcpu'. Was it taskq always, or was taskq only sporadic, and syncer process rest of the time ? FWIW, you could try this patch too, at least I have a theory now why the if (1) patch did not helped. My guess is that kern_yield() effectively returned the same high-priority syncer process back to the CPU. diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 67e078d..2325201 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4710,32 +4710,54 @@ __mnt_vnode_markerfree_all(struct vnode **mvp, stru= ct mount *mp) * These are helper functions for filesystems to traverse their * active vnodes. See MNT_VNODE_FOREACH_ACTIVE() in sys/mount.h */ -struct vnode * -__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) +static void +mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *mp) +{ + + KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); + + MNT_ILOCK(mp); + MNT_REL(mp); + MNT_IUNLOCK(mp); + free(*mvp, M_VNODE_MARKER); + *mvp =3D NULL; +} + +#ifdef SMP +#define ALWAYS_YIELD (mp_ncpus =3D=3D 1) +#else +#define ALWAYS_YIELD 1 +#endif + +static struct vnode * +mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) { struct vnode *vp, *nvp; =20 - if (should_yield()) - kern_yield(PRI_UNCHANGED); - mtx_lock(&vnode_free_list_mtx); -restart: + mtx_assert(&vnode_free_list_mtx, MA_OWNED); KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); +restart: vp =3D TAILQ_NEXT(*mvp, v_actfreelist); + TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); while (vp !=3D NULL) { if (vp->v_type =3D=3D VMARKER) { vp =3D TAILQ_NEXT(vp, v_actfreelist); continue; } if (!VI_TRYLOCK(vp)) { - if (should_yield()) { + if (ALWAYS_YIELD || should_yield()) { + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); - kern_yield(PRI_UNCHANGED); + kern_yield(PRI_USER); mtx_lock(&vnode_free_list_mtx); + goto restart; } - goto restart; + continue; } - if (vp->v_mount =3D=3D mp && vp->v_type !=3D VMARKER && - (vp->v_iflag & VI_DOOMED) =3D=3D 0) + KASSERT(vp->v_type !=3D VMARKER, ("locked marker %p", vp)); + KASSERT(vp->v_mount =3D=3D mp || vp->v_mount =3D=3D NULL, + ("alien vnode on the active list %p %p", vp, mp)); + if (vp->v_mount =3D=3D mp && (vp->v_iflag & VI_DOOMED) =3D=3D 0) break; nvp =3D TAILQ_NEXT(vp, v_actfreelist); VI_UNLOCK(vp); @@ -4745,22 +4767,31 @@ restart: /* Check if we are done */ if (vp =3D=3D NULL) { mtx_unlock(&vnode_free_list_mtx); - __mnt_vnode_markerfree_active(mvp, mp); - mtx_assert(MNT_MTX(mp), MA_NOTOWNED); + mnt_vnode_markerfree_active(mvp, mp); return (NULL); } - TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); ASSERT_VI_LOCKED(vp, "active iter"); KASSERT((vp->v_iflag & VI_ACTIVE) !=3D 0, ("Non-active vp %p", vp)); return (vp); } +#undef ALWAYS_YIELD + +struct vnode * +__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) +{ + + if (should_yield()) + kern_yield(PRI_UNCHANGED); + mtx_lock(&vnode_free_list_mtx); + return (mnt_vnode_next_active(mvp, mp)); +} =20 struct vnode * __mnt_vnode_first_active(struct vnode **mvp, struct mount *mp) { - struct vnode *vp, *nvp; + struct vnode *vp; =20 *mvp =3D malloc(sizeof(struct vnode), M_VNODE_MARKER, M_WAITOK | M_ZERO); MNT_ILOCK(mp); @@ -4770,44 +4801,14 @@ __mnt_vnode_first_active(struct vnode **mvp, struct= mount *mp) (*mvp)->v_mount =3D mp; =20 mtx_lock(&vnode_free_list_mtx); -restart: vp =3D TAILQ_FIRST(&mp->mnt_activevnodelist); - while (vp !=3D NULL) { - if (vp->v_type =3D=3D VMARKER) { - vp =3D TAILQ_NEXT(vp, v_actfreelist); - continue; - } - if (!VI_TRYLOCK(vp)) { - if (should_yield()) { - mtx_unlock(&vnode_free_list_mtx); - kern_yield(PRI_UNCHANGED); - mtx_lock(&vnode_free_list_mtx); - } - goto restart; - } - if (vp->v_mount =3D=3D mp && vp->v_type !=3D VMARKER && - (vp->v_iflag & VI_DOOMED) =3D=3D 0) - break; - nvp =3D TAILQ_NEXT(vp, v_actfreelist); - VI_UNLOCK(vp); - vp =3D nvp; - } - - /* Check if we are done */ if (vp =3D=3D NULL) { mtx_unlock(&vnode_free_list_mtx); - MNT_ILOCK(mp); - MNT_REL(mp); - MNT_IUNLOCK(mp); - free(*mvp, M_VNODE_MARKER); - *mvp =3D NULL; + mnt_vnode_markerfree_active(mvp, mp); return (NULL); } - TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); - mtx_unlock(&vnode_free_list_mtx); - ASSERT_VI_LOCKED(vp, "active iter first"); - KASSERT((vp->v_iflag & VI_ACTIVE) !=3D 0, ("Non-active vp %p", vp)); - return (vp); + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); + return (mnt_vnode_next_active(mvp, mp)); } =20 void @@ -4817,14 +4818,8 @@ __mnt_vnode_markerfree_active(struct vnode **mvp, st= ruct mount *mp) if (*mvp =3D=3D NULL) return; =20 - KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); - mtx_lock(&vnode_free_list_mtx); TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); - MNT_ILOCK(mp); - MNT_REL(mp); - MNT_IUNLOCK(mp); - free(*mvp, M_VNODE_MARKER); - *mvp =3D NULL; + mnt_vnode_markerfree_active(mvp, mp); } --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDJWiMACgkQC3+MBN1Mb4iiZgCg9SBNPgZcGW9uqDB/xAzIvfRf uYcAoMadJl1T2CF2zJvIsperxCrOOL6q =oTXG -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 09:32:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E71DC3F5; Thu, 13 Dec 2012 09:32:00 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id A97B68FC0C; Thu, 13 Dec 2012 09:31:59 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEY00EOBQG7OQ10@smtp3.clear.net.nz>; Thu, 13 Dec 2012 22:31:19 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Thu, 13 Dec 2012 22:31:19 +1300 Date: Thu, 13 Dec 2012 22:31:05 +1300 From: Andrew Turner Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) In-reply-to: To: Daisuke Aoyama Message-id: <20121213223105.5a719efb@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 09:32:01 -0000 On Thu, 13 Dec 2012 02:08:50 +0900 "Daisuke Aoyama" wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. If you haven't seen there is the start of FreeBSD ARM support in clang: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html I'm testing this with the version of clang we have in head and hope to bring in support for clang and ARM soon. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 09:43:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 978DC9CB for ; Thu, 13 Dec 2012 09:43:21 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 549368FC1C for ; Thu, 13 Dec 2012 09:43:20 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 7A8862E2; Thu, 13 Dec 2012 10:41:17 +0100 (CET) Date: Thu, 13 Dec 2012 10:44:54 +0100 From: Pawel Jakub Dawidek To: Johan Hendriks Subject: Re: auditdistd config file location Message-ID: <20121213094454.GB1449@garage.freebsd.pl> References: <50BE18E5.2050004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline In-Reply-To: <50BE18E5.2050004@gmail.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 09:43:21 -0000 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 04, 2012 at 04:38:13PM +0100, Johan Hendriks wrote: > Hello all. >=20 > I had some spare time so i thought it was a good moment to look at=20 > auditdistd . > One thing i noticed was the default config file location. > The man page and the wiki tells me it is /etc/security/auditdistd >=20 > I enabled audistd by placing the following in the rc.conf file > auditdistd_enable=3D"YES" >=20 > However if i want to start the deamon, it tells me the config file is=20 > not present. > And that is correct, because my config is in /etc/security/ and not /etc/ >=20 > [root@smb-filer01 ~]# /etc/rc.d/auditdistd start > /etc/rc.d/auditdistd: WARNING: /etc/auditdistd.conf is not readable. > /etc/rc.d/auditdistd: WARNING: failed precmd routine for auditdistd > [root@smb-filer01 ~]# >=20 > I think the default location of the config file needs to be modified to= =20 > match that of the wiki page and the man page. The one in the man page is correct (/etc/security/auditdistd.conf). This was last minute change, which I just fixed (r244181). Thank you for the report! If you have any other questions, don't hesitate to ask. Feel free to CC me when sending a question to the mailing list. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --yEPQxsgoJgBvi8ip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDJo5YACgkQForvXbEpPzRO6gCfYrDJ6XxQ13ueU03vzbOdHy9h 4hsAn01AV42+Usqm1GSZs7a073RYcs7p =VzaL -----END PGP SIGNATURE----- --yEPQxsgoJgBvi8ip-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 10:00:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4C19241; Thu, 13 Dec 2012 10:00:49 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6747A8FC17; Thu, 13 Dec 2012 10:00:48 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id C981539D49; Thu, 13 Dec 2012 19:00:41 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id B4ABF39D46; Thu, 13 Dec 2012 19:00:41 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Andrew Turner" References: <20121213223105.5a719efb@fubar.geek.nz> In-Reply-To: <20121213223105.5a719efb@fubar.geek.nz> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 13 Dec 2012 19:00:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 10:00:49 -0000 >> I've created FreeBSD clang world for RPI based on svn 244112 + >> eabi.diff(NOT USE) + few NetBSD code. >> I didn't test with "-mfloat-abi=softfp" but it might work. > > If you haven't seen there is the start of FreeBSD ARM support in clang: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html > > I'm testing this with the version of clang we have in head and hope to > bring in support for clang and ARM soon. I didn't see this, but it's not enough. I already adjusted clang for your EABI patch, so the patched version of clang can be compiled for both OABI(apcs-gnu) and EABI(aapcs). Note that some world code is still broken for EABI w/clang. -- Daisuke Aoyama From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 10:22:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E28C760 for ; Thu, 13 Dec 2012 10:22:06 +0000 (UTC) (envelope-from yerenkow@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 28B378FC13 for ; Thu, 13 Dec 2012 10:22:04 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so813858wey.13 for ; Thu, 13 Dec 2012 02:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ESVlbDQH3smw7KplUHWxLcqtswq1Q+R3GSR0+xK+Qd4=; b=oTQ0X6LGfamNUVhYZp0UQ6hspiaIqHFkhhKuXnWzVo3Kr706rZ0K0H02I18ruBh0KO 0TfmDqqgS+z5NFcmQ6qNpNJrKyAYIWGAHW3jYmeKjpNIMyysr7iiFm9ji8NU9s8ByVuu 7Ib3ekXFOnxvvfRriE1UBx5yqnL49TPNG7CvPAy8gHbXXu1bDEZRjIGGifCW65AuM1sF H0J7j52PVgrs8qCQArLmNq+ycsw1fRik3dff24ozbRt5cHU5Lqq/ssr75Zc3BK0XhuTT a+CQ3p2B0cKiqGx0Uh/4UK09vF2chCmVNbTbpYfPM5SJCTYDZGyrcg+beudYwU8J0muq yitw== MIME-Version: 1.0 Received: by 10.180.104.136 with SMTP id ge8mr2250814wib.2.1355394123237; Thu, 13 Dec 2012 02:22:03 -0800 (PST) Received: by 10.194.40.131 with HTTP; Thu, 13 Dec 2012 02:22:02 -0800 (PST) Date: Thu, 13 Dec 2012 12:22:02 +0200 Message-ID: Subject: Reproduceable hang From: Alexander Yerenkow To: freebsd-current Content-Type: multipart/mixed; boundary=f46d04426e623f09d904d0b94915 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 10:22:06 -0000 --f46d04426e623f09d904d0b94915 Content-Type: text/plain; charset=ISO-8859-1 Hello there. I have here 100% reproduceable hangs when run one custom java program. Can someone look into? I can give some more info (some other trace) if required. -- Regards, Alexander Yerenkow --f46d04426e623f09d904d0b94915-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 10:25:51 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0AD593C; Thu, 13 Dec 2012 10:25: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 84E848FC19; Thu, 13 Dec 2012 10:25:50 +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 MAA13707; Thu, 13 Dec 2012 12:25:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9AD2C.7000301@FreeBSD.org> Date: Thu, 13 Dec 2012 12:25:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> In-Reply-To: <50C8DC8E.1080204@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Volodymyr Kostyrko , freebsd-current@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 10:25:51 -0000 on 12/12/2012 21:35 Dimitry Andric said the following: > Especially the recursive spa_load and traverse_visitbp calls are scary, > because that can grow out of hand very quickly. It is probably tricky > to remove the recursion... Re-entering spa_load once is normal and is expected. traverse_visitbp is also expected to recurse depending on data layout. So yeah, it's probably even trickier than teaching clang to allocate smaller stack frames ;-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 10:46:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D25974E3 for ; Thu, 13 Dec 2012 10:46:09 +0000 (UTC) (envelope-from yerenkow@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 59B908FC12 for ; Thu, 13 Dec 2012 10:46:09 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so826459wey.13 for ; Thu, 13 Dec 2012 02:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lco9ANkrQUbNdSu1ybLQMpObKW5UMAu1JW2oez5ErgI=; b=pr56IxOVPNYezDgYDBJcf/qdXX5HbEwrhZRIM4UAp/HPApyOvDeZJCeD3Wy4oUbGuV LVCsxrC420VDXWm1Ij2SVFHujYL6rowLAreTKFNhsMS05gpNv6hxpQtkFwTQMdmOLXRQ fwK0OoyB4MOTZq9FV88/WUKcFmeZ2eNwtKUOhVpQhQdTyZytLMlQRanH0CwTvzzi1WaR MgbEeZwU/SVPmIgTTT1guO/t5RMasGNB5i85AgLyOyEOfl9fqYf+oxQSAFCLnXHPpF8R nuJVOCysQgKhhxK8aIdfVrgY7xrccAH9FXHfOkzVTwDCBZ+VA4OoDfTEWt8tY83dq9ex Y9gw== MIME-Version: 1.0 Received: by 10.194.80.135 with SMTP id r7mr7357264wjx.58.1355395568341; Thu, 13 Dec 2012 02:46:08 -0800 (PST) Received: by 10.194.40.131 with HTTP; Thu, 13 Dec 2012 02:46:08 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 12:46:08 +0200 Message-ID: Subject: Re: Reproduceable hang From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 10:46:09 -0000 2012/12/13 Alexander Yerenkow > Hello there. > I have here 100% reproduceable hangs when run one custom java program. > Can someone look into? > > I can give some more info (some other trace) if required. > > If someone didn't get attachment - here's link to screenshot https://www.box.com/s/fir8ntjc4rjq5xv0vbyl -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 10:51:43 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5239844 for ; Thu, 13 Dec 2012 10:51:43 +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 3B0928FC14 for ; Thu, 13 Dec 2012 10:51:42 +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 MAA14041; Thu, 13 Dec 2012 12:51:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9B33C.9020505@FreeBSD.org> Date: Thu, 13 Dec 2012 12:51:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Yerenkow Subject: Re: Reproduceable hang References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 10:51:44 -0000 on 13/12/2012 12:46 Alexander Yerenkow said the following: > 2012/12/13 Alexander Yerenkow > >> Hello there. >> I have here 100% reproduceable hangs when run one custom java program. >> Can someone look into? >> >> I can give some more info (some other trace) if required. >> >> > > > If someone didn't get attachment - here's link to screenshot > > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl Looks like either a bug or an "out-of-sync" issue in whatever (virtualization?) driver that has function OS_ReservedPageAlloc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 11:21:05 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4AFD573 for ; Thu, 13 Dec 2012 11:21:05 +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 A280F8FC13 for ; Thu, 13 Dec 2012 11:21:00 +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 NAA14523; Thu, 13 Dec 2012 13:20:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9BA19.4040504@FreeBSD.org> Date: Thu, 13 Dec 2012 13:20:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-zfs@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 11:21:05 -0000 on 07/12/2012 02:33 Garrett Cooper said the following: > On Thu, Dec 6, 2012 at 3:08 PM, Garrett Cooper wrote: > > ... > >> Please document the process to make this work in UPDATING (or at least >> the fact that this behavior was changed). >> >> I'm debugging moving from 9.1-RC2 to CURRENT [as of Tuesday] as it >> hasn't been as smooth as some of the other upgrades I've done; my >> zpool -- root -- is setup with a non-legacy mountpoint, I noticed that >> the cachefile attribute is now "None", etc. I have limited capability >> with my installed system to debug this because unfortunately there >> aren't a ton of CURRENT based livecds around to run from (I might look >> into one of gjb's livecds later on if I get super stuck, but I'm >> trying to avoid having to do that). gptzfsboot sees the pool with >> lsdev, but it gets stuck at the mountroot prompt trying to find the >> filesystem. >> >> I'll wipe my /boot/kernel directory and try building/installing the >> kernel again, but right now I'm kind of dead in the water on the >> system I'm upgrading :/. One thing that I recommend to all ZFS users is to make use of boot environments. They are very easy, very convenient and may save a lot of trouble. Use either any of the tool available in ports (e.g. sysutils/beadm) or just "do boot environments" in an ad hoc fashion: snapshot and clone your current / known good boot+root filesystem and you have a safe environment to fall back to. > I thought r236884 requiring a zpool upgrade was the culprit, but > it wasn't. Still stuck at a mountroot prompt (but now I have gjb's > liveCD so I can do something about it). > Something looks off with zdb -l on CURRENT and STABLE/9. Example > on my 9-stable box: > > # uname -a > FreeBSD forza.west.isilon.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 > r+2fd0a57: Mon Dec 3 12:02:18 PST 2012 > gcooper@forza.west.isilon.com:/usr/obj/usr/src/sys/FORZA amd64 > # zdb -l sac2 > cannot open 'sac2': No such file or directory > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > sac 95G 69.7G 25.3G 73% 1.00x ONLINE - > sac2 232G 117G 115G 50% 1.00x ONLINE - Proper zdb -l usage was described in the "HEADSUP" posting. It's also available in zdb(8). zdb -l should be used with disks/partitions/etc, not with pool names. > I'm running into the same behavior before and after I upgraded sac/sac2. > My git branch is a lightly modified version of FreeBSD, but > doesn't contain any ZFS specific changes (I can point you to it if you > like to look at it). > Would appreciate some pointers on what to do next. Try to get a working environment (using livecd, another disk, backups, etc), try to follow the original instructions. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 11:24:48 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 097F5798 for ; Thu, 13 Dec 2012 11:24:48 +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 50BCF8FC14 for ; Thu, 13 Dec 2012 11:24:46 +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 NAA14576; Thu, 13 Dec 2012 13:24:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9BAFC.4020804@FreeBSD.org> Date: Thu, 13 Dec 2012 13:24:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 11:24:48 -0000 on 07/12/2012 02:55 Garrett Cooper said the following: > If I try and let it import the pool at boot it claims the pool is in a > FAULTED state when I point mountroot to /dev/cd0 (one of gjb's > snapshot CDs -- thanks!), run service hostid onestart, etc. If I > export and try to reimport the pool it claims it's not available (!). > However, if I boot, run service hostid onestart, _then_ import the > pool, then the pool is imported properly. This sounds messy, not sure if it has any informative value. I think I've seen something like this after some reason ZFS import from upsteam when my kernel and userland were out of sync. Do you do a full boot from the livecd? Or do you boot your kernel but then mount userland from the cd? In any case, not sure if this is relevan to your main trouble. > While I was mucking around with the pool trying to get the system to > boot I set the cachefile attribute to /boot/zfs/zpool.cache before > upgrading. In order to diagnose whether or not that was at fault, I > set that back to none and I'm still running into the same issue. > > I'm going to try backing out your commit and rebuild my kernel in > order to determine whether or not that's at fault. > > One other thing: both my machines have more than one ZFS-only zpool, > and it might be probing the pools in the wrong order; one of the pools > has bootfs set, the other doesn't, and the behavior is sort of > resembling it not being set properly. bootfs property should not better. Multi-pool configurations has been tested before the commit. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 12:29:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D6DDB7; Thu, 13 Dec 2012 12:29:26 +0000 (UTC) (envelope-from c.kworr@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 61BCC8FC08; Thu, 13 Dec 2012 12:29:25 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so986444bkc.13 for ; Thu, 13 Dec 2012 04:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D1UYFwr8ACvDOt8LYE2rEHeZQDRe9ontGpWFGB6DvM4=; b=vYOW5y5TpUEaDHA1O5VjOLgFYLqfkwrDz9tF8IXEP4NWlGCn6RybjGQVGQmCU5FYCp zeIEQOMhMXlwbPLs/lY8sLZeI1xulDC30bshKwQg6jszBS86ImiA7CSI5j3YQklWqFGi H7yhwh1DCuFYJxTFFSMKB26feoXo0yvq8OpqhODj4COjs79VtgfM5Z6xg96IxCsnib7l yYXtEvhgQJL37HbsMtYVhdH++itVM2D2evmFKySmNPBtXeX9O8DKYmNMAJLFyr3ldQHu pzeov3w316igGrdgra9ZH3Dj94CZsm1VhDZoF/yRuAS5bM4CXEJ0QHJ7lUS5ich6sT9i 2/Uw== Received: by 10.204.6.87 with SMTP id 23mr905559bky.78.1355401764304; Thu, 13 Dec 2012 04:29:24 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id u3sm1182439bkw.9.2012.12.13.04.29.21 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 04:29:22 -0800 (PST) Message-ID: <50C9CA1C.8030002@gmail.com> Date: Thu, 13 Dec 2012 14:29:16 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> In-Reply-To: <50C8DC8E.1080204@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 12:29:26 -0000 12.12.2012 21:35, Dimitry Andric: > On 2012-12-12 14:04, Volodymyr Kostyrko wrote: >> 04.12.2012 00:41, Konstantin Belousov: >>> Please try the patch below. It might give an immediate relief, but still >>> there are many offenders in the backtrace. >> >> I'm having almost the same issue and the patch doesn't work for me. > ... > > Looking at the stack frame addresses, it seems some of them are mangled. > Did you type this by hand? The differences between subsequent frames > are a bit strange because of it (and because of awk's integer > processing): Yes, I had typed that by hand. I attached link to the pictures just in case. > The kernel stack is just 8,192 bytes; since you can see these routines > are all consuming massive amounts of stack, and the calls are very > deeply nested, it is almost inevitable that it would crash. > > Especially the recursive spa_load and traverse_visitbp calls are scary, > because that can grow out of hand very quickly. It is probably tricky > to remove the recursion... After playing more with this kernel I also found it can crash not only by this scenario. There are different possible ways. I actually don't think there's a point fixing it right now. New clang is coming anyway... -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 13:15:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2EEFD71; Thu, 13 Dec 2012 13:15:10 +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 4AAA48FC0A; Thu, 13 Dec 2012 13:15:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANTTyVCDaFvO/2dsb2JhbAA9CIY4tGWDanOCHgEBBAEjBFIFFg4KAgINGQJZBoggBqpkkwmBIos1CwyDGYETA4hgjSmQSIMRgU81 X-IronPort-AV: E=Sophos;i="4.84,273,1355115600"; d="scan'208";a="4306626" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Dec 2012 08:15:08 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5409BB4051; Thu, 13 Dec 2012 08:15:08 -0500 (EST) Date: Thu, 13 Dec 2012 08:15:08 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <391208440.1371194.1355404508315.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121213043132.GB71906@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 13:15:11 -0000 Konstantin Belousov wrote: > On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: > > > > Ok, I'll test r243598 and then r243599 and r243835, just to > > > > see if it really is this. > > > > > > > > I'll email when I have done this. > > > If you test only r243598, I am sure that you would experience > > > corruption. > > > The r243599 should cause the deadlocks. > > > > > I think you meant r243599 will result in corruptions and > > r243835 deadlocks. > > > > I have run r243598 for a while without a hang. (r243599 doesn't > > build) I haven't tried r243835 yet. > > > > > > > > > > > > > > > > > > Also, do you use the post-r244095 kernel ? > > > > > > > > > > > > Before and after. The most recent tests were post-r244095. > > > > > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > > > > > > > > > > > > > > > > > Is your machine SMP ? > > > > > > > > > > > > Old, slow single core i386. > > > > > > > > > > Try this. Please note that this is mostly a debugging > > > > > facility. > > > > > > > > > It seemed to help, but didn't stop the hangs completely. > > > > r244125 without the patch would hang somewhere in a kernel > > > > build. r244125 plus this patch ran almost 2 kernel builds > > > > before it got hung. > > > > > > Can you try to look into the system state on the hang (on the > > > kernel > > > with the if (1 || patch applied) ? Using the ddb and recipe from > > > the > > > web page. Basically watch for a thread looping in the mnt_active > > > iterator and threads owning vnode interlocks. > > > > Ok, there is only one process in the mnt_active iterator and its > > trace is as follows (syncer): > > dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') > > intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at > > intr_execute_handlers+0x49/frame 0xdfe33afc > > lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame > > 0xdfe33b10 > > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 > > --- interrupt, eip = 0xc0eca8db, esp = 0xdfe33b60, ebp = 0xdfe33b64 > > --- > > spinlock_exit(c128be90,4,c10b5017,130,1710,...) at > > spinlock_exit+0x2b/frame 0xdfe33b64 > > __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at > > __mtx_unlock_spin_flags+0x112/frame 0xdfe33b90 > > kern_yield(ffffffff,0,c10c75c9,127b,c8b05238,...) at > > kern_yield+0x125/frame 0xdfe33bbc > > __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at > > __mnt_vnode_next_active+0xda/frame 0xdfe33be0 > > vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame > > 0xdfe33c18 > > sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at > > sync_fsync+0x141/frame 0xdfe33c64 > > VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at > > VOP_FSYNC_APV+0xb4/frame 0xdfe33c64 > > sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at > > sched_sync+0x399/frame 0xdfe33cc8 > > fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 > > fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 > > --- trap 0, eip = 0, esp = 0xdfe33d40, ebp = 0 --- > > > > This process holds: > > exclusive lockmgr syncer (syncer) r = 0 (0xc85cf4c8) locked @ > > kern/vfs_subr.c:1780 > > > > The only other process that is doing anything in the VFS subsystem > > holds the vnode interlock. It's trace is: > > dle+0x12d/frame 0xdfe6a850 > > intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at > > intr_execute_handlers+0x49/frame 0xdfe6a870 > > lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame > > 0xdfe6a884 > > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 > > --- interrupt, eip = 0xc0b2206a, esp = 0xdfe6a8d4, ebp = 0xdfe6a908 > > --- > > witness_unlock(c8972a74,8,c10c75c9,965,0,...) at > > witness_unlock+0x3a/frame 0xdfe6a908 > > __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at > > __mtx_unlock_flags+0x9f/frame 0xdfe6a938 > > vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at > > vdropl+0x63/frame 0xdfe6a95c > > vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at > > vputx+0x300/frame 0xdfe6a994 > > vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame > > 0xdfe6a99c > > lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame > > 0xdfe6aa04 > > namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 > > vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at > > vn_open_cred+0x2c0/frame 0xdfe6ab40 > > vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at > > vn_open+0x3b/frame 0xdfe6ab60 > > kern_openat(c85c55e0,ffffff9c,2882dcc0,0,8001,...) at > > kern_openat+0x1e2/frame 0xdfe6ac0c > > kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame > > 0xdfe6ac2c > > sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at > > sys_open+0x30/frame 0xdfe6ac48 > > syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc > > --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x84a1667, esp = > > 0xbfbfcffc, ebp = 0xbfbfd018 --- > > > > The locks this process holds are: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > > (0x8972a74) locked @ kern/vfs_subr.c:2513 > > shared lockmgr ufs (ufs) r = 0 (0xc8bd181c) locked @ > > kern/vfs_subr.c:2161 > > > > The only other lock held by any thread/process is: > > Process 12 (intr) thread 0xc5dfc5e0 (100012) > > exclusive sleep mutex Giant (Giant) r = 1 (0xc127b690) locked @ > > dev/syscons/syscons.c:724 > > > > The only 2 locked vnodes are the ufs one and the syncer one, as > > shown above. > > > > The rest of the processes/threads don't hold any locks and don't > > seem > > to be in vfs code. > > > > db> show pcpu (this machine is single core) > > cpuid = 0 > > dynamic pcpu = 0x5e5b00 > > curthread = 0xc5dfc5e0: pid 12 "swi6: Giant taskq" > > curpcb = 0xc592fd60 > > fpcurthread = none > > idlethread = 0xc5dfb8d0: tid 100003 "idle: cpu0" > > APIC ID = 0 > > currentldt = 0x50 > > spin locks held: > > db> > > > > When I do a "db> cont", wait a while and then go > > back into the debugger with , everything > > looks the same. > > > > I'll leave this machine like this, in case you want me > > to do anything else in the debugger. The kernel is > > r244125 + your little patch and it took about 5 kernel > > build cycles to get it hung. (Without your little > > patch, it usually hangs in the first kernel build cycle.) > > > > Do you happen to know how I can tell where it was executing > > when I ? (show registers just has the eip in > > kdb_enter) > > Can I work up a the stack referenced by esp and find a saved > > eip? > The thread that was executing is shown as curthread from 'show pcpu'. > Was it taskq always, or was taskq only sporadic, and syncer process > rest of the time ? > I've never seen say anything except "taskq". (I just tried about 10 cycles of "cont, wait a bit, , show pcpu" and it has always been "taskq". It has always been "taskq" any other hang as well.) > FWIW, you could try this patch too, at least I have a theory now why > the if (1) patch did not helped. My guess is that kern_yield() > effectively > returned the same high-priority syncer process back to the CPU. > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index 67e078d..2325201 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -4710,32 +4710,54 @@ __mnt_vnode_markerfree_all(struct vnode **mvp, > struct mount *mp) > * These are helper functions for filesystems to traverse their > * active vnodes. See MNT_VNODE_FOREACH_ACTIVE() in sys/mount.h > */ > -struct vnode * > -__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > +static void > +mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *mp) > +{ > + > + KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list > mismatch")); > + > + MNT_ILOCK(mp); > + MNT_REL(mp); > + MNT_IUNLOCK(mp); > + free(*mvp, M_VNODE_MARKER); > + *mvp = NULL; > +} > + > +#ifdef SMP > +#define ALWAYS_YIELD (mp_ncpus == 1) > +#else > +#define ALWAYS_YIELD 1 > +#endif > + > +static struct vnode * > +mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > { > struct vnode *vp, *nvp; > > - if (should_yield()) > - kern_yield(PRI_UNCHANGED); > - mtx_lock(&vnode_free_list_mtx); > -restart: > + mtx_assert(&vnode_free_list_mtx, MA_OWNED); > KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list mismatch")); > +restart: > vp = TAILQ_NEXT(*mvp, v_actfreelist); > + TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > while (vp != NULL) { > if (vp->v_type == VMARKER) { > vp = TAILQ_NEXT(vp, v_actfreelist); > continue; > } > if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > + if (ALWAYS_YIELD || should_yield()) { > + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > - kern_yield(PRI_UNCHANGED); > + kern_yield(PRI_USER); > mtx_lock(&vnode_free_list_mtx); > + goto restart; > } > - goto restart; > + continue; > } > - if (vp->v_mount == mp && vp->v_type != VMARKER && > - (vp->v_iflag & VI_DOOMED) == 0) > + KASSERT(vp->v_type != VMARKER, ("locked marker %p", vp)); > + KASSERT(vp->v_mount == mp || vp->v_mount == NULL, > + ("alien vnode on the active list %p %p", vp, mp)); > + if (vp->v_mount == mp && (vp->v_iflag & VI_DOOMED) == 0) > break; > nvp = TAILQ_NEXT(vp, v_actfreelist); > VI_UNLOCK(vp); > @@ -4745,22 +4767,31 @@ restart: > /* Check if we are done */ > if (vp == NULL) { > mtx_unlock(&vnode_free_list_mtx); > - __mnt_vnode_markerfree_active(mvp, mp); > - mtx_assert(MNT_MTX(mp), MA_NOTOWNED); > + mnt_vnode_markerfree_active(mvp, mp); > return (NULL); > } > - TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > ASSERT_VI_LOCKED(vp, "active iter"); > KASSERT((vp->v_iflag & VI_ACTIVE) != 0, ("Non-active vp %p", vp)); > return (vp); > } > +#undef ALWAYS_YIELD > + > +struct vnode * > +__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > +{ > + > + if (should_yield()) > + kern_yield(PRI_UNCHANGED); > + mtx_lock(&vnode_free_list_mtx); > + return (mnt_vnode_next_active(mvp, mp)); > +} > > struct vnode * > __mnt_vnode_first_active(struct vnode **mvp, struct mount *mp) > { > - struct vnode *vp, *nvp; > + struct vnode *vp; > > *mvp = malloc(sizeof(struct vnode), M_VNODE_MARKER, M_WAITOK | > M_ZERO); > MNT_ILOCK(mp); > @@ -4770,44 +4801,14 @@ __mnt_vnode_first_active(struct vnode **mvp, > struct mount *mp) > (*mvp)->v_mount = mp; > > mtx_lock(&vnode_free_list_mtx); > -restart: > vp = TAILQ_FIRST(&mp->mnt_activevnodelist); > - while (vp != NULL) { > - if (vp->v_type == VMARKER) { > - vp = TAILQ_NEXT(vp, v_actfreelist); > - continue; > - } > - if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > - mtx_unlock(&vnode_free_list_mtx); > - kern_yield(PRI_UNCHANGED); > - mtx_lock(&vnode_free_list_mtx); > - } > - goto restart; > - } > - if (vp->v_mount == mp && vp->v_type != VMARKER && > - (vp->v_iflag & VI_DOOMED) == 0) > - break; > - nvp = TAILQ_NEXT(vp, v_actfreelist); > - VI_UNLOCK(vp); > - vp = nvp; > - } > - > - /* Check if we are done */ > if (vp == NULL) { > mtx_unlock(&vnode_free_list_mtx); > - MNT_ILOCK(mp); > - MNT_REL(mp); > - MNT_IUNLOCK(mp); > - free(*mvp, M_VNODE_MARKER); > - *mvp = NULL; > + mnt_vnode_markerfree_active(mvp, mp); > return (NULL); > } > - TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, > v_actfreelist); > - mtx_unlock(&vnode_free_list_mtx); > - ASSERT_VI_LOCKED(vp, "active iter first"); > - KASSERT((vp->v_iflag & VI_ACTIVE) != 0, ("Non-active vp %p", vp)); > - return (vp); > + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); > + return (mnt_vnode_next_active(mvp, mp)); > } > > void > @@ -4817,14 +4818,8 @@ __mnt_vnode_markerfree_active(struct vnode > **mvp, struct mount *mp) > if (*mvp == NULL) > return; > > - KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list > mismatch")); > - > mtx_lock(&vnode_free_list_mtx); > TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > - MNT_ILOCK(mp); > - MNT_REL(mp); > - MNT_IUNLOCK(mp); > - free(*mvp, M_VNODE_MARKER); > - *mvp = NULL; > + mnt_vnode_markerfree_active(mvp, mp); > } I'll try this patch and let you know what happens. rick From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 14:14:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D671FA2C; Thu, 13 Dec 2012 14:14:03 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB5B8FC17; Thu, 13 Dec 2012 14:14:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBDEE2oD068957; Thu, 13 Dec 2012 07:14:02 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBDEDxYF057893; Thu, 13 Dec 2012 07:13:59 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Ian Lepore To: Kimmo Paasiala In-Reply-To: References: <1355331231.87661.461.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Dec 2012 07:13:59 -0700 Message-ID: <1355408039.87661.491.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 14:14:03 -0000 On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote: > On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore > wrote: > > On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote: > >> Hello, > >> > >> My 9-STABLE buildworld broke in a very inexplicable way, I was > >> getting an error on /usr/src/include/osreldate.h that I couldn't > >> figure out until I started looking at the sys/conf/newvers.sh and what > >> it does. It turned out that the thing that broke my buildworld was > >> having .git directory at the root directory of the system because I > >> recently started using GIT to track the configuration files. > >> > >> I added some debug echos to the newvers.sh and I found out it's > >> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set > >> the gitdir to /.git and that seems to break the logic in newvers.sh. > >> > >> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source > >> tree (/usr/src/sys default)? > >> > >> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in > >> newvers.sh: > >> > >> SYSDIR=$(dirname $0)/.. > >> > >> $0 is actually /bin/sh and not the path to newver.sh because the > >> newvers.sh is sourced by the Makefile in /usr/src/include instead of > >> executing it: > >> > >> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \ > >> ${.CURDIR}/Makefile > >> @${ECHO} creating osreldate.h from newvers.sh > >> @MAKE=${MAKE}; \ > >> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ > >> . ${.CURDIR}/../sys/conf/newvers.sh; \ > >> > >> Now the question is how to fix this? > >> > >> -Kimmo > > > > Perhaps it could be handled similar to PARAMFILE, something like this in > > the makefile: > > > > PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ > > SYSDIR=${.CURDIR}/../sys; \ > > . ${.CURDIR}/../sys/conf/newvers.sh; \ > > > > I'm not sure if newvers.sh needs to work in ways that don't involve > > being invoked from that makefile rule, so to be safe it could have > > default handling, something like: > > > > : ${SYSDIR:=$(dirname $0)/..} > > > > -- Ian > > > > > > Thanks, that works. Should I file a PR about this? > > -Kimmo I think that would probably be a good idea, since no committer has chimed in on this thread saying they're about to commit a fix. -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 16:00:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B76D1C30; Thu, 13 Dec 2012 16:00:48 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0CDC08FC14; Thu, 13 Dec 2012 16:00:46 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id qBDG0dWv062654; Thu, 13 Dec 2012 10:00:39 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id qBDG0cxN062653; Thu, 13 Dec 2012 10:00:38 -0600 (CST) (envelope-from brooks) Date: Thu, 13 Dec 2012 10:00:38 -0600 From: Brooks Davis To: "Robert N. M. Watson" Subject: Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Message-ID: <20121213160038.GE40927@lor.one-eyed-alien.net> References: <50BA7158.1040302@fgznet.ch> <50BB136F.4040509@zedat.fu-berlin.de> <0857C6CA-31DF-441D-B30E-F7DB2492C213@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zaRBsRFn0XYhEU69" Content-Disposition: inline In-Reply-To: <0857C6CA-31DF-441D-B30E-F7DB2492C213@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "O. Hartmann" , FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 16:00:48 -0000 --zaRBsRFn0XYhEU69 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 02, 2012 at 03:43:22PM +0000, Robert N. M. Watson wrote: >=20 > On 2 Dec 2012, at 15:34, Ryan Stone wrote: >=20 > > On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson wro= te: > >=20 > > Just to follow up on this thread, since the question has come up a numb= er of times. "mergemaser -p" should be run prior to installworld always, b= ut most of the time will do very little. One of its responsibilities is to= add any necessary accounts and groups depended on by base system component= s -- e.g., that will be referenced during installworld as part of setting f= ile ownership and groups. > >=20 > > I often use "make installworld installkernel distribution DESTDIR=3D...= " to create bootable images (e.g. for a USB stick). What's the recommendat= ion for that case? Manually create the auditdistd user on the build host? >=20 > Yes, that's probably the best short-term bet. >=20 > In the longer term, it would be nice of installworld could not only gener= ate an mtree on the side rather than directly chmod/chowning the files (Bro= oks Davis has patches for this), but also use UIDs/GIDs from a user databas= e directly rather than assuming that the host where you are constructing th= e image has the same notion of users and groups. This is especially importa= nt if we want to support cross-building embedded images from Linux, Mac OS = X, etc, in the future. >=20 One useful feature of NetBSD's install is that we can use passwd and group databases other than the one in /. You would obviously use this when doing an unprivileged install, but you might also want to do it for a privileged install as well which would fix this bootstrapping problem. -- Brooks --zaRBsRFn0XYhEU69 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQyfumXY6L6fI4GtQRAmGZAKCd0T5MftevJmM44yWAYXRMDL89CQCfb0dk wVRJpCNCZHf/qRTwnFJx68g= =TdhV -----END PGP SIGNATURE----- --zaRBsRFn0XYhEU69-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 16:31:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08300ED3; Thu, 13 Dec 2012 16:31:24 +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 91D548FC0A; Thu, 13 Dec 2012 16:31:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A050873029; Thu, 13 Dec 2012 17:29:49 +0100 (CET) Date: Thu, 13 Dec 2012 17:29:49 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: new pc-bios/bios.bin breaks freebsd booting Message-ID: <20121213162949.GA23250@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: emulation@freebsd.org, nox@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 16:31:24 -0000 On Wed, Dec 12, 2012 at 09:01:01AM -0800, Adrian Chadd wrote: > Yes, the qemu bios people decided that they could change the ACPI > setup, in order to make Linux boot slightly (1 line) quieter. > > http://git.qemu.org/?p=seabios.git;a=commit;h=4540409d19a4baeec5006d925cfca19f8038a96e the qemu folks are actually being very responsive in trying to fix this for FreeBSD. See http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01703.html and also the message below cheers luigi ----- Forwarded message from Paolo Bonzini ----- Date: Thu, 13 Dec 2012 14:38:45 +0100 From: Paolo Bonzini Subject: Re: [SeaBIOS] [PATCH] acpi: reintroduce LNKS To: Laszlo Ersek CC: seabios@seabios.org, rizzo@iet.unipi.it, Marcelo Tosatti Il 13/12/2012 14:33, Laszlo Ersek ha scritto: >> > Unfortunately, the code after the patch is also against the spec, and it >> > breaks FreeBSD because it treats IRQ 9 polarity as active low without >> > the Interrupt() entry. Actually, numeric _PRT entries are handled the >> > same in Linux and FreeBSD (as active-low). However, under Linux it just >> > happens to trigger another special casing of SCI which sets SCI up from >> > its override entry in the MADT, ignoring the DSDT completely. > I won't pretend I understand what I'm talking about, but the ACPI spec > 5.0 says in "5.2.12.5 Interrupt Source Override Structure", > > Interrupt Source Overrides are also necessary when an identity > mapped interrupt input has a non-standard polarity. > > Hence "necessary but not sufficient", is that it? The MADT is about 8259 pins, while the _PRT entry identifies a GSI. So we have the same GSI (9) specified twice. Linux ignores the settings of the second entry and reuses those that came from the GSI. The important bit here is this: /* Don't set up the ACPI SCI because it's already set up */ if (acpi_gbl_FADT.sci_interrupt == gsi) return gsi; (And as you can see it's wrong, sci_interrupt is an 8259 interrupt not a GSI). > SCI_INT in the FADT is explained as > > [...] OSPM is required to treat the ACPI SCI interrupt as a > sharable, level, active low interrupt. > > which is then overridden in the MADT, stating active-high polarity. Yes, but this doesn't affect the definition of this GSI in the _PRT. It is always level/active-low for a numeric entry. Among the two conflicting choices, Linux happens to favor the MADT. FreeBSD doesn't. Paolo ----- End forwarded message ----- > > > > Adrian > > On 12 December 2012 08:07, Luigi Rizzo wrote: > > it seems that qemu-1.3.0 is broken for freebsd... > > > > cheers > > luigi > > > > ---------- Forwarded message ---------- > > From: Luigi Rizzo > > Date: Wed, Dec 12, 2012 at 8:04 AM > > Subject: new pc-bios/bios.bin breaks freebsd booting > > To: qemu-devel@nongnu.org, kraxel@redhat.com > > > > > > I am not sure if it has been reported already but this commit > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 > > > > (replacing pc-bios/bios.bin with a newer version) > > breaks booting of FreeBSD on recent qemu (starting roughly with qemu- > > 1.3.0-rc2). > > > > Using a FreeBSD host, and a FreeBSD guest, > > the qemu thread runs at 100% and the console is stuck > > after the 'pci0' probe: > > > > > > ... > > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 100000000 Hz quality 950 > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 > > > > pcib0: port 0xcf8-0xcff on acpi0 > > > > pci0: on pcib0 > > > > Reverting the bios fixes things. > > I wonder if it isn't the case of reverting this change ? > > > > cheers > > luigi > > > > > > > > -- > > -----------------------------------------+------------------------------- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+------------------------------- > > > > > > > > > > -- > > -----------------------------------------+------------------------------- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+------------------------------- > > _______________________________________________ > > 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 Dec 13 17:46:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF113F18; Thu, 13 Dec 2012 17:46:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 105918FC14; Thu, 13 Dec 2012 17:46:29 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so929514wgh.31 for ; Thu, 13 Dec 2012 09:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IUXFrUJOwQfoURlqb2RtVB/1gZJhbLwHUV5DQenv++w=; b=Y2Z+csbEudwCZ83iuVSG4a913MR9BvMlRb68+ck0TqZ/yDcZOiy9RvobvchK85lP+4 cjULiE0kZYerQak39xjmB5HZk/uhXRDqBK9THqZSztgMDiG3PNdCf7s6k8DPMjpp+QfD 3RXTp8RUjRWZGDOqoYRXvO3+8rdsgAjaVL1cNvyNqDnuSaKTRLWCcS5U/r5MBRGAAlZA he2Rp3pu1px9blOEOy5SaqujubBo8jio26Utn7lE184DQ//H/Is1p4pvz0qcE1ggQi08 kFdpqlC5v/X84WecuFVlKox7gkEJ/bAl8U0Yqaa7KO2zE7PVdRfHg6ARNpuBwaIdqdVa V9lw== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr9930777wjb.16.1355420783089; Thu, 13 Dec 2012 09:46:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Thu, 13 Dec 2012 09:46:23 -0800 (PST) In-Reply-To: <20121213162949.GA23250@onelab2.iet.unipi.it> References: <20121213162949.GA23250@onelab2.iet.unipi.it> Date: Thu, 13 Dec 2012 09:46:23 -0800 X-Google-Sender-Auth: wiFE1CjglvD1DhJioWcEbfSLs8Y Message-ID: Subject: Re: new pc-bios/bios.bin breaks freebsd booting From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: emulation@freebsd.org, nox@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 17:46:31 -0000 Oh, phew. :) adrian On 13 December 2012 08:29, Luigi Rizzo wrote: > On Wed, Dec 12, 2012 at 09:01:01AM -0800, Adrian Chadd wrote: >> Yes, the qemu bios people decided that they could change the ACPI >> setup, in order to make Linux boot slightly (1 line) quieter. >> >> http://git.qemu.org/?p=seabios.git;a=commit;h=4540409d19a4baeec5006d925cfca19f8038a96e > > the qemu folks are actually being very responsive in trying to fix > this for FreeBSD. See > > http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01703.html > > and also the message below > > cheers > luigi > > ----- Forwarded message from Paolo Bonzini ----- > > Date: Thu, 13 Dec 2012 14:38:45 +0100 > From: Paolo Bonzini > Subject: Re: [SeaBIOS] [PATCH] acpi: reintroduce LNKS > To: Laszlo Ersek > CC: seabios@seabios.org, rizzo@iet.unipi.it, > Marcelo Tosatti > > Il 13/12/2012 14:33, Laszlo Ersek ha scritto: >>> > Unfortunately, the code after the patch is also against the spec, and it >>> > breaks FreeBSD because it treats IRQ 9 polarity as active low without >>> > the Interrupt() entry. Actually, numeric _PRT entries are handled the >>> > same in Linux and FreeBSD (as active-low). However, under Linux it just >>> > happens to trigger another special casing of SCI which sets SCI up from >>> > its override entry in the MADT, ignoring the DSDT completely. >> I won't pretend I understand what I'm talking about, but the ACPI spec >> 5.0 says in "5.2.12.5 Interrupt Source Override Structure", >> >> Interrupt Source Overrides are also necessary when an identity >> mapped interrupt input has a non-standard polarity. >> >> Hence "necessary but not sufficient", is that it? > > The MADT is about 8259 pins, while the _PRT entry identifies a GSI. So > we have the same GSI (9) specified twice. Linux ignores the settings of > the second entry and reuses those that came from the GSI. The important > bit here is this: > > /* Don't set up the ACPI SCI because it's already set up */ > if (acpi_gbl_FADT.sci_interrupt == gsi) > return gsi; > > (And as you can see it's wrong, sci_interrupt is an 8259 interrupt not a > GSI). > >> SCI_INT in the FADT is explained as >> >> [...] OSPM is required to treat the ACPI SCI interrupt as a >> sharable, level, active low interrupt. >> >> which is then overridden in the MADT, stating active-high polarity. > > Yes, but this doesn't affect the definition of this GSI in the _PRT. It > is always level/active-low for a numeric entry. Among the two > conflicting choices, Linux happens to favor the MADT. FreeBSD doesn't. > > Paolo > > ----- End forwarded message ----- > >> >> >> >> Adrian >> >> On 12 December 2012 08:07, Luigi Rizzo wrote: >> > it seems that qemu-1.3.0 is broken for freebsd... >> > >> > cheers >> > luigi >> > >> > ---------- Forwarded message ---------- >> > From: Luigi Rizzo >> > Date: Wed, Dec 12, 2012 at 8:04 AM >> > Subject: new pc-bios/bios.bin breaks freebsd booting >> > To: qemu-devel@nongnu.org, kraxel@redhat.com >> > >> > >> > I am not sure if it has been reported already but this commit >> > >> > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 >> > >> > (replacing pc-bios/bios.bin with a newer version) >> > breaks booting of FreeBSD on recent qemu (starting roughly with qemu- >> > 1.3.0-rc2). >> > >> > Using a FreeBSD host, and a FreeBSD guest, >> > the qemu thread runs at 100% and the console is stuck >> > after the 'pci0' probe: >> > >> > >> > ... >> > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> > >> > Timecounter "HPET" frequency 100000000 Hz quality 950 >> > >> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> > >> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 >> > >> > pcib0: port 0xcf8-0xcff on acpi0 >> > >> > pci0: on pcib0 >> > >> > Reverting the bios fixes things. >> > I wonder if it isn't the case of reverting this change ? >> > >> > cheers >> > luigi >> > >> > >> > >> > -- >> > -----------------------------------------+------------------------------- >> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> > TEL +39-050-2211611 . via Diotisalvi 2 >> > Mobile +39-338-6809875 . 56122 PISA (Italy) >> > -----------------------------------------+------------------------------- >> > >> > >> > >> > >> > -- >> > -----------------------------------------+------------------------------- >> > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> > TEL +39-050-2211611 . via Diotisalvi 2 >> > Mobile +39-338-6809875 . 56122 PISA (Italy) >> > -----------------------------------------+------------------------------- >> > _______________________________________________ >> > 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 Dec 13 20:49:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50B295A0 for ; Thu, 13 Dec 2012 20:49:39 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 087348FC0A for ; Thu, 13 Dec 2012 20:49:38 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2588225obc.13 for ; Thu, 13 Dec 2012 12:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jgo7g8GjbSg15dusNFgJupXruJIG8gy3Ptf2OdYdUUA=; b=Sz6c7sRNKMd7N8krfyZ2GwpyVnFP0uXMqHuSfLO+ns70Zo5S5S/tbtZluQ6EOL0gxo lgWU029vi/IKdMyVL7AB3jayc0H7rnZxHy29ou1MAbYMeqa4VR3sVHoIkWf/ytNekV+I ov2fpLF8C1rJ6fDoeqKruNVHYXrWlskmq2YikndrXAFqC7+rJ0OqIHTQ+9dUqLrMXaHI +rg9je7PWdY6hCJo4um3bNonyEMAwv4DG1So613A5N4ydVQcF2Da4FZy6khFbEQBUDos eZaGX/XHueDCfaav9FjlZURmPoDdTvTNnTi4MYsVVE5pBPxv9gtg6DoNVirfOuE9flNI KN1w== MIME-Version: 1.0 Received: by 10.182.157.45 with SMTP id wj13mr2730051obb.58.1355431778478; Thu, 13 Dec 2012 12:49:38 -0800 (PST) Received: by 10.182.190.83 with HTTP; Thu, 13 Dec 2012 12:49:38 -0800 (PST) Date: Thu, 13 Dec 2012 15:49:38 -0500 Message-ID: Subject: new xorg segfault 11 with KMS From: Johannes Dieterich To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 20:49:39 -0000 Dear all, I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Unfortunately, I cannot tell what is the root cause of the problems as I first got bitten by the pcre update and also did the world update to the clang3.2 import. Needless to say that everything worked prior and the configuration (no xorg.conf here) did not change. uname -a: FreeBSD XXXXX 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXXXX:/usr/obj/usr/src/sys/GENERIC amd64. Xorg.0.log: [ 88.021] X.Org X Server 1.10.6 Release Date: 2012-02-10 [ 88.021] X Protocol Version 11, Revision 0 [ 88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 [ 88.021] Current Operating System: FreeBSD XXXXXXXXX 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXXXXXX:/usr/obj/usr/src/sys/GENERIC amd64 [ 88.021] Build Date: 13 December 2012 06:30:07AM [ 88.021] [ 88.021] Current version of pixman: 0.24.2 [ 88.021] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 88.021] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 88.022] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 13 15:01:42 2012 [ 88.024] (II) Loader magic: 0x7c1930 [ 88.024] (II) Module ABI versions: [ 88.024] X.Org ANSI C Emulation: 0.4 [ 88.024] X.Org Video Driver: 10.0 [ 88.024] X.Org XInput driver : 12.2 [ 88.024] X.Org Server Extension : 5.0 [ 88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x00005000/64, BIOS @ 0x????????/65536 [ 88.025] (==) Using default built-in configuration (30 lines) [ 88.025] (==) --- Start of built-in configuration --- [ 88.025] Section "Device" [ 88.025] Identifier "Builtin Default intel Device 0" [ 88.025] Driver "intel" [ 88.025] EndSection [ 88.025] Section "Screen" [ 88.025] Identifier "Builtin Default intel Screen 0" [ 88.025] Device "Builtin Default intel Device 0" [ 88.025] EndSection [ 88.025] Section "Device" [ 88.025] Identifier "Builtin Default vesa Device 0" [ 88.025] Driver "vesa" [ 88.025] EndSection [ 88.025] Section "Screen" [ 88.025] Identifier "Builtin Default vesa Screen 0" [ 88.025] Device "Builtin Default vesa Device 0" [ 88.025] EndSection [ 88.025] Section "Device" [ 88.025] Identifier "Builtin Default fbdev Device 0" [ 88.025] Driver "fbdev" [ 88.025] EndSection [ 88.025] Section "Screen" [ 88.025] Identifier "Builtin Default fbdev Screen 0" [ 88.025] Device "Builtin Default fbdev Device 0" [ 88.026] EndSection [ 88.026] Section "ServerLayout" [ 88.026] Identifier "Builtin Default Layout" [ 88.026] Screen "Builtin Default intel Screen 0" [ 88.026] Screen "Builtin Default vesa Screen 0" [ 88.026] Screen "Builtin Default fbdev Screen 0" [ 88.026] EndSection [ 88.026] (==) --- End of built-in configuration --- [ 88.026] (==) ServerLayout "Builtin Default Layout" [ 88.026] (**) |-->Screen "Builtin Default intel Screen 0" (0) [ 88.026] (**) | |-->Monitor "" [ 88.026] (**) | |-->Device "Builtin Default intel Device 0" [ 88.026] (==) No monitor specified for screen "Builtin Default intel Screen 0". Using a default monitor configuration. [ 88.026] (**) |-->Screen "Builtin Default vesa Screen 0" (1) [ 88.026] (**) | |-->Monitor "" [ 88.026] (**) | |-->Device "Builtin Default vesa Device 0" [ 88.026] (==) No monitor specified for screen "Builtin Default vesa Screen 0". Using a default monitor configuration. [ 88.026] (**) |-->Screen "Builtin Default fbdev Screen 0" (2) [ 88.027] (**) | |-->Monitor "" [ 88.027] (**) | |-->Device "Builtin Default fbdev Device 0" [ 88.027] (==) No monitor specified for screen "Builtin Default fbdev Screen 0". Using a default monitor configuration. [ 88.027] (==) Automatically adding devices [ 88.027] (==) Automatically enabling devices [ 88.027] (WW) The directory "/usr/local/lib/X11/fonts/misc/" does not exist. [ 88.027] Entry deleted from font path. [ 88.028] (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. [ 88.029] Entry deleted from font path. [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/100dpi/" does not exist. [ 88.029] Entry deleted from font path. [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/75dpi/" does not exist. [ 88.029] Entry deleted from font path. [ 88.029] (==) FontPath set to: /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF/ [ 88.029] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 88.029] (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AutoAddDevices. [ 88.029] (II) LoadModule: "extmod" [ 88.032] (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so [ 88.033] (II) Module extmod: vendor="X.Org Foundation" [ 88.033] compiled for 1.10.6, module version = 1.0.0 [ 88.033] Module class: X.Org Server Extension [ 88.033] ABI class: X.Org Server Extension, version 5.0 [ 88.033] (II) Loading extension MIT-SCREEN-SAVER [ 88.033] (II) Loading extension XFree86-VidModeExtension [ 88.033] (II) Loading extension XFree86-DGA [ 88.033] (II) Loading extension DPMS [ 88.034] (II) Loading extension XVideo [ 88.034] (II) Loading extension XVideo-MotionCompensation [ 88.034] (II) Loading extension X-Resource [ 88.034] (II) LoadModule: "dbe" [ 88.034] (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so [ 88.035] (II) Module dbe: vendor="X.Org Foundation" [ 88.035] compiled for 1.10.6, module version = 1.0.0 [ 88.035] Module class: X.Org Server Extension [ 88.035] ABI class: X.Org Server Extension, version 5.0 [ 88.035] (II) Loading extension DOUBLE-BUFFER [ 88.035] (II) LoadModule: "glx" [ 88.035] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 88.040] (II) Module glx: vendor="X.Org Foundation" [ 88.040] compiled for 1.10.6, module version = 1.0.0 [ 88.040] ABI class: X.Org Server Extension, version 5.0 [ 88.041] (==) AIGLX disabled [ 88.041] (II) Loading extension GLX [ 88.041] (II) LoadModule: "record" [ 88.042] (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so [ 88.043] (II) Module record: vendor="X.Org Foundation" [ 88.043] compiled for 1.10.6, module version = 1.13.0 [ 88.043] Module class: X.Org Server Extension [ 88.043] ABI class: X.Org Server Extension, version 5.0 [ 88.043] (II) Loading extension RECORD [ 88.043] (II) LoadModule: "dri" [ 88.043] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so [ 88.045] (II) Module dri: vendor="X.Org Foundation" [ 88.045] compiled for 1.10.6, module version = 1.0.0 [ 88.045] ABI class: X.Org Server Extension, version 5.0 [ 88.045] (II) Loading extension XFree86-DRI [ 88.046] (II) LoadModule: "dri2" [ 88.046] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so [ 88.047] (II) Module dri2: vendor="X.Org Foundation" [ 88.047] compiled for 1.10.6, module version = 1.2.0 [ 88.047] ABI class: X.Org Server Extension, version 5.0 [ 88.047] (II) Loading extension DRI2 [ 88.047] (II) LoadModule: "intel" [ 88.047] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so [ 88.053] (II) Module intel: vendor="X.Org Foundation" [ 88.053] compiled for 1.10.6, module version = 2.17.0 [ 88.053] Module class: X.Org Video Driver [ 88.053] ABI class: X.Org Video Driver, version 10.0 [ 88.053] (II) LoadModule: "vesa" [ 88.053] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so [ 88.054] (II) Module vesa: vendor="X.Org Foundation" [ 88.054] compiled for 1.10.6, module version = 2.3.0 [ 88.054] Module class: X.Org Video Driver [ 88.054] ABI class: X.Org Video Driver, version 10.0 [ 88.054] (II) LoadModule: "fbdev" [ 88.057] (WW) Warning, couldn't open module fbdev [ 88.057] (II) UnloadModule: "fbdev" [ 88.057] (II) Unloading fbdev [ 88.057] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 88.057] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server [ 88.060] (II) VESA: driver for VESA chipsets: vesa [ 88.060] (--) Using syscons driver with X support (version 2.0) [ 88.060] (--) using VT number 9 [ 88.062] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so [ 88.062] (WW) Falling back to old probe method for vesa [ 88.062] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 88.062] drmOpenDevice: node name is /dev/dri/card0 [ 88.062] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 88.062] drmOpenDevice: open result is -1, (No such file or directory) [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 88.062] drmOpenDevice: open result is -1, (No such file or directory) [ 88.062] drmOpenDevice: Open failed [ 89.135] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 89.135] drmOpenDevice: node name is /dev/dri/card0 [ 89.135] drmOpenDevice: open result is 8, (OK) [ 89.135] drmOpenByBusid: drmOpenMinor returns 8 [ 89.135] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 89.135] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 [ 89.135] (II) intel(0): Creating default Display subsection in Screen section "Builtin Default intel Screen 0" for depth/fbbpp 24/32 [ 89.135] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 89.135] (==) intel(0): RGB weight 888 [ 89.135] (==) intel(0): Default visual is TrueColor [ 89.135] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) [ 89.135] (--) intel(0): Chipset: "Ivybridge Mobile (GT2)" [ 89.135] (**) intel(0): Relaxed fencing enabled [ 89.135] (**) intel(0): Wait on SwapBuffers? enabled [ 89.135] (**) intel(0): Triple buffering? enabled [ 89.135] (**) intel(0): Framebuffer tiled [ 89.135] (**) intel(0): Pixmaps tiled [ 89.135] (**) intel(0): 3D buffers tiled [ 89.135] (**) intel(0): SwapBuffers wait enabled [ 89.136] (==) intel(0): video overlay key set to 0x101fe [ 89.136] (II) intel(0): Output LVDS1 has no monitor section [ 89.136] (II) intel(0): Output VGA1 has no monitor section [ 89.350] (II) intel(0): Output HDMI1 has no monitor section [ 89.368] (II) intel(0): Output DP1 has no monitor section [ 89.378] (II) intel(0): Output HDMI2 has no monitor section [ 89.387] (II) intel(0): Output HDMI3 has no monitor section [ 89.405] (II) intel(0): Output DP2 has no monitor section [ 89.423] (II) intel(0): Output DP3 has no monitor section [ 89.423] (II) intel(0): EDID for output LVDS1 [ 89.423] (II) intel(0): Manufacturer: SEC Model: 324c Serial#: 0 [ 89.423] (II) intel(0): Year: 2010 Week: 0 [ 89.423] (II) intel(0): EDID Version: 1.3 [ 89.423] (II) intel(0): Digital Display Input [ 89.423] (II) intel(0): Max Image Size [cm]: horiz.: 31 vert.: 17 [ 89.423] (II) intel(0): Gamma: 2.20 [ 89.424] (II) intel(0): DPMS capabilities: StandBy Suspend Off [ 89.424] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 89.424] (II) intel(0): First detailed timing is preferred mode [ 89.424] (II) intel(0): redX: 0.566 redY: 0.337 greenX: 0.351 greenY: 0.560 [ 89.424] (II) intel(0): blueX: 0.150 blueY: 0.094 whiteX: 0.313 whiteY: 0.329 [ 89.424] (II) intel(0): Manufacturer's mask: 0 [ 89.424] (II) intel(0): Supported detailed timing: [ 89.424] (II) intel(0): clock: 98.2 MHz Image Size: 310 x 174 mm [ 89.424] (II) intel(0): h_active: 1600 h_sync: 1648 h_sync_end 1680 h_blank_end 1760 h_border: 0 [ 89.424] (II) intel(0): v_active: 900 v_sync: 902 v_sync_end 907 v_blanking: 930 v_border: 0 [ 89.424] (II) intel(0): Unknown vendor-specific block f [ 89.424] (II) intel(0): SAMSUNG [ 89.424] (II) intel(0): LTN140KT03401 [ 89.424] (II) intel(0): EDID (in hex): [ 89.424] (II) intel(0): 00ffffffffffff004ca34c3200000000 [ 89.424] (II) intel(0): 00140103801f1178ea1d859156598f26 [ 89.424] (II) intel(0): 18505400000001010101010101010101 [ 89.424] (II) intel(0): 0101010101015d2640a060841e303020 [ 89.424] (II) intel(0): 250036ae100000190000000f00000000 [ 89.425] (II) intel(0): 000000000032c8043200000000fe0053 [ 89.425] (II) intel(0): 414d53554e470a204ca34b54000000fe [ 89.425] (II) intel(0): 004c544e3134304b54303334303100ca [ 89.425] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 89.425] (II) intel(0): Printing DDC gathered Modelines: [ 89.425] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 89.425] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported) [ 89.425] (II) intel(0): Not using default mode "1024x768" (doublescan mode not supported) [ 89.425] (II) intel(0): Printing probed modes for output LVDS1 [ 89.425] (II) intel(0): Modeline "1600x900"x60.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 89.425] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) [ 89.426] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) [ 89.426] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) [ 89.426] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) [ 89.426] (II) intel(0): EDID for output VGA1 [ 89.632] (II) intel(0): EDID for output HDMI1 [ 89.650] (II) intel(0): EDID for output DP1 [ 89.660] (II) intel(0): EDID for output HDMI2 [ 89.669] (II) intel(0): EDID for output HDMI3 [ 89.687] (II) intel(0): EDID for output DP2 [ 89.705] (II) intel(0): EDID for output DP3 [ 89.705] (II) intel(0): Output LVDS1 connected [ 89.705] (II) intel(0): Output VGA1 disconnected [ 89.705] (II) intel(0): Output HDMI1 disconnected [ 89.705] (II) intel(0): Output DP1 disconnected [ 89.705] (II) intel(0): Output HDMI2 disconnected [ 89.705] (II) intel(0): Output HDMI3 disconnected [ 89.705] (II) intel(0): Output DP2 disconnected [ 89.705] (II) intel(0): Output DP3 disconnected [ 89.705] (II) intel(0): Using exact sizes for initial modes [ 89.705] (II) intel(0): Output LVDS1 using initial mode 1600x900 [ 89.706] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 89.706] (II) intel(0): Kernel page flipping support detected, enabling [ 89.706] (**) intel(0): Display dimensions: (310, 170) mm [ 89.706] (**) intel(0): DPI set to (131, 134) [ 89.706] (II) Loading sub module "fb" [ 89.706] (II) LoadModule: "fb" [ 89.707] (II) Loading /usr/local/lib/xorg/modules/libfb.so [ 89.709] (II) Module fb: vendor="X.Org Foundation" [ 89.709] compiled for 1.10.6, module version = 1.0.0 [ 89.709] ABI class: X.Org ANSI C Emulation, version 0.4 [ 89.709] (II) Loading sub module "dri2" [ 89.709] (II) LoadModule: "dri2" [ 89.709] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so [ 89.710] (II) Module dri2: vendor="X.Org Foundation" [ 89.710] compiled for 1.10.6, module version = 1.2.0 [ 89.710] ABI class: X.Org Server Extension, version 5.0 [ 89.710] (II) UnloadModule: "vesa" [ 89.710] (II) Unloading vesa [ 89.710] (==) Depth 24 pixmap format is 32 bpp [ 89.710] (II) intel(0): [DRI2] Setup complete [ 89.710] (II) intel(0): [DRI2] DRI driver: i965 [ 89.710] (II) intel(0): Allocated new frame buffer 1600x900 stride 6656, tiled [ 89.716] (II) UXA(0): Driver registered support for the following operations: [ 89.716] (II) solid [ 89.716] (II) copy [ 89.716] (II) composite (RENDER acceleration) [ 89.716] (II) put_image [ 89.716] (II) get_image [ 89.716] (==) intel(0): Backing store disabled [ 89.716] (==) intel(0): Silken mouse enabled [ 89.716] (II) intel(0): Initializing HW Cursor [ 89.873] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 89.873] (==) intel(0): DPMS enabled [ 89.873] (==) intel(0): Intel XvMC decoder enabled [ 89.873] (II) intel(0): Set up textured video [ 89.874] (II) intel(0): [XvMC] xvmc_vld driver initialized. [ 89.874] (II) intel(0): direct rendering: DRI2 Enabled [ 89.874] (--) RandR disabled [ 89.874] (II) Initializing built-in extension Generic Event Extension [ 89.874] (II) Initializing built-in extension SHAPE [ 89.874] (II) Initializing built-in extension MIT-SHM [ 89.874] (II) Initializing built-in extension XInputExtension [ 89.874] (II) Initializing built-in extension XTEST [ 89.874] (II) Initializing built-in extension BIG-REQUESTS [ 89.874] (II) Initializing built-in extension SYNC [ 89.874] (II) Initializing built-in extension XKEYBOARD [ 89.874] (II) Initializing built-in extension XC-MISC [ 89.874] (II) Initializing built-in extension XINERAMA [ 89.874] (II) Initializing built-in extension XFIXES [ 89.874] (II) Initializing built-in extension RENDER [ 89.874] (II) Initializing built-in extension RANDR [ 89.874] (II) Initializing built-in extension COMPOSITE [ 89.874] (II) Initializing built-in extension DAMAGE [ 89.912] (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so [ 89.912] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 89.913] (II) intel(0): Setting screen physical size to 423 x 238 [ 92.986] (II) config/hal: Adding input device AT Keyboard [ 92.987] (II) LoadModule: "kbd" [ 92.987] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 92.988] (II) Module kbd: vendor="X.Org Foundation" [ 92.989] compiled for 1.10.6, module version = 1.6.1 [ 92.989] Module class: X.Org XInput Driver [ 92.989] ABI class: X.Org XInput driver, version 12.2 [ 92.989] (II) Using input driver 'kbd' for 'AT Keyboard' [ 92.989] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 92.989] (**) AT Keyboard: always reports core events [ 92.989] (**) AT Keyboard: always reports core events [ 92.989] (**) Option "Protocol" "standard" [ 92.989] (**) Option "XkbRules" "base" [ 92.989] (**) Option "XkbModel" "pc105" [ 92.989] (**) Option "XkbLayout" "us" [ 92.989] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/atkbd_0" [ 92.989] (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) [ 95.110] (II) config/hal: Adding input device PS/2 Mouse [ 95.110] (II) LoadModule: "mouse" [ 95.111] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 95.112] (II) Module mouse: vendor="X.Org Foundation" [ 95.112] compiled for 1.10.6, module version = 1.7.1 [ 95.112] Module class: X.Org XInput Driver [ 95.112] ABI class: X.Org XInput driver, version 12.2 [ 95.112] (II) Using input driver 'mouse' for 'PS/2 Mouse' [ 95.112] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 95.112] (**) PS/2 Mouse: always reports core events [ 95.112] (**) Option "Device" "/dev/psm0" [ 95.112] (==) PS/2 Mouse: Protocol: "Auto" [ 95.112] (**) PS/2 Mouse: always reports core events [ 95.165] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 [ 95.165] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 [ 95.165] (**) PS/2 Mouse: Buttons: 9 [ 95.165] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/psm_0" [ 95.165] (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE) [ 95.165] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 [ 95.165] (**) PS/2 Mouse: (accel) acceleration profile 0 [ 95.165] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 [ 95.165] (**) PS/2 Mouse: (accel) acceleration threshold: 4 [ 95.183] (II) PS/2 Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 [ 95.183] (II) PS/2 Mouse: SetupAuto: protocol is PS/2 [ 95.340] (II) PS/2 Mouse: ps2EnableDataReporting: succeeded [ 96.475] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 96.475] (II) intel(0): Printing DDC gathered Modelines: [ 96.475] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 96.755] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 96.755] (II) intel(0): Printing DDC gathered Modelines: [ 96.755] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 97.036] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 97.036] (II) intel(0): Printing DDC gathered Modelines: [ 97.036] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 97.315] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 97.315] (II) intel(0): Printing DDC gathered Modelines: [ 97.315] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 107.345] (II) intel(0): EDID vendor "SEC", prod id 12876 [ 107.345] (II) intel(0): Printing DDC gathered Modelines: [ 107.345] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) [ 108.696] Segmentation fault at address 0x3fffffffed [ 108.696] Fatal server error: [ 108.697] Caught signal 11 (Segmentation fault). Server aborting [ 108.697] [ 108.697] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 108.697] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 108.697] [ 108.698] (II) UnloadModule: "kbd" [ 108.698] (II) Unloading kbd [ 108.733] (II) UnloadModule: "mouse" [ 108.733] (II) Unloading mouse [ 108.733] (WW) intel(0): drmDropMaster failed: Unknown error: -22 Perhaps someone got an idea? Thanks a lot Johannes From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 20:52:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DDD371C for ; Thu, 13 Dec 2012 20:52:19 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id BF4FD8FC0C for ; Thu, 13 Dec 2012 20:52:18 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 137E0E604A; Thu, 13 Dec 2012 15:52:11 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: new xorg segfault 11 with KMS Date: Thu, 13 Dec 2012 22:51:47 +0200 Message-ID: <2279995.En67FjFeZ3@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Johannes Dieterich X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 20:52:19 -0000 I have a similar problem when running firefox On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: > Dear all, > > I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and > WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly > causes the segfault (log attached), gnome survives a bit longer but > starting any bigger application (e.g. firefox) causes it to crash with the > same log. > > I have a Xorg.core file, but since it is without debug symbols the > backtrace makes little sense to me. > > Unfortunately, I cannot tell what is the root cause of the problems as I > first got bitten by the pcre update and also did the world update to the > clang3.2 import. Needless to say that everything worked prior and the > configuration (no xorg.conf here) did not change. > > uname -a: > FreeBSD XXXXX 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 > 09:46:06 EST 2012 root@XXXXX:/usr/obj/usr/src/sys/GENERIC amd64. > > Xorg.0.log: > [ 88.021] > X.Org X Server 1.10.6 > Release Date: 2012-02-10 > [ 88.021] X Protocol Version 11, Revision 0 > [ 88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 > [ 88.021] Current Operating System: FreeBSD XXXXXXXXX 10.0-CURRENT > FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 > root@XXXXXXX:/usr/obj/usr/src/sys/GENERIC amd64 > [ 88.021] Build Date: 13 December 2012 06:30:07AM > [ 88.021] > [ 88.021] Current version of pixman: 0.24.2 > [ 88.021] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 88.021] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 88.022] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 13 > 15:01:42 2012 > [ 88.024] (II) Loader magic: 0x7c1930 > [ 88.024] (II) Module ABI versions: > [ 88.024] X.Org ANSI C Emulation: 0.4 > [ 88.024] X.Org Video Driver: 10.0 > [ 88.024] X.Org XInput driver : 12.2 > [ 88.024] X.Org Server Extension : 5.0 > [ 88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ > 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x00005000/64, BIOS @ > 0x????????/65536 > [ 88.025] (==) Using default built-in configuration (30 lines) > [ 88.025] (==) --- Start of built-in configuration --- > [ 88.025] Section "Device" > [ 88.025] Identifier "Builtin Default intel Device 0" > [ 88.025] Driver "intel" > [ 88.025] EndSection > [ 88.025] Section "Screen" > [ 88.025] Identifier "Builtin Default intel Screen 0" > [ 88.025] Device "Builtin Default intel Device 0" > [ 88.025] EndSection > [ 88.025] Section "Device" > [ 88.025] Identifier "Builtin Default vesa Device 0" > [ 88.025] Driver "vesa" > [ 88.025] EndSection > [ 88.025] Section "Screen" > [ 88.025] Identifier "Builtin Default vesa Screen 0" > [ 88.025] Device "Builtin Default vesa Device 0" > [ 88.025] EndSection > [ 88.025] Section "Device" > [ 88.025] Identifier "Builtin Default fbdev Device 0" > [ 88.025] Driver "fbdev" > [ 88.025] EndSection > [ 88.025] Section "Screen" > [ 88.025] Identifier "Builtin Default fbdev Screen 0" > [ 88.025] Device "Builtin Default fbdev Device 0" > [ 88.026] EndSection > [ 88.026] Section "ServerLayout" > [ 88.026] Identifier "Builtin Default Layout" > [ 88.026] Screen "Builtin Default intel Screen 0" > [ 88.026] Screen "Builtin Default vesa Screen 0" > [ 88.026] Screen "Builtin Default fbdev Screen 0" > [ 88.026] EndSection > [ 88.026] (==) --- End of built-in configuration --- > [ 88.026] (==) ServerLayout "Builtin Default Layout" > [ 88.026] (**) |-->Screen "Builtin Default intel Screen 0" (0) > [ 88.026] (**) | |-->Monitor "" > [ 88.026] (**) | |-->Device "Builtin Default intel Device 0" > [ 88.026] (==) No monitor specified for screen "Builtin Default intel > Screen 0". > Using a default monitor configuration. > [ 88.026] (**) |-->Screen "Builtin Default vesa Screen 0" (1) > [ 88.026] (**) | |-->Monitor "" > [ 88.026] (**) | |-->Device "Builtin Default vesa Device 0" > [ 88.026] (==) No monitor specified for screen "Builtin Default vesa > Screen 0". > Using a default monitor configuration. > [ 88.026] (**) |-->Screen "Builtin Default fbdev Screen 0" (2) > [ 88.027] (**) | |-->Monitor "" > [ 88.027] (**) | |-->Device "Builtin Default fbdev Device 0" > [ 88.027] (==) No monitor specified for screen "Builtin Default fbdev > Screen 0". > Using a default monitor configuration. > [ 88.027] (==) Automatically adding devices > [ 88.027] (==) Automatically enabling devices > [ 88.027] (WW) The directory "/usr/local/lib/X11/fonts/misc/" does not > exist. > [ 88.027] Entry deleted from font path. > [ 88.028] (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not > exist. > [ 88.029] Entry deleted from font path. > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/100dpi/" does not > exist. > [ 88.029] Entry deleted from font path. > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/75dpi/" does not > exist. > [ 88.029] Entry deleted from font path. > [ 88.029] (==) FontPath set to: > /usr/local/lib/X11/fonts/TTF/, > /usr/local/lib/X11/fonts/OTF/ > [ 88.029] (==) ModulePath set to "/usr/local/lib/xorg/modules" > [ 88.029] (II) The server relies on HAL to provide the list of input > devices. > If no devices become available, reconfigure HAL or disable > AutoAddDevices. > [ 88.029] (II) LoadModule: "extmod" > [ 88.032] (II) Loading > /usr/local/lib/xorg/modules/extensions/libextmod.so > [ 88.033] (II) Module extmod: vendor="X.Org Foundation" > [ 88.033] compiled for 1.10.6, module version = 1.0.0 > [ 88.033] Module class: X.Org Server Extension > [ 88.033] ABI class: X.Org Server Extension, version 5.0 > [ 88.033] (II) Loading extension MIT-SCREEN-SAVER > [ 88.033] (II) Loading extension XFree86-VidModeExtension > [ 88.033] (II) Loading extension XFree86-DGA > [ 88.033] (II) Loading extension DPMS > [ 88.034] (II) Loading extension XVideo > [ 88.034] (II) Loading extension XVideo-MotionCompensation > [ 88.034] (II) Loading extension X-Resource > [ 88.034] (II) LoadModule: "dbe" > [ 88.034] (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so > [ 88.035] (II) Module dbe: vendor="X.Org Foundation" > [ 88.035] compiled for 1.10.6, module version = 1.0.0 > [ 88.035] Module class: X.Org Server Extension > [ 88.035] ABI class: X.Org Server Extension, version 5.0 > [ 88.035] (II) Loading extension DOUBLE-BUFFER > [ 88.035] (II) LoadModule: "glx" > [ 88.035] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so > [ 88.040] (II) Module glx: vendor="X.Org Foundation" > [ 88.040] compiled for 1.10.6, module version = 1.0.0 > [ 88.040] ABI class: X.Org Server Extension, version 5.0 > [ 88.041] (==) AIGLX disabled > [ 88.041] (II) Loading extension GLX > [ 88.041] (II) LoadModule: "record" > [ 88.042] (II) Loading > /usr/local/lib/xorg/modules/extensions/librecord.so > [ 88.043] (II) Module record: vendor="X.Org Foundation" > [ 88.043] compiled for 1.10.6, module version = 1.13.0 > [ 88.043] Module class: X.Org Server Extension > [ 88.043] ABI class: X.Org Server Extension, version 5.0 > [ 88.043] (II) Loading extension RECORD > [ 88.043] (II) LoadModule: "dri" > [ 88.043] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so > [ 88.045] (II) Module dri: vendor="X.Org Foundation" > [ 88.045] compiled for 1.10.6, module version = 1.0.0 > [ 88.045] ABI class: X.Org Server Extension, version 5.0 > [ 88.045] (II) Loading extension XFree86-DRI > [ 88.046] (II) LoadModule: "dri2" > [ 88.046] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so > [ 88.047] (II) Module dri2: vendor="X.Org Foundation" > [ 88.047] compiled for 1.10.6, module version = 1.2.0 > [ 88.047] ABI class: X.Org Server Extension, version 5.0 > [ 88.047] (II) Loading extension DRI2 > [ 88.047] (II) LoadModule: "intel" > [ 88.047] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so > [ 88.053] (II) Module intel: vendor="X.Org Foundation" > [ 88.053] compiled for 1.10.6, module version = 2.17.0 > [ 88.053] Module class: X.Org Video Driver > [ 88.053] ABI class: X.Org Video Driver, version 10.0 > [ 88.053] (II) LoadModule: "vesa" > [ 88.053] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so > [ 88.054] (II) Module vesa: vendor="X.Org Foundation" > [ 88.054] compiled for 1.10.6, module version = 2.3.0 > [ 88.054] Module class: X.Org Video Driver > [ 88.054] ABI class: X.Org Video Driver, version 10.0 > [ 88.054] (II) LoadModule: "fbdev" > [ 88.057] (WW) Warning, couldn't open module fbdev > [ 88.057] (II) UnloadModule: "fbdev" > [ 88.057] (II) Unloading fbdev > [ 88.057] (EE) Failed to load module "fbdev" (module does not exist, 0) > [ 88.057] (II) intel: Driver for Intel Integrated Graphics Chipsets: > i810, > i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, > E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, > 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, > 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, > Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), > Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), > Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), > Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), > Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server > [ 88.060] (II) VESA: driver for VESA chipsets: vesa > [ 88.060] (--) Using syscons driver with X support (version 2.0) > [ 88.060] (--) using VT number 9 > > [ 88.062] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so > [ 88.062] (WW) Falling back to old probe method for vesa > [ 88.062] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card > support > [ 88.062] drmOpenDevice: node name is /dev/dri/card0 > [ 88.062] Failed to change owner or group for file /dev/dri! 2: No such > file or directory > [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: No > such file or directory > [ 88.062] drmOpenDevice: open result is -1, (No such file or directory) > [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: No > such file or directory > [ 88.062] drmOpenDevice: open result is -1, (No such file or directory) > [ 88.062] drmOpenDevice: Open failed > [ 89.135] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > [ 89.135] drmOpenDevice: node name is /dev/dri/card0 > [ 89.135] drmOpenDevice: open result is 8, (OK) > [ 89.135] drmOpenByBusid: drmOpenMinor returns 8 > [ 89.135] drmOpenByBusid: Interface 1.4 failed, trying 1.1 > [ 89.135] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 > [ 89.135] (II) intel(0): Creating default Display subsection in Screen > section > "Builtin Default intel Screen 0" for depth/fbbpp 24/32 > [ 89.135] (==) intel(0): Depth 24, (--) framebuffer bpp 32 > [ 89.135] (==) intel(0): RGB weight 888 > [ 89.135] (==) intel(0): Default visual is TrueColor > [ 89.135] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge > Mobile (GT2) > [ 89.135] (--) intel(0): Chipset: "Ivybridge Mobile (GT2)" > [ 89.135] (**) intel(0): Relaxed fencing enabled > [ 89.135] (**) intel(0): Wait on SwapBuffers? enabled > [ 89.135] (**) intel(0): Triple buffering? enabled > [ 89.135] (**) intel(0): Framebuffer tiled > [ 89.135] (**) intel(0): Pixmaps tiled > [ 89.135] (**) intel(0): 3D buffers tiled > [ 89.135] (**) intel(0): SwapBuffers wait enabled > [ 89.136] (==) intel(0): video overlay key set to 0x101fe > [ 89.136] (II) intel(0): Output LVDS1 has no monitor section > [ 89.136] (II) intel(0): Output VGA1 has no monitor section > [ 89.350] (II) intel(0): Output HDMI1 has no monitor section > [ 89.368] (II) intel(0): Output DP1 has no monitor section > [ 89.378] (II) intel(0): Output HDMI2 has no monitor section > [ 89.387] (II) intel(0): Output HDMI3 has no monitor section > [ 89.405] (II) intel(0): Output DP2 has no monitor section > [ 89.423] (II) intel(0): Output DP3 has no monitor section > [ 89.423] (II) intel(0): EDID for output LVDS1 > [ 89.423] (II) intel(0): Manufacturer: SEC Model: 324c Serial#: 0 > [ 89.423] (II) intel(0): Year: 2010 Week: 0 > [ 89.423] (II) intel(0): EDID Version: 1.3 > [ 89.423] (II) intel(0): Digital Display Input > [ 89.423] (II) intel(0): Max Image Size [cm]: horiz.: 31 vert.: 17 > [ 89.423] (II) intel(0): Gamma: 2.20 > [ 89.424] (II) intel(0): DPMS capabilities: StandBy Suspend Off > [ 89.424] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb > 4:4:4 > [ 89.424] (II) intel(0): First detailed timing is preferred mode > [ 89.424] (II) intel(0): redX: 0.566 redY: 0.337 greenX: 0.351 greenY: > 0.560 > [ 89.424] (II) intel(0): blueX: 0.150 blueY: 0.094 whiteX: 0.313 > whiteY: 0.329 > [ 89.424] (II) intel(0): Manufacturer's mask: 0 > [ 89.424] (II) intel(0): Supported detailed timing: > [ 89.424] (II) intel(0): clock: 98.2 MHz Image Size: 310 x 174 mm > [ 89.424] (II) intel(0): h_active: 1600 h_sync: 1648 h_sync_end 1680 > h_blank_end 1760 h_border: 0 > [ 89.424] (II) intel(0): v_active: 900 v_sync: 902 v_sync_end 907 > v_blanking: 930 v_border: 0 > [ 89.424] (II) intel(0): Unknown vendor-specific block f > [ 89.424] (II) intel(0): SAMSUNG > [ 89.424] (II) intel(0): LTN140KT03401 > [ 89.424] (II) intel(0): EDID (in hex): > [ 89.424] (II) intel(0): 00ffffffffffff004ca34c3200000000 > [ 89.424] (II) intel(0): 00140103801f1178ea1d859156598f26 > [ 89.424] (II) intel(0): 18505400000001010101010101010101 > [ 89.424] (II) intel(0): 0101010101015d2640a060841e303020 > [ 89.424] (II) intel(0): 250036ae100000190000000f00000000 > [ 89.425] (II) intel(0): 000000000032c8043200000000fe0053 > [ 89.425] (II) intel(0): 414d53554e470a204ca34b54000000fe > [ 89.425] (II) intel(0): 004c544e3134304b54303334303100ca > [ 89.425] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 89.425] (II) intel(0): Printing DDC gathered Modelines: > [ 89.425] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 89.425] (II) intel(0): Not using default mode "320x240" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "512x384" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "640x480" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "640x512" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "800x600" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "896x672" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "928x696" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "960x720" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "700x525" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Not using default mode "1024x768" (doublescan > mode not supported) > [ 89.425] (II) intel(0): Printing probed modes for output LVDS1 > [ 89.425] (II) intel(0): Modeline "1600x900"x60.0 98.21 1600 1648 > 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 89.425] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 > 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) > [ 89.426] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 > 1056 600 601 605 628 +hsync +vsync (37.9 kHz) > [ 89.426] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 > 1024 600 601 603 625 +hsync +vsync (35.2 kHz) > [ 89.426] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 > 800 480 490 492 525 -hsync -vsync (31.5 kHz) > [ 89.426] (II) intel(0): EDID for output VGA1 > [ 89.632] (II) intel(0): EDID for output HDMI1 > [ 89.650] (II) intel(0): EDID for output DP1 > [ 89.660] (II) intel(0): EDID for output HDMI2 > [ 89.669] (II) intel(0): EDID for output HDMI3 > [ 89.687] (II) intel(0): EDID for output DP2 > [ 89.705] (II) intel(0): EDID for output DP3 > [ 89.705] (II) intel(0): Output LVDS1 connected > [ 89.705] (II) intel(0): Output VGA1 disconnected > [ 89.705] (II) intel(0): Output HDMI1 disconnected > [ 89.705] (II) intel(0): Output DP1 disconnected > [ 89.705] (II) intel(0): Output HDMI2 disconnected > [ 89.705] (II) intel(0): Output HDMI3 disconnected > [ 89.705] (II) intel(0): Output DP2 disconnected > [ 89.705] (II) intel(0): Output DP3 disconnected > [ 89.705] (II) intel(0): Using exact sizes for initial modes > [ 89.705] (II) intel(0): Output LVDS1 using initial mode 1600x900 > [ 89.706] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless > otherwise stated. > [ 89.706] (II) intel(0): Kernel page flipping support detected, enabling > [ 89.706] (**) intel(0): Display dimensions: (310, 170) mm > [ 89.706] (**) intel(0): DPI set to (131, 134) > [ 89.706] (II) Loading sub module "fb" > [ 89.706] (II) LoadModule: "fb" > [ 89.707] (II) Loading /usr/local/lib/xorg/modules/libfb.so > [ 89.709] (II) Module fb: vendor="X.Org Foundation" > [ 89.709] compiled for 1.10.6, module version = 1.0.0 > [ 89.709] ABI class: X.Org ANSI C Emulation, version 0.4 > [ 89.709] (II) Loading sub module "dri2" > [ 89.709] (II) LoadModule: "dri2" > [ 89.709] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so > [ 89.710] (II) Module dri2: vendor="X.Org Foundation" > [ 89.710] compiled for 1.10.6, module version = 1.2.0 > [ 89.710] ABI class: X.Org Server Extension, version 5.0 > [ 89.710] (II) UnloadModule: "vesa" > [ 89.710] (II) Unloading vesa > [ 89.710] (==) Depth 24 pixmap format is 32 bpp > [ 89.710] (II) intel(0): [DRI2] Setup complete > [ 89.710] (II) intel(0): [DRI2] DRI driver: i965 > [ 89.710] (II) intel(0): Allocated new frame buffer 1600x900 stride > 6656, tiled > [ 89.716] (II) UXA(0): Driver registered support for the following > operations: > [ 89.716] (II) solid > [ 89.716] (II) copy > [ 89.716] (II) composite (RENDER acceleration) > [ 89.716] (II) put_image > [ 89.716] (II) get_image > [ 89.716] (==) intel(0): Backing store disabled > [ 89.716] (==) intel(0): Silken mouse enabled > [ 89.716] (II) intel(0): Initializing HW Cursor > [ 89.873] (II) intel(0): RandR 1.2 enabled, ignore the following RandR > disabled message. > [ 89.873] (==) intel(0): DPMS enabled > [ 89.873] (==) intel(0): Intel XvMC decoder enabled > [ 89.873] (II) intel(0): Set up textured video > [ 89.874] (II) intel(0): [XvMC] xvmc_vld driver initialized. > [ 89.874] (II) intel(0): direct rendering: DRI2 Enabled > [ 89.874] (--) RandR disabled > [ 89.874] (II) Initializing built-in extension Generic Event Extension > [ 89.874] (II) Initializing built-in extension SHAPE > [ 89.874] (II) Initializing built-in extension MIT-SHM > [ 89.874] (II) Initializing built-in extension XInputExtension > [ 89.874] (II) Initializing built-in extension XTEST > [ 89.874] (II) Initializing built-in extension BIG-REQUESTS > [ 89.874] (II) Initializing built-in extension SYNC > [ 89.874] (II) Initializing built-in extension XKEYBOARD > [ 89.874] (II) Initializing built-in extension XC-MISC > [ 89.874] (II) Initializing built-in extension XINERAMA > [ 89.874] (II) Initializing built-in extension XFIXES > [ 89.874] (II) Initializing built-in extension RENDER > [ 89.874] (II) Initializing built-in extension RANDR > [ 89.874] (II) Initializing built-in extension COMPOSITE > [ 89.874] (II) Initializing built-in extension DAMAGE > [ 89.912] (II) AIGLX: Loaded and initialized > /usr/local/lib/dri/swrast_dri.so > [ 89.912] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > [ 89.913] (II) intel(0): Setting screen physical size to 423 x 238 > [ 92.986] (II) config/hal: Adding input device AT Keyboard > [ 92.987] (II) LoadModule: "kbd" > [ 92.987] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so > [ 92.988] (II) Module kbd: vendor="X.Org Foundation" > [ 92.989] compiled for 1.10.6, module version = 1.6.1 > [ 92.989] Module class: X.Org XInput Driver > [ 92.989] ABI class: X.Org XInput driver, version 12.2 > [ 92.989] (II) Using input driver 'kbd' for 'AT Keyboard' > [ 92.989] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so > [ 92.989] (**) AT Keyboard: always reports core events > [ 92.989] (**) AT Keyboard: always reports core events > [ 92.989] (**) Option "Protocol" "standard" > [ 92.989] (**) Option "XkbRules" "base" > [ 92.989] (**) Option "XkbModel" "pc105" > [ 92.989] (**) Option "XkbLayout" "us" > [ 92.989] (**) Option "config_info" > "hal:/org/freedesktop/Hal/devices/atkbd_0" > [ 92.989] (II) XINPUT: Adding extended input device "AT Keyboard" (type: > KEYBOARD) > [ 95.110] (II) config/hal: Adding input device PS/2 Mouse > [ 95.110] (II) LoadModule: "mouse" > [ 95.111] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > [ 95.112] (II) Module mouse: vendor="X.Org Foundation" > [ 95.112] compiled for 1.10.6, module version = 1.7.1 > [ 95.112] Module class: X.Org XInput Driver > [ 95.112] ABI class: X.Org XInput driver, version 12.2 > [ 95.112] (II) Using input driver 'mouse' for 'PS/2 Mouse' > [ 95.112] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > [ 95.112] (**) PS/2 Mouse: always reports core events > [ 95.112] (**) Option "Device" "/dev/psm0" > [ 95.112] (==) PS/2 Mouse: Protocol: "Auto" > [ 95.112] (**) PS/2 Mouse: always reports core events > [ 95.165] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 > [ 95.165] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 > [ 95.165] (**) PS/2 Mouse: Buttons: 9 > [ 95.165] (**) Option "config_info" > "hal:/org/freedesktop/Hal/devices/psm_0" > [ 95.165] (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: > MOUSE) > [ 95.165] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 > [ 95.165] (**) PS/2 Mouse: (accel) acceleration profile 0 > [ 95.165] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 > [ 95.165] (**) PS/2 Mouse: (accel) acceleration threshold: 4 > [ 95.183] (II) PS/2 Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 > [ 95.183] (II) PS/2 Mouse: SetupAuto: protocol is PS/2 > [ 95.340] (II) PS/2 Mouse: ps2EnableDataReporting: succeeded > [ 96.475] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 96.475] (II) intel(0): Printing DDC gathered Modelines: > [ 96.475] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 96.755] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 96.755] (II) intel(0): Printing DDC gathered Modelines: > [ 96.755] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 97.036] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 97.036] (II) intel(0): Printing DDC gathered Modelines: > [ 97.036] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 97.315] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 97.315] (II) intel(0): Printing DDC gathered Modelines: > [ 97.315] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 107.345] (II) intel(0): EDID vendor "SEC", prod id 12876 > [ 107.345] (II) intel(0): Printing DDC gathered Modelines: > [ 107.345] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 1680 > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > [ 108.696] Segmentation fault at address 0x3fffffffed > [ 108.696] > Fatal server error: > [ 108.697] Caught signal 11 (Segmentation fault). Server aborting > [ 108.697] > [ 108.697] > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 108.697] Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > [ 108.697] > [ 108.698] (II) UnloadModule: "kbd" > [ 108.698] (II) Unloading kbd > [ 108.733] (II) UnloadModule: "mouse" > [ 108.733] (II) Unloading mouse > [ 108.733] (WW) intel(0): drmDropMaster failed: Unknown error: -22 > > Perhaps someone got an idea? > > Thanks a lot > > Johannes > _______________________________________________ > 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" -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:01:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D37199A for ; Thu, 13 Dec 2012 21:01:42 +0000 (UTC) (envelope-from geo.liaskos@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 78A538FC08 for ; Thu, 13 Dec 2012 21:01:40 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so1157491wey.13 for ; Thu, 13 Dec 2012 13:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jxaOu5fuyeu43HpYPcIPVa0txyAOOa7/Ia971PU1jk0=; b=QbDm66nzXcTPZZ0HUVVdxrqHoogFW7WEr8CKVsnnfyefQXGjblRuw+nmgiJXfUvn0n TsKyfp6xh38n6xduQ0HIuQMDI5ocwkQ7aDQxQ7+QVnJjvU/i4Gv9gyiOTw+s5SfrBFHj hxt/Y/fAm97RqH/HMckjKAUS0BcBXEoyFmM/coVB8n+haSLTiZ2qEBYCR4WNVXkzuMDR /fufNgkqdowoSFNhT5tOy5sfGsoLfW1KvSVWsAokQxapUuFzC7X3X2Q8Ujjg6ATqr2rA S3IB9qI6/RdIFkIRVJZnmVVTmMo+wQdUGjtlGEFBigosZaH3EagNpAJcb0IyX7bs7dfw Twug== MIME-Version: 1.0 Received: by 10.194.80.135 with SMTP id r7mr223955wjx.58.1355432499275; Thu, 13 Dec 2012 13:01:39 -0800 (PST) Received: by 10.195.12.113 with HTTP; Thu, 13 Dec 2012 13:01:39 -0800 (PST) In-Reply-To: <2279995.En67FjFeZ3@home.alkar.net> References: <2279995.En67FjFeZ3@home.alkar.net> Date: Thu, 13 Dec 2012 23:01:39 +0200 Message-ID: Subject: Re: new xorg segfault 11 with KMS From: George Liaskos To: Artyom Mirgorodskiy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Johannes Dieterich , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:01:42 -0000 Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm2. On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy < artyom@ijminteractive.net> wrote: > I have a similar problem when running firefox > > On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: > > Dear all, > > > > I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and > > WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly > > causes the segfault (log attached), gnome survives a bit longer but > > starting any bigger application (e.g. firefox) causes it to crash with > the > > same log. > > > > I have a Xorg.core file, but since it is without debug symbols the > > backtrace makes little sense to me. > > > > Unfortunately, I cannot tell what is the root cause of the problems as I > > first got bitten by the pcre update and also did the world update to the > > clang3.2 import. Needless to say that everything worked prior and the > > configuration (no xorg.conf here) did not change. > > > > uname -a: > > FreeBSD XXXXX 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 > > 09:46:06 EST 2012 root@XXXXX:/usr/obj/usr/src/sys/GENERIC amd64. > > > > Xorg.0.log: > > [ 88.021] > > X.Org X Server 1.10.6 > > Release Date: 2012-02-10 > > [ 88.021] X Protocol Version 11, Revision 0 > > [ 88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 > > [ 88.021] Current Operating System: FreeBSD XXXXXXXXX 10.0-CURRENT > > FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 > > root@XXXXXXX:/usr/obj/usr/src/sys/GENERIC amd64 > > [ 88.021] Build Date: 13 December 2012 06:30:07AM > > [ 88.021] > > [ 88.021] Current version of pixman: 0.24.2 > > [ 88.021] Before reporting problems, check http://wiki.x.org > > to make sure that you have the latest version. > > [ 88.021] Markers: (--) probed, (**) from config file, (==) default > > setting, > > (++) from command line, (!!) notice, (II) informational, > > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > [ 88.022] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 13 > > 15:01:42 2012 > > [ 88.024] (II) Loader magic: 0x7c1930 > > [ 88.024] (II) Module ABI versions: > > [ 88.024] X.Org ANSI C Emulation: 0.4 > > [ 88.024] X.Org Video Driver: 10.0 > > [ 88.024] X.Org XInput driver : 12.2 > > [ 88.024] X.Org Server Extension : 5.0 > > [ 88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ > > 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x00005000/64, BIOS @ > > 0x????????/65536 > > [ 88.025] (==) Using default built-in configuration (30 lines) > > [ 88.025] (==) --- Start of built-in configuration --- > > [ 88.025] Section "Device" > > [ 88.025] Identifier "Builtin Default intel Device 0" > > [ 88.025] Driver "intel" > > [ 88.025] EndSection > > [ 88.025] Section "Screen" > > [ 88.025] Identifier "Builtin Default intel Screen 0" > > [ 88.025] Device "Builtin Default intel Device 0" > > [ 88.025] EndSection > > [ 88.025] Section "Device" > > [ 88.025] Identifier "Builtin Default vesa Device 0" > > [ 88.025] Driver "vesa" > > [ 88.025] EndSection > > [ 88.025] Section "Screen" > > [ 88.025] Identifier "Builtin Default vesa Screen 0" > > [ 88.025] Device "Builtin Default vesa Device 0" > > [ 88.025] EndSection > > [ 88.025] Section "Device" > > [ 88.025] Identifier "Builtin Default fbdev Device 0" > > [ 88.025] Driver "fbdev" > > [ 88.025] EndSection > > [ 88.025] Section "Screen" > > [ 88.025] Identifier "Builtin Default fbdev Screen 0" > > [ 88.025] Device "Builtin Default fbdev Device 0" > > [ 88.026] EndSection > > [ 88.026] Section "ServerLayout" > > [ 88.026] Identifier "Builtin Default Layout" > > [ 88.026] Screen "Builtin Default intel Screen 0" > > [ 88.026] Screen "Builtin Default vesa Screen 0" > > [ 88.026] Screen "Builtin Default fbdev Screen 0" > > [ 88.026] EndSection > > [ 88.026] (==) --- End of built-in configuration --- > > [ 88.026] (==) ServerLayout "Builtin Default Layout" > > [ 88.026] (**) |-->Screen "Builtin Default intel Screen 0" (0) > > [ 88.026] (**) | |-->Monitor "" > > [ 88.026] (**) | |-->Device "Builtin Default intel Device 0" > > [ 88.026] (==) No monitor specified for screen "Builtin Default intel > > Screen 0". > > Using a default monitor configuration. > > [ 88.026] (**) |-->Screen "Builtin Default vesa Screen 0" (1) > > [ 88.026] (**) | |-->Monitor "" > > [ 88.026] (**) | |-->Device "Builtin Default vesa Device 0" > > [ 88.026] (==) No monitor specified for screen "Builtin Default vesa > > Screen 0". > > Using a default monitor configuration. > > [ 88.026] (**) |-->Screen "Builtin Default fbdev Screen 0" (2) > > [ 88.027] (**) | |-->Monitor "" > > [ 88.027] (**) | |-->Device "Builtin Default fbdev Device 0" > > [ 88.027] (==) No monitor specified for screen "Builtin Default fbdev > > Screen 0". > > Using a default monitor configuration. > > [ 88.027] (==) Automatically adding devices > > [ 88.027] (==) Automatically enabling devices > > [ 88.027] (WW) The directory "/usr/local/lib/X11/fonts/misc/" does not > > exist. > > [ 88.027] Entry deleted from font path. > > [ 88.028] (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does > not > > exist. > > [ 88.029] Entry deleted from font path. > > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/100dpi/" does > not > > exist. > > [ 88.029] Entry deleted from font path. > > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/75dpi/" does > not > > exist. > > [ 88.029] Entry deleted from font path. > > [ 88.029] (==) FontPath set to: > > /usr/local/lib/X11/fonts/TTF/, > > /usr/local/lib/X11/fonts/OTF/ > > [ 88.029] (==) ModulePath set to "/usr/local/lib/xorg/modules" > > [ 88.029] (II) The server relies on HAL to provide the list of input > > devices. > > If no devices become available, reconfigure HAL or disable > > AutoAddDevices. > > [ 88.029] (II) LoadModule: "extmod" > > [ 88.032] (II) Loading > > /usr/local/lib/xorg/modules/extensions/libextmod.so > > [ 88.033] (II) Module extmod: vendor="X.Org Foundation" > > [ 88.033] compiled for 1.10.6, module version = 1.0.0 > > [ 88.033] Module class: X.Org Server Extension > > [ 88.033] ABI class: X.Org Server Extension, version 5.0 > > [ 88.033] (II) Loading extension MIT-SCREEN-SAVER > > [ 88.033] (II) Loading extension XFree86-VidModeExtension > > [ 88.033] (II) Loading extension XFree86-DGA > > [ 88.033] (II) Loading extension DPMS > > [ 88.034] (II) Loading extension XVideo > > [ 88.034] (II) Loading extension XVideo-MotionCompensation > > [ 88.034] (II) Loading extension X-Resource > > [ 88.034] (II) LoadModule: "dbe" > > [ 88.034] (II) Loading > /usr/local/lib/xorg/modules/extensions/libdbe.so > > [ 88.035] (II) Module dbe: vendor="X.Org Foundation" > > [ 88.035] compiled for 1.10.6, module version = 1.0.0 > > [ 88.035] Module class: X.Org Server Extension > > [ 88.035] ABI class: X.Org Server Extension, version 5.0 > > [ 88.035] (II) Loading extension DOUBLE-BUFFER > > [ 88.035] (II) LoadModule: "glx" > > [ 88.035] (II) Loading > /usr/local/lib/xorg/modules/extensions/libglx.so > > [ 88.040] (II) Module glx: vendor="X.Org Foundation" > > [ 88.040] compiled for 1.10.6, module version = 1.0.0 > > [ 88.040] ABI class: X.Org Server Extension, version 5.0 > > [ 88.041] (==) AIGLX disabled > > [ 88.041] (II) Loading extension GLX > > [ 88.041] (II) LoadModule: "record" > > [ 88.042] (II) Loading > > /usr/local/lib/xorg/modules/extensions/librecord.so > > [ 88.043] (II) Module record: vendor="X.Org Foundation" > > [ 88.043] compiled for 1.10.6, module version = 1.13.0 > > [ 88.043] Module class: X.Org Server Extension > > [ 88.043] ABI class: X.Org Server Extension, version 5.0 > > [ 88.043] (II) Loading extension RECORD > > [ 88.043] (II) LoadModule: "dri" > > [ 88.043] (II) Loading > /usr/local/lib/xorg/modules/extensions/libdri.so > > [ 88.045] (II) Module dri: vendor="X.Org Foundation" > > [ 88.045] compiled for 1.10.6, module version = 1.0.0 > > [ 88.045] ABI class: X.Org Server Extension, version 5.0 > > [ 88.045] (II) Loading extension XFree86-DRI > > [ 88.046] (II) LoadModule: "dri2" > > [ 88.046] (II) Loading > /usr/local/lib/xorg/modules/extensions/libdri2.so > > [ 88.047] (II) Module dri2: vendor="X.Org Foundation" > > [ 88.047] compiled for 1.10.6, module version = 1.2.0 > > [ 88.047] ABI class: X.Org Server Extension, version 5.0 > > [ 88.047] (II) Loading extension DRI2 > > [ 88.047] (II) LoadModule: "intel" > > [ 88.047] (II) Loading > /usr/local/lib/xorg/modules/drivers/intel_drv.so > > [ 88.053] (II) Module intel: vendor="X.Org Foundation" > > [ 88.053] compiled for 1.10.6, module version = 2.17.0 > > [ 88.053] Module class: X.Org Video Driver > > [ 88.053] ABI class: X.Org Video Driver, version 10.0 > > [ 88.053] (II) LoadModule: "vesa" > > [ 88.053] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so > > [ 88.054] (II) Module vesa: vendor="X.Org Foundation" > > [ 88.054] compiled for 1.10.6, module version = 2.3.0 > > [ 88.054] Module class: X.Org Video Driver > > [ 88.054] ABI class: X.Org Video Driver, version 10.0 > > [ 88.054] (II) LoadModule: "fbdev" > > [ 88.057] (WW) Warning, couldn't open module fbdev > > [ 88.057] (II) UnloadModule: "fbdev" > > [ 88.057] (II) Unloading fbdev > > [ 88.057] (EE) Failed to load module "fbdev" (module does not exist, > 0) > > [ 88.057] (II) intel: Driver for Intel Integrated Graphics Chipsets: > > i810, > > i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, > 915G, > > E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview > G, > > 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, > > 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, > > Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), > > Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), > > Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), > > Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile > (GT2), > > Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge > Server > > [ 88.060] (II) VESA: driver for VESA chipsets: vesa > > [ 88.060] (--) Using syscons driver with X support (version 2.0) > > [ 88.060] (--) using VT number 9 > > > > [ 88.062] (II) Loading > /usr/local/lib/xorg/modules/drivers/intel_drv.so > > [ 88.062] (WW) Falling back to old probe method for vesa > > [ 88.062] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card > > support > > [ 88.062] drmOpenDevice: node name is /dev/dri/card0 > > [ 88.062] Failed to change owner or group for file /dev/dri! 2: No > such > > file or directory > > [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: > No > > such file or directory > > [ 88.062] drmOpenDevice: open result is -1, (No such file or > directory) > > [ 88.062] Failed to change owner or group for file /dev/dri/card0! 2: > No > > such file or directory > > [ 88.062] drmOpenDevice: open result is -1, (No such file or > directory) > > [ 88.062] drmOpenDevice: Open failed > > [ 89.135] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > > [ 89.135] drmOpenDevice: node name is /dev/dri/card0 > > [ 89.135] drmOpenDevice: open result is 8, (OK) > > [ 89.135] drmOpenByBusid: drmOpenMinor returns 8 > > [ 89.135] drmOpenByBusid: Interface 1.4 failed, trying 1.1 > > [ 89.135] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 > > [ 89.135] (II) intel(0): Creating default Display subsection in Screen > > section > > "Builtin Default intel Screen 0" for depth/fbbpp 24/32 > > [ 89.135] (==) intel(0): Depth 24, (--) framebuffer bpp 32 > > [ 89.135] (==) intel(0): RGB weight 888 > > [ 89.135] (==) intel(0): Default visual is TrueColor > > [ 89.135] (II) intel(0): Integrated Graphics Chipset: Intel(R) > Ivybridge > > Mobile (GT2) > > [ 89.135] (--) intel(0): Chipset: "Ivybridge Mobile (GT2)" > > [ 89.135] (**) intel(0): Relaxed fencing enabled > > [ 89.135] (**) intel(0): Wait on SwapBuffers? enabled > > [ 89.135] (**) intel(0): Triple buffering? enabled > > [ 89.135] (**) intel(0): Framebuffer tiled > > [ 89.135] (**) intel(0): Pixmaps tiled > > [ 89.135] (**) intel(0): 3D buffers tiled > > [ 89.135] (**) intel(0): SwapBuffers wait enabled > > [ 89.136] (==) intel(0): video overlay key set to 0x101fe > > [ 89.136] (II) intel(0): Output LVDS1 has no monitor section > > [ 89.136] (II) intel(0): Output VGA1 has no monitor section > > [ 89.350] (II) intel(0): Output HDMI1 has no monitor section > > [ 89.368] (II) intel(0): Output DP1 has no monitor section > > [ 89.378] (II) intel(0): Output HDMI2 has no monitor section > > [ 89.387] (II) intel(0): Output HDMI3 has no monitor section > > [ 89.405] (II) intel(0): Output DP2 has no monitor section > > [ 89.423] (II) intel(0): Output DP3 has no monitor section > > [ 89.423] (II) intel(0): EDID for output LVDS1 > > [ 89.423] (II) intel(0): Manufacturer: SEC Model: 324c Serial#: 0 > > [ 89.423] (II) intel(0): Year: 2010 Week: 0 > > [ 89.423] (II) intel(0): EDID Version: 1.3 > > [ 89.423] (II) intel(0): Digital Display Input > > [ 89.423] (II) intel(0): Max Image Size [cm]: horiz.: 31 vert.: 17 > > [ 89.423] (II) intel(0): Gamma: 2.20 > > [ 89.424] (II) intel(0): DPMS capabilities: StandBy Suspend Off > > [ 89.424] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb > > 4:4:4 > > [ 89.424] (II) intel(0): First detailed timing is preferred mode > > [ 89.424] (II) intel(0): redX: 0.566 redY: 0.337 greenX: 0.351 > greenY: > > 0.560 > > [ 89.424] (II) intel(0): blueX: 0.150 blueY: 0.094 whiteX: 0.313 > > whiteY: 0.329 > > [ 89.424] (II) intel(0): Manufacturer's mask: 0 > > [ 89.424] (II) intel(0): Supported detailed timing: > > [ 89.424] (II) intel(0): clock: 98.2 MHz Image Size: 310 x 174 mm > > [ 89.424] (II) intel(0): h_active: 1600 h_sync: 1648 h_sync_end 1680 > > h_blank_end 1760 h_border: 0 > > [ 89.424] (II) intel(0): v_active: 900 v_sync: 902 v_sync_end 907 > > v_blanking: 930 v_border: 0 > > [ 89.424] (II) intel(0): Unknown vendor-specific block f > > [ 89.424] (II) intel(0): SAMSUNG > > [ 89.424] (II) intel(0): LTN140KT03401 > > [ 89.424] (II) intel(0): EDID (in hex): > > [ 89.424] (II) intel(0): 00ffffffffffff004ca34c3200000000 > > [ 89.424] (II) intel(0): 00140103801f1178ea1d859156598f26 > > [ 89.424] (II) intel(0): 18505400000001010101010101010101 > > [ 89.424] (II) intel(0): 0101010101015d2640a060841e303020 > > [ 89.424] (II) intel(0): 250036ae100000190000000f00000000 > > [ 89.425] (II) intel(0): 000000000032c8043200000000fe0053 > > [ 89.425] (II) intel(0): 414d53554e470a204ca34b54000000fe > > [ 89.425] (II) intel(0): 004c544e3134304b54303334303100ca > > [ 89.425] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 89.425] (II) intel(0): Printing DDC gathered Modelines: > > [ 89.425] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 89.425] (II) intel(0): Not using default mode "320x240" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "512x384" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "640x480" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "640x512" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "800x600" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "896x672" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "928x696" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "960x720" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "700x525" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Not using default mode "1024x768" (doublescan > > mode not supported) > > [ 89.425] (II) intel(0): Printing probed modes for output LVDS1 > > [ 89.425] (II) intel(0): Modeline "1600x900"x60.0 98.21 1600 1648 > > 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 89.425] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 > > 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) > > [ 89.426] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 > > 1056 600 601 605 628 +hsync +vsync (37.9 kHz) > > [ 89.426] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 > > 1024 600 601 603 625 +hsync +vsync (35.2 kHz) > > [ 89.426] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 > > 800 480 490 492 525 -hsync -vsync (31.5 kHz) > > [ 89.426] (II) intel(0): EDID for output VGA1 > > [ 89.632] (II) intel(0): EDID for output HDMI1 > > [ 89.650] (II) intel(0): EDID for output DP1 > > [ 89.660] (II) intel(0): EDID for output HDMI2 > > [ 89.669] (II) intel(0): EDID for output HDMI3 > > [ 89.687] (II) intel(0): EDID for output DP2 > > [ 89.705] (II) intel(0): EDID for output DP3 > > [ 89.705] (II) intel(0): Output LVDS1 connected > > [ 89.705] (II) intel(0): Output VGA1 disconnected > > [ 89.705] (II) intel(0): Output HDMI1 disconnected > > [ 89.705] (II) intel(0): Output DP1 disconnected > > [ 89.705] (II) intel(0): Output HDMI2 disconnected > > [ 89.705] (II) intel(0): Output HDMI3 disconnected > > [ 89.705] (II) intel(0): Output DP2 disconnected > > [ 89.705] (II) intel(0): Output DP3 disconnected > > [ 89.705] (II) intel(0): Using exact sizes for initial modes > > [ 89.705] (II) intel(0): Output LVDS1 using initial mode 1600x900 > > [ 89.706] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless > > otherwise stated. > > [ 89.706] (II) intel(0): Kernel page flipping support detected, > enabling > > [ 89.706] (**) intel(0): Display dimensions: (310, 170) mm > > [ 89.706] (**) intel(0): DPI set to (131, 134) > > [ 89.706] (II) Loading sub module "fb" > > [ 89.706] (II) LoadModule: "fb" > > [ 89.707] (II) Loading /usr/local/lib/xorg/modules/libfb.so > > [ 89.709] (II) Module fb: vendor="X.Org Foundation" > > [ 89.709] compiled for 1.10.6, module version = 1.0.0 > > [ 89.709] ABI class: X.Org ANSI C Emulation, version 0.4 > > [ 89.709] (II) Loading sub module "dri2" > > [ 89.709] (II) LoadModule: "dri2" > > [ 89.709] (II) Loading > /usr/local/lib/xorg/modules/extensions/libdri2.so > > [ 89.710] (II) Module dri2: vendor="X.Org Foundation" > > [ 89.710] compiled for 1.10.6, module version = 1.2.0 > > [ 89.710] ABI class: X.Org Server Extension, version 5.0 > > [ 89.710] (II) UnloadModule: "vesa" > > [ 89.710] (II) Unloading vesa > > [ 89.710] (==) Depth 24 pixmap format is 32 bpp > > [ 89.710] (II) intel(0): [DRI2] Setup complete > > [ 89.710] (II) intel(0): [DRI2] DRI driver: i965 > > [ 89.710] (II) intel(0): Allocated new frame buffer 1600x900 stride > > 6656, tiled > > [ 89.716] (II) UXA(0): Driver registered support for the following > > operations: > > [ 89.716] (II) solid > > [ 89.716] (II) copy > > [ 89.716] (II) composite (RENDER acceleration) > > [ 89.716] (II) put_image > > [ 89.716] (II) get_image > > [ 89.716] (==) intel(0): Backing store disabled > > [ 89.716] (==) intel(0): Silken mouse enabled > > [ 89.716] (II) intel(0): Initializing HW Cursor > > [ 89.873] (II) intel(0): RandR 1.2 enabled, ignore the following RandR > > disabled message. > > [ 89.873] (==) intel(0): DPMS enabled > > [ 89.873] (==) intel(0): Intel XvMC decoder enabled > > [ 89.873] (II) intel(0): Set up textured video > > [ 89.874] (II) intel(0): [XvMC] xvmc_vld driver initialized. > > [ 89.874] (II) intel(0): direct rendering: DRI2 Enabled > > [ 89.874] (--) RandR disabled > > [ 89.874] (II) Initializing built-in extension Generic Event Extension > > [ 89.874] (II) Initializing built-in extension SHAPE > > [ 89.874] (II) Initializing built-in extension MIT-SHM > > [ 89.874] (II) Initializing built-in extension XInputExtension > > [ 89.874] (II) Initializing built-in extension XTEST > > [ 89.874] (II) Initializing built-in extension BIG-REQUESTS > > [ 89.874] (II) Initializing built-in extension SYNC > > [ 89.874] (II) Initializing built-in extension XKEYBOARD > > [ 89.874] (II) Initializing built-in extension XC-MISC > > [ 89.874] (II) Initializing built-in extension XINERAMA > > [ 89.874] (II) Initializing built-in extension XFIXES > > [ 89.874] (II) Initializing built-in extension RENDER > > [ 89.874] (II) Initializing built-in extension RANDR > > [ 89.874] (II) Initializing built-in extension COMPOSITE > > [ 89.874] (II) Initializing built-in extension DAMAGE > > [ 89.912] (II) AIGLX: Loaded and initialized > > /usr/local/lib/dri/swrast_dri.so > > [ 89.912] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > [ 89.913] (II) intel(0): Setting screen physical size to 423 x 238 > > [ 92.986] (II) config/hal: Adding input device AT Keyboard > > [ 92.987] (II) LoadModule: "kbd" > > [ 92.987] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so > > [ 92.988] (II) Module kbd: vendor="X.Org Foundation" > > [ 92.989] compiled for 1.10.6, module version = 1.6.1 > > [ 92.989] Module class: X.Org XInput Driver > > [ 92.989] ABI class: X.Org XInput driver, version 12.2 > > [ 92.989] (II) Using input driver 'kbd' for 'AT Keyboard' > > [ 92.989] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so > > [ 92.989] (**) AT Keyboard: always reports core events > > [ 92.989] (**) AT Keyboard: always reports core events > > [ 92.989] (**) Option "Protocol" "standard" > > [ 92.989] (**) Option "XkbRules" "base" > > [ 92.989] (**) Option "XkbModel" "pc105" > > [ 92.989] (**) Option "XkbLayout" "us" > > [ 92.989] (**) Option "config_info" > > "hal:/org/freedesktop/Hal/devices/atkbd_0" > > [ 92.989] (II) XINPUT: Adding extended input device "AT Keyboard" > (type: > > KEYBOARD) > > [ 95.110] (II) config/hal: Adding input device PS/2 Mouse > > [ 95.110] (II) LoadModule: "mouse" > > [ 95.111] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > [ 95.112] (II) Module mouse: vendor="X.Org Foundation" > > [ 95.112] compiled for 1.10.6, module version = 1.7.1 > > [ 95.112] Module class: X.Org XInput Driver > > [ 95.112] ABI class: X.Org XInput driver, version 12.2 > > [ 95.112] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > [ 95.112] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > [ 95.112] (**) PS/2 Mouse: always reports core events > > [ 95.112] (**) Option "Device" "/dev/psm0" > > [ 95.112] (==) PS/2 Mouse: Protocol: "Auto" > > [ 95.112] (**) PS/2 Mouse: always reports core events > > [ 95.165] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 > > [ 95.165] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 > > [ 95.165] (**) PS/2 Mouse: Buttons: 9 > > [ 95.165] (**) Option "config_info" > > "hal:/org/freedesktop/Hal/devices/psm_0" > > [ 95.165] (II) XINPUT: Adding extended input device "PS/2 Mouse" > (type: > > MOUSE) > > [ 95.165] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 > > [ 95.165] (**) PS/2 Mouse: (accel) acceleration profile 0 > > [ 95.165] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 > > [ 95.165] (**) PS/2 Mouse: (accel) acceleration threshold: 4 > > [ 95.183] (II) PS/2 Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 > > [ 95.183] (II) PS/2 Mouse: SetupAuto: protocol is PS/2 > > [ 95.340] (II) PS/2 Mouse: ps2EnableDataReporting: succeeded > > [ 96.475] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 96.475] (II) intel(0): Printing DDC gathered Modelines: > > [ 96.475] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 96.755] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 96.755] (II) intel(0): Printing DDC gathered Modelines: > > [ 96.755] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 97.036] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 97.036] (II) intel(0): Printing DDC gathered Modelines: > > [ 97.036] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 97.315] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 97.315] (II) intel(0): Printing DDC gathered Modelines: > > [ 97.315] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 107.345] (II) intel(0): EDID vendor "SEC", prod id 12876 > > [ 107.345] (II) intel(0): Printing DDC gathered Modelines: > > [ 107.345] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648 > 1680 > > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) > > [ 108.696] Segmentation fault at address 0x3fffffffed > > [ 108.696] > > Fatal server error: > > [ 108.697] Caught signal 11 (Segmentation fault). Server aborting > > [ 108.697] > > [ 108.697] > > Please consult the The X.Org Foundation support > > at http://wiki.x.org > > for help. > > [ 108.697] Please also check the log file at "/var/log/Xorg.0.log" for > > additional information. > > [ 108.697] > > [ 108.698] (II) UnloadModule: "kbd" > > [ 108.698] (II) Unloading kbd > > [ 108.733] (II) UnloadModule: "mouse" > > [ 108.733] (II) Unloading mouse > > [ 108.733] (WW) intel(0): drmDropMaster failed: Unknown error: -22 > > > > Perhaps someone got an idea? > > > > Thanks a lot > > > > Johannes > > _______________________________________________ > > 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" > -- > This message is for the person(s) named above only and may contain > privileged, proprietary, or otherwise private information. If you received > this transmission in error, please notify the sender immediately and delete > the original. Any other use of the email by you is prohibited. > _______________________________________________ > 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 Dec 13 21:03:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC412B07 for ; Thu, 13 Dec 2012 21:03:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 798438FC13 for ; Thu, 13 Dec 2012 21:03:58 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2777736oag.13 for ; Thu, 13 Dec 2012 13:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lAXNnjuYZfiXOUKykGJEJpxefSlvIKuNVi4kATbP7rA=; b=SfF6Gm/z107EgtpVNceG41HRpsTcuKcwCasYE1mJxasjSAIQxQF+csbxXg2Y5Vx0eE VmID1m9z/5d25ZeFZ2AXHj0RwcOKNo3ojAn/XXWMx46EkYvwIWF6LclcTAoUuGgMUax0 2H41/bWIolecUS4nWupvnD4TjoOSDsXusc9WsZduujuUFpiqFDSRp4ZiYFKRz5RBn7CF VCaMswwGNrcE8IsI4Rl8sVhwy+zIVwlUBDJ5RmRhPPDTfYA5vmKoEwe7LSVhgBxQJjti 1hLc5QWW0rVcBbwYRkzydtvK5tgdlmXFKKiUMxFfOsuw81chOYe1QoD02M3AsE1fnBtn 6itw== MIME-Version: 1.0 Received: by 10.60.21.167 with SMTP id w7mr2738539oee.18.1355432637670; Thu, 13 Dec 2012 13:03:57 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 13 Dec 2012 13:03:57 -0800 (PST) In-Reply-To: <2279995.En67FjFeZ3@home.alkar.net> References: <2279995.En67FjFeZ3@home.alkar.net> Date: Thu, 13 Dec 2012 13:03:57 -0800 Message-ID: Subject: Re: new xorg segfault 11 with KMS From: Garrett Cooper To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: Johannes Dieterich , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:03:58 -0000 On Thu, Dec 13, 2012 at 12:51 PM, Artyom Mirgorodskiy wrote: > I have a similar problem when running firefox I don't run into this problem with CURRENT and fluxbox/Firefox on my Netbook. There's just a nasty misprogrammed region across my screen that I've been meaning to file a bug about... My Netbook has a Pineview chipset. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:04:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F521C1D for ; Thu, 13 Dec 2012 21:04:35 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E81598FC14 for ; Thu, 13 Dec 2012 21:04:34 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2604145obc.13 for ; Thu, 13 Dec 2012 13:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZFSAQGw0MRmaJc3hA2SPvEmz7cSxM8fQ6/H/V2H4+C4=; b=B6Fdwvw3THeKU6Q6LZrjmF9O8jsKQcDLF9S5yA0wtSsazYRsUuQlYZg+wGa+Bdy+N2 cc+XIhmqFx+PZRc61+BI2fJvkiVjJwwDqcKSfNsQgP79Hiwe+4DRSqljsdZ9jcvGSodz hBif3JG8ru0iS/oHQjzwnO2liGG8N9dKE3cHIAdHwu6JsRXHqBXENFlsVkGZQscf0r70 flxzwelQQGJ5baWABar6CGXO7P/uRhm7U8SZlhbhn0Ik1jRGwjm0uasVfSvBP88HxJ0T JrBMJe1tML+0W5xAgMh4dM+r/QXcTbP+cQZ/31GZK5vHQvAP4OXdsDgypE/kWcjSTbnV /ELA== MIME-Version: 1.0 Received: by 10.182.64.14 with SMTP id k14mr2783752obs.72.1355432673961; Thu, 13 Dec 2012 13:04:33 -0800 (PST) Received: by 10.182.190.83 with HTTP; Thu, 13 Dec 2012 13:04:33 -0800 (PST) In-Reply-To: References: <2279995.En67FjFeZ3@home.alkar.net> Date: Thu, 13 Dec 2012 16:04:33 -0500 Message-ID: Subject: Re: new xorg segfault 11 with KMS From: Johannes Dieterich To: George Liaskos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Artyom Mirgorodskiy , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:04:35 -0000 On Thu, Dec 13, 2012 at 4:01 PM, George Liaskos wro= te: > > Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm= 2. So basically this is a regression from the previous clang3.1 to the clang3.2 import then? Is anyone of the clang guys aware of this? > On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy wrote: >> >> I have a similar problem when running firefox >> >> On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: >> > Dear all, >> > >> > I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=3Dyes and >> > WITH_KMS=3Dyes. Interestingly, gdm loads fine but xfce4 at login direc= tly >> > causes the segfault (log attached), gnome survives a bit longer but >> > starting any bigger application (e.g. firefox) causes it to crash with= the >> > same log. >> > >> > I have a Xorg.core file, but since it is without debug symbols the >> > backtrace makes little sense to me. >> > >> > Unfortunately, I cannot tell what is the root cause of the problems as= I >> > first got bitten by the pcre update and also did the world update to t= he >> > clang3.2 import. Needless to say that everything worked prior and the >> > configuration (no xorg.conf here) did not change. >> > >> > uname -a: >> > FreeBSD XXXXX 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 >> > 09:46:06 EST 2012 root@XXXXX:/usr/obj/usr/src/sys/GENERIC amd64. >> > >> > Xorg.0.log: >> > [ 88.021] >> > X.Org X Server 1.10.6 >> > Release Date: 2012-02-10 >> > [ 88.021] X Protocol Version 11, Revision 0 >> > [ 88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 >> > [ 88.021] Current Operating System: FreeBSD XXXXXXXXX 10.0-CURRENT >> > FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 >> > root@XXXXXXX:/usr/obj/usr/src/sys/GENERIC amd64 >> > [ 88.021] Build Date: 13 December 2012 06:30:07AM >> > [ 88.021] >> > [ 88.021] Current version of pixman: 0.24.2 >> > [ 88.021] Before reporting problems, check http://wiki.x.org >> > to make sure that you have the latest version. >> > [ 88.021] Markers: (--) probed, (**) from config file, (=3D=3D) def= ault >> > setting, >> > (++) from command line, (!!) notice, (II) informational, >> > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> > [ 88.022] (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 1= 3 >> > 15:01:42 2012 >> > [ 88.024] (II) Loader magic: 0x7c1930 >> > [ 88.024] (II) Module ABI versions: >> > [ 88.024] X.Org ANSI C Emulation: 0.4 >> > [ 88.024] X.Org Video Driver: 10.0 >> > [ 88.024] X.Org XInput driver : 12.2 >> > [ 88.024] X.Org Server Extension : 5.0 >> > [ 88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ >> > 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x00005000/64, BIOS @ >> > 0x????????/65536 >> > [ 88.025] (=3D=3D) Using default built-in configuration (30 lines) >> > [ 88.025] (=3D=3D) --- Start of built-in configuration --- >> > [ 88.025] Section "Device" >> > [ 88.025] Identifier "Builtin Default intel Device = 0" >> > [ 88.025] Driver "intel" >> > [ 88.025] EndSection >> > [ 88.025] Section "Screen" >> > [ 88.025] Identifier "Builtin Default intel Screen = 0" >> > [ 88.025] Device "Builtin Default intel Device 0" >> > [ 88.025] EndSection >> > [ 88.025] Section "Device" >> > [ 88.025] Identifier "Builtin Default vesa Device 0= " >> > [ 88.025] Driver "vesa" >> > [ 88.025] EndSection >> > [ 88.025] Section "Screen" >> > [ 88.025] Identifier "Builtin Default vesa Screen 0= " >> > [ 88.025] Device "Builtin Default vesa Device 0" >> > [ 88.025] EndSection >> > [ 88.025] Section "Device" >> > [ 88.025] Identifier "Builtin Default fbdev Device = 0" >> > [ 88.025] Driver "fbdev" >> > [ 88.025] EndSection >> > [ 88.025] Section "Screen" >> > [ 88.025] Identifier "Builtin Default fbdev Screen = 0" >> > [ 88.025] Device "Builtin Default fbdev Device 0" >> > [ 88.026] EndSection >> > [ 88.026] Section "ServerLayout" >> > [ 88.026] Identifier "Builtin Default Layout" >> > [ 88.026] Screen "Builtin Default intel Screen 0" >> > [ 88.026] Screen "Builtin Default vesa Screen 0" >> > [ 88.026] Screen "Builtin Default fbdev Screen 0" >> > [ 88.026] EndSection >> > [ 88.026] (=3D=3D) --- End of built-in configuration --- >> > [ 88.026] (=3D=3D) ServerLayout "Builtin Default Layout" >> > [ 88.026] (**) |-->Screen "Builtin Default intel Screen 0" (0) >> > [ 88.026] (**) | |-->Monitor "" >> > [ 88.026] (**) | |-->Device "Builtin Default intel Device 0" >> > [ 88.026] (=3D=3D) No monitor specified for screen "Builtin Default= intel >> > Screen 0". >> > Using a default monitor configuration. >> > [ 88.026] (**) |-->Screen "Builtin Default vesa Screen 0" (1) >> > [ 88.026] (**) | |-->Monitor "" >> > [ 88.026] (**) | |-->Device "Builtin Default vesa Device 0" >> > [ 88.026] (=3D=3D) No monitor specified for screen "Builtin Default= vesa >> > Screen 0". >> > Using a default monitor configuration. >> > [ 88.026] (**) |-->Screen "Builtin Default fbdev Screen 0" (2) >> > [ 88.027] (**) | |-->Monitor "" >> > [ 88.027] (**) | |-->Device "Builtin Default fbdev Device 0" >> > [ 88.027] (=3D=3D) No monitor specified for screen "Builtin Default= fbdev >> > Screen 0". >> > Using a default monitor configuration. >> > [ 88.027] (=3D=3D) Automatically adding devices >> > [ 88.027] (=3D=3D) Automatically enabling devices >> > [ 88.027] (WW) The directory "/usr/local/lib/X11/fonts/misc/" does = not >> > exist. >> > [ 88.027] Entry deleted from font path. >> > [ 88.028] (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does= not >> > exist. >> > [ 88.029] Entry deleted from font path. >> > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/100dpi/" doe= s not >> > exist. >> > [ 88.029] Entry deleted from font path. >> > [ 88.029] (WW) The directory "/usr/local/lib/X11/fonts/75dpi/" does= not >> > exist. >> > [ 88.029] Entry deleted from font path. >> > [ 88.029] (=3D=3D) FontPath set to: >> > /usr/local/lib/X11/fonts/TTF/, >> > /usr/local/lib/X11/fonts/OTF/ >> > [ 88.029] (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules" >> > [ 88.029] (II) The server relies on HAL to provide the list of inpu= t >> > devices. >> > If no devices become available, reconfigure HAL or disable >> > AutoAddDevices. >> > [ 88.029] (II) LoadModule: "extmod" >> > [ 88.032] (II) Loading >> > /usr/local/lib/xorg/modules/extensions/libextmod.so >> > [ 88.033] (II) Module extmod: vendor=3D"X.Org Foundation" >> > [ 88.033] compiled for 1.10.6, module version =3D 1.0.0 >> > [ 88.033] Module class: X.Org Server Extension >> > [ 88.033] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.033] (II) Loading extension MIT-SCREEN-SAVER >> > [ 88.033] (II) Loading extension XFree86-VidModeExtension >> > [ 88.033] (II) Loading extension XFree86-DGA >> > [ 88.033] (II) Loading extension DPMS >> > [ 88.034] (II) Loading extension XVideo >> > [ 88.034] (II) Loading extension XVideo-MotionCompensation >> > [ 88.034] (II) Loading extension X-Resource >> > [ 88.034] (II) LoadModule: "dbe" >> > [ 88.034] (II) Loading /usr/local/lib/xorg/modules/extensions/libdb= e.so >> > [ 88.035] (II) Module dbe: vendor=3D"X.Org Foundation" >> > [ 88.035] compiled for 1.10.6, module version =3D 1.0.0 >> > [ 88.035] Module class: X.Org Server Extension >> > [ 88.035] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.035] (II) Loading extension DOUBLE-BUFFER >> > [ 88.035] (II) LoadModule: "glx" >> > [ 88.035] (II) Loading /usr/local/lib/xorg/modules/extensions/libgl= x.so >> > [ 88.040] (II) Module glx: vendor=3D"X.Org Foundation" >> > [ 88.040] compiled for 1.10.6, module version =3D 1.0.0 >> > [ 88.040] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.041] (=3D=3D) AIGLX disabled >> > [ 88.041] (II) Loading extension GLX >> > [ 88.041] (II) LoadModule: "record" >> > [ 88.042] (II) Loading >> > /usr/local/lib/xorg/modules/extensions/librecord.so >> > [ 88.043] (II) Module record: vendor=3D"X.Org Foundation" >> > [ 88.043] compiled for 1.10.6, module version =3D 1.13.0 >> > [ 88.043] Module class: X.Org Server Extension >> > [ 88.043] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.043] (II) Loading extension RECORD >> > [ 88.043] (II) LoadModule: "dri" >> > [ 88.043] (II) Loading /usr/local/lib/xorg/modules/extensions/libdr= i.so >> > [ 88.045] (II) Module dri: vendor=3D"X.Org Foundation" >> > [ 88.045] compiled for 1.10.6, module version =3D 1.0.0 >> > [ 88.045] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.045] (II) Loading extension XFree86-DRI >> > [ 88.046] (II) LoadModule: "dri2" >> > [ 88.046] (II) Loading /usr/local/lib/xorg/modules/extensions/libdr= i2.so >> > [ 88.047] (II) Module dri2: vendor=3D"X.Org Foundation" >> > [ 88.047] compiled for 1.10.6, module version =3D 1.2.0 >> > [ 88.047] ABI class: X.Org Server Extension, version 5.0 >> > [ 88.047] (II) Loading extension DRI2 >> > [ 88.047] (II) LoadModule: "intel" >> > [ 88.047] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_dr= v.so >> > [ 88.053] (II) Module intel: vendor=3D"X.Org Foundation" >> > [ 88.053] compiled for 1.10.6, module version =3D 2.17.0 >> > [ 88.053] Module class: X.Org Video Driver >> > [ 88.053] ABI class: X.Org Video Driver, version 10.0 >> > [ 88.053] (II) LoadModule: "vesa" >> > [ 88.053] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv= .so >> > [ 88.054] (II) Module vesa: vendor=3D"X.Org Foundation" >> > [ 88.054] compiled for 1.10.6, module version =3D 2.3.0 >> > [ 88.054] Module class: X.Org Video Driver >> > [ 88.054] ABI class: X.Org Video Driver, version 10.0 >> > [ 88.054] (II) LoadModule: "fbdev" >> > [ 88.057] (WW) Warning, couldn't open module fbdev >> > [ 88.057] (II) UnloadModule: "fbdev" >> > [ 88.057] (II) Unloading fbdev >> > [ 88.057] (EE) Failed to load module "fbdev" (module does not exist= , 0) >> > [ 88.057] (II) intel: Driver for Intel Integrated Graphics Chipsets= : >> > i810, >> > i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, = 915G, >> > E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pinevie= w G, >> > 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45= , >> > 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandal= e, >> > Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), >> > Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), >> > Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), >> > Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (= GT2), >> > Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Se= rver >> > [ 88.060] (II) VESA: driver for VESA chipsets: vesa >> > [ 88.060] (--) Using syscons driver with X support (version 2.0) >> > [ 88.060] (--) using VT number 9 >> > >> > [ 88.062] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_dr= v.so >> > [ 88.062] (WW) Falling back to old probe method for vesa >> > [ 88.062] (WW) VGA arbiter: cannot open kernel arbiter, no multi-ca= rd >> > support >> > [ 88.062] drmOpenDevice: node name is /dev/dri/card0 >> > [ 88.062] Failed to change owner or group for file /dev/dri! 2: No = such >> > file or directory >> > [ 88.062] Failed to change owner or group for file /dev/dri/card0! = 2: No >> > such file or directory >> > [ 88.062] drmOpenDevice: open result is -1, (No such file or direct= ory) >> > [ 88.062] Failed to change owner or group for file /dev/dri/card0! = 2: No >> > such file or directory >> > [ 88.062] drmOpenDevice: open result is -1, (No such file or direct= ory) >> > [ 88.062] drmOpenDevice: Open failed >> > [ 89.135] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 >> > [ 89.135] drmOpenDevice: node name is /dev/dri/card0 >> > [ 89.135] drmOpenDevice: open result is 8, (OK) >> > [ 89.135] drmOpenByBusid: drmOpenMinor returns 8 >> > [ 89.135] drmOpenByBusid: Interface 1.4 failed, trying 1.1 >> > [ 89.135] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 >> > [ 89.135] (II) intel(0): Creating default Display subsection in Scr= een >> > section >> > "Builtin Default intel Screen 0" for depth/fbbpp 24/32 >> > [ 89.135] (=3D=3D) intel(0): Depth 24, (--) framebuffer bpp 32 >> > [ 89.135] (=3D=3D) intel(0): RGB weight 888 >> > [ 89.135] (=3D=3D) intel(0): Default visual is TrueColor >> > [ 89.135] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivyb= ridge >> > Mobile (GT2) >> > [ 89.135] (--) intel(0): Chipset: "Ivybridge Mobile (GT2)" >> > [ 89.135] (**) intel(0): Relaxed fencing enabled >> > [ 89.135] (**) intel(0): Wait on SwapBuffers? enabled >> > [ 89.135] (**) intel(0): Triple buffering? enabled >> > [ 89.135] (**) intel(0): Framebuffer tiled >> > [ 89.135] (**) intel(0): Pixmaps tiled >> > [ 89.135] (**) intel(0): 3D buffers tiled >> > [ 89.135] (**) intel(0): SwapBuffers wait enabled >> > [ 89.136] (=3D=3D) intel(0): video overlay key set to 0x101fe >> > [ 89.136] (II) intel(0): Output LVDS1 has no monitor section >> > [ 89.136] (II) intel(0): Output VGA1 has no monitor section >> > [ 89.350] (II) intel(0): Output HDMI1 has no monitor section >> > [ 89.368] (II) intel(0): Output DP1 has no monitor section >> > [ 89.378] (II) intel(0): Output HDMI2 has no monitor section >> > [ 89.387] (II) intel(0): Output HDMI3 has no monitor section >> > [ 89.405] (II) intel(0): Output DP2 has no monitor section >> > [ 89.423] (II) intel(0): Output DP3 has no monitor section >> > [ 89.423] (II) intel(0): EDID for output LVDS1 >> > [ 89.423] (II) intel(0): Manufacturer: SEC Model: 324c Serial#: 0 >> > [ 89.423] (II) intel(0): Year: 2010 Week: 0 >> > [ 89.423] (II) intel(0): EDID Version: 1.3 >> > [ 89.423] (II) intel(0): Digital Display Input >> > [ 89.423] (II) intel(0): Max Image Size [cm]: horiz.: 31 vert.: 17 >> > [ 89.423] (II) intel(0): Gamma: 2.20 >> > [ 89.424] (II) intel(0): DPMS capabilities: StandBy Suspend Off >> > [ 89.424] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb >> > 4:4:4 >> > [ 89.424] (II) intel(0): First detailed timing is preferred mode >> > [ 89.424] (II) intel(0): redX: 0.566 redY: 0.337 greenX: 0.351 gr= eenY: >> > 0.560 >> > [ 89.424] (II) intel(0): blueX: 0.150 blueY: 0.094 whiteX: 0.313 >> > whiteY: 0.329 >> > [ 89.424] (II) intel(0): Manufacturer's mask: 0 >> > [ 89.424] (II) intel(0): Supported detailed timing: >> > [ 89.424] (II) intel(0): clock: 98.2 MHz Image Size: 310 x 174 m= m >> > [ 89.424] (II) intel(0): h_active: 1600 h_sync: 1648 h_sync_end 1= 680 >> > h_blank_end 1760 h_border: 0 >> > [ 89.424] (II) intel(0): v_active: 900 v_sync: 902 v_sync_end 907 >> > v_blanking: 930 v_border: 0 >> > [ 89.424] (II) intel(0): Unknown vendor-specific block f >> > [ 89.424] (II) intel(0): SAMSUNG >> > [ 89.424] (II) intel(0): LTN140KT03401 >> > [ 89.424] (II) intel(0): EDID (in hex): >> > [ 89.424] (II) intel(0): 00ffffffffffff004ca34c3200000000 >> > [ 89.424] (II) intel(0): 00140103801f1178ea1d859156598f26 >> > [ 89.424] (II) intel(0): 18505400000001010101010101010101 >> > [ 89.424] (II) intel(0): 0101010101015d2640a060841e303020 >> > [ 89.424] (II) intel(0): 250036ae100000190000000f00000000 >> > [ 89.425] (II) intel(0): 000000000032c8043200000000fe0053 >> > [ 89.425] (II) intel(0): 414d53554e470a204ca34b54000000fe >> > [ 89.425] (II) intel(0): 004c544e3134304b54303334303100ca >> > [ 89.425] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 89.425] (II) intel(0): Printing DDC gathered Modelines: >> > [ 89.425] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 89.425] (II) intel(0): Not using default mode "320x240" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "400x300" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "512x384" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "640x480" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "640x512" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "800x600" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "896x672" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "928x696" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "960x720" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "700x525" (doublesc= an >> > mode not supported) >> > [ 89.425] (II) intel(0): Not using default mode "1024x768" (doubles= can >> > mode not supported) >> > [ 89.425] (II) intel(0): Printing probed modes for output LVDS1 >> > [ 89.425] (II) intel(0): Modeline "1600x900"x60.0 98.21 1600 164= 8 >> > 1680 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 89.425] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 104= 8 >> > 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) >> > [ 89.426] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 9= 68 >> > 1056 600 601 605 628 +hsync +vsync (37.9 kHz) >> > [ 89.426] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 8= 96 >> > 1024 600 601 603 625 +hsync +vsync (35.2 kHz) >> > [ 89.426] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 7= 52 >> > 800 480 490 492 525 -hsync -vsync (31.5 kHz) >> > [ 89.426] (II) intel(0): EDID for output VGA1 >> > [ 89.632] (II) intel(0): EDID for output HDMI1 >> > [ 89.650] (II) intel(0): EDID for output DP1 >> > [ 89.660] (II) intel(0): EDID for output HDMI2 >> > [ 89.669] (II) intel(0): EDID for output HDMI3 >> > [ 89.687] (II) intel(0): EDID for output DP2 >> > [ 89.705] (II) intel(0): EDID for output DP3 >> > [ 89.705] (II) intel(0): Output LVDS1 connected >> > [ 89.705] (II) intel(0): Output VGA1 disconnected >> > [ 89.705] (II) intel(0): Output HDMI1 disconnected >> > [ 89.705] (II) intel(0): Output DP1 disconnected >> > [ 89.705] (II) intel(0): Output HDMI2 disconnected >> > [ 89.705] (II) intel(0): Output HDMI3 disconnected >> > [ 89.705] (II) intel(0): Output DP2 disconnected >> > [ 89.705] (II) intel(0): Output DP3 disconnected >> > [ 89.705] (II) intel(0): Using exact sizes for initial modes >> > [ 89.705] (II) intel(0): Output LVDS1 using initial mode 1600x900 >> > [ 89.706] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unl= ess >> > otherwise stated. >> > [ 89.706] (II) intel(0): Kernel page flipping support detected, ena= bling >> > [ 89.706] (**) intel(0): Display dimensions: (310, 170) mm >> > [ 89.706] (**) intel(0): DPI set to (131, 134) >> > [ 89.706] (II) Loading sub module "fb" >> > [ 89.706] (II) LoadModule: "fb" >> > [ 89.707] (II) Loading /usr/local/lib/xorg/modules/libfb.so >> > [ 89.709] (II) Module fb: vendor=3D"X.Org Foundation" >> > [ 89.709] compiled for 1.10.6, module version =3D 1.0.0 >> > [ 89.709] ABI class: X.Org ANSI C Emulation, version 0.4 >> > [ 89.709] (II) Loading sub module "dri2" >> > [ 89.709] (II) LoadModule: "dri2" >> > [ 89.709] (II) Loading /usr/local/lib/xorg/modules/extensions/libdr= i2.so >> > [ 89.710] (II) Module dri2: vendor=3D"X.Org Foundation" >> > [ 89.710] compiled for 1.10.6, module version =3D 1.2.0 >> > [ 89.710] ABI class: X.Org Server Extension, version 5.0 >> > [ 89.710] (II) UnloadModule: "vesa" >> > [ 89.710] (II) Unloading vesa >> > [ 89.710] (=3D=3D) Depth 24 pixmap format is 32 bpp >> > [ 89.710] (II) intel(0): [DRI2] Setup complete >> > [ 89.710] (II) intel(0): [DRI2] DRI driver: i965 >> > [ 89.710] (II) intel(0): Allocated new frame buffer 1600x900 stride >> > 6656, tiled >> > [ 89.716] (II) UXA(0): Driver registered support for the following >> > operations: >> > [ 89.716] (II) solid >> > [ 89.716] (II) copy >> > [ 89.716] (II) composite (RENDER acceleration) >> > [ 89.716] (II) put_image >> > [ 89.716] (II) get_image >> > [ 89.716] (=3D=3D) intel(0): Backing store disabled >> > [ 89.716] (=3D=3D) intel(0): Silken mouse enabled >> > [ 89.716] (II) intel(0): Initializing HW Cursor >> > [ 89.873] (II) intel(0): RandR 1.2 enabled, ignore the following Ra= ndR >> > disabled message. >> > [ 89.873] (=3D=3D) intel(0): DPMS enabled >> > [ 89.873] (=3D=3D) intel(0): Intel XvMC decoder enabled >> > [ 89.873] (II) intel(0): Set up textured video >> > [ 89.874] (II) intel(0): [XvMC] xvmc_vld driver initialized. >> > [ 89.874] (II) intel(0): direct rendering: DRI2 Enabled >> > [ 89.874] (--) RandR disabled >> > [ 89.874] (II) Initializing built-in extension Generic Event Extens= ion >> > [ 89.874] (II) Initializing built-in extension SHAPE >> > [ 89.874] (II) Initializing built-in extension MIT-SHM >> > [ 89.874] (II) Initializing built-in extension XInputExtension >> > [ 89.874] (II) Initializing built-in extension XTEST >> > [ 89.874] (II) Initializing built-in extension BIG-REQUESTS >> > [ 89.874] (II) Initializing built-in extension SYNC >> > [ 89.874] (II) Initializing built-in extension XKEYBOARD >> > [ 89.874] (II) Initializing built-in extension XC-MISC >> > [ 89.874] (II) Initializing built-in extension XINERAMA >> > [ 89.874] (II) Initializing built-in extension XFIXES >> > [ 89.874] (II) Initializing built-in extension RENDER >> > [ 89.874] (II) Initializing built-in extension RANDR >> > [ 89.874] (II) Initializing built-in extension COMPOSITE >> > [ 89.874] (II) Initializing built-in extension DAMAGE >> > [ 89.912] (II) AIGLX: Loaded and initialized >> > /usr/local/lib/dri/swrast_dri.so >> > [ 89.912] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >> > [ 89.913] (II) intel(0): Setting screen physical size to 423 x 238 >> > [ 92.986] (II) config/hal: Adding input device AT Keyboard >> > [ 92.987] (II) LoadModule: "kbd" >> > [ 92.987] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so >> > [ 92.988] (II) Module kbd: vendor=3D"X.Org Foundation" >> > [ 92.989] compiled for 1.10.6, module version =3D 1.6.1 >> > [ 92.989] Module class: X.Org XInput Driver >> > [ 92.989] ABI class: X.Org XInput driver, version 12.2 >> > [ 92.989] (II) Using input driver 'kbd' for 'AT Keyboard' >> > [ 92.989] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so >> > [ 92.989] (**) AT Keyboard: always reports core events >> > [ 92.989] (**) AT Keyboard: always reports core events >> > [ 92.989] (**) Option "Protocol" "standard" >> > [ 92.989] (**) Option "XkbRules" "base" >> > [ 92.989] (**) Option "XkbModel" "pc105" >> > [ 92.989] (**) Option "XkbLayout" "us" >> > [ 92.989] (**) Option "config_info" >> > "hal:/org/freedesktop/Hal/devices/atkbd_0" >> > [ 92.989] (II) XINPUT: Adding extended input device "AT Keyboard" (= type: >> > KEYBOARD) >> > [ 95.110] (II) config/hal: Adding input device PS/2 Mouse >> > [ 95.110] (II) LoadModule: "mouse" >> > [ 95.111] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.= so >> > [ 95.112] (II) Module mouse: vendor=3D"X.Org Foundation" >> > [ 95.112] compiled for 1.10.6, module version =3D 1.7.1 >> > [ 95.112] Module class: X.Org XInput Driver >> > [ 95.112] ABI class: X.Org XInput driver, version 12.2 >> > [ 95.112] (II) Using input driver 'mouse' for 'PS/2 Mouse' >> > [ 95.112] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.= so >> > [ 95.112] (**) PS/2 Mouse: always reports core events >> > [ 95.112] (**) Option "Device" "/dev/psm0" >> > [ 95.112] (=3D=3D) PS/2 Mouse: Protocol: "Auto" >> > [ 95.112] (**) PS/2 Mouse: always reports core events >> > [ 95.165] (=3D=3D) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 >> > [ 95.165] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 >> > [ 95.165] (**) PS/2 Mouse: Buttons: 9 >> > [ 95.165] (**) Option "config_info" >> > "hal:/org/freedesktop/Hal/devices/psm_0" >> > [ 95.165] (II) XINPUT: Adding extended input device "PS/2 Mouse" (t= ype: >> > MOUSE) >> > [ 95.165] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 >> > [ 95.165] (**) PS/2 Mouse: (accel) acceleration profile 0 >> > [ 95.165] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 >> > [ 95.165] (**) PS/2 Mouse: (accel) acceleration threshold: 4 >> > [ 95.183] (II) PS/2 Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 >> > [ 95.183] (II) PS/2 Mouse: SetupAuto: protocol is PS/2 >> > [ 95.340] (II) PS/2 Mouse: ps2EnableDataReporting: succeeded >> > [ 96.475] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 96.475] (II) intel(0): Printing DDC gathered Modelines: >> > [ 96.475] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 96.755] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 96.755] (II) intel(0): Printing DDC gathered Modelines: >> > [ 96.755] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 97.036] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 97.036] (II) intel(0): Printing DDC gathered Modelines: >> > [ 97.036] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 97.315] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 97.315] (II) intel(0): Printing DDC gathered Modelines: >> > [ 97.315] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 107.345] (II) intel(0): EDID vendor "SEC", prod id 12876 >> > [ 107.345] (II) intel(0): Printing DDC gathered Modelines: >> > [ 107.345] (II) intel(0): Modeline "1600x900"x0.0 98.21 1600 1648= 1680 >> > 1760 900 902 907 930 -hsync -vsync (55.8 kHz) >> > [ 108.696] Segmentation fault at address 0x3fffffffed >> > [ 108.696] >> > Fatal server error: >> > [ 108.697] Caught signal 11 (Segmentation fault). Server aborting >> > [ 108.697] >> > [ 108.697] >> > Please consult the The X.Org Foundation support >> > at http://wiki.x.org >> > for help. >> > [ 108.697] Please also check the log file at "/var/log/Xorg.0.log" f= or >> > additional information. >> > [ 108.697] >> > [ 108.698] (II) UnloadModule: "kbd" >> > [ 108.698] (II) Unloading kbd >> > [ 108.733] (II) UnloadModule: "mouse" >> > [ 108.733] (II) Unloading mouse >> > [ 108.733] (WW) intel(0): drmDropMaster failed: Unknown error: -22 >> > >> > Perhaps someone got an idea? >> > >> > Thanks a lot >> > >> > Johannes >> > _______________________________________________ >> > 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" >> -- >> This message is for the person(s) named above only and may contain privi= leged, proprietary, or otherwise private information. If you received this = transmission in error, please notify the sender immediately and delete the = original. Any other use of the email by you is prohibited. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:05:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97F8CD3F for ; Thu, 13 Dec 2012 21:05:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5469A8FC18 for ; Thu, 13 Dec 2012 21:05:51 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2780030oag.13 for ; Thu, 13 Dec 2012 13:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=229m/U/dVazGDpVxK0u6RkYEnDQQ/7CNwfMK7vxB7Fw=; b=rmUVOIe6Troo0k2eCiywLkvSjcvyh+5pMUp8Egj6p3Ocd/J7JjmsQfQpGxAwoxQ1B7 uJ7XjsTnOh3qEiZQd0nXZ3TQOkYKbGN2ZWA4KLlbyLkG9yPZiaKmeW/gI0loqynFOG6y OtD6NiGYGsNczsMwcDCu9IaDEZwspFS+DySVMfR0nbQucUVoEnf7Qc0yDjZLEwS+Zyz2 SrAwAQQ7y87Nl94VcZU3bpkYJvOPW5O52/ea7SuduLLSXNeKJsiOxAto4b62J1omSvxh +HRwP/c9glJqzuB94WlqLDJkjBWuV+QJxSU/oywaqCBPSPxfWpQn8ED9yGjbXefvalUu mhyA== MIME-Version: 1.0 Received: by 10.60.0.165 with SMTP id 5mr2762059oef.128.1355432750791; Thu, 13 Dec 2012 13:05:50 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 13 Dec 2012 13:05:50 -0800 (PST) In-Reply-To: References: <2279995.En67FjFeZ3@home.alkar.net> Date: Thu, 13 Dec 2012 13:05:50 -0800 Message-ID: Subject: Re: new xorg segfault 11 with KMS From: Garrett Cooper To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: Johannes Dieterich , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:05:51 -0000 On Thu, Dec 13, 2012 at 1:03 PM, Garrett Cooper wrote: > On Thu, Dec 13, 2012 at 12:51 PM, Artyom Mirgorodskiy > wrote: >> I have a similar problem when running firefox > > I don't run into this problem with CURRENT and fluxbox/Firefox on > my Netbook. There's just a nasty misprogrammed region across my screen > that I've been meaning to file a bug about... > My Netbook has a Pineview chipset. Good point -- my ports were last built with gcc before I upgraded recently; haven't tried with clang. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:11:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DBDCF3A for ; Thu, 13 Dec 2012 21:11:07 +0000 (UTC) (envelope-from husyh@hush.com) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 662F48FC1B for ; Thu, 13 Dec 2012 21:11:07 +0000 (UTC) Received: from smtp1.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id A1D282FE84 for ; Thu, 13 Dec 2012 21:11:00 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp1.hushmail.com (Postfix) with ESMTP; Thu, 13 Dec 2012 21:11:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 5395F10E2C8; Thu, 13 Dec 2012 21:11:00 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 13 Dec 2012 22:11:00 +0100 To: "Adrian Chadd" , "John Baldwin" Subject: Re: ath0: unable to attach hardware From: husyh@hush.com In-Reply-To: References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <201212111549.49942.jhb@freebsd.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20121213211100.5395F10E2C8@smtp.hushmail.com> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:11:07 -0000 Hello everyone, I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided: dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd I assumed that "start of bar" is 0xfdee0000 in my case, since dmesg reports ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device 4.0 on pci2 This is what I get: # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4004)/4" | bc` count=1 | hd 00 00 01 00 # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4010)/4" | bc` count=1 | hd 14 00 01 00 Please correct me if my assumption about "start of bar" was wrong and/or I made some other mistake. Also, please don't hesitate to ask me to do anything else that might help you during debugging. Thank you very much for the effort. > >On 11 December 2012 12:49, John Baldwin wrote: > > >> Look, it's up to you to look at more registers if you want to >debug this >> further. PCI says everything is ok, so the ball is in your >court. > >Right, that's why I've asked for those two above registers. > >There are other things that could be wrong - eg, the device may >actually not have reset correctly. > >This isn't the first time that someone's come to me with a "linux >works, freebsd doesn't" for an AR5212 era NIC. ath5k and FreeBSD do >the same thing at probe/attach time. I believe they do the same >thing >during device power-on time too. There's some corner cases where >the >chip doesn't reset right because the BIOS PCI bus reset code does >things in a brain dead manner (eg doing two PCI bus resets back to >back with not enough time in between for the MAC to settle.) > >There may be PCI code differences in how Linux and FreeBSD does >things >like "reset the PCI bus." > > > >Adrian From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:18:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D3BA16F; Thu, 13 Dec 2012 21:18:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id B4FFC8FC13; Thu, 13 Dec 2012 21:18:51 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so1029931wgh.31 for ; Thu, 13 Dec 2012 13:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ckum+wb6dH/BEXJ71nLZrFjkcwG8LyBCrrPhygkHJxw=; b=vlsOR4+r/3crEovKIO8Gu9llUzk8+2bg9thG6FS/VGPE+0GIEBw3hkjDl1vpZU+J8h Hm26gUiuno6I868U9vGA7K6CK/4P7MLiL+yXwAR4N3w6UZB7io/5g3Lj15u7LFXIGe0v WZMsQZ1UyW73PWIye7aysVZoct3Veu3lSIU6Z6VRDrKjCrhWRNgXS6YhK+6bM9YGpPeQ LDWlteBgKkWAXjQmtnbfXFj3XMudb+KsbDeoeZ5Yn79AooC8NeKEQWrpdTJ3rLc6Nn45 hqK2u7qvGyD8EYCQKFBZ57LAwnsMKfleSzT6oMIdjUu9+GCPSJ/Vv2DcZEcisEITVEQg d1WA== MIME-Version: 1.0 Received: by 10.180.88.138 with SMTP id bg10mr5674432wib.13.1355433530595; Thu, 13 Dec 2012 13:18:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Thu, 13 Dec 2012 13:18:50 -0800 (PST) In-Reply-To: <20121213211100.5395F10E2C8@smtp.hushmail.com> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <201212111549.49942.jhb@freebsd.org> <20121213211100.5395F10E2C8@smtp.hushmail.com> Date: Thu, 13 Dec 2012 13:18:50 -0800 X-Google-Sender-Auth: sUOqC8Bgce_sTQKk_8NxN68cIpA Message-ID: Subject: Re: ath0: unable to attach hardware From: Adrian Chadd To: husyh@hush.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:18:52 -0000 On 13 December 2012 13:11, wrote: > Hello everyone, > > I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided: > dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd > > I assumed that "start of bar" is 0xfdee0000 in my case, since dmesg reports > ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device 4.0 on pci2 Yup. > This is what I get: > # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4004)/4" | bc` count=1 | hd > 00 00 01 00 > # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4010)/4" | bc` count=1 | hd > 14 00 01 00 > > Please correct me if my assumption about "start of bar" was wrong and/or I made some other mistake. > Also, please don't hesitate to ask me to do anything else that might help you during debugging. > > Thank you very much for the effort. Hm. Wait, what's the rest of the ath0: output? Adrian From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:36:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F728B77 for ; Thu, 13 Dec 2012 21:36:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF328FC08 for ; Thu, 13 Dec 2012 21:36:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:3197:1202:914b:a0c8] (unknown [IPv6:2001:7b8:3a7:0:3197:1202:914b:a0c8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 618545C5A; Thu, 13 Dec 2012 22:36:25 +0100 (CET) Message-ID: <50CA4A58.7070109@FreeBSD.org> Date: Thu, 13 Dec 2012 22:36:24 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Johannes Dieterich Subject: Re: new xorg segfault 11 with KMS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:36:27 -0000 On 2012-12-13 21:49, Johannes Dieterich wrote: > I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and > WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly > causes the segfault (log attached), gnome survives a bit longer but > starting any bigger application (e.g. firefox) causes it to crash with the > same log. > > I have a Xorg.core file, but since it is without debug symbols the > backtrace makes little sense to me. Please post the backtrace anyway. :-) Or recompile xorg-server with WITH_DEBUG=yes in your environment, and reproduce the crash. From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:48:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA70D278; Thu, 13 Dec 2012 21:48:48 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 700668FC08; Thu, 13 Dec 2012 21:48:47 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so869905vcb.13 for ; Thu, 13 Dec 2012 13:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2WM9mr4QuNPfES6pns9+Mnh44Dz12yjDkvRzmIb68nk=; b=ssBQ/8nlOiPZ36dSSMmMIm/wg36pvJEvbrSEZDte2NUsgoPvIlqd+g2TpnD09gIfsX /iEw21amORpWMRCrHn+Y3Ci3CmqX4GiRYh1KtgNXUnxBeitDgFRyhfYGQlpbMauTRHNs kqvH/meZWX6SiLioQFrKsuoxs+2EI6ROZuxmBltGB+C3de+Oqk/henuzyXKhMpvvjf1S hUpbpi0Rmm3nX1dLkfz80PIinYcQ2NIxKMrWn0hS70a9V+8C1wPgxwDqAWkA4HOT3Vj7 rzMvv4nmpatLErmvkDzIhlG9Vb1TouSrFFKx+NvZsMwcVFzKmlqUtSEo4IzcEYKvenhc 2zTA== Received: by 10.52.98.105 with SMTP id eh9mr5301357vdb.11.1355435327206; Thu, 13 Dec 2012 13:48:47 -0800 (PST) Received: from bresson.poelloepaeae.de (jd-t430s.Princeton.EDU. [128.112.34.82]) by mx.google.com with ESMTPS id x17sm1994150vdi.1.2012.12.13.13.48.46 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 13:48:46 -0800 (PST) Message-ID: <50CA4D3D.3040401@gmail.com> Date: Thu, 13 Dec 2012 16:48:45 -0500 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric , freebsd-current@freebsd.org Subject: Re: new xorg segfault 11 with KMS References: <50CA4A58.7070109@FreeBSD.org> In-Reply-To: <50CA4A58.7070109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:48:49 -0000 On 12/13/12 16:36, Dimitry Andric wrote: > On 2012-12-13 21:49, Johannes Dieterich wrote: >> I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and >> WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly >> causes the segfault (log attached), gnome survives a bit longer but >> starting any bigger application (e.g. firefox) causes it to crash with >> the >> same log. >> >> I have a Xorg.core file, but since it is without debug symbols the >> backtrace makes little sense to me. > > Please post the backtrace anyway. :-) Or recompile xorg-server with > WITH_DEBUG=yes in your environment, and reproduce the crash. Here we go: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Core was generated by `Xorg'. Program terminated with signal 6, Aborted. #0 0x0000000802c4520a in ?? () (gdb) bt #0 0x0000000802c4520a in ?? () #1 0x0000000802cf72bc in ?? () #2 0x0000000802cf85ca in ?? () #3 0x00000000007cdd5c in ?? () #4 0xffffffdf00000000 in ?? () #5 0xffffffffffffffff in ?? () #6 0x00000000ffffffff in ?? () #7 0x0000000000575f06 in ?? () #8 0x00007fffffffce50 in ?? () #9 0x0000000000472c9e in ?? () #10 0x00007fffffffce60 in ?? () #11 0x000000000047e034 in ?? () #12 0x00007fffffffce70 in ?? () #13 0x00000000004704ed in ?? () #14 0x00007fffffffcf50 in ?? () #15 0x000000000046fd26 in ?? () #16 0x0000000000003246 in ?? () #17 0x000000000000000b in ?? () #18 0x0000000802f31a10 in ?? () #19 0xfffffffffffff801 in ?? () #20 0x0101010101010101 in ?? () #21 0x8080808080808080 in ?? () #22 0xffffffffffffffff in ?? () #23 0x0000000000000001 in ?? () #24 0x6e7dec389dd25e4d in ?? () #25 0x0000000802c60f9e in ?? () #26 0x0000000802f31a10 in ?? () #27 0x0000000802f31a10 in ?? () #28 0xffffffffffffffff in ?? () #29 0x000000000000000b in ?? () #30 0x00007fffffffcf50 in ?? () #31 0x0000000802c19662 in ?? () #32 0x0000000000000006 in ?? () #33 0x0000000000470e50 in ?? () #34 0x000000000000000b in ?? () #35 0x00007fffffffd730 in ?? () #36 0x6e7dec389dd25e4d in ?? () #37 0x000000000000000b in ?? () #38 0x0000003000000018 in ?? () #39 0x00007fffffffcf60 in ?? () ---Type to continue, or q to quit--- #40 0x00007fffffffce80 in ?? () #41 0x000000000000000b in ?? () #42 0x00007fffffffcf70 in ?? () #43 0x0000000000470ee3 in ?? () #44 0x00007fffffffd358 in ?? () #45 0x00007fffffffd3c0 in ?? () #46 0x00007fffffffd330 in ?? () #47 0x00000008029ca2e6 in ?? () #48 0x0000000000000000 in ?? () I also rebuild xorg with debug enabled. Interestingly, I cannot reproduce the crash anymore. Either I forgot to rebuild something (seems unlikely) or the crash has to do with optimizations or flags not present in a debug build. Hope this helps. Johannes From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:53:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 676CD419; Thu, 13 Dec 2012 21:53:45 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 05A7B8FC13; Thu, 13 Dec 2012 21:53:44 +0000 (UTC) Received: from [192.168.0.2] (cpc39-cmbg15-2-0-cust69.5-4.cable.virginmedia.com [81.101.138.70]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id qBDLreTa098601 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 21:53:43 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: new xorg segfault 11 with KMS Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50CA4D3D.3040401@gmail.com> Date: Thu, 13 Dec 2012 21:53:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <07938D0C-15C4-430F-9E1F-828DB01CDFB7@FreeBSD.org> References: <50CA4A58.7070109@FreeBSD.org> <50CA4D3D.3040401@gmail.com> To: Johannes Dieterich X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:53:45 -0000 On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: > GNU gdb 6.1.1 [FreeBSD] You might try with gdb 7.x from ports. gdb 6.1.1 from the base system = doesn't do a good job of understanding the newer version of DWARF that = clang emits. David= From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:58:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97F6558A; Thu, 13 Dec 2012 21:58:56 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 114938FC0A; Thu, 13 Dec 2012 21:58:56 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 30E1C4000C; Thu, 13 Dec 2012 22:58:54 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 26B3A4000A; Thu, 13 Dec 2012 22:58:54 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id AE4B440009; Thu, 13 Dec 2012 22:58:53 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMpgd221Cz8hVn; Thu, 13 Dec 2012 22:58:53 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id 8wx0Sd5453CC; Thu, 13 Dec 2012 22:58:51 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMpgb15VDz8hVm; Thu, 13 Dec 2012 22:58:51 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [10.32.0.4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3YMpgb0SWNz9Ctj; Thu, 13 Dec 2012 22:58:51 +0100 (CET) Message-ID: <50CA4F99.3060106@freebsd.org> Date: Thu, 13 Dec 2012 22:58:49 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Johannes Dieterich Subject: Re: new xorg segfault 11 with KMS References: <50CA4A58.7070109@FreeBSD.org> <50CA4D3D.3040401@gmail.com> In-Reply-To: <50CA4D3D.3040401@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 21:58:56 -0000 On 12/13/12 22:48, Johannes Dieterich wrote: > On 12/13/12 16:36, Dimitry Andric wrote: >> On 2012-12-13 21:49, Johannes Dieterich wrote: >>> I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and >>> WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly >>> causes the segfault (log attached), gnome survives a bit longer but >>> starting any bigger application (e.g. firefox) causes it to crash with >>> the >>> same log. >>> >>> I have a Xorg.core file, but since it is without debug symbols the >>> backtrace makes little sense to me. >> >> Please post the backtrace anyway. :-) Or recompile xorg-server with >> WITH_DEBUG=yes in your environment, and reproduce the crash. > Here we go: > > I also rebuild xorg with debug enabled. Interestingly, I cannot > reproduce the crash anymore. Either I forgot to rebuild something (seems > unlikely) or the crash has to do with optimizations or flags not present > in a debug build. This is not unlikely. There are probably places in the X codebase which depends on gcc specific behavior, or undefined behavior, by accident or by chance. Regards -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:03:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38CB8970; Thu, 13 Dec 2012 22:03:54 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 742EA8FC0C; Thu, 13 Dec 2012 22:03:52 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so888386vcb.13 for ; Thu, 13 Dec 2012 14:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4Z5VwYOgWxEVN1b5edcKQkDbwvPRqwwVuHXKQEC1Tv4=; b=GzSZq98HtMA52h2T4LHev7H1yJ6Sfg4MNKtIQJLUfb79HBmV/FHjye75xGufrF5k2t 92RIwoiEbZl7vgQAMIV5Xl2dwwM34EPvVuUl/JN0OyA1E4NbV5ZD+/R4kI6jQox/HItF OuotyekXz/7BTgMf9zoC4xPbSYaInTyasljfkyzxBeSxY1BRSHmXhB/zMP13pR4VguNM BdpwPt38XVV6DSnyuM2naBSwZ9TrO8UAZAdbflxJu2pAmuS3+m/neKNAhTRxnHWH4vAY SBuQ+s7WZQXB4HQGsTVDchwh3p9poC5KQt7e9P5r+aRDXzss8uJGgIrfdQb3ZFP1XG/e Tvog== Received: by 10.58.85.134 with SMTP id h6mr6360355vez.18.1355436232139; Thu, 13 Dec 2012 14:03:52 -0800 (PST) Received: from bresson.poelloepaeae.de (jd-t430s.Princeton.EDU. [128.112.34.82]) by mx.google.com with ESMTPS id p10sm2006959vdh.4.2012.12.13.14.03.51 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:03:51 -0800 (PST) Message-ID: <50CA50C6.2080501@gmail.com> Date: Thu, 13 Dec 2012 17:03:50 -0500 From: Johannes Dieterich User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Chisnall Subject: Re: new xorg segfault 11 with KMS References: <50CA4A58.7070109@FreeBSD.org> <50CA4D3D.3040401@gmail.com> <07938D0C-15C4-430F-9E1F-828DB01CDFB7@FreeBSD.org> In-Reply-To: <07938D0C-15C4-430F-9E1F-828DB01CDFB7@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:03:54 -0000 On 12/13/12 16:53, David Chisnall wrote: > On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: > >> GNU gdb 6.1.1 [FreeBSD] > > You might try with gdb 7.x from ports. gdb 6.1.1 from the base system doesn't do a good job of understanding the newer version of DWARF that clang emits. Did that but it doesn't change much: GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd10.0". For bug reporting instructions, please see: . [New process 100714] Core was generated by `Xorg'. Program terminated with signal 6, Aborted. #0 0x0000000802c4520a in ?? () (gdb) bt #0 0x0000000802c4520a in ?? () #1 0x0000000802cf72bc in ?? () #2 0x0000000802cf85ca in ?? () #3 0x00000000007cdd5c in ?? () #4 0xffffffdf00000000 in ?? () #5 0xffffffffffffffff in ?? () #6 0x00000000ffffffff in ?? () #7 0x0000000000575f06 in ?? () #8 0x00007fffffffce50 in ?? () #9 0x0000000000472c9e in ?? () #10 0x00007fffffffce60 in ?? () #11 0x000000000047e034 in ?? () #12 0x00007fffffffce70 in ?? () #13 0x00000000004704ed in ?? () #14 0x00007fffffffcf50 in ?? () #15 0x000000000046fd26 in ?? () #16 0x0000000000003246 in ?? () #17 0x000000000000000b in ?? () #18 0x0000000802f31a10 in ?? () #19 0xfffffffffffff801 in ?? () #20 0x0101010101010101 in ?? () #21 0x8080808080808080 in ?? () #22 0xffffffffffffffff in ?? () #23 0x0000000000000001 in ?? () #24 0x6e7dec389dd25e4d in ?? () #25 0x0000000802c60f9e in ?? () #26 0x0000000802f31a10 in ?? () #27 0x0000000802f31a10 in ?? () #28 0xffffffffffffffff in ?? () #29 0x000000000000000b in ?? () #30 0x00007fffffffcf50 in ?? () #31 0x0000000802c19662 in ?? () #32 0x0000000000000006 in ?? () #33 0x0000000000470e50 in ?? () #34 0x000000000000000b in ?? () #35 0x00007fffffffd730 in ?? () #36 0x6e7dec389dd25e4d in ?? () #37 0x000000000000000b in ?? () #38 0x0000003000000018 in ?? () #39 0x00007fffffffcf60 in ?? () ---Type to continue, or q to quit--- #40 0x00007fffffffce80 in ?? () #41 0x000000000000000b in ?? () #42 0x00007fffffffcf70 in ?? () #43 0x0000000000470ee3 in ?? () #44 0x00007fffffffd358 in ?? () #45 0x00007fffffffd3c0 in ?? () #46 0x00007fffffffd330 in ?? () #47 0x00000008029ca2e6 in ?? () #48 0x0000000000000000 in ?? () I guess marking xorg-server to require USE_GCC=4.2+ would be a reasonable workaround for the time being? Best Johannes From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:40:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB0D39B8; Thu, 13 Dec 2012 22:40:01 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 922F08FC14; Thu, 13 Dec 2012 22:40:01 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 4ACE8E604A; Thu, 13 Dec 2012 17:40:00 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: new xorg segfault 11 with KMS Date: Fri, 14 Dec 2012 00:39:36 +0200 Message-ID: <150606223.2PmcIlS4ld@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: <50CA4A58.7070109@FreeBSD.org> References: <50CA4A58.7070109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Johannes Dieterich , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:40:01 -0000 I have recompile xorg-server with WITH_DEBUG=yes and did not get crash On Thursday 13 December 2012 22:36:24 Dimitry Andric wrote: > On 2012-12-13 21:49, Johannes Dieterich wrote: > > I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and > > WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly > > causes the segfault (log attached), gnome survives a bit longer but > > starting any bigger application (e.g. firefox) causes it to crash with the > > same log. > > > > I have a Xorg.core file, but since it is without debug symbols the > > backtrace makes little sense to me. > > Please post the backtrace anyway. :-) Or recompile xorg-server with > WITH_DEBUG=yes in your environment, and reproduce the crash. > _______________________________________________ > 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" -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:49:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 155C2CC6; Thu, 13 Dec 2012 22:49:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 875F08FC0A; Thu, 13 Dec 2012 22:49:27 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2888007oag.13 for ; Thu, 13 Dec 2012 14:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CzqNvgdAAQkLBrBZS4cS3q7nzJcKRsoxNJWDG9Vac04=; b=zNFwbC9USSNscEBwrcYuIX+RGHmF+F1KFHAGdfz1cyTRTEWD26ROW2SrH17tl1gTbn GCYAizPbr8hlJBs6e+C2s4nz1tioxQELZupQw4r1FThDgicQqrlmU9Hk6Wg/kiKWfNLj 6xsnmhxqV1zCKWQnwXy+n5h+VHh6iHu3w/xxNDkOM3rFQ3RNQpVlTw7Y62q6cWbDkEdd Tm3y0NJKz3d9ZNhbTEjI6ypH4bMXLmkCS83oQyz+DdlO0sa5g0pAtRdrmP39EC34gyCM JYepyVE9T09lNP20nRCQtXf1N8u9N+5OlEFFJPjUZYumVtDGrQtLl/g3uQ14XN9NYpRR tSvg== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr2972754obc.83.1355438966744; Thu, 13 Dec 2012 14:49:26 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 13 Dec 2012 14:49:26 -0800 (PST) In-Reply-To: <50C9BA19.4040504@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> <50C9BA19.4040504@FreeBSD.org> Date: Thu, 13 Dec 2012 14:49:26 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-zfs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:49:31 -0000 On Thu, Dec 13, 2012 at 3:20 AM, Andriy Gapon wrote: ... > One thing that I recommend to all ZFS users is to make use of boot environments. > They are very easy, very convenient and may save a lot of trouble. > Use either any of the tool available in ports (e.g. sysutils/beadm) or just "do > boot environments" in an ad hoc fashion: snapshot and clone your current / known > good boot+root filesystem and you have a safe environment to fall back to. Looks interesting (this page has a slightly more in-depth description of what beadm tries to achieve for the layman like me that doesn't use *Solaris: http://www.linuxquestions.org/questions/*bsd-17/howto-zfs-madness-beadm-on-freebsd-4175412036/ ). > Proper zdb -l usage was described in the "HEADSUP" posting. > It's also available in zdb(8). zdb -l should be used with disks/partitions/etc, > not with pool names. I realized that mistake after the fact :/. >> I'm running into the same behavior before and after I upgraded sac/sac2. >> My git branch is a lightly modified version of FreeBSD, but >> doesn't contain any ZFS specific changes (I can point you to it if you >> like to look at it). >> Would appreciate some pointers on what to do next. > > Try to get a working environment (using livecd, another disk, backups, etc), try > to follow the original instructions. Ok. That's sort of what I'm trying. Given that I didn't do a *ton* of customizations, I might just tar up the root pool's contents and basic configuration, wipe it out, and try creating a new one from scratch and restore the contents after the fact. However, thinking back I could turn on terse debugging in ZFS after building it with that (I've done it once before -- forgot about it until now). That would probably be the best way to get the official "story" from ZFS as to what it thinks is going south when importing the pool. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:51:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D4D577; Thu, 13 Dec 2012 22:51:26 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5938FC0A; Thu, 13 Dec 2012 22:51:26 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2889690oag.13 for ; Thu, 13 Dec 2012 14:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GJMjfvkvCO8SR9WVddCEtEbCCnmrft8Vqb8AcpyQVWU=; b=uJY3xS2A+ulPV3v0+oq7TPTc6okY6jIVYVq7AWsIMAOeSxqnXqF/dcTdcgMxvgZywl SegAFYZFR6mXUouPxMlemdT8CqsxcvGE0e5XQmO/OaJo7FnIdnf0xVbEwLLiq3AKrOYK /qPL1vQZpguutAwqw4hnq0aHR8TX9UesPpZnrWk9eDEQvHxlNjGlmCTIoBh3aoU3V0g0 GOrzmPjlRJM91IrVDmFJwnvxtZa57OFAcNyDFwP8WC1iq6vwO+BMetMSMm/y23MELgNr I6EafA5NkJ4GuzHFkv8RCFeoy3EtiCMB+AgoTA7D5VCev+hiizMrIdvoph+YskxUg7IA o63Q== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr2976524obc.83.1355439085841; Thu, 13 Dec 2012 14:51:25 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 13 Dec 2012 14:51:25 -0800 (PST) In-Reply-To: <50C9BAFC.4020804@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> <50C9BAFC.4020804@FreeBSD.org> Date: Thu, 13 Dec 2012 14:51:25 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:51:26 -0000 On Thu, Dec 13, 2012 at 3:24 AM, Andriy Gapon wrote: ... > This sounds messy, not sure if it has any informative value. > I think I've seen something like this after some reason ZFS import from upsteam > when my kernel and userland were out of sync. > Do you do a full boot from the livecd? Or do you boot your kernel but then mount > userland from the cd? > In any case, not sure if this is relevan to your main trouble. I tried booting from a custom kernel, ran into the mountroot prompt and then chose cd9660:/dev/cd0 instead of zfs:root (my root pool's name). ... > bootfs property should not better. Multi-pool configurations has been tested > before the commit. That's what I thought, but I was unsure... Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:56:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78311236; Thu, 13 Dec 2012 22:56:42 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 828BF8FC1E; Thu, 13 Dec 2012 22:56:41 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so2254817lah.13 for ; Thu, 13 Dec 2012 14:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R4lRhrnh7rGoT+IHbVPBZPnoeEc+b+/H3I68n8J9B+4=; b=TLR7xd8XvF6mcEWu+V5H4U8sU9N8hAupqTBRRctiYE6pgjHOGCEaHZxmuWAgxalHVc TmNLVCOr0N+dpcxNpkrymdY/U/EHh69vTBRHelUg6JQmi+2d7h2fAnYjRrSNgF8EWqnJ udoG0JKVO0prreCr+Z8ZNXW6NN8KsS44zCl604dj34ahwmTjgZIJ/wVKNbXGonzvikZW uKWKiyKe3ccmn16WCE5l6Sik/ejGrjoS/bz4BTobVeDyZdGsGo4T3Yilg5rhKW6bH2er 8TjnxEXQjsquNP0vN6jtO9S/+Of2vAkXweFMsAaWzPn+IfEZdPONAKCph7VEt2lXI09n 6D5Q== MIME-Version: 1.0 Received: by 10.152.103.19 with SMTP id fs19mr759400lab.15.1355439400025; Thu, 13 Dec 2012 14:56:40 -0800 (PST) Received: by 10.114.81.40 with HTTP; Thu, 13 Dec 2012 14:56:39 -0800 (PST) In-Reply-To: References: <50B6598B.20200@FreeBSD.org> <50C9BA19.4040504@FreeBSD.org> Date: Thu, 13 Dec 2012 14:56:39 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Freddie Cash To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , Andriy Gapon , freebsd-zfs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:56:42 -0000 On Thu, Dec 13, 2012 at 2:49 PM, Garrett Cooper wrote: > On Thu, Dec 13, 2012 at 3:20 AM, Andriy Gapon wrote: > > ... > > > One thing that I recommend to all ZFS users is to make use of boot > environments. > > They are very easy, very convenient and may save a lot of trouble. > > Use either any of the tool available in ports (e.g. sysutils/beadm) or > just "do > > boot environments" in an ad hoc fashion: snapshot and clone your current > / known > > good boot+root filesystem and you have a safe environment to fall back > to. > > Looks interesting (this page has a slightly more in-depth description > of what beadm tries to achieve for the layman like me that doesn't use > *Solaris: > http://www.linuxquestions.org/questions/*bsd-17/howto-zfs-madness-beadm-on-freebsd-4175412036/ > ). > > You could at least point to the FreeBSD Forums version of that post. :) https://forums.freebsd.org/showthread.php?t=31662 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 23:02:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64CC03E9; Thu, 13 Dec 2012 23:02:17 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E524C8FC13; Thu, 13 Dec 2012 23:02:16 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so953129vcb.13 for ; Thu, 13 Dec 2012 15:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2WhDXU9I6UeHKeVCIgrfRRTIev7490qQixTgE47M/bw=; b=BS/wgXFoi37wQvZkZeWxJtst66S31xgvSuuEIOWZ0JFlh7LLc+vjHHiBeQSvTY+VI9 Whlr31Owg3ejGWnpmt7GkL4kyGPDID6Grx8oo1Y3GsgqTWjKpVbpu2/WGwWrzX8yoFxY nTSoWrUZ6NQ5xZ5EvIGEPaF6ZdNUhWkHNdqIH1Ud62tgVUzEc1+dk6WQy5GWllu4MLnP FUd7BDqp0RLoQs81Pr72YOqaOhhpvvB11JgQgHqD4YOxu5AtzmPCKT85ldd+WN/c5Icu MTk21U9YiDPcXTRTgxrtk7dBFXUoG3d8Tfez7n7+zQnPFkObZ7MTDIX/2G2DBlP7deLC Q99g== MIME-Version: 1.0 Received: by 10.58.65.105 with SMTP id w9mr6282155ves.54.1355439735705; Thu, 13 Dec 2012 15:02:15 -0800 (PST) Received: by 10.58.209.163 with HTTP; Thu, 13 Dec 2012 15:02:15 -0800 (PST) In-Reply-To: <1355408039.87661.491.camel@revolution.hippie.lan> References: <1355331231.87661.461.camel@revolution.hippie.lan> <1355408039.87661.491.camel@revolution.hippie.lan> Date: Fri, 14 Dec 2012 01:02:15 +0200 Message-ID: Subject: Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory. From: Kimmo Paasiala To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 23:02:17 -0000 On Thu, Dec 13, 2012 at 4:13 PM, Ian Lepore wrote: > On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote: >> On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore >> wrote: >> > On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote: >> >> Hello, >> >> >> >> My 9-STABLE buildworld broke in a very inexplicable way, I was >> >> getting an error on /usr/src/include/osreldate.h that I couldn't >> >> figure out until I started looking at the sys/conf/newvers.sh and what >> >> it does. It turned out that the thing that broke my buildworld was >> >> having .git directory at the root directory of the system because I >> >> recently started using GIT to track the configuration files. >> >> >> >> I added some debug echos to the newvers.sh and I found out it's >> >> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set >> >> the gitdir to /.git and that seems to break the logic in newvers.sh. >> >> >> >> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source >> >> tree (/usr/src/sys default)? >> >> >> >> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in >> >> newvers.sh: >> >> >> >> SYSDIR=$(dirname $0)/.. >> >> >> >> $0 is actually /bin/sh and not the path to newver.sh because the >> >> newvers.sh is sourced by the Makefile in /usr/src/include instead of >> >> executing it: >> >> >> >> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \ >> >> ${.CURDIR}/Makefile >> >> @${ECHO} creating osreldate.h from newvers.sh >> >> @MAKE=${MAKE}; \ >> >> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ >> >> . ${.CURDIR}/../sys/conf/newvers.sh; \ >> >> >> >> Now the question is how to fix this? >> >> >> >> -Kimmo >> > >> > Perhaps it could be handled similar to PARAMFILE, something like this in >> > the makefile: >> > >> > PARAMFILE=${.CURDIR}/../sys/sys/param.h; \ >> > SYSDIR=${.CURDIR}/../sys; \ >> > . ${.CURDIR}/../sys/conf/newvers.sh; \ >> > >> > I'm not sure if newvers.sh needs to work in ways that don't involve >> > being invoked from that makefile rule, so to be safe it could have >> > default handling, something like: >> > >> > : ${SYSDIR:=$(dirname $0)/..} >> > >> > -- Ian >> > >> > >> >> Thanks, that works. Should I file a PR about this? >> >> -Kimmo > > I think that would probably be a good idea, since no committer has > chimed in on this thread saying they're about to commit a fix. > > -- Ian > > Submitted as misc/174422. -Kimmo From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 23:02:41 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E30775DF; Thu, 13 Dec 2012 23:02:41 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9128FC0A; Thu, 13 Dec 2012 23:02:41 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3FA0640009; Fri, 14 Dec 2012 00:02:40 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 33F9A4000A; Fri, 14 Dec 2012 00:02:40 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 4BA4840009; Fri, 14 Dec 2012 00:02:39 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMr5B6ZPQz8hVn; Fri, 14 Dec 2012 00:02:38 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id 84jaySTqP_Ao; Fri, 14 Dec 2012 00:02:36 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMr586J7Bz8hVm; Fri, 14 Dec 2012 00:02:36 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [10.32.0.4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3YMr584HpZz9Ctj; Fri, 14 Dec 2012 00:02:36 +0100 (CET) Message-ID: <50CA5E8C.3030803@freebsd.org> Date: Fri, 14 Dec 2012 00:02:36 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Johannes Dieterich Subject: Re: new xorg segfault 11 with KMS References: <50CA4A58.7070109@FreeBSD.org> <50CA4D3D.3040401@gmail.com> <07938D0C-15C4-430F-9E1F-828DB01CDFB7@FreeBSD.org> <50CA50C6.2080501@gmail.com> In-Reply-To: <50CA50C6.2080501@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dimitry Andric , freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 23:02:42 -0000 On 12/13/12 23:03, Johannes Dieterich wrote: > On 12/13/12 16:53, David Chisnall wrote: >> On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: >> >>> GNU gdb 6.1.1 [FreeBSD] >> >> You might try with gdb 7.x from ports. gdb 6.1.1 from the base system >> doesn't do a good job of understanding the newer version of DWARF that >> clang emits. > Did that but it doesn't change much: > > I guess marking xorg-server to require USE_GCC=4.2+ would be a > reasonable workaround for the time being? > I have a shot in the dark before we try that, I just need to finish the patch. I'll let you all know when it's ready. Regards -- Niclas -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 22:37:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4DC37CD for ; Thu, 13 Dec 2012 22:37:25 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB158FC08 for ; Thu, 13 Dec 2012 22:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=/k82+ov/OFG5vUitcJsagNQUFaBay5RdYidLHngL2y0=; b=NbmCXYXiO6grfVPB7MEVCg17MkplAX0FAAQ44KSdMecfiiaKWIVC8jlzyyEQs6Wz/y7aRzZIT8edEHnfVDh5mxUTSuE5eOTwswlKtW5d24Ht2fnBw87rQ8w1dVrTznxAabAlqGoePhO3IdYilaRCdLPMCs2ugDKVjcPEDlxgaI8=; Received: from iglou3.iglou.com ([192.107.41.6]:41273 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TjH4r-0006oc-3W by authid with igloumta_auth for freebsd-current@freebsd.org; Thu, 13 Dec 2012 17:16:25 -0500 Received: from shell1.iglou.com ([192.107.41.17]:43541 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TjH4q-0002vX-OD for freebsd-current@freebsd.org; Thu, 13 Dec 2012 17:16:24 -0500 Date: Thu, 13 Dec 2012 17:16:24 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-current@freebsd.org Subject: fifolog_writer Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Thu, 13 Dec 2012 23:03:57 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 22:37:25 -0000 Yesterday I updated source and when running installkernel it complained about no auditdistd user, so I ran 'mergemaster -p'. Then the kernel installed and I rebooted. Before running installworld I ran 'mergemaster -p' again and this time, if I recall correctly, it produced a new group. I ran installworld and am stuck here: ===> /usr.sbin/fifolog/fifolog_writer (install) This is amd64 and has been stuck like this for 9 hours. Any suggestions? Thank you, Darrel From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 23:12:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BD92D13; Thu, 13 Dec 2012 23:12:49 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B163C8FC08; Thu, 13 Dec 2012 23:12:48 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so3164676vba.13 for ; Thu, 13 Dec 2012 15:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=xQGObPxuA86pQu5j39tFpy4e/mQsJVE8nxbrZsItQGg=; b=nNTy79GvhA9M9wW+6vNcT/sdjsVHcm2kMjAK7MlFuTxFmZCuKomXMnil9ao+UMIeyQ +np99VymQus95d0zWRhQ2TuM6INKPJeAWADbFQEI0FLyx6ZhdP3Pm/lAr4v7q60LRY9c QiA31SHpjywwCOtKzaVuVIxSjPZ35+Oid7wK+uR0QDaMBULiKbH1sgXiP29Wt3tLA07b 5uTMiCZUWsDBTYmwO6XTw4ShhEQkgWLmEdTdG+K+hV5JUbgdla652RH3XcNa5tTE/Jam ZMaH44olf1re92kE01KLVSOC22wUybW/3I5rwkNDX5PJVhN+k2Uf+VX3QMugNhinQ6Ts 6t9A== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr5334048vdu.99.1355440367354; Thu, 13 Dec 2012 15:12:47 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Thu, 13 Dec 2012 15:12:47 -0800 (PST) Date: Fri, 14 Dec 2012 00:12:47 +0100 X-Google-Sender-Auth: DHruZbByEWtmhyCCkhKsl9v0H58 Message-ID: Subject: [RFC/RFT] calloutng From: Davide Italiano To: freebsd-current , freebsd-arch@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 23:12:49 -0000 Hi. This patch takes callout(9) and redesign the KPI and the implementation. The main objective of this work is making the subsystem tickless. In the last several years, this possibility has been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), but until now noone really implemented that. If you want a complete history of what has been done in the last months you can check the calloutng project repository http://svnweb.freebsd.org/base/projects/calloutng/ For lazy people, here's a summary: 1) callout(9) is not anymore constrained to the resolution a periodic "hz" clock can give. In order to do that, the eventtimers(4) subsystem is used as backend. 2) Conversely from what discussed in past, we maintained the callwheel as underlying data structure for keeping track of the outstading timeouts. This choice has a couple of advantages, in particular we can still take benefits from the O(1) average complexity of the wheel for all the operations. Also, we thought the code duplication that would arise from the use of a two-staged backend for callout (e.g. use wheel for coarse resolution event and another data structure, such as an heap for high resolution events), is unacceptable. In fact, as long as callout gained the ability to migrate from a cpu to another having a double backend would mean doubling the code for the migration path. 3) A way to dispatch interrupts from hardware interrupt context has been implemented, using special callout flag. This has limited applicability, but avoid the dispatching of a SWI thread for handling specific callouts, avoiding the wake up of another CPU for processing and a (relatively useless) context switch 4) As long as new callout mechanism deals with bintime and not anymore with ticks, time is specified as absolute and not relative anymore. In order to get current time binuptime() or getbinuptime() is used, and a sysctl is introduced to selectively choose the function to use, based on a precision threshold. 5) A mechanism for specifying precision tolerance has been implemented. The callout processing mechanism has been adapted and the callout data structure augmented so that the codepath can take advantage and aggregate events which overlap in time. The new proposed KPI for callout is the following: callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., int f= lags) where =91time=92 argument represets the time at which the callout should fire, =91pr=92 represents the precision tolerance expressed as an absolute value, and =91flags=92, which could be used to specify new features, i.e. for now, the possibility to run the callout from fast interrupt context. The old KPI has been extended introducing the callout_reset_flags() function, which is the same of callout_reset*(), but takes an additional argument =91int flags=92 that can be used in the same fashion of the =91flags=92 argument for the new KPI. Using the =91flags=92 consumer= s can also specify relative precision tolerance in terms of power-of-two portion of the timeout passed as ticks. Using this strategy, the new precision mechanism can be used for the existing services without major modifications. Some consumers have been ported to the new KPI, in particular nanosleep(), poll(), select(), because they take immediate advantage from the arbitrary precision offered by the new infrastructure. For some statistics about the outcome of the conversion to the new service, please refer to the end of this e-mail: http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html We didn't measure any significant performance regressions with hwmpc(4), using some benckmarks programs: http://people.freebsd.org/~davide/poll_test/poll_test.c http://people.freebsd.org/~mav/testsleep.c http://people.freebsd.org/~mav/testidle.c We tested the code on amd64, MIPS and arm. Any kind of testing or comment would be really appreciated. The full diff of the work against HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff If noone have objections, we plan to merge the repository to HEAD in a week or so. Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 23:30:59 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5138E410; Thu, 13 Dec 2012 23:30:59 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id A0C5F8FC12; Thu, 13 Dec 2012 23:30:58 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EBC0440009; Fri, 14 Dec 2012 00:30:57 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E0AA34000A; Fri, 14 Dec 2012 00:30:57 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A5AD540009; Fri, 14 Dec 2012 00:30:56 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMrjp4lcQz8hVn; Fri, 14 Dec 2012 00:30:54 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id yDNCrqvDdxOY; Fri, 14 Dec 2012 00:30:52 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3YMrjm2lP8z8hVm; Fri, 14 Dec 2012 00:30:52 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [10.32.0.4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3YMrjm24wBz9Ctj; Fri, 14 Dec 2012 00:30:52 +0100 (CET) Message-ID: <50CA652C.5010101@freebsd.org> Date: Fri, 14 Dec 2012 00:30:52 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Johannes Dieterich Subject: Re: new xorg segfault 11 with KMS References: <50CA4A58.7070109@FreeBSD.org> <50CA4D3D.3040401@gmail.com> <07938D0C-15C4-430F-9E1F-828DB01CDFB7@FreeBSD.org> <50CA50C6.2080501@gmail.com> In-Reply-To: <50CA50C6.2080501@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------050607000409020003060108" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dimitry Andric , freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 23:30:59 -0000 This is a multi-part message in MIME format. --------------050607000409020003060108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can you please try the attached patch, against x11-servers/xorg-server. Apply it and recompile xorg-server with normal flags (that is, no debugging) and let me and the list know the result when starting X. Regards! -- Niclas Zeising --------------050607000409020003060108 Content-Type: text/x-patch; name="xorg-server.clangfix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xorg-server.clangfix.diff" Index: x11-servers/xorg-server/Makefile =================================================================== --- x11-servers/xorg-server/Makefile (revision 308805) +++ x11-servers/xorg-server/Makefile (working copy) @@ -29,7 +29,8 @@ XORG_REVISION= 1 PLIST_SUB+= OLD="@comment " NEW="" EXTRA_PATCHES+= ${FILESDIR}/extra-hw_dmx_glxProxy_compsize.h \ - ${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h + ${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h \ + ${FILESDIR}/extra-clang .else XORG_VERSION= 1.7.7 XORG_REVISION= 6 Index: x11-servers/xorg-server/files/extra-clang =================================================================== --- x11-servers/xorg-server/files/extra-clang (revision 0) +++ x11-servers/xorg-server/files/extra-clang (working copy) @@ -0,0 +1,53 @@ +--- hw/xfree86/common/xf86Xinput.c.orig 2012-12-13 23:58:55.673738569 +0100 ++++ hw/xfree86/common/xf86Xinput.c 2012-12-13 23:59:52.528738525 +0100 +@@ -479,7 +479,7 @@ + MatchAttrToken(const char *attr, struct list *patterns, + int (*compare)(const char *attr, const char *pattern)) + { +- const xf86MatchGroup *group; ++ const xf86MatchGroup *group = NULL; + + /* If there are no patterns, accept the match */ + if (list_is_empty(patterns)) +--- hw/xfree86/parser/InputClass.c.orig 2012-12-14 00:03:07.149734651 +0100 ++++ hw/xfree86/parser/InputClass.c 2012-12-14 00:04:09.522735172 +0100 +@@ -338,7 +338,8 @@ + XF86ConfInputClassPtr prev; + + while (ptr) { +- xf86MatchGroup *group, *next; ++ xf86MatchGroup *group = NULL; ++ xf86MatchGroup *next; + char **list; + + TestFree(ptr->identifier); +--- hw/xfree86/dri2/dri2.c.orig 2012-12-14 00:06:39.680738243 +0100 ++++ hw/xfree86/dri2/dri2.c 2012-12-14 00:08:14.310729622 +0100 +@@ -201,7 +201,7 @@ + static DRI2DrawableRefPtr + DRI2LookupDrawableRef(DRI2DrawablePtr pPriv, XID id) + { +- DRI2DrawableRefPtr ref; ++ DRI2DrawableRefPtr ref = NULL; + + list_for_each_entry(ref, &pPriv->reference_list, link) { + if (ref->id == id) +@@ -267,7 +267,8 @@ + { + DRI2DrawablePtr pPriv = p; + DRI2ScreenPtr ds = pPriv->dri2_screen; +- DRI2DrawableRefPtr ref, next; ++ DRI2DrawableRefPtr ref = NULL; ++ DRI2DrawableRefPtr next; + WindowPtr pWin; + PixmapPtr pPixmap; + DrawablePtr pDraw; +@@ -534,7 +535,7 @@ + DRI2InvalidateDrawable(DrawablePtr pDraw) + { + DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw); +- DRI2DrawableRefPtr ref; ++ DRI2DrawableRefPtr ref = NULL; + + if (!pPriv) + return; --------------050607000409020003060108-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 23:51:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1A7289D; Thu, 13 Dec 2012 23:51:51 +0000 (UTC) (envelope-from artyom@ijminteractive.net) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id 662358FC13; Thu, 13 Dec 2012 23:51:51 +0000 (UTC) Received: from home.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 79DCFE604A; Thu, 13 Dec 2012 18:51:50 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: new xorg segfault 11 with KMS Date: Fri, 14 Dec 2012 01:51:26 +0200 Message-ID: <1698382.9Eyt0BnUlN@home.alkar.net> User-Agent: KMail/4.8.4 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) In-Reply-To: <50CA652C.5010101@freebsd.org> References: <50CA50C6.2080501@gmail.com> <50CA652C.5010101@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Johannes Dieterich , David Chisnall , freebsd-current@freebsd.org, Dimitry Andric , Niclas Zeising X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Dec 2012 23:51:51 -0000 This patch work for me. Thanks. On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: > Can you please try the attached patch, against x11-servers/xorg-server. > Apply it and recompile xorg-server with normal flags (that is, no > debugging) and let me and the list know the result when starting X. > Regards! > -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 00:24:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E822C2CD; Fri, 14 Dec 2012 00:24:27 +0000 (UTC) (envelope-from dieterich.joh@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 710518FC12; Fri, 14 Dec 2012 00:24:27 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2961229oag.13 for ; Thu, 13 Dec 2012 16:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7zjEpMUy/MjwgPAuu6macLxQCxo+h3kM2LbOJfot9H8=; b=QP9oJG2YN941+J1YS98+thqbx3n0RK0vjzYPWD9WBDOBJBmDxf8gmokjpLC+8wvj+o v5GXRLPq9dLV0gf/ApOPuS9M35TGEVCztsUmzyUSEBQWDgyc2RayBm20h9gHrdYtD0tb I/7wxS8PDNBcKfZ/aFE7lPpP4gF4y+/pTPxKbjsUIDZfAa4MuLaP99U/zQrlsWRCHhj2 waKQIv1hEEGGL8ih2RQZBIFCRUFN81GjGwHp1KOY6JIol8F3BB9+fYy1yVVCQVMaEU0j mbXKIfYbUsGQvuAE1KJVvs6gaABbf4So9UifI0g+G35oQfeksglp1R3lkToY/E6JWaXY IrnQ== MIME-Version: 1.0 Received: by 10.60.31.227 with SMTP id d3mr3138600oei.70.1355444661161; Thu, 13 Dec 2012 16:24:21 -0800 (PST) Received: by 10.182.190.83 with HTTP; Thu, 13 Dec 2012 16:24:20 -0800 (PST) In-Reply-To: <1698382.9Eyt0BnUlN@home.alkar.net> References: <50CA50C6.2080501@gmail.com> <50CA652C.5010101@freebsd.org> <1698382.9Eyt0BnUlN@home.alkar.net> Date: Thu, 13 Dec 2012 19:24:20 -0500 Message-ID: Subject: Re: new xorg segfault 11 with KMS From: Johannes Dieterich To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: David Chisnall , freebsd-current@freebsd.org, Dimitry Andric , Niclas Zeising X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 00:24:28 -0000 On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy wrote: > This patch work for me. Thanks. I can confirm that it also works for me. Thanks a lot! > On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: > >> Can you please try the attached patch, against x11-servers/xorg-server. > >> Apply it and recompile xorg-server with normal flags (that is, no > >> debugging) and let me and the list know the result when starting X. > >> Regards! > >> > > -- > > This message is for the person(s) named above only and may contain > privileged, proprietary, or otherwise private information. If you received > this transmission in error, please notify the sender immediately and delete > the original. Any other use of the email by you is prohibited. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 03:15:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E898D8C7; Fri, 14 Dec 2012 03:15:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5598FC14; Fri, 14 Dec 2012 03:15:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHGYylCDaFvO/2dsb2JhbAA9CIY4tGODcHOCHgEBBSMEUhsOCgICDRkCWQaIJqo/knyBIos1CwyDGYETA4hgjSmQSIMRgU81 X-IronPort-AV: E=Sophos;i="4.84,277,1355115600"; d="scan'208";a="4783445" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Dec 2012 22:14:30 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E8CDBB4063; Thu, 13 Dec 2012 22:14:29 -0500 (EST) Date: Thu, 13 Dec 2012 22:14:29 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1783866028.1396164.1355454869890.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121213043132.GB71906@kib.kiev.ua> Subject: Re: r244036 kernel hangs under load. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 03:15:41 -0000 Konstantin Belousov wrote: > On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: > > > > Ok, I'll test r243598 and then r243599 and r243835, just to > > > > see if it really is this. > > > > > > > > I'll email when I have done this. > > > If you test only r243598, I am sure that you would experience > > > corruption. > > > The r243599 should cause the deadlocks. > > > > > I think you meant r243599 will result in corruptions and > > r243835 deadlocks. > > > > I have run r243598 for a while without a hang. (r243599 doesn't > > build) I haven't tried r243835 yet. > > > > > > > > > > > > > > > > > > Also, do you use the post-r244095 kernel ? > > > > > > > > > > > > Before and after. The most recent tests were post-r244095. > > > > > > (If anything the more recent kernels hang more easily.) > > > > > > > > > > > > > > > > > > > > > > > > > > Is your machine SMP ? > > > > > > > > > > > > Old, slow single core i386. > > > > > > > > > > Try this. Please note that this is mostly a debugging > > > > > facility. > > > > > > > > > It seemed to help, but didn't stop the hangs completely. > > > > r244125 without the patch would hang somewhere in a kernel > > > > build. r244125 plus this patch ran almost 2 kernel builds > > > > before it got hung. > > > > > > Can you try to look into the system state on the hang (on the > > > kernel > > > with the if (1 || patch applied) ? Using the ddb and recipe from > > > the > > > web page. Basically watch for a thread looping in the mnt_active > > > iterator and threads owning vnode interlocks. > > > > Ok, there is only one process in the mnt_active iterator and its > > trace is as follows (syncer): > > dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') > > intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at > > intr_execute_handlers+0x49/frame 0xdfe33afc > > lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame > > 0xdfe33b10 > > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 > > --- interrupt, eip = 0xc0eca8db, esp = 0xdfe33b60, ebp = 0xdfe33b64 > > --- > > spinlock_exit(c128be90,4,c10b5017,130,1710,...) at > > spinlock_exit+0x2b/frame 0xdfe33b64 > > __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at > > __mtx_unlock_spin_flags+0x112/frame 0xdfe33b90 > > kern_yield(ffffffff,0,c10c75c9,127b,c8b05238,...) at > > kern_yield+0x125/frame 0xdfe33bbc > > __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at > > __mnt_vnode_next_active+0xda/frame 0xdfe33be0 > > vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame > > 0xdfe33c18 > > sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at > > sync_fsync+0x141/frame 0xdfe33c64 > > VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at > > VOP_FSYNC_APV+0xb4/frame 0xdfe33c64 > > sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at > > sched_sync+0x399/frame 0xdfe33cc8 > > fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 > > fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 > > --- trap 0, eip = 0, esp = 0xdfe33d40, ebp = 0 --- > > > > This process holds: > > exclusive lockmgr syncer (syncer) r = 0 (0xc85cf4c8) locked @ > > kern/vfs_subr.c:1780 > > > > The only other process that is doing anything in the VFS subsystem > > holds the vnode interlock. It's trace is: > > dle+0x12d/frame 0xdfe6a850 > > intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at > > intr_execute_handlers+0x49/frame 0xdfe6a870 > > lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame > > 0xdfe6a884 > > Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 > > --- interrupt, eip = 0xc0b2206a, esp = 0xdfe6a8d4, ebp = 0xdfe6a908 > > --- > > witness_unlock(c8972a74,8,c10c75c9,965,0,...) at > > witness_unlock+0x3a/frame 0xdfe6a908 > > __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at > > __mtx_unlock_flags+0x9f/frame 0xdfe6a938 > > vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at > > vdropl+0x63/frame 0xdfe6a95c > > vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at > > vputx+0x300/frame 0xdfe6a994 > > vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame > > 0xdfe6a99c > > lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame > > 0xdfe6aa04 > > namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 > > vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at > > vn_open_cred+0x2c0/frame 0xdfe6ab40 > > vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at > > vn_open+0x3b/frame 0xdfe6ab60 > > kern_openat(c85c55e0,ffffff9c,2882dcc0,0,8001,...) at > > kern_openat+0x1e2/frame 0xdfe6ac0c > > kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame > > 0xdfe6ac2c > > sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at > > sys_open+0x30/frame 0xdfe6ac48 > > syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc > > --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x84a1667, esp = > > 0xbfbfcffc, ebp = 0xbfbfd018 --- > > > > The locks this process holds are: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > > (0x8972a74) locked @ kern/vfs_subr.c:2513 > > shared lockmgr ufs (ufs) r = 0 (0xc8bd181c) locked @ > > kern/vfs_subr.c:2161 > > > > The only other lock held by any thread/process is: > > Process 12 (intr) thread 0xc5dfc5e0 (100012) > > exclusive sleep mutex Giant (Giant) r = 1 (0xc127b690) locked @ > > dev/syscons/syscons.c:724 > > > > The only 2 locked vnodes are the ufs one and the syncer one, as > > shown above. > > > > The rest of the processes/threads don't hold any locks and don't > > seem > > to be in vfs code. > > > > db> show pcpu (this machine is single core) > > cpuid = 0 > > dynamic pcpu = 0x5e5b00 > > curthread = 0xc5dfc5e0: pid 12 "swi6: Giant taskq" > > curpcb = 0xc592fd60 > > fpcurthread = none > > idlethread = 0xc5dfb8d0: tid 100003 "idle: cpu0" > > APIC ID = 0 > > currentldt = 0x50 > > spin locks held: > > db> > > > > When I do a "db> cont", wait a while and then go > > back into the debugger with , everything > > looks the same. > > > > I'll leave this machine like this, in case you want me > > to do anything else in the debugger. The kernel is > > r244125 + your little patch and it took about 5 kernel > > build cycles to get it hung. (Without your little > > patch, it usually hangs in the first kernel build cycle.) > > > > Do you happen to know how I can tell where it was executing > > when I ? (show registers just has the eip in > > kdb_enter) > > Can I work up a the stack referenced by esp and find a saved > > eip? > The thread that was executing is shown as curthread from 'show pcpu'. > Was it taskq always, or was taskq only sporadic, and syncer process > rest of the time ? > > FWIW, you could try this patch too, at least I have a theory now why > the if (1) patch did not helped. My guess is that kern_yield() > effectively > returned the same high-priority syncer process back to the CPU. > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index 67e078d..2325201 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -4710,32 +4710,54 @@ __mnt_vnode_markerfree_all(struct vnode **mvp, > struct mount *mp) > * These are helper functions for filesystems to traverse their > * active vnodes. See MNT_VNODE_FOREACH_ACTIVE() in sys/mount.h > */ > -struct vnode * > -__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > +static void > +mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *mp) > +{ > + > + KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list > mismatch")); > + > + MNT_ILOCK(mp); > + MNT_REL(mp); > + MNT_IUNLOCK(mp); > + free(*mvp, M_VNODE_MARKER); > + *mvp = NULL; > +} > + > +#ifdef SMP > +#define ALWAYS_YIELD (mp_ncpus == 1) > +#else > +#define ALWAYS_YIELD 1 > +#endif > + > +static struct vnode * > +mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > { > struct vnode *vp, *nvp; > > - if (should_yield()) > - kern_yield(PRI_UNCHANGED); > - mtx_lock(&vnode_free_list_mtx); > -restart: > + mtx_assert(&vnode_free_list_mtx, MA_OWNED); > KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list mismatch")); > +restart: > vp = TAILQ_NEXT(*mvp, v_actfreelist); > + TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > while (vp != NULL) { > if (vp->v_type == VMARKER) { > vp = TAILQ_NEXT(vp, v_actfreelist); > continue; > } > if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > + if (ALWAYS_YIELD || should_yield()) { > + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > - kern_yield(PRI_UNCHANGED); > + kern_yield(PRI_USER); > mtx_lock(&vnode_free_list_mtx); > + goto restart; > } > - goto restart; > + continue; > } > - if (vp->v_mount == mp && vp->v_type != VMARKER && > - (vp->v_iflag & VI_DOOMED) == 0) > + KASSERT(vp->v_type != VMARKER, ("locked marker %p", vp)); > + KASSERT(vp->v_mount == mp || vp->v_mount == NULL, > + ("alien vnode on the active list %p %p", vp, mp)); > + if (vp->v_mount == mp && (vp->v_iflag & VI_DOOMED) == 0) > break; > nvp = TAILQ_NEXT(vp, v_actfreelist); > VI_UNLOCK(vp); > @@ -4745,22 +4767,31 @@ restart: > /* Check if we are done */ > if (vp == NULL) { > mtx_unlock(&vnode_free_list_mtx); > - __mnt_vnode_markerfree_active(mvp, mp); > - mtx_assert(MNT_MTX(mp), MA_NOTOWNED); > + mnt_vnode_markerfree_active(mvp, mp); > return (NULL); > } > - TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > ASSERT_VI_LOCKED(vp, "active iter"); > KASSERT((vp->v_iflag & VI_ACTIVE) != 0, ("Non-active vp %p", vp)); > return (vp); > } > +#undef ALWAYS_YIELD > + > +struct vnode * > +__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) > +{ > + > + if (should_yield()) > + kern_yield(PRI_UNCHANGED); > + mtx_lock(&vnode_free_list_mtx); > + return (mnt_vnode_next_active(mvp, mp)); > +} > > struct vnode * > __mnt_vnode_first_active(struct vnode **mvp, struct mount *mp) > { > - struct vnode *vp, *nvp; > + struct vnode *vp; > > *mvp = malloc(sizeof(struct vnode), M_VNODE_MARKER, M_WAITOK | > M_ZERO); > MNT_ILOCK(mp); > @@ -4770,44 +4801,14 @@ __mnt_vnode_first_active(struct vnode **mvp, > struct mount *mp) > (*mvp)->v_mount = mp; > > mtx_lock(&vnode_free_list_mtx); > -restart: > vp = TAILQ_FIRST(&mp->mnt_activevnodelist); > - while (vp != NULL) { > - if (vp->v_type == VMARKER) { > - vp = TAILQ_NEXT(vp, v_actfreelist); > - continue; > - } > - if (!VI_TRYLOCK(vp)) { > - if (should_yield()) { > - mtx_unlock(&vnode_free_list_mtx); > - kern_yield(PRI_UNCHANGED); > - mtx_lock(&vnode_free_list_mtx); > - } > - goto restart; > - } > - if (vp->v_mount == mp && vp->v_type != VMARKER && > - (vp->v_iflag & VI_DOOMED) == 0) > - break; > - nvp = TAILQ_NEXT(vp, v_actfreelist); > - VI_UNLOCK(vp); > - vp = nvp; > - } > - > - /* Check if we are done */ > if (vp == NULL) { > mtx_unlock(&vnode_free_list_mtx); > - MNT_ILOCK(mp); > - MNT_REL(mp); > - MNT_IUNLOCK(mp); > - free(*mvp, M_VNODE_MARKER); > - *mvp = NULL; > + mnt_vnode_markerfree_active(mvp, mp); > return (NULL); > } > - TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, > v_actfreelist); > - mtx_unlock(&vnode_free_list_mtx); > - ASSERT_VI_LOCKED(vp, "active iter first"); > - KASSERT((vp->v_iflag & VI_ACTIVE) != 0, ("Non-active vp %p", vp)); > - return (vp); > + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); > + return (mnt_vnode_next_active(mvp, mp)); > } > > void > @@ -4817,14 +4818,8 @@ __mnt_vnode_markerfree_active(struct vnode > **mvp, struct mount *mp) > if (*mvp == NULL) > return; > > - KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list > mismatch")); > - > mtx_lock(&vnode_free_list_mtx); > TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > - MNT_ILOCK(mp); > - MNT_REL(mp); > - MNT_IUNLOCK(mp); > - free(*mvp, M_VNODE_MARKER); > - *mvp = NULL; > + mnt_vnode_markerfree_active(mvp, mp); > } Good work. This patch seems to have done the trick. I've run quite a few kernel build cycles without a hang. I'll keep running them, but I would have expected to see a hang by now. Maybe Tim can test the patch as well? (I needed to add #include btw.) rick From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 04:03:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCC65562; Fri, 14 Dec 2012 04:03:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC848FC12; Fri, 14 Dec 2012 04:03:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBE43dPZ025980; Fri, 14 Dec 2012 06:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qBE43dPZ025980 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBE43daa025979; Fri, 14 Dec 2012 06:03:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Dec 2012 06:03:39 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: r244036 kernel hangs under load. Message-ID: <20121214040339.GI71906@kib.kiev.ua> References: <20121213043132.GB71906@kib.kiev.ua> <1783866028.1396164.1355454869890.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jaTU8Y2VLE5tlY1O" Content-Disposition: inline In-Reply-To: <1783866028.1396164.1355454869890.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Tim Kientzle , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 04:03:45 -0000 --jaTU8Y2VLE5tlY1O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 10:14:29PM -0500, Rick Macklem wrote: > Good work. This patch seems to have done the trick. I've run > quite a few kernel build cycles without a hang. I'll keep running > them, but I would have expected to see a hang by now. >=20 > Maybe Tim can test the patch as well? > (I needed to add #include btw.) Below is the current version of the patch, it is being tested by Peter Holm. Compared to what I sent you earlier, it contain a bug fix only relevant if you use quotas. diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 67e078d..64d75fb 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -69,6 +69,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -4710,32 +4711,54 @@ __mnt_vnode_markerfree_all(struct vnode **mvp, stru= ct mount *mp) * These are helper functions for filesystems to traverse their * active vnodes. See MNT_VNODE_FOREACH_ACTIVE() in sys/mount.h */ -struct vnode * -__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) +static void +mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *mp) +{ + + KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); + + MNT_ILOCK(mp); + MNT_REL(mp); + MNT_IUNLOCK(mp); + free(*mvp, M_VNODE_MARKER); + *mvp =3D NULL; +} + +#ifdef SMP +#define ALWAYS_YIELD (mp_ncpus =3D=3D 1) +#else +#define ALWAYS_YIELD 1 +#endif + +static struct vnode * +mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) { struct vnode *vp, *nvp; =20 - if (should_yield()) - kern_yield(PRI_UNCHANGED); - mtx_lock(&vnode_free_list_mtx); -restart: + mtx_assert(&vnode_free_list_mtx, MA_OWNED); KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); +restart: vp =3D TAILQ_NEXT(*mvp, v_actfreelist); + TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); while (vp !=3D NULL) { if (vp->v_type =3D=3D VMARKER) { vp =3D TAILQ_NEXT(vp, v_actfreelist); continue; } if (!VI_TRYLOCK(vp)) { - if (should_yield()) { + if (ALWAYS_YIELD || should_yield()) { + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); - kern_yield(PRI_UNCHANGED); + kern_yield(PRI_USER); mtx_lock(&vnode_free_list_mtx); + goto restart; } - goto restart; + continue; } - if (vp->v_mount =3D=3D mp && vp->v_type !=3D VMARKER && - (vp->v_iflag & VI_DOOMED) =3D=3D 0) + KASSERT(vp->v_type !=3D VMARKER, ("locked marker %p", vp)); + KASSERT(vp->v_mount =3D=3D mp || vp->v_mount =3D=3D NULL, + ("alien vnode on the active list %p %p", vp, mp)); + if (vp->v_mount =3D=3D mp && (vp->v_iflag & VI_DOOMED) =3D=3D 0) break; nvp =3D TAILQ_NEXT(vp, v_actfreelist); VI_UNLOCK(vp); @@ -4745,22 +4768,31 @@ restart: /* Check if we are done */ if (vp =3D=3D NULL) { mtx_unlock(&vnode_free_list_mtx); - __mnt_vnode_markerfree_active(mvp, mp); - mtx_assert(MNT_MTX(mp), MA_NOTOWNED); + mnt_vnode_markerfree_active(mvp, mp); return (NULL); } - TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); ASSERT_VI_LOCKED(vp, "active iter"); KASSERT((vp->v_iflag & VI_ACTIVE) !=3D 0, ("Non-active vp %p", vp)); return (vp); } +#undef ALWAYS_YIELD + +struct vnode * +__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp) +{ + + if (should_yield()) + kern_yield(PRI_UNCHANGED); + mtx_lock(&vnode_free_list_mtx); + return (mnt_vnode_next_active(mvp, mp)); +} =20 struct vnode * __mnt_vnode_first_active(struct vnode **mvp, struct mount *mp) { - struct vnode *vp, *nvp; + struct vnode *vp; =20 *mvp =3D malloc(sizeof(struct vnode), M_VNODE_MARKER, M_WAITOK | M_ZERO); MNT_ILOCK(mp); @@ -4770,44 +4802,14 @@ __mnt_vnode_first_active(struct vnode **mvp, struct= mount *mp) (*mvp)->v_mount =3D mp; =20 mtx_lock(&vnode_free_list_mtx); -restart: vp =3D TAILQ_FIRST(&mp->mnt_activevnodelist); - while (vp !=3D NULL) { - if (vp->v_type =3D=3D VMARKER) { - vp =3D TAILQ_NEXT(vp, v_actfreelist); - continue; - } - if (!VI_TRYLOCK(vp)) { - if (should_yield()) { - mtx_unlock(&vnode_free_list_mtx); - kern_yield(PRI_UNCHANGED); - mtx_lock(&vnode_free_list_mtx); - } - goto restart; - } - if (vp->v_mount =3D=3D mp && vp->v_type !=3D VMARKER && - (vp->v_iflag & VI_DOOMED) =3D=3D 0) - break; - nvp =3D TAILQ_NEXT(vp, v_actfreelist); - VI_UNLOCK(vp); - vp =3D nvp; - } - - /* Check if we are done */ if (vp =3D=3D NULL) { mtx_unlock(&vnode_free_list_mtx); - MNT_ILOCK(mp); - MNT_REL(mp); - MNT_IUNLOCK(mp); - free(*mvp, M_VNODE_MARKER); - *mvp =3D NULL; + mnt_vnode_markerfree_active(mvp, mp); return (NULL); } - TAILQ_INSERT_AFTER(&mp->mnt_activevnodelist, vp, *mvp, v_actfreelist); - mtx_unlock(&vnode_free_list_mtx); - ASSERT_VI_LOCKED(vp, "active iter first"); - KASSERT((vp->v_iflag & VI_ACTIVE) !=3D 0, ("Non-active vp %p", vp)); - return (vp); + TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); + return (mnt_vnode_next_active(mvp, mp)); } =20 void @@ -4817,14 +4819,8 @@ __mnt_vnode_markerfree_active(struct vnode **mvp, st= ruct mount *mp) if (*mvp =3D=3D NULL) return; =20 - KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); - mtx_lock(&vnode_free_list_mtx); TAILQ_REMOVE(&mp->mnt_activevnodelist, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); - MNT_ILOCK(mp); - MNT_REL(mp); - MNT_IUNLOCK(mp); - free(*mvp, M_VNODE_MARKER); - *mvp =3D NULL; + mnt_vnode_markerfree_active(mvp, mp); } diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 4d010ec..ed2b002 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -199,8 +199,8 @@ struct vnode *__mnt_vnode_next_all(struct vnode **mvp, = struct mount *mp); struct vnode *__mnt_vnode_first_all(struct vnode **mvp, struct mount *mp); void __mnt_vnode_markerfree_all(struct vnode **mvp, struct mount = *mp); =20 -#define MNT_VNODE_FOREACH_ALL(vp, mp, mvp) \ - for (vp =3D __mnt_vnode_first_all(&(mvp), (mp)); \ +#define MNT_VNODE_FOREACH_ALL(vp, mp, mvp) \ + for (vp =3D __mnt_vnode_first_all(&(mvp), (mp)); \ (vp) !=3D NULL; vp =3D __mnt_vnode_next_all(&(mvp), (mp))) =20 #define MNT_VNODE_FOREACH_ALL_ABORT(mp, mvp) \ @@ -218,17 +218,12 @@ struct vnode *__mnt_vnode_next_active(struct vnode **= mvp, struct mount *mp); struct vnode *__mnt_vnode_first_active(struct vnode **mvp, struct mount *m= p); void __mnt_vnode_markerfree_active(struct vnode **mvp, struct mou= nt *); =20 -#define MNT_VNODE_FOREACH_ACTIVE(vp, mp, mvp) \ - for (vp =3D __mnt_vnode_first_active(&(mvp), (mp)); \ +#define MNT_VNODE_FOREACH_ACTIVE(vp, mp, mvp) \ + for (vp =3D __mnt_vnode_first_active(&(mvp), (mp)); \ (vp) !=3D NULL; vp =3D __mnt_vnode_next_active(&(mvp), (mp))) =20 #define MNT_VNODE_FOREACH_ACTIVE_ABORT(mp, mvp) \ - do { \ - MNT_ILOCK(mp); \ - __mnt_vnode_markerfree_active(&(mvp), (mp)); \ - /* MNT_IUNLOCK(mp); -- done in above function */ \ - mtx_assert(MNT_MTX(mp), MA_NOTOWNED); \ - } while (0) + __mnt_vnode_markerfree_active(&(mvp), (mp)) =20 /* * Definitions for MNT_VNODE_FOREACH. diff --git a/sys/ufs/ufs/ufs_quota.c b/sys/ufs/ufs/ufs_quota.c index 330f449..87ac9a1 100644 --- a/sys/ufs/ufs/ufs_quota.c +++ b/sys/ufs/ufs/ufs_quota.c @@ -1044,7 +1044,7 @@ again: error =3D vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, td); if (error) { if (error =3D=3D ENOENT) { - MNT_VNODE_FOREACH_ALL_ABORT(mp, mvp); + MNT_VNODE_FOREACH_ACTIVE_ABORT(mp, mvp); goto again; } continue; --jaTU8Y2VLE5tlY1O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDKpRcACgkQC3+MBN1Mb4ivmwCfZQN/MSCAKeSr11ZdS78ty+0O sMUAnRt32B6sO4I9YgGpdH3U7TIULIHb =+nFT -----END PGP SIGNATURE----- --jaTU8Y2VLE5tlY1O-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 04:16:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06AE9778; Fri, 14 Dec 2012 04:16:25 +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 B8EF38FC08; Fri, 14 Dec 2012 04:16:24 +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 qBE4GHrO026643; Thu, 13 Dec 2012 23:16:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBE4GHw8026619; Fri, 14 Dec 2012 04:16:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 14 Dec 2012 04:16:17 GMT Message-Id: <201212140416.qBE4GHw8026619@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 , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:16:25 -0000 TB --- 2012-12-13 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-13 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-13 22:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-13 22:40:00 - cleaning the object tree TB --- 2012-12-13 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-13 22:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-13 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-13 22:43:23 - /usr/local/bin/svn update /src TB --- 2012-12-13 22:43:44 - At svn revision 244194 TB --- 2012-12-13 22:43:45 - building world TB --- 2012-12-13 22:43:45 - CROSS_BUILD_TESTING=YES TB --- 2012-12-13 22:43:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-13 22:43:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-13 22:43:45 - SRCCONF=/dev/null TB --- 2012-12-13 22:43:45 - TARGET=i386 TB --- 2012-12-13 22:43:45 - TARGET_ARCH=i386 TB --- 2012-12-13 22:43:45 - TZ=UTC TB --- 2012-12-13 22:43:45 - __MAKE_CONF=/dev/null TB --- 2012-12-13 22:43:45 - cd /src TB --- 2012-12-13 22:43:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Dec 13 22:43:57 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 Dec 14 01:57:37 UTC 2012 TB --- 2012-12-14 01:57:37 - generating LINT kernel config TB --- 2012-12-14 01:57:37 - cd /src/sys/i386/conf TB --- 2012-12-14 01:57:37 - /usr/bin/make -B LINT TB --- 2012-12-14 01:57:37 - cd /src/sys/i386/conf TB --- 2012-12-14 01:57:37 - /usr/sbin/config -m LINT TB --- 2012-12-14 01:57:37 - building LINT kernel TB --- 2012-12-14 01:57:37 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 01:57:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 01:57:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 01:57:37 - SRCCONF=/dev/null TB --- 2012-12-14 01:57:37 - TARGET=i386 TB --- 2012-12-14 01:57:37 - TARGET_ARCH=i386 TB --- 2012-12-14 01:57:37 - TZ=UTC TB --- 2012-12-14 01:57:37 - __MAKE_CONF=/dev/null TB --- 2012-12-14 01:57:37 - cd /src TB --- 2012-12-14 01:57:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 14 01:57:37 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 >>> Kernel build for LINT completed on Fri Dec 14 02:31:38 UTC 2012 TB --- 2012-12-14 02:31:38 - cd /src/sys/i386/conf TB --- 2012-12-14 02:31:38 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-14 02:31:38 - building LINT-NOINET kernel TB --- 2012-12-14 02:31:38 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 02:31:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 02:31:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 02:31:38 - SRCCONF=/dev/null TB --- 2012-12-14 02:31:38 - TARGET=i386 TB --- 2012-12-14 02:31:38 - TARGET_ARCH=i386 TB --- 2012-12-14 02:31:38 - TZ=UTC TB --- 2012-12-14 02:31:38 - __MAKE_CONF=/dev/null TB --- 2012-12-14 02:31:38 - cd /src TB --- 2012-12-14 02:31:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Dec 14 02:31:38 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 >>> Kernel build for LINT-NOINET completed on Fri Dec 14 03:02:33 UTC 2012 TB --- 2012-12-14 03:02:33 - cd /src/sys/i386/conf TB --- 2012-12-14 03:02:33 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-14 03:02:33 - building LINT-NOINET6 kernel TB --- 2012-12-14 03:02:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:02:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:02:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:02:33 - SRCCONF=/dev/null TB --- 2012-12-14 03:02:33 - TARGET=i386 TB --- 2012-12-14 03:02:33 - TARGET_ARCH=i386 TB --- 2012-12-14 03:02:33 - TZ=UTC TB --- 2012-12-14 03:02:33 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:02:33 - cd /src TB --- 2012-12-14 03:02:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Dec 14 03:02:34 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 >>> Kernel build for LINT-NOINET6 completed on Fri Dec 14 03:32:41 UTC 2012 TB --- 2012-12-14 03:32:41 - cd /src/sys/i386/conf TB --- 2012-12-14 03:32:41 - /usr/sbin/config -m LINT-NOIP TB --- 2012-12-14 03:32:41 - building LINT-NOIP kernel TB --- 2012-12-14 03:32:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:32:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:32:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:32:41 - SRCCONF=/dev/null TB --- 2012-12-14 03:32:41 - TARGET=i386 TB --- 2012-12-14 03:32:41 - TARGET_ARCH=i386 TB --- 2012-12-14 03:32:41 - TZ=UTC TB --- 2012-12-14 03:32:41 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:32:41 - cd /src TB --- 2012-12-14 03:32:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Dec 14 03:32:41 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 >>> Kernel build for LINT-NOIP completed on Fri Dec 14 04:00:37 UTC 2012 TB --- 2012-12-14 04:00:37 - cd /src/sys/i386/conf TB --- 2012-12-14 04:00:37 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-12-14 04:00:37 - building LINT-VIMAGE kernel TB --- 2012-12-14 04:00:37 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 04:00:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 04:00:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 04:00:37 - SRCCONF=/dev/null TB --- 2012-12-14 04:00:37 - TARGET=i386 TB --- 2012-12-14 04:00:37 - TARGET_ARCH=i386 TB --- 2012-12-14 04:00:37 - TZ=UTC TB --- 2012-12-14 04:00:37 - __MAKE_CONF=/dev/null TB --- 2012-12-14 04:00:37 - cd /src TB --- 2012-12-14 04:00:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Dec 14 04:00:37 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 [...] /src/sys/netpfil/pf/if_pfsync.c:618:3: error: must use 'struct' tag to refer to type 'pfsyncstats' pfsyncstats.pfsyncs_badlen++; ^ struct /src/sys/netpfil/pf/if_pfsync.c:618:14: error: expected identifier or '(' pfsyncstats.pfsyncs_badlen++; ^ 2 errors generated. *** [if_pfsync.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT-VIMAGE. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-14 04:16:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-14 04:16:17 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2012-12-14 04:16:17 - 14609.84 user 2655.40 system 20176.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 04:48:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33A3DED9; Fri, 14 Dec 2012 04:48:22 +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 EFB4F8FC15; Fri, 14 Dec 2012 04:48:21 +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 qBE4mLX4038623; Thu, 13 Dec 2012 23:48:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBE4mLKN038618; Fri, 14 Dec 2012 04:48:21 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 14 Dec 2012 04:48:21 GMT Message-Id: <201212140448.qBE4mLKN038618@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 , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:48:22 -0000 TB --- 2012-12-13 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-13 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-13 22:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-13 22:40:00 - cleaning the object tree TB --- 2012-12-13 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-13 22:40:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-13 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-13 22:43:58 - /usr/local/bin/svn update /src TB --- 2012-12-13 22:44:11 - At svn revision 244194 TB --- 2012-12-13 22:44:12 - building world TB --- 2012-12-13 22:44:12 - CROSS_BUILD_TESTING=YES TB --- 2012-12-13 22:44:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-13 22:44:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-13 22:44:12 - SRCCONF=/dev/null TB --- 2012-12-13 22:44:12 - TARGET=amd64 TB --- 2012-12-13 22:44:12 - TARGET_ARCH=amd64 TB --- 2012-12-13 22:44:12 - TZ=UTC TB --- 2012-12-13 22:44:12 - __MAKE_CONF=/dev/null TB --- 2012-12-13 22:44:12 - cd /src TB --- 2012-12-13 22:44:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Dec 13 22:44:20 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Dec 14 02:36:03 UTC 2012 TB --- 2012-12-14 02:36:03 - generating LINT kernel config TB --- 2012-12-14 02:36:03 - cd /src/sys/amd64/conf TB --- 2012-12-14 02:36:03 - /usr/bin/make -B LINT TB --- 2012-12-14 02:36:04 - cd /src/sys/amd64/conf TB --- 2012-12-14 02:36:04 - /usr/sbin/config -m LINT TB --- 2012-12-14 02:36:04 - building LINT kernel TB --- 2012-12-14 02:36:04 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 02:36:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 02:36:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 02:36:04 - SRCCONF=/dev/null TB --- 2012-12-14 02:36:04 - TARGET=amd64 TB --- 2012-12-14 02:36:04 - TARGET_ARCH=amd64 TB --- 2012-12-14 02:36:04 - TZ=UTC TB --- 2012-12-14 02:36:04 - __MAKE_CONF=/dev/null TB --- 2012-12-14 02:36:04 - cd /src TB --- 2012-12-14 02:36:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 14 02:36:04 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 >>> Kernel build for LINT completed on Fri Dec 14 03:08:06 UTC 2012 TB --- 2012-12-14 03:08:06 - cd /src/sys/amd64/conf TB --- 2012-12-14 03:08:06 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-14 03:08:06 - building LINT-NOINET kernel TB --- 2012-12-14 03:08:06 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:08:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:08:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:08:06 - SRCCONF=/dev/null TB --- 2012-12-14 03:08:06 - TARGET=amd64 TB --- 2012-12-14 03:08:06 - TARGET_ARCH=amd64 TB --- 2012-12-14 03:08:06 - TZ=UTC TB --- 2012-12-14 03:08:06 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:08:06 - cd /src TB --- 2012-12-14 03:08:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Dec 14 03:08:06 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 >>> Kernel build for LINT-NOINET completed on Fri Dec 14 03:36:54 UTC 2012 TB --- 2012-12-14 03:36:54 - cd /src/sys/amd64/conf TB --- 2012-12-14 03:36:54 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-14 03:36:54 - building LINT-NOINET6 kernel TB --- 2012-12-14 03:36:54 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:36:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:36:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:36:54 - SRCCONF=/dev/null TB --- 2012-12-14 03:36:54 - TARGET=amd64 TB --- 2012-12-14 03:36:54 - TARGET_ARCH=amd64 TB --- 2012-12-14 03:36:54 - TZ=UTC TB --- 2012-12-14 03:36:54 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:36:54 - cd /src TB --- 2012-12-14 03:36:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Dec 14 03:36:55 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 >>> Kernel build for LINT-NOINET6 completed on Fri Dec 14 04:06:21 UTC 2012 TB --- 2012-12-14 04:06:21 - cd /src/sys/amd64/conf TB --- 2012-12-14 04:06:21 - /usr/sbin/config -m LINT-NOIP TB --- 2012-12-14 04:06:21 - building LINT-NOIP kernel TB --- 2012-12-14 04:06:21 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 04:06:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 04:06:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 04:06:21 - SRCCONF=/dev/null TB --- 2012-12-14 04:06:21 - TARGET=amd64 TB --- 2012-12-14 04:06:21 - TARGET_ARCH=amd64 TB --- 2012-12-14 04:06:21 - TZ=UTC TB --- 2012-12-14 04:06:21 - __MAKE_CONF=/dev/null TB --- 2012-12-14 04:06:21 - cd /src TB --- 2012-12-14 04:06:21 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Dec 14 04:06:21 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 >>> Kernel build for LINT-NOIP completed on Fri Dec 14 04:32:54 UTC 2012 TB --- 2012-12-14 04:32:54 - cd /src/sys/amd64/conf TB --- 2012-12-14 04:32:54 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-12-14 04:32:55 - building LINT-VIMAGE kernel TB --- 2012-12-14 04:32:55 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 04:32:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 04:32:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 04:32:55 - SRCCONF=/dev/null TB --- 2012-12-14 04:32:55 - TARGET=amd64 TB --- 2012-12-14 04:32:55 - TARGET_ARCH=amd64 TB --- 2012-12-14 04:32:55 - TZ=UTC TB --- 2012-12-14 04:32:55 - __MAKE_CONF=/dev/null TB --- 2012-12-14 04:32:55 - cd /src TB --- 2012-12-14 04:32:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Dec 14 04:32:55 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 [...] /src/sys/netpfil/pf/if_pfsync.c:618:3: error: must use 'struct' tag to refer to type 'pfsyncstats' pfsyncstats.pfsyncs_badlen++; ^ struct /src/sys/netpfil/pf/if_pfsync.c:618:14: error: expected identifier or '(' pfsyncstats.pfsyncs_badlen++; ^ 2 errors generated. *** [if_pfsync.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-14 04:48:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-14 04:48:21 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2012-12-14 04:48:21 - 15796.87 user 2920.58 system 22100.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 06:41:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D08F1180; Fri, 14 Dec 2012 06:41:15 +0000 (UTC) (envelope-from rizzo.unipi@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 053D28FC08; Fri, 14 Dec 2012 06:41:14 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so1716189eek.13 for ; Thu, 13 Dec 2012 22:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/JEv1mLcg622mmBZ07HvWGdevo9oyH95hSzu69md+fM=; b=PpspHUbC72i4CAoVI0AfJBnkmXu/UclgpYLq5XPM3Nl1FL/AaWIe6gI3oOM0yAdsQT Wos++AARCh5F9dK+e4UXt0cai3lwgwvFcLT7gQfbKxktoBxrmzvSD2lzECi9t/FdZXKq C4bfc/B123HUIJR6TESnXg2gmAg4Cau9vde696CTFrt9QVM9HMdtX2XCica6k9ZB+d2U n30P6BPqmH8UHvczjxXwAAHRtbApT4y1gUrVgFv3nUfev8r+IFSr1pu9aTZNlgP5wCR5 wE4dUnmZrbbKpdHSL6oK1vdQTr2pKF5kfWlGStuJ2yiw4JsFABW1PdbULqXzQWOeZpuV 76kg== MIME-Version: 1.0 Received: by 10.14.209.193 with SMTP id s41mr12493191eeo.9.1355467267853; Thu, 13 Dec 2012 22:41:07 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.0.2 with HTTP; Thu, 13 Dec 2012 22:41:07 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 07:41:07 +0100 X-Google-Sender-Auth: avhdjzvO5ecoEtcfvzAV7u6e5DM Message-ID: Subject: Re: [RFC/RFT] calloutng From: Luigi Rizzo To: Davide Italiano Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 06:41:16 -0000 On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano wrote= : > Hi. > This patch takes callout(9) and redesign the KPI and the > implementation. The main objective of this work is making the > subsystem tickless. In the last several years, this possibility has > been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), > but until now noone really implemented that. > If you want a complete history of what has been done in the last > months you can check the calloutng project repository > http://svnweb.freebsd.org/base/projects/calloutng/ > For lazy people, here's a summary: > thanks for the work and the detailed summary. Perhaps it would be useful if you could provide a few high level details on the use and performance of the new scheme, such as: - is the old callout KPI still available ? (i am asking because it would help maintaining third party kernel modules that are expected to work on different FreeBSD releases) - do you have numbers on what is the fastest rate at which callouts can be fired (e.g. say you have a callout which increments a counter and schedules the next callout in (struct bintime){0,1} ) ? - is there a possibility that if callout requests are too close to each other (e.g. the above test) the thread dispatching callouts will run forever ? if so, is there a way to make such thread yield after a while ? - since you mentioned nanosleep() poll() and select() have been ported to the new callout, is there a way to guarantee that user using these functions with a very short timeout are actually descheduled as opposed to "interval too short, don't bother" ? - do you have numbers on how many calls per second we can have for a process that does for (;;) { nanosleep(min_value_that_causes_descheduling); I also have some comments on the diff: - can you provide a diff -p ? - for several functions the only change is the name of an argument from "busy" to "us". Can you elaborate the reason for the change, and whether "us" means microseconds or the pronoun ?) Finally, a more substantial comment: - a lot of functions which formerly had only a "timo" argument now have "timo, bt, precision, flags". Take seltdwait() as an example. It seems that you have been undecided between two approaches: for some of these functions you have preserved the original function that deals with ticks and introduced a new one that deals with the bintime, whereas in other cases you have modified the original function to add "bt, precision, flags". I would suggest a more uniform approach, namely: - preserve all the existing functions (T) that take a timeout in ticks; - add a new set of corresponding functions (BT) that take bt, precision, flags _instead_ of the ticks - the functions (T) make immediately the conversion from ticks to bintime(s), using macros or inline - optionally, convert kernel components to the new (BT) functions where this makes sense (e.g. we can exploit the finer-granularity of the new calls, etc.) cheers luigi 1) callout(9) is not anymore constrained to the resolution a periodic > "hz" clock can give. In order to do that, the eventtimers(4) subsystem > is used as backend. > 2) Conversely from what discussed in past, we maintained the callwheel > as underlying data structure for keeping track of the outstading > timeouts. This choice has a couple of advantages, in particular we can > still take benefits from the O(1) average complexity of the wheel for > all the operations. Also, we thought the code duplication that would > arise from the use of a two-staged backend for callout (e.g. use wheel > for coarse resolution event and another data structure, such as an > heap for high resolution events), is unacceptable. In fact, as long as > callout gained the ability to migrate from a cpu to another having a > double backend would mean doubling the code for the migration path. > 3) A way to dispatch interrupts from hardware interrupt context has > been implemented, using special callout flag. This has limited > applicability, but avoid the dispatching of a SWI thread for handling > specific callouts, avoiding the wake up of another CPU for processing > and a (relatively useless) context switch > 4) As long as new callout mechanism deals with bintime and not anymore > with ticks, time is specified as absolute and not relative anymore. In > order to get current time binuptime() or getbinuptime() is used, and a > sysctl is introduced to selectively choose the function to use, based > on a precision threshold. > 5) A mechanism for specifying precision tolerance has been > implemented. The callout processing mechanism has been adapted and the > callout data structure augmented so that the codepath can take > advantage and aggregate events which overlap in time. > > > The new proposed KPI for callout is the following: > callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., int > flags) > where =91time=92 argument represets the time at which the callout should > fire, =91pr=92 represents the precision tolerance expressed as an absolut= e > value, and =91flags=92, which could be used to specify new features, i.e. > for now, the possibility to run the callout from fast interrupt > context. > The old KPI has been extended introducing the callout_reset_flags() > function, which is the same of callout_reset*(), but takes an > additional argument =91int flags=92 that can be used in the same fashion > of the =91flags=92 argument for the new KPI. Using the =91flags=92 consum= ers > can also specify relative precision tolerance in terms of power-of-two > portion of the timeout passed as ticks. > Using this strategy, the new precision mechanism can be used for the > existing services without major modifications. > > Some consumers have been ported to the new KPI, in particular > nanosleep(), poll(), select(), because they take immediate advantage > from the arbitrary precision offered by the new infrastructure. > For some statistics about the outcome of the conversion to the new > service, please refer to the end of this e-mail: > http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html > We didn't measure any significant performance regressions with > hwmpc(4), using some benckmarks programs: > http://people.freebsd.org/~davide/poll_test/poll_test.c > http://people.freebsd.org/~mav/testsleep.c > http://people.freebsd.org/~mav/testidle.c > > We tested the code on amd64, MIPS and arm. Any kind of testing or > comment would be really appreciated. The full diff of the work against > HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff > If noone have objections, we plan to merge the repository to HEAD in a > week or so. > > Thanks, > > Davide > _______________________________________________ > 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 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 09:26:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7E43CA7 for ; Fri, 14 Dec 2012 09:26:48 +0000 (UTC) (envelope-from husyh@hush.com) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by mx1.freebsd.org (Postfix) with ESMTP id 797D28FC12 for ; Fri, 14 Dec 2012 09:26:48 +0000 (UTC) Received: from smtp10.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id A705D1AE5CB for ; Fri, 14 Dec 2012 08:56:07 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp10.hushmail.com (Postfix) with ESMTP; Fri, 14 Dec 2012 08:56:07 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3938D10E2C8; Fri, 14 Dec 2012 08:56:07 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 14 Dec 2012 09:56:06 +0100 To: "Adrian Chadd" Subject: Re: ath0: unable to attach hardware From: husyh@hush.com In-Reply-To: References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <201212111549.49942.jhb@freebsd.org> <20121213211100.5395F10E2C8@smtp.hushmail.com> Content-Type: multipart/mixed; boundary="=_d1b9c4716a57f436e348f6ce4081c12a" Message-Id: <20121214085607.3938D10E2C8@smtp.hushmail.com> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 09:26:48 -0000 --=_d1b9c4716a57f436e348f6ce4081c12a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, attached to this e-mail you find the output of dmesg. What I guess the most relevant lines could be is: ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device 4.0 on pci2 ar5212ChipTest: address test failed addr: 0x00008000 - wr:0x00000000 != rd:0xffffffff ar5212Attach: hardware self-test failed ath0: unable to attach hardware; HAL status 14 device_attach: ath0 attach returned 6 I read the registers 4004 and 4010 again to make sure the values still are the same, which indeed they are. I hope this helps. Thanks! On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" wrote: > >On 13 December 2012 13:11, wrote: >> Hello everyone, >> >> I'm afraid I still don't know what exactly BAR is, or how I get >its value that I'm supposed to plug into the line John provided: >> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >count=1 | hd >> >> I assumed that "start of bar" is 0xfdee0000 in my case, since >dmesg reports >> ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device >4.0 on pci2 > >Yup. > >> This is what I get: >> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4004)/4" >| bc` count=1 | hd >> 00 00 01 00 >> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4010)/4" >| bc` count=1 | hd >> 14 00 01 00 >> >> Please correct me if my assumption about "start of bar" was >wrong and/or I made some other mistake. >> Also, please don't hesitate to ask me to do anything else that >might help you during debugging. >> >> Thank you very much for the effort. > >Hm. Wait, what's the rest of the ath0: output? > > > >Adrian --=_d1b9c4716a57f436e348f6ce4081c12a Content-Transfer-Encoding: base64 Content-Type: text/plain; name="dmesg.txt"; Content-Disposition: attachment; filename="dmesg.txt"; VGFibGUgJ0ZBQ1AnIGF0IDB4N2ZlZTMwYzAKVGFibGUgJ01DRkcnIGF0IDB4N2ZlZTg4MDAKVGFi bGUgJ0FQSUMnIGF0IDB4N2ZlZTg3MDAKQVBJQzogRm91bmQgdGFibGUgYXQgMHg3ZmVlODcwMApB UElDOiBVc2luZyB0aGUgTUFEVCBlbnVtZXJhdG9yLgpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAw IEFDUEkgSUQgMDogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAwIChBUCkKTUFEVDogRm91bmQgQ1BV IEFQSUMgSUQgMSBBQ1BJIElEIDE6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgMSAoQVApCk1BRFQ6 IEZvdW5kIENQVSBBUElDIElEIDIgQUNQSSBJRCAyOiBkaXNhYmxlZApNQURUOiBGb3VuZCBDUFUg QVBJQyBJRCAzIEFDUEkgSUQgMzogZGlzYWJsZWQKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTIgVGhl IEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAx OTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5p dmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEg cmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5 LjAtUkVMRUFTRSAjMDogV2VkIE9jdCAzMSAxNzo0NjoyNiBDRVQgMjAxMgogICAgcm9vdEBwYXZp bGlvbjovdXNyL29iai91c3Ivc3JjL3N5cy9QQVZJTElPTiBhbWQ2NApUYWJsZSAnRkFDUCcgYXQg MHg3ZmVlMzBjMApUYWJsZSAnTUNGRycgYXQgMHg3ZmVlODgwMApUYWJsZSAnQVBJQycgYXQgMHg3 ZmVlODcwMApBQ1BJOiBObyBTUkFUIHRhYmxlIGZvdW5kClByZWxvYWRlZCBlbGYga2VybmVsICIv Ym9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODEzZGIwMDAuCkNhbGlicmF0aW5nIFRT QyBjbG9jayAuLi4gVFNDIGNsb2NrOiAzMDAwOTIxNDgwIEh6CkNQVTogSW50ZWwoUikgUGVudGl1 bShSKSBEIENQVSAzLjAwR0h6ICgzMDAwLjkyLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0g IkdlbnVpbmVJbnRlbCIgIElkID0gMHhmNjIgIEZhbWlseSA9IGYgIE1vZGVsID0gNiAgU3RlcHBp bmcgPSAyCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN Q0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxB Q1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4ZTQzZDxT U0UzLERURVM2NCxNT04sRFNfQ1BMLFZNWCxDTlhULUlELENYMTYseFRQUixQRENNPgogIEFNRCBG ZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFI Rj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDIxNDc0ODM2NDggKDIw NDggTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgw MDAwMDAwMDAwMDliZmZmLCA2MzQ4ODAgYnl0ZXMgKDE1NSBwYWdlcykKMHgwMDAwMDAwMDAwMTAw MDAwIC0gMHgwMDAwMDAwMDAwMWZmZmZmLCAxMDQ4NTc2IGJ5dGVzICgyNTYgcGFnZXMpCjB4MDAw MDAwMDAwMTQwYTAwMCAtIDB4MDAwMDAwMDA3YzFlYmZmZiwgMjA2MTM3NzUzNiBieXRlcyAoNTAz MjY2IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAyMDQ1NTIxOTIwICgxOTUwIE1CKQpFdmVudCB0aW1l ciAiTEFQSUMiIHF1YWxpdHkgNDAwCkFDUEkgQVBJQyBUYWJsZTogPEhQLUNQQyBBV1JEQUNQST4K SU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMSBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlw cm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShz KSB4IDIgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJ RDogIDEKeDg2YmlvczogIElWVCAweDAwMDAwMC0weDAwMDRmZiBhdCAweGZmZmZmZTAwMDAwMDAw MDAKeDg2YmlvczogU1NFRyAweDAwMTAwMC0weDAwMWZmZiBhdCAweGZmZmZmZjgwMDAyMGQwMDAK eDg2YmlvczogRUJEQSAweDA5ZjAwMC0weDA5ZmZmZiBhdCAweGZmZmZmZTAwMDAwOWYwMDAKeDg2 YmlvczogIFJPTSAweDBhMDAwMC0weDBmZWZmZiBhdCAweGZmZmZmZTAwMDAwYTAwMDAKQVBJQzog Q1BVIDAgaGFzIEFDUEkgSUQgMApBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAxClVMRTogc2V0dXAg Y3B1IDAKVUxFOiBzZXR1cCBjcHUgMQpBQ1BJOiBSU0RQIDB4ZjdmODAgMDAwMTQgKHYwMCBIUC1D UEMpCkFDUEk6IFJTRFQgMHg3ZmVlMzA0MCAwMDAzMCAodjAxIEhQLUNQQyBBV1JEQUNQSSA0MjMw MkUzMSBBV1JEIDAwMDAwMDAwKQpBQ1BJOiBGQUNQIDB4N2ZlZTMwYzAgMDAwNzQgKHYwMSBIUC1D UEMgQVdSREFDUEkgNDIzMDJFMzEgQVdSRCAwMDAwMDAwMCkKQUNQSTogRFNEVCAweDdmZWUzMTgw IDA1NTI5ICh2MDEgSFAtQ1BDIEFXUkRBQ1BJIDAwMDAxMDAwIE1TRlQgMDEwMDAwMEUpCkFDUEk6 IEZBQ1MgMHg3ZmVlMDAwMCAwMDA0MApBQ1BJOiBNQ0ZHIDB4N2ZlZTg4MDAgMDAwM0MgKHYwMSBI UC1DUEMgQVdSREFDUEkgNDIzMDJFMzEgQVdSRCAwMDAwMDAwMCkKQUNQSTogQVBJQyAweDdmZWU4 NzAwIDAwMDg0ICh2MDEgSFAtQ1BDIEFXUkRBQ1BJIDQyMzAyRTMxIEFXUkQgMDAwMDAwMDApCk1B RFQ6IEZvdW5kIElPIEFQSUMgSUQgNCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMw OiBDaGFuZ2luZyBBUElDIElEIHRvIDQKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdz IC0+IGludHBpbiAwCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlv YXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRl OiBzb3VyY2UgOSwgaXJxIDkKaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwKbGFwaWMw OiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzA6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWMw OiBMSU5UMSBwb2xhcml0eTogaGlnaApsYXBpYzE6IFJvdXRpbmcgTk1JIC0+IExJTlQxCmxhcGlj MTogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzE6IExJTlQxIHBvbGFyaXR5OiBoaWdoCk1BRFQ6 IElnbm9yaW5nIGxvY2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBDUFUgMgpNQURUOiBJZ25vcmluZyBs b2NhbCBOTUkgcm91dGVkIHRvIEFDUEkgQ1BVIDMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjog MHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAw MTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgog IHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6 IDB4MDAwMTA0MDAKc25kX3VuaXRfaW5pdCgpIHU9MHgwMGZmODAwMCBbNTEyXSBkPTB4MDAwMDdj MDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdCmZlZWRlcl9yZWdpc3Rlcjogc25kX3VuaXQ9LTEg c25kX21heGF1dG92Y2hhbnM9MTYgbGF0ZW5jeT01IGZlZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9y YXRlX21heD0yMDE2MDAwIGZlZWRlcl9yYXRlX3JvdW5kPTI1CndsYW46IDw4MDIuMTEgTGluayBM YXllcj4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+CmtiZDogbmV3 IGFycmF5IHNpemUgNAprYmQxIGF0IGtiZG11eDAKbmZzbG9jazogcHNldWRvLWRldmljZQptZW06 IDxtZW1vcnk+CmlvOiA8SS9PPgpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpocHRy cjogUm9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCmFjcGkw OiA8SFAtQ1BDIEFXUkRBQ1BJPiBvbiBtb3RoZXJib2FyZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNv bmZpZ3VyYXRpb24gYmFzZSBAIDB4ZjAwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAo SVNBIElSUSA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhl ZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2Vy dmF0aW9uIG9mIDEwMDAwMCwgN2ZkZTAwMDAgKDMpIGZhaWxlZApBQ1BJIHRpbWVyOiAxLzAgMS8w IDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEkt ZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwyNC1i aXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0MDgtMHg0MGIgb24gYWNwaTAKY3B1MDog PEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUwOiBzd2l0Y2hpbmcgdG8gZ2VuZXJpYyBDeCBtb2RlCmNw dTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpX2xpbmswOiAgICAgICAgSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgNyAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA3ICAgTiAgICAg MCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiAgICAgICAgSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsy OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0 ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQg MTUKcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFs IFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMiAxNCAxNQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEy IDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkg MTAgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAx MSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms2OiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJs ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xp bms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyIDE0IDE1CiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIg MTQgMTUKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkg SG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaWIwOiBkZWNvZGlu ZyA0IHJhbmdlIDAtMHhjZjcKcGNpYjA6IGRlY29kaW5nIDQgcmFuZ2UgMHhkMDAtMHhmZmZmCnBj aWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4YTAwMDAtMHhiZmZmZgpwY2liMDogZGVjb2RpbmcgMyBy YW5nZSAweGMwMDAwLTB4ZGZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHg3ZmYwMDAwMC0w eGZlYmZmZmZmCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IGRvbWFpbj0wLCBw aHlzaWNhbCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3NzAsIHJldmlkPTB4 ODEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4Mjc3MSwgcmV2 aWQ9MHg4MQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDggKDIw MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NwoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQQpwY2liMDogc2xvdCAxIElOVEEgaGFyZHdpcmVk IHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZDgsIHJldmlkPTB4MDEK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNywgZnVuYz0wCgljbGFzcz0wNC0wMy0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEw XTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmRmZjgwMDAsIHNpemUgMTQsIGVuYWJs ZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmRmZjgwMDAtMHhmZGZmYmZmZikgZm9yIHJp ZCAxMCBvZiBwY2kwOjA6Mjc6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNy5JTlRBCnBj aWIwOiBzbG90IDI3IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDI3YzgsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVu Yz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1 LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGly cT0yNTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmYwMCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZjAwLTB4ZmYxZikgZm9y IHJpZCAyMCBvZiBwY2kwOjA6Mjk6MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3Yzks IHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0xCgljbGFzcz0wYy0w My0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0yNTUKCW1hcFsyMF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmUwMCwgc2l6ZSAgNSwgZW5hYmxlZApw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZTAwLTB4ZmUxZikgZm9yIHJpZCAyMCBvZiBwY2kw OjA6Mjk6MQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3Y2EsIHJldmlkPTB4MDEKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0yCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0yNTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4ZmQwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk IHR5cGUgNCAoMHhmZDAwLTB4ZmQxZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6Mgpmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDI3Y2IsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0yOSwgZnVuYz0zCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ aW50cGluPWQsIGlycT0yNTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4ZmMwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmYzAw LTB4ZmMxZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6Mwpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI3Y2MsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz03 CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBz dGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0y NTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlw ZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmRmZmYwMDAsIHNpemUgMTAsIGVuYWJsZWQKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmRmZmYwMDAtMHhmZGZmZjNmZikgZm9yIHJpZCAxMCBv ZiBwY2kwOjA6Mjk6Nwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0NGUsIHJldmlkPTB4 ZTEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMSwgaGRy dHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3YjgsIHJl dmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0wNi0wMS0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3 ZGYsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0w MS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4 MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDQgKDB4MWYwLTB4MWY3KSBmb3IgcmlkIDEwIG9mIHBjaTA6MDozMTox CnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNmNi0weDNmNikgZm9yIHJpZCAxNCBvZiBwY2kw OjA6MzE6MQpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxNzAtMHgxNzcpIGZvciByaWQgMTgg b2YgcGNpMDowOjMxOjEKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4Mzc2LTB4Mzc2KSBmb3Ig cmlkIDFjIG9mIHBjaTA6MDozMToxCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweGZiMDAsIHNpemUgIDQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4 ZmIwMC0weGZiMGYpIGZvciByaWQgMjAgb2YgcGNpMDowOjMxOjEKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyN2MwLCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9MgoJY2xhc3M9MDEtMDEtOGYsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Nywgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBp cnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmYTAwLCBzaXplICAzLCBlbmFibGVkCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZhMDAtMHhmYTA3KSBmb3IgcmlkIDEwIG9mIHBjaTA6 MDozMToyCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGY5MDAsIHNp emUgIDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZjkwMC0weGY5MDMpIGZv ciByaWQgMTQgb2YgcGNpMDowOjMxOjIKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ZjgwMCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAo MHhmODAwLTB4ZjgwNykgZm9yIHJpZCAxOCBvZiBwY2kwOjA6MzE6MgoJbWFwWzFjXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmNzAwLCBzaXplICAyLCBlbmFibGVkCnBjaWIwOiBh bGxvY2F0ZWQgdHlwZSA0ICgweGY3MDAtMHhmNzAzKSBmb3IgcmlkIDFjIG9mIHBjaTA6MDozMToy CgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGY2MDAsIHNpemUgIDQs IGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZjYwMC0weGY2MGYpIGZvciByaWQg MjAgb2YgcGNpMDowOjMxOjIKCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGZkZmZlMDAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZk ZmZlMDAwLTB4ZmRmZmUzZmYpIGZvciByaWQgMjQgb2YgcGNpMDowOjMxOjIKcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMzEuSU5UQgpwY2liMDogc2xvdCAzMSBJTlRCIGhhcmR3aXJlZCB0byBJ UlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2RhLCByZXZpZD0weDAxCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MjU1CgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweDUwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5 cGUgNCAoMHg1MDAtMHg1MWYpIGZvciByaWQgMjAgb2YgcGNpMDowOjMxOjMKcGNpYjE6IDxQQ0kt UENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2liMDogYWxsb2NhdGVk IHR5cGUgNCAoMHhkMDAwLTB4ZGZmZikgZm9yIHJpZCAxYyBvZiBwY2liMQpwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhmZGMwMDAwMC0weGZkY2ZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWIxCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGUwMDAwMDAwLTB4ZWZmZmZmZmYpIGZvciByaWQgMjQg b2YgcGNpYjEKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkg YnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29k ZSAgICAgICAgMHhkMDAwLTB4ZGZmZgpwY2liMTogICBtZW1vcnkgZGVjb2RlICAgICAweGZkYzAw MDAwLTB4ZmRjZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhlMDAwMDAwMC0weGVm ZmZmZmZmCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBkb21haW49MCwgcGh5c2ljYWwg YnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg3MTQ2LCByZXZpZD0weDAwCglkb21h aW49MCwgYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEg RDIgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEw XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGUwMDAwMDAwLCBz aXplIDI4LCBlbmFibGVkCnBjaWIxOiBhbGxvY2F0ZWQgcHJlZmV0Y2ggcmFuZ2UgKDB4ZTAwMDAw MDAtMHhlZmZmZmZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjE6MDowCgltYXBbMThdOiB0eXBlIE1l bW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZGNmMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMTog YWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmZGNmMDAwMC0weGZkY2ZmZmZmKSBmb3IgcmlkIDE4 IG9mIHBjaTA6MTowOjAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 ZGUwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTogYWxsb2NhdGVkIEkvTyBwb3J0IHJhbmdlICgw eGRlMDAtMHhkZWZmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MTowOjAKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMS5JTlRBCnBjaWIwOiBzbG90IDEgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnBj aWIxOiBzbG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2CmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NzE2NiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90PTAsIGZ1bmM9 MQoJY2xhc3M9MDMtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMCwg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJh bmdlIDY0LCBiYXNlIDB4ZmRjZTAwMDAsIHNpemUgMTYsIG1lbW9yeSBkaXNhYmxlZApwY2liMTog YWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmZGNlMDAwMC0weGZkY2VmZmZmKSBmb3IgcmlkIDEw IG9mIHBjaTA6MTowOjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhk ZTAwLTB4ZGVmZiBtZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmLDB4ZmRjZjAwMDAtMHhmZGNmZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBk aXNwbGF5PiBtZW0gMHhmZGNlMDAwMC0weGZkY2VmZmZmIGF0IGRldmljZSAwLjEgb24gcGNpMQpo ZGFjMDogPEludGVsIDgyODAxRyBIaWdoIERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVt IDB4ZmRmZjgwMDAtMHhmZGZmYmZmZiBpcnEgMTYgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFj MDogSERBIERyaXZlciBSZXZpc2lvbjogMjAxMDAyMjZfMDE0MgpoZGFjMDogYXR0ZW1wdGluZyB0 byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiByb3V0aW5nIE1TSSBJ UlEgMjU2IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNDkKaGRhYzA6IHVzaW5nIElSUSAyNTYgZm9y IE1TSQpoZGFjMDogQ2FwczogT1NTIDQsIElTUyA0LCBCU1MgMCwgTlNETyAxLCA2NGJpdCwgQ09S QiAyNTYsIFJJUkIgMjU2CnVoY2kwOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxl ciBVU0ItQT4gcG9ydCAweGZmMDAtMHhmZjFmIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJl ZCB0byBJUlEgMjMKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIGxh cGljIDAgdmVjdG9yIDUwCnVzYnVzMDogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xs ZXIgVVNCLUE+IG9uIHVoY2kwCnVzYnVzMDogYnBmIGF0dGFjaGVkCnVoY2kwOiB1c2JwZjogQXR0 YWNoZWQKdWhjaTE6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBw b3J0IDB4ZmUwMC0weGZlMWYgYXQgZGV2aWNlIDI5LjEgb24gcGNpMApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVkIHRvIElSUSAx OQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOSAoUENJIElSUSAxOSkgdG8gbGFwaWMgMCB2ZWN0 b3IgNTEKdXNidXMxOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQj4g b24gdWhjaTEKdXNidXMxOiBicGYgYXR0YWNoZWQKdWhjaTE6IHVzYnBmOiBBdHRhY2hlZAp1aGNp MjogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQgMHhmZDAw LTB4ZmQxZiBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjI5LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4KSB0byBsYXBpYyAwIHZlY3RvciA1Mgp1c2J1 czI6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1 c2J1czI6IGJwZiBhdHRhY2hlZAp1aGNpMjogdXNicGY6IEF0dGFjaGVkCnVoY2kzOiA8SW50ZWwg ODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweGZjMDAtMHhmYzFmIGF0 IGRldmljZSAyOS4zIG9uIHBjaTAKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5URApw Y2liMDogc2xvdCAyOSBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTYKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTYgKFBDSSBJUlEgMTYpIHRvIGxhcGljIDAgdmVjdG9yIDUzCnVzYnVzMzogPEludGVs IDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IG9uIHVoY2kzCnVzYnVzMzogYnBm IGF0dGFjaGVkCnVoY2kzOiB1c2JwZjogQXR0YWNoZWQKZWhjaTA6IDxJbnRlbCA4MjgwMUdCL1Ig KElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmRmZmYwMDAtMHhmZGZmZjNmZiBhdCBk ZXZpY2UgMjkuNyBvbiBwY2kwCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNp YjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzCnVzYnVzNDogRUhDSSB2ZXJzaW9u IDEuMAp1c2J1czQ6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4g b24gZWhjaTAKdXNidXM0OiBicGYgYXR0YWNoZWQKZWhjaTA6IHVzYnBmOiBBdHRhY2hlZApwY2li MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDQgKDB4ZTAwMC0weGVmZmYpIGZvciByaWQgMWMgb2YgcGNpYjIKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmRlMDAwMDAtMHhmZGVmZmZmZikgZm9yIHJpZCAyMCBvZiBw Y2liMgpwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhmZGQwMDAwMC0weGZkZGZmZmZmKSBmb3Ig cmlkIDI0IG9mIHBjaWIyCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAgc2Vj b25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4ZTAwMC0weGVmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAg MHhmZGUwMDAwMC0weGZkZWZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmRkMDAw MDAtMHhmZGRmZmZmZgpwY2liMjogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpwY2ky OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTIK Zm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDFiLCByZXZpZD0weDAxCglkb21haW49MCwg YnVzPTIsIHNsb3Q9NCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTggKGR3b3JkcykK CWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDBhICgyNTAwIG5zKSwgbWF4bGF0PTB4 MWMgKDcwMDAgbnMpCglpbnRwaW49YSwgaXJxPTcKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmRl ZTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjI6IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4 ZmRlZTAwMDAtMHhmZGVlZmZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjI6NDowCnBjaWIyOiBtYXRj aGVkIGVudHJ5IGZvciAyLjQuSU5UQQpwY2liMjogc2xvdCA0IElOVEEgaGFyZHdpcmVkIHRvIElS USAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZGMsIHJldmlkPTB4MDEKCWRvbWFp bj0wLCBidXM9Miwgc2xvdD04LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdv cmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhs YXQ9MHgzOCAoMTQwMDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGZkZWZmMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQgbWVt b3J5IHJhbmdlICgweGZkZWZmMDAwLTB4ZmRlZmZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDoyOjg6 MAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlZjAwLCBzaXplICA2 LCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQgSS9PIHBvcnQgcmFuZ2UgKDB4ZWYwMC0weGVmM2Yp IGZvciByaWQgMTQgb2YgcGNpMDoyOjg6MApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi44LklO VEEKcGNpYjI6IHNsb3QgOCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjAKYXRoMDogPEF0aGVyb3Mg NTQxMz4gbWVtIDB4ZmRlZTAwMDAtMHhmZGVlZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDQuMCBvbiBw Y2kyCmFyNTIxMkNoaXBUZXN0OiBhZGRyZXNzIHRlc3QgZmFpbGVkIGFkZHI6IDB4MDAwMDgwMDAg LSB3cjoweDAwMDAwMDAwICE9IHJkOjB4ZmZmZmZmZmYKYXI1MjEyQXR0YWNoOiBoYXJkd2FyZSBz ZWxmLXRlc3QgZmFpbGVkCmF0aDA6IHVuYWJsZSB0byBhdHRhY2ggaGFyZHdhcmU7IEhBTCBzdGF0 dXMgMTQKZGV2aWNlX2F0dGFjaDogYXRoMCBhdHRhY2ggcmV0dXJuZWQgNgpmeHAwOiA8SW50ZWwg ODI4MDFHQiAoSUNINykgMTAvMTAwIEV0aGVybmV0PiBwb3J0IDB4ZWYwMC0weGVmM2YgbWVtIDB4 ZmRlZmYwMDAtMHhmZGVmZmZmZiBpcnEgMjAgYXQgZGV2aWNlIDguMCBvbiBwY2kyCmZ4cDA6IHVz aW5nIG1lbW9yeSBzcGFjZSByZWdpc3RlciBtYXBwaW5nCmZ4cDA6IFBDSSBJRHM6IDgwODYgMjdk YyAxMDNjIDJhMjIgMDAwMQpmeHAwOiBEeW5hbWljIFN0YW5kYnkgbW9kZSBpcyBlbmFibGVkCm1p aWJ1czA6IDxNSUkgYnVzPiBvbiBmeHAwCmlucGh5MDogPGk4MjU2MkVUIDEwLzEwMCBtZWRpYSBp bnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKaW5waHkwOiBPVUkgMHgwMDU1MDAsIG1vZGVsIDB4 MDAzMywgcmV2LiAwCmlucGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEw MGJhc2VUWC1GRFgsIGF1dG8sIGF1dG8tZmxvdwpmeHAwOiBicGYgYXR0YWNoZWQKZnhwMDogRXRo ZXJuZXQgYWRkcmVzczogMDA6MTU6ZjI6MDY6YTM6YTQKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MjAgKFBDSSBJUlEgMjApIHRvIGxhcGljIDAgdmVjdG9yIDU0CmlzYWIwOiA8UENJLUlTQSBicmlk Z2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBj aTA6IDxJbnRlbCBJQ0g3IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNm NiwweDE3MC0weDE3NywweDM3NiwweGZiMDAtMHhmYjBmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAK YXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MTQgKElTQSBJUlEgMTQpIHRvIGxhcGljIDAgdmVjdG9yIDU1CmF0YXBjaTE6IDxJbnRlbCBJQ0g3 IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGZhMDAtMHhmYTA3LDB4ZjkwMC0weGY5MDMsMHhm ODAwLTB4ZjgwNywweGY3MDAtMHhmNzAzLDB4ZjYwMC0weGY2MGYgbWVtIDB4ZmRmZmUwMDAtMHhm ZGZmZTNmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGEyOiA8QVRBIGNoYW5uZWwg MD4gb24gYXRhcGNpMQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQpwY2kwOiA8c2Vy aWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlf dHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4 NDAtMHg0MyBpcnEgMCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkz MTgyIEh6IHF1YWxpdHkgMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyIChJU0EgSVJRIDApIHRv IGxhcGljIDAgdmVjdG9yIDU2CkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAxMDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcz IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2Nr IChyZXNvbHV0aW9uIDEwMDAwMDB1cywgYWRqdXN0bWVudCAwLjUwMDAwMDAwMHMpCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDggKElTQSBJUlEgOCkgdG8gbGFwaWMgMCB2ZWN0b3IgNTcKRXZlbnQg dGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApwcGMxOiB1c2luZyBleHRl bmRlZCBJL08gcG9ydCByYW5nZQpwcGMxOiBTUFAgRUNQICBFQ1ArRVBQCnBwYzE6IDxQYXJhbGxl bCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4NzdiIGlycSA1IGRycSAzIG9uIGFjcGkw CnBwYzE6IFNNQy1saWtlIGNoaXBzZXQgKEVDUC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJM RSBtb2RlCnBwYzE6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiA1IChJU0EgSVJRIDUpIHRvIGxhcGljIDAgdmVjdG9yIDU4CnBwYnVzMDog PFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMxCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFj ZT4gb24gcHBidXMwCnBsaXAwOiBicGYgYXR0YWNoZWQKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVz MApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBi dXMwCmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGZmZmZmZjgwOWU4ZTMwMDAgcGEgMHg0MDAwCmV4 X2lzYV9pZGVudGlmeSgpCmFoY19pc2FfcHJvYmUgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxl ZAphaGNfaXNhX3Byb2JlIDE6IGlvcG9ydCAweDFjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJv YmUgMjogaW9wb3J0IDB4MmMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSAzOiBpb3BvcnQg MHgzYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDQ6IGlvcG9ydCAweDRjMDAgYWxsb2Mg ZmFpbGVkCmFoY19pc2FfcHJvYmUgNTogaW9wb3J0IDB4NWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lz YV9wcm9iZSA2OiBpb3BvcnQgMHg2YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDc6IGlv cG9ydCAweDdjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgODogaW9wb3J0IDB4OGMwMCBh bGxvYyBmYWlsZWQKYWhjX2lzYV9wcm9iZSA5OiBpb3BvcnQgMHg5YzAwIGFsbG9jIGZhaWxlZAph aGNfaXNhX3Byb2JlIDEwOiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2Jl IDExOiBpb3BvcnQgMHhiYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEyOiBpb3BvcnQg MHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEzOiBpb3BvcnQgMHhkYzAwIGFsbG9j IGZhaWxlZAphaGNfaXNhX3Byb2JlIDE0OiBpb3BvcnQgMHhlYzAwIGFsbG9jIGZhaWxlZApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMDAwMC0weGEwN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMDgwMC0weGEwZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMTAwMC0weGExN2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMTgwMC0weGExZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMjAwMC0weGEyN2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMjgwMC0weGEyZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMzAwMC0weGEzN2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMzgwMC0weGEzZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNDAwMC0weGE0 N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNDgwMC0w eGE0ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNTAw MC0weGE1N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhh NTgwMC0weGE1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhhNjAwMC0weGE2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhhNjgwMC0weGE2ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhhNzAwMC0weGE3N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhhNzgwMC0weGE3ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhhODAwMC0weGE4N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhhODgwMC0weGE4ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhhOTAwMC0weGE5N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhOTgwMC0weGE5ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYTAwMC0weGFhN2ZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYTgwMC0weGFhZmZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYjAwMC0weGFiN2ZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYjgwMC0weGFiZmZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYzAwMC0weGFjN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYzgwMC0weGFjZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhZDAwMC0weGFkN2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhZDgwMC0weGFk ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhZTAwMC0w eGFlN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhZTgw MC0weGFlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhh ZjAwMC0weGFmN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhhZjgwMC0weGFmZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhiMDAwMC0weGIwN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhiMDgwMC0weGIwZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhiMTAwMC0weGIxN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhiMTgwMC0weGIxZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhiMjAwMC0weGIyN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhiMjgwMC0weGIyZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMzAwMC0weGIzN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMzgwMC0weGIzZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNDAwMC0weGI0N2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNDgwMC0weGI0ZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNTAwMC0weGI1N2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNTgwMC0weGI1ZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNjAwMC0weGI2N2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNjgwMC0weGI2ZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNzAwMC0weGI3 N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNzgwMC0w eGI3ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiODAw MC0weGI4N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhi ODgwMC0weGI4ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhiOTAwMC0weGI5N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhiOTgwMC0weGI5ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhiYTAwMC0weGJhN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhiYTgwMC0weGJhZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhiYjAwMC0weGJiN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhiYjgwMC0weGJiZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhiYzAwMC0weGJjN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYzgwMC0weGJjZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZDAwMC0weGJkN2ZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZDgwMC0weGJkZmZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZTAwMC0weGJlN2ZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZTgwMC0weGJlZmZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZjAwMC0weGJmN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZjgwMC0weGJmZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjMDAwMC0weGMwN2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjMDgwMC0weGMw ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjMTAwMC0w eGMxN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjMTgw MC0weGMxZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhj MjAwMC0weGMyN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhjMjgwMC0weGMyZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhjMzAwMC0weGMzN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhjMzgwMC0weGMzZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhjNDAwMC0weGM0N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhjNDgwMC0weGM0ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhjNTAwMC0weGM1N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhjNTgwMC0weGM1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNjAwMC0weGM2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNjgwMC0weGM2ZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNzAwMC0weGM3N2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNzgwMC0weGM3ZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjODAwMC0weGM4N2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjODgwMC0weGM4ZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjOTAwMC0weGM5N2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjOTgwMC0weGM5ZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjYTAwMC0weGNh N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjYTgwMC0w eGNhZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjYjAw MC0weGNiN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhj YjgwMC0weGNiZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhjYzAwMC0weGNjN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhjYzgwMC0weGNjZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhjZDAwMC0weGNkN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhjZDgwMC0weGNkZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhjZTAwMC0weGNlN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhjZTgwMC0weGNlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhjZjgwMC0weGNmZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMDAwMC0weGQwN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMDgwMC0weGQwZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMTAwMC0weGQxN2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMTgwMC0weGQxZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMjAwMC0weGQyN2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMjgwMC0weGQyZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMzAwMC0weGQzN2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMzgwMC0weGQzZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNDAwMC0weGQ0 N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNDgwMC0w eGQ0ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNTAw MC0weGQ1N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk NTgwMC0weGQ1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhkNjAwMC0weGQ2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhkNjgwMC0weGQ2ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhkNzAwMC0weGQ3N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhkNzgwMC0weGQ3ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhkODAwMC0weGQ4N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhkODgwMC0weGQ4ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhkOTAwMC0weGQ5N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkOTgwMC0weGQ5ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYTAwMC0weGRhN2ZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYTgwMC0weGRhZmZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYjAwMC0weGRiN2ZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYjgwMC0weGRiZmZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYzAwMC0weGRjN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYzgwMC0weGRjZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkZDAwMC0weGRkN2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkZDgwMC0weGRk ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkZTAwMC0w eGRlN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkZTgw MC0weGRlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk ZjAwMC0weGRmN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhkZjgwMC0weGRmZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMAppc2FfcHJvYmVfY2hpbGRyZW46IGRp c2FibGluZyBQblAgZGV2aWNlcwphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu ZyBpdAphdHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNj MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5n IG5vbi1QblAgZGV2aWNlcwphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFu ZCBieXRlIDAwNDcKYXRrYmQ6IGtleWJvYXJkIElEIDB4ZmZmZmZmZmYgKDEpCmF0a2JkOiBmYWls ZWQgdG8gcmVzZXQgdGhlIGtleWJvYXJkLgpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWlu YWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhh MDAwMC0weGJmZmZmIG9uIGlzYTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2MwLTB4M2Rm KSBmb3IgcmlkIDAgb2YgdmdhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMDAwMC0weGJm ZmZmKSBmb3IgcmlkIDAgb2YgdmdhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg2MC0weDYw KSBmb3IgcmlkIDAgb2YgYXRrYmRjMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHg2NC0weDY0 KSBmb3IgcmlkIDEgb2YgYXRrYmRjMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgw eDYwLTB4NjApIGZvciByaWQgMCBvZiBhdGtiZGMwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgw eDY0LTB4NjQpIGZvciByaWQgMSBvZiBhdGtiZGMwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQgODQgKDEpLCBjb25m aWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJR IDEpIHRvIGxhcGljIDAgdmVjdG9yIDU5CmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogdW5h YmxlIHRvIGFsbG9jYXRlIElSUQpwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjAtMHgzZjUp IGZvciByaWQgMCBvZiBmZGMwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNmNy0weDNmNykg Zm9yIHJpZCAxIG9mIGZkYzAKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNm NSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0 IHJhbmdlCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24g aXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjgtMHgzZmYpIGZvciByaWQgMCBvZiB1 YXJ0MAp1YXJ0MDogPG5zODI1MD4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjgtMHgzZmYg aXJxIDQgb24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgyZjgtMHgyZmYpIGZvciBy aWQgMCBvZiB1YXJ0MQp1YXJ0MTogPG5zODI1MD4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgy ZjgtMHgyZmYgaXJxIDMgb24gaXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRl dmljZXMKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKcDR0 Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKRGV2aWNlIGNvbmZp Z3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZy ZXF1ZW5jeSAxMDAwMzA3MzEgSHoKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2 bGFuOiBpbml0aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwpsbzA6IGJw ZiBhdHRhY2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KaGRhYzA6IFByb2Jpbmcg Y29kZWMgIzIuLi4KaGRhYzA6IEhEQSBDb2RlYyAjMjogUmVhbHRlayBBTEM4ODIKaGRhYzA6ICBI REEgQ29kZWMgSUQ6IDB4MTBlYzA4ODIKaGRhYzA6ICAgICAgICBWZW5kb3I6IDB4MTBlYwpoZGFj MDogICAgICAgIERldmljZTogMHgwODgyCmhkYWMwOiAgICAgIFJldmlzaW9uOiAweDAxCmhkYWMw OiAgICAgIFN0ZXBwaW5nOiAweDAxCmhkYWMwOiBQQ0kgU3VidmVuZG9yOiAweDJhMjMxMDNjCmhk YWMwOiAJRm91bmQgYXVkaW8gRkcgbmlkPTEgc3RhcnRub2RlPTIgZW5kbm9kZT0zOSB0b3RhbD0z NwpoZGFjMDogCmhkYWMwOiBQcm9jZXNzaW5nIGF1ZGlvIEZHIGNhZD0yIG5pZD0xLi4uCmhkYWMw OiBHUElPOiAweDQwMDAwMDAyIE51bUdQSU89MiBOdW1HUE89MCBOdW1HUEk9MCBHUElXYWtlPTAg R1BJVW5zb2w9MQpoZGFjMDogIG5pZCAyMCAweDAxMDE0MTEwIGFzICAxIHNlcSAgMCAgICAgIExp bmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgR3JlZW4gbWlzYyAxCmhkYWMwOiAg bmlkIDIxIDB4MDEwMTExMTIgYXMgIDEgc2VxICAyICAgICAgTGluZS1vdXQgIEphY2sgamFjayAg MSBsb2MgIDEgY29sb3IgICBCbGFjayBtaXNjIDEKaGRhYzA6ICBuaWQgMjIgMHgwMTAxNjExMSBh cyAgMSBzZXEgIDEgICAgICBMaW5lLW91dCAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgT3Jh bmdlIG1pc2MgMQpoZGFjMDogIG5pZCAyMyAweDAxMDEyMTE0IGFzICAxIHNlcSAgNCAgICAgIExp bmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEdyZXkgbWlzYyAxCmhkYWMwOiAg bmlkIDI0IDB4MDFhMTk5MzIgYXMgIDMgc2VxICAyICAgICAgICAgICBNaWMgIEphY2sgamFjayAg MSBsb2MgIDEgY29sb3IgICAgUGluayBtaXNjIDkKaGRhYzA6ICBuaWQgMjUgMHgwMmExOWM0MCBh cyAgNCBzZXEgIDAgICAgICAgICAgIE1pYyAgSmFjayBqYWNrICAxIGxvYyAgMiBjb2xvciAgICBQ aW5rIG1pc2MgMTIKaGRhYzA6ICBuaWQgMjYgMHgwMTgxMzEzMCBhcyAgMyBzZXEgIDAgICAgICAg TGluZS1pbiAgSmFjayBqYWNrICAxIGxvYyAgMSBjb2xvciAgICBCbHVlIG1pc2MgMQpoZGFjMDog IG5pZCAyNyAweDAyMjE0YzIwIGFzICAyIHNlcSAgMCAgICBIZWFkcGhvbmVzICBKYWNrIGphY2sg IDEgbG9jICAyIGNvbG9yICAgR3JlZW4gbWlzYyAxMgpoZGFjMDogIG5pZCAyOCAweDk5MzMxMTMx IGFzICAzIHNlcSAgMSAgICAgICAgICAgIENEIEZpeGVkIGphY2sgIDMgbG9jIDI1IGNvbG9yICAg QmxhY2sgbWlzYyAxCmhkYWMwOiBQYXRjaGluZyB3aWRnZXQgY2FwcyBuaWQ9MjkgMHgwMDQwMDAw MCAtPiAweDAwNzAwMDAwCmhkYWMwOiAgbmlkIDMwIDB4MDE0NDExMWUgYXMgIDEgc2VxIDE0ICAg ICBTUERJRi1vdXQgIEphY2sgamFjayAgNCBsb2MgIDEgY29sb3IgICBCbGFjayBtaXNjIDEKaGRh YzA6ICBuaWQgMzEgMHgwMWM0NjE1MCBhcyAgNSBzZXEgIDAgICAgICBTUERJRi1pbiAgSmFjayBq YWNrICA0IGxvYyAgMSBjb2xvciAgT3JhbmdlIG1pc2MgMQpoZGFjMDogUGF0Y2hlZCBwaW5zIGNv bmZpZ3VyYXRpb246CmhkYWMwOiAgbmlkIDIwIDB4MDEwMTQxMTAgYXMgIDEgc2VxICAwICAgICAg TGluZS1vdXQgIEphY2sgamFjayAgMSBsb2MgIDEgY29sb3IgICBHcmVlbiBtaXNjIDEKaGRhYzA6 ICBuaWQgMjEgMHgwMTAxMTExMiBhcyAgMSBzZXEgIDIgICAgICBMaW5lLW91dCAgSmFjayBqYWNr ICAxIGxvYyAgMSBjb2xvciAgIEJsYWNrIG1pc2MgMQpoZGFjMDogIG5pZCAyMiAweDAxMDE2MTEx IGFzICAxIHNlcSAgMSAgICAgIExpbmUtb3V0ICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICBP cmFuZ2UgbWlzYyAxCmhkYWMwOiAgbmlkIDIzIDB4MDEwMTIxMTQgYXMgIDEgc2VxICA0ICAgICAg TGluZS1vdXQgIEphY2sgamFjayAgMSBsb2MgIDEgY29sb3IgICAgR3JleSBtaXNjIDEKaGRhYzA6 ICBuaWQgMjQgMHgwMWExOTkzMiBhcyAgMyBzZXEgIDIgICAgICAgICAgIE1pYyAgSmFjayBqYWNr ICAxIGxvYyAgMSBjb2xvciAgICBQaW5rIG1pc2MgOQpoZGFjMDogIG5pZCAyNSAweDAyYTE5YzQw IGFzICA0IHNlcSAgMCAgICAgICAgICAgTWljICBKYWNrIGphY2sgIDEgbG9jICAyIGNvbG9yICAg IFBpbmsgbWlzYyAxMgpoZGFjMDogIG5pZCAyNiAweDAxODEzMTMwIGFzICAzIHNlcSAgMCAgICAg ICBMaW5lLWluICBKYWNrIGphY2sgIDEgbG9jICAxIGNvbG9yICAgIEJsdWUgbWlzYyAxCmhkYWMw OiAgbmlkIDI3IDB4MDIyMTRjMjAgYXMgIDIgc2VxICAwICAgIEhlYWRwaG9uZXMgIEphY2sgamFj ayAgMSBsb2MgIDIgY29sb3IgICBHcmVlbiBtaXNjIDEyCmhkYWMwOiAgbmlkIDI4IDB4OTkzMzEx MzEgYXMgIDMgc2VxICAxICAgICAgICAgICAgQ0QgRml4ZWQgamFjayAgMyBsb2MgMjUgY29sb3Ig ICBCbGFjayBtaXNjIDEKaGRhYzA6ICBuaWQgMzAgMHgwMTQ0MTExZSBhcyAgMSBzZXEgMTQgICAg IFNQRElGLW91dCAgSmFjayBqYWNrICA0IGxvYyAgMSBjb2xvciAgIEJsYWNrIG1pc2MgMQpoZGFj MDogIG5pZCAzMSAweDAxYzQ2MTUwIGFzICA1IHNlcSAgMCAgICAgIFNQRElGLWluICBKYWNrIGph Y2sgIDQgbG9jICAxIGNvbG9yICBPcmFuZ2UgbWlzYyAxCmhkYWMwOiA1IGFzc29jaWF0aW9ucyBm b3VuZDoKaGRhYzA6IEFzc29jaWF0aW9uIDAgKDEpIG91dDoKaGRhYzA6ICBQaW4gbmlkPTIwIHNl cT0wCmhkYWMwOiAgUGluIG5pZD0yMiBzZXE9MQpoZGFjMDogIFBpbiBuaWQ9MjEgc2VxPTIKaGRh YzA6ICBQaW4gbmlkPTIzIHNlcT00CmhkYWMwOiAgUGluIG5pZD0zMCBzZXE9MTQKaGRhYzA6IEFz c29jaWF0aW9uIDEgKDIpIG91dDoKaGRhYzA6ICBQaW4gbmlkPTI3IHNlcT0wCmhkYWMwOiBBc3Nv Y2lhdGlvbiAyICgzKSBpbjoKaGRhYzA6ICBQaW4gbmlkPTI2IHNlcT0wCmhkYWMwOiAgUGluIG5p ZD0yOCBzZXE9MQpoZGFjMDogIFBpbiBuaWQ9MjQgc2VxPTIKaGRhYzA6IEFzc29jaWF0aW9uIDMg KDQpIGluOgpoZGFjMDogIFBpbiBuaWQ9MjUgc2VxPTAKaGRhYzA6IEFzc29jaWF0aW9uIDQgKDUp IGluOgpoZGFjMDogIFBpbiBuaWQ9MzEgc2VxPTAKaGRhYzA6IFRyYWNpbmcgYXNzb2NpYXRpb24g MCAoMSkKaGRhYzA6ICBQaW4gMjAgdHJhY2VkIHRvIERBQyAyCmhkYWMwOiAgUGluIDIyIHRyYWNl ZCB0byBEQUMgMwpoZGFjMDogIFBpbiAyMSB0cmFjZWQgdG8gREFDIDQKaGRhYzA6ICBQaW4gMjMg dHJhY2VkIHRvIERBQyA1CmhkYWMwOiAgUGluIDMwIHRyYWNlZCB0byBEQUMgNgpoZGFjMDogQXNz b2NpYXRpb24gMCAoMSkgdHJhY2Ugc3VjY2VlZGVkCmhkYWMwOiBUcmFjaW5nIGFzc29jaWF0aW9u IDEgKDIpCmhkYWMwOiAgUGluIDI3IHRyYWNlZCB0byBEQUMgMzcKaGRhYzA6IEFzc29jaWF0aW9u IDEgKDIpIHRyYWNlIHN1Y2NlZWRlZApoZGFjMDogVHJhY2luZyBhc3NvY2lhdGlvbiAyICgzKQpo ZGFjMDogIFBpbiAyNiB0cmFjZWQgdG8gQURDIDcKaGRhYzA6ICBQaW4gMjggdHJhY2VkIHRvIEFE QyA3CmhkYWMwOiAgUGluIDI0IHRyYWNlZCB0byBBREMgNwpoZGFjMDogQXNzb2NpYXRpb24gMiAo MykgdHJhY2Ugc3VjY2VlZGVkCmhkYWMwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDMgKDQpCmhkYWMw OiAgUGluIDI1IHRyYWNlZCB0byBBREMgOApoZGFjMDogQXNzb2NpYXRpb24gMyAoNCkgdHJhY2Ug c3VjY2VlZGVkCmhkYWMwOiBUcmFjaW5nIGFzc29jaWF0aW9uIDQgKDUpCmhkYWMwOiAgVW5hYmxl IHRvIHRyYWNlIHBpbiAzMSB0byBBREMgOSwgdW5kbyB0cmFjZXMKaGRhYzA6ICBQaW4gMzEgdHJh Y2VkIHRvIEFEQyAxMApoZGFjMDogQXNzb2NpYXRpb24gNCAoNSkgdHJhY2Ugc3VjY2VlZGVkCmhk YWMwOiBUcmFjaW5nIGlucHV0IG1vbml0b3IKaGRhYzA6ICBUcmFjaW5nIG5pZCAxMSB0byBvdXQK aGRhYzA6ICBuaWQgMTEgaXMgaW5wdXQgbW9uaXRvcgpoZGFjMDogIFRyYWNpbmcgbmlkIDM1IHRv IG91dApoZGFjMDogIFRyYWNpbmcgbmlkIDM2IHRvIG91dApoZGFjMDogVHJhY2luZyBvdGhlciBp bnB1dCBtb25pdG9ycwpoZGFjMDogIFRyYWNpbmcgbmlkIDI0IHRvIG91dApoZGFjMDogIFRyYWNp bmcgbmlkIDI1IHRvIG91dApoZGFjMDogIFRyYWNpbmcgbmlkIDI2IHRvIG91dApoZGFjMDogIFRy YWNpbmcgbmlkIDI4IHRvIG91dApoZGFjMDogIFRyYWNpbmcgbmlkIDMxIHRvIG91dApoZGFjMDog VHJhY2luZyBiZWVwZXIKaGRhYzA6IEZHIGNvbmZpZy9xdWlya3M6IGZvcmNlc3RlcmVvIGl2cmVm NTAgaXZyZWY4MCBpdnJlZjEwMCBpdnJlZgpoZGFjMDogCmhkYWMwOiArLS0tLS0tLS0tLS0tLS0t LS0tLSsKaGRhYzA6IHwgRFVNUElORyBIREEgTk9ERVMgfApoZGFjMDogKy0tLS0tLS0tLS0tLS0t LS0tLS0rCmhkYWMwOiAKaGRhYzA6IERlZmF1bHQgUGFyYW1ldGVyCmhkYWMwOiAtLS0tLS0tLS0t LS0tLS0tLQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAg ICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYwCmhkYWMwOiAg ICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKaGRhYzA6ICAg ICAgICAgIElOIGFtcDogMHgwMDAwMDAwMApoZGFjMDogICAgICAgICBPVVQgYW1wOiAweDAwMDAw MDAwCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMgpoZGFjMDogICAgICAgICAgICBO YW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAwMDAxMQpoZGFj MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgw MDAwMDAwMSkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChwY20pCmhkYWMwOiAgICAgIFN0 cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWMwOiAg ICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYgMjAg MjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6 IDMKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gb3V0cHV0CmhkYWMwOiAgICAgIFdpZGdl dCBjYXA6IDB4MDAwMDAwMTEKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAg ICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBj bSAocGNtKQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAg ICAgICAgICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwNTYwCmhkYWMwOiAg ICAgICAgICAgICAgICAgIDE2IDIwIDI0IGJpdHMsIDQ0IDQ4IDk2IDE5MiBLSHoKaGRhYzA6IApo ZGFjMDogICAgICAgICAgICAgbmlkOiA0CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91 dHB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDAwMDExCmhkYWMwOiAgICAgICAgICAg ICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAwICgweDAwMDAwMDA0KQpoZGFj MDogICAgICAgICAgICAgT1NTOiBwY20gKHBjbSkKaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgw MDAwMDAwMQpoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNh cDogMHgwMDBlMDU2MApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0 OCA5NiAxOTIgS0h6CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogNQpoZGFjMDogICAg ICAgICAgICBOYW1lOiBhdWRpbyBvdXRwdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDAw MDAxMQpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlv bjogMCAoMHgwMDAwMDAxMCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtIChwY20pCmhkYWMw OiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENN CmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKaGRhYzA6ICAgICAgICAgICAgICAg ICAgMTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpoZGFjMDogCmhkYWMwOiAgICAgICAg ICAgICBuaWQ6IDYKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gb3V0cHV0CmhkYWMwOiAg ICAgIFdpZGdldCBjYXA6IDB4MDAwMDAyMTEKaGRhYzA6ICAgICAgICAgICAgICAgICAgRElHSVRB TCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwNDAwMCkKaGRhYzA6ICAg ICAgICAgICAgIE9TUzogcGNtIChwY20pCmhkYWMwOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAw MDEKaGRhYzA6ICAgICAgICAgICAgICAgICAgUENNCmhkYWMwOiAgICAgICAgIFBDTSBjYXA6IDB4 MDAxZTA1NjAKaGRhYzA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgMzIgYml0cywgNDQgNDgg OTYgMTkyIEtIegpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDcKaGRhYzA6ICAgICAg ICAgICAgTmFtZTogYXVkaW8gaW5wdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDEx YgpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjog MiAoMHgwMDAwMDAwNykKaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFjMDog ICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNhcDogMHgwMDA2MDE2MApo ZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCBiaXRzLCA0NCA0OCA5NiBLSHoKaGRhYzA6ICAg ICAgIElucHV0IGFtcDogMHg4MDA1MWYwOApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEg c3RlcD0zMSBzaXplPTUgb2Zmc2V0PTgKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDog ICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0zNiBbYXVkaW8gbWl4ZXJdCmhk YWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogOApoZGFjMDogICAgICAgICAgICBOYW1lOiBh dWRpbyBpbnB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMTAwMTFiCmhkYWMwOiAgICAg ICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAzICgweDAwMDAwMDAx KQpoZGFjMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAg ICAgIFBDTQpoZGFjMDogICAgICAgICBQQ00gY2FwOiAweDAwMDYwMTYwCmhkYWMwOiAgICAgICAg ICAgICAgICAgIDE2IDIwIGJpdHMsIDQ0IDQ4IDk2IEtIegpoZGFjMDogICAgICAgSW5wdXQgYW1w OiAweDgwMDUxZjA4CmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMxIHNpemU9 NSBvZmZzZXQ9OApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAxCmhkYWMwOiAgICAgICAgICAgfApo ZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM1IFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDog ICAgICAgICAgICAgbmlkOiA5IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVk aW8gaW5wdXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDEwMDExYgpoZGFjMDogICAgICAg ICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFj MDogICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNhcDogMHgwMDA2MDE2 MApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCBiaXRzLCA0NCA0OCA5NiBLSHoKaGRhYzA6 ICAgICAgIElucHV0IGFtcDogMHg4MDA1MWYwOApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTgKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFj MDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTM0IFth dWRpbyBtaXhlcl0gW0RJU0FCTEVEXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDEw CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIGlucHV0CmhkYWMwOiAgICAgIFdpZGdldCBj YXA6IDB4MDAxMDAzOTEKaGRhYzA6ICAgICAgICAgICAgICAgICAgRElHSVRBTCBVTlNPTCBTVEVS RU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogNCAoMHgwMDAwMDAwMSkKaGRhYzA6ICAgICAgU3Ry ZWFtIGNhcDogMHgwMDAwMDAwMQpoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAg ICAgICAgUENNIGNhcDogMHgwMDFlMDU2MApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAy NCAzMiBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDEKaGRh YzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MzEgW3BpbjogU1BESUYt aW4gKE9yYW5nZSBKYWNrKV0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAxMQpoZGFj MDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwMjAwMTBiCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29j aWF0aW9uOiAyICgweDAwMDAwMDA3KQpoZGFjMDogICAgICAgICAgICAgT1NTOiBtaXggKG1peCkK aGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDA1MWYxNwpoZGFjMDogICAgICAgICAgICAgICAg ICBtdXRlPTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTIzCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6 IDEwCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46 IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI1 IFtwaW46IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yNiBbcGlu OiBMaW5lLWluIChCbHVlIEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MjcgW3BpbjogSGVhZHBob25lcyAoR3JlZW4gSmFjayldCmhkYWMwOiAgICAgICAgICAgKyA8 LSBuaWQ9MjggW3BpbjogQ0QgKEZpeGVkKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yOSBb YmVlcCB3aWRnZXRdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGlu OiBMaW5lLW91dCAoR3JlZW4gSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0yMSBbcGluOiBMaW5lLW91dCAoQmxhY2sgSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBb RElTQUJMRURdIDwtIG5pZD0yMiBbcGluOiBMaW5lLW91dCAoT3JhbmdlIEphY2spXQpoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFj ayldCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMTIKaGRhYzA6ICAgICAgICAgICAg TmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFj MDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgw MDAwMDAwMSkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKaGRhYzA6ICAgICAgT3V0 cHV0IGFtcDogMHgwMDA1MWYxZgpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0z MSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAwMDAwMDAKaGRh YzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYzA6 ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD0yIFthdWRpbyBvdXRwdXRdCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1 ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDEzCmhkYWMwOiAgICAg ICAgICAgIE5hbWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAx MGYKaGRhYzA6ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246 IDAgKDB4MDAwMDAwMDIpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHBjbSwgbWl4CmhkYWMwOiAg ICAgIE91dHB1dCBhbXA6IDB4MDAwNTFmMWYKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0w IHN0ZXA9MzEgc2l6ZT01IG9mZnNldD0zMQpoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAw MDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0w CmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDIKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9MyBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsgPC0gbmlk PTExIFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAxNApoZGFj MDogICAgICAgICAgICBOYW1lOiBhdWRpbyBtaXhlcgpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAw eDAwMjAwMTBmCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29j aWF0aW9uOiAwICgweDAwMDAwMDA0KQpoZGFjMDogICAgICAgICAgICAgT1NTOiBwY20sIG1peApo ZGFjMDogICAgICBPdXRwdXQgYW1wOiAweDAwMDUxZjFmCmhkYWMwOiAgICAgICAgICAgICAgICAg IG11dGU9MCBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9MzEKaGRhYzA6ICAgICAgIElucHV0IGFtcDog MHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBv ZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiAyCmhkYWMwOiAgICAgICAgICAgfApoZGFj MDogICAgICAgICAgICsgPC0gbmlkPTQgW2F1ZGlvIG91dHB1dF0KaGRhYzA6ICAgICAgICAgICAr IDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDog MTUKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0 IGNhcDogMHgwMDIwMDEwZgpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAg ICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwMDAxMCkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNt LCBtaXgKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MWYxZgpoZGFjMDogICAgICAgICAg ICAgICAgICBtdXRlPTAgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgICBJbnB1 dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBz aXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAg IHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD01IFthdWRpbyBvdXRwdXRdCmhkYWMwOiAgICAg ICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAg ICBuaWQ6IDE2IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdl dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAwMDAwCmhkYWMwOiAKaGRhYzA6ICAgICAg ICAgICAgIG5pZDogMTcgW0RJU0FCTEVEXQpoZGFjMDogICAgICAgICAgICBOYW1lOiB2ZW5kb3Ig d2lkZ2V0CmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDBmMDAwMDAKaGRhYzA6IApoZGFjMDog ICAgICAgICAgICAgbmlkOiAxOCBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHZl bmRvciB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMGYwMDAwMApoZGFjMDogCmhk YWMwOiAgICAgICAgICAgICBuaWQ6IDE5IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFt ZTogdmVuZG9yIHdpZGdldApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwZjAwMDAwCmhkYWMw OiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMjAKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGlu OiBMaW5lLW91dCAoR3JlZW4gSmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4 ZgpoZGFjMDogICAgICAgICAgICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lh dGlvbjogMCAoMHgwMDAwMDAwMSkKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAzZgpo ZGFjMDogICAgICAgICAgICAgICAgICBJU0MgVFJRRCBQREMgSFAgT1VUIElOCmhkYWMwOiAgICAg IFBpbiBjb25maWc6IDB4MDEwMTQxMTAKaGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0 MCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAg ICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgICAgSW5wdXQg YW1wOiAweDAwMjcwMzAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6 ZT0zOSBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiA1CmhkYWMwOiAgICAgICAgICAg fApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0gKHNlbGVjdGVkKQpo ZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXQpoZGFj MDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTUgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAg ICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMw OiAgICAgICAgICAgICBuaWQ6IDIxCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1v dXQgKEJsYWNrIEphY2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAxOGYKaGRhYzA6 ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAg KDB4MDAwMDAwMDQpCmhkYWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwM2YKaGRhYzA6ICAg ICAgICAgICAgICAgICAgSVNDIFRSUUQgUERDIEhQIE9VVCBJTgpoZGFjMDogICAgICBQaW4gY29u ZmlnOiAweDAxMDExMTEyCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUCmhk YWMwOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwMDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAg bXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0PTAKaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHgw MDI3MDMwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zm c2V0PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogNQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6 ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0KaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAg ICAgICArIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAg ICArIFtESVNBQkxFRF0gPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAyMgpoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IExpbmUtb3V0IChPcmFu Z2UgSmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpoZGFjMDogICAgICAg ICAgICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAw MDAwMikKaGRhYzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAzZgpoZGFjMDogICAgICAgICAg ICAgICAgICBJU0MgVFJRRCBQREMgSFAgT1VUIElOCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4 MDEwMTYxMTEKaGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAg ICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEg c3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAw CmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZzZXQ9MApo ZGFjMDogICAgIGNvbm5lY3Rpb25zOiA1CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAg ICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAg ICsgPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9MTUgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FC TEVEXSA8LSBuaWQ9MzggW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBu aWQ6IDIzCmhkYWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTGluZS1vdXQgKEdyZXkgSmFjaykK aGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpoZGFjMDogICAgICAgICAgICAgICAg ICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMCAoMHgwMDAwMDAxMCkKaGRh YzA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAzZgpoZGFjMDogICAgICAgICAgICAgICAgICBJ U0MgVFJRRCBQREMgSFAgT1VUIElOCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDEwMTIxMTQK aGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0 IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNp emU9MCBvZmZzZXQ9MApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAwCmhkYWMwOiAg ICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZzZXQ9MApoZGFjMDogICAg IGNvbm5lY3Rpb25zOiA1CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJ U0FCTEVEXSA8LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FC TEVEXSA8LSBuaWQ9MTMgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVE XSA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTE1IFth dWRpbyBtaXhlcl0gKHNlbGVjdGVkKQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MzggW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDI0Cmhk YWMwOiAgICAgICAgICAgIE5hbWU6IHBpbjogTWljIChQaW5rIEphY2spCmhkYWMwOiAgICAgIFdp ZGdldCBjYXA6IDB4MDA0MDAxOGYKaGRhYzA6ICAgICAgICAgICAgICAgICAgVU5TT0wgU1RFUkVP CmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDIgKDB4MDAwMDAwMDQpCmhkYWMwOiAgICAgICAgICAg ICBPU1M6IG1pYyAobWljKQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAxNzNmCmhkYWMw OiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBIUCBPVVQgSU4gVlJFRlsgNTAgODAgR1JP VU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDFhMTk5MzIKaGRhYzA6ICAgICBQ aW4gY29udHJvbDogMHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDogICAgICBPdXRwdXQgYW1wOiAw eDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9m ZnNldD0wCmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4MDAyNzAzMDAKaGRhYzA6ICAgICAgICAg ICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVj dGlvbnM6IDUKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURd IDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRhYzA6ICAgICAgICAgICArIFtE SVNBQkxFRF0gPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxF RF0gPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0g PC0gbmlkPTM4IFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAgICAgICAgbmlkOiAy NQpoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IE1pYyAoUGluayBKYWNrKQpoZGFjMDogICAg ICBXaWRnZXQgY2FwOiAweDAwNDAwMThmCmhkYWMwOiAgICAgICAgICAgICAgICAgIFVOU09MIFNU RVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAzICgweDAwMDAwMDAxKQpoZGFjMDogICAgICAg ICAgICAgT1NTOiBtb25pdG9yIChtb25pdG9yKQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAw MDAxNzNmCmhkYWMwOiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBIUCBPVVQgSU4gVlJF RlsgNTAgODAgR1JPVU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDJhMTljNDAK aGRhYzA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyNCBJTiBWUkVGcwpoZGFjMDogICAgICBP dXRwdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVw PTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4MDAyNzAzMDAKaGRh YzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wCmhkYWMw OiAgICAgY29ubmVjdGlvbnM6IDUKaGRhYzA6ICAgICAgICAgICB8CmhkYWMwOiAgICAgICAgICAg KyBbRElTQUJMRURdIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdIChzZWxlY3RlZCkKaGRhYzA6ICAg ICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAg ICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAg ICArIFtESVNBQkxFRF0gPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0KaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0KaGRhYzA6IApoZGFjMDogICAgICAg ICAgICAgbmlkOiAyNgpoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IExpbmUtaW4gKEJsdWUg SmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDE4ZgpoZGFjMDogICAgICAgICAg ICAgICAgICBVTlNPTCBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMiAoMHgwMDAwMDAw MSkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogbGluZSAobGluZSkKaGRhYzA6ICAgICAgICAgUGlu IGNhcDogMHgwMDAwMTczZgpoZGFjMDogICAgICAgICAgICAgICAgICBJU0MgVFJRRCBQREMgSFAg T1VUIElOIFZSRUZbIDUwIDgwIEdST1VORCBISVogXQpoZGFjMDogICAgICBQaW4gY29uZmlnOiAw eDAxODEzMTMwCmhkYWMwOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwMjQgSU4gVlJFRnMKaGRh YzA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBt dXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAw MjcwMzAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZz ZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rpb25zOiA1CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXSAoc2VsZWN0ZWQp CmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMyBbYXVkaW8gbWl4ZXJdCmhk YWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdCmhkYWMw OiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAg ICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0zOCBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAKaGRh YzA6ICAgICAgICAgICAgIG5pZDogMjcKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGluOiBIZWFk cGhvbmVzIChHcmVlbiBKYWNrKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwNDAwMThmCmhk YWMwOiAgICAgICAgICAgICAgICAgIFVOU09MIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9u OiAxICgweDAwMDAwMDAxKQpoZGFjMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAxNzNmCmhkYWMw OiAgICAgICAgICAgICAgICAgIElTQyBUUlFEIFBEQyBIUCBPVVQgSU4gVlJFRlsgNTAgODAgR1JP VU5EIEhJWiBdCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDIyMTRjMjAKaGRhYzA6ICAgICBQ aW4gY29udHJvbDogMHgwMDAwMDBjMCBIUCBPVVQKaGRhYzA6ICAgICAgT3V0cHV0IGFtcDogMHg4 MDAwMDAwMApoZGFjMDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZz ZXQ9MApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAwCmhkYWMwOiAgICAgICAgICAg ICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rp b25zOiA1CmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8 LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MTMgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9 MTQgW2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTUg W2F1ZGlvIG1peGVyXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0g KHNlbGVjdGVkKQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDI4CmhkYWMwOiAgICAg ICAgICAgIE5hbWU6IHBpbjogQ0QgKEZpeGVkKQpoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAw NDAwMDAxCmhkYWMwOiAgICAgICAgICAgICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0 aW9uOiAyICgweDAwMDAwMDAyKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBjZCAoY2QpCmhkYWMw OiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwMjAKaGRhYzA6ICAgICAgICAgICAgICAgICAgSU4K aGRhYzA6ICAgICAgUGluIGNvbmZpZzogMHg5OTMzMTEzMQpoZGFjMDogICAgIFBpbiBjb250cm9s OiAweDAwMDAwMDIwIElOCmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMjkKaGRhYzA6 ICAgICAgICAgICAgTmFtZTogYmVlcCB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgw MDcwMDAwMApoZGFjMDogICAgIEFzc29jaWF0aW9uOiAtMiAoMHgwMDAwMDAwMCkKaGRhYzA6ICAg ICAgICAgICAgIE9TUzogc3BlYWtlciAoc3BlYWtlcikKaGRhYzA6IApoZGFjMDogICAgICAgICAg ICAgbmlkOiAzMApoZGFjMDogICAgICAgICAgICBOYW1lOiBwaW46IFNQRElGLW91dCAoQmxhY2sg SmFjaykKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDQwMDMwMApoZGFjMDogICAgICAgICAg ICAgICAgICBESUdJVEFMCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDAgKDB4MDAwMDQwMDApCmhk YWMwOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDAwMTAKaGRhYzA6ICAgICAgICAgICAgICAgICAg T1VUCmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDE0NDExMWUKaGRhYzA6ICAgICBQaW4gY29u dHJvbDogMHgwMDAwMDA0MCBPVVQKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMQpoZGFjMDogICAg ICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD02IFthdWRpbyBvdXRwdXRdCmhkYWMw OiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzEKaGRhYzA6ICAgICAgICAgICAgTmFtZTogcGlu OiBTUERJRi1pbiAoT3JhbmdlIEphY2spCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDA0MDAy MDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgRElHSVRBTApoZGFjMDogICAgIEFzc29jaWF0aW9u OiA0ICgweDAwMDAwMDAxKQpoZGFjMDogICAgICAgICAgICAgT1NTOiBkaWcxIChkaWcxKQpoZGFj MDogICAgICAgICBQaW4gY2FwOiAweDAwMDAwMDIwCmhkYWMwOiAgICAgICAgICAgICAgICAgIElO CmhkYWMwOiAgICAgIFBpbiBjb25maWc6IDB4MDFjNDYxNTAKaGRhYzA6ICAgICBQaW4gY29udHJv bDogMHgwMDAwMDAyMCBJTgpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDMyIFtESVNB QkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogdmVuZG9yIHdpZGdldApoZGFjMDogICAgICBX aWRnZXQgY2FwOiAweDAwZjAwMDQwCmhkYWMwOiAgICAgICAgICAgICAgICAgIFBST0MKaGRhYzA6 IApoZGFjMDogICAgICAgICAgICAgbmlkOiAzMyBbRElTQUJMRURdCmhkYWMwOiAgICAgICAgICAg IE5hbWU6IHZvbHVtZSB3aWRnZXQKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDYwMDA4MApo ZGFjMDogICAgICAgICAgICAgICAgICBVTlNPTApoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBu aWQ6IDM0IFtESVNBQkxFRF0KaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRh YzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFjMDogICAgICAgICAgICAgICAgICBT VEVSRU8KaGRhYzA6ICAgICAgIElucHV0IGFtcDogMHg4MDAwMDAwMApoZGFjMDogICAgICAgICAg ICAgICAgICBtdXRlPTEgc3RlcD0wIHNpemU9MCBvZmZzZXQ9MApoZGFjMDogICAgIGNvbm5lY3Rp b25zOiAxMQpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0g PC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNB QkxFRF0gPC0gbmlkPTI1IFtwaW46IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICAr IFtESVNBQkxFRF0gPC0gbmlkPTI2IFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayldCmhkYWMwOiAg ICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yNyBbcGluOiBIZWFkcGhvbmVzIChHcmVlbiBK YWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI4IFtwaW46IENEIChG aXhlZCldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yOSBbYmVlcCB3aWRn ZXRdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGluOiBMaW5lLW91 dCAoR3JlZW4gSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMSBb cGluOiBMaW5lLW91dCAoQmxhY2sgSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURd IDwtIG5pZD0yMiBbcGluOiBMaW5lLW91dCAoT3JhbmdlIEphY2spXQpoZGFjMDogICAgICAgICAg ICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFjayldCmhkYWMw OiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0xMSBbYXVkaW8gbWl4ZXJdCmhkYWMwOiAK aGRhYzA6ICAgICAgICAgICAgIG5pZDogMzUKaGRhYzA6ICAgICAgICAgICAgTmFtZTogYXVkaW8g bWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIwMDEwZgpoZGFjMDogICAgICAgICAg ICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlvbjogMyAoMHgwMDAwMDAwMSkKaGRh YzA6ICAgICAgICAgICAgIE9TUzogc3BlYWtlciwgbW9uaXRvcgpoZGFjMDogICAgICAgSW5wdXQg YW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6 ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6IDExCmhkYWMwOiAgICAgICAgICAg fApoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjQgW3BpbjogTWljIChQaW5r IEphY2spXQpoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI1IFtwaW46IE1pYyAoUGluayBKYWNr KV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI2IFtwaW46IExpbmUtaW4g KEJsdWUgSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yNyBbcGlu OiBIZWFkcGhvbmVzIChHcmVlbiBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0g PC0gbmlkPTI4IFtwaW46IENEIChGaXhlZCldCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9Mjkg W2JlZXAgd2lkZ2V0XQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjAgW3Bp bjogTGluZS1vdXQgKEdyZWVuIEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8 LSBuaWQ9MjEgW3BpbjogTGluZS1vdXQgKEJsYWNrIEphY2spXQpoZGFjMDogICAgICAgICAgICsg W0RJU0FCTEVEXSA8LSBuaWQ9MjIgW3BpbjogTGluZS1vdXQgKE9yYW5nZSBKYWNrKV0KaGRhYzA6 ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTIzIFtwaW46IExpbmUtb3V0IChHcmV5IEph Y2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVy XQpoZGFjMDogCmhkYWMwOiAgICAgICAgICAgICBuaWQ6IDM2CmhkYWMwOiAgICAgICAgICAgIE5h bWU6IGF1ZGlvIG1peGVyCmhkYWMwOiAgICAgIFdpZGdldCBjYXA6IDB4MDAyMDAxMGYKaGRhYzA6 ICAgICAgICAgICAgICAgICAgU1RFUkVPCmhkYWMwOiAgICAgQXNzb2NpYXRpb246IDIgKDB4MDAw MDAwMDcpCmhkYWMwOiAgICAgICAgICAgICBPU1M6IHNwZWFrZXIsIGxpbmUsIG1pYywgY2QsIG1p eApoZGFjMDogICAgICAgSW5wdXQgYW1wOiAweDgwMDAwMDAwCmhkYWMwOiAgICAgICAgICAgICAg ICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0wCmhkYWMwOiAgICAgY29ubmVjdGlvbnM6 IDExCmhkYWMwOiAgICAgICAgICAgfApoZGFjMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46 IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIFtESVNBQkxFRF0gPC0gbmlkPTI1 IFtwaW46IE1pYyAoUGluayBKYWNrKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yNiBbcGlu OiBMaW5lLWluIChCbHVlIEphY2spXQpoZGFjMDogICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBu aWQ9MjcgW3BpbjogSGVhZHBob25lcyAoR3JlZW4gSmFjayldCmhkYWMwOiAgICAgICAgICAgKyA8 LSBuaWQ9MjggW3BpbjogQ0QgKEZpeGVkKV0KaGRhYzA6ICAgICAgICAgICArIDwtIG5pZD0yOSBb YmVlcCB3aWRnZXRdCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwtIG5pZD0yMCBbcGlu OiBMaW5lLW91dCAoR3JlZW4gSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBbRElTQUJMRURdIDwt IG5pZD0yMSBbcGluOiBMaW5lLW91dCAoQmxhY2sgSmFjayldCmhkYWMwOiAgICAgICAgICAgKyBb RElTQUJMRURdIDwtIG5pZD0yMiBbcGluOiBMaW5lLW91dCAoT3JhbmdlIEphY2spXQpoZGFjMDog ICAgICAgICAgICsgW0RJU0FCTEVEXSA8LSBuaWQ9MjMgW3BpbjogTGluZS1vdXQgKEdyZXkgSmFj ayldCmhkYWMwOiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpoZGFjMDogCmhk YWMwOiAgICAgICAgICAgICBuaWQ6IDM3CmhkYWMwOiAgICAgICAgICAgIE5hbWU6IGF1ZGlvIG91 dHB1dApoZGFjMDogICAgICBXaWRnZXQgY2FwOiAweDAwMDAwMDExCmhkYWMwOiAgICAgICAgICAg ICAgICAgIFNURVJFTwpoZGFjMDogICAgIEFzc29jaWF0aW9uOiAxICgweDAwMDAwMDAxKQpoZGFj MDogICAgICAgICAgICAgT1NTOiBwY20gKHBjbSkKaGRhYzA6ICAgICAgU3RyZWFtIGNhcDogMHgw MDAwMDAwMQpoZGFjMDogICAgICAgICAgICAgICAgICBQQ00KaGRhYzA6ICAgICAgICAgUENNIGNh cDogMHgwMDBlMDU2MApoZGFjMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCBiaXRzLCA0NCA0 OCA5NiAxOTIgS0h6CmhkYWMwOiAKaGRhYzA6ICAgICAgICAgICAgIG5pZDogMzgKaGRhYzA6ICAg ICAgICAgICAgTmFtZTogYXVkaW8gbWl4ZXIKaGRhYzA6ICAgICAgV2lkZ2V0IGNhcDogMHgwMDIw MDEwZgpoZGFjMDogICAgICAgICAgICAgICAgICBTVEVSRU8KaGRhYzA6ICAgICBBc3NvY2lhdGlv bjogMSAoMHgwMDAwMDAwMSkKaGRhYzA6ICAgICAgICAgICAgIE9TUzogcGNtLCBtaXgKaGRhYzA6 ICAgICAgT3V0cHV0IGFtcDogMHgwMDA1MWYxZgpoZGFjMDogICAgICAgICAgICAgICAgICBtdXRl PTAgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTMxCmhkYWMwOiAgICAgICBJbnB1dCBhbXA6IDB4ODAw MDAwMDAKaGRhYzA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MCBzaXplPTAgb2Zmc2V0 PTAKaGRhYzA6ICAgICBjb25uZWN0aW9uczogMgpoZGFjMDogICAgICAgICAgIHwKaGRhYzA6ICAg ICAgICAgICArIDwtIG5pZD0zNyBbYXVkaW8gb3V0cHV0XQpoZGFjMDogICAgICAgICAgICsgPC0g bmlkPTExIFthdWRpbyBtaXhlcl0KaGRhYzA6IApwY20wOiA8SERBIFJlYWx0ZWsgQUxDODgyIFBD TSAjMCBEaWdpdGFsPiBhdCBjYWQgMiBuaWQgMSBvbiBoZGFjMApwY20wOiArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTA6IHwgRFVNUElORyBQQ00gUGxheWJhY2sv UmVjb3JkIENoYW5uZWxzIHwKcGNtMDogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwpwY20wOiAKcGNtMDogUGxheWJhY2s6CnBjbTA6IApwY20wOiAgICAgIFN0cmVhbSBj YXA6IDB4MDAwMDAwMDEKcGNtMDogICAgICAgICAgICAgICAgICBQQ00KcGNtMDogICAgICAgICBQ Q00gY2FwOiAweDAwMGUwNTYwCnBjbTA6ICAgICAgICAgICAgICAgICAgMTYgMjAgMjQgYml0cywg NDQgNDggOTYgMTkyIEtIegpwY20wOiAgICAgICAgICAgICBEQUM6IDIgMyA0IDUgNgpwY20wOiAK cGNtMDogUmVjb3JkOgpwY20wOiAKcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDA1CnBj bTA6ICAgICAgICAgICAgICAgICAgQUMzIFBDTQpwY20wOiAgICAgICAgIFBDTSBjYXA6IDB4MDAx ZTA1NjAKcGNtMDogICAgICAgICAgICAgICAgICAxNiAyMCAyNCAzMiBiaXRzLCA0NCA0OCA5NiAx OTIgS0h6CnBjbTA6ICAgICAgICAgICAgIEFEQzogMTAKcGNtMDogCnBjbTA6ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20wOiB8IERVTVBJTkcgUGxheWJhY2svUmVjb3JkIFBh dGhzIHwKcGNtMDogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTA6IApwY20w OiBQbGF5YmFjazoKcGNtMDogCnBjbTA6ICAgICBuaWQ9MjAgW3BpbjogTGluZS1vdXQgKEdyZWVu IEphY2spXQpwY20wOiAgICAgICB8CnBjbTA6ICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhl cl0gW3NyYzogcGNtLCBtaXhdCnBjbTA6ICAgICAgICAgICAgICB8CnBjbTA6ICAgICAgICAgICAg ICArIDwtIG5pZD0yIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMDogICAgICAgICAgICAg ICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5p ZD0yMiBbcGluOiBMaW5lLW91dCAoT3JhbmdlIEphY2spXQpwY20wOiAgICAgICB8CnBjbTA6ICAg ICAgICsgPC0gbmlkPTEzIFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBjbTA6ICAgICAg ICAgICAgICB8CnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdIFtz cmM6IHBjbV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3Ny YzogbWl4XQpwY20wOiAKcGNtMDogICAgIG5pZD0yMSBbcGluOiBMaW5lLW91dCAoQmxhY2sgSmFj ayldCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXSBb c3JjOiBwY20sIG1peF0KcGNtMDogICAgICAgICAgICAgIHwKcGNtMDogICAgICAgICAgICAgICsg PC0gbmlkPTQgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpwY20wOiAgICAgICAgICAgICAgKyA8 LSBuaWQ9MTEgW2F1ZGlvIG1peGVyXSBbc3JjOiBtaXhdCnBjbTA6IApwY20wOiAgICAgbmlkPTIz IFtwaW46IExpbmUtb3V0IChHcmV5IEphY2spXQpwY20wOiAgICAgICB8CnBjbTA6ICAgICAgICsg PC0gbmlkPTE1IFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBtaXhdCnBjbTA6ICAgICAgICAgICAg ICB8CnBjbTA6ICAgICAgICAgICAgICArIDwtIG5pZD01IFthdWRpbyBvdXRwdXRdIFtzcmM6IHBj bV0KcGNtMDogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4 XQpwY20wOiAKcGNtMDogICAgIG5pZD0zMCBbcGluOiBTUERJRi1vdXQgKEJsYWNrIEphY2spXQpw Y20wOiAgICAgICB8CnBjbTA6ICAgICAgICsgPC0gbmlkPTYgW2F1ZGlvIG91dHB1dF0gW3NyYzog cGNtXQpwY20wOiAKcGNtMDogUmVjb3JkOgpwY20wOiAKcGNtMDogICAgIG5pZD0xMCBbYXVkaW8g aW5wdXRdCnBjbTA6ICAgICAgIHwKcGNtMDogICAgICAgKyA8LSBuaWQ9MzEgW3BpbjogU1BESUYt aW4gKE9yYW5nZSBKYWNrKV0gW3NyYzogZGlnMV0KcGNtMDogCnBjbTA6IElucHV0IE1peDoKcGNt MDogCnBjbTA6ICAgICBuaWQ9MTEgW2F1ZGlvIG1peGVyXQpwY20wOiAgICAgICB8CnBjbTA6ICAg ICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWljXQpwY20wOiAg ICAgICArIDwtIG5pZD0yNiBbcGluOiBMaW5lLWluIChCbHVlIEphY2spXSBbc3JjOiBsaW5lXQpw Y20wOiAgICAgICArIDwtIG5pZD0yOCBbcGluOiBDRCAoRml4ZWQpXSBbc3JjOiBjZF0KcGNtMDog ICAgICAgKyA8LSBuaWQ9MjkgW2JlZXAgd2lkZ2V0XSBbc3JjOiBzcGVha2VyXQpwY20wOiAKcGNt MDogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTA6IHwgRFVNUElORyBWb2x1bWUgQ29u dHJvbHMgfApwY20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMDogCnBjbTA6IE1h c3RlciBWb2x1bWUgKE9TUzogdm9sKQpwY20wOiAgICB8CnBjbTA6ICAgICstIGN0bCAxNCAobmlk ICAxMiBvdXQpOiAgICAtNDYvMGRCICgzMiBzdGVwcykKcGNtMDogICAgKy0gY3RsIDE1IChuaWQg IDEyIGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDE2IChuaWQgIDEyIGluICAgMSk6IG11 dGUKcGNtMDogICAgKy0gY3RsIDE3IChuaWQgIDEzIG91dCk6ICAgIC00Ni8wZEIgKDMyIHN0ZXBz KQpwY20wOiAgICArLSBjdGwgMTggKG5pZCAgMTMgaW4gICAwKTogbXV0ZQpwY20wOiAgICArLSBj dGwgMTkgKG5pZCAgMTMgaW4gICAxKTogbXV0ZQpwY20wOiAgICArLSBjdGwgMjAgKG5pZCAgMTQg b3V0KTogICAgLTQ2LzBkQiAoMzIgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAyMSAobmlkICAxNCBp biAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyMiAobmlkICAxNCBpbiAgIDEpOiBtdXRlCnBj bTA6ICAgICstIGN0bCAyMyAobmlkICAxNSBvdXQpOiAgICAtNDYvMGRCICgzMiBzdGVwcykKcGNt MDogICAgKy0gY3RsIDI0IChuaWQgIDE1IGluICAgMCk6IG11dGUKcGNtMDogICAgKy0gY3RsIDI1 IChuaWQgIDE1IGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsIDI2IChuaWQgIDIwIGluICk6 ICAgIG11dGUKcGNtMDogICAgKy0gY3RsIDI4IChuaWQgIDIxIGluICk6ICAgIG11dGUKcGNtMDog ICAgKy0gY3RsIDMwIChuaWQgIDIyIGluICk6ICAgIG11dGUKcGNtMDogICAgKy0gY3RsIDMyIChu aWQgIDIzIGluICk6ICAgIG11dGUKcGNtMDogCnBjbTA6IFBDTSBWb2x1bWUgKE9TUzogcGNtKQpw Y20wOiAgICB8CnBjbTA6ICAgICstIGN0bCAxNSAobmlkICAxMiBpbiAgIDApOiBtdXRlCnBjbTA6 ICAgICstIGN0bCAxOCAobmlkICAxMyBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyMSAo bmlkICAxNCBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyNCAobmlkICAxNSBpbiAgIDAp OiBtdXRlCnBjbTA6IApwY20wOiBJbnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KQpwY20wOiAgICB8 CnBjbTA6ICAgICstIGN0bCAxNiAobmlkICAxMiBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0 bCAxOSAobmlkICAxMyBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyMiAobmlkICAxNCBp biAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyNSAobmlkICAxNSBpbiAgIDEpOiBtdXRlCnBj bTA6IApwY20wOiBJbnB1dCBNb25pdG9yaW5nIExldmVsIChPU1M6IGlnYWluKQpwY20wOiAgICB8 CnBjbTA6ICAgICstIGN0bCAxNiAobmlkICAxMiBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0 bCAxOSAobmlkICAxMyBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyMiAobmlkICAxNCBp biAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAyNSAobmlkICAxNSBpbiAgIDEpOiBtdXRlCnBj bTA6IApwY20wOiBFbmFibGluZyBTb2Z0IFBDTSB2b2x1bWUKcGNtMDogTWl4ZXIgInZvbCI6CnBj bTA6IE1peGVyICJwY20iOgpwY20wOiBNaXhlciAibWl4IjoKcGNtMDogTWl4ZXIgImlnYWluIjoK cGNtMDogU29mdCBQQ00gbWl4ZXIgRU5BQkxFRApwY20wOiBjbG9uZSBtYW5hZ2VyOiBkZWFkbGlu ZT03NTBtcyBmbGFncz0weDgwMDAwMDFlCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgNDAyMDAwMCwgNDAw MDsgMHhmZmZmZmY4MDllOGY2MDAwIC0+IDQwMjAwMDAKcGNtMDogc25kYnVmX3NldG1hcCA0MDMw MDAwLCA0MDAwOyAweGZmZmZmZjgwOWU5MDYwMDAgLT4gNDAzMDAwMApwY20xOiA8SERBIFJlYWx0 ZWsgQUxDODgyIFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAyIG5pZCAxIG9uIGhkYWMwCnBjbTE6ICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMTogfCBEVU1QSU5HIFBD TSBQbGF5YmFjay9SZWNvcmQgQ2hhbm5lbHMgfApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCnBjbTE6IApwY20xOiBQbGF5YmFjazoKcGNtMTogCnBjbTE6ICAg ICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMQpwY20xOiAgICAgICAgICAgICAgICAgIFBDTQpwY20x OiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA1NjAKcGNtMTogICAgICAgICAgICAgICAgICAxNiAy MCAyNCBiaXRzLCA0NCA0OCA5NiAxOTIgS0h6CnBjbTE6ICAgICAgICAgICAgIERBQzogMzcKcGNt MTogCnBjbTE6IFJlY29yZDoKcGNtMTogCnBjbTE6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAw MQpwY20xOiAgICAgICAgICAgICAgICAgIFBDTQpwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAw NjAxNjAKcGNtMTogICAgICAgICAgICAgICAgICAxNiAyMCBiaXRzLCA0NCA0OCA5NiBLSHoKcGNt MTogICAgICAgICAgICAgQURDOiA3CnBjbTE6IApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKcGNtMTogfCBEVU1QSU5HIFBsYXliYWNrL1JlY29yZCBQYXRocyB8CnBjbTE6 ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20xOiAKcGNtMTogUGxheWJhY2s6 CnBjbTE6IApwY20xOiAgICAgbmlkPTI3IFtwaW46IEhlYWRwaG9uZXMgKEdyZWVuIEphY2spXQpw Y20xOiAgICAgICB8CnBjbTE6ICAgICAgICsgPC0gbmlkPTM4IFthdWRpbyBtaXhlcl0gW3NyYzog cGNtLCBtaXhdCnBjbTE6ICAgICAgICAgICAgICB8CnBjbTE6ICAgICAgICAgICAgICArIDwtIG5p ZD0zNyBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21dCnBjbTE6ICAgICAgICAgICAgICArIDwtIG5p ZD0xMSBbYXVkaW8gbWl4ZXJdIFtzcmM6IG1peF0KcGNtMTogCnBjbTE6IFJlY29yZDoKcGNtMTog CnBjbTE6ICAgICBuaWQ9NyBbYXVkaW8gaW5wdXRdCnBjbTE6ICAgICAgIHwKcGNtMTogICAgICAg KyA8LSBuaWQ9MzYgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBsaW5lLCBtaWMsIGNkLCBt aXhdCnBjbTE6ICAgICAgICAgICAgICB8CnBjbTE6ICAgICAgICAgICAgICArIDwtIG5pZD0yNCBb cGluOiBNaWMgKFBpbmsgSmFjayldIFtzcmM6IG1pY10KcGNtMTogICAgICAgICAgICAgICsgPC0g bmlkPTI2IFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayldIFtzcmM6IGxpbmVdCnBjbTE6ICAgICAg ICAgICAgICArIDwtIG5pZD0yOCBbcGluOiBDRCAoRml4ZWQpXSBbc3JjOiBjZF0KcGNtMTogICAg ICAgICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0gW3NyYzogc3BlYWtlcl0KcGNtMTog ICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogbWl4XQpwY20xOiAK cGNtMTogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTE6IHwgRFVNUElORyBWb2x1bWUg Q29udHJvbHMgfApwY20xOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKcGNtMTogCnBjbTE6 IE1hc3RlciBWb2x1bWUgKE9TUzogdm9sKQpwY20xOiAgICB8CnBjbTE6ICAgICstIGN0bCA0MCAo bmlkICAyNyBpbiApOiAgICBtdXRlCnBjbTE6ICAgICstIGN0bCA3NSAobmlkICAzOCBvdXQpOiAg ICAtNDYvMGRCICgzMiBzdGVwcykKcGNtMTogICAgKy0gY3RsIDc2IChuaWQgIDM4IGluICAgMCk6 IG11dGUKcGNtMTogICAgKy0gY3RsIDc3IChuaWQgIDM4IGluICAgMSk6IG11dGUKcGNtMTogCnBj bTE6IFBDTSBWb2x1bWUgKE9TUzogcGNtKQpwY20xOiAgICB8CnBjbTE6ICAgICstIGN0bCA3NiAo bmlkICAzOCBpbiAgIDApOiBtdXRlCnBjbTE6IApwY20xOiBDRCBWb2x1bWUgKE9TUzogY2QpCnBj bTE6ICAgIHwKcGNtMTogICAgKy0gY3RsICA4IChuaWQgIDExIGluICAgNCk6IC0zNC8xMmRCICgz MiBzdGVwcykgKyBtdXRlCnBjbTE6ICAgICstIGN0bCA2OCAobmlkICAzNiBpbiAgIDQpOiBtdXRl CnBjbTE6IApwY20xOiBNaWNyb3Bob25lIFZvbHVtZSAoT1NTOiBtaWMpCnBjbTE6ICAgIHwKcGNt MTogICAgKy0gY3RsIDM1IChuaWQgIDI0IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKcGNtMTog ICAgKy0gY3RsIDY0IChuaWQgIDM2IGluICAgMCk6IG11dGUKcGNtMTogCnBjbTE6IExpbmUtaW4g Vm9sdW1lIChPU1M6IGxpbmUpCnBjbTE6ICAgIHwKcGNtMTogICAgKy0gY3RsIDM5IChuaWQgIDI2 IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKcGNtMTogICAgKy0gY3RsIDY2IChuaWQgIDM2IGlu ICAgMik6IG11dGUKcGNtMTogCnBjbTE6IFNwZWFrZXIvQmVlcCBWb2x1bWUgKE9TUzogc3BlYWtl cikKcGNtMTogICAgfApwY20xOiAgICArLSBjdGwgIDkgKG5pZCAgMTEgaW4gICA1KTogLTM0LzEy ZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMTogICAgKy0gY3RsIDY5IChuaWQgIDM2IGluICAgNSk6 IG11dGUKcGNtMTogCnBjbTE6IFJlY29yZGluZyBMZXZlbCAoT1NTOiByZWMpCnBjbTE6ICAgIHwK cGNtMTogICAgKy0gY3RsICAxIChuaWQgICA3IGluICAgMCk6IC0xMi8zNGRCICgzMiBzdGVwcykg KyBtdXRlCnBjbTE6ICAgICstIGN0bCA2NCAobmlkICAzNiBpbiAgIDApOiBtdXRlCnBjbTE6ICAg ICstIGN0bCA2NiAobmlkICAzNiBpbiAgIDIpOiBtdXRlCnBjbTE6ICAgICstIGN0bCA2OCAobmlk ICAzNiBpbiAgIDQpOiBtdXRlCnBjbTE6ICAgICstIGN0bCA2OSAobmlkICAzNiBpbiAgIDUpOiBt dXRlCnBjbTE6ICAgICstIGN0bCA3NCAobmlkICAzNiBpbiAgMTApOiBtdXRlCnBjbTE6IApwY20x OiBJbnB1dCBNaXggTGV2ZWwgKE9TUzogbWl4KQpwY20xOiAgICB8CnBjbTE6ICAgICstIGN0bCAg NCAobmlkICAxMSBpbiAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20xOiAgICAr LSBjdGwgIDYgKG5pZCAgMTEgaW4gICAyKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNt MTogICAgKy0gY3RsICA4IChuaWQgIDExIGluICAgNCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBt dXRlCnBjbTE6ICAgICstIGN0bCAgOSAobmlkICAxMSBpbiAgIDUpOiAtMzQvMTJkQiAoMzIgc3Rl cHMpICsgbXV0ZQpwY20xOiAgICArLSBjdGwgNzQgKG5pZCAgMzYgaW4gIDEwKTogbXV0ZQpwY20x OiAgICArLSBjdGwgNzcgKG5pZCAgMzggaW4gICAxKTogbXV0ZQpwY20xOiAKcGNtMTogSW5wdXQg TW9uaXRvcmluZyBMZXZlbCAoT1NTOiBpZ2FpbikKcGNtMTogICAgfApwY20xOiAgICArLSBjdGwg NzcgKG5pZCAgMzggaW4gICAxKTogbXV0ZQpwY20xOiAKcGNtMTogRW5hYmxpbmcgU29mdCBQQ00g dm9sdW1lCnBjbTE6IE1peGVyICJ2b2wiOgpwY20xOiBNaXhlciAicGNtIjoKcGNtMTogTWl4ZXIg InNwZWFrZXIiOgpwY20xOiBNaXhlciAibGluZSI6CnBjbTE6IE1peGVyICJtaWMiOgpwY20xOiBN aXhlciAiY2QiOgpwY20xOiBNaXhlciAibWl4IjoKcGNtMTogTWl4ZXIgInJlYyI6CnBjbTE6IE1p eGVyICJpZ2FpbiI6CnBjbTE6IFNvZnQgUENNIG1peGVyIEVOQUJMRUQKcGNtMTogY2xvbmUgbWFu YWdlcjogZGVhZGxpbmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAxZQpwY20xOiBzbmRidWZfc2V0bWFw IDQwNTAwMDAsIDQwMDA7IDB4ZmZmZmZmODA5ZTkxNjAwMCAtPiA0MDUwMDAwCnBjbTE6IHNuZGJ1 Zl9zZXRtYXAgNDA2MDAwMCwgNDAwMDsgMHhmZmZmZmY4MDllOTI2MDAwIC0+IDQwNjAwMDAKcGNt MjogPEhEQSBSZWFsdGVrIEFMQzg4MiBQQ00gIzIgQW5hbG9nPiBhdCBjYWQgMiBuaWQgMSBvbiBo ZGFjMApwY20yOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnBjbTI6 IHwgRFVNUElORyBQQ00gUGxheWJhY2svUmVjb3JkIENoYW5uZWxzIHwKcGNtMjogKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20yOiAKcGNtMjogUmVjb3JkOgpwY20y OiAKcGNtMjogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxCnBjbTI6ICAgICAgICAgICAgICAg ICAgUENNCnBjbTI6ICAgICAgICAgUENNIGNhcDogMHgwMDA2MDE2MApwY20yOiAgICAgICAgICAg ICAgICAgIDE2IDIwIGJpdHMsIDQ0IDQ4IDk2IEtIegpwY20yOiAgICAgICAgICAgICBBREM6IDgK cGNtMjogCnBjbTI6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20yOiB8IERV TVBJTkcgUGxheWJhY2svUmVjb3JkIFBhdGhzIHwKcGNtMjogKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCnBjbTI6IApwY20yOiBSZWNvcmQ6CnBjbTI6IApwY20yOiAgICAgbmlkPTgg W2F1ZGlvIGlucHV0XQpwY20yOiAgICAgICB8CnBjbTI6ICAgICAgICsgPC0gbmlkPTM1IFthdWRp byBtaXhlcl0gW3NyYzogc3BlYWtlciwgbW9uaXRvcl0KcGNtMjogICAgICAgICAgICAgIHwKcGNt MjogICAgICAgICAgICAgICsgPC0gbmlkPTI1IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzog bW9uaXRvcl0KcGNtMjogICAgICAgICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0gW3Ny Yzogc3BlYWtlcl0KcGNtMjogCnBjbTI6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwpwY20y OiB8IERVTVBJTkcgVm9sdW1lIENvbnRyb2xzIHwKcGNtMjogKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCnBjbTI6IApwY20yOiBNaWNyb3Bob25lMiBWb2x1bWUgKE9TUzogbW9uaXRvcikKcGNt MjogICAgfApwY20yOiAgICArLSBjdGwgMzcgKG5pZCAgMjUgb3V0KTogICAgMC8zMGRCICg0IHN0 ZXBzKQpwY20yOiAgICArLSBjdGwgNTQgKG5pZCAgMzUgaW4gICAxKTogbXV0ZQpwY20yOiAKcGNt MjogU3BlYWtlci9CZWVwIFZvbHVtZSAoT1NTOiBzcGVha2VyKQpwY20yOiAgICB8CnBjbTI6ICAg ICstIGN0bCA1OCAobmlkICAzNSBpbiAgIDUpOiBtdXRlCnBjbTI6IApwY20yOiBSZWNvcmRpbmcg TGV2ZWwgKE9TUzogcmVjKQpwY20yOiAgICB8CnBjbTI6ICAgICstIGN0bCAgMiAobmlkICAgOCBp biAgIDApOiAtMTIvMzRkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20yOiAgICArLSBjdGwgNTQgKG5p ZCAgMzUgaW4gICAxKTogbXV0ZQpwY20yOiAgICArLSBjdGwgNTggKG5pZCAgMzUgaW4gICA1KTog bXV0ZQpwY20yOiAKcGNtMjogTWl4ZXIgInNwZWFrZXIiOgpwY20yOiBNaXhlciAicmVjIjoKcGNt MjogTWl4ZXIgIm1vbml0b3IiOgpwY20yOiBjbG9uZSBtYW5hZ2VyOiBkZWFkbGluZT03NTBtcyBm bGFncz0weDgwMDAwMDFlCnBjbTI6IHNuZGJ1Zl9zZXRtYXAgNDA3MDAwMCwgNDAwMDsgMHhmZmZm ZmY4MDllOTM2MDAwIC0+IDQwNzAwMDAKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEu MAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogMTJNYnBzIEZ1bGwg U3BlZWQgVVNCIHYxLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czQ6 IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQxPTAxCmF0YTA6IHN0YXQwPTB4MTAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4 ZWIKYXRhMDogc3RhdDE9MHgwMSBlcnI9MHgwNCBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNl dCB0cDIgc3RhdDA9MTAgc3RhdDE9MDEgZGV2aWNlcz0weDEwMDAwCihhcHJvYmUwOmF0YTA6MDow OjApOiBTSUdOQVRVUkU6IGViMTQKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJ bnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4x OiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1 c2J1czMKdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8 SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzNAp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1 YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIyOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKYXRhMjogU0FUQSByZXNldDogcG9ydHMgc3RhdHVzPTB4MDEK YXRhMjogcDA6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMTMKYXRhMjogcDE6 IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGEyOiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTI6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4 MDAgbXNiPTB4MDAKYXRhMjogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAph dGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEKKGFwcm9iZTA6YXRh MjowOjA6MCk6IFNJR05BVFVSRTogMDAwMAphdGEzOiBTQVRBIHJlc2V0OiBwb3J0cyBzdGF0dXM9 MHgwMAphdGEzOiBwMDogU0FUQSBjb25uZWN0IHRpbWVvdXQgc3RhdHVzPTAwMDAwMDAwCmF0YTM6 IHAxOiBTQVRBIGNvbm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYWRhMCBhdCBhdGEyIGJ1 cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMAphZGEwOiA8U1QzMTYwMDIzQVMgMy40Mz4gQVRBLTcg U0FUQSAxLnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgNE1UMjJDMlMKYWRhMDogMTUwLjAw ME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTUsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IDE1 MjYyN01CICgzMTI1ODE4MDggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRh MDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CkdFT006IG5ldyBkaXNrIGFkYTAKcGFzczAg YXQgYXRhMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxUU1NUY29ycCBDRC9E VkRXIFRTLUg1NTJMIDA2MTQ+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKcGFzczA6 IDMzLjMwME1CL3MgdHJhbnNmZXJzIChVRE1BMiwgQVRBUEkgMTJieXRlcywgUElPIDY1NTM0Ynl0 ZXMpCmNkMCBhdCBhdGEwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApjZDA6IDxUU1NUY29y cCBDRC9EVkRXIFRTLUg1NTJMIDA2MTQ+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAK Y2QwOiAzMy4zMDBNQi9zIHRyYW5zZmVycyAoVURNQTIsIEFUQVBJIDEyYnl0ZXMsIFBJTyA2NTUz NGJ5dGVzKQpjZDA6IGNkIHByZXNlbnQgWzI5NTE4NCB4IDIwNDggYnl0ZSByZWNvcmRzXQpwYXNz MSBhdCBhdGEyIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMApwYXNzMTogPFNUMzE2MDAyM0FT IDMuNDM+IEFUQS03IFNBVEEgMS54IGRldmljZQpwYXNzMTogU2VyaWFsIE51bWJlciA0TVQyMkMy UwpwYXNzMTogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTUsIFBJTyA4MTky Ynl0ZXMpClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAw MDAwICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBs aW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAw eDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAw MDAwMGYwIHBtYzogMHgwMDAxMDQwMApTTVA6IGZhaWxlZCBUU0Mgc3luY2hyb25pemF0aW9uIHRl c3QKVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxvd2VyIDggYml0KHMpClRpbWVjb3VudGVyICJU U0MtbG93IiBmcmVxdWVuY3kgMTE3MjIzNDkgSHogcXVhbGl0eSAtMTAwCkdFT006IG5ldyBkaXNr IGNkMAp1aHViNDogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBt b3VudCB3YWl0aW5nIGZvcjogdXNidXM0ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9k ZXYvYWRhMHAyIFtyd10uLi4Kc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKdWdlbjAuMjog PFBsdXMgTW9yZSBFbnRlcnByaXNlIExURC4+IGF0IHVzYnVzMAp1a2JkMDogPFBsdXMgTW9yZSBF bnRlcnByaXNlIExURC4gVVNCLWNvbXBsaWFudCBrZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4x MC8xLjAwLCBhZGRyIDI+IG9uIHVzYnVzMAprYmQyIGF0IHVrYmQwCmtiZDI6IHVrYmQwLCBnZW5l cmljICgwKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKdW1zMDogPFBsdXMgTW9yZSBFbnRl cnByaXNlIExURC4gVVNCLWNvbXBsaWFudCBrZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8x LjAwLCBhZGRyIDI+IG9uIHVzYnVzMAp1bXMwOiAwIGJ1dHRvbnMgYW5kIFtYWVpdIGNvb3JkaW5h dGVzIElEPTMKdWdlbjQuMjogPEdIPiBhdCB1c2J1czQKdW1hc3MwOiA8R0ggUGljb0JpdCwgY2xh c3MgMC8wLCByZXYgMi4wMC8xLjEwLCBhZGRyIDI+IG9uIHVzYnVzNAp1bWFzczA6ICBTQ1NJIG92 ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDQxMDAKdW1hc3MwOjM6MDotMTogQXR0YWNoZWQgdG8g c2NidXMzCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZl cnNpb24gZnJvbSAyIHRvIDA/CnBhc3MyIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXMzIHRhcmdl dCAwIGx1biAwCnBhc3MyOiA8R0ggUGljb0JpdCBQTUFQPiBSZW1vdmFibGUgRGlyZWN0IEFjY2Vz cyBTQ1NJLTAgZGV2aWNlIApwYXNzMjogU2VyaWFsIE51bWJlciAwNzczMTQzODAwRkMKcGFzczI6 IDQwLjAwME1CL3MgdHJhbnNmZXJzCkdFT006IG5ldyBkaXNrIGRhMApkYTAgYXQgdW1hc3Mtc2lt MCBidXMgMCBzY2J1czMgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8R0ggUGljb0JpdCBQTUFQPiBSZW1v dmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTA6IFNlcmlhbCBOdW1iZXIgMDc3 MzE0MzgwMEZDCmRhMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiA5ODFNQiAoMjAwOTA4OCA1 MTIgYnl0ZSBzZWN0b3JzOiA2NEggMzJTL1QgOTgxQykK --=_d1b9c4716a57f436e348f6ce4081c12a-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 11:06:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4067536; Fri, 14 Dec 2012 11:06:35 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4A5DF8FC12; Fri, 14 Dec 2012 11:06:35 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F18AC40010; Fri, 14 Dec 2012 12:06:33 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E676140011; Fri, 14 Dec 2012 12:06:33 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 116AC40010; Fri, 14 Dec 2012 12:06:32 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3YN88R4Klxz8hVn; Fri, 14 Dec 2012 12:06:31 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id S7_FODM9OGDz; Fri, 14 Dec 2012 12:06:29 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3YN88P1fYJz8hVm; Fri, 14 Dec 2012 12:06:29 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [10.32.0.4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3YN88N51dPz9Ctj; Fri, 14 Dec 2012 12:06:28 +0100 (CET) Message-ID: <50CB0834.7020607@freebsd.org> Date: Fri, 14 Dec 2012 12:06:28 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Johannes Dieterich Subject: Re: new xorg segfault 11 with KMS References: <50CA50C6.2080501@gmail.com> <50CA652C.5010101@freebsd.org> <1698382.9Eyt0BnUlN@home.alkar.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Artyom Mirgorodskiy , Dimitry Andric , freebsd-current@freebsd.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 11:06:35 -0000 On 12/14/12 01:24, Johannes Dieterich wrote: > On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy > wrote: >> This patch work for me. Thanks. > I can confirm that it also works for me. Thanks a lot! > >> On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: >> >>> Can you please try the attached patch, against x11-servers/xorg-server. >> >>> Apply it and recompile xorg-server with normal flags (that is, no >> >>> debugging) and let me and the list know the result when starting X. >> >>> Regards! Patch is applied to the ports tree now. Thanks for help testing! Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 11:09:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 811046F6; Fri, 14 Dec 2012 11:09:42 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 23DFA8FC17; Fri, 14 Dec 2012 11:09:42 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7761740013; Fri, 14 Dec 2012 12:09:41 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 6C94440010; Fri, 14 Dec 2012 12:09:41 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 168AC4000C; Fri, 14 Dec 2012 12:09:41 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3YN8D45lksz8hVt; Fri, 14 Dec 2012 12:09:40 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id hkTc3JMSLR8i; Fri, 14 Dec 2012 12:09:38 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3YN8D253hvz8hVm; Fri, 14 Dec 2012 12:09:38 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [10.32.0.4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3YN8D24Y8Lz9CwY; Fri, 14 Dec 2012 12:09:38 +0100 (CET) Message-ID: <50CB08F2.9060206@freebsd.org> Date: Fri, 14 Dec 2012 12:09:38 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Artyom Mirgorodskiy Subject: Re: new xorg segfault 11 with KMS References: <50CA50C6.2080501@gmail.com> <50CA652C.5010101@freebsd.org> <1698382.9Eyt0BnUlN@home.alkar.net> In-Reply-To: <1698382.9Eyt0BnUlN@home.alkar.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Johannes Dieterich , Dimitry Andric , freebsd-current@freebsd.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 11:09:42 -0000 On 12/14/12 00:51, Artyom Mirgorodskiy wrote: > This patch work for me. Thanks. > > On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: >> Can you please try the attached patch, against x11-servers/xorg-server. >> Apply it and recompile xorg-server with normal flags (that is, no >> debugging) and let me and the list know the result when starting X. >> Regards! >> Patch is in the ports tree now. Thanks for testing! Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 08:02:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17A68462 for ; Fri, 14 Dec 2012 08:02:53 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id C199F8FC08 for ; Fri, 14 Dec 2012 08:02:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date; bh=OxtksDK7I2ryIOX6CFuqA2mfWEYKkQAnqCMSlUwlE4U=; b=KsjnuawN8z6/7znp4VtYpZLaCSgba5/4nlOUoIKC3WzwhzH6Nw0joDQQ3SiGaTV2vnzPahi2E1VbuMrUCYo+xljKKSkhxykSJzJkQu4fjLBIYQBrP3mqaeg0z5bV4wJqqUsJjsg9MXHXwnEVtnObHvoSZBDatCaWI7PylFEVQqo=; Received: from iglou1.iglou.com ([192.107.41.3]:60080 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TjQEN-0001nb-EJ by authid with igloumta_auth for freebsd-current@freebsd.org; Fri, 14 Dec 2012 03:02:51 -0500 Received: from shell1.iglou.com ([192.107.41.17]:44703 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TjQEN-0003AT-3Z for freebsd-current@freebsd.org; Fri, 14 Dec 2012 03:02:51 -0500 Date: Fri, 14 Dec 2012 03:02:50 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-current@freebsd.org Subject: re: fifolog_writer In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Fri, 14 Dec 2012 12:34:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 08:02:53 -0000 > I ran installworld and am stuck here: > > ===> /usr.sbin/fifolog/fifolog_writer (install) > Well, after a power cycle it boots and reports to be r244114. I have run 'svn up' and am going to try it again- seems like it will try to build r244201. Actually, right now I do not recall whether or not I cleared /usr/obj before the build- could be due to brain damage of the system administrator. Darrel From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 10:56:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AA5F230 for ; Fri, 14 Dec 2012 10:56:22 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7758FC13 for ; Fri, 14 Dec 2012 10:56:21 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so357178wib.13 for ; Fri, 14 Dec 2012 02:56:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=XLzN8ARhBmmmKSshIfonkBTCrek499LxNeRaAVbbeNc=; b=enUl1lENyT2P+3sY3WrwyWoah9xnLl3/4SGNww/RjOn6aHNncL8AVMiVGvTpMMl2Rp qUmLp5LYv1MTWCWM+VBUivdWd4/xYzqvyr9ylnnZRRjagQljJ8yzdy/dWoDd0p0YYRJA DAS4R/4CtF6DrjZxHz4gSf8py6LhmFwWcOVtbphBLp/o78PsAVbEGlzxDu+1nJX2QLYB GMC7+1T7fS3pKlHAYeYd0zjbj4vwBvUDFZ0BPrrzIlrdiwqdcuGhVNVK+jz1LU3C23WX 92rsuFrejAKTT4q8qYcTa8Gy0k7cqRFNzEHlk7DgRUWDHH+rWKw3srptUroezSyjsIa0 A70w== Received: by 10.194.89.167 with SMTP id bp7mr2788201wjb.0.1355482580319; Fri, 14 Dec 2012 02:56:20 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id y3sm11760566wix.6.2012.12.14.02.56.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 02:56:19 -0800 (PST) From: Fleuriot Damien Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 10-CURRENT r244183 amd64 multiple lock order reversals Message-Id: <5A9EB6A1-AA39-4AA5-B5FA-D566898AD248@my.gd> Date: Fri, 14 Dec 2012 11:56:19 +0100 To: FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmpYQL3L0BAzdm9+MGG2zGRn7TPIKExkwFfa+aBnTR64Zn42wfxWf+U2mfwTRvqHI+OlD9s X-Mailman-Approved-At: Fri, 14 Dec 2012 12:34:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 10:56:22 -0000 Hello list, I'm getting multipe LORs at boot on 10-CURRENT r244183 built yesterday = on amd64. Anyone else getting these ? Anything I can do to help get them fixed ? My make.conf contains: =3D=3D=3D CC=3Dclang CXX=3Dclang++ CPP=3Dclang-cpp # This setting to build world without -Werror NO_WERROR=3D # This setting to build kernel without -Werror WERROR=3D # Don't forget this when using jails ! NO_FSCHG=3D CFLAGS=3D -O2 -fno-strict-aliasing -pipe NO_GAMES=3Dtrue NO_INFO=3Dtrue NO_KERBEROS=3Dtrue NO_LPR=3Dtrue NO_NIS=3Dtrue NO_BLUETOOTH=3Dtrue KERNCONF=3DDAM MODULES_OVERRIDE=3D opensolaris zfs if_lagg pf pflog =3D=3D=3D First LOR, apparently in PF: altq: emulate 256000000Hz cpu clock lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff81390418 pf rulesets (pf rulesets) @ = /data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1153 2nd 0xffffffff80e5e298 ifnet_sx (ifnet_sx) @ = /data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_if.c:481 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xffffff80f6e4a9d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80f6e4aa80 witness_checkorder() at witness_checkorder+0xc47/frame = 0xffffff80f6e4ab00 _sx_slock() at _sx_slock+0x69/frame 0xffffff80f6e4ab40 pfi_kif_update() at pfi_kif_update+0x10d/frame 0xffffff80f6e4abb0 pfi_dynaddr_setup() at pfi_dynaddr_setup+0x2d1/frame 0xffffff80f6e4ac20 pfioctl() at pfioctl+0x4a61/frame 0xffffff80f6e4b9a0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff80f6e4ba00 kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff80f6e4ba50 sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff80f6e4baa0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff80f6e4bbb0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff80f6e4bbb0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800d923ea, rsp =3D = 0x7fffffffbde8, rbp =3D 0x7fffffffc9e0 --- PF is used as a module, however I've compiled in ALTQ support: options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC options ALTQ_DEBUG Second and third LORs, with vfs: lock order reversal: 1st 0xffffff80c0f92a48 bufwait (bufwait) @ = /data/freebsd/src/head/sys/kern/vfs_bio.c:2631 2nd 0xfffffe000619d600 dirhash (dirhash) @ = /data/freebsd/src/head/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xffffff80f0c32690 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80f0c32740 witness_checkorder() at witness_checkorder+0xc47/frame = 0xffffff80f0c327c0 _sx_xlock() at _sx_xlock+0x66/frame 0xffffff80f0c32800 ufsdirhash_remove() at ufsdirhash_remove+0x37/frame 0xffffff80f0c32830 ufs_dirremove() at ufs_dirremove+0x116/frame 0xffffff80f0c32880 ufs_remove() at ufs_remove+0x75/frame 0xffffff80f0c328e0 VOP_REMOVE_APV() at VOP_REMOVE_APV+0xc8/frame 0xffffff80f0c32900 kern_unlinkat() at kern_unlinkat+0x20b/frame 0xffffff80f0c32aa0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff80f0c32bb0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff80f0c32bb0 --- syscall (10, FreeBSD ELF64, sys_unlink), rip =3D 0x80091a61a, rsp =3D = 0x7fffffffca78, rbp =3D 0x7fffffffdc30 --- lock order reversal: 1st 0xfffffe0006208668 ufs (ufs) @ = /data/freebsd/src/head/sys/kern/vfs_mount.c:851 2nd 0xfffffe00371d1098 devfs (devfs) @ = /data/freebsd/src/head/sys/kern/vfs_subr.c:2161 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xffffff80f6e283f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80f6e284a0 witness_checkorder() at witness_checkorder+0xc47/frame = 0xffffff80f6e28520 __lockmgr_args() at __lockmgr_args+0x6e2/frame 0xffffff80f6e28650 vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff80f6e28670 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff80f6e28690 _vn_lock() at _vn_lock+0xab/frame 0xffffff80f6e28700 vget() at vget+0x70/frame 0xffffff80f6e28750 devfs_allocv() at devfs_allocv+0xfd/frame 0xffffff80f6e287a0 devfs_root() at devfs_root+0x43/frame 0xffffff80f6e287d0 vfs_donmount() at vfs_donmount+0xf92/frame 0xffffff80f6e28a60 sys_nmount() at sys_nmount+0x72/frame 0xffffff80f6e28aa0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff80f6e28bb0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff80f6e28bb0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x800a950fa, rsp =3D= 0x7fffffffccc8, rbp =3D 0x7fffffffd230 --- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:46:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F2FEB6D; Fri, 14 Dec 2012 12:46:21 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF44E8FC0A; Fri, 14 Dec 2012 12:46:20 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3481456oag.13 for ; Fri, 14 Dec 2012 04:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3wWj4ruzfL421fazLYWIaM+CcXlUV2Cau0kZYRRRiWI=; b=HXDhpCEenl6/3GGpZQ9+SE/P8Wz3cr82Xgm5ie7/XtFzxLUERJ4FUFAwHgPD8aGFds bB6IyQqJln5D6/0euBnluPOJA6nFyVUxkPnN15ACq9LRQI3+KcZ6FiPiqwA+aYJ5do6J Xxo6KYn1EpMt/4qxS0KOVOigZ/zCj3Fay91SoYu9xNKFW8dP3vy5Zj65paJkxEiOJWMm 4aXiLdBhGqsMxBWJHYAGC0exL92NRkZFXygF9Lt8FrBqQP7Ll7HwY/85LVApHoJGfXIF Iv29GLVNI47AqY1V224NOg0LEQcCTftChjvyqYge9QmI1nvX1ckQsPZ53EBsvU+4UCWX L13A== MIME-Version: 1.0 Received: by 10.60.30.70 with SMTP id q6mr4413600oeh.107.1355489179901; Fri, 14 Dec 2012 04:46:19 -0800 (PST) Received: by 10.60.170.167 with HTTP; Fri, 14 Dec 2012 04:46:19 -0800 (PST) In-Reply-To: <50C9B33C.9020505@FreeBSD.org> References: <50C9B33C.9020505@FreeBSD.org> Date: Fri, 14 Dec 2012 14:46:19 +0200 Message-ID: Subject: Re: Reproduceable hang From: Alexander Yerenkow To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 12:46:21 -0000 Setup: ESXi 5.1.0 Seems this happens when vmmemctl.ko loaded (from their latest vmtools), and when you give a bit more memory than there is free. 2012/12/13 Andriy Gapon > on 13/12/2012 12:46 Alexander Yerenkow said the following: > > 2012/12/13 Alexander Yerenkow > > > >> Hello there. > >> I have here 100% reproduceable hangs when run one custom java program. > >> Can someone look into? > >> > >> I can give some more info (some other trace) if required. > >> > >> > > > > > > If someone didn't get attachment - here's link to screenshot > > > > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl > > Looks like either a bug or an "out-of-sync" issue in whatever > (virtualization?) > driver that has function OS_ReservedPageAlloc. > > -- > Andriy Gapon > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:55:23 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B89AD17; Fri, 14 Dec 2012 12:55:23 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE928FC0A; Fri, 14 Dec 2012 12:55:23 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id F0AF21FA5DAA; Fri, 14 Dec 2012 13:55:21 +0100 (CET) From: "Ganael LAPLANCHE" To: freebsd-current@FreeBSD.org Subject: Lenovo x220 suspend/resume broken X-Openwebmail-Date: Fri, 14 Dec 2012 14:55:21 +0200 Message-Id: <20121214124854.M44964@martymac.org> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Fri, 14 Dec 2012 12:55:23 +0000 (UTC) Cc: sendtomatt@gmail.com, jkim@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 12:55:23 -0000 Hi everyone, Following this thread : http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032519.html I have finally taken time to track this regression. It occurs with revision 231797 : http://svnweb.freebsd.org/base?view=revision&revision=231797 Could anyone have a look at it ? Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:57:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A24C9E42; Fri, 14 Dec 2012 12:57:44 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 285DB8FC08; Fri, 14 Dec 2012 12:57:43 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so1650624vcb.13 for ; Fri, 14 Dec 2012 04:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8PJB2ecllx1iDqVgIRkKoBl1zftOU9L4PS3dIO1jDlk=; b=HQu4Wz4olQxj5ZoZ5m0AnHXJw99h5xeCcI1PsImakr8PBgnlgDerL9USEPuJe2yXZ/ E7NrpsV4UGGNts38KMtPpA9DCtTIPsCIzsCl5lhlU5N/0Ud4/ffnh1Ga9gpkrvFwJznh 0ZCztZwtqbU7eeV8smtFkR1B4TF3itsMszPLgF78bqxoJVJa1ByZw9TbGDeNqUohSN06 Ff+aAdbfNJuk0jfKOj3+L+iphF3p7Elsd7HPbzTkeEg0vFjgpYz1qG1ZGxfZI5QUIi7+ FywBy2pSGOYD3ggAoeyPfyKmbb3IwLEyaFzdaIyxZyDlmHGw3/Ms3lWJtVyqJcQyDSPt bbdw== MIME-Version: 1.0 Received: by 10.220.154.148 with SMTP id o20mr8871880vcw.54.1355489857090; Fri, 14 Dec 2012 04:57:37 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Fri, 14 Dec 2012 04:57:36 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 13:57:36 +0100 X-Google-Sender-Auth: Ifv5VTCJMyv6JvwmdGGnT1itmkw Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Luigi Rizzo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 12:57:44 -0000 On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: > > On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano > wrote: >> >> Hi. >> This patch takes callout(9) and redesign the KPI and the >> implementation. The main objective of this work is making the >> subsystem tickless. In the last several years, this possibility has >> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), >> but until now noone really implemented that. >> If you want a complete history of what has been done in the last >> months you can check the calloutng project repository >> http://svnweb.freebsd.org/base/projects/calloutng/ >> For lazy people, here's a summary: > > > thanks for the work and the detailed summary. > Perhaps it would be useful if you could provide a few high level > details on the use and performance of the new scheme, such as: > > - is the old callout KPI still available ? (i am asking because it would > help maintaining third party kernel modules that are expected to > work on different FreeBSD releases) > Obviously the old KPI is still available. callout(9) is a very popular interface and I don't think removing the old interface is a good idea, because could make unhappy some vendor when its code doesn't build anymore on FreeBSD. > - do you have numbers on what is the fastest rate at which callouts > can be fired (e.g. say you have a callout which increments a > counter and schedules the next callout in (struct bintime){0,1} ) ? > > > - is there a possibility that if callout requests are too close to each > other (e.g. the above test) the thread dispatching callouts will > run forever ? if so, is there a way to make such thread yield > after a while ? > > - since you mentioned nanosleep() poll() and select() have been > ported to the new callout, is there a way to guarantee that user > using these functions with a very short timeout are actually > descheduled as opposed to "interval too short, don't bother" ? > > - do you have numbers on how many calls per second we can > have for a process that does > for (;;) { nanosleep(min_value_that_causes_descheduling); > > I also have some comments on the diff: > - can you provide a diff -p ? > > - for several functions the only change is the name of an argument > from "busy" to "us". Can you elaborate the reason for the change, > and whether "us" means microseconds or the pronoun ?) > Please see r242905 by mav@. > Finally, a more substantial comment: > - a lot of functions which formerly had only a "timo" argument > now have "timo, bt, precision, flags". Take seltdwait() as an example. > seltdwait() is not part of the public KPI. It has been modified to avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e. two separate functions, even though we could share most of the code is not a clever approach, IMHO. As I told before, seltdwait() is not exposed so we can modify its argument without breaking anything. > It seems that you have been undecided between two approaches: > for some of these functions you have preserved the original function > that deals with ticks and introduced a new one that deals with the > bintime, > whereas in other cases you have modified the original function to add > "bt, precision, flags". > I'm not. All the functions which are part of the public KPI (e.g. condvar(9), sleepq(9), *) are still available. *_flags variants have been introduced so that consumers can take advantage of the new 'precision tolerance mechanism' implemented. Also, *_bt variants have been introduced. I don't see any "undecision" between the two approaches. Please note that now the callout backend deals with bintime, so every time callout_reset_on() is called, the 'tick' argument passed is silently converted to bintime. > I would suggest a more uniform approach, namely: > - preserve all the existing functions (T) that take a timeout in ticks; > - add a new set of corresponding functions (BT) that take > bt, precision, flags _instead_ of the ticks > - the functions (T) make immediately the conversion from ticks to > bintime(s), using macros or inline > - optionally, convert kernel components to the new (BT) functions > where this makes sense (e.g. we can exploit the finer-granularity > of the new calls, etc.) > > cheers > luigi > > 1) callout(9) is not anymore constrained to the resolution a periodic >> >> "hz" clock can give. In order to do that, the eventtimers(4) subsystem >> is used as backend. >> 2) Conversely from what discussed in past, we maintained the callwheel >> as underlying data structure for keeping track of the outstading >> timeouts. This choice has a couple of advantages, in particular we can >> still take benefits from the O(1) average complexity of the wheel for >> all the operations. Also, we thought the code duplication that would >> arise from the use of a two-staged backend for callout (e.g. use wheel >> for coarse resolution event and another data structure, such as an >> heap for high resolution events), is unacceptable. In fact, as long as >> callout gained the ability to migrate from a cpu to another having a >> double backend would mean doubling the code for the migration path. >> 3) A way to dispatch interrupts from hardware interrupt context has >> been implemented, using special callout flag. This has limited >> applicability, but avoid the dispatching of a SWI thread for handling >> specific callouts, avoiding the wake up of another CPU for processing >> and a (relatively useless) context switch >> 4) As long as new callout mechanism deals with bintime and not anymore >> with ticks, time is specified as absolute and not relative anymore. In >> order to get current time binuptime() or getbinuptime() is used, and a >> sysctl is introduced to selectively choose the function to use, based >> on a precision threshold. >> 5) A mechanism for specifying precision tolerance has been >> implemented. The callout processing mechanism has been adapted and the >> callout data structure augmented so that the codepath can take >> advantage and aggregate events which overlap in time. >> >> >> The new proposed KPI for callout is the following: >> callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., in= t >> flags) >> where =91time=92 argument represets the time at which the callout should >> fire, =91pr=92 represents the precision tolerance expressed as an absolu= te >> value, and =91flags=92, which could be used to specify new features, i.e= . >> for now, the possibility to run the callout from fast interrupt >> context. >> The old KPI has been extended introducing the callout_reset_flags() >> function, which is the same of callout_reset*(), but takes an >> additional argument =91int flags=92 that can be used in the same fashion >> of the =91flags=92 argument for the new KPI. Using the =91flags=92 consu= mers >> can also specify relative precision tolerance in terms of power-of-two >> portion of the timeout passed as ticks. >> Using this strategy, the new precision mechanism can be used for the >> existing services without major modifications. >> >> Some consumers have been ported to the new KPI, in particular >> nanosleep(), poll(), select(), because they take immediate advantage >> from the arbitrary precision offered by the new infrastructure. >> For some statistics about the outcome of the conversion to the new >> service, please refer to the end of this e-mail: >> http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html >> We didn't measure any significant performance regressions with >> hwmpc(4), using some benckmarks programs: >> http://people.freebsd.org/~davide/poll_test/poll_test.c >> http://people.freebsd.org/~mav/testsleep.c >> http://people.freebsd.org/~mav/testidle.c >> >> We tested the code on amd64, MIPS and arm. Any kind of testing or >> comment would be really appreciated. The full diff of the work against >> HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff >> If noone have objections, we plan to merge the repository to HEAD in a >> week or so. >> >> Thanks, >> >> Davide >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:02:12 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FAC12CC for ; Fri, 14 Dec 2012 13:02:12 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 010808FC16 for ; Fri, 14 Dec 2012 13:02: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 qBED23A4015908; Fri, 14 Dec 2012 17:02:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qBED231t015907; Fri, 14 Dec 2012 17:02:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Dec 2012 17:02:03 +0400 From: Gleb Smirnoff To: Fleuriot Damien Subject: Re: 10-CURRENT r244183 amd64 multiple lock order reversals Message-ID: <20121214130203.GI10163@FreeBSD.org> References: <5A9EB6A1-AA39-4AA5-B5FA-D566898AD248@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5A9EB6A1-AA39-4AA5-B5FA-D566898AD248@my.gd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 13:02:12 -0000 On Fri, Dec 14, 2012 at 11:56:19AM +0100, Fleuriot Damien wrote: F> First LOR, apparently in PF: F> F> altq: emulate 256000000Hz cpu clock F> lock order reversal: (sleepable after non-sleepable) F> 1st 0xffffffff81390418 pf rulesets (pf rulesets) @ /data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1153 F> 2nd 0xffffffff80e5e298 ifnet_sx (ifnet_sx) @ /data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_if.c:481 F> KDB: stack backtrace: F> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff80f6e4a9d0 F> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80f6e4aa80 F> witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff80f6e4ab00 F> _sx_slock() at _sx_slock+0x69/frame 0xffffff80f6e4ab40 F> pfi_kif_update() at pfi_kif_update+0x10d/frame 0xffffff80f6e4abb0 F> pfi_dynaddr_setup() at pfi_dynaddr_setup+0x2d1/frame 0xffffff80f6e4ac20 F> pfioctl() at pfioctl+0x4a61/frame 0xffffff80f6e4b9a0 F> devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff80f6e4ba00 F> kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff80f6e4ba50 F> sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff80f6e4baa0 F> amd64_syscall() at amd64_syscall+0x265/frame 0xffffff80f6e4bbb0 F> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff80f6e4bbb0 F> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800d923ea, rsp = 0x7fffffffbde8, rbp = 0x7fffffffc9e0 --- Strange that it wasn't noticed or reported before. Fixed. Thanks for submission. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:13:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 651F862E; Fri, 14 Dec 2012 13:13:07 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E054C8FC17; Fri, 14 Dec 2012 13:13:06 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so1677467vcb.13 for ; Fri, 14 Dec 2012 05:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2q+HuqqGX8DRlnglV+Ns18Qpoent+zbqkLMHF+3sPJ0=; b=hSlMOjCkOy3XLqSatRzGY93GCVux7B46Fogzjjvv7cCs+1UE5WGYTMCMDEXfoYQjgQ 8L0O+lXEYr/FcGtlPkiBcFtbtUiTCaw6Spju3IZRRWcdcwRB84pGrCrz4VgM41wwiidb HeaU509NMARDqIIF1s+l1tBYTHytaAN5CePFu9RsDQuPJp+FKHnJYTb+FL65RhMiX24p me2EaStiHZ0t0REaiQVhlxhv1Dnvz5ppEkKfhFEEPx6qgEnuq/Lc/7FxN9Prh+kX+dHB vAd3PkunhpNOO4MxLS6Zc0sLFJDPIFOR1/tXyqKbgHpdOhaHmnyi9NgvIPfBuPKT9tzO sRLQ== MIME-Version: 1.0 Received: by 10.52.92.139 with SMTP id cm11mr7744830vdb.85.1355490785961; Fri, 14 Dec 2012 05:13:05 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Fri, 14 Dec 2012 05:13:05 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 14:13:05 +0100 X-Google-Sender-Auth: fVarY5sYh8B5WuY61x-2-2K7Uvo Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Luigi Rizzo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 13:13:07 -0000 On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano wrote= : > On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: >> >> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano >> wrote: >>> >>> Hi. >>> This patch takes callout(9) and redesign the KPI and the >>> implementation. The main objective of this work is making the >>> subsystem tickless. In the last several years, this possibility has >>> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), >>> but until now noone really implemented that. >>> If you want a complete history of what has been done in the last >>> months you can check the calloutng project repository >>> http://svnweb.freebsd.org/base/projects/calloutng/ >>> For lazy people, here's a summary: >> >> >> thanks for the work and the detailed summary. >> Perhaps it would be useful if you could provide a few high level >> details on the use and performance of the new scheme, such as: >> >> - is the old callout KPI still available ? (i am asking because it would >> help maintaining third party kernel modules that are expected to >> work on different FreeBSD releases) >> > > Obviously the old KPI is still available. callout(9) is a very popular > interface and I don't think removing the old interface is a good idea, > because could make unhappy some vendor when its code doesn't build > anymore on FreeBSD. > >> - do you have numbers on what is the fastest rate at which callouts >> can be fired (e.g. say you have a callout which increments a >> counter and schedules the next callout in (struct bintime){0,1} ) ? >> Right now, all the services rely on the old interface. This means they cannot be fired before 1 tick has elapsed, e.g. considering hz =3D 1000 on most of the machines, 1 millisecond. Now that nanosleep() relies on the new interface, we measured 4-5 microseconds latency for the processing before the callout is actually fired. I can't say if we can still lower this value, but I cannot imagine, for now, a consumer that actually request a shorter timeout. >> >> - is there a possibility that if callout requests are too close to each >> other (e.g. the above test) the thread dispatching callouts will >> run forever ? if so, is there a way to make such thread yield >> after a while ? >> Most of the processing is still done in a SWI thread, "at a later time", so I don't think this is a problem. >> - since you mentioned nanosleep() poll() and select() have been >> ported to the new callout, is there a way to guarantee that user >> using these functions with a very short timeout are actually >> descheduled as opposed to "interval too short, don't bother" ? >> >> - do you have numbers on how many calls per second we can >> have for a process that does >> for (;;) { nanosleep(min_value_that_causes_descheduling); >> I don't follow you here. >> I also have some comments on the diff: >> - can you provide a diff -p ? >> >> - for several functions the only change is the name of an argument >> from "busy" to "us". Can you elaborate the reason for the change, >> and whether "us" means microseconds or the pronoun ?) >> > > Please see r242905 by mav@. > >> Finally, a more substantial comment: >> - a lot of functions which formerly had only a "timo" argument >> now have "timo, bt, precision, flags". Take seltdwait() as an example. >> > > seltdwait() is not part of the public KPI. It has been modified to > avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e. > two separate functions, even though we could share most of the code is > not a clever approach, IMHO. > As I told before, seltdwait() is not exposed so we can modify its > argument without breaking anything. > >> It seems that you have been undecided between two approaches: >> for some of these functions you have preserved the original function >> that deals with ticks and introduced a new one that deals with the >> bintime, >> whereas in other cases you have modified the original function to add >> "bt, precision, flags". >> > > I'm not. All the functions which are part of the public KPI (e.g. > condvar(9), sleepq(9), *) are still available. *_flags variants have > been introduced so that consumers can take advantage of the new > 'precision tolerance mechanism' implemented. Also, *_bt variants have > been introduced. I don't see any "undecision" between the two > approaches. > Please note that now the callout backend deals with bintime, so every > time callout_reset_on() is called, the 'tick' argument passed is > silently converted to bintime. > >> I would suggest a more uniform approach, namely: >> - preserve all the existing functions (T) that take a timeout in ticks= ; >> - add a new set of corresponding functions (BT) that take >> bt, precision, flags _instead_ of the ticks >> - the functions (T) make immediately the conversion from ticks to >> bintime(s), using macros or inline >> - optionally, convert kernel components to the new (BT) functions >> where this makes sense (e.g. we can exploit the finer-granularity >> of the new calls, etc.) >> > This is the strategy we followed. > > >> cheers >> luigi >> >> 1) callout(9) is not anymore constrained to the resolution a periodic >>> >>> "hz" clock can give. In order to do that, the eventtimers(4) subsystem >>> is used as backend. >>> 2) Conversely from what discussed in past, we maintained the callwheel >>> as underlying data structure for keeping track of the outstading >>> timeouts. This choice has a couple of advantages, in particular we can >>> still take benefits from the O(1) average complexity of the wheel for >>> all the operations. Also, we thought the code duplication that would >>> arise from the use of a two-staged backend for callout (e.g. use wheel >>> for coarse resolution event and another data structure, such as an >>> heap for high resolution events), is unacceptable. In fact, as long as >>> callout gained the ability to migrate from a cpu to another having a >>> double backend would mean doubling the code for the migration path. >>> 3) A way to dispatch interrupts from hardware interrupt context has >>> been implemented, using special callout flag. This has limited >>> applicability, but avoid the dispatching of a SWI thread for handling >>> specific callouts, avoiding the wake up of another CPU for processing >>> and a (relatively useless) context switch >>> 4) As long as new callout mechanism deals with bintime and not anymore >>> with ticks, time is specified as absolute and not relative anymore. In >>> order to get current time binuptime() or getbinuptime() is used, and a >>> sysctl is introduced to selectively choose the function to use, based >>> on a precision threshold. >>> 5) A mechanism for specifying precision tolerance has been >>> implemented. The callout processing mechanism has been adapted and the >>> callout data structure augmented so that the codepath can take >>> advantage and aggregate events which overlap in time. >>> >>> >>> The new proposed KPI for callout is the following: >>> callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., i= nt >>> flags) >>> where =91time=92 argument represets the time at which the callout shoul= d >>> fire, =91pr=92 represents the precision tolerance expressed as an absol= ute >>> value, and =91flags=92, which could be used to specify new features, i.= e. >>> for now, the possibility to run the callout from fast interrupt >>> context. >>> The old KPI has been extended introducing the callout_reset_flags() >>> function, which is the same of callout_reset*(), but takes an >>> additional argument =91int flags=92 that can be used in the same fashio= n >>> of the =91flags=92 argument for the new KPI. Using the =91flags=92 cons= umers >>> can also specify relative precision tolerance in terms of power-of-two >>> portion of the timeout passed as ticks. >>> Using this strategy, the new precision mechanism can be used for the >>> existing services without major modifications. >>> >>> Some consumers have been ported to the new KPI, in particular >>> nanosleep(), poll(), select(), because they take immediate advantage >>> from the arbitrary precision offered by the new infrastructure. >>> For some statistics about the outcome of the conversion to the new >>> service, please refer to the end of this e-mail: >>> http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html >>> We didn't measure any significant performance regressions with >>> hwmpc(4), using some benckmarks programs: >>> http://people.freebsd.org/~davide/poll_test/poll_test.c >>> http://people.freebsd.org/~mav/testsleep.c >>> http://people.freebsd.org/~mav/testidle.c >>> >>> We tested the code on amd64, MIPS and arm. Any kind of testing or >>> comment would be really appreciated. The full diff of the work against >>> HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff >>> If noone have objections, we plan to merge the repository to HEAD in a >>> week or so. >>> >>> Thanks, >>> >>> Davide >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >> >> >> >> >> -- >> -----------------------------------------+------------------------------= - >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------= - >> From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:41:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0705C72; Fri, 14 Dec 2012 13:41:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 612868FC15; Fri, 14 Dec 2012 13:41:36 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so1378322wgh.31 for ; Fri, 14 Dec 2012 05:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JWYBdj5JR3VEj4FTfpwpWVVbLhjefJKWfYYDxqO77WM=; b=zq3SyrFncRzS0nkjsWGCbUEr3MKGe7M6WiAjimDwbULPbxTKjKf0knsuriwMLXu8Qt 6OgJ9RwJJ5h+UdihKXw8Sae79jIMP5d0lDYK+9dC3VJv8G53NUU1AeL1z/bSawexgSP7 og7qo8bYlc83chyAdImzwLNFpDjsPDjQ9Ddk5IGiLoN9RHvyAGEkkgMULUFsAl0ZZmvI 4B22NT7GGBZB0uPfzM/h5rpyThFJfEQf9VFGUJncdp9qE+rizYU+lDycL6ejK1azPXO2 HnppOC6tz2eDPOB8PHL/YQNxTMJQWlK0Vt9LtPE+oaIyS52NmXDM/1QHDbZNIk2NjN3i EZyA== MIME-Version: 1.0 Received: by 10.180.104.69 with SMTP id gc5mr2711451wib.13.1355492495241; Fri, 14 Dec 2012 05:41:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 14 Dec 2012 05:41:35 -0800 (PST) In-Reply-To: <20121214085607.3938D10E2C8@smtp.hushmail.com> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <201212111549.49942.jhb@freebsd.org> <20121213211100.5395F10E2C8@smtp.hushmail.com> <20121214085607.3938D10E2C8@smtp.hushmail.com> Date: Fri, 14 Dec 2012 05:41:35 -0800 X-Google-Sender-Auth: xrEoDSmdxYThJDv8sQDC2h4JBx0 Message-ID: Subject: Re: ath0: unable to attach hardware From: Adrian Chadd To: husyh@hush.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 13:41:37 -0000 Hi, Ok. I'm travelling for a little bit; if I don't reply in a few days, please poke me again. It may be that the device is asleep for a bit longer (failing this test) and has completed resetting at this point. It may be that the power on sequence is not quite right for some reason. Would you mind recompiling your kernel and making if_ath a kld, rather than statically in the kernel? Thanks, Adrian > > attached to this e-mail you find the output of dmesg. What I guess the most relevant lines could be is: > > ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device 4.0 on pci2 > ar5212ChipTest: address test failed addr: 0x00008000 - wr:0x00000000 != rd:0xffffffff > ar5212Attach: hardware self-test failed > ath0: unable to attach hardware; HAL status 14 > device_attach: ath0 attach returned 6 > > I read the registers 4004 and 4010 again to make sure the values still are the same, which indeed they are. > > I hope this helps. > > Thanks! > > On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" wrote: >> >>On 13 December 2012 13:11, wrote: >>> Hello everyone, >>> >>> I'm afraid I still don't know what exactly BAR is, or how I get >>its value that I'm supposed to plug into the line John provided: >>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) >>count=1 | hd >>> >>> I assumed that "start of bar" is 0xfdee0000 in my case, since >>dmesg reports >>> ath0: mem 0xfdee0000-0xfdeeffff irq 16 at device >>4.0 on pci2 >> >>Yup. >> >>> This is what I get: >>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4004)/4" >>| bc` count=1 | hd >>> 00 00 01 00 >>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4010)/4" >>| bc` count=1 | hd >>> 14 00 01 00 >>> >>> Please correct me if my assumption about "start of bar" was >>wrong and/or I made some other mistake. >>> Also, please don't hesitate to ask me to do anything else that >>might help you during debugging. >>> >>> Thank you very much for the effort. >> >>Hm. Wait, what's the rest of the ath0: output? >> >> >> >>Adrian From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 14:15:02 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B4E5D20; Fri, 14 Dec 2012 14:15:02 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2075B8FC0A; Fri, 14 Dec 2012 14:15:01 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3YNDKp07wTzFTXG; Fri, 14 Dec 2012 15:14:54 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRA_T6jTk50p; Fri, 14 Dec 2012 15:14:49 +0100 (CET) Received: from vwg82.hq.ignesti.it (unknown [80.74.176.55]) by winston.madpilot.net (Postfix) with ESMTPSA; Fri, 14 Dec 2012 15:14:49 +0100 (CET) Message-ID: <50CB3456.3000708@madpilot.net> Date: Fri, 14 Dec 2012 15:14:46 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD current , FreeBSD Ports Subject: Request import of fix for clang 3.2 bug Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 14:15:02 -0000 I have stumbled upon a solved bug in clang 3.2 while testing some ports: http://llvm.org/bugs/show_bug.cgi?id=14491 Fixed in this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=169451 Should the fix be imported in FreeBSD?? Thanks. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 14:21:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D48CD376; Fri, 14 Dec 2012 14:21:56 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA958FC17; Fri, 14 Dec 2012 14:21:56 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3581454oag.13 for ; Fri, 14 Dec 2012 06:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=97x28J9YvCya+h3C2TFfcQ+VeL2iGwlkcR8md7mgS3s=; b=W3g+WsXcYheGDMTGnOG2aUZhxjOInZABdVHMFN9+6ZEn9RDoMKb6tjfTUGFtgAochc Wcx3Tu6hqK5Bkki+r8G9mOYeS2quX4UFZiliMgNuUihDIgbV+JY5C6KFLb+ux5HnrJmC 5bAueKBfzYI0TP+bKUP/PMAMvOrAyvtrpFd/afp/Oe3rp5wIY/wAdzuwrqYwTouTX1uv iJhtnMGwIIflSmCJ7e6XbvUbekfVusmpXIYMPhBREV0kGUJNAZwKBoloPRiPhdk+ApiB KClC3CIW3+JZMjIj33plrkKr4NlsVGIKgGKd0HByBkK6SgmF1ZZIktHRIfgFxFBeTxkd XKXA== MIME-Version: 1.0 Received: by 10.182.17.72 with SMTP id m8mr4614135obd.55.1355494915778; Fri, 14 Dec 2012 06:21:55 -0800 (PST) Received: by 10.76.34.227 with HTTP; Fri, 14 Dec 2012 06:21:55 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 15:21:55 +0100 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Oliver Pinter To: Davide Italiano Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Luigi Rizzo , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 14:21:57 -0000 Hi! 635 - return tticks; 636 + getbinuptime(&pbt); 637 + bt.sec =3D data / 1000; 638 + bt.frac =3D (data % 1000) * (uint64_t)1844674407309000LL; 639 + bintime_add(&bt, &pbt); 640 + return bt; 641 } What is this 1844674407309000LL constant? 783 @@ -275,7 +288,7 @@ 784 do { 785 th =3D timehands; 786 gen =3D th->th_generation; 787 - bintime2timeval(&th->th_offset, tvp); 788 + Bintime2timeval(&th->th_offset, tvp); 789 } while (gen =3D=3D 0 || gen !=3D th->th_generation); 790 } 791 Capital B is there possible a typo? On 12/14/12, Davide Italiano wrote: > On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano > wrote: >> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: >>> >>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano >>> wrote: >>>> >>>> Hi. >>>> This patch takes callout(9) and redesign the KPI and the >>>> implementation. The main objective of this work is making the >>>> subsystem tickless. In the last several years, this possibility has >>>> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), >>>> but until now noone really implemented that. >>>> If you want a complete history of what has been done in the last >>>> months you can check the calloutng project repository >>>> http://svnweb.freebsd.org/base/projects/calloutng/ >>>> For lazy people, here's a summary: >>> >>> >>> thanks for the work and the detailed summary. >>> Perhaps it would be useful if you could provide a few high level >>> details on the use and performance of the new scheme, such as: >>> >>> - is the old callout KPI still available ? (i am asking because it woul= d >>> help maintaining third party kernel modules that are expected to >>> work on different FreeBSD releases) >>> >> >> Obviously the old KPI is still available. callout(9) is a very popular >> interface and I don't think removing the old interface is a good idea, >> because could make unhappy some vendor when its code doesn't build >> anymore on FreeBSD. >> >>> - do you have numbers on what is the fastest rate at which callouts >>> can be fired (e.g. say you have a callout which increments a >>> counter and schedules the next callout in (struct bintime){0,1} ) ? >>> > > Right now, all the services rely on the old interface. This means they > cannot be fired before 1 tick has elapsed, e.g. considering hz =3D 1000 > on most of the machines, 1 millisecond. > Now that nanosleep() relies on the new interface, we measured 4-5 > microseconds latency for the processing before the callout is actually > fired. I can't say if we can still lower this value, but I cannot > imagine, for now, a consumer that actually request a shorter timeout. > >>> >>> - is there a possibility that if callout requests are too close to each >>> other (e.g. the above test) the thread dispatching callouts will >>> run forever ? if so, is there a way to make such thread yield >>> after a while ? >>> > > Most of the processing is still done in a SWI thread, "at a later > time", so I don't think this is a problem. > >>> - since you mentioned nanosleep() poll() and select() have been >>> ported to the new callout, is there a way to guarantee that user >>> using these functions with a very short timeout are actually >>> descheduled as opposed to "interval too short, don't bother" ? >>> >>> - do you have numbers on how many calls per second we can >>> have for a process that does >>> for (;;) { nanosleep(min_value_that_causes_descheduling); >>> > > I don't follow you here. > >>> I also have some comments on the diff: >>> - can you provide a diff -p ? >>> >>> - for several functions the only change is the name of an argument >>> from "busy" to "us". Can you elaborate the reason for the change, >>> and whether "us" means microseconds or the pronoun ?) >>> >> >> Please see r242905 by mav@. >> >>> Finally, a more substantial comment: >>> - a lot of functions which formerly had only a "timo" argument >>> now have "timo, bt, precision, flags". Take seltdwait() as an example= . >>> >> >> seltdwait() is not part of the public KPI. It has been modified to >> avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e. >> two separate functions, even though we could share most of the code is >> not a clever approach, IMHO. >> As I told before, seltdwait() is not exposed so we can modify its >> argument without breaking anything. >> >>> It seems that you have been undecided between two approaches: >>> for some of these functions you have preserved the original function >>> that deals with ticks and introduced a new one that deals with the >>> bintime, >>> whereas in other cases you have modified the original function to add >>> "bt, precision, flags". >>> >> >> I'm not. All the functions which are part of the public KPI (e.g. >> condvar(9), sleepq(9), *) are still available. *_flags variants have >> been introduced so that consumers can take advantage of the new >> 'precision tolerance mechanism' implemented. Also, *_bt variants have >> been introduced. I don't see any "undecision" between the two >> approaches. >> Please note that now the callout backend deals with bintime, so every >> time callout_reset_on() is called, the 'tick' argument passed is >> silently converted to bintime. >> >>> I would suggest a more uniform approach, namely: >>> - preserve all the existing functions (T) that take a timeout in >>> ticks; >>> - add a new set of corresponding functions (BT) that take >>> bt, precision, flags _instead_ of the ticks >>> - the functions (T) make immediately the conversion from ticks to >>> bintime(s), using macros or inline >>> - optionally, convert kernel components to the new (BT) functions >>> where this makes sense (e.g. we can exploit the finer-granularity >>> of the new calls, etc.) >>> >> > > This is the strategy we followed. > >> >> >>> cheers >>> luigi >>> >>> 1) callout(9) is not anymore constrained to the resolution a periodic >>>> >>>> "hz" clock can give. In order to do that, the eventtimers(4) subsystem >>>> is used as backend. >>>> 2) Conversely from what discussed in past, we maintained the callwheel >>>> as underlying data structure for keeping track of the outstading >>>> timeouts. This choice has a couple of advantages, in particular we can >>>> still take benefits from the O(1) average complexity of the wheel for >>>> all the operations. Also, we thought the code duplication that would >>>> arise from the use of a two-staged backend for callout (e.g. use wheel >>>> for coarse resolution event and another data structure, such as an >>>> heap for high resolution events), is unacceptable. In fact, as long as >>>> callout gained the ability to migrate from a cpu to another having a >>>> double backend would mean doubling the code for the migration path. >>>> 3) A way to dispatch interrupts from hardware interrupt context has >>>> been implemented, using special callout flag. This has limited >>>> applicability, but avoid the dispatching of a SWI thread for handling >>>> specific callouts, avoiding the wake up of another CPU for processing >>>> and a (relatively useless) context switch >>>> 4) As long as new callout mechanism deals with bintime and not anymore >>>> with ticks, time is specified as absolute and not relative anymore. In >>>> order to get current time binuptime() or getbinuptime() is used, and a >>>> sysctl is introduced to selectively choose the function to use, based >>>> on a precision threshold. >>>> 5) A mechanism for specifying precision tolerance has been >>>> implemented. The callout processing mechanism has been adapted and the >>>> callout data structure augmented so that the codepath can take >>>> advantage and aggregate events which overlap in time. >>>> >>>> >>>> The new proposed KPI for callout is the following: >>>> callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., >>>> int >>>> flags) >>>> where =91time=92 argument represets the time at which the callout shou= ld >>>> fire, =91pr=92 represents the precision tolerance expressed as an abso= lute >>>> value, and =91flags=92, which could be used to specify new features, i= .e. >>>> for now, the possibility to run the callout from fast interrupt >>>> context. >>>> The old KPI has been extended introducing the callout_reset_flags() >>>> function, which is the same of callout_reset*(), but takes an >>>> additional argument =91int flags=92 that can be used in the same fashi= on >>>> of the =91flags=92 argument for the new KPI. Using the =91flags=92 con= sumers >>>> can also specify relative precision tolerance in terms of power-of-two >>>> portion of the timeout passed as ticks. >>>> Using this strategy, the new precision mechanism can be used for the >>>> existing services without major modifications. >>>> >>>> Some consumers have been ported to the new KPI, in particular >>>> nanosleep(), poll(), select(), because they take immediate advantage >>>> from the arbitrary precision offered by the new infrastructure. >>>> For some statistics about the outcome of the conversion to the new >>>> service, please refer to the end of this e-mail: >>>> http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html >>>> We didn't measure any significant performance regressions with >>>> hwmpc(4), using some benckmarks programs: >>>> http://people.freebsd.org/~davide/poll_test/poll_test.c >>>> http://people.freebsd.org/~mav/testsleep.c >>>> http://people.freebsd.org/~mav/testidle.c >>>> >>>> We tested the code on amd64, MIPS and arm. Any kind of testing or >>>> comment would be really appreciated. The full diff of the work against >>>> HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff >>>> If noone have objections, we plan to merge the repository to HEAD in a >>>> week or so. >>>> >>>> Thanks, >>>> >>>> Davide >>>> _______________________________________________ >>>> 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" >>> >>> >>> >>> >>> -- >>> -----------------------------------------+-----------------------------= -- >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazion= e >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>> TEL +39-050-2211611 . via Diotisalvi 2 >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> -----------------------------------------+-----------------------------= -- >>> > _______________________________________________ > 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 Fri Dec 14 14:20:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A3AD159; Fri, 14 Dec 2012 14:20:10 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB8C8FC12; Fri, 14 Dec 2012 14:20:09 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id qBEEJxnV002540 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 14:20:00 GMT (envelope-from theraven@theravensnest.org) Subject: Re: Request import of fix for clang 3.2 bug Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50CB3456.3000708@madpilot.net> Date: Fri, 14 Dec 2012 14:19:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50CB3456.3000708@madpilot.net> To: Guido Falsi X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 14 Dec 2012 14:38:40 +0000 Cc: FreeBSD Ports , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 14:20:10 -0000 Looks like it's been imported to the 3.2 branch, so we should get it = when dim pulls in the latest version. David On 14 Dec 2012, at 14:14, Guido Falsi wrote: > I have stumbled upon a solved bug in clang 3.2 while testing some = ports: >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D14491 >=20 > Fixed in this commit: >=20 > http://llvm.org/viewvc/llvm-project?view=3Drev&revision=3D169451 >=20 > Should the fix be imported in FreeBSD?? >=20 > Thanks. >=20 > --=20 > Guido Falsi > _______________________________________________ > 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 Fri Dec 14 14:39:46 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4489B89 for ; Fri, 14 Dec 2012 14:39:46 +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 017F28FC14 for ; Fri, 14 Dec 2012 14:39:45 +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 QAA28352; Fri, 14 Dec 2012 16:39:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50CB3A2E.7030407@FreeBSD.org> Date: Fri, 14 Dec 2012 16:39:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Yerenkow Subject: Re: Reproduceable hang References: <50C9B33C.9020505@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 14:39:46 -0000 on 14/12/2012 14:46 Alexander Yerenkow said the following: > Setup: ESXi 5.1.0 > Seems this happens when vmmemctl.ko loaded (from their latest vmtools), and when > you give a bit more memory than there is free. This is weird... As I can see in os_kmem_alloc function (in modules/freebsd/vmmemctl/os.c of /usr/ports/emulators/open-vm-tools port), the object lock is correctly acquired there. I suspect some binary incompatibility between the module and your kernel. Try to recompile the module again using the same source tree tree and the option. > 2012/12/13 Andriy Gapon > > > on 13/12/2012 12:46 Alexander Yerenkow said the following: > > 2012/12/13 Alexander Yerenkow > > > > >> Hello there. > >> I have here 100% reproduceable hangs when run one custom java program. > >> Can someone look into? > >> > >> I can give some more info (some other trace) if required. > >> > >> > > > > > > If someone didn't get attachment - here's link to screenshot > > > > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl > > Looks like either a bug or an "out-of-sync" issue in whatever (virtualization?) > driver that has function OS_ReservedPageAlloc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 14:42:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B26F2CCF; Fri, 14 Dec 2012 14:42:20 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1968FC15; Fri, 14 Dec 2012 14:42:19 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so1849222vcb.13 for ; Fri, 14 Dec 2012 06:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qOhXhYMsRcEo6Ji3MGDvErU9Ml4I9pNNXrR6HdVSpY8=; b=OB0aie8Mp5rAliaIqP98zB7P1+wtZKeU4v5nE5eKoHhUPqkHYOHyJGJ+NVVMeAt9+6 qxwsBl5/oxzCgFPL1+Rs5XdZgfqCebm4OEVr9Mifv0aGPcD+u2UMque2rWm0qgC8I34q yXeW6ND9C2zuyIP720k8M2V1oWQvVLZE2km/tVtpWieU1xKNYMU7kk4uhiXFbIkIYzvl o8RhWqgIWol4uLVn6TOSbtC/OhzR2XKnkgwwGX8GMF1IDnclvEG6zPw9a349YZfLK7eC QsjDwehyf5HZ2GL82egM/guwDrQfiPTxzKyERQ4uzTrScs84ziYmZ9zXF7JSCl/p8vbF i/1A== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr8057207vdu.99.1355496138797; Fri, 14 Dec 2012 06:42:18 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Fri, 14 Dec 2012 06:42:18 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 15:42:18 +0100 X-Google-Sender-Auth: e1H7Zj66rHMppm5oDrHiD1IuL1A Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Oliver Pinter Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Luigi Rizzo , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 14:42:20 -0000 On Fri, Dec 14, 2012 at 3:21 PM, Oliver Pinter wrot= e: > Hi! > > 635 - return tticks; > 636 + getbinuptime(&pbt); > 637 + bt.sec =3D data / 1000; > 638 + bt.frac =3D (data % 1000) * (uint64_t)1844674407309000LL; > 639 + bintime_add(&bt, &pbt); > 640 + return bt; > 641 } > > What is this 1844674407309000LL constant? > > > 783 @@ -275,7 +288,7 @@ > 784 do { > 785 th =3D timehands; > 786 gen =3D th->th_generation; > 787 - bintime2timeval(&th->th_offset, tvp); > 788 + Bintime2timeval(&th->th_offset, tvp); > 789 } while (gen =3D=3D 0 || gen !=3D th->th_generation); > 790 } > 791 > > Capital B is there possible a typo? > Hi Oliver, thanks for reporting. Yes, both are typos. The costant is /* 18446744073709 =3D int(2^64 / 1000000) */ used to convert from timeval to bintime. > On 12/14/12, Davide Italiano wrote: >> On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano >> wrote: >>> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote= : >>>> >>>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano >>>> wrote: >>>>> >>>>> Hi. >>>>> This patch takes callout(9) and redesign the KPI and the >>>>> implementation. The main objective of this work is making the >>>>> subsystem tickless. In the last several years, this possibility has >>>>> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), >>>>> but until now noone really implemented that. >>>>> If you want a complete history of what has been done in the last >>>>> months you can check the calloutng project repository >>>>> http://svnweb.freebsd.org/base/projects/calloutng/ >>>>> For lazy people, here's a summary: >>>> >>>> >>>> thanks for the work and the detailed summary. >>>> Perhaps it would be useful if you could provide a few high level >>>> details on the use and performance of the new scheme, such as: >>>> >>>> - is the old callout KPI still available ? (i am asking because it wou= ld >>>> help maintaining third party kernel modules that are expected to >>>> work on different FreeBSD releases) >>>> >>> >>> Obviously the old KPI is still available. callout(9) is a very popular >>> interface and I don't think removing the old interface is a good idea, >>> because could make unhappy some vendor when its code doesn't build >>> anymore on FreeBSD. >>> >>>> - do you have numbers on what is the fastest rate at which callouts >>>> can be fired (e.g. say you have a callout which increments a >>>> counter and schedules the next callout in (struct bintime){0,1} ) ? >>>> >> >> Right now, all the services rely on the old interface. This means they >> cannot be fired before 1 tick has elapsed, e.g. considering hz =3D 1000 >> on most of the machines, 1 millisecond. >> Now that nanosleep() relies on the new interface, we measured 4-5 >> microseconds latency for the processing before the callout is actually >> fired. I can't say if we can still lower this value, but I cannot >> imagine, for now, a consumer that actually request a shorter timeout. >> >>>> >>>> - is there a possibility that if callout requests are too close to eac= h >>>> other (e.g. the above test) the thread dispatching callouts will >>>> run forever ? if so, is there a way to make such thread yield >>>> after a while ? >>>> >> >> Most of the processing is still done in a SWI thread, "at a later >> time", so I don't think this is a problem. >> >>>> - since you mentioned nanosleep() poll() and select() have been >>>> ported to the new callout, is there a way to guarantee that user >>>> using these functions with a very short timeout are actually >>>> descheduled as opposed to "interval too short, don't bother" ? >>>> >>>> - do you have numbers on how many calls per second we can >>>> have for a process that does >>>> for (;;) { nanosleep(min_value_that_causes_descheduling); >>>> >> >> I don't follow you here. >> >>>> I also have some comments on the diff: >>>> - can you provide a diff -p ? >>>> >>>> - for several functions the only change is the name of an argument >>>> from "busy" to "us". Can you elaborate the reason for the change, >>>> and whether "us" means microseconds or the pronoun ?) >>>> >>> >>> Please see r242905 by mav@. >>> >>>> Finally, a more substantial comment: >>>> - a lot of functions which formerly had only a "timo" argument >>>> now have "timo, bt, precision, flags". Take seltdwait() as an exampl= e. >>>> >>> >>> seltdwait() is not part of the public KPI. It has been modified to >>> avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e. >>> two separate functions, even though we could share most of the code is >>> not a clever approach, IMHO. >>> As I told before, seltdwait() is not exposed so we can modify its >>> argument without breaking anything. >>> >>>> It seems that you have been undecided between two approaches: >>>> for some of these functions you have preserved the original function >>>> that deals with ticks and introduced a new one that deals with the >>>> bintime, >>>> whereas in other cases you have modified the original function to ad= d >>>> "bt, precision, flags". >>>> >>> >>> I'm not. All the functions which are part of the public KPI (e.g. >>> condvar(9), sleepq(9), *) are still available. *_flags variants have >>> been introduced so that consumers can take advantage of the new >>> 'precision tolerance mechanism' implemented. Also, *_bt variants have >>> been introduced. I don't see any "undecision" between the two >>> approaches. >>> Please note that now the callout backend deals with bintime, so every >>> time callout_reset_on() is called, the 'tick' argument passed is >>> silently converted to bintime. >>> >>>> I would suggest a more uniform approach, namely: >>>> - preserve all the existing functions (T) that take a timeout in >>>> ticks; >>>> - add a new set of corresponding functions (BT) that take >>>> bt, precision, flags _instead_ of the ticks >>>> - the functions (T) make immediately the conversion from ticks to >>>> bintime(s), using macros or inline >>>> - optionally, convert kernel components to the new (BT) functions >>>> where this makes sense (e.g. we can exploit the finer-granularity >>>> of the new calls, etc.) >>>> >>> >> >> This is the strategy we followed. >> >>> >>> >>>> cheers >>>> luigi >>>> >>>> 1) callout(9) is not anymore constrained to the resolution a periodic >>>>> >>>>> "hz" clock can give. In order to do that, the eventtimers(4) subsyste= m >>>>> is used as backend. >>>>> 2) Conversely from what discussed in past, we maintained the callwhee= l >>>>> as underlying data structure for keeping track of the outstading >>>>> timeouts. This choice has a couple of advantages, in particular we ca= n >>>>> still take benefits from the O(1) average complexity of the wheel for >>>>> all the operations. Also, we thought the code duplication that would >>>>> arise from the use of a two-staged backend for callout (e.g. use whee= l >>>>> for coarse resolution event and another data structure, such as an >>>>> heap for high resolution events), is unacceptable. In fact, as long a= s >>>>> callout gained the ability to migrate from a cpu to another having a >>>>> double backend would mean doubling the code for the migration path. >>>>> 3) A way to dispatch interrupts from hardware interrupt context has >>>>> been implemented, using special callout flag. This has limited >>>>> applicability, but avoid the dispatching of a SWI thread for handling >>>>> specific callouts, avoiding the wake up of another CPU for processing >>>>> and a (relatively useless) context switch >>>>> 4) As long as new callout mechanism deals with bintime and not anymor= e >>>>> with ticks, time is specified as absolute and not relative anymore. I= n >>>>> order to get current time binuptime() or getbinuptime() is used, and = a >>>>> sysctl is introduced to selectively choose the function to use, based >>>>> on a precision threshold. >>>>> 5) A mechanism for specifying precision tolerance has been >>>>> implemented. The callout processing mechanism has been adapted and th= e >>>>> callout data structure augmented so that the codepath can take >>>>> advantage and aggregate events which overlap in time. >>>>> >>>>> >>>>> The new proposed KPI for callout is the following: >>>>> callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., >>>>> int >>>>> flags) >>>>> where =91time=92 argument represets the time at which the callout sho= uld >>>>> fire, =91pr=92 represents the precision tolerance expressed as an abs= olute >>>>> value, and =91flags=92, which could be used to specify new features, = i.e. >>>>> for now, the possibility to run the callout from fast interrupt >>>>> context. >>>>> The old KPI has been extended introducing the callout_reset_flags() >>>>> function, which is the same of callout_reset*(), but takes an >>>>> additional argument =91int flags=92 that can be used in the same fash= ion >>>>> of the =91flags=92 argument for the new KPI. Using the =91flags=92 co= nsumers >>>>> can also specify relative precision tolerance in terms of power-of-tw= o >>>>> portion of the timeout passed as ticks. >>>>> Using this strategy, the new precision mechanism can be used for the >>>>> existing services without major modifications. >>>>> >>>>> Some consumers have been ported to the new KPI, in particular >>>>> nanosleep(), poll(), select(), because they take immediate advantage >>>>> from the arbitrary precision offered by the new infrastructure. >>>>> For some statistics about the outcome of the conversion to the new >>>>> service, please refer to the end of this e-mail: >>>>> http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html >>>>> We didn't measure any significant performance regressions with >>>>> hwmpc(4), using some benckmarks programs: >>>>> http://people.freebsd.org/~davide/poll_test/poll_test.c >>>>> http://people.freebsd.org/~mav/testsleep.c >>>>> http://people.freebsd.org/~mav/testidle.c >>>>> >>>>> We tested the code on amd64, MIPS and arm. Any kind of testing or >>>>> comment would be really appreciated. The full diff of the work agains= t >>>>> HEAD can be found at: http://people.freebsd.org/~davide/calloutng.dif= f >>>>> If noone have objections, we plan to merge the repository to HEAD in = a >>>>> week or so. >>>>> >>>>> Thanks, >>>>> >>>>> Davide >>>>> _______________________________________________ >>>>> 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" >>>> >>>> >>>> >>>> >>>> -- >>>> -----------------------------------------+----------------------------= --- >>>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazio= ne >>>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>> TEL +39-050-2211611 . via Diotisalvi 2 >>>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>> -----------------------------------------+----------------------------= --- >>>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:00:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCCB8603; Fri, 14 Dec 2012 15:00:47 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 75A478FC08; Fri, 14 Dec 2012 15:00:47 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3630647oag.13 for ; Fri, 14 Dec 2012 07:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QnNNKVQMOJY2sF4bDK6ltikGnPOwkfmX7jV/ORquLOE=; b=xIXfeWjlRbTi0eDaWLw624L4nkZHIy4U/6ehi8k0Us0pXVD6N9zz+2axdLEWseUw+7 iDMVp8Fk3JGqjwCPSy7QYydRmtiyx0ZtSQoMxJyH7XQZkQmvDg0bktnCbox6Td5gURhW yeSfgI2Dm5noIkr3j40rgZqUsuscTP/iXvy07b1sMdl3bHMhAR35lv9oKY5oSYnxztU1 k+aTwaO6bIpGmXGUK1vtxxe07kM3hHyMdfgrpr/my904T7me26BCzcVj//PcxQfU1jx1 Qs0rAgEoihGr5k+kRxNF7BsHx6lumJsN8Uv/t1685LZ5RuB5+q+4zPN+0kvPib3OztFl zkWw== MIME-Version: 1.0 Received: by 10.182.18.165 with SMTP id x5mr4840870obd.73.1355497246803; Fri, 14 Dec 2012 07:00:46 -0800 (PST) Received: by 10.60.170.167 with HTTP; Fri, 14 Dec 2012 07:00:46 -0800 (PST) Received: by 10.60.170.167 with HTTP; Fri, 14 Dec 2012 07:00:46 -0800 (PST) In-Reply-To: <50CB3A2E.7030407@FreeBSD.org> References: <50C9B33C.9020505@FreeBSD.org> <50CB3A2E.7030407@FreeBSD.org> Date: Fri, 14 Dec 2012 17:00:46 +0200 Message-ID: Subject: Re: Reproduceable hang From: Alexander Yerenkow To: Andriy Gapon Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 15:00:47 -0000 I'm using official tools, not open ones. Will try to repeat this at saturday with openvm tools. I could place somewhere their archive. Btw, they require compat6x. Regards, Alexander Yerenkow 14.12.2012 16:39 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Andriy Gapon" =CE=C1=D0=C9=D3=C1=CC: > on 14/12/2012 14:46 Alexander Yerenkow said the following: > > Setup: ESXi 5.1.0 > > Seems this happens when vmmemctl.ko loaded (from their latest vmtools), > and when > > you give a bit more memory than there is free. > > This is weird... As I can see in os_kmem_alloc function (in > modules/freebsd/vmmemctl/os.c of /usr/ports/emulators/open-vm-tools port)= , > the > object lock is correctly acquired there. I suspect some binary > incompatibility > between the module and your kernel. Try to recompile the module again > using the > same source tree tree and the option. > > > 2012/12/13 Andriy Gapon > > > > > on 13/12/2012 12:46 Alexander Yerenkow said the following: > > > 2012/12/13 Alexander Yerenkow yerenkow@gmail.com>> > > > > > >> Hello there. > > >> I have here 100% reproduceable hangs when run one custom java > program. > > >> Can someone look into? > > >> > > >> I can give some more info (some other trace) if required. > > >> > > >> > > > > > > > > > If someone didn't get attachment - here's link to screenshot > > > > > > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl > > > > Looks like either a bug or an "out-of-sync" issue in whatever > (virtualization?) > > driver that has function OS_ReservedPageAlloc. > > -- > Andriy Gapon > From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:07:53 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33A01CB4 for ; Fri, 14 Dec 2012 15:07:53 +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 7A2598FC0C for ; Fri, 14 Dec 2012 15:07:51 +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 RAA28696; Fri, 14 Dec 2012 17:07:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50CB40C5.7010402@FreeBSD.org> Date: Fri, 14 Dec 2012 17:07:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Yerenkow Subject: Re: Reproduceable hang References: <50C9B33C.9020505@FreeBSD.org> <50CB3A2E.7030407@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 15:07:53 -0000 on 14/12/2012 17:00 Alexander Yerenkow said the following: > I'm using official tools, not open ones. Will try to repeat this at saturday with > openvm tools. > I could place somewhere their archive. Btw, they require compat6x. Using third-party binary modules with head does not always work. compat6x does not affect internal kernel interfaces. So I suggest that you stick to some stable branch and use modules compiled for that branch if you want to keep using the binary modules. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:09:00 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E581BECB; Fri, 14 Dec 2012 15:09:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCD68FC0A; Fri, 14 Dec 2012 15:09:00 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A7E3B5C5A; Fri, 14 Dec 2012 16:08:52 +0100 (CET) Message-ID: <50CB4109.2080905@FreeBSD.org> Date: Fri, 14 Dec 2012 16:08:57 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Guido Falsi Subject: Re: Request import of fix for clang 3.2 bug References: <50CB3456.3000708@madpilot.net> In-Reply-To: <50CB3456.3000708@madpilot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 15:09:01 -0000 On 2012-12-14 15:14, Guido Falsi wrote: > I have stumbled upon a solved bug in clang 3.2 while testing some ports: > > http://llvm.org/bugs/show_bug.cgi?id=14491 > > Fixed in this commit: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=169451 > > Should the fix be imported in FreeBSD?? Yes, it will come with the import of 3.2, when it is released. This should be Really Soon Now. :-) From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:57:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B20DD04 for ; Fri, 14 Dec 2012 15:57:43 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id D23788FC13 for ; Fri, 14 Dec 2012 15:57:42 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3YNGcN3yySzFTXH for ; Fri, 14 Dec 2012 16:57:40 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbfyJHSm2sGq for ; Fri, 14 Dec 2012 16:57:38 +0100 (CET) Received: from vwg82.hq.ignesti.it (unknown [80.74.176.55]) by winston.madpilot.net (Postfix) with ESMTPSA for ; Fri, 14 Dec 2012 16:57:38 +0100 (CET) Message-ID: <50CB4C73.6050501@madpilot.net> Date: Fri, 14 Dec 2012 16:57:39 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Request import of fix for clang 3.2 bug References: <50CB3456.3000708@madpilot.net> <50CB4109.2080905@FreeBSD.org> In-Reply-To: <50CB4109.2080905@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 15:57:43 -0000 On 12/14/12 16:08, Dimitry Andric wrote: > On 2012-12-14 15:14, Guido Falsi wrote: >> I have stumbled upon a solved bug in clang 3.2 while testing some ports: >> >> http://llvm.org/bugs/show_bug.cgi?id=14491 >> >> Fixed in this commit: >> >> http://llvm.org/viewvc/llvm-project?view=rev&revision=169451 >> >> Should the fix be imported in FreeBSD?? > > Yes, it will come with the import of 3.2, when it is released. This > should be Really Soon Now. :-) Thanks to all for the fast feedback. I'll quietly wait for the import. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 17:12:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE9614E9; Fri, 14 Dec 2012 17:12:28 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAC18FC12; Fri, 14 Dec 2012 17:12:28 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so1439834dad.13 for ; Fri, 14 Dec 2012 09:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=LCGUq155hfx5kD+oQlks2trRaqguBHH5WiTiLnCWufU=; b=sc27QiIq6+S1ATMqRlwLCeqoeESVE84rMKjNx/pPJC7Dx6mgh4XuFR9junng+DqTS5 0HJW0cfmwS/QCME/JzCTYd/zk7FJTYAnAsqWKMXENQiCrwyTRMM//Sq3/Ng7n+7JLp/8 hr2Q5JkxOo0EUC88Bw1ar/gR5e3c80+scOQ4ahHks6qWubDgVyCmtIzeLc42Rhy59zMj BEyTtO7YOZ3upwoOUdRjAJihZIg+TV+FVx0egAUra9K84GmWMK7iojtWfNVNxSLs3EPr Rs4VmFrmd92JPLz/VjyADOuRW5jVyxotqAKIxn2Er4QACfqP21KJR5dpo5svP84L2x8u sPjw== Received: by 10.68.241.65 with SMTP id wg1mr17535925pbc.141.1355505142738; Fri, 14 Dec 2012 09:12:22 -0800 (PST) Received: from bakeneko.local (108-213-216-134.lightspeed.sntcca.sbcglobal.net. [108.213.216.134]) by mx.google.com with ESMTPS id ov4sm3225421pbb.45.2012.12.14.09.12.20 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:12:21 -0800 (PST) Message-ID: <50CB5DEF.8030503@gmail.com> Date: Fri, 14 Dec 2012 09:12:15 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121203 Thunderbird/10.0.11 MIME-Version: 1.0 To: Ganael LAPLANCHE Subject: Re: Lenovo x220 suspend/resume broken References: <20121214124854.M44964@martymac.org> In-Reply-To: <20121214124854.M44964@martymac.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, jkim@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Dec 2012 17:12:28 -0000 On 12/14/12 04:55, Ganael LAPLANCHE wrote: > Hi everyone, > > Following this thread : > > http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032519.html > > I have finally taken time to track this regression. It occurs with > revision 231797 : > > http://svnweb.freebsd.org/base?view=revision&revision=231797 > > Could anyone have a look at it ? > > Best regards, > > -- > Ganael LAPLANCHE > http://www.martymac.org | http://contribs.martymac.org > FreeBSD: martymac , http://www.FreeBSD.org Thanks for digging for that... Perhaps revert the spinlocks to the the intr_suspend/intr_resume code and see if it has an effect? It's an uneducated guess :) Matt From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 06:14:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFF5D403 for ; Sat, 15 Dec 2012 06:14:42 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 307068FC13 for ; Sat, 15 Dec 2012 06:14:41 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so3381837lah.13 for ; Fri, 14 Dec 2012 22:14:40 -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:content-type; bh=G/1IzYbyq3R7cd5NMl9k1rHuJkXTRacqeOjBVuiZ4fQ=; b=fmIOrYb8BPWrnrPfaSNn1M8QxMsEqfhUjzpTejwOhgWCsS4SWlqv4dwjIf7cOU/PDL 27wncpS0wahOanZdCb8HGaOUrbXqtDgWg9Nr+PgSqv6hi3jFfeQzpo6qSeBxRsmzcUmV Q843YJ+tihcDXZgQDDuOhV0Q+Sq85iuoBebzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=G/1IzYbyq3R7cd5NMl9k1rHuJkXTRacqeOjBVuiZ4fQ=; b=GQUbv7WS5ok9aYk6zpxmFYCE8yRGXEGjvoZjlhlO5BfR66YcVjTd7rupN5614heD2v XhzO9MPRtijSJxEQfG6CBd4Opw3zccnj0uVAxPzKB/NbCDFjuncFPVUpDnWKWPempWAX /AdzulNIQnIUIktmJYlbkY1xZ9JeWFHOpiK+aE9Y7IQRMGqf+lGlM5uWUPHaDgPTX2p4 HQE/6cXWjDMYAS1gkvHAfKOv+z5/lmc1dwZribIKwnVkV/vtAWXxfnBqkzvvvSVIvxXV VFXYErl5CZrHpg0FPf9lwimMLTyb1R4J7eY0+cCMLkMOqzpIrv9DiocFg9S3wamMN6Td XvRg== Received: by 10.152.111.166 with SMTP id ij6mr4791026lab.47.1355552080725; Fri, 14 Dec 2012 22:14:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.149.225 with HTTP; Fri, 14 Dec 2012 22:14:10 -0800 (PST) In-Reply-To: <20121203154154.GA20011@in-addr.com> References: <20121203154154.GA20011@in-addr.com> From: Eitan Adler Date: Sat, 15 Dec 2012 01:14:10 -0500 Message-ID: Subject: Re: looking for help from ppp users To: Gary Palmer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmsJRmm4ky5zJZZsDweIBGCHOxU3DmaDBIRQ1Wqqe3Kp7VpiQgvO/ck5icetpVyu5z+VFNU Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 06:14:42 -0000 On 3 December 2012 10:41, Gary Palmer wrote: > While not commenting on the correctness of the current contents, the userland > PPP section of the FAQ appears to mostly deal with dialup modems. I suspect > more people use it now to do PPPoA or PPPoE for some form of DSL link and > there probably needs to be some effort to address the differences. I've never used PPP in any sense. Any chance I could enlist you to help write some content? I could turn it into docbook, edit it, etc. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 10:52:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C79A386; Sat, 15 Dec 2012 10:52:40 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC6398FC13; Sat, 15 Dec 2012 10:52:39 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4451911oag.13 for ; Sat, 15 Dec 2012 02:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZFke9YRlzBdmV18enKt3D8DATotVbthF0mjlZT34+H4=; b=COoSVBhpDrOJ6AZWL33kjfrRNTVqks/Un1syw2cshwBDPI9GMWsx+3KJBN5RBfOOt1 3A0dA95wh+MJlqQRQ8S41pfa6bqtDGyx+1uI4CEv39gzmImbofEjznJlo2YYJPVagJWV ZYgwMm4brw5ImuUsMbi5XyFnQ5S7J0DMMafD8pQnFqKovwXV2X5kH/iWycZVRNT2YXCW b4LxVJkwNieQNOtCFJMr5nVquazYU8uysSRcVSAF7K+nlHeUOLKT38dV5sw/0q7IYyxR 6JB8QdZ23BrSX66XTO7koARNpfad2DMCtzRId44bRnJSKJwxC1zpKmVh/MX4o2DrX3nF XkBA== MIME-Version: 1.0 Received: by 10.182.53.3 with SMTP id x3mr6972987obo.87.1355568758888; Sat, 15 Dec 2012 02:52:38 -0800 (PST) Received: by 10.76.34.227 with HTTP; Sat, 15 Dec 2012 02:52:38 -0800 (PST) In-Reply-To: <20121215183409.U1603@besplex.bde.org> References: <20121215183409.U1603@besplex.bde.org> Date: Sat, 15 Dec 2012 11:52:38 +0100 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Oliver Pinter To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 10:52:40 -0000 On 12/15/12, Bruce Evans wrote: > On Fri, 14 Dec 2012, Oliver Pinter wrote: > >> 635 - return tticks; >> 636 + getbinuptime(&pbt); >> 637 + bt.sec = data / 1000; >> 638 + bt.frac = (data % 1000) * (uint64_t)1844674407309000LL; >> 639 + bintime_add(&bt, &pbt); >> 640 + return bt; > > Style bugs: missing spaces around return value in new and old code. > >> 641 } >> >> What is this 1844674407309000LL constant? > > This is > > 2**64 / 10**6 * 10**3 > > obfuscated by printing it in hex and doing the scaling by powers of > 10 manually, and then giving it a bogus type using the abominable long > long misfeature. I try to kill this obfuscation and the abimination > whenever I see them. In sys/time.h, this resulted in a related binary > conversion using a scale factor of > > ((uint64_t)1 << 63) / (1000000000 >> 1). > > Here the power of 2 term is 2**63. 2**64 cannot be used since it exceeds > uintmax_t. The power of 10 term is 10**9. This is divided by 2 to > compensate for dividing 2**64 by 2. The abomination is avoided by using > smaller literal values and expandling them to 64-bit values using shifts. > > Long long suffixes on literal constants are only needed to support C90 > compilers with the long long extension on 32-bit systems anyway. > Otherwise, C90+extension compilers will warn about literal constants > larger than ULONG_MAX (which can only occur on 32-bit systems). Since > C99 is now the default, the warnings would only without LL in the above > if you use nonstandard CFLAGS. > > The above has to convert from the bad units of milliseconds to the bloated > units of bintimes, and it is less refined than most other bintime > conversions. I think that since it doesn't try to be optimal, it should > just use the standard bintime conversions after first converting > milliseconds to a timeval. It already does essentially that with its > divisions by 1000: > > struct timeval tv; > > tv.tv_sec = data / 1000; > tv.tv_usec = data % 1000 * 1000; > timeval2bintime(&tv, &bt); > > The compliler will probably optimize /1000 and %1000 to shifts in both > this and the above. Then timeval2bintime() does the almost the same > multiplication as above, but spelled differently accuracy. Both give > unnecessary inaccuracy in the conversion to weenieseconds: the first > gives: > > bt.frac = data % 1000 * (2**64 / 10**6 * 10**3); > > the second gives: > > bt.frac = data % 1000 * 1000 * (2**64 / 10**6); > > Because of the different grouping of the multiplications, the second > is unfortunately slower (1 more multiplication that cannot be done at > compile time). The second also gives unnecessary (but findamental to > the method) inaccuracy by pulling out the factor of 1000. The first > gives the same inaccuracy, and now it is because the constant is not > correctly rounded. It should be > > 2.0**64 / 10**3 = 1844674407309551.616 (exactly) > = 1844674407309552 (rounded to nearest int) > > but is actually rounded down to a multiple of 1000. > > It would be better to round the scale factors so that the conversions > are inverses of each other and tticks can be recovered from bt, but > this is impossible. I tried to make the bintime conversions invert > most values correctly by rounding to nearest, but phk didn't like this > and the result is the bogus comment about always rounding down in time.h. > So when you start with 999 msec in tticks, the resulting bt will be > rounded down a little and converting back will give 998 msec; the > next round of conversions will reduce 1 more, and so on until you > reach a value that is exactly representable in both milliseconds and > weenieseconds (875?). This despite weenieseconds providing vastly > more accuracy than can be measured and vastly more accuracy than needed > to represent all other time values in the kernel in a unique way. Just > not in a unique way that is expressible using simple scaling conversions. > The conversions that give uniqueness can still be monotonic, but can't > be nonlinear in the same way that simple scaling gives. Thanks for the detailed answer. :) > > Bruce > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 08:44:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F33C81C5; Sat, 15 Dec 2012 08:44:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED5C8FC0A; Sat, 15 Dec 2012 08:44:52 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBF8ig3G022984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 19:44:43 +1100 Date: Sat, 15 Dec 2012 19:44:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oliver Pinter Subject: Re: [RFC/RFT] calloutng In-Reply-To: Message-ID: <20121215183409.U1603@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=fev1UDsF c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=w_hYTCC3XhR2lAYixAoA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Sat, 15 Dec 2012 12:27:08 +0000 Cc: Davide Italiano , freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 08:44:53 -0000 On Fri, 14 Dec 2012, Oliver Pinter wrote: > 635 - return tticks; > 636 + getbinuptime(&pbt); > 637 + bt.sec = data / 1000; > 638 + bt.frac = (data % 1000) * (uint64_t)1844674407309000LL; > 639 + bintime_add(&bt, &pbt); > 640 + return bt; Style bugs: missing spaces around return value in new and old code. > 641 } > > What is this 1844674407309000LL constant? This is 2**64 / 10**6 * 10**3 obfuscated by printing it in hex and doing the scaling by powers of 10 manually, and then giving it a bogus type using the abominable long long misfeature. I try to kill this obfuscation and the abimination whenever I see them. In sys/time.h, this resulted in a related binary conversion using a scale factor of ((uint64_t)1 << 63) / (1000000000 >> 1). Here the power of 2 term is 2**63. 2**64 cannot be used since it exceeds uintmax_t. The power of 10 term is 10**9. This is divided by 2 to compensate for dividing 2**64 by 2. The abomination is avoided by using smaller literal values and expandling them to 64-bit values using shifts. Long long suffixes on literal constants are only needed to support C90 compilers with the long long extension on 32-bit systems anyway. Otherwise, C90+extension compilers will warn about literal constants larger than ULONG_MAX (which can only occur on 32-bit systems). Since C99 is now the default, the warnings would only without LL in the above if you use nonstandard CFLAGS. The above has to convert from the bad units of milliseconds to the bloated units of bintimes, and it is less refined than most other bintime conversions. I think that since it doesn't try to be optimal, it should just use the standard bintime conversions after first converting milliseconds to a timeval. It already does essentially that with its divisions by 1000: struct timeval tv; tv.tv_sec = data / 1000; tv.tv_usec = data % 1000 * 1000; timeval2bintime(&tv, &bt); The compliler will probably optimize /1000 and %1000 to shifts in both this and the above. Then timeval2bintime() does the almost the same multiplication as above, but spelled differently accuracy. Both give unnecessary inaccuracy in the conversion to weenieseconds: the first gives: bt.frac = data % 1000 * (2**64 / 10**6 * 10**3); the second gives: bt.frac = data % 1000 * 1000 * (2**64 / 10**6); Because of the different grouping of the multiplications, the second is unfortunately slower (1 more multiplication that cannot be done at compile time). The second also gives unnecessary (but findamental to the method) inaccuracy by pulling out the factor of 1000. The first gives the same inaccuracy, and now it is because the constant is not correctly rounded. It should be 2.0**64 / 10**3 = 1844674407309551.616 (exactly) = 1844674407309552 (rounded to nearest int) but is actually rounded down to a multiple of 1000. It would be better to round the scale factors so that the conversions are inverses of each other and tticks can be recovered from bt, but this is impossible. I tried to make the bintime conversions invert most values correctly by rounding to nearest, but phk didn't like this and the result is the bogus comment about always rounding down in time.h. So when you start with 999 msec in tticks, the resulting bt will be rounded down a little and converting back will give 998 msec; the next round of conversions will reduce 1 more, and so on until you reach a value that is exactly representable in both milliseconds and weenieseconds (875?). This despite weenieseconds providing vastly more accuracy than can be measured and vastly more accuracy than needed to represent all other time values in the kernel in a unique way. Just not in a unique way that is expressible using simple scaling conversions. The conversions that give uniqueness can still be monotonic, but can't be nonlinear in the same way that simple scaling gives. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 09:01:16 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A542588; Sat, 15 Dec 2012 09:01:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8D23C8FC12; Sat, 15 Dec 2012 09:01:14 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBF915ck029165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 20:01:06 +1100 Date: Sat, 15 Dec 2012 20:01:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans Subject: Re: [RFC/RFT] calloutng In-Reply-To: <20121215183409.U1603@besplex.bde.org> Message-ID: <20121215194819.C1778@besplex.bde.org> References: <20121215183409.U1603@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=e5de0tV/ c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=fliXX_qwswpPfyGDAOYA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Sat, 15 Dec 2012 12:27:43 +0000 Cc: Davide Italiano , freebsd-arch@FreeBSD.org, freebsd-current , Oliver Pinter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 09:01:16 -0000 On Sat, 15 Dec 2012, Bruce Evans wrote: > On Fri, 14 Dec 2012, Oliver Pinter wrote: >> >> What is this 1844674407309000LL constant? > > This is > > 2**64 / 10**6 * 10**3 > > obfuscated by printing it in hex and doing the scaling by powers of > 10 manually, and then giving it a bogus type using the abominable long > long misfeature. I try to kill this obfuscation and the abimination > whenever I see them. In sys/time.h, this resulted in a related binary > conversion using a scale factor of > > ((uint64_t)1 << 63) / (1000000000 >> 1). > > Here the power of 2 term is 2**63. 2**64 cannot be used since it exceeds > uintmax_t. The power of 10 term is 10**9. This is divided by 2 to > compensate for dividing 2**64 by 2. The abomination is avoided by using > smaller literal values and expandling them to 64-bit values using shifts. Bah, this is only de-obfuscated and de-abominated in my version: % Index: time.h % =================================================================== % RCS file: /home/ncvs/src/sys/sys/time.h,v % retrieving revision 1.65 % diff -u -2 -r1.65 time.h % --- time.h 7 Apr 2004 04:19:49 -0000 1.65 % +++ time.h 7 Apr 2004 11:28:54 -0000 % @@ -118,6 +118,5 @@ % % bt->sec = ts->tv_sec; % - /* 18446744073 = int(2^64 / 1000000000) */ % - bt->frac = ts->tv_nsec * (uint64_t)18446744073LL; % + bt->frac = ts->tv_nsec * (((uint64_t)1 << 63) / (1000000000 >> 1)); % } % The magic 1844... in time.h is at least commented on. This makes it less obscure, but takes twice as many source lines and risks the comment getting out of date with the code. The comment is also sloppy with types and uses the '^' operator without saying that it is exponentiation and nothing like the C '^' operator. The types are especially critical in the shift exprression. I like to use the Fortran '**' operator in C comments without saying what it is instead. In another reply to this thread, the value in the explanation is off by a factor of 1000 and the rounding to a multiple of 1000 is not explained. It is easy to have such errors in comments, while the code tends to be more correct since it gets checked by running it. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 11:24:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86E44C0D; Sat, 15 Dec 2012 11:24:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 142DB8FC0A; Sat, 15 Dec 2012 11:24:53 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBFBOnEA019642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 22:24:51 +1100 Date: Sat, 15 Dec 2012 22:24:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oliver Pinter Subject: Re: [RFC/RFT] calloutng In-Reply-To: Message-ID: <20121215222156.H2309@besplex.bde.org> References: <20121215183409.U1603@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zvi1sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=NQ0KR7aI5Mbd9Gopmc4A:9 a=CjuIK1q_8ugA:10 a=oZ2IPoelaH8A:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Sat, 15 Dec 2012 12:28:24 +0000 Cc: Davide Italiano , freebsd-current , Bruce Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 11:24:54 -0000 On Sat, 15 Dec 2012, Oliver Pinter wrote: > On 12/15/12, Bruce Evans wrote: >> ... >> Because of the different grouping of the multiplications, the second >> is unfortunately slower (1 more multiplication that cannot be done at >> compile time). The second also gives unnecessary (but findamental to >> the method) inaccuracy by pulling out the factor of 1000. The first >> gives the same inaccuracy, and now it is because the constant is not >> correctly rounded. It should be >> >> 2.0**64 / 10**3 = 1844674407309551.616 (exactly) >> = 1844674407309552 (rounded to nearest int) >> >> but is actually rounded down to a multiple of 1000. >> ... mav@ already fixed the rounding before I wrote that :-). He also changed some (uint64_t)1's to use the long long abomination :-(. > Thanks for the detailed answer. :) Bruce From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 13:22:49 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 717E5F7A; Sat, 15 Dec 2012 13:22:49 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E9F158FC0A; Sat, 15 Dec 2012 13:22:48 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBFDMlR9077003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 14:22:47 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sat, 15 Dec 2012 14:22:46 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: developers@FreeBSD.org, current@FreeBSD.org, hackers@FreeBSD.org Subject: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20121215132246.GH69724@acme.spoerlein.net> Mail-Followup-To: developers@FreeBSD.org, current@FreeBSD.org, hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M/SuVGWktc5uNpra" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: current@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: Sat, 15 Dec 2012 13:22:49 -0000 --M/SuVGWktc5uNpra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Bad news everyone, tl;dr The git mirror of the source repository needs to be re-rolled to make the conversion deterministically repeatable, this will change pretty much all git commit hashes. The re-roll will be done January 15, 2013. Not affected are the ports and doc repositories, nor is the svn_head (for use with git-svn) affected. Background The converter (svn2git) was handing commits and objects to git's fast-import in arbitrary order, this makes merge commits have an arbitrary order of their parent commits and thus these merge commits have changing commit hashes for each converter run. This has been fixed, but requires us to move all the branches over to this deterministic scheme, which will change all their commit hashes. None of the contents of these commits change, so rebasing/remerging your work into these branches is possible without running into any merge conflicts. We need your help A goal of these conversions is to have them repeatable by you (yes, you!), so the correctness of the conversion can be verified. There are also no backups of the conversion runs, as they should be repeatable anyway. We need 2-3 volunteers to run these conversions themselves and verify that the produced commit hashes match the published ones. The necessary steps to do this are documented on the Wiki under http://wiki.freebsd.org/GitWorkflow#History Please send me your output of git show-ref in a private mail, thanks. Cheers, Uli PS: This re-roll has nothing to do with the recent security incident. --M/SuVGWktc5uNpra Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQEcBAEBAgAGBQJQzHmmAAoJEKOmmGRKr4LOvoIH/35PTmdC/afsPmOpcaLNYFuN UsS6fmQwYYrw/qNe1x9mCyjrEAigZz/QzMeyc1lxBtgC74LxehMPOc6FcVywHzah 3nU5uNyTl4LS0CLVVaL26N77AKjbsGiO4eX9h/gC4NnlpTnEpntkgg087FAtnDkc 76kMR6n9Yy5zBmmZhBncqGA/O/LEjkuNadBH2+3sd4vMtHebalyxtNCCoTGUjpYk IFrm/flC1GHptgtXqASgXrrh1ky1Beqr5hKWn7i4N8i9/5tclSwGlkZ6Z4hU5cCN Wy3o57yFSU4WDzeZmsj5nEyfXuT3ZOiEHoWpcp/77QB9UH+L5g8MRQrLOQj73qM= =Fvzq -----END PGP SIGNATURE----- --M/SuVGWktc5uNpra-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 14:47:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B367B5F3; Sat, 15 Dec 2012 14:47:19 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 134D98FC17; Sat, 15 Dec 2012 14:47:18 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1086697wib.13 for ; Sat, 15 Dec 2012 06:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:subject:references:date:cc:to:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=5ZAZ/Bxh4fEw8OgAOWtabfXTrOYuzy5m15kjCABVhw4=; b=PACxKRN9+n7T1nUe4O6VuW5/Iy966S0Vpa4EBw2OgZTNnNmwsXXSPqo0HLMi8n4KLh liu5nmfZvbFMBXvur7djg1T4gmuBKmLPsV448/yqCBU3ftHXljZxUrLTC2WeXC9oLETX +R6X4Zk16HvVyOhOmdTvY1q0PK0DheERjYwOIFsXQmpO7WQ1fwMermamzBhrcg8jR21S v9hepvE8HyNyjo/Mz978hN+xedGq42xyK6q1LzugtUZmDZcQaI0xd4td9ci1v7v6zqfr +vhFNU8uJPVBMmmdZJCotppeoiqR8Uw7dXP4sraFDYaPnMXZBuWDKQFjoYUv8HDbg/0X kT+g== Received: by 10.194.174.196 with SMTP id bu4mr8743063wjc.35.1355582838061; Sat, 15 Dec 2012 06:47:18 -0800 (PST) Received: from box.lan1.daemonrage.net ([31.110.72.236]) by mx.google.com with ESMTPS id i6sm2414430wix.5.2012.12.15.06.47.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 06:47:17 -0800 (PST) Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Subject: Re: looking for help from ppp users References: <20121203154154.GA20011@in-addr.com> Date: Sat, 15 Dec 2012 14:47:12 -0000 To: gpalmer@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Paul Webster" Organization: Interflective Group Message-ID: In-Reply-To: User-Agent: Opera Mail/12.11 (Win64) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 14:47:19 -0000 Hey there gary, this works for talktalk/UK ADSL modem in PPPoE mode, or did beore my house move ill double cobnfirm in 6 days when my new line is active. #talktalk: set reconnect 999 1 set device PPPoE:xl0 # replace xl1 with your Ethernet device set authname my-house-phone-number@talktalk.net set authkey myAdsl password set dial set login add default HISADDR set speed sync set mru 1492 set mtu 1492 set ctsrts off enable echo set echoperiod 15 enable lqr set lqrperiod 15 enable ipcp disable ipv6cp disable dns set server /tmp/pppoe-adsl0 .. 0177 add! default HISADDR add! default HISADDR6 On Sat, 15 Dec 2012 06:14:10 -0000, Eitan Adler wrote: > On 3 December 2012 10:41, Gary Palmer wrote: >> While not commenting on the correctness of the current contents, the >> userland >> PPP section of the FAQ appears to mostly deal with dialup modems. I >> suspect >> more people use it now to do PPPoA or PPPoE for some form of DSL link >> and >> there probably needs to be some effort to address the differences. > > I've never used PPP in any sense. Any chance I could enlist you to > help write some content? I could turn it into docbook, edit it, etc. > > > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:04:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B7669BF; Sat, 15 Dec 2012 16:04:45 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 71A348FC14; Sat, 15 Dec 2012 16:04:45 +0000 (UTC) Received: from [10.0.10.3] ([173.88.197.103]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 15 Dec 2012 08:03:42 -0800 Message-ID: <50CC9F5E.6080102@a1poweruser.com> Date: Sat, 15 Dec 2012 11:03:42 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Adrian Chadd Subject: Re: AR9285 not see n-channels References: <50c92508.6384440a.1379.3a4a@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2012 16:03:42.0340 (UTC) FILETIME=[C0F32440:01CDDADD] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: Andrey Fesenko , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 16:04:45 -0000 > Adrian > > On 12 December 2012 17:39, Andrey Fesenko wrote: >> On Thu, Dec 13, 2012 at 5:33 AM, Adrian Chadd wrote: >>> Hi, >>> >>> The AR9285 is a 2GHz only NIC. >>> >>> The channel list shows 11b, 11bg, HT20 and HT40 channels. >>> >>> It all looks right, why don't you think it is? >>> >>> >>> Adrian >>> >>> >>> On 12 December 2012 17:32, Andrey Fesenko wrote: >>>> On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: >>>>> .. yup, you're doing 11n! Welcome! >>>>> >>>>> >>>>> >>>>> Adrian >>>>> >>>>> On 12 December 2012 16:54, Andrey Fesenko wrote: >>>>>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: >>>>>>> Yup. It's doing 11n rates. >>>>>>> >>>>>>> Compile and run athstats, it'll tell you how many aggregate frames are being >>>>>>> sent and received. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> Sent from my Palm Pre on AT&T >>>>>>> >>>>>>> ________________________________ >>>>>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>>>>>> >>>>>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: >>>>>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> adrian >>>>>>>> >>>>>>>> >>>>>>>> On 12 December 2012 15:51, Andrey Fesenko wrote: >>>>>>>>> I have >>>>>>>>> # uname -a >>>>>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 >>>>>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>>>>>> options ATH_ENABLE_11N >>>>>>>>> options ATH_DEBUG >>>>>>>>> options ATH_DIAGAPI >>>>>>>>> >>>>>>>>> pciconf >>>>>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>>>>>> rev=0x01 hdr=0x00 >>>>>>>>> vendor = 'Atheros Communications Inc.' >>>>>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>>>>>> class = network >>>>>>>>> >>>>>>>>> >>>>>>>>> # ifconfig -v wlan0 list channel >>>>>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>>>>>> .... >>>>>>>>> >>>>>>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>>>>>> How to turn on or activate n-mode? >>>>>>> # ifconfig wlan0 list sta >>>>>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>>>>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>>>>>> RSN HTCAP WME WPS >>>>>>> # ifconfig wlan0 >>>>>>> wlan0: flags=8843 metric 0 mtu 1500 >>>>>>> ether 4c:0f:6e:4b:4e:f5 >>>>>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>>>>>> nd6 options=29 >>>>>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>>>>>> status: associated >>>>>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 >>>>>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>>>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 >>>>>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>>>>>> burst roaming MANUAL >>>>>> # ./athstats >>>>>> 526213 data frames received >>>>>> 10205 data frames transmit >>>>>> 79 short on-chip tx retries >>>>>> 103 long on-chip tx retries >>>>>> 16 tx failed 'cuz too many retries >>>>>> 220 mib overflow interrupts >>>>>> MCS7 current transmit rate >>>>>> 1 watchdog timeouts >>>>>> 42 beacon miss interrupts >>>>>> 23154 rx failed 'cuz of bad CRC >>>>>> 56 rx failed 'cuz of PHY err >>>>>> 56 illegal service >>>>>> 1638 periodic calibrations >>>>>> -0/+0 TDMA slot adjust (usecs, smoothed) >>>>>> 56 rssi of last ack >>>>>> 50 avg recv rssi >>>>>> -96 rx noise floor >>>>>> 13 phantom beacon misses >>>>>> 6569 tx frames through raw api >>>>>> 1460 A-MPDU sub-frames received >>>>>> 183 Half-GI frames received >>>>>> 183 40MHz frames received >>>>>> 2397 CRC errors for non-last A-MPDU subframes >>>>>> 3151 Frames transmitted with HT Protection >>>>>> 25 A-MPDU sub-frame TX attempt success >>>>>> 2 first step level >>>>>> 1 OFDM weak signal detect >>>>>> 268 listen time >>>>>> 190 ANI increased spur immunity >>>>>> 174 ANI decrease spur immunity >>>>>> 2 ANI enabled OFDM weak signal detect >>>>>> 3517 ANI disabled OFDM weak signal detect >>>>>> 3515 ANI disabled CCK weak signal threshold >>>>>> 4 ANI increased first step level >>>>>> 2 ANI decreased first step level >>>>>> 154772 cumulative OFDM phy error count >>>>>> 528256 cumulative CCK phy error count >>>>>> 851 ANI forced listen time to zero >>>>>> 26 missing ACK's >>>>>> 78 RTS without CTS >>>>>> 3135 successful RTS >>>>>> 65747 bad FCS >>>>>> 473007 beacons received >>>>>> 53 average rssi (beacons only) >>>>>> 35 average rssi (all rx'd frames) >>>>>> 48 average rssi (ACKs only) >>>>>> Antenna profile: >>>>>> [0] tx 10173 rx 4 >>>>>> [1] tx 0 rx 526209 >>>>>> >>>>>> >>>>>> # ./athaggrstats >>>>>> 17 single frames scheduled >>>>>> 9 aggregate frames scheduled >>>>>> 1217 single frames scheduled due to low HWQ depth >>>>>> >>>>>> Aggregate size profile: >>>>>> >>>>>> 0: 0 1: 0 2: 6 3: 2 >>>>>> 4: 0 5: 0 6: 0 7: 1 >>>>>> 8: 0 9: 0 10: 0 11: 0 >>>> why # ifconfig -v wlan0 list channel >>>> show only b and g channels? and only 13? or this restriction AR9285 >>>> >>>> though >>>> # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K >>>> ------------------------------------------------------------ >>>> Client connecting to 192.168.1.26, TCP port 5001 >>>> TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) >>>> ------------------------------------------------------------ >>>> [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 >>>> [ ID] Interval Transfer Bandwidth >>>> [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec >> Thanks >> >> I was confused that there is no mention n-mode in the output channel list > Adrian Chadd wrote: > Right, that's what "HT" is for. > > Well it would be much clearer to understand by changing the output of the the channel list to show 11b, 11bg, 11n20 and 11n40 channels instead of HT20 and HT40, so people would readily know n-mode was active. HT has no meaning to the general user. From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:11:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5654ED71; Sat, 15 Dec 2012 16:11:21 +0000 (UTC) (envelope-from utisoft@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 8227E8FC19; Sat, 15 Dec 2012 16:11:19 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so2107974bkc.13 for ; Sat, 15 Dec 2012 08:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=4uSl/hUB7zoqq6Vv5ApRV0QfFU8/WS1FBps7OoIOQaA=; b=bxGGzifDJrh0ds/mNq+/6q2JpL9xaMcU06uiuKOOcXY8uu8JJ7J/zfdZDokw+tlNF1 fykk1/xECsqP1hs0erXSylkxPGWmqVNQwnTSvcJOihphtDZ6W3E8YwNA8fDLCJQ0fY65 WXZZGPERh6ZSHa0zvHIZM7m23CWi6gstGIDiU2IxD8PL1gagZ8xINQJ8364IP8s9zUvn ZNDQ2yEvFJNAWcHs/WbCLvC2FLMK0b/WXMRGnb4pFmqzSzDRfBqsA/EnWwM6R0NyHqbd o8WoZZ/JwO1l4Ke5W4d6WvXUVHi5Lev1kHAqK9f+bri0I91/fk8mK9VV9oMulQj/bWnY kvQQ== Received: by 10.204.149.143 with SMTP id t15mr4154624bkv.45.1355587876351; Sat, 15 Dec 2012 08:11:16 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.167.71 with HTTP; Sat, 15 Dec 2012 08:10:46 -0800 (PST) In-Reply-To: <20121215132246.GH69724@acme.spoerlein.net> References: <20121215132246.GH69724@acme.spoerlein.net> From: Chris Rees Date: Sat, 15 Dec 2012 16:10:46 +0000 X-Google-Sender-Auth: BSv-TxjQAhpEz0EszjFWaPPrruw Message-ID: Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help To: "current@freebsd.org" , FreeBSD developers , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 16:11:21 -0000 On 15 December 2012 13:22, Ulrich Sp=F6rlein wrote: > Bad news everyone, > > tl;dr The git mirror of the source repository needs to be re-rolled to > make the conversion deterministically repeatable, this will change > pretty much all git commit hashes. > > The re-roll will be done January 15, 2013. > > Not affected are the ports and doc repositories, nor is the svn_head > (for use with git-svn) affected. > > > Background > > The converter (svn2git) was handing commits and objects to git's > fast-import in arbitrary order, this makes merge commits have an > arbitrary order of their parent commits and thus these merge commits > have changing commit hashes for each converter run. > > This has been fixed, but requires us to move all the branches over to > this deterministic scheme, which will change all their commit hashes. > None of the contents of these commits change, so rebasing/remerging your > work into these branches is possible without running into any merge > conflicts. > > > We need your help > > A goal of these conversions is to have them repeatable by you (yes, > you!), so the correctness of the conversion can be verified. There are > also no backups of the conversion runs, as they should be repeatable > anyway. > > We need 2-3 volunteers to run these conversions themselves and verify > that the produced commit hashes match the published ones. The necessary > steps to do this are documented on the Wiki under > > http://wiki.freebsd.org/GitWorkflow#History > > Please send me your output of git show-ref in a private mail, thanks. Hey, http://www.bayofrum.net/~crees/scratch/git-show-ref.txt I hope it's what you were hoping for :) My local svn mirror is synchronised at midnight GMT (UTC). Need anything else? Chris From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:32:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A4EE610; Sat, 15 Dec 2012 16:32:23 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id EBCF28FC12; Sat, 15 Dec 2012 16:32:22 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tjueo-0008eh-Da; Sat, 15 Dec 2012 11:32:10 -0500 Date: Sat, 15 Dec 2012 11:32:10 -0500 From: Gary Palmer To: Fbsd8 Subject: Re: AR9285 not see n-channels Message-ID: <20121215163210.GD20011@in-addr.com> References: <50c92508.6384440a.1379.3a4a@mx.google.com> <50CC9F5E.6080102@a1poweruser.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CC9F5E.6080102@a1poweruser.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Adrian Chadd , Andrey Fesenko , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 16:32:23 -0000 On Sat, Dec 15, 2012 at 11:03:42AM -0500, Fbsd8 wrote: > > > Adrian > > > > On 12 December 2012 17:39, Andrey Fesenko wrote: > >> On Thu, Dec 13, 2012 at 5:33 AM, Adrian Chadd wrote: > >>> Hi, > >>> > >>> The AR9285 is a 2GHz only NIC. > >>> > >>> The channel list shows 11b, 11bg, HT20 and HT40 channels. > >>> > >>> It all looks right, why don't you think it is? > >>> > >>> > >>> Adrian > >>> > >>> > >>> On 12 December 2012 17:32, Andrey Fesenko wrote: > >>>> On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd wrote: > >>>>> .. yup, you're doing 11n! Welcome! > >>>>> > >>>>> > >>>>> > >>>>> Adrian > >>>>> > >>>>> On 12 December 2012 16:54, Andrey Fesenko wrote: > >>>>>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd wrote: > >>>>>>> Yup. It's doing 11n rates. > >>>>>>> > >>>>>>> Compile and run athstats, it'll tell you how many aggregate frames are being > >>>>>>> sent and received. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Adrian > >>>>>>> > >>>>>>> Sent from my Palm Pre on AT&T > >>>>>>> > >>>>>>> ________________________________ > >>>>>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: > >>>>>>> > >>>>>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd wrote: > >>>>>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> adrian > >>>>>>>> > >>>>>>>> > >>>>>>>> On 12 December 2012 15:51, Andrey Fesenko wrote: > >>>>>>>>> I have > >>>>>>>>> # uname -a > >>>>>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 > >>>>>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 > >>>>>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 > >>>>>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK > >>>>>>>>> options ATH_ENABLE_11N > >>>>>>>>> options ATH_DEBUG > >>>>>>>>> options ATH_DIAGAPI > >>>>>>>>> > >>>>>>>>> pciconf > >>>>>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c > >>>>>>>>> rev=0x01 hdr=0x00 > >>>>>>>>> vendor = 'Atheros Communications Inc.' > >>>>>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' > >>>>>>>>> class = network > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> # ifconfig -v wlan0 list channel > >>>>>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 > >>>>>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b > >>>>>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g > >>>>>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 > >>>>>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b > >>>>>>>>> .... > >>>>>>>>> > >>>>>>>>> wi-fi router have and enable n-mode (linksys e4200) > >>>>>>>>> How to turn on or activate n-mode? > >>>>>>> # ifconfig wlan0 list sta > >>>>>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > >>>>>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS > >>>>>>> RSN HTCAP WME WPS > >>>>>>> # ifconfig wlan0 > >>>>>>> wlan0: flags=8843 metric 0 mtu 1500 > >>>>>>> ether 4c:0f:6e:4b:4e:f5 > >>>>>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 > >>>>>>> nd6 options=29 > >>>>>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > >>>>>>> status: associated > >>>>>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid 58:6d:8f:fa:d9:50 > >>>>>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON > >>>>>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7 > >>>>>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme > >>>>>>> burst roaming MANUAL > >>>>>> # ./athstats > >>>>>> 526213 data frames received > >>>>>> 10205 data frames transmit > >>>>>> 79 short on-chip tx retries > >>>>>> 103 long on-chip tx retries > >>>>>> 16 tx failed 'cuz too many retries > >>>>>> 220 mib overflow interrupts > >>>>>> MCS7 current transmit rate > >>>>>> 1 watchdog timeouts > >>>>>> 42 beacon miss interrupts > >>>>>> 23154 rx failed 'cuz of bad CRC > >>>>>> 56 rx failed 'cuz of PHY err > >>>>>> 56 illegal service > >>>>>> 1638 periodic calibrations > >>>>>> -0/+0 TDMA slot adjust (usecs, smoothed) > >>>>>> 56 rssi of last ack > >>>>>> 50 avg recv rssi > >>>>>> -96 rx noise floor > >>>>>> 13 phantom beacon misses > >>>>>> 6569 tx frames through raw api > >>>>>> 1460 A-MPDU sub-frames received > >>>>>> 183 Half-GI frames received > >>>>>> 183 40MHz frames received > >>>>>> 2397 CRC errors for non-last A-MPDU subframes > >>>>>> 3151 Frames transmitted with HT Protection > >>>>>> 25 A-MPDU sub-frame TX attempt success > >>>>>> 2 first step level > >>>>>> 1 OFDM weak signal detect > >>>>>> 268 listen time > >>>>>> 190 ANI increased spur immunity > >>>>>> 174 ANI decrease spur immunity > >>>>>> 2 ANI enabled OFDM weak signal detect > >>>>>> 3517 ANI disabled OFDM weak signal detect > >>>>>> 3515 ANI disabled CCK weak signal threshold > >>>>>> 4 ANI increased first step level > >>>>>> 2 ANI decreased first step level > >>>>>> 154772 cumulative OFDM phy error count > >>>>>> 528256 cumulative CCK phy error count > >>>>>> 851 ANI forced listen time to zero > >>>>>> 26 missing ACK's > >>>>>> 78 RTS without CTS > >>>>>> 3135 successful RTS > >>>>>> 65747 bad FCS > >>>>>> 473007 beacons received > >>>>>> 53 average rssi (beacons only) > >>>>>> 35 average rssi (all rx'd frames) > >>>>>> 48 average rssi (ACKs only) > >>>>>> Antenna profile: > >>>>>> [0] tx 10173 rx 4 > >>>>>> [1] tx 0 rx 526209 > >>>>>> > >>>>>> > >>>>>> # ./athaggrstats > >>>>>> 17 single frames scheduled > >>>>>> 9 aggregate frames scheduled > >>>>>> 1217 single frames scheduled due to low HWQ depth > >>>>>> > >>>>>> Aggregate size profile: > >>>>>> > >>>>>> 0: 0 1: 0 2: 6 3: 2 > >>>>>> 4: 0 5: 0 6: 0 7: 1 > >>>>>> 8: 0 9: 0 10: 0 11: 0 > >>>> why # ifconfig -v wlan0 list channel > >>>> show only b and g channels? and only 13? or this restriction AR9285 > >>>> > >>>> though > >>>> # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K > >>>> ------------------------------------------------------------ > >>>> Client connecting to 192.168.1.26, TCP port 5001 > >>>> TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) > >>>> ------------------------------------------------------------ > >>>> [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port 5001 > >>>> [ ID] Interval Transfer Bandwidth > >>>> [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec > >> Thanks > >> > >> I was confused that there is no mention n-mode in the output channel list > > > Adrian Chadd wrote: > > Right, that's what "HT" is for. > > > > > > Well it would be much clearer to understand by changing the output of > the the channel list to show 11b, 11bg, 11n20 and 11n40 channels instead > of HT20 and HT40, so people would readily know n-mode was active. HT has > no meaning to the general user. Did you check 'man ifconfig'? The meaning of HT is clearly documented. I agree that the output could be made clearer, however a very quick glance at the man page showed what HT meant in this context. Gary From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:55:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94BE0B43; Sat, 15 Dec 2012 16:55:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id C63868FC12; Sat, 15 Dec 2012 16:55:57 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so1892022wgh.31 for ; Sat, 15 Dec 2012 08:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=eoauxAZqa62RhIFNayvyKCrYwtGy06dZzfaaGxohpwM=; b=NRZVmX0JUw8fnTMsl8B3ofM4BBz4tyWl6sJv8DzcGtAmYGHF5ic+yOkLLvx/or3rUE b3Bn7lt3J3ZsJZTTWheUyQeW6XJWi43Jretz/XLj68I79EU+D5A+6/p3YpxZkDe8cfrJ PecX3se7d5G5KJB+CZdnnkk41B9UhNEpaRZdm0XgyTSRULHVKtyxTpkdnjBMAthOWF9Q wVWAPQueyU0wSHKdN41Q74XPNb39cECbDWrcQJ8OyP/rTP4lywp+MheWJF16aIeu2ILP boVFaBNmNs2kkBvebAVUWQGtljQMNE+8ITc7Fx0NJhrmJ6pVUKd0hImsWa7OqQL37Vyf IaNA== Received: by 10.181.13.75 with SMTP id ew11mr8133537wid.9.1355590556876; Sat, 15 Dec 2012 08:55:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id t17sm3281287wiv.6.2012.12.15.08.55.54 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 08:55:56 -0800 (PST) Sender: Alexander Motin Message-ID: <50CCAB99.4040308@FreeBSD.org> Date: Sat, 15 Dec 2012 18:55:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: [RFC/RFT] calloutng Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 16:55:58 -0000 Hi. I'm sorry to interrupt review, but as usual good ideas came during the final testing, causing another round. :) Here is updated patch for HEAD, that includes several new changes: http://people.freebsd.org/~mav/calloutng_12_15.patch The new changes are: -- Precision and event aggregation code was reworked. Instead of previous -prec/+prec representation, precision is now single-sided -- -0/+prec. It allowed to significantly improve precision on long time intervals for APIs which imply that event should not happen before the specified time. Depending on CPU activity, mistake for long time intervals now will never be more then 1-500ms, even if specified precision allows more. -- Some minor optimizations were made to reduce callout overhead and latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer and TSC timecounter usleep(1) call from user-level executes in just 5-6us, instead of 7-8us before. Now it can do 180K cycles per second on single CPU with only partial CPU load. -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, setrlimit) were modified to reduce number of interrupts, also with event aggregation by explicit specification of the acceptable events precision. Now my Core2Duo test system has only 30 interrupts per second in idle. If not remaining syscons events, it could easily be 15. My IvyBridge ultrabook first time in its history shown 5.5 hours of battery time with full screen brightness and 10 hours with lid closed. -- Some kernel functions were added to make KPIs more complete. I've successfully tested this patch on amd64 and arm. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:05:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2C21256; Sat, 15 Dec 2012 18:05:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id E3A8F8FC12; Sat, 15 Dec 2012 18:05:36 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1151423wib.13 for ; Sat, 15 Dec 2012 10:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yI89ZhXmodb2CDrycrx11CGIJo58aoQ0396euQN7jd4=; b=Zrrej/HM2rPuyEwwvqhf1igRhK60nQSuJ/DPvErHN8krQkaDUiA0cznkFYtdGrx9t6 C1Mm3mx66Rz4otinllUioCLAWN5hwrmnonFpn0J6JeS2p+ZwSvJRGFYAxyIhMY6saPPQ lA8KzTJlA76WJ91YFJYKI1ptnIB7RpaBPsqErq4lfZX43b98yOUj/LvgoTtPrjHxyWLN XvJtoiqpx79hgFO4C21wbPjvyzA4K5Yqo1hryCxw8ddGQiOwjc9EGombsjqKqzEODqMe v9J3zIC/Q1NMHhPeVYh6bRA+6BBaJRp4M/5CN9jv2KqgoG/tzs7kjXzxXRdyRCoIrcd7 PIJg== MIME-Version: 1.0 Received: by 10.180.24.4 with SMTP id q4mr8289579wif.19.1355594735846; Sat, 15 Dec 2012 10:05:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 15 Dec 2012 10:05:35 -0800 (PST) In-Reply-To: <50CCAB99.4040308@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> Date: Sat, 15 Dec 2012 10:05:35 -0800 X-Google-Sender-Auth: cbYU2j5_y0TgoBYMR87_RQx4cRI Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 18:05:38 -0000 Hi, Can you please test with MIPS? David has a MIPS board now. Can you also test that various performance tests haven't been affected? Eg, do iperf tests through that MIPS board, configured up as an AP. Please test with a bunch of disk IO activity too. I know this is a lot to ask for, but I'd hate to see some driver / subsystem behaviour change because you didn't quite see the evil way the callout mechanism is used, or how the timer stuff is affecting driver pre-emption. Thanks, Adrian On 15 December 2012 08:55, Alexander Motin wrote: > Hi. > > I'm sorry to interrupt review, but as usual good ideas came during the final > testing, causing another round. :) Here is updated patch for HEAD, that > includes several new changes: > http://people.freebsd.org/~mav/calloutng_12_15.patch > > The new changes are: > -- Precision and event aggregation code was reworked. Instead of previous > -prec/+prec representation, precision is now single-sided -- -0/+prec. It > allowed to significantly improve precision on long time intervals for APIs > which imply that event should not happen before the specified time. > Depending on CPU activity, mistake for long time intervals now will never be > more then 1-500ms, even if specified precision allows more. > -- Some minor optimizations were made to reduce callout overhead and > latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer and > TSC timecounter usleep(1) call from user-level executes in just 5-6us, > instead of 7-8us before. Now it can do 180K cycles per second on single CPU > with only partial CPU load. > -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, > setrlimit) were modified to reduce number of interrupts, also with event > aggregation by explicit specification of the acceptable events precision. > Now my Core2Duo test system has only 30 interrupts per second in idle. If > not remaining syscons events, it could easily be 15. My IvyBridge ultrabook > first time in its history shown 5.5 hours of battery time with full screen > brightness and 10 hours with lid closed. > -- Some kernel functions were added to make KPIs more complete. > > I've successfully tested this patch on amd64 and arm. > > -- > Alexander Motin > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:14:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71F0E885; Sat, 15 Dec 2012 18:14:39 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9FAA8FC0C; Sat, 15 Dec 2012 18:14:38 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so3498890vcb.13 for ; Sat, 15 Dec 2012 10:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XAaxIesgeYTRBfjwUk8HCNywdiBP33u/wuBmbbbHCY0=; b=aklRXlzDbV+pFLuFHpLGZMxi0SCfsPsntQFWwE1y6Xo2jJgDwQqc7Dw0eCuwhZaZCF 0XJeiuiNjoZ9nWuBthnmAi3/50XgUP3qamt80Nd+y+1N3bOxtrd3XxvC9ha1akmrMEcA 6v5gqf4M2RWn0Yi8mn+nMCHfpEgJb/hTEj2cPMpTuvCz6cnvgqasF5Qg02w4MznxH3vC Wzey3delqwljHfID8eeI2x9XbNAkOaFaL9/FUzTtWsq82RyA00ifZlHhUNFQ1wZUGCdg DGLsxMTOkIC/WDqu1I7iOVM4mYglAZXJVJuxyelgWOL+SgYSb8O94u/FeW3H08cS0X5d wQ0A== MIME-Version: 1.0 Received: by 10.220.154.148 with SMTP id o20mr15374194vcw.54.1355595277325; Sat, 15 Dec 2012 10:14:37 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Sat, 15 Dec 2012 10:14:37 -0800 (PST) In-Reply-To: References: <50CCAB99.4040308@FreeBSD.org> Date: Sat, 15 Dec 2012 10:14:37 -0800 X-Google-Sender-Auth: WTlB-VC05qzxBuYU_Dgiq7YU3mY Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 18:14:39 -0000 On Sat, Dec 15, 2012 at 10:05 AM, Adrian Chadd wrote: > Hi, > > Can you please test with MIPS? David has a MIPS board now. > Quoting from my first mail -- "We tested the code on amd64, MIPS and arm." I used the board you gave to me. I run only some "basic" tests, but I can look forward running something more complicated in order to track regressions (if any). > Can you also test that various performance tests haven't been > affected? Eg, do iperf tests through that MIPS board, configured up as > an AP. > Can you be more specific? Do we need it configured as AP or this situation can be in some way simulated? > Please test with a bunch of disk IO activity too. > What benckmark/tool do you suggest? iozone? Do you think is better attaching some external drive and run test on that rather than on the flash present on the board? > I know this is a lot to ask for, but I'd hate to see some driver / > subsystem behaviour change because you didn't quite see the evil way > the callout mechanism is used, or how the timer stuff is affecting > driver pre-emption. > I understand your concerns. I'll try to do my best in order to heavily test. Any kind of suggestion is obviously appreciated. > Thanks, > > > Adrian > > On 15 December 2012 08:55, Alexander Motin wrote: >> Hi. >> >> I'm sorry to interrupt review, but as usual good ideas came during the final >> testing, causing another round. :) Here is updated patch for HEAD, that >> includes several new changes: >> http://people.freebsd.org/~mav/calloutng_12_15.patch >> >> The new changes are: >> -- Precision and event aggregation code was reworked. Instead of previous >> -prec/+prec representation, precision is now single-sided -- -0/+prec. It >> allowed to significantly improve precision on long time intervals for APIs >> which imply that event should not happen before the specified time. >> Depending on CPU activity, mistake for long time intervals now will never be >> more then 1-500ms, even if specified precision allows more. >> -- Some minor optimizations were made to reduce callout overhead and >> latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer and >> TSC timecounter usleep(1) call from user-level executes in just 5-6us, >> instead of 7-8us before. Now it can do 180K cycles per second on single CPU >> with only partial CPU load. >> -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, >> setrlimit) were modified to reduce number of interrupts, also with event >> aggregation by explicit specification of the acceptable events precision. >> Now my Core2Duo test system has only 30 interrupts per second in idle. If >> not remaining syscons events, it could easily be 15. My IvyBridge ultrabook >> first time in its history shown 5.5 hours of battery time with full screen >> brightness and 10 hours with lid closed. >> -- Some kernel functions were added to make KPIs more complete. >> >> I've successfully tested this patch on amd64 and arm. >> >> -- >> Alexander Motin >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 19:55:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD59937F; Sat, 15 Dec 2012 19:55:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 37EEB8FC0C; Sat, 15 Dec 2012 19:55:30 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so1935526wgh.31 for ; Sat, 15 Dec 2012 11:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KgH6pYv90Tz1vpdnDwvnp0b0FXD5WPljs6BAztYdXr8=; b=iPuPh6UGBXWybs28cA87M3F+RO7LrffoUU8ffMpOwEm4ViCuY6OVmN2Bg2II//CUq3 sQWYtFo/G3qrM2JxUcWnTvtxwGMPeucCtlySUG5mtwqEOYxrdqmicnGMdmXgwFTP/sVs uJt/Ev9eOcGrrIRXEEqghmDXVyBaBKkarPc2ZdnnqOOlO/6U3rVvKAWO1yfbjEc51QO8 h1YQRFqm7nW2+j9NOVlhQwHQBhCztIfXnqCqZDwd66FE5hdAIMmkeOejOJ7EPes4a4qY cJH/7QLPNSNuJRzBQ2QCQMbWrTUqldJL90zs6FSiNjUGLVRPNfrQj8sdJcnTDKPGcksI hN7Q== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr9730574wjb.16.1355601330192; Sat, 15 Dec 2012 11:55:30 -0800 (PST) Received: by 10.217.57.9 with HTTP; Sat, 15 Dec 2012 11:55:29 -0800 (PST) In-Reply-To: <50CC9F5E.6080102@a1poweruser.com> References: <50c92508.6384440a.1379.3a4a@mx.google.com> <50CC9F5E.6080102@a1poweruser.com> Date: Sat, 15 Dec 2012 11:55:29 -0800 Message-ID: Subject: Re: AR9285 not see n-channels From: Adrian Chadd To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrey Fesenko , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 19:55:31 -0000 Hi, The output is in line with the 802.11n specification, which calls all of this stuff "HT". I'll work with Eadler and others to improve the wireless documentation and FAQ and I'll make sure there's a chapter on "802.11n", which explains what HT (high throughput) is. 802.11ac is adding "VHT" (very high throughput) rates, so expect ifconfig to grow vht information shortly. Adrian On 15 December 2012 08:03, Fbsd8 wrote: > >> Adrian >> >> On 12 December 2012 17:39, Andrey Fesenko wrote: >>> >>> On Thu, Dec 13, 2012 at 5:33 AM, Adrian Chadd >>> wrote: >>>> >>>> Hi, >>>> >>>> The AR9285 is a 2GHz only NIC. >>>> >>>> The channel list shows 11b, 11bg, HT20 and HT40 channels. >>>> >>>> It all looks right, why don't you think it is? >>>> >>>> >>>> Adrian >>>> >>>> >>>> On 12 December 2012 17:32, Andrey Fesenko wrote: >>>>> >>>>> On Thu, Dec 13, 2012 at 4:55 AM, Adrian Chadd >>>>> wrote: >>>>>> >>>>>> .. yup, you're doing 11n! Welcome! >>>>>> >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> On 12 December 2012 16:54, Andrey Fesenko wrote: >>>>>>> >>>>>>> On Thu, Dec 13, 2012 at 4:44 AM, Adrian Chadd >>>>>>> wrote: >>>>>>>> >>>>>>>> Yup. It's doing 11n rates. >>>>>>>> >>>>>>>> Compile and run athstats, it'll tell you how many aggregate frames >>>>>>>> are being >>>>>>>> sent and received. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> Sent from my Palm Pre on AT&T >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> On Dec 12, 2012 4:39 PM, Andrey Fesenko wrote: >>>>>>>> >>>>>>>> On Thu, Dec 13, 2012 at 4:32 AM, Adrian Chadd >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> What's 'ifconfig wlan0' and 'ifconfig wlan0 list sta' look like? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12 December 2012 15:51, Andrey Fesenko >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I have >>>>>>>>>> # uname -a >>>>>>>>>> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT >>>>>>>>>> #1 >>>>>>>>>> r243259: Mon Nov 19 09:28:08 MSK 2012 >>>>>>>>>> root@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >>>>>>>>>> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >>>>>>>>>> options ATH_ENABLE_11N >>>>>>>>>> options ATH_DEBUG >>>>>>>>>> options ATH_DIAGAPI >>>>>>>>>> >>>>>>>>>> pciconf >>>>>>>>>> ath0@pci0:5:0:0: class=0x028000 card=0xe016105b chip=0x002b168c >>>>>>>>>> rev=0x01 hdr=0x00 >>>>>>>>>> vendor = 'Atheros Communications Inc.' >>>>>>>>>> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >>>>>>>>>> class = network >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> # ifconfig -v wlan0 list channel >>>>>>>>>> Channel 1 : 2412 MHz 11b Channel 7 : 2442 MHz 11g ht/20 >>>>>>>>>> Channel 1 : 2412 MHz 11g Channel 8 : 2447 MHz 11b >>>>>>>>>> Channel 1 : 2412 MHz 11g ht/20 Channel 8 : 2447 MHz 11g >>>>>>>>>> Channel 2 : 2417 MHz 11b Channel 8 : 2447 MHz 11g ht/20 >>>>>>>>>> Channel 2 : 2417 MHz 11g Channel 9 : 2452 MHz 11b >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> wi-fi router have and enable n-mode (linksys e4200) >>>>>>>>>> How to turn on or activate n-mode? >>>>>>>> >>>>>>>> # ifconfig wlan0 list sta >>>>>>>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>>>>>>> 58:6d:8f:fa:d9:50 5 12 72M 27.5 0 2079 31872 EP AQEHTRS >>>>>>>> RSN HTCAP WME WPS >>>>>>>> # ifconfig wlan0 >>>>>>>> wlan0: flags=8843 metric 0 >>>>>>>> mtu 1500 >>>>>>>> ether 4c:0f:6e:4b:4e:f5 >>>>>>>> inet 192.168.1.41 netmask 0xffffff00 broadcast 192.168.1.255 >>>>>>>> nd6 options=29 >>>>>>>> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng >>>>>>>> status: associated >>>>>>>> ssid hometest channel 12 (2467 MHz 11g ht/20) bssid >>>>>>>> 58:6d:8f:fa:d9:50 >>>>>>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>>>>>> deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss >>>>>>>> 7 >>>>>>>> scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme >>>>>>>> burst roaming MANUAL >>>>>>> >>>>>>> # ./athstats >>>>>>> 526213 data frames received >>>>>>> 10205 data frames transmit >>>>>>> 79 short on-chip tx retries >>>>>>> 103 long on-chip tx retries >>>>>>> 16 tx failed 'cuz too many retries >>>>>>> 220 mib overflow interrupts >>>>>>> MCS7 current transmit rate >>>>>>> 1 watchdog timeouts >>>>>>> 42 beacon miss interrupts >>>>>>> 23154 rx failed 'cuz of bad CRC >>>>>>> 56 rx failed 'cuz of PHY err >>>>>>> 56 illegal service >>>>>>> 1638 periodic calibrations >>>>>>> -0/+0 TDMA slot adjust (usecs, smoothed) >>>>>>> 56 rssi of last ack >>>>>>> 50 avg recv rssi >>>>>>> -96 rx noise floor >>>>>>> 13 phantom beacon misses >>>>>>> 6569 tx frames through raw api >>>>>>> 1460 A-MPDU sub-frames received >>>>>>> 183 Half-GI frames received >>>>>>> 183 40MHz frames received >>>>>>> 2397 CRC errors for non-last A-MPDU subframes >>>>>>> 3151 Frames transmitted with HT Protection >>>>>>> 25 A-MPDU sub-frame TX attempt success >>>>>>> 2 first step level >>>>>>> 1 OFDM weak signal detect >>>>>>> 268 listen time >>>>>>> 190 ANI increased spur immunity >>>>>>> 174 ANI decrease spur immunity >>>>>>> 2 ANI enabled OFDM weak signal detect >>>>>>> 3517 ANI disabled OFDM weak signal detect >>>>>>> 3515 ANI disabled CCK weak signal threshold >>>>>>> 4 ANI increased first step level >>>>>>> 2 ANI decreased first step level >>>>>>> 154772 cumulative OFDM phy error count >>>>>>> 528256 cumulative CCK phy error count >>>>>>> 851 ANI forced listen time to zero >>>>>>> 26 missing ACK's >>>>>>> 78 RTS without CTS >>>>>>> 3135 successful RTS >>>>>>> 65747 bad FCS >>>>>>> 473007 beacons received >>>>>>> 53 average rssi (beacons only) >>>>>>> 35 average rssi (all rx'd frames) >>>>>>> 48 average rssi (ACKs only) >>>>>>> Antenna profile: >>>>>>> [0] tx 10173 rx 4 >>>>>>> [1] tx 0 rx 526209 >>>>>>> >>>>>>> >>>>>>> # ./athaggrstats >>>>>>> 17 single frames scheduled >>>>>>> 9 aggregate frames scheduled >>>>>>> 1217 single frames scheduled due to low HWQ depth >>>>>>> >>>>>>> Aggregate size profile: >>>>>>> >>>>>>> 0: 0 1: 0 2: 6 3: 2 >>>>>>> 4: 0 5: 0 6: 0 7: 1 >>>>>>> 8: 0 9: 0 10: 0 11: 0 >>>>> >>>>> why # ifconfig -v wlan0 list channel >>>>> show only b and g channels? and only 13? or this restriction AR9285 >>>>> >>>>> though >>>>> # iperf -i 10 -t 20 -c 192.168.1.26 -w 1024K -l 1024K >>>>> ------------------------------------------------------------ >>>>> Client connecting to 192.168.1.26, TCP port 5001 >>>>> TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) >>>>> ------------------------------------------------------------ >>>>> [ 3] local 192.168.1.41 port 22263 connected with 192.168.1.26 port >>>>> 5001 >>>>> [ ID] Interval Transfer Bandwidth >>>>> [ 3] 0.0-10.0 sec 54.0 MBytes 45.3 Mbits/sec >>> >>> Thanks >>> >>> I was confused that there is no mention n-mode in the output channel list >> >> > Adrian Chadd wrote: >> Right, that's what "HT" is for. >> >> > > Well it would be much clearer to understand by changing the output of the > the channel list to show 11b, 11bg, 11n20 and 11n40 channels instead of HT20 > and HT40, so people would readily know n-mode was active. HT has no meaning > to the general user. > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 20:35:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75EE8BBE; Sat, 15 Dec 2012 20:35:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C44E8FC0A; Sat, 15 Dec 2012 20:35:15 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so7586098iec.13 for ; Sat, 15 Dec 2012 12:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=J2rqCHuEssg/RRlH1bpsFC4yRbJUO9RlxBCqtMW2kCk=; b=ELpVsTItFCJwhWDbWRxp/RviTZ2fnlIZSfLjw5XcuEArjiw+XpsCnHqsB7mNvh721N U+wvD4WE2w1CIGTpPZbsogM6inVUP06H/x9Sj3lzX6zv8Ll90SP8HJxU+b5EZAu1x3es eUlIM5wFzLTxy3wpXGD5Ykb4PqHipg1XX9leAHY19gaM/H0oRqkfhnhjBswDyd/et5TS ZgEhQeD5YoXdxVqtmjTIHQeE0TKeSR5kmZdVKbZNf5InCJHDzTt8AsLEDBQX57oq4k2o McgBDRaAEfZ0nKKtBHa6Rsh0TXOcbcRP+HbW5Jk8BUhV9FIQkfkgHTaflD8EhOFBzoSW 10xQ== Received: by 10.42.75.6 with SMTP id y6mr7722823icj.30.1355603715468; Sat, 15 Dec 2012 12:35:15 -0800 (PST) Received: from oddish ([66.11.160.25]) by mx.google.com with ESMTPS id x7sm2003527igk.8.2012.12.15.12.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 12:35:14 -0800 (PST) Date: Sat, 15 Dec 2012 15:34:59 -0500 From: Mark Johnston To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121215203458.GA22361@oddish> References: <50CCAB99.4040308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CCAB99.4040308@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 20:35:16 -0000 On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: > Hi. > > I'm sorry to interrupt review, but as usual good ideas came during the > final testing, causing another round. :) Here is updated patch for > HEAD, that includes several new changes: > http://people.freebsd.org/~mav/calloutng_12_15.patch This patch breaks the libprocstat build. Specifically, the OpenSolaris sys/time.h defines the preprocessor symbols gethrestime and gethrestime_sec. These symbols are also defined in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. libprocstat:zfs.c is compiled using include paths that pick up the OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. zfs.c includes taskqueue.h (with _KERNEL defined), which includes _callout.h, so both time.h and zfs_context.h are included in zfs.c, and the symbols are thus defined twice. The patch below fixes the build for me. Another approach might be to include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. Thanks, -Mark diff --git a/lib/libprocstat/zfs.c b/lib/libprocstat/zfs.c index aa6d78e..f8844bf 100644 --- a/lib/libprocstat/zfs.c +++ b/lib/libprocstat/zfs.c @@ -35,6 +35,7 @@ #undef lbolt #undef lbolt64 +#undef gethrestime #undef gethrestime_sec #include #include From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 20:46:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE6CCE8D; Sat, 15 Dec 2012 20:46:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4C08FC14; Sat, 15 Dec 2012 20:46:13 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2820047pbc.13 for ; Sat, 15 Dec 2012 12:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rDDLRFOudkIXCVcGGOqERmHSD2Yu2R5ZRzxPpsD5hcY=; b=R/D7uscuPt+jIvhMHUZdfZW2/Nj/JeIQSPNhie1gHce6AuCDVZIvuCrWLBO9XhpZjn dgbwxjthzc6mqkAKwLMr60MLBpuNG/pWudv+kZivW6eNoYxtIVj0Oi+d8O8ex0WTA24J ybVSvcZXAG92zGNQQt1dgcr/FSZarOjC0iIZ8B3v7bXSdaxrnFUOKs9ZX3dJvPoNhLfe adYd9mYXfDq2sWLrOFQGe7wah+eSArwEUMdwMal58SeKUYDa9oYxl6gsshhUA7pZRkwL XOOuN2w39VFnayDMofPkM/e7AFlT2PZz0LDu35kCySc/MjfRKdxLiZMPsis0oqa9GK6Q 5s6A== Received: by 10.66.88.133 with SMTP id bg5mr27607992pab.21.1355604367814; Sat, 15 Dec 2012 12:46:07 -0800 (PST) Received: from [192.168.20.11] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id rk17sm5226225pbb.3.2012.12.15.12.46.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 12:46:06 -0800 (PST) Subject: Re: [RFC/RFT] calloutng Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20121215203458.GA22361@oddish> Date: Sat, 15 Dec 2012 12:46:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35705A81-690A-4993-B0C3-C8BC0BC89C67@gmail.com> References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> To: Mark Johnston X-Mailer: Apple Mail (2.1283) Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 20:46:14 -0000 On Dec 15, 2012, at 12:34 PM, Mark Johnston wrote: > On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: >> Hi. >>=20 >> I'm sorry to interrupt review, but as usual good ideas came during = the=20 >> final testing, causing another round. :) Here is updated patch for=20= >> HEAD, that includes several new changes: >> http://people.freebsd.org/~mav/calloutng_12_15.patch >=20 > This patch breaks the libprocstat build. >=20 > Specifically, the OpenSolaris sys/time.h defines the preprocessor > symbols gethrestime and gethrestime_sec. These symbols are also = defined > in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. > libprocstat:zfs.c is compiled using include paths that pick up the > OpenSolaris time.h, and with this patch _callout.h includes = sys/time.h. >=20 > zfs.c includes taskqueue.h (with _KERNEL defined), which includes > _callout.h, so both time.h and zfs_context.h are included in zfs.c, = and > the symbols are thus defined twice. >=20 > The patch below fixes the build for me. Another approach might be to > include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. I had a patch open once upon a time to cleanup inclusion of = sys/time.h all over the tree and deal with the sys/time.h <-> time.h = pollution issue, but it got dropped due to lack of interest (20~30 = apps/libs were affected IIRC and I only really got assistance in fixing = the UFS and bsnmpd pieces, and gave up due to lack of response from = maintainers). dtrace/zfs is a definite instigator in this pollution (I = remember nasty cddl/... pollution with the compat sys/time.h header). Bottom line: make sure anything new you're defining isn't = already defined via POSIX or other OSes, and if so please try to make = the implementations match (so that eventual POSIX inclusion might be = possible) and when in doubt I suggest consulting standards@ / brde@. Cheers, -Garrett= From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 20:50:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DA4E351; Sat, 15 Dec 2012 20:50:47 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D9C948FC0A; Sat, 15 Dec 2012 20:50:46 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so3578976vcb.13 for ; Sat, 15 Dec 2012 12:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=J7IG0GsmlLlh6Q10fkGbRhKCrRcIVQfRIM9SxQL8dpg=; b=Fx1g79EIl6LPTrl7O4IotE/ljZ8or4h6gGFZTujxUBWQhT7XazkLqvDZ4RKD9OPA5c N0YZu5M4Cdopxq/zHbKaGGgzWmUJxgYPdlUSeXkWS4QuSM1CoeGlHu9BmkzNyjsFiIa5 5WNh/TOIUsZ3Spx5ZkTxGkuIwplbNy0bDJ9D0HBr/kR7RbTdu65eUGGhruYZywrDbTmH 9S6izpHGhdhVyutURYuVnrMS1DEbXYpBtNzmZYiz/uNDlzYdAzRAUcOtC9BSPRhJQ3lH kyyzTk57uLONpaf06OGucbnPsWcNRoshedHHB8C92Te/Oai2qwIokEc7roXjuz/ash0G 6ZRA== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr13583598vdu.99.1355604645889; Sat, 15 Dec 2012 12:50:45 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Sat, 15 Dec 2012 12:50:45 -0800 (PST) In-Reply-To: <20121215203458.GA22361@oddish> References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> Date: Sat, 15 Dec 2012 12:50:45 -0800 X-Google-Sender-Auth: DcVtRg3QFEp51CzTIX97kavb0O4 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 20:50:47 -0000 On Sat, Dec 15, 2012 at 12:34 PM, Mark Johnston wrote: > On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: >> Hi. >> >> I'm sorry to interrupt review, but as usual good ideas came during the >> final testing, causing another round. :) Here is updated patch for >> HEAD, that includes several new changes: >> http://people.freebsd.org/~mav/calloutng_12_15.patch > > This patch breaks the libprocstat build. > > Specifically, the OpenSolaris sys/time.h defines the preprocessor > symbols gethrestime and gethrestime_sec. These symbols are also defined > in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. > libprocstat:zfs.c is compiled using include paths that pick up the > OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. > > zfs.c includes taskqueue.h (with _KERNEL defined), which includes > _callout.h, so both time.h and zfs_context.h are included in zfs.c, and > the symbols are thus defined twice. > > The patch below fixes the build for me. Another approach might be to > include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. > > Thanks, > -Mark > > diff --git a/lib/libprocstat/zfs.c b/lib/libprocstat/zfs.c > index aa6d78e..f8844bf 100644 > --- a/lib/libprocstat/zfs.c > +++ b/lib/libprocstat/zfs.c > @@ -35,6 +35,7 @@ > > #undef lbolt > #undef lbolt64 > +#undef gethrestime > #undef gethrestime_sec > #include > #include I fixed (or at least workarounded) that issue during the summer. http://svnweb.freebsd.org/base?view=revision&revision=237068 Probably that was lost somewhere. We're going to regenerate a patch, but for now I suggest to patch that manually or to checkout the calloutng project repository. From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:03:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ADA2A9F; Sat, 15 Dec 2012 21:03:33 +0000 (UTC) (envelope-from mavbsd@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 AD1C68FC19; Sat, 15 Dec 2012 21:03:32 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2129547wey.13 for ; Sat, 15 Dec 2012 13:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uVNWanL7oPU4mSpbgzQpla/m8Id0omxxLsJEieKqPhg=; b=p+ZLMK8hO6kLuGhgS/qEkJ0SffXPxe/CuzN8ZUgb+ON8H8dtzGz7SA+AIhb/hQKoyY oQOc+9UrXPo48ZG0MLOqYi6W3W8I5hvlbM22T/5J1gIjbodm6zw5jQM3B74SuI/4GyiM oV4nT2cM73/UGxPdzZ4RI/Hhh+j7zA38Zw14ROldVdNIrGdeXy1yGAe+KwOtDN3KGd7+ ugiyGTRGoAkNh8UIQOE7BfrBnY59i4vhYOFFDZ/W1dO1l42raqKA0VnLOO/vaQEmiQxW qnp90iyghSkAWN9wXvc6EhNFNL4uYHA/cAUR2Fv8ug9C6k6D8uOFZ4UofTf/auvjvJK8 KApw== Received: by 10.180.88.138 with SMTP id bg10mr8703142wib.13.1355605411525; Sat, 15 Dec 2012 13:03:31 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id cf6sm4316001wib.3.2012.12.15.13.03.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 13:03:30 -0800 (PST) Sender: Alexander Motin Message-ID: <50CCE59F.1080107@FreeBSD.org> Date: Sat, 15 Dec 2012 23:03:27 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Davide Italiano Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 21:03:33 -0000 On 15.12.2012 22:50, Davide Italiano wrote: > On Sat, Dec 15, 2012 at 12:34 PM, Mark Johnston wrote: >> On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: >>> I'm sorry to interrupt review, but as usual good ideas came during the >>> final testing, causing another round. :) Here is updated patch for >>> HEAD, that includes several new changes: >>> http://people.freebsd.org/~mav/calloutng_12_15.patch >> >> This patch breaks the libprocstat build. >> >> Specifically, the OpenSolaris sys/time.h defines the preprocessor >> symbols gethrestime and gethrestime_sec. These symbols are also defined >> in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. >> libprocstat:zfs.c is compiled using include paths that pick up the >> OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. >> >> zfs.c includes taskqueue.h (with _KERNEL defined), which includes >> _callout.h, so both time.h and zfs_context.h are included in zfs.c, and >> the symbols are thus defined twice. >> >> The patch below fixes the build for me. Another approach might be to >> include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. > > I fixed (or at least workarounded) that issue during the summer. > http://svnweb.freebsd.org/base?view=revision&revision=237068 > Probably that was lost somewhere. We're going to regenerate a patch, > but for now I suggest to patch that manually or to checkout the > calloutng project repository. Sorry, it's my fault. I've tried to save some time on patch generation and forgot about that change in lib/. We haven't touched user-level in our work except that file. Here is patch with that chunk added: http://people.freebsd.org/~mav/calloutng_12_15_1.patch -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:07:49 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95F18E62; Sat, 15 Dec 2012 21:07:49 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 250DF8FC13; Sat, 15 Dec 2012 21:07:48 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBFL7lbx089552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 22:07:47 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sat, 15 Dec 2012 22:07:47 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Chris Rees Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20121215210746.GI69724@acme.spoerlein.net> Mail-Followup-To: Chris Rees , "current@freebsd.org" References: <20121215132246.GH69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 21:07:49 -0000 On Sat, 2012-12-15 at 16:10:46 +0000, Chris Rees wrote: > On 15 December 2012 13:22, Ulrich Spörlein wrote: > > Bad news everyone, > > > > tl;dr The git mirror of the source repository needs to be re-rolled to > > make the conversion deterministically repeatable, this will change > > pretty much all git commit hashes. > > > > The re-roll will be done January 15, 2013. > > > > Not affected are the ports and doc repositories, nor is the svn_head > > (for use with git-svn) affected. > > > > > > Background > > > > The converter (svn2git) was handing commits and objects to git's > > fast-import in arbitrary order, this makes merge commits have an > > arbitrary order of their parent commits and thus these merge commits > > have changing commit hashes for each converter run. > > > > This has been fixed, but requires us to move all the branches over to > > this deterministic scheme, which will change all their commit hashes. > > None of the contents of these commits change, so rebasing/remerging your > > work into these branches is possible without running into any merge > > conflicts. > > > > > > We need your help > > > > A goal of these conversions is to have them repeatable by you (yes, > > you!), so the correctness of the conversion can be verified. There are > > also no backups of the conversion runs, as they should be repeatable > > anyway. > > > > We need 2-3 volunteers to run these conversions themselves and verify > > that the produced commit hashes match the published ones. The necessary > > steps to do this are documented on the Wiki under > > > > http://wiki.freebsd.org/GitWorkflow#History > > > > Please send me your output of git show-ref in a private mail, thanks. > > Hey, > > http://www.bayofrum.net/~crees/scratch/git-show-ref.txt > > I hope it's what you were hoping for :) > > My local svn mirror is synchronised at midnight GMT (UTC). > > Need anything else? That was fast, thanks! I need to write up some comparison scripts first, because it's not a simple comparison (due to different SVN bases). I took a random branch that hasn't been changed in a while, though, and your hashes are different then mine. What versions of Subversion, APR, git and QT4 do you have installed? Can you make that repo available somewhere for me to pull (or better yet, rsync it with all the svn2git metadata?) Thanks Uli From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:13:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3C241D0; Sat, 15 Dec 2012 21:13:31 +0000 (UTC) (envelope-from mavbsd@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 D5A298FC13; Sat, 15 Dec 2012 21:13:30 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2131715wey.13 for ; Sat, 15 Dec 2012 13:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zlGgyR5dR9vhntoD3Pa0ZBhySFyS8xxNaaXEj9GspIc=; b=gpWImdjc6HcvMWu+SRVYI3jfgZxT6C3x/5K3C/Bo3cUvD62UUefxWLe0NIJ1gCQZBq EAj/kPL6EEZmj2ZY6TzVvdAmPVzOi6lxJ47wrFfilVygYE6CxLr2bTt+DbSCuMGGOUXV 96FfaqXlqFHiQViF+BuJQhbL3QQARTx1u8lbH+7lOAnj1uwsxPQDyWbPlt++dqULb5Zq IWVPAynLeDvNh0I4u6YNqG3QjyOKlV/ty2bbfW+mxV9eX7LDYEbPmsqCQkMdm2KCoEmJ ItOeP4w4pfCBnumTQlSNv9XCL2gEV7sd4fmPRQPGhJuEjihurZjy1L/oE7WXeiDorl+3 J07Q== X-Received: by 10.180.87.39 with SMTP id u7mr8719439wiz.6.1355606009701; Sat, 15 Dec 2012 13:13:29 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id i2sm3895838wiw.3.2012.12.15.13.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 13:13:28 -0800 (PST) Sender: Alexander Motin Message-ID: <50CCE7F6.2090505@FreeBSD.org> Date: Sat, 15 Dec 2012 23:13:26 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Davide Italiano Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> <50CCE59F.1080107@FreeBSD.org> In-Reply-To: <50CCE59F.1080107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 21:13:31 -0000 On 15.12.2012 23:03, Alexander Motin wrote: > On 15.12.2012 22:50, Davide Italiano wrote: >> On Sat, Dec 15, 2012 at 12:34 PM, Mark Johnston >> wrote: >>> On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: >>>> I'm sorry to interrupt review, but as usual good ideas came during the >>>> final testing, causing another round. :) Here is updated patch for >>>> HEAD, that includes several new changes: >>>> http://people.freebsd.org/~mav/calloutng_12_15.patch >>> >>> This patch breaks the libprocstat build. >>> >>> Specifically, the OpenSolaris sys/time.h defines the preprocessor >>> symbols gethrestime and gethrestime_sec. These symbols are also defined >>> in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. >>> libprocstat:zfs.c is compiled using include paths that pick up the >>> OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. >>> >>> zfs.c includes taskqueue.h (with _KERNEL defined), which includes >>> _callout.h, so both time.h and zfs_context.h are included in zfs.c, and >>> the symbols are thus defined twice. >>> >>> The patch below fixes the build for me. Another approach might be to >>> include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. >> >> I fixed (or at least workarounded) that issue during the summer. >> http://svnweb.freebsd.org/base?view=revision&revision=237068 >> Probably that was lost somewhere. We're going to regenerate a patch, >> but for now I suggest to patch that manually or to checkout the >> calloutng project repository. > > Sorry, it's my fault. I've tried to save some time on patch generation > and forgot about that change in lib/. We haven't touched user-level in > our work except that file. Here is patch with that chunk added: > http://people.freebsd.org/~mav/calloutng_12_15_1.patch And one more part I've missed is manual pages update, that probably needs more improvements: http://people.freebsd.org/~mav/calloutng_12_15.man.patch -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:16:36 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18887531 for ; Sat, 15 Dec 2012 21:16:36 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 842858FC0A for ; Sat, 15 Dec 2012 21:16:35 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBFLGYdf089856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 15 Dec 2012 22:16:34 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sat, 15 Dec 2012 22:16:34 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20121215211634.GJ69724@acme.spoerlein.net> Mail-Followup-To: current@freebsd.org References: <20121215132246.GH69724@acme.spoerlein.net> <20121215210746.GI69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20121215210746.GI69724@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 21:16:36 -0000 On Sat, 2012-12-15 at 22:07:46 +0100, Ulrich Spörlein wrote: > On Sat, 2012-12-15 at 16:10:46 +0000, Chris Rees wrote: > > On 15 December 2012 13:22, Ulrich Spörlein wrote: > > > Bad news everyone, > > > > > > tl;dr The git mirror of the source repository needs to be re-rolled to > > > make the conversion deterministically repeatable, this will change > > > pretty much all git commit hashes. > > > > > > The re-roll will be done January 15, 2013. > > > > > > Not affected are the ports and doc repositories, nor is the svn_head > > > (for use with git-svn) affected. > > > > > > > > > Background > > > > > > The converter (svn2git) was handing commits and objects to git's > > > fast-import in arbitrary order, this makes merge commits have an > > > arbitrary order of their parent commits and thus these merge commits > > > have changing commit hashes for each converter run. > > > > > > This has been fixed, but requires us to move all the branches over to > > > this deterministic scheme, which will change all their commit hashes. > > > None of the contents of these commits change, so rebasing/remerging your > > > work into these branches is possible without running into any merge > > > conflicts. > > > > > > > > > We need your help > > > > > > A goal of these conversions is to have them repeatable by you (yes, > > > you!), so the correctness of the conversion can be verified. There are > > > also no backups of the conversion runs, as they should be repeatable > > > anyway. > > > > > > We need 2-3 volunteers to run these conversions themselves and verify > > > that the produced commit hashes match the published ones. The necessary > > > steps to do this are documented on the Wiki under > > > > > > http://wiki.freebsd.org/GitWorkflow#History > > > > > > Please send me your output of git show-ref in a private mail, thanks. > > > > Hey, > > > > http://www.bayofrum.net/~crees/scratch/git-show-ref.txt > > > > I hope it's what you were hoping for :) > > > > My local svn mirror is synchronised at midnight GMT (UTC). > > > > Need anything else? > > That was fast, thanks! I need to write up some comparison scripts first, > because it's not a simple comparison (due to different SVN bases). > > I took a random branch that hasn't been changed in a while, though, and > your hashes are different then mine. What versions of Subversion, APR, > git and QT4 do you have installed? > > Can you make that repo available somewhere for me to pull (or better > yet, rsync it with all the svn2git metadata?) Ok, scrap that, I have too many copies of the conversion lying around and got confused. I'd like to thank all who reported in with hashes of their conversion run and will make sure all is solid tomorrow. Thanks again, Uli From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:54:17 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16B55679; Sat, 15 Dec 2012 21:54:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id CB2F98FC0C; Sat, 15 Dec 2012 21:54:16 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 5A1DF23F763; Sat, 15 Dec 2012 16:54:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us 5A1DF23F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sat, 15 Dec 2012 16:54:12 -0500 From: Glen Barber To: stable@FreeBSD.org, current@FreeBSD.org Subject: FWD: FreeBSD Development Snapshot Availability Message-ID: <20121215215412.GE1344@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fWddYNRDgTk9wQGZ" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Dec 2012 21:54:17 -0000 --fWddYNRDgTk9wQGZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For those on -stable@ and -current@ not subscribed to -announce@: Glen ----- Forwarded message from Glen Barber ----- Date: Sat, 15 Dec 2012 10:37:11 -0500 =46rom: Glen Barber To: freebsd-announce@FreeBSD.org Subject: FreeBSD Development Snapshot Availability I am pleased to announce the re-availability of FreeBSD development snapshots provided by the FreeBSD Project. As with any development branch, these snapshots are not intended for use on production systems. However, we do encourage testing on non-production systems as much as possible. At this time, installation images are available for: - 10.0-CURRENT/amd64 - 10.0-CURRENT/i386 - 10.0-CURRENT/powerpc - 10.0-CURRENT/powerpc64 - 9.1-PRERELEASE/amd64 - 9.1-PRERELEASE/i386 Snapshots for the stable/8 branch are currently not available. Please note, the 9.1-PRERELEASE images are the stable/9 branch, not what will be 9.1-RELEASE. Also note, the 10.0-CURRENT powerpc and powerpc64 builds do not currently include a memstick image. Users interested in testing the development branches are also encouraged to subscribe to the freebsd-snapshots@ mailing list, where new snapshot availability, including corresponding installation image checksums, and any additional noteworthy information about the images will be announced. The list subscription URL is: http://lists.freebsd.org/mailman/listinfo/freebsd-snapshots Snapshots may be downloaded from the corresponding architecture subdirectory over FTP: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the GNATS PR system or the appropriate mailing list, such as -current@ or -stable@ . Checksums for the current set of snapshots: o 10.0-CURRENT amd64: MD5 (FreeBSD-10.0-CURRENT-amd64-20121209-bootonly.iso) =3D c98f99312f9da7dc= f94e571da759583d MD5 (FreeBSD-10.0-CURRENT-amd64-20121209-memstick) =3D eb7bcf8dcfae35d772b9= b20ce64c7399 MD5 (FreeBSD-10.0-CURRENT-amd64-20121209-release.iso) =3D 239bdf4de6774a47c= cc11ca1d378e1ef SHA256 (FreeBSD-10.0-CURRENT-amd64-20121209-bootonly.iso) =3D 20998c1272115= dde8ef032ea58471e7aafd6c41284d81a65b9e407d3884c5d1f SHA256 (FreeBSD-10.0-CURRENT-amd64-20121209-memstick) =3D 2429ba78a4647324b= 2a0009037e0400df06e2e10a2a9547b5c7a8ac3b28629b9 SHA256 (FreeBSD-10.0-CURRENT-amd64-20121209-release.iso) =3D 9d0dc08bdae87e= 9dd883afa5e0448b85491345124c0a8a0741559d6599b720bf o 10.0-CURRENT i386: MD5 (FreeBSD-10.0-CURRENT-i386-20121209-bootonly.iso) =3D 6ef0f61e42e0554f8= 128bfe468840451 MD5 (FreeBSD-10.0-CURRENT-i386-20121209-memstick) =3D 1af85be9389e43b373c67= c7aa3e5c550 MD5 (FreeBSD-10.0-CURRENT-i386-20121209-release.iso) =3D cae4bc258aaf94c056= a9e818ca7393fa SHA256 (FreeBSD-10.0-CURRENT-i386-20121209-bootonly.iso) =3D d576dcae22df22= 6a59dbe2d4e25efee335c85f62b9551936e2f1c1a973dbb3fb SHA256 (FreeBSD-10.0-CURRENT-i386-20121209-memstick) =3D c828b881f2587cebd7= 746033e774767894555968bbf0052237a55ee1697b71c2 SHA256 (FreeBSD-10.0-CURRENT-i386-20121209-release.iso) =3D e8745fb4ed6efa9= aa4eb4e4873e4dcf39d97d381c983326758eb001954ac8405 o 10.0-CURRENT powerpc: MD5 (FreeBSD-10.0-CURRENT-powerpc-20121211-bootonly.iso) =3D 6767d524c12c79= 63dc788b451a7a8384 MD5 (FreeBSD-10.0-CURRENT-powerpc-20121211-release.iso) =3D 7374f919c36dbd5= 2966db35b86a58f78 SHA256 (FreeBSD-10.0-CURRENT-powerpc-20121211-bootonly.iso) =3D 509f7e0d9e7= 95ca7fda95e6c68fc94afa914b24eaaddf463a82183475e9d2dc1 SHA256 (FreeBSD-10.0-CURRENT-powerpc-20121211-release.iso) =3D 2a8955dbb193= 7cffd205bb518be43dea5c33353bfb44606fabed6f719b9680b0 o 10.0-CURRENT powerpc64: MD5 (FreeBSD-10.0-CURRENT-powerpc64-20121210-bootonly.iso) =3D 066fb4da4339= b67cb7d33bc7c0947f54 MD5 (FreeBSD-10.0-CURRENT-powerpc64-20121210-release.iso) =3D db30b252b78fd= 85eefdbfddd37c91797 SHA256 (FreeBSD-10.0-CURRENT-powerpc64-20121210-bootonly.iso) =3D 2e3b725f9= 101afa87932bb3688dcc1ec9ceb40d419d7c7bd5ab808bb85f43513 SHA256 (FreeBSD-10.0-CURRENT-powerpc64-20121210-release.iso) =3D 36cd422196= 18524239906bedeb6b9571b1dae41471f9cb025d1dfec8618bf1c4 o 9.1-PRERELEASE amd64: MD5 (FreeBSD-9.1-PRERELEASE-amd64-20121209-bootonly.iso) =3D 10e970db2eb681= 07eed0d010798f30cc MD5 (FreeBSD-9.1-PRERELEASE-amd64-20121209-memstick) =3D 07b0422e45a8836daf= f9e052bd973e1a MD5 (FreeBSD-9.1-PRERELEASE-amd64-20121209-release.iso) =3D 1e7f7836d1ad519= c5fd01775c7bb7576 SHA256 (FreeBSD-9.1-PRERELEASE-amd64-20121209-bootonly.iso) =3D 5359dc27d38= 8da44163e5d0b9ecef1dda2eb4a4e83469849c86ad967ff74e26a SHA256 (FreeBSD-9.1-PRERELEASE-amd64-20121209-memstick) =3D c6a8c4e5ffffc1a= 56a4f6efcdbef2736d265d2270693b763ed4171ffea9f94a5 SHA256 (FreeBSD-9.1-PRERELEASE-amd64-20121209-release.iso) =3D ca180c895890= 2c32e01629b01b2db4c826aa5817ab1abf03512103f948e87492 o 9.1-PRERELEASE i386: MD5 (FreeBSD-9.1-PRERELEASE-i386-20121209-bootonly.iso) =3D 05511515a607399= 037de2227284aa119 MD5 (FreeBSD-9.1-PRERELEASE-i386-20121209-memstick) =3D 9b12248a2eb06e5c7f3= 4d48684d3979d MD5 (FreeBSD-9.1-PRERELEASE-i386-20121209-release.iso) =3D f4c880b3d6d124d1= 943e37bc4b5d51a3 SHA256 (FreeBSD-9.1-PRERELEASE-i386-20121209-bootonly.iso) =3D 1d5e6f52b356= 7c78c384df34d80ab90fd594d26f8064955118477964a1278939 SHA256 (FreeBSD-9.1-PRERELEASE-i386-20121209-memstick) =3D 33d86994013df479= 70e8b780a94649505fc41ca43f922bf3014a6b425dbc80f0 SHA256 (FreeBSD-9.1-PRERELEASE-i386-20121209-release.iso) =3D 1e8998f069ce8= 85c0d6a8d267d5fe14da9b33ed2dc90a52b501197d67f28090b Regards, Glen --=20 One OS to rule them all, On FTP, we'll host them. One machine to build them all, And any bugs, we'll find them. ----- End forwarded message ----- --fWddYNRDgTk9wQGZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQzPGEAAoJEFJPDDeguUajUmMH/2aWVcsoWIC905k4n54Xbrmw gnALqiCcHaoFRFFkwe4OwG6+spQHyDuQp6ukvpwfkWcd+GsAsibvk4jWIqupmzUD fQDZ9PFQNq1fzE8CoZqhmQgD6LCV7vAg8XHzGKFDVNB/HoauISWx5X2iJnTnQpu6 q7RwWbL4QssnsoYrxs2iT3z0CdgbxIgk53pShLbMrYi+RBmEJ5FHMPHQOgy0qZLN x1DyzgrVQQQlvjP0SwXSBAkwfakHXj0XlgRaSBXx9zosFE5nT6XREl8vgEufZXtf nPQJSA4YFSkBrd///h+3jdBT++8bAvCIBvL+cYYKF8fKBQhQQG7AC8TqTTxufGk= =iUFz -----END PGP SIGNATURE----- --fWddYNRDgTk9wQGZ--