From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 00:43:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4664106568D for ; Sun, 16 Aug 2009 00:43:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id D39298FC43 for ; Sun, 16 Aug 2009 00:43:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOG001B920QNX00@asmtp029.mac.com> for freebsd-current@freebsd.org; Sat, 15 Aug 2009 17:43:39 -0700 (PDT) From: Marcel Moolenaar Date: Sat, 15 Aug 2009 17:43:38 -0700 Message-id: To: FreeBSD Current X-Mailer: Apple Mail (2.1074) Subject: panic: mtx_init: mtx_lock not aligned for turnstile chain: 0xe00000000482b778 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 00:43:40 -0000 This is PR kern/137800. Present on ia64 as well. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xe000000004068000... panic: mtx_init: mtx_lock not aligned for turnstile chain: 0xe00000000482b778 cpuid = 0 fatal kernel trap (cpu 0): trap vector = 0x4 (Alternate Data TLB) cr.iip = 0xe0000000042fbd50 cr.ipsr = 0x1010080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=0,bn) cr.isr = 0x80400000000 (code=0,vector=0,r,ei=0,ed) cr.ifa = 0x18 curthread = 0xe00000000481ecb0 pid = 0, comm = -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 05:13:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061C5106568C for ; Sun, 16 Aug 2009 05:13:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3928FC45 for ; Sun, 16 Aug 2009 05:13:40 +0000 (UTC) Received: by bwz19 with SMTP id 19so2436550bwz.37 for ; Sat, 15 Aug 2009 22:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=eSr9LOV4ZEMSWk9EeloYieMO/aA+e2/bAjh1hrWaZi0=; b=B8vh2jBidGK+295Eb8I1K8h4DKW1zXzBGdZRvf6TDFrE2WpN1rFa1NImLVOGX4RSNR 8DTnVhJovhlk5p2Plm0Z/P4ctrodc8ydoZp/94GILP5WaqqgoQ5ZZa9uwAmdlsjGoMDj fks/UV8nWCP6+hSy9p1UEFNPRMks8G34pYrLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XDJYFp2Gw+kUrCRPqjClKeZiZPx8XDoE1WycjLdWJAcp5yxhV8nbPy8xweIr7YPF6T TtQc5ijFZWHd10lAiyPQ8L61noRIYSQj87BUKeHyGFBlxIxKotATHqcJrBbejP7NlUG1 8fumKGSONzFsENVQl1eQ4OB7EUKUBjzARgxyY= MIME-Version: 1.0 Received: by 10.204.26.134 with SMTP id e6mr1944708bkc.87.1250399619522; Sat, 15 Aug 2009 22:13:39 -0700 (PDT) Date: Sun, 16 Aug 2009 09:13:39 +0400 Message-ID: From: pluknet To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: broken regression/acct for several years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 05:13:41 -0000 Hi. This commit - kern_acct.c,v1,94 / svn r172023 - broke regression/acct just before 7.0 was out by inclusion kernel log() function call that requires include, and some magic with kernel/userland side of syslog() since log() on userland side is not present. It could be fixed by changing log() with simple printf() and adding specilally for regression test to -- m wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 05:22:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82AA0106568C for ; Sun, 16 Aug 2009 05:22:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9F88FC15 for ; Sun, 16 Aug 2009 05:22:38 +0000 (UTC) Received: by bwz19 with SMTP id 19so2439445bwz.37 for ; Sat, 15 Aug 2009 22:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=M25OzLGC6tKIK8mA5xhZVyNvEYuT7KjD+NtqVvHNX2A=; b=RvD2hb6rFQtTF2d7lsOF0YWjJH2puesmg3k0C0r9pUs4Xtjj730BcUC2UbqRNapOW+ hewp/1bJADqG4WgRkW3Uigb/r/Tl2IYUlanD2DW/8RPS4GBEuuv8yUBg9DQYbAiUniTh 0cAFfWyHqy1ng5x7dxYx0ht6gyAm6IdJr9Bck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=FWYwJOCZ/euXEE4Fnjn7XDLtS9/wTSn9FsIvhkyW9ySRXqBGRLr1Zx5RPNDoB4A4ox VjCDIuZYZrYYa7qRnFyHZPVVQeTjRuuR+9XfOgJJcaOacY3sGVNZMV6VCjRHu4TKkCwZ HdnnxAY2TnQ+31UTwBC1wnG4N4Ace1aW55E3k= MIME-Version: 1.0 Received: by 10.204.151.83 with SMTP id b19mr1912253bkw.102.1250400157833; Sat, 15 Aug 2009 22:22:37 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Aug 2009 09:22:37 +0400 Message-ID: From: pluknet To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: broken regression/acct for several years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 05:22:39 -0000 2009/8/16 pluknet : > Hi. > > This commit - kern_acct.c,v1,94 / svn r172023 - broke > regression/acct just before 7.0 was out by inclusion > kernel log() function call that requires include, > and some magic with kernel/userland side of syslog() since > log() on userland side is =A0not present. > > It could be fixed by changing log() with simple printf() and > adding specially for regression test to [Sorry, wrong button pressed] to fix "LONG_MAX undefined", so it would be like: convert.c: ../../../sys/kern/kern_acct.c - sed -n '/FLOAT_CONVERSION_START/,/FLOAT_CONVERSION_END/p' $? >= $@ + echo "#include " > $@ + sed -n '/FLOAT_CONVERSION_START/,/FLOAT_CONVERSION_END/p' $? >>= $@ or by reverting r172023. Thanks. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 10:28:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B452106568B; Sun, 16 Aug 2009 10:28:33 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id CCA9C8FC16; Sun, 16 Aug 2009 10:28:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 7057E6D423; Sun, 16 Aug 2009 12:30:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwyW5B7-jg7u; Sun, 16 Aug 2009 12:30:31 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 0B82B6D41E; Sun, 16 Aug 2009 12:30:31 +0200 (CEST) Date: Sun, 16 Aug 2009 12:30:30 +0200 From: Rink Springer To: Robert Watson Message-ID: <20090816103030.GA11725@rink.nu> References: <20090803152202.GB61519@rink.nu> 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: David Boyd , Rink Springer , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 10:28:33 -0000 On Sun, Aug 09, 2009 at 07:33:35PM +0100, Robert Watson wrote: > > On Mon, 3 Aug 2009, Rink Springer wrote: > > > On Mon, Aug 03, 2009 at 11:04:31AM -0400, David Boyd wrote: > >> Can someone "PLEASE" commit this fix. > > > > This fix looks OK to me; I'll ask re@ for permission. > > Just a status update: this is in the re@ queue but approval is pending > completion of the stable/7 branch. The plan is that this should appear in > beta3. It has been committed (r196272) and merged to 8, which means it will be in BETA3 and 8.0-RELEASE. Thank you for your persistance and patience. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 13:02:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12CA4106564A for ; Sun, 16 Aug 2009 13:02:53 +0000 (UTC) (envelope-from scb+freebsd-current@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id B70C28FC5A for ; Sun, 16 Aug 2009 13:02:52 +0000 (UTC) Received: from [10.1.1.60] (dslb-088-065-048-196.pools.arcor-ip.net [88.65.48.196]) by mx01.netsrc.de (Postfix) with ESMTP id 2661C192FD9; Sun, 16 Aug 2009 14:51:33 +0200 (CEST) Message-Id: <1618A5F5-F037-46CF-954A-38FB13BAA649@techwires.net> From: Bernhard Schmidt To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 16 Aug 2009 14:51:25 +0200 X-Mailer: Apple Mail (2.936) Cc: Marc UBM , Daniel Eriksson Subject: Several reported instances of boot hangs ("still waiting for xpt_config") for hptrr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 13:02:53 -0000 Hi, I do have a Highpoint RocketRaid 2220 controller myself which throws similar errors since the release of 8.0-BETA2. Tracking the commits, I could narrow it down to r195534. The issue is, that htprr makes use of xpt_scan_bus() which ist no longer available in xpt_action[_default]() when cpi->transport is not set to one of XPORT_*. This probably affects all drivers relying upon xpt_scan_bus() but not setting cpi->transport. This patch has been tested against latest head and stable/8 with no more issues for me. Index: sys/dev/hptrr/hptrr_osm_bsd.c =================================================================== --- sys/dev/hptrr/hptrr_osm_bsd.c (revision 196273) +++ sys/dev/hptrr/hptrr_osm_bsd.c (working copy) @@ -814,6 +814,10 @@ strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); strncpy(cpi->hba_vid, "HPT ", HBA_IDLEN); strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); + cpi->transport = XPORT_SPI; + cpi->transport_version = 2; + cpi->protocol = PROTO_SCSI; + cpi->protocol_version = SCSI_REV_2; cpi->ccb_h.status = CAM_REQ_CMP; break; } From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 15:08:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A9A2106568C for ; Sun, 16 Aug 2009 15:08:47 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF368FC3F for ; Sun, 16 Aug 2009 15:08:46 +0000 (UTC) Received: by bwz19 with SMTP id 19so2593434bwz.37 for ; Sun, 16 Aug 2009 08:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=NYvr/3c1+gqPXIlI46ITCQEesCeaaOFGIVDO4/fRxrU=; b=vguHNJyFpFQm6cMsufRrYB6fcA8w3C1Dcmdxqr6hsC6Es/9KJYuEiOvx+HJRx2rd7g u0S3wz076+BCPSwW1R3DBoJXxvqP50E72hn9FyA6Vjg+H27qCCQllsnETQULxWloZi1o gOvcJ0jbd7pxBU3zGQLOSLDUmxeH1BTTi6XWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=rIwByAE0HiYj/orYZZZ6kIthc1RnFG9qEc2uJB/nVR9H2e/cS6DpZ2Q0HS4ZDyNSER HSvq9xbeHf9NpSank7wAsFmuxzG745dvOJ6vgVeGtKXUH8P9wDkjoVHEcI4nvQJco5Dj XpXe/dP4jJKlrbBH/ZvLL/MNV/2jWM9HDixyg= Received: by 10.204.11.9 with SMTP id r9mr2110594bkr.34.1250435325780; Sun, 16 Aug 2009 08:08:45 -0700 (PDT) Received: from ubm.mine.nu (e181039198.adsl.alicedsl.de [85.181.39.198]) by mx.google.com with ESMTPS id 2sm4075034fks.3.2009.08.16.08.08.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Aug 2009 08:08:44 -0700 (PDT) Date: Sun, 16 Aug 2009 17:08:43 +0200 From: Marc UBM To: current@freebsd.org Message-Id: <20090816170843.f300d004.ubm.freebsd@gmail.com> In-Reply-To: <1618A5F5-F037-46CF-954A-38FB13BAA649@techwires.net> References: <1618A5F5-F037-46CF-954A-38FB13BAA649@techwires.net> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 16 Aug 2009 15:29:18 +0000 Cc: Subject: Re: Several reported instances of boot hangs ("still waiting for xpt_config") for hptrr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 15:08:47 -0000 On Sun, 16 Aug 2009 14:51:25 +0200 Bernhard Schmidt wrote: > Hi, > > I do have a Highpoint RocketRaid 2220 controller myself which throws > similar errors since the release of 8.0-BETA2. Tracking the commits, > I could narrow it down to r195534. > > The issue is, that htprr makes use of xpt_scan_bus() which ist no > longer available in xpt_action[_default]() when cpi->transport is > not set to one of XPORT_*. This probably affects all drivers relying > upon xpt_scan_bus() but not setting cpi->transport. > > > This patch has been tested against latest head and stable/8 with no > more issues for me. I can confirm that this patch fixes the hptrr issue for me. It would be nice if this could make it into 8.0-RELEASE ;-) Thanks a lot for tracking it down! Bye Marc From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 16:10:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 141DF106568B for ; Sun, 16 Aug 2009 16:10:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 977038FC6C for ; Sun, 16 Aug 2009 16:10:48 +0000 (UTC) Received: by fxm1 with SMTP id 1so1883991fxm.7 for ; Sun, 16 Aug 2009 09:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=1f6FQII/ZArCGzLmCN4wAZYyvNNClADTn2oY3v6gw9U=; b=ZmLtm4HumR/0v3yINzV+CyGz3q0HxFyJsQqtmJuWEGwEm5c/TjjNwMXQ0jpxIWYboq fI3lJfJcCw9c3ytHn7DRaOzGVzwQZopsjlObnezPbOsTTBltiXQPC9q3dmmTci8OGSg8 mmFH7P9FUl0q35G4u0wydUQTKiRP+QK5TeFV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jznRcjx8Wwc83WuQfE4WDqpXh4HNlgaFSWSjoFAtpyH7C9DClHkS9j1C2vGa1OpYOU VHZZF9gTnM9VinZ9tmI9sAa9g6ygwgqWg8/SObgLsMxoNocBPicbZWXkcOUqTXnHInWg GlHSCdsrsLZ3gJz/roM6GXFQoD4kAHd/TIacw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.109.138 with SMTP id j10mr330673fap.55.1250439047690; Sun, 16 Aug 2009 09:10:47 -0700 (PDT) In-Reply-To: <20090813191724.GA1499@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> <20090813191724.GA1499@plebeian.afflictions.org> Date: Sun, 16 Aug 2009 18:10:47 +0200 X-Google-Sender-Auth: 6902d06a3e30e577 Message-ID: <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> From: Attilio Rao To: Damian Gerow Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 16:10:49 -0000 2009/8/13 Damian Gerow : > Attilio Rao wrote: > : > The script does not run when resuming in graphics mode, unfortunately. > : > Try as I might, I just don't get anything. I'm not sure what exactly > : > the system is doing when it resumes, as attempts to create files on > : > the local fs seem to fail. > : > : You have to manually break in DDB for that. > : BTW, differently from GENERIC, remove WITNESS_SKIPSPIN, just in case. > > After removing WITNESS_SKIPSPIN, the ddb script works. I've included the > output from textdump below. Hans suggested to try this patch: http://p4db.freebsd.org/chv.cgi?CH=167286 Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 17:51:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DC01106568D for ; Sun, 16 Aug 2009 17:51:44 +0000 (UTC) (envelope-from freebsd@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id CC72A8FC3D for ; Sun, 16 Aug 2009 17:51:43 +0000 (UTC) Received: from xtaz.co.uk (tao.xtaz.co.uk [192.168.1.2]) by mail.xtaz.co.uk (Postfix) with ESMTP id 0AEBEB083E4 for ; Sun, 16 Aug 2009 18:51:43 +0100 (BST) MIME-Version: 1.0 Date: Sun, 16 Aug 2009 18:51:42 +0100 From: Matt Smith To: Message-ID: <5d818cc5707ff67be276f3baf1d252d7@xtaz.co.uk> X-Sender: freebsd@xtaz.co.uk User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Subject: Can't talk to local network interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 17:51:44 -0000 I have just installed a new world/kernel dated: Aug 16 09:54:34 tao kernel: FreeBSD 8.0-BETA2 #0: Sun Aug 16 03:21:18 BST 2009 I've found that since booting it I can not talk to anything using the servers own IP address locally. I can telnet ports and ping 127.0.0.1 but trying anything on 192.168.1.2 just sits there saying trying... and 100% packet loss. I can connect to 192.168.1.2 from another server on the network however. It's literally just the box looping back to itself. If I revert to this kernel: Aug 16 18:17:47 tao kernel: FreeBSD 8.0-BETA2 #0: Sat Jul 25 20:09:24 BST 2009 then everything works fine again. The interface in question is this: vr0: port 0xb000-0xb0ff mem 0xf6000000-0xf60000ff irq 16 at device 13.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x8d miibus0: on vr0 vr0: Ethernet address: 00:40:63:e8:79:3e vr0: [ITHREAD] vr0: flags=8843 metric 0 mtu 1500 options=2808 ether 00:40:63:e8:79:3e inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active I am running ipfw but the only rule loaded is the default rule which is default to accept on all interfaces. I've tried disabling the firewall with the sysctl as well and the problem persists so I don't think it's ipfw related. Regards, Matt From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 17:53:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC351065693 for ; Sun, 16 Aug 2009 17:53:03 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtai106.cox.net (fed1rmmtai106.cox.net [68.230.241.54]) by mx1.freebsd.org (Postfix) with ESMTP id 02CEF8FC5A for ; Sun, 16 Aug 2009 17:53:02 +0000 (UTC) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20090816171211.KVJB21192.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Sun, 16 Aug 2009 13:12:11 -0400 Received: from vaio ([72.220.91.251]) by fed1rmimpo01.cox.net with bizsmtp id V5CA1c00K5RPd34035CAVQ; Sun, 16 Aug 2009 13:12:10 -0400 X-VR-Score: -120.00 X-Authority-Analysis: v=1.0 c=1 a=Vja7GxIc_SS9M3zAd-cA:9 a=no2R8gG6cNU1qFaqawUwKeYRlj4A:4 X-CM-Score: 0.00 Date: Sun, 16 Aug 2009 10:12:05 -0700 From: Robert To: Collin Kreklow Message-ID: <20090816101205.514faf3e@vaio> In-Reply-To: <20090811235507.GA33894@srv.home.kreklow.us> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <20090811235507.GA33894@srv.home.kreklow.us> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 17:53:03 -0000 On Tue, 11 Aug 2009 18:55:07 -0500 Collin Kreklow wrote: > On Sat, Aug 08, 2009 at 01:41:01PM -0700, Robert wrote: > > > > The interface card is old. It shows to be a Netgear MA401. I have > > ordered a newer model of the Netgear card. It is a WG511T which is > > supposed to have an atheros chipset. I should receive this card in > > about a week. I really do not know if any of this is relevant to my > > problem. > > > > FWIW, I've found the WG511T and it's PCI sibling WG311T to be some of > the most stable wireless cards available under FreeBSD. The ath > driver is very capable with these cards. I've recently had bad > experiences with ipw, wpi, and ral based cards prompting me to pick > up a few spare 311s for my AP "just in case." I think you won't be > disappointed. > > - Collin > Collin Thanks for that tidbit. FWIW, I received two WG511T's (on Ebay for $12 US and free US shipping) in the mail this past Friday and they are both working excellent in two separate laptops with WPA. I'm sorry it took so long to respond but my ISP had locked out all of my email accounts and it took 5 calls and 3 techs to reset the master account so that I could reset the others. All is well :-) Robert From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 18:09:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4CB1065691; Sun, 16 Aug 2009 18:09:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8C78FC43; Sun, 16 Aug 2009 18:09:12 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C88AA1D0E4; Sun, 16 Aug 2009 20:09:11 +0200 (CEST) Date: Sun, 16 Aug 2009 20:09:11 +0200 From: Ed Schouten To: Andrew Gallatin Message-ID: <20090816180911.GL1292@hoeg.nl> References: <4A857D16.9070403@cs.duke.edu> <4A85B9CD.4050802@cs.duke.edu> <20090814193254.GO1884@deviant.kiev.zoral.com.ua> <4A85C325.6050400@cs.duke.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aO2SyuDEANnesPMC" Content-Disposition: inline In-Reply-To: <4A85C325.6050400@cs.duke.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-current@freebsd.org, Robert Watson Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 18:09:12 -0000 --aO2SyuDEANnesPMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andrew Gallatin wrote: > FWIW, the fix to my problem was to add D_NEEDMINOR to > my cdevsw d_flags, to restore the same behavior as FreeBSD 5/6/7 Yes. INVARIANTS should trigger a kernel panic if you use clone_create() without D_NEEDMINOR. I think you probably didn't have it enabled, which means it dies later on. --=20 Ed Schouten WWW: http://80386.nl/ --aO2SyuDEANnesPMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqIS0cACgkQ52SDGA2eCwVRTgCeOn7aUNT3MShQersORWIncRAl dFAAniBQvU4wa6g4EIqhC9egfq3W07aN =yB3y -----END PGP SIGNATURE----- --aO2SyuDEANnesPMC-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 16:59:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 526DD106568D for ; Sun, 16 Aug 2009 16:59:35 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 09AF28FC4B for ; Sun, 16 Aug 2009 16:59:34 +0000 (UTC) Received: by yxe11 with SMTP id 11so3277477yxe.3 for ; Sun, 16 Aug 2009 09:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=cELdMp1gfvlEZJrcd1i3daWBhUzJt5qFuQRN1Sr+fmc=; b=FK8ZSD2+4SE46QY8ec8xDuPHwX3WpqreLwGgsJar+BiacEmLvqh14DeN7NxgUFgOfP leG27IJU+bM9aXj27lKlJ5bebKLEFQc9XzfkazotM9qLTM+5PECjgKrihKpZOmmS8ekv 2tN46Fj+VuN0qrdNgUSezoaz3JVotu0YoBXEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=hgniqNmVFWXmCMv5aq1kJQc2IF6sP+ksvkT58eIexsyFt7eWf0rnRiBCTgNtJz+GUy mooufRMebVwyIYo38lxuQJsLsXl3lBVWcppTyKx7RyVVRmRQOK/60ubrSYSmjTwEKISw RVwKhI7QU04oGYtJNWdaxHvt2JN54ALZFzaGw= Received: by 10.90.35.7 with SMTP id i7mr244821agi.31.1250441974130; Sun, 16 Aug 2009 09:59:34 -0700 (PDT) Received: from ubm.mine.nu ([72.14.241.8]) by mx.google.com with ESMTPS id 27sm6580813agb.2.2009.08.16.09.59.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Aug 2009 09:59:33 -0700 (PDT) Date: Sun, 16 Aug 2009 18:59:30 +0200 From: Marc UBM To: current@freebsd.org Message-Id: <20090816185930.49144213.ubm.freebsd@gmail.com> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 16 Aug 2009 18:15:56 +0000 Cc: Subject: panic: _sx_xlock_hard: recursed on non-recursive sx newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 16:59:35 -0000 Hiho! :-) While loading snd_hda for fun on my fileserver, I got the following panic (crashdump available for poking around): panic: _sx_xlock_hard: recursed on non-recursive sx newbus @ /usr/src/sys/kern/subr_bus.c:219 Backtrace is attached. Bye Marc From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 18:50:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46A05106568C; Sun, 16 Aug 2009 18:50:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4CD8FC45; Sun, 16 Aug 2009 18:50:04 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A90FB46B23; Sun, 16 Aug 2009 14:50:03 -0400 (EDT) Date: Sun, 16 Aug 2009 19:50:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marc UBM In-Reply-To: <20090816185930.49144213.ubm.freebsd@gmail.com> Message-ID: References: <20090816185930.49144213.ubm.freebsd@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@FreeBSD.org, current@freebsd.org Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 18:50:04 -0000 On Sun, 16 Aug 2009, Marc UBM wrote: > While loading snd_hda for fun on my fileserver, I got the following panic > (crashdump available for poking around): > > panic: _sx_xlock_hard: recursed on non-recursive sx newbus @ > /usr/src/sys/kern/subr_bus.c:219 > > Backtrace is attached. Hi Marc-- This is most likely associated with the known "newbus" locking issues from late-break MPSAFEty work on newbus for 8.0. I understand that Attilio is working actively on fixing this (CC'd). Robert From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 19:00:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31655106568D for ; Sun, 16 Aug 2009 19:00:32 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id D2C828FC41 for ; Sun, 16 Aug 2009 19:00:31 +0000 (UTC) Received: by qyk29 with SMTP id 29so1958782qyk.3 for ; Sun, 16 Aug 2009 12:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=Qy5uZp98+eKPT8wIMsCBqnCPB4L7WYvIW6M38nCkGMI=; b=d8B+b9aKouEhyVHiyuy5XwBV41LGjcj8cl27o6Btfpbe3/bFUaLiryK4QmW7rDheCe urcsZH7UqzjVwGUOoicxaJTOiA7jMioB2I+YJDCNcdpL1Zk2FhFes7vdXPDYOsSb19GV pHnVlgmzvN//LNX8CdvI6JQbAhlFhfai6ddHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=tOG9DXy4dBYnXmjOcrEdN7JurjXz7m8R7nIka0Ham7Tkzc+wsrxK0FNepFTz0MZiSs eNtLCy1BTvtsIbOn1eJKmxb0EWyhYulj/YH2QivRGAhIP7CX2AXtylGoyUisPBFWFZde dSapDVFBB0wBh5LnjDoaMEHI3L77RcuSzfVCc= Received: by 10.224.37.198 with SMTP id y6mr3719538qad.198.1250449231126; Sun, 16 Aug 2009 12:00:31 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.85.93]) by mx.google.com with ESMTPS id 6sm7095249qwk.2.2009.08.16.12.00.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Aug 2009 12:00:29 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id B6982B80CB; Sun, 16 Aug 2009 16:00:20 -0300 (BRT) Received: from 10.1.1.100 (SquirrelMail authenticated user matheus) by lamneth with HTTP; Sun, 16 Aug 2009 16:00:20 -0300 (BRT) Message-ID: <5722ad33ffed8b9ea493f21c4f36e6ac.squirrel@lamneth> In-Reply-To: <20090814074358.GA24969@dmr.ath.cx> References: <521743b0e93ba19c3e9d0226f5de1660.squirrel@10.1.1.10> <20090814074358.GA24969@dmr.ath.cx> Date: Sun, 16 Aug 2009 16:00:20 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Update - RELENG_8 open for business (but you probably noticed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 19:00:32 -0000 On Fri, August 14, 2009 04:43, Emil Mikulic wrote: > On Thu, Aug 13, 2009 at 11:20:47PM -0300, Nenhum_de_Nos wrote: >> this change from cvs to svn may solve one of my problem of not having >> direct connection to the internet. where I work we have a proxy >> upstream, >> and just http/https goes out. this svn rep can be used right away (same >> codebase?) and does it have this feature ? how to use if so ? > > Try: http://svn.freebsd.org/base/ > >> I've seen some svn reps where svn co http://lalalalalala.caaaa/thecode >> would work great. > > I've seen some corporate proxies where this didn't work because svn uses > some of the more exotic WebDAV methods, not just plain HTTP GET. ;) > > --Emil thanks for the reply. Trying this tomorrow :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 21:21:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7020B106568B for ; Sun, 16 Aug 2009 21:21:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 5F84E8FC5A for ; Sun, 16 Aug 2009 21:21:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOH004H8NCILQ90@asmtp025.mac.com> for freebsd-current@freebsd.org; Sun, 16 Aug 2009 14:21:55 -0700 (PDT) From: Marcel Moolenaar Date: Sun, 16 Aug 2009 14:20:47 -0700 Message-id: To: FreeBSD Current X-Mailer: Apple Mail (2.1074) Subject: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 21:21:58 -0000 All, A few of my machines still can't boot successfully to multi-user: ... Trying to mount root from ufs:da0p3 Entropy harvesting: interrupts ethernet point_to_point kickstart. /dev/da0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0p3: clean, 8843098 free (98130 frags, 1093121 blocks, 0.6% fragmentation) WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 bge0: link state changed to DOWN Starting Network: lo0 bge0. bge1: link state changed to DOWN Mounting NFS file systems:mount_nfs: nfs: hostname nor servname provided, or not known . bge0: link state changed to UP Setting date via ntp. Error : hostname nor servname provided, or not known 16 Aug 14:05:51 ntpdate[644]: can't find host time.lan.xcllnt.net 16 Aug 14:05:51 ntpdate[644]: no servers can be used, exiting rpc.umntall: nfs: MOUNTPROG: RPC: Unknown host Setting NIS domain: xcllnt. Recovering vi editor sessions:. Mounting late file systems:mount_nfs: nfs: hostname nor servname provided, or not known . Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Aug 16 14:05:53 hob init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: This is an obvious regression and I don't see that this is being addressed. Am I mistaken? Yes, I can make the NFS mount continue in the background to avoid the problem, but that doesn't address the fact that we're trying to use the network before interfaces are configured... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 22:29:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1440106568C for ; Sun, 16 Aug 2009 22:29:09 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 425D48FC15 for ; Sun, 16 Aug 2009 22:29:08 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7GMT5us016949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Aug 2009 00:29:06 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Marcel Moolenaar In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 00:29:05 +0200 References: X-Mailer: Apple Mail (2.936) Cc: FreeBSD Current Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 22:29:09 -0000 Am 16.08.2009 um 23:20 schrieb Marcel Moolenaar: > All, > > A few of my machines still can't boot successfully to multi-user: > > ... > Trying to mount root from ufs:da0p3 > Entropy harvesting: interrupts ethernet point_to_point kickstart. > /dev/da0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0p3: clean, 8843098 free (98130 frags, 1093121 blocks, 0.6% > fragmentation) > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 13 > ZFS storage pool version 13 > bge0: link state changed to DOWN > Starting Network: lo0 bge0. At this point, /etc/rc.d/netif is finished. > bge1: link state changed to DOWN > Mounting NFS file systems:mount_nfs: nfs: hostname nor servname > provided, or not known > . > bge0: link state changed to UP Only now is the interface capable of forwarding packets. > Setting date via ntp. > Error : hostname nor servname provided, or not known > 16 Aug 14:05:51 ntpdate[644]: can't find host time.lan.xcllnt.net Is this a timeout, or did netif not configure all the interfaces/routes? > > 16 Aug 14:05:51 ntpdate[644]: no servers can be used, exiting > rpc.umntall: nfs: MOUNTPROG: RPC: Unknown host > Setting NIS domain: xcllnt. > Recovering vi editor sessions:. > Mounting late file systems:mount_nfs: nfs: hostname nor servname > provided, or not known > . > Mounting /etc/fstab filesystems failed, startup aborted > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > Aug 16 14:05:53 hob init: /bin/sh on /etc/rc terminated abnormally, > going to single user mode > Enter full pathname of shell or RETURN for /bin/sh: > > > This is an obvious regression and I don't see that this is being > addressed. Am I mistaken? Maybe not everyone is seeing this? I certainly have no problems bringing up interfaces in time for ntpdate to work, or nfs mounts to succeed. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sun Aug 16 22:41:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382E3106568E for ; Sun, 16 Aug 2009 22:41:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 245B88FC64 for ; Sun, 16 Aug 2009 22:41:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOH00CBRR1MJI30@asmtp025.mac.com> for freebsd-current@freebsd.org; Sun, 16 Aug 2009 15:41:46 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sun, 16 Aug 2009 15:41:45 -0700 Message-id: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> References: To: Stefan Bethke X-Mailer: Apple Mail (2.1074) Cc: FreeBSD Current Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 22:41:47 -0000 On Aug 16, 2009, at 3:29 PM, Stefan Bethke wrote: > At this point, /etc/rc.d/netif is finished. I presume dhclient has been started at this time. > >> bge1: link state changed to DOWN >> Mounting NFS file systems:mount_nfs: nfs: hostname nor servname >> provided, or not known >> . >> bge0: link state changed to UP > > Only now is the interface capable of forwarding packets. Which means that dhclient is only now able to obtain a network address. > >> Setting date via ntp. >> Error : hostname nor servname provided, or not known >> 16 Aug 14:05:51 ntpdate[644]: can't find host time.lan.xcllnt.net > > Is this a timeout, or did netif not configure all the interfaces/ > routes? Interfaces/routes have not been configured yet, because dhclient isn't finished yet. >> This is an obvious regression and I don't see that this is being >> addressed. Am I mistaken? > > Maybe not everyone is seeing this? I certainly have no problems > bringing up interfaces in time for ntpdate to work, or nfs mounts to > succeed. I don't see it on all machines, even though they use DHCP. I think the problem relates to how long it takes for the (primary) interface to become up. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 00:32:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2634A106568C for ; Mon, 17 Aug 2009 00:32:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f227.google.com (mail-gx0-f227.google.com [209.85.217.227]) by mx1.freebsd.org (Postfix) with ESMTP id D468D8FC4B for ; Mon, 17 Aug 2009 00:32:26 +0000 (UTC) Received: by gxk27 with SMTP id 27so3407485gxk.12 for ; Sun, 16 Aug 2009 17:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=gIiZdqej+ZJA8QlrVnHPeZeo0whq9VwiZYu0XwMiwuw=; b=DdXfdYMP0GiJj0i8czxOR1SIIDv6iL5Q5n5HThThFSBlmry4u3Q+RaEG5g2r9gCMBB qZtv9agd8T2cWUrv+QFj6BNnY0UdqKBRe89nX0tgn1NloiEe1spnqjzYra42BEV8lOSp Br8H8EeCPM7cJ2sZhmQX1aCbomjfqCtVs/0rU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ffJiwTzM0IBKj+trRqL7Po0IQl97ixzfTyg40ZS+st0cQvo2AHr3T4NiXCCwyzrUFR 81TOH6TzBqJu8ZsL6QSJIoPyTk48HXDR2TRbAxB2G4JYZxev2kjQNTVqvym4sTNydogQ OCTXAucJWv4DnWonh4iKsMvHqXC7Smo/bKbAM= MIME-Version: 1.0 Received: by 10.150.150.4 with SMTP id x4mr4965842ybd.38.1250469146098; Sun, 16 Aug 2009 17:32:26 -0700 (PDT) In-Reply-To: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> Date: Sun, 16 Aug 2009 17:32:26 -0700 Message-ID: From: Freddie Cash To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 00:32:27 -0000 On Sun, Aug 16, 2009 at 3:41 PM, Marcel Moolenaar wrote: > On Aug 16, 2009, at 3:29 PM, Stefan Bethke wrote: > >> At this point, /etc/rc.d/netif is finished. >> > > I presume dhclient has been started at this time. > >> bge1: link state changed to DOWN >>> Mounting NFS file systems:mount_nfs: nfs: hostname nor servname provided, >>> or not known >>> . >>> bge0: link state changed to UP >>> >> >> Only now is the interface capable of forwarding packets. >> > > Which means that dhclient is only now able to obtain a > network address. > I've seen this on FreeBSD 6.1-6.3, and 7.0-7.2. It depends on the NIC. fxp(4) and xl(4) appear to be ready as soon as the interface is brought up by /etc/rc.d/netif. em(4) seems to need 3-10 seconds to negotiate a link with the other end of the ethernet cable (regardless of whether it is another NIC or a switch port). For a 10/100 link, it only takes 2-3 seconds to get the link, so things continue as normal. For a 1000 link, it takes up to 10 seconds. I've worked around this on our firewalls by adding a 10-second sleep to /etc/rc.d/netif, to allow the physical link to come up. Haven't had any issues with bge(4) or bce(4) either, although are only used in testing, not in production. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 02:40:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DAD106568F for ; Mon, 17 Aug 2009 02:40:30 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 924E58FC6C for ; Mon, 17 Aug 2009 02:40:30 +0000 (UTC) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 9455679003; Mon, 17 Aug 2009 06:40:28 +0400 (MSD) Message-ID: <4A88C31C.70204@haruhiism.net> Date: Mon, 17 Aug 2009 06:40:28 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Marcel Moolenaar References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> In-Reply-To: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Stefan Bethke Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 02:40:30 -0000 Marcel Moolenaar wrote: >>> bge1: link state changed to DOWN >>> Mounting NFS file systems:mount_nfs: nfs: hostname nor servname >>> provided, or not known >>> bge0: link state changed to UP >> Only now is the interface capable of forwarding packets. > Which means that dhclient is only now able to obtain a > network address. (snip) > > I don't see it on all machines, even though they use DHCP. > I think the problem relates to how long it takes for the > (primary) interface to become up. This happens for me with some interfaces (namely, bge and em) as well; media state is detected with a slight delay and therefore by the time ntpdate is started we don't have an IP address yet. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 02:58:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A73F106568B for ; Mon, 17 Aug 2009 02:58:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 302B38FC15 for ; Mon, 17 Aug 2009 02:58:29 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id n7H2wTsO081487; Sun, 16 Aug 2009 19:58:29 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id n7H2wTet081486; Sun, 16 Aug 2009 19:58:29 -0700 (PDT) (envelope-from david) Date: Sun, 16 Aug 2009 19:58:29 -0700 From: David Wolfskill To: Kamigishi Rei Message-ID: <20090817025829.GH74242@bunrab.catwhisker.org> References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> <4A88C31C.70204@haruhiism.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqCDj3hiknadvR6t" Content-Disposition: inline In-Reply-To: <4A88C31C.70204@haruhiism.net> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 02:58:30 -0000 --AqCDj3hiknadvR6t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2009 at 06:40:28AM +0400, Kamigishi Rei wrote: > ... > This happens for me with some interfaces (namely, bge and em) as well;=20 > media state is detected with a slight delay and therefore by the time=20 > ntpdate is started we don't have an IP address yet. > ... Perhaps it might be appropriate to ensure that we have an IP address before starting ntpd, then? As far as the actual check, examining the output of "netstat -nif inet" or "netstat -nif inet6" is generally what I'd normally do. Possibilities that come to mind: * Modify rc.d/netif to ensure that an IP address is assigned before it exits (assuming(!) that at least one interface has come up. * Modify rc.d/ntpd to ensure that an IP address is assigned before it tries to start ntpd(8). * Create a new rc.d script that sleeps until an IP address is assigned. I think the latter would be most flexible, as the appropriate keywords could be specified for precisely those rc.d/* scripts that actually need an IP address in order to function, though implementing it might engender rather more churn in /etc/rc.d/* than folks might prefer. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --AqCDj3hiknadvR6t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkqIx1QACgkQmprOCmdXAD3xEgCcC0X76qfyXZIP4JTP6pdhwam9 00kAmwdbJnW+kAkG+zXlaey9+BNMyywR =BdY8 -----END PGP SIGNATURE----- --AqCDj3hiknadvR6t-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 03:37:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406DF106568B for ; Mon, 17 Aug 2009 03:37:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C25208FC41 for ; Mon, 17 Aug 2009 03:37:31 +0000 (UTC) Received: (qmail 7052 invoked by uid 399); 17 Aug 2009 03:37:25 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Aug 2009 03:37:25 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A88D06F.2000408@FreeBSD.org> Date: Sun, 16 Aug 2009 20:37:19 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: David Wolfskill References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> <4A88C31C.70204@haruhiism.net> <20090817025829.GH74242@bunrab.catwhisker.org> In-Reply-To: <20090817025829.GH74242@bunrab.catwhisker.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 03:37:32 -0000 David Wolfskill wrote: > * Create a new rc.d script that sleeps until an IP address is assigned. > > I think the latter would be most flexible, as the appropriate keywords > could be specified for precisely those rc.d/* scripts that actually need > an IP address in order to function, though implementing it might > engender rather more churn in /etc/rc.d/* than folks might prefer. This is definitely the preferred solution, and has been discussed in the past on the rc.d list. One way to implement this would be to specify a default address to ping, and make it overridable, similar to how I did the named_wait feature. Bonus points if the user has ntpd enabled and we can pick one of the server lines from ntp.conf at random. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 05:23:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C02E106568C for ; Mon, 17 Aug 2009 05:23:30 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id 93B1F8FC5A for ; Mon, 17 Aug 2009 05:23:29 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1Mcu7W-0000ht-K0 for freebsd-current@freebsd.org; Mon, 17 Aug 2009 06:46:58 +0200 Received: from ip59935289.rubicom.hu ([89.147.82.137] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1Mcu7W-0000hm-EC for freebsd-current@freebsd.org; Mon, 17 Aug 2009 06:46:58 +0200 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3) with ESMTP id n7H4kw86001955 for ; Mon, 17 Aug 2009 06:46:58 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3/Submit) id n7H4kwLT001954 for freebsd-current@freebsd.org; Mon, 17 Aug 2009 06:46:58 +0200 (CEST) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Mon, 17 Aug 2009 06:46:58 +0200 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20090817044658.GA1504@baranyfelhocske.buza.adamsfamily.xx> References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> <4A88C31C.70204@haruhiism.net> <20090817025829.GH74242@bunrab.catwhisker.org> <4A88D06F.2000408@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A88D06F.2000408@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 05:23:30 -0000 On Sun, Aug 16, 2009 at 08:37:19PM -0700, Doug Barton wrote: > David Wolfskill wrote: > > > * Create a new rc.d script that sleeps until an IP address is assigned. > > > > I think the latter would be most flexible, as the appropriate keywords > > could be specified for precisely those rc.d/* scripts that actually need > > an IP address in order to function, though implementing it might > > engender rather more churn in /etc/rc.d/* than folks might prefer. > > This is definitely the preferred solution, and has been discussed in > the past on the rc.d list. Well, this would probably cover the story of DHCP + slow media change detection (or just plain slow DHCP). However, there are similar (and way worse) problems if you are using a machine with a wlan interface, even without DHCP. In this case, an IP address is immediately assigned as soon as the wlanX interface is created, but that does not mean that traffic can flow. In my case, getting an association with an iwi(4) card lasts about 15-25 seconds. True, NTPD does not exit because an IP address is configured, but the spamming that it (and stuff like sendmail) produce on the console bears witness to the fact that they are not prepared to handle this situation... I will not even start to imagine what happens if I add a DHCP server into this mix... > One way to implement this would be to specify a default address to > ping, and make it overridable, similar to how I did the named_wait > feature. Bonus points if the user has ntpd enabled and we can pick one > of the server lines from ntp.conf at random. This, however, would be a much better solution, because it would also cover slow wireless. -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 05:47:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C85D106568B for ; Mon, 17 Aug 2009 05:47:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id E9E218FC43 for ; Mon, 17 Aug 2009 05:47:54 +0000 (UTC) Received: (qmail 3151 invoked by uid 399); 17 Aug 2009 05:47:52 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Aug 2009 05:47:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A88EF03.3000507@FreeBSD.org> Date: Sun, 16 Aug 2009 22:47:47 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Szilveszter Adam References: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> <4A88C31C.70204@haruhiism.net> <20090817025829.GH74242@bunrab.catwhisker.org> <4A88D06F.2000408@FreeBSD.org> <20090817044658.GA1504@baranyfelhocske.buza.adamsfamily.xx> In-Reply-To: <20090817044658.GA1504@baranyfelhocske.buza.adamsfamily.xx> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 05:47:55 -0000 Szilveszter Adam wrote: > On Sun, Aug 16, 2009 at 08:37:19PM -0700, Doug Barton wrote: >> David Wolfskill wrote: >> >>> * Create a new rc.d script that sleeps until an IP address is assigned. >>> >>> I think the latter would be most flexible, as the appropriate keywords >>> could be specified for precisely those rc.d/* scripts that actually need >>> an IP address in order to function, though implementing it might >>> engender rather more churn in /etc/rc.d/* than folks might prefer. >> This is definitely the preferred solution, and has been discussed in >> the past on the rc.d list. > > Well, this would probably cover the story of DHCP + slow media change > detection (or just plain slow DHCP). However, there are similar (and way > worse) problems if you are using a machine with a wlan interface, even > without DHCP. In this case, an IP address is immediately assigned as > soon as the wlanX interface is created, but that does not mean that > traffic can flow. In my case, getting an association with an iwi(4) card > lasts about 15-25 seconds. True, NTPD does not exit because an IP > address is configured, but the spamming that it (and stuff like > sendmail) produce on the console bears witness to the fact that they are > not prepared to handle this situation... I will not even start to imagine > what happens if I add a DHCP server into this mix... > >> One way to implement this would be to specify a default address to >> ping, and make it overridable, similar to how I did the named_wait >> feature. Bonus points if the user has ntpd enabled and we can pick one >> of the server lines from ntp.conf at random. > > This, however, would be a much better solution, because it would also > cover slow wireless. Yes, I agree that merely detecting the presence of an IP address is not enough. David actually had a good idea regarding having the default ping address be the gateway, which I think is a much better default. That should be enough for most people, those who need something more specific can specify it as an option. Anyone want to take this project on? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 06:31:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96891106568D for ; Mon, 17 Aug 2009 06:31:50 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 155F98FC59 for ; Mon, 17 Aug 2009 06:31:49 +0000 (UTC) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 251713369; Mon, 17 Aug 2009 09:31:46 +0300 Message-ID: <4A88F912.1050308@FreeBSD.org> Date: Mon, 17 Aug 2009 09:30:42 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Ilya Zhuravlev References: <4A4517BE.9040504@FreeBSD.org> <4A6EBAFC.6090800@cbtnet.ru> <4A709323.6050001@FreeBSD.org> <4A7AB52B.5000300@cbtnet.ru> <4A7AEF07.2040906@FreeBSD.org> <4A8406E1.5070905@cbtnet.ru> <4A84470B.6040507@FreeBSD.org> <4A88CFE8.3000005@cbtnet.ru> In-Reply-To: <4A88CFE8.3000005@cbtnet.ru> Content-Type: multipart/mixed; boundary="------------040203010404030101080705" Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 06:31:50 -0000 This is a multi-part message in MIME format. --------------040203010404030101080705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ilya Zhuravlev wrote: > Alexander Motin пишет: >> Ilya Zhuravlev wrote: >>> Alexander Motin wrote: >>>> Ilya Zhuravlev wrote: >>>>> Alexander Motin wrote: >>>>>> Ilya Zhuravlev wrote: >>>>>>> ahci cannot attach drives >>>>>>> 8.0-beta2, laptop asus k50in, nvidia MCP75L-based >>>>>>> >>>>>>> ahci0: [THREAD] >>>>>>> ahci0: AHCI v1.20 with 2 3Gbps ports, Port Multiplier supported >>>>>>> ahcich0: at channel 0 on ahci0 >>>>>>> ahcich0: [THREAD] >>>>>>> ahcich1: at channel 1 on ahci0 >>>>>>> ahcich1: [THREAD] >>>>>>> ...... >>>>>>> (aprobe0:ahcich0:0:15:0): SIGNATURE: 0000 >>>>>>> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 >>>>>>> (aprobe0:ahcich0:0:0:0): Uncorrected Parity Error >>>>>>> (aprobe0:ahcich0:0:0:0): Retrying Command >>>>>>> (aprobe0:ahcich0:0:0:0): Uncoreccted Parity Error >>>>>>> (aprobe0:ahcich0:0:0:0): error 5 >>>>>>> (aprobe0:ahcich0:0:0:0): Retries Exhausted >>>>>>> (aprobe1:ahcich1:0:15:0): SIGNATURE: eb14 >>>>>>> (aprobe0:ahcich1:0:0:0): SIGNATURE: eb14 >>>>>>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>>>>>> (aprobe0:ahcich1:0:0:0): Retrying Command >>>>>>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>>>>>> (aprobe0:ahcich1:0:0:0): error 5 >>>>>>> (aprobe0:ahcich1:0:0:0): Retries Exhausted >>>>>>> >>>>>> Try please to uncomment device_printf() lines inside ahci_ch_intr() >>>>>> function. It could give some ideas about what's going on there. >>>>>> >>>>> Sorry for long delay. >>>>> boot -v, pciconf attached >>>> >>>> I don't see that you've uncommented >>>> //device_printf(dev, "%s ERROR is %08x cs %08x... >>>> lines in ahci_ch_intr() and rebuilt kernel as I've said. >>>> >>> Ehm, sorry, svn upping after edit was bad idea >> > Or some additional changes were missed by me? I have meant simple 4-line patch, attached here. -- Alexander Motin --------------040203010404030101080705 Content-Type: text/plain; name="xfer.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="xfer.patch" LS0tIGF0YV94cHQuYwkyMDA5LTA3LTE0IDAwOjIxOjE2LjAwMDAwMDAwMCArMDMwMAorKysg YXRhX3hwdC5jCTIwMDktMDgtMTAgMDA6Mzg6MDMuMDAwMDAwMDAwICswMzAwCkBAIC0zNzAs MTAgKzM0NCwxMCBAQCBwcm9iZXN0YXJ0KHN0cnVjdCBjYW1fcGVyaXBoICpwZXJpcGgsIHVu CiAJCWNhbV9maWxsX2F0YWlvKGF0YWlvLAogCQkgICAgICAxLAogCQkgICAgICBwcm9iZWRv bmUsCi0JCSAgICAgIC8qZmxhZ3MqL0NBTV9ESVJfSU4sCi0JCSAgICAgIE1TR19TSU1QTEVf UV9UQUcsCi0JCSAgICAgIC8qZGF0YV9wdHIqLyh1X2ludDhfdCAqKWlkZW50X2J1ZiwKLQkJ ICAgICAgLypkeGZlcl9sZW4qL3NpemVvZihzdHJ1Y3QgYXRhX3BhcmFtcyksCisJCSAgICAg IC8qZmxhZ3MqL0NBTV9ESVJfTk9ORSwKKwkJICAgICAgMCwKKwkJICAgICAgLypkYXRhX3B0 ciovTlVMTCwKKwkJICAgICAgLypkeGZlcl9sZW4qLzAsCiAJCSAgICAgIDMwICogMTAwMCk7 CiAJCWF0YV8zNmJpdF9jbWQoYXRhaW8sIEFUQV9TRVRGRUFUVVJFUywgQVRBX1NGX1NFVFhG RVIsIDAsCiAJCSAgICBhdGFfbWF4X21vZGUoaWRlbnRfYnVmLCBBVEFfVURNQTYsIEFUQV9V RE1BNikpOwo= --------------040203010404030101080705-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 08:19:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49D74106568E for ; Mon, 17 Aug 2009 08:19:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.tele2.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id D4DBB8FC51 for ; Mon, 17 Aug 2009 08:19:41 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=ylFMtTpzSNTu0OfOyC0A:9 a=kmst0aUsRWAuG2unrSFrThVcC_8A:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 551451318; Mon, 17 Aug 2009 09:19:38 +0200 From: Hans Petter Selasky To: Deniz , current@freebsd.org Date: Mon, 17 Aug 2009 09:19:46 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <791271c80908151025k344d906ar17cc585ae70927c7@mail.gmail.com> <200908152139.02493.hselasky@c2i.net> <791271c80908151621g4aec8548mc64e7c3f43f666ff@mail.gmail.com> In-Reply-To: <791271c80908151621g4aec8548mc64e7c3f43f666ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908170919.47870.hselasky@c2i.net> Cc: Subject: Re: unable to mount root from USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 08:19:42 -0000 Hi, I suspect that your problem might have something to do with suspend/resume support. Assuming your device is High Speed, could you edit: /sys/dev/usb/controller/ehci.c and find the function: ehci_set_hw_power() There you change: if (flags & (USB_HW_POWER_CONTROL | USB_HW_POWER_BULK)) { DPRINTF("Async is active\n"); temp |= EHCI_CMD_ASE; } if (flags & (USB_HW_POWER_INTERRUPT | USB_HW_POWER_ISOC)) { DPRINTF("Periodic is active\n"); temp |= EHCI_CMD_PSE; } Into: if (1) { DPRINTF("Async is active\n"); temp |= EHCI_CMD_ASE; } if (1) { DPRINTF("Periodic is active\n"); temp |= EHCI_CMD_PSE; } Lookup ohci_set_hw_power() and uhci_set_hw_power() and patch likewise. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 12:38:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97B7B106568F for ; Mon, 17 Aug 2009 12:38:01 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 58D7C8FC16 for ; Mon, 17 Aug 2009 12:38:01 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n7HCbbwh016480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 08:37:37 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n7HCbbwh016480 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1250512657; bh=FUoSwe4mJLTItv0MG3GurBxqa10gqEp/mh1usaMziks=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pfjro2ckZJVCZQUZGMHMqhWE1BiPuxf/4wYyvQ1h0uItRqduIPr2sc93qdUgx57kZ JABBMUEavqdye95hn/Pja6iC2p/fNaEoTvh8AEDNGd1vxr4nqXNzBbQrhPh+0C97Z2 UXAQ2GR3ZcwwUo4T4e69wJnCtFE+jf85DhmuxWlk= Message-ID: <4A894F0B.3080606@cs.duke.edu> Date: Mon, 17 Aug 2009 08:37:31 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ed Schouten References: <4A857D16.9070403@cs.duke.edu> <4A85B9CD.4050802@cs.duke.edu> <20090814193254.GO1884@deviant.kiev.zoral.com.ua> <4A85C325.6050400@cs.duke.edu> <20090816180911.GL1292@hoeg.nl> In-Reply-To: <20090816180911.GL1292@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 12:38:01 -0000 Ed Schouten wrote: > * Andrew Gallatin wrote: >> FWIW, the fix to my problem was to add D_NEEDMINOR to >> my cdevsw d_flags, to restore the same behavior as FreeBSD 5/6/7 > > Yes. INVARIANTS should trigger a kernel panic if you use clone_create() > without D_NEEDMINOR. I think you probably didn't have it enabled, which > means it dies later on. > No, I didn't have INVARIANTS compiled in, I probably should have. Is there any reason you don't just |= in D_NEEDMINOR on first use of clone_create()? By adding the requirement of this flag, you've gratuitously broken any 3rd party driver using clones, which has used the same API unchanged since 5.x Drew From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 13:26:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 356B2106568B; Mon, 17 Aug 2009 13:26:52 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id BCC888FC16; Mon, 17 Aug 2009 13:26:51 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:40645 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Md2Dk-0005JI-55; Mon, 17 Aug 2009 15:25:59 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id A3A6E3B1E1; Mon, 17 Aug 2009 15:25:54 +0200 (CEST) Message-Id: From: Thomas Backman To: Pawel Dawidek Jakub Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 15:25:52 +0200 X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1Md2Dk-0005JI-55. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Md2Dk-0005JI-55 b99d288f8010ca88187b82835b28a14a Cc: FreeBSD current Subject: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 13:26:52 -0000 So, I've got myself a source tree almost completely free of patches after today's batch of ZFS patches merged - all that remains is that I uncommented ps -axl from /usr/sbin/crashinfo, since it only coredumps anyway, and added CFLAGS+=-DDEBUG=1 to zfs/Makefile. One of the changes I didn't already have prior to this must have broken something, though, because this script worked just fine before the merges earlier today. The script below is the exact same I linked in http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html back in July (URL to the script: http://exscape.org/temp/zfs_clone_panic.sh ) - I made some local changes, thus the name invoked below. Now that all the patches are merged, you should need nothing but the script, bash, and the ~200MB free space on the partition containing / root/ to reproduce this problem. (Note that the "no such pool" in the FIRST script is normal; it simply tries to clean up something that isn't there, without error/sanity checking.) [root@chaos ~]# bash -x panic-tests/CLONE_CRASH.submitted.sh initial + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/ local/bin:/root/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ local/sbin + MASTERPATH=/root/zfsclonecrash/crashtestmaster.disk + SLAVEPATH=/root/zfsclonecrash/crashtestslave.disk + LASTBACKUP=/root/zfsclonecrash/last-backup-name + MASTERNUM=1482 + SLAVENUM=1675 + '[' '!' -z initial ']' + case $1 in + initial ++ dirname /root/zfsclonecrash/crashtestmaster.disk + mkdir -p /root/zfsclonecrash + rm -rf /crashtestmaster /crashtestslave + mount_unmount unmount + '[' -z unmount ']' + [[ unmount == \m\o\u\n\t ]] + [[ unmount == \u\n\m\o\u\n\t ]] + zpool export crashtestmaster cannot open 'crashtestmaster': no such pool + ggatel destroy -u 1482 + zpool export crashtestslave cannot open 'crashtestslave': no such pool + ggatel destroy -u 1675 + echo Creating files and syncing Creating files and syncing + dd if=/dev/zero of=/root/zfsclonecrash/crashtestmaster.disk bs=1000k count=100 100+0 records in 100+0 records out 102400000 bytes transferred in 0.367217 secs (278854144 bytes/sec) + dd if=/dev/zero of=/root/zfsclonecrash/crashtestslave.disk bs=1000k count=100 100+0 records in 100+0 records out 102400000 bytes transferred in 0.286532 secs (357377280 bytes/sec) + sync + echo Sleeping 5 seconds Sleeping 5 seconds + sleep 5 + echo 'Creating GEOM providers (~10 secs)' Creating GEOM providers (~10 secs) + ggatel create -u 1482 /root/zfsclonecrash/crashtestmaster.disk + sleep 5 + ggatel create -u 1675 /root/zfsclonecrash/crashtestslave.disk + sleep 5 + echo 'Creating pools' Creating pools + zpool create -f crashtestmaster ggate1482 + zpool create -f crashtestslave ggate1675 + echo 'Adding some data to the master pool' Adding some data to the master pool + zfs create crashtestmaster/test_orig + dd if=/dev/random of=/crashtestmaster/test_orig/file1 bs=1000k count=10 10+0 records in 10+0 records out 10240000 bytes transferred in 0.447472 secs (22884109 bytes/sec) + dd if=/dev/random of=/crashtestmaster/test_orig/file2 bs=1000k count=10 10+0 records in 10+0 records out 10240000 bytes transferred in 0.626774 secs (16337625 bytes/sec) + echo 'Cloning test_base' Cloning test_base + zfs snapshot crashtestmaster/test_orig@snap + zfs clone crashtestmaster/test_orig@snap crashtestmaster/test_cloned + zfs promote crashtestmaster/test_cloned ++ date +backup-%Y%m%d-%H%M%S + NOW=backup-20090817-151412 + echo 'Creating snapshots' Creating snapshots + zfs snapshot -r crashtestmaster@backup-20090817-151412 + echo 'Doing initial clone to slave pool' Doing initial clone to slave pool + zfs send -R crashtestmaster@backup-20090817-151412 + zfs recv -vFd crashtestslave cannot receive: invalid stream (malformed nvlist) warning: cannot send 'crashtestmaster/test_cloned@snap': Broken pipe warning: cannot send 'crashtestmaster/ test_cloned@backup-20090817-151412': Broken pipe + mount_unmount unmount + '[' -z unmount ']' + [[ unmount == \m\o\u\n\t ]] + [[ unmount == \u\n\m\o\u\n\t ]] + zpool export crashtestmaster + ggatel destroy -u 1482 + zpool export crashtestslave + ggatel destroy -u 1675 + echo backup-20090817-151412 + echo 'Done!' Done! + exit 0 I first noticed this after trying to make an incremental backup right after the installworld+reboot, as I always do; it didn't find the slave zpool to import...(! This may be very bad in real-life cases - I have no clue if ggate is the culprit or if people will soon start reporting lost pools.) So I tried wiping the backup and creating a new one from scratch (~15GB over the network), giving me the very same problem, instantly: [...] + zpool create -f -R /slave slave ggate666 ++ date +backup-%Y%m%d-%H%M + NOW=backup-20090817-1522 + echo 'Creating snapshots' Creating snapshots + zfs snapshot -r tank@backup-20090817-1522 + echo 'Cloning pool' Cloning pool + zfs send -R tank@backup-20090817-1522 + zfs recv -vFd slave cannot receive: invalid stream (malformed nvlist) warning: cannot send 'tank@backup-20090817-1522': Broken pipe Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 13:58:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04760106568B; Mon, 17 Aug 2009 13:58:03 +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 B94768FC45; Mon, 17 Aug 2009 13:58:02 +0000 (UTC) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Md2if-0004dq-M7; Mon, 17 Aug 2009 14:58:01 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1Md2ie-0004UL-UR; Mon, 17 Aug 2009 14:57:53 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n7HDvqQO073509; Mon, 17 Aug 2009 14:57:52 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n7HDvqTM073508; Mon, 17 Aug 2009 14:57:52 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Mon, 17 Aug 2009 14:57:52 +0100 From: Anton Shterenlikht To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -4.1 X-Spam-Level: ---- Cc: Subject: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 13:58:03 -0000 Ports lang/gcc43, 44 and 45 fail to build on 8.0-beta2 ia64: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 I know they build fine on 6.4-stable alpha, but what about sparc64? amd64? mips? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:01:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C8B106568C for ; Mon, 17 Aug 2009 14:01:09 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 7851A8FC43 for ; Mon, 17 Aug 2009 14:01:08 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n7HDStRg016021; Mon, 17 Aug 2009 14:28:55 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Md2Gd-0007g0-Iy; Mon, 17 Aug 2009 14:28:55 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n7HDStR7034484; Mon, 17 Aug 2009 14:28:55 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n7HDStr1034483; Mon, 17 Aug 2009 14:28:55 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Alexey Tarasov In-Reply-To: References: <4A858F5C.5060500@haruhiism.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 17 Aug 2009 14:28:54 +0100 Message-Id: <1250515734.32945.18.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: current@freebsd.org Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:01:09 -0000 On Sat, 2009-08-15 at 10:54 +0400, Alexey Tarasov wrote: > Hello. > Here is core.txt: > http://lexasoft.ru/metamphetamine/Panic/core.txt.0 > > 'All versions' means all versions before and including 7-STABLE. > This servers were used before on Linux. There were no problems. This is odd. For the bug to have existed since 6.0 without being seen before, and given you are seeing this issue across 30 servers, it suggests that this may be triggered by something unusual in your setup. Are you doing anything unusual on these machines? For example, strange NFS mount options, unusual filesystems mounted, or anything? Are you using jails or similar? Is there anything else you can think of that you may be doing on these servers that is in any way unusual? Do you know if the panics seen on 6.x are the same as the panics seen on 7.x? There's always a chance you're seeing entirely different problems. Also, in the first email in this thread, you posted some pictures of the debugger output, but there isn't actually a photo of the panic text itself. Is there any chance you still have this information? Lastly, if you still have the kernel that was running during the first panic, can you do the following please: objdump -t /usr/obj/usr/src/sys/GENERIC/kernel | grep witness_lock there should be one ".text" entry for "witness_lock". Add 0x1c7 to it, then: addr2line -e /usr/obj/usr/src/sys/GENERIC/kernel 0xADDRESS (with address replaced by what you calculated above). Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:16:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CDFC10656B5 for ; Mon, 17 Aug 2009 14:16:32 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 18B828FC61 for ; Mon, 17 Aug 2009 14:16:31 +0000 (UTC) Received: by bwz19 with SMTP id 19so3175182bwz.37 for ; Mon, 17 Aug 2009 07:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=6YMvLBYC9KYDnchykv0+f9Fz3acE5B3MXA0P7vA1GW4=; b=wNIultjVIVzLIT2O7D05FFnr9zI2pjh7f+uRBcGMoH7DWA/i3S6elSjTRZ6RO4AIO7 PqXNamlOwmnbRhpiL9PEkBC39piOUPz/V35i+BE+xl1qqk8ubGvgDgXg7VUr74ozlUiV CC5ogHqoMmJPIStSiCpg0+M4/SevoV7gVuORo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xz1L9IrTZRm3pd7GUgJeOn7wQNvTWREGw93TGFuVk7HGET3z2ponmNahId0r0pdQx3 VtnpV6gDIZrH0aBya1sww/cJg9s0eayHX/OOzBbh3oL0EwO4g6ZfcmjIPreBIXVe3Ygu ByAMzDUlXJ9K1QLCFCBuo6FnZB+UMyljmGj5E= MIME-Version: 1.0 Received: by 10.204.2.205 with SMTP id 13mr2724897bkk.205.1250517329972; Mon, 17 Aug 2009 06:55:29 -0700 (PDT) Date: Mon, 17 Aug 2009 15:55:29 +0200 Message-ID: From: Pascal Hofstee To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: mfutil causes RELENG_8 breakage ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:16:32 -0000 I just installed a fresh 8.0-BETA2 ... and updated my source-tree to RELENG_8 a buildworld seems to bail out with the following message. If i noticed correctlly the mfiutil commit went in earlier today, so i am assuming something is probably missing an INCLUDE-path somewhere ? ===> usr.sbin/mfiutil (depend) rm -f .depend mkdep -f .depend -a /usr/src/usr.sbin/mfiutil/mfiutil.c /usr/src/usr.sbin/mfiutil/mfi_cmd.c /usr/src/usr.sbin/mfiutil/mfi_config.c /usr/src/usr.sbin/mfiutil/mfi_drive.c /usr/src/usr.sbin/mfiutil/mfi_evt.c /usr/src/usr.sbin/mfiutil/mfi_flash.c /usr/src/usr.sbin/mfiutil/mfi_patrol.c /usr/src/usr.sbin/mfiutil/mfi_show.c /usr/src/usr.sbin/mfiutil/mfi_volume.c In file included from /usr/src/usr.sbin/mfiutil/mfiutil.c:38: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_cmd.c:45: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory /usr/src/usr.sbin/mfiutil/mfi_cmd.c:46:31: error: dev/mfi/mfi_ioctl.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_config.c:46: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_drive.c:44: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_evt.c:41: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_flash.c:41: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_patrol.c:40: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_show.c:40: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory In file included from /usr/src/usr.sbin/mfiutil/mfi_volume.c:40: /usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.sbin/mfiutil. *** Error code 1 -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:19:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBBED106568B for ; Mon, 17 Aug 2009 14:19:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 99CED8FC59 for ; Mon, 17 Aug 2009 14:19:33 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n7HEGObK087789; Mon, 17 Aug 2009 10:16:24 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200908171416.n7HEGObK087789@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Aug 2009 10:19:38 -0400 To: Pascal Hofstee , FreeBSD Current From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: mfutil causes RELENG_8 breakage ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:19:33 -0000 At 09:55 AM 8/17/2009, Pascal Hofstee wrote: >I just installed a fresh 8.0-BETA2 ... and updated my source-tree to >RELENG_8 a buildworld seems to bail out with the following message. >If i noticed correctlly the mfiutil commit went in earlier today, so i >am assuming something is probably missing an INCLUDE-path somewhere ? I noticed the same thing. I think http://lists.freebsd.org/pipermail/svn-src-stable-8/2009-August/000069.html fixes it ---Mike >===> usr.sbin/mfiutil (depend) >rm -f .depend >mkdep -f .depend -a /usr/src/usr.sbin/mfiutil/mfiutil.c >/usr/src/usr.sbin/mfiutil/mfi_cmd.c >/usr/src/usr.sbin/mfiutil/mfi_config.c >/usr/src/usr.sbin/mfiutil/mfi_drive.c >/usr/src/usr.sbin/mfiutil/mfi_evt.c >/usr/src/usr.sbin/mfiutil/mfi_flash.c >/usr/src/usr.sbin/mfiutil/mfi_patrol.c >/usr/src/usr.sbin/mfiutil/mfi_show.c >/usr/src/usr.sbin/mfiutil/mfi_volume.c >In file included from /usr/src/usr.sbin/mfiutil/mfiutil.c:38: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_cmd.c:45: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >/usr/src/usr.sbin/mfiutil/mfi_cmd.c:46:31: error: dev/mfi/mfi_ioctl.h: >No such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_config.c:46: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_drive.c:44: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_evt.c:41: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_flash.c:41: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_patrol.c:40: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_show.c:40: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >In file included from /usr/src/usr.sbin/mfiutil/mfi_volume.c:40: >/usr/src/usr.sbin/mfiutil/mfiutil.h:38:28: error: dev/mfi/mfireg.h: No >such file or directory >mkdep: compile failed >*** Error code 1 > >Stop in /usr/src/usr.sbin/mfiutil. >*** Error code 1 > > >-- > Pascal Hofstee >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:23:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433021065692 for ; Mon, 17 Aug 2009 14:23:15 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id D64418FC57 for ; Mon, 17 Aug 2009 14:23:14 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 178751D1C4; Mon, 17 Aug 2009 16:23:14 +0200 (CEST) Date: Mon, 17 Aug 2009 16:23:14 +0200 From: Ed Schouten To: Andrew Gallatin Message-ID: <20090817142314.GM1292@hoeg.nl> References: <4A857D16.9070403@cs.duke.edu> <4A85B9CD.4050802@cs.duke.edu> <20090814193254.GO1884@deviant.kiev.zoral.com.ua> <4A85C325.6050400@cs.duke.edu> <20090816180911.GL1292@hoeg.nl> <4A894F0B.3080606@cs.duke.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YMoJtYXQBeUqimUz" Content-Disposition: inline In-Reply-To: <4A894F0B.3080606@cs.duke.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:23:15 -0000 --YMoJtYXQBeUqimUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andrew, * Andrew Gallatin wrote: > Is there any reason you don't just |=3D in D_NEEDMINOR on first > use of clone_create()? By adding the requirement of this flag, > you've gratuitously broken any 3rd party driver using clones, > which has used the same API unchanged since 5.x Over the last year I've made more rigorous changes to the kernel than adding a new flag to make an undocumented kernel programming interface work. Saying that the API has not been changed since 5.x isn't entirely correct. Even the null.c source code of 5.x doesn't build on HEAD anymore, because of d_maj, for example. Even though we could probably change the code to |=3D D_NEEDMINOR, I'd rather not. Having the flag there makes it very easy for me to figure out which pieces of code still depend on clonelists. As Kostik pointed out, you'd better use the cdevpriv interface if you need per-descriptor data. If it ever turns out we can live without clonelists, I am tempted to remove unit numbers from character devices entirely, making si_drv0 the integer counterpart of si_drv1 and si_drv2. --=20 Ed Schouten WWW: http://80386.nl/ --YMoJtYXQBeUqimUz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqJZ9EACgkQ52SDGA2eCwVxqgCZAcyPkE8q0Rvq6iWcSp+WKH23 rXAAn3eqnhJAOGOpbb5Xd2fuvrTitwL8 =CNrN -----END PGP SIGNATURE----- --YMoJtYXQBeUqimUz-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:24:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76FCB106568B for ; Mon, 17 Aug 2009 14:24:13 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 019908FC57 for ; Mon, 17 Aug 2009 14:24:12 +0000 (UTC) Received: by bwz19 with SMTP id 19so3179824bwz.37 for ; Mon, 17 Aug 2009 07:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tz6VGRPEciiMstEIqtq+fRUJuBKol/lIiwNGAz5MAwM=; b=YtLjhpU4lBo/x05AswPzK8btOvOXgwE69uwxI7c76JbPobxnEqe/u659Uk7DF8jmo0 RzjtFSVusEo7UvmgByaOBXusCW8xJxkKnjTczDVzTF8h2SnozMyQAuAHRr2GEqDmEG6E RDvRqDDTz05EtB/9pSAZxtVkdxjSuORgR2U+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UWA7PhzzfUOuDtFyJDKZkjuSCGl4hwLDQ7bDKNVzVhPkiDmzqYpeCzc7amLBKxbNeq j4cM3SIBs/eDa7CN+QTzVXPr65gTywk1vdaGe3jgbXAAxUHqNd1ugMpy69ffS9vMDakF slRrWvVd0wTa7wXl34t16JoL9OEFOYVy35j3s= MIME-Version: 1.0 Received: by 10.204.154.82 with SMTP id n18mr1867721bkw.128.1250519051761; Mon, 17 Aug 2009 07:24:11 -0700 (PDT) In-Reply-To: <200908171416.n7HEGObK087789@lava.sentex.ca> References: <200908171416.n7HEGObK087789@lava.sentex.ca> Date: Mon, 17 Aug 2009 16:24:11 +0200 Message-ID: From: Pascal Hofstee To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: mfutil causes RELENG_8 breakage ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:24:13 -0000 On Mon, Aug 17, 2009 at 4:19 PM, Mike Tancsa wrote: > At 09:55 AM 8/17/2009, Pascal Hofstee wrote: >> >> I just installed a fresh 8.0-BETA2 ... and updated my source-tree to >> RELENG_8 a buildworld seems to bail out with the following message. >> If i noticed correctlly the mfiutil commit went in earlier today, so i >> am assuming something is probably missing an INCLUDE-path somewhere ? > > I noticed the same thing. =A0I think > > http://lists.freebsd.org/pipermail/svn-src-stable-8/2009-August/000069.ht= ml > > fixes it I see ... looks like the cvsup-servers are lagging behind a bit then ... guess i should just avoid the inevitable and switch over to an SVN tree for /usr/src :) Thanks for the pointer though. --=20 Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:51:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137F61065691; Mon, 17 Aug 2009 14:51:46 +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 C2E788FC77; Mon, 17 Aug 2009 14:51:45 +0000 (UTC) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Md3YZ-0007fJ-LA; Mon, 17 Aug 2009 15:51:45 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1Md3YS-0002Xq-V9; Mon, 17 Aug 2009 15:51:30 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n7HEpON9090988; Mon, 17 Aug 2009 15:51:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n7HEpOdn090987; Mon, 17 Aug 2009 15:51:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Mon, 17 Aug 2009 15:51:24 +0100 From: Anton Shterenlikht To: Mark Linimon Message-ID: <20090817145124.GA89493@mech-cluster241.men.bris.ac.uk> References: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> <20090817143602.GB2365@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090817143602.GB2365@lonesome.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.5 X-Spam-Level: - Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:51:46 -0000 On Mon, Aug 17, 2009 at 09:36:02AM -0500, Mark Linimon wrote: > On Mon, Aug 17, 2009 at 02:57:52PM +0100, Anton Shterenlikht wrote: > > Ports lang/gcc43, 44 and 45 fail to build on 8.0-beta2 ia64: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 > > > > I know they build fine on 6.4-stable alpha, but what about sparc64? > > amd64? mips? > > You can check things like this using the Ports Monitoring tool: > http://portsmon.freebsd.org/portoverview.py?category=lang&portname=gcc4&wildcard=yes > > According to that, for 8.0: > > - gcc4* are set to "not for ia64". From a commit log for gcc43/Makefile: > > Add ia64 to NOT_FOR_ARCHS. This has been broken for ages, it is not clear > whether it is our kernel/userland, the hardware, or something else at fault > and nobody on our side nor upstream seems to have any interest. yes, I understand.. Unfortunately a FBSD system without gcc4x is of little use to me, because I need fortran OMP compiler, and many other ports which depend on gcc4x. I wonder if they work under ia64 linux? > amd64, i386, and sparc64. Although we have some ia64 machines, the last > time I tried to upgrade them I had trouble. We do not yet have any arm, I volunteer to build gcc4x ports on my rx2600 SMP ia64 current. > mips, or powerpc machines. Our alphas have been deinstalled (sorry), > after the alpha src code had fallen too far behind the main 3 archs, and > no one was keeping it up. yes, I gave up on alpha because of this. > Unless a developer with specific interest in ia64 steps up to help, > you may be out of luck. Sorry. well.. unfortunately I've no relevant skills to offer, only testing. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 14:51:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2232106568B; Mon, 17 Aug 2009 14:51:17 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 835158FC41; Mon, 17 Aug 2009 14:51:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id DFD898C078; Mon, 17 Aug 2009 09:36:02 -0500 (CDT) Date: Mon, 17 Aug 2009 09:36:02 -0500 From: Mark Linimon To: Anton Shterenlikht Message-ID: <20090817143602.GB2365@lonesome.com> References: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Mon, 17 Aug 2009 15:14:53 +0000 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-ia64@FreeBSD.org Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:51:17 -0000 On Mon, Aug 17, 2009 at 02:57:52PM +0100, Anton Shterenlikht wrote: > Ports lang/gcc43, 44 and 45 fail to build on 8.0-beta2 ia64: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 > > I know they build fine on 6.4-stable alpha, but what about sparc64? > amd64? mips? You can check things like this using the Ports Monitoring tool: http://portsmon.freebsd.org/portoverview.py?category=lang&portname=gcc4&wildcard=yes According to that, for 8.0: - gcc4* are set to "not for ia64". From a commit log for gcc43/Makefile: Add ia64 to NOT_FOR_ARCHS. This has been broken for ages, it is not clear whether it is our kernel/userland, the hardware, or something else at fault and nobody on our side nor upstream seems to have any interest. - previous versions of gcc43 built everywhere; the latest version has not yet been tried on amd64 or sparc64, but builds on i386. - previous versions of gcc44 built everywhere; the latest version has not yet been tried on amd64 or sparc64, but builds on i386. - previous versions of gcc45 built everywhere; the latest version has not yet been tried on amd64 or sparc64, but builds on i386. The package building cluster is currently only set up to try builds on amd64, i386, and sparc64. Although we have some ia64 machines, the last time I tried to upgrade them I had trouble. We do not yet have any arm, mips, or powerpc machines. Our alphas have been deinstalled (sorry), after the alpha src code had fallen too far behind the main 3 archs, and no one was keeping it up. Unless a developer with specific interest in ia64 steps up to help, you may be out of luck. Sorry. mcl * yes, I know that portsmon is throwing 'database not connected' errors, but don't have a fix for it yet. It only seems to affect the query for 'show me uploaded packages', and even then not all the time. From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 15:25:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEF6106568F; Mon, 17 Aug 2009 15:25:09 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 67D798FC55; Mon, 17 Aug 2009 15:25:09 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:34069 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Md44m-0003Om-5M; Mon, 17 Aug 2009 17:24:51 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 9F93640732; Mon, 17 Aug 2009 17:24:49 +0200 (CEST) Message-Id: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> From: Thomas Backman To: Pawel Dawidek Jakub In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 17:24:47 +0200 References: X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1Md44m-0003Om-5M. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Md44m-0003Om-5M 4d5b7d8f6a460e9904f795ae935727d1 Cc: FreeBSD current Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:25:10 -0000 On Aug 17, 2009, at 15:25, Thomas Backman wrote: > So, I've got myself a source tree almost completely free of patches > after today's batch of ZFS patches merged - all that remains is that > I uncommented ps -axl from /usr/sbin/crashinfo, since it only > coredumps anyway, and added CFLAGS+=-DDEBUG=1 to zfs/Makefile. > > One of the changes I didn't already have prior to this must have > broken something, though, because this script worked just fine > before the merges earlier today. > The script below is the exact same I linked in http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html > back in July (URL to the script: http://exscape.org/temp/zfs_clone_panic.sh > ) - I made some local changes, thus the name invoked below. > > Now that all the patches are merged, you should need nothing but the > script, bash, and the ~200MB free space on the partition containing / > root/ to reproduce this problem. > (Note that the "no such pool" in the FIRST script is normal; it > simply tries to clean up something that isn't there, without error/ > sanity checking.) > > [root@chaos ~]# bash -x panic-tests/CLONE_CRASH.submitted.sh initial > + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/ > local/bin:/root/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/ > usr/local/sbin > + MASTERPATH=/root/zfsclonecrash/crashtestmaster.disk > + SLAVEPATH=/root/zfsclonecrash/crashtestslave.disk > + LASTBACKUP=/root/zfsclonecrash/last-backup-name > + MASTERNUM=1482 > + SLAVENUM=1675 > + '[' '!' -z initial ']' > + case $1 in > + initial > ++ dirname /root/zfsclonecrash/crashtestmaster.disk > + mkdir -p /root/zfsclonecrash > + rm -rf /crashtestmaster /crashtestslave > + mount_unmount unmount > + '[' -z unmount ']' > + [[ unmount == \m\o\u\n\t ]] > + [[ unmount == \u\n\m\o\u\n\t ]] > + zpool export crashtestmaster > cannot open 'crashtestmaster': no such pool > + ggatel destroy -u 1482 > + zpool export crashtestslave > cannot open 'crashtestslave': no such pool > + ggatel destroy -u 1675 > + echo Creating files and syncing > Creating files and syncing > + dd if=/dev/zero of=/root/zfsclonecrash/crashtestmaster.disk > bs=1000k count=100 > 100+0 records in > 100+0 records out > 102400000 bytes transferred in 0.367217 secs (278854144 bytes/sec) > + dd if=/dev/zero of=/root/zfsclonecrash/crashtestslave.disk > bs=1000k count=100 > 100+0 records in > 100+0 records out > 102400000 bytes transferred in 0.286532 secs (357377280 bytes/sec) > + sync > + echo Sleeping 5 seconds > Sleeping 5 seconds > + sleep 5 > + echo 'Creating GEOM providers (~10 secs)' > Creating GEOM providers (~10 secs) > + ggatel create -u 1482 /root/zfsclonecrash/crashtestmaster.disk > + sleep 5 > + ggatel create -u 1675 /root/zfsclonecrash/crashtestslave.disk > + sleep 5 > + echo 'Creating pools' > Creating pools > + zpool create -f crashtestmaster ggate1482 > + zpool create -f crashtestslave ggate1675 > + echo 'Adding some data to the master pool' > Adding some data to the master pool > + zfs create crashtestmaster/test_orig > + dd if=/dev/random of=/crashtestmaster/test_orig/file1 bs=1000k > count=10 > 10+0 records in > 10+0 records out > 10240000 bytes transferred in 0.447472 secs (22884109 bytes/sec) > + dd if=/dev/random of=/crashtestmaster/test_orig/file2 bs=1000k > count=10 > 10+0 records in > 10+0 records out > 10240000 bytes transferred in 0.626774 secs (16337625 bytes/sec) > + echo 'Cloning test_base' > Cloning test_base > + zfs snapshot crashtestmaster/test_orig@snap > + zfs clone crashtestmaster/test_orig@snap crashtestmaster/test_cloned > + zfs promote crashtestmaster/test_cloned > ++ date +backup-%Y%m%d-%H%M%S > + NOW=backup-20090817-151412 > + echo 'Creating snapshots' > Creating snapshots > + zfs snapshot -r crashtestmaster@backup-20090817-151412 > + echo 'Doing initial clone to slave pool' > Doing initial clone to slave pool > + zfs send -R crashtestmaster@backup-20090817-151412 > + zfs recv -vFd crashtestslave > cannot receive: invalid stream (malformed nvlist) > warning: cannot send 'crashtestmaster/test_cloned@snap': Broken pipe > warning: cannot send 'crashtestmaster/ > test_cloned@backup-20090817-151412': Broken pipe > + mount_unmount unmount > + '[' -z unmount ']' > + [[ unmount == \m\o\u\n\t ]] > + [[ unmount == \u\n\m\o\u\n\t ]] > + zpool export crashtestmaster > + ggatel destroy -u 1482 > + zpool export crashtestslave > + ggatel destroy -u 1675 > + echo backup-20090817-151412 > + echo 'Done!' > Done! > + exit 0 > > > I first noticed this after trying to make an incremental backup > right after the installworld+reboot, as I always do; it didn't find > the slave zpool to import...(! This may be very bad in real-life > cases - I have no clue if ggate is the culprit or if people will > soon start reporting lost pools.) So I tried wiping the backup and > creating a new one from scratch (~15GB over the network), giving me > the very same problem, instantly: > > [...] > + zpool create -f -R /slave slave ggate666 > ++ date +backup-%Y%m%d-%H%M > + NOW=backup-20090817-1522 > + echo 'Creating snapshots' > Creating snapshots > + zfs snapshot -r tank@backup-20090817-1522 > + echo 'Cloning pool' > Cloning pool > + zfs send -R tank@backup-20090817-1522 > + zfs recv -vFd slave > cannot receive: invalid stream (malformed nvlist) > warning: cannot send 'tank@backup-20090817-1522': Broken pipe > > > Regards, > Thomas This is perhaps more troubling... [root@chaos ~]# dd if=/dev/zero of=./zfstestfile bs=1000k count=100 && ggatel create -u 142 ./zfstestfile && zpool create -f testpool142 ggate142 100+0 records in 100+0 records out 102400000 bytes transferred in 0.266194 secs (384681697 bytes/sec) [root@chaos ~]# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 66G 9.86G 56.1G 14% ONLINE - testpool142 93M 73.5K 92.9M 0% ONLINE - [root@chaos ~]# zpool export testpool142 [root@chaos ~]# ggatel destroy -u 142 [root@chaos ~]# ggatel create -u 142 ./zfstestfile [root@chaos ~]# zpool import testpool142 cannot import 'testpool142': no such pool available [root@chaos ~]# zpool import [root@chaos ~]# ggatel list ggate142 [root@chaos ~]# Worse yet: [root@chaos ~]# zpool create testpool ad0s1d [root@chaos ~]# zpool export testpool [root@chaos ~]# zpool import testpool cannot import 'testpool': no such pool available Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 15:35:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929B2106568C for ; Mon, 17 Aug 2009 15:35:27 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 411928FC59 for ; Mon, 17 Aug 2009 15:35:27 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7HFZPnD091858 ; Mon, 17 Aug 2009 17:35:25 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7HFZOnr001879; Mon, 17 Aug 2009 17:35:24 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7HFZOku001876; Mon, 17 Aug 2009 17:35:24 +0200 (CEST) (envelope-from arno) To: Marcel Moolenaar From: "Arno J. Klaassen" References: Date: Mon, 17 Aug 2009 17:35:24 +0200 In-Reply-To: (Marcel Moolenaar's message of "Sun\, 16 Aug 2009 14\:20\:47 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9704/Mon Aug 17 03:54:29 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A8978BD.008 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A8978BD.008/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: current@freebsd.org Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:35:27 -0000 Marcel Moolenaar writes: > All, > > A few of my machines still can't boot successfully to multi-user: > > ... > Trying to mount root from ufs:da0p3 > Entropy harvesting: interrupts ethernet point_to_point kickstart. > /dev/da0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0p3: clean, 8843098 free (98130 frags, 1093121 blocks, 0.6% > fragmentation) > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 13 > ZFS storage pool version 13 > bge0: link state changed to DOWN > Starting Network: lo0 bge0. > bge1: link state changed to DOWN > Mounting NFS file systems:mount_nfs: nfs: hostname nor servname > provided, or not known > . > bge0: link state changed to UP > Setting date via ntp. > Error : hostname nor servname provided, or not known > > [ ... ] > I have a similar problem, and it seems related to the moment that bge0 is brought up : I have a kernel-config with only 'device mii' compiled in; if I set if_bge_load=YES in loader.conf, boot single user and run netif by hand I get : Trying to mount root from ufs:/dev/aacd0s1a ct_to_ts([2009-08-17 13:42:03]) = 1250516523.000000000 start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: # /etc/rc.d/netif start XXX netif start ... bge0: link state changed to DOWN Starting Network: bge0. bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:e0:81:4d:5d:b8 inet 172.16.1.8 netmask 0xffffff00 broadcast 172.16.1.255 inet6 fe80::2e0:81ff:fe4d:5db8%bge0 prefixlen 64 tentative scopeid 0x1 media: Ethernet autoselect (none) status: no carrier # bge0: link UP bge0: link state changed to UP # ping 172.16.1.6 PING 172.16.1.6 (172.16.1.6): 56 data bytes ping: sendto: Permission denied ping: sendto: Permission denied ping: sendto: Permission denied ^C --- 172.16.1.6 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # freed 1 flow entries # nslookup 172.16.1.6 172.16.1.6 ;; connection timed out; no servers could be reached # However, if I place kldload if_bge in rc.local (and normal multi-user boot) : XXX netif start ... Starting Network: lo0. route: writing to routing socket: Network is unreachable add net default: gateway 172.16.1.254: Network is unreachable /etc/rc: WARNING: Dump device does not exist. Savecore not run. rpc.umntall: push: MOUNTPROG: RPC: Unknown host Aug 17 16:11:08 siamesetwins kernel: NLM: failed to contact remo Aug 17 16:1bge0: mem 0xff0d0000-0xff0dffff,0xff0c0000-0xff0cffff irq 26 at device 4.0 on pci4 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xff0d0000 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 48 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x81000000; ASIC REV 0x08; CHIP REV 0x81; PCI-X 1:08 siamesetwinmiibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0035, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: XXX bge0: [MPSAFE] bge0: [ITHREAD] [ ... ] Mon Aug 17 16:11:24 CEST 2009 FreeBSD/amd64 (siamesetwins) (ttyu0) login: ts_to_ct(1250518288.759918777) = [2009-08-17 14:11:28] FreeBSD/amd64 (siamesetwins) (ttyu0) login: toor [ ... ] [root@siamesetwins ~]# ping 172.16.1.6 PING 172.16.1.6 (172.16.1.6): 56 data bytes 64 bytes from 172.16.1.6: icmp_seq=0 ttl=64 time=0.210 ms 64 bytes from 172.16.1.6: icmp_seq=1 ttl=64 time=0.231 ms ^C --- 172.16.1.6 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.210/0.221/0.231/0.010 ms [root@siamesetwins ~]# nslookup 172.16.1.6 172.16.1.6 Server: 172.16.1.6 Address: 172.16.1.6#53 6.1.16.172.in-addr.arpa name = XXX [root@siamesetwins ~]# /etc/rc.d/lockd restart lockd not running? Starting lockd. [root@siamesetwins ~]# Arno From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 15:44:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ABFC106568B for ; Mon, 17 Aug 2009 15:44:18 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id BC8778FC61 for ; Mon, 17 Aug 2009 15:44:17 +0000 (UTC) Received: from [192.168.0.2] (unknown [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id BD05E79000; Mon, 17 Aug 2009 19:44:14 +0400 (MSD) Message-ID: <4A897ACE.8020405@haruhiism.net> Date: Mon, 17 Aug 2009 19:44:14 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Arno J. Klaassen" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:44:18 -0000 Arno J. Klaassen wrote: > However, if I place kldload if_bge in rc.local (and normal multi-user > boot) : > I'm pretty sure that rc.local is executed after netif. Which means that when netif parses ifconfig_bge0, that interface is not even present in the system. Issue "rcorder /etc/rc.d/*" to check that. For my system, it's way later. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 16:34:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05FAC106568B; Mon, 17 Aug 2009 16:34:53 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id BC3FE8FC16; Mon, 17 Aug 2009 16:34:52 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 4EC181E0031D; Mon, 17 Aug 2009 18:34:51 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n7HGViKt003454; Mon, 17 Aug 2009 18:31:44 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n7HGVi7B003453; Mon, 17 Aug 2009 18:31:44 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 17 Aug 2009 18:31:44 +0200 To: freebsd-current@FreeBSD.org, mav@FreeBSD.org Message-ID: <20090817163144.GA2991@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: most simple way to hang ahci(4): camcontrol tur on ada disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:34:53 -0000 Hi! After looking again at my `cdrecord -scanbus -V' log... http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010660.html ...I remembered camcontrol(8) can send the test unit ready command as well, so I booted into single user (to avoid having to fsck again) and tried it - and lo and behold, the first `ls' afterwards hung again. So its not something weird cdrecord/cdrdao do, a simple test unit ready is enough to reproduce it, or at least here... (My guess is this has something to do with the fact that sata disks are not atapi i.e. don't speak scsi commands by default so the test unit ready would have to be either emulated or translated and there's probably something missing or broken in that code? Or maybe scsi commands should just be rejected on non-atapi sata devices for now?) HTH, Juergen From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 16:42:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2552106568B; Mon, 17 Aug 2009 16:42:24 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF9B8FC55; Mon, 17 Aug 2009 16:42:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOJ0012D52A7150@asmtp024.mac.com>; Mon, 17 Aug 2009 09:42:24 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090817143602.GB2365@lonesome.com> Date: Mon, 17 Aug 2009 09:42:09 -0700 Message-id: References: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> <20090817143602.GB2365@lonesome.com> To: Mark Linimon X-Mailer: Apple Mail (2.1074) Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-ia64@FreeBSD.org Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:42:24 -0000 On Aug 17, 2009, at 7:36 AM, Mark Linimon wrote: > The package building cluster is currently only set up to try builds on > amd64, i386, and sparc64. Although we have some ia64 machines, the > last > time I tried to upgrade them I had trouble. Really, you have ia64 machines for ports building? Are you referring to pluto1 and pluto2 or are these entirely different beasts? > Unless a developer with specific interest in ia64 steps up to help, > you may be out of luck. Sorry. I'll see about fixing it... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 17:18:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492B21065691; Mon, 17 Aug 2009 17:18:50 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id D26E08FC61; Mon, 17 Aug 2009 17:18:49 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n7HGwqeB041736; Mon, 17 Aug 2009 11:58:53 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1250528333; bh=pdp52duLjK9AymP3F5gQX+fFiqhd+K3naBVlZVElS7s=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=kyAPvhYggJn7CRYs7w48fHJUVM1MsNJ2DuiGwfzCPjNNw7JdhnaWLKs2QxtgRk5TP BatIVb7+s19aWSlDfkhF5s7y5redapoXb2/36yL+hrAdup3jcYMq4dTqyExghPwvo8 zEnjjcnswrhZbAxe2aDRQnKICr/6TMX7+JbKqDjU= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n7HGwqc3041735; Mon, 17 Aug 2009 11:58:52 -0500 (CDT) (envelope-from tinguely) Date: Mon, 17 Aug 2009 11:58:52 -0500 (CDT) From: Mark Tinguely Message-Id: <200908171658.n7HGwqc3041735@casselton.net> To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, mexas@bristol.ac.uk In-Reply-To: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 17 Aug 2009 11:58:53 -0500 (CDT) Cc: Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:18:50 -0000 > Ports lang/gcc43, 44 and 45 fail to build on 8.0-beta2 ia64: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 > > I know they build fine on 6.4-stable alpha, but > what about sparc64? amd64? mips? > > many thanks > > -- > Anton Shterenlikht FYI: I mostly ported GCC 4.5 to the BSD Makefiles (svn head sys/gnu/usr.bin/cc) for ARM. Basically, I added the FreeBSD format extension, the __FreeBSD_cc_version built-in define and the PATH changes. I did not make BSD Makefile for the GMP and MPFR libraries. I don't have the FreeBSD-8.0 revision 195697 that eliminates ".text relocations in shared libraries compiled with stack protector". Vassilis Laganakos has been working with GCC 4.4 on the ARM. I haven't push the compiler (and newer binutils 2.19) much beyond building the kernel. GCC 4.5 "-O" option creates new kernel warnings with the conditional locks. Below is a typical error: /mnt/arm64/usr/bin/gcc -mlittle-endian -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 -nostdinc -I. -I../../.. -I../../../contrib/altq -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 -mcpu=xscale -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c cc1: warnings being treated as errors ../../../fs/devfs/devfs_vnops.c: In function 'devfs_lookup': ../../../sys/sx.h:165:1: error: inlining failed in call to '__sx_xunlock': call is unlikely and code size would grow ../../../fs/devfs/devfs_vnops.c:809:3: error: called from here ../../../sys/sx.h:165:1: error: inlining failed in call to '__sx_xunlock': call is unlikely and code size would grow ../../../fs/devfs/devfs_vnops.c:817:4: error: called from here ../../../sys/sx.h:165:1: error: inlining failed in call to '__sx_xunlock': call is unlikely and code size would grow ../../../fs/devfs/devfs_vnops.c:828:4: error: called from here *** Error code 1 --Mark Tinguely. From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 18:30:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B1A106568B for ; Mon, 17 Aug 2009 18:30:54 +0000 (UTC) (envelope-from esbjerg@gustav.anc.dk) Received: from gustav.anc.dk (gustav.anc.dk [194.255.112.205]) by mx1.freebsd.org (Postfix) with ESMTP id CFB828FC55 for ; Mon, 17 Aug 2009 18:30:53 +0000 (UTC) Received: by gustav.anc.dk (Postfix, from userid 1000) id C20B91BE67; Mon, 17 Aug 2009 19:57:45 +0200 (CEST) Date: Mon, 17 Aug 2009 19:57:45 +0200 From: Sven Esbjerg To: current@freebsd.org Message-ID: <20090817175745.GA697@esbjerg.name> References: <20090816185930.49144213.ubm.freebsd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:30:54 -0000 On Sun, Aug 16, 2009 at 07:50:03PM +0100, Robert Watson wrote: > > On Sun, 16 Aug 2009, Marc UBM wrote: > > >While loading snd_hda for fun on my fileserver, I got the following panic > >(crashdump available for poking around): > > > >panic: _sx_xlock_hard: recursed on non-recursive sx newbus @ > >/usr/src/sys/kern/subr_bus.c:219 > > > >Backtrace is attached. > > Hi Marc-- > > This is most likely associated with the known "newbus" locking issues from > late-break MPSAFEty work on newbus for 8.0. I understand that Attilio is > working actively on fixing this (CC'd). You could try Attilio's patch: http://people.freebsd.org/~attilio/hdac.diff It fixed the panic I was having while loading the sound driver. -Sven From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 20:24:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622CE106568C for ; Mon, 17 Aug 2009 20:24:35 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id F125E8FC71 for ; Mon, 17 Aug 2009 20:24:34 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7HKOYl4046461 ; Mon, 17 Aug 2009 22:24:34 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7HKOXsB004265; Mon, 17 Aug 2009 22:24:33 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7HKOX1T004262; Mon, 17 Aug 2009 22:24:33 +0200 (CEST) (envelope-from arno) To: Kamigishi Rei From: "Arno J. Klaassen" References: <4A897ACE.8020405@haruhiism.net> Date: Mon, 17 Aug 2009 22:24:32 +0200 In-Reply-To: <4A897ACE.8020405@haruhiism.net> (Kamigishi Rei's message of "Mon\, 17 Aug 2009 19\:44\:14 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9705/Mon Aug 17 19:03:09 2009 on shiva.jussieu.fr X-Virus-Status: Clean Cc: Marcel Moolenaar , current@freebsd.org Subject: Re: rc(8) regression. What's the story? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 20:24:35 -0000 Kamigishi Rei writes: > Arno J. Klaassen wrote: >> However, if I place kldload if_bge in rc.local (and normal multi-user >> boot) : >> > I'm pretty sure that rc.local is executed after netif. > Which means that when netif parses ifconfig_bge0, that interface is > not even present in the system. my main point is that 'ping' and 'resolv' do not function when ifconfig_bge0 is started by netif and if_bge loaded at boot, nor in multi-user neither in single-user and executing netif by hand and then go multi-user I ignore how netif or some other mechanism can pick up ifconfig_bge0 when if_bge is kldloaded in rc.local, I can just confirm that when I leave it out rc.local my ifconfig list only contains lo0 tested with network_interfaces="auto" Arno From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 20:53:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5237110656F2 for ; Mon, 17 Aug 2009 20:53:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D196C8FC16 for ; Mon, 17 Aug 2009 20:53:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1Md9CN-0005Lw-Ji for freebsd-current@freebsd.org; Mon, 17 Aug 2009 22:52:59 +0200 Received: from 93-138-45-215.adsl.net.t-com.hr ([93.138.45.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Aug 2009 22:52:59 +0200 Received: from ivoras by 93-138-45-215.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Aug 2009 22:52:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 17 Aug 2009 22:52:32 +0200 Lines: 67 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA592CD1FAE1F2A15E773223" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-45-215.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) In-Reply-To: X-Enigmail-Version: 0.96.0 Sender: news Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 20:53:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA592CD1FAE1F2A15E773223 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Alexey Tarasov wrote: > Hello. >=20 > I have more than 30 Supermicro servers with same config and on all of t= hem I > get kernel panic. >=20 > Here is the screenshots of kgdb output: > http://lexasoft.ru/metamphetamine/Panic/Picture%2073.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2074.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2075.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2076.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2077.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2078.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2079.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2082.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2083.png >=20 > Here is dmesg output: >=20 > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-STABLE #0: Wed Aug 12 01:06:04 MSD 2009 > root@st2.srv.getthebit.com:/usr/obj/usr/src/sys/STORAGE > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf65 Stepping =3D 5 > atapci0: port A bit old system, but at least it should be "well known" - if it's a OS=20 problem someone would have noticed it by now. How did you create your file systems? Can you rule out disk drive data corruption? Does the panic happen with all drives and all file systems you have? Can = you boot single-user and test each file system? --------------enigBA592CD1FAE1F2A15E773223 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJwxAACgkQldnAQVacBcg6mwCePaPatQ2X5SuVfskacBWMqdL8 ndQAoK0Qs4qEtVIqW5zF8iPKe8HOa9IT =CQSY -----END PGP SIGNATURE----- --------------enigBA592CD1FAE1F2A15E773223-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 22:33:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A9410656A8 for ; Mon, 17 Aug 2009 22:33:31 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED358FC64 for ; Mon, 17 Aug 2009 22:33:31 +0000 (UTC) Received: from tau.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 3E91D851A; Mon, 17 Aug 2009 22:33:30 +0000 (UTC) Date: Mon, 17 Aug 2009 23:33:31 +0100 From: Bruce Cran To: Bruce Cran Message-ID: <20090817233331.2adbf2a8@tau.draftnet> In-Reply-To: <20090815142043.2b18dae0@tau.draftnet> References: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> <94F61AF3-E0D2-4BCD-8C74-07C3C0752A47@exscape.org> <20090814093916.11c89255@gluon.draftnet> <9CBAB74F-45CD-4B20-835C-A77C9D01B5D1@exscape.org> <20090815142043.2b18dae0@tau.draftnet> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD current , Thomas Backman Subject: Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 22:33:31 -0000 On Sat, 15 Aug 2009 14:20:43 +0100 Bruce Cran wrote: > I managed to get a full backtrace and can at least see what's causing > the crash: it seems it's stepping past the nlist array and calls > vsnprintf with a bad argument. kvm_nlist returns -1 to report that the > symbol table couldn't be read, but the code assumes it has returned a > positive number to indicate that there's an invalid entry, so it > starts searching for that entry where n_type is 0. I've submitted a bug report for this - it's http://www.freebsd.org/cgi/query-pr.cgi?pr=137890 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 01:33:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70A87106568B; Tue, 18 Aug 2009 01:33:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id C8AD58FC3F; Tue, 18 Aug 2009 01:33:39 +0000 (UTC) Received: by ewy2 with SMTP id 2so208715ewy.43 for ; Mon, 17 Aug 2009 18:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kyWkZFIE/YPqQdFvSfdr1sxfhxa9ExTRob0bzwI1grU=; b=CIPAnj0Cfjd/YH25RPOg51vDZjxvbgHXTG9NxmOpg5M0uQaZjPdrY0hfZtaDBn0bFc np3UmZ4TBzQflA4lMCltt9Rnk/rSQdXz1OElT8I01Baaj4aPFuhfSOg/bmu9Bvg28aeb 3yvNV4P0YKTEZRyAiqOp0ZYZnA+MQR+MZdo2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hb8rOnRIOoqXT3h4dOEeyNoiyHCLbUqZFJomlCEJquxNktFqTo1oeNsCGKwmh8Mnj3 zRw/zu+YAQnp3rvEhl/kbFSEjr7ubKYB16Xm4Ml0nzqnRr87dn5pf+tr2xE/uVWOzjzc dSK1epbeT6or4fymugu8ziOch7Df1GHKrTUbM= MIME-Version: 1.0 Received: by 10.210.63.16 with SMTP id l16mr210478eba.27.1250557602739; Mon, 17 Aug 2009 18:06:42 -0700 (PDT) In-Reply-To: <200908171658.n7HGwqc3041735@casselton.net> References: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> <200908171658.n7HGwqc3041735@casselton.net> Date: Mon, 17 Aug 2009 21:06:42 -0400 Message-ID: From: Ryan Stone To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, mexas@bristol.ac.uk, freebsd-questions@freebsd.org Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 01:33:40 -0000 That error is gcc oh-so-helpfully telling you that it decided not to inline an function declared inline. Why the gcc devs decided that was deserving of a diagnostic on -Wall is beyond me. I think that you can squelch it by passing -Wno-inline to gcc. From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 02:51:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24941065672 for ; Tue, 18 Aug 2009 02:51:11 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id C3BE38FC43 for ; Tue, 18 Aug 2009 02:51:11 +0000 (UTC) Received: from localhost (pool-70-20-219-14.phil.east.verizon.net [70.20.219.14]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id B61DD8234E; Tue, 18 Aug 2009 11:51:09 +0900 (JST) Date: Mon, 17 Aug 2009 22:51:05 -0400 From: Yoshihiro Ota To: Hans Petter Selasky , freebsd-current@freebsd.org Message-Id: <20090817225105.88fa579d.ota@j.email.ne.jp> In-Reply-To: <20090214133457.e47df9b5.ota@j.email.ne.jp> References: <20090213204112.7b982402.ota@j.email.ne.jp> <200902141759.27816.hselasky@c2i.net> <20090214124727.82638653.ota@j.email.ne.jp> <200902141853.14366.hselasky@c2i.net> <20090214130426.5265143b.ota@j.email.ne.jp> <20090214133457.e47df9b5.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: USB2 - keyboard error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 02:51:12 -0000 Hi all and Hans, After switching code base for 8 release, I realized problems with my keyboard. The work-around described below fixed my problems. Could you be able to incorporate fix for this? Thanks, Hiro On Sat, 14 Feb 2009 13:34:57 -0500 Yoshihiro Ota wrote: > On Sat, 14 Feb 2009 13:04:26 -0500 > Yoshihiro Ota wrote: > > > On Sat, 14 Feb 2009 18:53:13 +0100 > > Hans Petter Selasky wrote: > > > > > What I can offer is to add a USB quirk that disables the setting of the leds. > > > Then you can add this by usbconfig for example. > > > > > > Try adding a return before the switch() in "ukbd_set_leds_callback()" and see > > > if the keyboard works like expected. > > > > > > BTW: Do leds work with USB1 ? > > > > > > --HPS > > > > I will try to add a return before the switch. > > > > Keyboard works fine with USB1; I never had problems. > > > > By the way, what is "leds"? > > > > Thanks, > > Hiro > > After I added a return before the switch in the function, the USB keyboard > started working fine. One minor finding is that its caps-lock right doesn't > turn on. 'Caps-lock' itself is working, making to UPPER cases. > > Hiro From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 03:48:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203A1106568C; Tue, 18 Aug 2009 03:48:47 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 003FD8FC3F; Tue, 18 Aug 2009 03:48:46 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 7767F8C086; Mon, 17 Aug 2009 22:48:46 -0500 (CDT) Date: Mon, 17 Aug 2009 22:48:46 -0500 From: Mark Linimon To: Anton Shterenlikht Message-ID: <20090818034846.GC14408@lonesome.com> References: <20090817135752.GA73485@mech-cluster241.men.bris.ac.uk> <20090817143602.GB2365@lonesome.com> <20090817145124.GA89493@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090817145124.GA89493@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Tue, 18 Aug 2009 04:45:08 +0000 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ports lang/gcc4x fail to build on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 03:48:47 -0000 On Mon, Aug 17, 2009 at 03:51:24PM +0100, Anton Shterenlikht wrote: > I wonder if they work under ia64 linux? I don't know. A quick check of NetBSD seems to indicate that their ia64 port only runs in emulation mode; OpenBSD doesn't list an ia64 port. mcl From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 05:06:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 306A51065692 for ; Tue, 18 Aug 2009 05:06:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id B92968FC41 for ; Tue, 18 Aug 2009 05:06:26 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=wmTVOl381u9Fsp30FvcA:9 a=c5HWPibFOKeuq0ZherQViatYe0QA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 241152471; Tue, 18 Aug 2009 07:06:20 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 18 Aug 2009 07:06:29 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090213204112.7b982402.ota@j.email.ne.jp> <20090214133457.e47df9b5.ota@j.email.ne.jp> <20090817225105.88fa579d.ota@j.email.ne.jp> In-Reply-To: <20090817225105.88fa579d.ota@j.email.ne.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908180706.30202.hselasky@c2i.net> Cc: Yoshihiro Ota Subject: Re: USB2 - keyboard error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:06:27 -0000 On Tuesday 18 August 2009 04:51:05 Yoshihiro Ota wrote: > Hi all and Hans, > > After switching code base for 8 release, I realized problems with my > keyboard. The work-around described below fixed my problems. > > Could you be able to incorporate fix for this? > > Thanks, > Hiro Can you resend the patch? --HPS From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 05:17:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4490106568C; Tue, 18 Aug 2009 05:17:58 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by mx1.freebsd.org (Postfix) with ESMTP id 902C88FC5B; Tue, 18 Aug 2009 05:17:58 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id AA8D9225173; Tue, 18 Aug 2009 07:17:54 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 19D72F09B; Tue, 18 Aug 2009 01:16:59 -0400 (EDT) Date: Tue, 18 Aug 2009 01:16:59 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090818051659.GA1477@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> <20090813191724.GA1499@plebeian.afflictions.org> <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:17:58 -0000 Attilio Rao wrote: : > : > The script does not run when resuming in graphics mode, unfortunately. : > : > Try as I might, I just don't get anything. I'm not sure what exactly : > : > the system is doing when it resumes, as attempts to create files on : > : > the local fs seem to fail. : > : : > : You have to manually break in DDB for that. : > : BTW, differently from GENERIC, remove WITNESS_SKIPSPIN, just in case. : > : > After removing WITNESS_SKIPSPIN, the ddb script works. I've included the : > output from textdump below. : : Hans suggested to try this patch: : http://p4db.freebsd.org/chv.cgi?CH=167286 I've applied the patch, and the panic no longer happens. Unfortunately, I still no longer receive my display; the behaviour of the system has gone back to before the removal of SKIPSPIN from GENERIC. - Damian From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 05:52:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81AFC106564A for ; Tue, 18 Aug 2009 05:52:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0213F8FC62 for ; Tue, 18 Aug 2009 05:52:48 +0000 (UTC) Received: by bwz19 with SMTP id 19so3687410bwz.37 for ; Mon, 17 Aug 2009 22:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5f4VVulp1xf8VDHL9qpubu0AAE9d87fBy0GITVH/U5I=; b=SLviXk54qalgDn+myeZUGEHAY/t7o0xWyDQ31KJXkEDCL3+SSRojZbPvFSta5MSTzI yx6hmPqgq5BPqg5lKpR8g1Eo6stmbwejcxJdiydAk/YUOLlieqisag2EnWY6aRDDjPYz 8OIP7yVpAqgi+3NQeqYji/z9qTzpy13HD389I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZM+f4t7NprL1nQv58SqXULF8XXFp4C5MymrZETpY/LUa2q0iB+R9qcvnU/Qn+MSfsk QwMllM5HxBb7/qMJWx7/NBoBgcKlyZL6EdJiKv+dMvh1348IzUx6/Snc89VJpARIvnj5 CFX4AznZ3xZvWJuEx9egd/5Ud6bdVc6NYaAgQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.14.22 with SMTP id e22mr1047565faa.42.1250574767623; Mon, 17 Aug 2009 22:52:47 -0700 (PDT) In-Reply-To: <20090818051659.GA1477@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> <20090813191724.GA1499@plebeian.afflictions.org> <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> <20090818051659.GA1477@plebeian.afflictions.org> Date: Tue, 18 Aug 2009 07:52:47 +0200 X-Google-Sender-Auth: dd251751a13dca76 Message-ID: <3bbf2fe10908172252t3b176f06r5ae46fed6644df7c@mail.gmail.com> From: Attilio Rao To: Damian Gerow Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:52:49 -0000 2009/8/18 Damian Gerow : > Attilio Rao wrote: > : > : > The script does not run when resuming in graphics mode, unfortuna= tely. > : > : > Try as I might, I just don't get anything. =C2=A0I'm not sure wha= t exactly > : > : > the system is doing when it resumes, as attempts to create files = on > : > : > the local fs seem to fail. > : > : > : > : You have to manually break in DDB for that. > : > : BTW, differently from GENERIC, remove WITNESS_SKIPSPIN, just in cas= e. > : > > : > After removing WITNESS_SKIPSPIN, the ddb script works. =C2=A0I've inc= luded the > : > output from textdump below. > : > : Hans suggested to try this patch: > : http://p4db.freebsd.org/chv.cgi?CH=3D167286 > > I've applied the patch, and the panic no longer happens. =C2=A0Unfortunat= ely, I > still no longer receive my display; the behaviour of the system has gone > back to before the removal of SKIPSPIN from GENERIC. You should now retry the past instructions I gave you breaking in DDB when you get the deadlock (ctrl+alt+esc will do it, for example). Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 09:37:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A4D106568E for ; Tue, 18 Aug 2009 09:37:11 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 41E7C8FC5B for ; Tue, 18 Aug 2009 09:37:10 +0000 (UTC) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 251847717; Tue, 18 Aug 2009 12:37:07 +0300 Message-ID: <4A8A7642.7070403@FreeBSD.org> Date: Tue, 18 Aug 2009 12:37:06 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.22 (X11/20090805) MIME-Version: 1.0 To: Ilya Zhuravlev References: <4A4517BE.9040504@FreeBSD.org> <4A6EBAFC.6090800@cbtnet.ru> <4A709323.6050001@FreeBSD.org> <4A7AB52B.5000300@cbtnet.ru> <4A7AEF07.2040906@FreeBSD.org> <4A8406E1.5070905@cbtnet.ru> <4A84470B.6040507@FreeBSD.org> <4A88CFE8.3000005@cbtnet.ru> <4A88F912.1050308@FreeBSD.org> <4A8A3E8D.2030708@cbtnet.ru> In-Reply-To: <4A8A3E8D.2030708@cbtnet.ru> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 09:37:11 -0000 Ilya Zhuravlev wrote: > Alexander Motin wrote: >> >> I have meant simple 4-line patch, attached here. >> > Thanks, it works for me: > scbus0 on ahcich0 bus 0: > at scbus0 target 0 lun 0 (pass0,ada0) > <> at scbus0 target -1 lun -1 () > scbus1 on ahcich1 bus 0: > at scbus1 target 0 lun 0 (pass1,cd0) > <> at scbus1 target -1 lun -1 () > scbus2 on umass-sim0 bus 0: > at scbus2 target 0 lun 0 (da0,pass2) > at scbus2 target 0 lun 1 (da1,pass3) > scbus3 on umass-sim1 bus 1: > at scbus3 target 0 lun 0 (da2,pass4) > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun -1 (xpt0) Committed. Thanks. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 10:12:20 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3068A1065690; Tue, 18 Aug 2009 10:12:20 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 06C468FC69; Tue, 18 Aug 2009 10:12:19 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-240-232.hsd1.ms.comcast.net [75.65.240.232]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 096D037B64D; Tue, 18 Aug 2009 05:12:18 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 2DB8C61C41; Tue, 18 Aug 2009 05:12:17 -0500 (CDT) Date: Tue, 18 Aug 2009 05:12:17 -0500 From: "Matthew D. Fuller" To: Juergen Lock Message-ID: <20090818101217.GA67451@over-yonder.net> References: <20090817163144.GA2991@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090817163144.GA2991@triton8.kn-bremen.de> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: most simple way to hang ahci(4): camcontrol tur on ada disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 10:12:20 -0000 On Mon, Aug 17, 2009 at 06:31:44PM +0200 I heard the voice of Juergen Lock, and lo! it spake thus: > > So its not something weird cdrecord/cdrdao do, a simple test unit > ready is enough to reproduce it, or at least here... `camcontrol inquiry` (not 'identify') does the same. Presumably the same situation. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 10:57:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3594106568D; Tue, 18 Aug 2009 10:57:53 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFBD8FC52; Tue, 18 Aug 2009 10:57:52 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MdMNx-0000Pw-I9; Tue, 18 Aug 2009 12:57:49 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MdMO7-0000zJ-I5; Tue, 18 Aug 2009 12:57:59 +0200 To: Robert Watson From: Ian FREISLICH In-Reply-To: References: <4A8484E4.6090504@uffner.com> X-Attribution: BOFH Date: Tue, 18 Aug 2009 12:57:59 +0200 Message-Id: Cc: pf@freebsd.org, current@freebsd.org Subject: Re: packet forwarding/firewall performance question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 10:57:54 -0000 Robert Watson wrote: > > On Thu, 13 Aug 2009, Tom Uffner wrote: > > > i'm hoping a few people will give me estimates on what kind of > > throughput i should theoretically expect before i provide any actual > > test data. also, any suggestions on tuning would be welcome. > > > > so far in preliminary tests, enabling polling on the network > > interfaces reduces my performance slightly both to/from and through > > the box. net.inet.ip.fastforwarding doesn't seem to make much > > difference either way but i haven't done very thorough testing of > > it. increasing net.inet.tcp.sendbuf_max & recvbuf_max may have > > helped, but again, not sufficiently tested. > > I can't speak to absolute numbers, but I wouldn't expect > net.inet.tcp.* changes to make any difference, as they should affect > only locally terminated sockets on the firewall host, not forwarded > packets. > > You might want to try experimenting with net.isr.direct -- try setting > it to 0, as this changes the kernel dispatch model for the network > stack. On a UP box, I would probably anticipate a performance loss > for making that change, or similar configuration changes for multiple > netisr threads using net.isr.maxthreads. > > If you're using firewall code, fast forwarding is unlikely > to make a difference. Depending on the cache/memory/CPU > trade-off, you might find turning off flowtable support helps -- > net.inet.flowtable.enable=0. I found that forwarding made a fantastic difference to the forwarding rate in the past. Even with firewalling - was the difference between 38kpps and 500kpps using RTL8110 gigE interfaces. Perhaps I need to retest the effect on a modern FreeBSD. As to the OP, on a VIA Epia LN - C7-1GHz with vr interfaces maxed out at 100Mbit/s. Putting gigE interfaces in the PCI slot made no difference. The bottle-neck appeared to be the number of interrupts the cards generated and the amount of time servicing interrupts, which was not affected by polling(4). Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 11:24:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE6D106568D for ; Tue, 18 Aug 2009 11:24:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 46F6F8FC6D for ; Tue, 18 Aug 2009 11:24:46 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id C47068461 for ; Tue, 18 Aug 2009 11:24:44 +0000 (UTC) Date: Tue, 18 Aug 2009 12:24:53 +0100 From: Bruce Cran To: current@freebsd.org Message-ID: <20090818122453.0000301a@unknown> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/KO9t4LLV.CTY6CnAbp8M/k." Cc: Subject: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 11:24:46 -0000 --MP_/KO9t4LLV.CTY6CnAbp8M/k. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline There appears to be a regression between 7.2 and 8.0-BETA2 with fdc(4): it used to find and attach fdc0, but now it fails to probe fdc0 but appears to initially find a nonexistant fdc1: fdc0: No FDOUT register! fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 But: fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: ic_type 90 part_id 80 fdc1: [FILTER] But then it realises it doesn't really exist later on: fdc1: output ready timeout fdc1: output ready timeout fdc1: output ready timeout fdc1: output ready timeout fdc1: output ready timeout fdc1: output ready timeout fdc1: output ready timeout [...] fdc1: output ready timeout fdc1: input ready timeout fdc1: input ready timeout fdc1: output ready timeout fdc1: input ready timeout fdc1: input ready timeout fdc1: output ready timeout fdc1: input ready timeout fdc1: input ready timeout fdc1: output ready timeout fdc1: input ready timeout fdc1: input ready timeout I've attached a full verbose boot log. I also noticed that sio(4) can still be included in a kernel configuration file but doesn't build due to the tty changes. I know people should be using uart(4) instead, but is this something that might trip people up as they move their kernel configs from 7 to 8? -- Bruce Cran --MP_/KO9t4LLV.CTY6CnAbp8M/k. Content-Type: application/octet-stream; name=dmesg_fdc Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmesg_fdc Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQkVUQTIgIzA6IFR1ZSBBdWcgMTggMDE6NTQ6 NDIgQlNUIDIwMDkKICAgIGJydWNlY0BnbHVvbi5kcmFmdG5ldDovdXNyL29iai91c3Ivc3JjL3N5 cy9HRU5FUklDCldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2Vk IHBlcmZvcm1hbmNlLgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIg YXQgMHhjMTEwMjAwMC4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDEyNTI4NTA3MTkg SHoKQ1BVOiBBTUQgQXRobG9uKFRNKSBYUCAyODAwKyAoMTI1Mi44NS1NSHogNjg2LWNsYXNzIENQ VSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDZhMCAgU3RlcHBpbmcgPSAwCiAg RmVhdHVyZXM9MHgzODNmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJ QyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRT4KICBBTUQgRmVh dHVyZXM9MHhjMDQwMDgwMDxTWVNDQUxMLE1NWCssM0ROb3chKywzRE5vdyE+CkRhdGEgVExCOiAz MiBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpJbnN0cnVjdGlvbiBUTEI6IDE2IGVudHJpZXMs IGZ1bGx5IGFzc29jaWF0aXZlCkwxIGRhdGEgY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGlu ZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0aXZlCkwxIGluc3RydWN0aW9uIGNhY2hlOiA2 NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpM MiBpbnRlcm5hbCBjYWNoZTogNTEyIGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcs IDgtd2F5IGFzc29jaWF0aXZlCnJlYWwgbWVtb3J5ICA9IDEwNzM3NDE4MjQgKDEwMjQgTUIpClBo eXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAw MDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykKMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgw MDAwMDAwMDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpCjB4MDAwMDAwMDAwMTQy NjAwMCAtIDB4MDAwMDAwMDAzZWRiMGZmZiwgMTAzMzQxNjcwNCBieXRlcyAoMjUyMjk5IHBhZ2Vz KQphdmFpbCBtZW1vcnkgPSAxMDMyMDU2ODMyICg5ODQgTUIpClRhYmxlICdGQUNQJyBhdCAweDNm ZmZjMGIyClRhYmxlICdCT09UJyBhdCAweDNmZmZjMDMwClRhYmxlICdBUElDJyBhdCAweDNmZmZj MDU4Ck1BRFQ6IEZvdW5kIHRhYmxlIGF0IDB4M2ZmZmMwNTgKQVBJQzogVXNpbmcgdGhlIE1BRFQg ZW51bWVyYXRvci4KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDA6IGVuYWJsZWQK U01QOiBBZGRlZCBDUFUgMCAoQVApCkFDUEkgQVBJQyBUYWJsZTogPEFTVVMgICBBN1YzMzMgID4K YmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVyIGF0IDB4YzAwZjFl NzAKYmlvczMyOiBFbnRyeSA9IDB4ZjE3YjAgKGMwMGYxN2IwKSAgUmV2ID0gMCAgTGVuID0gMQpw Y2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4MTdlMApwbnBiaW9zOiBGb3VuZCBQ blAgQklPUyBkYXRhIGF0IDB4YzAwZjlhNDAKcG5wYmlvczogRW50cnkgPSBmMDAwMDo5YTcwICBS ZXYgPSAxLjAKcG5wYmlvczogT0VNIElEIGNkMDQxCk90aGVyIEJJT1Mgc2lnbmF0dXJlcyBmb3Vu ZDoKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMApVTEU6IHNldHVwIGNwdSAwCkFDUEk6IFJTRFAg MHhmNWMxMCAwMDAxNCAodjAgQVNVUyAgKQpBQ1BJOiBSU0RUIDB4M2ZmZmMwMDAgMDAwMzAgKHYx IEFTVVMgICBBN1YzMzMgICA0MjMwMkUzMSBNU0ZUIDMxMzEzMDMxKQpBQ1BJOiBGQUNQIDB4M2Zm ZmMwYjIgMDAwNzQgKHYxIEFTVVMgICBBN1YzMzMgICA0MjMwMkUzMSBNU0ZUIDMxMzEzMDMxKQpB Q1BJOiBEU0RUIDB4M2ZmZmMxMjYgMDIxMjQgKHYxICAgQVNVUyBBN1YzMzMgICAwMDAwMTAwMCBN U0ZUIDAxMDAwMDBCKQpBQ1BJOiBGQUNTIDB4M2ZmZmYwMDAgMDAwNDAKQUNQSTogQk9PVCAweDNm ZmZjMDMwIDAwMDI4ICh2MSBBU1VTICAgQTdWMzMzICAgNDIzMDJFMzEgTVNGVCAzMTMxMzAzMSkK QUNQSTogQVBJQyAweDNmZmZjMDU4IDAwMDVBICh2MSBBU1VTICAgQTdWMzMzICAgNDIzMDJFMzEg TVNGVCAzMTMxMzAzMSkKTUFEVDogRm91bmQgSU8gQVBJQyBJRCAyLCBJbnRlcnJ1cHQgMCBhdCAw eGZlYzAwMDAwCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gMgppb2FwaWMwOiBSb3V0aW5n IGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBz b3VyY2UgMCwgaXJxIDIKaW9hcGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgpNQURUOiBJ bnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmln Z2VyOiBsZXZlbAppb2FwaWMwOiBpbnRwaW4gOSBwb2xhcml0eTogbG93CmxhcGljMDogUm91dGlu ZyBOTUkgLT4gTElOVDEKbGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMDogTElOVDEg cG9sYXJpdHk6IGhpZ2gKaW9hcGljMCA8VmVyc2lvbiAwLjI+IGlycXMgMC0yMyBvbiBtb3RoZXJi b2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA0MDAxMCBMRFI6 IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4 MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEw MGVmIHRoZXJtOiAweDAwMDAwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKd2xh bjogPDgwMi4xMSBMaW5rIExheWVyPgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUs IFlhcnJvdz4KbmZzbG9jazogcHNldWRvLWRldmljZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2Jk MSBhdCBrYmRtdXgwCm1lbTogPG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJs ZWQKaW86IDxJL08+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CmhwdHJyOiBSb2Nr ZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIKbnB4MDogSU5UIDE2 IGludGVyZmFjZQphY3BpMDogPEFTVVMgQTdWMzMzPiBvbiBtb3RoZXJib2FyZAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDAgdmVjdG9yIDQ4CmFjcGkwOiBb TVBTQUZFXQphY3BpMDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3Bp MDogd2FrZXVwIGNvZGUgdmEgMHhjNDJiNjAwMCBwYSAweDEwMDAKcGNpX29wZW4oMSk6CW1vZGUg MSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwMDA2MApwY2lfb3BlbigxYSk6CW1vZGUxcmVz PTB4ODAwMDAwMDAgKDB4ODAwMDAwMDApCnBjaV9jZmdjaGVjazoJZGV2aWNlIDAgW2NsYXNzPTA2 MDAwMF0gW2hkcj0wMF0gaXMgdGhlcmUgKGlkPTMwOTkxMTA2KQpwY2liaW9zOiBCSU9TIHZlcnNp b24gMi4xMAphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAw CkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5QWDQwLlBJUlEgLT4gYnVzIDAgZGV2IDE3 IGZ1bmMgMAphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAw CkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5QWDQwLlVTQkUgLT4gYnVzIDAgZGV2IDE3 IGZ1bmMgMAphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAw CkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5VU0IwLlBJUlEgLT4gYnVzIDAgZGV2IDE3 IGZ1bmMgMgphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDog cmVzZXJ2YXRpb24gb2YgMTAwMDAwLCAzZmYwMDAwMCAoMykgZmFpbGVkCkFDUEkgdGltZXI6IDEv MSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAtPiAxMApUaW1lY291bnRlciAi QUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6 IDwzMi1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHhlNDA4LTB4ZTQwYiBvbiBhY3Bp MApwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwg UHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIg MTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAx MCAxMSAxMiAxNCAxNQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDEx IDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2 IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazM6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEyICAg TiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1CiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAgMTIgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGlu azQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgICA1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyIDE0CiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIgMTQKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMiAxNAphY3Bp X2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTEw NiwgZGV2PTB4MzA5OSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwg c3RhdHJlZz0weDIyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBQcmVmZXRjaGFibGUgTWVt b3J5LCByYW5nZSAzMiwgYmFzZSAweGUwMDAwMDAwLCBzaXplIDI4LCBlbmFibGVkCmZvdW5kLT4J dmVuZG9yPTB4MTEwNiwgZGV2PTB4YjA5OSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNywgc3RhdHJlZz0weDIyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRv cj0weDEzZjYsIGRldj0weDAxMTEsIHJldmlkPTB4MTAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD01 LCBmdW5jPTAKCWNsYXNzPTA0LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAwODUsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgy MCAoOTYwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDE4ICg2MDAwIG5zKQoJ aW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJy ZW50IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ4MDAsIHNp emUgIDgsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNS5JTlRBCnBjaWIwOiBz bG90IDUgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2 PTB4MzAzOCwgcmV2aWQ9MHg1MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTksIGZ1bmM9MAoJY2xh c3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAxNywgc3RhdHJl Zz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMgoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ0MDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuOS5JTlRBCnBjaWIwOiBzbG90IDkgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHg1MAoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04IChk d29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eGQwMDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuOS5JTlRC CnBjaWIwOiBzbG90IDkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4 MTEwNiwgZGV2PTB4MzEwNCwgcmV2aWQ9MHg1MQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTksIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAx Nywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5 NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMs IGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhjYzgwMDAwMCwgc2l6ZSAgOCwgZW5hYmxl ZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC45LklOVEMKcGNpYjA6IHNsb3QgOSBJTlRDIGhh cmR3aXJlZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHgxMTgwLCBkZXY9MHgwNDc1LCByZXZp ZD0weDgwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTQsIGZ1bmM9MAoJY2xhc3M9MDYtMDctMDAs IGhkcnR5cGU9MHgwMiwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAyMTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDA3ICgxNzUwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgMzIsIGJhc2UgMCwgc2l6ZSAxMiwgbWVtb3J5IGRpc2FibGVkCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjE0LklOVEEKcGNpYjA6IHNsb3QgMTQgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4MTAwYiwgZGV2PTB4MDAyMCwgcmV2aWQ9MHgwMAoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTE2LCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MGIgKDI3NTAgbnMpLCBt YXhsYXQ9MHgzNCAoMTMwMDAgbnMpCglpbnRwaW49YSwgaXJxPTEyCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4YjgwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBNZW1v cnksIHJhbmdlIDMyLCBiYXNlIDB4Y2MwMDAwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMTYuSU5UQQpwY2liMDogc2xvdCAxNiBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMTQ3LCByZXZpZD0weDAwCglk b21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDA4Nywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApm b3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDA1NzEsIHJldmlkPTB4MDYKCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0xNywgZnVuYz0xCgljbGFzcz0wMS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGI0MDAs IHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMDM4LCByZXZp ZD0weDIzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNh Y2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWQsIGlycT0yNTUKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHhiMDAwLCBzaXplICA1LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTEw NiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHgyMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE3LCBmdW5j PTMKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMTcs IHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBp cnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGE4MDAsIHNpemUgIDUsIGVuYWJsZWQKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTcuSU5URApwY2liMDogc2xvdCAxNyBJTlREIGhhcmR3 aXJlZCB0byBJUlEgMjEKYWdwMDogPFZJQSA4MzY3IChLVDI2Ni9LWTI2NngvS1QzMzMpIGhvc3Qg dG8gUENJIGJyaWRnZT4gb24gaG9zdGIwCmhvc3RiMDogUmVzZXJ2ZWQgMHgxMDAwMDAwMCBieXRl cyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTAwMDAwMDAKYWdwMDogYWxsb2NhdGluZyBHQVRU IGZvciBhcGVydHVyZSBvZiBzaXplIDI1Nk0KYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAyNTZNCnBj aWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaWIxOiAg IGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTog ICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZTAwMC0w eGRmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhjZDAwMDAwMC0weGNmZGZmZmZmCnBj aWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4Y2ZmMDAwMDAtMHhkZmZmZmZmZgpwY2kxOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTEKZm91bmQt Pgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMmUxLCByZXZpZD0weGEyCglkb21haW49MCwgYnVzPTEs IHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNSAoMTI1MCBucyksIG1heGxhdD0weDAxICgy NTAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGNlMDAwMDAw LCBzaXplIDI0LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4Y2UwMDAw MDAtMHhjZWZmZmZmZjogZ29vZAoJbWFwWzE0XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCBy YW5nZSAzMiwgYmFzZSAweGQwMDAwMDAwLCBzaXplIDI4LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0 ZWQgbWVtb3J5IHJhbmdlIDB4ZDAwMDAwMDAtMHhkZmZmZmZmZjogZ29vZAoJbWFwWzE4XTogdHlw ZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4Y2QwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNp YjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhjZDAwMDAwMC0weGNkZmZmZmZmOiBnb29kCnBj aWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5UQQpwY2liMTogc2xvdCAwIElOVEEgaGFyZHdp cmVkIHRvIElSUSAxNgp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4Y2Uw MDAwMDAtMHhjZWZmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhjZDAwMDAwMC0weGNkZmZm ZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKcGNpMDogPG11bHRpbWVkaWEsIGF1ZGlv PiBhdCBkZXZpY2UgNS4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnVoY2kwOiA8VklBIDgzQzU3MiBV U0IgY29udHJvbGxlcj4gcG9ydCAweGQ0MDAtMHhkNDFmIGlycSAxOSBhdCBkZXZpY2UgOS4wIG9u IHBjaTAKdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAw eGQ0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTkgKFBDSSBJUlEgMTkpIHRvIGxhcGljIDAg dmVjdG9yIDQ5CnVoY2kwOiBbTVBTQUZFXQp1aGNpMDogW0lUSFJFQURdCnVzYnVzMDogPFZJQSA4 M0M1NzIgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8VklBIDgzQzU3MiBVU0IgY29u dHJvbGxlcj4gcG9ydCAweGQwMDAtMHhkMDFmIGlycSAxNiBhdCBkZXZpY2UgOS4xIG9uIHBjaTAK dWhjaTE6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGQwMDAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTYgKFBDSSBJUlEgMTYpIHRvIGxhcGljIDAgdmVjdG9y IDUwCnVoY2kxOiBbTVBTQUZFXQp1aGNpMTogW0lUSFJFQURdCnVzYnVzMTogPFZJQSA4M0M1NzIg VVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCmVoY2kwOiA8VklBIFZUNjIwMiBVU0IgMi4wIGNvbnRy b2xsZXI+IG1lbSAweGNjODAwMDAwLTB4Y2M4MDAwZmYgaXJxIDE3IGF0IGRldmljZSA5LjIgb24g cGNpMAplaGNpMDogUmVzZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAw eGNjODAwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3KSB0byBsYXBp YyAwIHZlY3RvciA1MQplaGNpMDogW01QU0FGRV0KZWhjaTA6IFtJVEhSRUFEXQp1c2J1czI6IEVI Q0kgdmVyc2lvbiAwLjk1CnVzYnVzMjogPFZJQSBWVDYyMDIgVVNCIDIuMCBjb250cm9sbGVyPiBv biBlaGNpMApjYmIwOiA8UkY1QzQ3NSBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IGlycSAxNyBhdCBkZXZp Y2UgMTQuMCBvbiBwY2kwCmNiYjA6IExhenkgYWxsb2NhdGlvbiBvZiAweDEwMDAgYnl0ZXMgcmlk IDB4MTAgdHlwZSAzIGF0IDB4ODAwMDAwMDAKY2JiMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZv ciByaWQgMHgxMCB0eXBlIDMgYXQgMHg4MDAwMDAwMApjYXJkYnVzMDogPENhcmRCdXMgYnVzPiBv biBjYmIwCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMApjYmIwOiBbTVBTQUZF XQpjYmIwOiBbRklMVEVSXQpjYmIwOiBQQ0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAw eDA0NzUxMTgwIDB4MDIxMDAwMDcgMHgwNjA3MDA4MCAweDAwMDIyMDAwIAogIDB4MTA6IDB4ODAw MDAwMDAgMHgwMjAwMDBkYyAweDIwMDMwMjAwIDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAw MCAweGZmZmZmMDAwIDB4MDAwMDAwMDAgMHhmZmZmZmZmYyAKICAweDMwOiAweDAwMDAwMDAwIDB4 ZmZmZmZmZmMgMHgwMDAwMDAwMCAweDA3MDAwMTExIAogIDB4NDA6IDB4MDEwMTE0ZWYgMHgwMDAw MDAwMSAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgCiAgMHg4MDogMHgwMDAwMDAwMSAweDAwMDAwMDAwIDB4MDQ2MzA0NjMg MHgwMDAwMDAwMCAKICAweDkwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIAogIDB4YTA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgCiAgMHhiMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAK ICAweGMwOiAweDAxMDExNGVmIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4 ZDA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4ZmUwYTAwMDEgCiAgMHhlMDog MHgyNGMwYzAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAw MDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIApzaXMwOiA8TmF0U2VtaSBE UDgzODFbNTZdIDEwLzEwMEJhc2VUWD4gcG9ydCAweGI4MDAtMHhiOGZmIG1lbSAweGNjMDAwMDAw LTB4Y2MwMDBmZmYgaXJxIDE5IGF0IGRldmljZSAxNi4wIG9uIHBjaTAKc2lzMDogUmVzZXJ2ZWQg MHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweGI4MDAKc2lzMDogU2lsaWNvbiBS ZXZpc2lvbjogRFA4MzgxNUQKbWlpYnVzMDogPE1JSSBidXM+IG9uIHNpczAKbnNwaHl0ZXIwOiA8 RFA4MzgxNSAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMCBvbiBtaWlidXMwCm5zcGh5dGVy MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8K c2lzMDogYnBmIGF0dGFjaGVkCnNpczA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjQwOmY0OjU3Ojk4 OjcxCnNpczA6IFtNUFNBRkVdCnNpczA6IFtJVEhSRUFEXQppc2FiMDogPFBDSS1JU0EgYnJpZGdl PiBhdCBkZXZpY2UgMTcuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kw OiA8VklBIDgyMzNBIFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiww eDE3MC0weDE3NywweDM3NiwweGI0MDAtMHhiNDBmIGF0IGRldmljZSAxNy4xIG9uIHBjaTAKYXRh cGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YjQwMAph dGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0 ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBv c3RhdDA9NTAgb3N0YXQxPTUwCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNi PTB4MDAKYXRhMDogc3RhdDE9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiBy ZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9NTAgZGV2aWNlcz0weDMKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIGxhcGljIDAgdmVjdG9yIDUyCmF0YTA6IFtNUFNBRkVd CmF0YTA6IFtJVEhSRUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFwY2kw OiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MAphdGFwY2kw OiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDM3NgphdGExOiBy ZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTUwCmF0YTE6IHN0YXQwPTB4NTAgZXJy PTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMTogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgx NCBtc2I9MHhlYgphdGExOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDIw MDAxCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byBsYXBpYyAwIHZl Y3RvciA1MwphdGExOiBbTVBTQUZFXQphdGExOiBbSVRIUkVBRF0KdWhjaTI6IDxWSUEgODNDNTcy IFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YjAwMC0weGIwMWYgYXQgZGV2aWNlIDE3LjIgb24gcGNp MAp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YjAw MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xNy5JTlRECnBjaWIwOiBzbG90IDE3IElOVEQg aGFyZHdpcmVkIHRvIElSUSAyMQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElSUSAy MSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTQKdWhjaTI6IFtNUFNBRkVdCnVoY2kyOiBbSVRIUkVBRF0K dWhjaTI6IExlZ1N1cCA9IDB4MDAxMAp1c2J1czM6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMgp1aGNpMzogPFZJQSA4M0M1NzIgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhhODAw LTB4YTgxZiBpcnEgMjEgYXQgZGV2aWNlIDE3LjMgb24gcGNpMAp1aGNpMzogUmVzZXJ2ZWQgMHgy MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YTgwMAp1aGNpMzogW01QU0FGRV0KdWhj aTM6IFtJVEhSRUFEXQp1aGNpMzogTGVnU3VwID0gMHgwMDEwCnVzYnVzNDogPFZJQSA4M0M1NzIg VVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0 IDB4NzAtMHg3MyBpcnEgOCBvbiBhY3BpMAphdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9m LWRheSBjbG9jayAocmVzb2x1dGlvbiAxMDAwMDAwdXMpCmZkYzE6IDxmbG9wcHkgZHJpdmUgY29u dHJvbGxlcj4gcG9ydCAweDNmMi0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMx OiBpY190eXBlIDkwIHBhcnRfaWQgODAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElS USA2KSB0byBsYXBpYyAwIHZlY3RvciA1NQpmZGMxOiBbRklMVEVSXQpwcGMwOiB1c2luZyBleHRl bmRlZCBJL08gcG9ydCByYW5nZQpwcGMwOiBTUFAgRUNQICBFQ1ArRVBQCnBwYzA6IDxQYXJhbGxl bCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4NzdiIGlycSA3IGRycSAzIG9uIGFjcGkw CnBwYzA6IFNNQy1saWtlIGNoaXBzZXQgKEVDUC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJM RSBtb2RlCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi85IGJ5dGVzIHRocmVzaG9sZAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiA3IChJU0EgSVJRIDcpIHRvIGxhcGljIDAgdmVjdG9yIDU2CnBwYzA6IFtN UFNBRkVdCnBwYzA6IFtJVEhSRUFEXQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBj MApwbGlwMDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMApwbGlwMDogYnBmIGF0 dGFjaGVkCnBsaXAwOiBbTVBTQUZFXQpwbGlwMDogW0lUSFJFQURdCmxwdDA6IDxQcmludGVyPiBv biBwcGJ1czAKbHB0MDogW01QU0FGRV0KbHB0MDogW0lUSFJFQURdCmxwdDA6IEludGVycnVwdC1k cml2ZW4gcG9ydApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAKdWFydDA6IDwxNjU1MCBv ciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0byBsYXBpYyAwIHZlY3RvciA1 Nwp1YXJ0MDogW0ZJTFRFUl0KdWFydDA6IGZhc3QgaW50ZXJydXB0CnVhcnQxOiA8MTY1NTAgb3Ig Y29tcGF0aWJsZT4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAzIChJU0EgSVJRIDMpIHRvIGxhcGljIDAgdmVjdG9yIDU4CnVhcnQxOiBbRklM VEVSXQp1YXJ0MTogZmFzdCBpbnRlcnJ1cHQKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUw OiBzd2l0Y2hpbmcgdG8gZ2VuZXJpYyBDeCBtb2RlCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBm YWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0 dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYK dW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRl c3QgZmFpbGVkIGZmCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMjgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMzQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKZXhf aXNhX2lkZW50aWZ5KCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMK cG10aW1lcjAgb24gaXNhMAphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0 YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRydGM6IGF0cnRjMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKcHBjOiBwcGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAp1YXJ0OiB1YXJ0MCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKdWFydDogdWFydDEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0CmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElT QSBPcHRpb24gUk9NPiBhdCBpb21lbSAweGQwMDAwLTB4ZDNmZmYgcG5waWQgT1JNMDAwMCBvbiBp c2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdB IDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDEsIHRlcm1p bmFsIGVtdWxhdG9yOiBzY3Rla2VuICh0ZWtlbiB0ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNB IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAph dGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBv biBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRr YmQwCmtiZDA6IGF0a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2YwMDAw CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3Ig NTkKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiBjdXJyZW50 IGNvbW1hbmQgYnl0ZTowMDY3CnBzbTA6IGZhaWxlZCB0byByZXNldCB0aGUgYXV4IGRldmljZS4K ZmRjMDogTm8gRkRPVVQgcmVnaXN0ZXIhCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgz ZjAgaXJxIDYgZHJxIDIgb24gaXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRl dmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkCmxh cGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDAyMjgwODIgaHoKVGltZWNvdW50ZXIgIlRTQyIg ZnJlcXVlbmN5IDEyNTI4NTA3MTkgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZl cnkgMS4wMDAgbXNlYwpsbzA6IGJwZiBhdHRhY2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRl Y3RlZC4KYXRhMDogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDMKYXRhMDogTmV3IGRldmlj ZXM6IDAwMDAwMDAzCmZkYzE6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzE6IG91dHB1dCByZWFk eSB0aW1lb3V0CmZkYzE6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzE6IG91dHB1dCByZWFkeSB0 aW1lb3V0CmZkYzE6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzE6IG91dHB1dCByZWFkeSB0aW1l b3V0CmZkYzE6IG91dHB1dCByZWFkeSB0aW1lb3V0CnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQg VVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDQ4ME1i cHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w CnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKYXRhMC1zbGF2ZTogcGlvPVBJTzQg d2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9ODAgd2lyZQphdGEwLW1hc3RlcjogcGlvPVBJ TzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9ODAgd2lyZQphZDA6IHNldHRpbmcgUElP NCBvbiA4MjMzQSBjaGlwCmFkMDogc2V0dGluZyBVRE1BMTAwIG9uIDgyMzNBIGNoaXAKYWQwOiA3 NjMxOU1CIDxXREMgV0Q4MDBCQi0wMENBQTEgMTcuMDdXMTc+IGF0IGF0YTAtbWFzdGVyIFVETUEx MDAKYWQwOiAxNTYzMDE0ODggc2VjdG9ycyBbMTU1MDYxQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2lu dGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkMAphZDA6IFZJQSBjaGVjazEg ZmFpbGVkCmFkMDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkMDogTFNJICh2MykgY2hlY2sxIGZh aWxlZAphZDA6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQwOiBGcmVlQlNEIGNoZWNrMSBmYWls ZWQKYWQxOiBzZXR0aW5nIFBJTzQgb24gODIzM0EgY2hpcAphZDE6IHNldHRpbmcgVURNQTEwMCBv biA4MjMzQSBjaGlwCmFkMTogNTg2NDRNQiA8SUMzNUwwNjBBVkVSMDcgMCBFUjZPQTQ2QT4gYXQg YXRhMC1zbGF2ZSBVRE1BMTAwCmFkMTogMTIwMTAzMjAwIHNlY3RvcnMgWzExOTE1MEMvMTZILzYz U10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQphZDE6IFZJQSBjaGVjazEgZmFp bGVkCmFkMTogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkMTogTFNJICh2MykgY2hlY2sxIGZhaWxl ZAphZDE6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQxOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQK YXRhMTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMjAwMDEKYXRhMTogTmV3IGRldmljZXM6IDAw MDIwMDAxCmF0YTEtc2xhdmU6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9 ODAgd2lyZQphdGExLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2Fi bGU9ODAgd2lyZQpHRU9NOiBhZDBzMTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1 NWgsNjNzICE9IDE2aCw2M3MpLgphZDI6IHNldHRpbmcgUElPNCBvbiA4MjMzQSBjaGlwCmFkMjog c2V0dGluZyBVRE1BMTAwIG9uIDgyMzNBIGNoaXAKYWQyOiAxNTI2MjdNQiA8V0RDIFdEMTYwMEpC LTAwUkVBMCAyMC4wMEsyMD4gYXQgYXRhMS1tYXN0ZXIgVURNQTEwMAphZDI6IDMxMjU4MTgwOCBz ZWN0b3JzIFszMTAxMDFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVl dWUKYWQyOiBWSUEgY2hlY2sxIGZhaWxlZApHRU9NOiBuZXcgZGlzayBhZDEKYWQyOiBBZGFwdGVj IGNoZWNrMSBmYWlsZWQKYWQyOiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkMjogTFNJICh2Mikg Y2hlY2sxIGZhaWxlZAphZDI6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphY2QwOiBzZXR0aW5nIFBJ TzQgb24gODIzM0EgY2hpcAphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiA4MjMzQSBjaGlwCmFjZDA6 IDxITC1EVC1TVCBEVkRSQU0gR1NBLTQxNjNCL0ExMDQ+IERWRFIgZHJpdmUgYXQgYXRhMSBhcyBz bGF2ZQphY2QwOiByZWFkIDY4OTBLQi9zICg2ODkwS0Ivcykgd3JpdGUgNjg5MEtCL3MgKDY4OTBL Qi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEg c3RyZWFtLCBEVkRST00sIERWRFIsIERWRFJBTSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBD RFJXLCBEVkRSLCBEVkRSQU0sIHRlc3Qgd3JpdGUsIGJ1cm5wcm9vZgphY2QwOiBBdWRpbzogcGxh eSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVjaGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5s b2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFuayBkaXNjCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApX QVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5j ZS4KdWdlbjAuMTogPFZJQT4gYXQgdXNidXMwCnVodWIwOiA8VklBIFVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKR0VPTTogbmV3IGRpc2sg YWQyCkdFT006IGFkMXMxOiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2M3Mg IT0gMTZoLDYzcykuCkdFT006IHVmc2lkLzQ5Yzg5MWZiNTY1MDVjNzc6IGdlb21ldHJ5IGRvZXMg bm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4KUm9vdCBtb3VudCB3YWl0aW5n IGZvcjogdXNidXM0IHVzYnVzMyBjYmIwIHVzYnVzMiB1c2J1czEgdXNidXMwCnVodWIwOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuMS4xOiA8VklBPiBhdCB1c2J1 czEKdWh1YjE6IDxWSUEgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWdlbjIuMTogPFZJQT4gYXQgdXNidXMyCnVodWIyOiA8VklBIEVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKZmRjMTogb3V0cHV0 IHJlYWR5IHRpbWVvdXQKZmRjMTogaW5wdXQgcmVhZHkgdGltZW91dApmZGMxOiBpbnB1dCByZWFk eSB0aW1lb3V0CmZkYzE6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzE6IGlucHV0IHJlYWR5IHRp bWVvdXQKZmRjMTogaW5wdXQgcmVhZHkgdGltZW91dApmZGMxOiBvdXRwdXQgcmVhZHkgdGltZW91 dApmZGMxOiBpbnB1dCByZWFkeSB0aW1lb3V0CmZkYzE6IGlucHV0IHJlYWR5IHRpbWVvdXQKZmRj MTogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMTogaW5wdXQgcmVhZHkgdGltZW91dApmZGMxOiBp bnB1dCByZWFkeSB0aW1lb3V0ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNCB1c2J1czMg Y2JiMCB1c2J1czIKdWh1YjI6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CnVnZW4zLjE6IDxWSUE+IGF0IHVzYnVzMwp1aHViMzogPFZJQSBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVodWIzOiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNC4xOiA8VklBPiBhdCB1c2J1czQKdWh1 YjQ6IDxWSUEgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzNAp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIGNiYjAKcGNjYXJkMDogQ0lTIHZlcnNpb24g UEMgQ2FyZCBTdGFuZGFyZCA1LjAKcGNjYXJkMDogQ0lTIGluZm86IE1FTENPLCBXTEktUENNLUwx MSwgVmVyc2lvbiAwMS4wMSwgCnBjY2FyZDA6IE1hbnVmYWN0dXJlciBjb2RlIDB4MTU2LCBwcm9k dWN0IDB4MgpwY2NhcmQwOiBmdW5jdGlvbiAwOiBuZXR3b3JrIGFkYXB0ZXIsIGNjciBhZGRyIDB4 M2UwIG1hc2sgMHgxCnBjY2FyZDA6IGZ1bmN0aW9uIDAsIGNvbmZpZyB0YWJsZSBlbnRyeSAxOiBJ L08gY2FyZDsgaXJxIG1hc2sgMHhmZmZmOyBpb21hc2sgMHg2LCBpb3NwYWNlIDAtMHgzZjsgaW8x NiBpcnFwdWxzZSBpcnFsZXZlbAp3aTA6IDxNRUxDTyBXTEktUENNLUwxMT4gYXQgcG9ydCAweDEw MC0weDEzZiBpcnEgMTcgZnVuY3Rpb24gMCBjb25maWcgMSBvbiBwY2NhcmQwCndpMDogdXNpbmcg THVjZW50IFRlY2hub2xvZ2llcywgV2F2ZUxBTi9JRUVFCndpMDogSGVybWVzIEZpcm13YXJlOiBT dGF0aW9uICg4LjM2LjEpCndpMDogMTFiIHJhdGVzOiAxTWJwcyAyTWJwcyA1LjVNYnBzIDExTWJw cwp3aTA6IFtNUFNBRkVdCndpMDogW0lUSFJFQURdCnVnZW4zLjI6IDx2ZW5kb3IgMHgwNDVlPiBh dCB1c2J1czMKdWtiZDA6IDx2ZW5kb3IgMHgwNDVlIHByb2R1Y3QgMHgwMDBiLCBjbGFzcyAwLzAs IHJldiAxLjAwLzAuODIsIGFkZHIgMj4gb24gdXNidXMzCmtiZDIgYXQgdWtiZDAKa2JkMjogdWti ZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czMKdWdlbjMuMzogPE1pY3Jvc29mdD4gYXQgdXNidXMzCnVtczA6IDxN aWNyb3NvZnQgcHJvZHVjdCAweDAwNDAsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy4wMCwgYWRkciAz PiBvbiB1c2J1czMKdW1zMDogMyBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wCnVn ZW4zLjI6IDx2ZW5kb3IgMHgwNDVlPiBhdCB1c2J1czMgKGRpc2Nvbm5lY3RlZCkKdWtiZDA6IGF0 IHVodWIzLCBwb3J0IDEsIGFkZHIgMiAoZGlzY29ubmVjdGVkKQpUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FkMHMxYQpjdF90b190cyhbMjAwOS0wOC0xOCAxMTowNDo1N10pID0g MTI1MDU5MzQ5Ny4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKdWdlbjMu MjogPHZlbmRvciAweDA0NWU+IGF0IHVzYnVzMwp1a2JkMDogPHZlbmRvciAweDA0NWUgcHJvZHVj dCAweDAwMGIsIGNsYXNzIDAvMCwgcmV2IDEuMDAvMC44MiwgYWRkciAyPiBvbiB1c2J1czMKa2Jk MiBhdCB1a2JkMAprYmQyOiB1a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZsYWdzOjB4 M2QwMDAwCkdFT006IHVmc2lkLzQ5Yzg5MWZiNTY1MDVjNzc6IGdlb21ldHJ5IGRvZXMgbm90IG1h dGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4Kc2lzMDogQXBwbHlpbmcgc2hvcnQgY2Fi bGUgZml4IChyZWc9ZjUpCnNpczA6IEFwcGx5aW5nIHNob3J0IGNhYmxlIGZpeCAocmVnPWY1KQpz aXMwOiBBcHBseWluZyBzaG9ydCBjYWJsZSBmaXggKHJlZz1mNSkKc2lzMDogQXBwbHlpbmcgc2hv cnQgY2FibGUgZml4IChyZWc9ZjQpCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhjNDlhZWRm NCB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIwODMKIDJuZCAweGQ4 NTA4ZTQwIGJ1ZndhaXQgKGJ1ZndhaXQpIEAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRk ZXAuYzo2MTc3CiAzcmQgMHhjNGM0N2JkYyB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfc3Vici5jOjIwODMKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBl cihjMGM3MzlkNyxlNmI2NDNjYyxjMDhjMGY3NSxjMDhiMWI2YixjMGM3NjhkMiwuLi4pIGF0IGRi X3RyYWNlX3NlbGZfd3JhcHBlcisweDI2CmtkYl9iYWNrdHJhY2UoYzA4YjFiNmIsYzBjNzY4ZDIs YzQ1MmJlOTAsYzQ1MmY0MzAsZTZiNjQ0MjgsLi4uKSBhdCBrZGJfYmFja3RyYWNlKzB4MjkKX3dp dG5lc3NfZGVidWdnZXIoYzBjNzY4ZDIsYzRjNDdiZGMsYzBjNjk0YzksYzQ1MmY0MzAsYzBjN2Ri NDQsLi4uKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDI1CndpdG5lc3NfY2hlY2tvcmRlcihjNGM0 N2JkYyw5LGMwYzdkYjQ0LDgyMywwLC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODM5Cl9f bG9ja21ncl9hcmdzKGM0YzQ3YmRjLDgwMTAwLGM0YzQ3YmY4LDAsMCwuLi4pIGF0IF9fbG9ja21n cl9hcmdzKzB4N2E3CmZmc19sb2NrKGU2YjY0NTM4LGMwOGMwZDFiLGMwYzdkMDM3LDgwMTAwLGM0 YzQ3Yjg0LC4uLikgYXQgZmZzX2xvY2srMHg4YQpWT1BfTE9DSzFfQVBWKGMwZDc3MDYwLGU2YjY0 NTM4LGM0OTcyZTI0LGMwZDhmYTgwLGM0YzQ3Yjg0LC4uLikgYXQgVk9QX0xPQ0sxX0FQVisweGI1 Cl92bl9sb2NrKGM0YzQ3Yjg0LDgwMTAwLGMwYzdkYjQ0LDgyMyw0LC4uLikgYXQgX3ZuX2xvY2sr MHg1ZQp2Z2V0KGM0YzQ3Yjg0LDgwMTAwLGM0OTcyZDgwLDUwLDAsLi4uKSBhdCB2Z2V0KzB4YjkK dmZzX2hhc2hfZ2V0KGM0OTY1NzhjLGMwYzIsODAwMDAsYzQ5NzJkODAsZTZiNjQ2OTQsLi4uKSBh dCB2ZnNfaGFzaF9nZXQrMHhlNgpmZnNfdmdldGYoYzQ5NjU3OGMsYzBjMiw4MDAwMCxlNmI2NDY5 NCwxLC4uLikgYXQgZmZzX3ZnZXRmKzB4NDkKc29mdGRlcF9zeW5jX21ldGFkYXRhKGM0OWFlZDlj LDAsYzBjOTcyY2UsMTQ2LDAsLi4uKSBhdCBzb2Z0ZGVwX3N5bmNfbWV0YWRhdGErMHg1YmEKZmZz X3N5bmN2bm9kZShjNDlhZWQ5YywxLGMwYzZlZjNkLGMwYzY4YjQ2LDMsLi4uKSBhdCBmZnNfc3lu Y3Zub2RlKzB4M2UyCmZmc190cnVuY2F0ZShjNDlhZWQ5YywyMDAsMCw4ODAsYzQ1NmMxMDAsLi4u KSBhdCBmZnNfdHJ1bmNhdGUrMHg2NmEKdWZzX2RpcmVudGVyKGM0OWFlZDljLGM0YzQ3Yjg0LGU2 YjY0YTFjLGU2YjY0YzAwLGQ4NTA5MWQwLC4uLikgYXQgdWZzX2RpcmVudGVyKzB4OGY2CnVmc19t a2RpcihlNmI2NGMyOCxlNmI2NGMzYywwLDAsZTZiNjRiNmMsLi4uKSBhdCB1ZnNfbWtkaXIrMHg4 YTcKVk9QX01LRElSX0FQVihjMGQ3NzA2MCxlNmI2NGMyOCxlNmI2NGMwMCxlNmI2NGI2YywwLC4u LikgYXQgVk9QX01LRElSX0FQVisweGE1Cmtlcm5fbWtkaXJhdChjNDk3MmQ4MCxmZmZmZmY5Yyxi ZmJmZWY1YSwwLDFmZiwuLi4pIGF0IGtlcm5fbWtkaXJhdCsweDIyYgprZXJuX21rZGlyKGM0OTcy ZDgwLGJmYmZlZjVhLDAsMWZmLGU2YjY0ZDJjLC4uLikgYXQga2Vybl9ta2RpcisweDJlCm1rZGly KGM0OTcyZDgwLGU2YjY0Y2Y4LDgsYzBjNzcxZDMsYzBkNTY2ZTAsLi4uKSBhdCBta2RpcisweDI5 CnN5c2NhbGwoZTZiNjRkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0 IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoMTM2LCBGcmVlQlNEIEVMRjMyLCBt a2RpciksIGVpcCA9IDB4MjgxNjk4ZTMsIGVzcCA9IDB4YmZiZmVkNmMsIGVicCA9IDB4YmZiZmVl MzggLS0tCnNwbGFzaDogaW1hZ2UgZGVjb2RlciBmb3VuZDogYmxhbmtfc2F2ZXIKbG9jayBvcmRl ciByZXZlcnNhbDoKIDFzdCAweGM0OWFhMzJjIGZpbGVkZXNjIHN0cnVjdHVyZSAoZmlsZWRlc2Mg c3RydWN0dXJlKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6MTIxMQogMm5kIDB4 YzRjYjI3YWMgZGV2ZnMgKGRldmZzKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjg2 MwpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMwYzczOWQ3LGU2 YmI5OTUwLGMwOGMwZjc1LGMwOGIxYjZiLGMwYzc2OGI5LC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKzB4MjYKa2RiX2JhY2t0cmFjZShjMDhiMWI2YixjMGM3NjhiOSxjNDUyYzE2OCxjNDUy ZjM2MCxlNmJiOTlhYywuLi4pIGF0IGtkYl9iYWNrdHJhY2UrMHgyOQpfd2l0bmVzc19kZWJ1Z2dl cihjMGM3NjhiOSxjNGNiMjdhYyxjMGM2NTgyNCxjNDUyZjM2MCxjMGM3ZWQwZCwuLi4pIGF0IF93 aXRuZXNzX2RlYnVnZ2VyKzB4MjUKd2l0bmVzc19jaGVja29yZGVyKGM0Y2IyN2FjLDksYzBjN2Vk MGQsMzVmLGM0Y2IyN2M4LC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODM5Cl9fbG9ja21n cl9hcmdzKGM0Y2IyN2FjLDgwNDAwLGM0Y2IyN2M4LDAsMCwuLi4pIGF0IF9fbG9ja21ncl9hcmdz KzB4N2E3CnZvcF9zdGRsb2NrKGU2YmI5YWI0LGM0YWIwMGE4LGU2YmI5YjhjLDgwNDAwLGM0Y2Iy NzU0LC4uLikgYXQgdm9wX3N0ZGxvY2srMHg2MgpWT1BfTE9DSzFfQVBWKGMwZDUyNDAwLGU2YmI5 YWI0LDdjYSxjMGQ4ZmE4MCxjNGNiMjc1NCwuLi4pIGF0IFZPUF9MT0NLMV9BUFYrMHhiNQpfdm5f bG9jayhjNGNiMjc1NCw4MDQwMCxjMGM3ZWQwZCwzNWYsMCwuLi4pIGF0IF92bl9sb2NrKzB4NWUK dm5fcG9sbChjNDk3NjExOCwxLGM0YzViMDAwLGM0Y2EwMjQwLGU2YmI5YjVjLC4uLikgYXQgdm5f cG9sbCsweDc3CnBvbGwoYzRjYTAyNDAsZTZiYjljZjgsYyxjMGM3NzNmYyxjMGQ1NmVkYywuLi4p IGF0IHBvbGwrMHgyMGMKc3lzY2FsbChlNmJiOWQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4 MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICgyMDksIEZy ZWVCU0QgRUxGMzIsIHBvbGwpLCBlaXAgPSAweDI4MzAzMzRmLCBlc3AgPSAweGJmYmZlMzJjLCBl YnAgPSAweGJmYmZlMzQ4IC0tLQo= --MP_/KO9t4LLV.CTY6CnAbp8M/k.-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:22:23 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2654C106568B for ; Tue, 18 Aug 2009 12:22:23 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id B62088FC16 for ; Tue, 18 Aug 2009 12:22:22 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n7IBqAsp001525; Tue, 18 Aug 2009 12:52:10 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MdNEY-000312-LA; Tue, 18 Aug 2009 12:52:10 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n7IBqAfK043240; Tue, 18 Aug 2009 12:52:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n7IBqA1R043239; Tue, 18 Aug 2009 12:52:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Bruce Cran In-Reply-To: <20090818122453.0000301a@unknown> References: <20090818122453.0000301a@unknown> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 18 Aug 2009 12:52:09 +0100 Message-Id: <1250596329.41855.20.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: current@FreeBSD.org Subject: Re: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:22:23 -0000 On Tue, 2009-08-18 at 12:24 +0100, Bruce Cran wrote: > There appears to be a regression between 7.2 and 8.0-BETA2 with fdc(4): > it used to find and attach fdc0, but now it fails to probe fdc0 but > appears to initially find a nonexistant fdc1: "devinfo -rv" from both 7 and 8, and verbose dmesg from both (best on Pastebin or in a PR, not to the mailing list!) will probably be useful in determining what's up. It would also be worth removing any hints for the floppy drive from /boot/device.hints (assuming mergemaster didn't do this for you) and seeing if that makes a difference. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:22:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383711065765 for ; Tue, 18 Aug 2009 12:22:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EDA5C8FC55 for ; Tue, 18 Aug 2009 12:22:31 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MdNOF-000DhP-53 for current@freebsd.org; Tue, 18 Aug 2009 15:02:11 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Aug 2009 15:02:11 +0300 From: Danny Braniss Message-ID: Cc: Subject: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:22:32 -0000 it seems that the latest changes to zfs prevents zpool to see/find the pool in /dev/ad0p4 (BTW, the pool was created under 8.0) # gpart show => 34 1953525101 ad0 GPT (932G) 34 128 1 freebsd-boot (64K) 162 4194304 2 freebsd-ufs (2.0G) 4194466 8388608 3 freebsd-swap (4.0G) 12583074 1940942061 4 freebsd-zfs (926G) # zpool list no pools available # zpool import -a # under 7.2, the pool is still there: pundit-2> zfs list NAME USED AVAIL REFER MOUNTPOINT z 5.27G 900G 18K /z z/home 5.21G 900G 5.21G /home z/var 59.7M 900G 59.7M /var pundit-2> zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT z 920G 5.27G 915G 0% ONLINE - From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:31:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13234106568B; Tue, 18 Aug 2009 12:31:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC1028FC45; Tue, 18 Aug 2009 12:31:18 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 778D546B37; Tue, 18 Aug 2009 08:31:18 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C977C8A01B; Tue, 18 Aug 2009 08:31:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 18 Aug 2009 08:30:58 -0400 User-Agent: KMail/1.9.7 References: <20090818122453.0000301a@unknown> In-Reply-To: <20090818122453.0000301a@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908180830.58904.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 18 Aug 2009 08:31:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Bruce Cran , current@freebsd.org Subject: Re: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:31:19 -0000 On Tuesday 18 August 2009 7:24:53 am Bruce Cran wrote: > There appears to be a regression between 7.2 and 8.0-BETA2 with fdc(4): > it used to find and attach fdc0, but now it fails to probe fdc0 but > appears to initially find a nonexistant fdc1: > > fdc0: No FDOUT register! > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > But: > > fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 fdc1: ic_type 90 part_id 80 > fdc1: [FILTER] > > But then it realises it doesn't really exist later on: > > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > [...] > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > > I've attached a full verbose boot log. I think fdc0 will work if you remove the fdc0 hints. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13234106568B; Tue, 18 Aug 2009 12:31:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC1028FC45; Tue, 18 Aug 2009 12:31:18 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 778D546B37; Tue, 18 Aug 2009 08:31:18 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C977C8A01B; Tue, 18 Aug 2009 08:31:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 18 Aug 2009 08:30:58 -0400 User-Agent: KMail/1.9.7 References: <20090818122453.0000301a@unknown> In-Reply-To: <20090818122453.0000301a@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908180830.58904.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 18 Aug 2009 08:31:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Bruce Cran , current@freebsd.org Subject: Re: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:31:19 -0000 On Tuesday 18 August 2009 7:24:53 am Bruce Cran wrote: > There appears to be a regression between 7.2 and 8.0-BETA2 with fdc(4): > it used to find and attach fdc0, but now it fails to probe fdc0 but > appears to initially find a nonexistant fdc1: > > fdc0: No FDOUT register! > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > But: > > fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 fdc1: ic_type 90 part_id 80 > fdc1: [FILTER] > > But then it realises it doesn't really exist later on: > > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > fdc1: output ready timeout > [...] > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > fdc1: output ready timeout > fdc1: input ready timeout > fdc1: input ready timeout > > I've attached a full verbose boot log. I think fdc0 will work if you remove the fdc0 hints. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:34:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B1D106568D for ; Tue, 18 Aug 2009 12:34:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 017B78FC59 for ; Tue, 18 Aug 2009 12:34:15 +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 PAA24376; Tue, 18 Aug 2009 15:18:55 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A8A9C2E.7000409@icyb.net.ua> Date: Tue, 18 Aug 2009 15:18:54 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Bruce Cran References: <20090818122453.0000301a@unknown> In-Reply-To: <20090818122453.0000301a@unknown> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:34:16 -0000 on 18/08/2009 14:24 Bruce Cran said the following: > There appears to be a regression between 7.2 and 8.0-BETA2 with fdc(4): > it used to find and attach fdc0, but now it fails to probe fdc0 but > appears to initially find a nonexistant fdc1: > > fdc0: No FDOUT register! > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > But: > > fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 fdc1: ic_type 90 part_id 80 > fdc1: [FILTER] I think that this could be related to device.hints? Could you please compare the fdc hints (if any) between the versions? Could you please try removing any fdc hints from 8.0 config? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:45:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FBA106568E; Tue, 18 Aug 2009 12:45:31 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay3-v.mail.gandi.net (relay3-v.mail.gandi.net [217.70.178.77]) by mx1.freebsd.org (Postfix) with ESMTP id BE7B28FC61; Tue, 18 Aug 2009 12:45:30 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id B9EECB9FF; Tue, 18 Aug 2009 14:45:26 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 5D499F0A8; Tue, 18 Aug 2009 08:44:31 -0400 (EDT) Date: Tue, 18 Aug 2009 08:44:31 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090818124429.GA1483@plebeian.afflictions.org> References: <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> <20090813191724.GA1499@plebeian.afflictions.org> <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> <20090818051659.GA1477@plebeian.afflictions.org> <3bbf2fe10908172252t3b176f06r5ae46fed6644df7c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3bbf2fe10908172252t3b176f06r5ae46fed6644df7c@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:45:31 -0000 Attilio Rao wrote: : > : Hans suggested to try this patch: : > : http://p4db.freebsd.org/chv.cgi?CH=167286 : > : > I've applied the patch, and the panic no longer happens.  Unfortunately, I : > still no longer receive my display; the behaviour of the system has gone : > back to before the removal of SKIPSPIN from GENERIC. : : You should now retry the past instructions I gave you breaking in DDB : when you get the deadlock (ctrl+alt+esc will do it, for example). Right, sorry. It took me about an hour to generate this. It appears as though the system, more often than not, becomes completely unresponsive after resume (no keyboard, no network). The ddb output seems like it was cut short. I'll try to generate a new dump in a bit. ----- begin version.txt FreeBSD 8.0-BETA2 #1 r196196M: Tue Aug 18 00:21:53 EDT 2009 dgerow@plebeian.afflictions.org:/usr/obj/usr/src/sys/GENERIC.NOSKIPSPIN ----- end version.txt ----- begin msgbuf.txt KDB: enter: manual escape to debugger exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff000a654e40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex Giant (Giant) r = 1 (0xffffffff80bdbfa0) locked @ /usr/src/sys/dev/syscons/syscons.c:596 ----- end msgbuf.txt ----- begin ddb.txt db:0:kdb.enter.default> show allpcpu Current CPU: 1 cpuid = 0 dynamic pcpu = 0x56ff00 curthread = 0xffffff00024f6390: pid 11 "idle: cpu0" curpcb = 0xffffff800002dd40 fpcurthread = none idlethread = 0xffffff00024f6390: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80de7900 commontssp = 0xffffffff80de7900 rsp0 = 0xffffff800002dd40 gs32p = 0xffffffff80de6738 ldt = 0xffffffff80de6778 tss = 0xffffffff80de6768 spin locks held: cpuid = 1 dynamic pcpu = 0xffffff807f483f00 curthread = 0xffffff0002512000: pid 12 "swi6: Giant taskq" curpcb = 0xffffff8000072d40 fpcurthread = none idlethread = 0xffffff00024f6720: pid 11 "idle: cpu1" curpmap = 0 tssp = 0xffffffff80de7968 commontssp = 0xffffffff80de7968 rsp0 = 0xffffff8000072d40 gs32p = 0xffffffff80de67a0 ldt = 0xffffffff80de67e0 tss = 0xffffffff80de67d0 spin locks held: db:0:kdb.enter.default> bt Tracing pid 12 tid 100017 td 0xffffff0002512000 kdb_enter() at kdb_enter+0x3d scgetc() at scgetc+0x5e8 sckbdevent() at sckbdevent+0x1fc kbdmux_intr() at kbdmux_intr+0x24 kbdmux_kbd_intr() at kbdmux_kbd_intr+0x23 taskqueue_run() at taskqueue_run+0xf3 taskqueue_swi_giant_run() at taskqueue_swi_giant_run+0x10 intr_event_execute_handlers() at intr_event_execute_handlers+0x107 ithread_loop() at ithread_loop+0xbe fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000072d30, rbp = 0 --- db:0:kdb.enter.default> ps pid ppid pgrp uid state wmesg wchan cmd 1534 1527 1534 1001 S+ select 0xffffff000a5eecc0 ssh 1527 1448 1527 1001 Ss+ pause 0xffffff000a215500 zsh 1524 1503 1491 1001 S futex 0xffffff0003e7fa60 npviewer.bin 1523 1503 1491 1001 S futex 0xffffff00026cd900 npviewer.bin 1520 1503 1491 1001 S select 0xffffff001cf7fc40 npviewer.bin 1515 1 1514 1001 S select 0xffffff001caa4bc0 initial thread 1510 1 1508 1001 S select 0xffffff001ca90a40 initial thread 1508 1 1508 1001 Ss select 0xffffff001c9333c0 dbus-daemon 1507 1 1491 1001 S select 0xffffff001c9298c0 dbus-launch 1503 1499 1491 1001 S (threaded) firefox-bin 100236 S ucond 0xffffff001cd29980 firefox-bin 100235 S ucond 0xffffff000a140780 firefox-bin 100232 S ucond 0xffffff001cd63300 firefox-bin 100231 S ucond 0xffffff000aa30800 firefox-bin 100228 S ucond 0xffffff001cd78000 firefox-bin 100227 S ucond 0xffffff001cd29a80 firefox-bin 100230 S ucond 0xffffff001cd63080 firefox-bin 100229 S ucond 0xffffff001ca91500 firefox-bin 100226 S ucond 0xffffff0003a05780 firefox-bin 100225 S select 0xffffff001c933240 firefox-bin 100224 S ucond 0xffffff000a342600 firefox-bin 100164 S select 0xffffff000a899540 initial thread 1499 1491 1491 1001 S wait 0xffffff0003f64460 sh 1491 1 1491 1001 Ss wait 0xffffff000a6b68c0 sh 1472 1448 1472 1001 Ss+ ttyin 0xffffff0003536ca8 zsh 1469 1 1456 1001 S select 0xffffff000aa30b40 conky 1468 1 1458 1001 S select 0xffffff000a5ed3c0 conky 1467 1 1460 1001 S select 0xffffff0003df18c0 conky 1466 1460 1460 1001 S select 0xffffff000a5ee5c0 dzen2 1464 1458 1458 1001 S select 0xffffff000aa315c0 dzen2 1462 1456 1456 1001 S select 0xffffff001c4ed540 dzen2 1460 1 1460 1001 Ss wait 0xffffff000a215000 sh 1458 1 1458 1001 Ss wait 0xffffff0003a70460 sh 1456 1 1456 1001 Ss wait 0xffffff0003a6f000 sh 1454 1 1454 1001 Ss select 0xffffff001c371740 dzen2 1452 1442 1442 1001 S+ select 0xffffff000a881040 dzen2 1451 1442 1442 1001 S+ select 0xffffff001c350bc0 xmonad-x86_64-freeb 1448 1 1442 1001 S+ select 0xffffff0003fea3c0 urxvtd 1447 1 1442 1001 S+ sbwait 0xffffff000a654e8c urxvtd 1445 1 1445 1001 Ss select 0xffffff000a140240 ssh-agent 1442 1438 1442 1001 S+ wait 0xffffff000a6b7000 sh 1439 1438 1439 1001 S+ drmwtq 0xffffff000266c13c initial thread 1438 1420 1420 1001 S+ wait 0xffffff000a6b4000 xinit 1420 1414 1420 1001 S+ wait 0xffffff000a6b7460 sh 1414 1363 1414 1001 S+ pause 0xffffff0003a6f500 zsh 1384 1379 1375 0 S kqread 0xffffff000a47e500 initial thread 1379 1375 1375 0 S select 0xffffff0003dea140 initial thread 1378 1 1378 0 Ss (threaded) console-kit-daemon 100199 S waitvt 0xffffffff80bd79c0 console-kit-daemon 100206 S waitvt 0xffffffff80bd7a38 console-kit-daemon 100205 S waitvt 0xffffffff80bd7a30 console-kit-daemon 100204 S waitvt 0xffffffff80bd7a28 console-kit-daemon 100203 S waitvt 0xffffffff80bd7a20 console-kit-daemon 100202 S waitvt 0xffffffff80bd7a18 console-kit-daemon 100201 S waitvt 0xffffffff80bd7a10 console-kit-daemon 100200 S waitvt 0xffffffff80bd7a08 console-kit-daemon 100198 S waitvt 0xffffffff80bd79f8 console-kit-daemon 100197 S waitvt 0xffffffff80bd79f0 console-kit-daemon 100196 S waitvt 0xffffffff80bd79e8 console-kit-daemon 100195 S waitvt 0xffffffff80bd79e0 console-kit-daemon 100194 S waitvt 0xffffffff80bd79d8 console-kit-daemon 100193 S waitvt 0xffffffff80bd79d0 console-kit-daemon 100192 S waitvt 0xffffffff80bd79c8 console-kit-daemon 100191 S ucond 0xffffff000a18f880 console-kit-daemon 100165 S select 0xffffff000a140340 console-kit-daemon 1375 1 1375 560 Ss select 0xffffff0003fea340 hald 1370 1 1370 0 Ss+ ttyin 0xffffff000354a8a8 getty 1369 1 1369 0 Ss+ ttyin 0xffffff000353e8a8 getty 1368 1 1368 0 Ss+ ttyin 0xffffff000354b0a8 getty 1367 1 1367 0 Ss+ ttyin 0xffffff000353fca8 getty 1366 1 1366 0 Ss+ ttyin 0xffffff000354e4a8 getty 1365 1 1365 0 Ss+ ttyin 0xffffff000353cca8 getty 1364 1 1364 0 Ss+ ttyin 0xffffff00025050a8 getty 1363 1 1363 0 Ss+ wait 0xffffff0003bc28c0 login 1307 1 1307 0 Ss nanslp 0xffffffff80bdcbe8 cron 1298 1 1298 0 Ss select 0xffffff000a32c840 sshd 1255 1 1255 556 Ss select 0xffffff000a13f4c0 dbus-daemon 1249 1239 1239 125 S kqread 0xffffff000a387100 qmgr 1248 1239 1239 125 S kqread 0xffffff000a387b00 pickup 1239 1 1239 0 Ss kqread 0xffffff000a155d00 master 1121 1 1121 65 Ss select 0xffffff000a1405c0 dhclient 1104 1 1104 0 Ss select 0xffffff000a1411c0 dhclient 1080 1 1080 0 Ss kqread 0xffffff000a043500 cupsd 1037 1 1037 0 Ss select 0xffffff0003df12c0 powerd 963 1 963 0 Ss rpcsvc 0xffffff0003d3b720 NLM: master 950 1 950 0 Ss select 0xffffff0003d552c0 rpc.statd 948 1 948 0 Ss select 0xffffff0003bf40c0 rpcbind 874 0 0 0 SL mdwait 0xffffff0003fad000 [md0] 825 1 825 0 Ss select 0xffffff0003d55340 syslogd 728 0 0 0 SL - 0xffffffff80bd9c40 [accounting] 655 1 655 0 Ss select 0xffffff0003bf31c0 devd 285 0 0 0 SL tq->tq_d 0xffffff0003a4dba0 [zil_clean] 284 0 0 0 SL tq->tq_d 0xffffff0003a4c060 [zil_clean] 283 0 0 0 SL tq->tq_d 0xffffff0003aac3c0 [zil_clean] 282 0 0 0 SL tq->tq_d 0xffffff0003aac4e0 [zil_clean] 281 0 0 0 SL tq->tq_d 0xffffff0003aac600 [zil_clean] 280 0 0 0 SL tq->tq_d 0xffffff0003aac720 [zil_clean] 279 0 0 0 SL tq->tq_d 0xffffff0003aac840 [zil_clean] 278 0 0 0 SL tq->tq_d 0xffffff0003aac960 [zil_clean] 277 0 0 0 SL tq->tq_d 0xffffff0003aaca80 [zil_clean] 276 0 0 0 SL tq->tq_d 0xffffff0003aacba0 [zil_clean] 275 0 0 0 SL tx->tx_s 0xffffff0003594e38 [txg_thread_enter] 274 0 0 0 SL tx->tx_q 0xffffff0003594e58 [txg_thread_enter] 273 0 0 0 SL vgeom:io 0xffffff000397ba90 [vdev:worker ad4s1d.] 272 0 0 0 SL tq->tq_d 0xffffff0003a4da80 [spa_zio] 271 0 0 0 SL tq->tq_d 0xffffff0003a4d960 [spa_zio] 270 0 0 0 SL tq->tq_d 0xffffff0003a4d840 [spa_zio] 269 0 0 0 SL tq->tq_d 0xffffff0003a4d720 [spa_zio] 268 0 0 0 SL tq->tq_d 0xffffff0003a4d600 [spa_zio] 267 0 0 0 SL tq->tq_d 0xffffff0003a4d4e0 [spa_zio] 266 0 0 0 SL tq->tq_d 0xffffff0003a4dcc0 [spa_zio] 265 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 264 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 263 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 262 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 261 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 260 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 259 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 258 0 0 0 SL tq->tq_d 0xffffff0003aac180 [spa_zio] 257 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 256 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 255 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 254 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 253 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 252 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 251 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 250 0 0 0 SL tq->tq_d 0xffffff0003aac2a0 [spa_zio] 249 0 0 0 SL tq->tq_d 0xffffff0003a4c180 [spa_zio] 248 0 0 0 SL tq->tq_d 0xffffff0003a4c2a0 [spa_zio] 247 0 0 0 SL tq->tq_d 0xffffff0003a4c3c0 [spa_zio] 192 0 0 0 SL geli:w 0xffffff000369b000 [g_eli[1] ad4s1d] 191 0 0 0 SL geli:w 0xffffff000369b000 [g_eli[0] ad4s1d] 186 0 0 0 SL crypto_r 0xffffffff81339900 [crypto returns] 185 0 0 0 SL crypto_w 0xffffffff813398c0 [crypto] 75 0 0 0 SL l2arc_fe 0xffffffff8130bec0 [l2arc_feed_thread] 74 0 0 0 SL arc_recl 0xffffffff813038e0 [arc_reclaim_thread] 72 0 0 0 SL vacv 0xffffffff813025e0 [vaclean] 71 0 0 0 SL tq->tq_d 0xffffff0003a4d060 [system_taskq] 70 0 0 0 SL tq->tq_d 0xffffff0003a4d060 [system_taskq] 52 0 0 0 SL flowclea 0xffffffff80bdc8c4 [flowcleaner] 51 0 0 0 SL sdflush 0xffffffff80dad358 [softdepflush] 50 0 0 0 SL syncer 0xffffffff80d9e1c0 [syncer] 49 0 0 0 SL vlruwt 0xffffff00035da000 [vnlru] 48 0 0 0 SL psleep 0xffffffff80d9dce8 [bufdaemon] 9 0 0 0 SL pgzero 0xffffffff80daedac [pagezero] 8 0 0 0 SL psleep 0xffffffff80dae148 [vmdaemon] 7 0 0 0 SL psleep 0xffffffff80dae10c [pagedaemon] 47 0 0 0 SL wmsg 0xffffff8000326dd0 [usbus7] 46 0 0 0 SL wmsg 0xffffff8000326d78 [usbus7] 45 0 0 0 SL wmsg 0xffffff8000326d20 [usbus7] 44 0 0 0 SL wmsg 0xffffff8000326cc8 [usbus7] 43 0 0 0 SL wmsg 0xffffff800031def0 [usbus6] 42 0 0 0 SL wmsg 0xffffff800031de98 [usbus6] 41 0 0 0 SL wmsg 0xffffff800031de40 [usbus6] 40 0 0 0 SL wmsg 0xffffff800031dde8 [usbus6] 39 0 0 0 SL wmsg 0xffffff8000314ef0 [usbus5] 38 0 0 0 SL wmsg 0xffffff8000314e98 [usbus5] 37 0 0 0 SL wmsg 0xffffff8000314e40 [usbus5] 36 0 0 0 SL wmsg 0xffffff8000314de8 [usbus5] 35 0 0 0 SL wmsg 0xffffff800030bef0 [usbus4] 34 0 0 0 SL wmsg 0xffffff800030be98 [usbus4] 33 0 0 0 SL wmsg 0xffffff800030be40 [usbus4] 32 0 0 0 SL wmsg 0xffffff800030bde8 [usbus4] 31 0 0 0 SL wmsg 0xffffff8000302dd0 [usbus3] 30 0 0 0 SL wmsg 0xffffff8000302d78 [usbus3] 29 0 0 0 SL wmsg 0xffffff8000302d20 [usbus3] 28 0 0 0 SL wmsg 0xffffff8000302cc8 [usbus3] 27 0 0 0 SL wmsg 0xffffff80002f9ef0 [usbus2] 26 0 0 0 SL wmsg 0xffffff80002f9e98 [usbus2] 25 0 0 0 SL wmsg 0xffffff80002f9e40 [usbus2] 24 0 0 0 SL wmsg 0xffffff80002f9de8 [usbus2] 23 0 0 0 SL wmsg 0xffffff80002f0ef0 [usbus1] 22 0 0 0 SL wmsg 0xffffff80002f0e98 [usbus1] 21 0 0 0 SL wmsg 0xffffff80002f0e40 [usbus1] 20 0 0 0 SL wmsg 0xffffff80002f0de8 [usbus1] 19 0 0 0 SL wmsg 0xffffff80002e7ef0 [usbus0] 18 0 0 0 SL wmsg 0xffffff80002e7e98 [usbus0] 17 0 0 0 SL wmsg 0xffffff80002e7e40 [usbus0] 16 0 0 0 SL wmsg 0xffffff80002e7de8 [usbus0] 6 0 0 0 SL waiting_ 0xffffffff80da10e0 [sctp_iterator] 15 0 0 0 SL cooling 0xffffff000352ad58 [acpi_cooling1] 14 0 0 0 SL tzpoll 0xffffffff80baa210 [acpi_thermal] 5 0 0 0 SL ccb_scan 0xffffffff80ba5b60 [xpt_thrd] 13 0 0 0 SL - 0xffffffff80bdc8c4 [yarrow] 4 0 0 0 SL - 0xffffffff80bd90a8 [g_down] 3 0 0 0 SL - 0xffffffff80bd90a0 [g_up] 2 0 0 0 SL - 0xffffffff80bd9090 [g_event] 12 0 0 0 RL (threaded) intr 100222 I [irq256:] 100039 I [irq12: psm0] 100038 I [irq1: atkbd0] 100035 I [irq19: ehci1] 100034 I [irq18: uhci5] 100033 I [irq17: uhci4] 100032 I [irq16: uhci3+] 100031 I [irq258: hdac0] 100030 I [irq23: ehci0+] 100029 I [irq22: uhci2] 100028 I [irq21: uhci1] 100027 I [irq20: uhci0] 100025 I [irq9: acpi0] 100024 I [swi2: cambio] 100018 I [swi6: task queue] 100017 Run CPU 1 [swi6: Giant taskq] 100014 I [swi5: +] 100008 I [swi3: vm] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 I [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 Run CPU 0 [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff00024f48c0 [init] 10 0 0 0 SL audit_wo 0xffffffff80dac6b0 [audit] 0 0 0 0 SLs (threaded) kernel 100026 D - 0xffffff0002726500 [em0 taskq] 100022 D - 0xffffff000265a300 [kqueue taskq] 100021 D - 0xffffff000261fc80 [acpi_task_2] 100020 D - 0xffffff000261fc80 [acpi_task_1] 100019 D - 0xffffff000261fc80 [acpi_task_0] 100016 D - 0xffffff000265a080 [aiod_bio taskq] 100015 D - 0xffffff000265a100 [thread taskq] 100012 D - 0xffffff00024f8580 [firmware taskq] 100000 D sched 0xffffffff80bd91a0 [swapper] db:0:kdb.enter.default> alltrace Tracing command ssh pid 1534 tid 100115 td 0xffffff0003a08ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x800f5b0cc, rsp = 0x7fffffffc1e8, rbp = 0x7fffffffc300 --- Tracing command zsh pid 1527 tid 100179 td 0xffffff0003f6c390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_sigsuspend() at kern_sigsuspend+0xcd sigsuspend() at sigsuspend+0x34 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x800b562ac, rsp = 0x7fffffffe838, rbp = 0 --- Tracing command npviewer.bin pid 1524 tid 100166 td 0xffffff0003a69720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 linux_sys_futex() at linux_sys_futex+0x6b9 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28767f60, rsp = 0x32a4e2b0, rbp = 0x32a4e2f8 --- Tracing command npviewer.bin pid 1523 tid 100122 td 0xffffff0003aa2000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 linux_sys_futex() at linux_sys_futex+0x6b9 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28767f60, rsp = 0x2ea4e2b0, rbp = 0x2ea4e2f8 --- Tracing command npviewer.bin pid 1520 tid 100218 td 0xffffff000a8b6390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (168, Linux ELF32, poll), rip = 0x2886682d, rsp = 0xffffd5c4, rbp = 0xffffd5d8 --- Tracing command gam_server pid 1515 tid 100183 td 0xffffff000a329390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800de24dc, rsp = 0x7fffffffe538, rbp = 0x5 --- Tracing command gconfd-2 pid 1510 tid 100175 td 0xffffff0003f6d390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x80162f4dc, rsp = 0x7fffffffe488, rbp = 0x7 --- Tracing command dbus-daemon pid 1508 tid 100151 td 0xffffff0003b22390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8009544dc, rsp = 0x7fffffffe0b8, rbp = 0 --- Tracing command dbus-launch pid 1507 tid 100167 td 0xffffff0003f7d390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8010ba0cc, rsp = 0x7fffffffe038, rbp = 0x6 --- Tracing command firefox-bin pid 1503 tid 100236 td 0xffffff001cdc3ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffdbeee08, rbp = 0x80d7b2140 --- Tracing command firefox-bin pid 1503 tid 100235 td 0xffffff000a55c720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffddefe08, rbp = 0x80d7b24c0 --- Tracing command firefox-bin pid 1503 tid 100232 td 0xffffff001cdc4720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffe3f2dc8, rbp = 0x80d7b2d80 --- Tracing command firefox-bin pid 1503 tid 100231 td 0xffffff001cdc4ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffe5f3e98, rbp = 0x80d7b3100 --- Tracing command firefox-bin pid 1503 tid 100228 td 0xffffff001cdc5000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffe7f4e78, rbp = 0x80d32e700 --- Tracing command firefox-bin pid 1503 tid 100227 td 0xffffff001cdc5390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffebf6e08, rbp = 0x809a2ae00 --- Tracing command firefox-bin pid 1503 tid 100230 td 0xffffff001cdc5720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffeff8d18, rbp = 0x809a2b180 --- Tracing command firefox-bin pid 1503 tid 100229 td 0xffffff001cdc5ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff3fadc8, rbp = 0x809a2ba40 --- Tracing command firefox-bin pid 1503 tid 100226 td 0xffffff000a510ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff7fcda8, rbp = 0x8088978c0 --- Tracing command firefox-bin pid 1503 tid 100225 td 0xffffff000a8cc390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8048664dc, rsp = 0x7fffff9fdb08, rbp = 0x7fffff9fdb4c --- Tracing command firefox-bin pid 1503 tid 100224 td 0xffffff000a510720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffffbfee68, rbp = 0x808897fc0 --- Tracing command firefox-bin pid 1503 tid 100164 td 0xffffff0003a9f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8048664dc, rsp = 0x7fffffffdcb8, rbp = 0xa --- Tracing command sh pid 1499 tid 100159 td 0xffffff0003aa0390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe3b8, rbp = 0x5d3 --- Tracing command sh pid 1491 tid 100211 td 0xffffff000a35f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe7b8, rbp = 0x5d3 --- Tracing command zsh pid 1472 tid 100130 td 0xffffff00039bdab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe538, rbp = 0 --- Tracing command conky pid 1469 tid 100174 td 0xffffff0003f6d720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command conky pid 1468 tid 100190 td 0xffffff000a18e720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command conky pid 1467 tid 100181 td 0xffffff0003b22ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command dzen2 pid 1466 tid 100177 td 0xffffff0003f6cab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command dzen2 pid 1464 tid 100162 td 0xffffff0003a9f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command dzen2 pid 1462 tid 100208 td 0xffffff000a35fab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command sh pid 1460 tid 100180 td 0xffffff0003f6c000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe898, rbp = 0x5b4 --- Tracing command sh pid 1458 tid 100113 td 0xffffff0003a66390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe8a8, rbp = 0x5b2 --- Tracing command sh pid 1456 tid 100117 td 0xffffff0003aa3390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe8a8, rbp = 0x5b0 --- Tracing command dzen2 pid 1454 tid 100207 td 0xffffff000a18e000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x290 --- Tracing command dzen2 pid 1452 tid 100220 td 0xffffff000a8cdab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffde28, rbp = 0x801271500 --- Tracing command xmonad-x86_64-freeb pid 1451 tid 100215 td 0xffffff000a8b7000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8011d64dc, rsp = 0x7fffffffa7c8, rbp = 0x801846000 --- Tracing command urxvtd pid 1448 tid 100158 td 0xffffff0003b2b720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x80284e0cc, rsp = 0x7fffffffe918, rbp = 0x40 --- Tracing command urxvtd pid 1447 tid 100216 td 0xffffff000a8b6ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sbwait() at sbwait+0x66 soreceive_generic() at soreceive_generic+0x377 soreceive() at soreceive+0x12 soo_read() at soo_read+0x3d dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80284e14c, rsp = 0x7fffffffe728, rbp = 0x7fffffffe768 --- Tracing command ssh-agent pid 1445 tid 100223 td 0xffffff000a8ccab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d2b0cc, rsp = 0x7fffffffe9f8, rbp = 0xa --- Tracing command sh pid 1442 tid 100210 td 0xffffff000a35f390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe988, rbp = 0x5a2 --- Tracing command Xorg pid 1439 tid 100221 td 0xffffff000a8cd720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 i915_irq_wait() at i915_irq_wait+0x15d drm_ioctl() at drm_ioctl+0x2f3 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801a020ec, rsp = 0x7fffffffe508, rbp = 0x7fffffffe550 --- Tracing command xinit pid 1438 tid 100219 td 0xffffff000a8b6000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8008d816c, rsp = 0x7fffffffea48, rbp = 0x7fffffffea70 --- Tracing command sh pid 1420 tid 100209 td 0xffffff000a35f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe858, rbp = 0x58c --- Tracing command zsh pid 1414 tid 100116 td 0xffffff0003a08720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_sigsuspend() at kern_sigsuspend+0xcd sigsuspend() at sigsuspend+0x34 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x800b562ac, rsp = 0x7fffffffea68, rbp = 0 --- Tracing command hald-addon-mouse-sy pid 1384 tid 100163 td 0xffffff0003a9f390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e44c0c, rsp = 0x7fffffffe788, rbp = 0x801621070 --- Tracing command hald-runner pid 1379 tid 100168 td 0xffffff0003f7d000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800c0d4dc, rsp = 0x7fffffffeb68, rbp = 0x1 --- Tracing command console-kit-daemon pid 1378 tid 100199 td 0xffffff000a8cd390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffaeef38, rbp = 0x1 --- Tracing command console-kit-daemon pid 1378 tid 100206 td 0xffffff000a55dab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffafff38, rbp = 0x10 --- Tracing command console-kit-daemon pid 1378 tid 100205 td 0xffffff000a55e000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb10f38, rbp = 0xf --- Tracing command console-kit-daemon pid 1378 tid 100204 td 0xffffff000a55e390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb21f38, rbp = 0xe --- Tracing command console-kit-daemon pid 1378 tid 100203 td 0xffffff000a55e720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb32f38, rbp = 0xd --- Tracing command console-kit-daemon pid 1378 tid 100202 td 0xffffff000a55eab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb43f38, rbp = 0xc --- Tracing command console-kit-daemon pid 1378 tid 100201 td 0xffffff000a510000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb54f38, rbp = 0xb --- Tracing command console-kit-daemon pid 1378 tid 100200 td 0xffffff000a510390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb65f38, rbp = 0xa --- Tracing command console-kit-daemon pid 1378 tid 100198 td 0xffffff0003aceab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb87f38, rbp = 0x8 --- Traci ----- end ddb.txt From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 12:51:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577C0106568F for ; Tue, 18 Aug 2009 12:51:24 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 11B968FC55 for ; Tue, 18 Aug 2009 12:51:23 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1198135qwe.7 for ; Tue, 18 Aug 2009 05:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=58cD6Vpn1NMivbqKmCvR0e9uIYt5adAY/WumcsW1miI=; b=A58P6FFOdaIi30n3bVz3Ga0I32slKSJxFmiTC7IyqqFAnrF1ToJxvIXrJmKw98ocYt SYn0SeDAtHEfcWB7SCzBS9I7ryRkaNOcDeZWyD/HBMq3k0rnnXCTOZXWv5pZe50A5keQ 9d1myHEEVIx11TnqJmPLs6p+zmn4ug2j1nehQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=teuQYhVebvQXZh8+C7dRftLpifWeVnxo+Kp9+nwByfBulQqroM5DUZP1+SdCYW2e5w ZewQvktOoEaDTrZj1XAwNGq91HgZ4BHT5o9gk5wIkZlF7Sc4vdseupJPqp86EHtbGGUf wU50Q+86H8Q/3N441bcCjWI0ogEGuLevx2kQ8= MIME-Version: 1.0 Received: by 10.229.1.83 with SMTP id 19mr2307430qce.68.1250599883284; Tue, 18 Aug 2009 05:51:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2009 16:51:22 +0400 Message-ID: From: Alexey Tarasov To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 12:51:24 -0000 Hello. > A bit old system, but at least it should be "well known" - if it's a OS > problem someone would have noticed it by now. > > How did you create your file systems? 4 disks with gjournal. Disks are quite old. I will replace them with fresh disks and make new tests. > > > Can you rule out disk drive data corruption? > > Does the panic happen with all drives and all file systems you have? Can > you boot single-user and test each file system? > > I have installed this disks to another server and get some unreadable files and vfs errors in dmesg. I will make new tests and send results. --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 13:11:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9CC106564A for ; Tue, 18 Aug 2009 13:11:10 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF9B8FC55 for ; Tue, 18 Aug 2009 13:11:10 +0000 (UTC) Received: from localhost (pool-70-20-219-14.phil.east.verizon.net [70.20.219.14]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id E625480293; Tue, 18 Aug 2009 22:11:07 +0900 (JST) Date: Tue, 18 Aug 2009 09:11:04 -0400 From: Yoshihiro Ota To: Hans Petter Selasky Message-Id: <20090818091104.28cda3be.ota@j.email.ne.jp> In-Reply-To: <200908180706.30202.hselasky@c2i.net> References: <20090213204112.7b982402.ota@j.email.ne.jp> <20090214133457.e47df9b5.ota@j.email.ne.jp> <20090817225105.88fa579d.ota@j.email.ne.jp> <200908180706.30202.hselasky@c2i.net> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: USB2 - keyboard error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:11:10 -0000 On Tue, 18 Aug 2009 07:06:29 +0200 Hans Petter Selasky wrote: > On Tuesday 18 August 2009 04:51:05 Yoshihiro Ota wrote: > > Hi all and Hans, > > > > After switching code base for 8 release, I realized problems with my > > keyboard. The work-around described below fixed my problems. > > > > Could you be able to incorporate fix for this? > > > > Thanks, > > Hiro > > Can you resend the patch? > > --HPS Below is the change you suggested. It doesn't look good for other keyboards. Thanks, Hiro %env LANG=C svn diff --diff-cmd /usr/bin/diff -x-U10 input/ukbd.c Index: input/ukbd.c =================================================================== --- input/ukbd.c (revision 196086) +++ input/ukbd.c (working copy) @@ -606,20 +606,21 @@ } static void ukbd_set_leds_callback(struct usb_xfer *xfer, usb_error_t error) { struct usb_device_request req; struct usb_page_cache *pc; uint8_t buf[2]; struct ukbd_softc *sc = usbd_xfer_softc(xfer); +return; /* USB-keyboard workaround */ switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: case USB_ST_SETUP: if (sc->sc_flags & UKBD_FLAG_SET_LEDS) { sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; req.bmRequestType = UT_WRITE_CLASS_INTERFACE; req.bRequest = UR_SET_REPORT; USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); req.wIndex[0] = sc->sc_iface_no; From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 13:14:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A58106568C for ; Tue, 18 Aug 2009 13:14:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id BFECC8FC15 for ; Tue, 18 Aug 2009 13:14:31 +0000 (UTC) Received: by fxm1 with SMTP id 1so2806011fxm.7 for ; Tue, 18 Aug 2009 06:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=8x+UMUp4qoQMHpU6smkqZrbIlSQMJU5SWVJswSeP0hU=; b=uw6xVYdZgnBpWz8t24OoUPP8UpFLrbtbruTODGcKW6nxjnLFYB7wK6kYJwOyfirqxx kOKoapzLubcIkEupji3Bax+KbkB4CjFGK9YMYhhflFYcyTLfJc8nEJX9VVWF2LrLsqWr F1C3BfBykS5C7ziWYrA2fdC49KLM2vwSnS+78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L6jrSqD/YiyGkgpXtVIQjugeYLXT9nuj54KuS69yIfbzTE9domudMAtHRzmPpBahit tqyIOv7lxVD/3y4pnt/FLgo4rCsZoNwUVFmAbQIOOmkXVad1VRttU9FdC2iaXKOpcPM7 l+0xY59Q3TBCwsAQBX5pDBFDEzuNEAYX+uRes= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.134.68 with SMTP id i4mr1139557fat.101.1250601270635; Tue, 18 Aug 2009 06:14:30 -0700 (PDT) In-Reply-To: <1280352d0908180604s6b3bf050l9bde52f3c57a5a75@mail.gmail.com> References: <1280352d0908180604s6b3bf050l9bde52f3c57a5a75@mail.gmail.com> Date: Tue, 18 Aug 2009 15:14:29 +0200 X-Google-Sender-Auth: ff7350f5449b36de Message-ID: <3bbf2fe10908180614r16c86cb6q2a42f1856b6a0cc7@mail.gmail.com> From: Attilio Rao To: Andrew Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current , Hans Petter Selasky Subject: Re: USB newbus livelock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:14:32 -0000 2009/8/18 Andrew Thompson : > Hi Attilio, > > > At the moment usb controller modules can not be unloaded due to a > newbus locking problem, roughly... > > # kldunload ehci > syscall() > driver_module_handler() > --> newbus xlock (subr_bus.c:4127) > usb_detach() > usb_proc_mwait() <- wakeup, detach and drain the usb thread > > > [usb thread, detaching...] > usb_bus_detach() > --> newbus xlock (livelock, the kldunload process has this) > > Hans has made some changes WRT this, perforce changes 167093 and > possibly 167087. Do you want to review this or maybe go for a similar > fix? The other and me are alredy aware of such a problem. Actually, the right fix is to have attach/detach virtual functions to be called completely locklessly (in particular the detach() path). This also means a lot of work atm. This is why the newbus locking change will be backed out for 8.0-REL (just backported to 8.1 proabilly though). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 13:04:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18978106568B; Tue, 18 Aug 2009 13:04:28 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f180.google.com (mail-vw0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B79938FC3D; Tue, 18 Aug 2009 13:04:27 +0000 (UTC) Received: by vws10 with SMTP id 10so3083183vws.7 for ; Tue, 18 Aug 2009 06:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.42.143 with SMTP id s15mr6282984vce.116.1250600667002; Tue, 18 Aug 2009 06:04:27 -0700 (PDT) Date: Tue, 18 Aug 2009 06:04:26 -0700 Message-ID: <1280352d0908180604s6b3bf050l9bde52f3c57a5a75@mail.gmail.com> From: Andrew Thompson To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Aug 2009 13:29:30 +0000 Cc: current , Hans Petter Selasky Subject: USB newbus livelock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:04:28 -0000 Hi Attilio, At the moment usb controller modules can not be unloaded due to a newbus locking problem, roughly... # kldunload ehci syscall() driver_module_handler() --> newbus xlock (subr_bus.c:4127) usb_detach() usb_proc_mwait() <- wakeup, detach and drain the usb thread [usb thread, detaching...] usb_bus_detach() --> newbus xlock (livelock, the kldunload process has this) Hans has made some changes WRT this, perforce changes 167093 and possibly 167087. Do you want to review this or maybe go for a similar fix? cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 13:32:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7A6106568E for ; Tue, 18 Aug 2009 13:32:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA818FC55 for ; Tue, 18 Aug 2009 13:31:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=tlORsIYbfsrD9LvzZ0MA:9 a=mmPAAgUw-sakB0tzUaMA:7 a=qCVTN3qJ7QMixclqrM8UUxwZxO4A:4 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 907980503; Tue, 18 Aug 2009 15:31:57 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 18 Aug 2009 15:32:08 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090213204112.7b982402.ota@j.email.ne.jp> <200908180706.30202.hselasky@c2i.net> <20090818091104.28cda3be.ota@j.email.ne.jp> In-Reply-To: <20090818091104.28cda3be.ota@j.email.ne.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908181532.09088.hselasky@c2i.net> Cc: Yoshihiro Ota Subject: Re: USB2 - keyboard error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:32:00 -0000 On Tuesday 18 August 2009 15:11:04 Yoshihiro Ota wrote: > On Tue, 18 Aug 2009 07:06:29 +0200 > > Hans Petter Selasky wrote: > > On Tuesday 18 August 2009 04:51:05 Yoshihiro Ota wrote: > > > Hi all and Hans, > > > > > > After switching code base for 8 release, I realized problems with my > > > keyboard. The work-around described below fixed my problems. > > > > > > Could you be able to incorporate fix for this? > > > > > > Thanks, > > > Hiro > > > > Can you resend the patch? > > > > --HPS > > Below is the change you suggested. > It doesn't look good for other keyboards. I can implement this like a sysctl: hw.usb.ukbd.no_leds --HPS > > Thanks, > Hiro > > %env LANG=C svn diff --diff-cmd /usr/bin/diff -x-U10 input/ukbd.c > Index: input/ukbd.c > =================================================================== > --- input/ukbd.c (revision 196086) > +++ input/ukbd.c (working copy) > @@ -606,20 +606,21 @@ > } > > static void > ukbd_set_leds_callback(struct usb_xfer *xfer, usb_error_t error) > { > struct usb_device_request req; > struct usb_page_cache *pc; > uint8_t buf[2]; > struct ukbd_softc *sc = usbd_xfer_softc(xfer); > > +return; /* USB-keyboard workaround */ > switch (USB_GET_STATE(xfer)) { > case USB_ST_TRANSFERRED: > case USB_ST_SETUP: > if (sc->sc_flags & UKBD_FLAG_SET_LEDS) { > sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; > > req.bmRequestType = UT_WRITE_CLASS_INTERFACE; > req.bRequest = UR_SET_REPORT; > USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); > req.wIndex[0] = sc->sc_iface_no; > _______________________________________________ > 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 Aug 18 13:24:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1BA1065690 for ; Tue, 18 Aug 2009 13:24:17 +0000 (UTC) (envelope-from viktor@cisti.cz) Received: from mx0.estimese.net (super.estimese.net [194.149.99.140]) by mx1.freebsd.org (Postfix) with ESMTP id 76A928FC52 for ; Tue, 18 Aug 2009 13:24:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 80) by mx0.estimese.net with local; Tue, 18 Aug 2009 15:14:14 +0200 id 000BDC50.000000004A8AA926.000113B2 To: freebsd-current@freebsd.org Received: from 194.149.99.140 (auth. user viktor@mx.estimese.net) by webmail.estimese.net with HTTP; Tue, 18 Aug 2009 13:14:14 +0000 X-IlohaMail-Blah: viktor@mx.estimese.net X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.estimese.net) Message-ID: <8cBY1VMA.1250601254.4165210.viktor@mx.estimese.net> From: "Viktor CISTICZ" Bounce-To: "Viktor CISTICZ" Errors-To: "Viktor CISTICZ" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 15:14:14 +0200 X-Mailman-Approved-At: Tue, 18 Aug 2009 13:43:51 +0000 Subject: NETIO UDP benchmark problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:24:18 -0000 Hello, recently i have been testing two servers via crosslink. Both have Freebsd installed > twin1$ uname -a FreeBSD twin1 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Sun Aug 16 22:57:29 CEST 2009 viktor@twin1:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 twin2$ uname -a FreeBSD kitt.twin2 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 22 15:05:19 CEST 2009 viktor@kitt.twin2:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 GEN_NO_DBG is GENERIC kernel without debugging options Twin2 is virtual machine on the same hardware as twin1, vmware used. I have this set installed on both machines > twin1$ pkg_info NetPIPE-3.7.1 A self-scaling network benchmark gettext-0.17_1 GNU gettext package gmake-3.81_3 GNU version of 'make' utility iperf-2.0.4 A tool to measure maximum TCP and UDP bandwidth libiconv-1.13.1 A character set conversion library libtool-2.2.6a Generic shared library support script netio-1.26 Network benchmark netperf-2.4.5 Network performance benchmarking package portaudit-0.5.13 Checks installed ports against a list of security vulnerabi portmaster-2.9 Manage your ports without external databases or languages screen-4.0.3_6 A multi-screen window manager ttcp-1.12 Benchmarking tool for analysing TCP and UDP performance unzip-5.52_5 List, test and extract compressed files in a ZIP archive Both machines are connected via crosslink > twin1# ifconfig igb0 : public interface igb1: flags=3D8843 metric 0 mtu 1500 options=3D13b ether 00:30:48:c8:f3:91 inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (1000baseT ) status: active twin2# ifconfig em0: public interface em1: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 00:0c:29:4b:f1:76 inet 10.10.10.20 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (1000baseT ) status: active I have set up twin2 as a server for netio > kitt.twin2# netio -s -p 1122 And then tested from twin1 tcp test > twin1# netio -p 1122 -t 10.10.10.20 It was allright, i've got some results. But when I tried UDP, it failed. The server is still the same > kitt.twin2# netio -s -p 1122 Client twin1# netio -p 1122 -u 10.10.10.20 After around 1 minute, twin1 server stopped responding on public interface, i've been disconnected. Via remote console i could access the machine, it was acting normally. I could ping both interfaces. I could even ping from other side of crosslink, from twin2 the privat interface, but no reply on public interface. The interface was shown UP in ifconfig, no messages in /var/log/messages. Then i executed ifconfig igb1 down && ifconfig igb1 up and it worked again. I have then executed netio udp test again with 2k udp packets The server is still the same > kitt.twin2# netio -s -p 1122 twin1# netio -p 1122 -u -b 2k 10.10.10.20 The same problem on twin1, but now it has crashed the computer > via remote console i could see this > twin1# GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 then it executed core dump and restarted. I am lost, thanks for any advise. VC From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 14:15:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC33106568E for ; Tue, 18 Aug 2009 14:15:00 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0968FC16 for ; Tue, 18 Aug 2009 14:15:00 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 999FA851A; Tue, 18 Aug 2009 14:14:59 +0000 (UTC) Date: Tue, 18 Aug 2009 15:14:59 +0100 From: Bruce Cran To: John Baldwin Message-ID: <20090818151459.00004e1c@unknown> In-Reply-To: <200908180830.58904.jhb@freebsd.org> References: <20090818122453.0000301a@unknown> <200908180830.58904.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: fdc(4) regression: fdc0 fails to probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:15:00 -0000 On Tue, 18 Aug 2009 08:30:58 -0400 John Baldwin wrote: > On Tuesday 18 August 2009 7:24:53 am Bruce Cran wrote: > > There appears to be a regression between 7.2 and 8.0-BETA2 with > > fdc(4): it used to find and attach fdc0, but now it fails to probe > > fdc0 but appears to initially find a nonexistant fdc1: > > > > fdc0: No FDOUT register! > > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > > I think fdc0 will work if you remove the fdc0 hints. Removing /boot/device.hints made fdc0 probe again, but /dev/fd0 didn't appear because during boot after the probe it timed out on input/output for fdc0 this time. I'll investigate some more later. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 14:21:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E92106568F; Tue, 18 Aug 2009 14:21:02 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D9F858FC3F; Tue, 18 Aug 2009 14:21:01 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:45452 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MdPY5-0005pi-3g; Tue, 18 Aug 2009 16:20:31 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 97AD1199BA; Tue, 18 Aug 2009 16:20:26 +0200 (CEST) Message-Id: From: Thomas Backman To: Pawel Dawidek Jakub In-Reply-To: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 16:20:24 +0200 References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MdPY5-0005pi-3g. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MdPY5-0005pi-3g 08131470b976214b8c0065d7cdd052dd Cc: FreeBSD current Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:21:02 -0000 On Aug 17, 2009, at 17:24, Thomas Backman wrote: > On Aug 17, 2009, at 15:25, Thomas Backman wrote: > >> So, I've got myself a source tree almost completely free of patches >> after today's batch of ZFS patches merged - all that remains is >> that I uncommented ps -axl from /usr/sbin/crashinfo, since it only >> coredumps anyway, and added CFLAGS+=-DDEBUG=1 to zfs/Makefile. >> >> One of the changes I didn't already have prior to this must have >> broken something, though, because this script worked just fine >> before the merges earlier today. >> The script below is the exact same I linked in http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html >> back in July (URL to the script: http://exscape.org/temp/zfs_clone_panic.sh >> ) - I made some local changes, thus the name invoked below. >> >> Now that all the patches are merged, you should need nothing but >> the script, bash, and the ~200MB free space on the partition >> containing /root/ to reproduce this problem. >> (Note that the "no such pool" in the FIRST script is normal; it >> simply tries to clean up something that isn't there, without error/ >> sanity checking.) >> >> [...] >> + zpool create -f -R /slave slave ggate666 >> ++ date +backup-%Y%m%d-%H%M >> + NOW=backup-20090817-1522 >> + echo 'Creating snapshots' >> Creating snapshots >> + zfs snapshot -r tank@backup-20090817-1522 >> + echo 'Cloning pool' >> Cloning pool >> + zfs send -R tank@backup-20090817-1522 >> + zfs recv -vFd slave >> cannot receive: invalid stream (malformed nvlist) >> warning: cannot send 'tank@backup-20090817-1522': Broken pipe >> >> >> Regards, >> Thomas > This is perhaps more troubling... > [...] > [root@chaos ~]# zpool create testpool ad0s1d > [root@chaos ~]# zpool export testpool > [root@chaos ~]# zpool import testpool > cannot import 'testpool': no such pool available > > Regards, > Thomas OK, I tried to reproduce this in a VM... And I have to say I was a bit surprised: after doing an installkernel/installworld, but BEFORE REBOOTING (I install in "multi"-user (one user via ssh), never had a problem with that), the same issue has appeared, so I'm guessing zfs.ko can't be to blame here? What the heck? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 14:42:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4429106568F for ; Tue, 18 Aug 2009 14:42:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 71FFB8FC59 for ; Tue, 18 Aug 2009 14:42:03 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MdPsw-00015S-7x for current@freebsd.org; Tue, 18 Aug 2009 17:42:02 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: current@freebsd.org In-reply-to: References: Comments: In-reply-to Danny Braniss message dated "Tue, 18 Aug 2009 15:02:11 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Aug 2009 17:42:02 +0300 From: Danny Braniss Message-ID: Cc: Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:42:03 -0000 > it seems that the latest changes to zfs prevents zpool to see/find > the pool in /dev/ad0p4 (BTW, the pool was created under 8.0) > > # gpart show > => 34 1953525101 ad0 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 4194304 2 freebsd-ufs (2.0G) > 4194466 8388608 3 freebsd-swap (4.0G) > 12583074 1940942061 4 freebsd-zfs (926G) > > # zpool list > no pools available > # zpool import -a > # > > under 7.2, the pool is still there: > > pundit-2> zfs list > NAME USED AVAIL REFER MOUNTPOINT > z 5.27G 900G 18K /z > z/home 5.21G 900G 5.21G /home > z/var 59.7M 900G 59.7M /var > pundit-2> zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > z 920G 5.27G 915G 0% ONLINE - running 'truss zpool import -a' reveals the problem: open("ad0p4",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/ad0p4",O_RDONLY,05003312752) = 5 (0x5) ioctl(5,DIOCGSECTORSIZE,0xbfbfa1f4) = 0 (0x0) fstat(5,{ mode=crw-r----- ,inode=75,size=0,blksize=4096 }) = 0 (0x0) pread(0x5,0x2834a000,0x40000,0x0,0x0,0x805ab64) = 262144 (0x40000) pread(0x5,0x2834a000,0x40000,0x40000,0x0,0x1bfd8) = 262144 (0x40000) pread(0x5,0x2834a000,0x40000,0xfff80000,0xffffffff,0x1bfd8) ERR#5 'Input/output error' ********** offset is a bit too big :-) pread(0x5,0x2834a000,0x40000,0xfffc0000,0xffffffff,0x1bfd8) ERR#5 'Input/output error' From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 14:57:35 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8B71065690; Tue, 18 Aug 2009 14:57:35 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id B613E8FC65; Tue, 18 Aug 2009 14:57:34 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n7IEvVd9024744; Tue, 18 Aug 2009 15:57:31 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MdQ7v-00068i-18; Tue, 18 Aug 2009 15:57:31 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n7IEvUc5031361; Tue, 18 Aug 2009 15:57:30 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n7IEvUqG031319; Tue, 18 Aug 2009 15:57:30 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Thomas Backman In-Reply-To: References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 18 Aug 2009 15:57:29 +0100 Message-Id: <1250607450.41855.39.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: FreeBSD current , Pawel Dawidek Jakub Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:57:35 -0000 On Tue, 2009-08-18 at 16:20 +0200, Thomas Backman wrote: > OK, I tried to reproduce this in a VM... And I have to say I was a bit > surprised: after doing an installkernel/installworld, but BEFORE > REBOOTING (I install in "multi"-user (one user via ssh), never had a > problem with that), the same issue has appeared, so I'm guessing > zfs.ko can't be to blame here? > What the heck? So, you're using a new zfs binary, with an old kernel? This isn't supported and there's every chance it will fail in odd ways. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 15:04:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E908106568C; Tue, 18 Aug 2009 15:04:22 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id DAA938FC43; Tue, 18 Aug 2009 15:04:21 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:47479 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MdQDp-00047l-59; Tue, 18 Aug 2009 17:03:39 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id D3F66199BA; Tue, 18 Aug 2009 17:03:36 +0200 (CEST) Message-Id: <2254F332-3304-4521-884E-F6BC5BBE544C@exscape.org> From: Thomas Backman To: Gavin Atkinson In-Reply-To: <1250607450.41855.39.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 17:03:34 +0200 References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> <1250607450.41855.39.camel@buffy.york.ac.uk> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MdQDp-00047l-59. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MdQDp-00047l-59 6101b6c56055302aa880887fffc7bf13 Cc: FreeBSD current , Pawel Dawidek Jakub Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 15:04:22 -0000 On Aug 18, 2009, at 16:57, Gavin Atkinson wrote: > On Tue, 2009-08-18 at 16:20 +0200, Thomas Backman wrote: >> OK, I tried to reproduce this in a VM... And I have to say I was a >> bit >> surprised: after doing an installkernel/installworld, but BEFORE >> REBOOTING (I install in "multi"-user (one user via ssh), never had a >> problem with that), the same issue has appeared, so I'm guessing >> zfs.ko can't be to blame here? >> What the heck? > > So, you're using a new zfs binary, with an old kernel? This isn't > supported and there's every chance it will fail in odd ways. > > Gavin Well, yes, but it fails no matter what... In the previous case, I installed as usual, rebooted as usual and it still fails the exact same way. From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 16:06:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1EF106568E for ; Tue, 18 Aug 2009 16:06:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 647928FC51 for ; Tue, 18 Aug 2009 16:06:19 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=rmy27fAPBHwiE_GFYE0A:9 a=wT4M02_W9IcI2dJxBz2KI-AnNJcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 908049543; Tue, 18 Aug 2009 18:06:17 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 18 Aug 2009 18:06:28 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090213204112.7b982402.ota@j.email.ne.jp> <200908180706.30202.hselasky@c2i.net> <20090818091104.28cda3be.ota@j.email.ne.jp> In-Reply-To: <20090818091104.28cda3be.ota@j.email.ne.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908181806.29140.hselasky@c2i.net> Cc: Yoshihiro Ota Subject: Re: USB2 - keyboard error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:06:19 -0000 On Tuesday 18 August 2009 15:11:04 Yoshihiro Ota wrote: > On Tue, 18 Aug 2009 07:06:29 +0200 > > > Below is the change you suggested. > It doesn't look good for other keyboards. We have to debug this later. I'm out of time :-) http://perforce.freebsd.org/chv.cgi?CH=167481 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 16:11:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23723106568B; Tue, 18 Aug 2009 16:11:58 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id C54F68FC41; Tue, 18 Aug 2009 16:11:57 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7IGBrrt034267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Aug 2009 18:11:53 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Thomas Backman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 18:11:52 +0200 References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> X-Mailer: Apple Mail (2.936) Cc: FreeBSD current , Pawel Dawidek Jakub Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:11:58 -0000 Am 18.08.2009 um 16:20 schrieb Thomas Backman: > On Aug 17, 2009, at 17:24, Thomas Backman wrote: > >> On Aug 17, 2009, at 15:25, Thomas Backman wrote: >> >>> So, I've got myself a source tree almost completely free of >>> patches after today's batch of ZFS patches merged - all that >>> remains is that I uncommented ps -axl from /usr/sbin/crashinfo, >>> since it only coredumps anyway, and added CFLAGS+=-DDEBUG=1 to zfs/ >>> Makefile. >>> >>> One of the changes I didn't already have prior to this must have >>> broken something, though, because this script worked just fine >>> before the merges earlier today. >>> The script below is the exact same I linked in http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html >>> back in July (URL to the script: http://exscape.org/temp/zfs_clone_panic.sh >>> ) - I made some local changes, thus the name invoked below. >>> >>> Now that all the patches are merged, you should need nothing but >>> the script, bash, and the ~200MB free space on the partition >>> containing /root/ to reproduce this problem. >>> (Note that the "no such pool" in the FIRST script is normal; it >>> simply tries to clean up something that isn't there, without error/ >>> sanity checking.) >>> >>> [...] >>> + zpool create -f -R /slave slave ggate666 >>> ++ date +backup-%Y%m%d-%H%M >>> + NOW=backup-20090817-1522 >>> + echo 'Creating snapshots' >>> Creating snapshots >>> + zfs snapshot -r tank@backup-20090817-1522 >>> + echo 'Cloning pool' >>> Cloning pool >>> + zfs send -R tank@backup-20090817-1522 >>> + zfs recv -vFd slave >>> cannot receive: invalid stream (malformed nvlist) >>> warning: cannot send 'tank@backup-20090817-1522': Broken pipe >>> >>> >>> Regards, >>> Thomas >> This is perhaps more troubling... >> [...] >> [root@chaos ~]# zpool create testpool ad0s1d >> [root@chaos ~]# zpool export testpool >> [root@chaos ~]# zpool import testpool >> cannot import 'testpool': no such pool available >> >> Regards, >> Thomas > > OK, I tried to reproduce this in a VM... And I have to say I was a > bit surprised: after doing an installkernel/installworld, but BEFORE > REBOOTING (I install in "multi"-user (one user via ssh), never had a > problem with that), the same issue has appeared, so I'm guessing > zfs.ko can't be to blame here? It's not the zpool binary by itself: after updating from a two-day old current (make world && reboot): root@freebsd-current:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT zroot 14.9G 753M 14.1G 4% ONLINE - root@freebsd-current:~# zpool export zroot root@freebsd-current:~# zpool list no pools available root@freebsd-current:~# zpool import zroot cannot import 'zroot': no such pool available root@freebsd-current:~# zpool.old import zroot cannot import 'zroot': no such pool available root@freebsd-current:~# zpool.old import root@freebsd-current:~# uname -a FreeBSD freebsd-current.lassitu.de 8.0-BETA2 FreeBSD 8.0-BETA2 #1 r196359: Tue Aug 18 16:42:41 CEST 2009 root@freebsd-current.lassitu.de :/usr/obj/usr/src/sys/MINIMAL amd64 I saved zfs and zpool before the installworld. And my root is actually on UFS; this pool was left over from root on zfs raidz experiments. root@freebsd-current:~# ls -l /sbin/zpool* -r-xr-xr-x 1 root wheel 76752 Aug 18 17:47 /sbin/zpool* -r-xr-xr-x 1 root wheel 76752 Aug 18 17:46 /sbin/zpool.old* root@freebsd-current:~# md5 /sbin/zpool* MD5 (/sbin/zpool) = 83dcf6343bb0392a38159dd456dcf4c5 MD5 (/sbin/zpool.old) = 340cb5a383b2fc3c77afbdc881258597 HTH, Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 16:25:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B51106568B for ; Tue, 18 Aug 2009 16:25:14 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id BB4FC8FC65 for ; Tue, 18 Aug 2009 16:25:13 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7IGOmo2036592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Aug 2009 18:24:49 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 18:24:48 +0200 References: X-Mailer: Apple Mail (2.936) Cc: current@freebsd.org Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:25:14 -0000 Am 18.08.2009 um 16:42 schrieb Danny Braniss: >> it seems that the latest changes to zfs prevents zpool to see/find >> the pool in /dev/ad0p4 (BTW, the pool was created under 8.0) >> >> # gpart show >> => 34 1953525101 ad0 GPT (932G) >> 34 128 1 freebsd-boot (64K) >> 162 4194304 2 freebsd-ufs (2.0G) >> 4194466 8388608 3 freebsd-swap (4.0G) >> 12583074 1940942061 4 freebsd-zfs (926G) >> >> # zpool list >> no pools available >> # zpool import -a >> # >> >> under 7.2, the pool is still there: >> >> pundit-2> zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> z 5.27G 900G 18K /z >> z/home 5.21G 900G 5.21G /home >> z/var 59.7M 900G 59.7M /var >> pundit-2> zpool list >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >> z 920G 5.27G 915G 0% ONLINE - > > running 'truss zpool import -a' reveals the problem: > > open("ad0p4",O_RDONLY,00) ERR#2 'No such file > or directory' > open("/dev/ad0p4",O_RDONLY,05003312752) = 5 (0x5) > ioctl(5,DIOCGSECTORSIZE,0xbfbfa1f4) = 0 (0x0) > fstat(5,{ mode=crw-r----- ,inode=75,size=0,blksize=4096 }) = 0 (0x0) > pread(0x5,0x2834a000,0x40000,0x0,0x0,0x805ab64) = 262144 (0x40000) > pread(0x5,0x2834a000,0x40000,0x40000,0x0,0x1bfd8) = 262144 (0x40000) > pread(0x5,0x2834a000,0x40000,0xfff80000,0xffffffff,0x1bfd8) ERR#5 > 'Input/output error' > ********** offset is a bit too big :-) > pread(0x5,0x2834a000,0x40000,0xfffc0000,0xffffffff,0x1bfd8) ERR#5 > 'Input/output error' I think the problem is that it doesn't like what it's reading at offsets 0 and 0x40000. The fact that it's not properly reading from the end of the device is a seperate bug. From a system a couple days old: # uname -a FreeBSD diesel.lassitu.de 8.0-BETA2 FreeBSD 8.0-BETA2 #1 r196200: Fri Aug 14 12:00:46 CEST 2009 root@diesel.lassitu.de:/usr/obj/usr/src/ sys/DIESEL amd64 # truss zpool import __sysctl(0x7fffffffe4a0,0x2,0x7fffffffe4bc,0x7fffffffe4b0,0x0,0x0) = 0 (0x0) ... open("/dev/label/diesel_zfs0",O_RDONLY,00) = 6 (0x6) ioctl(6,DIOCGSECTORSIZE,0xffffa044) = 0 (0x0) fstat(6,{ mode=crw-r----- ,inode=75,size=0,blksize=4096 }) = 0 (0x0) pread(0x6,0x801253000,0x40000,0x0,0x6d004,0x801200de8) = 262144 (0x40000) close(6) = 0 (0x0) (That's a valid zfs device.) open("/dev/md0",O_RDONLY,00) = 6 (0x6) ioctl(6,DIOCGSECTORSIZE,0xffffa044) = 0 (0x0) fstat(6,{ mode=crw-r----- ,inode=97,size=0,blksize=4096 }) = 0 (0x0) pread(0x6,0x801253000,0x40000,0x0,0x6d004,0x801200de8) = 262144 (0x40000) pread(0x6,0x801253000,0x40000,0x40000,0x1,0x801200de8) = 262144 (0x40000) pread(0x6,0x801253000,0x40000,0xfffffffffff80000,0x1,0x801200de8) ERR#5 'Input/output error' pread(0x6,0x801253000,0x40000,0xfffffffffffc0000,0x1,0x801200de8) ERR#5 'Input/output error' close(6) = 0 (0x0) (This is not.) Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 16:36:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F03106568B for ; Tue, 18 Aug 2009 16:36:31 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3E55B8FC15 for ; Tue, 18 Aug 2009 16:36:30 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 18 Aug 2009 12:36:30 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.6-GA) with ESMTP id QCN14758; Tue, 18 Aug 2009 12:36:24 -0400 (EDT) X-Auth-ID: roberthuff Received: from 209-6-159-252.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO [209.6.159.252]) ([209.6.159.252]) by smtp01.lnh.mail.rcn.net with ESMTP; 18 Aug 2009 12:36:25 -0400 Message-ID: <4A8AD86E.5020302@rcn.com> Date: Tue, 18 Aug 2009 12:35:58 -0400 From: Robert Huff User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Robert Huff , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Subject: HEAD newfs/sysinstall issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:36:31 -0000 Did this ever get resolved? I'm having the same problem, and I _think_ I may know (part of) the problem. The error message talks about "/dev/ad0s1b" however in the Fixit shell a listing of /dev/ad* gives things like /dev/ad0a /dev/ad0b /dev/ad0c /dev/ad0d etc.. This happens whether I use slices or choose "dd" mode. Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 16:47:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C30E106568B for ; Tue, 18 Aug 2009 16:47:54 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8C14C8FC65 for ; Tue, 18 Aug 2009 16:47:53 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:59902 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MdRq1-0004xK-3t; Tue, 18 Aug 2009 18:47:11 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3D644199B6; Tue, 18 Aug 2009 18:46:57 +0200 (CEST) Message-Id: From: Thomas Backman To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 18:46:54 +0200 References: X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MdRq1-0004xK-3t. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MdRq1-0004xK-3t 4f61eae8d7047f6d6b28a9f2d47fc7df Cc: current@freebsd.org Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:47:54 -0000 On Aug 18, 2009, at 16:42, Danny Braniss wrote: >> it seems that the latest changes to zfs prevents zpool to see/find >> the pool in /dev/ad0p4 (BTW, the pool was created under 8.0) >> >> # gpart show >> => 34 1953525101 ad0 GPT (932G) >> 34 128 1 freebsd-boot (64K) >> 162 4194304 2 freebsd-ufs (2.0G) >> 4194466 8388608 3 freebsd-swap (4.0G) >> 12583074 1940942061 4 freebsd-zfs (926G) >> >> # zpool list >> no pools available >> # zpool import -a >> # >> >> under 7.2, the pool is still there: >> >> pundit-2> zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> z 5.27G 900G 18K /z >> z/home 5.21G 900G 5.21G /home >> z/var 59.7M 900G 59.7M /var >> pundit-2> zpool list >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >> z 920G 5.27G 915G 0% ONLINE - > > running 'truss zpool import -a' reveals the problem: > > open("ad0p4",O_RDONLY,00) ERR#2 'No such file > or directory' > open("/dev/ad0p4",O_RDONLY,05003312752) = 5 (0x5) > ioctl(5,DIOCGSECTORSIZE,0xbfbfa1f4) = 0 (0x0) > fstat(5,{ mode=crw-r----- ,inode=75,size=0,blksize=4096 }) = 0 (0x0) > pread(0x5,0x2834a000,0x40000,0x0,0x0,0x805ab64) = 262144 (0x40000) > pread(0x5,0x2834a000,0x40000,0x40000,0x0,0x1bfd8) = 262144 (0x40000) > pread(0x5,0x2834a000,0x40000,0xfff80000,0xffffffff,0x1bfd8) ERR#5 > 'Input/output error' > ********** offset is a bit too big :-) > pread(0x5,0x2834a000,0x40000,0xfffc0000,0xffffffff,0x1bfd8) ERR#5 > 'Input/output error' Glad I'm not the only one. I reported the same issue yesterday, in a thread originally about something else zfs related (zfs send sends a broken stream, or recv considers it broken despite it being fine; I don't know which one it is): http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010709.html FWIW, my truss output (ggate142 is the ZFS pool device I *just* created and then exported, and ad2s1b is my swap/dump device): (from "truss -o outfile zpool import") [...] open("ad2s1b",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/ad2s1b",O_RDONLY,00) = 7 (0x7) ioctl(7,DIOCGSECTORSIZE,0xffff9fc4) = 0 (0x0) fstat(7,{ mode=crw-r----- ,inode=79,size=0,blksize=4096 }) = 0 (0x0) pread(0x7,0x80128c000,0x40000,0x0,0x34004,0x801201340) = 262144 (0x40000) pread(0x7,0x80128c000,0x40000,0x40000,0x1,0x801201340) = 262144 (0x40000) pread(0x7,0x80128c000,0x40000,0xfffffffffff80000,0x1,0x801201340) ERR#5 'Input/output error' pread(0x7,0x80128c000,0x40000,0xfffffffffffc0000,0x1,0x801201340) ERR#5 'Input/output error' close(7) = 0 (0x0) open("ggate142",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/ggate142",O_RDONLY,00) = 7 (0x7) ioctl(7,DIOCGSECTORSIZE,0xffff9fc4) = 0 (0x0) fstat(7,{ mode=crw-r----- ,inode=93,size=0,blksize=4096 }) = 0 (0x0) pread(0x7,0x80128c000,0x40000,0x0,0x34004,0x801201340) = 262144 (0x40000) pread(0x7,0x80128c000,0x40000,0x40000,0x1,0x801201340) = 262144 (0x40000) pread(0x7,0x80128c000,0x40000,0xfffffffffff80000,0x1,0x801201340) ERR#5 'Input/output error' pread(0x7,0x80128c000,0x40000,0xfffffffffffc0000,0x1,0x801201340) ERR#5 'Input/output error' close(7) = 0 (0x0) close(4) = 0 (0x0) close(5) = 0 (0x0) close(6) = 0 (0x0) ... sigprocmask(...) process exit, rval = 1 Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 18:03:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1597B106568B; Tue, 18 Aug 2009 18:03:09 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 29C168FC3D; Tue, 18 Aug 2009 18:03:07 +0000 (UTC) Received: by ewy5 with SMTP id 5so296878ewy.36 for ; Tue, 18 Aug 2009 11:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=s0TGJjVsxz6rlnOOgwIKTukJLddAbKOYZsNaNpgZbdU=; b=Z/sp760d4yy3FrLQS1+CZSgcQk3S7tujCAh6jkUC+5ObOnXgMzVlouFfUtRE1znMYk OLHFEP0rP4gzXQyXygiysyeeFAJYvJbbZRMClEYmbERIFJAy3xwQIxnB3RT++6h0jfVV 6p3yYdzpmdDPZTaGL5Uj+ByOCfkYNkL0wbyKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EL38b5D/ymoj6n994EaCs/dlDYj3oi2afBzeRtCuQuKdUdbz356T0B5qgYMZ0dnoyZ ha1FAwnKeUFthneEtyqA/NmoAN/6mAXYTgqwHYHTaRXQ1/C8Ooal1jphOMt9HGIMPj7U IKwinCSUQsq4KO9ROnHYxO4jsk2/Tywmox4ww= MIME-Version: 1.0 Received: by 10.216.88.209 with SMTP id a59mr1301012wef.50.1250616765863; Tue, 18 Aug 2009 10:32:45 -0700 (PDT) In-Reply-To: References: <4A8484E4.6090504@uffner.com> Date: Tue, 18 Aug 2009 13:32:45 -0400 Message-ID: <5f67a8c40908181032x5b23de27jc01dc1147281a1a6@mail.gmail.com> From: Zaphod Beeblebrox To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pf@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: packet forwarding/firewall performance question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:03:09 -0000 On Tue, Aug 18, 2009 at 6:57 AM, Ian FREISLICH wrote: > Robert Watson wrote: > > > > On Thu, 13 Aug 2009, Tom Uffner wrote: > > > > > i'm hoping a few people will give me estimates on what kind of > > > throughput i should theoretically expect before i provide any actual > > > test data. also, any suggestions on tuning would be welcome. > I havn't tried 800Mhz hardware, but I have extensive experience with the 266Mhz c3 in the WRAP board for comparison. The 266 Mhz part has no heatsink, but I've found it to be flakey in "hot" environments if a heatsink is not rigged to it. So... the WRAP boards have 3 "sis" interfaces. With various combinations of usage, one can expect 30 megabit of average sized packets if they kernel is doing the passing. This makes the board an adequate wireless bridge. If userland is doing the packet passing (pppd vs. mpd as a DSL router), I've had trouble getting more than about 10 megabit through the unit. This makes it an adequate DSL router but poor for aggregating multiple links. From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 18:26:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B9F31065698; Tue, 18 Aug 2009 18:26:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD2A8FC71; Tue, 18 Aug 2009 18:26:47 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35347 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MdTNQ-0003AW-4L; Tue, 18 Aug 2009 20:25:46 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id E35F240773; Tue, 18 Aug 2009 20:25:43 +0200 (CEST) Message-Id: <8DFB5DA3-403A-46AB-9CD7-B7A2E1841BCC@exscape.org> From: Thomas Backman To: Stefan Bethke In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 20:25:41 +0200 References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MdTNQ-0003AW-4L. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MdTNQ-0003AW-4L e32aa0909cf362f9c6d39e7123d83ab7 Cc: FreeBSD current , Pawel Dawidek Jakub Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:26:48 -0000 On Aug 18, 2009, at 18:11, Stefan Bethke wrote: > Am 18.08.2009 um 16:20 schrieb Thomas Backman: > >> On Aug 17, 2009, at 17:24, Thomas Backman wrote: >> >>> On Aug 17, 2009, at 15:25, Thomas Backman wrote: >>> >>>> So, I've got myself a source tree almost completely free of >>>> patches after today's batch of ZFS patches merged - all that >>>> remains is that I uncommented ps -axl from /usr/sbin/crashinfo, >>>> since it only coredumps anyway, and added CFLAGS+=-DDEBUG=1 to >>>> zfs/Makefile. >>>> >>>> One of the changes I didn't already have prior to this must have >>>> broken something, though, because this script worked just fine >>>> before the merges earlier today. >>>> The script below is the exact same I linked in http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html >>>> back in July (URL to the script: http://exscape.org/temp/zfs_clone_panic.sh >>>> ) - I made some local changes, thus the name invoked below. >>>> >>>> Now that all the patches are merged, you should need nothing but >>>> the script, bash, and the ~200MB free space on the partition >>>> containing /root/ to reproduce this problem. >>>> (Note that the "no such pool" in the FIRST script is normal; it >>>> simply tries to clean up something that isn't there, without >>>> error/sanity checking.) >>>> >>>> [...] >>>> + zpool create -f -R /slave slave ggate666 >>>> ++ date +backup-%Y%m%d-%H%M >>>> + NOW=backup-20090817-1522 >>>> + echo 'Creating snapshots' >>>> Creating snapshots >>>> + zfs snapshot -r tank@backup-20090817-1522 >>>> + echo 'Cloning pool' >>>> Cloning pool >>>> + zfs send -R tank@backup-20090817-1522 >>>> + zfs recv -vFd slave >>>> cannot receive: invalid stream (malformed nvlist) >>>> warning: cannot send 'tank@backup-20090817-1522': Broken pipe >>>> >>>> >>>> Regards, >>>> Thomas >>> This is perhaps more troubling... >>> [...] >>> [root@chaos ~]# zpool create testpool ad0s1d >>> [root@chaos ~]# zpool export testpool >>> [root@chaos ~]# zpool import testpool >>> cannot import 'testpool': no such pool available >>> >>> Regards, >>> Thomas >> >> OK, I tried to reproduce this in a VM... And I have to say I was a >> bit surprised: after doing an installkernel/installworld, but >> BEFORE REBOOTING (I install in "multi"-user (one user via ssh), >> never had a problem with that), the same issue has appeared, so I'm >> guessing zfs.ko can't be to blame here? > > It's not the zpool binary by itself: after updating from a two-day > old current (make world && reboot): > > root@freebsd-current:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > zroot 14.9G 753M 14.1G 4% ONLINE - > root@freebsd-current:~# zpool export zroot > root@freebsd-current:~# zpool list > no pools available > root@freebsd-current:~# zpool import zroot > cannot import 'zroot': no such pool available > root@freebsd-current:~# zpool.old import zroot > cannot import 'zroot': no such pool available > root@freebsd-current:~# zpool.old import > root@freebsd-current:~# uname -a > FreeBSD freebsd-current.lassitu.de 8.0-BETA2 FreeBSD 8.0-BETA2 #1 > r196359: Tue Aug 18 16:42:41 CEST 2009 root@freebsd-current.lassitu.de > :/usr/obj/usr/src/sys/MINIMAL amd64 > > I saved zfs and zpool before the installworld. And my root is > actually on UFS; this pool was left over from root on zfs raidz > experiments. > > root@freebsd-current:~# ls -l /sbin/zpool* > -r-xr-xr-x 1 root wheel 76752 Aug 18 17:47 /sbin/zpool* > -r-xr-xr-x 1 root wheel 76752 Aug 18 17:46 /sbin/zpool.old* > root@freebsd-current:~# md5 /sbin/zpool* > MD5 (/sbin/zpool) = 83dcf6343bb0392a38159dd456dcf4c5 > MD5 (/sbin/zpool.old) = 340cb5a383b2fc3c77afbdc881258597 Interestingly, it doesn't appear to be the kernel by itself, either. I did a bad thing(tm) and reverted my sources back to r196074 + patches, the last rev I had working before yesterday's upgrade, and then did a build+installkernel. I did *not* build/install world. Yes, I know that this is bound to cause problems, just thought I'd chime in anyway. The same problems remained with the old kernel. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 18:30:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78FA0106568B for ; Tue, 18 Aug 2009 18:30:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id A158B8FC61 for ; Tue, 18 Aug 2009 18:30:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5B91D45CDD; Tue, 18 Aug 2009 20:30:15 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E84B945C89; Tue, 18 Aug 2009 20:30:09 +0200 (CEST) Date: Tue, 18 Aug 2009 20:30:11 +0200 From: Pawel Jakub Dawidek To: Thomas Backman Message-ID: <20090818183011.GA1794@garage.freebsd.pl> References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> <8DFB5DA3-403A-46AB-9CD7-B7A2E1841BCC@exscape.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <8DFB5DA3-403A-46AB-9CD7-B7A2E1841BCC@exscape.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: FreeBSD current , Stefan Bethke Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:30:18 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2009 at 08:25:41PM +0200, Thomas Backman wrote: > Interestingly, it doesn't appear to be the kernel by itself, either. I = =20 > did a bad thing(tm) and reverted my sources back to r196074 + patches, = =20 > the last rev I had working before yesterday's upgrade, and then did a =20 > build+installkernel. I did *not* build/install world. Yes, I know that = =20 > this is bound to cause problems, just thought I'd chime in anyway. The = =20 > same problems remained with the old kernel. I found the problem, I'll commit a fix once I get approval. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKivMzForvXbEpPzQRAobzAKDocatlV6pF2RaAsFTSWJmDs1YEggCfbrKc ZlhPs4p5i0Vbx65RQ75Mp8s= =Ysgu -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 18:25:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F52106568F for ; Tue, 18 Aug 2009 18:25:37 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 40ABE8FC41 for ; Tue, 18 Aug 2009 18:25:37 +0000 (UTC) Received: by fxm1 with SMTP id 1so3006140fxm.7 for ; Tue, 18 Aug 2009 11:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=NYvr/3c1+gqPXIlI46ITCQEesCeaaOFGIVDO4/fRxrU=; b=b1uUmJQKljX14WjY0s5JZ4cDJgE82mo2qg/bMtfJ+6/AmnpC68Lf30WdPHuJ0IvKkE Z6tI2vl3o8UsU0D7kdbOrjz3qnK3RILXBHyIjZN7LWLvjxdrmFpJ1n0l1qKQM0MFniVk H0j/cIn19GnmEpp7auRKFYddnJmK1h4CR30yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=sl6VXOAwfG5pAYZ4a2pYCYzMM57cYqAvgQYJOJi0AGwcblIplGLsCe45wTtWGX3uqs bBNZoI5nUR5DcvjMu9x02vY70zQWbmiDrvl/vqq1PAUrpPycdMVdmQRYw0em598D+bDa yQT8iYGTLPvD5LuXBz+d7lyYdczmSVEQ//o2w= Received: by 10.204.38.85 with SMTP id a21mr4020571bke.71.1250619936208; Tue, 18 Aug 2009 11:25:36 -0700 (PDT) Received: from ubm.mine.nu (e181051041.adsl.alicedsl.de [85.181.51.41]) by mx.google.com with ESMTPS id 12sm7070359fks.21.2009.08.18.11.25.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 11:25:35 -0700 (PDT) Date: Tue, 18 Aug 2009 20:25:33 +0200 From: Marc UBM To: current@freebsd.org Message-Id: <20090818202533.e79e957f.ubm.freebsd@gmail.com> In-Reply-To: <1618A5F5-F037-46CF-954A-38FB13BAA649@techwires.net> References: <1618A5F5-F037-46CF-954A-38FB13BAA649@techwires.net> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Aug 2009 18:51:50 +0000 Cc: Subject: Re: Several reported instances of boot hangs ("still waiting for xpt_config") for hptrr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:25:37 -0000 On Sun, 16 Aug 2009 14:51:25 +0200 Bernhard Schmidt wrote: > Hi, > > I do have a Highpoint RocketRaid 2220 controller myself which throws > similar errors since the release of 8.0-BETA2. Tracking the commits, > I could narrow it down to r195534. > > The issue is, that htprr makes use of xpt_scan_bus() which ist no > longer available in xpt_action[_default]() when cpi->transport is > not set to one of XPORT_*. This probably affects all drivers relying > upon xpt_scan_bus() but not setting cpi->transport. > > > This patch has been tested against latest head and stable/8 with no > more issues for me. I can confirm that this patch fixes the hptrr issue for me. It would be nice if this could make it into 8.0-RELEASE ;-) Thanks a lot for tracking it down! Bye Marc From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 20:29:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95AA0106568B for ; Tue, 18 Aug 2009 20:29:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f198.google.com (mail-px0-f198.google.com [209.85.216.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1188FC55 for ; Tue, 18 Aug 2009 20:29:45 +0000 (UTC) Received: by pxi36 with SMTP id 36so1948816pxi.7 for ; Tue, 18 Aug 2009 13:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=6H+bUwOOmoY3+cQglzwzlginF+8AhrrbXsJ1qiOC58w=; b=U+l3iaOb1qO7Q5SlgPKOVzycQ1a6NBXBLXhCqKtwXNUQjuV1N4Mis9OzwS9bfbXCIi fiJjpmZsJNJLJUo4Qz/enaJlgNf5Wpz8d+rRgE2NTuH5ZeLusOiX1q/gNRv59sOGw1ac 8PHcBQFbc7h13E56A8y+FphdxuRNYtzQK0Xgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=WNhGat6va9+DjIaDNlnNVXjBzfzne0mRPObD+0CMkecz7wPv7WxQMeMT+gvRckF0ly ME8Zpw71oxPP1ytJ50eu8ywbJAxGjGm0q+3SUr0kbtdCn/+OoTKzfzxc7/VBead5jvJz uE9eKVJOP9d5C4o6JPCmT+flzJtZHncoKkiVg= Received: by 10.114.30.15 with SMTP id d15mr6169382wad.68.1250627385017; Tue, 18 Aug 2009 13:29:45 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l38sm4937411waf.18.2009.08.18.13.29.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 13:29:43 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 18 Aug 2009 13:29:05 -0700 From: Pyun YongHyeon Date: Tue, 18 Aug 2009 13:29:05 -0700 To: "Sam Fourman Jr." Message-ID: <20090818202905.GA15025@michelle.cdnetworks.com> References: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> <11167f520908141120r3970af40s449941c9af114cc7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520908141120r3970af40s449941c9af114cc7@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Ryan Rogers , freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 20:29:45 -0000 On Fri, Aug 14, 2009 at 01:20:15PM -0500, Sam Fourman Jr. wrote: > > Thanks for testing. > > Unfortunately the change requires more testing on various > > controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer > > Yukon controllers as well as NVIDIA controllers. Since we are in > > 8.0-BETA stage changing common PHY code at this time looks > > dangerous. > > what if you roll back this commit 193289 so that MCP55 controllers > work by default again? > I've backed out the change so MCP55 should work. Thanks. > Sam Fourman Jr From owner-freebsd-current@FreeBSD.ORG Tue Aug 18 23:37:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4A32106568B for ; Tue, 18 Aug 2009 23:37:19 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3398FC43 for ; Tue, 18 Aug 2009 23:37:19 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so695128eye.7 for ; Tue, 18 Aug 2009 16:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=V3tEUadgGWGRpXO6eyvRqX89pyvmaE6yznuqEDhizLs=; b=gIERkXIHJRt3n3mKbmPwpOvZxfFVgzBZdgosxtHMhw+clxkO/hzac7104DlB8Zb3zs bug4p3Lv1OTS94bwSmuZ2dFov+Uc9lPQicqB6gNk71Uujm4uRmGwY4OejqgoQ8jmh1CI CIW+4r5Z++HhvSZIECg1Nv0z9NbNUi/j2Ld/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=xDZ0zdiEC23wQ0lwBfTjTSaV9xXUNCX4m+ht+gzRN7NWStbLOWIR7kzSSfW0A4Jwfr qQBaRIuztttHvlIgl1fIUL67HYyVjZQ0To3c4d0UXZRT4s04u7fpZb35cR1hmeFzUaRk FvBqCbmsfUnTyThq65TLA2mS3OHWTitERGx2k= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.210.76.7 with SMTP id y7mr5244275eba.75.1250638638351; Tue, 18 Aug 2009 16:37:18 -0700 (PDT) In-Reply-To: <4A8AD86E.5020302@rcn.com> References: <4A8AD86E.5020302@rcn.com> Date: Tue, 18 Aug 2009 16:37:18 -0700 X-Google-Sender-Auth: c7fd05a9baf44949 Message-ID: From: Randi Harper To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: HEAD newfs/sysinstall issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 23:37:20 -0000 On Tue, Aug 18, 2009 at 9:35 AM, Robert Huff wrote: > Did this ever get resolved? I'm having the same problem, and I > _think_ I may know (part of) the problem. The error message talks about > "/dev/ad0s1b" however in the Fixit shell a listing of /dev/ad* gives things > like > > /dev/ad0a > /dev/ad0b > /dev/ad0c > /dev/ad0d > > etc.. > This happens whether I use slices or choose "dd" mode. > > > Robert Huff > > _______________________________________________ > 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 mode is borked for the time being. It has been removed from sysinstall. -- randi From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 01:21:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ACAA106568C; Wed, 19 Aug 2009 01:21:37 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay1-v.mail.gandi.net (relay1-v.mail.gandi.net [217.70.178.75]) by mx1.freebsd.org (Postfix) with ESMTP id 600FC8FC16; Wed, 19 Aug 2009 01:21:36 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay1-v.mail.gandi.net (Postfix) with ESMTP id 6E57A362AA; Wed, 19 Aug 2009 03:21:28 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 61330F0C9; Tue, 18 Aug 2009 21:20:33 -0400 (EDT) Date: Tue, 18 Aug 2009 21:20:33 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090819012031.GA1480@plebeian.afflictions.org> References: <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> <20090813191724.GA1499@plebeian.afflictions.org> <3bbf2fe10908160910t2af565f9w3a1f5f09457e30d3@mail.gmail.com> <20090818051659.GA1477@plebeian.afflictions.org> <3bbf2fe10908172252t3b176f06r5ae46fed6644df7c@mail.gmail.com> <20090818124429.GA1483@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090818124429.GA1483@plebeian.afflictions.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 01:21:37 -0000 Damian Gerow wrote: : The ddb output seems like it was cut short. I'll try to generate a new : dump in a bit. Here's a better dump: ----- begin msgbuf.txt exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff000a51db98) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex Giant (Giant) r = 1 (0xffffffff80bdbfa0) locked @ /usr/src/sys/dev/syscons/syscons.c:596 ----- end msgbuf.txt ----- begin ddb.txt db:0:kdb.enter.default> show allpcpu Current CPU: 1 cpuid = 0 dynamic pcpu = 0x56ff00 curthread = 0xffffff00024f6390: pid 11 "idle: cpu0" curpcb = 0xffffff800002dd40 fpcurthread = none idlethread = 0xffffff00024f6390: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80de7900 commontssp = 0xffffffff80de7900 rsp0 = 0xffffff800002dd40 gs32p = 0xffffffff80de6738 ldt = 0xffffffff80de6778 tss = 0xffffffff80de6768 spin locks held: cpuid = 1 dynamic pcpu = 0xffffff807f483f00 curthread = 0xffffff0002512000: pid 12 "swi6: Giant taskq" curpcb = 0xffffff8000072d40 fpcurthread = none idlethread = 0xffffff00024f6720: pid 11 "idle: cpu1" curpmap = 0 tssp = 0xffffffff80de7968 commontssp = 0xffffffff80de7968 rsp0 = 0xffffff8000072d40 gs32p = 0xffffffff80de67a0 ldt = 0xffffffff80de67e0 tss = 0xffffffff80de67d0 spin locks held: db:0:kdb.enter.default> bt Tracing pid 12 tid 100017 td 0xffffff0002512000 kdb_enter() at kdb_enter+0x3d scgetc() at scgetc+0x5e8 sckbdevent() at sckbdevent+0x1fc kbdmux_intr() at kbdmux_intr+0x24 kbdmux_kbd_intr() at kbdmux_kbd_intr+0x23 taskqueue_run() at taskqueue_run+0xf3 taskqueue_swi_giant_run() at taskqueue_swi_giant_run+0x10 intr_event_execute_handlers() at intr_event_execute_handlers+0x107 ithread_loop() at ithread_loop+0xbe fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000072d30, rbp = 0 --- db:0:kdb.enter.default> ps pid ppid pgrp uid state wmesg wchan cmd 1550 1530 1518 1001 S futex 0xffffff000364e9c0 npviewer.bin 1549 1530 1518 1001 S futex 0xffffff0003e6e7c0 npviewer.bin 1546 1530 1518 1001 S select 0xffffff0034fae440 npviewer.bin 1542 1 1541 1001 S select 0xffffff0034d7a540 initial thread 1537 1 1535 1001 S select 0xffffff000a9341c0 initial thread 1535 1 1535 1001 Ss select 0xffffff000a3620c0 dbus-daemon 1534 1 1518 1001 S select 0xffffff00347d8cc0 dbus-launch 1530 1526 1518 1001 S (threaded) firefox-bin 100235 S ucond 0xffffff0034bc7300 firefox-bin 100234 S ucond 0xffffff000366e980 firefox-bin 100232 S ucond 0xffffff000366ea00 firefox-bin 100231 S ucond 0xffffff000366eb00 firefox-bin 100230 S ucond 0xffffff000366eb80 firefox-bin 100227 S ucond 0xffffff00345c3300 firefox-bin 100229 S ucond 0xffffff0034bc7200 firefox-bin 100228 S ucond 0xffffff000a57f880 firefox-bin 100226 S ucond 0xffffff000a11f800 firefox-bin 100225 S ucond 0xffffff0003f96d80 firefox-bin 100224 S select 0xffffff003470c4c0 firefox-bin 100188 S select 0xffffff00347da940 initial thread 1526 1518 1518 1001 S wait 0xffffff0003a6f000 sh 1518 1 1518 1001 Ss wait 0xffffff000a69d460 sh 1515 1240 1240 125 S kqread 0xffffff000aa6c700 tlsmgr 1479 1449 1479 1001 Ss+ ttyin 0xffffff0002c060a8 zsh 1473 1449 1473 1001 Ss+ ttyin 0xffffff00027298a8 zsh 1470 1 1457 1001 S select 0xffffff000a521840 conky 1469 1 1461 1001 S select 0xffffff0003b09040 conky 1468 1 1459 1001 S select 0xffffff000a5227c0 conky 1467 1461 1461 1001 S select 0xffffff000a520540 dzen2 1465 1459 1459 1001 S select 0xffffff000a5218c0 dzen2 1463 1457 1457 1001 S select 0xffffff003446ba40 dzen2 1461 1 1461 1001 Ss wait 0xffffff000a3998c0 sh 1459 1 1459 1001 Ss wait 0xffffff0003b178c0 sh 1457 1 1457 1001 Ss wait 0xffffff0003edc000 sh 1455 1 1455 1001 Ss select 0xffffff0003ded9c0 dzen2 1453 1443 1443 1001 S+ select 0xffffff003440b1c0 dzen2 1452 1443 1443 1001 S+ select 0xffffff000a38ee40 xmonad-x86_64-freeb 1449 1 1443 1001 S+ select 0xffffff000a5210c0 urxvtd 1448 1 1443 1001 S+ sbwait 0xffffff000a51dbe4 urxvtd 1446 1 1446 1001 Ss select 0xffffff000a520440 ssh-agent 1443 1439 1443 1001 S+ wait 0xffffff000a397460 sh 1440 1439 1440 1001 S+ drmwtq 0xffffff000266c13c initial thread 1439 1421 1421 1001 S+ wait 0xffffff0003a62000 xinit 1421 1417 1421 1001 S+ wait 0xffffff000a63c000 sh 1417 1364 1417 1001 S+ pause 0xffffff000a69e500 zsh 1385 1380 1376 0 S kqread 0xffffff000a078900 initial thread 1380 1376 1376 0 S select 0xffffff000a0d51c0 initial thread 1379 1 1379 0 Ss (threaded) console-kit-daemon 100199 S waitvt 0xffffffff80bd79c0 console-kit-daemon 100206 S waitvt 0xffffffff80bd7a38 console-kit-daemon 100205 S waitvt 0xffffffff80bd7a30 console-kit-daemon 100204 S waitvt 0xffffffff80bd7a28 console-kit-daemon 100203 S waitvt 0xffffffff80bd7a20 console-kit-daemon 100202 S waitvt 0xffffffff80bd7a18 console-kit-daemon 100201 S waitvt 0xffffffff80bd7a10 console-kit-daemon 100200 S waitvt 0xffffffff80bd7a08 console-kit-daemon 100198 S waitvt 0xffffffff80bd79f8 console-kit-daemon 100197 S waitvt 0xffffffff80bd79f0 console-kit-daemon 100196 S waitvt 0xffffffff80bd79e8 console-kit-daemon 100195 S waitvt 0xffffffff80bd79e0 console-kit-daemon 100194 S waitvt 0xffffffff80bd79d8 console-kit-daemon 100193 S waitvt 0xffffffff80bd79d0 console-kit-daemon 100192 S waitvt 0xffffffff80bd79c8 console-kit-daemon 100191 S ucond 0xffffff000a363880 console-kit-daemon 100141 S select 0xffffff000a38ecc0 console-kit-daemon 1376 1 1376 560 Ss select 0xffffff000a420a40 hald 1371 1 1371 0 Ss+ ttyin 0xffffff000354a8a8 getty 1370 1 1370 0 Ss+ ttyin 0xffffff000353e8a8 getty 1369 1 1369 0 Ss+ ttyin 0xffffff000354b0a8 getty 1368 1 1368 0 Ss+ ttyin 0xffffff000353fca8 getty 1367 1 1367 0 Ss+ ttyin 0xffffff000354e4a8 getty 1366 1 1366 0 Ss+ ttyin 0xffffff000353cca8 getty 1365 1 1365 0 Ss+ ttyin 0xffffff00025050a8 getty 1364 1 1364 0 Ss+ wait 0xffffff0003b17460 login 1308 1 1308 0 Ss nanslp 0xffffffff80bdcbe8 cron 1299 1 1299 0 Ss select 0xffffff000a4203c0 sshd 1256 1 1256 556 Ss select 0xffffff000a2ce8c0 dbus-daemon 1250 1240 1240 125 S kqread 0xffffff000a017600 qmgr 1249 1240 1240 125 S kqread 0xffffff000a00d300 pickup 1240 1 1240 0 Ss kqread 0xffffff000a2cf700 master 1122 1 1122 65 Ss select 0xffffff000a1eba40 dhclient 1105 1 1105 0 Ss select 0xffffff0003dbae40 dhclient 1081 1 1081 0 Ss kqread 0xffffff000a019d00 cupsd 1038 1 1038 0 Ss select 0xffffff0003e52a40 powerd 964 1 964 0 Ss rpcsvc 0xffffff0003e71ba0 NLM: master 951 1 951 0 Ss select 0xffffff0003da8540 rpc.statd 949 1 949 0 Ss select 0xffffff0003f94540 rpcbind 875 0 0 0 SL mdwait 0xffffff000a009000 [md0] 826 1 826 0 Ss select 0xffffff0003f950c0 syslogd 729 0 0 0 SL - 0xffffffff80bd9c40 [accounting] 656 1 656 0 Ss select 0xffffff0003aa4640 devd 285 0 0 0 SL tq->tq_d 0xffffff0003ad3060 [zil_clean] 284 0 0 0 SL tq->tq_d 0xffffff0003abade0 [zil_clean] 283 0 0 0 SL tq->tq_d 0xffffff0003abacc0 [zil_clean] 282 0 0 0 SL tq->tq_d 0xffffff0003ababa0 [zil_clean] 281 0 0 0 SL tq->tq_d 0xffffff0003abaa80 [zil_clean] 280 0 0 0 SL tq->tq_d 0xffffff0003aba960 [zil_clean] 279 0 0 0 SL tq->tq_d 0xffffff0003aba840 [zil_clean] 278 0 0 0 SL tq->tq_d 0xffffff0003a48a80 [zil_clean] 277 0 0 0 SL tq->tq_d 0xffffff0003a48960 [zil_clean] 276 0 0 0 SL tq->tq_d 0xffffff0003a48840 [zil_clean] 275 0 0 0 SL tx->tx_s 0xffffff000369f238 [txg_thread_enter] 274 0 0 0 SL tx->tx_q 0xffffff000369f258 [txg_thread_enter] 273 0 0 0 SL vgeom:io 0xffffff0003aa4b10 [vdev:worker ad4s1d.] 272 0 0 0 SL tq->tq_d 0xffffff0003a47600 [spa_zio] 271 0 0 0 SL tq->tq_d 0xffffff0003a47720 [spa_zio] 270 0 0 0 SL tq->tq_d 0xffffff0003a47840 [spa_zio] 269 0 0 0 SL tq->tq_d 0xffffff0003a47960 [spa_zio] 268 0 0 0 SL tq->tq_d 0xffffff0003aba2a0 [spa_zio] 267 0 0 0 SL tq->tq_d 0xffffff0003aba180 [spa_zio] 266 0 0 0 SL tq->tq_d 0xffffff0003aba060 [spa_zio] 265 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 264 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 263 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 262 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 261 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 260 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 259 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 258 0 0 0 SL tq->tq_d 0xffffff0003a48720 [spa_zio] 257 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 256 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 255 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 254 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 253 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 252 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 251 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 250 0 0 0 SL tq->tq_d 0xffffff0003a48600 [spa_zio] 249 0 0 0 SL tq->tq_d 0xffffff0003a484e0 [spa_zio] 248 0 0 0 SL tq->tq_d 0xffffff0003a483c0 [spa_zio] 247 0 0 0 SL tq->tq_d 0xffffff0003a482a0 [spa_zio] 192 0 0 0 SL geli:w 0xffffff000369f400 [g_eli[1] ad4s1d] 191 0 0 0 SL geli:w 0xffffff000369f400 [g_eli[0] ad4s1d] 186 0 0 0 SL crypto_r 0xffffffff81339900 [crypto returns] 185 0 0 0 SL crypto_w 0xffffffff813398c0 [crypto] 75 0 0 0 SL l2arc_fe 0xffffffff8130bec0 [l2arc_feed_thread] 74 0 0 0 SL arc_recl 0xffffffff813038e0 [arc_reclaim_thread] 72 0 0 0 SL vacv 0xffffffff813025e0 [vaclean] 71 0 0 0 SL tq->tq_d 0xffffff0003a48060 [system_taskq] 70 0 0 0 SL tq->tq_d 0xffffff0003a48060 [system_taskq] 52 0 0 0 SL flowclea 0xffffffff80bdc8c4 [flowcleaner] 51 0 0 0 SL sdflush 0xffffffff80dad358 [softdepflush] 50 0 0 0 SL syncer 0xffffffff80d9e1c0 [syncer] 49 0 0 0 SL vlruwt 0xffffff00035da000 [vnlru] 48 0 0 0 SL psleep 0xffffffff80d9dce8 [bufdaemon] 9 0 0 0 SL pgzero 0xffffffff80daedac [pagezero] 8 0 0 0 SL psleep 0xffffffff80dae148 [vmdaemon] 7 0 0 0 SL psleep 0xffffffff80dae10c [pagedaemon] 47 0 0 0 SL wmsg 0xffffff8000326dd0 [usbus7] 46 0 0 0 SL wmsg 0xffffff8000326d78 [usbus7] 45 0 0 0 SL wmsg 0xffffff8000326d20 [usbus7] 44 0 0 0 SL wmsg 0xffffff8000326cc8 [usbus7] 43 0 0 0 SL wmsg 0xffffff800031def0 [usbus6] 42 0 0 0 SL wmsg 0xffffff800031de98 [usbus6] 41 0 0 0 SL wmsg 0xffffff800031de40 [usbus6] 40 0 0 0 SL wmsg 0xffffff800031dde8 [usbus6] 39 0 0 0 SL wmsg 0xffffff8000314ef0 [usbus5] 38 0 0 0 SL wmsg 0xffffff8000314e98 [usbus5] 37 0 0 0 SL wmsg 0xffffff8000314e40 [usbus5] 36 0 0 0 SL wmsg 0xffffff8000314de8 [usbus5] 35 0 0 0 SL wmsg 0xffffff800030bef0 [usbus4] 34 0 0 0 SL wmsg 0xffffff800030be98 [usbus4] 33 0 0 0 SL wmsg 0xffffff800030be40 [usbus4] 32 0 0 0 SL wmsg 0xffffff800030bde8 [usbus4] 31 0 0 0 SL wmsg 0xffffff8000302dd0 [usbus3] 30 0 0 0 SL wmsg 0xffffff8000302d78 [usbus3] 29 0 0 0 SL wmsg 0xffffff8000302d20 [usbus3] 28 0 0 0 SL wmsg 0xffffff8000302cc8 [usbus3] 27 0 0 0 SL wmsg 0xffffff80002f9ef0 [usbus2] 26 0 0 0 SL wmsg 0xffffff80002f9e98 [usbus2] 25 0 0 0 SL wmsg 0xffffff80002f9e40 [usbus2] 24 0 0 0 SL wmsg 0xffffff80002f9de8 [usbus2] 23 0 0 0 SL wmsg 0xffffff80002f0ef0 [usbus1] 22 0 0 0 SL wmsg 0xffffff80002f0e98 [usbus1] 21 0 0 0 SL wmsg 0xffffff80002f0e40 [usbus1] 20 0 0 0 SL wmsg 0xffffff80002f0de8 [usbus1] 19 0 0 0 SL wmsg 0xffffff80002e7ef0 [usbus0] 18 0 0 0 SL wmsg 0xffffff80002e7e98 [usbus0] 17 0 0 0 SL wmsg 0xffffff80002e7e40 [usbus0] 16 0 0 0 SL wmsg 0xffffff80002e7de8 [usbus0] 6 0 0 0 SL waiting_ 0xffffffff80da10e0 [sctp_iterator] 15 0 0 0 SL cooling 0xffffff000352ad58 [acpi_cooling1] 14 0 0 0 SL tzpoll 0xffffffff80baa210 [acpi_thermal] 5 0 0 0 SL ccb_scan 0xffffffff80ba5b60 [xpt_thrd] 13 0 0 0 SL - 0xffffffff80bdc8c4 [yarrow] 4 0 0 0 SL - 0xffffffff80bd90a8 [g_down] 3 0 0 0 SL - 0xffffffff80bd90a0 [g_up] 2 0 0 0 SL - 0xffffffff80bd9090 [g_event] 12 0 0 0 RL (threaded) intr 100223 I [irq256:] 100039 I [irq12: psm0] 100038 I [irq1: atkbd0] 100035 I [irq19: ehci1] 100034 I [irq18: uhci5] 100033 I [irq17: uhci4] 100032 I [irq16: uhci3+] 100031 I [irq258: hdac0] 100030 I [irq23: ehci0+] 100029 I [irq22: uhci2] 100028 I [irq21: uhci1] 100027 I [irq20: uhci0] 100025 I [irq9: acpi0] 100024 I [swi2: cambio] 100018 I [swi6: task queue] 100017 Run CPU 1 [swi6: Giant taskq] 100014 I [swi5: +] 100008 I [swi3: vm] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 I [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 Run CPU 0 [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff00024f48c0 [init] 10 0 0 0 SL audit_wo 0xffffffff80dac6b0 [audit] 0 0 0 0 SLs (threaded) kernel 100026 D - 0xffffff0002726500 [em0 taskq] 100022 D - 0xffffff000265a300 [kqueue taskq] 100021 D - 0xffffff000261fc80 [acpi_task_2] 100020 D - 0xffffff000261fc80 [acpi_task_1] 100019 D - 0xffffff000261fc80 [acpi_task_0] 100016 D - 0xffffff000265a080 [aiod_bio taskq] 100015 D - 0xffffff000265a100 [thread taskq] 100012 D - 0xffffff00024f8580 [firmware taskq] 100000 D sched 0xffffffff80bd91a0 [swapper] db:0:kdb.enter.default> show alllocks Process 1448 (urxvtd) thread 0xffffff000a3ce390 (100187) Process 12 (intr) thread 0xffffff0002512000 (100017) db:0:kdb.enter.default> alltrace Tracing command npviewer.bin pid 1550 tid 100216 td 0xffffff000a41a000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 linux_sys_futex() at linux_sys_futex+0x6b9 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28767f60, rsp = 0x32a4e2b0, rbp = 0x32a4e2f8 --- Tracing command npviewer.bin pid 1549 tid 100177 td 0xffffff0003e91ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 linux_sys_futex() at linux_sys_futex+0x6b9 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28767f60, rsp = 0x2ea4e2b0, rbp = 0x2ea4e2f8 --- Tracing command npviewer.bin pid 1546 tid 100089 td 0xffffff0003980ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 ia32_syscall() at ia32_syscall+0x2a4 Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (168, Linux ELF32, poll), rip = 0x2886682d, rsp = 0xffffd5c4, rbp = 0xffffd5d8 --- Tracing command gam_server pid 1542 tid 100190 td 0xffffff000a3cd720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800de24dc, rsp = 0x7fffffffe538, rbp = 0x5 --- Tracing command gconfd-2 pid 1537 tid 100129 td 0xffffff0003a9f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x80162f4dc, rsp = 0x7fffffffe488, rbp = 0x7 --- Tracing command dbus-daemon pid 1535 tid 100189 td 0xffffff000a3cdab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8009544dc, rsp = 0x7fffffffe0b8, rbp = 0 --- Tracing command dbus-launch pid 1534 tid 100214 td 0xffffff000a3cf720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8010ba0cc, rsp = 0x7fffffffe038, rbp = 0x6 --- Tracing command firefox-bin pid 1530 tid 100235 td 0xffffff0034d47720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffddefe08, rbp = 0x80d878d80 --- Tracing command firefox-bin pid 1530 tid 100234 td 0xffffff00039f9390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffdff0e08, rbp = 0x80e406340 --- Tracing command firefox-bin pid 1530 tid 100232 td 0xffffff00039f9720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffeff8e08, rbp = 0x80c0f8800 --- Tracing command firefox-bin pid 1530 tid 100231 td 0xffffff00039f9ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff3fadc8, rbp = 0x80c0f8b80 --- Tracing command firefox-bin pid 1530 tid 100230 td 0xffffff00039fa000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff1f9e08, rbp = 0x80c0f89c0 --- Tracing command firefox-bin pid 1530 tid 100227 td 0xffffff0034d47000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffd9eddc8, rbp = 0x80c2a2a00 --- Tracing command firefox-bin pid 1530 tid 100229 td 0xffffff0034d39390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffebf6e98, rbp = 0x80c0f6c00 --- Tracing command firefox-bin pid 1530 tid 100228 td 0xffffff000a57e720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7ffffedf7e78, rbp = 0x80c0f6f80 --- Tracing command firefox-bin pid 1530 tid 100226 td 0xffffff000a4f6ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff7fcda8, rbp = 0x806808e40 --- Tracing command firefox-bin pid 1530 tid 100225 td 0xffffff000a249000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 do_cv_wait() at do_cv_wait+0x5e5 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x804b1ef0c, rsp = 0x7fffff9fde68, rbp = 0x80889dc40 --- Tracing command firefox-bin pid 1530 tid 100224 td 0xffffff000a249390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8048664dc, rsp = 0x7fffffbfeb08, rbp = 0x7fffffbfeb4c --- Tracing command firefox-bin pid 1530 tid 100188 td 0xffffff000a3ce000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8048664dc, rsp = 0x7fffffffdca8, rbp = 0x8068e7000 --- Tracing command sh pid 1526 tid 100124 td 0xffffff0003aa0ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe3b8, rbp = 0x5ee --- Tracing command sh pid 1518 tid 100221 td 0xffffff000a249ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe7b8, rbp = 0x5ee --- Tracing command tlsmgr pid 1515 tid 100136 td 0xffffff00039faab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801126c0c, rsp = 0x7fffffffde08, rbp = 0x7fffffffde10 --- Tracing command zsh pid 1479 tid 100183 td 0xffffff000a3cf390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe538, rbp = 0 --- Tracing command zsh pid 1473 tid 100103 td 0xffffff0003a69000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe538, rbp = 0 --- Tracing command conky pid 1470 tid 100209 td 0xffffff000a57aab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command conky pid 1469 tid 100165 td 0xffffff0003ac1ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command conky pid 1468 tid 100210 td 0xffffff000a57a720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8016a44dc, rsp = 0x7fffffffe528, rbp = 0x801947000 --- Tracing command dzen2 pid 1467 tid 100213 td 0xffffff000a3cfab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command dzen2 pid 1465 tid 100208 td 0xffffff000a57c000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command dzen2 pid 1463 tid 100087 td 0xffffff0003984000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x801271500 --- Tracing command sh pid 1461 tid 100178 td 0xffffff0003e91720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe898, rbp = 0x5b5 --- Tracing command sh pid 1459 tid 100173 td 0xffffff0003e16ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe8a8, rbp = 0x5b3 --- Tracing command sh pid 1457 tid 100160 td 0xffffff0003bfe000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe8a8, rbp = 0x5b1 --- Tracing command dzen2 pid 1455 tid 100154 td 0xffffff0003bff720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd58, rbp = 0x290 --- Tracing command dzen2 pid 1453 tid 100222 td 0xffffff000a249720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffde28, rbp = 0x801271500 --- Tracing command xmonad-x86_64-freeb pid 1452 tid 100122 td 0xffffff0003aa2390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8011d64dc, rsp = 0x7fffffffa7c8, rbp = 0x801846000 --- Tracing command urxvtd pid 1449 tid 100217 td 0xffffff000a501ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x80284e0cc, rsp = 0x7fffffffe918, rbp = 0x40 --- Tracing command urxvtd pid 1448 tid 100187 td 0xffffff000a3ce390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sbwait() at sbwait+0x66 soreceive_generic() at soreceive_generic+0x377 soreceive() at soreceive+0x12 soo_read() at soo_read+0x3d dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80284e14c, rsp = 0x7fffffffe728, rbp = 0x7fffffffe768 --- Tracing command ssh-agent pid 1446 tid 100207 td 0xffffff000a57c390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d2b0cc, rsp = 0x7fffffffe9f8, rbp = 0xa --- Tracing command sh pid 1443 tid 100185 td 0xffffff000a3ceab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe988, rbp = 0x5a3 --- Tracing command Xorg pid 1440 tid 100082 td 0xffffff0003985390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 i915_irq_wait() at i915_irq_wait+0x15d drm_ioctl() at drm_ioctl+0x2f3 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801a020ec, rsp = 0x7fffffffe508, rbp = 0x7fffffffe550 --- Tracing command xinit pid 1439 tid 100100 td 0xffffff00035e3720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8008d816c, rsp = 0x7fffffffea48, rbp = 0x7fffffffea70 --- Tracing command sh pid 1421 tid 100219 td 0xffffff000a501390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe858, rbp = 0x58d --- Tracing command zsh pid 1417 tid 100215 td 0xffffff000a41a390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_sigsuspend() at kern_sigsuspend+0xcd sigsuspend() at sigsuspend+0x34 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x800b562ac, rsp = 0x7fffffffea68, rbp = 0 --- Tracing command hald-addon-mouse-sy pid 1385 tid 100158 td 0xffffff0003bfe720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e44c0c, rsp = 0x7fffffffe788, rbp = 0x801621070 --- Tracing command hald-runner pid 1380 tid 100175 td 0xffffff0003e16390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800c0d4dc, rsp = 0x7fffffffeb68, rbp = 0x1 --- Tracing command console-kit-daemon pid 1379 tid 100199 td 0xffffff00039fa720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffaeef38, rbp = 0x1 --- Tracing command console-kit-daemon pid 1379 tid 100206 td 0xffffff000a57c720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffafff38, rbp = 0x10 --- Tracing command console-kit-daemon pid 1379 tid 100205 td 0xffffff000a57cab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb10f38, rbp = 0xf --- Tracing command console-kit-daemon pid 1379 tid 100204 td 0xffffff000a57d000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb21f38, rbp = 0xe --- Tracing command console-kit-daemon pid 1379 tid 100203 td 0xffffff000a57d390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb32f38, rbp = 0xd --- Tracing command console-kit-daemon pid 1379 tid 100202 td 0xffffff000a57d720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb43f38, rbp = 0xc --- Tracing command console-kit-daemon pid 1379 tid 100201 td 0xffffff000a57dab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb54f38, rbp = 0xb --- Tracing command console-kit-daemon pid 1379 tid 100200 td 0xffffff000a57e000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb65f38, rbp = 0xa --- Tracing command console-kit-daemon pid 1379 tid 100198 td 0xffffff0003e08720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl( ----- end ddb.txt From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 07:01:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8028F106568B for ; Wed, 19 Aug 2009 07:01:52 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF3B8FC3F for ; Wed, 19 Aug 2009 07:01:51 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id EF7A82C2B32; Wed, 19 Aug 2009 02:01:50 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7h5+8U1DMLoH; Wed, 19 Aug 2009 02:01:43 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 19DAA2C2A81; Wed, 19 Aug 2009 02:01:43 -0500 (CDT) Message-ID: <4A8BA356.8020502@cs.rice.edu> Date: Wed, 19 Aug 2009 02:01:42 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= , current@freebsd.org References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> In-Reply-To: <20090714105245.GR2145@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 07:01:52 -0000 Ulrich Spörlein wrote: > On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: > >> Ulrich Spörlein wrote: >> >>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: >>> >>> >>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: >>>> >>>> >>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static >>>>>> analyzer on a buildworld with something like the following panic: >>>>>> >>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 >>>>>> cpuid = 1 >>>>>> KDB: stack backtrace: >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>>>>> panic() at panic+0x182 >>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 >>>>>> vm_object_terminate() at vm_object_terminate+0xb7 >>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a >>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 >>>>>> vm_map_remove() at vm_map_remove+0x6f >>>>>> vmspace_free() at vmspace_free+0x56 >>>>>> vmspace_exec() at vmspace_exec+0x56 >>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 >>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee >>>>>> kern_execve() at kern_execve+0x3b2 >>>>>> execve() at execve+0x3d >>>>>> syscall() at syscall+0x1af >>>>>> Xfast_syscall() at Xfast_syscall+0xe1 >>>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- >>>>>> >>>>>> >>>>> Can you try the following change: >>>>> >>>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 >>>>> >>>>> >>>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into >>>> the scan-build run. So no luck there. Next up is a test using the >>>> GENERIC kernel. >>>> >>> No improvement with a GENERIC kernel. Next up will be to run this with >>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. >>> >>> Does the backtrace above point to any specific subsystem? I'm using UFS, >>> ZFS and GELI on this machine and could try a few combinations... >>> >> The interesting thing about the backtrace is that it shows a 32-bit i386 >> executable being started on a 64-bit amd64 machine. I've seen this >> backtrace once before, and you'll find it in the PR database. In that >> case, the problem "went away" after the known-to-be-broken >> ZERO_COPY_SOCKETS option was removed from the reporter's kernel >> configuration. However, I don't see that as the culprit here. >> > > Hi Alan, first the bad news > > I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set to 2 > GB in single user mode, so no other processes or deamons running, > nothing special in loader.conf except for ZFS and GELI. It reliably > panics, so nothing new here. > > Now the good news, you may be able to crash your own amd64 box in 3 > minutes by doing: > > mkdir /tmp/foo && cd /tmp/foo > fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - > while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done > > Please note that scan-build/ccc-analyzer wont actually do anything, as > they cannot create output in /dev/null. So this is just running the > perl-script and forking make/sh/awk/ccc-analyzer like mad. It does not > survive 3 minutes on my Core2 Duo 3.3 GHz. > I just wanted to let you know that Kostik Belousov committed a change (r196318) on Monday that fixes a pmap bug that could have produced this assertion failure. So, if you see this assertion failure again after updating your kernel, please let me know. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 09:08:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BFE1065690 for ; Wed, 19 Aug 2009 09:08:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9828FC55 for ; Wed, 19 Aug 2009 09:08:04 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Mdh9F-000Aja-4X; Wed, 19 Aug 2009 12:08:01 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Thomas Backman In-reply-to: References: Comments: In-reply-to Thomas Backman message dated "Tue, 18 Aug 2009 18:46:54 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Aug 2009 12:08:01 +0300 From: Danny Braniss Message-ID: Cc: Stefan Bethke , current@freebsd.org Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:08:05 -0000 > On Aug 18, 2009, at 16:42, Danny Braniss wrote: > > >> it seems that the latest changes to zfs prevents zpool to see/find > >> the pool in /dev/ad0p4 (BTW, the pool was created under 8.0) > >> > >> # gpart show > >> => 34 1953525101 ad0 GPT (932G) > >> 34 128 1 freebsd-boot (64K) > >> 162 4194304 2 freebsd-ufs (2.0G) > >> 4194466 8388608 3 freebsd-swap (4.0G) > >> 12583074 1940942061 4 freebsd-zfs (926G) > >> > >> # zpool list > >> no pools available > >> # zpool import -a > >> # > >> > >> under 7.2, the pool is still there: > >> > >> pundit-2> zfs list > >> NAME USED AVAIL REFER MOUNTPOINT > >> z 5.27G 900G 18K /z > >> z/home 5.21G 900G 5.21G /home > >> z/var 59.7M 900G 59.7M /var > >> pundit-2> zpool list > >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT > >> z 920G 5.27G 915G 0% ONLINE - > > > > running 'truss zpool import -a' reveals the problem: > > > > open("ad0p4",O_RDONLY,00) ERR#2 'No such file > > or directory' > > open("/dev/ad0p4",O_RDONLY,05003312752) = 5 (0x5) > > ioctl(5,DIOCGSECTORSIZE,0xbfbfa1f4) = 0 (0x0) > > fstat(5,{ mode=crw-r----- ,inode=75,size=0,blksize=4096 }) = 0 (0x0) > > pread(0x5,0x2834a000,0x40000,0x0,0x0,0x805ab64) = 262144 (0x40000) > > pread(0x5,0x2834a000,0x40000,0x40000,0x0,0x1bfd8) = 262144 (0x40000) > > pread(0x5,0x2834a000,0x40000,0xfff80000,0xffffffff,0x1bfd8) ERR#5 > > 'Input/output error' > > ********** offset is a bit too big :-) > > pread(0x5,0x2834a000,0x40000,0xfffc0000,0xffffffff,0x1bfd8) ERR#5 > > 'Input/output error' > > Glad I'm not the only one. I reported the same issue yesterday, in a > thread originally about something else zfs related (zfs send sends a > broken stream, or recv considers it broken despite it being fine; I > don't know which one it is): http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010709.html > > FWIW, my truss output (ggate142 is the ZFS pool device I *just* > created and then exported, and ad2s1b is my swap/dump device): > (from "truss -o outfile zpool import") > [...] > open("ad2s1b",O_RDONLY,00) ERR#2 'No such file > or directory' > open("/dev/ad2s1b",O_RDONLY,00) = 7 (0x7) > ioctl(7,DIOCGSECTORSIZE,0xffff9fc4) = 0 (0x0) > fstat(7,{ mode=crw-r----- ,inode=79,size=0,blksize=4096 }) = 0 (0x0) > pread(0x7,0x80128c000,0x40000,0x0,0x34004,0x801201340) = 262144 > (0x40000) > pread(0x7,0x80128c000,0x40000,0x40000,0x1,0x801201340) = 262144 > (0x40000) > pread(0x7,0x80128c000,0x40000,0xfffffffffff80000,0x1,0x801201340) > ERR#5 'Input/output error' > pread(0x7,0x80128c000,0x40000,0xfffffffffffc0000,0x1,0x801201340) > ERR#5 'Input/output error' > close(7) = 0 (0x0) > open("ggate142",O_RDONLY,00) ERR#2 'No such file > or directory' > open("/dev/ggate142",O_RDONLY,00) = 7 (0x7) > ioctl(7,DIOCGSECTORSIZE,0xffff9fc4) = 0 (0x0) > fstat(7,{ mode=crw-r----- ,inode=93,size=0,blksize=4096 }) = 0 (0x0) > pread(0x7,0x80128c000,0x40000,0x0,0x34004,0x801201340) = 262144 > (0x40000) > pread(0x7,0x80128c000,0x40000,0x40000,0x1,0x801201340) = 262144 > (0x40000) > pread(0x7,0x80128c000,0x40000,0xfffffffffff80000,0x1,0x801201340) > ERR#5 'Input/output error' > pread(0x7,0x80128c000,0x40000,0xfffffffffffc0000,0x1,0x801201340) > ERR#5 'Input/output error' > close(7) = 0 (0x0) > close(4) = 0 (0x0) > close(5) = 0 (0x0) > close(6) = 0 (0x0) > ... > sigprocmask(...) > process exit, rval = 1 > > Regards, > Thomas the plot thickens, compiling cddl/lib/libnvpair under 8-BETA2 works ok, so it seems that cross compiling (using a 7.2 system) causes the problem, it seems it's picking something from the local environment. any make expert in the house? danny From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 09:21:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D554F10656AE for ; Wed, 19 Aug 2009 09:21:15 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBC78FC66 for ; Wed, 19 Aug 2009 09:21:15 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:53592 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MdhLm-0008AS-3w; Wed, 19 Aug 2009 11:21:00 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3F5E31A309; Wed, 19 Aug 2009 11:20:56 +0200 (CEST) Message-Id: <8878B946-63D9-426E-B3E3-41A17369C47A@exscape.org> From: Thomas Backman To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 11:20:54 +0200 References: X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MdhLm-0008AS-3w. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MdhLm-0008AS-3w effabed8a3008e11d8119d2ae40c7723 Cc: Stefan Bethke , current@freebsd.org Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:21:15 -0000 On Aug 19, 2009, at 11:08, Danny Braniss wrote: > the plot thickens, compiling cddl/lib/libnvpair under 8-BETA2 works > ok, > so it seems that cross compiling (using a 7.2 system) causes the > problem, it > seems it's picking something from the local environment. > > any make expert in the house? > > danny I've been running 8-CURRENT (i.e. BETA2 now) all the time since May with the same problem starting 2 days ago as of today, so it can't be cross-compiling. However, Pawel says he's solved the issue and is waiting for re@ to approve the fix: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010753.html Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 10:08:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1F1106564A for ; Wed, 19 Aug 2009 10:08:02 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id BD68D8FC51 for ; Wed, 19 Aug 2009 10:08:01 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Mdi5H-000BG4-Bp; Wed, 19 Aug 2009 13:07:59 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Thomas Backman In-reply-to: Your message of Wed, 19 Aug 2009 11:20:54 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Aug 2009 13:07:59 +0300 From: Danny Braniss Message-ID: Cc: Stefan Bethke , current@freebsd.org Subject: Re: latest 8.0-BETA2 lost my zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 10:08:02 -0000 > I've been running 8-CURRENT (i.e. BETA2 now) all the time since May > with the same problem starting 2 days ago as of today, so it can't be > cross-compiling. > However, Pawel says he's solved the issue and is waiting for re@ to > approve the fix: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010753.html maybe there is more than one problem? In my case, compiling outside the src directory resulted in a working libnvpair - and yes, i also compiled it under 7.2 and it too worked! failes: zpool import works: env LD_LIBRARY_PATH=/myhomedir/cddl/lib/libnvpair zpool import go figure danny From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 08:25:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8AB1065698 for ; Wed, 19 Aug 2009 08:25:50 +0000 (UTC) (envelope-from denis@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 81A6C8FC61 for ; Wed, 19 Aug 2009 08:25:49 +0000 (UTC) Received: (qmail 54855 invoked from network); 19 Aug 2009 07:59:06 -0000 Received: from unknown (HELO ?10.1.2.230?) (denis@85.178.62.185) by mail.h3q.com with AES128-SHA encrypted SMTP; 19 Aug 2009 07:59:06 -0000 Message-Id: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> From: Denis Ahrens To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 09:59:05 +0200 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 19 Aug 2009 11:27:46 +0000 Subject: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 08:25:50 -0000 Hi After installing the latest CURRENT from today I see strange network problems. The problems are similar to http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html I see alot of this in the log: Aug 19 09:33:39 monolith kernel: IPv4 address: "213.191.89.1" is not on the network Aug 19 09:33:57 monolith last message repeated 22 times Aug 19 09:36:07 monolith last message repeated 6 times Aug 19 09:38:19 monolith last message repeated 15 times 213.191.89.1 is my ppp endpoint: tun0: flags=8051 metric 0 mtu 1492 inet 85.178.62.185 --> 213.191.89.1 netmask 0xffffffff Opened by PID 1351 When I try to ping the address the machine panics! (something with sin_family and in_lltable_lookup) http://denisy.dyndns.org/panic.jpg While restarting the ppp daemon I see this in the logs: Aug 19 09:33:33 monolith kernel: tun0: link state changed to UP Aug 19 09:33:38 monolith ppp[1351]: tun0: Warning: 0.0.0.0: Change route failed: errno: No such process I don't know if it is related at all. netstat -rn Internet: Destination Gateway Flags Refs Use Netif Expire default 213.191.89.1 UGS 0 12579 tun0 10.1.2.0/24 link#1 U 2 18778 re0 10.1.2.1 link#4 UHS 0 0 lo0 85.178.62.185 link#4 UHS 0 0 lo0 127.0.0.1 link#4 UH 0 87 lo0 213.191.89.1 link#5 UGHS 0 0 tun0 Denis From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 12:30:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7A97106568C; Wed, 19 Aug 2009 12:30:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7DE8FC43; Wed, 19 Aug 2009 12:30:32 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JCU0is001099; Wed, 19 Aug 2009 08:30:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JCU041001097; Wed, 19 Aug 2009 12:30:00 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 12:30:00 GMT Message-Id: <200908191230.n7JCU041001097@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 12:30:32 -0000 TB --- 2009-08-19 12:30:00 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 12:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-08-19 12:30:00 - mkdir /tinderbox/HEAD TB --- 2009-08-19 12:30:00 - ERROR: /tinderbox/HEAD/i386/pc98: File exists TB --- 2009-08-19 12:30:00 - 0.02 user 0.02 system 0.02 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 12:30:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8398106568D; Wed, 19 Aug 2009 12:30:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9348FC65; Wed, 19 Aug 2009 12:30:32 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JCU0Wp001098; Wed, 19 Aug 2009 08:30:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JCU0Vq001096; Wed, 19 Aug 2009 12:30:00 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 12:30:00 GMT Message-Id: <200908191230.n7JCU0Vq001096@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 12:30:33 -0000 TB --- 2009-08-19 12:30:00 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 12:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-19 12:30:00 - mkdir /tinderbox/HEAD TB --- 2009-08-19 12:30:00 - ERROR: /tinderbox/HEAD/arm/arm: File exists TB --- 2009-08-19 12:30:00 - 0.02 user 0.01 system 0.02 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 12:38:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1551065672; Wed, 19 Aug 2009 12:38:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6628FC43; Wed, 19 Aug 2009 12:38:55 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JCcNot001148; Wed, 19 Aug 2009 08:38:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JCcNjC001147; Wed, 19 Aug 2009 12:38:23 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 12:38:23 GMT Message-Id: <200908191238.n7JCcNjC001147@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 12:38:55 -0000 TB --- 2009-08-19 12:30:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 12:30:01 - starting HEAD tinderbox run for mips/mips TB --- 2009-08-19 12:30:01 - mkdir /tinderbox/HEAD/mips TB --- 2009-08-19 12:30:01 - mkdir /tinderbox/HEAD/mips/mips TB --- 2009-08-19 12:30:01 - cleaning the object tree TB --- 2009-08-19 12:30:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 12:30:01 - cd /tinderbox/HEAD/mips/mips TB --- 2009-08-19 12:30:01 - /usr/local/bin/svn checkout http://svn.freebsd.org/base//head /src TB --- 2009-08-19 12:38:20 - WARNING: /usr/local/bin/svn caught signal 10 TB --- 2009-08-19 12:38:20 - ERROR: unable to check out the source tree TB --- 2009-08-19 12:38:20 - 14.77 user 30.47 system 499.02 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 13:17:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A23E31065690 for ; Wed, 19 Aug 2009 13:17:01 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8D28FC55 for ; Wed, 19 Aug 2009 13:17:01 +0000 (UTC) Received: from baby-jane.lamaiziere.net (80.6.192-77.rev.gaoland.net [77.192.6.80]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 0AD7963352C for ; Wed, 19 Aug 2009 15:00:14 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id F0433B857 for ; Wed, 19 Aug 2009 15:00:46 +0200 (CEST) Date: Wed, 19 Aug 2009 15:00:45 +0200 From: Patrick Lamaiziere To: current@freebsd.org Message-ID: <20090819150045.0e01640a@baby-jane.lamaiziere.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: Subject: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 13:17:01 -0000 [8.0/i386 from today] Hello, =46rom time to time, I see this at boot-time on my laptop (a Macbook pro model 3,1). I'm not sure but it seems related if an USB device is plugged in one plug (strange because the internal keyboard and the touchpad are USB devices) (copied by hand) Table FACP at 0x7fefc000 Table HPET at 0x7fefb000 Table APIC at 0x7fefa000 MADT found table at 0x7fefa000 APIC: Using the MADT enumerator MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI: APIC Table AP #1 (PHY #1) failed! panic y/n? (cannot reply because I've got only an USB keyboard) Also, sometimes the box waits a long time (~20 seconds) at the step ACPI: APIC Table , but finally boots fine. Thanks, regards. From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 13:38:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7DFD106568C for ; Wed, 19 Aug 2009 13:38:21 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id B01288FC51 for ; Wed, 19 Aug 2009 13:38:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 8CEF46D423; Wed, 19 Aug 2009 15:21:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e39GEhLbUQ0w; Wed, 19 Aug 2009 15:21:20 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id E7E566D41E; Wed, 19 Aug 2009 15:21:20 +0200 (CEST) Date: Wed, 19 Aug 2009 15:21:20 +0200 From: Rink Springer To: Patrick Lamaiziere Message-ID: <20090819132120.GB4200@rink.nu> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090819150045.0e01640a@baby-jane.lamaiziere.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 13:38:22 -0000 Hi Patrick, On Wed, Aug 19, 2009 at 03:00:45PM +0200, Patrick Lamaiziere wrote: > AP #1 (PHY #1) failed! > panic y/n? > (cannot reply because I've got only an USB keyboard) I believe this is a quite long-standing problem due to a race in our SMP initialization code; it would happen on a Dual Xeon box since at least 5.0... Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:05:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA46106568B; Wed, 19 Aug 2009 14:05:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id CBDC98FC15; Wed, 19 Aug 2009 14:05:32 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JE51WI001147; Wed, 19 Aug 2009 10:05:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JE51Sw001145; Wed, 19 Aug 2009 14:05:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 14:05:01 GMT Message-Id: <200908191405.n7JE51Sw001145@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:05:33 -0000 TB --- 2009-08-19 14:05:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 14:05:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-08-19 14:05:01 - cleaning the object tree TB --- 2009-08-19 14:05:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 14:05:01 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2009-08-19 14:05:01 - /usr/local/bin/svn update /src TB --- 2009-08-19 14:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2009-08-19 14:05:01 - ERROR: unable to check out the source tree TB --- 2009-08-19 14:05:01 - 0.04 user 0.01 system 0.40 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:05:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E65F106568F; Wed, 19 Aug 2009 14:05:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id CF6228FC16; Wed, 19 Aug 2009 14:05:32 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JE51Sv001146; Wed, 19 Aug 2009 10:05:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JE51nI001144; Wed, 19 Aug 2009 14:05:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 14:05:01 GMT Message-Id: <200908191405.n7JE51nI001144@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:05:33 -0000 TB --- 2009-08-19 14:05:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 14:05:01 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-19 14:05:01 - cleaning the object tree TB --- 2009-08-19 14:05:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 14:05:01 - cd /tinderbox/HEAD/i386/i386 TB --- 2009-08-19 14:05:01 - /usr/local/bin/svn update /src TB --- 2009-08-19 14:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2009-08-19 14:05:01 - ERROR: unable to check out the source tree TB --- 2009-08-19 14:05:01 - 0.02 user 0.03 system 0.39 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:05:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A901065690; Wed, 19 Aug 2009 14:05:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id F3B258FC52; Wed, 19 Aug 2009 14:05:35 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JE51q6001162; Wed, 19 Aug 2009 10:05:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JE51hq001160; Wed, 19 Aug 2009 14:05:01 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 14:05:01 GMT Message-Id: <200908191405.n7JE51hq001160@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:05:36 -0000 TB --- 2009-08-19 14:05:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 14:05:01 - starting HEAD tinderbox run for mips/mips TB --- 2009-08-19 14:05:01 - cleaning the object tree TB --- 2009-08-19 14:05:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 14:05:01 - cd /tinderbox/HEAD/mips/mips TB --- 2009-08-19 14:05:01 - /usr/local/bin/svn update /src TB --- 2009-08-19 14:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2009-08-19 14:05:01 - ERROR: unable to check out the source tree TB --- 2009-08-19 14:05:01 - 0.03 user 0.01 system 0.03 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:05:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40AB9106564A; Wed, 19 Aug 2009 14:05:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD248FC57; Wed, 19 Aug 2009 14:05:37 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JE56qF001173; Wed, 19 Aug 2009 10:05:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JE56CV001161; Wed, 19 Aug 2009 14:05:06 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 14:05:06 GMT Message-Id: <200908191405.n7JE56CV001161@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:05:38 -0000 TB --- 2009-08-19 14:05:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 14:05:01 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-08-19 14:05:01 - cleaning the object tree TB --- 2009-08-19 14:05:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 14:05:01 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2009-08-19 14:05:01 - /usr/local/bin/svn update /src TB --- 2009-08-19 14:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2009-08-19 14:05:01 - ERROR: unable to check out the source tree TB --- 2009-08-19 14:05:01 - 0.02 user 0.01 system 0.07 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:05:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D2D81065672; Wed, 19 Aug 2009 14:05:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current2.sentex.ca (freebsd-current2.sentex.ca [64.7.128.100]) by mx1.freebsd.org (Postfix) with ESMTP id 39ACA8FC59; Wed, 19 Aug 2009 14:05:38 +0000 (UTC) Received: from freebsd-current2.sentex.ca (localhost [127.0.0.1]) by freebsd-current2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7JE579a001180; Wed, 19 Aug 2009 10:05:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current2.sentex.ca (8.14.3/8.14.3/Submit) id n7JE57ZB001169; Wed, 19 Aug 2009 14:05:07 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Aug 2009 14:05:07 GMT Message-Id: <200908191405.n7JE57ZB001169@freebsd-current2.sentex.ca> X-Authentication-Warning: freebsd-current2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:05:38 -0000 TB --- 2009-08-19 14:05:01 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 14:05:01 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-08-19 14:05:01 - cleaning the object tree TB --- 2009-08-19 14:05:01 - checking out /src from http://svn.freebsd.org/base/ TB --- 2009-08-19 14:05:01 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2009-08-19 14:05:02 - /usr/local/bin/svn update /src TB --- 2009-08-19 14:05:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2009-08-19 14:05:02 - ERROR: unable to check out the source tree TB --- 2009-08-19 14:05:02 - 0.03 user 0.01 system 0.06 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:18:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951FA106568C for ; Wed, 19 Aug 2009 14:18:16 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 38CFA8FC66 for ; Wed, 19 Aug 2009 14:18:16 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9E5D61CD18; Wed, 19 Aug 2009 16:18:15 +0200 (CEST) Date: Wed, 19 Aug 2009 16:18:15 +0200 From: Ed Schouten To: Patrick Lamaiziere Message-ID: <20090819141815.GU1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D3uGefx/nfj0hkMF" Content-Disposition: inline In-Reply-To: <20090819150045.0e01640a@baby-jane.lamaiziere.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:18:16 -0000 --D3uGefx/nfj0hkMF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Patrick Lamaiziere wrote: > From time to time, I see this at boot-time on my laptop (a Macbook > pro model 3,1). I'm not sure but it seems related if an USB device is > plugged in one plug (strange because the internal keyboard and the > touchpad are USB devices) So what does smbios.system.product say? (Escape to the loader prompt and run `show' or whatever it's called) I'll have to re-add this device string to machdep.c to make it work again. --=20 Ed Schouten WWW: http://80386.nl/ --D3uGefx/nfj0hkMF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqMCacACgkQ52SDGA2eCwXTCgCeI4ubeR4KQ58RNi6ZEYLKM/uv wt8An0IBhZGrYIVtghUNA0P6W9yGJTy4 =E07c -----END PGP SIGNATURE----- --D3uGefx/nfj0hkMF-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:41:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9C6106568B for ; Wed, 19 Aug 2009 14:41:37 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 906428FC5B for ; Wed, 19 Aug 2009 14:41:37 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7B2511CD3E; Wed, 19 Aug 2009 16:41:36 +0200 (CEST) Date: Wed, 19 Aug 2009 16:41:36 +0200 From: Ed Schouten To: pluknet Message-ID: <20090819144136.GV1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wXrNoiI3xS2qTXng" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:41:37 -0000 --wXrNoiI3xS2qTXng Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * pluknet wrote: > I'm not Patrik, but I saw this on two Intel boxes running on 6.2. > smbios.system.product=3D"S5000PAL". I didn't try the later releases on t= hem. I wouldn't mind adding non-Apple hardware to this list, but only if you can tell me the following: - Is this piece of hardware capable of running FreeBSD/amd64? If not, then it doesn't make sense to add it to sys/amd64/amd64/machdep.c. - Can you try latest HEAD on this system and test whether adding this string has any influence? --=20 Ed Schouten WWW: http://80386.nl/ --wXrNoiI3xS2qTXng Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqMDyAACgkQ52SDGA2eCwXbegCeN7tLbwrL5C61Rk9qw+GfmPzH tOUAn0z8uM++060S/MlOKtWLDnwMoqSS =hhd5 -----END PGP SIGNATURE----- --wXrNoiI3xS2qTXng-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 14:55:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A51C106568B for ; Wed, 19 Aug 2009 14:55:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 865168FC52 for ; Wed, 19 Aug 2009 14:55:41 +0000 (UTC) Received: by bwz2 with SMTP id 2so3510482bwz.43 for ; Wed, 19 Aug 2009 07:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=85OpEdcKz2jQHZyR2uY/jEey/nmbXqWVN38a+XZ1yG4=; b=ALwFWxH9femVHRlW3egwjJIWHzwvHzflWCf/TwrsXWlBB2B/77cxZ7vgaYJvxUfdVG ADLRIenn7Mq+F1v5uum72GFKdAPFcBzqH8nNHwpPswQTkeVcE98C+QX7PDRcZ8DSV5gy uIJTB3gJqt1B7cYAkiiW5jJdIK0MHa+L+i9Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C8GKJyd8WMYLkZwcHfRc2wv3RL7O2Tu9zqQIkt7K9nQSxoMlFFy2bFgh2oNhKB/FuM sbV/YsHJnWbhBosXzoX+SgCBl1isM74J3blvlKiOU3zG6F4MPnwWj6+Tye0JE+qSCEXe ZGterUmE3s6ZeoBKIqwBXXfjy29UFrI7eAzZ4= MIME-Version: 1.0 Received: by 10.204.160.80 with SMTP id m16mr5036210bkx.138.1250693739857; Wed, 19 Aug 2009 07:55:39 -0700 (PDT) In-Reply-To: <20090819144136.GV1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819144136.GV1292@hoeg.nl> Date: Wed, 19 Aug 2009 18:55:39 +0400 Message-ID: From: pluknet To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:55:42 -0000 2009/8/19 Ed Schouten : > * pluknet wrote: >> I'm not Patrik, but I saw this on two Intel boxes running on 6.2. >> =A0smbios.system.product=3D"S5000PAL". I didn't try the later releases o= n them. > > I wouldn't mind adding non-Apple hardware to this list, but only if you > can tell me the following: > > - Is this piece of hardware capable of running FreeBSD/amd64? It seems so. This is a system with two Xeon 5130 populated. AMD Features=3D0x20000000 AP #3 (PHY# 7) failed! panic y/n? [y] panic: bye-bye cpuid =3D 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop db> x/s *panicstr buf.1: bye-bye db> bt Tracing pid 0 tid 0 td 0xc0a04d40 kdb_enter(c0924c08) at kdb_enter+0x2b panic(c09431b0,c0c26000,a,9,3,...) at panic+0x127 start_all_aps(10,c0c20d44,c0c20d5c,c067a5ba,c0a113c0,...) at start_all_aps+= 0x243 cpu_mp_start(c0a113c0,c0926d2b,0,1,c0c20d88,...) at cpu_mp_start+0x10c mp_start(0,c1ec00,c1e000,0,c044f3f5,...) at mp_start+0x47 mi_startup() at mi_startup+0x96 begin() at begin+0x2c > - Can you try latest HEAD on this system and test whether adding this > =A0string has any influence? This issue is repeated on boot rather seldom, one per dozen or so. I'll try anyway. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 15:02:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8D1106568F for ; Wed, 19 Aug 2009 15:02:56 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id B10A68FC55 for ; Wed, 19 Aug 2009 15:02:55 +0000 (UTC) Received: by fxm6 with SMTP id 6so3483956fxm.43 for ; Wed, 19 Aug 2009 08:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UiBJaUsnvM54TykVreZdeDEIs94i+eCTdKAqhanXvw0=; b=H6miwphldrNboCxh0sZsDtOfWXtnTITwqyTSyoJKlnoLJP1SnJs8lCAvdlx05m3hir 6zaLTVIHnCfC3GVVm+aP/X8Rb3m152wtCtFYWm1xDAY4cWtTlhfSSBknHjaTJ0GETHD5 tkP/qJHCn4NMc8+g8XcBys7fsqEW8AEvH17Zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZbX19yAU+3pjCxGqJZPzt3WGAKxTSwlhzPC8aJVOl9/dhGEwYqLGszFySLu0GV+W+l K0AMRP3beOgnNsW0KkxD3KgH9mI+H192LNvBy/56ofZSk+2Z73k0krspb9y4nMUvhQc9 MqSCUCzQ8PGvx+KjehUM6Xd6v/3qsNIUfR6qI= MIME-Version: 1.0 Received: by 10.204.11.23 with SMTP id r23mr4998244bkr.158.1250692641169; Wed, 19 Aug 2009 07:37:21 -0700 (PDT) In-Reply-To: <20090819141815.GU1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> Date: Wed, 19 Aug 2009 18:37:21 +0400 Message-ID: From: pluknet To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:02:56 -0000 2009/8/19 Ed Schouten : > * Patrick Lamaiziere wrote: >> From time to time, I see this at boot-time on my laptop (a Macbook >> pro model 3,1). I'm not sure but it seems related if an USB device is >> plugged in one plug (strange because the internal keyboard and the >> touchpad are USB devices) > > So what does smbios.system.product say? (Escape to the loader prompt and > run `show' or whatever it's called) I'm not Patrik, but I saw this on two Intel boxes running on 6.2. smbios.system.product="S5000PAL". I didn't try the later releases on them. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 15:07:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A6B106568B for ; Wed, 19 Aug 2009 15:07:33 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id D1C688FC5B for ; Wed, 19 Aug 2009 15:07:32 +0000 (UTC) Received: from baby-jane.lamaiziere.net (80.6.192-77.rev.gaoland.net [77.192.6.80]) by smtp.lamaiziere.net (Postfix) with ESMTPA id EE49A63352C; Wed, 19 Aug 2009 17:07:31 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 9B892B855; Wed, 19 Aug 2009 17:08:04 +0200 (CEST) Date: Wed, 19 Aug 2009 17:08:03 +0200 From: Patrick Lamaiziere To: Ed Schouten Message-ID: <20090819170803.355e1857@baby-jane.lamaiziere.net> In-Reply-To: <20090819141815.GU1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:07:33 -0000 Le Wed, 19 Aug 2009 16:18:15 +0200, Ed Schouten a =E9crit : > * Patrick Lamaiziere wrote: > > From time to time, I see this at boot-time on my laptop (a Macbook > > pro model 3,1). I'm not sure but it seems related if an USB device > > is plugged in one plug (strange because the internal keyboard and > > the touchpad are USB devices) >=20 > So what does smbios.system.product say? (Escape to the loader prompt > and run `show' or whatever it's called) MacBookPro3,1 with dmidecode: Handle 0x0011, DMI type 1, 27 bytes System Information =20 Manufacturer: Apple Inc. =20 Product Name: MacBookPro3,1 Version: 1.0 =20 Serial Number: W88080NBXAH=20 UUID: 9CFE245E-D0C8-BD45-A79F-54EA5FBD3D97 Wake-up Type: Power Switch =20 SKU Number: System SKU# =20 Family: MacBook Pro =20 =20 > I'll have to re-add this device string to machdep.c to make it work > again. Thanks, the problem is quite reproductible here, so I can test anything and any idea if it can help. Regards. From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 15:10:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79CAD10656C4 for ; Wed, 19 Aug 2009 15:10:22 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 400428FC6B for ; Wed, 19 Aug 2009 15:10:22 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A5D491CD18; Wed, 19 Aug 2009 17:10:21 +0200 (CEST) Date: Wed, 19 Aug 2009 17:10:21 +0200 From: Ed Schouten To: Patrick Lamaiziere Message-ID: <20090819151021.GW1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819170803.355e1857@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kprVLFHawVuICufS" Content-Disposition: inline In-Reply-To: <20090819170803.355e1857@baby-jane.lamaiziere.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:10:22 -0000 --kprVLFHawVuICufS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Patrick Lamaiziere wrote: > Thanks, the problem is quite reproductible here, so I can test anything > and any idea if it can help. Can you try this patch, then? ;-) Index: sys/i386/i386/machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/i386/i386/machdep.c (revision 196377) +++ sys/i386/i386/machdep.c (working copy) @@ -261,6 +261,7 @@ strncmp(sysenv, "MacBook3,1", 10) =3D=3D 0 || strncmp(sysenv, "MacBookPro1,1", 13) =3D=3D 0 || strncmp(sysenv, "MacBookPro1,2", 13) =3D=3D 0 || + strncmp(sysenv, "MacBookPro3,1", 13) =3D=3D 0 || strncmp(sysenv, "Macmini1,1", 10) =3D=3D 0) { if (bootverbose) printf("Disabling LEGACY_USB_EN bit on " Index: sys/amd64/amd64/machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/amd64/amd64/machdep.c (revision 196377) +++ sys/amd64/amd64/machdep.c (working copy) @@ -217,6 +217,7 @@ strncmp(sysenv, "MacBook3,1", 10) =3D=3D 0 || strncmp(sysenv, "MacBookPro1,1", 13) =3D=3D 0 || strncmp(sysenv, "MacBookPro1,2", 13) =3D=3D 0 || + strncmp(sysenv, "MacBookPro3,1", 13) =3D=3D 0 || strncmp(sysenv, "Macmini1,1", 10) =3D=3D 0) { if (bootverbose) printf("Disabling LEGACY_USB_EN bit on " --=20 Ed Schouten WWW: http://80386.nl/ --kprVLFHawVuICufS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqMFd0ACgkQ52SDGA2eCwUBHACeOnAomo/3eImlfEuCvNrd6sax 9YQAn1auoSXPyfm1mH5tHLpu2foCMWNL =Hnu2 -----END PGP SIGNATURE----- --kprVLFHawVuICufS-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 16:14:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1E3106568C for ; Wed, 19 Aug 2009 16:14:34 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by mx1.freebsd.org (Postfix) with ESMTP id AFDD98FC43 for ; Wed, 19 Aug 2009 16:14:33 +0000 (UTC) Received: by ywh37 with SMTP id 37so6397955ywh.28 for ; Wed, 19 Aug 2009 09:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=MrCIFBnP1TFefCOEqFzGrv3gNeY0H7FH0kfz1VGEAEM=; b=klAd+BIkTYeNuXgQD7AoiUs5QGGg9FA0gTqL3ovNgTHFY8AMZFdfXzVe13bKfFw4zB cIL/t2GPqWqFBfL1ZcPGrcV2TDbLPSrIOs39SnvtiIfdqvxqZ0w4fJxkfX1jBV9Ag4ZP srCpbAeEJ8AlPfkdQUg1n6/poXjfKiRlU0fcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=uHCeZRUOtBgBo0CjTM37kaZA8zjnIiu2ta9+tHtjvXB2ui/v0YJLDfXWx46t3dmVZj wUC2PzuFhJQnsYya75p3Dv0RRLlBT8iGGCmZkEVGqDcmbw1HaGW8/BanfrSbkYt6gVDe j+6rb7d/D1NLe7eXrz8Z58KH4VdjyS2qmBTQ0= Received: by 10.90.205.4 with SMTP id c4mr4948543agg.29.1250696801604; Wed, 19 Aug 2009 08:46:41 -0700 (PDT) Received: from adnote989 (201-26-3-225.dsl.telesp.net.br [201.26.3.225]) by mx.google.com with ESMTPS id 29sm227862agd.15.2009.08.19.08.46.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Aug 2009 08:46:40 -0700 (PDT) Message-ID: <3CFBFE5595F643CDB6F4C004C09788A0@adnote989> From: "Luiz Otavio O Souza" To: "Denis Ahrens" , References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> Date: Wed, 19 Aug 2009 12:46:09 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 16:14:34 -0000 Hi Denis, > Hi > > After installing the latest CURRENT from today I see strange network > problems. > > The problems are similar to > http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html I think the problem is not the same, if you look at that thread you will see the Qing answer pointing to the wrong routing table setup, which is not our case. > > I see alot of this in the log: > > Aug 19 09:33:39 monolith kernel: IPv4 address: "213.191.89.1" is not on > the network > Aug 19 09:33:57 monolith last message repeated 22 times > Aug 19 09:36:07 monolith last message repeated 6 times > Aug 19 09:38:19 monolith last message repeated 15 times I'm also seeing this after the update today... but my dsl is working fine (while i'm seeing the same message on syslog) and no crashes so far. > > 213.191.89.1 is my ppp endpoint: > > tun0: flags=8051 metric 0 mtu 1492 > inet 85.178.62.185 --> 213.191.89.1 netmask 0xffffffff > Opened by PID 1351 > > When I try to ping the address the machine panics! > (something with sin_family and in_lltable_lookup) > http://denisy.dyndns.org/panic.jpg Can you reproduce this ? Can you tell us how to reproduce this ? > > While restarting the ppp daemon I see this in the logs: > > Aug 19 09:33:33 monolith kernel: tun0: link state changed to UP > Aug 19 09:33:38 monolith ppp[1351]: tun0: Warning: 0.0.0.0: Change route > failed: errno: No such process > > I don't know if it is related at all. This is probably unrelated... i've seen this before without any further harm. > > netstat -rn > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 213.191.89.1 UGS 0 12579 tun0 > 10.1.2.0/24 link#1 U 2 18778 re0 > 10.1.2.1 link#4 UHS 0 0 lo0 > 85.178.62.185 link#4 UHS 0 0 lo0 > 127.0.0.1 link#4 UH 0 87 lo0 > 213.191.89.1 link#5 UGHS 0 0 tun0 > > Denis exactly like mine: Destination Gateway Flags Refs Use Netif Expire default 200.204.210.242 UGS 0 6688 tun0 127.0.0.1 link#4 UH 0 0 lo0 192.168.0.0/24 link#1 U 1 2710 rl0 192.168.0.1 link#4 UHS 0 78730 lo0 200.204.210.242 link#5 UGHS 0 0 tun0 201.26.3.225 link#4 UHS 0 0 lo0 Aug 19 12:32:44 server kernel: IPv4 address: "200.204.210.242" is not on the network Aug 19 12:33:15 server last message repeated 67 times Aug 19 12:35:16 server last message repeated 291 times Aug 19 12:35:33 server last message repeated 41 times Luiz From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 16:45:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02DC5106568B for ; Wed, 19 Aug 2009 16:45:01 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 585F78FC5B for ; Wed, 19 Aug 2009 16:45:00 +0000 (UTC) Received: (qmail 3809 invoked from network); 19 Aug 2009 11:18:17 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 19 Aug 2009 11:18:17 -0500 Received: (qmail 89831 invoked by uid 2001); 19 Aug 2009 16:18:17 -0000 Date: Wed, 19 Aug 2009 11:18:17 -0500 From: "Rick C. Petty" To: current@freebsd.org Message-ID: <20090819161817.GA89704@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 16:45:01 -0000 Upon every restart, I see a few LORs. I couldn't find PRs for any of them. See attached dmesg below. Should I submit a PR for each of them or one PR for all five? % uname -a FreeBSD myhost 8.0-BETA2 FreeBSD 8.0-BETA2 #4 r196381M: Wed Aug 19 10:06:03 CDT 2009 root@myhost:/usr/obj/usr/src/sys/GENERIC amd64 % cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1a / ufs rw 1 1 /dev/ad4s2 none swap sw 0 0 /dev/ad4s1d /usr ufs rw,noatime 2 2 /dev/ad4s1e /cache ufs rw 2 2 fs:/home /home nfs rw,soft,intr,bg,rdirplus //rick@fs/sw /sw smbfs rw,-N,-f=0664,-d=0775 fs:/sw/bsd/ports/7 /usr/ports nfs ro,soft,intr,bg devfs /dev devfs rw linprocfs /compat/linux/proc linprocfs rw I'm willing to test any patches. Thanks in advance, -- Rick C. Petty ~~~ dmesg -a ~~~ Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA2 #4 r196381M: Wed Aug 19 10:06:03 CDT 2009 root@myhost:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. module_register: module uhub/ums already exists! Module uhub/ums failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9600 Quad-Core Processor (2300.02-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f22 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8253128704 (7870 MB) ACPI APIC Table: <070208 APIC1604> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <070208 RSDT1604> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x900-0x9ff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) ohci0: mem 0xfe97e000-0xfe97efff irq 22 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe97fc00-0xfe97fcff irq 23 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 ohci1: mem 0xfe97d000-0xfe97dfff irq 20 at device 4.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0xfe97f800-0xfe97f8ff irq 21 at device 4.1 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] hdac0: mem 0xfe978000-0xfe97bfff irq 22 at device 7.0 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib1: at device 8.0 on pci0 pci1: on pcib1 ahc0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 18 at device 6.0 on pci1 ahc0: [ITHREAD] aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs ahc1: port 0xd400-0xd4ff mem 0xfeafe000-0xfeafefff irq 19 at device 7.0 on pci1 ahc1: [ITHREAD] aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs atapci1: port 0xc480-0xc487,0xc400-0xc403,0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc0f mem 0xfe976000-0xfe977fff irq 23 at device 9.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] nfe0: port 0xb880-0xb887 mem 0xfe97c000-0xfe97cfff,0xfe97f400-0xfe97f4ff,0xfe97f000-0xfe97f00f irq 20 at device 10.0 on pci0 miibus0: on nfe0 rgephy0: PHY 3 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:22:15:b4:2d:c8 nfe0: [FILTER] pcib2: irq 16 at device 16.0 on pci0 pci2: on pcib2 vgapci0: port 0xe800-0xe8ff mem 0xd0000000-0xdfffffff,0xfebe0000-0xfebeffff irq 16 at device 0.0 on pci2 hdac1: mem 0xfebfc000-0xfebfffff irq 17 at device 0.1 on pci2 hdac1: HDA Driver Revision: 20090624_0136 hdac1: [ITHREAD] pcib3: irq 17 at device 18.0 on pci0 pci3: on pcib3 acpi_button0: on acpi0 ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] atrtc1: port 0x70-0x71 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd07ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad4: 305245MB at ata2-master UDMA33 ad5: 305245MB at ata2-slave UDMA33 acd0: DVDR at ata3-master UDMA33 hdac0: HDA Codec #0: VIA VT1708B_1 hdac0: HDA Codec #3: NVidia MCP78 HDMI hdac0: No jack detection support at pin 29 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 3 nid 1 on hdac0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 6 ports with 6 removable, self powered ugen1.1: at usbus1 uhub1: on usbus1 uhub1: 6 ports with 6 removable, self powered ugen2.1: at usbus2 uhub2: on usbus2 uhub2: 6 ports with 6 removable, self powered ugen3.1: at usbus3 uhub3: on usbus3 uhub3: 6 ports with 6 removable, self powered hdac1: HDA Codec #0: ATI R6xx HDMI pcm3: at cad 0 nid 1 on hdac1 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus3 Root mount waiting for: usbus3 Trying to mount root from ufs:/dev/ad4s1a ugen2.2: at usbus2 ulpt0: on usbus2 ulpt0: using bi-directional mode Entropy harvesting: interrupts ethernet point_to_point kickstart . /dev/ad4s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s1a: clean, 245826 free (2202 frags, 30453 blocks, 0.4% fragmentation) /dev/ad4s1d: DEFER FOR BACKGROUND CHECKING ugen2.3: at usbus2 ums0: on usbus2 /dev/ad4s1e: DEFER FOR BACKGROUND CHECKING ums0: 3 buttons and [XYZ] coordinates ID=0 lock order reversal: 1st 0xffffff0002e48620 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 2nd 0xffffff0002e48d80 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x100 devfs_root() at devfs_root+0x48 vflush() at vflush+0x4c devfs_unmount() at devfs_unmount+0x46 dounmount() at dounmount+0x2e6 unmount() at unmount+0x27e syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a09ec, rsp = 0x7fffffffe248, rbp = 0 --- WARNING: /usr was not properly dismounted WARNING: /cache was not properly dismounted ugen2.4: at usbus2 uhid0: on usbus2 Starting Network: lo0 nfe0. add net default: gateway 172.23.20.1 Additional routing options: broadcast ping responses=YES . Mounting NFS file systems: . Mounting SMB file systems: netsmb_dev: loaded . Additional ABI support: linux . Setting date via ntp. 19 Aug 10:32:44 ntpdate[594]: step time server 75.140.36.90 offset 0.676700 sec lock order reversal: 1st 0xffffff80a51147e8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffff000439b400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_mkdir() at ufs_mkdir+0x623 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x270 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800729dbc, rsp = 0x7fffffffec88, rbp = 0x7fffffffef66 --- Configuring syscons: keymap keyrate . /etc/rc.d/sysctl: WARNING: sysctl net.link.tap.user_open does not exist. Wed Aug 19 10:32:47 CDT 2009 lock order reversal: 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:4097 2nd 0xffffff80a5129968 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:1835 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:161 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 nfs_nget() at nfs_nget+0x1c9 nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc nfs_doio() at nfs_doio+0x617 nfs_bioread() at nfs_bioread+0xa9f nfs_readdir() at nfs_readdir+0x85 kern_getdirentries() at kern_getdirentries+0x12e getdirentries() at getdirentries+0x23 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8009d11dc, rsp = 0x7fffffffc3a8, rbp = 0x1 --- drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV620 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] lock order reversal: 1st 0xffffff000412b270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 2nd 0xffffff00043e6098 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_msync() at vfs_msync+0xa3 sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80e7b74d30, rbp = 0 --- Aug 19 10:34:10 myhost kernel: NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 NLM: failed to contact remote rpcbind, stat = 0, port = 0 acquiring duplicate lock of same type: "ftlk" 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x8ef _sx_xlock() at _sx_xlock+0x55 futex_get0() at futex_get0+0xfe linux_sys_futex() at linux_sys_futex+0x96 ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28799533, rsp = 0xffffaecc, rbp = 0x4000001 --- NLM: failed to contact remote rpcbind, stat = 0, port = 0 Aug 19 10:34:46 myhost last message repeated 18 times NLM: failed to contact remote rpcbind, stat = 0, port = 0 Aug 19 10:34:50 myhost kernel: NLM: failed to contact remote rpcbind, stat = 0, port = 0 From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 16:51:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1D21065696 for ; Wed, 19 Aug 2009 16:51:09 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A44EF8FC43 for ; Wed, 19 Aug 2009 16:51:09 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7JGp8Y9024066; Wed, 19 Aug 2009 09:51:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 09:50:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: network problems Thread-Index: AcogwCZMOPzTie0KQdef4pCG9rleQQAKgDYN References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> From: "Li, Qing" To: "Denis Ahrens" , Cc: Subject: RE: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 16:51:09 -0000 > > The problems are similar to = http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.htm= l > That was a configuration issue. >=20 > When I try to ping the address the machine panics! > (something with sin_family and in_lltable_lookup) > http://denisy.dyndns.org/panic.jpg > After a quick cursory read over the code, this issue appears to be a = problem=20 in the flow-table handling logic in ip_output() function. Two problems seem to exist in the flow-table logic. 1. In flowtable_lookup() where it searches for the destination in the=20 routing table, the code does not check for the rt_ifp type once a route entry is found. In the case of "if_tun", the flow-table=20 must not try to cache any entry whose "rt_ifp->if_flag & = IFF_POINTOPOINT" is true. Right now it does, and I think this will trigger the crash later. 2. The flowtable_lookup() seems to alway assume a valid entry=20 will be returned as long as a route entry exists for the destination. In other words, if a route exists for the destination, then either flow-table already have a cache, or a new entry is created. This does not work due to (1.) above.=20 flowtable_lookup() should allow a "bypass flow-table" return, not=20 just success/failure result. This is especially true for tunneling interfaces "if_tun, if_gre" etc. where ip_output() will be called multiple times (nested). Only at the final = invocation of ip_output() (where the rt->rt_ifp points to a physical NIC) should a flow-table entry be created. So for now, as a possible temporary workaround, disable FLOWTABLE in = your kernel configuration file and see if that fixes the problem. -- Qing From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:00:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB7901065717 for ; Wed, 19 Aug 2009 17:00:47 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id B14548FC61 for ; Wed, 19 Aug 2009 17:00:47 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 6966D8512; Wed, 19 Aug 2009 17:00:46 +0000 (UTC) Date: Wed, 19 Aug 2009 18:00:31 +0100 From: Bruce Cran To: rick-freebsd2008@kiwi-computer.com Message-ID: <20090819180031.2182de8c@gluon.draftnet> In-Reply-To: <20090819161817.GA89704@keira.kiwi-computer.com> References: <20090819161817.GA89704@keira.kiwi-computer.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:00:47 -0000 On Wed, 19 Aug 2009 11:18:17 -0500 "Rick C. Petty" wrote: > Upon every restart, I see a few LORs. I couldn't find PRs for any of > them. See attached dmesg below. Should I submit a PR for each of > them or one PR for all five? You should check http://sources.zabbadoz.net/freebsd/lor.html first before submitting PRs, to see if they're known. I've been seeing quite a few LORs recently too, but the only one I've seen on my system that can't see on that page is between bufwait (vfs_bio.c) and proctree (subr_prf.c). -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:16:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87CA810656A4 for ; Wed, 19 Aug 2009 17:16:44 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 45C8F8FC57 for ; Wed, 19 Aug 2009 17:16:44 +0000 (UTC) Received: from baby-jane.lamaiziere.net (80.6.192-77.rev.gaoland.net [77.192.6.80]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 3090D63352C; Wed, 19 Aug 2009 19:16:43 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 69767B857; Wed, 19 Aug 2009 19:17:15 +0200 (CEST) Date: Wed, 19 Aug 2009 19:17:14 +0200 From: Patrick Lamaiziere To: pluknet Message-ID: <20090819191714.0c95cea7@baby-jane.lamaiziere.net> In-Reply-To: References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819144136.GV1292@hoeg.nl> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:16:44 -0000 Le Wed, 19 Aug 2009 18:55:39 +0400, pluknet a =E9crit : > 2009/8/19 Ed Schouten : > > * pluknet wrote: > >> I'm not Patrik, but I saw this on two Intel boxes running on 6.2. > >> =A0smbios.system.product=3D"S5000PAL". I didn't try the later releases > >> on them. > > > > I wouldn't mind adding non-Apple hardware to this list, but only if > > you can tell me the following: > > > > - Is this piece of hardware capable of running FreeBSD/amd64? >=20 > It seems so. This is a system with two Xeon 5130 populated. > AMD Features=3D0x20000000 The work-around sent by Ed is only for the chipset Intel ICH (Intel 82801H here), it disables the SMI on the legacy USB circuit. Are you using such chipset? From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:19:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B029106568D for ; Wed, 19 Aug 2009 17:19:36 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4B04B8FC61 for ; Wed, 19 Aug 2009 17:19:36 +0000 (UTC) Received: from baby-jane.lamaiziere.net (80.6.192-77.rev.gaoland.net [77.192.6.80]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 5915F63352C; Wed, 19 Aug 2009 19:19:35 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 976FBB857; Wed, 19 Aug 2009 19:20:07 +0200 (CEST) Date: Wed, 19 Aug 2009 19:20:07 +0200 From: Patrick Lamaiziere To: Ed Schouten Message-ID: <20090819192007.0e1c6a12@baby-jane.lamaiziere.net> In-Reply-To: <20090819151021.GW1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819170803.355e1857@baby-jane.lamaiziere.net> <20090819151021.GW1292@hoeg.nl> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:19:36 -0000 Le Wed, 19 Aug 2009 17:10:21 +0200, Ed Schouten a =E9crit : > * Patrick Lamaiziere wrote: > > Thanks, the problem is quite reproductible here, so I can test > > anything and any idea if it can help. >=20 > Can you try this patch, then? ;-) It works for me on i386. Thanks a lot. From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:04:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5F1106568B for ; Wed, 19 Aug 2009 17:04:05 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0948FC64 for ; Wed, 19 Aug 2009 17:04:04 +0000 (UTC) Received: by ywh37 with SMTP id 37so6445623ywh.28 for ; Wed, 19 Aug 2009 10:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=I5G1Aoh2kUT40s1vvNSICTF/MDpt4jPwlf4ZRcJHPiU=; b=JwyG/z3UD/zl/mXW1ascihXGwheqtRzCuku/Ssrk5PhgOb85G5GAAN0BCr2gJOhyqp //+MmfOrrruro1D4Rct5bzSWrxV+z1PBm0Wn4rU/KFUgpgquQ+86DC6YMV7QMmn/mMQc sstjdQcy97nt7V7WNSs7QUNtb6nuPLR+jvFkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=QgQZfZXxJRnum7+3/dMsSyit/Sav1bNkOUVVd3Rjb6Wkgtx6RcxJ7IzekdSa9mfhic GK4ys5BtByi5gRB9JX5mqejNIQ1K7GILpD7dpnZqpxda0p22ZnRlZAPjUAsSh759k/Jh bFDnigCEu5+dbe6mAke/+5DuTz4L/V4oXCXVE= Received: by 10.91.135.13 with SMTP id m13mr5018172agn.25.1250701444084; Wed, 19 Aug 2009 10:04:04 -0700 (PDT) Received: from adnote989 (201-42-159-160.dsl.telesp.net.br [201.42.159.160]) by mx.google.com with ESMTPS id 6sm3762646agb.28.2009.08.19.10.03.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Aug 2009 10:04:03 -0700 (PDT) Message-ID: <35FF00562E814F08BE71B6407FB6C1BF@adnote989> From: "Luiz Otavio O Souza" To: "Li, Qing" , "Denis Ahrens" , References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> Date: Wed, 19 Aug 2009 14:03:28 -0300 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 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Wed, 19 Aug 2009 17:23:01 +0000 Cc: Subject: Re: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:04:05 -0000 >> >> The problems are similar to >> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html >> > > That was a configuration issue. > >> >> When I try to ping the address the machine panics! >> (something with sin_family and in_lltable_lookup) >> http://denisy.dyndns.org/panic.jpg >> > > After a quick cursory read over the code, this issue appears to be a > problem > in the flow-table handling logic in ip_output() function. > > Two problems seem to exist in the flow-table logic. > > 1. In flowtable_lookup() where it searches for the destination in the > routing table, the code does not check for the rt_ifp type once a > route entry is found. In the case of "if_tun", the flow-table > must not try to cache any entry whose "rt_ifp->if_flag & > IFF_POINTOPOINT" > is true. Right now it does, and I think this will trigger the crash > later. > > 2. The flowtable_lookup() seems to alway assume a valid entry > will be returned as long as a route entry exists for the > destination. In other words, if a route exists for the destination, > then either flow-table already have a cache, or a new entry > is created. This does not work due to (1.) above. > flowtable_lookup() should allow a "bypass flow-table" return, not > just success/failure result. This is especially true for > tunneling interfaces "if_tun, if_gre" etc. where ip_output() > will be called multiple times (nested). Only at the final invocation > of ip_output() (where the rt->rt_ifp points to a physical NIC) > should a flow-table entry be created. > > So for now, as a possible temporary workaround, disable FLOWTABLE in your > kernel configuration file and see if that fixes the problem. > > -- Qing Qing, yes, disabling the flowtable (sysctl net.inet.flowtable.enable=0) fix the problem (no more IPv4 is not on the network). But here, everything is working fine, even with that annoying message (no crashes). Thanks, Luiz From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:50:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F86B106568B for ; Wed, 19 Aug 2009 17:50:31 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id B5F178FC6D for ; Wed, 19 Aug 2009 17:50:30 +0000 (UTC) Received: (qmail 30617 invoked from network); 19 Aug 2009 12:50:29 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 19 Aug 2009 12:50:29 -0500 Received: (qmail 90550 invoked by uid 2001); 19 Aug 2009 17:50:29 -0000 Date: Wed, 19 Aug 2009 12:50:29 -0500 From: "Rick C. Petty" To: current@freebsd.org Message-ID: <20090819175029.GA90205@keira.kiwi-computer.com> References: <20090819161817.GA89704@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090819161817.GA89704@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.3i Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: Re: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:50:31 -0000 On Wed, Aug 19, 2009 at 06:00:31PM +0100, Bruce Cran wrote: > On Wed, Aug 19, 2009 at 11:18:17AM -0500, Rick C. Petty wrote: > > > Upon every restart, I see a few LORs. I couldn't find PRs for any of them. > > See attached dmesg below. Should I submit a PR for each of them or one PR > > for all five? > > You should check http://sources.zabbadoz.net/freebsd/lor.html first > before submitting PRs, to see if they're known. Thanks, I'll update my post accordingly... > % uname -a > FreeBSD myhost 8.0-BETA2 FreeBSD 8.0-BETA2 #4 r196381M: Wed Aug 19 10:06:03 CDT 2009 root@myhost:/usr/obj/usr/src/sys/GENERIC amd64 This is LOR #280 with slightly different line numbers and backtrace: > lock order reversal: > 1st 0xffffff0002e48620 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 > 2nd 0xffffff0002e48d80 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > devfs_allocv() at devfs_allocv+0x100 > devfs_root() at devfs_root+0x48 > vflush() at vflush+0x4c > devfs_unmount() at devfs_unmount+0x46 > dounmount() at dounmount+0x2e6 > unmount() at unmount+0x27e > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a09ec, rsp = 0x7fffffffe248, rbp = 0 --- LOR #261 was already reported: > lock order reversal: > 1st 0xffffff80a51147e8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 > 2nd 0xffffff000439b400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 This LOR doesn't seem to be reported anywhere: > lock order reversal: > 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:4097 > 2nd 0xffffff80a5129968 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:1835 > 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:161 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > nfs_nget() at nfs_nget+0x1c9 > nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc > nfs_doio() at nfs_doio+0x617 > nfs_bioread() at nfs_bioread+0xa9f > nfs_readdir() at nfs_readdir+0x85 > kern_getdirentries() at kern_getdirentries+0x12e > getdirentries() at getdirentries+0x23 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8009d11dc, rsp = 0x7fffffffc3a8, rbp = 0x1 --- This one has not been reported either: > lock order reversal: > 1st 0xffffff000412b270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 > 2nd 0xffffff00043e6098 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xcf3 > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > vfs_msync() at vfs_msync+0xa3 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80e7b74d30, rbp = 0 --- This one is not an LOR but should probably be investigated nonetheless: > acquiring duplicate lock of same type: "ftlk" > 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 > 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x8ef > _sx_xlock() at _sx_xlock+0x55 > futex_get0() at futex_get0+0xfe > linux_sys_futex() at linux_sys_futex+0x96 > ia32_syscall() at ia32_syscall+0x19c > Xint0x80_syscall() at Xint0x80_syscall+0x95 > --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28799533, rsp = 0xffffaecc, rbp = 0x4000001 --- -- Rick C. Petty From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:54:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6A23106568F; Wed, 19 Aug 2009 17:54:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9258B8FC5B; Wed, 19 Aug 2009 17:54:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3940C46B09; Wed, 19 Aug 2009 13:54:13 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 640998A022; Wed, 19 Aug 2009 13:54:12 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 19 Aug 2009 13:51:49 -0400 User-Agent: KMail/1.9.7 References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908191351.49892.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 19 Aug 2009 13:54:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00,PLING_QUERY, RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ed Schouten , pluknet , Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:54:13 -0000 On Wednesday 19 August 2009 10:37:21 am pluknet wrote: > 2009/8/19 Ed Schouten : > > * Patrick Lamaiziere wrote: > >> From time to time, I see this at boot-time on my laptop (a Macbook > >> pro model 3,1). I'm not sure but it seems related if an USB device is > >> plugged in one plug (strange because the internal keyboard and the > >> touchpad are USB devices) > > > > So what does smbios.system.product say? (Escape to the loader prompt and > > run `show' or whatever it's called) > > I'm not Patrik, but I saw this on two Intel boxes running on 6.2. > smbios.system.product="S5000PAL". I didn't try the later releases on them. Look for a BIOS update. Your issue may be different than the MacBook issue. I know of some boxes of this sort where the hangs were resolved by a BIOS update that included newer micrcode for certain CPUs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:54:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6A23106568F; Wed, 19 Aug 2009 17:54:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9258B8FC5B; Wed, 19 Aug 2009 17:54:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3940C46B09; Wed, 19 Aug 2009 13:54:13 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 640998A022; Wed, 19 Aug 2009 13:54:12 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 19 Aug 2009 13:51:49 -0400 User-Agent: KMail/1.9.7 References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908191351.49892.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 19 Aug 2009 13:54:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00,PLING_QUERY, RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ed Schouten , pluknet , Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:54:13 -0000 On Wednesday 19 August 2009 10:37:21 am pluknet wrote: > 2009/8/19 Ed Schouten : > > * Patrick Lamaiziere wrote: > >> From time to time, I see this at boot-time on my laptop (a Macbook > >> pro model 3,1). I'm not sure but it seems related if an USB device is > >> plugged in one plug (strange because the internal keyboard and the > >> touchpad are USB devices) > > > > So what does smbios.system.product say? (Escape to the loader prompt and > > run `show' or whatever it's called) > > I'm not Patrik, but I saw this on two Intel boxes running on 6.2. > smbios.system.product="S5000PAL". I didn't try the later releases on them. Look for a BIOS update. Your issue may be different than the MacBook issue. I know of some boxes of this sort where the hangs were resolved by a BIOS update that included newer micrcode for certain CPUs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 18:08:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAA1D106568D for ; Wed, 19 Aug 2009 18:08:16 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7030B8FC51 for ; Wed, 19 Aug 2009 18:08:16 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7JI6VsP007959; Wed, 19 Aug 2009 11:08:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 11:05:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: network problems Thread-Index: Acog9Awam8jkpd1iRUa3ms1hMeFmlQAA49bO References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> <35FF00562E814F08BE71B6407FB6C1BF@adnote989> From: "Li, Qing" To: "Denis Ahrens" , Cc: Luiz Otavio O Souza Subject: RE: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 18:08:16 -0000 >> >> Qing, >> >> yes, disabling the flowtable (sysctl net.inet.flowtable.enable=3D0) =20 >> fix the problem (no more IPv4 is not on the network). But here, =20 >> everything is working fine, even with that annoying message (no =20 >> crashes). > > My network is also working fine, but it crashes when I ping the =20 > endpoint of the tunnel interface. > When you say your network is working fine, do you actually mean traffic flows across the tunnel ? > > When I turn flowtable off it does not crash but I get no ping reply =20 > back. > Okay, so there is probably another bug lurking somewhere. I am=20 traveling right now and will dig into it once I get back at the end of this week, if someone else hasn't already fixed it by then. -- Qing From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:39:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D9A1065700 for ; Wed, 19 Aug 2009 17:39:15 +0000 (UTC) (envelope-from denis@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 8017E8FC61 for ; Wed, 19 Aug 2009 17:39:14 +0000 (UTC) Received: (qmail 17697 invoked from network); 19 Aug 2009 17:39:13 -0000 Received: from unknown (HELO ?10.1.2.230?) (denis@85.178.13.111) by mail.h3q.com with AES128-SHA encrypted SMTP; 19 Aug 2009 17:39:13 -0000 From: Denis Ahrens To: freebsd-current@freebsd.org In-Reply-To: <35FF00562E814F08BE71B6407FB6C1BF@adnote989> X-Priority: 3 References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> <35FF00562E814F08BE71B6407FB6C1BF@adnote989> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 19:39:11 +0200 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 19 Aug 2009 18:09:39 +0000 Cc: Luiz Otavio O Souza , "Li, Qing" Subject: Re: network problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 17:39:15 -0000 On 19.08.2009, at 19:03, Luiz Otavio O Souza wrote: >>> >>> The problems are similar to http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html >>> >> >> That was a configuration issue. >> >>> >>> When I try to ping the address the machine panics! >>> (something with sin_family and in_lltable_lookup) >>> http://denisy.dyndns.org/panic.jpg >>> >> >> After a quick cursory read over the code, this issue appears to be >> a problem >> in the flow-table handling logic in ip_output() function. >> >> Two problems seem to exist in the flow-table logic. >> >> 1. In flowtable_lookup() where it searches for the destination in the >> routing table, the code does not check for the rt_ifp type once a >> route entry is found. In the case of "if_tun", the flow-table >> must not try to cache any entry whose "rt_ifp->if_flag & >> IFF_POINTOPOINT" >> is true. Right now it does, and I think this will trigger the >> crash >> later. >> >> 2. The flowtable_lookup() seems to alway assume a valid entry >> will be returned as long as a route entry exists for the >> destination. In other words, if a route exists for the >> destination, >> then either flow-table already have a cache, or a new entry >> is created. This does not work due to (1.) above. >> flowtable_lookup() should allow a "bypass flow-table" return, not >> just success/failure result. This is especially true for >> tunneling interfaces "if_tun, if_gre" etc. where ip_output() >> will be called multiple times (nested). Only at the final >> invocation >> of ip_output() (where the rt->rt_ifp points to a physical NIC) >> should a flow-table entry be created. >> >> So for now, as a possible temporary workaround, disable FLOWTABLE >> in your >> kernel configuration file and see if that fixes the problem. >> >> -- Qing > > Qing, > > yes, disabling the flowtable (sysctl net.inet.flowtable.enable=0) > fix the problem (no more IPv4 is not on the network). But here, > everything is working fine, even with that annoying message (no > crashes). My network is also working fine, but it crashes when I ping the endpoint of the tunnel interface. When I turn flowtable off it does not crash but I get no ping reply back. Denis From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 18:17:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1C7E8106568E; Wed, 19 Aug 2009 18:17:59 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 19 Aug 2009 14:17:48 -0400 User-Agent: KMail/1.6.2 References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819144136.GV1292@hoeg.nl> In-Reply-To: <20090819144136.GV1292@hoeg.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200908191417.50237.jkim@FreeBSD.org> Cc: Ed Schouten , pluknet , Patrick Lamaiziere Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 18:17:59 -0000 On Wednesday 19 August 2009 10:41 am, Ed Schouten wrote: > * pluknet wrote: > > I'm not Patrik, but I saw this on two Intel boxes running on 6.2. > > smbios.system.product="S5000PAL". I didn't try the later > > releases on them. > > I wouldn't mind adding non-Apple hardware to this list, but only if > you can tell me the following: There are many Intel ICH boards with this "feature", not just Apple Macs. ;-) I heard disabling legacy keyboard/mouse emulation may work around the problem if there is option in the BIOS: http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application The hack for Mac is required because it doesn't have "BIOS". FYI, I found RT Linux people wrote a simple tool to control the bits from user space: http://www.rts.uni-hannover.de/rtaddon/ and kernel patches, of course: http://www.captain.at/xenomai-smi-high-latency.php Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 18:49:30 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 86D07106568B; Wed, 19 Aug 2009 18:49:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 19 Aug 2009 14:49:17 -0400 User-Agent: KMail/1.6.2 References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819144136.GV1292@hoeg.nl> <200908191417.50237.jkim@FreeBSD.org> In-Reply-To: <200908191417.50237.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200908191449.19887.jkim@FreeBSD.org> Cc: Ed Schouten , pluknet , Patrick Lamaiziere Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 18:49:30 -0000 On Wednesday 19 August 2009 02:17 pm, Jung-uk Kim wrote: > On Wednesday 19 August 2009 10:41 am, Ed Schouten wrote: > > * pluknet wrote: > > > I'm not Patrik, but I saw this on two Intel boxes running on > > > 6.2. smbios.system.product="S5000PAL". I didn't try the later > > > releases on them. > > > > I wouldn't mind adding non-Apple hardware to this list, but only > > if you can tell me the following: > > There are many Intel ICH boards with this "feature", not just Apple > Macs. ;-) > > I heard disabling legacy keyboard/mouse emulation may work around > the problem if there is option in the BIOS: > > http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application > > The hack for Mac is required because it doesn't have "BIOS". > > FYI, I found RT Linux people wrote a simple tool to control the > bits from user space: > > http://www.rts.uni-hannover.de/rtaddon/ I found I had a similar (but very old) tool for FreeBSD: http://people.freebsd.org/~jkim/ich-periodic-smm-disable.c Originally it was posted here: http://lists.freebsd.org/pipermail/freebsd-stable/2005-April/013737.html It was a different symptom but basically the same problem, i.e., a buggy BIOS spinning too much time in SMM code. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 19:10:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B04A106568D for ; Wed, 19 Aug 2009 19:10:08 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp3.apollo.lv (smtp3.apollo.lv [80.232.168.198]) by mx1.freebsd.org (Postfix) with ESMTP id D77A28FC66 for ; Wed, 19 Aug 2009 19:10:07 +0000 (UTC) Received: from [87.110.119.231] (unknown [87.110.119.231]) by smtp3.apollo.lv (Postfix) with ESMTP id 5E95B983D6; Wed, 19 Aug 2009 21:38:18 +0300 (EEST) From: Dmitriy Demidov To: ed@80386.nl, freebsd-current@freebsd.org Date: Wed, 19 Aug 2009 21:38:16 +0300 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908192138.17160.dima_bsd@inbox.lv> X-Lattelecom-MailScanner-Information: Please contact the ISP for more information X-Lattelecom-MailScanner-ID: 5E95B983D6.AD395 X-Lattelecom-MailScanner: Found to be clean X-Lattelecom-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.901, required 5, BAYES_00 -2.60, RCVD_IN_PBL 0.91, RDNS_NONE 0.10, SPF_FAIL 0.69) X-Lattelecom-MailScanner-From: dima_bsd@inbox.lv X-Spam-Status: No Cc: Subject: vesa driver already for amd64! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:10:08 -0000 Hello. I just want to make you know about one ongoing project of "porting" vesa driver from i386 into amd64 architecture. You can read more about it's status in English here: http://forums.freebsd.org/showthread.php?t=6291 Or in Russian here: http://forum.lissyara.su/viewtopic.php?f=8&t=19906 The author of this effort is one skilled programmer who is hiding behind the nickname "paradox" (I'm not ilvolved in this project - so all glories and questions you should address to him, ok? :) The ability to run vesa console driver in amd64 became a reality after porting of x86emu from OpenBSD performed by paradox. At this moment there already is ability to use vesa mode in early stages of FreeBSD booting process and to have hight screen resolutions@32bit in console!!! Work is still in progress at this moment. The is one question regarding of this project: do FreeBSD community and official commiters is interested in this feature? Is there any possibility to see this code commited in official FreeBSD tree? Ed, can you please take a look on this code? I know about ongoing work in syscons. May be this solution will be good enought to be used right now, and may be it will help to speed up new graphical console development (on what you are working now)? Best regards! From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 19:37:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EC6D106568E for ; Wed, 19 Aug 2009 19:37:39 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id DC8B78FC51 for ; Wed, 19 Aug 2009 19:37:38 +0000 (UTC) Received: (qmail 3398 invoked from network); 19 Aug 2009 12:23:48 -0700 Received: by simscan 1.1.0 ppid: 3378, pid: 3379, t: 2.1832s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp2.surewest.net. X-Spam-Level: X-Spam-Status: No, score=0.0 required=10.0 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=jDt-9pEAAAAA:8 a=LATiwjgCkAoXcU-ZVCkA:9 a=veYLx3zBxlZKQf9RXmsA:7 a=xRrpAHo2FFnHjnbcrF2jaCYbMSYA:4 Received: from unknown (HELO blacklamb.mykitchentable.net) (69.62.230.77) by smtp2 with SMTP; 19 Aug 2009 12:23:46 -0700 Received: from [127.0.0.1] (bigdaddy.mykitchentable.net [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with ESMTPA id 62B801658B1 for ; Wed, 19 Aug 2009 12:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mykitchentable.net; s=default; t=1250710655; bh=vicJnhB8+P2G24NGnhdYU6KNmc/vNGNdI/sknY9YlfM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=2Tp5cRwtkQ1hrf4SIahOw5Y8eJXklzMjH8WGdgbm/4B3mJmhsFtZTeGmaqRHQf84d aOUWE0aAGAJEdE5i9WUCs1tfo25pdmKfsgv3eD11RZCjdCUn3yCaC5t1Ux2+3PCjo0 Rr99/m+WBrvhqOkJmakVchzZ2IHTr/4vC8GxNCFA= Message-ID: <4A8C5475.3020205@mykitchentable.net> Date: Wed, 19 Aug 2009 12:37:25 -0700 From: Drew Tomlinson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090818-0, 08/18/2009), Outbound message X-Antivirus-Status: Clean Subject: How To Copy DVD to ISO File X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:37:39 -0000 I'm using 8.0-BETA2 and have a SATA DVD drive. I'd like to take a DVD and create an ISO file from it. I have not done this before on FreeBSD. I've googled and it appears it should be as simple as: dd if=/dev/ of=/path/to/ISO So I figured out that my DVD drive is seen as /dev/acd0 and verified that it's accessible with "mount -t 9660 /dev/acd0 /mnt". After doing so, I can 'ls' files on /mnt. Then I unmounted the drive. So to create my ISO, I issued this command: dd if=/dev/acd0 of=DVD.iso But get this output: dd: /dev/acd0: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 0.000132 secs (0 bytes/sec) I googled some more and thought that loading atapicam.ko might help. But yet I get the same error when using /dev/cd0. So what am I doing wrong? Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 20:08:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B71106568B for ; Wed, 19 Aug 2009 20:08:11 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 13BC58FC59 for ; Wed, 19 Aug 2009 20:08:10 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7JK8881029342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 22:08:09 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <9598E097-F552-4E66-B53B-5EA2CDF05E4F@lassitu.de> From: Stefan Bethke To: Drew Tomlinson In-Reply-To: <4A8C5475.3020205@mykitchentable.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 22:08:08 +0200 References: <4A8C5475.3020205@mykitchentable.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: How To Copy DVD to ISO File X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 20:08:11 -0000 Am 19.08.2009 um 21:37 schrieb Drew Tomlinson: > I'm using 8.0-BETA2 and have a SATA DVD drive. I'd like to take a > DVD and create an ISO file from it. I have not done this before on > FreeBSD. > > I've googled and it appears it should be as simple as: > > dd if=/dev/ of=/path/to/ISO > > So I figured out that my DVD drive is seen as /dev/acd0 and verified > that it's accessible with "mount -t 9660 /dev/acd0 /mnt". After > doing so, I can 'ls' files on /mnt. Then I unmounted the drive. > > So to create my ISO, I issued this command: > > dd if=/dev/acd0 of=DVD.iso > > But get this output: > > dd: /dev/acd0: Invalid argument > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.000132 secs (0 bytes/sec) > > I googled some more and thought that loading atapicam.ko might > help. But yet I get the same error when using /dev/cd0. > > So what am I doing wrong? The driver only supports reads of blocksized chunks, so: $ dd if=/dec/acd0 bs=2048 ... should work. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 20:13:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79961065691 for ; Wed, 19 Aug 2009 20:13:56 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id BF6FE8FC16 for ; Wed, 19 Aug 2009 20:13:56 +0000 (UTC) Received: (qmail 21567 invoked from network); 19 Aug 2009 13:00:03 -0700 Received: by simscan 1.1.0 ppid: 21418, pid: 21420, t: 2.1814s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp2.surewest.net. X-Spam-Level: X-Spam-Status: No, score=0.0 required=10.0 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=jDt-9pEAAAAA:8 a=aoCsIJWZbv5gampnDnEA:9 a=GVbn_hoqA3oIa20V7FoA:7 a=3GxxJoYamziAia2pk9WsUlQ9BMIA:4 Received: from unknown (HELO blacklamb.mykitchentable.net) (69.62.230.77) by smtp2 with SMTP; 19 Aug 2009 13:00:00 -0700 Received: from [127.0.0.1] (bigdaddy.mykitchentable.net [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with ESMTPA id 4B5181658B5; Wed, 19 Aug 2009 13:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mykitchentable.net; s=default; t=1250712830; bh=M0GPmhatimf79S400z4SCI7Uoa9WPxyHBj0EktD2WQI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=J+UMBop8uQOze/S/ZsOyWxyimAdabjoDDD49cupFlEmDgU3XRrg6sLy8s1YBM+1Sw qhc4a8QmVI56Y07KxJ8viaPw9JKgDZld+IX6taI6tZDsro3fERxzs1esmFP7in0dsc EsOqhnZzwZS65eK8Bf6CkG3o6jn1C3B9Zl7doRio= Message-ID: <4A8C5CF5.2040104@mykitchentable.net> Date: Wed, 19 Aug 2009 13:13:41 -0700 From: Drew Tomlinson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stefan Bethke References: <4A8C5475.3020205@mykitchentable.net> <9598E097-F552-4E66-B53B-5EA2CDF05E4F@lassitu.de> In-Reply-To: <9598E097-F552-4E66-B53B-5EA2CDF05E4F@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090818-0, 08/18/2009), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: How To Copy DVD to ISO File X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 20:13:57 -0000 Stefan Bethke wrote: > Am 19.08.2009 um 21:37 schrieb Drew Tomlinson: > >> I'm using 8.0-BETA2 and have a SATA DVD drive. I'd like to take a >> DVD and create an ISO file from it. I have not done this before on >> FreeBSD. >> >> I've googled and it appears it should be as simple as: >> >> dd if=/dev/ of=/path/to/ISO >> >> So I figured out that my DVD drive is seen as /dev/acd0 and verified >> that it's accessible with "mount -t 9660 /dev/acd0 /mnt". After >> doing so, I can 'ls' files on /mnt. Then I unmounted the drive. >> >> So to create my ISO, I issued this command: >> >> dd if=/dev/acd0 of=DVD.iso >> >> But get this output: >> >> dd: /dev/acd0: Invalid argument >> 0+0 records in >> 0+0 records out >> 0 bytes transferred in 0.000132 secs (0 bytes/sec) >> >> I googled some more and thought that loading atapicam.ko might help. >> But yet I get the same error when using /dev/cd0. >> >> So what am I doing wrong? > > The driver only supports reads of blocksized chunks, so: > $ dd if=/dec/acd0 bs=2048 ... > should work. Thanks! That was it. I'm usually getting snagged by some sort of "BS"... :) Cheers, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 20:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E65F106568C for ; Wed, 19 Aug 2009 20:31:19 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f180.google.com (mail-vw0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 060288FC16 for ; Wed, 19 Aug 2009 20:31:18 +0000 (UTC) Received: by vws10 with SMTP id 10so4004250vws.7 for ; Wed, 19 Aug 2009 13:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=M9krnCG+NZix4bKknxT44AsOZmW3JosrLCpiwVeVaw8=; b=xkwDyVZdQWXSfiqoX2qljaOoNIJgmB9eC54L4FTCVnhK5wnwzmW2fBNmdZ33p1bxQU IVk7meccqFn0XvpK8+M6F8B5xU367gbvJoh5xB3NYy24ehANaj1VNuFESoU9RmRtkEnI eF4XZ9KcLeyxoQVecyJA6K87SwDlCUBzopGQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=ERfLzDemqRrwHRE3K19J6Xta4S3uRWBP5LAr140YBcjyNO2qVhE56tOZRY4WFqlC0i XXvkyUqLt4HCghJgqtVl/zjYN19gqORI9KPDIuUcqphjM+d94OQGVbINBbfgV7KCvqhC wlYwzIa7yHj35lORxb23dcWMAXjfK1fMXMiv4= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.14.145 with SMTP id g17mr9631037vca.118.1250713878280; Wed, 19 Aug 2009 13:31:18 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 19 Aug 2009 22:30:58 +0200 X-Google-Sender-Auth: a04d2c1229fa9bd0 Message-ID: <3131aa530908191330y79d9de43idadad109033e5552@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Regression] Can't mount my root hard drive (failure - read_dma48) with nVidia nForce CK804 UDMA133 controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 20:31:19 -0000 Hi, I still can't use my PATA hard drive on the 8.0-current (source synced today) on Asus K8N4-E Delux motherboard (using nVidia nForce CK804 UDMA133 controller). This system works great under FreeBSD 7.2. I've got lot's of theses error messages during bootup: ad0: FAILURE - READ_DMA48 timed out LBA=586072364 ad0: TIMEOUT - READ_DMA retrying (1 retries left) LBA= ata0: reiniting channel... And after few minutes, it stop with message that it can't mount the root filesystem. Thanks, Olivier dmesg (under FreeBSD 7.2): Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (2010.31-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 usable memory = 2134417408 (2035 MB) avail memory = 2058027008 (1962 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xd3103000-0xd3103fff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xd3104000-0xd31040ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 23 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3101000-0xd3101fff irq 21 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pci5: on pcib1 fwohci0: mem 0xd3004000-0xd30047ff,0xd3000000-0xd3003fff irq 16 at device 11.0 on pci5 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:00:65:26:3c fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7c314000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:65:26:3c fwe0: Ethernet address: 02:11:d8:65:26:3c fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:00:65:26:3c @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode nfe0: port 0xb000-0xb007 mem 0xd3100000-0xd3100fff irq 22 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 15 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:13:d4:d6:3a:7b nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci4: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci2: on pcib4 pcib5: at device 14.0 on pci0 pci1: on pcib5 vgapci0: mem 0xd0000000-0xd0ffffff,0xc0000000-0xcfffffff,0xd1000000-0xd1ffffff irq 18 at device 0.0 on pci1 acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 orm0: at iomem 0xd0000-0xd3fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: on uhub0 uhub2: 2 ports with 1 removable, bus powered ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 ums0: on uhub2 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2010312449 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 286168MB at ata0-master UDMA100 ad8: 953869MB at ata4-master SATA150 GEOM: ad0: the secondary GPT table is corrupt or invalid. GEOM: ad0: using the primary only -- recovery suggested. GEOM_LABEL: Label for provider ad0p1 is ufsid/477f45096d16161b. GEOM_LABEL: Label for provider ad0p1 is ufs/Disque1. GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. GEOM_LABEL: Label for provider ad8p1 is ufsid/499c8ec590cbe4cd. GEOM_LABEL: Label for provider ad8p1 is ufs/1TB3. Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ufs/Disque1 removed. GEOM_LABEL: Label ufsid/477f45096d16161b removed. GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. GEOM_LABEL: Label ufsid/499c8ec590cbe4cd removed. From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 20:58:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 553861065672 for ; Wed, 19 Aug 2009 20:58:20 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id D261B8FC15 for ; Wed, 19 Aug 2009 20:58:19 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7JKvwYx035703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 22:57:59 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <9013F85E-E2AD-45C5-ACF1-E3B2E99D949D@lassitu.de> From: Stefan Bethke To: Dmitriy Demidov In-Reply-To: <200908192138.17160.dima_bsd@inbox.lv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 22:57:58 +0200 References: <200908192138.17160.dima_bsd@inbox.lv> X-Mailer: Apple Mail (2.936) Cc: ed@80386.nl, freebsd-current@freebsd.org Subject: Re: vesa driver already for amd64! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 20:58:20 -0000 Am 19.08.2009 um 20:38 schrieb Dmitriy Demidov: > Hello. > > I just want to make you know about one ongoing project of "porting" > vesa > driver from i386 into amd64 architecture. You can read more about > it's status > in English here: http://forums.freebsd.org/showthread.php?t=6291 > Or in Russian here: http://forum.lissyara.su/viewtopic.php?f=8&t=19906 Cool stuff. I've just tried in VMware, and the window size changes very briefly, but then vidcontrol tells me: vidcontrol: cannot activate raster display: Inappropriate ioctl for device (I tried with MODE_320 which is listed as 800x600x32.) And I just realized that this is consistent with i386 (tried on 6.4/ i386), so no luck for :-/ Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 21:27:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4729106568D for ; Wed, 19 Aug 2009 21:27:51 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id AFC1F8FC15 for ; Wed, 19 Aug 2009 21:27:51 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 72F6C851A; Wed, 19 Aug 2009 21:27:50 +0000 (UTC) Date: Wed, 19 Aug 2009 22:27:36 +0100 From: Bruce Cran To: rick-freebsd2008@kiwi-computer.com Message-ID: <20090819222736.6495e3f8@gluon.draftnet> In-Reply-To: <20090819161817.GA89704@keira.kiwi-computer.com> References: <20090819161817.GA89704@keira.kiwi-computer.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 21:27:51 -0000 On Wed, 19 Aug 2009 11:18:17 -0500 "Rick C. Petty" wrote: > Upon every restart, I see a few LORs. I couldn't find PRs for any of > them. See attached dmesg below. Should I submit a PR for each of > them or one PR for all five? Since it hasn't been reported yet, this is one I saw on 8.0-BETA2 a few days ago: lock order reversal: 1st 0xffffff8053208060 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffffff80c1c8e0 proctree (proctree) @ /usr/src/sys/kern/subr_prf.c:140 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_slock() at _sx_slock+0x55 uprintf() at uprintf+0x7d ffs_alloc() at ffs_alloc+0x1ba ffs_balloc_ufs2() at ffs_balloc_ufs2+0x11cc ffs_write() at ffs_write+0x248 VOP_WRITE_APV() at VOP_WRITE_APV+0x103 vn_rdwr() at vn_rdwr+0x21d vn_rdwr_inchunks() at vn_rdwr_inchunks+0xc2 elf64_coredump() at elf64_coredump+0x191 sigexit() at sigexit+0x81d postsig() at postsig+0x32f ast() at ast+0x3ac doreti_ast() at doreti_ast+0x1f -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 21:28:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6629106568B for ; Wed, 19 Aug 2009 21:28:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5E79F8FC45 for ; Wed, 19 Aug 2009 21:28:36 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7JLSI0W039716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 23:28:19 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <85C2BFCC-8A50-4BC9-B1A0-0EE279CE77AD@lassitu.de> From: Stefan Bethke To: FreeBSD current In-Reply-To: <9013F85E-E2AD-45C5-ACF1-E3B2E99D949D@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 23:28:18 +0200 References: <200908192138.17160.dima_bsd@inbox.lv> <9013F85E-E2AD-45C5-ACF1-E3B2E99D949D@lassitu.de> X-Mailer: Apple Mail (2.936) Cc: ed@80386.nl, Dmitriy Demidov Subject: Re: vesa driver already for amd64! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 21:28:36 -0000 Am 19.08.2009 um 22:57 schrieb Stefan Bethke: > Am 19.08.2009 um 20:38 schrieb Dmitriy Demidov: > >> Hello. >> >> I just want to make you know about one ongoing project of "porting" >> vesa >> driver from i386 into amd64 architecture. You can read more about >> it's status >> in English here: http://forums.freebsd.org/showthread.php?t=6291 >> Or in Russian here: http://forum.lissyara.su/viewtopic.php? >> f=8&t=19906 > > Cool stuff. I've just tried in VMware, and the window size changes > very briefly, but then vidcontrol tells me: > vidcontrol: cannot activate raster display: Inappropriate ioctl for > device Sorry for the noise, reading the instructions carefully helps. I was missing options SC_PIXEL_MODE, and now everything appears to be working perfectly, including the boot-time mode change via hints.sc. 0.flags. 8-bit modes give just a blank window (with the right dimensions though), and I can switch to a different console and switch to a working mode. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 01:53:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F05106564A for ; Thu, 20 Aug 2009 01:53:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id E8CDD8FC3D for ; Thu, 20 Aug 2009 01:53:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KON004B8JXL4I20@asmtp026.mac.com> for freebsd-current@freebsd.org; Wed, 19 Aug 2009 18:53:46 -0700 (PDT) From: Marcel Moolenaar Date: Wed, 19 Aug 2009 18:53:45 -0700 Message-id: <6359C817-0D09-4BBC-95A3-5F9226EA8706@mac.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1074) Subject: ZFS regression: Giant lock held by kldload syscall (panic: witness_warn) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 01:53:47 -0000 All, I can't boot with ZFS enabled on my ia64 box: : Trying to mount root from ufs:da0p3 kldload: can't load zfs: No such file or directory /etc/rc: WARNING: Unable to load kernel module zfs Entropy harvesting: interrupts ethernet point_to_point kickstart. /dev/da0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0p3: clean, 8743374 free (100606 frags, 1080346 blocks, 0.6% fragmentation) WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 System call kldload returning with the following locks held: exclusive sleep mutex Giant (Giant) r = 0 (0xe000000004821188) locked @ /nfs/freebsd/base/head/sys/modules/zfs/../../cddl/compat/opensolaris/ kern/opensolaris_kobj.c:228 panic: witness_warn cpuid = 0 KDB: enter: panic [thread pid 88 tid 100058 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1c308,gp ;; db> bt Tracing pid 88 tid 100058 td 0xe000000011558740 kdb_enter(0xe0000000046dc040, 0xe0000000046dc040, 0xe000000004317870, 0x793) at kdb_enter+0x92 panic(0xe0000000046ab268, 0xe0000000046e4618) at panic+0x2f0 witness_warn(0x2, 0x0, 0xe0000000047139b0, 0xe0000000046e5ba8) at witness_warn+0x500 syscall(0xa0000000c5c55400, 0x130, 0x2e, 0xe000000011558740, 0xe000000010ce7568, 0x0, 0x130, 0x130) at syscall+0x520 epc_syscall_return() at epc_syscall_return db> ps pid ppid pgrp uid state wmesg wchan cmd 90 0 0 0 SL l2arc_fe 0xa0000000006ac978 [l2arc_feed_thread] 89 0 0 0 SL arc_recl 0xa0000000006a44d8 [arc_reclaim_thread] 88 86 23 0 R+ CPU 0 kldload 86 23 23 0 S+ wait 0xe0000000115c1120 sh 23 1 23 0 Ss+ wait 0xe000000011416000 sh 22 0 0 0 SL - 0xe0000000048133b0 [schedcpu] 19 0 0 0 SL sdflush 0xe0000000048145d0 [softdepflush] 18 0 0 0 SL syncer 0xe0000000049ca2e0 [syncer] 17 0 0 0 SL vlruwt 0xe000000010c1c448 [vnlru] 16 0 0 0 SL psleep 0xe000000004813aa0 [bufdaemon] 15 0 0 0 SL pgzero 0xe0000000048148ec [pagezero] 9 0 0 0 SL psleep 0xe000000004814888 [vmdaemon] 8 0 0 0 SL psleep 0xe00000000481489c [pagedaemon] 14 0 0 0 SL (threaded) usb 100045 D - 0xa0000000000c6dd0 [usbus2] 100044 D - 0xa0000000000c6d78 [usbus2] 100043 D - 0xa0000000000c6d20 [usbus2] 100042 D - 0xa0000000000c6cc8 [usbus2] 100041 D - 0xa0000000000bd460 [usbus1] 100040 D - 0xa0000000000bd408 [usbus1] 100039 D - 0xa0000000000bd3b0 [usbus1] 100038 D - 0xa0000000000bd358 [usbus1] 100037 D - 0xa0000000000b9460 [usbus0] 100036 D - 0xa0000000000b9408 [usbus0] 100035 D - 0xa0000000000b93b0 [usbus0] 100034 D - 0xa0000000000b9358 [usbus0] 7 0 0 0 SL idle 0xa0000000000ca300 [mpt_raid0] 6 0 0 0 SL idle 0xa0000000000ca000 [mpt_recovery0] 13 0 0 0 SL tzpoll 0xe000000004812a18 [acpi_thermal] 5 0 0 0 SL ccb_scan 0xe000000004814ba0 [xpt_thrd] 12 0 0 0 SL - 0xe0000000048133b0 [yarrow] 4 0 0 0 SL - 0xe000000004812e88 [g_down] 3 0 0 0 SL - 0xe000000004812e80 [g_up] 2 0 0 0 SL - 0xe000000004812e70 [g_event] 11 0 0 0 WL (threaded) intr 100033 I [irq30: bge1] 100032 I [irq29: bge0] 100029 I [irq27: mpt0] 100028 I [irq19: ehci0] 100027 I [irq18: ohci1] 100026 I [irq17: ohci0] 100025 I [swi0: uart uart] 100023 I [irq25: acpi0] 100018 I [swi2: cambio] 100016 I [swi6: task queue] 100015 I [swi6: Giant taskq] 100013 I [swi5: +] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 I [swi4: clock] 100004 I [swi3: vm] 10 0 0 0 RL (threaded) idle 100003 CanRun [idle: cpu0] 100002 Run CPU 1 [idle: cpu1] 1 0 1 0 SLs wait 0xe000000010c1c000 [init] 0 0 0 0 SLs (threaded) kernel 100022 D - 0xe000000010c24780 [kqueue taskq] 100021 D - 0xe000000010c24c00 [acpi_task_2] 100020 D - 0xe000000010c24c00 [acpi_task_1] 100019 D - 0xe000000010c24c00 [acpi_task_0] 100014 D - 0xe000000010c25100 [thread taskq] 100011 D - 0xe000000010c19900 [firmware taskq] 100000 D sched 0xe00000000481e8e0 [swapper] Should I stop loading the opensolaris and zfs modules in the loader? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 02:13:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B011A106564A for ; Thu, 20 Aug 2009 02:13:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1C18FC5B for ; Thu, 20 Aug 2009 02:13:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KON002D1KS70110@asmtp029.mac.com> for freebsd-current@freebsd.org; Wed, 19 Aug 2009 19:13:56 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <6359C817-0D09-4BBC-95A3-5F9226EA8706@mac.com> Date: Wed, 19 Aug 2009 19:12:06 -0700 Message-id: <5E3EBBE8-4A7D-4335-B814-8E70EA1CC81B@mac.com> References: <6359C817-0D09-4BBC-95A3-5F9226EA8706@mac.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1074) Subject: Re: ZFS regression: Giant lock held by kldload syscall (panic: witness_warn) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:13:56 -0000 On Aug 19, 2009, at 6:53 PM, Marcel Moolenaar wrote: > All, > > I can't boot with ZFS enabled on my ia64 box: On top of that, the pool became unavailable. Importing the pool resulted in an immediate panic again: hob# zpool import rel panic: mutex Giant owned at /nfs/freebsd/base/head/sys/kern/ kern_exit.c:131 cpuid = 0 KDB: enter: panic [thread pid 1022 tid 100090 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1c308,gp ;; db> bt Tracing pid 1022 tid 100090 td 0xe000000011567220 kdb_enter(0xe0000000046dc040, 0xe0000000046dc040, 0xe000000004317870, 0x793) at kdb_enter+0x92 panic(0xe0000000046da148, 0xe0000000046da6b8, 0xe0000000046d5d28, 0x83) at panic+0x2f0 _mtx_assert(0xe000000004821188, 0x0, 0xe0000000046d5d28, 0x83, 0xe0000000042c49f0) at _mtx_assert+0x200 exit1(0xe000000011567220, 0x0, 0xe0000000042ded90, 0x48d) at exit1+0x40 kproc_exit(0x0, 0xe0000000046d79b8, 0xe0000000117fa0f8, 0xe0000000117fa000) at kproc_exit+0x130 spa_async_thread(0xe000000011572000, 0x1, 0xe0000000046d5ff8, 0x33e) at spa_async_thread+0x1a0 fork_exit(0xe000000004794c20, 0xe000000011572000, 0xa0000000c5cbf550) at fork_exit+0x110 enter_userland() at enter_userland db> show alllocks Process 1022 (solthread 0xe000000) thread 0xe000000011567220 (100090) exclusive sleep mutex Giant (Giant) r = 1 (0xe000000004821188) locked @ /nfs/freebsd/base/head/sys/kern/vfs_lookup.c:749 Something likes Giant and can't just let go... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 02:52:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED0E106568C for ; Thu, 20 Aug 2009 02:52:14 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BC7768FC65 for ; Thu, 20 Aug 2009 02:52:13 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D3B5E19E044; Thu, 20 Aug 2009 04:52:09 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7145619E043; Thu, 20 Aug 2009 04:52:07 +0200 (CEST) Message-ID: <4A8CBA58.3060809@quip.cz> Date: Thu, 20 Aug 2009 04:52:08 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Viktor CISTICZ References: <8cBY1VMA.1250601254.4165210.viktor@mx.estimese.net> In-Reply-To: <8cBY1VMA.1250601254.4165210.viktor@mx.estimese.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: GET BUF: dmamap load failure - 12 + kernel panic [was: NETIO UDP benchmark problem] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:52:14 -0000 I changed subject to better describing one, because it is not problem in netio itself. Viktor CISTICZ wrote: > Hello, > recently i have been testing two servers via crosslink. Both have > Freebsd installed > > > twin1$ uname -a > FreeBSD twin1 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Sun Aug 16 > 22:57:29 CEST 2009 > viktor@twin1:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 > > twin2$ uname -a > FreeBSD kitt.twin2 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 22 15:05:19 > CEST 2009 viktor@kitt.twin2:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 > > GEN_NO_DBG is GENERIC kernel without debugging options > > Twin2 is virtual machine on the same hardware as twin1, vmware used. > > I have this set installed on both machines > > twin1$ pkg_info > NetPIPE-3.7.1 A self-scaling network benchmark > gettext-0.17_1 GNU gettext package > gmake-3.81_3 GNU version of 'make' utility > iperf-2.0.4 A tool to measure maximum TCP and UDP bandwidth > libiconv-1.13.1 A character set conversion library > libtool-2.2.6a Generic shared library support script > netio-1.26 Network benchmark > netperf-2.4.5 Network performance benchmarking package > portaudit-0.5.13 Checks installed ports against a list of security > vulnerabi > portmaster-2.9 Manage your ports without external databases or > languages > screen-4.0.3_6 A multi-screen window manager > ttcp-1.12 Benchmarking tool for analysing TCP and UDP > performance > unzip-5.52_5 List, test and extract compressed files in a ZIP > archive > > Both machines are connected via crosslink > > twin1# ifconfig > igb0 : public interface > igb1: flags=8843 metric 0 mtu 1500 > options=13b > ether 00:30:48:c8:f3:91 > inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 > media: Ethernet autoselect (1000baseT ) > status: active > > twin2# ifconfig > em0: public interface > em1: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:0c:29:4b:f1:76 > inet 10.10.10.20 netmask 0xffffff00 broadcast 10.10.10.255 > media: Ethernet autoselect (1000baseT ) > status: active > > I have set up twin2 as a server for netio > > kitt.twin2# netio -s -p 1122 > > And then tested from twin1 tcp test > > twin1# netio -p 1122 -t 10.10.10.20 > > It was allright, i've got some results. > > But when I tried UDP, it failed. > > The server is still the same > > kitt.twin2# netio -s -p 1122 > > Client > twin1# netio -p 1122 -u 10.10.10.20 > > After around 1 minute, twin1 server stopped responding on public > interface, i've been disconnected. Via remote console i could access > the machine, it was acting normally. I could ping both interfaces. I > could even ping from other side of crosslink, from twin2 the privat > interface, but no reply on public interface. > The interface was shown UP in ifconfig, no messages in /var/log/messages. > > Then i executed ifconfig igb1 down && ifconfig igb1 up and it worked > again. Did you ifconfig down + up igb1 or igb0? As you said "server stopped responding on public interface", but you have igb0 marked as public interface and igb1 as private crosslink interface in ifconfig above. Are you really saying that heavy UDP load on private interface igb1 caused freez of public interface igb0 and then kernel panic? > I have then executed netio udp test again with 2k udp packets > > The server is still the same > > kitt.twin2# netio -s -p 1122 > > twin1# netio -p 1122 -u -b 2k 10.10.10.20 > > The same problem on twin1, but now it has crashed the computer > > via remote console i could see this > > twin1# GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > > then it executed core dump and restarted. > > I am lost, thanks for any advise. Did you run it as root or regular user? Can you add output of netstat -m right before interface freez / kernel panic? And last - can you reproduce it with kernel with debugging options enabled? Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 04:58:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7BA0106568B for ; Thu, 20 Aug 2009 04:58:53 +0000 (UTC) (envelope-from uwe@laverenz.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0AA8FC55 for ; Thu, 20 Aug 2009 04:58:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1250744331; l=621; s=domk; d=laverenz.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=2WQGJQ4xHXh9u4bF+BCgIs4GRXs=; b=NhBLpw8J2Id3+QOXzxNyY+1RfIgRspbVdG9XtcRjeAW06UT+MPbi5beemN3yC0ZiD/F S1l/iqoxWjLUudUoHzaZ2Zt2RX6uqMTs10kWXlDBqF3TRHA6jd2U4HdSXZQ1cdDBamQx1 3qtjjcIfw672EjbOsFzWTOgx83QCREZIYf4= X-RZG-AUTH: :LWgJfE6Id/4Sm/WkdV0gEbKL+/p/UjmosA/b4BPR0oc5Ok8M77fXsZg= X-RZG-CLASS-ID: mo00 Received: from athena.laverenz.de (91-67-7-194-dynip.superkabel.de [91.67.7.194]) by post.strato.de (klopstock mo26) (RZmta 20.5) with ESMTP id t00780l7K3SYuU for ; Thu, 20 Aug 2009 06:47:44 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id 18D36127BD8 for ; Thu, 20 Aug 2009 06:48:28 +0200 (CEST) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11673-04 for ; Thu, 20 Aug 2009 06:48:27 +0200 (CEST) Received: from [192.168.23.142] (unknown [192.168.23.142]) by athena.laverenz.de (Postfix) with ESMTP id AFF0C127BD2 for ; Thu, 20 Aug 2009 06:48:27 +0200 (CEST) Message-ID: <4A8CD532.5090705@laverenz.de> Date: Thu, 20 Aug 2009 06:46:42 +0200 From: Uwe Laverenz Organization: private site User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 04:58:53 -0000 Hi all, > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config I just tested an Asus board with 785G chipset (M4A785TD-M EVO). I see the same problem with both 8.0-Beta2 and 7.2-RELEASE (amd64). In my case it helped to disable Firewire device in the BIOS settings. cu, Uwe From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 06:53:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111DE106568C for ; Thu, 20 Aug 2009 06:53:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 596528FC45 for ; Thu, 20 Aug 2009 06:53:15 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9099145C8A; Thu, 20 Aug 2009 08:53:13 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 96D7E45C9F; Thu, 20 Aug 2009 08:53:08 +0200 (CEST) Date: Thu, 20 Aug 2009 08:53:11 +0200 From: Pawel Jakub Dawidek To: Thomas Backman Message-ID: <20090820065310.GA2865@garage.freebsd.pl> References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: FreeBSD current Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 06:53:17 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2009 at 05:24:47PM +0200, Thomas Backman wrote: [...] > Worse yet: >=20 > [root@chaos ~]# zpool create testpool ad0s1d > [root@chaos ~]# zpool export testpool > [root@chaos ~]# zpool import testpool > cannot import 'testpool': no such pool available Should be fixed in head and stable/8, could you verify that it works for yo= u? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKjPLWForvXbEpPzQRAhR6AKCV5NpixGyoSQa2dCFE+ZcwEEVvJQCgxZDS QBJxB7VfnKFk6q94MBE9eNE= =niBj -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 06:54:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83F09106568F for ; Thu, 20 Aug 2009 06:54:46 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 247D38FC16 for ; Thu, 20 Aug 2009 06:54:45 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 0FF6C1CD3E; Thu, 20 Aug 2009 08:54:45 +0200 (CEST) Date: Thu, 20 Aug 2009 08:54:44 +0200 From: Ed Schouten To: Patrick Lamaiziere Message-ID: <20090820065444.GA1292@hoeg.nl> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819170803.355e1857@baby-jane.lamaiziere.net> <20090819151021.GW1292@hoeg.nl> <20090819192007.0e1c6a12@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OqG5N5f8gK0cTFut" Content-Disposition: inline In-Reply-To: <20090819192007.0e1c6a12@baby-jane.lamaiziere.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 06:54:46 -0000 --OqG5N5f8gK0cTFut Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Patrick, * Patrick Lamaiziere wrote: > Le Wed, 19 Aug 2009 17:10:21 +0200, > Ed Schouten a =E9crit : >=20 > > * Patrick Lamaiziere wrote: > > > Thanks, the problem is quite reproductible here, so I can test > > > anything and any idea if it can help. > >=20 > > Can you try this patch, then? ;-) >=20 > It works for me on i386. >=20 > Thanks a lot. I forgot to send this message yesterday, but I've committed the patch to SVN. --=20 Ed Schouten WWW: http://80386.nl/ --OqG5N5f8gK0cTFut Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqM8zQACgkQ52SDGA2eCwUPyQCfcZ7HShsYTdbL2T2ucLqRYxL+ i18AnigHEI1/mR5AipqT73AYm1mu13ua =xwRa -----END PGP SIGNATURE----- --OqG5N5f8gK0cTFut-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 07:41:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21521065690; Thu, 20 Aug 2009 07:41:58 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0C18FC43; Thu, 20 Aug 2009 07:41:58 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:32911 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Me2H7-0005Zl-5y; Thu, 20 Aug 2009 09:41:35 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3FB6C119040; Thu, 20 Aug 2009 09:41:31 +0200 (CEST) Message-Id: <4A6623E5-43D1-4E50-9A04-D7AA66D15606@exscape.org> From: Thomas Backman To: Pawel Jakub Dawidek In-Reply-To: <20090820065310.GA2865@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Aug 2009 09:41:29 +0200 References: <25E11A9B-9FDE-4C34-8C6F-8A7883E9876A@exscape.org> <20090820065310.GA2865@garage.freebsd.pl> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1Me2H7-0005Zl-5y. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Me2H7-0005Zl-5y af7b9ce8126436e3232546f6392f8b60 Cc: FreeBSD current Subject: Re: Bad news re: new (20080817) ZFS patches and send/recv (broken again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 07:41:58 -0000 On Aug 20, 2009, at 08:53, Pawel Jakub Dawidek wrote: > On Mon, Aug 17, 2009 at 05:24:47PM +0200, Thomas Backman wrote: > [...] >> Worse yet: >> >> [root@chaos ~]# zpool create testpool ad0s1d >> [root@chaos ~]# zpool export testpool >> [root@chaos ~]# zpool import testpool >> cannot import 'testpool': no such pool available > > Should be fixed in head and stable/8, could you verify that it works > for you? Yes! This solved the problem. Great job. :) I was about to say "no" after a buildkernel/installkernel did nothing, but I looked closer and noticed the #ifndef KERNEL... After rebuilding zfs, zpool, and of course nvpair (last thing I tried, figures, when I "knew" it was at fault), it works great. Both finding pools and send/ recv is restored to normal as far as I can tell. :) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 08:15:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8862A106568C for ; Thu, 20 Aug 2009 08:15:16 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6198FC65 for ; Thu, 20 Aug 2009 08:15:16 +0000 (UTC) Received: (qmail 15814 invoked from network); 20 Aug 2009 01:15:15 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.200?) (69.64.235.60) by iron2.pdx.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2009 01:15:15 -0700 From: Sean Bruno To: freebsd-current@freebsd.org Content-Type: text/plain Date: Thu, 20 Aug 2009 01:15:14 -0700 Message-Id: <1250756114.23644.8.camel@Lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: freebsd-firewire Subject: Have *you* disabled Firewire? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 08:15:16 -0000 I'm seeing evidence that the Firewire stack has been problematic for a small, but growing set of users out there. I see from a perusal of the mailing lists, that some users are disabling their Firewire stack after they cannot boot or install FreeBSD. This usually is due to a panic preceded by the message:" "run_interrupt_driven_hooks - waiting for xpt_config" This log message was added in the past to provide a diagnostic indication of a failure. If you are one of these folks who have disabled their Firewire driver, please let me know. Also get me the following: Full boot dmesg output (bootverbose) Can you load "firewire"?(in kernel? after boot via module?) Can you load "sbp"?(in kernel? after boot via module?) *anything* else you might thing is relevant? Sean From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 09:09:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED422106568C for ; Thu, 20 Aug 2009 09:09:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 764328FC68 for ; Thu, 20 Aug 2009 09:09:40 +0000 (UTC) Received: by bwz2 with SMTP id 2so3910491bwz.43 for ; Thu, 20 Aug 2009 02:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VVkH2mgdVTei+MhWSyB8OdXVnFaMh+LKPUA5P+ItbXY=; b=Eo9yd3PDiMqXy1yCupA5bzsLROdqWm9kkj3dfJymYBhtVQhp9TlBlEFXoukhU+PDn8 FBskHpc7FMCosf2+r3gSWh8V71uPaIYc88Nhzo+3WD+Ds4r4R+hjuDX6rwLE/z0w6tPi qMSpa51llD/z2VysvWvVEkmg8lI7uXtvwk5OU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Qpz81QQGb+fl1XM8WXtIAly61UFqrrIrz/P5bZC+FaXKrE3lIabgtKSqnEOEMXh4Nx 5JiW5eW8o4iJIp18K4C/wc+yoVcp6AenVL2Ycq/U84GVTgLWakCOgDAsuzloDWyYVias MWoOtrowuSF6U2QZ6oqFjYOoSqo2lGYfWLvIo= MIME-Version: 1.0 Received: by 10.204.175.73 with SMTP id w9mr5800030bkz.24.1250759378482; Thu, 20 Aug 2009 02:09:38 -0700 (PDT) In-Reply-To: <20090819191714.0c95cea7@baby-jane.lamaiziere.net> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <20090819144136.GV1292@hoeg.nl> <20090819191714.0c95cea7@baby-jane.lamaiziere.net> Date: Thu, 20 Aug 2009 13:09:38 +0400 Message-ID: From: pluknet To: Patrick Lamaiziere Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 09:09:41 -0000 2009/8/19 Patrick Lamaiziere : > Le Wed, 19 Aug 2009 18:55:39 +0400, > pluknet a =E9crit : > >> 2009/8/19 Ed Schouten : >> > * pluknet wrote: >> >> I'm not Patrik, but I saw this on two Intel boxes running on 6.2. >> >> =A0smbios.system.product=3D"S5000PAL". I didn't try the later release= s >> >> on them. >> > >> > I wouldn't mind adding non-Apple hardware to this list, but only if >> > you can tell me the following: >> > >> > - Is this piece of hardware capable of running FreeBSD/amd64? >> >> It seems so. This is a system with two Xeon 5130 populated. >> =A0 AMD Features=3D0x20000000 > > The work-around sent by Ed is only for the chipset Intel ICH (Intel > 82801H here), it disables the SMI on the legacy USB circuit. > Are you using such chipset? > No, it's like 63XXESB_3. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 09:12:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F31106568F; Thu, 20 Aug 2009 09:12:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 854E58FC57; Thu, 20 Aug 2009 09:11:59 +0000 (UTC) Received: by bwz2 with SMTP id 2so3911435bwz.43 for ; Thu, 20 Aug 2009 02:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3AISZxn3KTxMxA8pNhoRCEOmnruPyL4ZdLdXhcfZK04=; b=mCxXBirn4BfFXFYMFNfd0GR/rn//at0eRvrrXcvNZoTXiqHMsX2fDMmUD7DoKzYtOi H04/zJviVjIS/7XJH5EyiQF2fIgZf4LeJMpyJkW0Tgb/XTF6eiDDN+dZqQ0p4onM1IFt GUHjBEHlet0pAEp2RT6J9gfK44USnuwosPNCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KktSN2SMCKhqek5A7vOfPktBjk0prGAvl4NErArc2wLpHmcYQEzLLlmxt5a4ogKi1P XUGKQkDQIy2+MRgQD5+8Avy4uJnnYgkfI8q02Dh1jtfVw0l/6vjgRnEWAAB6QfhutD2G okAH3FxOGWevnrr4uz0mDjm2ulpoHne6mcyLM= MIME-Version: 1.0 Received: by 10.204.15.152 with SMTP id k24mr5831115bka.83.1250759518550; Thu, 20 Aug 2009 02:11:58 -0700 (PDT) In-Reply-To: <200908191351.49892.jhb@freebsd.org> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <200908191351.49892.jhb@freebsd.org> Date: Thu, 20 Aug 2009 13:11:58 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-current@freebsd.org, Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 09:12:00 -0000 2009/8/19 John Baldwin : > On Wednesday 19 August 2009 10:37:21 am pluknet wrote: >> 2009/8/19 Ed Schouten : >> > * Patrick Lamaiziere wrote: >> >> From time to time, I see this at boot-time on my laptop (a Macbook >> >> pro model 3,1). I'm not sure but it seems related if an USB device is >> >> plugged in one plug (strange because the internal keyboard and the >> >> touchpad are USB devices) >> > >> > So what does smbios.system.product say? (Escape to the loader prompt a= nd >> > run `show' or whatever it's called) >> >> I'm not Patrik, but I saw this on two Intel boxes running on 6.2. >> =A0smbios.system.product=3D"S5000PAL". I didn't try the later releases o= n them. > > Look for a BIOS update. =A0Your issue may be different than the MacBook i= ssue. > I know of some boxes of this sort where the hangs were resolved by a BIOS > update that included newer micrcode for certain CPUs. > Ok. Thank you for this information, John. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 09:12:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F31106568F; Thu, 20 Aug 2009 09:12:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 854E58FC57; Thu, 20 Aug 2009 09:11:59 +0000 (UTC) Received: by bwz2 with SMTP id 2so3911435bwz.43 for ; Thu, 20 Aug 2009 02:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3AISZxn3KTxMxA8pNhoRCEOmnruPyL4ZdLdXhcfZK04=; b=mCxXBirn4BfFXFYMFNfd0GR/rn//at0eRvrrXcvNZoTXiqHMsX2fDMmUD7DoKzYtOi H04/zJviVjIS/7XJH5EyiQF2fIgZf4LeJMpyJkW0Tgb/XTF6eiDDN+dZqQ0p4onM1IFt GUHjBEHlet0pAEp2RT6J9gfK44USnuwosPNCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KktSN2SMCKhqek5A7vOfPktBjk0prGAvl4NErArc2wLpHmcYQEzLLlmxt5a4ogKi1P XUGKQkDQIy2+MRgQD5+8Avy4uJnnYgkfI8q02Dh1jtfVw0l/6vjgRnEWAAB6QfhutD2G okAH3FxOGWevnrr4uz0mDjm2ulpoHne6mcyLM= MIME-Version: 1.0 Received: by 10.204.15.152 with SMTP id k24mr5831115bka.83.1250759518550; Thu, 20 Aug 2009 02:11:58 -0700 (PDT) In-Reply-To: <200908191351.49892.jhb@freebsd.org> References: <20090819150045.0e01640a@baby-jane.lamaiziere.net> <20090819141815.GU1292@hoeg.nl> <200908191351.49892.jhb@freebsd.org> Date: Thu, 20 Aug 2009 13:11:58 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-current@freebsd.org, Patrick Lamaiziere , FreeBSD Current Subject: Re: AP#1 Failed! panic y/n? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 09:12:00 -0000 2009/8/19 John Baldwin : > On Wednesday 19 August 2009 10:37:21 am pluknet wrote: >> 2009/8/19 Ed Schouten : >> > * Patrick Lamaiziere wrote: >> >> From time to time, I see this at boot-time on my laptop (a Macbook >> >> pro model 3,1). I'm not sure but it seems related if an USB device is >> >> plugged in one plug (strange because the internal keyboard and the >> >> touchpad are USB devices) >> > >> > So what does smbios.system.product say? (Escape to the loader prompt a= nd >> > run `show' or whatever it's called) >> >> I'm not Patrik, but I saw this on two Intel boxes running on 6.2. >> =A0smbios.system.product=3D"S5000PAL". I didn't try the later releases o= n them. > > Look for a BIOS update. =A0Your issue may be different than the MacBook i= ssue. > I know of some boxes of this sort where the hangs were resolved by a BIOS > update that included newer micrcode for certain CPUs. > Ok. Thank you for this information, John. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 09:22:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2584B106568E for ; Thu, 20 Aug 2009 09:22:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id B17848FC52 for ; Thu, 20 Aug 2009 09:22:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7K9M5IO026561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 12:22:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7K9M55K032234; Thu, 20 Aug 2009 12:22:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7K9M5oh032233; Thu, 20 Aug 2009 12:22:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 20 Aug 2009 12:22:05 +0300 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20090820092205.GN9623@deviant.kiev.zoral.com.ua> References: <6359C817-0D09-4BBC-95A3-5F9226EA8706@mac.com> <5E3EBBE8-4A7D-4335-B814-8E70EA1CC81B@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0yP1TEATOxPughaP" Content-Disposition: inline In-Reply-To: <5E3EBBE8-4A7D-4335-B814-8E70EA1CC81B@mac.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: ZFS regression: Giant lock held by kldload syscall (panic: witness_warn) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 09:22:11 -0000 --0yP1TEATOxPughaP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 19, 2009 at 07:12:06PM -0700, Marcel Moolenaar wrote: >=20 > On Aug 19, 2009, at 6:53 PM, Marcel Moolenaar wrote: >=20 > >All, > > > >I can't boot with ZFS enabled on my ia64 box: >=20 > On top of that, the pool became unavailable. Importing the > pool resulted in an immediate panic again: >=20 > hob# zpool import rel > panic: mutex Giant owned at /nfs/freebsd/base/head/sys/kern/=20 > kern_exit.c:131 > cpuid =3D 0 > KDB: enter: panic > [thread pid 1022 tid 100090 ] > Stopped at kdb_enter+0x92: [I2] addl =20 > r14=3D0xffffffffffe1c308,gp ;; > db> bt > Tracing pid 1022 tid 100090 td 0xe000000011567220 > kdb_enter(0xe0000000046dc040, 0xe0000000046dc040, 0xe000000004317870, =20 > 0x793) at kdb_enter+0x92 > panic(0xe0000000046da148, 0xe0000000046da6b8, 0xe0000000046d5d28, =20 > 0x83) at panic+0x2f0 > _mtx_assert(0xe000000004821188, 0x0, 0xe0000000046d5d28, 0x83, =20 > 0xe0000000042c49f0) at _mtx_assert+0x200 > exit1(0xe000000011567220, 0x0, 0xe0000000042ded90, 0x48d) at exit1+0x40 > kproc_exit(0x0, 0xe0000000046d79b8, 0xe0000000117fa0f8, =20 > 0xe0000000117fa000) at kproc_exit+0x130 > spa_async_thread(0xe000000011572000, 0x1, 0xe0000000046d5ff8, 0x33e) =20 > at spa_async_thread+0x1a0 > fork_exit(0xe000000004794c20, 0xe000000011572000, 0xa0000000c5cbf550) =20 > at fork_exit+0x110 > enter_userland() at enter_userland > db> show alllocks > Process 1022 (solthread 0xe000000) thread 0xe000000011567220 (100090) > exclusive sleep mutex Giant (Giant) r =3D 1 (0xe000000004821188) locked = =20 > @ /nfs/freebsd/base/head/sys/kern/vfs_lookup.c:749 >=20 > Something likes Giant and can't just let go... Please try this patch. diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c b/sys/cddl= /compat/opensolaris/kern/opensolaris_kobj.c index c214488..d794345 100644 --- a/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c @@ -69,7 +69,7 @@ kobj_open_file_vnode(const char *file) struct thread *td =3D curthread; struct filedesc *fd; struct nameidata nd; - int error, flags; + int error, flags, vfslocked; =20 fd =3D td->td_proc->p_fd; FILEDESC_XLOCK(fd); @@ -86,11 +86,13 @@ kobj_open_file_vnode(const char *file) flags =3D FREAD | O_NOFOLLOW; NDINIT(&nd, LOOKUP, MPSAFE, UIO_SYSSPACE, file, td); error =3D vn_open_cred(&nd, &flags, 0, 0, curthread->td_ucred, NULL); - NDFREE(&nd, NDF_ONLY_PNBUF); if (error !=3D 0) return (NULL); + vfslocked =3D NDHASGIANT(&nd); + NDFREE(&nd, NDF_ONLY_PNBUF); /* We just unlock so we hold a reference. */ VOP_UNLOCK(nd.ni_vp, 0); + VFS_UNLOCK_GIANT(vfslocked); return (nd.ni_vp); } =20 --0yP1TEATOxPughaP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqNFbwACgkQC3+MBN1Mb4jV7QCgmHk75NuFb7eqB7ugDt7R3Ql+ A4IAn0IOFyHVOERz812udk50VSX7x8Us =31Ed -----END PGP SIGNATURE----- --0yP1TEATOxPughaP-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 11:26:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A61E5106568F for ; Thu, 20 Aug 2009 11:26:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 28C318FC77 for ; Thu, 20 Aug 2009 11:26:37 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-198-91.ard.bellsouth.net [72.154.198.91]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7KBQXle069793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 07:26:34 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Hans Petter Selasky In-Reply-To: <200908030926.12472.hselasky@c2i.net> References: <200908030926.12472.hselasky@c2i.net> Content-Type: text/plain Organization: FreeBSD Date: Thu, 20 Aug 2009 06:26:28 -0500 Message-Id: <1250767588.1668.4.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: Patch to address coredump slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 11:26:38 -0000 On Mon, 2009-08-03 at 09:26 +0200, Hans Petter Selasky wrote: > Hi, > > The following attached patch addresses recently slowed coredumps. > > http://perforce.freebsd.org/chv.cgi?CH=166957 > > MD5 (ukbd.c.diff) = 1e3c143942593b0ed4617d306a9d2ee2 > > cd /usr/src/sys/dev/usb/input/ > cat ukbd.c.diff | patch Can we get some version of this committed. robert. > --HPS > > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 11:38:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11DF106568C; Thu, 20 Aug 2009 11:38:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED948FC5B; Thu, 20 Aug 2009 11:38:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=6I5d2MoRAAAA:8 a=z_Wjxn8vN5UXvGiZRc4A:9 a=4McKT1jFgnSX9jm_NVQA:7 a=_wrkukHAJ5y6ZWDmBSTGw7L72woA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 242352786; Thu, 20 Aug 2009 13:38:06 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, alfred@freebsd.org Date: Thu, 20 Aug 2009 13:38:18 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200908030926.12472.hselasky@c2i.net> <1250767588.1668.4.camel@balrog.2hip.net> In-Reply-To: <1250767588.1668.4.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908201338.19413.hselasky@c2i.net> Cc: Robert Noland Subject: Re: Patch to address coredump slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 11:38:09 -0000 On Thursday 20 August 2009 13:26:28 Robert Noland wrote: > On Mon, 2009-08-03 at 09:26 +0200, Hans Petter Selasky wrote: > > Hi, > > > > The following attached patch addresses recently slowed coredumps. > > > > http://perforce.freebsd.org/chv.cgi?CH=166957 > > > > MD5 (ukbd.c.diff) = 1e3c143942593b0ed4617d306a9d2ee2 > > > > cd /usr/src/sys/dev/usb/input/ > > cat ukbd.c.diff | patch > > Can we get some version of this committed. I've sent a larger USB patchset over to Alfred. I expect it gets committed soon. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 11:44:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF724106568C; Thu, 20 Aug 2009 11:44:35 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 84CE88FC60; Thu, 20 Aug 2009 11:44:35 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-198-91.ard.bellsouth.net [72.154.198.91]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7KBiWGt069887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 07:44:32 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Hans Petter Selasky In-Reply-To: <200908201338.19413.hselasky@c2i.net> References: <200908030926.12472.hselasky@c2i.net> <1250767588.1668.4.camel@balrog.2hip.net> <200908201338.19413.hselasky@c2i.net> Content-Type: text/plain Organization: FreeBSD Date: Thu, 20 Aug 2009 06:44:26 -0500 Message-Id: <1250768666.2064.0.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, alfred@freebsd.org Subject: Re: Patch to address coredump slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 11:44:36 -0000 On Thu, 2009-08-20 at 13:38 +0200, Hans Petter Selasky wrote: > On Thursday 20 August 2009 13:26:28 Robert Noland wrote: > > On Mon, 2009-08-03 at 09:26 +0200, Hans Petter Selasky wrote: > > > Hi, > > > > > > The following attached patch addresses recently slowed coredumps. > > > > > > http://perforce.freebsd.org/chv.cgi?CH=166957 > > > > > > MD5 (ukbd.c.diff) = 1e3c143942593b0ed4617d306a9d2ee2 > > > > > > cd /usr/src/sys/dev/usb/input/ > > > cat ukbd.c.diff | patch > > > > Can we get some version of this committed. > > I've sent a larger USB patchset over to Alfred. I expect it gets committed > soon. ok, thanks. Alfred, any ETA on submission to re@? robert. > --HPS > > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 18:23:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597AD1065672 for ; Thu, 20 Aug 2009 18:23:16 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0668FC66 for ; Thu, 20 Aug 2009 18:23:15 +0000 (UTC) Received: from [192.168.5.143] (host-216-89-228-162.wlb.terranova.net [216.89.228.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTPSA id 2021F82AE; Thu, 20 Aug 2009 14:07:51 -0400 (EDT) Message-ID: <4A8D90EB.8090602@terranova.net> Date: Thu, 20 Aug 2009 14:07:39 -0400 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> In-Reply-To: <20090814175649.GB1311@michelle.cdnetworks.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.terranova.net/pgp/bofh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, Ryan Rogers Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:23:16 -0000 Pyun YongHyeon wrote: > On Thu, Aug 13, 2009 at 07:56:05PM -0700, Ryan Rogers wrote: >> Pyun YongHyeon wrote: >>> On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: >>>> Weongyo Jeong wrote: >>>>> On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >>>>>>> svn co svn://svn.freebsd.org/base/head >>>>>>> svn merge -c -193289 >>>>>>> >>>>>>> Thereafter, in the root of the repo: >>>>>>> svn up >>>>>>> svn merge >>>>>> Confirmed, running the above set of commands fixed my 88E1116 nfe >>>>>> problem >>>>>> everything works as it should now. thanks guys for the help. >>>>>> >>>>>> Sam Fourman Jr. >>>>>> >>>>>> ps. svn was WAY faster than csup, I think I am going to use svn all >>>>>> the time now. >>>>> I know that yongari@ knows what the problem is and the solution but he >>>>> could not access the internet right now due to relocation to USA. >>>>> >>>>> It looks he is busy with looking for house and etc... >>>>> >>>>> regards, >>>>> Weongyo Jeong >>>>> >>>>> >>>>> >>>> Well, the good news is that r193289 was the only thing keeping my nics >>> >from working. I was able to update to current as of today and revert >>>> that patch, and everything is working nicely now. So I'll just keep my >>>> eye on the commit logs and patch that up by hand whenever I need to >>>> update until yongari is able to get situated. >>>> >>> Would you try attached patch and let me know how it goes on your >>> box? >> The patch works great, thanks! > > Thanks for testing. > Unfortunately the change requires more testing on various > controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer > Yukon controllers as well as NVIDIA controllers. Since we are in > 8.0-BETA stage changing common PHY code at this time looks > dangerous. Before I start a bug report, I'm curious, do you think it is possible for this issue to also affect the general stability in operation of the nfe driver? I mean if nfe comes up and works fine for many days and then suddenly stops passing traffic? In both 8.0 and 7.2-STABLE some time after the beginning of June, two separate systems with two different nfe NICs started showing exactly the same issue. The 7.2-STABLE system was built from June 16th source and has a Marvell 88E1116. The 8.0-BETA2 system has a Marvell 88E1111 and is built from Aug 13th source. Both systems did not ever have this issue with code from before June (7.2-RELEASE included). Both will stop passing traffic across their nfe0 NIC randomly and require an ifconfig nfe0 down; ifconfig nfe0 up to continue. In the meantime before the interface is reset, ping says sendto no buffer space available and named starts spitting out a lot of "error sending response: not enough free resources" from the DNS queries it was in the middle of responding to. From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 19:12:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E91921065672 for ; Thu, 20 Aug 2009 19:12:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id B1FDD8FC57 for ; Thu, 20 Aug 2009 19:12:33 +0000 (UTC) Received: by rv-out-0506.google.com with SMTP id l9so122758rvb.3 for ; Thu, 20 Aug 2009 12:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Nlx3lxOZhnI7h9jTkNvzgGSGnMS46JDP5vkvsYfEf0Y=; b=xHpLISR/bn1S58OTTo+O5ZtpF0vTGgK8sUI+523Y//rY3C3l2PtL1JbL5tD5bV+PeW pAcYhN11o2v9CgDMeCqrsNs9NN2LKNxk6zrJ7EnoU41t+Qnl0d+II50QRv1/xH8GtUqm yYvssAI63rLt8ISm8/8KVrvUFMmlqwBdPQjjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=MPOe5k0/K2tsCkaulOzGZl+GAYJzD0h8cKwAZ12gQa1eYMcnQyurV5enI7huXzF4EZ lGqJj2PfK3dvyGoPAj5wJCZo4z3fNNeDOeclw0sCLuwEvbpJzeGEWHcAzc3/81GsoUtt cTHdp8S8Df0BRNBKUr9VCFu9sKh9cF5PivSm0= Received: by 10.140.131.5 with SMTP id e5mr114637rvd.205.1250795553416; Thu, 20 Aug 2009 12:12:33 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id k2sm1002469rvb.53.2009.08.20.12.12.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Aug 2009 12:12:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 20 Aug 2009 12:11:53 -0700 From: Pyun YongHyeon Date: Thu, 20 Aug 2009 12:11:53 -0700 To: Travis Mikalson Message-ID: <20090820191153.GB1262@michelle.cdnetworks.com> References: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> <4A8D90EB.8090602@terranova.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8D90EB.8090602@terranova.net> User-Agent: Mutt/1.4.2.3i Cc: Ryan Rogers , freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 19:12:34 -0000 On Thu, Aug 20, 2009 at 02:07:39PM -0400, Travis Mikalson wrote: > Pyun YongHyeon wrote: > > On Thu, Aug 13, 2009 at 07:56:05PM -0700, Ryan Rogers wrote: > >> Pyun YongHyeon wrote: > >>> On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: > >>>> Weongyo Jeong wrote: > >>>>> On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: > >>>>>>> svn co svn://svn.freebsd.org/base/head > >>>>>>> svn merge -c -193289 > >>>>>>> > >>>>>>> Thereafter, in the root of the repo: > >>>>>>> svn up > >>>>>>> svn merge > >>>>>> Confirmed, running the above set of commands fixed my 88E1116 nfe > >>>>>> problem > >>>>>> everything works as it should now. thanks guys for the help. > >>>>>> > >>>>>> Sam Fourman Jr. > >>>>>> > >>>>>> ps. svn was WAY faster than csup, I think I am going to use svn all > >>>>>> the time now. > >>>>> I know that yongari@ knows what the problem is and the solution but he > >>>>> could not access the internet right now due to relocation to USA. > >>>>> > >>>>> It looks he is busy with looking for house and etc... > >>>>> > >>>>> regards, > >>>>> Weongyo Jeong > >>>>> > >>>>> > >>>>> > >>>> Well, the good news is that r193289 was the only thing keeping my nics > >>> >from working. I was able to update to current as of today and revert > >>>> that patch, and everything is working nicely now. So I'll just keep my > >>>> eye on the commit logs and patch that up by hand whenever I need to > >>>> update until yongari is able to get situated. > >>>> > >>> Would you try attached patch and let me know how it goes on your > >>> box? > >> The patch works great, thanks! > > > > Thanks for testing. > > Unfortunately the change requires more testing on various > > controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer > > Yukon controllers as well as NVIDIA controllers. Since we are in > > 8.0-BETA stage changing common PHY code at this time looks > > dangerous. > > Before I start a bug report, I'm curious, do you think it is possible > for this issue to also affect the general stability in operation of the > nfe driver? I mean if nfe comes up and works fine for many days and then > suddenly stops passing traffic? > > In both 8.0 and 7.2-STABLE some time after the beginning of June, two > separate systems with two different nfe NICs started showing exactly the > same issue. The 7.2-STABLE system was built from June 16th source and > has a Marvell 88E1116. The 8.0-BETA2 system has a Marvell 88E1111 and is > built from Aug 13th source. Both systems did not ever have this issue > with code from before June (7.2-RELEASE included). > Sorry, I don't know. Both Marvell, vendor of PHY hardware and NIVIA , vendor of ethernet controller didn't release documentation to open source developers, so some part of code might be wrong on some controllers. I think nfe(4) didn't have code changes during that time window. e1000phy(4) received a couple changes to support LED for Yukon FE+, Yukon Ultra and Yukon Extrme. But I don't think it may cause problems on nfe(4) as the change only affects LED blinking rate. You can verify it by backing out r193291. > Both will stop passing traffic across their nfe0 NIC randomly and > require an ifconfig nfe0 down; ifconfig nfe0 up to continue. In the > meantime before the interface is reset, ping says sendto no buffer space > available and named starts spitting out a lot of "error sending > response: not enough free resources" from the DNS queries it was in the > middle of responding to. By chance are you using jumbo frame? Before digging into source code it would be even better to know which controllers you have. Just sending dmesg(1) output related with nfe(4)/e1000phy(4) would be enough to know that. From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 19:59:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E1F106568E for ; Thu, 20 Aug 2009 19:59:22 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A41F8FC6C for ; Thu, 20 Aug 2009 19:59:21 +0000 (UTC) Received: from [192.168.5.143] (host-216-89-228-162.wlb.terranova.net [216.89.228.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTPSA id 96E59851C; Thu, 20 Aug 2009 15:59:20 -0400 (EDT) Message-ID: <4A8DAB0C.7000104@terranova.net> Date: Thu, 20 Aug 2009 15:59:08 -0400 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> <4A8D90EB.8090602@terranova.net> <20090820191153.GB1262@michelle.cdnetworks.com> In-Reply-To: <20090820191153.GB1262@michelle.cdnetworks.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.terranova.net/pgp/bofh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, Ryan Rogers Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 19:59:22 -0000 Pyun YongHyeon wrote: > On Thu, Aug 20, 2009 at 02:07:39PM -0400, Travis Mikalson wrote: >> Pyun YongHyeon wrote: >>> On Thu, Aug 13, 2009 at 07:56:05PM -0700, Ryan Rogers wrote: >>>> Pyun YongHyeon wrote: >>>>> On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: >>>>>> Weongyo Jeong wrote: >>>>>>> On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >>>>>>>>> svn co svn://svn.freebsd.org/base/head >>>>>>>>> svn merge -c -193289 >>>>>>>>> >>>>>>>>> Thereafter, in the root of the repo: >>>>>>>>> svn up >>>>>>>>> svn merge >>>>>>>> Confirmed, running the above set of commands fixed my 88E1116 nfe >>>>>>>> problem >>>>>>>> everything works as it should now. thanks guys for the help. >>>>>>>> >>>>>>>> Sam Fourman Jr. >>>>>>>> >>>>>>>> ps. svn was WAY faster than csup, I think I am going to use svn all >>>>>>>> the time now. >>>>>>> I know that yongari@ knows what the problem is and the solution but he >>>>>>> could not access the internet right now due to relocation to USA. >>>>>>> >>>>>>> It looks he is busy with looking for house and etc... >>>>>>> >>>>>>> regards, >>>>>>> Weongyo Jeong >>>>>>> >>>>>>> >>>>>>> >>>>>> Well, the good news is that r193289 was the only thing keeping my nics >>>>> >from working. I was able to update to current as of today and revert >>>>>> that patch, and everything is working nicely now. So I'll just keep my >>>>>> eye on the commit logs and patch that up by hand whenever I need to >>>>>> update until yongari is able to get situated. >>>>>> >>>>> Would you try attached patch and let me know how it goes on your >>>>> box? >>>> The patch works great, thanks! >>> Thanks for testing. >>> Unfortunately the change requires more testing on various >>> controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer >>> Yukon controllers as well as NVIDIA controllers. Since we are in >>> 8.0-BETA stage changing common PHY code at this time looks >>> dangerous. >> Before I start a bug report, I'm curious, do you think it is possible >> for this issue to also affect the general stability in operation of the >> nfe driver? I mean if nfe comes up and works fine for many days and then >> suddenly stops passing traffic? >> >> In both 8.0 and 7.2-STABLE some time after the beginning of June, two >> separate systems with two different nfe NICs started showing exactly the >> same issue. The 7.2-STABLE system was built from June 16th source and >> has a Marvell 88E1116. The 8.0-BETA2 system has a Marvell 88E1111 and is >> built from Aug 13th source. Both systems did not ever have this issue >> with code from before June (7.2-RELEASE included). >> > > Sorry, I don't know. Both Marvell, vendor of PHY hardware and NIVIA > , vendor of ethernet controller didn't release documentation to > open source developers, so some part of code might be wrong on some > controllers. I think nfe(4) didn't have code changes during that > time window. e1000phy(4) received a couple changes to support LED > for Yukon FE+, Yukon Ultra and Yukon Extrme. But I don't think it > may cause problems on nfe(4) as the change only affects LED > blinking rate. You can verify it by backing out r193291. > >> Both will stop passing traffic across their nfe0 NIC randomly and >> require an ifconfig nfe0 down; ifconfig nfe0 up to continue. In the >> meantime before the interface is reset, ping says sendto no buffer space >> available and named starts spitting out a lot of "error sending >> response: not enough free resources" from the DNS queries it was in the >> middle of responding to. > > By chance are you using jumbo frame? Before digging into source > code it would be even better to know which controllers you have. > Just sending dmesg(1) output related with nfe(4)/e1000phy(4) would > be enough to know that. Not using jumbo frames, using regular 1500 MTU. On the 7.2-STABLE box: nfe0: port 0xb400-0xb407 mem 0xfeaf8000-0xfeaf8fff,0xfeaf7c00-0xfeaf7cff,0xfeaf7800-0xfeaf780f irq 20 at device 8.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 2 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe1: port 0xb080-0xb087 mem 0xfeaf6000-0xfeaf6fff,0xfeaf7400-0xfeaf74ff,0xfeaf7000-0xfeaf700f irq 21 at device 9.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 3 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto On the 8.0-BETA2 box: nfe0: port 0x1460-0x1467 mem 0xb0003000-0xb0003fff irq 23 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: port 0x3000-0x3007 mem 0xd0401000-0xd0401fff irq 52 at device 10.0 on pci128 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 20:45:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A66106568D for ; Thu, 20 Aug 2009 20:45:57 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5F48FC5B for ; Thu, 20 Aug 2009 20:45:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOP00B8G0CEMX10@asmtp027.mac.com> for freebsd-current@freebsd.org; Thu, 20 Aug 2009 13:45:54 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090820092205.GN9623@deviant.kiev.zoral.com.ua> Date: Thu, 20 Aug 2009 13:45:49 -0700 Message-id: <2CDA7720-61DE-49EB-8364-DCB6304A69FE@mac.com> References: <6359C817-0D09-4BBC-95A3-5F9226EA8706@mac.com> <5E3EBBE8-4A7D-4335-B814-8E70EA1CC81B@mac.com> <20090820092205.GN9623@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1074) Cc: FreeBSD Current Subject: Re: ZFS regression: Giant lock held by kldload syscall (panic: witness_warn) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 20:45:57 -0000 On Aug 20, 2009, at 2:22 AM, Kostik Belousov wrote: >> >> Something likes Giant and can't just let go... > > Please try this patch. Give me a day or so. The box is going through a gnome2 build right now... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 21:05:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B37F1065672; Thu, 20 Aug 2009 21:05:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDE528FC43; Thu, 20 Aug 2009 21:05:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5305546B8E; Thu, 20 Aug 2009 17:05:26 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 703488A01F; Thu, 20 Aug 2009 17:05:25 -0400 (EDT) From: John Baldwin To: FreeBSD Current Date: Thu, 20 Aug 2009 17:05:20 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908201705.21310.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 20 Aug 2009 17:05:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Warner Losh , Robert Noland Subject: [PATCH] Adjust hints matching for ACPI devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 21:05:27 -0000 This patch adjusts how the acpi0 device matches hint devices with built-in devices. First, it relaxes the matching somewhat so that if the memory and I/O ports specified in hints match a device then mismatches in IRQs or DRQs are ignored. This should fix the problem with atrtc1 devices because the ACPI-enumerated atrtc device did not include an IRQ. The second change is a hack to allow floppy drive controllers to match the hints on systems where the BIOS does not include 0x3f0 in the list of resources for the floppy drive (see the comments above fdc_isa_alloc_resources() for the gory details). This should fix the reports of the floppy controller showing up as fdc1 rather than fdc0. --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2009/08/02 14:30:16 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2009/08/20 21:00:30 @@ -1008,14 +1004,27 @@ continue; /* - * Check for matching resources. We must have at least one, - * and all resources specified have to match. + * Check for matching resources. We must have at least one match. + * Since I/O and memory resources cannot be shared, if we get a + * match on either of those, ignore any mismatches in IRQs or DRQs. * * XXX: We may want to revisit this to be more lenient and wire * as long as it gets one match. */ matches = 0; if (resource_long_value(name, unit, "port", &value) == 0) { + /* + * Floppy drive controllers are notorious for having a + * wide variety of resources not all of which include the + * first port that is specified by the hint (typically + * 0x3f0) (see the comment above fdc_isa_alloc_resources() + * in fdc_isa.c). However, they do all seem to include + * port + 2 (e.g. 0x3f2) so for a floppy device, look for + * 'value + 2' in the port resources instead of the hint + * value. + */ + if (strcmp(name, "fdc") == 0) + value += 2; if (acpi_match_resource_hint(child, SYS_RES_IOPORT, value)) matches++; else @@ -1027,6 +1036,8 @@ else continue; } + if (matches > 0) + goto matched; if (resource_long_value(name, unit, "irq", &value) == 0) { if (acpi_match_resource_hint(child, SYS_RES_IRQ, value)) matches++; @@ -1040,6 +1051,7 @@ continue; } + matched: if (matches > 0) { /* We have a winner! */ *unitp = unit; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 21:55:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFF5106564A for ; Thu, 20 Aug 2009 21:55:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 690A48FC16 for ; Thu, 20 Aug 2009 21:55:03 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MeFb4-0005jx-CF for freebsd-current@freebsd.org; Thu, 20 Aug 2009 23:55:02 +0200 Received: from dslb-094-222-063-132.pools.arcor-ip.net ([94.222.63.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Aug 2009 23:55:02 +0200 Received: from js by dslb-094-222-063-132.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Aug 2009 23:55:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Thu, 20 Aug 2009 23:51:12 +0200 Lines: 30 Message-ID: <87hbw2gnn3.fsf@tabernacle.localhost> References: <1250756114.23644.8.camel@Lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dslb-094-222-063-132.pools.arcor-ip.net User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:M/R+zdd7rUYAQWxqEZw4fMTVnMk= Sender: news Cc: freebsd-firewire@freebsd.org Subject: Re: Have *you* disabled Firewire? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 21:55:03 -0000 Sean Bruno writes: > I'm seeing evidence that the Firewire stack has been problematic for a > small, but growing set of users out there. I see from a perusal of the > mailing lists, that some users are disabling their Firewire stack after > they cannot boot or install FreeBSD. This usually is due to a panic > preceded by the message:" > "run_interrupt_driven_hooks - waiting for xpt_config" Panic? Most people reported hangs, haven't they? > This log message was added in the past to provide a diagnostic > indication of a failure. > > If you are one of these folks who have disabled their Firewire driver, > please let me know. Also get me the following: > Full boot dmesg output (bootverbose) > Can you load "firewire"?(in kernel? after boot via module?) > Can you load "sbp"?(in kernel? after boot via module?) > *anything* else you might thing is relevant? I did provide this some months ago for my AMD 780G-based board. Was there anything that looked suspicious? Is it worth retrying? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Thu Aug 20 23:22:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D832106564A for ; Thu, 20 Aug 2009 23:22:46 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 817AA8FC62 for ; Thu, 20 Aug 2009 23:22:44 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n7KNMcUM026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Aug 2009 09:22:39 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1250810559; bh=sYbaECv5d5R/bBiKKe8xV8S7n+wWhSpfUmHf4ooeEdE=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=UPZlfC83Xv10tlxi8JWcZV6YD09OKUGRMgYJVRDFj2pQ2PX9wVh3ya9CmXcxz1RLp CfpKpad+/ZsHQG6fCQo9rUOknIzbpzNkA++b3TyOpN2TDCL98FVr8U8VBc7lpcR2a8 6ZCeb1cwWOcfv6UdADzamx+b7vHOLlcxQW57Q3S0= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n7KNMcIJ021271 for ; Fri, 21 Aug 2009 09:22:38 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n7KNMbE6021270 for freebsd-current@freebsd.org; Fri, 21 Aug 2009 09:22:37 +1000 (AEST) (envelope-from john) Date: Fri, 21 Aug 2009 09:22:37 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090820232237.GH2675@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="krsqJi1PDCheOQxO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Heimdal in 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:22:46 -0000 --krsqJi1PDCheOQxO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is there a good reason why we don't include the current Heimdal 1.2.1 release with the FreeBSD 8.0 base? Heimdal 1.2.1 was released just over 12 months ago and includes fixes to the 1.1.0 version which is currently included with FreeBSD 8.0. I was not able to get gssapi authentication working with an OpenLDAP server on an 8.0-BETA2 server until I installed Heimdal 1.2.1 (via a hacked port) and re-built OpenLDAP against that. --=20 John Marshall --krsqJi1PDCheOQxO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkqN2r0ACgkQw/tAaKKahKJv7QCfUO+M2gIWIUeK/B6bJk/ua/Qs 1JMAoLEGnHa94AYFBauxuNScVKM6HuEU =O5Oc -----END PGP SIGNATURE----- --krsqJi1PDCheOQxO-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 02:16:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C818106568C for ; Fri, 21 Aug 2009 02:16:45 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0857A8FC55 for ; Fri, 21 Aug 2009 02:16:44 +0000 (UTC) Received: by fxm6 with SMTP id 6so234498fxm.43 for ; Thu, 20 Aug 2009 19:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=W/XYso6A47KXxBPa+F2Q0GfQPzV3e76BDwPXmaASniM=; b=ML9b8+5YZ6cS+HMBZsBxzboj3QqMfl0dCI6N0locI76sD65lcWCFmW/U9CYYH8IYnn apuGOE53x4aYTJbQoQEJikOM/t7e96v1XXQvc5gsCtQMXoWEujkjRNXxzT5au0h9TDL9 iHmO1/3lJxVgUl/xrUBFu3SN60qk4tUxElpB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xe4lMc8i6padJjcKBxYPO1r7eSn/PVEhw6ebGS37rfLIQMtxTQLj/8sVi/0uRCpdlJ xecvdar79Iq23u+6f9FE5bA0gwHU9pttKBNPHBQSjf30zQorg3aEyKR79TkaxkkPxZis pt3xmnRDjgskin23dYbG0Sd7rgltIQGY1DT04= MIME-Version: 1.0 Received: by 10.223.81.65 with SMTP id w1mr113546fak.46.1250821003313; Thu, 20 Aug 2009 19:16:43 -0700 (PDT) Date: Thu, 20 Aug 2009 21:16:43 -0500 Message-ID: <2d1264630908201916od427177kc5dd5fc699e93096@mail.gmail.com> From: Jason Harmening To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 Aug 2009 02:29:56 +0000 Cc: Subject: Fatal trap 30 w/ latest 8.0-BETA2/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 02:16:45 -0000 Sorry for the partial dump--I don't (yet) have a swap partition, so I can't do postmortem: Machine is nehalem (4 cores + HT): FreeBSD riviera.austin.rr.com 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Thu Aug 20 09:06:25 CDT 2009 jason@riviera.austin.rr.com:/usr/obj/usr/src/sys/CUSTOM amd64 current process = 11 (idle: cpu1) [Thread pid 11 tid 100009 ] Stopped at acpi_cpu_c1+0x6: popq %rbp Tracing pid 11 tid 100009 td 0xffffff000169dab0 acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x13b cpu_idle_acpi() at cpu_idle_acpi+0x1f cpu_idle() at cpu_idle+0x1c sched_idletd() at sched_idletd+0x258 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000076d30, rbp = 0 From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 06:51:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA763106568D; Fri, 21 Aug 2009 06:51:28 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8078FC51; Fri, 21 Aug 2009 06:51:28 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:42236 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MeNxn-0004Gm-5m; Fri, 21 Aug 2009 08:51:05 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 270CE38FB; Fri, 21 Aug 2009 08:51:02 +0200 (CEST) Message-Id: <7F161876-8DA7-4617-98B6-7CD54C691BC6@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 08:51:00 +0200 X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MeNxn-0004Gm-5m. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MeNxn-0004Gm-5m 81ae9bf9b580978506f89afbb1dff361 Cc: freebsd-fs@freebsd.org Subject: Yet another ZFS recv panic; old but rarely seen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 06:51:28 -0000 Ugh. Bad news again: another zfs send/recv panic during an incremental backup. Unread portion of the kernel message buffer: panic: dirtying dbuf obj=b213 lvl=1 blkid=2 but not tx_held cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 dmu_tx_dirty_buf() at dmu_tx_dirty_buf+0x28f dbuf_dirty() at dbuf_dirty+0x69 dnode_free_range() at dnode_free_range+0x80d dnode_reallocate() at dnode_reallocate+0x131 dmu_object_reclaim() at dmu_object_reclaim+0x99 dmu_recv_stream() at dmu_recv_stream+0x1446 zfs_ioc_recv() at zfs_ioc_recv+0x25a zfsdev_ioctl() at zfsdev_ioctl+0x8a devfs_ioctl_f() at devfs_ioctl_f+0x77 kern_ioctl() at kern_ioctl+0xf6ioctl() at ioctl+0xfd syscall() at syscall+0x28f Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800fe5f7c, rsp = 0x7fffffff8fb8, rbp = 0x7fffffff9cf0 --- KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 4h52m26s Looks *eerily* similar to this panic fron OpenSolaris: http://mail.opensolaris.org/pipermail/zfs-code/2008-September/000694.html GDB backtrace isn't of that much more use, I guess: #11 0xffffffff8036d02b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:562 #12 0xffffffff80b4765f in dmu_tx_dirty_buf () from /boot/kernel/zfs.ko #13 0xffffffff80b3a519 in dbuf_dirty () from /boot/kernel/zfs.ko #14 0xffffffff80b4b68d in dnode_free_range () from /boot/kernel/zfs.ko #15 0xffffffff80b4c461 in dnode_reallocate () from /boot/kernel/zfs.ko #16 0xffffffff80b42569 in dmu_object_reclaim () from /boot/kernel/zfs.ko #17 0xffffffff80b421b6 in dmu_recv_stream () from /boot/kernel/zfs.ko #18 0xffffffff80ba430a in zfs_ioc_recv () from /boot/kernel/zfs.ko #19 0xffffff002ac13d68 in ?? () #20 0xffffff002aa6c320 in ?? () #21 0xffffff002ae15000 in ?? () #22 0xffffff0002891400 in ?? () #23 0xffffff00028f2800 in ?? () #24 0xffffff00744a1ab8 in ?? () ... #34 0xffffff803e7fc860 in ?? () #35 0xffffffff805b699f in uma_zalloc_arg (zone=0xffffff00183c6600, udata=0xffffff00744a1000, flags=-128) at /usr/src/sys/vm/ uma_core.c:1990 Previous frame inner to this frame (corrupt stack?) (kgdb) Apparently, I've gotten this once before, at r195910 (+ patches, not such which ones at that time), on July 30th. Same DDB backtrace, same broken GDB backtrace. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 07:45:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17491065672; Fri, 21 Aug 2009 07:45:08 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2DB8FC74; Fri, 21 Aug 2009 07:45:08 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7L7j7ZP043841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 09:45:07 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250840707; bh=bqV8tYefqIlY13GtY4YAv3Zd0ADdaB9PXf4BfkB3oe0=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=ua7c8x0U8tRlKWjvfU9d7NUESMAFVvOaKtpM4dVAK2t713es3QT0CkxuH0kpl1dME gYb1Fqmrq5kT8QVru+jbi5AL7ks0VAmgJTKzmrBCAZznoGTqubB6Zolvhci+HRsnPX KY1/utmE2ImGgMMeExza5DKiUTTL5j5oyDSvlxmg= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7L7j602043840; Fri, 21 Aug 2009 09:45:06 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 09:45:06 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@freebsd.org Message-ID: <20090821074506.GT70474@acme.spoerlein.net> Mail-Followup-To: current@freebsd.org, sam@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sam@freebsd.org Subject: [regression] iwi0 with WPA on 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 07:45:08 -0000 Good evening, so I managed to bring my laptop up to 8.0 and after lots of ports recompiling I'm happy to say that it's pretty stable, but iwi0 and WPA no longer work. during boot I get: wlan0: Ethernet address: 00:15:00:22:26:61 iwi0: need multicast update callback iwi0: need multicast update callback iwi0: need multicast update callback iwi0: need multicast update callback iwi0: need multicast update callback wlan0: link state changed to DOWN wlan0: link state changed to UP and in messages we see Aug 20 21:00:04 roadrunner wpa_supplicant[481]: CTRL-EVENT-SCAN-RESULTS Aug 20 21:00:04 roadrunner wpa_supplicant[481]: Trying to associate with 00:21:27:f3:37:37 (SSID='COYOTE' freq=2417 MHz) Aug 20 21:00:04 roadrunner wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 Aug 20 21:00:04 roadrunner kernel: wlan0: link state changed to UP Aug 20 21:00:07 roadrunner wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Aug 20 21:00:07 roadrunner kernel: wlan0: link state changed to DOWN Aug 20 21:00:08 roadrunner wpa_supplicant[481]: CTRL-EVENT-SCAN-RESULTS Aug 20 21:00:08 roadrunner wpa_supplicant[481]: Trying to associate with 00:21:27:f3:37:37 (SSID='COYOTE' freq=2417 MHz) Aug 20 21:00:08 roadrunner wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 Aug 20 21:00:08 roadrunner kernel: wlan0: link state changed to UP Aug 20 21:00:11 roadrunner wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Aug 20 21:00:11 roadrunner kernel: wlan0: link state changed to DOWN Aug 20 21:00:11 roadrunner wpa_supplicant[481]: CTRL-EVENT-SCAN-RESULTS Aug 20 21:00:11 roadrunner wpa_supplicant[481]: Trying to associate with 00:21:27:f3:37:37 (SSID='COYOTE' freq=2417 MHz) Aug 20 21:00:11 roadrunner wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 Aug 20 21:00:11 roadrunner kernel: wlan0: link state changed to UP ... rc.conf has wlans_iwi0="wlan0" ifconfig_wlan0="WPA ether 00:0f:1f:1d:a3:76 ssid COYOTE" but I also tried this with # ifconfig wlan0 create wlandev iwi0 (or something like that) # /etc/rc.d/wpa_supplicant start wlan0 Any hints or ideas? Regards Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 09:47:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCDA106568C; Fri, 21 Aug 2009 09:47:46 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id E24A88FC47; Fri, 21 Aug 2009 09:47:45 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:52491 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MeQii-0004Kc-5V; Fri, 21 Aug 2009 11:47:42 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id AA636122B64; Fri, 21 Aug 2009 11:47:37 +0200 (CEST) Message-Id: <306284EA-C89C-433C-9D33-E6CF44305800@exscape.org> From: Thomas Backman To: Pawel Dawidek Jakub In-Reply-To: <7F161876-8DA7-4617-98B6-7CD54C691BC6@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 11:47:35 +0200 References: <7F161876-8DA7-4617-98B6-7CD54C691BC6@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MeQii-0004Kc-5V. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MeQii-0004Kc-5V a283eea3a8bc599c31c2e39bb1910ce5 Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Yet another ZFS recv panic; old but rarely seen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 09:47:46 -0000 On Aug 21, 2009, at 08:51, Thomas Backman wrote: > Ugh. Bad news again: another zfs send/recv panic during an > incremental backup. > > Unread portion of the kernel message buffer: > panic: dirtying dbuf obj=b213 lvl=1 blkid=2 but not tx_held > > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > dmu_tx_dirty_buf() at dmu_tx_dirty_buf+0x28f > dbuf_dirty() at dbuf_dirty+0x69 > dnode_free_range() at dnode_free_range+0x80d > dnode_reallocate() at dnode_reallocate+0x131 > dmu_object_reclaim() at dmu_object_reclaim+0x99 > dmu_recv_stream() at dmu_recv_stream+0x1446 > zfs_ioc_recv() at zfs_ioc_recv+0x25a > zfsdev_ioctl() at zfsdev_ioctl+0x8a > devfs_ioctl_f() at devfs_ioctl_f+0x77 > kern_ioctl() at kern_ioctl+0xf6ioctl() at ioctl+0xfd > syscall() at syscall+0x28f > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800fe5f7c, rsp = > 0x7fffffff8fb8, rbp = 0x7fffffff9cf0 --- > KDB: enter: panic > panic: from debugger > cpuid = 0 > Uptime: 4h52m26s > > Looks *eerily* similar to this panic fron OpenSolaris: http://mail.opensolaris.org/pipermail/zfs-code/2008-September/000694.html > > GDB backtrace isn't of that much more use, I guess: > #11 0xffffffff8036d02b in panic (fmt=Variable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:562 > #12 0xffffffff80b4765f in dmu_tx_dirty_buf () from /boot/kernel/zfs.ko > #13 0xffffffff80b3a519 in dbuf_dirty () from /boot/kernel/zfs.ko > #14 0xffffffff80b4b68d in dnode_free_range () from /boot/kernel/zfs.ko > #15 0xffffffff80b4c461 in dnode_reallocate () from /boot/kernel/zfs.ko > #16 0xffffffff80b42569 in dmu_object_reclaim () from /boot/kernel/ > zfs.ko > #17 0xffffffff80b421b6 in dmu_recv_stream () from /boot/kernel/zfs.ko > #18 0xffffffff80ba430a in zfs_ioc_recv () from /boot/kernel/zfs.ko > #19 0xffffff002ac13d68 in ?? () > #20 0xffffff002aa6c320 in ?? () > #21 0xffffff002ae15000 in ?? () > #22 0xffffff0002891400 in ?? () > #23 0xffffff00028f2800 in ?? () > #24 0xffffff00744a1ab8 in ?? () > ... > #34 0xffffff803e7fc860 in ?? () > #35 0xffffffff805b699f in uma_zalloc_arg (zone=0xffffff00183c6600, > udata=0xffffff00744a1000, flags=-128) at /usr/src/sys/vm/ > uma_core.c:1990 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Apparently, I've gotten this once before, at r195910 (+ patches, not > such which ones at that time), on July 30th. Same DDB backtrace, > same broken GDB backtrace. > > Regards, > Thomas I found some more info mere minutes after posting this (figures; that's why I prefer media where you can edit your posts!), but had other things to do. So, here's some more: OpenSolaris bug ID: 6754448 ( http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6754448 ) Fixed in build 108: http://dlc.sun.com/osol/on/downloads/b108/on-changelog-b108.html Changelogs are to be found on that page (just search for "6754448", with a history/diff link on each source file's page. Unfortunately (unless FreeBSD suffers from both, that is), they apparently fixed two bugs in the same batch, making it harder - at least for *me* - to see what changes relate to *this* panic. Still, I'm guessing this will help, unless the code is too much out of sync with OpenSolaris. I'm also guessing Pawel already knows waaaaaaay more about their system than I do (... which is about nothing), so I'll probably shut up now... ;) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 10:01:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B828106568F for ; Fri, 21 Aug 2009 10:01:01 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 062DD8FC52 for ; Fri, 21 Aug 2009 10:01:00 +0000 (UTC) Received: by alf.bsdes.net (Postfix, from userid 1001) id 676CD11A206; Fri, 21 Aug 2009 11:44:05 +0200 (CEST) Date: Fri, 21 Aug 2009 11:44:05 +0200 From: Victor Balada Diaz To: current@freebsd.org Message-ID: <20090821094404.GD59862@alf.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: kern/113885: [gmirror] [patch] improved gmirror balance algorithm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 10:01:01 -0000 Hello, Is there any chance that this code gets committed before 8.0-RELEASE? Thanks a lot. Regards. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 10:46:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7549F106568F for ; Fri, 21 Aug 2009 10:46:11 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BE408FC57 for ; Fri, 21 Aug 2009 10:46:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id B21D86D423; Fri, 21 Aug 2009 12:46:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h03g5lmnfpF4; Fri, 21 Aug 2009 12:46:07 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 08D8A6D41E; Fri, 21 Aug 2009 12:46:07 +0200 (CEST) Date: Fri, 21 Aug 2009 12:46:07 +0200 From: Rink Springer To: Victor Balada Diaz Message-ID: <20090821104606.GC4200@rink.nu> References: <20090821094404.GD59862@alf.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090821094404.GD59862@alf.bsdes.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: kern/113885: [gmirror] [patch] improved gmirror balance algorithm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 10:46:11 -0000 Hi Victor, On Fri, Aug 21, 2009 at 11:44:05AM +0200, Victor Balada Diaz wrote: > Is there any chance that this code gets committed before 8.0-RELEASE? Highly unlikely; this would be a new feature, and 8.0 is in such a late stadium of release that I'm pretty sure this will have to wait for 8.0-STABLE. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 11:00:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B099106568B; Fri, 21 Aug 2009 11:00:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 535B58FC52; Fri, 21 Aug 2009 11:00:36 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2144145C9B; Fri, 21 Aug 2009 13:00:34 +0200 (CEST) Received: from localhost (pjd-w.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6AA6645684; Fri, 21 Aug 2009 13:00:28 +0200 (CEST) Date: Fri, 21 Aug 2009 13:00:31 +0200 From: Pawel Jakub Dawidek To: Thomas Backman Message-ID: <20090821110031.GB1962@garage.freebsd.pl> References: <7F161876-8DA7-4617-98B6-7CD54C691BC6@exscape.org> <306284EA-C89C-433C-9D33-E6CF44305800@exscape.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <306284EA-C89C-433C-9D33-E6CF44305800@exscape.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Yet another ZFS recv panic; old but rarely seen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 11:00:38 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2009 at 11:47:35AM +0200, Thomas Backman wrote: > On Aug 21, 2009, at 08:51, Thomas Backman wrote: >=20 > >Ugh. Bad news again: another zfs send/recv panic during an =20 > >incremental backup. > > > >Unread portion of the kernel message buffer: > >panic: dirtying dbuf obj=3Db213 lvl=3D1 blkid=3D2 but not tx_held > > > >cpuid =3D 0 > >KDB: stack backtrace: > >db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >panic() at panic+0x182 > >dmu_tx_dirty_buf() at dmu_tx_dirty_buf+0x28f > >dbuf_dirty() at dbuf_dirty+0x69 > >dnode_free_range() at dnode_free_range+0x80d > >dnode_reallocate() at dnode_reallocate+0x131 > >dmu_object_reclaim() at dmu_object_reclaim+0x99 > >dmu_recv_stream() at dmu_recv_stream+0x1446 > >zfs_ioc_recv() at zfs_ioc_recv+0x25a > >zfsdev_ioctl() at zfsdev_ioctl+0x8a > >devfs_ioctl_f() at devfs_ioctl_f+0x77 > >kern_ioctl() at kern_ioctl+0xf6ioctl() at ioctl+0xfd > >syscall() at syscall+0x28f > >Xfast_syscall() at Xfast_syscall+0xe1 > >--- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x800fe5f7c, rsp =3D =20 > >0x7fffffff8fb8, rbp =3D 0x7fffffff9cf0 --- > >KDB: enter: panic > >panic: from debugger > >cpuid =3D 0 > >Uptime: 4h52m26s > > > >Looks *eerily* similar to this panic fron OpenSolaris:=20 > >http://mail.opensolaris.org/pipermail/zfs-code/2008-September/000694.html > > > >GDB backtrace isn't of that much more use, I guess: > >#11 0xffffffff8036d02b in panic (fmt=3DVariable "fmt" is not available. > >) > > at /usr/src/sys/kern/kern_shutdown.c:562 > >#12 0xffffffff80b4765f in dmu_tx_dirty_buf () from /boot/kernel/zfs.ko > >#13 0xffffffff80b3a519 in dbuf_dirty () from /boot/kernel/zfs.ko > >#14 0xffffffff80b4b68d in dnode_free_range () from /boot/kernel/zfs.ko > >#15 0xffffffff80b4c461 in dnode_reallocate () from /boot/kernel/zfs.ko > >#16 0xffffffff80b42569 in dmu_object_reclaim () from /boot/kernel/=20 > >zfs.ko > >#17 0xffffffff80b421b6 in dmu_recv_stream () from /boot/kernel/zfs.ko > >#18 0xffffffff80ba430a in zfs_ioc_recv () from /boot/kernel/zfs.ko > >#19 0xffffff002ac13d68 in ?? () > >#20 0xffffff002aa6c320 in ?? () > >#21 0xffffff002ae15000 in ?? () > >#22 0xffffff0002891400 in ?? () > >#23 0xffffff00028f2800 in ?? () > >#24 0xffffff00744a1ab8 in ?? () > >... > >#34 0xffffff803e7fc860 in ?? () > >#35 0xffffffff805b699f in uma_zalloc_arg (zone=3D0xffffff00183c6600, > > udata=3D0xffffff00744a1000, flags=3D-128) at /usr/src/sys/vm/=20 > >uma_core.c:1990 > >Previous frame inner to this frame (corrupt stack?) > >(kgdb) > > > >Apparently, I've gotten this once before, at r195910 (+ patches, not =20 > >such which ones at that time), on July 30th. Same DDB backtrace, =20 > >same broken GDB backtrace. > > > >Regards, > >Thomas >=20 > I found some more info mere minutes after posting this (figures; =20 > that's why I prefer media where you can edit your posts!), but had =20 > other things to do. So, here's some more: >=20 > OpenSolaris bug ID: 6754448 (=20 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6754448 ) > Fixed in build 108:=20 > http://dlc.sun.com/osol/on/downloads/b108/on-changelog-b108.html > Changelogs are to be found on that page (just search for "6754448", =20 > with a history/diff link on each source file's page. Unfortunately =20 > (unless FreeBSD suffers from both, that is), they apparently fixed two = =20 > bugs in the same batch, making it harder - at least for *me* - to see =20 > what changes relate to *this* panic. > Still, I'm guessing this will help, unless the code is too much out of = =20 > sync with OpenSolaris. > I'm also guessing Pawel already knows waaaaaaay more about their =20 > system than I do (... which is about nothing), so I'll probably shut =20 > up now... ;) Right, the bug is already fixed in OpenSolaris. If you can reproduce the problem, you might try this patch: http://people.freebsd.org/~pjd/patches/dirtying_dbuf.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKjn5PForvXbEpPzQRAiUbAJ9+4N2km8QzGfVtwzfZIjtmXBdJBwCcDJ8D +kSfuJlTH3Ban7+VTwJAAsM= =RHhz -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 08:58:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA36106568C; Fri, 21 Aug 2009 08:58:50 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id D68F98FC6B; Fri, 21 Aug 2009 08:58:49 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so139103fgb.12 for ; Fri, 21 Aug 2009 01:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:organization:x-mailer :mime-version:content-type:content-transfer-encoding; bh=9GZt899zzu5o5Oy4lXU7/EhLBWDHVFuOtoYYGxkIpIc=; b=TRl8BdBqfN2/DSDl51WJbdnqx5aBjNrqCaDdRLKwbCZnj45ctQ/b3GhRUt1Ya8k48C gtPU76ONtMc0u6kJX/uca1GtpFeN5PuaRk80JTxqLoYlxK8EuKz0v66A2hfI3d55efi5 +7RkTwFg+Ge5B/1DywglGFFzkpC7DEQKccmQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; b=fc0KT/zrfWir+8hwHPSjKEa+hbcMhBAdU66lZH+oubvyEvvp83Did3gRIssM/8WJsd oQHn/r/dxVPPVroGHN2Bqap/7eab7psGjKN4C40Ix+NKaOQ6ObUjNyhktmYw6bRZhnqC qT7pkxZvyuupILwFcBcyKFSZyi7BFtWOLzzr0= Received: by 10.86.187.27 with SMTP id k27mr682678fgf.11.1250843516920; Fri, 21 Aug 2009 01:31:56 -0700 (PDT) Received: from vlado.suse.cz (nat.scz.novell.com [213.151.88.252]) by mx.google.com with ESMTPS id l12sm1180474fgb.13.2009.08.21.01.31.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 01:31:56 -0700 (PDT) Date: Fri, 21 Aug 2009 10:31:39 +0200 From: Vladimir Botka To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= Message-ID: <20090821103139.66925eb3@vlado.suse.cz> In-Reply-To: <20090821074506.GT70474@acme.spoerlein.net> References: <20090821074506.GT70474@acme.spoerlein.net> Organization: netng.org X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.4; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 Aug 2009 11:23:17 +0000 Cc: sam@freebsd.org, current@freebsd.org Subject: Re: [regression] iwi0 with WPA on 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 08:58:50 -0000 It seems that there is no problem with WPA. The wpa_supplicant associates. You can see the message. wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 Run the wpa_supplicant with more debug info to get more information why the wpa_supplicant disconnects later. wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect Cheers, -- -vlado Vladimir Botka From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 09:55:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 269EE106568B for ; Fri, 21 Aug 2009 09:55:23 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id DB9748FC62 for ; Fri, 21 Aug 2009 09:55:22 +0000 (UTC) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id A46891C595 for ; Fri, 21 Aug 2009 11:26:25 +0200 (CEST) Message-Id: From: Fabien Thomas To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 11:25:54 +0200 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 21 Aug 2009 11:23:42 +0000 Subject: Forwarding benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabient@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 09:55:23 -0000 Hi all, Just a quick benchmark on 8.0 Beta2+ (18/08) show no regression vs 7.2. Result in FPS for 64bytes frame using Breakingpoint Elite Breakingpoint P1 === DUT === Breakingpoint P2 Stream1 : P1 -> P2 Stream2: P2 -> P1 GENERIC kernel + netisr.direct 4.11 : 236 (with 1 stream down for unknown reason) 6.3 : 248 7.2 : 350 8.0b : 352 POLLING kernel + netisr.direct 4.11 : 526 6.3 : 246 7.2 : 230 8.0b : 330 Note that the perf grow a little bit from version to version but 4.11 with polling is always a lot better. There is a lot a more in depth testing to do (HW flow tag, 10gb, lot of interface, latency ...) but it give a rough idea of the perf in the forwarding area. Regards, Fabien dmesg: CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf47 Stepping = 7 Features = 0xbfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP ,MTRR ,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x641d AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1035210752 (987 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ... em8: port 0x7000-0x701f mem 0xed700000-0xed71ffff irq 18 at device 0.0 on pci6 em8: Using MSI interrupt em8: [FILTER] em8: Ethernet address: 00:30:48:5c:40:82 pcib7: irq 19 at device 28.3 on pci0 pci8: on pcib7 em9: port 0x8000-0x801f mem 0xed800000-0xed81ffff irq 19 at device 0.0 on pci8 em9: Using MSI interrupt em9: [FILTER] em9: Ethernet address: 00:30:48:5c:40:83 From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 12:26:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F6D106568E for ; Fri, 21 Aug 2009 12:26:50 +0000 (UTC) (envelope-from viktor@cisti.cz) Received: from mx0.estimese.net (super.estimese.net [194.149.99.140]) by mx1.freebsd.org (Postfix) with ESMTP id 877888FC51 for ; Fri, 21 Aug 2009 12:26:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 80) by mx0.estimese.net with local; Fri, 21 Aug 2009 14:26:51 +0200 id 000BDC50.000000004A8E928B.00003CEE To: 000.fbsd@quip.cz Received: from 194.149.99.140 (auth. user viktor@mx.estimese.net) by webmail.estimese.net with HTTP; Fri, 21 Aug 2009 12:26:51 +0000 X-IlohaMail-Blah: viktor@mx.estimese.net X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.estimese.net) Message-ID: In-Reply-To: <4A8CBA58.3060809@quip.cz> From: "Viktor CISTICZ" Bounce-To: "Viktor CISTICZ" Errors-To: "Viktor CISTICZ" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 14:26:51 +0200 X-Mailman-Approved-At: Fri, 21 Aug 2009 12:32:51 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: GET BUF: dmamap load failure - 12 + kernel panic [was: NETIO UDP benchmark problem] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:26:50 -0000 Hello! Thanks for changing subject, this is better. Dne 20/8/2009, napsal "Miroslav Lachman" <000.fbsd@quip.cz>: >I changed subject to better describing one, because it is not problem in >netio itself. > >Viktor CISTICZ wrote: >> Hello, >> recently i have been testing two servers via crosslink. Both have >> Freebsd installed > >> >> twin1$ uname -a >> FreeBSD twin1 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Sun Aug 16 >> 22:57:29 CEST 2009 >> viktor@twin1:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 >> >> twin2$ uname -a >> FreeBSD kitt.twin2 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 22 15:05:19 >> CEST 2009 viktor@kitt.twin2:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 >> >> GEN_NO_DBG is GENERIC kernel without debugging options >> >> Twin2 is virtual machine on the same hardware as twin1, vmware used. >> >> I have this set installed on both machines > >> twin1$ pkg_info >> NetPIPE-3.7.1 A self-scaling network benchmark >> gettext-0.17_1 GNU gettext package >> gmake-3.81_3 GNU version of 'make' utility >> iperf-2.0.4 A tool to measure maximum TCP and UDP bandwidth >> libiconv-1.13.1 A character set conversion library >> libtool-2.2.6a Generic shared library support script >> netio-1.26 Network benchmark >> netperf-2.4.5 Network performance benchmarking package >> portaudit-0.5.13 Checks installed ports against a list of security >> vulnerabi >> portmaster-2.9 Manage your ports without external databases or >> languages >> screen-4.0.3_6 A multi-screen window manager >> ttcp-1.12 Benchmarking tool for analysing TCP and UDP >> performance >> unzip-5.52_5 List, test and extract compressed files in a ZIP >> archive >> >> Both machines are connected via crosslink > >> twin1# ifconfig >> igb0 : public interface >> igb1: flags=3D8843 metric 0 mtu 15= 00 >> options=3D13b >> ether 00:30:48:c8:f3:91 >> inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> twin2# ifconfig >> em0: public interface >> em1: flags=3D8843 metric 0 mtu 150= 0 >> options=3D9b >> ether 00:0c:29:4b:f1:76 >> inet 10.10.10.20 netmask 0xffffff00 broadcast 10.10.10.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> I have set up twin2 as a server for netio > >> kitt.twin2# netio -s -p 1122 >> >> And then tested from twin1 tcp test > >> twin1# netio -p 1122 -t 10.10.10.20 >> >> It was allright, i've got some results. >> >> But when I tried UDP, it failed. >> >> The server is still the same > >> kitt.twin2# netio -s -p 1122 >> >> Client >> twin1# netio -p 1122 -u 10.10.10.20 >> >> After around 1 minute, twin1 server stopped responding on public >> interface, i've been disconnected. Via remote console i could access >> the machine, it was acting normally. I could ping both interfaces. I >> could even ping from other side of crosslink, from twin2 the privat >> interface, but no reply on public interface. >> The interface was shown UP in ifconfig, no messages in /var/log/messages. >> >> Then i executed ifconfig igb1 down && ifconfig igb1 up and it worked >> again. > >Did you ifconfig down + up igb1 or igb0? As you said "server stopped >responding on public interface", but you have igb0 marked as public >interface and igb1 as private crosslink interface in ifconfig above. Server stopped responding on igb0(public interface) from outside of the box. Via igb1 there was ping response. >Are you really saying that heavy UDP load on private interface igb1 >caused freez of public interface igb0 and then kernel panic? Yeah, test was run via igb1, after it crashed, the server was not responding on public interface igb0 and crashed. > >> I have then executed netio udp test again with 2k udp packets >> >> The server is still the same > >> kitt.twin2# netio -s -p 1122 >> >> twin1# netio -p 1122 -u -b 2k 10.10.10.20 >> >> The same problem on twin1, but now it has crashed the computer > >> via remote console i could see this > >> twin1# GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> >> then it executed core dump and restarted. >> >> I am lost, thanks for any advise. > >Did you run it as root or regular user? > >Can you add output of netstat -m right before interface freez / kernel >panic? > >And last - can you reproduce it with kernel with debugging options enabled? > >Miroslav Lachman > I have done another testing, this time i've booted twin1 server with GENERIC kernel from 8.0-BETA2-amd64 and it has happened again. this is what i've done on twin1 (client), i have done it as a normal user > twin1$ netio -u -p 1122 10.10.10.20 NETIO - Network Throughput Benchmark, Version 1.26 (C) 1997-2005 Kai Uwe Rommel UDP connection established. Packet size 1k bytes: 6494 KByte/s (32%) Tx, 114228 KByte/s (73%) Rx. Packet size 2k bytes: 115122 KByte/s (0%) Tx, on kitt.twin2 (server) kitt.twin2# netio -s -p 1122 this appeared on kitt.twin2 > sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available sendto(): No buffer space available Sending to client, packet size 1k ... Receiving from client, packet size 2k ... Then twin1 stopped working and kernel panic. On another terminal on kitt.twin2 I ran (while 1, while netstat -m, while sleep 1, while end) > 67272K/12510K/79782K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines 35585/8200/43785 mbufs in use (current/cache/total) 3892/4926/8818/25600 mbuf clusters in use (current/cache/total/max) 3892/4812 mbuf+clusters out of packet secondary zone in use (current/cache) 12648/152/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 67272K/12510K/79782K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I have captured via remote console what happened on twin1 (rewritten from the picture)> twin1# the same netstat -m statistic procedure as at kitt.twin2> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 60243K/5841K/66085K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines 34079/2791/36870 mbufs in use 514/2320/2834/25600 mbuf clusters in use 0/512 mbuf +clusters out of packet secondary 12674/126/12800/12800 4k (page size) jumbo clusters in use 0/0/0/6400 9k jumbo clusters in use 0/0/0/3200 16k jumbo clusters in use 60243K/5841K/66085K bytes alocated to network .. and during the crash > twin1# Memory modified after free 0xffffff0083eb800(256) val=3Da8 @ 0xffffff00083eb818 Memory modified after free 0xffffff0083ec600(256) val=3Da8 @ 0xffffff00083ec618 there was many lines of this similar text. VC From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 13:17:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D669106568B for ; Fri, 21 Aug 2009 13:17:25 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 338CC8FC3F for ; Fri, 21 Aug 2009 13:17:25 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7LDHO9w005819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Aug 2009 15:17:24 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250860644; bh=TNoPVZ0tTt8H9AyJJ0/FGg9jQF5wbuEmF7ZmIZXXYK0=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=VmRLFnkiIR1gWB1mtpMVCutiEPxqjn9tp3epAUj35n+KG61x8JyabwaFmUsZUGjT3 q0P+GzOpBQQD7ZHn+GASF30X/t9ZIJYNFNjduBDTpskh0eHeXBISNDF6mFdn2AtZYS M8ZLd3NU/Iq7+1BY3xnyjzp+3xot13OOTY0wF/yc= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7LDHOPm005818 for current@freebsd.org; Fri, 21 Aug 2009 15:17:24 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 15:17:23 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@freebsd.org Message-ID: <20090821131723.GA91417@acme.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 13:17:25 -0000 Hello, I'm not sure this ever worked for 7.x but now I need to have the same root fs device on two machines: labels to the rescue! As I don't want to use the GEOM labels, but UFS labels, this is what I did: # tunefs -L root / (in single user) then updated /etc/fstab and rebooted The kernel does not find this filesystem, pressing ? shows only - a bunch of ufsid/* devices - lots of partition names - ntfs/System and msdosfs/HIDDEN which are other partitions on this machine. Only ufs/ comes up empty. What's my error? Regards Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 12:45:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6EE71065690 for ; Fri, 21 Aug 2009 12:45:15 +0000 (UTC) (envelope-from viktor@cisti.cz) Received: from mx0.estimese.net (super.estimese.net [194.149.99.140]) by mx1.freebsd.org (Postfix) with ESMTP id 559808FC69 for ; Fri, 21 Aug 2009 12:45:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 80) by mx0.estimese.net with local; Fri, 21 Aug 2009 14:45:18 +0200 id 000BDC4F.000000004A8E96DE.00003EAD To: 000.fbsd@quip.cz Received: from 194.149.99.140 (auth. user viktor@mx.estimese.net) by webmail.estimese.net with HTTP; Fri, 21 Aug 2009 12:45:18 +0000 X-IlohaMail-Blah: viktor@mx.estimese.net X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.estimese.net) Message-ID: <4vPdkHf5.1250858718.4294130.viktor@mx.estimese.net> In-Reply-To: <4A8CBA58.3060809@quip.cz> From: "Viktor CISTICZ" Bounce-To: "Viktor CISTICZ" Errors-To: "Viktor CISTICZ" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 14:45:18 +0200 X-Mailman-Approved-At: Fri, 21 Aug 2009 14:16:23 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: GET BUF: dmamap load failure - 12 + kernel panic [was: NETIO UDP benchmark problem] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:45:15 -0000 Sorry, forgot something. Dne 20/8/2009, napsal "Miroslav Lachman" <000.fbsd@quip.cz>: >I changed subject to better describing one, because it is not problem in >netio itself. > >Viktor CISTICZ wrote: >> Hello, >> recently i have been testing two servers via crosslink. Both have >> Freebsd installed > >> >> twin1$ uname -a >> FreeBSD twin1 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Sun Aug 16 >> 22:57:29 CEST 2009 >> viktor@twin1:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 >> >> twin2$ uname -a >> FreeBSD kitt.twin2 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 22 15:05:19 >> CEST 2009 viktor@kitt.twin2:/usr/obj/usr/src/sys/GEN_NO_DBG amd64 >> >> GEN_NO_DBG is GENERIC kernel without debugging options >> >> Twin2 is virtual machine on the same hardware as twin1, vmware used. >> >> I have this set installed on both machines > >> twin1$ pkg_info >> NetPIPE-3.7.1 A self-scaling network benchmark >> gettext-0.17_1 GNU gettext package >> gmake-3.81_3 GNU version of 'make' utility >> iperf-2.0.4 A tool to measure maximum TCP and UDP bandwidth >> libiconv-1.13.1 A character set conversion library >> libtool-2.2.6a Generic shared library support script >> netio-1.26 Network benchmark >> netperf-2.4.5 Network performance benchmarking package >> portaudit-0.5.13 Checks installed ports against a list of security >> vulnerabi >> portmaster-2.9 Manage your ports without external databases or >> languages >> screen-4.0.3_6 A multi-screen window manager >> ttcp-1.12 Benchmarking tool for analysing TCP and UDP >> performance >> unzip-5.52_5 List, test and extract compressed files in a ZIP >> archive >> >> Both machines are connected via crosslink > >> twin1# ifconfig >> igb0 : public interface >> igb1: flags=3D8843 metric 0 mtu 15= 00 >> options=3D13b >> ether 00:30:48:c8:f3:91 >> inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> twin2# ifconfig >> em0: public interface >> em1: flags=3D8843 metric 0 mtu 150= 0 >> options=3D9b >> ether 00:0c:29:4b:f1:76 >> inet 10.10.10.20 netmask 0xffffff00 broadcast 10.10.10.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> I have set up twin2 as a server for netio > >> kitt.twin2# netio -s -p 1122 >> >> And then tested from twin1 tcp test > >> twin1# netio -p 1122 -t 10.10.10.20 >> >> It was allright, i've got some results. >> >> But when I tried UDP, it failed. >> >> The server is still the same > >> kitt.twin2# netio -s -p 1122 >> >> Client >> twin1# netio -p 1122 -u 10.10.10.20 >> >> After around 1 minute, twin1 server stopped responding on public >> interface, i've been disconnected. Via remote console i could access >> the machine, it was acting normally. I could ping both interfaces. I >> could even ping from other side of crosslink, from twin2 the privat >> interface, but no reply on public interface. >> The interface was shown UP in ifconfig, no messages in /var/log/messages. >> >> Then i executed ifconfig igb1 down && ifconfig igb1 up and it worked >> again. > >Did you ifconfig down + up igb1 or igb0? As you said "server stopped >responding on public interface", but you have igb0 marked as public >interface and igb1 as private crosslink interface in ifconfig above. I did ifconfig down and up on igb0 (public interface). Then it responded again. But the second test crashed the machine completely. > >Are you really saying that heavy UDP load on private interface igb1 >caused freez of public interface igb0 and then kernel panic? > >> I have then executed netio udp test again with 2k udp packets >> >> The server is still the same > >> kitt.twin2# netio -s -p 1122 >> >> twin1# netio -p 1122 -u -b 2k 10.10.10.20 >> >> The same problem on twin1, but now it has crashed the computer > >> via remote console i could see this > >> twin1# GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> GET BUF: dmamap load failure - 12 >> >> then it executed core dump and restarted. >> >> I am lost, thanks for any advise. > >Did you run it as root or regular user? First I did run it as root on both machines. Then i ran it as normal user. REsults were the same, kernel panic. > >Can you add output of netstat -m right before interface freez / kernel >panic? > >And last - can you reproduce it with kernel with debugging options enabled? > >Miroslav Lachman > From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 12:57:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 941A21065690; Fri, 21 Aug 2009 12:57:46 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id CBF528FC52; Fri, 21 Aug 2009 12:57:45 +0000 (UTC) Received: by fxm6 with SMTP id 6so423880fxm.43 for ; Fri, 21 Aug 2009 05:57:44 -0700 (PDT) Received: by 10.103.84.25 with SMTP id m25mr456647mul.111.1250859463628; Fri, 21 Aug 2009 05:57:43 -0700 (PDT) Received: from ?27.237.21.69? (93-47-1-139.ip110.fastwebnet.it [93.47.1.139]) by mx.google.com with ESMTPS id y6sm10006113mug.40.2009.08.21.05.57.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 05:57:42 -0700 (PDT) From: Andrew Thompson To: Julian Elischer In-Reply-To: <4A84452B.4070306@elischer.org> X-Mailer: iPod Mail (7A341) References: <20090813073002.GA66860@citylink.fud.org.nz> <4A84452B.4070306@elischer.org> Message-Id: <1503C8A3-8B3C-4AE3-BC11-5A0B30F91121@fud.org.nz> Mime-Version: 1.0 (iPod Mail 7A341) Date: Fri, 21 Aug 2009 14:56:27 +0200 X-Mailman-Approved-At: Fri, 21 Aug 2009 14:16:43 +0000 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "current@freebsd.org" , Andrew Thompson , Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:57:46 -0000 On 13/08/2009, at 18:54, Julian Elischer wrote: > Andrew Thompson wrote: >> Hi, >> Here is an aesthetic patch to change the usb kernel processes to >> threads, >> this hides them from the usual 'ps' output. Please test and review. >> 1290 ?? DL 0:00.00 [usbus0] >> [lots and lots more...] >> 1309 ?? DL 0:00.00 [usbus4] >> After the patch they can be seen as kernel threads. >> PID TID COMM TDNAME CPU PRI STATE >> WCHAN 0 100000 kernel swapper 0 68 >> sleep sched 0 100009 kernel firmware taskq >> 0 92 sleep - 0 100020 kernel kqueue >> taskq 0 92 sleep - 0 100021 kernel >> acpi_task_0 0 92 sleep - 0 100022 >> kernel acpi_task_1 0 92 sleep - 0 >> 100023 kernel acpi_task_2 0 92 sleep >> - 0 100027 kernel thread taskq 0 92 >> sleep - 0 100031 kernel bwi0 taskq >> 0 16 sleep - 0 100032 kernel bwi0 >> taskq 0 16 sleep - 0 100106 >> kernel usbus0 0 20 sleep wmsg 0 >> 100107 kernel usbus0 0 16 sleep >> wmsg 0 100108 kernel usbus0 0 20 >> sleep wmsg 0 100109 kernel usbus0 >> 0 20 sleep wmsg [ ... ] >> 0 100127 kernel usbus4 0 20 sleep >> wmsg Andrew > > use kproc_kthread_add() > to create a seoarate usb process and make all the threads belong to > that process. > (kproc_kthread_add() will create a new process the first time > and add more threads to it the more it is run.) I have found a problem with this use of kproc_kthread_add where all the threads can exit (unload all hci modules) and the proc exits. On the next thread add it panics on a stale proc pointer. It may be easier just to use kthread_create which adds on proc0. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 14:28:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE97106568C for ; Fri, 21 Aug 2009 14:28:09 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3188FC62 for ; Fri, 21 Aug 2009 14:28:09 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MeV67-0001f0-C1; Fri, 21 Aug 2009 16:28:07 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeV68-000De1-Ik; Fri, 21 Aug 2009 16:28:08 +0200 To: fabient@freebsd.org From: Ian FREISLICH In-Reply-To: References: X-Attribution: BOFH Date: Fri, 21 Aug 2009 16:28:08 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: Forwarding benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:28:10 -0000 Fabien Thomas wrote: > Hi all, > > Just a quick benchmark on 8.0 Beta2+ (18/08) show no regression vs 7.2. Are these with witness copiled out of the kernel? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 14:32:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E4AA106568D; Fri, 21 Aug 2009 14:32:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 104168FC47; Fri, 21 Aug 2009 14:32:41 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-198-91.ard.bellsouth.net [72.154.198.91]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7LEWdND087087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 10:32:40 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: John Baldwin In-Reply-To: <200908201705.21310.jhb@freebsd.org> References: <200908201705.21310.jhb@freebsd.org> Content-Type: text/plain Organization: FreeBSD Date: Fri, 21 Aug 2009 09:32:33 -0500 Message-Id: <1250865154.8177.2.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Warner Losh , FreeBSD Current Subject: Re: [PATCH] Adjust hints matching for ACPI devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:32:42 -0000 On Thu, 2009-08-20 at 17:05 -0400, John Baldwin wrote: > This patch adjusts how the acpi0 device matches hint devices with built-in > devices. First, it relaxes the matching somewhat so that if the memory and > I/O ports specified in hints match a device then mismatches in IRQs or DRQs > are ignored. This should fix the problem with atrtc1 devices because the > ACPI-enumerated atrtc device did not include an IRQ. The second change is a > hack to allow floppy drive controllers to match the hints on systems where > the BIOS does not include 0x3f0 in the list of resources for the floppy drive > (see the comments above fdc_isa_alloc_resources() for the gory details). > This should fix the reports of the floppy controller showing up as fdc1 > rather than fdc0. I've restored my hints file to default and atrtc seems to DTRT now. robert. > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2009/08/02 14:30:16 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2009/08/20 21:00:30 > @@ -1008,14 +1004,27 @@ > continue; > > /* > - * Check for matching resources. We must have at least one, > - * and all resources specified have to match. > + * Check for matching resources. We must have at least one match. > + * Since I/O and memory resources cannot be shared, if we get a > + * match on either of those, ignore any mismatches in IRQs or DRQs. > * > * XXX: We may want to revisit this to be more lenient and wire > * as long as it gets one match. > */ > matches = 0; > if (resource_long_value(name, unit, "port", &value) == 0) { > + /* > + * Floppy drive controllers are notorious for having a > + * wide variety of resources not all of which include the > + * first port that is specified by the hint (typically > + * 0x3f0) (see the comment above fdc_isa_alloc_resources() > + * in fdc_isa.c). However, they do all seem to include > + * port + 2 (e.g. 0x3f2) so for a floppy device, look for > + * 'value + 2' in the port resources instead of the hint > + * value. > + */ > + if (strcmp(name, "fdc") == 0) > + value += 2; > if (acpi_match_resource_hint(child, SYS_RES_IOPORT, value)) > matches++; > else > @@ -1027,6 +1036,8 @@ > else > continue; > } > + if (matches > 0) > + goto matched; > if (resource_long_value(name, unit, "irq", &value) == 0) { > if (acpi_match_resource_hint(child, SYS_RES_IRQ, value)) > matches++; > @@ -1040,6 +1051,7 @@ > continue; > } > > + matched: > if (matches > 0) { > /* We have a winner! */ > *unitp = unit; > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 14:41:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69FD4106568B for ; Fri, 21 Aug 2009 14:41:32 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 174958FC16 for ; Fri, 21 Aug 2009 14:41:31 +0000 (UTC) Received: (qmail 87600 invoked from network); 21 Aug 2009 09:41:31 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 21 Aug 2009 09:41:31 -0500 Received: (qmail 8008 invoked by uid 2001); 21 Aug 2009 14:41:30 -0000 Date: Fri, 21 Aug 2009 09:41:30 -0500 From: "Rick C. Petty" To: current@freebsd.org Message-ID: <20090821144130.GA7873@keira.kiwi-computer.com> References: <20090821131723.GA91417@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090821131723.GA91417@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:41:32 -0000 On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Spörlein wrote: > > I'm not sure this ever worked for 7.x but now I need to have the same It sure does, for me at least: /dev/ufs/home on /home (ufs, NFS exported, local, soft-updates) /dev/ufs/mm on /mm (ufs, NFS exported, local, noatime, soft-updates) /dev/ufs/mm-flac on /mm/flac (ufs, NFS exported, local, noatime, read-only) /dev/ufs/mm-music on /mm/music (ufs, NFS exported, local, noatime, read-only) /dev/ufs/mm-video on /mm/video (ufs, NFS exported, local, noatime, soft-updates) /dev/ufs/mm-video-tv on /mm/video/tv (ufs, local, noatime, soft-updates) /dev/ufs/sw on /sw (ufs, local, noatime, soft-updates) /dev/ufs/sw-bsd on /sw/bsd (ufs, NFS exported, local, noatime, soft-updates) /dev/ufs/sw-images on /sw/images (ufs, NFS exported, local, noatime, read-only) /dev/ufs/backup on /backup (ufs, local, noatime, soft-updates) # uname -a FreeBSD myhost 7.1-STABLE FreeBSD 7.1-STABLE #26: Thu Feb 12 15:07:00 CST 2009 rick@myhost:/usr/obj/usr/src/sys/GENERIC i386 > root fs device on two machines: labels to the rescue! As I don't want to > use the GEOM labels, but UFS labels, this is what I did: These are essentially the same thing, in that glabel wraps the UFS labels. > # tunefs -L root / (in single user) > then updated /etc/fstab and rebooted Was / mounted read-write at the time? After the tunefs, you should have seen some messages on the console related to the labels. > The kernel does not find this filesystem, pressing ? shows only > - a bunch of ufsid/* devices > - lots of partition names > - ntfs/System and msdosfs/HIDDEN which are other partitions on this > machine. > > Only ufs/ comes up empty. What's my error? What version/build of FreeBSD? Are you using a GENERIC kernel? What does dmesg say? What was shown on the console when you did the tunefs? What is the output of "ffsinfo -l 1 / | grep volname"? Also show us a listing of /dev/ufs/. -- Rick C. Petty From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 14:51:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B9D1065695 for ; Fri, 21 Aug 2009 14:51:18 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id C12A78FC73 for ; Fri, 21 Aug 2009 14:51:17 +0000 (UTC) Received: from [192.168.5.143] (host-216-89-228-162.wlb.terranova.net [216.89.228.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTPSA id 4EF1A8D20; Fri, 21 Aug 2009 10:51:16 -0400 (EDT) Message-ID: <4A8EB453.8000307@terranova.net> Date: Fri, 21 Aug 2009 10:50:59 -0400 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> <4A8D90EB.8090602@terranova.net> <20090820191153.GB1262@michelle.cdnetworks.com> In-Reply-To: <20090820191153.GB1262@michelle.cdnetworks.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.terranova.net/pgp/bofh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:51:18 -0000 Pyun YongHyeon wrote: > On Thu, Aug 20, 2009 at 02:07:39PM -0400, Travis Mikalson wrote: >> Pyun YongHyeon wrote: >>> On Thu, Aug 13, 2009 at 07:56:05PM -0700, Ryan Rogers wrote: >>>> Pyun YongHyeon wrote: >>>>> On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: >>>>>> Weongyo Jeong wrote: >>>>>>> On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >>>>>>>>> svn co svn://svn.freebsd.org/base/head >>>>>>>>> svn merge -c -193289 >>>>>>>>> >>>>>>>>> Thereafter, in the root of the repo: >>>>>>>>> svn up >>>>>>>>> svn merge >>>>>>>> Confirmed, running the above set of commands fixed my 88E1116 nfe >>>>>>>> problem >>>>>>>> everything works as it should now. thanks guys for the help. >>>>>>>> >>>>>>>> Sam Fourman Jr. >>>>>>>> >>>>>>>> ps. svn was WAY faster than csup, I think I am going to use svn all >>>>>>>> the time now. >>>>>>> I know that yongari@ knows what the problem is and the solution but he >>>>>>> could not access the internet right now due to relocation to USA. >>>>>>> >>>>>>> It looks he is busy with looking for house and etc... >>>>>>> >>>>>>> regards, >>>>>>> Weongyo Jeong >>>>>>> >>>>>>> >>>>>>> >>>>>> Well, the good news is that r193289 was the only thing keeping my nics >>>>> >from working. I was able to update to current as of today and revert >>>>>> that patch, and everything is working nicely now. So I'll just keep my >>>>>> eye on the commit logs and patch that up by hand whenever I need to >>>>>> update until yongari is able to get situated. >>>>>> >>>>> Would you try attached patch and let me know how it goes on your >>>>> box? >>>> The patch works great, thanks! >>> Thanks for testing. >>> Unfortunately the change requires more testing on various >>> controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer >>> Yukon controllers as well as NVIDIA controllers. Since we are in >>> 8.0-BETA stage changing common PHY code at this time looks >>> dangerous. >> Before I start a bug report, I'm curious, do you think it is possible >> for this issue to also affect the general stability in operation of the >> nfe driver? I mean if nfe comes up and works fine for many days and then >> suddenly stops passing traffic? >> >> In both 8.0 and 7.2-STABLE some time after the beginning of June, two >> separate systems with two different nfe NICs started showing exactly the >> same issue. The 7.2-STABLE system was built from June 16th source and >> has a Marvell 88E1116. The 8.0-BETA2 system has a Marvell 88E1111 and is >> built from Aug 13th source. Both systems did not ever have this issue >> with code from before June (7.2-RELEASE included). >> > > Sorry, I don't know. Both Marvell, vendor of PHY hardware and NIVIA > , vendor of ethernet controller didn't release documentation to > open source developers, so some part of code might be wrong on some > controllers. I think nfe(4) didn't have code changes during that > time window. e1000phy(4) received a couple changes to support LED > for Yukon FE+, Yukon Ultra and Yukon Extrme. But I don't think it > may cause problems on nfe(4) as the change only affects LED > blinking rate. You can verify it by backing out r193291. > >> Both will stop passing traffic across their nfe0 NIC randomly and >> require an ifconfig nfe0 down; ifconfig nfe0 up to continue. In the >> meantime before the interface is reset, ping says sendto no buffer space >> available and named starts spitting out a lot of "error sending >> response: not enough free resources" from the DNS queries it was in the >> middle of responding to. > > By chance are you using jumbo frame? Before digging into source > code it would be even better to know which controllers you have. > Just sending dmesg(1) output related with nfe(4)/e1000phy(4) would > be enough to know that. I updated my system to RELENG_7 source from last night and tried out your patch, it hasn't had any effect on my nfe problem I'm afraid. A few hours after rebooting my nfe interface started dying and requiring a reset again. So, that answers that question. I definitely have a separate unrelated issue from the one in this thread. From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:01:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B69106564A for ; Fri, 21 Aug 2009 15:01:15 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 58B4E8FC65 for ; Fri, 21 Aug 2009 15:01:14 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MeVc8-00074Z-TC for current@freebsd.org; Fri, 21 Aug 2009 17:01:13 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeVcA-000Dg2-0b for current@freebsd.org; Fri, 21 Aug 2009 17:01:14 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Fri, 21 Aug 2009 17:01:14 +0200 Message-Id: Cc: Subject: panic: in pf_reassemble() ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:01:15 -0000 Hi So, I thought I'd run a benchmark and see how my forwarding did. I got the following panic, easily provokable: Fatal trap 9: general protection fault while in kernel mode cpuid = 10; apic id = 0a instruction pointer = 0x20:0xffffffff801bc111 stack pointer = 0x28:0xffffff81ccae46b0 frame pointer = 0x28:0xffffff81ccae4710 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (irq258: bce2) trap number = 9 panic: general protection fault cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap() at trap+0x10b calltrap() at calltrap+0x8 --- trap 0x9, rip = 0xffffffff801bc111, rsp = 0xffffff81ccae46b0, rbp = 0xffffff 81ccae4710 --- pf_reassemble() at pf_reassemble+0xb1 pf_normalize_ip() at pf_normalize_ip+0x694 pf_test() at pf_test+0x78e pf_check_in() at pf_check_in+0x39 pfil_run_hooks() at pfil_run_hooks+0x9c ip_fastforward() at ip_fastforward+0x319 ether_demux() at ether_demux+0x131 ether_input() at ether_input+0x1e0 ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x1e0 bce_intr() at bce_intr+0x398 intr_event_execute_handlers() at intr_event_execute_handlers+0x100 ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x117 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff81ccae4d30, rbp = 0 --- I also got a core, but it's totally useless: [firewall2.jnb1] ~ # kgdb -c /var/crash/vmcore.10 /boot/kernel/kernel 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"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. kgdb: kvm_read: invalid address (0xffffff009c31a460) #0 0x0000000000000000 in ?? () I can setup remote GDB and set this panic off again if there's something specific someone would like me to look at. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:17:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11464106564A for ; Fri, 21 Aug 2009 15:17:53 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C3E068FC14 for ; Fri, 21 Aug 2009 15:17:52 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MeVsE-0005Tu-U4 for freebsd-current@freebsd.org; Fri, 21 Aug 2009 17:17:50 +0200 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2009 17:17:50 +0200 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2009 17:17:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Fri, 21 Aug 2009 08:22:54 +0000 Lines: 7 Message-ID: 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: 207.155.204.151.ptr.us.xo.net User-Agent: Thunderbird 2.0.0.22 (X11/20090705) Sender: news Subject: 'shutdown now' not dropping to single user? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:17:53 -0000 I've updated two serial console only boxes recently to -current and neither of them seems to be able to drop to single user on 'shutdown now'. Anyone else seeing this issue? First box was updated Aug 16th the other Aug 18th. From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:22:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9EE3106568C for ; Fri, 21 Aug 2009 15:22:56 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 50BC28FC14 for ; Fri, 21 Aug 2009 15:22:56 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7LFMtax010148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 17:22:55 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250868175; bh=J/xTX4s10KVrdccgY0AmE6OSYSkswjY+u1QGUNeNFEw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=U/7MawHHhVOvivFPHcRvnGJmnOT4M1zv51elaA4qD7LD+gqsqv4YJbcaXIRGcXM0Y /VFPHm5T6TK8a7Pd7rwA3/hWeY1aF7/dU2LZ5IyzfzVeZwlFiFe0MA0xQ4c9oHwjwb L+6r0t5cjwXZIY20wfQfnstcBXti4yoLdzIjc4NQ= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7LFMsDv010147; Fri, 21 Aug 2009 17:22:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 17:22:54 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Drew Tomlinson Message-ID: <20090821152254.GB91417@acme.spoerlein.net> Mail-Followup-To: Drew Tomlinson , Stefan Bethke , freebsd-current@freebsd.org References: <4A8C5475.3020205@mykitchentable.net> <9598E097-F552-4E66-B53B-5EA2CDF05E4F@lassitu.de> <4A8C5CF5.2040104@mykitchentable.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8C5CF5.2040104@mykitchentable.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: How To Copy DVD to ISO File X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:22:56 -0000 On Wed, 19.08.2009 at 13:13:41 -0700, Drew Tomlinson wrote: > Stefan Bethke wrote: > > Am 19.08.2009 um 21:37 schrieb Drew Tomlinson: > >> dd: /dev/acd0: Invalid argument > >> 0+0 records in > >> 0+0 records out > >> 0 bytes transferred in 0.000132 secs (0 bytes/sec) > >> > >> I googled some more and thought that loading atapicam.ko might help. > >> But yet I get the same error when using /dev/cd0. > >> > >> So what am I doing wrong? > > > > The driver only supports reads of blocksized chunks, so: > > $ dd if=/dec/acd0 bs=2048 ... > > should work. > > Thanks! That was it. I'm usually getting snagged by some sort of > "BS"... :) recoverdisk(1) should be faster, use it like this: # touch image.iso # recoverdisk /dev/acd0 image.iso Regards, Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:24:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D841106568D for ; Fri, 21 Aug 2009 15:24:55 +0000 (UTC) (envelope-from oschonef@techfak.uni-bielefeld.de) Received: from smarthost.TechFak.Uni-Bielefeld.DE (smarthost.TechFak.Uni-Bielefeld.DE [129.70.137.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE7F8FC0A for ; Fri, 21 Aug 2009 15:24:54 +0000 (UTC) Received: from asahi.TechFak.Uni-Bielefeld.DE (asahi.TechFak.Uni-Bielefeld.DE [129.70.137.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTPS id 6D87B116; Fri, 21 Aug 2009 15:24:47 +0000 (UTC) From: oschonef@techfak.uni-bielefeld.de Date: Fri, 21 Aug 2009 17:24:47 +0200 To: Mark Atkinson Message-ID: <20090821152447.GA19795@asahi.TechFak.Uni-Bielefeld.DE> Mail-Followup-To: oschonef@techfak.uni-bielefeld.de, Mark Atkinson , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Zen: Oooommmmmmmmmmmmmmmmmmmmmmm Cc: freebsd-current@freebsd.org Subject: Re: 'shutdown now' not dropping to single user? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:24:55 -0000 Hi, Eines schoenen Tages schrieb Mark Atkinson: > I've updated two serial console only boxes recently to -current and > neither of them seems to be able to drop to single user on 'shutdown > now'. > > Anyone else seeing this issue? Yes, I have a box here which behaves the same. However, booting to single user from the loader prompt works fine. Unfortunatly I have no idea, what causes this behaviour and how to fix it :( As a work-around I added "options ALT_BREAK_TO_DEBUGGER" to my kernel, so I can reboot using serial console using "CR ~ ^r" (and don't have to call my Provider ;) Best Regards, Oliver -- -------------------------------------------------------- And remember: "To Infinity And Far Beyond ... Somehow?!" Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:27:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EDE0106568E for ; Fri, 21 Aug 2009 15:27:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id CD9B28FC0C for ; Fri, 21 Aug 2009 15:27:12 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-032-025.pools.arcor-ip.net [88.66.32.25]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MKsym-1MeW1H3IUv-000lQD; Fri, 21 Aug 2009 17:27:11 +0200 Received: (qmail 49154 invoked from network); 21 Aug 2009 15:27:11 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.200) by router.laiers.local with SMTP; 21 Aug 2009 15:27:11 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 21 Aug 2009 17:27:11 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-ARCH; KDE/4.3.0; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <200908211727.11400.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+eV4PVEFjEybd50Dknt1D7Cwkd8GV9qhwcrLT XyhK974940CG337ILdnBTvylHz9SmwZb5bvSiSbvUXPcw25b9L VH/k9v33ZX74RX8Iphqkg== Cc: Ian Freislich Subject: Re: panic: in pf_reassemble() ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:27:13 -0000 On Friday 21 August 2009 17:01:14 Ian Freislich wrote: > So, I thought I'd run a benchmark and see how my forwarding did. > I got the following panic, easily provokable: > > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 10; apic id =3D 0a > instruction pointer =3D 0x20:0xffffffff801bc111 > stack pointer =3D 0x28:0xffffff81ccae46b0 > frame pointer =3D 0x28:0xffffff81ccae4710 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 11 (irq258: bce2) > trap number =3D 9 > panic: general protection fault > cpuid =3D 10 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > trap_fatal() at trap_fatal+0x2ad > trap() at trap+0x10b > calltrap() at calltrap+0x8 > --- trap 0x9, rip =3D 0xffffffff801bc111, rsp =3D 0xffffff81ccae46b0, rbp= =3D > 0xffffff 81ccae4710 --- > pf_reassemble() at pf_reassemble+0xb1 > pf_normalize_ip() at pf_normalize_ip+0x694 Can you get me line numbers for these two? > pf_test() at pf_test+0x78e > pf_check_in() at pf_check_in+0x39 > pfil_run_hooks() at pfil_run_hooks+0x9c > ip_fastforward() at ip_fastforward+0x319 Does switching fast forward off change the situation - not that it should, = but=20 it might help with finding the culprit. > ether_demux() at ether_demux+0x131 > ether_input() at ether_input+0x1e0 > ether_demux() at ether_demux+0x6f > ether_input() at ether_input+0x1e0 > bce_intr() at bce_intr+0x398 > intr_event_execute_handlers() at intr_event_execute_handlers+0x100 > ithread_loop() at ithread_loop+0x8e > fork_exit() at fork_exit+0x117 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff81ccae4d30, rbp =3D 0 --- > > I also got a core, but it's totally useless: > > [firewall2.jnb1] ~ # kgdb -c /var/crash/vmcore.10 /boot/kernel/kernel > 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 detail= s. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > found)... Attempt to extract a component of a value that is not a structu= re > pointer. Attempt to extract a component of a value that is not a structure > pointer. Attempt to extract a component of a value that is not a structure > pointer. Attempt to extract a component of a value that is not a structure > pointer. kgdb: kvm_read: invalid address (0xffffff009c31a460) > #0 0x0000000000000000 in ?? () > > I can setup remote GDB and set this panic off again if there's > something specific someone would like me to look at. =46rom a very first glance this could be a byte order mismatch in ip_len or= the=20 like, so if you could take a look at the ip header in the involved mbufs. = =20 Anything that looks like swapped bytes. Are you using jumbo frames? Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 15:31:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E474F106568D for ; Fri, 21 Aug 2009 15:31:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id C82AB8FC20 for ; Fri, 21 Aug 2009 15:31:29 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BA078B70D0; Fri, 21 Aug 2009 08:31:29 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 1451E2D600F; Fri, 21 Aug 2009 08:31:29 -0700 (PDT) Message-ID: <4A8EBDD0.2030604@elischer.org> Date: Fri, 21 Aug 2009 08:31:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andrew Thompson References: <20090813073002.GA66860@citylink.fud.org.nz> <4A84452B.4070306@elischer.org> <1503C8A3-8B3C-4AE3-BC11-5A0B30F91121@fud.org.nz> In-Reply-To: <1503C8A3-8B3C-4AE3-BC11-5A0B30F91121@fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Andrew Thompson , Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:31:30 -0000 Andrew Thompson wrote: > On 13/08/2009, at 18:54, Julian Elischer wrote: > >> Andrew Thompson wrote: >>> Hi, >>> Here is an aesthetic patch to change the usb kernel processes to >>> threads, >>> this hides them from the usual 'ps' output. Please test and review. >>> 1290 ?? DL 0:00.00 [usbus0] >>> [lots and lots more...] >>> 1309 ?? DL 0:00.00 [usbus4] >>> After the patch they can be seen as kernel threads. >>> PID TID COMM TDNAME CPU PRI STATE >>> WCHAN 0 100000 kernel swapper 0 68 >>> sleep sched 0 100009 kernel firmware taskq >>> 0 92 sleep - 0 100020 kernel kqueue >>> taskq 0 92 sleep - 0 100021 kernel >>> acpi_task_0 0 92 sleep - 0 100022 >>> kernel acpi_task_1 0 92 sleep - 0 >>> 100023 kernel acpi_task_2 0 92 sleep >>> - 0 100027 kernel thread taskq 0 92 >>> sleep - 0 100031 kernel bwi0 taskq >>> 0 16 sleep - 0 100032 kernel bwi0 >>> taskq 0 16 sleep - 0 100106 kernel >>> usbus0 0 20 sleep wmsg 0 100107 >>> kernel usbus0 0 16 sleep wmsg 0 >>> 100108 kernel usbus0 0 20 sleep >>> wmsg 0 100109 kernel usbus0 0 20 >>> sleep wmsg [ ... ] >>> 0 100127 kernel usbus4 0 20 sleep >>> wmsg Andrew >> >> use kproc_kthread_add() >> to create a seoarate usb process and make all the threads belong to >> that process. >> (kproc_kthread_add() will create a new process the first time >> and add more threads to it the more it is run.) > > I have found a problem with this use of kproc_kthread_add where all the > threads can exit (unload all hci modules) and the proc exits. On the > next thread add it panics on a stale proc pointer. It may be easier just > to use kthread_create which adds on proc0. just make the last one out clear the proc pointer. > > Andrew > _______________________________________________ > 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 Aug 21 15:29:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65FFA1065694; Fri, 21 Aug 2009 15:29:48 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 261D28FC2B; Fri, 21 Aug 2009 15:29:48 +0000 (UTC) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id 2141322C30; Fri, 21 Aug 2009 17:29:47 +0200 (CEST) Message-Id: From: Fabien Thomas To: Ian FREISLICH In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 17:29:15 +0200 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 21 Aug 2009 15:39:48 +0000 Cc: freebsd-current@freebsd.org, fabient@freebsd.org Subject: Re: Forwarding benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:29:48 -0000 yes invariant / ddb / witness... all the debug block Le 21 ao=FBt 09 =E0 16:28, Ian FREISLICH a =E9crit : > Fabien Thomas wrote: >> Hi all, >> >> Just a quick benchmark on 8.0 Beta2+ (18/08) show no regression vs =20= >> 7.2. > > Are these with witness copiled out of the kernel? > > Ian > > -- > Ian Freislich > From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 16:07:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA831065690 for ; Fri, 21 Aug 2009 16:07:03 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id AA9118FC12 for ; Fri, 21 Aug 2009 16:07:02 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7LG70qS011662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 18:07:01 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250870821; bh=ij6DD5rNeCRiSvP9S+hG5nqpTPep9OrGnyZBO/UrnCQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=SPQSVPllamxKOvQQKf/e8yhx6DuO0zHPWD/FtOxH2MlbkOFyCE2xQXF+2ZTKIxccf dUu2lYdnPTYsD4CrzVG5qVe9z31gqgIgAf2JYcnRILSjk3FcyIDqfgZyi2+SEm6y3Q VDhQ9UaRAXXcyrHadk/NHNp2X8mEVEgj9juRZjwM= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7LG706q011661; Fri, 21 Aug 2009 18:07:00 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 18:07:00 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "Rick C. Petty" Message-ID: <20090821160700.GD91417@acme.spoerlein.net> Mail-Followup-To: "Rick C. Petty" , current@freebsd.org References: <20090821131723.GA91417@acme.spoerlein.net> <20090821144130.GA7873@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090821144130.GA7873@keira.kiwi-computer.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:07:03 -0000 On Fri, 21.08.2009 at 09:41:30 -0500, Rick C. Petty wrote: > On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Spörlein wrote: > > > > I'm not sure this ever worked for 7.x but now I need to have the same > > It sure does, for me at least: > > /dev/ufs/home on /home (ufs, NFS exported, local, soft-updates) > /dev/ufs/mm on /mm (ufs, NFS exported, local, noatime, soft-updates) > /dev/ufs/mm-flac on /mm/flac (ufs, NFS exported, local, noatime, read-only) > /dev/ufs/mm-music on /mm/music (ufs, NFS exported, local, noatime, read-only) > /dev/ufs/mm-video on /mm/video (ufs, NFS exported, local, noatime, soft-updates) > /dev/ufs/mm-video-tv on /mm/video/tv (ufs, local, noatime, soft-updates) > /dev/ufs/sw on /sw (ufs, local, noatime, soft-updates) > /dev/ufs/sw-bsd on /sw/bsd (ufs, NFS exported, local, noatime, soft-updates) > /dev/ufs/sw-images on /sw/images (ufs, NFS exported, local, noatime, read-only) > /dev/ufs/backup on /backup (ufs, local, noatime, soft-updates) Well, there's no / ... > > # tunefs -L root / (in single user) > > then updated /etc/fstab and rebooted > > Was / mounted read-write at the time? After the tunefs, you should have > seen some messages on the console related to the labels. Not quite, the dmesg spammage has been quenched in RELENG_8 and the label *did* show up in dumpfs and /dev/ufs. But I now tried again, and re-mounting the / filesystem r/w makes the label go away. So I guess I need to boot a live system first and have the label created from "outside". Now where is that USB stick ... Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 16:41:29 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 857D8106568B; Fri, 21 Aug 2009 16:41:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2458FC16; Fri, 21 Aug 2009 16:41:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n7LGentr081258; Fri, 21 Aug 2009 10:40:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 21 Aug 2009 10:41:49 -0600 (MDT) Message-Id: <20090821.104149.1723938629.imp@bsdimp.com> To: rnoland@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <1250865154.8177.2.camel@balrog.2hip.net> References: <200908201705.21310.jhb@freebsd.org> <1250865154.8177.2.camel@balrog.2hip.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: [PATCH] Adjust hints matching for ACPI devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:41:29 -0000 In message: <1250865154.8177.2.camel@balrog.2hip.net> Robert Noland writes: : On Thu, 2009-08-20 at 17:05 -0400, John Baldwin wrote: : > This patch adjusts how the acpi0 device matches hint devices with built-in : > devices. First, it relaxes the matching somewhat so that if the memory and : > I/O ports specified in hints match a device then mismatches in IRQs or DRQs : > are ignored. This should fix the problem with atrtc1 devices because the : > ACPI-enumerated atrtc device did not include an IRQ. The second change is a : > hack to allow floppy drive controllers to match the hints on systems where : > the BIOS does not include 0x3f0 in the list of resources for the floppy drive : > (see the comments above fdc_isa_alloc_resources() for the gory details). : > This should fix the reports of the floppy controller showing up as fdc1 : > rather than fdc0. : : I've restored my hints file to default and atrtc seems to DTRT now. These changes look good to me as well... I never did like the match IRQ requirement... Warner : robert. : : > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2009/08/02 14:30:16 : > +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2009/08/20 21:00:30 : > @@ -1008,14 +1004,27 @@ : > continue; : > : > /* : > - * Check for matching resources. We must have at least one, : > - * and all resources specified have to match. : > + * Check for matching resources. We must have at least one match. : > + * Since I/O and memory resources cannot be shared, if we get a : > + * match on either of those, ignore any mismatches in IRQs or DRQs. : > * : > * XXX: We may want to revisit this to be more lenient and wire : > * as long as it gets one match. : > */ : > matches = 0; : > if (resource_long_value(name, unit, "port", &value) == 0) { : > + /* : > + * Floppy drive controllers are notorious for having a : > + * wide variety of resources not all of which include the : > + * first port that is specified by the hint (typically : > + * 0x3f0) (see the comment above fdc_isa_alloc_resources() : > + * in fdc_isa.c). However, they do all seem to include : > + * port + 2 (e.g. 0x3f2) so for a floppy device, look for : > + * 'value + 2' in the port resources instead of the hint : > + * value. : > + */ : > + if (strcmp(name, "fdc") == 0) : > + value += 2; : > if (acpi_match_resource_hint(child, SYS_RES_IOPORT, value)) : > matches++; : > else : > @@ -1027,6 +1036,8 @@ : > else : > continue; : > } : > + if (matches > 0) : > + goto matched; : > if (resource_long_value(name, unit, "irq", &value) == 0) { : > if (acpi_match_resource_hint(child, SYS_RES_IRQ, value)) : > matches++; : > @@ -1040,6 +1051,7 @@ : > continue; : > } : > : > + matched: : > if (matches > 0) { : > /* We have a winner! */ : > *unitp = unit; : > : -- : Robert Noland : FreeBSD : : From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 16:42:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82BB106568E for ; Fri, 21 Aug 2009 16:42:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 766468FC23 for ; Fri, 21 Aug 2009 16:42:37 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7523C19E045; Fri, 21 Aug 2009 18:25:52 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4EB2819E043; Fri, 21 Aug 2009 18:25:50 +0200 (CEST) Message-ID: <4A8ECA8F.1070800@quip.cz> Date: Fri, 21 Aug 2009 18:25:51 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= References: <20090821131723.GA91417@acme.spoerlein.net> <20090821144130.GA7873@keira.kiwi-computer.com> <20090821160700.GD91417@acme.spoerlein.net> In-Reply-To: <20090821160700.GD91417@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Rick C. Petty" , current@freebsd.org Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:42:37 -0000 Ulrich Spörlein wrote: > On Fri, 21.08.2009 at 09:41:30 -0500, Rick C. Petty wrote: > >>On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Spörlein wrote: >> >>>I'm not sure this ever worked for 7.x but now I need to have the same >> >>It sure does, for me at least: >> >>/dev/ufs/home on /home (ufs, NFS exported, local, soft-updates) >>/dev/ufs/mm on /mm (ufs, NFS exported, local, noatime, soft-updates) >>/dev/ufs/mm-flac on /mm/flac (ufs, NFS exported, local, noatime, read-only) >>/dev/ufs/mm-music on /mm/music (ufs, NFS exported, local, noatime, read-only) >>/dev/ufs/mm-video on /mm/video (ufs, NFS exported, local, noatime, soft-updates) >>/dev/ufs/mm-video-tv on /mm/video/tv (ufs, local, noatime, soft-updates) >>/dev/ufs/sw on /sw (ufs, local, noatime, soft-updates) >>/dev/ufs/sw-bsd on /sw/bsd (ufs, NFS exported, local, noatime, soft-updates) >>/dev/ufs/sw-images on /sw/images (ufs, NFS exported, local, noatime, read-only) >>/dev/ufs/backup on /backup (ufs, local, noatime, soft-updates) > > > Well, there's no / ... > > >>># tunefs -L root / (in single user) >>>then updated /etc/fstab and rebooted >> >>Was / mounted read-write at the time? After the tunefs, you should have >>seen some messages on the console related to the labels. > > > Not quite, the dmesg spammage has been quenched in RELENG_8 and the > label *did* show up in dumpfs and /dev/ufs. But I now tried again, and > re-mounting the / filesystem r/w makes the label go away. > > So I guess I need to boot a live system first and have the label created > from "outside". Now where is that USB stick ... quip@kiwi ~/> mount /dev/ufs/2gLive on / (ufs, local, read-only) devfs on /dev (devfs, local) tank on /tank (zfs, local, noatime) This is 2GB USB flash disk. It was labeled from outside, as you guess. uname -r 7.2-RELEASE-p2 Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 18:00:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 099C2106568C for ; Fri, 21 Aug 2009 18:00:53 +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 B41188FC0C for ; Fri, 21 Aug 2009 18:00:52 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPZ9jkqDaFvL/2dsb2JhbADXOIQaBYFP X-IronPort-AV: E=Sophos;i="4.44,251,1249272000"; d="scan'208";a="45172921" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 21 Aug 2009 14:00:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 075318D4041; Fri, 21 Aug 2009 14:00:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhzEVvNqr8b0; Fri, 21 Aug 2009 14:00:49 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id C1EB48D4138; Fri, 21 Aug 2009 14:00:49 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n7LI5DH15410; Fri, 21 Aug 2009 14:05:13 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 21 Aug 2009 14:05:13 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Rick C. Petty" In-Reply-To: <20090819175029.GA90205@keira.kiwi-computer.com> Message-ID: References: <20090819161817.GA89704@keira.kiwi-computer.com> <20090819175029.GA90205@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:00:53 -0000 On Wed, 19 Aug 2009, Rick C. Petty wrote: > > This LOR doesn't seem to be reported anywhere: > >> lock order reversal: >> 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:4097 >> 2nd 0xffffff80a5129968 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:1835 >> 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:161 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x2e >> witness_checkorder() at witness_checkorder+0x81e >> __lockmgr_args() at __lockmgr_args+0xcf3 >> nfs_nget() at nfs_nget+0x1c9 >> nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc >> nfs_doio() at nfs_doio+0x617 >> nfs_bioread() at nfs_bioread+0xa9f >> nfs_readdir() at nfs_readdir+0x85 >> kern_getdirentries() at kern_getdirentries+0x12e >> getdirentries() at getdirentries+0x23 >> syscall() at syscall+0x1af >> Xfast_syscall() at Xfast_syscall+0xe1 >> --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8009d11dc, rsp = 0x7fffffffc3a8, rbp = 0x1 --- Since the 3rd one is locking a newly allocated nfs vnode (that isn't yet in the mount point list, etc), I don't think this will cause a problem and I don't see an easy way to avoid it. rick From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 18:02:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7ECA106568E for ; Fri, 21 Aug 2009 18:02:04 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFE78FC22 for ; Fri, 21 Aug 2009 18:02:03 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7LI23cH014844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 20:02:03 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250877723; bh=6JNuWctmxNtQ7OvwCxktX1m6DleV8F5ACqmr4t7ksss=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=ZXZf+rk5ZNfGsAkKSljJFENAXtyW8czWhjZFFd8249fTekqW2+eJdaf2x3t3jLuZN BLNjB31GOt2Upq79DeHZe6eDlcHQdO41lwEb4Ht3Wb7P23ZVbrcEn4tFnHUw4wsg3M DKNqfMZMGEvwAU9E/fTk/U+izwAxi2DL/mfF8vOc= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7LI23FD014843; Fri, 21 Aug 2009 20:02:03 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 20:02:02 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "Rick C. Petty" , current@freebsd.org Message-ID: <20090821180202.GE91417@acme.spoerlein.net> Mail-Followup-To: "Rick C. Petty" , current@freebsd.org References: <20090821131723.GA91417@acme.spoerlein.net> <20090821144130.GA7873@keira.kiwi-computer.com> <20090821160700.GD91417@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090821160700.GD91417@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:02:04 -0000 On Fri, 21.08.2009 at 18:07:00 +0200, Ulrich Spörlein wrote: > On Fri, 21.08.2009 at 09:41:30 -0500, Rick C. Petty wrote: > > On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Spörlein wrote: > > > # tunefs -L root / (in single user) > > > then updated /etc/fstab and rebooted > > > > Was / mounted read-write at the time? After the tunefs, you should have > > seen some messages on the console related to the labels. > > Not quite, the dmesg spammage has been quenched in RELENG_8 and the > label *did* show up in dumpfs and /dev/ufs. But I now tried again, and > re-mounting the / filesystem r/w makes the label go away. > > So I guess I need to boot a live system first and have the label created > from "outside". Now where is that USB stick ... Just to clarify, this worked. What's broken is tunefs on / in single user mode. The change is seen by dumpfs but will not survive a reboot. I guess that's ok, though. Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 18:36:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361071065695 for ; Fri, 21 Aug 2009 18:36:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.yandex.ru (forward15.yandex.ru [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id E0AC78FC0C for ; Fri, 21 Aug 2009 18:36:12 +0000 (UTC) Received: from smtp12.yandex.ru (smtp12.yandex.ru [95.108.131.191]) by forward15.yandex.ru (Yandex) with ESMTP id 5EFCEC0138 for ; Fri, 21 Aug 2009 22:36:11 +0400 (MSD) Received: from btr.properlan.net (vpn.heavennet.ru [77.72.136.194]) by smtp12.yandex.ru (Yandex) with ESMTPSA id 18AEA4CC0134 for ; Fri, 21 Aug 2009 22:36:11 +0400 (MSD) Message-ID: <4A8EE90F.4030201@yandex.ru> Date: Fri, 21 Aug 2009 22:35:59 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.22 (X11/20090821) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1250879771 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.yandex.ru Subject: SONY DSC doesn't work via usb [regression] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:36:13 -0000 Hi, All. I tried to attach my Sony DSC-W50 camera to 8.0-BETA2 and it doesn't work. First of i got following dmesg: ugen3.2: at usbus3 (disconnected) umass0: at uhub3, port 4, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry ugen3.2: at usbus3 umass0: on usbus3 umass0: RBC over CBI; quirks = 0x1000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 And da0 device sometime doesn't appear, but sometime appears. When I try to get access to da0 i'm getting I/O error: # mount_msdosfs -m 0664 -M 0775 /dev/da0 /mnt/ mount_msdosfs: /dev/da0: Input/output error So, I tried to add NO_SYNCHRONIZE_CACHE to quirks list in umass.c But it didn't resolve the problem. ugen3.2: at usbus3 umass0: on usbus3 umass0: RBC over CBI; quirks = 0x5000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) da0 device didn't appear. It seems the problem is not in USB code. Any suggestions? -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 18:38:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656071065690; Fri, 21 Aug 2009 18:38:08 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id D13A78FC18; Fri, 21 Aug 2009 18:38:07 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7LIc61O015720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 20:38:06 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1250879886; bh=nU+8HegUWpoz5tQGsDR124y9aozONNtFVoS/suyM6wE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=DmrOA9CmK4NciXRGzSMnJuIWY7daHv02xW7KUqiXsVODHtAQYlUDsTB1v8hcyXb42 jMLb98qRJI/ydcgvmNyLMs0TNQPEFKAG9LGdq6v1LuXFllXQlKDPJWlqHedvibC6rN 7c9rDvtkvBqXz8eX1cFpkWcYAWswWDQyXpmNIu0Q= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7LIc6uO015719; Fri, 21 Aug 2009 20:38:06 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 21 Aug 2009 20:38:06 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Vladimir Botka Message-ID: <20090821183806.GG91417@acme.spoerlein.net> Mail-Followup-To: Vladimir Botka , current@freebsd.org, sam@freebsd.org References: <20090821074506.GT70474@acme.spoerlein.net> <20090821103139.66925eb3@vlado.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090821103139.66925eb3@vlado.suse.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sam@freebsd.org, current@freebsd.org Subject: Re: [regression] iwi0 with WPA on 8.0 - FIXED, pilot error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:38:08 -0000 On Fri, 21.08.2009 at 10:31:39 +0200, Vladimir Botka wrote: > It seems that there is no problem with WPA. The wpa_supplicant > associates. You can see the message. > > wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 > > Run the wpa_supplicant with more debug info to get more information why > the wpa_supplicant disconnects later. > > wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect It is a combination of setting the MAC address that makes wpa_supplicant barf. These settings in rc.conf result in broken wpa_supplicant during boot: ifconfig_bfe0="up" ifconfig_iwi0="up" wlans_iwi0="wlan0" ifconfig_wlan0="WPA ether 00:0f:1f:1d:a3:76 ssid COYOTE" cloned_interfaces="lagg0" ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0" Result iwi0: timeout waiting for (null) firmware initialization to complete iwi0: could not load boot firmware (null) iwi0: timeout waiting for (null) firmware initialization to complete iwi0: could not load boot firmware (null) wlan0: Ethernet address: 00:15:00:22:26:61 iwi0: need multicast update callback iwi0: need multicast update callback iwi0: need multicast update callback wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN As you can see, wlan0 is created with the wrong MAC address and wpa_supplicant does not like different MACs on the wlanX dev and the real hardware. These settings now work. Everything is well ifconfig_bfe0="up" ifconfig_iwi0="ether 00:0f:1f:1d:a3:76 up" wlans_iwi0="wlan0" ifconfig_wlan0="WPA ssid COYOTE" cloned_interfaces="lagg0" ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0" Regards, Uli From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 19:05:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B02106564A for ; Fri, 21 Aug 2009 19:05:20 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id A19C68FC12 for ; Fri, 21 Aug 2009 19:05:19 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MeZQL-0005TU-3v; Fri, 21 Aug 2009 21:05:17 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MeZQL-000Dzg-UM; Fri, 21 Aug 2009 21:05:17 +0200 To: Max Laier From: Ian FREISLICH In-Reply-To: <200908211727.11400.max@love2party.net> References: <200908211727.11400.max@love2party.net> X-Attribution: BOFH Date: Fri, 21 Aug 2009 21:05:17 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: panic: in pf_reassemble() ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 19:05:20 -0000 Max Laier wrote: > On Friday 21 August 2009 17:01:14 Ian Freislich wrote: > > 0xffffff 81ccae4710 --- > > pf_reassemble() at pf_reassemble+0xb1 > > pf_normalize_ip() at pf_normalize_ip+0x694 > > Can you get me line numbers for these two? How? > > pf_test() at pf_test+0x78e > > pf_check_in() at pf_check_in+0x39 > > pfil_run_hooks() at pfil_run_hooks+0x9c > > ip_fastforward() at ip_fastforward+0x319 > > Does switching fast forward off change the situation - not that it > should, but it might help with finding the culprit. I'll test and let you know. I'm also running Watson's: net.isr.maxthreads=8 net.isr.direct=0 But, these didn't seem to make a difference either. > > ether_demux() at ether_demux+0x131 > > ether_input() at ether_input+0x1e0 > > ether_demux() at ether_demux+0x6f > > ether_input() at ether_input+0x1e0 > > bce_intr() at bce_intr+0x398 > > intr_event_execute_handlers() at intr_event_execute_handlers+0x100 > > ithread_loop() at ithread_loop+0x8e > > fork_exit() at fork_exit+0x117 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip =3D 0, rsp =3D 0xffffff81ccae4d30, rbp =3D 0 --- > > > > I can setup remote GDB and set this panic off again if there's > > something specific someone would like me to look at. > > From a very first glance this could be a byte order mismatch in ip_len > or the like, so if you could take a look at the ip header in the > involved mbufs. Anything that looks like swapped bytes. Are you > using jumbo frames? We're not using jumbo frames. It'll take me a while to setup a test-bed. This happened on my live routers. It panicked the first one, the carp failover and it panicked the second one. I'm away for a week now, so if I don't manage to get this done before we leave, it'll be the first thing I do when I get back. It's easily reproduceable: Mine's a 16 core amd64 with 4x bce(4) interfaces in a lagg(4) and vlans using the lagg as the parent (but I doubt that's involved). At the time there were about 180000 states + 40000 NAT states on the firewall. Limits are as high as they are because we've been up to about 430000 states in the past. pf.conf: # Options # ~~~~~~~ set timeout { \ adaptive.start 480000, \ adaptive.end 960000 \ } set state-policy if-bound set optimization normal set ruleset-optimization basic set limit states 800000 set limit frags 40000 set limit src-nodes 150000 # Normalization # ~~~~~~~~~~~~~ scrub on tun0 all fragment reassemble scrub on vlan2 all fragment reassemble scrub on vlan3 all fragment reassemble scrub on vlan4 all fragment reassemble scrub on vlan5 all fragment reassemble scrub on vlan7 all fragment reassemble scrub on vlan8 all fragment reassemble scrub on vlan9 all fragment reassemble scrub on vlan14 all fragment reassemble scrub on vlan15 all fragment reassemble scrub on vlan20 all fragment reassemble scrub on vlan21 all fragment reassemble scrub on vlan22 all fragment reassemble scrub on vlan23 all fragment reassemble scrub on vlan25 all fragment reassemble scrub on vlan26 all fragment reassemble # Queueing # ~~~~~~~~ altq on lagg0 cbq bandwidth 8Gb queue { vlan2_m_in, vlan2_m_out, default } queue vlan2_m_in bandwidth 100Mb { vlan2_in, vlan15_in } queue vlan2_m_out bandwidth 100Mb { vlan2_out, vlan15_out } queue vlan2_in bandwidth 80Mb borrow queue vlan2_out bandwidth 80Mb borrow queue vlan15_in bandwidth 20Mb queue vlan15_out bandwidth 20Mb queue default bandwidth 7176Mb cbq(default) Then use netperf from a machine on one vlan to a machine on another vlan: netperf -tUDP_STREAM -i2 -H othermachine It takes about 3 seconds to panic. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 20:10:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45852106568C for ; Fri, 21 Aug 2009 20:10:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id B0F938FC13 for ; Fri, 21 Aug 2009 20:10:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7LK9wSC050471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 23:09:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7LK9wg3004408; Fri, 21 Aug 2009 23:09:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7LK9vxT004407; Fri, 21 Aug 2009 23:09:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Aug 2009 23:09:57 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20090821200957.GC9623@deviant.kiev.zoral.com.ua> References: <20090819161817.GA89704@keira.kiwi-computer.com> <20090819175029.GA90205@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rKOd0RGqnoxbj4so" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "Rick C. Petty" , bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: various vfs LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 20:10:13 -0000 --rKOd0RGqnoxbj4so Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2009 at 02:05:13PM -0400, Rick Macklem wrote: >=20 >=20 > On Wed, 19 Aug 2009, Rick C. Petty wrote: >=20 > > > >This LOR doesn't seem to be reported anywhere: > > > >>lock order reversal: > >> 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:40= 97 > >> 2nd 0xffffff80a5129968 bufwait (bufwait) @=20 > >> /usr/src/sys/kern/vfs_bio.c:1835 > >> 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:1= 61 > >>KDB: stack backtrace: > >>db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >>_witness_debugger() at _witness_debugger+0x2e > >>witness_checkorder() at witness_checkorder+0x81e > >>__lockmgr_args() at __lockmgr_args+0xcf3 > >>nfs_nget() at nfs_nget+0x1c9 > >>nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc > >>nfs_doio() at nfs_doio+0x617 > >>nfs_bioread() at nfs_bioread+0xa9f > >>nfs_readdir() at nfs_readdir+0x85 > >>kern_getdirentries() at kern_getdirentries+0x12e > >>getdirentries() at getdirentries+0x23 > >>syscall() at syscall+0x1af > >>Xfast_syscall() at Xfast_syscall+0xe1 > >>--- syscall (196, FreeBSD ELF64, getdirentries), rip =3D 0x8009d11dc, r= sp =3D=20 > >>0x7fffffffc3a8, rbp =3D 0x1 --- >=20 > Since the 3rd one is locking a newly allocated nfs vnode (that isn't yet= =20 > in the mount point list, etc), I don't think this will cause a problem > and I don't see an easy way to avoid it. We could add LK_NOWITNESS to nfsclient/nfs_subr.c:161. --rKOd0RGqnoxbj4so Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqO/xUACgkQC3+MBN1Mb4j9iwCgiUQjQ7JZ1HFrBQmn4tSAluMQ ZjsAn24tzN3T7UY0uUU+gaRrICw3NQFq =t1dS -----END PGP SIGNATURE----- --rKOd0RGqnoxbj4so-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 20:23:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930F7106568B for ; Fri, 21 Aug 2009 20:23:59 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 3EED58FC14 for ; Fri, 21 Aug 2009 20:23:59 +0000 (UTC) Received: (qmail 84860 invoked from network); 21 Aug 2009 15:23:58 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 21 Aug 2009 15:23:58 -0500 Received: (qmail 10615 invoked by uid 2001); 21 Aug 2009 20:23:58 -0000 Date: Fri, 21 Aug 2009 15:23:58 -0500 From: "Rick C. Petty" To: current@freebsd.org Message-ID: <20090821202358.GA10290@keira.kiwi-computer.com> References: <20090821131723.GA91417@acme.spoerlein.net> <20090821144130.GA7873@keira.kiwi-computer.com> <20090821160700.GD91417@acme.spoerlein.net> <20090821180202.GE91417@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090821180202.GE91417@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 20:23:59 -0000 On Fri, Aug 21, 2009 at 08:02:02PM +0200, Ulrich Spörlein wrote: > On Fri, 21.08.2009 at 18:07:00 +0200, Ulrich Spörlein wrote: > > On Fri, 21.08.2009 at 09:41:30 -0500, Rick C. Petty wrote: > > > On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Spörlein wrote: > > > > # tunefs -L root / (in single user) > > > > then updated /etc/fstab and rebooted > > > > > > Was / mounted read-write at the time? After the tunefs, you should have > > > seen some messages on the console related to the labels. > > > > Not quite, the dmesg spammage has been quenched in RELENG_8 and the > > label *did* show up in dumpfs and /dev/ufs. But I now tried again, and > > re-mounting the / filesystem r/w makes the label go away. > > > > So I guess I need to boot a live system first and have the label created > > from "outside". Now where is that USB stick ... > > Just to clarify, this worked. > > What's broken is tunefs on / in single user mode. The change is seen by > dumpfs but will not survive a reboot. I guess that's ok, though. You didn't explain whether you had / mounted read-only or read-write. Also, it probably matters how you got into single-user mode ("shutdown now" vs. option 4 from boot2). Also, the fact that it's mounted might be the issue. I'm not sure I would claim this as "broken", although I can't see any reason a read-only mount is prevented from tuning (at least changing the volume name). -- Rick C. Petty From owner-freebsd-current@FreeBSD.ORG Fri Aug 21 20:59:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF94106568B for ; Fri, 21 Aug 2009 20:59:38 +0000 (UTC) (envelope-from barney@databus.com) Received: from mail1.acecape.com (mail1.aceinnovative.com [66.114.74.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC368FC18 for ; Fri, 21 Aug 2009 20:59:38 +0000 (UTC) Received: from pit.databus.com ([71.167.133.111]) (authenticated bits=0) by mail1.aceinnovative.com (8.13.8/8.13.8) with ESMTP id n7LKlhVu025842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Aug 2009 16:47:43 -0400 Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.3/8.14.3) with ESMTP id n7LKlhON044689; Fri, 21 Aug 2009 16:47:43 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.14.3/8.14.3/Submit) id n7LKlhwk044688; Fri, 21 Aug 2009 16:47:43 -0400 (EDT) (envelope-from barney) Date: Fri, 21 Aug 2009 16:47:42 -0400 From: Barney Wolff To: "Andrey V. Elsukov" Message-ID: <20090821204742.GA42996@pit.databus.com> References: <4A8EE90F.4030201@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8EE90F.4030201@yandex.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: SONY DSC doesn't work via usb [regression] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 20:59:38 -0000 On Fri, Aug 21, 2009 at 10:35:59PM +0400, Andrey V. Elsukov wrote: > Hi, All. > > I tried to attach my Sony DSC-W50 camera to 8.0-BETA2 and it > doesn't work. > First of i got following dmesg: > > ugen3.2: at usbus3 (disconnected) > umass0: at uhub3, port 4, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: RBC over CBI; quirks = 0x1000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 > > And da0 device sometime doesn't appear, but sometime appears. > When I try to get access to da0 i'm getting I/O error: > > # mount_msdosfs -m 0664 -M 0775 /dev/da0 /mnt/ > mount_msdosfs: /dev/da0: Input/output error On my 7-stable system, I have to use da0s1, not just da0, for an older dsc. Perhaps that will work for you. From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 01:01:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59707106568B for ; Sat, 22 Aug 2009 01:01:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7568FC1D for ; Sat, 22 Aug 2009 01:01:22 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B7BBD45C9F; Sat, 22 Aug 2009 02:28:24 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id AF6DB45C98 for ; Sat, 22 Aug 2009 02:28:19 +0200 (CEST) Date: Sat, 22 Aug 2009 02:28:22 +0200 From: Pawel Jakub Dawidek To: current@freebsd.org Message-ID: <20090822002822.GA2613@garage.freebsd.pl> References: <20090821131723.GA91417@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20090821131723.GA91417@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Subject: Re: Cannot mount / from UFS labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 01:01:23 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2009 at 03:17:23PM +0200, Ulrich Sp=F6rlein wrote: > Hello, >=20 > I'm not sure this ever worked for 7.x but now I need to have the same > root fs device on two machines: labels to the rescue! As I don't want to > use the GEOM labels, but UFS labels, this is what I did: >=20 > # tunefs -L root / (in single user) > then updated /etc/fstab and rebooted The problem is this: tunefs will write volume name into file system's superblock on the disk. Then you remount read-write and UFS will overwrite superblock with in-memory copy it picked up on first read-only mount (no vo= lume name in there). So there will be no volume name in the superblock anymore.= You can confirm that with: # tunefs -L root /dev/ad0s1a # dumpfs /dev/ad0s1a | grep volname There should be volume name here. # mount -uw / # dumpfs /dev/ad0s1a | grep volname No volume name here. You cannot remount it read-only again and use tunefs again, because this is= a bit of a hack how it works now. Only first read-only mount opens GEOM provi= der (eg. /dev/ad0s1a) for reading, but without exclusive bit. Once you remount = it the exclusive bit will be there and you will no longer be able to use tunef= s on this file system. You can confirm that with: # gpart list | grep -A3 'Name: ad0s1a' Take a look at the 'e' (exclusive) count. So what you have to do instead is to boot into single-user mode, put volume name using tunefs and reboot without remounting the file system. After the reboot, boot it again into single-user mode, remount it read-write and edit /etc/fstab. Alternatively for the second single-user mode boot you can chan= ge root provider from loader prompt with this command: OK set vfs.root.mountfrom=3D"ufs:/dev/ufs/root" OK boot And once you boot, edit /etc/fstab. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKjzumForvXbEpPzQRAsW6AKC99En9Qeu+V8AgllMIPWLw98eYCQCgo8u5 NIyt9aumzPMuMb+r4hMENaI= =rMHR -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 02:29:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B939A106564A for ; Sat, 22 Aug 2009 02:29:22 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC2A8FC19 for ; Sat, 22 Aug 2009 02:29:21 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 13so276414fge.12 for ; Fri, 21 Aug 2009 19:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7JuUTIE4/os72IW5s0yr69hx8PhPIyT7ok6/Z2xzVxk=; b=WlI93svsZ/yNcKlPVvo+HnGvXtHUuPrVmF9nIlWIg5pgXR2R1A/wYUePzAtVKhvrXT p0ifoizhVGVBpPLQm6xtcqxyk21ay4+Yjl8LN1MUjVKyaBjof8FoIzLl3O+OX0EbCnFJ u+PDeu0AVGMitkg/Gd06BG8puUAEGceDvAhgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IXDBcA52tKNHpL1MRJ3TzdUvPhOzEKQKOAEZAgIwMEYpbNkzK2wV5ZdqOenwh4XUKQ n7cCjUqF3jWoZZq/zW/yyCubWg6mk4aPTC0yoIQrzl8jCY2zH1xh0JzzPJWCjGjcIrvf FIzKFQi+/IE0bHVJmwAr2qrBWuVeTBmBFtZeo= MIME-Version: 1.0 Received: by 10.86.220.1 with SMTP id s1mr1342739fgg.50.1250908159986; Fri, 21 Aug 2009 19:29:19 -0700 (PDT) In-Reply-To: <4A8EE90F.4030201@yandex.ru> References: <4A8EE90F.4030201@yandex.ru> Date: Sat, 22 Aug 2009 04:29:19 +0200 Message-ID: <6101e8c40908211929o14691537w9f874980eb12e535@mail.gmail.com> From: Oliver Pinter To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: SONY DSC doesn't work via usb [regression] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 02:29:22 -0000 can you this probe: mount_msdosfs /dev/da0 /foo # this may fail, and after this: mount_msdosfs /dev/da0s1 /foo # and this mounter the real device On 8/21/09, Andrey V. Elsukov wrote: > Hi, All. > > I tried to attach my Sony DSC-W50 camera to 8.0-BETA2 and it > doesn't work. > First of i got following dmesg: > > ugen3.2: at usbus3 (disconnected) > umass0: at uhub3, port 4, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: RBC over CBI; quirks = 0x1000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 > > And da0 device sometime doesn't appear, but sometime appears. > When I try to get access to da0 i'm getting I/O error: > > # mount_msdosfs -m 0664 -M 0775 /dev/da0 /mnt/ > mount_msdosfs: /dev/da0: Input/output error > > So, I tried to add NO_SYNCHRONIZE_CACHE to quirks list in umass.c > But it didn't resolve the problem. > > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: RBC over CBI; quirks = 0x5000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) > > da0 device didn't appear. It seems the problem is not in USB code. > Any suggestions? > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > 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 Sat Aug 22 05:31:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AC1C106568C for ; Sat, 22 Aug 2009 05:31:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.yandex.ru (forward11.yandex.ru [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id E45028FC1A for ; Sat, 22 Aug 2009 05:31:09 +0000 (UTC) Received: from smtp15.yandex.ru (smtp15.yandex.ru [95.108.130.69]) by forward11.yandex.ru (Yandex) with ESMTP id 71DF7F483CA; Sat, 22 Aug 2009 09:31:08 +0400 (MSD) Received: from btr.properlan.net (vpn.heavennet.ru [77.72.136.194]) by smtp15.yandex.ru (Yandex) with ESMTPSA id 2F6BF4E28274; Sat, 22 Aug 2009 09:31:08 +0400 (MSD) Message-ID: <4A8F8298.2030803@yandex.ru> Date: Sat, 22 Aug 2009 09:31:04 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.22 (X11/20090821) MIME-Version: 1.0 To: Barney Wolff References: <4A8EE90F.4030201@yandex.ru> <20090821204742.GA42996@pit.databus.com> In-Reply-To: <20090821204742.GA42996@pit.databus.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1250919068 X-Yandex-Spam: 1 X-Yandex-Front: smtp15.yandex.ru Cc: freebsd-current@freebsd.org Subject: Re: SONY DSC doesn't work via usb [regression] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 05:31:10 -0000 Barney Wolff wrote: > On my 7-stable system, I have to use da0s1, not just da0, for an older > dsc. Perhaps that will work for you. Yes, It worked on 6.x and 7.x, but now it doesn't work. System doesn't see any partitions and any access to da0 returns I/O errors. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 06:13:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69B17106568C; Sat, 22 Aug 2009 06:13:24 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 2EED08FC18; Sat, 22 Aug 2009 06:13:24 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A4EEC8465; Sat, 22 Aug 2009 06:13:22 +0000 (UTC) Date: Sat, 22 Aug 2009 07:13:16 +0100 From: Bruce Cran To: John Baldwin Message-ID: <20090822071316.17a37b52@gluon.draftnet> In-Reply-To: <200908201705.21310.jhb@freebsd.org> References: <200908201705.21310.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Warner Losh , FreeBSD Current , Robert Noland Subject: Re: [PATCH] Adjust hints matching for ACPI devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 06:13:24 -0000 On Thu, 20 Aug 2009 17:05:20 -0400 John Baldwin wrote: > This patch adjusts how the acpi0 device matches hint devices with > built-in devices. First, it relaxes the matching somewhat so that if > the memory and I/O ports specified in hints match a device then > mismatches in IRQs or DRQs are ignored. This should fix the problem > with atrtc1 devices because the ACPI-enumerated atrtc device did not > include an IRQ. The second change is a hack to allow floppy drive > controllers to match the hints on systems where the BIOS does not > include 0x3f0 in the list of resources for the floppy drive (see the > comments above fdc_isa_alloc_resources() for the gory details). This > should fix the reports of the floppy controller showing up as fdc1 > rather than fdc0. Thanks - with this patch and /boot/device.hints restored fdc0 is found and attaches; /dev/fd0 is present again. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 07:16:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82CD0106568B for ; Sat, 22 Aug 2009 07:16:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id E4A328FC18 for ; Sat, 22 Aug 2009 07:16:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=EqX_-DVH5OMA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=zLqepthZrQe9WqQpH9sA:9 a=157zlDi6--NJrVeBkIEA:7 a=xvmblRjcNwqTmhyOas7EeQfmow0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1306947020; Sat, 22 Aug 2009 09:16:23 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 22 Aug 2009 09:16:34 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A8EE90F.4030201@yandex.ru> <6101e8c40908211929o14691537w9f874980eb12e535@mail.gmail.com> In-Reply-To: <6101e8c40908211929o14691537w9f874980eb12e535@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908220916.35836.hselasky@c2i.net> Cc: "Andrey V. Elsukov" , Oliver Pinter Subject: Re: SONY DSC doesn't work via usb [regression] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 07:16:25 -0000 On Saturday 22 August 2009 04:29:19 Oliver Pinter wrote: > can you this probe: > > mount_msdosfs /dev/da0 /foo # this may fail, and after this: > mount_msdosfs /dev/da0s1 /foo # and this mounter the real device > > On 8/21/09, Andrey V. Elsukov wrote: > > Hi, All. > > > > I tried to attach my Sony DSC-W50 camera to 8.0-BETA2 and it > > doesn't work. > > First of i got following dmesg: > > > > ugen3.2: at usbus3 (disconnected) > > umass0: at uhub3, port 4, addr 2 (disconnected) > > (da0:umass-sim0:0:0:0): lost device > > (da0:umass-sim0:0:0:0): removing device entry > > ugen3.2: at usbus3 > > umass0: on usbus3 > > umass0: RBC over CBI; quirks = 0x1000 > > umass0:1:0:-1: Attached to scbus1 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > > > And da0 device sometime doesn't appear, but sometime appears. > > When I try to get access to da0 i'm getting I/O error: > > > > # mount_msdosfs -m 0664 -M 0775 /dev/da0 /mnt/ > > mount_msdosfs: /dev/da0: Input/output error > > > > So, I tried to add NO_SYNCHRONIZE_CACHE to quirks list in umass.c > > But it didn't resolve the problem. > > > > ugen3.2: at usbus3 > > umass0: on usbus3 > > umass0: RBC over CBI; quirks = 0x5000 > > umass0:1:0:-1: Attached to scbus1 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C) > > > > da0 device didn't appear. It seems the problem is not in USB code. > > Any suggestions? I see there are several quirk entries for Sony cameras. Could you try to change "UMASS_PROTO_RBC | UMASS_PROTO_CBI" into "UMASS_PROTO_DEFAULT" for all DSC entries? {USB_VENDOR_SONY, USB_PRODUCT_SONY_DSC, 0x0600, UMASS_PROTO_RBC | UMASS_PROTO_CBI, RBC_PAD_TO_12 }, --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 10:04:52 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92D3106568F; Sat, 22 Aug 2009 10:04:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C83488FC13; Sat, 22 Aug 2009 10:04:52 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7B6A646B66; Sat, 22 Aug 2009 06:04:52 -0400 (EDT) Date: Sat, 22 Aug 2009 11:04:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Quick 8.0 update: BETA3 builds in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 10:04:53 -0000 For those tracking the 8.0 release process, BETA3 builds have now started. They were held up for a few days while a few critical issues were resolved: - Changes to make newbus MPSAFE were reverted as they lead to reports of a number of WITNESS warnings and panics during device driver attach/detach. - Another nit in the Subversion->CVS updater was resolved. - The flowtable crash at boot reported by several users has been resolved. - A boot-time hang for users of the htprr driver has been resolved. - ZFS zpool import was fixed. - freebsd-update now backs up the old kernel before installing a new one. You can find a regularly updated release status, the above information, and much more, on the 8.0 release engineering wiki page: http://wiki.freebsd.org/8.0TODO I don't have a specific ETA on BETA3 going out the door, except to say that so far several architectures have reported back on successful builds, so probably quite soon. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 11:01:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CDD106568B; Sat, 22 Aug 2009 11:01:53 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 76CEE8FC0C; Sat, 22 Aug 2009 11:01:53 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:54552 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MeoL1-0003Wz-5C; Sat, 22 Aug 2009 13:00:49 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 886AC163D76; Sat, 22 Aug 2009 13:00:45 +0200 (CEST) Message-Id: From: Thomas Backman To: Pawel Jakub Dawidek In-Reply-To: <20090821110031.GB1962@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 Aug 2009 13:00:43 +0200 References: <7F161876-8DA7-4617-98B6-7CD54C691BC6@exscape.org> <306284EA-C89C-433C-9D33-E6CF44305800@exscape.org> <20090821110031.GB1962@garage.freebsd.pl> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MeoL1-0003Wz-5C. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MeoL1-0003Wz-5C 4233f70c3b8049a6fd951852eb66412e Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Yet another ZFS recv panic; old but rarely seen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 11:01:54 -0000 On Aug 21, 2009, at 13:00, Pawel Jakub Dawidek wrote: > > Right, the bug is already fixed in OpenSolaris. If you can reproduce > the > problem, you might try this patch: > > http://people.freebsd.org/~pjd/patches/dirtying_dbuf.patch I tried to reproduce it, a lot (~750 incremental send/recvs) but no "luck". I've only gotten it twice AFAIK, and that's since May. However, during the stress, I got a solaris assert panic (I've still got -DDEBUG=1), after a couple hours: Unread portion of the kernel message buffer: panic: solaris assert: (int64_t)(arc_stats.arcstat_p.value.ui64) >= 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ common/fs/zfs/arc.c, line: 2044 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 arc_get_data_buf() at arc_get_data_buf+0x2a0 arc_buf_alloc() at arc_buf_alloc+0xe6 arc_read_nolock() at arc_read_nolock+0xf7 arc_read() at arc_read+0xaf dbuf_read() at dbuf_read+0x62b dmu_buf_hold() at dmu_buf_hold+0xcc zap_lockdir() at zap_lockdir+0x68 zap_lookup_norm() at zap_lookup_norm+0x45 zap_lookup() at zap_lookup+0x2e dsl_prop_changed_notify() at dsl_prop_changed_notify+0x1c9 dsl_prop_changed_notify() at dsl_prop_changed_notify+0x157 dsl_prop_set_sync() at dsl_prop_set_sync+0x2ab dsl_sync_task_group_sync() at dsl_sync_task_group_sync+0x173 dsl_pool_sync() at dsl_pool_sync+0x122 spa_sync() at spa_sync+0x35e txg_sync_thread() at txg_sync_thread+0x2d7 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803e8cdd30, rbp = 0 --- KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 1d3h17m21s Physical memory: 2029 MB GDB backtrace is the same until spa_sync(), at which point (#26) it turns into ??'s until #61 0xffffffff80b75447 in txg_sync_thread () from /boot/kernel/zfs.ko Previous frame inner to this frame (corrupt stack?) core.txt vmstat -s: 29040 pages active 28905 pages inactive 143 pages in VM cache 231106 pages wired down (903MiB out of ~2048) 214771 pages free 2GB RAM, amd64. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 12:28:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 489FB1065672; Sat, 22 Aug 2009 12:28:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 173B58FC22; Sat, 22 Aug 2009 12:28:50 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n7MCPb5Z029349; Sat, 22 Aug 2009 08:25:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200908221225.n7MCPb5Z029349@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Aug 2009 08:28:51 -0400 To: Robert Watson , current@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stable@freebsd.org Subject: Re: Quick 8.0 update: BETA3 builds in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 12:28:51 -0000 At 06:04 AM 8/22/2009, Robert Watson wrote: >I don't have a specific ETA on BETA3 going out the door, except to >say that so far several architectures have reported back on >successful builds, so probably quite soon. Just an FYI about builds, the HEAD tinderbox after getting a hardware update is now building RELENG_8 as well http://tinderbox.freebsd.org/ ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 10:00:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8AB106568E for ; Sat, 22 Aug 2009 10:00:08 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6408FC14 for ; Sat, 22 Aug 2009 10:00:07 +0000 (UTC) Received: by fxm6 with SMTP id 6so758995fxm.43 for ; Sat, 22 Aug 2009 03:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=f8IZ2E06yQymRFJgq/c6z4rGYfFl0lu+tXD8sspfAto=; b=QgpFo2E6pV9sV8Z6wdn85g239dxb9cg4DtdGiZ4NcfMxO/SxHbelAsnPwZcT5TDzSb Ka1UiBclxDbmE6B4c3MPxS9e7/ZZBXUZghOFvjqcoLP8COoo5bIWERGSpjyfKyVY8M8H nBI4QtoObAJNCA2Wsx+HD9KLr0711FaJ6u9M8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=g/b1aueNwSRJFxfxfLN6yjWOQENs+dGKoCr2rXV/3H6zPOfH1FrgBWR91gNLxy/jRc +bRq1nrgrc8GwI8dISE3Fs4uZ6TpgqmjNi32YIyIYlPvt64QN+6vO/O4UGoAx0LKnnWh DTsueADWsxu+MxAqqTLVHEjFduy98UNTfVsC8= Received: by 10.86.164.6 with SMTP id m6mr1589802fge.42.1250935206411; Sat, 22 Aug 2009 03:00:06 -0700 (PDT) Received: from ubm.mine.nu (e181051017.adsl.alicedsl.de [85.181.51.17]) by mx.google.com with ESMTPS id l12sm468852fgb.1.2009.08.22.03.00.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 22 Aug 2009 03:00:05 -0700 (PDT) Date: Sat, 22 Aug 2009 11:59:58 +0200 From: Marc UBM To: current@freebsd.org Message-Id: <20090822115958.f93fcf29.ubm.freebsd@gmail.com> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__22_Aug_2009_11_59_58_+0200_zCtc9HKhe3=WgH/u" X-Mailman-Approved-At: Sat, 22 Aug 2009 13:51:37 +0000 Cc: Subject: panic: apic_free_vector: Thread already bound. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 10:00:08 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__22_Aug_2009_11_59_58_+0200_zCtc9HKhe3=WgH/u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hiho! :-) I'm seeing above panic in the final stages of the shutdown process. Coredump is available, bt as follows, textdump attached. FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17 CEST 2009 oni0@hamstor:/usr/obj/usr/src/sys/HAMSTOR amd64 (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not #available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0, #cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801b5ba0 in db_command_loop () #at /usr/src/sys/ddb/db_command.c:498 4 0xffffffff801b7b69 in db_trap #(type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff8038d775 in kdb_trap (type=3, code=0, #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6 #0xffffffff8060e170 in trap (frame=0xffffff8000017760) #at /usr/src/sys/amd64/amd64/trap.c:611 7 0xffffffff805f3b23 in #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8 #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic", #msg=0xa
) at cpufunc.h:63 9 #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:562 #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable "apic_id" #is not available. ) at /usr/src/sys/amd64/amd64/local_apic.c:995 #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable "cookie" #is not available. ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203 #12 0xffffffff806250d4 in hpt_shutdown_vbus #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not available. ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361 #13 0xffffffff8035da8b in boot (howto=16392) #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in #reboot (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:173 #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80) #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17 #0x000000000040892c in ?? () Previous frame inner to this frame (corrupt stack?) frame #12 & #13 make me suspect the hptrr driver (again :-)), but I'm not sure. Bye Marc -- Marc "UBM" Bocklet --Multipart=_Sat__22_Aug_2009_11_59_58_+0200_zCtc9HKhe3=WgH/u Content-Type: application/octet-stream; name="core.txt.4" Content-Disposition: attachment; filename="core.txt.4" Content-Transfer-Encoding: base64 aGFtc3RvciBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS40CgpTYXQgQXVnIDIy IDExOjA3OjAzIENFU1QgMjAwOQoKRnJlZUJTRCBoYW1zdG9yIDguMC1CRVRBMiBGcmVlQlNEIDgu MC1CRVRBMiAjMTQ6IFdlZCBBdWcgMTkgMjI6NDM6MTcgQ0VTVCAyMDA5ICAgICBvbmkwQGhhbXN0 b3I6L3Vzci9vYmovdXNyL3NyYy9zeXMvSEFNU1RPUiAgYW1kNjQKCnBhbmljOiBhcGljX2ZyZWVf dmVjdG9yOiBUaHJlYWQgYWxyZWFkeSBib3VuZC4KCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNv cHlyaWdodCAyMDA0IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBz b2Z0d2FyZSwgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5 b3UgYXJlCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBp dCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRo ZSBjb25kaXRpb25zLgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBU eXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQg YXMgImFtZDY0LW1hcmNlbC1mcmVlYnNkIi4uLgoKVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5l bCBtZXNzYWdlIGJ1ZmZlcjoKPDExOD5TdG9wcGluZyBkZXZkLgo8MTE4PldyaXRpbmcgZW50cm9w eSBmaWxlOgo8MTE4Pi4KPDExOD5UZXJtaW5hdGVkCjwxMTg+Lgo8MTE4PkF1ZyAyMiAxMDo0Nzoy NiBoYW1zdG9yIHN5c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1CldhaXRpbmcgKG1heCA2MCBz ZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5n IChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3Au Li5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNl cicgdG8gc3RvcC4uLgpTeW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uMSAxIDEgMCAw IGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgp6ZnNfdW1vdW50Ojk3MVswXTogRm9yY2UgdW5tb3Vu dCBpcyBleHBlcmltZW50YWwgLSByZXBvcnQgYW55IHByb2JsZW1zLgpVcHRpbWU6IDJoMThtMjdz CnBhbmljOiBhcGljX2ZyZWVfdmVjdG9yOiBUaHJlYWQgYWxyZWFkeSBib3VuZC4KCmNwdWlkID0g MApLREI6IGVudGVyOiBwYW5pYwpQaHlzaWNhbCBtZW1vcnk6IDQwMjIgTUIKRHVtcGluZyAxNTky IE1COiAxNTc3IDE1NjEgMTU0NSAxNTI5IDE1MTMgMTQ5NyAxNDgxIDE0NjUgMTQ0OSAxNDMzIDE0 MTcgMTQwMSAxMzg1IDEzNjkgMTM1MyAxMzM3IDEzMjEgMTMwNSAxMjg5IDEyNzMgMTI1NyAxMjQx IDEyMjUgMTIwOSAxMTkzIDExNzcgMTE2MSAxMTQ1IDExMjkgMTExMyAxMDk3IDEwODEgMTA2NSAx MDQ5IDEwMzMgMTAxNyAxMDAxIDk4NSA5NjkgOTUzIDkzNyA5MjEgOTA1IDg4OSA4NzMgODU3IDg0 MSA4MjUgODA5IDc5MyA3NzcgNzYxIDc0NSA3MjkgNzEzIDY5NyA2ODEgNjY1IDY0OSA2MzMgNjE3 IDYwMSA1ODUgNTY5IDU1MyA1MzcgNTIxIDUwNSA0ODkgNDczIDQ1NyA0NDEgNDI1IDQwOSAzOTMg Mzc3IDM2MSAzNDUgMzI5IDMxMyAyOTcgMjgxIDI2NSAyNDkgMjMzIDIxNyAyMDEgMTg1IDE2OSAx NTMgMTM3IDEyMSAxMDUgODkgNzMgNTcgNDEgMjUgOQoKUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL2FoY2kua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWhj aS5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5l bC9haGNpLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC96ZnMua28uLi5SZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvemZzLmtvLnN5bWJvbHMuLi5kb25lLgpkb25l LgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5rbwpSZWFkaW5nIHN5bWJvbHMg ZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAv Ym9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBz eW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28KUmVhZGluZyBzeW1ib2xzIGZy b20gL2Jvb3Qva2VybmVsL2JsYW5rX3NhdmVyLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL2JsYW5rX3NhdmVyLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3lt Ym9scyBmb3IgL2Jvb3Qva2VybmVsL2JsYW5rX3NhdmVyLmtvCiMwICBkb2FkdW1wICgpIGF0IHBj cHUuaDoyMjMKMjIzCXBjcHUuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeS4KCWluIHBjcHUu aAooa2dkYikgIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjIyMwojMSAgMHhmZmZmZmZmZjgwMWI1 NjFjIGluIGRiX2ZuY2FsbCAoZHVtbXkxPVZhcmlhYmxlICJkdW1teTEiIGlzIG5vdCBhdmFpbGFi bGUuCikKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjU0OAojMiAgMHhmZmZm ZmZmZjgwMWI1OTUxIGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGZmZmZmZmZmODA4NTk0YTAs IGNtZF90YWJsZT1WYXJpYWJsZSAiY21kX3RhYmxlIiBpcyBub3QgYXZhaWxhYmxlLgoKKSBhdCAv dXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NDUKIzMgIDB4ZmZmZmZmZmY4MDFiNWJhMCBp biBkYl9jb21tYW5kX2xvb3AgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5j OjQ5OAojNCAgMHhmZmZmZmZmZjgwMWI3YjY5IGluIGRiX3RyYXAgKHR5cGU9VmFyaWFibGUgInR5 cGUiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjI5 CiM1ICAweGZmZmZmZmZmODAzOGQ3NzUgaW4ga2RiX3RyYXAgKHR5cGU9MywgY29kZT0wLCB0Zj0w eGZmZmZmZjgwMDAwMTc3NjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX2tkYi5jOjUz NQojNiAgMHhmZmZmZmZmZjgwNjBlMTcwIGluIHRyYXAgKGZyYW1lPTB4ZmZmZmZmODAwMDAxNzc2 MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NjExCiM3ICAweGZmZmZm ZmZmODA1ZjNiMjMgaW4gY2FsbHRyYXAgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2 NC9leGNlcHRpb24uUzoyMjQKIzggIDB4ZmZmZmZmZmY4MDM4ZDk0ZCBpbiBrZGJfZW50ZXIgKHdo eT0weGZmZmZmZmZmODA2ODE5NTQgInBhbmljIiwgCiAgICBtc2c9MHhhIDxBZGRyZXNzIDB4YSBv dXQgb2YgYm91bmRzPikgYXQgY3B1ZnVuYy5oOjYzCiM5ICAweGZmZmZmZmZmODAzNWUwNGIgaW4g cGFuaWMgKGZtdD1WYXJpYWJsZSAiZm10IiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NTYyCiMxMCAweGZmZmZmZmZmODA1ZmFmYmIg aW4gYXBpY19mcmVlX3ZlY3RvciAoYXBpY19pZD1WYXJpYWJsZSAiYXBpY19pZCIgaXMgbm90IGF2 YWlsYWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2xvY2FsX2FwaWMuYzo5 OTUKIzExIDB4ZmZmZmZmZmY4MDVmNzU2MCBpbiBpbnRyX3JlbW92ZV9oYW5kbGVyIChjb29raWU9 VmFyaWFibGUgImNvb2tpZSIgaXMgbm90IGF2YWlsYWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L2ludHJfbWFjaGRlcC5jOjIwMwojMTIgMHhmZmZmZmZmZjgwNjI1MGQ0IGlu IGhwdF9zaHV0ZG93bl92YnVzICh2YnVzX2V4dD0weGZmZmZmZjgwMDAyNTQwMDAsIAogICAgaG93 dG89VmFyaWFibGUgImhvd3RvIiBpcyBub3QgYXZhaWxhYmxlLgopIGF0IC91c3Ivc3JjL3N5cy9k ZXYvaHB0cnIvaHB0cnJfb3NtX2JzZC5jOjM2MQojMTMgMHhmZmZmZmZmZjgwMzVkYThiIGluIGJv b3QgKGhvd3RvPTE2MzkyKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5j OjQxOQojMTQgMHhmZmZmZmZmZjgwMzVlMTI2IGluIHJlYm9vdCAodGQ9VmFyaWFibGUgInRkIiBp cyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3du LmM6MTczCiMxNSAweGZmZmZmZmZmODA2MGRiYmEgaW4gc3lzY2FsbCAoZnJhbWU9MHhmZmZmZmY4 MDAwMDE3YzgwKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo5ODIKIzE2 IDB4ZmZmZmZmZmY4MDVmM2UwMSBpbiBYZmFzdF9zeXNjYWxsICgpCiAgICBhdCAvdXNyL3NyYy9z eXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6MzczCiMxNyAweDAwMDAwMDAwMDA0MDg5MmMgaW4g Pz8gKCkKUHJldmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8p CihrZ2RiKSAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwcyAtYXhsCgpTZWdtZW50YXRpb24gZmF1bHQKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQp2bXN0YXQgLXMKCiAgICAgICAgMCBjcHUgY29udGV4dCBzd2l0Y2hlcwog ICAgICAgIDAgZGV2aWNlIGludGVycnVwdHMKICAgICAgICAwIHNvZnR3YXJlIGludGVycnVwdHMK ICAgICAgICAwIHRyYXBzCiAgICAgICAgMCBzeXN0ZW0gY2FsbHMKICAgICAgICAwIGtlcm5lbCB0 aHJlYWRzIGNyZWF0ZWQKICAgICAgICAwICBmb3JrKCkgY2FsbHMKICAgICAgICAwIHZmb3JrKCkg Y2FsbHMKICAgICAgICAwIHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZWlu cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgc3dhcCBwYWdl ciBwYWdlb3V0cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBvdXQKICAgICAgICAw IHZub2RlIHBhZ2VyIHBhZ2VpbnMKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIGlu CiAgICAgICAgMCB2bm9kZSBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFn ZXMgcGFnZWQgb3V0CiAgICAgICAgMCBwYWdlIGRhZW1vbiB3YWtldXBzCiAgICAgICAgMCBwYWdl cyBleGFtaW5lZCBieSB0aGUgcGFnZSBkYWVtb24KICAgICAgMjM2IHBhZ2VzIHJlYWN0aXZhdGVk CiAgICAgICAgMCBjb3B5LW9uLXdyaXRlIGZhdWx0cwogICAgICAgIDAgY29weS1vbi13cml0ZSBv cHRpbWl6ZWQgZmF1bHRzCiAgICAgICAgMCB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAg MCB6ZXJvIGZpbGwgcGFnZXMgcHJlemVyb2VkCiAgICAgICAgMCBpbnRyYW5zaXQgYmxvY2tpbmcg cGFnZSBmYXVsdHMKICAgICAgICAwIHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFn ZXMgYWZmZWN0ZWQgYnkga2VybmVsIHRocmVhZCBjcmVhdGlvbgogICAgICAgIDAgcGFnZXMgYWZm ZWN0ZWQgYnkgIGZvcmsoKQogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAg ICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkgcmZvcmsoKQogICAgICAyNjEgcGFnZXMgY2FjaGVkCiAg ICAgICAgMCBwYWdlcyBmcmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgIDEy MDYyOCBwYWdlcyBmcmVlZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICAgICAgMjQgcGFnZXMgYWN0 aXZlCiAgICAgICAgNSBwYWdlcyBpbmFjdGl2ZQogICAgICAgIDAgcGFnZXMgaW4gVk0gY2FjaGUK ICAgMTA4MDA4IHBhZ2VzIHdpcmVkIGRvd24KICAgODg1MDEyIHBhZ2VzIGZyZWUKICAgICA0MDk2 IGJ5dGVzIHBlciBwYWdlCiAgICA2NzI3MiB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNh Y2hlIGhpdHMgKDg3JSBwb3MgKyA2JSBuZWcpIHN5c3RlbSAwJSBwZXItZGlyZWN0b3J5CiAgICAg ICAgICBkZWxldGlvbnMgMCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCnZtc3RhdCAtbQoKICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0 cyAgU2l6ZShzKQogICAgYWRfZHJpdmVyICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAz MgogICAgICAgIHNpZ2lvICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAxICA2NAogICAgIGZp bGVkZXNjICAgIDU3ICAgIDI5SyAgICAgICAtICAgICAxNjYxICAzMiw1MTIsMTAyNCw0MDk2CiAg ICAgICAgIGtlbnYgICAgNzIgICAgMTFLICAgICAgIC0gICAgICAgNzcgIDE2LDMyLDY0LDEyOAog ICAgICAga3F1ZXVlICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDg2ICAyNTYsMjA0OAogICAg cHJvYy1hcmdzICAgICAxICAgICAxSyAgICAgICAtICAgICAyNDU5ICAxNiwzMiw2NCwxMjgsMjU2 CiAgICAgIGl0aHJlYWQgICAgNjUgICAgMTFLICAgICAgIC0gICAgICAgNjYgIDMyLDEyOCwyNTYK ICAgIGFyX2RyaXZlciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxOCAgNTEyLDIwNDgKICAg ICAgIEtUUkFDRSAgIDEwMCAgICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgICAgICBsaW5r ZXIgICAxMzcgICA2MDRLICAgICAgIC0gICAgICAxODYgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEw MjQsMjA0OCw0MDk2CiAgICAgICAgbG9ja2YgICAgIDIgICAgIDFLICAgICAgIC0gICAgIDYwMDIg IDY0LDEyOAogICAgICAgaXA2bmRwICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA0ICA2NCwx MjgKICAgICAgICAgdGVtcCAgICAxOSAgICAxNUsgICAgICAgLSAgICA0MDc2NSAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIGRldmJ1ZiAxNjEzNiAzMDE5MUsgICAg ICAgLSAgICAxNjIwMCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAg YWNwaXNlbSAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgMTI4CiAgICAgICBtb2R1bGUg ICAyNTAgICAgMzJLICAgICAgIC0gICAgICAyNTAgIDEyOAogICAgIG10eF9wb29sICAgICAyICAg IDE2SyAgICAgICAtICAgICAgICAyICAKICAgICAgQ0FNIFhQVCAgICA0MCAgICAxNEsgICAgICAg LSAgICAgNzM4MCAgMzIsNjQsMTI4LDI1NiwyMDQ4CiAgICAgICAgICBvc2QgICAgIDMgICAgIDFL ICAgICAgIC0gICAgICAgIDQgIDE2LDY0CiAgIENBTSBwZXJpcGggICAgMTAgICAgIDNLICAgICAg IC0gICAgICAyNzQgIDE2LDMyLDY0LDEyOCwyNTYKICAgICAgc3VicHJvYyAgIDE1OCAgIDI4Mksg ICAgICAgLSAgICAgMTcwMyAgNTEyLDQwOTYKICAgICAgICAgcHJvYyAgICAgMiAgICAxNksgICAg ICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgIDEgICAgIDFLICAgICAgIC0gICAgICAg OTggIDEyOAogICAgICAgICBwZ3JwICAgICAxICAgICAxSyAgICAgICAtICAgICAgMTUzICAxMjgK ICAgICAgICAgY3JlZCAgICAxMCAgICAgMksgICAgICAgLSAgICAxMTgxOCAgNjQsMjU2CiAgICAg IHVpZGluZm8gICAgIDIgICAgIDNLICAgICAgIC0gICAgICA3ODkgIDEyOCwyMDQ4CiAgICAgICBw bGltaXQgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDExMjAgIDI1NgogICAgc3lzY3RsdG1wICAg ICAwICAgICAwSyAgICAgICAtICAgICAgMzM1ICAxNiwzMiw2NCwxMjgKICAgIHN5c2N0bG9pZCAg Mzc1MyAgIDE4NEsgICAgICAgLSAgICAgMzg2MCAgMTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwg ICAgIDAgICAgIDBLICAgICAgIC0gICAgICA1OTUgIDE2LDMyLDY0CiAgICAgICAgIHVtdHggICAx NDQgICAgMThLICAgICAgIC0gICAgICAxNDQgIDEyOAogICAgIHAxMDAzLjFiICAgICAxICAgICAx SyAgICAgICAtICAgICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAwICAgICAwSyAgICAgICAt ICAgICAgICAyICA2NAogICAgICBzY3NpX2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDI0 ICAxNgogICAgICAgYnVzLXNjICAgIDg4ICAgMTA0SyAgICAgICAtICAgICAyMjYwICAxNiwzMiw2 NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICAgYnVzICAgODA5ICAgIDc3SyAg ICAgICAtICAgICA1MzQxICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0YXQg ICAgMTAgICAgMjFLICAgICAgIC0gICAgICAgMTAgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA2 NiAgICAgNksgICAgICAgLSAgICAgICA2NyAgNjQsMTI4CiAgICAgIGFjcGlkZXYgICAgOTQgICAg IDZLICAgICAgIC0gICAgICAgOTQgIDY0CiAgICAgICAgIGtvYmogICAxNjAgICA2NDBLICAgICAg IC0gICAgICAyMDkgIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICAgcm1hbiAgIDE3MyAgICAyMUsgICAgICAgLSAgICAgIDU3MSAgMTYs MzIsMTI4CkNBTSBkZXYgcXVldWUgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDEyOAog ICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAgNjA2ICAxNiwzMiw2NCwxMjgs MjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgQ0FNIHF1ZXVlICAgIDE0ICAgICAySyAgICAgICAt ICAgICAxODAwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICBwY2lfbGluayAg ICA3NiAgICAgNksgICAgICAgLSAgICAgICA3NiAgMTYsMzIsMTI4CiAgICAgICAgc3RhY2sgICAg IDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDI1NgogICAgdGFza3F1ZXVlICAgIDEzICAgICAy SyAgICAgICAtICAgICAgIDEzICAxNiwzMiwxMjgKICAgICAgIFVuaXRubyAgICAxMCAgICAgMUsg ICAgICAgLSAgICAgICA1NCAgMzIsNjQKICAgICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAg LSAgICAgIDI4NiAgMTYsNjQsMjU2LDUxMgogICAgICAgc2VsZWN0ICAgIDE0ICAgICAySyAgICAg ICAtICAgICAgIDE0ICAxMjgKICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAgICAx NDMyMSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgIG1zZyAg ICAgNCAgICAzMEsgICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzZW0gICAg IDQgICAgMTFLICAgICAgIC0gICAgICAgIDQgIDUxMiwxMDI0CiAgICAgICAgICBzaG0gICAgIDEg ICAgMjBLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICAgdHR5ICAgIDIwICAgIDIwSyAgICAg ICAtICAgICAgIDI1ICAxMDI0LDIwNDgKICAgICAgICAgIHB0cyAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgMSAgMjU2CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg IDkgIDMyLDEyOAogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICAK ICAgICAgIGtiZG11eCAgICAgNyAgICAxMEsgICAgICAgLSAgICAgICAgNyAgMTYsNTEyLDEwMjQs MjA0OCw0MDk2CiAgICAgICAgICBwY2IgICAgMTMgICAxNTdLICAgICAgIC0gICAgICAxMTYgIDE2 LDMyLDEyOCwxMDI0LDIwNDgsNDA5NgogICAgICAgc29uYW1lICAgICAwICAgICAwSyAgICAgICAt ICAgICAgODMyICAxNiwzMiwxMjgKICAgICAgIGJpb2J1ZiAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAgNiAgMjA0OAogICAgIHZmc2NhY2hlICAgICAxICAxMDI0SyAgICAgICAtICAgICAgICAx ICAKICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICB2 ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAgMSAgCiAgICAgICB2bm9kZXMgICAg IDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogIHZub2RlbWFya2VyICAgICAwICAgICAw SyAgICAgICAtICAgICAyMjM3ICA1MTIKICAgICAgICBtb3VudCAgICAgMSAgICAgMUsgICAgICAg LSAgICAgIDEyMSAgMTYsMzIsNjQsMTI4LDI1NgogICAgICAgICAgQlBGICAgICAzICAgICAxSyAg ICAgICAtICAgICAgICAzICAxMjgKICBldGhlcl9tdWx0aSAgICAxNSAgICAgMUsgICAgICAgLSAg ICAgICAxNiAgMTYsMzIsNjQKICAgICAgIGlmYWRkciAgICAzNSAgICAxMksgICAgICAgLSAgICAg ICAzNSAgMzIsNjQsMTI4LDI1Niw1MTIsNDA5NgogICAgICAgIGlmbmV0ICAgICA0ICAgICA3SyAg ICAgICAtICAgICAgICA0ICAxMjgsMjA0OAogICAgICAgIGNsb25lICAgICA1ICAgIDIwSyAgICAg ICAtICAgICAgICA1ICA0MDk2CiAgICAgICBhcnBjb20gICAgIDEgICAgIDFLICAgICAgIC0gICAg ICAgIDEgIDE2CiAgICAgIGxsdGFibGUgICAgMTMgICAgIDVLICAgICAgIC0gICAgICAgMTggIDI1 Niw1MTIKICAgIGFjcGlfcGVyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAg ZGRiX2NhcHR1cmUgICAgIDEgICAgNDhLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgYWNwaWNh ICAyMjI0ICAgMTk3SyAgICAgICAtICAgIDc1MDI4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0 LDIwNDgKICAgICBwcGJ1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMjU2CiAg ICAgcm91dGV0YmwgICAgMTggICAgIDRLICAgICAgIC0gICAgICAgNjYgIDMyLDY0LDEyOCwyNTYs NTEyCiAgICAgICAgIGlnbXAgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDI1NgogICAg ICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAgICAgICBVQVJU ICAgICAzICAgICAySyAgICAgICAtICAgICAgICAzICAxNiw1MTIsMTAyNAogICAgIGFjcGl0YXNr ICAgICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4CiAgICAgaW5fbXVsdGkgICAgIDIg ICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogICAgc2N0cF9pdGVyICAgICAwICAgICAwSyAg ICAgICAtICAgICAgICAzICAyNTYKICAgICBzY3RwX2lmbiAgICAgMiAgICAgMUsgICAgICAgLSAg ICAgICAgMiAgMTI4CiAgICAgc2N0cF9pZmEgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDQg IDEyOAogICAgIHNjdHBfdnJmICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NAogICAg c2N0cF9hX2l0ICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAzICAxNgogICAgaG9zdGNhY2hl ICAgICAxICAgIDI4SyAgICAgICAtICAgICAgICAxICAKICAgICBzeW5jYWNoZSAgICAgMSAgICA5 NksgICAgICAgLSAgICAgICAgMSAgCiAgICAgICBVU0JkZXYgICAgMTIgICAgIDNLICAgICAgIC0g ICAgICAgMTIgIDY0LDEyOCwxMDI0CiAgICAgICAgICBVU0IgICAgMjMgICAgMTlLICAgICAgIC0g ICAgICAgMjQgIDE2LDMyLDY0LDEyOCwyMDQ4LDQwOTYKICAgIGluNl9tdWx0aSAgICAxMiAgICAg MksgICAgICAgLSAgICAgICAxMiAgMzIsMjU2CiAgICAgICBERVZGUzEgICAgOTYgICAgNDhLICAg ICAgIC0gICAgICAxMDQgIDUxMgogICAgICAgICAgbWxkICAgICAzICAgICAxSyAgICAgICAtICAg ICAgICAzICAxMjgKICAgICAgTkZTIEZIQSAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAg MjA0OAogICAgICAgICAgcnBjICAgICAyICAgICA5SyAgICAgICAtICAgICAgICAyICAyNTYKICAg ICBzYXZlZGlubyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA0NSAgMjU2CiAgICAgICBkaXJy ZW0gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAxNjggIDY0CiAgICAgICAgbWtkaXIgICAgIDAg ICAgIDBLICAgICAgIC0gICAgICAgIDIgIDY0CiAgICAgICBkaXJhZGQgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAxNjggIDY0CiAgICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgIC0gICAg ICAgNTYgIDY0CiAgICAgZnJlZWJsa3MgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNTEgIDI1 NgogICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEzICA2NAogIGFsbG9j ZGlyZWN0ICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDgyICAyNTYKICAgIGJtc2FmZW1hcCAg ICAgMCAgICAgMEsgICAgICAgLSAgICAgICA0NCAgMTI4CiAgICAgICBuZXdibGsgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAgODMgIDY0LDUxMgogICAgIGlub2RlZGVwICAgICAxICAgNTEySyAg ICAgICAtICAgICAgMjI2ICAyNTYKICAgICAgcGFnZWRlcCAgICAgMSAgIDEyOEsgICAgICAgLSAg ICAgICAzNSAgMTI4CiAgdWZzX2Rpcmhhc2ggICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNDgg IDE2LDMyLDY0LDEyOCw1MTIKICAgIHVmc19tb3VudCAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICAgOSAgNTEyLDIwNDgsNDA5NgogICAgICAgREVWRlMzICAgMTEzICAgIDI5SyAgICAgICAtICAg ICAgMTIyICAyNTYKICAgIHZtX3BnZGF0YSAgICAgMSAgIDEyOEsgICAgICAgLSAgICAgICAgMiAg MTI4CiAgICAgICAgREVWRlMgICAgMTQgICAgIDFLICAgICAgIC0gICAgICAgMTUgIDE2LDEyOAog ICAgcGZzX25vZGVzICAgIDIwICAgICA1SyAgICAgICAtICAgICAgIDIwICAyNTYKICAgICAgaW9f YXBpYyAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICAgICBDQU0gU0lNICAg ICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICAgICAgbWVtZGVzYyAgICAgMSAgICAg NEsgICAgICAgLSAgICAgICAgMSAgNDA5NgogICAgIG5leHVzZGV2ICAgICAzICAgICAxSyAgICAg ICAtICAgICAgICAzICAxNgogICAgICAgICBHRU9NICAgMTE3ICAgIDMySyAgICAgICAtICAgICAg OTYzICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICBpc2FkZXYgICAgIDcgICAgIDFL ICAgICAgIC0gICAgICAgIDcgIDEyOAogICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAt ICAgICAgICAyICA2NAogIGF0YV9nZW5lcmljICAgICAzICAgICAzSyAgICAgICAtICAgICAgICAz ICAxMDI0CiAgICAgICAgIGNkZXYgICAgIDcgICAgIDJLICAgICAgIC0gICAgICAgIDcgIDI1Ngog ICAgICBzb2xhcmlzIDE3NDgzIDM0NzYxNksgICAgICAgLSAgIDEyNjg3NSAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAga3N0YXRfZGF0YSAgICAgMiAgICAgMUsgICAgICAg LSAgICAgICAgMiAgNjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAgICAg ICAgICAgICAgICBTSVpFICAgICBMSU1JVCAgICAgIFVTRUQgICAgICBGUkVFICBSRVFVRVNUUyAg RkFJTFVSRVMKClVNQSBLZWdzOiAgICAgICAgICAgICAgICAgMjA4LCAgICAgICAgMCwgICAgICAg OTMsICAgICAgICA5LCAgICAgICA5MywgICAgICAgIDAKVU1BIFpvbmVzOiAgICAgICAgICAgICAg ICAyMjQsICAgICAgICAwLCAgICAgICA5MywgICAgICAgIDksICAgICAgIDkzLCAgICAgICAgMApV TUEgU2xhYnM6ICAgICAgICAgICAgICAgIDU2OCwgICAgICAgIDAsICAgICA1MzMyLCAgICAgIDYz OSwgICAgNDU2NzUsICAgICAgICAwClVNQSBSQ250U2xhYnM6ICAgICAgICAgICAgNTY4LCAgICAg ICAgMCwgICAgICAzMTQsICAgICAgICAxLCAgICAgIDMxNCwgICAgICAgIDAKVU1BIEhhc2g6ICAg ICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgICAgMywgICAgICAgMTIsICAgICAgICAz LCAgICAgICAgMAoxNiBCdWNrZXQ6ICAgICAgICAgICAgICAgIDE1MiwgICAgICAgIDAsICAgICAg IDU4LCAgICAgICAxNywgICAgICAgNTgsICAgICAgICAwCjMyIEJ1Y2tldDogICAgICAgICAgICAg ICAgMjgwLCAgICAgICAgMCwgICAgICAgNDgsICAgICAgICA4LCAgICAgICA0OCwgICAgICAgIDAK NjQgQnVja2V0OiAgICAgICAgICAgICAgICA1MzYsICAgICAgICAwLCAgICAgICA4NiwgICAgICAg IDUsICAgICAgIDg2LCAgICAgIDQwOQoxMjggQnVja2V0OiAgICAgICAgICAgICAgMTA0OCwgICAg ICAgIDAsICAgICAgMjEzLCAgICAgICAgMCwgICAgICAyMTMsICAgICAgICAwClZNIE9CSkVDVDog ICAgICAgICAgICAgICAgMjE2LCAgICAgICAgMCwgICAgICAxMzksICAgICAxMzAxLCAgICAyNDYw MSwgICAgICAgIDAKTUFQOiAgICAgICAgICAgICAgICAgICAgICAyMzIsICAgICAgICAwLCAgICAg ICAgNywgICAgICAgMjUsICAgICAgICA3LCAgICAgICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAg ICAgIDEyMCwgICAxNDg4MDAsICAgICAgNTcwLCAgICAgICAxOSwgICAgOTQwNTgsICAgICAgICAw Ck1BUCBFTlRSWTogICAgICAgICAgICAgICAgMTIwLCAgICAgICAgMCwgICAgICAgIDcsICAgICAx MDE2LCAgICA0NTg5NiwgICAgICAgIDAKRFAgZmFrZXBnOiAgICAgICAgICAgICAgICAxMjAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApTRyBmYWtlcGc6 ICAgICAgICAgICAgICAgIDEyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCm10X3pvbmU6ICAgICAgICAgICAgICAgICAyMDU2LCAgICAgICAgMCwgICAg ICAyMzcsICAgICAgIDEwLCAgICAgIDIzNywgICAgICAgIDAKMTY6ICAgICAgICAgICAgICAgICAg ICAgICAgMTYsICAgICAgICAwLCAgICAgMTgxMywgICAgICAyMDMsICAgIDQyNjc1LCAgICAgICAg MAozMjogICAgICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAgIDAsICAgICAyNTE2LCAgICAg IDYxNSwgICAgMTMxMTQsICAgICAgICAwCjY0OiAgICAgICAgICAgICAgICAgICAgICAgIDY0LCAg ICAgICAgMCwgICAgMTU3MDEsICAgICAgNjUxLCAgIDEwODg2NywgICAgICAgIDAKMTI4OiAgICAg ICAgICAgICAgICAgICAgICAxMjgsICAgICAgICAwLCAgICAgMzk3MywgICAgIDE0NzksICAgIDMy MTY4LCAgICAgICAgMAoyNTY6ICAgICAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAgIDAsICAg ICAgNTA0LCAgICAgIDM2NiwgICAgMzMwOTEsICAgICAgICAwCjUxMjogICAgICAgICAgICAgICAg ICAgICAgNTEyLCAgICAgICAgMCwgICAgIDkyODksICAgICAyMTIxLCAgICAyMTY2MSwgICAgICAg IDAKMTAyNDogICAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgICAwLCAgICAgIDEzNCwgICAg IDMyMTAsICAgIDEyMDc2LCAgICAgICAgMAoyMDQ4OiAgICAgICAgICAgICAgICAgICAgMjA0OCwg ICAgICAgIDAsICAgICAgNDU1LCAgICAgIDM2NywgICAgIDg1MzEsICAgICAgICAwCjQwOTY6ICAg ICAgICAgICAgICAgICAgICA0MDk2LCAgICAgICAgMCwgICAgICAzMjUsICAgICAgMjEwLCAgICAg OTA0NywgICAgICAgIDAKRmlsZXM6ICAgICAgICAgICAgICAgICAgICAgODAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAxODAsICAgICA4NTQzLCAgICAgICAgMApUVVJOU1RJTEU6ICAgICAgICAg ICAgICAgIDEzNiwgICAgICAgIDAsICAgICAgMTQ1LCAgICAgICAzNSwgICAgICAxNDUsICAgICAg ICAwCnVtdHggcGk6ICAgICAgICAgICAgICAgICAgIDk2LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKUFJPQzogICAgICAgICAgICAgICAgICAgIDExMjAs ICAgICAgICAwLCAgICAgICA1NywgICAgICAgNDIsICAgICAxNjAyLCAgICAgICAgMApUSFJFQUQ6 ICAgICAgICAgICAgICAgICAgIDkxMiwgICAgICAgIDAsICAgICAgMTI4LCAgICAgICAxNiwgICAg ICAxNDEsICAgICAgICAwClNMRUVQUVVFVUU6ICAgICAgICAgICAgICAgIDY0LCAgICAgICAgMCwg ICAgICAxNDUsICAgICAgIDc5LCAgICAgIDE0NSwgICAgICAgIDAKVk1TUEFDRTogICAgICAgICAg ICAgICAgICAzOTIsICAgICAgICAwLCAgICAgICAgMSwgICAgICAgMzksICAgICAxNTE0LCAgICAg ICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAgICA3MiwgICAgICAgIDAsICAgICAgICAyLCAg ICAgICA5OCwgICAgICAgIDIsICAgICAgICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgICAgMjU2 LCAgICAgICAgMCwgICAgICAyNjQsICAgICAgMTI0LCAgMTE1NDIzMCwgICAgICAgIDAKbWJ1Zjog ICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgIDEyNCwgICAgICAzOTIsICAy NTkzNDEyLCAgICAgICAgMAptYnVmX2NsdXN0ZXI6ICAgICAgICAgICAgMjA0OCwgICAgMjU2MDAs ICAgICAgMzg0LCAgICAgICAgNiwgICAgICAzODQsICAgICAgICAwCm1idWZfanVtYm9fcGFnZTog ICAgICAgICA0MDk2LCAgICAxMjgwMCwgICAgICAgNjAsICAgICAgIDU5LCAgIDMxMzA5NywgICAg ICAgIDAKbWJ1Zl9qdW1ib185azogICAgICAgICAgIDkyMTYsICAgIDE5MjAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAptYnVmX2p1bWJvXzE2azogICAgICAgICAxNjM4 NCwgICAgMTI4MDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm1idWZf ZXh0X3JlZmNudDogICAgICAgICAgICA0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAKZ19iaW86ICAgICAgICAgICAgICAgICAgICAyMzIsICAgICAgICAw LCAgICAgICAgMCwgICAgICAyNzIsICAgIDM1NjAyLCAgICAgICAgMAp0dHlpbnE6ICAgICAgICAg ICAgICAgICAgIDE2MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgIDE0NCwgICAgICAzMDAsICAg ICAgICAwCnR0eW91dHE6ICAgICAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgIDkwLCAgICAgIDE2MCwgICAgICAgIDAKYXRhX3JlcXVlc3Q6ICAgICAgICAgICAgICAz MTIsICAgICAgICAwLCAgICAgICAgMSwgICAgICAxNTUsICAgMjgxMDE4LCAgICAgICAgMAphdGFf Y29tcG9zaXRlOiAgICAgICAgICAgIDMzNiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwClZOT0RFOiAgICAgICAgICAgICAgICAgICAgNDcyLCAgICAgICAg MCwgICAgICAgIDksICAgICAyNTkxLCAgICAgMjY0MCwgICAgICAgIDAKVk5PREVQT0xMOiAgICAg ICAgICAgICAgICAxMTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMApOQU1FSTogICAgICAgICAgICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAxMiwgICAgMjYwMTYsICAgICAgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgICAg MTA4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAxNjUwLCAgICAgMjg1OSwgICAgICAgIDAKTCBW RlMgQ2FjaGU6ICAgICAgICAgICAgICAzMjgsICAgICAgICAwLCAgICAgICAgMCwgICAgIDExMDQs ICAgICAxMDk1LCAgICAgICAgMApESVJIQVNIOiAgICAgICAgICAgICAgICAgMTAyNCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICA1NiwgICAgICAgNTUsICAgICAgICAwCk5GU01PVU5UOiAgICAg ICAgICAgICAgICAgNjA4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKTkZTTk9ERTogICAgICAgICAgICAgICAgICA2NDgsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwaXBlOiAgICAgICAgICAgICAgICAgICAg IDcyOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAxNSwgICAgICA4NDYsICAgICAgICAwCmtz aWdpbmZvOiAgICAgICAgICAgICAgICAgMTEyLCAgICAgICAgMCwgICAgICAgOTEsICAgICAgOTY1 LCAgICAgICA5MSwgICAgICAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAgICAzNDQsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApLTk9URTogICAgICAg ICAgICAgICAgICAgIDEyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICA2MiwgICAgICAgODgs ICAgICAgICAwCnNvY2tldDogICAgICAgICAgICAgICAgICAgNjgwLCAgICAyNTYwMiwgICAgICAg IDAsICAgICAgIDM2LCAgICAgIDQ0OCwgICAgICAgIDAKaXBxOiAgICAgICAgICAgICAgICAgICAg ICAgNTYsICAgICAgODE5LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp1 ZHBfaW5wY2I6ICAgICAgICAgICAgICAgIDMzNiwgICAgMjU2MDgsICAgICAgICAwLCAgICAgICAy MiwgICAgICAzMTQsICAgICAgICAwCnVkcGNiOiAgICAgICAgICAgICAgICAgICAgIDE2LCAgICAy NTcwNCwgICAgICAgIDAsICAgICAgMTY4LCAgICAgIDMxNCwgICAgICAgIDAKdGNwX2lucGNiOiAg ICAgICAgICAgICAgICAzMzYsICAgIDI1NjA4LCAgICAgICAgMSwgICAgICAgMjEsICAgICAgIDI3 LCAgICAgICAgMAp0Y3BjYjogICAgICAgICAgICAgICAgICAgIDg4MCwgICAgMjU2MDAsICAgICAg ICAwLCAgICAgICAxMiwgICAgICAgMjcsICAgICAgICAwCnRjcHR3OiAgICAgICAgICAgICAgICAg ICAgIDcyLCAgICAgNTE1MCwgICAgICAgIDEsICAgICAgIDk5LCAgICAgICAgNiwgICAgICAgIDAK c3luY2FjaGU6ICAgICAgICAgICAgICAgICAxNDQsICAgIDE1MzY2LCAgICAgICAgMCwgICAgICAg NTIsICAgICAgICAzLCAgICAgICAgMApob3N0Y2FjaGU6ICAgICAgICAgICAgICAgIDEzNiwgICAg MTUzNzIsICAgICAgICAxLCAgICAgICA1NSwgICAgICAgIDIsICAgICAgICAwCnRjcHJlYXNzOiAg ICAgICAgICAgICAgICAgIDQwLCAgICAgMTY4MCwgICAgICAgIDAsICAgICAgMTY4LCAgICAxOTc3 MSwgICAgICAgIDAKc2Fja2hvbGU6ICAgICAgICAgICAgICAgICAgMzIsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAyMDIsICAgICAgIDUxLCAgICAgICAgMApzY3RwX2VwOiAgICAgICAgICAgICAg ICAgMTI0OCwgICAgMjU2MDIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw CnNjdHBfYXNvYzogICAgICAgICAgICAgICAyMTc2LCAgICA0MDAwMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9sYWRkcjogICAgICAgICAgICAgICAgNDgsICAg IDgwMDY0LCAgICAgICAgMCwgICAgICAxNDQsICAgICAgICAzLCAgICAgICAgMApzY3RwX3JhZGRy OiAgICAgICAgICAgICAgIDU5MiwgICAgODAwMDQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnNjdHBfY2h1bms6ICAgICAgICAgICAgICAgMTQ0LCAgIDQwMDAxMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9yZWFkcTogICAgICAgICAg ICAgICAxMDQsICAgNDAwMDMyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MApzY3RwX3N0cmVhbV9tc2dfb3V0OiAgICAgICA5NiwgICA0MDAwMjYsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfYXNjb25mOiAgICAgICAgICAgICAgIDQwLCAg IDQwMDAwOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9hc2Nv bmZfYWNrOiAgICAgICAgICAgNDgsICAgNDAwMDMyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMApyaXBjYjogICAgICAgICAgICAgICAgICAgIDMzNiwgICAgMjU2MDgsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnVucGNiOiAgICAgICAgICAgICAg ICAgICAgMjQwLCAgICAyNTYwMCwgICAgICAgIDAsICAgICAgIDMyLCAgICAgIDEwNiwgICAgICAg IDAKcnRlbnRyeTogICAgICAgICAgICAgICAgICAyMDAsICAgICAgICAwLCAgICAgICAgOCwgICAg ICAgMzAsICAgICAgICA4LCAgICAgICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgICA1Niwg ICAgICAgIDAsICAgICAgIDE1LCAgICAgIDExMSwgICAgMTc2NzgsICAgICAgICAwClNXQVBNRVRB OiAgICAgICAgICAgICAgICAgMjg4LCAgIDExNjUxOSwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKTW91bnRwb2ludHM6ICAgICAgICAgICAgICA3NTIsICAgICAgICAwLCAg ICAgICAgMSwgICAgICAgIDksICAgICAgICA1LCAgICAgICAgMApGRlMgaW5vZGU6ICAgICAgICAg ICAgICAgIDE2OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgIDYzOCwgICAgICA2NTgsICAgICAg ICAwCkZGUzEgZGlub2RlOiAgICAgICAgICAgICAgMTI4LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAgICAyNTYs ICAgICAgICAwLCAgICAgICAgMCwgICAgICA2MTUsICAgICAgNjU4LCAgICAgICAgMAp0YXNrcV9l bnRfY2FjaGU6ICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICAgNjA0LCAgICAgICAxMiwgICAg IDEyMDYsICAgICAgICAwCnRhc2txX2NhY2hlOiAgICAgICAgICAgICAgMjg4LCAgICAgICAgMCwg ICAgICAgMTMsICAgICAgIDEzLCAgICAgICAyNiwgICAgICAgIDAKemlvX2NhY2hlOiAgICAgICAg ICAgICAgICA3MjAsICAgICAgICAwLCAgICAgICAgMCwgICAgIDMxMzAsICAgIDM5OTQ5LCAgICAg ICAgMApkbXVfYnVmX2ltcGxfdDogICAgICAgICAgIDIyNCwgICAgICAgIDAsICAgICAgMzY0LCAg ICAgMjcxMywgICAgIDMxOTcsICAgICAgICAwCmRub2RlX3Q6ICAgICAgICAgICAgICAgICAgNzY4 LCAgICAgICAgMCwgICAgICAzMTAsICAgICAxOTU1LCAgICAgMjI4MiwgICAgICAgIDAKYXJjX2J1 Zl9oZHJfdDogICAgICAgICAgICAyMDgsICAgICAgICAwLCAgICAgMzQ1NCwgICAgICAgMjAsICAg ICAzNjc4LCAgICAgICAgMAphcmNfYnVmX3Q6ICAgICAgICAgICAgICAgICA3MiwgICAgICAgIDAs ICAgICAyNzMzLCAgICAgIDc2NywgICAgIDM2NzgsICAgICAgICAwCnppbF9sd2JfY2FjaGU6ICAg ICAgICAgICAgMjAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgIDM4LCAgICAgICAyNCwgICAg ICAgIDAKemZzX3pub2RlX2NhY2hlOiAgICAgICAgICAzNzYsICAgICAgICAwLCAgICAgICAgMCwg ICAgIDE5NjAsICAgICAxOTQ3LCAgICAgICAgMAoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLWkK CmludGVycnVwdCAgICAgICAgICAgICAgICAgICAgICAgICAgdG90YWwgICAgICAgcmF0ZQppcnEx NDogYXRhMCAgICAgICAgICAgICAgICAgICAgICAgICAyNzE5ICAgICAgICAgMjMKaXJxMTY6IGhw dHJyMCAgICAgICAgICAgICAgICAgICAgICAgNDgzNiAgICAgICAgIDQwCmlycTE3OiBlbTAgICAg ICAgICAgICAgICAgICAgICAgICAzMjM3MjUgICAgICAgMjc0MwppcnEyMTogb2hjaTArICAgICAg ICAgICAgICAgICAgICAgICA4MDE5ICAgICAgICAgNjcKaXJxMjI6IGVoY2kwICAgICAgICAgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAwCmNwdTA6IHRpbWVyICAgICAgICAgICAgICAgICAg ICAgMTY2MjM1NzQgICAgIDE0MDg3NwpUb3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAgIDE2 OTYyODc1ICAgICAxNDM3NTMKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtVAoKICAwLzEyMzI4IGZp bGVzCjBNLzBNIHN3YXAgc3BhY2UKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNlICAg ICAgICAgIDUxMi1ibG9ja3MgICAgIFVzZWQgICAgQXZhaWwgQ2FwYWNpdHkKCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQppb3N0YXQKCmlvc3RhdDoga3ZtX3JlYWQoX3RrX25pbik6IGludmFsaWQgYWRkcmVzcyAo MHgwKQppb3N0YXQ6IGRpc2FibGluZyBUVFkgc3RhdGlzdGljcwppb3N0YXQ6IGt2bV9nZXRjcHRp bWU6IGludmFsaWQgYWRkcmVzcyAoMHgwKQppb3N0YXQ6IGRpc2FibGluZyBDUFUgdGltZSBzdGF0 aXN0aWNzCiAgICAgICAgICAgICBhZDAgICAgICAgICAgICAgIGFkNCAgICAgICAgICAgICAgYWQ2 IAogIEtCL3QgdHBzICBNQi9zICAgS0IvdCB0cHMgIE1CL3MgICBLQi90IHRwcyAgTUIvcyAKIDE1 Ljc4ICAyMSAgMC4zMyAgNDQuNjUgIDMxICAxLjM3ICA0NC40OCAgMzEgIDEuMzYgCgotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KaXBjcyAtYQoKTWVzc2FnZSBRdWV1ZXM6ClQgICAgICAgICAgIElEICAgICAgICAg IEtFWSBNT0RFICAgICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAg ICAgICAgICAgIENCWVRFUyAgICAgICAgICAgICAgICAgUU5VTSAgICAgICAgICAgICAgIFFCWVRF UyAgICAgICAgTFNQSUQgICAgICAgIExSUElEIFNUSU1FICAgIFJUSU1FICAgIENUSU1FICAgCgpT aGFyZWQgTWVtb3J5OgpUICAgICAgICAgICBJRCAgICAgICAgICBLRVkgTU9ERSAgICAgICAgT1dO RVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAgICAgTkFUVENIICAgICAgICBTRUdT WiAgICAgICAgIENQSUQgICAgICAgICBMUElEIEFUSU1FICAgIERUSU1FICAgIENUSU1FICAgCgpT ZW1hcGhvcmVzOgpUICAgICAgICAgICBJRCAgICAgICAgICBLRVkgTU9ERSAgICAgICAgT1dORVIg ICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAgICAgIE5TRU1TIE9USU1FICAgIENUSU1F ICAgCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlwY3MgLVQKCm1zZ2luZm86Cgltc2dtYXg6ICAgICAgICAx NjM4NAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlKQoJbXNnbW5pOiAgICAgICAgICAgNDAJ KCMgb2YgbWVzc2FnZSBxdWV1ZXMpCgltc2dtbmI6ICAgICAgICAgMjA0OAkobWF4IGNoYXJhY3Rl cnMgaW4gYSBtZXNzYWdlIHF1ZXVlKQoJbXNndHFsOiAgICAgICAgICAgNDAJKG1heCAjIG9mIG1l c3NhZ2VzIGluIHN5c3RlbSkKCW1zZ3NzejogICAgICAgICAgICA4CShzaXplIG9mIGEgbWVzc2Fn ZSBzZWdtZW50KQoJbXNnc2VnOiAgICAgICAgIDIwNDgJKCMgb2YgbWVzc2FnZSBzZWdtZW50cyBp biBzeXN0ZW0pCgpzaG1pbmZvOgoJc2htbWF4OiAgICAgMzM1NTQ0MzIJKG1heCBzaGFyZWQgbWVt b3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1pbjogICAgICAgICAgICAxCShtaW4gc2hhcmVkIG1lbW9y eSBzZWdtZW50IHNpemUpCglzaG1tbmk6ICAgICAgICAgIDE5MgkobWF4IG51bWJlciBvZiBzaGFy ZWQgbWVtb3J5IGlkZW50aWZpZXJzKQoJc2htc2VnOiAgICAgICAgICAxMjgJKG1heCBzaGFyZWQg bWVtb3J5IHNlZ21lbnRzIHBlciBwcm9jZXNzKQoJc2htYWxsOiAgICAgICAgIDgxOTIJKG1heCBh bW91bnQgb2Ygc2hhcmVkIG1lbW9yeSBpbiBwYWdlcykKCnNlbWluZm86CglzZW1tYXA6ICAgICAg ICAgICAzMAkoIyBvZiBlbnRyaWVzIGluIHNlbWFwaG9yZSBtYXApCglzZW1tbmk6ICAgICAgICAg ICAxMAkoIyBvZiBzZW1hcGhvcmUgaWRlbnRpZmllcnMpCglzZW1tbnM6ICAgICAgICAgICA2MAko IyBvZiBzZW1hcGhvcmVzIGluIHN5c3RlbSkKCXNlbW1udTogICAgICAgICAgIDMwCSgjIG9mIHVu ZG8gc3RydWN0dXJlcyBpbiBzeXN0ZW0pCglzZW1tc2w6ICAgICAgICAgICA2MAkobWF4ICMgb2Yg c2VtYXBob3JlcyBwZXIgaWQpCglzZW1vcG06ICAgICAgICAgIDEwMAkobWF4ICMgb2Ygb3BlcmF0 aW9ucyBwZXIgc2Vtb3AgY2FsbCkKCXNlbXVtZTogICAgICAgICAgIDEwCShtYXggIyBvZiB1bmRv IGVudHJpZXMgcGVyIHByb2Nlc3MpCglzZW11c3o6ICAgICAgICAgIDE1Mgkoc2l6ZSBpbiBieXRl cyBvZiB1bmRvIHN0cnVjdHVyZSkKCXNlbXZteDogICAgICAgIDMyNzY3CShzZW1hcGhvcmUgbWF4 aW11bSB2YWx1ZSkKCXNlbWFlbTogICAgICAgIDE2Mzg0CShhZGp1c3Qgb24gZXhpdCBtYXggdmFs dWUpCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5mc3N0YXQKCkNsaWVudCBJbmZvOgpScGMgQ291bnRzOgog IEdldGF0dHIgICBTZXRhdHRyICAgIExvb2t1cCAgUmVhZGxpbmsgICAgICBSZWFkICAgICBXcml0 ZSAgICBDcmVhdGUgICAgUmVtb3ZlCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgUmVuYW1lICAg ICAgTGluayAgIFN5bWxpbmsgICAgIE1rZGlyICAgICBSbWRpciAgIFJlYWRkaXIgIFJkaXJQbHVz ICAgIEFjY2VzcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCiAgICBNa25vZCAgICBGc3N0YXQgICAg RnNpbmZvICBQYXRoQ29uZiAgICBDb21taXQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMApScGMgSW5mbzoKIFRpbWVkT3V0ICAgSW52YWxpZCBYIFJlcGxp ZXMgICBSZXRyaWVzICBSZXF1ZXN0cwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwCkNhY2hlIEluZm86CkF0dHIgSGl0cyAgICBNaXNzZXMgTGt1cCBIaXRz ICAgIE1pc3NlcyBCaW9SIEhpdHMgICAgTWlzc2VzIEJpb1cgSGl0cyAgICBNaXNzZXMKICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMApCaW9STEhpdHMgICAgTWlzc2VzIEJpb0QgSGl0cyAgICBNaXNzZXMg RGlyRSBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwICAgICAgICAgMAoKU2VydmVyIEluZm86CiAgR2V0YXR0ciAgIFNldGF0dHIg ICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1v dmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAg ICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAg MCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAg IENvbW1pdAogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw ClNlcnZlciBSZXQtRmFpbGVkCiAgICAgICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAg ICAgICAgMApTZXJ2ZXIgQ2FjaGUgU3RhdHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVt ICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVy IFdyaXRlIEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6Cgkx MDk2MzcxIHBhY2tldHMgc2VudAoJCTg2ODY0MCBkYXRhIHBhY2tldHMgKDEyNTQ2NDU4NDggYnl0 ZXMpCgkJMTU0MSBkYXRhIHBhY2tldHMgKDIyMTQwNDAgYnl0ZXMpIHJldHJhbnNtaXR0ZWQKCQkw IGRhdGEgcGFja2V0cyB1bm5lY2Vzc2FyaWx5IHJldHJhbnNtaXR0ZWQKCQkwIHJlc2VuZHMgaW5p dGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkKCQkxNjk0MzggYWNrLW9ubHkgcGFja2V0cyAoMzIgZGVs YXllZCkKCQkwIFVSRyBvbmx5IHBhY2tldHMKCQkwIHdpbmRvdyBwcm9iZSBwYWNrZXRzCgkJNTY3 MzUgd2luZG93IHVwZGF0ZSBwYWNrZXRzCgkJMTcgY29udHJvbCBwYWNrZXRzCgkxMDMyMDU5IHBh Y2tldHMgcmVjZWl2ZWQKCQk0OTQwMjYgYWNrcyAoZm9yIDEyNTQ2NDU4NTAgYnl0ZXMpCgkJNDY3 NSBkdXBsaWNhdGUgYWNrcwoJCTAgYWNrcyBmb3IgdW5zZW50IGRhdGEKCQkzMDgyODAgcGFja2V0 cyAoNDQyMTQyODEzIGJ5dGVzKSByZWNlaXZlZCBpbi1zZXF1ZW5jZQoJCTEzMjEgY29tcGxldGVs eSBkdXBsaWNhdGUgcGFja2V0cyAoMTkxMjgwOCBieXRlcykKCQkzMSBvbGQgZHVwbGljYXRlIHBh Y2tldHMKCQkwIHBhY2tldHMgd2l0aCBzb21lIGR1cC4gZGF0YSAoMCBieXRlcyBkdXBlZCkKCQkx OTc3MSBvdXQtb2Ytb3JkZXIgcGFja2V0cyAoMjg2Mjg0MDggYnl0ZXMpCgkJMCBwYWNrZXRzICgw IGJ5dGVzKSBvZiBkYXRhIGFmdGVyIHdpbmRvdwoJCTAgd2luZG93IHByb2JlcwoJCTIwNDc0MyB3 aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkwIHBhY2tldHMgcmVjZWl2ZWQgYWZ0ZXIgY2xvc2UKCQkw IGRpc2NhcmRlZCBmb3IgYmFkIGNoZWNrc3VtcwoJCTAgZGlzY2FyZGVkIGZvciBiYWQgaGVhZGVy IG9mZnNldCBmaWVsZHMKCQkwIGRpc2NhcmRlZCBiZWNhdXNlIHBhY2tldCB0b28gc2hvcnQKCQkw IGRpc2NhcmRlZCBkdWUgdG8gbWVtb3J5IHByb2JsZW1zCgkxMyBjb25uZWN0aW9uIHJlcXVlc3Rz CgkzIGNvbm5lY3Rpb24gYWNjZXB0cwoJMCBiYWQgY29ubmVjdGlvbiBhdHRlbXB0cwoJMCBsaXN0 ZW4gcXVldWUgb3ZlcmZsb3dzCgkwIGlnbm9yZWQgUlNUcyBpbiB0aGUgd2luZG93cwoJOCBjb25u ZWN0aW9ucyBlc3RhYmxpc2hlZCAoaW5jbHVkaW5nIGFjY2VwdHMpCgkyNiBjb25uZWN0aW9ucyBj bG9zZWQgKGluY2x1ZGluZyAxIGRyb3ApCgkJNiBjb25uZWN0aW9ucyB1cGRhdGVkIGNhY2hlZCBS VFQgb24gY2xvc2UKCQk3IGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBv biBjbG9zZQoJCTUgY29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgc3N0aHJlc2ggb24gY2xvc2UK CTggZW1icnlvbmljIGNvbm5lY3Rpb25zIGRyb3BwZWQKCTQ3OTUzMyBzZWdtZW50cyB1cGRhdGVk IHJ0dCAob2YgMjYzMzA2IGF0dGVtcHRzKQoJMjYgcmV0cmFuc21pdCB0aW1lb3V0cwoJCTEgY29u bmVjdGlvbiBkcm9wcGVkIGJ5IHJleG1pdCB0aW1lb3V0CgkwIHBlcnNpc3QgdGltZW91dHMKCQkw IGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkgcGVyc2lzdCB0aW1lb3V0CgkwIENvbm5lY3Rpb25zIChm aW5fd2FpdF8yKSBkcm9wcGVkIGJlY2F1c2Ugb2YgdGltZW91dAoJMCBrZWVwYWxpdmUgdGltZW91 dHMKCQkwIGtlZXBhbGl2ZSBwcm9iZXMgc2VudAoJCTAgY29ubmVjdGlvbnMgZHJvcHBlZCBieSBr ZWVwYWxpdmUKCTEzMjI5IGNvcnJlY3QgQUNLIGhlYWRlciBwcmVkaWN0aW9ucwoJMzA3MDc0IGNv cnJlY3QgZGF0YSBwYWNrZXQgaGVhZGVyIHByZWRpY3Rpb25zCgkzIHN5bmNhY2hlIGVudHJpZXMg YWRkZWQKCQkwIHJldHJhbnNtaXR0ZWQKCQkwIGR1cHN5bgoJCTAgZHJvcHBlZAoJCTMgY29tcGxl dGVkCgkJMCBidWNrZXQgb3ZlcmZsb3cKCQkwIGNhY2hlIG92ZXJmbG93CgkJMCByZXNldAoJCTAg c3RhbGUKCQkwIGFib3J0ZWQKCQkwIGJhZGFjawoJCTAgdW5yZWFjaAoJCTAgem9uZSBmYWlsdXJl cwoJMyBjb29raWVzIHNlbnQKCTAgY29va2llcyByZWNlaXZlZAoJMjUgU0FDSyByZWNvdmVyeSBl cGlzb2RlcwoJNjk2IHNlZ21lbnQgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkx MDA3ODA4IGJ5dGUgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkzNzA5IFNBQ0sg b3B0aW9ucyAoU0FDSyBibG9ja3MpIHJlY2VpdmVkCgkxODI2NyBTQUNLIG9wdGlvbnMgKFNBQ0sg YmxvY2tzKSBzZW50CgkwIFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBwYWNrZXRzIHdpdGgg RUNOIENFIGJpdCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkgYml0IHNldAoJMCBwYWNr ZXRzIHdpdGggRUNOIEVDVCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3NmdWwgRUNOIGhhbmRzaGFrZXMK CTAgdGltZXMgRUNOIHJlZHVjZWQgdGhlIGNvbmdlc3Rpb24gd2luZG93CnVkcDoKCTI5NCBkYXRh Z3JhbXMgcmVjZWl2ZWQKCTAgd2l0aCBpbmNvbXBsZXRlIGhlYWRlcgoJMCB3aXRoIGJhZCBkYXRh IGxlbmd0aCBmaWVsZAoJMCB3aXRoIGJhZCBjaGVja3N1bQoJMCB3aXRoIG5vIGNoZWNrc3VtCgkw IGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tldAoJMCBicm9hZGNhc3QvbXVsdGljYXN0IGRhdGFncmFt cyB1bmRlbGl2ZXJlZAoJMCBkcm9wcGVkIGR1ZSB0byBmdWxsIHNvY2tldCBidWZmZXJzCgkwIG5v dCBmb3IgaGFzaGVkIHBjYgoJMjk0IGRlbGl2ZXJlZAoJMTEwIGRhdGFncmFtcyBvdXRwdXQKCTAg dGltZXMgbXVsdGljYXN0IHNvdXJjZSBmaWx0ZXIgbWF0Y2hlZAppcDoKCTEwMzIzNDUgdG90YWwg cGFja2V0cyByZWNlaXZlZAoJMCBiYWQgaGVhZGVyIGNoZWNrc3VtcwoJMCB3aXRoIHNpemUgc21h bGxlciB0aGFuIG1pbmltdW0KCTAgd2l0aCBkYXRhIHNpemUgPCBkYXRhIGxlbmd0aAoJMCB3aXRo IGlwIGxlbmd0aCA+IG1heCBpcCBwYWNrZXQgc2l6ZQoJMCB3aXRoIGhlYWRlciBsZW5ndGggPCBk YXRhIHNpemUKCTAgd2l0aCBkYXRhIGxlbmd0aCA8IGhlYWRlciBsZW5ndGgKCTAgd2l0aCBiYWQg b3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJlcgoJMCBmcmFnbWVudHMgcmVj ZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Ygc3BhY2UpCgkwIGZyYWdt ZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJMTAz MjM0NSBwYWNrZXRzIGZvciB0aGlzIGhvc3QKCTAgcGFja2V0cyBmb3IgdW5rbm93bi91bnN1cHBv cnRlZCBwcm90b2NvbAoJMCBwYWNrZXRzIGZvcndhcmRlZCAoMCBwYWNrZXRzIGZhc3QgZm9yd2Fy ZGVkKQoJMCBwYWNrZXRzIG5vdCBmb3J3YXJkYWJsZQoJMCBwYWNrZXRzIHJlY2VpdmVkIGZvciB1 bmtub3duIG11bHRpY2FzdCBncm91cAoJMCByZWRpcmVjdHMgc2VudAoJMTA5NjQ4MSBwYWNrZXRz IHNlbnQgZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBo ZWFkZXIKCTAgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJMCBv dXRwdXQgcGFja2V0cyBkaXNjYXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkwIG91dHB1dCBkYXRhZ3Jh bXMgZnJhZ21lbnRlZAoJMCBmcmFnbWVudHMgY3JlYXRlZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4n dCBiZSBmcmFnbWVudGVkCgkwIHR1bm5lbGluZyBwYWNrZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYK CTAgZGF0YWdyYW1zIHdpdGggYmFkIGFkZHJlc3MgaW4gaGVhZGVyCmljbXA6CgkwIGNhbGxzIHRv IGljbXBfZXJyb3IKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNt cCBtZXNzYWdlCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIGxl c3MgdGhhbiB0aGUgbWluaW11bSBsZW5ndGgKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0K CTAgbWVzc2FnZXMgd2l0aCBiYWQgbGVuZ3RoCgkwIG11bHRpY2FzdCBlY2hvIHJlcXVlc3RzIGln bm9yZWQKCTAgbXVsdGljYXN0IHRpbWVzdGFtcCByZXF1ZXN0cyBpZ25vcmVkCgkwIG1lc3NhZ2Ug cmVzcG9uc2VzIGdlbmVyYXRlZAoJMCBpbnZhbGlkIHJldHVybiBhZGRyZXNzZXMKCTAgbm8gcmV0 dXJuIHJvdXRlcwppZ21wOgoJMCBtZXNzYWdlcyByZWNlaXZlZAoJMCBtZXNzYWdlcyByZWNlaXZl ZCB3aXRoIHRvbyBmZXcgYnl0ZXMKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB3cm9uZyBUVEwK CTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCBiYWQgY2hlY2tzdW0KCTAgVjEvVjIgbWVtYmVyc2hp cCBxdWVyaWVzIHJlY2VpdmVkCgkwIFYzIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZAoJMCBt ZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkwIGdlbmVy YWwgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cCBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNv dXJjZSBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIGRyb3BwZWQKCTAg bWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZl ZCB3aXRoIGludmFsaWQgZmllbGQocykKCTAgbWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIGZv ciBncm91cHMgdG8gd2hpY2ggd2UgYmVsb25nCgkwIFYzIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aG91 dCBSb3V0ZXIgQWxlcnQKCTAgbWVtYmVyc2hpcCByZXBvcnRzIHNlbnQKaXA2OgoJOCB0b3RhbCBw YWNrZXRzIHJlY2VpdmVkCgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWluaW11bQoJMCB3aXRo IGRhdGEgc2l6ZSA8IGRhdGEgbGVuZ3RoCgkwIHdpdGggYmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNv cnJlY3QgdmVyc2lvbiBudW1iZXIKCTAgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBk cm9wcGVkIChkdXAgb3Igb3V0IG9mIHNwYWNlKQoJMCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0 aW1lb3V0CgkwIGZyYWdtZW50cyB0aGF0IGV4Y2VlZGVkIGxpbWl0CgkwIHBhY2tldHMgcmVhc3Nl bWJsZWQgb2sKCTggcGFja2V0cyBmb3IgdGhpcyBob3N0CgkwIHBhY2tldHMgZm9yd2FyZGVkCgkw IHBhY2tldHMgbm90IGZvcndhcmRhYmxlCgkwIHJlZGlyZWN0cyBzZW50Cgk4IHBhY2tldHMgc2Vu dCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQgd2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRl cgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0byBubyBidWZzLCBldGMuCgkwIG91dHB1 dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91dGUKCTAgb3V0cHV0IGRhdGFncmFtcyBm cmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkwIGRhdGFncmFtcyB0aGF0IGNhbid0IGJl IGZyYWdtZW50ZWQKCTAgcGFja2V0cyB0aGF0IHZpb2xhdGVkIHNjb3BlIHJ1bGVzCgkwIG11bHRp Y2FzdCBwYWNrZXRzIHdoaWNoIHdlIGRvbid0IGpvaW4KCUlucHV0IGhpc3RvZ3JhbToKCQlUQ1A6 IDgKCU1idWYgc3RhdGlzdGljczoKCQk4IG9uZSBtYnVmCgkJMCBvbmUgZXh0IG1idWYKCQkwIHR3 byBvciBtb3JlIGV4dCBtYnVmCgkwIHBhY2tldHMgd2hvc2UgaGVhZGVycyBhcmUgbm90IGNvbnRp bnVvdXMKCTAgdHVubmVsaW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBwYWNrZXRz IGRpc2NhcmRlZCBiZWNhdXNlIG9mIHRvbyBtYW55IGhlYWRlcnMKCTAgZmFpbHVyZXMgb2Ygc291 cmNlIGFkZHJlc3Mgc2VsZWN0aW9uCglTb3VyY2UgYWRkcmVzc2VzIHNlbGVjdGlvbiBydWxlIGFw cGxpZWQ6CgkJOCBmaXJzdCBjYW5kaWRhdGUKCQk4IHNhbWUgYWRkcmVzcwppY21wNjoKCTAgY2Fs bHMgdG8gaWNtcDZfZXJyb3IKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8g YW4gaWNtcDYgbWVzc2FnZQoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBiZWNhdXNlIG9mIHJhdGUg bGltaXRhdGlvbgoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjb2RlIGZpZWxkcwoJMCBtZXNzYWdlcyA8 IG1pbmltdW0gbGVuZ3RoCgkwIGJhZCBjaGVja3N1bXMKCTAgbWVzc2FnZXMgd2l0aCBiYWQgbGVu Z3RoCglIaXN0b2dyYW0gb2YgZXJyb3IgbWVzc2FnZXMgdG8gYmUgZ2VuZXJhdGVkOgoJCTAgbm8g cm91dGUKCQkwIGFkbWluaXN0cmF0aXZlbHkgcHJvaGliaXRlZAoJCTAgYmV5b25kIHNjb3BlCgkJ MCBhZGRyZXNzIHVucmVhY2hhYmxlCgkJMCBwb3J0IHVucmVhY2hhYmxlCgkJMCBwYWNrZXQgdG9v IGJpZwoJCTAgdGltZSBleGNlZWQgdHJhbnNpdAoJCTAgdGltZSBleGNlZWQgcmVhc3NlbWJseQoJ CTAgZXJyb25lb3VzIGhlYWRlciBmaWVsZAoJCTAgdW5yZWNvZ25pemVkIG5leHQgaGVhZGVyCgkJ MCB1bnJlY29nbml6ZWQgb3B0aW9uCgkJMCByZWRpcmVjdAoJCTAgdW5rbm93bgoJMCBtZXNzYWdl IHJlc3BvbnNlcyBnZW5lcmF0ZWQKCTAgbWVzc2FnZXMgd2l0aCB0b28gbWFueSBORCBvcHRpb25z CgkwIG1lc3NhZ2VzIHdpdGggYmFkIE5EIG9wdGlvbnMKCTAgYmFkIG5laWdoYm9yIHNvbGljaXRh dGlvbiBtZXNzYWdlcwoJMCBiYWQgbmVpZ2hib3IgYWR2ZXJ0aXNlbWVudCBtZXNzYWdlcwoJMCBi YWQgcm91dGVyIHNvbGljaXRhdGlvbiBtZXNzYWdlcwoJMCBiYWQgcm91dGVyIGFkdmVydGlzZW1l bnQgbWVzc2FnZXMKCTAgYmFkIHJlZGlyZWN0IG1lc3NhZ2VzCgkwIHBhdGggTVRVIGNoYW5nZXMK cmlwNjoKCTAgbWVzc2FnZXMgcmVjZWl2ZWQKCTAgY2hlY2tzdW0gY2FsY3VsYXRpb25zIG9uIGlu Ym91bmQKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2FnZXMgZHJvcHBlZCBk dWUgdG8gbm8gc29ja2V0CgkwIG11bHRpY2FzdCBtZXNzYWdlcyBkcm9wcGVkIGR1ZSB0byBubyBz b2NrZXQKCTAgbWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBk ZWxpdmVyZWQKCTAgZGF0YWdyYW1zIG91dHB1dAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLW0K CjM4OC81MTYvOTA0IG1idWZzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKMjYwLzEzMC8z OTAvMjU2MDAgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQoy NjQvMTI0IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2Ug KGN1cnJlbnQvY2FjaGUpCjYwLzU5LzExOS8xMjgwMCA0ayAocGFnZSBzaXplKSBqdW1ibyBjbHVz dGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC8xOTIwMCA5ayBqdW1i byBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC8xMjgwMCAx NmsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKODU3Sy82 MjVLLzE0ODJLIGJ5dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChjdXJyZW50L2NhY2hlL3RvdGFs KQowLzAvMCByZXF1ZXN0cyBmb3IgbWJ1ZnMgZGVuaWVkIChtYnVmcy9jbHVzdGVycy9tYnVmK2Ns dXN0ZXJzKQowLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVuaWVkICg0ay85ay8x NmspCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRl bGF5ZWQKMCByZXF1ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmlsZQowIGNhbGxzIHRv IHByb3RvY29sIGRyYWluIHJvdXRpbmVzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtaWQKCk5h bWUgICAgTXR1IE5ldHdvcmsgICAgICAgQWRkcmVzcyAgICAgICAgICAgICAgSXBrdHMgSWVycnMg ICAgT3BrdHMgT2VycnMgIENvbGwgRHJvcAplbTAgICAgOTAwMCA8TGluayMxPiAgICAgIDAwOjFi OjIxOjE3OjJlOjVkICAxMDMyNTA0ICAgICAwICAxMDk2NDI1ICAgICAwICAgICAwICAgIDAgCmVt MCAgICA5MDAwIDE5Mi4xNjguMC4wICAgaDRtc3Qwci5tYXJpbmVzICAgIDEwMzIzMzcgICAgIC0g IDEwOTY0NzMgICAgIC0gICAgIC0gICAgLSAKcGxpcDAgIDE1MDAgPExpbmsjMj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAps bzAgICAxNjM4NCA8TGluayMzPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE2ICAgICAw ICAgICAgIDE2ICAgICAwICAgICAwICAgIDAgCmxvMCAgIDE2Mzg0IGZlODA6Mzo6MSAgICAgZmU4 MDozOjoxICAgICAgICAgICAgICAgIDAgICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAK bG8wICAgMTYzODQgbG9jYWxob3N0Lm1hciA6OjEgICAgICAgICAgICAgICAgICAgICAgMCAgICAg LSAgICAgICAgOCAgICAgLSAgICAgLSAgICAtIApsbzAgICAxNjM4NCB5b3VyLW5ldCAgICAgIGxv Y2FsaG9zdC5tYXJpbmVzICAgICAgICA4ICAgICAtICAgICAgICA4ICAgICAtICAgICAtICAgIC0g CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6 CkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAg IFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAxOTIuMTY4LjAuMSAgICAgICAg VUdTICAgICAgICAgMCAgICAgICAgMCAgICBlbTAKMTI3LjAuMC4xICAgICAgICAgIGxpbmsjMyAg ICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICA4ICAgIGxvMAoxOTIuMTY4LjAuMC8yNCAg ICAgbGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAgIDEwOTY0NzMgICAgZW0wCjE5Mi4x NjguMC4yMjIgICAgICBsaW5rIzMgICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAg ICBsbzAKCkludGVybmV0NjoKRGVzdGluYXRpb24gICAgICAgICAgICAgICAgICAgICAgIEdhdGV3 YXkgICAgICAgICAgICAgICAgICAgICAgIEZsYWdzICAgICAgTmV0aWYgRXhwaXJlCjo6MSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBV SCAgICAgICAgICBsbzAKZmU4MDo6JWxvMC82NCAgICAgICAgICAgICAgICAgICAgIGxpbmsjMyAg ICAgICAgICAgICAgICAgICAgICAgIFUgICAgICAgICAgIGxvMApmZjAxOjM6Oi8zMiAgICAgICAg ICAgICAgICAgICAgICAgZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICAg bG8wCmZmMDI6OiVsbzAvMzIgICAgICAgICAgICAgICAgICAgICBmZTgwOjoxJWxvMCAgICAgICAg ICAgICAgICAgICBVICAgICAgICAgICBsbzAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hbkEK CkFjdGl2ZSBJbnRlcm5ldCBjb25uZWN0aW9ucyAoaW5jbHVkaW5nIHNlcnZlcnMpClRjcGNiICAg IFByb3RvIFJlY3YtUSBTZW5kLVEgIExvY2FsIEFkZHJlc3MgICAgICBGb3JlaWduIEFkZHJlc3Mg ICAoc3RhdGUpCmZmZmZmZjAwNWU5YjFjYTggdGNwNCAgICAgICAwICAgICAgMCAxOTIuMTY4LjAu MjIyLjIyICAgMTkyLjE2OC4wLjIzLjM1NzU0IFRJTUVfV0FJVAoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5l dHN0YXQgLWFMCgpDdXJyZW50IGxpc3RlbiBxdWV1ZSBzaXplcyAocWxlbi9pbmNxbGVuL21heHFs ZW4pClByb3RvIExpc3RlbiAgICAgICAgIExvY2FsIEFkZHJlc3MgICAgICAgICAKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpmc3RhdAoKU2VnbWVudGF0aW9uIGZhdWx0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZG1lc2cK CkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJp Z2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG cmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOC4wLUJFVEEyICMxNDogV2VkIEF1ZyAxOSAyMjo0 MzoxNyBDRVNUIDIwMDkKICAgIG9uaTBAaGFtc3RvcjovdXNyL29iai91c3Ivc3JjL3N5cy9IQU1T VE9SClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQ VTogQU1EIFNlbXByb24odG0pIFByb2Nlc3NvciBMRS0xMTAwICgxOTA4LjcwLU1IeiBLOC1jbGFz cyBDUFUpCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHg3MGZmMSAgU3RlcHBpbmcg PSAxCiAgRmVhdHVyZXM9MHg3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxD WDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1Is U1NFLFNTRTI+CiAgRmVhdHVyZXMyPTB4MjAwMTxTU0UzLENYMTY+CiAgQU1EIEZlYXR1cmVzPTB4 ZWE1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFJEVFNDUCxMTSwzRE5vdyErLDNETm93IT4K ICBBTUQgRmVhdHVyZXMyPTB4MTE5PExBSEYsRXh0QVBJQyxDUjgsUHJlZmV0Y2g+CnJlYWwgbWVt b3J5ICA9IDIxNDc0ODM2NDggKDIwNDggTUIpCmF2YWlsIG1lbW9yeSA9IDQwNDQzMjQ4NjQgKDM4 NTYgTUIpCkFDUEkgQVBJQyBUYWJsZTogPEdCVCAgICBOVkRBQUNQST4KaW9hcGljMDogQ2hhbmdp bmcgQVBJQyBJRCB0byAyCmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVy Ym9hcmQKa2JkMSBhdCBrYmRtdXgwCmFjcGkwOiA8R0JUIE5WREFBQ1BJPiBvbiBtb3RoZXJib2Fy ZAphY3BpMDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogcmVz ZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAw MDAwLCBjYmVmMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5j eSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAz LjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmFjcGlfaHBldDA6IDxIaWdo IFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWZmMDAwMC0weGZlZmYwM2ZmIG9uIGFj cGkwClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMjUwMDAwMDAgSHogcXVhbGl0eSA5MDAK YWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1Q Q0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIwCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0 dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNl IDEuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAx LjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKb2hjaTA6IDxuVmlkaWEgbkZvcmNlIE1DUDYxIFVTQiBD b250cm9sbGVyPiBtZW0gMHhlZjAwNzAwMC0weGVmMDA3ZmZmIGlycSAyMSBhdCBkZXZpY2UgMi4w IG9uIHBjaTAKb2hjaTA6IFtJVEhSRUFEXQp1c2J1czA6IDxuVmlkaWEgbkZvcmNlIE1DUDYxIFVT QiBDb250cm9sbGVyPiBvbiBvaGNpMAplaGNpMDogPE5WSURJQSBuRm9yY2UgTUNQNjEgVVNCIDIu MCBjb250cm9sbGVyPiBtZW0gMHhlZjAwNDAwMC0weGVmMDA0MGZmIGlycSAyMiBhdCBkZXZpY2Ug Mi4xIG9uIHBjaTAKZWhjaTA6IFtJVEhSRUFEXQp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNi dXMxOiA8TlZJRElBIG5Gb3JjZSBNQ1A2MSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnBj aWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kwCnBjaTE6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29u bmVjdGlvbiA2LjkuMTQ+IHBvcnQgMHhhMDAwLTB4YTAzZiBtZW0gMHhlYzAyMDAwMC0weGVjMDNm ZmZmLDB4ZWMwMDAwMDAtMHhlYzAxZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDcuMCBvbiBwY2kxCmVt MDogW0ZJTFRFUl0KZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxYjoyMToxNzoyZTo1ZApwY2kw OiA8bXVsdGltZWRpYSwgSERBPiBhdCBkZXZpY2UgNS4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0 YXBjaTA6IDxuVmlkaWEgbkZvcmNlIE1DUDYxIFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFm MC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGYwMDAtMHhmMDBmIGF0IGRldmljZSA2 LjAgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEwOiBbSVRIUkVB RF0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMTogW0lUSFJFQURdCnBjaTA6 IDxicmlkZ2U+IGF0IGRldmljZSA3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMTogPG5W aWRpYSBuRm9yY2UgTUNQNjEgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4OWYwLTB4OWY3LDB4 YmYwLTB4YmYzLDB4OTcwLTB4OTc3LDB4YjcwLTB4YjczLDB4ZGMwMC0weGRjMGYgbWVtIDB4ZWYw MDYwMDAtMHhlZjAwNmZmZiBpcnEgMjEgYXQgZGV2aWNlIDguMCBvbiBwY2kwCmF0YXBjaTE6IFtJ VEhSRUFEXQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEyOiBbSVRIUkVBRF0K YXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhMzogW0lUSFJFQURdCnBjaWIyOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24g cGNpMgpwY2kzOiA8UENJIGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDAuMiBvbiBwY2kyCnBjaTQ6IDxQQ0kgYnVzPiBvbiBwY2liNApocHRycjA6IDxzeDUw OHg+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhlOTAwMDAwMC0weGU5MGZmZmZmIGlycSAxNiBh dCBkZXZpY2UgNC4wIG9uIHBjaTQKaHB0cnI6IGFkYXB0ZXIgYXQgUENJIDQ6NDowLCBJUlEgMTYK dmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGVhMDAwMDAwLTB4ZWFmZmZm ZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZWQwMDAwMDAtMHhlZGZmZmZmZiBpcnEgMjIgYXQg ZGV2aWNlIDEzLjAgb24gcGNpMAphdHJ0YzE6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcw LTB4NzMgb24gYWNwaTAKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4 M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKdWFydDA6IFtGSUxURVJdCnBwYzA6IDxQYXJh bGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGFjcGkwCnBwYzA6IEdlbmVyaWMg Y2hpcHNldCAoTklCQkxFLW9ubHkpIGluIENPTVBBVElCTEUgbW9kZQpwcGMwOiBbSVRIUkVBRF0K cHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKcGxpcDA6IDxQTElQIG5ldHdvcmsg aW50ZXJmYWNlPiBvbiBwcGJ1czAKcGxpcDA6IFtJVEhSRUFEXQpscHQwOiA8UHJpbnRlcj4gb24g cHBidXMwCmxwdDA6IFtJVEhSRUFEXQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDog PFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKcG93ZXJu b3cwOiA8UG93ZXJOb3chIEs4PiBvbiBjcHUwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlv bWVtIDB4ZDAwMDAtMHhkM2ZmZiwweGQ0MDAwLTB4ZDRmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0g Y29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAt MHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNv bnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBL ZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1M T0NLRURdCmF0a2JkMDogW0lUSFJFQURdCmF0cnRjMDogPEFUIFJlYWwgVGltZSBDbG9jaz4gYXQg cG9ydCAweDcwIGlycSA4IG9uIGlzYTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9P LgphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJbnRlcnJ1cHQuClRpbWVjb3VudGVyICJU U0MiIGZyZXF1ZW5jeSAxOTA4Njk2NDc3IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKaHB0cnI6IHN0YXJ0IGNoYW5uZWwgWzAsMF0KaHB0cnI6IHN0YXJ0 IGNoYW5uZWwgWzAsMV0KaHB0cnI6IHN0YXJ0IGNoYW5uZWwgWzAsMl0KaHB0cnI6IHN0YXJ0IGNo YW5uZWwgWzAsM10KaHB0cnI6IGNoYW5uZWwgWzAsMF0gc3RhcnRlZCBzdWNjZXNzZnVsbHkKaHB0 cnI6IGNoYW5uZWwgWzAsMV0gc3RhcnRlZCBzdWNjZXNzZnVsbHkKaHB0cnI6IGNoYW5uZWwgWzAs Ml0gc3RhcnRlZCBzdWNjZXNzZnVsbHkKaHB0cnI6IGNoYW5uZWwgWzAsM10gc3RhcnRlZCBzdWNj ZXNzZnVsbHkKaHB0cnIwOiBbR0lBTlQtTE9DS0VEXQpocHRycjA6IFtJVEhSRUFEXQp1c2J1czA6 IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVT QiB2Mi4wCmFkMDogNzgxNjZNQiA8TWF4dG9yIDRSMDgwTDAgUkFNQjFUVTA+IGF0IGF0YTAtbWFz dGVyIFVETUExMzMKYWQ0OiA3MTU0MDRNQiA8U0FNU1VORyBIRDc1M0xKIDFBQTAxMTA5PiBhdCBh dGEyLW1hc3RlciBTQVRBMzAwCmFkNjogNzE1NDA0TUIgPFNBTVNVTkcgSEQ3NTNMSiAxQUEwMTEw OT4gYXQgYXRhMy1tYXN0ZXIgU0FUQTMwMApHRU9NOiBhZDBzMTogZ2VvbWV0cnkgZG9lcyBub3Qg bWF0Y2ggbGFiZWwgKDI1NWgsNjNzICE9IDE2aCw2M3MpLgp1Z2VuMC4xOiA8blZpZGlhPiBhdCB1 c2J1czAKdWh1YjA6IDxuVmlkaWEgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1aHViMDogMTAgcG9ydHMgd2l0aCAxMCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1Z2VuMS4xOiA8blZpZGlhPiBhdCB1c2J1czEKdWh1YjE6IDxuVmlkaWEg RUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz MQpkYTAgYXQgaHB0cnIwIGJ1cyAwIHRhcmdldCAwIGx1biAwCmRhMDogPEhQVCBESVNLIDBfMCA0 LjAwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCmRhMSBhdCBocHRycjAgYnVz IDAgdGFyZ2V0IDEgbHVuIDAKZGExOiA8SFBUIERJU0sgMF8xIDQuMDA+IEZpeGVkIERpcmVjdCBB Y2Nlc3MgU0NTSS0wIGRldmljZSAKZGEyIGF0IGhwdHJyMCBidXMgMCB0YXJnZXQgMiBsdW4gMApk YTI6IDxIUFQgRElTSyAwXzIgNC4wMD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNl IApkYTMgYXQgaHB0cnIwIGJ1cyAwIHRhcmdldCAzIGx1biAwCmRhMzogPEhQVCBESVNLIDBfMyA0 LjAwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgClJvb3QgbW91bnQgd2FpdGlu ZyBmb3I6IHVzYnVzMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEKUm9vdCBtb3VudCB3 YWl0aW5nIGZvcjogdXNidXMxClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMQp1aHViMTog MTAgcG9ydHMgd2l0aCAxMCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQp1Z2VuMC4yOiA8RGFyZm9uPiBhdCB1c2J1czAKdWti ZDA6IDxEYXJmb24gVVNCIENvbWJvIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuMDIs IGFkZHIgMj4gb24gdXNidXMwCmtiZDIgYXQgdWtiZDAKRW50cm9weSBoYXJ2ZXN0aW5nOgogaW50 ZXJydXB0cwogZXRoZXJuZXQKIHBvaW50X3RvX3BvaW50CiBraWNrc3RhcnQKLgovZGV2L2FkMHMx YTogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2FkMHMxYTogY2xlYW4s IDUxODg4IGZyZWUgKDEzOTIgZnJhZ3MsIDYzMTIgYmxvY2tzLCAwLjMlIGZyYWdtZW50YXRpb24p Ci9kZXYvYWQwczFmOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQw czFmOiBjbGVhbiwgMzA2ODg4NTQgZnJlZSAoMTU1NjIyIGZyYWdzLCAzODE2NjU0IGJsb2Nrcywg MC41JSBmcmFnbWVudGF0aW9uKQovZGV2L2FkMHMxZDogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQ SU5HIENIRUNLUwovZGV2L2FkMHMxZDogY2xlYW4sIDIzNjc0NDQgZnJlZSAoNjEyIGZyYWdzLCAy OTU4NTQgYmxvY2tzLCAwLjAlIGZyYWdtZW50YXRpb24pCldBUk5JTkc6IFpGUyBpcyBjb25zaWRl cmVkIHRvIGJlIGFuIGV4cGVyaW1lbnRhbCBmZWF0dXJlIGluIEZyZWVCU0QuClpGUyBmaWxlc3lz dGVtIHZlcnNpb24gMTMKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDEzClN0YXJ0aW5nIE5ldHdv cms6IGxvMCBlbTAuCmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxOTIuMTY4LjAuMQpDb25maWd1 cmluZyBrZXlib2FyZDoKIGtleW1hcAoga2V5cmF0ZQouClJ1bm5pbmc6IC91c3IvbG9jYWwvc2Jp bi9wdXJlLWZ0cGQgLWM1MCAtQiAtQzggLUQgLUUgLWZmdHAgLUggLUkxNSAtbHVuaXggLUwyMDAw OjggLW00IC1TMTkyLjE2OC4wLjIyMiw2NTIyMiAtVTAyMjowMjIgLXcgLVIKZW0wOiBsaW5rIHN0 YXRlIGNoYW5nZWQgdG8gVVAKUmVtb3Zpbmcgc3RhbGUgU2FtYmEgdGRiIGZpbGVzOiAKLgouCiBk b25lCkNvbmZpZ3VyaW5nIHN5c2NvbnM6CiBrZXltYXAKIGtleXJhdGUKIGZvbnQ4eDE2CiBmb250 OHgxNAogZm9udDh4OAogYmxhbmt0aW1lCiBzY3JlZW5zYXZlcgouCgpTYXQgQXVnIDIyIDA4OjI5 OjI4IENFU1QgMjAwOQpBdWcgMjIgMTA6MDE6MjIgaGFtc3RvciBzdTogb25pMCB0byByb290IG9u IC9kZXYvcHRzLzAKQXVnIDIyIDEwOjQ3OjIzIGhhbXN0b3Igc2h1dGRvd246IHBvd2VyLWRvd24g Ynkgb25pMDogClN0b3BwaW5nIGluZXRkLgpTdG9wcGluZyBjcm9uLgpTdG9wcGluZyBzc2hkLgpT dG9wcGluZyBwb3dlcmQuClN0b3BwaW5nIHNtYmQuClN0b3BwaW5nIG5tYmQuClN0b3BwaW5nIHB1 cmVmdHBkLgpTdG9wcGluZyBkZXZkLgpXcml0aW5nIGVudHJvcHkgZmlsZToKLgpUZXJtaW5hdGVk Ci4KQXVnIDIyIDEwOjQ3OjI2IGhhbXN0b3Igc3lzbG9nZDogZXhpdGluZyBvbiBzaWduYWwgMTUK V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0 b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1 ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1h aW5pbmcuLi4xIDEgMSAwIDAgZG9uZQpBbGwgYnVmZmVycyBzeW5jZWQuCnpmc191bW91bnQ6OTcx WzBdOiBGb3JjZSB1bm1vdW50IGlzIGV4cGVyaW1lbnRhbCAtIHJlcG9ydCBhbnkgcHJvYmxlbXMu ClVwdGltZTogMmgxOG0yN3MKcGFuaWM6IGFwaWNfZnJlZV92ZWN0b3I6IFRocmVhZCBhbHJlYWR5 IGJvdW5kLgoKY3B1aWQgPSAwCktEQjogZW50ZXI6IHBhbmljClBoeXNpY2FsIG1lbW9yeTogNDAy MiBNQgpEdW1waW5nIDE1OTIgTUI6IDE1NzcgMTU2MSAxNTQ1IDE1MjkgMTUxMyAxNDk3IDE0ODEg MTQ2NSAxNDQ5IDE0MzMgMTQxNyAxNDAxIDEzODUgMTM2OSAxMzUzIDEzMzcgMTMyMSAxMzA1IDEy ODkgMTI3MyAxMjU3IDEyNDEgMTIyNSAxMjA5IDExOTMgMTE3NyAxMTYxIDExNDUgMTEyOSAxMTEz IDEwOTcgMTA4MSAxMDY1IDEwNDkgMTAzMyAxMDE3IDEwMDEgOTg1IDk2OSA5NTMgOTM3IDkyMSA5 MDUgODg5IDg3MyA4NTcgODQxIDgyNSA4MDkgNzkzIDc3NyA3NjEgNzQ1IDcyOSA3MTMgNjk3IDY4 MSA2NjUgNjQ5IDYzMyA2MTcgNjAxIDU4NSA1NjkgNTUzIDUzNyA1MjEgNTA1IDQ4OSA0NzMgNDU3 IDQ0MSA0MjUgNDA5IDM5MyAzNzcgMzYxIDM0NSAzMjkgMzEzIDI5NyAyODEgMjY1IDI0OSAyMzMg MjE3IDIwMSAxODUgMTY5IDE1MyAxMzcgMTIxIDEwNSA4OSA3MyA1NyA0MSAyNSA5CgotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0Ka2VybmVsIGNvbmZpZwoKY29uZmlnOiBGaWxlIC9ib290L2tlcm5lbC9rZXJuZWwg ZG9lc24ndCBjb250YWluIGNvbmZpZ3VyYXRpb24gZmlsZS4gRWl0aGVyIHVuc3VwcG9ydGVkLCBv ciBub3QgY29tcGlsZWQgd2l0aCBJTkNMVURFX0NPTkZJR19GSUxFCg== --Multipart=_Sat__22_Aug_2009_11_59_58_+0200_zCtc9HKhe3=WgH/u-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 10:08:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CA8106568C for ; Sat, 22 Aug 2009 10:08:02 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 8ED4B8FC1A for ; Sat, 22 Aug 2009 10:08:01 +0000 (UTC) Received: (qmail 3886 invoked by uid 89); 22 Aug 2009 10:08:00 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 22 Aug 2009 10:08:00 -0000 Date: Sat, 22 Aug 2009 12:08:09 +0200 From: Oliver Lehmann To: freebsd-current@freebsd.org Message-Id: <20090822120809.b749c7e8.lehmann@ans-netz.de> In-Reply-To: <20090822114802.df02b57d.lehmann@ans-netz.de> References: <20090822114802.df02b57d.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.5; amd64-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Aug 2009 13:51:48 +0000 Subject: Re: no /sbin/gpt on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 10:08:02 -0000 Hi, by luck I found out, that gpt got replaced by gpart now. When adding a partition it is easy to have gpart coredump: # gpart create -s GPT /dev/da2 da2 created # gpart add -t freebsd-ufs /dev/da2 Segmentation fault (core dumped) # gpart add -t freebsd-ufs da2 da2p1 added This should not happen - right? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 10:14:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989D31065693 for ; Sat, 22 Aug 2009 10:14:36 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 399058FC14 for ; Sat, 22 Aug 2009 10:14:35 +0000 (UTC) Received: (qmail 3429 invoked by uid 89); 22 Aug 2009 09:47:54 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 22 Aug 2009 09:47:54 -0000 Date: Sat, 22 Aug 2009 11:48:02 +0200 From: Oliver Lehmann To: freebsd-current@freebsd.org Message-Id: <20090822114802.df02b57d.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.5; amd64-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Aug 2009 13:51:56 +0000 Subject: no /sbin/gpt on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 10:14:36 -0000 Hi, I installed a "minmal" 8.0-BETA2 from the ISO but I don't have a /sbin/gpt. I'll now build it from source, but I guess something went wrong with the ISO creation or is it included in some other "package" not installed by the minimal installation? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 14:13:10 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC2AA1065692; Sat, 22 Aug 2009 14:13:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 874238FC1A; Sat, 22 Aug 2009 14:13:10 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id ED75C46B1A; Sat, 22 Aug 2009 10:13:09 -0400 (EDT) Date: Sat, 22 Aug 2009 15:13:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pete French In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: Quick 8.0 update: BETA3 builds in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 14:13:10 -0000 On Sat, 22 Aug 2009, Pete French wrote: >> I don't have a specific ETA on BETA3 going out the door, except to say that >> so far several architectures have reported back on successful builds, so >> probably quite soon. > > Is there any point in making bug reports for BETA2 at this point ? I only > got to try it a coupleof days ago, and had a big issue with installing (had > to use 7.2 to partition the drive) but I am thinkingthat maybe just waiting > and re-doing the test with BETA3 is better ? I think it's probably more useful to wait a day and retry with BETA3. I don't know that the issue you're experiencing has been fixed, but given that there were some partitioning-related fixes (see the wiki page for a complete list) it's possible that something like it was. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 14:07:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95811106568C; Sat, 22 Aug 2009 14:07:41 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5D60B8FC13; Sat, 22 Aug 2009 14:07:41 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MerFf-000Ilj-LA; Sat, 22 Aug 2009 15:07:27 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MerFf-000ARg-KF; Sat, 22 Aug 2009 15:07:27 +0100 To: current@FreeBSD.org, rwatson@FreeBSD.org In-Reply-To: Message-Id: From: Pete French Date: Sat, 22 Aug 2009 15:07:27 +0100 X-Mailman-Approved-At: Sat, 22 Aug 2009 14:14:27 +0000 Cc: stable@FreeBSD.org Subject: Re: Quick 8.0 update: BETA3 builds in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 14:07:41 -0000 > I don't have a specific ETA on BETA3 going out the door, except to say that so > far several architectures have reported back on successful builds, so probably > quite soon. Is there any point in making bug reports for BETA2 at this point ? I only got to try it a coupleof days ago, and had a big issue with installing (had to use 7.2 to partition the drive) but I am thinkingthat maybe just waiting and re-doing the test with BETA3 is better ? cheers, -pete. From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 14:08:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9F31065693 for ; Sat, 22 Aug 2009 14:08:35 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost2.zedat.fu-berlin.de (outpost2.zedat.fu-berlin.de [130.133.4.90]) by mx1.freebsd.org (Postfix) with ESMTP id 988668FC17 for ; Sat, 22 Aug 2009 14:08:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1MerGk-0004vI-Nn>; Sat, 22 Aug 2009 16:08:34 +0200 Received: from e178003223.adsl.alicedsl.de ([85.178.3.223] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1MerGk-0003ut-L5>; Sat, 22 Aug 2009 16:08:34 +0200 Message-ID: <4A8FFBE2.3040600@mail.zedat.fu-berlin.de> Date: Sat, 22 Aug 2009 16:08:34 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.22 (X11/20090723) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.3.223 X-Mailman-Approved-At: Sat, 22 Aug 2009 14:14:47 +0000 Subject: JAVA: Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 14:08:35 -0000 I can not run java nor can I install packages depending on diablo-jdk16. The error occuring is: Error occurred during initialization of VM Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so I deleted and reinstalled port diablo-jdk16, but with no success ... what is wrong? Even Openoffice won't compile when JAVA support is enabled (and neccessary). Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 14:35:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9EC106568D; Sat, 22 Aug 2009 14:35:38 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.yandex.ru (forward13.yandex.ru [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id F3DE38FC08; Sat, 22 Aug 2009 14:35:37 +0000 (UTC) Received: from smtp12.yandex.ru (smtp12.yandex.ru [95.108.131.191]) by forward13.yandex.ru (Yandex) with ESMTP id 306C8A78421; Sat, 22 Aug 2009 18:35:36 +0400 (MSD) Received: from btr.properlan.net (butcher.heavennet.ru [77.72.136.194]) by smtp12.yandex.ru (Yandex) with ESMTPSA id CF4AF4CC012D; Sat, 22 Aug 2009 18:35:35 +0400 (MSD) Message-ID: <4A900234.1030202@yandex.ru> Date: Sat, 22 Aug 2009 18:35:32 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.22 (X11/20090821) MIME-Version: 1.0 To: Oliver Lehmann References: <20090822114802.df02b57d.lehmann@ans-netz.de> <20090822120809.b749c7e8.lehmann@ans-netz.de> In-Reply-To: <20090822120809.b749c7e8.lehmann@ans-netz.de> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1250951736 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.yandex.ru Cc: freebsd-current@freebsd.org, marcel@freebsd.org Subject: Re: no /sbin/gpt on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 14:35:38 -0000 Oliver Lehmann wrote: > # gpart create -s GPT /dev/da2 > da2 created > # gpart add -t freebsd-ufs /dev/da2 > Segmentation fault (core dumped) > # gpart add -t freebsd-ufs da2 > da2p1 added > > This should not happen - right? It fixed in BETA3. http://www.freebsd.org/cgi/query-pr.cgi?pr=137656 But, i think gpart will report about nonexistent geom when you will try to use "/dev/da2" sintax. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 15:16:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5895C106568E for ; Sat, 22 Aug 2009 15:16:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0BE8FC19 for ; Sat, 22 Aug 2009 15:16:09 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n7MFG895073627; Sat, 22 Aug 2009 08:16:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n7MFG8mq073626; Sat, 22 Aug 2009 08:16:08 -0700 (PDT) (envelope-from sgk) Date: Sat, 22 Aug 2009 08:16:08 -0700 From: Steve Kargl To: "O. Hartmann" Message-ID: <20090822151608.GB73524@troutmask.apl.washington.edu> References: <4A8FFBE2.3040600@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8FFBE2.3040600@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: JAVA: Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 15:16:09 -0000 On Sat, Aug 22, 2009 at 04:08:34PM +0200, O. Hartmann wrote: > I can not run java nor can I install packages depending on diablo-jdk16. > > The error occuring is: > > Error occurred during initialization of VM > Unable to load ZIP library: > /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so > > I deleted and reinstalled port diablo-jdk16, but with no success ... > what is wrong? > Search the java mailing list archive. REMOVE:root[11] cat /etc/libmap.conf # # candidate mapping # libz.so.4 libz.so.5 -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 16:43:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B43106568B for ; Sat, 22 Aug 2009 16:43:50 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6C58FC12 for ; Sat, 22 Aug 2009 16:43:49 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n7MGhm12049522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Aug 2009 09:43:49 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A902044.1010200@errno.com> Date: Sat, 22 Aug 2009 09:43:48 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: current@freebsd.org References: <20090821074506.GT70474@acme.spoerlein.net> <20090821103139.66925eb3@vlado.suse.cz> <20090821183806.GG91417@acme.spoerlein.net> In-Reply-To: <20090821183806.GG91417@acme.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Vladimir Botka Subject: Re: [regression] iwi0 with WPA on 8.0 - FIXED, pilot error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 16:43:50 -0000 Ulrich Spörlein wrote: > On Fri, 21.08.2009 at 10:31:39 +0200, Vladimir Botka wrote: >> It seems that there is no problem with WPA. The wpa_supplicant >> associates. You can see the message. >> >> wpa_supplicant[481]: Associated with 00:21:27:f3:37:37 >> >> Run the wpa_supplicant with more debug info to get more information why >> the wpa_supplicant disconnects later. >> >> wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect > > It is a combination of setting the MAC address that makes wpa_supplicant > barf. These settings in rc.conf result in broken wpa_supplicant during > boot: > > ifconfig_bfe0="up" > ifconfig_iwi0="up" > wlans_iwi0="wlan0" > ifconfig_wlan0="WPA ether 00:0f:1f:1d:a3:76 ssid COYOTE" > cloned_interfaces="lagg0" > ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0" > > Result > > iwi0: timeout waiting for (null) firmware initialization to complete > iwi0: could not load boot firmware (null) > iwi0: timeout waiting for (null) firmware initialization to complete > iwi0: could not load boot firmware (null) > wlan0: Ethernet address: 00:15:00:22:26:61 > iwi0: need multicast update callback > iwi0: need multicast update callback > iwi0: need multicast update callback > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > > As you can see, wlan0 is created with the wrong MAC address and > wpa_supplicant does not like different MACs on the wlanX dev and the > real hardware. > > These settings now work. Everything is well > > ifconfig_bfe0="up" > ifconfig_iwi0="ether 00:0f:1f:1d:a3:76 up" > wlans_iwi0="wlan0" > ifconfig_wlan0="WPA ssid COYOTE" > cloned_interfaces="lagg0" > ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0" It so happens I've been discussing this issue with someone else. The lagg setup is documented in the EXAMPLES section of lagg(4) and doing things this way will be necessary for 8.0. Changing the mac address of a vap after it is created does not work right and may never work for certain devices. There are issues in how the ifnet layer handles this operation and when there are multiple vap's present it is unclear how to handle this operation (if it's possible at all). Devices like iwn that do not support multi-bssid can handle dynamically changing the mac address but not w/o some changes to the infrastructure. For now you need to force the mac address of the underlying device so cloned ifnet's inherit the new address. Sam From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 17:20:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6D6106568F for ; Sat, 22 Aug 2009 17:20:21 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 4D56E8FC14 for ; Sat, 22 Aug 2009 17:20:20 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7MHKKRM044699 for ; Sat, 22 Aug 2009 19:20:20 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7MHKJwE015871 for ; Sat, 22 Aug 2009 19:20:19 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7MHKJJN015868; Sat, 22 Aug 2009 19:20:19 +0200 (CEST) (envelope-from arno) To: current@freebsd.org From: "Arno J. Klaassen" Date: Sat, 22 Aug 2009 19:20:18 +0200 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9727/Sat Aug 22 16:04:10 2009 on shiva.jussieu.fr X-Virus-Status: Clean Cc: Subject: [regression] : 8.0-BETA3 (and BETA2?) acpi_hpet0 fails on TYAN H2000M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 17:20:21 -0000 Hello, I have a regression with acpi_hpet on a Tyan H2000M MB : acpi_hpet0: iomem 0xfed00000-0xfed03fff on acpi0 acpi_hpet0: HPET never increments, disabling device_attach: acpi_hpet0 attach returned 6 [twice] it exists at least since Aug16 sources (I just looked at the 'netif' problems on this board which BTW are indeed fixed by recent flowtable init changes) I dug up an old email from March of this year when it worked OK : FreeBSD 8.0-CURRENT #1: Sun Mar 1 23:38:34 CET 2009 toor@siamesetwins:/usr/obj/raid1/bsd/src-current/sys/S3992 ... Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Googling learned me that this could be a BIOS issue, but I did not touch the BIOS of this board since ages and the explicit HPET-enable option in any case does not exist in mine. I can choose between "ACPI Version Features" [ACPI v2.0, v1.0, v3.0]: I use v2.0 and changing for v3.0 or v1.0 does not help. I noticed this by 'vmstat -i' shortly after boot : cpu0: timer 20596 1872 cpu1: timer 12896 1172 cpu3: timer 12929 1175 cpu4: timer 11137 1012 cpu2: timer 11006 1000 cpu5: timer 12835 1166 cpu6: timer 12930 1175 cpu7: timer 12930 1175 I can't remember ever have seen so low values (they used to be around 1990 shortly after boot) which make me think this rather recently stopped working. Non-verbose dmesg below; let me know what I could provide as other info. Thanx, Arno ##### dmesg : Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA3 #1: Sat Aug 22 15:45:26 CEST 2009 toor@siamesetwins:/zfiles/obj/raid1/bsd/8/src/sys/S3992-E Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Quad-Core AMD Opteron(tm) Processor 2354 (2194.52-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 9663676416 (9216 MB) avail memory = 8255045632 (7872 MB) ACPI APIC Table: <101308 APIC1100> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 acpi0: <101308 XSDT1100> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb41f mem 0xfeffe000-0xfeffffff irq 11 at device 14.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] isab0: at device 2.2 on pci0 isa0: on isab0 pci0: at device 4.0 (no driver attached) pcib3: at device 6.0 on pci0 pci3: on pcib3 pcib4: at device 7.0 on pci0 pci4: on pcib4 pci4: at device 4.0 (no driver attached) pci4: at device 4.1 (no driver attached) pcib5: at device 8.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci7: on pcib6 aac0: mem 0xff400000-0xff5fffff irq 28 at device 14.0 on pci7 aac0: Enabling 64-bit address support aac0: Enable Raw I/O aac0: Enable 64-bit array aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 3405, aac driver 2.0.0-1 aacp0: on aac0 aacp1: on aac0 aacp2: on aac0 pcib7: at device 0.2 on pci5 pci6: on pcib7 pcib8: at device 9.0 on pci0 pci8: on pcib8 pcib9: at device 10.0 on pci0 pci9: on pcib9 pcib10: at device 11.0 on pci0 pci10: on pcib10 vgapci0: port 0xe000-0xe0ff mem 0xd8000000-0xdfffffff,0xff6f0000-0xff6fffff irq 17 at device 12.0 on pci0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] acpi_hpet0: iomem 0xfed00000-0xfed03fff on acpi0 acpi_hpet0: HPET never increments, disabling device_attach: acpi_hpet0 attach returned 6 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed03fff on acpi0 acpi_hpet0: HPET never increments, disabling device_attach: acpi_hpet0 attach returned 6 From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 15:22:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D48C106568E for ; Sat, 22 Aug 2009 15:22:44 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 9ACA18FC19 for ; Sat, 22 Aug 2009 15:22:43 +0000 (UTC) Received: (qmail 10297 invoked by uid 89); 22 Aug 2009 15:22:41 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 22 Aug 2009 15:22:41 -0000 Date: Sat, 22 Aug 2009 17:22:50 +0200 From: Oliver Lehmann To: "Andrey V. Elsukov" Message-Id: <20090822172250.3eaa80fe.lehmann@ans-netz.de> In-Reply-To: <4A900234.1030202@yandex.ru> References: <20090822114802.df02b57d.lehmann@ans-netz.de> <20090822120809.b749c7e8.lehmann@ans-netz.de> <4A900234.1030202@yandex.ru> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.5; amd64-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Aug 2009 17:42:40 +0000 Cc: freebsd-current@freebsd.org, marcel@freebsd.org Subject: Re: no /sbin/gpt on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 15:22:44 -0000 Andrey V. Elsukov wrote: > Oliver Lehmann wrote: > > # gpart create -s GPT /dev/da2 > > da2 created > > # gpart add -t freebsd-ufs /dev/da2 > > Segmentation fault (core dumped) > > # gpart add -t freebsd-ufs da2 > > da2p1 added > > > > This should not happen - right? > > It fixed in BETA3. > http://www.freebsd.org/cgi/query-pr.cgi?pr=137656 > > But, i think gpart will report about nonexistent geom when you > will try to use "/dev/da2" sintax. Are you sure it is the same error? Why is it working with a full path when working with a gmirror object? # gpart add -b 1572864 -s 262144 -t freebsd-swap -i 2 /dev/mirror/gm0s1 mirror/gm0s1b added Why isn't it segfaulting here? I already opend a PR... http://www.freebsd.org/cgi/query-pr.cgi?pr=138065 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 19:16:58 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5E17106568E for ; Sat, 22 Aug 2009 19:16:58 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9D68FC1A for ; Sat, 22 Aug 2009 19:16:56 +0000 (UTC) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 4437ED1B13E for ; Sat, 22 Aug 2009 20:58:56 +0200 (CEST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id E1F6C9400B1 for ; Sat, 22 Aug 2009 20:58:50 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0FF029400D6 for ; Sat, 22 Aug 2009 20:58:48 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id D808236313 for ; Sat, 22 Aug 2009 18:58:12 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id B63C6A2538; Sat, 22 Aug 2009 18:58:12 +0000 (UTC) Date: Sat, 22 Aug 2009 20:58:12 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20090822185812.GC61707@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: truss(1) locked in kernel with 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 19:16:58 -0000 Hi, I've upgraded my laptop to 8.0-BETA2 and ran portupgrade in script(1). But according to top, it seems script(1) is going crazy, even after I've hit ^C: % CPU: 0.0% user, 7.9% nice, 92.1% system, 0.0% interrupt, 0.0% idle % Mem: 64M Active, 675M Inact, 141M Wired, 21M Cache, 111M Buf, 90M Free % Swap: 1024M Total, 1024M Free % % PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND % 47998 root 1 128 10 3344K 788K RUN 3:02 100.00% script jarjarbinks:~:7# procstat -k 47998 PID TID COMM TDNAME KSTACK 47998 100087 script - mi_switch critical_exit intr_event_handle intr_execute_handlers lapic_handle_intr Xapic_isr1 binuptime bintime microtime gettimeofday syscall Xint0x80_syscall truss(1) show the following sequence infinitely: % gettimeofday({1250965404.830938 },0x0) = 0 (0x0) % select(5,{0 4},0x0,0x0,{30.000000 }) = 1 (0x1) % read(0,0xbfbfdf5c,1024) = 0 (0x0) % write(4,0xbfbfdf5c,0) = 0 (0x0) And when I try to stop truss, it nevers end and seems to be blocked in kernel: ps aux: root 49506 0.0 0.1 3284 912 2 I+ 8:23PM 0:00.06 truss -p 47998 root 47998 0.0 0.1 3344 788 1 TNX+ 8:39AM 6:37.36 /usr/bin/script -qa /tmp/portupgrade20090822-4080-3knxs0-0 env UPGRA procstat -k: 49506 100121 truss - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscall Xint0x80_syscall 47998 100087 script - mi_switch thread_suspend_switch ptracestop syscall Xint0x80_syscall Note that once I've truss(1)'ed script(1), it stops consuming all the CPU cycles. It seems to be deadlocked, but DDB shows only one lock. So this is not a deadlock stricly speaking, but obviously truss(1) is waiting for something that will never come but nonetheless I can kill it with a SIGKILL. The same thing can happen with dialog(1); truss shows: % read(0,0xbfbfcf10,1) = 0 (0x0) % read(0,0xbfbfcf10,1) = 0 (0x0) % read(0,0xbfbfcf10,1) = 0 (0x0) % read(0,0xbfbfcf10,1) = 0 (0x0) And so on. And after ^C the processes are staled in the same state in the kernel. I've reproduced this twice in a row across a reboot. I think I can reproduce it on demand. Any idea woul be welcome. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 19:40:09 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB06B106568C for ; Sat, 22 Aug 2009 19:40:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id B44248FC1B for ; Sat, 22 Aug 2009 19:40:09 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 2E33E1CD18; Sat, 22 Aug 2009 21:40:09 +0200 (CEST) Date: Sat, 22 Aug 2009 21:40:09 +0200 From: Ed Schouten To: Jeremie Le Hen Message-ID: <20090822194009.GQ1292@hoeg.nl> References: <20090822185812.GC61707@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x6I3On15oG0ucwLF" Content-Disposition: inline In-Reply-To: <20090822185812.GC61707@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: truss(1) locked in kernel with 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 19:40:10 -0000 --x6I3On15oG0ucwLF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeremie, * Jeremie Le Hen wrote: > I've upgraded my laptop to 8.0-BETA2 and ran portupgrade in script(1). > But according to top, it seems script(1) is going crazy, even after I've > hit ^C: The fact that script(1) is going crazy, is a known issue. I have been pointed to this issue earlier, but unfortunately I don't know what to do. A certain Colin introduced this bug about 6 years ago. ;-) It's basically a shortcoming of pseudo-terminals in general. script(1) wants to behave in a way which cannot be implemented using pseudo-terminals; when it receives a hangup on its standard input (on the outside), it wants to propagate the end-of-file condition and wants to continue until the child processes are finished, instead of shutting down immediately. So a couple of milliseconds later on, it calls select(2) again, but because the TTY it uses on the outside is still in a hangup condition, select(2) returns immediately. This can easily be reproduced as follows: script < /dev/null I think the only way we can sanely fix this, is by adding a special flag to instruct script(1) to keep going on, even if stdin disappears. I wrote a patch for this back in May: http://80386.nl/pub/script.diff Thanks for reminding me. I should contact re@ about this. --=20 Ed Schouten WWW: http://80386.nl/ --x6I3On15oG0ucwLF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqQSZkACgkQ52SDGA2eCwV7eACfUDMFGzBk5er27FAFuwO+OF6y vIoAn2KUrp4ZsgmIP6OMlCoW+9MtAeTr =FNGJ -----END PGP SIGNATURE----- --x6I3On15oG0ucwLF-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 19:47:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 148EF1065693 for ; Sat, 22 Aug 2009 19:47:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A148B8FC34 for ; Sat, 22 Aug 2009 19:47:38 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7MJlOLo027070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Aug 2009 22:47:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7MJlOBX051130; Sat, 22 Aug 2009 22:47:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7MJlOY2051129; Sat, 22 Aug 2009 22:47:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Aug 2009 22:47:24 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20090822194724.GE9623@deviant.kiev.zoral.com.ua> References: <20090822185812.GC61707@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kh0gS47ASyprwiQo" Content-Disposition: inline In-Reply-To: <20090822185812.GC61707@felucia.tataz.chchile.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: truss(1) locked in kernel with 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 19:47:39 -0000 --kh0gS47ASyprwiQo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 22, 2009 at 08:58:12PM +0200, Jeremie Le Hen wrote: > Hi, >=20 > I've upgraded my laptop to 8.0-BETA2 and ran portupgrade in script(1). > But according to top, it seems script(1) is going crazy, even after I've > hit ^C: >=20 > % CPU: 0.0% user, 7.9% nice, 92.1% system, 0.0% interrupt, 0.0% idle > % Mem: 64M Active, 675M Inact, 141M Wired, 21M Cache, 111M Buf, 90M Free > % Swap: 1024M Total, 1024M Free > %=20 > % PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > % 47998 root 1 128 10 3344K 788K RUN 3:02 100.00% scri= pt >=20 > jarjarbinks:~:7# procstat -k 47998 > PID TID COMM TDNAME KSTACK = =20 > 47998 100087 script - mi_switch critical_exit in= tr_event_handle intr_execute_handlers lapic_handle_intr Xapic_isr1 binuptim= e bintime microtime gettimeofday syscall Xint0x80_syscall=20 >=20 > truss(1) show the following sequence infinitely: > % gettimeofday({1250965404.830938 },0x0) =3D 0 (0x0) > % select(5,{0 4},0x0,0x0,{30.000000 }) =3D 1 (0x1) > % read(0,0xbfbfdf5c,1024) =3D 0 (0x0) > % write(4,0xbfbfdf5c,0) =3D 0 (0x0) >=20 > And when I try to stop truss, it nevers end and seems to be blocked in ke= rnel: >=20 > ps aux: > root 49506 0.0 0.1 3284 912 2 I+ 8:23PM 0:00.06 truss -p 4= 7998 > root 47998 0.0 0.1 3344 788 1 TNX+ 8:39AM 6:37.36 /usr/bin/s= cript -qa /tmp/portupgrade20090822-4080-3knxs0-0 env UPGRA >=20 > procstat -k: > 49506 100121 truss - mi_switch sleepq_switch sl= eepq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscall Xint0x80_= syscall > 47998 100087 script - mi_switch thread_suspend_s= witch ptracestop syscall Xint0x80_syscall=20 > Note that once I've truss(1)'ed script(1), it stops consuming all the > CPU cycles. It seems to be deadlocked, but DDB shows only one lock. So > this is not a deadlock stricly speaking, but obviously truss(1) is > waiting for something that will never come but nonetheless I can kill it > with a SIGKILL. >=20 >=20 > The same thing can happen with dialog(1); truss shows: > % read(0,0xbfbfcf10,1) =3D 0 (0x0) > % read(0,0xbfbfcf10,1) =3D 0 (0x0) > % read(0,0xbfbfcf10,1) =3D 0 (0x0) > % read(0,0xbfbfcf10,1) =3D 0 (0x0) >=20 > And so on. And after ^C the processes are staled in the same state in > the kernel. >=20 > I've reproduced this twice in a row across a reboot. I think I can > reproduce it on demand. Does kill -9 kills truss ? I expect that it does, and then the debuggee is killable. --kh0gS47ASyprwiQo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqQS0sACgkQC3+MBN1Mb4izCQCgw7TAJ4w7EW7eu1nzwZcV/vjL 8sQAoIYH4ruzjbrrgLAn1FPZPZ9UvWdt =c27E -----END PGP SIGNATURE----- --kh0gS47ASyprwiQo-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 20:03:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB7F3106568B for ; Sat, 22 Aug 2009 20:03:35 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4C36B8FC0A for ; Sat, 22 Aug 2009 20:03:34 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7MK3XMP098807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Aug 2009 22:03:33 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Jeremie Le Hen In-Reply-To: <20090822185812.GC61707@felucia.tataz.chchile.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 Aug 2009 22:03:33 +0200 References: <20090822185812.GC61707@felucia.tataz.chchile.org> X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: truss(1) locked in kernel with 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 20:03:35 -0000 Am 22.08.2009 um 20:58 schrieb Jeremie Le Hen: > The same thing can happen with dialog(1); truss shows: > % read(0,0xbfbfcf10,1) = 0 (0x0) > % read(0,0xbfbfcf10,1) = 0 (0x0) > % read(0,0xbfbfcf10,1) = 0 (0x0) > % read(0,0xbfbfcf10,1) = 0 (0x0) > > And so on. And after ^C the processes are staled in the same state in > the kernel. I've noticed the dialog issue some years ago, and finally managed to put a patch together. See PR#137665. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Aug 22 21:11:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8808D106568D for ; Sat, 22 Aug 2009 21:11:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE548FC19 for ; Sat, 22 Aug 2009 21:11:13 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 910EC8465; Sat, 22 Aug 2009 21:11:11 +0000 (UTC) Date: Sat, 22 Aug 2009 22:10:57 +0100 From: Bruce Cran To: Thomas Backman Message-ID: <20090822221057.5429428c@gluon.draftnet> In-Reply-To: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> References: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 21:11:13 -0000 On Wed, 29 Jul 2009 22:19:47 +0200 Thomas Backman wrote: > All the info I happen to have: > > (from core.txt.X) > "ps -axl > > Segmentation fault (core dumped)" > > The last core I got (/ps.core) was 1076211712 bytes (1026 MiB). > > Anyone else with this problem? > Unfortunately, I deleted the most recent core and so can't gdb it, > at least not right now. I did try it on the first one, but got a > very broken backtrace. Can you try the patches at http://www.cran.org.uk/~brucec/libkvm_20090822.diff and http://www.cran.org.uk/~brucec/ps_20090822.diff please? I've tested them on both amd64 and i386 PCs and it seems to work. It turned out there were 3 bugs: 1. The call to kvm_nlist on line 558 of lib/libkvm/kvm_proc.c was failing with -1, but the code assumed it was returning a positive number and so ended up walking off the end of the array. gavin@ created the patch - a standalone version is at http://people.freebsd.org/~gavin/PRs/137890.2.diff but has been integrated into libkvm_20090822.diff. There may be more calls to kvm_nlist that don't have the correct error checking in kvm_proc.c 2. kvm_open(3) states that execfile can be NULL, but line 215 of bin/ps/ps.c initializes it to _PATH_DEVNULL. That was why kvm_nlist was failing. 3. On line 154 of kvm_proc.c bcopy is called with the address in ucred.cr_groups. It appears that it's a kernel address and I guess that an extra call to KREAD needs to be made. At the same time as fixing those bugs I bumped WARNS up and fixed the resulting errors: invalid formatting strings, casts and unused variables - and converted some functions from K&R to ANSI to try and get better warnings of any potential problems from gcc. I can split out the actual bug fixes into separate patches if needed. -- Bruce