From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 05:51:24 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B756106566C; Sun, 26 Jun 2011 05:51:24 +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 2F0618FC14; Sun, 26 Jun 2011 05:51:24 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5Q5pLwO038505 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 25 Jun 2011 23:51:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E05F582.2010500@FreeBSD.org> Date: Sat, 25 Jun 2011 23:51:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> References: <4E05F582.2010500@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 25 Jun 2011 23:51:22 -0600 (MDT) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: kern.sync_on_panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 05:51:24 -0000 On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: > Does anybody actually use kern.sync_on_panic tunable/sysctl? > If yes, then in what circumstances do you need it? > That is, why any other alternative doesn't work for you? > Like: > 1. remounting filesystems R/O before panic if you knowingly provoke it = for testing > 2. using netboot for your test system > 3. using su+j, gjournal or a different filesystem altogether > 4. using fsck after reboot >=20 > It seems to me that syncing filesystems in panic context is an = adventure. And it > may become even more of an adventure if we introduce code that = completely stops > scheduler in and after panic. I've used it in the past when I was developing a device driver that was = in the late stages of maturing. Since all the panics in the system were = when the driver dereferenced NULL in that driver, sync was safe because = all the data structures were sane except the aforementioned driver. (1) It was a production system, and everything that could be was already = mounted r/w. However, some small, but every critical, amount of data = was still r/w and it was very important to not lose this data. = Production here likely should be in quotes, because it was in the late = stages of testing/validation. The problem was without this sometimes = the saved state of the GPS receiver and other hardware would wind up = being zero, which meant that we'd have to do a cold start which cost us = a few hours of time. At the time I was doing this, we saw zero files a = couple times a day without this turned on. (2) netbooting wasn't an option since we were qualifying a = non-netbooting system. (3) these weren't available at the time, but the goal was to prevent = data loss, not to necessarily have to avoid fsck on boot. (4) Data loss without it. Now, I'll be the first to admit this has been a few years, and I haven't = done a fresh evaluation to see if things are still safe. I'll also be = the first to admit that this was a useful debugging setting late in = development, and not in production. I'm also the first to admit this = isn't what I'd call a very wide-spread case. But it did come in very = handy when chasing a few bugs to be able to do 10 panic/reboot cycles an = hour rather than 2 a day. Warner= From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 09:50:43 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12961106566B for ; Sun, 26 Jun 2011 09:50:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 477A88FC12 for ; Sun, 26 Jun 2011 09:50:42 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id C19AA15351B for ; Sun, 26 Jun 2011 11:50:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mCQfF06-fw9 for ; Sun, 26 Jun 2011 11:50:36 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id BA83C15358E for ; Sun, 26 Jun 2011 01:53:08 +0200 (CEST) Message-ID: <4E0674ED.5090502@digiware.nl> Date: Sun, 26 Jun 2011 01:53:17 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 09:50:43 -0000 Hi, I'm running ZFS of of 8 disks on an areca 1120.... Things were just running fine until I tried upgrading to the most recent STABLE. Turns out that my configuration causes a panic in arcmsr.c:2093, Because the MTX is multiple invoked here. Now my previous working version dates from 26/2, and since then a new release from areca was imported..... So I tried opgrading my firmware to 1.49, but to no avail. The system keeps panicing. So I guess that there is still a coding error somewhere in the driver. But I'm not into this enough to even know where to start looking for tracing this..... But perhaps somebody has a suggestion? Thanx, --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 11:01:24 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBE0106564A for ; Sun, 26 Jun 2011 11:01:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 16BAB8FC0C for ; Sun, 26 Jun 2011 11:01:23 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 0b1M1h0010x6nqcAFb1Mh2; Sun, 26 Jun 2011 11:01:21 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id 0b1K1h00C1t3BNj8Yb1KtJ; Sun, 26 Jun 2011 11:01:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0D181102C19; Sun, 26 Jun 2011 04:01:22 -0700 (PDT) Date: Sun, 26 Jun 2011 04:01:22 -0700 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20110626110121.GA5197@icarus.home.lan> References: <4E0674ED.5090502@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0674ED.5090502@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:01:24 -0000 On Sun, Jun 26, 2011 at 01:53:17AM +0200, Willem Jan Withagen wrote: > I'm running ZFS of of 8 disks on an areca 1120.... > Things were just running fine until I tried upgrading to the most recent > STABLE. > > Turns out that my configuration causes a panic in > > arcmsr.c:2093, > Because the MTX is multiple invoked here. > > Now my previous working version dates from 26/2, and since then a new > release from areca was imported..... > > So I tried opgrading my firmware to 1.49, but to no avail. > The system keeps panicing. > > So I guess that there is still a coding error somewhere in the driver. > But I'm not into this enough to even know where to start looking for > tracing this..... > > But perhaps somebody has a suggestion? Have you reported this problem directly to Areca? They do officially support FreeBSD. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 11:26:46 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B5B4106566C for ; Sun, 26 Jun 2011 11:26:46 +0000 (UTC) (envelope-from prvs=11581a8220=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0563D8FC16 for ; Sun, 26 Jun 2011 11:26:45 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 26 Jun 2011 12:16:02 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 26 Jun 2011 12:16:02 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013873131.msg for ; Sun, 26 Jun 2011 12:16:01 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11581a8220=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: stable@freebsd.org Message-ID: <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> From: "Steven Hartland" To: "Willem Jan Withagen" , References: <4E0674ED.5090502@digiware.nl> Date: Sun, 26 Jun 2011 12:16:21 +0100 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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:26:46 -0000 ----- Original Message ----- From: "Willem Jan Withagen" ... > So I tried opgrading my firmware to 1.49, but to no avail. > The system keeps panicing. > > So I guess that there is still a coding error somewhere in the driver. > But I'm not into this enough to even know where to start looking for > tracing this..... > > But perhaps somebody has a suggestion? FYI we run these and other controllers across a large number of machines including those running 8.2 and zfs and haven't suffered any panics as yet. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 11:32:47 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6201065670 for ; Sun, 26 Jun 2011 11:32:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99E0A8FC12 for ; Sun, 26 Jun 2011 11:32:46 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 23C1C153434; Sun, 26 Jun 2011 13:32:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXSC4azDbunJ; Sun, 26 Jun 2011 13:32:43 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 2AD0E153433; Sun, 26 Jun 2011 13:32:43 +0200 (CEST) Message-ID: <4E0718E4.9030808@digiware.nl> Date: Sun, 26 Jun 2011 13:32:52 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jeremy Chadwick References: <4E0674ED.5090502@digiware.nl> <20110626110121.GA5197@icarus.home.lan> In-Reply-To: <20110626110121.GA5197@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:32:47 -0000 On 26-6-2011 13:01, Jeremy Chadwick wrote: > On Sun, Jun 26, 2011 at 01:53:17AM +0200, Willem Jan Withagen wrote: >> I'm running ZFS of of 8 disks on an areca 1120.... >> Things were just running fine until I tried upgrading to the most recent >> STABLE. >> >> Turns out that my configuration causes a panic in >> >> arcmsr.c:2093, >> Because the MTX is multiple invoked here. >> >> Now my previous working version dates from 26/2, and since then a new >> release from areca was imported..... >> >> So I tried opgrading my firmware to 1.49, but to no avail. >> The system keeps panicing. >> >> So I guess that there is still a coding error somewhere in the driver. >> But I'm not into this enough to even know where to start looking for >> tracing this..... >> >> But perhaps somebody has a suggestion? > > Have you reported this problem directly to Areca? They do officially > support FreeBSD. To be honest, it has NOT crossed my mind, and even now I'm sort of baffled. But you are right, they would/could be the people to help. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 11:37:13 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764911065670 for ; Sun, 26 Jun 2011 11:37:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 057978FC0A for ; Sun, 26 Jun 2011 11:37:13 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id CD16B153434; Sun, 26 Jun 2011 13:37:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9t+AIuS96CC; Sun, 26 Jun 2011 13:37:09 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id CB6F1153433; Sun, 26 Jun 2011 13:37:09 +0200 (CEST) Message-ID: <4E0719EF.4060403@digiware.nl> Date: Sun, 26 Jun 2011 13:37:19 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Steven Hartland References: <4E0674ED.5090502@digiware.nl> <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> In-Reply-To: <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:37:13 -0000 On 26-6-2011 13:16, Steven Hartland wrote: > ----- Original Message ----- From: "Willem Jan Withagen" > ... >> So I tried opgrading my firmware to 1.49, but to no avail. >> The system keeps panicing. >> >> So I guess that there is still a coding error somewhere in the driver. >> But I'm not into this enough to even know where to start looking for >> tracing this..... >> >> But perhaps somebody has a suggestion? > > > FYI we run these and other controllers across a large number of machines > including those running 8.2 and zfs and haven't suffered any panics as > yet. Well the main key to the problem is that on 2011/06/06 the new version from Areca got imported. So if you have all your boxes with kernels predating 06-06, you're not running the new code. It the above is true and if you have a spare/development box, it would be interesting to see if a very recent 8.2-STABLE would work. But thanx for giving me a reference point. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 11:51:47 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4395F106566B for ; Sun, 26 Jun 2011 11:51:47 +0000 (UTC) (envelope-from prvs=11581a8220=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C10548FC0C for ; Sun, 26 Jun 2011 11:51:46 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 26 Jun 2011 12:50:38 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 26 Jun 2011 12:50:38 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013873349.msg for ; Sun, 26 Jun 2011 12:50:37 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11581a8220=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: stable@freebsd.org Message-ID: <6049DAF547274E10A11C66936374E878@multiplay.co.uk> From: "Steven Hartland" To: "Willem Jan Withagen" References: <4E0674ED.5090502@digiware.nl> <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> <4E0719EF.4060403@digiware.nl> Date: Sun, 26 Jun 2011 12:50:59 +0100 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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: stable@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:51:47 -0000 ----- Original Message ----- From: "Willem Jan Withagen" > Well the main key to the problem is that on 2011/06/06 the new version > from Areca got imported. So if you have all your boxes with kernels > predating 06-06, you're not running the new code. > > It the above is true and if you have a spare/development box, it would > be interesting to see if a very recent 8.2-STABLE would work. > > But thanx for giving me a reference point. Ahh when you said 8.2 that infers release not stable which is 8-stable in my mind. So to clarify all our machines are running 8.2-release with a few minor imports from stable to fix local issues such as the updated ixgbe driver. I don't have a box I can use to test stable I'm afraid sorry. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 12:19:24 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0991106566B for ; Sun, 26 Jun 2011 12:19:24 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 503C08FC1B for ; Sun, 26 Jun 2011 12:19:24 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id B6790153434; Sun, 26 Jun 2011 14:19:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAV90vzD91WQ; Sun, 26 Jun 2011 14:19:20 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id BB450153433; Sun, 26 Jun 2011 14:19:20 +0200 (CEST) Message-ID: <4E0723D2.8050706@digiware.nl> Date: Sun, 26 Jun 2011 14:19:30 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Steven Hartland References: <4E0674ED.5090502@digiware.nl> <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> <4E0719EF.4060403@digiware.nl> <6049DAF547274E10A11C66936374E878@multiplay.co.uk> In-Reply-To: <6049DAF547274E10A11C66936374E878@multiplay.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 12:19:24 -0000 On 26-6-2011 13:50, Steven Hartland wrote: > ----- Original Message ----- From: "Willem Jan Withagen" > >> Well the main key to the problem is that on 2011/06/06 the new version >> from Areca got imported. So if you have all your boxes with kernels >> predating 06-06, you're not running the new code. >> >> It the above is true and if you have a spare/development box, it would >> be interesting to see if a very recent 8.2-STABLE would work. >> >> But thanx for giving me a reference point. > > Ahh when you said 8.2 that infers release not stable which is 8-stable > in my mind. > > So to clarify all our machines are running 8.2-release with a few minor > imports from stable to fix local issues such as the updated ixgbe driver. > > I don't have a box I can use to test stable I'm afraid sorry. Hi Steven, My sense is more or less the other way around. 8.2 would feel like 8.2-stable, and only release when specifcally marked so. But then that's probably where one is coming from. I always run non-RELEASE version. Too bad, I only have one controller and it is in active use.... I'd otherwise build a clean system. But then use this as a point of attention, once you want to proceed from release into stable.... --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 13:02:29 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4B2106564A for ; Sun, 26 Jun 2011 13:02:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0568FC13 for ; Sun, 26 Jun 2011 13:02:28 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id 0crp1h0021vXlb85Dd2V1K; Sun, 26 Jun 2011 13:02:29 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id 0d2T1h0131t3BNj3dd2UD7; Sun, 26 Jun 2011 13:02:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E3969102C19; Sun, 26 Jun 2011 06:02:25 -0700 (PDT) Date: Sun, 26 Jun 2011 06:02:25 -0700 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20110626130225.GA7164@icarus.home.lan> References: <4E0674ED.5090502@digiware.nl> <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> <4E0719EF.4060403@digiware.nl> <6049DAF547274E10A11C66936374E878@multiplay.co.uk> <4E0723D2.8050706@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0723D2.8050706@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, Steven Hartland Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 13:02:29 -0000 On Sun, Jun 26, 2011 at 02:19:30PM +0200, Willem Jan Withagen wrote: > On 26-6-2011 13:50, Steven Hartland wrote: > > ----- Original Message ----- From: "Willem Jan Withagen" > > > >> Well the main key to the problem is that on 2011/06/06 the new version > >> from Areca got imported. So if you have all your boxes with kernels > >> predating 06-06, you're not running the new code. > >> > >> It the above is true and if you have a spare/development box, it would > >> be interesting to see if a very recent 8.2-STABLE would work. > >> > >> But thanx for giving me a reference point. > > > > Ahh when you said 8.2 that infers release not stable which is 8-stable > > in my mind. > > > > So to clarify all our machines are running 8.2-release with a few minor > > imports from stable to fix local issues such as the updated ixgbe driver. > > > > I don't have a box I can use to test stable I'm afraid sorry. > > Hi Steven, > > My sense is more or less the other way around. 8.2 would feel like > 8.2-stable, and only release when specifcally marked so. > But then that's probably where one is coming from. I always run > non-RELEASE version. > > Too bad, I only have one controller and it is in active use.... > I'd otherwise build a clean system. > > But then use this as a point of attention, once you want to proceed from > release into stable.... I would strongly recommend (to both of you) of referring to things by either full version string (e.g. 8.2-RELEASE or 8.2-STABLE), or alternatively by release tag (e.g. RELENG_8_2 or RELENG_8). The "x.y" nomenclature hasn't ever sufficed. Regardless of what convention you go with, always remember to include your kernel/world build date (the date shown in "uname -a" is usually sufficient as long as you haven't done something nonsensical like rebuilding kernel and not world). This is *especially* important when reporting issues with RELENG_8 (8.2-STABLE), because MFC's happen all the time, case in point. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 13:52:16 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDED106564A; Sun, 26 Jun 2011 13:52:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A29218FC19; Sun, 26 Jun 2011 13:52:16 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p5QDq5gk001339; Sun, 26 Jun 2011 09:52:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E073982.8050601@sentex.net> Date: Sun, 26 Jun 2011 09:52:02 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willem Jan Withagen References: <4E0674ED.5090502@digiware.nl> In-Reply-To: <4E0674ED.5090502@digiware.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: stable@freebsd.org, delphij@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 13:52:16 -0000 On 6/25/2011 7:53 PM, Willem Jan Withagen wrote: > Hi, > > I'm running ZFS of of 8 disks on an areca 1120.... > Things were just running fine until I tried upgrading to the most recent > STABLE. > > Turns out that my configuration causes a panic in > > arcmsr.c:2093, > Because the MTX is multiple invoked here. > > But perhaps somebody has a suggestion? I am running RELENG_8 as of June 20th on a different controller and havent had any problems with it. But its an ARC-1210 with V1.44 2008-2-1 with disks in raid 5. arcmsr0: mem 0xb4200000-0xb4200fff irq 18 at device 14.0 on pci8 ARECA RAID ADAPTER0: Driver Version 1.20.00.21 2010-03-03 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] Perhaps open a ticket with Areca ? ---Mike ching2048@areca.com.tw -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 14:24:06 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20DCA106566C for ; Sun, 26 Jun 2011 14:24:06 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB058FC08 for ; Sun, 26 Jun 2011 14:24:05 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id C3BCF153434; Sun, 26 Jun 2011 16:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oEctqozXgiH; Sun, 26 Jun 2011 16:24:00 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 81568153433; Sun, 26 Jun 2011 16:24:00 +0200 (CEST) Message-ID: <4E074109.1060500@digiware.nl> Date: Sun, 26 Jun 2011 16:24:09 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jeremy Chadwick References: <4E0674ED.5090502@digiware.nl> <4BF3C5A181754319A7A83BE40F321E29@multiplay.co.uk> <4E0719EF.4060403@digiware.nl> <6049DAF547274E10A11C66936374E878@multiplay.co.uk> <4E0723D2.8050706@digiware.nl> <20110626130225.GA7164@icarus.home.lan> In-Reply-To: <20110626130225.GA7164@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Steven Hartland Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 14:24:06 -0000 On 26-6-2011 15:02, Jeremy Chadwick wrote: > On Sun, Jun 26, 2011 at 02:19:30PM +0200, Willem Jan Withagen wrote: >> On 26-6-2011 13:50, Steven Hartland wrote: >>> ----- Original Message ----- From: "Willem Jan Withagen" >>> >>>> Well the main key to the problem is that on 2011/06/06 the new version >>>> from Areca got imported. So if you have all your boxes with kernels >>>> predating 06-06, you're not running the new code. >>>> >>>> It the above is true and if you have a spare/development box, it would >>>> be interesting to see if a very recent 8.2-STABLE would work. >>>> >>>> But thanx for giving me a reference point. >>> >>> Ahh when you said 8.2 that infers release not stable which is 8-stable >>> in my mind. >>> >>> So to clarify all our machines are running 8.2-release with a few minor >>> imports from stable to fix local issues such as the updated ixgbe driver. >>> >>> I don't have a box I can use to test stable I'm afraid sorry. >> >> Hi Steven, >> >> My sense is more or less the other way around. 8.2 would feel like >> 8.2-stable, and only release when specifcally marked so. >> But then that's probably where one is coming from. I always run >> non-RELEASE version. >> >> Too bad, I only have one controller and it is in active use.... >> I'd otherwise build a clean system. >> >> But then use this as a point of attention, once you want to proceed from >> release into stable.... > > I would strongly recommend (to both of you) of referring to things by > either full version string (e.g. 8.2-RELEASE or 8.2-STABLE), or > alternatively by release tag (e.g. RELENG_8_2 or RELENG_8). The "x.y" > nomenclature hasn't ever sufficed. > > Regardless of what convention you go with, always remember to include > your kernel/world build date (the date shown in "uname -a" is usually > sufficient as long as you haven't done something nonsensical like > rebuilding kernel and not world). This is *especially* important when > reporting issues with RELENG_8 (8.2-STABLE), because MFC's happen all > the time, case in point. > Jeremy, You are absolutely correct. Being an old fart on these lists I should have known better. However the kernel is not running, so getting things as an afterthought is rather hard. Since it is my fileserver, I need it to be up to do most sensible work. Greping the kernel gives: FreeBSD 8.2-STABLE #117: Fri Jun 24 06:28:46 CEST 2011 --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 14:26:16 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3676106566C; Sun, 26 Jun 2011 14:26:16 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 44DC58FC15; Sun, 26 Jun 2011 14:26:16 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 1B77B153434; Sun, 26 Jun 2011 16:26:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmX0ldHGiBZj; Sun, 26 Jun 2011 16:26:13 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 1BE02153433; Sun, 26 Jun 2011 16:26:13 +0200 (CEST) Message-ID: <4E07418E.90701@digiware.nl> Date: Sun, 26 Jun 2011 16:26:22 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mike Tancsa References: <4E0674ED.5090502@digiware.nl> <4E073982.8050601@sentex.net> In-Reply-To: <4E073982.8050601@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, delphij@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 14:26:16 -0000 On 26-6-2011 15:52, Mike Tancsa wrote: > On 6/25/2011 7:53 PM, Willem Jan Withagen wrote: >> Hi, >> >> I'm running ZFS of of 8 disks on an areca 1120.... >> Things were just running fine until I tried upgrading to the most recent >> STABLE. >> >> Turns out that my configuration causes a panic in >> >> arcmsr.c:2093, >> Because the MTX is multiple invoked here. > >> >> But perhaps somebody has a suggestion? > > > I am running RELENG_8 as of June 20th on a different controller and > havent had any problems with it. But its an ARC-1210 with V1.44 > 2008-2-1 with disks in raid 5. > arcmsr0: > mem 0xb4200000-0xb4200fff irq 18 at device 14.0 on pci8 > ARECA RAID ADAPTER0: Driver Version 1.20.00.21 2010-03-03 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 > arcmsr0: [ITHREAD] > > Perhaps open a ticket with Areca ? > > ---Mike > ching2048@areca.com.tw I just went to their web-interface and submitted a ticket online. We'll see what happens. I'm jusing them just as JBOD, since I let ZFS do the work. Sort of expensive, but the controller was on my desk anyways. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 26 16:49:20 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22AA61065674 for ; Sun, 26 Jun 2011 16:49:20 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D95628FC08 for ; Sun, 26 Jun 2011 16:49:19 +0000 (UTC) Received: by iwr19 with SMTP id 19so4939398iwr.13 for ; Sun, 26 Jun 2011 09:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=4BEJ9UyR5+JFL2kHW9YeaD6a4JCMw9g8ZwaH/qGgzC8=; b=vG3VRFaN1dQ4+qPnJE6GM+MShbQxKoyzEPc4eEnb+2c2clmtpguHfBd30Jlesl0LIP 6WvWGvyNfWG9jvJJlBVsugVdrtEQmPFW3ovUOb2adxXFzlQtQvM7IN5XsQjr4kO9QWAy PpkgCK7UVppgh5xzEdyrMN8VnRmHC3lZticLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=KkgwXLzX3LL5IRJrgSJjkPmC8ttGmdaqPivUuCVwZTOzReq1CvIph0cFwek8J69bbh ZfNVC//7oSNzk2+S3FtsVHCO7yff3uEdPhTmSfbVKh5XoJBqBjFRFr8gIK4pBAzvZah8 4xe6mrDBoPagKRKli83V9D4OpVY/NFB01SSrQ= Received: by 10.42.171.71 with SMTP id i7mr3731837icz.96.1309105575044; Sun, 26 Jun 2011 09:26:15 -0700 (PDT) Received: from schism.local (c-76-124-49-145.hsd1.pa.comcast.net [76.124.49.145]) by mx.google.com with ESMTPS id p15sm2578451ibh.12.2011.06.26.09.26.13 (version=SSLv3 cipher=OTHER); Sun, 26 Jun 2011 09:26:13 -0700 (PDT) Message-ID: <4E075DA4.6070902@gmail.com> Date: Sun, 26 Jun 2011 12:26:12 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Sebastian Anding References: <20110623144700.7679a699@jf.bluem00n.gotdns.org> In-Reply-To: <20110623144700.7679a699@jf.bluem00n.gotdns.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: 8 Stable won't boot into zfs with underlying geli layer amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 16:49:20 -0000 On 6/23/11 8:47 AM, Sebastian Anding wrote: > Hi, > > i tried to switch to 8.0 stable. I checkout the src-all with cvsup 3 > days ago. What branch did you switch from, and what tag do you have in your supfile for the -stable branch? The tag for the latest -stable branch should be RELENG_8 . > After make buildworld, make buildkernel and make installkernel, I booted > into the new system. But now I'm not asked for the geli passphrases. > That results in the kernel not beeing able to mount the root vfs. The > keyboard (USB) is not responding anymore and so I'm not able to set > parameters after the root fs went missing, or produce a dmesg. > > I guess that the discs are not detected anymore. > > My setup can be seen in the attached files. There are one freebsd-swap > and one freebsd-zfs gpart partition on each disc. The gpart partitions > freebsd-zfs are encrypted with geli. I attach the dmesg of the Generic > 8.2 release kernel too. > I'm not familiar with mixing GELI with ZFS, but I have a few questions to try to clarify exactly what you did because of ZFS pool compatibility. You mentioned 8.0-STABLE above, but you mention 8.2-RELEASE for dmesg. If you did in fact switch from 8.2-RELEASE to 8.0-STABLE, you downgraded your system. Depending on what ZFS version you were using (v15 was the default in 8.2-RELEASE), the zpool may not be usable by older ZFS versions (the default in 8.0-STABLE was v13 when it was branched from HEAD). Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 10:08:24 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C8106564A; Mon, 27 Jun 2011 10:08:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEC58FC16; Mon, 27 Jun 2011 10:08:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA20175; Mon, 27 Jun 2011 13:08:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qb8jm-0001ue-DE; Mon, 27 Jun 2011 13:08:14 +0300 Message-ID: <4E08568E.4060309@FreeBSD.org> Date: Mon, 27 Jun 2011 13:08:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4E05F582.2010500@FreeBSD.org> <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> In-Reply-To: <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: kern.sync_on_panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 10:08:24 -0000 on 26/06/2011 08:51 Warner Losh said the following: > > On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: >> Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, then >> in what circumstances do you need it? That is, why any other alternative >> doesn't work for you? Like: 1. remounting filesystems R/O before panic if >> you knowingly provoke it for testing 2. using netboot for your test system >> 3. using su+j, gjournal or a different filesystem altogether 4. using fsck >> after reboot >> >> It seems to me that syncing filesystems in panic context is an adventure. >> And it may become even more of an adventure if we introduce code that >> completely stops scheduler in and after panic. > > I've used it in the past when I was developing a device driver that was in > the late stages of maturing. Since all the panics in the system were when > the driver dereferenced NULL in that driver, sync was safe because all the > data structures were sane except the aforementioned driver. > > (1) It was a production system, and everything that could be was already > mounted r/w. However, some small, but every critical, amount of data was > still r/w and it was very important to not lose this data. Production here > likely should be in quotes, because it was in the late stages of > testing/validation. The problem was without this sometimes the saved state > of the GPS receiver and other hardware would wind up being zero, which meant > that we'd have to do a cold start which cost us a few hours of time. At the > time I was doing this, we saw zero files a couple times a day without this > turned on. (2) netbooting wasn't an option since we were qualifying a > non-netbooting system. (3) these weren't available at the time, but the goal > was to prevent data loss, not to necessarily have to avoid fsck on boot. (4) > Data loss without it. > > Now, I'll be the first to admit this has been a few years, and I haven't done > a fresh evaluation to see if things are still safe. I'll also be the first > to admit that this was a useful debugging setting late in development, and > not in production. I'm also the first to admit this isn't what I'd call a > very wide-spread case. But it did come in very handy when chasing a few bugs > to be able to do 10 panic/reboot cycles an hour rather than 2 a day. A fine enough use-case for me. I guess the problem ultimately boiled down to peculiarities of UFS behavior, but still... However, please be aware that sync_on_panic might get broken when/if we start stopping scheduler in panic. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 11:31:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AD6106564A for ; Mon, 27 Jun 2011 11:31:29 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (lxnt.info [94.124.200.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6037F8FC18 for ; Mon, 27 Jun 2011 11:31:29 +0000 (UTC) Received: from [94.124.202.132] (helo=[192.168.3.31]) by mail.lxnt.info with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Qb9Zj-000EzJ-Ej for freebsd-stable@freebsd.org; Mon, 27 Jun 2011 15:01:55 +0400 Message-ID: <4E0862CF.6010508@lxnt.info> Date: Mon, 27 Jun 2011 15:00:31 +0400 From: Alexander Sabourenkov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Stable References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 11:31:29 -0000 Hello. Seems like my patch fell off the bus when the ata subsystem was rewamped. The problem is a silicon bug in TX4 ASICs. See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079764.html -- ./lxnt From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 12:15:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 668331065675 for ; Mon, 27 Jun 2011 12:15:40 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30ABE8FC1B for ; Mon, 27 Jun 2011 12:15:39 +0000 (UTC) Received: by iwr19 with SMTP id 19so5624498iwr.13 for ; Mon, 27 Jun 2011 05:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gkTgvawFmoiSpbC1KLwfBODBQEP/tiK5/xDnfR/0Xrs=; b=IWhRlUaA3xYaOdTfj8fKkwCQOVT2HgJ8ka/YzXItxhdUbY3B4/1AHu9nlyput2UP4Y ZmNgIVhFoxhA6WNumEB4AEufOacnqvkBjMhvfrbkPrk1GgG6j5YKWBPfVCe7rChfZOqX BaqXMpC5Yu4nxxHbzg7AFOdt7juyRd0OqcvDg= 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=gXPdUp6swGuq9ux9fqZH/ieUrkiM5FF1Ih8CFOC751SWhhyprz0pgpZfwDFYBQmvvG 3yEjjtnTinG9peVhWGIP5W52VecJeyEP8LRri0TxM5fqIFae93dQ9SkhadHqvf6ueTxV QGliQMD1a2YxPWeUA+5FlGs9/mjWTsTCoo0gM= MIME-Version: 1.0 Received: by 10.231.114.78 with SMTP id d14mr5486581ibq.137.1309176939308; Mon, 27 Jun 2011 05:15:39 -0700 (PDT) Received: by 10.231.207.20 with HTTP; Mon, 27 Jun 2011 05:15:39 -0700 (PDT) In-Reply-To: <4E0862CF.6010508@lxnt.info> References: <4E0862CF.6010508@lxnt.info> Date: Mon, 27 Jun 2011 15:15:39 +0300 Message-ID: From: George Kontostanos To: Alexander Sabourenkov Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 12:15:40 -0000 On Mon, Jun 27, 2011 at 2:00 PM, Alexander Sabourenkov wrote: > Hello. > > Seems like my patch fell off the bus when the ata subsystem was rewamped. > > The problem is a silicon bug in TX4 ASICs. > > See this thread: > http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079764.html > > -- > > ./lxnt > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Thanks for the info!!! Unfortunately ata-chipset.c doesn't exist in my source tree. Maybe something has changed and the patch has to be applied differently ? -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 12:40:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78334106566C for ; Mon, 27 Jun 2011 12:40:21 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4898FC0A for ; Mon, 27 Jun 2011 12:40:20 +0000 (UTC) Received: by iyb11 with SMTP id 11so5655847iyb.13 for ; Mon, 27 Jun 2011 05:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JCzyt7ZCKGN1tOc7X2dRhBSt8/a38lGWbYOnERTwlaw=; b=AAu2cYX6pLBhDIkTwdGv2N4lGC3E1ZwtaYlUb0quZtANKor+y1l/by60tiO3gxNfzm nqAH3ZLLPAUBaXsRPBx9+DmFVMkPT/biVKZzYEhGTfbzKUrSrINhuAVhfCPpr/QOsfIi CrWy669MPKsjSDBMaw2mvUud+Z9HibJKw2kUA= 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=h7XKH1YtO1EzefkFIBTYbP+YWMENo0pq8Pafn3r1Vs8WAMUTieZ31M6sePwo35MLdD 2S+Zm8BpDDyIfkEplk7UkSOHhIhmAhRpbAnYTq8IPN8tx7Nw2+iB0R0GKsXQZYbWh9O6 qWihsP6nicIdSpGbFUhJZvngkTsyYINceTfIk= MIME-Version: 1.0 Received: by 10.231.54.100 with SMTP id p36mr5907456ibg.162.1309178420403; Mon, 27 Jun 2011 05:40:20 -0700 (PDT) Received: by 10.231.207.20 with HTTP; Mon, 27 Jun 2011 05:40:20 -0700 (PDT) In-Reply-To: References: <4E0862CF.6010508@lxnt.info> Date: Mon, 27 Jun 2011 15:40:20 +0300 Message-ID: From: George Kontostanos To: Alexander Sabourenkov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 12:40:21 -0000 On Mon, Jun 27, 2011 at 3:15 PM, George Kontostanos wrote: > On Mon, Jun 27, 2011 at 2:00 PM, Alexander Sabourenkov > wrote: >> Hello. >> >> Seems like my patch fell off the bus when the ata subsystem was rewamped= . >> >> The problem is a silicon bug in TX4 ASICs. >> >> See this thread: >> http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079764.= html >> >> -- >> >> ./lxnt >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " >> > > Thanks for the info!!! > > Unfortunately ata-chipset.c doesn't exist in my source tree. Maybe > something has changed and the patch has to be applied differently =A0? > > -- After browsing through the code a bit I saw that your patch is included in: /usr/src/sys/dev/ata/chipsets/ata-promise.c Thanks --=20 George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 13:39:47 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0B42106566B; Mon, 27 Jun 2011 13:39:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 938CB8FC1F; Mon, 27 Jun 2011 13:39:47 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p5RDddI8091201; Mon, 27 Jun 2011 09:39:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E088815.40306@sentex.net> Date: Mon, 27 Jun 2011 09:39:33 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?UTF-8?B?6buD5riF6ZqG?= References: <4E0674ED.5090502@digiware.nl> <4E073982.8050601@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: stable@freebsd.org, Willem Jan Withagen , delphij@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:39:47 -0000 Hi Ching, Thanks very much for the quick turn around! The person who was having the error is actually Willem, not me. All has been running fine for my setup, but I will deploy it as well to test. ---Mike On 6/26/2011 10:49 PM, 黃清隆 wrote: > Hi Mike, > > Thanks for your bug report. > Please compile the new driver in attached zip file and try again. > > Thanks, > Ching > > 2011/6/26 Mike Tancsa > > > On 6/25/2011 7:53 PM, Willem Jan Withagen wrote: > > Hi, > > > > I'm running ZFS of of 8 disks on an areca 1120.... > > Things were just running fine until I tried upgrading to the most > recent > > STABLE. > > > > Turns out that my configuration causes a panic in > > > > arcmsr.c:2093, > > Because the MTX is multiple invoked here. > > > > > But perhaps somebody has a suggestion? > > > I am running RELENG_8 as of June 20th on a different controller and > havent had any problems with it. But its an ARC-1210 with V1.44 > 2008-2-1 with disks in raid 5. > arcmsr0: > mem 0xb4200000-0xb4200fff irq 18 at device 14.0 on pci8 > ARECA RAID ADAPTER0: Driver Version 1.20.00.21 2010-03-03 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 > arcmsr0: [ITHREAD] > > Perhaps open a ticket with Areca ? > > ---Mike > ching2048@areca.com.tw > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > > Cambridge, Ontario Canada http://www.tancsa.com/ > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 16:11:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44B4A106566B for ; Mon, 27 Jun 2011 16:11:24 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 242678FC15 for ; Mon, 27 Jun 2011 16:11:24 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p5RGBMk8030979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2011 09:11:23 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p5RGBM33030978; Mon, 27 Jun 2011 09:11:22 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA15120; Mon, 27 Jun 11 09:08:30 PDT Date: Mon, 27 Jun 2011 09:12:11 -0700 From: perryh@pluto.rain.com To: screwdriver@lxnt.info, gkontos.mail@gmail.com Message-Id: <4e08abdb.OjX8YAKmssV1v7Qf%perryh@pluto.rain.com> References: <4E0862CF.6010508@lxnt.info> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:11:24 -0000 George Kontostanos wrote: > On Mon, Jun 27, 2011 at 2:00 PM, Alexander Sabourenkov > wrote: > > Seems like my patch fell off the bus when the ata subsystem > > was rewamped. The problem is a silicon bug in TX4 ASICs. > > See this thread: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079764.html > > Unfortunately ata-chipset.c doesn't exist in my source tree. Maybe > something has changed and the patch has to be applied differently? In 8.1, it looks as if we now have a src/sys/dev/ata/chipsets directory. Functions named ata_promise_mio_* are in ata-promise.c. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 19:44:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB48106567C; Mon, 27 Jun 2011 19:44:02 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B246E8FC18; Mon, 27 Jun 2011 19:44:01 +0000 (UTC) Received: by qwc9 with SMTP id 9so3325799qwc.13 for ; Mon, 27 Jun 2011 12:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Byw1LAt81lMq+TWGgK6RADIQ6nTVMrpLaO6WoCIpF8=; b=pFJolZ5LjOqENLfxJRFf6vXBXQEc/uWAJfxm90T61x9Cj+b7jM+13sHqV3BB5jiHfL DxziLzymcytsTrDB2W/bunrlpVHlMgz5zY1u5ihMwlb41nDw/NBlikV06QUT7WLYoT6F eW3MeKxDhm4rbeNRRYIxqUEJ6vkM2k8TjKVRk= 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=dIAqSUBh177ZiXnvwS4CIWta7at6vhppdCwPOHq3C/Z2vAJG38uIqqnNDnVxIpqR5i qKMoCu93/iMlhPC9TipRFMMHHzLiYGw1vcDG2Sr5K4qM3WNHBKtYklTuzajI0jXNjTxK 1Cp4r25iQKF/blwWES35t9ifiqDSyvKE/IoA8= MIME-Version: 1.0 Received: by 10.229.2.131 with SMTP id 3mr4966220qcj.156.1309202387229; Mon, 27 Jun 2011 12:19:47 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.62.229 with HTTP; Mon, 27 Jun 2011 12:19:47 -0700 (PDT) In-Reply-To: <4E08568E.4060309@FreeBSD.org> References: <4E05F582.2010500@FreeBSD.org> <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> <4E08568E.4060309@FreeBSD.org> Date: Mon, 27 Jun 2011 12:19:47 -0700 X-Google-Sender-Auth: i-1OHeDAibxgLbgyt5oGPFFA918 Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kern.sync_on_panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:44:02 -0000 On Mon, Jun 27, 2011 at 3:08 AM, Andriy Gapon wrote: > on 26/06/2011 08:51 Warner Losh said the following: >> >> On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: >>> Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, th= en >>> in what circumstances do you need it? That is, why any other alternativ= e >>> doesn't work for you? Like: 1. remounting filesystems R/O before panic = if >>> you knowingly provoke it for testing 2. using netboot for your test sys= tem >>> 3. using su+j, gjournal or a different filesystem altogether 4. using f= sck >>> after reboot >>> >>> It seems to me that syncing filesystems in panic context is an adventur= e. >>> And it may become even more of an adventure if we introduce code that >>> completely stops scheduler in and after panic. >> >> I've used it in the past when I was developing a device driver that was = in >> the late stages of maturing. =A0Since all the panics in the system were = when >> the driver dereferenced NULL in that driver, sync was safe because all t= he >> data structures were sane except the aforementioned driver. >> >> (1) It was a production system, and everything that could be was already >> mounted r/w. =A0However, some small, but every critical, amount of data = was >> still r/w and it was very important to not lose this data. =A0Production= here >> likely should be in quotes, because it was in the late stages of >> testing/validation. =A0The problem was without this sometimes the saved = state >> of the GPS receiver and other hardware would wind up being zero, which m= eant >> that we'd have to do a cold start which cost us a few hours of time. =A0= At the >> time I was doing this, we saw zero files a couple times a day without th= is >> turned on. (2) netbooting wasn't an option since we were qualifying a >> non-netbooting system. (3) these weren't available at the time, but the = goal >> was to prevent data loss, not to necessarily have to avoid fsck on boot.= (4) >> Data loss without it. >> >> Now, I'll be the first to admit this has been a few years, and I haven't= done >> a fresh evaluation to see if things are still safe. =A0I'll also be the = first >> to admit that this was a useful debugging setting late in development, a= nd >> not in production. =A0I'm also the first to admit this isn't what I'd ca= ll a >> very wide-spread case. =A0But it did come in very handy when chasing a f= ew bugs >> to be able to do 10 panic/reboot cycles an hour rather than 2 a day. > > A fine enough use-case for me. =A0I guess the problem ultimately boiled d= own to > peculiarities of UFS behavior, but still... > However, please be aware that sync_on_panic might get broken when/if we s= tart > stopping scheduler in panic. The entirety of the sync code should be a subroutine in vfs_bio.c so the 'buf' variable is static to the file. At that point it would be reasonable to explicitly call it at the beginning of panic(9) for the sync-on-panic case, either before IPIing the other CPUs, or at least before entering the critical section that prevents the scheduler from running. Cheers, matthew From owner-freebsd-stable@FreeBSD.ORG Mon Jun 27 19:44:35 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5ED5106566C; Mon, 27 Jun 2011 19:44:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF1E8FC21; Mon, 27 Jun 2011 19:44:35 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 8D0D6153434; Mon, 27 Jun 2011 21:44:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpNS-CV4Kt4R; Mon, 27 Jun 2011 21:44:31 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:5dc6:fb01:d251:6852] (unknown [IPv6:2001:4cb8:3:1:5dc6:fb01:d251:6852]) by mail.digiware.nl (Postfix) with ESMTP id C1E42153433; Mon, 27 Jun 2011 21:44:31 +0200 (CEST) Message-ID: <4E08DDAA.5090309@digiware.nl> Date: Mon, 27 Jun 2011 21:44:42 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mike Tancsa References: <4E0674ED.5090502@digiware.nl> <4E073982.8050601@sentex.net> <4E088815.40306@sentex.net> In-Reply-To: <4E088815.40306@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?6buD5riF6ZqG?= , stable@freebsd.org, delphij@freebsd.org Subject: Re: arcmsr panic runnig 8.2 of 2011 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:44:35 -0000 On 2011-06-27 15:39, Mike Tancsa wrote: > Hi Ching, > Thanks very much for the quick turn around! The person who was having > the error is actually Willem, not me. All has been running fine for my > setup, but I will deploy it as well to test. Yup, And I've got my plate full with real-live job. So I've got to find a slot to tinker with the server. Probably again in the weekend. --WjW From owner-freebsd-stable@FreeBSD.ORG Tue Jun 28 19:01:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CE9106566C for ; Tue, 28 Jun 2011 19:01:46 +0000 (UTC) (envelope-from tsw5@duke.edu) Received: from mail-gw-01.oit.duke.edu (lb-mx-gateway-pat.oit.duke.edu [152.3.68.136]) by mx1.freebsd.org (Postfix) with ESMTP id F01F08FC14 for ; Tue, 28 Jun 2011 19:01:45 +0000 (UTC) Received: from mail-gw-01.oit.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C83F02FF51FC_E0A229EB for ; Tue, 28 Jun 2011 18:51:10 +0000 (GMT) X-Sophos-ESA-SMTPD-Auth-On: authentication enabled X-Sophos-ESA-External-Sender: external sender Received: from mail.skylab.org (mail.skylab.org [174.140.162.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-gw-01.oit.duke.edu (Sophos Email Appliance) with ESMTP id 4E8072FF51EA_E0A229EF for ; Tue, 28 Jun 2011 18:51:10 +0000 (GMT) Date: Tue, 28 Jun 2011 11:45:06 -0700 (PDT) From: Todd Wasson X-X-Sender: todd@skylab.org To: freebsd-stable@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 Subject: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:01:46 -0000 I've been thinking about how to best combine encryption and zfs on freebsd, and though I've seen some discussion about each individual option, I haven't found an explicit compare/contrast. I'm thinking of either encryption the devices directly via geli and then making a zfs pool of the foo.eli devices once they're "geli attach"ed (zfs on geli) or making a zfs pool of the unencrypted devices and providing a zvol from the pool as a raw device which I can then use geli to encrypt, and lay a ufs (or even another zfs) filesystem down on this (geli on zfs). While zfs on geli is less complex (in the sense that geli on zfs involves two layers of filesystems), I'm concerned as to whether encrypting the device will somehow affect zfs' ability to detect silent corruption, self-heal, or in any other way adversely affect zfs' functionality. In my mind, if I use geli on zfs, then I've got zfs directly on a device and the zvol it's providing will be transparently gaining the benefits of zfs' various features, providing a "safety layer" against device failure and silent corruption that I'm not sure if geli would detect. In a simpler sense, the question is this: if there is some damage to the device that zfs could putatively work around, if I were to have geli directly on that device, is it the case that geli would _not_ provide this protection and the device would be less robust than if it had had zfs directly on it? If this is not the case, then it seems clear to me that the less complicated zfs on geli route is the way to go, but I'm curious if anyone has any input on this. Thanks! Todd From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 08:18:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE98106567A; Wed, 29 Jun 2011 08:18:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DF07D8FC19; Wed, 29 Jun 2011 08:18:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Qbpes-0002h8-Q8>; Wed, 29 Jun 2011 09:58:02 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Qbpes-00051L-Mn>; Wed, 29 Jun 2011 09:58:02 +0200 Message-ID: <4E0ADB0A.2070409@zedat.fu-berlin.de> Date: Wed, 29 Jun 2011 09:58:02 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110627 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:18:56 -0000 On a Dell PowerEdge 1950, BIOS from 2007, a freshly installed WD 3 TB SATA 6GB harddrive doesn't get recognized as 3 TB disk, it is reported as 2TB disk only. The box is running FreeBSD 8.2-STABLE (see below the dmesg excerpt). The drive is configured as ZFS pool on top of a GPT partition. I tried the 3 TB harddrive on a FreeBSD 9.0-CURRENT box with Intel ICH10R SATA chipset and it worked fine, was reported as 2.7TB drive as expected. I found some postings concerning mptutil not dealing with HD > 2TB, but this issue seems not to be a tool-issue. Questions: a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS issue which can be solved? b) regarding to a), how can I update the BIOS/MPT firmware of the Dell PowerEdge 1950? Is there an option to do this via USB? As I said, the firmware is quite old, it's from 2007. Thanks in advance, Oliver ========================== Copyright (c) 1992-2011 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.2-STABLE #266 r223622: Tue Jun 28 09:38:38 CEST 2011 root@thusnelda.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/THUSNELDA amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.76-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 17179869184 (16384 MB) avail memory = 16522498048 (15757 MB) ACPI APIC Table: 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 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard aesni0: No AESNI support. acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ipmi0: KCS mode found at io 0xca8 on acpi ipmi0: KCS error: ff Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 [...] mpt0: port 0xec00-0xecff mem 0xfc4fc000-0xfc4fffff,0xfc4e0000-0xfc4effff irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.14.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) [...] ipmi0: IPMI device rev. 0, firmware rev. 2.10, version 2.0 ipmi0: Number of channels 4 ipmi0: Attached watchdog da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da1 at mpt0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 2097151MB (4294967295 512 byte sectors: 255H 63S/T 267349C) ses0 at mpt0 bus 0 scbus0 target 8 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: SCSI-3 SES Device cd0 at ata0 bus 0 scbus2 target 0 lun 0SMP: AP CPU #3 Launched! cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 08:33:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B928D1065678 for ; Wed, 29 Jun 2011 08:33:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id A1AF38FC14 for ; Wed, 29 Jun 2011 08:33:57 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 1kYn1h0020FhH24A4kZuUG; Wed, 29 Jun 2011 08:33:54 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id 1ka01h0111t3BNj8Uka1t5; Wed, 29 Jun 2011 08:34:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7DE31102C19; Wed, 29 Jun 2011 01:33:55 -0700 (PDT) Date: Wed, 29 Jun 2011 01:33:55 -0700 From: Jeremy Chadwick To: "O. Hartmann" Message-ID: <20110629083355.GA72679@icarus.home.lan> References: <4E0ADB0A.2070409@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0ADB0A.2070409@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-questions@FreeBSD.ORG Subject: Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:33:57 -0000 On Wed, Jun 29, 2011 at 09:58:02AM +0200, O. Hartmann wrote: > On a Dell PowerEdge 1950, BIOS from 2007, a freshly installed WD 3 > TB SATA 6GB harddrive doesn't get recognized as 3 TB disk, it is > reported as 2TB disk only. > > The box is running FreeBSD 8.2-STABLE (see below the dmesg excerpt). > The drive is configured as ZFS pool on top of a GPT partition. > > I tried the 3 TB harddrive on a FreeBSD 9.0-CURRENT box with Intel > ICH10R SATA chipset and it worked fine, was reported as 2.7TB drive > as expected. > > I found some postings concerning mptutil not dealing with HD > 2TB, > but this issue seems not to be a tool-issue. > > Questions: > a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS > issue which can be solved? > > b) regarding to a), how can I update the BIOS/MPT firmware of the > Dell PowerEdge 1950? Is there an option to do this via USB? As I > said, the firmware is quite old, it's from 2007. The answer is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/147572 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 09:31:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDED5106566B for ; Wed, 29 Jun 2011 09:31:11 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (ingresso-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:176e::2]) by mx1.freebsd.org (Postfix) with ESMTP id B91B48FC08 for ; Wed, 29 Jun 2011 09:31:11 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Qbr70-0001rq-OZ; Wed, 29 Jun 2011 10:31:10 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qbr70-000KIT-Nl; Wed, 29 Jun 2011 10:31:10 +0100 To: freebsd-stable@freebsd.org, tsw5@duke.edu In-Reply-To: Message-Id: From: Pete French Date: Wed, 29 Jun 2011 10:31:10 +0100 Cc: Subject: Re: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:31:12 -0000 > While zfs on geli is less complex (in the sense that geli on zfs > involves two layers of filesystems), I'm concerned as to whether > encrypting the device will somehow affect zfs' ability to detect > silent corruption, self-heal, or in any other way adversely affect > zfs' functionality. In my mind, if I use geli on zfs, then I've > got zfs directly on a device and the zvol it's providing will be > transparently gaining the benefits of zfs' various features, providing > a "safety layer" against device failure and silent corruption that > I'm not sure if geli would detect. These are very good questions - I ran ZFS on top of geli for a long time, and what I found was that when there were problems with the underlying discs, then geli would have problems and those would not be reported back to ZFS properly. I got lockups under those circumstances - when is witched to ZFS on top directly what I got were discs dropping out and ZFS properly continuing with the remaining drives. I never managed to characterise it well enougnh to file a PR I am afraid though - it only ever happened with failing hardware which made it hard to reproduce. -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 13:15:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A41106564A; Wed, 29 Jun 2011 13:15:14 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 957E48FC1C; Wed, 29 Jun 2011 13:15:13 +0000 (UTC) Received: by bwa20 with SMTP id 20so1460987bwa.13 for ; Wed, 29 Jun 2011 06:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.140.18 with SMTP id g18mr712530bku.59.1309351815400; Wed, 29 Jun 2011 05:50:15 -0700 (PDT) Sender: antony@mawer.org X-Google-Sender-Delegation: antony@mawer.org Received: by 10.204.57.137 with HTTP; Wed, 29 Jun 2011 05:50:15 -0700 (PDT) Date: Wed, 29 Jun 2011 22:50:15 +1000 X-Google-Sender-Auth: BV-JcN5RQ9IG7Cw491aYkJLQVv0 Message-ID: From: Antony Mawer To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 13:15:14 -0000 Hi all, Not sure if this is the right place to post it -- about 6 years ago I put together a module which displays an ASCII splash screen on boot (rather than the graphical splash_pcx and splash_bmp modules). We have been running it in production since that time without issue. With the the code slush for 9.0 on the horizon, I thought it might again be worth trying to see if someone is prepared to get this into the tree so others can benefit from it. I have a PR open, kern/143370, which includes the patch for the module; it is against 7.0 but has been used largely unmodified since 4.x days. It currently builds on 8.x still fine as we are running it in production on 8.x for $WORK. Summary of instructions from my previous post about this from ~18mths ago: In case the list eats the patch, you can grab a copy of it here: http://www.mawer.org/freebsd/splash_txt.patch To give you an idea of what it looks like, here is a screenshot of a quick generic FreeBSD splash screen I put together: http://www.mawer.org/freebsd/splash_txt_1.png http://www.mawer.org/freebsd/splash_txt_2.png If you'd like to try it for yourself then the process to build it should be something like this: 1. Download the attached patch 2. Create the required folders before applying the patch -- cd /usr/src && mkdir sys/modules/splash/txt 3. Apply the patch -- patch < splash_txt.patch 4. Build the module -- cd sys/modules/splash/txt && make && make install Once that's completed, you can configure it by adding the following to loader.conf: splash_txt_load="YES" bitmap_load="YES" bitmap_name="/boot/freebsd.bin" I have uploaded two sample boot splash screens at http://www.mawer.org/freebsd/freebsd1.bin and http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced using TheDraw and saving in its Binary file format, which consists of a sequence of 2 byte pairs. The first byte in a pair is the character to draw on the screen, and the second is the colour/display attributes to draw the character with. If anyone else would like to try this out and has any feedback, or if someone thinks it may be of interest to integrate into the tree please let me know ... Otherwise if anyone would like to help push this into the tree in time for 9.0 would be great. It should be safe to MFC to 8.x as well -- as I said we've been running it ever since 4.x days. I am sure others out there would gain at least some (cosmetic) benefits from this! -- Antony From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 13:58:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9188106566B for ; Wed, 29 Jun 2011 13:58:18 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 293588FC0A for ; Wed, 29 Jun 2011 13:58:17 +0000 (UTC) Received: by fxe6 with SMTP id 6so1065118fxe.17 for ; Wed, 29 Jun 2011 06:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jbip.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4qn7ln4MPJMgvvxxi1+S9FjiMVIF61HQm7wQfvnL1CM=; b=boWoAnF87cQ5bvDNot1XFcGWmYi98No7Z9awt72wVIFF4r6r4liIYJbO4FHPSQvJfP nBdx3OiROElFty+DT9mrLkmt5s84KLxhWTAcVL+0vlpc8G5qaZ5hQ0cfR6tHPeiZW+l1 0d9g186PpWKK1IhjS3s0q0dOJKd+bUjHZ8eM4= Received: by 10.223.14.11 with SMTP id e11mr1267852faa.131.1309355897069; Wed, 29 Jun 2011 06:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.25.1 with HTTP; Wed, 29 Jun 2011 06:57:57 -0700 (PDT) In-Reply-To: <4E0ADB0A.2070409@zedat.fu-berlin.de> References: <4E0ADB0A.2070409@zedat.fu-berlin.de> From: Joshua Boyd Date: Wed, 29 Jun 2011 09:57:57 -0400 Message-ID: To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 13:58:19 -0000 2011/6/29 O. Hartmann > Questions: > a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS issue > which can be solved? > Hi Oliver, Neither, unfortunately. The 1068E based cards do not support drives over 2TB. See here: http://kb.lsi.com/KnowledgebaseArticle16399.aspx -- Joshua Boyd E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 17:04:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95275106566B for ; Wed, 29 Jun 2011 17:04:40 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5159F8FC13 for ; Wed, 29 Jun 2011 17:04:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LNK00HJBA3K8A80@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Wed, 29 Jun 2011 19:04:32 +0200 (CEST) Received: from kg-v2.kg4.no ([80.203.92.230]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LNK001FIA3KG8N0@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Wed, 29 Jun 2011 19:04:32 +0200 (CEST) Date: Wed, 29 Jun 2011 19:04:31 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> In-reply-to: References: X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:04:40 -0000 On Wed, 29 Jun 2011 22:50:15 +1000 Antony Mawer wrote: > Hi all, > > Not sure if this is the right place to post it -- about 6 years ago I > put together a module which displays an ASCII splash screen on boot > (rather than the graphical splash_pcx and splash_bmp modules). We have > been running it in production since that time without issue. So, the difference between this and loader.conf's loader_logo construct is that a) this is a proper splash screen module b) you can / must design your splash screen with a separate program (compared to write / modify Forth code) Is my understanding correct? -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 18:13:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9776106564A for ; Wed, 29 Jun 2011 18:13:33 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7FBE8FC08 for ; Wed, 29 Jun 2011 18:13:33 +0000 (UTC) Received: by vws18 with SMTP id 18so1498740vws.13 for ; Wed, 29 Jun 2011 11:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.176.3 with SMTP id bc3mr430161vcb.26.1309371212601; Wed, 29 Jun 2011 11:13:32 -0700 (PDT) Received: by 10.220.7.146 with HTTP; Wed, 29 Jun 2011 11:13:32 -0700 (PDT) X-Originating-IP: [93.221.173.99] In-Reply-To: References: Date: Wed, 29 Jun 2011 20:13:32 +0200 Message-ID: From: "C. P. Ghost" To: Todd Wasson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 18:13:34 -0000 On Tue, Jun 28, 2011 at 8:45 PM, Todd Wasson wrote: > While zfs on geli is less complex (in the sense that geli on zfs involves > two layers of filesystems), I'm concerned as to whether encrypting the > device will somehow affect zfs' ability to detect silent corruption, > self-heal, or in any other way adversely affect zfs' functionality. =A0In= my > mind, if I use geli on zfs, then I've got zfs directly on a device and th= e > zvol it's providing will be transparently gaining the benefits of zfs' > various features, providing a "safety layer" against device failure and > silent corruption that I'm not sure if geli would detect. I'm going out on a limb here, but that's how I see it without intimate knowledge of the geom/geli and zfs code paths involved. Basically, you leave the transparent encryption of sectors to geli, and the integrity checking and repairing to zfs, and you should be *mostly* secure, except for the failure modes below. .eli devices behave just like normal disks, in the sense that they are a block device that transparently encrypts and decrypts sectors when they are accessed. So what could go wrong there: 1. single sectors may be corrupted on disk (e.g. bits flipping). 2. geli metadata (keys etc...) are destroyed. Same for glabel metadata. Case 1.) is probably harmless, because geli would return a corrupted sectors' content to zfs... which zfs will likely detect because it wouldn't checksum correctly. So zfs will correct it out of redundant storage, and write it back through a new encryption. BE CAREFUL: don't enable hmac integrity checks in geli, as that would prevent geli from returning corrupted data and would result in hangs! Case 2.) is a bigger problem. If a sector containing vital geli metadata (perhaps portions of keys?) gets corrupted, and geli had no way to detect and/or correct this (e.g. by using redundant sectors on the same .eli volume!), the whole .eli, or maybe some stripes out of it, could become useless. ZFS couldn't repair this at all... at least not automatically. You'll have to MANUALLY reformat the failed .eli device, and resilver it from zfs redundant storage later. There may be other failure modes involved as well. I don't know. But in most practical day to day uses, with enough redundancy and regular backups, a zfs-over-geli should be good enough. I wouldn't put {zfs,ufs}-over-geli-over-raw-zpool though, as this would involve considerable overhead, IMHO. In this case, I'd rather use a gmirror as a backend, as in a setup: {zfs,ufs}-over-geli-over-{gmirror,graid3} or something similar. But I've never tried this though. -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 21:29:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DE31065672 for ; Wed, 29 Jun 2011 21:29:04 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41C838FC16 for ; Wed, 29 Jun 2011 21:29:03 +0000 (UTC) Received: by eyg7 with SMTP id 7so840784eyg.13 for ; Wed, 29 Jun 2011 14:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.29.3 with SMTP id h3mr335762eea.75.1309381408802; Wed, 29 Jun 2011 14:03:28 -0700 (PDT) Received: by 10.14.27.204 with HTTP; Wed, 29 Jun 2011 14:03:28 -0700 (PDT) X-Originating-IP: [216.223.13.111] In-Reply-To: <8D25FDEA-9F87-4132-9DAA-1982B1DA72B2@lists.zabbadoz.net> References: <8D25FDEA-9F87-4132-9DAA-1982B1DA72B2@lists.zabbadoz.net> Date: Wed, 29 Jun 2011 17:03:28 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: nickolasbug@gmail.com Subject: Re: UFS SU+J X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 21:29:04 -0000 On Thu, Jun 16, 2011 at 9:01 AM, Bjoern A. Zeeb wrote: > On Jun 16, 2011, at 12:54 PM, nickolasbug@gmail.com wrote: > >> I' like to know, if there plans to MFC journaled softupdates to 8-stable= ? >> If yes, when it would be done? > > it cannot be done and will therefor not happen. =C2=A0There used to be a = branch > in user/jeff/ =C2=A0or somewhere in the /user or /project area in svn wit= h an > older version of a backport but I am not sure if it was ever updated agai= n. > > /bz > > -- > Bjoern A. Zeeb =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 You have to have vi= sions! > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stop bit received. Insert coin for new addres= s family. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ . Why would suj not make it into 8-STABLE ? --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 01:33:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7A77106564A for ; Thu, 30 Jun 2011 01:33:30 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 77F298FC0C for ; Thu, 30 Jun 2011 01:33:30 +0000 (UTC) Received: by iyb11 with SMTP id 11so2105549iyb.13 for ; Wed, 29 Jun 2011 18:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to; bh=LtSbdqxLSmPUl9eJ5JlPXuJtemFpTv37W8hJVNWFwaY=; b=IM49xWr7DZWs+SIq+Sjwu3Gqw1wyVAw/nk6/Iii2h/vi+Meih2KO0+x2s1ww26VDgR wLpcqqmdxlod4ALghw7mZF1rnFIDXQzYcPcBIQ4in722XkmlJoqjqHx5ZuZEmK4c/p2U QL/McoQLrE62tb25aEpai0M7qxdEceIQoqZmw= Received: by 10.42.155.74 with SMTP id t10mr1325724icw.527.1309397609785; Wed, 29 Jun 2011 18:33:29 -0700 (PDT) Received: from DataIX.net (adsl-99-190-86-179.dsl.klmzmi.sbcglobal.net [99.190.86.179]) by mx.google.com with ESMTPS id d6sm1615182icx.1.2011.06.29.18.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 18:33:28 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p5U1XO3f042305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 21:33:25 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p5U1XN2n042304; Wed, 29 Jun 2011 21:33:23 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Wed, 29 Jun 2011 21:33:23 -0400 From: jhell To: Torfinn Ingolfsen Message-ID: <20110630013323.GA41789@DataIX.net> References: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> Cc: freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 01:33:30 -0000 On Wed, Jun 29, 2011 at 07:04:31PM +0200, Torfinn Ingolfsen wrote: > On Wed, 29 Jun 2011 22:50:15 +1000 > Antony Mawer wrote: > > > Hi all, > > > > Not sure if this is the right place to post it -- about 6 years ago I > > put together a module which displays an ASCII splash screen on boot > > (rather than the graphical splash_pcx and splash_bmp modules). We have > > been running it in production since that time without issue. > > So, the difference between this and loader.conf's loader_logo construct is that > a) this is a proper splash screen module > b) you can / must design your splash screen with a separate program (compared to write / modify Forth code) > > Is my understanding correct? Sorry but I can never resist... Youve been running this in production... How often do these servers reboot ;¿ and is it to identify what is actually running on the machine so they are not confused with surrounding equipment ? Most admins that I know don't bother with things like splash screens on 'production' equipment because its irrelevant to the actual server usage and unneeded overhead since the actual boot messages prove much more useful than some random ascii or bmp/pcx. Again though my view of a production box/blade may be quite a bit different than your usage so all-in-all nice contribution, Im just that guy that doesn't waste time covering up usefulness. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 02:47:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AC0C1065672 for ; Thu, 30 Jun 2011 02:47:47 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5C5F8FC0C for ; Thu, 30 Jun 2011 02:47:46 +0000 (UTC) Received: by bwa20 with SMTP id 20so2162601bwa.13 for ; Wed, 29 Jun 2011 19:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.14.18 with SMTP id e18mr1319679bka.175.1309402065146; Wed, 29 Jun 2011 19:47:45 -0700 (PDT) Received: by 10.204.63.71 with HTTP; Wed, 29 Jun 2011 19:47:45 -0700 (PDT) In-Reply-To: <20110630013323.GA41789@DataIX.net> References: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> <20110630013323.GA41789@DataIX.net> Date: Thu, 30 Jun 2011 12:47:45 +1000 Message-ID: From: Antony Mawer To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 02:47:47 -0000 On Thu, Jun 30, 2011 at 11:33 AM, jhell wrote: > Youve been running this in production... How often do these servers > reboot ;=BF and is it to identify what is actually running on the machine > so they are not confused with surrounding equipment ? > > Most admins that I know don't bother with things like splash screens on > 'production' equipment because its irrelevant to the actual server > usage and unneeded overhead since the actual boot messages prove much > more useful than some random ascii or bmp/pcx. They're embedded-style server systems at remote client sites, about 1200 of them. The splash module is just a visual "nicety" which is displayed during startup - at least providing some feedback as to what the system is doing. These are systems aimed at a non-tech audience, so those "niceties" count. The alternative to that was either standard kernel messages during boot, or a silent boot, both of which tend to confuse the crap out of non-tech end users. -- Antony From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 02:53:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E933D106566B for ; Thu, 30 Jun 2011 02:53:57 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBCC8FC13 for ; Thu, 30 Jun 2011 02:53:57 +0000 (UTC) Received: by bwa20 with SMTP id 20so2166293bwa.13 for ; Wed, 29 Jun 2011 19:53:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.136.217 with SMTP id s25mr1412153bkt.13.1309402436215; Wed, 29 Jun 2011 19:53:56 -0700 (PDT) Received: by 10.204.63.71 with HTTP; Wed, 29 Jun 2011 19:53:56 -0700 (PDT) In-Reply-To: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> References: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> Date: Thu, 30 Jun 2011 12:53:56 +1000 Message-ID: From: Antony Mawer To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 02:53:58 -0000 On Thu, Jun 30, 2011 at 3:04 AM, Torfinn Ingolfsen wrote: > On Wed, 29 Jun 2011 22:50:15 +1000 > Antony Mawer wrote: >> Not sure if this is the right place to post it -- about 6 years ago I >> put together a module which displays an ASCII splash screen on boot >> (rather than the graphical splash_pcx and splash_bmp modules). We have >> been running it in production since that time without issue. > > So, the difference between this and loader.conf's loader_logo construct is that > a) this is a proper splash screen module > b) you can / must design your splash screen with a separate program (compared to write / modify Forth code) > > Is my understanding correct? Not quite. The loader_logo is only displayed at the boot screen, and disappears as soon as the kernel begins booting. The splash module effectively creates an "overlay" display which is placed on-screen while the kernel probes devices and starts up, replacing the standard startup messages. Think more along the lines of your OS boot screen on Windows/Mac/Linux. In our case, this provides a clean boot screen instead of confusing probe messages (or silence if they're hidden) while the system starts, which can be reassuring to a non-tech audience, and does so without reliance on VESA support which doesn't always work on the systems we work with. The choice of file format was simply that it was an easy to use format supported by ASCII drawing software that I was familiar with (TheDraw, DuhDraw). There is nothing to stop someone adding support for a different format of encoding if they wanted -- the same as someone could write a splash_jpg or splash_gif module if they really wanted to. -- Antony From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 03:11:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A51F0106564A for ; Thu, 30 Jun 2011 03:11:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63D478FC1A for ; Thu, 30 Jun 2011 03:11:00 +0000 (UTC) Received: by iyb11 with SMTP id 11so2165488iyb.13 for ; Wed, 29 Jun 2011 20:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to; bh=H2Yymh6fwMrEfrWhqL94GVR0pDxsQD4LwpXqyXEmnec=; b=OfG0sDGQgYGmZphg4tSGxXYoVw0BIDtLg9iLdfhIQhv9Ynn5abVgjCRn/rOtrV62qN cwtKxE07GcGW/O27+R+7A3725BLMlfn++BiJ7hshGZTkqLs7hCdGqeUiZydLfo8DN2Ss +Kfb7Ub0FRZOxAt+GFq5IXivevyfWz1zJRe88= Received: by 10.42.156.8 with SMTP id x8mr1551985icw.519.1309403459637; Wed, 29 Jun 2011 20:10:59 -0700 (PDT) Received: from DataIX.net (adsl-99-190-86-179.dsl.klmzmi.sbcglobal.net [99.190.86.179]) by mx.google.com with ESMTPS id v15sm954644ibh.62.2011.06.29.20.10.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 20:10:58 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p5U3Att5051177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 23:10:55 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p5U3AsBx051176; Wed, 29 Jun 2011 23:10:55 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Wed, 29 Jun 2011 23:10:54 -0400 From: jhell To: Antony Mawer Message-ID: <20110630031054.GC41789@DataIX.net> References: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> <20110630013323.GA41789@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 03:11:00 -0000 On Thu, Jun 30, 2011 at 12:47:45PM +1000, Antony Mawer wrote: > On Thu, Jun 30, 2011 at 11:33 AM, jhell wrote: > > Youve been running this in production... How often do these servers > > reboot ;¿ and is it to identify what is actually running on the machine > > so they are not confused with surrounding equipment ? > > > > Most admins that I know don't bother with things like splash screens on > > 'production' equipment because its irrelevant to the actual server > > usage and unneeded overhead since the actual boot messages prove much > > more useful than some random ascii or bmp/pcx. > > They're embedded-style server systems at remote client sites, about > 1200 of them. The splash module is just a visual "nicety" which is > displayed during startup - at least providing some feedback as to what > the system is doing. These are systems aimed at a non-tech audience, > so those "niceties" count. > > The alternative to that was either standard kernel messages during > boot, or a silent boot, both of which tend to confuse the crap out of > non-tech end users. > Yeah I agree. I originally downloaded your patch, I think it was for a 6.X system back then ~2008-09ish possibly even 7.X and twiddled with it for a bit playing around with all the funkiness of TheDraw and getting that good ole feeling of BBS days. But that's usually about as far as I go with things like that as you could probably tell from above ;) I was going through my archive file directory probably last month and came across the copy of the program which made me remember that patch, funny coincidence that it comes back up now ;) I must say though having to use a reproducible .bin file over trying to figure out all the complexities of making a proper gzip'd xpm,bmp,pcx file was NICE! My first attempt ever making a splash image bmp was a fail due to manual reading problems but needless to say it was a pain. TheDraw nearly painless but how long can we seriously hold on to that program and will there ever be anything to replace it ? From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 03:32:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3AE9106566B for ; Thu, 30 Jun 2011 03:32:09 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 455F48FC14 for ; Thu, 30 Jun 2011 03:32:08 +0000 (UTC) Received: by bwa20 with SMTP id 20so2188140bwa.13 for ; Wed, 29 Jun 2011 20:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.85.25 with SMTP id m25mr1428263bkl.148.1309404727010; Wed, 29 Jun 2011 20:32:07 -0700 (PDT) Received: by 10.204.63.71 with HTTP; Wed, 29 Jun 2011 20:32:06 -0700 (PDT) In-Reply-To: <20110630031054.GC41789@DataIX.net> References: <20110629190431.e03ac76f.torfinn.ingolfsen@broadpark.no> <20110630013323.GA41789@DataIX.net> <20110630031054.GC41789@DataIX.net> Date: Thu, 30 Jun 2011 13:32:06 +1000 Message-ID: From: Antony Mawer To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 03:32:09 -0000 On Thu, Jun 30, 2011 at 1:10 PM, jhell wrote: > On Thu, Jun 30, 2011 at 12:47:45PM +1000, Antony Mawer wrote: >> On Thu, Jun 30, 2011 at 11:33 AM, jhell wrote: >> > Most admins that I know don't bother with things like splash screens o= n >> > 'production' equipment because its irrelevant to the actual server >> > usage and unneeded overhead since the actual boot messages prove much >> > more useful than some random ascii or bmp/pcx. >> >> They're embedded-style server systems at remote client sites, about >> 1200 of them. The splash module is just a visual "nicety" which is >> displayed during startup - at least providing some feedback as to what >> the system is doing. These are systems aimed at a non-tech audience, >> so those "niceties" count. >> >> The alternative to that was either standard kernel messages during >> boot, or a silent boot, both of which tend to confuse the crap out of >> non-tech end users. > > Yeah I agree. I originally downloaded your patch, I think it was for a > 6.X system back then ~2008-09ish possibly even 7.X and twiddled with it > for a bit playing around with all the funkiness of TheDraw and getting > that good ole feeling of BBS days. But that's usually about as far as I > go with things like that as you =A0could probably tell from above ;) > > I was going through my archive file directory probably last month and > came across the copy of the program which made me remember that patch, > funny coincidence that it comes back up now ;) > > I must say though having to use a reproducible .bin file over trying to > figure out all the complexities of making a proper gzip'd xpm,bmp,pcx > file was NICE! > > My first attempt ever making a splash image bmp was a fail due to manual > reading problems but needless to say it was a pain. TheDraw nearly > painless but how long can we seriously hold on to that program and will > there ever be anything to replace it ? I had to update our splash screen recently for $WORK, and have recently shifted my primary desktop+laptop to a Mac. Thought I'd give DOSBox a go and sure enough TheDraw fired up beautifully! You are right about it being a flash back to the BBS days. I have used DuhDraw (open source clone of TheDraw) under Linux many many years ago; there's a port in graphics/duhdraw if anyone wanted to try it out and see if it still works. In theory it should work just as well as TheDraw... Have been keeping this building in our local tree for all these years, but figured that there must be some people out there who might like to use it too... -- Antony From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 07:13:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E84D106564A; Thu, 30 Jun 2011 07:13:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3B6428FC0C; Thu, 30 Jun 2011 07:13:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QcBRX-0006Ld-UR>; Thu, 30 Jun 2011 09:13:43 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QcBRX-0007mN-SP>; Thu, 30 Jun 2011 09:13:43 +0200 Message-ID: <4E0C2226.1060507@zedat.fu-berlin.de> Date: Thu, 30 Jun 2011 09:13:42 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110627 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joshua Boyd References: <4E0ADB0A.2070409@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 07:13:45 -0000 On 06/29/11 15:57, Joshua Boyd wrote: > 2011/6/29 O. Hartmann > > > Questions: > a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS > issue which can be solved? > > > Hi Oliver, > > Neither, unfortunately. The 1068E based cards do not support drives over > 2TB. See here: > > http://kb.lsi.com/KnowledgebaseArticle16399.aspx > > -- > Joshua Boyd > > E-mail: boydjd@jbip.net > http://www.jbip.net Hello Joshua. Thanks for the fast response. Yes, you're right. I revealed by several postings in the net that the controller in question is not capable of handling disks > 2TB. It's a pitty. Oliver From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 10:28:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6C31065678 for ; Thu, 30 Jun 2011 10:28:37 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BD3548FC08 for ; Thu, 30 Jun 2011 10:28:36 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QcEU7-0007vh-9W for freebsd-stable@freebsd.org; Thu, 30 Jun 2011 12:28:35 +0200 Received: from 78-3-66-221.adsl.net.t-com.hr ([78.3.66.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 12:28:35 +0200 Received: from ivoras by 78-3-66-221.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 12:28:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 30 Jun 2011 12:28:20 +0200 Lines: 8 Message-ID: References: <8D25FDEA-9F87-4132-9DAA-1982B1DA72B2@lists.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-3-66-221.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: Subject: Re: UFS SU+J X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:28:37 -0000 On 29/06/2011 23:03, Mark Saad wrote: > The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ . > > Why would suj not make it into 8-STABLE ? It is a too large patch, and it changes a lot of important, known and working code (like softupdates). In other words, it's too risky. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 12:06:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F181065672; Thu, 30 Jun 2011 12:06:35 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7B8D8FC17; Thu, 30 Jun 2011 12:06:34 +0000 (UTC) Received: by bwa20 with SMTP id 20so2576311bwa.13 for ; Thu, 30 Jun 2011 05:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ApbmueIqT/KDAA7SCw19tv3udanLVaSDAbmWRmfdQgk=; b=pGamJThGmmZ1LMcNTtnEatzHtBcyAg4uW8eEvE9p/NKHSMPtLs5OXB5ginX96o3ewz B61LOU/06IXFTfrL3yWeVZGd25zpu0SqW5e4fCkFfQvMnFPOz9Y7yvf2dV1oX+LK5GFf ZL1n9T4yJdU1oyEepUcav3Qs6/nKihqkz8En8= Received: by 10.204.177.141 with SMTP id bi13mr1837485bkb.203.1309434251597; Thu, 30 Jun 2011 04:44:11 -0700 (PDT) Received: from [172.29.1.142] (altimet-gw.cs2.dp.wnet.ua [217.20.178.249]) by mx.google.com with ESMTPS id c13sm2024339bkc.2.2011.06.30.04.44.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 04:44:10 -0700 (PDT) Message-ID: <4E0C62B8.5090802@gmail.com> Date: Thu, 30 Jun 2011 14:49:12 +0300 From: Vitaly Magerya User-Agent: Thunderbird MIME-Version: 1.0 To: Antony Mawer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:06:35 -0000 Antony Mawer wrote: > Not sure if this is the right place to post it -- about 6 years ago I > put together a module which displays an ASCII splash screen on boot > (rather than the graphical splash_pcx and splash_bmp modules). As a user, I think this is rather cool; at least it is more useful for me than bmp/pcx splash modules, as I don't want to load vesa. Hm... Can you center the image if the display size is other than 80x25? Or try to temporarily change the video mode? It looks a bit misplaced in 80x50. Also, this would be 2x as cool if you could animate the splash. For example, if the supplied bitmap is 80x50, you could treat that as 2 frames, and cycle through them periodically (I assume that splash modules work the same way as saved modules do: the main function is called a few times per second, so you can update the screen there). BTW, in txt_init you currently check for data_size <= 0; you should also check for data_size < BIN_IMAGE_WIDTH * BIN_IMAGE_HEIGHT * 2, since if the bitmap is smaller, you'll draw garbage on the screen. > I have uploaded two sample boot splash screens at > http://www.mawer.org/freebsd/freebsd1.bin and > http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced > using TheDraw and saving in its Binary file format, which consists of > a sequence of 2 byte pairs. The first byte in a pair is the character > to draw on the screen, and the second is the colour/display attributes > to draw the character with. As a side note, these images can also be made from video buffer dumps that vidcontrol produces like this: vidcontrol -p < /dev/ttyv0 | tail -c +13 > screenshot.bin (Substitute ttyv0 for the tty you want to take a picture of; the tty should be in 80x25 mode). From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 16:41:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3CC1065672; Thu, 30 Jun 2011 16:41:50 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 600EB8FC0A; Thu, 30 Jun 2011 16:41:49 +0000 (UTC) Received: by fxe6 with SMTP id 6so2058794fxe.17 for ; Thu, 30 Jun 2011 09:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jbip.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TK9+0LjsjJoiasOR673nbmkmLSFvYEhy5MWiuD3aDlY=; b=bR3CFAfrvsEkHHU9rTATb15jI0PKpiuJbCBXQxNSvue/m40uHbWxbgg0i2ip/QKIai MyXgWRa23vRRcOOvmaxnoHT5G3XooOi+vzw0UJ1LtMt3RbLY3brF459IktR0wFqgl/Kh koc0JsY1vOPHjMFIXvZ5DcFZs01lf2iCjJhwo= Received: by 10.223.61.134 with SMTP id t6mr3262016fah.28.1309452109145; Thu, 30 Jun 2011 09:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.106.131 with HTTP; Thu, 30 Jun 2011 09:41:29 -0700 (PDT) In-Reply-To: <4E0C2226.1060507@zedat.fu-berlin.de> References: <4E0ADB0A.2070409@zedat.fu-berlin.de> <4E0C2226.1060507@zedat.fu-berlin.de> From: Joshua Boyd Date: Thu, 30 Jun 2011 12:41:29 -0400 Message-ID: To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:41:51 -0000 2011/6/30 O. Hartmann > It's a pitty. > Indeed, it is. I have 3 1068s for 45 bays, I'm gonna have to buy new cards :(. -- Joshua Boyd E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 17:32:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC4A106566B for ; Thu, 30 Jun 2011 17:32:00 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id DB9FE8FC0C for ; Thu, 30 Jun 2011 17:31:59 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QcL5p-000846-Cn for freebsd-stable@freebsd.org; Thu, 30 Jun 2011 19:31:57 +0200 Received: from dtmd-4d0bfb17.pool.mediaways.net ([77.11.251.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 19:31:57 +0200 Received: from christian.baer by dtmd-4d0bfb17.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 19:31:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Christian Baer Date: Thu, 30 Jun 2011 19:31:44 +0200 Lines: 28 Message-ID: References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dtmd-4d0bfb17.pool.mediaways.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101125 Lightning/1.0b1 Thunderbird/3.0.11 In-Reply-To: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:32:00 -0000 On 18.06.2011 18:49, Stefan Bethke wrote: >> I have to slightly explain the word "crash" here: I don't actually >> have to hard reset the system myself. My box just does a reboot by >> itself. No filesystem is unmounted cleanly and because the machine >> isn't really new and powerful fsck takes pretty long. > > I can't help you with your controllers, but anyone in a position to > help will likely want to know if the box simply resets, or if the > kernel panics. And if there are going to be any patches, you most > certainly will want to get familiar with the debugger to help try > stuff out. The handbook has information on how to enable crash dumps > and getting the kernel debugger going. If you haven't done so > already, try and get a serial console going, it helps tremendously to > be able to cut&paste debugger info instead of trying to hand > transcribe it. As far as I can tell so far there isn't any realy kernel panik. But the machine resets alright. All I can find in /var/log/messages is what I have already written. :-( A serial console is easy enough to set up on a Sun for example, but in this case, I am running a simple AthlonXP, which has nothing for that sort of help. I would need a special card for that and those cose quite a bit. :-( Regards, Chris From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 18:06:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A51D11065673 for ; Thu, 30 Jun 2011 18:06:52 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (unknown [IPv6:2001:470:1f15:a0::10]) by mx1.freebsd.org (Postfix) with ESMTP id 69DBF8FC0C for ; Thu, 30 Jun 2011 18:06:52 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 38D6138141 for ; Thu, 30 Jun 2011 20:06:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vI68xqQi4Ty for ; Thu, 30 Jun 2011 20:06:50 +0200 (CEST) Received: from appelflap.local (unknown [IPv6:2001:610:799:0:223:6cff:fe7f:480e]) by mail.knopje.net (Postfix) with ESMTPSA id C55AB38127 for ; Thu, 30 Jun 2011 20:06:50 +0200 (CEST) Message-ID: <4E0CBB3A.5020004@ronner.org> Date: Thu, 30 Jun 2011 20:06:50 +0200 From: Thomas Ronner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:06:52 -0000 On 6/30/11 7:31 PM, Christian Baer wrote: > As far as I can tell so far there isn't any realy kernel panik. But the > machine resets alright. All I can find in /var/log/messages is what I > have already written. :-( > > A serial console is easy enough to set up on a Sun for example, but in > this case, I am running a simple AthlonXP, which has nothing for that > sort of help. I would need a special card for that and those cose quite > a bit. :-( You can use a USB to serial converter. They cost around $20. I don't know which one to choose; I've never used one on FreeBSD so hopefully someone else can fill me in here. Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 18:09:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80521065674 for ; Thu, 30 Jun 2011 18:09:02 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 35B838FC08 for ; Thu, 30 Jun 2011 18:09:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QcLff-0007hF-Bj for freebsd-stable@freebsd.org; Thu, 30 Jun 2011 20:08:59 +0200 Received: from dtmd-4d0bfb17.pool.mediaways.net ([77.11.251.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 20:08:59 +0200 Received: from christian.baer by dtmd-4d0bfb17.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jun 2011 20:08:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Christian Baer Date: Thu, 30 Jun 2011 20:08:44 +0200 Lines: 72 Message-ID: References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> <20110618175215.GA18645@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dtmd-4d0bfb17.pool.mediaways.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101125 Lightning/1.0b1 Thunderbird/3.0.11 In-Reply-To: <20110618175215.GA18645@icarus.home.lan> Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:09:02 -0000 On 18.06.2011 19:52, Jeremy Chadwick wrote: Hello Jeremy! Thanks for your long answer! I'm sorry to have kept you waiting but I was out of town and turned off all my computers while I was away. > It may be that the kernel is panic'ing and auto-rebooting before he can > see the message in question. I would advocate he put the following > directives in his kernel configuration and rebuild/reinstall kernel and > wait for it to happen again. > > # Debugging options > options KDB # Enable kernel debugger support > options KDB_TRACE # Print stack trace automatically on panic > options DDB # Support DDB > options GDB # Support remote GDB > > If after doing this the machine literally reboots rather than panics, > then that would indicate a mainboard having issues, or power-related > stuff (keep reading). I always read the full post if someone takes the time to help me out. :-) Ok, new kernel compiled and installed. System restarted and running. :-) I'm guessing that a panic won't show up in the log files, but only on the console. I have set up a monitor for this machine (normally it doesn't have one). I'll try to provoke the little problem as of now and I will get back to you as soon at I have something. [power issues] > I have no proof this is Christian's problem, but it's worth > considering anyway. You don't need proof to encourage me to start poking around in a certain area. Hell, it's pretty hard to give someone proof when only aswering to a post on a mailing list. :-) Don't feel bad. ;-) I have to admit that I haven't considered this and when running the numbers it seems pretty unlikely. The computer has 11 HDs running but even if we allow each HD 15W, that still isn't really all that much - not much more than a good graphics card. Apart from the CPU the computer has no real consumers (not even an optical drive). Apart from that, the problem doesn't seem to apply when reading from the drives, only when writing to them. I realize that writing uses a bit more power than reading but the "surge of writing" shouldn't be such a big deal that it could make the difference in my case. Or could it? Apart from that, HDs use much more power when spinning up. This doesn't seem to pose a problem for the power supply. I have seen no troubles when starting the system. What got me thinking was that I don't know how many of the drives are actually connected by a single rail. I didn't really pay much attention to that when I connected them but they should be spread somewhat just the same, mainly because the cables are just too short to connect everything to a single rail without *really* going out of you way to do it. Once I have a panic screen to show you I will grab a second power supply and start some tests. Please keep in mind though that I am not the only person out there with the same error using the same controller (type). I somehow doubt that all those hits by Google are all caused by power difficulties and the common controller is pure coincidence. Best regards, Chris From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 18:26:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A4C5106566B for ; Thu, 30 Jun 2011 18:26:12 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (unknown [IPv6:2001:470:1f15:a0::10]) by mx1.freebsd.org (Postfix) with ESMTP id D241F8FC0C for ; Thu, 30 Jun 2011 18:26:11 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id C62E33816E for ; Thu, 30 Jun 2011 20:26:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foGymfCB4aut for ; Thu, 30 Jun 2011 20:26:10 +0200 (CEST) Received: from appelflap.local (unknown [IPv6:2001:610:799:0:223:6cff:fe7f:480e]) by mail.knopje.net (Postfix) with ESMTPSA id 6074938127 for ; Thu, 30 Jun 2011 20:26:10 +0200 (CEST) Message-ID: <4E0CBFC2.40905@ronner.org> Date: Thu, 30 Jun 2011 20:26:10 +0200 From: Thomas Ronner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> <20110618175215.GA18645@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:26:12 -0000 On 6/30/11 8:08 PM, Christian Baer wrote: > Please keep in mind though that I am not the only person out there with > the same error using the same controller (type). I somehow doubt that > all those hits by Google are all caused by power difficulties and the > common controller is pure coincidence. > Just a little 'me too'. I used to have a system with an Athlon XP 3200+, an ASUS A7V880 mainboard (iirc) and a Promise SATA150TX4 and a Promise SATA300something, both PCI (no PCI-e) cards with 4 SATA ports. I didn't encounter system resets, but hard lockups with FreeBSD 7 and 8. No kernel messages on the console, everything just hang until I pressed the hard reset button. After about 3 months of testing and frustration I gave up and bought another controller. Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jun 30 21:19:58 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5202106566B; Thu, 30 Jun 2011 21:19:58 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 764F08FC14; Thu, 30 Jun 2011 21:19:58 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p5UKqJOR052583; Thu, 30 Jun 2011 14:52:19 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Thu, 30 Jun 2011 14:52:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82124F91-99C5-481E-A509-62BAAF64D1A9@samsco.org> References: <8D25FDEA-9F87-4132-9DAA-1982B1DA72B2@lists.zabbadoz.net> To: Ivan Voras X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-stable@FreeBSD.org Subject: Re: UFS SU+J X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:19:58 -0000 On Jun 30, 2011, at 4:28 AM, Ivan Voras wrote: > On 29/06/2011 23:03, Mark Saad wrote: >=20 >> The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ = . >>=20 >> Why would suj not make it into 8-STABLE ? >=20 > It is a too large patch, and it changes a lot of important, known and > working code (like softupdates). In other words, it's too risky. >=20 I'm preparing to put it into large-scale deployment at Yahoo on FreeBSD = 7. It wasn't ready for production until the latest round of fixes from = Jeff and Kirk. Scott From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 03:33:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62EF5106564A for ; Fri, 1 Jul 2011 03:33:53 +0000 (UTC) (envelope-from tts@personalmis.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EA3E68FC0A for ; Fri, 1 Jul 2011 03:33:52 +0000 (UTC) Received: by bwa20 with SMTP id 20so3361745bwa.13 for ; Thu, 30 Jun 2011 20:33:51 -0700 (PDT) Received: by 10.204.42.21 with SMTP id q21mr1327436bke.186.1309489344668; Thu, 30 Jun 2011 20:02:24 -0700 (PDT) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx.google.com with ESMTPS id k16sm2590963bks.13.2011.06.30.20.02.20 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:02:22 -0700 (PDT) Received: by bwa20 with SMTP id 20so3345761bwa.13 for ; Thu, 30 Jun 2011 20:02:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.19.83 with SMTP id z19mr2566192bka.191.1309489339783; Thu, 30 Jun 2011 20:02:19 -0700 (PDT) Received: by 10.204.117.198 with HTTP; Thu, 30 Jun 2011 20:02:19 -0700 (PDT) Date: Thu, 30 Jun 2011 20:02:19 -0700 Message-ID: From: Timothy Smith To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: HAST + ZFS: no action on drive failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 03:33:53 -0000 First posting here, hopefully I'm doing it right =) I also posted this to the FreeBSD forum, but I know some hast folks monitor this list regularly and not so much there, so... Basically, I'm testing failure scenarios with HAST/ZFS. I got two nodes, scripted up a bunch of checks and failover actions between the nodes. Looking good so far, though more complex that I expected. It would be cool to post it somewher to get some pointers/critiques, but that's another thing. Anyway, now I'm just seeing what happens when a drive fails on primary node. Oddly/sadly, NOTHING! Hast just keeps on a ticking, and doesn't change the state of the failed drive, so the zpool has no clue the drive is offline. The /dev/hast/ remains. The hastd does log some errors to the system log like this, but nothing more. messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Unable to flush activemap to disk: Device not configured. messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Local request failed (Device not configured): WRITE(4736512, 512). So, I guess the question is, "Do I have to script a cronjob to check for these kinds of errors and then change the hast resource to 'init' or something to handle this?" Or is there some kind of hastd config setting that I need to set? What's the SOP for this? As something related too, when the zpool in FreeBSD does finally notice that the drive is missing because I have manually changed the hast resource to INIT (so the /dev/hast/ is gone), my zpool (raidz2) hot spare doesn't engage, even with "autoreplace=on". The zpool status of the degraded pool seems to indicate that I should manually replace the failed drive. If that's the case, it's not really a "hot spare". Does this mean the "FMA Agent" referred to in the ZFS manual is not implemented in FreeBSD? thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 05:05:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B3110656E6 for ; Fri, 1 Jul 2011 05:05:09 +0000 (UTC) (envelope-from tsw5@duke.edu) Received: from mail-gw-01.oit.duke.edu (lb-mx-gateway-pat.oit.duke.edu [152.3.68.136]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9BA8FC1D for ; Fri, 1 Jul 2011 05:05:08 +0000 (UTC) Received: from mail-gw-01.oit.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AF2BA2FF5346_E0D5583B; Fri, 1 Jul 2011 05:05:07 +0000 (GMT) X-Sophos-ESA-SMTPD-Auth-On: authentication enabled X-Sophos-ESA-External-Sender: external sender X-Sophos-ESA-SMTPD-Auth-On: authentication enabled X-Sophos-ESA-External-Sender: external sender X-Sophos-ESA-SMTPD-Auth-On: authentication enabled X-Sophos-ESA-External-Sender: external sender Received: from shoggoth.rlyeh (c-76-103-21-157.hsd1.ca.comcast.net [76.103.21.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail-gw-01.oit.duke.edu (Sophos Email Appliance) with ESMTP id B63752FF5362_E0D5582F; Fri, 1 Jul 2011 05:05:06 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Todd Wasson In-Reply-To: Date: Thu, 30 Jun 2011 22:05:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. P. Ghost" , Pete French X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 05:05:22 -0000 Thanks to both C. P. and Pete for your responses. Comments inline: > Case 1.) is probably harmless, because geli would return a > corrupted sectors' content to zfs... which zfs will likely detect > because it wouldn't checksum correctly. So zfs will correct it > out of redundant storage, and write it back through a new > encryption. BE CAREFUL: don't enable hmac integrity checks > in geli, as that would prevent geli from returning corrupted > data and would result in hangs! Perhaps the hmac integrity checks were related to the lack of reporting = of problems back to zfs that Pete referred to? Maybe we need someone = with more technical experience with the filesystem / disk access = infrastructure to weigh in, but it still doesn't seem clear to me what = the best option is. > Case 2.) is a bigger problem. If a sector containing vital > geli metadata (perhaps portions of keys?) gets corrupted, > and geli had no way to detect and/or correct this (e.g. by > using redundant sectors on the same .eli volume!), the whole > .eli, or maybe some stripes out of it, could become useless. > ZFS couldn't repair this at all... at least not automatically. > You'll have to MANUALLY reformat the failed .eli device, and > resilver it from zfs redundant storage later. This is precisely the kind of thing that made me think about putting zfs = directly on the disks instead of geli... This, and other unknown issues = that could crop up and are out of geli's ability to guard against. > There may be other failure modes involved as well. I don't know. > But in most practical day to day uses, with enough redundancy > and regular backups, a zfs-over-geli should be good enough. I understand the point here, but I'm specifically thinking about my = backup server. As I understand it, part of the purpose of zfs is to be = reliable enough to run on a backup server itself, given some redundancy = as you say. Perhaps asking for encryption as well is asking too much = (at least, unless zfs v30 with zfs-crypto ever gets open-sourced and = ported) but I'd really like to maintain zfs' stability while also having = an option for encryption. > I wouldn't put {zfs,ufs}-over-geli-over-raw-zpool though, as this > would involve considerable overhead, IMHO. In this case, I'd > rather use a gmirror as a backend, as in a setup: > {zfs,ufs}-over-geli-over-{gmirror,graid3} > or something similar. But I've never tried this though. I understand about the overhead, but I'm interested in using zfs via a = zraid to avoid using gmirror or graid3, because of the benefits = (detection of silent corruption, etc.) that you get with a zraid. I = think your suggestion is a pretty good one in terms of = performance/reliability tradeoff, though. In my specific case I'm more = likely to pay a performance cost instead of a reliability cost, but only = because my server spends most of its time hanging around idling, and = throughput isn't really an issue. Thanks regardless, though. Todd= From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 08:46:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B99510656D3 for ; Fri, 1 Jul 2011 08:46:28 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAE768FC20 for ; Fri, 1 Jul 2011 08:46:27 +0000 (UTC) Received: by qwc9 with SMTP id 9so2060405qwc.13 for ; Fri, 01 Jul 2011 01:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vnf80JLzSPLlWg+1e7RJbgII9kp7Np2F2AII215JVZA=; b=bUcBDJmB0EAFR+WpLbwoKzNNu1mqkXJLjZfvSZP5YS4Bwo8r+bZJv9JniplR2YDAav JXRmzCUgF1b/NHd5fVNUrUOWn/Z8XQqwQll4HsH8QeAMflOoeJBGqzN5X+oLJm3VZa/H nu2Drok5sJvDsxlSAM2n5Ww/e2d686PXesMYE= MIME-Version: 1.0 Received: by 10.229.37.71 with SMTP id w7mr2390338qcd.15.1309509987029; Fri, 01 Jul 2011 01:46:27 -0700 (PDT) Received: by 10.229.102.17 with HTTP; Fri, 1 Jul 2011 01:46:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jul 2011 11:46:26 +0300 Message-ID: From: nickolasbug@gmail.com To: Todd Wasson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, "C. P. Ghost" , Pete French Subject: Re: zfs on geli vs. geli on zfs (via zvol) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:46:28 -0000 2011/7/1 Todd Wasson : > Thanks to both C. P. and Pete for your responses. =A0Comments inline: > >> Case 1.) is probably harmless, because geli would return a >> corrupted sectors' content to zfs... which zfs will likely detect >> because it wouldn't checksum correctly. So zfs will correct it >> out of redundant storage, and write it back through a new >> encryption. BE CAREFUL: don't enable hmac integrity checks >> in geli, as that would prevent geli from returning corrupted >> data and would result in hangs! > > Perhaps the hmac integrity checks were related to the lack of reporting o= f problems back to zfs that Pete referred to? =A0Maybe we need someone with= more technical experience with the filesystem / disk access infrastructure= to weigh in, but it still doesn't seem clear to me what the best option is= . > >> Case 2.) is a bigger problem. If a sector containing vital >> geli metadata (perhaps portions of keys?) gets corrupted, >> and geli had no way to detect and/or correct this (e.g. by >> using redundant sectors on the same .eli volume!), the whole >> .eli, or maybe some stripes out of it, could become useless. >> ZFS couldn't repair this at all... at least not automatically. >> You'll have to MANUALLY reformat the failed .eli device, and >> resilver it from zfs redundant storage later. > > This is precisely the kind of thing that made me think about putting zfs = directly on the disks instead of geli... =A0This, and other unknown issues = that could crop up and are out of geli's ability to guard against. > Agree. If you wanna have encrypted ZFS it's better to wait until zpool version 30 (which supports encryption) will be ported to FreeBSD. ------- wbr, Nickolas From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 10:44:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B11106566B for ; Fri, 1 Jul 2011 10:44:10 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61C398FC14 for ; Fri, 1 Jul 2011 10:44:10 +0000 (UTC) Received: by vws18 with SMTP id 18so3115609vws.13 for ; Fri, 01 Jul 2011 03:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VQJmUpxLup7UH9tduGMir8Md1MJ/H5dDBylaERfvS6g=; b=SZKu8xYrhtHX+xfuVRvMt8hQOyhZXGRwVLYYqFWPvoRVfkbcu4ti5Nbu3BL3AQQ9ca XAnYcMwh8wMGo2UK+ZWuK8jY0gTEPoBYoUi3yfqLqbziKPxzQzc/bnPaIbxaBvKMV6Ih Va5asrk6ZyjOLpwoiJF95ODgmmkXh54N6R1Ek= MIME-Version: 1.0 Received: by 10.52.76.10 with SMTP id g10mr605251vdw.252.1309515504489; Fri, 01 Jul 2011 03:18:24 -0700 (PDT) Received: by 10.52.108.4 with HTTP; Fri, 1 Jul 2011 03:18:24 -0700 (PDT) In-Reply-To: References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> Date: Fri, 1 Jul 2011 11:18:24 +0100 Message-ID: From: Tom Evans To: Christian Baer Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 10:44:10 -0000 On Thu, Jun 30, 2011 at 6:31 PM, Christian Baer wrote: > A serial console is easy enough to set up on a Sun for example, but in > this case, I am running a simple AthlonXP, which has nothing for that > sort of help. I would need a special card for that and those cose quite > a bit. :-( > Not that special - you just need a serial port on two computers. If your computers don't have serial ports, USB serial adapters work fine, and are cheap, as are (single port) PCI serial cards. Alternatively, if both computers have firewire ports, you can use dcons, and all you need is a cable. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 19:36:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16C4A1065670 for ; Fri, 1 Jul 2011 19:36:33 +0000 (UTC) (envelope-from cscotts@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 337968FC14 for ; Fri, 1 Jul 2011 19:36:31 +0000 (UTC) Received: by fxe6 with SMTP id 6so2987405fxe.17 for ; Fri, 01 Jul 2011 12:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6s/TczsQa3tw8nBGS1ELHEqjL2fc/6HGz71+sgLKpWA=; b=WYcPaaiB+TWdi8R4+gr2jcua6hkowu6vwneyU+zWowmCaN8LRuyosBVoaRGAx4IpQF ZbB4BJkaHxzub4YwksrLVvs9YVeI4nFyl9F8BdM4UD7zVdKDooH9AZ1LDw0t5o2CEbyq PbIi273FnMb1iaA9vGPPm716nmH1vjLPTp1YY= MIME-Version: 1.0 Received: by 10.223.156.9 with SMTP id u9mr5318840faw.70.1309547597396; Fri, 01 Jul 2011 12:13:17 -0700 (PDT) Received: by 10.223.125.201 with HTTP; Fri, 1 Jul 2011 12:13:17 -0700 (PDT) Date: Fri, 1 Jul 2011 15:13:17 -0400 Message-ID: From: Scott Sipe To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=002354010a9a5bfc4e04a706cfac X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: scp: Write Failed: Cannot allocate memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:36:33 -0000 --002354010a9a5bfc4e04a706cfac Content-Type: text/plain; charset=ISO-8859-1 Hello, I'm running 8.2-RELEASE and am having new problems with scp. When scping files to a ZFS directory on the FreeBSD server -- most notably large files -- the transfer frequently dies after just a few seconds. In my last test, I tried to scp an 800mb file to the FreeBSD system and the transfer died after 200mb. It completely copied the next 4 times I tried, and then died again on the next attempt. On the client side: "Connection to home closed by remote host. lost connection" In /var/log/auth.log: Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot allocate memory I've never seen this before and have used scp before to transfer large files without problems. This computer has been used in production for months and has a current uptime of 36 days. I have not been able to notice any problems copying files to the server via samba or netatalk, or any problems in apache. Uname: FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 EST 2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64 I've attached my dmesg and output of vmstat -z. I have not restarted the sshd daemon or rebooted the computer. Am glad to provide any other information or test anything else. Thanks, Scott --002354010a9a5bfc4e04a706cfac Content-Type: text/plain; charset=US-ASCII; name="vmstat.txt" Content-Disposition: attachment; filename="vmstat.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpligd9n1 IyB2bXN0YXQgLXoKSVRFTSAgICAgICAgICAgICAgICAgICAgIFNJWkUgICAgIExJTUlUICAgICAg VVNFRCAgICAgIEZSRUUgIFJFUVVFU1RTICBGQUlMVVJFUwoKVU1BIEtlZ3M6ICAgICAgICAgICAg ICAgICAyMDgsICAgICAgICAwLCAgICAgIDIwNSwgICAgICAgMTYsICAgICAgMjA1LCAgICAgICAg MApVTUEgWm9uZXM6ICAgICAgICAgICAgICAgIDcwNCwgICAgICAgIDAsICAgICAgMjA1LCAgICAg ICAgMCwgICAgICAyMDUsICAgICAgICAwClVNQSBTbGFiczogICAgICAgICAgICAgICAgNTY4LCAg ICAgICAgMCwgICAgNjk1MDMsICAgIDMyNzExLCA3Mjk0MjUwOSwgICAgICAgIDAKVU1BIFJDbnRT bGFiczogICAgICAgICAgICA1NjgsICAgICAgICAwLCAgICAgNDY2NywgICAgICA1ODMsICAgICA1 NjY0LCAgICAgICAgMApVTUEgSGFzaDogICAgICAgICAgICAgICAgIDI1NiwgICAgICAgIDAsICAg ICAgIDc5LCAgICAgICAxMSwgICAgICAgODEsICAgICAgICAwCjE2IEJ1Y2tldDogICAgICAgICAg ICAgICAgMTUyLCAgICAgICAgMCwgICAgICAgODUsICAgICAgMTY1LCAgICAgIDIyNywgICAgICAg IDAKMzIgQnVja2V0OiAgICAgICAgICAgICAgICAyODAsICAgICAgICAwLCAgICAgIDIzOCwgICAg ICAxOTYsICAgICAgNDQyLCAgICAgICAgMQo2NCBCdWNrZXQ6ICAgICAgICAgICAgICAgIDUzNiwg ICAgICAgIDAsICAgICAgMzU5LCAgICAgIDIyMiwgICAgICA3MjEsICAgICAgMTI2CjEyOCBCdWNr ZXQ6ICAgICAgICAgICAgICAxMDQ4LCAgICAgICAgMCwgICAgIDU4NjcsICAgICAgICAxLCAgICA0 NTI5NiwgICAxOTY3MDEKVk0gT0JKRUNUOiAgICAgICAgICAgICAgICAyMTYsICAgICAgICAwLCAg ICAyNjY5OCwgICAgMjcxNDAsIDQwNzEyOTEyLCAgICAgICAgMApNQVA6ICAgICAgICAgICAgICAg ICAgICAgIDIzMiwgICAgICAgIDAsICAgICAgICA3LCAgICAgICAyNSwgICAgICAgIDcsICAgICAg ICAwCktNQVAgRU5UUlk6ICAgICAgICAgICAgICAgMTIwLCAgIDQxMjczNCwgICAgMTUyNDQsICAg ICAzMjAxLCAyMDAzOTk2NjksICAgICAgICAwCk1BUCBFTlRSWTogICAgICAgICAgICAgICAgMTIw LCAgICAgICAgMCwgICAgMTA3OTUsICAgICA3NTU3LCA2NDA5NjQ1NywgICAgICAgIDAKRFAgZmFr ZXBnOiAgICAgICAgICAgICAgICAxMjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMApTRyBmYWtlcGc6ICAgICAgICAgICAgICAgIDEyMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm10X3pvbmU6ICAgICAgICAg ICAgICAgICAyMDU2LCAgICAgICAgMCwgICAgICAyNzgsICAgICAgICAxLCAgICAgIDI3OCwgICAg ICAgIDAKMTY6ICAgICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgICAwLCAgICA4ODU2OCwg ICAxNTM2ODgsIDE5MTM3NTA5MTIsICAgICAgICAwCjMyOiAgICAgICAgICAgICAgICAgICAgICAg IDMyLCAgICAgICAgMCwgICAgIDM4MjUsICAgIDEyMDMyLCAyNjA3OTY1MDcsICAgICAgICAwCjY0 OiAgICAgICAgICAgICAgICAgICAgICAgIDY0LCAgICAgICAgMCwgICAgNzAxMDYsICAgMTk1OTUw LCAyMTUwNzUyMDg3MCwgICAgICAgIDAKMTI4OiAgICAgICAgICAgICAgICAgICAgICAxMjgsICAg ICAgICAwLCAgIDQyODUxOCwgICAzMzc4MzYsIDMxNjI0MTY3MTcsICAgICAgICAwCjI1NjogICAg ICAgICAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgNDcwNzEsICAgMTk3MDk5LCA1MTcy ODk1NjMsICAgICAgICAwCjUxMjogICAgICAgICAgICAgICAgICAgICAgNTEyLCAgICAgICAgMCwg ICA1OTM5MjEsICAgNjU2ODUzLCA1NjMzMzg0ODgsICAgICAgICAwCjEwMjQ6ICAgICAgICAgICAg ICAgICAgICAxMDI0LCAgICAgICAgMCwgICAgIDcxOTAsICAgIDE4NDIyLCAyNTYwNDI2MSwgICAg ICAgIDAKMjA0ODogICAgICAgICAgICAgICAgICAgIDIwNDgsICAgICAgICAwLCAgICAgNTI3MSwg ICAgIDU1NTksICA3NTY1NzkyLCAgICAgICAgMAo0MDk2OiAgICAgICAgICAgICAgICAgICAgNDA5 NiwgICAgICAgIDAsICAgICAzMzQ0LCAgICAgMjAzMCwgNTcyNTUyMzAsICAgICAgICAwCkZpbGVz OiAgICAgICAgICAgICAgICAgICAgIDgwLCAgICAgICAgMCwgICAgIDE2MDMsICAgICAyMzEyLCA1 MjQ0MzQ0OCwgICAgICAgIDAKVFVSTlNUSUxFOiAgICAgICAgICAgICAgICAxMzYsICAgICAgICAw LCAgICAgMjUxNSwgICAgICAyNjUsICAgICAyNTQ1LCAgICAgICAgMAp1bXR4IHBpOiAgICAgICAg ICAgICAgICAgICA5NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCk1BQyBsYWJlbHM6ICAgICAgICAgICAgICAgIDQwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKUFJPQzogICAgICAgICAgICAgICAgICAgIDEx MjAsICAgICAgICAwLCAgICAgIDExMiwgICAgIDE1NDQsICAxMTE3Mzc4LCAgICAgICAgMApUSFJF QUQ6ICAgICAgICAgICAgICAgICAgMTExMiwgICAgICAgIDAsICAgICAxOTMyLCAgICAgIDU4Miwg ICAgIDMxMDEsICAgICAgICAwClNMRUVQUVVFVUU6ICAgICAgICAgICAgICAgIDgwLCAgICAgICAg MCwgICAgIDI1MTUsICAgICAgMjk4LCAgICAgMjU0NSwgICAgICAgIDAKVk1TUEFDRTogICAgICAg ICAgICAgICAgICAzOTIsICAgICAgICAwLCAgICAgICA4NiwgICAgICA3ODQsICAxMTE4NDEyLCAg ICAgICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAgICA3MiwgICAgICAgIDAsICAgICAgICAy LCAgICAgICA5OCwgICAgICAgIDIsICAgICAgICAwCmF1ZGl0X3JlY29yZDogICAgICAgICAgICAg OTUyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKbWJ1 Zl9wYWNrZXQ6ICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgMTAyNCwgICAgIDM1ODQs IDIxODIyMDg2OSwgICAgICAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAg ICAwLCAgICAgICAgMSwgICAgIDM0NjEsIDU2MjczNTQ5NCwgICAgICAgIDAKbWJ1Zl9jbHVzdGVy OiAgICAgICAgICAgIDIwNDgsICAgIDI1NjAwLCAgICAgNDYwOCwgICAgIDEwMDgsICAgICA1NjMy LCAgICAgICAgMAptYnVmX2p1bWJvX3BhZ2U6ICAgICAgICAgNDA5NiwgICAgMTI4MDAsICAgICAg ICAwLCAgICAgMTg1OSwgNTAwMTcwODUsICAgICAgICAwCm1idWZfanVtYm9fOWs6ICAgICAgICAg ICA5MjE2LCAgICAgNjQwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK bWJ1Zl9qdW1ib18xNms6ICAgICAgICAgMTYzODQsICAgICAzMjAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAptYnVmX2V4dF9yZWZjbnQ6ICAgICAgICAgICAgNCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgMzAyNCwgICAgIDY5NzgsICAgICAgICAwCmdfYmlvOiAgICAg ICAgICAgICAgICAgICAgMjMyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAyNDgwLCA0OTIyNzEz OTQsICAgICAgICAwCnR0eWlucTogICAgICAgICAgICAgICAgICAgMTYwLCAgICAgICAgMCwgICAg ICAxMzUsICAgICAgODAxLCAgICAgMjIwNSwgICAgICAgIDAKdHR5b3V0cTogICAgICAgICAgICAg ICAgICAyNTYsICAgICAgICAwLCAgICAgICA3MiwgICAgICA0ODMsICAgICAxMTc2LCAgICAgICAg MAphdGFfcmVxdWVzdDogICAgICAgICAgICAgIDMyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCmF0YV9jb21wb3NpdGU6ICAgICAgICAgICAgMzM2LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKdGFza3Ffem9u ZTogICAgICAgICAgICAgICAgNTYsICAgICAgICAwLCAgICAgICAgMCwgICAgIDMxNTAsICA2MDA4 NDk2LCAgICAgICAgMApWTk9ERTogICAgICAgICAgICAgICAgICAgIDQ3MiwgICAgICAgIDAsICAg IDc3OTA4LCAgICAyNDIyOCwgMTc1MDc2MTM5LCAgICAgICAgMApWTk9ERVBPTEw6ICAgICAgICAg ICAgICAgIDExMiwgICAgICAgIDAsICAgICAgICA3LCAgICAgICA5MiwgICAgICAgIDksICAgICAg ICAwCk5BTUVJOiAgICAgICAgICAgICAgICAgICAxMDI0LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgNTEyLCA0ODU3MzUyMzEsICAgICAgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgICAgMTA4 LCAgICAgICAgMCwgICAgNzUwNTAsICAgIDMyODYwLCAxNTk5MTQ5NjMsICAgICAgICAwCkwgVkZT IENhY2hlOiAgICAgICAgICAgICAgMzI4LCAgICAgICAgMCwgICAgIDIwNzksICAgIDM2Mjg1LCAx ODE1NTU3OCwgICAgICAgIDAKRElSSEFTSDogICAgICAgICAgICAgICAgIDEwMjQsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApORlNNT1VOVDogICAgICAg ICAgICAgICAgIDYyNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCk5GU05PREU6ICAgICAgICAgICAgICAgICAgNjg4LCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2NhY2hlOiAgICAgICAgICAgICAgICA4 NjQsICAgICAgICAwLCAgICAgICAgMSwgICAgNTAxNzUsIDI3NTc0MjQ3NTIsICAgICAgICAwCnpp b19saW5rX2NhY2hlOiAgICAgICAgICAgIDQ4LCAgICAgICAgMCwgICAgICAgIDAsICAgIDUwMTg0 LCA2NTQ4MTQ2ODAsICAgICAgICAwCnppb19idWZfNTEyOiAgICAgICAgICAgICAgNTEyLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVm XzUxMjogICAgICAgICA1MTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aW9fYnVmXzEwMjQ6ICAgICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8xMDI0OiAgICAg ICAxMDI0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK emlvX2J1Zl8xNTM2OiAgICAgICAgICAgIDE1MzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfMTUzNjogICAgICAgMTUzNiwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMjA0 ODogICAgICAgICAgICAyMDQ4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzIwNDg6ICAgICAgIDIwNDgsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzI1NjA6ICAgICAgICAg ICAgMjU2MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw Cnppb19kYXRhX2J1Zl8yNTYwOiAgICAgICAyNTYwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8zMDcyOiAgICAgICAgICAgIDMwNzIsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9i dWZfMzA3MjogICAgICAgMzA3MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnppb19idWZfMzU4NDogICAgICAgICAgICAzNTg0LCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzM1ODQ6ICAg ICAgIDM1ODQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MAp6aW9fYnVmXzQwOTY6ICAgICAgICAgICAgNDA5NiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl80MDk2OiAgICAgICA0MDk2LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl81 MTIwOiAgICAgICAgICAgIDUxMjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfNTEyMDogICAgICAgNTEyMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfNjE0NDogICAgICAg ICAgICA2MTQ0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKemlvX2RhdGFfYnVmXzYxNDQ6ICAgICAgIDYxNDQsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzcxNjg6ICAgICAgICAgICAgNzE2OCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRh X2J1Zl83MTY4OiAgICAgICA3MTY4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKemlvX2J1Zl84MTkyOiAgICAgICAgICAgIDgxOTIsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfODE5Mjog ICAgICAgODE5MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwCnppb19idWZfMTAyNDA6ICAgICAgICAgIDEwMjQwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzEwMjQwOiAgICAgMTAyNDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVm XzEyMjg4OiAgICAgICAgICAxMjI4OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8xMjI4ODogICAgIDEyMjg4LCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8xNDMzNjogICAg ICAgICAgMTQzMzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAp6aW9fZGF0YV9idWZfMTQzMzY6ICAgICAxNDMzNiwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTYzODQ6ICAgICAgICAgIDE2Mzg0 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2Rh dGFfYnVmXzE2Mzg0OiAgICAgMTYzODQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzIwNDgwOiAgICAgICAgICAyMDQ4MCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8yMDQ4 MDogICAgIDIwNDgwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAKemlvX2J1Zl8yNDU3NjogICAgICAgICAgMjQ1NzYsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfMjQ1NzY6ICAgICAyNDU3 NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19i dWZfMjg2NzI6ICAgICAgICAgIDI4NjcyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzI4NjcyOiAgICAgMjg2NzIsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzMyNzY4OiAg ICAgICAgICAzMjc2OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCnppb19kYXRhX2J1Zl8zMjc2ODogICAgIDMyNzY4LCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8zNjg2NDogICAgICAgICAgMzY4 NjQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9f ZGF0YV9idWZfMzY4NjQ6ICAgICAzNjg2NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwCnppb19idWZfNDA5NjA6ICAgICAgICAgIDQwOTYwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzQw OTYwOiAgICAgNDA5NjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMAp6aW9fYnVmXzQ1MDU2OiAgICAgICAgICA0NTA1NiwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl80NTA1NjogICAgIDQ1 MDU2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlv X2J1Zl80OTE1MjogICAgICAgICAgNDkxNTIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfNDkxNTI6ICAgICA0OTE1MiwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfNTMyNDg6 ICAgICAgICAgIDUzMjQ4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAKemlvX2RhdGFfYnVmXzUzMjQ4OiAgICAgNTMyNDgsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzU3MzQ0OiAgICAgICAgICA1 NzM0NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnpp b19kYXRhX2J1Zl81NzM0NDogICAgIDU3MzQ0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl82MTQ0MDogICAgICAgICAgNjE0NDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZf NjE0NDA6ICAgICA2MTQ0MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwCnppb19idWZfNjU1MzY6ICAgICAgICAgIDY1NTM2LCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzY1NTM2OiAgICAg NjU1MzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6 aW9fYnVmXzY5NjMyOiAgICAgICAgICA2OTYzMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl82OTYzMjogICAgIDY5NjMyLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl83Mzcy ODogICAgICAgICAgNzM3MjgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMAp6aW9fZGF0YV9idWZfNzM3Mjg6ICAgICA3MzcyOCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfNzc4MjQ6ICAgICAgICAg IDc3ODI0LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK emlvX2RhdGFfYnVmXzc3ODI0OiAgICAgNzc4MjQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzgxOTIwOiAgICAgICAgICA4MTkyMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1 Zl84MTkyMDogICAgIDgxOTIwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAKemlvX2J1Zl84NjAxNjogICAgICAgICAgODYwMTYsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfODYwMTY6ICAg ICA4NjAxNiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw Cnppb19idWZfOTAxMTI6ICAgICAgICAgIDkwMTEyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzkwMTEyOiAgICAgOTAxMTIsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzk0 MjA4OiAgICAgICAgICA5NDIwOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAsICAgICAgICAwCnppb19kYXRhX2J1Zl85NDIwODogICAgIDk0MjA4LCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl85ODMwNDogICAgICAg ICAgOTgzMDQsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MAp6aW9fZGF0YV9idWZfOTgzMDQ6ICAgICA5ODMwNCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZfMTAyNDAwOiAgICAgICAgMTAyNDAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFf YnVmXzEwMjQwMDogICAxMDI0MDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMAp6aW9fYnVmXzEwNjQ5NjogICAgICAgIDEwNjQ5NiwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8xMDY0OTY6 ICAgMTA2NDk2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKemlvX2J1Zl8xMTA1OTI6ICAgICAgICAxMTA1OTIsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0YV9idWZfMTEwNTkyOiAgIDExMDU5Miwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19idWZf MTE0Njg4OiAgICAgICAgMTE0Njg4LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzExNDY4ODogICAxMTQ2ODgsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fYnVmXzExODc4NDogICAg ICAgIDExODc4NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwCnppb19kYXRhX2J1Zl8xMTg3ODQ6ICAgMTE4Nzg0LCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2J1Zl8xMjI4ODA6ICAgICAgICAxMjI4ODAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAp6aW9fZGF0 YV9idWZfMTIyODgwOiAgIDEyMjg4MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnppb19idWZfMTI2OTc2OiAgICAgICAgMTI2OTc2LCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemlvX2RhdGFfYnVmXzEyNjk3 NjogICAxMjY5NzYsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMAp6aW9fYnVmXzEzMTA3MjogICAgICAgIDEzMTA3MiwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnppb19kYXRhX2J1Zl8xMzEwNzI6ICAgMTMxMDcy LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKZG11X2J1 Zl9pbXBsX3Q6ICAgICAgICAgICAyMjQsICAgICAgICAwLCAgIDY1NTU2MSwgICA3MDk4NjIsIDE5 MjEwNDE1OCwgICAgICAgIDAKZG5vZGVfdDogICAgICAgICAgICAgICAgICA3ODQsICAgICAgICAw LCAgIDU4MDk4NSwgICA1ODczMDUsIDE2MjQ3NTYxMiwgICAgICAgIDAKYXJjX2J1Zl9oZHJfdDog ICAgICAgICAgICAyMDgsICAgICAgICAwLCAgIDIxMDAzOSwgICAyODEzMjUsICA5OTgyMTI1LCAg ICAgICAgMAphcmNfYnVmX3Q6ICAgICAgICAgICAgICAgICA3MiwgICAgICAgIDAsICAgIDgwMTQ1 LCAgIDEwMzQ1NSwgMzA2ODI0NDIsICAgICAgICAwCnppbF9sd2JfY2FjaGU6ICAgICAgICAgICAg MjAwLCAgICAgICAgMCwgICAgICAgMTQsICAgIDEyMTY1LCAgMTAxODk5OSwgICAgICAgIDAKemZz X3pub2RlX2NhY2hlOiAgICAgICAgICAzNTIsICAgICAgICAwLCAgICA3NzgzMCwgICAgMjQxNzMs IDE3NTA3NDI3NywgICAgICAgIDAKcGlwZTogICAgICAgICAgICAgICAgICAgICA3MjgsICAgICAg ICAwLCAgICAgICA2NSwgICAgIDE0MDAsICAgNjAwMDIyLCAgICAgICAgMApBSU86ICAgICAgICAg ICAgICAgICAgICAgIDIwOCwgICAgICAgIDAsICAgICAgIDE2LCAgICAgIDQ1MiwgICAgICAyMzMs ICAgICAgICAwCkFJT1A6ICAgICAgICAgICAgICAgICAgICAgIDMyLCAgICAgICAgMCwgICAgICAg IDQsICAgICAgMTk4LCAgICAgICAgNCwgICAgICAgIDAKQUlPQ0I6ICAgICAgICAgICAgICAgICAg ICA0ODAsICAgICAgICAwLCAgICAgICAgMCwgICAgICA0NDgsICAzOTU1ODE4LCAgICAgICAgMApB SU9MOiAgICAgICAgICAgICAgICAgICAgIDEyOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwCkFJT0xJTzogICAgICAgICAgICAgICAgICAgMjcyLCAgICAg ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKa3NpZ2luZm86ICAg ICAgICAgICAgICAgICAxMTIsICAgICAgICAwLCAgICAgMTY0NSwgICAgIDE0OTAsICAgNTk2MzM5 LCAgICAgICAgMAppdGltZXI6ICAgICAgICAgICAgICAgICAgIDM0NCwgICAgICAgIDAsICAgICAg ICAyLCAgICAgICAzMSwgICAgICAgIDIsICAgICAgICAwCktOT1RFOiAgICAgICAgICAgICAgICAg ICAgMTI4LCAgICAgICAgMCwgICAgICAgMzEsICAgICAxMTI5LCAxMzY1ODAzNywgICAgICAgIDAK c29ja2V0OiAgICAgICAgICAgICAgICAgICA2ODAsICAgIDI1NjAyLCAgICAgIDE0OSwgICAgIDE1 NDMsICAxMzU1NTAxLCAgICAgICAgMAppcHE6ICAgICAgICAgICAgICAgICAgICAgICA1NiwgICAg ICA4MTksICAgICAgICAwLCAgICAgIDI1MiwgICAgICAgIDMsICAgICAgICAwCnVkcF9pbnBjYjog ICAgICAgICAgICAgICAgMzM2LCAgICAyNTYwOCwgICAgICAgMTksICAgICAgNjYzLCAgIDQ3ODA5 MCwgICAgICAgIDAKdWRwY2I6ICAgICAgICAgICAgICAgICAgICAgMTYsICAgIDI1NzA0LCAgICAg ICAxOSwgICAgIDIzMzMsICAgNDc4MDkwLCAgICAgICAgMAp0Y3BfaW5wY2I6ICAgICAgICAgICAg ICAgIDMzNiwgICAgMjU2MDgsICAgICAgIDczLCAgICAgMTI4MCwgICAzNTcwNTUsICAgICAgICAw CnRjcGNiOiAgICAgICAgICAgICAgICAgICAgODgwLCAgICAyNTYwMCwgICAgICAgNzIsICAgICAg NzcyLCAgIDM1NzA1NSwgICAgICAgIDAKdGNwdHc6ICAgICAgICAgICAgICAgICAgICAgNzIsICAg ICA1MTUwLCAgICAgICAgMSwgICAgIDE3OTksICAgMTA0MTE2LCAgICAgICAgMApzeW5jYWNoZTog ICAgICAgICAgICAgICAgIDE0NCwgICAgMTUzNjYsICAgICAgICAwLCAgICAgIDY1MCwgICAyNzAx NTIsICAgICAgICAwCmhvc3RjYWNoZTogICAgICAgICAgICAgICAgMTM2LCAgICAxNTM3MiwgICAg ICAgMTYsICAgICAgNzEyLCAgICAgMTYwNiwgICAgICAgIDAKdGNwcmVhc3M6ICAgICAgICAgICAg ICAgICAgNDAsICAgICAxNjgwLCAgICAgICAgMCwgICAgIDE2ODAsICAgIDI5MzkzLCAgICAgICAg MApzYWNraG9sZTogICAgICAgICAgICAgICAgICAzMiwgICAgICAgIDAsICAgICAgICAwLCAgICAg MTcxNywgICAgIDUzMzUsICAgICAgICAwCnNjdHBfZXA6ICAgICAgICAgICAgICAgICAxMjcyLCAg ICAyNTYwMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9hc29j OiAgICAgICAgICAgICAgIDIyNDAsICAgIDQwMDAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwLCAgICAgICAgMApzY3RwX2xhZGRyOiAgICAgICAgICAgICAgICA0OCwgICAgODAwNjQsICAg ICAgICAwLCAgICAgIDE0NCwgICAgICAgIDMsICAgICAgICAwCnNjdHBfcmFkZHI6ICAgICAgICAg ICAgICAgNjE2LCAgICA4MDAwNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg IDAKc2N0cF9jaHVuazogICAgICAgICAgICAgICAxMzYsICAgNDAwMDA4LCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX3JlYWRxOiAgICAgICAgICAgICAgIDEwNCwg ICA0MDAwMzIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfc3Ry ZWFtX21zZ19vdXQ6ICAgICAgIDk2LCAgIDQwMDAyNiwgICAgICAgIDAsICAgICAgICAwLCAgICAg ICAgMCwgICAgICAgIDAKc2N0cF9hc2NvbmY6ICAgICAgICAgICAgICAgNDAsICAgNDAwMDA4LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2FzY29uZl9hY2s6ICAg ICAgICAgICA0OCwgICA0MDAwMzIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg ICAwCnJpcGNiOiAgICAgICAgICAgICAgICAgICAgMzM2LCAgICAyNTYwOCwgICAgICAgIDAsICAg ICAgMTEwLCAgICAgICA2MSwgICAgICAgIDAKdW5wY2I6ICAgICAgICAgICAgICAgICAgICAyNDAs ICAgIDI1NjAwLCAgICAgICA1NiwgICAgIDExNzYsICAgNTIwMjkxLCAgICAgICAgMApydGVudHJ5 OiAgICAgICAgICAgICAgICAgIDIwMCwgICAgICAgIDAsICAgICAgICA5LCAgICAgICA0OCwgICAg ICAgIDksICAgICAgICAwCnBmc3JjdHJwbDogICAgICAgICAgICAgICAgMTUyLCAgICAxMDAwMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZydWxlcGw6ICAgICAgICAg ICAgICAgICA5MTIsICAgICAgICAwLCAgICAgICA4MCwgICAgICAgNzIsICAgICAgMTUyLCAgICAg ICAgMApwZnN0YXRlcGw6ICAgICAgICAgICAgICAgIDM5MiwgICAgMTAwMDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmYWx0cXBsOiAgICAgICAgICAgICAgICAgMjQw LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZwb29s YWRkcnBsOiAgICAgICAgICAgICAgODgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwLCAgICAgICAgMApwZnJrdGFibGU6ICAgICAgICAgICAgICAgMTI5NiwgICAgIDEwMDIs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmcmtlbnRyeTogICAgICAg ICAgICAgICAgMjE2LCAgIDEwMDAwOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAKcGZya2VudHJ5MjogICAgICAgICAgICAgICAyMTYsICAgICAgICAwLCAgICAgICAgMCwg ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmZyZW50OiAgICAgICAgICAgICAgICAgICAz MiwgICAgIDUwNTAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmZnJh ZzogICAgICAgICAgICAgICAgICAgIDgwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAg ICAgICAgMCwgICAgICAgIDAKcGZmcmNhY2hlOiAgICAgICAgICAgICAgICAgODAsICAgIDEwMDM1 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmZyY2VudDogICAgICAg ICAgICAgICAgICAyNCwgICAgNTAwMjIsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg ICAgICAwCnBmc3RhdGVzY3J1YjogICAgICAgICAgICAgIDQwLCAgICAgICAgMCwgICAgICAgIDAs ICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZpYWRkcnBsOiAgICAgICAgICAgICAgICAx MjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZm9z cGZlbjogICAgICAgICAgICAgICAgIDExMiwgICAgICAgIDAsICAgICAgNjk2LCAgICAgICAzMCwg ICAgIDEzOTIsICAgICAgICAwCnBmb3NmcDogICAgICAgICAgICAgICAgICAgIDQwLCAgICAgICAg MCwgICAgICA0MDcsICAgICAgIDk3LCAgICAgIDgxNCwgICAgICAgIDAKc2VsZmQ6ICAgICAgICAg ICAgICAgICAgICAgNTYsICAgICAgICAwLCAgICAgMTkyNywgICAgIDIzNTcsIDg1MDI5Nzc1OSwg ICAgICAgIDAKU1dBUE1FVEE6ICAgICAgICAgICAgICAgICAyODgsICAgMTE2NTE5LCAgICAgICAg MSwgICAgICAgMjUsICAgICAgICAxLCAgICAgICAgMAppcDRmbG93OiAgICAgICAgICAgICAgICAg ICA1NiwgICAzOTQyNTQsICAgICAgIDQ5LCAgICAgMjAzMCwgICA3NjQwMDQsICAgICAgICAwCmlw NmZsb3c6ICAgICAgICAgICAgICAgICAgIDgwLCAgIDM5NDI0NSwgICAgICAgIDAsICAgICAgICAw LCAgICAgICAgMCwgICAgICAgIDAKTW91bnRwb2ludHM6ICAgICAgICAgICAgICA3NTIsICAgICAg ICAwLCAgICAgICAyNCwgICAgICAgMzEsICAgICAgIDI2LCAgICAgICAgMApOZXRHcmFwaCBpdGVt czogICAgICAgICAgICA3MiwgICAgIDQxMTgsICAgICAgICAwLCAgICAgICA4NywgICAgICAgIDQs ICAgICAgICAwCk5ldEdyYXBoIGRhdGEgaXRlbXM6ICAgICAgIDcyLCAgICAgIDUyMiwgICAgICAg IDAsICAgICAgNTIyLCA0MDQzMTY3MDQsICAgICAxMjA0Cg== --002354010a9a5bfc4e04a706cfac Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gplikjsc1 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjItUkVMRUFTRSAjMDogU2F0IEZlYiAxOSAwMTow Mjo1NCBFU1QgMjAxMQogICAgcm9vdEB4ZW9uOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMg YW1kNjQKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAK Q1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTU1MjAgIEAgMi4yN0dIeiAoMjI2 Ni43Ny1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4 MTA2YTUgIEZhbWlseSA9IDYgIE1vZGVsID0gMWEgIFN0ZXBwaW5nID0gNQogIEZlYXR1cmVzPTB4 YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJS LFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NF MixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDljZTNiZDxTU0UzLERURVM2NCxNT04sRFNf Q1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLERDQSxTU0U0LjEsU1NFNC4yLFBP UENOVD4KICBBTUQgRmVhdHVyZXM9MHgyODEwMDgwMDxTWVNDQUxMLE5YLFJEVFNDUCxMTT4KICBB TUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKcmVhbCBtZW1v cnkgID0gMTI4ODQ5MDE4ODggKDEyMjg4IE1CKQphdmFpbCBtZW1vcnkgPSAxMjM2ODkyODc2OCAo MTE3OTUgTUIpCkFDUEkgQVBJQyBUYWJsZTogPDAzMTcxMCBBUElDMTYxNz4KRnJlZUJTRC9TTVA6 IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMTYgQ1BVcwpGcmVlQlNEL1NNUDogMiBw YWNrYWdlKHMpIHggNCBjb3JlKHMpIHggMiBTTVQgdGhyZWFkcwogY3B1MCAoQlNQKTogQVBJQyBJ RDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNw dTMgKEFQKTogQVBJQyBJRDogIDMKIGNwdTQgKEFQKTogQVBJQyBJRDogIDQKIGNwdTUgKEFQKTog QVBJQyBJRDogIDUKIGNwdTYgKEFQKTogQVBJQyBJRDogIDYKIGNwdTcgKEFQKTogQVBJQyBJRDog IDcKIGNwdTggKEFQKTogQVBJQyBJRDogMTYKIGNwdTkgKEFQKTogQVBJQyBJRDogMTcKIGNwdTEw IChBUCk6IEFQSUMgSUQ6IDE4CiBjcHUxMSAoQVApOiBBUElDIElEOiAxOQogY3B1MTIgKEFQKTog QVBJQyBJRDogMjAKIGNwdTEzIChBUCk6IEFQSUMgSUQ6IDIxCiBjcHUxNCAoQVApOiBBUElDIElE OiAyMgogY3B1MTUgKEFQKTogQVBJQyBJRDogMjMKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxWZXJzaW9uIDIuMD4gaXJxcyAyNC00NyBvbiBt b3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDwwMzE3MTAgWFNEVDE2MTc+IG9uIG1v dGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFj cGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlv biBvZiAxMDAwMDAsIGJmZjAwMDAwICgzKSBmYWlsZWQKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRp bWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJ IENQVT4gb24gYWNwaTAKQUNQSSBXYXJuaW5nOiBJbmNvcnJlY3QgY2hlY2tzdW0gaW4gdGFibGUg W09FTUJdIC0gMHhBRCwgc2hvdWxkIGJlIDB4QUEgKDIwMTAxMDEzL3RidXRpbHMtMzU0KQpjcHUx OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MzogPEFD UEkgQ1BVPiBvbiBhY3BpMApjcHU0OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTU6IDxBQ1BJIENQ VT4gb24gYWNwaTAKY3B1NjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU3OiA8QUNQSSBDUFU+IG9u IGFjcGkwCmNwdTg6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1OTogPEFDUEkgQ1BVPiBvbiBhY3Bp MApjcHUxMDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxMTogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHUxMjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxMzogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUx NDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxNTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2liMDog PEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDEuMCBvbiBwY2kwCnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMjogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzLjAgb24gcGNpMApwY2k5OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMgpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAg b24gcGNpMApwY2k4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgOC4wIG9uIHBjaTAKcGNpNzogPFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1 OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA5LjAgb24gcGNpMApwY2k2OiA8UENJIGJ1cz4g b24gcGNpYjUKcGNpYjY6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEwLjAgb24gcGNpMApw Y2k1OiA8UENJIGJ1cz4gb24gcGNpYjYKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0 IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxi YXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJv bGxlcj4gYXQgZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVy aXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4wIChubyBkcml2 ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4xIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4yIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4z IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAy Mi40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmlj ZSAyMi41IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRl dmljZSAyMi42IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0 IGRldmljZSAyMi43IChubyBkcml2ZXIgYXR0YWNoZWQpCnVoY2kwOiA8SW50ZWwgODI4MDFKSSAo SUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4YTQwMC0weGE0MWYgaXJxIDE2IGF0 IGRldmljZSAyNi4wIG9uIHBjaTAKdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgy ZjAwCnVzYnVzMDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRD4g b24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNC LUU+IHBvcnQgMHhhNDgwLTB4YTQ5ZiBpcnEgMjEgYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1aGNp MTogW0lUSFJFQURdCnVoY2kxOiBMZWdTdXAgPSAweDJmMDAKdXNidXMxOiA8SW50ZWwgODI4MDFK SSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1FPiBvbiB1aGNpMQp1aGNpMjogPEludGVsIDgy ODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRj4gcG9ydCAweGE4MDAtMHhhODFmIGly cSAxOSBhdCBkZXZpY2UgMjYuMiBvbiBwY2kwCnVoY2kyOiBbSVRIUkVBRF0KdWhjaTI6IExlZ1N1 cCA9IDB4MmYwMAp1c2J1czI6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIg VVNCLUY+IG9uIHVoY2kyCmVoY2kwOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29u dHJvbGxlciBVU0ItQj4gbWVtIDB4ZmJjZjQwMDAtMHhmYmNmNDNmZiBpcnEgMTggYXQgZGV2aWNl IDI2Ljcgb24gcGNpMAplaGNpMDogW0lUSFJFQURdCnVzYnVzMzogRUhDSSB2ZXJzaW9uIDEuMAp1 c2J1czM6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQi1CPiBv biBlaGNpMApwY2liNzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjgu MCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3CnBjaWI4OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpMzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjgKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9u IDcuMS45PiBwb3J0IDB4ZWMwMC0weGVjMWYgbWVtIDB4ZmJlZTAwMDAtMHhmYmVmZmZmZiwweGZi ZWRjMDAwLTB4ZmJlZGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwplbTA6IFVzaW5n IE1TSVggaW50ZXJydXB0cyB3aXRoIDMgdmVjdG9ycwplbTA6IFtJVEhSRUFEXQplbTA6IFtJVEhS RUFEXQplbTA6IFtJVEhSRUFEXQplbTA6IEV0aGVybmV0IGFkZHJlc3M6IHNuaXAKcGNpYjk6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2kyOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQplbTE6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENv bm5lY3Rpb24gNy4xLjk+IHBvcnQgMHhkYzAwLTB4ZGMxZiBtZW0gMHhmYmRlMDAwMC0weGZiZGZm ZmZmLDB4ZmJkZGMwMDAtMHhmYmRkZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCmVt MTogVXNpbmcgTVNJWCBpbnRlcnJ1cHRzIHdpdGggMyB2ZWN0b3JzCmVtMTogW0lUSFJFQURdCmVt MTogW0lUSFJFQURdCmVtMTogW0lUSFJFQURdCmVtMTogRXRoZXJuZXQgYWRkcmVzczogc25pcAp1 aGNpMzogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAw eGE4ODAtMHhhODlmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kzOiBbSVRIUkVB RF0KdWhjaTM6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czQ6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkg VVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kzCnVoY2k0OiA8SW50ZWwgODI4MDFKSSAoSUNI MTApIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4YWMwMC0weGFjMWYgaXJxIDE5IGF0IGRl dmljZSAyOS4xIG9uIHBjaTAKdWhjaTQ6IFtJVEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgyZjAw CnVzYnVzNTogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQj4gb24g dWhjaTQKdWhjaTU6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+ IHBvcnQgMHhiMDAwLTB4YjAxZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNTog W0lUSFJFQURdCnVoY2k1OiBMZWdTdXAgPSAweDJmMDAKdXNidXM2OiA8SW50ZWwgODI4MDFKSSAo SUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpNQplaGNpMTogPEludGVsIDgyODAx SkkgKElDSDEwKSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUE+IG1lbSAweGZiY2Y2MDAwLTB4ZmJj ZjYzZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtJVEhSRUFEXQp1c2J1 czc6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM3OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAy LjAgY29udHJvbGxlciBVU0ItQT4gb24gZWhjaTEKcGNpYjEwOiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTAK dmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhjYzAwLTB4Y2M3ZiBtZW0g MHhmYjAwMDAwMC0weGZiN2ZmZmZmLDB4ZmFmZTAwMDAtMHhmYWZmZmZmZiBpcnEgMTYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kxCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9u IHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmFoY2kwOiA8SW50ZWwgSUNIMTAgQUhDSSBT QVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhiODgwLTB4Yjg4NywweGI4MDAtMHhiODAzLDB4YjQ4MC0w eGI0ODcsMHhiNDAwLTB4YjQwMywweGIwODAtMHhiMDlmIG1lbSAweGZiY2Y4MDAwLTB4ZmJjZjg3 ZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYWhjaTA6IFtJVEhSRUFEXQphaGNpMDog QUhDSSB2MS4yMCB3aXRoIDYgM0dicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBub3Qgc3VwcG9y dGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gw OiBbSVRIUkVBRF0KYWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kw CmFoY2ljaDE6IFtJVEhSRUFEXQphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDIg b24gYWhjaTAKYWhjaWNoMjogW0lUSFJFQURdCmFoY2ljaDM6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgMyBvbiBhaGNpMAphaGNpY2gzOiBbSVRIUkVBRF0KYWhjaWNoNDogPEFIQ0kgY2hhbm5l bD4gYXQgY2hhbm5lbCA0IG9uIGFoY2kwCmFoY2ljaDQ6IFtJVEhSRUFEXQphaGNpY2g1OiA8QUhD SSBjaGFubmVsPiBhdCBjaGFubmVsIDUgb24gYWhjaTAKYWhjaWNoNTogW0lUSFJFQURdCnBjaTA6 IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkK YWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGlt ZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKdWFydDA6IDwxNjU1MCBvciBj b21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKdWFy dDA6IFtGSUxURVJdCnVhcnQxOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDJmOC0weDJm ZiBpcnEgMyBvbiBhY3BpMAp1YXJ0MTogW0ZJTFRFUl0KYWNwaV9ocGV0MDogPEhpZ2ggUHJlY2lz aW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGlt ZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMApxcGkwOiA8 UVBJIHN5c3RlbSBidXM+IG9uIG1vdGhlcmJvYXJkCnBjaWIxMTogPFFQSSBIb3N0LVBDSSBicmlk Z2U+IHBjaWJ1cyAyNTUgb24gcXBpMApwY2kyNTU6IDxQQ0kgYnVzPiBvbiBwY2liMTEKcGNpYjEy OiA8UVBJIEhvc3QtUENJIGJyaWRnZT4gcGNpYnVzIDI1NCBvbiBxcGkwCnBjaTI1NDogPFBDSSBi dXM+IG9uIHBjaWIxMgpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhj N2ZmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2Ew CnNjMDogQ0dBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVy aWMgSVNBIFZHQT4gYXQgcG9ydCAweDNkMC0weDNkYiBpb21lbSAweGI4MDAwLTB4YmZmZmYgb24g aXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAs MHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAg YXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHBjMDog Y2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVy bWFsIFNlbnNvcnM+IG9uIGNwdTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4g b24gY3B1MApjb3JldGVtcDE6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MQpl c3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCnA0dGNj MTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCmNvcmV0ZW1wMjogPENQ VSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUyCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0 ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTIKcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5jeSBUaGVy bWFsIENvbnRyb2w+IG9uIGNwdTIKY29yZXRlbXAzOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNv cnM+IG9uIGNwdTMKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4g b24gY3B1MwpwNHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Mwpj b3JldGVtcDQ6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1NAplc3Q0OiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU0CnA0dGNjNDogPENQVSBG cmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHU0CmNvcmV0ZW1wNTogPENQVSBPbi1EaWUg VGhlcm1hbCBTZW5zb3JzPiBvbiBjcHU1CmVzdDU6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTUKcDR0Y2M1OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRy b2w+IG9uIGNwdTUKY29yZXRlbXA2OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNw dTYKZXN0NjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Ngpw NHRjYzY6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Ngpjb3JldGVtcDc6 IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Nwplc3Q3OiA8RW5oYW5jZWQgU3Bl ZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU3CnA0dGNjNzogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHU3CmNvcmV0ZW1wODogPENQVSBPbi1EaWUgVGhlcm1hbCBT ZW5zb3JzPiBvbiBjcHU4CmVzdDg6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRy b2w+IG9uIGNwdTgKcDR0Y2M4OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNw dTgKY29yZXRlbXA5OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTkKZXN0OTog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1OQpwNHRjYzk6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1OQpjb3JldGVtcDEwOiA8Q1BVIE9u LURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTEwCmVzdDEwOiA8RW5oYW5jZWQgU3BlZWRTdGVw IEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxMApwNHRjYzEwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVy bWFsIENvbnRyb2w+IG9uIGNwdTEwCmNvcmV0ZW1wMTE6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vu c29ycz4gb24gY3B1MTEKZXN0MTE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRy b2w+IG9uIGNwdTExCnA0dGNjMTE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24g Y3B1MTEKY29yZXRlbXAxMjogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxMgpl c3QxMjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTIKcDR0 Y2MxMjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxMgpjb3JldGVtcDEz OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTEzCmVzdDEzOiA8RW5oYW5jZWQg U3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxMwpwNHRjYzEzOiA8Q1BVIEZyZXF1 ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEzCmNvcmV0ZW1wMTQ6IDxDUFUgT24tRGllIFRo ZXJtYWwgU2Vuc29ycz4gb24gY3B1MTQKZXN0MTQ6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTE0CnA0dGNjMTQ6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29u dHJvbD4gb24gY3B1MTQKY29yZXRlbXAxNTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBv biBjcHUxNQplc3QxNTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24g Y3B1MTUKcDR0Y2MxNTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxNQpa RlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDQKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDE1ClRpbWVj b3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdmJveGRydjogZkFzeW5jPTAgb2ZmTWluPTB4 NWU4IG9mZk1heD0weDhlYwp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVz MTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czQ6IDEyTWJw cyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAK dXNidXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czc6IDQ4ME1icHMgSGlnaCBT cGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVI Q0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAK dWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRl bD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1 aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBV SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0 CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwg Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50 ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWdlbjcuMTogPEludGVsPiBhdCB1c2J1czcK dWh1Yjc6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXM3CnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDog PFdEQyBXRDIwMDNGWVlTLTAyVzBCMCAwMS4wMUQwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFk YTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVz KQphZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMDogMTkwNzcyOU1CICgzOTA3MDI5 MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTEgYXQgYWhjaWNoMSBi dXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFdEQyBXRDIwMDNGWVlTLTAyVzBCMCAw MS4wMUQwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTE6IDMwMC4wMDBNQi9zIHRyYW5zZmVy cyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGExOiBDb21tYW5kIFF1ZXVlaW5n IGVuYWJsZWQKYWRhMTogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2 SCA2M1MvVCAxNjM4M0MpClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTMg TGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTUgTGF1bmNo ZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTEgTGF1bmNoZWQhClNN UDogQVAgQ1BVICM3IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTAgTGF1bmNoZWQhClNNUDogQVAg Q1BVICM0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjOSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzUg TGF1bmNoZWQhClNNUDogQVAgQ1BVICM4IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNiBMYXVuY2hl ZCEKU01QOiBBUCBDUFUgIzE0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTIgTGF1bmNoZWQhClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNyB1c2J1czMKUm9vdCBtb3VudCB3YWl0aW5nIGZv cjogdXNidXM3IHVzYnVzMwp1aHViMzogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWh1Yjc6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW43 LjI6IDxBbWVyaWNhbiBNZWdhdHJlbmRzIEluYy4+IGF0IHVzYnVzNwpUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHpmczp6cm9vdAp2Ym94bmV0MDogRXRoZXJuZXQgYWRkcmVzczogMGE6MDA6Mjc6 MDA6MDA6MDAKZW0xOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKZW0xOiBwcm9taXNjdW91cyBt b2RlIGVuYWJsZWQK --002354010a9a5bfc4e04a706cfac-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 1 22:22:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7BF3106566C for ; Fri, 1 Jul 2011 22:22:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 846A58FC1C for ; Fri, 1 Jul 2011 22:22:39 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id 2mLg1h0011c6gX85DmNfF2; Fri, 01 Jul 2011 22:22:39 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.westchester.pa.mail.comcast.net with comcast id 2mNa1h0121t3BNj3jmNbpo; Fri, 01 Jul 2011 22:22:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C8352102C19; Fri, 1 Jul 2011 15:22:32 -0700 (PDT) Date: Fri, 1 Jul 2011 15:22:32 -0700 From: Jeremy Chadwick To: Scott Sipe Message-ID: <20110701222232.GA33935@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: scp: Write Failed: Cannot allocate memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:22:39 -0000 On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote: > I'm running 8.2-RELEASE and am having new problems with scp. When scping > files to a ZFS directory on the FreeBSD server -- most notably large files > -- the transfer frequently dies after just a few seconds. In my last test, I > tried to scp an 800mb file to the FreeBSD system and the transfer died after > 200mb. It completely copied the next 4 times I tried, and then died again on > the next attempt. > > On the client side: > > "Connection to home closed by remote host. > lost connection" > > In /var/log/auth.log: > > Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot allocate > memory > > I've never seen this before and have used scp before to transfer large files > without problems. This computer has been used in production for months and > has a current uptime of 36 days. I have not been able to notice any problems > copying files to the server via samba or netatalk, or any problems in > apache. > > Uname: > > FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 EST > 2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64 > > I've attached my dmesg and output of vmstat -z. > > I have not restarted the sshd daemon or rebooted the computer. > > Am glad to provide any other information or test anything else. > > {snip vmstat -z and dmesg} You didn't provide details about your networking setup (rc.conf, ifconfig -a, etc.). netstat -m would be useful too. Next, please see this thread circa September 2010, titled "Network memory allocation failures": http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708 The user in that thread is using rsync, which relies on scp by default. I believe this problem is similar, if not identical, to yours. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 04:54:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0802D1065672 for ; Sat, 2 Jul 2011 04:54:43 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB50A8FC0A for ; Sat, 2 Jul 2011 04:54:42 +0000 (UTC) Received: by iyb11 with SMTP id 11so4476721iyb.13 for ; Fri, 01 Jul 2011 21:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=+G6jG4Ec2kXK+PJRkTxxoffF7f2pTuB+GllvZY3aPIs=; b=F5YPN0vTTJebl6IJxZyS5uWKlOJuJ6AGQypfFYpYWSIVbZp6BL7Xk/OrREANQHCtfV Tm9Q6PglcQeNEz5d65NL+G68GGWoEoHmkh1ejFHOAzqko2ypZojd/k8NcxTuNa053awc afKwtaLXnECbS8j0i66VsbTheWnFKeNEkCIe8= Received: by 10.42.177.138 with SMTP id bi10mr3659269icb.212.1309582481296; Fri, 01 Jul 2011 21:54:41 -0700 (PDT) Received: from DataIX.net ([99.190.86.179]) by mx.google.com with ESMTPS id hw7sm4090741icc.3.2011.07.01.21.54.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 21:54:39 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p624sab2082274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 00:54:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p624sZ48082273; Sat, 2 Jul 2011 00:54:35 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 2 Jul 2011 00:54:35 -0400 From: jhell To: Jeremy Chadwick Message-ID: <20110702045435.GA81502@DataIX.net> References: <20110701222232.GA33935@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20110701222232.GA33935@icarus.home.lan> Cc: freebsd-stable@freebsd.org, Scott Sipe Subject: Re: scp: Write Failed: Cannot allocate memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 04:54:43 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote: > On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote: > > I'm running 8.2-RELEASE and am having new problems with scp. When scping > > files to a ZFS directory on the FreeBSD server -- most notably large fi= les > > -- the transfer frequently dies after just a few seconds. In my last te= st, I > > tried to scp an 800mb file to the FreeBSD system and the transfer died = after > > 200mb. It completely copied the next 4 times I tried, and then died aga= in on > > the next attempt. > >=20 > > On the client side: > >=20 > > "Connection to home closed by remote host. > > lost connection" > >=20 > > In /var/log/auth.log: > >=20 > > Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot alloca= te > > memory > >=20 > > I've never seen this before and have used scp before to transfer large = files > > without problems. This computer has been used in production for months = and > > has a current uptime of 36 days. I have not been able to notice any pro= blems > > copying files to the server via samba or netatalk, or any problems in > > apache. > >=20 > > Uname: > >=20 > > FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 EST > > 2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64 > >=20 > > I've attached my dmesg and output of vmstat -z. > >=20 > > I have not restarted the sshd daemon or rebooted the computer. > >=20 > > Am glad to provide any other information or test anything else. > > > > {snip vmstat -z and dmesg} >=20 > You didn't provide details about your networking setup (rc.conf, > ifconfig -a, etc.). netstat -m would be useful too. >=20 > Next, please see this thread circa September 2010, titled "Network > memory allocation failures": >=20 > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.h= tml#58708 >=20 > The user in that thread is using rsync, which relies on scp by default. > I believe this problem is similar, if not identical, to yours. >=20 Please also provide your output of ( /usr/bin/limits -a ) for the server end and the client. I am not quite sure I agree with the need for ifconfig -a but some information about the networking driver your using for the interface would be helpful, uptime of the boxes. And configuration of the pool. e.g. ( zpool status -a ;zfs get all ) You should probably prop this information up somewhere so you can reference by URL whenever needed. rsync(1) does not rely on scp(1) whatsoever but rsync(1) can be made to use ssh(1) instead of rsh(1) and I believe that is what Jeremy is stating here but correct me if I am wrong. It does use ssh(1) by default. Its a possiblity as well that if using tmpfs(5) or mdmfs(8) for /tmp type filesystems that rsync(1) may be just filling up your temp ram area and causing the connection abort which would be expected. ( df -h ) would help here. --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJODqSKAAoJEJBXh4mJ2FR+nkAH/0WzDyYUIuxJrKQI0j7IWrnY QFfPH2pHns+ppADGDrqn1nCcDz7kVVVNajCHgWBdRwheCGaeXTArUKJ0jYcSZPsv tHsfjs5pYT9G0wbh3mpoqniEvE70m+UHOY0jRRQLHevwsOKbc5Z97hGIy/9d4ljJ id4762JFS1tpwivwzHrmkMyLdnAX1szvcSNGhWpHe4oyYx+WLg8gQrEBnZqe1EdC qkglrNshkS1MamiSn6BwdapibBSH+hzQ0bwMvF9hmn6fSAPeWuLN6sRCrqiUSjWU +mbBmmwQUtCpWmUA3aGhZWukv9wKDXZ4UPKnprFduto/OIXcz8k10/ir2V4tb9E= =3rQd -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 05:48:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3899106566C for ; Sat, 2 Jul 2011 05:48:01 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68C9A8FC0C for ; Sat, 2 Jul 2011 05:48:01 +0000 (UTC) Received: by gwb15 with SMTP id 15so1963344gwb.13 for ; Fri, 01 Jul 2011 22:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4sh77j9gCoRgH3T+ifJAQrTxQifI61ifIyMrwgaqKDo=; b=oOB9aRMFw+/7sD2LdngOYiBWPPD7yXuIvGp0zNhu3jKfZxfBIO2kbJeuKjs7rC3/u0 UK+4qj+xvH5/82MCfc/p8FVew/OZu2lkcTcjg7/8yzt65qlEZ7zl34/iSIvTca7c1TOF nIcFQvhlnO767Lhei+s+MVZIKPFKO6Xw3vSPc= MIME-Version: 1.0 Received: by 10.150.62.1 with SMTP id k1mr3842732yba.196.1309583994035; Fri, 01 Jul 2011 22:19:54 -0700 (PDT) Received: by 10.150.220.20 with HTTP; Fri, 1 Jul 2011 22:19:53 -0700 (PDT) Date: Fri, 1 Jul 2011 19:19:53 -1000 Message-ID: From: Kevin Oberman To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: libarchive, lzma, and xz interaction X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 05:48:01 -0000 I'm trying to understand the problems I am having on some systems regarding libarchive, lzma, and xz. I have an 8-Stable system updated yesterday. As far as I can tell, libarchive does include the lzma stuff from libzma. At least I see the references. But several ports seem to still pull in xz-5.0.1 and link to it. This has a wonderful potential to cause library symbol conflicts. I get: /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_memusage@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_code@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_end@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder@XZ_5.0' ldd shows libarchive linked against liblzma.so.5 and an objdump of the dynamic symbols from liblzma.so.5 shows the "undefined symbols" defined with the XZ_5.0 version, so I am mystified. It looks o me like it is there. Is confusion with xz-5.0.1 causing this? Should get rid of it? Even so, I don't understand why the loader is claiming that these symbols are undefined when they seem to be defined as far as I can tell. 0000000000007c60 g DF .text 0000000000000084 XZ_5.0 lzma_stream_encoder Any clues to what i happening would be greatly appreciated! -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 05:49:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70E0D106566B for ; Sat, 2 Jul 2011 05:49:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1C24C8FC16 for ; Sat, 2 Jul 2011 05:49:45 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id 2toK1h0011ZXKqc58tpmZJ; Sat, 02 Jul 2011 05:49:46 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.westchester.pa.mail.comcast.net with comcast id 2tpl1h0031t3BNj3htplBB; Sat, 02 Jul 2011 05:49:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A6469102C19; Fri, 1 Jul 2011 22:49:43 -0700 (PDT) Date: Fri, 1 Jul 2011 22:49:43 -0700 From: Jeremy Chadwick To: jhell Message-ID: <20110702054943.GA40703@icarus.home.lan> References: <20110701222232.GA33935@icarus.home.lan> <20110702045435.GA81502@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110702045435.GA81502@DataIX.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Scott Sipe Subject: Re: scp: Write Failed: Cannot allocate memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 05:49:46 -0000 On Sat, Jul 02, 2011 at 12:54:35AM -0400, jhell wrote: > On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote: > > The user in that thread is using rsync, which relies on scp by default. > > I believe this problem is similar, if not identical, to yours. > > rsync(1) does not rely on scp(1) whatsoever but rsync(1) can be made to > use ssh(1) instead of rsh(1) and I believe that is what Jeremy is > stating here but correct me if I am wrong. It does use ssh(1) by > default. My apologies; yep that is what I meant. It uses ssh(1) pipe for I/O transport. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 06:01:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928B5106566C for ; Sat, 2 Jul 2011 06:01:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 54B678FC08 for ; Sat, 2 Jul 2011 06:01:08 +0000 (UTC) Received: by ywf7 with SMTP id 7so1988033ywf.13 for ; Fri, 01 Jul 2011 23:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=8ukf+xjVf2doJE31nK2+BkseUG6u6I1JEcIiHhlGZ2Q=; b=qLa1LpjOExJDRMJpHvgEpRHNJbdnacsH7WXo5ZVRCV8RnOabpGU3N83nfzQ/nLdRRd qkCWqaZsPSJ7a7GnjD1ewBU/jYQlhZYq5vugpTGyIaNvG1HIFhqJWx+x3tb3/SUPcn2X 60ScpjfI8x9GfyuBq5IiPaUguPseBoWPRldcc= MIME-Version: 1.0 Received: by 10.150.75.4 with SMTP id x4mr3819167yba.310.1309586467478; Fri, 01 Jul 2011 23:01:07 -0700 (PDT) Received: by 10.150.220.20 with HTTP; Fri, 1 Jul 2011 23:01:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jul 2011 20:01:07 -1000 Message-ID: From: Kevin Oberman To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: libarchive, lzma, and xz interaction X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 06:01:08 -0000 On Fri, Jul 1, 2011 at 7:19 PM, Kevin Oberman wrote: > I'm trying to understand the problems I am having on some systems > regarding libarchive, lzma, and xz. > I have an 8-Stable system updated yesterday. As far as I can tell, > libarchive does include the lzma stuff > from libzma. At least I see the references. But several ports seem to > still pull in xz-5.0.1 and link to it. > This has a wonderful potential to cause library symbol conflicts. I get: > /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder@XZ_5.= 0' > /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder@XZ_5.0= ' > /usr/lib/libarchive.so: undefined reference to `lzma_memusage@XZ_5.0' > /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder@XZ_5.= 0' > /usr/lib/libarchive.so: undefined reference to `lzma_code@XZ_5.0' > /usr/lib/libarchive.so: undefined reference to `lzma_end@XZ_5.0' > /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset@XZ_5.0' > /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder@XZ_5.0= ' > > ldd shows libarchive linked against liblzma.so.5 and an objdump of the > dynamic symbols from liblzma.so.5 > shows the "undefined symbols" defined with the XZ_5.0 version, so I am > mystified. It looks o me like it is > there. Is confusion with xz-5.0.1 causing this? Should get rid of it? > Even so, I don't understand why the > loader is claiming that these symbols are undefined when they seem to > be defined as far as I can tell. > 0000000000007c60 g =A0 =A0DF .text =A00000000000000084 =A0XZ_5.0 > lzma_stream_encoder > > Any clues to what i happening would be greatly appreciated! Replying to myself, I re-built all programs that depended on xz and then deleted the port. Now everything works fine. I still don't completely understand what I was seeing, but it is working, now. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 06:04:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05BB106566B for ; Sat, 2 Jul 2011 06:04:21 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id 36F748FC0A for ; Sat, 2 Jul 2011 06:04:20 +0000 (UTC) Received: from faust (cable-94-189-176-48.dynamic.sbb.rs [94.189.176.48]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id p625OqvL009010 for ; Sat, 2 Jul 2011 07:24:52 +0200 Received: by faust (Postfix, from userid 1001) id BC39717053; Sat, 2 Jul 2011 07:24:53 +0200 (CEST) Date: Sat, 2 Jul 2011 07:24:53 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20110702052453.GA1182@faust> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 Subject: dell latitude 13 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 06:04:21 -0000 Dear folks! I see threads on the laptop subject, some forums also, but no clue for cheap lapper with freebsd compatibility. There is a chance to get mentioned box for about 450 euros, without OS and with specs like this: Intel Core#2 Duo SU7300 1.3GHz, 3MB L2 cache, FSB 800MHz Intel GS45 Express + Intel ICH9M-Enhanced (chipset) Intel GMA 4500 MHD (graphics) 13.3" 1366x768 HD WLED Anti-Glare (screen) Intel Link 5100 IEEE 802.11a/b/g/n WiFi (wifi) ExpressCard 6-cell Li-lon battery FreeDos (OS) I'm aware of something called "optimus" to optimize graphics and inability to know prior getting laptop home. Someone already has this laptop? To me it looks like it should work out of the box. I tend to like box to be cold and silent. If you have idea or better laptop in the price range, I'd be eager to know. Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 07:11:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B769D106566B for ; Sat, 2 Jul 2011 07:11:15 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 957888FC17 for ; Sat, 2 Jul 2011 07:11:15 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p627BEhT021490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Jul 2011 00:11:14 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p627BE2A021489; Sat, 2 Jul 2011 00:11:14 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA03815; Sat, 2 Jul 11 00:06:34 PDT Date: Sat, 02 Jul 2011 00:06:36 -0700 From: perryh@pluto.rain.com To: christian.baer@uni-dortmund.de, tevans.uk@googlemail.com Message-Id: <4e0ec37c.K0c+wL6t2YIr09OD%perryh@pluto.rain.com> References: <52F39CE0-EEC7-4180-8186-BF8696AF279D@lassitu.de> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Crashes with Promise controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 07:11:15 -0000 Tom Evans wrote: > On Thu, Jun 30, 2011 at 6:31 PM, Christian Baer > wrote: > > A serial console is easy enough to set up on a Sun for example, but in > > this case, I am running a simple AthlonXP, which has nothing for that > > sort of help. I would need a special card for that and those cose quite > > a bit. :-( > > Not that special - you just need a serial port on two computers. If > your computers don't have serial ports, USB serial adapters work fine, While it should work up to a point, a USB serial port is not the ideal choice for a console port (on the machine that is crashing), because it requires the USB stack to be working. If that machine has no built-in serial port, but has an available PCI slot, adding a PCI serial port is likely the best choice. > and are cheap, as are (single port) PCI serial cards. > > Alternatively, if both computers have firewire ports, you can use > dcons, and all you need is a cable. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 07:27:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5ADF1065672; Sat, 2 Jul 2011 07:27:43 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 73C3E8FC0C; Sat, 2 Jul 2011 07:27:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QcucA-0005ro-An>; Sat, 02 Jul 2011 09:27:42 +0200 Received: from e178019114.adsl.alicedsl.de ([85.178.19.114] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QcucA-00036c-82>; Sat, 02 Jul 2011 09:27:42 +0200 Message-ID: <4E0EC86E.9050608@zedat.fu-berlin.de> Date: Sat, 02 Jul 2011 09:27:42 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.19.114 Cc: Subject: devel/subversion: svn: Couldn't perform atomic initialization X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 07:27:43 -0000 Hello. Since two days now I realize on several recently ports-updated servers a failure of the subversion server running on those servers. Sneaking around the internet I found several issues exactly targeting this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed in sqlite-3.7.7.2. At this very moment, our subversion servers in question has all recently been updated and it seems, they all fail the same way. Does anyone also realize this behaviour shown below when commiting? Is there a workaround? Any help or hint is appreciated. Thanks in advance, Oliver Transmitting file data .svn: Commit failed (details follow): svn: Couldn't perform atomic initialization svn: database schema has changed svn: Your commit message was left in a temporary file: From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 08:08:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50B051065672 for ; Sat, 2 Jul 2011 08:08:03 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1002C8FC19 for ; Sat, 2 Jul 2011 08:08:02 +0000 (UTC) Received: by yxl31 with SMTP id 31so1547871yxl.13 for ; Sat, 02 Jul 2011 01:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lQyx8eUmI4qKdO+jCCu4ubafwGNzjmxrWHJWV8z6L2I=; b=YMYbHVDf0wMX+MTwRsSh+xCfE+8LTDHbplv5E74anUnPrrMnaYXXGP2wfLOh2DaNxN p/UzNecQT1JHx3urfsm4UHg0u28gjIWNcE/QKVTJ8hb5MW5KqMqbjIzR6+PFMgkHB0Jm T5ES+I2HQiLaD/JEfwabiYc0q3lNINJdXIhv4= MIME-Version: 1.0 Received: by 10.150.69.3 with SMTP id r3mr3594014yba.139.1309594081791; Sat, 02 Jul 2011 01:08:01 -0700 (PDT) Received: by 10.150.220.20 with HTTP; Sat, 2 Jul 2011 01:08:01 -0700 (PDT) Received: by 10.150.220.20 with HTTP; Sat, 2 Jul 2011 01:08:01 -0700 (PDT) In-Reply-To: <20110702052453.GA1182@faust> References: <20110702052453.GA1182@faust> Date: Fri, 1 Jul 2011 22:08:01 -1000 Message-ID: From: Kevin Oberman To: Zoran Kolic Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: dell latitude 13 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:08:03 -0000 While NVIDIA provides a FreeBSD driver for their stand-alone video, Optimus is not supported and NVIDIA has stated that they have no plans to support it for Linux or BSD. If you Google "FreeBSD NVIDIA optimus", you will find that not only is it useless other than for Windows, but that it interferes with the main graphics system, usually Intel 3000 which is actually a part of the Sandy Bridge CPU. Since the Intel chip is also still unsupported by FreeBSD, you will be limited to VEDA support which is very limited. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com On Jul 1, 2011 8:04 PM, "Zoran Kolic" wrote: > Dear folks! > I see threads on the laptop subject, some forums also, > but no clue for cheap lapper with freebsd compatibility. > There is a chance to get mentioned box for about 450 > euros, without OS and with specs like this: > > Intel Core#2 Duo SU7300 1.3GHz, 3MB L2 cache, FSB 800MHz > Intel GS45 Express + Intel ICH9M-Enhanced (chipset) > Intel GMA 4500 MHD (graphics) > 13.3" 1366x768 HD WLED Anti-Glare (screen) > Intel Link 5100 IEEE 802.11a/b/g/n WiFi (wifi) > ExpressCard > 6-cell Li-lon battery > FreeDos (OS) > > I'm aware of something called "optimus" to optimize graphics > and inability to know prior getting laptop home. Someone > already has this laptop? To me it looks like it should work > out of the box. > I tend to like box to be cold and silent. If you have idea > or better laptop in the price range, I'd be eager to know. > Best regards all > > Zoran > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 08:15:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F39A0106564A for ; Sat, 2 Jul 2011 08:15:57 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id AAEDA8FC0C for ; Sat, 2 Jul 2011 08:15:57 +0000 (UTC) Received: by qyk30 with SMTP id 30so321441qyk.13 for ; Sat, 02 Jul 2011 01:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7gwmvtjFAYnWZidJOtGas/gwiQ/5bLhSr1PjSjze/+0=; b=mJAFmg6PZayailexim/N9jWiE5NF4/TPCo4BBagaIwWli8roEQPFVcclX0mZZW6vdK PXtFLL/3sNcvEESvYLx9l04SdO9J15zrrwSq8H6hbTY7qq0oYc2RHXFHizzMPLBQeqF4 Y6ggdqOy+vaicxOXUbWZW3f+cGr6PhE4vJKIY= MIME-Version: 1.0 Received: by 10.224.194.70 with SMTP id dx6mr3309884qab.309.1309592780552; Sat, 02 Jul 2011 00:46:20 -0700 (PDT) Received: by 10.224.47.148 with HTTP; Sat, 2 Jul 2011 00:46:20 -0700 (PDT) In-Reply-To: <20110702052453.GA1182@faust> References: <20110702052453.GA1182@faust> Date: Sat, 2 Jul 2011 03:46:20 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: dell latitude 13 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:15:58 -0000 On Sat, Jul 2, 2011 at 1:24 AM, Zoran Kolic wrote: > Dear folks! > I see threads on the laptop subject, some forums also, > but no clue for cheap lapper with freebsd compatibility. > There is a chance to get mentioned box for about 450 > euros, without OS and with specs like this: > > Intel Core#2 Duo SU7300 1.3GHz, 3MB L2 cache, FSB 800MHz > Intel GS45 Express + Intel ICH9M-Enhanced (chipset) > Intel GMA 4500 MHD (graphics) > 13.3" 1366x768 HD WLED Anti-Glare (screen) > Intel Link 5100 IEEE 802.11a/b/g/n WiFi (wifi) > ExpressCard > 6-cell Li-lon battery > FreeDos (OS) > > I'm aware of something called "optimus" to optimize graphics > and inability to know prior getting laptop home. Someone > already has this laptop? To me it looks like it should work > out of the box. > I tend to like box to be cold and silent. If you have idea > or better laptop in the price range, I'd be eager to know. > Best regards all > > Zoran > > For laptops you may check the following site : http://laptop.bsdgroup.de/freebsd/ Also check FreeBSD Hardware lists such as ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.2-RELEASE/HARDWARE.HTM ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/8.2-RELEASE/HARDWARE.HTM for hardware compatibility issues , for example , search Intel GMA 4500 MHD (graphics) , and other chips . It is NOT possible to know in advance without any prior knowledge whether a computer is working with FreeDOS will work with FreeBSD because these are very different systems . Therefore my idea is to avoid FreeDOS loaded computers if it is to be used for FreeBSD or Linux . The producer/seller can install FreeBSD or Linux without cost ( if the computer is NOT a DOS computer , i.e. , FreeBSD ( Unix ) , Linux can work on it ) . Over the years , always my suggestion to my friends is to select at least a computer having Linux installed . If there is Linux on it and it is working it is very likely that it will work with FreeBSD . If you can find a laptop as FreeBSD is installed , it is much better than any other ones . Another way is to test the computer for FreeBSD is to start it with a FreeBSD LiveCD ( This will not show the FreeBSD can be installed and run successfully . Over time , some programs may crash due to missing circuit parts because such parts are NOT included into the circuits because they are NOT necessary for DOS or its children . With a few run , this point can not be understood without applying test programs ( which I do NOT know any such program name ) . Such a feature may turn your computer unusable for you with FreeBSD or Linux over time when it occurs under a required program . ) . As a summary , to such Live CD checks , do NOT rely on much , actually ignore such pseudo-tests . For other BSD related GUI Live CD distributions , you may check the following site : http://www.livebsd.org/ Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 10:01:32 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194A01065670 for ; Sat, 2 Jul 2011 10:01:32 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB2688FC0A for ; Sat, 2 Jul 2011 10:01:31 +0000 (UTC) Received: by pzk27 with SMTP id 27so1385157pzk.13 for ; Sat, 02 Jul 2011 03:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B4BH6wC8NtzuFVYuZCh5j58IVAVA5vSDz2R/7daUYZI=; b=FvrJrcbIDfY6DUEtK/s7kUd5BxJY4ORahWW7jF+GueRHQqbws7QkS9U02b0ZU31IFz VX1tJopWc2Ye3ZgbYj/eNirMfKHlbYcVpcYNTxt/qthOLKt95eh1aM+yrOIT/LLdjQGG h1PrI6u9HQL4khDOhLjZoEZdpZBc3/4Ys8vRM= MIME-Version: 1.0 Received: by 10.68.25.201 with SMTP id e9mr5106289pbg.22.1309599129166; Sat, 02 Jul 2011 02:32:09 -0700 (PDT) Received: by 10.68.64.104 with HTTP; Sat, 2 Jul 2011 02:32:09 -0700 (PDT) Date: Sat, 2 Jul 2011 09:32:09 +0000 Message-ID: From: "b. f." To: Kevin Oberman , freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: libarchive, lzma, and xz interaction X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 10:01:32 -0000 > On Fri, Jul 1, 2011 at 7:19 PM, Kevin Oberman wrot= e: > > I'm trying to understand the problems I am having on some systems > > regarding libarchive, lzma, and xz. > > I have an 8-Stable system updated yesterday. As far as I can tell, > > libarchive does include the lzma stuff > > from libzma. At least I see the references. But several ports seem to > > still pull in xz-5.0.1 and link to it. > > This has a wonderful potential to cause library symbol conflicts. I get= : > > /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder at = XZ_5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder at X= Z_5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_memusage at XZ_5.0= ' > > /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder at = XZ_5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_code at XZ_5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_end at XZ_5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset at XZ_= 5.0' > > /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder at X= Z_5.0' > > > > ldd shows libarchive linked against liblzma.so.5 and an objdump of the > > dynamic symbols from liblzma.so.5 > > shows the "undefined symbols" defined with the XZ_5.0 version, so I am > > mystified. It looks o me like it is > > there. Is confusion with xz-5.0.1 causing this? Should get rid of it? > > Even so, I don't understand why the > > loader is claiming that these symbols are undefined when they seem to > > be defined as far as I can tell. > > 0000000000007c60 g =C2=A0 =C2=A0DF .text =C2=A00000000000000084 =C2=A0X= Z_5.0 > > lzma_stream_encoder > > > > Any clues to what i happening would be greatly appreciated! Nothing mysterious here: src/lib/libarchive/archive_write_set_compression_xz.c uses some code from the base system /usr/lib/liblzma.so shared library, from src/lib/liblzma, which is derived from the base system xz 5.0.1, in src/contrib/xz. Hence the symbols are present, with the symbol versions that you noted, but undefined in libarchive, because it is obtaining them from liblzma at run-time. It nudges rtld(1) to do this in the usual way, via it's DT_NEEDED tag for that library: objdump -x /usr/lib/libarchive.so | egrep 'NEEDED.*lzma' > Replying to myself, I re-built all programs that depended on xz and > then deleted the port. Now everything works fine. I still don't > completely understand what I was seeing, but it is working, now. Perhaps you recently updated your base system, but were using old ports or packages? With up-to-date ports and a recent version of 8-stable you should not have been able to build the archivers/xz port, even if other ports mistakenly tried to drag it in, because of the following lines in the ports/archivers/xz Makefile: .if ${OSVERSION} >=3D 900012 || (${OSVERSION} < 900000 && ${OSVERSION} >=3D= 800505) IGNORE=3D is already in the base system .endif Of course, you could have overridden this, by setting NO_IGNORE. b. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 14:16:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05AD11065670 for ; Sat, 2 Jul 2011 14:16:12 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF9B8FC1B for ; Sat, 2 Jul 2011 14:16:11 +0000 (UTC) Received: from faust (cable-188-2-18-77.dynamic.sbb.rs [188.2.18.77]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id p62EG9B8005860 for ; Sat, 2 Jul 2011 16:16:09 +0200 Received: by faust (Postfix, from userid 1001) id 5C61F1701D; Sat, 2 Jul 2011 16:16:04 +0200 (CEST) Date: Sat, 2 Jul 2011 16:16:04 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20110702141604.GA1056@faust> References: <20110702120041.D87B81065825@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110702120041.D87B81065825@hub.freebsd.org> X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.6 Subject: Re: dell latitude 13 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 14:16:12 -0000 Thanks for answering my question. > Since the Intel chip is also still unsupported by FreeBSD, you will be > limited to VEDA support which is very limited. I found that dell sells ubuntu on mentioned laptop in some parts of the globe. Further, my old laptop (HP nx9020) has intel chip and works under intel driver. I need simple 2d, no frills. Does newer chip run for plain graphics at all? No acceleration? Fine. I don't use it neither on my NVIDIA GeForce 6200 card with "nv" driver. > For laptops you may check the following site : > http://laptop.bsdgroup.de/freebsd/ Old and no newer machines on the site. > Also check FreeBSD Hardware lists such as > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.2-RELEASE/HARDWARE.HTM Intel 5100 wifi should work with "device iwn5000fw" or "5150"? > It is NOT possible to know in advance without any prior knowledge whether a > computer is working with FreeDOS will work with FreeBSD because these are > very different systems . It is sold with freedos to be cheap enough. I appreciate that. > The producer/seller can install FreeBSD or Linux without cost Not where I live. When I bought my previous laptop, live cd was the guide if it worked at all. It is a matter of "buy it as it is" now. More, no cd on latitude 13, which is fine, since it keeps it at 3 lb. My two fears are acpi and graphics 4500mhd. I found links that show 4500 supported. http://freebsd.1045724.n5.nabble.com/subnotebooks-once-again-td4197868.html If the list thinks I should wait, it is a metter of adding the code as on this link: http://forums.freebsd.org/archive/index.php/t-21852.html Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 15:49:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4BE3106564A; Sat, 2 Jul 2011 15:49:11 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4F88FC0C; Sat, 2 Jul 2011 15:49:10 +0000 (UTC) Received: by fxe6 with SMTP id 6so3352135fxe.17 for ; Sat, 02 Jul 2011 08:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=13VlCpn1fR+pbQ4Qqgh+RYI+OHfUKnMbEe6bDKLDu2Q=; b=Y7O0ad+UWxmDEGxAOQm7T050GlYOmeBH5DTp5PXxJFvBX07ku3nHR23QeKrALtY+ew FaM/mBEVmYNd0FUOr7P+pgsqOp/IUktrGQp05naC630A/Qh5xD6kBmpibn8rxSqa0Ix1 1nLxOHiiU3orktqdPgp/J/vuAE+T+zrdYDs8Y= Received: by 10.223.78.143 with SMTP id l15mr3330574fak.106.1309621749953; Sat, 02 Jul 2011 08:49:09 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id l9sm53486fal.19.2011.07.02.08.49.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 08:49:08 -0700 (PDT) From: Mikolaj Golub To: Timothy Smith References: X-Comment-To: Timothy Smith Sender: Mikolaj Golub Date: Sat, 02 Jul 2011 18:49:05 +0300 In-Reply-To: (Timothy Smith's message of "Thu, 30 Jun 2011 20:02:19 -0700") Message-ID: <8639ioadji.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: HAST + ZFS: no action on drive failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 15:49:12 -0000 On Thu, 30 Jun 2011 20:02:19 -0700 Timothy Smith wrote: TS> First posting here, hopefully I'm doing it right =) TS> I also posted this to the FreeBSD forum, but I know some hast folks monitor TS> this list regularly and not so much there, so... TS> Basically, I'm testing failure scenarios with HAST/ZFS. I got two nodes, TS> scripted up a bunch of checks and failover actions between the nodes. TS> Looking good so far, though more complex that I expected. It would be cool TS> to post it somewher to get some pointers/critiques, but that's another TS> thing. TS> Anyway, now I'm just seeing what happens when a drive fails on primary node. TS> Oddly/sadly, NOTHING! TS> Hast just keeps on a ticking, and doesn't change the state of the failed TS> drive, so the zpool has no clue the drive is offline. The TS> /dev/hast/ remains. The hastd does log some errors to the system TS> log like this, but nothing more. TS> messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Unable to TS> flush activemap to disk: Device not configured. TS> messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Local request TS> failed (Device not configured): WRITE(4736512, 512). Although the request to local drive failed it succeeded on remote node, so data was not lost, it was considered as successful, and no error was returned to ZFS. TS> So, I guess the question is, "Do I have to script a cronjob to check for TS> these kinds of errors and then change the hast resource to 'init' or TS> something to handle this?" Or is there some kind of hastd config setting TS> that I need to set? What's the SOP for this? Currently the only way to know is monitoring logs. It is not difficult to hook event for these errors in the HAST code (like it is done for connect/disconnect, syncstart/done etc) so one could script what to do on an error occurrence but I am not sure it is a good idea -- the errors may be generated with high rate. TS> As something related too, when the zpool in FreeBSD does finally notice that TS> the drive is missing because I have manually changed the hast resource to TS> INIT (so the /dev/hast/ is gone), my zpool (raidz2) hot spare doesn't TS> engage, even with "autoreplace=on". The zpool status of the degraded pool TS> seems to indicate that I should manually replace the failed drive. If that's TS> the case, it's not really a "hot spare". Does this mean the "FMA Agent" TS> referred to in the ZFS manual is not implemented in FreeBSD? TS> thanks! TS> _______________________________________________ TS> freebsd-stable@freebsd.org mailing list TS> http://lists.freebsd.org/mailman/listinfo/freebsd-stable TS> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 19:06:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267841065673 for ; Sat, 2 Jul 2011 19:06:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBCB78FC1D for ; Sat, 2 Jul 2011 19:06:44 +0000 (UTC) Received: by gyf3 with SMTP id 3so2110201gyf.13 for ; Sat, 02 Jul 2011 12:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WIRwp/u0xT6VTPZ2akTUqrHHbspjTvaZonhKn32A0AM=; b=OcFLY2Fth35QFiaFUyeKMOpBW0/gD1rkV2P2mKLqQ3GjJkO/WydPQ+eVi4bXp6C21h oXmZL/2SaVEAO/ukeQJkXP964XUVgqFTxmJCQf+7nP6TA7nIxPAB/Y+Kjf5eFZNoZahx 8de3eBfvXfHDQmAY9R+c/ruOtIg5zndPxn3XM= MIME-Version: 1.0 Received: by 10.150.171.15 with SMTP id t15mr1692118ybe.424.1309633603943; Sat, 02 Jul 2011 12:06:43 -0700 (PDT) Received: by 10.150.220.20 with HTTP; Sat, 2 Jul 2011 12:06:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Jul 2011 09:06:43 -1000 Message-ID: From: Kevin Oberman To: bf1783@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: libarchive, lzma, and xz interaction X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 19:06:45 -0000 On Fri, Jul 1, 2011 at 11:32 PM, b. f. wrote: >> On Fri, Jul 1, 2011 at 7:19 PM, Kevin Oberman wro= te: >> > I'm trying to understand the problems I am having on some systems >> > regarding libarchive, lzma, and xz. >> > I have an 8-Stable system updated yesterday. As far as I can tell, >> > libarchive does include the lzma stuff >> > from libzma. At least I see the references. But several ports seem to >> > still pull in xz-5.0.1 and link to it. >> > This has a wonderful potential to cause library symbol conflicts. I ge= t: >> > /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder at= XZ_5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder at = XZ_5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_memusage at XZ_5.= 0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder at= XZ_5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_code at XZ_5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_end at XZ_5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset at XZ= _5.0' >> > /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder at = XZ_5.0' >> > >> > ldd shows libarchive linked against liblzma.so.5 and an objdump of the >> > dynamic symbols from liblzma.so.5 >> > shows the "undefined symbols" defined with the XZ_5.0 version, so I am >> > mystified. It looks o me like it is >> > there. Is confusion with xz-5.0.1 causing this? Should get rid of it? >> > Even so, I don't understand why the >> > loader is claiming that these symbols are undefined when they seem to >> > be defined as far as I can tell. >> > 0000000000007c60 g =C2=A0 =C2=A0DF .text =C2=A00000000000000084 =C2=A0= XZ_5.0 >> > lzma_stream_encoder >> > >> > Any clues to what i happening would be greatly appreciated! > > Nothing mysterious here: > > src/lib/libarchive/archive_write_set_compression_xz.c uses some code > from the base system /usr/lib/liblzma.so shared library, from > src/lib/liblzma, which is derived from the base system xz 5.0.1, =A0in > src/contrib/xz. =A0Hence the symbols are present, with the symbol > versions that you noted, but undefined in libarchive, because it is > obtaining them from liblzma at run-time. =A0It nudges rtld(1) to do this > in the usual way, via it's DT_NEEDED tag for that library: > > objdump -x /usr/lib/libarchive.so | egrep 'NEEDED.*lzma' > >> Replying to myself, I re-built all programs that depended on xz and >> then deleted the port. Now everything works fine. I still don't >> completely understand what I was seeing, but it is working, now. > > Perhaps you recently updated your base system, but were using old > ports or packages? =A0 With up-to-date ports and a recent version of > 8-stable you should not have been able to build the archivers/xz port, > even if other ports mistakenly tried to drag it in, because of the > following lines in the ports/archivers/xz Makefile: > > > .if ${OSVERSION} >=3D 900012 || (${OSVERSION} < 900000 && ${OSVERSION} >= =3D 800505) > IGNORE=3D is already in the base system > .endif > > Of course, you could have overridden this, by setting NO_IGNORE. Thanks! Now I understand what was happening much better. It does make sense= . And you were right about the sequence o events. Due to a bug in the atkbd driver in 8.1 and 8.2 I installed 8.0-RELEASE and, after installing a few critical ports (which must have pulled in xz), I csuped RELENG_8, I applied the required patch (which has now been MFCed), and built a stable system. Unfortunately, I now had xz and got into the problems I reported. I am a bit disturbed to note that there is no entry in either /usr/src/UPDATING or /usr/ports/UPDATING about lzma moving into the base system and the need to re-install ports that had depended on the xz port and delete xz. While googling for the problem I found many reports of the problem with no solutions. A note in UPDATING (in this case, probably both of them, but at least /usr/src) could have made them easily resolved. Thanks for taking the time to educate me. I've been working with FreeBSD for several years, but I still don't know a great many things about it. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 19:15:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B96910656AB; Sat, 2 Jul 2011 19:15:52 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 996C98FC1A; Sat, 2 Jul 2011 19:15:51 +0000 (UTC) Received: by qyk30 with SMTP id 30so477594qyk.13 for ; Sat, 02 Jul 2011 12:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=AnQlRddHLy9qT5vwuRjxxkVKEj7G1u/aM4x8Lvqqybs=; b=b/4AUPUIUiAq6x+MbC5h2XodF0mvsGyorNPtLBijGtFmonOs4dYsIopVesogx4ZKQh obVv8+16s2hS7048lTyBb3LzCAtjLU+m3zOdAWHqabRYaHKKScoPo3Qu8qia7x30euVt DvlRmnDc/TqazVl72LPHSIrtpdqU5zZ2pmgKw= Received: by 10.224.137.212 with SMTP id x20mr3730162qat.48.1309632321593; Sat, 02 Jul 2011 11:45:21 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id u10sm236748qct.21.2011.07.02.11.45.19 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 11:45:20 -0700 (PDT) Date: Sat, 2 Jul 2011 14:45:13 -0400 From: Alexander Kabaev To: "Hartmann, O." Message-ID: <20110702144513.5c5b9f75@kan.dnsalias.net> In-Reply-To: <4E0EC86E.9050608@zedat.fu-berlin.de> References: <4E0EC86E.9050608@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eLCFLU41i_AWTsBqDFMYbwD"; protocol="application/pgp-signature" Cc: FreeBSD Current , FreeBSD Stable Subject: Re: devel/subversion: svn: Couldn't perform atomic initialization X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 19:15:52 -0000 --Sig_/eLCFLU41i_AWTsBqDFMYbwD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 02 Jul 2011 09:27:42 +0200 "Hartmann, O." wrote: > Hello. > Since two days now I realize on several recently ports-updated > servers a failure of the subversion server running on those servers. > Sneaking around the internet I found several issues exactly targeting > this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed > in sqlite-3.7.7.2. At this very moment, our subversion servers in > question has all recently been updated and it seems, they all fail > the same way. Does anyone also realize this behaviour shown below > when commiting? >=20 > Is there a workaround? Any help or hint is appreciated. >=20 > Thanks in advance, > Oliver >=20 > Transmitting file data .svn: Commit failed (details follow): > svn: Couldn't perform atomic initialization > svn: database schema has changed > svn: Your commit message was left in a temporary file: >=20 Update database/sqlite3 port to the 3.7.7.1 version committed today. --=20 Alexander Kabaev --Sig_/eLCFLU41i_AWTsBqDFMYbwD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOD2c+Q6z1jMm+XZYRAr4OAJwL5BHanHJGgFPsn6FdsqBPye2JXwCfYswL u/+5f/EOSY6TOzF02WMcqLE= =OyLi -----END PGP SIGNATURE----- --Sig_/eLCFLU41i_AWTsBqDFMYbwD-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 21:11:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FDB106564A for ; Sat, 2 Jul 2011 21:11:09 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5087B8FC13 for ; Sat, 2 Jul 2011 21:11:09 +0000 (UTC) Received: by pvg11 with SMTP id 11so4942007pvg.13 for ; Sat, 02 Jul 2011 14:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1stxn027fgA0xjWqgi/UIeRnA+8/gkDFwqc5jbJoqMs=; b=c2wFSHqZpZt04/QO/8bPkWTopQfWF3QyM70nmeRSmiqqvC1/s8qaN2I3MZWzUwEklQ X5RnrVRQdLJibPiuN1mSbYjLZ5ybLsRFzo/w/jMlgX/M8FDlUucz+7aIAjjXkqNiUXdZ 300TlTRY1SReRT7bjeRuHER11UYgyuEiF3Xks= MIME-Version: 1.0 Received: by 10.68.33.97 with SMTP id q1mr5328039pbi.424.1309641068819; Sat, 02 Jul 2011 14:11:08 -0700 (PDT) Received: by 10.68.64.104 with HTTP; Sat, 2 Jul 2011 14:11:08 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Jul 2011 21:11:08 +0000 Message-ID: From: "b. f." To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: libarchive, lzma, and xz interaction X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 21:11:09 -0000 On 7/2/11, Kevin Oberman wrote: > On Fri, Jul 1, 2011 at 11:32 PM, b. f. wrote: >>> On Fri, Jul 1, 2011 at 7:19 PM, Kevin Oberman ... > And you were right about the sequence o events. Due to a bug in the > atkbd driver in 8.1 and 8.2 I installed 8.0-RELEASE and, after > installing a few critical ports (which must have pulled in xz), I > csuped RELENG_8, I applied the required patch (which has now been > MFCed), and built a stable system. Unfortunately, I now had xz and got > into the problems I reported. > > I am a bit disturbed to note that there is no entry in either > /usr/src/UPDATING or /usr/ports/UPDATING about lzma moving into the > base system and the need to re-install ports that had depended on the > xz port and delete xz. While googling for the problem I found many > reports of the problem with no solutions. A note in UPDATING (in this > case, probably both of them, but at least /usr/src) could have made > them easily resolved. Yes, this probably should have been mentioned in UPDATING. Oddly, it did make it into the 8.1 Release Notes. A complicating factor for those using packages from the FreeBSD build cluster is that the packages for 8* (i.e., packages-stable or packages-8-stable) are usually built on some version of the oldest supported security branch of 8, so for a period of time after the addition of xz to 8-stable those packages included an unnecessary dependency on archivers/xz for users of 8-stable, 8.1, and 8.1-stable. Fortunately, in this case, there probably wouldn't have been any adverse effects, other than a small waste of space and some confusion. b. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 2 21:43:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8CC81065670; Sat, 2 Jul 2011 21:43:22 +0000 (UTC) (envelope-from tts@personalmis.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7D38FC08; Sat, 2 Jul 2011 21:43:21 +0000 (UTC) Received: by bwa20 with SMTP id 20so4957917bwa.13 for ; Sat, 02 Jul 2011 14:43:20 -0700 (PDT) Received: by 10.204.9.203 with SMTP id m11mr4122816bkm.56.1309643000463; Sat, 02 Jul 2011 14:43:20 -0700 (PDT) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx.google.com with ESMTPS id ek1sm4166176bkb.21.2011.07.02.14.43.18 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 14:43:18 -0700 (PDT) Received: by bwa20 with SMTP id 20so4957882bwa.13 for ; Sat, 02 Jul 2011 14:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.9.195 with SMTP id m3mr282764bkm.29.1309642995570; Sat, 02 Jul 2011 14:43:15 -0700 (PDT) Received: by 10.204.117.198 with HTTP; Sat, 2 Jul 2011 14:43:15 -0700 (PDT) In-Reply-To: <8639ioadji.fsf@kopusha.home.net> References: <8639ioadji.fsf@kopusha.home.net> Date: Sat, 2 Jul 2011 14:43:15 -0700 Message-ID: From: Timothy Smith To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: HAST + ZFS: no action on drive failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 21:43:22 -0000 Hello Mikolaj, So, just to be clear, if a local drive fails in my pool, but the corresponding remote drive remains available, then hastd will both write to and read from the remote drive? That's really very cool! I looked more closely at the hastd(8) man page. There is some indication of what you say, but not so clear: "Read operations (BIO_READ) are handled locally unless I/O error occurs or local version of the data is not up-to-date yet (synchronization is in progress)." Perhaps this can be modified a bit? Adding, "or the local disk is unavailable. In such a case, the I/O operation will be handled by the remote resource." It does makes sense however, since HAST is base on the idea of raid. This feature increases the redundancy of the system greatly. My boss will be very impressed, as am I! I did notice however that when the pulled drive is reinserted, I need to change the associated hast resource to init, then back to primary to allow hastd to once again use it (perhaps the same if the secondary drive is failed?). Unless it will do this on it's own after some time? I did not wait more than a few minutes. But this is easy enough to script or to monitor the log and present a notification to admin at such a time. Thank you so much for the help! On Sat, Jul 2, 2011 at 8:49 AM, Mikolaj Golub wrote: > > On Thu, 30 Jun 2011 20:02:19 -0700 Timothy Smith wrote: > > TS> First posting here, hopefully I'm doing it right =) > > TS> I also posted this to the FreeBSD forum, but I know some hast folks > monitor > TS> this list regularly and not so much there, so... > > TS> Basically, I'm testing failure scenarios with HAST/ZFS. I got two > nodes, > TS> scripted up a bunch of checks and failover actions between the nodes. > TS> Looking good so far, though more complex that I expected. It would be > cool > TS> to post it somewher to get some pointers/critiques, but that's another > TS> thing. > > TS> Anyway, now I'm just seeing what happens when a drive fails on primary > node. > TS> Oddly/sadly, NOTHING! > > TS> Hast just keeps on a ticking, and doesn't change the state of the > failed > TS> drive, so the zpool has no clue the drive is offline. The > TS> /dev/hast/ remains. The hastd does log some errors to the > system > TS> log like this, but nothing more. > > TS> messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Unable > to > TS> flush activemap to disk: Device not configured. > TS> messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Local > request > TS> failed (Device not configured): WRITE(4736512, 512). > > Although the request to local drive failed it succeeded on remote node, so > data was not lost, it was considered as successful, and no error was > returned > to ZFS. > > TS> So, I guess the question is, "Do I have to script a cronjob to check > for > TS> these kinds of errors and then change the hast resource to 'init' or > TS> something to handle this?" Or is there some kind of hastd config > setting > TS> that I need to set? What's the SOP for this? > > Currently the only way to know is monitoring logs. It is not difficult to > hook > event for these errors in the HAST code (like it is done for > connect/disconnect, syncstart/done etc) so one could script what to do on > an > error occurrence but I am not sure it is a good idea -- the errors may be > generated with high rate. > > TS> As something related too, when the zpool in FreeBSD does finally > notice that > TS> the drive is missing because I have manually changed the hast resource > to > TS> INIT (so the /dev/hast/ is gone), my zpool (raidz2) hot spare > doesn't > TS> engage, even with "autoreplace=on". The zpool status of the degraded > pool > TS> seems to indicate that I should manually replace the failed drive. If > that's > TS> the case, it's not really a "hot spare". Does this mean the "FMA > Agent" > TS> referred to in the ZFS manual is not implemented in FreeBSD? > > TS> thanks! > TS> _______________________________________________ > TS> freebsd-stable@freebsd.org mailing list > TS> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > TS> To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > > -- > Mikolaj Golub >